Práticas recomendadas para o Certificate Manager

Nesta página, descrevemos várias práticas recomendadas para configurar e gerenciar certificados no Google Cloud usando o Gerenciador de certificados e o Certificate Authority Service (CA Service). Esta página descreve como projetar sua arquitetura de gerenciamento de certificados.

Antes de ler esta página, confira as páginas de visão geral do Certificate Manager e visão geral do Certificate Authority Service.

Projetar sua arquitetura de gerenciamento de certificados

Ao criar uma estratégia de gerenciamento de certificados empresariais, considere os principais casos de uso da organização e todo o ciclo de vida dos certificados. Essas decisões afetam o custo, o overhead operacional e a facilidade de implementação de recursos de gerenciamento de certificados, como emissão, revogação e rotação.

As seções a seguir explicam nossas recomendações para cada opção de design.

Escolher um tipo de certificado

Ao criar um certificado, selecione um tipo adequado para seu caso de uso, dependendo dos requisitos do aplicativo e das políticas de segurança da organização.

Para analisar o tipo de certificado mais adequado para você, consulte o fluxograma a seguir:

Avalie qual tipo de certificado escolher.
Avalie qual tipo de certificado escolher (clique para ampliar).

Confira alguns links úteis para os tópicos mencionados no fluxograma:

Simplificar a hierarquia do serviço de CA particular

Recomendamos que você mantenha a hierarquia do serviço de CA o mais simples possível para garantir operações e solução de problemas sem dificuldades. Você precisa armazenar sua autoridade de certificação (CA) raiz em um projeto do Google. A CA raiz assina algumas CAs intermediárias, que emitem os certificados finais.

Essa estrutura hierárquica simples aumenta a transparência, simplifica os processos de revogação de certificados e reduz a probabilidade de configurações incorretas. Embora o serviço de CA seja regional, uma CA raiz em uma região pode assinar CAs subordinadas localizadas em outras regiões.

Siga estas práticas recomendadas na hierarquia de serviços da CA, conforme mostrado no diagrama:

  • Isole a CA raiz no próprio projeto Google Cloud para assinar a CA emissora.

  • Crie CAs emissoras em pools de CAs hospedados em projetos separados. Hospede esses pools em projetos separados e segmente-os por local geográfico (região), ciclo de vida de desenvolvimento de software (desenvolvimento, produção, teste) ou um caso de uso específico.

  • Configure o Gerenciador de certificados para usar um pool de CAs emissoras que podem emitir certificados confiáveis particulares para recursos compatíveis.

Design recomendado da hierarquia de CA.
Design recomendado para sua hierarquia de CA (clique para ampliar).

Use uma cobertura abrangente de nomes de host

Recomendamos que você verifique se os certificados oferecem cobertura suficiente de nome de host para todos os domínios e subdomínios que seus serviços precisam proteger. Uma cobertura inadequada de nomes de host pode gerar avisos de segurança para os usuários, interrupções de serviço e uma experiência negativa.

Evite usar um único certificado para vários domínios. Se o certificado único não for renovado ou for excluído por engano, todos os domínios que ele abrange ficarão desprotegidos. Recomendamos que você crie certificados distintos para domínios diferentes.

Se você planeja adicionar novos subdomínios ou serviços mais tarde, use caracteres curinga para incluir os subdomínios ou serviços no certificado desde o início. Por exemplo, um certificado curinga para *.myorg.example.com protege apenas o primeiro nível de subdomínio, mas não os níveis mais profundos, como sub.subdomain.myorg.example.com.

Usar certificados gerenciados pelo Google

Para um gerenciamento eficiente e fácil de usar de certificados públicos, recomendamos que você use os certificados gerenciados pelo Google. Essa abordagem reduz significativamente a sobrecarga operacional, automatizando tarefas como a rotação de certificados e eliminando os riscos associados a renovações manuais.

Além disso, os certificados gerenciados pelo Google oferecem integração perfeita com outros serviços doGoogle Cloud . Os certificados gerenciados pelo Google são válidos por 90 dias, e o processo de renovação começa cerca de um mês antes da expiração.

Escalonar e melhorar a performance do certificado

As seções a seguir descrevem as práticas recomendadas para escalonar seus certificados e melhorar o desempenho de ações relacionadas a certificados, como provisionamento e renovação.

Aplicar implantação descentralizada para o Gerenciador de certificados

Use o Gerenciador de certificados por projeto e por local, o que significa que seus certificados são armazenados no mesmo projeto que os recursos associados na mesma região. Essa estratégia aumenta a confiabilidade ao evitar a reutilização de certificados em diferentes regiões e minimizar o impacto no caso improvável de uma interrupção regional.

Além disso, como as cotas e os limites são aplicados no nível do projeto Google Cloud , a implantação do Certificate Manager em vários projetos aumenta as cotas gerais. Isso acontece porque o uso de um recurso em um projeto não afeta a cota disponível em outro.

Usar certificados com chaves ECDSA

Nesta seção, vamos analisar por que recomendamos o ECDSA em vez do RSA como prática recomendada para chaves de assinatura de certificado.

Qual tipo de chave usar

ECDSA P-256 é a opção recomendada de tipo de chave para a maioria dos certificados TLS porque oferece segurança criptográfica forte, excelente desempenho para operações de assinatura e uso eficiente da largura de banda da rede.

Confira alguns dos possíveis motivos para usar outros tipos de chaves de certificado:

  • Se você precisar oferecer suporte a clientes legados que não aceitam certificados ECDSA, forneça certificados RSA-2048 além dos certificados ECDSA P-256.
  • Se você tiver requisitos de compliance específicos que exijam o uso de chaves maiores ou tipos específicos, use as chaves ECDSA P-384, RSA-2048, RSA-3072 e RSA-4096.

Por que escolher ECDSA em vez de RSA

A principal vantagem do ECDSA é a capacidade de fornecer um nível de segurança criptográfica equivalente com chaves significativamente menores em comparação com o RSA. Essa eficiência se traduz em benefícios tangíveis de desempenho e recursos. Uma chave menor não implica segurança mais fraca. O ECDSA é baseado no problema de logaritmo discreto de curva elíptica, que oferece mais segurança por unidade de chave e, em alguns casos, melhor eficiência computacional em comparação com o RSA.

Exemplo:

  • Uma chave ECDSA de 256 bits oferece um nível de segurança semelhante a uma chave RSA-3072.
  • Uma chave ECDSA de 384 bits oferece um nível de segurança maior do que qualquer tamanho de chave RSA amplamente aceito.

Principais benefícios do ECDSA:

  • Performance: as operações de assinatura ECDSA são significativamente menos intensivas em computação do que as operações RSA, oferecendo um nível de segurança equivalente. Isso reduz a carga da CPU e a latência, o que é crucial para sistemas de alta capacidade ou sensíveis à latência.

  • Eficiência: chaves e assinaturas menores exigem menos largura de banda e armazenamento, o que é especialmente benéfico para ambientes com recursos limitados como dispositivos móveis e de IoT.

Você pode criar a seguinte política personalizada da organização para exigir o uso de tipos de chaves específicos nos seus certificados. Isso se aplica apenas a certificados gerenciados pelo Google do CA Service (certificados gerenciados de confiança privada), não a certificados autogerenciados e certificados gerenciados pelo Google de confiança pública.

    name: organizations/ORGANIZATION_ID/customConstraints/custom.restrictAlgorithm \
    resourceTypes: \
    - certificatemanager.googleapis.com/CertificateIssuanceConfig \
    methodTypes: \
    - CREATE \
    - UPDATE \
    condition: "resource.keyAlgorithm == 'ECDSA_P256'" \
    actionType: ALLOW \
    displayName: Allow only ECDSA_P256 in Certificate Issuance configs \
    description: Only ECDSA_P256 certificates are allowed from CA Service.

Usar um pool de CAs para emitir certificados de CAs particulares

Recomendamos que você use pools de CA para suas CAs emissoras. Um pool de ACs é uma coleção de várias ACs com uma política de emissão de certificados e uma política do Identity and Access Management (IAM) comuns. Usar um pool de CAs aumenta o total de consultas efetivas por segundo (QPS) ao fazer o balanceamento de carga e distribuir as solicitações de certificado recebidas entre todas as CAs ativadas no pool. Isso melhora o desempenho sem afetar a carga de trabalho ou as mudanças do lado do cliente.

Os pools de CA fornecem um único endpoint para emissão e recuperação de certificados. Você pode usar pools de CA para alternar as CAs com segurança sem causar inatividade devido a expiração ou comprometimento do certificado.

Usar mapas de certificados

Para garantir a escalonabilidade ideal, recomendamos usar mapas de certificados com recursos compatíveis. Os mapas de certificados são projetados para escalonar, oferecendo suporte a milhares de entradas de certificados por padrão e capazes de processar milhões de certificados. Quando usadas por balanceadores de carga, as entradas do mapa de certificados têm precedência sobre outros certificados, como os certificados SSL do Compute Engine.

Com os mapas de certificados, também é possível configurar a lógica de seleção de certificados. Por exemplo, durante um handshake, se o nome de host de um cliente não corresponder a nenhuma entrada no mapa de certificados provisionado, o balanceador de carga vai retornar o certificado principal.

Escolher o tipo correto de autorização de domínio

Para emitir certificados gerenciados pelo Google, prove a propriedade do seu domínio usando a autorização do balanceador de carga ou a autorização de DNS.

A tabela a seguir descreve as considerações para cada abordagem:

Recurso Autorização do balanceador de carga Autorização de DNS
Complexidade da configuração Não requer etapas de configuração adicionais nem mudanças na configuração de DNS. Exige que você crie uma autorização de DNS e adicione o registro CNAME correspondente à sua configuração de DNS.
Segurança de rede O balanceador de carga precisa estar totalmente acessível usando a Internet na porta 443, incluindo a configuração de DNS para todos os domínios atendidos por um certificado. A autorização do balanceador de carga não funciona com outras configurações. A autorização de DNS funciona com configurações altamente complexas, como portas diferentes de 443 e camadas de CDN na frente do proxy de destino.
Velocidade de provisionamento Velocidade de provisionamento mais rápida. Só é possível provisionar certificados depois que o balanceador de carga estiver totalmente configurado e atendendo ao tráfego de rede. É possível provisionar certificados com antecedência, antes que o proxy de destino esteja pronto para atender ao tráfego de rede.
Certificados curinga Incompatível. Compatível.

Automatizar a rotação de certificados autogerenciados

Ao contrário dos certificados gerenciados pelo Google, os autogerenciados precisam ser substituídos manualmente antes da expiração. Recomendamos que você automatize esse processo usando as ofertas de gerenciamento do ciclo de vida do certificado (CLM, na sigla em inglês) de sua escolha. Isso ajuda a reduzir erros e tempo de inatividade, além de garantir a eficiência operacional.

Você também pode usar mapas de certificados para orquestrar uma rotação de certificado perfeita. Esse processo inclui as seguintes etapas:

  1. Monitore o vencimento do certificado usando o Cloud Monitoring e alertas. Recomendamos que você crie um alerta para certificados que vão expirar nos próximos 15 a 30 dias.
  2. Gere uma solicitação de assinatura de certificado (CSR) e uma chave privada para enviar à AC.
  3. Envie a CSR e a chave privada para a CA e recupere o novo certificado.

  4. Faça upload do novo certificado para o Gerenciador de certificados em um mapa de certificados adequado.

    • Se os nomes de domínio no novo certificado corresponderem a um certificado prestes a expirar, use o método UpdateCertificate no recurso de certificado atual.
    • Se o novo certificado tiver nomes de domínio diferentes, primeiro use o método CreateCertificateRequest com os novos arquivos PEM (e-mail com privacidade aprimorada) para criá-lo. Em seguida, use o método UpdateCertificateMapEntry para substituir a referência do certificado antigo no mapa de certificados pelo novo.

    Importante: você precisa concluir esse processo em uma chamada de API sem resultar em tempo de inatividade.

Aplicar controles de acesso adequados

Recomendamos que você considere os princípios de privilégio mínimo e separação de responsabilidades ao configurar seus controles de acesso. As seções a seguir explicam essas recomendações em mais detalhes.

Aplicar o princípio de privilégio mínimo

Ao atribuir permissões para gerenciar certificados, considere o princípio de privilégio mínimo e conceda as permissões mínimas necessárias para executar uma tarefa. Recomendamos que você evite usar papéis básicos do IAM. Em vez disso, conceda papéis predefinidos ou personalizados do Certificate Manager e do CA Service para reduzir o risco de incidentes de segurança relacionados a acesso com privilégios excessivos.

Planejar a separação de tarefas

Recomendamos que você mantenha identidades e permissões distintas para administradores de certificados e para quem tem a função de emissor ou solicitante de certificado. Para isso, crie grupos separados de administradores e solicitantes na parte de cima da hierarquia de recursos para seus usuários.

Verifique se o grupo de administradores é responsável por realizar as seguintes ações:

  • Gerenciar e manter sua infraestrutura de certificados, como o provisionamento de CA.
  • Configure modelos de certificado.
  • Gerencie sua lista de revogação de certificados (CRL) e os respondentes do protocolo on-line de status de certificados (OCSP).
  • Implemente políticas de segurança para sua CA.

Para projetos que hospedam uma AC raiz, evite atribuir papéis básicos, como Proprietário (roles/owner), Editor (roles/editor) e Administrador do serviço de AC (roles/privateca.admin), a qualquer usuário ou grupo. Essa prática evita exclusão acidental, configuração incorreta e exposição excessiva. Em vez disso, use o Privileged Access Manager (PAM) para acesso Just-in-Time (JIT) conforme necessário, com justificativa e aprovações após a instalação e configuração da CA raiz.

Verifique se o grupo solicitante é responsável pelas operações diárias de processamento de solicitações de certificados e emissão de certificados com base em modelos predefinidos.

A tabela a seguir lista os papéis do IAM que normalmente são associados a várias funções de trabalho:

Persona Descrição Papéis IAM
Administradores de certificados Configurar e gerenciar a infraestrutura de CA e certificados. Proprietário do Gerenciador de certificados (roles/certificatemanager.owner),
Administrador do serviço de CA (roles/privateca.admin)
Solicitante de certificado Solicitar certificados para cargas de trabalho. Requerente de certificado do Certificate Authority Service (roles/privateca.certificateRequester)
Cargas de trabalho (contas de serviço de automação) Usado por cargas de trabalho ou em pipelines para solicitar certificados. Requerente de certificado da carga de trabalho do serviço de autoridade certificadora (roles/privateca.workloadCertificateRequester)
Engenheiros de segurança ou proprietários de ICP Gerenciar a política, a revogação e o ciclo de vida do certificado. Gerente de operações de serviço de CA (roles/privateca.caManager), Gerente de certificado do serviço de autoridade certificadora (roles/privateca.certificateManager)
Engenheiros de DevOps ou de plataforma Gerenciar a implantação de certificados em balanceadores de carga e muito mais. Editor do Gerenciador de certificados (roles/certificatemanager.editor)
Auditor ou compliance Monitore os certificados e o uso deles. Leitor do Gerenciador de certificados (roles/certificatemanager.viewer), Auditor do serviço de autoridade certificadora (roles/privateca.auditor)

Usar a autorização de DNS por projeto para implantações multirregionais e em várias nuvens

Recomendamos que você use a abordagem de autorização de DNS por projeto para gerenciar de forma independente várias autorizações para projetos em várias regiões, várias nuvens e em todo o ciclo de vida de desenvolvimento de software (SDLC).

A compartimentalização das autorizações de DNS ajuda a garantir que cada projeto mantenha seu próprio conjunto distinto de registros e permissões de DNS. Esse nível de controle permite que cada projeto gerencie as configurações de DNS de forma autônoma, sem interferir ou ser afetado pelas operações de outros projetos. Por exemplo, uma equipe de desenvolvimento pode testar novas configurações de DNS para um aplicativo específico sem correr o risco de afetar os sistemas de produção ou outros projetos em andamento.

Usar registros CAA para proteger seus domínios

Os registros de autorização de autoridade de certificação (CAA) são um mecanismo de segurança no Sistema de Nomes de Domínio (DNS). Os registros CAA oferecem aos proprietários de domínio controle total para configurar as autoridades de certificação (CAs) públicas que podem emitir certificados para seus domínios. Esse controle é importante para evitar a emissão não autorizada de certificados. Com a CAA, a superfície de ataque para certificados fraudulentos é reduzida, tornando os sites mais seguros.

Para certificados gerenciados pelo Google, recomendamos que você autorize manualmente o seguinte para ter a melhor confiabilidade das solicitações de emissão e renovação de certificados:

Cloud Logging, Cloud Monitoring e visibilidade

As seções a seguir descrevem as práticas recomendadas para o registro de auditoria e para monitorar o uso e o vencimento de certificados.

Ativar e agregar registros de auditoria

Para monitorar todos os recursos da sua organização, agregue os registros de auditoria de atividade do administrador de todos os serviços, incluindo o Gerenciador de certificados, em um local centralizado.

Assim, sua equipe de segurança ou auditor pode analisar toda a atividade relacionada à criação ou modificação de recursos do Certificate Manager e do CA Service em um só lugar. Para mais informações sobre como configurar registros agregados, consulte Agregar e armazenar os registros da sua organização.

Monitorar o uso e o vencimento do certificado

Recomendamos que você configure alertas com base em registros para eventos importantes do Certificate Manager, como uso de CA raiz, expiração e exclusão de certificados. Esses alertas ajudam você a classificar operações, como uma alta taxa de falhas na criação de certificados, e podem acionar um processo downstream para solicitar um novo certificado ou aumentar a cota.

Configure os seguintes alertas e políticas de registro para operações relacionadas a privilégios:

Requisitos de conformidade

Normalmente, as estruturas de compliance especificam expectativas e objetivos de alto nível para o gerenciamento de certificados, em vez de produtos ou configurações específicas.

Por exemplo, o Padrão de Segurança de Dados do Setor de Cartões de Pagamento (PCI DSS) e o Instituto Nacional de Padrões e Tecnologia (NIST) exigem que as organizações documentem e implementem períodos de rotação para chaves de assinatura. Eles também exigem o monitoramento contínuo do inventário e de todas as chaves e certificados de assinatura confiáveis que protegem os dados do titular do cartão.

Para mais informações sobre como os serviços do Google Cloud podem ajudar a atender a vários requisitos de estruturas de conformidade, consulte os seguintes recursos:

A seguir