Authentication Context schützt sensible SharePoint-Sites gezielt

In vielen Tenants, die ich mir ansehe, liegen auf einzelnen SharePoint-Sites besonders heikle Inhalte, zum Beispiel Vorstandsunterlagen, Projekte mit externen Partnern oder HR-Daten. Die übliche Absicherung per Conditional Access genügt dort oft nicht, denn sie greift auf ganze Apps wie „Office 365“ oder „SharePoint Online“. Wer etwa phishingresistente MFA oder ein konformes Gerät nur für bestimmte Sites verlangen möchte, kommt damit nicht weit. Genau für solche Fälle gibt es den Authentication Context, mit dem sich Zugriffsrichtlinien wesentlich feiner steuern lassen.

Authentication Context knüpft Richtlinien an Kontextwerte statt an Apps

Mit Authentication Context lassen sich in Entra ID zusätzliche Anforderungen an die Anmeldung mit bestimmten Aktionen oder Bereichen verbinden. Bei klassischen Conditional-Access-Richtlinien hängt man die Regel an eine App. Hier dagegen bezieht sie sich auf einen sogenannten Kontextwert, etwa „c1“ oder „c2“. Diesen Kontext weist man dann einzelnen Ressourcen zu: einer SharePoint-Site, einem Label oder sogar einer Rolle, die über PIM aktiviert wird.

Viele Admins haben Authentication Context nach meiner Erfahrung noch nie eingesetzt. Dabei eröffnet gerade das Zusammenspiel mit Sensitivity Labels aus Microsoft Purview oder mit Privileged Identity Management (PIM) eine Menge interessanter Möglichkeiten. Bei den Lizenzen ist die Sache recht übersichtlich. Für Authentication Context selbst genügt Entra ID P1, wer Sensitivity Labels nutzen will, braucht zusätzlich eine Purview-Lizenz (weitere Details bei Microsoft).

Der Weg zur ersten Richtlinie beginnt im Entra-Portal

Zuerst legt man im Entra-Portal unter „Conditional Access > Authentication context“ einen neuen Kontextwert an, beispielsweise „c1 – Hochsicherer Zugriff“. Auf diesen Wert greift man später gezielt zurück. Danach folgt eine Conditional-Access-Richtlinie, die auf genau diesen Kontext zielt und festlegt, was beim Zugriff erfüllt sein muss, zum Beispiel:

• Zugriff nur mit phishingresistenter MFA (etwa FIDO2 oder CBA)
• alternativ Zugriff nur von verwalteten, konformen Geräten

Testen lassen sich solche Richtlinien zunächst im Report-only-Modus, und das empfehle ich bei neuen Kontexten ausnahmslos. Wie die Richtlinien grundsätzlich funktionieren, beschreibt die Dokumentation von Microsoft verständlich. Richtet man sie auf einen Authentication Context aus, kommen allerdings noch einige Möglichkeiten hinzu.

Mein Tipp aus der Praxis: Nutzt für Tests immer eigene Testbenutzer und den Report-only-Modus, bevor ihr produktive Sites tatsächlich sperrt.

Einzelne SharePoint-Sites lassen sich gezielt mit einem Kontext belegen

Seine Stärken zeigt der Authentication Context vor allem dann, wenn man ihn auf eine einzelne SharePoint-Site anwendet. Dafür gibt es zwei Wege. Man weist entweder ein Sensitivity Label mit Container-Einstellungen zu, das auf den Kontext verweist, oder man setzt das Flag direkt per PowerShell:

Set-SPOSite -Identity "https://contoso.sharepoint.com/sites/Geheimprojekt" -ConditionalAccessPolicy AuthenticationContext

Anschließend schließt man die Zuordnung des Kontexts im SharePoint-Admin-Portal oder ebenfalls per PowerShell ab. Voraussetzung sind die passenden Lizenzen, außerdem funktioniert das derzeit nur bei modernen Sites.

In einer typischen Umgebung läuft der Zugriff dann so ab:

flowchart TD
  User["User-Zugriff"] --> SharePoint["SharePoint-Site"]
  SharePoint --> Context["Authentication Context getriggert"]
  Context --> CA["Conditional Access Policy"]
  CA --> MFA["Phishing-resistente MFA / Gerät"]
  MFA --> Zugriff["Zugriff gewährt"]

Abbildung: Beim Zugriff auf eine geschützte SharePoint-Site greifen Authentication Context und Conditional-Access-Richtlinie nacheinander.

Der Kontext wirkt auch bei Labels, Defender und PIM

Besonders schätze ich am Authentication Context, dass er sich so vielseitig einsetzen lässt. Über Sensitivity Labels (Dokumentation zu Microsoft Purview) binde ich neben SharePoint-Sites auch Teams und M365-Gruppen an denselben Kontext. Bei Projekten mit verschachtelten Freigaben und strengen Vorgaben zur Data Governance hilft mir das sehr. Zusammen mit Defender for Cloud Apps lassen sich außerdem Aktivitäten wie Downloads oder Zugriffe aus bestimmten Ländern zusätzlich absichern. Und in Privileged Identity Management kann der Kontext Bedingung dafür sein, dass jemand eine kritische Rolle aktivieren darf.

Eine Schritt-für-Schritt-Anleitung zur Absicherung mit Conditional Access gibt es in meinem Beitrag mit Best Practices für Conditional Access in Entra ID.

Nutzer merken wenig davon, solange der Rollout gut geplant ist

Die meisten Anwender bekommen vom Authentication Context kaum etwas mit. Die zusätzliche Anmeldung wird erst fällig, wenn sie zum ersten Mal die geschützte Site oder den Container öffnen. Session Controls verringern die Zahl der Abfragen, abhängig von der Richtlinie kann es in manchen Browserszenarien aber dennoch zu wiederholten MFA-Aufforderungen kommen. Ohne klaren Rollout-Plan und frühzeitige Information trifft die zusätzliche Abfrage viele Nutzer völlig unvorbereitet.

Oft beobachte ich, dass Teams Labels und Kontexte erst während der Testphase den richtigen Ressourcen zuordnen. Mit dem Report-only-Modus und einem schrittweisen Rollout lassen sich größere Störungen dabei vermeiden. Klassische Conditional-Access-Regeln auf App-Ebene helfen in diesem Szenario übrigens nicht weiter.

Mehr Kontrolle gibt es nur mit einem durchdachten Konzept

Authentication Context löst nicht jedes Problem. Für besonders sensible Sites und Container in Microsoft 365 ist er aber ein wirkungsvolles Werkzeug. Wer das Prinzip einmal verinnerlicht hat, kann Sicherheitsanforderungen wesentlich feiner abstufen als bisher. Lizenzen und technische Grenzen sollte man trotzdem nicht aus den Augen verlieren. Sauber eingeführt ergänzt Authentication Context den Conditional Access sinnvoll, und ich gehe davon aus, dass er in Zukunft noch wichtiger wird.