
Les codeurs conquièrent l'infrastructure de sécurité sous forme de séries de codes : stockage des mots de passe en clair
En ce qui concerne le déploiement d'une infrastructure sécurisée sous forme de code dans votre propre organisation, comment vous en sortez-vous ? Cela peut être un peu une courbe d'apprentissage, mais apprendre les ficelles du métier sera une excellente occasion d'améliorer vos compétences, de vous démarquer de vos pairs, et protégez davantage les données des utilisateurs finaux.
Avant de commencer ce prochain chapitre de notre dernière série Coders Conquer Security, j'aimerais vous inviter à relever un défi ludique sur la vulnérabilité du stockage de données sensibles ; jouez dès maintenant et choisissez parmi Kubernetes, Terraform, Ansible, Docker ou CloudFormation :
Comment c'était ? Si vos connaissances ont besoin d'être approfondies, lisez ce qui suit :
De nos jours, les mots de passe constituent la clé de la plupart des sécurités informatiques. Même si d'autres méthodes de sécurité sont utilisées, telles que l'authentification à deux facteurs ou la biométrie, la plupart des organisations utilisent toujours la sécurité par mot de passe comme élément de leur protection. Pour de nombreuses entreprises, les mots de passe sont utilisés exclusivement.
Nous utilisons tellement de mots de passe que nous avons même des règles sur la façon 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 utilisent encore des mots de passe faibles, comme en témoigne une récente rapport de NordPass. Il est difficile de croire qu'en 2020, les gens utilisent encore 12345 ainsi que tout un tas d'autres mots faciles à deviner comme chocolat, mot de passe et Dieu pour protéger leurs actifs les plus sensibles.
Il y aura toujours ceux qui n'aimeront pas utiliser des mots de passe complexes, mais la plupart des organisations professionnelles obligeront les utilisateurs à créer leurs mots d'accès ou leurs phrases d'une certaine manière. Nous connaissons tous les règles maintenant, les mots de passe devant comporter au moins huit caractères, composés de majuscules et de minuscules, avec au moins un chiffre et un caractère spécial requis.
Le problème, c'est que même si les utilisateurs respectent les règles relatives à la création des types de mots de passe les plus sûrs, il se peut qu'ils ne soient pas utiles s'ils sont tous stockés en texte brut. Le mot de passe 12345 est aussi mauvais que Nuts53 ! Spike&Dog12 si un pirate informatique est capable de lire l'intégralité du fichier de mot de passe.
Pourquoi est-il dangereux de stocker des mots de passe en clair ?
Le stockage des mots de passe en texte brut est une mauvaise chose car cela met en danger à la fois le système et les utilisateurs. De toute évidence, le fait qu'un pirate informatique soit capable de trouver et de lire chaque mot de passe utilisé pour accéder à un système serait une catastrophe. Ils pourraient simplement trouver un utilisateur possédant des informations d'identification d'administrateur et compromettre l'ensemble du système ou du site. Et comme ils utiliseraient des noms d'utilisateur et des mots de passe appropriés, la sécurité interne risque de ne pas détecter l'intrusion ou de la détecter longtemps après que les dommages aient été causés.
Le fait de permettre aux attaquants de voler facilement les mots de passe stockés en texte clair nuit également aux utilisateurs, car de nombreuses personnes réutilisent les mots de passe. Parce que nous avons rendu la création de mots de passe si difficile, de nombreuses personnes ont recours à la réutilisation de mots de passe dont elles peuvent se souvenir sur plusieurs sites. Si un attaquant compromet un fichier de mots de passe, il essaiera 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 crimes secondaires.
Il est relativement facile de stocker accidentellement des mots de passe en texte brut ou de ne pas se rendre compte que cela pourrait entraîner des problèmes majeurs à l'avenir. Par exemple, le code suivant est une méthode couramment 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 » « par défaut » {
moteur = « mysql »
stockage_alloué = 10
instance_class = « db.t2.micro »
nom d'utilisateur = « admin »
mot de passe = « 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 brut. Cela signifie que toute personne ayant accès au référentiel de code source peut le lire, voire le copier.
La protection des mots de passe varie en fonction du framework, mais des méthodes de protection existent pour chaque plateforme. Par exemple, le mot de passe MySQL peut être stocké dans un espace de stockage sécurisé comme AWS Secrets Manager :
ressource « aws_db_instance » « par défaut » {
moteur = « mysql »
stockage_alloué = 10
instance_class = « db.t2.micro »
nom d'utilisateur = « admin »
mot de passe = « $ {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 texte brut dans les fichiers modèles.
Protéger les mots de passe en évitant le stockage en texte brut
Les mots de passe sont les clés de votre royaume et ne doivent jamais être stockés en texte clair. Même les personnes internes d'une organisation ne devraient pas avoir accès à un vaste référentiel de mots de passe non protégé, et ce protocole commercial ne devrait pas non plus être accepté (il existe de nombreux gestionnaires de mots de passe qui autorisent le partage d'informations d'identification cryptées de nos jours, aucune excuse !). Il existe également le risque que des initiés malveillants espionnent des fichiers et y accèdent là où ils ne devraient pas.
Et en cas d'attaque extérieure, imaginez le double inconvénient qui pourrait survenir si une porte dérobée vers votre base de données est découverte grâce à une simple faille d'injection SQL, et si l'utilisateur accède au répertoire dans lequel les mots de passe sont également stockés. Vous pensez qu'il s'agit d'un trop grand nombre d'étapes truffées d'erreurs pour porter leurs fruits ? Malheureusement, ce scénario exact s'est produit en L'infraction commise par Sony en 2011. Plus d'un million de mots de passe clients ont été stockés en texte clair, et le groupe de hackers Lulzsec a accédé à ces mots de passe et à bien d'autres encore grâce à une attaque par injection SQL courante.
Tous les mots de passe doivent être protégés par toutes les défenses disponibles dans le cadre de support. 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, selon le fournisseur d'infrastructure.
Forcer les utilisateurs à créer des mots de passe sécurisés est une bonne idée, mais vous devez également faire votre part sur le backend. Garder les mots de passe hors du stockage en texte brut contribuera grandement à protéger vos utilisateurs et vos systèmes. Le principal danger du stockage des mots de passe en clair est le mauvais 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 de plus en plus de personnes ont accès à des informations sensibles) que celles-ci soient correctement hachées et que seules les personnes qui en ont absolument besoin y aient accès y soient autorisées.
Consultez le Secure Code Warrior des pages de blog pour en savoir plus sur cette vulnérabilité et sur la manière de protéger votre organisation et vos clients des ravages causés par d'autres failles de sécurité et vulnérabilités. Vous pouvez également essayez une démo IaC challenge au sein de la plateforme de formation Secure Code Warrior pour maintenir toutes vos compétences en cybersécurité à jour et à jour.


De nos jours, les mots de passe constituent la clé de la plupart des sécurités informatiques. Même si d'autres méthodes de sécurité sont utilisées, telles que l'authentification à deux facteurs ou la biométrie, la plupart des organisations utilisent toujours la sécurité par mot de passe comme élément de leur protection.
Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.

Secure Code Warrior Ihr Unternehmen dabei, den Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie für die Anwendungssicherheit verantwortlich sind, Entwickler, IT-Sicherheitsbeauftragter oder in einer anderen Funktion im Bereich Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchenMatias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Matias ist ein Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung im Bereich der Softwaresicherheit. Er hat Lösungen für Unternehmen wie Fortify Software und sein eigenes Unternehmen Sensei Security entwickelt. Im Laufe seiner Karriere hat Matias mehrere Forschungsprojekte zur Anwendungssicherheit geleitet, die zu kommerziellen Produkten geführt haben, und kann auf über 10 Patente verweisen. Wenn er nicht am Schreibtisch sitzt, ist Matias als Ausbilder für fortgeschrittene Anwendungssicherheitstrainings courses tätig und hält regelmäßig Vorträge auf globalen Konferenzen wie RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.
Matias hat einen Doktortitel in Computertechnik von der Universität Gent, wo er die Sicherheit von Anwendungen durch Programmverschleierung untersuchte, um die innere Funktionsweise einer Anwendung zu verbergen.


En ce qui concerne le déploiement d'une infrastructure sécurisée sous forme de code dans votre propre organisation, comment vous en sortez-vous ? Cela peut être un peu une courbe d'apprentissage, mais apprendre les ficelles du métier sera une excellente occasion d'améliorer vos compétences, de vous démarquer de vos pairs, et protégez davantage les données des utilisateurs finaux.
Avant de commencer ce prochain chapitre de notre dernière série Coders Conquer Security, j'aimerais vous inviter à relever un défi ludique sur la vulnérabilité du stockage de données sensibles ; jouez dès maintenant et choisissez parmi Kubernetes, Terraform, Ansible, Docker ou CloudFormation :
Comment c'était ? Si vos connaissances ont besoin d'être approfondies, lisez ce qui suit :
De nos jours, les mots de passe constituent la clé de la plupart des sécurités informatiques. Même si d'autres méthodes de sécurité sont utilisées, telles que l'authentification à deux facteurs ou la biométrie, la plupart des organisations utilisent toujours la sécurité par mot de passe comme élément de leur protection. Pour de nombreuses entreprises, les mots de passe sont utilisés exclusivement.
Nous utilisons tellement de mots de passe que nous avons même des règles sur la façon 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 utilisent encore des mots de passe faibles, comme en témoigne une récente rapport de NordPass. Il est difficile de croire qu'en 2020, les gens utilisent encore 12345 ainsi que tout un tas d'autres mots faciles à deviner comme chocolat, mot de passe et Dieu pour protéger leurs actifs les plus sensibles.
Il y aura toujours ceux qui n'aimeront pas utiliser des mots de passe complexes, mais la plupart des organisations professionnelles obligeront les utilisateurs à créer leurs mots d'accès ou leurs phrases d'une certaine manière. Nous connaissons tous les règles maintenant, les mots de passe devant comporter au moins huit caractères, composés de majuscules et de minuscules, avec au moins un chiffre et un caractère spécial requis.
Le problème, c'est que même si les utilisateurs respectent les règles relatives à la création des types de mots de passe les plus sûrs, il se peut qu'ils ne soient pas utiles s'ils sont tous stockés en texte brut. Le mot de passe 12345 est aussi mauvais que Nuts53 ! Spike&Dog12 si un pirate informatique est capable de lire l'intégralité du fichier de mot de passe.
Pourquoi est-il dangereux de stocker des mots de passe en clair ?
Le stockage des mots de passe en texte brut est une mauvaise chose car cela met en danger à la fois le système et les utilisateurs. De toute évidence, le fait qu'un pirate informatique soit capable de trouver et de lire chaque mot de passe utilisé pour accéder à un système serait une catastrophe. Ils pourraient simplement trouver un utilisateur possédant des informations d'identification d'administrateur et compromettre l'ensemble du système ou du site. Et comme ils utiliseraient des noms d'utilisateur et des mots de passe appropriés, la sécurité interne risque de ne pas détecter l'intrusion ou de la détecter longtemps après que les dommages aient été causés.
Le fait de permettre aux attaquants de voler facilement les mots de passe stockés en texte clair nuit également aux utilisateurs, car de nombreuses personnes réutilisent les mots de passe. Parce que nous avons rendu la création de mots de passe si difficile, de nombreuses personnes ont recours à la réutilisation de mots de passe dont elles peuvent se souvenir sur plusieurs sites. Si un attaquant compromet un fichier de mots de passe, il essaiera 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 crimes secondaires.
Il est relativement facile de stocker accidentellement des mots de passe en texte brut ou de ne pas se rendre compte que cela pourrait entraîner des problèmes majeurs à l'avenir. Par exemple, le code suivant est une méthode couramment 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 » « par défaut » {
moteur = « mysql »
stockage_alloué = 10
instance_class = « db.t2.micro »
nom d'utilisateur = « admin »
mot de passe = « 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 brut. Cela signifie que toute personne ayant accès au référentiel de code source peut le lire, voire le copier.
La protection des mots de passe varie en fonction du framework, mais des méthodes de protection existent pour chaque plateforme. Par exemple, le mot de passe MySQL peut être stocké dans un espace de stockage sécurisé comme AWS Secrets Manager :
ressource « aws_db_instance » « par défaut » {
moteur = « mysql »
stockage_alloué = 10
instance_class = « db.t2.micro »
nom d'utilisateur = « admin »
mot de passe = « $ {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 texte brut dans les fichiers modèles.
Protéger les mots de passe en évitant le stockage en texte brut
Les mots de passe sont les clés de votre royaume et ne doivent jamais être stockés en texte clair. Même les personnes internes d'une organisation ne devraient pas avoir accès à un vaste référentiel de mots de passe non protégé, et ce protocole commercial ne devrait pas non plus être accepté (il existe de nombreux gestionnaires de mots de passe qui autorisent le partage d'informations d'identification cryptées de nos jours, aucune excuse !). Il existe également le risque que des initiés malveillants espionnent des fichiers et y accèdent là où ils ne devraient pas.
Et en cas d'attaque extérieure, imaginez le double inconvénient qui pourrait survenir si une porte dérobée vers votre base de données est découverte grâce à une simple faille d'injection SQL, et si l'utilisateur accède au répertoire dans lequel les mots de passe sont également stockés. Vous pensez qu'il s'agit d'un trop grand nombre d'étapes truffées d'erreurs pour porter leurs fruits ? Malheureusement, ce scénario exact s'est produit en L'infraction commise par Sony en 2011. Plus d'un million de mots de passe clients ont été stockés en texte clair, et le groupe de hackers Lulzsec a accédé à ces mots de passe et à bien d'autres encore grâce à une attaque par injection SQL courante.
Tous les mots de passe doivent être protégés par toutes les défenses disponibles dans le cadre de support. 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, selon le fournisseur d'infrastructure.
Forcer les utilisateurs à créer des mots de passe sécurisés est une bonne idée, mais vous devez également faire votre part sur le backend. Garder les mots de passe hors du stockage en texte brut contribuera grandement à protéger vos utilisateurs et vos systèmes. Le principal danger du stockage des mots de passe en clair est le mauvais 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 de plus en plus de personnes ont accès à des informations sensibles) que celles-ci soient correctement hachées et que seules les personnes qui en ont absolument besoin y aient accès y soient autorisées.
Consultez le Secure Code Warrior des pages de blog pour en savoir plus sur cette vulnérabilité et sur la manière de protéger votre organisation et vos clients des ravages causés par d'autres failles de sécurité et vulnérabilités. Vous pouvez également essayez une démo IaC challenge au sein de la plateforme de formation Secure Code Warrior pour maintenir toutes vos compétences en cybersécurité à jour et à jour.

En ce qui concerne le déploiement d'une infrastructure sécurisée sous forme de code dans votre propre organisation, comment vous en sortez-vous ? Cela peut être un peu une courbe d'apprentissage, mais apprendre les ficelles du métier sera une excellente occasion d'améliorer vos compétences, de vous démarquer de vos pairs, et protégez davantage les données des utilisateurs finaux.
Avant de commencer ce prochain chapitre de notre dernière série Coders Conquer Security, j'aimerais vous inviter à relever un défi ludique sur la vulnérabilité du stockage de données sensibles ; jouez dès maintenant et choisissez parmi Kubernetes, Terraform, Ansible, Docker ou CloudFormation :
Comment c'était ? Si vos connaissances ont besoin d'être approfondies, lisez ce qui suit :
De nos jours, les mots de passe constituent la clé de la plupart des sécurités informatiques. Même si d'autres méthodes de sécurité sont utilisées, telles que l'authentification à deux facteurs ou la biométrie, la plupart des organisations utilisent toujours la sécurité par mot de passe comme élément de leur protection. Pour de nombreuses entreprises, les mots de passe sont utilisés exclusivement.
Nous utilisons tellement de mots de passe que nous avons même des règles sur la façon 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 utilisent encore des mots de passe faibles, comme en témoigne une récente rapport de NordPass. Il est difficile de croire qu'en 2020, les gens utilisent encore 12345 ainsi que tout un tas d'autres mots faciles à deviner comme chocolat, mot de passe et Dieu pour protéger leurs actifs les plus sensibles.
Il y aura toujours ceux qui n'aimeront pas utiliser des mots de passe complexes, mais la plupart des organisations professionnelles obligeront les utilisateurs à créer leurs mots d'accès ou leurs phrases d'une certaine manière. Nous connaissons tous les règles maintenant, les mots de passe devant comporter au moins huit caractères, composés de majuscules et de minuscules, avec au moins un chiffre et un caractère spécial requis.
Le problème, c'est que même si les utilisateurs respectent les règles relatives à la création des types de mots de passe les plus sûrs, il se peut qu'ils ne soient pas utiles s'ils sont tous stockés en texte brut. Le mot de passe 12345 est aussi mauvais que Nuts53 ! Spike&Dog12 si un pirate informatique est capable de lire l'intégralité du fichier de mot de passe.
Pourquoi est-il dangereux de stocker des mots de passe en clair ?
Le stockage des mots de passe en texte brut est une mauvaise chose car cela met en danger à la fois le système et les utilisateurs. De toute évidence, le fait qu'un pirate informatique soit capable de trouver et de lire chaque mot de passe utilisé pour accéder à un système serait une catastrophe. Ils pourraient simplement trouver un utilisateur possédant des informations d'identification d'administrateur et compromettre l'ensemble du système ou du site. Et comme ils utiliseraient des noms d'utilisateur et des mots de passe appropriés, la sécurité interne risque de ne pas détecter l'intrusion ou de la détecter longtemps après que les dommages aient été causés.
Le fait de permettre aux attaquants de voler facilement les mots de passe stockés en texte clair nuit également aux utilisateurs, car de nombreuses personnes réutilisent les mots de passe. Parce que nous avons rendu la création de mots de passe si difficile, de nombreuses personnes ont recours à la réutilisation de mots de passe dont elles peuvent se souvenir sur plusieurs sites. Si un attaquant compromet un fichier de mots de passe, il essaiera 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 crimes secondaires.
Il est relativement facile de stocker accidentellement des mots de passe en texte brut ou de ne pas se rendre compte que cela pourrait entraîner des problèmes majeurs à l'avenir. Par exemple, le code suivant est une méthode couramment 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 » « par défaut » {
moteur = « mysql »
stockage_alloué = 10
instance_class = « db.t2.micro »
nom d'utilisateur = « admin »
mot de passe = « 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 brut. Cela signifie que toute personne ayant accès au référentiel de code source peut le lire, voire le copier.
La protection des mots de passe varie en fonction du framework, mais des méthodes de protection existent pour chaque plateforme. Par exemple, le mot de passe MySQL peut être stocké dans un espace de stockage sécurisé comme AWS Secrets Manager :
ressource « aws_db_instance » « par défaut » {
moteur = « mysql »
stockage_alloué = 10
instance_class = « db.t2.micro »
nom d'utilisateur = « admin »
mot de passe = « $ {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 texte brut dans les fichiers modèles.
Protéger les mots de passe en évitant le stockage en texte brut
Les mots de passe sont les clés de votre royaume et ne doivent jamais être stockés en texte clair. Même les personnes internes d'une organisation ne devraient pas avoir accès à un vaste référentiel de mots de passe non protégé, et ce protocole commercial ne devrait pas non plus être accepté (il existe de nombreux gestionnaires de mots de passe qui autorisent le partage d'informations d'identification cryptées de nos jours, aucune excuse !). Il existe également le risque que des initiés malveillants espionnent des fichiers et y accèdent là où ils ne devraient pas.
Et en cas d'attaque extérieure, imaginez le double inconvénient qui pourrait survenir si une porte dérobée vers votre base de données est découverte grâce à une simple faille d'injection SQL, et si l'utilisateur accède au répertoire dans lequel les mots de passe sont également stockés. Vous pensez qu'il s'agit d'un trop grand nombre d'étapes truffées d'erreurs pour porter leurs fruits ? Malheureusement, ce scénario exact s'est produit en L'infraction commise par Sony en 2011. Plus d'un million de mots de passe clients ont été stockés en texte clair, et le groupe de hackers Lulzsec a accédé à ces mots de passe et à bien d'autres encore grâce à une attaque par injection SQL courante.
Tous les mots de passe doivent être protégés par toutes les défenses disponibles dans le cadre de support. 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, selon le fournisseur d'infrastructure.
Forcer les utilisateurs à créer des mots de passe sécurisés est une bonne idée, mais vous devez également faire votre part sur le backend. Garder les mots de passe hors du stockage en texte brut contribuera grandement à protéger vos utilisateurs et vos systèmes. Le principal danger du stockage des mots de passe en clair est le mauvais 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 de plus en plus de personnes ont accès à des informations sensibles) que celles-ci soient correctement hachées et que seules les personnes qui en ont absolument besoin y aient accès y soient autorisées.
Consultez le Secure Code Warrior des pages de blog pour en savoir plus sur cette vulnérabilité et sur la manière de protéger votre organisation et vos clients des ravages causés par d'autres failles de sécurité et vulnérabilités. Vous pouvez également essayez une démo IaC challenge au sein de la plateforme de formation Secure Code Warrior pour maintenir toutes vos compétences en cybersécurité à jour et à jour.

Klicken Sie auf den untenstehenden Link und laden Sie das PDF dieser Ressource herunter.
Secure Code Warrior Ihr Unternehmen dabei, den Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie für die Anwendungssicherheit verantwortlich sind, Entwickler, IT-Sicherheitsbeauftragter oder in einer anderen Funktion im Bereich Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht anzeigenDemo buchenMatias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Matias ist ein Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung im Bereich der Softwaresicherheit. Er hat Lösungen für Unternehmen wie Fortify Software und sein eigenes Unternehmen Sensei Security entwickelt. Im Laufe seiner Karriere hat Matias mehrere Forschungsprojekte zur Anwendungssicherheit geleitet, die zu kommerziellen Produkten geführt haben, und kann auf über 10 Patente verweisen. Wenn er nicht am Schreibtisch sitzt, ist Matias als Ausbilder für fortgeschrittene Anwendungssicherheitstrainings courses tätig und hält regelmäßig Vorträge auf globalen Konferenzen wie RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.
Matias hat einen Doktortitel in Computertechnik von der Universität Gent, wo er die Sicherheit von Anwendungen durch Programmverschleierung untersuchte, um die innere Funktionsweise einer Anwendung zu verbergen.
En ce qui concerne le déploiement d'une infrastructure sécurisée sous forme de code dans votre propre organisation, comment vous en sortez-vous ? Cela peut être un peu une courbe d'apprentissage, mais apprendre les ficelles du métier sera une excellente occasion d'améliorer vos compétences, de vous démarquer de vos pairs, et protégez davantage les données des utilisateurs finaux.
Avant de commencer ce prochain chapitre de notre dernière série Coders Conquer Security, j'aimerais vous inviter à relever un défi ludique sur la vulnérabilité du stockage de données sensibles ; jouez dès maintenant et choisissez parmi Kubernetes, Terraform, Ansible, Docker ou CloudFormation :
Comment c'était ? Si vos connaissances ont besoin d'être approfondies, lisez ce qui suit :
De nos jours, les mots de passe constituent la clé de la plupart des sécurités informatiques. Même si d'autres méthodes de sécurité sont utilisées, telles que l'authentification à deux facteurs ou la biométrie, la plupart des organisations utilisent toujours la sécurité par mot de passe comme élément de leur protection. Pour de nombreuses entreprises, les mots de passe sont utilisés exclusivement.
Nous utilisons tellement de mots de passe que nous avons même des règles sur la façon 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 utilisent encore des mots de passe faibles, comme en témoigne une récente rapport de NordPass. Il est difficile de croire qu'en 2020, les gens utilisent encore 12345 ainsi que tout un tas d'autres mots faciles à deviner comme chocolat, mot de passe et Dieu pour protéger leurs actifs les plus sensibles.
Il y aura toujours ceux qui n'aimeront pas utiliser des mots de passe complexes, mais la plupart des organisations professionnelles obligeront les utilisateurs à créer leurs mots d'accès ou leurs phrases d'une certaine manière. Nous connaissons tous les règles maintenant, les mots de passe devant comporter au moins huit caractères, composés de majuscules et de minuscules, avec au moins un chiffre et un caractère spécial requis.
Le problème, c'est que même si les utilisateurs respectent les règles relatives à la création des types de mots de passe les plus sûrs, il se peut qu'ils ne soient pas utiles s'ils sont tous stockés en texte brut. Le mot de passe 12345 est aussi mauvais que Nuts53 ! Spike&Dog12 si un pirate informatique est capable de lire l'intégralité du fichier de mot de passe.
Pourquoi est-il dangereux de stocker des mots de passe en clair ?
Le stockage des mots de passe en texte brut est une mauvaise chose car cela met en danger à la fois le système et les utilisateurs. De toute évidence, le fait qu'un pirate informatique soit capable de trouver et de lire chaque mot de passe utilisé pour accéder à un système serait une catastrophe. Ils pourraient simplement trouver un utilisateur possédant des informations d'identification d'administrateur et compromettre l'ensemble du système ou du site. Et comme ils utiliseraient des noms d'utilisateur et des mots de passe appropriés, la sécurité interne risque de ne pas détecter l'intrusion ou de la détecter longtemps après que les dommages aient été causés.
Le fait de permettre aux attaquants de voler facilement les mots de passe stockés en texte clair nuit également aux utilisateurs, car de nombreuses personnes réutilisent les mots de passe. Parce que nous avons rendu la création de mots de passe si difficile, de nombreuses personnes ont recours à la réutilisation de mots de passe dont elles peuvent se souvenir sur plusieurs sites. Si un attaquant compromet un fichier de mots de passe, il essaiera 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 crimes secondaires.
Il est relativement facile de stocker accidentellement des mots de passe en texte brut ou de ne pas se rendre compte que cela pourrait entraîner des problèmes majeurs à l'avenir. Par exemple, le code suivant est une méthode couramment 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 » « par défaut » {
moteur = « mysql »
stockage_alloué = 10
instance_class = « db.t2.micro »
nom d'utilisateur = « admin »
mot de passe = « 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 brut. Cela signifie que toute personne ayant accès au référentiel de code source peut le lire, voire le copier.
La protection des mots de passe varie en fonction du framework, mais des méthodes de protection existent pour chaque plateforme. Par exemple, le mot de passe MySQL peut être stocké dans un espace de stockage sécurisé comme AWS Secrets Manager :
ressource « aws_db_instance » « par défaut » {
moteur = « mysql »
stockage_alloué = 10
instance_class = « db.t2.micro »
nom d'utilisateur = « admin »
mot de passe = « $ {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 texte brut dans les fichiers modèles.
Protéger les mots de passe en évitant le stockage en texte brut
Les mots de passe sont les clés de votre royaume et ne doivent jamais être stockés en texte clair. Même les personnes internes d'une organisation ne devraient pas avoir accès à un vaste référentiel de mots de passe non protégé, et ce protocole commercial ne devrait pas non plus être accepté (il existe de nombreux gestionnaires de mots de passe qui autorisent le partage d'informations d'identification cryptées de nos jours, aucune excuse !). Il existe également le risque que des initiés malveillants espionnent des fichiers et y accèdent là où ils ne devraient pas.
Et en cas d'attaque extérieure, imaginez le double inconvénient qui pourrait survenir si une porte dérobée vers votre base de données est découverte grâce à une simple faille d'injection SQL, et si l'utilisateur accède au répertoire dans lequel les mots de passe sont également stockés. Vous pensez qu'il s'agit d'un trop grand nombre d'étapes truffées d'erreurs pour porter leurs fruits ? Malheureusement, ce scénario exact s'est produit en L'infraction commise par Sony en 2011. Plus d'un million de mots de passe clients ont été stockés en texte clair, et le groupe de hackers Lulzsec a accédé à ces mots de passe et à bien d'autres encore grâce à une attaque par injection SQL courante.
Tous les mots de passe doivent être protégés par toutes les défenses disponibles dans le cadre de support. 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, selon le fournisseur d'infrastructure.
Forcer les utilisateurs à créer des mots de passe sécurisés est une bonne idée, mais vous devez également faire votre part sur le backend. Garder les mots de passe hors du stockage en texte brut contribuera grandement à protéger vos utilisateurs et vos systèmes. Le principal danger du stockage des mots de passe en clair est le mauvais 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 de plus en plus de personnes ont accès à des informations sensibles) que celles-ci soient correctement hachées et que seules les personnes qui en ont absolument besoin y aient accès y soient autorisées.
Consultez le Secure Code Warrior des pages de blog pour en savoir plus sur cette vulnérabilité et sur la manière de protéger votre organisation et vos clients des ravages causés par d'autres failles de sécurité et vulnérabilités. Vous pouvez également essayez une démo IaC challenge au sein de la plateforme de formation Secure Code Warrior pour maintenir toutes vos compétences en cybersécurité à jour et à jour.
Inhaltsverzeichnis
Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.

Secure Code Warrior Ihr Unternehmen dabei, den Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie für die Anwendungssicherheit verantwortlich sind, Entwickler, IT-Sicherheitsbeauftragter oder in einer anderen Funktion im Bereich Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchenHerunterladenRessourcen, die Ihnen den Einstieg erleichtern
Themen und Inhalte der Schulung zum sicheren Code
Unsere hochmodernen Inhalte werden ständig weiterentwickelt, um mit den ständigen Veränderungen in der Softwareentwicklungslandschaft Schritt zu halten und gleichzeitig Ihre Rolle zu berücksichtigen. Die Themen reichen von KI bis hin zu XQuery-Injection und sind für eine Vielzahl von Positionen konzipiert, von Architekten über Ingenieure bis hin zu Produktmanagern und Qualitätssicherungsmitarbeitern. Verschaffen Sie sich einen Überblick über die Inhalte unseres Katalogs, sortiert nach Themen und Rollen.
Die Kamer van Koophandel setzt Maßstäbe für entwicklergesteuerte Sicherheit in großem Maßstab
Die Kamer van Koophandel berichtet, wie sie sicheres Codieren durch rollenbasierte Zertifizierungen, Trust Score-Benchmarking und eine Kultur der gemeinsamen Verantwortung für Sicherheit in die tägliche Entwicklungsarbeit integriert hat.
Bedrohungsmodellierung mit KI: So wird jeder Entwickler zum Bedrohungsmodellierer
Sie werden besser gerüstet sein, um Entwicklern dabei zu helfen, Ideen und Techniken zur Bedrohungsmodellierung mit den KI-Tools zu kombinieren, die sie bereits verwenden, um die Sicherheit zu erhöhen, die Zusammenarbeit zu verbessern und von Anfang an widerstandsfähigere Software zu entwickeln.
Ressourcen, die Ihnen den Einstieg erleichtern
Cybermon ist zurück: Die missions „Beat the Boss“ sind jetzt auf Abruf verfügbar.
Cybermon 2025 Beat the Boss ist jetzt das ganze Jahr über in SCW verfügbar. Setzen Sie fortschrittliche Sicherheitsherausforderungen im Zusammenhang mit KI und LLM ein, um die sichere Entwicklung von KI in großem Maßstab zu stärken.
Erläuterung des Gesetzes zur Cyberresilienz: Was bedeutet das für die Entwicklung sicherer Software bereits ab der Konzeption?
Entdecken Sie, was das europäische Gesetz zur Cyberresilienz (CRA) verlangt, für wen es gilt und wie sich Ingenieurteams durch Sicherheitsmaßnahmen bereits in der Entwurfsphase, durch die Vermeidung von Schwachstellen und durch die Stärkung der Fähigkeiten der Entwickler darauf vorbereiten können.
Moderator 1: Definierte und messbare Erfolgskriterien
Enabler 1 gibt den Startschuss für unsere 10-teilige Serie mit dem Titel „Enablers of Success“ und zeigt, wie sichere Codierung mit geschäftlichen Ergebnissen wie Risikominderung und Schnelligkeit kombiniert werden kann, um die langfristige Reife von Programmen sicherzustellen.




%20(1).avif)
.avif)
