Cloud & Infrastructure

Configuration sécurisée des services cloud 2026

Configuration sécurisée des services cloud AWS/Azure/GCP : stockage, base de données, compute, réseau. Référentiels CIS Benchmarks, outils de drift, IaC sécurisée.

Naim Aouaichia
20 min de lecture
  • Cloud Security
  • AWS
  • Azure
  • GCP
  • CIS Benchmarks
  • Hardening
  • IaC
  • Configuration

La configuration sécurisée des services cloud est l'ensemble des paramètres appliqués à chaque service (stockage objet, bases de données managées, compute, réseau, IAM, logging) pour minimiser sa surface d'attaque et respecter les quatre piliers fondamentaux de la sécurité cloud : moindre privilège IAM, chiffrement au repos et en transit, isolation réseau, journalisation complète. Elle est encadrée par les CIS Benchmarks publiés par le Center for Internet Security — CIS AWS Foundations Benchmark v3.0 (107 recommandations), CIS Microsoft Azure Foundations Benchmark v3.0 (195 recommandations), CIS Google Cloud Platform Foundation Benchmark v2.1 (133 recommandations) — et par les référentiels NIST SP 800-53 Rev 5 et CSA Cloud Controls Matrix v4.0. Selon les observatoires 2026, 82 % des entreprises ont subi au moins un incident lié à une misconfiguration cloud, avec des pertes projetées à 5 000 milliards de dollars annuels — la misconfiguration reste la cause #1 d'incidents cloud devant les 0-days, l'ingénierie sociale et les attaques supply chain. Cinq familles de services concentrent 85 % des misconfigurations observées : stockage objet (S3 / Azure Blob / GCS), bases de données managées (RDS / Azure SQL / Cloud SQL), IAM, réseau (VPC / VNet), compute (EC2 / VM / GCE). Cet article détaille les paramètres de sécurité à maîtriser pour chaque famille de service, les outils d'audit automatique (Prowler, AWS Config, Azure Policy, GCP Security Command Center), la gestion du drift via IaC, et les référentiels CIS Benchmarks pour construire une posture cloud auditable.

1. Les 4 piliers transverses à tout service cloud

Quatre contrôles s'appliquent à tout service cloud en 2026, indépendamment du cloud provider ou de la catégorie. Leur maîtrise systématique couvre 70-80 % du risque misconfiguration.

PilierContrôleAWSAzureGCP
IAM moindre privilègePolicies scopées, rôles temporairesIAM + IAM Identity CenterEntra ID + RBACCloud IAM + IAM conditions
Chiffrement at-restDonnées chiffrées au stockageKMS + SSE-S3/KMSStorage Service Encryption + Key VaultCloud KMS + CMEK
Chiffrement in-transitTLS 1.2+ partoutACM + ALB/NLB HTTPSFront Door + App Gateway TLSCloud Load Balancing + Managed SSL
Logging et auditLogs complets centralisésCloudTrail + Config + VPC FlowActivity Log + Defender for Cloud + NSG FlowCloud Audit Logs + VPC Flow Logs

2. Stockage objet : S3, Azure Blob, GCS

Premier service mal configuré en 2026, responsable de la majorité des fuites publiques (Capital One 2019, Facebook 2019, Toyota 2024 — 240 Go exposés 5 ans, Red Hat/Crimson Collective 2025 — 570 Go exfiltrés).

2.1 Les 8 contrôles obligatoires S3 (AWS)

#ContrôleOutil natifCIS Benchmark
1Block Public Access account-wideS3 Block Public AccessCIS 2.1.5
2Chiffrement SSE-KMS ou SSE-S3 par défautDefault encryptionCIS 2.1.1
3Versioning activéS3 VersioningCIS 2.1.3
4MFA Delete sur buckets critiquesS3 Bucket PolicyCIS 2.1.4
5Access Logging activéS3 Server Access LoggingCIS 3.6
6Bucket Policy restrictiveBucket Policy + IAMCIS 2.1.2
7Object Lock pour immutabilité (backup, logs)Object Lock-
8Cross-Region Replication pour critiquesCRR-

2.2 Exemple Terraform d'un bucket S3 sécurisé par construction

# s3-bucket-securise-reference.tf
# Bucket S3 avec tous les controles securite activement configures.
# Application : stockage sensible (PII, backups, logs d'audit).
 
resource "aws_s3_bucket" "secure_bucket" {
  bucket = "monorg-production-data-eu-west-3"
 
  tags = {
    Environment = "production"
    DataClass   = "sensitive"
    Owner       = "security-team"
  }
}
 
# Controle 1 : Block Public Access systematique
resource "aws_s3_bucket_public_access_block" "secure_bucket" {
  bucket                  = aws_s3_bucket.secure_bucket.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}
 
# Controle 2 : Chiffrement SSE-KMS avec CMK customer-managed
resource "aws_s3_bucket_server_side_encryption_configuration" "secure_bucket" {
  bucket = aws_s3_bucket.secure_bucket.id
 
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm     = "aws:kms"
      kms_master_key_id = aws_kms_key.bucket_cmk.arn
    }
    bucket_key_enabled = true
  }
}
 
# Controle 3 : Versioning pour recovery
resource "aws_s3_bucket_versioning" "secure_bucket" {
  bucket = aws_s3_bucket.secure_bucket.id
  versioning_configuration {
    status = "Enabled"
  }
}
 
# Controle 5 : Access logging vers bucket dedie
resource "aws_s3_bucket_logging" "secure_bucket" {
  bucket        = aws_s3_bucket.secure_bucket.id
  target_bucket = aws_s3_bucket.logs_bucket.id
  target_prefix = "s3-access-logs/monorg-production-data/"
}
 
# Controle 6 : Bucket policy refus explicite HTTP non-chiffre
resource "aws_s3_bucket_policy" "secure_bucket" {
  bucket = aws_s3_bucket.secure_bucket.id
 
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid       = "DenyInsecureTransport"
        Effect    = "Deny"
        Principal = "*"
        Action    = "s3:*"
        Resource = [
          aws_s3_bucket.secure_bucket.arn,
          "${aws_s3_bucket.secure_bucket.arn}/*"
        ]
        Condition = {
          Bool = {
            "aws:SecureTransport" = "false"
          }
        }
      }
    ]
  })
}
 
# Controle 7 : Object Lock pour immutabilite (compliance WORM)
# Note : doit etre active a la creation, pas activable apres
resource "aws_s3_bucket_object_lock_configuration" "secure_bucket" {
  bucket = aws_s3_bucket.secure_bucket.id
 
  rule {
    default_retention {
      mode = "COMPLIANCE"
      days = 2555  # 7 ans pour conformite RGPD/archivage
    }
  }
}

2.3 Équivalents Azure Blob et GCS

Azure Blob Storage : Storage Service Encryption activé par défaut depuis 2020 (clés Microsoft-managed), Customer-Managed Keys via Azure Key Vault pour données sensibles, Public network access disabled + Private Endpoints via Azure Private Link, Soft Delete + Versioning + Immutable Blob Storage (WORM).

Google Cloud Storage (GCS) : Server-side encryption Google-managed par défaut, CMEK via Cloud KMS pour données sensibles, Bucket IAM + Uniform Bucket-Level Access (deny ACL legacy), VPC Service Controls pour limiter l'accès aux API depuis des périmètres, Retention Policy pour WORM, Object Versioning.

3. Bases de données managées : RDS, Azure SQL, Cloud SQL

Second vecteur majeur. Les bases managées sont souvent négligées car « le cloud s'en occupe » — faux, la configuration reste ta responsabilité.

3.1 Les 10 contrôles obligatoires base managée

#ContrôleRaison
1Encryption at rest activéeNon modifiable post-création RDS — critique dès la creation
2Encryption in transit forcée (SSL/TLS)Prévient sniff réseau interne
3Endpoint non-public (subnet privé)Pas d'exposition 0.0.0.0/0 DB
4IAM authentication ou SSO (pas password)Reduce credential sprawl
5Rotation automatique credentialsVault ou Secrets Manager
6Backup automatique + PITRRecovery post-incident
7Multi-AZ ou équivalentRésilience
8Audit log activéCloudTrail DB events, Azure SQL Auditing
9Network ACL stricte (security group)Allow-list port 3306/5432/1433
10Version engine à jour (patches majeurs)CVE patching

3.2 Exemple RDS PostgreSQL sécurisé

# rds-postgres-securise.tf
# Instance RDS PostgreSQL production avec defaults securises.
 
resource "aws_db_instance" "production_db" {
  identifier     = "monorg-prod-postgres"
  engine         = "postgres"
  engine_version = "16.4"
  instance_class = "db.r6g.large"
 
  allocated_storage     = 200
  max_allocated_storage = 1000
  storage_type          = "gp3"
 
  # Controle 1 : Encryption at rest OBLIGATOIRE a la creation
  storage_encrypted = true
  kms_key_id        = aws_kms_key.rds_cmk.arn
 
  # Controle 3 : Endpoint en subnet prive, pas public
  db_subnet_group_name   = aws_db_subnet_group.private.name
  publicly_accessible    = false
  vpc_security_group_ids = [aws_security_group.rds_allow_app.id]
 
  # Controle 4 : IAM authentication activee (moins de passwords)
  iam_database_authentication_enabled = true
 
  # Controle 5 : Master password dans Secrets Manager avec rotation
  manage_master_user_password = true
  master_user_secret_kms_key_id = aws_kms_key.rds_cmk.arn
 
  # Controle 6 : Backup 30 jours + PITR
  backup_retention_period   = 30
  backup_window             = "03:00-04:00"
  copy_tags_to_snapshot     = true
  delete_automated_backups  = false
  skip_final_snapshot       = false
 
  # Controle 7 : Multi-AZ pour resilience
  multi_az = true
 
  # Controle 8 : Logs exports vers CloudWatch
  enabled_cloudwatch_logs_exports = ["postgresql", "upgrade"]
 
  # Controle 9 : Performance Insights pour detection anomalies
  performance_insights_enabled          = true
  performance_insights_retention_period = 31
 
  # Controle 10 : Auto minor version upgrade
  auto_minor_version_upgrade = true
  deletion_protection        = true
 
  # Force SSL connections
  parameter_group_name = aws_db_parameter_group.force_ssl.name
 
  tags = {
    Environment = "production"
    DataClass   = "sensitive"
  }
}
 
resource "aws_db_parameter_group" "force_ssl" {
  family = "postgres16"
  name   = "monorg-postgres16-ssl-force"
 
  parameter {
    name  = "rds.force_ssl"
    value = "1"
  }
}

3.3 Équivalents Azure SQL et Cloud SQL

Azure SQL Database : Transparent Data Encryption activé par défaut, Always Encrypted pour colonnes ultra-sensibles, Private Endpoint via Azure Private Link, Microsoft Entra ID authentication (pas SQL auth), Azure SQL Auditing + Advanced Threat Protection, Firewall rules strictes (pas 0.0.0.0/0), Long-term retention backup.

Google Cloud SQL : Encryption at rest par défaut, CMEK via Cloud KMS pour sensibles, Private IP via VPC peering (pas public IP), IAM database authentication, Automated backups avec PITR, SSL/TLS required, Cloud SQL Auth Proxy pour connexions depuis compute.

4. Compute : EC2, Azure VM, GCE

Les instances compute sont l'historique de l'infrastructure cloud. Moins fréquentes en 2026 avec l'adoption Kubernetes et serverless, mais toujours largement déployées.

4.1 Contrôles critiques

ContrôleDescription
IMDSv2 enforcedPrévient le vol credentials via SSRF (Capital One 2019)
Encryption disque at restEBS encrypted default, Azure Managed Disk, PD GCE
IAM Role attaché (pas access keys)Credentials temporaires rotés auto
SSM Session Manager (pas bastion SSH)Pas de port 22 exposé
Patch baselineSSM Patch Manager, Azure Update Manager, OS Config GCP
Security Group minimalistePas de 0.0.0.0/0 sur admin ports
VPC Flow LogsTrafic réseau audité
Anti-malware endpointCrowdStrike, SentinelOne, ou natif (GuardDuty Malware Protection)

4.2 IMDSv2 : le must-have 2026

Depuis l'incident Capital One 2019 (100 millions de comptes exfiltrés via SSRF → IMDSv1 → credentials IAM), IMDSv2 (Instance Metadata Service v2) est devenu obligatoire.

Vérifier l'état du parc EC2 :

# verify-imdsv2-enforcement.sh
# Liste toutes les EC2 avec IMDSv1 encore autorise (risque).
 
aws ec2 describe-instances \
  --query 'Reservations[].Instances[?MetadataOptions.HttpTokens!=`required`].[InstanceId,State.Name,MetadataOptions.HttpTokens]' \
  --output table
 
# Pour basculer IMDSv2 enforced sur une instance existante (rolling)
aws ec2 modify-instance-metadata-options \
  --instance-id i-0abc1234567890def \
  --http-tokens required \
  --http-put-response-hop-limit 1
 
# Pour enforcer via account default (nouvelles instances)
aws ec2 modify-instance-metadata-defaults \
  --http-tokens required \
  --http-put-response-hop-limit 1 \
  --instance-metadata-tags enabled

5. Réseau : VPC, VNet, Cloud VPC

Le réseau cloud a sa propre logique (pas d'équivalent direct aux firewalls physiques).

5.1 Les 6 règles de base

RègleAWSAzureGCP
Subnets privés pour workloads sensiblesPrivate subnet + NAT GatewayPrivate subnet + NAT GatewayPrivate subnet + Cloud NAT
Security Groups minimaux (stateful)Security GroupNSG (Network Security Group)Firewall rules
Jamais 0.0.0.0/0 sur ports adminSG rulesNSG rulesFirewall rules
Private endpoints pour services SaaSVPC Endpoints (Gateway + Interface)Private LinkPrivate Service Connect
Flow logs activésVPC Flow LogsNSG Flow LogsVPC Flow Logs
Segmentation multi-compte/multi-projetOrganizations + SCPs + Transit GatewayManagement Groups + Hub-SpokeOrganizations + VPC Service Controls

5.2 Erreurs classiques réseau

  1. Security Group default modifié. Ne jamais toucher le SG default. Créer des SG nommés par fonction.
  2. 0.0.0.0/0:22 sur un SG. Utiliser SSM Session Manager à la place.
  3. NAT Gateway par VPC au lieu de par AZ. Résilience insuffisante.
  4. VPC Peering full-mesh dans une topologie > 5 VPC. Préférer Transit Gateway ou Hub-Spoke VNet.
  5. Pas de Flow Logs en prod. Aucune investigation possible post-incident.

6. IAM cross-cloud : principes communs

Même si AWS IAM, Azure RBAC et GCP IAM ont chacun leurs spécificités, cinq principes communs s'appliquent.

6.1 Les 5 principes universels

  1. Least privilege : actions et ressources scopées au minimum vital.
  2. Roles > users : credentials temporaires via STS / SAS token / short-lived tokens.
  3. MFA obligatoire sur tous les humains, hardware key pour privilégiés.
  4. SSO / IAM Identity Center : identité centrale, provisioning automatique SCIM.
  5. Rotation automatique : credentials machine via Vault ou KMS natif, rotation < 90 jours.

6.2 Anti-patterns IAM observés en audit

# anti-patterns-iam-cloud-2026.yml
# Top 10 anti-patterns IAM detectes systematiquement en audit Prowler/ScoutSuite.
 
anti_pattern_1:
  nom: "Policy avec Action: \"*\" et Resource: \"*\""
  impact: "Sur-privilege total, pivot trivial post-compromise"
  remedy: "Scoper Action a la liste explicite, Resource aux ARN precis"
 
anti_pattern_2:
  nom: "Access keys longue duree sans rotation"
  impact: "Credential qui traine, leak GitHub = crypto mining sous 60s"
  remedy: "IAM Identity Center + STS + rotation < 90 jours"
 
anti_pattern_3:
  nom: "Users IAM humains au lieu de federation SSO"
  impact: "Multiplication des identites, audit impossible"
  remedy: "IAM Identity Center (ex-AWS SSO), Entra ID, Workforce Identity"
 
anti_pattern_4:
  nom: "Permission boundaries non utilisees sur roles admin"
  impact: "Privilege escalation via creation de role over-privileged"
  remedy: "Permission boundary obligatoire sur delegation IAM"
 
anti_pattern_5:
  nom: "MFA non forcee"
  impact: "Credential stuffing / phishing triviaux"
  remedy: "SCP MFARequired sur toute operation sensible"
 
anti_pattern_6:
  nom: "Roles service assumables par n'importe quel compte"
  impact: "Cross-account takeover"
  remedy: "Trust policy restrictive avec external-id"
 
anti_pattern_7:
  nom: "Service accounts GCP avec keys JSON exportees"
  impact: "Credential en clair, leak = compromission totale"
  remedy: "Workload Identity Federation (cross-cloud) ou IAM Identity"
 
anti_pattern_8:
  nom: "Azure subscription Owner sur groupe large"
  impact: "Owner = delete subscription, transfert billing"
  remedy: "Contributor max, Owner reserve a 1-2 breakglass"
 
anti_pattern_9:
  nom: "Absence de monitoring IAM changes"
  impact: "Backdoor persistante non detectee"
  remedy: "CloudTrail + EventBridge alerts sur IAM policy change"
 
anti_pattern_10:
  nom: "Pas d'Access Analyzer actif"
  impact: "Ressources accessibles externes non identifiees"
  remedy: "IAM Access Analyzer + external-access findings reviews hebdo"

7. Outils d'audit automatique

L'audit manuel d'un compte cloud de taille moyenne (100+ ressources) est impraticable. Outillage recommandé 2026.

7.1 Outils natifs cloud providers

Outil natifCloudGratuitéUsage
AWS ConfigAWS~20-80 €/moisInventaire + règles conformité
AWS Security HubAWS~10-30 €/moisAgrégation + CIS/PCI-DSS/FedRAMP benchmarks
Azure PolicyAzureGratuitRègles de conformité
Azure Defender for CloudAzureGratuit Foundational, payant fullSecurity posture + threat detection
GCP Security Command CenterGCPGratuit Standard, payant PremiumFindings + compliance benchmarks
Google Cloud Config ValidatorGCPGratuit (OPA)Validation manifest pré-déploiement

7.2 Outils open source multi-cloud

OutilÉditeurSpécificité
ProwlerToni de la Fuente (Prowler Inc.)500+ checks AWS + Azure + GCP + Kubernetes, référence
ScoutSuiteNCC GroupMulti-cloud scan + rapport HTML
CloudSploitAqua200+ checks cloud
Cloud CustodianCapital OnePolicy-as-code cross-cloud
kube-benchAquaCIS Kubernetes Benchmark
kubescapeARMOMulti-framework K8s (NSA, MITRE ATT&CK, CIS)
PacuRhino Security LabsExploitation AWS post-recon

7.3 Exemple d'audit Prowler

# audit-cloud-prowler.sh
# Audit initial complet d'un compte AWS avec Prowler.
# Duree typique : 10-30 minutes selon nombre de ressources.
 
# Installation
pip install prowler
 
# Audit AWS complet avec CIS v3.0
prowler aws \
  --compliance cis_3.0_aws \
  --output-formats html json-ocsf \
  --output-directory ./audit-$(date +%Y%m%d)
 
# Audit Azure avec CIS v3.0
prowler azure \
  --compliance cis_3.0_azure \
  --subscription-id 11111111-2222-3333-4444-555555555555
 
# Audit GCP avec CIS v2.1
prowler gcp \
  --compliance cis_2.1_gcp \
  --project-ids my-production-project
 
# Audit Kubernetes
prowler kubernetes --kubeconfig-file ~/.kube/config
 
# Rapport HTML dans ./audit-<date>/prowler-output-<timestamp>.html
# Triage : filtrer par severite HIGH + CRITICAL d'abord

7.4 CNAPP commercial 2026

Pour les grands comptes et scale-up matures, les CNAPP (Cloud-Native Application Protection Platforms) offrent vue unifiée cross-cloud + détection temps réel + priorisation par attack path.

VendeurPositionnement 2026
WizRacheté Google mars 2025 (32 Mds $), graph-based, leader
Palo Alto Prisma CloudSuite complète, intégration Panorama
CrowdStrike Falcon CloudThreat intel + AI detection
Orca SecuritySide-scanning agentless
AccuKnoxOpen source + commercial, K8s-first
Sysdig SecureRuntime-first (Falco origin)

8. IaC : la prévention à la source

La configuration manuelle via console est l'ennemi #1 de la sécurité cloud. Infrastructure as Code (IaC) bascule la configuration vers du code versionné, revu, scanné avant déploiement.

8.1 Stack IaC sécurisée 2026

CoucheOutil
ProvisioningTerraform 1.x, OpenTofu 1.x, Pulumi, AWS CDK
Templates K8sHelm 3.x, Kustomize, CUE
Policy-as-codeOPA/Conftest, Checkov, tfsec, Terrascan, KICS
SecretsHashiCorp Vault, AWS Secrets Manager, SOPS
CI/CD validationGitLab CI, GitHub Actions avec pipeline scan

8.2 Pipeline IaC sécurisé

# .gitlab-ci.yml extrait - pipeline IaC securise
# Valide chaque PR Terraform avec scan multi-outils avant apply.
 
stages:
  - validate
  - security
  - plan
  - apply
 
terraform-validate:
  stage: validate
  image: hashicorp/terraform:1.10.3
  script:
    - terraform fmt -check -recursive
    - terraform init -backend=false
    - terraform validate
 
tfsec:
  stage: security
  image: aquasec/tfsec-ci:v1.28.12
  script:
    - tfsec --soft-fail --format sarif --out tfsec.sarif .
    - tfsec --minimum-severity HIGH .
  artifacts:
    reports:
      sast: tfsec.sarif
 
checkov:
  stage: security
  image: bridgecrew/checkov:3.2.401
  script:
    - checkov --directory .
        --framework terraform
        --output json
        --output-file-path checkov.json
        --hard-fail-on HIGH,CRITICAL
 
opa-policy-validate:
  stage: security
  image: openpolicyagent/conftest:v0.60.0
  script:
    - conftest test terraform/ --policy policies/
 
terraform-plan:
  stage: plan
  image: hashicorp/terraform:1.10.3
  script:
    - terraform init
    - terraform plan -out=tfplan
  artifacts:
    paths:
      - tfplan
    expire_in: 7 days
  only:
    - merge_requests
 
terraform-apply:
  stage: apply
  image: hashicorp/terraform:1.10.3
  script:
    - terraform apply -auto-approve tfplan
  only:
    - main
  when: manual

8.3 Politique zero manual change en prod

Protocole recommandé 2026 :

  1. SCP / Azure Policy deny bloquant la modification manuelle des ressources taguées ManagedBy: Terraform en production.
  2. Drift detection automatique (AWS Config, Terraform Cloud, Prowler) scanné quotidiennement.
  3. Alerting immédiat sur drift détecté → création ticket Jira / notification Slack.
  4. Investigation systématique : oubli de code ? mauvaise manipulation ? compromise en cours ?

9. Référentiels et checklists

Trois référentiels majeurs à maîtriser pour un programme de configuration sécurisée cloud en 2026.

9.1 CIS Benchmarks

BenchmarkVersion 2026RecommandationsUsage
CIS AWS Foundationsv3.0107Core AWS, tout compte
CIS Microsoft Azure Foundationsv3.0195Core Azure, toute subscription
CIS Google Cloud Platform Foundationv2.1133Core GCP, tout projet
CIS Amazon EKS Benchmarkv1.5~45Clusters EKS
CIS Kubernetes Benchmarkv1.9~120K8s self-managed 1.29+
CIS Docker Benchmarkv1.7~100Docker runtime

9.2 Autres référentiels

  • NIST SP 800-53 Rev 5 : contrôles sécurité systèmes US, largement utilisé FR.
  • NIST Cybersecurity Framework 2.0 (février 2024) : 6 fonctions (Govern, Identify, Protect, Detect, Respond, Recover).
  • CSA Cloud Controls Matrix (CCM) v4 : 197 contrôles cloud cross-framework.
  • ISO/IEC 27017 : code de bonne pratique sécurité cloud.
  • ISO/IEC 27018 : protection PII cloud.
  • FedRAMP : baseline cloud US fédéral (Low, Moderate, High).
  • PCI-DSS 4.0 : si traitement de cartes bancaires.
  • HDS (Hébergeur de Données de Santé, FR) : obligatoire santé France.

9.3 AWS Foundational Security Best Practices

Référentiel AWS natif, intégré à Security Hub gratuitement. Complément au CIS Benchmark avec checks spécifiques AWS : ECS, ECR, Lambda, API Gateway, CloudFront, etc. ~200 règles en 2026.

9.4 Checklist minimale universelle

Point de départ pour tout nouveau compte cloud, quel que soit le provider :

  1. MFA hardware sur root / Global Admin / Project Owner.
  2. CloudTrail / Activity Log / Audit Log activés tous événements, logs chiffrés en compte dédié.
  3. Posture management activé (Security Hub, Defender for Cloud, Security Command Center).
  4. Chiffrement par défaut actif sur tout stockage (S3, Blob, GCS, EBS, Disk).
  5. Block Public Access account-wide activé.
  6. Pas d'access keys longue durée pour humains (SSO / IAM Identity Center).
  7. Network segmentation minimale (VPC / VNet séparé par environnement).
  8. Pas de 0.0.0.0/0 sur ports admin (22, 3389, 3306, 5432, 6379, 27017, 9200).
  9. IaC en place (Terraform ou équivalent) pour toute nouvelle ressource.
  10. Prowler scan initial exécuté, findings HIGH/CRITICAL triés.

Pour approfondir AWS spécifiquement, voir AWS security pour débutant qui détaille le parcours initial 14 jours. Pour Kubernetes, la ressource pillar sécurité Kubernetes : les bases couvre le hardening K8s. Pour la roadmap d'apprentissage cloud security complète, la roadmap cloud security structure 12-18 mois en 6 phases.

Points clés à retenir

  • Misconfiguration = cause #1 d'incidents cloud : 82 % des organisations touchées, pertes projetées 5 000 Mds $ / an.
  • 4 piliers transverses : IAM moindre privilège, chiffrement at-rest + in-transit, isolation réseau, logging complet.
  • 5 familles de services concentrent 85 % des findings : stockage, base de données, IAM, réseau, compute.
  • CIS Benchmarks sont le référentiel standard : AWS v3.0 (107 recos), Azure v3.0 (195), GCP v2.1 (133).
  • Tout chiffrer par défaut : at-rest + in-transit, CMK pour sensibles, rotation auto.
  • IMDSv2 enforced sur EC2 (depuis oct 2024 par défaut sur nouvelles, à forcer sur parcs existants).
  • IaC = prévention à la source : Terraform + tfsec + Checkov + OPA pipeline, zero manual change en prod.
  • Drift = toujours un signal à investiguer : oubli code, erreur humaine, ou compromission.
  • Outillage audit : Prowler (multi-cloud référence), AWS Config/Security Hub, Azure Defender for Cloud, GCP Security Command Center.
  • CNAPP 2026 : Wiz (Google 32 Md$ mars 2025), Prisma Cloud, CrowdStrike Falcon, Orca pour vue cross-cloud.

Questions fréquentes

  • Qu'est-ce qu'une configuration sécurisée d'un service cloud ?
    Une configuration sécurisée d'un service cloud est l'ensemble des paramètres appliqués à un service (S3, RDS, EC2, Azure SQL, GCS, Cloud Run, Kubernetes Engine) pour minimiser sa surface d'attaque et respecter les principes fondamentaux : moindre privilège IAM, chiffrement au repos et en transit, isolation réseau, journalisation complète, protection contre la suppression et l'accès public. Les référentiels de référence 2026 sont les **CIS Benchmarks** publiés par le Center for Internet Security : CIS AWS Foundations Benchmark v3.0 (107 recommandations), CIS Microsoft Azure Foundations Benchmark v3.0 (195), CIS Google Cloud Platform Foundation Benchmark v2.1 (133). Chaque service a ses défauts non-sécurisés par conception (S3 chiffrement SSE-S3 activé par défaut depuis janvier 2023 mais Block Public Access à activer manuellement, RDS encryption désactivé par défaut historiquement, etc.). Selon les observatoires 2026, **82 % des entreprises** ont subi au moins un incident lié à une misconfiguration cloud, avec des pertes projetées à 5 000 milliards de dollars annuels.
  • Quels sont les services cloud les plus souvent mal configurés ?
    Cinq catégories dominent les incidents observés. 1) **Stockage objets** (AWS S3, Azure Blob, Google Cloud Storage) : buckets publics par erreur, chiffrement désactivé, versioning absent, logs d'accès absents. Voir les incidents Capital One 2019, Facebook 2019, Red Hat/Crimson Collective 2025 (570 Go exfiltrés). 2) **Bases de données managées** (RDS, Azure SQL, Cloud SQL) : encryption désactivé, backup insuffisant, endpoints publics, mots de passe faibles, absence de rotation automatique. 3) **IAM** : permissions over-privileged (Resource `*`, Action `*`, MFA non forcée, access keys longue durée non rotées). 4) **Network** : Security Groups avec 0.0.0.0/0 sur ports sensibles, VPC Flow Logs absents, pas de private endpoints pour services SaaS. 5) **Compute** (EC2, VM, GCE) : IMDSv1 encore actif, pas de disk encryption, instances exposées en direct sans load balancer ou bastion. Ces 5 catégories représentent plus de 85 % des findings d'un audit CNAPP sur un compte cloud moyen.
  • Comment auditer la configuration de son cloud ?
    Trois approches complémentaires. 1) **Services natifs gratuits ou low-cost** : AWS Config + Security Hub avec règles CIS Benchmarks (AWS), Azure Policy + Defender for Cloud (Azure), Security Command Center + Config Validator (GCP). 2) **Outils open source** : Prowler (multi-cloud, 500+ checks AWS + Azure + GCP + Kubernetes, référence du marché), ScoutSuite (NCC Group, multi-cloud), CloudSploit (Aqua), Cloud Custodian (Capital One), kube-bench pour Kubernetes, CSPM open. 3) **CNAPP commercial** en grand compte : Wiz (racheté Google mars 2025 pour 32 Md$), Palo Alto Prisma Cloud, CrowdStrike Falcon Cloud Security, Orca Security, AccuKnox, Sysdig Secure. Un audit initial avec Prowler (30 minutes sur un compte AWS) identifie typiquement 50-200 findings à trier. L'audit récurrent en continu via AWS Config / Azure Policy / GCP SCC est indispensable pour détecter les drifts (modifications manuelles hors IaC).
  • Que faut-il chiffrer dans un cloud public en 2026 ?
    **Tout chiffrer par défaut**, sans exception justifiable en 2026. Au repos : tous les buckets objet (S3 SSE-KMS ou SSE-S3 au minimum, chiffrement par défaut depuis janvier 2023 côté AWS, Microsoft Azure storage encrypted by default depuis 2020), toutes les bases de données (RDS encryption activée dès la création — non modifiable après), tous les volumes block (EBS, Azure Managed Disks, Persistent Disks GCP), tous les snapshots. En transit : HTTPS/TLS 1.2 minimum (TLS 1.3 recommandé) partout, communications inter-services via service mesh (Istio, Linkerd) avec mTLS. Gestion des clés : **customer-managed keys (CMK)** via KMS (AWS), Key Vault (Azure), Cloud KMS (GCP) pour les données sensibles ou soumises à conformité, AWS-managed keys acceptable pour les données de niveau standard. Rotation automatique des clés activée. Les CMK permettent aussi de révoquer l'accès en cas de compromise : supprimer la clé rend les données chiffrées inaccessibles, même à AWS.
  • Comment gérer le drift de configuration après déploiement ?
    Trois niveaux de défense contre le drift. 1) **Prévention** via IaC (Terraform, OpenTofu, Pulumi, CloudFormation) : tout changement passe par code, revue PR, pipeline CI, `terraform plan` avant apply. Interdire les modifications manuelles via console ou CLI en production — verrouiller via Service Control Policies AWS Organizations (SCPs) ou Azure Policy deny. 2) **Détection** via drift detection natif : Terraform Cloud / Enterprise drift detection (paid), AWS Config drift pour CloudFormation stacks, Azure Policy compliance reports, Prowler scheduled scans. 3) **Remédiation** automatique pour les drifts mineurs : AWS Config remediation actions via Systems Manager Automation, Azure Policy remediation tasks. Règle opérationnelle 2026 : **zéro drift toléré en prod**, toute modification hors IaC est un incident à investiguer. Chaque drift signale soit un oubli de code, soit une mauvaise manipulation, soit une compromission en cours. Les CNAPP commerciaux (Wiz, Prisma Cloud) offrent aussi une vue drift cross-cloud centralisée.
  • CIS Benchmarks AWS, Azure, GCP : lequel prioriser ?
    Commencer par le cloud majoritaire de l'organisation. Distribution typique FR 2026 : AWS ~45 % des workloads, Azure ~35 %, GCP ~15 %, autres (OVH, Scaleway, multi-cloud) ~5 %. **CIS AWS Foundations Benchmark v3.0** (107 recommandations dans 5 sections : IAM, Logging, Monitoring, Networking, Storage) reste le référentiel le plus audité. **CIS Microsoft Azure Foundations Benchmark v3.0** (195 recommandations) est le plus volumineux. **CIS Google Cloud Platform Foundation Benchmark v2.1** (133 recommandations) est plus léger mais essentiel pour les workloads GCP. Pour chaque service spécialisé, CIS publie des benchmarks dédiés : CIS Kubernetes Benchmark 1.9 (K8s 1.29+), CIS Docker Community Edition Benchmark, CIS Amazon EKS / Azure AKS / GKE Benchmark. Outils d'évaluation automatique : Prowler (multi-cloud référence), AWS Security Hub CIS Standard, Azure Defender for Cloud Compliance, GCP Security Command Center Premium.

Écrit par

Naim Aouaichia

Expert cybersécurité et fondateur de Zeroday Cyber Academy

Expert cybersécurité avec un master spécialisé et un parcours hybride : développement, DevOps, DevSecOps, SOC, GRC. Fondateur de Hash24Security et Zeroday Cyber Academy. Formateur et créateur de contenu technique sur la cybersécurité appliquée, la sécurité des LLM et le DevSecOps.