CompTIA SY0-701: Sécurité du Cloud, de la virtualisation et des conteneurs — Guide d'étude

By Laurynas Brazys · 20 July 2026 · #comptia #sy0-701 #certification #exam-prep #study-guide

Fait partie du CompTIA Security+ SY0-701 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens CompTIA, ou passez des tests chronométrés sur ExamRoll.io.

Les entreprises modernes opèrent rarement dans un seul centre de données autonome. Les charges de travail s’étendent sur des fournisseurs de cloud public, des clusters de virtualisation privés, des orchestrateurs de conteneurs et des fonctions serverless éphémères. Chaque couche d’abstraction modifie le modèle de menace, la surface de contrôle et, point essentiel, qui est responsable de quels contrôles de sécurité.

Le modèle de responsabilité partagée

Chaque grand fournisseur de cloud publie un modèle de responsabilité partagée qui répartit les tâches de sécurité entre le client et le fournisseur de services cloud (CSP). La ligne de démarcation se déplace en fonction du niveau de service.

Dans le modèle Infrastructure as a Service (IaaS) — Amazon EC2, Azure Virtual Machines, Google Compute Engine — le CSP sécurise les installations physiques, le matériel, l’hyperviseur et la structure réseau. Tout ce qui se trouve au-dessus de l’hyperviseur appartient au client : le système d’exploitation invité, l’application des correctifs, les pare-feu basés sur l’hôte, le middleware, l’environnement d’exécution, le code applicatif, la configuration de l’identité et les données elles-mêmes. Si une entreprise déploie une base de données MySQL sur une instance EC2, la sécurisation de cette base de données relève entièrement de la responsabilité du client.

Dans le modèle Platform as a Service (PaaS) — AWS RDS, Azure App Service, Google App Engine — le fournisseur gère en plus le système d’exploitation, l’application des correctifs au moteur de base de données et l’environnement d’exécution. Le client reste responsable du code applicatif, de la classification des données, des contrôles d’accès, des règles d’exposition réseau et de la gestion des identités.

Dans le modèle Software as a Service (SaaS) — Microsoft 365, Salesforce, Workday — le fournisseur gère la quasi-totalité de la pile. Les responsabilités restantes du client ne sont pas négligeables : provisionnement et déprovisionnement des comptes, application du MFA, classification des données, autorisations de partage, configuration DLP et intégration avec le fournisseur d’identité de l’entreprise. Un site SharePoint mal configuré qui expose des données de paie à « Tout le monde » n’est pas une faille de Microsoft, mais celle de l’administrateur du locataire (tenant).

Une idée fausse persistante est que la migration vers le cloud transfère toute la responsabilité de la sécurité au fournisseur. Les violations de données impliquant des buckets S3 mal configurés, des clusters Elasticsearch exposés et des clés d’API divulguées remontent presque universellement à des erreurs côté client, et non à une compromission du CSP.

Virtualisation et risque lié à l’hyperviseur

La virtualisation regroupe le matériel physique en invités logiques à l’aide d’un hyperviseur. Les hyperviseurs de Type 1 (bare-metal) tels que VMware ESXi, Microsoft Hyper-V et KVM s’exécutent directement sur le matériel. Les hyperviseurs de Type 2 (hébergés) comme VirtualBox s’exécutent sur un système d’exploitation à usage général et ne sont pas adaptés aux charges de travail de production.

Les menaces dominantes spécifiques à la virtualisation sont l’évasion de VM (VM escape) et la compromission de l’hyperviseur. L’évasion de VM se produit lorsqu’un code malveillant à l’intérieur d’un invité sort de sa limite de virtualisation et s’exécute sur l’hyperviseur ou sur une VM adjacente. Les exemples historiques incluent CVE-2015-3456 (VENOM, dans le contrôleur de disquette de QEMU) et diverses vulnérabilités des VMware Tools. Parce qu’un seul hyperviseur peut héberger des centaines de charges de travail sur plusieurs zones de confiance, une évasion réussie offre un accès disproportionné.

Les mesures d’atténuation incluent l’application rigoureuse des correctifs de l’hyperviseur, la minimisation des ajouts invités et du matériel émulé inutilisé, la séparation des charges de travail par sensibilité sur des clusters distincts et l’isolement du plan de gestion (management plane). Le serveur vCenter, les interfaces de gestion ESXi et les API du cluster doivent résider sur un réseau de gestion dédié, accessible uniquement depuis des hôtes de rebond (jump hosts) privilégiés avec MFA.

Les préoccupations supplémentaires incluent la prolifération de VM (VM sprawl) (des VM orphelines et non corrigées qui s’accumulent avec le temps) et la réutilisation des ressources (resource reuse) où la mémoire ou le stockage d’une VM déclassée n’est pas correctement remis à zéro avant d’être alloué à un autre locataire.

Conteneurs, microservices et partage du noyau

Les conteneurs empaquettent une application avec ses dépendances mais, contrairement aux VM, partagent le noyau du système d’exploitation hôte. Docker, containerd et CRI-O gèrent les cycles de vie des conteneurs ; Kubernetes les orchestre à grande échelle. Cet isolement léger est une fonctionnalité — démarrage en millisecondes, densification élevée — mais aussi le risque principal.

L’isolement des conteneurs n’est pas équivalent à l’isolement des VM. Une vulnérabilité du noyau exploitée depuis un conteneur peut compromettre l’hôte et tous les autres conteneurs qui s’y trouvent. Les namespaces (PID, network, mount, UTS, IPC, user) et les cgroups fournissent un isolement, mais ce sont des constructions logicielles partageant une seule surface d’attaque.

La sécurité des conteneurs nécessite des contrôles tout au long du pipeline :

# Example: Pod security context enforcing hardening
securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]
  seccompProfile:
    type: RuntimeDefault

Les images doivent être scannées pour détecter les vulnérabilités avant le déploiement (Trivy, Snyk, Clair), construites à partir d’images de base minimales (distroless ou Alpine), et tirées uniquement de registres de confiance avec la signature d’image appliquée (Cosign, Notary). Les outils de protection à l’exécution (Falco, Aqua, Sysdig) surveillent le comportement des conteneurs et alertent en cas d’anomalies telles que l’exécution de processus inattendus ou des connexions réseau imprévues.

Posture de sécurité du cloud et IAM

Le service IAM du cloud diffère d’Active Directory sur site sur des points importants. Dans AWS, les politiques IAM sont des documents JSON attachés à des utilisateurs, des groupes ou des rôles, et la permission effective est l’intersection des politiques basées sur l’identité et des politiques basées sur les ressources, un refus explicite l’emportant toujours :

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject"],
    "Resource": "arn:aws:s3:::company-data/*",
    "Condition": {
      "StringEquals": {"aws:RequestedRegion": "us-east-1"}
    }
  }]
}

Les outils de gestion de la posture de sécurité du cloud (CSPM) scannent en continu les configurations cloud par rapport à des référentiels de sécurité (CIS AWS Foundations, NIST), signalant les buckets S3 publics, les groupes de sécurité trop permissifs, la journalisation CloudTrail désactivée et les volumes EBS non chiffrés. Les courtiers en sécurité d’accès au cloud (CASB) se placent entre les utilisateurs et les services cloud, appliquant la DLP, les politiques d’accès et la détection des menaces pour les applications SaaS.

Scénario pratique : Mauvaise configuration d’un bucket S3 exposant des données personnelles

Une startup du secteur de la santé stockait des formulaires d’admission de patients dans un bucket S3 qui avait été créé avec un accès en lecture public lors d’un sprint de développement et n’avait jamais été verrouillé avant sa mise en production. Le bucket a été découvert par un chercheur en sécurité utilisant une combinaison de brute-forcing DNS et de la technique d’énumération des buckets AWS S3. Environ 87 000 dossiers de patients — comprenant des noms, des dates de naissance, des identifiants d’assurance et des descriptions du motif principal de consultation — étaient accessibles sans authentification. La startup ne disposait d’aucun outil CSPM et d’aucune analyse de configuration automatisée. Une règle AWS Config de base vérifiant s3-bucket-public-read-prohibited aurait signalé la mauvaise configuration quelques minutes seulement après sa création. L’incident a entraîné une enquête du HHS, un règlement de 450 000 $, et une atteinte à la réputation qui a contribué au rachat de l’entreprise à une valeur décotée.

← Sécurité des applications et du web · Tous les domaines · Sécurité des données →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →