Controlla l'accesso a richieste di assistenza e avvisi di Google
Questa guida è rivolta agli amministratori e agli analisti della sicurezza di Google SecOps che vogliono controllare l'accesso ad avvisi e casi proprietari (1P) utilizzando il controllo degli accessi basato su ruoli (RBAC) dei dati. Spiega come configurare gli ambiti di accesso ai dati sul lato SIEM della piattaforma e mapparli agli ambienti SOAR in modo che gli utenti possano visualizzare solo gli avvisi e i casi derivati dai dati a cui sono autorizzati ad accedere. Seguendo questo metodo, puoi applicare le policy di governance dei dati e migliorare la sicurezza. Il completamento con successo consente alle organizzazioni di limitare la visibilità dei dati in base a ruoli e responsabilità, migliorando la conformità e riducendo il rischio di esposizione dei dati.
Terminologia chiave
I seguenti termini vengono utilizzati in questa guida per descrivere i concetti e i componenti del RBAC dei dati.
- Avvisi proprietari (1P): rilevamenti generati dal motore di rilevamento SIEM di Google SecOps, come regole, corrispondenze di threat intelligence o analisi della sicurezza. Quando questi rilevamenti SIEM vengono importati nel componente SOAR utilizzando il connettore Google SecOps, formano avvisi proprietari e vengono raggruppati in richieste proprietarie.
- Avvisi di terze parti (3P): avvisi importati direttamente nel componente SOAR da strumenti di sicurezza esterni (ad esempio, firewall di terze parti o agenti di rilevamento degli endpoint) utilizzando integrazioni SOAR separate. Questi avvisi bypassano il motore di rilevamento SIEM e non sono soggetti agli ambiti di accesso ai dati SIEM.
Per gli avvisi proprietari, Google SecOps propaga gli ambiti dei dati associati degli eventi sottostanti al componente SOAR. Questa propagazione consente agli analisti di visualizzare gli avvisi e le richieste associate solo se hanno accesso agli ambiti dei dati degli eventi sottostanti. Ad esempio, a un utente del reparto finanziario potrebbe essere concesso l'accesso ai dati finanziari acquisiti in Google SecOps, ma non ai dati di contatto dei clienti. L'utente del team finanziario può visualizzare solo gli avvisi e le richieste associati ai dati finanziari e non può visualizzare gli avvisi o le richieste associati ai dati di contatto dei clienti.
Prima di iniziare
Prima di configurare l'RBAC dei dati per richieste di assistenza e avvisi di Google, assicurati che siano soddisfatti i seguenti requisiti:
- La tua istanza Google SecOps deve essere unificata (SIEM e SOAR abilitati).
- Comportamento SIEM multi-istanza: se hai più istanze SIEM connesse a una singola istanza SOAR, la propagazione e l'applicazione dell'ambito si applicano solo all'istanza SIEM principale. Gli ambiti delle istanze SIEM secondarie vengono ignorati sul lato SOAR e questi avvisi sono visibili a qualsiasi utente con accesso all'ambiente assegnato in SOAR.
- Connettore Chronicle: il connettore Chronicle che collega il componente SIEM al componente SOAR utilizza l'API Chronicle moderna. Assicurati che venga eseguito l'upgrade del connettore dall'API Backstory legacy all'API Chronicle prima di attivare questa funzionalità. Per maggiori dettagli, consulta Esegui l'upgrade all'API Chronicle.
Abilita l'RBAC dei dati per avvisi e richieste di terze parti
Gli amministratori di Google SecOps (ruolo Amministratore API Chronicle all'interno di Google Cloud IAM) possono attivare l'RBAC dei dati per gli avvisi e i casi di terze parti nella loro istanza. Esistono due scenari:
Scenario A: l'accesso ai dati SIEM è già applicato
Se i controlli di accesso ai dati sono già attivi nel componente SIEM, segui questi passaggi per estendere l'applicazione agli avvisi e alle richieste proprietari nel componente SOAR:
- Accedi a Google SecOps.
- Verifica che gli ambiti siano configurati correttamente in Impostazioni > Gestione degli accessi > Accesso ai dati.
- Assegna gli ambiti dei dati agli utentinella console Google Cloud utilizzando Google Cloud IAM.
- In Google SecOps, vai a Impostazioni > Gestione degli accessi > Accesso ai dati e fai clic su Abilita l'accesso ai dati in SOAR.
- Mappa gli ambiti SIEM agli ambienti SOAR come descritto in Mappa gli ambiti agli ambienti.
L'accesso ai dati è ora applicato per gli avvisi e i casi di prima parte nel componente SOAR. Questo vale per tutti i nuovi avvisi e casi, nonché per quelli esistenti creati dopo l'applicazione iniziale di SIEM Data Access.
Scenario B: l'accesso ai dati SIEM NON è ancora applicato
Se non hai ancora attivato i controlli di accesso ai dati in SIEM, l'applicazione verrà attivata contemporaneamente per SIEM e SOAR.
- Accedi a Google SecOps.
- Verifica che gli ambiti siano configurati correttamente in Impostazioni > Gestione degli accessi > Accesso ai dati.
- Assegna gli ambiti dei dati agli utentinella console Google Cloud utilizzando Google Cloud IAM.
- In Google SecOps, vai a Impostazioni > Gestione degli accessi > Accesso ai dati e fai clic su Applica accesso ai dati.
- Mappa gli ambiti SIEM agli ambienti SOAR come descritto in Mappa gli ambiti agli ambienti.
L'accesso ai dati è ora applicato nel componente SIEM e per i nuovi avvisi e richieste proprietari nel componente SOAR.
Mappa gli ambiti agli ambienti
Per collegare gli ambiti dei dati SIEM a SOAR, mappa gli ambiti di accesso ai dati SIEM agli ambienti SOAR.
- Vai a Impostazioni > Gestione accessi > Ambienti per accedere alla pagina di configurazione dell'ambiente.
- Seleziona un ambiente esistente da modificare o fai clic su Aggiungi ambiente.
- Associa gli ambiti collegando uno o più ambiti SIEM a questo ambiente.
- Individua il campo Ambiti di accesso ai dati e seleziona gli ambiti SIEM richiesti.
- Regole di mappatura:
- Un ambito può essere mappato a un solo ambiente.
- È possibile mappare più ambiti a un singolo ambiente.
- Fai clic su Salva per applicare la mappatura dell'ambito all'ambiente.
Mappatura di riserva dell'ambiente
Quando è configurata la mappatura da ambito ad ambiente, gli avvisi SIEM con un ambito mappato vengono assegnati automaticamente all'ambiente SOAR associato. In questo modo, le impostazioni dell'ambiente nel connettore Chronicle vengono sostituite.
Se un avviso SIEM non ha un ambito (globale) o il suo ambito non è mappato a un ambiente, viene indirizzato all'ambiente di riserva. L'ambiente di riserva è definito dall'impostazione Environment o Environment Field Name nel connettore Chronicle.
Informazioni sulla valutazione degli accessi
Questa sezione descrive in che modo Google SecOps valuta l'accesso degli utenti a casi e avvisi in base agli ambiti e agli ambienti assegnati. Per visualizzare una richiesta o un avviso di prima parte, un utente deve soddisfare le autorizzazioni relative sia all'ambiente sia all'ambito.
Logica di propagazione dell'ambito
- Ambito dell'avviso: un avviso importato contiene l'ambito di accesso ai dati assegnato dalle regole di rilevamento di Google SecOps SIEM.
- Ambito della richiesta: una richiesta eredita automaticamente l'unione di tutti gli ambiti dagli avvisi associati. Ad esempio, se una richiesta raggruppa l'Avviso 1 (Ambito A) e l'Avviso 2 (Ambito B), la richiesta eredita sia l'Ambito A che l'Ambito B.
Regole di accesso
Per accedere a una risorsa (richiesta o avviso), un utente deve disporre di:
- Accesso all'ambiente SOAR assegnato alla risorsa.
- Accesso a tutti gli ambiti di accesso ai dati assegnati alla risorsa.
Scenari di valutazione
La tabella seguente mostra come viene valutato l'accesso degli utenti in diversi scenari:
| Avvisi sulle richieste | Ambiti delle richieste | Ambiti assegnati dall'utente | Livello di accesso utente | Accesso concesso alla richiesta e agli avvisi associati? | Rationale |
|---|---|---|---|---|---|
| Allarme 1 (Ambito 1) | Ambito 1 | Ambito 1 | Utente con ambito | Sì | L'utente ha accesso all'ambito singolo assegnato alla richiesta. |
| Avviso 1 (ambito 1) e Avviso 2 (ambito 2) | Ambito 1 e Ambito 2 | Ambito 1 | Utente con ambito | No | All'utente manca l'ambito 2; deve avere accesso a tutti gli ambiti assegnati alla richiesta. |
| Avviso 1 (ambito 1) e Avviso 2 (ambito 2) | Ambito 1 e Ambito 2 | Ambito 1 e Ambito 2 | Utente con ambito | Sì | L'utente ha accesso a tutti gli ambiti assegnati alla richiesta. |
| Avviso 1 (ambito 1) e Avviso 2 (ambito 2) | Ambito 1 e Ambito 2 | Globale | Utente globale | Sì | Gli utenti globali bypassano il filtro dell'ambito e possono visualizzare tutte le richieste. |
| Avviso 1 (ambito globale) | Globale | Globale | Utente globale | Sì | Gli utenti globali bypassano il filtro dell'ambito e possono visualizzare tutte le richieste. |
| Avviso 1 (ambito 1) e Avviso 2 (ambito globale) | Globale | Ambito 1 | Utente con ambito | No | Le richieste con ambito globale sono limitate agli utenti globali. |
| Avviso 1 (ambito 1) e Avviso 2 (ambito globale) | Globale | Globale | Utente globale | Sì | Gli utenti globali bypassano il filtro dell'ambito e possono visualizzare tutte le richieste. |
| Avviso 1 (ambito globale) | Globale | Ambito 1 | Utente con ambito | No | Le richieste con ambito globale sono limitate agli utenti globali. |
Regole di raggruppamento delle richieste e di definizione dell'ambito delle entità
- Raggruppamento limitato dall'ambiente: gli avvisi possono essere raggruppati in un'unica richiesta solo se i relativi ambiti mappati li indirizzano allo stesso ambiente.
- Accumulo di ambiti: quando gli avvisi con ambiti diversi vengono mappati allo stesso ambiente e raggruppati in un caso, quest'ultimo eredita tutti gli ambiti.
- Impatto degli avvisi senza ambito: se un avviso senza ambito viene raggruppato con un avviso con ambito nell'ambiente di riserva, la richiesta eredita l'ambito globale, rendendola visibile solo agli utenti globali.
- Ambito delle entità univoche: un'entità univoca eredita gli ambiti di tutti gli avvisi in cui viene visualizzata.
- Ambito delle entità coinvolte: le entità coinvolte ereditano solo l'ambito dell'avviso principale.
Modifica le mappature da ambito ad ambiente
Quando modifichi o rimuovi una mappatura dell'ambito, l'impatto dipende dal fatto che gli avvisi e i casi siano nuovi o esistenti.
- Spostamento di un ambito: modifica della mappatura di un ambito dall'Ambiente A all'Ambiente B:
- Nuovi avvisi e richieste: indirizzati all'Ambiente B.
- Avvisi e richieste esistenti: rimangono nell'Ambiente A. Gli utenti possono accedervi se dispongono delle autorizzazioni sia per l'Ambiente A sia per l'ambito assegnato.
- Rimuovi una mappatura dell'ambito: annulla la mappatura di un ambito da un ambiente:
- Nuovi avvisi e richieste: indirizzati all'ambiente di riserva. Visibile solo agli utenti globali e agli utenti con accesso all'ambiente di riserva.
- Avvisi e casi esistenti: rimangono nel loro ambiente originale, ma diventano visibili solo agli utenti globali perché l'ambito non è più mappato.
Gestisci i casi manuali e di overflow
Questa sezione descrive come gestire le richieste create manualmente o che derivano da un overflow di avvisi.
Crea richieste manuali
- Nella scheda Richieste, fai clic su Crea richiesta manuale.
- Seleziona l'ambiente di destinazione.
- Seleziona un Ambito di accesso ai dati. L'elenco mostra gli ambiti mappati all'ambiente e assegnati al tuo account utente.
- Se non esistono ambiti sovrapposti, l'elenco è vuoto e non puoi inviare la richiesta.
- Gli utenti globali possono selezionare qualsiasi ambito mappato all'ambiente.
- Inserisci i dettagli della richiesta e fai clic su Invia. La richiesta e l'avviso manuale ereditano l'ambito selezionato.
Richieste in overflow
Le richieste di overflow raggruppano gli avvisi in più ambiti senza seguire il modello di entità condivisa. Viene assegnato loro l'ambito globale e sono visibili solo agli utenti globali.
Trova gli ambiti nella pagina Richieste
Puoi visualizzare gli ambiti di accesso ai dati assegnati a un caso in diverse posizioni all'interno dell'interfaccia di Google SecOps.
Intestazione della richiesta
Gli ambiti assegnati vengono visualizzati come etichette di sola lettura accanto al campo Ambiente. Tieni premuto il puntatore sull'area per visualizzare l'elenco completo.
Tabella dell'elenco delle richieste
Puoi anche visualizzare gli ambiti direttamente dalla tabella Elenco richieste:
- Nella tabella Elenco richieste è disponibile una colonna Ambiti di accesso ai dati.
- Questa colonna mostra gli ambiti assegnati alla richiesta (separati da virgole se sono più di uno).
- Puoi filtrare la coda digitando i nomi degli ambiti nel filtro di testo della colonna.
Gestisci le eliminazioni degli ambiti
Questa sezione spiega cosa succede alle richieste e agli avvisi esistenti quando un ambito di accesso ai dati viene eliminato nella sezione SIEM della piattaforma.
Se un amministratore elimina un ambito di accesso ai dati in Impostazioni > Gestione degli accessi > Accesso ai dati:
- L'ambito viene automaticamente rimosso dalla mappatura di qualsiasi ambiente SOAR.
- Applicazione dell'accesso: poiché l'ambito viene eliminato dal componente SIEM e da Cloud IAM, solo gli utenti globali (o gli utenti che possiedono ancora l'attestazione del token memorizzato nella cache) potranno accedere a questi casi e avvisi storici.
Risoluzione dei problemi
Questa sezione descrive le aspettative in termini di prestazioni e fornisce soluzioni self-service per i problemi di deployment più comuni.
Latenza e limiti
La propagazione delle modifiche alle mappature degli ambiti agli ambienti o l'attivazione iniziale possono richiedere fino a 30 secondi.
Convalida e test
Per convalidare la configurazione, testa l'accesso a richieste e avvisi utilizzando account utente con autorizzazioni di ambito e ambiente diverse. Verifica che gli utenti possano visualizzare solo i dati per cui sono autorizzati.
Hai bisogno di ulteriore assistenza? Ricevi risposte dai membri della community e dai professionisti di Google SecOps.