Práticas recomendadas para o Gestor de certificados

Esta página descreve várias práticas recomendadas para configurar e gerir certificados no Google Cloud gestor de certificados e no serviço de autoridade de certificação (serviço de AC). Esta página descreve como estruturar a arquitetura de gestão de certificados.

Antes de ler esta página, certifique-se de que conhece a vista geral do Gestor de certificados e as páginas da vista geral do serviço de autoridade de certificação.

Conceba a arquitetura de gestão de certificados

Ao conceber uma estratégia de gestão de certificados empresariais, tem de considerar os principais exemplos de utilização da sua organização e o ciclo de vida completo dos seus certificados. Estas decisões afetam o custo, os custos gerais operacionais e a facilidade de implementação de capacidades de gestão de certificados, como emissão, revogação e rotação.

As secções seguintes explicam as nossas recomendações para cada escolha de design.

Escolha um tipo de certificado

Ao criar um certificado, tem de se certificar de que seleciona um tipo de certificado adequado para o seu exemplo de utilização, consoante os requisitos da sua aplicação e as políticas de segurança da sua organização.

Para analisar o tipo de certificado que pode ser mais adequado para si, consulte o seguinte fluxograma:

Avalie o tipo de certificado a escolher.
Avalie que tipo de certificado escolher (clique para aumentar).

Seguem-se alguns links úteis para a documentação dos tópicos mencionados no fluxograma:

Simplifique a hierarquia do seu serviço de AC privada

Recomendamos que mantenha a hierarquia do seu serviço de AC o mais simples possível para garantir operações e resolução de problemas sem problemas. Tem de armazenar a sua autoridade de certificação (AC) de raiz no respetivo projeto Google. A AC raiz assina algumas ACs intermédias e, em seguida, essas ACs emitem os certificados finais.

Esta estrutura hierárquica simples melhora a transparência, simplifica os processos de revogação de certificados e reduz a probabilidade de configurações incorretas. Embora o serviço de AC seja um serviço regional, uma AC raiz numa região pode assinar ACs subordinadas localizadas noutras regiões.

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

  • Isole a sua AC de raiz no respetivo projeto Google Cloud para assinar a AC de emissão.

  • Crie ACs de emissão em conjuntos de ACs alojados em projetos separados. Alojamento destes conjuntos em projetos separados e segmentação por localização geográfica (região), ciclo de vida de desenvolvimento de software (desenvolvimento, produção, teste) ou um exemplo de utilização específico.

  • Configure o Gestor de certificados para usar um conjunto de ACs de emissão que podem emitir certificados fidedignos privados para recursos suportados.

Design da hierarquia da AC recomendado.
Estrutura recomendada para a hierarquia de ACs (clique para aumentar).

Use uma cobertura abrangente de nomes de anfitrião

Recomendamos que se certifique de que os seus certificados oferecem cobertura suficiente do nome do anfitrião para todos os domínios e subdomínios que os seus serviços precisam de proteger. A cobertura inadequada do nome do anfitrião pode originar avisos de segurança para os utilizadores, interrupções de serviço e uma experiência do utilizador negativa.

Evite usar um único certificado para vários domínios. Se o certificado único não for renovado ou for eliminado acidentalmente, todos os domínios que abrange ficam desprotegidos. Recomendamos que crie certificados distintos para diferentes domínios.

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

Use certificados geridos pela Google

Para uma gestão eficiente dos certificados públicos e facilidade de utilização, recomendamos que use certificados geridos pela Google. Esta abordagem reduz significativamente os custos indiretos operacionais, automatizando tarefas como a rotação de certificados e eliminando os riscos associados a renovações manuais.

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

Expanda e melhore o desempenho dos seus certificados

As secções seguintes descrevem as práticas recomendadas para dimensionar os seus certificados e melhorar o desempenho das ações relacionadas com certificados, como o aprovisionamento e a renovação.

Aplique a implementação descentralizada para o Gestor de certificados

Use o Gestor de certificados por projeto<0x0Ae por localização, o que significa que os seus certificados são armazenados no mesmo projeto que os recursos associados na mesma região. Esta estratégia melhora a fiabilidade ao impedir a reutilização de certificados em diferentes regiões e minimiza eficazmente o impacto no caso improvável de uma indisponibilidade regional.

Além disso, uma vez que as quotas e os limites são aplicados ao nível do projeto, a implementação do Certificate Manager em vários projetos aumenta as suas quotas gerais. Google Cloud Isto deve-se ao facto de a utilização de um recurso num projeto não afetar a quota disponível noutro projeto.

Use certificados com chaves ECDSA

Esta secção examina o motivo pelo qual recomendamos o ECDSA em vez do RSA como prática recomendada para chaves de assinatura de certificados.

Que tipo de chave usar

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

Seguem-se alguns dos possíveis motivos para usar outros tipos de chaves de certificados:

  • Se precisar de suportar clientes antigos que não suportam certificados ECDSA, pode fornecer certificados RSA-2048, além de certificados ECDSA P-256.
  • Se tiver requisitos de conformidade específicos que exijam a utilização de tamanhos de chaves maiores ou tipos de chaves específicos, pode usar chaves ECDSA P-384, RSA-2048, RSA-3072 e RSA-4096.

Por que motivo deve escolher ECDSA em vez de RSA

A principal vantagem do ECDSA reside na sua capacidade de fornecer um nível de segurança criptográfica equivalente com chaves significativamente mais pequenas em comparação com o RSA. Esta eficiência traduz-se em benefícios tangíveis de desempenho e recursos. Uma chave mais pequena não implica uma segurança mais fraca. A ECDSA baseia-se no problema do logaritmo discreto da curva elíptica, que oferece uma segurança mais forte por unidade de chave e, em alguns casos, uma melhor eficiência computacional em comparação com a RSA.

Por exemplo:

  • Uma chave ECDSA de 256 bits oferece um nível de segurança semelhante ao de uma chave RSA-3072.
  • Uma chave ECDSA de 384 bits oferece um nível de segurança superior ao de qualquer tamanho de chave RSA amplamente suportado.

Principais vantagens do ECDSA:

  • Desempenho: as operações de assinatura ECDSA são significativamente menos intensivas em termos de computação do que as operações RSA, oferecendo um nível de segurança equivalente. Isto reduz a carga da CPU e a latência, o que é fundamental para sistemas de elevado débito ou sensíveis à latência.

  • Eficiência: as chaves e as assinaturas mais pequenas requerem menos largura de banda e armazenamento, o que é especialmente benéfico para ambientes com restrições de recursos, como dispositivos móveis e de IdC.

Pode criar a seguinte política de organização personalizada para aplicar a utilização de tipos de chaves específicos nos seus certificados. Isto só é aplicável a certificados geridos pela Google do serviço de AC (certificados geridos por confiança privada) e não a certificados autogeridos e certificados geridos pela 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.

Use um conjunto de ACs para emitir certificados de ACs privadas

Recomendamos que use pools de ACs para as suas ACs de emissão. Um conjunto de ACs é uma coleção de várias ACs com uma política de emissão de certificados comum e uma política de gestão de identidade e de acesso (IAM). A utilização de um conjunto de ACs aumenta o total de consultas efetivas por segundo (CPS) através do equilíbrio de carga e da distribuição dos pedidos de certificados recebidos por todas as ACs ativadas no conjunto. Isto melhora o desempenho sem afetar a carga de trabalho nem as alterações do lado do cliente.

Os conjuntos de ACs oferecem um único ponto final para a emissão e a obtenção de certificados. Pode usar conjuntos de ACs para rodar em segurança as suas ACs sem causar tempo de inatividade devido à expiração ou à violação de certificados.

Use mapeamentos de certificados

Para garantir uma escalabilidade ideal, recomendamos que use mapas de certificados com recursos suportados. Os mapeamentos de certificados foram concebidos para serem escaláveis, suportando milhares de entradas de certificados por predefinição e capazes de processar milhões de certificados. Quando usadas por equilibradores de carga, as entradas do mapa de certificados têm precedência sobre outros certificados, como os certificados SSL do Compute Engine.

Os mapeamentos de certificados também lhe permitem configurar a lógica de seleção de certificados. Por exemplo, durante uma negociação, se o nome do anfitrião de um cliente não corresponder a nenhuma entrada no mapa de certificados aprovisionado, o equilibrador de carga devolve o certificado principal.

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

Para emitir certificados geridos pela Google, pode provar a propriedade do seu domínio através da autorização do equilibrador de carga ou da autorização de DNS.

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

Funcionalidade Autorização do balanceador de carga Autorização de DNS
Complexidade da configuração Não requer passos de configuração adicionais nem alterações à configuração de DNS. Requer que crie uma autorização de DNS e adicione o respetivo registo CNAME à configuração de DNS.
Segurança de redes O balanceador de carga tem de estar totalmente acessível através da Internet na porta 443, incluindo a configuração de DNS para todos os domínios publicados por um certificado. A autorização do equilibrador de carga não funciona com outras configurações. A autorização de DNS funciona com configurações altamente complexas, como portas que não sejam a 443 e camadas de RFC à frente do proxy de destino.
Velocidade de aprovisionamento Velocidade de aprovisionamento mais rápida. Só pode aprovisionar certificados depois de o equilibrador de carga estar totalmente configurado e a servir tráfego de rede. Pode aprovisionar certificados antecipadamente, antes de o proxy de destino estar pronto para publicar tráfego de rede.
Certificados com carateres universais Não suportado. Compatível.

Automatize a rotação de certificados autogeridos

Ao contrário dos certificados geridos pela Google, os certificados autogeridos têm de ser substituídos manualmente antes de expirarem. Recomendamos que automatize este processo através das ofertas de gestão do ciclo de vida dos certificados (CLM) da sua escolha. Isto ajuda a reduzir os erros e o tempo de inatividade, bem como a garantir a eficiência operacional.

Também pode usar mapas de certificados para orquestrar uma rotação de certificados perfeita. Este processo inclui os seguintes passos:

  1. Monitorize a expiração dos certificados através do Cloud Monitoring e de alertas. Recomendamos que crie um alerta para os certificados que expiram nos próximos 15 a 30 dias.
  2. Gere um pedido de assinatura de certificado (CSR) e uma chave privada para enviar à sua AC.
  3. Envie o CSR e a chave privada à sua AC e, em seguida, obtenha o novo certificado.

  4. Carregue o novo certificado no Gestor de certificados para um mapa de certificados adequado.

    Importante: tem de concluir este processo numa chamada API sem resultar em tempo de inatividade.

Aplique controlos de acesso adequados

Recomendamos que tenha em consideração os princípios do menor privilégio e da separação de funções ao configurar os controlos de acesso. As secções seguintes explicam estas recomendações mais detalhadamente.

Aplique o princípio do menor privilégio

Ao atribuir autorizações para gerir certificados, considere o princípio do menor privilégio e conceda as autorizações mínimas necessárias para realizar uma tarefa. Recomendamos vivamente que evite usar funções básicas do IAM. Em alternativa, conceda funções predefinidas ou personalizadas do Gestor de certificados e do serviço de AC para mitigar qualquer risco de incidentes de segurança relacionados com acesso com privilégios excessivos.

Planeie a separação de funções

Recomendamos que mantenha identidades e autorizações distintas para os administradores de certificados e para as pessoas que têm a função de emissor de certificados ou requerente de certificados. Para tal, crie grupos de administradores e requerentes separados na parte superior da hierarquia de recursos para os seus utilizadores.

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

  • Faça a gestão e a manutenção da sua infraestrutura de certificados, como o aprovisionamento da AC.
  • Configure modelos de certificados.
  • Faça a gestão da sua lista de revogação de certificados (LRC) e dos respondentes do protocolo de estado de certificados online (OCSP).
  • Implemente políticas de segurança para a sua AC.

Para projetos que alojam uma AC raiz, evite atribuir funções básicas, como Proprietário (roles/owner), Editor (roles/editor) e Administrador de serviço de AC (roles/privateca.admin), a qualquer utilizador ou grupo. Esta prática evita a eliminação acidental, a configuração incorreta e a exposição excessiva. Em alternativa, use o gestor de acesso privilegiado (PAM) para acesso just-in-time (JIT) conforme necessário com justificação e aprovações após a instalação e a configuração da CA de raiz.

Certifique-se de que o grupo de solicitantes é responsável pelas operações diárias de processamento de pedidos de certificados e emissão de certificados com base em modelos predefinidos.

A tabela seguinte indica as funções da IAM que estão normalmente associadas a várias funções profissionais:

Perfil Descrição Funções de IAM
Administradores de certificados Configurar e gerir a infraestrutura de certificados e ACs. Proprietário do Gestor de certificados (roles/certificatemanager.owner),
Administrador de serviço de AC (roles/privateca.admin)
Requerente do certificado Pedir certificados para cargas de trabalho. Certificate Authority Service Certificate Requester (roles/privateca.certificateRequester)
Cargas de trabalho (contas de serviço de automatização) Usado por cargas de trabalho ou em pipelines para pedir certificados. Certificate Authority Service Workload Certificate Requester (roles/privateca.workloadCertificateRequester)
Engenheiros de segurança ou proprietários de PKI Faça a gestão da política, revogação e ciclo de vida dos certificados. Gestor de operações do serviço de AC (roles/privateca.caManager) e gestor de certificados do serviço de autoridade de certificação (roles/privateca.certificateManager)
Engenheiros de DevOps ou de plataformas Gerir a implementação de certificados em equilibradores de carga, e muito mais. Editor do Gestor de certificados (roles/certificatemanager.editor)
Auditor ou conformidade Monitorize os certificados e a respetiva utilização. Visualizador do Gestor de certificados (roles/certificatemanager.viewer), Auditor do serviço de autoridade de certificação (roles/privateca.auditor)

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

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

A compartimentalização das autorizações de DNS ajuda a garantir que cada projeto mantém o seu próprio conjunto distinto de registos e autorizações de DNS. Este nível de controlo permite que cada projeto faça a gestão das respetivas configurações de DNS de forma autónoma, sem interferir ou ser afetado pelas operações de outros projetos. Por exemplo, uma equipa de desenvolvimento pode experimentar novas configurações de DNS para a respetiva aplicação específica sem arriscar qualquer impacto adverso nos sistemas de produção ou noutros projetos em curso.

Use registos CAA para proteger os seus domínios

Os registos de autorização da autoridade de certificação (CAA) são um mecanismo de segurança no sistema de nomes de domínio (DNS). Os registos CAA oferecem aos proprietários de domínios controlo total para configurar as autoridades de certificação (ACs) públicas que podem emitir certificados para os respetivos domínios. Este controlo é importante para impedir a emissão não autorizada de certificados. Com os registos CAA implementados, a superfície de ataque para certificados fraudulentos é reduzida, o que torna os Websites mais seguros.

Para certificados geridos pela Google, recomendamos que autorize manualmente o seguinte para ter a melhor fiabilidade dos seus pedidos de emissão e renovação de certificados:

Registos na nuvem, Cloud Monitoring e visibilidade

As secções seguintes descrevem as práticas recomendadas para o registo de auditoria e para a monitorização da utilização e expiração de certificados.

Ative e agregue o registo de auditoria

Para monitorizar todos os recursos da sua organização, agregue os registos de auditoria da atividade do administrador para todos os serviços, incluindo o Gestor de certificados, numa localização centralizada.

Isto permite que a sua equipa de segurança ou auditor reveja toda a atividade relacionada com a criação ou a modificação de recursos do Certificate Manager e do CA Service num único local. Para mais informações sobre a configuração de registos agregados, consulte o artigo Agregue e armazene os registos da sua organização.

Monitorize a utilização e a expiração dos certificados

Recomendamos que configure alertas baseados em registos para eventos importantes do Gestor de certificados, como a utilização da AC raiz, a expiração do certificado e a eliminação do certificado. Estes alertas ajudam a avaliar as operações, como uma taxa elevada de falhas na criação de certificados, e podem acionar um processo a jusante para pedir um novo certificado ou aumentar a quota.

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

Requisitos de conformidade

Normalmente, as estruturas de conformidade especificam expetativas e objetivos de alto nível para a gestão de certificados, em vez de para produtos ou configurações específicos.

Por exemplo, a Norma de Segurança de Dados do Setor de Cartões de Pagamento (PCI DSS) e o National Institute of Standards and Technology (NIST) exigem que as organizações documentem e implementem períodos de rotação para chaves de assinatura. Também exigem a monitorização contínua do inventário e de todas as chaves de assinatura e certificados fidedignos que protegem os dados dos titulares de cartões.

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

O que se segue?