Les audits CI/CD réalisés en 2025 et 2026 ont révélé que des identifiants exposés dans des dépôts, des runners mal configurés, des stockages d’artefacts non sécurisés et des rôles cloud trop permissifs constituent autant de vecteurs d’attaque que des acteurs malveillants peuvent exploiter afin d’obtenir un accès persistant et fortement privilégié à l’ensemble de l’infrastructure.

Une vue d’ensemble des outils DevOps est illustrée ci-dessous :

Une compromission à n’importe quelle étape du pipeline peut ouvrir une voie vers des systèmes plus sensibles.

Cet article décrit une chaîne d’attaque CI/CD représentative visant un environnement CI/CD, fondée sur des scénarios observés en conditions réelles. Il met en évidence les vecteurs d’attaque les plus couramment exploités ainsi que les principales mesures de durcissement permettant de réduire la surface d’attaque à chaque étape du pipeline, depuis le code source jusqu’au déploiement en production.

La chaîne d’attaque: de la reconnaissance à la persistance

Reconnaissance et accès initial

La chaîne d’attaque débute généralement par une attaque de phishing ciblant les développeurs afin de voler des identifiants et des codes MFA, bien que le MFA puisse lui-même être contourné via le vol de jetons d’accès ou de détournement de sessions.

Il convient de noter que la compromission d’identifiants seule n’est pas toujours suffisante pour accéder directement à des portails administratifs sensibles. Les contrôles de sécurité autour des interfaces d’administration Microsoft 365 ont été renforcés par des mécanismes de MFA ainsi que, le cas échéant, par des politiques d’accès conditionnel, limitant l’impact du phishing sur les accès hautement privilégiés.

Cependant, dans les environnements d’entreprise modernes où la majorité des applications reposent sur le Single Sign-On (SSO), la compromission d’une session Microsoft (par exemple via le vol de cookies de session) peut donner aux attaquants accès à un large éventail de services interconnectés, incluant les dépôts de code et les plateformes CI/CD. Les attaquants utilisent généralement ce point d’entrée initial pour identifier les environnements de développement et établir une persistance via des mécanismes tels que les Jetons d’accès personnels (PAT).

Un risque souvent négligé survient lorsqu’un compte utilisateur est désactivé au niveau du fournisseur d’identité (ex. Entra ID) mais n’est pas entièrement désactivé dans les plateformes de dépôt. Dans ce cas, des PATs précédemment émis peuvent rester valides, permettant à un attaquant de conserver un accès malgré la révocation du compte.

D’autres vecteurs d’entrée incluent l’exploitation de CVE connues ainsi qu’une mauvaise gestion des identifiants. De nombreuses vulnérabilités majeures sur les outils DevOps sont régulièrement découvertes, ce qui souligne la nécessité d’une gestion continue des vulnérabilités. L’exploitation d’une vulnérabilité critique peut directement fournir un accès privilégié à un outil de la chaîne.

Exemples :

• CVE-2024-23897 (Jenkins), permettant à des attaquants non authentifiés de lire des fichiers arbitraires présents sur le contrôleur Jenkins, exposant ainsi des secrets sensibles,
• CVE-2023-7028 (GitLab), dans laquelle les emails de réinitialisation de mot de passe pouvaient être envoyés vers une adresse électronique non vérifiée.
• CVE-2023-36561 (Azure DevOps Server), une vulnérabilité d’élévation de privilèges permettant à un attaquant d’obtenir un accès non autorisé à certaines fonctionnalités d’Azure DevOps Server, avec un impact potentiel sur les pipelines, les secrets et les ressources des projets.

REMÉDIATION – Renforcer les contrôles d’accès aux dépôts de code source

Afin de réduire les risques liés à l’accès initial, les organisations doivent mettre en œuvre des contrôles permettant d’empêcher les accès non autorisés, de détecter les mécanismes de persistance et de renforcer la gouvernance des identités.

Appliquer des politiques d’accès strictes et réduire l’exposition réseau

• Eviter l’utilisation des comptes génériques ou partagés,
• Utiliser des identités développeurs dédiées, séparées des comptes bureautiques standards (messagerie et outils collaboratifs), afin de réduire l’exposition au phishing et l’impact d’une compromission dans les environnements CI/CD,
• Imposer des mécanismes MFA résistants au phishing (clés FIDO2, certificats, etc),
• Mettre en place des politiques d’accès conditionnel basées sur des critères contextuels (localisation réseau, conformité des appareils).

Mettre en place des mécanismes de détection de persistance

• Surveiller la création ou l’utilisation suspecte de PAT dans GitLab, ainsi que les activités anormales (ex. déploiements à des horaires inhabituels),
• Surveiller l’ajout de nouvelles méthodes d’authentification dans Entra ID, notamment les méthodes sans mot de passe, après un événement de phishing.

Réviser périodiquement les accès et supprimer les comptes inutilisés

• Désactiver ou supprimer les comptes inutilisés ou inactifs,
• Révoquer les accès des collaborateurs sortis de l’organisation sur tous les systèmes,
• Réaliser des revues d’accès périodiques, au minimum tous les six mois pour les utilisateurs à risque élevé.

Compromission des dépôts de code et des pipelines

Les dépôts de code sont souvent directement intégrés aux pipelines CI/CD, ce qui signifie que toute modification du code peut déclencher automatiquement des processus de build et de déploiement. Ainsi, la compromission d’un compte développeur peut influencer la manière dont les applications sont construites et déployées.

Pour réduire le risque de modifications non autorisées en production, les organisations protègent généralement les branches de production (ex. main ou master) via des pull requests, des validations et des contrôles automatisés. En revanche, les branches de développement sont souvent moins strictement contrôlées afin de favoriser la rapidité de développement et de test.

Dans le scénario observé, l’attaquant cible la branche de développement et modifie le fichier de configuration du pipeline (gitlab-ci.yml), en y injectant une commande malveillante (visant à établir un accès distant) au sein d’un job existant. Lors de l’exécution du pipeline, cette commande est exécutée sur le runner CI/CD, ce qui permet à l’attaquant d’obtenir un accès distant à ce dernier.

Une fois dans le runner CI/CD, l’attaquant peut alors exécuter du code arbitraire sur le runner CI/CD et, entre autres, énumérer les variables d’environnement contenant des paramètres de configurations et les secrets définis dans le projet GitLab.

Cependant, il arrive que certains composants de la chaîne CI/CD ne sont pas dupliqués entre environnements pour des raisons de coûts. Dans ce cas précis, les secrets GitLab ne sont pas segmentés entre les environnements de production et de développement. Ainsi l’attaquant est en capacité de lister les secrets de production depuis le runner CI/CD de développement.

Un exemple de variables d’environnement rencontrées dans les pipelines CI/CD est présenté ci-dessous.

Ce flux d’attaque montre comment la manipulation de pipeline permet l’exécution de code dans le runner et l’extraction de variables sensibles de production depuis un environnement de développement.

Parmi les identifiants récupérés dans l’environnement CI/CD compromis, l’attaquant obtient un jeton d’accès à Nexus, système de gestion d’artefacts utilisé pour stocker et distribuer les artefacts de build de confiance consommés par les pipelines situés en aval.

REMÉDIATION – Durcir la sécurité des dépôts de code

La sécurisation du dépôt de code est essentielle pour empêcher l’exploitation des pipelines CI/CD après un accès initial, car les dépôts contrôlent directement le build et le déploiement.

Durcir les dépôts pour limiter les déclenchements de pipeline

• Configurer des branches protégées pour les branches de déploiement,
• Mettre en place des workflows d’approbation multi-niveaux pour les merge requests déclenchant des pipelines et interdire l’auto-approbation,
• Utiliser la propriété du code (ownership) pour assigner et exiger l’approbation des responsables désignés sur les fichiers sensibles (ex. configuration CI/CD).

Limiter la visibilité et les permissions

• Limiter les droits d’écriture aux seuls utilisateurs qui en ont besoin,
• Restreindre la visibilité des projets selon le principe du besoin de savoir (interne ou privé recommandé).

Mettre en place une bonne hygiène de gestion des secrets

• Configurer des secrets CI/CD scopés au niveau projet et privilégier des identifiants éphémères,
• Détecter les secrets en clair le plus tôt possible (au moment du commit ou avant la publication du code) et les révoquer immédiatement en cas d’exposition,
• Réaliser des revues périodiques (ex. audits internes, exercices de red team) sur des plateformes telles que les dépôts Git, Jira ou Confluence afin d’identifier d’éventuelles fuites de secrets passées inaperçues.

REMÉDIATION – Renforcer la sécurité des runners auto-hébergés

Les runners sont des composants critiques des pipelines CI/CD car ils exécutent le code et manipulent des données sensibles. S’ils sont compromis, ils peuvent permettre des mouvements latéraux, l’accès aux secrets ou la prise de contrôle de l’environnement.

Réduire l’exposition réseau et le périmètre d’exécution

• Restreindre le trafic réseau des runners uniquement à ce qui est nécessaire à l’exécution des pipelines, et appliquer des contrôles réseau tels que des proxies et de la segmentation afin d’empêcher tout accès Internet non contrôlé et limiter les mouvements latéraux au sein des réseaux internes,
• Restreindre les déclenchements depuis des dépôts non fiables ou personnels.

Considérer les runners comme des systèmes sensibles

• Considérer les runners comme des serveurs critiques (Application régulière des correctifs du système d’exploitation et durcissement),
• Déployer des solutions de Endpoint Detection and Response (EDR) pour la surveillance des processus, y compris dans les environnements conteneurisés.

Utiliser des runners dédiés et éphémères

• Privilégier des runners dédiés par projet ou environnement. Le partage de runners entre plusieurs contextes augmente le risque de contamination inter-projets et d’escalade de privilèges,
• Utiliser des runners éphémères / autoscalés détruits après chaque job,
• S’assurer que les runners basés sur VM soient également éphémères et isolés afin qu’aucune donnée ou accès résiduel ne persiste entre les exécutions. En complément, s’appuyer uniquement sur des images de base durcies et de confiance (par exemple des golden images pour les runners VM et des images conteneurs approuvées), afin d’éviter toute exécution dans des environnements compromis ou non vérifiés.

Sécuriser les runners containerisés

• N’autoriser que des images approuvées et de confiance dans les exécutions de pipelines afin d’éviter l’introduction de code malveillant via des images compromises ou non vérifiées,
• Appliquer le principe du moindre privilège dans les environnements d’exécution conteneurisés,
• Éviter le mode privilégié et supprimer les capacités Linux inutiles,
• Utiliser des moteurs de build sécurisés (BuildKit / Buildah) lorsque le Docker-in-Docker est requis.

Durcir les runners cloud

• Lors de l’utilisation de runners managés dans le cloud, appliquer une isolation stricte et un périmètre d’identité, restreindre l’accès aux métadonnées afin d’éviter l’exposition d’identifiants depuis l’infrastructure sous-jacente, et s’assurer que les rôles CI/CD sont gouvernés par des politiques IAM strictes en moindre privilège afin d’éviter des permissions excessives.

Empoisonnement d’artefacts et attaques sur les dépendances

Dans les environnements de livraison logicielle, les systèmes de gestion d’artefacts stockent et distribuent les sorties générées par les pipelines CI/CD. Ces sorties, appelées artefacts, représentent les résultats packagés du processus de build, tels que des binaires compilés, des packages applicatifs ou des images de déploiement.

Les artefacts sont stockés de manière centralisée afin d’assurer le versioning, la traçabilité et la réutilisation à travers plusieurs pipelines. En plus des sorties spécifiques aux applications, ces dépôts hébergent souvent également des composants partagés tels que des golden images, des bibliothèques réutilisables ou des dépendances runtime communes. Comme ils proviennent de processus de build considérés comme fiables, les artefacts sont généralement supposés sûrs et largement consommés par les pipelines en aval sans validation supplémentaire.

Dans le scénario observé, l’attaquant utilise des identifiants précédemment obtenus pour s’authentifier au dépôt d’artefacts (Nexus dans cet exemple) avec des permissions excessives (lecture/écriture sur plusieurs catégories, plutôt que limitées à un périmètre applicatif unique), et obtient ainsi un accès à la fois aux artefacts de production et aux artefacts partagés.

Parmi ces derniers, l’attaquant identifie un binaire Terraform légitime utilisé dans le processus de déploiement d’infrastructure (appelé ici le binaire tofu), qui est couramment approuvé et consommé par les pipelines CI/CD pour provisionner et gérer les ressources cloud.

L’attaquant télécharge cet artefact localement et en modifie le contenu en injectant une logique malveillante tout en conservant sa fonctionnalité d’origine, et y intègre un comportement caché conçu pour interagir avec les services AWS Identity and Access Management (IAM) et AWS Security Token Service (STS) afin de récupérer des identifiants.

Le binaire modifié est ensuite téléversé de nouveau dans Nexus, remplaçant la version légitime par un artefact compromis.

À partir de ce moment, tout pipeline CI/CD consommant cet artefact récupère automatiquement le binaire compromis lors de la résolution des dépendances, car il est toujours considéré comme fiable.

Lors de son exécution, le binaire compromis active la charge malveillante intégrée, dont l’objectif est de récupérer le jeton d’accès AWS utilisé par le contexte d’exécution Terraform et de l’envoyer vers un serveur contrôlé par l’attaquant pour exfiltration. Il génère ensuite une sortie obfusquée encodée en Base32. Le décodage permet de reconstruire un objet JSON contenant des identifiants AWS (AccessKeyId, SecretAccessKey et SessionToken).

L’attaquant configure ensuite ces identifiants localement et utilise AWS STS (appel API GetCallerIdentity) pour confirmer l’usurpation d’identité du runner CI/CD.

Cette illustration montre la chaîne d’attaque : compromission d’artefact, injection de logique malveillante, propagation via les pipelines CI/CD et vol final d’identifiants AWS menant à la compromission de l’environnement.

En conséquence, l’attaquant obtient un accès non autorisé aux ressources AWS sous une identité légitime.

REMÉDIATION – Améliorer la gestion des accès à l’Artifactory

Les dépôts d’artefacts tels que Nexus sont des composants clés des pipelines CI/CD utilisés pour stocker et distribuer les dépendances et artefacts de build. Ce sont des cibles à forte valeur pour les attaques de chaîne d’approvisionnement.

La sécurité nécessite des contrôles d’accès forts, une gouvernance des dépendances et une surveillance continue de l’intégrité.

Durcir la plateforme d’artefacts

• Autoriser une large lecture du dépôt uniquement sous deux conditions : depuis le service nécessaire (CI/CD) et si une gestion de mots de passe dans les dépendances existe,
• Restreindre fortement les permissions d’écriture,
• Modifier les identifiants par défaut.

Analyse de composition logicielle (SCA)

• Appliquer une analyse de composition logicielle aux dépendances internes (stockées dans des dépôts locaux) ainsi qu’aux dépendances externes (récupérées depuis des dépôts distants ou proxy) afin de détecter les vulnérabilités connues et les composants obsolètes.

Restreindre les sources d’artefacts

• Maintenir une whitelist de dépôts de confiance afin de garantir que seules des sources approuvées sont utilisées,
• Appliquer des contrôles au niveau des dépôts pour exclure les versions non approuvées ou vulnérables, par exemple dans Nexus ou via des règles d’exclusion dans JFrog Artifactory,
• Empêcher les pipelines CI/CD d’accéder à des sources externes non fiables en imposant des frontières strictes entre dépôts.

Compromission cloud via abus des workloads CI/CD

Dans les environnements cloud, les runners CI/CD sont généralement associés à des rôles IAM privilégiés pour effectuer des opérations de déploiement, incluant la création, modification et suppression de ressources d’infrastructure. Ces rôles incluent souvent des permissions larges telles que AdministratorAccess ou des politiques personnalisées trop permissives, permettant au runner d’interagir avec un large ensemble de services AWS, incluant les services de calcul, le stockage et la gestion des identités.

Lorsqu’un runner CI/CD est compromis, un attaquant peut directement abuser de ces privilèges sans nécessiter d’escalade supplémentaire. Cela peut conduire à un accès immédiat à des ressources sensibles telles que des buckets S3 ou des bases de données RDS, permettant l’exfiltration de données. L’attaquant peut également exploiter les permissions IAM pour assumer d’autres rôles dans d’autres comptes ou projets AWS, facilitant les mouvements latéraux au sein de l’organisation. En outre, l’accès aux services de compute peut être utilisé pour déployer, modifier ou maintenir des charges malveillantes, aboutissant finalement à une compromission complète de l’environnement cloud.

De la compromission initiale du développeur à la prise de contrôle cloud : vue complète de la chaîne CI/CD

la chaîne d’attaque CI/CD commence par la compromission initiale du développeur jusqu’à la prise de contrôle complète de l’environnement cloud.

L’illustration suivante met en évidence les opportunités clés de détection et de surveillance à travers l’écosystème CI/CD. Elle montre comment les données de télémétrie de sécurité peuvent être collectées et corrélées tout au long des différentes étapes de la chaîne d’attaque CI/CD, depuis les activités de développement jusqu’aux runners CI/CD, aux dépôts d’artefacts et aux opérations IAM dans le cloud.

Dans l’ensemble, bien que les pipelines CI/CD élargissent significativement la surface d’attaque, ils offrent également de multiples points d’interception stratégiques où une journalisation centralisée et une surveillance de sécurité peuvent permettre une détection précoce et une réponse aux activités malveillantes.

En conclusion, pour obtenir un pipeline CI/CD sécurisé, la sécurité doit être pensée de bout en bout, des environnements développeurs jusqu’aux systèmes de production.

Les développeurs sont le premier maillon de la chaîne, et la sécurisation de leurs comptes est essentielle. Cela doit être complété par de bonnes pratiques telles que la gestion sécurisée des secrets et la sensibilisation régulière à la sécurité.

Il est également crucial d’assurer une bonne isolation entre environnements et d’appliquer strictement le principe du moindre privilège, aussi bien pour les utilisateurs que pour les comptes de service.

Les problèmes de sécurité ne peuvent pas être corrigés par de simples correctifs si la conception globale du pipeline est faible.

Enfin, les cas d’usage de déploiement doivent être définis clairement dès le départ, car ils influencent directement l’architecture et les choix IAM.

Au-delà des aspects techniques, la sécurité CI/CD doit être évaluée en continu via des audits techniques réguliers ainsi que des revues organisationnelles du cycle de développement afin de maintenir les risques sous contrôle.

Pour une perspective plus large et des recommandations de haut niveau sur le positionnement du CI/CD comme pilier du système d’information, voir l’article RiskInsight : « CI/CD: the new cornerstone of the information system ».

Cet article Sécurité CI/CD : attaque de chaîne d’approvisionnement depuis un développeur compromis est apparu en premier sur RiskInsight.

Le principe de tiering préconisé sur les infrastructures on-premise est-il applicable au cloud ?

Évolution du modèle de sécurité

Dans les environnements on-premise, en particulier Active Directory, la sécurité des infrastructures s’appuie généralement sur une segmentation stricte en trois niveaux (T0, T1 et T2) permettant d’isoler les systèmes d’administration critiques (T0), les serveurs (T1) et les postes utilisateurs (T2) afin de limiter les risques de propagation.

Cette organisation hiérarchique et périmétrique est inhérente au monde AD et ne peut être directement appliquée au cloud pour ces deux principales raisons :

• Les portails sont centralisés: une grande diversité d’administrateurs aux droits différents interagit avec la même URL.
• La frontière entre les niveaux d’administration est complexifiée: le principe de permission fine, par rôle (RBAC), par attribut de ressources (ABAC), selon certaines conditions (provenance, risque, conformité, méthode d’authentification…) permet de configurer des accès très précisément, mais complexifie et floute la vision globale des permissions.

Afin de proposer une réponse à ce nouveau paradigme, Microsoft a publié son Enterprise Access Model (décrit ici), mettant en évidence 3 principaux plans : le Control Plane, Management Plane et Data Plane.

Ce modèle reprend la criticité « en cascade », mais simplifiant :

• les 3 tiers en 2 accès : administrateur vs utilisateur ;
• les flux d’administration en accès au portail ;
• la criticité des serveurs en les centralisant dans le Data plane.

Une illustration de l’ancien et du nouveau modèle :

Ce nouveau modèle met particulièrement en valeur 3 éléments :

• L’identité de l’utilisateur : accès privilégié vs accès utilisateur ;
• La donnée et les services : au détriment des serveurs ;
• La méthode d’accès aux portails web d’administration.

L’inversion des importances entre « serveurs » et « portails web » abstrayant l’Active Directory est un changement radical.

Cependant, très peu (si ce n’est aucune) grande structure en est à ce niveau d’abandon de son SI « legacy », une grande partie sera dans un état transitoire où ce SI aura été virtualisé sur un Cloud afin de se séparer de ses datacenters, mais dont les modalités d’administration sont restées les mêmes.

Ces entreprises doivent donc traiter avec un tiering model désuet et un Enterprise Access Model décoléré des risques et besoins de sécurité actuels.

Pour la suite de cet article, nous prendrons comme exemple la société Tartampion, qui vient de terminer un programme Move-to-Cloud de 3 ans sur AWS. Le bilan est le suivant :

• Une Landing Zone a été créée, les applications déjà sur AWS y ont été intégrées
• Les Data Center ont été fermés
• Pris par le manque de temps et de moyens, une majeure partie du SI a été incorporé en lift and shift, incluant des solutions métiers, réseau, bastion et AD.

Un SI hybride et virtualisé qui pose problème

Selon l’EAM, les portails Azure et AWS sont affichés au même niveau (le management plane) au rang T1, sans autre forme de distinction. Or ces 2 environnements cloud sont à eux seuls le support de nombreux SI, utilisés par de multiples collaborateurs avec des niveaux de droits et d’impacts très variés.

Pour illustrer les précédents propos, mettons de côté l’aspect Digital Workplace (suite O365) et prenons 3 comptes AWS issus d’une Landing Zone de Tartampion, supportant différents services d’infrastructure :

En se fiant au référentiel proposé par Microsoft, ces trois comptes AWS devraient appartenir au Management plane avec un niveau de sécurité T1. Cependant, en cas de compromission d’un des 3 comptes par un attaquant, les impacts seraient très différents.

Si la Landing Zone est correctement implémentée, la compromission d’un compte de Sandbox n’aurait que très peu d’impact, tandis que celle du Master Account entrainerait celle de tous les comptes et ressources sous-jacentes.

Un exemple de découpage plus adéquat serait le suivant :

L’Enterprise Access Model par Microsoft est un framework macroscopique permettant d’initier une base de découpage des services cloud, mais qui reste à adapter selon la criticité des SI concernés.

Comment le rendre pertinent ? Pour répondre, il faut comprendre les scénarios d’attaque exploitant les services cloud.

Le Cloud vu de l’attaquant

5 principes du cloud favorisant les attaques

Premièrement, les infrastructures cloud sont par défaut exposées sur Internet, contrairement aux ressources sensibles d’un SI. Ainsi, un phishing réussi conduit très probablement à un accès sur le Cloud.

Deuxièmement, les entreprises ont aujourd’hui des organisations hybrides (on-premise et cloud) :

• Les infrastructures cloud sont reliées au reste du SI on-premise ;
• Les postes de travail peuvent également être hybrides et gérés par un service cloud comme Intune. Les permissions pour utiliser ce service sont gérées dans Entra ID ;
• Les identités sont souvent des comptes synchronisés, cela concerne également les comptes d’administration.

Les organisations hybrides peuvent faciliter les latéralisations entre le cloud et l’on-premise.

Troisièmement, la gestion des identités est très complexe avec différentes portées. Par exemple, Entra ID permet de gérer les accès à Azure et M365 aussi bien pour des utilisateurs, que des applications que des comptes de service.

Pour compléter, les notions de cybersécurité liées au Cloud sont encore relativement nouvelles et méconnues pour certaines équipes « legacy », comme le SOC/CERT, le réseau… Les ressources cloud les plus sensibles ne sont pas systématiquement identifiées, protégées et surveillées.

Enfin, même si des mécanismes de détection natifs sont présents, ils ne sont pas toujours interconnectés avec les SIEM/SOAR, ce qui ralentit les capacités d’intervention. Une récente opération Purple Team menée sur des infrastructures Azure et AWS a confirmé que les outils de détection natifs ont une capacité de détection limitée. Il s’agit d’un constat retrouvable dans les Red Team puisqu’avec une démarche « OpSec », les outils de détection cloud sont rarement capables d’identifier une attaque en cours.

REX de nos tests d’intrusion & Red Team

Issus des opérations de Red Team menées récemment, ces chemins d’attaques spécifiques aux environnements cloud sont témoin des impacts et des facilités qu’il est possible d’avoir pour s’élever en privilège jusqu’à obtenir des accès très permissifs :

Le premier scénario, effectué sur AWS, est décrit ci-dessous, les deux autres ont été analysés dans une série d’articles Risk Insight disponible ici.

Reconnaissance et Accès initial

Des catégories d’employés sont généralement ciblées afin de compromettre une personne avec des droits intéressants dans le SI (Développeur, Support, OPS…). Un moyen souvent utilisé est d’utiliser du phishing. Les mécanismes de phishing actuel sont capables de contourner l’usage de mots de passe complexe et la plupart des méthodes de MFA (Multi-Factor Authentication).

Escalade de privilèges et mouvements latéraux

Dans le premier scénario, un développeur compromis possédait des accès à une ferme Citrix. Les environnements Citrix ne sont pas simples à durcir complètement et quelques vulnérabilités d’échappement ont permis à la Red Team d’avoir un accès au serveur sous-jacent.

Les informations récoltées sur la machine ont indiqué que le serveur pouvait être hébergé sur AWS. Cela s’est vérifié en essayant d’accéder aux métadonnées AWS du serveur : l’instance avait des droits sur le compte AWS du client. La machine virtuelle du Citrix possédait le rôle « AmazonEC2FullAccess » lui permettant des actions de gestion sur les EC2 du même compte AWS.

À l’aide de la CLI AWS, les autres EC2 ont été listées. Un contrôleur de domaine du client était présent dans ce compte AWS. C’est une pratique courante de vouloir regrouper dans un même compte, généralement appelé « Shared Services », les services qui ont pour vocation d’être utilisés par plusieurs projets. Il est néanmoins recommandé de vérifier que la criticité des services partagés soit homogène de sorte à pouvoir appliquer un durcissement adéquat sur le compte, ou les séparer en plusieurs environnements.

Actions sur les trophées

À partir du rôle AWS du serveur Citrix, une sauvegarde instantanée du contrôleur de domaine a été faite puis téléchargée. Les sauvegardes d’un contrôleur de domaine contiennent tous les fichiers de la machine, y compris les fichiers les plus sensibles, comme la base ntds.dit, qui contient les informations et secrets de tous les utilisateurs du domaine. L’exfiltration de cette base se traduit en la compromission totale du domaine AD concerné.

Ce scénario illustre l’un des chemins d’attaques qui ont été exploités lors des opérations de redteam, facilité par le manque de visibilité sur les impacts que peuvent avoir une ressource compromise hébergée sur le cloud.

Des impacts plus rapides et plus forts

Les attaques déjà possibles sur un SI on-premise peuvent être reproduites et même accélérées grâce aux fonctionnalités du cloud. Par exemple, le chiffrement de buckets S3 (service de stockage de fichiers) à partir d’une clé KMS (de chiffrement) d’un autre compte AWS imite le chiffrement massif de données, ou l’utilisation de la fonctionnalité « lifecycle » permet une suppression de tous les objets en moins de 24 heures, peu importe la quantité de données.

De nouvelles attaques sont également apparues comme le « Hijack de souscription » qui permet de rattacher un abonnement d’une organisation Azure à une autre et ainsi de voler toutes les données qu’il contient et empêcher les actions de remédiation. Cette attaque est réalisable en quelques clics depuis l’interface web Azure.

Identification et protection du cœur de confiance cloud

Identification du Cœur de confiance

Le cœur de confiance adopte une approche centrée sur la priorisation des actifs, qui diffère du modèle de tiering ou de l’Enterprise Access Model de Microsoft. Contrairement à ces modèles qui proposent un découpage prédéfini, il n’existe pas de grille universelle : chaque organisation doit identifier elle-même quelles ressources méritent le plus haut niveau de protection. L’idée est d’établir un cercle restreint de ressources critiques (qu’elles soient cloud ou on-premise) puis de déployer des niveaux de protection dégressifs à mesure que l’on s’éloigne de ce cœur.

L’identification du cœur de confiance repose sur deux grands critères :

• Criticité métier: ce sont les ressources qui concentrent la valeur et la continuité des activités de l’entreprise. Si elles venaient à être perdues ou compromises, les conséquences seraient immédiates pour le fonctionnement quotidien et financièrement. Un environnement SharePoint contenant la donnée intellectuelle / brevets en est un exemple courant ;
• Criticité SI: il s’agit des ressources qui assurent l’administration du système d’information et qui disposent d’un niveau d’accès élevé. Leur compromission aurait un impact majeur sur l’ensemble du SI et permettrait d’avoir l’impact métier précédemment énoncé. On retrouve ici les contrôleurs de domaine ou encore les services d’IAM Cloud comme Entra ID et AWS Identity Center.

Cette cartographie n’est jamais totalement tranchée. Pour certains éléments, la posture à adopter reste plus floue, deux exemples l’illustrent bien :

• L’EDR: élément de sécurité évident d’un SI, systématiquement déployé tant sur les postes de travail que sur les serveurs cloud et on-premise, sa console d’administration est de plus en plus souvent exposée sur internet, et permet d’exécuter des commandes arbitraires sur les équipements qui en sont équipés.
• Les chaînes CICD: un savant, mais complexe agglomérat d’applications s’appelant entre elles, dont l’accès (le gestionnaire de code : GitLab, GitHub…) est offert à l’ensemble des collaborateurs et les droits sur le SI (manipulé par les runners de déploiement) sont bien souvent administrateur de l’ensemble des infrastructures cloud. Sur l’ensemble des Red Team effectués en 2024 & 2025, 80% ont exploité des vulnérabilités associées à ses solutions pour progresser dans leur opération, voire obtenir des trophées de compromission par ce biais.

Afin d’identifier le « noyau dur » du cœur de confiance, qu’on appellera socle de sécurité, on peut reprendre les préceptes de l’ancien T0 : la compromission d’un de ses éléments entrainerait probablement celles des autres, et par cascade de la majeure partie du SI.

En supposant que vos applications appliquent un correct cloisonnement interutilisateur (l’intégralité de vos sites SharePoint n’est pas accessible par tous, n’est-ce pas ?), les références aux prochaines applications seront à comprendre comme des accès administrateurs / super-utilisateurs à ces dernières, et non simple utilisateur.

Voici l’une des représentations possibles pour un cœur de confiance hybride :

Dans cette représentation, il y a côté on-premise :

• Le T0 avec ses contrôleurs de domaine, l’ADCS, et potentiellement la PKI, le bastion, la console EDR…
• Le T1 en intégrant en plus les applications métiers à fort impact.

Et côté Cloud, on retrouve :

• Au cœur le Control Plane (AWS Orga & Identity Center, Entra ID) ainsi que les modules de la Landing Zone supportant le T0 (si une partie du T0 est hébergée dans le Cloud) ;
• En s’éloignant, les diverses consoles d’administration des suites de bureautique, et de management des infrastructures ou des applications.

En établissant ce diagramme, il est important de garder à l’esprit que :

• L’IT sert au métier et quand bien même la zone centrale du cœur de confiance est principalement occupée par des briques techniques, il convient d’inscrire ses solutions critiques ;
• Les chaînes de dépendance / compromission ont beaucoup d’impact sur les choix d’architecture: positionner un AD sur AWS, ou déployer un EDR sur un AD peut soudainement créer de nombreux chemins de compromission et de rebond entre les 2 mondes.

Enfin, la construction d’un cœur de confiance ne peut pas se limiter à une logique de classification statique. Elle doit reposer sur une approche qui évalue la criticité de chaque actif et le risque qu’il introduit (une entreprise de développement de logiciel ne positionnera surement son Git au même niveau qu’une entreprise de travaux public).

Protection du cœur de confiance cloud

La sécurité du cœur de confiance va reposer sur les deux traditionnels facteurs de risques :

• Réduire l’impact: comment empêcher un utilisateur compromis ou malveillant de se connecter aux portails cloud sur un navigateur et de faire des actions sensibles en quelques clics, comme faire une sauvegarde d’un contrôleur de domaine hébergé sur une VM ou supprimer les sauvegardes de données de production ?
• Réduire la probabilité : comment réduire les risques d’accès illégitimes à partir d’un cookie de session volé par phishing, de la compromission d’un poste de travail ou de la réutilisation de mots de passe des utilisateurs ?

Protection du socle de sécurité cloud

Concernant le « socle de sécurité » cloud il est possible de hiérarchiser les environnements par criticité selon cette échelle macroscopique :

En fonction des équipes en charge et de la complexité de les inclure dans un niveau de protection particulièrement élevée, certaines organisations font le choix d’exclure des environnements dont la compromission ne permettrait pas une latéralisation dangereuse, telle que ceux de FinOps, de détection, le Digital Workplace…

La sécurisation du socle de sécurité cloud repose sur 2 principaux points :

• Une hygiène impeccable : configuration IAM épurée, respect du moindre privilège, procédure de déploiement, limitation des ressources au strict nécessaire…
• Une couche de sécurité passive / active : déploiement de politiques (SCP sur AWS, Policy sur Azure) interdisant explicitement certaines actions, ou la manipulation de certaines ressources, et règles de détection afin de lever une alerte en cas de modification d’une politique ou l’occurrence d’un de ses évènements protégés ;

Ces politiques peuvent efficacement être associées à une stratégie de tagging afin d’appliquer, en plus du modèle RBAC (Role Based Access Control) un modèle ABAC (Attribute Based Access Control).

Par exemple il est possible de tagger différentes ressources avec une clé « tiering » et une valeur entre « T0 », « T1 », « T2 » puis de déployer cet ensemble de stratégies :

• Interdire toute action visant une ressource taguée tiering par une identité dont la valeur de son propre tag tiering n’est pas équivalente ;
• Interdire la manipulation de tag tiering, sauf pour un rôle bien précis.

Et voilà comment, en quelques tags et 2 SCP, il est possible de répliquer le tiering model de Microsoft (quelques exceptions peuvent subvenir).

Protections des identités et des accès

Pour protéger les utilisateurs, 3 thématiques de durcissement peuvent être mises en place :

• Identité : avec quel compte l’utilisateur se connecte-t-il aux interfaces d’administration cloud ? Comment les droits sont-ils obtenus ?
• MFA : l’identité est-elle protégée avec une authentification multifactorielle résistante aux attaques de phishing ?
• Provenance: à partir de quelle plateforme l’utilisateur se connecte-t-il aux interfaces d’administration cloud ? La plateforme est-elle managée, et saine ?

Plusieurs niveaux de protection sont envisageables afin de protéger les administrateurs cloud :

Afin de protéger le cœur de confiance restreint, représenté par les triples cadenas, il est recommandé de mettre en œuvre les facteurs d’authentification les plus robustes. Cela inclut l’utilisation d’un compte dédié à l’administration cloud, l’activation d’une authentification multifactorielle physique (exemple : clé de sécurité FIDO2) et le recours à un poste de travail spécifiquement réservé aux opérations sur ce cœur de confiance.

Pour les ressources plus éloignées du centre du cœur de confiance, symbolisées par les doubles cadenas, un niveau de sécurité durci, mais proportionné peut être appliqué, afin de renforcer la protection pour maitriser les coûts et réduire les contraintes excessives aux utilisateurs concernés.

Finalement, les méthodes les plus sécurisées sont également celles qui impliquent le plus de contraintes aux personnes concernées. Il faut maitriser les usages et prendre en compte des situations d’urgence, comme une intervention en astreinte nécessitant des privilèges très élevés.

Répéter les opérations

À l’issue des phases d’identification et de protection, les ressources seront réparties dans les différentes couches du cœur de confiance.

Pour vérifier la bonne implémentation du cœur de confiance, un audit peut être conduit pour vérifier la bonne protection des ressources critiques qui le compose.

Un système d’information est toujours en évolution, mais les deux premières phases auront été faites à un instant t. De nouvelles ressources critiques peuvent être ajoutées, d’autres modifiées, voire supprimées. Il est primordial de refaire une évaluation régulière de son SI et de mettre à jour la répartition des ressources dans le cœur de confiance.

En conclusion, la sécurité des systèmes d’information s’inscrit désormais dans un contexte de complexité croissante et de forte diversification des composants et services d’infrastructures.

Dans ce contexte, il apparaît de plus en plus complexe de définir un modèle de sécurité universel. Certains cadres conservent toute leur pertinence sur des périmètres bien identifiés : le tiering reste une référence pour la sécurisation de l’Active Directory, tout comme l’EAM pour des environnements Cloud fortement centrés sur l’écosystème Microsoft. Néanmoins, ces modèles atteignent rapidement leurs limites dès lors que l’on s’éloigne de ces cas d’usage spécifiques.

Pour la majorité des systèmes d’information, une approche fondée sur l’analyse des risques s’impose donc comme la plus pertinente. Identifier un cœur de confiance, définir clairement les actifs critiques — les crown jewels — et décliner les mesures de sécurité à partir de ces éléments permet de construire une posture de sécurité plus pragmatique, adaptée à la réalité du SI et capable d’évoluer avec lui.

Cette logique, moins normative mais plus contextualisée, constitue sans doute l’un des leviers majeurs pour concilier sécurité, agilité et pérennité des systèmes d’information.

Cet article Sécurité orientée cloud : Adaptation à une nouvelle réalité est apparu en premier sur RiskInsight.