Le renouvellement est terminé, les abonnements Microsoft Graph répondent et le webhook reçoit toujours des messages. Pourtant, certaines notifications ne peuvent plus être ouvertes. L’équipe a remplacé le certificat utilisé pour chiffrer les données, puis supprimé trop vite l’ancienne clé privée. Le blocage touche les messages qui réclament encore cette clé, même si les nouvelles réceptions fonctionnent.
La réussite d’une rotation se mesure à la capacité de traiter les notifications des deux générations. Modifier un abonnement et retirer un moyen de déchiffrement sont deux décisions différentes. Entre les deux, il faut observer les messages reçus, ceux conservés pour une reprise et les erreurs qui empêchent leur exploitation.
Pour une intégration API exploitée dans la durée, cette distinction protège les demandes commerciales et les événements métier déjà collectés. Nous suivons ici une relève fictive entre deux certificats, avec six notifications et une file de reprise. Les noms, horaires et volumes sont pédagogiques ; ils ne représentent ni un client Dawap ni une durée garantie par Microsoft.
La conception d’une intégration Microsoft Graph couvre aussi les consommateurs différés, leurs permissions et la reprise des notifications conservées.
Pour qui : les notifications Graph contenant des données chiffrées
Ce problème concerne les notifications enrichies qui embarquent des données de ressource chiffrées. Une notification basique, utilisée comme signal avant une lecture séparée de la ressource, n’emprunte pas exactement ce parcours. Commencez donc par identifier les abonnements concernés, les ressources supportées et le mode réellement utilisé par votre application.
La documentation Microsoft sur les notifications enrichies décrit les propriétés encryptionCertificate et encryptionCertificateId. Elle précise qu’après un changement, l’ancienne clé peut encore être nécessaire. Le message indique le certificat à utiliser ; le consommateur doit pouvoir retrouver la clé correspondante.
Ne pas confondre les deux usages d’un certificat
Le certificat servant à ouvrir ces données n’est pas automatiquement celui qui authentifie votre application auprès de la plateforme. Un incident de déchiffrement et un refus d’authentification demandent des diagnostics différents. N’essayez pas de réparer le premier en renouvelant au hasard les identifiants de connexion ou en élargissant les permissions.
Avant la rotation, faites nommer ces responsabilités par l’équipe : qui administre les abonnements, qui gère les clés, qui exploite la file et qui vérifie l’effet dans l’outil métier ? Une même personne peut cumuler plusieurs rôles. Le problème apparaît lorsqu’aucune équipe ne sait si la suppression d’une clé affecte encore un traitement ancien.
Inventorier les consommateurs avant de publier le nouveau certificat
Le webhook visible n’est souvent que la porte d’entrée. Il peut transmettre à une file, à un traitement nocturne, à une file d’échecs ou à un outil de reprise manuel. Chaque chemin susceptible de recevoir une ancienne notification doit disposer du mécanisme de sélection de clé, ou déléguer le déchiffrement à un service qui le possède.
Relevez les abonnements actifs et leur périmètre, les identifiants de certificats déclarés, les déploiements des consommateurs et les emplacements où les notifications sont conservées. Une liste des serveurs ne suffit pas : une tâche éteinte depuis trois jours peut redémarrer avec une ancienne configuration et consommer un stock de messages oublié.
Utiliser une correspondance explicite
Dans l’exemple, notif-A et notif-B désignent deux générations différentes. Le consommateur consulte une correspondance contrôlée entre l’identifiant reçu et la référence du secret autorisé. Il ne transforme pas une valeur reçue en chemin de fichier arbitraire et ne suppose pas que « le dernier certificat installé » convient à tous les messages.
Les journaux enregistrent l’identifiant, l’abonnement, le résultat du traitement et une référence de diagnostic. Ils ne contiennent ni la clé privée ni une copie systématique du contenu déchiffré. Pour enquêter, l’exploitant a besoin de localiser l’échec, pas de multiplier les copies des données sensibles dans les outils de supervision.
Suivre six notifications pendant une relève fictive
À 9 h 00, le consommateur sait utiliser A et B. À 9 h 10, l’équipe modifie les abonnements prévus pour employer B. À 9 h 20, elle constate encore des références à A. Cette chronologie représente une recette construite par l’équipe ; elle ne définit pas un délai normal de propagation du service.
| Notification | Observation | Décision attendue |
|---|---|---|
| N1, référence A | Reçue avant la modification, encore en file. | Ouvrir avec A puis poursuivre le traitement métier. |
| N2, référence B | Reçue après la modification. | Ouvrir avec B sans modifier N1. |
| N3, référence A | Arrive alors que B est déjà déclaré. | Accepter la coexistence ; ne pas conclure à une attaque sur ce seul indice. |
| N4, référence inconnue | Aucune clé autorisée ne correspond. | Isoler l’événement et examiner son origine ; aucune recherche de clé à l’aveugle. |
| N5, référence B | Échec de vérification de l’intégrité. | Refuser l’exploitation du contenu et ouvrir un diagnostic distinct. |
| N6, référence A | Reprise d’un ancien échec après correction du CRM. | Retrouver A ou appliquer la procédure de récupération prévue. |
N6 est le piège le moins visible. Le message n’arrive plus depuis Microsoft ; il revient d’une file locale. Une supervision limitée aux nouvelles réceptions peut annoncer la disparition de A alors que l’application conserve encore des données qui en dépendent. Le retrait doit regarder les deux populations.
Pour chaque notification valide, distinguez aussi l’ouverture cryptographique et la réussite métier. Une donnée correctement déchiffrée peut échouer ensuite à cause d’un compte client absent ou d’un CRM indisponible. Le statut final doit permettre de reprendre cette seconde étape sans transformer la rotation en prétexte pour recréer le même dossier.
Déployer la capacité de lecture avant de changer les abonnements
Commencez par mettre B à disposition des consommateurs autorisés, tout en conservant A. Vérifiez la nouvelle configuration sur chaque instance et sur le chemin de reprise. Ensuite seulement, modifiez un premier périmètre d’abonnements, observez les résultats et élargissez lorsque les notifications produisent l’effet attendu dans l’application.
Microsoft documente la mise à jour des deux propriétés de chiffrement sur les abonnements, notamment lors de leur renouvellement. Conservez le résultat réellement retourné par l’API et les erreurs par abonnement. Un script qui se termine sans exception globale ne prouve pas que toute la liste a été modifiée.
Préparer l’échec partiel
Si huit abonnements changent et deux restent sur A, l’état recherché n’est pas « presque terminé ». Il faut identifier les deux exceptions, comprendre leur réponse et maintenir leur traitement. Une nouvelle exécution reprend cette liste précise ; elle ne recrée pas indistinctement tous les abonnements et leurs événements.
La récupération des données manquantes dépend ensuite de la ressource et des mécanismes qu’elle expose. Pour les flux Outlook concernés, le dossier sur les messages absents du CRM traite le rattrapage et les curseurs. Une rotation de certificat ne donne pas, à elle seule, le droit de supposer qu’une lecture historique quelconque reconstituera tous les événements perdus.
Décider du retrait de A depuis les dépendances restantes
Le responsable sécurité et l’exploitant doivent partager la même vue : abonnements encore configurés sur A, dernières notifications observées, messages en attente, archives rejouables et consommateurs hors ligne. Chaque dépendance restante reçoit une décision : terminer, récupérer autrement, conserver sous contrôle ou renoncer explicitement au rejeu selon les obligations du dossier.
La recommandation Microsoft est de ne retirer l’ancien certificat qu’après disparition des notifications récentes qui le référencent. Votre politique doit compléter ce point par l’examen des files locales et des durées de conservation réellement retenues. Fixer arbitrairement vingt-quatre heures pour toutes les installations masque ces différences.
Ne pas traiter une compromission comme un renouvellement ordinaire
Si A est soupçonnée d’être compromise, le choix change : maintenir sa disponibilité pour faciliter une reprise peut devenir inacceptable. La procédure d’incident doit décider de la limitation des accès, de la récupération des données et des conséquences sur les messages conservés. Le calendrier de confort d’une rotation normale ne doit pas retarder cette décision.
Une fois le retrait autorisé, vérifiez que les consommateurs ne demandent plus A et qu’une tentative ancienne produit une erreur identifiable. Évitez de conserver une copie cachée « au cas où » dans un répertoire de dépannage. Si une conservation temporaire est décidée, elle appartient au dispositif de secrets et possède un responsable ainsi qu’une échéance contrôlée.
Erreurs fréquentes : un abonnement vert, une file illisible
Remplacer une variable globale par B casse les messages de A. Supprimer A dès le premier succès de B confond preuve de nouveauté et disparition de l’ancien. Tester seulement le webhook ignore les consommateurs différés. Ces trois erreurs produisent le même symptôme apparent, mais pas la même correction.
Un autre raccourci consiste à acquitter puis jeter les notifications impossibles à ouvrir. La file paraît alors saine parce que les éléments ont disparu. Préparez un stockage d’échec contrôlé, une classification et une alerte ; l’acquittement de transport ne doit pas servir de preuve de traitement métier.
Enfin, ne réessayez pas indéfiniment une référence inconnue. Une absence de clé, un refus d’accès au coffre et une intégrité invalide méritent des catégories distinctes. Cette séparation réduit les reprises inutiles et permet d’orienter le bon spécialiste sans exposer le contenu des notifications.
Plan d’action : recevoir la rotation avec une file réellement mixte
La première séance réunit l’inventaire des abonnements et des chemins de consommation. Prenez une notification de chaque génération dans un environnement de recette adapté, puis préparez un message inconnu et un message altéré. Le résultat attendu est écrit avant l’essai, y compris pour les éléments que l’application doit refuser.
La deuxième étape exerce le retard : suspendez un consommateur, effectuez la relève et redémarrez-le avec un mélange de références A et B. Ajoutez une panne métier après déchiffrement. Le dossier doit montrer quels messages restent à traiter et comment leur reprise évite un second effet commercial.
La troisième étape vérifie les incidents de coffre et le déploiement incomplet. Un consommateur privé d’accès ne doit ni absorber silencieusement les événements ni interrompre tous les périmètres sans distinction. L’équipe mesure les messages en attente par cause et leur ancienneté, puis confirme que le rattrapage fonctionne après correction.
Enfin, faites signer la décision de retrait sur les dépendances observées. Gardez les références des essais, la liste finale des abonnements et la procédure de récupération. La réception devient alors une vérification reproductible, indépendante de la personne qui a exécuté le script de renouvellement.
- Bloquer le retrait de A si une file de reprise référence encore cette clé sans solution de récupération approuvée.
- Autoriser l’élargissement à un autre abonnement seulement après un message valide traité avec B et un ancien message traité avec A.
- Isoler une référence inconnue plutôt que tenter plusieurs clés au hasard ou supprimer le message pour vider la file.
Rapprocher la rotation des autres mécanismes de collecte
Le rattrapage d’un abonnement
Quand le déchiffrement fonctionne mais que des demandes restent absentes du CRM, il faut revenir au périmètre collecté et à sa reprise. Ce parcours examine les abonnements et les curseurs sans supposer que la rotation a, à elle seule, récupéré les événements manqués. Retrouver les messages Outlook absents du CRM.
Le certificat qui authentifie un worker
Une clé utilisée pour signer une connexion pose une autre question : quel processus continue de l’employer ? Cette lecture aide à inventorier les instances techniques, tout en conservant la distinction entre authentification de l’application et déchiffrement des notifications Graph. Vérifier les certificats utilisés par les workers.
Conclusion : retirer une clé seulement après avoir compris ses derniers usages
La rotation est achevée lorsque les nouvelles notifications fonctionnent et que le sort des anciennes est connu. La présence de B dans les abonnements ne démontre pas que A est devenue inutile. Les files, les reprises et les consommateurs différés font partie du périmètre.
Le scénario des six notifications donne une recette simple : choisir la clé indiquée, distinguer l’intégrité de l’effet métier et rendre les exceptions visibles. Il permet de discuter du retrait avec des éléments concrets, plutôt qu’avec la seule date de déploiement.
Dawap accompagne vos intégrations API et traitements de notifications pour relier configuration, gestion des secrets et exploitation métier. Le livrable utile est une relève que l’équipe peut vérifier, reprendre et expliquer sans perdre les demandes déjà reçues.
