Panoramica di RBAC per i dati
Il controllo degli accessi basato sui ruoli per i dati (RBAC dei dati) è un modello di sicurezza che utilizza i ruoli utente individuali per limitare l'accesso degli utenti ai dati all'interno di un'organizzazione. Con il controllo degli accessi basato sui ruoli (RBAC) dei dati, gli amministratori possono definire ambiti e assegnarli agli utenti per garantire che questi possano accedere solo ai dati necessari per le loro funzioni lavorative.
Questa pagina fornisce una panoramica del controllo dell'accesso basato sui ruoli per i dati e ti aiuta a capire come le etichette e gli ambiti interagiscono per definire le autorizzazioni di accesso ai dati.
Differenza tra RBAC dei dati e RBAC delle funzionalità
RBAC per i dati e RBAC per le funzionalità sono entrambi metodi per controllare l'accesso all'interno di un sistema, ma si concentrano su aspetti diversi.
Il controllo dell'accesso basato sui ruoli (RBAC) delle funzionalità controlla l'accesso a funzionalità specifiche all'interno di un sistema. Determina quali funzionalità sono accessibili agli utenti in base ai loro ruoli. Ad esempio, un analista junior potrebbe avere accesso solo alla visualizzazione delle dashboard, ma non alla creazione o alla modifica delle regole di rilevamento, mentre un analista senior potrebbe disporre delle autorizzazioni per creare e gestire le regole di rilevamento. Per saperne di più su RBAC delle funzionalità, consulta Configurare il controllo dell'accesso alle funzionalità utilizzando IAM.
RBAC per i dati controlla l'accesso a dati o informazioni specifici all'interno di un sistema. Determina se un utente può visualizzare, modificare o eliminare i dati in base ai suoi ruoli. Ad esempio, in un sistema di gestione dei rapporti con i clienti (CRM), un rappresentante di vendita potrebbe avere accesso ai dati di contatto dei clienti, ma non ai dati finanziari, mentre un responsabile finanziario potrebbe avere accesso ai dati finanziari, ma non ai dati di contatto dei clienti.
RBAC per i dati e RBAC per le funzionalità vengono spesso utilizzati insieme per fornire un sistema di controllo dell'accesso completo. Ad esempio, a un utente potrebbe essere consentito di accedere a una funzionalità specifica (RBAC delle funzionalità) e poi, all'interno di questa funzionalità, il suo accesso a dati specifici potrebbe essere limitato in base al suo ruolo (RBAC dei dati).
Pianificare l'implementazione
Per pianificare l'implementazione, esamina l'elenco dei ruoli e delle autorizzazioni predefiniti di Google SecOps e allineali alle esigenze della tua organizzazione. Elabora una strategia per definire gli ambiti
ed etichettare i dati in entrata. Assicurati di disporre del ruolo
Visualizzatore ruoli (roles/iam.roleViewer
) per gestire gli ambiti.
Identifica i membri che devono avere accesso ai dati all'interno di questi ambiti.
Se la tua organizzazione richiede criteri IAM oltre ai ruoli Google SecOps predefiniti, crea ruoli personalizzati per supportare requisiti specifici.
Ruoli utente
Gli utenti possono disporre dell'accesso ai dati con ambito (utenti con ambito) o dell'accesso globale ai dati (utenti globali).
Gli utenti con ambito hanno accesso limitato ai dati in base agli ambiti assegnati. Questi ambiti limitano la visibilità e le azioni a dati specifici. Le autorizzazioni specifiche associate all'accesso con ambito sono descritte in dettaglio nella tabella seguente.
Gli utenti globali non hanno ambiti assegnati e hanno accesso illimitato a tutti i dati all'interno di Google SecOps. Le autorizzazioni specifiche associate all'accesso globale sono descritte in dettaglio nella tabella seguente.
L'accesso globale sostituisce l'accesso con ambito. Se a un utente vengono assegnati sia un ruolo globale sia un ruolo con ambito, l'utente ha accesso a tutti i dati, indipendentemente dalle restrizioni imposte dal ruolo con ambito.
Gli amministratori RBAC dei dati possono creare ambiti e assegnarli agli utenti per controllare
il loro accesso ai dati all'interno di Google SecOps. Per limitare un utente a determinati
ambiti, devi assegnargli il ruolo Chronicle API Restricted Data Access
(roles/chronicle.restrictedDataAccess
) insieme
a un ruolo predefinito o personalizzato. Il ruolo Chronicle API Restricted Data Access
identifica un utente come utente con ambito. Non è necessario assegnare il ruolo Accesso limitato ai dati di Chronicle agli utenti che hanno bisogno dell'accesso globale ai dati.
Agli utenti possono essere assegnati i seguenti ruoli:
Tipo di accesso | Ruoli | Autorizzazioni |
---|---|---|
Accesso globale predefinito | Agli utenti globali può essere concesso uno qualsiasi dei ruoli IAM predefiniti. | |
Accesso di sola lettura con ambito predefinito | Chronicle API Restricted Data Access (roles/chronicle.restrictedDataAccess ) e Chronicle API Restricted Data Access Viewer (roles/chronicle.restrictedDataAccessViewer )
|
Chronicle API Restricted Data Access Viewer |
Accesso con ambito personalizzato | Chronicle API Restricted Data Access (roles/chronicle.restrictedDataAccess ) e ruolo personalizzato (per la definizione RBAC della funzionalità)
|
Autorizzazioni personalizzate all'interno delle funzionalità |
Accesso globale personalizzato | Autorizzazione chronicle.globalDataAccessScopes.permit e Chronicle API Global Data Access (roles/globalDataAccess )
|
Autorizzazioni globali all'interno delle funzionalità |
Di seguito è riportata una descrizione di ciascun tipo di accesso presentato nella tabella:
Accesso globale predefinito:questo accesso è in genere richiesto per gli utenti che devono accedere a tutti i dati. Puoi assegnare uno o più ruoli a un utente in base alle autorizzazioni richieste.
Accesso di sola lettura con ambito predefinito: questo accesso è per gli utenti che necessitano dell'accesso di sola lettura. Il ruolo Chronicle API Restricted Data Access identifica un utente come utente con ambito. Il ruolo Chronicle API Restricted Data Access Viewer consente agli utenti di visualizzare l'accesso all'interno delle loro funzionalità.
Accesso con ambito personalizzato:il ruolo Chronicle API Restricted Data Access identifica un utente come utente con ambito. Il ruolo personalizzato specifica le funzionalità a cui l'utente può accedere. Gli ambiti aggiunti al ruolo Chronicle API Restricted Data Access specificano i dati a cui gli utenti possono accedere nelle funzionalità.
Per verificare che gli ambiti personalizzati RBAC funzionino correttamente, includi l'autorizzazione chronicle.dataAccessScopes.list
quando crei i ruoli personalizzati. Tuttavia, non includere le autorizzazionichronicle.DataAccessScopes.permit
o chronicle.globalDataAccessScopes.permit
. Queste autorizzazioni potrebbero essere incluse
se hai utilizzato l'editor API Chronicle o l'amministratore API Chronicle predefiniti come
punto di partenza per i tuoi ruoli personalizzati.
Accesso globale personalizzato: questo accesso è per gli utenti che necessitano di autorizzazioni illimitate all'interno delle funzionalità assegnate. Per concedere l'accesso globale personalizzato a un
utente, devi specificare l'autorizzazione chronicle.globalDataAccessScopes.permit
oltre al ruolo personalizzato assegnato all'utente.
Controllo dell'accesso con ambiti ed etichette
Google SecOps ti consente di controllare l'accesso ai dati per gli utenti utilizzando gli ambiti. Gli ambiti vengono definiti con l'aiuto di etichette che definiscono i dati a cui un utente all'interno dell'ambito ha accesso. Durante l'importazione, i metadati vengono assegnati ai dati sotto forma di etichette come spazio dei nomi (facoltativo), metadati di importazione (facoltativi) e tipo di log (obbligatorio). Queste sono etichette predefinite che vengono applicate ai dati durante l'importazione. Inoltre, puoi creare etichette personalizzate. Puoi utilizzare etichette predefinite e personalizzate per definire gli ambiti e il livello di accesso ai dati che definiranno gli ambiti.
Visibilità dei dati con etichette di autorizzazione e negazione
Ogni ambito contiene una o più etichette Consenti accesso e, facoltativamente, etichette Nega accesso. Le etichette di accesso consentono agli utenti di accedere ai dati associati all'etichetta. Le etichette di negazione dell'accesso impediscono agli utenti di accedere ai dati associati all'etichetta. Le etichette di negazione dell'accesso sostituiscono le etichette di autorizzazione dell'accesso nel limitare l'accesso utente.
In una definizione di ambito, le etichette di accesso dello stesso tipo (ad esempio, tipo di log) vengono combinate utilizzando l'operatore OR, mentre le etichette di tipi diversi (ad esempio, tipo di log e un'etichetta personalizzata) vengono combinate utilizzando l'operatore AND. Le etichette di negazione dell'accesso vengono combinate utilizzando l'operatore OR. Quando vengono applicate più etichette Nega accesso all'interno di un ambito, l'accesso viene negato se corrispondono a UNA QUALSIASI di queste etichette.
Ad esempio, considera un sistema Cloud Logging che classifica i log utilizzando i seguenti tipi di etichette:
Tipo di log:Accesso, Sistema, Firewall
Spazio dei nomi: App1, App2, Database
Gravità: critica, avviso
Prendi in considerazione un ambito denominato Log limitati con il seguente accesso:
Tipo di etichetta | Valori consentiti | Valori negati |
---|---|---|
Tipo di log | Accesso, Firewall | Sistema |
Spazio dei nomi | App1 | App2, Database |
Gravità | Avviso | Critico |
La definizione dell'ambito ha il seguente aspetto:
Consenti: (Log type: "Access" OR "Firewall") AND (Namespace: "App1") AND (Severity: "Warning")
Rifiuta:Log type: "System" OR Namespace: App2 OR Namespace: Database OR Severity: "Critical"
Esempi di log che corrispondono all'ambito:
- Log di accesso da App1 con gravità: Avviso
- Log del firewall di App1 con gravità: Avviso
Esempi di log che non corrispondono all'ambito:
- Log di sistema di App1 con gravità: Avviso
- Log di accesso dal database con gravità: Avviso
- Log del firewall di App2 con gravità: critica
Visibilità dei dati negli eventi avanzati
Gli eventi arricchiti sono eventi di sicurezza che sono stati migliorati con contesto e informazioni aggiuntivi rispetto a quelli contenuti nei dati dei log non elaborati. Gli eventi arricchiti sono accessibili in un ambito solo se l'evento di base è accessibile nell'ambito e nessuna delle etichette arricchite include una delle etichette di negazione dell'ambito.
Ad esempio, considera un log non elaborato che indica un tentativo di accesso non riuscito da un indirizzo IP e ha un'etichetta arricchita user_risk: high
(indica un utente ad alto rischio).
Un utente con un ambito che ha l'etichetta di negazione user_risk: high
non può visualizzare i tentativi di accesso non riusciti da parte di utenti ad alto rischio.
Impatto del controllo dell'accesso basato sui ruoli per i dati sulle funzionalità di Google Security Operations
Una volta configurato l'RBAC dei dati, gli utenti iniziano a visualizzare i dati filtrati nelle funzionalità di Google Security Operations. L'impatto dipende da come la funzionalità è integrata con i dati sottostanti. Per capire in che modo il controllo dell'accesso basato sui ruoli ai dati influisce su ogni funzionalità, consulta la pagina Impatto del controllo dell'accesso basato sui ruoli ai dati sulle funzionalità di Google Security Operations.
Passaggi successivi
Hai bisogno di ulteriore assistenza? Ricevi risposte dai membri della community e dai professionisti di Google SecOps.