Note: Identity and Access Management (IAM) offers predefined roles that are tailored to specific job functions. If you want to give a user the necessary permissions to perform a specific job function in your organization, consider granting one of these predefined roles. To determine if IAM offers a predefined role for your use case, seePredefined roles for job functions.

This topic describes how to configure Identity and Access Management permissions for a set ofsample auditing scenarios. It provides guidance on which IAMroles to grant to the auditing-related functional roles in your company for eachscenarios. The examples in this topic are mainly targeted at securityadministrators, auditors, and employees who manage auditing tasks for anorganization.

To learn about audit logs for Google Cloud, seeCloud Audit Logs. To learn about the audit logs thatIAM generates, seeIAM audit logging for service accounts.

Scenario: Operational monitoring

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

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

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

Once log entries have been exported, access to the exported copies is controlledentirely by IAM permissions and roles on any of thedestinations: Cloud Storage, BigQuery, orPub/Sub. In this scenario, Cloud Storage is the destinationfor 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 withSensitive Data Protection gives the ability to redact sensitive PII datawhen viewing Data Access logs whether they are in the Data Access logs or fromthe historical archive in Cloud Storage.

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

{"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"]}]}

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

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

Scenario: Development teams monitoring their audit logs

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

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

Access to the exported copies is controlledentirely by IAM permissions and roles on any of thedestinations: Cloud Storage, BigQuery, orPub/Sub. In this scenario, BigQuery is the destinationfor storage of audit logs.

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

{"bindings":[{"role":"roles/logging.viewer","members":["group:developer-team@example.com"]},{"role":"roles/logging.privateLogViewer","members":["group:developer-team@example.com"]}]}

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

{"bindings":[{"role":"roles/logging.viewer","members":["group:security-team@example.com"]},{"role":"roles/logging.privateLogViewer","members":["group:security-team@example.com"]}]}

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

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

Scenario: External auditors

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

The organization creates a group for these external auditors and adds thecurrent auditor to the group. This group is monitored and is typically grantedaccess to the dashboard application.

During normal access, the auditors' group is only granted access to viewthe historic logs stored in BigQuery. If any anomalies arediscovered, the group is granted permission to view the actual Cloud LoggingAdmin Activity logs via the dashboard's elevated access mode. At the end of eachaudit period, the group's access is then revoked.

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

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

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

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

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

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