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 :

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

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é

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

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

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

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.

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.

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 …