Automatizzare l'integrazione di Sentinel con Azure DevOps

Questo articolo descrive come automatizzare le operazioni di integrazione e distribuzione di Microsoft Sentinel con Azure DevOps. È possibile implementare Azure DevOps usando le funzionalità di Microsoft Sentinel per proteggere la distribuzione. Si usa quindi un framework DevSecOps per gestire e distribuire gli artefatti di Microsoft Sentinel su larga scala.

Architettura

Il diagramma seguente illustra una configurazione di Azure DevOps e IaC di Microsoft Sentinel.

Scaricare un file di Visio di questa architettura.

Flusso di dati

1. Il master scrum e la gestione dei prodotti usano Azure DevOps per definire epiche, storie utente ed elementi di backlog del prodotto come parte del backlog del progetto.
   • Il master scrum e la gestione dei prodotti usano Azure Boards per creare il backlog, pianificare il lavoro negli sprint, esaminare la bacheca del progetto, creare la struttura del repository e impostare regole di sicurezza come flussi di lavoro di approvazione e rami.
   • Il repository Git di Azure archivia gli script e consente di gestire gli artefatti di Microsoft Sentinel nell'infrastruttura come codice.
   • Gli artefatti e il controllo del codice sorgente mantengono le estensioni e aggiornano pacchetti o componenti del flusso di lavoro DevSecOps usati nella soluzione, ad esempio Azure Resource Manager Template Toolkit e PowerShell Pester.
2. Artefatti di Microsoft Sentinel:
   • Criteri (Policies). I tecnici SIEM usano i criteri di Azure nell'architettura di riferimento per configurare e ridimensionare le impostazioni di diagnostica dei servizi di Azure. I criteri consentono di automatizzare la distribuzione dei connettori dati di Microsoft Sentinel, ad esempio Azure Key Vault. I criteri dipendono dall'API OMSIntegration.
   • Connettori. Microsoft Sentinel usa connettori logici, i connettori dati di Azure, per inserire i dati di sicurezza, come nei controlli o nelle metriche, da origini dati supportate, ad esempio MICROSOFT Entra ID, risorse di Azure, Microsoft Defender o soluzioni di terze parti. L'elenco principale dei connettori dati è gestito dall'API SecurityInsights. Altri si basano sull'API OMSIntegration e vengono gestiti con le impostazioni di diagnostica Criteri di Azure.
   • Identità gestita. Microsoft Sentinel usa l'identità gestita per agire per conto dell'identità del servizio gestita durante l'interazione con playbook, app per la logica o runbook di automazione e l'insieme di credenziali delle chiavi.
   • Automazione. I team SOC usano l'automazione durante le indagini. I team SOC eseguono procedure di acquisizione dei dati forensi digitali con Automazione di Azure, ad esempio la catena di macchine virtuali di Azure di custodia o eDiscovery (Premium) per Microsoft Defender.
   • Analisi. Gli analisti soC o i cacciatori di minacce usano regole di analisi predefinite o personalizzate per analizzare e correlare i dati in Microsoft Sentinel o attivare playbook se vengono identificate minacce ed eventi imprevisti.
   • Playbook. Le app per la logica eseguono le azioni ripetibili SecOps, ad esempio l'assegnazione di un evento imprevisto, l'aggiornamento di un evento imprevisto o l'esecuzione di azioni correttive, ad esempio l'isolamento o l'inserimento di una macchina virtuale, la revoca di un token o la reimpostazione di una password utente.
   • Ricerca delle minacce. I cacciatori di minacce usano funzionalità di ricerca proattiva delle minacce che possono essere associate ai notebook di Jupyter per casi d'uso avanzati, ad esempio l'elaborazione dei dati, la manipolazione dei dati, la visualizzazione dei dati, l'apprendimento automatico o l'apprendimento avanzato.
   • Workbooks. I tecnici SIEM usano i dashboard delle cartelle di lavoro per visualizzare tendenze e statistiche e per visualizzare lo stato di un'istanza di Microsoft Sentinel e dei relativi sottocomponenti.
   • Threat intelligence. Un connettore dati specifico che combina le piattaforme di intelligence per le minacce si inserisce in Microsoft Sentinel. Sono supportati due metodi di connettività: TAXII e API Graph. Entrambi i metodi fungono da tiIndicator, o indicatori di intelligence per le minacce, nelle API di sicurezza.
3. Microsoft Entra ID. Le funzionalità di gestione delle identità e degli accessi vengono distribuite ai componenti usati nell'architettura di riferimento, ad esempio identità gestite, entità servizio, controlli degli accessi in base al ruolo di Azure per Microsoft Sentinel, app per la logica e runbook di automazione.
4. Azure Pipelines. I tecnici DevOps usano pipeline per creare connessioni al servizio per gestire le diverse sottoscrizioni di Azure, ad esempio gli ambienti sandbox e di produzione con pipeline di integrazione continua e recapito continuo (CI/CD). È consigliabile usare flussi di lavoro di approvazione per evitare distribuzioni impreviste e entità servizio separate se si usano più sottoscrizioni per ogni ambiente di Azure.
5. Azure Key Vault. I tecnici SOC usano l'insieme di credenziali delle chiavi per archiviare in modo sicuro i segreti e i certificati dell'entità servizio. Questo componente dell'architettura consente di applicare il principio DevSecOps di nessun segreto nel codice quando viene usato dalle connessioni al servizio Azure Pipeline.
6. Sottoscrizione di Azure. I team SOC usano due istanze di Microsoft Sentinel in questa architettura di riferimento, separate all'interno di due sottoscrizioni logiche di Azure per simulare ambienti di produzione e sandbox. È possibile ridimensionare le esigenze con altri ambienti, ad esempio test, sviluppo, preproduzione e così via.

Esempio di flusso di dati

1. Un amministratore aggiunge, aggiorna o elimina una voce nel fork del file di configurazione di Microsoft 365.
2. L'amministratore esegue il commit e sincronizza le modifiche nel repository con fork.
3. L'amministratore crea quindi una richiesta pull per unire le modifiche al repository principale.
4. La pipeline di compilazione viene eseguita nella richiesta pull.

Componenti

• Microsoft Entra ID è un servizio basato sul cloud per gestire le identità e i controlli di accesso.
• Azure DevOps è un servizio cloud per collaborare al codice, compilare e distribuire app o pianificare e tenere traccia del lavoro.
• Azure Key Vault è un servizio cloud per archiviare i segreti e accedervi in modo sicuro. Un segreto è qualsiasi elemento per cui si vuole controllare rigorosamente l'accesso, ad esempio chiavi API, password, certificati o chiavi crittografiche.
• Criteri di Azure è un servizio per creare, assegnare e gestire definizioni di criteri nell'ambiente Azure.
• Microsoft Sentinel è una soluzione SOAR (Scalabile, nativa del cloud, SIEM e orchestrazione della sicurezza, automazione e risposta).
• Automazione di Azure è un servizio per semplificare la gestione del cloud tramite l'automazione dei processi. Usare Automazione di Azure per automatizzare attività a esecuzione prolungata, manuali, soggette a errori e ripetute di frequente. L'automazione consente di migliorare l'affidabilità, l'efficienza e il tempo di valore per l'azienda.

Dettagli dello scenario

I team del Centro operazioni di sicurezza (SOC) a volte riscontrano problemi quando integrano Microsoft Sentinel con Azure DevOps. Il processo prevede molti passaggi e la configurazione può richiedere giorni e comportare ripetizioni. È possibile automatizzare questa parte dello sviluppo.

Per modernizzare il cloud, i tecnici devono apprendere costantemente nuove competenze e tecniche per proteggere e proteggere gli asset aziendali vitali. I tecnici devono creare soluzioni affidabili e scalabili che tengano il passo con il mutevole panorama della sicurezza e con le esigenze aziendali. Una soluzione di sicurezza deve essere flessibile, agile e attentamente pianificata dalle prime fasi di sviluppo. Questa metodologia di pianificazione anticipata è nota come shift-left.

Questo articolo descrive come automatizzare le operazioni di integrazione e distribuzione di Microsoft Sentinel con Azure DevOps. È possibile espandere la soluzione per organizzazioni complesse con più entità, sottoscrizioni e vari modelli operativi. Alcuni dei modelli operativi supportati da questa soluzione includono SOC locale, SOC globale, cloud service provider (CSP) e provider di servizi di sicurezza gestiti (MSSP).

Questo articolo è destinato ai destinatari seguenti:

• Specialisti SOC, come analisti e cacciatori di minacce
• Tecnici siem (Security Information and Event Management)
• Architetti della cybersecurity
• Sviluppatori

Potenziali casi d'uso

Di seguito sono riportati i casi d'uso tipici per questa architettura:

• Prototipazione rapida e modello di verifica. Questa soluzione è ideale per le organizzazioni di sicurezza e i team SOC che vogliono migliorare la copertura delle minacce cloud o modernizzare l'infrastruttura SIEM con infrastruttura distribuita come codice (IaC) e Microsoft Sentinel.
• Microsoft Sentinel come servizio. Questo framework di sviluppo integra i principi di gestione del ciclo di vita del servizio. Questi principi si adattano a team semplici o complessi, ad esempio MSSP che eseguono azioni ripetibili e standardizzate in più tenant dei clienti, combinando al tempo stesso la potenza di Azure DevOps e Azure Lighthouse. Ad esempio, un team che deve pubblicare casi d'uso di Microsoft Sentinel per un nuovo attore di minaccia o una campagna in corso potrebbe usare questa soluzione.
• Creazione di casi d'uso SOC per il rilevamento delle minacce. Molti gruppi e piattaforme di intelligence per le minacce si basano su contenuti MITRE Att&ck e tassonomia per analizzare il comportamento di sicurezza contro tecniche e tecniche avanzate e procedure tattiche. La soluzione definisce un approccio strutturato per lo sviluppo di procedure di progettazione del rilevamento delle minacce incorporando la terminologia MITRE Att&ck all'interno dello sviluppo di artefatti di Microsoft Sentinel.

La figura seguente illustra uno scenario cloud MITRE Att&ck.

Scaricare un file di Visio di questa architettura.

Scenari di attacco di definizione delle minacce basati su MITRE

Questa tabella illustra i termini, le definizioni e i dettagli degli aspetti importanti degli scenari di attacco.

Elemento di dati	Descrizione	Artefatti di Microsoft Sentinel
Title	Nome descrittivo per lo scenario di attacco, in base alle caratteristiche del vettore di attacco o alle descrizioni delle tecniche.	Manifesto MITRE
Tattiche di MITRE ATT&CK	Tattiche MITRE ATT&CK correlate allo scenario di attacco	Manifesto MITRE
Tecniche MITRE ATT&CK	Tecniche MITRE ATT&CK, inclusa la tecnica o l'ID sotto tecnica, correlati allo scenario di attacco.	Manifesto MITRE
Origini del connettore dati	Origine di informazioni raccolte da un sistema di registrazione o sensore che potrebbe essere usato per raccogliere informazioni rilevanti per identificare l'azione eseguita, la sequenza di azioni o i risultati di tali azioni da parte di un antagonista.	Connettore dati di Microsoft Sentinel o origine log personalizzata
Descrizione	Informazioni sulla tecnica, su ciò che è, su ciò che viene in genere usato, sul modo in cui un avversario può sfruttarlo e sulle variazioni su come potrebbe essere usato. Include riferimenti ad articoli autorevoli che descrivono le informazioni tecniche correlate alla tecnica e ai riferimenti all'uso selvaggio in base alle esigenze.
Rilevamento	Strategie di analisi, sensori, dati e rilevamento di alto livello utili per identificare una tecnica usata da un avversario. Questa sezione informa i responsabili del rilevamento del comportamento antagonista, ad esempio i difensori di rete, in modo da poter eseguire un'azione, ad esempio la scrittura di un sensore analitico o la distribuzione di un sensore. Dovrebbero esserci informazioni e riferimenti sufficienti per puntare a metodologie difensive utili. Il rilevamento potrebbe non essere sempre possibile per una determinata tecnica e deve essere documentato come tale.	Ricerca di minacce di analisi
Strategia di riduzione del rischio	Configurazioni, strumenti o processi che impediscono a una tecnica di funzionare o avere il risultato desiderato per un avversario. Questa sezione informa coloro che sono responsabili della mitigazione contro avversari, ad esempio difensori di rete o responsabili politici, per consentire loro di intraprendere un'azione come la modifica di un criterio o la distribuzione di uno strumento. La mitigazione potrebbe non essere sempre possibile per una determinata tecnica e deve essere documentata come tale.
Strategia di riduzione del rischio	Configurazioni, strumenti o processi che impediscono a una tecnica di funzionare o avere il risultato desiderato per un avversario. Questa sezione descrive come ridurre gli effetti degli attacchi antagonisti per i difensori di rete o i responsabili dei criteri. Vengono illustrati i passaggi per la modifica di un criterio o la distribuzione di uno strumento. La mitigazione potrebbe non essere sempre possibile per una determinata tecnica e deve essere documentata come tale.	Playbook, runbook di automazione

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Microsoft Azure Well-Architected Framework.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per altre informazioni, vedere Panoramica del pilastro della sicurezza.

Con la sicurezza, in termini generali, l'automazione aumenta l'efficienza delle operazioni risparmiando tempo per casi d'uso più complessi, ad esempio progettazione del rilevamento delle minacce, intelligence sulle minacce, SOC e casi d'uso SOAR. I team DevOps devono sapere dove possono usare IaC in modo sicuro nel contesto dell'integrazione continua/distribuzione continua di Microsoft Sentinel. Questo processo introduce l'uso di identità specifiche usate dagli account non umani in MICROSOFT Entra ID denominato entità servizio e identità gestite.

La tabella seguente riepiloga le considerazioni sulla sicurezza per le entità servizio e i principali casi d'uso trattati dalle pipeline di versione di Microsoft Sentinel e Azure DevOps.

Caso d'uso	Requisiti (privilegi minimi)	Durata dell'assegnazione di ruolo	Ambito di autorizzazione	Fiduciario	Considerazioni relative alla sicurezza
Abilitare i connettori di Microsoft Sentinel	Amministratore della sicurezza** Proprietario* Collaboratore di Microsoft Sentinel Lettore	JIT (attivazione una tantum) A scopo (ogni volta che viene distribuita una nuova sottoscrizione e un nuovo connettore)	Tenant	SPN	Usare l'insieme di credenziali delle chiavi per archiviare segreti e certificati del nome dell'entità servizio (SPN). Abilitare il controllo SPN. Esaminare periodicamente l'assegnazione di autorizzazioni (Azure Privileged Identity Management per SPN) o l'attività sospetta per SPN. Usare le autorità di certificazione Microsoft Entra e l'autenticazione a più fattori (se supportata) per gli account con privilegi. Usare i ruoli personalizzati di Microsoft Entra per una maggiore granularità.
Distribuire artefatti di Microsoft Sentinel, ad esempio cartelle di lavoro, analisi, regole, query di ricerca delle minacce, notebook e playbook	Collaboratore di Microsoft Sentinel Collaboratore di App per la logica	Permanente	Area di lavoro o gruppo di risorse di Microsoft Sentinel	SPN	Usare l'approvazione del flusso di lavoro di Azure DevOps (ADO) e verifica la sicurezza della distribuzione della pipeline con questo SPN.
Assegnare un criterio per configurare le funzionalità di streaming dei log a Microsoft Sentinel	Collaboratore criteri risorse **	A scopo (ogni volta che viene distribuita una nuova sottoscrizione e un nuovo connettore)	Tutte le sottoscrizioni da monitorare	SPN	Usare Microsoft Entra ID, CA e MFA, se supportato, per gli account con privilegi.

* Riguarda solo le impostazioni di diagnostica di Microsoft Entra.
** Per i connettori specifici sono necessarie autorizzazioni aggiuntive, ad esempio "amministratore della sicurezza" o "collaboratore ai criteri delle risorse" per consentire lo streaming dei dati nell'area di lavoro di Microsoft Sentinel, microsoft Entra ID, Microsoft 365 o Microsoft Defender e risorse PaaS (Platform as a Service) come Azure Key Vault.

Modello di accesso con privilegi

È consigliabile adottare una strategia di modello di accesso con privilegi per ridurre rapidamente i rischi per l'azienda da attacchi ad alto impatto e alta probabilità all'accesso con privilegi. Nel caso dei processi automatici in un modello DevOps, basare l'identità sulle identità dell'entità servizio.

L'accesso con privilegi deve essere la priorità di sicurezza principale di ogni azienda. Qualsiasi compromissione di queste identità crea effetti estremamente negativi. Le identità con privilegi hanno accesso agli asset critici per l'azienda, che causano quasi sempre un impatto significativo quando gli utenti malintenzionati comprometteno questi account.

La sicurezza dell'accesso con privilegi è fondamentale perché è fondamentale per tutte le altre garanzie di sicurezza. Un utente malintenzionato che controlla gli account con privilegi può compromettere tutte le altre garanzie di sicurezza.

Per questo motivo, è consigliabile distribuire logicamente le entità servizio in livelli o livelli diversi seguendo un principio di privilegio minimo. Nella figura seguente viene illustrato come classificare le entità servizio, a seconda del tipo di accesso e della posizione in cui è necessario l'accesso.

Entità servizio di livello 0

Le entità servizio di livello 0 hanno il livello massimo di autorizzazioni. Queste entità servizio autorizzano un utente a eseguire attività di amministrazione del gruppo di gestione a livello di tenant o radice come amministratore globale.

Per motivi di sicurezza e gestibilità, è consigliabile disporre di una sola entità servizio per questo livello. Le autorizzazioni per questa entità servizio vengono mantenute, pertanto è consigliabile concedere solo le autorizzazioni minime necessarie e mantenere monitorato e protetto l'account.

Archiviare il segreto o il certificato per questo account in modo sicuro in Azure Key Vault. È consigliabile individuare l'insieme di credenziali delle chiavi in una sottoscrizione amministrativa dedicata, se possibile.

Entità servizio di livello 1

Le entità servizio di livello 1 sono autorizzazioni elevate limitate e limitate ai gruppi di gestione a livello di organizzazione aziendale. Queste entità servizio autorizzano un utente a creare sottoscrizioni nel gruppo di gestione incluso nell'ambito.

Per motivi di sicurezza e gestibilità, è consigliabile disporre di una sola entità servizio per questo livello. Le autorizzazioni per questa entità servizio vengono mantenute, quindi è consigliabile concedere solo le autorizzazioni minime necessarie e mantenere monitorato e protetto l'account.

Archiviare il segreto o il certificato per questo account in modo sicuro in Azure Key Vault. È consigliabile individuare l'insieme di credenziali delle chiavi in una sottoscrizione amministrativa dedicata, se possibile.

Entità servizio di livello 2

Le entità servizio di livello 2 sono limitate al livello di sottoscrizione. Queste entità servizio autorizzano un utente a eseguire attività amministrative in una sottoscrizione, fungendo da proprietario della sottoscrizione.

Per motivi di sicurezza e gestibilità, è consigliabile disporre di una sola entità servizio per questo livello. Le autorizzazioni per questa entità servizio vengono mantenute, pertanto è consigliabile concedere solo le autorizzazioni minime necessarie e mantenere monitorato e protetto l'account.

Archiviare il segreto o il certificato per questo account in modo sicuro in Azure Key Vault. È consigliabile individuare l'insieme di credenziali delle chiavi in un gruppo di risorse amministrative dedicato.

Entità servizio di livello 3

Le entità servizio di livello 3 sono limitate all'amministratore del carico di lavoro. In uno scenario tipico, ogni carico di lavoro è contenuto nello stesso gruppo di risorse. Questa struttura limita le autorizzazioni dell'entità servizio solo a questo gruppo di risorse.

Per motivi di sicurezza e gestibilità, è consigliabile disporre di una sola entità servizio per ogni carico di lavoro. Le autorizzazioni per questa entità servizio vengono mantenute, pertanto è consigliabile concedere solo le autorizzazioni minime necessarie e mantenere monitorato e protetto l'account.

Archiviare il segreto o il certificato per questo account in modo sicuro in Azure Key Vault. È consigliabile individuare l'insieme di credenziali delle chiavi in un gruppo di risorse amministrative dedicato.

Entità servizio di livello 4

Le entità servizio di livello 4 hanno le autorizzazioni più limitate. Queste entità servizio autorizzano un utente a eseguire attività amministrative limitate a una sola risorsa.

È consigliabile usare le identità gestite, dove possibile. Nel caso di identità non gestite, archiviare il segreto o il certificato in modo sicuro in Azure Key Vault in cui vengono archiviati i segreti di livello 3.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e la mantengono in esecuzione nell'ambiente di produzione. Per altre informazioni, vedere Panoramica del pilastro dell'eccellenza operativa.

Le soluzioni di Microsoft Sentinel sono costituite da tre blocchi, che garantiscono operazioni complete e riuscite.

Il primo blocco è la definizione dell'ambiente, che costituisce gli elementi essenziali dell'architettura. Il problema principale di questo blocco consiste nel considerare il numero di ambienti di produzione e non di produzione da distribuire e quindi assicurarsi che la configurazione sia omogenea in tutti i casi.

Il secondo blocco è la distribuzione del connettore di Microsoft Sentinel, in cui si considera il tipo di connettori richiesti dal team e i requisiti di sicurezza per abilitarli.

Il terzo blocco è la gestione del ciclo di vita degli artefatti di Microsoft Sentinel, che illustra la codifica, la distribuzione e l'uso o la distruzione dei componenti. Ad esempio, questo blocco contiene le regole analitiche, i playbook, le cartelle di lavoro, la ricerca delle minacce e così via.

Considerare queste dipendenze tra gli artefatti:

• Regole di automazione definite in una regola di analisi
• Cartelle di lavoro o analisi che richiedono una nuova origine dati o un nuovo connettore
• Gestione degli aggiornamenti dei componenti esistenti
  • Come eseguire la versione degli artefatti
  • Come identificare, testare e distribuire una regola di analisi aggiornata o completamente nuova

Creare, testare e distribuire l'infrastruttura

Nella gestione delle soluzioni di Microsoft Sentinel e DevOps è importante considerare gli aspetti relativi alla connettività e alla sicurezza dell'architettura aziendale.

Azure DevOps può usare agenti ospitati da Microsoft o agenti self-hosted per attività di compilazione, test e distribuzione. A seconda dei requisiti aziendali, è possibile usare Microsoft ospitato, self-hosted o una combinazione di entrambi i modelli.

• Agenti ospitati da Microsoft. Questa opzione è il modo più rapido per lavorare con gli agenti Di Azure DevOps, perché è un'infrastruttura condivisa per l'intera organizzazione. Per altre informazioni sull'uso di agenti ospitati da Microsoft nella pipeline, vedere Agenti ospitati da Microsoft. Gli agenti ospitati da Microsoft possono funzionare in ambienti di rete ibrida, concedendo l'accesso agli intervalli IP. Per scaricare gli intervalli IP a cui questi agenti concedono l'accesso, vedere Intervalli IP e tag di servizio di Azure - Cloud pubblico.
• Agenti self-hosted. Questa opzione offre risorse dedicate e maggiore controllo durante l'installazione di software dipendente per le compilazioni e le distribuzioni. Gli agenti self-hosted possono usare macchine virtuali, set di scalabilità e contenitori in Azure. Per altre informazioni sugli agenti self-hosted, vedere Agenti di Azure Pipelines.

Strumenti di esecuzione di GitHub

GitHub può usare strumenti di esecuzione ospitati in GitHub o strumenti di esecuzione self-hosted per attività correlate alla compilazione, al test e alla distribuzione. A seconda delle esigenze dell'azienda, è possibile usare GitHub ospitato, self-hosted o una combinazione di entrambi i modelli.

Strumenti di esecuzione ospitati da GitHub

Questa opzione è il modo più rapido per lavorare con i flussi di lavoro di GitHub, poiché si tratta di un'infrastruttura condivisa per un'intera organizzazione. Per altre informazioni, vedere Informazioni sugli strumenti di esecuzione ospitati su GitHub. Gli agenti ospitati da GitHub funzionano in ambienti di rete ibrida, in base a determinati requisiti di rete. Per altre informazioni sui requisiti di rete, vedere Strumenti di esecuzione supportati e risorse hardware.

Strumenti di esecuzione self-hosted

Questa opzione offre all'azienda un'infrastruttura di risorse dedicata. Gli strumenti di esecuzione self-hosted funzionano su macchine virtuali e contenitori in Azure e supportano il ridimensionamento automatico.

Considerazioni sulla scelta degli strumenti di esecuzione

Quando si scelgono le opzioni per gli agenti e gli strumenti di esecuzione nella soluzione Microsoft Sentinel, considerare le esigenze seguenti:

• L'azienda necessita di risorse dedicate per l'esecuzione di processi in ambienti Di Microsoft Sentinel?
• Si vogliono isolare le risorse per le attività DevOps dell'ambiente di produzione dal resto degli ambienti?
• È necessario testare alcuni case che richiedono l'accesso a risorse o risorse critiche disponibili solo in una rete interna?

Orchestrazione e automazione dei processi di rilascio

È possibile configurare il processo di distribuzione con Azure DevOps o GitHub. Azure DevOps supporta l'uso di una pipeline YAML o di una pipeline di versione. Per altre informazioni sull'uso di una pipeline YAML in Azure DevOps, vedere Usare Azure Pipelines. Per altre informazioni sull'uso di una pipeline di versione in Azure DevOps, vedere Pipeline di versione. Per altre informazioni sull'uso di GitHub con GitHub Actions, vedere Informazioni su GitHub Actions.

Azure DevOps

È possibile eseguire le attività di distribuzione seguenti in una distribuzione di Azure DevOps.

• Usare una pipeline YAML per attivare automaticamente le approvazioni pull o eseguire su richiesta.
• Gestire le connessioni al servizio per ambienti diversi usando i gruppi di Azure DevOps.
• Negli ambienti critici configurare le approvazioni di distribuzione usando la funzionalità di connessione al servizio e i gruppi di Azure DevOps per assegnare autorizzazioni utente specifiche nel team.

GitHub

È possibile eseguire le attività di distribuzione seguenti in una distribuzione GitHub.

• Usare GitHub per creare richieste pull o attività di distribuzione.
• Gestire le credenziali dell'entità servizio usando i segreti di GitHub.
• Integrare l'approvazione della distribuzione tramite il flusso di lavoro associato a GitHub.

Distribuzione automatica con l'infrastruttura di Microsoft Sentinel

È possibile distribuire uno o più ambienti di Microsoft Sentinel, a seconda dell'architettura aziendale:

• Le organizzazioni che necessitano di più istanze nell'ambiente di produzione possono configurare sottoscrizioni diverse nello stesso tenant per ogni località geografica.
• Un'istanza centralizzata nell'ambiente di produzione fornisce l'accesso a una o più organizzazioni nello stesso tenant.
• I gruppi che necessitano di più ambienti, ad esempio produzione, preproduzione, integrazione e così via, possono crearli ed eliminarli in base alle esigenze.

Definizioni di ambiente fisico e logico

Sono disponibili due opzioni per configurare le definizioni di ambiente, fisiche o logiche. Entrambe hanno opzioni e vantaggi diversi:

• Definizione fisica: gli elementi dell'architettura di Microsoft Sentinel sono definiti con le opzioni seguenti per l'infrastruttura come codice (IaC):
  • Modelli Bicep
  • Modelli di Azure Resource Manager (modelli ARM)
  • Terraform
• Definizione logica: funge da livello di astrazione per configurare team diversi nel gruppo e definire i propri ambienti. La definizione viene impostata nella pipeline di distribuzione e nei flussi di lavoro come input per l'ambiente di compilazione usando il livello infrastruttura fisica.

Considerare questi punti quando si definiscono gli ambienti logici:

• Convenzioni di denominazione
• Identificazioni dell'ambiente
• Connettori e configurazioni

Repository di codice

Dato gli approcci all'ambiente illustrati nella sezione precedente, prendere in considerazione l'organizzazione del repository di codice GitHub seguente.

Definizione fisica: in base alle opzioni IaC, considerare un approccio che usa singole definizioni di modulo collegate nella definizione di distribuzione principale.

Nell'esempio seguente viene illustrato come organizzare il codice.

Limitare l'accesso a questo repository al team che definisce l'architettura a livello fisico, garantendo una definizione omogenea nell'architettura aziendale.

È possibile adattare la strategia di diramazione e unione alla strategia di distribuzione per ogni organizzazione. Se il team deve iniziare con la definizione, vedere Adottare una strategia di diramazione Git.

Per altre informazioni sui modelli di Resource Manager, vedere Uso di modelli collegati e annidati durante la distribuzione delle risorse di Azure.

Per altre informazioni sulla configurazione di ambienti Bicep, vedere Installare gli strumenti Bicep. Per altre informazioni su GitHub, vedere Flusso di GitHub.

Le definizioni logiche definiscono gli ambienti di un'azienda. Il repository Git raccoglie le diverse definizioni per un'azienda.

Nell'esempio seguente viene illustrato come organizzare il codice.

Il repository riflette le azioni pull eseguite da team diversi. Più ambienti sono definiti da team diversi e approvati dai proprietari o dai responsabili approvazione dell'azienda.

Il livello di privilegio per l'esecuzione di una distribuzione dell'ambiente è di livello 2. Questo livello garantisce che il gruppo di risorse e le risorse vengano create per l'ambiente con la sicurezza e la privacy necessarie. Questo livello imposta anche le autorizzazioni utente per le azioni consentite negli ambienti di produzione, produzione e preproduzione.

Le organizzazioni che vogliono ambienti su richiesta per test e sviluppo e la possibilità di eliminare definitivamente gli ambienti dopo aver completato i test, possono implementare una pipeline di Azure DevOps o gitHub actions. Possono impostare trigger pianificati per eliminare definitivamente gli ambienti in base alle esigenze usando gli eventi di Azure DevOps o GitHub actions.

Configurazione automatica dei connettori di Microsoft Sentinel

I connettori di Microsoft Sentinel sono una parte essenziale della soluzione che supporta la connessione con diversi elementi nel panorama dell'architettura aziendale, ad esempio Microsoft Entra ID, Microsoft 365, Microsoft Defender, soluzioni della piattaforma di intelligence sulle minacce e così via.

Quando si definisce un ambiente, è possibile usare la configurazione dei connettori per configurare ambienti con configurazioni omogenee.

L'abilitazione dei connettori come parte del modello DevOps deve essere supportata dal modello a livello di entità servizio. Questo stato attivo garantisce il livello corretto di autorizzazioni, come illustrato nella tabella seguente.

Scenario connettore	Livello del modello di accesso con privilegi	Privilegio minimo di Azure	Richiede l'approvazione del flusso di lavoro
Microsoft Entra ID	Livello 0	amministratore globale o amministratore della sicurezza	Consigliato
Microsoft Entra ID Protection	Livello 0	amministratore globale o amministratore della sicurezza	Consigliato
Microsoft Defender per identità	Livello 0	amministratore globale o amministratore della sicurezza	Consigliato
Microsoft Office 365	Livello 0	amministratore globale o amministratore della sicurezza	Consigliato
Microsoft Cloud App Security	Livello 0	amministratore globale o amministratore della sicurezza	Consigliato
Microsoft Defender XDR	Livello 0	amministratore globale o amministratore della sicurezza	Consigliato
Microsoft Defender per IOT	Livello 2	Collaboratore	Consigliato
Microsoft Defender for Cloud	Livello 2	Ruolo con autorizzazioni di lettura per la sicurezza	Facoltativo
Attività di Azure	Livello 2	Lettore di sottoscrizioni	Facoltativo
Piattaforme di intelligence sulle minacce	Livello 0	amministratore globale o amministratore della sicurezza	Consigliato
Eventi di sicurezza	Livello 4	None	Facoltativo
Syslog	Livello 4	None	Facoltativo
DNS (anteprima)	Livello 4	None	Facoltativo
Windows Firewall	Livello 4	None	Facoltativo
Eventi di Sicurezza di Windows tramite AMA	Livello 4	None	Facoltativo

Distribuzione degli artefatti di Microsoft Sentinel

Nell'implementazione degli artefatti di Microsoft Sentinel, DevOps ottiene maggiore rilevanza, perché ogni azienda crea più artefatti per prevenire e correggere gli attacchi.

L'implementazione degli artefatti può essere responsabilità di un team o di più team. La distribuzione automatica di compilazioni ed artefatti è spesso il requisito di processo più comune e determina l'approccio e le condizioni per gli agenti e gli strumenti di esecuzione.

La distribuzione e la gestione degli artefatti di Microsoft Sentinel richiede l'uso dell'API REST di Microsoft Sentinel. Per altre informazioni, vedere API REST di Microsoft Sentinel. Il diagramma seguente illustra una pipeline di Azure DevOps in uno stack di API REST di Azure.

È anche possibile implementare il repository usando PowerShell.

Se il team usa MITRE, valutare la possibilità di classificare i diversi artefatti e specificare le tattiche e le tecniche per ognuno di essi. Assicurarsi di includere un file di metadati corrispondente per ogni tipo di artefatto.

Ad esempio, se si sta creando un nuovo playbook usando un modello di Azure Resource Manager e il nome file è Playbook.arm.json, si aggiunge un file JSON denominato Playbook.arm.mitre.json. I metadati per questo file includono quindi i formati CSV, JSON o YAML che corrispondono alle tattiche o alle tecniche MITRE in uso.

Seguendo questa procedura, il team può valutare la copertura MITRE in base ai processi eseguiti durante la configurazione per i diversi tipi di artefatti usati.

Artefatti della compilazione

L'obiettivo del processo di compilazione è garantire la generazione degli artefatti di qualità più elevata. Il diagramma seguente illustra alcune delle azioni del processo di compilazione che è possibile eseguire.

Scaricare un file di Visio di questa architettura.

• È possibile basare la definizione dell'artefatto su uno schema descrittivo in formato JSON o YAML e quindi convalidare lo schema per evitare errori di sintassi.
  • Convalidare i modelli di Resource Manager usando il toolkit di test dei modelli di Resource Manager.
  • Convalidare i file YAML e JSON per i modelli personalizzati usando PowerShell.
• Convalidare le impostazioni dell'elenco di controllo e assicurarsi che i record CIDR (Classless Inter-Domain Routing) definiti seguono lo schema corretto, ad esempio 10.1.0.0/16.
• Usare query KQL (Keyword Query Language), che è possibile convalidare a livello di sintassi, per regole di analisi, regole di ricerca e regole di flusso live, che è possibile convalidare a livello di sintassi.
• Rendere la convalida locale KQL un'opzione.
• Integrare lo strumento di convalida inline KQL nella pipeline DevOps.
• Se si implementa la logica basata su PowerShell per Automazione di Azure, è possibile includere la convalida della sintassi e gli unit test usando gli elementi seguenti:
  • Pester
  • PSScriptAnalyzer
• Generare il report dei metadati del manifesto MITRE in base ai file di metadati inclusi negli artefatti.

Esportare gli elementi

In genere, più team lavorano su diverse istanze di Microsoft Sentinel per generare gli artefatti necessari e convalidarli. Con l'obiettivo di riutilizzare gli artefatti esistenti, l'azienda può configurare processi automatici per ottenere le definizioni degli artefatti dagli ambienti esistenti. L'automazione può anche fornire informazioni su tutti gli artefatti creati da team di sviluppo diversi durante l'installazione.

Il diagramma seguente mostra un processo di estrazione degli artefatti di esempio.

Scaricare un file di Visio di questa architettura.

Distribuire artefatti

Gli obiettivi del processo di distribuzione sono:

• Ridurre il time-to-market.
• Aumentare le prestazioni tra più team coinvolti nella configurazione e nella gestione della soluzione.
• Configurare i test di integrazione per valutare l'integrità dell'ambiente.

I team di sviluppo usano il processo per assicurarsi che possano distribuire, testare e convalidare i casi d'uso degli artefatti in fase di sviluppo. L'architettura e i team SOC convalidano la qualità della pipeline negli ambienti di controllo di qualità e collaborano con i test di integrazione per gli scenari di attacco. Nei test case, un team combina in genere elementi diversi come regole analitiche, playbook di correzione, watchlist e così via. Una parte di ogni caso d'uso include la simulazione di attacchi in cui l'intera catena viene valutata dall'inserimento, dal rilevamento e dalla correzione.

Il diagramma seguente mostra la sequenza del processo di distribuzione che garantisce che gli artefatti vengano distribuiti nell'ordine corretto.

Scaricare un file di Visio di questa architettura.

La gestione degli artefatti di Sentinel come codice offre modi flessibili per gestire le operazioni e automatizzare la distribuzione in una pipeline DevOps CI/CD.

Le soluzioni Microsoft forniscono flussi di lavoro di automazione per gli artefatti seguenti.

Artefatto	Flussi di lavoro di automazione
Watchlist	Revisione del codice Convalida dello schema Distribuzione Creare, aggiornare, eliminare watchlist ed elementi
Fusione delle regole di analisi Microsoft Security Analisi comportamentale di Machine Learning Anomalia Pianificati	Revisione del codice Convalida della sintassi KQL Convalida dello schema Pester Distribuzione Creare, abilitare, aggiornare, eliminare, esportare Supporto dei modelli di avviso
Regole di automazione	Revisione del codice Convalida dello schema Distribuzione Creare, abilitare, aggiornare, eliminare, esportare
Connettori	Revisione del codice Convalida dello schema Distribuzione Azioni: abilitare, eliminare (disabilitare), aggiornare
Regole di ricerca	Revisione del codice Convalida della sintassi KQL Convalida dello schema Pester Distribuzione Azioni: creare, abilitare, aggiornare, eliminare, esportare
Playbook	Revisione del codice TTK Distribuzione Azioni: creare, abilitare, aggiornare, eliminare, esportare
Cartelle di lavoro	Distribuzione Azioni: creare, aggiornare, eliminare
Runbook	Revisione del codice Convalida della sintassi di PowerShell Pester Distribuzione Azioni: creare, abilitare, aggiornare, eliminare, esportare

A seconda del linguaggio di automazione scelto, alcune funzionalità di automazione potrebbero non essere supportate. Il diagramma seguente illustra le funzionalità di automazione supportate dal linguaggio.

* Funzionalità in fase di sviluppo non ancora documentate
** Metodi di automazione supportati da Microsoft Operational Insights o dalle API del provider di risorse di Microsoft Insights

Automazione di Azure

Il diagramma seguente illustra i componenti per semplificare l'accesso a Microsoft Sentinel con l'identità del servizio gestito.

Scaricare un file di Visio di questa architettura.

Se è necessario concedere l'accesso ad altre risorse, usare l'identità gestita, che garantisce un'identità univoca per tutte le operazioni critiche.

Usare Automazione di Azure per configurare i playbook. Usare gli script di PowerShell per le attività e le funzionalità di automazione complesse seguenti:

• Integrazione con soluzioni di terze parti, in cui sono necessari diversi livelli di credenziali e in base all'ID Microsoft Entra o alle credenziali personalizzate:
  • Credenziali utente di Microsoft Entra
  • Credenziali dell'entità servizio Microsoft Entra
  • Autenticazione del certificato
  • Credenziali personalizzate
  • Identità gestita
• Implementazione di una soluzione che riutilizza gli script dell'organizzazione o soluzioni che richiedono l'uso di comandi di PowerShell per evitare una traduzione complessa nei playbook:
  • Soluzioni basate su PowerShell
  • Soluzioni basate su Python
• Implementazione di soluzioni in scenari ibridi, in cui le azioni di correzione possono influire sulle risorse cloud e locali.

Repository di Microsoft Sentinel

I team DevOps esperti potrebbero prendere in considerazione la gestione di Microsoft Sentinel nell'infrastruttura come codice (IaC) con pipeline CI/CD compilate in Azure DevOps. I gruppi di prodotti comprendono le sfide che i clienti e i partner devono affrontare nella creazione di un'architettura di sicurezza di Azure DevOps, in modo che le due iniziative seguenti possano essere utili:

• Documentazione dell'architettura di riferimento
• Sviluppo di una nuova soluzione, annunciata a Ignite 2021, denominata "Repository di Microsoft Sentinel"

Per supportare la scelta della soluzione più adatta alle esigenze del team, la tabella seguente confronta i criteri funzionali e tecnici.

Casi d'uso e funzionalità	Approccio personalizzato di Azure DevOps e GitHub	Repository di Microsoft Sentinel
Si vuole iniziare rapidamente a distribuire gli artefatti di Microsoft Sentinel senza dedicare tempo alla definizione dei componenti dell'architettura di Azure DevOps, ad esempio agenti, pipeline, Git, dashboard, wiki, entità servizio, RBAC, controllo e così via.	Non consigliata	Consigliato
Sono disponibili team di piccole dimensioni e set di competenze bassi per gestire le pipeline CI/CD.	Non consigliata	Consigliato
Si vuole controllare e gestire tutti gli aspetti di sicurezza delle pipeline CI/CD.	Supportato	Non supportato
È necessario integrare gate e diramazioni per l'integrazione della supervisione, prima di consentire agli sviluppatori di attivare pipeline di distribuzione, ad esempio il controllo del codice sorgente, la revisione del codice, il rollback, l'approvazione del flusso di lavoro e così via.	Supportato	Parzialmente supportato
È disponibile una struttura personalizzata di Git o repository.	Supportata	Supportata
I linguaggi IaC o Resource Manager non vengono usati per creare artefatti.	Supportato	Non supportato
Si vuole gestire centralmente la distribuzione degli artefatti in più aree di lavoro di Microsoft Sentinel in un singolo tenant di Microsoft Entra.	Supportata	Supportata
Si vuole integrare o estendere le pipeline CI/CD in più tenant di Microsoft Entra.	Supportata	Supportata
Sono disponibili playbook con parametrizzazione diversa a seconda della sottoscrizione, della posizione, dell'ambiente e così via.	Supportata	TBD, linee guida da documentare
Si vogliono integrare diversi artefatti nello stesso repository per comporre casi d'uso.	Supportata	Supportata
Si vuole che la possibilità di rimuovere in blocco gli artefatti.	Supportato	Non supportato

Disponibilità, prestazioni e scalabilità

Quando si sceglie l'architettura per gli agenti Di Azure DevOps nell'azienda per gli scenari di Microsoft Sentinel, prendere in considerazione le esigenze seguenti:

• L'ambiente di produzione potrebbe richiedere un pool di agenti dedicato per le operazioni nell'ambiente Di Microsoft Sentinel.
• Gli ambienti non di produzione possono condividere il pool di agenti con un numero elevato di istanze per gestire le diverse richieste dei team, in particolare per le procedure CI/CD.
  • Gli scenari di simulazione degli attacchi sono un caso speciale in cui è possibile richiedere agenti dedicati. Valutare se è necessario un pool dedicato per le esigenze di test.
• Le organizzazioni che lavorano in scenari di rete ibrida possono prendere in considerazione l'integrazione degli agenti all'interno della rete.

Le organizzazioni possono creare immagini personalizzate per gli agenti in base ai contenitori. Per altre informazioni, vedere Eseguire un agente self-hosted in Docker.

Gestione tra tenant di Microsoft Sentinel con Azure DevOps

Come SOC globale o MSSP, potrebbe essere necessario gestire più tenant. Azure Lighthouse supporta operazioni con scalabilità orizzontale in diversi tenant di Microsoft Entra contemporaneamente, rendendo le attività di gestione più efficienti. Per altre informazioni, vedere Panoramica di Azure Lighthouse.

La gestione tra tenant è particolarmente efficace negli scenari seguenti:

• Gestire le risorse di Microsoft Sentinel nei tenant dei clienti.
• Tenere traccia degli attacchi e visualizzare gli avvisi di sicurezza in più tenant.
• Visualizzare gli eventi imprevisti in più aree di lavoro di Microsoft Sentinel distribuite tra tenant.

Metodi per eseguire l'onboarding dei clienti

Sono disponibili due opzioni per eseguire l'onboarding dei clienti, un'offerta di servizio gestito e un modello di Resource Manager.

Onboarding manuale con un modello di Resource Manager

Se non si vuole pubblicare un'offerta in Azure Marketplace come provider di servizi o non si soddisfano tutti i requisiti, è possibile eseguire manualmente l'onboarding dei clienti usando i modelli di Resource Manager. Questa è l'opzione più probabile in uno scenario aziendale, in cui la stessa azienda ha più tenant.

Nella tabella seguente vengono confrontati i metodi di onboarding.

Considerazioni	Offerta di un servizio gestito	Modelli di Gestione risorse di Azure
Richiede un account del Centro per i partner	Sì	No
Richiede il livello di competenza della piattaforma cloud Silver o Gold o lo stato del provider msp (Expert Managed Services Provider)	Sì	No
Disponibile per i nuovi clienti tramite Azure Marketplace	Sì	No
Possibilità di limitare l'offerta a clienti specifici	Sì (solo con offerte private, che non possono essere usate con le sottoscrizioni stabilite tramite un rivenditore del programma CSP)	Sì
Richiede l'accettazione del cliente nel portale di Azure	Sì	No
Può usare l'automazione per eseguire l'onboarding di più sottoscrizioni, gruppi di risorse o clienti	No	Sì
Fornisce l'accesso immediato alle nuove funzionalità predefinite e di Azure Lighthouse	Non sempre (disponibile a livello generale dopo un certo ritardo)	Sì

Per altre informazioni sulla pubblicazione di offerte di servizi gestiti, vedere Pubblicare un'offerta di servizio gestito in Azure Marketplace.

Per altre informazioni su come creare un modello di Resource Manager, vedere Creare e distribuire modelli di Resource Manager.

Il diagramma seguente illustra l'integrazione dell'architettura di alto livello tra un tenant MSSP e i tenant del provider di risorse di un cliente con Azure Lighthouse e Microsoft Sentinel.

Scaricare un file di Visio di questa architettura.

1. Un'offerta MSP è integrata tramite un modello arm o un'offerta di servizio Azure Marketplace.
2. Gestione risorse delegate di Azure verifica che la richiesta provena da un tenant partner e chiami un provider di risorse del servizio gestito.
3. Il provider di risorse del servizio gestito usa il controllo degli accessi in base al ruolo per controllare l'accesso del provider di servizi gestiti.
4. L'MSP completa le azioni SecOps in una risorsa del cliente.
5. Il processo di fatturazione considera le spese come addebiti per i clienti. La suddivisione della fatturazione è possibile se le entità cliente hanno aree di lavoro separate nello stesso tenant di Microsoft Entra.
6. La sicurezza e la sovranità dei dati dipendono dal limite del tenant del cliente.

Identità tra più tenant

Per gestire Microsoft Sentinel con Azure DevOps, valutare le decisioni di progettazione seguenti per i componenti.

Caso d'uso	Vantaggi
Identità globale per la gestione delle azioni DevOps, singola entità servizio	Questo caso si applica ai processi di distribuzione globale, che coinvolgono tutti i tenant. L'uso di un'identità unificata facilita l'accesso per i diversi tenant, ma potrebbe rendere complesso il processo di gestione delle azioni di approvazione per tenant specifici. Anche il meccanismo di protezione e il modello di autorizzazione per questo tipo di identità sono molto importanti, per evitare l'utilizzo non autorizzato dovuto all'impatto globale correlato.
Identità dedicata per la gestione delle azioni DevOps, più entità servizio	Questo caso si applica quando i processi di distribuzione sono dedicati per ogni azione tenant o tenant richiedono l'approvazione. In questo caso, la raccomandazione per la protezione e l'autorizzazione di questo utilizzo dell'identità è identica a quella del caso globale, anche quando l'impatto è ridotto.

Organizzazione del repository di codice

Caso d'uso	Vantaggi
Repository unificato con una singola versione di codice per tutti i tenant	Questo caso facilita la creazione di versioni unificate per il codice nel repository. In questo caso, una versione unificata del codice che gestisce una versione specifica per i tenant potrebbe richiedere il supporto su rami per ogni caso.
Repository unificato con cartelle di codice specifiche per tenant	In questo caso viene completato il caso di repository singolo. In questo caso, una struttura di cartelle può suddividere gli artefatti dedicati per tenant.
Repository dedicato per tenant	Questo approccio fornisce l'isolamento durante la gestione degli artefatti del codice. Semplifica l'evoluzione tra tenant con team o requisiti diversi. Per consolidare le modifiche è necessario stabilire un processo tra i repository, che potrebbe richiedere sforzi per la manutenzione.

Processi di compilazione e distribuzione

Caso d'uso	Vantaggi
Processo di compilazione singolo per tutti i tenant	Quando tutti i tenant funzionano con la stessa versione degli artefatti, questa è l'opzione più semplice per implementare la generazione e il pacchetto.
Processo di compilazione per tenant	Una versione diversa del codice viene distribuita in ogni tenant.
Processo di distribuzione globale per tutti i tenant	Le nuove distribuzioni e gli aggiornamenti alle distribuzioni si applicano a tutti i tenant. I passaggi dei processi di distribuzione e aggiornamento vengono usati per tutti i tenant.
Tenant del processo di distribuzione globale per tenant	Le nuove distribuzioni e gli aggiornamenti delle distribuzioni si applicano a uno o più tenant.
Processo di distribuzione dedicato per tenant	Il processo di distribuzione viene adattato per ogni tenant.

Ottimizzazione dei costi

L'ottimizzazione dei costi riguarda la riduzione delle spese non necessarie e il miglioramento dell'efficienza operativa. Per altre informazioni, vedere Panoramica del pilastro di ottimizzazione dei costi.

Il costo della soluzione dipende dai fattori seguenti:

• Volume di dati che l'azienda inserisce nell'area di lavoro Log Analytics di Microsoft Sentinel mensile
• Il livello di impegno o il metodo di fatturazione scelto, ad esempio il pagamento in base al consumo (pagamento in base al consumo)
• Frequenza di conservazione dei criteri di dati a livello di tabella o globale

Per altre informazioni, vedere Conservazione dei tipi di dati di Azure.

Per calcolare i prezzi, vedere il calcolatore dei prezzi di Microsoft Sentinel. Per altre informazioni sulle considerazioni avanzate sui prezzi e sugli esempi, vedere Pianificare i costi per Microsoft Sentinel.

Se si estende la soluzione con i componenti seguenti, è possibile sostenere costi aggiuntivi:

• Playbook: runtime per App per la logica di Azure e Funzioni di Azure. Per altre informazioni, vedere Dettagli prezzi.
• Esportazione in una risorsa di archiviazione esterna come Azure Esplora dati, Hub eventi o un account Archiviazione di Azure.
• Un'area di lavoro di Machine Learning e il calcolo usato da un componente Jupyter Notebook.

Distribuire lo scenario

La sezione seguente descrive i passaggi per la distribuzione di questo scenario sotto forma di caso d'uso di esempio che illustra i vari processi DevOps.

Compilare e rilasciare il framework di Microsoft Sentinel

Prima di tutto, configurare i componenti NuGet necessari in un repository dedicato in cui i diversi processi possono usare le versioni generate.

Se si usa Azure DevOps, è possibile creare un feed di componenti per ospitare i diversi pacchetti NuGet dal framework di Microsoft Sentinel per PowerShell. Per altre informazioni, vedere Introduzione ai pacchetti NuGet.

Se il team sceglie un registro GitHub, è possibile connetterlo come repository NuGet, perché è compatibile con il protocollo di feed. Per altre informazioni, vedere Introduzione ai pacchetti GitHub.

Quando si dispone di un repository NuGet disponibile, la pipeline contiene una connessione al servizio per NuGet. Questi screenshot mostrano la configurazione per la nuova connessione al servizio denominata Connessione NuGet Framework di Microsoft Sentinel.

Dopo aver configurato il feed, è possibile importare la pipeline per la compilazione del framework di PowerShell direttamente da GitHub in un fork specifico. Per altre informazioni, vedere Creare repository GitHub. In questo caso, si crea una nuova pipeline e si sceglie GitHub come origine del codice.

Un'altra opzione consiste nell'importare il repository Git come repository Azure DevOps basato su Git. In entrambi i casi, per importare la pipeline, specificare il percorso seguente:

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

È ora possibile eseguire la pipeline per la prima volta. Il framework compila e rilascia quindi il feed NuGet.

Definire l'ambiente di Microsoft Sentinel

Quando si inizia con Microsoft Sentinel e si usano questi esempi, definire l'ambiente nell'azienda, ad esempio Environment as Code o EaC. Specificare i diversi elementi che costituiscono l'ambiente in ogni caso.

L'architettura di Microsoft Sentinel include gli elementi seguenti in Azure:

• Area di lavoro Log Analytics: questa area di lavoro costituisce la base della soluzione. Le informazioni relative alla sicurezza vengono archiviate qui e l'area di lavoro è il motore per Linguaggio di query Kusto (KQL).
• Soluzione Microsoft Sentinel nell'area di lavoro Log Analytics: questa soluzione estende le funzionalità dell'area di lavoro Log Analytics per includere funzionalità SIEM e SOAR.
• Key Vault: l'insieme di credenziali delle chiavi mantiene i segreti e le chiavi usati durante i processi di correzione.
• Account di Automazione: questo account è facoltativo e viene usato per i processi di correzione. Il processo di correzione usato si basa sui runbook PowerShell e Python. Il processo include un'identità gestita dal sistema che funziona con risorse diverse in base alle procedure consigliate.
• Identità gestita dall'utente: questa funzionalità funge da livello di identità unificato di Microsoft Sentinel che gestisce le interazioni tra playbook e runbook di Microsoft Sentinel.
• Connessioni all'app per la logica: si tratta di connessioni per Microsoft Sentinel, l'insieme di credenziali delle chiavi e l'automazione che usano l'identità gestita dall'utente.
• Connessioni di app per la logica esterna: si tratta di connessioni per le risorse esterne coinvolte nei processi di correzione e basate sui playbook.
• Hub eventi di Azure: questa funzionalità è facoltativa e gestisce l'integrazione tra Microsoft Sentinel e altre soluzioni, ad esempio Splunk, Azure Databricks e Machine Learning e Resilient.
• Account di archiviazione: questa funzionalità è facoltativa e gestisce l'integrazione tra Microsoft Sentinel e altre soluzioni, ad esempio Splunk, Azure Databricks e Machine Learning e Resilient.

Usando esempi del repository, è possibile definire l'ambiente con i file JSON per specificare i diversi concetti logici. Le opzioni disponibili per la definizione dell'ambiente possono essere letterali o automatiche.

In una definizione letterale si specificano il nome e gli elementi per ogni risorsa nell'ambiente, come illustrato in questo esempio.

{
    {
        "SubscriptionId": "<subscription-identifier-associated-with-service-connection>",
        "Name": "<environment-name>",
        "NamingConvention": "<naming-convention-template-for-automatic-cases>",
        "Location": "<environment-location>",
        "ResourceGroup": {
            "Type": "Literal",
            "ResourceGroupName": "<resource-group-name>"
         }
    },
    "Resources":
    {
        "Sentinel":
        {
            "Type": "Literal",
            "LogAnalyticsWorkspaceName": "<Log-Analytics-workspace-name>",
            "ManagedIdentityName": "<user-managed-identity-name>",
            "SentinelConnectionName": "<Sentinel-API-connection-name>",
            "KeyVaultName": "<Key-Vault-name>",
            "KeyVaultConnectionName": "<Key-Vault-API-connection-name>"
        },
        "Automation":
        {
            "Type": "Literal",
            "AutomationAccountName": "<automation-account-name>",
            "AutomationAccountConnectionName": "<automation-account-API-connection-name>"
        },
        "Integration":
        {
            "Type": "Literal",
            "EventHubNamespaces": [
                "<Event-Hubs-namespace-1-name>",
                "<Event-Hubs-namespace-2-name>",
                "<Event-Hubs-namespace-3-name>",
                "<Event-Hubs-namespace-4-name>",
                "<Event-Hubs-namespace-5-name>",
                "<Event-Hubs-namespace-6-name>",
                "<Event-Hubs-namespace-7-name>",
                "<Event-Hubs-namespace-8-name>",
                "<Event-Hubs-namespace-9-name>",
                "<Event-Hubs-namespace-10-name>",
            ],
            "StorageAccountName": "<storage-account-name>"
        }
    }
}

In una definizione automatica i nomi degli elementi vengono generati automaticamente in base alle convenzioni di denominazione, come illustrato in questo esempio.

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

È possibile trovare esempi nel repository GitHub nel percorso degli ambienti di Microsoft Sentinel e usare gli esempi come riferimento per preparare i casi d'uso.

Distribuire l'ambiente di Microsoft Sentinel

Dopo aver definito almeno un ambiente, è possibile creare la connessione al servizio di Azure per l'integrazione con Azure DevOps. Dopo aver creato la connessione al servizio, impostare l'entità servizio collegata sul ruolo proprietario o un livello di autorizzazioni simile sulla sottoscrizione di destinazione.

1. Importare la pipeline per creare il nuovo ambiente come definito in questo file.

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

2. Immettere quindi il nome della connessione al servizio che rappresenta l'ambiente.

   

3. Scegliere il ramo per la definizione dell'ambiente nel repository. 

4. Immettere il nome della connessione al servizio Azure DevOps per la sottoscrizione nella casella Connessione all'ambiente di Azure.

5. Immettere il nome dell'ambiente che una connessione al servizio può usare per risolvere più ambienti nella stessa sottoscrizione.

6. Scegliere l'azione da applicare ai connettori.

7. Selezionare Use PowerShell Pre-Release Artifacts (Usa artefatti versione non definitiva di PowerShell) se si vogliono usare le versioni non definitive dei componenti del framework di PowerShell.

La pipeline include i passaggi seguenti come parte del flusso di distribuzione:

• Distribuire i componenti NuGet.
• Connettersi usando gli strumenti NuGet con il repository degli artefatti.
• Risolvere il feed.
• Installare i moduli necessari.
• Ottenere la definizione dell'ambiente.
• Convalidare le risorse presenti nella destinazione.
• Aggiungere Log Analytics e Microsoft Sentinel se non si trovano nell'area di lavoro.
• Se si ha già Log Analytics, aggiungere Microsoft Sentinel sull'istanza di Log Analytics.
• Creare un'identità gestita per rappresentare l'interazione tra Microsoft Sentinel e App per la logica.
• Creare Azure Key Vault e impostare l'assegnazione di ruolo per la gestione di segreti e chiavi sull'identità gestita.
• Se applicabile, creare un account Automazione di Azure e attivare l'identità gestita assegnata dal sistema.
• Impostare l'assegnazione di ruolo sull'insieme di credenziali delle chiavi per l'identità gestita assegnata dal sistema.
• Creare le definizioni di Hub eventi se non esistono e impostare se la definizione include gli elementi di integrazione.
• Impostare l'assegnazione di ruolo sull'insieme di credenziali delle chiavi per l'identità gestita assegnata dal sistema.
• Creare le definizioni dell'account di archiviazione se non esistono e impostare se la definizione include gli elementi di integrazione.
• Impostare l'assegnazione di ruolo sull'insieme di credenziali delle chiavi per l'identità gestita assegnata dal sistema.
• Distribuire le azioni del connettore.
• Distribuire il runbook di integrazione nell'account di Automazione.
• Distribuire le connessioni di App per la logica se sono definite come parte dell'ambiente.

Eliminare definitivamente un ambiente di Microsoft Sentinel

Quando l'ambiente non è più necessario, ad esempio nel caso di un ambiente di sviluppo o test, è possibile eliminarlo come definito in questo file.

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

Come quando si distribuisce la pipeline di ambiente, si specifica il nome della connessione al servizio che rappresenta l'ambiente.

Uso dell'ambiente di Microsoft Sentinel

Dopo aver pronto l'ambiente, è possibile iniziare a creare gli artefatti per configurare i diversi casi d'uso.

1. Esportare gli artefatti dall'ambiente su cui si sta lavorando come definito in questo file.

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

2. Scegliere il ramo per la definizione dell'ambiente nel repository.

   

3. Immettere il nome della connessione al servizio Azure DevOps per l'ambiente esportato nella casella Connessione all'ambiente di Azure.

4. Selezionare Use PowerShell Pre-Release Artifacts (Usa artefatti versione non definitiva di PowerShell) se si vogliono usare le versioni non definitive dei componenti del framework di PowerShell.

5. Scegliere il formato per le regole di analisi e ricerca.

   Il file di output degli artefatti è disponibile nei risultati. Dopo aver creato gli artefatti, è possibile includere il file di output nel repository Git.

Creare gli artefatti nell'ambiente Microsoft Sentinel

Posizionare gli artefatti nel percorso dei casi d'uso MITRE di Microsoft Sentinel. Configurare la struttura di cartelle in base ai diversi tipi di artefatti.

1. Avviare il processo di compilazione come definito in questo file.

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

2. Scegliere il ramo per la definizione dell'ambiente nel repository.

   Diagramma di come scegliere il ramo per la compilazione degli artefatti.(./media/build-artifacts-pipeline.png)

3. Selezionare Use PowerShell Pre-Release Artifacts (Usa artefatti versione non definitiva di PowerShell) se si vogliono usare le versioni non definitive dei componenti del framework di PowerShell.

La pipeline è costituita da questi passaggi:

• Distribuire i componenti NuGet.
• Connettere gli strumenti NuGet al repository degli artefatti.
• Risolvere il feed.
• Installare i moduli necessari.
• Ottenere il framework del toolkit di test per convalidare i modelli di Resource Manager.
• Convalidare i modelli di Resource Manager.
• Convalidare il codice dei runbook di PowerShell ed eseguire la convalida della sintassi.
• Eseguire gli unit test pester, se applicabile.
• Convalidare la sintassi KQL nelle regole di ricerca e analisi.

Distribuire gli artefatti nell'ambiente Di Microsoft Sentinel

Nella distribuzione degli artefatti è possibile usare i repository di Microsoft Sentinel o gli esempi di pipeline di distribuzione in questo repository. Per altre informazioni, vedere Distribuire contenuto personalizzato dal repository.

Repository di Microsoft Sentinel

Se si usano i repository di Microsoft Sentinel, è possibile configurare un processo di rilascio per includere gli artefatti nel repository connesso a ogni istanza di Microsoft Sentinel. Dopo aver eseguito il commit degli artefatti nel repository, alcuni dei passaggi vengono eseguiti automaticamente durante la creazione della pipeline e l'abilitazione dei repository di Microsoft Sentinel.

È anche possibile personalizzare i processi di distribuzione che i repository di Microsoft Sentinel eseguono in base alle procedure descritte in questo documento. Un aspetto importante da considerare è l'approvazione del rilascio, che è possibile configurare seguendo questi approcci:

• Approvazione della richiesta pull durante il commit degli artefatti. Per altre informazioni, vedere Creare richieste pull.
• Approvazione della pipeline di rilascio durante l'esecuzione della distribuzione. Per altre informazioni, vedere Definire le approvazioni e i controlli.

Esempi di pipeline di distribuzione di Microsoft Sentinel

Usando gli esempi di pipeline di distribuzione di Microsoft Sentinel, è possibile configurare un processo di rilascio.

1. Configurare il processo di rilascio come definito in questo file.

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

2. Scegliere il ramo per la definizione dell'ambiente nel repository.

   

3. Immettere il nome della connessione al servizio Azure DevOps per l'ambiente esportato nella casella Connessione all'ambiente di Azure.

4. Selezionare Use PowerShell Pre-Release Artifacts (Usa artefatti versione non definitiva di PowerShell) se si vogliono usare le versioni non definitive dei componenti del framework di PowerShell.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autore principale:

• Kevin Kisoka | Architetto associato

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

• Per informazioni su Microsoft Sentinel con DevOps per l'architettura a tenant singolo, vedere Distribuzione e gestione di Microsoft Sentinel come codice.
• Per informazioni sulla progettazione di un'architettura MSSP che funziona in più directory di Microsoft Entra, vedere Combinazione di Azure Lighthouse con le funzionalità DevOps di Microsoft Sentinel.
• Per informazioni sull'identità gestita con Microsoft Sentinel, vedere Novità: Identità gestita per il connettore app per la logica di Microsoft Sentinel.
• Per informazioni su come distribuire il contenuto da un repository di Microsoft Sentinel, vedere Distribuire contenuto personalizzato dal repository.
• Per informazioni sulle considerazioni sulla sicurezza di Azure DevOps, vedere Informazioni di riferimento rapido sulle autorizzazioni predefinite.
• Per informazioni su come proteggere un repository Di Azure DevOps, vedere Aggiungere la protezione a una risorsa del repository.
• Per informazioni su come gestire la sicurezza delle connessioni al servizio Azure DevOps, vedere Connessioni al servizio in Azure Pipelines.

Risorse correlate

• Monitoraggio della sicurezza ibrida con Microsoft Defender per cloud e Microsoft Sentinel
• Progettare una pipeline CI/CD con Azure DevOps
• Funzionalità avanzate dei modelli di Resource Manager