{
	"id": "bce735f7-e601-48c5-be04-f3d66d252a5b",
	"created_at": "2026-04-06T00:18:25.007559Z",
	"updated_at": "2026-04-10T13:12:03.931878Z",
	"deleted_at": null,
	"sha1_hash": "28462245eeb5a1dab1d379f1ec49b637a9e4b1f4",
	"title": "Enable Data Access audit logs",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 268979,
	"plain_text": "Enable Data Access audit logs\r\nArchived: 2026-04-02 12:21:30 UTC\r\nThis guide explains how to enable or disable some or all Data Access audit logs in your Google Cloud projects,\r\nbilling accounts, folders, and organizations by using the Google Cloud console or the API.\r\nBefore you begin\r\nBefore you proceed with configuring Data Access audit logs, understand the following information:\r\nData Access audit logs are disabled by default for all services but some BigQuery services. If you want\r\nData Access audit logs to be written for services where these logs are disabled by default, then you must\r\nexplicitly enable them in the Google Cloud console, or by using the API.\r\nData Access audit logs are stored in the _Default bucket unless you've routed them elsewhere. For more\r\ninformation, see Storing and routing audit logs.\r\nData Access audit logs help Google Support troubleshoot issues with your account. Therefore, we\r\nrecommend enabling Data Access audit logs when possible.\r\nTo get the permissions that you need to get access to all logs in the _Required and _Default buckets,\r\nincluding Data Access logs, ask your administrator to grant you the Private Logs Viewer\r\n( roles/logging.privateLogViewer ) IAM role on your project.\r\nThe Private Logs Viewer role (roles/logging.privateLogViewer) includes the permissions contained in\r\nthe Logs Viewer role ( roles/logging.viewer ), and those necessary to read Data Access audit logs in the\r\n_Default bucket.\r\nThe Editor role ( roles/editor ) doesn't include the permissions required to view Data Access logs.\r\nFor more information about the IAM permissions and roles that apply to audit logs data, see Access control\r\nwith IAM.\r\nConfiguration overview\r\nYou can configure how Data Access audit logs are enabled for your Google Cloud resources and services:\r\nOrganizations: You can enable and configure Data Access audit logs in an organization, which applies to all\r\nthe existing and new Google Cloud projects and folders in the organization.\r\nFolders: You can enable and configure Data Access audit logs in a folder, which applies to all the existing\r\nand new Google Cloud projects in the folder. You can't disable a Data Access audit log that was enabled in\r\nthe project's parent organization.\r\nhttps://cloud.google.com/logging/docs/audit/configure-data-access\r\nPage 1 of 16\n\nProjects: You can configure Data Access audit logs for an individual Google Cloud project. You can't\r\ndisable a Data Access audit log that was enabled in a parent organization or folder.\r\nBilling accounts: To configure Data Access audit logs for billing accounts, use the Google Cloud CLI. For\r\nmore information about using the gcloud CLI with Data Access audit logs and billing accounts, see the\r\ngcloud beta billing accounts set-iam-policy documentation.\r\nDefault configurations: You can specify a default Data Access audit log configuration in an organization,\r\nfolder, or Google Cloud project that applies to future Google Cloud services that begin to produce Data\r\nAccess audit logs. For instructions, see Set the default configuration.\r\nPermission types: You can specify that Google Cloud APIs which only check for a certain type of\r\npermission emit an audit log. For more information, see the Permission types section of this page.\r\nExempted principals: You can exempt specific principals from having their data accesses recorded. For\r\nexample, you can exempt your internal testing accounts from having their Cloud Monitoring operations\r\nrecorded. For a list of valid principals, including users and groups, see the Binding type reference.\r\nYou can configure your Data Access audit logs through the IAM Audit Logs page of the Google Cloud console,\r\nor by using the API. These methods are explained in the following sections.\r\nPermission types\r\nAPI methods check IAM permissions. Each IAM permission has a permission type, which is defined by the\r\ntype property. Permission types are categorized as either a Data Access permission type or as an Admin Activity\r\npermission type:\r\nData Access permission types:\r\nADMIN_READ : IAM permissions of this type are checked for Google Cloud API methods that read\r\nmetadata or configuration information. Typically, ADMIN_READ audit logs are disabled by default\r\nand must be enabled.\r\nDATA_READ : IAM permissions of this type are checked for Google Cloud API methods that read\r\nuser-provided data. Typically, DATA_READ audit logs are disabled by default and must be enabled.\r\nDATA_WRITE : IAM permissions of this type are checked for Google Cloud API methods that write\r\nuser-provided data. Typically, DATA_WRITE audit logs are disabled by default and must be enabled.\r\nAdmin Activity permission type:\r\nADMIN_WRITE : IAM permissions of this type are checked for Google Cloud API methods that write\r\nmetadata or configuration information. The audit logs associated with this type, Admin Activity\r\naudit logs, are on by default and can't be disabled.\r\nYou can enable or disable permission types for services by using the Google Cloud console or by invoking the\r\nAPI.\r\nhttps://cloud.google.com/logging/docs/audit/configure-data-access\r\nPage 2 of 16\n\nMost Google Cloud APIs only check if the caller has a single IAM permission. If the permission type associated\r\nwith that permission is enabled for the service whose API is being called, then the API generates an audit log.\r\nThe following sections generally describe other ways in which Google Cloud API methods check for IAM\r\npermissions. For service-specific information about which methods are checked for which permission types, see\r\nthe service's audit logging documentation.\r\nIAM permissions checking for Data Access permission types\r\nSome Google Cloud API methods check whether the caller has multiple IAM permissions with different Data\r\nAccess permission types. An audit log is written when one of those Data Access permission types is enabled on\r\nthe project.\r\nFor example, an API method might check that the principal issuing an API request has the permissions\r\nexample.resource.get ( DATA_READ ) and example.resource.write ( DATA_WRITE ). The project only needs\r\neither DATA_WRITE or DATA_READ enabled for the service to emit the audit log when issuing the call.\r\nAdmin Activity and Data Access IAM permission types checked\r\nSome Google Cloud API methods check for both an IAM permission that has the ADMIN_WRITE permission type,\r\nand one or more permissions that have a Data Access permission type.\r\nThese types of API calls emit Admin Activity audit logs, which are on by default and can't be disabled.\r\nAPI method checks for IAM permissions not owned by service\r\nSome Google Cloud services have API methods that generate an audit log only when a specific permission type is\r\nenabled for a different service.\r\nFor example, Cloud Billing has an API method that checks for an ADMIN_READ permission type that is owned by\r\nResource Manager. ADMIN_READ must be enabled for the service cloudresourcemanager.googleapis.com to\r\nenable the audit log associated with the Cloud Billing API.\r\nSame API method checks for different IAM permissions\r\nFor some Google Cloud APIs, how the method is called determines which IAM permission type(s) must be\r\nenabled on the project for an audit log to be generated.\r\nFor example, Spanner has an API method that sometimes checks for an IAM permission with the DATA_WRITE\r\ntype, and sometimes checks for an IAM permission with the DATA_READ type depending on how the method is\r\ncalled. In this case, enabling DATA_WRITE for Spanner on the project the API call only enables the audit log\r\nassociated with the API when the IAM permission with the DATA_WRITE type is checked.\r\nService-specific configurations\r\nhttps://cloud.google.com/logging/docs/audit/configure-data-access\r\nPage 3 of 16\n\nIf there is both a Google Cloud service-wide ( allServices ) configuration and a configuration for a specific\r\nGoogle Cloud service, then the resulting configuration for the service is the union of the two configurations. In\r\nother words:\r\nYou can enable Data Access audit logs for specific Google Cloud services, but you can't disable Data\r\nAccess audit logs for Google Cloud services that are enabled in the broader configuration.\r\nYou can add additional kinds of information to a Google Cloud service's Data Access audit log, but you\r\ncan't remove kinds of information that are specified in the broader configuration.\r\nYou can add principals to exemption lists, but you can't remove them from exemption lists in the broader\r\nconfiguration.\r\nFor BigQuery Data Transfer Service, Data Access audit log configuration is inherited from your default\r\naudit log configuration.\r\nGoogle Cloud MCP servers servers write Data Access audit logs that are service-specific and use the format\r\nSERVICE_NAME.googleapis.com/mcp . You can enable these Data Access logs by turning on audit logging for\r\nmcp.googleapis.com in the IAM AuditConfig object. For more information about audit logging for Google\r\nCloud MCP servers, see Google Cloud MCP servers audit logging.\r\nGoogle Cloud resource configurations\r\nYou can configure Data Access audit logs for Google Cloud projects, billing accounts, folders, and organizations.\r\nIf there is a configuration for a Google Cloud service across the hierarchy, then the resulting configuration is the\r\nunion of the configurations. In other words, at the Google Cloud project level:\r\nYou can enable logs for a Google Cloud service, but you can't disable logs for a Google Cloud service that\r\nis enabled in a parent organization or folder.\r\nYou can enable kinds of information, but you can't disable kinds of information that are enabled in a parent\r\norganization or folder.\r\nYou can add principals to exemption lists, but you can't remove them from exemption lists in a parent\r\norganization or folder.\r\nAt a parent organization or folder level, you can enable Data Access audit logs for a Google Cloud project\r\nwithin that organization or folder, even if Data Access audit logs haven't been configured in the Google\r\nCloud project.\r\nAccess control\r\nIdentity and Access Management roles and permissions govern access to Logging data, including viewing and\r\nmanaging the IAM policies underlying Data Access audit logging configurations.\r\nTo view or set the policies associated with Data Access configuration, you need a role with permissions at the\r\nappropriate resource level. For instructions on granting these resource-level roles, see Manage access to Google\r\nhttps://cloud.google.com/logging/docs/audit/configure-data-access\r\nPage 4 of 16\n\nCloud projects, folders, and organizations.\r\nTo set IAM policies, you need a role with the resourcemanager.RESOURCE_TYPE.setIamPolicy permission.\r\nTo view IAM policies, you need a role with the resourcemanager.RESOURCE_TYPE.getIamPolicy\r\npermission.\r\nFor the list of the permissions and roles you need to view Data Access audit logs, see Access control with IAM.\r\nConfigure Data Access audit logs with the Google Cloud console\r\nThis section explains how to use the Google Cloud console to configure Data Access audit logs.\r\nYou can also use the API or the Google Cloud CLI to perform these tasks programmatically; see Configure Data\r\nAccess audit logs with the API for details.\r\nTo access audit log configuration options in the Google Cloud console, follow these steps:\r\n1. In the Google Cloud console, go to the Audit Logs page:\r\nGo to Audit Logs\r\nIf you use the search bar to find this page, then select the result whose subheading is IAM \u0026 Admin.\r\n2. Select an existing Google Cloud project, folder, or organization.\r\nEnable audit logs\r\nTo enable Data Access audit logs, do the following:\r\n1. In the Data Access audit logs configuration table, select one or more Google Cloud services from the\r\nService column.\r\n2. In the Permission types tab, select the Data Access audit log types that you want to enable for your\r\nselected services.\r\n3. Click Save.\r\nWhere you have successfully enabled audit logs, the table includes a Check icon.\r\nIn the following example, you see that, for the Access Approval service, the Data Read audit log type is enabled:\r\nhttps://cloud.google.com/logging/docs/audit/configure-data-access\r\nPage 5 of 16\n\nYou can also enable audit logs for all Google Cloud services that produce Data Access audit logs. In the Data\r\nAccess audit logs configuration table, select all Google Cloud services.\r\nNote that this bulk configuration method applies only to the Google Cloud services that are available for your\r\nresource. If a new Google Cloud service is added, it inherits your default audit configuration.\r\nDisable Data Access audit logs\r\nTo disable Data Access audit logs, do the following:\r\n1. In the Data Access audit logs configuration table, select one or more Google Cloud services.\r\n2. In the Log Types tab in the information panel, select the Data Access audit log types that you want to\r\ndisable for your selected services.\r\n3. Click Save.\r\nWhere you've successfully disabled Data Access audit logs, the table indicates this with a dash. Any enabled Data\r\nAccess audit logs are indicated with a Check icon.\r\nSet exemptions\r\nYou can set exemptions to let you control which principals generate Data Access audit logs for particular services.\r\nWhen you add an exempted principal, audit logs aren't created for them for the selected log types.\r\nTo set exemptions, do the following:\r\n1. In the Data Access audit logs configuration table, select a Google Cloud service from the Service\r\ncolumn.\r\n2. Select the Exempted Principals tab in the information panel.\r\n3. In Add exempted principal, enter the principal that you want to exempt from generating Data Access\r\naudit logs for your selected service.\r\nYou can add multiple principals by clicking the Add exempted principal button as many times as needed.\r\nFor a list of valid principals, including users and groups, see the Binding type reference.\r\nhttps://cloud.google.com/logging/docs/audit/configure-data-access\r\nPage 6 of 16\n\n4. In Disabled Log Types, select the Data Access audit log types that you want to disable.\r\n5. Click Save.\r\nWhere you have successfully added exempted principals to a service, the Data Access audit logs configuration\r\ntable indicates this with a number under the Exempted principals column.\r\nTo remove a principal from your exemption list, do the following:\r\n1. In the Data Access audit logs configuration table, select a Google Cloud service from the Service\r\ncolumn.\r\n2. Select the Exempted Principals tab in the information panel.\r\n3. Hold your pointer over a principal name and then select Delete.\r\n4. After the principal's name is shown in strikethrough text, click Save.\r\nTo edit the information for an exempted principal, do the following:\r\n1. In the Data Access audit logs configuration table, select a Google Cloud service from the Service\r\ncolumn.\r\n2. Select the Exempted Principals tab in the information panel.\r\n3. Locate the principal and select expand Show more.\r\n4. Select or deselect the Data Access audit log types as appropriate for the principal.\r\n5. Click Save.\r\nSet the default configuration\r\nYou can set a configuration that all new and existing Google Cloud services in your Google Cloud project, folder,\r\nor organization inherit. Setting this default configuration applies if a new Google Cloud service becomes available\r\nand principals in your organization begin using it: the service inherits the audit logging policy that you have\r\nalready set for other Google Cloud services, ensuring that Data Access audit logs are captured.\r\nTo set or edit the default configuration, do the following:\r\n1. Click Set Default Configuration.\r\n2. In the Log Types tab in the information panel, select the Data Access audit log types that you want to\r\nenable or disable.\r\n3. Click Save.\r\n4. Select the Exempted Principals tab in the information panel.\r\nhttps://cloud.google.com/logging/docs/audit/configure-data-access\r\nPage 7 of 16\n\n5. In Add exempted principal, enter the principal that you want to exempt from generating Data Access\r\naudit logs for your selected service.\r\nYou can add multiple principals by clicking the Add exempted principal button as many times as needed.\r\nFor a list of valid principals, including users and groups, see the Binding type reference.\r\n6. In Disabled Log Types, select the Data Access audit log types that you want to disable.\r\n7. Click Save.\r\nConfigure Data Access audit logs with the API\r\nThis section explains how to use the API and the gcloud CLI to configure Data Access audit logs\r\nprogrammatically.\r\nMany of these tasks can also be performed by using the Google Cloud console; for instructions, see Configure\r\nData Access audit logs with the Google Cloud console on this page.\r\nSome BigQuery services, like BigQuery Reservation API, require you to explicitly enable Data Access audit logs.\r\nTo enable data access audit logs for the BigQuery Reservation API, you must edit your configuration to enable\r\nADMIN_READ audit logs for bigquery.googleapis.com .\r\nIAM policy objects\r\nTo configure Data Access audit logs using the API, you must edit the IAM policy associated with your Google\r\nCloud project, folder, or organization. The audit log configuration is in the auditConfigs section of the policy:\r\n\"auditConfigs\": [\r\n {\r\n object(AuditConfig)\r\n }\r\n]\r\nFor details, see the IAM Policy type.\r\nThe following sections describe the AuditConfig object in more detail. For the API and gcloud CLI commands\r\nused to change the configuration, see the section titled getIamPolicy and setIamPolicy .\r\nAuditConfig objects\r\nThe audit log configuration consists of a list of AuditConfig objects. Each object configures the logs for one\r\nservice, or it establishes a broader configuration for all services. Each object looks like the following:\r\n{\r\n \"service\": SERVICE_NAME,\r\nhttps://cloud.google.com/logging/docs/audit/configure-data-access\r\nPage 8 of 16\n\n\"auditLogConfigs\": [\r\n {\r\n \"logType\": \"ADMIN_READ\"\r\n \"exemptedMembers\": [ PRINCIPAL,]\r\n },\r\n {\r\n \"logType\": \"DATA_READ\"\r\n \"exemptedMembers\": [ PRINCIPAL,]\r\n },\r\n {\r\n \"logType\": \"DATA_WRITE\"\r\n \"exemptedMembers\": [ PRINCIPAL,]\r\n },\r\n ]\r\n},\r\nSERVICE_NAME has a value such as \"appengine.googleapis.com\" , or it is the special value, \"allServices\" .\r\nIf a configuration doesn't mention a particular service, then the broader configuration is used for that service. If\r\nthere is no configuration, then Data Access audit logs aren't enabled for that service. For a list of the service\r\nnames, see Log services.\r\nThe auditLogConfigs section of the AuditConfig object is a list of 0 to 3 objects, each of which configures one\r\nkind of audit log information. If you omit one of the kinds from the list, then that kind of information isn't enabled\r\nfor the service.\r\nPRINCIPAL is a user for whom Data Access audit logs isn't collected. The Binding type describes different\r\nkinds of principals, including users and groups, but not all of those can be used to configure Data Access audit\r\nlogs.\r\nFollowing is an example of an audit configuration in both JSON and YAML formats. The YAML format is the\r\ndefault when using the Google Cloud CLI.\r\n\"auditConfigs\": [\r\n {\r\n \"auditLogConfigs\": [\r\n {\r\n \"logType\": \"ADMIN_READ\"\r\n },\r\n {\r\n \"logType\": \"DATA_WRITE\"\r\n },\r\n {\r\n \"logType\": \"DATA_READ\"\r\n }\r\n ],\r\nhttps://cloud.google.com/logging/docs/audit/configure-data-access\r\nPage 9 of 16\n\n\"service\": \"allServices\"\r\n },\r\n {\r\n \"auditLogConfigs\": [\r\n {\r\n \"exemptedMembers\": [\r\n \"499862534253-compute@developer.gserviceaccount.com\"\r\n ],\r\n \"logType\": \"ADMIN_READ\"\r\n }\r\n ],\r\n \"service\": \"cloudsql.googleapis.com\"\r\n }\r\n],\r\nauditConfigs:\r\n- auditLogConfigs:\r\n - logType: ADMIN_READ\r\n - logType: DATA_WRITE\r\n - logType: DATA_READ\r\n service: allServices\r\n- auditLogConfigs:\r\n - exemptedMembers:\r\n - 499862534253-compute@developer.gserviceaccount.com\r\n logType: ADMIN_READ\r\n service: cloudsql.googleapis.com\r\nCommon configurations\r\nFollowing are some common audit log configurations for Google Cloud projects.\r\nEnable all Data Access audit logs\r\nThe following auditConfigs section enables Data Access audit logs for all services and principals:\r\n\"auditConfigs\": [\r\n {\r\n \"service\": \"allServices\",\r\n \"auditLogConfigs\": [\r\n { \"logType\": \"ADMIN_READ\" },\r\n { \"logType\": \"DATA_READ\" },\r\n { \"logType\": \"DATA_WRITE\" },\r\n ]\r\nhttps://cloud.google.com/logging/docs/audit/configure-data-access\r\nPage 10 of 16\n\n},\r\n ]\r\nauditConfigs:\r\n- auditLogConfigs:\r\n - logType: ADMIN_READ\r\n - logType: DATA_WRITE\r\n - logType: DATA_READ\r\n service: allServices\r\nEnable one service and information kind\r\nThe following configuration enables DATA_WRITE Data Access audit logs for Cloud SQL:\r\n\"auditConfigs\": [\r\n {\r\n \"service\": \"cloudsql.googleapis.com\",\r\n \"auditLogConfigs\": [\r\n { \"logType\": \"DATA_WRITE\" },\r\n ]\r\n },\r\n]\r\nauditConfigs:\r\n- auditLogConfigs:\r\n - logType: DATA_WRITE\r\n service: cloudsql.googleapis.com\r\nDisable all Data Access audit logs\r\nTo disable all Data Access audit logs (except for some BigQuery logs) in a Google Cloud project, include an\r\nempty auditConfigs: section in your new IAM policy:\r\n\"auditConfigs\": [],\r\nhttps://cloud.google.com/logging/docs/audit/configure-data-access\r\nPage 11 of 16\n\nauditConfigs:\r\nIf you remove the auditConfigs section entirely from your new policy, then setIamPolicy doesn't change the\r\nexisting Data Access audit logs configuration. For more information, see the section titled The setIamPolicy\r\nupdate mask.\r\nBigQuery Data Access audit logs can't be disabled.\r\ngetIamPolicy and setIamPolicy\r\nYou use the Cloud Resource Manager API getIamPolicy and setIamPolicy methods to read and write your\r\nIAM policy. You have several choices for the specific methods to use:\r\nThe Cloud Resource Manager API has the following methods:\r\nprojects.getIamPolicy\r\nprojects.setIamPolicy\r\norganizations.getIamPolicy\r\norganizations.setIamPolicy\r\nThe Google Cloud CLI has the following Resource Manager commands:\r\ngcloud projects get-iam-policy\r\ngcloud projects set-iam-policy\r\ngcloud resource-manager folders get-iam-policy\r\ngcloud resource-manager folders set-iam-policy\r\ngcloud organizations get-iam-policy\r\ngcloud organizations set-iam-policy\r\ngcloud beta billing accounts get-iam-policy\r\ngcloud beta billing accounts set-iam-policy\r\nRegardless of your choice, follow these three steps:\r\n1. Read the current policy using one of the getIamPolicy methods. Save the policy to a temporary file.\r\n2. Edit the policy in the temporary file. Change (or add) only the auditConfigs section.\r\n3. Write the edited policy in the temporary file, using one of the setIamPolicy methods.\r\nsetIamPolicy fails if Resource Manager detects that someone else changed the policy after you read it in the\r\nfirst step. If this happens, then repeat the three steps.\r\nExamples\r\nhttps://cloud.google.com/logging/docs/audit/configure-data-access\r\nPage 12 of 16\n\nThe following examples demonstrate how to configure your project's Data Access audit logs using the gcloud\r\ncommand and the Cloud Resource Manager API.\r\nTo configure organization Data Access audit logs, replace the \"projects\" version of the commands and API\r\nmethods with the \"organizations\" version.\r\nTo configure your Data Access audit logs using the gcloud projects command, do the following:\r\n1. Read your project's IAM policy and store it in a file:\r\ngcloud projects get-iam-policy PROJECT_ID \u003e /tmp/policy.yaml\r\nThe following shows the returned policy. This policy doesn't have an auditConfigs section:\r\nbindings:\r\n- members:\r\n - user:colleague@example.com\r\n role: roles/editor\r\n- members:\r\n - user:myself@example.com\r\n role: roles/owner\r\netag: BwVM-FDzeYM=\r\nversion: 1\r\n2. Edit your policy in /tmp/policy.yaml , adding or changing only the Data Access audit logs configuration.\r\nAn example of your edited policy, which enables Cloud SQL data-write Data Access audit logs:\r\nauditConfigs:\r\n- auditLogConfigs:\r\n - logType: DATA_WRITE\r\n service: cloudsql.googleapis.com\r\nbindings:\r\n- members:\r\n - user:colleague@example.com\r\n role: roles/editor\r\n- members:\r\n - user:myself@example.com\r\n role: roles/owner\r\netag: BwVM-FDzeYM=\r\nversion: 1\r\nhttps://cloud.google.com/logging/docs/audit/configure-data-access\r\nPage 13 of 16\n\nAs the previous example shows, four lines have been added to the beginning of the policy.\r\n3. Write your new IAM policy:\r\ngcloud projects set-iam-policy PROJECT_ID /tmp/policy.yaml\r\nIf the preceding command reports a conflict with another change, then repeat these steps, starting with the\r\nfirst step.\r\nJSON\r\nTo work with your IAM policy in JSON format instead of YAML, substitute the following gcloud commands\r\ninto the example:\r\ngcloud projects get-iam-policy PROJECT_ID --format=json \u003e/tmp/policy.json\r\ngcloud projects set-iam-policy PROJECT_ID /tmp/policy.json\r\nTo configure your Data Access audit logs using the Cloud Resource Manager API, do the following:\r\n1. Read your project's IAM policy, specifying the following parameters to the getIamPolicy API method:\r\nresource: projects/PROJECT_ID\r\nRequest body: empty\r\nThe method returns the current policy object:\r\n{\r\n \"version\": 1,\r\n \"etag\": \"BwXqwxkr40M=\",\r\n \"bindings\": [\r\n {\r\n \"role\": \"roles/owner\",\r\n \"members\": [\r\n \"user:myself@example.com\"\r\n ]\r\n }\r\n ]\r\n}\r\nThe previous example shows that the project's policy doesn't have an auditConfigs section.\r\n2. Edit the current policy:\r\nhttps://cloud.google.com/logging/docs/audit/configure-data-access\r\nPage 14 of 16\n\nChange or add the auditConfigs section.\r\nTo disable your Data Access audit logs, include an empty value for the section: auditConfigs:[] .\r\nPreserve the value of etag .\r\nYou can also remove all other information from the new policy object, as long as you're careful to set\r\nupdateMask in the next step. The following shows the edited policy, which enables Cloud SQL\r\nDATA_WRITE audit logs:\r\n{\r\n \"policy\": {\r\n \"auditConfigs\": [\r\n {\r\n \"auditLogConfigs\": [\r\n {\r\n \"logType\": \"DATA_WRITE\"\r\n }\r\n ],\r\n \"service\": \"cloudsql.googleapis.com\"\r\n }\r\n ],\r\n \"etag\": \"BwXqwxkr40M=\"\r\n },\r\n \"updateMask\": \"auditConfigs,etag\"\r\n}\r\n3. Write the new policy using the setIamPolicy API method, specifying the following parameters:\r\nresource: projects/PROJECT_ID\r\nRequest body: Include the edited policy.\r\nThe setIamPolicy update mask\r\nThis section explains the importance of the updateMask parameter in the setIamPolicy method, and explains\r\nwhy you must be careful with the gcloud CLI set-iam-policy command so that you don't cause accidental harm\r\nto your Google Cloud project or organization.\r\nThe setIamPolicy API method uses an updateMask parameter to control which policy fields are updated. For\r\nexample, if the mask does not contain bindings , then you can't accidentally change that policy section. On the\r\nother hand, if the mask does contain bindings , then that section is always updated. If you don't include an\r\nupdated value for bindings , then that section is removed entirely from the policy.\r\nThe gcloud projects set-iam-policy command, which calls setIamPolicy , doesn't let you specify the\r\nupdateMask parameter. Instead, the command computes a value for updateMask in the following way:\r\nhttps://cloud.google.com/logging/docs/audit/configure-data-access\r\nPage 15 of 16\n\nThe updateMask always contains the fields bindings and etag .\r\nIf the policy object supplied in set-iam-policy contains any other top-level fields—such as\r\nauditConfigs —then those fields are added to updateMask .\r\nAs a consequence of these rules, the set-iam-policy command has the following behaviors:\r\nIf you omit the auditConfigs section in your new policy, then the previous value of auditConfigs\r\nsection (if any) isn't changed, because that section isn't in the update mask. This is harmless but might be\r\nconfusing.\r\nIf you omit bindings in your new policy object, then the bindings section is removed from your policy,\r\nsince this section appears in the update mask. This is very harmful, and causes all principals to lose access\r\nto your Google Cloud project.\r\nIf you omit etag in your new policy object, this disables the checking for concurrent changes to your\r\npolicy and might result in your changes accidentally overwriting someone else's changes.\r\nSource: https://cloud.google.com/logging/docs/audit/configure-data-access\r\nhttps://cloud.google.com/logging/docs/audit/configure-data-access\r\nPage 16 of 16",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://cloud.google.com/logging/docs/audit/configure-data-access"
	],
	"report_names": [
		"configure-data-access"
	],
	"threat_actors": [
		{
			"id": "67bf0462-41a3-4da5-b876-187e9ef7c375",
			"created_at": "2022-10-25T16:07:23.44832Z",
			"updated_at": "2026-04-10T02:00:04.607111Z",
			"deleted_at": null,
			"main_name": "Careto",
			"aliases": [
				"Careto",
				"The Mask",
				"Ugly Face"
			],
			"source_name": "ETDA:Careto",
			"tools": [
				"Careto"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "f5bf6853-3f6e-452c-a7b7-8f81c9a27476",
			"created_at": "2023-01-06T13:46:38.677391Z",
			"updated_at": "2026-04-10T02:00:03.064818Z",
			"deleted_at": null,
			"main_name": "Careto",
			"aliases": [
				"The Mask",
				"Ugly Face"
			],
			"source_name": "MISPGALAXY:Careto",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434705,
	"ts_updated_at": 1775826723,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/28462245eeb5a1dab1d379f1ec49b637a9e4b1f4.pdf",
		"text": "https://archive.orkl.eu/28462245eeb5a1dab1d379f1ec49b637a9e4b1f4.txt",
		"img": "https://archive.orkl.eu/28462245eeb5a1dab1d379f1ec49b637a9e4b1f4.jpg"
	}
}