Série sur la sécurisation de l'infrastructure en tant que code : Cryptographie non sécurisée

Les organisations avisées adoptent le concept d'infrastructure en tant que code, et ce sont des développeurs comme vous qui peuvent apporter une contribution significative à la création de code sécurisé, même en dehors du développement d'applications. Le chemin peut sembler long au début, mais l'effort en vaut la peine pour vous démarquer de vos pairs.

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 :

De nos jours, le hachage des données critiques telles que les mots de passe, les informations personnelles et les dossiers financiers au repos est la pierre angulaire de toute défense en cybersécurité. À bien des égards, cela constitue à la fois une dernière ligne de défense et l'une des meilleures formes de protection. En effet, même si un attaquant parvient à franchir d'autres défenses et à obtenir des fichiers critiques, ceux-ci ne lui seront d'aucune utilité s'ils sont correctement hachés et stockés.

Cela constitue également une solide protection secondaire contre les menaces internes, car les fichiers chiffrés peuvent utiliser des clés ou des mots de passe distincts du reste du réseau. Dans ce cas, un administrateur système ou un pirate informatique ayant compromis les identifiants d'un administrateur pourrait accéder à un répertoire protégé, mais resterait incapable de déverrouiller les fichiers chiffrés s'il ne possède pas la clé de chiffrement, conservée ailleurs.

Bien entendu, toutes les méthodes de protection par chiffrement reposent sur l'utilisation de normes robustes, impossibles à briser, même par les ordinateurs les plus puissants.

Pourquoi une cryptographie non sécurisée est-elle dangereuse ?

En matière de technologie informatique, la création d'algorithmes de chiffrement robustes et la capacité à les briser se livrent une concurrence de longue date. En 1977, le gouvernement fédéral des États-Unis a développé le Data Encryption Standard (DES), un algorithme 56 bits considéré comme sécurisé à l'époque, compte tenu de la puissance relative des ordinateurs.

Mais les ordinateurs ont évolué, et des méthodes ont été trouvées pour les mettre en réseau afin d'accroître encore leur puissance. En 1999, l'Electronic Frontier Foundation, en collaboration avec Distributed.net, a réussi à briser publiquement le chiffrement d'un document protégé par DES en seulement 22 heures. Soudainement, tout document protégé par le chiffrement DES n'était plus en sécurité.

Croyez-le ou non, certaines organisations protègent encore leurs fichiers critiques avec l'algorithme DES ou des protections de chiffrement tout aussi faibles. Et s'il a fallu un réseau distribué pour briser le chiffrement 56 bits en 1999, aujourd'hui, presque n'importe quel ordinateur autonome suffisamment puissant peut y parvenir en un rien de temps. Les pirates ont également créé des machines de craquage dédiées, composées de banques d'unités de traitement graphique (GPU). Ces GPU sont exceptionnellement efficaces pour cette tâche, relativement peu coûteux à acquérir et faciles à mettre en réseau localement.

Si vous choisissez de protéger vos fichiers critiques avec un algorithme cryptographique non sécurisé ou faible aujourd'hui, il ne faudra pas longtemps avant que la plupart des pirates ne parviennent à déchiffrer ces fichiers et à les rendre lisibles. En cas de violation de données, vous devez partir du principe que les fichiers seront tôt ou tard compromis s'ils n'étaient pas suffisamment protégés.

Par exemple, l'extrait de code Kubernetes suivant utilise un algorithme de chiffrement faible pour protéger les informations au niveau du contrôleur d'entrée NGINX :

apiVersion: v1
kind: ConfigMap
metadata:
 name: nginx-load-balancer-conf
 namespace: kube-system
data:
 ssl-ciphers: DES-CBC3-SHA
 ssl-protocols: "TLSv1.2"

Dans cet exemple, la suite de chiffrement DES a été utilisée pour protéger les informations. Cependant, un attaquant pourrait facilement la déchiffrer et accéder aux informations sensibles.

Il est recommandé d'utiliser des algorithmes de chiffrement robustes. Dans l'exemple Kubernetes suivant, des suites de chiffrement robustes ont été utilisées pour protéger les informations au niveau du contrôleur d'entrée NGINX :

apiVersion: v1
kind: ConfigMap
metadata:
 name: nginx-load-balancer-conf
 namespace: kube-system
data:
 ssl-ciphers: |
   ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:
   ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:
   ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:
   ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:
   ECDHE-RSA-AES128-SHA256
 ssl-protocols: "TLSv1.2"

Dans cet exemple, une suite de chiffrement robuste a été utilisée afin d'éviter que des attaquants n'obtiennent un accès potentiel à des informations sensibles.

Protéger les informations critiques grâce à un chiffrement robuste

Il existe aujourd'hui des méthodes de chiffrement robustes quasi inviolables. En 2001, le National Institute of Standards and Technology (NIST) a créé une nouvelle technologie de chiffrement pour remplacer le DES. Baptisée Advanced Encryption Standard (AES), elle utilise trois longueurs de clé différentes : 128, 192 ou 256 bits. Le chiffrement AES 256 bits est le plus sécurisé, bien que les trois soient considérés comme pratiquement inviolables avec la technologie actuelle. Des tests effectués avec des supercalculateurs ont démontré qu'il faudrait des milliers d'années de travail constant pour déchiffrer la plupart des documents protégés par AES.

Pour protéger correctement les fichiers critiques, les développeurs doivent d'abord les identifier. Il n'est pas nécessaire de tout chiffrer sur un réseau, car cela pourrait ralentir les opérations en raison du processus constant de chiffrement et de déchiffrement. Cependant, les fichiers sensibles tels que les dossiers du personnel, les données clients et les informations financières nécessitent une protection adéquate. Il s'agit essentiellement de trouver un équilibre entre sécurité et efficacité opérationnelle.

Ces données doivent être chiffrées selon l'une des normes AES, en allant jusqu'au chiffrement 256 bits pour les informations réellement critiques qui ne doivent jamais tomber entre de mauvaises mains.

Un autre point à prendre en compte est que l'ajout d'un chiffrement revient à ajouter des mots de passe supplémentaires à un site. Cela signifie que les utilisateurs autorisés devront gérer les clés de chiffrement. Pour éviter que cela ne devienne un goulot d'étranglement, envisagez de mettre en place une plateforme de gestion des clés afin de les suivre et de les sécuriser. Même si vous n'utilisez pas de gestion centralisée, assurez-vous que toutes les clés et tous les mots de passe sont protégés pour empêcher tout accès non autorisé à vos coffres-forts de données les plus sécurisés.

Consultez les pages du blog 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 une démonstration d'un défi IaC sur la plateforme de formation Secure Code Warrior pour maintenir vos compétences en cybersécurité à jour.