Rotation des clés DKE : manuelle et planifiée
Faites pivoter la clé d'un service DKE 365 quand vous le décidez, ou laissez le Cockpit la faire pivoter pour vous à intervalle fixe.
Un service DKE sert une clé RSA courante (RSA-2048 ou RSA-4096). Vous pouvez la faire pivoter manuellement à tout moment, ou donner au service un calendrier de rotation pour que le Cockpit la fasse pivoter automatiquement.
Ce que fait une rotation
Vérifier la nouvelle clé
La nouvelle clé est vérifiée de bout en bout sur son coffre : ce doit être une clé RSA à l'état Active, le coffre doit répondre, et un aller-retour chiffrement / déchiffrement RSA-OAEP doit réussir.
La rendre courante
À partir de là, GetKey renvoie la nouvelle clé publique, et les nouveaux documents sont scellés avec elle.
Garder la clé précédente en déchiffrement seul
La clé précédente passe dans l'historique des clés du service en déchiffrement seul. Elle continue de répondre à GetKey sous son propre identifiant et de déchiffrer : les documents scellés avant la rotation s'ouvrent toujours. Elle n'expire jamais d'elle-même : elle reste en déchiffrement seul jusqu'à ce qu'un administrateur la retire, et une clé retirée peut être restaurée.
L'URL de l'étiquette (https://{slug}.{domaine DKE}/dke/{slug}) désigne le service, pas une clé : les étiquettes de confidentialité ne changent pas lors d'une rotation. Voir Rotation des clés et historique des clés.
Ce que voient les clients Office
| Situation | Ce qui se passe |
|---|---|
| Le client récupère la clé publique après la rotation | Il obtient la nouvelle clé et scelle les nouveaux documents avec elle. |
| Le client a encore la clé publique précédente en cache | Il continue de sceller avec la clé précédente jusqu'à l'expiration de son cache (durée de cache du service, 24 heures par défaut). Ces documents s'ouvrent quand même, car la clé précédente est en déchiffrement seul, pas supprimée. |
| Ouverture d'un document | Le déchiffrement va toujours vers l'identifiant de clé enregistré dans le document : anciens et nouveaux documents s'ouvrent tant que leur clé est courante ou en déchiffrement seul. |
| Clé retirée par un administrateur | Tous les documents scellés avec cette clé deviennent illisibles via ce service jusqu'à la restauration de la clé. |
Ne retirez une clé sortie de rotation que lorsque vous n'avez plus besoin des documents scellés avec elle. Si vous avez retiré une clé par erreur, restaurez-la depuis l'historique des clés.
La page de détail du service liste la clé courante, les clés en déchiffrement seul et les clés retirées, ainsi qu'une chronologie indiquant qui a fait pivoter, retiré ou restauré quelle clé, et quand.
Rotation manuelle
Créer la nouvelle clé
Créez une clé RSA (dans n'importe quel coffre du tenant) et activez-la.
Faire pivoter
Sur la page de détail du service DKE, choisissez Rotate key, sélectionnez la nouvelle clé RSA Active et confirmez.
POST /api/dke/services/{id}/rotate-key
{ "new_key_id": "<key id>" }L'appel requiert la permission Operations.Dke.Update et est audité sous DkeKeyRotated.
Rotation planifiée
Un service peut faire pivoter sa clé seul, à intervalle fixe. Par défaut, un service n'a pas de calendrier (rotation manuelle uniquement).
Définir le calendrier dans le Cockpit
La carte Scheduled rotation de la page de détail du service DKE affiche l'intervalle, la prochaine rotation automatique, la dernière rotation automatique et la dernière erreur éventuelle. Edit schedule propose :
| Choix | Intervalle |
|---|---|
| Manuelle uniquement | Pas de rotation automatique (défaut) |
| Tous les 30 jours | 30 jours |
| Tous les 6 mois | 180 jours |
| Tous les ans | 365 jours |
| Personnalisé | Tout nombre de jours de 1 à 3650 |
Modifier le calendrier requiert la même permission qu'une rotation manuelle (Operations.Dke.Update) : décider quand la clé pivote est aussi sensible que la faire pivoter. Les utilisateurs sans cette permission voient la carte mais pas le bouton Edit schedule. Un service arrêté ne peut pas recevoir de calendrier et ne pivote jamais.
Définir le calendrier via l'API
PUT /api/dke/services/{id}/rotation-schedule
{ "rotation_interval_days": 30 } // 1 à 3650, ou null pour manuel uniquementPUT /api/dke/services/{id} accepte le même champ rotation_interval_days : absent, le calendrier est inchangé ; null, la rotation devient manuelle uniquement. Les deux routes requièrent Operations.Dke.Update, et la modification est auditée sous DkeRotationScheduleUpdated.
GET /api/dke/services/{id} renvoie l'état du calendrier :
| Champ | Signification |
|---|---|
rotation_interval_days | Intervalle en jours, ou null pour manuel uniquement |
next_rotation_at | Échéance de la prochaine rotation automatique |
last_auto_rotation_at | Date de la dernière rotation automatique réussie |
last_auto_rotation_error | Erreur de la dernière tentative échouée, effacée en cas de succès |
auto_rotation_failures | Nombre d'échecs consécutifs |
Quand a lieu la prochaine rotation
Lorsque vous définissez un intervalle, la prochaine rotation est calculée à partir du moment où la clé courante l'est devenue (sa dernière rotation), ou à partir de maintenant si le service n'a jamais pivoté. Si la clé courante est déjà plus ancienne que l'intervalle, le service est échu immédiatement et pivote au prochain passage de la tâche.
Chaque rotation réussie, manuelle ou automatique, relance le compteur : la prochaine rotation automatique passe à date de rotation + intervalle.
Ce que fait la tâche planifiée
La tâche de rotation s'exécute toutes les heures (à la minute 20). Pour chaque service échu, dans un tenant actif dont l'édition inclut DKE 365 et la gestion des clés, elle :
Génère une nouvelle clé dans le même coffre
Même type et même taille, mêmes capacités, exportabilité, indicateur d'audit et unité organisationnelle, et mêmes rattachements aux politiques crypto et de quorum que la clé courante. La nouvelle clé passe les mêmes contrôles qu'une clé créée manuellement (fonctionnalité d'édition pour le type de clé, quota de clés du tenant, politique crypto du coffre). Elle porte le nom de la clé courante suivi du suffixe -rot-YYYYMMDDHHMMSS, puis est activée.
Fait pivoter le service sur cette clé
Exactement comme une rotation manuelle : vérification de bout en bout d'abord, puis la clé précédente passe en déchiffrement seul.
Audite la rotation
La rotation est enregistrée sous DkeKeyRotated, avec le système comme acteur et reason: scheduled.
Une seule instance du Cockpit exécute chaque occurrence horaire, et chaque service est réservé avant sa rotation : plusieurs réplicas, une exécution manuelle de la tâche ou une rotation manuelle au même moment ne font jamais pivoter un service deux fois.
Approbation par quorum (M-of-N)
Si la politique de quorum qui s'applique à la clé courante (une politique rattachée à la clé, sinon celle rattachée à son coffre) exige une approbation pour l'opération rotate, la tâche planifiée ne la contourne pas :
- elle ouvre une demande d'approbation pour
rotatesur la clé, avec le système comme demandeur, ou réutilise celle déjà ouverte ; - elle ne fait pas encore pivoter la clé. La carte Scheduled rotation affiche Waiting for quorum approval avec l'identifiant de la demande, et une seule alerte est envoyée par demande (activité
DkeKeyAutoRotationPendingApproval, événement webhookdke.rotation_pending_approval) ; - elle revérifie toutes les heures. Une fois la demande approuvée par les approbateurs, le passage suivant fait pivoter la clé et marque l'approbation comme consommée : elle ne peut pas servir deux fois.
L'attente d'approbation n'est pas comptée comme un échec. La nouvelle clé hérite du rattachement de quorum de l'ancienne : la rotation planifiée suivante est soumise à la même approbation.
Donnez à la politique de quorum une durée de validité d'approbation supérieure à une heure. Sinon, une approbation peut expirer avant que la tâche horaire ne la prenne en compte, et une nouvelle demande est ouverte.
Échecs, nouvelles tentatives et alertes
Une rotation planifiée peut échouer, par exemple si le coffre est injoignable, si le quota de clés est atteint, si la politique crypto refuse la clé, si la vérification de bout en bout échoue, ou si l'édition n'inclut plus DKE ou la gestion des clés. Dans ce cas :
- le service continue de servir sa clé courante : rien ne change pour les utilisateurs Office ;
- l'erreur et le nombre d'échecs consécutifs s'affichent sur la carte Scheduled rotation (
last_auto_rotation_error,auto_rotation_failures) ; - la tâche réessaie après 1 heure, puis 6 heures, puis toutes les 24 heures jusqu'au succès ;
- une clé générée pour la tentative échouée est désactivée puis supprimée : les nouvelles tentatives n'accumulent pas de clés inutilisées.
Chaque échec déclenche une alerte sur tous les canaux configurés par le tenant :
| Canal | Ce qui est envoyé |
|---|---|
| Journal d'activité et SIEM | Une ligne d'activité DkeKeyAutoRotationFailed, transmise au SIEM configuré |
| Webhooks (Slack, Teams, Rocket.Chat, générique) | L'événement dke.rotation_failed, pour les abonnements à cet événement ou à dke.* |
| Un message aux destinataires d'alertes du tenant, lorsque les alertes e-mail sont activées (paramètres Certificate alerts) |
Enregistrer à nouveau le calendrier efface l'erreur et le compteur d'échecs ; une rotation manuelle réussie aussi.
Référence des événements
| Type d'activité | Quand |
|---|---|
DkeKeyRotated | Une clé a pivoté (manuellement, ou avec reason: scheduled) |
DkeRotationScheduleUpdated | L'intervalle de rotation a été défini, modifié ou supprimé |
DkeKeyAutoRotationFailed | Une rotation planifiée a échoué et sera retentée |
DkeKeyAutoRotationPendingApproval | Une rotation planifiée attend l'approbation du quorum |
DkeKeyRetired / DkeKeyRestored | Une clé sortie de rotation a été retirée / restaurée |
| Événement webhook | Quand |
|---|---|
dke.rotation_failed | Une rotation planifiée a échoué |
dke.rotation_pending_approval | Une rotation planifiée requiert une approbation du quorum |