Notes techniques sur la sécurité

Les algorithmes à clé publique largement déployés aujourd'hui (RSA, courbes elliptiques) reposent sur des problèmes mathématiques que des ordinateurs quantiques suffisamment puissants pourraient résoudre efficacement. En 2024, le NIST a finalisé ses premières normes de cryptographie post-quantique (ML-KEM, dérivé de CRYSTALS-Kyber, pour l'échange de clés, et ML-DSA, dérivé de CRYSTALS-Dilithium, pour les signatures numériques), une étape décisive vers une adoption généralisée.

Le risque ne se limite pas à un scénario futur théorique : un trafic chiffré intercepté aujourd'hui peut être stocké puis déchiffré a posteriori, dès qu'une puissance de calcul quantique suffisante existera — c'est la stratégie dite «harvest now, decrypt later » (collecter maintenant, déchiffrer plus tard). Les données qui doivent rester confidentielles à long terme (secrets d'affaires, dossiers médicaux, données gouvernementales sensibles) sont directement exposées : la préparation doit donc commencer maintenant, et non après la concrétisation de la menace.

Se préparer ne signifie pas migrer dans l'urgence, mais plutôt adopter une démarche de crypto-agilité : cartographier les usages cryptographiques existants, identifier les données dont l'horizon de confidentialité est long, et concevoir des architectures capables d'intégrer de nouveaux algorithmes sans refonte complète.

La grande majorité des incidents de sécurité touchant les environnements cloud IaaS ne proviennent pas d'une faille du service du fournisseur, mais d'une erreur de configuration côté client — un rappel du modèle de responsabilité partagée du cloud : le fournisseur sécurise l'infrastructure sous-jacente, tandis que le client reste responsable de la configuration de ses propres ressources.

Les lacunes les plus fréquentes relevées en audit : des règles réseau trop permissives qui exposent directement des services d'administration sur Internet, des rôles IAM qui accumulent des privilèges excessifs faute de revue périodique, des volumes de stockage laissés publiquement accessibles par défaut, et une journalisation absente ou non centralisée qui retarde la détection des incidents.

Des revues de configuration régulières, une politique du moindre privilège appliquée aux identités et une segmentation réseau claire entre production et environnements de test réduisent déjà une grande partie de cette exposition — avant même d'envisager des outils de détection plus avancés.

Un scanner de vulnérabilités automatisé reste un outil précieux pour couvrir rapidement les failles connues et bien signaturées — injections classiques, composants obsolètes, en-têtes de sécurité manquants. Il atteint cependant vite ses limites face aux failles de logique métier : contournement d'un parcours de paiement, élévation de privilèges par manipulation d'un identifiant de ressource, ou enchaînement de plusieurs faiblesses mineures pour produire un impact critique.

Ce type de vulnérabilité ne se découvre qu'en comprenant le fonctionnement métier réel de l'application testée, en manipulant activement ses parcours et en raisonnant comme un attaquant motivé, plutôt qu'en appliquant une liste de signatures génériques. C'est précisément ce que couvre un test d'intrusion mené manuellement — en complément, et jamais en remplacement, de l'outillage automatisé.

Un rapport de test d'intrusion utile va au-delà d'une liste de failles techniques : il hiérarchise les constats selon leur impact réel sur l'activité, avec des recommandations de remédiation directement exploitables par les équipes techniques.