AWS — S3 & KMS¶

Rôle¶

Usage AWS ciblé pour Indio, sur un compte AWS dédié Indio (région principale eu-west-3), réparti sur deux dépôts Terraform indépendants, sans lien technique entre eux :

• /root/aws-s3 (repo GitLab indio/iac/aws-s3) — socle cloud « core » de l'infra : bucket S3 pour le state Terraform distant + bucket S3 d'archivage (logs/sauvegardes) avec cycle de vie complet. Appliqué et vérifié en direct à ce jour (voir Architecture).
• /root/aws-s3-siem — projet séparé, un lab pédagogique de détection SIEM (« Lab étudiant », selon sa propre documentation) démontrant la remontée d'un événement de sécurité S3 jusqu'à une alerte Kibana. Le code Terraform est complet et cohérent, mais rien n'indique qu'il ait jamais été réellement déployé dans le compte AWS (voir Architecture) — à ne pas confondre avec le socle core.

Architecture¶

aws-s3 — socle core (appliqué, vérifié en direct)¶

Cycle de vie de backup_archive (transitions configurables, valeurs par défaut) :

Standard --30j--> STANDARD_IA --90j--> GLACIER --180j--> DEEP_ARCHIVE --2555j (~7 ans)--> expiration

flowchart LR
    CTL["Nœud de contrôle<br/>terraform apply<br/>profils AWS locaux default/s3"]
    SEG["seg-sauvegarde<br/>10.100.3.16/28<br/>agents backup"]
    FW["T0-Edge / FortiGate"]

    subgraph AWS["Compte AWS dédié Indio — eu-west-3"]
        TFSTATE[("Bucket S3 tfstate<br/>versionné, SSE-S3")]
        ARCHIVE[("Bucket S3 backup_archive<br/>SSE-S3")]
        SIA["STANDARD_IA"]
        GL["GLACIER"]
        DA["DEEP_ARCHIVE"]
        EXP(["Expiration"])
    end

    CTL -->|"apply (aws-s3)"| TFSTATE
    CTL -->|"apply (aws-s3)"| ARCHIVE
    SEG --> FW
    FW -->|"HTTPS — règle DFW<br/>sauvegarde-to-aws-s3"| ARCHIVE
    ARCHIVE -->|30j| SIA
    SIA -->|90j| GL
    GL -->|180j| DA
    DA -->|"2555j (~7 ans)"| EXP

Vérifié en direct le 2026-07-19 (lecture seule, aws s3api get-bucket-versioning / get-bucket-lifecycle-configuration, profil IAM s3) : la configuration réelle des deux buckets correspond exactement au code — versioning Enabled sur tfstate, cycle de vie 30j → STANDARD_IA, 90j → GLACIER, 180j → DEEP_ARCHIVE, expiration 2555j, identique à main.tf. Aucune dérive.

Les deux buckets sont vides (0 objet), également vérifié en direct :

• tfstate : aucun projet Terraform de l'infra (une trentaine de dépôts) n'utilise encore ce backend distant — le state reste 100 % local partout (voir Points de vigilance).
• backup_archive : aucune tâche applicative n'y écrit encore, malgré le chemin réseau déjà ouvert côté NSX (règle DFW sauvegarde-to-aws-s3, zone admin → Internet en HTTPS depuis seg-sauvegarde, voir NSX) — la cible de consommation réelle (Veeam ? un script d'archivage dédié ?) n'a jamais été précisée ni implémentée à ce jour.

backend.tf.example fournit le modèle pour qu'un autre projet Terraform utilise ce bucket comme backend distant : verrouillage natif S3 (use_lockfile = true, sans DynamoDB, nécessite Terraform ≥ 1.10), chiffrement activé — non encore adopté par aucun projet.

aws-s3-siem — lab de détection (état de déploiement non confirmé)¶

Objectif du lab : journaliser, transporter et détecter un événement de sécurité S3 jusqu'à une alerte Kibana, avec deux chemins d'alerte volontairement redondants.

flowchart TD
    ATTACK["attack/simulate.sh<br/>3 scénarios simulés"]
    DATA[("Bucket S3 data<br/>cible simulée")]
    CT["CloudTrail<br/>mono-région<br/>management + data events (bucket data)"]
    LOGS[("Bucket S3 logs<br/>rétention 7j")]
    SQS{{"SQS notifications<br/>+ DLQ (5 échecs)"}}
    AGENT["Elastic Agent on-prem<br/>intégration AWS S3/SQS<br/>via proxy Squid 10.100.10.4:3128"]
    ES[("Elasticsearch")]
    KIB["Kibana<br/>alerte Elastic Security"]
    EB["EventBridge<br/>StopLogging/DeleteTrail/PutEventSelectors"]
    SNS{{"SNS topic alerts"}}
    MAIL["Email (alert_email)"]
    BUDGET["Budget guardrail<br/>5 USD/mois — 80% et 100%"]

    ATTACK --> DATA
    DATA --> CT
    CT --> LOGS
    LOGS -->|"S3 Event Notification"| SQS
    SQS --> AGENT
    AGENT --> ES
    ES --> KIB
    CT -.->|"évènement anti-forensics"| EB
    EB --> SNS
    SNS --> MAIL
    BUDGET -.-> MAIL

• CloudTrail mono-région : management events complets + data events S3 filtrés au seul bucket data (reste dans le free tier).
• IAM : un utilisateur dédié elastic_agent, strictement scopé en lecture seule (sqs:ReceiveMessage/DeleteMessage/ChangeMessageVisibility/GetQueueAttributes sur la queue + s3:GetObject sur le bucket logs uniquement — jamais de Resource: "*").
• Chemin anti-forensics indépendant : une règle EventBridge sur StopLogging/DeleteTrail/PutEventSelectors publie sur un topic SNS (abonnement email) — volontairement séparé du chemin SIEM, car couper CloudTrail couperait aussi la détection côté Elastic.
• Garde-fou budget : aws_budgets_budget de type COST, 5 USD/mois, notifications à 80 % et 100 %. Sans filtre de coût (aucun cost_filter dans budget.tf) : s'il était appliqué, ce budget surveillerait la dépense totale du compte AWS, pas seulement les ressources de ce lab — donc aussi, entre autres, l'usage KMS/S3 du socle core.
• Simulation d'attaque (attack/simulate.sh + cleanup.sh) : 3 scénarios — bucket rendu public, 500× GetObject (exfiltration simulée), arrêt de CloudTrail — avec remise en état automatisée.
• Règles de détection fournies en NDJSON (detections/s3-threat-rules.ndjson, 3 règles Elastic Security, mappées MITRE ATT&CK T1530/T1020).
• Ce lab a sa propre documentation MkDocs (aws-s3-siem/mkdocs.yml, thème readthedocs) sous docs/ — seules 3 pages sur 7 annoncées dans la nav existent réellement à ce jour (index.md, architecture.md, deployment.md).

Provisioning Terraform¶

aws-s3 (main.tf, variables.tf, versions.tf, backend.tf.example) :

• variables.tf : aws_region (défaut eu-west-3), aws_account_id (identifiant du compte — non reproduit dans cette page), paramètres de transition du cycle de vie (30/90/180/2555 jours par défaut).
• Provider hashicorp/aws >= 5.0.0, Terraform >= 1.5.0.
• Sorties : tfstate_bucket, backup_archive_bucket.
• 2 commits seulement (6ddf55f création, dc4155b tiering complet du cycle de vie) — projet stable depuis son premier apply le 2026-07-15.

aws-s3-siem/terraform (9 fichiers) :

Aucune ressource KMS dans l'un ou l'autre dépôt (voir Rôle).

Configuration Ansible¶

Aucune dans les deux dépôts — Terraform seul, pas de dossier ansible/. La consommation applicative des ressources créées ici (Elastic Agent, Vault) est configurée dans les dépôts elk et vault, hors périmètre de cette page.

Procédure manuelle¶

Plusieurs étapes de ce périmètre AWS sont volontairement hors Terraform, à la main :

• Clé KMS alias/vault-unseal : créée hors Terraform (voir Rôle), jamais reprise en IaC depuis. Aucune rotation ni suppression possible depuis aws-s3/aws-s3-siem pour cette clé.
• Pattern IAM récurrent : à chaque nouveau besoin AWS, c'est le user (pas l'agent Terraform/l'automatisation) qui crée l'utilisateur IAM dédié et attache la policy scopée fournie. Confirmé en direct aujourd'hui : ni le profil local default (user/kms) ni le profil s3 (user/s3) n'ont le moindre droit iam:* — AccessDenied systématique, y compris pour lire leur propre policy attachée (iam:ListAttachedUserPolicies, iam:GetUserPolicy). C'est un choix de scoping strict assumé, pas une négligence : ces comptes ne peuvent agir que dans leur périmètre (KMS seul pour l'un, S3/SQS/IAM du lab pour l'autre côté code), jamais s'auto-inspecter ni s'élargir eux-mêmes.
• Configuration locale des profils AWS (~/.aws/credentials) : deux profils distincts, default (usage KMS) et s3 (usage buckets), jamais un seul profil réutilisé pour les deux usages.
• Côté aws-s3-siem, une fois terraform apply réellement lancé (voir avertissement en Architecture) :
  1. Confirmer l'abonnement SNS reçu par email (topic <name_prefix>-alerts) — aucune erreur visible côté Terraform si cette étape est oubliée, l'abonnement reste juste en PendingConfirmation et aucune alerte anti-forensics ni notification budgétaire n'est reçue.
  2. Configurer l'intégration AWS côté Elastic Agent (Fleet → Add integration → AWS → input S3 en mode SQS, avec proxy_url = http://10.100.10.4:3128 obligatoire — voir Proxy Squid & DNS).
  3. Importer les règles de détection NDJSON dans Kibana.
  4. Lancer attack/simulate.sh puis cleanup.sh pour valider et nettoyer le scénario.

Procédure de déploiement¶

aws-s3 :

cd /root/aws-s3
terraform init
terraform plan
terraform apply

aws-s3-siem :

cd /root/aws-s3-siem/terraform
terraform init
terraform plan  -var="alert_email=<email>"
terraform apply -var="alert_email=<email>"

Les étapes de configuration post-apply (confirmation SNS, intégration Elastic Agent, import des règles, simulation) sont détaillées ci-dessus en Procédure manuelle.

Points d'attention¶

• Ne pas confondre les deux dépôts : aws-s3 est le socle infra core, appliqué et vérifié en direct (tfstate + archivage, deux buckets vides mais existants et configurés) ; aws-s3-siem est un lab pédagogique dont le code est prêt mais dont le déploiement réel dans le compte AWS n'est pas confirmé — buckets, IAM et cycle de vie totalement distincts et non partagés entre les deux de toute façon.
• La clé KMS de l'auto-unseal Vault ne vit dans aucun des deux dépôts documentés ici (voir encadré en Rôle) : aucune rotation ni suppression possible depuis aws-s3/aws-s3-siem pour cette clé.
• iam_secret_access_key (aws-s3-siem) est un output Terraform marqué sensitive : toujours le récupérer via terraform output -raw iam_secret_access_key, jamais via un terraform output simple, et ne jamais le committer.
• L'abonnement SNS (anti-forensics + budget) reste en PendingConfirmation tant que l'email de confirmation n'est pas validé manuellement — silence total côté Terraform si on l'oublie, pas d'alerte visible.
• Le garde-fou budget (aws-s3-siem, 5 USD/mois) n'a aucun filtre de coût : s'il était un jour appliqué, il surveillerait la dépense de tout le compte AWS, pas seulement les ressources du lab — à garder en tête avant de considérer que « le lab reste dans son budget » couvre aussi le socle core (aws-s3).
• Les data events CloudTrail du lab sont volontairement restreints au seul bucket data (pas tout le compte) pour rester dans le free tier — un usage hors lab nécessiterait de revoir ce périmètre.
• L'Elastic Agent du lab dépend entièrement du proxy Squid (10.100.10.4:3128) pour joindre AWS (aucun accès direct) : un changement de whitelist ou une panne du proxy casse silencieusement la collecte — voir Proxy Squid & DNS et son piège de sous-domaine déjà rencontré.
• Aucun projet Terraform de l'infra (aws-s3 y compris) n'utilise le bucket tfstate comme backend distant : tous les states restent locaux à ce jour, y compris celui d'aws-s3 lui-même. Voir Points de vigilance.
• aws-s3-siem n'a aucune trace git locale (git rev-parse échoue, pas de .git) et n'existe pas non plus sur GitLab (indio/iac/aws-s3-siem introuvable, vérifié) — contrairement à aws-s3, correctement versionné. Voir Points de vigilance.
• Ne jamais recopier l'identifiant de compte AWS ni un ARN complet dans une future mise à jour de cette page (règle du projet suite à l'incident de fuite de clés TLS committées) — utiliser « compte AWS dédié Indio ».