De nos jours, nombreuses sont les entreprises subissant des attaques informatiques ayant pour origine une mauvaise gestion de leurs secrets. En effet, le phénomène du “move to cloud” et le passage aux infrastructures dynamiques ont engendré une multiplication de ces secrets et de leur exposition.
Dans un souci de conformité avec les différentes normes de sécurité (ISO 27001, RGPD…), ces secrets nécessitent désormais un contrôle strict et des processus définis afin d’atteindre une gestion efficace, sécurisée et ainsi éviter la compromission des données des utilisateurs et/ou collaborateurs.
Afin de mieux comprendre ces problématiques et de savoir comment les résoudre, cet article détaillera l’approche utilisée par Devoteam pour accompagner ses clients vers une gestion efficace de leurs secrets. Nous évoquerons notamment les solutions de Vault et plus précisément celle développée par HashiCorp à travers plusieurs cas d’usage et parlerons également des solutions de KMS.
La gestion de secrets en entreprise
Avant même de parler de gestionnaire de secret, savez-vous quelles données peuvent être qualifiées de secrets ? Par définition, ce sont des informations qui permettent d’accéder à des données sensibles protégées et/ou qui nécessitent un contrôle d’accès. On peut citer par exemple : les clés de chiffrement, les clés API, les clés SSH, les certificats, les login/password, tokens…
S’agissant de données très sensibles, il est donc primordial d’implémenter une solution permettant la gestion de celles-ci afin de garantir les points suivants :
- Centraliser les clés et les secrets : si tous les secrets sont au même endroit, il est plus simple de contrôler leur accès et de réduire le secret sprawl. Ce phénomène désigne le fait de stocker un secret dans plusieurs endroits différents, de telle sorte qu’on ne sache plus qui a accès à celui-ci.
- Chiffrer les données au repos : l’accès au gestionnaire de secrets étant partagé, ceux-ci doivent être chiffrés afin d’éviter une fuite de données compromettant l’ensemble des secrets.
- Configurer des politiques d’accès : toutes les données sensibles étant stockées au même endroit, il est important de définir qui peut accéder à quel secret.
- Auditer les accès : chaque connexion et chaque récupération de secret doit apparaître dans les logs du gestionnaire de secrets. Ainsi, il est possible de voir si des données ont fuité en cas de compromission.
Malheureusement ce type de solutions n’est pas assez répandu dans les entreprises pour protéger leurs données sensibles. La plupart du temps, les secrets sont rangés dans des coffres forts individuels (type Keepass) ou pire encore, sont présents en clair dans certains fichiers ou dossiers partagés.
Ces mauvaises pratiques sont surtout dues au fait que les entreprises ne sont pas assez sensibilisées aux solutions qui existent sur le marché. Pour citer les plus connues : Azure Key Vault, Conjur Cyber Ark, AKeyless Vault et Hashicorp Vault. Étant la plus complète en termes de fonctionnalités, c’est la solution Vault de Hashicorp qui sera décrite par la suite.
Vault, la solution de gestion de secrets Hashicorp
Présentation générale
Vault, comme son nom l’indique, est un coffre-fort qui est “API driven” et qui intègre un système d’authentification universel ainsi que des secret engines compatibles avec la majorité des applications (base de données). Il existe sous 2 versions, Open Source et Entreprise qui inclut des options pour le déployer en clusters à grande échelle.
Vault propose de nombreuses fonctionnalités, notamment :
- Secure Secret Storage
- Policies
- Data Encryption (EaaS)
- Revocation
- Namespace
- High Availability
- Dynamic Secrets
- Human & Machine Authentication
- Leasing and Renewal
- Audit Device & Telemetry
- Disaster Recovery / Performance Réplication
Cas d’usage de Vault Hashicorp
- Secret Management
Ce cas d’usage vient répondre à plusieurs besoins : la centralisation, la sécurisation et le management des secrets statiques et dynamiques. Vault intègre un module appelé le secret engine qui se décline sous plusieurs formes. La plus basique est le KV (Key Value) qui va associer un secret statique, par exemple un mot de passe ou un token, avec un identifiant. - EaaS (Encryption as a Service)
Le but de ce cas d’usage est de déléguer les opérations cryptographiques de manière transparente pour les utilisateurs et les applications. Pour cela, Vault est en mesure de chiffrer les données sensibles en utilisant des algorithmes robustes, de garantir la bonne rotation des clés et de facilement déployer une autorité de certification (TLS/SSH, PKI). Pour rappel, la rotation des clés permet de réduire la quantité de données chiffrées par une clé pour éviter que trop de données soient compromises en cas de fuite de celle-ci. - Identity based access
Ce cas d’usage permet de déléguer l’authentification à Vault auprès d’une autorité de confiance. Vault est compatible avec beaucoup de services : Azure AD et Active Directory, AWS, GCP, Kubernetes, Github, LDAP, Alibaba Cloud…
L’avantage pour une entreprise est qu’elle n’a pas besoin de créer un compte pour chaque employé si elle possède déjà un annuaire LDAP ou un service d’authentification tiers.
Comparaison avec les autres services de gestion de secrets
Hashicorp Vault n’est évidemment pas le seul outil qui propose de gérer les secrets sur une infrastructure Cloud, il existe aussi les solutions Conjur de CyberArk, Azure Key Vault et AKeylessVault. Un des atouts principaux de Vault est qu’il peut s’installer chez n’importe quel Cloud Provider et même en multi-cloud de par sa nature agnostique (cloud-agnostic).
L’autre avantage est la gestion de secrets dynamiques qui permet de faciliter le workflow d’une demande d’identifiants par exemple, c’est ce que nous allons voir dans la mise en situation suivante avec la demande d’un compte utilisateur dans une base de données (les flèches noires représentent la création du compte et les flèches rouges la mise à jour du mot de passe) :
Pour un gestionnaire de secret statique (à gauche) il y a 6 étapes :
- L’utilisateur demande des identifiants pour accéder à la base de données auprès du DBA (DataBase Administrator)
- Le DBA crée un nouveau compte dans la base de données
- Le DBA range le mot de passe de l’utilisateur dans le gestionnaire de secret statique
- Le DBA indique à l’utilisateur que son compte est prêt
- L’utilisateur récupère son mot de passe
- Ayant récupéré ses identifiants, l’utilisateur peut donc se connecter à la base de données
Dans le cas où l’utilisateur souhaite changer son mot de passe dans la base de données, si celui-ci a fuité par exemple, il doit répéter ces 6 étapes (flèches rouges), ce qui rend le processus assez lourd.
Avec un gestionnaire de secret dynamique, il y a toujours 6 étapes mais le workflow n’est pas le même :
- L’utilisateur demande des identifiants pour accéder à la base de données auprès du DBA (DataBase Administrator)
- Le DBA configure le compte de l’utilisateur sur Vault
- Le DBA indique à l’utilisateur que son compte est prêt
- L’utilisateur récupère son mot de passe auprès de Vault
- Vault crée un compte dynamique sur la base de données et le renvoi à l’utilisateur
- Ayant récupéré ses identifiants, il se connecte à la base de données
Premier avantage, Vault communique directement avec la base de données, l’administrateur n’a donc plus besoin de se connecter à celle-ci quand la connexion a déjà été configurée. De plus, dans le cas où l’utilisateur souhaite changer de mot de passe (flèches rouges), il n’a plus besoin de passer par l’administrateur car pour chaque connexion il utilise de nouveaux identifiants. Au bout d’une certaine période définie par l’administrateur, Vault révoque le compte dynamique qu’il a créé auprès de la base de données.
En conclusion, une solution de gestion de secrets dynamiques est beaucoup plus pratique car elle allège le workflow de certaines tâches, augmente la productivité et réduit fortement l’impact d’une fuite d’identifiants. Ayant parcouru les avantages d’une solution de gestion des secrets dynamiques, il est indispensable de définir les KMS et de comparer les solutions disponibles sur le marché.
Key Management Service (KMS) & KMaaS
Le chiffrement des données est devenu monnaie courante, que ce soit : les bases de données, les données qui sont échangées sur internet via le protocole HTTPS ou encore les données en cours d’utilisation. Évidemment, le chiffrement est une excellente pratique mais plusieurs points viennent compliquer le processus : Comment générer les clés de chiffrement ? Comment les distribuer ? La confidentialité, l’authenticité et l’intégrité des clés sont-elles garanties ? Comment gérer la rotation des clés, et à quelle fréquence ?
Ces questions ont en partie été répondues dans la première partie mais elles nécessitent plus de précisions.
Description et architecture d’un KMS
Le KMS est un service qui permet de gérer les clés cryptographiques sur l’ensemble de leur cycle de vie, de la génération à la révocation puis la suppression.
Le chiffrement de données avec une clé stockée dans un KMS se déroule comme ceci :
Les données sont d’abord chiffrées en utilisant une DEK (Data Encryption Key), cette DEK est ensuite chiffrée par une KEK (Key Encryption Key) pour devenir une wrapped DEK. Enfin, la wrapped DEK est stockée avec les données chiffrées tandis que la KEK est rangée dans le KMS. Le processus est évidemment symétrique pour le déchiffrement :
Les KEK sont des bi-clés, c’est-à-dire qu’il y a une clé publique et une clé privée. Ce chiffrement d’enveloppe permet de ne jamais sortir les clés privées du KMS. Lors du chiffrement on utilise la clé publique de la KEK, qui n’est pas un secret, mais le déchiffrement de la DEK se fait à l’intérieur du KMS (Request for unwrapping DEK). Cette méthode de chiffrement et de gestion de clé fait partie du protocole KMIP (Key Management Interoperability Protocol) qui est une norme pour assurer la sécurité des données et des clés. Le stockage des clés privées dans le KMS est très important car ceux-ci sont couplés avec des HSM (Hardware Security Module) qui viennent ajouter une couche de sécurité physique sur le stockage des clés.
Un HSM est conçu pour s’occuper de la génération, du stockage des clés et des opérations de chiffrement/déchiffrement. Pour générer une clé sécurisée en cryptographie nous avons besoin d’une bonne entropie, avec des nombres “parfaitement” aléatoires, cette condition est satisfaite grâce aux HSM.
Le Key Management pour le Multi-cloud avec les KMaaS
La majorité des Cloud Providers propose une solution de KMS pour pouvoir administrer les clés de ses clients lors de l’utilisation de leurs services. Cependant, des entreprises font le choix d’installer leur environnement informatique chez plusieurs Cloud Providers, c’est ce qu’on appelle le multi-cloud. Il est aussi possible d’avoir une configuration hybride (Cloud + On-premise). Cela pose un problème au niveau de la gestion des clés car si on utilise le KMS de chaque CP, les communications inter-cloud deviennent compliquées à gérer.
Pour résoudre ce problème de gestion de clés, des solutions appelées KMaaS (Key Management as a Service) ont émergé. Leur fonctionnement est quasiment le même qu’un KMS classique, c’est-à-dire qu’elles utilisent le protocole KMIP pour gérer les clés et qu’elles sont couplées avec un HSM, mais elles sont agnostiques de tout Cloud Provider. Leur modèle de fonctionnement peut se résumer avec ce schéma :
Ainsi, dans ce genre d’architecture, si un Cloud Provider a besoin de chiffrer/déchiffrer des données, il communique avec le KMaaS pour le faire. À noter que l’on peut retrouver le nom de CKMS (Centralized Key Management System) à la place de KMaaS dans certains articles pour identifier ce type de solutions.
Les avantages de ces services, en plus du multi-cloud, sont la portabilité, la standardisation et la centralisation. Si l’entreprise change de Cloud Provider, la gestion des clés ne sera pas impactée et les applications qui s’interfacent avec le KMaaS auront un standard sur lequel se reposer.
KMS & Vault Benchmark
Voici un tableau comparatif des différentes solutions Vault et KMS du marché :
Que retenir de cet article ?
Afin de protéger les données sensibles et les secrets, une entreprise doit disposer d’une solution de gestion des clés et de secrets (KMS / Vault) bien configurée et qui répond à ces cas d’usages majeurs. La centralisation des clés et des secrets dans un coffre fort est la meilleure méthode pour assurer la confidentialité de ces données sensibles.
Cependant cette opération étant très délicate, elle nécessite de respecter plusieurs conditions de sécurité et de faire appel à un expert avant de se lancer dans un projet de centralisation / gestion de secrets / clés :
- Faire un inventaire des secrets existants, évaluer leur robustesse et leur criticité, faire la liste des utilisateurs qui peuvent y accéder et vérifier leur durée de vie.
- S’assurer que les différents services sont toujours disponibles : l’installation d’une sécurité supplémentaire ne doit pas entraver ce qui est déjà fonctionnel.
- Choisir une solution qui convient à ses cas d’usage et les réglementations : infrastructure multi-cloud, secrets dynamiques, disaster recovery, haute disponibilité, FIPS…
