Arquitetura de referência do Keyfactor EJBCA

Visão geral

Esta arquitetura de referência define o design conceitual para integrar o Keyfactor EJBCA Enterprise como uma autoridade certificadora (CA) de terceiros no Google Distributed Cloud (GDC) com isolamento físico.

O Keyfactor EJBCA Enterprise é uma plataforma de autoridade certificadora altamente escalonável, robusta e em conformidade com o FIPS que permite que as organizações gerenciem a infraestrutura de chave pública (ICP) em ambientes heterogêneos.

O GDC com isolamento físico inclui um serviço nativo de autoridade certificadora para gerenciamento automatizado de chaves e certificados dentro do limite da nuvem hospedada. O serviço de CA nativo é a solução recomendada para a maioria dos clientes, oferecendo recursos de PKI totalmente gerenciados e integrados na plataforma. No entanto, as organizações que padronizaram a infraestrutura de PKI no Keyfactor EJBCA para cargas de trabalho atuais fora do GDC podem preferir aproveitar a mesma arquitetura de CA e as mesmas políticas de gerenciamento consistentes para cargas de trabalho em execução nos ambientes do GDC.

Recursos e funcionalidades

A solução oferece vários componentes funcionais principais para o gerenciamento do ciclo de vida de certificados:

  • Gerenciamento automatizado do ciclo de vida de certificados: use o emissor personalizado do EJBCA nos clusters padrão do GDC para automatizar o provisionamento, a renovação e a revogação de certificados de servidor usando o cert-manager.
  • Automação ACME padronizada: suporte ao protocolo de ambiente de gerenciamento automático de certificados (ACME) usando desafios DNS-01, permitindo que os serviços de plataforma solicitem e renovem certificados sem problemas.
  • Integração segura de HSM: proteção criptográfica direta de todas as chaves privadas de CA dentro de um módulo de segurança de hardware (HSM) certificado CC EAL4+, garantindo que o material da chave nunca saia do limite de segurança física. O Keyfactor EJBCA Enterprise pode usar o próprio HSM gerenciado ou se conectar a um HSM externo.
  • Compatibilidade com isolamento físico: fluxos de trabalho especializados para espelhar a imagem do emissor do cert-manager do EJBCA de registros públicos para o registro particular do Harbor do GDC, garantindo a disponibilidade off-line.
  • Isolamento de tráfego de saída: configuração de rede de saída usando recursos de sub-rede do GDC e CloudNATGateway para restringir o tráfego da API do GDC diretamente ao endereço IP externo do servidor EJBCA.

Princípios de arquitetura

  • Modelo de responsabilidade compartilhada: o cliente opera o servidor EJBCA externo e o HSM, sendo proprietário da infraestrutura de PKI física e das chaves raiz da CA, enquanto o GDC fornece as camadas de computação, DNS interno e cliente automatizado dentro do cluster padrão.
  • Design focado em segurança: segue os requisitos de segurança com isolamento físico ao usar espelhos de imagens do contêiner locais e aplicar um controle rigoroso de saída para minimizar a superfície de ataque da rede.
  • Padronização de protocolo: prioriza protocolos padrão (ACME e mTLS REST) para interação com a CA, evitando dependências de API proprietárias e permitindo integrações flexíveis de clientes.

Arquitetura

A arquitetura segue o modelo de autoridade certificadora externa, em que o servidor EJBCA e o módulo de segurança de hardware (HSM) de apoio são hospedados externamente fora dos limites físicos do GDC, mas são acessíveis pela rede. O servidor EJBCA pode ser implantado externamente como um dispositivo de hardware ou software. A integração principal descrita neste guia exige apenas que o servidor EJBCA externo seja acessível por um endereço IP estável.

Diagrama de arquitetura do Keyfactor EJBCA.

Os principais componentes dessa arquitetura incluem:

  • EJBCA Enterprise Server: implantado externamente como um dispositivo de hardware ou software da Keyfactor, que abriga as CAs (raiz e subordinada) e gera todo o material de chave de CA dentro de um HSM certificado CC EAL4+.
  • VPC padrão: VPC em que as cargas de trabalho do usuário são implantadas, seja em clusters padrão do Kubernetes ou em máquinas virtuais.
  • DNS interno do GDC: gerencia zonas de DNS particulares locais (usando o nome de domínio particular configurado nas variáveis de ambiente) usadas para resolver desafios de DNS-01 do ACME.
  • Gateway NAT de saída do GDC: direciona o tráfego de saída dos pods do cluster para o endereço IP externo do servidor EJBCA.
  • Registro particular do Harbor: hospeda imagens de contêiner espelhadas (como o emissor do cert-manager do EJBCA) para implantação com isolamento físico.

Conceitos e tecnologias

Nesta seção, detalhamos os componentes funcionais, as responsabilidades deles e como eles se comunicam no sistema.

Infraestrutura e plataforma

  • Cluster padrão do GDC: o ambiente de computação principal em que residem os pods do emissor do EJBCA e do cert-manager, executando a automação de certificados para cargas de trabalho.
  • Registro do Harbor: a fonte de verdade local e segura para todas as imagens de contêiner no GDC. Ele oferece verificação automatizada para garantir que as imagens não tenham vulnerabilidades conhecidas antes da implantação.
  • Gateway de saída do GDC: recursos de rede nativos da plataforma (sub-rede e CloudNATGateway) que controlam e protegem o tráfego de API de saída dos pods do cluster para o servidor de CA externo.

Serviços e lógica

  • Servidor EJBCA Enterprise: o mecanismo de CA externo (dispositivo de software ou hardware) responsável por gerenciar hierarquias de CA (raiz e subordinada), validar solicitações de certificado, assinar certificados e registrar registros de auditoria.
  • Módulo de segurança de hardware (HSM): o módulo criptográfico compatível com CC EAL4+ que processa a geração de chaves e a assinatura de certificados, garantindo que as chaves privadas da CA nunca sejam expostas.
  • DNS interno do GDC: gerencia zonas de DNS particulares (ManagedDNSZone e ResourceRecordSet) usadas pelo serviço de validação de desafio do ACME para verificar a propriedade do domínio usando registros TXT temporários.
  • cert-manager com emissor EJBCA: o controlador de certificado nativo do Kubernetes que intercepta solicitações de certificado e usa o emissor EJBCA para traduzi-las em chamadas de API EJBCA seguras.

Fluxo de dados e interfaces

  • Protocolo ACME: a interface de API padrão para emissão automatizada de certificados de servidor validados por domínio usando o desafio DNS-01.
  • API REST do EJBCA: a interface RESTful usada para inicialização administrativa e operações programáticas (como assinatura e revogação de CSR).
  • Autenticação de cliente mTLS: o principal mecanismo de autenticação para a integração do cert-manager, que verifica a identidade do cliente por meio de TLS mútuo usando certificados de cliente dedicados.

Considerações

  • Escalabilidade e desempenho:
    • O servidor EJBCA externo precisa ser escalonado (CPU, memória, capacidade do HSM) para processar solicitações simultâneas de validação e solicitações assinadas, principalmente durante perfis de emissão em massa.
    • Os recursos do gateway de saída do GDC precisam ser dimensionados para garantir latência mínima para o servidor de CA externo, evitando tempos limite durante os ciclos de validação do cert-manager.
  • Segurança e conformidade:
    • Isolar as chaves raiz da CA em um HSM externo atende a altos padrões de segurança e conformidade (como BSI VS-NfD).
    • O acesso administrativo ao EJBCA precisa ser estritamente limitado usando controles de acesso baseados em papéis (RBAC) e mapeado para números de série exclusivos de certificados do cliente.
  • Disponibilidade e confiabilidade:
    • A implantação de alta disponibilidade do servidor EJBCA externo em várias zonas de disponibilidade (usando uma configuração ativa-passiva ou em cluster) é recomendada para garantir a operação contínua e evitar um ponto único de falha.
    • A implantação de várias réplicas do controlador do cert-manager no GDC garante que a emissão automatizada de certificados no cluster permaneça resiliente.
  • Gerenciamento operacional:
    • O cliente mantém a propriedade do servidor EJBCA, incluindo patches do sistema, rotação de chaves do HSM e publicação de CRL.
    • Os administradores da plataforma GDC do cliente são responsáveis por manter o cert-manager no cluster e o controlador do emissor EJBCA, além de gerenciar os registros DNS particulares do GDC.

Decisão de design

As principais escolhas de arquitetura para essa solução se concentram em equilibrar a automação com as restrições do ambiente com isolamento físico.

Opção de integração com o EJBCA

O serviço de autoridade certificadora nativo do GDC é a solução de PKI recomendada para a maioria dos clientes, oferecendo recursos de PKI totalmente gerenciados e integrados em ambientes com isolamento físico do GDC. No entanto, para organizações que já padronizaram a infraestrutura de PKI no Keyfactor EJBCA para cargas de trabalho fora do GDC, a integração do servidor de CA externo atual é oferecida como uma opção de ativação. Isso permite que eles reutilizem modelos de PKI, políticas de segurança e modelos operacionais estabelecidos sem precisar reformular a hierarquia de confiança ou migrar fluxos de trabalho principais.

Opções de validação de desafio do ACME

Os protocolos de validação de desafio ACME HTTP-01 e DNS-01 são totalmente compatíveis. Embora este guia de arquitetura destaque o desafio DNS-01 usando o DNS interno do GDC (ideal para ambientes isolados e particulares que não oferecem suporte ao tráfego HTTP público de entrada), os clientes podem selecionar qualquer método de validação com base na topologia de rede específica, nas políticas de segurança e nos requisitos de carga de trabalho.

Recomendação de canal administrativo de mTLS

O uso do TLS mútuo (mTLS) é recomendado como um método de autenticação robusto para o cert-manager e os clientes de integração. O mTLS fornece uma verificação criptográfica altamente segura da identidade do cliente usando certificados do cliente, embora o cliente possa optar por configurar outros mecanismos de autenticação compatíveis com a instância do EJBCA de acordo com as políticas de segurança corporativas.

Suposições e limitações

Suposições

  • O servidor EJBCA externo é implantado, configurado e acessível por um endereço IP estável.
  • O servidor EJBCA é pré-configurado com as CAs raiz e subordinada necessárias, além dos perfis de entidade final apropriados.
  • Um mecanismo seguro (como um nó de bastião ou um fluxo de trabalho de transferência off-line) está disponível para publicar a imagem do contêiner do emissor do EJBCA no registro do GDC Harbor.
  • Os clusters padrão do Kubernetes no GDC têm o cert-manager pré-instalado ou configurado para operação.

Limitações

  • Manutenção externa de HSM e EJBCA: o plano de controle do GDC não gerencia o servidor EJBCA externo ou o HSM de backup. As operações de ciclo de vida (backups, upgrades, rotações de chaves) são processadas pela equipe de operações de PKI do cliente.
  • Restrição de validação de DNSSEC: como o DNS interno particular é usado, a validação de DNSSEC precisa ser desativada do lado do servidor na configuração do ACME para evitar falhas de resolução em domínios particulares locais.
  • Dependência de conectividade de saída: os serviços automatizados de emissão de certificados dependem da disponibilidade e da latência do link de rede entre o rack do GDC e o servidor EJBCA externo.