Opções de design para o Google Cloud Certificate Authority Service

Três formas de relacionar Autoridades Certificadoras raiz e subordinadas nos seus projetos e na sua organização do Google Cloud

O Certificate Authority Service é um serviço totalmente gerenciado que permite simplificar, automatizar e personalizar a implantação, a gestão e a segurança de autoridades certificadoras (CA) privadas.

Se a sua organização provisiona e gerencia certificados privados para workloads e load balancers SSL internos no Google Cloud, dá para usar o Certificate Authority Service para eliminar o processo manual de criação e rotação de certificados e aplicar controles de acesso rigorosos.

Este artigo mostra os prós e contras de três opções de design para implementar um certificate authority service: três formas diferentes de relacionar CAs raiz e subordinadas nos seus projetos e na sua organização do Google Cloud.

Todas usam o tier Enterprise CA pool service (em vez do tier DevOps, mais limitado) e uma hierarquia de autoridade certificadora com dois níveis. (Dá para ter mais níveis, mas recomendo no máximo três.)

Opção 1: configuração de CA no nível da organização

Nesta arquitetura, configuramos uma única CA raiz e uma CA subordinada por ambiente. É a arquitetura mais direta e permite gerenciar todas as CAs e certificados de forma centralizada, além de aplicar os controles de política de IAM necessários.

Basta instalar uma única CA raiz em todos os clientes. Você pode usar a política de emissão de certificados para garantir que cada CA subordinada só emita certificados para os domínios esperados.

A desvantagem é que uma única CA raiz faz com que todos os clientes confiem em todos os certificados de todos os ambientes (por exemplo, sistemas de produção vão confiar em sistemas de pré-produção, e vice-versa).

Usar uma configuração com uma única CA raiz dificulta testar qualquer alteração, já que uma configuração incorreta afeta todas as CAs subordinadas. Evite mexer na CA raiz e, em vez disso, implante novas CAs subordinadas para testar as mudanças.

Opção 2: configuração de CA por tipo de ambiente

Nesta arquitetura, configuramos uma CA raiz e uma CA subordinada separadas para cada tipo de ambiente. As CAs ficam todas em um único projeto, separando produção de pré-produção, enquanto os demais recursos de nuvem ficam em projetos distintos — por exemplo, para desenvolvimento, pré-produção e produção.

De acordo com o tipo de ambiente, os serviços executados no projeto obtêm o certificado necessário da CA subordinada e podem usar uma política de emissão de certificados para garantir que cada CA subordinada só emita certificados para os domínios esperados.

Essa configuração permite testar alterações em um ambiente inferior antes de levá-las para produção.

A desvantagem é que precisamos instalar CAs raiz diferentes em clientes diferentes, conforme o tipo de ambiente.

Opção 3: configuração de CA por projeto

Nesta arquitetura, configuramos uma CA raiz e uma CA subordinada separadas para cada projeto, garantindo separação total. Dá para testar alterações em um ambiente inferior com facilidade, sem afetar outras configurações de CA.

Ter várias CAs raiz significa que precisamos instalar CAs raiz diferentes em clientes diferentes, conforme o ambiente em que estão.

Se for preciso ter confiança entre vários ambientes, precisamos instalar várias CAs raiz no mesmo cliente.

Esta é a opção mais complexa em termos de arquitetura e manutenção, mas garante segurança por meio da separação.

Considerações finais

A escolha da opção de design para o certificate authority service depende de como a sua organização equilibra os requisitos de segurança com a facilidade de gestão e o baixo custo.

Entre em contato para saber mais sobre trabalhar com a DoiT. Estamos aqui para ajudar se você precisar de orientação sobre o design do certificate authority service (CAS) ou qualquer outro tema relacionado à nuvem.