Section 07PKIFactorZetaCACISOSecOps

Security

Defense in depth, continuous audit, post-quantum native.

Last updated 2026-04-18

7.1. Cryptographie

PKIFactor et ZetaCA prennent en charge les algorithmes classiques et post-quantum standardisés par le NIST :

Famille	Algorithmes	Cas d'usage
Classique RSA	RSA-2048, RSA-3072, RSA-4096	Compatibilité large
Classique ECC	ECDSA P-256, P-384, P-521, Ed25519	Performance
Post-quantum (signature)	ML-DSA-44, ML-DSA-65, ML-DSA-87 (FIPS 204)	Anti-Harvest-Now-Decrypt-Later
Post-quantum (KEM)	ML-KEM-512, ML-KEM-768, ML-KEM-1024 (FIPS 203)	Échange de clés résistant quantique
Hybride	RSA-3072 + ML-DSA-65 (composé)	Migration progressive

Les clés cryptographiques de l'autorité ZetaCA sont scellées dans un HSM Utimaco CryptoServer (FIPS 140-3 niveau 3, Common Criteria EAL 4+).

Harvest Now, Decrypt Later

Les données chiffrées aujourd'hui avec RSA ou ECDSA pourront être déchiffrées rétroactivement par un ordinateur quantique suffisamment puissant. Les templates PQC ou hybrides de ZetaCA répondent à ce risque dès maintenant.

7.2. Chiffrement au repos

Toutes les données sensibles (clés privées éphémères, secrets de connecteurs PKI, mots de passe LDAP, tokens OAuth) sont chiffrées avec AES-256-GCM via une clé KEK stockée dans HashiCorp Vault Transit ou dans le HSM. Les DEK (data encryption keys) sont rotées automatiquement (90 jours par défaut).

bash

# Rotation manuelle de la KEK
sudo pkifactor-ctl kms rotate

# Re-encrypt en arrière-plan (rolling)
sudo pkifactor-ctl kms rewrap --rate 100/s

7.3. Chiffrement en transit

TLS 1.2+ obligatoire (TLS 1.3 préféré)
mTLS entre composants internes (backend ↔ ACME, backend ↔ Patroni)
HSTS, CSP, X-Frame-Options, Referrer-Policy, X-Content-Type-Options actifs par défaut
Suites chiffrées : ECDHE+AES-GCM, ChaCha20-Poly1305 (anciennes suites désactivées)

7.4. Authentification & autorisation

MFA obligatoire pour les rôles admin (TOTP, WebAuthn/Passkeys)
SSO : OIDC, SAML 2.0, Keycloak, Azure AD/Entra, Okta, Google Workspace
RBAC granulaire : 5 rôles natifs (admin, operator, validator, auditor, user) + permissions custom
Délégation par organisation (multi-tenancy)

7.5. Audit

Tous les événements sont consignés dans un journal JSON structuré signé (Ed25519), avec horodatage UTC et trace_id corrélable.

json

{
  "ts": "2026-04-18T10:02:34.123Z",
  "actor": { "type": "user", "id": 12, "email": "alice@acme.com", "ip": "203.0.113.42" },
  "event": "certificate.revoked",
  "resource": { "type": "certificate", "id": 1024, "serial": "3F:A1:B2:..." },
  "metadata": { "reason": "key_compromise", "revocation_source": "ui" },
  "trace_id": "01J5...",
  "signature": "ed25519:..."
}

Forward direct vers SIEM (Splunk, Sentinel, QRadar, Elastic, Datadog) via :

Syslog UDP/TCP/TLS (RFC 5424)
CEF (ArcSight)
JSON HTTP (webhook)

7.6. Hardening par défaut

Mesure	Activée par défaut
Rate limiting (10 req/min/IP sur `/login`)	✓
Anti-énumération (dummy bcrypt hash)	✓
JWT TTL 30 min + rotation `JWT_SECRET_PREVIOUS`	✓
Cookie `Secure` + `HttpOnly` + `SameSite=Strict`	✓
CORS restreint à BASE_URL	✓
Sanitization des entrées (anti-injection PS pour ADCS, SSRF pour ACME HTTP-01)	✓
Validation Fernet key au démarrage	✓
Logs sanitisés (masquage des champs sensibles)	✓

← PreviousHigh availability Next →Compliance