Ative os registos de auditoria de acesso a dados

Este guia explica como ativar ou desativar alguns ou todos os registos de auditoria de acesso a dados nos seusTrusted Cloud projetos, contas de faturação, pastas e organizações através da Trusted Cloud consola ou da API.

Antes de começar

Antes de continuar com a configuração dos registos de auditoria de acesso a dados, compreenda as seguintes informações:

• Os registos de auditoria de acesso aos dados, exceto para o BigQuery, estão desativados por predefinição. Se quiser que os registos de auditoria de acesso aos dados sejam escritos para Trusted Cloud serviços que não sejam o BigQuery, tem de os ativar explicitamente.

• Os registos de auditoria de acesso aos dados são armazenados no contentor _Default, a menos que os tenha encaminhado para outro local. Para mais informações, consulte o artigo Armazenar e encaminhar registos de auditoria.

• Os registos de auditoria de acesso aos dados ajudam o apoio técnico da Google a resolver problemas com a sua conta. Por conseguinte, recomendamos que ative os registos de auditoria de acesso aos dados sempre que possível.

• Para receber as autorizações de que precisa para aceder a todos os registos nos contentores _Required e _Default, incluindo os registos de acesso aos dados, peça ao seu administrador que lhe conceda a função do IAM Visualizador de registos privados (roles/logging.privateLogViewer) no seu projeto.

  A função Leitor de registos privados (roles/logging.privateLogViewer) inclui as autorizações contidas na função Leitor de registos (roles/logging.viewer) e as necessárias para ler os registos de auditoria de acesso aos dados no contentor _Default.

  A função de editor (roles/editor) não inclui as autorizações necessárias para ver os registos de acesso aos dados.

  Para mais informações acerca das autorizações e funções da IAM que se aplicam aos dados dos registos de auditoria, consulte o artigo Controlo de acesso com a IAM.

Vista geral da configuração

Pode configurar a forma como os registos de auditoria de acesso a dados são ativados para os seus Trusted Cloud recursos e serviços:

• Organizações: pode ativar e configurar registos de auditoria de acesso aos dados numa organização, o que se aplica a todos os projetos e pastas existentes e novos na organização.Trusted Cloud

• Pastas: pode ativar e configurar os registos de auditoria de acesso a dados numa pasta, que se aplica a todos os projetos existentes e novos na pasta. Trusted Cloud Não pode desativar um registo de auditoria de acesso a dados que foi ativado na organização principal do projeto.

• Projetos: pode configurar os registos de auditoria de acesso a dados para um Trusted Cloud projeto individual. Não pode desativar um registo de auditoria de acesso aos dados que foi ativado numa organização ou pasta principal.

• Contas de faturação: para configurar os registos de auditoria de acesso a dados para contas de faturação, use a Google Cloud CLI. Para mais informações sobre a utilização da CLI gcloud com registos de auditoria de acesso a dados e contas de faturação, consulte a documentação gcloud beta billing accounts set-iam-policy.

• Configurações predefinidas: pode especificar uma configuração predefinida do registo de auditoria de acesso a dados numa organização, numa pasta ou num Trusted Cloud projeto que se aplica a serviços Trusted Cloud futuros que comecem a produzir registos de auditoria de acesso a dados. Para ver instruções, consulte o artigo Defina a configuração predefinida.

• Tipos de autorização: pode especificar que as Trusted Cloud APIs que apenas verificam um determinado tipo de autorização emitem um registo de auditoria. Para mais informações, consulte a secção Tipos de autorizações desta página.

• Diretores isentos: pode isentar diretores específicos de terem os respetivos acessos aos dados registados. Por exemplo, pode isentar as suas contas de testes internos de terem as respetivas operações do Cloud Monitoring registadas. Para ver uma lista de responsáveis válidos, incluindo utilizadores e grupos, consulte a referência do tipo Binding.

Pode configurar os registos de auditoria de acesso aos dados através da página Registos de auditoria do IAM na Trusted Cloud consola ou através da API. Estes métodos são explicados nas secções seguintes.

Tipos de autorização

Os métodos da API verificam as autorizações de IAM. Cada autorização de IAM tem um tipo de autorização, que é definido pela propriedade type. Os tipos de autorizações são categorizados como um tipo de autorização de acesso aos dados ou como um tipo de autorização de atividade de administrador:

• Tipos de autorização de acesso a dados:

  • ADMIN_READ: as autorizações da IAM deste tipo são verificadas para Trusted Cloud métodos da API que leem metadados ou informações de configuração. Normalmente, os ADMIN_READregistos de auditoria estão desativados por predefinição e têm de ser ativados.

  • DATA_READ: as autorizações do IAM deste tipo são verificadas para Trusted Cloud métodos de API que leem dados fornecidos pelos utilizadores. Normalmente, DATA_READ os registos de auditoria estão desativados por predefinição e têm de ser ativados.

  • DATA_WRITE: as autorizações do IAM deste tipo são verificadas para Trusted Cloud métodos de API que escrevem dados fornecidos pelo utilizador. Normalmente, DATA_WRITE os registos de auditoria estão desativados por predefinição e têm de ser ativados.

• Tipo de autorização de atividade de administrador:

  • ADMIN_WRITE: as autorizações da IAM deste tipo são verificadas para Trusted Cloud métodos da API que escrevem metadados ou informações de configuração. Os registos de auditoria associados a este tipo, os registos de auditoria da atividade de administrador, estão ativados por predefinição e não podem ser desativados.

Pode ativar ou desativar tipos de autorizações para serviços através da Trusted Cloud consola ou invocando a API.

A maioria das Trusted Cloud APIs só verifica se o autor da chamada tem uma única autorização do IAM. Se o tipo de autorização associado a essa autorização estiver ativado para o serviço cuja API está a ser chamada, a API gera um registo de auditoria.

As secções seguintes descrevem geralmente outras formas como os métodos da API verificam as autorizações de IAM. Trusted CloudPara obter informações específicas do serviço sobre os métodos verificados para cada tipo de autorização, consulte a documentação de registo de auditoria do serviço.

Verificação das autorizações da IAM para tipos de autorizações de acesso a dados

Alguns Trusted Cloud métodos da API verificam se o autor da chamada tem várias autorizações da IAM com diferentes tipos de autorizações de acesso aos dados. É escrito um registo de auditoria quando um desses tipos de autorização de acesso a dados é ativado no projeto.

Por exemplo, um método API pode verificar se o principal que emite um pedido API tem as autorizações example.resource.get (DATA_READ) e example.resource.write (DATA_WRITE). O projeto só precisa de ter DATA_WRITE ou DATA_READ ativado para que o serviço emita o registo de auditoria quando emitir a chamada.

Tipos de autorizações IAM de acesso a dados e atividade de administrador selecionados

Alguns métodos da API verificam uma autorização de IAM que tem o tipo de autorização ADMIN_WRITE e uma ou mais autorizações que têm um tipo de autorização de acesso aos dados. Trusted Cloud

Estes tipos de chamadas API emitem registos de auditoria da atividade de administrador, que estão ativados por predefinição e não podem ser desativados.

O método da API verifica as autorizações da IAM que não são propriedade do serviço

Alguns Trusted Cloud serviços têm métodos de API que geram um registo de auditoria apenas quando um tipo de autorização específico está ativado para um serviço diferente.

Por exemplo, a Cloud Billing tem um método de API que verifica um ADMIN_READ tipo de autorização pertencente ao Resource Manager. ADMIN_READ tem de estar ativado para o serviço cloudresourcemanager.googleapis.com para ativar o registo de auditoria associado à API Cloud Billing.

O mesmo método da API verifica diferentes autorizações de IAM

Para algumas Trusted Cloud APIs, a forma como o método é chamado determina que tipos de autorizações do IAM têm de ser ativados no projeto para gerar um registo de auditoria.

Por exemplo, o Spanner tem um método de API que, por vezes, verifica uma autorização de IAM com o tipo DATA_WRITE e, por vezes, verifica uma autorização de IAM com o tipo DATA_READ, consoante a forma como o método é chamado. Neste caso, a ativação da DATA_WRITE para o Spanner no projeto, a chamada API só ativa o registo de auditoria associado à API quando a autorização do IAM com o tipo DATA_WRITE é verificada.

Configurações específicas do serviço

Se existir uma configuração Trusted Cloud ao nível do serviço (allServices) e uma configuração para um Trusted Cloud serviço específico, a configuração resultante para o serviço é a união das duas configurações. Por outras palavras:

• Pode ativar os registos de auditoria de acesso a dados para serviços Trusted Cloud específicos, mas não pode desativar os registos de auditoria de acesso a dados para Trusted Cloud serviços ativados na configuração mais ampla.

• Pode adicionar tipos de informações adicionais ao registo de auditoria de acesso aos dados de um serviço, mas não pode remover tipos de informações especificados na configuração mais ampla. Trusted Cloud

• Pode adicionar responsáveis a listas de isenções, mas não os pode remover das listas de isenções na configuração mais ampla.

• Para o Serviço de transferência de dados do BigQuery, a configuração do registo de auditoria de acesso a dados é herdada da configuração do registo de auditoria predefinida.

Trusted Cloud configurações de recursos

Pode configurar os registos de auditoria de acesso a dados para Trusted Cloud projetos, contas de faturação, pastas e organizações. Se existir uma configuração para um Trusted Cloud serviço na hierarquia, a configuração resultante é a união das configurações. Por outras palavras, aoTrusted Cloud nível do projeto:

• Pode ativar os registos de um Trusted Cloud serviço, mas não pode desativar os registos de um Trusted Cloud serviço que esteja ativado numa organização ou pasta principal.

• Pode ativar tipos de informações, mas não pode desativar tipos de informações ativados numa organização ou pasta principal.

• Pode adicionar responsáveis a listas de isenções, mas não os pode remover de listas de isenções numa organização ou pasta principal.

• Ao nível de uma organização principal ou de uma pasta, pode ativar os registos de auditoria de acesso a dados para um projeto nessa organização ou pasta, mesmo que os registos de auditoria de acesso a dados não tenham sido configurados no projeto. Trusted Cloud Trusted Cloud

Controlo de acesso

As funções e as autorizações da gestão de identidade e de acesso regem o acesso aos dados de registo, incluindo a visualização e a gestão das políticas de IAM subjacentes às configurações de registo de auditoria de acesso a dados.

Para ver ou definir as políticas associadas à configuração de acesso aos dados, precisa de uma função com autorizações ao nível do recurso adequado. Para instruções sobre como conceder estas funções ao nível do recurso, consulte o artigo Faça a gestão do acesso a Trusted Cloud projetos, pastas e organizações.

• Para definir políticas de IAM, precisa de uma função com a autorização resourcemanager.RESOURCE_TYPE.setIamPolicy.

• Para ver as políticas de IAM, precisa de uma função com a autorização resourcemanager.RESOURCE_TYPE.getIamPolicy.

Para ver a lista das autorizações e das funções necessárias para ver os registos de auditoria de acesso aos dados, consulte o artigo Controlo de acesso com a IAM.

Configure registos de auditoria de acesso a dados com a Trusted Cloud consola

Esta secção explica como usar a Trusted Cloud consola para configurar os registos de auditoria de acesso aos dados.

Também pode usar a API ou a CLI Google Cloud para realizar estas tarefas de forma programática. Consulte o artigo Configure registos de auditoria de acesso aos dados com a API para ver detalhes.

Para aceder às opções de configuração do registo de auditoria na Trusted Cloud consola, siga estes passos:

1. Na Trusted Cloud consola, aceda à página Registos de auditoria:

   Aceda a Registos de auditoria

   Se usar a barra de pesquisa para encontrar esta página, selecione o resultado cujo subtítulo é IAM e administração.

2. Selecione um Trusted Cloud projeto, uma pasta ou uma organização existente.

Ative os registos de auditoria

Para ativar os registos de auditoria de acesso a dados, faça o seguinte:

1. Na tabela Configuração dos registos de auditoria de acesso aos dados, selecione um ou mais Trusted Cloud serviços na coluna Serviço.

2. No separador Tipos de autorizações, selecione os tipos de registos de auditoria de acesso a dados que quer ativar para os serviços selecionados.

3. Clique em Guardar.

Quando ativa com êxito os registos de auditoria, a tabela inclui um ícone de check_circle marca de verificação.

No exemplo seguinte, pode ver que, para o serviço Access Approval, o tipo de registo de auditoria Data Read está ativado:

Também pode ativar os registos de auditoria para todos os Trusted Cloud serviços que produzem registos de auditoria de acesso a dados. Na tabela Configuração dos registos de auditoria de acesso aos dados, selecione todos os Trusted Cloud serviços.

Tenha em atenção que este método de configuração em massa se aplica apenas aos Trusted Cloud serviços disponíveis para o seu recurso. Se for adicionado um novo Trusted Cloud serviço, este herda a sua configuração de auditoria predefinida.

Desative os registos de auditoria de acesso aos dados

Para desativar os registos de auditoria de acesso a dados, faça o seguinte:

1. Na tabela Configuração dos registos de auditoria de acesso aos dados, selecione um ou mais Trusted Cloud serviços.

2. No separador Tipos de registos no painel de informações, selecione os tipos de registos de auditoria de acesso aos dados que quer desativar para os serviços selecionados.

3. Clique em Guardar.

Quando desativou com êxito os registos de auditoria de acesso a dados, a tabela indica-o com um traço. Todos os registos de auditoria de acesso a dados ativados são indicados com um ícone de check_circle marca de verificação.

Defina isenções

Pode definir isenções para controlar que responsáveis geram registos de auditoria de acesso a dados para serviços específicos. Quando adiciona um principal isento, não são criados registos de auditoria para o mesmo para os tipos de registos selecionados.

Para definir isenções, faça o seguinte:

1. Na tabela Configuração dos registos de auditoria de acesso aos dados, selecione um Trusted Cloud serviço na coluna Serviço.

2. Selecione o separador Diretores isentos no painel de informações.

3. Em Adicionar principal isento, introduza o principal que quer isentar da geração de registos de auditoria de acesso a dados para o serviço selecionado.

   Pode adicionar vários responsáveis clicando no botão Adicionar responsável isento quantas vezes forem necessárias.

   Para ver uma lista de responsáveis válidos, incluindo utilizadores e grupos, consulte a referência do tipo Binding.

4. Em Tipos de registos desativados, selecione os tipos de registos de auditoria de acesso aos dados que quer desativar.

5. Clique em Guardar.

Quando adiciona com êxito responsáveis isentos a um serviço, a tabela Configuração dos registos de auditoria de acesso aos dados indica-o com um número na coluna Responsáveis isentos.

Para remover um principal da sua lista de isenções, faça o seguinte:

1. Na tabela Configuração dos registos de auditoria de acesso aos dados, selecione um Trusted Cloud serviço na coluna Serviço.

2. Selecione o separador Diretores isentos no painel de informações.

3. Passe o cursor sobre um nome principal e, de seguida, selecione delete Eliminar.

4. Depois de o nome do diretor ser apresentado com texto rasurado, clique em Guardar.

Para editar as informações de um principal isento, faça o seguinte:

1. Na tabela Configuração dos registos de auditoria de acesso aos dados, selecione um Trusted Cloud serviço na coluna Serviço.

2. Selecione o separador Diretores isentos no painel de informações.

3. Localize o principal e selecione expandir expand_more Mostrar mais.

4. Selecione ou desmarque os tipos de registos de auditoria de acesso a dados conforme adequado para o principal.

5. Clique em Guardar.

Defina a configuração predefinida

Pode definir uma configuração que todos os serviços novos e existentes Trusted Cloud no seu Trusted Cloud projeto, pasta ou organização herdam. A definição desta configuração predefinida aplica-se se um novo serviço Trusted Cloud ficar disponível e os principais na sua organização começarem a usá-lo: o serviço herda a política de registo de auditoria que já definiu para outros serviçosTrusted Cloud , garantindo que os registos de auditoria de acesso aos dados são capturados.

Para definir ou editar a configuração predefinida, faça o seguinte:

1. Clique em Predefinir configuração.

2. No separador Tipos de registos no painel de informações, selecione os tipos de registos de auditoria de acesso aos dados que quer ativar ou desativar.

3. Clique em Guardar.

4. Selecione o separador Diretores isentos no painel de informações.

5. Em Adicionar principal isento, introduza o principal que quer isentar da geração de registos de auditoria de acesso a dados para o serviço selecionado.

   Pode adicionar vários responsáveis clicando no botão Adicionar responsável isento quantas vezes forem necessárias.

   Para ver uma lista de responsáveis válidos, incluindo utilizadores e grupos, consulte a referência do tipo Binding.

6. Em Tipos de registos desativados, selecione os tipos de registos de auditoria de acesso aos dados que quer desativar.

7. Clique em Guardar.

Configure os registos de auditoria de acesso a dados com a API

Esta secção explica como usar a API e a CLI gcloud para configurar os registos de auditoria de acesso aos dados de forma programática.

Muitas destas tarefas também podem ser realizadas através da Trusted Cloud consola; para obter instruções, consulte Configure os registos de auditoria de acesso aos dados com a Trusted Cloud consola nesta página.

Objetos de políticas IAM

Para configurar os registos de auditoria de acesso aos dados através da API, tem de editar a política de IAM associada ao seu Trusted Cloud projeto, pasta ou organização. A configuração do registo de auditoria encontra-se na secção auditConfigs da política:

"auditConfigs": [
  {
    object(AuditConfig)
  }
]

Para obter detalhes, consulte o tipo de política do IAM.

As secções seguintes descrevem o objeto AuditConfig mais detalhadamente. Para os comandos da API e da CLI gcloud usados para alterar a configuração, consulte a secção intitulada getIamPolicy e setIamPolicy.

AuditConfig objetos

A configuração do registo de auditoria consiste numa lista de objetos AuditConfig. Cada objeto configura os registos de um serviço ou estabelece uma configuração mais ampla para todos os serviços. Cada objeto tem o seguinte aspeto:

{
  "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, é usada a configuração mais abrangente para esse serviço. Se não existir nenhuma configuração, os registos de auditoria de acesso a dados não estão ativados para esse serviço. Para ver uma lista dos nomes dos serviços, consulte o artigo Serviços de registo.

A secção auditLogConfigs do objeto AuditConfig é uma lista de 0 a 3 objetos, cada um dos quais configura um tipo de informação de registo de auditoria. Se omitir um dos tipos da lista, esse tipo de informações não é ativado para o serviço.

PRINCIPAL é um utilizador para o qual os registos de auditoria de acesso aos dados não são recolhidos. O tipo Binding descreve diferentes tipos de responsáveis, incluindo utilizadores e grupos, mas nem todos podem ser usados para configurar registos de auditoria de acesso aos dados.

Segue-se um exemplo de uma configuração de auditoria nos formatos JSON e YAML. O formato YAML é o predefinido quando usa a CLI do Google Cloud.

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

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

Seguem-se algumas configurações comuns de registo de auditoria para Trusted Cloud projetos.

Ative todos os registos de auditoria de acesso a dados

A secção auditConfigs seguinte ativa os registos de auditoria de acesso a dados para todos os serviços e responsáveis:

"auditConfigs": [
      {
        "service": "allServices",
        "auditLogConfigs": [
          { "logType": "ADMIN_READ" },
          { "logType": "DATA_READ"  },
          { "logType": "DATA_WRITE" },
        ]
      },
    ]

auditConfigs:
- auditLogConfigs:
  - logType: ADMIN_READ
  - logType: DATA_WRITE
  - logType: DATA_READ
  service: allServices

Ative um tipo de serviço e informações

A seguinte configuração ativa os registos de auditoria de acesso a dados do DATA_WRITE para o Cloud SQL:

"auditConfigs": [
  {
    "service": "cloudsql.googleapis.com",
    "auditLogConfigs": [
      { "logType": "DATA_WRITE" },
    ]
  },
]

auditConfigs:
- auditLogConfigs:
  - logType: DATA_WRITE
  service: cloudsql.googleapis.com

Desative todos os registos de auditoria de acesso aos dados

Para desativar todos os registos de auditoria de acesso aos dados (exceto o BigQuery) num projetoTrusted Cloud , inclua uma secção auditConfigs: vazia na nova política de IAM:

"auditConfigs": [],

auditConfigs:

Se remover completamente a secção auditConfigs da sua nova política, setIamPolicy não altera a configuração dos registos de auditoria de acesso aos dados existentes. Para mais informações, consulte a secção intitulada A setIamPolicymáscara de atualização.

Não é possível desativar os registos de auditoria de acesso aos dados do BigQuery.

getIamPolicy e setIamPolicy

Utiliza os métodos getIamPolicy e setIamPolicy da API Cloud Resource Manager para ler e escrever a sua política de IAM. Tem várias opções para os métodos específicos a usar:

• A API Cloud Resource Manager tem os seguintes métodos:

  projects.getIamPolicy
  projects.setIamPolicy
  organizations.getIamPolicy
  organizations.setIamPolicy
  

• A CLI gcloud do Google Cloud 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
  

Independentemente da sua escolha, siga estes três passos:

1. Leia a política atual através de um dos getIamPolicy métodos. Guarde a política num ficheiro temporário.
2. Edite a política no ficheiro temporário. Altere (ou adicione) apenas a secção auditConfigs.
3. Escreva a política editada no ficheiro temporário, usando um dos métodos setIamPolicy.

setIamPolicy falha se o Resource Manager detetar que outra pessoa alterou a política depois de a ter lido no primeiro passo. Se isto acontecer, repita os três passos.

Exemplos

Os exemplos seguintes demonstram como configurar os registos de auditoria de acesso aos dados do seu projeto usando o comando gcloud e a API Cloud Resource Manager.

Para configurar os registos de auditoria de acesso a dados da organização, substitua a versão "projects" dos comandos e dos métodos da API pela versão "organizations".

gcloud projects get-iam-policy PROJECT_ID --format=json >/tmp/policy.json
gcloud projects set-iam-policy PROJECT_ID /tmp/policy.json

A máscara de atualização setIamPolicy

Esta secção explica a importância do parâmetro updateMask no método setIamPolicy e explica por que motivo tem de ter cuidado com o comando set-iam-policy da CLI gcloud para não causar danos acidentais ao seu projeto ou organização. Trusted Cloud

O método da API setIamPolicy usa um parâmetro updateMask para controlar os campos da política que são atualizados. Por exemplo, se a máscara não contiver bindings, não pode alterar acidentalmente essa secção da política. Por outro lado, se a máscara contiver bindings, essa secção é sempre atualizada. Se não incluir um valor atualizado para bindings, essa secção é totalmente removida da política.

O comando gcloud projects set-iam-policy, que chama setIamPolicy, não lhe permite especificar o parâmetro updateMask. Em vez disso, o comando calcula um valor para updateMask da seguinte forma:

• O elemento updateMask contém sempre os campos bindings e etag.
• Se o objeto de política fornecido em set-iam-policy contiver quaisquer outros campos de nível superior, como auditConfigs, esses campos são adicionados a updateMask.

Como consequência destas regras, o comando set-iam-policy tem os seguintes comportamentos:

• Se omitir a secção auditConfigs na nova política, o valor anterior da secção auditConfigs (se existir) não é alterado, porque essa secção não está na máscara de atualização. Isto é inofensivo, mas pode ser confuso.

• Se omitir bindings no novo objeto de política, a secção bindings é removida da sua política, uma vez que esta secção aparece na máscara de atualização. Isto é muito prejudicial e faz com que todos os principais percam o acesso ao seu Trusted Cloud projeto.

• Se omitir etag no novo objeto de política, desativa a verificação de alterações concorrentes à sua política e pode fazer com que as suas alterações substituam acidentalmente as alterações de outra pessoa.