Série Coders Conquer Security Infrastructure as Code : Stockage des mots de passe en clair

Lorsqu'il s'agit de déployer une infrastructure sécurisée en tant que code au sein de votre organisation, où en êtes-vous ? C'est peut-être un apprentissage progressif, mais maîtriser ces bases est une excellente occasion d'améliorer vos compétences, de vous démarquer auprès de vos pairs et de mieux protéger les données des utilisateurs finaux.

Avant d'aborder ce nouveau chapitre de notre série « Coders Conquer Security », je vous invite à participer à un défi ludique sur la vulnérabilité liée au stockage des données sensibles ; jouez dès maintenant et choisissez parmi Kubernetes, Terraform, Ansible, Docker ou CloudFormation :

Qu'en avez-vous pensé ? Si vos connaissances ont besoin d'être approfondies, poursuivez votre lecture :

La clé de la plupart des systèmes de sécurité informatique repose aujourd'hui sur les mots de passe. Même si d'autres méthodes de sécurité sont utilisées, comme l'authentification à deux facteurs ou la biométrie, la plupart des organisations continuent d'utiliser la sécurité par mot de passe comme élément de protection. Pour de nombreuses entreprises, les mots de passe sont la seule méthode utilisée.

Nous utilisons tellement les mots de passe que nous avons même des règles pour les créer. Cela est censé les rendre moins vulnérables aux attaques par force brute ou aux simples devinettes. Bien sûr, certaines personnes utilisent encore des mots de passe faibles, comme le montre un récent rapport de NordPass. Il est difficile de croire qu'en 2020, les gens utilisent encore « 12345 » ainsi qu'une multitude d'autres mots faciles à deviner comme « chocolat », « password » ou « Dieu » pour protéger leurs actifs les plus sensibles.

Il y aura toujours des personnes qui ne se soucient pas d'utiliser des mots de passe robustes, mais la plupart des organisations professionnelles imposent aux utilisateurs de créer leurs accès selon certaines règles. Nous connaissons tous désormais les exigences : les mots de passe doivent comporter au moins huit caractères, inclure des lettres majuscules et minuscules, ainsi qu'au moins un chiffre et un caractère spécial.

Le problème est que même si les utilisateurs respectent les règles pour créer les mots de passe les plus robustes, cela ne sert à rien s'ils sont stockés en texte clair. Le mot de passe « 12345 » est tout aussi vulnérable que « Nuts53!SpiKe&Dog12 » si un pirate informatique parvient à lire l'intégralité du fichier de mots de passe.

Pourquoi le stockage des mots de passe en texte clair est-il dangereux ?

Stocker des mots de passe en texte clair est risqué car cela expose à la fois le système et les utilisateurs. Évidemment, le fait qu'un pirate puisse trouver et lire chaque mot de passe utilisé pour accéder à un système serait un désastre. Il pourrait simplement trouver un utilisateur disposant d'identifiants d'administrateur et compromettre l'ensemble du système ou du site. Et comme il utiliserait des noms d'utilisateur et des mots de passe valides, la sécurité interne pourrait ne pas détecter l'intrusion, ou ne la remarquer qu'une fois les dégâts causés.

Faciliter le vol de mots de passe stockés en texte clair nuit également aux utilisateurs, car beaucoup réutilisent leurs mots de passe. Comme nous avons rendu la création de mots de passe complexe, beaucoup de gens finissent par réutiliser les mêmes sur plusieurs sites. Si un attaquant compromet un fichier de mots de passe, il tentera presque certainement d'accéder à d'autres systèmes en utilisant les mêmes identifiants, ce qui expose les utilisateurs à un risque élevé de crimes secondaires.

Il est relativement facile de stocker accidentellement des mots de passe en texte clair ou de ne pas réaliser que cela pourrait causer des problèmes majeurs à l'avenir. Par exemple, le code suivant est une méthode couramment utilisée pour stocker des mots de passe lors de la définition d'une ressource AWS à l'aide de modèles Terraform :

resource "aws_db_instance" "default" {
 engine                 = "mysql"
 allocated_storage      = 10
 instance_class         = "db.t2.micro"
 username               = "admin"
 password               = "s3.cr3t.admin.p2ss"
 db_subnet_group_name   = aws_db_subnet_group.default.name
 vpc_security_group_ids = [aws_security_group.default.id]
}

Dans cet exemple, le mot de passe utilisé pour gérer l'instance de base de données MySQL dans AWS est stocké en texte clair. Cela signifie que toute personne ayant accès au dépôt de code source pourrait le lire, voire le copier.

La protection des mots de passe varie selon le framework, mais des méthodes existent pour chaque plateforme. Par exemple, le mot de passe MySQL peut être stocké dans un espace sécurisé comme AWS Secrets Manager :

resource "aws_db_instance" "default" {
 engine            = "mysql"
 allocated_storage = 10
 instance_class    = "db.t2.micro"
 username          = "admin"
 password = "${data.aws_secretsmanager_secret_version.password.secret_string}"
 db_subnet_group_name   = aws_db_subnet_group.default.name
 vpc_security_group_ids = [aws_security_group.default.id]
}

Dans cet exemple, le modèle Terraform récupérera le mot de passe depuis le service AWS Secrets Manager et il ne sera jamais stocké en texte clair dans les fichiers de modèles.

Protéger les mots de passe en évitant le stockage en texte clair

Les mots de passe sont les clés de votre royaume et ne devraient jamais être stockés en texte clair. Même au sein d'une organisation, personne ne devrait avoir accès à un vaste dépôt de mots de passe non protégés, et cela ne devrait pas être un protocole métier accepté (il existe aujourd'hui de nombreux gestionnaires de mots de passe permettant le partage sécurisé et chiffré des identifiants - aucune excuse !). Il existe également le risque que des employés malveillants fouillent dans les fichiers pour obtenir des accès non autorisés.

Imaginez maintenant le double impact possible en cas d'attaque extérieure si une porte dérobée vers votre base de données est découverte via une simple faille par injection SQL, permettant d'accéder également au répertoire où sont stockés les mots de passe. Vous pensez que ce scénario est trop complexe pour se réaliser ? C'est pourtant exactement ce qui s'est produit lors de la violation de données chez Sony en 2011. Plus d'un million de mots de passe clients étaient stockés en clair, et le groupe de hackers Lulzsec y a accédé, ainsi qu'à bien d'autres données, grâce à une attaque par injection SQL classique.

Tous les mots de passe doivent être protégés par les mécanismes de défense offerts par le framework utilisé. Avec Terraform, les mots de passe ne doivent jamais être stockés dans des fichiers de modèles. Il est recommandé d'utiliser des solutions de stockage sécurisées comme AWS Secrets Manager ou Azure Key Vault, selon votre fournisseur d'infrastructure.

Imposer des mots de passe robustes aux utilisateurs est une bonne chose, mais vous devez également faire votre part en backend. Éviter le stockage en clair contribue grandement à protéger vos utilisateurs et vos systèmes. Le principal danger du stockage en clair réside dans le contrôle d'accès défaillant : n'importe qui peut les voir. Il est impératif, surtout dans un environnement IaC où davantage de personnes accèdent à des informations sensibles, qu'ils soient correctement hachés et réservés aux seuls utilisateurs autorisés.

Consultez les pages du blog de Secure Code Warrior pour en savoir plus sur cette vulnérabilité et découvrir comment protéger votre organisation et vos clients contre les ravages d'autres failles de sécurité. Vous pouvez également essayer un défi IaC sur la plateforme de formation Secure Code Warrior pour maintenir vos compétences en cybersécurité à jour.