In questo argomento viene descritto come configurare le autorizzazioni di Identity and Access Management per una serie di scenari di controllo di esempio. Fornisce indicazioni su quali ruoli IAM concedere ai ruoli funzionali relativi all'auditing della tua azienda per ciascun scenario. Gli esempi in questo argomento sono rivolti principalmente ad amministratori, revisori e dipendenti della sicurezza che gestiscono attività di controllo per un'organizzazione.
Per informazioni sugli audit log per Google Cloud, consulta Audit log di Cloud. Per informazioni sugli audit log generati da IAM, consulta Audit logging IAM per gli account di servizio.
Scenario: monitoraggio operativo
In questo scenario, un'organizzazione ha un team di sicurezza centrale in grado di esaminare i log che possono contenere informazioni sensibili sia in Cloud Logging sia quando sono archiviati in uno spazio di archiviazione a lungo termine.
I dati di controllo storici sono archiviati in Cloud Storage. L'organizzazione utilizza un'applicazione per fornire l'accesso ai dati di controllo storici. L'applicazione utilizza un account di servizio per accedere ai dati di log. A causa della sensibilità di alcuni dei dati degli audit log, vengono oscurati utilizzando Sensitive Data Protection prima di essere resi accessibili per la visualizzazione.
La tabella seguente illustra i ruoli IAM che devono essere concessi al CTO, al team di sicurezza e all'account di servizio, nonché il livello di risorsa a cui vengono concessi i ruoli.
| Ruolo | Risorsa | Entità | Descrizione |
|---|---|---|---|
| resourcemanager.organizationAdmin | organizzazione | CTO | Il ruolo resourcemanager.organizationAdmin consente al CTO di assegnare le autorizzazioni al team di sicurezza e all'account di servizio. |
| logging.viewer | organizzazione | Team addetto alla sicurezza | Il ruolo logging.viewer consente al team di amministrazione della sicurezza di visualizzare i log delle attività di amministrazione. |
| logging.privateLogViewer | organizzazione | Team addetto alla sicurezza | Il ruolo logging.privateLogViewer consente di visualizzare i log di accesso ai dati. |
Una volta esportate le voci di log, l'accesso alle copie esportate è interamente controllato dalle autorizzazioni e dai ruoli IAM su qualsiasi destinazione: Cloud Storage, BigQuery o Pub/Sub. In questo scenario, Cloud Storage è la destinazione per l'archiviazione a lungo termine degli audit log.
| Ruolo | Risorsa | Entità | Descrizione |
|---|---|---|---|
| logging.viewer | organizzazione | Account di servizio | Il ruolo logging.viewer consente all'account di servizio di leggere i log delle attività di amministrazione in Cloud Logging. |
I dati nei log di accesso ai dati sono considerati informazioni che consentono l'identificazione personale (PII) per questa organizzazione. L'integrazione dell'applicazione con Sensitive Data Protection consente di oscurare i dati PII sensibili durante la visualizzazione dei log di accesso ai dati sia che si trovino nei log di accesso ai dati o nell'archivio storico in Cloud Storage.
| Ruolo | Risorsa | Entità | Descrizione |
|---|---|---|---|
| storage.objectViewer | Bucket | Account di servizio | Il ruolo storage.objectViewer consente all'account di servizio di leggere i log delle attività di amministrazione esportati. |
Il criterio di autorizzazione associato alla risorsa dell'organizzazione per questo scenario sarà simile al seguente:
{
"bindings": [{
"role": "roles/resourcemanager.organizationAdmin",
"members": [
"user:cto@example.com"
]
},
{
"role": "roles/logging.viewer",
"members": [
"group:security-team@example.com",
"serviceAccount:prod-logviewer@admin-resources.iam.gserviceaccount.com"
]
},
{
"role": "roles/logging.privateLogViewer",
"members": [
"group:security-team@example.com"
]
}
]
}
Il criterio di autorizzazione associato al bucket configurato come sink di destinazione per questo scenario sarà simile al seguente:
{
"bindings": [{
"role": "roles/storage.objectViewer",
"members": [
"serviceAccount:prod-logviewer@admin-resources.iam.gserviceaccount.com"
]
}]
}
Scenario: team di sviluppo che monitorano i propri audit log
In questo scenario, gli sviluppatori dell'organizzazione devono esaminare gli audit log generati durante lo sviluppo delle applicazioni. Non possono esaminare i log di produzione, a meno che non siano stati oscurati mediante Sensitive Data Protection. Per gli sviluppatori è disponibile un'applicazione dashboard che fornisce accesso di sola visualizzazione ai dati di produzione esportati. Il team di sicurezza dell'organizzazione ha accesso a tutti i log, sia in produzione che nell'ambiente di sviluppo.
La tabella seguente illustra i ruoli IAM che devono essere concessi al team di sicurezza, agli sviluppatori e all'account di servizio, nonché il livello delle risorse a cui vengono concessi i ruoli.
| Ruolo | Risorsa | Entità | Descrizione |
|---|---|---|---|
| logging.viewer | organizzazione | Team addetto alla sicurezza | Il ruolo logging.viewer consente al team di amministrazione della sicurezza di visualizzare i log delle attività di amministrazione. |
| logging.privateLogViewer | organizzazione | Team addetto alla sicurezza | Il ruolo logging.privateLogViewer consente di visualizzare i log di accesso ai dati. |
| logging.viewer | cartella | Team di sviluppo | Il ruolo logging.viewer consente al team di sviluppatori di visualizzare i log delle attività di amministrazione generati dai progetti sviluppatore contenuti in una cartella in cui si trovano tutti i progetti sviluppatore. |
| logging.privateLogViewer | cartella | Team di sviluppatori | Il ruolo logging.privateLogViewer consente di visualizzare i log di accesso ai dati. |
L'accesso alle copie esportate è interamente controllato dalle autorizzazioni e dai ruoli IAM su qualsiasi destinazione: Cloud Storage, BigQuery o Pub/Sub. In questo scenario, BigQuery è la destinazione per l'archiviazione degli audit log.
| Ruolo | Risorsa | Entità | Descrizione |
|---|---|---|---|
| bigquery.dataViewer | Set di dati BigQuery | Account di servizio della dashboard | Il ruolo bigquery.dataViewer consente all'account di servizio utilizzato dall'applicazione dashboard di leggere i log dell'attività di amministrazione esportati. |
Il criterio di autorizzazione associato alla risorsa cartella del team di sviluppo per questo scenario sarà simile al seguente:
{
"bindings": [{
"role": "roles/logging.viewer",
"members": [
"group:developer-team@example.com"
]
},
{
"role": "roles/logging.privateLogViewer",
"members": [
"group:developer-team@example.com"
]
}]
}
Il criterio di autorizzazione associato alla risorsa dell'organizzazione per questo scenario sarà simile al seguente:
{
"bindings": [{
"role": "roles/logging.viewer",
"members": [
"group:security-team@example.com"
]
},
{
"role": "roles/logging.privateLogViewer",
"members": [
"group:security-team@example.com"
]
}]
}
Il criterio di autorizzazione associato al set di dati BigQuery configurato come sink di destinazione per questo scenario sarà simile al seguente:
{
"bindings": [{
"role": "roles/bigquery.dataViewer",
"members": [
"serviceAccount:prod-project-dashboard@admin-resources.iam.gserviceaccount.com"
]
}]
}
Scenario: revisori esterni
In questo scenario, gli audit log per un'organizzazione vengono aggregati ed esportati in un sink centrale. A un revisore di terze parti viene concesso l'accesso più volte all'anno per esaminare gli audit log dell'organizzazione. Il revisore non è autorizzato a visualizzare i dati PII nei log delle attività di amministrazione. Per rispettare questo requisito, è disponibile una dashboard che fornisce l'accesso ai log storici archiviati in BigQuery e, su richiesta, ai log delle attività di amministrazione di Cloud Logging.
L'organizzazione crea un gruppo Google per i revisori esterni e aggiunge al gruppo il revisore corrente. Questo gruppo è monitorato e in genere riceve l'accesso all'applicazione dashboard.
Durante il normale accesso, al gruppo Google degli revisori viene concesso l'accesso solo per visualizzare i log storici archiviati in BigQuery. Se vengono rilevate eventuali anomalie, al gruppo viene concessa l'autorizzazione per visualizzare i log effettivi delle attività di amministrazione di Cloud Logging tramite la modalità di accesso con elevato livello della dashboard. Al termine di ogni periodo di controllo, l'accesso del gruppo viene revocato.
I dati vengono oscurati utilizzando Sensitive Data Protection prima di essere resi accessibili per la visualizzazione tramite l'applicazione dashboard.
La tabella seguente illustra i ruoli di logging IAM che un Amministratore organizzazione può concedere all'account di servizio utilizzato dalla dashboard, nonché il livello di risorsa a cui viene concesso il ruolo.
| Ruolo | Risorsa | Entità | Descrizione |
|---|---|---|---|
| logging.viewer | organizzazione | Account di servizio della dashboard | Il ruolo logging.viewer consente all'account di servizio di leggere i log delle attività di amministrazione in Cloud Logging. |
| bigquery.dataViewer | Set di dati BigQuery | Account di servizio della dashboard | Il ruolo bigquery.dataViewer consente all'account di servizio utilizzato dall'applicazione dashboard di leggere i log dell'attività di amministrazione esportati. |
Il criterio di autorizzazione associato alla risorsa Organizzazione per questo scenario sarà simile al seguente:
{
"bindings": [{
"role": "roles/logging.viewer",
"members": [
"serviceAccount:prod-project-dashboard@admin-resources.iam.gserviceaccount.com"
]
}]
}
Il criterio di autorizzazione associato al set di dati BigQuery configurato come sink di destinazione per questo scenario sarà simile al seguente:
{
"bindings": [{
"role": "roles/bigquery.dataViewer",
"members": [
"serviceAccount:prod-project-dashboard@admin-resources.iam.gserviceaccount.com"
]
}]
}