Questo argomento descrive come configurare le autorizzazioni Identity and Access Management per una serie di scenari di controllo di esempio. Fornisce indicazioni su quali ruoli IAM concedere ai ruoli funzionali relativi al controllo della tua azienda in diversi scenari. Gli esempi in questo argomento sono principalmente rivolti agli amministratori della sicurezza, ai revisori e ai dipendenti che gestiscono le attività di controllo per un'organizzazione.
Per informazioni sui log di controllo per Google Cloud, vedi Audit log di Cloud. Per scoprire di più sui log di controllo generati da IAM, consulta Audit logging IAM per i service account.
Scenario: monitoraggio operativo
In questo scenario, un'organizzazione ha un team di sicurezza centrale che ha la possibilità di esaminare i log che potrebbero contenere informazioni sensibili sia in Cloud Logging sia quando vengono archiviati in un archivio a lungo termine.
I dati di controllo storici vengono archiviati in Cloud Storage. L'organizzazione utilizza un'applicazione per fornire l'accesso ai dati di audit storici. L'applicazione utilizza unaccount di serviziot per accedere ai dati di log. A causa della sensibilità di alcuni dati dei log audit, questi vengono oscurati utilizzando la protezione dei dati sensibili prima di essere resi accessibili per la visualizzazione.
La tabella riportata di seguito illustra i ruoli IAM che devono essere concessi al CTO, al team di sicurezza e al 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 autorizzazioni al team di sicurezza e al account di servizio. |
| logging.viewer | Organizzazione | Team di sicurezza | Il ruolo logging.viewer consente al team di amministratori della sicurezza di visualizzare i log delle attività di amministrazione. |
| logging.privateLogViewer | Organizzazione | Team di 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 è controllato interamente da ruoli e autorizzazioni IAM in una qualsiasi delle destinazioni: 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 | Service account | Il ruolo logging.viewer consente al account di servizio di leggere i log attività amministratore 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 quando si visualizzano i log di accesso ai dati, indipendentemente dal fatto che si trovino nei log di accesso ai dati o nell'archivio storico in Cloud Storage.
| Ruolo | Risorsa | Entità | Descrizione |
|---|---|---|---|
| storage.objectViewer | Bucket | Service account | Il ruolo storage.objectViewer consente al account di servizio di leggere i log attività amministratore esportati. |
Il criterio di autorizzazione associato alla risorsa 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 loro applicazioni. Non è consentito esaminare i log di produzione a meno che non siano stati oscurati utilizzando Sensitive Data Protection. Per gli sviluppatori è disponibile un'applicazione dashboard che fornisce l'accesso in sola visualizzazione ai dati di produzione esportati. Il team di sicurezza dell'organizzazione ha accesso a tutti i log sia in produzione sia nell'ambiente di sviluppo.
La tabella seguente illustra i ruoli IAM che devono essere concessi al team di sicurezza, agli sviluppatori e al account di servizio, nonché il livello di risorsa a cui vengono concessi i ruoli.
| Ruolo | Risorsa | Entità | Descrizione |
|---|---|---|---|
| logging.viewer | Organizzazione | Team di sicurezza | Il ruolo logging.viewer consente al team di amministratori della sicurezza di visualizzare i log delle attività di amministrazione. |
| logging.privateLogViewer | Organizzazione | Team di 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 attività di amministrazione generati dai progetti per sviluppatori contenuti in una cartella in cui si trovano tutti i progetti per sviluppatori. |
| logging.privateLogViewer | Cartella | Team di sviluppo | Il ruolo logging.privateLogViewer consente di visualizzare i log di accesso ai dati. |
L'accesso alle copie esportate è controllato interamente da ruoli e autorizzazioni IAM in una qualsiasi delle destinazioni: 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 del servizio dashboard | Il ruolo bigquery.dataViewer consente all'account di servizio utilizzato dall'applicazione della dashboard di leggere i log delle 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 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 di un'organizzazione vengono aggregati ed esportati in una posizione centrale del sink. A un revisore di terze parti viene concesso l'accesso più volte all'anno per esaminare i log di controllo dell'organizzazione. L'auditor non è autorizzato a visualizzare i dati PII nei log 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 per questi revisori esterni e aggiunge il revisore attuale al gruppo. Questo gruppo viene monitorato e in genere gli viene concesso l'accesso all'applicazione della dashboard.
Durante l'accesso normale, al gruppo di revisori viene concesso l'accesso solo per visualizzare i log storici archiviati in BigQuery. Se vengono rilevate anomalie, al gruppo viene concessa l'autorizzazione per visualizzare i log di attività di amministrazione di Cloud Logging effettivi tramite la modalità di accesso con privilegi elevati 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 della dashboard.
La tabella riportata di seguito illustra i ruoli di logging IAM che un Amministratore organizzazione può concedere al account di servizio utilizzato dal dashboard, nonché il livello di risorsa a cui viene concesso il ruolo.
| Ruolo | Risorsa | Entità | Descrizione |
|---|---|---|---|
| logging.viewer | Organizzazione | Account di servizio del servizio dashboard | Il ruolo logging.viewer consente al account di servizio di leggere i log attività amministratore in Cloud Logging. |
| bigquery.dataViewer | Set di dati BigQuery | Account di servizio del servizio dashboard | Il ruolo bigquery.dataViewer consente all'account di servizio utilizzato dall'applicazione della dashboard di leggere i log delle 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"
]
}]
}