Une clé qui n'expire jamais est pratique exactement de la manière qui fait qu'on oublie facilement son existence. Elle est générée une fois, intégrée dans un fichier de configuration ou une variable d'environnement, puis elle continue simplement de fonctionner, indéfiniment, sans que personne ne se demande si elle le devrait. Des années plus tard, la personne qui l'a générée a peut-être quitté l'entreprise, le projet pour lequel elle a été créée a peut-être été abandonné, et la clé elle-même se trouve peut-être sur un serveur oublié, dans un dépôt ayant fuité ou dans une ancienne sauvegarde, toujours parfaitement valide, parce que rien dans le système ne lui a jamais demandé de prouver qu'elle était encore nécessaire.
C'est un problème de sécurité réel et sous-estimé, pas une hypothèse. Les clés fuient par des fichiers de configuration versionnés, par des journaux qui ont enregistré un en-tête de requête par accident, par d'anciennes sauvegardes qui survivent au projet auquel elles appartenaient. Une clé qui n'expire jamais signifie que chacune de ces sources de fuite reste dangereuse indéfiniment, sans moment naturel où l'exposition se referme d'elle-même. Une clé renouvelée ou réexaminée périodiquement limite au moins la durée pendant laquelle une fuite donnée reste exploitable, même si la fuite elle-même n'a jamais été détectée.
Nous ne pensons pas que la solution consiste à imposer des dates d'expiration qui cassent les intégrations sans préavis, ce qui remplace un problème par un autre, tout aussi frustrant : une clé qui cesse de fonctionner en pleine production à cause d'une politique de renouvellement que personne n'a clairement communiquée. La solution réside dans une visibilité et un contrôle qui font du renouvellement un choix délibéré et éclairé, plutôt qu'une chose qui n'arrive jamais ou qui arrive comme une surprise imprévue. Les en-têtes de quota présents dans chaque réponse, y compris le nombre d'emplacements IP d'une clé en cours d'utilisation, fournissent un signal continu indiquant si l'utilisation d'une clé correspond encore à ce pour quoi elle a été émise, ce qui est exactement le type d'information qui devrait déclencher un examen périodique du genre « cette clé doit-elle encore exister ? ».
L'habitude répandue dans le secteur de traiter une clé comme un identifiant permanent, installé une fois pour toutes, vient de la priorité donnée à la commodité de l'intégration initiale plutôt qu'à toute la durée de vie de cet identifiant. Il est réellement plus simple, le premier jour, de générer une clé qu'il ne faudra plus jamais toucher. Cette commodité est concentrée au début, et le coût, une vieille clé non surveillée et jamais renouvelée qui traîne quelque part comme un risque permanent, est reporté sur un futur incident auquel personne ne pense le premier jour.
Nous pensons que le comportement par défaut le plus sain consiste à traiter une clé moins comme une installation figée et davantage comme un identifiant entretenant une relation continue avec le compte : visible en temps réel à travers les requêtes qu'il effectue, réexaminable périodiquement et révocable sans drame lorsque le projet auquel il appartenait est réellement terminé. Rien de tout cela n'exige d'imposer une expiration à qui que ce soit. Cela exige de rendre suffisamment facile de voir ce que fait réellement une clé pour que laisser traîner indéfiniment une vieille clé cesse d'être la solution de facilité.