Controllare l'accesso a richieste e avvisi proprietari
Questa guida è rivolta agli amministratori e agli analisti della sicurezza di Google SecOps che vogliono controllare l'accesso a richieste e avvisi proprietari utilizzando il controllo degli accessi basato su ruoli (RBAC) dei dati. Spiega come configurare gli ambiti di accesso ai dati nella parte SIEM della piattaforma e come eseguirne il mapping 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. Seguendo questo metodo, puoi applicare le policy di governance dei dati e migliorare la sicurezza. Il completamento corretto 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 dell'RBAC dei dati.
- Avvisi proprietari: 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 inseriti 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 le richieste associate solo se hanno accesso agli ambiti dei 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 finanza può visualizzare solo gli avvisi e le richieste associati ai dati finanziari e non può visualizzare avvisi o richieste associati ai dati di contatto dei clienti.
Prima di iniziare
Prima di configurare l'RBAC dei dati per richieste e avvisi proprietari, assicurati che siano soddisfatti i seguenti requisiti:
- La tua istanza Google SecOps deve essere unificata (SIEM e SOAR abilitati).
- Comportamento SIEM multiistanza: se hai più istanze SIEM connesse a una singola istanza SOAR, la propagazione e l'applicazione degli ambiti 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 la moderna API Chronicle. Prima di abilitare questa funzionalità, assicurati che il connettore sia stato eseguito l'upgrade dall'API Backstory legacy all'API Chronicle. Per maggiori dettagli, consulta Eseguire l'upgrade all'API Chronicle.
Abilitare l'RBAC dei dati per avvisi e richieste proprietari
Gli amministratori di Google SecOps (ruolo Amministratore API Chronicle in Google Cloud IAM) possono abilitare 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 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 SIEM > Accesso ai dati.
- Assegna gli ambiti dei dati agli utenti nella Google Cloud console utilizzando Google Cloud IAM.
- In Google SecOps, vai a Impostazioni SIEM > Accesso ai dati e fai clic su Abilita l'accesso ai dati in SOAR.
- Esegui il mapping degli ambiti SIEM agli ambienti SOAR come descritto in Eseguire il mapping degli ambiti agli ambienti.
L'accesso ai dati è ora applicato per avvisi e richieste proprietari nel componente SOAR. Questo vale per tutti i nuovi avvisi e le nuove richieste, nonché per quelli esistenti creati dopo l'applicazione iniziale dell'accesso ai dati SIEM.
Scenario B: l'accesso ai dati SIEM NON è ancora applicato
Se non hai ancora abilitato i controlli di accesso ai dati in SIEM, l'applicazione verrà abilitata contemporaneamente per SIEM e SOAR.
- Accedi a Google SecOps.
- Verifica che gli ambiti siano configurati correttamente in Impostazioni SIEM > Accesso ai dati.
- Assegna gli ambiti dei dati agli utenti nella Google Cloud console utilizzando Google Cloud IAM.
- In Google SecOps, vai a Impostazioni SIEM > Accesso ai dati e fai clic su Applica accesso ai dati.
- Esegui il mapping degli ambiti SIEM agli ambienti SOAR come descritto in Eseguire il mapping degli ambiti agli ambienti.
L'accesso ai dati è ora applicato nel componente SIEM e per i nuovi avvisi e le nuove richieste proprietari nel componente SOAR.
Eseguire il mapping degli ambiti agli ambienti
Per collegare gli ambiti dei dati SIEM a SOAR, esegui il mapping degli 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 gli ambiti SIEM a questo ambiente.
- Individua il campo Ambiti di accesso ai dati e seleziona gli ambiti SIEM richiesti.
- Regole di mapping:
- Un ambito può essere mappato a un solo ambiente.
- È possibile eseguire il mapping di più ambiti a un singolo ambiente.
- Fai clic su Salva per applicare il mapping da ambito ad ambiente.
Mapping di fallback dell'ambiente
Quando viene configurato il mapping 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 ha ambito (globale) o il suo ambito non è mappato a un ambiente, viene indirizzato all'ambiente di fallback. L'ambiente di fallback è 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 richieste 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 dell'ambiente sia quelle dell'ambito.
Logica di propagazione dell'ambito
- Ambito dell'avviso: un avviso inserito include l'ambito di accesso ai dati assegnato dalle regole di rilevamento SIEM di Google SecOps.
- Ambito della richiesta: una richiesta eredita automaticamente l'unione di tutti gli ambiti degli 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 sia 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 all'utente | Livello di accesso utente | L'accesso alla richiesta e agli avvisi associati è stato concesso? | 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 | 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 ignorano il filtro degli ambiti 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 una singola 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 una richiesta, la richiesta 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 e diventa visibile solo agli utenti globali.
- Definizione dell'ambito delle entità univoche: un'entità univoca 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.
Modificare i mapping da ambito ad ambiente
Quando modifichi o rimuovi un mapping di ambiti, l'impatto dipende dal fatto che gli avvisi e le richieste siano nuovi o esistenti.
- Spostare un ambito: modifica del mapping di un ambito da Ambiente A a Ambiente B:
- Nuovi avvisi e nuove richieste: indirizzati a Ambiente B.
- Avvisi e richieste esistenti: rimangono in Ambiente A. Gli utenti possono accedervi se dispongono delle autorizzazioni sia per Ambiente A sia per l'ambito assegnato.
- Rimuovere un mapping di ambiti: annullamento del mapping di un ambito da un ambiente:
- Nuovi avvisi e nuove richieste: indirizzati all'ambiente di fallback. Visibili solo agli utenti globali e agli utenti con accesso all'ambiente di fallback.
- Avvisi e richieste esistenti: rimangono nel loro ambiente originale, ma diventano visibili solo agli utenti globali perché l'ambito non è più mappato.
Gestire le richieste manuali e di overflow
Questa sezione descrive come gestire le richieste create manualmente o derivanti dall'overflow degli 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. La richiesta e l'avviso manuale ereditano l'ambito selezionato.
Richieste di overflow
Le richieste di overflow raggruppano gli avvisi in più ambiti senza seguire il modello di entità condivisa. 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 dell'elenco delle richieste
Puoi anche visualizzare gli ambiti direttamente dalla tabella dell'elenco delle richieste:
- Nella tabella dell'elenco delle 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 alle richieste 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 dal mapping 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 hanno ancora l'attestazione del token memorizzata nella cache) potranno accedere a queste richieste e a questi avvisi storici.
Risoluzione dei problemi
Questa sezione illustra le aspettative di rendimento e fornisce soluzioni self-service per i problemi di deployment comuni.
Latenza e limiti
La propagazione delle modifiche ai mapping da ambito ad ambiente o l'abilitazione iniziale può 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.