Cloud Cloud Security Guide

Cloud Security Guide

Workflow en 8 étapes

1. Auditer et durcir l'IAM

Critère de déclenchement : nouveau compte cloud, audit trimestriel, onboarding d'un service.

# AWS — lister les utilisateurs sans MFA
aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | base64 -d | grep ',false,'

# AWS — trouver les politiques permissives (Action: *)
aws iam list-policies --scope Local --query "Policies[*].Arn" --output text | \
  xargs -I{} aws iam get-policy-version --policy-arn {} --version-id v1 \
  --query "PolicyVersion.Document" 2>/dev/null | grep -B5 '"Action": "\*"'

# Azure — Access Review via CLI
az ad user list --query "[?accountEnabled==\`true\`].{UPN:userPrincipalName}" --output table

Règles d'or :

• Pas de credentials longue durée sur les machines : utiliser des Instance Profiles / Managed Identities / Workload Identity.
• Séparer les comptes par environnement (dev / staging / prod) avec AWS Organizations SCPs ou Azure Management Groups.
• Imposer MFA via une SCP/Policy bloquant toutes les actions si MFA absent.

// AWS SCP — forcer MFA
{
  "Effect": "Deny",
  "NotAction": ["iam:CreateVirtualMFADevice","iam:EnableMFADevice","sts:GetSessionToken"],
  "Resource": "*",
  "Condition": {"BoolIfExists": {"aws:MultiFactorAuthPresent": "false"}}
}

2. Segmenter le réseau

# AWS — VPC avec sous-réseaux isolés (Terraform snippet)
resource "aws_vpc" "main" { cidr_block = "10.0.0.0/16" }
resource "aws_subnet" "public"   { cidr_block = "10.0.1.0/24" ... }
resource "aws_subnet" "private"  { cidr_block = "10.0.2.0/24" ... }
resource "aws_subnet" "data"     { cidr_block = "10.0.3.0/24" ... }

# Activer les VPC Flow Logs
aws ec2 create-flow-logs \
  --resource-type VPC --resource-ids vpc-xxx \
  --traffic-type ALL --log-destination-type cloud-watch-logs \
  --log-group-name /vpc/flowlogs

Décision rapide :

3. Chiffrer les données

# AWS — activer le chiffrement SSE-KMS sur un bucket S3
aws s3api put-bucket-encryption --bucket mon-bucket \
  --server-side-encryption-configuration '{
    "Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"aws:kms","KMSMasterKeyID":"arn:aws:kms:..."}}]
  }'

# Azure — activer CMK sur un Storage Account
az storage account update \
  --name monstorage --resource-group monrg \
  --encryption-key-source Microsoft.Keyvault \
  --encryption-key-vault https://monkeyvault.vault.azure.net/ \
  --encryption-key-name maclé --encryption-key-version latest

Critères CMK vs clés gérées par le provider :

• Clés provider (SSE-S3, Microsoft-managed) : acceptable pour données non réglementées.
• CMK obligatoire : données médicales, financières, PII soumises à RGPD/HIPAA/PCI-DSS.
• Activer la rotation automatique annuelle des CMK.

4. Gérer les secrets sans les exposer

# AWS — créer un secret avec rotation
aws secretsmanager create-secret \
  --name prod/myapp/db-password \
  --secret-string '{"username":"admin","password":"xxx"}'

aws secretsmanager rotate-secret \
  --secret-id prod/myapp/db-password \
  --rotation-lambda-arn arn:aws:lambda:...

# Récupérer au runtime (Python)
import boto3, json
secret = json.loads(
  boto3.client("secretsmanager").get_secret_value(SecretId="prod/myapp/db-password")["SecretString"]
)

Règles :

• Scan automatique des secrets dans le code : git-secrets, trufflehog, detect-secrets en pre-commit hook.
• Variables d'environnement en CI/CD : toujours via le secret store du pipeline (GitHub Secrets, Azure Key Vault linked variable groups) — jamais en clair dans le YAML.

5. Déployer un CSPM et automatiser la remédiation

# AWS Security Hub — activer CIS Benchmark
aws securityhub enable-security-hub --enable-default-standards
aws securityhub batch-enable-standards \
  --standards-subscription-requests '[
    {"StandardsArn":"arn:aws:securityhub:::ruleset/cis-aws-foundations-benchmark/v/1.4.0"}
  ]'

# Azure — activer Defender for Cloud sur tous les plans
az security pricing create -n VirtualMachines --tier Standard
az security pricing create -n StorageAccounts --tier Standard

Remédiation automatique : utiliser AWS Config Remediation Actions ou Azure Policy DeployIfNotExists pour corriger automatiquement les findings récurrents (ex: activer CloudTrail si désactivé).

6. Détection de menaces et SIEM

# AWS — activer GuardDuty sur tous les comptes d'une org
aws guardduty create-detector --enable --finding-publishing-frequency FIFTEEN_MINUTES
# Déléguer à un compte sécurité centralisé
aws guardduty enable-organization-admin-account --admin-account-id 123456789012

# Centraliser les logs CloudTrail → S3 → CloudWatch → SIEM
aws cloudtrail create-trail \
  --name org-trail --s3-bucket-name audit-logs-bucket \
  --is-multi-region-trail --enable-log-file-validation

Alertes prioritaires à configurer :

• Root account login
• IAM policy modification
• S3 bucket rendu public
• Connexion depuis IP suspecte / pays inhabituel
• Exfiltration de données (volume anormal d'accès sortants)

7. Conformité as Code

# OPA — policy interdisant les buckets S3 publics (Rego)
deny[msg] {
  input.resource.type == "aws_s3_bucket"
  input.resource.config.acl == "public-read"
  msg := sprintf("Bucket %v ne doit pas être public", [input.resource.name])
}

# AWS Config Rule custom
aws configservice put-config-rule --config-rule '{
  "ConfigRuleName": "s3-no-public-acl",
  "Source": {"Owner":"AWS","SourceIdentifier":"S3_BUCKET_PUBLIC_READ_PROHIBITED"}
}'

Mapping frameworks 2026 :

8. Réponse aux incidents cloud

Procédure d'isolation rapide :

# AWS — isoler une instance compromise
aws ec2 create-security-group --group-name quarantine --description "No ingress/egress"
aws ec2 modify-instance-attribute \
  --instance-id i-xxxx --groups sg-quarantine

# Snapshot pour préservation des preuves
aws ec2 create-snapshot --volume-id vol-xxxx \
  --description "forensics-$(date +%Y%m%d-%H%M%S)" \
  --tag-specifications 'ResourceType=snapshot,Tags=[{Key=incident,Value=INC-001}]'

Décisions clés lors d'un incident :

1. Isoler SANS éteindre (préserver la mémoire volatile si forensics nécessaire).
2. Révoquer les credentials immédiatement (pas juste désactiver).
3. Notifier le DPO si données personnelles concernées (RGPD : 72h).

Anti-patterns et pièges

Bonnes pratiques 2026

• Zero Trust : ne pas faire confiance au réseau interne — vérifier chaque appel avec des tokens courts (SPIFFE/SPIRE pour les workloads).
• Supply chain : signer les images container (Sigstore/Cosign), scanner les CVEs avant le push en registry (Trivy, Grype).
• Infrastructure immutable : pas de SSH direct en prod — utiliser AWS SSM Session Manager / Azure Bastion sans port 22 exposé.
• Shift-left security : intégrer les checks SAST/SCA/IaC-scan dans la PR (Checkov pour Terraform, Semgrep, Dependabot).
• Tagging obligatoire : env, owner, data-classification, cost-center sur toutes les ressources — prérequis pour les politiques automatisées.

Communication Rules — MANDATORY

• Ultra-concise. No filler, no preamble, no pleasantries.
• Never say "happy to help", "sure!", "great question", "let me", or similar.
• Tool first, talk second. Act before explaining.
• Result first. Lead with outcome, not process.
• Stop when done. No summary, no recap, no trailing commentary.
• No politeness wrappers. Direct and blunt.
• Minimum words. If one word works, do not use ten.
• No unsolicited explanations.
• No emoji unless asked.