Introduction

La sécurité est un pilier fondamental du cloud. Si AWS met à disposition une infrastructure hautement sécurisée, la responsabilité de sa bonne utilisation incombe aux clients, selon le principe du modèle de responsabilité partagée. Ce modèle stipule qu’AWS est responsable de la sécurité du cloud (protection physique des datacenters, hyperviseur, réseau, matériel), tandis que le client est responsable de la sécurité dans le cloud (configuration des accès, chiffrement, gestion des applications et des données). La répartition exacte de ces responsabilités varie toutefois selon le type de service : la part qui revient au client est plus étendue en IaaS (par exemple EC2) et se réduit progressivement avec le PaaS puis le SaaS.

Les erreurs de configuration constituent encore la première cause d’incidents de sécurité dans le cloud. Buckets S3 exposés publiquement, clés IAM trop permissives, secrets laissés en clair dans du code source : autant de situations évitables si les bonnes pratiques sont respectées.

Dans ce chapitre, nous allons explorer trois domaines essentiels :

IAM avancé, pour comprendre comment structurer les permissions de manière fine et sécurisée ;
le chiffrement et la gestion...

IAM avancé : rôles, permissions et bonnes pratiques

1. Comprendre les fondations d’IAM

L’IAM (Identity and Access Management) est le cœur de la sécurité dans AWS. Il contrôle qui peut accéder à quoi, et dans quelles conditions. Mal configuré, il peut transformer une architecture sécurisée en un environnement vulnérable.

IAM repose sur plusieurs concepts fondamentaux :

Utilisateurs et groupes : destinés aux personnes humaines. Toutefois, AWS recommande aujourd’hui d’utiliser IAM Identity Center (anciennement AWS SSO) pour gérer les identités humaines, et de réserver IAM aux identités machines. L’usage d’utilisateurs IAM reste néanmoins justifié dans certains cas précis, comme un compte de secours (break-glass) ou des besoins de compatibilité avec des systèmes existants.
Rôles : entités IAM qui définissent un ensemble de permissions et qui sont assumées temporairement par des utilisateurs, applications ou services.
Politiques (policies) : documents JSON qui décrivent les permissions accordées (Allow/Deny), sur quelles actions (Actions) et sur quelles ressources (Resources).
STS (Security Token Service) : mécanisme qui délivre des identifiants temporaires, réduisant les risques liés à des clés longue durée.

Erreur fréquente

De nombreuses entreprises créent des utilisateurs IAM avec des clés d’accès permanentes pour leurs développeurs ou leurs applications. En cas de fuite (dans GitHub par exemple), ces clés donnent un accès illimité au compte. La bonne pratique est de remplacer ces clés par l’usage de rôles et de tokens temporaires.

2. Les rôles IAM : un levier de sécurité et de flexibilité

L’usage des rôles IAM permet de déléguer des permissions temporaires, sans avoir à distribuer de secrets. Ils sont omniprésents dans les environnements modernes...

Chiffrement et gestion des secrets : AWS KMS et Secrets Manager

1. Pourquoi le chiffrement est devenu incontournable

Dans un monde où la donnée est devenue un actif stratégique, la protection des informations sensibles est une exigence autant technique que réglementaire. Les incidents liés à des fuites de données sont parmi les plus coûteux pour une organisation, non seulement en termes financiers, mais aussi en termes d’image et de confiance.

Les régulations internationales (RGPD en Europe, PCI DSS pour les paiements, HIPAA dans le secteur de la santé, SOX pour les entreprises cotées aux États-Unis) imposent des règles strictes sur la confidentialité et l’intégrité des données. Le chiffrement est l’un des piliers techniques qui permet de s’y conformer.

Sur AWS, le chiffrement peut être appliqué à trois niveaux :

Au repos : les données stockées dans S3, RDS, EBS ou DynamoDB sont chiffrées avant d’être écrites sur le disque.
En transit : les communications passent par TLS/SSL, garantissant que les échanges entre clients, applications et services ne peuvent pas être interceptés en clair.
Au niveau applicatif : les données sont chiffrées avant même d’être envoyées à AWS, selon des logiques propres à l’organisation.

2. AWS Key Management Service (KMS) : centraliser la gestion des clés

AWS Key Management Service (KMS) est le service managé dédié à la gestion des clés de chiffrement. Il permet de créer, stocker et administrer des clés KMS gérées par le client (Customer Managed Keys), qui peuvent être utilisées pour chiffrer des données ou générer des clés temporaires.

a. Intégration avec les services AWS

La grande force de KMS réside dans son intégration quasi universelle. Activer le chiffrement côté serveur (SSE) dans un bucket S3, cocher Enable Encryption dans RDS ou activer le chiffrement d’un volume EBS : dans tous ces cas, KMS est le service sous-jacent qui génère et gère les clés.

Cela permet...

AWS WAF, Shield et GuardDuty : sécuriser ses ressources

1. Protéger les applications web avec AWS WAF

Dans un environnement cloud, la surface d’exposition principale est souvent constituée par les applications web : sites e-commerce, API REST, portails clients. Ces applications sont des cibles privilégiées pour des attaques telles que l’injection SQL, le cross-site scripting (XSS) ou les tentatives d’exfiltration via des requêtes malveillantes.

L’AWS Web Application Firewall (WAF) agit comme une barrière de protection. Placé devant une ressource exposée (un Application Load Balancer (ALB), une API Gateway ou un CloudFront), il inspecte chaque requête HTTP/HTTPS et applique des règles définies par l’administrateur.

Ces règles peuvent être :

managées (fournies par AWS ou des partenaires, par exemple pour bloquer les bots connus) ;
personnalisées, écrites en fonction de besoins spécifiques.

Exemple concret

Une entreprise déploie un site e-commerce mondial. Après quelques jours, elle subit des tentatives d’injection SQL sur ses formulaires de recherche. En activant le jeu de règles managées « AWS Managed Rules - SQL Injection », toutes ces requêtes sont bloquées en amont. L’application continue de fonctionner normalement, mais les attaques n’atteignent jamais le backend.

Exemple de règle WAF JSON

{ 
  "Name": "BlockSQLi", 
  "Priority": 1, 
  "Statement": { 
    "SqliMatchStatement": { 
      "FieldToMatch": { 
        "QueryString": {} 
      }, ...

Résumé du chapitre

Ce chapitre a présenté trois axes majeurs de la sécurité AWS :

IAM pour contrôler et auditer les accès ;
KMS et Secrets Manager pour protéger les données sensibles ;
WAF, Shield et GuardDuty pour sécuriser les ressources exposées à Internet et détecter les menaces.

La combinaison de ces services, associée à une gouvernance claire, constitue la base d’une posture de sécurité robuste dans AWS.

Sécurité et conformité AWS