# La sécurité des bureaux d’enregistrement exige une approbation par appel

Donner à un agent IA un identifiant d’API de bureau d’enregistrement ne lui confère pas un pouvoir unique et cohérent. Cela lui donne plusieurs pouvoirs sans lien direct, réunis derrière le même secret : rediriger le domaine, le préparer à un transfert, changer les personnes qui reçoivent les avis de récupération et modifier la chaîne de confiance DNSSEC. La sécurité d’un bureau d’enregistrement échoue lorsqu’une couche d’approbation traite tous ces appels comme interchangeables.

Chaque appel de modification d’état au bureau d’enregistrement mérite une décision liée à l’action exacte, au domaine, à l’ancienne valeur et à la valeur proposée. Une personne peut approuver le remplacement des serveurs de noms lors d’une migration planifiée tout en refusant la suppression d’un verrou, un changement d’adresse e-mail du titulaire ou la suppression d’un DS effectués dans la même exécution. L’approbation de session seule ne peut pas exprimer cette différence.

## Un identifiant masque plusieurs frontières de sécurité

Un identifiant de bureau d’enregistrement prouve une authentification, pas une intention humaine. Même lorsqu’un fournisseur propose des permissions d’API fines, les équipes regroupent souvent plusieurs actions d’écriture requises dans un même rôle pour qu’un travail automatisé puisse aboutir. D’autres fournisseurs exposent un jeton étendu de bureau d’enregistrement. Dans les deux cas, le fait de posséder l’identifiant répond uniquement à la question de savoir qui peut demander. Cela ne dit pas si ce changement précis doit avoir lieu maintenant.

Les protocoles sous-jacents ne prétendent pas que ces opérations sont équivalentes. RFC 5731, le mappage de domaine EPP utilisé entre bureaux d’enregistrement et registres, décrit les associations de serveurs de noms, les associations de contacts, les valeurs d’état et les informations d’autorisation comme des attributs distincts du domaine. Sa commande de mise à jour peut ajouter ou supprimer des serveurs de noms et des contacts, changer le titulaire, modifier les informations d’autorisation et les valeurs d’état client. Une API pratique peut placer ces opérations sous un même identifiant, mais l’état du registre conserve leurs significations distinctes.

Un bureau d’enregistrement de cloud public rend la même distinction visible dans sa liste de commandes. L’API Route 53 Domains propose des opérations distinctes pour `UpdateDomainNameservers`, `UpdateDomainContact`, `DisableDomainTransferLock`, `AssociateDelegationSignerToDomain` et `DisassociateDelegationSignerFromDomain`. Cette liste est utile, car elle nomme les décisions qu’un système d’approbation doit préserver au lieu de les aplatir en `registrar.write`.

J’utilise quatre questions avant de donner à un agent un accès au bureau d’enregistrement :

- Cet appel peut-il rediriger la résolution de tout le domaine ?
- Peut-il faciliter un vol ou une récupération ultérieurs ?
- Peut-il changer les personnes qui reçoivent les messages de contrôle ou de vérification ?
- Peut-il amener des résolveurs validants à rejeter des réponses DNS pourtant correctes ?

Si deux appels donnent des réponses différentes, ils correspondent à deux actions d’approbation distinctes. Partager une clé d’API ne les fusionne pas.

## Un changement de serveurs de noms délègue toute la zone

Remplacer les serveurs de noms confie l’autorité DNS au nouvel ensemble de serveurs. Son rayon d’impact est donc bien plus large que la modification d’un seul enregistrement. RFC 8499 définit la délégation comme l’ajout par le parent d’un ensemble d’enregistrements NS pour l’origine enfant. Une fois que les caches suivent cette délégation, les nouveaux serveurs faisant autorité peuvent répondre pour les adresses web de la zone, ses serveurs de messagerie, ses enregistrements de découverte de service et ses enregistrements TXT de vérification.

Cette dernière catégorie rend le risque facile à sous-estimer. RFC 8555 indique qu’un client ACME peut prouver le contrôle d’un domaine en publiant une valeur TXT sous `_acme-challenge`. L’opérateur qui contrôle la zone déléguée peut répondre à ce défi et demander des certificats pour des noms sous le domaine, sous réserve des vérifications de l’autorité de certification. Un changement de serveurs de noms n’est donc pas un simple réglage d’hébergement.

L’approbation doit afficher les ensembles complets d’anciens et de nouveaux serveurs, et non une phrase comme `update DNS`. Les ensembles comptent, car une migration ajoute souvent des serveurs avant d’en retirer d’anciens, tandis que certaines API de bureaux d’enregistrement remplacent tout l’ensemble dans un seul appel. Le relecteur doit voir si la demande conserve chaque serveur voulu, si des adresses glue sont concernées et si les serveurs ciblés répondent déjà de manière autoritative pour la zone.

Avant l’approbation, interrogez directement chaque serveur proposé au lieu de faire confiance à un cache récursif :

```sh
for ns in ns1.new-dns.example ns2.new-dns.example; do
  dig +norecurse +short @"$ns" example.com SOA
  dig +norecurse +short @"$ns" example.com MX
done
```

Un contrôle sain renvoie une ligne SOA de chaque serveur et les cibles MX attendues. Une sortie vide, des numéros de série incohérents ou des réponses sans autorité demandent une investigation. Le plan de migration précis détermine si les numéros de série doivent déjà correspondre, mais le relecteur ne doit jamais approuver un nom de serveur qui n’a pas répondu pour la zone.

Le dossier d’approbation doit identifier cette action comme `nameserver.replace`, inclure la demande ordonnée et une différence d’ensembles normalisée, puis préciser si l’appel modifie aussi les adresses glue. Ne la cachez pas dans une mise à jour générique du domaine : une erreur plausible de l’agent peut rediriger tous les services d’un coup.

## Retirer un verrou de transfert ouvre une fenêtre

Désactiver un verrou de transfert ne transfère pas un domaine, mais retire un contrôle qui empêche le transfert. L’ICANN appelle le verrou familier du bureau d’enregistrement `clientTransferProhibited`, ou un statut similaire. RFC 5731 indique qu’une demande de transfert doit être rejetée tant que `clientTransferProhibited` ou `serverTransferProhibited` s’applique.

Cette distinction compte lors de la revue. Un agent peut avoir besoin de retirer correctement le verrou d’un domaine avant un déplacement prévu. Une suppression de verrou inattendue reste toutefois dangereuse, car elle crée une condition utile pour un autre acteur. Traitez `transfer_lock.disable` comme une action à part entière et exigez que la demande nomme le bureau d’enregistrement de destination, le ticket de changement et l’heure prévue de reverrouillage ou d’achèvement. Ces champs n’obligent pas le bureau d’enregistrement à suivre le plan, mais ils donnent à l’approbateur assez de contexte pour refuser une suppression de verrou inexpliquée.

Le code d’autorisation est un secret distinct et une décision distincte. Sa récupération ne doit jamais être dissimulée dans l’approbation de la suppression du verrou. Un plan de contrôle utile demande une première fois de retirer le verrou, puis une seconde fois de récupérer ou d’utiliser le code d’autorisation de transfert. Si le flux modifie aussi le titulaire, l’ordre compte, car la politique de transfert de l’ICANN impose, dans les cas concernés, un verrou inter-registraire de 60 jours après un changement de titulaire, sauf si le bureau d’enregistrement a proposé un retrait avant la modification et que le titulaire l’a choisi.

Une recommandation répandue conseille de laisser le domaine verrouillé et d’en déduire que l’automatisation du bureau d’enregistrement est sûre. Le verrou aide, mais ce conseil s’arrête trop tôt. Un identifiant capable de retirer le verrou peut aussi supprimer cette protection. L’approbation par appel rend la suppression visible au moment où elle importe, tandis qu’une politique permanente qui vérifie seulement l’état actuel du verrou peut être invalidée par la requête d’API suivante.

Activer le verrou est généralement une correction moins risquée, mais cela reste une écriture avec des conséquences opérationnelles. Elle peut bloquer un transfert légitime déjà en cours. Affichez l’état du transfert en attente et laissez une personne confirmer, sauf si une procédure d’incident autorise explicitement un reverrouillage d’urgence.

## Les changements de contact modifient le chemin de récupération

La mise à jour d’un contact titulaire ou administratif change les personnes qui reçoivent des avis importants et peut modifier l’éligibilité au transfert. Elle ne redirige pas immédiatement le trafic, ce qui pousse les équipes à la classer sous les travaux sur les serveurs de noms. Ce classement ignore la façon dont la récupération d’un domaine se déroule réellement.

L’ICANN demande aux titulaires de garder leurs coordonnées à jour, car les bureaux d’enregistrement envoient par e-mail les avis de protection et de gestion. Sa politique de transfert associe aussi un changement de titulaire à un verrou de transfert de 60 jours dans certaines circonstances. Un agent qui remplace l’adresse e-mail du titulaire juste avant un transfert planifié peut retarder le travail. Un attaquant qui modifie un contact joignable peut perturber les notifications ou une récupération future, selon le processus du bureau d’enregistrement et du registre.

La carte d’approbation doit montrer les différences champ par champ. `contact.update` est trop vague quand la demande modifie simultanément une adresse e-mail, un numéro de téléphone, une organisation, un réglage de confidentialité et l’identité du titulaire. Affichez chaque ancienne et nouvelle valeur, indiquez les rôles de contact modifiés et précisez si le bureau d’enregistrement signale une restriction de transfert qui en résulte. Le masquage peut protéger les données personnelles dans les journaux courants, mais la personne qui autorise un changement d’identité sensible doit voir assez d’informations pour reconnaître le destinataire attendu.

Ne laissez pas un agent résoudre l’échec d’une mise à jour de contact en modifiant sans cesse des champs jusqu’à ce que l’API les accepte. Les registres appliquent des règles de validation différentes, et certains domaines nationaux imposent des exigences supplémentaires. Un flux plus sûr valide la charge utile, demande une approbation pour la différence finale, l’envoie une seule fois et enregistre l’identifiant d’opération du fournisseur. Si le fournisseur traite le changement de façon asynchrone, l’action reste en attente jusqu’à ce qu’une lecture confirme l’état voulu.

La confidentialité du contact est une autre action distincte. Modifier l’exposition de la confidentialité n’équivaut pas à changer le titulaire sous-jacent. Un relecteur peut accepter l’activation de la confidentialité et refuser un changement de propriété. Un système d’approbation ne doit donc pas les réunir sous prétexte qu’un fournisseur utilise le même point de terminaison.

## Les changements DNSSEC peuvent faire échouer des réponses correctes

Un changement de délégation DNSSEC modifie la chaîne par laquelle les résolveurs validants authentifient la zone enfant. RFC 4034 est précis : l’enregistrement DS renvoie à un DNSKEY grâce à une étiquette de clé, un algorithme et un condensat, et le DS se trouve du côté parent de la délégation. Le DNSKEY correspondant se trouve dans la zone enfant. Les API de bureaux d’enregistrement transmettent souvent le matériel DS au registre, car le titulaire ne peut pas modifier directement la zone parent.

Un mauvais serveur de noms peut rediriger les réponses. Un mauvais enregistrement DS peut amener les résolveurs à considérer comme frauduleuses des réponses authentiques. C’est un mode de défaillance différent et il demande une revue différente. Supprimer un DS peut transformer, après mise à jour des caches, une zone déléguée de manière sécurisée en délégation non sécurisée. Ajouter un DS qui ne correspond pas à un DNSKEY publié peut casser la validation. Retirer trop tôt l’ancien DS lors d’un renouvellement de clé peut abandonner des validateurs qui s’appuient encore sur des données en cache.

L’approbation de `dnssec.ds.add`, `dnssec.ds.replace` et `dnssec.ds.remove` doit afficher l’étiquette de clé, l’algorithme, le type de condensat, l’empreinte du condensat et les preuves DNSKEY recueillies auprès de chaque serveur faisant autorité. Le relecteur doit aussi voir si la demande ajoute un chevauchement pendant un renouvellement ou remplace le seul DS en une opération.

Ces commandes exposent les deux côtés de la chaîne :

```sh
dig +short example.com DS
dig +short example.com DNSKEY
dig +dnssec example.com A
```

La première requête demande, par le chemin de résolution normal, les données DS du côté parent. La deuxième récupère l’ensemble DNSKEY de la zone enfant. La troisième affiche la réponse et les enregistrements DNSSEC employés pour la validation. Sur un chemin validant, les indicateurs de réponse peuvent inclure `ad` lorsque le résolveur a authentifié les données. Ne réduisez pas la revue à la seule correspondance de l’étiquette de clé numérique. Le condensat et l’algorithme doivent correspondre au DNSKEY voulu, et la séquence de déploiement doit tenir compte des caches.

Le flux « activer DNSSEC » en un clic d’un hébergeur DNS peut coordonner ces détails pour une personne. Un agent qui utilise séparément les API du bureau d’enregistrement et du DNS n’hérite pas automatiquement de cette protection. Exigez une séquence proposée, la preuve que la nouvelle clé est publiée et une approbation explicite de chaque modification côté parent.

## L’approbation doit se lier à une action normalisée

L’objet d’approbation doit décrire le sens de l’opération, au lieu d’exposer seulement une requête HTTP brute. Les URL, les noms d’opérations du fournisseur et les formes JSON varient. Un nom d’action interne stable permet au relecteur de reconnaître le même événement de sécurité chez plusieurs bureaux d’enregistrement, sans prétendre que les fournisseurs se comportent de façon identique.

Voici une enveloppe d’action pratique pour la frontière d’un outil agent :

```json
{
  "action": "nameserver.replace",
  "domain": "example.com",
  "before": {
    "nameservers": ["ns1.old-dns.example", "ns2.old-dns.example"]
  },
  "after": {
    "nameservers": ["ns1.new-dns.example", "ns2.new-dns.example"]
  },
  "reason": "CHG-1842 registrar migration",
  "evidence": {
    "authoritative_checks": "passed",
    "checked_at": "2026-07-24T14:25:00Z"
  },
  "request_hash": "sha256:..."
}
```

La passerelle doit déduire l’action de la méthode, du point de terminaison et du corps validé. L’agent ne doit pas pouvoir choisir une étiquette d’action rassurante tout en envoyant une requête différente. Liez l’approbation à un hachage de requête canonique afin que l’agent ne puisse pas obtenir un consentement pour un ensemble de serveurs de noms puis en soumettre un autre. Si un fournisseur asynchrone exige un second appel pour confirmer une opération, classez et approuvez cet appel selon ce qu’il engage.

La normalisation rend aussi visibles les modifications mixtes. RFC 5731 permet qu’une même commande de mise à jour de domaine touche les serveurs de noms, les contacts, les valeurs d’état et les informations d’autorisation. Si un point de terminaison accepte plusieurs catégories dans une seule charge utile, séparez le flux avant l’approbation lorsque l’API le permet. Lorsqu’elle ne le permet pas, affichez chaque action dans l’approbation et appliquez la décision la plus stricte. Une étiquette telle que `domain.update` n’apprend presque rien au relecteur.

Refusez les demandes qui omettent l’état actuel. Sans lecture récente, la différence peut s’appuyer sur des hypothèses périmées et écraser la modification de quelqu’un d’autre. Utilisez le jeton de version du fournisseur ou sa fonctionnalité de requête conditionnelle lorsqu’elle existe. S’il n’offre ni l’un ni l’autre, lisez juste avant l’envoi, comparez l’état normalisé à la valeur `before` approuvée et arrêtez-vous au moindre écart.

## Les lectures et les écritures n’exigent pas le même niveau de contrainte

L’approbation par appel doit couvrir les utilisations sensibles de l’identifiant du bureau d’enregistrement, sans habituer les personnes à cliquer pour de simples lectures d’inventaire. Si chaque opération de liste interrompt un développeur, le mécanisme d’approbation devient un obstacle et les relecteurs cessent de lire. La bonne frontière suit l’effet et la divulgation.

Les recherches DNS publiques non authentifiées n’ont besoin d’aucun identifiant de bureau d’enregistrement. Les lectures authentifiées de l’inventaire des domaines, des données de contact privées, des codes de transfert, des données de facturation ou des opérations en attente demandent un traitement différent. Une lecture détaillée du domaine peut révéler des coordonnées personnelles. La récupération d’un code d’autorisation crée une capacité de transfert immédiate, même si un catalogue d’API la qualifie de lecture.

Utilisez une petite table de classification et gardez-la facile à comprendre :

La liste des domaines gérés et la lecture d’un état masqué peuvent généralement utiliser l’approbation de session, car elles révèlent un inventaire sans le modifier. La récupération d’un code d’autorisation de transfert demande une approbation par appel, car elle produit un secret qui peut permettre un transfert.

Le remplacement des serveurs de noms, la suppression du verrou de transfert, les changements de contact titulaire ou administratif, ainsi que chaque ajout, remplacement ou suppression de données DS demandent une approbation par appel, car chacun modifie le contrôle ou la validation. Le renouvellement dépend de la politique : il coûte de l’argent mais préserve normalement le contrôle. Une équipe peut donc le préautoriser dans une limite de dépense définie.

La dernière ligne n’est volontairement pas forcée dans la même réponse. Le renouvellement a des effets financiers et de cycle de vie, mais son risque diffère de la redirection ou du transfert d’un domaine. Les équipes peuvent préautoriser le renouvellement dans une limite de dépense tout en exigeant une personne pour chaque changement de délégation. C’est l’intérêt de nommer clairement les actions.

N’utilisez pas la seule méthode HTTP comme classificateur. Certaines API emploient un POST générique pour les lectures comme pour les écritures. N’utilisez pas non plus une vaste catégorie de fournisseur telle que `Write`. La référence d’autorisation Route 53 Domains distingue à juste titre le remplacement des serveurs de noms, la mise à jour de contact et la suppression du verrou de transfert comme permissions séparées, mais une couche d’approbation a toujours besoin du domaine réel et des différences de valeurs.

## Le relecteur a besoin de preuves, pas du texte de l’agent

Une explication générée par l’agent fournit du contexte, pas une preuve. L’approbation doit commencer par des faits recueillis indépendamment : le processus authentifié, le domaine exact, l’action normalisée, les valeurs avant et après, et les résultats des contrôles. Placez ensuite la raison donnée par l’agent.

Pour une demande de serveurs de noms, recueillez les vérifications SOA faisant autorité et les contrôles d’enregistrements essentiels de chaque serveur proposé. Pour une demande DS, recueillez les ensembles DS parent actuels et DNSKEY enfant. Pour une suppression de verrou, recueillez l’état actuel et tout transfert en attente. Pour un changement de contact, affichez les rôles modifiés et la conséquence de verrou indiquée par le bureau d’enregistrement. Le code qui recueille ces preuves doit se trouver du côté de confiance de la frontière, car un agent peut résumer par erreur une sortie périmée ou omettre une différence gênante.

L’approbation doit expirer. Une différence de serveurs de noms vieille de cinq heures peut ne plus décrire l’état actuel. L’expiration doit être assez courte pour limiter la dérive et assez longue pour qu’une personne puisse examiner les preuves. Évitez un nombre universel copié dans tous les flux : définissez-le selon le modèle de concurrence du bureau d’enregistrement et le temps de réponse de l’équipe, puis refusez la demande si l’état `before` change.

L’approbation groupée n’est sûre que si chaque élément est visible et homogène. Approuver la même migration de serveurs de noms pour vingt domaines inactifs peut être raisonnable si la carte liste chaque domaine et si les preuves réussissent pour chacun. Réunir un changement de serveurs de noms, une suppression de verrou et une mise à jour de contact sous un bouton « approuver la migration » efface les distinctions dont le relecteur a besoin.

Un refus d’approbation doit arrêter l’appel, sans inviter l’agent à reformuler et recommencer jusqu’à ce que quelqu’un clique sur oui. Enregistrez le refus avec le hachage de requête. Une demande substantiellement modifiée peut être soumise de nouveau, mais le système doit rendre la différence évidente.

## La vérification fait partie de l’action

Une réponse HTTP réussie signifie souvent que le bureau d’enregistrement a accepté une tâche, pas que le registre et le DNS exposent maintenant l’état voulu. Plusieurs API de domaine renvoient un identifiant d’opération à interroger plus tard. Traitez l’envoi, l’achèvement chez le fournisseur et la vérification publique comme des états séparés dans le journal.

Une séquence de vérification compacte détecte la plupart des surprises après un changement sensible :

1. Enregistrez l’identifiant d’opération du fournisseur et interrogez son état documenté jusqu’à ce qu’il atteigne un état terminal.
2. Relisez l’état du bureau d’enregistrement et comparez-le à l’objet `after` approuvé.
3. Interrogez les données NS et DS côté parent par plus d’un chemin récursif, puis interrogez directement les serveurs faisant autorité.
4. Testez un petit ensemble de services dépendant de la zone, y compris le routage du courrier et les enregistrements de validation de certificats lorsqu’ils existent.
5. Ne clôturez le changement qu’après concordance des preuves, ou exécutez le chemin de récupération préparé.

C’est l’un des rares cas où les nouvelles tentatives doivent avoir des limites franches. Réessayer une lecture qui a expiré est normal. Réessayer une requête de modification d’état après une réponse inconnue peut créer des tâches qui se chevauchent ou basculer deux fois une valeur. Avant toute nouvelle tentative, interrogez avec le jeton d’idempotence ou lisez l’opération et l’état actuels du domaine. Si le fournisseur n’offre aucun mécanisme d’idempotence, faites remonter le résultat ambigu au lieu de deviner.

Le retour arrière varie aussi selon l’action. Restaurer les anciens serveurs de noms peut rétablir la délégation, mais les caches retardent la convergence. Réactiver un verrou de transfert peut refermer une exposition si aucun transfert n’a progressé. Restaurer un contact peut déclencher une autre confirmation ou un verrou. Restaurer un ancien DS peut échouer si la clé privée de signature correspondante n’est plus active. Le dossier de récupération doit nommer le retour arrière propre à l’action et ses prérequis avant l’approbation.

Une fenêtre de maintenance ne remplace pas la vérification. Les changements DNS se propagent dans les caches selon les TTL existants, et les opérations de bureau d’enregistrement peuvent être asynchrones. Continuez la surveillance jusqu’à ce que les anciens et nouveaux états se comportent comme le prévoit le plan de migration.

## Des identifiants séparés ne remplacent pas le consentement par appel

Le principe du moindre privilège reste important. Donnez à un agent accès uniquement au compte du bureau d’enregistrement, aux domaines et aux opérations dont il a besoin, et écartez l’accès à la facturation ou à un portefeuille sans rapport lorsque le fournisseur le permet. Des identifiants de courte durée et l’isolation des processus réduisent encore l’exposition.

Cependant, diviser un jeton étendu en quatre identifiants ne prouve pas l’intention. L’agent peut toujours mal utiliser l’identifiant des serveurs de noms dans son périmètre autorisé, et un processus compromis peut attendre que le bon jeton apparaisse. Des identifiants séparés réduisent le rayon d’impact maximal. Le consentement par appel décide si un impact précis doit se produire.

L’autorisation de session et l’approbation par appel résolvent des problèmes différents. L’autorisation de session répond à la question de savoir si ce processus d’agent peut agir via la passerelle pendant son exécution. L’approbation par appel interrompt les quelques opérations où une personne doit comparer l’intention aux effets exacts. Les lectures et les appels routiniers à faible impact peuvent continuer dans la session, tandis qu’une clé de bureau d’enregistrement marquée pour approbation s’arrête à chaque utilisation.

Sallyport met en œuvre cette séparation avec une porte de coffre-fort, une autorisation pour chaque nouveau processus d’agent et une option par clé qui exige une approbation à chaque utilisation tout en gardant le secret du bureau d’enregistrement hors de l’agent. Pour un identifiant de bureau d’enregistrement étendu, marquez la clé pour chaque appel et faites porter à la description de la requête l’action normalisée et la différence décrites ci-dessus.

N’apprenez pas à l’agent à conserver temporairement le jeton d’API afin de terminer un lot. Dès que le jeton entre dans le processus du modèle, l’approbation devient indicative, car les appels suivants peuvent contourner la porte. Le composant qui stocke l’identifiant doit exécuter lui-même la requête approuvée et ne renvoyer que le résultat.

## Le dossier d’audit doit reconstituer la décision

Une entrée d’audit qui dit `agent called registrar` ne peut pas régler un incident. Le dossier doit montrer ce que la personne a vu, ce qu’elle a approuvé, quels octets ont été envoyés, ce que le fournisseur a renvoyé et ce que la vérification a observé ensuite. Sinon, l’équipe peut prouver une activité sans prouver l’autorisation.

Pour chaque appel sensible, conservez l’identité du processus, l’identifiant de session, l’approbateur, l’heure de décision, l’action normalisée, le domaine, les objets avant et après, le hachage de requête, l’identifiant d’opération du fournisseur, l’état de réponse et le résultat de vérification. Protégez les valeurs de contact personnelles selon vos règles de traitement des données, mais gardez un condensat stable ou une copie chiffrée contrôlée afin que les enquêteurs puissent distinguer deux changements.

Conservez aussi les événements de refus et de révocation. Si un opérateur révoque une session d’agent après avoir vu une demande inattendue de suppression de verrou, cette séquence explique pourquoi les appels ultérieurs se sont arrêtés. Un journal en écriture seule, chaîné par hachage, rend la modification silencieuse détectable, tandis qu’un export ou une vérification indépendante évite de dépendre de la même interface que celle qui a exécuté l’action.

Sallyport enregistre les sessions d’agent et les appels individuels dans un journal d’audit unique, chiffré et chaîné par hachage. `sp audit verify` vérifie hors ligne la chaîne sur les données chiffrées sans clé du coffre-fort. Cette vérification prouve que la chaîne enregistrée n’a pas été modifiée, tandis que l’enveloppe d’action fournit le sens propre au domaine dont les enquêteurs ont besoin.

Le dossier d’approbation doit aussi survivre à l’abstraction du fournisseur. Stockez le nom d’opération du fournisseur à côté de l’action normalisée, jamais à sa place. Un enquêteur peut ainsi relier une étiquette portable telle que `dnssec.ds.remove` à l’appel d’API exact, sans obliger chaque relecteur à apprendre le vocabulaire de chaque fournisseur. Conservez les octets canoniques de la requête ou leur condensat cryptographique et indiquez la version de normalisation qui a produit l’action. Si le classificateur change plus tard, les enquêteurs peuvent reproduire la décision réellement vue par l’opérateur au lieu d’appliquer une nouvelle logique à d’anciens événements.

Testez ce dossier avant de lui faire confiance. Faites passer un changement inoffensif sur un domaine de préproduction par l’approbation, refusez une requête modifiée avec la même raison déclarée, révoquez la session de l’agent et vérifiez que le journal conserve les trois événements dans l’ordre. Simulez ensuite une expiration ambiguë chez le fournisseur et confirmez que le flux lit l’état au lieu de renvoyer aveuglément la demande. Une conception d’audit qui ne fonctionne que pour les appels réussis échouera pendant l’incident qu’elle devait expliquer.

Le premier changement utile consiste à arrêter d’appeler l’outil du bureau d’enregistrement « mettre à jour le domaine ». Donnez un nom propre au remplacement des serveurs de noms, à la suppression du verrou de transfert, à la modification de contact, à la récupération du code d’autorisation et à la modification DS. Placez ensuite le consentement humain sur l’appel qui porte chacun de ces effets. L’identifiant peut rester étendu parce que le fournisseur l’a conçu ainsi, mais la décision n’a plus besoin de l’être.