Architecture de référence Keyfactor EJBCA

Présentation

Cette architecture de référence définit la conception conceptuelle pour intégrer Keyfactor EJBCA Enterprise en tant qu'autorité de certification tierce sur Google Distributed Cloud (GDC) sous air gap.

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, car il fournit des fonctionnalités PKI entièrement gérées et transparentes 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 cohérentes 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 : utilisez l'émetteur EJBCA personnalisé dans les clusters standards GDC pour automatiser le provisionnement, le renouvellement et la révocation des certificats de serveur via cert-manager.
• Automatisation ACME standardisée : prise en charge du protocole ACME (Automatic Certificate Management Environment) à l'aide de défis DNS-01, ce qui permet aux services de plate-forme de demander et de renouveler des certificats de manière transparente.
• Intégration HSM sécurisée : protection cryptographique directe de toutes les clés privées de l'autorité de certification dans un module de sécurité matériel (HSM) certifié CC EAL4+, ce qui garantit que le matériel clé ne quitte jamais la limite de sécurité physique. Keyfactor EJBCA Enterprise peut utiliser son propre HSM géré ou se connecter à un HSM externe.
• Compatibilité sous air gap : workflows spécialisés pour la mise en miroir de l'image de l'émetteur cert-manager EJBCA des registres publics vers le registre privé Harbor GDC, ce qui garantit la disponibilité hors connexion.
• Isolation du trafic sortant : configuration du réseau sortant à l'aide des ressources GDC Subnet 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, possède l'infrastructure PKI physique et les clés racines de l'autorité de certification, tandis que GDC fournit les couches de calcul, DNS interne et client automatisées 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.
• Normalisation des protocoles : donne la priorité aux protocoles standards (ACME et mTLS REST) pour l'interaction avec l'autorité de certification, en évitant les dépendances d'API propriétaires et en permettant 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ériel (HSM) de sauvegarde sont hébergés en externe 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'appliance matérielle ou logicielle. 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.

Les principaux composants de cette architecture sont les suivants :

• Serveur EJBCA Enterprise : déployé en externe en tant qu'appliance matérielle ou logicielle Keyfactor, hébergeant les autorités de certification (racine et subordonnée) et générant tout le matériel clé de l'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 défis ACME DNS-01.
• Passerelle NAT de sortie GDC : dirige le trafic sortant des pods de cluster vers l'adresse IP du serveur EJBCA externe.
• Registre privé Harbor : héberge des images de conteneurs mises en miroir (telles que l'émetteur cert-manager EJBCA) pour le déploiement sous air gap.

Concepts et technologies

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

Infrastructure et plate-forme

• Cluster standard GDC : environnement de calcul principal dans lequel résident l'émetteur EJBCA et les pods cert-manager, exécutant l'automatisation des certificats pour les charges de travail.
• Registre Harbor : source d'informations sécurisée et locale pour toutes les images de conteneurs dans GDC. Il fournit une analyse automatisée pour s'assurer que les images sont exemptes 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 sortant de l'API des pods de cluster vers le serveur d'autorité de certification externe.

Services et logique

• Serveur EJBCA Enterprise : moteur d'autorité de certification externe (appliance logicielle ou matérielle) chargé de gérer les hiérarchies d'autorités de certification (racine et subordonnée), de valider les demandes de certificats, de signer les certificats et d'enregistrer les journaux 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 de l'autorité 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 des défis ACME pour vérifier la propriété du domaine via des enregistrements TXT temporaires.
• cert-manager avec émetteur EJBCA : contrôleur de certificats natif de Kubernetes qui intercepte les demandes de certificats 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 d'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 la TLS mutuelle à l'aide de certificats client dédiés.

Remarques

• Évolutivité et performances:
  • Le serveur EJBCA externe doit être mis à l'échelle (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 pour garantir une latence minimale vers le serveur d'autorité de certification externe, en évitant les délais d'attente lors des cycles de validation de cert-manager.
• Sécurité et conformité:
  • L'isolation des clés racines 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 d'accès basés sur les rôles (RBAC) et mappé à des numéros de série de certificats client uniques.
• Disponibilité et fiabilité:
  • Le déploiement à haute disponibilité du serveur EJBCA externe dans plusieurs zones de disponibilité (à l'aide d'une configuration active-passive ou en cluster) est recommandé pour garantir un fonctionnement continu et éviter un point de défaillance unique.
  • Le déploiement de plusieurs instances dupliquées du contrôleur cert-manager dans GDC garantit que l'émission automatisée de certificats côté cluster reste résiliente.
• 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 de listes de révocation de certificats.
  • Les administrateurs de la plate-forme GDC du client sont responsables de la maintenance du contrôleur cert-manager et de l'émetteur EJBCA dans le cluster, ainsi que de la gestion des enregistrements DNS privés côté GDC.

Décision de conception

Les principaux choix architecturaux de cette solution visent à équilibrer l'automatisation et les contraintes de l'environnement sous air gap.

Option d'intégration EJBCA

Le service d'autorité de certification natif de GDC est la solution PKI recommandée pour la plupart des clients, car il fournit des fonctionnalités PKI entièrement gérées et transparentes 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 tant qu'option d'activation. 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 les workflows principaux.

Options de validation des défis ACME

Les protocoles de validation des défis ACME HTTP-01 et DNS-01 sont entièrement compatibles. Bien que ce guide d'architecture mette en évidence le défi DNS-01 à l'aide du DNS interne de GDC (idéal pour les environnements privés isolés qui ne peuvent pas prendre en charge 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 spécifique, de leurs règles de sécurité et des exigences de leur charge de travail.

Recommandation concernant le canal d'administration mTLS

L'utilisation de la TLS mutuelle (mTLS) est recommandée comme méthode d'authentification robuste pour cert-manager et les clients d'intégration. La TLS mutuelle fournit une vérification cryptographique hautement sécurisée de l'identité du client en utilisant des certificats client. Toutefois, le client peut choisir de configurer d'autres mécanismes d'authentification compatibles avec son instance EJBCA en fonction de 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 qu'avec les profils d'entité finale 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 Harbor GDC.
• Les clusters Kubernetes standards dans GDC sont préinstallés ou configurés pour fonctionner avec cert-manager.

Limites

• Maintenance externe de 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 d'opérations PKI du client.
• Contrainte de validation DNSSEC : comme le 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 des domaines privés locaux.
• Dépendance de la connectivité sortante : les services d'émission automatisée de certificats dépendent de la disponibilité et de la latence de la liaison réseau entre le rack GDC et le serveur EJBCA externe.