Cloud de confiance : le piège de la preuve négative

Démonstration pédagogique des risques structurels

Kernel, librairies, attaques dormantes, télémétrie de facturation, chaîne de dépendance systémique

---

AVANT DE COMMENCER : Guide de lecture pour les non-techniciens

Note sur le format : Ce document adopte un style factuel et technique. Les encadrés intitulés "L'ESSENTIEL À RETENIR" (avec emojis) offrent des résumés simplifiés pour les lecteurs non-spécialistes. Les experts peuvent les ignorer sans perdre d'information.

Pourquoi ce document vous concerne

Même si vous n'êtes pas informaticien, les décisions concernant le cloud impactent directement :

• La continuité de votre activité : Que se passe-t-il si vos outils cessent de fonctionner ?
• La confidentialité de vos données : Qui peut réellement y accéder ?
• Votre conformité légale : Êtes-vous en règle avec le RGPD ?
• Votre indépendance stratégique : Dépendez-vous d'un fournisseur étranger ?

Le cloud expliqué simplement

Qu'est-ce que le cloud ?

Imaginez que vous louiez un appartement au lieu d'acheter une maison :

• Vous ne possédez pas les murs (les serveurs)
• Vous payez un loyer mensuel (abonnement)
• Le propriétaire s'occupe de l'entretien (maintenance)
• Mais le propriétaire a les clés et décide des règles

Le cloud, c'est pareil : au lieu d'avoir vos propres ordinateurs (serveurs), vous louez de la puissance informatique à une entreprise qui possède d'immenses centres de données.

Les trois géants du cloud (les "hyperscalers")

Source : Synergy Research Group, T3 2024. Parts de marché du cloud IaaS/PaaS mondial.

Le constat : Plus de 65% du marché mondial du cloud est contrôlé par trois entreprises américaines, soumises aux lois américaines (CLOUD Act, FISA).

Les concepts clés en 2 minutes

Backdoor (porte dérobée)

Analogie : Une porte cachée dans votre maison dont vous ignorez l'existence, mais que le constructeur connaît.

En informatique : Un accès secret permettant d'entrer dans un système sans passer par la porte principale (mot de passe, authentification).

Le problème : Dans un logiciel fermé, vous ne pouvez pas vérifier s'il existe des portes dérobées.

Kill switch (interrupteur d'arrêt)

Analogie : Le fournisseur d'électricité peut couper votre courant à distance.

En informatique : La capacité d'un éditeur à désactiver ses logiciels ou services, où qu'ils soient dans le monde.

Exemple concret : En 2022, Microsoft, Oracle et SAP ont suspendu leurs services en Russie en quelques jours.

Code propriétaire vs Open source

La pile technique (ou "stack")

Imaginez un immeuble avec plusieurs étages. Chaque étage dépend de celui du dessous :

```json { "type": "flowchart", "metadata": { "title": "La pile technique cloud : qui contrôle quoi ?", "description": "Chaque couche dépend de celle du dessous. Le fournisseur cloud contrôle les étages inférieurs.", "height": 380 }, "data": { "nodes": [ {"id": "app", "label": "Vos applications", "color": "green"}, {"id": "os", "label": "Système d'exploitation", "color": "yellow"}, {"id": "hyper", "label": "Hyperviseur", "color": "orange"}, {"id": "firm", "label": "Firmware / Matériel", "color": "red"} ], "edges": [ {"from": "app", "to": "os", "label": "Visible"}, {"from": "os", "to": "hyper", "label": "Invisible"}, {"from": "hyper", "to": "firm", "label": "Fournisseur"} ] } } ```

Le problème : Vous ne contrôlez que l'étage du haut (vert). Les étages inférieurs (jaune, orange, rouge) sont entre les mains du fournisseur cloud.

Les lois qui posent problème

CLOUD Act (États-Unis, 2018)

Ce que dit la loi : Le gouvernement américain peut exiger l'accès aux données stockées par une entreprise américaine, même si ces données sont physiquement en Europe.

Conséquence : Vos données chez Microsoft Azure (même dans un datacenter parisien) peuvent être réclamées par les autorités américaines.

RGPD (Europe, 2018)

Ce que dit le règlement : Les données personnelles des Européens doivent être protégées. Leur transfert hors UE est encadré.

Le conflit : CLOUD Act et RGPD sont contradictoires. Un fournisseur américain ne peut pas respecter les deux en même temps.

Comment lire ce document

L'essentiel à retenir avant de continuer

```json { "type": "swot", "metadata": { "title": "Ce qu'il faut comprendre en 4 points", "description": "Les fondamentaux avant d'aller plus loin" }, "data": { "strengths": [ "Le cloud offre flexibilité, puissance et économies d'échelle", "Les grands fournisseurs investissent massivement dans la sécurité", "Des alternatives européennes émergent et se structurent" ], "weaknesses": [ "Le code fermé empêche toute vérification indépendante", "Les lois américaines s'appliquent aux éditeurs US, où que soient vos données", "Les couches techniques profondes échappent à votre contrôle" ], "opportunities": [ "Les offres 'de confiance' (S3NS, Bleu) réduisent certains risques", "L'open source permet l'audit et la maîtrise", "La réglementation européenne pousse vers plus de souveraineté" ], "threats": [ "Un conflit géopolitique peut entraîner des suspensions de service", "Les réquisitions légales américaines sont secrètes", "La dépendance technique crée une vulnérabilité stratégique" ] } } ```

---

SYNTHÈSE EXÉCUTIVE (1 page)

5 constats clés

3 risques majeurs

RISQUE 1 : INTERRUPTION DE SERVICE (Kill switch)

RISQUE 2 : ACCÈS NON AUTORISÉ AUX DONNÉES (Backdoor/Exfiltration)

RISQUE 3 : NON-CONFORMITÉ RÉGLEMENTAIRE

3 options de décision

Arbre de décision simplifié

```json { "type": "flowchart", "metadata": { "title": "Arbre de décision simplifié", "description": "Orientation stratégique selon la criticité des données", "height": 520 }, "data": { "nodes": [ {"id": "q1", "label": "Données critiques ?", "color": "orange"}, {"id": "oui1", "label": "OUI", "color": "gray"}, {"id": "non1", "label": "NON", "color": "gray"}, {"id": "basculer1", "label": "BASCULER", "color": "green"}, {"id": "q2", "label": "Besoin justifie le risque ?", "color": "orange"}, {"id": "oui2", "label": "OUI", "color": "gray"}, {"id": "non2", "label": "NON", "color": "gray"}, {"id": "attenuer", "label": "ATTÉNUER", "color": "blue"}, {"id": "basculer2", "label": "BASCULER", "color": "green"} ], "edges": [ {"from": "q1", "to": "oui1", "label": ""}, {"from": "q1", "to": "non1", "label": ""}, {"from": "oui1", "to": "basculer1", "label": "Souverain"}, {"from": "non1", "to": "q2", "label": ""}, {"from": "q2", "to": "oui2", "label": ""}, {"from": "q2", "to": "non2", "label": ""}, {"from": "oui2", "to": "attenuer", "label": "Cloud de confiance"}, {"from": "non2", "to": "basculer2", "label": "Souverain"} ] } } ```

Message clé

La question n'est pas "Y a-t-il une backdoor ?" mais "Pouvons-nous vérifier qu'il n'y en a pas ?"

Dans une architecture fermée, la réponse est structurellement : non.

Ce constat ne constitue pas une accusation mais un fait technique. La décision appartient au responsable, en fonction de la sensibilité des données et de l'acceptabilité du risque résiduel.

---

Avertissement méthodologique

Ce document analyse des possibilités structurelles, non des faits avérés d'exploitation. La distinction est fondamentale :

• Possibilité structurelle : capacité technique ou juridique existante, documentée, qui pourrait être utilisée
• Exploitation avérée : utilisation effective, prouvée, de cette capacité

L'objectif est d'éclairer les décideurs sur les risques inhérents aux architectures fermées, en distinguant clairement :

• Ce qui est démontrable techniquement
• Ce qui est plausible juridiquement
• Ce qui relève de l'évaluation qualitative

Les scores et pourcentages présentés dans les visualisations sont des indices qualitatifs à vocation pédagogique, construits selon la méthodologie décrite en Annexe D. Ils ne prétendent pas à une précision quantitative absolue.

---

Résumé exécutif

Ce document analyse comment une offre cloud reposant sur des briques propriétaires soumises à une juridiction étrangère peut, par construction, intégrer des mécanismes de contrôle non vérifiables par le client.

Thèse centrale : La question pertinente n'est pas "Y a-t-il une backdoor ?" mais "Le client dispose-t-il des moyens techniques et juridiques de vérifier qu'il n'y en a pas ?". Dans une architecture fermée, cette capacité de vérification est structurellement limitée.

Ce que ce document affirme :

• Les architectures fermées présentent des points de contrôle potentiels non auditables
• Le cadre juridique américain permet des obligations de coopération secrètes
• La capacité de vérification du client est asymétrique par rapport au contrôle de l'éditeur

Ce que ce document n'affirme pas :

• Que des backdoors sont effectivement présentes dans les offres citées
• Que les éditeurs américains agissent de mauvaise foi
• Que les offres "de confiance" n'apportent aucune valeur ajoutée

```json { "type": "flowchart", "metadata": { "title": "Chaîne de dépendance d'une offre cloud basée sur code propriétaire étranger", "description": "Flux de contrôle potentiel depuis l'éditeur jusqu'aux systèmes client", "height": 480 }, "data": { "nodes": [ {"id": "editeur", "label": "Éditeur US/étranger", "color": "red"}, {"id": "code", "label": "Code propriétaire", "color": "orange"}, {"id": "licence", "label": "Serveurs de licence", "color": "orange"}, {"id": "maj", "label": "Mises à jour", "color": "orange"}, {"id": "operateur", "label": "Opérateur local (FR)", "color": "yellow"}, {"id": "hyperviseur", "label": "Hyperviseur", "color": "blue"}, {"id": "agents", "label": "Agents / SDK", "color": "blue"}, {"id": "vm", "label": "Machines virtuelles", "color": "green"}, {"id": "client", "label": "Données client", "color": "green"} ], "edges": [ {"from": "editeur", "to": "code", "label": ""}, {"from": "editeur", "to": "licence", "label": ""}, {"from": "editeur", "to": "maj", "label": ""}, {"from": "code", "to": "operateur", "label": ""}, {"from": "licence", "to": "operateur", "label": ""}, {"from": "maj", "to": "operateur", "label": ""}, {"from": "operateur", "to": "hyperviseur", "label": ""}, {"from": "operateur", "to": "agents", "label": ""}, {"from": "hyperviseur", "to": "vm", "label": ""}, {"from": "agents", "to": "vm", "label": ""}, {"from": "vm", "to": "client", "label": ""} ] } } ```

---

Partie I : Fondements conceptuels

1.1 Définitions essentielles

Backdoor

Une backdoor est un mécanisme intentionnel ou structurel permettant un accès, une action ou un contournement de contrôle en dehors des mécanismes documentés et auditables par le client.

Une backdoor n'est pas nécessairement malveillante :

• elle peut être contractuelle (clause d'accès pour maintenance),
• imposée par la loi (réquisition judiciaire),
• ou simplement non vérifiable faute d'accès au code source.

Kill switch

Un kill switch est une capacité technique permettant d'interrompre, dégrader ou neutraliser un système à distance :

• révocation de licence logicielle,
• invalidation de certificat,
• arrêt de service cloud,
• désactivation de fonctionnalités.

Distinction importante : Un kill switch peut être légitime (protection anti-piratage, conformité contractuelle) ou problématique (usage géopolitique, extraterritorialité).

L'ESSENTIEL À RETENIR : Les 3 concepts clés

Concept	Analogie simple	Exemple concret
Backdoor	Une porte cachée dans votre maison, dont seul le constructeur a la clé	Un accès administrateur secret dans un logiciel
Kill switch	La compagnie d'électricité peut couper votre courant à distance	Microsoft suspend les licences Office en Russie (2022)
Attaque dormante	Une bombe à retardement cachée dans les fondations	Le virus Stuxnet, inactif pendant des mois avant de frapper

🔑 Le point commun : Dans tous les cas, quelqu'un d'autre que vous a un pouvoir sur votre système.

Attaque dormante

Une attaque dormante est une logique implantée dans un système qui :

• reste inactive pendant une période indéterminée,
• ne produit aucun signal détectable durant cette phase,
• se déclenche uniquement sur condition spécifique.

1.2 Taxonomie des mécanismes de contrôle

```json { "type": "radar", "metadata": { "title": "Vecteurs de contrôle externe par couche technique", "description": "Évaluation qualitative : Faible (0-30), Moyen (30-60), Élevé (60-80), Très élevé (80-100). Voir Annexe D pour méthodologie.", "height": 450 }, "data": { "labels": ["Kernel/OS", "Hyperviseur", "Firmware/UEFI", "Agents/SDK", "Licences", "Mises à jour", "Télémétrie", "Certificats"], "datasets": [ { "label": "Offre cloud propriétaire étrangère", "values": [70, 90, 85, 90, 95, 95, 80, 85] }, { "label": "Offre souveraine open source", "values": [25, 30, 55, 20, 15, 25, 15, 35] } ] }, "config": { "palette": "corporate" } } ```

Légende des scores (voir Annexe D pour détails) :

• 0-30 (Faible) : Contrôle externe limité, audit possible
• 30-60 (Moyen) : Contrôle externe partiel, audit difficile
• 60-80 (Élevé) : Contrôle externe significatif, audit très limité
• 80-100 (Très élevé) : Contrôle externe quasi-total, audit impossible

---

Partie II : Le principe d'asymétrie de vérifiabilité

2.1 Axiome fondamental

Ce qui n'est pas accessible en source n'est pas intégralement auditable.

Dans une offre cloud basée sur du code propriétaire, le client fait confiance à :

• du code qu'il ne peut pas lire intégralement,
• compilé par un tiers selon un processus non vérifiable,
• exécuté avec des privilèges élevés,
• mis à jour selon des modalités définies par l'éditeur.

Cette asymétrie informationnelle constitue la racine structurelle du problème analysé.

Nuance importante : Cela ne signifie pas que le code est malveillant, mais que le client n'a pas les moyens de le vérifier de manière indépendante.

2.2 Matrice d'asymétrie informationnelle

2.3 Le problème de la preuve négative

```json { "type": "flowchart", "metadata": { "title": "Capacité de vérification selon le type d'architecture", "description": "Différence structurelle entre architectures ouverte et fermée", "height": 420 }, "data": { "nodes": [ {"id": "question", "label": "Vérification possible ?", "color": "orange"}, {"id": "code_ferme", "label": "Architecture fermée", "color": "red"}, {"id": "code_ouvert", "label": "Architecture ouverte", "color": "green"}, {"id": "audit_limite", "label": "Audit limité", "color": "orange"}, {"id": "audit_complet", "label": "Audit complet", "color": "green"}, {"id": "confiance", "label": "Confiance requise", "color": "orange"}, {"id": "verification", "label": "Vérification possible", "color": "green"}, {"id": "risque_residuel", "label": "Risque non quantifiable", "color": "red"}, {"id": "risque_maitrise", "label": "Risque gérable", "color": "green"} ], "edges": [ {"from": "question", "to": "code_ferme", "label": "Propriétaire"}, {"from": "question", "to": "code_ouvert", "label": "Open source"}, {"from": "code_ferme", "to": "audit_limite", "label": ""}, {"from": "code_ouvert", "to": "audit_complet", "label": ""}, {"from": "audit_limite", "to": "confiance", "label": "Seule option"}, {"from": "audit_complet", "to": "verification", "label": ""}, {"from": "confiance", "to": "risque_residuel", "label": ""}, {"from": "verification", "to": "risque_maitrise", "label": ""} ] } } ```

Conclusion logique : Dans un système fermé, l'évaluation du risque repose sur la confiance accordée à l'éditeur et au cadre juridique qui le contraint, non sur une vérification technique indépendante.

---

Partie III : Cartographie des points de contrôle techniques

3.1 Architecture des niveaux de privilège x86

Les processeurs modernes organisent l'exécution du code en "rings" (anneaux) de privilège. Cette hiérarchie détermine les capacités de contrôle de chaque couche.

```json { "type": "bar", "metadata": { "title": "Niveaux de privilège x86 : contrôle éditeur vs visibilité client", "description": "Évaluation qualitative. Scores indicatifs, voir Annexe D.", "height": 400 }, "data": { "labels": ["Ring -3 (ME/PSP)", "Ring -2 (SMM)", "Ring -1 (Hyperviseur)", "Ring 0 (Kernel)", "Ring 3 (Applications)"], "datasets": [ { "label": "Contrôle potentiel éditeur (%)", "values": [95, 90, 95, 75, 55] }, { "label": "Visibilité client (%)", "values": [5, 10, 15, 45, 85] } ] }, "config": { "palette": "sunset" } } ```

Légende des rings :

3.2 Le kernel : ring 0

Le kernel s'exécute avec les privilèges maximaux du système d'exploitation.

Vecteurs de contrôle potentiel :

• Modules binaires fermés (pilotes propriétaires)
• Correctifs appliqués par l'opérateur non publiés
• Différence entre code source public et binaire exécuté

Nuance : Sur un système Linux standard, le kernel principal est open source. Les risques concernent principalement les modules additionnels propriétaires et la vérification que le binaire correspond au source.

3.3 Firmware et microcode : ring -2 et -3

Intel Management Engine et AMD PSP

Ces sous-systèmes ont fait l'objet d'analyses par des chercheurs en sécurité. Les principales conclusions rapportées sont :

Intel ME (selon les analyses de Positive Technologies, 2017, et d'autres chercheurs) :

• Processeur séparé avec son propre environnement d'exécution
• Basé sur un système d'exploitation de type Minix (rapporté par plusieurs analyses de firmware)
• Accès aux ressources système via DMA
• Vulnérabilités documentées (voir Annexe E pour références CVE)

Implication pour l'analyse : Ces sous-systèmes constituent des points de contrôle potentiels hors de portée de l'OS principal. Leur code n'est pas auditable par le client.

```json { "type": "flowchart", "metadata": { "title": "Architecture simplifiée des sous-systèmes de gestion", "description": "Représentation conceptuelle des capacités d'accès (Intel ME / AMD PSP)", "height": 450 }, "data": { "nodes": [ {"id": "alimentation", "label": "Alimentation secteur", "color": "gray"}, {"id": "veille", "label": "Alimentation veille", "color": "orange"}, {"id": "me", "label": "Sous-système de gestion", "color": "red"}, {"id": "ram", "label": "Accès mémoire possible", "color": "orange"}, {"id": "nic", "label": "Accès réseau possible", "color": "orange"}, {"id": "cpu", "label": "CPU principal", "color": "blue"}, {"id": "os", "label": "OS client", "color": "green"}, {"id": "opaque", "label": "Non visible par l'OS", "color": "darkRed"} ], "edges": [ {"from": "alimentation", "to": "veille", "label": "Permanent"}, {"from": "veille", "to": "me", "label": "Alimente"}, {"from": "me", "to": "ram", "label": "Via DMA"}, {"from": "me", "to": "nic", "label": "Selon config"}, {"from": "cpu", "to": "os", "label": "Exécute"}, {"from": "os", "to": "opaque", "label": "Ne voit pas ME"} ] } } ```

L'ESSENTIEL À RETENIR : Le firmware

🔑 En termes simples : Le firmware, c'est comme le système nerveux d'un ordinateur. Il existe un "mini-ordinateur dans l'ordinateur" (Intel ME ou AMD PSP) qui :

• Fonctionne même quand votre PC semble éteint
• Peut accéder à tout ce qui est en mémoire
• N'est pas visible par Windows ou Linux
• Ne peut pas être inspecté par le client

🎯 Pourquoi c'est important : Ce système est contrôlé par le fabricant de la puce (Intel ou AMD). Dans un cloud, vous ne savez pas ce qui s'y passe.

Références : Les analyses techniques détaillées sont disponibles …