Les codeurs conquièrent la sécurité Série "Infrastructure as Code" : Stockage des mots de passe en clair
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.
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é par mot de passe comme un élément de leur protection.
Matias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Réservez une démonstrationMatias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.
Matias est un chercheur et un développeur qui possède plus de 15 ans d'expérience pratique dans le domaine de la sécurité des logiciels. Il a développé des solutions pour des entreprises telles que Fortify Software et sa propre entreprise Sensei Security. Au cours de sa carrière, Matias a dirigé de nombreux projets de recherche sur la sécurité des applications qui ont débouché sur des produits commerciaux et peut se targuer d'avoir déposé plus de 10 brevets. Lorsqu'il n'est pas à son bureau, Matias a été instructeur pour des formations avancées en matière de sécurité des applications ( courses ) et intervient régulièrement lors de conférences mondiales telles que RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec et BruCon.
Matias est titulaire d'un doctorat en ingénierie informatique de l'Université de Gand, où il a étudié la sécurité des applications par le biais de l'obscurcissement des programmes afin de dissimuler le fonctionnement interne d'une application.
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.
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.
Cliquez sur le lien ci-dessous et téléchargez le PDF de cette ressource.
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Voir le rapportRéservez une démonstrationMatias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.
Matias est un chercheur et un développeur qui possède plus de 15 ans d'expérience pratique dans le domaine de la sécurité des logiciels. Il a développé des solutions pour des entreprises telles que Fortify Software et sa propre entreprise Sensei Security. Au cours de sa carrière, Matias a dirigé de nombreux projets de recherche sur la sécurité des applications qui ont débouché sur des produits commerciaux et peut se targuer d'avoir déposé plus de 10 brevets. Lorsqu'il n'est pas à son bureau, Matias a été instructeur pour des formations avancées en matière de sécurité des applications ( courses ) et intervient régulièrement lors de conférences mondiales telles que RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec et BruCon.
Matias est titulaire d'un doctorat en ingénierie informatique de l'Université de Gand, où il a étudié la sécurité des applications par le biais de l'obscurcissement des programmes afin de dissimuler le fonctionnement interne d'une application.
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.
Table des matières
Matias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Réservez une démonstrationTéléchargerRessources pour vous aider à démarrer
Évaluation comparative des compétences en matière de sécurité : Rationalisation de la conception sécurisée dans l'entreprise
Le mouvement "Secure-by-Design" (conception sécurisée) est l'avenir du développement de logiciels sécurisés. Découvrez les éléments clés que les entreprises doivent garder à l'esprit lorsqu'elles envisagent une initiative de conception sécurisée.
DigitalOcean réduit sa dette de sécurité avec Secure Code Warrior
L'utilisation par DigitalOcean de la formation Secure Code Warrior a considérablement réduit la dette de sécurité, permettant aux équipes de se concentrer davantage sur l'innovation et la productivité. L'amélioration de la sécurité a renforcé la qualité des produits et l'avantage concurrentiel de l'entreprise. À l'avenir, le score de confiance SCW les aidera à améliorer leurs pratiques de sécurité et à continuer à stimuler l'innovation.
Ressources pour vous aider à démarrer
Sécurité réactive contre sécurité préventive : La prévention est un meilleur remède
L'idée d'apporter une sécurité préventive aux codes et systèmes existants en même temps qu'aux applications plus récentes peut sembler décourageante, mais une approche "Secure-by-Design", mise en œuvre en améliorant les compétences des développeurs, permet d'appliquer les meilleures pratiques de sécurité à ces systèmes. C'est la meilleure chance qu'ont de nombreuses organisations d'améliorer leur sécurité.
Les avantages de l'évaluation des compétences des développeurs en matière de sécurité
L'importance croissante accordée au code sécurisé et aux principes de conception sécurisée exige que les développeurs soient formés à la cybersécurité dès le début du cycle de développement durable, et que des outils tels que le Trust Score de Secure Code Warriorles aident à mesurer et à améliorer leurs progrès.
Assurer le succès des initiatives de conception sécurisée de l'entreprise
Notre dernier document de recherche, Benchmarking Security Skills : Streamlining Secure-by-Design in the Enterprise est le résultat d'une analyse approfondie d'initiatives réelles de conception sécurisée au niveau de l'entreprise, et de l'élaboration d'approches de meilleures pratiques basées sur des conclusions fondées sur des données.
Plongée en profondeur : Naviguer dans la vulnérabilité critique de CUPS dans les systèmes GNU-Linux
Découvrez les derniers défis de sécurité auxquels sont confrontés les utilisateurs de Linux en explorant les récentes vulnérabilités de haute sévérité dans le système d'impression commun d'UNIX (CUPS). Apprenez comment ces problèmes peuvent conduire à une potentielle exécution de code à distance (RCE) et ce que vous pouvez faire pour protéger vos systèmes.