Annexe — Architecture de sécurité cloud, approfondissement

⏱ ~20 min · référence

Le Chapitre 10 couvre les concepts fondamentaux de la sécurité cloud. Cette annexe approfondit l'angle architecture — une approche agnostique par rapport au fournisseur (Azure, AWS, GCP), orientée sur les principes plutôt que sur une checklist propre à une plateforme.

Le modèle de responsabilité partagée, en détail

Le principe général (le fournisseur sécurise le cloud, le client sécurise ce qu'il y met) cache une nuance importante : la frontière exacte de responsabilité se déplace selon le modèle de service.

Couche	IaaS	PaaS	SaaS
Données et accès	Client	Client	Client
Application	Client	Client	Fournisseur
Système d'exploitation	Client	Fournisseur	Fournisseur
Virtualisation, matériel, réseau physique	Fournisseur	Fournisseur	Fournisseur

Mémorisez ! Peu importe le modèle de service choisi, la sécurité des données et des accès reste toujours la responsabilité du client. C'est l'erreur la plus coûteuse observée en pratique : croire qu'un fournisseur cloud réputé élimine le besoin de configurer correctement les permissions et le chiffrement de ses propres données.

Défense en profondeur appliquée au cloud

Les principes de défense en profondeur (voir Chapitre 1) se traduisent différemment en environnement cloud, où le périmètre réseau traditionnel n'existe plus de la même façon :

Identité comme nouveau périmètre : en l'absence d'un périmètre réseau classique, la gestion rigoureuse des identités (IAM, moindre privilège, authentification multifacteur systématique) devient le contrôle de sécurité le plus critique — pas le pare-feu.
Segmentation logique : équivalent cloud de la segmentation réseau physique — groupes de sécurité, réseaux virtuels isolés, séparation stricte entre environnements de test et de production.
Chiffrement par défaut : au repos et en transit, sans exception, y compris pour les données jugées peu sensibles au départ — les mauvaises configurations de stockage exposé restent l'une des causes d'incident les plus fréquentes (voir Chapitre 10.4).
Visibilité centralisée : consolidation des journaux de tous les services cloud utilisés, puisque l'éclatement naturel des services complique la détection d'une activité anormale répartie sur plusieurs composants.

Modélisation des menaces spécifique au cloud

Le cadre STRIDE (voir Chapitre 5) reste applicable en cloud, avec des angles morts supplémentaires propres à l'environnement partagé :

Attaques inter-locataires (multi-tenant) : risque théorique qu'une faille d'isolation dans l'infrastructure du fournisseur permette à un client d'accéder aux ressources d'un autre — rare en pratique chez les grands fournisseurs, mais à considérer pour des charges de travail très sensibles.
Dérive de configuration : contrairement à une infrastructure physique où un changement non autorisé est visible, une permission cloud mal configurée peut rester invisible pendant des mois sans outil de surveillance de conformité continue.
Sécurité des API : la quasi-totalité des interactions cloud passe par des API — leur exposition (clés d'accès mal protégées, absence de limitation de débit) constitue une surface d'attaque à part entière, distincte de la sécurité applicative classique.

Conteneurs et orchestration — risques spécifiques

Au-delà des machines virtuelles classiques, les architectures conteneurisées (voir 10.3) ajoutent leurs propres angles de risque : images de conteneurs construites à partir de sources non vérifiées, API du plan de contrôle Kubernetes exposée sans authentification stricte, et absence de segmentation réseau entre les charges de travail d'un même cluster — trois causes fréquentes d'incidents documentés dans l'industrie.

Sur le terrain

Une approche orientée architecture (plutôt qu'une checklist propre à un fournisseur) vieillit mieux : les noms des services changent d'une plateforme à l'autre et d'une année à l'autre, mais les principes — identité comme périmètre, chiffrement par défaut, visibilité centralisée — restent valides indépendamment du fournisseur choisi.