Architecture de référence Keyfactor EJBCA

Présentation

Cette architecture de référence définit la conception conceptuelle de l'intégration de Keyfactor EJBCA Enterprise en tant qu'autorité de certification (CA) tierce sur Google Distributed Cloud (GDC) air-gapped.

Keyfactor EJBCA Enterprise est une plate-forme d'autorité de certification hautement évolutive, robuste et conforme à la norme FIPS, qui permet aux organisations de gérer l'infrastructure à clé publique (PKI) dans des environnements hétérogènes.

GDC sous air gap inclut un service d'autorité de certification natif pour la gestion automatisée des clés et des certificats dans la limite du cloud hébergé. Le service d'autorité de certification natif est la solution recommandée pour la plupart des clients. Il fournit des fonctionnalités PKI entièrement gérées et fluides au sein de la plate-forme. Toutefois, les organisations qui ont standardisé leur infrastructure PKI sur Keyfactor EJBCA pour les charges de travail existantes en dehors de GDC peuvent préférer utiliser la même architecture d'autorité de certification et les mêmes règles de gestion pour les charges de travail exécutées dans leurs environnements GDC.

Fonctionnalités et capacités

La solution fournit plusieurs composants fonctionnels de base pour la gestion du cycle de vie des certificats :

• Gestion automatisée du cycle de vie des certificats : exploitez l'émetteur EJBCA personnalisé dans les clusters GDC standards pour automatiser le provisionnement, le renouvellement et la révocation des certificats de serveur via cert-manager.
• Automatisation ACME standardisée : compatibilité avec le protocole ACME (Automatic Certificate Management Environment) à l'aide de défis DNS-01, ce qui permet aux services de la plate-forme de demander et de renouveler des certificats de manière fluide.
• Intégration sécurisée des HSM : protection cryptographique directe de toutes les clés privées des autorités de certification dans un module de sécurité matériel (HSM) certifié CC EAL4+, garantissant que les clés ne quittent jamais la limite de sécurité physique. Keyfactor EJBCA Enterprise peut utiliser son propre HSM géré ou se connecter à un HSM externe.
• Compatibilité avec les environnements air gap : workflows spécialisés pour mettre en miroir l'image de l'émetteur cert-manager EJBCA depuis des registres publics vers le registre Harbor privé de GDC, garantissant ainsi la disponibilité hors connexion.
• Isolation du trafic sortant : configuration du réseau sortant à l'aide des ressources de sous-réseau GDC et CloudNATGateway pour limiter le trafic de l'API GDC directement à l'adresse IP du serveur EJBCA externe.

Principes architecturaux

• Modèle de responsabilité partagée : le client exploite le serveur EJBCA externe et le HSM, et possède l'infrastructure PKI physique et les clés racine de l'autorité de certification, tandis que GDC fournit les couches de calcul, de DNS interne et de client automatisé dans le cluster standard.
• Conception axée sur la sécurité : respecte les exigences de sécurité sous air gap en utilisant des miroirs d'images de conteneurs locaux et en appliquant un contrôle strict des sorties pour minimiser la surface d'attaque du réseau.
• Standardisation des protocoles : donne la priorité aux protocoles standards (ACME et mTLS REST) pour l'interaction avec les autorités de certification, ce qui évite les dépendances aux API propriétaires et permet des intégrations client flexibles.

Architecture

L'architecture suit le modèle d'autorité de certification externe, dans lequel le serveur EJBCA et son module de sécurité matérielle (HSM) sont hébergés en dehors des limites physiques de GDC, mais sont accessibles via le réseau. Le serveur EJBCA peut être déployé en externe en tant qu'appareil matériel ou logiciel. L'intégration de base décrite dans ce guide nécessite uniquement que le serveur EJBCA externe soit accessible via une adresse IP stable.

Voici les principaux composants de cette architecture :

• Serveur EJBCA Enterprise : déployé en externe en tant qu'appareil matériel ou logiciel Keyfactor, hébergeant les autorités de certification (racine et subordonnée) et générant tout le matériel de clé d'autorité de certification dans un HSM certifié CC EAL4+.
• VPC par défaut : VPC dans lequel les charges de travail utilisateur sont déployées, soit dans des clusters Kubernetes standards, soit dans des machines virtuelles.
• DNS interne GDC : gère les zones DNS privées locales (à l'aide du nom de domaine privé configuré dans les variables d'environnement) utilisées pour résoudre les questions ACME DNS-01.
• Passerelle NAT de sortie GDC : dirige le trafic sortant des pods du cluster vers l'adresse IP du serveur EJBCA externe.
• Registre privé Harbor : héberge des images de conteneurs dupliquées (telles que l'émetteur cert-manager EJBCA) pour un déploiement sous air gap.

Concepts et technologies

Cette section détaille les composants fonctionnels, leurs responsabilités et la manière dont ils communiquent au sein du système.

Infrastructure et plate-forme

• Cluster GDC standard : environnement de calcul principal où résident l'émetteur EJBCA et les pods cert-manager, qui exécutent l'automatisation des certificats pour les charges de travail.
• Registre Harbor : source de vérité locale et sécurisée pour toutes les images de conteneurs dans GDC. Il fournit une analyse automatisée pour s'assurer que les images ne contiennent pas de failles connues avant le déploiement.
• Passerelle de sortie GDC : ressources réseau natives de la plate-forme (sous-réseau et CloudNATGateway) qui régissent et sécurisent le trafic API sortant des pods du cluster vers le serveur d'autorité de certification externe.

Services et logique

• Serveur EJBCA Enterprise : moteur d'autorité de certification externe (appareil logiciel ou matériel) chargé de gérer les hiérarchies d'autorités de certification (racine et subordonnée), de valider les demandes de certificat, de signer les certificats et de consigner les enregistrements d'audit.
• Module de sécurité matériel (HSM) : module cryptographique conforme à la norme CC EAL4+ qui gère la génération de clés et la signature de certificats, garantissant que les clés privées des autorités de certification ne sont jamais exposées.
• DNS interne GDC : gère les zones DNS privées (ManagedDNSZone et ResourceRecordSet) utilisées par le service de validation de la vérification ACME pour vérifier la propriété du domaine via des enregistrements TXT temporaires.
• cert-manager avec l'émetteur EJBCA : contrôleur de certificats natif Kubernetes qui intercepte les requêtes de certificat et utilise l'émetteur EJBCA pour les traduire en appels d'API EJBCA sécurisés.

Flux de données et interfaces

• Protocole ACME : interface API standard pour l'émission automatisée de certificats de serveur validés par domaine à l'aide du défi DNS-01.
• API REST EJBCA : interface RESTful utilisée pour l'amorçage administratif et les opérations programmatiques (telles que la signature et la révocation de CSR).
• Authentification client mTLS : mécanisme d'authentification principal pour l'intégration de cert-manager, qui vérifie l'identité du client via TLS mutuelle à l'aide de certificats client dédiés.

Remarques

• Évolutivité et performances :
  • Le serveur EJBCA externe doit être dimensionné (processeur, mémoire, capacité HSM) pour gérer les requêtes de validation et de signature simultanées, en particulier lors des profils d'émission en rafale.
  • Les ressources de la passerelle de sortie GDC doivent être dimensionnées de manière à garantir une latence minimale vers le serveur d'autorité de certification externe, ce qui évite les délais d'expiration lors des cycles de validation de cert-manager.
• Sécurité et conformité :
  • L'isolation des clés racine de l'autorité de certification dans un HSM externe répond à des normes de sécurité et de conformité élevées (telles que BSI VS-NfD).
  • L'accès administratif à EJBCA doit être strictement limité à l'aide de contrôles des accès basés sur les rôles (RBAC) et mappé à des numéros de série de certificats clients uniques.
• Disponibilité et fiabilité :
  • Nous vous recommandons de déployer le serveur EJBCA externe en haute disponibilité sur plusieurs zones de disponibilité (à l'aide d'une configuration actif-passif ou en cluster) pour garantir un fonctionnement continu et éviter un point de défaillance unique.
  • Le déploiement de plusieurs instances répliquées du contrôleur cert-manager dans GDC garantit la résilience de l'émission automatisée de certificats côté cluster.
• Gestion opérationnelle :
  • Le client conserve la propriété du serveur EJBCA, y compris l'application de correctifs système, la rotation des clés HSM et la publication des listes de révocation de certificats.
  • Les administrateurs de la plate-forme GDC du client sont chargés de gérer le cert-manager et le contrôleur d'émetteur EJBCA dans le cluster, ainsi que les enregistrements DNS privés côté GDC.

Décision de conception

Les principaux choix architecturaux de cette solution visent à équilibrer l'automatisation avec les contraintes de l'environnement isolé.

Option d'intégration d'EJBCA

Le service d'autorité de certification natif de GDC est la solution PKI recommandée pour la plupart des clients. Il fournit des fonctionnalités PKI entièrement gérées et fluides dans les environnements GDC sous air gap. Toutefois, pour les organisations qui ont déjà standardisé leur infrastructure PKI sur Keyfactor EJBCA pour les charges de travail en dehors de GDC, l'intégration de leur serveur d'autorité de certification externe existant est proposée en option. Cela leur permet de réutiliser des modèles PKI, des règles de sécurité et des modèles opérationnels établis sans avoir à repenser leur hiérarchie de confiance ni à migrer leurs workflows principaux.

Options de validation des questions d'authentification ACME

Les protocoles de validation de défi ACME HTTP-01 et DNS-01 sont entièrement compatibles. Bien que ce guide d'architecture mette en avant le test DNS-01 à l'aide du DNS interne de GDC (idéal pour les environnements privés isolés qui ne peuvent pas accepter le trafic HTTP public entrant), les clients peuvent sélectionner l'une ou l'autre méthode de validation en fonction de leur topologie réseau, de leurs règles de sécurité et de leurs exigences de charge de travail spécifiques.

Recommandation de canal d'administration mTLS

L'utilisation de mTLS (TLS mutuelle) est recommandée comme méthode d'authentification robuste pour cert-manager et les clients d'intégration. mTLS fournit une vérification cryptographique hautement sécurisée de l'identité du client en exploitant les certificats client, bien que le client puisse choisir de configurer d'autres mécanismes d'authentification compatibles avec son instance EJBCA conformément à ses règles de sécurité d'entreprise.

Hypothèses et limites

Hypothèses

• Le serveur EJBCA externe est déployé, configuré et accessible via une adresse IP stable.
• Le serveur EJBCA est préconfiguré avec les autorités de certification racine et subordonnée nécessaires, ainsi que les profils d'entité de fin appropriés.
• Un mécanisme sécurisé (tel qu'un nœud bastion ou un workflow de transfert hors connexion) est disponible pour publier l'image de conteneur de l'émetteur EJBCA dans le registre GDC Harbor.
• Les clusters Kubernetes standards de GDC sont préinstallés ou configurés pour fonctionner avec cert-manager.

Limites

• Maintenance externe du HSM et d'EJBCA : le plan de contrôle GDC ne gère pas le serveur EJBCA externe ni son HSM de sauvegarde. Les opérations de cycle de vie (sauvegardes, mises à niveau, rotations de clés) sont gérées par l'équipe chargée des opérations PKI du client.
• Contrainte de validation DNSSEC : comme un DNS interne privé est utilisé, la validation DNSSEC doit être désactivée côté serveur dans la configuration ACME pour éviter les échecs de résolution pour les domaines privés locaux.
• Dépendance de la connectivité de sortie : les services d'émission de certificats automatisés dépendent de la disponibilité et de la latence de la liaison réseau entre le rack GDC et le serveur EJBCA externe.