Der wichtigste Zugang zu Microsoft 365 ist kein Gebäude, kein VPN und kein Gerät. Es ist die Identität. Wer Identitäten, Rollen und Zugriffswege nicht laufend steuert, verliert früher oder später den Überblick über den tatsächlichen Schutz des Unternehmens.
Microsoft Entra ID verbindet Mitarbeitende, Gäste, Anwendungen und Geräte mit nahezu allen Diensten des Microsoft-365-Mandanten. Diese zentrale Rolle macht die Identitätsplattform leistungsfähig, aber auch anspruchsvoll. Ein Benutzerkonto ist heute selten nur ein Eintrag im Verzeichnis. Es besitzt Gruppenmitgliedschaften, Lizenzen, App-Zustimmungen, Teams-Zugriffe, SharePoint-Berechtigungen, Gerätebeziehungen und möglicherweise administrative Rollen.
In der Praxis entstehen Risiken deshalb weniger durch eine einzelne grobe Fehlkonfiguration als durch viele kleine Veränderungen: Ein Projekt wird verlängert, ein Gast bleibt Mitglied, ein Abteilungswechsel wird nur teilweise umgesetzt oder eine privilegierte Rolle wird nach einer Störung nicht wieder entzogen. Der Zugriff funktioniert weiterhin. Ob er noch gerechtfertigt ist, bleibt jedoch unbeantwortet.
Identitätsverwaltung und Identitätsgovernance sind nicht dasselbe
Identitätsverwaltung sorgt dafür, dass Konten angelegt, geändert und deaktiviert werden. Identitätsgovernance geht einen Schritt weiter. Sie beantwortet, warum eine Person Zugriff erhält, wer diesen Zugriff genehmigt, wie lange er gelten darf und wie regelmäßig seine Notwendigkeit bestätigt wird.
Damit wird aus einer technischen Kontenverwaltung ein nachvollziehbarer Geschäftsprozess. Die Personalabteilung kennt Eintritt, Wechsel und Austritt. Der Fachbereich kennt die benötigten Arbeitsmittel. Die IT kennt technische Abhängigkeiten und Sicherheitsanforderungen. Erst wenn diese Informationen zusammengeführt werden, entsteht ein belastbarer Zugriffsprozess.
Joiner, Mover und Leaver: Drei Phasen, drei typische Fehlerbilder
Der Eintritt
Neue Mitarbeitende sollen am ersten Arbeitstag arbeitsfähig sein. Unter Zeitdruck werden deshalb häufig pauschale Gruppenmitgliedschaften kopiert oder zusätzliche Rechte vorsorglich vergeben. Das beschleunigt den Start, schafft aber unnötige Berechtigungen, deren Ursprung später kaum nachvollziehbar ist.
Ein besserer Einstieg orientiert sich an Rolle, Standort und tatsächlichem Aufgabenprofil. Standardisierte Zugriffspakete können dafür sorgen, dass die benötigten Ressourcen vollständig und nachvollziehbar bereitstehen, ohne historische Berechtigungen eines vermeintlich vergleichbaren Kollegen zu übernehmen.
Der interne Wechsel
Der Abteilungs- oder Rollenwechsel ist oft schwieriger als der Eintritt. Neue Rechte werden ergänzt, alte bleiben bestehen. Nach mehreren Jahren besitzt eine Person dadurch Zugriffe aus unterschiedlichen Tätigkeiten. Gerade bei Finanzdaten, Personalinformationen oder vertraulichen Projekten kann diese Berechtigungsakkumulation problematisch werden.
Ein Rollenwechsel braucht deshalb nicht nur eine Liste neuer Zugriffe, sondern ebenso eine verbindliche Prüfung der bisherigen Berechtigungen. Was nicht mehr zum neuen Aufgabenprofil gehört, sollte kontrolliert entfernt oder mit einem Ablaufdatum versehen werden.
Der Austritt
Ein deaktiviertes Konto ist wichtig, aber nicht die ganze Lösung. Zu einem vollständigen Austritt gehören unter anderem aktive Sitzungen, registrierte Geräte, Weiterleitungen, Postfachzugriffe, Teams-Eigentümerschaften, OneDrive-Inhalte, Gastbeziehungen, App-Zustimmungen und gegebenenfalls privilegierte Rollen. Für jeden dieser Punkte sollte feststehen, wer entscheidet und wer umsetzt.
Besonders kritisch sind Konten, die fachliche Eigentümerschaft tragen. Verlässt der einzige Besitzer eines Teams oder einer SharePoint-Site das Unternehmen, entsteht nicht automatisch ein Sicherheitsvorfall. Wohl aber ein Governance-Problem, das spätestens bei der nächsten Freigabe, Archivierung oder Berechtigungsprüfung sichtbar wird.
Conditional Access braucht ein klares Zielbild
Conditional Access ist die zentrale Richtlinienebene für Zugriffsentscheidungen. Signale wie Benutzer, Anwendung, Gerät, Standort oder Risiko können mit Anforderungen wie Mehrstufenauthentifizierung, einer bestimmten Authentifizierungsstärke oder einem konformen Gerät verbunden werden.
Die Qualität einer Richtlinie zeigt sich jedoch nicht an ihrer Anzahl. Viele überlappende Regeln mit historischen Ausnahmen sind schwer zu verstehen und noch schwerer sicher zu verändern. Sinnvoller ist eine dokumentierte Baseline mit wenigen, klar benannten Schutzabsichten:
- Mehrstufenauthentifizierung für alle relevanten Benutzer und Ressourcen durchsetzen.
- Privilegierte Rollen mit stärkeren Authentifizierungsanforderungen schützen.
- Veraltete oder besonders riskante Authentifizierungsabläufe kontrollieren.
- Zugriffe von nicht verwalteten Geräten abhängig vom Schutzbedarf begrenzen.
- Notfallkonten gezielt ausnehmen, überwachen und regelmäßig testen.
- Änderungen zunächst mit Berichtsfunktionen und einem begrenzten Pilotkreis prüfen.
Eine Ausnahme sollte nie nur aus einem Benutzernamen bestehen. Sie benötigt einen dokumentierten Grund, eine verantwortliche Person und ein Ablaufdatum. Was dauerhaft ausgenommen wird, wird sonst schnell zur unbemerkten Nebenroute in den Mandanten.
Access Reviews machen Berechtigungen überprüfbar
Zugriffsüberprüfungen verlagern Entscheidungen dorthin, wo sie fachlich getroffen werden können. Gruppen- oder Anwendungseigentümer prüfen, ob Mitglieder ihren Zugriff weiterhin benötigen. Für Gäste und projektbezogene Gruppen ist das besonders wertvoll, weil deren Bedarf häufig zeitlich begrenzt ist.
Eine Access Review ist allerdings nur dann wirksam, wenn die Prüfer den Zweck der Ressource verstehen. Eine Liste unbekannter Benutzernamen führt schnell zu vorsorglichen Bestätigungen. Gute Reviews benötigen deshalb verständliche Gruppennamen, eindeutige Eigentümer und einen nachvollziehbaren Nutzungskontext.
Auch der Umgang mit ausbleibenden Antworten sollte vorab festgelegt sein. Wird der Zugriff automatisch entfernt, an eine andere Person eskaliert oder zunächst nur gemeldet? Die richtige Entscheidung hängt vom Schutzbedarf und vom Geschäftsprozess ab. Entscheidend ist, dass sie bewusst getroffen und dokumentiert wird.
Access Packages statt Einzelberechtigungen
Mit Entitlement Management lassen sich mehrere Ressourcen zu einem Zugriffspaket bündeln. Ein Paket für ein Kundenprojekt kann beispielsweise eine Gruppe, ein Team, eine Anwendung und eine SharePoint-Site enthalten. Genehmigung, Laufzeit und regelmäßige Überprüfung werden gemeinsam festgelegt.
Damit wird nicht jede Berechtigung einzeln beantragt. Gleichzeitig lässt sich der Zugriff am Projektende kontrolliert entfernen. Für externe Partner ist dieser Ansatz häufig wesentlich sauberer als eine Folge manueller Einladungen in unterschiedliche Dienste.
Der fachliche Nutzen liegt vor allem in der Wiederholbarkeit: Vergleichbare Anforderungen werden vergleichbar behandelt. Genehmigungen sind nachvollziehbar, Laufzeiten werden nicht vergessen und die IT muss nicht für jeden Zugriff einen individuellen Sonderweg bauen.
Privilegierte Rollen sind Arbeitsmittel, kein Status
Administrative Rollen sollten so spezifisch und so kurz wie möglich genutzt werden. Privileged Identity Management kann Rollen zeitlich begrenzt aktivierbar machen und Anforderungen wie Begründung, Genehmigung oder starke Authentifizierung ergänzen.
Entscheidend bleibt der betriebliche Prozess: Welche Rollen werden tatsächlich benötigt? Wer darf sie aktivieren? Wie werden Notfälle behandelt? Welche Aktivitäten werden kontrolliert? Ein technisch eingerichtetes PIM ohne klare Rollenstrategie reduziert das Risiko nur teilweise.
Globale Administratorrechte aus Bequemlichkeit zu vergeben, ist selten notwendig. Für viele Aufgaben stehen spezifische Rollen zur Verfügung. Das Prinzip der geringsten erforderlichen Berechtigung schützt dabei nicht nur vor Angriffen, sondern begrenzt auch die Auswirkungen unbeabsichtigter Änderungen.
Anwendungen gehören zur Identitätsgovernance
Nicht nur Menschen besitzen Zugriff. Unternehmensanwendungen, Automatisierungen und Integrationen können über Microsoft Graph weitreichende delegierte Berechtigungen oder Anwendungsberechtigungen erhalten. Manche dieser Zugriffe bestehen unabhängig von einem interaktiv angemeldeten Benutzer.
Eine belastbare Governance erfasst deshalb auch Anwendungen: Wer ist Eigentümer? Welchem Geschäftsprozess dient die Integration? Welche Berechtigungen wurden erteilt? Werden alle davon noch benötigt? Wann laufen Zertifikate oder Geheimnisse ab? Wie wird eine Anwendung kontrolliert außer Betrieb genommen?
Gerade bei länger bestehenden Integrationen ist häufig nicht mehr bekannt, wer sie eingeführt hat. Vorschnelles Löschen kann einen Geschäftsprozess unterbrechen. Untätigkeit lässt dagegen unnötige Zugriffswege bestehen. Der richtige Weg beginnt mit Transparenz und geklärter Verantwortung.
Ein pragmatischer Einstieg
- Bestand erfassen: Konten, Gäste, Gruppen, Anwendungen und privilegierte Rollen inventarisieren.
- Prozesse aufnehmen: Die wichtigsten Eintritts-, Wechsel- und Austrittsprozesse gemeinsam mit Personalabteilung und Fachbereichen betrachten.
- Baseline definieren: Eine nachvollziehbare Conditional-Access-Basis festlegen und Ausnahmen vollständig dokumentieren.
- Zeitliche Grenzen einführen: Gast- und Projektzugriffe nach Möglichkeit befristen und über Access Packages erproben.
- Überprüfungen etablieren: Access Reviews für besonders sensible Gruppen, Anwendungen und externe Benutzer einführen.
- Privilegien absichern: Rollenaktivierungen, Notfallzugänge und Abweichungen regelmäßig auswerten.
- Verbesserungen messen: Offene Maßnahmen, Ausnahmen und überfällige Entscheidungen in einem wiederkehrenden Betriebsprozess nachhalten.
Der CloudLights-Blick: Zugriff braucht einen Eigentümer
Identitätsgovernance soll Zusammenarbeit nicht verlangsamen. Sie soll dafür sorgen, dass Zugriffe schnell, passend und nachvollziehbar bereitstehen – und ebenso zuverlässig wieder verschwinden. Gute Governance macht den sicheren Weg zum einfachen Weg.
Wer Zugriffe nur technisch betrachtet, verwaltet Konten. Wer Zweck, Verantwortlichkeit und Lebenszyklus einbezieht, steuert das Unternehmen. Genau dort beginnt ein Microsoft-365-Mandant, dauerhaft beherrschbar zu werden.
Weiterführende Microsoft-Quellen
- Microsoft Entra Conditional Access
- Microsoft Entra ID Governance
- Entitlement Management und Access Packages
- Lifecycle Workflows
- Access Reviews für Gruppen und Anwendungen
Mit Unterstützung von KI erzeugt.
