I den här artikeln beskrivs hur du automatiserar microsoft Sentinel-integrerings- och distributionsåtgärder med Azure DevOps. Du implementerar Azure DevOps med hjälp av Microsoft Sentinel-funktioner för att skydda distributionen. Sedan använder du ett DevSecOps-ramverk för att hantera och distribuera Microsoft Sentinel-artefakter i stor skala.
Arkitektur
Följande diagram visar en Azure DevOps- och Microsoft Sentinel IaC-konfiguration.
Ladda ned en Visio-fil med den här arkitekturen.
Dataflöde
- Scrum Master och produkthantering använder Azure DevOps för att definiera epos, användarberättelser och produkteftersläpningar som en del av kvarvarande projekt.
- Scrum Master och produkthantering använder Azure Boards för att skapa kvarvarande uppgifter, schemalägga arbete i sprintar, granska projekttavlan, skapa lagringsplatsens struktur och ange säkerhetsregler som arbetsflöden och grenar för godkännande.
- Azure Git-lagringsplatsen lagrar skripten och tillstånden för att hantera Microsoft Sentinel-artefakter i infrastrukturen som kod.
- Artefakter och källkontroll underhåller tillägg och uppdateringspaket eller komponenter i DevSecOps-arbetsflödet som används i lösningen, till exempel Azure Resource Manager Template Toolkit och PowerShell Pester.
- Microsoft Sentinel-artefakter:
- Principer. SIEM-tekniker använder Azure-principer i referensarkitekturen för att konfigurera och skala diagnostikinställningarna för Azure-tjänsterna. Principerna hjälper till att automatisera distributionen av Microsoft Sentinel-dataanslutningarna, till exempel Azure Key Vault. Principerna är beroende av OMSIntegration-API:et.
- Anslutningsprogram. Microsoft Sentinel använder logiska anslutningsappar, Azure Data Connectors, för att mata in säkerhetsdata, som i granskningar eller mått, från datakällor som stöds, till exempel Microsoft Entra-ID, Azure-resurser, Microsoft Defender eller lösningar från tredje part. Huvudlistan över dataanslutningar hanteras av SecurityInsights-API:et. Andra förlitar sig på OMSIntegration-API:et och hanteras med diagnostikinställningarna för Azure Policy.
- Hanterad identitet. Microsoft Sentinel använder hanterad identitet för att agera på uppdrag av den hanterade tjänstidentiteten (MSI) när de interagerar med spelböcker, logikappar eller Automation-runbooks och nyckelvalvet.
- Automatisering. SOC-team använder automatisering under undersökningar. SOC-team kör procedurer för insamling av digitala kriminaltekniska data med Azure Automation, till exempel kedjan för lagring av virtuella Azure-datorer (VM) eller eDiscovery (Premium) för Microsoft Defender.
- Analys. SOC-analytiker eller hotjägare använder inbyggda eller anpassade analysregler för att analysera och korrelera data i Microsoft Sentinel eller för att utlösa spelböcker om ett hot och en incident identifieras.
- Spelböcker. Logikappar kör secops-repeterbara åtgärder, till exempel att tilldela en incident, uppdatera en incident eller vidta reparationsåtgärder, till exempel isolera eller innehålla en virtuell dator, återkalla en token eller återställa ett användarlösenord.
- Jakt på hot. Hotjägare använder proaktiva hotjaktfunktioner som kan kopplas till Jupyter Notebooks för avancerade användningsfall, till exempel databehandling, datamanipulering, datavisualisering, maskininlärning eller djupinlärning.
- Arbetsböcker. SIEM-tekniker använder instrumentpaneler för arbetsböcker för att visualisera trender och statistik och för att visa status för en Microsoft Sentinel-instans och dess underkomponenter.
- Hotinformation. En specifik dataanslutning som kombinerar plattformar för hotinformation matas in i Microsoft Sentinel. Två anslutningsmetoder stöds: TAXII och Graph API. Båda metoderna fungerar som tiIndicatorer, eller hotinformationsindikatorer, i säkerhets-API:er.
- Microsoft Entra-ID. Funktioner för identitets- och åtkomsthantering levereras till komponenter som används i referensarkitekturen, till exempel hanterade identiteter, tjänstens huvudnamn, Rollbaserade åtkomstkontroller i Azure (RBACs) för Microsoft Sentinel, logikappar och Automation-runbooks.
- Azure Pipelines. DevOps-tekniker använder pipelines för att skapa tjänstanslutningar för att hantera olika Azure-prenumerationer som sandbox- och produktionsmiljöer med CI/CD-pipelines (kontinuerlig integrering och kontinuerlig leverans). Vi rekommenderar att du använder arbetsflöden för godkännande för att förhindra oväntade distributioner och avgränsade tjänsthuvudnamn om du riktar in dig på flera prenumerationer per Azure-miljö.
- Azure Key Vault. SOC-tekniker använder nyckelvalvet för att lagra hemligheter och certifikat för tjänstens huvudnamn på ett säkert sätt. Den här komponenten i arkitekturen hjälper till att framtvinga DevSecOps-principen om inga hemligheter i kod när den används av Azure Pipeline-tjänstanslutningar.
- En Azure-prenumeration. SOC-teamen använder två instanser av Microsoft Sentinel i den här referensarkitekturen, avgränsade inom två logiska Azure-prenumerationer för att simulera produktions- och sandbox-miljöer. Du kan skala efter dina behov med andra miljöer, till exempel testning, utveckling, förproduktion och så vidare.
Exempel på dataflöde
- En administratör lägger till, uppdaterar eller tar bort en post i sin förgrening av Microsoft 365-konfigurationsfilen.
- Administratören checkar in och synkroniserar ändringarna till sin förgrenade lagringsplats.
- Administratören skapar sedan en pull-begäran (PR) för att sammanfoga ändringarna till huvudlagringsplatsen.
- Bygg-pipelinen körs på PR.
Komponenter
- Microsoft Entra ID är en molnbaserad tjänst för att hantera dina identitets- och åtkomstkontroller.
- Azure DevOps är en molntjänst som samarbetar med kod, skapar och distribuerar appar eller planerar och spårar ditt arbete.
- Azure Key Vault är en molntjänst för säker lagring och åtkomst till hemligheter. En hemlighet är allt som du vill kontrollera åtkomsten till, till exempel API-nycklar, lösenord, certifikat eller kryptografiska nycklar.
- Azure Policy är en tjänst för att skapa, tilldela och hantera principdefinitioner i din Azure-miljö.
- Microsoft Sentinel är en skalbar, molnbaserad, SIEM- och säkerhetsorkestreringslösning, automatisering och svarslösning (SOAR).
- Azure Automation är en tjänst för att förenkla molnhanteringen genom processautomatisering. Använd Azure Automation för att automatisera långvariga, manuella, felbenägna och ofta upprepade uppgifter. Automation hjälper till att förbättra tillförlitlighet, effektivitet och tid till värde för ditt företag.
Information om scenario
SOC-team (Security Operations Center) upplever ibland utmaningar när de integrerar Microsoft Sentinel med Azure DevOps. Processen omfattar många steg, och installationen kan ta dagar och innebära upprepning. Du kan automatisera den här delen av utvecklingen.
För att modernisera för molnet måste ingenjörer ständigt lära sig nya färdigheter och tekniker för att skydda viktiga affärstillgångar. Ingenjörer måste skapa robusta och skalbara lösningar som håller jämna steg med det föränderliga säkerhetslandskapet och med affärsbehov. En säkerhetslösning måste vara flexibel, flexibel och noggrant planerad från de tidigaste utvecklingsstegen. Den här metoden för tidig planering kallas skift-vänster.
I den här artikeln beskrivs hur du automatiserar microsoft Sentinel-integrerings- och distributionsåtgärder med Azure DevOps. Du kan utöka lösningen för komplexa organisationer som har flera entiteter, prenumerationer och olika driftsmodeller. Några av de driftsmodeller som stöds av den här lösningen är lokal SOC, global SOC, molntjänstleverantör (CSP) och mssp (managed security service provider).
Den här artikeln är avsedd för följande målgrupper:
- SOC-specialister, som analytiker och hotjägare
- SiEM-tekniker (Säkerhetsinformation och händelsehantering)
- Cybersäkerhetsarkitekter
- Utvecklare
Potentiella användningsfall
Följande är vanliga användningsfall för den här arkitekturen:
- Snabba prototyper och konceptbevis. Den här lösningen är perfekt för säkerhetsorganisationer och SOC-team som vill förbättra molnhottäckningen eller modernisera sin SIEM-infrastruktur med infrastruktur som kod (IaC) och Microsoft Sentinel.
- Microsoft Sentinel som en tjänst. Det här utvecklingsramverket integrerar principer för hantering av tjänstlivscykel. Dessa principer passar enkla eller komplexa team som MSSP:er som kör repeterbara, standardiserade åtgärder i flera kundklientorganisationer samtidigt som de kombinerar kraften i Azure DevOps och Azure Lighthouse. Ett team som till exempel behöver publicera Microsoft Sentinel-användningsfall för en ny hotskådespelare eller pågående kampanj kan använda den här lösningen.
- Skapa SOC-användningsfall för hotidentifiering. Många grupper och plattformar för hotinformation förlitar sig på MITRE Att&ck-innehåll och taxonomi för att analysera deras säkerhetsstatus mot avancerade tekniker och taktiker. Lösningen definierar en strukturerad metod för att utveckla metoder för hotidentifiering genom att införliva MITRE Att&ck-terminologi i utveckling av Microsoft Sentinel-artefakter.
Följande bild visar ett MITRE Att&ck-molnscenario.
Ladda ned en Visio-fil med den här arkitekturen.
Scenarier för hotdefinitionsattacker baserade på MITRE
Den här tabellen visar termer, definitioner och information om viktiga aspekter av attackscenarier.
| Dataobjekt | beskrivning | Microsoft Sentinel-artefakter |
|---|---|---|
| Title | Beskrivande namn för attackscenariot baserat på attackvektoregenskaper eller teknikbeskrivningar. | MITRE-manifest |
| MITRE ATT&CK-taktik | MITRE ATT&CK-taktik relaterad till attackscenario | MITRE-manifest |
| MITRE ATT&CK-tekniker | MITRE ATT&CK-tekniker, inklusive teknik- eller underteknik-ID, relaterade till attackscenariot. | MITRE-manifest |
| Dataanslutningskällor | Informationskälla som samlas in av en sensor eller ett loggningssystem som kan användas för att samla in information som är relevant för att identifiera den åtgärd som utförs, sekvens av åtgärder eller resultatet av dessa åtgärder av en angripare. | Microsoft Sentinel-dataanslutning eller anpassad loggkälla |
| beskrivning | Information om tekniken, vad den är, vad den vanligtvis används till, hur en angripare kan dra nytta av den och variationer om hur den kan användas. Innehåller referenser till auktoritativa artiklar som beskriver teknisk information som rör tekniken samt i de vilda användningsreferenserna efter behov. | |
| Detection | Analysprocesser på hög nivå, sensorer, data och identifieringsstrategier som är användbara för att identifiera en teknik som har använts av en angripare. Det här avsnittet informerar de som ansvarar för att identifiera angripares beteende, till exempel nätverksförsvarare, så att de kan vidta åtgärder som att skriva en analys eller distribuera en sensor. Det bör finnas tillräckligt med information och referenser för att peka mot användbara defensiva metoder. Identifiering kanske inte alltid är möjligt för en viss teknik och bör dokumenteras som sådan. | Analyshotjakt |
| Riskreducering | Konfigurationer, verktyg eller processer som förhindrar att en teknik fungerar eller har önskat resultat för en angripare. Det här avsnittet informerar de ansvariga för att mildra mot angripare, till exempel nätverksförsvarare eller beslutsfattare, så att de kan vidta åtgärder som att ändra en princip eller distribuera ett verktyg. Riskreducering kanske inte alltid är möjligt för en viss teknik och bör dokumenteras som sådan. | |
| Riskreducering | Konfigurationer, verktyg eller processer som förhindrar att en teknik fungerar eller har önskat resultat för en angripare. I det här avsnittet beskrivs hur du minskar effekterna av angrepp mot nätverk för nätverksförsvarare eller beslutsfattare. Den beskriver steg för att ändra en princip eller distribuera ett verktyg. Riskreducering kanske inte alltid är möjligt för en viss teknik och bör dokumenteras som sådan. | Spelböcker, Automation Runbooks |
Att tänka på
Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, en uppsättning vägledande grundsatser som du kan använda för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Microsoft Azure Well-Architected Framework.
Säkerhet
Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i Översikt över säkerhetspelare.
Med säkerhet ökar automatiseringen i allmänhet drifteffektiviteten samtidigt som du sparar tid för mer komplexa användningsfall, till exempel teknik för hotidentifiering, hotinformation, SOC och SOAR-användning. DevOps-team behöver veta var de kan använda IaC på ett säkert sätt i samband med Microsoft Sentinel CI/CD. Den här processen introducerar användningen av specifika identiteter som används av icke-mänskliga konton i Microsoft Entra-ID som kallas tjänstens huvudnamn och hanterade identiteter.
I följande tabell sammanfattas säkerhetsöverväganden för tjänstens huvudnamn och de huvudsakliga användningsfall som omfattas av Microsoft Sentinel- och Azure DevOps-versionspipelines.
| Användningsfall | Krav (minst behörighet) | Varaktighet för rolltilldelning | Behörighetsomfång | Förvaltare | Säkerhetsfrågor |
|---|---|---|---|---|---|
| Aktivera Microsoft Sentinel-anslutningsappar | Säkerhetsadministratör** Ägare* Microsoft Sentinel-deltagare Läsare |
JIT (engångsaktivering) I syfte (varje gång en ny prenumeration och anslutningsprogram distribueras) |
Klientorganisation | SPN | Använd nyckelvalvet för att lagra SPN-hemligheter (service principal name) och certifikat. Aktivera SPN-granskning. Granska med jämna mellanrum behörighetstilldelningen (Azure Privileged Identity Management för SPN) eller misstänkt aktivitet för SPN. Använd Microsoft Entra-certifikatutfärdare och multifaktorautentisering (när det stöds) för privilegierade konton. Använd Microsoft Entra-anpassade roller för mer kornighet. |
| Distribuera Microsoft Sentinel-artefakter, till exempel arbetsböcker, analys, regler, frågor om hotjakt, notebook-filer och spelböcker | Microsoft Sentinel-deltagare Logic Apps-deltagare |
Permanent | Microsoft Sentinels arbetsyta eller resursgrupp | SPN | Använd godkännande av Azure DevOps-arbetsflöden (ADO) och kontroller för att skydda pipelinedistributionen med det här SPN:et. |
| Tilldela en princip för att konfigurera funktioner för loggströmning till Microsoft Sentinel | Resursprincipdeltagare ** | I syfte (varje gång en ny prenumeration och anslutningsprogram distribueras) | Alla prenumerationer som ska övervakas | SPN | Använd Microsoft Entra ID, CA och MFA när det stöds för privilegierade konton. |
* Gäller endast diagnostikinställningar för Microsoft Entra.
** Specifika anslutningsappar behöver ytterligare behörigheter som "säkerhetsadministratör" eller "resursprincipdeltagare" för att tillåta strömmande data till Microsoft Sentinel-arbetsytan, Microsoft Entra-ID, Microsoft 365 eller Microsoft Defender och PaaS-resurser (Plattform som en tjänst) som Azure Key Vault.
Privilegierad åtkomstmodell
Vi rekommenderar att du antar en strategi för privilegierad åtkomstmodell för att snabbt minska riskerna för ditt företag från attacker med hög effekt och hög sannolikhet på privilegierad åtkomst. När det gäller automatiska processer i en DevOps-modell baserar du identiteten på tjänstens huvudnamnsidentiteter .
Privilegierad åtkomst bör vara högsta säkerhetsprioritet på varje företag. Alla kompromettering av dessa identiteter skapar mycket negativa effekter. Privilegierade identiteter har åtkomst till affärskritiska tillgångar, vilket nästan alltid orsakar stora konsekvenser när angripare komprometterar dessa konton.
Säkerheten för privilegierad åtkomst är mycket viktig eftersom den är grundläggande för alla andra säkerhetsgarantier. En angripare som har kontroll över dina privilegierade konton kan undergräva alla andra säkerhetsgarantier.
Därför rekommenderar vi att du logiskt sprider tjänstens huvudnamn till olika nivåer eller nivåer genom att följa en minimiprivilegier. Följande bild visar hur du klassificerar tjänstens huvudnamn, beroende på vilken typ av åtkomst som krävs och var åtkomsten krävs.
Tjänsthuvudnamn på nivå 0
Tjänstens huvudnamn på nivå 0 har den högsta behörighetsnivån. Dessa tjänsthuvudnamn ger någon rätt att utföra administrationsuppgifter för hela klientorganisationen eller rothanteringsgruppen som global administratör.
Av säkerhetsskäl och hanterbarhet rekommenderar vi att du bara har ett huvudnamn för tjänsten för den här nivån. Behörigheterna för tjänstens huvudnamn kvarstår, så vi rekommenderar att du endast beviljar de minsta behörigheter som krävs och håller kontot övervakat och skyddat.
Lagra hemligheten eller certifikatet för det här kontot på ett säkert sätt i Azure Key Vault. Vi rekommenderar starkt att du hittar nyckelvalvet i en dedikerad administrativ prenumeration om möjligt.
Tjänsthuvudnamn på nivå 1
Tjänsthuvudnamn på nivå 1 är utökade behörigheter som är begränsade och begränsade till hanteringsgrupper på företagsnivå. Dessa tjänsthuvudnamn ger någon rätt att skapa prenumerationer under hanteringsgruppen som finns i omfånget.
Av säkerhetsskäl och hanterbarhet rekommenderar vi att du bara har ett huvudnamn för tjänsten för den här nivån. Behörigheterna för tjänstens huvudnamn kvarstår, så vi rekommenderar starkt att du endast beviljar de minsta behörigheter som krävs och håller kontot övervakat och skyddat.
Lagra hemligheten eller certifikatet för det här kontot på ett säkert sätt i Azure Key Vault. Vi rekommenderar starkt att du hittar nyckelvalvet i en dedikerad administrativ prenumeration om möjligt.
Tjänsthuvudnamn på nivå 2
Tjänstens huvudnamn på nivå 2 är begränsade till prenumerationsnivån. Dessa tjänsthuvudnamn ger någon rätt att utföra administrativa uppgifter under en prenumeration, som fungerar som prenumerationsägare.
Av säkerhetsskäl och hanterbarhet rekommenderar vi att du bara har ett huvudnamn för tjänsten för den här nivån. Behörigheterna för tjänstens huvudnamn kvarstår, så vi rekommenderar starkt att du endast beviljar de minsta behörigheter som krävs och håller kontot övervakat och skyddat.
Lagra hemligheten eller certifikatet för det här kontot på ett säkert sätt i Azure Key Vault. Vi rekommenderar starkt att du hittar nyckelvalvet i en dedikerad administrativ resursgrupp.
Tjänsthuvudnamn på nivå 3
Tjänstens huvudnamn på nivå 3 är begränsade till arbetsbelastningsadministratören. I ett typiskt scenario finns varje arbetsbelastning i samma resursgrupp. Den här strukturen begränsar behörigheterna för tjänstens huvudnamn till bara den här resursgruppen.
Av säkerhetsskäl och hanterbarhet rekommenderar vi att du bara har ett huvudnamn för tjänsten per arbetsbelastning. Behörigheterna för tjänstens huvudnamn kvarstår, så vi rekommenderar starkt att du endast beviljar de minsta behörigheter som krävs och håller kontot övervakat och skyddat.
Lagra hemligheten eller certifikatet för det här kontot på ett säkert sätt i Azure Key Vault. Vi rekommenderar starkt att du hittar nyckelvalvet i en dedikerad administrativ resursgrupp.
Tjänsthuvudnamn på nivå 4
Tjänstens huvudnamn på nivå 4 har de mest begränsade behörigheterna. Dessa tjänsthuvudnamn ger någon rätt att utföra administrativa uppgifter som är begränsade till en resurs.
Vi rekommenderar att du använder hanterade identiteter där det är möjligt. När det gäller icke-hanterade identiteter lagrar du hemligheten eller certifikatet på ett säkert sätt i Azure Key Vault där nivå 3-hemligheter lagras.
Driftsäkerhet
Driftskvalitet omfattar de driftsprocesser som distribuerar ett program och håller det igång i produktion. Mer information finns i Översikt över grundpelare för driftskvalitet.
Microsoft Sentinel-lösningar består av tre block som säkerställer fullständiga och lyckade åtgärder.
Det första blocket är miljödefinitionen, som utgör de viktigaste arkitekturelementen. Ditt största problem med det här blocket är att överväga antalet produktions- och icke-produktionsmiljöer som ska distribueras och sedan se till att installationen är homogen i alla fall.
Det andra blocket är distributionen av Microsoft Sentinel-anslutningsappen, där du överväger vilken typ av anslutningsappar som krävs av ditt team och de säkerhetskrav som krävs för att aktivera dem.
Det tredje blocket är livscykelhanteringen för Microsoft Sentinel-artefakter, som omfattar kodning, distribution och användning eller destruktion av komponenterna. Det här blocket innehåller till exempel analysregler, spelböcker, arbetsböcker, hotjakt och så vidare.
Tänk på dessa beroenden mellan artefakter:
- Automatiseringsregler som definieras i en analysregel
- Arbetsböcker eller analyser som kräver en ny datakälla eller anslutning
- Hantera uppdateringar av befintliga komponenter
- Så här versionshanterar du artefakter
- Så här identifierar, testar och distribuerar du en uppdaterad eller helt ny analysregel
Skapa, testa och distribuera infrastruktur
När du hanterar Microsoft Sentinel-lösningar och DevOps är det viktigt att tänka på anslutnings- och säkerhetsaspekterna i din företagsarkitektur.
Azure DevOps kan använda Microsoft-värdbaserade agenter eller lokalt installerade agenter för att skapa, testa och distribuera aktiviteter. Beroende på företagets krav kan du använda Microsoft-värdbaserad, lokalt installerad eller en kombination av båda modellerna.
- Microsofts värdbaserade agenter. Det här alternativet är det snabbaste sättet att arbeta med Azure DevOps-agenter eftersom det är en delad infrastruktur för hela organisationen. Mer information om hur du använder Microsoft-värdbaserade agenter i din pipeline finns i Microsoft-värdbaserade agenter. Microsoft-värdbaserade agenter kan fungera i hybridnätverksmiljöer och bevilja åtkomst för IP-intervallen. Information om hur du laddar ned DE IP-intervall som dessa agenter beviljar åtkomst till finns i Azure IP-intervall och tjänsttaggar – offentligt moln.
- Lokalt installerade agenter. Det här alternativet ger dig dedikerade resurser och mer kontroll när du installerar beroende programvara för dina byggen och distributioner. Lokalt installerade agenter kan fungera över virtuella datorer, skalningsuppsättningar och containrar i Azure. Mer information om lokalt installerade agenter finns i Azure Pipelines-agenter.
GitHub-löpare
GitHub kan använda GitHub-värdbaserade löpare eller lokalt installerade löpare för aktiviteter som är relaterade till att skapa, testa och distribuera. Beroende på företagets behov kan du använda GitHub-värdbaserad, lokalt installerad eller en kombination av båda modellerna.
GitHub-värdbaserade löpare
Det här alternativet är det snabbaste sättet att arbeta med GitHub-arbetsflöden eftersom det är en delad infrastruktur för en hel organisation. Mer information finns i Om GitHub-värdbaserade löpare. GitHub-värdbaserade agenter fungerar i hybridnätverksmiljöer enligt vissa nätverkskrav. Mer information om nätverkskraven finns i Löpare och maskinvaruresurser som stöds.
Egenvärdade löpare
Det här alternativet ger ditt företag en dedikerad resursinfrastruktur. Lokalt installerade löpare arbetar över virtuella datorer och containrar i Azure och stöder automatisk skalning.
Överväganden för att välja löpare
När du väljer alternativ för agenter och löpare i din Microsoft Sentinel-lösning bör du tänka på följande:
- Behöver ditt företag dedikerade resurser för att köra processer i dina Microsoft Sentinel-miljöer?
- Vill du isolera resurser för DevOps-aktiviteter i produktionsmiljön från resten av miljöerna?
- Behöver du testa vissa fall som kräver åtkomst till kritiska resurser eller resurser som endast är tillgängliga i ett internt nätverk?
Orkestrering och automatisering av lanseringsprocesser
Du kan konfigurera distributionsprocessen med Azure DevOps eller GitHub. Azure DevOps stöder användning av en YAML-pipeline eller en versionspipeline. Mer information om hur du använder en YAML-pipeline i Azure DevOps finns i Använda Azure Pipelines. Mer information om hur du använder en versionspipeline i Azure DevOps finns i Versionspipelines. Mer information om hur du använder GitHub med GitHub Actions finns i Förstå GitHub Actions.
Azure DevOps
Du kan utföra följande distributionsaktiviteter i en Azure DevOps-distribution.
- Använd en YAML-pipeline för att automatiskt utlösa PR-godkännanden eller köra på begäran.
- Hantera tjänstanslutningar för olika miljöer med hjälp av Azure DevOps-grupper.
- I dina kritiska miljöer konfigurerar du distributionsgodkännanden med hjälp av tjänstanslutningsfunktionen och Azure DevOps-grupper för att tilldela specifika användarbehörigheter i ditt team.
GitHub
Du kan utföra följande distributionsaktiviteter i en GitHub-distribution.
- Använd GitHub för att skapa PR:er eller distributionsaktiviteter.
- Hantera autentiseringsuppgifter för tjänstens huvudnamn med hjälp av GitHub Secrets.
- Integrera distributionsgodkännande via arbetsflödet som är associerat med GitHub.
Automatisk distribution med Microsoft Sentinel-infrastruktur
Du kan distribuera en eller flera Microsoft Sentinel-miljöer, beroende på din företagsarkitektur:
- Organisationer som behöver flera instanser i sin produktionsmiljö kan konfigurera olika prenumerationer på samma klientorganisation för varje geografisk plats.
- En centraliserad instans i produktionsmiljön ger åtkomst till en eller flera organisationer i samma klientorganisation.
- Grupper som behöver flera miljöer som produktion, förproduktion, integrering och så vidare kan skapa och förstöra dem efter behov.
Definitioner för fysisk kontra logisk miljö
Du har två alternativ när du konfigurerar miljödefinitioner, fysiska eller logiska. Båda har olika alternativ och fördelar:
- Fysisk definition – Elementen i Microsoft Sentinel-arkitekturen definieras med följande alternativ för infrastruktur som kod (IaC):
- Bicep-mallar
- Azure Resource Manager-mallar (ARM-mallar)
- Terraform
- Logisk definition – Detta fungerar som ett abstraktionslager för att konfigurera olika team i gruppen och definiera deras miljöer. Definitionen anges i distributionspipelinen och arbetsflöden som indata för byggmiljön med hjälp av det fysiska infrastrukturlagret.
Tänk på dessa punkter när du definierar dina logiska miljöer:
- Namngivningskonventioner
- Miljöidentifieringar
- Anslutningsappar och konfigurationer
Kodlagringsplats
Med tanke på de miljömetoder som visas i föregående avsnitt bör du överväga följande GitHub-kodlagringsplatsorganisation.
Fysisk definition – Baserat på IaC-alternativ bör du tänka på en metod som använder enskilda moduldefinitioner som är länkade i huvuddistributionsdefinitionen.
I följande exempel visas hur koden kan ordnas.
Begränsa åtkomsten till den här lagringsplatsen till det team som definierar arkitekturen på fysisk nivå, vilket säkerställer en homogen definition i företagsarkitekturen.
Du kan anpassa förgrenings- och sammanslagningsstrategin till distributionsstrategin för varje organisation. Om ditt team behöver börja med definitionen läser du Anta en Git-förgreningsstrategi.
Mer information om ARM-mallar finns i Använda länkade och kapslade mallar när du distribuerar Azure-resurser.
Mer information om hur du konfigurerar Bicep-miljöer finns i Installera Bicep-verktyg. Mer information om GitHub finns i GitHub-flödet.
Logiska definitioner definierar ett företags miljöer. Git-lagringsplatsen samlar in de olika definitionerna för ett företag.
I följande exempel visas hur koden kan ordnas.
Lagringsplatsen återspeglar de PR-åtgärder som görs av olika team. Flera miljöer definieras av olika team och godkänns av företagets ägare eller godkännare.
Behörighetsnivån för att köra en miljödistribution är nivå 2. Den här nivån säkerställer att resursgruppen och resurserna skapas för miljön med nödvändig säkerhet och sekretess. På den här nivån anges även användarbehörigheter för tillåtna åtgärder i produktionsmiljöer, produktion och förproduktion.
Organisationer som vill ha miljöer på begäran för testning och utveckling och möjligheten att sedan förstöra miljöer när de har slutfört testningen kan implementera en Azure DevOps-pipeline eller GitHub-åtgärder. De kan ställa in schemalagda utlösare för att förstöra miljöer efter behov med hjälp av Azure DevOps-händelser eller GitHub-åtgärder.
Automatisk konfiguration av Microsoft Sentinel-anslutningsappar
Microsoft Sentinel-anslutningsappar är en viktig del av lösningen som stöder anslutning med olika element i arkitekturlandskapet för företag, till exempel Microsoft Entra ID, Microsoft 365, Microsoft Defender, plattformslösningar för hotinformation och så vidare.
När du definierar en miljö kan du använda konfigurationen för anslutningsappar för att konfigurera miljöer med homogena konfigurationer.
Aktivering av anslutningsappar som en del av DevOps-modellen måste stödjas av tjänstens huvudnamnsnivåmodell. Det här fokuset säkerställer rätt behörighetsnivå enligt följande tabell.
| Scenario för anslutningsapp | Modellnivå för privilegierad åtkomst | Lägsta behörighet för Azure | Kräver arbetsflödesgodkännande |
|---|---|---|---|
| Microsoft Entra ID | Nivå 0 | global administratör eller säkerhetsadministratör | Rekommenderat |
| Microsoft Entra ID Protection | Nivå 0 | global administratör eller säkerhetsadministratör | Rekommenderat |
| Microsoft Defender for Identity | Nivå 0 | global administratör eller säkerhetsadministratör | Rekommenderat |
| Microsoft Office 365 | Nivå 0 | global administratör eller säkerhetsadministratör | Rekommenderat |
| Microsoft Cloud App Security | Nivå 0 | global administratör eller säkerhetsadministratör | Rekommenderat |
| Microsoft Defender XDR | Nivå 0 | global administratör eller säkerhetsadministratör | Rekommenderat |
| Microsoft Defender för IOT | Nivå 2 | Deltagare | Rekommenderat |
| Microsoft Defender for Cloud | Nivå 2 | Säkerhetsläsare | Valfritt |
| Azure-aktivitet | Nivå 2 | Prenumerationsläsare | Valfritt |
| Plattformar för hotinformation | Nivå 0 | global administratör eller säkerhetsadministratör | Rekommenderat |
| Säkerhetshändelser | Nivå 4 | Ingen | Valfritt |
| Syslog | Nivå 4 | Ingen | Valfritt |
| DNS (förhandsversion) | Nivå 4 | Ingen | Valfritt |
| Windows-brandväggen | Nivå 4 | Ingen | Valfritt |
| Windows-säkerhet händelser via AMA | Nivå 4 | Ingen | Valfritt |
Distribution av Microsoft Sentinel-artefakter
Vid implementeringen av Microsoft Sentinel-artefakter får DevOps större relevans eftersom varje företag skapar flera artefakter för att förhindra och åtgärda attacker.
Att implementera artefakterna kan vara ett team eller flera team. Automatisk distribution av bygg- och artefakter är ofta det vanligaste processkravet och avgör metoden och villkoren för dina agenter och löpare.
Distribution och hantering av Microsoft Sentinel-artefakter kräver användning av Rest-API:et för Microsoft Sentinel. Mer information finns i Microsoft Sentinel REST API. Följande diagram visar en Azure DevOps-pipeline på en Azure REST API-stack.
Du kan också implementera lagringsplatsen med hjälp av PowerShell.
Om ditt team använder MITRE kan du överväga att klassificera de olika artefakterna och ange taktik och tekniker för var och en. Se till att du inkluderar en motsvarande metadatafil för varje artefakttyp.
Om du till exempel skapar en ny spelbok med hjälp av en Azure ARM-mall och filnamnet är Playbook.arm.json lägger du till en JSON-fil med namnet Playbook.arm.mitre.json. Metadata för den här filen innehåller sedan CSV-, JSON- eller YAML-format som motsvarar MITRE-taktiken eller teknikerna som du använder.
Genom att följa den här metoden kan ditt team utvärdera DIN MITRE-täckning baserat på de jobb som utförs under installationen för de olika artefakttyper som du använder.
Skapa artefakter
Målet med byggprocessen är att säkerställa att du genererar artefakter av högsta kvalitet. Följande diagram visar några av de byggprocessåtgärder som du kan vidta.
Ladda ned en Visio-fil med den här arkitekturen.
- Du kan basera artefaktdefinitionen på ett beskrivande schema i JSON- eller YAML-format och sedan validera schemat för att undvika syntaxfel.
- Verifiera arm-mallarna med hjälp av TESTverktyg för ARM-mallar.
- Verifiera YAML- och JSON-filerna för anpassade modeller med hjälp av PowerShell.
- Verifiera inställningarna för visningslistan och kontrollera att de CIDR-poster (classless inter-domain routing) som du definierar följer rätt schema, till exempel 10.1.0.0/16.
- Använd KQL-frågor (keyword query language), som du kan verifiera på syntaxnivå, för analysregler, jaktregler och live stream-regler, som du kan verifiera på syntaxnivå.
- Gör den lokala KQL-valideringen till ett alternativ.
- Integrera det infogade KQL-valideringsverktyget i DevOps-pipelinen.
- Om du implementerar logik som baseras på PowerShell för Azure Automation kan du inkludera syntaxverifiering och enhetstestning med hjälp av följande element:
- Generera MITRE-manifestmetadatarapporten baserat på metadatafilerna som ingår i artefakterna.
Exportera artefakter
Vanligtvis arbetar flera team över flera Microsoft Sentinel-instanser för att generera nödvändiga artefakter och verifiera dem. Med målet att återanvända befintliga artefakter kan företaget konfigurera automatiska processer för att hämta artefaktdefinitionerna från befintliga miljöer. Automation kan också ange information om artefakter som skapas av olika utvecklingsteam under installationen.
Följande diagram visar ett exempel på en artefaktextraheringsprocess.
Ladda ned en Visio-fil med den här arkitekturen.
Distribuera artefakter
Syftet med distributionsprocessen är att:
- Minska tiden till marknaden.
- Öka prestandan för flera team som är involverade i att konfigurera och hantera din lösning.
- Konfigurera integreringstestning för att utvärdera miljöns hälsa.
Utvecklingsteam använder processen för att säkerställa att de kan distribuera, testa och validera artefaktanvändningsfall som är under utveckling. Arkitektur- och SOC-teamen validerar pipelinekvaliteten i QA-miljöer och arbetar med integreringstesterna för attackscenarier. I testfallen kombinerar ett team vanligtvis olika artefakter som analysregler, reparationsspelböcker, bevakningslistor och så vidare. En del av varje användningsfall omfattar simulering av attacker där hela kedjan utvärderas från inmatning, identifiering och reparation.
Följande diagram visar distributionsprocessens sekvens som säkerställer att dina artefakter distribueras i rätt ordning.
Ladda ned en Visio-fil med den här arkitekturen.
Genom att hantera Sentinel-artefakter som kod kan du underhålla dina åtgärder på ett flexibelt sätt och automatisera distributionen i en CI/CD DevOps-pipeline.
Microsoft-lösningar tillhandahåller automatiseringsarbetsflöden för följande artefakter.
| Artefakt | Automation-arbetsflöden |
|---|---|
| Visningslistor | Kodgranskning Schemaverifiering Distribution Skapa, uppdatera, ta bort visningslistor och objekt |
| Fusion av analysregler Microsoft Security ML-beteendeanalys Anomali Har schemalagts |
Kodgranskning KQL-syntaxverifiering Schemavalidering Tjata Distribution Skapa, aktivera, uppdatera, ta bort, exportera Stöd för aviseringsmallar |
| Automatiseringsregler | Kodgranskning Schemavalidering Distribution Skapa, aktivera, uppdatera, ta bort, exportera |
| Anslutningar | Kodgranskning Schemavalidering Distribution Åtgärder: aktivera, ta bort (inaktivera), uppdatera |
| Jaktregler | Kodgranskning KQL-syntaxverifiering Schemavalidering Tjata Distribution Åtgärder: skapa, aktivera, uppdatera, ta bort, exportera |
| Spelböcker | Kodgranskning TTK Distribution Åtgärder: skapa, aktivera, uppdatera, ta bort, exportera |
| Arbetsböcker | Distribution Åtgärder: skapa, uppdatera, ta bort |
| Runbooks | Kodgranskning Validering av PowerShell-syntax Tjata Distribution Åtgärder: skapa, aktivera, uppdatera, ta bort, exportera |
Beroende på vilket automationsspråk du väljer kanske vissa automatiseringsfunktioner inte stöds. Följande diagram visar vilka automatiseringsfunktioner som stöds av språket.
* Funktioner under utveckling som ännu inte har dokumenterats
** Automatiseringsmetoder som stöds av Api:er för Microsoft Operational Insights eller Microsoft Insights-resursprovider
Azure Automation
Följande diagram visar komponenterna för att förenkla Microsoft Sentinel-åtkomsten med hanterad tjänstidentitet.
Ladda ned en Visio-fil med den här arkitekturen.
Om du behöver bevilja åtkomst till andra resurser använder du hanterad identitet, vilket garanterar en unik identitet för alla kritiska åtgärder.
Använd Azure Automation för att konfigurera spelböcker. Använd PowerShell-skript för följande komplexa uppgifter och automatiseringsfunktioner:
- Integrera med lösningar från tredje part, där olika autentiseringsnivåer krävs och baseras på Microsoft Entra-ID eller anpassade autentiseringsuppgifter:
- Autentiseringsuppgifter för Microsoft Entra-användare
- Autentiseringsuppgifter för Microsoft Entra-tjänstens huvudnamn
- Certifikatsautentisering
- Anpassade autentiseringsuppgifter
- Hanterad identitet
- Implementera en lösning som återanvänder organisationsskript eller lösningar som kräver användning av PowerShell-kommandon för att undvika komplex översättning till spelböcker:
- PowerShell-baserade lösningar
- Python-baserade lösningar
- Implementera lösningar i hybridscenarier, där reparationsåtgärder kan påverka dina molnresurser och lokala resurser.
Microsoft Sentinel-lagringsplatser
Erfarna DevOps-team kan överväga att hantera Microsoft Sentinel i infrastruktur som kod (IaC) med CI/CD-pipelines som är inbyggda i Azure DevOps. Produktgrupper förstår de utmaningar som kunder och partner står inför när de skapar Azure DevOps-säkerhetsarkitektur, så följande två initiativ kan vara till hjälp:
- Dokumentera referensarkitekturen
- Utveckla en ny lösning, som tillkännagavs på Ignite 2021, som kallas "Microsoft Sentinel-lagringsplatser"
Om du vill ha stöd för att välja den lösning som passar ditt teams behov jämförs de funktionella och tekniska kriterierna i följande tabell.
| Användningsfall och funktioner | Anpassad Azure DevOps- och GitHub-metod | Microsoft Sentinel-lagringsplatser |
|---|---|---|
| Vi vill snabbt börja distribuera Microsoft Sentinel-artefakter utan att ägna tid åt att definiera Azure DevOps-arkitekturkomponenter, till exempel agenter, pipelines, Git, instrumentpaneler, en wiki, tjänstens huvudnamn, RBACs, granskning och så vidare. | Rekommenderas inte | Rekommenderat |
| Vi har små team och låg kompetensuppsättningar för att hantera CI/CD-pipelines. | Rekommenderas inte | Rekommenderat |
| Vi vill styra och hantera alla säkerhetsaspekter av CI/CD-pipelines. | Stöds | Stöds inte |
| Vi måste integrera grindar och förgrening för att övervaka integrering innan utvecklare kan utlösa distributionspipelines, till exempel källkontroll, kodningsgranskning, återställning, arbetsflödesgodkännande och så vidare. | Stöds | Delvis stöd |
| Vi har en anpassad Git- eller lagringsplatsstruktur. | Stöds | Stöds |
| Vi använder inte Resource Manager- eller Bicep IaC-språk för att skapa artefakter. | Stöds | Stöds inte |
| Vi vill centralt hantera distributionen av artefakter till flera Microsoft Sentinel-arbetsytor i en enda Microsoft Entra-klientorganisation. | Stöds | Stöds |
| Vi vill integrera eller utöka CI/CD-pipelines över flera Microsoft Entra-klienter. | Stöds | Stöds |
| Vi har spelböcker med olika parameterisering beroende på prenumeration, plats, miljö och så vidare. | Stöds | TBD, riktlinjer som ska dokumenteras |
| Vi vill integrera olika artefakter på samma lagringsplats för att skapa användningsfall. | Stöds | Stöds |
| Vi vill kunna masshantera artefakter. | Stöds | Stöds inte |
Tillgänglighet, prestanda och skalbarhet
När du väljer arkitekturen för Azure DevOps-agenter i ditt företag för Microsoft Sentinel-scenarier bör du tänka på följande:
- Produktionsmiljön kan kräva en dedikerad agentpool för åtgärder i Microsoft Sentinel-miljön.
- Icke-produktionsmiljöer kan dela agentpoolen med ett stort antal instanser för hantering av olika krav från teamen, särskilt för CI/CD-metoder.
- Scenarier för attacksimulering är ett specialfall där dedikerade agenter kan krävas. Överväg om en dedikerad pool är nödvändig för dina testbehov.
- Organisationer som arbetar med hybridnätverksscenarier kan överväga att integrera agenterna i nätverket.
Organisationer kan skapa egna avbildningar för agenter baserat på containrar. Mer information finns i Köra en lokalt installerad agent i Docker.
Hantering mellan klientorganisationer i Microsoft Sentinel med Azure DevOps
Som global SOC eller MSSP kan du behöva hantera flera klienter. Azure Lighthouse har stöd för skalbara åtgärder i flera Microsoft Entra-klienter samtidigt, vilket gör dina hanteringsuppgifter mer effektiva. Mer information finns i Översikt över Azure Lighthouse.
Hantering mellan klientorganisationer är särskilt effektivt i följande scenarier:
- Hantera Microsoft Sentinel-resurser i kundklientorganisationer.
- Spåra attacker och visa säkerhetsaviseringar i flera klienter.
- Visa incidenter över flera Microsoft Sentinel-arbetsytor som är spridda över klientorganisationer.
Metoder för att registrera kunder
Du har två alternativ för att registrera kunder, ett erbjudande om hanterad tjänst och en ARM-mall.
Manuell registrering med hjälp av en ARM-mall
Om du inte vill publicera ett erbjudande till Azure Marketplace som tjänstleverantör, eller om du inte uppfyller alla krav, kan du registrera kunder manuellt med hjälp av ARM-mallar. Det här är det mest sannolika alternativet i ett företagsscenario, där samma företag har flera klienter.
I följande tabell jämförs registreringsmetoderna.
| Att tänka på | Erbjudande för hanterad tjänst | ARM-mallar |
|---|---|---|
| Kräver ett Partnercenter-konto | Ja | Nej |
| Kräver kompetensnivå för silver- eller guldmolnplattform eller STATUS för Azure Expert Managed Services Provider (MSP) | Ja | Nej |
| Tillgänglig för nya kunder via Azure Marketplace | Ja | Nej |
| Kan begränsa erbjudandet till specifika kunder | Ja (endast med privata erbjudanden, som inte kan användas med prenumerationer som upprättas via en återförsäljare av CSP-programmet) | Ja |
| Kräver kundgodkännande i Azure Portal | Ja | Nej |
| Kan använda automatisering för att registrera flera prenumerationer, resursgrupper eller kunder | Nej | Ja |
| Ger omedelbar åtkomst till nya inbyggda roller och Azure Lighthouse-funktioner | Inte alltid (allmänt tillgänglig efter viss fördröjning) | Ja |
Mer information om hur du publicerar erbjudanden för hanterade tjänster finns i Publicera ett erbjudande om hanterade tjänster till Azure Marketplace.
Mer information om hur du skapar en ARM-mall finns i Skapa och distribuera ARM-mallar.
Följande diagram visar arkitekturintegrering på hög nivå mellan en MSSP-klientorganisation och en kunds resursproviderklienter med Azure Lighthouse och Microsoft Sentinel.
Ladda ned en Visio-fil med den här arkitekturen.
- Ett MSP-erbjudande integreras via en ARM-mall eller ett Azure Marketplace-tjänsterbjudande.
- Azure-delegerad resurshantering kontrollerar att begäran kommer från en partnerklientorganisation och anropar en resursprovider för hanterade tjänster.
- Den hanterade tjänstresursprovidern använder RBAC för att styra MSP:s åtkomst.
- MSP slutför SecOps-åtgärder på en kundresurs.
- Faktureringsprocessen behandlar utgifter som kundavgifter. Delad fakturering är möjlig om kundentiteter har separata arbetsytor i samma Microsoft Entra-klientorganisation.
- Säkerheten och suveräniteten för data är beroende av kundens klientgräns.
Identitet för flera klienter
Om du vill hantera Microsoft Sentinel med Azure DevOps utvärderar du följande designbeslut för komponenterna.
| Användningsfall | Fördelar |
|---|---|
| Global identitet för hantering av DevOps-åtgärder, huvudnamn för enskild tjänst | Det här fallet gäller för globala distributionsprocesser, som omfattar alla klienter. Att använda enhetlig identitet underlättar åtkomsten för de olika klienterna, men kan göra processen med att hantera godkännandeåtgärder för specifika klientorganisationer komplex. Skyddsmekanismen och auktoriseringsmodellen för den här typen av identitet är också mycket viktig för att undvika icke-auktoriserad användning som beror på den relaterade globala påverkan. |
| Dedikerad identitet för att hantera DevOps-åtgärder, flera tjänsthuvudnamn | Det här fallet gäller när distributionsprocesser är dedikerade för varje klient- eller klientorganisationsåtgärder som kräver godkännande. I det här fallet är rekommendationen för att skydda och auktorisera den här identitetsanvändningen densamma som i det globala fallet, även när effekten minskar. |
Kodlagringsplatsorganisation
| Användningsfall | Fördelar |
|---|---|
| Enhetlig lagringsplats med en enda kodversion för alla klienter | Det här fallet underlättar att ha enhetliga versioner för koden på lagringsplatsen. I det här fallet kan en enhetlig version av koden som hanterar en specifik version för klientorganisationer kräva stöd över grenar för varje ärende. |
| Enhetlig lagringsplats med specifika kodmappar efter klientorganisation | Det här fallet kompletterar fallet med en lagringsplats. Här kan en mappstruktur dela upp dedikerade artefakter efter klientorganisation. |
| Dedikerad lagringsplats efter klientorganisation | Den här metoden ger isolering vid hantering av kodartefakter. Det gör utvecklingen enklare mellan klienter med olika team eller krav. För att konsolidera ändringar krävs att en process upprättas mellan lagringsplatser, vilket kan kräva arbete för att underhålla. |
Bygg- och distributionsprocesser
| Användningsfall | Fördelar |
|---|---|
| En enda byggprocess för alla klienter | När alla klienter arbetar med samma version av artefakterna är detta det enklaste alternativet för att implementera genereringen och paketet. |
| Byggprocess efter klientorganisation | En annan version av koden distribueras till varje klientorganisation. |
| Global distributionsprocess för alla klienter | Nya distributioner och uppdateringar av distributioner gäller för alla klienter. Stegen i distributions- och uppdateringsprocesserna används för alla klienter. |
| Klientorganisation för global distributionsprocess efter klientorganisation | Nya distributioner och uppdateringar av distributioner gäller för en eller flera klienter. |
| Dedikerad distributionsprocess efter klientorganisation | Distributionsprocessen anpassas för varje klientorganisation. |
Kostnadsoptimering
Kostnadsoptimering handlar om att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i Översikt över kostnadsoptimeringspelare.
Kostnaden för lösningen beror på följande faktorer:
- Mängden data som ditt företag matar in på Microsoft Sentinel Log Analytics-arbetsytan varje månad
- Åtagandenivån eller faktureringsmetoden som du väljer, t.ex. betala per användning (PAYG)
- Kvarhållningshastigheten för dataprinciperna på en tabell eller global nivå
Mer information finns i Kvarhållning av Azure-datatyp.
Information om hur du beräknar priser finns i priskalkylatorn för Microsoft Sentinel. Mer information om avancerade prisöverväganden och exempel finns i Planera kostnader för Microsoft Sentinel..
Du kan medföra ytterligare kostnader om du utökar lösningen med följande komponenter:
- Spelböcker – runtimes för Azure Logic Apps och Azure Functions. Mer information finns i Prisinformation.
- Exportera till extern lagring som Azure Data Explorer, Event Hubs eller ett Azure Storage-konto.
- En maskininlärningsarbetsyta och den beräkning som en Jupyter Notebook-komponent använder.
Distribuera det här scenariot
I följande avsnitt beskrivs stegen för att distribuera det här scenariot i form av ett exempel på användningsfall som täcker de olika DevOps-processerna.
Skapa och släppa Microsoft Sentinel-ramverket
Börja med att konfigurera nödvändiga NuGet-komponenter i en dedikerad lagringsplats där olika processer kan använda de versioner som du genererar.
Om du arbetar med Azure DevOps kan du skapa en komponentfeed som värd för de olika NuGet-paketen från Microsoft Sentinel-ramverket för PowerShell. Mer information finns i Kom igång med NuGet-paket.
Om ditt team väljer ett GitHub-register kan du ansluta det som en NuGet-lagringsplats eftersom det är kompatibelt med feedprotokollet. Mer information finns i Introduktion till GitHub-paket.
När du har en tillgänglig NuGet-lagringsplats innehåller pipelinen en tjänstanslutning för NuGet. De här skärmbilderna visar konfigurationen för den nya tjänstanslutningen med namnet Microsoft Sentinel NuGet Framework Connection.
När du har konfigurerat feeden kan du importera pipelinen för att skapa PowerShell-ramverket direkt från GitHub i en specifik förgrening. Mer information finns i Skapa GitHub-lagringsplatser. I det här fallet skapar du en ny pipeline och väljer GitHub som kodkälla.
Ett annat alternativ är att importera Git-lagringsplatsen som en Azure DevOps-lagringsplats som baseras på Git. I båda fallen anger du följande sökväg för att importera pipelinen:
src/Build/Framework/ADO/Microsoft.Sentinel.Framework.Build.yml
Nu kan du köra pipelinen för första gången. Ramverket skapar och släpper sedan till NuGet-feeden.
Definiera din Microsoft Sentinel-miljö
När du börjar med Microsoft Sentinel och använder dessa exempel definierar du miljön i ditt företag, till exempel Miljö som kod eller EaC. Du anger de olika elementen som utgör miljön i varje enskilt fall.
Microsoft Sentinel-arkitekturen innehåller följande element i Azure:
- Log Analytics-arbetsyta – Den här arbetsytan utgör grunden för lösningen. Säkerhetsrelaterad information lagras här och arbetsytan är motorn för Kusto-frågespråk (KQL).
- Microsoft Sentinel-lösning via Log Analytics-arbetsytan – Den här lösningen utökar funktionerna i Log Analytics-arbetsytan till att omfatta SIEM- och SOAR-funktioner.
- Key Vault – Nyckelvalvet behåller de hemligheter och nycklar som används under reparationsprocesserna.
- Automation-konto – Det här kontot är valfritt och används för reparationsprocesserna. Reparationsprocessen som du använder baseras på PowerShell- och Python-runbooks. Processen innehåller en systemhanterad identitet som fungerar med olika resurser enligt bästa praxis.
- Användarhanterad identitet – Den här funktionen fungerar som ett enhetligt identitetslager i Microsoft Sentinel som hanterar interaktioner mellan Microsoft Sentinel-spelböcker och runbooks.
- Logic App-anslutningar – det här är anslutningar för Microsoft Sentinel, nyckelvalvet och automatisering som använder den användarhanterade identiteten.
- Externa Logic App-anslutningar – det här är anslutningar för externa resurser som ingår i reparationsprocesserna och som baseras på spelböckerna.
- Azure Event Hubs – Den här funktionen är valfri och hanterar integrering mellan Microsoft Sentinel och andra lösningar, till exempel Splunk, Azure Databricks och maskininlärning och Resilient.
- Lagringskonto – Den här funktionen är valfri och hanterar integrering mellan Microsoft Sentinel och andra lösningar, till exempel Splunk, Azure Databricks och maskininlärning och Resilient.
Genom att använda exempel från lagringsplatsen kan du definiera miljön med JSON-filer för att ange de olika logiska begreppen. De alternativ som är tillgängliga för att definiera miljön kan vara literala eller automatiska.
I en literaldefinition anger du namnet och elementen för varje resurs i miljön som du ser i det här exemplet.
{
{
"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>"
}
}
}
I en automatisk definition genererar elementnamnen automatiskt baserat på namngivningskonventioner, som du ser i det här exemplet.
{
{
"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
}
}
}
Du hittar exempel på GitHub-lagringsplatsen under sökvägen till Microsoft Sentinel-miljöer och använder exemplen som referens när du förbereder dina användningsfall.
Distribuera din Microsoft Sentinel-miljö
När du har definierat minst en miljö kan du skapa Azure-tjänstanslutningen för integrering med Azure DevOps. När du har skapat tjänstanslutningen anger du det länkade tjänstens huvudnamn till ägarrollen eller en liknande behörighetsnivå över målprenumerationen.
Importera pipelinen för att skapa den nya miljön enligt definitionen i den här filen.
src/Release/Sentinel Deployment/ADO/Microsoft.Sentinel.Environment.Deployment.ymlAnge sedan namnet på tjänstanslutningen som representerar miljön.
Välj grenen för miljödefinitionen på lagringsplatsen.
Ange namnet på Azure DevOps-tjänstanslutningen för din prenumeration i rutan Azure-miljöanslutning .
Ange namnet på den miljö som en tjänstanslutning kan använda för att lösa flera miljöer i samma prenumeration.
Välj den åtgärd som ska tillämpas på anslutningsapparna.
Välj Använd PowerShell Pre-Release Artifacts om du vill använda förhandsversionerna av PowerShell-ramverkskomponenterna.
Pipelinen innehåller följande steg som en del av distributionsflödet:
- Distribuera NuGet-komponenter.
- Anslut med hjälp av NuGet-verktyg med artefaktlagringsplatsen.
- Lös feeden.
- Installera de moduler som krävs.
- Hämta miljödefinitionen.
- Verifiera vilka resurser som finns i målet.
- Lägg till Log Analytics och Microsoft Sentinel om de inte finns på arbetsytan.
- Om du redan har Log Analytics lägger du till Microsoft Sentinel över din instans av Log Analytics.
- Skapa en hanterad identitet som representerar interaktionen mellan Microsoft Sentinel och Logic Apps.
- Skapa Azure Key Vault och ange rolltilldelningen för hantering av hemligheter och nycklar till den hanterade identiteten.
- Om tillämpligt skapar du ett Azure Automation-konto och aktiverar den systemtilldelade hanterade identiteten.
- Ange rolltilldelningen över nyckelvalvet för den systemtilldelade hanterade identiteten.
- Skapa Event Hubs-definitionerna om de inte finns och ange om definitionen innehåller integreringselementen.
- Ange rolltilldelningen över nyckelvalvet för den systemtilldelade hanterade identiteten.
- Skapa definitionerna för lagringskontot om de inte finns och ange om definitionen innehåller integreringselementen.
- Ange rolltilldelningen över nyckelvalvet för den systemtilldelade hanterade identiteten.
- Distribuera anslutningsåtgärderna.
- Distribuera integrationsrunbooken på Automation-kontot.
- Distribuera Logic Apps-anslutningarna om de definieras som en del av miljön.
Förstöra en Microsoft Sentinel-miljö
När miljön inte längre behövs, som när det gäller en utvecklings- eller testmiljö, kan du förstöra den enligt definitionen i den här filen.
src/Release/Sentinel Deployment/ADO/Microsoft.Sentinel.Environment.Destroy.yml
Precis som när du distribuerar miljöpipelinen anger du namnet på tjänstanslutningen som representerar miljön.
Arbeta med din Microsoft Sentinel-miljö
När miljön är klar kan du börja skapa artefakterna för att konfigurera de olika användningsfallen.
Exportera artefakterna från miljön som du arbetar med enligt definitionen i den här filen.
src/Release/Artifacts Deployment/ADO/Microsoft.Sentinel.Artifacts.Export.ymlVälj grenen för miljödefinitionen på lagringsplatsen.
Ange namnet på Azure DevOps-tjänstanslutningen för miljön som exporteras i rutan Azure-miljöanslutning .
Välj Använd PowerShell Pre-Release Artifacts om du vill använda förhandsversionerna av PowerShell-ramverkskomponenterna.
Välj formatet för analys- och jaktreglerna.
Artefaktutdatafilen är tillgänglig i resultatet. När du har artefakterna kan du inkludera utdatafilen på Git-lagringsplatsen.
Skapa artefakter i Microsoft Sentinel-miljön
Placera dina artefakter under microsoft Sentinel MITRE-användningsfallssökvägen. Konfigurera mappstrukturen enligt de olika typerna av artefakter.
Starta byggprocessen enligt definitionen i den här filen.
src/Build/Artifacts/ADO/Microsoft.Sentinel.Artifacts.Build.yamlVälj grenen för miljödefinitionen på lagringsplatsen.
Diagram över hur du väljer grenen för att skapa artefakterna.](./media/build-artifacts-pipeline.png)
Välj Använd PowerShell Pre-Release Artifacts om du vill använda förhandsversionerna av PowerShell-ramverkskomponenterna.
Pipelinen består av följande steg:
- Distribuera NuGet-komponenter.
- Anslut NuGet-verktygen till artefaktlagringsplatsen.
- Lös feeden.
- Installera de moduler som krävs.
- Hämta testverktygsramverket för att verifiera ARM-mallarna.
- Verifiera ARM-mallarna.
- Verifiera PowerShell Runbooks-koden och gör syntaxverifiering.
- Kör Pester-enhetstesterna om det är tillämpligt.
- Verifiera KQL-syntaxen i jakt- och analysreglerna.
Distribuera dina artefakter till Microsoft Sentinel-miljön
När du distribuerar dina artefakter kan du använda Microsoft Sentinel-lagringsplatserna eller distributionspipelines på den här lagringsplatsen. Mer information finns i Distribuera anpassat innehåll från din lagringsplats.
Microsoft Sentinel-lagringsplatser
Om du använder Microsoft Sentinel-lagringsplatser kan du konfigurera en lanseringsprocess för att inkludera artefakterna i lagringsplatsen som är ansluten till varje Microsoft Sentinel-instans. När artefakterna har checkats in på lagringsplatsen utförs några av stegen automatiskt som en del av att skapa pipelinen och aktivera Microsoft Sentinel-lagringsplatserna.
Du kan också anpassa de distributionsprocesser som Microsoft Sentinel-lagringsplatserna gör baserat på metoder som beskrivs i det här dokumentet. En viktig aspekt att tänka på är versionsgodkännandet, som du kan konfigurera genom att följa dessa metoder:
- PR-godkännande när artefakterna checkas in. Mer information finns i Skapa pull-begäranden.
- Släpp pipelinegodkännande när du kör distributionen. Mer information finns i Definiera godkännanden och kontroller.
Exempel på Microsoft Sentinel-distributionspipeline
Genom att använda pipelineexempel för Microsoft Sentinel-distribution kan du konfigurera en lanseringsprocess.
Konfigurera versionsprocessen enligt definitionen i den här filen.
src/Release/Artifacts Deployment/ADO/Microsoft.Sentinel.Artifacts.Deployment.ymlVälj grenen för miljödefinitionen på lagringsplatsen.
Ange namnet på Azure DevOps-tjänstanslutningen för miljön som exporteras i rutan Azure-miljöanslutning .
Välj Använd PowerShell Pre-Release Artifacts om du vill använda förhandsversionerna av PowerShell-ramverkskomponenterna.
Deltagare
Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.
Huvudförfattare:
- Kevin Kisoka | Associera arkitekt
Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.
Nästa steg
- Mer information om Microsoft Sentinel med DevOps för arkitektur med en enda klientorganisation finns i Distribuera och hantera Microsoft Sentinel som kod.
- Mer information om hur du utformar en MSSP-arkitektur som fungerar i flera Microsoft Entra-kataloger finns i Kombinera Azure Lighthouse med Microsoft Sentinels DevOps-funktioner.
- Information om hanterad identitet med Microsoft Sentinel finns i Nyheter: Hanterad identitet för Anslutningsprogram för Microsoft Sentinel Logic Apps.
- Information om hur du distribuerar innehåll från en Microsoft Sentinel-lagringsplats finns i Distribuera anpassat innehåll från din lagringsplats.
- Mer information om azure DevOps-säkerhetsöverväganden finns i Snabbreferens för standardbehörigheter.
- Information om hur du skyddar en Azure DevOps-lagringsplats finns i Lägga till skydd i en lagringsplatsresurs.
- Information om hur du hanterar azure DevOps-tjänstanslutningssäkerhet finns i Tjänstanslutningar i Azure Pipelines.