Automatisieren der Sentinel-Integration mit Azure DevOps

In diesem Artikel wird beschrieben, wie Sie Integrations- und Bereitstellungsvorgänge von Microsoft Sentinel mit Azure DevOps automatisieren. Sie implementieren Azure DevOps, indem Sie Microsoft Sentinel-Funktionen verwenden, um Ihre Bereitstellung zu schützen. Anschließend verwenden Sie ein DevSecOps-Framework, um Microsoft Sentinel-Artefakte im großen Stil zu verwalten und bereitzustellen.

Aufbau

Das folgende Diagramm zeigt ein Azure DevOps- und das Microsoft Sentinel IaC-Setup.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Datenfluss

1. Die Master- und Produktverwaltung verwendet Azure DevOps, um Epics, User Storys und Produktbacklogelemente als Teil des Projektbacklogs zu definieren.
   • Die Master- und Produktverwaltung verwendet Azure Boards, um das Backlog zu erstellen, die Arbeit in Sprints zu planen, das Projektboard zu überprüfen, die Repositorystruktur zu erstellen und Sicherheitsregeln wie Genehmigungsworkflows und Branches festzulegen.
   • Das Azure Git-Repository speichert die Skripts und erlaubt die Verwaltung von Microsoft Sentinel-Artefakten in der Infrastruktur als Code.
   • Artefakte und Quellcodeverwaltung verwalten die Erweiterungen und Updatepakete oder Komponenten des DevSecOps-Workflows, die in der Lösung verwendet werden, z. B. Azure Resource Manager Template Toolkit und PowerShell Pester.
2. Microsoft Sentinel-Artefakte:
   • Richtlinien. SIEM-Techniker verwenden Azure-Richtlinien in der Referenzarchitektur, um die Diagnoseeinstellungen der Azure-Dienste zu konfigurieren und zu skalieren. Die Richtlinien helfen bei der Automatisierung der Bereitstellung der Microsoft Sentinel-Datenconnectors, z. B. Azure Key Vault. Die Richtlinien sind von der OMSIntegration-API abhängig.
   • Connectors: Microsoft Sentinel verwendet logische Connectors – die Azure-Datenconnectors –, um Sicherheitsdaten zu erfassen, z. B. bei Überwachungen oder in Metriken, aus unterstützten Datenquellen wie Microsoft Entra ID, Azure-Ressourcen, Microsoft Defender oder Drittanbieterlösungen. Die Hauptliste der Datenconnectors wird von der SecurityInsights-API verwaltet. Andere verwenden die OMSIntegration-API und werden mit den Azure Policy Diagnoseeinstellungen verwaltet.
   • Eine verwaltete Identität Microsoft Sentinel verwendet die verwaltete Identität, um im Namen der verwalteten Dienstidentität (Managed Service Identity, MSI) zu agieren, während mit Playbooks, Logik-Apps oder Automation-Runbooks und dem Key Vault interagiert wird.
   • Automatisierung: SOC-Teams verwenden automatisierungsbasierte Untersuchungen. SOC-Teams führen Verfahren für den digitalen Forensikdatenabruf mit Azure Automation aus, z. B. die Sicherungskette virtueller Azure-Computer (VM) oder eDiscovery (Premium) für Microsoft Defender.
   • Analysen SOC-Analysten oder Bedrohungsexperten verwenden integrierte oder benutzerdefinierte Analyseregeln, um Daten in Microsoft Sentinel zu analysieren und zu korrelieren oder Playbooks auszulösen, wenn eine Bedrohung und ein Incident identifiziert werden.
   • Playbooks Logik-Apps führen die wiederholbaren SecOps-Aktionen aus, z. B. zuweisen eines Incidents, Aktualisieren eines Incidents oder Durchführen von Korrekturaktionen, z. B. Isolieren oder Enthalten eines virtuellen Computers, Widerrufen eines Tokens oder Zurücksetzen eines Benutzerkennworts.
   • Bedrohungssuche Bedrohungssuche nutzt proaktive Bedrohungssuchefunktionen, die mit Jupyter Notebooks für erweiterte Anwendungsfälle gekoppelt werden können, z. B. Datenverarbeitung, Datenbearbeitung, Datenvisualisierung, Machine Learning oder Deep Learning.
   • Arbeitsmappen. SIEM-Techniker verwenden Dashboards für Arbeitsmappen, um Trends und Statistiken zu visualisieren und den Status einer Microsoft Sentinel-Instanz und ihrer Unterkomponenten anzuzeigen.
   • Informationen zu Bedrohungen: Ein bestimmter Datenconnector, der Threat Intelligence-Plattformen mit Microsoft Sentinel verbindet. Zwei Konnektivitätsmethoden werden unterstützt: TAXII und Graph-API. Beide Methoden dienen als TiIndicators oder Threat Intelligence-Indikatoren in Sicherheits-APIs.
3. Microsoft Entra ID. Identitäts- und Zugriffsverwaltungsfunktionen werden an Komponenten bereitgestellt, die in der Referenzarchitektur verwendet werden, z. B. verwaltete Identitäten, Dienstprinzipale, rollenbasierte Zugriffssteuerungen (Role-Based Access Controls, RBACs) von Azure für Microsoft Sentinel, Logik-Apps und Automation-Runbooks.
4. Azure Pipelines. DevOps-Techniker verwenden Pipelines, um Dienstverbindungen für die Verwaltung der verschiedenen Azure-Abonnements wie Sandbox- und Produktionsumgebungen mit CI/CD-Pipelines (Continuous Integration und Continuous Delivery) zu erstellen. Es wird empfohlen, Genehmigungsworkflows zu verwenden, um unerwartete Bereitstellungen und getrennte Dienstprinzipale zu verhindern, wenn Sie mehrere Abonnements pro Azure-Umgebung als Ziel verwenden.
5. Azure Key Vault: SOC-Techniker verwenden den Key Vault, um Dienstprinzipalgeheimnisse und -zertifikate sicher zu speichern. Diese Komponente der Architektur hilft, das DevSecOps-Prinzip keine Geheimnisse im Code zu erzwingen, wenn es von Azure Pipeline-Dienstverbindungen verwendet wird.
6. Azure-Abonnement. Die SOC-Teams verwenden in dieser Referenzarchitektur zwei Instanzen von Microsoft Sentinel, die in zwei logischen Azure-Abonnements getrennt sind, um Produktions- und Sandboxumgebungen zu simulieren. Sie können für Ihre Anforderungen mit anderen Umgebungen skalieren, z. B. mit Tests, Entwicklung, Präproduktion usw.

Dataflowbeispiel

1. Ein Administrator fügt einen Eintrag in seinem Fork der Microsoft 365-Konfigurationsdatei hinzu, aktualisiert oder löscht ihn.
2. Der Administrator committet die Änderungen und synchronisiert sie mit seinem geforktem Repository.
3. Der Administrator erstellt dann einen Pull Request (PR), um die Änderungen mit dem Hauptrepository zusammenzuführen.
4. Die Buildpipeline wird auf dem PR ausgeführt.

Komponenten

• Microsoft Entra ID ist ein mehrinstanzenfähiger, cloudbasierter Dienst zum Verwalten Ihrer Identitäts- und Zugriffssteuerungen.
• Azure DevOps ist ein Cloud-Dienst, mit dem Sie gemeinsam an Code arbeiten, Anwendungen erstellen und bereitstellen oder Ihre Arbeit planen und verfolgen können.
• Azure Key Vault ist ein Clouddienst zum sicheren Speichern und Zugreifen auf Geheimnisse. Als Geheimnis wird alles bezeichnet, für das Sie den Zugriff streng kontrollieren möchten, z. B. API-Schlüssel, Kennwörter, Zertifikate oder kryptografische Schlüssel.
• Azure Policy ist ein Dienst, mit dem Sie Richtliniendefinitionen in Ihrer Azure-Umgebung erstellen, zuweisen und verwalten können.
• Microsoft Sentinel ist eine skalierbare, cloudnative SIEM- und SOAR-Lösung (Sicherheitsorchestrierung, Automation, Reaktion).
• Azure Automation ist ein Dienst für die Vereinfachung der Cloudverwaltung durch eine Prozessautomatisierung. Verwenden Sie Azure Automation, um langwierige, manuelle, fehleranfällige und häufig wiederholte Aufgaben zu automatisieren. Automation trägt dazu bei, die Zuverlässigkeit, Effizienz und die Zeit bis zur Wertschöpfung für Ihr Unternehmen zu verbessern.

Szenariodetails

Security Operations Center-Teams (SOC) stehen bei der Integration von Microsoft Sentinel in Azure DevOps bisweilen vor Herausforderungen. Der Prozess umfasst viele Schritte, und das Setup kann tagelang mit Wiederholung dauern. Sie können diesen Teil der Entwicklung automatisieren.

Zur Modernisierung für die Cloud müssen Techniker ständig neue Fähigkeiten und Techniken zum Sichern und Schützen wichtiger Geschäftsressourcen erlernen. Techniker müssen stabile und skalierbare Lösungen erstellen, die mit den sich ständig ändernden Sicherheitslandschaften und Geschäftsanforderungen Schritt halten. Eine Sicherheitslösung muss flexibel, agil und sorgfältig ab den frühesten Phasen der Entwicklung geplant sein. Diese Methodik der frühzeitigen Planung wird als Linksverschiebung bezeichnet.

In diesem Artikel wird beschrieben, wie Sie Integrations- und Bereitstellungsvorgänge von Microsoft Sentinel mit Azure DevOps automatisieren. Sie können die Lösung für komplexe Organisationen erweitern, die über mehrere Entitäten, Abonnements und verschiedene Betriebsmodelle verfügen. Zu den von dieser Lösung unterstützten Betriebsmodellen gehören lokales SOC, globales SOC, Clouddienstanbieter (Cloud Service Provider, CSP) und verwalteter Sicherheitsdienstanbieter (Managed Security Service Provider, MSSP).

Dieser Artikel ist für die folgenden Zielgruppen gedacht:

• SOC-Spezialisten wie Analysten und Bedrohungsexperten
• SIEM-Techniker (Security Information & Event Management)
• Cybersicherheitsarchitekten
• Entwickler

Mögliche Anwendungsfälle

Es folgen die typischen Anwendungsfälle für diese Architektur:

• Schnelle Prototyperstellung und Proof of Concept. Diese Lösung eignet sich ideal für Sicherheitsorganisationen und SOC-Teams, die die Abdeckung von Cloudbedrohungen verbessern oder ihre SIEM-Infrastruktur mit Infrastructure-as-Code (IaC) und Microsoft Sentinel modernisieren möchten.
• Microsoft Sentinel als Dienst. Dieses Entwicklungsframework integriert die Prinzipien der Dienstlebenszyklusverwaltung. Diese Prinzipien sind für einfache oder komplexe Teams geeignet, z. B. MSSPs, die wiederholbare, standardisierte Aktionen für mehrere Kundenmandanten ausführen und gleichzeitig die Leistungsfähigkeit von Azure DevOps und Azure Lighthouse kombinieren. Beispielsweise könnte ein Team, das Microsoft Sentinel-Anwendungsfälle für einen neuen Bedrohungsakteur oder eine laufende Kampagne veröffentlichen muss, diese Lösung verwenden.
• Erstellen von SOC-Anwendungsfällen für die Bedrohungserkennung. Viele Gruppen und Threat Intelligence-Plattformen nutzen MITRE Att&ck-Inhalte und Taxonomie, um ihren Sicherheitsstatus gegen erweiterte Handelstechniken oder Techniken und Taktikverfahren zu analysieren. Die Lösung definiert einen strukturierten Ansatz für die Entwicklung von Methoden zur Bedrohungserkennung, indem die MITRE Att&ck-Terminologie in die Entwicklung von Microsoft Sentinel-Artefakten integriert wird.

Die folgende Abbildung zeigt ein MITRE Att&ck-Cloudszenario.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Bedrohungsdefinitions-Angriffsszenarien basierend auf MITRE

In dieser Tabelle werden die Begriffe, Definitionen und Details zu wichtigen Aspekten von Angriffsszenarien angezeigt.

Datenelement	BESCHREIBUNG	Microsoft Sentinel-Artefakte
Titel	Beschreibender Name für das Angriffsszenario, basierend auf Angriffsvektormerkmalen oder Beschreibungen der Technik.	MITRE-Manifest
MITRE ATT&CK-Taktik	MITRE ATT&CK-Taktiken im Zusammenhang mit einem Angriffsszenario	MITRE-Manifest
MITRE ATT&CK-Techniken	MITRE ATT&CK-Techniken, einschließlich der Technik- oder Untertechnik-ID im Zusammenhang mit dem Angriffsszenario.	MITRE-Manifest
Datenconnector-Quellen	Quelle der von einem Sensor oder Protokollierungssystem gesammelten Informationen, die zum Sammeln von Informationen verwendet werden können, die relevant sind, um die ausgeführte Aktion, die Abfolge von Aktionen oder die Ergebnisse dieser Aktionen durch einen Angreifer zu identifizieren.	Microsoft Sentinel-Datenconnector oder benutzerdefinierte Protokollquelle
BESCHREIBUNG	Informationen zur Technik, zur Funktionsweise, zur Verwendung in der Regel, zur Nutzung durch einen Angreifer und zu Varianten seiner Verwendung. Enthält Verweise auf autoritative Artikel, die technische Informationen im Zusammenhang mit der Technik sowie in der Freien Verwendung nach Bedarf beschreiben.
Erkennung	Analyseprozess, Sensoren, Daten und Erkennungsstrategien auf hoher Ebene, die nützlich sind, um eine Technik zu identifizieren, die von einem Angreifer verwendet wird. In diesem Abschnitt werden die verantwortlichen Personen informiert, die für die Erkennung von Angreiferverhalten verantwortlich sind, z. B. Netzwerk-Defenders, damit sie eine Aktion wie das Schreiben einer Analyse oder die Bereitstellung eines Sensors durchführen können. Es sollten genügend Informationen und Verweise vorhanden sein, um auf nützliche defensiv ausgerichtete Methoden hinzuweisen. Die Erkennung ist für eine bestimmte Technik möglicherweise nicht immer möglich und sollte als solche dokumentiert werden.	Bedrohungssuche in Analytics
Minderung	Konfigurationen, Tools oder Prozesse, die verhindern, dass eine Technik funktioniert oder das gewünschte Ergebnis für einen Kontrahenten hat. In diesem Abschnitt werden die verantwortlichen Personen für die Abwehr von Gegenmaßnahmen gegen Angreifer wie Netzwerk-Defenders oder Juristen informiert, damit diese eine Aktion wie das Ändern einer Richtlinie oder das Bereitstellen eines Tools durchführen können. Eine Entschärfung ist für ein bestimmtes Verfahren möglicherweise nicht immer möglich und sollte als solche dokumentiert werden.
Minderung	Konfigurationen, Tools oder Prozesse, die verhindern, dass eine Technik funktioniert oder das gewünschte Ergebnis für einen Kontrahenten hat. In diesem Abschnitt wird beschrieben, wie Sie die Auswirkungen von Angriffen für Netzwerk-Defenders oder Juristen abschwächen. Es werden die Schritte zum Ändern einer Richtlinie oder zum Bereitstellen eines Tools beschrieben. Die Entschärfung ist für eine bestimmte Technik möglicherweise nicht immer möglich und sollte als solche dokumentiert werden.	Playbooks, Automation-Runbooks

Überlegungen

Diese Überlegungen setzen die Säulen des Azure Well-Architected Framework um, das aus einer Reihe von Leitprinzipien besteht, die zur Verbesserung der Qualität einer Workload verwendet werden können. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Sicherheit

Sicherheit bietet Schutz vor vorsätzlichen Angriffen und dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Übersicht über die Säule „Sicherheit“.

Bei der Sicherheit erhöht die Automatisierung im Allgemeinen die Effizienz des Betriebs und spart Gleichzeitig Zeit für komplexere Anwendungsfälle wie Bedrohungserkennung, Threat Intelligence, SOC und SOAR-Anwendungsfälle. DevOps-Teams müssen wissen, wo sie IaC im Kontext von Microsoft Sentinel CI/CD sicher verwenden können. Dieser Prozess führt die Verwendung spezifischer Identitäten ein, die von nicht zu einer Person gehörigen Konten in Microsoft Entra ID verwendet werden, die als Dienstprinzipale und verwaltete Identitäten bezeichnet werden.

In der folgenden Tabelle werden Sicherheitsüberlegungen für Dienstprinzipale und die wichtigsten Anwendungsfälle zusammengefasst, die von Microsoft Sentinel und Azure DevOps Releasepipelines abgedeckt werden.

Anwendungsfall	Anforderungen (geringste Rechte)	Dauer der Rollenzuweisung	Berechtigungsbereich	Treuhänder	Sicherheitshinweise
Aktivieren von Microsoft Sentinel-Connectors	Sicherheitsadministrator** Besitzer* Microsoft Sentinel-Mitwirkender Leser	JIT (einmalige Aktivierung) Absichtlich (jedes Mal, wenn ein neues Abonnement und ein Connector bereitgestellt werden)	Tenant	SPN	Verwenden Sie den Key Vault, um SpN-Geheimnisse (Service Principal Name, Dienstprinzipalname) und das Zertifikat zu speichern. Aktivieren Sie die SPN-Überprüfung. Überprüfen Sie in regelmäßigen Abständen die Berechtigungszuweisung (Azure Privileged Identity Management für SPN) oder verdächtige Aktivitäten für SPN. Verwenden Sie Microsoft Entra-Zertifizierungsstellen und (sofern unterstützt) die Multi-Faktor-Authentifizierung (MFA) für privilegierte Konten. Verwenden Sie benutzerdefinierte Microsoft Entra-Rollen für mehr Granularität.
Bereitstellen von Microsoft Sentinel-Artefakten wie Arbeitsmappen, Analysen, Regeln, Abfragen zur Bedrohungssuche, Notebooks und Playbooks	Microsoft Sentinel-Mitwirkender Logic Apps-Mitwirkender	Dauerhaft	Arbeitsbereich oder Ressourcengruppe von Microsoft Sentinel	SPN	Verwenden Sie Azure DevOps Workflowgenehmigung (ADO) und Überprüfungen, um die Pipelinebereitstellung mit diesem SPN zu sichern.
Zuweisen einer Richtlinie zum Konfigurieren von Protokollstreamingfeatures zu Microsoft Sentinel	Mitwirkender bei Ressourcenrichtlinien**	Absichtlich (jedes Mal, wenn ein neues Abonnement und ein Connector bereitgestellt werden)	Alle zu überwachenden Abonnements	SPN	Verwenden Sie Microsoft Entra ID, die Zertifizierungsstelle und MFA (sofern unterstützt) für privilegierte Konten.

* Betrifft nur Microsoft Entra-Diagnoseeinstellungen.
** Bestimmte Connectors benötigen zusätzliche Berechtigungen wie „Sicherheitsadministrator“ oder „Mitwirkender bei Ressourcenrichtlinien“, um das Streamen von Daten an den Microsoft Sentinel-Arbeitsbereich, Microsoft Entra ID, Microsoft 365 oder Microsoft Defender sowie PaaS-Ressourcen (Platform-as-a-Service) wie Azure Key Vault zu ermöglichen.

Modell „Privilegierter Zugriff“

Es wird empfohlen, eine Modellstrategie für privilegierten Zugriff zu verwenden, um die Risiken für Ihr Unternehmen durch Angriffe mit hoher Auswirkung und hoher Wahrscheinlichkeit auf privilegierten Zugriff schnell zu verringern. Bei automatischen Prozessen in einem DevOps Modell basieren Sie die Identität auf Dienstprinzipalidentitäten.

Der privilegierte Zugriff sollte in jedem Unternehmen die oberste Sicherheitspriorität haben. Jede Gefährdung dieser Identitäten hat äußerst negative Auswirkungen. Privilegierte Identitäten haben Zugriff auf unternehmenskritische Ressourcen, was fast immer erhebliche Auswirkungen hat, wenn Angreifer diese Konten gefährden.

Die Sicherheit des privilegierten Zugriffs ist von entscheidender Bedeutung, da sie die Grundlage für alle anderen Sicherheitsgarantien bildet. Ein Angreifer, der die Kontrolle über Ihre privilegierten Konten hat, kann alle anderen Sicherheitsgarantien beeinträchtigen.

Aus diesem Grund wird empfohlen, die Dienstprinzipale logisch auf verschiedene Ebenen oder Ebenen zu verteilen, indem Sie einem Prinzip der Mindestberechtigung folgen. Die folgende Abbildung zeigt, wie die Dienstprinzipale je nach Zugriffstyp und erforderlicher Zugriffsart klassifiziert werden.

Dienstprinzipale der Ebene 0

Dienstprinzipale der Ebene 0 verfügen über die höchste Berechtigungsebene. Diese Dienstprinzipale berechtigen jemanden, mandantenweite Verwaltungsgruppen- oder Stammverwaltungsgruppen-Verwaltungsaufgaben als globaler Administrator auszuführen.

Aus Sicherheitsgründen und der Verwaltbarkeit wird empfohlen, für diese Ebene nur einen Dienstprinzipal zu verwenden. Die Berechtigungen für diesen Dienstprinzipal bleiben erhalten. Daher wird empfohlen, nur die erforderlichen Mindestberechtigungen zu gewähren und das Konto überwacht und geschützt zu lassen.

Speichern Sie das Geheimnis oder Zertifikat für dieses Konto sicher in Azure Key Vault. Es wird dringend empfohlen, den Key Vault nach Möglichkeit in einem dedizierten Administratorabonnement zu platzieren.

Dienstprinzipale der Ebene 1

Dienstprinzipale der Ebene 1 sind erhöhte Berechtigungen, die auf Verwaltungsgruppen auf Unternehmensorganisationsebene beschränkt sind. Diese Dienstprinzipale berechtigen jemanden, Abonnements unter der Verwaltungsgruppe zu erstellen, die sich im Gültigkeitsbereich des Bereichs bekennt.

Aus Sicherheitsgründen und der Verwaltbarkeit wird empfohlen, für diese Ebene nur einen Dienstprinzipal zu verwenden. Die Berechtigungen für diesen Dienstprinzipal bleiben erhalten. Daher empfehlen wir dringend, nur die erforderlichen Mindestberechtigungen zu gewähren und das Konto überwacht und geschützt zu lassen.

Speichern Sie das Geheimnis oder Zertifikat für dieses Konto sicher in Azure Key Vault. Es wird dringend empfohlen, den Key Vault nach Möglichkeit in einem dedizierten Administratorabonnement zu platzieren.

Dienstprinzipale der Ebene 2

Dienstprinzipale der Ebene 2 sind auf die Abonnementebene beschränkt. Diese Dienstprinzipale berechtigen eine Person, administrative Aufgaben unter einem Abonnement auszuführen, die als Abonnementbesitzer fungieren.

Aus Sicherheitsgründen und der Verwaltbarkeit wird empfohlen, für diese Ebene nur einen Dienstprinzipal zu verwenden. Die Berechtigungen für diesen Dienstprinzipal bleiben erhalten. Daher empfehlen wir dringend, nur die erforderlichen Mindestberechtigungen zu gewähren und das Konto überwacht und geschützt zu lassen.

Speichern Sie das Geheimnis oder Zertifikat für dieses Konto sicher in Azure Key Vault. Es wird dringend empfohlen, den Key Vault in einer dedizierten administrativen Ressourcengruppe zu platzieren.

Dienstprinzipale der Ebene 3

Dienstprinzipale der Ebene 3 sind auf den Workloadadministrator beschränkt. In einem typischen Szenario ist jede Workload in derselben Ressourcengruppe enthalten. Diese Struktur beschränkt die Dienstprinzipalberechtigungen auf diese Ressourcengruppe.

Aus Sicherheitsgründen und der Verwaltbarkeit wird empfohlen, nur einen Dienstprinzipal pro Workload zu verwenden. Die Berechtigungen für diesen Dienstprinzipal bleiben erhalten. Daher empfehlen wir dringend, nur die erforderlichen Mindestberechtigungen zu gewähren und das Konto überwacht und geschützt zu lassen.

Speichern Sie das Geheimnis oder Zertifikat für dieses Konto sicher in Azure Key Vault. Es wird dringend empfohlen, den Key Vault in einer dedizierten administrativen Ressourcengruppe zu platzieren.

Dienstprinzipale der Ebene 4

Dienstprinzipale der Ebene 4 verfügen über die meisten eingeschränkten Berechtigungen. Diese Dienstprinzipale berechtigen jemanden, administrative Aufgaben auszuführen, die auf eine Ressource beschränkt sind.

Es wird empfohlen, nach Möglichkeit verwaltete Identitäten zu verwenden. Speichern Sie bei nicht verwalteten Identitäten das Geheimnis oder Zertifikat sicher in Azure Key Vault, in dem Geheimnisse der Ebene 3 gespeichert werden.

Optimaler Betrieb

Die Säule „Optimaler Betrieb“ deckt die Betriebsprozesse ab, die für die Bereitstellung einer Anwendung und deren Ausführung in der Produktion sorgen. Weitere Informationen finden Sie unter Übersicht über die Säule „Optimaler Betrieb“.

Microsoft Sentinel-Lösungen bestehen aus drei Blöcken, die vollständige und erfolgreiche Vorgänge sicherstellen.

Der erste Block ist die Umgebungsdefinition, aus der die wesentlichen Architekturelemente besteht. Ihr Hauptanliegen bei diesem Block besteht darin, die Anzahl der bereitzustellenden Produktions- und Nichtproduktionsumgebungen zu berücksichtigen und dann sicherzustellen, dass das Setup in allen Fällen homogen ist.

Der zweite Block ist die Bereitstellung des Microsoft Sentinel-Connectors, bei der Sie die Art der Connectors berücksichtigen, die von Ihrem Team benötigt werden, und die Sicherheitsanforderungen, um sie zu aktivieren.

Der dritte Block ist die Lebenszyklusverwaltung von Microsoft Sentinel-Artefakten, die die Codierung, Bereitstellung und Verwendung oder Zerstörung der Komponenten abdeckt. Dieser Block enthält beispielsweise Analyseregeln, Playbooks, Arbeitsmappen, Bedrohungssuche und so weiter.

Beachten Sie diese Abhängigkeiten zwischen Artefakten:

• Automatisierungsregeln, die in einer Analyseregel definiert sind
• Arbeitsmappen oder Analysen, die eine neue Datenquelle oder einen neuen Connector erfordern
• Verwalten der Updates vorhandener Komponenten
  • Versionierung ihrer Artefakte
  • Identifizieren, Testen und Bereitstellen einer aktualisierten oder vollständig neuen Analyseregel

Erstellen, Testen und Bereitstellen der Infrastruktur

Bei der Verwaltung von Microsoft Sentinel-DevOps ist es wichtig, die Konnektivitäts- und Sicherheitsaspekte Ihrer Unternehmensarchitektur zu berücksichtigen.

Azure DevOps können von Microsoft gehostete Agents oder selbstgehostete Agents zum Erstellen, Testen und Bereitstellen von Aktivitäten verwenden. Abhängig von den Anforderungen Ihres Unternehmens können Sie von Microsoft gehostete, selbstgehostete oder eine Kombination aus beiden Modellen verwenden.

• Von Microsoft gehostete Agents Diese Option ist die schnellste Möglichkeit, mit Azure DevOps-Agents zu arbeiten, da es sich um eine gemeinsame Infrastruktur für Ihre gesamte Organisation handelt. Weitere Informationen zur Verwendung von von Microsoft gehosteten Agents in Ihrer Pipeline finden Sie unter Von Microsoft gehostete Agents. Von Microsoft gehostete Agents können in Hybridnetzwerkumgebungen verwendet werden, um Zugriff auf die IP-Adressbereiche zu gewähren. Informationen zum Herunterladen der IP-Adressbereiche, auf die diese Agents Zugriff gewähren, finden Sie unter Azure-IP-Adressbereiche und Diensttags – Öffentliche Cloud.
• Selbstgehostete Agents. Diese Option bietet Ihnen dedizierte Ressourcen und mehr Kontrolle bei der Installation abhängiger Software für Ihre Builds und Bereitstellungen. Selbstgehostete Agents können über VMs, Skalierungssätze und Container in Azure arbeiten. Weitere Informationen zu selbstgehosteten Agents finden Sie unter Azure Pipelines Agents.

GitHub Runner

GitHub können von GitHub gehostete Runner oder selbstgehostete Runner für Aktivitäten im Zusammenhang mit dem Erstellen, Testen und Bereitstellen verwenden. Abhängig von den Anforderungen Ihres Unternehmens können Sie von Microsoft gehostete, selbstgehostete oder eine Kombination aus beiden Modellen verwenden.

Von GitHub gehostete Runner

Diese Option ist die schnellste Möglichkeit, mit GitHub zu arbeiten, da es sich um eine freigegebene Infrastruktur für eine gesamte Organisation handelt. Weitere Informationen finden Sie unter Informationen zu von GitHub gehosteten Runnern. Von GitHub gehostete Agents funktionieren in Hybridnetzwerkumgebungen gemäß bestimmten Netzwerkanforderungen. Weitere Informationen zu den Netzwerkanforderungen finden Sie unter Unterstützte Runner und Hardwareressourcen.

Selbstgehostete Runner

Diese Option bietet Ihrem Unternehmen eine dedizierte Ressourceninfrastruktur. Selbstgehostete Runner arbeiten über VMs und Container in Azure und unterstützen die automatische Skalierung.

Überlegungen zur Auswahl von Runnern

Berücksichtigen Sie bei der Auswahl von Optionen für die Agents und Runner in Ihrer Microsoft Sentinel-Lösung die folgenden Anforderungen:

• Benötigt Ihr Unternehmen dedizierte Ressourcen zum Ausführen von Prozessen in Ihren Microsoft Sentinel-Umgebungen?
• Möchten Sie die Ressourcen für DevOps-Aktivitäten in der Produktionsumgebung von den übrigen Umgebungen isolieren?
• Müssen Sie bestimmte Fälle testen, die Zugriff auf kritische Ressourcen oder Ressourcen erfordern, die nur in einem internen Netzwerk verfügbar sind?

Orchestrierung und Automatisierung von Releaseprozessen

Sie können den Bereitstellungsprozess mit einem Azure DevOps oder GitHub einrichten. Azure DevOps unterstützt die Verwendung einer YAML-Pipeline oder einer Releasepipeline. Weitere Informationen zur Verwendung einer YAML-Pipeline in Azure DevOps finden Sie unter Azure Pipelines verwenden. Weitere Informationen zur Verwendung einer Releasepipeline in Azure DevOps finden Sie unter Releasepipelines. Weitere Informationen zur Verwendung von GitHub mit GitHub-Aktionen finden Sie unter Grundlegendes zu GitHub-Aktionen.

Azure DevOps

Sie können die folgenden Bereitstellungsaktivitäten in einer Azure DevOps-Bereitstellung tun.

• Verwenden Sie eine YAML-Pipeline, um automatisch PR-Genehmigungen auszulösen oder bei Bedarf auszuführen.
• Verwalten Sie Dienstverbindungen für verschiedene Umgebungen mithilfe von Azure DevOps-Gruppen.
• Richten Sie in Ihren kritischen Umgebungen Bereitstellungsgenehmigungen ein, indem Sie das Dienstverbindungsfeature verwenden und Azure DevOps Benutzerberechtigungen in Ihrem Team zuweisen.

GitHub

Sie können die folgenden Bereitstellungsaktivitäten in einer Azure DevOps-Bereitstellung tun.

• Verwenden GitHub zum Erstellen von PRs oder Bereitstellungsaktivitäten.
• Verwalten Von Dienstprinzipalanmeldeinformationen mit GitHub-Geheimnissen.
• Integrieren Sie die Genehmigung der Bereitstellung über den Workflow, der dem GitHub zugeordnet ist.

Automatische Bereitstellung mit der Microsoft Sentinel-Infrastruktur

Je nach Unternehmensarchitektur können Sie eine oder mehrere Microsoft Sentinel-Umgebungen bereitstellen:

• Organisationen, die mehrere Instanzen in ihrer Produktionsumgebung benötigen, können für jeden geografischen Standort unterschiedliche Abonnements auf demselben Mandanten einrichten.
• Eine zentralisierte Instanz in der Produktionsumgebung ermöglicht den Zugriff auf eine oder mehrere Organisationen im gleichen Mandanten.
• Gruppen, die mehrere Umgebungen wie Produktion, Präproduktion, Integration und so weiter benötigen, können sie nach Bedarf erstellen und zerstören.

Definitionen der physischen und logischen Umgebung

Beim Einrichten ihrer Umgebungsdefinitionen haben Sie zwei Möglichkeiten: physisch oder logisch. Beide haben unterschiedliche Optionen und Vorteile:

• Physische Definition: Die Elemente der Microsoft Sentinel-Architektur werden mit den folgenden Optionen für Infrastructure-as-Code (IaC) definiert:
  • Bicep-Vorlagen
  • Azure Resource Manager-Vorlagen (ARM-Vorlagen)
  • Terraform
• Logische Definition: Dies fungiert als Abstraktionsschicht zum Einrichten verschiedener Teams in der Gruppe und zum Definieren ihrer Umgebungen. Die Definition wird in der Bereitstellungspipeline und den Workflows als Eingabe für die Buildumgebung mithilfe der physischen Infrastrukturebene festgelegt.

Berücksichtigen Sie diese Punkte, wenn Sie Ihre logischen Umgebungen definieren:

• Benennungskonventionen
• Umgebungsidentifikationen
• Connectors und Konfigurationen

Coderepository

Berücksichtigen Sie bei den im vorherigen Abschnitt gezeigten Umgebungsansätzen die folgenden GitHub Coderepositoryorganisation.

Physische Definition: Denken Sie basierend auf IaC-Optionen an einen Ansatz, bei dem einzelne Moduldefinitionen verwendet werden, die in der Hauptbereitstellungsdefinition verknüpft sind.

Das folgende Beispiel zeigt, wie Ihr Code organisiert werden kann.

Beschränken Sie den Zugriff auf dieses Repository auf das Team, das die Architektur auf physischer Ebene definiert, um eine homogene Definition in der Unternehmensarchitektur sicherzustellen.

Sie können die Verzweigungs- und Zusammenführungsstrategie an die Bereitstellungsstrategie für jede Organisation anpassen. Wenn Ihr Team mit der Definition beginnen muss, finden Sie weitere Informationen unter Adopt a Git branching strategy (Übernehmen einer Git-Verzweigungsstrategie).

Weitere Informationen zu ARM-Vorlagen finden Sie unter Verwenden von verknüpften und geschachtelten Vorlagen bei der Bereitstellung von Azure-Ressourcen.

Weitere Informationen zum Einrichten von Bicep-Umgebungen finden Sie unter Installieren von Bicep-Tools. Weitere Informationen zum GitHub finden Sie unter GitHub Flow.

Logische Definitionen definieren die Umgebungen eines Unternehmens. Das Git-Repository sammelt die verschiedenen Definitionen für ein Unternehmen.

Das folgende Beispiel zeigt, wie Ihr Code organisiert werden kann.

Das Repository spiegelt die PR-Aktionen wider, die von verschiedenen Teams durchgeführt werden. Mehrere Umgebungen werden von verschiedenen Teams definiert und von den Besitzern oder genehmigenden Genehmigenden des Unternehmens genehmigt.

Die Berechtigungsstufe zum Ausführen einer Umgebungsbereitstellung ist Ebene 2. Diese Ebene stellt sicher, dass die Ressourcengruppe und die Ressourcen für die Umgebung mit der erforderlichen Sicherheit und dem erforderlichen Datenschutz erstellt werden. Diese Ebene legt auch die Benutzerberechtigungen für zulässige Aktionen in Produktionsumgebungen, in der Produktion und in der Präproduktion fest.

Organisationen, die Umgebungen nach Bedarf für Tests und Entwicklung benötigen und die Möglichkeit haben, die Umgebungen nach Abschluss ihrer Tests dann zu zerstören, können eine Azure DevOps-Pipeline oder GitHub implementieren. Sie können geplante Trigger festlegen, um die Umgebungen nach Bedarf zu zerstören, indem Azure DevOps-Ereignisse oder GitHub werden.

Automatische Konfiguration von Microsoft Sentinel-Connectors

Microsoft Sentinel-Connectors sind ein wesentlicher Bestandteil der Lösung, die das Herstellen einer Verbindung mit verschiedenen Elementen in der Unternehmensarchitektur unterstützt, z. B. Microsoft Entra ID, Microsoft 365, Microsoft Defender, Threat Intelligence-Plattformlösungen usw.

Beim Definieren einer Umgebung ermöglicht die Konfiguration der Connectors das Einrichten von Umgebungen mit homogenen Konfigurationen.

Das Aktivieren von Connectors als Teil des DevOps muss vom Dienstprinzipalebenenmodell unterstützt werden. Dieser Fokus stellt die richtige Berechtigungsebene sicher, wie in der folgenden Tabelle gezeigt.

Connectorszenario	Modell „Privilegierter Zugriff“ – Ebene	Azure – geringste Rechte	Workflowgenehmigung erforderlich
Microsoft Entra ID	Stufe 0	globaler Administrator oder Sicherheitsadministrator	Empfohlen
Microsoft Entra ID Protection	Stufe 0	globaler Administrator oder Sicherheitsadministrator	Empfohlen
Microsoft Defender for Identity	Stufe 0	globaler Administrator oder Sicherheitsadministrator	Empfohlen
Microsoft Office 365	Stufe 0	globaler Administrator oder Sicherheitsadministrator	Empfohlen
Microsoft Cloud App Security	Stufe 0	globaler Administrator oder Sicherheitsadministrator	Empfohlen
Microsoft Defender XDR	Stufe 0	globaler Administrator oder Sicherheitsadministrator	Empfohlen
Microsoft Defender für IoT	Ebene 2	Mitwirkender	Empfohlen
Microsoft Defender für Cloud	Ebene 2	Sicherheitsleseberechtigter	Optional
Azure-Aktivität	Ebene 2	Abonnementleser	Optional
Threat Intelligence-Plattformen	Stufe 0	globaler Administrator oder Sicherheitsadministrator	Empfohlen
Sicherheitsereignisse	Ebene 4	Keine	Optional
syslog	Ebene 4	Keine	Optional
DNS (Vorschau)	Ebene 4	Keine	Optional
Windows-Firewall	Ebene 4	Keine	Optional
Windows-Sicherheitsereignisse über AMA	Ebene 4	Keine	Optional

Bereitstellung von Microsoft Sentinel-Artefakten

Bei der Implementierung von Microsoft Sentinel-Artefakten gewinnen DevOps an Relevanz, da jedes Unternehmen mehrere Artefakte erstellt, um Angriffe zu verhindern und zu beheben.

Die Implementierung der Artefakte kann in der Verantwortung eines Teams oder mehrerer Teams stehen. Die automatische Build- und Artefaktbereitstellung ist häufig die gängigste Prozessanforderung und bestimmt den Ansatz und die Bedingungen für Ihre Agents und Runner.

Die Bereitstellung und Verwaltung von Microsoft Sentinel-Artefakten erfordert die Verwendung der Microsoft Sentinel-REST-API. Weitere Informationen finden Sie unter Microsoft Sentinel REST API. Das folgende Diagramm zeigt eine Azure DevOps Pipeline auf einem Azure-REST-API-Stapel.

Sie können Ihr Repository auch mithilfe von PowerShell implementieren.

Wenn Ihr Team MITRE verwendet, sollten Sie erwägen, die verschiedenen Artefakte zu klassifizieren und die Taktiken und Techniken für die einzelnen Artefakte anzugeben. Stellen Sie sicher, dass Sie eine entsprechende Metadatendatei für jeden Artefakttyp einschließen.

Wenn Sie beispielsweise ein neues Playbook mithilfe einer Azure ARM-Vorlage erstellen und der Dateiname Playbook.arm.json lautet, fügen Sie eine JSON-Datei mit dem Namen Playbook.arm.mitre.json hinzu. Die Metadaten für diese Datei enthalten dann die CSV-, JSON- oder YAML-Formate, die den von Ihnen verwendeten MITRE-Taktiken oder -Techniken entsprechen.

Durch Befolgen dieser Vorgehensweise kann Ihr Team Ihre MITRE-Abdeckung basierend auf den Aufträgen auswerten, die während des Setups für die verschiedenen Artefakttypen ausgeführt werden, die Sie verwenden.

Build-Artefakte

Das Ziel Ihres Buildprozesses besteht darin, sicherzustellen, dass Sie Artefakte mit der höchsten Qualität generieren. Das folgende Diagramm zeigt einige der Buildprozessaktionen, die Sie ausführen können.

Laden Sie eine Visio-Datei dieser Architektur herunter.

• Sie können Ihre Artefaktdefinition auf einem beschreibenden Schema im JSON- oder YAML-Format basieren und dann das Schema überprüfen, um Syntaxfehler zu vermeiden.
  • Validieren Sie Ihre ARM-Vorlagen mit dem ARM-Vorlagen-Test-Toolkit.
  • Überprüfen Sie Ihre YAML- und JSON-Dateien mithilfe von PowerShell auf benutzerdefinierte Modelle.
• Überprüfen Sie ihre Watchlisteinstellungen und stellen Sie sicher, dass die von Ihnen definierten CIDR-Datensätze (Classless Inter-Domain Routing) dem richtigen Schema folgen, z. B. 10.1.0.0/16.
• Verwenden Sie KQL-Abfragen (Keyword Query Language), die Sie auf Syntaxebene überprüfen können, für Analyseregeln, Hunting-Regeln und Livestreamregeln, die Sie auf Syntaxebene überprüfen können.
• Machen Sie die lokale KQL-Validierung zu einer Option.
• Integrieren Sie das KQL-Inlinevalidierungstool in die DevOps Pipeline.
• Wenn Sie Logik implementieren, die auf PowerShell für Azure Automation basiert, können Sie die Syntaxvalidierung und Komponententests mithilfe der folgenden Elemente einschließen:
  • Pester
  • PSScriptAnalyzer
• Generieren Sie den MITRE-Manifestmetadatenbericht basierend auf den Metadatendateien, die in den Artefakten enthalten sind.

Exportieren von Artefakten

In der Regel arbeiten mehrere Teams über mehrere Microsoft Sentinel-Instanzen, um die erforderlichen Artefakte zu generieren und zu überprüfen. Mit dem Ziel, vorhandene Artefakte wiederzuverwenden, kann Ihr Unternehmen automatische Prozesse einrichten, um die Artefaktdefinitionen aus vorhandenen Umgebungen zu erhalten. Automation kann auch Informationen zu allen Artefakten bereitstellen, die während des Setups von verschiedenen Entwicklungsteams erstellt werden.

Das folgende Diagramm zeigt einen Beispielprozess für die Artefaktextraktion.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Bereitstellen von Artefakten

Die Ziele Ihres Bereitstellungsprozesses sind:

• Verkürzen Sie die Markteinführungszeit.
• Steigern Sie die Leistung für mehrere Teams, die an der Einrichtung und Verwaltung Ihrer Lösung beteiligt sind.
• Richten Sie Integrationstests ein, um die Integrität der Umgebung auszuwerten.

Entwicklungsteams verwenden den Prozess, um sicherzustellen, dass sie Anwendungsfälle für Artefakte bereitstellen, testen und überprüfen können, die sich in der Entwicklung befinden. Die Architektur- und SOC-Teams überprüfen die Pipelinequalität in QA-Umgebungen und arbeiten mit den Integrationstests für Angriffsszenarien. In den Testfällen kombiniert ein Team in der Regel verschiedene Artefakte als Analyseregeln, Korrekturplaybooks, Watchlists und so weiter. Ein Teil jedes Anwendungsfalls umfasst das Simulieren von Angriffen, bei denen die gesamte Kette anhand von Erfassung, Erkennung und Behebung ausgewertet wird.

Das folgende Diagramm zeigt die Bereitstellungsprozesssequenz, die sicherstellt, dass Ihre Artefakte in der richtigen Reihenfolge bereitgestellt werden.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Die Verwaltung von Sentinel-Artefakten als Code bietet Ihnen flexible Möglichkeiten, Ihre Vorgänge zu verwalten und die Bereitstellung in einer CI/CD-DevOps automatisieren.

Microsoft-Lösungen bieten Automatisierungsworkflows für die folgenden Artefakte.

Artefakt	Automatisierungsworkflows
Watchlists	Code Review Schemaüberprüfung Bereitstellung Erstellen, Aktualisieren, Löschen von Watchlists und Elementen
Fusion von Analyseregeln Microsoft Security ML-Verhaltensanalyse Anomalie Geplant	Code Review KQL-Syntaxüberprüfung Schemavalidierung Pester Bereitstellung Erstellen, Aktivieren, Aktualisieren, Löschen, Exportieren Unterstützung von Warnungsvorlagen
Automatisierungsregeln	Code Review Schemavalidierung Bereitstellung Erstellen, Aktivieren, Aktualisieren, Löschen, Exportieren
Connectors	Code Review Schemavalidierung Bereitstellung Aktionen: Aktivieren, Löschen (Deaktivieren), Aktualisieren
Hunting-Regeln	Code Review KQL-Syntaxüberprüfung Schemavalidierung Pester Bereitstellung Aktionen: Erstellen, Aktivieren, Aktualisieren, Löschen, Exportieren
Playbooks	Code Review TTK Bereitstellung Aktionen: Erstellen, Aktivieren, Aktualisieren, Löschen, Exportieren
Arbeitsmappen	Bereitstellung Aktionen: Erstellen, Aktualisieren, Löschen
Runbooks	Code Review Validierung der PowerShell-Syntax Pester Bereitstellung Aktionen: Erstellen, Aktivieren, Aktualisieren, Löschen, Exportieren

Abhängig von der von Ihnen bestimmten Automatisierungssprache werden einige Automatisierungsfunktionen möglicherweise nicht unterstützt. Das folgende Diagramm zeigt, welche Automatisierungsfunktionen von der Sprache unterstützt werden.

* Features in der Entwicklung, die noch nicht dokumentiert sind
** Automatisierungsmethoden, die von Microsoft Operational Insights- oder Microsoft Insights-Ressourcenanbieter-APIs unterstützt werden

Azure Automation

Das folgende Diagramm zeigt die Komponenten der Vereinfachung des Microsoft Sentinel-Zugriffs mit einer verwalteten Dienstidentität.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Wenn Sie Zugriff auf andere Ressourcen gewähren müssen, verwenden Sie die verwaltete Identität, die eine eindeutige Identität für alle kritischen Vorgänge sicherstellt.

Verwenden Azure Automation zum Einrichten von Playbooks. Verwenden Sie PowerShell-Skripts für die folgenden komplexen Aufgaben und Automatisierungsfeatures:

• Integration in Drittanbieterlösungen, bei denen verschiedene Ebenen von Anmeldeinformationen erforderlich sind und die auf Microsoft Entra ID oder benutzerdefinierten Anmeldeinformationen basieren:
  • Microsoft Entra-Benutzeranmeldeinformationen
  • Microsoft Entra-Dienstprinzipalanmeldeinformationen
  • Zertifikatauthentifizierung
  • Benutzerdefinierte Anmeldeinformationen
  • Verwaltete Identität
• Implementieren einer Lösung, die Organisationsskripts wiederverwendet, oder Lösungen, die die Verwendung von PowerShell-Befehlen erfordern, um komplexe Übersetzungen in Playbooks zu vermeiden:
  • PowerShell-basierte Lösungen
  • Python-basierte Lösungen
• Implementieren von Lösungen in Hybridszenarien, bei denen sich Korrekturaktionen auf Ihre Cloud- und lokalen Ressourcen auswirken können.

Microsoft Sentinel-Repositorys

Erfahrene DevOps können erwägen, Microsoft Sentinel in Infrastructure as Code (IaC) mit CI/CD-Pipelines zu verwalten, die in Azure DevOps. Produktgruppen verstehen die Herausforderungen, vor denen Kunden und Partner beim Erstellen Azure DevOps Sicherheitsarchitektur stehen, sodass die folgenden beiden Initiativen helfen können:

• Dokumentation der Referenzarchitektur
• Entwickeln einer neuen Lösung, die auf der Ignite 2021 angekündigt wurde und als „Microsoft Sentinel-Repositorys“ bezeichnet wird

Um die Auswahl der Lösung zu unterstützen, die den Anforderungen Ihres Teams entspricht, werden in der folgenden Tabelle die funktionalen und technischen Kriterien verglichen.

Anwendungsfall und Funktionen	Azure DevOps und GitHub benutzerdefinierter Ansatz	Microsoft Sentinel-Repositorys
Wir möchten schnell mit der Bereitstellung von Microsoft Sentinel-Artefakten beginnen, ohne Zeit damit zu verbringen, Azure DevOps-Architekturkomponenten wie Agents, Pipelines, Git, Dashboards, ein Wiki, Dienstprinzipale, RBACs, Überwachung und so weiter zu definieren.	Nicht empfohlen	Empfohlen
Für die Verwaltung der CI/CD-Pipelines verfügen wir über kleine Teams und geringe Qualifikationen.	Nicht empfohlen	Empfohlen
Wir möchten alle Sicherheitsaspekte der CI/CD-Pipelines steuern und verwalten.	Unterstützt	Nicht unterstützt
Wir müssen Gates und Verzweigungen für die Überwachung der Integration integrieren, bevor Entwickler Bereitstellungspipelines wie Quellcodeverwaltung, Codierungsüberprüfung, Rollback, Workflowgenehmigung und so weiter auslösen können.	Unterstützt	Teilweise unterstützt
Wir verfügen über eine angepasste Git- oder Repositorystruktur.	Unterstützt	Unterstützt
Wir verwenden keine Resource Manager- oder Bicep-IaC-Sprachen, um Artefakte zu erstellen.	Unterstützt	Nicht unterstützt
Wir möchten die Bereitstellung von Artefakten in mehreren Microsoft Sentinel-Arbeitsbereichen in einem einzelnen Microsoft Entra-Mandanten zentral verwalten.	Unterstützt	Unterstützt
Wir möchten CI/CD-Pipelines (Continuous Integration und Continuous Delivery) über mehrere Microsoft Entra-Mandanten hinweg integrieren oder erweitern.	Unterstützt	Unterstützt
Wir verfügen über Playbooks mit unterschiedlicher Parametrisierung, abhängig von Abonnement, Standort, Umgebung usw.	Unterstützt	TBD, zu dokumentierende Richtlinien
Wir möchten verschiedene Artefakte in dasselbe Repository integrieren, um Anwendungsfälle zu erstellen.	Unterstützt	Unterstützt
Wir möchten die Möglichkeit haben, Artefakte massenweise zu entfernen.	Unterstützt	Nicht unterstützt

Verfügbarkeit, Leistung und Skalierbarkeit

Berücksichtigen Sie bei der Auswahl der Architektur für die Azure DevOps Agents in Ihrem Unternehmen für Microsoft Sentinel-Szenarien die folgenden Anforderungen:

• Die Produktionsumgebung erfordert möglicherweise einen dedizierten Agentpool für Vorgänge über die Microsoft Sentinel-Umgebung.
• Nicht-Produktionsumgebungen können den Agentpool mit einer großen Anzahl von Instanzen gemeinsam nutzen, um die unterschiedlichen Anforderungen der Teams zu erfüllen, insbesondere für CI/CD-Methoden.
  • Szenarien für die Angriffssimulation sind ein Sonderfall, in dem dedizierte Agents erforderlich sein können. Überlegen Sie, ob ein dedizierter Pool für Ihre Testanforderungen erforderlich ist.
• Organisationen, die hybride Netzwerkszenarien verwenden, können die Integration der Agents in das Netzwerk in Betracht ziehen.

Organisationen können eigene Images für Agents erstellen, die auf Containern basieren. Weitere Informationen finden Sie unter Ausführen eines selbstgehosteten Agenten in Docker.

Mandantenübergreifende Microsoft Sentinel-Verwaltung mit Azure DevOps

Als globaler SOC oder MSSP müssen Sie möglicherweise mehrere Mandanten verwalten. Azure Lighthouse unterstützt die gleichzeitige Durchführung skalierter Vorgänge auf mehreren Microsoft Entra-Mandanten, wodurch die Effizienz Ihrer Verwaltungsaufgaben erhöht wird. Weitere Informationen finden Sie unter Azure Lighthouse – Übersicht.

Die mandantenübergreifende Verwaltung ist in den folgenden Szenarien besonders effektiv:

• Verwalten von Microsoft Sentinel-Ressourcen in Kundenmandanten
• Verfolgen von Angriffen und Anzeigen von Sicherheitswarnungen für mehrere Mandanten
• Anzeigen von Vorfällen in mehreren Microsoft Sentinel-Arbeitsbereichen in verschiedenen Mandanten

Methoden zum Onboarding von Kunden

Sie haben zwei Optionen zum Integrieren von Kunden: ein Angebot für verwaltete Dienste und eine ARM-Vorlage.

Manuelles Onboarding mithilfe einer ARM-Vorlage

Wenn Sie kein Angebot auf dem Azure Marketplace als Dienstanbieter veröffentlichen möchten oder nicht alle Anforderungen erfüllen, können Sie Kunden manuell mit Hilfe von ARM-Vorlagen einbinden. Dies ist die wahrscheinlichste Option in einem Unternehmensszenario, in dem dasselbe Unternehmen über mehrere Mandanten verfügt.

In der folgenden Tabelle werden die Onboardingmethoden verglichen.

Aspekt	Angebot eines verwalteten Diensts	ARM-Vorlagen
Erfordert ein Partner Center-Konto	Ja	Nein
Erfordert den Silver- oder Gold-Cloudplattform-Kompetenzgrad oder den MSP-Status (Azure Expert Managed Services Provider).	Ja	Nein
Verfügbar für neue Kunden über Azure Marketplace	Ja	Nein
Das Angebot kann auf bestimmte Kunden beschränkt werden	Ja (nur bei privaten Angeboten, die nicht mit Abonnements genutzt werden können, die über einen Wiederverkäufer des CSP-Programms abgeschlossen wurden)	Ja
Erfordert Kundenakzeptanz im Azure-Portal	Ja	Nein
Kann die Automatisierung nutzen, um das Onboarding für mehrere Abonnements, Ressourcengruppen oder Kunden durchzuführen	Nein	Ja
Bietet sofortigen Zugriff auf neue integrierte Rollen und Azure Lighthouse-Features	Nicht immer (im Allgemeinen nach einiger Verzögerung verfügbar)	Ja

Weitere Informationen zum Veröffentlichen von Angeboten für verwaltete Dienste finden Sie unter Veröffentlichen eines Angebots für verwaltete Dienste in Azure Marketplace.

Weitere Informationen zum Erstellen einer ARM-Vorlage finden Sie unter Erstellen und Bereitstellen von ARM-Vorlagen.

Das folgende Diagramm zeigt die architekturübergreifende Integration zwischen einem MSSP-Mandanten und den Ressourcenanbietermandanten eines Kunden mit Azure Lighthouse und Microsoft Sentinel.

Laden Sie eine Visio-Datei dieser Architektur herunter.

1. Ein MSP-Angebot ist über eine ARM-Vorlage oder ein Azure Marketplace-Dienstangebot integriert.
2. Die delegierte Azure-Ressourcenverwaltung überprüft, ob die Anforderung von einem Partnermandanten stammt, und ruft einen verwalteten Dienstanbieter auf.
3. Der Ressourcenanbieter für verwaltete Dienste verwendet RBAC, um den Zugriff des MSP zu steuern.
4. Der MSP schließt SecOps-Aktionen für eine Kundenressource ab.
5. Beim Abrechnungsprozess werden Ausgaben als Kundengebühren behandelt. Eine getrennte Abrechnung ist möglich, wenn Kundenentitäten über separate Arbeitsbereiche im gleichen Microsoft Entra-Mandanten verfügen.
6. Die Sicherheit und Hoheit der Daten hängt von der Mandantengrenze des Kunden ab.

Identifikation über mehrere Mandanten hinweg

Um Microsoft Sentinel mit Azure DevOps zu verwalten, bewerten Sie die folgenden Entwurfsentscheidungen für die Komponenten.

Anwendungsfall	Vorteile
Globale Identität für die Verwaltung von DevOps-Aktionen, einzelner Dienstprinzipal	Dieser Fall gilt für globale Bereitstellungsprozesse, die alle Mandanten umfassen. Die Verwendung einer einheitlichen Identität erleichtert den Zugriff für die verschiedenen Mandanten, kann aber die Verwaltung von Genehmigungsaktionen für bestimmte Mandanten komplex machen. Der Schutzmechanismus und das Autorisierungsmodell für diese Art von Identität sind ebenfalls sehr wichtig, um eine nicht autorisierte Nutzung aufgrund der damit verbundenen globalen Auswirkungen zu vermeiden.
Dedizierte Identität für die Verwaltung DevOps-Aktionen, mehrere Dienstprinzipale	Dieser Fall gilt, wenn Bereitstellungsprozesse für jeden Mandanten oder jede Mandantenaktion dedizierend sind und eine Genehmigung erforderlich ist. In diesem Fall ist die Empfehlung zum Schützen und Autorisieren dieser Identitätsverwendung identisch mit der Empfehlung im globalen Fall, auch wenn die Auswirkungen reduziert werden.

Aufbau des Code-Repositorys

Anwendungsfall	Vorteile
Einheitliches Repository mit einer einzelnen Codeversion für alle Mandanten	Dieser Fall erleichtert einheitliche Versionen für den Code im Repository. In diesem Fall kann bei einer einheitlichen Version des Codes, der eine bestimmte Version für den Mandanten verwaltet, Unterstützung über Branches für jeden Fall erforderlich sein.
Einheitliches Repository mit bestimmten Code-Ordnern nach Mandant.	Dieser Fall ergänzt den Fall eines einzelnen Repositorys. Hier kann eine Ordnerstruktur dedizierte Artefakte nach Mandant aufteilen.
Dediziertes Repository nach Mandant	Dieser Ansatz bietet Isolation bei der Verwaltung von Code-Artefakten. Es erleichtert die Entwicklung zwischen Mietern mit unterschiedlichen Teams oder Anforderungen. Das Konsolidieren von Änderungen erfordert die Einrichtung eines Prozesses zwischen Repositorys, der ggf. Wartungsaufwand erfordert.

Build- und Bereitstellungsprozessen

Anwendungsfall	Vorteile
Einzelner Buildprozess für alle Mandanten	Wenn alle Mandanten mit derselben Version der Artefakte arbeiten, ist dies die einfachste Option zum Implementieren der Generierung und des Pakets.
Buildprozess nach Mandant	Für jeden Mandanten wird eine andere Version des Codes bereitgestellt.
Globaler Bereitstellungsprozess für alle Mandanten	Neue Bereitstellungen und Updates für Bereitstellungen gelten für alle Mandanten. Die Schritte des Bereitstellungs- und Aktualisierungsprozesses werden für alle Mandanten verwendet.
Globaler Bereitstellungsprozessmandant nach Mandant	Neue Bereitstellungen und Aktualisierungen von Bereitstellungen gelten für einen oder mehrere Mandanten.
Dedizierter Bereitstellungsprozess nach Mandant	Der Bereitstellungsprozess wird für jeden Mandanten angepasst.

Kostenoptimierung

Bei der Kostenoptimierung geht es darum, unnötige Ausgaben zu reduzieren und die Betriebseffizienz zu verbessern. Weitere Informationen finden Sie unter Übersicht über die Säule „Kostenoptimierung“.

Die Kosten der Lösung hängen von den folgenden Faktoren ab:

• Die Menge der Daten, die Ihr Unternehmen monatlich in den Microsoft Sentinel Log Analytics-Arbeitsbereich einspeist
• Die von Ihnen gewählten Verpflichtungstarife oder Abrechnungsmethoden, z. B. „Pay-as-You-Go“ (PAYG)
• Die Aufbewahrungsrate der Datenrichtlinien auf Tabellen- oder globaler Ebene

Weitere Informationen finden Sie in der Azure-Aufbewahrung nach Datentyp.

Informationen zum Berechnen der Preise finden Sie im Microsoft Sentinel-Preisrechner. Weitere Informationen zu den erweiterten Preisüberlegungen und -beispielen finden Sie unter Planen von Kosten für Microsoft Sentinel.

Sie können zusätzliche Kosten verursachen, wenn Sie Ihre Lösung um die folgenden Komponenten erweitern:

• Playbooks: Runtimes für Azure Logic Apps und Azure Functions. Weitere Informationen finden Sie unter Preise.
• Exportieren in externen Speicher wie Azure Data Explorer, Event Hubs oder ein Azure Storage-Konto.
• Ein Machine Learning-Arbeitsbereich und die Compute-Komponente, die von einer Jupyter Notebook Komponente verwendet wird.

Bereitstellen dieses Szenarios

Im folgenden Abschnitt werden die Schritte zum Bereitstellen dieses Szenarios in Form eines Beispiel-Anwendungsfalls beschrieben, der die verschiedenen DevOps Prozesse abdeckt.

Erstellen und Veröffentlichen des Microsoft Sentinel-Frameworks

Richten Sie zunächst die erforderlichen NuGet Komponenten in einem dedizierten Repository ein, in dem verschiedene Prozesse die von Ihnen generierten Releases nutzen können.

Wenn Sie mit Azure DevOps arbeiten, können Sie einen Komponentenfeed erstellen, um die verschiedenen NuGet Pakete aus dem Microsoft Sentinel-Framework für PowerShell zu hosten. Weitere Informationen finden Sie unter Erste Schritte mit NuGet-Paketen.

Wenn Ihr Team eine GitHub-Registrierung ausschließt, können Sie sie als NuGet Repository verbinden, da sie mit dem Feedprotokoll kompatibel ist. Weitere Informationen finden Sie unter Einführung in GitHub-Pakete.

Wenn Sie über ein NuGet Repository verfügen, enthält die Pipeline eine Dienstverbindung für NuGet. Diese Screenshots zeigen die Konfiguration für die neue Dienstverbindung mit dem Namen Microsoft Sentinel NuGet Framework Connection.

Nach dem Konfigurieren des Feeds können Sie die Pipeline zum Erstellen des PowerShell-Frameworks direkt aus GitHub in einer bestimmten Verzweigung importieren. Weitere Informationen finden Sie unter Konfigurieren von Repositorys. In diesem Fall erstellen Sie eine neue Pipeline und wählen GitHub als Codequelle aus.

Eine weitere Möglichkeit besteht darin, das Git-Repository als Azure DevOps Repository zu importieren, das auf Git basiert. In beiden Fällen geben Sie zum Importieren der Pipeline den folgenden Pfad an:

src/Build/Framework/ADO/Microsoft.Sentinel.Framework.Build.yml

Sie können jetzt die Pipeline erstmalig ausführen. Anschließend wird das Framework erstellt und für den NuGet Feed veröffentlicht.

Definieren Ihrer Microsoft Sentinel-Umgebung

Wenn Sie mit Microsoft Sentinel beginnen und diese Beispiele verwenden, definieren Sie die Umgebung in Ihrem Unternehmen, z. B. Umgebung als Code oder EaC. Sie geben jeweils die verschiedenen Elemente an, aus denen sich die Umgebung zusammensetzt.

Die Microsoft Sentinel-Architektur umfasst die folgenden Elemente in Azure:

• Log Analytics-Arbeitsbereich: Dieser Arbeitsbereich bildet die Grundlage der Lösung. Sicherheitsbezogene Informationen werden hier gespeichert, und der Arbeitsbereich ist die Engine für Kusto Query Language (KQL).
• Microsoft Sentinel-Lösung über den Log Analytics-Arbeitsbereich: Diese Lösung erweitert die Funktionalität des Log Analytics-Arbeitsbereichs um SIEM- und SOAR-Funktionen.
• Key Vault: Der Key Vault speichert die Geheimnisse und Schlüssel, die während der Wiederherstellungsprozesse verwendet werden.
• Automation-Konto: Dieses Konto ist optional und wird für die Korrekturprozesse verwendet. Der von Ihnen genutzte Wiederherstellungsprozess basiert auf den PowerShell- und Python-Runbooks. Der Prozess umfasst eine vom System verwaltete Identität, die mit verschiedenen Ressourcen gemäß den bewährten Methoden funktioniert.
• Benutzerverwaltete Identität: Dieses Feature fungiert als einheitliche Microsoft Sentinel-Identitätsebene, die Interaktionen zwischen Microsoft Sentinel-Playbooks und Runbooks verwaltet.
• Logik-App-Verbindungen: Dies sind Verbindungen für Microsoft Sentinel, den Key Vault und die Automatisierung, die die vom Benutzer verwaltete Identität verwenden.
• Externe Logik-App-Verbindungen: Dies sind Verbindungen für externe Ressourcen, die an den Korrekturprozessen beteiligt sind und auf den Playbooks basieren.
• Azure Event Hubs: Dieses Feature ist optional und übernimmt die Integration zwischen Microsoft Sentinel und anderen Lösungen wie Splunk, Azure Databricks und Machine Learning sowie Resilient.
• Speicherkonto: Dieses Feature ist optional und übernimmt die Integration zwischen Microsoft Sentinel und anderen Lösungen wie Splunk, Azure Databricks und Machine Learning sowie Resilient.

Anhand von Beispielen aus dem Repository können Sie die Umgebung mit JSON-Dateien definieren, um die verschiedenen logischen Konzepte anzugeben. Die Optionen, die zum Definieren der Umgebung verfügbar sind, können literal oder automatisch sein.

In einer Literaldefinition geben Sie den Namen und die Elemente für jede Ressource in der Umgebung an, wie in diesem Beispiel gezeigt.

{
    {
        "SubscriptionId": "<subscription-identifier-associated-with-service-connection>",
        "Name": "<environment-name>",
        "NamingConvention": "<naming-convention-template-for-automatic-cases>",
        "Location": "<environment-location>",
        "ResourceGroup": {
            "Type": "Literal",
            "ResourceGroupName": "<resource-group-name>"
         }
    },
    "Resources":
    {
        "Sentinel":
        {
            "Type": "Literal",
            "LogAnalyticsWorkspaceName": "<Log-Analytics-workspace-name>",
            "ManagedIdentityName": "<user-managed-identity-name>",
            "SentinelConnectionName": "<Sentinel-API-connection-name>",
            "KeyVaultName": "<Key-Vault-name>",
            "KeyVaultConnectionName": "<Key-Vault-API-connection-name>"
        },
        "Automation":
        {
            "Type": "Literal",
            "AutomationAccountName": "<automation-account-name>",
            "AutomationAccountConnectionName": "<automation-account-API-connection-name>"
        },
        "Integration":
        {
            "Type": "Literal",
            "EventHubNamespaces": [
                "<Event-Hubs-namespace-1-name>",
                "<Event-Hubs-namespace-2-name>",
                "<Event-Hubs-namespace-3-name>",
                "<Event-Hubs-namespace-4-name>",
                "<Event-Hubs-namespace-5-name>",
                "<Event-Hubs-namespace-6-name>",
                "<Event-Hubs-namespace-7-name>",
                "<Event-Hubs-namespace-8-name>",
                "<Event-Hubs-namespace-9-name>",
                "<Event-Hubs-namespace-10-name>",
            ],
            "StorageAccountName": "<storage-account-name>"
        }
    }
}

In einer automatischen Definition werden die Elementnamen automatisch basierend auf Benennungskonventionen generiert, wie in diesem Beispiel gezeigt.

{
    {
        "SubscriptionId": "<subscription-identifier-associated-with-service-connection>",
        "Name": "<environment-name>",
        "NamingConvention": "<naming-convention-template-for-automatic-cases>",
        "Location": "<environment-location>",
        "ResourceGroup": {
            "Type": "Automatic"
        }
    },
    "Resources":
    {
        "Sentinel":
        {
            "Type": "Automatic"
        },
        "Automation":
        {
            "Type": "Automatic"
        },
        "Integration":
        {
            "Type": "Automatic",
            "MaxEventHubNamespaces": 5
        }
    }
}

Beispiele finden Sie im GitHub-Repository unter dem Pfad zu Microsoft Sentinel-Umgebungen und verwenden die Beispiele als Referenz für die Vorbereitung Ihrer Anwendungsfälle.

Bereitstellen Ihrer Microsoft Sentinel-Umgebung

Wenn Sie mindestens eine Umgebung definiert haben, können Sie die Azure-Dienstverbindung für die Integration in Azure DevOps erstellen. Nachdem Sie die Dienstverbindung erstellt haben, legen Sie den verknüpften Dienstprinzipal auf die Rolle Besitzer oder eine ähnliche Berechtigungsebene für das Zielabonnement fest.

1. Importieren Sie die Pipeline für die Erstellung der neuen Umgebung, wie in dieser Datei definiert.

   src/Release/Sentinel Deployment/ADO/Microsoft.Sentinel.Environment.Deployment.yml

2. Geben Sie dann den Namen der Dienstverbindung ein, die die Umgebung darstellt.

   

3. Wählen Sie den Zweig für die Umgebungsdefinition im Repository. 

4. Geben Sie den Namen der Azure DevOps-Dienstverbindung für Ihr Abonnement in das Feld Azure-Umgebungsverbindung ein.

5. Geben Sie den Namen der Umgebung ein, mit der eine Dienstverbindung mehrere Umgebungen im selben Abonnement auflösen kann.

6. Wählen Sie die Aktion aus, die auf die Connectors angewendet werden soll.

7. Wählen Sie PowerShell-Vorarbversions-Artefakte verwenden aus, wenn Sie die Vorabversionen der PowerShell-Frameworkkomponenten verwenden möchten.

Die Pipeline umfasst die folgenden Schritte im Rahmen des Bereitstellungsablaufs:

• Stellen Sie NuGet-Komponenten bereit.
• Verbinden mithilfe von NuGet-Tools mit dem Artefakt-Repository.
• Lösen Sie den Feed auf.
• Installieren der erforderlichen Module.
• Abrufen der Umgebungsdefinition.
• Überprüfen Sie, welche Ressourcen im Ziel vorhanden sind.
• Fügen Sie Log Analytics und Microsoft Sentinel hinzu, wenn sie sich nicht im Arbeitsbereich befinden.
• Wenn Sie bereits über Log Analytics verfügen, fügen Sie Microsoft Sentinel über Ihre Log Analytics-Instanz hinzu.
• Erstellen Sie eine verwaltete Identität, um die Interaktion zwischen Microsoft Sentinel und Logic Apps darzustellen.
• Erstellen Sie Azure Key Vault, und legen Sie die Rollenzuweisung für die Verwaltung von Geheimnissen und Schlüsseln auf die verwaltete Identität fest.
• Erstellen Sie ggf. ein Azure Automation-Konto, und aktivieren Sie die vom System zugewiesene verwaltete Identität.
• Legen Sie die Rollenzuweisung für den Key Vault für die vom System zugewiesene verwaltete Identität fest.
• Erstellen Sie die Event Hubs-Definitionen, wenn sie nicht vorhanden sind, und legen Sie fest, ob die Definition die Integrationselemente enthält.
• Legen Sie die Rollenzuweisung für den Key Vault für die vom System zugewiesene verwaltete Identität fest.
• Erstellen Sie die Speicherkonto-Definitionen, wenn sie nicht vorhanden sind, und legen Sie fest, ob die Definition die Integrationselemente enthält.
• Legen Sie die Rollenzuweisung für den Key Vault für die vom System zugewiesene verwaltete Identität fest.
• Stellen Sie die Connectoraktionen bereit.
• Stellen Sie das Integrations-Runbook für das Automation-Konto bereit.
• Stellen Sie die Logic Apps-Verbindungen bereit, wenn sie als Teil der Umgebung definiert sind.

Zerstören einer Microsoft Sentinel-Umgebung

Wenn die Umgebung nicht mehr benötigt wird, z. B. bei einer Entwicklungs- oder Testumgebung, können Sie sie wie in dieser Datei definiert zerstören.

src/Release/Sentinel Deployment/ADO/Microsoft.Sentinel.Environment.Destroy.yml

Wie beim Bereitstellen der Umgebungspipeline geben Sie den Namen der Dienstverbindung an, die die Umgebung darstellt.

Arbeiten mit Ihrer Microsoft Sentinel-Umgebung

Nachdem Ihre Umgebung bereit ist, können Sie mit dem Erstellen der Artefakte zum Einrichten der verschiedenen Anwendungsfälle beginnen.

1. Exportieren Sie die Artefakte aus der Umgebung, an der Sie arbeiten, wie in dieser Datei definiert.

   src/Release/Artifacts Deployment/ADO/Microsoft.Sentinel.Artifacts.Export.yml

2. Wählen Sie den Zweig für die Umgebungsdefinition im Repository.

   

3. Geben Sie den Namen der Azure DevOps-Dienstverbindung für die zu exportierende Umgebung in das Feld Azure-Umgebungsverbindung ein.

4. Wählen Sie PowerShell-Vorarbversions-Artefakte verwenden aus, wenn Sie die Vorabversionen der PowerShell-Frameworkkomponenten verwenden möchten.

5. Wählen Sie das Format für die Analyse- und Huntingregeln aus.

   Die Artefaktausgabedatei ist in den Ergebnissen verfügbar. Nachdem Sie über die Artefakte verfügen, können Sie die Ausgabedatei in das Git-Repository hinzufügen.

Erstellen Ihrer Artefakte in der Microsoft Sentinel-Umgebung

Platzieren Sie Ihre Artefakte unter dem Microsoft Sentinel MITRE-Anwendungsfällepfad. Richten Sie die Ordnerstruktur entsprechend den verschiedenen Arten von Artefakten ein.

1. Starten Sie den Buildprozess, wie in dieser Datei definiert.

   src/Build/Artifacts/ADO/Microsoft.Sentinel.Artifacts.Build.yaml

2. Wählen Sie den Zweig für die Umgebungsdefinition im Repository.

   Diagramm: Auswählen des Branch zum Erstellen der Artefakte.](./media/build-artifacts-pipeline.png)

3. Wählen Sie PowerShell-Vorarbversions-Artefakte verwenden aus, wenn Sie die Vorabversionen der PowerShell-Frameworkkomponenten verwenden möchten.

Die Pipeline besteht aus den folgenden Schritten:

• Stellen Sie NuGet-Komponenten bereit.
• Verbinden sie NuGet-Tools in das Artefakt-Repository ein.
• Lösen Sie den Feed auf.
• Installieren der erforderlichen Module.
• Hier finden Sie das Framework für das Test-Toolkit zum Überprüfen der ARM-Vorlagen.
• Überprüfen Sie die ARM-Vorlagen.
• Überprüfen Sie den PowerShell-Runbooks-Code, und führen Sie die Syntaxüberprüfung durch.
• Führen Sie ggf. die Pester-Komponententests aus.
• Überprüfen Sie die KQL-Syntax in den Hunting- und Analyseregeln.

Bereitstellen Ihrer Artefakte in der Microsoft Sentinel-Umgebung

Bei der Bereitstellung Ihrer Artefakte können Sie die Microsoft Sentinel-Repositorys oder die Beispiele für die Bereitstellungspipeline in diesem Repository verwenden. Weitere Informationen finden Sie unter Bereitstellen benutzerdefinierter Inhalte aus Ihrem Repository.

Microsoft Sentinel-Repositorys

Wenn Sie Microsoft Sentinel-Repositorys verwenden, können Sie einen Releaseprozess einrichten, der die Artefakte in das Repository einfing, das mit jeder Microsoft Sentinel-Instanz verbunden ist. Nachdem die Artefakte im Repository comittet wurden, werden einige der Schritte automatisch im Rahmen der Erstellung der Pipeline und der Aktivierung der Microsoft Sentinel-Repositorys ausgeführt.

Außerdem können Sie die Bereitstellungsprozesse, die die Microsoft Sentinel-Repositorys ausführen, basierend auf den in diesem Dokument beschriebenen Methoden anpassen. Ein wichtiger Aspekt, der zu berücksichtigen ist, ist die Freigabegenehmigung, die Sie mit den folgenden Ansätzen einrichten können:

• PR-Genehmigung beim Committen der Artefakte. Weitere Informationen finden Sie unter Erstellen einer Pull Request.
• Genehmigung der Releasepipeline beim Ausführen der Bereitstellung. Weitere Informationen finden Sie unter Definieren von Genehmigungen und Überprüfungen.

Beispiele für die Microsoft Sentinel-Bereitstellungspipeline

Mithilfe der Beispiele für die Microsoft Sentinel-Bereitstellungspipeline können Sie einen Releaseprozess einrichten.

1. Richten Sie den Releaseprozess gemäß der Definition in dieser Datei ein.

   src/Release/Artifacts Deployment/ADO/Microsoft.Sentinel.Artifacts.Deployment.yml

2. Wählen Sie den Zweig für die Umgebungsdefinition im Repository.

   

3. Geben Sie den Namen der Azure DevOps-Dienstverbindung für die zu exportierende Umgebung in das Feld Azure-Umgebungsverbindung ein.

4. Wählen Sie PowerShell-Vorarbversions-Artefakte verwenden aus, wenn Sie die Vorabversionen der PowerShell-Frameworkkomponenten verwenden möchten.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

• Kevin Kisoka | Associate Architect

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte

• Informationen zu Microsoft Sentinel mit DevOps für die Architektur mit nur einem Mandanten finden Sie unter Bereitstellen und Verwalten von Microsoft Sentinel als Code.
• Weitere Informationen zur mehr mandantenbasierten MSSP-Architektur finden Sie unter Kombinieren von Azure Lighthouse mit den Funktionen von Microsoft Sentinel.
• Informationen zur verwalteten Identität mit Microsoft Sentinel finden Sie unter Neues: Verwaltete Identität für den Microsoft Sentinel Logic Apps Connector.
• Informationen zum Bereitstellen von Inhalten aus einem Microsoft Sentinel-Repository finden Sie unter Bereitstellen benutzerdefinierter Inhalte aus Ihrem Repository.
• Weitere Informationen zu Azure DevOps Sicherheitsüberlegungen finden Sie in der Kurzreferenz zu Standardberechtigungen.
• Informationen zum Schützen eines Azure DevOps Repositorys finden Sie unter Hinzufügen von Schutz zu einer Repositoryressource.
• Informationen zum Verwalten Azure DevOps Dienstverbindungssicherheit finden Sie unter Dienstverbindungen in Azure Pipelines.

Zugehörige Ressourcen

• Hybride Sicherheitsüberwachung mit Microsoft Defender für Cloud und Microsoft Sentinel
• Entwerfen einer CI/CD-Pipeline mithilfe von Azure DevOps
• Erweiterte ARM-Vorlagenfunktionen