Eines der größten Einfallstore für Datenverlust ist nicht der Hacker, der ein Passwort knackt, sondern der gutgläubige Mitarbeiter, der einer App Zugriff auf seine Daten gewährt. "Diese App möchte Ihre Kontakte lesen und E-Mails senden". Ein schneller Klick auf "Akzeptieren", und die Daten fließen ab.
Beim OAuth-Consent-Phishing (Illicit Consent Grant) zielt der Angriff nicht auf das Passwort, sondern auf die autorisierte Token-Vergabe durch den Nutzer selbst. Um dieses Risiko zu minimieren und die DSGVO-Hoheit zu behalten, steuerst du, wer wem Zugriff gewähren darf.
1. Einstellungen für die Benutzereinwilligung
Hier entscheidest du, ob deine Mitarbeiter selbstständig Apps von Drittanbietern installieren und mit Unternehmensdaten füttern dürfen.
Du hast zwei Wege: die von Microsoft verwaltete Richtlinie oder die manuelle Steuerung über die klassischen Optionen.
Empfohlen für die meisten Tenants: "Lassen Sie Microsoft Ihre Einwilligungseinstellungen verwalten (empfohlen)". Diese Option aktualisiert deinen Tenant automatisch auf die jeweils aktuelle, von Microsoft empfohlene Benutzereinwilligungsrichtlinie (Weitere Informationen). Nutzer dürfen damit nur Apps mit gering eingestuften delegierten Berechtigungen selbst zustimmen. Hochriskante Rechte wie voller Postfach-, Datei-, Kalender- oder Chat-Zugriff sowie Legacy-Mail-Protokolle erfordern dann zwingend einen Admin. Für neue Tenants ist diese Richtlinie bereits der Standard.
Dazu gehört der Schalter "Benutzereinwilligung für gängige E-Mail-Clients aktivieren". Er erlaubt Nutzern, einer von Microsoft gepflegten Liste beliebter Mail-Apps bestimmte Mail-Berechtigungen zu erteilen. Welche Anwendungen und Berechtigungen das sind, findest du hier.
Ein Punkt zur Abwägung: Bei der verwalteten Richtlinie ändert Microsoft die zugrundeliegenden Bedingungen automatisch, sobald sich die Sicherheitsempfehlungen ändern. Das kann dazu führen, dass eine bisher nutzerfreigebbare App plötzlich admin-pflichtig wird. In stark regulierten Umgebungen, in denen du jede Änderung selbst kontrollieren willst, ist die deterministische Variante "Benutzereinwilligung nicht zulassen" die sauberere Wahl.
Manuelle Steuerung. Willst du die Richtlinie selbst festlegen, stehen drei Optionen zur Wahl:
- Benutzereinwilligung nicht zulassen: die sicherste und strikteste Option. Sie verhindert, dass Benutzer eigenmächtig Apps autorisieren, die Daten absaugen könnten. Für jede App ist dann ein Administrator erforderlich.
- Für ausgewählte Berechtigungen die Benutzereinwilligung für Apps von verifizierten Herausgebern zulassen: der Mittelweg. Nutzer dürfen Apps installieren, wenn der Hersteller von Microsoft verifiziert ist und die App nur als gering eingestufte Rechte verlangt (siehe Punkt 3, Klassifizierung).
- Benutzereinwilligung für Apps zulassen: erlaubt jede nutzerfreigebbare Berechtigung. Diese Option solltest du nicht verwenden, weil sie genau das Consent-Phishing-Risiko offenlässt.
2. Der Admin-Einwilligungsworkflow
Sperrst du die Benutzereinwilligung, stoßen Mitarbeiter auf eine Fehlermeldung, sobald sie eine nützliche App brauchen. Das frustriert und treibt sie in die Schatten-IT. Die Lösung ist der Admin-Einwilligungsworkflow. Statt "Zugriff verweigert" sieht der Nutzer ein Fenster mit der Option "Genehmigung durch Admin anfordern".
Empfohlene Konfiguration:
- Benutzer können Administratoreinwilligungen für Apps anfordern: Ja. Nur so erfahren Admins, welche Tools wirklich gebraucht werden, ohne dass Benutzer blockiert sind.
- Wer kann Anforderungen überprüfen?: Wähle Benutzer (etwa den IT-Leiter), Gruppen (etwa den Helpdesk) oder Rollen aus.
- Benachrichtigungen: Setze beide Schalter auf Ja, damit die Prüfer per E-Mail informiert werden und keine Anfrage untergeht.
3. Berechtigungsklassifizierungen
Dieser Bereich greift, wenn du dich in Schritt 1 für den Mittelweg (verifizierte Herausgeber) entschieden hast. Hier definierst du, was geringes Risiko überhaupt bedeutet.
Du legst fest, welche Berechtigungen als "Niedrig" gelten. Apps, die ausschließlich diese Rechte fordern, dürfen im Mittelweg-Szenario von Nutzern selbst installiert werden. Microsoft schlägt vor, mit den häufigsten, harmlosen Berechtigungen zu starten:
User.Read(Anmelden und Profil lesen)offline_access(Zugriff beibehalten)openid(Benutzer anmelden)profile(Grundlegendes Profil anzeigen)email(E-Mail-Adresse anzeigen)
Füge diese unter dem Reiter "Niedrig" hinzu. Alles, was darüber hinausgeht, etwa "Dateien lesen" oder "Mails senden", gilt automatisch als höheres Risiko und erfordert zwingend einen Admin.
4. Bestehende Apps auditieren
Die drei Einstellungen oben sperren künftige Risiken, sie räumen aber nicht auf, was bereits erteilt wurde. Hat ein Nutzer vor der Verschärfung einer bösartigen App Zugriff gewährt, bleibt dieser Token bestehen, bis du ihn entziehst. Prüfe deshalb regelmäßig die vorhandenen Unternehmensanwendungen unter Identität > Anwendungen > Unternehmensanwendungen > Alle Anwendungen.
Achte dabei auf die Unterscheidung zwischen delegierten Berechtigungen und Anwendungsberechtigungen. Anwendungsberechtigungen wie Mail.Read, Files.ReadWrite.All oder Directory.ReadWrite.All exponieren den Tenant auch ohne kompromittierten Nutzer, weil die App eigenständig im Hintergrund läuft. Diese Rechte verlangen immer eine Admin-Einwilligung. Ein Audit deckt überprivilegierte und verwaiste Apps auf. Den Bestand wertest du per PowerShell aus (zum Beispiel mit dem Cmdlet Export-MsIdAppConsentGrantReport) oder, sofern lizenziert, über die App-Governance in Microsoft Defender for Cloud Apps.
Sei der Erste und starte die Diskussion mit einem hilfreichen Beitrag.
Kommentar hinterlassen
Dein Beitrag wird vor der Veröffentlichung kurz geprüft — fachlich, respektvoll und auf den Punkt ist hier genau richtig.