Neste guia, explicamos como ativar ou desativar alguns ou todos os registros de auditoria do Data Access em Trusted Cloud projetos, contas de faturamento, pastas e organizações usando o console Trusted Cloud ou a API.
Antes de começar
Antes de continuar a configuração dos registros de auditoria do Data Access, entenda as seguintes informações:
Os registros de auditoria de acesso a dados (exceto BigQuery) são desativados por padrão. Se você quiser que os registros de auditoria de acesso a dados sejam gravados para serviços doTrusted Cloud diferentes do BigQuery, será necessário ativá-los explicitamente.
Os registros de auditoria de acesso a dados são armazenados no bucket
_Default
, a menos que você os tenha encaminhado para outro lugar. Para mais informações, consulte Armazenar e rotear registros de auditoria.Os registros de auditoria de acesso a dados ajudam o Suporte do Google a resolver problemas na sua conta. Portanto, recomendamos ativar os registros de auditoria de acesso a dados quando possível.
-
Para receber as permissões necessárias para acessar todos os registros nos buckets
_Required
e_Default
, incluindo os registros de acesso a dados, peça ao administrador para conceder a você o papel do IAM Leitor de registros particulares (roles/logging.privateLogViewer
) no seu projeto.O papel Visualizador de registros particulares
(roles/logging.privateLogViewer)
inclui as permissões contidas no papel Visualizador de registros (roles/logging.viewer
) e as necessárias para ler registros de auditoria de acesso a dados no bucket_Default
.O papel de Editor (
roles/editor
) não inclui as permissões necessárias para visualizar registros de acesso a dados.Para mais informações sobre as permissões e os papéis do IAM que se aplicam aos dados de registros de auditoria, consulte Controle de acesso com IAM.
Visão geral da configuração
É possível configurar como os registros de auditoria de acesso a dados são ativados para seus recursos e serviços doTrusted Cloud :
Organizações: é possível ativar e configurar os registros de auditoria de acesso a dados em uma organização, o que se aplica a todos osTrusted Cloud projetos e pastas novos e atuais na organização.
Pastas: ative e configure os registros de auditoria de acesso a dados em uma pasta, o que se aplica a todos os projetos Trusted Cloud novos e atuais na pasta. Não é possível desativar um registro de auditoria de acesso a dados que foi ativado na organização mãe do projeto.
Projetos: é possível configurar registros de auditoria de acesso a dados para um projetoTrusted Cloud individual. Não é possível desativar um registro de auditoria de acesso a dados que foi ativado em uma organização ou pasta mãe.
Contas de faturamento: para configurar registros de auditoria de acesso a dados para contas de faturamento, use a Google Cloud CLI. Para mais informações sobre como usar a CLI gcloud com registros de auditoria de acesso a dados e contas de faturamento, consulte a documentação de
gcloud beta billing accounts set-iam-policy
.Configurações padrão: é possível especificar uma configuração padrão de registro de auditoria de acesso a dados em uma organização, pasta ou projeto Trusted Cloud que se aplique a futuros serviços Trusted Cloud que comecem a produzir registros de auditoria de acesso a dados. Para instruções, consulte Definir a configuração padrão.
Tipos de permissão: é possível especificar que as APIs Trusted Cloud que verificam apenas um determinado tipo de permissão emitam um registro de auditoria. Para mais informações, consulte a seção Tipos de permissão desta página.
Principais isentas: é possível isentar principais específicas de ter os acessos de dados delas registrados. Por exemplo, é possível isentar suas contas de teste internas de ter as operações do Cloud Monitoring registradas. Para uma lista de participantes válidos, incluindo usuários e grupos, consulte a referência do tipo
Binding
.
É possível configurar os registros de auditoria de acesso a dados na página Registros de auditoria do IAM no console do Trusted Cloud ou usando a API. Esses métodos são explicados nas seções abaixo.
Tipos de permissão
Os métodos da API verificam as permissões do IAM. Cada permissão do IAM tem um tipo de permissão, que é definido pela propriedade type
.
Os tipos de permissão são categorizados como um tipo de permissão de acesso a dados ou como um tipo de permissão de atividade do administrador:
Tipos de permissão de acesso a dados:
ADMIN_READ
: as permissões do IAM desse tipo são verificadas para métodos da APITrusted Cloud que leem metadados ou informações de configuração. Normalmente, os registros de auditoria deADMIN_READ
ficam desativados por padrão e precisam ser ativados.DATA_READ
: as permissões do IAM desse tipo são verificadas para métodos da APITrusted Cloud que leem dados fornecidos pelo usuário. Normalmente, os registros de auditoria doDATA_READ
ficam desativados por padrão e precisam ser ativados.DATA_WRITE
: as permissões do IAM desse tipo são verificadas para métodos da APITrusted Cloud que gravam dados fornecidos pelo usuário. Normalmente, os registros de auditoria doDATA_WRITE
ficam desativados por padrão e precisam ser ativados.
Tipo de permissão de atividade do administrador:
ADMIN_WRITE
: as permissões do IAM desse tipo são verificadas para métodos da APITrusted Cloud que gravam metadados ou informações de configuração. Os registros de auditoria associados a esse tipo, registros de auditoria de atividade do administrador, ficam ativados por padrão e não podem ser desativados.
É possível ativar ou desativar tipos de permissão para serviços usando o consoleTrusted Cloud ou invocando a API.
A maioria das APIs Trusted Cloud verifica apenas se o autor da chamada tem uma única permissão do IAM. Se o tipo de permissão associado a essa permissão estiver ativado para o serviço cuja API está sendo chamada, a API vai gerar um registro de auditoria.
As seções a seguir descrevem outras maneiras pelas quais os métodos da API Trusted Cloudverificam as permissões do IAM. Para informações específicas do serviço sobre quais métodos são verificados para quais tipos de permissão, consulte a documentação de registros de auditoria do serviço.
Verificação de permissões do IAM para tipos de permissão de acesso a dados
Alguns métodos da API Trusted Cloud verificam se o autor da chamada tem várias permissões do IAM com diferentes tipos de permissão de acesso a dados. Um registro de auditoria é gravado quando um desses tipos de permissão de acesso a dados é ativado no projeto.
Por exemplo, um método de API pode verificar se o principal que emite uma solicitação de API tem as permissões example.resource.get
(DATA_READ
) e example.resource.write
(DATA_WRITE
). O projeto só precisa ter DATA_WRITE
ou DATA_READ
ativado para que o serviço emita o registro de auditoria ao fazer a chamada.
Tipos de permissão do IAM de atividade do administrador e acesso a dados verificados
Alguns métodos da API Trusted Cloud verificam uma permissão do IAM com o tipo ADMIN_WRITE
e uma ou mais permissões com o tipo de acesso a dados.
Esses tipos de chamadas de API emitem registros de auditoria de atividade do administrador, que são ativados por padrão e não podem ser desativados.
O método da API verifica permissões do IAM que não pertencem ao serviço
Alguns serviços Trusted Cloud têm métodos de API que geram um registro de auditoria somente quando um tipo de permissão específico está ativado para um serviço diferente.
Por exemplo, o Cloud Billing tem um método de API que verifica um tipo de permissão ADMIN_READ
pertencente ao Resource Manager. ADMIN_READ
precisa estar
ativado para o serviço cloudresourcemanager.googleapis.com
para ativar
o registro de auditoria associado à API Cloud Billing.
O mesmo método de API verifica diferentes permissões do IAM
Para algumas APIs Trusted Cloud , a forma como o método é chamado determina quais tipos de permissão do IAM precisam ser ativados no projeto para que um registro de auditoria seja gerado.
Por exemplo, o Spanner tem um método de API que às vezes verifica uma permissão do IAM com o tipo DATA_WRITE
e outras vezes com o tipo DATA_READ
, dependendo de como o método é chamado. Nesse caso, a ativação de DATA_WRITE
para o Spanner
no projeto em que a chamada de API é feita só ativa o registro de auditoria associado à API
quando a permissão do IAM com o tipo DATA_WRITE
é verificada.
Configurações específicas do serviço
Se houver uma configuração Trusted Cloud para todos os serviços (allServices
) e uma configuração para um serviço Trusted Cloud específico, a configuração resultante para o serviço será a união das duas configurações.
Resumindo:
É possível ativar registros de auditoria de acesso a dados para serviços específicos do Trusted Cloud, mas não é possível desativar os registros de auditoria de acesso a dados para serviços doTrusted Cloud ativados na configuração mais ampla.
É possível adicionar outros tipos de informações ao registro de auditoria de acesso a dados de um serviço do Trusted Cloud, mas não é possível remover os tipos de informações especificados na configuração mais ampla.
É possível adicionar principais a listas de isenção, mas não é possível removê-los dessas listas na configuração mais ampla.
Para o serviço de transferência de dados do BigQuery, a configuração do registro de auditoria de acesso a dados é herdada da configuração padrão.
Trusted Cloud configurações de recursos
É possível configurar os registros de auditoria de acesso a dados para projetos, contas de faturamento, pastas e organizações do Trusted Cloud . Se houver uma configuração para um serviçoTrusted Cloud em toda a hierarquia, a configuração resultante será a união das configurações. Em outras palavras, no nível do projetoTrusted Cloud :
É possível ativar os registros de um serviço do Trusted Cloud , mas não desativar os registros de um serviço do Trusted Cloud ativado em uma organização ou pasta pai.
É possível ativar tipos de informações, mas não é possível desativar os tipos que estão ativados em uma organização ou pasta pai.
É possível adicionar principais a listas de isenção, mas não é possível removê-los de listas de isenção em uma organização ou pasta mãe.
No nível de uma organização ou pasta mãe, é possível ativar os registros de auditoria de acesso a dados para um projeto Trusted Cloud dentro dessa organização ou pasta, mesmo que os registros de auditoria de acesso a dados não tenham sido configurados no projetoTrusted Cloud .
Controle de acesso
Os papéis e as permissões do gerenciamento de identidade e acesso regem o acesso aos dados do Logging, incluindo a visualização e o gerenciamento das políticas do IAM subjacentes às configurações de geração de registros de auditoria de acesso a dados.
Para visualizar ou definir as políticas associadas à configuração do acesso a dados, é preciso ter um papel com permissões no nível de recurso apropriado. Para instruções sobre como conceder esses papéis no nível do recurso, consulte Gerenciar o acesso a projetos, pastas e organizações do Trusted Cloud .
Para definir políticas do IAM, você precisa de um papel com a permissão
resourcemanager.RESOURCE_TYPE.setIamPolicy
.Para visualizar as políticas do IAM, você precisa de um papel com a permissão
resourcemanager.RESOURCE_TYPE.getIamPolicy
.
Para ver a lista de permissões e papéis necessários para visualizar os registros de auditoria de acesso a dados, consulte Controle de acesso com o IAM.
Configurar registros de auditoria de acesso a dados com o Trusted Cloud console
Esta seção explica como usar o console Trusted Cloud para configurar os registros de auditoria de acesso a dados.
Também é possível usar a API ou a Google Cloud CLI para executar essas tarefas de maneira programática. Consulte Configurar registros de auditoria de acesso a dados com a API para mais detalhes.
Para acessar as opções de configuração do registro de auditoria no console do Trusted Cloud , siga estas etapas:
-
No console Trusted Cloud , acesse a página Registros de auditoria:
Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo IAM e administrador.
Selecione um projeto, uma pasta ou uma organização Trusted Cloud .
Ativar registros de auditoria
Para ativar os registros de auditoria de acesso a dados, faça o seguinte:
Na tabela Configuração dos registros de auditoria de acesso a dados, selecione um ou mais Trusted Cloud serviços na coluna Serviço.
Na guia Tipos de permissão, selecione os tipos de registro de auditoria de acesso a dados que você quer ativar para os serviços selecionados.
Clique em Salvar.
A tabela inclui um ícone de check_circle Verificação onde os registros de auditoria foram ativados com êxito.
No exemplo a seguir, você vê que, para o serviço Aprovação de acesso, o tipo de registro de auditoria Leitura de dados está ativado:
Também é possível ativar registros de auditoria para todos os serviços do Trusted Cloud que produzem registros de auditoria de acesso a dados. Na tabela Configuração dos registros de auditoria de acesso a dados, selecione todos os serviços Trusted Cloud .
Esse método de configuração em massa se aplica apenas aos serviços do Trusted Cloud disponíveis para seu recurso. Se um novo serviço doTrusted Cloud for adicionado, ele vai herdar sua configuração de auditoria padrão.
Desativar registros de auditoria do Data Access
Para desativar os registros de auditoria de acesso a dados, faça o seguinte:
Na tabela Configuração de registros de auditoria de acesso a dados, selecione um ou mais serviços doTrusted Cloud .
Na guia Tipos de registro no painel de informações, selecione os tipos de registro de auditoria de acesso a dados que você quer desativar para os serviços selecionados.
Clique em Salvar.
Quando você desativa os registros de auditoria de acesso a dados, a tabela indica isso com um traço. Todos os registros de auditoria de acesso a dados ativados são indicados com um ícone de check_circle marca de seleção.
Definir isenções
É possível definir isenções para controlar quais principais geram registros de auditoria de acesso a dados para serviços específicos. Quando você adiciona um principal isento, os registros de auditoria não são criados para ele nos tipos de registro selecionados.
Para definir isenções, faça o seguinte:
Na tabela Configuração dos registros de auditoria de acesso a dados, selecione um serviçoTrusted Cloud na coluna Serviço.
Selecione a guia Principais isentos no painel de informações.
Em Adicionar principal isenta, insira o principal que você quer isentar da geração de registros de auditoria de acesso a dados para o serviço selecionado.
Você pode adicionar várias pessoas autorizadas clicando no botão Adicionar pessoa autorizada isenta quantas vezes forem necessárias.
Para uma lista de participantes válidos, incluindo usuários e grupos, consulte a referência do tipo
Binding
.Em Tipos de registro desativados, selecione os tipos de registro de auditoria de acesso a dados que você quer desativar.
Clique em Salvar.
Quando você adiciona principais isentos a um serviço, a tabela Configuração dos registros de auditoria de acesso a dados indica isso com um número na coluna Principais isentos.
Para remover um principal da sua lista de isenções, faça o seguinte:
Na tabela Configuração dos registros de auditoria de acesso a dados, selecione um serviçoTrusted Cloud na coluna Serviço.
Selecione a guia Principais isentos no painel de informações.
Passe o cursor sobre um nome de principal e selecione
Excluir.Quando o nome do principal for mostrado em texto riscado, clique em Salvar.
Para editar as informações de um principal isento, faça o seguinte:
Na tabela Configuração dos registros de auditoria de acesso a dados, selecione um serviçoTrusted Cloud na coluna Serviço.
Selecione a guia Principais isentos no painel de informações.
Localize o principal e selecione expandir expand_more Mostrar mais.
Marque ou desmarque os tipos de registro de auditoria de acesso a dados conforme apropriado para o principal.
Clique em Salvar.
Definir a configuração padrão
É possível definir uma configuração que todos os serviços novos e atuais do Trusted Cloud no seu projeto, pasta ou organização do Trusted Cloud herdarão. A configuração padrão será aplicada se um novo serviço do Trusted Cloud começar a ser usado pelos principais na organização: o serviço vai herdar a política de auditoria de registros já definida para outros serviços doTrusted Cloud , garantindo a captura dos registros de auditoria de acesso a dados.
Para definir ou editar a configuração padrão, faça o seguinte:
Clique em Definir configuração padrão.
Na guia Tipos de registro no painel de informações, selecione os tipos de registro de auditoria de acesso a dados que você quer ativar ou desativar.
Clique em Salvar.
Selecione a guia Principais isentos no painel de informações.
Em Adicionar principal isenta, insira o principal que você quer isentar da geração de registros de auditoria de acesso a dados para o serviço selecionado.
Você pode adicionar várias pessoas autorizadas clicando no botão Adicionar pessoa autorizada isenta quantas vezes forem necessárias.
Para uma lista de participantes válidos, incluindo usuários e grupos, consulte a referência do tipo
Binding
.Em Tipos de registro desativados, selecione os tipos de registro de auditoria de acesso a dados que você quer desativar.
Clique em Salvar.
Como configurar registros de auditoria do Data Access com a API
Nesta seção, explicamos como usar a API e a CLI gcloud para configurar os registros de auditoria de acesso a dados de maneira programática.
Muitas dessas tarefas também podem ser realizadas usando o console do Trusted Cloud . Para instruções, consulte Configurar registros de auditoria de acesso a dados com o console do Trusted Cloud nesta página.
Objetos de política de IAM
Para configurar os registros de auditoria do acesso a dados usando a API, é necessário editar a
política de IAM associada ao seu projeto, pasta
ou organização do Trusted Cloud . A configuração do registro de auditoria está na seção auditConfigs
da
política:
"auditConfigs": [
{
object(AuditConfig)
}
]
Para ver detalhes, consulte o tipo de política de IAM.
As seções a seguir descrevem o objeto AuditConfig
em mais detalhes.
Para a API e os comandos da CLI gcloud usados para mudar a configuração,
consulte a seção intitulada
getIamPolicy
e setIamPolicy
.
AuditConfig
objetos
A configuração do registro de auditoria consiste em uma lista de objetos
AuditConfig
. Cada objeto configura os registros para um serviço ou estabelece uma
configuração mais abrangente para todos os serviços. Esta é a aparência de cada objeto:
{
"service": SERVICE_NAME,
"auditLogConfigs": [
{
"logType": "ADMIN_READ"
"exemptedMembers": [ PRINCIPAL,]
},
{
"logType": "DATA_READ"
"exemptedMembers": [ PRINCIPAL,]
},
{
"logType": "DATA_WRITE"
"exemptedMembers": [ PRINCIPAL,]
},
]
},
SERVICE_NAME tem um valor como "appengine.googleapis.com"
ou é o valor especial "allServices"
. Se uma configuração não mencionar um serviço
específico, a configuração mais abrangente será usada para esse serviço. Se não houver
configuração, os registros de auditoria de acesso a dados não serão ativados para esse serviço.
Para ver uma lista dos nomes de serviços,
consulte Serviços de registro.
A seção auditLogConfigs
do objeto AuditConfig
é uma lista de 0 a 3
objetos, cada um deles configura um tipo de informação do registro de auditoria. Se você omitir
um dos tipos da lista, esse tipo de informação não estará ativado
para o serviço.
PRINCIPAL é um usuário de quem os registros de auditoria de acesso a dados não são coletados. O
tipo Binding
descreve diferentes tipos de principais, incluindo
usuários e grupos, mas nem todos podem ser usados para configurar registros de auditoria de acesso a
dados.
Veja a seguir um exemplo de uma configuração de auditoria nos formatos JSON e YAML. O formato YAML é o padrão ao usar a Google Cloud CLI.
JSON
"auditConfigs": [
{
"auditLogConfigs": [
{
"logType": "ADMIN_READ"
},
{
"logType": "DATA_WRITE"
},
{
"logType": "DATA_READ"
}
],
"service": "allServices"
},
{
"auditLogConfigs": [
{
"exemptedMembers": [
"499862534253-compute@developer.s3ns-system.iam.gserviceaccount.com"
],
"logType": "ADMIN_READ"
}
],
"service": "cloudsql.googleapis.com"
}
],
YAML
auditConfigs:
- auditLogConfigs:
- logType: ADMIN_READ
- logType: DATA_WRITE
- logType: DATA_READ
service: allServices
- auditLogConfigs:
- exemptedMembers:
- 499862534253-compute@developer.s3ns-system.iam.gserviceaccount.com
logType: ADMIN_READ
service: cloudsql.googleapis.com
Configurações comuns
Confira a seguir algumas configurações comuns de registro de auditoria para projetos do Trusted Cloud .
Ativar todos os registros de auditoria do Data Access
A seção auditConfigs
a seguir ativa registros de auditoria de acesso a dados para todos
os serviços e principais:
JSON
"auditConfigs": [
{
"service": "allServices",
"auditLogConfigs": [
{ "logType": "ADMIN_READ" },
{ "logType": "DATA_READ" },
{ "logType": "DATA_WRITE" },
]
},
]
YAML
auditConfigs:
- auditLogConfigs:
- logType: ADMIN_READ
- logType: DATA_WRITE
- logType: DATA_READ
service: allServices
Ativar um tipo de informação e serviço
A configuração a seguir ativa os registros de auditoria de acesso a dados do DATA_WRITE
para o
Cloud SQL:
JSON
"auditConfigs": [
{
"service": "cloudsql.googleapis.com",
"auditLogConfigs": [
{ "logType": "DATA_WRITE" },
]
},
]
YAML
auditConfigs:
- auditLogConfigs:
- logType: DATA_WRITE
service: cloudsql.googleapis.com
Desativar todos os registros de auditoria do Data Access
Para desativar todos os registros de auditoria de acesso a dados (exceto BigQuery) em um projetoTrusted Cloud , inclua uma seção auditConfigs:
vazia na nova política de IAM:
JSON
"auditConfigs": [],
YAML
auditConfigs:
Se você remover completamente a seção auditConfigs
da nova política,
o setIamPolicy
não alterará a configuração dos registros de auditoria
de acesso a dados. Para mais informações, consulte a seção A máscara de atualização setIamPolicy
.
Não é possível desativar os registros de auditoria do acesso a dados do BigQuery.
getIamPolicy
e setIamPolicy
Use os métodos getIamPolicy
e setIamPolicy
da API Cloud Resource Manager para ler
e gravar sua política do IAM. Existem várias opções, dependendo do método escolhido:
A API Cloud Resource Manager tem os seguintes métodos:
projects.getIamPolicy projects.setIamPolicy organizations.getIamPolicy organizations.setIamPolicy
A Google Cloud CLI tem os seguintes comandos do Resource Manager:
gcloud projects get-iam-policy gcloud projects set-iam-policy gcloud resource-manager folders get-iam-policy gcloud resource-manager folders set-iam-policy gcloud organizations get-iam-policy gcloud organizations set-iam-policy gcloud beta billing accounts get-iam-policy gcloud beta billing accounts set-iam-policy
Seja qual for sua escolha, siga estes três passos:
- Leia a política atual usando um dos métodos
getIamPolicy
. Salve a política em um arquivo temporário. - Edite a política no arquivo temporário.
Alterar (ou adicionar) somente a seção
auditConfigs
. - Grave a política editada no arquivo temporário
usando um dos métodos
setIamPolicy
.
setIamPolicy
falhará se o Resource Manager detectar que outra pessoa
alterou a política depois que você a leu na primeira etapa. Se isso acontecer,
repita as três etapas.
Exemplos
Os exemplos a seguir demonstram como configurar os registros de auditoria de acesso a dados do projeto usando o comando gcloud
e a API Cloud Resource Manager.
Para configurar registros de auditoria do acesso a dados da organização, substitua a versão "projetos" dos comandos e dos métodos de API pela versão "organizações".
gcloud
Para configurar os registros de auditoria de acesso a dados usando
o comando gcloud projects
,
faça o seguinte:
Leia a política de IAM do projeto e guarde-a em um arquivo:
gcloud projects get-iam-policy PROJECT_ID > /tmp/policy.yaml
Confira abaixo a política retornada. Esta política ainda não tem uma seção
auditConfigs
:bindings: - members: - user:colleague@example.com role: roles/editor - members: - user:myself@example.com role: roles/owner etag: BwVM-FDzeYM= version: 1
Edite sua política em
/tmp/policy.yaml
, adicionando ou alterando apenas a configuração dos registros de auditoria de acesso a dados.Confira abaixo um exemplo da política editada, que ativa os registros de auditoria do acesso a dados de gravação do Cloud SQL:
auditConfigs: - auditLogConfigs: - logType: DATA_WRITE service: cloudsql.googleapis.com bindings: - members: - user:colleague@example.com role: roles/editor - members: - user:myself@example.com role: roles/owner etag: BwVM-FDzeYM= version: 1
Como mostrado no exemplo anterior, quatro linhas foram adicionadas ao início da política.
Grave a nova política de IAM:
gcloud projects set-iam-policy PROJECT_ID /tmp/policy.yaml
Se o comando anterior relatar um conflito com outra alteração, repita essas etapas, começando pela primeira delas.
JSON
Para trabalhar com sua política de IAM no formato JSON em vez de YAML,
substitua os seguintes comandos gcloud
no exemplo:
gcloud projects get-iam-policy PROJECT_ID --format=json >/tmp/policy.json
gcloud projects set-iam-policy PROJECT_ID /tmp/policy.json
API
Para configurar seus registros de auditoria do acesso a dados usando a API Cloud Resource Manager, siga estas instruções:
Leia a política do IAM do projeto que especifica os seguintes parâmetros para o método da API getIamPolicy:
- recurso:
projects/PROJECT_ID
- Corpo da solicitação: vazio
O método retorna o objeto de política atual:
{ "version": 1, "etag": "BwXqwxkr40M=", "bindings": [ { "role": "roles/owner", "members": [ "user:myself@example.com" ] } ] }
O exemplo anterior mostra que a política do projeto não tem uma seção
auditConfigs
.- recurso:
Edite a política atual:
Altere ou adicione a seção
auditConfigs
.Para desativar os registros de auditoria de acesso a dados, inclua um valor vazio para a seção:
auditConfigs:[]
.Preserve o valor de
etag
.
Também é possível remover todas as outras informações do novo objeto de política, desde que você tenha cuidado para definir
updateMask
na próxima etapa. Confira abaixo a política editada, que ativa os registros de auditoria do Cloud SQLDATA_WRITE
:{ "policy": { "auditConfigs": [ { "auditLogConfigs": [ { "logType": "DATA_WRITE" } ], "service": "cloudsql.googleapis.com" } ], "etag": "BwXqwxkr40M=" }, "updateMask": "auditConfigs,etag" }
Grave a nova política usando o método da API
setIamPolicy
, especificando os seguintes parâmetros:- recurso:
projects/PROJECT_ID
- Corpo da solicitação: inclua a política editada.
- recurso:
A máscara de atualização setIamPolicy
Esta seção explica a importância do parâmetro updateMask
no
método setIamPolicy
e explica por que você precisa ter cuidado com o
comando set-iam-policy
da CLI gcloud para não causar
danos acidentais ao projeto ou organização Trusted Cloud .
O método da API setIamPolicy
usa um parâmetro updateMask
para controlar quais campos de política são atualizados. Por exemplo, se a máscara não
contiver bindings
, não será possível alterar acidentalmente essa seção de política. Por
outro lado, se a máscara contiver bindings
, essa seção será
sempre atualizada. Se você não incluir um valor atualizado para bindings
, essa
seção será removida totalmente da política.
O comando gcloud projects set-iam-policy
, que chama setIamPolicy
,
não permite que você especifique o parâmetro updateMask
. Em vez disso, o comando
calcula um valor para updateMask
da seguinte maneira:
- O
updateMask
sempre contém os camposbindings
eetag
. - Se o objeto de política fornecido em
set-iam-policy
contiver outros campos de nível superior, comoauditConfigs
, esses campos serão adicionados aupdateMask
.
Como consequência dessas regras, o comando set-iam-policy
tem os seguintes
comportamentos:
Se você omitir a seção
auditConfigs
na nova política, o valor anterior da seçãoauditConfigs
(se houver) não será alterado, porque essa seção não está na máscara de atualização. Isso é inofensivo, mas pode ser confuso.Se você omitir
bindings
no novo objeto de política, a seçãobindings
será removida da sua política, já que essa seção aparece na máscara de atualização. Isso é muito prejudicial e faz com que todos os principais percam o acesso ao projeto Trusted Cloud .Se você omitir
etag
no novo objeto de política, a verificação de alterações simultâneas em sua política será desativada e suas alterações poderão resultar na substituição acidental das alterações de outra pessoa.