„Sign in with Microsoft“ – so bequem es für Nutzer ist, so schnell wird es für Administratoren zum Albtraum. Im Laufe der Jahre sammeln sich in fast jedem Microsoft 365 Tenant unzählige „Enterprise Applications“ an. Oft wissen wir gar nicht mehr, woher sie kommen oder welche Berechtigungen sie eigentlich haben.
In diesem Artikel zeige ich dir, warum das freie Hinzufügen von Apps durch Nutzer (und sogar durch Admins im falschen Kontext) eine schlechte Idee ist und wie du die Kontrolle zurückgewinnst.
Das Problem: Der Klick im Vorbeigehen
Vielleicht kennst du das: Du testest ein neues KI-Tool oder ein Add-in, klickst schnell auf „Akzeptieren“, weil die angeforderten Berechtigungen harmlos aussehen, und vergisst die App fünf Minuten später wieder.
Selbst erfahrenen IT-Profis passiert das. Ein klassisches Szenario: Beim Audit fällt plötzlich ein Service Principal auf – nennen wir ihn beispielhaft „GuideAnts“ –, der vor kurzem hinzugefügt wurde. Niemand erinnert sich daran.
Eine schnelle Analyse des Unified Audit Logs (via PowerShell:Search-UnifiedAuditLog mit Operation „Add Service Principal“) bringt dann oft die ernüchternde Wahrheit ans Licht: Man war es selbst.
Das Protokoll zeigt gnadenlos:
- Actor: Dein Admin-Account
- Target: ServicePrincipal (z. B. GuideAnts)
- Zeitpunkt: Irgendwann spät abends
Ein Abgleich mit dem Browserverlauf bestätigt oft: Es war nur ein kurzer Login, ein schneller Test. Doch die App bleibt im Tenant und hat Zugriff.
Die drei Todsünden bei Enterprise Apps
An diesem Beispiel lassen sich drei grundlegende Sicherheitsfehler ableiten, die in vielen Umgebungen täglich passieren:
- Mangelnde Sorgfalt: Apps werden oft ohne tiefergehende Prüfung der Notwendigkeit hinzugefügt.
- Unverifizierte Herausgeber: Oft stammen diese Apps von „Unverified Publishers“. Das bedeutet, Microsoft hat die Identität des Herausgebers nicht validiert. Ein unnötiges Sicherheitsrisiko.
- Admin-Privilegien missbraucht: Wenn du solche Apps mit deinem Global Admin oder einem anderen hoch privilegierten Account hinzufügst, umgehst du oft Sicherheitsmechanismen, die für normale User (hoffentlich) gelten.
Die Lösung: Admin Consent Workflow statt Selbstbedienung
Der wichtigste Schritt, um Wildwuchs und Schatten-IT zu verhindern, ist die Deaktivierung der Option, dass Benutzer eigenständig Apps consenten (zustimmen) dürfen.
Warum? Wenn ein normaler User versucht, eine App hinzuzufügen, sollte er blockiert werden. Stattdessen greift der Admin Consent Workflow. Der User muss eine Begründung eingeben, und du als Administrator erhältst eine Anfrage (z. B. per Mail oder im Admin Center).
Das hat zwei entscheidende Vorteile:
- Vier-Augen-Prinzip: Selbst wenn du die Anfrage stellst, zwingt dich der Prozess kurz zum Nachdenken: „Brauche ich das wirklich?“ und „Ist diese Redirect-URL vertrauenswürdig?“.
- Zentrale Kontrolle: Du kannst prüfen, ob die App verifiziert ist und ob die angeforderten Berechtigungen (Scopes) verhältnismäßig sind.
Mehr Details zur Einrichtung findest du in unserem Artikel:
Einwilligung und Berechtigungen
Praxis: Analyse & Bereinigung mit PowerShell
Um Licht ins Dunkel zu bringen, helfen dir zwei konkrete Skripte. Voraussetzung ist, dass du die entsprechenden Module installiert hast.
1. Wer hat was hinzugefügt? (Audit Log)
Wenn du dich fragst, woher eine bestimmte App kommt, hilft ein Blick ins Unified Audit Log. Da die Suche im Compliance Center oft träge ist, geht es per PowerShell schneller.
Dieses Skript sucht nach dem Vorgang „Add service principal“ der letzten 90 Tage:
# Voraussetzung: ExchangeOnlineManagement Modul
Connect-ExchangeOnline
# Zeitraum definieren (z. B. letzte 90 Tage)
$StartDate = (Get-Date).AddDays(-90)
$EndDate = (Get-Date)
Write-Host "Durchsuche Audit Logs..." -ForegroundColor Cyan
# Suche nach dem Event "Add service principal"
$Events = Search-UnifiedAuditLog -StartDate $StartDate -EndDate $EndDate -Operations "Add service principal" -ResultSize 5000
# Ergebnis aufbereiten
$Results = $Events | Select-Object CreationTime, @{N='User';E={$_.UserIds}}, @{N='AppName';E={($_.AuditData | ConvertFrom-Json).Target[3].ID}}
# Ausgabe in GridView zur schnellen Filterung
$Results | Out-GridView -Title "Hinzugefügte Enterprise Apps (Letzte 90 Tage)"2. Bestandsaufnahme: Welche Apps habe ich überhaupt?
Einen schnellen Überblick über alle Drittanbieter-Apps in deinem Tenant (ohne die Microsoft-eigenen Dienste) bekommst du am besten über Microsoft Graph.
Hinweis: Achte besonders auf Einträge, bei denen PublisherName leer ist oder „Unverified“ enthält. Das sind die ersten Kandidaten für eine Prüfung oder Löschung.
# Voraussetzung: Microsoft.Graph Modul
Connect-MgGraph -Scopes "Application.Read.All"
Write-Host "Lade Service Principals..." -ForegroundColor Cyan
# Alle Service Principals abrufen
$AllApps = Get-MgServicePrincipal -All
# Filtern: Wir wollen keine Microsoft-First-Party Apps, sondern "echte" Enterprise Apps
# Hinweis: Das Filtern nach "nicht Microsoft" ist komplex, oft hilft der Check auf leere Tags oder Publisher.
# Hier ein Ansatz, um neuere Apps zu finden:
$RecentApps = $AllApps | Where-Object { $_.CreatedDateTime -gt (Get-Date).AddDays(-180) } | Select-Object DisplayName, AppId, PublisherName, CreatedDateTime, AccountEnabled
# Tabelle ausgeben, sortiert nach Datum (neueste zuerst)
$RecentApps | Sort-Object CreatedDateTime -Descending | Format-Table -AutoSizeFazit & Checkliste
Neben der Prävention ist die regelmäßige Hygiene im Tenant essenziell. Dank des verbesserten Microsoft Graph PowerShell SDK ist es mittlerweile deutlich einfacher, Berichte über alle Enterprise Apps, deren Nutzung und Berechtigungen zu ziehen.
Mein Tipp:
Verlasse dich nicht darauf, dass deine User (oder deine Kollegen) sicherheitsbewusst handeln.
[ ] Deaktiviere den User Consent für Apps.
[ ] Aktiviere den Admin Consent Workflow.
[ ] Prüfe regelmäßig via Script / Entra ID Portal, welche Service Principals neu sind und entferne Leichen.
Wir lernen alle aus Fehlern – am besten ist es aber, wenn das System uns davor bewahrt, sie überhaupt zu machen.
Microsoft Learn – Admin Consent Workflow: https://learn.microsoft.com/de-de/entra/identity/enterprise-apps/configure-admin-consent-workflow
Microsoft Graph PowerShell SDK: https://learn.microsoft.com/de-de/powershell/microsoftgraph/installation
PhinIT.DE Interner Artikel mit mehr Details:
UNTERNEHMENSANWENDUNGEN – Einwilligung und Berechtigungen
1 Trackback / Pingback