Architecture
Une plateforme modulaire qui orchestre vos autorités de certification existantes et nouvelles.
PKIFactor adopte une architecture microservices conteneurisée centrée sur un orchestrateur de cycle de vie (CLM) qui délègue l'émission cryptographique à des autorités de certification (CA) tierces ou à ZetaCA, l'autorité post-quantum native ZetaCert. Cette séparation garantit la portabilité multi-CA, l'interopérabilité avec les écosystèmes existants (ADCS, Sectigo, Let's Encrypt, EJBCA, Vault PKI, DigiCert) et permet une migration progressive vers la cryptographie post-quantum sans rupture.
2.1. Vue d'ensemble
PKIFactor se compose de quatre plans logiques :
- Plan de contrôle — API REST, interface d'administration, moteur de workflow d'approbation, gestion des organisations et utilisateurs.
- Plan d'enrôlement — Passerelles protocolaires ACME (RFC 8555), EST (RFC 7030), SCEP (RFC 8894), CMP (RFC 4210).
- Plan d'intégration PKI — Connecteurs vers Vault PKI, Microsoft ADCS, EJBCA, DigiCert ONE, Sectigo, GlobalSign, ZetaCA.
- Plan de données — PostgreSQL (Patroni en HA), KMS pour le chiffrement des secrets, journal d'audit JSON structuré.
La séparation plan de contrôle / plan de données n'est pas un détail d'implémentation : elle permet de mettre à jour PKIFactor (orchestrateur) sans toucher à vos CA existantes, et inversement.
2.2. Schéma architectural
2.3. Flux d'émission d'un certificat
Chaque certificat suit un chemin déterministe à travers 5 composants logiques : client, API PKIFactor, moteur de workflow, connecteur PKI et CA backend.
Les protocoles automatisés (ACME, EST, SCEP) bypassent l'étape ③ — la validation du challenge cryptographique fait office de preuve de contrôle.
Les certificats émis via les protocoles automatisés (ACME, EST, SCEP) bypassent l'étape ③ d'approbation manuelle : la validation du challenge cryptographique fait office de preuve de contrôle.
2.4. Modèle de données
Les entités principales représentent la hiérarchie d'organisation, le template d'émission (politique cryptographique) et le certificat émis. Chaque certificat est rattaché à son template, à son PKI backend et à une équipe propriétaire.
- id
- name
- code
- default_domain
- id
- org_id
- idp_subject
- id
- name
- permissions
- id
- code
- pki_id
- key_algorithm
- validity_days
- acme_path
- requires_approval
- id
- name
- type
- base_url
- auth_config
- mount_path
- id
- template_id
- serial
- subject
- sans
- not_before
- not_after
- status
- pki_metadata
- team_email
- team_id
Statuts du cycle de vie :
| Statut | Description |
|---|---|
pending_approval | En attente de validation par un approbateur |
approved | Approuvé, prêt à être émis |
issued | Émis et actif |
revoked | Révoqué (raison stockée dans revocation_reason) |
expired | Date not_after dépassée |
replaced | Remplacé par un renouvellement |