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 (AC) de terceiros no Google Distributed Cloud (GDC) isolado.

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

O GDC com isolamento físico inclui um serviço de autoridade certificadora nativo para gerenciamento automatizado de chaves e certificados dentro do limite da nuvem hospedada. O serviço de AC 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 fora do GDC podem preferir aproveitar a mesma arquitetura de AC e políticas de gerenciamento consistentes para cargas de trabalho executadas nos ambientes do GDC.

Recursos e funcionalidades

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

  • Gerenciamento automatizado do ciclo de vida do certificado: aproveite o emissor EJBCA personalizado 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 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 da AC 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 isolada: 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 do tráfego de saída: configuração de rede de saída usando recursos de sub-rede e CloudNATGateway do GDC para restringir o tráfego da API do GDC diretamente ao endereço IP do servidor EJBCA externo.

Princípios arquitetônicos

  • 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 AC, enquanto o GDC fornece as camadas de computação, DNS interno e cliente automatizadas dentro do cluster padrão.
  • Design com foco em segurança: adere aos requisitos de segurança isolados usando espelhos de imagem de contêiner local e aplicando um controle de saída rigoroso para minimizar a superfície de ataque de rede.
  • Padronização de protocolo: prioriza protocolos padrão (ACME e mTLS REST) para interação com a AC, 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 possa ser acessado por um endereço IP estável.

Diagrama de arquitetura do Keyfactor EJBCA.

Os principais componentes dessa arquitetura incluem:

  • Servidor EJBCA Enterprise: implantado externamente como um dispositivo de hardware ou software Keyfactor, que abriga as ACs (raiz e subordinada) e gera todo o material de chave da AC dentro de um HSM certificado CC EAL4+.
  • VPC padrão: VPC em que as cargas de trabalho do usuário são implantadas, em clusters padrão do Kubernetes ou em máquinas virtuais.
  • DNS interno do GDC: gerencia zonas DNS particulares locais (usando o nome de domínio particular configurado nas variáveis de ambiente) usadas para resolver desafios 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 do servidor EJBCA externo.
  • Registro particular do Harbor: hospeda imagens de contêiner espelhadas (como o emissor do cert-manager do EJBCA) para implantação isolada.

Conceitos e tecnologias

Esta seção detalha os componentes funcionais, as responsabilidades deles e como eles se comunicam dentro do sistema.

Infraestrutura e plataforma

  • Cluster padrão do GDC: o ambiente de computação principal em que o emissor do EJBCA e os pods do cert-manager residem, 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 fornece a verificação automatizada para garantir que as imagens estejam livres de vulnerabilidades conhecidas antes da implantação.
  • Gateway de saída do GDC: recursos de rede nativos da plataforma (sub-rede e CloudNATGateway) que regem e protegem o tráfego de API de saída dos pods do cluster para o servidor de AC externo.

Serviços e lógica

  • Servidor EJBCA Enterprise: o mecanismo de AC externo (dispositivo de software ou hardware aplicativo) responsável por gerenciar hierarquias de AC (raiz e subordinada), validar solicitações de certificado, assinar certificados e registrar registros de auditoria. registros.
  • 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 AC nunca sejam expostas.
  • DNS interno do GDC: gerencia zonas DNS particulares (ManagedDNSZone e ResourceRecordSet) usadas pelo serviço de validação de desafio 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 aproveita 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 mecanismo de autenticação principal para a integração do cert-manager, que verifica a identidade do cliente via TLS mútuo usando certificados de cliente dedicados.

Considerações

  • Escalonabilidade e desempenho:
    • O servidor EJBCA externo precisa ser escalonado (CPU, memória, capacidade de HSM) para processar solicitações simultâneas de validação e assinatura, principalmente durante perfis de emissão de burst.
    • Os recursos do gateway de saída do GDC precisam ser dimensionados para garantir a latência mínima para o servidor de AC externo, evitando tempos limite durante os ciclos de validação do cert-manager.
  • Segurança e conformidade:
    • Isolar as chaves raiz da AC 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 baseado em papéis (RBAC) e mapeado para números de série de certificados de cliente exclusivos.
  • 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 único ponto 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 do lado do cluster permaneça resiliente.
  • Gerenciamento operacional:
    • O cliente mantém a propriedade do servidor EJBCA, incluindo aplicação de patches do sistema, rotação de chaves HSM e publicação de CRL.
    • Os administradores da plataforma GDC do cliente são responsáveis por manter o controlador do emissor do cert-manager e do EJBCA no cluster e gerenciar registros DNS particulares do lado do GDC.

Decisão de design

As principais opções arquitetônicas para essa solução se concentram em equilibrar a automação com as restrições do ambiente isolado.

Opção de integração do 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 GDC com isolamento físico. 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 AC externo atual é oferecida como uma opção de ativação. Isso permite que eles reutilizem modelos de PKI estabelecidos, políticas de segurança e modelos operacionais sem redesenhar a hierarquia de confiança ou migrar fluxos de trabalho principais.

Opções de validação de desafio 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 (que é ideal para ambientes isolados e particulares que não podem oferecer 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 mTLS

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

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 ACs raiz e subordinada necessárias, além dos perfis de entidade final adequados.
  • Um mecanismo seguro (como um nó de bastion ou 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 Harbor do GDC.
  • 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 do HSM e do EJBCA: o plano de controle do GDC não gerencia o servidor EJBCA externo nem o HSM de apoio. 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 de domínios particulares locais.
  • Dependência de conectividade de saída: os serviços de emissão automatizada de certificados dependem da disponibilidade e da latência do link de rede entre o rack do GDC e o servidor EJBCA externo.