Introduction à la gestion sécurisée des secrets avec les systèmes de contrôle de version

Si vous connaissez une chaîne exacte à rechercher, vous pouvez utiliser la fonctionnalité de recherche native de votre outil VCS pour vérifier si la valeur fournie est présente dans les validations. Par exemple, avecgit, une commande comme celle-ci peut rechercher un mot de passe spécifique:

Ceci recherchera la totalité de l’historique de votre projet pour la chaîne spécifiée.

Un certain nombre d'outils dédiés peuvent aider à révéler des secrets plus largement. Des outils tels quegitrob peuvent analyser chaque référentiel dans une organisation GitHub à la recherche de noms de fichiers correspondant à ceux d'une liste prédéfinie. Le projetgit-secrets peut analyser les référentiels localement à la recherche de secrets définis, en fonction de modèles dans les chemins de fichiers et le contenu. L'outiltruffleHog utilise une approche différente en recherchant dans les référentiels des chaînes à haute entropie qui représentent probablement des secrets générés utilisés par les applications. Pour combiner certaines de ces fonctionnalités en un seul outil,git-all-secrets colle ensemble ou réimplémente les outils ci-dessus dans une interface unifiée.

Si vous découvrez des fichiers ou des données qui n'auraient pas dû être validés, il est important de réagir de manière appropriée pour atténuer l'impact des données divulguées. Le bon plan d'action dépendra de l'étendue du partage du référentiel, de la nature du matériel exposé et du fait que vous souhaitiez effacer toute mention du contenu divulgué ou tout simplement l'invalider.

Si les informations d'identification sont validées dans votre référentiel de projet, la première étape consiste à modifier immédiatement le mot de passe ou le secret afin d'invalider la valeur précédente. Cette étape doit être terminée, que le référentiel soit partagé ou non, pour plusieurs raisons. Les exigences de collaboration peuvent changer au cours de la vie d'un projet, entraînant une exposition plus importante que prévu. Même si vous savez que vous ne partagerez jamais intentionnellement votre projet, des incidents de sécurité peuvent transmettre des données à des tiers inattendus. Il est donc préférable d’être proactif en modifiant les valeurs actuelles.

Même si vous devez alterner vos informations d'identification compromises dans tous les cas, vous souhaiterez peut-être également supprimer entièrement les informations d'identification ou le fichier qui ont été divulgués de votre historique VCS. Ceci est particulièrement important pour les données sensibles qui ne peuvent pas être modifiées, comme toutes les données utilisateur qui ont été validées par inadvertance. La suppression des données de vos référentiels implique la réécriture de l'historique VCS pour supprimer le fichier des validations précédentes. Cela peut être faitusing native git commands or with the help of some dedicated tools. Il est important de noter que même si vous supprimez tous les enregistrements des données du référentiel, toute personne ayant précédemment copié la base de code peut toujours avoir accès au matériel confidentiel. Gardez cela à l'esprit lors de l'évaluation de l'ampleur de l'impact.

Si vous pensez que des secrets ont été compromis, il est judicieux de consulter les données du journal associées à ces programmes ou services pour tenter de déterminer s’il ya eu un accès ou un comportement inhabituel. Cela peut prendre la forme d'activités inhabituelles ou de demandes émanant généralement d'adresses de votre réseau interne et provenant d'adresses non contrôlées. Cette enquête vous aidera à déterminer les prochaines étapes appropriées pour protéger votre infrastructure et vos données.

Le moyen le plus simple de conserver les fichiers contenant des données sensibles en dehors de votre référentiel consiste à exploiter dès le début la fonctionnalité d’ignorer de votre VCS. Les fichiers «ignorés» du VCS (comme.gitignore) définissent des modèles, des répertoires ou des fichiers qui doivent être exclus du référentiel. Ce sont une bonne première ligne de défense contre la divulgation accidentelle de données. Cette stratégie est utile car elle ne repose pas sur des outils externes, la liste des éléments exclus est automatiquement configurée pour les collaborateurs et facile à configurer.

Bien que la fonctionnalité d’ignorer de VCS soit utile en tant que référence, elle repose sur la mise à jour des définitions d’ignorer. Il est facile de valider des données sensibles accidentellement avant de mettre à jour ou d’implémenter le fichier ignore. Ignorer les modèles n'a qu'une granularité de niveau fichier. Vous devrez donc peut-être refactoriser certaines parties de votre projet si des secrets sont mélangés à du code ou à d'autres données à valider.

La plupart des implémentations modernes de VCS incluent un système appelé «crochets» permettant d’exécuter des scripts avant ou après certaines actions dans le référentiel. Cette fonctionnalité peut être utilisée pour exécuter un script afin de vérifier le contenu des modifications en attente concernant des éléments sensibles. L'outilgit-secrets mentionné précédemment a la capacité d'installer des hookspre-commit qui implémentent la vérification automatique du type de contenu qu'il évalue. Vous pouvez ajouter vos proprescustom scripts pour vérifier les modèles contre lesquels vous souhaitez vous protéger.

Les points d'ancrage de référentiels offrent un mécanisme beaucoup plus flexible pour rechercher et protéger contre l'ajout de données sensibles au moment de la validation. Cette flexibilité accrue se traduit par la création de scripts de tous les comportements que vous souhaitez implémenter, ce qui peut être un processus difficile en fonction du type de données que vous souhaitez vérifier. Il convient également de noter que les points d’accès ne sont pas partagés aussi facilement que les fichiers ignorés, car ils ne font pas partie du référentiel copié par d’autres développeurs. Chaque contributeur devra configurer les crochets sur sa propre machine, ce qui rend l'application plus difficile.

Bien que la portée soit plus localisée, une stratégie simple qui peut vous aider à être plus attentif à vos commits consiste à ajouter des éléments uniquement de manière explicite à la zone de transfert VCS. Bien que l'ajout de fichiers par caractère générique ou par expansion puisse gagner du temps, le fait d'intégrer intentionnellement chaque fichier à ajouter permet d'éviter des ajouts accidentels qui pourraient sinon être inclus. Un effet secondaire bénéfique est que cela vous permet généralement de créer des commits plus ciblés et cohérents, ce qui facilite de nombreux autres aspects du travail collaboratif.

Un certain nombre de logiciels différents simplifient le cryptage partiel du référentiel. La plupart fonctionnent sur les mêmes principes de base, mais chacun offre une implémentation unique qui peut offrir des avantages convaincants en fonction des besoins de votre projet.

Un projet appelégit-secret (à ne pas confondre avec l'outilgit-secrets mentionné précédemment) peut chiffrer le contenu des fichiers secrets avec les clés GPG de collaborateurs de confiance. En exploitant un réseau de confiance existant, les utilisateurs degit-secret peuvent gérer l'accès aux fichiers en spécifiant les utilisateurs qui devraient être en mesure de déchiffrer chaque élément. Si l'utilisateur a publié sa clé publique sur un serveur de clés, vous pouvez lui fournir un accès au contenu crypté sans jamais lui demander directement sa clé.

L'outilgit-crypt fonctionne de manière similaire àgit-secret en ce sens qu'il vous permet de crypter et de valider des parties de votre référentiel et de réguler l'accès à d'autres contributeurs en utilisant leurs clés GPG. Le projetgit-crypt peut également utiliser le chiffrement à clé symétrique si votre équipe n'utilise pas GPG ou si ce modèle de gestion est trop complexe pour votre cas d'utilisation. De plus,git-crypt chiffrera automatiquement au moment de la validation et déchiffrera lors du clone en utilisant le filtre et les attributs diffgit, ce qui simplifie la gestion.

LeBlackBox project est une autre solution qui s'appuie sur GPG pour chiffrer le contenu de manière collaborative. Contrairement aux outils précédents, BlackBox fonctionne avec de nombreux systèmes de contrôle de version différents, de sorte qu'il peut être utilisé dans différents projets. Conçu à l'origine comme un outil pour l'écosystème de Puppet, il a été repensé pour prendre en charge un système basé sur un plugin plus ouvert. BlackBox peut crypter et décrypter des fichiers individuels à volonté, mais fournit également un mécanisme permettant d'appeler un éditeur de texte de manière transparente, qui décrypte le fichier, ouvre un éditeur, puis le rechiffre lors de la sauvegarde.

En dehors des solutions générales ci-dessus, certaines solutions sont conçues pour fonctionner avec des types de référentiels spécifiques. Par exemple, à partir de la version 5.1, les projets Ruby on Rails peuvent inclure desencrypted secrets within the repository utilisant un système qui configure une clé principale en dehors du référentiel.

Le chiffrement et la validation de vos données secrètes dans votre référentiel peuvent vous aider à conserver vos informations d'identification à jour et synchronisées avec la façon dont le code les utilise. Cela peut éviter les écarts entre les modifications du format ou de l'étiquetage des données confidentielles et la manière dont le code les utilise ou les utilise. Des modifications peuvent être apportées à la base de code sans faire référence à une ressource externe.

De plus, garder vos secrets avec votre code peut simplifier considérablement le déploiement. Plutôt que d'extraire des informations de plusieurs emplacements pour obtenir un système entièrement fonctionnel, ces informations sont toutes regroupées dans une seule unité, certains composants nécessitant un déchiffrement. Cela peut être très utile si l’infrastructure n’est pas configurée pour prendre en charge un magasin secret externe ou si vous souhaitez réduire au minimum la quantité de coordination nécessaire au déploiement de votre projet.

L'avantage général d'utiliser un outil pour chiffrer des informations sensibles dans un référentiel est que le chiffrement est facile à mettre en œuvre sans infrastructure ni planification supplémentaires. Les utilisateurs peuvent passer du stockage des secrets sous forme de données en texte brut à un système sécurisé crypté en quelques minutes. Pour les projets avec un seul développeur ou une petite équipe statique, ces outils remplissent probablement toutes les exigences de gestion secrètes sans ajouter de complexité supplémentaire.

Comme pour toute solution, il existe des compromis pour ce style de gestion secrète.

Fondamentalement, les secrets sont des données de configuration, pas de code. Bien que le code déployé dans différents environnements soit probablement le même, la configuration peut varier considérablement. En conservant des secrets avec le code dans votre référentiel, il devient plus difficile de maintenir la configuration dans différents environnements et encourage la réutilisation des informations d'identification de manière à nuire à la sécurité.

De même, il est souvent difficile de configurer un accès granulaire à plusieurs niveaux à des secrets chiffrés dans un référentiel. Le niveau requis de contrôle d'accès est souvent beaucoup plus complexe que ce qui est facilement modélisé par les outils utilisés pour chiffrer les secrets dans VCS, en particulier pour les grandes équipes et les projets. Faire appel à des collaborateurs ou supprimer des contributeurs du projet implique le rechiffrement de tous les fichiers contenant des données sensibles dans le référentiel. Bien que ces utilitaires facilitent généralement la modification du chiffrement utilisé pour protéger les fichiers, les secrets de ces fichiers devraientalso être tournés dans ces circonstances, ce qui peut être un processus manuel difficile.

Un point important qui est souvent négligé est que les clés utilisées pour décrypter les données sont souvent stockées à côté du contenu crypté. Sur un ordinateur portable de développeur, les clés GPG capables de déchiffrer des données sensibles sont souvent présentes et utilisables sans autre saisie. Vous pouvez atténuer quelque peu ce problème en utilisant une phrase de passe GPG, mais cela est difficile à appliquer pour une grande équipe. Si l'ordinateur portable d'un membre de l'équipe est compromis, l'accès aux données les plus sensibles de votre projet peut être accessible comme s'il s'agissait d'un texte brut.

En général, il peut être difficile de protéger des secrets dans un référentiel sur une longue période. Des opérations simples telles que l'annulation de modifications de code peuvent réintroduire accidentellement un accès précédemment supprimé. Si une clé privée est exposée, les valeurs historiques peuvent être récupérées et déchiffrées à partir de l'historique du référentiel. Bien que l'historique VCS fournisse un journal des modifications de cryptage, il n'existe aucune méthode d'audit des accès secrets permettant de déterminer les accès inhabituels.

Chef encrypted data bags etchef-vault fournissent des fonctionnalités intégrées de gestion des secrets pour l'infrastructure gérée par Chef. Les sacs de données cryptés sont utilisés pour empêcher les valeurs sensibles d’apparaître dans l’historique des révisions ou d’autres machines utilisant des secrets partagés. Chef-vault permet à la place de chiffrer les secrets à l’aide de la clé publique de la machine cible, offrant ainsi une sécurité supplémentaire qui isole les capacités de déchiffrement des destinataires.

De même, le système de stockage clé-valeur dePuppet’s Hiera peut être utilisé avecHiera eyaml pour gérer les secrets de manière sécurisée pour des composants d'infrastructure spécifiques. Contrairement à certains autres systèmes, Hiera eyaml connaît la syntaxe et la structure de YAML, le format de sérialisation des données utilisé par Hiera, lui permettant de chiffrer uniquement les valeurs sensibles au lieu du fichier entier. Cela permet de travailler avec des fichiers contenant des données cryptées à l'aide d'outils normaux pour la plupart des tâches. Comme les moteurs sont enfichables, les équipes peuvent implémenter le cryptage GPG pour gérer facilement les accès.

Saltstack utilisePillars pour stocker les données désignées pour certaines machines. Pour protéger ces éléments, les utilisateurs peuvent chiffrer les valeurs YAML à l'aide de GPG, puis configurer lesGPG renderer pour permettre à Salt de déchiffrer les valeurs au moment de l'exécution. Comme Hiera eyaml, ce système implique de chiffrer uniquement les données sensibles plutôt que le fichier complet, permettant ainsi à l’édition normale de fichiers et aux outils de différenciation de fonctionner correctement.

Ansible inclutAnsible Vault, un système de cryptage et un outil de ligne de commande pour crypter les fichiers YAML sensibles dans une structure de playbook. Ansible peut ensuite déchiffrer de manière transparente les fichiers secrets au moment de l'exécution pour combiner les données secrètes et non secrètes nécessaires à l'exécution de tâches données. Le coffre Ansible crypte le fichier entier plutôt que les valeurs; l'édition nécessite donc un déchiffrement et les outils de diff ne peuvent pas afficher d'informations de changement précises. Cependant, à partir d'Ansible 2.3,single variables can be encrypted in variable files, donnant aux utilisateurs le choix de la manière dont ils souhaitent chiffrer les valeurs sensibles.

Ces solutions sont bien adaptées à certains des défis liés à la gestion des secrets dans des contextes de gestion de configuration. Ils sont capables d'orchestrer l'accès aux secrets en exploitant le système d'inventaire de l'infrastructure existante et les désignations de rôles qui définissent le type d'accès requis par chaque machine. Les mêmes mécanismes qui garantissent que chaque ordinateur obtient la configuration correcte peuvent garantir que les secrets ne sont livrés qu'aux hôtes qui en ont besoin.

L'utilisation d'outils natifs sur vos systèmes de gestion et de déploiement d'infrastructure existants minimise les coûts opérationnels liés à la mise en œuvre du cryptage. Il est plus facile de migrer des secrets vers le chiffrement à l’aide d’outils natifs de votre environnement et d’intégrer le déchiffrement au moment de l’exécution sans étapes supplémentaires. Si vous utilisez déjà un système de gestion de la configuration, l’utilisation de leurs mécanismes de gestion secrets sera probablement la première étape vers la protection de vos données sensibles.

L'intégration étroite signifie que les utilisateurs peuvent utiliser leurs systèmes existants pour gérer leurs secrets, mais cela signifie également que ces solutions sont verrouillées sur leurs outils de gestion de configuration respectifs. Utiliser la plupart de ces stratégies dans d'autres contextes serait difficile, voire impossible, ce qui signifie que vous ajoutez une dépendance aux outils de gestion de la configuration eux-mêmes. L'intégration étroite à une plate-forme unique peut également poser problème pour les systèmes externes nécessitant un accès aux données. Sans une API externe ou une commande appelable dans certains cas, les secrets peuvent être efficacement «piégés» sauf s'ils sont accessibles via le système de gestion de la configuration, ce qui peut être limitant.

De nombreux inconvénients du stockage de secrets chiffrés dans votre référentiel d'applications s'appliquent également au stockage de secrets avec votre système de gestion de la configuration. Au lieu d’avoir des ordinateurs portables avec vos référentiels d’applications comme vecteur de compromis, tout ordinateur portable avec le référentiel de gestion de la configuration sera également vulnérable. Fondamentalement, tout système contenant à la fois les valeurs chiffrées et la clé de déchiffrement sera vulnérable à ce type de compromission.

Une préoccupation connexe est que, si le système de gestion de la configuration est en mesure de garantir que les secrets ne sont accessibles qu'aux machines appropriées, la définition de contrôles d'accès à granularité fine pour limiter les membres de l'équipe est souvent plus difficile. Certains systèmes ne peuvent crypter qu’avec un mot de passe ou une clé unique, ce qui limite la possibilité de partitionner l’accès des membres de l’équipe aux secrets.

Les services de gestion des secrets dédiés tels queHashiCorp’s Vault offrent une grande flexibilité et des fonctionnalités puissantes pour protéger le matériel sensible sans sacrifier la convivialité. Vault protège les données au repos et en transit et est conçu pour utiliser différents «backends» afin d'exposer différentes fonctionnalités et de gérer les complexités du cryptage, du stockage et de l'authentification. Plusieurs fonctionnalités clés incluent la possibilité de configurer des secrets dynamiques (informations d'identification à court terme pour les services connectés, créées à la volée), le cryptage de données en tant que service (cryptage et stockage de données provenant de services externes et restitution du contenu décrypté à la demande d'un opérateur) partie autorisée) et la gestion secrète basée sur le contrat de location (fournissant un accès pour une durée donnée, après quoi l'accès est automatiquement révoqué). L’architecture enfichable de Vault signifie que les backends de stockage, les mécanismes d’authentification, etc. sont tous interchangeables en fonction de l'évolution des besoins de l'entreprise.

Le système de gestion des secretsKeywhizde Square est un autre service dédié utilisé pour assurer la sécurité générale des données sensibles. Comme Vault, Keywhiz expose des API que les clients et les utilisateurs peuvent utiliser pour stocker et accéder à des secrets. Keywhiz offre une fonctionnalité unique: la possibilité d’exposer des secrets à l’aide d’un système de fichiers FUSE, un système de fichiers virtuel que les clients peuvent monter pour accéder aux données sensibles sous forme de pseudo-fichiers. Ce mécanisme permet à de nombreux types de programmes d'accéder aux données dont ils ont besoin sans l'aide d'un agent ou d'un wrapper, et permet aux administrateurs de verrouiller l'accès à l'aide des autorisations de système de fichiers Unix normales.

PinterestKnox est un autre service de gestion des secrets. Il offre bon nombre des mêmes fonctionnalités que Vault et Keywhiz. Une fonctionnalité non trouvée dans les autres systèmes est la possibilité de faire pivoter les clés dans le temps en fournissant des états explicites pour les versions de clés. Une version clé peut être marquée comme principale pour indiquer qu'il s'agit du secret préféré actuel, active pour indiquer que la version peut encore être utilisée ou inactive pour la désactiver. Ce système permet aux administrateurs de passer des clés sur une flotte de machines au fil du temps sans interrompre les services.

Les services de gestion secrets dédiés présentent de nombreux avantages convaincants par rapport aux autres systèmes. Le déchargement de la complexité de la sécurisation et de la gestion des données sensibles sur un système autonome évite de devoir résoudre ces problèmes dans les référentiels de gestion des applications et de la configuration. Cette séparation des responsabilités simplifie le modèle de sécurité opérationnelle en centralisant le stockage secret et en régissant l'accès via des interfaces strictement contrôlées. En fournissant des interfaces génériques pour interagir avec le système, les utilisateurs autorisés ou les clients peuvent accéder à leurs secrets, quel que soit le système de gestion de la configuration ou le VCS utilisé.

D'un point de vue administratif, les systèmes de gestion secrets fournissent de nombreuses fonctionnalités uniques, non disponibles dans d'autres outils. La rotation facile des clés de chiffrement ainsi que des secrets sous-jacents qu'elles protègent est extrêmement utile pour les déploiements de grande envergure et les systèmes complexes nécessitant la coordination de nombreuses valeurs sensibles différentes. L'accès peut être réglementé et révoqué facilement sans déployer de code ni effectuer de modifications à l'échelle de la flotte. Des fonctionnalités telles que les secrets dynamiques permettent aux serveurs de gestion secrets d'accéder à des services externes tels que des bases de données pour créer des informations d'identification à l'utilisation à la demande. L'accès aux secrets à court terme basé sur un contrat de location fonctionne comme un mécanisme automatique permettant de limiter ou d'exclure les accès sans nécessiter de révocation explicite.

L’auditabilité est l’une des améliorations les plus importantes apportées par la gestion centralisée des secrets. Chacun des systèmes mentionnés ci-dessus conserve de nombreux dossiers indiquant quand des secrets sont ajoutés, demandés, consultés ou modifiés. Cela peut être utile pour détecter les anomalies et détecter les comportements suspects, mais également pour évaluer l'étendue de tout accès en cas de compromission. Avoir une vue globale des données sensibles de votre organisation, des règles définies pour contrôler l’accès et des informations sur chaque tentative de modification ou de récupération réussie et tentée, permet aux équipes de prendre des décisions éclairées en matière de sécurité des infrastructures.

Le principal inconvénient d'un système de gestion secrète centralisée réside dans les frais généraux supplémentaires qu'il nécessite, à la fois en termes d'infrastructure et de gestion.

L'installation d'un système centralisé nécessite beaucoup de planification, de test et de coordination avant d'être déployée dans un environnement de production. Une fois l’infrastructure opérationnelle, les clients doivent être mis à jour pour interroger les API du serveur de gestion secret ou un processus d’agent doit être configuré pour obtenir des secrets pour le compte des processus qui le nécessitent. Des règles doivent être établies pour déterminer les applications, l'infrastructure et les membres de l'équipe qui doivent avoir accès à chaque valeur protégée.

En raison de la valeur des données qu'il protège, le serveur de gestion secret devient l'un des environnements de sécurité les plus importants à gérer. Bien que la centralisation minimise la surface à protéger, elle fait du système lui-même une cible de choix pour les acteurs malveillants. Bien que de nombreuses solutions incluent des fonctionnalités telles que les modes de verrouillage, les redémarrages basés sur des clés et les journaux d'audit, l'accès non autorisé à une mémoire secrète active déchiffrée nécessiterait des mesures de correction importantes.

Au-delà du coût initial de la configuration et des éléments de sécurité, la fourniture de toutes les données sensibles à partir d'un seul service introduit un composant critique supplémentaire pour votre infrastructure. Étant donné que des secrets sont souvent nécessaires pour amorcer de nouvelles applications et pour les opérations de routine, les temps d'arrêt de la gestion des secrets peuvent provoquer des interruptions majeures qui ne peuvent pas être résolues tant que le service ne peut pas être restauré. La disponibilité est cruciale pour un système responsable de la coordination entre autant de composants différents.