Chapitre 5 — Cloud, CASB, SDN & Infrastructure Moderne

Ce module couvre les modèles de services cloud (IaaS, PaaS, SaaS), la responsabilité partagée, et les technologies de sécurité cloud comme CASB, SDN et Infrastructure as Code.

Modèles de Services Cloud

Mémorisez ! IaaS = vous gérez l'OS et plus. PaaS = vous gérez uniquement le code/données. SaaS = vous ne gérez rien. La responsabilité de sécurité diminue du côté client à mesure qu'on monte vers SaaS.

Modèle	Vous gérez	Le fournisseur gère	Exemples
IaaS	OS, middleware, applications, données	Matériel, réseau, virtualisation	AWS EC2, Azure VMs, GCP Compute
PaaS	Applications, données	+ OS, middleware, runtime	AWS Elastic Beanstalk, Heroku, Azure App Service
SaaS	Données utilisateur, accès	Tout (infrastructure, app, OS)	Office 365, Salesforce, Slack, Google Workspace
FaaS/Serverless	Code de fonction uniquement	Tout le reste, y compris l'exécution	AWS Lambda, Azure Functions

Modèles de Déploiement Cloud

Modèle	Description	Cas d'usage
Cloud Public	Infrastructure partagée d'un fournisseur (AWS, Azure, GCP)	PME, startups, charges variables
Cloud Privé	Infrastructure dédiée, on-premise ou hébergée	Réglementations strictes, données classifiées
Cloud Hybride	Combinaison public + privé avec interconnexion	Workloads sensibles on-premise, burst vers cloud public
Cloud Communautaire	Partagé entre plusieurs organisations du même secteur	Secteur santé, gouvernement, défense
Multicloud	Utilisation de plusieurs fournisseurs cloud simultanément	Éviter le lock-in, résilience géographique

Responsabilité Partagée (Shared Responsibility)

Le modèle de responsabilité partagée définit qui (client ou fournisseur cloud) est responsable de chaque aspect de la sécurité.

Exemple concret : AWS est responsable de la sécurité du cloud (infrastructure physique, hyperviseurs, réseau). Le client est responsable de la sécurité dans le cloud : chiffrement des données S3, politiques IAM, configuration des groupes de sécurité, mise à jour des OS EC2, contrôle des accès à l'application.

Astuce Examen

Si une donnée est exposée dans un bucket S3 mal configuré, c'est la responsabilité du client (mauvaise configuration). Si l'infrastructure AWS est compromise, c'est la responsabilité d'AWS. La ligne varie selon le modèle (IaaS vs SaaS).

Technologies de Sécurité Cloud

CASB (Cloud Access Security Broker) : intermédiaire entre les utilisateurs et les services SaaS. Applique les politiques de sécurité, DLP, chiffrement, authentification. Peut être en mode proxy (inline) ou API.
Cloud DLP : prévient la fuite de données sensibles vers des services cloud non autorisés.
CWPP (Cloud Workload Protection Platform) : protège les workloads cloud (VMs, conteneurs, fonctions serverless).
CSPM (Cloud Security Posture Management) : identifie les mauvaises configurations dans l'environnement cloud (ex: buckets S3 publics, règles de sécurité trop permissives).
CNAPP (Cloud-Native Application Protection Platform) : combine CWPP + CSPM.

SDN & Infrastructure as Code

SDN (Software-Defined Networking) : sépare le plan de contrôle (décisions de routage) du plan de données (transmission). Permet de configurer le réseau via des API et du code.
Infrastructure as Code (IaC) : définir l'infrastructure via du code (Terraform, CloudFormation, Ansible). Reproductible, versionné, auditable.
Risques IaC : secrets hardcodés dans les fichiers IaC, configurations par défaut non sécurisées, drift entre le code et l'environnement réel.
Immutable Infrastructure : au lieu de patcher un serveur, on redéploie un nouveau serveur avec la configuration à jour. Réduit le risque de configuration drift.

Quiz — Cloud & Infrastructure

1. Dans le modèle IaaS, quelle est la responsabilité du CLIENT en matière de sécurité ?

Sécuriser l'infrastructure physique et les hyperviseurs Sécuriser l'OS, les applications, les données et les configurations réseau (groupes de sécurité) Uniquement sécuriser les données applicatives Aucune responsabilité — le fournisseur gère tout

IaaS (Infrastructure as a Service) : le fournisseur gère le matériel, la virtualisation et l'hyperviseur. Le client est responsable de tout le reste : OS (patches), applications, données, chiffrement, contrôle d'accès, configuration réseau (SG, NACLs).

2. Des données d'entreprise sensibles sont accessibles publiquement via un bucket S3 mal configuré. Selon le modèle de responsabilité partagée AWS, qui est responsable ?

AWS — ils auraient dû empêcher la mauvaise configuration Les deux partagent la responsabilité à 50/50 Le client — la configuration des ressources est sa responsabilité Le développeur qui a créé le bucket

AWS est responsable DE l'infrastructure (le service S3 fonctionne). La configuration du bucket (accès public/privé, politiques) est la responsabilité du CLIENT. Les mauvaises configurations S3 sont l'une des causes les plus fréquentes de fuites de données cloud.

3. Un CSPM (Cloud Security Posture Management) est utilisé pour :

Gérer les identités dans le cloud IAM Déployer automatiquement des mises à jour OS dans le cloud Filtrer le trafic réseau vers les VMs cloud Identifier et corriger les mauvaises configurations de sécurité dans l'environnement cloud

CSPM analyse en continu la configuration cloud (AWS, Azure, GCP) pour détecter les écarts par rapport aux bonnes pratiques : groupes de sécurité trop ouverts, MFA désactivé, chiffrement absent, buckets publics, ports dangereux exposés.

4. Office 365 et Salesforce sont des exemples de quel modèle de service cloud ?

SaaS IaaS PaaS FaaS

SaaS (Software as a Service) : l'application complète est hébergée par le fournisseur. Le client accède via navigateur ou client. Responsabilité client limitée aux données et aux accès utilisateurs. Office 365, Salesforce, Slack, Google Workspace = SaaS classiques.

5. Quelle est la différence entre un cloud public et un cloud privé ?

Le cloud public est plus sécurisé car géré par des professionnels Le cloud privé est dédié à une seule organisation avec une meilleure isolation ; le cloud public est partagé entre multiple clients Le cloud privé est toujours on-premise ; le cloud public est toujours externe Le cloud privé ne peut pas utiliser de virtualisation

Cloud public = multi-tenant (partagé entre organisations, isolation logique). Cloud privé = dédié à une organisation (matériel dédié, isolation physique). Cloud privé peut être on-premise (datacenter interne) ou hébergé chez un fournisseur (hosted private cloud).

6. L'Infrastructure as Code (IaC) améliore la sécurité principalement en : Chiffrant automatiquement toutes les communications réseau Remplaçant les administrateurs humains par des automatismes Permettant de versionner, auditer et appliquer des contrôles de sécurité de manière cohérente et reproductible Générant automatiquement des politiques IAM

IaC (Terraform, CloudFormation, Ansible) = configuration en code versionné dans Git. Bénéfices sécurité : auditabilité (qui a changé quoi, quand), cohérence (pas de configuration manuelle, pas de "configuration drift"), reproductibilité (recreer un environnement identique), code review des changements.

7. Le SDN (Software-Defined Networking) améliore la sécurité réseau en : Chiffrant tout le trafic réseau automatiquement Remplaçant les pare-feux physiques Augmentant la bande passante disponible Permettant une micro-segmentation dynamique et la configuration centralisée des politiques réseau via des API

SDN sépare le plan de contrôle (intelligence, décisions) du plan de données (transmission). Cela permet la micro-segmentation granulaire, la modification dynamique des règles réseau, et une visibilité centralisée — impossible à cette échelle avec des équipements réseau traditionnels.

8. Heroku, AWS Elastic Beanstalk et Azure App Service sont des exemples de quel modèle de service cloud ? PaaS IaaS SaaS FaaS

PaaS (Platform as a Service) : le développeur dépose son code, la plateforme gère l'OS, le runtime, les middlewares, la mise à l'échelle. Responsabilité sécurité = code applicatif et données. Plus de gestion de serveurs.

9. Le principal risque de sécurité lié à l'Infrastructure as Code (IaC) est : Les fichiers IaC consomment trop d'espace disque L'IaC est trop complexe pour les équipes de sécurité Les secrets et credentials peuvent être accidentellement inclus dans les fichiers IaC versionnés dans Git L'IaC ne supporte pas les environnements multi-cloud

Les secrets hardcodés dans Terraform, CloudFormation ou Ansible (clés API, mots de passe, certificats) qui se retrouvent dans Git sont une fuite de sécurité majeure. Solution : utiliser des gestionnaires de secrets (Vault, AWS Secrets Manager), des variables d'environnement, ou des scans automatiques avec git-secrets, truffleHog.

10. Un CASB en mode "API" diffère d'un CASB en mode "proxy" en ce qu'il : Bloque le trafic en temps réel avant qu'il atteigne l'application SaaS Accède aux logs et données via les APIs du SaaS (post-facto) — ne peut pas bloquer en temps réel mais pas de latence Nécessite un agent sur chaque endpoint des utilisateurs Ne peut surveiller que les applications on-premise

CASB API-mode : se connecte via les APIs des SaaS (Office 365, Google Drive) pour analyser les logs, contenu, et configuration — pas de latence, mais réaction retardée (détection après coup). CASB proxy-mode : s'interpose dans le flux (inline) pour bloquer en temps réel mais peut ajouter de la latence.