Wer in den letzten Tagen in Microsoft Sentinel gearbeitet hat, dürfte die Hinweise kaum übersehen haben. Der Umzug ins Defender-Portal ist nicht länger freiwillig, für neue Tenants ist er ab Juli 2025 sogar Standard. Inzwischen hat Microsoft offiziell angekündigt, den Sentinel-Bereich im Azure-Portal zum 1. Juli 2026 einzustellen. In meinen Projekten sehe ich trotzdem, dass die meisten SOC-Teams noch überwiegend im Azure-Portal arbeiten und den Wechsel vor sich herschieben. Wer langfristig mit Microsoft Sentinel plant, kommt am Defender-Portal aber nicht mehr vorbei.

Mit Sentinel im Defender-Portal ändert sich mehr als nur die Oberfläche

Die neue Heimat von Sentinel bringt für den Alltag im SOC (Security Operations Center) einige handfeste Änderungen mit sich, die über eine frische Optik weit hinausgehen. Neue Workspaces werden inzwischen direkt im Defender-Portal angebunden (→ Einstellungen → Microsoft Sentinel), sofern der Tenant nach Juli 2025 erstellt wurde oder man den Wechsel ausdrücklich vollzieht. Damit gewinnt der sogenannte Primär-Workspace an Gewicht. Im Defender-Portal lassen sich nämlich nur Workspaces verwalten, die mit Microsoft Sentinel verknüpft und als primär festgelegt sind. Die Verbindung richtet man im Defender-Portal unter Einstellungen → Microsoft Sentinel ein, und das sollte man für alle produktiven Workspaces bald nachholen. Wie die damalige Vorschau aussah, habe ich ausführlich in meinem früheren Artikel Sentinel im Defender-Portal: Mehr Einblick, weniger Silos beschrieben.

Auch Analyseregeln und Incident-Management funktionieren anders als bisher. Erkennungsregeln, Automatisierungen und die Bearbeitung von Vorfällen laufen jetzt über die einheitliche Oberfläche und damit über ein Security-RBAC-Modell, das für Defender XDR, Purview und Sentinel gleichermaßen gilt. Die Benutzerverwaltung wird dadurch einfacher. Wer im SOC bisher mit Azure-spezifischen Rollen gearbeitet hat, muss allerdings umdenken. Falls Sie benutzerdefinierte Detection Rules einsetzen, finden Sie in meinem Beitrag Custom Detection Rules in Defender XDR aus Hunting-Queries weitere Hinweise.

Regeln, Incidents und Automatisierungen laufen künftig über ein Portal

Im Defender-Portal wachsen viele Abläufe zusammen, die bisher getrennt waren. Analyseregeln erscheinen übersichtlich in Tabs, Incidents kann man nach Produkten oder Arbeitsbereichen filtern. Automatisierungsregeln, Logic Apps und Playbooks bleiben grundsätzlich erhalten, verwaltet und überwacht werden sie aber vollständig im Defender-Portal. Das hat direkte Folgen für die Berechtigungen. Die klassischen Azure-Rollen (z. B. Contributor, Reader) braucht das operative SOC nur noch, wenn parallel im Azure-Portal gearbeitet wird, und das wird mit der Zeit immer seltener nötig sein.

Ich rate dazu, den Umzug für ein gemeinsames RBAC-Review zu nutzen und die Berechtigungen dabei zu konsolidieren. Automatisierungs- und Hunting-Workflows lassen sich in der Regel problemlos migrieren, solange alle Ressourcen (Workbooks, Playbooks, Datenquellen) dem primären Workspace zugeordnet sind. Gerade an dieser Stelle lohnt sich dennoch ein Testlauf im produktiven SOC-Prozess, bevor das Azure-Portal endgültig abgeschaltet wird.

Praktischer Tipp: Bevor man den Wechsel aktiviert, sollte man im Defender-Portal ein eigenes Testkonto anlegen und mit diesem Konto die eigenen Automatisierungs-, Hunting- und Incident-Prozesse durchspielen. Probleme mit der Oberfläche oder den Berechtigungen fallen so früh auf, und das Team lässt sich gezielt schulen.

Workbooks und Hunting hängen weiterhin am primären Workspace

Auch im Defender-Portal gehören Workbooks und Hunting-Abfragen zu den wichtigsten Werkzeugen im SOC. Man findet sie im Bereich „Ermitteln“, wo sie von der einheitlichen Portallogik profitieren. Besonders beim Hunting merkt man das: Abfragen lassen sich schneller teilen, und Defender und Sentinel nutzen KQL-Workflows gemeinsam. Für anspruchsvollere Szenarien wie benutzerdefinierte Workbooks aus Vorlagen muss die Zuordnung zum primären Workspace nach wie vor stimmen. Die Datenquellen verwaltet man über Data Connectors, und dieser Teil ist im Defender-Portal spürbar schlanker und leichter verständlich geworden.

Wie die Bausteine im Portal zusammenhängen, zeigt dieses einfache Diagramm:

flowchart TD
    user["SOC-Analyst"] --> defenderportal["Defender-Portal"]
    defenderportal --> sentinelsettings["Einstellungen: Microsoft Sentinel"]
    defenderportal --> detectionrules["Analyse-/Erkennungsregeln"]
    defenderportal --> incidents["Incidents"]
    defenderportal --> automation["Automatisierungsregeln"]
    defenderportal --> hunting["Hunting & Workbooks"]
    sentinelsettings --> workspace["Primär-Workspace"]
    workspace --> datenquellen["Datenquellen"]

Abbildung: Die wichtigsten Pfade von Sentinel im neuen Defender-Portal, alles läuft über den primären Workspace.

Im Diagramm sieht man gut, dass sämtliche Sentinel-Funktionen jetzt am primären Workspace hängen. Fehlt diese Zuordnung, tauchen viele Funktionen im Defender-Portal gar nicht erst auf.

Das SOC-Team braucht Schulung und eine saubere Planung

Ein Häkchen in den Einstellungen reicht für den Umstieg nicht aus. Analysten und Incident-Responder brauchen in den meisten Organisationen eine Weile, bis sie sich an die neue Oberfläche und die geänderten Navigationspfade gewöhnt haben. Workshops, praktische Übungen und ein kurzer Leitfaden für das SOC-Team halte ich deshalb für unverzichtbar. Mit den Fachbereichen sollte man die Zusammenarbeit ebenfalls neu abstimmen, etwa bei eigenen Workbooks oder Playbooks, weil Berechtigungen nun produktübergreifend vergeben werden.

Für die Planung empfehle ich diese Schritte:

  • Primär-Workspace festlegen und die Verbindung im Defender-Portal testen
  • Alle Automatisierungs- und Erkennungsregeln auf Kompatibilität mit dem Portal prüfen
  • SOC-Team gezielt im Defender-Portal schulen
  • Workbooks, Playbooks und Data Connectors im primären Workspace konsolidieren
  • Monitoring und Berechtigungen im neuen RBAC-Modell einrichten

Weitere Details und die offiziellen Informationen von Microsoft zu Migrationspfaden und aktuellen Einschränkungen stehen in der Dokumentation (Move to Defender portal, Onboard Sentinel in Defender portal, Sentinel in Defender portal).

Ein früher Umstieg erspart 2026 viel Ärger

Je eher man den Wechsel ins Defender-Portal angeht, desto entspannter läuft der Betrieb ab 2026. Die technische Migration ist meist unspektakulär. Ob sie gelingt, hängt vor allem an Rollen, Zugriffen und Schulung, also an der organisatorischen Seite. Wer jetzt testet und das SOC-Team vorbereitet, erlebt später keine bösen Überraschungen. Ich finde, dass das einheitliche Security-Portal vieles übersichtlicher macht, auch wenn sich Security-Teams erst einmal an den Abschied vom Azure-Portal gewöhnen müssen.