코드 시리즈로 보안 인프라를 정복한 코더: 불충분한 전송 계층 보호

Si vous êtes un développeur et que vous souhaitez en savoir plus sur les étapes à suivre pour commencer à déployer une infrastructure sécurisée sous forme de code (IaC) dans votre entreprise, vous êtes au bon endroit. Il s'agit du chapitre suivant de notre série sur l'IaC, conçue pour vous faire progresser dans les meilleures pratiques de sécurité de l'IaC.

Avant de commencer, comment avez-vous relevé le défi du dernier épisode ? Si vous maîtrisez la cryptographie non sécurisée, voyons comment vous vous en sortez avec une protection de la couche transport insuffisante avant d'entrer dans les détails :

Vous voulez en savoir plus et obtenir une note parfaite ? Lisez la suite :

Dans notre dernier article, nous avons parlé de l'importance de disposer d'une cryptographie sécurisée pour protéger toutes les données importantes ou personnelles stockées par des applications et des programmes. Si vous disposez d'un cryptage fort, il agit comme une dernière ligne de défense parfaite. Même si un pirate est en mesure de voler ces données, si elles sont fortement cryptées, les informations enfermées dans ces fichiers sont toujours protégées.

La protection des données au repos n'est toutefois qu'une partie d'une défense complète des données. Lorsque des utilisateurs valides ont besoin d'accéder à des données protégées, celles-ci doivent leur être envoyées. Parfois, les applications partagent également des données avec d'autres programmes dans le cadre d'une charge de travail globale. Si la couche transport n'est pas protégée, elle est vulnérable à la fois à l'espionnage extérieur et à la visualisation interne non autorisée. Ainsi, une protection insuffisante de la couche transport peut entraîner de graves problèmes.

Il s'agit d'un problème courant. L'organisation de sécurité OWASP consacre même une page entière à la protection insuffisante de la couche de transport.

Pourquoi une protection insuffisante de la couche de transport est-elle dangereuse ?

Si vous ne protégez pas suffisamment vos couches de transport, il est relativement facile pour des pirates compétents d'intercepter les informations circulant entre vos utilisateurs et vos applications à l'aide de techniques telles que les attaques de type "man-in-the-middle". L'aspect le plus dangereux de ce type d'espionnage est qu'il est presque totalement invisible pour les plateformes ou les analyses de cybersécurité internes, car il se produit en dehors de votre réseau et de votre contrôle.

Par exemple, dans un environnement Docker qui déploie un service Nginx, les pirates peuvent intercepter les informations qui circulent entre vos utilisateurs et vos applications :

services :
nginx :
image : localhost:5000/scw_nginx
build : ./nginx
secrets :
- nginx_cert
- nginx_key
volumes :
- type : bind
source : ./nginx/nginx.conf
target : /etc/nginx/nginx.conf
read_only : yes
ports :
- 80:8443
networks :
- frontend
deploy :
restart_policy : *default-restart_policy
resources : *politique_default-resources

La configuration du service Nginx ne crypte ni ne protège la connexion, ce qui rend toutes les informations échangées par le biais de la liaison vulnérables à diverses attaques ou à l'espionnage.

server {
       server_name scw-dev-blog.org;
       listen 8443;
       ssl_protocols TLSv1.2 TLSv1.3;
       ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
       ssl_prefer_server_ciphers on;
       ssl_certificate /run/secrets/nginx_cert;
       ssl_certificate_key /run/secrets/nginx_key;
       access_log /dev/stdout;
       error_log /dev/stderr;
       location / {
           proxy_pass http://wordpress:8080;
           proxy_set_header Host $http_host;
           proxy_set_header X-Forwarded-Host $http_host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto $scheme;
       }
   }

Souvent, le premier signe que quelqu'un est en train d'espionner vos couches de transport est l'utilisation d'un grand nombre de mots de passe d'utilisateurs volés lors d'attaques ultérieures. Si d'autres données, telles que des informations sur les clients, des dossiers financiers ou des secrets d'entreprise importants, sont volées via une couche de transport non sécurisée, il se peut que vous ne vous rendiez même pas compte que vous avez été compromis.

Et ce n'est pas seulement la couche de transport entre les utilisateurs et les applications qui doit être protégée. En arrière-plan, de nombreuses applications communiquent entre elles et avec des serveurs situés plus loin dans la chaîne de travail. Bien que ces communications internes ne soient généralement pas vulnérables à l'espionnage extérieur, elles peuvent exposer des données à des utilisateurs qui peuvent être autorisés à accéder au réseau mais qui ne sont pas autorisés à voir certaines informations hautement protégées ou sensibles.

Sécuriser correctement les couches de transport pour une protection totale des données

La meilleure façon de protéger les couches de transport est de le faire pendant la création des applications. Ce processus commence par la mise en place d'une infrastructure dorsale sécurisée. Pour les sites web, tout doit être fait en HTTPS. Ne mélangez jamais les infrastructures HTTP et HTTPS. Vous devriez même configurer vos sites de manière à ce que les requêtes HTTP non sécurisées soient automatiquement acheminées vers l'infrastructure HTTPS.

Dans l'exemple ci-dessus, une méthode appropriée de protection de la couche transport serait la suivante :

server {
       server_name scw-dev-blog.org;
       listen 8443 ssl;
       ssl_protocols TLSv1.2 TLSv1.3;
       ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
       ssl_prefer_server_ciphers on;
       ssl_certificate /run/secrets/nginx_cert;
       ssl_certificate_key /run/secrets/nginx_key;
       access_log /dev/stdout;
       error_log /dev/stderr;
       location / {
           proxy_pass http://wordpress:8080;
           proxy_set_header Host $http_host;
           proxy_set_header X-Forwarded-Host $http_host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto $scheme;
       }
   }

Dans cet exemple, toutes les connexions avec le service Nginx sont fortement cryptées. La section serveur de la configuration de Nginx n'inclut que listen 8443 ssl afin de forcer SSL à protéger les connexions.

Pour protéger vos données contre les menaces internes, les développeurs doivent utiliser un protocole de cryptage de la couche de transport solide comme TLS 1.2. Une fois que vous avez mis en place TLS 1.2 ou son équivalent, les protocoles plus faibles comme SSL v2 doivent être complètement supprimés de votre infrastructure et automatiquement interdits d'utilisation.

N'oubliez jamais que la sécurisation d'une application n'est pas complète tant que les données au repos et les couches de transport ne sont pas suffisamment protégées. De cette façon, vous pouvez garantir une protection complète de bout en bout des données, tant en interne que lorsqu'elles sont transmises à des utilisateurs externes autorisés.
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 des ravages causés par d'autres failles de sécurité. Vous pouvez également essayer une démo de la plateforme de formation Secure Code Warrior pour maintenir vos compétences en cybersécurité à jour.