Série Coders Conquer Security Infrastructure as Code : Protection insuffisante de la couche de transport

Si vous êtes un développeur cherchant à en savoir plus sur les étapes à suivre pour commencer à déployer une infrastructure sécurisée en tant que code (IaC) au sein de votre organisation, vous êtes au bon endroit. Voici le prochain chapitre de notre série sur l'IaC, conçu pour vous faire monter en compétence sur les meilleures pratiques de sécurité IaC.

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

Vous voulez en savoir plus et obtenir un score parfait ? Lisez la suite :

Dans notre dernier article, nous avons évoqué l'importance d'une cryptographie sécurisée pour protéger toutes les données importantes ou personnelles stockées par les applications et les programmes. Un chiffrement robuste constitue une ultime ligne de défense idéale. Même si un attaquant parvient à dérober ces données, si elles sont fortement chiffrées, les informations verrouillées dans ces fichiers restent protégées.

La protection des données au repos n'est cependant qu'une partie d'une défense complète. Chaque fois que des utilisateurs valides doivent accéder à des données protégées, celles-ci doivent leur être transmises. Il arrive que des applications partagent également des données avec d'autres programmes dans le cadre d'une charge de travail globale. Si la couche de transport n'est pas protégée, elle devient vulnérable aussi bien à l'espionnage extérieur qu'à la consultation interne non autorisée. Par conséquent, une protection insuffisante de la couche de transport peut entraîner de graves problèmes.

C'est 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 informatiques qualifiés d'intercepter les informations circulant entre vos utilisateurs et vos applications, en utilisant des techniques telles que les attaques de l'homme du milieu (man-in-the-middle). L'aspect le plus dangereux de ce type d'espionnage est probablement 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 déployant un service Nginx :

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: *default-resources_policy

La configuration du service Nginx ne chiffrera ni ne protégera la connexion, rendant toutes les informations échangées via ce lien 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;
       }
   }

Bien souvent, le premier signe que quelqu'un espionne 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 clients, des dossiers financiers ou des secrets d'entreprise importants, sont dérobées via une couche de transport non sécurisée, il est possible que vous ne vous rendiez jamais compte que vous avez été compromis.

Et il n'y a pas que la couche de transport entre les utilisateurs et les applications qui nécessite une protection. En backend, de nombreuses applications communiquent entre elles et avec des serveurs situés plus loin dans la chaîne de flux 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, bien qu'autorisés sur le réseau, ne sont pas habilités à consulter certaines informations hautement protégées ou sensibles.

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

La protection des couches de transport s'effectue idéalement lors de la création des applications. Ce processus commence par la mise en place d'une infrastructure backend sécurisée. Pour les sites web, tout doit être effectué via HTTPS. Ne mélangez jamais les infrastructures HTTP et HTTPS. Vous devriez même configurer vos sites pour qu'ils redirigent automatiquement les requêtes HTTP non sécurisées vers l'infrastructure HTTPS.

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

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 au service Nginx sont fortement chiffrées. La section serveur de la configuration Nginx inclut uniquement listen 8443 ssl afin d'imposer le protocole SSL pour sécuriser les connexions.

Pour protéger vos données contre les menaces internes, les développeurs doivent utiliser un protocole de chiffrement de couche transport robuste tel que TLS 1.2. Une fois TLS 1.2 ou un équivalent mis en place, les protocoles obsolètes comme SSL v2 doivent être totalement supprimés de votre infrastructure et leur utilisation systématiquement bloquée.

Gardez toujours à l'esprit que la sécurisation d'une application n'est complète que lorsque les données au repos et les couches de transport sont suffisamment protégées. Vous garantissez ainsi une protection de bout en bout, tant en interne que lors des échanges avec des utilisateurs externes autorisé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 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.