PKI interne

La PKI interne Enterprise peut créer des autorités racines et intermédiaires, émettre des certificats serveur, client, de signature de code et d’e-mail, appliquer des modèles, publier des CRL et exporter dans les formats pris en charge, sous des scopes explicites.

Dans la console, la PKI interne se trouve sur la page Certificates, dans les onglets Authorities, PKI Certificates et Templates.

Utilisez la PKI interne lorsqu’Opfield doit exploiter un domaine de confiance privé pour des personnes, des services, la signature de code ou la protection des e-mails. Émettre un certificat n’est que la première étape : avant qu’il ne devienne une dépendance de production, prouvez sa chaîne, son usage prévu, son renouvellement, sa révocation, sa sauvegarde et sa reprise.

PKI signifie infrastructure à clés publiques : les autorités, certificats, clés privées, enregistrements de révocation et politiques qui permettent aux systèmes de décider à quelles identités faire confiance. Une autorité de certification racine est l’ancre de confiance de plus haut niveau. Une autorité intermédiaire émet les certificats du quotidien, afin que la racine puisse être utilisée moins souvent et mieux protégée.

Les clés privées sont chiffrées avec PKI_MASTER_KEY. Conservez cette clé indépendamment de la sauvegarde de la base de données. Limitez les permissions d’export et auditez chaque opération sur une autorité, un certificat, une révocation ou une clé privée.

La PKI interne destinée aux utilisateurs est distincte de la PKI système cachée qu’Opfield utilise pour le transport géré. Après la fin d’une période de grâce de licence, les autorités, certificats, modèles et l’historique d’audit existants sont conservés ; vous pouvez toujours les consulter, télécharger les listes de révocation, révoquer et exporter des certificats et supprimer des modèles, tandis que la création d’autorités, l’émission de certificats et la modification des modèles exigent à nouveau le plan. Le transport système continue de fonctionner.

Modèle de confiance

Ne créez une autorité racine que lorsqu’Opfield est destiné à détenir cette ancre de confiance. Préférez garder la racine hors ligne ou rarement utilisée, et émettez les certificats opérationnels depuis une autorité intermédiaire. Les modèles encadrent le sujet, la durée de vie, l’usage de la clé, l’usage étendu de la clé et le comportement d’export, afin que les opérateurs n’aient pas à reproduire manuellement la politique pour chaque demande.

Les autorités d’Opfield destinées aux utilisateurs ne doivent jamais être détournées pour remplacer la PKI système cachée, la Database CA, les identités des démons ou les identités de service de Relay. Ces domaines de confiance internes ont des contrats de rotation et de reprise distincts.

Décisions de gouvernance

Avant de créer une racine, approuvez son périmètre, son responsable, sa durée de vie, les usages de certificats autorisés, le contact en cas d’incident et le plan de mise hors service. Décidez si la racine doit être générée dans Opfield ou importée, si l’export de la clé privée est autorisé et quels systèmes dépendants consommeront les listes de révocation de certificats (CRL). Si ces décisions ne sont pas documentées, créer l’autorité est prématuré.

Utilisez des autorités intermédiaires distinctes pour des environnements ou des niveaux d’assurance sensiblement différents. Un émetteur de développement compromis ne doit pas menacer automatiquement la production, et un émetteur de signature de code ne doit pas être interchangeable avec un émetteur général de certificats serveur. Les modèles doivent encoder ces frontières plutôt que de s’en remettre à la mémoire des opérateurs.

Provisionner une hiérarchie d’autorités

1. Confirmez le droit Enterprise et les scopes PKI requis.
2. Générez ou importez l’autorité racine.
3. Sauvegardez PKI_MASTER_KEY et la base de données d’Opfield via des procédures protégées distinctes.
4. Créez une autorité intermédiaire pour l’environnement ou la frontière organisationnelle prévus.
5. Créez des modèles pour les certificats serveur, client, de signature de code ou d’e-mail.
6. Émettez un certificat de test et vérifiez sa chaîne, l’usage de sa clé, sa durée de vie et son format d’export.
7. Publiez et testez l’emplacement de la CRL avant l’émission en production.

Émettre et exploiter des certificats

Consignez le responsable, l’objectif, le modèle, le sujet, la validité, l’attente de renouvellement et le contact de révocation de chaque certificat. N’accordez l’export de clé privée qu’aux identités qui ont besoin du matériel de clé. Un utilisateur qui peut examiner les métadonnées des certificats n’a pas automatiquement besoin de permissions sur les autorités ou l’export de clés.

Lorsqu’une Route utilise un certificat issu d’une CA interne, le nœud Ingress le sert avec ses CA intermédiaires, afin que les clients qui ne font confiance qu’à la racine puissent le valider.

Avant un renouvellement, vérifiez que le sujet et l’usage prévu sont toujours valables. Révoquez les certificats compromis ou retirés, publiez la CRL mise à jour et confirmez que les systèmes dépendants la consomment. Supprimer un enregistrement dans l’interface ne remplace pas la révocation lorsqu’un certificat peut encore être considéré comme de confiance à l’extérieur.

Validité, alertes d’expiration et réémission automatique

Un certificat ne peut pas survivre à la CA qui l’émet. Par défaut, une demande dont la validité se terminerait après celle de la CA est refusée avec VALIDITY_EXCEEDS_CA. Définissez clampToCaValidity dans l’API REST, MCP ou l’assistant pour faire se terminer le certificat avec sa CA ; la boîte de dialogue d’émission affiche un avis et l’applique automatiquement. Les certificats signés à partir d’une CSR suivent la même règle. Les certificats feuilles issus des CA système d’Opfield se terminent toujours avec leur CA.

Opfield déclenche des alertes d’expiration pour les CA utilisateurs 180, 60, 30 et 7 jours avant leur expiration (les deux dernières suivent les paramètres d’avertissement et de criticité d’expiration PKI) et pour les CA système 730, 365, 180, 60, 30 et 7 jours à l’avance. Les CA système n’ont pas encore de renouvellement automatique (rollover), et chaque certificat de nœud, de relais, de stockage managé et de base de données managée qu’elles ont émis cesse de fonctionner à leur expiration ; planifiez donc leur remplacement dès la première alerte. Les alertes nomment la ressource propriétaire, comme un cluster de stockage managé, une base de données managée, un relais, un écouteur d’Opfield ou un nœud. Chaque seuil n’alerte qu’une fois : ignorer une alerte vaut jusqu’au seuil suivant, et un certificat renouvelé alerte à nouveau au cours de sa nouvelle durée de vie.

Un certificat de PKI interne lié en tant que certificat SSL ou référencé directement par une Route est réémis automatiquement lorsqu’Opfield détient sa clé privée ; les certificats signés à partir d’une CSR ne sont jamais réémis. La réémission nécessite pki:cert:issue sur la CA, comme une émission manuelle.

Accordez pki:ca:edit pour modifier les URL de CRL et d’émetteur, la validité maximale et le répondeur OCSP d’une CA, et pki:ca:export pour exporter une CA avec sa clé privée ; les deux peuvent être restreints à une seule CA. pki:ca:view couvre les CA racines et intermédiaires et peut aussi être restreint à une seule CA.

Les autorités de certification, les certificats et les modèles de certificats peuvent être organisés en dossiers, comme les Routes et les certificats SSL : créez, renommez et réordonnez des dossiers, faites glisser des éléments de l’un à l’autre et choisissez un dossier lors de la création d’un élément. Un dossier de CA contient des hiérarchies entières : seules les CA racines se déplacent, et leurs intermédiaires suivent. Les permissions accordées sur un dossier de CA couvrent chaque CA racine qu’il contient et ses intermédiaires, et les permissions sur un dossier de certificats couvrent les certificats qu’il contient ; les dossiers de modèles de certificats ne servent qu’à organiser la liste. Voir Prise en charge des dossiers par type de ressource.

Mesurez le succès opérationnel par la couverture des expirations, la publication des révocations, l’exhaustivité de l’audit et les tests de restauration. Examinez les certificats sans responsable, les modèles trop larges, les exports de clés privées inattendus, les intermédiaires inutilisés et les CRL que les systèmes dépendants ne peuvent pas joindre. L’affichage ou l’export d’une clé privée doit rester rare, être autorisé séparément et être suivi d’une conservation sécurisée hors d’Opfield.

Sauvegarde et reprise

Une sauvegarde de la base de données sans PKI_MASTER_KEY ne permet pas de récupérer les clés privées chiffrées. Une sauvegarde de la clé sans la base de données ne permet pas de reconstituer les autorités, modèles, certificats, révocations et relations d’audit. Stockez et testez les deux parties tout en les gardant séparées sur le plan opérationnel.

Après une restauration, vérifiez les chaînes des autorités, le déchiffrement, les permissions d’export des certificats, la publication des CRL et la continuité de l’audit avant d’émettre du nouveau matériel.

Détails pour l’opérateur : incident et mise hors service

Si une clé d’émission est soupçonnée d’être compromise, arrêtez les nouvelles émissions, identifiez tous les certificats descendants, préparez une hiérarchie de remplacement, publiez les informations de révocation et coordonnez les modifications des magasins de confiance avec les systèmes dépendants. Restaurer la même clé compromise n’est pas une reprise. Conservez les éléments d’audit et l’ancienne chaîne publique pour l’enquête, sans continuer à leur faire confiance.

Mettre une autorité hors service ne se limite pas à la retirer de la navigation. Arrêtez l’émission, remplacez les descendants ou laissez-les expirer, conservez les preuves de révocation pendant la durée requise, retirez la confiance des clients, et ne supprimez l’autorité qu’une fois qu’Opfield confirme que les objets dépendants sont résolus.

Droits et comportement de suppression

Après la fin d’une période de grâce de licence, Opfield conserve les autorités et les certificats et laisse disponibles la consultation, les listes de révocation, la révocation et l’export des certificats ainsi que la suppression, tandis que la création d’autorités, l’émission de certificats et la modification des modèles exigent à nouveau le plan. Le transport système n’est jamais désactivé. Avant de supprimer une autorité, résolvez toutes les intermédiaires et tous les certificats enfants et conservez les preuves de révocation requises.