Navigationspfad

Zugriff auf Systeme von Drittanbietern

Einleitung

Dieses Dokument beschreibt den Umfang der Zugriffsrechte, die Identum während und nach der Projektumsetzung auf Kundensysteme benötigt. Gemäß unserer Richtlinie nutzen wir vorübergehende Zugriffsrechte mit den geringstmöglichen Berechtigungen, die zur Erledigung der erforderlichen Aufgaben notwendig sind. Identum benötigt keinen dauerhaften Zugriff auf Kundenumgebungen.


1. Quellsysteme

Identum benötigt keinen permanenten Benutzerzugriff auf Quellsysteme wie HRM/Lohnabrechnung, Studierendeninformationssysteme oder andere Personaldatenbanken. Der Zugriff auf Datenexporte aus diesen Systemen – entweder per Dateiübertragung oder über eine API – ist ausreichend.

Hinweis: Auf Anfrage benötigen wir möglicherweise vorübergehend Zugriff für bestimmte Aufgaben wie die Fehlerbehebung oder Schulungen.


2. Dataporten / Feide-Kundenportal

Wir benötigen keinen dauerhaften Zugriff auf Dataporten oder das Sikt-Kundenportal (ehemals Uninett). Bei Bedarf kann auf Anfrage ein vorübergehender Zugriff gewährt werden.


3. Microsoft Azure Active Directory (Azure AD)

Damit unsere Dienste (eADM/eFeide) Benutzer, Gruppen, Passwörter, Lizenzen, Mitgliedschaften und Status mit Azure AD synchronisieren können, benötigen wir ein Konto mit Berechtigungen, die denen eines Benutzeradministrators in Microsoft 365 entsprechen.

  • Dieser Zugriff ist nur für die Dauer des Projekts erforderlich.

  • Das Konto muss durch eine Multi-Faktor-Authentifizierung (MFA) geschützt sein.

  • Das Konto muss nach Abschluss des Projekts deaktiviert oder gelöscht werden.

Hinweis: Die laufende Kommunikation zwischen eADM/eFeide und Azure AD wird über eine Azure-Unternehmensanwendung verwaltet, nicht über ein Benutzerkonto. Einzelheiten zur Konfiguration finden Sie in unserer Dokumentation: So konfigurieren Sie Azure AD für die Integration.


4. Google Workspace

Damit unsere Dienste Benutzer, Gruppen, Passwörter, Organisationseinheiten (OUs), Mitgliedschaften und Status mit Google Workspace synchronisieren können, benötigen wir ein Benutzerkonto mit Berechtigungen, die denen eines „User Management Admin“ entsprechen.

  • Dieses Konto muss durch MFA geschützt werden.

  • Das Konto kann nach Abschluss des Projekts deaktiviert werden.

Außerdem muss der globale Administrator des Kunden Zugriffsschlüssel für unseren API-Client konfigurieren.


5. Lokales Active Directory (AD)

Für die Integration in ein lokales Active Directory wird eine Client-Anwendung im internen Netzwerk des Kunden installiert. eADM benötigt keinen dedizierten Server. Wir raten davon ab, die eADM-Client-Anwendung auf einem Domänencontroller zu installieren.


Kundenkommunikation

  • Der Client ist eine Windows-basierte .NET-Konsolenanwendung, die als geplante Aufgabe unter Verwendung eines Dienstkontos ausgeführt wird.

  • Die Kommunikation mit unserer Cloud-Lösung wird vom Client über eine verschlüsselte Verbindung (TLS 1.2 oder höher, ausgehend über Port 443) initiiert. Es sind keine Öffnungen in der Firewall für eingehenden Datenverkehr erforderlich.

  • Jeder Client verwendet eindeutige Authentifizierungsschlüssel, um mit dem Cloud-Dienst zu kommunizieren.


Zugang für Berater (während des Projekts)

Während des Projekts benötigt der Projektleiter und/oder Berater einen Fernzugriff auf die lokale AD-Umgebung über VPN oder TeamViewer.

  • Dieser Zugriff muss durch MFA geschützt werden.

  • Der Zugriff kann über einen primären Domänencontroller erfolgen, wir empfehlen jedoch die Verwendung eines dedizierten Servers für den eADM-Client.

  • Der Server muss Zugriff auf Folgendes haben:

    • Active Directory-Benutzer und -Computer

    • Active Directory-Modul für Windows PowerShell

    • Windows Exchange-Verwaltungstools für PowerShell (falls zutreffend)


Serveranforderungen

  • Betriebssystem: Windows Server

  • .NET Framework: Version 4.0 oder höher

  • PowerShell: Version 4.0 oder höher

  • Firewall: Port 443 muss für ausgehenden SSL-Datenverkehr geöffnet sein.

  • Software: Bitte stellen Sie sicher, dass Notepad++ auf dem Server installiert ist.


Berechtigungen für Dienstkonten

Zum Ausführen des eADM-Clients ist ein spezielles Dienstkonto erforderlich. Dieses Konto benötigt die folgenden Berechtigungen:

  • AD-Rechte: Benutzer, Gruppen und Organisationseinheiten anlegen, löschen und bearbeiten.

  • Lokale Rechte:

    • Als Batch-Job anmelden (für geplante Aufgaben).

    • Vollständiger Lese- und Schreibzugriff auf C:\eADM\ und dessen Unterordner.

  • Optionale Rechte (falls zutreffend):

    • NTFS-Berechtigungen für Benutzer-Home-Ordner erstellen und festlegen.

    • Postfächer anlegen (enable-mailbox und enable-remotemailbox).

Warnung: Sobald das System in Betrieb ist, müssen unsere persönlichen Benutzerkonten deaktiviert werden. Alle betrieblichen Aufgaben werden über das Dienstkonto ausgeführt, dessen Passwort geändert werden sollte, damit Identum keinen Zugriff mehr darauf hat.

Diese Standardarbeitsanweisung (SOP) legt die Zugriffsberechtigungen fest, die Identum für kundeneigene Systeme von Drittanbietern wie Azure AD, Google Workspace und das lokale Active Directory benötigt. Dabei wird betont, dass der Zugriff vorübergehend ist, auf die Projektlaufzeit beschränkt ist und dem Prinzip der geringsten Berechtigungen folgt. Das Dokument enthält detaillierte Anforderungen an Dienstkonten, den Zugriff für Berater, die Serverkonfiguration und Sicherheitsprotokolle, einschließlich der obligatorischen Verwendung von MFA und der Deaktivierung von Konten nach Projektende.

Zuletzt aktualisiert: