コーダーがセキュリティインフラを征服するコードシリーズ:パスワードのプレーンテキスト保存

Lorsqu'il s'agit de déployer une infrastructure sécurisée sous forme de code dans votre propre organisation, où en êtes-vous ? Il peut s'agir d'une courbe d'apprentissage, mais le fait d'apprendre les ficelles du métier vous permettra d'améliorer vos compétences, de vous démarquer de vos pairs et d' assurer la sécurité des données des utilisateurs finaux.

Avant de commencer ce nouveau chapitre de notre dernière série Coders Conquer Security, j'aimerais vous inviter à jouer à un défi gamifié de la vulnérabilité du stockage des données sensibles ; jouez maintenant et choisissez entre Kubernetes, Terraform, Ansible, Docker ou CloudFormation :

Comment cela s'est-il passé ? Si vos connaissances ont besoin d'être approfondies, lisez ce qui suit :

De nos jours, les mots de passe sont la clé de la plupart des sécurités informatiques. 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 utilisent toujours la sécurité basée sur les mots de passe comme un élément de leur protection. Pour de nombreuses entreprises, les mots de passe sont utilisés exclusivement.

Nous utilisons tellement les mots de passe que nous avons même des règles sur la manière de les créer. Cela est censé les rendre moins vulnérables aux attaques par force brute ou même aux devinettes. Bien entendu, certaines personnes continuent d'utiliser des mots de passe faibles, comme le montre un rapport récent de NordPass. Il est difficile de croire qu'en 2020, les gens utilisent encore 12345 ainsi qu'un tas d'autres mots devinables comme chocolat, mot de passe et 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 forts, mais la plupart des organisations professionnelles obligent les utilisateurs à rédiger leurs mots ou phrases d'accès d'une certaine manière. Nous connaissons tous les règles : les mots de passe doivent comporter au moins huit caractères et être composés de lettres majuscules et minuscules, avec au moins un chiffre et un caractère spécial.

Le problème, c'est que même si les utilisateurs respectent les règles relatives à la création des mots de passe les plus forts, cela ne sert à rien si tous les mots de passe sont stockés en clair. Le mot de passe 12345 est tout aussi mauvais que Nuts53!SpiKe&Dog12 si un pirate informatique est en mesure de lire l'intégralité du fichier de mots de passe.

Pourquoi est-il dangereux de stocker des mots de passe en clair ?

Le stockage des mots de passe en clair est une mauvaise chose car il met en danger à la fois le système et les utilisateurs. Il est évident qu'un pirate informatique capable de trouver et de lire chaque mot de passe utilisé pour accéder à un système serait un désastre. Il lui suffirait de trouver un utilisateur disposant d'identifiants d'administrateur pour compromettre l'ensemble du système ou du site. Et comme il utiliserait des noms d'utilisateur et des mots de passe appropriés, la sécurité interne pourrait ne pas détecter l'intrusion ou la détecter longtemps après que les dégâts ont été causés.

Faciliter le vol des mots de passe stockés en clair par les attaquants nuit également aux utilisateurs, car de nombreuses personnes réutilisent leurs mots de passe. Parce que nous avons rendu les mots de passe si difficiles à créer, beaucoup de gens réutilisent ceux dont ils se souviennent sur plusieurs sites. Si un pirate compromet un fichier de mots de passe, il essaiera presque certainement d'accéder à d'autres systèmes en utilisant le même nom et le même mot de passe, ce qui expose les utilisateurs à un risque élevé de délits secondaires.

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

ressource "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 la base de données MySQL dans AWS est stocké en clair. Cela signifie que toute personne ayant accès au dépôt de code source peut le lire, voire le copier.

La protection des mots de passe varie en fonction du cadre, mais il existe des méthodes de protection pour chaque plateforme. Par exemple, le mot de passe MySQL peut être stocké dans un espace de stockage 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 obtiendra le mot de passe du service AWS Secrets Manager et il ne sera jamais stocké en clair dans les fichiers du modèle.

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

Les mots de passe sont les clés de votre royaume et ne devraient jamais être stockés en clair. Même les personnes internes à une organisation ne devraient pas avoir accès à un grand dépôt non protégé de mots de passe, et cela ne devrait pas être un protocole d'entreprise accepté (il existe de nos jours de nombreux gestionnaires de mots de passe qui permettent le partage crypté des informations d'identification - pas d'excuses !) Il y a également le risque que des personnes internes malveillantes fouillent dans les fichiers et accèdent à des endroits où elles ne le devraient pas.

Et dans le cas d'une attaque extérieure, imaginez le double effet possible si une porte dérobée vers votre base de données est trouvée grâce à quelque chose d'aussi simple qu'une vulnérabilité d'injection SQL, et qu'ils accèdent également au répertoire où les mots de passe sont stockés. Vous pensez qu'il s'agit là d'un trop grand nombre d'étapes truffées d'erreurs pour que cela porte ses fruits ? Malheureusement, c'est exactement ce scénario qui s'est produit lors de la faille de Sony en 2011. Plus d'un million de mots de passe de clients étaient stockés en clair, et le groupe de pirates Lulzsec a accédé à ces mots de passe et à bien d'autres encore par le biais d'une banale attaque par injection SQL.

Tous les mots de passe doivent être protégés par les défenses disponibles dans le cadre d'appui. Pour Terraform, les mots de passe ne doivent jamais être stockés dans des fichiers modèles. Il est recommandé d'utiliser un stockage sécurisé comme AWS Secrets Manager ou Azure Key Vault, en fonction du fournisseur d'infrastructure.

Obliger les utilisateurs à créer des mots de passe sécurisés est une bonne idée, mais vous devez également faire votre part du travail en arrière-plan. Le fait de ne pas stocker les mots de passe en clair contribuera grandement à la protection de vos utilisateurs et de vos systèmes. Le principal danger du stockage des mots de passe en clair est la faiblesse du contrôle d'accès ; en fait, tout le monde peut les voir. Il est impératif (en particulier dans un environnement IaC où soudainement, davantage de personnes ont accès à des informations sensibles) que les mots de passe soient hachés de manière adéquate et que seules les personnes qui ont absolument besoin d'y accéder puissent le faire.

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