Amazon SAA-C03: Sécurité, IAM, KMS et gouvernance — Guide d'étude

By Laurynas Brazys · 16 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Fait partie du AWS SAA-C03 — Guide d’étude complet. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Amazon, ou passez des tests chronométrés sur ExamRoll.io.

Fondations de l’identité : Utilisateurs, Root, Groupes et Rôles

La gestion des identités et des accès (IAM) est le plan de contrôle par lequel passe chaque charge de travail, et son principe directeur est celui du moindre privilège : n’accorder que ce qui est nécessaire, uniquement pour la durée nécessaire, et préférer les identités qui produisent des informations d’identification à durée de vie limitée à celles qui détiennent des secrets statiques.

L’utilisateur root est propriétaire du compte, détient des autorisations illimitées et ne peut être limité par les politiques IAM ou les SCP. Cela en fait l’information d’identification la plus sensible de l’environnement, et elle doit être traitée comme une solution de secours (break-glass). Sur un nouveau compte : activez un périphérique MFA matériel ou virtuel sur le compte root, définissez un mot de passe long et unique, supprimez toutes les clés d’accès root historiques et enregistrez des contacts alternatifs pour la facturation, les opérations et la sécurité afin de permettre la récupération. Après la configuration initiale — création d’une identité d’administrateur IAM, configuration de la facturation et définition de l’alias du compte — le compte root n’est plus utilisé, sauf pour l’ensemble restreint de tâches pour lesquelles AWS l’exige explicitement (fermeture du compte, changement du nom du compte, restauration des autorisations IAM supprimées, activation de MFA Delete, et une poignée d’opérations S3/CloudFront signées par le root). Utiliser le compte root pour le travail quotidien est une mauvaise pratique car il ne peut pas être restreint par une politique, son attribution est difficile à suivre dans CloudTrail lorsqu’il est partagé, et une seule compromission accorde un contrôle irrévocable.

L’accès humain au quotidien passe par des identités IAM régies par des politiques de moindre privilège. Attachez les politiques gérées aux groupes, et non aux utilisateurs individuels : un groupe Administrators avec la politique AdministratorAccess attachée, et des utilisateurs nommés placés dedans, offre un point de modification unique et évite l’anti-modèle consistant à copier des politiques identiques sur chaque utilisateur. Définissez la portée des ressources avec des ARN explicites plutôt qu’avec *.

Les rôles ont un objectif entièrement différent. Ils sont assumés par des principaux — services, instances EC2, fonctions Lambda, utilisateurs fédérés, appelants inter-comptes — et produisent des informations d’identification STS temporaires qui sont renouvelées automatiquement. Comme ces informations d’identification ne peuvent pas fuiter dans un commit Git et expirent en quelques minutes ou heures plutôt que de persister jusqu’à leur renouvellement manuel, les rôles sont l’identité par défaut pour tout ce qui n’est pas humain.

Deux politiques par rôle : Autorisations et Confiance

Chaque rôle est régi par deux documents indépendants, et oublier l’un ou l’autre est un mode d’échec classique.

La politique d’autorisations (basée sur l’identité) déclare ce que le rôle peut faire une fois qu’il est assumé. La politique de confiance (basée sur la ressource, attachée au rôle lui-même) déclare qui peut l’assumer. Attacher AmazonS3ReadOnlyAccess à un rôle ne sert à rien si aucun principal n’est autorisé à appeler sts:AssumeRole sur celui-ci, et inversement, une politique de confiance permissive sans politique d’autorisations produit un rôle qui peut être assumé mais qui n’a aucune utilité.

Un rôle d’exécution Lambda illustre le modèle du principal de service — le service lui-même, et non le propriétaire du compte, est l’appelant :

AssumeRolePolicyDocument:              # trust policy
  Version: "2012-10-17"
  Statement:
    - Effect: Allow
      Principal: { Service: lambda.amazonaws.com }
      Action: sts:AssumeRole
Policies:                              # permissions
  - PolicyName: ReadOrders
    PolicyDocument:
      Statement:
        - Effect: Allow
          Action: dynamodb:GetItem
          Resource: arn:aws:dynamodb:*:*:table/Orders

Identité des charges de travail : Profils d’instance, Rôles de tâche, IRSA, Roles Anywhere

Toute information d’identification qui se trouve dans un modèle, une variable d’environnement ou sur un ordinateur portable est une future faille de sécurité. Le modèle canonique d’AWS remplace les clés d’accès statiques par des informations d’identification à durée de vie limitée, renouvelées automatiquement et fournies via des rôles.

Pour EC2, le mécanisme de livraison est le profil d’instance — un conteneur léger qui lie un rôle IAM à une instance afin que le service de métadonnées d’instance (IMDSv2) puisse fournir des informations d’identification temporaires au SDK. La chaîne de fournisseurs d’informations d’identification par défaut les trouve sans configuration, donc boto3.client('s3') fonctionne directement et le code de l’application ne voit jamais d’information d’identification. IMDSv2 (HttpTokens: required) doit être appliqué pour contrer l’exfiltration d’informations d’identification basée sur les attaques SSRF. Les informations d’identification sont renouvelées environ toutes les six heures, et leur révocation se fait par une simple modification du rôle.

AppRole:
  Type: AWS::IAM::Role
  Properties:
    AssumeRolePolicyDocument:
      Statement:
        - Effect: Allow
          Principal: { Service: ec2.amazonaws.com }
          Action: sts:AssumeRole
    Policies:
      - PolicyName: S3DocAccess
        PolicyDocument:
          Statement:
            - Effect: Allow
              Action: [s3:GetObject, s3:PutObject]
              Resource: arn:aws:s3:::docs-bucket/*
AppInstanceProfile:
  Type: AWS::IAM::InstanceProfile
  Properties:
    Roles: [!Ref AppRole]

Pour ECS, l’analogue est le rôle de tâche ; pour Lambda, c’est le rôle d’exécution ; pour les pods EKS, c’est IRSA (IAM Roles for Service Accounts) ou EKS Pod Identity. Dans tous les cas, AWS lui-même négocie les informations d’identification par rapport à un rôle et la charge de travail ne voit jamais de secret à longue durée de vie.

Intégrer des clés d’accès dans une AMI, un script de données utilisateur ou un fichier .env est une mauvaise pratique pour trois raisons concrètes : les clés ne sont jamais renouvelées automatiquement, leur portée ne peut pas être limitée au contexte de la session comme un point de terminaison VPC source, et si l’instance est compromise ou qu’une AMI est partagée par inadvertance, l’information d’identification est divulguée de manière permanente.

Pour les charges de travail en dehors d’AWS — serveurs sur site, autres clouds, exécuteurs CI — qui ont besoin d’informations d’identification AWS temporaires sans clés intégrées, IAM Roles Anywhere utilise des certificats X.509 provenant d’une autorité de certification privée (AWS Private CA ou la vôtre) comme ancre de confiance. La charge de travail présente son certificat client et reçoit des informations d’identification STS à durée de vie limitée :

aws_signing_helper credential-process \
  --certificate /etc/pki/client.pem \
  --private-key /etc/pki/client.key \
  --trust-anchor-arn arn:aws:rolesanywhere:...:trust-anchor/... \
  --profile-arn arn:aws:rolesanywhere:...:profile/... \
  --role-arn arn:aws:iam::111122223333:role/OnPremWorkload

Cela résout le même anti-modèle que les rôles d’instance et Secrets Manager résolvent à l’intérieur d’AWS.

Accès humain à grande échelle : Identity Center, SAML, Directory Service

Le provisionnement d’utilisateurs IAM par compte, quelle que soit l’échelle, est ingérable. AWS IAM Identity Center (successeur d’AWS SSO) est la porte d’entrée recommandée pour l’accès des employés : un annuaire unique qui se fédère à chaque compte d’une organisation et émet des sessions temporaires basées sur des rôles via des ensembles d’autorisations (permission sets) — des modèles de rôles IAM mappés à des groupes de l’IdP. Les utilisateurs s’authentifient une seule fois sur le portail Identity Center, puis assument des ensembles d’autorisations dans n’importe quel compte qui leur est assigné.

Identity Center s’intègre avec des IdP externes (Okta, Entra ID/Azure AD, Google Workspace, ADFS) via SAML 2.0 et SCIM pour des flux automatisés d’arrivée/mobilité/départ d’employés, et avec Active Directory sur site via AWS Directory Service AD Connector (un proxy) ou AWS Managed Microsoft AD (une réplique complète dans AWS). Pour les applications mobiles ou web qui doivent appeler AWS à partir d’utilisateurs non authentifiés ou authentifiés par un tiers, Amazon Cognito échange l’identité externe contre des informations d’identification STS temporaires, évitant là encore les clés à longue durée de vie intégrées.

Accès entre comptes (Cross-Account Access)

L’accès entre comptes s’exprime avec des rôles, et non des utilisateurs partagés, et les deux parties doivent donner leur accord. Le compte cible (B) crée un rôle dont la politique de confiance nomme le compte A (ou un principal spécifique s’y trouvant), et l’appelant dans A doit également avoir la permission sts:AssumeRole ciblant l’ARN de ce rôle. L’autorisation d’un seul côté est insuffisante. Cela produit des informations d’identification à durée de vie limitée et une piste d’audit claire dans CloudTrail pour les deux comptes.

Lorsqu’un tiers (un fournisseur SaaS) est le principal qui assume le rôle, ajoutez une condition ExternalId pour contrer le problème du député confus, et envisagez d’exiger le MFA :

{
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::222222222222:root" },
  "Action": "sts:AssumeRole",
  "Condition": {
    "StringEquals": { "sts:ExternalId": "a1b2c3-unique-token" },
    "Bool": { "aws:MultiFactorAuthPresent": "true" }
  }
}

Pour les invocations entre comptes de service à service, ce sont les politiques basées sur les ressources qui font le travail. Pour autoriser un topic SNS dans le compte A à invoquer une fonction Lambda dans le compte B :

aws lambda add-permission \
  --function-name ProcessNotification \
  --statement-id AllowSNSInvoke \
  --action lambda:InvokeFunction \
  --principal sns.amazonaws.com \
  --source-arn arn:aws:sns:us-east-1:111111111111:my-topic

Le --principal sns.amazonaws.com est le principal de service (SNS lui-même invoque Lambda), et --source-arn limite la confiance à un topic spécifique pour éviter le problème du député confus.

Pour le partage S3 au sein d’une Organization, l’approche naïve — lister chaque ARN de compte dans la politique de compartiment — n’est pas scalable et échoue à chaque ajout d’un nouveau compte. Le bon modèle est d’utiliser aws:PrincipalOrgID :

{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::reports-bucket/*",
  "Condition": {
    "StringEquals": { "aws:PrincipalOrgID": "o-abcd1234ef" }
  }
}

Tout principal dans n’importe quel compte de cette organisation est autorisé ; tous les autres sont refusés. Notez que Principal: "*" sans la condition rendrait le compartiment public — c’est la clé de condition qui restreint la portée. L’aspect identité reste important : les utilisateurs dans les comptes membres ont également besoin que la permission s3:GetObject leur soit accordée par leur propre politique IAM (sauf s’ils sont le root du compte), car l’accès entre comptes nécessite que les deux parties autorisent l’appel.

Pour S3 spécifiquement, depuis 2023, le paramètre par défaut de Propriété de l’objet, Propriétaire du compartiment appliqué, désactive entièrement les ACL, faisant des politiques de compartiment le seul mécanisme d’autorisation pour le compartiment. Lorsque des objets ont été précédemment chargés par d’autres comptes, les ACL d’objet historiques ou l’ACL prédéfinie bucket-owner-full-control peuvent encore être en jeu.

Organizations et Service Control Policies

AWS Organizations regroupe les comptes dans une arborescence d’unités d’organisation (OU) avec un compte de gestion à la racine. Les Service Control Policies (SCP) sont des garde-fous attachés à la racine, à une OU ou à un compte individuel. Elles s’appliquent à chaque utilisateur et rôle IAM dans le compte — y compris le root du compte — mais pas au compte de gestion lui-même, c’est pourquoi aucune charge de travail ne devrait jamais y être exécutée.

Le modèle mental essentiel : les SCP n’accordent jamais de permissions. Elles définissent l’ensemble maximal d’actions autorisées dans un compte. Une action n’est autorisée que si elle est accordée par une politique basée sur l’identité ou sur les ressources et qu’elle n’est bloquée par aucune SCP dans le chemin hiérarchique du compte. Si un développeur a AdministratorAccess mais qu’une SCP refuse ec2:RunInstances en dehors de ap-southeast-2, un lancement dans us-east-1 échouera. Inversement, une SCP autorisant s3:* ne fait rien par elle-même — l’utilisateur a toujours besoin d’une politique IAM lui accordant s3:*. Les SCP filtrent ce que IAM a déjà autorisé ; ce sont des plafonds, pas des planchers.

Les cas d’usage typiques des SCP incluent le verrouillage de régions, l’interdiction de désactiver CloudTrail ou GuardDuty, l’interdiction de supprimer des clés KMS en dehors d’un rôle d’urgence (« break-glass »), et l’application du chiffrement. Pour forcer le chiffrement des volumes EBS au lancement, combinez deux mécanismes : activez le chiffrement EBS par défaut dans la région (un paramètre de compte par région pour que les utilisateurs ne modifient pas leurs scripts), plus une SCP comme garde-fou auditable :

{
  "Effect": "Deny",
  "Action": "ec2:RunInstances",
  "Resource": "arn:aws:ec2:*:*:volume/*",
  "Condition": { "Bool": { "ec2:Encrypted": "false" } }
}

Comme les SCP s’appliquent à l’ensemble du compte, elles ne peuvent pas être contournées par un administrateur compromis dans un compte membre. Les politiques de balises (Tag policies) imposent la standardisation des clés de balise et de leur casse (CostCenter, et non costcenter) afin que l’allocation des coûts et l’ABAC fonctionnent de manière fiable. Organizations prend également en charge l’administration déléguée : au lieu d’exécuter les services de sécurité depuis le compte de gestion, déléguez un compte membre (de type « sécurité » ou « audit ») comme administrateur pour GuardDuty, Security Hub, IAM Access Analyzer ou Config — préservant ainsi la séparation des tâches.

KMS : Clés, politiques de clé et modèles de propriété

KMS distingue le matériel de clé par sa propriété et son contrôle :

Une CMK est régie par une politique de clé (key policy) — une politique basée sur la ressource attachée à la clé. Contrairement à presque toutes les autres ressources AWS, les politiques IAM seules ne peuvent pas accorder l’accès à une clé KMS, à moins que la politique de clé ne délègue d’abord cet accès à IAM :

{
  "Sid": "EnableIAMPolicies",
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
  "Action": "kms:*",
  "Resource": "*"
}

Sans cette déclaration, aucune politique IAM ne rend la clé utilisable. La politique de clé et la politique IAM de l’appelant doivent toutes deux autoriser l’opération — c’est l’erreur de chiffrement la plus fréquente. Accorder kms:Decrypt dans une politique IAM est nécessaire mais pas suffisant ; si la politique de clé ne délègue pas à IAM ou ne nomme pas le principal, le déchiffrement échoue avec une erreur AccessDenied, même pour un administrateur.

Pour les services qui utilisent KMS en votre nom (EBS, S3, RDS, Lambda), le rôle appelant a généralement besoin des permissions kms:GenerateDataKey, kms:Decrypt, et souvent kms:CreateGrant. Pour un groupe de nœuds géré EKS chiffrant des volumes EBS avec une CMK, le rôle lié au service (service-linked role) Auto Scaling doit apparaître dans la politique de clé avec la permission kms:CreateGrant, sinon le lancement des instances échoue silencieusement.

La rotation des CMK gérées par le client nécessite une activation explicite — de nombreux praticiens supposent à tort que toutes les clés KMS effectuent une rotation automatique :

aws kms enable-key-rotation --key-id alias/my-cmk
aws kms get-key-rotation-status --key-id alias/my-cmk

La rotation préserve le même ID de clé et le même alias ; le matériel de clé sous-jacent change, mais les textes chiffrés antérieurs restent déchiffrables car KMS conserve l’ancien matériel pour déchiffrer les textes existants, tandis que les nouvelles écritures utilisent le nouveau matériel. Le matériel importé n’effectue jamais de rotation automatique. KMS impose une période de suppression en attente obligatoire de 7 à 30 jours ; associez cela à une règle EventBridge qui correspond à ScheduleKeyDeletion ou DisableKey dans CloudTrail et ciblez un sujet SNS pour un modèle d’alerte sans serveur et sans interrogation (poll-free) :

{
  "source": ["aws.kms"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": { "eventName": ["ScheduleKeyDeletion", "DisableKey"] }
}

Les External Key Stores (XKS) étendent le modèle lorsque les régulateurs exigent que le matériel de clé réside physiquement dans un HSM contrôlé par le client. KMS transmet les opérations cryptographiques à un proxy XKS qui communique avec le HSM sur site ; si le HSM est hors ligne, le déchiffrement échoue — la disponibilité devient la responsabilité du client.

Les clés multi-régions (MRK) partagent le même ID de clé et le même matériel entre les Régions, de sorte qu’un texte chiffré produit dans us-east-1 peut être déchiffré directement dans eu-west-1. C’est le modèle correct pour les tables globales DynamoDB, la réplication inter-régions S3 (Cross-Region Replication) avec SSE-KMS, et la reprise après sinistre (DR) où une Région de secours doit lire des sauvegardes chiffrées. Les clés mono-région standard nécessiteraient un déchiffrement puis un ré-chiffrement au moment de la réplication.

Partage de ressources chiffrées entre comptes

Le partage d’AMI et de snapshots EBS chiffrés est l’un des modes d’échec inter-comptes les plus courants car il nécessite quatre actions coordonnées : (1) utiliser une CMK gérée par le client — les clés gérées par AWS ne peuvent pas être partagées ; (2) ajouter le compte de destination en tant que principal dans la politique de clé avec les permissions kms:Decrypt, kms:DescribeKey, kms:CreateGrant et kms:ReEncrypt* ; (3) modifier les permissions de lancement/partage de l’AMI ou du snapshot pour inclure ce compte ; et (4) s’assurer que le principal IAM dans le compte de destination dispose également de ces actions KMS. L’opération de partage semble réussir si vous sautez l’étape 2, mais le compte récepteur ne peut pas déchiffrer. Supposer que le partage de l’AMI seul est suffisant est le piège classique.

Modes de chiffrement côté serveur S3

Lorsqu’une exigence spécifie une rotation annuelle automatique, une auditabilité via CloudTrail, et une minimisation des coûts de clé, la réponse est SSE-KMS avec la clé gérée par AWS aws/s3 — elle effectue une rotation annuelle sans frais et chaque appel GenerateDataKey/Decrypt est journalisé. SSE-S3 est moins cher mais ne laisse aucune trace d’utilisation de la clé. Une CMK gérée par le client ajoute 1 $/mois et n’effectue une rotation que si vous l’activez.

Confondre SSE-S3 et SSE-KMS est le piège classique des données de santé (PHI). SSE-S3 chiffre les données mais ne fournit aucune politique de clé, aucune visibilité dans CloudTrail, et aucun moyen pour une équipe de conformité d’administrer la clé — il ne répond donc à aucune exigence mentionnant « administrer », « contrôler », « auditer » ou « révoquer l’accès à » la clé. Inversement, choisir SSE-KMS lorsque l’exigence est seulement de « chiffrer au repos avec une gestion minimale » relève de la sur-ingénierie.

Activer SSE-KMS n’empêche pas en soi les lectures non autorisées. Si la politique de compartiment (bucket policy) autorise s3:GetObject et que la politique de clé accorde kms:Decrypt au même principal, l’objet est lisible. Le chiffrement au repos protège contre la compromission des supports physiques et ajoute une seconde vérification d’autorisation via la politique de clé — il ne se substitue pas à des politiques de compartiment, des politiques IAM, des politiques de point de terminaison VPC et des conditions aws:PrincipalOrgID correctement définies.

Appliquer le chiffrement et TLS sur S3

Rendre un bucket « chiffré par défaut » n’est pas suffisant — les clients peuvent omettre ou remplacer l’en-tête de chiffrement. Deux garde-fous doivent être superposés : le chiffrement de bucket par défaut (qui renseigne l’en-tête si le client l’omet) et une politique de bucket basée sur le refus (deny) qui rejette les PutObject sans l’en-tête requis, ainsi qu’une déclaration refusant l’accès non-TLS :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnEncryptedObjectUploads",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::phi-bucket/*",
      "Condition": {
        "StringNotEquals": { "s3:x-amz-server-side-encryption": "aws:kms" }
      }
    },
    {
      "Sid": "DenyInsecureTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": ["arn:aws:s3:::phi-bucket", "arn:aws:s3:::phi-bucket/*"],
      "Condition": { "Bool": { "aws:SecureTransport": "false" } }
    }
  ]
}

La condition aws:SecureTransport force l’utilisation de HTTPS, satisfaisant ainsi l’exigence de « chiffrement en transit ». Combiné avec SSE-KMS utilisant une CMK appartenant à l’équipe de conformité, c’est le modèle canonique pour le stockage de PHI.

Chiffrement en transit vs au repos

Le chiffrement au repos (stockage EBS, RDS, objets S3 chiffrés avec KMS) et le chiffrement en transit (TLS sur le réseau) sont des contrôles indépendants qui répondent à des menaces différentes : le vol de disque contre l’interception réseau. Activer KMS sur une instance RDS protège le stockage sous-jacent ; cela ne fait rien pour une session client-base de données, qui par défaut peut ne pas être chiffrée. Pour RDS MySQL, la protection en transit nécessite de télécharger le bundle d’AC (CA bundle) RDS, de définir require_secure_transport=ON dans le groupe de paramètres, et de connecter les clients avec --ssl-ca=rds-combined-ca-bundle.pem. Considérer que « le chiffrement au repos est activé » est suffisant est une erreur d’audit fréquente.

Secrets Manager et Parameter Store

Les mots de passe de base de données statiques dans les fichiers de configuration, les variables d’environnement ou les paramètres CloudFormation sont le principal vecteur de fuite d’identifiants. AWS Secrets Manager stocke les secrets chiffrés avec KMS, les expose via l’appel GetSecretValue contrôlé par IAM, et — point essentiel — effectue leur rotation automatique via une fonction Lambda de rotation. Pour RDS, Aurora, Redshift et DocumentDB, AWS fournit une Lambda de rotation gérée qui se connecte à la base de données, génère un nouveau mot de passe, met à jour de manière atomique à la fois le secret et l’utilisateur de la BDD, et prend en charge des stratégies mono-utilisateur ou multi-utilisateurs. Pour les autres systèmes, vous créez une Lambda qui implémente le cycle de vie en quatre étapes : createSecret, setSecret, testSecret, finishSecret.

import boto3, json
secret = json.loads(
    boto3.client('secretsmanager')
         .get_secret_value(SecretId='prod/aurora/app')['SecretString'])
conn = pymysql.connect(host=secret['host'],
                       user=secret['username'],
                       password=secret['password'])

Les applications mettent la valeur en cache brièvement (en utilisant la bibliothèque de mise en cache du SDK AWS) et se reconnectent en cas d’échec d’authentification. La rotation est invisible et aucun déploiement n’est nécessaire pour changer un mot de passe.

SSM Parameter Store SecureString est l’alternative lorsque la rotation n’est pas requise et que le coût est le facteur dominant :

L’entité qui récupère un paramètre SecureString a besoin à la fois de ssm:GetParameter et de kms:Decrypt sur la clé. Oublier la permission KMS est l’une des erreurs de configuration les plus courantes — la politique IAM semble correcte mais l’appel d’API échoue au déchiffrement.

Sur EC2, ECS, EKS et Lambda, le code doit assumer un rôle IAM et appeler GetSecretValue ou GetParameter ; pas d’identifiants à longue durée de vie sur le disque. Intégrer des clés d’accès d’utilisateur IAM directement dans le code de l’application — même chiffrées — viole le principe de moindre privilège et complique la rotation.

Outils d’audit et d’investigation numérique (Forensics)

CloudTrail enregistre chaque appel d’API AWS : qui, quoi, quand, d’où. Un organization trail (journal d’organisation) activé depuis le compte de gestion capture les événements de tous les comptes dans un unique bucket S3, idéalement dans un compte de sécurité verrouillé avec S3 Object Lock et MFA Delete. Cela fournit une chronologie d’investigation immuable — quel principal a supprimé un volume, quel rôle a modifié un groupe de sécurité, quelle clé d’accès a appelé ec2:RunInstances à 03:17 UTC. Complétez avec CloudWatch Logs et des alarmes (connexion root, changements de politique IAM), et AWS Config pour l’état des ressources à un instant T et les packs de conformité. Empêchez toute altération avec une SCP refusant cloudtrail:StopLogging et cloudtrail:DeleteTrail.

MFA Delete sur un bucket S3 force l’utilisateur root à présenter un token MFA pour supprimer définitivement une version d’objet ou désactiver le versioning. Il ne peut être activé que par l’utilisateur root via la CLI et fournit une protection forte contre les ransomwares et les suppressions par des initiés (insiders).

Amazon Macie utilise le ML géré pour découvrir des PII, PHI, identifiants et données financières dans S3, produisant des résultats (findings) classés par sévérité. C’est un outil de découverte, pas un outil de chiffrement.

Détection de menaces : GuardDuty, Security Hub, Detective

Amazon GuardDuty analyse en continu les VPC Flow Logs, les journaux DNS, et les événements de gestion et de données de CloudTrail, avec des plans de protection dédiés pour les journaux d’audit EKS, les événements de données S3, les analyses de malwares EBS, l’activité réseau Lambda, et les événements de connexion RDS. GuardDuty RDS Protection fait remonter les tentatives d’authentification anormales ou par force brute contre Aurora et RDS — un comportement qu’un groupe de sécurité ne peut pas intercepter car la connexion est légitime au niveau L4. Les résultats (findings) sont acheminés vers les tableaux de bord EventBridge, Security Hub et Detective.

Les groupes de sécurité opèrent uniquement aux niveaux L3-L4. Un groupe autorisant 0.0.0.0/0 sur le port 443 fait son travail lorsqu’il transmet une charge utile (payload) d’injection SQL — c’est précisément ce que WAF est conçu pour arrêter. La défense en profondeur signifie des groupes de sécurité plus WAF plus Shield plus GuardDuty, chacun couvrant une couche que les autres ne peuvent pas voir.

DDoS : Shield Standard et Advanced

AWS Shield Standard est automatique et gratuit, défendant chaque compte contre les attaques courantes de niveau L3/L4 (SYN floods, reflection). Il s’exécute silencieusement sans visibilité, sans atténuation personnalisée et sans voie d’intervention humaine.

AWS Shield Advanced (3 000 $/mois par organisation plus les frais de transfert de données) est requis chaque fois que le scénario mentionne un engagement proactif, une réponse dédiée, une protection des coûts contre le scaling induit par un DDoS, ou une visibilité des attaques en quasi-temps réel. Il couvre CloudFront, Global Accelerator, ALB, CLB, Route 53 et les Elastic IPs, et fournit un accès 24/7 à la Shield Response Team (SRT) — pré-autorisée via un rôle IAM — pour écrire des règles WAF en votre nom lors d’une attaque active. Lorsqu’une conception derrière un ALB et Route 53 nécessite une détection gérée et une réponse humaine, Shield Standard seul est insuffisant ; c’est le piège récurrent. Advanced offre également une protection des coûts pour le scaling déclenché par les attaques. Lorsque « LE MOINS d’effort de mise en œuvre » est mentionné et que l’architecture inclut déjà Global Accelerator ou un ALB, la réponse est généralement d’activer Shield Advanced et d’attacher les groupes de règles WAF gérés par AWS, plutôt que de créer des Lambda@Edge personnalisées ou de migrer de CDN.

Protection de la couche applicative : AWS WAF

AWS WAF s’attache à CloudFront, aux Application Load Balancers, à API Gateway, AppSync, App Runner et aux pools d’utilisateurs Cognito. Il ne protège pas directement les Network Load Balancers (placez CloudFront devant). Il inspecte le trafic L7 et applique des règles pour l’injection SQL, le XSS, les contraintes de taille, le géoblocage, la réputation d’IP et la limitation de débit (rate limiting). Les AWS Managed Rules fournissent des groupes de règles sélectionnés tels que AWSManagedRulesCommonRuleSet et AWSManagedRulesSQLiRuleSet sans avoir à écrire de regex.

Les règles basées sur le débit (rate-based rules) sont la principale défense contre les inondations HTTP (HTTP floods) et le credential stuffing — elles comptent les requêtes par fenêtre de cinq minutes par IP source (ou par en-tête transféré) et bloquent automatiquement les contrevenants :

Rules:
  - Name: RateLimitPerIP
    Priority: 1
    Statement:
      RateBasedStatement:
        Limit: 2000        # per 5-min window per IP
        AggregateKeyType: IP
    Action: { Block: {} }
    VisibilityConfig:
      CloudWatchMetricsEnabled: true
      MetricName: RateLimitPerIP
      SampledRequestsEnabled: true

WAF n’est pas un service DDoS — c’est le rôle de Shield. WAF complète les politiques de ressources (politiques de bucket S3 refusant le non-TLS, politiques de VPC endpoint limitant les buckets accessibles) et les contrôles réseau (security groups, NACLs) — une mauvaise configuration à n’importe quelle couche ne doit pas exposer les données.

Isolation réseau : Security Groups, NACLs, Network Firewall

Au sein d’un VPC, la défense est organisée en couches :

• Les Security groups sont stateful, s’appliquent aux ENI, fonctionnent uniquement sur autorisation (allow-only) et évaluent toutes les règles ensemble. Le trafic de retour est automatiquement autorisé, il n’est donc pas nécessaire d’ouvrir explicitement les ports éphémères.
• Les Network ACLs sont stateless, s’appliquent aux subnets, prennent en charge à la fois l’autorisation (allow) et le refus (deny), et sont évaluées par ordre numérique. Comme elles sont stateless, si vous autorisez le trafic entrant sur le port 443, vous devez également autoriser le trafic sortant sur les ports éphémères 1024–65535 pour les réponses. Oublier cela entraîne le rejet de toutes les réponses de manière subtile. Les Security groups n’ont pas ce problème.
• AWS Network Firewall fournit une inspection approfondie des paquets (deep packet inspection), des règles IPS compatibles avec Suricata et un filtrage de sortie basé sur les domaines, se positionnant entre les subnets et les IGW/TGW pour une inspection centralisée.

Supposer que les security groups seuls suffisent ignore les menaces au niveau du subnet et les contrôles du rayon d’impact (blast radius) ; supposer que les NACL seules suffisent ignore leur nature stateless et leur granularité grossière.

Catalogue des pièges

Politique de confiance (trust policy) oubliée. La politique de permissions d’un rôle accorde des capacités ; seule la politique de confiance accorde la possibilité d’assumer le rôle (assumability). Les deux doivent être configurées pour que l’accès inter-comptes ou de service à service fonctionne — l’appelant reçoit une erreur AccessDenied sur sts:AssumeRole, quelle que soit la permissivité de la politique d’identité.

Politique IAM sans politique de clé correspondante. kms:Decrypt dans IAM est nécessaire mais pas suffisant. La politique de la clé doit soit nommer le principal, soit déléguer à IAM avec Principal: {"AWS": "arn:aws:iam::ACCOUNT:root"}. Le partage d’AMI/snapshot chiffrés échoue si seul le partage de l’AMI est effectué et que la politique de la clé n’est pas mise à jour.

SCPs considérées comme des autorisations. Les SCPs plafonnent, elles n’accordent jamais de permissions. Une SCP Allow s3:* ne fait rien sans une politique d’identité correspondante. Inversement, une politique d’identité permissive est limitée par toute SCP Deny dans le chemin de l’organisation du compte.

Présomption de rotation automatique des clés KMS. Les clés gérées par le client (CMK) ne tournent pas tant que la rotation n’est pas activée ; le matériel de clé importé ne tourne jamais automatiquement.

Choix de SSE-S3 pour des données soumises à des contrôles de conformité. SSE-S3 n’a pas de politique de clé, pas de visibilité dans CloudTrail et pas de chemin de révocation — il ne répond à aucune exigence mentionnant « administrer », « contrôler », « auditer » ou « révoquer » la clé.

Chiffrement au repos considéré comme suffisant. Au repos et en transit sont indépendants. Un RDS avec KMS nécessite toujours require_secure_transport=ON et la validation de l’autorité de certification (CA) cliente.

Politique de bucket nommant les comptes individuellement. N’est pas scalable et se brise lors des changements d’organisation. Utilisez aws:PrincipalOrgID.

Clés d’accès en dur n’importe où. Dans les user data, les fichiers .env, les paramètres CloudFormation, Git — c’est toujours une erreur. Utilisez des profils d’instance, des rôles de tâche, des rôles d’exécution, IRSA/Pod Identity ou Roles Anywhere.

Utilisateur root pour le travail quotidien ou avec des politiques attachées. Root ne peut être contraint par IAM ou les SCPs ; ajouter une politique à root n’a aucun sens. Toute réponse qui le fait est fondamentalement incorrecte.

Utilisateurs IAM pour l’accès inter-comptes. Les utilisateurs IAM ne peuvent pas être assumés entre les comptes ; créez un rôle dans le compte cible et laissez le principal du compte source l’assumer.

NLB derrière WAF. WAF ne s’attache pas aux NLB. Placez le NLB derrière CloudFront si un filtrage L7 est nécessaire.

NACL sans règle de sortie pour les ports éphémères. Les NACL stateless nécessitent des règles explicites pour le chemin de retour. L’absence de la règle de sortie pour les ports 1024-65535 interrompt silencieusement toutes les réponses au trafic entrant sur le port 443.

Shield Standard pour un engagement géré. Standard est passif et sans accès au SRT ; seul Advanced répond aux besoins d’« engagement proactif géré » ou de « protection des coûts ».

← Intégration d’applications · Tous les domaines · Gestion →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Amazon →