Guide de la gestion des secrets

Nous avons tous des secrets. Parfois, ce sont des plaisirs coupables que nous essayons de garder cachés, comme regarder de la téléréalité kitsch ou nous offrir un étrange plat réconfort. Nous nous inquiétons souvent :

« Comment protéger le secret ? »

« Que pourrait-il se passer si quelqu’un découvre le secret ? »

« Qui garde un secret ? »

« Que se passe-t-il si nous perdons un secret ? »

Chez Bazaarvoice, notre équipe de sécurité part des mêmes questions pour la gestion des secrets. Elle s’intéresse moins aux secrets sans importance, comme qui a laissé sa vaisselle dans l’évier du bureau ou qui a fini le lait. Elle se concentre plutôt sur les secrets utilisés dans les systèmes qui font fonctionner un large éventail de produits de l’organisation. En voici quelques-uns :

• Clés API et tokens

• Chaînes de connexion à des bases de données contenant des mots de passe

• Clés de chiffrement

• Mots de passe

Avec des centaines de systèmes et de composants qui dépendent de secrets chez Bazaarvoice, les recenser et répondre aux questions ci-dessus de manière rapide, cohérente et fiable peut devenir un défi en l’absence de normes directrices.

Cet article abordera la gestion des secrets et expliquera comment Bazaarvoice a mis en place un Secret Catalog à l’aide de logiciels open source. Il fournira des exemples réutilisables et des conseils utiles pour réduire les risques et améliorer la conformité de votre organisation. Plongeons-nous dedans !

Catalogue de secrets

Bazaarvoice est conforme à la norme ISO27001S'ouvre dans une nouvelle fenêtre et veille à ce que ses systèmes s'appuient sur des outils et des pratiques conformes aux standards du secteur pour stocker les secrets en toute sécurité. Pourtant, ils ne se trouvent pas toujours au même endroit et peuvent être stockés avec différents outils. Parfois, AWS Secret ManagerS'ouvre dans une nouvelle fenêtre est pertinent ; dans d'autres cas, AWS KMSS'ouvre dans une nouvelle fenêtre convient mieux à une solution donnée. Vous pouvez même avoir une stratégie multicloud, qui disperse encore davantage les secrets. C'est là qu'un catalogue de secrets s'avère extrêmement utile, en offrant une vue unifiée des secrets entre les outils et les fournisseurs.

Cela peut paraître un peu ennuyeux, et les informations recueillies ne sont le plus souvent pas nécessaires. Pourtant, en cas d'incident, disposer d'un catalogue secret devient une ressource inestimable pour réduire le temps dont vous avez besoin pour résoudre le problème.

Bazaarvoice a reconnu la valeur d'un catalogue de secrets et a décidé d'en mettre un en place. L'équipe Sécurité a convenu que chaque entrée du catalogue devait répondre aux critères suivants :

• Un nom unique

• Une bonne description de sa finalité

• Responsabilité clairement définie

• Où elles sont stockées

• Une liste des systèmes dépendants

• Références à la documentation permettant de remédier à tout incident associé, par exemple comment effectuer la rotation d’une clé API

Il est essentiel que la valeur du secretdoit rester à son emplacement d’origine, sécurisé, en dehors du Catalog, mais il est indispensable de savoir où le secret est stocké. Cela évite un point de défaillance unique et n’entrave aucun critère de réussite.

Savoir où sont stockés les secrets aide à repérer les mauvaises pratiques. Par exemple, conserver une clé SSH uniquement sur les ordinateurs portables des membres de l’équipe représenterait un risque important. Une personne peut quitter l’entreprise, gagner au loto ou même renverser un verre sur son ordinateur (nous connaissons tous quelqu’un !). Les espaces de stockage déjà définis dans le catalogue guident les équipes pour décider comment stocker un nouveau secret, en les orientant vers des outils sécurisés et approuvés, résistants à l’erreur humaine.

Il faut reconnaître que la première tentative de mise en œuvre du catalogue chez Bazaarvoice ne s'est pas tout à fait déroulée comme prévu. Les équipes ont commencé à respecter les critères, mais il est vite devenu évident que chaque équipe produisait des interprétations différentes, stockées à plusieurs endroits et dans plusieurs formats. La sécurité n'aurait pas de vue unifiée si plusieurs catalogues de secrets finissaient par exister. Les équipes auraient besoin d'un accompagnement supplémentaire et d'un standard concret pour réussir.

Nous avons déjà ce qu’il vous faut pour cela !

Bazaarvoice adore les catalogues. Après nos clients, ce sont peut-être nos choses préférées. Nous avons un catalogue de produits pour chacun de nos plus de dix mille clients, un catalogue de données et, surtout, un catalogue de services propulsé par BackstageS'ouvre dans une nouvelle fenêtre.

« BackstageS'ouvre dans une nouvelle fenêtre unifie tous vos outils d’infrastructure, services et documentations pour créer un environnement de développement fluide de bout en bout. »

Dès l’installation, il inclut des entités de base permettant une modélisation puissante de l’écosystème :

https://backstage.io/docs/features/software-catalog/system-model#ecosystem-modeling

Comme le montre le schéma ci-dessus, au cœur du modèle Backstage se trouvent les Systems, les Components et les Resources, les entités les plus pertinentes pour la gestion des secrets. Vous trouverez une description détaillée de chaque entité dans la documentation de modélisation de BackstageS'ouvre dans une nouvelle fenêtre. En bref, on peut les concevoir de la façon suivante :

• Système

  – Un ensemble d’entités de niveau inférieur, y compris des Components et des Resources, qui joue le rôle de couche d’abstraction.

• Composant

  – Un élément logiciel. Il peut éventuellement produire ou consommer des API.

• Ressource

  – L’infrastructure dont les Components ont besoin pour fonctionner.

Nouveaux types de ressources

Les ResourcesS'ouvre dans une nouvelle fenêtre sont l’une des entités Backstage utilisées pour représenter l’infrastructure. Elles conviennent parfaitement pour représenter des secrets, ce qui nous évite de développer en interne un logiciel sur mesure pour le même travail. Nous avons donc défini deux nouveaux Resource Types : secret et secret-store.

Conseil : Convenez à l’avance des Types autorisés afin d’éviter la prolifération de variantes telles que « database » et « db », qui peuvent nuire à la recherche et au filtrage.

Les équipes avaient déjà investi l’effort nécessaire pour modéliser l’écosystème Bazaarvoice ; ajouter le YAML requis pour définir les secrets et les secret stores a donc été trivial.

Exemple minimal de secret store :

apiVersion: backstage.io/v1alpha1
kind: Resource
metadata:
name: aws-secrets-manager
description: Resources of type 'secret' can depend on this Resource to indicate that it is stored in AWS Secrets Manager
spec:
type: secret-store
owner: team-x

Exemple minimal de secret :

apiVersion: backstage.io/v1alpha1
kind: Resource
metadata:
name: system-a-top-secret-key
description: An example key stored in AWS Secrets Manager
links:
- url:https://internal-dev-handbook/docs/how-to-rotate-secrets
title: Rotation guide
spec:
type: secret
owner: team-1
system: system-a
dependsOn:
- resource:aws-secrets-manager

Enfin, pour relier les éléments aux Systems, Components et Resources existants, il suffit d’ajouter une section dependsOn à leurs définitions. Par exemple :

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
name: system-a-component
...
spec:
...
dependsOn:
- resource:system-a-top-secret-key

Quel en est le rendu ?

À nos yeux, c'est fantastique ! Décortiquons l'image ci-dessus.

La section « About » explique le secret, notamment le système auquel il est associé, son propriétaire et le fait qu’il est actuellement en production. Elle fournit aussi un lien vers le code source et un moyen de signaler des problèmes ou des erreurs, comme des fautes de frappe.

La section « Relations », reposant sur un autre pluginS'ouvre dans une nouvelle fenêtre, propose un graphe visuel et interactif qui affiche les relations associées au secret. Ce graphe aide les utilisateurs à se faire rapidement une représentation mentale des ressources dans le contexte de leurs systèmes, de leurs propriétaires et de leurs composants. La navigation dans ce graphe s’est révélée être un mécanisme efficace et efficient pour comprendre les relations associées au secret.

La section « Links » offre un emplacement cohérent pour référencer la documentation relative à la gestion des secrets.

Enfin, le pluginS'ouvre dans une nouvelle fenêtre « PagerDuty » s’intègre au système d’astreinte, ce qui élimine la nécessité d’identifier manuellement les contacts lors d’incidents d’urgence.

La valeur de Backstage tient à la puissance des plugins disponibles. La recherche et le filtrage facilitent la découverte, et l’API ouvre la voie à d’autres intégrations avec les systèmes internes.

Rester dans le coup

Maintenir une documentation exacte et à jour est toujours un défi. Regrouper le catalogue de services avec les bases de code associées permet d’éviter le risque qu’il devienne obsolète et est devenu un élément à prendre en compte pour examiner et approuver les modifications.

Nous n'en sommes qu'au début de notre démarche avec cette approche d'un catalogue de secrets et nous comptons partager nos améliorations progressives dans de prochains articles de blog au fil de notre avancement.

À propos de l'auteur

John McCloskey est Principal Software Engineer et vit à Belfast, en Irlande du Nord. Il dirige les équipes de développement responsables des plateformes Catalog et Actionable Insights de Bazaarvoice. Pendant son temps libre, John McCloskey aime courir, faire de la randonnée et explorer de nouvelles destinations.