Architettura di riferimento Keyfactor EJBCA

Panoramica

Questa architettura di riferimento definisce il design concettuale per l'integrazione di Keyfactor EJBCA Enterprise come autorità di certificazione (CA) di terze parti su Google Distributed Cloud (GDC) con air gap.

Keyfactor EJBCA Enterprise è una piattaforma di autorità di certificazione altamente scalabile, solida e conforme allo standard FIPS che consente alle organizzazioni di gestire l'infrastruttura a chiave pubblica (PKI) in ambienti eterogenei.

GDC con air gap include un servizio Certificate Authority nativo per la gestione automatizzata di chiavi e certificati all'interno del confine del cloud in hosting. Il servizio CA nativo è la soluzione consigliata per la maggior parte dei clienti, in quanto fornisce funzionalità PKI completamente gestite e integrate all'interno della piattaforma. Tuttavia, le organizzazioni che hanno standardizzato la propria infrastruttura PKI su Keyfactor EJBCA per i workload esistenti al di fuori di GDC potrebbero preferire sfruttare la stessa architettura CA e le stesse policy di gestione coerenti per i workload in esecuzione all'interno dei loro ambienti GDC.

Caratteristiche e funzionalità

La soluzione fornisce diversi componenti funzionali di base per la gestione del ciclo di vita dei certificati:

  • Gestione automatizzata del ciclo di vita dei certificati: sfrutta l'emittente EJBCA personalizzato all'interno dei cluster standard di GDC per automatizzare il provisioning, il rinnovo e la revoca dei certificati del server tramite cert-manager.
  • Automazione ACME standardizzata: supporto del protocollo ACME (Automatic Certificate Management Environment) utilizzando le sfide DNS-01, consentendo ai servizi della piattaforma di richiedere e rinnovare i certificati senza problemi.
  • Integrazione HSM sicura: protezione crittografica diretta di tutte le chiavi private della CA all'interno di un modulo di sicurezza hardware (HSM) certificato CC EAL4+, per garantire che il materiale delle chiavi non lasci mai il confine di sicurezza fisico. Keyfactor EJBCA Enterprise può utilizzare il proprio HSM gestito o connettersi a un HSM esterno.
  • Compatibilità con ambienti air-gapped: flussi di lavoro specializzati per il mirroring dell'immagine dell'emittente cert-manager EJBCA dai registri pubblici al registro Harbor privato di GDC, garantendo la disponibilità offline.
  • Isolamento del traffico in uscita: configurazione di rete in uscita che utilizza le risorse GDC Subnet e CloudNATGateway per limitare il traffico dell'API GDC direttamente all'indirizzo IP del server EJBCA esterno.

Principi di architettura

  • Modello di responsabilità condivisa: il cliente gestisce il server EJBCA esterno e l'HSM, possedendo l'infrastruttura PKI fisica e le chiavi root della CA, mentre GDC fornisce i livelli di computing, DNS interno e client automatizzato all'interno del cluster standard.
  • Design incentrato sulla sicurezza: rispetta i requisiti di sicurezza con air gap utilizzando mirror di immagini container locali e applicando un controllo rigoroso del traffico in uscita per ridurre al minimo la superficie di attacco della rete.
  • Standardizzazione dei protocolli: dà la priorità ai protocolli standard (ACME e mTLS REST) per l'interazione con la CA, evitando dipendenze da API proprietarie e consentendo integrazioni client flessibili.

Architettura

L'architettura segue il modello di autorità di certificazione esterna, in cui il server EJBCA e il relativo modulo di sicurezza hardware (HSM) di supporto sono ospitati esternamente al di fuori dei confini fisici di GDC, ma sono accessibili dalla rete. Il server EJBCA può essere distribuito esternamente come appliance hardware o software. L'integrazione di base descritta in questa guida richiede solo che il server EJBCA esterno sia raggiungibile tramite un indirizzo IP stabile.

Diagramma dell'architettura di Keyfactor EJBCA.

I componenti chiave di questa architettura includono:

  • EJBCA Enterprise Server: viene eseguito il deployment esternamente come appliance hardware o software Keyfactor, che ospita le CA (principale e subordinata) e genera tutto il materiale delle chiavi CA all'interno di un HSM certificato CC EAL4+.
  • VPC predefinito: VPC in cui viene eseguito il deployment dei workload degli utenti, in cluster Kubernetes standard o in macchine virtuali.
  • DNS interno GDC: gestisce le zone DNS private locali (utilizzando il nome di dominio privato configurato nelle variabili di ambiente) utilizzate per risolvere le verifiche DNS-01 ACME.
  • Gateway NAT in uscita GDC: indirizza il traffico in uscita dai pod del cluster all'indirizzo IP del server EJBCA esterno.
  • Registry privato Harbor: ospita le immagini container sottoposte a mirroring (come l'emittente cert-manager EJBCA) per il deployment con air gap.

Concetti e tecnologie

Questa sezione descrive in dettaglio i componenti funzionali, le loro responsabilità e il modo in cui comunicano all'interno del sistema.

Infrastruttura e piattaforma

  • Cluster GDC Standard: l'ambiente di computing principale in cui risiedono i pod dell'emittente EJBCA e di cert-manager, che esegue l'automazione dei certificati per i workload.
  • Harbor Registry: la fonte di riferimento locale e sicura per tutte le immagini container in GDC. Fornisce la scansione automatica per garantire che le immagini siano prive di vulnerabilità note prima del deployment.
  • Gateway in uscita GDC: risorse di networking native della piattaforma (Subnet e CloudNATGateway) che regolano e proteggono il traffico API in uscita dai pod del cluster al server CA esterno.

Servizi e logica

  • EJBCA Enterprise Server: il motore CA esterno (software o hardware) responsabile della gestione delle gerarchie CA (principale e subordinata), della convalida delle richieste di certificato, della firma dei certificati e della registrazione dei record di controllo.
  • Hardware Security Module (HSM): il modulo crittografico conforme a CC EAL4+ che gestisce la generazione delle chiavi e la firma dei certificati, garantendo che le chiavi private della CA non vengano mai esposte.
  • DNS interno di GDC: gestisce le zone DNS private (ManagedDNSZone e ResourceRecordSet) utilizzate dal servizio di convalida della verifica ACME per verificare la proprietà del dominio tramite record TXT temporanei.
  • cert-manager con emittente EJBCA: il controller dei certificati nativo di Kubernetes che intercetta le richieste di certificato e utilizza l'emittente EJBCA per tradurle in chiamate API EJBCA sicure.

Flusso di dati e interfacce

  • Protocollo ACME: l'interfaccia API standard per l'emissione automatizzata di certificati server convalidati dal dominio utilizzando la verifica DNS-01.
  • API REST EJBCA: l'interfaccia RESTful utilizzata per il bootstrap amministrativo e le operazioni programmatiche (come la firma e la revoca delle CSR).
  • Autenticazione client mTLS: il meccanismo di autenticazione principale per l'integrazione di cert-manager, che verifica l'identità del client tramite mutual TLS utilizzando certificati client dedicati.

Considerazioni

  • Scalabilità e prestazioni:
    • Il server EJBCA esterno deve essere scalato (CPU, memoria, capacità HSM) per gestire le richieste di convalida e le richieste firmate simultanee, in particolare durante i profili di emissione in burst.
    • Le risorse del gateway in uscita di GDC devono essere dimensionate in modo da garantire una latenza minima per il server CA esterno, evitando timeout durante i cicli di convalida di cert-manager.
  • Sicurezza e conformità:
    • L'isolamento delle chiavi root della CA all'interno di un HSM esterno soddisfa elevati standard di sicurezza e conformità (come BSI VS-NfD).
    • L'accesso amministrativo a EJBCA deve essere rigorosamente limitato utilizzando i controlli degli accessi basati su ruoli (RBAC) e mappato a numeri di serie univoci dei certificati client.
  • Disponibilità e affidabilità:
    • Per garantire un funzionamento continuo ed evitare un single point of failure, è consigliato il deployment ad alta affidabilità del server EJBCA esterno in più zone di disponibilità (utilizzando una configurazione attiva-passiva o in cluster).
    • Il deployment di più repliche del controller cert-manager all'interno di GDC garantisce che l'emissione automatica dei certificati lato cluster rimanga resiliente.
  • Gestione operativa:
    • Il cliente mantiene la proprietà del server EJBCA, inclusi l'applicazione di patch al sistema, rotazione della chiave HSM e la pubblicazione delle CRL.
    • Gli amministratori della piattaforma GDC del cliente sono responsabili della manutenzione del cert-manager nel cluster e del controller dell'emittente EJBCA, nonché della gestione dei record DNS privati lato GDC.

Decisione di progettazione

Le principali scelte architettoniche per questa soluzione si concentrano sul bilanciamento dell'automazione con i vincoli dell'ambiente con air gap.

Opzione di integrazione EJBCA

Il servizio Certificate Authority nativo di GDC è la soluzione PKI consigliata per la maggior parte dei clienti, in quanto offre funzionalità PKI completamente gestite e integrate negli ambienti GDC con air gap. Tuttavia, per le organizzazioni che hanno già standardizzato la propria infrastruttura PKI su Keyfactor EJBCA per i workload esterni a GDC, l'integrazione del server CA esterno esistente è offerta come opzione di attivazione. In questo modo, possono riutilizzare modelli PKI, policy di sicurezza e modelli operativi consolidati senza dover riprogettare la gerarchia di attendibilità o migrare i workflow principali.

Opzioni di convalida della verifica ACME

I protocolli di convalida delle richieste ACME HTTP-01 e DNS-01 sono completamente supportati. Sebbene questa guida all'architettura evidenzi la verifica DNS-01 utilizzando il DNS interno di GDC (ideale per ambienti isolati e privati che non possono supportare il traffico HTTP pubblico in entrata), i clienti possono selezionare uno dei due metodi di convalida in base alla Network Topology, alle policy di sicurezza e ai requisiti dei workload specifici.

Suggerimento per il canale amministrativo mTLS

L'utilizzo di mutual TLS (mTLS) è consigliato come metodo di autenticazione efficace per i client cert-manager e di integrazione. mTLS fornisce una verifica crittografica altamente sicura dell'identità del client sfruttando i certificati client, anche se il cliente può scegliere di configurare altri meccanismi di autenticazione supportati dalla propria istanza EJBCA in base alle policy di sicurezza aziendali.

Ipotesi e limitazioni

Ipotesi

  • Il server EJBCA esterno è stato sottoposto a deployment, configurato e reso raggiungibile tramite un indirizzo IP stabile.
  • Il server EJBCA è preconfigurato con le CA principali e subordinate necessarie, insieme ai profili delle entità finali appropriati.
  • È disponibile un meccanismo sicuro (ad esempio un nodo bastion o un workflow di trasferimento offline) per pubblicare l'immagine container dell'emittente EJBCA nel registry Harbor di GDC.
  • I cluster Kubernetes standard all'interno di GDC hanno cert-manager preinstallato o configurato per il funzionamento.

Limitazioni

  • Manutenzione di HSM ed EJBCA esterni: il control plane di GDC non gestisce il server EJBCA esterno o l'HSM di supporto; le operazioni del ciclo di vita (backup, upgrade, rotazioni delle chiavi) sono gestite dal team operativo PKI del cliente.
  • Vincolo di convalida DNSSEC: poiché viene utilizzato il DNS interno privato, la convalida DNSSEC deve essere disabilitata lato server nella configurazione ACME per evitare errori di risoluzione per i domini privati locali.
  • Dipendenza dalla connettività in uscita: i servizi di emissione automatica dei certificati dipendono dalla disponibilità e dalla latenza del collegamento di rete tra il rack GDC e il server EJBCA esterno.