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.
| Pilier | Contrôle | AWS | Azure | GCP |
|---|---|---|---|---|
| IAM moindre privilège | Policies scopées, rôles temporaires | IAM + IAM Identity Center | Entra ID + RBAC | Cloud IAM + IAM conditions |
| Chiffrement at-rest | Données chiffrées au stockage | KMS + SSE-S3/KMS | Storage Service Encryption + Key Vault | Cloud KMS + CMEK |
| Chiffrement in-transit | TLS 1.2+ partout | ACM + ALB/NLB HTTPS | Front Door + App Gateway TLS | Cloud Load Balancing + Managed SSL |
| Logging et audit | Logs complets centralisés | CloudTrail + Config + VPC Flow | Activity Log + Defender for Cloud + NSG Flow | Cloud 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ôle | Outil natif | CIS Benchmark |
|---|---|---|---|
| 1 | Block Public Access account-wide | S3 Block Public Access | CIS 2.1.5 |
| 2 | Chiffrement SSE-KMS ou SSE-S3 par défaut | Default encryption | CIS 2.1.1 |
| 3 | Versioning activé | S3 Versioning | CIS 2.1.3 |
| 4 | MFA Delete sur buckets critiques | S3 Bucket Policy | CIS 2.1.4 |
| 5 | Access Logging activé | S3 Server Access Logging | CIS 3.6 |
| 6 | Bucket Policy restrictive | Bucket Policy + IAM | CIS 2.1.2 |
| 7 | Object Lock pour immutabilité (backup, logs) | Object Lock | - |
| 8 | Cross-Region Replication pour critiques | CRR | - |
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ôle | Raison |
|---|---|---|
| 1 | Encryption at rest activée | Non modifiable post-création RDS — critique dès la creation |
| 2 | Encryption in transit forcée (SSL/TLS) | Prévient sniff réseau interne |
| 3 | Endpoint non-public (subnet privé) | Pas d'exposition 0.0.0.0/0 DB |
| 4 | IAM authentication ou SSO (pas password) | Reduce credential sprawl |
| 5 | Rotation automatique credentials | Vault ou Secrets Manager |
| 6 | Backup automatique + PITR | Recovery post-incident |
| 7 | Multi-AZ ou équivalent | Résilience |
| 8 | Audit log activé | CloudTrail DB events, Azure SQL Auditing |
| 9 | Network ACL stricte (security group) | Allow-list port 3306/5432/1433 |
| 10 | Version 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ôle | Description |
|---|---|
| IMDSv2 enforced | Prévient le vol credentials via SSRF (Capital One 2019) |
| Encryption disque at rest | EBS 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 baseline | SSM Patch Manager, Azure Update Manager, OS Config GCP |
| Security Group minimaliste | Pas de 0.0.0.0/0 sur admin ports |
| VPC Flow Logs | Trafic réseau audité |
| Anti-malware endpoint | CrowdStrike, 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 enabled5. 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ègle | AWS | Azure | GCP |
|---|---|---|---|
| Subnets privés pour workloads sensibles | Private subnet + NAT Gateway | Private subnet + NAT Gateway | Private subnet + Cloud NAT |
| Security Groups minimaux (stateful) | Security Group | NSG (Network Security Group) | Firewall rules |
| Jamais 0.0.0.0/0 sur ports admin | SG rules | NSG rules | Firewall rules |
| Private endpoints pour services SaaS | VPC Endpoints (Gateway + Interface) | Private Link | Private Service Connect |
| Flow logs activés | VPC Flow Logs | NSG Flow Logs | VPC Flow Logs |
| Segmentation multi-compte/multi-projet | Organizations + SCPs + Transit Gateway | Management Groups + Hub-Spoke | Organizations + VPC Service Controls |
5.2 Erreurs classiques réseau
- Security Group default modifié. Ne jamais toucher le SG default. Créer des SG nommés par fonction.
0.0.0.0/0:22sur un SG. Utiliser SSM Session Manager à la place.- NAT Gateway par VPC au lieu de par AZ. Résilience insuffisante.
- VPC Peering full-mesh dans une topologie > 5 VPC. Préférer Transit Gateway ou Hub-Spoke VNet.
- 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
- Least privilege : actions et ressources scopées au minimum vital.
- Roles > users : credentials temporaires via STS / SAS token / short-lived tokens.
- MFA obligatoire sur tous les humains, hardware key pour privilégiés.
- SSO / IAM Identity Center : identité centrale, provisioning automatique SCIM.
- 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 natif | Cloud | Gratuité | Usage |
|---|---|---|---|
| AWS Config | AWS | ~20-80 €/mois | Inventaire + règles conformité |
| AWS Security Hub | AWS | ~10-30 €/mois | Agrégation + CIS/PCI-DSS/FedRAMP benchmarks |
| Azure Policy | Azure | Gratuit | Règles de conformité |
| Azure Defender for Cloud | Azure | Gratuit Foundational, payant full | Security posture + threat detection |
| GCP Security Command Center | GCP | Gratuit Standard, payant Premium | Findings + compliance benchmarks |
| Google Cloud Config Validator | GCP | Gratuit (OPA) | Validation manifest pré-déploiement |
7.2 Outils open source multi-cloud
| Outil | Éditeur | Spécificité |
|---|---|---|
| Prowler | Toni de la Fuente (Prowler Inc.) | 500+ checks AWS + Azure + GCP + Kubernetes, référence |
| ScoutSuite | NCC Group | Multi-cloud scan + rapport HTML |
| CloudSploit | Aqua | 200+ checks cloud |
| Cloud Custodian | Capital One | Policy-as-code cross-cloud |
| kube-bench | Aqua | CIS Kubernetes Benchmark |
| kubescape | ARMO | Multi-framework K8s (NSA, MITRE ATT&CK, CIS) |
| Pacu | Rhino Security Labs | Exploitation 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'abord7.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.
| Vendeur | Positionnement 2026 |
|---|---|
| Wiz | Racheté Google mars 2025 (32 Mds $), graph-based, leader |
| Palo Alto Prisma Cloud | Suite complète, intégration Panorama |
| CrowdStrike Falcon Cloud | Threat intel + AI detection |
| Orca Security | Side-scanning agentless |
| AccuKnox | Open source + commercial, K8s-first |
| Sysdig Secure | Runtime-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
| Couche | Outil |
|---|---|
| Provisioning | Terraform 1.x, OpenTofu 1.x, Pulumi, AWS CDK |
| Templates K8s | Helm 3.x, Kustomize, CUE |
| Policy-as-code | OPA/Conftest, Checkov, tfsec, Terrascan, KICS |
| Secrets | HashiCorp Vault, AWS Secrets Manager, SOPS |
| CI/CD validation | GitLab 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: manual8.3 Politique zero manual change en prod
Protocole recommandé 2026 :
- SCP / Azure Policy deny bloquant la modification manuelle des ressources taguées
ManagedBy: Terraformen production. - Drift detection automatique (AWS Config, Terraform Cloud, Prowler) scanné quotidiennement.
- Alerting immédiat sur drift détecté → création ticket Jira / notification Slack.
- 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
| Benchmark | Version 2026 | Recommandations | Usage |
|---|---|---|---|
| CIS AWS Foundations | v3.0 | 107 | Core AWS, tout compte |
| CIS Microsoft Azure Foundations | v3.0 | 195 | Core Azure, toute subscription |
| CIS Google Cloud Platform Foundation | v2.1 | 133 | Core GCP, tout projet |
| CIS Amazon EKS Benchmark | v1.5 | ~45 | Clusters EKS |
| CIS Kubernetes Benchmark | v1.9 | ~120 | K8s self-managed 1.29+ |
| CIS Docker Benchmark | v1.7 | ~100 | Docker 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 :
- MFA hardware sur root / Global Admin / Project Owner.
- CloudTrail / Activity Log / Audit Log activés tous événements, logs chiffrés en compte dédié.
- Posture management activé (Security Hub, Defender for Cloud, Security Command Center).
- Chiffrement par défaut actif sur tout stockage (S3, Blob, GCS, EBS, Disk).
- Block Public Access account-wide activé.
- Pas d'access keys longue durée pour humains (SSO / IAM Identity Center).
- Network segmentation minimale (VPC / VNet séparé par environnement).
- Pas de 0.0.0.0/0 sur ports admin (22, 3389, 3306, 5432, 6379, 27017, 9200).
- IaC en place (Terraform ou équivalent) pour toute nouvelle ressource.
- 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.







