TITRE : Architecture adaptative pour la détection et le confinement de la propagation latérale dans les environnements multi-cloud, fondée sur des graphes de privilèges et une analyse probabiliste

1. Introduction

La transformation numérique accélérée de la dernière décennie a consacré le cloud computing comme infrastructure essentielle pour les services financiers, les systèmes de santé, les télécommunications, l’énergie et l’administration publique. Les modèles Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) et Software-as-a-Service (SaaS) coexistent dans des architectures hybrides et multi-cloud, dans lesquelles les organisations répartissent les charges de travail entre plusieurs fournisseurs afin d’éviter la dépendance technologique, d’optimiser les coûts ou de satisfaire à des exigences réglementaires.

Cependant, cette diversification introduit une complexité structurelle substantielle. Dans les environnements traditionnels on-premises, le périmètre réseau jouait un rôle central dans la segmentation et la défense. En revanche, les environnements cloud adoptent un paradigme orienté identité, dans lequel des politiques déclaratives définissent des permissions fines sur des API programmatiques. Le modèle de responsabilité partagée implique que les mauvaises configurations, les privilèges excessifs et les délégations mal comprises restent sous le contrôle direct du client.

Des rapports largement reconnus, tels que le Data Breach Investigations Report de Verizon, ont constamment identifié l’abus d’identifiants valides comme le vecteur prédominant de compromission. Le framework MITRE ATT&CK documente des techniques telles que Valid Accounts (T1078), Use of Web Application Vulnerabilities pour l’obtention initiale d’accès, ainsi que des techniques ultérieures de Pass-the-Token (T1550) ou Account Manipulation (T1098), qui illustrent la progression latérale après la compromission initiale. La vulnérabilité CVE-2021-44228 (Log4Shell), identifiée dans la bibliothèque Apache Log4j, a montré comment des failles dans des composants largement diffusés peuvent entraîner l’exécution de code à distance et l’exfiltration subséquente de secrets stockés dans des variables d’environnement, incluant fréquemment des clés d’accès à des services cloud.

L’incident impliquant Capital One en 2019, largement analysé dans des rapports publics et dans des procédures judiciaires, a mis en évidence comment des configurations inadéquates de pare-feu d’application web combinées à des permissions excessives sur des services de stockage peuvent permettre une extraction massive de données. Indépendamment des détails spécifiques, le schéma récurrent est clair : l’impact maximal découle non seulement du vecteur initial, mais de la capacité à exploiter des chemins de privilège.

Dans les environnements multi-cloud, la situation est aggravée par des identités fédérées via SAML 2.0 ou OpenID Connect (OIDC), par des rôles assumables (comme AWS STS AssumeRole), des Managed Identities dans Azure et des Service Accounts dans Google Cloud. Les relations de confiance croisées entre comptes et abonnements créent des graphes de délégation qui ne sont pas trivialement visibles à partir d’une seule interface administrative.

Cette réalité soulève des questions fondamentales :

RQ1 : Comment modéliser formellement les relations de privilège et de confiance dans des environnements multi-cloud de manière unifiée et scalable, tout en préservant la sémantique spécifique de chaque fournisseur ?

RQ2 : Est-il possible d’estimer quantitativement — même de façon probabiliste et non déterministe — la probabilité de mouvement latéral réussi à partir d’un point initial compromis ?

RQ3 : Comment réduire la surface d’attaque associée aux chemins critiques de privilège avec un impact minimal sur les opérations légitimes, en respectant les principes de continuité d’activité ?

Nous proposons une architecture qui répond à ces questions en intégrant la théorie des graphes, l’analyse probabiliste et l’optimisation combinatoire sous contraintes opérationnelles. Notre approche se distingue en combinant une modélisation structurelle explicite avec une estimation probabiliste interprétable et des mécanismes adaptatifs de confinement.

2. Background and Related Work

2.1 Graphes d’attaque et modélisation structurelle

La littérature sur les graphes d’attaque remonte à des travaux classiques tels que Ammann, Wijesekera et Kaushik (2002), qui ont proposé des techniques pour la génération scalable de graphes d’attaque (AMMANN; WIJESEKERA; KAUSHIK, 2002). Par la suite, Noel et al. (2009) ont exploré des métriques quantitatives de risque dans les réseaux (NOEL et al., 2009). Ces travaux ont établi les fondements pour représenter des états de système et des transitions exploitables.

Cependant, nombre de ces modèles supposent des environnements réseau relativement statiques et ne capturent pas la nature déclarative et dynamique des politiques IAM dans le cloud. Des outils tels que BloodHound, présentés publiquement par Singla (2016), modélisent les relations de privilège dans Active Directory, permettant l’identification de chemins vers des comptes privilégiés. Bien que conceptuellement similaires, ces approches se concentrent principalement sur les environnements on-premises et n’intègrent pas plusieurs fournisseurs cloud.

2.2 Détection fondée sur l’anomalie et les journaux

Les systèmes de détection d’intrusion (AXELSSON, 2000; SCARFONE; MELL, 2007) ont évolué d’approches fondées sur les signatures vers des méthodes comportementales. Des travaux tels que DeepLog (DU et al., 2017) ont appliqué des réseaux neuronaux récurrents à la modélisation séquentielle des journaux. Dans le contexte cloud, des journaux tels que AWS CloudTrail et Azure Activity Logs sont fréquemment analysés pour détecter des anomalies d’API.

Toutefois, les approches purement comportementales font face à des défis d’interprétabilité et peuvent souffrir d’un taux élevé de faux positifs dans des environnements très dynamiques. De plus, détecter des anomalies n’implique pas nécessairement l’identification des chemins structurels qui rendent possible l’escalade de privilèges.

2.3 Zero Trust et architectures fondées sur l’identité

Le NIST SP 800-207 définit les principes de la Zero Trust Architecture (ROSE et al., 2020), en mettant l’accent sur la vérification continue et le moindre privilège. Le NIST SP 800-53 Rev.5 (NIST, 2020) établit des contrôles de sécurité applicables aux systèmes fédéraux. Toutefois, ces documents fournissent des directives normatives, et non des algorithmes concrets pour l’analyse probabiliste de graphes multi-cloud.

2.4 Lacunes identifiées

À partir de la revue, nous identifions trois lacunes principales :

1. Absence d’un modèle formel unifié incorporant plusieurs fournisseurs tout en conservant la sémantique de délégation.
2. Manque d’intégration entre la structure des privilèges et l’estimation probabiliste de l’exploitation.
3. Rareté de méthodes systématiques pour une mitigation optimisée avec une analyse explicite de l’impact opérationnel.

Notre travail se positionne à l’intersection de ces lacunes.

3. Threat Model and Problem Formalization

3.1 Définitions formelles

Définition 1 (Environnement Multi-Cloud).
Un environnement multi-cloud est modélisé comme un graphe dirigé pondéré $G = (V, E, w, \lambda)$, où :

• $V = V_I \cup V_R$ est l’ensemble des sommets, partitionné en identités $V_I$ et ressources $V_R$ ;
• $E \subseteq V \times V$ est l’ensemble des arêtes représentant des permissions ou des relations de confiance ;
• $w: E \rightarrow (0,1]$ attribue des poids interprétés comme des probabilités conditionnelles d’exploitation ;
• $\lambda: V \rightarrow {AWS, Azure, GCP, …}$ étiquette le fournisseur associé.

Définition 2 (Chemin de Mouvement Latéral).
Un chemin $p = (v_0, v_1, …, v_k)$ est une séquence telle que $(v_i, v_{i+1}) \in E$ pour tout $i$.

En supposant l’indépendance conditionnelle simplificatrice entre les arêtes, le risque accumulé est :

$$ R(p) = \prod_{i=0}^{k-1} w(v_i, v_{i+1}). $$

Nous reconnaissons que l’hypothèse d’indépendance est une approximation ; nous discutons ses limites à la Section 7.

3.2 Modèle d’adversaire

Nous définissons des classes de capacités :

• Classe A1 : Compromission initiale d’une identité valide.
• Classe A2 : Capacité d’énumérer les métadonnées via les API autorisées.
• Classe A3 : Exploitation automatisée de chaînes de délégation.
• Classe A4 : Persistance via la manipulation des politiques (lorsque permis).

Nous n’assumons ni compromission du plan de contrôle du fournisseur ni failles cryptographiques sous-jacentes à TLS ou aux mécanismes de signature.

3.3 Jeu de sécurité

Nous modélisons l’interaction comme un jeu probabiliste :

1. Le défenseur choisit la politique $E$.
2. L’adversaire choisit $v_0 \in V_I$.
3. Le système évolue selon une distribution induite par $w$.

Définition 3 (Nœud Critique).
Un nœud $v$ est critique s’il représente une ressource de grande valeur (par exemple, une base de données sensible).

L’objectif du défenseur est de minimiser :

$$ \Pr[\exists p: v_0 \leadsto v_{crit} \land R(p) \geq \tau]. $$

4. Proposed Methodology

4.1 Architecture générale

L’architecture est composée de :

1. Ingestion des politiques : collecte des politiques IAM, rôles, bindings et relations fédérées.
2. Normalisation sémantique : traduction vers un modèle intermédiaire commun.
3. Construction du graphe : persistance dans une base orientée graphe.
4. Moteur probabiliste : calcul de centralité et de risque via RWR.
5. Mécanisme de mitigation : optimisation sous contraintes.

4.2 Random Walk with Restart (RWR)

Soit $W$ la matrice de transition normalisée telle que :

$$ W_{ij} = \frac{w(j,i)}{\sum_{k} w(j,k)}. $$

Le vecteur de risque $r$ satisfait :

$$ r = (1-\alpha) W^T r + \alpha r_0. $$

Théorème 1 (Convergence).
Pour $0 < \alpha < 1$, l’itération converge vers une solution unique.

Esquisse de la preuve :
La matrice $(1-\alpha)W^T$ a un rayon spectral strictement inférieur à 1, garantissant une contraction dans l’espace normé $\ell_1$.

Complexité par itération : $O(|E|)$.
Nombre d’itérations jusqu’à la convergence $\epsilon$ : $O(\log(1/\epsilon))$ sous les hypothèses usuelles.

4.3 Optimisation de mitigation

Nous formulons :

$$ \min_{\Delta E} |\Delta E| $$

sous contraintes :

$$ r_{crit} < \tau $$

où $r_{crit}$ est la composante de $r$ associée aux nœuds critiques.

Le problème est NP-difficile par réduction au problème de coupe minimale sous multiples contraintes. Nous utilisons une heuristique gloutonne fondée sur la contribution marginale :

Définition 4 (Contribution Marginale).

$$ \Delta_e = r_{crit}^{(E)} - r_{crit}^{(E \setminus {e})}. $$

Nous sélectionnons itérativement les arêtes ayant le plus grand $\Delta_e / C_e$, où $C_e$ représente le coût opérationnel estimé.

Complexité approximative : $O(k|E|)$ pour $k$ suppressions.

5. Implementation

Nous avons implémenté un prototype en Python 3.11. La collecte utilise :

• AWS boto3 (IAM, STS, Organizations).
• Azure SDK for Python (Microsoft Graph, Role Assignments).
• Google Cloud Client Libraries (IAM Policy Bindings).

Le graphe est stocké dans Neo4j, permettant des requêtes Cypher pour l’identification de motifs.

5.1 Pipeline de données

1. Extraction périodique des politiques.
2. Stockage dans un format intermédiaire JSON normalisé.
3. Construction incrémentale du graphe.
4. Exécution asynchrone du RWR.

5.2 Intégration avec les journaux

Journaux pris en charge :

• AWS CloudTrail.
• Azure Activity Logs.
• Google Cloud Audit Logs.

Exemple de règle Sigma pour la détection d’un AssumeRole inhabituel :

title: AWS AssumeRole from Unusual IP
logsource:
  product: aws
  service: cloudtrail
detection:
  selection:
    eventName: AssumeRole
  condition: selection
level: medium

Exemple de signature Suricata pour la détection d’une exploitation Log4Shell (simplifiée) :

alert http any any -> any any (msg:"Possible Log4Shell Exploit"; content:"${jndi:"; nocase; sid:100001;)

Exemple de règle YARA pour identifier des artefacts d’outils d’énumération IAM :

rule IAM_Enum_Tool
{
    strings:
        $s1 = "iam:ListRoles"
        $s2 = "iam:ListUsers"
    condition:
        any of ($s)
}

Ces mécanismes complètent l’analyse structurelle.

5.3 Considérations de déploiement

• Exécution sur cluster Kubernetes.
• Segmentation par fournisseur.
• Contrôle d’accès au graphe lui-même (principe du moindre privilège).
• Journaux immuables stockés dans un espace de stockage avec versionnement.

6. Experimental Evaluation

Afin d’éviter des affirmations non vérifiables, nous présentons une évaluation méthodologique fondée sur des scénarios contrôlés.

6.1 Méthodologie

Nous avons construit des environnements de test sur plusieurs fournisseurs avec :

• des comptes isolés pour l’expérimentation ;
• des politiques délibérément configurées avec différents niveaux de privilège ;
• l’injection contrôlée de scénarios de mauvaise configuration (par exemple, des rôles largement assumables).

Baselines comparés qualitativement :

• outils natifs d’analyse d’accès (AWS IAM Access Analyzer) ;
• revue manuelle fondée sur les bonnes pratiques du NIST SP 800-53.

6.2 Métriques

• Nombre relatif de chemins critiques identifiés.
• Réduction en pourcentage des arêtes à haut risque après mitigation.
• Impact opérationnel mesuré par des échecs dans des tests automatisés de workloads.

Nous observons, de manière constante, que la priorisation probabiliste permet d’identifier un sous-ensemble réduit d’arêtes dont la suppression réduit significativement la connectivité vers les nœuds critiques, par rapport à des approches purement fondées sur la correspondance de motifs.

6.3 Analyse de scalabilité

La construction du graphe croît linéairement avec $|E|$. Dans des expériences internes contrôlées, le temps d’exécution du RWR a présenté un comportement approximativement linéaire par rapport au nombre d’arêtes, cohérent avec la complexité théorique.

7. Case Studies

7.1 Secteur financier

Dans un environnement représentatif d’une institution financière avec plusieurs comptes séparés par domaine d’activité, nous avons identifié des chaînes impliquant :

1. Compromission d’un compte de développeur.
2. Assumption d’un rôle d’intégration CI/CD.
3. Accès à un bucket contenant des artefacts de déploiement.
4. Extraction d’identifiants intégrés dans une configuration héritée.

En appliquant la mitigation, nous avons restreint la confiance cross-account et appliqué des conditions fondées sur l’origine réseau.

7.2 Secteur de la santé

Dans une organisation de santé avec des charges de travail sur Azure et GCP :

• Managed Identity avec de larges permissions sur la base de données.
• Fédération OIDC avec un fournisseur externe.

Le modèle a identifié un chemin potentiel vers des données sensibles. La mitigation a impliqué la segmentation des rôles et l’application de politiques conditionnelles fondées sur les attributs de l’appareil.

8. Discussion

La modélisation structurelle probabiliste offre un avantage interprétable par rapport aux méthodes purement statistiques. Toutefois, les limitations incluent :

• l’hypothèse d’indépendance des arêtes ;
• la difficulté d’estimer avec précision les poids $w$ ;
• une possible explosion combinatoire dans des environnements extrêmement vastes.

Comparativement aux graphes d’attaque classiques, notre modèle incorpore explicitement la sémantique d’identité fédérée multi-cloud.

Pour les praticiens, la principale implication est la nécessité d’une visibilité globale et d’une normalisation sémantique. Pour les chercheurs, cela ouvre un agenda impliquant la vérification formelle des politiques IAM à l’aide de techniques de model checking et l’intégration avec la cryptographie appliquée pour la preuve d’intégrité des journaux.

9. Conclusion and Future Work

Nous avons présenté une architecture adaptative pour la détection et le confinement du mouvement latéral dans des environnements multi-cloud, fondée sur des graphes de privilèges et l’analyse probabiliste. Nous avons formalisé le modèle de menace, démontré la convergence mathématique de l’algorithme de risque et discuté une heuristique de mitigation sous contraintes opérationnelles.

Comme agenda futur, nous proposons :

1. L’intégration avec la vérification formelle (par exemple, la traduction des politiques IAM en logique temporelle et l’utilisation du model checking).
2. L’estimation bayésienne des poids $w$ fondée sur des données historiques.
3. L’utilisation de l’optimisation robuste en tenant compte de l’incertitude adversariale.
4. L’incorporation de l’apprentissage par renforcement avec des garanties formelles de sécurité.
5. Une évaluation à grande échelle avec collaboration interinstitutionnelle.

Nous pensons que la convergence entre théorie formelle, analyse probabiliste et pratiques opérationnelles est essentielle pour faire face à la complexité croissante des environnements multi-cloud.

References

AMMANN, P.; WIJESEKERA, D.; KAUSHIK, S. Scalable, graph-based network vulnerability analysis. In: ACM CCS, 2002. Available at: https://dl.acm.org/doi/10.1145/586110.586145

AXELSSON, S. Intrusion detection systems: A survey and taxonomy. Technical Report, Chalmers University, 2000. Available at: https://www.cse.chalmers.se/~svenaxel/publications/

DU, M. et al. DeepLog: Anomaly Detection and Diagnosis from System Logs. In: ACM CCS, 2017. Available at: https://dl.acm.org/doi/10.1145/3133956.3134015

NIST. Security and Privacy Controls for Information Systems and Organizations (SP 800-53 Rev.5), 2020. Available at: https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final

NOEL, S. et al. Measuring security risk of networks using attack graphs. IEEE Security & Privacy, 2009. Available at: https://ieeexplore.ieee.org/document/4812701

ROSE, S. et al. Zero Trust Architecture (SP 800-207). NIST, 2020. Available at: https://csrc.nist.gov/publications/detail/sp/800-207/final

SINGLA, A. BloodHound. Black Hat USA, 2016. Available at: https://www.blackhat.com/docs/us-16/materials/us-16-Singla-BloodHound.pdf

SCARFONE, K.; MELL, P. Guide to Intrusion Detection and Prevention Systems (SP 800-94). NIST, 2007. Available at: https://csrc.nist.gov/publications/detail/sp/800-94/final

VERIZON. 2023 Data Breach Investigations Report. Available at: https://www.verizon.com/business/resources/reports/dbir/

MITRE. ATT&CK Framework. Available at: https://attack.mitre.org/

ARMBRUST, M. et al. A view of cloud computing. Communications of the ACM, 2010. Available at: https://dl.acm.org/doi/10.1145/1721654.1721672

ENISA. Cloud Security Risk Assessment, 2022. Available at: https://www.enisa.europa.eu/publications

ISO/IEC. 27017:2015 Information technology — Security techniques — Code of practice for information security controls based on ISO/IEC 27002 for cloud services. Available at: https://www.iso.org/standard/43757.html

KATZ, J.; LINDELL, Y. Introduction to Modern Cryptography. CRC Press, 2014. Available at: https://www.cs.umd.edu/~jkatz/imc.html