Questo argomento descrive come configurare le autorizzazioni di Identity and Access Management per una serie di scenari di controllo di esempio. Fornisce indicazioni su quali IAM ruoli da assegnare ai ruoli funzionali relativi all'auditing nella propria azienda per ciascun diversi scenari. Gli esempi su questo argomento sono rivolti principalmente alla sicurezza amministratori, revisori e dipendenti che gestiscono attività di controllo per dell'organizzazione.
Per scoprire di più sugli audit log per Google Cloud, consulta Cloud Audit Logs. Per informazioni sui log di controllo generati da IAM, consulta Audit logging per gli account di servizio IAM.
Scenario: monitoraggio operativo
In questo scenario, un’organizzazione ha un team di sicurezza centrale che di esaminare i log che potrebbero contenere informazioni sensibili sia in Cloud Logging e quando archiviato nello spazio di archiviazione a lungo termine.
I dati di audit storici vengono archiviati in Cloud Storage. L'organizzazione utilizza un un'applicazione per fornire l'accesso ai dati cronologici dei controlli. L'applicazione utilizza un account di servizio per accedere ai dati dei log. A causa della sensibilità di alcuni dei dati dei log di controllo, questi vengono oscurati utilizzando la protezione dei dati sensibili 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é la 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 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 della sicurezza | Il ruolo logging.privateLogViewer consente di visualizzare i log di accesso ai dati. |
Una volta esportate le voci di log, viene controllato l'accesso alle copie esportate interamente da autorizzazioni e ruoli IAM su qualsiasi di destinazione: Cloud Storage, BigQuery in 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 all'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, che si tratti di log di accesso ai dati o dell'archivio storico in Cloud Storage.
| Ruolo | Risorsa | Entità | Descrizione |
|---|---|---|---|
| storage.objectViewer | Bucket | Service account | Il ruolo storage.objectViewer consente all'account di servizio 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/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 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 sono autorizzati a esaminare i log di produzione, a meno che non siano stati oscurati utilizzando la protezione dei dati sensibili. R dashboard è disponibile per gli sviluppatori che forniscono 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é 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 della sicurezza | Il ruolo logging.privateLogViewer consente di visualizzare i log di accesso ai dati. |
| logging.viewer | Cartella | Team di sviluppatori | Il ruolo logging.viewer offre al team degli sviluppatori la possibilità di visualizzare i log delle attività di amministrazione generati dai progetti dello sviluppatore contenuti in una cartella in cui si trovano tutti i progetti dello 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 è controllato interamente da autorizzazioni e ruoli IAM su qualsiasi di destinazione: Cloud Storage, BigQuery in 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 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 della cartella del team di sviluppo per questo 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 avrà un aspetto 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 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 di un lavandino centrale. A un revisore di terze parti viene concesso l'accesso più volte per esaminare gli audit log dell'organizzazione. L'auditor non è autorizzato a visualizzare i dati PII nei log delle attività di amministrazione. Per soddisfare questo requisito, che fornisce accesso ai log storici archiviati BigQuery e, su richiesta, all'attività di amministrazione di Cloud Logging logaritmi.
L'organizzazione crea un gruppo Google per questi revisori esterni e aggiunge il revisore corrente al gruppo. Questo gruppo viene monitorato e in genere viene concesso accesso all'applicazione della dashboard.
Durante il normale accesso, Al gruppo Google è concesso soltanto l'accesso alla visualizzazione i log storici archiviati in BigQuery. Se esistono anomalie rilevato, al gruppo viene concessa l'autorizzazione per visualizzare l'attuale Cloud Logging Log delle attività di amministrazione tramite la modalità di accesso elevato della dashboard. Alla fine di ogni periodo di controllo, l'accesso al gruppo viene revocato.
I dati vengono oscurati utilizzando Sensitive Data Protection prima di essere resi accessibili a la visualizzazione tramite l'applicazione dashboard.
La tabella riportata di seguito 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 Dashboard | Il ruolo logging.viewer consente all'account di servizio di leggere i log Attività amministratore in Cloud Logging. |
| bigquery.dataViewer | Set di dati BigQuery | Account di servizio Dashboard | Il ruolo bigquery.dataViewer consente all'account di servizio utilizzato dall'applicazione della dashboard di leggere i log delle attività amministrative esportati. |
Il criterio di autorizzazione associato alla risorsa Organizzazione per questo scenario apparirà 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 destinazione per questo scenario sarà simile al seguente:
{
"bindings": [{
"role": "roles/bigquery.dataViewer",
"members": [
"serviceAccount:prod-project-dashboard@admin-resources.iam.gserviceaccount.com"
]
}]
}