Un dépôt privé peut exposer une clé dans son historique ou ses journaux. Cette méthode aide une PME à stocker, limiter, renouveler et révoquer ses secrets.
Dresser l’inventaire des secrets
Commencez par chercher les catégories de secrets utilisées par l’application : mots de passe de base de données, jetons d’API, certificats, clés SSH, identifiants de registre et variables de paiement. Notez le service concerné, l’environnement, le propriétaire et la date de dernière rotation.
Un fichier .env local n’a pas le même rôle qu’un secret de production. Les deux peuvent avoir un nom proche et provoquer une erreur lors d’un déploiement. Séparez clairement les valeurs de développement, de préproduction et de production. Les données de test ne doivent pas donner accès à un système réel.
Garder les secrets hors du dépôt
Ajoutez les fichiers locaux au mécanisme d’exclusion du projet et vérifiez l’historique Git, car supprimer un fichier dans le dernier commit ne retire pas forcément sa valeur des commits précédents. Les scans automatiques peuvent détecter des motifs connus, mais ils ne remplacent pas une rotation lorsqu’une valeur a été exposée.
Les journaux de CI demandent la même attention. Une commande qui affiche une variable, un outil en mode verbeux ou une exception peut imprimer un secret. Masquez les valeurs dans les logs et limitez les artefacts conservés. Examinez aussi les captures de configuration et les fichiers générés avant de les rendre accessibles à toute l’équipe.
Donner au pipeline les droits nécessaires
Un job de test n’a généralement pas besoin de publier une image ou de modifier la production. Créez des identités différentes pour les tests, la construction, la publication et le déploiement. Accordez à chacune les permissions nécessaires à une étape précise et retirez les accès qui ne sont plus utilisés.
Les secrets doivent être injectés au moment où la commande en a besoin. Évitez de les écrire dans un fichier permanent ou de les transmettre à toutes les étapes du pipeline. Une étape compromise ne devrait pas pouvoir lire les identifiants d’une autre étape sans raison opérationnelle.
Ajoutez une séparation entre les branches et les environnements. Une branche de fonctionnalité peut lancer des tests avec des services limités, tandis qu’une publication vers la production demande une validation et une identité différente. Cette distinction réduit l’impact d’un script malveillant introduit dans une dépendance ou une modification de pipeline.
Prévoir rotation et révocation
Un secret doit avoir un propriétaire et une procédure de remplacement. Documentez la création, le déploiement de la nouvelle valeur, la vérification du service et la révocation de l’ancienne. Quand une application accepte deux valeurs pendant une courte période, vous pouvez faire la rotation sans interrompre toutes les requêtes.
Testez la révocation sur un environnement contrôlé. Une clé oubliée dans un worker, une tâche planifiée ou un outil local peut continuer à être utilisée après un changement apparent. Recherchez les consommateurs par nom, empreinte ou journal d’accès, selon ce que le fournisseur permet.
Réagir à une exposition
Si une clé apparaît dans un dépôt ou un log partagé, considérez-la comme compromise. Révoquez-la d’abord, examinez les accès effectués et créez une nouvelle valeur. Le nettoyage de l’historique peut être nécessaire pour limiter la diffusion, mais il ne rend pas l’ancien secret fiable.
Conservez les éléments utiles à l’analyse : heure de détection, emplacements concernés, systèmes accessibles et actions menées. Évitez de recopier la valeur dans le ticket d’incident. La documentation GitHub sur la protection des secrets décrit les mécanismes de détection et d’alerte disponibles sur cette plateforme.
Vérifier le pipeline avant chaque évolution
Relisez les permissions lorsqu’un nouveau job apparaît, contrôlez les logs sur un build de test et vérifiez que les artefacts ne contiennent aucune configuration sensible. Faites tourner un scan de secrets sur les branches et sur l’historique selon la capacité de l’outil. Les développeurs doivent savoir où demander un secret et comment signaler une exposition, sans l’envoyer dans un canal public.
Notre article sur le retour arrière d’un déploiement complète cette démarche en traitant la récupération d’une version précédente. Sky Vaults peut aussi vous aider à structurer un pipeline DevOps au Maroc en tenant compte de vos environnements et de vos responsabilités.
Sources : OWASP, Secrets Management Cheat Sheet, GitHub, Secret scanning.