Microsoft Sentinel Im Defender-Portal: Was Sie bis zum 31. März 2027 vorbereiten müssen

Nach dem 31. März 2027 wird Microsoft Sentinel im Portal nicht mehr unterstützt Azure und wird nur noch im Microsoft Defender-Portal verfügbar sein. Microsoft teilt mit, dass alle Kunden, die es noch im Portal nutzen Azure , zum Defender-Portal weitergeleitet werden. Das Produkt ist dort allgemein verfügbar, auch für Kunden, die weder über Microsoft Defender XDR noch über eine E5-Lizenz verfügen, und Microsoft weist darauf hin, dass die Umstellung keine zusätzlichen Kosten verursacht, da die Nutzung von „ Microsoft Sentinel “ weiterhin wie bisher abgerechnet wird.

Die Funktionsweise ändert sich jedoch: Vorfälle werden über die Korrelations-Engine von Defender XDR weitergeleitet, mehrere Bedingungen der Automatisierungsregeln gelten nicht mehr, und für die Verbindung mit einem Arbeitsbereich sind bestimmte Rollen im Abonnement und in Microsoft erforderlich Entra ID.

Abgerufen am 29. September 2026 aus der Microsoft-Dokumentation.

Einen Arbeitsbereich verbinden: Erforderliche Rollen

Wenn die Verbindung zum Defender-Portal nicht automatisch hergestellt wird, erfolgt dies unter „System“ > „Einstellungen“ > „ Microsoft Sentinel “ > „Arbeitsbereich verbinden“, indem Sie die Arbeitsbereiche und anschließend den Hauptarbeitsbereich auswählen. Ein Benutzer, der „ Microsoft Sentinel “ ohne „ Defender XDR “ verwendet, muss einen zusätzlichen Schritt ausführen, um die Verbindung herzustellen.

Für die Verbindung ist entweder die Rolle „Owner“, die auf Abonnementebene uneingeschränkt zugewiesen wurde, oder die Kombination aus „User Access Administrator“ und „ Microsoft Sentinel Contributor“ erforderlich. In der Tabelle von Microsoft wird außerdem die Rolle Microsoft Entra „Security Administrator“ auf Tenant-Ebene, und in der Anmerkung dazu heißt es, dass diese Rolle erforderlich ist, sobald der Tenant mehr als einen Arbeitsbereich mit „ Microsoft Sentinel “ umfasst.

Sobald der Bereich verbunden ist, gelten die Azure RBAC gelten weiterhin. Microsoft empfiehlt, die Benutzerrollen für „ Microsoft Sentinel “ über das Portal zu verwalten Azurezu verwalten, und jede Änderung wird im Defender-Portal übernommen. Durch die Verbindung wird den Anwendungen „Microsoft Threat Protection“ und „Windows Defender ATP“ im Abonnement zudem die Rolle „ Microsoft Sentinel Contributor“ zugewiesen.

Für „ Microsoft Sentinel “-Daten im Defender-Portal unterstützt Microsoft GDAP nicht mit Azure Lighthouse und verweist auf die B2B-Authentifizierung von Microsoft Entra . Die Tabelle „IdentityInfo“ wird zu einer nativen Defender-Tabelle ohne Zugriffskontrolle auf Tabellenebene: Eine auf dieser Ebene im Portal festgelegte Einschränkung Azure verschwindet bei der Übertragung. Um Daten zu isolieren, ohne die Bereiche zu trennen, bietet Microsoft „Scoping“ an, ein RBAC auf Zeilenebene, das sich derzeit in der Preview befindet und im Defender-Portal mit Unified RBAC konfiguriert wird.

Wenn die Defender-Funktionen nicht aktiviert sind, listet Microsoft drei eingeschränkte oder nicht verfügbare Funktionen auf

Bei „ Defender XDR “ kombinieren die Seiten „Home“, „Incidents“ und „Advanced Hunting“ Daten von Microsoft Sentinel und Defender XDR ; ohne „ Defender XDR “ werden nur die Daten von Microsoft Sentinel angezeigt. Wenn Microsoft Sentinel ohne die Defender-Funktionen und andere Dienste mit dem Defender-Portal verbunden ist, gibt Microsoft an, dass drei Funktionen eingeschränkt oder nicht verfügbar sind: Microsoft Security Exposure Management, die benutzerdefinierten Erkennungsregeln und das Action Center, wobei die beiden letztgenannten von Microsoft Defender bereitgestellt werden.

Auch die Datenrichtlinien ändern sich. Im Defender-Portal gelten die Richtlinien von „ Microsoft Defender XDR“ für die Speicherung, Verarbeitung, Aufbewahrung und Weitergabe von Daten, einschließlich der Daten aus „ Microsoft Sentinel “. Bei einem mit einem vom Kunden verwalteten Schlüssel (CMK) verschlüsselten Speicherbereich bleiben die Protokolle und Regeln weiterhin mit dem CMK verschlüsselt, die Warnmeldungen und Vorfälle sind jedoch nach der Verbindung nicht mehr verschlüsselt.

Analyse-Regeln: Die Korrelations-Engine von Defender XDR ersetzt Fusion

Die Analyseregeln werden wie bisher erstellt und verwaltet – über den Assistenten, die Repositorys oder denAPI Microsoft Sentinel . Im Defender-Portal werden jedoch alle Vorfälle, einschließlich derer aus den Regeln von Microsoft Sentinel, von der Engine unter Defender XDR generiert. Die Fusion-Regel wird bei der Anmeldung deaktiviert, und diese Engine übernimmt die Korrelation, die zuvor von ihr gewährleistet wurde. Dabei ändern sich mehrere Verhaltensweisen:

• Die Zusammenfassung von Warnmeldungen und die Zusammenführung von Vorfällen werden von der Engine von Defender XDR gesteuert, auch wenn die Einstellung in der Regel sichtbar bleibt: Regeln, die pro Warnmeldung einen Vorfall erstellen, können zu zusammengeführten Vorfällen führen;
• Warnmeldungen einer Regel, die so konfiguriert ist, dass sie ausschließlich Warnmeldungen ohne Vorfall generiert, sind im Defender-Portal nicht sichtbar;
• Die aktiven Regeln zur Erstellung von Microsoft-Vorfällen sind deaktiviert, um Doppelbuchungen zu vermeiden;
• Die Zusammenfassung von Warnmeldungen kann nicht mehr so eingestellt werden, dass ein geschlossener Vorfall wieder geöffnet wird: Neue Warnmeldungen führen zur Erstellung neuer Vorfälle.

Automatisierungsregeln: Die Bedingung „Incident Provider“ entfällt, und drei weitere Bedingungen ändern sich

Playbooks bleiben weiterhin Workflows Azure von Logic Apps. Es ändern sich lediglich die Automatisierungsregeln, die sie auslösen: Im Defender-Portal wirkt eine Regel mit einem Alarmauslöser nur auf Alarme von Microsoft Sentinel, und Microsoft verweist für Alarme von Defender XDR auf den „Enhanced Alert Trigger“.

Die Angabe „Incident Provider“ verschwindet im Portal Azure ebenso wie im Defender-Portal, da alle Vorfälle im Feld „Microsoft XDR“ enthalten sind ProviderName. Die bestehenden Regeln werden dann sowohl auf Vorfälle unter Microsoft Sentinel als auch auf solche unter Defender XDR angewendet, einschließlich derjenigen, die auf einen einzelnen Anbieter abzielten. Um eine Regel auf Vorfälle unter Microsoft Sentinel zu beschränken, empfiehlt Microsoft die Bedingung „Analytic rule name“ mit einer Analyseregel, die ausschließlich unter Microsoft Sentinel existiert. Weitere Bedingungen sind davon betroffen:

• Die Tabelle „SecurityIncident“ enthält kein Feld „Beschreibung“ mehr: Eine Regel, die dieses Feld als Bedingung verwendet, funktioniert nicht mehr, und ein Ticket-System wie ServiceNow erhält die Beschreibung nicht mehr;
• Die Bezeichnungen der Vorfälle können sich ändern, wenn die Korrelation greift, und Microsoft empfiehlt, diese nicht als Bedingung zu verwenden, sondern stattdessen den Namen der Analyseregel und die Tags zu nutzen;
• Im Feld „Updated by“ wird der Wert Microsoft 365 „Defender“ in „Other“.

Auch die Zeiträume ändern sich. Eine Automatisierungsregel kann bis zu 10 Minuten nach Auslösung des Alarms ausgeführt werden, da der Vorfall zunächst im Defender-Portal entsteht, bevor er an Microsoft Sentinel weitergeleitet wird. Wenn innerhalb von 5 bis 10 Minuten mehrere Änderungen denselben Vorfall betreffen, wird nur eine einzige Aktualisierung mit der letzten Änderung gesendet, und die Zwischenzustände gehen verloren.

Das manuelle Ausführen eines Playbooks für einen Alarm oder eine Entität wird im Defender-Portal derzeit nicht unterstützt, und eine Automatisierungsregel wird dort nicht ausgehend von einem Vorfall erstellt, sondern über die Seite „Automatisierung“. Vorfälle, die über den „API “, durch ein Logic Apps-Playbook oder manuell im Portal erstellt wurden Azure , werden nicht mit dem Defender-Portal synchronisiert.

Workbooks, Hunting und „ API  “: Lesezeichen, Workspace-Manager und providerName

Die Arbeitsmappen sind nach wie vor das wichtigste Visualisierungstool und funktionieren wie im Portal Azure ; um dort Daten aus „Advanced Hunting“ anzuzeigen, müssen die Protokolle in „ Microsoft Sentinel “ eingelesen werden. Die vorhandenen Tabellen, KQL-Abfragen und Funktionen können weiterhin in „Advanced Hunting“ genutzt werden, Lesezeichen sind dort jedoch nicht verfügbar: Sie befinden sich weiterhin unter „Microsoft Sentinel “ > „Threat Management“ > „Hunting“. Die Tabelle „IdentityInfo“ in „Advanced Hunting“ benennt bestimmte Felder um oder unterstützt sie nicht, und Abfragen, die in „ Microsoft Defender “ ausgeführt werden, insbesondere benutzerdefinierte Erkennungen, müssen überprüft werden. Der Workspace Manager ist im Defender-Portal nicht verfügbar; Microsoft bietet die Bereitstellung von Inhalten aus einem Repository (in der Preview) oder über das mandantenfähige Portal an.

Was „ API “ betrifft, ändert sich der Antworttext von SecurityInsights wie folgt: providerName Wechsel von „ Azure Sentinel“ zu „Microsoft XDR“ und ein Feld providerIncidentUrl kommt hinzu. Für einheitliche Vorfälle und Warnmeldungen empfiehlt Microsoft die „API “ (Microsoft Graph ); die „API “ (Microsoft Sentinel ) wird weiterhin für Regeln und andere Ressourcen unterstützt.

Mehrere Arbeitsbereiche: Der „ Defender XDR “-Connector lässt sich nur mit dem Hauptarbeitsbereich verbinden

Das Defender-Portal unterstützt pro Mandant einen Hauptbereich und mehrere Unterbereiche. Der „ Defender XDR “-Konnektor ist nur mit dem Hauptbereich verbunden, und die Verbindung trennt in den Unterbereichen automatisch die eigenständigen Konnektoren von „ Microsoft Defender for Office 365, Microsoft Entra ID Protection, Microsoft Defender for Cloud Apps, Microsoft Defender for Endpoint und Microsoft Defender for Identity automatisch getrennt. Die Warnmeldungen dieser Produkte sind dann nur noch im Hauptarbeitsbereich verfügbar, und nur die Warnmeldungen dieses Arbeitsbereichs werden mit Defender XDR korreliert. Microsoft empfiehlt, die Automatisierungsregeln in den betreffenden Arbeitsbereich zu übertragen, damit sie weiterhin ausgeführt werden. Der Hauptarbeitsbereich lässt sich unter „System > Einstellungen > Microsoft Sentinel > Arbeitsbereiche“ mit „Als primär festlegen“ ändern.

Von einem MSSP verwaltete Kunden: Die automatische „onboarding “ soll im September 2026 eingeführt werden

Am 9. September 2026 teilte Microsoft seinen Partnern mit, dass das Unternehmen ab September 2026 damit beginnen werde, verwaltete Kunden, die noch nicht zum Defender-Portal gewechselt sind, automatisch dort anzumelden. Microsoft kümmert sich um den Zeitplan, die Benachrichtigungen und die technische Anbindung; die Tenant-Administratoren erhalten etwa 30 Tage vorher einen Hinweis im Portal und eine E-Mail. Konnektoren von Drittanbietern, Inhalte und Daten bleiben erhalten.

Bei einem Kunden mit mehreren Bereichen wählt Microsoft den Hauptbereich aus, und Inhalte in den sekundären Bereichen, die von „ Defender XDR “ abhängig sind, funktionieren möglicherweise nicht mehr. Microsoft empfiehlt, die betroffenen Scan-Regeln, Automatisierungsregeln, Playbooks und Arbeitsmappen in den Hauptbereich zu migrieren. Um einen anderen Hauptbereich zu beantragen, wird in der Ankündigung darauf hingewiesen, eine E-Mail an [email protected] zusammen mit der Tenant-ID und der Ressourcen-ID des gewünschten Bereichs.

Onboarding nach dem 23. September 2026: Für den Data Lake ist kein separates „ onboarding “ erforderlich

Für Kunden, die ihre „ onboarding “ nach dem 23. September 2026 durchführen, ist der „ Microsoft Sentinel “-Data-Lake in „ Microsoft Sentinel “ als kostengünstige Erfassungs- und Speicherebene für die Langzeitaufbewahrung integriert, ohne dass eine separate „ onboarding “ oder Abrechnungskonfiguration erforderlich ist. Schließen Sie die „onboarding “ von „ Microsoft Sentinel “ ab, überprüfen Sie, ob der Speicherbereich mit dem Defender-Portal verbunden ist, und aktivieren Sie dann die Data-Lake-Ebene in der „Table Management“-Ansicht, indem Sie eine Tabelle auswählen und deren „Retention“-Einstellungen festlegen.

Bei einem Bestandskunden, der noch keine „onboarding “ des Data Lake durchgeführt hatte, wird die Aufbewahrung von einem archivbasierten Modell auf die Aufbewahrung im Data Lake umgestellt, auf den direkt in „Advanced Hunting“ zugegriffen werden kann, ohne dass eine Wiederherstellung erforderlich ist. Auf der Microsoft-Seite zum Thema „onboarding “ des Data Lake wird auf eine Auswirkung auf die Kosten hingewiesen: Für ein Unternehmen, das bereits den „ SIEM “ nutzt, werden Funktionen wie Suchaufträge, Zusatzprotokolle und Langzeitaufbewahrung nun über die Zähler des Data Lake abgerechnet, was zu höheren Kosten führen kann.

Unsere Lektüre

Wir würden den 31. März 2027 nicht als Schnittstellenwechsel behandeln. Durch die Anbindung wird die Erstellung von Vorfällen in die Engine von Defender XDR verlagert, und genau dort treten Regressionen auf: Eine Automatisierungsregel, die nach der Beschreibung oder dem Anbieter des Vorfalls filtert, verhält sich nicht mehr wie zuvor, und eine Regel, die nach dem Titel filtert, wird möglicherweise nicht mehr angewendet, wenn die Korrelation den Vorfall umbenennt. Wir würden daher zunächst eine Bestandsaufnahme der Automatisierungsregeln und Playbooks vornehmen.

In einer Tenant-Umgebung mit mehreren Bereichen würden wir vor der Verbindung den Hauptbereich auswählen und die Inhalte, die von „ Defender XDR “ abhängen, dorthin verschieben. Für einen verwalteten Kunden lohnt es sich, diese Entscheidung zu treffen, bevor Microsoft sie im Rahmen der automatischen „onboarding “ trifft. Schließlich würden wir die Verschlüsselung von Warnungen und Vorfällen überprüfen, die nach der Verbindung nicht mehr unter CMK fällt, sowie die Zugriffe auf IdentityInfo. Die Verfahren zur Reaktion auf Vorfälle, einschließlich derer, diedie Meldung eines Cyberangriffs an das OFCS vorbereiten, wenn die Organisation davon betroffen ist, stützen sich auf die Vorfallwarteschlange des Defender-Portals: Sie sollten nach der Verbindung des Bereichs erneut überprüft werden.

Was zu überprüfen ist

• Die Rollen der Person, die die Verbindung herstellt: uneingeschränkter „Owner“ des Abonnements oder „User Access Administrator“ und „ Microsoft Sentinel “ sowie „Contributor“ und „Security Administrator“ in Microsoft Entra ID – diese Rollen werden in der Tabelle von Microsoft für die Verbindung aufgeführt und sind laut deren Hinweis erforderlich, sobald der Tenant mehr als einen Bereich umfasst.
• Ohne Defender XDR, den zusätzlichen Anmeldeschritt und die mögliche Nutzung von Exposure Management, benutzerdefinierten Erkennungsregeln oder dem Action Center.
• Die Wahl des Hauptbereichs sowie der Inhalt der Nebenbereiche hängen von Defender XDR ab.
• Automatisierungsregeln, die den „Incident Provider“, das Feld „Beschreibung“, den Titel des Vorfalls oder den Wert Microsoft 365 „Defender“ im Feld „Updated by“ verwenden.
• Die Regeln für die Analyse im reinen Warnmodus sowie diejenigen, die geschlossene Vorfälle wieder öffnen.
• Integrationen, die lesen providerName oder die Beschreibung der Vorfälle durch den „API “ von SecurityInsights.
• Die CMK-Verschlüsselung von Warnmeldungen und Vorfällen, Einschränkungen bei IdentityInfo und der Zugriff über GDAP mit Azure Lighthouse.
• Bei einem „ onboarding “ nach dem 23. September 2026: die Aktivierung des Data Lake in der Tabellenverwaltung und deren Auswirkungen auf die Abrechnung.

Quellen von Microsoft

• Microsoft Sentinel im Portal „ Microsoft Defender “
• Stellen Sie Ihre „ Microsoft Sentinel “-Umgebung auf das Defender-Portal um
• Verbinden Sie „ Microsoft Sentinel “ mit dem Portal „ Microsoft Defender “
• Was ist das Sicherheitsinformations- und Ereignismanagement von „ Microsoft Sentinel “ (SIEM)?
• Was gibt’s Neues in Microsoft Sentinel
• Mitteilungen des Partner Centers, September 2026
• Rollen und Berechtigungen in der „ Microsoft Sentinel “-Plattform
• Daten in den „ Microsoft Sentinel “-Data-Lake und den „ Microsoft Sentinel “-Graph einbinden
• Microsoft Sentinel -Daten in einen Log Analytics-Arbeitsbereich integrieren