Résumé

  • La documentation actuelle d’ARIN dit qu’une clé API n’est plus identifiable, après sa création, que par son préfixe et sa date, alors qu’ARIN affirme pouvoir rattacher des actions à des clés précises.
  • La suggestion ACSP 2023.15, qui demande une description choisie par l’utilisateur, demeure ouverte depuis octobre 2023 malgré l’accord de principe d’ARIN.
  • Une description ne constitue ni une permission, ni une date d’expiration, ni une preuve de garde. Elle permet de confronter l’usage prévu à l’activité observée.
  • ARIN devrait conserver une fiche de finalité versionnée : identifiant non secret, principal émetteur, service observé, responsable de revue, historique des libellés et preuve de désactivation.

Un préfixe n’est pas un mode d’emploi

La scène paraît banale. Un administrateur ouvre le tableau des clés API dans ARIN Online. Le secret complet, affiché une seule fois lors de la création, n’est plus visible — c’est souhaitable. À sa place, la documentation promet un préfixe et une date de création. Ces deux éléments empêchent les lignes de se confondre. Ils ne racontent cependant rien du travail confié à chacune.

Cette pauvreté sémantique serait secondaire si la clé ne servait qu’à une commande étroite et éphémère. Le propre guide d’ARIN décrit le contraire. Une même clé peut être employée dans plusieurs interactions. Elle peut accompagner Reg-RWS, la modification de réseaux, DNSSEC, RPKI, le DNS inverse, des opérations IRR ou l’accès automatisé à des rapports. Elle n’expire pas d’elle-même ; elle reste valable jusqu’à sa désactivation.

Une clé portant seulement la marque « préfixe créé tel jour » est donc un pouvoir durable sans raison durable jointe. Le fichier de secrets peut posséder un nom plus parlant. Un dépôt de code peut mentionner le préfixe. Une demande de changement peut expliquer la mise en service. Mais ARIN Online, qui détient la relation décisive entre le jeton et l’autorité acceptée par le registre, ne documente publiquement aucune manière de porter cette intention dans sa propre liste.

Ce manque a été formulé précisément. Le 25 octobre 2023, la suggestion ACSP 2023.15 a demandé que l’utilisateur puisse décrire une clé. Son auteur distinguait déjà la commodité d’un libellé de la puissance de permissions fines ou de rôles de service nommés. La description aiderait à savoir à quelle fonction une clé était destinée ; une règle d’autorisation limiterait les actes réellement permis. Le 27 octobre, ARIN a reconnu l’utilité du champ pour les clients qui disposent de plusieurs clés, annoncé son inscription au calendrier de déploiement et maintenu la suggestion ouverte jusqu’à réalisation.

Près de trois ans plus tard, la page de la suggestion et l’index ACSP la présentent toujours comme ouverte. Le dossier public ne comporte pas de mise à jour ultérieure. Cette absence ne démontre pas qu’ARIN ne travaille pas en interne ni qu’aucune interface d’essai ne contient un champ supplémentaire. Elle établit une chose plus modeste et vérifiable : l’engagement public n’a pas reçu de disposition publique, et le guide actuel décrit toujours une ligne limitée au préfixe et à la date.

L’action est observable, l’intention ne l’est pas

ARIN a consacré un billet entier à la bonne gestion des clés en équipe. Le raisonnement est solide : partager la clé personnelle d’un administrateur transmet une autorité large et efface la distinction entre les personnes qui agissent. L’organisation recommande des clés uniques associées aux bons Role POCs. Elle précise qu’une clé hérite des permissions de l’utilisateur qui l’a créée et que des actions précises peuvent être retracées jusqu’à des clés précises.

Cette traçabilité répond à « quelle clé a fait quoi ? ». Elle ne répond pas à « cette action correspondait-elle à la mission confiée à la clé ? ».

Imaginons deux clés appartenant au même principal de service. L’une met à jour des ROA dans RPKI ; l’autre télécharge un rapport mensuel. Si le tableau ne montre que deux préfixes et deux dates, le réviseur doit chercher ailleurs la séparation des tâches. Si l’une des clés modifie soudain un objet IRR, le journal peut désigner le jeton. Sans finalité déclarée, il ne dit pas si l’opération était prévue, si le périmètre avait été élargi par une décision valide ou si un ancien outil a été réutilisé par commodité.

Une déclaration de finalité fournit le terme manquant de la comparaison. Elle n’est pas vraie par magie. « Rapport mensuel » peut être obsolète, mensonger ou trop vague. C’est justement pour cela qu’il faut la rapprocher d’une activité observée et conserver ses modifications. L’écart entre « prévu » et « constaté » est un signal de revue, non une preuve automatique de faute.

Le même raisonnement s’applique à l’inactivité. Une clé qui n’a pas servi depuis douze mois peut être abandonnée, réservée à une urgence ou liée à un traitement annuel. Le préfixe et la date ne permettent pas de choisir. Un libellé précis ouvre l’enquête ; il ne rend pas la décision. L’opérateur peut alors contacter le responsable, vérifier le système, tester la relève et documenter la désactivation.

La nuance protège aussi contre une fausse promesse de sécurité. Une zone de texte ne limite aucun appel. Elle n’attache pas la clé à une adresse IP, n’impose pas MFA, ne réduit pas les droits hérités d’un POC, ne fait pas expirer le secret et ne révèle pas qui l’a copié. ARIN a d’autres dossiers pour ces contrôles. La suggestion 2011.17 porte sur des restrictions par opération et par POC. La suggestion 2024.1 évoque MFA, durée de validité ou bornage réseau. La consultation 2024.3 a traité du passage du jeton dans un en-tête et de limites par plage IP. Ce sont des contraintes techniques.

Le champ de finalité est une pièce de preuve destinée à la gestion.

Les voisins du ticket ont avancé

L’environnement des clés ARIN a changé de façon tangible. Le 28 juillet 2026, le registre a livré l’envoi du jeton dans l’en-tête d’autorisation comme méthode préférée, au lieu de l’insérer dans l’URL. Il a également supprimé la restriction qui empêchait la création de comptes de service non humains. Les notes de version relient ces deux changements aux suggestions désormais closes. Le guide Reg-RWS indique aujourd’hui « API Key in Header (Recommended) », tout en conservant l’ancienne forme dans l’URL comme méthode prise en charge.

Ces décisions améliorent deux frontières réelles. L’en-tête réduit la circulation accidentelle d’un secret dans des URL, historiques ou journaux intermédiaires. Le compte non humain permet de nommer une identité d’automatisation durable sans la déguiser en salarié permanent. Mais aucune de ces réponses ne décrit l’objet d’une clé particulière.

Le principal de service répond à la question de l’identité authentifiée. Il ne sépare pas nécessairement deux clés émises pour deux traitements. Le canal d’en-tête répond à la question du transport du secret. Il ne qualifie pas le mandat. Le Role POC contribue à déterminer l’autorité du créateur. Il ne consigne pas l’application censée l’exercer.

Cette chronologie rend le ticket 2023.15 plus intéressant qu’une simple fonction en attente. ARIN a démontré qu’il savait fermer une suggestion par un changement précis et mettre à jour les guides correspondants. Une disposition équivalente pour les descriptions devrait rendre le résultat observable : emplacement du champ, visibilité après création, règles d’édition, export, recherche, historique et relation avec le journal d’activité.

Ajouter seulement une colonne de texte serait un début, mais pas une fin. Un libellé réinscriptible sans historique peut effacer le mandat initial après une réorganisation. Un libellé visible seulement au moment de la création disparaît au moment de la revue. Un libellé non exportable oblige une grande organisation à copier manuellement l’inventaire. Une description qui ne partage aucun identifiant stable avec les traces ne peut pas être confrontée aux opérations.

Le produit utile est une petite chaîne de conservation de l’intention.

La fiche de finalité d’une clé

ARIN pourrait traiter le libellé comme le premier élément d’une fiche de finalité versionnée. Cette fiche resterait dans l’espace authentifié. Elle n’exposerait ni le secret ni les noms internes qu’un client ne souhaite pas communiquer. Son objectif serait d’unir, autour d’un identifiant non sensible, la déclaration du client et les observations que le registre peut fournir.

La fiche devrait contenir au moins :

  1. le préfixe de la clé ou un identifiant stable non secret ;
  2. un libellé de finalité obligatoire pour les nouvelles clés, accompagné au besoin de catégories structurées — Reg-RWS, RPKI, IRR, DNSSEC, DNS inverse, rapports ;
  3. le principal humain ou de service qui a émis la clé et le contexte POC ou organisation dont proviennent ses droits ;
  4. la date de création, la dernière utilisation et la dernière classe de service ou d’action observée, lorsque cette restitution est sûre ;
  5. le rôle chargé de la prochaine revue et une échéance choisie par le client ;
  6. l’historique des changements de libellé, avec auteur et horodatage ;
  7. la désactivation, son motif et la confirmation qu’ARIN n’accepte plus le jeton ;
  8. un avertissement explicite : la description ne crée, ne retire et ne restreint aucun droit.

La fiche n’a pas à devenir un système de gestion de secrets. Le client peut conserver l’hôte, le dépôt, la procédure de relève et l’équipe d’astreinte dans son propre coffre. ARIN doit surtout fournir le pivot fiable : le même identifiant non secret dans l’inventaire et dans l’activité. Sans ce pivot, deux registres parallèles décrivent une même autorité sans pouvoir prouver leur correspondance.

La dernière utilisation n’est pas une condamnation automatique. Elle transforme une revue vague en question datée. La classe d’action ne révèle pas forcément chaque ressource touchée ; elle peut simplement distinguer lecture de rapport, écriture Reg-RWS, gestion RPKI ou objet IRR. Le client peut ainsi repérer une divergence sans publier sa topologie ni ses secrets.

L’historique évite une autre perte de preuve. Une clé créée pour une migration peut devenir une dépendance de production. Deux décisions sont alors possibles : émettre une nouvelle clé adaptée au rôle durable, ou approuver explicitement le changement de finalité. Dans les deux cas, remplacer silencieusement « migration » par « production » détruit la séquence. La version conserve ce que les responsables savaient et ont décidé à chaque étape.

Enfin, la désactivation doit être un résultat, pas seulement un bouton. La fiche devrait indiquer quand ARIN a cessé d’accepter le jeton et à quelle finalité cette fin correspond. Elle ne prouve pas que toutes les copies du secret ont été effacées, mais elle donne au client un événement vérifiable à rapprocher de la suppression dans le coffre, le code et les procédures.

Ce que le registre public devrait permettre de conclure

Si ARIN met en œuvre la suggestion, sa clôture pourrait préciser si le champ est requis pour les nouvelles clés, facultatif pour l’existant, modifiable, historisé, interrogeable et exportable. Elle pourrait nommer les rôles autorisés à le voir ou à le modifier, ainsi que l’identifiant commun aux vues d’activité. Ce niveau de détail ferait de la clôture une preuve de capacité, pas une simple étiquette d’état.

ARIN peut aussi décider que la finalité relève entièrement de l’inventaire du client. Cette frontière est défendable à deux conditions : fournir un identifiant immuable que le client peut stocker, et rendre l’activité exportable sous ce même identifiant. Le champ interne devient alors inutile parce que le raccord externe est fiable. Ce qui ne fonctionne pas est l’entre-deux : aucune finalité dans ARIN Online et aucun moyen robuste de joindre l’inventaire externe à l’usage accepté par le registre.

Les sources examinées ne comptent ni clés dormantes, ni incidents, ni désactivations différées. Elles ne disent pas combien d’organisations ont plusieurs clés. L’article ne transforme donc pas un mécanisme plausible en sinistre observé. Il constate que l’autorité peut être durable, que l’usage est attribuable et que la finalité documentée manque au tableau public. C’est assez pour demander une preuve mieux conçue.

Sources