Ruoli IAM per mansioni relative al controllo

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 ruoli IAM concedere ai ruoli funzionali relativi al controllo della tua azienda per ogni scenario. 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 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 dispone di un team di sicurezza centrale che ha la possibilità di esaminare i log che potrebbero contenere informazioni sensibili sia in Cloud Logging sia quando sono archiviati in un'area di archiviazione 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 controllo storici. 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 riportata di seguito illustra i ruoli IAM che devono essere assegnati al CTO, al team di sicurezza e all'account di servizio, nonché il livello di risorsa a cui vengono assegnati i ruoli.

Una volta esportate le voci di log, l'accesso alle copie esportate è controllato interamente dalle autorizzazioni e dai ruoli IAM in una delle destinazioni: Cloud Storage, BigQuery o Pub/Sub. In questo scenario, Cloud Storage è la destinazione per l'archiviazione a lungo termine degli audit log.

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.

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 destinazione per questo scenario sarà simile al seguente:

{
  "bindings": [{
    "role": "roles/storage.objectViewer",
    "members": [
      "serviceAccount:prod-logviewer@admin-resources.iam.gserviceaccount.com"
    ]
  }]
}

Scenario: i team di sviluppo monitorano i propri log di controllo

In questo caso, 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. Gli sviluppatori possono utilizzare 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 riportata di seguito illustra i ruoli IAM che devono essere assegnati al team di sicurezza, agli sviluppatori e all'account di servizio, nonché il livello di risorsa a cui vengono assegnati.

L'accesso alle copie esportate è controllato interamente dalle autorizzazioni e dai ruoli IAM in una delle destinazioni: Cloud Storage, BigQuery o Pub/Sub. In questo scenario, BigQuery è la destinazione per l'archiviazione degli audit log.

Il criterio di autorizzazione associato alla risorsa della 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 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 del sink centrale. 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 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 l'accesso normale, al gruppo Google degli auditor 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 delle attività amministrative di Cloud Logging tramite la modalità di accesso elevata della dashboard. Al termine di ogni periodo di controllo, l'accesso del gruppo viene revocato.

I dati vengono oscurati utilizzando la funzionalità 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 all'account di servizio utilizzato dalla dashboard, nonché il livello di risorsa a cui viene concesso il ruolo.

Il criterio di autorizzazione associato alla risorsa Organization 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 destinazione per questo scenario sarà simile al seguente:

{
  "bindings": [{
    "role": "roles/bigquery.dataViewer",
    "members": [
      "serviceAccount:prod-project-dashboard@admin-resources.iam.gserviceaccount.com"
    ]
  }]
}