Service Accounts in Microsoft 365 absichern: Vom Inventar bis zum Monitoring
MFA, Conditional Access und PIM stehen im Fokus jeder Identity-Diskussion. Für User-Accounts. Service Accounts laufen daneben mit, oft seit Jahren ungeprüft, mit erhöhten Rechten und ohne Monitoring. Nach einem initialen Compromise sind sie die häufigste Tür für laterale Bewegung. Dieser Artikel zeigt die 4-Schritt-Methodik zur systematischen Absicherung.
Warum Service Accounts ein Blind Spot sind
Ein typischer M365-Tenant hat 5 bis 25 Service Accounts: für Backup-Tools, für Migrations-Software, für Drucker-Anbindungen, für legacy Anwendungen, für SSO-Konnektoren. Manche wurden vor 5 Jahren angelegt, dokumentiert hat sie damals niemand richtig, und jetzt traut sich keiner, sie anzufassen. "Wenn wir das ändern, geht der Drucker nicht mehr." Klassischer Satz.
Das Problem: Diese Accounts haben oft erhöhte Rechte. Global Admin, weil "der Backup-Provider braucht das". Application Administrator, weil "die Migration-Tools haben das so verlangt". MFA ist nicht aktiv, weil "Service Accounts können kein MFA". Das Passwort wurde seit 6 Jahren nicht geändert.
In dieser Konstellation ist ein Service Account nach einem initialen Compromise eines User-Accounts die effektivste Eskalationsstufe für einen Angreifer. Privilegien, kein MFA, keine Anomalie-Erkennung, wenig Logging. Die saubere Methodik ist nicht "ein bisschen MFA hinzufügen", sondern die systematische Inventarisierung, Klassifizierung, Härtung und Überwachung.
Vollständige Inventarisierung
Im Entra Admin Center lassen sich Service Accounts nicht direkt filtern, weil sie technisch normale User-Accounts sind. Ein erster Filter: alle Accounts mit "Last sign-in > 90 Tage" anzeigen. Daneben: alle Accounts mit privilegierten Rollen (Global Admin, Application Administrator, Privileged Role Administrator).
Die Schnittmenge dieser beiden Listen plus alle Accounts mit Service-typischen Naming-Konventionen (svc_*, sa_*, system_*) ergibt die initiale Inventory-Liste. PowerShell-Script mit Get-MgUser und Filter auf accountEnabled=true plus passwordPolicies extrahiert die Liste maschinell.
Aktion: Inventory-Liste über PowerShell extrahieren, in Tenant-Dokumentations-Register importieren, mit IT-Abteilung und Anwendungs-Verantwortlichen die Liste auf Vollständigkeit prüfen.
Klassifizierung pro Account
Jeder identifizierte Account wird in vier Kategorien klassifiziert: aktiv und benötigt, aktiv und überflüssig, inaktiv und löschbar, unklar (zur weiteren Analyse). Pro aktivem Account werden Owner (Person, die das Account-Lifecycle verantwortet), Funktion (was technisch macht der Account) und Berechtigungen dokumentiert.
Das Owner-Feld ist nicht trivial. Bei Accounts, die vor Jahren angelegt wurden, ist der ursprüngliche Owner oft im Unternehmen nicht mehr. Für jeden orphan Account wird ein neuer Owner benannt, typisch jemand aus der Abteilung, die das Tool nutzt. Ohne Owner gibt es keine Verantwortung für den Account-Lifecycle.
Aktion: Klassifizierung pro Account in Excel oder Sharepoint-Liste, Owner-Feld zwingend füllen, Re-Klassifizierung quartalsweise im Tenant-Review.
Modern Auth statt Passwort-Authentifizierung
Service Accounts können kein klassisches MFA, das stimmt. Aber sie können moderne Authentifizierungsmechanismen, die deutlich stärker sind als Passwort plus IP-Restriction. Die drei Optionen: Certificate-based Authentication, Managed Identities und Workload Identity Federation.
Certificate-based Auth ersetzt das Passwort durch ein Zertifikat, das nur auf dem berechtigten System verwendet werden kann. Managed Identities (für Azure-native Integrationen) machen Passwörter komplett überflüssig, das Token wird vom Azure-AD direkt an den autorisierten Service ausgestellt. Workload Identity Federation eignet sich für Service Accounts, die von externen Plattformen wie GitHub Actions oder GitLab Runners aufgerufen werden.
Wo modernen Auth nicht möglich ist (legacy Anwendungen ohne API-Anpassung), bleibt nur Conditional Access mit IP-Restriction. Dann wird der Account auf eine eng definierte IP-Range eingeschränkt, typischerweise die statische IP des betreibenden Servers.
Aktion: Pro aktivem Service Account die Auth-Methode entscheiden, Certificate-based Auth als Standard, Managed Identities wo möglich, IP-Restriction als Fallback. Migration in 4-Wochen-Sprints.
Monitoring und Anomalie-Erkennung
Service Accounts haben deterministische Anmeldemuster: der Backup-Provider meldet sich um 02:00 Uhr von der gleichen IP an, das Migrations-Tool nur während aktiver Migrations-Phasen, der Drucker-Service stündlich. Anomalien sind in dieser Welt einfach zu definieren.
Mit Microsoft Sentinel oder Defender for Cloud Apps lassen sich Alert-Regeln pro Service Account konfigurieren: Anmeldung außerhalb erwarteter Zeitfenster, Anmeldung von unerwarteter IP, Berechtigungs-Änderung am Account, Passwort-Änderung. Diese Alerts gehen direkt an die SOC-Triage.
Wichtig: Alert-Schwellen sollten initial großzügig konfiguriert werden, sonst entstehen Alert-Storms während legitimer Wartungs-Phasen. Nach 4 Wochen Tuning sind die Schwellen auf das echte Anomalie-Niveau eingestellt.
Aktion: Pro aktivem Service Account ein Sentinel-Alert-Profil definieren, in den ersten 4 Wochen feinjustieren, danach in den produktiven SOC-Workflow übernehmen.
Faustregel: Ein Service Account ohne dokumentierten Owner ist ein Service Account, den niemand schützt. Bevor irgendeine technische Härtung beginnt, muss jeder Account einen Owner haben.
Die vier Schritte lassen sich in einem mittleren Tenant in 1 bis 2 Wochen umsetzen. Der größte Aufwand liegt nicht in der Konfiguration, sondern in der Klärung der Owner und Funktionen. In großen Tenants mit 50+ Service Accounts ist es entsprechend mehr. Aber die Investition ist eine der höchsten Risiko-Reduktionen pro Tag, die in einem M365-Tenant möglich sind.
Microsoft 365 Governance Blueprint
Wir bauen mit Ihnen einen vollständigen Identity-Lifecycle für User- und Service-Accounts: Inventory, Klassifizierung, Härtung, Monitoring, Quarterly Reviews. Audit-prüfbar dokumentiert.
Zum Governance Blueprint