Microsoft 365 · Sichere Administration
Ein Microsoft-365-Administratorkonto kann Identitäten, E-Mail, Dateien und Sicherheitsregeln des gesamten Unternehmens verändern. Es gehört deshalb weder in den täglichen Posteingang noch in ein gemeinsam benutztes Kennwort. Kleine Unternehmen benötigen persönliche Administratorkonten mit begrenzten Rollen, phishingresistente Anmeldung für privilegierte Aufgaben und mindestens zwei unabhängig funktionierende Notfallzugänge.
Die Kurzantwort: Persönlich administrieren, Rechte begrenzen, unabhängigen Notfallzugang erhalten
Für jede regelmäßig administrierende Person gibt es ein normales Arbeitskonto und ein separates Administratorkonto. Das Arbeitskonto nutzt E-Mail, Teams und Web. Das Administratorkonto erhält nur die benötigten Rollen, eine starke Anmeldemethode und möglichst keinen produktiven Posteingang. Zwei cloudbasierte Notfallkonten bleiben von normalen Identitätsabhängigkeiten getrennt und werden regelmäßig getestet.
| Kontotyp | Zweck | Wesentliche Grenze |
|---|---|---|
| Normales Arbeitskonto | E-Mail, Teams, Dateien, Browser und tägliche Facharbeit. | Keine dauerhafte globale Administration. |
| Persönliches Administratorkonto | Nachvollziehbare administrative Aufgaben in zugewiesenen Rollen. | Keine Alltagskommunikation und möglichst kein allgemeines Surfen. |
| Notfallkonto | Zugang bei Ausfall regulärer Anmeldung, Richtlinienfehlern oder Verlust anderer Adminzugänge. | Nur für Test und tatsächlichen Notfall; jede Nutzung wird alarmiert und ausgewertet. |
| Workload-Identität | Automatisierung, Anwendung oder technische Integration. | Kein menschliches Sammelkonto; Berechtigungen und Geheimnisse folgen eigenem Lebenszyklus. |
Diese Trennung löst zwei gegensätzliche Risiken. Wird das tägliche Konto durch Phishing, Schadsoftware oder eine bösartige Browsererweiterung kompromittiert, besitzt es nicht automatisch die stärksten Mandantenrechte. Verliert ein Administrator sein Arbeitskonto oder blockiert eine fehlerhafte Richtlinie die normale Anmeldung, bleibt ein kontrollierter Wiederherstellungsweg bestehen.
„Wir haben nur fünf Beschäftigte“ verkleinert die technische Wirkung eines globalen Administrators nicht. Das Konto kann Domains, andere Administratoren, bedingten Zugriff, App-Berechtigungen und zentrale Dienste beeinflussen. Die Architektur wird deshalb nach Schadenspotenzial und Wiederherstellbarkeit entworfen, nicht nach Mitarbeiterzahl.
1. Arbeitskonto und Administratorkonto werden konsequent getrennt
Das separate Administratorkonto ist keine kosmetische zweite Adresse. Es reduziert die Zahl riskanter Situationen, in denen ein hoch privilegiertes Konto E-Mails öffnet, Links folgt, Dokumente bearbeitet oder Browserdienste verwendet.
Das Arbeitskonto bleibt der sichtbare Benutzer im Unternehmen
Mit dem Arbeitskonto kommuniziert die Person, nimmt an Besprechungen teil und bearbeitet Dateien. Es trägt die fachlichen Gruppen- und Teammitgliedschaften. Für gelegentliche Benutzerverwaltung erhält es keine globale Rolle „aus Bequemlichkeit“. So führt ein gestohlenes Sitzungscookie aus dem Alltag nicht unmittelbar zur vollständigen Kontrolle über den Mandanten.
Der Name des getrennten Administratorkontos bleibt einer konkreten Person zugeordnet. Ein gemeinsames Konto wie admin@ mit geteiltem Kennwort verhindert die sichere Zuordnung von Änderungen, erschwert MFA und bleibt nach Personalwechseln oft unkontrolliert bestehen. Persönliche Konten können einzeln gesperrt, geprüft und ersetzt werden.
Das Administratorkonto wird nur für administrative Sitzungen verwendet
Das privilegierte Konto meldet sich an Microsoft-365-, Entra-, Exchange-, SharePoint-, Teams-, Intune- oder Defender-Verwaltung an, wenn eine konkrete Aufgabe ansteht. Es erhält nach Möglichkeit keine Office-Lizenz, keinen normalen Posteingang und keine operativen Gruppenmitgliedschaften. Benachrichtigungen gehen an das überwachte Arbeitskonto oder ein dafür vorgesehenes Funktionspostfach.
Browserprofile werden getrennt. Ein sichtbar benanntes Verwaltungsprofil verhindert, dass der Administrator versehentlich mit dem privilegierten Konto gewöhnliche Webseiten öffnet oder eine Aufgabe mit dem falschen Benutzer ausführt. Für stärkere Anforderungen dient ein verwaltetes, gehärtetes Administrationsgerät beziehungsweise eine Privileged Access Workstation.
Technische Automatisierungen erhalten keine geteilten Benutzerkonten
Ein Skript, Backupdienst oder Connector sollte nicht mit dem Kennwort eines Mitarbeiters dauerhaft Globaler Administrator sein. Wo Microsoft Graph oder eine andere Schnittstelle verwendet wird, erhält die Anwendung eine eigene Identität und die kleinsten erforderlichen Anwendungsberechtigungen. Zertifikate oder verwaltete Identitäten sind langlebigen Klartextgeheimnissen vorzuziehen, soweit der Dienst sie unterstützt.
Auch eine Workload-Identität braucht Eigentümer, Zweck, Ablaufdatum, Berechtigungsprüfung und einen Notfallplan. Sie wird nicht interaktiv für menschliche Administration benutzt. Verlässt der technische Verantwortliche das Unternehmen, bleibt die Anwendung bestehen, ihre Betreuung muss aber ausdrücklich übertragen werden.
Kontotrennung, die im Alltag funktioniert
- Persönliche, eindeutig benannte Administratorkonten statt gemeinsamem admin@-Login
- Keine produktive E-Mail und keine gewöhnlichen Teams- oder SharePoint-Mitgliedschaften
- Eigenes Browserprofil und definierter, verwalteter Administrationsarbeitsplatz
- Starke, nur für dieses Konto registrierte Authentifizierungsmethoden
- Benachrichtigungen an überwachte Arbeits- oder Sicherheitsadressen
- Eigene Identitäten für Anwendungen, Skripte und Integrationen
- Dokumentierter Eigentümer und Stellvertretung für jedes privilegierte Konto
2. Jede administrative Aufgabe erhält die kleinste passende Rolle
Microsoft 365 und Microsoft Entra unterscheiden zahlreiche Rollen. Wer Postfächer verwaltet, benötigt nicht automatisch das Recht, bedingten Zugriff oder Unternehmensanwendungen zu ändern. Diese Trennung begrenzt Fehler und Missbrauch.
Globaler Administrator bleibt der Ausnahmefall
Die globale Rolle kann nahezu alle Einstellungen und viele Datenzugänge des Mandanten beeinflussen. Sie wird nur den Personen beziehungsweise Notfallkonten zugewiesen, die diesen vollständigen Wiederherstellungs- und Steuerungsumfang wirklich benötigen. Tagesaufgaben wie Benutzer anlegen, Kennwörter zurücksetzen oder SharePoint-Sites verwalten erhalten passendere Rollen.
Microsoft empfiehlt möglichst wenige globale Administratoren und zusätzlich einen handlungsfähigen Weg, falls einer ausgesperrt wird. Eine große Zahl globaler Administratoren erhöht die Angriffsfläche; ein einziges persönliches Konto schafft dagegen einen betrieblichen Ausfallpunkt. Begrenzung und Redundanz müssen gleichzeitig erfüllt sein.
Rollen folgen Aufgaben und Verantwortungsgrenzen
Ein Helpdesk- oder Kennwortadministrator kann bestimmte Benutzerprobleme lösen, ohne Domains und Sicherheitsrichtlinien zu verwalten. Exchange-, SharePoint- und Teams-Administratoren bearbeiten ihre jeweiligen Dienste. Ein Globaler Leser kann viele Einstellungen prüfen, ohne sie zu verändern. Welche Rolle tatsächlich genügt, wird anhand der konkreten Administrationsaufgabe und der aktuellen Microsoft-Rollenbeschreibung entschieden.
Manche Aufgaben benötigen mehrere Rollen oder ausnahmsweise höhere Berechtigungen. Diese werden nicht dauerhaft vorsorglich vergeben. Der Administrator dokumentiert Anlass und Endzeitpunkt. Microsoft Entra Privileged Identity Management kann lizenzabhängig eine Rolle als „berechtigt“ statt dauerhaft aktiv zuweisen; sie wird dann für eine begrenzte Dauer, gegebenenfalls mit MFA, Begründung und Freigabe aktiviert.
Administrative Rechte werden regelmäßig aus beiden Richtungen geprüft
Die Benutzeransicht zeigt, welche Rollen ein Administratorkonto besitzt. Die Rollenansicht zeigt, wer eine bestimmte Berechtigung besitzt. Beide Perspektiven werden benötigt, weil Gruppen, PIM-Zuweisungen, administrative Einheiten und direkte Rollen unterschiedliche Pfade bilden können. Zusätzlich werden Eigentümer von Anwendungen und privilegierten Gruppen kontrolliert.
Die Prüfung beantwortet nicht nur „Ist diese Person noch beschäftigt?“, sondern „Benötigt sie diese Rolle für eine aktuelle Aufgabe?“. Ein externer Dienstleister kann fachlich weiterhin beauftragt sein und trotzdem keinen dauerhaften Global-Admin-Zugang benötigen. Rechte werden zeitlich und inhaltlich am Auftrag ausgerichtet.
Praktische Rollenmatrix für kleine Umgebungen
| Aufgabe | Ausgangspunkt | Nicht automatisch erforderlich |
|---|---|---|
| Benutzer und Lizenzen verwalten | Benutzeradministrator beziehungsweise passende eingeschränkte Rolle. | Globaler Administrator. |
| Postfächer und Mailfluss betreuen | Exchange-Administrator. | SharePoint- oder Conditional-Access-Rechte. |
| Sites und Freigabeeinstellungen betreuen | SharePoint-Administrator. | Vollständige Identitätsverwaltung. |
| Sicherheitslage nur einsehen | Security Reader oder Global Reader, abhängig vom benötigten Portal. | Schreibende Sicherheitsrolle. |
| Rollen und Notfallzugang steuern | Privileged Role Administrator beziehungsweise Globaler Administrator im erforderlichen Umfang. | Dauerhafte Nutzung für Tagesaufgaben. |
Die Tabelle ist eine Planungsorientierung. Rollen und enthaltene Berechtigungen ändern sich; vor der Zuweisung wird die aktuelle Microsoft-Dokumentation für die konkrete Aufgabe geprüft.
3. Privilegierte Anmeldung muss Phishing und Sitzungsdiebstahl widerstehen
MFA verbessert die Sicherheit erheblich, doch nicht jede Methode schützt gleich gut gegen eine täuschend echte Anmeldeseite. Für Administratoren empfiehlt Microsoft phishingresistente Verfahren wie Passkeys nach FIDO2, FIDO2-Sicherheitsschlüssel, Windows Hello for Business oder zertifikatbasierte Authentifizierung.
Phishingresistente Verfahren binden die Anmeldung an den echten Dienst
Ein Angreifer kann Kennwort und Einmalcode auf einer gefälschten Seite abfragen und in Echtzeit weiterreichen. FIDO2-basierte Verfahren prüfen kryptografisch die Herkunft der Anmeldeanforderung und geben die Anmeldeinformation nicht an eine falsche Domain heraus. Das reduziert klassische Adversary-in-the-Middle-Angriffe deutlich.
Die Einführung beginnt mit Registrierung und Wiederherstellung. Mindestens zwei geeignete Methoden beziehungsweise Geräte verhindern, dass ein verlorener Schlüssel den Administrator aussperrt. Ersatzschlüssel werden geschützt gelagert und eindeutig zugeordnet. SMS bleibt für privilegierte Konten keine Zielarchitektur, auch wenn sie vorübergehend besser als eine reine Kennwortanmeldung sein kann.
Conditional Access wird zuerst beobachtet und dann kontrolliert erzwungen
Eine Richtlinie kann für administrative Rollen eine phishingresistente Authentifizierungsstärke verlangen. Bevor sie aktiv blockiert, müssen alle betroffenen Administratoren geeignete Methoden registriert haben. Microsoft empfiehlt, die Auswirkung zunächst im reinen Berichtsmodus zu prüfen. Anmeldeprotokolle zeigen, welche Benutzer- und Gerätekombinationen sonst gesperrt worden wären.
Richtlinien werden mit einem Pilotkonto und einem dokumentierten Rückweg eingerichtet. Eine pauschale Aktivierung ohne Test kann den Mandanten unzugänglich machen. Notfallkonten werden von Richtlinien ausgeschlossen, die ihre Anmeldung blockieren oder von gerade ausgefallenen Bedingungen abhängig machen könnten. Ihre starke Authentifizierung und Überwachung werden unabhängig davon sichergestellt.
Der benutzte Arbeitsplatz ist Teil der Sicherheitsgrenze
Ein starker Sicherheitsschlüssel schützt nicht vor jeder Schadsoftware auf einem kompromittierten Rechner. Administration erfolgt deshalb auf einem gepflegten, verschlüsselten und überwachten Gerät mit aktuellem Browser. Erweiterungen und lokale Administratorrechte werden begrenzt. Private oder fremde Computer sind keine geeigneten Verwaltungsarbeitsplätze.
Für kleine Unternehmen kann ein eigenes verwaltetes Benutzerprofil oder ein dediziertes Administrationsnotebook eine pragmatische Stufe sein. Höhere Schutzanforderungen verlangen ein konsequenter isoliertes Gerät. Entscheidend ist, dass das privilegierte Konto nicht denselben E-Mail-, Download- und Browsingrisiken wie der Alltagsarbeitsplatz ausgesetzt wird.
Abnahmetests für die Administratoranmeldung
- Jedes persönliche Administratorkonto besitzt mindestens eine freigegebene starke Methode und einen geregelten Ersatzweg.
- Die Methode funktioniert in allen tatsächlich benötigten Verwaltungsportalen.
- Report-only-Auswertung zeigt keine unerwartet ausgeschlossenen Administratoren.
- Aktive Richtlinien erzwingen die geplante Authentifizierungsstärke für privilegierte Rollen.
- Notfallkonten bleiben von blockierenden Abhängigkeiten ausgenommen.
- Ein nicht zugelassenes Verfahren oder ungeeigneter Testzugang wird erwartungsgemäß abgelehnt.
- Anmelde- und Auditprotokolle sind für die verantwortliche Person erreichbar.
4. Notfallkonten sichern die Erreichbarkeit des Mandanten
Notfallzugänge sind für Situationen gedacht, in denen reguläre Administratorkonten nicht funktionieren: fehlerhafter bedingter Zugriff, Ausfall einer Authentifizierungskomponente, Verlust mehrerer Zugangsmittel oder eine Störung verbundener Identitätssysteme.
Mindestens zwei cloudbasierte Konten vermeiden gemeinsame Ausfallursachen
Microsoft empfiehlt zwei oder mehr Notfallkonten. Sie werden direkt im Cloudmandanten unter der onmicrosoft.com-Domain angelegt und nicht aus einem lokalen Verzeichnis synchronisiert oder über einen externen Identitätsanbieter föderiert. Damit bleibt ihre Anmeldung möglich, wenn genau diese vorgelagerten Systeme ausfallen.
Die Konten erhalten die für eine Wiederherstellung erforderliche globale Rolle dauerhaft aktiv. Das ist eine bewusst eng begrenzte Ausnahme von zeitlich aktivierten Rollen. Die Konten sind keiner einzelnen Person als Alltagsidentität zugeordnet, besitzen keine normale Mailbox und werden niemals für Routineadministration verwendet.
Die Authentifizierung bleibt stark und unabhängig
Aktuelle Microsoft-Leitlinien sehen phishingresistente Anmeldung für Notfallkonten vor, bevorzugt Passkeys beziehungsweise FIDO2-Sicherheitsschlüssel oder bei vorhandener Infrastruktur zertifikatbasierte Authentifizierung. Die Methode unterscheidet sich nach Möglichkeit von der normalen Adminanmeldung. Ein Ausfall der Authenticator-App oder der Mobilfunknummer darf nicht beide Wege gleichzeitig beseitigen.
Schlüssel und Zugangsinformationen werden getrennt an sicheren Orten gelagert, auf die mehrere ausdrücklich autorisierte Personen zugreifen können. Die Lagerung berücksichtigt Feuer, Diebstahl und organisatorische Abwesenheit. Ablaufende Zertifikate, Batterien, automatisches Kontocleanup oder unbekannte PINs dürfen den vermeintlichen Notfallweg nicht unbrauchbar machen.
Jede Anmeldung löst eine Meldung und Nachprüfung aus
Notfallkonten sollten im normalen Betrieb keine Aktivität zeigen. Anmeldungen und relevante Auditereignisse werden deshalb überwacht; jede Nutzung erzeugt eine Benachrichtigung an andere Verantwortliche. Nach einem Test wird bestätigt, dass Anlass, Zeitpunkt und Handlung vorgesehen waren. Nach einem echten Notfall folgt eine Auswertung der vorgenommenen Änderungen.
Microsoft empfiehlt regelmäßige Funktionsprüfungen, mindestens etwa alle 90 Tage. Der Test umfasst nicht nur die Anmeldung, sondern eine harmlose administrative Abfrage und anschließend die Kontrolle, ob Alarm und Protokollierung ausgelöst wurden. Er wird auf einem vorgesehenen sicheren Gerät durchgeführt.
Notfallkonto: Mindestanforderungen
- Redundanz
- Mindestens zwei voneinander unabhängige Notfallkonten und getrennte Zugangsmittel.
- Identität
- Cloud-only unter onmicrosoft.com, ohne Abhängigkeit von Synchronisierung oder Föderation.
- Authentifizierung
- Phishingresistentes Verfahren mit sicher gelagertem Ersatz und ohne normale Privatgeräte.
- Richtlinien
- Ausnahme von blockierenden Conditional-Access-Abhängigkeiten, dokumentiert und regelmäßig geprüft.
- Nutzung
- Nur Test oder tatsächlicher Notfall; keine E-Mail, keine Tagesadministration.
- Überwachung
- Alarm bei jeder Anmeldung, anschließende Prüfung der Auditereignisse.
- Test
- Mindestens vierteljährlich mit dokumentiertem Ergebnis und bestätigter Alarmierung.
5. Der laufende Betrieb hält Rechte, Zugänge und Wiederherstellung aktuell
Eine sichere Ersteinrichtung verfällt, wenn Personal wechselt, neue Dienste hinzukommen oder Richtlinien geändert werden. Privilegierte Identitäten erhalten deshalb einen überschaubaren Betriebsrhythmus.
Änderungen werden mit Ausgangslage und Rückweg dokumentiert
Vor einer Änderung an Domains, Authentifizierung, Conditional Access oder Administratorrollen wird der aktuelle Zustand exportiert beziehungsweise dokumentiert. Der Auftrag nennt Ziel, betroffene Konten, Test, Rückrollmöglichkeit und verantwortliche Person. Änderungen an der eigenen Rettungsmöglichkeit werden nie ohne zweiten arbeitsfähigen Administrator durchgeführt.
Für kritische Richtlinien wird der Berichtsmodus genutzt, wenn die Funktion ihn anbietet. Danach folgt ein begrenzter Pilot, erst dann die allgemeine Durchsetzung. Diese Reihenfolge ist kein unnötiger Prozessaufwand: Sie verhindert, dass eine syntaktisch gültige, fachlich aber falsche Einstellung alle Administratoren aussperrt.
Personalwechsel lösen eine sofortige Rechteprüfung aus
Scheidet ein interner Administrator oder externer Dienstleister aus, werden persönliche privilegierte Konten gesperrt, Sitzungen widerrufen, Rollen entfernt und verwaltete Geräte beziehungsweise Schlüssel zurückgenommen. Anwendungseigentum, PIM-Berechtigungen, Partnerbeziehungen und gespeicherte Geheimnisse werden ausdrücklich übertragen.
Ein gemeinsam bekanntes Notfallgeheimnis wird nach personeller Änderung neu abgesichert. Persönliche FIDO2-Schlüssel werden aus dem Konto entfernt. Der verbleibende Administrator testet anschließend, dass reguläre und Notfallwege weiterhin funktionieren. Ausführlicher behandelt der vorherige Beitrag den gesamten Microsoft-365-Offboarding-Prozess.
Die regelmäßige Prüfung verbindet Rollen, Methoden und Protokolle
Vierteljährlich werden globale und weitere privilegierte Rollen, Notfallkonten, Authentifizierungsmethoden, Conditional-Access-Ausnahmen sowie Partnerzugänge kontrolliert. Sign-in- und Auditprotokolle zeigen verdächtige oder unerwartete Nutzung. Konten ohne bestätigten Eigentümer werden nicht kommentarlos belassen.
Lizenzabhängige Funktionen wie PIM, Access Reviews, risikobasierte Richtlinien oder erweiterte Protokollierung werden nur eingeplant, wenn die vorhandenen Abonnements sie tatsächlich abdecken. Das Basismodell aus getrennten Konten, kleinen Rollen, starker MFA, zwei Notfallzugängen und dokumentierter Prüfung bleibt auch in einer kleinen Lizenzumgebung der tragfähige Ausgangspunkt.
Abnahmekriterien für sichere Microsoft-365-Administration
- Alltags- und Administratorkonten sind personengebunden und funktional getrennt.
- Kein geteilter interaktiver Administratorzugang bleibt im Einsatz.
- Jedes Administratorkonto besitzt nur die bestätigten Rollen.
- Privilegierte Anmeldung nutzt die vorgesehene phishingresistente Methode.
- Conditional Access wurde beobachtet, getestet und mit dokumentiertem Rückweg aktiviert.
- Mindestens zwei unabhängige cloudbasierte Notfallkonten funktionieren.
- Jede Notfallanmeldung erzeugt eine überwachte Meldung.
- Anwendungen und Automatisierungen nutzen eigene, begrenzte Identitäten.
- Rollen, Methoden, Eigentümer und Notfallzugang haben einen wiederkehrenden Prüftermin.
Häufige Fragen zu Microsoft-365-Administratorkonten
Warum braucht ein kleines Unternehmen separate Administratorkonten?
Weil die Wirkung der Rolle unverändert groß bleibt. Ein kompromittiertes Alltagskonto mit globalen Rechten kann den gesamten Mandanten verändern. Ein separates Konto reduziert Kontakt mit E-Mail, Downloads und gewöhnlichem Webzugriff und macht Verwaltungsaktionen besser nachvollziehbar.
Wie viele globale Administratoren sind sinnvoll?
So wenige wie für Regelbetrieb und Wiederherstellung erforderlich. Persönliche globale Rollen werden auf den tatsächlichen Bedarf begrenzt; zusätzlich bestehen mindestens zwei kontrollierte Notfallkonten. Ein einziges persönliches Konto wäre ein Ausfallpunkt, eine große Zahl erhöht die Angriffsfläche.
Reicht Microsoft Authenticator als MFA für Administratoren?
Authenticator verbessert die Sicherheit gegenüber Kennwort allein erheblich. Für privilegierte Rollen empfiehlt Microsoft jedoch phishingresistente Verfahren wie FIDO2-Passkeys beziehungsweise Sicherheitsschlüssel, Windows Hello for Business oder zertifikatbasierte Authentifizierung. Die konkrete Methode muss zu Geräten und Wiederherstellung passen.
Soll ein Notfallkonto von MFA ausgenommen werden?
Aktuelle Microsoft-Leitlinien sehen starke phishingresistente Authentifizierung auch für Notfallkonten vor. Ausgenommen werden sie von Conditional-Access-Richtlinien, die den Zugang im Störungsfall blockieren könnten. Die Authentifizierung muss unabhängig von normalen Adminmethoden und externen Systemen funktionieren.
Kann ein IT-Dienstleister einen gemeinsamen Global-Admin-Zugang verwenden?
Ein geteilter interaktiver Zugang schwächt Nachvollziehbarkeit und kontrolliertes Offboarding. Besser sind personengebundene Konten beziehungsweise eine geeignete delegierte Partnerverwaltung mit begrenztem Umfang und Laufzeit. Der Auftrag bestimmt, welche Rollen wirklich erforderlich sind.
Wie oft werden Notfallkonten getestet?
Microsoft empfiehlt regelmäßige Prüfungen, mindestens etwa alle 90 Tage. Dabei werden Anmeldung, eine harmlose administrative Funktion, Alarmierung und Protokollierung bestätigt. Zugangsmittel und autorisierte Personen werden ebenfalls kontrolliert.
Quellen und fachliche Grundlage
- Microsoft Learn: Administratorkonten in Microsoft 365 for Business schützen
- Microsoft Learn: Administratorrollen im Microsoft 365 Admin Center
- Microsoft Learn: Notfallzugangskonten in Microsoft Entra verwalten
- Microsoft Learn: Phishingresistente MFA für Administratorrollen verlangen
- Microsoft Learn: Authentifizierungsstärken in Conditional Access
- Microsoft Learn: Privileged Identity Management
- Microsoft Learn: Privilegierter Zugriff und sichere Administrationsarbeitsplätze
- Microsoft Learn: Microsoft 365 vor lokalen Identitätsangriffen schützen
Rollen, Authentifizierungsmethoden, Microsoft-verwaltete Richtlinien und Lizenzvoraussetzungen können sich ändern. Vor der Umsetzung werden die aktuelle Microsoft-Dokumentation, vorhandene Lizenzen, bestehende Identitätsabhängigkeiten und der tatsächliche Wiederherstellungsweg des Mandanten geprüft.
Sichere Microsoft-365-Administration für kleine Unternehmen in Frankfurt
Administratorkonten und Notfallzugang belastbar einrichten
fra.digital prüft Rollen und Zugangswege, trennt persönliche Administratorkonten vom Arbeitsalltag, richtet starke Anmeldemethoden und unabhängige Notfallkonten ein und dokumentiert die Abnahme als klar begrenztes Sicherheitsprojekt.
