Points clés
- Chaque nouveau déploiement crée des dépendances techniques avec les systèmes existants — des connexions, des flux de données et des dépendances d'authentification qui étendent la surface d'attaque.
- Les dépendances non documentées sont les plus dangereuses : elles créent des points de défaillance et des vecteurs d'attaque que personne ne gère parce que personne ne sait qu'ils existent.
- La cartographie des dépendances est un prérequis à toute évaluation sérieuse des risques d'un projet — et elle est régulièrement négligée.
- Le principe de zero trust s'applique aux dépendances inter-systèmes : chaque connexion doit être justifiée, contrôlée et auditée.
Chaque nouveau système déployé dans un SI existant s'intègre dans un réseau de dépendances — il dépend d'autres systèmes pour fonctionner (authentification, données, APIs) et d'autres systèmes en dépendent en retour. Ces dépendances sont souvent sous-documentées, créant un SI dont la complexité réelle dépasse largement ce que les équipes IT peuvent visualiser.
Cette opacité des dépendances a des conséquences sécuritaires directes : la compromission d'un système compromet tous les systèmes qui en dépendent, et la défaillance d'un système peut paralyser tous les systèmes qui l'utilisent. Ces effets de propagation, largement amplifiés par les dépendances non documentées, expliquent pourquoi les incidents dans les SI complexes sont souvent plus graves que prévu initialement.
Les dépendances d'authentification et d'accès
Un nouveau système qui s'authentifie via un annuaire d'entreprise, utilise un SSO, ou accède à des APIs via des tokens partagés crée des dépendances d'authentification qui signifient que la compromission de n'importe lequel de ces mécanismes d'authentification peut ouvrir l'accès au nouveau système. Si l'annuaire d'entreprise est compromis, tous les systèmes qui s'authentifient via lui sont potentiellement compromis. La cartographie de ces dépendances d'authentification est indispensable pour évaluer la propagation potentielle d'une compromission.
Les flux de données et les APIs
Un nouveau système qui importe des données d'autres systèmes ou exporte des données vers d'autres destinations crée des flux qui transportent de la valeur et des risques. Une API mal sécurisée dans le nouveau système peut permettre l'exfiltration de données de tous les systèmes qui lui transmettent des données. Un flux de données vers un système tiers crée une dépendance sur la sécurité de ce tiers pour la protection des données transmises.
La cartographie des flux de données entrants et sortants de chaque nouveau système déployé est une exigence de base d'une analyse de risques sérieuse — et une obligation réglementaire pour les données personnelles (registre des traitements RGPD).
Les dépendances de services cloud et de tiers
Les nouvelles applications cloud créent des dépendances sur la disponibilité, la sécurité et la politique de confidentialité des prestataires cloud. Si un prestataire SaaS est compromis, les données et les accès de ses clients sont potentiellement compromis. Ces dépendances, souvent minimisées lors du choix des solutions, deviennent des risques réels qui se manifestent lors des incidents affectant les prestataires — comme l'illustre la compromission de SolarWinds qui a affecté 18 000 de ses clients.
Documenter et gérer les dépendances
La documentation systématique des dépendances — quels systèmes dépendent de quoi, avec quels mécanismes et quelles données circulant dans quels sens — est la base d'une gestion sérieuse des risques liés aux nouveaux déploiements. Cette documentation, maintenue à jour lors de chaque modification, permet d'évaluer l'impact potentiel des incidents, de planifier les maintenances, et de prendre des décisions d'architecture fondées sur une compréhension réelle du SI existant.
Études de cas
SolarWinds 2020 — Dépendance sur une mise à jour compromise
L'attaque SolarWinds a exploité la dépendance de 18 000 organisations sur les mises à jour logicielles d'un éditeur de confiance. La compromission de la chaîne de build de SolarWinds a transformé une dépendance normale (recevoir les mises à jour d'un éditeur) en vecteur d'intrusion massif. Chaque organisation qui n'avait pas cartographié ses dépendances sur SolarWinds Orion n'a pas pu évaluer rapidement son niveau d'exposition — retardant sa réponse et aggravant les conséquences.
Déploiement d'une API sans sécurité — Optus 2022
La compromission d'Optus en 2022, qui a exposé les données de 11 millions de clients australiens, a exploité une API non authentifiée exposée sur Internet lors d'une migration. Cette API, créée pendant le projet de migration comme canal temporaire de transfert de données, n'avait pas été documentée dans l'inventaire des actifs de l'entreprise et n'était pas protégée par les contrôles habituels. Sa découverte par un attaquant via un scan automatique a permis l'exfiltration des données sans aucune sophistication technique particulière.
NotPetya 2017 — Propagation via les dépendances réseau non segmentées
NotPetya a pu se propager à 45 000 postes de Maersk et à des systèmes dans 40 pays en quelques heures grâce aux dépendances réseau non segmentées créées par des années de déploiements de systèmes sans planification des dépendances. Chaque nouveau système connecté au réseau interne sans restriction avait étendu la portée de propagation potentielle d'un malware disposant des bons exploits. La reconstruction post-incident a inclus une refonte de l'architecture réseau avec une segmentation explicite des dépendances.
États-Unis — CISA et la gestion des dépendances dans les infrastructures critiques
La CISA a publié des guides sur la gestion des dépendances dans les infrastructures critiques, incluant des recommandations sur la cartographie des interdépendances systèmes, la gestion des dépendances sur des prestataires tiers, et la planification de la résilience en cas de défaillance d'un composant clé. Ces guides, appliqués aux projets de transformation numérique dans les secteurs critiques, fournissent un cadre pratique pour intégrer la gestion des dépendances dans la gouvernance de la sécurité des projets.
Union européenne — RGPD et la cartographie des flux de données
L'obligation de tenir un registre des traitements de données personnelles sous le RGPD impose une forme de cartographie des flux de données — qui envoie quelles données à qui, via quels systèmes. Cette obligation, bien que limitée aux données personnelles, a conduit les organisations à développer des capacités de cartographie des flux qu'elles ont progressivement étendues à l'ensemble de leurs dépendances de données. La discipline de documentation imposée par le RGPD est un sous-produit positif pour la gouvernance de la sécurité des projets.
Corée du Sud — Cartes des dépendances dans les projets de digitalisation gouvernementale
Le gouvernement coréen a formalisé l'obligation de produire une cartographie des dépendances pour tout projet de digitalisation des services publics, incluant la documentation des connexions inter-systèmes, des flux de données et des dépendances sur des prestataires externes. Cette cartographie, revue lors des jalons de gouvernance du projet, permet d'évaluer l'impact de chaque composant sur l'ensemble du système et de concevoir des architectures qui limitent la propagation des incidents — une leçon tirée de plusieurs incidents affectant des services publics numériques coréens.