Qu’est-ce qu’un secret ?
Dans le contexte de la sécurité des applications, un secret est toute information permettant de prouver que son détenteur est bien celui ou ce qu’il prétend être lors du processus d’authentification et d’autorisation. Si des acteurs malveillants accèdent à des secrets, ils obtiennent un accès non autorisé à vos systèmes, qu’ils peuvent exploiter à diverses fins, notamment pour dérober des secrets d’entreprise et des informations sur les clients, voire prendre vos données en otage contre rançon.
Un exemple classique est le nom d’utilisateur et le mot de passe qui permettent à une application d’accéder à sa base de données, mais un secret peut également être une clé d’API, un identifiant, un certificat ou une clé privée, entre autres types d’informations. Les secrets étant utilisés pour contrôler l’accès aux ressources d’une organisation, il est essentiel de les stocker et de les protéger de manière sécurisée afin de réduire le risque que l’organisation soit compromise.
Qu’est-ce que la gestion des secrets ?
La gestion des secrets est le processus qu’une organisation utilise pour :
- Identifier les données sensibles
- Classer les données
- Étiqueter les données
- Stocker les données en toute sécurité
- Distribuer les secrets
- Renouveler (remplacer) régulièrement les secrets
Lorsque les organisations passent d’une architecture monolithique à une architecture de microservices, le nombre de composants applicatifs et d’infrastructure indépendants, chacun disposant de ses propres identifiants, augmente, ce qui multiplie le nombre de secrets à gérer.
Méthodes de stockage des secrets
Examinons de plus près deux options permettant de stocker des secrets en toute sécurité :
Vault
L’approche par coffre-fort consiste à installer un outil tiers de gestion des secrets. La solution de coffre-fort chiffre chaque secret afin d’empêcher les utilisateurs non autorisés d’y accéder. Le coffre-fort expose une API qui permet aux utilisateurs d’accéder aux secrets conformément aux politiques établies. Lorsque les utilisateurs s’authentifient auprès de l’API, ils ne peuvent accéder qu’aux secrets pour lesquels ils disposent d’une autorisation.
Inconvénients :
- Vous devez gérer vous-même la solution et les identifiants
- Nécessite la mise en place d’une infrastructure dédiée, sans quoi il est difficile pour les équipes de travailler de manière autonome
Avantages :
- Outils bien connus dans le secteur (la plupart des développeurs savent les utiliser)
- S’intègre facilement aux autres outils fournis par l’éditeur de la solution de coffre-fort
- Certains coffres-forts sont disponibles gratuitement
Il existe de nombreux outils sur le marché permettant aux développeurs de stocker et de gérer des secrets chiffrés. Pour découvrir comment utiliser un outil centralisé et automatisé de gestion des secrets, consultez notre article de blog « Protection des clés privées SSL dans NGINX avec HashiCorp Vault ».
Fournisseurs de services cloud
Une autre approche consiste à faire appel à un fournisseur de services cloud pour gérer les secrets en tant que service. L’un des avantages est que l’outil de gestion des secrets s’intègre généralement étroitement à d’autres services cloud, tels que les bases de données gérées. Les services des fournisseurs cloud peuvent également proposer des fonctionnalités telles que la rotation automatique, bien que des recherches supplémentaires soient nécessaires pour déterminer si cette option entraîne une interruption de service.
Inconvénient :
- Généralement payant
Avantages :
- L’accès et l’interface utilisateur sont configurés et gérés par le fournisseur de services cloud.
- S’intègre parfaitement aux autres services du fournisseur de cloud
- Peut être géré à l’aide d’un outil d’infrastructure en tant que code
Où ne pas stocker de secrets
Les secrets doivent être gérés avec soin afin d’éviter toute perturbation de l’application lorsqu’ils sont déverrouillés et consultés. Une bonne pratique consiste à ne jamais enregistrer de secrets dans un système de gestion de versions. Leur stockage dans un tel système expose l’organisation à un risque de catastrophe si des secrets sont accidentellement consultés ou compromis lorsqu’une équipe ou une personne met à jour le code ou l’application. Par conséquent, si un secret est enregistré dans le système de gestion de versions, même brièvement, il doit être considéré comme compromis. Les données sensibles doivent être supprimées du dépôt et effacées de l’historique du système de gestion de versions.
