Vista geral das políticas da organização do AlloyDB

Esta página descreve as políticas organizacionais do AlloyDB for PostgreSQL, que os administradores da organização usam para definir restrições sobre a forma como os utilizadores configuram clusters e cópias de segurança nessa organização.

Os projetos, as pastas e as organizações são recursos de contentores organizados numa hierarquia de recursos principal/secundário. Uma organização é o nó de raiz nessa hierarquia. Para mais informações, consulte o artigo Hierarquia de recursos.

As políticas da organização contêm regras, denominadas restrições, que o administrador da organização aplica a um projeto, uma pasta ou uma organização. As restrições aplicam uma política em todos os clusters e cópias de segurança. Por exemplo, se tentar criar um cluster ou uma cópia de segurança numa entidade que tenha uma política da organização, a restrição executa uma verificação para garantir que a configuração do cluster ou da cópia de segurança cumpre os requisitos da restrição. Se a verificação falhar, o AlloyDB não cria o cluster nem o recurso de cópia de segurança.

Quando adiciona projetos a uma organização ou a uma pasta que usa uma política organizacional, os projetos herdam as restrições dessa política.

Para mais informações sobre as políticas de organização, consulte os artigos Introdução ao serviço de políticas de organização, Restrições e Compreender a avaliação da hierarquia.

As seguintes políticas da organização são específicas do AlloyDB:

Políticas da organização predefinidas

Para começar, pode usar as definições de chaves de encriptação geridas pelo cliente (CMEK) dos clusters e das cópias de segurança do AlloyDB. Para mais detalhes, consulte o artigo Use políticas da organização predefinidas. Para um controlo detalhado e personalizável sobre outras definições suportadas, use restrições personalizadas. Para mais informações, consulte o artigo Use políticas de organização personalizadas.

Políticas da organização de chaves de encriptação geridas pelo cliente (CMEK)

O AlloyDB suporta as seguintes restrições da política da organização:

  • constraints/gcp.restrictNonCmekServices: requer a proteção CMEK para a API alloydb.googleapis.com. Quando adiciona esta restrição e alloydb.googleapis.com à lista de serviços da política Deny, o AlloyDB recusa-se a criar um novo cluster ou um recurso de cópia de segurança, a menos que o novo cluster ou recurso de cópia de segurança esteja ativado com a CMEK.
  • constraints/gcp.restrictCmekCryptoKeyProjects: limita as CryptoKeys do Cloud KMS a usar para a proteção CMEK em clusters e cópias de segurança do AlloyDB. Quando o AlloyDB cria um novo cluster ou uma nova cópia de segurança usando CMEK e esta restrição, a CryptoKey tem de vir de um projeto, uma pasta ou uma organização permitidos.

Estas restrições ajudam a garantir a proteção CMEK numa organização e só são aplicadas a clusters e cópias de segurança do AlloyDB criados recentemente. Para mais informações, consulte as políticas da organização CMEK e as restrições da política da organização.

Políticas da organização personalizadas

Para um controlo detalhado e personalizável das definições, pode criar restrições personalizadas e usá-las numa política organizacional personalizada. Use políticas da organização personalizadas para melhorar a segurança, a conformidade e a gestão.

Para saber como criar políticas de organização personalizadas, consulte o artigo Use políticas de organização personalizadas. Também pode ver uma lista de restrições e operações personalizadas suportadas.

Regras de aplicação da política da organização

O AlloyDB aplica a política da organização às seguintes operações:

  • Criação da instância
  • Atualização da instância
  • Criação de clusters
  • Criação de cópias de segurança

Tal como todas as restrições de políticas organizacionais, as alterações às políticas não se aplicam retroativamente aos clusters e às cópias de segurança existentes. Seguem-se alguns exemplos:

  • Uma nova política não tem efeito nas instâncias, nos clusters nem nas cópias de segurança existentes.
  • A menos que um utilizador altere a instância, o cluster ou a configuração da cópia de segurança de um estado de conformidade para um estado de não conformidade através da Google Cloud consola, da CLI gcloud ou do RPC, uma instância, um cluster ou uma configuração de cópia de segurança existente permanece válido.
  • Uma atualização de manutenção agendada não causa a aplicação de políticas porque a manutenção não altera a configuração de instâncias, clusters nem cópias de segurança.

O que se segue?