Chapitre 10 — Concepts Cloud, IAM & Conteneurs
⏱ ~30 min autonome · ~45 min encadré
Le cloud a déplacé une grande partie de l'infrastructure hors des murs de l'organisation — ce qui ne signifie pas moins de responsabilité de sécurité, mais une responsabilité partagée selon des règles précises qu'il faut comprendre pour ne pas se tromper de camp.
- Distinguer les modèles de service IaaS, PaaS et SaaS.
- Expliquer le modèle de responsabilité partagée et pourquoi la frontière se déplace selon le modèle.
- Décrire les risques spécifiques aux conteneurs et à leur orchestration.
Modèles de service
| Modèle | Ce que le fournisseur gère | Ce que le client gère |
|---|---|---|
| IaaS (Infrastructure as a Service) | Matériel, virtualisation, réseau physique | Système d'exploitation, applications, données — le client garde le plus de contrôle, mais aussi le plus de responsabilité directe |
| PaaS (Platform as a Service) | Matériel, virtualisation, système d'exploitation | Applications et données uniquement — le client se concentre sur son code |
| SaaS (Software as a Service) | Tout, y compris l'application elle-même | Seulement ses propres données et sa configuration d'accès |
Modèles de déploiement
Public (ressources mutualisées entre clients, gérées par un fournisseur tiers), privé (infrastructure dédiée à une seule organisation, sur site ou hébergée), et hybride (combinaison des deux, souvent pour garder certaines données sensibles hors du cloud public tout en profitant de son élasticité pour le reste).
Modèle de responsabilité partagée
Le principe général — le fournisseur sécurise le cloud (l'infrastructure sous-jacente), le client sécurise dans le cloud (ce qu'il y dépose) — se précise selon le modèle de service choisi : plus le modèle est géré (SaaS > PaaS > IaaS), plus le fournisseur assume de responsabilité technique, mais la sécurité des données et des accès reste, dans tous les cas, la responsabilité du client. Voir l'annexe dédiée pour le détail complet couche par couche.
IAM cloud — principes
En l'absence d'un périmètre réseau traditionnel, la gestion des identités (IAM — Identity and Access Management) devient le contrôle de sécurité central : qui peut faire quoi, sur quelle ressource précise, généralement défini par des politiques granulaires plutôt qu'un accès binaire tout-ou-rien.
Fédération d'identité et SSO
La fédération d'identité permet à un utilisateur de s'authentifier une seule fois auprès d'un fournisseur d'identité de confiance, puis d'accéder à plusieurs services cloud sans ressaisir ses identifiants (SSO — Single Sign-On) — pratique pour l'utilisateur, mais qui concentre aussi le risque : la compromission d'un seul compte d'identité fédérée peut ouvrir l'accès à de nombreux services connectés.
Conteneurs — principes de sécurité
Un conteneur empaquette une application avec ses dépendances dans une unité légère et portable, partageant le noyau du système hôte plutôt que de virtualiser un système d'exploitation complet. Cette légèreté a un revers : une isolation moins forte qu'une machine virtuelle classique entre le conteneur et son hôte, rendant la provenance de l'image utilisée (vérifiée ou non) particulièrement critique.
Introduction à Kubernetes et ses risques
Kubernetes orchestre le déploiement, la mise à l'échelle et la gestion de nombreux conteneurs. Sa puissance vient avec une surface de configuration importante — une API de gestion (le « plan de contrôle ») insuffisamment protégée, ou une absence de segmentation réseau entre charges de travail d'un même cluster, comptent parmi les erreurs de configuration les plus documentées dans l'industrie.