Microsoft 365 · Externe Administration · Berechtigungsprüfung
Ein beendeter Dienstleistervertrag entfernt nicht automatisch jeden technischen Zugriff. Partnerbeziehungen, direkte Administratorkonten, Gastbenutzer, Gruppen, Unternehmensanwendungen und Azure-Rollen bilden voneinander unabhängige Wege. Eine belastbare Prüfung erfasst deshalb nicht nur Namen, sondern Rolle, Geltungsbereich, Authentifizierung, letzte Nutzung und geschäftlichen Zweck.
Prüfregel: Gewährter Zugriff und tatsächlich ausgeübter Zugriff werden getrennt bewertet. Zuerst wird der vollständige Bestand gesichert, danach werden unnötige Rechte kontrolliert entfernt und schließlich mit Protokollen sowie einem Testkonto nachgewiesen, dass kein unbeabsichtigter Verwaltungsweg verblieben ist.
Die Kurzantwort: Sechs Zugriffsebenen gemeinsam prüfen
Die Prüfung umfasst Partnerbeziehungen, Microsoft-Entra-Rollen, rollenberechtigte Gruppen, Benutzer- und Gastkonten, Anwendungen mit delegierten oder anwendungsbezogenen Berechtigungen sowie getrennte Azure-Rollen. Erst wenn alle Ebenen einem aktuellen Auftrag zugeordnet sind, ist die Frage „Wer kann was administrieren?“ belastbar beantwortet.
| Zugriffsebene | Wo sie geprüft wird | Wesentliche Frage |
|---|---|---|
| Partnerbeziehung | Microsoft 365 Admin Center, Einstellungen, Partnerbeziehungen | Welche Rollen besitzt welcher Partner, wie lange und für welchen Auftrag? |
| Direkte Entra-Rolle | Entra Admin Center, Rollen und Administratoren | Ist die Person oder Gruppe aktiv oder nur berechtigt, und auf welchem Geltungsbereich? |
| Benutzer und Gäste | Entra Admin Center, Benutzer sowie Gruppenmitgliedschaften | Gehört das Konto zu einer realen Person, und ist dessen Zugriff noch erforderlich? |
| Unternehmensanwendung | Entra Admin Center, Unternehmensanwendungen, Berechtigungen und Zustimmung | Kann die Anwendung ohne interaktive Person auf Daten oder Verzeichnis zugreifen? |
| Azure-Ressource | Azure-Portal, Abonnement oder Ressource, Zugriffssteuerung | Bestehen Owner-, Contributor- oder andere Rollen getrennt von Microsoft 365 fort? |
| Lokales oder verbundenes System | Server, Firewall, Backup, Domainregistrar, Supportportal und Fernwartung | Welche Zugänge liegen außerhalb des Microsoft-365-Mandanten? |
Der Anzeigename eines Kontos beweist weder Arbeitgeber noch Zweck
Ein Konto namens „IT Support“ kann intern angelegt, einem früheren Dienstleister übergeben oder von mehreren Personen genutzt worden sein. Die Prüfung benötigt deshalb eindeutige Person oder technische Identität, verantwortliche Organisation, Auftrag, Rollen, Anmeldemethode und dokumentierten Eigentümer im eigenen Unternehmen.
1. Microsoft 365 kennt mehrere voneinander unabhängige Verwaltungswege
Ein Dienstleister kann über seine Partnerorganisation, ein Konto im Kundenmandanten, eine Anwendung oder eine Azure-Rolle arbeiten. Manche Aufträge verwenden mehrere Wege gleichzeitig. Das Ende eines Weges sagt daher nichts Sicheres über die übrigen aus.
| Typ | Funktionsweise | Typisches Risiko |
|---|---|---|
| GDAP | Zeitlich begrenzte Partnerbeziehung mit benannten Microsoft-Entra-Rollen, die Partner-Sicherheitsgruppen zugeordnet werden | Zu viele Rollen, zu lange Laufzeit oder fehlende Prüfung des aktuellen Auftrags |
| Legacy-DAP | Älterer delegierter Partnerzugriff mit sehr weitreichender Administration | Breite Rechte ohne granulare Begrenzung |
| Direktes Mitgliedskonto | Konto wird im Kundenmandanten angelegt und erhält Rollen oder Gruppenrechte | Bleibt nach Personal- oder Anbieterwechsel bestehen; Identität und MFA liegen beim Kundenmandanten. |
| Gastkonto | Externe Identität wird eingeladen und erhält direkte oder gruppenbasierte Rechte | Gaststatus wird fälschlich mit geringer Berechtigung gleichgesetzt. |
| Unternehmensanwendung | Service Principal erhält delegierte oder Anwendungsberechtigungen und gegebenenfalls Administratorzustimmung | Anwendungsberechtigung kann ohne angemeldeten Benutzer und außerhalb eines Arbeitszeitfensters wirken. |
| Azure RBAC | Rolle gilt auf Managementgruppe, Abonnement, Ressourcengruppe oder Ressource | Bleibt trotz Entfernung von Microsoft-365-Partnerrollen separat bestehen. |
| Fernwartung oder Supportportal | Zugriff erfolgt über ein anderes Produkt auf Endgeräte, Backups oder Netze | Im Entra-Rollenbestand unsichtbar und deshalb beim Offboarding leicht vergessen |
Auch innerhalb einer Entra-Rolle ist der Geltungsbereich relevant. Eine Rolle kann mandantenweit, für eine administrative Einheit oder für ein bestimmtes Objekt gelten. Bei Privileged Identity Management wird zusätzlich zwischen dauerhaft aktiver und nur berechtigter, zeitweise aktivierbarer Zuweisung unterschieden. Diese Funktionen und Berichte hängen von der vorhandenen Lizenzierung ab; eine manuelle Prüfung bleibt unabhängig davon erforderlich.
2. Die Inventur verbindet technische Zuweisung und geschäftlichen Auftrag
Ein technischer Export zeigt, dass ein Recht existiert. Ob es erforderlich und angemessen ist, ergibt sich erst aus Vertrag, Leistungsumfang, verantwortlicher Fachperson und letztem nachvollziehbaren Einsatz.
Schritt für Schritt: Externe Verwaltungsrechte vollständig erfassen
- Prüfzeitraum, verantwortliche interne Person und Systeme im Umfang schriftlich festlegen.
- Mindestens zwei funktionsfähige interne Administrations- und Notfallzugänge prüfen, bevor externe Rechte verändert werden.
- Aktuelle Verträge, Leistungsbeschreibungen, Laufzeiten, Ansprechpartner und vereinbarte Administrationsaufgaben zusammenstellen.
- Partnerbeziehungen im Microsoft 365 Admin Center mit Partnername, Beziehungstyp, Rollen und Ablaufdatum erfassen.
- Alle aktiven und berechtigten Microsoft-Entra-Rollenzuweisungen exportieren, einschließlich Gruppen und Geltungsbereichen.
- Mitglieder rollenberechtigter Gruppen auflösen; Gruppenname allein reicht nicht.
- Benutzer mit externer Domain, Gaststatus, verdächtigem Anzeigenamen oder dienstleisterbezogener Beschreibung erfassen.
- Für jedes Konto direkte Rollen, Gruppen, Lizenzen, registrierte Authentifizierungsmethoden und Kontostatus prüfen.
- Unternehmensanwendungen und Service Principals mit Eigentümern, Anmeldeaktivität, delegierten Berechtigungen, Anwendungsberechtigungen und Administratorzustimmung erfassen.
- App-Registrierungen auf Client-Geheimnisse, Zertifikate, Ablaufdaten und verantwortliche Eigentümer prüfen.
- Azure-Abonnements, Ressourcengruppen und kritische Ressourcen auf externe Rollen sowie Partnerzuweisungen untersuchen.
- Exchange-, SharePoint-, Teams-, Intune- und Sicherheitsrollen berücksichtigen, auch wenn sie nicht als Globaler Administrator erscheinen.
- Supportportale, Fernwartung, Backup, Domainverwaltung, DNS, Hosting, Firewall und lokale Administratoren außerhalb des Mandanten ergänzen.
- Für jede Identität letzte interaktive und nicht interaktive Anmeldung sowie relevante Auditereignisse im verfügbaren Zeitraum sichern.
- Jeden Zugriff einem aktuellen Auftrag, konkreter Aufgabe, internen Eigentümer und erforderlichen Geltungsbereich zuordnen.
- Abweichungen als behalten, reduzieren, ersetzen, entfernen oder weiter untersuchen klassifizieren.
- Änderungsreihenfolge und Rückfallplan festlegen, damit der Betrieb nicht von einem ungeprüften Einzelzugang abhängt.
- Bestand vor jeder Änderung exportieren und Integrität, Zeitpunkt sowie ausführende Person dokumentieren.
| Feld | Beispiel für ausreichende Genauigkeit | Unzureichend |
|---|---|---|
| Identität | Partnerorganisation, konkrete Person, Gastkonto oder Service Principal mit Objekt-ID | „IT-Firma“ |
| Zugriffsweg | GDAP, direkte Rolle, Gruppe, App-Berechtigung, Azure RBAC oder Fernwartung | „Adminzugriff“ |
| Recht und Umfang | Exchange Administrator mandantenweit oder Reader auf Ressourcengruppe X | „Kann E-Mail“ |
| Geschäftsgrund | Postfachmigration bis Abnahme am konkreten Datum | „Für Support“ |
| Eigentümer | Interne Rolle, die Bedarf bestätigt und Entzug auslösen darf | Nur externer Ansprechpartner |
| Lebenszyklus | Beginn, Ende, letzte Prüfung und nächster Prüftermin | Kein Ablauf |
| Nutzung | Letzte Anmeldung oder App-Aktivität mit Quelle und Zeitraum | „Wird vermutlich genutzt“ |
| Entscheidung | Behalten, reduzieren oder entfernen mit Begründung und Termin | Leeres Kommentarfeld |
3. Partnerbeziehungen werden im Microsoft 365 Admin Center separat bewertet
Delegierte Partnerrechte sind nicht zuverlässig aus der gewöhnlichen Entra-Benutzerliste abzuleiten. Die Partnerbeziehungsseite zeigt, welche Organisationen als Händler oder mit administrativen Rollen verbunden sind.
| Beobachtung | Bedeutung | Entscheidung |
|---|---|---|
| Reseller ohne Administratorrollen | Partner kann Produkte oder Lizenzen bereitstellen, hat aber über diese Beziehung keinen Verwaltungszugriff auf Dienste. | Kauf- und Vertragsbeziehung getrennt bewerten. |
| GDAP mit begrenzten Rollen | Partnergruppen können die angegebenen Aufgaben während der Beziehungsdauer ausführen. | Rollen, Dauer und Leistungsauftrag einzeln abgleichen. |
| GDAP mit Global Administrator | Granulare Technik wurde verwendet, aber die gewählte Rolle besitzt weiterhin sehr weitreichende Befugnisse. | Konkrete Notwendigkeit prüfen und durch kleinere Rollen ersetzen. |
| DAP oder Global Administrator als Partnerrolle | Älterer, breiter delegierter Zugriff | Dringend prüfen, entfernen und erforderlichen Zugriff gezielt neu gestalten. |
| Rollen entfernt, Reseller bleibt | Administration endet, Handelsbeziehung kann fortbestehen. | Gewünschter Zustand, wenn nur Lizenzbezug benötigt wird. |
| Partnerrollen entfernt, Azure-Zugriff bleibt | Azure RBAC ist eine separate Berechtigungsebene. | Abonnement und Ressourcen zusätzlich prüfen. |
Schritt für Schritt: Eine GDAP-Anfrage vor Annahme prüfen
- Anfragende Partnerorganisation gegen Vertrag und bekannten Ansprechpartner prüfen.
- Beziehungsname, angeforderte Dauer und jede einzelne Rolle erfassen.
- Für jede Rolle die konkrete Aufgabe benennen lassen, die ohne sie nicht ausführbar wäre.
- Global Administrator, Privileged Role Administrator und andere weitreichende Rollen besonders begründen und möglichst ersetzen.
- Dauer auf Projekt oder Betreuungszeitraum begrenzen; automatische Bequemlichkeitsverlängerung vermeiden.
- Interne Person als Eigentümer und einen Prüftermin vor Ablauf festlegen.
- Anfrage nur über das bekannte Microsoft-365-Admin-Center prüfen; Link aus einer unerwarteten Nachricht nicht als alleinigen Einstieg verwenden.
- Nach Annahme sichtbare Rollen und Laufzeit erneut gegen die genehmigte Fassung vergleichen.
- Ersten administrativen Einsatz anhand des Audit- und Anmeldeverlaufs kontrollieren.
- Abweichung sofort stoppen und mit dem Partner über einen bekannten Kontaktweg klären.
4. Die Rolle wird aus konkreten Tätigkeiten und nicht aus der Berufsbezeichnung abgeleitet
„IT-Support“, „Administrator“ oder „Systemhaus“ sind keine Berechtigungsanforderungen. Für jede wiederkehrende Aufgabe wird ermittelt, welche kleinste integrierte Rolle sie ermöglicht, welche zusätzlichen Aktionen diese Rolle erlaubt und ob sie dauerhaft oder nur für ein Projekt benötigt wird.
| Tatsächliche Aufgabe | Zu prüfende kleinere Rolle | Warum Global Administrator regelmäßig zu weit geht |
|---|---|---|
| Benutzer anlegen und grundlegende Eigenschaften verwalten | User Administrator; genaue Grenzen und Zielgruppe prüfen | Globaler Administrator kann Sicherheits- und Mandanteneinstellungen weit über Benutzerverwaltung hinaus verändern. |
| Ausgewählte Kennwort- und Anmeldeprobleme bearbeiten | Helpdesk Administrator oder Authentication Administrator nach betroffenem Personenkreis | Supportfall benötigt keine vollständige Kontrolle über Anwendungen, Domains und Administratorrollen. |
| Exchange Online konfigurieren | Exchange Administrator | Postfach- und Transportaufgaben begründen keinen Zugriff auf sämtliche übrigen Dienste. |
| SharePoint und OneDrive verwalten | SharePoint Administrator | Sites und Freigaben lassen sich ohne mandantenweite Volladministration bearbeiten. |
| Teams-Richtlinien und Besprechungen verwalten | Passende Teams-Administratorrolle je Aufgabe | Teams-Betrieb erfordert keine freie Rollenvergabe im Verzeichnis. |
| Intune-Geräte und Richtlinien administrieren | Intune Administrator oder eine passend begrenzte Intune-Rolle | Geräteverwaltung darf nicht automatisch sämtliche Identitäten und Cloud-Dienste kontrollieren. |
| Sicherheitsbefunde nur lesen | Security Reader beziehungsweise passende Lesefunktion | Analyse und Berichterstellung benötigen häufig keine Änderungsrechte. |
| Administrative Rollen zuweisen | Privileged Role Administrator nur bei ausdrücklich beauftragter Rollenverwaltung | Rollenvergabe kann weitere hochprivilegierte Zugänge schaffen und ist selbst besonders kritisch. |
| Mandantenweite Notfalländerung | Global Administrator nur für den begründeten Ausnahmefall | Die Rolle besitzt sehr breite Kontrolle und ist kein Standard für täglichen Support. |
Die Tabelle ist eine Vorauswahl, keine automatische Rollenzuweisung. Microsoft verändert Dienste und Rollengrenzen; außerdem können einzelne Aufgaben zusätzliche Rechte oder einen anderen Geltungsbereich verlangen. Vor der Freigabe wird die aktuelle Rollendokumentation gelesen und die konkrete Tätigkeit mit einem Testkonto ausgeführt.
Steht Privileged Identity Management in der vorhandenen Lizenzierung zur Verfügung, kann eine Person für eine Rolle lediglich berechtigt sein und sie nur bei Bedarf aktivieren. Aktivierung kann Dauer, Begründung, MFA, Ticketangabe oder Genehmigung verlangen. Das reduziert dauerhaft aktive Rechte, ersetzt aber weder die Prüfung der zugrunde liegenden Berechtigung noch den Entzug am Vertragsende.
Für kleine Mandanten ohne PIM wird derselbe Grundgedanke organisatorisch umgesetzt: selten benötigte Hochrechte werden nicht dauerhaft am externen Tageskonto belassen. Eine benannte interne Person genehmigt die konkrete Änderung, vergibt oder begleitet den zeitlich abgegrenzten Zugriff und kontrolliert anschließend Protokoll sowie Rücknahme.
Die dokumentierte Aufgabe bleibt dabei der Maßstab. Eine Rolle wird weder vorsorglich für mögliche spätere Arbeiten noch allein aufgrund langjähriger Zusammenarbeit vergeben. Entsteht ein neuer Bedarf, wird er als neuer Berechtigungsvorgang mit Umfang, Dauer und Abnahme behandelt.
Schritt für Schritt: Eine bestehende Global-Administrator-Zuweisung reduzieren
- Alle realen Tätigkeiten des externen Kontos aus Auftrag, Tickets und Protokollen sammeln.
- Einmalige Projektaufgaben von wiederkehrendem Regelbetrieb trennen.
- Für jede Tätigkeit die aktuell dokumentierte kleinste geeignete Rolle und den erforderlichen Geltungsbereich bestimmen.
- Besonders kritische Aktionen wie Rollenvergabe, Conditional Access, Domains oder App-Zustimmung ausdrücklich kennzeichnen.
- Neue kleinere Rollen zunächst zusätzlich an ein persönliches Test- oder Pilotkonto vergeben.
- Typische Arbeitsfälle in Exchange, SharePoint, Teams, Intune oder Benutzerverwaltung vollständig ausführen.
- Prüfen, ob nur die beauftragten Objekte sichtbar und veränderbar sind; ein erfolgreicher Hauptfall allein reicht nicht.
- Fehlende Einzelaufgabe nicht sofort mit Global Administrator lösen, sondern alternative Rolle oder internen Freigabeprozess prüfen.
- Erforderliche Rollen, Laufzeit, Geltungsbereich und getestete Tätigkeiten dokumentieren.
- Global-Administrator-Zuweisung in einem angekündigten Wartungsfenster entfernen.
- Externe Regelaufgaben erneut testen und Anmelde- sowie Auditprotokoll auf die verwendete Identität prüfen.
- Für seltene hochprivilegierte Änderungen einen zeitlich begrenzten, freizugebenden Weg festlegen, sofern Lizenz und Betriebsmodell dies unterstützen.
- Alte Gruppenzuweisungen kontrollieren, damit sie die entfernte direkte Rolle nicht unbemerkt erneut vermitteln.
- Nachher-Bestand mit vorherigem Rollenexport vergleichen und die Reduktion durch den internen Eigentümer abnehmen lassen.
Leserechte können bereits vertrauliche Informationen erschließen
Eine Rolle ohne Änderungsbefugnis ist nicht automatisch unkritisch. Sicherheits-, Nachrichtenfluss-, Benutzer- oder Gerätereports können personenbezogene Daten, interne Adressen, Systemnamen und Angriffshinweise enthalten. Leserechte werden daher ebenfalls nach Auftrag, Empfängerkreis, Aufbewahrung und Vertragsende begrenzt.
5. Direkte externe Konten benötigen eine persönliche Zuordnung und einen eigenen Lebenszyklus
Ein im Kundenmandanten angelegtes Administratorkonto kann sinnvoll sein, wenn kein Partnerzugriff verwendet wird. Es darf jedoch weder geteilt noch nach dem Ende einer Person oder Leistung unbeaufsichtigt weiterbestehen.
| Prüffeld | Tragfähiger Zustand | Abweichung |
|---|---|---|
| Person | Eindeutige natürliche Person und arbeitgebende Organisation dokumentiert | Geteiltes Konto „support@“ |
| Kontentrennung | Administrationskonto getrennt vom täglichen E-Mail- und Webkonto | Privilegierte Rolle am normalen Benutzerkonto |
| Rolle | Kleinste für die Aufgabe geeignete Rolle und passender Geltungsbereich | Globaler Administrator aus Gewohnheit |
| Authentifizierung | Phishing-resistente MFA für privilegierte Aufgaben und kontrolliertes Ersatzverfahren | SMS oder gemeinsames Diensttelefon als einziger Faktor |
| Gerät | Vertrauenswürdiges, gepflegtes Administrationsgerät | Beliebiges privates Gerät ohne vereinbarte Anforderungen |
| Laufzeit | Projektende, Vertragsende oder regelmäßige Bestätigung | Dauerhaft aktiv ohne Eigentümer |
| Nutzung | Protokollierbar und einem Ticket oder Auftrag zuordenbar | Ungeklärte Anmeldung außerhalb des Einsatzes |
Der Entra-Wert „User type: Guest“ ist keine Sicherheitsstufe. Ein Gast kann über direkte Rolle oder Gruppe hohe Rechte besitzen; ein Mitgliedskonto kann dennoch einer externen Person gehören. Domain, Ersteller, Sponsoring, Gruppen, Rollen, letzte Anmeldung und aktueller Geschäftsgrund werden deshalb gemeinsam betrachtet.
Interner Notfallzugang bleibt unabhängig vom Dienstleister
Vor dem Entzug externer Rechte müssen funktionsfähige interne Notfallkonten und die dazugehörigen Authenticatoren vorhanden sein. Sie verwenden andere Abhängigkeiten als die täglichen Administratorkonten, werden überwacht und regelmäßig getestet. Ein externer Anbieter verwahrt nicht den einzigen Weg, mit dem der Kunde seinen eigenen Mandanten wieder übernehmen kann.
6. Anwendungen können weiter zugreifen, obwohl kein externer Administrator angemeldet ist
Backup, Migration, Signatur, Archivierung und Verwaltung werden häufig als Unternehmensanwendung eingebunden. Anwendungsberechtigungen können ohne Benutzerkontext wirken. Ihr Entzug ist daher ein eigener Arbeitsschritt.
| Merkmal | Delegierte Berechtigung | Anwendungsberechtigung |
|---|---|---|
| Handlungskontext | Anwendung handelt im Kontext eines angemeldeten Benutzers. | Anwendung handelt als eigene technische Identität. |
| Reichweite | Durch Zustimmung und Rechte des Benutzers begrenzt | Kann mandantenweit auf freigegebene Datenklassen zugreifen. |
| Aktivität | Oft in Benutzeranmeldungen und Zustimmungsereignissen sichtbar | Service-Principal-Anmeldungen, Audit- und Graph-Aktivität prüfen. |
| Entzug | Zustimmung, Zuweisung und gegebenenfalls Benutzersitzung entfernen | App-Rollen, Credentials, Service Principal und Herstellerintegration kontrolliert entfernen. |
| Häufiger Fehler | Benutzer wird gelöscht, aber eine andere Zustimmung bleibt. | Vertrag endet, doch Zertifikat oder Client-Geheimnis funktioniert weiter. |
Schritt für Schritt: Eine externe Unternehmensanwendung prüfen
- Anzeigename, Anwendungs-ID, Service-Principal-Objekt-ID, Herausgeber und Erstellungsdatum erfassen.
- Verifizierten Herausgeber als Indiz, nicht als Beweis für den eigenen Geschäftsgrund behandeln.
- Interne Eigentümer und externen Anbieter gegen Vertrag und aktuelle Leistung prüfen.
- Delegierte Berechtigungen und Anwendungsberechtigungen getrennt exportieren.
- Für jede weitreichende Microsoft-Graph-Berechtigung benötigte Daten, Zweck und Begrenzung dokumentieren.
- Administrator- und Benutzerzustimmungen sowie Zeitpunkt ihrer Erteilung prüfen.
- Benutzer- und Gruppenzuweisungen sowie die Einstellung zur erforderlichen Zuweisung erfassen.
- Client-Geheimnisse und Zertifikate mit Ablaufdatum, letztem Wechsel und sicherem Eigentümer prüfen.
- Interaktive, nicht interaktive und Service-Principal-Anmeldungen im verfügbaren Protokollzeitraum auswerten.
- Auditereignisse für neue Berechtigungen, Zustimmungen, Credentials und Eigentümer suchen.
- Mit Fachverantwortlichen klären, welche Geschäftsabläufe beim Entzug tatsächlich ausfallen.
- Nicht mehr benötigte Berechtigung zuerst in einem kontrollierten Fenster entfernen und Wirkung testen.
- Anwendung nach vollständigem Vertragsende deaktivieren oder löschen, sobald Export, Aufbewahrung und Rückfall geklärt sind.
- Nach dem Entzug prüfen, dass frühere Credentials und Tokens keinen erfolgreichen Zugriff mehr ermöglichen.
7. Protokolle zeigen Nutzung, ersetzen aber nicht die Berechtigungsprüfung
Ein ungenutztes Recht kann weiterhin gefährlich sein; ein fehlender Treffer kann aus kurzer Aufbewahrung, falschem Protokolltyp oder nicht interaktiver Nutzung entstehen. Protokolle ergänzen den Bestand um tatsächliche Aktivität.
| Quelle | Kann zeigen | Kann nicht allein beweisen |
|---|---|---|
| Benutzer-Anmeldeprotokoll | Zeit, Anwendung, IP, Gerät, Authentifizierung und Richtlinien einer Anmeldung | Dass das Konto keine weiteren Rechte besitzt |
| Nicht interaktive Anmeldung | Tokenbasierte Hintergrundaktivität eines Benutzers | Den vollständigen Inhalt jeder ausgeführten Aktion |
| Service-Principal-Anmeldung | Authentifizierung einer Anwendung ohne Benutzer | Dass jede gewährte Berechtigung genutzt wurde |
| Entra-Auditprotokoll | Änderungen an Rollen, Gruppen, Anwendungen, Credentials und Zustimmungen | Alle Aktionen in Exchange, SharePoint oder Azure |
| Microsoft-365-Audit | Workload-Aktivitäten abhängig von Dienst, Lizenz und Auditierung | Unbegrenzte historische Vollständigkeit |
| Azure-Aktivitätsprotokoll | Verwaltungsaktionen an Azure-Ressourcen und Rollen | Microsoft-365-Partnerbeziehungen |
Vor einer Bereinigung werden relevante Protokolle innerhalb ihrer verfügbaren Aufbewahrungszeit exportiert. Zeitstempel werden auf eine gemeinsame Zeitzone gebracht. IP-Adresse und Standort sind Hinweise, keine sichere Personenidentifikation: VPN, Mobilfunk, Partnernetze und Cloud-Dienste können die Darstellung verändern.
8. Der Entzug folgt einer Reihenfolge, die Kontrolle und Betriebsfähigkeit erhält
Bei einem planmäßigen Anbieterwechsel werden interne Eigentümer, Dokumentation und Ersatzadministration zuerst hergestellt. Bei Missbrauchsverdacht steht dagegen die sofortige Eindämmung im Vordergrund. Beide Fälle benötigen eine abschließende technische Kontrolle.
Schritt für Schritt: Einen Dienstleisterzugang vollständig beenden
- Stichtag, betroffene Leistungen, internen Entscheider und technische Ausführung festlegen.
- Funktionsfähige interne Administrator- und Notfallkonten mit unabhängigen Authenticatoren testen.
- Konfigurationen, Dokumentation, Domains, Lizenzen, Backups, Geräteschlüssel und offene Vorgänge übernehmen.
- Vollständigen Vorher-Bestand der Partner-, Rollen-, Konto-, App- und Azure-Zugriffe sichern.
- Partner-GDAP- oder DAP-Rollen im Microsoft 365 Admin Center entfernen, wenn sie nicht mehr benötigt werden.
- Reseller- und Lizenzbeziehung bewusst behalten oder gesondert vertraglich beenden; beides nicht mit Administratorrechten verwechseln.
- Direkte Rollen von externen Benutzer- und Gastkonten entfernen.
- Mitgliedschaften in rollenberechtigten und fachlichen Gruppen entziehen.
- Konten sperren, Sitzungen widerrufen und registrierte Authentifizierungsmethoden nach Beweissicherung entfernen.
- Unternehmensanwendungen deaktivieren oder deren Zustimmungen, App-Rollen, Secrets und Zertifikate kontrolliert entziehen.
- Azure-RBAC-Zuweisungen auf Abonnement-, Ressourcengruppen- und Ressourcenebene separat entfernen.
- Fernwartung, lokale Administratoren, Backup-Portale, Domainregistrar, DNS, Hosting und Geräteverwaltung außerhalb Microsoft 365 bearbeiten.
- Gemeinsam bekannte Kennwörter, Recovery-Codes, API-Schlüssel und andere nicht rückholbare Geheimnisse risikobasiert rotieren.
- Protokolle auf Zugriff nach dem Stichtag sowie ungewöhnliche Änderungen vor dem Stichtag prüfen.
- Fachliche Funktionen testen: E-Mail, Benutzerverwaltung, Geräte, Backup, Domains, Lizenzierung und Sicherheitsmeldungen.
- Mit früherem externem Konto oder kontrolliertem Test nachweisen, dass die entfernten Wege tatsächlich abgewiesen werden.
- Nachher-Bestand erzeugen und Added/Removed/Retained mit Begründung dokumentieren.
- Offene Ausnahmen mit Eigentümer, Schutzmaßnahme und festem Endtermin versehen.
Tokenentzug und Kennwortwechsel lösen unterschiedliche Probleme
Das Ändern eines Kennworts beendet nicht zwangsläufig jede bestehende Sitzung sofort. Umgekehrt entfernt der Sitzungswiderruf keine App-Berechtigung oder Rolle. Kontosperre, Sitzungsentzug, Methodenbereinigung, Rollenentzug, App-Credential-Wechsel und Geheimnisrotation werden deshalb entsprechend dem jeweiligen Zugriffspfad kombiniert und danach praktisch getestet.
9. Die Abnahme vergleicht Soll, Bestand, Nutzung und wirksamen Entzug
Die Berechtigungsprüfung ist abgeschlossen, wenn jeder verbleibende Zugriff erforderlich, begrenzt, geschützt und terminiert ist und jeder entfernte Zugriff nachweislich nicht mehr funktioniert.
| Prüfobjekt | Abnahmekriterium | Nachweis |
|---|---|---|
| Partnerbeziehungen | Nur aktuelle Partnerrollen mit notwendigem Umfang und Laufzeit | Export oder dokumentierte Admin-Center-Ansicht |
| Direkte Rollen | Jede externe Person und Gruppe besitzt nur bestätigte Rolle und Geltungsbereich. | Rollenzuweisung samt Gruppenauflösung |
| Konten | Persönliche Zuordnung, starke MFA, verwalteter Status und Lebenszyklus | Kontenregister und Anmeldeprüfung |
| Anwendungen | Eigentümer, Zweck, Berechtigungen und Credentials aktuell; ungenutzte Zugriffe entfernt | App-Inventar und Test |
| Azure | Externe Rollen separat bestätigt oder entzogen | RBAC-Export je relevantem Scope |
| Protokolle | Aktivität passt zu Auftrag; Abweichungen sind untersucht. | Zeitlich eingegrenzte Anmelde- und Auditdaten |
| Entzug | Frühere Konten, Partnerrollen und Credentials werden abgewiesen. | Negativtest und Nachher-Bestand |
| Betriebsfähigkeit | Interne Verantwortliche können alle kritischen Verwaltungsaufgaben ausführen. | Funktions- und Notfalltest |
Quartalscheck für den Regelbetrieb
- Partnerorganisationen, Rollen und Ablaufdaten gegen laufende Aufträge prüfen.
- Neue und geänderte privilegierte Rollenzuweisungen nachvollziehen.
- Externe Benutzer, Gäste und Mitglieder rollenberechtigter Gruppen bestätigen.
- Unternehmensanwendungen mit neuen Berechtigungen, Credentials oder Eigentümern prüfen.
- Inaktive Administratoren nicht automatisch löschen, sondern Bedarf und Protokollzeitraum klären.
- Ungewöhnliche Anmeldungen und administrative Aktivitäten untersuchen.
- Azure-Rollen und externe Systeme außerhalb des Mandanten einbeziehen.
- Ausnahmen, Projektzugänge und Übergangsrechte bis zu ihrem Enddatum schließen.
- Interne Notfallzugänge testen und Nutzung alarmieren.
- Zugriffsregister mit Prüfer, Datum, Entscheidung und nächstem Termin abschließen.
Häufige Fragen zu externen Microsoft-365-Administratoren
Kann ein Lizenzhändler ohne Administratorrolle weiter Lizenzen liefern?
Ja. Microsoft unterscheidet die Händler- oder Resellerbeziehung von delegierten Administratorrollen. Das Entfernen der Rollen kann die Lizenzbeziehung bestehen lassen. Vertrag, Abrechnung und mögliche Bestellbefugnisse werden dennoch gesondert geprüft.
Ist GDAP automatisch nach dem Least-Privilege-Prinzip konfiguriert?
GDAP ermöglicht granulare und zeitlich begrenzte Rollen, wählt sie aber nicht automatisch passend zum Auftrag. Auch eine GDAP-Beziehung kann mehrere weitreichende Rollen enthalten. Jede angeforderte Rolle und ihre Dauer werden deshalb fachlich begründet.
Reicht es, alle Gastbenutzer zu löschen?
Nein. Externe Personen können Mitgliedskonten besitzen, Partnerrechte nutzen oder über Anwendungen zugreifen. Umgekehrt können Gäste weiterhin berechtigte Projektteilnehmer sein. Entscheidend sind Identität, Rechte, Geschäftsgrund und Lebenszyklus, nicht allein der Wert „Gast“.
Warum erscheint ein Dienstleister nicht in den Benutzer-Anmeldeprotokollen?
Er kann über eine Partnerbeziehung, eine nicht interaktive Sitzung oder einen Service Principal handeln. Außerdem kann der betrachtete Zeitraum zu kurz sein. Benutzer-, Service-Principal-, Audit-, Microsoft-365- und Azure-Protokolle werden passend zum Zugriffspfad ausgewertet.
Wann wird ein externer Zugriff sofort gesperrt?
Bei konkretem Missbrauchsverdacht, ungeklärter hochprivilegierter Anmeldung, kompromittiertem Konto oder unberechtigter Berechtigungsänderung steht die Eindämmung vor dem geordneten Übergang. Beweise werden gesichert, Sitzungen und Zugriffspfade gezielt entzogen und Auswirkungen anschließend untersucht.
Weiterführende technische Grundlagen
Externe Microsoft-365-Zugänge vollständig prüfen
fra.digital unterstützt kleine Unternehmen in Frankfurt bei Inventur, Rollenbewertung, Partnerbeziehungen, App-Berechtigungen, kontrolliertem Entzug und der technischen Abnahme ihrer Microsoft-365-Administration.
