Sentinel-integratie automatiseren met Azure DevOps

Azure Active Directory
Azure DevOps
Key Vault
Azure Security Center
Microsoft Sentinel

Soc-teams (Security Operations Center) ervaren uitdagingen bij het integreren van Microsoft Sentinel met Azure DevOps. Het proces omvat veel stappen en de installatie kan dagen duren met een constante herhaling. U kunt dit deel van de ontwikkeling automatiseren.

Cloudmodernisatie betekent dat technici voortdurend nieuwe vaardigheden en technieken moeten leren voor het beveiligen en beschermen van essentiële bedrijfsactiva. Technici moeten robuuste en schaalbare oplossingen bouwen die voldoen aan de steeds veranderende beveiligingslandschap en bedrijfsbehoeften. De beveiligingsoplossing moet flexibel, flexibel en zorgvuldig worden gepland vanaf de vroegste stadia van ontwikkeling, ook wel shift-left genoemd.

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

U kunt zelfs de oplossing uitbreiden om complexe organisaties te behandelen die meerdere entiteiten, abonnementen en verschillende operationele modellen hebben. Enkele van de operationele modellen die door deze oplossing worden ondersteund, zijn lokale SOC, globale SOC, cloudserviceprovider (CSP) en een beheerde BEVEILIGINGSserviceprovider (MSSP).

Dit artikel ondersteunt de volgende doelgroepen:

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

Potentiële gebruikscases

Hieronder volgen de typische use cases voor deze architectuur:

  • Snelle prototypen en proof-of-concept: deze oplossing is ideaal voor beveiligingsorganisaties en SOC-teams die de dekking van cloudbedreigingen willen verbeteren of hun SIEM-infrastructuur willen moderniseren met infrastructuur als code (IaC) en Microsoft Sentinel.
  • Microsoft Sentinel as a Service: dit ontwikkelingsframework integreert de principes voor levenscyclusbeheer van services. Deze principes zijn geschikt voor eenvoudige of complexe teams, zoals MSSP's die herhaalbare, gestandaardiseerde acties uitvoeren in meerdere tenants van klanten en tegelijkertijd de kracht van Azure DevOps en Azure Lighthouse combineren. 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 bedreigingsdetectie: veel groepen en bedreigingsinformatieplatforms zijn afhankelijk van MITRE Att&ck-inhoud en taxonomie om hun beveiligingspostuur te analyseren tegen geavanceerde handelsactiviteiten 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.

Diagram van een MITRE Att&ck-cloudscenario.

Een Visio-bestand van deze architectuur downloaden.

Architectuur

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

Diagram van de architectuur voor het automatiseren van een Microsoft Sentinel Infra als codepijplijn.

Gegevensstroom

  1. De scrummaster en het productbeheer gebruiken Azure DevOps om epics, gebruikersverhalen en productachterstanditems te definiëren als onderdeel van de projectachterstand.
    • De scrummaster en 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 opgeslagen en de vergunningen 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:
    • Beleid: 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-gegevensconnectors, om beveiligingsgegevens, zoals in controles of metrische gegevens, op te nemen uit ondersteunde gegevensbronnen, zoals Azure Active Directory (Azure AD), 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 Azure Policy diagnostische instellingen.
    • Beheerde identiteit: Microsoft Sentinel gebruikt 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 te correleren of playbooks te activeren als er 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.
    • Bedreigingsjagers gebruiken proactieve opsporingsmogelijkheden voor 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 die bedreigingsinformatieplatforms combineert met Microsoft Sentinel. Er worden twee connectiviteitsmethoden ondersteund: TAXII en Graph API. Beide methoden fungeren als tiIndicators of bedreigingsinformatie-indicatoren in beveiligings-API's.
  3. Azure AD : 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 voor Microsoft Sentinel, logische apps en automatiseringsrunbooks.
  4. Azure-pijplijnen: 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 om 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 bij of verwijdert een vermelding in de fork van het Microsoft 365-configuratiebestand.
  2. De beheerder verbindt 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

Deze architectuur maakt gebruik van de volgende onderdelen:

  • Azure Active Directory 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 om de betrouwbaarheid, efficiëntie en de waarde van uw bedrijf te verbeteren.

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 informatie die wordt 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 persoon ervan kan profiteren 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.
Detectie Analyseproces op hoog niveau, sensoren, gegevens en detectiestrategieën die nuttig zijn bij het identificeren van een techniek die door een kwaadwillende persoon wordt gebruikt. Deze sectie informeert degenen die verantwoordelijk zijn voor het detecteren van kwaadwillend gedrag, zoals netwerkverdedigers, zodat ze een actie kunnen ondernemen, zoals het schrijven van een analyse of het implementeren van een sensor. Er moet voldoende informatie en verwijzingen zijn om nuttige defensieve methodologieën aan te wijzen. Detectie is mogelijk niet altijd mogelijk voor een bepaalde techniek en moet als zodanig worden gedocumenteerd. Opsporing van analyserisico's
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 netwerk defenders 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 netwerk defenders of beleidsmakers kunt verminderen. Hierin worden de 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 beveiliging verhoogt automatisering in het algemeen de efficiëntie van bewerkingen en bespaart u tijd voor complexere use cases, zoals engineering voor detectie van bedreigingen, bedreigingsinformatie, SOC en SOAR-use cases. 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 Azure AD service-principals en beheerde identiteiten genoemd.

De volgende tabel bevat een overzicht van beveiligingsoverwegingen voor service-principals en de belangrijkste gebruiksvoorbeelden die worden behandeld door De release-pijplijnen van Microsoft Sentinel en Azure DevOps.

Gebruiksvoorbeeld 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-naam Gebruik de sleutelkluis om SPN-geheimen (Service Principal Name) en certificaat op te slaan.

SPN-controle inschakelen.

Controleer regelmatig de machtigingstoewijzing (Azure Privileged Identity Management voor SPN) of verdachte activiteit voor SPN.

Gebruik Azure AD certificeringsinstanties en meervoudige verificatie (indien ondersteund) voor bevoegde accounts.

Gebruik Azure AD aangepaste 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-naam Gebruik goedkeuring van ADO-werkstromen (Azure DevOps) en controleert of u pijplijnimplementatie met deze SPN wilt beveiligen.
Een beleid toewijzen voor het configureren van functies voor logboekstreaming 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-naam Gebruik Microsoft Azure Active Directory (Azure AD), CA en MFA, wanneer dit wordt ondersteund voor bevoegde accounts.

* Alleen zorgen Azure AD diagnostische instellingen.
** Specifieke connectors hebben aanvullende machtigingen nodig, zoals 'beveiligingsbeheerder' of 'inzender voor resourcebeleid' om streaminggegevens toe te staan aan de Microsoft Sentinel-werkruimte, Azure AD, 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 geprivilegieerd toegangsmodel te gebruiken om de risico's voor uw bedrijf snel te verlagen van aanvallen met hoge impact en hoge waarschijnlijkheid op bevoorrechte 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 veroorzaakt zeer negatieve gevolgen. Bevoegde identiteiten hebben toegang tot bedrijfskritieke assets, wat vrijwel altijd grote gevolgen heeft wanneer aanvallers deze accounts in gevaar komen.

Beveiliging van bevoegde toegang is essentieel, 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 verspreiden 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.

Diagram van de gelaagde architectuur voor een geprivilegieerd toegangsmodel in een pijplijn.

Download een PowerPoint-bestand van deze architectuur.

Service-principals op niveau 0

Service-principals op niveau 0 hebben het hoogste machtigingsniveau. Deze service-principals geven iemand de opdracht 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, dus we raden u aan 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 sterk 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 organisatieniveau. Deze service-principals geven iemand de 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 sterk 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 de 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 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 sterk aan om de sleutelkluis te vinden in een toegewezen beheerresourcegroep.

Service-principals op niveau 3

Service-principals van niveau 3 zijn beperkt tot de workloadbeheerder. 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 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 sterk 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 de opdracht 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.

DevOps

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. Uw belangrijkste zorg voor dit blok is om rekening te houden met het aantal productie- en niet-productieomgevingen dat moet worden geïmplementeerd en zorg er vervolgens voor 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 het coderen, implementeren en gebruiken of vernietigen van de onderdelen. Dit blok bevat bijvoorbeeld de analyseregels, 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 versiebeheer
    • Een bijgewerkte of volledig 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 het 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-hostend, zelf-hostend of een combinatie van beide modellen gebruiken.

Door GitHub gehoste runners

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

Zelf-hostende runners

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 runners

Houd rekening met de volgende behoeften bij het kiezen van opties voor de agents en runners 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 is vereist tot kritieke resources of resources 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 Understanding 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.
  • Implementatiegoedkeuring integreren 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 Infrastructure as 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
  • Connectors en configuraties

Codeopslagplaats

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

Fysieke definitie: op basis van IaC-opties moet 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.

Diagram van een mogelijke codeorganisatie in GitHub voor een definitie van een fysieke omgeving.

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 vertakking en samenvoegingsstrategie aanpassen aan de implementatiestrategie voor elke organisatie. Als uw team moet beginnen met de definitie, raadpleegt u Een Git-vertakkingsstrategie gebruiken.

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.

Diagram van een mogelijke codeorganisatie in GitHub voor een logische omgevingsdefinitie.

De opslagplaats weerspiegelt de pull-acties die door verschillende teams worden gemaakt. 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 voor de omgeving worden gemaakt met de benodigde beveiliging en privacy. Op dit niveau worden ook de gebruikersmachtigingen ingesteld voor toegestane acties in de productieomgevingen, productie en preproductie.

Organisaties die op aanvraag omgevingen 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 architectuurlandschap van de onderneming, zoals Azure AD, Microsoft 365, Microsoft Defender, platformoplossingen voor bedreigingsinformatie, enzovoort.

Bij het definiëren van een omgeving maakt de configuratie van connectors het mogelijk om omgevingen met homogene configuraties in te stellen.

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.

Connectorscenario Toegangsmodelniveau voor bevoegdheden Minimale azure-bevoegdheid Goedkeuring van werkstroom vereist
Azure AD Niveau 0 globale beheerder of beveiligingsbeheerder Aanbevolen
Azure AD Identity Protection 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 365 Defender 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
Windows-beveiliging gebeurtenissen via AMA Niveau 4 Geen Optioneel

Implementatie van Microsoft Sentinel-artefacten

Microsoft Sentinel-artefacten zijn de plek waar DevOps meer relevantie krijgt, omdat elk bedrijf meerdere artefacten maakt voor het voorkomen en oplossen van aanvallen.

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 in een Azure REST API-stack.

Diagram van een Azure DevOps-pijplijn in De API-stack van Microsoft Sentinel.

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 type artefact.

Als u bijvoorbeeld een nieuw playbook maakt met behulp van een Azure ARM-sjabloon en de bestandsnaam Playbook.arm.json is, voegt u een JSON-bestand met de naam Playbook.arm.mitre.json toe. 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 tijdens de installatie worden uitgevoerd voor de verschillende artefacttypen die u gebruikt.

Artefacten bouwen

Het doel van uw buildproces is om 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.

Buildproces van Microsoft Sentinel.

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 de watchlist-instellingen en zorg ervoor dat de CIDR-records (Classless Inter-Domain Routing) die u definieert, het juiste schema volgen, bijvoorbeeld 10.1.0.0/16.
  • Gebruik KQL-query's (trefwoordquerytaal), 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 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:
  • 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 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. Automatisering kan ook informatie verstrekken over artefacten die tijdens de installatie door verschillende ontwikkelteams worden gemaakt.

In het volgende diagram ziet u een voorbeeld van het extractieproces voor artefacten.

Extractieproces voor Microsoft Sentinel-artefacten.

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.
  • Stel integratietests in 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, watchlists, 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 reeks implementatieprocessen die ervoor zorgt dat uw artefacten in de juiste volgorde worden geïmplementeerd.

Implementatieproces voor Microsoft Sentinel-artefacten.

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
Volglijsten 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
Playbooks 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 worden ondersteund door taal.

Diagram van de grafiek met ondersteunde automatiseringsmogelijkheden.

* 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.

Diagram van het vereenvoudigen van Microsoft Sentinel-toegang met beheerde service-identiteit.

Een Visio-bestand van deze architectuur downloaden.

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

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

  • Integratie met oplossingen van derden, waarbij verschillende referentieniveaus vereist zijn en op basis van Azure AD of aangepaste referenties:
    • gebruikersreferenties Azure AD
    • referenties voor Azure AD 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, implementeren om complexe vertaling naar playbooks te voorkomen:
    • Op PowerShell gebaseerde 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 Infra 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 een Azure DevOps-beveiligingsarchitectuur, zodat de volgende twee initiatieven u kunnen helpen:

  • De referentiearchitectuur documenteren
  • Een nieuwe oplossing ontwikkelen, aangekondigd op Ignite 2021, dat '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 vaardigheden om de CI/CD-pijplijnen te beheren. 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 supervisieintegratie, 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 Azure AD tenant. Ondersteund Ondersteund
We willen CI/CD-pijplijnen integreren of uitbreiden in meerdere Azure AD 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 agentspool 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 Azure AD tenants tegelijkertijd, 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:

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 ondernemingsscenario, 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 Nee
Vereist het competentieniveau van het Silver- of Gold-cloudplatform of de MSP-status (Azure Expert Managed Services Provider) Ja Nee
Beschikbaar voor nieuwe klanten via Azure Marketplace Ja Nee
Kan aanbieding beperken tot specifieke klanten Ja (alleen met privéaanbiedingen, die niet kunnen worden gebruikt met abonnementen die tot stand zijn gebracht via een reseller van het CSP-programma) Ja
Vereist acceptatie van klanten in Azure Portal Ja Nee
Kan automatisering gebruiken om meerdere abonnementen, resourcegroepen of klanten te onboarden Nee Ja
Biedt directe toegang tot nieuwe ingebouwde rollen en Azure Lighthouse-functies Niet altijd (algemeen beschikbaar na enige vertraging) Ja

Zie Een beheerde serviceaanbieding 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 resourceprovidertenants van een klant met Azure Lighthouse en Microsoft Sentinel.

Diagram van een door Microsoft Sentinel beheerde serviceidentiteitsarchitectuur.

  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 resourceprovider van de beheerde service gebruikt RBAC om de toegang van de MSP te beheren.
  4. De MSP voltooit SecOps-acties voor een klantresource.
  5. Het factureringsproces behandelt onkosten als klantkosten. Gesplitste facturering is mogelijk als klantentiteiten afzonderlijke werkruimten in dezelfde Azure AD 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.

Gebruiksvoorbeeld 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 wanneer de impact wordt verminderd.
Organisatie van codeopslagplaats
Gebruiksvoorbeeld 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, met een uniforme versie van de code die specifieke versie voor tenant beheert, ondersteuning vereisen via vertakkingen voor elk geval.
Geïntegreerde opslagplaats met specifieke codemappen per tenant. In dit geval wordt de case met één opslagplaats aangevuld. Hier kan een mapstructuur toegewezen artefacten splitsen per tenant.
Toegewezen opslagplaats per tenant Deze aanpak biedt isolatie bij het beheren van codeartefacten. 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.
Bouw- en implementatieprocessen
Gebruiksvoorbeeld 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.
Tenant voor globaal implementatieproces 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.

Prijzen

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

  • Het aantal 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 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 berekening 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.

Schermopname van het maken van een onderdeelfeed voor het hosten van de NuGet-pakketten.

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. In deze schermopnamen ziet u de configuratie voor de nieuwe serviceverbinding met de naam Microsoft Sentinel NuGet Framework Connection.

Schermopname van het maken van een nieuwe serviceverbinding.

Schermopname van het bewerken van een serviceverbinding.

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

Nu kunt u de pijplijn voor het eerst uitvoeren. Vervolgens wordt het framework gebouwd en uitgebracht in 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. Beveiligingsgerelateerde informatie wordt hier opgeslagen en de werkruimte is de engine voor Kusto-querytaal (KQL).
  • Microsoft Sentinel-oplossing voor 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 tijdens de herstelprocessen worden gebruikt.
  • 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 best practices.
  • 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.
  • Logische 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 wordt weergegeven in dit voorbeeld.

{
    {
        "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 kunt voorbeelden vinden in de GitHub-opslagplaats onder het pad naar de Microsoft Sentinel-omgevingen en de voorbeelden gebruiken 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.

    Schermopname van het invoeren van de naam van de serviceverbinding.

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

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

  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 verbindingslijnen.

  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.
  • Maak verbinding 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 in het doel aanwezig zijn.
  • 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 om de interactie tussen Microsoft Sentinel en Logic Apps weer te geven.
  • Maak Azure Key Vault en stel de roltoewijzing in voor het beheren van geheimen en sleutels voor de beheerde identiteit.
  • Maak, indien van toepassing, een Azure Automation-account en schakel 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 opslagaccountdefinities 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 deze 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.

    Schermopname van het kiezen van een vertakking voor het exporteren van de artefacten.

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

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

  5. Kies de indeling 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 pad naar Microsoft Sentinel MITRE-use cases. 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.
  • Verbind de NuGet-hulpprogramma's met de opslagplaats 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 indien van toepassing de Pester-eenheidstests uit.
  • 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 in de opslagplaats op te nemen die zijn verbonden met elk Microsoft Sentinel-exemplaar. Nadat de artefacten zijn doorgevoerd in de opslagplaats, worden sommige 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 deze benaderingen te volgen:

Voorbeelden van implementatiepijplijnen voor Microsoft Sentinel

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

  1. Stel uw 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.

    Schermopname van het kiezen van de vertakking voor het instellen van het releaseproces.

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

  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 bijgewerkt en onderhouden door Microsoft. Het is oorspronkelijk geschreven door de volgende inzenders.

Hoofdauteurs:

Volgende stappen