Accueil / Sécurité et données

Secrets : ne jamais les faire transiter, ne jamais les afficher en clair

Un secret collé dans une conversation, même brièvement, reste ensuite présent dans les journaux et dans toute relecture automatique de l'historique, et une commande de configuration lancée pour un motif précis peut afficher un secret voisin en clair si son filtre est trop large.

Un secret collé dans une conversation ne disparaît jamais vraiment. Il reste dans les journaux du service qui a reçu le message, et toute relecture automatique de cet historique, la vôtre ou celle d'un outil tiers, peut le réafficher des mois plus tard. La règle la plus simple reste donc la première : un mot de passe, une clé d'API ou un jeton d'accès ne se colle jamais dans une conversation, même pour une question rapide ou une correction ponctuelle.

Le moindre privilège, avant tout le reste

Le moindre privilège est le principe qui consiste à ne donner à un outil, un agent ou une personne que l'accès minimum nécessaire à la tâche en cours, jamais un accès plus large par confort. Un agent chargé de renommer des fichiers dans un dossier n'a besoin d'aucun droit sur une base de données voisine, même si cette base est techniquement accessible depuis le même poste. Restreindre l'accès dès le départ coûte moins cher que de découvrir, après coup, tout ce qu'un accès trop large a permis de lire.

Le filtre trop large, un canal de fuite discret

Une commande qui liste des variables ou interroge une table de configuration pour un motif précis peut afficher, à côté de la valeur cherchée, tout ce qui se trouve juste à côté. Le risque ne vient pas de la commande elle même, il vient de la largeur de son filtre. L'exemple suivant crée ses propres données de démonstration, sans toucher à rien de réel sur votre poste :

echo "CLE_API=ax92kQ" > fixture.txt
echo "NOM_SERVEUR=serveur-principal" >> fixture.txt
grep NOM fixture.txt
grep -i "e" fixture.txt

La première commande, filtrée sur NOM, ne renvoie que la ligne attendue. La seconde, filtrée sur la seule lettre e, renvoie les deux lignes, y compris la clé. Rien dans l'intention n'a changé entre les deux commandes, seule la précision du filtre a changé le résultat affiché à l'écran.

Filtrer sur ce qui est attendu, jamais sur un motif générique

Avant de lancer une commande qui affiche une configuration, la question à se poser n'est pas ce que la commande fait, c'est ce qu'elle affiche réellement à l'écran. Filtrer sur les noms attendus, ou sur une longueur précise, réduit ce risque bien mieux qu'un filtre par une seule lettre ou un motif trop court. Ce réflexe vaut pour une commande locale comme pour une requête confiée à un agent : demandez lui de filtrer sur des noms précis, jamais sur un motif large qui ratisse tout un ensemble de colonnes ou de variables. La leçon suivante traite ce qui se passe quand un secret finit malgré tout par être écrit dans un dépôt suivi par un outil de version.