Dernière révision : mai 2026
Configurez les services AWS figurant à l'examen SCS-C03 avec Terraform simple — un bloc à la fois, chacun étant lié à un domaine de l'examen. Le même code fonctionne sur OpenTofu.
À la fin de ce lab, vous aurez provisionné, avec du Terraform simple, les quatre primitives de sécurité que tout compte AWS devrait avoir dès le premier jour — une clé KMS gérée par le client avec rotation automatique, un IAM Access Analyzer recherchant les accès publics ou inter-comptes non intentionnels, GuardDuty activé avec des flux de renseignements sur les menaces, et un compartiment de logs d'audit centralisé dans lequel d'autres charges de travail écriront. Ceci est la base de référence sécurisée par défaut du SCS-C03.
Chaque ressource est du Terraform simple — le même code fonctionne sans modification sur OpenTofu. Pas de variables, pas de modules. Déposez les extraits dans un unique main.tf, exécutez terraform init, puis terraform apply étape par étape.
>= 1.5 ou OpenTofu >= 1.6.us-east-1.Trois des quatre services présentés ici sont gratuits pour les nouveaux comptes ; l'un d'eux génère une facture réelle :
Si vous maintenez cette base de référence active sur un compte réel, attendez-vous à payer environ 5 à 15 $/mois au total. Peu coûteux pour la visibilité qu'il vous offre. Détruisez après le lab si vous préférez ne pas le conserver.
Ouverture standard. Le SCS-C03 est indépendant du fournisseur et de la région en termes de portée, mais une base de référence sécurisée doit être appliquée par région — GuardDuty et Access Analyzer sont des services régionaux. La plupart des équipes choisissent une région principale (par exemple us-east-1) pour la base de référence et la répliquent via Terraform par région à mesure que le compte s'étend.
terraform {
required_version = ">= 1.5"
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.60"
}
}
}
provider "aws" {
region = "us-east-1"
default_tags {
tags = {
Project = "certlabpro-scs-c03"
ManagedBy = "terraform"
}
}
}
data "aws_caller_identity" "current" {}Le SCS-C03 teste la différence entre les clés KMS gérées par AWS (gratuites, rotation automatique, aucune politique de clé que vous contrôlez) et les clés gérées par le client (1 $/mois, vous possédez la politique, vous contrôlez la rotation, vous obtenez une visibilité d'audit sur chaque appel Encrypt/Decrypt via CloudTrail). La production devrait toujours opter pour les clés gérées par le client.
Nous activons la rotation annuelle (enable_key_rotation = true) et écrivons une politique de clé qui donne au compte root la capacité d'administrer la clé (le comportement par défaut d'AWS pour toute clé gérée par le client) et accorde explicitement au service IAM Access Analyzer la permission d'évaluer la politique de la clé. L'alias rend la clé référençable par un nom lisible par l'homme dans le code en aval au lieu d'un UUID — le SCS-C03 teste cette convention de nommage comme prérequis d'audit CloudTrail.
resource "aws_kms_key" "app_data" {
description = "Customer-managed key for application data encryption."
enable_key_rotation = true
deletion_window_in_days = 30
policy = jsonencode({
Version = "2012-10-17"
Statement = [
{
Sid = "EnableRootAccountAdmin"
Effect = "Allow"
Principal = { AWS = "arn:aws:iam::${data.aws_caller_identity.current.account_id}:root" }
Action = "kms:*"
Resource = "*"
},
{
Sid = "AllowAccessAnalyzerToDescribe"
Effect = "Allow"
Principal = { Service = "access-analyzer.amazonaws.com" }
Action = ["kms:DescribeKey", "kms:GetKeyPolicy"]
Resource = "*"
},
]
})
}
resource "aws_kms_alias" "app_data" {
name = "alias/certlabpro-scs-c03-app-data"
target_key_id = aws_kms_key.app_data.id
}Access Analyzer évalue continuellement les politiques basées sur les ressources (politiques de compartiment S3, politiques de clé KMS, politiques d'approbation de rôle IAM, permissions Lambda, politiques de file d'attente SQS, politiques de rotation Secrets Manager, et plus encore) et signale une constatation chaque fois qu'il détecte une ressource accessible depuis l'extérieur de votre compte ou de votre limite de confiance. Le domaine Détection des menaces et réponse aux incidents du SCS-C03 teste ce modèle exact — les constatations d'Access Analyzer sont le signal canonique pour "oh, ce compartiment est maintenant public".
type = "ACCOUNT" limite l'analyseur à votre compte ; type = "ORGANIZATION" nécessite AWS Organizations et s'étend à l'ensemble de l'organisation (la réponse multi-comptes du SCS-C03). Dans tous les cas, il est toujours gratuit et ne nécessite aucune configuration une fois activé.
resource "aws_accessanalyzer_analyzer" "main" {
analyzer_name = "certlabpro-scs-c03"
type = "ACCOUNT"
}GuardDuty est le service de détection des menaces géré par AWS. Il analyse continuellement les logs CloudTrail, les logs de flux VPC et les logs DNS par rapport aux flux de renseignements sur les menaces d'AWS — des listes publiées d'IPs malveillantes connues, de domaines de crypto-minage, d'infrastructures de commande et de contrôle, et de modèles de comportement de compte suspects. Les constatations sont étiquetées avec une gravité (Faible / Moyenne / Élevée) et un type analysable par machine comme Recon:EC2/PortProbeUnprotectedPort.
Nous activons le détecteur avec une fréquence de publication de 15 minutes (plus rapide que le défaut de 6 heures ; les questions du SCS-C03 concernant le MTTR supposent presque toujours une publication fréquente). Les plug-ins de protection basés sur IAM (MALWARE_PROTECTION_FOR_EC2, S3_DATA_EVENTS, etc.) coûtent plus cher et sont hors de portée de cette base de référence ; activez-les par charge de travail en production.
Les constatations sont publiées automatiquement sur EventBridge — c'est ainsi que l'automatisation en aval (notifications Slack, corrélation Security Hub, Lambdas d'auto-remédiation) s'y connecte. Le SCS-C03 teste cette chaîne constatations → EventBridge → réponse de manière répétée. Nous ne connectons pas l'aval ici, mais dès que l'étape 4 est terminée, GuardDuty commence à publier.
resource "aws_guardduty_detector" "main" {
enable = true
finding_publishing_frequency = "FIFTEEN_MINUTES"
}Chaque question Journalisation et surveillance de la sécurité du SCS-C03 s'attend à ce que vous disposiez d'un compartiment centralisé, chiffré et de type "écriture unique" dans lequel d'autres outils de sécurité — CloudTrail, logs de flux VPC, logs d'accès ELB, exportations GuardDuty, enregistreurs Config — écrivent. Le compartiment est chiffré avec la clé KMS gérée par le client de l'étape 2, l'accès public est entièrement bloqué, et une politique de compartiment impose que tout objet écrit doit passer par la clé de l'étape 2 (aucune écriture en texte clair n'est acceptée).
Nous utilisons le paramètre de propriété bucket-owner-enforced (le mode ACLs désactivé, recommandé par AWS depuis 2023) — c'est l'un des attributs de durcissement S3 les plus testés sur le SCS-C03 car il élimine toute une catégorie de mauvaises configurations ACL inter-comptes.
Avec le compartiment en place, la base de référence est complète : KMS pour les clés de chiffrement, Access Analyzer pour l'exposition non intentionnelle, GuardDuty pour la détection des menaces, et un compartiment d'audit pour tout ce qui doit être conservé pour examen de conformité. Chaque scénario multi-services du SCS-C03 s'attend à ce que vous ayez ces quatre éléments ; les questions plus avancées ajoutent Security Hub, Config, Inspector ou Macie en plus de cette base.
resource "aws_s3_bucket" "audit_logs" {
bucket_prefix = "certlabpro-scs-c03-audit-"
}
resource "aws_s3_bucket_public_access_block" "audit_logs" {
bucket = aws_s3_bucket.audit_logs.id
block_public_acls = true
block_public_policy = true
ignore_public_acls = true
restrict_public_buckets = true
}
resource "aws_s3_bucket_ownership_controls" "audit_logs" {
bucket = aws_s3_bucket.audit_logs.id
rule {
object_ownership = "BucketOwnerEnforced"
}
}
resource "aws_s3_bucket_server_side_encryption_configuration" "audit_logs" {
bucket = aws_s3_bucket.audit_logs.id
rule {
apply_server_side_encryption_by_default {
sse_algorithm = "aws:kms"
kms_master_key_id = aws_kms_key.app_data.arn
}
bucket_key_enabled = true # cuts KMS request costs ~99% on bulk writes
}
}
resource "aws_s3_bucket_versioning" "audit_logs" {
bucket = aws_s3_bucket.audit_logs.id
versioning_configuration {
status = "Enabled"
}
}
resource "aws_s3_bucket_policy" "audit_logs_require_kms" {
bucket = aws_s3_bucket.audit_logs.id
policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Sid = "DenyUnencryptedWrites"
Effect = "Deny"
Principal = "*"
Action = "s3:PutObject"
Resource = "${aws_s3_bucket.audit_logs.arn}/*"
Condition = {
StringNotEquals = {
"s3:x-amz-server-side-encryption" = "aws:kms"
}
}
}]
})
}terraform destroy supprime tout dans ce lab. Deux remarques :
deletion_window_in_days = 30, ce qui signifie que destroy la planifie pour une suppression dans 30 jours — elle n'est pas immédiatement supprimée (c'est le modèle de sécurité prescrit par le SCS-C03 ; la suppression KMS est irréversible). Pendant les 30 jours, vous pouvez annuler via la console. Pour la supprimer réellement, vous devez également attendre la fin de cette période. AWS continue de facturer 1 $/mois pendant cette période.force_destroy = false — si vous y avez collecté des logs, videz-le avant de le détruire (aws s3 rm s3://<bucket> --recursive).Le SCS-C03 couvre plus de terrain qu'un seul lab ne peut en contenir — AWS Config (évaluation continue de la conformité), Security Hub (agrégation centralisée des constatations), Macie (découverte de PII dans S3), Inspector (analyse de vulnérabilités EC2/Lambda), Detective (investigation des menaces), WAF + Shield (protection des périphéries), Network Firewall, Network Access Analyzer, Cognito (identité des utilisateurs), Secrets Manager + Systems Manager Parameter Store, ACM (TLS), Firewall Manager (application des politiques multi-comptes), et l'ensemble de l'espace des clés matérielles CloudHSM.
Nous nous en tenons aux quatre primitives ci-dessus car elles constituent la base de référence du premier jour sur laquelle tout le reste se construit. Les règles Config écrivent les constatations dans Security Hub, qui les corrèle avec les constatations GuardDuty, qui pointent vers des ressources protégées par des clés KMS, avec des problèmes de politique détectés par Access Analyzer — et tout cela atterrit dans le compartiment d'audit pour examen de conformité. Construisez d'abord les fondations ; ajoutez le reste au fur et à mesure que le profil de risque de la charge de travail l'exige.
Pour une couverture service par service, consultez les sections Parcourir, Guide et Editorial de cette page de certification. Un lab de suivi ajoutant Security Hub + Config + la chaîne d'auto-remédiation GuardDuty-vers-EventBridge serait une prochaine étape naturelle.