Panoramica del RBAC dei dati

Supportato in:

Il controllo degli accessi basato su ruoli dei dati (RBAC dei dati) è un modello di sicurezza che utilizza i singoli ruoli utente per limitare l'accesso degli utenti ai dati all'interno di un'organizzazione. Con il RBAC dei dati, gli amministratori possono definire gli ambiti e assegnarli agli utenti per contribuire ad assicurarsi che possano accedere solo ai dati necessari per le loro funzioni lavorative.

Questa pagina fornisce una panoramica del RBAC dei dati e ti aiuta a capire in che modo le etichette e gli ambiti interagiscono per definire le autorizzazioni di accesso ai dati.

Differenza tra RBAC dei dati e RBAC delle funzionalità

Il controllo dell'accesso basato sui dati e il controllo dell'accesso basato sulle funzionalità sono entrambi metodi per controllare l'accesso all'interno di un sistema, ma si concentrano su aspetti diversi.

Il RBAC delle funzionalità controlla l'accesso a funzionalità o 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 ulteriori informazioni sul RBAC delle funzionalità, consulta Configurare il controllo dell'accesso alle funzionalità utilizzando IAM.

Il RBAC dei dati controlla l'accesso a dati o informazioni specifici all'interno di un sistema. Controlla 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.

I controlli RBAC dei dati e delle funzionalità vengono spesso utilizzati insieme per fornire un sistema di controllo dell'accesso completo. Ad esempio, un utente potrebbe avere l'autorizzazione ad accedere a una funzionalità specifica (RBAC per funzionalità) e, all'interno di questa funzionalità, il suo accesso a dati specifici potrebbe essere limitato in base al suo ruolo (RBAC per i dati).

Pianifica l'implementazione

Per pianificare l'implementazione, esamina l'elenco dei ruoli e delle autorizzazioni di Google SecOps predefinite in base ai requisiti della tua organizzazione. Elabora una strategia per definire gli ambiti di cui necessita la tua organizzazione ed etichettare i dati in entrata. Identifica i membri della tua organizzazione che devono avere accesso ai dati associati a questi ambiti. Se la tua organizzazione richiede criteri IAM diversi dai ruoli di SecOps di Google predefiniti, crea ruoli personalizzati per supportare questi requisiti.

Ruoli utente

Gli utenti possono avere accesso ai dati con ambito (utenti con ambito) o accesso ai dati globale (utenti globali).

  • Gli utenti con ambito hanno accesso limitato ai dati in base agli ambiti assegnati. Questi ambiti limitano la loro visibilità e le loro azioni a dati specifici. Le autorizzazioni specifiche associate all'accesso limitato sono descritte 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 nella tabella seguente.

L'accesso globale ha la precedenza sull'accesso limitato. Se a un utente vengono assegnati sia un ruolo globale sia un ruolo basato su ambito, ha accesso a tutti i dati, indipendentemente dalle limitazioni imposte dal ruolo basato su ambito.

Gli amministratori RBAC dei dati possono creare ambiti e assegnarli agli utenti per controllare il loro accesso ai dati in Google SecOps. Per limitare un utente a determinati ambiti, devi assegnargli il ruolo Accesso ai dati con limitazioni dell'API Chronicle (roles/chronicle.restrictedDataAccess) insieme a un ruolo predefinito o personalizzato. Il ruolo Accesso ai dati con limitazioni dell'API Chronicle identifica un utente come utente con ambito. Non è necessario assegnare il ruolo Accesso ai dati con limitazioni di Chronicle agli utenti che richiedono l'accesso globale ai dati.

È possibile assegnare agli utenti i seguenti ruoli:

Tipo di accesso Ruoli Autorizzazioni
Accesso globale predefinito Agli utenti globali è possibile concedere uno dei ruoli IAM predefiniti.
Accesso di sola lettura con ambito predefinito Accesso ai dati con limitazioni dell'API Chronicle (roles/chronicle.restrictedDataAccess) e visualizzatore dell'accesso ai dati con limitazioni dell'API Chronicle (roles/chronicle.restrictedDataAccessViewer) Visualizzatore dell'accesso ai dati con limitazioni dell'API Chronicle
Accesso con ambito personalizzato Accesso ai dati con limitazioni dell'API Chronicle (roles/chronicle.restrictedDataAccess) e ruolo personalizzato (per la definizione del RBAC delle funzionalità) Autorizzazioni personalizzate all'interno delle funzionalità
Accesso globale personalizzato 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 mostrato 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 è destinato agli utenti che hanno bisogno di accesso di sola lettura. Il ruolo Accesso limitato ai dati dell'API Chronicle identifica un utente come utente con ambito. Il ruolo Chronicle API Restricted Data Access Viewer consente agli utenti di visualizzare gli elementi all'interno delle loro funzionalità.

Accesso con ambito personalizzato:il ruolo Accesso ai dati con limitazioni dell'API Chronicle identifica un utente come utente con ambito. Il ruolo personalizzato specifica le funzionalità a cui l'utente può accedere. Gli ambiti aggiunti al ruolo Accesso ai dati con limitazioni dell'API Chronicle specificano i dati a cui gli utenti possono accedere nelle funzionalità. Per assicurarti che gli ambiti personalizzati RBAC funzionino correttamente, non includere le autorizzazioni chronicle.DataAccessScopes.permit o chronicle.globalDataAccessScopes.permit quando crei i ruoli personalizzati. Queste autorizzazioni potrebbero essere incluse se hai utilizzato l'Editor dell'API Chronicle o l'Amministratore dell'API Chronicle predefiniti come punto di partenza per i tuoi ruoli personalizzati.

Accesso globale personalizzato:questo accesso è destinato agli utenti che richiedono autorizzazioni illimitate all'interno delle funzionalità assegnate. Per concedere un 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 degli 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 (facoltativo) e tipo di log (obbligatorio). Si tratta di etichette predefinite che vengono applicate ai dati durante l'importazione. Inoltre, puoi creare etichette personalizzate. Puoi utilizzare le etichette predefinite e personalizzate per definire gli ambiti e il livello di accesso ai dati che verranno definiti dagli ambiti.

Visibilità dei dati con etichette Consenti e Nega

Ogni ambito contiene una o più etichette Consenti accesso e, facoltativamente, Nega accesso. Le etichette di accesso consentito concedono agli utenti l'accesso ai dati associati all'etichetta. Le etichette di rifiuto dell'accesso negano agli utenti l'accesso ai dati associati all'etichetta. Le etichette di accesso negato sostituiscono le etichette di accesso consentito per limitare l'accesso utente.

In una definizione di ambito, le etichette di accesso consentite dello stesso tipo (ad es. tipo di log) vengono combinate utilizzando l'operatore OR, mentre le etichette di tipi diversi (ad es. tipo di log ed etichetta personalizzata) vengono combinate utilizzando l'operatore AND. Le etichette di accesso negato vengono combinate utilizzando l'operatore OR. Quando vengono applicati più indicatori di rifiuto dell'accesso all'interno di un ambito, l'accesso viene negato se corrisponde a UNO DI QUESTI indicatori.

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

Considera un ambito denominato Log con limitazioni che ha 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 corrispondenti all'ambito:

  • Accesso al log dall'app1 con gravità: avviso
  • Log del firewall di App1 con gravità: avviso

Esempi di log non corrispondenti all'ambito:

  • Log di sistema dell'app1 con gravità: avviso
  • Log di accesso dal database con gravità: avviso
  • Log del firewall da 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 quanto contenuto nei dati non elaborati dei log. Gli eventi arricchiti sono accessibili in un ambito solo se l'evento di base è accessibile nell'ambito e nessuna delle etichette arricchite include le etichette di rifiuto dell'ambito.

Ad esempio, prendiamo un log non elaborato che indica un tentativo di accesso non riuscito da un indirizzo IP e che ha un'etichetta arricchita user_risk: high (indica un utente ad alto rischio). Un utente con un ambito che ha l'etichetta di rifiuto user_risk: high non può vedere i tentativi di accesso non riusciti degli utenti ad alto rischio.

Impatto del RBAC dei dati sulle funzionalità di Google Security Operations

Dopo aver configurato il RBAC dei dati, gli utenti iniziano a vedere 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 RBAC dei dati influisce su ogni funzionalità, consulta Impatto del RBAC dei 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.