Où doivent vivre les identifiants de vos panneaux

Tout panneau de gestion hébergé pour l’automatisation de serveurs vous demande la même chose dans son assistant de configuration : l’adresse de votre hyperviseur, un jeton d’API, les identifiants root de votre panneau d’hébergement web. Puis il les stocke, parce qu’il en a besoin à chaque requête.

C’est une chose raisonnable à vouloir pour un logiciel, et une chose réellement inconfortable à avoir acceptée. Vous venez de donner à la base de données d’un tiers la capacité de supprimer toutes les machines que vous possédez. Ni par un bogue ni par malveillance : c’est le comportement normal, documenté et fonctionnel du produit.

Il vaut la peine d’être précis sur ce que les autres approches apportent vraiment, car « nous les chiffrons au repos » est la réponse que tout le monde donne, et elle ne veut presque rien dire à elle seule.

Chiffré au repos, déchiffré par qui

Si un SaaS stocke votre jeton d’hyperviseur chiffré, la clé doit se trouver quelque part où ce même SaaS peut l’atteindre, puisqu’il doit utiliser le jeton pour vous pendant que vous dormez. Le chiffrement au repos protège contre un disque volé et une sauvegarde qui fuit. Il ne protège pas contre ce qui vous inquiète réellement : la compromission de la plateforme elle-même.

Ce n’est pas un argument contre le chiffrement au repos. C’est un argument pour dire que la question « où est la clé » est la seule question, et qu’un plan de contrôle capable de déchiffrer est un plan de contrôle que l’on peut contraindre à déchiffrer.

L’autre approche, structurelle, est la troisième ligne : ne pas détenir le secret du tout. Ce qui semble facile à dire, jusqu’à ce que l’on regarde ce qu’il en coûte de l’organiser.

Gardez le secret là où se trouve la machine

La forme qui fonctionne : un petit agent tourne à l’intérieur du réseau du client, détient les identifiants localement, et se connecte vers l’extérieur à la plateforme. La plateforme envoie des instructions. L’agent détient les clés.

Cela inverse le rayon d’explosion. La compromission du plan de contrôle permet désormais d’émettre des commandes, ce qui est grave et sur quoi nous reviendrons, mais elle ne permet pas de repartir avec un fichier plein de jetons d’hyperviseur appartenant à tous les clients, car ce fichier n’existe pas.

Ce qui rend la chose réelle n’a rien de glorieux.

Le coffre, et ce contre quoi il protège honnêtement

Notre agent stocke les identifiants dans un fichier local chiffré avec XChaCha20-Poly1305. La clé n’est pas le fichier sur le disque : elle est dérivée par HKDF à partir d’un fichier de clé mélangé à l’identité propre de la machine, et les données authentifiées supplémentaires lient le message chiffré à la version du format et à l’identifiant de l’agent.

La conséquence pratique est celle pour laquelle il faut concevoir. Copiez le fichier de clé et le coffre sur une autre machine : il ne s’ouvre pas. Restaurez la sauvegarde du mois dernier du répertoire de données sur un autre hôte : il ne s’ouvre pas. Chaque mode de défaillance, mauvaise clé, autre agent, octets modifiés, produit la même erreur indiscernable, et c’est bien l’objectif.

Voici la partie qui devrait figurer dans la documentation de tout produit de ce type, et qui n’y est généralement pas. Cela ne protège pas contre un accès root sur l’hôte. C’est impossible, et ce n’est pas nécessaire : le client possède l’hôte et possède les identifiants. Ce contre quoi le coffre protège, c’est un fichier qui fuit, pas le propriétaire de la machine. Un fournisseur qui laisse entendre autre chose vous vend une impression.

Les identifiants ne touchent jamais la base de données de la plateforme

C’est la partie facile à rater tout en croyant l’avoir réussie, car le code a bonne allure dans les deux cas.

Quand quelqu’un saisit un jeton d’hyperviseur dans notre panneau, la ligne qui entre dans la table des commandes ne contient que des noms de champs. Les valeurs voyagent dans un message transitoire séparé, qui n’est pas stocké, et partent directement dans la livraison vers l’agent. Le répartiteur de commandes ne les journalise jamais et ne les conserve jamais.

Si vous évaluez un produit là-dessus, la question à poser n’est pas « stockez-vous des identifiants ». C’est « qu’y a-t-il dans votre journal d’audit, et qu’y a-t-il dans votre file d’attente ». Une file qui transporte le secret est une base de données qui transporte le secret, avec des étapes en plus.

Supprimer un secret est un autre problème que le stocker

Retirer une intégration dans le panneau doit aboutir à la disparition des identifiants sur une machine que vous ne contrôlez pas, ce qui est plus difficile qu’il n’y paraît.

L’implémentation évidente est une réconciliation : demander à l’agent ce qu’il détient, comparer à ce que la base dit qu’il devrait détenir, supprimer la différence. C’est plus court et c’est dangereux, car la soustraction échoue vers tout a disparu. Une lecture ratée, une liste tronquée, et vous avez produit l’instruction d’effacer toutes les intégrations qui fonctionnent sur cet hôte, et ces identifiants sont irrécupérables sans que le client les retape.

L’instruction ne vient donc que d’une connaissance positive : une ligne existe parce que quelqu’un a réellement supprimé une intégration. Une lecture ratée produit zéro ligne et donc zéro instruction, et le secret reste où il était, c’est-à-dire exactement dans l’état où vous étiez avant.

Elle est livrée deux fois : immédiatement par le bus d’événements, puis de nouveau à chaque poignée de main de session, pour l’agent qui était hors ligne, le message qui a été perdu, la passerelle qui a redémarré. Les deux chemins lisent la même table : il n’y a donc pas de seconde vérité ni de second ordonnancement.

Ce qu’un certificat d’agent volé peut et ne peut pas faire

Si l’agent s’authentifie avec un certificat client, la question honnête est de savoir ce qui se passe quand quelqu’un s’en empare. Être précis là-dessus est plus utile qu’une page sécurité.

Il peut usurper cet agent-là. Le port de session exige un TLS mutuel, et par-dessus la vérification TLS l’empreinte du certificat du pair est recherchée dans la table des agents, qui porte un index unique. Une empreinte désigne donc exactement un agent, et l’identité revendiquée dans la poignée de main lui est comparée. Un attaquant muni du certificat devient cet agent, et peut envoyer tout ce qu’un agent a le droit d’envoyer : événements d’état, résultats, télémétrie.

Il ne peut pas lire les données des autres clients. Tout est cantonné à l’organisation à laquelle l’agent appartient, résolue depuis le certificat et non depuis ce que le client dit de lui-même.

Il ne livre pas à lui seul les identifiants. Le certificat est l’identité utilisée pour parler à la plateforme. La clé du coffre est distincte, vit sur l’hôte, et est liée à l’identité machine de cet hôte. Qui possède les deux possède un accès root sur la machine, et à ce stade le certificat est le moindre des soucis.

Il cesse de fonctionner quand vous le décidez, en une minute environ. La révocation est un état en base, pas une CRL ni OCSP. Une nouvelle connexion est refusée immédiatement. Une connexion existante est revérifiée toutes les minutes : un attaquant déjà connecté ne dispose donc au plus que de ce délai. Si la vérification d’état échoue elle-même à répétition, la session est fermée après trois échecs consécutifs plutôt que maintenue ouverte indéfiniment, ce qui borne le pire cas à environ trois minutes.

Et l’agent fait le ménage derrière lui. À la révocation, il efface le coffre, la clé du coffre, son identité, son état de session et ses files, dans cet ordre, les identifiants d’abord. Chaque étape se fait au mieux et est journalisée séparément, car un demi-effacement vaut mieux qu’aucun effacement.

Les certificats sont aussi de courte durée, quatre-vingt-dix jours, renouvelés automatiquement à mi-parcours avec une vérification horaire. Ce n’est pas tant une défense contre le vol qu’une borne sur la durée pendant laquelle un vol que personne n’a remarqué reste utile.

Ce que cela ne règle pas

Trois choses, dites franchement, car un modèle de menace sans risque résiduel est une page de marketing.

Un plan de contrôle compromis peut toujours émettre des commandes. Il ne peut pas voler vos jetons, mais il peut dire à votre agent de supprimer une machine, et l’agent le fera. Déplacer les secrets déplace le rayon d’explosion ; il ne le supprime pas. Ce que vous récupérez, c’est que les dégâts sont bornés par ce que l’API sait exprimer et visibles dans une piste d’audit, au lieu d’un attaquant muni de vos identifiants qui fait ce qu’il veut directement contre votre hyperviseur à trois heures du matin.

Un accès root sur l’hôte de l’agent lit tout. Par conception. Si cet hôte est compromis, vous avez une machine compromise à l’intérieur de votre propre réseau, et elle détient vos identifiants d’hyperviseur parce que c’est là qu’ils doivent être.

La suppression dépend du retour de l’agent. Si un hôte ne se reconnecte jamais, l’instruction d’oublier ses identifiants reste ouverte. Cela se voit dans le panneau au lieu d’être silencieusement marqué comme fait, ce qui est le bon compromis, mais c’est une vraie limite et il vaut mieux la connaître avant de compter dessus.

Questions à poser à un fournisseur

Quoi que vous achetiez au bout du compte, ces cinq questions séparent les produits qui y ont réfléchi de ceux qui ont écrit un paragraphe :

1. 01Où se trouve physiquement la clé de déchiffrement ? Si la réponse est « dans notre plateforme », le chiffrement au repos protège contre le vol de disque et rien d’autre.
2. 02Qu’y a-t-il dans le journal d’audit et dans la file de travaux ? Les secrets fuient dans ces deux endroits bien plus souvent que dans la table dont quelqu’un a pris soin.
3. 03Qu’advient-il des identifiants quand je supprime une intégration, et puis-je vérifier que cela s’est réellement produit ?
4. 04Combien de temps prend la révocation d’un accès, et s’applique-t-elle aux sessions déjà ouvertes ?
5. 05Est-ce que quelque chose a besoin d’un port entrant ? Une règle de pare-feu qui laisse la plage d’adresses d’un fournisseur entrer dans l’interface de gestion de votre hyperviseur est une seconde version, plus discrète, du même problème.

C’est ainsi que nous l’avons construit chez Provibr : l’agent tourne sur le matériel du client, détient les identifiants localement, et ne se connecte que vers l’extérieur.