Configuring Roles for Audit Logging

This topic describes how to configure Google Cloud Identity and Access Management permissions for a set of sample auditing scenarios. It provides guidance on which Cloud 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.

Background

Google Cloud Platform (GCP) provides Cloud Audit Logging, which is an integral part of the Stackdriver suite of products to address logging requirements. It consists of two log streams for each project: Admin Activity and Data Access, which are generated by GCP services to help you answer the question of "who did what, where, and when?" within your GCP projects. These logs are distinct from your application logs, and are described below:

  • Admin activity logs contain log entries for API calls or other administrative actions that modify the configuration or metadata of resources. Admin activity logs are always enabled. There is no charge for your admin activity audit logs.
  • Data access logs record API calls that create, modify, or read user-provided data. Data access audit logs are disabled by default because they can be large.

Each service that produces audit logs is listed in the Services producing audit logs section.

It is important to note that log entries are held in Stackdriver for a limited time known as the retention period. After that, the entries are deleted. To keep log entries longer they must be exported outside of Stackdriver to Cloud Pub/Sub, BigQuery, or a Cloud Storage bucket.

The example scenarios in this topic assume a Cloud Organization has been configured.

This document does not describe logging roles and permissions in detail. For a detailed description, see the Access Control Guide for Stackdriver.

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 Stackdriver 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 the Data Loss Prevention API before being made accessible for viewing.

The table below explains the Cloud 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.

Role Resource Member Description
resourcemanager.organizationAdmin Organization CTO The resourcemanager.organizationAdmin role gives the CTO the ability to assign permissions to the security team and service account.
logging.viewer Organization Security team The logging.viewer role gives the security admin team the ability to view the admin activity logs.
logging.privateLogsViewer Organization Security team The logging.privateLogsViewer role gives the ability to view the data access logs.

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

Role Resource Member Description
logging.viewer Organization Service account The logging.viewer role permits the service account to read the admin activity logs in Stackdriver.

Data in the data access logs is deemed as personally identifiable information (PII) for this organization. Integrating the application with the Data Loss Prevention API 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.

Role Resource Member Description
storage.objectViewer Bucket Service account The storage.objectViewer role permits the service account to read the exported admin activity logs.

The Cloud IAM policy bound to the organization resource for this scenario will look similar 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.gserviceacount.com"
            ]
        },
        {
            "role": "roles/logging.privateLogViewer",
            "members": [
                "group:security-team@example.com"

            ]
        }
    ]
}

The Cloud IAM 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:prod-logviewer@admin-resources.iam.gserviceacount.com"
        ]
    }]
}

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 the Data Loss Prevention API. 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 Cloud 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.

Role Resource Member Description
logging.viewer Organization Security team The logging.viewer role gives the security admin team the ability to view the admin activity logs.
logging.privateLogsViewer Organization Security team The logging.privateLogsViewer role gives the ability to view the data access logs.
logging.viewer Folder Developer team The logging.viewer role gives the developer team the ability to view the admin activity logs generated by the developer projects contained in a folder where all developer projects are located.
logging.privateLogsViewer Folder Developer team The logging.privateLogsViewer role gives the ability to view the data access logs.

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

Role Resource Member Description
bigquery.dataViewer BigQuery dataset Dashboard service account The bigquery.dataViewer role permits the service account used by the dashboard application to read the exported admin activity logs.

The Cloud IAM 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:developer-team@example.com"
            ]
        },
        {
            "role": "roles/logging.privateLogViewer",
            "members": [
                "group:developer-team@example.com"

            ]
        }
    ]
}

The Cloud IAM policy bound to the organization resource for this scenario will look similar 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 Cloud IAM 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:prod-project-dashboard@admin-resources.iam.gserviceacount.com"

        ]
    }]
}

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 Stackdriver admin activity logs.

The organization creates a temporary auditor account for each audit period. This account is monitored and is typically granted access to the dashboard application.

During normal access, the auditors are only granted access to view the historic logs stored in BigQuery. If any anomalies are discovered, the auditor is granted permission to view the actual Stackdriver admin activity logs via the dashboard's elevated access mode. At the end of each audit period, access is then revoked.

Data is redacted using the Data Loss Prevention API before being made accessible for viewing via the dashboard application.

The table below explains Cloud 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.

Role Resource Member Description
logging.viewer Organization Dashboard service account The logging.viewer role permits the service account to read the admin activity logs in Stackdriver.
bigquery.dataViewer BigQuery dataset Dashboard service account The bigquery.dataViewer role permits the service account used by the dashboard application to read the exported admin activity logs.

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

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

The Cloud IAM 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:prod-project-dashboard@admin-resources.iam.gserviceacount.com"
        ]
    }]
}

フィードバックを送信...

Cloud Identity and Access Management Documentation