Overview of Access Transparency

This page introduces Access Transparency logging.

Introduction

Google’s long-term commitment to security goes hand in hand with our ongoing practice of transparency, enabling our customers not only to trust us, but also to verify that we are making good on our commitments.

As part of this practice of transparency, we have developed the Access Transparency product, which provides logs of actions taken by Google staff when accessing customer content. As part of your regular logs in Stackdriver Logging, you can also see logs of Google staff activity, including: actions by customer support that you may have requested by phone, lower level engineering investigations in furtherance of your support requests, or other actions made for valid business purposes such as recovering from an outage.

When to use Access Transparency

There are a variety of reasons why you might need Access Transparency. Some examples include:

  • Verifying that Google isn’t accessing your data for any reason except for a valid business reason, such as fixing a fault or attending to your requests.
  • Verifying that Google’s staff have not made an error when carrying out your instructions.
  • Verifying and tracking compliance with legal/regulatory obligations.
  • Collecting and analyzing tracked access events through an automated security information and event management (SIEM) tool.

Configuring Access Transparency

Use the following information to become familiar with requirements and steps for enabling or disabling Access Transparency.

Requirements for using Access Transparency

Access Transparency can only be enabled at an Organization level for Organizations with Platinum or Gold support. Support for role-based and project-level onboarding is coming soon, but in the interim please contact sales or support in order to enable Access Transparency.

Granting yourself the appropriate permission

In order to enable Access Transparency, you will need to grant yourself both the Organization Admin and the Access Transparency Admin roles. To learn more about how to grant yourself an IAM role, visit the IAM documentation. If you prefer not to grant yourself the Access Transparency Admin role, you can create a custom role containing the axt.labels.get and axt.labels.set permissions. To find out more about custom roles, please visit the IAM documentation on custom roles.

Enabling Access Transparency

To enable Access Transparency:

  1. Select a project inside the Organization for which you want to enable Access Transparency. Note that selecting the Organization itself will not work.
  2. Ensure that the selected project is funded by a Billing Account that has Platinum or Gold support.
  3. Navigate to the IAM & Admin sub-menu in the Google Cloud Platform Console.
  4. Select the Settings sub-menu.
  5. Press the Enable Access Transparency button.

Disabling Access Transparency

In order to disable Access Transparency please contact support.

Service availability

The table below lists the Google Cloud Platform services that write Access Transparency logs. GA indicates that a log type is Generally Available for a service; Beta indicates that a log type is available, but might be changed in backward-incompatible ways and is not subject to any SLA or deprecation policy.

Access Transparency logs are produced by the following services:

Services with Access Transparency support Availability
App Engine1 GA
Cloud Identity and Access Management (IAM) GA
Cloud Key Management Service (KMS) GA
Cloud Storage GA
Compute Engine GA
Persistent Disk GA

1 Cloud Storage is the only compatible storage backend for App Engine currently supported by Access Transparency.

What’s included in the logs?

Access Transparency logs are generated when people working for Google access data uploaded by you into an Access Transparency supported service (for example, viewing one of the labels on your Compute Engine instance), except when:

  1. You grant the person accessing the data permission via your Cloud Identity and Access Management policy.
    • Cloud Audit Logging (when enabled) will be generated whenever you have a Google employee working with you to whom you have given access via Cloud Identity and Access Management.
  2. Google is legally prohibited from notifying you of the access.
  3. The data in question is a public resource identifier. For example, Cloud Project IDs or Cloud Storage Bucket IDs.
  4. The access is a system job. For example, a compression job that runs on the data.
    • Google uses an internal version of Binary Authorization to check that system code running on Access Transparency services has been reviewed by a second party.

What's next

¿Te sirvió esta página? Envíanos tu opinión:

Enviar comentarios sobre…