IAM roles for auditing-related job functions

This topic describes how to configure Identity and Access Management permissions for a set of sample auditing scenarios. It provides guidance on which IAM roles to grant to the auditing-related functional roles in your company for each scenarios. The examples in this topic are mainly targeted at security administrators, auditors, and employees who manage auditing tasks for an organization.

To learn about audit logs for Google Cloud, see Cloud Audit Logs. To learn about the audit logs that IAM generates, see IAM audit logging for service accounts.

Scenario: Operational monitoring

In this scenario, an organization has a central security team that has the ability to review logs that may contain sensitive information both in Cloud Logging and when stored in long-term storage.

Historical audit data is stored in Cloud Storage. The organization uses an application to provide access to the historical audit data. The application uses a service account to access the log data. Due to the sensitivity of some of the audit log data, it is redacted using Sensitive Data Protection before being made accessible for viewing.

The table below explains the IAM roles that need to be granted to the CTO, security team, and service account, as well as the resource level at which the roles are granted.

Once log entries have been exported, access to the exported copies is controlled entirely by IAM permissions and roles on any of the destinations: Cloud Storage, BigQuery, or Pub/Sub. In this scenario, Cloud Storage is the destination for long term storage of audit logs.

Data in the Data Access logs is deemed as personally identifiable information (PII) for this organization. Integrating the application with Sensitive Data Protection gives the ability to redact sensitive PII data when viewing Data Access logs whether they are in the Data Access logs or from the historical archive in Cloud Storage.

The allow policy bound to the organization resource for this scenario will look similar to the following:

{
  "bindings": [{
    "role": "roles/resourcemanager.organizationAdmin",
      "members": [
        "user:[email protected]"
      ]
    },
    {
      "role": "roles/logging.viewer",
      "members": [
        "group:[email protected]",
        "serviceAccount:[email protected]"
      ]
    },
    {
      "role": "roles/logging.privateLogViewer",
      "members": [
        "group:[email protected]"
      ]
    }
  ]
}

The allow policy bound at the bucket configured as the destination sink for this scenario will look similar to the following:

{
  "bindings": [{
    "role": "roles/storage.objectViewer",
    "members": [
      "serviceAccount:[email protected]"
    ]
  }]
}

Scenario: Development teams monitoring their audit logs

In this scenario, the organization's developers need to look at audit logs generated while developing their applications. They are not permitted to review production logs unless they have been redacted using Sensitive Data Protection. A dashboard application is available to the developers that provides view-only access to exported production data. The organization's security team has access to all logs both in production and in the development environment.

The table below explains the IAM roles that need to be granted to the security team, developers, and service account, as well as the resource level at which the roles are granted.

Access to the exported copies is controlled entirely by IAM permissions and roles on any of the destinations: Cloud Storage, BigQuery, or Pub/Sub. In this scenario, BigQuery is the destination for storage of audit logs.

The allow policy bound to the development team's folder resource for this scenario will look similar to the following:

{
  "bindings": [{
    "role": "roles/logging.viewer",
    "members": [
      "group:[email protected]"
    ]
  },
  {
    "role": "roles/logging.privateLogViewer",
    "members": [
      "group:[email protected]"
    ]
  }]
}

The allow policy bound to the organization resource for this scenario will look similar to the following:

{
  "bindings": [{
    "role": "roles/logging.viewer",
    "members": [
      "group:[email protected]"
    ]
  },
  {
    "role": "roles/logging.privateLogViewer",
    "members": [
      "group:[email protected]"
    ]
  }]
}

The allow policy bound at the BigQuery dataset that is configured as the destination sink for this scenario will look similar to the following:

{
  "bindings": [{
    "role": "roles/bigquery.dataViewer",
    "members": [
      "serviceAccount:[email protected]"
    ]
  }]
}

Scenario: External auditors

In this scenario, audit logs for an organization are aggregated and exported to a central sink location. A third-party auditor is granted access several times a year to review the organization's audit logs. The auditor is not authorized to view PII data in the Admin Activity logs. To comply with this requirement, a dashboard is available that provides access to the historic logs stored in BigQuery, and on request, to the Cloud Logging Admin Activity logs.

The organization creates a Google group for these external auditors and adds the current auditor to the group. This group is monitored and is typically granted access to the dashboard application.

During normal access, the auditors' Google group is only granted access to view the historic logs stored in BigQuery. If any anomalies are discovered, the group is granted permission to view the actual Cloud Logging Admin Activity logs via the dashboard's elevated access mode. At the end of each audit period, the group's access is then revoked.

Data is redacted using Sensitive Data Protection before being made accessible for viewing via the dashboard application.

The table below explains IAM logging roles that an Organization Administrator can grant to the service account used by the dashboard, as well as the resource level at which the role is granted.

The allow policy bound to the Organization resource for this scenario will look similar to the following:

{
  "bindings": [{
    "role": "roles/logging.viewer",
    "members": [
      "serviceAccount:[email protected]"
    ]
  }]
}

The allow policy bound at the BigQuery dataset that is configured as the destination sink for this scenario will look similar to the following:

{
  "bindings": [{
    "role": "roles/bigquery.dataViewer",
    "members": [
      "serviceAccount:[email protected]"
    ]
  }]
}