Protezione della proprietà intellettuale MSSP in Microsoft Sentinel
Questo articolo descrive i metodi che i provider di servizi di sicurezza gestiti (MSSP) 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 abbia un account Contratto Enterprise (EA)/Con pagamento in base al consumo (PAYG). Nelle sezioni seguenti vengono descritti separatamente ognuno di questi metodi.
Cloud Solutions Providers (CSP)
Se si rivende Azure come Cloud Solutions Provider (CSP), si gestisce l'abbonamento Azure del cliente. Grazie ad Amministrazione per conto di (AOBO), agli utenti del gruppo Agenti di amministrazione del tenant MSSP viene concesso l'accesso proprietario alla sottoscrizione di Azure del cliente, mentre il cliente non ha accesso per impostazione predefinita.
Se altri utenti del tenant MSSP, al di fuori del gruppo Agenti di 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é all'intera sottoscrizione, in modo da 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 relative applicazioni, ma mantenere comunque 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 concedendo l'accesso a livello di gruppo di risorse, i clienti hanno accesso ai dati di log per le risorse a cui possono accedere, come i log di una macchina virtuale, anche senza accedere a Microsoft Sentinel. Per altre informazioni, vedere Gestire l'accesso ai dati di Microsoft Sentinel in base alla risorsa.
Suggerimento
Se è necessario fornire ai clienti l'accesso all'intera sottoscrizione, è possibile visualizzare le indicazioni riportate in Contratti Enterprise (EA) o con pagamento in base al consumo (PAYG).
Esempio di architettura CSP di Microsoft Sentinel
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 a cui è concesso l'accesso come proprietario alla sottoscrizione CSP sono gli utenti del gruppo Agenti di amministrazione, nel tenant MSSP di 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, come le regole di Analisi e le query di ricerca.
Per altre informazioni, vedere anche la documentazione di Azure Lighthouse.
Contratti Enterprise (EA)/pagamento in base al consumo (PAYG)
Se il cliente acquista direttamente da Microsoft, il cliente ha già accesso completo all'ambiente Azure e non è possibile nascondere nulla del contenuto della 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, è necessario avere un'area di lavoro nel proprio tenant con Microsoft Sentinel abilitato e 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 indicato di seguito:
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 incidenti nell'area di lavoro del cliente. Gli avvisi e gli incidenti 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, poiché la dichiarazione 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 generare un numero elevato di regole, che è possibile gestire tramite script 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ò comportare 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
Cartelle di lavoro
Se è stata sviluppata una cartella di lavoro di Microsoft Sentinel che non si vuole venga copiata dal cliente, ospitare la cartella di lavoro nel tenant MSSP. Assicurarsi di avere accesso alle aree di lavoro dei clienti tramite Azure Lighthouse, quindi assicurarsi di modificare la cartella di lavoro per usare tali aree di lavoro.
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 alla dashboard di Power BI, in cui può visualizzare i dati segnalati, senza dover richiedere autorizzazioni di accesso ad Azure.
- Abilita la pianificazione. Configurare Power BI per inviare periodicamente messaggi di posta elettronica contenenti uno snapshot della dashboard per quel periodo di tempo.
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 le regole di automazione insieme ai playbook, è necessario impostare le autorizzazioni delle regole di automazione sul gruppo di risorse in cui risiedono i playbook. Per altre informazioni, vedere Autorizzazioni per le regole di automazione per l'esecuzione dei playbook.
Passaggi successivi
Per altre informazioni, vedi: