Práticas recomendadas para o Certificate Manager

Esta página descreve várias práticas recomendadas para configurar e gerenciar certificados usando o Google Cloud 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 do Certificate Authority Service.

Projetar sua arquitetura de gerenciamento de certificados

Ao projetar uma estratégia de gerenciamento de certificados corporativos, considere os principais casos de uso da sua 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 sua organização.

Para analisar o tipo de certificado que pode funcionar melhor para você, consulte o fluxograma a seguir:

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

Confira alguns links úteis de documentação para os tópicos mencionados no fluxograma:

Simplificar a hierarquia do seu 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. É necessário armazenar a autoridade certificadora raiz (CA) no próprio projeto do Google. A CA raiz assina algumas CAs intermediárias, e essas CAs 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 do serviço de CA, conforme mostrado no diagrama:

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

  • Crie CAs emissoras em pools de CA hospedados em projetos separados. Hospede esses pools em projetos separados e segmente-os por localização geográfica (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 possam emitir certificados confiáveis particulares para recursos compatíveis.

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

Usar cobertura abrangente de nomes de host

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

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

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 de certificados públicos e facilidade de uso, recomendamos que você use certificados gerenciados pelo Google. Essa abordagem reduz significativamente o overhead 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 Google Cloud serviços. O Certificate Manager só oferece suporte à Public Certificate Authority (pki.goog) e à CA Let's Encrypt (letsencrypt.org) para emitir certificados gerenciados pelo Google confiáveis publicamente. O Gerenciador de certificados provisiona certificados gerenciados pelo Google com um período de validade de 45 ou 90 dias, dependendo da CA emissora:

  • Os certificados emitidos pelo Public CA estão passando gradualmente de um período de validade de 90 dias para um período de validade de 45 dias. Os certificados de 90 dias atuais permanecem válidos por 90 dias até a próxima renovação.
  • Os certificados emitidos pela CA Let's Encrypt têm um período de validade de 90 dias.

O Gerenciador de certificados inicia automaticamente o processo de renovação quando resta aproximadamente um terço do período de validade do certificado. A renovação começa cerca de 15 dias antes do vencimento para certificados de 45 dias e cerca de 30 dias antes do vencimento para certificados de 90 dias.

Escalar e melhorar a performance do certificado

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

Aplicar a implantação descentralizada para o Certificate Manager

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

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

Usar certificados com chaves ECDSA

Esta seção examina por que recomendamos o ECDSA em vez do RSA como uma 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 performance 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 chave de certificado:

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

Por que escolher ECDSA em vez de RSA

A principal vantagem do ECDSA está na 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 performance 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 maior 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:

  • Desempenho: as operações de assinatura ECDSA são significativamente menos intensivas em computação do que as operações RSA que fornecem 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 de processamento 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 restrição de recursos como dispositivos móveis e IoT.

É possível criar a seguinte política da organização personalizada para aplicar o uso de tipos de chave específicos nos certificados. Isso é aplicável apenas a certificados gerenciados pelo Google do serviço de CA (certificados gerenciados por 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 CAs para suas CAs emissoras. Um pool de CAs é uma coleção de várias CAs com uma política de emissão de certificados e uma política do Identity and Access Management (IAM) comuns. O uso de um pool de CAs aumenta o total de consultas efetivas por segundo (QPS) pelo balanceamento de carga e pela distribuição das solicitações de certificado recebidas em todas as CAs ativadas no pool. Isso melhora a performance sem afetar a carga de trabalho ou as mudanças do lado do cliente.

Os pools de CAs fornecem um único endpoint para emissão e recuperação de certificados. É possível usar pools de CAs para alternar suas CAs com segurança sem causar inatividade devido à expiração ou comprometimento do certificado.

Usar mapas de certificados

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

Os mapas de certificados também permitem configurar a lógica de seleção de certificados. Por exemplo, durante um handshake, se o nome do host de um cliente não corresponder a nenhuma entrada no mapa de certificados provisionado, o balanceador de carga retornará o certificado principal.

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

Para emitir certificados gerenciados pelo Google, é possível comprovar a propriedade do 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 instalação Não requer etapas de configuração ou mudanças adicionais na configuração de DNS. Exige que você crie uma autorização de DNS e adicione o registro CNAME correspondente à 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. É possível provisionar certificados somente 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 certificados autogerenciados precisam ser substituídos manualmente antes de expirar. Recomendamos que você automatize esse processo usando as ofertas de gerenciamento do ciclo de vida de certificados (CLM, na sigla em inglês) de sua escolha. Isso ajuda a reduzir erros, inatividade e garantir a eficiência operacional.

Também é possível usar mapas de certificados para orquestrar uma rotação de certificados perfeita. Esse processo inclui as seguintes etapas:

  1. Monitore a expiração do certificado usando o Cloud Monitoring e alertas. Recomendamos que você crie um alerta para certificados que expiram nos próximos 15 a 30 dias.
  2. Gere uma solicitação de assinatura de certificado (CSR) e uma chave privada para enviar à CA.
  3. Envie sua CSR e 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 apropriado.

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

    Importante: conclua esse processo em uma chamada de API sem resultar em inatividade.

Aplicar controles de acesso adequados

Recomendamos que você considere os princípios de privilégio mínimo e segregação de funções ao configurar os controles de acesso. As seções a seguir explicam essas recomendações com 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 o mínimo de permissões 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 serviço de CA para mitigar qualquer risco de incidentes de segurança relacionados ao acesso com privilégios excessivos.

Planejar a segregação de funções

Recomendamos que você mantenha identidades e permissões distintas para administradores de certificados e para aqueles que têm o papel de emissor ou requerente de certificado. Para fazer isso, crie grupos de administradores e requerentes separados 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 a infraestrutura de certificados, como o provisionamento de CA.
  • Configurar modelos de certificado.
  • Gerenciar a lista de revogação de certificados (CRL) e os respondentes do protocolo de status de certificado on-line (OCSP).
  • Implementar políticas de segurança para sua CA.

Para projetos que hospedam uma CA raiz, evite atribuir papéis básicos, como Proprietário (roles/owner), Editor (roles/editor) e Administrador do serviço de CA (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 de requerentes é responsável pelas operações diárias de processamento de solicitações de certificado e emissão de certificados com base em modelos predefinidos.

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

Persona Descrição Papéis do IAM
Administradores de certificados Configurar e gerenciar a infraestrutura de CA e certificados. Proprietário do Certificate Manager (roles/certificatemanager.owner),
Administrador do serviço de CA (roles/privateca.admin)
Requerente 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 Certificate Authority Service (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 do Certificate Authority Service (roles/privateca.caManager), Certificate Manager do Certificate Authority Service (roles/privateca.certificateManager)
Engenheiros de DevOps ou de plataforma Gerenciar a implantação de certificados em balanceadores de carga, e muito mais. Editor do Certificate Manager (roles/certificatemanager.editor)
Auditor ou compliance Monitorar certificados e o uso deles. Leitor do Certificate Manager (roles/certificatemanager.viewer), Auditor do Certificate Authority Service (roles/privateca.auditor)

Usar a autorização de DNS por projeto para implantações multirregionais e multicloud

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 DNS e permissões. 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 o aplicativo específico sem arriscar qualquer impacto negativo nos sistemas de produção ou em outros projetos em andamento.

Usar registros CAA para proteger seus domínios

Os registros de autorização de autoridade certificadora (CAA) são um mecanismo de segurança no Sistema de Nomes de Domínio (DNS). Os registros CAA fornecem aos proprietários de domínio controle completo para configurar as autoridades certificadoras (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 o 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 geração de registros de auditoria e para monitorar o uso e a expiração de certificados.

Ativar e agregar a geração de registros de auditoria

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

Isso permite que sua equipe de segurança ou auditor analise todas as atividades relacionadas à criação ou modificação de recursos do Certificate Manager e do serviço de CA 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 a expiração de certificados

Recomendamos que você configure alertas baseados em registros para eventos importantes do Certificate Manager, como uso de CA raiz, expiração de certificado e exclusão de certificado. Esses alertas ajudam 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 compliance

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 Google Cloud os serviços do podem ajudar a atender a vários requisitos de estrutura de compliance, consulte os seguintes recursos:

A seguir