Sentinel-integratie automatiseren met Azure DevOps

In dit artikel wordt beschreven hoe u integratie- en implementatiebewerkingen van Microsoft Sentinel automatiseert met Azure DevOps. U implementeert Azure DevOps met behulp van De mogelijkheden van Microsoft Sentinel om uw implementatie te beveiligen. Vervolgens gebruikt u een DevSecOps-framework om Microsoft Sentinel-artefacten op schaal te beheren en te implementeren.

Architectuur

In het volgende diagram ziet u een Installatie van Azure DevOps en Microsoft Sentinel IaC.

Een Visio-bestand van deze architectuur downloaden.

Gegevensstroom

1. De scrum-master en het productbeheer maken gebruik van Azure DevOps om epics, gebruikersverhalen en productachterstanditems te definiëren als onderdeel van de projectachterstand.
   • De scrum-master en het productbeheer maken gebruik van Azure Boards om de achterstand te maken, werk in sprints te plannen, het projectbord te bekijken, de structuur van de opslagplaats te maken en beveiligingsregels in te stellen, zoals goedkeuringswerkstromen en vertakkingen.
   • In de Azure Git-opslagplaats worden de scripts en de vergunningen opgeslagen voor het beheren van Microsoft Sentinel-artefacten in de infrastructuur als code.
   • Artefacten en broncodebeheer onderhouden de extensies en updatepakketten of onderdelen van de DevSecOps-werkstroom die in de oplossing worden gebruikt, zoals Azure Resource Manager Template Toolkit en PowerShell Pester.
2. Microsoft Sentinel-artefacten:
   • Beleidsregels. SIEM-technici gebruiken Azure-beleid in de referentiearchitectuur om de diagnostische instellingen van de Azure-services te configureren en te schalen. Het beleid helpt bij het automatiseren van de implementatie van de Microsoft Sentinel-gegevensconnectors, zoals Azure Key Vault. Het beleid is afhankelijk van de OMSIntegration-API.
   • Connectors. Microsoft Sentinel maakt gebruik van logische connectors, de Azure Data Verbinding maken ors, voor het opnemen van beveiligingsgegevens, zoals in controles of metrische gegevens, uit ondersteunde gegevensbronnen, zoals Microsoft Entra ID, Azure-resources, Microsoft Defender of oplossingen van derden. De hoofdlijst met gegevensconnectors wordt beheerd door de SecurityInsights-API. Anderen zijn afhankelijk van de OMSIntegration-API en worden beheerd met de diagnostische instellingen van Azure Policy.
   • Beheerde identiteit. Microsoft Sentinel maakt gebruik van een beheerde identiteit om namens de Managed Service Identity (MSI) te handelen tijdens interactie met playbooks, logische apps of automation-runbooks en de sleutelkluis.
   • Automatisering. SOC-teams gebruiken automatisering tijdens onderzoeken. SOC-teams voeren procedures voor digitale forensische gegevensverwerving uit met Azure Automation, zoals de keten van bewaring van virtuele Azure-machines (VM) of eDiscovery (Premium) voor Microsoft Defender.
   • Analyse. SOC-analisten of bedreigingsjagers gebruiken ingebouwde of aangepaste analyseregels om gegevens in Microsoft Sentinel te analyseren en correleren of playbooks te activeren als een bedreiging en incident worden geïdentificeerd.
   • Playbooks. Logische apps voeren de herhaalbare SecOps-acties uit, zoals het toewijzen van een incident, het bijwerken van een incident of het uitvoeren van herstelacties, zoals het isoleren of bevatten van een VIRTUELE machine, het intrekken van een token of het opnieuw instellen van een gebruikerswachtwoord.
   • Detectie van bedreigingen. Bedreigingsjagers gebruiken proactieve mogelijkheden voor het opsporen van bedreigingen die kunnen worden gekoppeld aan Jupyter-notebooks voor geavanceerde gebruiksvoorbeelden, zoals gegevensverwerking, gegevensmanipulatie, gegevensvisualisatie, machine learning of deep learning.
   • Werkmappen. SIEM-technici gebruiken Workbooks-dashboards om trends en statistieken te visualiseren en om de status van een Microsoft Sentinel-exemplaar en de bijbehorende subonderdelen weer te geven.
   • Bedreigingsinformatie. Een specifieke gegevensconnector waarmee bedreigingsinformatieplatforms worden samengevoegd in Microsoft Sentinel. Er worden twee connectiviteitsmethoden ondersteund: TAXII en Graph API. Beide methoden fungeren als tiIndicators of bedreigingsinformatie-indicatoren in beveiligings-API's.
3. Microsoft Entra-id. Mogelijkheden voor identiteits- en toegangsbeheer worden geleverd aan onderdelen die worden gebruikt in de referentiearchitectuur, zoals beheerde identiteiten, service-principals, op rollen gebaseerd toegangsbeheer van Azure (RBAC's) voor Microsoft Sentinel, logische apps en automatiseringsrunbooks.
4. Azure Pipelines. DevOps-technici gebruiken pijplijnen om serviceverbindingen te maken voor het beheren van de verschillende Azure-abonnementen, zoals de sandbox- en productieomgevingen met CI/CD-pijplijnen (continue integratie en continue levering). We raden u aan goedkeuringswerkstromen te gebruiken om onverwachte implementaties en gescheiden service-principals te voorkomen als u zich richt op meerdere abonnementen per Azure-omgeving.
5. Azure Key Vault. SOC-technici gebruiken de sleutelkluis om geheimen en certificaten van service-principals veilig op te slaan. Dit onderdeel van de architectuur helpt bij het afdwingen van het DevSecOps-principe van geen geheimen in code wanneer deze worden gebruikt door Azure Pipeline-serviceverbindingen.
6. Azure-abonnement. De SOC-teams gebruiken twee exemplaren van Microsoft Sentinel in deze referentiearchitectuur, gescheiden binnen twee logische Azure-abonnementen om productie- en sandboxomgevingen te simuleren. U kunt schalen voor uw behoeften met andere omgevingen, zoals testen, ontwikkelen, preproductie, enzovoort.

Voorbeeld van gegevensstroom

1. Een beheerder voegt een vermelding toe, werkt of verwijdert een vermelding in de fork van het Microsoft 365-configuratiebestand.
2. De beheerder doorvoert en synchroniseert de wijzigingen in de geforkte opslagplaats.
3. De beheerder maakt vervolgens een pull-aanvraag (PR) om de wijzigingen samen te voegen in de hoofdopslagplaats.
4. De build-pijplijn wordt uitgevoerd op de pull-aanvraag.

Onderdelen

• Microsoft Entra ID is een multitenant, cloudservice voor het beheren van uw identiteit en toegangsbeheer.
• Azure DevOps is een cloudservice om samen te werken aan code, apps te bouwen en te implementeren, of uw werk te plannen en bij te houden.
• Azure Key Vault is een cloudservice voor het veilig opslaan en openen van geheimen. Een geheim is alles waartoe u de toegang strikt wilt beheren, zoals API-sleutels, wachtwoorden, certificaten of cryptografische sleutels.
• Azure Policy is een service voor het maken, toewijzen en beheren van beleidsdefinities in uw Azure-omgeving.
• Microsoft Sentinel is een schaalbare, cloudeigen, SIEM- en beveiligingsindeling, automatisering en responsoplossing (SOAR).
• Azure Automation is een service voor het vereenvoudigen van cloudbeheer via procesautomatisering. Gebruik Azure Automation om langlopende, handmatige, foutgevoelige en vaak herhaalde taken te automatiseren. Automatisering helpt de betrouwbaarheid, efficiëntie en de waarde van uw bedrijf te verbeteren.

Scenariodetails

Soc-teams (Security Operations Center) ondervinden soms uitdagingen wanneer ze Microsoft Sentinel integreren met Azure DevOps. Het proces omvat veel stappen en de installatie kan dagen duren en herhalingen omvatten. U kunt dit deel van de ontwikkeling automatiseren.

Om de cloud te moderniseren, moeten technici voortdurend nieuwe vaardigheden en technieken leren voor het beveiligen en beschermen van essentiële bedrijfsactiva. Technici moeten robuuste en schaalbare oplossingen bouwen die in de hoogte blijven van het veranderende beveiligingslandschap en met bedrijfsbehoeften. Een beveiligingsoplossing moet flexibel, flexibel en zorgvuldig worden gepland vanaf de vroegste ontwikkelingsfasen. Deze vroege planningsmethodologie wordt shift-left genoemd.

In dit artikel wordt beschreven hoe u integratie- en implementatiebewerkingen van Microsoft Sentinel automatiseert met Azure DevOps. U kunt de oplossing uitbreiden voor complexe organisaties met meerdere entiteiten, abonnementen en verschillende operationele modellen. Enkele van de operationele modellen die door deze oplossing worden ondersteund, zijn onder andere lokale SOC, globale SOC, cloudserviceprovider (CSP) en mssp (Managed Security Service Provider).

Dit artikel is bedoeld voor de volgende doelgroepen:

• SOC-specialisten, zoals analisten en bedreigingsjagers
• SIEM-technici (Security Information and Event Management)
• Cyberbeveiligingsarchitecten
• Ontwikkelaars

Potentiële gebruikscases

Hieronder volgen de typische gebruiksvoorbeelden voor deze architectuur:

• Snelle prototypen en proof-of-concept. Deze oplossing is ideaal voor beveiligingsorganisaties en SOC-teams die de dekking van cloudrisico's willen verbeteren of hun SIEM-infrastructuur willen moderniseren met infrastructuur als code (IaC) en Microsoft Sentinel.
• Microsoft Sentinel als een service. Dit ontwikkelingsframework integreert principes voor levenscyclusbeheer van services. Deze principes zijn geschikt voor eenvoudige of complexe teams, zoals MSSP's die herhaalbare, gestandaardiseerde acties uitvoeren voor meerdere tenants van klanten, terwijl de kracht van Azure DevOps en Azure Lighthouse wordt gecombineerd. Een team dat microsoft Sentinel-use cases moet publiceren voor een nieuwe bedreigingsacteur of lopende campagne, kan deze oplossing bijvoorbeeld gebruiken.
• Soc-gebruiksvoorbeelden bouwen voor detectie van bedreigingen. Veel groepen en bedreigingsinformatieplatforms zijn afhankelijk van MITRE Att&ck-inhoud en taxonomie om hun beveiligingspostuur te analyseren tegen geavanceerde tradecraft- of technieken en tactiekprocedures. De oplossing definieert een gestructureerde benadering voor het ontwikkelen van technische procedures voor detectie van bedreigingen door miTRE Att&ck-terminologie op te nemen in de ontwikkeling van Microsoft Sentinel-artefacten.

In de volgende afbeelding ziet u een MITRE Att&ck-cloudscenario.

Een Visio-bestand van deze architectuur downloaden.

Bedreigingsdefinitiescenario's op basis van MITRE

In deze tabel ziet u de termen, definities en details van belangrijke aspecten van aanvalsscenario's.

Gegevensitem	Beschrijving	Microsoft Sentinel-artefacten
Titel	Beschrijvende naam voor het aanvalsscenario, op basis van aanvalsvectorkenmerken of techniekenbeschrijvingen.	MITRE-manifest
MITRE ATT&CK-tactieken	MITRE ATT&CK-tactieken met betrekking tot aanvalsscenario	MITRE-manifest
MITRE ATT&CK-technieken	MITRE ATT&CK-technieken, waaronder de techniek of subtechniek-id, gerelateerd aan het aanvalsscenario.	MITRE-manifest
Gegevensconnectorbronnen	Bron van gegevens die worden verzameld door een sensor of logboekregistratiesysteem dat kan worden gebruikt om informatie te verzamelen die relevant is voor het identificeren van de actie die wordt uitgevoerd, de volgorde van acties of de resultaten van deze acties door een kwaadwillende persoon.	Microsoft Sentinel-gegevensconnector of aangepaste logboekbron
Beschrijving	Informatie over de techniek, wat het is, waarvoor het meestal wordt gebruikt, hoe een kwaadwillende kan profiteren van de techniek en variaties op hoe het kan worden gebruikt. Bevat verwijzingen naar gezaghebbende artikelen die technische informatie beschrijven die betrekking hebben op de techniek en in de verwijzingen naar wildgebruik, indien van toepassing.
Detection	Analyseproces op hoog niveau, sensoren, gegevens en detectiestrategieën die nuttig zijn bij het identificeren van een techniek die door een kwaadwillende gebruiker wordt gebruikt. Deze sectie informeert degenen die verantwoordelijk zijn voor het detecteren van kwaadwillende gedragingen, zoals netwerkverdedigers, zodat ze een actie kunnen ondernemen, zoals het schrijven van een analyse of het implementeren van een sensor. Er moeten voldoende informatie en verwijzingen zijn om te verwijzen naar nuttige defensieve methodologieën. Detectie is mogelijk niet altijd mogelijk voor een bepaalde techniek en moet als zodanig worden gedocumenteerd.	Opsporing van bedreigingen analyseren
Oplossing	Configuraties, hulpprogramma's of processen die voorkomen dat een techniek werkt of het gewenste resultaat heeft voor een kwaadwillende persoon. Deze sectie informeert degenen die verantwoordelijk zijn voor het beperken van aanvallers, zoals netwerkverdedigers of beleidsmakers, om ze een actie te laten ondernemen, zoals het wijzigen van een beleid of het implementeren van een hulpprogramma. Risicobeperking is mogelijk niet altijd mogelijk voor een bepaalde techniek en moet als zodanig worden gedocumenteerd.
Oplossing	Configuraties, hulpprogramma's of processen die voorkomen dat een techniek werkt of het gewenste resultaat heeft voor een kwaadwillende persoon. In deze sectie wordt beschreven hoe u de effecten van kwaadwillende aanvallen voor netwerkverdedigers of beleidsmakers vermindert. Hierin worden stappen beschreven voor het wijzigen van een beleid of het implementeren van een hulpprogramma. Risicobeperking is mogelijk niet altijd mogelijk voor een bepaalde techniek en moet als zodanig worden gedocumenteerd.	Playbooks, automation-runbooks

Overwegingen

Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd, een set richtlijnen die u kunt gebruiken om de kwaliteit van een workload te verbeteren. Zie Microsoft Azure Well-Architected Framework voor meer informatie.

Beveiliging

Beveiliging biedt garanties tegen opzettelijke aanvallen en misbruik van uw waardevolle gegevens en systemen. Zie Overzicht van de beveiligingspijler voor meer informatie.

Met beveiliging verhoogt automatisering de efficiëntie van bewerkingen en bespaart u tijd voor complexere gebruiksvoorbeelden, zoals detectie van bedreigingen, bedreigingsinformatie, SOC en SOAR-gebruiksvoorbeelden. DevOps-teams moeten weten waar ze IaC veilig kunnen gebruiken in de context van Microsoft Sentinel CI/CD. Dit proces introduceert het gebruik van specifieke identiteiten die worden gebruikt door niet-menselijke accounts in Microsoft Entra-id, service-principals en beheerde identiteiten.

De volgende tabel bevat een overzicht van beveiligingsoverwegingen voor service-principals en de belangrijkste use cases die worden gedekt door Microsoft Sentinel- en Azure DevOps-releasepijplijnen.

Gebruiksscenario	Vereisten (minimale bevoegdheid)	Duur van roltoewijzing	Machtigingsbereik	Trustee	Beveiligingsoverwegingen
Microsoft Sentinel-connectors inschakelen	Beveiligingsbeheerder** Eigenaar* Microsoft Sentinel-inzender Lezer	JIT (eenmalige activering) Met opzet (telkens wanneer een nieuw abonnement en een nieuwe connector wordt geïmplementeerd)	Tenant	SPN	Gebruik de sleutelkluis om SPN-geheimen (Service Principal Name) en certificaat op te slaan. Schakel SPN-controle in. Controleer regelmatig de machtigingstoewijzing (Azure Privileged Identity Management voor SPN) of verdachte activiteit voor SPN. Gebruik Microsoft Entra-certificeringsinstanties en meervoudige verificatie (indien ondersteund) voor bevoegde accounts. Gebruik aangepaste Microsoft Entra-rollen voor meer granulariteit.
Microsoft Sentinel-artefacten implementeren, zoals werkmappen, analyses, regels, query's voor opsporing van bedreigingen, notebooks en playbooks	Microsoft Sentinel-inzender Logic Apps-inzender	Permanent	Werkruimte of resourcegroep van Microsoft Sentinel	SPN	Gebruik goedkeuring van ADO-werkstromen (Azure DevOps) en controles om de pijplijnimplementatie met deze SPN te beveiligen.
Een beleid toewijzen voor het configureren van logboekstreamingfuncties aan Microsoft Sentinel	Inzender voor resourcebeleid **	Met opzet (telkens wanneer een nieuw abonnement en een nieuwe connector wordt geïmplementeerd)	Alle abonnementen die moeten worden bewaakt	SPN	Gebruik Microsoft Entra ID, CA en MFA, indien ondersteund, voor bevoegde accounts.

* Alleen gaat het om diagnostische instellingen van Microsoft Entra.
** Specifieke connectors hebben aanvullende machtigingen nodig, zoals 'beveiligingsbeheerder' of 'inzender voor resourcebeleid' om streaminggegevens toe te staan aan microsoft Sentinel-werkruimte, Microsoft Entra-id, Microsoft 365 of Microsoft Defender en PaaS-resources (Platform as a Service), zoals Azure Key Vault.

Privileged Access Model

We raden u aan een strategie voor een privileged access model te gebruiken om de risico's voor uw bedrijf snel te verlagen tegen aanvallen met hoge impact en een hoge kans op bevoegde toegang. In het geval van automatische processen in een DevOps-model baseert u de identiteit op service-principal-identiteiten .

Bevoegde toegang moet de hoogste beveiligingsprioriteit van elk bedrijf zijn. Elke inbreuk op deze identiteiten heeft zeer negatieve gevolgen. Bevoegde identiteiten hebben toegang tot bedrijfskritieke assets, wat vrijwel altijd grote gevolgen heeft wanneer aanvallers inbreuk maken op deze accounts.

Beveiliging van bevoegde toegang is van cruciaal belang, omdat het fundamenteel is voor alle andere beveiligingsgaranties. Een aanvaller die controle heeft over uw bevoegde accounts, kan alle andere beveiligingsgaranties ondermijnen.

Daarom raden we u aan de service-principals logisch te spreiden in verschillende niveaus of lagen door een minimumprivilegiatieprincipe te volgen. In de volgende afbeelding ziet u hoe u de service-principals classificeert, afhankelijk van het type toegang en waar de toegang is vereist.

Service-principals op niveau 0

Service-principals op niveau 0 hebben het hoogste machtigingsniveau. Deze service-principals geven iemand het recht om beheertaken voor tenantbrede of hoofdbeheergroepen uit te voeren als globale beheerder.

Om veiligheidsredenen en beheerbaarheid raden we u aan slechts één service-principal voor dit niveau te hebben. De machtigingen voor deze service-principal blijven behouden. Daarom wordt u aangeraden alleen de minimale machtigingen te verlenen die vereist zijn en het account bewaakt en beveiligd te houden.

Sla het geheim of certificaat voor dit account veilig op in Azure Key Vault. We raden u ten zeere aan om de sleutelkluis in een toegewezen beheerabonnement te vinden, indien mogelijk.

Service-principals op niveau 1

Service-principals op niveau 1 zijn verhoogde machtigingen die beperkt zijn en binnen het bereik vallen van beheergroepen op bedrijfsniveau. Deze service-principals geven iemand het recht om abonnementen te maken onder de beheergroep die binnen het bereik valt.

Om veiligheidsredenen en beheerbaarheid raden we u aan slechts één service-principal voor dit niveau te hebben. De machtigingen voor deze service-principal blijven behouden, dus we raden u ten zeerste aan om alleen de minimale machtigingen te verlenen die vereist zijn en het account bewaakt en beveiligd te houden.

Sla het geheim of certificaat voor dit account veilig op in Azure Key Vault. We raden u ten zeere aan om de sleutelkluis in een toegewezen beheerabonnement te vinden, indien mogelijk.

Service-principals op niveau 2

Service-principals op niveau 2 zijn beperkt tot het abonnementsniveau. Deze service-principals geven iemand het recht om beheertaken uit te voeren onder een abonnement, die als eigenaar van het abonnement fungeert.

Om veiligheidsredenen en beheerbaarheid raden we u aan slechts één service-principal voor dit niveau te hebben. De machtigingen voor deze service-principal blijven behouden, dus we raden u ten zeerste aan om alleen de minimale machtigingen te verlenen die vereist zijn en het account bewaakt en beveiligd te houden.

Sla het geheim of certificaat voor dit account veilig op in Azure Key Vault. We raden u ten zeere aan om de sleutelkluis te vinden in een toegewezen beheerresourcegroep.

Service-principals op niveau 3

Service-principals op niveau 3 zijn beperkt tot de workload-Beheer istrator. In een typisch scenario bevindt elke workload zich in dezelfde resourcegroep. Deze structuur beperkt de machtigingen van de service-principal tot alleen deze resourcegroep.

Om veiligheidsredenen en beheerbaarheid raden we u aan slechts één service-principal per workload te hebben. De machtigingen voor deze service-principal blijven behouden, dus we raden u ten zeerste aan om alleen de minimale machtigingen te verlenen die vereist zijn en het account bewaakt en beveiligd te houden.

Sla het geheim of certificaat voor dit account veilig op in Azure Key Vault. We raden u ten zeere aan om de sleutelkluis te vinden in een toegewezen beheerresourcegroep.

Service-principals op niveau 4

Service-principals op niveau 4 hebben de meest beperkte machtigingen. Deze service-principals geven iemand het recht om beheertaken uit te voeren die beperkt zijn tot één resource.

We raden u aan om waar mogelijk beheerde identiteiten te gebruiken. In het geval van niet-beheerde identiteiten slaat u het geheim of certificaat veilig op in Azure Key Vault waar geheimen van niveau 3 worden opgeslagen.

Operationele uitmuntendheid

Operationele uitmuntendheid omvat de operationele processen die een toepassing implementeren en deze in productie houden. Zie Overzicht van de operationele uitmuntendheidpijler voor meer informatie.

Microsoft Sentinel-oplossingen bestaan uit drie blokken, die zorgen voor volledige en succesvolle bewerkingen.

Het eerste blok is de omgevingsdefinitie, die de essentiële architectuurelementen vormt. Het belangrijkste probleem met dit blok is om rekening te houden met het aantal productie- en niet-productieomgevingen dat moet worden geïmplementeerd, en vervolgens ervoor te zorgen dat de installatie in alle gevallen homogeen is.

Het tweede blok is de implementatie van de Microsoft Sentinel-connector, waarbij u rekening houdt met het soort connectors dat uw team nodig heeft en de beveiligingsvereisten om ze in te schakelen.

Het derde blok is het levenscyclusbeheer van Microsoft Sentinel-artefacten, dat betrekking heeft op coderen, implementeren en gebruiken of vernietigen van de onderdelen. Dit blok bevat bijvoorbeeld de analytische regels, playbooks, werkmappen, opsporing van bedreigingen, enzovoort.

Houd rekening met deze afhankelijkheden tussen artefacten:

• Automatiseringsregels die zijn gedefinieerd in een analyseregel
• Werkmappen of analyses waarvoor een nieuwe gegevensbron of connector is vereist
• De updates van bestaande onderdelen beheren
  • Uw artefacten versien
  • Een bijgewerkte of geheel nieuwe analyseregel identificeren, testen en implementeren

Infrastructuur bouwen, testen en implementeren

Bij het beheren van Microsoft Sentinel-oplossingen en DevOps is het belangrijk om rekening te houden met de connectiviteits- en beveiligingsaspecten van uw bedrijfsarchitectuur.

Azure DevOps kan door Microsoft gehoste agents of zelf-hostende agents gebruiken voor het bouwen, testen en implementeren van activiteiten. Afhankelijk van de vereisten van uw bedrijf kunt u door Microsoft gehost, zelf-hostend of een combinatie van beide modellen gebruiken.

• Door Microsoft gehoste agents. Deze optie is de snelste manier om met Azure DevOps-agents te werken, omdat dit een gedeelde infrastructuur is voor uw hele organisatie. Zie door Microsoft gehoste agents voor meer informatie over het gebruik van door Microsoft gehoste agents in uw pijplijn. Door Microsoft gehoste agents kunnen werken in hybride netwerkomgevingen, waarbij toegang wordt verleend voor de IP-bereiken. Als u de IP-bereiken wilt downloaden waartoe deze agents toegang verlenen, raadpleegt u Azure IP-bereiken en servicetags : openbare cloud.
• Zelf-hostende agents. Deze optie biedt u toegewezen resources en meer controle bij het installeren van afhankelijke software voor uw builds en implementaties. Zelf-hostende agents kunnen werken via VM's, schaalsets en containers in Azure. Zie Azure Pipelines-agents voor meer informatie over zelf-hostende agents.

GitHub-runners

GitHub kan gebruikmaken van door GitHub gehoste runners of zelf-hostende runners voor activiteiten die betrekking hebben op het bouwen, testen en implementeren. Afhankelijk van de behoeften van uw bedrijf kunt u gitHub-gehost, zelf-hostend of een combinatie van beide modellen gebruiken.

Door GitHub gehoste hardlopers

Deze optie is de snelste manier om te werken met GitHub-werkstromen, omdat het een gedeelde infrastructuur is voor een hele organisatie. Zie Voor meer informatie over door GitHub gehoste runners. GitHub-gehoste agents werken in hybride netwerkomgevingen, volgens bepaalde netwerkvereisten. Zie Ondersteunde hardlopers en hardwareresources voor meer informatie over de netwerkvereisten.

Zelf-hostende hardlopers

Met deze optie krijgt uw bedrijf een toegewezen infrastructuur voor resources. Zelf-hostende hardlopers werken via VM's en containers in Azure en ondersteunen automatisch schalen.

Overwegingen voor het kiezen van hardlopers

Houd rekening met de volgende behoeften bij het kiezen van opties voor de agents en hardlopers in uw Microsoft Sentinel-oplossing:

• Heeft uw bedrijf toegewezen resources nodig voor het uitvoeren van processen in uw Microsoft Sentinel-omgevingen?
• Wilt u resources isoleren voor DevOps-activiteiten in de productieomgeving van de rest van de omgevingen?
• Moet u bepaalde gevallen testen waarvoor toegang tot kritieke resources of resources is vereist die alleen beschikbaar zijn in een intern netwerk?

Indeling en automatisering van releaseprocessen

U kunt het implementatieproces instellen met Azure DevOps of GitHub. Azure DevOps biedt ondersteuning voor het gebruik van een YAML-pijplijn of een release-pijplijn. Zie Azure Pipelines gebruiken voor meer informatie over het gebruik van een YAML-pijplijn in Azure DevOps. Zie Release-pijplijnen voor meer informatie over het gebruik van een release-pijplijn in Azure DevOps. Zie GitHub Actions voor meer informatie over het gebruik van GitHub met GitHub Actions.

Azure DevOps

U kunt de volgende implementatieactiviteiten uitvoeren in een Azure DevOps-implementatie.

• Gebruik een YAML-pijplijn om pull-goedkeuringen automatisch te activeren of on demand uit te voeren.
• Serviceverbindingen voor verschillende omgevingen beheren met behulp van Azure DevOps-groepen.
• Stel in uw kritieke omgevingen implementatiegoedkeuringen in met behulp van de serviceverbindingsfunctie en Azure DevOps-groepen om specifieke gebruikersmachtigingen in uw team toe te wijzen.

GitHub

U kunt de volgende implementatieactiviteiten uitvoeren in een GitHub-implementatie.

• Gebruik GitHub om pull-aanvragen of implementatieactiviteiten te maken.
• Referenties van de service-principal beheren met behulp van GitHub Secrets.
• Integreer implementatiegoedkeuring via de werkstroom die is gekoppeld aan GitHub.

Automatische implementatie met Microsoft Sentinel-infrastructuur

U kunt een of meer Microsoft Sentinel-omgevingen implementeren, afhankelijk van uw bedrijfsarchitectuur:

• Organisaties die meerdere exemplaren in hun productieomgeving nodig hebben, kunnen voor elke geografische locatie verschillende abonnementen instellen op dezelfde tenant.
• Een gecentraliseerd exemplaar in de productieomgeving biedt toegang tot een of meer organisaties in dezelfde tenant.
• Groepen die meerdere omgevingen nodig hebben, zoals productie, preproductie, integratie, enzovoort, kunnen ze indien nodig maken en vernietigen.

Definities van fysieke versus logische omgevingen

U hebt twee opties voor het instellen van uw omgevingsdefinities, fysiek of logisch. Beide hebben verschillende opties en voordelen:

• Fysieke definitie: de elementen van de Microsoft Sentinel-architectuur worden gedefinieerd met de volgende opties voor infrastructuur als code (IaC):
  • Bicep-sjablonen
  • Azure Resource Manager-sjablonen (ARM-sjablonen)
  • Terraform
• Logische definitie: dit fungeert als een abstractielaag voor het instellen van verschillende teams in de groep en het definiëren van hun omgevingen. De definitie wordt ingesteld in de implementatiepijplijn en werkstromen als invoer voor de buildomgeving met behulp van de fysieke infrastructuurlaag.

Houd rekening met deze punten wanneer u uw logische omgevingen definieert:

• Naamconventies
• Omgevingsidentificaties
• Verbinding maken ors en configuraties

Codeopslagplaats

Gezien de omgevingsbenaderingen die in de vorige sectie worden weergegeven, kunt u de volgende organisatie van de GitHub-codeopslagplaats overwegen.

Fysieke definitie: op basis van IaC-opties kunt u nadenken over een benadering die gebruikmaakt van afzonderlijke moduledefinities die zijn gekoppeld aan de hoofdimplementatiedefinitie.

In het volgende voorbeeld ziet u hoe uw code kan worden georganiseerd.

Beperk de toegang tot deze opslagplaats tot het team dat de architectuur op fysiek niveau definieert, waardoor een homogene definitie in de bedrijfsarchitectuur wordt gegarandeerd.

U kunt de vertakkings- en samenvoegstrategie aanpassen aan de implementatiestrategie voor elke organisatie. Als uw team moet beginnen met de definitie, raadpleegt u Een Git-vertakkingsstrategie aannemen.

Zie Gekoppelde en geneste sjablonen gebruiken bij het implementeren van Azure-resources voor meer informatie over ARM-sjablonen.

Zie Bicep-hulpprogramma's installeren voor meer informatie over het instellen van Bicep-omgevingen. Zie De GitHub-stroom voor meer informatie over GitHub.

Logische definities definiëren de omgevingen van een bedrijf. De Git-opslagplaats verzamelt de verschillende definities voor een bedrijf.

In het volgende voorbeeld ziet u hoe uw code kan worden georganiseerd.

De opslagplaats weerspiegelt de pull-acties die door verschillende teams worden uitgevoerd. Meerdere omgevingen worden gedefinieerd door verschillende teams en goedgekeurd door de eigenaren of goedkeurders van het bedrijf.

Het bevoegdheidsniveau voor het uitvoeren van een omgevingsimplementatie is niveau 2. Dit niveau zorgt ervoor dat de resourcegroep en de resources worden gemaakt voor de omgeving met de benodigde beveiliging en privacy. Met dit niveau worden ook de gebruikersmachtigingen ingesteld voor toegestane acties in de productieomgevingen, productie en preproductie.

Organisaties die omgevingen op aanvraag willen testen en ontwikkelen en de mogelijkheid hebben om de omgevingen vervolgens te vernietigen nadat ze zijn getest, kunnen een Azure DevOps-pijplijn of GitHub-acties implementeren. Ze kunnen geplande triggers zo nodig instellen om de omgevingen te vernietigen met behulp van Azure DevOps-gebeurtenissen of GitHub-acties.

Automatische configuratie van Microsoft Sentinel-connectors

Microsoft Sentinel-connectors zijn een essentieel onderdeel van de oplossing die ondersteuning biedt voor het maken van verbinding met verschillende elementen in het landschap van de bedrijfsarchitectuur, zoals Microsoft Entra-id, Microsoft 365, Microsoft Defender, platformoplossingen voor bedreigingsinformatie, enzovoort.

Wanneer u een omgeving definieert, kunt u de configuratie van connectors gebruiken om omgevingen in te stellen met homogene configuraties.

Het inschakelen van connectors als onderdeel van het DevOps-model moet worden ondersteund door het model op service-principalniveau. Deze focus zorgt voor het juiste machtigingsniveau, zoals wordt weergegeven in de volgende tabel.

Verbinding maken orscenario	Niveau van privilege-toegangsmodel	Minimale azure-bevoegdheid	Goedkeuring van werkstroom vereist
Microsoft Entra ID	Niveau 0	globale beheerder of beveiligingsbeheerder	Aanbevolen
Microsoft Entra ID-beveiliging	Niveau 0	globale beheerder of beveiligingsbeheerder	Aanbevolen
Microsoft Defender for Identity	Niveau 0	globale Beheer of beveiligingsbeheerder	Aanbevolen
Microsoft Office 365	Niveau 0	globale beheerder of beveiligingsbeheerder	Aanbevolen
Microsoft Cloud App Security	Niveau 0	globale beheerder of beveiligingsbeheerder	Aanbevolen
Microsoft Defender XDR	Niveau 0	globale beheerder of beveiligingsbeheerder	Aanbevolen
Microsoft Defender voor IOT	Niveau 2	Inzender	Aanbevolen
Microsoft Defender for Cloud	Niveau 2	Beveiligingslezer	Optioneel
Azure-activiteit	Niveau 2	Abonnementslezer	Optioneel
Platformen voor bedreigingsinformatie	Niveau 0	globale beheerder of beveiligingsbeheerder	Aanbevolen
Beveiligingsevenementen	Niveau 4	Geen	Optioneel
Syslog	Niveau 4	Geen	Optioneel
DNS (preview)	Niveau 4	Geen	Optioneel
Windows Firewall	Niveau 4	Geen	Optioneel
gebeurtenissen Windows-beveiliging via AMA	Niveau 4	Geen	Optioneel

Implementatie van Microsoft Sentinel-artefacten

In de implementatie van Microsoft Sentinel-artefacten krijgt DevOps meer relevantie, omdat elk bedrijf meerdere artefacten maakt om aanvallen te voorkomen en te herstellen.

Het implementeren van de artefacten kan de verantwoordelijkheid van één team of meerdere teams zijn. Automatische implementatie van build en artefacten is vaak de meest voorkomende procesvereiste en bepaalt de aanpak en voorwaarden voor uw agents en hardlopers.

Voor het implementeren en beheren van Microsoft Sentinel-artefacten is het gebruik van de Microsoft Sentinel REST API vereist. Zie Microsoft Sentinel REST API voor meer informatie. In het volgende diagram ziet u een Azure DevOps-pijplijn op een Azure REST API-stack.

U kunt uw opslagplaats ook implementeren met behulp van PowerShell.

Als uw team MITRE gebruikt, kunt u overwegen de verschillende artefacten te classificeren en de tactieken en technieken voor elke artefact op te geven. Zorg ervoor dat u een bijbehorend metagegevensbestand opneemt voor elk artefacttype.

Als u bijvoorbeeld een nieuw playbook maakt met behulp van een Azure ARM-sjabloon en de bestandsnaam Playbook.arm.json, voegt u een JSON-bestand toe met de naam Playbook.arm.mitre.json. De metagegevens voor dit bestand bevatten vervolgens de CSV-, JSON- of YAML-indelingen die overeenkomen met de MITRE-tactieken of -technieken die u gebruikt.

Door deze procedure te volgen, kan uw team uw MITRE-dekking evalueren op basis van de taken die worden uitgevoerd tijdens de installatie voor de verschillende artefacttypen die u gebruikt.

Artefacten bouwen

Het doel van uw buildproces is ervoor te zorgen dat u de artefacten van de hoogste kwaliteit genereert. In het volgende diagram ziet u enkele van de buildprocesacties die u kunt uitvoeren.

Een Visio-bestand van deze architectuur downloaden.

• U kunt uw artefactdefinitie baseren op een beschrijvend schema in JSON- of YAML-indeling en vervolgens het schema valideren om syntaxisfouten te voorkomen.
  • Valideer uw ARM-sjablonen met behulp van de TEST-toolkit voor ARM-sjablonen.
  • Valideer uw YAML- en JSON-bestanden voor aangepaste modellen met behulp van PowerShell.
• Valideer de controlelijstinstellingen en zorg ervoor dat de CIDR-records (Classless Inter-Domain Routing) die u definieert, voldoen aan het juiste schema, bijvoorbeeld 10.1.0.0/16.
• Gebruik KQL-query's (Keyword Query Language), die u kunt valideren op het niveau van de syntaxis, voor analyseregels, opsporingsregels en livestreamregels, die u kunt valideren op het niveau van de syntaxis.
• Maak van de lokale KQL-validatie één optie.
• Integreer het hulpprogramma voor inlinevalidatie van KQL in de DevOps-pijplijn.
• Als u logica implementeert die is gebaseerd op PowerShell voor Azure Automation, kunt u syntaxisvalidatie en eenheidstests opnemen met behulp van de volgende elementen:
  • Pester
  • PSScriptAnalyzer
• Genereer het miTRE-manifestmetagegevensrapport op basis van de metagegevensbestanden die zijn opgenomen in de artefacten.

Artefacten exporteren

Meestal werken meerdere teams via verschillende Microsoft Sentinel-exemplaren om de benodigde artefacten te genereren en te valideren. Met het doel om bestaande artefacten opnieuw te gebruiken, kan uw bedrijf automatische processen instellen voor het ophalen van de artefactdefinities uit bestaande omgevingen. Automation kan ook informatie verstrekken over alle artefacten die tijdens de installatie door verschillende ontwikkelteams worden gemaakt.

In het volgende diagram ziet u een voorbeeld van een proces voor artefactextractie.

Een Visio-bestand van deze architectuur downloaden.

Artefacten implementeren

De doelstellingen van uw implementatieproces zijn:

• Verminder de tijd tot de markt.
• Verhoog de prestaties voor meerdere teams die betrokken zijn bij het instellen en beheren van uw oplossing.
• Integratietests instellen om de status van de omgeving te evalueren.

Ontwikkelteams gebruiken het proces om ervoor te zorgen dat ze use cases voor artefacten die in ontwikkeling zijn, kunnen implementeren, testen en valideren. De architectuur- en SOC-teams valideren de kwaliteit van de pijplijn in QA-omgevingen en werken met de integratietests voor aanvalsscenario's. In de testcases combineert een team meestal verschillende artefacten als analyseregels, herstelplaybooks, volglijsten enzovoort. Een deel van elke use case omvat het simuleren van aanvallen waarbij de hele keten wordt geëvalueerd op basis van opname, detectie en herstel.

In het volgende diagram ziet u de implementatieprocesvolgorde die ervoor zorgt dat uw artefacten in de juiste volgorde worden geïmplementeerd.

Een Visio-bestand van deze architectuur downloaden.

Het beheren van Sentinel-artefacten als code biedt u flexibele manieren om uw bewerkingen te onderhouden en de implementatie in een CI/CD DevOps-pijplijn te automatiseren.

Microsoft-oplossingen bieden automatiseringswerkstromen voor de volgende artefacten.

Artefact	Automatiseringswerkstromen
Volglijsten	Codebeoordeling Schemavalidatie Implementatie Watchlists en items maken, bijwerken, verwijderen
Analyseregels samenvoegen Microsoft Beveiliging Ml-gedragsanalyse Anomalie Gepland	Codebeoordeling KQL-syntaxisvalidatie Schemavalidatie Pester Implementatie Maken, inschakelen, bijwerken, verwijderen, exporteren Ondersteuning voor waarschuwingssjablonen
Automatiseringsregels	Codebeoordeling Schemavalidatie Implementatie Maken, inschakelen, bijwerken, verwijderen, exporteren
Connectors	Codebeoordeling Schemavalidatie Implementatie Acties: inschakelen, verwijderen (uitschakelen), bijwerken
Opsporingsregels	Codebeoordeling KQL-syntaxisvalidatie Schemavalidatie Pester Implementatie Acties: maken, inschakelen, bijwerken, verwijderen, exporteren
Draaiboeken	Codebeoordeling TTK Implementatie Acties: maken, inschakelen, bijwerken, verwijderen, exporteren
Werkmappen	Implementatie Acties: maken, bijwerken, verwijderen
Runbooks	Codebeoordeling Validatie van PowerShell-syntaxis Pester Implementatie Acties: maken, inschakelen, bijwerken, verwijderen, exporteren

Afhankelijk van de automatiseringstaal die u kiest, worden sommige automatiseringsmogelijkheden mogelijk niet ondersteund. In het volgende diagram ziet u welke automatiseringsmogelijkheden door taal worden ondersteund.

* Functies in ontwikkeling die nog niet zijn gedocumenteerd
** Automatiseringsmethoden die worden ondersteund door Api's van Microsoft Operational Insights of Microsoft Insights-resourceprovider

Azure Automation

In het volgende diagram ziet u de onderdelen van het vereenvoudigen van Microsoft Sentinel-toegang met beheerde service-identiteit.

Een Visio-bestand van deze architectuur downloaden.

Als u toegang tot andere resources wilt verlenen, gebruikt u beheerde identiteit, die zorgt voor een unieke identiteit voor alle kritieke bewerkingen.

Gebruik Azure Automation voor het instellen van playbooks. Gebruik PowerShell-scripts voor de volgende complexe taken en automatiseringsfuncties:

• Integreren met oplossingen van derden, waarbij verschillende referentieniveaus vereist zijn en op basis van Microsoft Entra-id of aangepaste referenties:
  • Microsoft Entra-gebruikersreferenties
  • Referenties voor de Microsoft Entra-service-principal
  • Verificatie via certificaat
  • Aangepaste referenties
  • Beheerde identiteit
• Het implementeren van een oplossing die organisatiescripts of oplossingen die het gebruik van PowerShell-opdrachten vereisen, gebruiken om complexe vertaling naar playbooks te voorkomen:
  • PowerShell-oplossingen
  • Op Python gebaseerde oplossingen
• Het implementeren van oplossingen in hybride scenario's, waarbij herstelacties van invloed kunnen zijn op uw cloud- en on-premises resources.

Microsoft Sentinel-opslagplaatsen

Ervaren DevOps-teams kunnen overwegen om Microsoft Sentinel in infrastructuur als code (IaC) te beheren met CI/CD-pijplijnen die zijn gebouwd in Azure DevOps. Productgroepen begrijpen de uitdagingen waarmee klanten en partners te maken krijgen bij het bouwen van azure DevOps-beveiligingsarchitectuur, zodat de volgende twee initiatieven kunnen helpen:

• De referentiearchitectuur documenteren
• Een nieuwe oplossing ontwikkelen, aangekondigd op Ignite 2021, die 'Microsoft Sentinel-opslagplaatsen' wordt genoemd

Ter ondersteuning van het kiezen van de oplossing die aansluit bij de behoeften van uw team, vergelijkt de volgende tabel de functionele en technische criteria.

Use case en functies	Aangepaste benadering van Azure DevOps en GitHub	Microsoft Sentinel-opslagplaatsen
We willen snel beginnen met het implementeren van Microsoft Sentinel-artefacten zonder tijd te besteden aan het definiëren van azure DevOps-architectuuronderdelen, zoals agents, pijplijnen, Git, dashboards, een wiki, service-principals, RBAC's, controle, enzovoort.	Niet aanbevolen	Aanbevolen
We hebben kleine teams en weinig vaardighedensets voor het beheren van de CI/CD-pijplijnen.	Niet aanbevolen	Aanbevolen
We willen alle beveiligingsaspecten van de CI/CD-pijplijnen beheren en beheren.	Ondersteund	Niet ondersteund
We moeten poorten en vertakkingen integreren voor het begeleiden van integratie, voordat ontwikkelaars implementatiepijplijnen kunnen activeren, zoals broncodebeheer, coderingsbeoordeling, terugdraaien, goedkeuring van werkstromen, enzovoort.	Ondersteund	Gedeeltelijk ondersteund
We hebben een aangepaste Git- of opslagplaatsstructuur.	Ondersteund	Ondersteund
We gebruiken geen Resource Manager- of Bicep IaC-talen om artefacten te bouwen.	Ondersteund	Niet ondersteund
We willen de implementatie van artefacten centraal beheren in meerdere Microsoft Sentinel-werkruimten in één Microsoft Entra-tenant.	Ondersteund	Ondersteund
We willen CI/CD-pijplijnen integreren of uitbreiden in meerdere Microsoft Entra-tenants.	Ondersteund	Ondersteund
We hebben playbooks met verschillende parameters, afhankelijk van abonnement, locatie, omgeving, enzovoort.	Ondersteund	TBD, richtlijnen die moeten worden gedocumenteerd
We willen verschillende artefacten in dezelfde opslagplaats integreren om use cases op te stellen.	Ondersteund	Ondersteund
We willen dat artefacten bulksgewijs kunnen worden verwijderd.	Ondersteund	Niet ondersteund

Beschikbaarheid, prestaties en schaalbaarheid

Houd rekening met de volgende behoeften bij het kiezen van de architectuur voor de Azure DevOps-agents in uw bedrijf in uw bedrijf voor Microsoft Sentinel-scenario's:

• Voor de productieomgeving is mogelijk een toegewezen agents-pool vereist voor bewerkingen via de Microsoft Sentinel-omgeving.
• Niet-productieomgevingen kunnen de agentgroep delen met een groot aantal exemplaren voor het afhandelen van de verschillende vereisten van de teams, met name voor CI/CD-procedures.
  • Scenario's voor aanvalssimulatie zijn een speciaal geval waarbij toegewezen agents kunnen worden vereist. Overweeg of een toegewezen pool nodig is voor uw testbehoeften.
• Organisaties die aan hybride netwerkscenario's werken, kunnen overwegen om de agents in het netwerk te integreren.

Organisaties kunnen hun eigen installatiekopieën voor agents maken op basis van containers. Zie Een zelf-hostende agent uitvoeren in Docker voor meer informatie.

Microsoft Sentinel-beheer tussen tenants met Azure DevOps

Als globale SOC of MSSP moet u mogelijk meerdere tenants beheren. Azure Lighthouse biedt ondersteuning voor geschaalde bewerkingen in verschillende Microsoft Entra-tenants tegelijk, waardoor uw beheertaken efficiënter worden. Zie Overzicht van Azure Lighthouse voor meer informatie.

Beheer tussen tenants is met name effectief in de volgende scenario's:

• Microsoft Sentinel-resources beheren in tenants van klanten.
• Houd aanvallen bij en bekijk beveiligingswaarschuwingen voor meerdere tenants.
• Incidenten weergeven in meerdere Microsoft Sentinel-werkruimten die zijn verspreid over tenants.

Methoden voor het onboarden van klanten

U hebt twee opties voor het onboarden van klanten, een aanbieding voor beheerde services en een ARM-sjabloon.

Handmatig onboarden met behulp van een ARM-sjabloon

Als u geen aanbieding wilt publiceren naar Azure Marketplace als serviceprovider of als u niet aan alle vereisten voldoet, kunt u klanten handmatig onboarden met behulp van ARM-sjablonen. Dit is de meest waarschijnlijke optie in een enterprise-scenario, waarbij dezelfde onderneming meerdere tenants heeft.

In de volgende tabel worden de onboardingmethoden vergeleken.

Overweging	Aanbieding voor beheerde service	ARM-sjablonen
Vereist een Partnercentrum-account	Ja	Nr.
Vereist het competentieniveau van het Silver- of Gold-cloudplatform of de MSP-status (Azure Expert Managed Services Provider)	Ja	Nr.
Beschikbaar voor nieuwe klanten via Azure Marketplace	Ja	Nr.
Kan aanbieding beperken tot specifieke klanten	Ja (alleen met privéaanbiedingen, die niet kunnen worden gebruikt met abonnementen die zijn ingesteld via een reseller van het CSP-programma)	Ja
Vereist klantacceptatie in Azure Portal	Ja	Nr.
Kan automatisering gebruiken om meerdere abonnementen, resourcegroepen of klanten te onboarden	Nr.	Ja
Biedt directe toegang tot nieuwe ingebouwde rollen en Azure Lighthouse-functies	Niet altijd (algemeen beschikbaar na enige vertraging)	Ja

Zie Een aanbieding voor beheerde services publiceren naar Azure Marketplace voor meer informatie over het publiceren van aanbiedingen voor beheerde services.

Zie ARM-sjablonen maken en implementeren voor meer informatie over het maken van een ARM-sjabloon.

In het volgende diagram ziet u de integratie van architectuur op hoog niveau tussen een MSSP-tenant en de tenants van de resourceprovider van een klant met Azure Lighthouse en Microsoft Sentinel.

Een Visio-bestand van deze architectuur downloaden.

1. Een MSP-aanbieding is geïntegreerd via een ARM-sjabloon of een Azure Marketplace-serviceaanbieding.
2. Door Azure gedelegeerd resourcebeheer controleert of de aanvraag afkomstig is van een partnertenant en roept een beheerde serviceresourceprovider aan.
3. De beheerde serviceresourceprovider gebruikt RBAC om de toegang van de MSP te beheren.
4. De MSP voltooit SecOps-acties voor een klantresource.
5. Het factureringsproces behandelt kosten als klantkosten. Gesplitste facturering is mogelijk als klantentiteiten afzonderlijke werkruimten in dezelfde Microsoft Entra-tenant hebben.
6. De beveiliging en soevereiniteit van de gegevens zijn afhankelijk van de tenantgrens van de klant.

Identiteit tussen meerdere tenants

Als u Microsoft Sentinel wilt beheren met Azure DevOps, evalueert u de volgende ontwerpbeslissingen voor de onderdelen.

Gebruiksscenario	Voordelen
Globale identiteit voor het beheren van DevOps-acties, één service-principal	Dit geval is van toepassing op algemene implementatieprocessen, waarbij alle tenants betrokken zijn. Het gebruik van geïntegreerde identiteit vereenvoudigt de toegang voor de verschillende tenants, maar kan het proces van het beheren van goedkeuringsacties voor specifieke tenants complex maken. Het beveiligingsmechanisme en het autorisatiemodel voor dit soort identiteiten zijn ook erg belangrijk om niet-geautoriseerd gebruik te voorkomen dat dit te wijten is aan de gerelateerde wereldwijde impact.
Toegewezen identiteit voor het beheren van DevOps-acties, meerdere service-principals	Dit geval geldt wanneer implementatieprocessen zijn toegewezen voor elke tenant- of tenantacties goedkeuring vereisen. In dit geval is de aanbeveling voor het beveiligen en autoriseren van dit identiteitsgebruik hetzelfde als in het algemene geval, zelfs als de impact wordt verminderd.

Organisatie van codeopslagplaats

Gebruiksscenario	Voordelen
Geïntegreerde opslagplaats met één codeversie voor alle tenants	In dit geval kunt u uniforme versies voor de code in de opslagplaats gebruiken. In dit geval kan een uniforme versie van de code die een specifieke versie voor tenants beheert, ondersteuning vereisen via vertakkingen voor elke aanvraag.
Geïntegreerde opslagplaats met specifieke codemappen per tenant	Dit geval vormt een aanvulling op de case met één opslagplaats. Hier kan een mapstructuur toegewezen artefacten splitsen op tenant.
Toegewezen opslagplaats per tenant	Deze benadering biedt isolatie bij het beheren van code-artefacten. Het maakt de evolutie tussen tenants met verschillende teams of vereisten eenvoudiger. Het consolideren van wijzigingen vereist het tot stand brengen van een proces tussen opslagplaatsen, wat mogelijk moeite kost om te onderhouden.

Processen voor bouwen en implementeren

Gebruiksscenario	Voordelen
Eén buildproces voor alle tenants	Wanneer alle tenants met dezelfde versie van de artefacten werken, is dit de eenvoudigste optie voor het implementeren van de generatie en het pakket.
Bouwproces per tenant	Er wordt een andere versie van de code geïmplementeerd voor elke tenant.
Globaal implementatieproces voor alle tenants	Nieuwe implementaties en updates voor implementaties zijn van toepassing op alle tenants. De stappen van de implementatie- en updateprocessen worden gebruikt voor alle tenants.
Globale implementatieprocestenant per tenant	Nieuwe implementaties en updates voor implementaties zijn van toepassing op een of meer tenants.
Toegewezen implementatieproces per tenant	Het implementatieproces wordt aangepast voor elke tenant.

Kostenoptimalisatie

Kostenoptimalisatie gaat over het verminderen van onnodige uitgaven en het verbeteren van operationele efficiëntie. Zie Overzicht van de pijler kostenoptimalisatie voor meer informatie.

De kosten van de oplossing zijn afhankelijk van de volgende factoren:

• Het volume aan gegevens dat uw bedrijf maandelijks invoert in de Microsoft Sentinel Log Analytics-werkruimte
• De toezeggingslaag of factureringsmethode die u kiest, zoals betalen per gebruik (PAYG)
• De bewaarsnelheid van het gegevensbeleid op tabel- of globaal niveau

Zie Retentie van Azure-gegevenstypen voor meer informatie.

Als u prijzen wilt berekenen, raadpleegt u de prijscalculator van Microsoft Sentinel. Zie Plankosten voor Microsoft Sentinel voor meer informatie over de geavanceerde prijsoverwegingen en voorbeelden.

U kunt extra kosten in rekening worden gebracht als u uw oplossing uitbreidt met de volgende onderdelen:

• Playbooks: runtimes voor Azure Logic Apps en Azure Functions. Zie prijsinformatie voor meer informatie.
• Exporteren naar externe opslag, zoals Azure Data Explorer, Event Hubs of een Azure Storage-account.
• Een machine learning-werkruimte en de rekenkracht die een Jupyter Notebook-onderdeel gebruikt.

Dit scenario implementeren

In de volgende sectie worden de stappen beschreven voor het implementeren van dit scenario in de vorm van een voorbeeldgebruiksscenario voor de verschillende DevOps-processen.

Het Microsoft Sentinel-framework bouwen en vrijgeven

Stel eerst de benodigde NuGet-onderdelen in een toegewezen opslagplaats in waar verschillende processen de releases kunnen gebruiken die u genereert.

Als u met Azure DevOps werkt, kunt u een onderdeelfeed maken om de verschillende NuGet-pakketten te hosten vanuit het Microsoft Sentinel-framework voor PowerShell. Zie Aan de slag met NuGet-pakketten voor meer informatie.

Als uw team een GitHub-register kiest, kunt u het verbinden als een NuGet-opslagplaats, omdat het compatibel is met het feedprotocol. Zie Inleiding tot GitHub-pakketten voor meer informatie.

Wanneer u een beschikbare NuGet-opslagplaats hebt, bevat de pijplijn een serviceverbinding voor NuGet. Deze schermopnamen tonen de configuratie voor de nieuwe serviceverbinding met de naam Microsoft Sentinel NuGet Framework Verbinding maken ion.

Nadat u de feed hebt geconfigureerd, kunt u de pijplijn importeren voor het bouwen van het PowerShell-framework rechtstreeks vanuit GitHub in een specifieke fork. Zie GitHub-opslagplaatsen bouwen voor meer informatie. In dit geval maakt u een nieuwe pijplijn en kiest u GitHub als de codebron.

Een andere optie is om de Git-opslagplaats te importeren als een Azure DevOps-opslagplaats die is gebaseerd op Git. Geef in beide gevallen het volgende pad op om de pijplijn te importeren:

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

U kunt de pijplijn nu voor het eerst uitvoeren. Vervolgens wordt het framework gebouwd en vrijgegeven aan de NuGet-feed.

Uw Microsoft Sentinel-omgeving definiëren

Wanneer u begint met Microsoft Sentinel en deze voorbeelden gebruikt, definieert u de omgeving in uw bedrijf, bijvoorbeeld Omgeving als Code of EaC. U geeft in elk geval de verschillende elementen op waaruit de omgeving bestaat.

De Architectuur van Microsoft Sentinel bevat de volgende elementen in Azure:

• Log Analytics-werkruimte: deze werkruimte vormt de basis van de oplossing. Informatie over beveiliging wordt hier opgeslagen en de werkruimte is de engine voor Kusto-querytaal (KQL).
• Microsoft Sentinel-oplossing via de Log Analytics-werkruimte: deze oplossing breidt de functionaliteit van de Log Analytics-werkruimte uit met SIEM- en SOAR-mogelijkheden.
• Key Vault: de sleutelkluis bewaart de geheimen en sleutels die worden gebruikt tijdens de herstelprocessen.
• Automation-account: dit account is optioneel en wordt gebruikt voor de herstelprocessen. Het herstelproces dat u gebruikt, is gebaseerd op de PowerShell- en Python-runbooks. Het proces bevat een door het systeem beheerde identiteit die werkt met verschillende resources volgens aanbevolen procedures.
• Door de gebruiker beheerde identiteit: deze functie fungeert als een geïntegreerde Identiteitslaag van Microsoft Sentinel waarmee interacties tussen Microsoft Sentinel-playbooks en runbooks worden beheerd.
• Logic App-verbindingen: dit zijn verbindingen voor Microsoft Sentinel, de sleutelkluis en automatisering die gebruikmaken van de door de gebruiker beheerde identiteit.
• Externe logische app-verbindingen: dit zijn verbindingen voor externe resources die betrokken zijn bij de herstelprocessen en die zijn gebaseerd op de playbooks.
• Azure Event Hubs: deze functie is optioneel en verwerkt integratie tussen Microsoft Sentinel en andere oplossingen, zoals Splunk, Azure Databricks en machine learning en Resilient.
• Opslagaccount: deze functie is optioneel en verwerkt integratie tussen Microsoft Sentinel en andere oplossingen, zoals Splunk, Azure Databricks en machine learning en Resilient.

Met behulp van voorbeelden uit de opslagplaats kunt u de omgeving definiëren met JSON-bestanden om de verschillende logische concepten op te geven. De opties die beschikbaar zijn voor het definiëren van de omgeving, kunnen letterlijk of automatisch zijn.

In een letterlijke definitie geeft u de naam en de elementen voor elke resource in de omgeving op, zoals in dit voorbeeld wordt weergegeven.

{
    {
        "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 een automatische definitie genereren de elementnamen automatisch op basis van naamconventies, zoals in dit voorbeeld wordt weergegeven.

{
    {
        "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
        }
    }
}

U vindt voorbeelden in de GitHub-opslagplaats onder het pad naar microsoft Sentinel-omgevingen en gebruikt de voorbeelden als referentie bij het voorbereiden van uw gebruiksvoorbeelden.

Uw Microsoft Sentinel-omgeving implementeren

Wanneer u ten minste één omgeving hebt gedefinieerd, kunt u de Azure-serviceverbinding maken om te integreren met Azure DevOps. Nadat u de serviceverbinding hebt gemaakt, stelt u de gekoppelde service-principal in op de rol eigenaar of een vergelijkbaar machtigingsniveau voor het doelabonnement.

1. Importeer de pijplijn voor het maken van de nieuwe omgeving zoals gedefinieerd in dit bestand.

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

2. Voer vervolgens de naam in van de serviceverbinding die de omgeving vertegenwoordigt.

   

3. Kies de vertakking voor de omgevingsdefinitie in de opslagplaats. 

4. Voer in het vak Azure Environment Verbinding maken ion de naam in van de Azure DevOps-serviceverbinding voor uw abonnement.

5. Voer de naam in van de omgeving die een serviceverbinding kan gebruiken om meerdere omgevingen in hetzelfde abonnement op te lossen.

6. Kies de actie die u wilt toepassen op de connectors.

7. Selecteer PowerShell Pre-Release Artifacts gebruiken als u de voorlopige versies van de Onderdelen van het PowerShell-framework wilt gebruiken.

De pijplijn bevat de volgende stappen als onderdeel van de implementatiestroom:

• NuGet-onderdelen implementeren.
• Verbinding maken met behulp van NuGet-hulpprogramma's met de opslagplaats voor artefacten.
• Los de feed op.
• Installeer de vereiste modules.
• Haal de omgevingsdefinitie op.
• Controleer welke resources aanwezig zijn in de bestemming.
• Voeg Log Analytics en Microsoft Sentinel toe als ze zich niet in de werkruimte bevinden.
• Als u Al Log Analytics hebt, voegt u Microsoft Sentinel toe via uw exemplaar van Log Analytics.
• Maak een beheerde identiteit voor de interactie tussen Microsoft Sentinel en Logic Apps.
• Maak Azure Key Vault en stel de roltoewijzing in voor het beheren van geheimen en sleutels voor de beheerde identiteit.
• Indien van toepassing, maakt u een Azure Automation-account en schakelt u de door het systeem toegewezen beheerde identiteit in.
• Stel de roltoewijzing in via de sleutelkluis voor de door het systeem toegewezen beheerde identiteit.
• Maak de Event Hubs-definities als deze niet bestaan en stel in of de definitie de integratie-elementen bevat.
• Stel de roltoewijzing in via de sleutelkluis voor de door het systeem toegewezen beheerde identiteit.
• Maak de definities van het opslagaccount als deze niet bestaan en stel in of de definitie de integratie-elementen bevat.
• Stel de roltoewijzing in via de sleutelkluis voor de door het systeem toegewezen beheerde identiteit.
• Implementeer de connectoracties.
• Implementeer het integratierunbook in het Automation-account.
• Implementeer de Logic Apps-verbindingen als ze zijn gedefinieerd als onderdeel van de omgeving.

Een Microsoft Sentinel-omgeving vernietigen

Wanneer de omgeving niet meer nodig is, zoals in het geval van een ontwikkel- of testomgeving, kunt u deze vernietigen zoals gedefinieerd in dit bestand.

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

Net als bij het implementeren van de omgevingspijplijn geeft u de naam op van de serviceverbinding die de omgeving vertegenwoordigt.

Werken met uw Microsoft Sentinel-omgeving

Nadat uw omgeving gereed is, kunt u beginnen met het maken van de artefacten voor het instellen van de verschillende use cases.

1. Exporteer de artefacten uit de omgeving waaraan u werkt zoals gedefinieerd in dit bestand.

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

2. Kies de vertakking voor de omgevingsdefinitie in de opslagplaats.

   

3. Voer de naam in van de Azure DevOps-serviceverbinding voor de omgeving die wordt geëxporteerd in het vak Azure Environment Verbinding maken ion.

4. Selecteer PowerShell Pre-Release Artifacts gebruiken als u de voorlopige versies van de Onderdelen van het PowerShell-framework wilt gebruiken.

5. Kies de notatie voor de analyse- en opsporingsregels.

   Het uitvoerbestand voor artefacten is beschikbaar in de resultaten. Nadat u de artefacten hebt, kunt u het uitvoerbestand opnemen in de Git-opslagplaats.

Uw artefacten bouwen in de Microsoft Sentinel-omgeving

Plaats uw artefacten onder het microsoft Sentinel MITRE-gebruiksscenariopad. Stel de mapstructuur in op basis van de verschillende typen artefacten.

1. Start het buildproces zoals gedefinieerd in dit bestand.

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

2. Kies de vertakking voor de omgevingsdefinitie in de opslagplaats.

   Diagram van het kiezen van de vertakking voor het bouwen van de artefacten.] (./media/build-artifacts-pipeline.png)

3. Selecteer PowerShell Pre-Release Artifacts gebruiken als u de voorlopige versies van de Onderdelen van het PowerShell-framework wilt gebruiken.

De pijplijn bestaat uit deze stappen:

• NuGet-onderdelen implementeren.
• Verbinding maken de NuGet-hulpprogramma's naar de opslagplaats voor artefacten.
• Los de feed op.
• Installeer de vereiste modules.
• Haal het test-toolkitframework op voor het valideren van de ARM-sjablonen.
• Valideer de ARM-sjablonen.
• Valideer de PowerShell-runbookscode en voer syntaxisvalidatie uit.
• Voer de Pester-eenheidstests uit, indien van toepassing.
• Valideer de KQL-syntaxis in de opsporings- en analyseregels.

Uw artefacten implementeren in de Microsoft Sentinel-omgeving

Bij het implementeren van uw artefacten kunt u de Microsoft Sentinel-opslagplaatsen of de voorbeelden van de implementatiepijplijn in deze opslagplaats gebruiken. Zie Aangepaste inhoud implementeren vanuit uw opslagplaats voor meer informatie.

Microsoft Sentinel-opslagplaatsen

Als u Microsoft Sentinel-opslagplaatsen gebruikt, kunt u een releaseproces instellen om de artefacten op te nemen in de opslagplaats die is verbonden met elk Microsoft Sentinel-exemplaar. Nadat de artefacten zijn doorgevoerd in de opslagplaats, worden enkele van de stappen automatisch uitgevoerd als onderdeel van het maken van de pijplijn en het inschakelen van de Microsoft Sentinel-opslagplaatsen.

U kunt ook de implementatieprocessen aanpassen die door de Microsoft Sentinel-opslagplaatsen worden uitgevoerd op basis van procedures die in dit document worden beschreven. Een belangrijk aspect waarmee u rekening moet houden, is de goedkeuring van de release, die u kunt instellen door de volgende benaderingen te volgen:

• PR-goedkeuring bij het doorvoeren van de artefacten. Zie Pull-aanvragen maken voor meer informatie.
• Goedkeuring van releasepijplijn bij het uitvoeren van de implementatie. Zie Goedkeuringen en controles definiëren voor meer informatie.

Voorbeelden van implementatiepijplijnen voor Microsoft Sentinel

Met behulp van de voorbeelden van de Implementatiepijplijn van Microsoft Sentinel kunt u een releaseproces instellen.

1. Stel het releaseproces in zoals gedefinieerd in dit bestand.

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

2. Kies de vertakking voor de omgevingsdefinitie in de opslagplaats.

   

3. Voer de naam in van de Azure DevOps-serviceverbinding voor de omgeving die wordt geëxporteerd in het vak Azure Environment Verbinding maken ion.

4. Selecteer PowerShell Pre-Release Artifacts gebruiken als u de voorlopige versies van de Onderdelen van het PowerShell-framework wilt gebruiken.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Hoofdauteur:

• Kevin Kisoka | Associate Architect

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen

• Zie Microsoft Sentinel implementeren en beheren als code voor meer informatie over Microsoft Sentinel met DevOps voor architectuur met één tenant.
• Zie Azure Lighthouse combineren met devOps-mogelijkheden van Microsoft Sentinel voor meer informatie over mssp-architectuur met meerdere tenants.
• Zie Wat is er nieuw voor beheerde identiteiten met Microsoft Sentinel : Beheerde identiteit voor Microsoft Sentinel Logic Apps-connector.
• Zie Aangepaste inhoud implementeren vanuit uw opslagplaats voor meer informatie over het implementeren van inhoud uit een Microsoft Sentinel-opslagplaats.
• Zie de snelzoekgids voor standaardmachtigingen voor meer informatie over azure DevOps-beveiligingsoverwegingen.
• Zie Beveiliging toevoegen aan een opslagplaatsresource voor meer informatie over het beveiligen van een Azure DevOps-opslagplaats.
• Zie Serviceverbindingen in Azure Pipelines voor informatie over het beheren van azure DevOps-serviceverbindingsbeveiliging.

Verwante resources

• Hybride beveiligingsbewaking met Microsoft Defender voor cloud en Microsoft Sentinel
• Een CI/CD-pijplijn ontwerpen met behulp van Azure DevOps
• Geavanceerde ARM-sjabloonfunctionaliteit