Controllare l'accesso a casi e avvisi di prima parte
Questa guida è destinata agli amministratori e agli analisti della sicurezza di Google SecOps che vogliono controllare l'accesso a casi e avvisi proprietari utilizzando il controllo dell'accesso basato sui ruoli (RBAC) dei dati. Spiega come configurare gli ambiti di accesso ai dati nella parte SIEM della piattaforma e come mapparli agli ambienti SOAR in modo che gli utenti possano visualizzare solo gli avvisi e le richieste derivati dai dati a cui sono autorizzati ad accedere. Se segui questo metodo, puoi applicare le policy di governance dei dati e migliorare la sicurezza. Il completamento riuscito 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 controllo dell'accesso basato sui ruoli per i dati.
- Avvisi proprietari (1P): rilevamenti generati dal motore di rilevamento SIEM di Google SecOps, ad esempio regole, corrispondenze di threat intelligence o analisi della sicurezza. Quando questi rilevamenti SIEM vengono inseriti nel componente SOAR utilizzando il connettore Google SecOps, formano avvisi proprietari e vengono raggruppati in richieste proprietarie.
- Avvisi di terze parti: avvisi acquisiti 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 ignorano 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 i casi associati solo se hanno accesso agli ambiti di dati degli eventi sottostanti. Ad esempio, a un utente del reparto finanza potrebbe essere concesso l'accesso ai dati finanziari inseriti in Google SecOps, ma non ai dati di contatto dei clienti. L'utente del reparto Finanze può visualizzare solo gli avvisi e le richieste associati ai dati finanziari e non può visualizzare avvisi o richieste associati ai dati di contatto del cliente.
Prima di iniziare
Prima di configurare il controllo dell'accesso basato sui ruoli per dati per avvisi e casi proprietari, assicurati che siano soddisfatti i seguenti requisiti:
- L'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 al proprio ambiente assegnato in SOAR.
- Connettore Chronicle: il connettore Chronicle che collega il componente SIEM al componente SOAR utilizza l'API Chronicle moderna. Prima di abilitare questa funzionalità, assicurati che il connettore sia stato eseguito l'upgrade dall'API Backstory legacy all'API Chronicle. Per maggiori dettagli, vedi Eseguire l'upgrade all'API Chronicle.
Abilitare RBAC dei dati per avvisi e richieste di prima parte
Gli amministratori di Google SecOps (ruolo Amministratore API Chronicle in Google Cloud IAM) possono attivare l'RBAC dei dati per avvisi e richieste proprietari nella loro istanza. Esistono due scenari:
Scenario A: l'accesso ai dati SIEM è già applicato
Se i controlli dell'accesso ai dati sono già attivi nel componente SIEM, segui questi passaggi per estendere l'applicazione agli avvisi e ai casi proprietari nel componente SOAR:
- Accedi a Google SecOps.
- Verifica che gli ambiti siano configurati correttamente in Impostazioni SIEM > Accesso ai dati.
- Assegna ambiti di dati agli utenti nella console Google Cloud utilizzando Google Cloud IAM.
- In Google SecOps, vai a Impostazioni SIEM > Accesso ai dati e fai clic su Attiva l'accesso ai dati in SOAR.
- Mappa gli ambiti SIEM agli ambienti SOAR come descritto in Mappare gli ambiti agli ambienti.
L'accesso ai dati è ora applicato agli avvisi e alle richieste di prima parte nel componente SOAR. Ciò vale per tutti i nuovi avvisi e casi, nonché per quelli esistenti creati dopo l'applicazione iniziale dell'accesso ai dati SIEM.
Scenario B: l'accesso ai dati SIEM NON è ancora stato applicato
Se non hai ancora attivato i controlli dell'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 SIEM > Accesso ai dati.
- Assegna ambiti di dati agli utenti nella console Google Cloud utilizzando Google Cloud IAM.
- In Google SecOps, vai a Impostazioni SIEM > Accesso ai dati e fai clic su Applica accesso ai dati.
- Mappa gli ambiti SIEM agli ambienti SOAR come descritto in Mappare gli ambiti agli ambienti.
L'accesso ai dati viene ora applicato nel componente SIEM e per i nuovi avvisi e richieste proprietari nel componente SOAR.
Mappare 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 SOAR > 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 ambito-ambiente.
Mappatura di riserva dell'ambiente
Quando viene configurata la mappatura da ambito ad ambiente, gli avvisi SIEM con un ambito mappato vengono assegnati automaticamente all'ambiente SOAR associato. Questa impostazione sostituisce le impostazioni dell'ambiente nel connettore Chronicle.
Se un avviso SIEM non è limitato (globale) o il suo ambito non è mappato a un ambiente, viene indirizzato all'ambiente di riserva. L'ambiente di fallback è definito dall'impostazione Environment o Environment Field Name nel connettore Chronicle.
Informazioni sulla valutazione dell'accesso
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 proprietario, un utente deve soddisfare sia le autorizzazioni di ambiente che quelle di ambito.
Logica di propagazione dell'ambito
- Ambito dell'avviso: un avviso importato include l'ambito di accesso ai dati assegnato dalle regole di rilevamento di Google SecOps SIEM.
- Ambito del caso: un caso eredita automaticamente l'unione di tutti gli ambiti dagli avvisi associati. Ad esempio, se un caso raggruppa l'avviso 1 (ambito A) e l'avviso 2 (ambito B), il caso 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 |
|---|---|---|---|---|---|
| Avviso 1 (ambito 1) | Ambito 1 | Ambito 1 | Utente con ambito | Sì | L'utente ha accesso al singolo ambito 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 ignorano il filtro degli ambiti e possono visualizzare tutte le richieste. |
| Avviso 1 (ambito globale) | Globale | Globale | Utente globale | Sì | Gli utenti globali ignorano il filtro degli ambiti e possono visualizzare tutte le richieste. |
| Avviso 1 (ambito 1) e Avviso 2 (ambito globale) | Globale | Ambito 1 | Utente con ambito | No | I casi con ambito globale sono limitati agli utenti globali. |
| Avviso 1 (ambito 1) e Avviso 2 (ambito globale) | Globale | Globale | Utente globale | Sì | Gli utenti globali ignorano il filtro degli ambiti e possono visualizzare tutte le richieste. |
| Avviso 1 (ambito globale) | Globale | Ambito 1 | Utente con ambito | No | I casi con ambito globale sono limitati agli utenti globali. |
Regole di raggruppamento dei casi e definizione dell'ambito delle entità
- Raggruppamento delimitato dall'ambiente: gli avvisi possono essere raggruppati in un'unica richiesta solo se gli 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, il caso eredita tutti questi ambiti.
- Impatto degli avvisi senza ambito: se un avviso senza ambito viene raggruppato con un avviso con ambito nell'ambiente di fallback, la richiesta eredita l'ambito globale, rendendola visibile solo agli utenti globali.
- Definizione dell'ambito delle entità uniche: un'entità unica eredita gli ambiti di tutti gli avvisi in cui viene visualizzata.
- Definizione dell'ambito delle entità coinvolte: le entità coinvolte ereditano solo l'ambito dell'avviso principale.
Modifica le mappature ambito-ambiente
Quando modifichi o rimuovi una mappatura degli ambiti, l'impatto dipende dal fatto che gli avvisi e le richieste siano nuovi o esistenti.
- Spostare un ambito: modifica della mappatura di un ambito da Ambiente A ad Ambiente B:
- Nuovi avvisi e casi: indirizzati all'ambiente B.
- Avvisi e casi esistenti: rimangono nell'ambiente A. Gli utenti possono accedervi se dispongono delle autorizzazioni sia per l'ambiente A sia per l'ambito assegnato.
- Rimuovere una mappatura degli ambiti: annullare la mappatura di un ambito da un ambiente:
- Nuovi avvisi e richieste: indirizzati all'ambiente di fallback. Visibile solo agli utenti globali e agli utenti con accesso all'ambiente di fallback.
- Avvisi e casi esistenti: rimangono nel loro ambiente originale, ma diventano visibili solo agli utenti globali perché l'ambito non è più mappato.
Gestire i casi manuali e di overflow
Questa sezione descrive come gestire i casi creati manualmente o derivanti dal superamento del limite di avvisi.
Creare 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. Il caso e il relativo 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. A questi utenti viene assegnato l'ambito globale e sono visibili solo agli utenti globali.
Trovare gli ambiti nella pagina Richieste
Puoi visualizzare gli ambiti di accesso ai dati assegnati a una richiesta 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 il puntatore sopra l'area per visualizzare l'elenco completo.
Tabella Elenco 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.
Gestire le eliminazioni degli ambiti
Questa sezione spiega cosa succede ai casi e agli avvisi esistenti quando un ambito di accesso ai dati viene eliminato nella parte SIEM della piattaforma.
Se un amministratore elimina un ambito di accesso ai dati in Impostazioni SIEM > Accesso ai dati:
- L'ambito viene automaticamente annullato da 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 detengono ancora l'attestazione del token memorizzata nella cache) potranno accedere a questi casi e avvisi storici.
Risoluzione dei problemi
Questa sezione descrive le aspettative di rendimento e fornisce soluzioni self-service per i problemi di deployment comuni.
Latenza e limiti
La propagazione delle modifiche alle mappature ambito-ambiente o all'attivazione iniziale può richiedere fino a 30 secondi.
Convalida e test
Per convalidare la configurazione, testa l'accesso a casi e avvisi utilizzando account utente con ambiti e autorizzazioni per l'ambiente diversi. 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.