A Sentinel integrációjának automatizálása az Azure DevOpsszal

Ez a cikk azt ismerteti, hogyan automatizálhatja a Microsoft Sentinel integrációs és üzembehelyezési műveleteit az Azure DevOpsszal. Az Azure DevOps a Microsoft Sentinel képességeinek használatával valósítja meg az üzembe helyezés biztonságossá tételét. Ezután egy DevSecOps-keretrendszer használatával kezelheti és helyezheti üzembe a Microsoft Sentinel-összetevőket nagy méretekben.

Architektúra

Az alábbi ábrán az Azure DevOps és a Microsoft Sentinel IaC beállítása látható.

Töltse le az architektúra Visio-fájlját.

Adatfolyam

1. A scrum fő- és termékfelügyelete az Azure DevOps használatával definiálja az eposzokat, a felhasználói történeteket és a termék-hátralékelemeket a projekt hátralékának részeként.
   • A scrum fő- és termékfelügyelete az Azure Boards használatával hozza létre a hátralékot, ütemezze a munkát a futamokban, tekintse át a projekttáblát, hozza létre az adattár struktúráját, és állítson be biztonsági szabályokat, például jóváhagyási munkafolyamatokat és ágakat.
   • Az Azure Git-adattár kódként tárolja a szkripteket és az engedélyeket a Microsoft Sentinel-összetevők kezeléséhez az infrastruktúrában.
   • Az összetevők és a forrásvezérlés fenntartja a megoldásban használt DevSecOps-munkafolyamat bővítményeit és frissítési csomagjait vagy összetevőit, például az Azure Resource Manager-sabloneszközkészletet és a PowerShell Pestert.
2. Microsoft Sentinel-összetevők:
   • Szabályzatok. A SIEM mérnökei a referenciaarchitektúra Azure-szabályzatait használják az Azure-szolgáltatások diagnosztikai beállításainak konfigurálásához és méretezéséhez. A szabályzatok segítenek automatizálni a Microsoft Sentinel adatösszekötők, például az Azure Key Vault üzembe helyezését. A szabályzatok az OMSIntegration API-tól függenek.
   • Csatlakozás orok. A Microsoft Sentinel logikai összekötőket, az Azure Data Csatlakozás orokat használ a biztonsági adatok naplózásához vagy metrikáihoz hasonlóan támogatott adatforrásokból, például a Microsoft Entra ID-ból, az Azure-erőforrásokból, a Microsoft Defenderből vagy külső megoldásokból. Az adatösszekötők fő listáját a Security Elemzések API kezeli. Mások az OMSIntegration API-ra támaszkodnak, és az Azure Policy diagnosztikai beállításaival kezelik.
   • Felügyelt identitás. A Microsoft Sentinel felügyelt identitást használ a felügyeltszolgáltatás-identitás (MSI) nevében, miközben a forgatókönyvekkel, logikai alkalmazásokkal vagy automatizálási runbookokkal és a kulcstartóval kommunikál.
   • Automatizálás. Az SOC-csapatok automatizálást használnak a vizsgálatok során. A SOC-csapatok digitális kriminalisztikai adatgyűjtési eljárásokat futtatnak az Azure Automation használatával, például Az Azure-beli virtuális gép (VM) felügyeleti láncával vagy a Microsoft Defenderhez készült elektronikus adatfeltárási (Prémium) szolgáltatással.
   • Elemzés. Az SOC-elemzők vagy fenyegetésvadászok beépített vagy egyéni elemzési szabályokat használnak a Microsoft Sentinel adatainak elemzéséhez és korrelálásához, illetve forgatókönyvek aktiválásához, ha fenyegetést és incidenst észlelnek.
   • Forgatókönyvek. A logikai alkalmazások a SecOps megismételhető műveleteit futtatják, például incidenst rendelnek hozzá, frissítenek egy incidenst, vagy szervizelési műveleteket hajtanak végre, például elkülönítenek vagy tartalmaznak egy virtuális gépet, visszavonják a jogkivonatot, vagy visszaállítják a felhasználói jelszót.
   • Veszélyforrás-keresés. A fenyegetésvadászok proaktív veszélyforrás-keresési képességeket használnak, amelyek jupyter notebookokkal összekapcsolhatók speciális használati esetekhez, például adatfeldolgozáshoz, adatfeldolgozáshoz, adatvizualizációhoz, gépi tanuláshoz vagy mély tanuláshoz.
   • Munkafüzetek. A SIEM mérnökei munkafüzet-irányítópultokkal jelenítik meg a trendeket és a statisztikákat, valamint megtekinthetik a Microsoft Sentinel-példányok és alösszetevőik állapotát.
   • Fenyegetések felderítése. Egy konkrét adatösszekötő, amely a fenyegetésfelderítési platformokat egyesíti, a Microsoft Sentinelbe kerül. Két csatlakozási módszer támogatott: TAXII és Graph API. Mindkét módszer tiIndikátorként vagy fenyegetésintelligencia-mutatóként szolgál a biztonsági API-kban.
3. Microsoft Entra-azonosító. Az identitás- és hozzáférés-kezelési képességek a referenciaarchitektúrában használt összetevőkre, például a felügyelt identitásokra, a szolgáltatásnevekre, a Microsoft Sentinel azure-beli szerepköralapú hozzáférés-vezérlőire (RBAC-k), a logikai alkalmazásokra és az automatizálási runbookokra kerülnek.
4. Azure Pipelines. A DevOps mérnökei folyamatokkal hoznak létre szolgáltatáskapcsolatokat a különböző Azure-előfizetések, például a tesztkörnyezet és az éles környezetek kezeléséhez folyamatos integrációs és folyamatos kézbesítési (CI/CD) folyamatokkal. Javasoljuk, hogy jóváhagyási munkafolyamatokkal megelőzze a váratlan üzembe helyezéseket és a különálló szolgáltatásnevek használatát, ha több előfizetést céloz meg Azure-környezetenként.
5. Azure Key Vault. A SOC mérnökei a kulcstartó használatával biztonságosan tárolják a szolgáltatásnév titkos kulcsait és tanúsítványait. Az architektúra ezen összetevője segít kikényszeríteni a kódban nem szereplő titkos kódok DevSecOps-elvét, amikor az Azure Pipeline szolgáltatáskapcsolatai használják.
6. Egy Azure-előfizetés. Az SOC-csapatok ebben a referenciaarchitektúrában a Microsoft Sentinel két példányát használják, két logikai Azure-előfizetésen belül elválasztva az éles és tesztkörnyezeti környezetek szimulálásához. Az igényeinek megfelelően skálázhat más környezetekkel is, például teszteléssel, fejlesztéssel, gyártás előtti fejlesztéssel stb.

Példa adatfolyamra

1. A rendszergazda hozzáad, frissít vagy töröl egy bejegyzést a Microsoft 365 konfigurációs fájljának elágazásában.
2. A rendszergazda véglegesíti és szinkronizálja a módosításokat az elágazott adattárba.
3. A rendszergazda ezután létrehoz egy lekéréses kérelmet (PR) a fő adattár módosításainak egyesítése érdekében.
4. A buildelési folyamat a lekéréses kérelemen fut.

Összetevők

• A Microsoft Entra ID egy több-bérlős, felhőalapú szolgáltatás, amely kezeli az identitás- és hozzáférés-vezérlést.
• Az Azure DevOps egy felhőszolgáltatás, amely együttműködik a kódokkal, alkalmazásokat hozhat létre és helyezhet üzembe, illetve megtervezheti és nyomon követheti a munkáját.
• Az Azure Key Vault egy felhőalapú szolgáltatás a titkos kódok biztonságos tárolására és elérésére. A titkos kód minden olyan dolog, amelyhez szigorúan szabályozni szeretné a hozzáférést, például API-kulcsokat, jelszavakat, tanúsítványokat vagy titkosítási kulcsokat.
• Az Azure Policy egy szolgáltatás, amely szabályzatdefiníciókat hoz létre, rendel hozzá és kezel az Azure-környezetben.
• A Microsoft Sentinel egy méretezhető, felhőalapú natív, SIEM- és biztonsági vezénylési, automatizálási és válaszmegoldás (SOAR).
• Az Azure Automation egy szolgáltatás a felhőfelügyelet folyamatautomatizálással történő egyszerűsítésére. Az Azure Automation használatával automatizálhatja a hosszú ideig futó, manuális, hibalehetőségeket és gyakran ismétlődő feladatokat. Az automatizálás segít a vállalat megbízhatóságának, hatékonyságának és értékének növelésében.

Forgatókönyv részletei

A Biztonsági üzemeltetési központ (SOC) csapatai időnként nehézségekbe ütköznek, amikor integrálják a Microsoft Sentinelt az Azure DevOpsszal. A folyamat több lépést is magában foglal, és a beállítás napokig is eltarthat, és ismétlést is igénybe vehet. A fejlesztés ezen részét automatizálhatja.

A felhő modernizálásához a mérnököknek folyamatosan új készségeket és technikákat kell elsajátítaniük a létfontosságú üzleti eszközök védelméhez és védelméhez. A mérnököknek robusztus és méretezhető megoldásokat kell létrehozniuk, amelyek lépést tartanak a változó biztonsági környezettel és az üzleti igényekkel. A biztonsági megoldásnak rugalmasnak, agilisnak és gondosan megtervezettnek kell lennie a fejlesztés legkorábbi szakaszaitól kezdve. Ezt a korai tervezési módszertant bal oldali műszaknak nevezzük.

Ez a cikk azt ismerteti, hogyan automatizálhatja a Microsoft Sentinel integrációs és üzembehelyezési műveleteit az Azure DevOpsszal. Kibővítheti a megoldást olyan összetett szervezetek számára, amelyek több entitást, előfizetést és különböző működési modellt használnak. A megoldás által támogatott üzemeltetési modellek közé tartozik a helyi SOC, a globális SOC, a felhőszolgáltató (CSP) és a felügyelt biztonsági szolgáltató (MSSP).

Ez a cikk a következő célközönségek számára készült:

• SOC-szakemberek, például elemzők és fenyegetésvadászok
• Biztonsági információk és eseménykezelési (SIEM) mérnökök
• Kiberbiztonsági tervezők
• Fejlesztők

Lehetséges használati esetek

Az architektúra jellemző használati esetei a következők:

• Gyors prototípus-készítés és a koncepció igazolása. Ez a megoldás ideális azoknak a biztonsági szervezeteknek és SOC-csapatoknak, amelyek javítani szeretnék a felhőfenyegetettség lefedettségét, vagy modernizálni szeretnék SIEM-infrastruktúrájukat kódként (IaC) és Microsoft Sentinelként.
• Microsoft Sentinel mint szolgáltatás. Ez a fejlesztési keretrendszer integrálja a szolgáltatás életciklus-kezelési alapelveit. Ezek az alapelvek olyan egyszerű vagy összetett csapatoknak felelnek meg, mint az OLYAN MSSP-k, amelyek ismétlődő, szabványosított műveleteket futtatnak több ügyfélbérlőn, miközben egyesítik az Azure DevOps és az Azure Lighthouse teljesítményét. Ezt a megoldást használhatja például egy csapat, amelyeknek közzé kell tenni a Microsoft Sentinel használati eseteit egy új fenyegetéskezelőhöz vagy egy folyamatban lévő kampányhoz.
• SOC-használati esetek létrehozása fenyegetésészleléshez. Számos csoport és fenyegetésfelderítési platform a MITRE Att&ck tartalmára és osztályozására támaszkodik, hogy elemezze a biztonsági helyzetüket a fejlett kereskedelmi eszközök vagy technikák és taktikák ellen. A megoldás strukturált megközelítést határoz meg a fenyegetésészlelési mérnöki eljárások fejlesztéséhez a MITRE Att&ck terminológiájának a Microsoft Sentinel-összetevők fejlesztésében való beépítésével.

Az alábbi ábrán egy MITRE Att&ck felhőforgatókönyv látható.

Töltse le az architektúra Visio-fájlját.

Fenyegetésdefiníciós támadási forgatókönyvek a MITRE alapján

Ez a táblázat a támadási forgatókönyvek fontos aspektusainak kifejezéseit, definícióit és részleteit mutatja be.

Adatelem	Leírás	Microsoft Sentinel-összetevők
Cím	A támadási forgatókönyv leíró neve a támadási vektor jellemzői vagy a technika leírása alapján.	MITRE-jegyzék
MITRE ATT&CK-taktikák	A MITRE ATT&CK támadási forgatókönyvhöz kapcsolódó taktikája	MITRE-jegyzék
MITRE ATT&CK technikák	MITRE ATT&CK technikák, beleértve a technikát vagy az altechnika azonosítóját, a támadási forgatókönyvhöz kapcsolódóan.	MITRE-jegyzék
Adatforrások	Az érzékelő vagy a naplózási rendszer által gyűjtött információk forrása, amelyek felhasználhatók a végrehajtott művelet, a műveletek sorozata vagy a támadó által végzett műveletek eredményeinek azonosításához szükséges információk gyűjtésére.	Microsoft Sentinel adatösszekötő vagy egyéni naplóforrás
Leírás	Információ a technikáról, az újdonságokról, az általában használt eszközökről, arról, hogy egy támadó hogyan használhatja ki, és hogy hogyan lehet használni. Hivatkozásokat tartalmaz a technikával kapcsolatos műszaki információkat leíró mérvadó cikkekre, valamint adott esetben a vadon élő használati hivatkozásokra.
Észlelés	A magas szintű elemzési folyamatok, érzékelők, adatok és észlelési stratégiák hasznosak a támadó által használt technika azonosításában. Ez a szakasz tájékoztatja a támadók viselkedésének észleléséért felelős személyeket, például a hálózati védőket, hogy olyan műveleteket hajtsanak végre, mint például elemzés írása vagy egy érzékelő üzembe helyezése. Elegendő információnak és hivatkozásnak kell lennie ahhoz, hogy hasznos védekező módszerekre mutasson. Előfordulhat, hogy az észlelés bizonyos technikák esetében nem mindig lehetséges, ezért dokumentálni kell.	Elemzési fenyegetéskeresés
Kockázatcsökkentés	Olyan konfigurációk, eszközök vagy folyamatok, amelyek megakadályozzák, hogy egy technika működve vagy a támadó számára a kívánt eredménnyel járjon. Ez a szakasz tájékoztatja a támadók , például a hálózati védők vagy a szabályzatkészítők ellen való mérséklésért felelős személyeket, hogy lehetővé teszik számukra, hogy olyan műveletet hajtsanak végre, mint például egy szabályzat módosítása vagy egy eszköz üzembe helyezése. Előfordulhat, hogy egy adott technika esetében a kockázatcsökkentés nem mindig lehetséges, ezért dokumentálni kell.
Kockázatcsökkentés	Olyan konfigurációk, eszközök vagy folyamatok, amelyek megakadályozzák, hogy egy technika működve vagy a támadó számára a kívánt eredménnyel járjon. Ez a szakasz azt ismerteti, hogyan csökkentheti a támadó támadások hatását a hálózati védők vagy a szabályzatkészítők számára. A szabályzat módosításának vagy egy eszköz üzembe helyezésének lépéseit ismerteti. Előfordulhat, hogy a kockázatcsökkentés nem mindig lehetséges egy bizonyos technika esetében, ezért dokumentálni kell.	Forgatókönyvek, automatizálási runbookok

Megfontolások

Ezek a szempontok implementálják az Azure Well-Architected Framework alappilléreit, amelyek a számítási feladatok minőségének javítása érdekében használható vezérelvek. További információ: Microsoft Azure Well-Architected Framework.

Biztonság

A biztonság biztosítékokat nyújt a szándékos támadások és az értékes adatokkal és rendszerekkel való visszaélés ellen. További információ: A biztonsági pillér áttekintése.

A biztonság általános értelemben véve az automatizálás növeli az üzemeltetés hatékonyságát, és időt takarít meg az összetettebb használati esetekhez, például a fenyegetésészleléshez, a fenyegetésfelderítéshez, a SOC-hoz és a SOAR-használati esetekhez. A DevOps-csapatoknak tudniuk kell, hol használhatják biztonságosan az IaC-t a Microsoft Sentinel CI/CD kontextusában. Ez a folyamat bemutatja a nem emberi fiókok által a Microsoft Entra ID-ban használt, szolgáltatásneveknek és felügyelt identitásoknak nevezett egyedi identitások használatát.

Az alábbi táblázat összefoglalja a szolgáltatásnevek biztonsági szempontjait, valamint a Microsoft Sentinel és az Azure DevOps kiadási folyamatainak fő használati eseteit.

Használati eset	Követelmények (minimális jogosultság)	Szerepkör-hozzárendelés időtartama	Engedély hatóköre	Vagyonkezelő	Biztonsági szempontok
Microsoft Sentinel-összekötők engedélyezése	Biztonsági rendszergazda** Tulajdonos* Microsoft Sentinel-közreműködő Olvasó	JIT (egyszeri aktiválás) Szándékosan (minden alkalommal, amikor új előfizetést és összekötőt helyez üzembe)	Bérlő	EGYSZERŰ SZOLGÁLTATÁSNÉV	A kulcstartóval tárolhatja a szolgáltatásnév (SPN) titkos kulcsát és tanúsítványát. SpN-naplózás engedélyezése. Rendszeresen tekintse át az spn engedély-hozzárendelését (azure privileged identity management for SPN) vagy gyanús tevékenységet az SPN-hez. A microsoft entrai hitelesítésszolgáltatók és a többtényezős hitelesítés használata (ha támogatott) a kiemelt fiókokhoz. A részletesebbség érdekében használja a Microsoft Entra egyéni szerepköröket.
Microsoft Sentinel-összetevők, például munkafüzetek, elemzések, szabályok, fenyegetéskeresési lekérdezések, jegyzetfüzetek és forgatókönyvek üzembe helyezése	Microsoft Sentinel-közreműködő Logic Apps-közreműködő	Állandó	A Microsoft Sentinel munkaterülete vagy erőforráscsoportja	EGYSZERŰ SZOLGÁLTATÁSNÉV	Az Azure DevOps (ADO) munkafolyamat-jóváhagyásával és ellenőrzéseivel biztonságossá teheti a folyamattelepítést ezzel az egyszerű szolgáltatásnévvel.
Szabályzat hozzárendelése a naplóstreamelési funkciók Microsoft Sentinelhez való konfigurálásához	Erőforrásházirend-közreműködő **	Szándékosan (minden alkalommal, amikor új előfizetést és összekötőt helyez üzembe)	Minden monitorozni kívánt előfizetés	EGYSZERŰ SZOLGÁLTATÁSNÉV	Ha támogatott, használja a Microsoft Entra-azonosítót, a hitelesítésszolgáltatót és az MFA-t a kiemelt fiókokhoz.

* Csak a Microsoft Entra diagnosztikai beállításait érinti.
** Az egyes összekötőknek további engedélyekre van szükségük, például "biztonsági rendszergazda" vagy "erőforrásházirend-közreműködő" az adatok Microsoft Sentinel-munkaterületre, a Microsoft Entra ID-ba, a Microsoft 365-be vagy a Microsoft Defenderbe való streameléshez, valamint a Szolgáltatásként nyújtott platform (PaaS) erőforrásokhoz, például az Azure Key Vaulthoz.

Emelt szintű hozzáférési modell

Javasoljuk, hogy egy emelt szintű hozzáférési modellstratégiát vezessen be, amely gyorsan csökkenti a vállalatra nézve a kiemelt hozzáféréssel kapcsolatos nagy hatású és nagy valószínűségű támadások kockázatát. Ha egy DevOps-modellben automatikus folyamatok futnak, az identitást szolgáltatásnév-identitásokra alapozza.

A kiemelt hozzáférésnek minden vállalatnál a legfontosabb biztonsági prioritásnak kell lennie. Ezeknek az identitásoknak a feltörése rendkívül negatív hatásokat okoz. A kiemelt identitások hozzáféréssel rendelkeznek az üzletileg kritikus fontosságú objektumokhoz, ami szinte mindig jelentős hatásokat okoz, ha a támadók feltörik ezeket a fiókokat.

A kiemelt hozzáférés biztonsága kritikus fontosságú, mert minden más biztonsági garancia alapja. A kiemelt fiókok felett álló támadók alááshatják az összes többi biztonsági biztosítékot.

Ezért azt javasoljuk, hogy a szolgáltatásnevek logikailag különböző szintekre vagy szintekre oszlanak egy minimális jogosultsági elv követésével. Az alábbi ábra bemutatja, hogyan osztályozhatja a szolgáltatásneveket a hozzáférés típusától és a szükséges hozzáféréstől függően.

0. szintű szolgáltatásnevek

A 0. szintű szolgáltatásnevek rendelkeznek a legmagasabb szintű engedélyekkel. Ezek a szolgáltatásnevek arra jogosítanak fel valakit, hogy globális rendszergazdaként bérlőszintű vagy gyökérszintű felügyeleti csoportfelügyeleti feladatokat végezzenek.

Biztonsági okokból és kezelhetőség miatt azt javasoljuk, hogy ehhez a szinthez csak egy szolgáltatásnévvel rendelkezzen. A szolgáltatásnév engedélyei továbbra is megmaradnak, ezért azt javasoljuk, hogy csak a minimálisan szükséges engedélyeket adja meg, és tartsa monitoron és biztonságban a fiókot.

A fiók titkos kulcsát vagy tanúsítványát biztonságosan tárolhatja az Azure Key Vaultban. Javasoljuk, hogy ha lehetséges, keresse meg a kulcstartót egy dedikált rendszergazdai előfizetésben.

1. szintű szolgáltatásnevek

Az 1. szintű szolgáltatásnevek emelt szintű engedélyek, amelyek az üzleti szervezet szintjén korlátozott és hatókörrel rendelkező felügyeleti csoportokra terjednek ki. Ezek a szolgáltatásnevek feljogosítanak valakit arra, hogy előfizetéseket hozzon létre a hatókörben lévő felügyeleti csoport alatt.

Biztonsági okokból és kezelhetőség miatt azt javasoljuk, hogy ehhez a szinthez csak egy szolgáltatásnévvel rendelkezzen. A szolgáltatásnév engedélyei továbbra is megmaradnak, ezért javasoljuk, hogy csak a minimálisan szükséges engedélyeket adja meg, és tartsa a fiókot figyelve és védve.

A fiók titkos kulcsát vagy tanúsítványát biztonságosan tárolhatja az Azure Key Vaultban. Javasoljuk, hogy ha lehetséges, keresse meg a kulcstartót egy dedikált rendszergazdai előfizetésben.

2. szintű szolgáltatásnevek

A 2. szintű szolgáltatásnevek az előfizetési szintre korlátozódnak. Ezek a szolgáltatásnevek arra jogosítanak fel valakit, hogy rendszergazdai feladatokat végezzenek egy előfizetésben, és az előfizetés tulajdonosaként járjanak el.

Biztonsági okokból és kezelhetőség miatt azt javasoljuk, hogy ehhez a szinthez csak egy szolgáltatásnévvel rendelkezzen. A szolgáltatásnév engedélyei továbbra is megmaradnak, ezért javasoljuk, hogy csak a minimálisan szükséges engedélyeket adja meg, és tartsa monitoron és biztonságban a fiókot.

A fiók titkos kulcsát vagy tanúsítványát biztonságosan tárolhatja az Azure Key Vaultban. Határozottan javasoljuk, hogy keresse meg a kulcstartót egy dedikált felügyeleti erőforráscsoportban.

3. szintű szolgáltatásnevek

A 3. szintű szolgáltatásnevek a számítási feladatok Rendszergazda istratorra korlátozódnak. Egy tipikus forgatókönyvben minden számítási feladat ugyanabban az erőforráscsoportban található. Ez a struktúra csak erre az erőforráscsoportra korlátozza a szolgáltatásnév-engedélyeket.

Biztonsági okokból és kezelhetőség miatt azt javasoljuk, hogy számítási feladatonként csak egy szolgáltatásnévvel rendelkezzen. A szolgáltatásnév engedélyei továbbra is megmaradnak, ezért javasoljuk, hogy csak a minimálisan szükséges engedélyeket adja meg, és tartsa monitoron és biztonságban a fiókot.

A fiók titkos kulcsát vagy tanúsítványát biztonságosan tárolhatja az Azure Key Vaultban. Határozottan javasoljuk, hogy keresse meg a kulcstartót egy dedikált felügyeleti erőforráscsoportban.

4. szintű szolgáltatásnevek

A 4. szintű szolgáltatásnevek rendelkeznek a korlátozott engedélyekkel. Ezek a szolgáltatásnevek arra jogosítanak fel valakit, hogy egy erőforrásra korlátozott rendszergazdai feladatokat hajtsanak végre.

Ajánlott felügyelt identitásokat használni, ahol lehetséges. Nem felügyelt identitások esetén a titkos kulcsot vagy a tanúsítványt biztonságosan tárolja az Azure Key Vaultban, ahol a 3. szintű titkos kulcsok vannak tárolva.

Működés eredményessége

Az üzemeltetési kiválóság azokat az üzemeltetési folyamatokat fedi le, amelyek üzembe helyeznek egy alkalmazást, és éles környezetben tartják azt. További információ: A működési kiválósági pillér áttekintése.

A Microsoft Sentinel-megoldások három blokkból állnak, amelyek teljes és sikeres műveleteket biztosítanak.

Az első blokk a környezetdefiníció, amely az alapvető architektúraelemeket alkotja. Ezzel a blokktal az a legfontosabb szempont, hogy figyelembe vegye az üzembe helyezendő éles és nem éles környezetek számát, majd győződjön meg arról, hogy a beállítás minden esetben homogén.

A második blokk a Microsoft Sentinel-összekötő üzembe helyezése, ahol figyelembe veszi a csapat által igényelt összekötők típusait és az engedélyezésükhöz szükséges biztonsági követelményeket.

A harmadik blokk a Microsoft Sentinel-összetevők életciklus-kezelése, amely az összetevők kódolására, üzembe helyezésére és használatára vagy megsemmisítésére terjed ki. Ez a blokk például az elemzési szabályokat, forgatókönyveket, munkafüzeteket, fenyegetéskeresést stb. tartalmazza.

Vegye figyelembe az összetevők közötti függőségeket:

• Elemzési szabályban definiált automatizálási szabályok
• Új adatforrást vagy összekötőt igénylő munkafüzetek vagy elemzések
• Meglévő összetevők frissítéseinek kezelése
  • Az összetevők verziószáma
  • Frissített vagy teljesen új elemzési szabály azonosítása, tesztelése és üzembe helyezése

Infrastruktúra létrehozása, tesztelése és üzembe helyezése

A Microsoft Sentinel-megoldások és a DevOps kezelése során fontos figyelembe venni a vállalati architektúra kapcsolati és biztonsági aspektusait.

Az Azure DevOps a Microsoft által üzemeltetett ügynököket vagy saját üzemeltetésű ügynököket használhatja a létrehozási, tesztelési és üzembe helyezési tevékenységekhez. A vállalat igényeitől függően használhatja a Microsoft által üzemeltetett, saját üzemeltetésű vagy mindkét modell kombinációját.

• Microsoft által üzemeltetett ügynökök. Ez a lehetőség a leggyorsabb módszer az Azure DevOps-ügynökökkel való együttműködésre, mivel ez egy megosztott infrastruktúra a teljes szervezet számára. A Microsoft által üzemeltetett ügynökök folyamaton belüli használatáról további információt a Microsoft által üzemeltetett ügynökökben talál. A Microsoft által üzemeltetett ügynökök hibrid hálózati környezetekben dolgozhatnak, és hozzáférést biztosítanak az IP-tartományokhoz. Az ezen ügynökök számára hozzáférést biztosító IP-tartományok letöltéséhez tekintse meg az Azure IP-tartományok és szolgáltatáscímkék – nyilvános felhő című témakört.
• Saját üzemeltetésű ügynökök. Ez a beállítás dedikált erőforrásokat és nagyobb felügyeletet biztosít a függő szoftverek buildekhez és központi telepítésekhez való telepítésekor. A saját üzemeltetésű ügynökök virtuális gépeken, méretezési csoportokon és tárolókon dolgozhatnak az Azure-ban. A saját üzemeltetésű ügynökökkel kapcsolatos további információkért lásd: Azure Pipelines-ügynökök.

GitHub-futók

A GitHub használhatja a GitHub által üzemeltetett futókat vagy saját üzemeltetésű futókat az építéshez, teszteléshez és üzembe helyezéshez kapcsolódó tevékenységekhez. A vállalat igényeitől függően használhatja a GitHub által üzemeltetett, saját üzemeltetésű vagy mindkét modell kombinációját.

A GitHub által üzemeltetett futók

Ez a lehetőség a leggyorsabb módja a GitHub-munkafolyamatok használatának, mivel egy teljes szervezet megosztott infrastruktúrája. További információt a GitHub által üzemeltetett futókról szóló cikkben talál. A GitHub által üzemeltetett ügynökök bizonyos hálózati követelményeknek megfelelően hibrid hálózati környezetekben működnek. A hálózati követelményekkel kapcsolatos további információkért lásd : Támogatott futók és hardvererőforrások.

Saját üzemeltetésű futók

Ez a beállítás dedikált erőforrás-infrastruktúrát biztosít a vállalatnak. A saját üzemeltetésű futók virtuális gépeken és tárolókon dolgoznak az Azure-ban, és támogatják az automatikus skálázást.

A futók kiválasztásának szempontjai

Amikor a Microsoft Sentinel-megoldásban kiválasztja az ügynökök és a futók beállításait, vegye figyelembe az alábbi igényeket:

• A vállalatnak dedikált erőforrásokra van szüksége a folyamatok Microsoft Sentinel-környezetekben való futtatásához?
• El szeretné különíteni az éles környezet devOps-tevékenységeinek erőforrásait a többi környezettől?
• Tesztelnie kell bizonyos eseteket, amelyek csak belső hálózaton érhetők el kritikus erőforrásokhoz vagy erőforrásokhoz való hozzáférést igényelnek?

A kiadási folyamatok vezénylése és automatizálása

Az üzembehelyezési folyamatot az Azure DevOps vagy a GitHub használatával állíthatja be. Az Azure DevOps támogatja a YAML-folyamat vagy a kiadási folyamat használatát. A YAML-folyamatok Azure DevOpsban való használatáról további információt az Azure Pipelines használata című témakörben talál. A kiadási folyamat Azure DevOpsban való használatáról további információt a Kiadási folyamatok című témakörben talál. További információ a GitHub És a GitHub Actions használatáról: A GitHub Actions ismertetése.

Azure DevOps

Azure DevOps-környezetben az alábbi üzembehelyezési tevékenységeket végezheti el.

• YAML-folyamat használatával automatikusan aktiválhat PR-jóváhagyásokat, vagy igény szerint futtatható.
• A különböző környezetek szolgáltatáskapcsolatainak kezelése Azure DevOps-csoportok használatával.
• A kritikus környezetekben állítsa be az üzembehelyezési jóváhagyásokat a szolgáltatáskapcsolati funkció és az Azure DevOps-csoportok használatával, hogy meghatározott felhasználói engedélyeket rendeljen a csapatához.

GitHub

A GitHub-környezetekben az alábbi üzembe helyezési tevékenységeket végezheti el.

• A GitHub használatával PRS-eket vagy üzembehelyezési tevékenységeket hozhat létre.
• Szolgáltatásnév hitelesítő adatainak kezelése a GitHub Titkos kulcsok használatával.
• Integrálja az üzembehelyezési jóváhagyást a GitHubhoz társított munkafolyamaton keresztül.

Automatikus üzembe helyezés a Microsoft Sentinel-infrastruktúrával

A vállalati architektúrától függően egy vagy több Microsoft Sentinel-környezetet is üzembe helyezhet:

• Azok a szervezetek, amelyeknek több példányra van szükségük az éles környezetben, különböző előfizetéseket állíthatnak be ugyanazon a bérlőn minden földrajzi helyhez.
• Az éles környezetben található központosított példány hozzáférést biztosít egy vagy több szervezethez ugyanazon bérlőn.
• Azok a csoportok, amelyeknek több környezetre, például az éles üzemre, az előkészítésre, az integrációra stb. van szükségük, szükség szerint létrehozhatják és megsemmisíthetik őket.

Fizikai és logikai környezet definíciói

A környezetdefiníciók beállításához két lehetőség közül választhat: fizikai vagy logikai. Mindkettőnek különböző lehetőségei és előnyei vannak:

• Fizikai definíció – A Microsoft Sentinel-architektúra elemei az infrastruktúra kódként (IaC) következő lehetőségeivel vannak definiálva:
  • Bicep-sablonok
  • Azure Resource Manager-sablonok (ARM-sablonok)
  • Terraform
• Logikai definíció – Ez absztrakciós rétegként működik a csoport különböző csoportjainak beállításához és a környezetük definiálásához. A definíció az üzembehelyezési folyamatban és a munkafolyamatokban van beállítva a buildkörnyezet bemeneteként a fizikai infrastruktúra réteg használatával.

A logikai környezetek definiálásakor vegye figyelembe ezeket a pontokat:

• Elnevezési konvenciók
• Környezetazonosítások
• Csatlakozás orok és konfigurációk

Kódtár

Tekintettel az előző szakaszban bemutatott környezeti megközelítésekre, vegye figyelembe az alábbi GitHub-kódtár-szervezetet.

Fizikai definíció – Az IaC-beállítások alapján olyan megközelítésre gondoljon, amely a fő üzembehelyezési definícióban összekapcsolt egyedi moduldefiníciókat használja.

Az alábbi példa bemutatja a kód rendszerezésének módját.

Korlátozza az adattárhoz való hozzáférést ahhoz a csapathoz, amely fizikai szinten határozza meg az architektúrát, biztosítva a vállalati architektúra homogén definícióját.

Az elágaztatási és egyesítési stratégiát az egyes szervezetek üzembehelyezési stratégiájához igazíthatja. Ha a csapatnak a definícióval kell kezdenie, tekintse meg a Git-elágaztatási stratégia bevezetése című témakört.

Az ARM-sablonokról további információt az Azure-erőforrások üzembe helyezésekor csatolt és beágyazott sablonok használata című témakörben talál.

A Bicep-környezetek beállításáról további információt a Bicep-eszközök telepítése című témakörben talál. A GitHubról további információt a GitHub folyamatában talál.

A logikai definíciók definiálják a vállalat környezeteit. A Git-adattár összegyűjti a vállalat különböző definícióit.

Az alábbi példa bemutatja a kód rendszerezésének módját.

Az adattár a különböző csapatok által végrehajtott PR-műveleteket tükrözi. Több környezetet különböző csapatok határoznak meg, és a vállalat tulajdonosai vagy jóváhagyói hagyják jóvá.

A környezet központi telepítésének futtatásához szükséges jogosultsági szint a 2. szint. Ez a szint biztosítja, hogy az erőforráscsoport és az erőforrások a szükséges biztonsággal és adatvédelemmel legyenek létrehozva a környezet számára. Ez a szint a felhasználói engedélyeket is beállítja az éles környezetekben, az éles környezetben és az előgyártásban engedélyezett műveletekhez.

Azok a szervezetek, amelyek igény szerint tesztelni és fejlesztenék a környezeteket, és a tesztelés befejezése után képesek megsemmisíteni a környezeteket, azure DevOps-folyamatot vagy GitHub-műveleteket implementálhatnak. Ütemezett eseményindítókat állíthatnak be, hogy szükség szerint elpusztítsák a környezeteket az Azure DevOps-események vagy a GitHub-műveletek használatával.

A Microsoft Sentinel-összekötők automatikus konfigurációja

A Microsoft Sentinel-összekötők a megoldás alapvető részei, amelyek támogatják a vállalati architektúra különböző elemeivel való kapcsolódást, például a Microsoft Entra ID, a Microsoft 365, a Microsoft Defender, a fenyegetésfelderítési platform megoldásai stb.

Amikor meghatároz egy környezetet, az összekötők konfigurációjával homogén konfigurációkkal állíthat be környezeteket.

Az összekötők DevOps-modell részeként való engedélyezését a szolgáltatásnévszintű modellnek kell támogatnia. Ez a fókusz biztosítja a megfelelő szintű engedélyeket az alábbi táblázatban látható módon.

Csatlakozás or forgatókönyv	Jogosultsági hozzáférési modell szintje	Az Azure legkisebb jogosultsága	Munkafolyamat-jóváhagyást igényel
Microsoft Entra ID	0. szint	globális rendszergazda vagy biztonsági rendszergazda	Ajánlott
Microsoft Entra ID Protection	0. szint	globális rendszergazda vagy biztonsági rendszergazda	Ajánlott
Microsoft Defender for Identity	0. szint	globális Rendszergazda vagy biztonsági rendszergazda	Ajánlott
Microsoft Office 365	0. szint	globális rendszergazda vagy biztonsági rendszergazda	Ajánlott
Microsoft Cloud App Security	0. szint	globális rendszergazda vagy biztonsági rendszergazda	Ajánlott
Microsoft Defender XDR	0. szint	globális rendszergazda vagy biztonsági rendszergazda	Ajánlott
Microsoft Defender for IOT	2. szint	Közreműködő	Ajánlott
Microsoft Defender for Cloud	2. szint	Biztonsági olvasó	Választható
Azure-tevékenység	2. szint	Előfizetés-olvasó	Választható
Fenyegetésfelderítési platformok	0. szint	globális rendszergazda vagy biztonsági rendszergazda	Ajánlott
Biztonsági események	4. szint	Egyik sem	Választható
Rendszernapló	4. szint	Egyik sem	Választható
DNS (előzetes verzió)	4. szint	Egyik sem	Választható
Windows tűzfal	4. szint	Egyik sem	Választható
Windows biztonság események az AMA-on keresztül	4. szint	Egyik sem	Választható

Microsoft Sentinel-összetevők üzembe helyezése

A Microsoft Sentinel-összetevők implementálásában a DevOps nagyobb jelentőséggel bír, mivel minden vállalat több összetevőt hoz létre a támadások megelőzéséhez és elhárításához.

Az összetevők implementálása egy vagy több csapat feladata lehet. Az automatikus build- és összetevők üzembe helyezése gyakran a leggyakoribb folyamatkövetelmény, és meghatározza az ügynökök és a futók megközelítését és feltételeit.

A Microsoft Sentinel-összetevők üzembe helyezéséhez és kezeléséhez a Microsoft Sentinel REST API-t kell használni. További információ: Microsoft Sentinel REST API. Az alábbi ábra egy Azure DevOps-folyamatot mutat be egy Azure REST API-veremen.

Az adattárat a PowerShell használatával is implementálhatja.

Ha a csapata MITRE-t használ, fontolja meg a különböző összetevők besorolását és az egyes összetevők taktikáinak és technikáinak megadását. Minden összetevőtípushoz adjon meg egy megfelelő metaadatfájlt.

Ha például azure ARM-sablonnal hoz létre új forgatókönyvet, és a fájlnév Playbook.arm.json, akkor egy Playbook.arm.mitre.json nevű JSON-fájlt kell hozzáadnia. A fájl metaadatai ezután tartalmazzák a használt MITRE-taktikának vagy technikáknak megfelelő CSV-, JSON- vagy YAML-formátumokat.

A gyakorlat követésével a csapat kiértékelheti a MITRE-lefedettséget a különböző használt összetevőtípusok beállítása során elvégzett feladatok alapján.

Összetevők létrehozása

A létrehozási folyamat célja annak biztosítása, hogy a legmagasabb minőségű összetevőket hozza létre. Az alábbi ábrán a buildelési folyamat néhány elvégezhető művelete látható.

Töltse le az architektúra Visio-fájlját.

• Az összetevődefiníciót egy leíró sémára alapozhatja JSON vagy YAML formátumban, majd érvényesítheti a sémát a szintaxishibák elkerülése érdekében.
  • Az ARM-sablonok ellenőrzése ARM-sablontesztelési eszközkészlettel.
  • A YAML- és JSON-fájlok ellenőrzése egyéni modellekhez a PowerShell használatával.
• Ellenőrizze a figyelőlista beállításait, és győződjön meg arról, hogy a megadott osztály nélküli tartományközi útválasztási (CIDR) rekordok a megfelelő sémát követik, például 10.1.0.0/16.
• Használjon kulcsszólekérdezési nyelv (KQL) lekérdezéseket, amelyeket a szintaxis szintjén érvényesíthet elemzési szabályokhoz, vadászati szabályokhoz és élő streamszabályokhoz, amelyeket a szintaxis szintjén érvényesíthet.
• A KQL helyi érvényesítési beállításának beállítása.
• Integrálja a KQL beágyazott érvényesítő eszközt a DevOps-folyamatba.
• Ha az Azure AutomationHez készült PowerShellen alapuló logikát implementál, a szintaxis-ellenőrzést és az egységtesztelést a következő elemek használatával végezheti el:
  • Kártevőirtó
  • PSScriptAnalyzer
• Hozza létre a MITRE-jegyzék metaadat-jelentését az összetevőkben található metaadatfájlok alapján.

Összetevők exportálása

Általában több csapat dolgozik több Microsoft Sentinel-példányon a szükséges összetevők létrehozásához és érvényesítéséhez. A meglévő összetevők újrafelhasználásának célja, hogy a vállalat automatikus folyamatokat állítson be az összetevő-definíciók meglévő környezetekből való lekéréséhez. Az Automation információkat is képes szolgáltatni a különböző fejlesztői csapatok által a beállítás során létrehozott összetevőkről.

Az alábbi ábrán egy mintaösszetevő-kinyerési folyamat látható.

Töltse le az architektúra Visio-fájlját.

Összetevők üzembe helyezése

Az üzembe helyezési folyamat céljai a következők:

• Csökkentse a piacra ásott időt.
• A megoldás beállításában és kezelésében részt vevő több csapat teljesítményének növelése.
• Integrációs tesztelés beállítása a környezet állapotának kiértékeléséhez.

A fejlesztői csapatok a folyamat segítségével biztosítják, hogy üzembe helyezhesse, tesztelhesse és érvényesíthesse a fejlesztés alatt álló összetevők használati eseteit. Az architektúra és az SOC-csapatok ellenőrzik a folyamat minőségét a minőségbiztosítási környezetekben, és együttműködnek a támadási forgatókönyvek integrációs tesztjeivel. A tesztesetekben a csapatok általában különböző összetevőket kombinálnak elemzési szabályokként, szervizelési forgatókönyvekként, figyelőlistákként stb. Az egyes használati esetek egy része olyan támadásokat szimulál, amelyek során a teljes láncot kiértékeli a betöltés, az észlelés és a szervizelés.

Az alábbi ábra az üzembe helyezési folyamatütemezést mutatja be, amely biztosítja, hogy az összetevők a megfelelő sorrendben legyenek üzembe helyezve.

Töltse le az architektúra Visio-fájlját.

A Sentinel-összetevők kódként való kezelése rugalmas módszereket kínál a műveletek karbantartására és az üzembe helyezés automatizálására egy CI/CD DevOps-folyamatban.

A Microsoft-megoldások automatizálási munkafolyamatokat biztosítanak a következő összetevőkhöz.

Műtermék	Automatizálási munkafolyamatok
Figyelőlisták	Kód áttekintése Séma érvényesítése Üzembe helyezés Figyelőlisták és elemek létrehozása, frissítése, törlése
Elemzési szabályok fúziója Microsoft Security Gépi tanulási viselkedéselemzés Anomália Ütemezett	Kód áttekintése KQL-szintaxis érvényesítése Sémaellenőrzés Kártevőirtó Üzembe helyezés Létrehozás, engedélyezés, frissítés, törlés, exportálás Riasztássablonok támogatása
Automatizálási szabályok	Kód áttekintése Sémaellenőrzés Üzembe helyezés Létrehozás, engedélyezés, frissítés, törlés, exportálás
Összekötők	Kód áttekintése Sémaellenőrzés Üzembe helyezés Műveletek: engedélyezés, törlés (letiltás), frissítés
Vadászati szabályok	Kód áttekintése KQL-szintaxis érvényesítése Sémaellenőrzés Kártevőirtó Üzembe helyezés Műveletek: létrehozás, engedélyezés, frissítés, törlés, exportálás
Forgatókönyvek	Kód áttekintése TTK Üzembe helyezés Műveletek: létrehozás, engedélyezés, frissítés, törlés, exportálás
Munkafüzetek	Üzembe helyezés Műveletek: létrehozás, frissítés, törlés
Runbookok	Kód áttekintése PowerShell-szintaxis érvényesítése Kártevőirtó Üzembe helyezés Műveletek: létrehozás, engedélyezés, frissítés, törlés, exportálás

A választott automatizálási nyelvtől függően előfordulhat, hogy egyes automatizálási képességek nem támogatottak. Az alábbi ábra azt mutatja be, hogy mely automatizálási képességeket támogatja a nyelv.

* A fejlesztés olyan funkciói, amelyek még nincsenek dokumentálva
** A Microsoft Operatív Elemzések vagy a Microsoft Elemzések erőforrás-szolgáltató API-k által támogatott automatizálási módszerek

Azure Automation

Az alábbi ábra a Microsoft Sentinel-hozzáférés felügyeltszolgáltatás-identitással való egyszerűsítésének összetevőit mutatja be.

Töltse le az architektúra Visio-fájlját.

Ha más erőforrásokhoz is hozzáférést kell adnia, használjon felügyelt identitást, amely minden kritikus művelethez egyedi identitást biztosít.

Forgatókönyvek beállításához használja az Azure Automationt. PowerShell-szkriptek használata az alábbi összetett feladatokhoz és automatizálási funkciókhoz:

• Integráció külső megoldásokkal, ahol különböző szintű hitelesítő adatokra van szükség, és a Microsoft Entra-azonosító vagy az egyéni hitelesítő adatok alapján:
  • Microsoft Entra felhasználói hitelesítő adatok
  • A Microsoft Entra szolgáltatásnév hitelesítő adatai
  • Tanúsítványhitelesítés
  • Egyéni hitelesítő adatok
  • Felügyelt identitás
• Olyan megoldás implementálása, amely újra felhasználja a szervezeti szkripteket, vagy olyan megoldásokat, amelyekhez PowerShell-parancsok használata szükséges a forgatókönyvek összetett fordításának elkerülése érdekében:
  • PowerShell-alapú megoldások
  • Python-alapú megoldások
• Megoldások megvalósítása hibrid forgatókönyvekben, ahol a szervizelési műveletek hatással lehetnek a felhőre és a helyszíni erőforrásokra.

Microsoft Sentinel-adattárak

A tapasztalt DevOps-csapatok fontolóra vehetik a Microsoft Sentinel kezelését az infrastruktúrában kódként (IaC) az Azure DevOpsban beépített CI/CD-folyamatokkal. A termékcsoportok megértik az Azure DevOps biztonsági architektúrájának kialakítása során az ügyfelek és a partnerek előtt álló kihívásokat, így az alábbi két kezdeményezés segíthet:

• A referenciaarchitektúra dokumentálása
• Az Ignite 2021-ben bejelentett új megoldás fejlesztése, amelynek neve "Microsoft Sentinel-adattárak"

A csapat igényeinek megfelelő megoldás kiválasztásának támogatása érdekében az alábbi táblázat összehasonlítja a funkcionális és technikai feltételeket.

Kis- és nagybetűk használata	Egyéni Azure DevOps- és GitHub-megközelítés	Microsoft Sentinel-adattárak
Gyorsan el szeretnénk kezdeni a Microsoft Sentinel-összetevők üzembe helyezését anélkül, hogy időt töltenénk az Azure DevOps architektúra összetevőinek definiálásával, például ügynökökkel, folyamatokkal, Gittel, irányítópultokkal, wikivel, szolgáltatásnévvel, RBA-kkal, naplózással stb.	Nem ajánlott	Ajánlott
A CI/CD-folyamatok kezeléséhez kis csapatok és alacsony képzettségi csoportok tartoznak.	Nem ajánlott	Ajánlott
A CI/CD-folyamatok minden biztonsági aspektusát szabályozni és kezelni szeretnénk.	Támogatott	Nem támogatott
Az integráció felügyeletéhez integrálni kell a kapukat és az elágaztatást, mielőtt lehetővé tenné a fejlesztők számára az üzembe helyezési folyamatok aktiválását, például a forrásvezérlést, a kódolási felülvizsgálatot, a visszaállítást, a munkafolyamat-jóváhagyást stb.	Támogatott	Részben támogatott
Testreszabott Git- vagy adattár-struktúrával rendelkezünk.	Támogatott	Támogatott
Nem használunk Resource Manager- vagy Bicep IaC-nyelveket az összetevők létrehozásához.	Támogatott	Nem támogatott
Központilag szeretnénk kezelni az összetevők üzembe helyezését több Microsoft Sentinel-munkaterületen egyetlen Microsoft Entra-bérlőben.	Támogatott	Támogatott
Ci/CD-folyamatokat szeretnénk integrálni vagy kiterjeszteni több Microsoft Entra-bérlőre.	Támogatott	Támogatott
Az előfizetéstől, a helytől, a környezettől és egyebektől függően különböző paraméterezésű forgatókönyveket használunk.	Támogatott	TBD, dokumentálandó irányelvek
Különböző összetevőket szeretnénk integrálni ugyanazon az adattáron a használati esetek írásához.	Támogatott	Támogatott
Lehetővé szeretnénk tenni az összetevők tömeges eltávolítását.	Támogatott	Nem támogatott

Rendelkezésre állás, teljesítmény és méretezhetőség

Amikor a vállalat Azure DevOps-ügynökeinek architektúráját választja a Microsoft Sentinel-forgatókönyvekhez, vegye figyelembe az alábbi igényeket:

• Az éles környezethez dedikált ügynökkészletre lehet szükség a Microsoft Sentinel-környezeten keresztüli műveletekhez.
• A nem éles környezetek nagy számú példányban oszthatják meg az ügynökkészletet a csapatok különböző igényeinek kezelésére, különösen a CI/CD-eljárások esetében.
  • A támadásszimulációs forgatókönyvek speciális esetek, ahol dedikált ügynökökre lehet szükség. Gondolja át, hogy szükség van-e dedikált készletre a tesztelési igényekhez.
• A hibrid hálózatkezelési forgatókönyveken dolgozó szervezetek fontolóra vehetik az ügynökök hálózaton belüli integrálását.

A szervezetek saját lemezképeket hozhatnak létre az ügynökök számára tárolók alapján. További információ: Saját üzemeltetésű ügynök futtatása a Dockerben.

Microsoft Sentinel bérlők közötti felügyelet az Azure DevOpsszal

Globális SOC-ként vagy MSSP-ként előfordulhat, hogy több bérlőt kell kezelnie. Az Azure Lighthouse egyszerre több Microsoft Entra-bérlő skálázott műveleteit is támogatja, így hatékonyabbá téve a felügyeleti feladatokat. További információkért tekintse meg az Azure Lighthouse áttekintését.

A bérlők közötti felügyelet különösen hatékony a következő esetekben:

• Microsoft Sentinel-erőforrások kezelése az ügyfélbérlőkben.
• Kövesse nyomon a támadásokat, és tekintse meg a több bérlőre vonatkozó biztonsági riasztásokat.
• Több Microsoft Sentinel-munkaterület incidenseinek megtekintése, amelyek a bérlők között oszlanak meg.

Az ügyfelek előkészítésének módszerei

Két lehetősége van az ügyfelek előkészítésére, egy felügyelt szolgáltatási ajánlatra és egy ARM-sablonra.

Manuális előkészítés ARM-sablonnal

Ha nem szeretne ajánlatot közzétenni az Azure Marketplace-en szolgáltatóként, vagy nem felel meg az összes követelménynek, arm-sablonokkal manuálisan is előkészítheti az ügyfeleket. Ez a legvalószínűbb lehetőség egy nagyvállalati forgatókönyvben, ahol ugyanaz a vállalat több bérlőt is használ.

Az alábbi táblázat az előkészítési módszereket hasonlítja össze.

Szempont	Felügyelt szolgáltatásra vonatkozó ajánlat	ARM-sablonok
Partnerközpont-fiók szükséges	Igen	Nem
Silver vagy Gold felhőplatform kompetenciaszintet vagy Azure Expert Managed Services Provider (MSP) állapotot igényel	Igen	Nem
Új ügyfelek számára elérhető az Azure Marketplace-en keresztül	Igen	Nem
Korlátozhatja az adott ügyfelekre vonatkozó ajánlatot	Igen (csak magánajánlatokkal, amelyek nem használhatók a CSP-program viszonteladója által létrehozott előfizetésekkel)	Igen
Ügyfélelfogadást igényel az Azure Portalon	Igen	Nem
Az automation használatával több előfizetést, erőforráscsoportot vagy ügyfelet is létrehozhat	Nem	Igen
Azonnali hozzáférést biztosít az új beépített szerepkörökhöz és az Azure Lighthouse-funkciókhoz	Nem mindig (általánosan elérhető némi késés után)	Igen

A felügyelt szolgáltatásajánlatok közzétételével kapcsolatos további információkért lásd : Felügyelt szolgáltatásajánlat közzététele az Azure Marketplace-en.

Az ARM-sablonok létrehozásáról további információt az ARM-sablonok létrehozása és üzembe helyezése című témakörben talál.

Az alábbi ábra az MSSP-bérlő és az ügyfél erőforrás-szolgáltatói bérlői közötti magas szintű architektúra-integrációt mutatja be az Azure Lighthouse és a Microsoft Sentinel használatával.

Töltse le az architektúra Visio-fájlját.

1. Az MSP-ajánlatok arm-sablonnal vagy Azure Marketplace-szolgáltatásajánlattal integrálhatók.
2. Az Azure delegált erőforrás-kezelése ellenőrzi, hogy a kérés egy partnerbérladótól származik-e, és egy felügyelt szolgáltatót hív meg.
3. A felügyelt szolgáltatás erőforrás-szolgáltatója RBAC használatával szabályozza az MSP hozzáférését.
4. Az MSP végrehajtja a SecOps-műveleteket egy ügyfélerőforráson.
5. A számlázási folyamat a költségeket ügyféldíjként kezeli. A számlázás felosztása akkor lehetséges, ha az ügyfél-entitások külön munkaterületekkel rendelkeznek ugyanabban a Microsoft Entra-bérlőben.
6. Az adatok biztonsága és szuverenitása az ügyfél bérlői határától függ.

Identitás több bérlő között

Ha a Microsoft Sentinelt az Azure DevOpsszal szeretné kezelni, értékelje ki az összetevőkre vonatkozó alábbi tervezési döntéseket.

Használati eset	Előnyök
Globális identitás a DevOps-műveletek kezeléséhez, egyetlen szolgáltatásnév	Ez az eset az összes bérlőt magában foglaló globális üzembehelyezési folyamatokra vonatkozik. Az egységes identitás használata megkönnyíti a hozzáférést a különböző bérlők számára, de összetettebbé teheti az adott bérlők jóváhagyási műveleteinek kezelését. Az ilyen típusú identitások védelmi mechanizmusa és engedélyezési modellje szintén nagyon fontos, hogy elkerüljük a nem engedélyezett használatot, amely a kapcsolódó globális hatásnak köszönhető.
Dedikált identitás a DevOps-műveletek kezeléséhez, több szolgáltatásnév	Ez az eset akkor érvényes, ha az üzembehelyezési folyamatok minden bérlői vagy bérlői művelethez dedikáltak, és jóváhagyást igényelnek. Ebben az esetben az identitáshasználat védelmére és engedélyezésére vonatkozó javaslat ugyanaz, mint a globális esetben, még akkor is, ha a hatás csökken.

Kódtár szervezete

Használati eset	Előnyök
Egységesített adattár egyetlen kódverzióval az összes bérlőhöz	Ez az eset megkönnyíti a kód egységes verzióinak használatát az adattárban. Ebben az esetben a kód egy adott bérlői verziót kezelő egységes verziója minden esetben igényelhet támogatást az ágakon.
Egységesített adattár adott kódmappákkal bérlő szerint	Ez az eset kiegészíti az egyadattár-esetet. Itt egy mappastruktúra feloszthatja a dedikált összetevőket bérlőnként.
Dedikált adattár bérlő szerint	Ez a megközelítés elkülönítést biztosít a kódösszetevők kezelésekor. Megkönnyíti a különböző csapatokkal vagy követelményekkel rendelkező bérlők közötti fejlődést. A módosítások összevonásához létre kell hoznia egy folyamatot az adattárak között, ami karbantartást igényelhet.

Buildelési és üzembehelyezési folyamatok

Használati eset	Előnyök
Egyetlen buildelési folyamat az összes bérlőhöz	Ha minden bérlő az összetevők ugyanazon verziójával dolgozik, ez a legegyszerűbb megoldás a létrehozás és a csomag implementálásához.
Létrehozási folyamat bérlő szerint	A kód egy másik verziója van üzembe helyezve az egyes bérlőkben.
Globális üzembehelyezési folyamat az összes bérlőhöz	Az új üzembe helyezések és az üzembe helyezési frissítések minden bérlőre érvényesek. Az üzembe helyezési és frissítési folyamatok lépéseit az összes bérlő használja.
Globális üzembehelyezési folyamat bérlőnként	Az új üzembe helyezések és az üzembe helyezési frissítések egy vagy több bérlőre vonatkoznak.
Dedikált üzembehelyezési folyamat bérlő szerint	Az üzembe helyezési folyamat minden bérlőhöz igazodik.

Költségoptimalizálás

A költségoptimalizálás a szükségtelen kiadások csökkentéséről és a működési hatékonyság javításáról szól. További információ: A költségoptimalizálási pillér áttekintése.

A megoldás költsége a következő tényezőktől függ:

• A vállalat által a Microsoft Sentinel Log Analytics-munkaterületre havonta betáplálásra került adatok mennyisége
• A választott kötelezettségvállalási szint vagy számlázási módszer, például a használatalapú fizetés (PAYG)
• Az adatszabályzatok adatmegőrzési aránya egy táblázatban vagy globális szinten

További információ: Azure-adattípus-megőrzés.

A díjszabás kiszámításához tekintse meg a Microsoft Sentinel díjkalkulátorát. A speciális díjszabási szempontokról és példákról további információt a Microsoft Sentinel költségeinek megtervezése című témakörben talál.

További költségek merülhetnek fel, ha a megoldást az alábbi összetevőkkel bővíti:

• Forgatókönyvek – az Azure Logic Apps és az Azure Functions futtatókörnyezetei. További információ: Díjszabási adatok.
• Exportálás külső tárolóba, például Azure Data Explorerbe, Event Hubsba vagy Azure Storage-fiókba.
• Egy gépi tanulási munkaterület és egy Jupyter Notebook-összetevő által használt számítás.

A forgatókönyv üzembe helyezése

A következő szakasz a forgatókönyv üzembe helyezésének lépéseit ismerteti a különböző DevOps-folyamatokra kiterjedő mintahasználati eset formájában.

A Microsoft Sentinel keretrendszer létrehozása és kiadása

Először állítsa be a szükséges NuGet-összetevőket egy dedikált adattárban, ahol a különböző folyamatok felhasználhatják a létrehozott kiadásokat.

Ha az Azure DevOpsszal dolgozik, létrehozhat egy összetevőcsatornát a PowerShellHez készült Microsoft Sentinel keretrendszer különböző NuGet-csomagjainak üzemeltetéséhez. További információ: Ismerkedés a NuGet-csomagokkal.

Ha a csapata egy GitHub-beállításjegyzéket választ, nuGet-adattárként csatlakoztathatja, mert kompatibilis a hírcsatorna protokollal. További információ: Bevezetés a GitHub-csomagok használatába.

Ha rendelkezik egy elérhető NuGet-adattárral, a folyamat a NuGet szolgáltatáskapcsolatát tartalmazza. Ezek a képernyőképek a Microsoft Sentinel NuGet Framework Csatlakozás ion nevű új szolgáltatáskapcsolat konfigurációját mutatják be.

A hírcsatorna konfigurálása után importálhatja a PowerShell-keretrendszer létrehozásához szükséges folyamatot közvetlenül a GitHubról egy adott elágazásban. További információ: GitHub-adattárak létrehozása. Ebben az esetben létrehoz egy új folyamatot, és a GitHubot választja kódforrásként.

Egy másik lehetőség a Git-adattár importálása a Giten alapuló Azure DevOps-adattárként. Mindkét esetben a folyamat importálásához adja meg a következő elérési utat:

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

Most már első alkalommal futtathatja a folyamatot. Ezután a keretrendszer létrehozza és kiadja a NuGet-hírcsatornát.

A Microsoft Sentinel-környezet meghatározása

A Microsoft Sentineltől kezdődően és a minták használatakor határozza meg a vállalat környezetét, például a Környezetet kódként vagy EaC-ként. Minden esetben meg kell adnia a környezetet alkotó különböző elemeket.

A Microsoft Sentinel architektúrája a következő elemeket tartalmazza az Azure-ban:

• Log Analytics-munkaterület – Ez a munkaterület képezi a megoldás alapját. A biztonsági adatok tárolása itt történik, és a munkaterület a Kusto lekérdezésnyelv (KQL) motorja.
• Microsoft Sentinel-megoldás a Log Analytics-munkaterületen – Ez a megoldás kiterjeszti a Log Analytics-munkaterület funkcióit, hogy SIEM- és SOAR-képességeket is tartalmazzon.
• Key Vault – A kulcstartó megőrzi a szervizelési folyamatok során használt titkos kulcsokat és kulcsokat.
• Automation-fiók – Ez a fiók nem kötelező, és a szervizelési folyamatokhoz használatos. A használt szervizelési folyamat a PowerShell- és Python-runbookokon alapul. A folyamat tartalmaz egy rendszer által felügyelt identitást, amely az ajánlott eljárásoknak megfelelően különböző erőforrásokkal működik.
• Felhasználó által felügyelt identitás – Ez a funkció a Microsoft Sentinel egységes identitásrétegeként működik, amely kezeli a Microsoft Sentinel forgatókönyvek és runbookok közötti interakciókat.
• Logic App-kapcsolatok – Ezek a Microsoft Sentinel, a kulcstartó és az automatizálás felhasználói által felügyelt identitást használó kapcsolatai.
• Külső logikai alkalmazáskapcsolatok – Ezek olyan külső erőforrások kapcsolatai, amelyek részt vesznek a szervizelési folyamatokban, és amelyek a forgatókönyveken alapulnak.
• Azure Event Hubs – Ez a funkció nem kötelező, és kezeli a Microsoft Sentinel és más megoldások, például a Splunk, az Azure Databricks és a gépi tanulás, valamint az Rugalmas integrációt.
• Tárfiók – Ez a funkció nem kötelező, és kezeli a Microsoft Sentinel és más megoldások, például a Splunk, az Azure Databricks és a gépi tanulás, valamint az Rugalmas integrációt.

Az adattárból származó példák használatával JSON-fájlokkal határozhatja meg a környezetet a különböző logikai fogalmak megadásához. A környezet meghatározásához rendelkezésre álló beállítások lehetnek literál vagy automatikusak.

A konstans definícióban meg kell adnia a környezet egyes erőforrásainak nevét és elemeit az ebben a példában látható módon.

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

Az automatikus definícióban az elemnevek az elnevezési konvenciók alapján automatikusan létrejönnek, ahogyan az ebben a példában is látható.

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

A Microsoft Sentinel-környezetek elérési útja alatt található GitHub-adattárban találhat mintákat, és referenciaként használhatja a mintákat a használati esetek előkészítéséhez.

A Microsoft Sentinel-környezet üzembe helyezése

Ha legalább egy környezet van meghatározva, létrehozhatja az Azure-szolgáltatáskapcsolatot az Azure DevOpsba való integrációhoz. A szolgáltatáskapcsolat létrehozása után állítsa a társított szolgáltatásnevet a tulajdonosi szerepkörre vagy egy hasonló engedélyszintre a célelőfizetésen keresztül.

1. Importálja az új környezet létrehozására szolgáló folyamatot a fájlban meghatározott módon.

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

2. Ezután adja meg a környezetet képviselő szolgáltatáskapcsolat nevét.

   

3. Válassza ki a környezetdefiníció ágát az adattárban. 

4. Adja meg az előfizetéséhez tartozó Azure DevOps szolgáltatáskapcsolat nevét az Azure Environment Csatlakozás ion mezőben.

5. Adja meg annak a környezetnek a nevét, amellyel egy szolgáltatáskapcsolat több környezetet is feloldhat ugyanabban az előfizetésben.

6. Válassza ki az összekötőkre alkalmazandó műveletet.

7. Válassza a PowerShell előzetes kiadás előtti összetevőinek használata lehetőséget, ha a PowerShell-keretrendszer összetevőinek előzetes verzióit szeretné használni.

A folyamat a következő lépéseket tartalmazza az üzembehelyezési folyamat részeként:

• NuGet-összetevők üzembe helyezése.
• Csatlakozás NuGet-eszközökkel az összetevők tárházával.
• Oldja fel a hírcsatornát.
• Telepítse a szükséges modulokat.
• Kérje le a környezetdefiníciót.
• Ellenőrizze, hogy mely erőforrások találhatók a célhelyen.
• Ha nincsenek a munkaterületen, adja hozzá a Log Analyticset és a Microsoft Sentinelt.
• Ha már rendelkezik a Log Analytics szolgáltatásával, adja hozzá a Microsoft Sentinelt a Log Analytics-példányhoz.
• Hozzon létre egy felügyelt identitást, amely a Microsoft Sentinel és a Logic Apps közötti interakciót képviseli.
• Hozza létre az Azure Key Vaultot, és állítsa be a szerepkör-hozzárendelést a titkos kódok és kulcsok felügyelt identitáshoz való kezeléséhez.
• Szükség esetén hozzon létre egy Azure Automation-fiókot, és kapcsolja be a rendszer által hozzárendelt felügyelt identitást.
• Állítsa be a szerepkör-hozzárendelést a rendszer által hozzárendelt felügyelt identitás kulcstartójában.
• Ha nem léteznek, hozza létre az Event Hubs-definíciókat, és adja meg, hogy a definíció tartalmazza-e az integrációs elemeket.
• Állítsa be a szerepkör-hozzárendelést a rendszer által hozzárendelt felügyelt identitás kulcstartójában.
• Hozza létre a tárfiókdefiníciókat, ha nem léteznek, és állítsa be, hogy a definíció tartalmazza-e az integrációs elemeket.
• Állítsa be a szerepkör-hozzárendelést a rendszer által hozzárendelt felügyelt identitás kulcstartójában.
• Az összekötő műveleteinek üzembe helyezése.
• Telepítse az integrációs runbookot az Automation-fiókban.
• A Logic Apps-kapcsolatok üzembe helyezése, ha azok a környezet részeként vannak definiálva.

Microsoft Sentinel-környezet elpusztítása

Ha a környezetre már nincs szükség, például fejlesztési vagy tesztelési környezet esetén, a fájlban meghatározott módon megsemmisítheti azt.

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

A környezeti folyamat üzembe helyezésekor meg kell adnia a környezetet jelképező szolgáltatáskapcsolat nevét.

A Microsoft Sentinel-környezet használata

Miután a környezet elkészült, elkezdheti létrehozni az összetevőket a különböző használati esetek beállításához.

1. Exportálja az összetevőket a fájlban definiált környezetből.

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

2. Válassza ki a környezetdefiníció ágát az adattárban.

   

3. Adja meg az Exportálandó környezet Azure DevOps szolgáltatáskapcsolatának nevét az Azure Environment Csatlakozás ion mezőben.

4. Válassza a PowerShell előzetes kiadás előtti összetevőinek használata lehetőséget, ha a PowerShell-keretrendszer összetevőinek előzetes verzióit szeretné használni.

5. Válassza ki a elemzési és a vadászati szabályok formátumát.

   Az összetevők kimeneti fájlja elérhető az eredmények között. Miután elvégezte az összetevőket, felveheti a kimeneti fájlt a Git-adattárba.

Összetevők létrehozása a Microsoft Sentinel-környezetben

Helyezze el az összetevőket a Microsoft Sentinel MITRE használati esetek elérési útja alatt. Állítsa be a mappastruktúrát a különböző típusú összetevők szerint.

1. Indítsa el a buildelési folyamatot a fájlban meghatározott módon.

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

2. Válassza ki a környezetdefiníció ágát az adattárban.

   Az összetevők készítéséhez szükséges ág kiválasztásának diagramja.] (./media/build-artifacts-pipeline.png)

3. Válassza a PowerShell előzetes kiadás előtti összetevőinek használata lehetőséget, ha a PowerShell-keretrendszer összetevőinek előzetes verzióit szeretné használni.

A folyamat a következő lépésekből áll:

• NuGet-összetevők üzembe helyezése.
• Csatlakozás a NuGet-eszközöket az összetevők adattárába.
• Oldja fel a hírcsatornát.
• Telepítse a szükséges modulokat.
• Szerezze be a Test toolkit frameworkt az ARM-sablonok érvényesítéséhez.
• Ellenőrizze az ARM-sablonokat.
• Ellenőrizze a PowerShell-runbookok kódját, és végezze el a szintaxis érvényesítését.
• Szükség esetén futtassa a Pester egységteszteket.
• Ellenőrizze a KQL szintaxisát a vadászati és elemzési szabályokban.

Összetevők üzembe helyezése a Microsoft Sentinel-környezetben

Az összetevők üzembe helyezésekor használhatja a Microsoft Sentinel-adattárakat vagy az üzembehelyezési folyamat mintáit ezen az adattáron. További információ: Egyéni tartalom üzembe helyezése az adattárból.

Microsoft Sentinel-adattárak

Ha Microsoft Sentinel-adattárakat használ, beállíthat egy kiadási folyamatot, amely az egyes Microsoft Sentinel-példányokhoz csatlakoztatott adattárban lévő összetevőket tartalmazza. Miután az összetevők véglegesítése megtörtént az adattárban, a folyamat létrehozása és a Microsoft Sentinel-adattárak engedélyezése során a rendszer automatikusan elvégzi a lépéseket.

Emellett testre szabhatja a Microsoft Sentinel-adattárak üzembehelyezési folyamatait a jelen dokumentumban ismertetett eljárások alapján. Az egyik fontos szempont a kiadás jóváhagyása, amelyet az alábbi módszerekkel állíthat be:

• A lekéréses kérelem jóváhagyása az összetevők véglegesítésekor. További információ: Lekéréses kérelmek létrehozása.
• A folyamat jóváhagyása az üzembe helyezés futtatásakor. További információ: Jóváhagyások és ellenőrzések meghatározása.

Microsoft Sentinel üzembehelyezési folyamatminták

A Microsoft Sentinel üzembehelyezési folyamat mintáival beállíthat egy kiadási folyamatot.

1. Állítsa be a kiadási folyamatot a fájlban meghatározott módon.

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

2. Válassza ki a környezetdefiníció ágát az adattárban.

   

3. Adja meg az Exportálandó környezet Azure DevOps szolgáltatáskapcsolatának nevét az Azure Environment Csatlakozás ion mezőben.

4. Válassza a PowerShell előzetes kiadás előtti összetevőinek használata lehetőséget, ha a PowerShell-keretrendszer összetevőinek előzetes verzióit szeretné használni.

Közreműködők

Ezt a cikket a Microsoft tartja karban. Eredetileg a következő közreműködők írták.

Fő szerző:

• Kevin Kisoka | Tervező társítása

A nem nyilvános LinkedIn-profilok megtekintéséhez jelentkezzen be a LinkedInbe.

Következő lépések

• A Microsoft Sentinel és az egybérlős architektúra DevOps szolgáltatással való használatával kapcsolatos további információkért lásd a Microsoft Sentinel kódként való üzembe helyezését és kezelését ismertető témakört.
• Az MSSP több-bérlős architektúrájáról az Azure Lighthouse és a Microsoft Sentinel DevOps képességeinek kombinálása című témakörben olvashat.
• A Microsoft Sentinel felügyelt identitásával kapcsolatos információkért tekintse meg a Microsoft Sentinel Logic Apps-összekötő felügyelt identitásával kapcsolatos újdonságokat.
• Ha tudni szeretné, hogyan helyezhet üzembe tartalmakat a Microsoft Sentinel-adattárból, olvassa el az egyéni tartalmak üzembe helyezése az adattárból című témakört.
• Az Azure DevOps biztonsági szempontjairól az alapértelmezett engedélyek rövid útmutatója nyújt tájékoztatást.
• Az Azure DevOps-adattárak védelmének megismeréséhez tekintse meg a Védelem hozzáadása adattár-erőforráshoz című témakört.
• Az Azure DevOps szolgáltatás kapcsolatbiztonságának kezelésével kapcsolatos információkért tekintse meg az Azure Pipelines szolgáltatáskapcsolatait.

Kapcsolódó erőforrások

• Hibrid biztonsági monitorozás a Felhőhöz készült Microsoft Defender és a Microsoft Sentinel használatával
• CI/CD-folyamat tervezése az Azure DevOps használatával
• Speciális ARM-sablonfunkciók