Automatyzowanie integracji usługi Sentinel z usługą Azure DevOps

W tym artykule opisano sposób automatyzowania operacji integracji i wdrażania usługi Microsoft Sentinel za pomocą usługi Azure DevOps. Zaimplementujesz usługę Azure DevOps przy użyciu funkcji usługi Microsoft Sentinel, aby ułatwić zabezpieczanie wdrożenia. Następnie użyjesz struktury DevSecOps do zarządzania artefaktami usługi Microsoft Sentinel na dużą skalę i wdrażania ich.

Architektura

Na poniższym diagramie przedstawiono konfigurację IaC usług Azure DevOps i Microsoft Sentinel.

Pobierz plik programu Visio z tą architekturą.

Przepływ danych

1. Master scrum master i zarządzanie produktami używają usługi Azure DevOps do definiowania epików, historii użytkowników i elementów listy prac produktu w ramach listy prac projektu.
   • Narzędzie scrum master i zarządzanie produktami używają usługi Azure Boards do tworzenia listy prac, planowania pracy w przebiegach, przeglądania tablicy projektu, tworzenia struktury repozytorium i ustawiania reguł zabezpieczeń, takich jak przepływy pracy zatwierdzania i gałęzie.
   • Repozytorium Git platformy Azure przechowuje skrypty i zezwolenia na zarządzanie artefaktami usługi Microsoft Sentinel w infrastrukturze jako kodem.
   • Artefakty i kontrola źródła utrzymują rozszerzenia i pakiety aktualizacji lub składniki przepływu pracy DevSecOps używanego w rozwiązaniu, takiego jak zestaw narzędzi szablonu usługi Azure Resource Manager i program PowerShell Pester.
2. Artefakty usługi Microsoft Sentinel:
   • Zasady. Inżynierowie SIEM używają zasad platformy Azure w architekturze referencyjnej do konfigurowania i skalowania ustawień diagnostycznych usług platformy Azure. Zasady pomagają zautomatyzować wdrażanie łączników danych usługi Microsoft Sentinel, takich jak usługa Azure Key Vault. Zasady są zależne od interfejsu API OMSIntegration.
   • Łączniki. Usługa Microsoft Sentinel używa łączników logicznych, Połączenie or danych platformy Azure do pozyskiwania danych zabezpieczeń, podobnie jak w przypadku inspekcji lub metryk, z obsługiwanych źródeł danych, takich jak Microsoft Entra ID, zasoby platformy Azure, usługa Microsoft Defender lub rozwiązania innych firm. Główna lista łączników danych jest zarządzana przez interfejs API Security Szczegółowe informacje. Inne polegają na interfejsie API OMSIntegration i są zarządzane przy użyciu ustawień diagnostycznych usługi Azure Policy.
   • Tożsamość zarządzana. Usługa Microsoft Sentinel używa tożsamości zarządzanej do działania w imieniu tożsamości usługi zarządzanej (MSI) podczas interakcji z podręcznikami, aplikacjami logiki lub elementami Runbook automatyzacji i magazynem kluczy.
   • Automatyzacja. Zespoły SOC używają automatyzacji podczas badania. Zespoły SOC uruchamiają procedury pozyskiwania danych śledczego cyfrowego za pomocą usługi Azure Automation, takie jak łańcuch nadzoru maszyn wirtualnych platformy Azure lub zbierania elektronicznych materiałów dowodowych (Premium) dla usługi Microsoft Defender.
   • Analiza. Analitycy SOC lub łowcy zagrożeń używają wbudowanych lub niestandardowych reguł analizy do analizowania i korelowania danych w usłudze Microsoft Sentinel lub wyzwalania podręczników w przypadku zidentyfikowania zagrożenia i zdarzenia.
   • Podręczniki. Aplikacje logiki uruchamiają powtarzalne akcje SecOps, takie jak przypisywanie zdarzenia, aktualizowanie zdarzenia lub podejmowanie akcji korygujących, takich jak izolowanie lub zawieranie maszyny wirtualnej, odwołowanie tokenu lub resetowanie hasła użytkownika.
   • Wyszukiwanie zagrożeń. Łowcy zagrożeń używają proaktywnych funkcji wyszukiwania zagrożeń, które można połączyć z notesami Jupyter w zaawansowanych przypadkach użycia, takich jak przetwarzanie danych, manipulowanie danymi, wizualizacja danych, uczenie maszynowe lub uczenie głębokie.
   • Skoroszytów. Inżynierowie SIEM używają pulpitów nawigacyjnych skoroszytów do wizualizacji trendów i statystyk oraz do wyświetlania stanu wystąpienia usługi Microsoft Sentinel i jego podskładników.
   • Analiza zagrożeń. Konkretny łącznik danych, który łączy platformy analizy zagrożeń, jest przesyłany do usługi Microsoft Sentinel. Obsługiwane są dwie metody łączności: TAXII i Graph API. Obie metody służą jako wskaźniki tiIndicators lub analizy zagrożeń w interfejsach API zabezpieczeń.
3. Microsoft Entra ID. Funkcje zarządzania tożsamościami i dostępem są dostarczane do składników używanych w architekturze referencyjnej, takich jak tożsamości zarządzane, jednostki usługi, mechanizmy kontroli dostępu opartej na rolach (RBACs) platformy Azure dla usługi Microsoft Sentinel, aplikacji logiki i elementów Runbook automatyzacji.
4. Azure Pipelines. Inżynierowie devOps używają potoków do tworzenia połączeń usług na potrzeby zarządzania różnymi subskrypcjami platformy Azure, takimi jak środowiska piaskownicy i środowiska produkcyjne z potokami ciągłej integracji i ciągłego dostarczania (CI/CD). Zalecamy używanie przepływów pracy zatwierdzania, aby zapobiec nieoczekiwanym wdrożeniom i oddzielnym jednostkom usługi, jeśli jest przeznaczonych dla wielu subskrypcji na środowisko platformy Azure.
5. Azure Key Vault. Inżynierowie SOC używają magazynu kluczy do bezpiecznego przechowywania wpisów tajnych i certyfikatów jednostki usługi. Ten składnik architektury pomaga wymusić zasadę DevSecOps braku wpisów tajnych w kodzie , gdy są używane przez połączenia usługi Azure Pipeline.
6. Subskrypcja platformy Azure. Zespoły SOC używają dwóch wystąpień usługi Microsoft Sentinel w tej architekturze referencyjnej, oddzielonych w ramach dwóch logicznych subskrypcji platformy Azure w celu symulowania środowisk produkcyjnych i piaskownicy. Możesz skalować pod kątem potrzeb z innymi środowiskami, takimi jak testowanie, tworzenie deweloperskie, przedprodukcyjne itd.

Przykład przepływu danych

1. Administrator dodaje, aktualizuje lub usuwa wpis w rozwidleniu pliku konfiguracji platformy Microsoft 365.
2. Administrator zatwierdza i synchronizuje zmiany z rozwidlonym repozytorium.
3. Następnie administrator tworzy żądanie ściągnięcia w celu scalenia zmian w repozytorium głównym.
4. Potok kompilacji jest uruchamiany w żądaniu ściągnięcia.

Składniki

• Microsoft Entra ID to wielodostępna, oparta na chmurze usługa do zarządzania tożsamościami i kontrolami dostępu.
• Azure DevOps to usługa w chmurze, która umożliwia współpracę nad kodem, tworzeniem i wdrażaniem aplikacji albo planowaniem i śledzeniem pracy.
• Azure Key Vault to usługa w chmurze do bezpiecznego przechowywania i uzyskiwania dostępu do wpisów tajnych. Wpis tajny to wszystko, do czego chcesz ściśle kontrolować dostęp, na przykład klucze interfejsu API, hasła, certyfikaty lub klucze kryptograficzne.
• Azure Policy to usługa służąca do tworzenia i przypisywania definicji zasad oraz zarządzania nimi w środowisku platformy Azure.
• Microsoft Sentinel to skalowalne, natywne dla chmury rozwiązanie SIEM i aranżacja zabezpieczeń, automatyzacja i reagowanie (SOAR).
• Azure Automation to usługa ułatwiając zarządzanie chmurą dzięki automatyzacji procesów. Usługa Azure Automation umożliwia automatyzowanie długotrwałych, ręcznych, podatnych na błędy i często powtarzanych zadań. Automatyzacja pomaga zwiększyć niezawodność, wydajność i czas na wartość dla twojej firmy.

Szczegóły scenariusza

Zespoły centrum operacji zabezpieczeń (SOC) czasami napotykają wyzwania podczas integrowania usługi Microsoft Sentinel z usługą Azure DevOps. Proces obejmuje wiele kroków, a konfiguracja może potrwać kilka dni i obejmować powtórzenie. Tę część programowania można zautomatyzować.

Aby zmodernizować chmurę, inżynierowie muszą stale uczyć się nowych umiejętności i technik zabezpieczania i ochrony ważnych zasobów biznesowych. Inżynierowie muszą tworzyć niezawodne i skalowalne rozwiązania, które nadążają za zmieniającym się krajobrazem zabezpieczeń i potrzebami biznesowymi. Rozwiązanie zabezpieczeń musi być elastyczne, zwinne i starannie zaplanowane od najwcześniejszych etapów programowania. Ta metodologia wczesnego planowania jest znana jako shift-left.

W tym artykule opisano sposób automatyzowania operacji integracji i wdrażania usługi Microsoft Sentinel za pomocą usługi Azure DevOps. Możesz rozszerzyć rozwiązanie dla złożonych organizacji, które mają wiele jednostek, subskrypcji i różnych modeli operacyjnych. Niektóre modele operacyjne obsługiwane przez to rozwiązanie obejmują lokalne SOC, globalne SOC, dostawcę usług w chmurze (CSP) i zarządzanego dostawcę usług zabezpieczeń (MSSP).

Ten artykuł jest przeznaczony dla następujących odbiorców:

• Specjaliści SOC, tacy jak analitycy i łowcy zagrożeń
• Inżynierowie ds. zarządzania informacjami i zdarzeniami zabezpieczeń (SIEM)
• Architekci cyberbezpieczeństwa
• Deweloperzy

Potencjalne przypadki użycia

Poniżej przedstawiono typowe przypadki użycia tej architektury:

• Szybkie tworzenie prototypów i weryfikacja koncepcji. To rozwiązanie jest idealne dla organizacji zabezpieczeń i zespołów SOC, które chcą poprawić pokrycie zagrożeń w chmurze lub zmodernizować infrastrukturę SIEM przy użyciu infrastruktury jako kodu (IaC) i usługi Microsoft Sentinel.
• Microsoft Sentinel jako usługa. Ta struktura deweloperska integruje zasady zarządzania cyklem życia usługi. Te zasady są odpowiednie dla prostych lub złożonych zespołów, takich jak dostawcy usług MSSPs, którzy uruchamiają powtarzalne, ustandaryzowane akcje w wielu dzierżawach klientów, łącząc możliwości usług Azure DevOps i Azure Lighthouse. Na przykład zespół, który musi opublikować przypadki użycia usługi Microsoft Sentinel dla nowego aktora zagrożeń lub trwającej kampanii, może użyć tego rozwiązania.
• Kompilowanie przypadków użycia SOC na potrzeby wykrywania zagrożeń. Wiele grup i platform analizy zagrożeń polega na zawartości i taksonomii MITRE Att&ck, aby przeanalizować stan bezpieczeństwa przed zaawansowanymi rzemiosłami lub technikami i procedurami taktyki. Rozwiązanie definiuje ustrukturyzowane podejście do opracowywania praktyk inżynieryjnych wykrywania zagrożeń przez włączenie terminologii MITRE Att&ck w ramach opracowywania artefaktów usługi Microsoft Sentinel.

Na poniższej ilustracji przedstawiono scenariusz chmury MITRE Att&ck.

Pobierz plik programu Visio z tą architekturą.

Scenariusze ataku na definicję zagrożeń oparte na usłudze MITRE

W tej tabeli przedstawiono terminy, definicje i szczegóły ważnych aspektów scenariuszy ataku.

Element danych	opis	Artefakty usługi Microsoft Sentinel
Tytuł	Opisowa nazwa scenariusza ataku oparta na cechach wektorów ataku lub opisach technik.	Manifest MITRE
TAKTYKA MITRE ATT&CK	TAKTYKA MITRE ATT&CK związana ze scenariuszem ataku	Manifest MITRE
TECHNIKI MITRE ATT&CK	TECHNIKI MITRE ATT&CK, w tym technika lub identyfikator sub-techniki, związane ze scenariuszem ataku.	Manifest MITRE
Źródła łącznika danych	Źródło informacji zebranych przez czujnik lub system rejestrowania, który może służyć do zbierania informacji istotnych do identyfikowania wykonywanej akcji, sekwencji akcji lub wyników tych działań przez przeciwnika.	Łącznik danych usługi Microsoft Sentinel lub niestandardowe źródło dziennika
opis	Informacje na temat techniki, tego, co to jest, co jest zwykle używane, jak przeciwnik może z niego korzystać, i różnice w sposobie jego użycia. Zawiera odwołania do autorytatywnych artykułów opisujących informacje techniczne związane z techniką, a także w odpowiednich odwołaniach do użytku dzikiego.
Detection	Ogólny proces analityczny, czujniki, dane i strategie wykrywania przydatne podczas identyfikowania techniki używanej przez przeciwnika. Ta sekcja informuje osoby odpowiedzialne za wykrywanie zachowań przeciwników, takich jak obrońcy sieci, dzięki czemu mogą podjąć działania, takie jak pisanie analizy lub wdrażanie czujnika. Powinna istnieć wystarczająca ilość informacji i odwołań, aby wskazać na przydatne metodologie obronne. Wykrywanie może nie zawsze być możliwe dla określonej techniki i powinno być udokumentowane w ten sposób.	Wyszukiwanie zagrożeń analitycznych
Czynności zapobiegawcze	Konfiguracje, narzędzia lub procesy, które uniemożliwiają działanie techniki lub uzyskanie pożądanego wyniku dla przeciwnika. Ta sekcja informuje osoby odpowiedzialne za łagodzenie działań przeciwko przeciwnikom, takim jak obrońcy sieci lub decydenci, aby umożliwić im podjęcie działań, takich jak zmiana zasad lub wdrożenie narzędzia. Środki zaradcze mogą nie zawsze być możliwe dla danej techniki i powinny być udokumentowane jako takie.
Czynności zapobiegawcze	Konfiguracje, narzędzia lub procesy, które uniemożliwiają działanie techniki lub uzyskanie pożądanego wyniku dla przeciwnika. W tej sekcji opisano, jak zmniejszyć skutki ataków niepożądanych dla obrońców sieci lub decydentów politycznych. Obejmuje on kroki zmiany zasad lub wdrażania narzędzia. Środki zaradcze mogą nie zawsze być możliwe dla określonej techniki i powinny być udokumentowane jako takie.	Podręczniki, elementy Runbook automatyzacji

Kwestie wymagające rozważenia

Te zagadnienia implementują filary platformy Azure Well-Architected Framework— zestaw wytycznych, których można użyć do poprawy jakości obciążenia. Aby uzyskać więcej informacji, zobacz Microsoft Azure Well-Architected Framework.

Zabezpieczenia

Zabezpieczenia zapewniają ochronę przed celowymi atakami i nadużyciami cennych danych i systemów. Aby uzyskać więcej informacji, zobacz Omówienie filaru zabezpieczeń.

W przypadku zabezpieczeń, ogólnie rzecz biorąc, automatyzacja zwiększa wydajność operacji przy jednoczesnym oszczędzaniu czasu dla bardziej złożonych przypadków użycia, takich jak inżynieria wykrywania zagrożeń, analiza zagrożeń, SOC i przypadki użycia SOAR. Zespoły DevOps muszą wiedzieć, gdzie mogą bezpiecznie korzystać z usługi IaC w kontekście ciągłej integracji/ciągłego wdrażania usługi Microsoft Sentinel. W tym procesie wprowadzono użycie określonych tożsamości, które są używane przez konta inne niż ludzkie w usłudze Microsoft Entra ID nazywane jednostkami usługi i tożsamościami zarządzanymi.

Poniższa tabela zawiera podsumowanie zagadnień dotyczących zabezpieczeń jednostek usługi i głównych przypadków użycia, które są objęte potokami wydań usługi Microsoft Sentinel i Azure DevOps.

Przypadek użycia	Wymagania (najmniej uprzywilejowane)	Czas trwania przypisania roli	Zakres uprawnień	Powiernika	Zagadnienia dotyczące zabezpieczeń
Włączanie łączników usługi Microsoft Sentinel	Administrator zabezpieczeń** Właściciel* Współautor usługi Microsoft Sentinel Czytelnik	JIT (jednorazowa aktywacja) Celowo (za każdym razem, gdy jest wdrażana nowa subskrypcja i łącznik)	Dzierżawa	SPN	Magazyn kluczy służy do przechowywania wpisów tajnych i certyfikatów nazwy głównej usługi (SPN). Włącz inspekcję nazwy SPN. Okresowo przejrzyj przypisanie uprawnień (Azure Privileged Identity Management for SPN) lub podejrzane działania dla nazwy SPN. Używaj urzędów certyfikacji Firmy Microsoft Entra i uwierzytelniania wieloskładnikowego (jeśli jest obsługiwane) dla kont uprzywilejowanych. Użyj ról niestandardowych firmy Microsoft w celu uzyskania większej szczegółowości.
Wdrażanie artefaktów usługi Microsoft Sentinel, takich jak skoroszyty, analiza, reguły, zapytania wyszukiwania zagrożeń, notesy i podręczniki	Współautor usługi Microsoft Sentinel Współautor usługi Logic Apps	Stale	Obszar roboczy lub grupa zasobów usługi Microsoft Sentinel	SPN	Użyj zatwierdzania i sprawdzania przepływu pracy usługi Azure DevOps (ADO), aby zabezpieczyć wdrożenie potoku za pomocą tej nazwy SPN.
Przypisywanie zasad w celu skonfigurowania funkcji przesyłania strumieniowego dzienników do usługi Microsoft Sentinel	Współautor zasad zasobów **	Celowo (za każdym razem, gdy jest wdrażana nowa subskrypcja i łącznik)	Wszystkie subskrypcje, które mają być monitorowane	SPN	Użyj identyfikatora Entra firmy Microsoft, urzędu certyfikacji i uwierzytelniania wieloskładnikowego, jeśli jest to obsługiwane, w przypadku kont uprzywilejowanych.

* Dotyczy tylko ustawień diagnostyki Entra firmy Microsoft.
** Określone łączniki wymagają dodatkowych uprawnień, takich jak "administrator zabezpieczeń" lub "współautor zasad zasobów", aby umożliwić przesyłanie strumieniowe danych do obszaru roboczego usługi Microsoft Sentinel, identyfikatora Entra firmy Microsoft, platformy Microsoft 365 lub usługi Microsoft Defender oraz zasobów platformy jako usługi (PaaS), takich jak usługa Azure Key Vault.

Model dostępu uprzywilejowanego

Zalecamy wdrożenie strategii modelu dostępu uprzywilejowanego, aby szybko zmniejszyć ryzyko dla twojej firmy przed atakami o wysokim wpływie i wysokim prawdopodobieństwem na uprzywilejowany dostęp. W przypadku procesów automatycznych w modelu DevOps na podstawie tożsamości jednostki usługi.

Dostęp uprzywilejowany powinien być najwyższym priorytetem zabezpieczeń w każdej firmie. Każde naruszenie tych tożsamości powoduje bardzo negatywny wpływ. Tożsamości uprzywilejowane mają dostęp do zasobów krytycznych dla działania firmy, co prawie zawsze powoduje poważny wpływ, gdy osoby atakujące naruszyją te konta.

Bezpieczeństwo uprzywilejowanego dostępu jest niezwykle ważne, ponieważ jest podstawą wszystkich innych gwarancji zabezpieczeń. Osoba atakująca kontrolującą uprzywilejowane konta może podważyć wszystkie inne zabezpieczenia.

Z tego powodu zalecamy logiczne rozłożenie jednostek usługi na różne poziomy lub warstwy, postępując zgodnie z zasadą minimalnych uprawnień. Na poniższej ilustracji przedstawiono sposób klasyfikowania jednostek usługi w zależności od typu dostępu i miejsca, w którym jest wymagany dostęp.

Jednostki usługi poziomu 0

Jednostki usługi na poziomie 0 mają najwyższy poziom uprawnień. Te jednostki usługi uprawniają kogoś do wykonywania zadań administracyjnych dla całej dzierżawy lub głównej grupy zarządzania jako administrator globalny.

Ze względów bezpieczeństwa i możliwości zarządzania zalecamy posiadanie tylko jednej jednostki usługi dla tego poziomu. Uprawnienia dla tej jednostki usługi są utrwalane, dlatego zalecamy przyznanie tylko minimalnych uprawnień, które są wymagane, i zachować konto monitorowane i zabezpieczone.

Bezpiecznie przechowuj wpis tajny lub certyfikat dla tego konta w usłudze Azure Key Vault. Zdecydowanie zalecamy zlokalizowanie magazynu kluczy w dedykowanej subskrypcji administracyjnej, jeśli jest to możliwe.

Jednostki usługi poziomu 1

Jednostki usługi na poziomie 1 są podwyższonymi uprawnieniami, które są ograniczone i ograniczone do grup zarządzania na poziomie organizacji biznesowej. Te jednostki usługi uprawniają kogoś do tworzenia subskrypcji w grupie zarządzania, która jest w zakresie.

Ze względów bezpieczeństwa i możliwości zarządzania zalecamy posiadanie tylko jednej jednostki usługi dla tego poziomu. Uprawnienia dla tej jednostki usługi są utrwalane, dlatego zdecydowanie zalecamy przyznanie tylko minimalnych wymaganych uprawnień i utrzymania konta monitorowanego i zabezpieczonego.

Bezpiecznie przechowuj wpis tajny lub certyfikat dla tego konta w usłudze Azure Key Vault. Zdecydowanie zalecamy zlokalizowanie magazynu kluczy w dedykowanej subskrypcji administracyjnej, jeśli jest to możliwe.

Jednostki usługi poziomu 2

Jednostki usługi na poziomie 2 są ograniczone do poziomu subskrypcji. Te jednostki usługi uprawniają kogoś do wykonywania zadań administracyjnych w ramach subskrypcji, działając jako właściciel subskrypcji.

Ze względów bezpieczeństwa i możliwości zarządzania zalecamy posiadanie tylko jednej jednostki usługi dla tego poziomu. Uprawnienia dla tej jednostki usługi są utrwalane, dlatego zdecydowanie zalecamy przyznanie tylko minimalnych uprawnień, które są wymagane, i zachować konto monitorowane i zabezpieczone.

Bezpiecznie przechowuj wpis tajny lub certyfikat dla tego konta w usłudze Azure Key Vault. Zdecydowanie zalecamy zlokalizowanie magazynu kluczy w dedykowanej grupie zasobów administracyjnych.

Jednostki usługi poziomu 3

Jednostki usługi poziomu 3 są ograniczone do Administracja istratora obciążenia. W typowym scenariuszu każde obciążenie jest zawarte w tej samej grupie zasobów. Ta struktura ogranicza uprawnienia jednostki usługi tylko do tej grupy zasobów.

Ze względów bezpieczeństwa i możliwości zarządzania zalecamy posiadanie tylko jednej jednostki usługi na obciążenie. Uprawnienia dla tej jednostki usługi są utrwalane, dlatego zdecydowanie zalecamy przyznanie tylko minimalnych uprawnień, które są wymagane, i zachować konto monitorowane i zabezpieczone.

Bezpiecznie przechowuj wpis tajny lub certyfikat dla tego konta w usłudze Azure Key Vault. Zdecydowanie zalecamy zlokalizowanie magazynu kluczy w dedykowanej grupie zasobów administracyjnych.

Jednostki usługi poziomu 4

Jednostki usługi na poziomie 4 mają najbardziej ograniczone uprawnienia. Te jednostki usługi uprawniają kogoś do wykonywania zadań administracyjnych, które są ograniczone do jednego zasobu.

W miarę możliwości zalecamy używanie tożsamości zarządzanych. W przypadku tożsamości niezarządzanych należy bezpiecznie przechowywać wpis tajny lub certyfikat w usłudze Azure Key Vault, gdzie są przechowywane wpisy tajne poziomu 3.

Doskonałość operacyjna

Doskonałość operacyjna obejmuje procesy operacyjne, które wdrażają aplikację i działają w środowisku produkcyjnym. Aby uzyskać więcej informacji, zobacz Omówienie filaru doskonałości operacyjnej.

Rozwiązania microsoft Sentinel składają się z trzech bloków, które zapewniają pełne i pomyślne operacje.

Pierwszy blok to definicja środowiska, która składa się z podstawowych elementów architektury. Głównym problemem z tym blokiem jest rozważenie liczby środowisk produkcyjnych i nieprodukcyjnych do wdrożenia, a następnie upewnienie się, że konfiguracja jest jednorodna we wszystkich przypadkach.

Drugim blokiem jest wdrożenie łącznika usługi Microsoft Sentinel, w którym należy wziąć pod uwagę rodzaj łączników wymaganych przez zespół i wymagania dotyczące zabezpieczeń, aby je włączyć.

Trzeci blok to zarządzanie cyklem życia artefaktów usługi Microsoft Sentinel, które obejmuje kodowanie, wdrażanie i używanie lub niszczenie składników. Na przykład ten blok zawiera reguły analityczne, podręczniki, skoroszyty, wyszukiwanie zagrożeń itd.

Rozważ następujące zależności między artefaktami:

• Reguły automatyzacji zdefiniowane w regule analizy
• Skoroszyty lub analizy wymagające nowego źródła danych lub łącznika
• Zarządzanie aktualizacjami istniejących składników
  • Jak wersję artefaktów
  • Jak identyfikować, testować i wdrażać zaktualizowaną lub całkowicie nową regułę analizy

Tworzenie, testowanie i wdrażanie infrastruktury

W zarządzaniu rozwiązaniami usługi Microsoft Sentinel i metodykami DevOps należy wziąć pod uwagę aspekty łączności i zabezpieczeń architektury przedsiębiorstwa.

Usługa Azure DevOps może używać agentów hostowanych przez firmę Microsoft lub własnych agentów do tworzenia, testowania i wdrażania działań. W zależności od wymagań firmy można używać hostowanych przez firmę Microsoft, własnych lub kombinacji obu modeli.

• Agenci hostowani przez firmę Microsoft Ta opcja jest najszybszym sposobem pracy z agentami usługi Azure DevOps, ponieważ jest to udostępniona infrastruktura dla całej organizacji. Aby uzyskać więcej informacji na temat korzystania z agentów hostowanych przez firmę Microsoft w potoku, zobacz Agenci hostowani przez firmę Microsoft. Agenci hostowani przez firmę Microsoft mogą pracować w środowiskach sieci hybrydowych, udzielając dostępu do zakresów adresów IP. Aby pobrać zakresy adresów IP, do których ci agenci udzielają dostępu, zobacz Zakresy adresów IP platformy Azure i tagi usług — chmura publiczna.
• Agenci hostowani samodzielnie. Ta opcja zapewnia dedykowaną kontrolę nad zasobami i większą kontrolą podczas instalowania oprogramowania zależnego dla kompilacji i wdrożeń. Agenci self-hosted mogą pracować nad maszynami wirtualnymi, zestawami skalowania i kontenerami na platformie Azure. Aby uzyskać więcej informacji na temat własnych agentów, zobacz Azure Pipelines agents (Agenci usługi Azure Pipelines).

Moduły uruchamiane w usłudze GitHub

Usługa GitHub może używać modułów uruchamiających hostowane w usłudze GitHub lub samodzielnie hostowanych modułów uruchamiających działania związane z tworzeniem, testowaniem i wdrażaniem. W zależności od potrzeb firmy można użyć usługi GitHub hostowanej samodzielnie lub kombinacji obu modeli.

Moduły uruchamiane w usłudze GitHub

Ta opcja jest najszybszym sposobem pracy z przepływami pracy usługi GitHub, ponieważ jest to udostępniona infrastruktura dla całej organizacji. Aby uzyskać więcej informacji, zobacz About GitHub-hosted runners (Informacje o modułach uruchamianych w usłudze GitHub). Agenci hostowani w usłudze GitHub działają w środowiskach sieci hybrydowych zgodnie z pewnymi wymaganiami sieciowymi. Aby uzyskać więcej informacji na temat wymagań sieciowych, zobacz Obsługiwane moduły uruchamiacze i zasoby sprzętowe.

Moduły uruchamiane samodzielnie

Ta opcja zapewnia firmie dedykowaną infrastrukturę zasobów. Własne moduły uruchamiające działają na maszynach wirtualnych i kontenerach na platformie Azure i obsługują skalowanie automatyczne.

Zagadnienia dotyczące wybierania modułów uruchamiających

Podczas wybierania opcji agentów i modułów uruchamiających rozwiązanie usługi Microsoft Sentinel należy wziąć pod uwagę następujące potrzeby:

• Czy Twoja firma potrzebuje dedykowanych zasobów do uruchamiania procesów w środowiskach usługi Microsoft Sentinel?
• Czy chcesz odizolować zasoby dla działań devOps środowiska produkcyjnego z pozostałych środowisk?
• Czy należy przetestować niektóre przypadki, które wymagają dostępu do krytycznych zasobów lub zasobów, które są dostępne tylko w sieci wewnętrznej?

Orkiestracja i automatyzacja procesów wydawania

Proces wdrażania można skonfigurować za pomocą usługi Azure DevOps lub GitHub. Usługa Azure DevOps obsługuje używanie potoku YAML lub potoku wydania. Aby uzyskać więcej informacji na temat korzystania z potoku YAML w usłudze Azure DevOps, zobacz Korzystanie z usługi Azure Pipelines. Aby uzyskać więcej informacji na temat korzystania z potoku wydania w usłudze Azure DevOps, zobacz Potoki wydania. Aby uzyskać więcej informacji na temat korzystania z usługi GitHub z funkcją GitHub Actions, zobacz Omówienie funkcji GitHub Actions.

Azure DevOps

Następujące działania wdrażania można wykonać we wdrożeniu usługi Azure DevOps.

• Użyj potoku YAML, aby automatycznie wyzwalać zatwierdzenia żądania ściągnięcia lub uruchamiać je na żądanie.
• Zarządzanie połączeniami usług dla różnych środowisk przy użyciu grup usługi Azure DevOps.
• W środowiskach krytycznych skonfiguruj zatwierdzenia wdrożenia przy użyciu funkcji połączenia z usługą i grup usługi Azure DevOps w celu przypisania określonych uprawnień użytkowników w zespole.

GitHub

Następujące działania wdrażania można wykonać we wdrożeniu usługi GitHub.

• Użyj usługi GitHub, aby utworzyć żądania ściągnięcia lub działania wdrażania.
• Zarządzanie poświadczeniami jednostki usługi przy użyciu wpisów tajnych usługi GitHub.
• Zintegruj zatwierdzenie wdrożenia za pośrednictwem przepływu pracy skojarzonego z usługą GitHub.

Automatyczne wdrażanie za pomocą infrastruktury usługi Microsoft Sentinel

W zależności od architektury przedsiębiorstwa można wdrożyć co najmniej jedno środowisko usługi Microsoft Sentinel:

• Organizacje, które potrzebują wielu wystąpień w swoim środowisku produkcyjnym, mogą skonfigurować różne subskrypcje w tej samej dzierżawie dla każdej lokalizacji geograficznej.
• Scentralizowane wystąpienie w środowisku produkcyjnym zapewnia dostęp do co najmniej jednej organizacji w tej samej dzierżawie.
• Grupy, które wymagają wielu środowisk, takich jak produkcja, przedprodukcja, integracja i tak dalej, mogą je tworzyć i niszczyć w razie potrzeby.

Definicje środowiska fizycznego i logicznego

Istnieją dwie opcje konfigurowania definicji środowiska, fizycznych lub logicznych. Oba mają różne opcje i zalety:

• Definicja fizyczna — elementy architektury usługi Microsoft Sentinel są definiowane przy użyciu następujących opcji infrastruktury jako kodu (IaC):
  • Szablony Bicep
  • Szablony usługi Azure Resource Manager (szablony usługi ARM)
  • Terraform
• Definicja logiczna — działa to jako warstwa abstrakcji do konfigurowania różnych zespołów w grupie i definiowania ich środowisk. Definicja jest ustawiana w potoku wdrażania i przepływach pracy jako dane wejściowe dla środowiska kompilacji przy użyciu warstwy infrastruktury fizycznej.

Podczas definiowania środowisk logicznych należy wziąć pod uwagę następujące kwestie:

• Konwencje nazewnictwa
• Identyfikacje środowiska
• Połączenie ory i konfiguracje

Repozytorium kodu

Biorąc pod uwagę podejścia środowiska pokazane w poprzedniej sekcji, należy wziąć pod uwagę następującą organizację repozytorium kodu GitHub.

Definicja fizyczna — na podstawie opcji IaC pomyśl o podejściu, które korzysta z poszczególnych definicji modułów połączonych z główną definicją wdrożenia.

W poniższym przykładzie pokazano, jak można zorganizować kod.

Ogranicz dostęp do tego repozytorium do zespołu, który definiuje architekturę na poziomie fizycznym, zapewniając jednorodną definicję w architekturze przedsiębiorstwa.

Strategię rozgałęziania i scalania można dostosować do strategii wdrażania dla każdej organizacji. Jeśli twój zespół musi zacząć od definicji, zobacz Wdrażanie strategii rozgałęziania git.

Aby uzyskać więcej informacji na temat szablonów usługi ARM, zobacz Używanie połączonych i zagnieżdżonych szablonów podczas wdrażania zasobów platformy Azure.

Aby uzyskać więcej informacji na temat konfigurowania środowisk Bicep, zobacz Instalowanie narzędzi Bicep. Aby uzyskać więcej informacji na temat usługi GitHub, zobacz Przepływ usługi GitHub.

Definicje logiczne definiują środowiska firmy. Repozytorium Git zbiera różne definicje dla firmy.

W poniższym przykładzie pokazano, jak można zorganizować kod.

Repozytorium odzwierciedla akcje żądania ściągnięcia wykonywane przez różne zespoły. Wiele środowisk jest definiowanych przez różne zespoły i zatwierdzone przez właścicieli lub osoby zatwierdzające firmy.

Poziom uprawnień do uruchamiania wdrożenia środowiska to Poziom 2. Ten poziom zapewnia, że grupa zasobów i zasoby są tworzone dla środowiska z niezbędnymi zabezpieczeniami i prywatnością. Ten poziom ustawia również uprawnienia użytkownika do dozwolonych akcji w środowiskach produkcyjnych, środowisku produkcyjnym i przedprodukcyjnym.

Organizacje, które chcą, aby środowiska na żądanie testowały i programistyczne oraz możliwość niszczenia środowisk po zakończeniu testowania, mogą implementować potok usługi Azure DevOps lub akcje usługi GitHub. Mogą one ustawiać zaplanowane wyzwalacze, aby zniszczyć środowiska zgodnie z potrzebami przy użyciu zdarzeń usługi Azure DevOps lub akcji usługi GitHub.

Automatyczna konfiguracja łączników usługi Microsoft Sentinel

Łączniki usługi Microsoft Sentinel są istotną częścią rozwiązania, które obsługuje nawiązywanie połączenia z różnymi elementami w krajobrazie architektury przedsiębiorstwa, takimi jak Microsoft Entra ID, Microsoft 365, Microsoft Defender, rozwiązania platformy analizy zagrożeń itd.

Podczas definiowania środowiska można użyć konfiguracji łączników do skonfigurowania środowisk z homogeniczną konfiguracją.

Włączanie łączników w ramach modelu DevOps musi być obsługiwane przez model poziomu jednostki usługi. Ten fokus zapewnia odpowiedni poziom uprawnień, jak pokazano w poniższej tabeli.

scenariusz Połączenie or	Poziom modelu dostępu uprzywilejowanego	Najmniejsze uprawnienia platformy Azure	Wymaga zatwierdzenia przepływu pracy
Microsoft Entra ID	Poziom 0	administrator globalny lub administrator zabezpieczeń	Zalecane
Microsoft Entra ID — ochrona	Poziom 0	administrator globalny lub administrator zabezpieczeń	Zalecane
Microsoft Defender for Identity	Poziom 0	administrator globalny Administracja lub administrator zabezpieczeń	Zalecane
Usługa Microsoft Office 365	Poziom 0	administrator globalny lub administrator zabezpieczeń	Zalecane
Microsoft Cloud App Security	Poziom 0	administrator globalny lub administrator zabezpieczeń	Zalecane
Microsoft Defender XDR	Poziom 0	administrator globalny lub administrator zabezpieczeń	Zalecane
Usługa Microsoft Defender dla IOT	Poziom 2	Współautor	Zalecane
Microsoft Defender for Cloud	Poziom 2	Czytelnik zabezpieczeń	Opcjonalnie
Działanie platformy Azure	Poziom 2	Czytelnik subskrypcji	Opcjonalnie
Platformy analizy zagrożeń	Poziom 0	administrator globalny lub administrator zabezpieczeń	Zalecane
Zdarzenia zabezpieczeń	Level 4	Brak	Opcjonalnie
Dziennik systemu	Level 4	Brak	Opcjonalnie
DNS (wersja zapoznawcza)	Level 4	Brak	Opcjonalnie
Zapora systemu Windows	Level 4	Brak	Opcjonalnie
Zabezpieczenia Windows zdarzenia za pośrednictwem usługi AMA	Level 4	Brak	Opcjonalnie

Wdrażanie artefaktów usługi Microsoft Sentinel

W implementacji artefaktów usługi Microsoft Sentinel metodyka DevOps zyskuje większe znaczenie, ponieważ każda firma tworzy wiele artefaktów w celu zapobiegania atakom i korygowania ich.

Implementowanie artefaktów może być obowiązkiem jednego zespołu lub wielu zespołów. Automatyczne wdrażanie kompilacji i artefaktów jest często najczęściej wymaganym procesem i określa podejście i warunki dla agentów i modułów uruchamiających.

Wdrażanie artefaktów usługi Microsoft Sentinel i zarządzanie nimi wymaga użycia interfejsu API REST usługi Microsoft Sentinel. Aby uzyskać więcej informacji, zobacz Interfejs API REST usługi Microsoft Sentinel. Na poniższym diagramie przedstawiono potok usługi Azure DevOps w stosie interfejsu API REST platformy Azure.

Repozytorium można również zaimplementować przy użyciu programu PowerShell.

Jeśli twój zespół używa mitRE, rozważ sklasyfikowanie różnych artefaktów i określenie taktyki i technik dla każdego z nich. Upewnij się, że dołączysz odpowiedni plik metadanych dla każdego typu artefaktu.

Jeśli na przykład tworzysz nowy podręcznik przy użyciu szablonu usługi Azure ARM, a nazwa pliku to Playbook.arm.json, dodaj plik JSON o nazwie Playbook.arm.mitre.json. Metadane tego pliku zawierają następnie formaty CSV, JSON lub YAML, które odpowiadają taktyki lub technikom MITRE, których używasz.

Wykonując tę praktykę, zespół może ocenić pokrycie MITRE na podstawie zadań wykonywanych podczas konfigurowania dla różnych typów artefaktów, których używasz.

Tworzenie artefaktów

Celem procesu kompilacji jest upewnienie się, że generujesz artefakty o najwyższej jakości. Na poniższym diagramie przedstawiono niektóre akcje procesu kompilacji, które można wykonać.

Pobierz plik programu Visio z tą architekturą.

• Definicję artefaktu można oprzeć na schemacie opisowym w formacie JSON lub YAML, a następnie zweryfikować schemat, aby uniknąć błędów składni.
  • Zweryfikuj szablony usługi ARM przy użyciu zestawu narzędzi do testowania szablonu usługi ARM.
  • Zweryfikuj pliki YAML i JSON dla modeli niestandardowych przy użyciu programu PowerShell.
• Zweryfikuj ustawienia listy obserwowanych i upewnij się, że zdefiniowane rekordy routingu między domenami klasy (CIDR) są zgodne z poprawnym schematem, na przykład 10.1.0.0/16.
• Użyj zapytań języka zapytań słów kluczowych (KQL), które można zweryfikować na poziomie składni, dla reguł analitycznych, reguł wyszukiwania zagrożeń i reguł strumienia na żywo, które można zweryfikować na poziomie składni.
• Ustaw lokalną walidację KQL na jedną opcję.
• Zintegruj narzędzie weryfikacji wbudowanej języka KQL w potoku DevOps.
• Jeśli implementujesz logikę opartą na programie PowerShell dla usługi Azure Automation, możesz uwzględnić walidację składni i testowanie jednostkowe przy użyciu następujących elementów:
  • Pester
  • PSScriptAnalyzer
• Wygeneruj raport metadanych manifestu MITRE na podstawie plików metadanych dołączonych do artefaktów.

Eksportowanie artefaktów

Zazwyczaj wiele zespołów pracuje nad kilkoma wystąpieniami usługi Microsoft Sentinel, aby wygenerować niezbędne artefakty i je zweryfikować. W celu ponownego korzystania z istniejących artefaktów firma może skonfigurować automatyczne procesy pobierania definicji artefaktów z istniejących środowisk. Automatyzacja może również dostarczać informacje o artefaktach tworzonych przez różne zespoły programistyczne podczas instalacji.

Na poniższym diagramie przedstawiono przykładowy proces wyodrębniania artefaktów.

Pobierz plik programu Visio z tą architekturą.

Wdrażanie artefaktów

Cele procesu wdrażania to:

• Skrócenie czasu obrotu.
• Zwiększ wydajność wielu zespołów zaangażowanych w konfigurowanie rozwiązania i zarządzanie nim.
• Skonfiguruj testowanie integracji, aby ocenić kondycję środowiska.

Zespoły deweloperów używają tego procesu, aby upewnić się, że mogą wdrażać, testować i weryfikować przypadki użycia artefaktów, które są opracowywane. Zespoły ds. architektury i SOC weryfikują jakość potoku w środowiskach QA i pracują z testami integracji na potrzeby scenariuszy ataku. W przypadkach testowych zespół zwykle łączy różne artefakty jako reguły analityczne, podręczniki korygowania, listy do obejrzenia itd. Część każdego przypadku użycia obejmuje symulowanie ataków, w których cały łańcuch jest oceniany na podstawie pozyskiwania, wykrywania i korygowania.

Na poniższym diagramie przedstawiono sekwencję procesu wdrażania, która zapewnia wdrożenie artefaktów w odpowiedniej kolejności.

Pobierz plik programu Visio z tą architekturą.

Zarządzanie artefaktami usługi Sentinel jako kodem oferuje elastyczne sposoby obsługi operacji i automatyzowania wdrażania w potoku devOps ciągłej integracji/ciągłego wdrażania.

Rozwiązania firmy Microsoft zapewniają przepływy pracy automatyzacji dla następujących artefaktów.

Artefakt	Przepływy pracy automatyzacji
Listy do obejrzenia	Przegląd kodu Walidacja schematu Wdrożenie Tworzenie, aktualizowanie, usuwanie list obserwowanych i elementów
Łączenie reguł analizy Zabezpieczenia firmy Microsoft Analiza behawioralna uczenia maszynowego Anomalia Zaplanowane	Przegląd kodu Walidacja składni języka KQL Weryfikacja schematu Pester Wdrożenie Tworzenie, włączanie, aktualizowanie, usuwanie, eksportowanie Obsługa szablonów alertów
Reguły automatyzacji	Przegląd kodu Weryfikacja schematu Wdrożenie Tworzenie, włączanie, aktualizowanie, usuwanie, eksportowanie
Łączniki	Przegląd kodu Weryfikacja schematu Wdrożenie Akcje: włączanie, usuwanie (wyłączanie), aktualizacja
Reguły wyszukiwania zagrożeń	Przegląd kodu Walidacja składni języka KQL Weryfikacja schematu Pester Wdrożenie Akcje: tworzenie, włączanie, aktualizowanie, usuwanie, eksportowanie
Podręczniki	Przegląd kodu TTK Wdrożenie Akcje: tworzenie, włączanie, aktualizowanie, usuwanie, eksportowanie
Skoroszyty	Wdrożenie Akcje: tworzenie, aktualizowanie, usuwanie
Elementy Runbook	Przegląd kodu Walidacja składni programu PowerShell Pester Wdrożenie Akcje: tworzenie, włączanie, aktualizowanie, usuwanie, eksportowanie

W zależności od wybranego języka automatyzacji niektóre funkcje automatyzacji mogą nie być obsługiwane. Na poniższym diagramie przedstawiono, które funkcje automatyzacji są obsługiwane przez język.

* Funkcje programowania, które nie zostały jeszcze udokumentowane
** Metody automatyzacji obsługiwane przez interfejsy API programu Microsoft Operational Szczegółowe informacje lub Microsoft Szczegółowe informacje Resource Provider

Azure Automation

Na poniższym diagramie przedstawiono składniki upraszczania dostępu do usługi Microsoft Sentinel przy użyciu tożsamości usługi zarządzanej.

Pobierz plik programu Visio z tą architekturą.

Jeśli musisz udzielić dostępu do innych zasobów, użyj tożsamości zarządzanej, która zapewnia unikatową tożsamość dla wszystkich operacji krytycznych.

Konfigurowanie podręczników za pomocą usługi Azure Automation. Użyj skryptów programu PowerShell dla następujących złożonych zadań i funkcji automatyzacji:

• Integracja z rozwiązaniami innych firm, w których wymagane są różne poziomy poświadczeń i na podstawie identyfikatora Entra firmy Microsoft lub poświadczeń niestandardowych:
  • Poświadczenia użytkownika entra firmy Microsoft
  • Poświadczenia jednostki usługi Microsoft Entra
  • Uwierzytelnianie certyfikatu
  • Poświadczenia niestandardowe
  • Tożsamość zarządzana
• Implementowanie rozwiązania, które ponownie używa skryptów organizacyjnych lub rozwiązań, które wymagają użycia poleceń programu PowerShell, aby uniknąć złożonego tłumaczenia podręczników:
  • Rozwiązania oparte na programie PowerShell
  • Rozwiązania oparte na języku Python
• Implementowanie rozwiązań w scenariuszach hybrydowych, w których akcje korygowania mogą mieć wpływ na zasoby chmurowe i lokalne.

Repozytoria usługi Microsoft Sentinel

Doświadczeni zespoły DevOps mogą rozważyć zarządzanie usługą Microsoft Sentinel w infrastrukturze jako kodem (IaC) za pomocą potoków ciągłej integracji/ciągłego wdrażania, które są wbudowane w usłudze Azure DevOps. Grupy produktów rozumieją wyzwania, przed którymi stoją klienci i partnerzy w tworzeniu architektury zabezpieczeń usługi Azure DevOps, dzięki czemu następujące dwie inicjatywy mogą pomóc:

• Dokumentowanie architektury referencyjnej
• Opracowywanie nowego rozwiązania ogłoszonego na konferencji Ignite 2021 o nazwie "Repozytoria usługi Microsoft Sentinel"

Aby zapewnić obsługę wybierania rozwiązania, które odpowiada potrzebom twojego zespołu, poniższa tabela zawiera porównanie kryteriów funkcjonalnych i technicznych.

Przypadek użycia i funkcje	Niestandardowe podejście dotyczące usług Azure DevOps i GitHub	Repozytoria usługi Microsoft Sentinel
Chcemy szybko rozpocząć wdrażanie artefaktów usługi Microsoft Sentinel bez poświęcania czasu na definiowanie składników architektury usługi Azure DevOps, takich jak agenci, potoki, Git, pulpity nawigacyjne, witryna typu wiki, jednostki usługi, RBACs, inspekcja itd.	Niezalecane	Zalecane
Mamy małe zespoły i zestawy umiejętności do zarządzania potokami ciągłej integracji/ciągłego wdrażania.	Niezalecane	Zalecane
Chcemy kontrolować wszystkie aspekty zabezpieczeń potoków ciągłej integracji/ciągłego wdrażania i zarządzać nimi.	Obsługiwane	Nieobsługiwane
Musimy zintegrować bramy i rozgałęzianie w celu nadzorowania integracji, zanim deweloperzy będą mogli wyzwalać potoki wdrażania, takie jak kontrola źródła, przegląd kodu, wycofywanie, zatwierdzanie przepływu pracy itd.	Obsługiwane	Zaimportowano częściowo
Mamy dostosowaną strukturę git lub repozytorium.	Obsługiwane	Obsługiwane
Do tworzenia artefaktów nie używamy usługi Resource Manager ani języków Bicep IaC.	Obsługiwane	Nieobsługiwane
Chcemy centralnie zarządzać wdrażaniem artefaktów w wielu obszarach roboczych usługi Microsoft Sentinel w jednej dzierżawie firmy Microsoft Entra.	Obsługiwane	Obsługiwane
Chcemy zintegrować lub rozszerzyć potoki ciągłej integracji/ciągłego wdrażania w wielu dzierżawach firmy Microsoft Entra.	Obsługiwane	Obsługiwane
Mamy podręczniki z różnymi parametryzacji w zależności od subskrypcji, lokalizacji, środowiska itd.	Obsługiwane	TBD, wytyczne, które mają być udokumentowane
Chcemy zintegrować różne artefakty w tym samym repozytorium, aby tworzyć przypadki użycia.	Obsługiwane	Obsługiwane
Chcemy mieć możliwość zbiorczego usuwania artefaktów.	Obsługiwane	Nieobsługiwany

Dostępność, wydajność i skalowalność

Podczas wybierania architektury dla agentów usługi Azure DevOps w firmie dla scenariuszy usługi Microsoft Sentinel należy wziąć pod uwagę następujące potrzeby:

• Środowisko produkcyjne może wymagać dedykowanej puli agentów na potrzeby operacji w środowisku usługi Microsoft Sentinel.
• Środowiska nieprodukcyjne mogą współdzielić pulę agentów z dużą liczbą wystąpień do obsługi różnych wymagań zespołów, w szczególności w przypadku praktyk ciągłej integracji/ciągłego wdrażania.
  • Scenariusze symulacji ataków to szczególny przypadek, w którym mogą być wymagane dedykowane agenty. Zastanów się, czy dedykowana pula jest niezbędna do potrzeb testowych.
• Organizacje, które pracują w scenariuszach sieci hybrydowej, mogą rozważyć integrację agentów w sieci.

Organizacje mogą tworzyć własne obrazy dla agentów na podstawie kontenerów. Aby uzyskać więcej informacji, zobacz Uruchamianie własnego agenta na platformie Docker.

Zarządzanie między dzierżawami w usłudze Microsoft Sentinel za pomocą usługi Azure DevOps

Jako globalny SOC lub MSSP może być konieczne zarządzanie wieloma dzierżawami. Usługa Azure Lighthouse obsługuje operacje skalowane w kilku dzierżawach firmy Microsoft w tym samym czasie, dzięki czemu zadania zarządzania będą wydajniejsze. Aby uzyskać więcej informacji, zobacz Omówienie usługi Azure Lighthouse.

Zarządzanie między dzierżawami jest szczególnie skuteczne w następujących scenariuszach:

• Zarządzanie zasobami usługi Microsoft Sentinel w dzierżawach klientów.
• Śledzenie ataków i wyświetlanie alertów zabezpieczeń w wielu dzierżawach.
• Wyświetlanie zdarzeń w wielu obszarach roboczych usługi Microsoft Sentinel, które są rozmieszczone w różnych dzierżawach.

Metody dołączania klientów

Dostępne są dwie opcje dołączania klientów, oferty usługi zarządzanej i szablonu usługi ARM.

Ręczne dołączanie przy użyciu szablonu usługi ARM

Jeśli nie chcesz publikować oferty w witrynie Azure Marketplace jako dostawca usług lub nie spełniasz wszystkich wymagań, możesz dołączyć klientów ręcznie przy użyciu szablonów usługi ARM. Jest to najbardziej prawdopodobna opcja w scenariuszu przedsiębiorstwa, w którym to samo przedsiębiorstwo ma wiele dzierżaw.

W poniższej tabeli porównaliśmy metody dołączania.

Kwestie wymagające rozważenia	Oferta usługi zarządzanej	Szablony usługi ARM
Wymaga konta Centrum partnerskiego	Tak	Nie.
Wymaga poziomu kompetencji platformy Silver lub Gold w chmurze lub stanu dostawcy usług zarządzanych (MSP, Azure Expert Managed Services Provider)	Tak	Nie.
Dostępne dla nowych klientów za pośrednictwem witryny Azure Marketplace	Tak	Nie.
Może ograniczyć ofertę dla określonych klientów	Tak (tylko w przypadku ofert prywatnych, których nie można używać z subskrypcjami utworzonymi za pośrednictwem odsprzedawcy programu CSP)	Tak
Wymaga akceptacji klienta w witrynie Azure Portal	Tak	Nie.
Może używać automatyzacji do dołączania wielu subskrypcji, grup zasobów lub klientów	Nie.	Tak
Zapewnia natychmiastowy dostęp do nowych wbudowanych ról i funkcji usługi Azure Lighthouse	Nie zawsze (ogólnie dostępne po pewnym opóźnieniu)	Tak

Aby uzyskać więcej informacji na temat publikowania ofert usług zarządzanych, zobacz Publikowanie oferty usługi zarządzanej w witrynie Azure Marketplace.

Aby uzyskać więcej informacji na temat tworzenia szablonu usługi ARM, zobacz Tworzenie i wdrażanie szablonów usługi ARM.

Na poniższym diagramie przedstawiono integrację architektury wysokiego poziomu między dzierżawą msSP a dzierżawami dostawcy zasobów klienta z usługami Azure Lighthouse i Microsoft Sentinel.

Pobierz plik programu Visio z tą architekturą.

1. Oferta MSP jest zintegrowana za pośrednictwem szablonu usługi ARM lub oferty usługi Azure Marketplace.
2. Delegowane zarządzanie zasobami platformy Azure sprawdza, czy żądanie pochodzi z dzierżawy partnera i wywołuje dostawcę zasobów usługi zarządzanej.
3. Dostawca zasobów usługi zarządzanej używa kontroli dostępu opartej na rolach w celu kontrolowania dostępu msp.
4. Msp wykonuje akcje SecOps dla zasobu klienta.
5. Proces rozliczeń traktuje wydatki jako opłaty za klienta. Podział rozliczeń jest możliwy, jeśli jednostki klienta mają oddzielne obszary robocze w tej samej dzierżawie firmy Microsoft Entra.
6. Bezpieczeństwo i niezależność danych zależy od granicy dzierżawy klienta.

Tożsamość w wielu dzierżawach

Aby zarządzać usługą Microsoft Sentinel przy użyciu usługi Azure DevOps, oceń następujące decyzje projektowe dotyczące składników.

Przypadek użycia	Plusy
Globalna tożsamość do zarządzania akcjami DevOps, pojedynczą jednostką usługi	Ten przypadek dotyczy globalnych procesów wdrażania, które obejmują wszystkie dzierżawy. Użycie ujednoliconej tożsamości ułatwia dostęp do różnych dzierżaw, ale może sprawić, że proces zarządzania akcjami zatwierdzania dla określonych dzierżaw jest złożony. Mechanizm ochrony i model autoryzacji dla tego rodzaju tożsamości jest również bardzo ważny, aby uniknąć nieautoryzowanego użycia, które jest spowodowane powiązanym globalnym wpływem.
Dedykowana tożsamość do zarządzania akcjami DevOps, wieloma jednostkami usługi	Ten przypadek ma zastosowanie, gdy procesy wdrażania są dedykowane dla każdej dzierżawy lub akcji dzierżawy wymagają zatwierdzenia. W takim przypadku zalecenie dotyczące ochrony i autoryzowania tego użycia tożsamości jest takie samo jak w przypadku globalnym, nawet jeśli wpływ zostanie zmniejszony.

Organizacja repozytorium kodu

Przypadek użycia	Plusy
Ujednolicone repozytorium z pojedynczą wersją kodu dla wszystkich dzierżaw	Ten przypadek ułatwia posiadanie ujednoliconych wersji kodu w repozytorium. W takim przypadku ujednolicona wersja kodu zarządzającego określoną wersją dzierżawców może wymagać obsługi gałęzi dla każdego przypadku.
Ujednolicone repozytorium z określonymi folderami kodu według dzierżawy	Ten przypadek uzupełnia przypadek pojedynczego repozytorium. W tym miejscu struktura folderów może podzielić dedykowane artefakty według dzierżawy.
Dedykowane repozytorium według dzierżawy	Takie podejście zapewnia izolację podczas zarządzania artefaktami kodu. Ułatwia to ewolucję między dzierżawami z różnymi zespołami lub wymaganiami. Konsolidacja zmian wymaga ustanowienia procesu między repozytoriami, co może wymagać nakładu pracy w celu utrzymania.

Procesy kompilowania i wdrażania

Przypadek użycia	Plusy
Pojedynczy proces kompilacji dla wszystkich dzierżaw	Gdy wszyscy dzierżawcy pracują z tą samą wersją artefaktów, jest to najprostsza opcja implementacji generowania i pakietu.
Proces kompilacji według dzierżawy	W każdej dzierżawie jest wdrażana inna wersja kodu.
Globalny proces wdrażania dla wszystkich dzierżaw	Nowe wdrożenia i aktualizacje wdrożeń mają zastosowanie do wszystkich dzierżaw. Kroki procesów wdrażania i aktualizacji są używane dla wszystkich dzierżaw.
Dzierżawa globalnego procesu wdrażania według dzierżawy	Nowe wdrożenia i aktualizacje wdrożeń dotyczą co najmniej jednej dzierżawy.
Dedykowany proces wdrażania według dzierżawy	Proces wdrażania jest dostosowywany dla każdej dzierżawy.

Optymalizacja kosztów

Optymalizacja kosztów polega na zmniejszeniu niepotrzebnych wydatków i poprawie wydajności operacyjnej. Aby uzyskać więcej informacji, zobacz Omówienie filaru optymalizacji kosztów.

Koszt rozwiązania zależy od następujących czynników:

• Ilość danych przesyłanych przez firmę do obszaru roboczego usługi Log Analytics usługi Microsoft Sentinel co miesiąc
• Wybrana warstwa zobowiązania lub metoda rozliczeń, na przykład płatność zgodnie z rzeczywistym użyciem (PAYG)
• Wskaźnik przechowywania zasad danych na poziomie tabeli lub globalnej

Aby uzyskać więcej informacji, zobacz Przechowywanie typów danych platformy Azure.

Aby obliczyć ceny, zobacz kalkulator cen usługi Microsoft Sentinel. Aby uzyskać więcej informacji na temat zaawansowanych zagadnień dotyczących cen i przykładów, zobacz Planowanie kosztów usługi Microsoft Sentinel.

Jeśli rozszerzysz rozwiązanie przy użyciu następujących składników, możesz ponieść dodatkowe koszty:

• Podręczniki — środowiska uruchomieniowe dla usług Azure Logic Apps i Azure Functions. Aby uzyskać więcej informacji, zobacz Szczegóły cennika.
• Eksportowanie do magazynu zewnętrznego, takiego jak Azure Data Explorer, Event Hubs lub konto usługi Azure Storage.
• Obszar roboczy uczenia maszynowego i obliczenia używane przez składnik jupyter Notebook.

Wdrażanie tego scenariusza

W poniższej sekcji opisano kroki wdrażania tego scenariusza w postaci przykładowego przypadku użycia obejmującego różne procesy DevOps.

Kompilowanie i wydawanie struktury usługi Microsoft Sentinel

Najpierw skonfiguruj niezbędne składniki NuGet w dedykowanym repozytorium, w którym różne procesy mogą korzystać z generowanych wersji.

Jeśli pracujesz z usługą Azure DevOps, możesz utworzyć źródło danych składników do hostowania różnych pakietów NuGet z platformy Microsoft Sentinel dla programu PowerShell. Aby uzyskać więcej informacji, zobacz Wprowadzenie do pakietów NuGet.

Jeśli twój zespół wybierze rejestr GitHub, możesz połączyć go jako repozytorium NuGet, ponieważ jest on zgodny z protokołem kanału informacyjnego. Aby uzyskać więcej informacji, zobacz Wprowadzenie do pakietów GitHub.

Jeśli masz dostępne repozytorium NuGet, potok zawiera połączenie usługi dla narzędzia NuGet. Te zrzuty ekranu przedstawiają konfigurację nowego połączenia usługi o nazwie Microsoft Sentinel NuGet Framework Połączenie ion.

Po skonfigurowaniu kanału informacyjnego możesz zaimportować potok do kompilowania struktury programu PowerShell bezpośrednio z usługi GitHub w określonym rozwidleniu. Aby uzyskać więcej informacji, zobacz Tworzenie repozytoriów GitHub. W takim przypadku utworzysz nowy potok i wybierzesz usługę GitHub jako źródło kodu.

Inną opcją jest zaimportowanie repozytorium Git jako repozytorium Usługi Azure DevOps opartego na usłudze Git. W obu przypadkach, aby zaimportować potok, określ następującą ścieżkę:

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

Teraz możesz uruchomić potok po raz pierwszy. Następnie struktura kompiluje i publikuje je w kanale informacyjnym NuGet.

Definiowanie środowiska usługi Microsoft Sentinel

Zaczynając od usługi Microsoft Sentinel i korzystając z tych przykładów, zdefiniuj środowisko w firmie, na przykład Środowisko jako kod lub EaC. Należy określić różne elementy tworzące środowisko w każdym przypadku.

Architektura usługi Microsoft Sentinel obejmuje następujące elementy na platformie Azure:

• Obszar roboczy usługi Log Analytics — ten obszar roboczy stanowi podstawę rozwiązania. Informacje dotyczące zabezpieczeń są przechowywane tutaj, a obszar roboczy jest aparatem język zapytań Kusto (KQL).
• Rozwiązanie usługi Microsoft Sentinel w obszarze roboczym usługi Log Analytics — to rozwiązanie rozszerza funkcjonalność obszaru roboczego usługi Log Analytics w celu uwzględnienia funkcji SIEM i SOAR.
• Key Vault — magazyn kluczy przechowuje wpisy tajne i klucze używane podczas procesów korygowania.
• Konto usługi Automation — to konto jest opcjonalne i jest używane do procesów korygowania. Używany proces korygowania jest oparty na elementach Runbook programu PowerShell i języka Python. Proces obejmuje tożsamość zarządzaną przez system, która współpracuje z różnymi zasobami zgodnie z najlepszymi rozwiązaniami.
• Tożsamość zarządzana przez użytkownika — ta funkcja działa jako ujednolicona warstwa tożsamości usługi Microsoft Sentinel, która zarządza interakcjami między podręcznikami usługi Microsoft Sentinel i elementami Runbook.
• Połączenia aplikacji logiki — są to połączenia dla usługi Microsoft Sentinel, magazynu kluczy i automatyzacji, które używają tożsamości zarządzanej przez użytkownika.
• Połączenia aplikacji logiki zewnętrznej — są to połączenia dla zasobów zewnętrznych, które są zaangażowane w procesy korygowania i które są oparte na podręcznikach.
• Azure Event Hubs — ta funkcja jest opcjonalna i obsługuje integrację między usługą Microsoft Sentinel i innymi rozwiązaniami, takimi jak Splunk, Azure Databricks i uczenie maszynowe oraz Odporne.
• Konto magazynu — ta funkcja jest opcjonalna i obsługuje integrację między usługą Microsoft Sentinel i innymi rozwiązaniami, takimi jak Splunk, Azure Databricks i uczenie maszynowe oraz Odporne.

Korzystając z przykładów z repozytorium, można zdefiniować środowisko z plikami JSON w celu określenia różnych pojęć logicznych. Dostępne opcje do definiowania środowiska mogą być literałami lub automatycznymi.

W definicji literału należy określić nazwę i elementy dla każdego zasobu w środowisku, jak pokazano w tym przykładzie.

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

W definicji automatycznej nazwy elementów są generowane automatycznie na podstawie konwencji nazewnictwa, jak pokazano w tym przykładzie.

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

Przykłady można znaleźć w repozytorium GitHub w ścieżce środowisk usługi Microsoft Sentinel i użyć przykładów jako odwołania podczas przygotowywania przypadków użycia.

Wdrażanie środowiska usługi Microsoft Sentinel

Jeśli masz zdefiniowane co najmniej jedno środowisko, możesz utworzyć połączenie usługi platformy Azure w celu integracji z usługą Azure DevOps. Po utworzeniu połączenia z usługą ustaw połączoną jednostkę usługi na rolę właściciela lub podobny poziom uprawnień w ramach subskrypcji docelowej.

1. Zaimportuj potok do utworzenia nowego środowiska zgodnie z definicją w tym pliku.

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

2. Następnie wprowadź nazwę połączenia usługi reprezentującego środowisko.

   

3. Wybierz gałąź definicji środowiska w repozytorium. 

4. Wprowadź nazwę połączenia usługi Azure DevOps dla subskrypcji w polu Azure Environment Połączenie ion.

5. Wprowadź nazwę środowiska, którego połączenie usługi może użyć do rozpoznawania wielu środowisk w tej samej subskrypcji.

6. Wybierz akcję, która ma być stosowana do łączników.

7. Wybierz pozycję Użyj artefaktów wersji wstępnej programu PowerShell, jeśli chcesz użyć wersji wstępnej składników struktury programu PowerShell.

Potok obejmuje następujące kroki w ramach przepływu wdrażania:

• Wdrażanie składników NuGet.
• Połączenie przy użyciu narzędzi NuGet z repozytorium artefaktów.
• Rozwiąż kanał informacyjny.
• Zainstaluj wymagane moduły.
• Pobierz definicję środowiska.
• Sprawdź, które zasoby istnieją w miejscu docelowym.
• Dodaj usługi Log Analytics i Microsoft Sentinel, jeśli nie są w obszarze roboczym.
• Jeśli masz już usługę Log Analytics, dodaj usługę Microsoft Sentinel do swojego wystąpienia usługi Log Analytics.
• Utwórz tożsamość zarządzaną reprezentującą interakcję między usługą Microsoft Sentinel i usługą Logic Apps.
• Utwórz usługę Azure Key Vault i ustaw przypisanie roli do zarządzania wpisami tajnymi i kluczami do tożsamości zarządzanej.
• Jeśli ma to zastosowanie, utwórz konto usługi Azure Automation i włącz tożsamość zarządzaną przypisaną przez system.
• Ustaw przypisanie roli w magazynie kluczy dla tożsamości zarządzanej przypisanej przez system.
• Utwórz definicje usługi Event Hubs, jeśli nie istnieją i ustaw, czy definicja zawiera elementy integracji.
• Ustaw przypisanie roli w magazynie kluczy dla tożsamości zarządzanej przypisanej przez system.
• Utwórz definicje konta magazynu, jeśli nie istnieją i określ, czy definicja zawiera elementy integracji.
• Ustaw przypisanie roli w magazynie kluczy dla tożsamości zarządzanej przypisanej przez system.
• Wdrażanie akcji łącznika.
• Wdróż element Runbook integracji na koncie usługi Automation.
• Wdróż połączenia usługi Logic Apps, jeśli są zdefiniowane jako część środowiska.

Niszczenie środowiska usługi Microsoft Sentinel

Gdy środowisko nie jest już potrzebne, podobnie jak w przypadku środowiska programistycznego lub testowego, można go zniszczyć zgodnie z definicją w tym pliku.

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

Tak jak podczas wdrażania potoku środowiska należy określić nazwę połączenia usługi reprezentującego środowisko.

Praca ze środowiskiem usługi Microsoft Sentinel

Gdy środowisko będzie gotowe, możesz rozpocząć tworzenie artefaktów do konfigurowania różnych przypadków użycia.

1. Wyeksportuj artefakty ze środowiska, nad którym pracujesz zgodnie z definicją w tym pliku.

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

2. Wybierz gałąź definicji środowiska w repozytorium.

   

3. Wprowadź nazwę połączenia usługi Azure DevOps dla środowiska eksportowanego w polu Azure Environment Połączenie ion.

4. Wybierz pozycję Użyj artefaktów wersji wstępnej programu PowerShell, jeśli chcesz użyć wersji wstępnej składników struktury programu PowerShell.

5. Wybierz format reguł analizy i wyszukiwania zagrożeń.

   Plik wyjściowy artefaktów jest dostępny w wynikach. Po dokonaniu artefaktów możesz dołączyć plik wyjściowy do repozytorium Git.

Tworzenie artefaktów w środowisku usługi Microsoft Sentinel

Umieść artefakty w ścieżce przypadków użycia MITRE usługi Microsoft Sentinel. Skonfiguruj strukturę folderów zgodnie z różnymi typami artefaktów.

1. Uruchom proces kompilacji zgodnie z definicją w tym pliku.

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

2. Wybierz gałąź definicji środowiska w repozytorium.

   Diagram przedstawiający sposób wybierania gałęzi do tworzenia artefaktów. (./media/build-artifacts-pipeline.png)

3. Wybierz pozycję Użyj artefaktów wersji wstępnej programu PowerShell, jeśli chcesz użyć wersji wstępnej składników struktury programu PowerShell.

Potok składa się z następujących kroków:

• Wdrażanie składników NuGet.
• Połączenie narzędzia NuGet do repozytorium artefaktów.
• Rozwiąż kanał informacyjny.
• Zainstaluj wymagane moduły.
• Uzyskaj strukturę zestawu narzędzi do testowania na potrzeby sprawdzania poprawności szablonów usługi ARM.
• Zweryfikuj szablony usługi ARM.
• Zweryfikuj kod elementów Runbook programu PowerShell i przeprowadź walidację składni.
• W razie potrzeby uruchom testy jednostkowe Pester.
• Zweryfikuj składnię języka KQL w regułach wyszukiwania zagrożeń i analizy.

Wdrażanie artefaktów w środowisku usługi Microsoft Sentinel

Podczas wdrażania artefaktów można użyć repozytoriów usługi Microsoft Sentinel lub przykładów potoku wdrażania w tym repozytorium. Aby uzyskać więcej informacji, zobacz Wdrażanie zawartości niestandardowej z repozytorium.

Repozytoria usługi Microsoft Sentinel

Jeśli używasz repozytoriów usługi Microsoft Sentinel, możesz skonfigurować proces wydania, aby uwzględnić artefakty w repozytorium połączonym z każdym wystąpieniem usługi Microsoft Sentinel. Po zatwierdzeniu artefaktów w repozytorium niektóre kroki są wykonywane automatycznie w ramach tworzenia potoku i włączania repozytoriów usługi Microsoft Sentinel.

Ponadto można dostosować procesy wdrażania, które repozytoria usługi Microsoft Sentinel wykonują na podstawie praktyk opisanych w tym dokumencie. Ważnym aspektem, który należy wziąć pod uwagę, jest zatwierdzenie wydania, które można skonfigurować, wykonując następujące podejścia:

• Zatwierdzanie żądania ściągnięcia podczas zatwierdzania artefaktów. Aby uzyskać więcej informacji, zobacz Tworzenie żądań ściągnięcia.
• Zatwierdzanie potoku wydania podczas uruchamiania wdrożenia. Aby uzyskać więcej informacji, zobacz Definiowanie zatwierdzeń i kontroli.

Przykłady potoku wdrażania usługi Microsoft Sentinel

Korzystając z przykładów potoku wdrażania usługi Microsoft Sentinel, można skonfigurować proces wydawania.

1. Skonfiguruj proces wydania zgodnie z definicją w tym pliku.

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

2. Wybierz gałąź definicji środowiska w repozytorium.

   

3. Wprowadź nazwę połączenia usługi Azure DevOps dla środowiska eksportowanego w polu Azure Environment Połączenie ion.

4. Wybierz pozycję Użyj artefaktów wersji wstępnej programu PowerShell, jeśli chcesz użyć wersji wstępnej składników struktury programu PowerShell.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Główny autor:

• Kevin Kisoka | Kojarzenie architekta

Aby wyświetlić niepubalne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki

• Aby dowiedzieć się więcej o usłudze Microsoft Sentinel z usługą DevOps dla architektury z jedną dzierżawą, zobacz Wdrażanie usługi Microsoft Sentinel i zarządzanie nią jako kod.
• Aby dowiedzieć się więcej o architekturze wielodostępnej programu MSSP, zobacz Łączenie usługi Azure Lighthouse z funkcjami devOps usługi Microsoft Sentinel.
• Aby uzyskać informacje na temat tożsamości zarządzanej za pomocą usługi Microsoft Sentinel, zobacz Co nowego: tożsamość zarządzana dla łącznika usługi Logic Apps usługi Microsoft Sentinel.
• Aby dowiedzieć się, jak wdrożyć zawartość z repozytorium usługi Microsoft Sentinel, zobacz Wdrażanie niestandardowej zawartości z repozytorium.
• Aby dowiedzieć się więcej na temat zagadnień dotyczących zabezpieczeń usługi Azure DevOps, zobacz Krótkie informacje o uprawnieniach domyślnych.
• Aby dowiedzieć się, jak chronić repozytorium Usługi Azure DevOps, zobacz Dodawanie ochrony do zasobu repozytorium.
• Aby uzyskać informacje na temat zarządzania zabezpieczeniami połączeń usługi Azure DevOps, zobacz Połączenia usług w usłudze Azure Pipelines.

Powiązane zasoby

• Monitorowanie zabezpieczeń hybrydowych przy użyciu usługi Microsoft Defender dla chmury i usługi Microsoft Sentinel
• Projektowanie potoku ciągłej integracji/ciągłego wdrażania przy użyciu usługi Azure DevOps
• Zaawansowane funkcje szablonu usługi ARM