Plan pratique de gestion des secrets pour les applications auto-hébergées

Pourquoi la gestion des secrets est une exigence opérationnelle, et pas seulement une exigence de sécurité

Une application auto-hébergée fonctionne rarement avec un seul identifiant. Elle peut nécessiter un compte de base de données, un mot de passe SMTP, des jetons d’API de tiers, des webhooks, des éléments de signature et une ou plusieurs clés de chiffrement. Si ces valeurs ne sont pas gérées, les tâches courantes deviennent risquées : un déploiement est plus difficile à reproduire, le départ d’un collaborateur laisse des accès incertains et une exposition suspectée peut se transformer en interruption urgente.

Un processus utile de gestion des secrets rend le travail autorisé prévisible. L’équipe sait à quoi sert chaque secret, qui en est responsable, où il est fourni, quelle application en dépend et comment il peut être remplacé. Cela est cohérent avec l’accent mis par le NIST CSF 2.0 sur l’établissement, la communication et l’application des rôles, responsabilités et autorités en matière de cybersécurité.

Une infrastructure gérée peut réduire la charge opérationnelle liée à une application, mais elle ne règle pas la gouvernance des identifiants. Par exemple, Airbip déploie les applications de son catalogue sous forme de charges de travail Docker sur ses serveurs cloud et automatise le routage ainsi que les certificats TLS par l’intermédiaire de Traefik et Let’s Encrypt. Les clients doivent toujours décider qui peut créer, approuver, consulter et faire tourner les identifiants d’application qui relient ces charges de travail aux bases de données et aux services externes.

• Traitez chaque secret de production comme une dépendance opérationnelle dotée d’un responsable.
• Concevez les procédures de remplacement avant qu’un secret ne soit suspecté, ou confirmé, comme exposé de manière urgente.
• Lorsque cela est possible, séparez les responsabilités d’administration de l’infrastructure de l’approbation métier des comptes tiers sensibles.

Ce qui constitue un secret

Un secret est une information dont la divulgation pourrait permettre un accès non autorisé, une usurpation d’identité, un déchiffrement ou une action privilégiée. Une clé secrète, par exemple, est une clé cryptographique qui n’est pas publique ; sa confidentialité est fondamentale pour sa finalité.

Ne limitez pas le registre aux valeurs littéralement nommées PASSWORD. Une chaîne de connexion peut contenir un nom d’utilisateur et un mot de passe. Un export de configuration peut contenir un jeton d’intégration. Une clé privée, une valeur de signature de cookie, un secret client OAuth ou un code de récupération peut avoir davantage de conséquences qu’un mot de passe classique.

À l’inverse, la configuration ordinaire ne donne généralement pas accès à quoi que ce soit si elle est divulguée. Elle peut inclure l’URL publique d’une application, un réglage de fonctionnalité non sensible, une langue ou un niveau de journalisation. La classification doit se fonder sur ce que permet une divulgation, plutôt que sur le nom d’une variable d’environnement.

• Noms d’utilisateur et mots de passe de bases de données, y compris les identifiants intégrés dans les chaînes de connexion.
• Jetons d’API, secrets de webhook et secrets clients OAuth utilisés par les intégrations.
• Noms d’utilisateur et mots de passe SMTP utilisés pour envoyer les e-mails de l’application.
• Valeurs de signature de session, clés privées et autres clés de signature.
• Clés de chiffrement, éléments de chiffrement de clés et codes de récupération.
• Mots de passe administrateur et jetons d’accès pour les comptes de l’application, du serveur ou de services tiers.

Séparez les secrets de la configuration non sensible avant le déploiement

Avant le déploiement, créez deux listes : la configuration qui peut être conservée dans la documentation ordinaire du déploiement et les valeurs nécessitant un traitement restreint. Cette petite étape évite un mode de défaillance courant dans lequel un fichier .env pratique devient la source de vérité informelle pour tout, y compris les identifiants de production.

Pour les déploiements basés sur Docker, utilisez une méthode de fourniture des secrets distincte lorsque l’application le permet. Docker conseille d’utiliser des secrets plutôt que des variables d’environnement pour les valeurs sensibles dans les déploiements Compose. Les secrets Compose sont déclarés au niveau supérieur, puis explicitement accordés à des services individuels ; un service ne peut pas accéder à un secret déclaré à moins que sa propre définition n’inclue cet accès.

Les secrets Docker sont montés sous forme de fichiers plutôt que définis directement comme variables d’environnement, normalement sous /run/secrets. Cette approche peut restreindre le nombre de services qui reçoivent une valeur. Elle n’élimine pas la nécessité de sécuriser l’hôte, la configuration de déploiement ou les personnes disposant d’un accès administratif, et l’application doit pouvoir lire le secret sous la forme fournie.

Évitez de placer des identifiants de compilation dans les arguments de compilation Docker ou les variables d’environnement. Docker indique que ceux-ci peuvent persister dans l’image finale. Utilisez des montages de secrets de compilation ou des montages SSH pour les identifiants nécessaires uniquement pendant une compilation. Excluez également les fichiers .env du contexte de compilation avec .dockerignore lorsqu’ils peuvent contenir des secrets ; sans cela, ils peuvent être inclus dans une couche de l’image.

• Classez chaque valeur de déploiement avant de l’ajouter à un fichier Compose, une tâche CI ou un panneau d’administration.
• N’accordez un secret Docker Compose qu’au service qui en a besoin.
• Consultez la documentation de configuration de l’application afin de déterminer si elle accepte un secret depuis un fichier, une variable d’environnement ou un autre mécanisme.
• Examinez les Dockerfiles, les contextes de compilation et l’historique des images lorsque des identifiants de compilation ont déjà été utilisés.

Cartographiez tous les emplacements où un secret peut être exposé

Un secret n’est protégé qu’à hauteur de chacune de ses copies. Le fichier de déploiement n’est qu’un emplacement parmi d’autres à inspecter. Les artefacts de compilation, l’ordinateur portable d’un développeur, une demande d’assistance archivée ou une configuration exportée peuvent devenir discrètement des copies supplémentaires qui survivent à l’identifiant prévu.

Créez une carte d’exposition pour chaque secret de grande valeur. Consignez à la fois les emplacements intentionnels, tels qu’un magasin de secrets restreint, et les emplacements accidentels possibles, tels que l’historique du shell, les captures d’écran ou les rapports d’erreur. Cette carte est particulièrement précieuse lors d’une réponse à incident, car elle indique à l’équipe ce qui doit être examiné après une rotation.

Les journaux méritent une attention explicite. OWASP ASVS indique que les identifiants et les informations de paiement peuvent être interdits dans les journaux, tandis que les jetons de session peuvent nécessiter un hachage ou un masquage. Il préconise également un inventaire des fichiers et services vers lesquels les journaux sont stockés ou diffusés. Traitez les destinations de journaux, les outils de suivi des erreurs et les canaux d’assistance comme faisant partie de la frontière des secrets.

• Dépôts de code source, y compris les fichiers .env versionnés, les exemples et les anciens commits.
• Fichiers Compose, variables CI/CD, historique du shell et sortie de ligne de commande.
• Journaux de conteneurs, journaux de proxy inverse, rapports d’erreur applicatifs et services de journaux externes.
• Tickets d’assistance, messages de discussion, e-mails, captures d’écran et sorties de terminal copiées.
• Sauvegardes, exports de bases de données, exports de configuration et anciens instantanés de serveur.
• Ordinateurs des administrateurs, coffres de gestionnaires de mots de passe, sessions de navigateur et supports amovibles.

Choisissez un modèle de responsabilité avant d’accorder des accès

Les petites équipes regroupent souvent la responsabilité sous un seul compte administrateur. Cela peut être commode, mais rend l’approbation, la récupération et le départ des collaborateurs difficiles à gérer. Attribuez plutôt des rôles nommés pour chaque secret important, même si une personne occupe temporairement plusieurs rôles.

Un modèle pratique sépare le responsable de l’application, l’administrateur de l’infrastructure et le responsable du service tiers. Le responsable de l’application décide si une intégration est nécessaire et accepte son risque métier. L’administrateur de l’infrastructure fournit la configuration approuvée au service en cours d’exécution et maintient l’accès au déploiement. Le responsable du service tiers administre le compte externe qui a émis l’identifiant, tel qu’un fournisseur de messagerie ou une plateforme d’API.

Les recommandations du NIST soutiennent la définition de rôles et la restriction des comptes privilégiés à des personnes ou rôles définis. Lorsque cela est possible, les administrateurs devraient utiliser des comptes non privilégiés pour le travail courant et réserver l’accès privilégié aux tâches qui l’exigent.

• Responsable de l’application : approuve la finalité, l’utilisation des données et le besoin métier.
• Administrateur de l’infrastructure : déploie les valeurs approuvées et contrôle l’accès au niveau de la plateforme.
• Responsable du service tiers : gère le compte du fournisseur externe, la relation de facturation et l’émission des identifiants.
• Examinateur sécurité ou exploitation : confirme périodiquement les accès, l’expiration, l’état de rotation et la préparation à la récupération.

Stockez et fournissez les secrets de manière sûre

Choisissez le processus le plus léger qui limite de façon fiable la divulgation et permet la récupération. La meilleure option dépend de la taille de l’équipe, du nombre d’applications, du renouvellement des collaborateurs, des exigences de conformité et de la fréquence de changement des identifiants. Un système de gestion des secrets mature n’est pas automatiquement le bon premier choix si l’équipe ne peut pas l’exploiter de manière cohérente.

Un magasin de secrets chiffré avec un accès utilisateur individuel est généralement un choix solide lorsque plusieurs personnes ont besoin d’un accès contrôlé à un inventaire grandissant. Une configuration de déploiement restreinte est utile lorsque le mécanisme de déploiement peut limiter les personnes capables de lire ou de modifier une valeur. Un processus de saisie manuelle peut convenir à un petit nombre de changements rares, à condition qu’il consigne qui a saisi le secret, où il a été saisi et comment la valeur est récupérée.

Évitez de traiter un document partagé en clair, une discussion d’équipe sans restriction ou un dépôt comme le magasin principal des secrets de production. Évitez également de supposer qu’un secret Compose constitue un coffre-fort complet : Compose peut obtenir le contenu d’un secret depuis un fichier hôte ou, dans Docker Compose, depuis une variable d’environnement de l’hôte. Ces emplacements sources nécessitent leurs propres contrôles d’accès. Les secrets Compose fondés sur l’environnement ne sont pas pris en charge par docker stack deploy.

• Utilisez un magasin de secrets chiffré avec des comptes individuels lorsque plusieurs personnes ont besoin d’un accès ou que l’auditabilité est importante.
• Utilisez des paramètres de déploiement restreints lorsqu’un petit groupe administratif seulement doit fournir des valeurs aux charges de travail.
• N’utilisez un processus manuel documenté que pour des changements peu fréquents, avec des étapes claires d’approbation, de transfert sécurisé et de récupération.
• Conservez dans la documentation de déploiement une référence à l’identifiant du registre du secret, et non sa valeur réelle.

Appliquez le principe du moindre privilège aux bases de données, services de messagerie, API et intégrations

Le moindre privilège consiste à n’accorder aux utilisateurs et aux processus que les accès nécessaires à leurs tâches attribuées. Le NIST appelle également à examiner périodiquement les privilèges et à supprimer ou réattribuer les accès inutiles. Appliquez ce principe aux identifiants, et pas seulement aux utilisateurs humains.

Pour une base de données, préférez un compte spécifique à l’application plutôt qu’un compte administrateur partagé. Pour les e-mails, utilisez des identifiants prévus pour la fonction d’envoi de l’application plutôt que le mot de passe de la boîte mail d’une personne. Pour les API, sélectionnez les autorisations les plus restreintes disponibles et séparez les identifiants de développement, de test et de production. Pour les intégrations, déterminez si le jeton peut lire des données, écrire des données, supprimer des données, administrer des utilisateurs ou créer d’autres identifiants.

Un test utile consiste à évaluer le rayon d’impact : si cette valeur est exposée, que peut réellement faire un attaquant ? Un jeton à portée limitée, attaché à une seule application, est plus facile à révoquer et moins dommageable qu’un jeton largement privilégié réutilisé entre plusieurs systèmes.

• Créez des identifiants de base de données distincts pour chaque application et environnement lorsque le service le permet.
• Évitez d’utiliser un superutilisateur de base de données ou un identifiant administrateur étendu pour l’accès courant de l’application.
• Utilisez des jetons d’API distincts pour différentes applications ou intégrations au lieu de réutiliser un jeton général.
• Limitez les autorisations, les données accessibles et les capacités administratives au besoin réel de l’application.
• Examinez les identifiants après des changements de rôle, de fournisseur, d’intégration ou d’architecture.

Établissez une procédure de rotation qui évite les intégrations défaillantes

La rotation est un remplacement contrôlé, et pas seulement une réinitialisation de mot de passe. Un changement non planifié peut interrompre la connectivité à la base de données, l’envoi des e-mails, les webhooks ou une automatisation essentielle. La séquence la plus sûre consiste à préparer un remplacement, à mettre à jour le service consommateur, à le valider, à révoquer l’ancienne valeur et à documenter le résultat.

Commencez par une entrée d’inventaire indiquant si des identifiants parallèles sont possibles. Certains fournisseurs permettent à un nouveau jeton de coexister brièvement avec l’ancien ; cela facilite une bascule progressive. Lorsqu’aucun chevauchement n’est possible, planifiez une fenêtre de maintenance, définissez une voie de retour en arrière et assurez-vous que les responsables adéquats sont disponibles.

Après le changement, vérifiez la fonction réelle plutôt que de simplement confirmer que le service démarre. Testez une lecture et une écriture dans la base de données adaptées à l’application, envoyez un e-mail contrôlé, effectuez un appel d’API autorisé ou exécutez le flux de travail critique. Retirez ensuite l’ancien identifiant et recherchez les emplacements d’exposition connus si la rotation a suivi une fuite suspectée.

• 1. Inventaire : identifiez l’identifiant, son responsable, ses consommateurs, ses dépendances et ses emplacements d’exposition.
• 2. Remplacement : générez ou obtenez une nouvelle valeur au moyen du processus approuvé par le responsable du tiers.
• 3. Mise à jour : fournissez le remplacement uniquement à l’application ou au chemin de déploiement autorisé.
• 4. Validation : testez l’intégration ou la fonction précise qui dépend de l’identifiant.
• 5. Révocation : désactivez, supprimez ou invalidez autrement la valeur précédente dès que cela est possible en toute sécurité.
• 6. Documentation : consignez la date, l’opérateur, le résultat de validation, la prochaine date de révision et toute exception.