Protezione della proprietà intellettuale MSSP in Microsoft Sentinel

Questo articolo descrive i metodi che i provider di servizi di sicurezza gestiti possono usare per proteggere la proprietà intellettuale sviluppata in Microsoft Sentinel, ad esempio le regole di analisi di Microsoft Sentinel, le query di ricerca, i playbook e le cartelle di lavoro.

Il metodo scelto dipende dal modo in cui ogni cliente acquista Azure; sia che si agisca come Cloud Solutions Provider (CSP) o che il cliente disponga di un account con pagamento in base al consumo (EA) Contratto Enterprise (EA)/Pagamento in base al consumo. Le sezioni seguenti descrivono ognuno di questi metodi separatamente.

Cloud Solutions Providers (CSP)

Se si riapplica Azure come Cloud Solutions Provider (CSP), si gestisce la sottoscrizione di Azure del cliente. Grazie a Amministrazione-On-Behalf-Of (AOBO), agli utenti del gruppo Amministrazione Agents del tenant MSSP viene concesso l'accesso proprietario alla sottoscrizione di Azure del cliente e il cliente non ha accesso per impostazione predefinita.

Se altri utenti del tenant MSSP, all'esterno del gruppo agenti Amministrazione, devono accedere all'ambiente del cliente, è consigliabile usare Azure Lighthouse. Azure Lighthouse consente di concedere a utenti o gruppi l'accesso a un ambito specifico, ad esempio un gruppo di risorse o una sottoscrizione, usando uno dei ruoli predefiniti.

Se è necessario fornire agli utenti dei clienti l'accesso all'ambiente Azure, è consigliabile concedere loro l'accesso a livello di gruppo di risorse, anziché l'intera sottoscrizione, in modo da poter mostrare/nascondere parti dell'ambiente in base alle esigenze.

Ad esempio:

• È possibile concedere al cliente l'accesso a diversi gruppi di risorse in cui si trovano le applicazioni, ma mantenere l'area di lavoro di Microsoft Sentinel in un gruppo di risorse separato, in cui il cliente non ha accesso.

• Usare questo metodo per consentire ai clienti di visualizzare cartelle di lavoro e playbook selezionati, ovvero risorse separate che possono risiedere nel proprio gruppo di risorse.

Anche con la concessione dell'accesso a livello di gruppo di risorse, i clienti hanno accesso ai dati di log per le risorse a cui possono accedere, ad esempio i log da una macchina virtuale, anche senza accesso a Microsoft Sentinel. Per altre informazioni, vedere Gestire l'accesso ai dati di Microsoft Sentinel per risorsa.

Suggerimento

Se è necessario fornire ai clienti l'accesso all'intera sottoscrizione, è consigliabile visualizzare le linee guida in Contratto Enterprise (EA) / con pagamento in base al consumo (con pagamento in base al consumo).

Architettura CSP di Microsoft Sentinel di esempio

L'immagine seguente descrive il funzionamento delle autorizzazioni descritte nella sezione precedente quando si fornisce l'accesso ai clienti CSP:

In questa immagine:

• Gli utenti concessi con l'accesso proprietario alla sottoscrizione CSP sono gli utenti del gruppo Amministrazione Agents, nel tenant mssp Microsoft Entra.

• Altri gruppi di MSSP ottengono l'accesso all'ambiente del cliente tramite Azure Lighthouse.

• L'accesso dei clienti alle risorse di Azure viene gestito dal controllo degli accessi in base al ruolo di Azure a livello di gruppo di risorse.

  In questo modo, gli MSSP possono nascondere i componenti di Microsoft Sentinel in base alle esigenze, ad esempio le regole di analisi e le query di ricerca.

Per altre informazioni, vedere anche la documentazione di Azure Lighthouse.

Contratto Enterprise (EA) / pagamento in base al consumo (pagamento in base al consumo)

Se il cliente acquista direttamente da Microsoft, il cliente ha già accesso completo all'ambiente Azure e non è possibile nascondere nulla nella sottoscrizione di Azure del cliente.

Proteggere invece la proprietà intellettuale sviluppata in Microsoft Sentinel come indicato di seguito, a seconda del tipo di risorsa da proteggere:

Regole di analisi e query di ricerca

Le regole di analisi e le query di ricerca sono entrambe contenute in Microsoft Sentinel e pertanto non possono essere separate dall'area di lavoro di Microsoft Sentinel.

Anche se un utente dispone solo delle autorizzazioni di lettura di Microsoft Sentinel, può visualizzare la query. In questo caso, è consigliabile ospitare le regole di Analisi e le query di ricerca nel proprio tenant MSSP, anziché nel tenant del cliente.

A tale scopo, è necessaria un'area di lavoro nel proprio tenant con Microsoft Sentinel abilitato ed è anche necessario visualizzare l'area di lavoro del cliente tramite Azure Lighthouse.

Per creare una regola analitica o una query di ricerca nel tenant MSSP che fa riferimento ai dati nel tenant del cliente, è necessario usare l'istruzione workspace come segue:

workspace('<customer-workspace>').SecurityEvent
| where EventID == ‘4625’

Quando si aggiunge un'istruzione workspace alle regole di analisi, considerare quanto segue:

• Nessun avviso nell'area di lavoro del cliente. Le regole create in questo modo non creano avvisi o eventi imprevisti nell'area di lavoro del cliente. Gli avvisi e gli eventi imprevisti esistono solo nell'area di lavoro MSSP.

• Creare avvisi separati per ogni cliente. Quando si usa questo metodo, è anche consigliabile usare regole di avviso separate per ogni cliente e rilevamento, perché l'istruzione dell'area di lavoro è diversa in ogni caso.

  È possibile aggiungere il nome del cliente al nome della regola di avviso per identificare facilmente il cliente in cui viene attivato l'avviso. Gli avvisi separati possono comportare un numero elevato di regole, che è possibile gestire tramite scripting o Microsoft Sentinel come codice.

  Ad esempio:

  

• Creare aree di lavoro MSSP separate per ogni cliente. La creazione di regole separate per ogni cliente e rilevamento può causare il raggiungimento del numero massimo di regole di analisi per l'area di lavoro (512). Se si hanno molti clienti e si prevede di raggiungere questo limite, è possibile creare un'area di lavoro MSSP separata per ogni cliente.

  Ad esempio:

  

Importante

La chiave per usare correttamente questo metodo consiste nell'usare l'automazione per gestire un ampio set di regole nelle aree di lavoro.

Per altre informazioni, vedere Regole di analisi tra aree di lavoro

Workbooks

Se è stata sviluppata una cartella di lavoro di Microsoft Sentinel che non si vuole copiare dal cliente, ospitare la cartella di lavoro nel tenant MSSP. Assicurarsi di avere accesso alle aree di lavoro dei clienti tramite Azure Lighthouse e quindi assicurarsi di modificare la cartella di lavoro per usare tali aree di lavoro dei clienti.

Ad esempio:

Per altre informazioni, vedere Cartelle di lavoro tra aree di lavoro.

Se si vuole che il cliente sia in grado di visualizzare le visualizzazioni della cartella di lavoro, mantenendo comunque il segreto del codice, è consigliabile esportare la cartella di lavoro in Power BI.

Esportazione della cartella di lavoro in Power BI:

• Semplifica la condivisione delle visualizzazioni della cartella di lavoro. È possibile inviare al cliente un collegamento al dashboard di Power BI, in cui possono visualizzare i dati segnalati, senza richiedere autorizzazioni di accesso ad Azure.
• Abilita la pianificazione. Configurare Power BI per inviare periodicamente messaggi di posta elettronica che contengono uno snapshot del dashboard per quel periodo.

Per altre informazioni, vedere Importare i dati di log di Monitoraggio di Azure in Power BI.

Playbook

È possibile proteggere i playbook come indicato di seguito, a seconda della posizione in cui sono state create le regole di analisi che attivano il playbook:

• Regole di analisi create nell'area di lavoro MSSP. Assicurarsi di creare i playbook nel tenant MSSP e di ottenere tutti i dati relativi a eventi imprevisti e avvisi dall'area di lavoro MSSP. È possibile allegare i playbook ogni volta che si crea una nuova regola nell'area di lavoro.

  Ad esempio:

  

• Regole di analisi create nell'area di lavoro del cliente. Usare Azure Lighthouse per collegare regole di analisi dall'area di lavoro del cliente a un playbook ospitato nell'area di lavoro MSSP. In questo caso, il playbook ottiene i dati degli avvisi e degli eventi imprevisti e qualsiasi altra informazione del cliente dall'area di lavoro del cliente.

  Ad esempio:

  

In entrambi i casi, se il playbook deve accedere all'ambiente Azure del cliente, usare un utente o un'entità servizio con tale accesso tramite Lighthouse.

Tuttavia, se il playbook deve accedere alle risorse non di Azure nel tenant del cliente, ad esempio Microsoft Entra ID, Office 365 o Microsoft Defender XDR, creare un'entità servizio con autorizzazioni appropriate nel tenant del cliente e quindi aggiungere tale identità nel playbook.

Nota

Se si usano regole di automazione insieme ai playbook, è necessario impostare le autorizzazioni per le regole di automazione per il gruppo di risorse in cui si trovano i playbook. Per altre informazioni, vedere Autorizzazioni per le regole di automazione per l'esecuzione di playbook.

Passaggi successivi

Per altre informazioni, vedere:

• Playbook tecnico di Microsoft Sentinel per i provider di servizi cloud
• Gestire più tenant in Microsoft Sentinel come MSSP
• Estendere Microsoft Sentinel tra più aree di lavoro e tenant
• Visualizzare e monitorare i dati
• Esercitazione: Configurare le risposte automatiche alle minacce in Microsoft Sentinel