Modèle de responsabilité partagée

Le modèle de responsabilité partagée divise la sécurité en deux : AWS sécurise le cloud lui-même et vous sécurisez ce que vous y créez. C’est l’un des concepts les plus souvent évalués à l’examen.

AWS prend en charge la sécurité du cloud — les centres de données, le matériel, l’hyperviseur et les logiciels des services gérés. Vous ne pouvez pas les auditer directement, mais AWS détient des certifications qui l’attestent.

Vous êtes responsable de la sécurité dans le cloud : IAM, chiffrement des données, correctifs du système d’exploitation et règles réseau. Si vous rendez un compartiment S3 public, c’est votre responsabilité, pas celle d’AWS.

Avec EC2, la distinction est claire : AWS gère l’hôte et l’hyperviseur, tandis que vous gérez le système d’exploitation, les applications, les groupes de sécurité et les données. Une règle SSH ouverte doit être corrigée par vos soins. Le code les recherche.

Plus un service est géré, plus AWS prend de responsabilités en charge. Avec RDS, AWS applique les correctifs au moteur ; avec Lambda, AWS exécute l’ensemble de l’environnement d’exécution ; avec S3, AWS gère tout ce qui se trouve en dessous.

Quel que soit le service, la protection de vos données relève toujours de votre responsabilité. AWS vous fournit les outils — KMS et les paramètres de chiffrement — mais c’est à vous de les choisir et de les activer.

AWS fournit le réseau physique, mais vous configurez le VPC, les sous-réseaux, les groupes de sécurité et les NACL. Laisser le port 22 ouvert à tout Internet est une erreur classique et coûteuse.

AWS détient de nombreuses certifications de conformité pour son infrastructure, mais vous devez certifier votre propre configuration. Des outils comme Artifact, Config et Security Hub vous y aident.

Les conteneurs ajoutent une nuance. Sur ECS avec EC2, vous gérez l’hôte ; avec Fargate, c’est AWS qui s’en charge. En revanche, l’image du conteneur relève toujours de votre responsabilité : vous devez l’analyser et la maintenir à jour.

À l’examen, l’heuristique est simple : les défaillances physiques ou logicielles d’un service géré relèvent d’AWS ; les défaillances de configuration, d’accès, de données et du système d’exploitation sur une infrastructure en tant que service relèvent du client.

AWS répartit les contrôles en trois catégories : hérités (entièrement pris en charge par AWS), gérés par le client (entièrement par vous) et partagés (chacun ajoute une couche, comme pour l’application des correctifs). Cette classification apparaît à l’examen.

Vérifiez votre compréhension des concepts AWS Solutions Architect (SAA-C03) présentés dans cette leçon.

Vous avez appris qu’AWS sécurise l’infrastructure, tandis que vous sécurisez IAM, les données, le système d’exploitation et la configuration, et que les services davantage gérés transfèrent davantage de responsabilités à AWS. Ensuite : IAM en détail.