Amazon SCS-C02: Protection des données et S3 — Guide d'étude

By Laurynas Brazys · 24 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

Fait partie du AWS Security Specialty SCS-C02 — Guide d’étude. 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.

Stratégies de compartiment S3, ARN de ressource et refus explicites

Une stratégie de compartiment S3 est un document JSON basé sur les ressources, évalué conjointement avec les stratégies basées sur l’identité. Deux règles dominent son comportement. Premièrement, un Deny explicite l’emporte toujours : peu importe le nombre de déclarations Allow existantes, un Deny correspondant bloque la requête. Deuxièmement, l’élément Resource doit correspondre précisément au modèle d’ARN de l’action. Les actions au niveau du compartiment comme s3:ListBucket opèrent sur arn:aws:s3:::my-bucket, tandis que les actions au niveau de l’objet comme s3:GetObject et s3:PutObject opèrent sur arn:aws:s3:::my-bucket/*. Une erreur de configuration courante consiste à accorder s3:GetObject sur arn:aws:s3:::my-bucket sans le suffixe /* — l’appel d’API cible un ARN d’objet, aucune déclaration ne correspond, et la requête est refusée par défaut.

La stratégie suivante refuse tout accès non-TLS et accorde un accès en lecture pour un rôle spécifique, en utilisant correctement les deux formes d’ARN.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyInsecureTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::reports",
        "arn:aws:s3:::reports/*"
      ],
      "Condition": { "Bool": { "aws:SecureTransport": "false" } }
    },
    {
      "Sid": "AllowAnalyticsRead",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:role/Analytics" },
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::reports/*"
    }
  ]
}

Un piège fréquent est d’essayer de « créer une exception » en ajoutant un Allow après un Deny général. Les déclarations de stratégie ne sont pas sensibles à l’ordre, et la logique d’évaluation d’IAM renvoie Deny dès qu’un refus correspondant existe. La correction appropriée consiste à restreindre le Deny — par exemple, via un NotPrincipal ou une Condition — plutôt que d’ajouter une déclaration permissive en dessous.

Règles de cycle de vie, expiration d’objets et Vault Lock

Les règles de cycle de vie S3 automatisent les transitions de classe de stockage et l’expiration des objets. Pour satisfaire aux exigences de rétention — comme la suppression des PII 30 jours après leur ingestion — attachez une règle qui fait expirer les versions actuelles des objets après 30 jours et supprime définitivement les versions non actuelles peu de temps après. Pour les métadonnées associées écrites dans DynamoDB, activez l’attribut TTL de DynamoDB afin que les éléments s’auto-suppriment selon le même calendrier ; la combinaison de ces deux mécanismes est efficace sur le plan opérationnel car aucun code Lambda, planificateur ou script de nettoyage personnalisé n’est requis.

LifecycleConfiguration:
  Rules:
    - Id: ExpirePIIAfter30Days
      Status: Enabled
      Filter: { Prefix: "ingest/" }
      Expiration: { Days: 30 }
      NoncurrentVersionExpiration: { NoncurrentDays: 1 }

Pour les données archivées soumises à une rétention réglementaire, S3 Glacier Vault Lock fournit un contrôle WORM distinct au niveau du coffre-fort (vault). Une fois la stratégie Vault Lock validée (un processus en deux étapes, initier/compléter, en 24 heures), elle ne peut plus être modifiée, même par l’utilisateur root du compte. Ceci est distinct d’Object Lock, qui opère au niveau de l’objet S3.

Block Public Access et CloudFront OAC

S3 Block Public Access (BPA) est un ensemble de quatre commutateurs au niveau du compte et du compartiment qui outrepassent toute ACL ou stratégie qui accorderait autrement un accès public. Activez les quatre au niveau du compte et renforcez cette configuration avec une SCP, par exemple en refusant s3:PutBucketPublicAccessBlock lorsque cela assouplirait les paramètres. Cette défense en profondeur empêche un ingénieur d’exposer à nouveau accidentellement un compartiment via une ACL permissive.

Pour le contenu public servi via CloudFront, le modèle correct est Origin Access Control (OAC). OAC signe les requêtes de CloudFront vers S3 en utilisant SigV4 ; la stratégie de compartiment n’autorise alors que le principal de service de la distribution CloudFront. Se fier uniquement à CloudFront sans OAC (ou l’ancien OAI) laisse l’URL S3 directement accessible, annulant les contrôles d’accès et le WAF du CDN. Le compartiment doit rester privé, le BPA activé, et la stratégie limitée à l’ARN de la distribution :

{
  "Effect": "Allow",
  "Principal": { "Service": "cloudfront.amazonaws.com" },
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::site-assets/*",
  "Condition": {
    "StringEquals": {
      "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/E1ABCXYZ"
    }
  }
}

S3 Object Lock et réplication inter-régions

Object Lock applique une sémantique WORM sur des objets individuels et exige que le versioning soit activé et qu’Object Lock soit activé lors de la création du compartiment (il ne peut pas être ajouté ultérieurement à un compartiment existant sans contacter AWS). Deux modes de rétention existent :

• Mode Gouvernance : les principaux privilégiés disposant de la permission s3:BypassGovernanceRetention peuvent raccourcir ou supprimer la rétention.

• Mode Conformité : aucun utilisateur — y compris l’utilisateur root du compte AWS — ne peut supprimer ou écraser l’objet, ni réduire sa période de rétention jusqu’à son expiration. Une conservation légale (legal hold) peut en outre être appliquée et supprimée indépendamment par les utilisateurs disposant de la permission s3:PutObjectLegalHold.

Le mode Conformité est le bon choix lorsque l’exigence est une immuabilité absolue contre toutes les identités. Pour étendre cette garantie à plusieurs Régions, associez Object Lock à S3 Replication. Les objets répliqués conservent leur configuration de verrouillage dans le compartiment de destination (qui doit également avoir Object Lock activé), de sorte qu’un événement à l’échelle d’une Région ou une tentative de suppression malveillante ne peut pas compromettre la copie conservée.

Macie et Athena pour la découverte et l’investigation

Amazon Macie utilise des identifiants de données gérés et personnalisés pour analyser les objets S3 à la recherche de PII, PHI, d’identifiants et d’autres modèles de données sensibles. Il signale les résultats à Security Hub et EventBridge, permettant une remédiation automatisée telle que la mise en quarantaine d’objets avec une stratégie de compartiment restrictive basée sur les balises. Activez Macie dans chaque Région qui stocke des données client et déléguez l’administration via AWS Organizations pour centraliser les résultats.

Amazon Athena fournit un service SQL sans serveur sur les données dans S3, et c’est l’outil standard pour interroger les événements de données au niveau objet de CloudTrail. Pour enquêter sur qui a accédé à un objet S3 spécifique, activez les événements de données CloudTrail pour le compartiment, livrez les journaux dans un compartiment S3 central et interrogez-les avec Athena :

SELECT eventTime, userIdentity.arn, sourceIPAddress, requestParameters
FROM cloudtrail_logs
WHERE eventName IN ('GetObject','DeleteObject')
  AND requestParameters LIKE '%reports/q3-financials.pdf%'
  AND eventTime > '2024-01-01T00:00:00Z';

Pièges courants et leurs causes profondes

• /* manquant sur les ARN d’objet : Les appels d’API au niveau de l’objet sont évalués par rapport à compartiment/clé, et non à l’ARN du compartiment. Sans /*, aucune déclaration ne correspond et IAM renvoie un refus implicite, ce qui se manifeste par des erreurs 403 inattendues sur GetObject même lorsque le « compartiment » semble autorisé.

• Ajout d’un Allow après un Deny explicite : L’évaluation IAM ne dépend pas de l’ordre ; toute correspondance avec un Deny entraîne un refus immédiat. La solution consiste à restreindre la portée du refus (via Condition, NotPrincipal ou NotResource), et non à ajouter des déclarations permissives.

• CloudFront sans OAC ou sans politique de compartiment restrictive : L’URL d’origine S3 reste accessible directement, contournant les URL signées, les règles WAF et les restrictions géographiques. Activez toujours le BPA sur le compartiment d’origine et limitez s3:GetObject au principal de service CloudFront via AWS:SourceArn.

• Supposer qu’Object Lock peut être activé sur un compartiment existant : Object Lock doit être configuré lors de la création du compartiment. La mise à niveau nécessite de créer un nouveau compartiment avec Object Lock activé et de migrer les données.

• Confusion entre le mode gouvernance et le mode conformité : Le mode gouvernance n’empêche pas un utilisateur privilégié de supprimer la rétention ; seul le mode conformité bloque même le compte racine.

Problème pratique : Scénario d’utilisation

Scénario : Meridian Financial stocke des relevés clients, des journaux de transactions et des archives de conformité à long terme dans plusieurs compartiments S3 répartis sur deux régions AWS. Leur environnement utilise CloudFront pour les portails clients, la journalisation inter-comptes et les transitions de cycle de vie automatisées vers des classes de stockage d’archivage pour la rétention réglementaire.

Défi : Un audit interne récent a révélé plusieurs compartiments avec des politiques incohérentes exposant des informations d’identification personnelle (PII), aucune rétention immuable pour les enregistrements archivés, et aucune méthode centralisée pour découvrir où se trouvent les objets sensibles à travers les comptes et les régions.

Approche recommandée :

1. Activer S3 Block Public Access au niveau du compte et du compartiment et déployer CloudFront Origin Access Control (OAC) ; renforcer la politique de compartiment pour n’autoriser GetObject qu’à partir du principal OAC de CloudFront en utilisant des ARN de ressource précis et ajouter des refus explicites pour toute requête ne provenant pas de l’OAC.
2. Imposer le chiffrement côté serveur avec AWS KMS en exigeant kms:Encrypt/kms:GenerateDataKey dans une politique de compartiment et ajouter des refus explicites pour les requêtes PutObject qui n’incluent pas x-amz-server-side-encryption et le kms:context requis pour empêcher les téléversements non chiffrés.
3. Configurer S3 Object Lock en mode conformité pour les compartiments qui doivent être immuables et activer la réplication inter-régions (CRR) avec des règles de réplication qui préservent les métadonnées de verrouillage d’objet afin que les objets répliqués restent immuables dans la région de reprise après sinistre (DR).
4. Créer des règles de cycle de vie S3 (Lifecycle Rules) pour faire passer les objets anciens vers les classes de stockage S3 Glacier et définir l’expiration des objets pour les fenêtres de rétention autorisées ; pour les archives qui doivent être légalement immuables, les placer dans des coffres-forts (vaults) Amazon S3 Glacier et appliquer des politiques Glacier Vault Lock pour imposer une rétention non réinscriptible (write-once).
5. Déployer Amazon Macie sur l’ensemble des comptes pour découvrir et classifier les PII, activer S3 Inventory et interroger les résultats avec Amazon Athena pour des requêtes d’investigation, et déclencher une remédiation automatisée (Lambda/Step Functions) pour étiqueter, mettre en quarantaine ou déplacer les objets sensibles dans des compartiments verrouillés et chiffrés.

Justification : Cette approche multicouche applique le moindre privilège et le chiffrement, fournit une rétention immuable et une durabilité inter-régions pour la conformité, et utilise Macie/Athena pour la découverte centralisée et la remédiation automatisée, s’alignant ainsi sur les meilleures pratiques AWS en matière de protection des données et de gestion du cycle de vie.

Amazon Macie : Découverte automatisée, tâches de classification et listes d’autorisation

Amazon Macie est un service de sécurité des données géré qui utilise l’apprentissage automatique (machine learning) et la reconnaissance de formes pour découvrir des données sensibles — informations d’identification personnelle (PII), numéros de carte de paiement (PAN), informations d’identification et types de données personnalisés définis par des expressions régulières (regex) — stockées dans Amazon S3. Macie fonctionne selon deux modes complémentaires qui sont souvent confondus.

La découverte automatisée de données sensibles est un processus peu coûteux et continu qui échantillonne des objets dans chaque compartiment du compte (ou au sein d’une organisation lorsque Macie est délégué à un compte de sécurité). Il établit un score de sensibilité et un inventaire par compartiment. C’est le point de départ correct lorsque vous avez des milliers de compartiments et que vous ne savez pas encore où se trouvent les données sensibles, car cela minimise les coûts et la charge administrative en échantillonnant plutôt qu’en analysant chaque objet.

Les tâches de classification (tâches de découverte de données sensibles) sont des analyses approfondies, ponctuelles ou planifiées, ciblant des compartiments spécifiques. Une fois que la découverte automatisée signale qu’un compartiment contient des données sensibles, vous créez une tâche de classification limitée à ce compartiment pour une analyse exhaustive. Le modèle canonique est donc le suivant : activer la découverte automatisée à l’échelle de l’organisation, puis effectuer des tâches de classification uniquement sur les compartiments signalés.

Les listes d’autorisation sont le mécanisme permettant de supprimer les correspondances connues comme étant bénignes. Si un lac de données (data lake) contient des numéros de carte de paiement (PAN) de test synthétiques (par exemple, la plage de cartes de test bien connue 4111 1111 1111 1111), Macie signalera chaque occurrence. Réécrire les données ou les déplacer est coûteux et perturbateur ; l’approche correcte consiste à définir une liste d’autorisation Macie — soit une liste en texte brut de valeurs exactes, soit une expression régulière (regex) — et à l’associer à vos tâches de classification et à votre configuration de découverte automatisée. Les correspondances avec la liste d’autorisation sont exclues des résultats, tandis que les véritables PAN continuent de déclencher des alertes.

Problème pratique : Scénario d’utilisation

Scénario : Meridian Financial gère un environnement AWS multi-comptes avec des centaines de compartiments S3 stockant des journaux de transactions, des documents clients et des archives à long terme déplacées vers S3 Glacier. Leur équipe de sécurité a mis en place un chiffrement et une journalisation de base, mais ne dispose d’aucune découverte centralisée des données sensibles ni de contrôles de rétention cohérents entre les comptes.

Défi : Un compartiment récemment découvert, exposé publiquement, contenait des dossiers clients archivés avec des informations d’identification personnelle (PII) suite à une politique de compartiment erronée et une transition de cycle de vie vers S3 Glacier. Meridian doit maintenant trouver toutes les données sensibles, remédier aux expositions et appliquer une rétention d’archivage conforme à l’avenir.

Approche recommandée :

1. Activer Amazon Macie sur l’ensemble de l’AWS Organization et activer la découverte automatisée S3 pour que Macie évalue en continu les compartiments et les objets à la recherche de données sensibles et de configurations à risque.
2. Créer des tâches de classification Macie qui ciblent tous les compartiments S3 ; configurer des identifiants de données sensibles personnalisés pour les numéros de sécurité sociale et les numéros de compte, et mettre en place des listes d’autorisation (allow lists) pour exclure les données de test connues, les fichiers de fournisseurs et les comptes de service.
3. Utiliser S3 Inventory pour énumérer les objets dans S3 Glacier, puis exécuter des opérations S3 Batch Operations pour restaurer temporairement uniquement les objets signalés par l’inventaire pour l’analyse Macie, afin que les tâches de classification puissent inspecter le contenu archivé dans Glacier.
4. Automatiser la remédiation en envoyant les résultats (findings) de Macie à Amazon EventBridge et Security Hub ; déclencher des fonctions Lambda pour appliquer des politiques de compartiment S3 sécurisées, activer S3 Block Public Access, supprimer les ACL publiques et marquer les compartiments pour révision.
5. Mettre en œuvre une rétention et une prévention durables : activer S3 Versioning et S3 Object Lock (modes gouvernance/conformité) sur les compartiments critiques, imposer le chiffrement SSE-KMS avec des CMK via une politique de compartiment, et déployer des SCP (Service Control Policies) AWS Organizations pour bloquer les ACL publiques et exiger le chiffrement et Object Lock le cas échéant.
6. Activer les événements de données CloudTrail pour S3 et intégrer les résultats dans un SIEM pour l’alerte et la planification périodique des tâches de classification Macie afin d’assurer une couverture continue.

Justification : Cette approche utilise Macie pour la découverte automatisée et la classification ciblée (avec des listes d’autorisation), restaure les objets Glacier uniquement lorsque c’est nécessaire pour l’inspection, automatise la remédiation via EventBridge/Lambda et impose une rétention immuable et un chiffrement avec Object Lock et KMS, s’alignant ainsi sur les meilleures pratiques AWS en matière de détection, de remédiation et de contrôles préventifs.

# Example allow list (regex form) matching common test PANs
Type: Regex
Regex: '^4111[- ]?1111[- ]?1111[- ]?1111$|^5555[- ]?5555[- ]?5555[- ]?4444$'
Name: synthetic-test-pans

Traiter les résultats bruts de Macie comme une vérité absolue sans configurer de listes d’autorisation ou de suppression produit une fatigue d’alerte et peut masquer de réels incidents au milieu du bruit généré par les données synthétiques — c’est pourquoi « faire simplement confiance aux résultats » est la mauvaise réponse dans les environnements sujets aux faux positifs.

Intégration des résultats Macie avec EventBridge

Macie publie chaque résultat (finding) sur Amazon EventBridge via la source aws.macie. Cela vous permet de router les résultats sans avoir à interroger l’API de Macie. Une règle typique transfère les résultats de type Policy à SNS pour les notifications d’astreinte et envoie les résultats de type SensitiveData à AWS Security Hub pour agrégation.

{
  "source": ["aws.macie"],
  "detail-type": ["Macie Finding"],
  "detail": { "severity": { "description": ["High"] } }
}

Les cibles de la règle sont des rubriques SNS, Security Hub, ou une fonction Lambda pour une remédiation personnalisée (par exemple, appliquer automatiquement une politique de compartiment restrictive sur le compartiment incriminé).

Conditions de politique de compartiment pour les périmètres d’organisation

S3 Block Public Access (BPA) ne bloque que l’accès provenant de l’internet public ou de principaux anonymes. Il n’empêche pas un principal authentifié dans un autre compte AWS ou une autre AWS Organization d’accéder au compartiment si une politique de compartiment ou une ACL accorde un tel accès. Se fier uniquement à BPA est donc incorrect lorsque l’exigence est d’empêcher l’accès inter-organisations — vous devez combiner les politiques de compartiment avec des politiques de contrôle de service (SCP) au niveau d’Organizations.

Deux clés de condition IAM rendent l’application des périmètres d’organisation précise :

• aws:ResourceOrgID : l’ID de l’organisation qui possède la ressource à laquelle on accède. Utilisé dans les politiques d’identité/SCP pour empêcher les principaux de toucher à des ressources en dehors de votre organisation.

• aws:PrincipalOrgID : l’ID de l’organisation du principal appelant. Utilisé dans les politiques de compartiment pour refuser l’accès aux principaux extérieurs à votre organisation.

• aws:SourceOrgPaths : le chemin de l’UO (Unité d’Organisation) du principal source, permettant de limiter la portée à une UO spécifique (par exemple, seule l’UO « Production » peut écrire dans un compartiment de conformité).

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyOutsideOrg",
    "Effect": "Deny",
    "Principal": "*",
    "Action": ["s3:GetObject", "s3:DeleteObject"],
    "Resource": "arn:aws:s3:::acme-compliance/*",
    "Condition": {
      "StringNotEqualsIfExists": {
        "aws:PrincipalOrgID": "o-abcd1234",
        "aws:SourceOrgPaths": "o-abcd1234/r-root/ou-prod-xyz/"
      }
    }
  }]
}

Associez cela à une SCP qui refuse s3:DeleteObject* sur les ressources où aws:ResourceOrgID ne correspond pas à votre organisation, et l’exfiltration ou la suppression inter-organisations devient impossible, même si une politique de compartiment est accidentellement assouplie.

S3 Object Lock : Mode Conformité et Gestion des versions

Object Lock applique une sémantique WORM (write-once-read-many) sur les versions d’objets individuelles. Il exige que S3 Versioning (la gestion des versions) soit activé sur le compartiment (Object Lock sans gestion des versions n’est pas possible — le verrouillage protège un ID de version spécifique, pas la clé).

• Mode Gouvernance : les utilisateurs disposant de la permission s3:BypassGovernanceRetention peuvent raccourcir ou supprimer la rétention. Convient pour l’application de politiques internes.

• Mode Conformité : aucun principal, y compris le root du compte AWS, ne peut raccourcir, supprimer ou effacer la version de l’objet avant l’expiration de la période de rétention. C’est le bon choix pour les exigences réglementaires d’immuabilité (archivage SEC 17a-4, FINRA, HIPAA).

La rétention peut être définie par objet (date Retain-Until) ou via une configuration de rétention par défaut au niveau du compartiment. Les conservations légales (Legal Holds) sont des verrouillages distincts et indéfinis qui persistent jusqu’à ce qu’ils soient explicitement supprimés par un principal détenant la permission s3:PutObjectLegalHold.

aws s3api put-object-retention \
  --bucket acme-audit-logs \
  --key 2024/transactions.parquet \
  --retention '{"Mode":"COMPLIANCE","RetainUntilDate":"2031-01-01T00:00:00Z"}'

S3 Glacier Vault Lock : Correction des erreurs de stratégie avant la finalisation du verrouillage

Vault Lock sur S3 Glacier applique des stratégies d’accès immuables au coffre. Le processus comporte deux appels : initiate-vault-lock place la stratégie dans un état en cours (in-progress) avec une fenêtre de 24 heures, et complete-vault-lock la rend permanente. Si une faute de frappe est découverte pendant la fenêtre de 24 heures — par exemple, un Principal trop permissif — la solution corrective la plus appropriée et la moins coûteuse est :

aws glacier abort-vault-lock --account-id - --vault-name compliance-archive
aws glacier initiate-vault-lock --account-id - --vault-name compliance-archive \
  --policy file://corrected-policy.json

abort-vault-lock annule le verrouillage en cours sans frais, vous permettant de réinitier le processus avec la stratégie corrigée. Les « correctifs » alternatifs — supprimer et recréer le coffre (ce qui nécessite de supprimer les 10 To d’archives et de les réimporter, entraînant des frais de récupération et de transfert), ou attendre la finalisation du verrouillage pour ensuite tenter de le contourner — sont une perte de ressources ou impossibles. Une fois que complete-vault-lock est exécuté, la stratégie est immuable pour toujours ; l’annulation (abort) n’est valide que pendant la fenêtre de l’état en cours.

Piège connexe : Chaîne de confiance DNSSEC

Un piège inter-domaines courant concerne DNSSEC sur Route 53. L’activation de la signature DNSSEC sur une zone hébergée pour un sous-domaine génère une clé de signature de clé (Key Signing Key - KSK) et un enregistrement DS correspondant. Cet enregistrement DS doit être publié dans la zone parente ; sans lui, les résolveurs ne peuvent pas valider la chaîne de confiance et soit traitent les réponses comme invalides (bogus), soit se rabattent sur une résolution non sécurisée, perturbant ainsi le DNS pour les clients qui effectuent la validation. Activer la signature sans exporter l’enregistrement DS et l’insérer au niveau du bureau d’enregistrement (registrar) ou de la zone parente correspond à un état de configuration incomplète, et non à un déploiement DNSSEC fonctionnel.

← Chiffrement · Tous les domaines · Réseau et sécurité VPC →

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

Parcourir Amazon →