Die Secure Future Initiative macht Sicherheit im Tenant-Alltag spürbar

In vielen Tenants, die ich betreue, beobachte ich seit einigen Monaten eine deutliche Verschiebung. Sicherheit hatte schon immer einen hohen Stellenwert, durch die Secure Future Initiative steht sie jetzt aber ganz oben, häufig noch vor neuen Funktionen oder Komfort. Anfang des Monats hat Microsoft die nächste Ausbaustufe der Secure Future Initiative (SFI) angekündigt. Prinzipien wie „secure by design“, „secure by default“ und „secure operations“ sollen damit keine PR-Floskeln mehr sein, sondern bestimmen, wie sich Azure, Microsoft 365 und die übrigen Dienste weiterentwickeln. Für uns Admins bedeutet das strengere Standards. Was gestern noch nach dem Motto „geht schon irgendwie“ lief, ist morgen womöglich schlicht abgeklemmt.

Sechs Säulen bilden den Rahmen der Secure Future Initiative

Die SFI ist kein einmaliges Projekt, sondern ein dauerhafter Rahmen, der auf sechs Säulen ruht. Microsoft nennt im Einzelnen den Schutz von Identitäten und Geheimnissen, die Isolation von Tenants und Produktionssystemen, die Absicherung von Netzwerken, den Schutz der Engineering-Prozesse, die Überwachung von Bedrohungen und vor allem schnellere Reaktion und Wiederherstellung. Neu ist, dass diese Prinzipien jetzt auch die Chefetage erreichen, denn das Top-Management wird an ihrer Umsetzung gemessen. Das klingt zunächst nach einem Organisationsthema. Ich sehe darin aber eine direkte Auswirkung auf unsere tägliche Arbeit. Wer einen Tenant betreibt, muss mit neuen Standardeinstellungen und schärferen Anforderungen rechnen und hat für alte Zöpfe immer weniger Spielraum. Das geht auch aus den offiziellen Informationen von Microsoft klar hervor (hier nachzulesen).

Microsoft rollt Default-Richtlinien aus und beendet die Legacy-Authentifizierung

Am deutlichsten merkt man die SFI an Funktionen wie den von Microsoft verwalteten Conditional-Access-Richtlinien. Immer mehr Mandanten erhalten sie automatisch. Der Schwerpunkt liegt auf der MFA-Pflicht, dem Schutz vor riskanten Anmeldungen und der Grundabsicherung der wichtigsten Identitäten. In neuen Tenants gehören sie inzwischen zum Standard, in bestehenden tauchen sie bisweilen ohne Vorwarnung auf. Ich habe schon mehrere Umgebungen erlebt, in denen auf einmal Anmeldungen blockiert wurden, weil ein Legacy-Client oder ein alter Dienst die höheren Anforderungen an die Authentifizierung nicht mehr erfüllte. Spätestens da wird klar, dass hinter der SFI konkrete Änderungen stecken und nicht bloß eine bessere Dokumentation.

Mein Tipp aus der Praxis lautet, sich nicht auf die Defaults zu verlassen, denn sonst landet man schnell bei der Support-Hotline. Eigene Baseline-Richtlinien sollten immer vor den Microsoft-Defaults greifen. Legacy-Schnittstellen solltet ihr aktiv abschalten oder ersetzen, bevor Microsoft das für euch erledigt.

Vor allem bei Authentifizierung, MFA und den unterstützten Protokollen zieht Microsoft die Zügel an. Basic Auth ist Geschichte, moderne Authentifizierung mit starken Faktoren gilt als neuer Mindeststandard. Ich rechne mit weiteren Schritten, etwa einer MFA-Pflicht für alle, strengeren Session-Controls und dem Aus für veraltete Mechanismen. Wer noch Dienste betreibt, die da nicht mitziehen, sollte spätestens jetzt in die Migration investieren.

Mehr Kontrolle bringt auch mehr Verantwortung für Admins

Neben den Defaults liefert die SFI auch neue Werkzeuge, mit denen sich die eigene Absicherung prüfen und nachjustieren lässt. Die verwalteten Richtlinien kann man teilweise anpassen oder gezielt aussetzen, komplett ignorieren lassen sie sich jedoch nicht. Häufig beobachte ich, dass Admins sich auf die neuen Defaults verlassen und ihre eigene Baseline vernachlässigen. Das rächt sich spätestens dann, wenn eine Microsoft-Policy greift, die nicht zur eigenen Umgebung passt, zum Beispiel bei Gastzugriffen, Legacy-Apps oder speziellen Dienstkonten. In solchen Fällen muss man selbst aktiv werden, nachbessern und mögliche Sperren vorab testen, bevor die Änderung im Produktivbetrieb zuschlägt.

Knifflig wird vor allem das Zusammenspiel von Microsoft-Default und eigener Policy. Wer etwa für bestimmte Dienstkonten mit einer MFA-Ausnahmeregel arbeitet, sollte jetzt prüfen, ob die Managed Policies diese übersteuern. Welche Regel tatsächlich gilt, hängt von Reihenfolge und Priorisierung der Richtlinien ab. Mit diesem kleinen PowerShell-Schnipsel lassen sich alle Conditional-Access-Policies samt Status auflisten:

Get-MgIdentityConditionalAccessPolicy | Select-Object DisplayName, State, CreatedDateTime

Ein Anmeldevorgang zeigt den roten Faden der SFI im Tenant

Wie die SFI-Prinzipien im Alltag zusammenwirken, habe ich in einem Mermaid-Diagramm skizziert. Es zeigt den Ablauf einer Anmeldung mit den neuen Defaults:

flowchart TD
  User["Benutzer meldet sich an"] --> CA["Conditional Access prüft Default- und eigene Policies"]
  CA --> MFA["MFA-Anforderung wird ausgelöst"]
  MFA --> Allow["Zugriff gewährt oder blockiert"]
  Allow --> Audit["Überwachung und Logging"]
  Audit --> Threat["Erkennung von Bedrohungen"]
  Threat --> Response["Automatisierte Reaktion oder Alarm"]

Abbildung: Vereinfachter Ablauf von der Anmeldung bis zur Reaktion im SFI-Kontext.

Gut zu erkennen ist, dass die SFI keine Einzelmaßnahme darstellt. Sie bildet einen durchgehenden Kontrollfluss, der von der Authentifizierung über die Policy-Engine bis zur Reaktion auf Angriffe reicht.

Die SFI ist Realität, und die eigene Baseline entscheidet

Die Secure Future Initiative ist längst mehr als ein Schlagwort. Wer als Tenant-Admin seine Hausaufgaben nicht macht, bekommt sie jetzt von Microsoft diktiert, und zwar oft nach dem Gießkannenprinzip. Ich empfehle deshalb, die eigene Policy-Baseline regelmäßig zu prüfen, Legacy-Altlasten konsequent auszumisten und mit der Entwicklung Schritt zu halten. Wer erst auf den nächsten Default wartet, ist meist zu spät dran und steht im Zweifel vor gesperrten Zugängen oder Supportfällen. Die SFI wird bleiben, und sie wird dafür sorgen, dass Sicherheit tatsächlich an erster Stelle steht.