Configurez la sécurité de vos environnements (A02:2025)

Vous avez franchi une première étape décisive en verrouillant les accès logiques aux ressources de votre application (A01). Cependant, vos efforts de conception pour le portail B2B de TechNova seront vains si l'infrastructure qui héberge votre produit est laissée grande ouverte. L'équipe doit maintenant étendre son cadre d'exigences à la dimension infrastructurelle pour anticiper la phase de déploiement.

Avec l'adoption massive du cloud computing, la surface d'attaque s'est drastiquement déplacée.

Une application, même parfaitement codée et exempte de failles logiques, sera immédiatement compromise si elle est déployée sur un serveur qui laisse ses ports ouverts ou qui conserve ses mots de passe par défaut.

C'est la raison pour laquelle les erreurs de configuration de sécurité, ou Security Misconfiguration, se hissent désormais à la 2ème place du Top 10 OWASP 2025.

Fait alarmant : 100 % des applications testées lors de l'élaboration de ce classement présentaient une forme de mauvaise configuration.

L'objectif de ce chapitre est de vous fournir les clés pour instaurer un processus de durcissement (Hardening) rigoureux. En éliminant les réglages par défaut et en automatisant vos déploiements, vous construirez des fondations solides et résilientes pour TechNova.

Analysez le cas public de vulnérabilité : les espaces de stockage cloud

Pour comprendre l'ampleur des risques liés à une mauvaise configuration, nous n'avons pas besoin de chercher des techniques de piratage complexes. Les attaques les plus dévastatrices de ces dernières années reposent souvent sur de simples oublis.

En juillet 2019, Capital One révèle qu'un attaquant est parvenu à accéder aux données personnelles de plus de 100 millions de clients hébergées sur Amazon Web Services. L'enquête montre que l'attaque s'appuyait notamment sur une mauvaise configuration de l'infrastructure cloud, permettant d'accéder à des ressources S3 normalement réservées aux applications internes. Cet incident est devenu l'un des exemples les plus célèbres de mauvaise configuration cloud.

La réalité est que les cybercriminels utilisent des scanners automatisés qui parcourent Internet en continu. Ils testent des millions de combinaisons de noms d'espaces de stockage associés à des entreprises connues (ex: technova-backup-prod, technova-assets). Si les permissions d'un bucket autorisent l'accès public en lecture, le scanner télécharge discrètement l'intégralité des données. De nombreuses entreprises ont ainsi vu les données personnelles de millions de clients exposées, simplement parce qu'une case "Rendre public" n'avait pas été décochée lors de la création de l'environnement cloud.

Étudions un second impact tout aussi critique : l'exposition d'une console d'administration non protégée. De nombreux serveurs d'application, bases de données ou routeurs sont livrés avec une interface d'administration web accessible publiquement par défaut.

Imaginez que l'équipe de TechNova déploie un nouveau serveur d'application web et oublie de désactiver la console d'administration intégrée. Pire encore, les identifiants par défaut définis par le constructeur (souvent admin / admin ou root / password) ne sont pas modifiés.

Dans ce cas, l'attaquant n'a aucune faille complexe à exploiter : il lui suffit de se rendre sur l'URL de la console, d'entrer les identifiants bien connus fournis dans la documentation publique du logiciel, et de prendre le contrôle total du serveur. Ce type de négligence transforme une infrastructure robuste en une véritable passoire.

Identifiez les éléments clés de ce type de vulnérabilité

Maintenant que vous mesurez l'impact d'une infrastructure mal configurée, il est indispensable de décortiquer les éléments techniques qui constituent la catégorie A02 du Top 10 OWASP 2025. Contrairement à une faille de code spécifique, la mauvaise configuration de sécurité est un problème systémique qui peut se nicher à tous les étages de votre pile technologique (réseau, base de données, serveur web, frameworks applicatifs).

Le premier danger réside dans l'utilisation de comptes par défaut, ainsi que dans la présence d'applications d'exemple non supprimées et de services inutiles activés.

Si vous laissez ces applications d'exemple sur un serveur en production, elles constituent une porte d'entrée inespérée. Elles contiennent souvent des failles de sécurité connues que les attaquants exploitent automatiquement. De plus, chaque port ouvert inutilement ou chaque service actif (comme un ancien serveur FTP oublié) augmente inutilement votre surface d'attaque. Une règle d'or en cybersécurité est que tout ce qui n'est pas strictement nécessaire doit être éteint et supprimé.

Le deuxième risque majeur est lié à la fuite d'informations techniques via les traces d'erreurs (stack traces) exposées par le serveur.

Si le serveur est mal configuré et renvoie ce rapport détaillé directement sur l'écran de l'utilisateur final, il offre à l'attaquant une véritable carte au trésor. En connaissant les versions exactes de vos composants technologiques, l'attaquant peut chercher des vulnérabilités publiques (CVE) qui leur sont spécifiquement associées.

Enfin, la configuration incomplète des en-têtes HTTP (Security Headers) prive les navigateurs de vos utilisateurs des mécanismes de défense intégrés modernes. Ces éléments clés démontrent que l'absence d'une politique de configuration centralisée et révisée est une vulnérabilité critique en soi.

Définissez le processus de résolution pour éviter la vulnérabilité

Face à l'étendue de ces risques, la correction manuelle n'est pas une option viable. L'erreur humaine est inévitable si l'on demande à un administrateur système de configurer manuellement des dizaines de serveurs. Votre rôle, en tant que garant du cadre d'exigences chez TechNova, est d'imposer un processus de résolution industriel et systématique.

La solution absolue pour contrer la catégorie A02 est d'exiger un processus de durcissement (ou Hardening) automatisé et reproductible pour tous vos environnements.

Pour que ce processus soit fiable, vous devez adopter l'approche de la « Configuration as Code ». Les environnements de Développement (Dev), de Qualification (QA) et de Production (Prod) doivent tous être configurés de manière strictement identique via des scripts d'automatisation. La seule différence technique entre ces environnements doit résider dans les identifiants utilisés, qui doivent être distincts pour chaque niveau. Si une configuration est validée et sécurisée en Dev, le fait de la rejouer à l'identique en QA puis en Prod élimine la « dérive de configuration » (configuration drift), c'est-à-dire les écarts manuels qui s'accumulent d'un environnement à l'autre. 

Pour mettre en pratique cette exigence, vous devez intégrer l'utilisation d'outils d'analyse dynamique en continu. Exigez l'intégration du ZAP Automation Framework (ou d'outils similaires) directement dans vos chaînes de déploiement CI/CD.

Ces outils agiront comme des auditeurs intraitables : à chaque fois qu'un environnement est déployé, ils scanneront automatiquement la configuration pour vérifier si le listing des répertoires est bien désactivé, si des mots de passe par défaut subsistent, ou si des en-têtes de sécurité sont manquants. Si l'outil détecte une anomalie de configuration, le déploiement en production doit être automatiquement bloqué.

En intégrant ce processus de vérification automatisé à votre cadre d'exigences, vous garantissez que la sécurité de l'infrastructure de TechNova ne dépend plus de la mémoire ou de la disponibilité d'une seule personne, mais d'un standard technique gravé dans le marbre.

À vous de jouer

Contexte

La direction de TechNova souhaite accélérer le développement du portail B2B. Pour ce faire, l'équipe DevOps est chargée de préparer la nouvelle infrastructure d'hébergement. Ils vont instancier plusieurs dizaines de serveurs applicatifs et de bases de données hébergées dans le cloud.

Cependant, avant de lancer leurs scripts de déploiement, l'équipe DevOps vient vous consulter. Ils ont besoin que vous leur fournissiez la liste des prérequis de sécurité absolus, les "garde-fous" initiaux pour éviter de créer une infrastructure vulnérable dès le premier jour. En reprenant la situation et les éléments vus depuis le lancement de ce projet, vous devez cadrer cette étape cruciale.

Consigne

Établissez la checklist des 3 règles d'or de configuration sécurisée à respecter obligatoirement par les équipes d'infrastructure.

En résumé

• La mauvaise configuration de sécurité est généralisée : Classée numéro 2 du Top 10 OWASP, elle affecte 100 % des applications testées et survient lorsque l'infrastructure, le cloud ou le serveur ne sont pas durcis.

• Méfiez-vous des paramètres par défaut : Les mots de passe constructeurs non modifiés, les consoles d'administration exposées sur Internet et les applications d'exemple constituent les portes d'entrée les plus faciles pour les cybercriminels.

• Maîtrisez vos messages d'erreur : Exposer des traces d'erreurs détaillées (stack traces) révèle la structure interne de votre système et permet aux attaquants de cibler précisément vos vulnérabilités.

• Automatisez le durcissement (Hardening) : Définissez vos configurations sous forme de code et déployez des environnements de Développement, QA et Production strictement identiques et testés en continu.

Vous êtes désormais capable d'ériger les murs protecteurs de votre infrastructure cloud en automatisant son durcissement ; découvrons donc, dans le prochain chapitre, comment protéger les briques mêmes qui composent notre logiciel.