Panoramica di Data RBAC

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

Questa pagina fornisce una panoramica dell'RBAC dei dati e spiega come le etichette e gli ambiti interagiscono per definire le autorizzazioni di accesso ai dati.

Differenza tra RBAC dei dati e RBAC delle funzionalità

Data RBAC e Feature RBAC sono entrambi metodi per controllare l'accesso all'interno di un sistema, ma si concentrano su aspetti diversi.

RBAC delle funzionalità controlla l'accesso a caratteristiche 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 per visualizzare le dashboard, ma non per creare o modificare le regole di rilevamento, mentre un analista senior potrebbe avere le autorizzazioni per creare e gestire le regole di rilevamento. Per ulteriori informazioni su RBAC alle funzionalità, consulta Configurare il controllo dell'accesso alle funzionalità utilizzando IAM.

Data RBAC 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 a quelli finanziari, mentre un responsabile finanziario potrebbe avere accesso ai dati finanziari, ma non a quelli di contatto dei clienti.

Data RBAC e feature RBAC vengono spesso utilizzati insieme per fornire un sistema di controllo dell'accesso completo. Ad esempio, un utente potrebbe essere autorizzato ad accedere a una funzionalità specifica (RBAC della funzionalità) e quindi, all'interno di questa funzionalità, l'accesso a dati specifici potrebbe essere limitato in base al suo ruolo (RBAC dei dati).

Pianifica l'implementazione

Per pianificare l'implementazione, consulta l'elenco di ruoli e autorizzazioni predefiniti di Google SecOps in base ai requisiti della tua organizzazione. Definisci una strategia per definire gli ambiti necessari alla tua organizzazione e per etichettare i dati in arrivo. Identificare quali membri dell'organizzazione devono avere accesso ai dati associati a questi ambiti. Se la tua organizzazione richiede criteri IAM diversi dai ruoli predefiniti di Google SecOps, crea ruoli personalizzati per supportare questi requisiti.

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 loro visibilità e le loro 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 senza restrizioni a tutti i dati all'interno di Google SecOps. Le autorizzazioni specifiche associate all'accesso globale sono dettagliate nella tabella seguente.

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

I seguenti ruoli possono essere assegnati agli utenti:

Tipo di accesso Ruoli Autorizzazioni
Accesso globale predefinito Agli utenti globali può essere concesso qualsiasi ruolo IAM predefinito.
Accesso di sola lettura con ambito predefinito Accesso limitato ai dati dell'API Chronicle (roles/chronicle.restrictedDataAccess) e Visualizzatore dell'accesso limitato ai dati dell'API Chronicle (roles/chronicle.restrictedDataAccessViewer) Visualizzatore accesso limitato ai dati API Chronicle
Accesso con ambito personalizzato Accesso limitato ai dati dell'API Chronicle (roles/chronicle.restrictedDataAccess) e ruolo personalizzato Autorizzazioni personalizzate all'interno delle funzionalità
Accesso globale personalizzato Autorizzazione chronicle.globalDataAccessScopes.permit e ruolo personalizzato Autorizzazioni globali all'interno delle funzionalità

Di seguito è riportata una descrizione di ogni tipo di accesso presentato nella tabella:

Accesso globale predefinito:questo accesso è in genere obbligatorio 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 devono accedere in sola lettura. Il ruolo Accesso limitato ai dati dell'API Chronicle identifica un utente come utente con ambito. Il ruolo Visualizzatore accesso limitato ai dati dell'API Chronicle concede l'accesso in visualizzazione agli utenti all'interno delle loro funzionalità.

Accesso con ambito personalizzato:il ruolo di accesso limitato ai dati 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 di accesso limitato ai dati dell'API Chronicle specificano i dati a cui gli utenti possono accedere nelle funzionalità.

Accesso globale personalizzato: questo accesso è per gli utenti che hanno bisogno di autorizzazioni senza restrizioni 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 ha accesso un utente all'interno dell'ambito. Durante l'importazione, i metadati vengono assegnati ai dati sotto forma di etichette, ad esempio 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 di autorizzazione e negazione

Ogni ambito contiene una o più etichette allow access e, facoltativamente, nega accesso. Le etichette di accesso consentono agli utenti di accedere ai dati associati all'etichetta. Le etichette di negazione dell'accesso negano agli utenti l'accesso ai dati associati all'etichetta. Le etichette di negazione dell'accesso sostituiscono le etichette di Consenti accesso nella limitazione dell'accesso utente.

In una definizione di ambito, le etichette di accesso consentite 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 ed etichetta personalizzata) vengono combinate utilizzando l'operatore AND. Le etichette di negazione dell'accesso vengono combinate utilizzando l'operatore OR. Quando più etichette di negazione dell'accesso vengono applicate all'interno di un ambito, l'accesso viene negato se corrispondono a una 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

Considera un ambito chiamato Log con restrizioni 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 è simile alla seguente:

Consenti: (Log type: "Access" OR "Firewall") AND (Namespace: "App1") AND (Severity: "Warning")

Nega: Log type: "System" OR Namespace: App2 OR Namespace: Database OR Severity: "Critical"

Esempi di log corrispondenti all'ambito:

  • Log di accesso da App1 con gravità: avviso
  • Log firewall da App1 con gravità: avviso

Esempi di log non corrispondenti all'ambito:

  • Registro di sistema da App1 con gravità: avviso
  • Accedi al log dal database con gravità: avviso
  • Log firewall da App2 con gravità: critica

Visibilità dei dati negli eventi estesi

Gli eventi estesi sono eventi di sicurezza che sono stati migliorati con contesto e informazioni aggiuntivi oltre a quelli contenuti nei dati di log non elaborati. Gli eventi estesi sono accessibili all'interno di un ambito solo se il relativo evento di base è accessibile all'interno dell'ambito e nessuna delle etichette arricchite non include nessuna delle etichette di negazione dell'ambito.

Considera ad esempio 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 con l'etichetta di negazione user_risk: high non può vedere i tentativi di accesso non riusciti da parte di utenti ad alto rischio.

Impatto dei dati RBAC sulle funzionalità di Google Security Operations

Dopo aver configurato 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 comprendere in che modo RBAC dei dati influisce su ciascuna funzionalità, consulta Impatto dei dati delle funzionalità di RBAC di Google Security Operations.

Passaggi successivi