Sécurité des workloads cloud - Guide par type de workload

Un workload cloud est toute unité de calcul déployée sur un provider : machine virtuelle, conteneur orchestré, fonction serverless, base de données managée, file de messages, pipeline de données. Chacune a son modèle de responsabilité, ses surfaces d'attaque propres et ses contrôles adaptés. Un ingénieur qui sécurise "le cloud" en généralisant oublie toujours la moitié. Ce guide décompose la question par type de workload, avec les contrôles prioritaires, les pièges fréquents et les outils de marché.

1. Responsabilité partagée par type de workload

Le modèle "shared responsibility" d'AWS/GCP/Azure évolue avec le niveau d'abstraction. Plus le workload est managé, plus le client se concentre sur la configuration et l'identité, moins sur l'OS et le réseau.

Corollaire pratique : un audit sécurité cloud qui traite tous les workloads avec la même grille passe à côté. Chaque type a sa grille.

2. Les trois piliers de contrôle transverses

Avant de plonger par type, trois contrôles s'appliquent à tous les workloads cloud, sans exception.

2.1 Workload identity - la pierre angulaire

Un workload doit avoir une identité cryptographique liée à sa plateforme, pas des credentials long-lived stockés quelque part.

Bénéfices : aucun credential long-lived, rotation automatique, audit unifié, scope précis.

2.2 Moindre privilège et CIEM

Chaque identité de workload ne devrait avoir que les permissions strictement nécessaires. En pratique dans les grandes entreprises, plus de 95 % des permissions IAM ne sont jamais utilisées, et plus de 50 % des identités ont des privilèges élevés sans justification documentée.

Solutions :

• IAM Access Analyzer (AWS), Policy Analyzer (GCP), Identity Governance (Azure) : détection des permissions inutilisées.
• CIEM (Cloud Infrastructure Entitlement Management) : catégorie d'outils spécialisée (Wiz, Orca, Ermetic, Sonrai). Ils modélisent l'ensemble des identités + permissions + chemins d'escalade dans un graphe et aident à réduire la surface.
• Politique de revue trimestrielle obligatoire pour les rôles à privilèges élevés.

2.3 Observabilité sécurité

Un workload cloud sans logs, sans métriques sécurité et sans audit trail ne peut pas être défendu.

• Audit logs API du provider exportés vers un SIEM (CloudTrail, Cloud Audit Logs, Activity Log).
• VPC Flow Logs ou équivalents pour le trafic réseau.
• Runtime events : syscalls, processus, connexions (Falco, Tetragon, agents CWPP).
• Application logs structurés avec corrélation par trace ID.
• Rétention minimale : 90 jours pour SIEM chaud, 1 an pour archive.

3. Sécurité des machines virtuelles (VM)

3.1 Modèle de menace VM

• Exploitation de services exposés (SSH, RDP, applications).
• Compromission via vulnérabilité non patchée (Heartbleed, Log4Shell, etc.).
• Vol de credentials via Instance Metadata Service (voir §3.4).
• Latéralisation depuis un autre workload du même VPC.
• Exfiltration de données sur volumes non chiffrés.

3.2 Contrôles prioritaires

• Images durcies (golden images) : construites via Packer ou équivalent, avec CIS Benchmark appliqué, scan de vulnérabilités, versioning.
• Patch management automatisé : AWS Systems Manager Patch Manager, Azure Update Management, Google OS Config. Fenêtres de patching récurrentes.
• SSH/RDP accessibles via bastion uniquement, jamais exposés sur internet.
• Bastion moderne : AWS Session Manager (zero SSH exposure), GCP IAP (Identity-Aware Proxy), Azure Bastion.
• Segmentation réseau : VPC dédiés, subnets privés par tier, security groups restrictifs.
• Chiffrement des volumes par défaut avec KMS customer-managed keys.

3.3 Exemple - Security Group AWS restrictif

resource "aws_security_group" "app" {
  name        = "app-production"
  vpc_id      = aws_vpc.main.id
 
  ingress {
    description     = "HTTPS from ALB only"
    from_port       = 443
    to_port         = 443
    protocol        = "tcp"
    security_groups = [aws_security_group.alb.id]
  }
 
  egress {
    description     = "PostgreSQL to database SG"
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
    security_groups = [aws_security_group.db.id]
  }
 
  egress {
    description = "HTTPS to AWS APIs via VPC endpoint"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    prefix_list_ids = [aws_vpc_endpoint.s3.prefix_list_id]
  }
}

Points clés : source_security_groups plutôt que cidr_blocks = ["0.0.0.0/0"], egress explicite, VPC endpoints pour les services cloud (évite le trafic internet).

3.4 IMDSv2 obligatoire - l'erreur Capital One

L'Instance Metadata Service (IMDS) permet à une VM de récupérer ses credentials IAM temporaires en interrogeant l'adresse locale 169.254.169.254. L'IMDSv1 répondait sur une simple requête GET, ce qui transforme toute SSRF en vol de credentials cloud (incident Capital One 2019, 100 millions de clients).

Mitigation : IMDSv2 exige un token court obtenu via PUT. Depuis 2024, IMDSv2 est par défaut sur les nouvelles instances AWS. Vérifier sur le parc existant :

aws ec2 describe-instances --query 'Reservations[].Instances[?MetadataOptions.HttpTokens!=`required`].InstanceId'

3.5 Runtime security sur VM

• EDR ou équivalent (CrowdStrike, SentinelOne, Microsoft Defender for Cloud).
• Agents CWPP (Cloud Workload Protection Platform) : Prisma Cloud, Wiz Runtime, Lacework.
• Logs d'authentification système exportés (/var/log/auth.log, Windows Security Event).
• File Integrity Monitoring (FIM) sur répertoires sensibles.

4. Sécurité des conteneurs et Kubernetes

Détaillé dans le guide Sécurité Kubernetes : les bases. Synthèse des contrôles essentiels :

• Images depuis registre privé, scannées, signées Cosign.
• Pod Security Admission en profil restricted pour workloads applicatifs.
• Network Policies default-deny + autorisations explicites.
• RBAC strict, SA dédié par workload, automountServiceAccountToken: false.
• Admission controllers (Kyverno/OPA) pour vérification signatures et politiques.
• Secrets externalisés via External Secrets Operator ou CSI Driver.
• Runtime security via Falco/Tetragon.

Spécificités serverless conteneur (Fargate, Cloud Run) :

• Pas d'accès au node, pas d'agent runtime installable → dépendance aux contrôles d'admission et à la défense en profondeur applicative.
• Logs centralisés via CloudWatch/Cloud Logging, pas d'accès shell.
• Scan d'image avant push obligatoire (les scans runtime étant limités).

5. Sécurité serverless (FaaS)

5.1 Modèle de menace Lambda / Cloud Functions / Azure Functions

• Injection dans le code de la fonction (classique : SQLi, SSRF, command injection).
• Event injection : triggers manipulables (S3 event, SQS message, HTTP API) qui déclenchent la fonction avec un payload malveillant.
• Over-permissioned execution role : fonction avec *:* qui devient un point de pivot si compromise.
• Dependency poisoning : une lib vulnérable ou malveillante dans les node_modules/requirements.txt.
• Cold start enumeration : tests de synchronisation qui révèlent des informations sur l'infrastructure.

5.2 Contrôles prioritaires

• IAM role minimal par fonction : une fonction par rôle, pas un rôle partagé. Permissions au niveau ARN précis.
• Validation stricte des events d'entrée : schéma JSON validé dès l'entrée de la fonction.
• Secrets via store managé : Lambda → Secrets Manager / Parameter Store, pas en variables d'environnement.
• VPC endpoints pour éviter le trafic internet sortant quand la fonction parle à des services AWS.
• Concurrency limits pour éviter les scénarios de DoS par facturation.
• Dead Letter Queue (DLQ) pour tracer les événements qui ont échoué.
• Layers versionnés : figer les versions, pas de tag latest.

5.3 Exemple - Lambda avec IAM minimal

resource "aws_iam_role" "lambda_process_order" {
  name = "lambda-process-order"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect = "Allow"
      Principal = { Service = "lambda.amazonaws.com" }
      Action = "sts:AssumeRole"
    }]
  })
}
 
resource "aws_iam_role_policy" "lambda_process_order" {
  role = aws_iam_role.lambda_process_order.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Action = ["logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents"]
        Resource = "arn:aws:logs:eu-west-3:123456789012:log-group:/aws/lambda/process-order:*"
      },
      {
        Effect = "Allow"
        Action = ["secretsmanager:GetSecretValue"]
        Resource = "arn:aws:secretsmanager:eu-west-3:123456789012:secret:orders/db-password-*"
      },
      {
        Effect = "Allow"
        Action = ["dynamodb:PutItem", "dynamodb:UpdateItem"]
        Resource = "arn:aws:dynamodb:eu-west-3:123456789012:table/Orders"
      }
    ]
  })
}

5.4 SAST et SCA adaptés

• SAST classique s'applique au code de la fonction.
• SCA sur les dépendances déployées (incluses dans le package ou dans les layers).
• Outils spécialisés : Snyk Cloud, Checkmarx AST, PureSec (Prisma Cloud).

5.5 Le piège du "serverless = pas de sécurité à gérer"

Erreur classique : croire qu'en supprimant les serveurs on supprime les responsabilités. En réalité les responsabilités sont déplacées vers l'identité et le code, où elles deviennent plus granulaires (une fonction = une identité = un ensemble de permissions).

6. Sécurité des bases de données managées

6.1 Modèle de menace

• Exposition publique par mauvaise configuration (base accessible depuis internet).
• Credentials hardcodés dans le code ou les configs.
• Snapshots/backups non chiffrés ou partagés cross-account par erreur.
• Absence d'audit des accès.
• Extraction massive non détectée.

6.2 Contrôles prioritaires

• Pas d'accès public : security group restrictif, base dans subnet privé.
• Chiffrement au repos avec KMS customer-managed keys (pas seulement AWS-managed).
• Chiffrement en transit avec TLS obligatoire (force SSL option côté RDS PostgreSQL par exemple).
• IAM authentication quand le DB engine le supporte (RDS IAM auth, Cloud SQL IAM, Cosmos DB AAD) plutôt que mots de passe.
• Audit logs activés, exportés vers SIEM : connexions, requêtes DDL, requêtes sur tables sensibles.
• Snapshots chiffrés et isolés, copies cross-region chiffrées avec même clé KMS.
• Secrets Manager avec rotation automatique pour les credentials DB.
• Database firewall pour détecter les requêtes anormales (AWS RDS Proxy avec auth, ProxySQL, etc.).

6.3 Data Loss Prevention (DLP)

• Classification automatique des données sensibles : Macie (AWS), DLP (GCP), Purview (Azure).
• Masking ou tokenization des données sensibles pour environnements de dev/test.
• Policies d'exfiltration : alertes sur volumes de requêtes anormaux, téléchargements massifs.

6.4 Exemple - RDS avec exigences durcies

resource "aws_db_instance" "orders" {
  identifier     = "orders-prod"
  engine         = "postgres"
  engine_version = "16.4"
  instance_class = "db.m6g.large"
 
  storage_encrypted = true
  kms_key_id        = aws_kms_key.rds.arn
 
  publicly_accessible       = false
  vpc_security_group_ids    = [aws_security_group.db.id]
  db_subnet_group_name      = aws_db_subnet_group.private.name
 
  iam_database_authentication_enabled = true
  performance_insights_enabled        = true
  monitoring_interval                 = 60
 
  backup_retention_period = 30
  deletion_protection     = true
  skip_final_snapshot     = false
 
  enabled_cloudwatch_logs_exports = ["postgresql", "upgrade"]
 
  parameter_group_name = aws_db_parameter_group.secure.name
}
 
resource "aws_db_parameter_group" "secure" {
  family = "postgres16"
  parameter {
    name  = "rds.force_ssl"
    value = "1"
  }
  parameter {
    name  = "log_statement"
    value = "ddl"
  }
  parameter {
    name  = "log_connections"
    value = "1"
  }
}

7. Sécurité du stockage objet (S3, GCS, Blob)

7.1 Le problème historique - buckets publics

Des milliards de fichiers ont été exposés ces 10 dernières années via des buckets S3 publics par erreur : Capital One, Accenture, Pentagon, Uber, TSB Bank, WWE, Verizon, Viacom.

7.2 Contrôles prioritaires

• Block Public Access activé au niveau account + bucket. Sur AWS depuis 2023, bloqué par défaut sur nouveaux buckets.
• Bucket policies explicites avec principe de moindre privilège. Pas de Principal: "*" sauf cas très justifié.
• Encryption by default : SSE-KMS avec clé customer-managed obligatoire pour données sensibles.
• Versioning + MFA Delete : empêche la suppression accidentelle ou malveillante.
• Object Lock (mode WORM) : immuabilité pour données réglementaires.
• Access logs activés, exportés vers SIEM.
• IAM policies conditionnelles : aws:SourceVpc, aws:PrincipalOrgID pour limiter l'accès.

7.3 Classification automatique

• Macie (AWS), DLP (GCP), Purview (Azure) scannent les buckets pour détecter automatiquement les données sensibles (PII, credentials, données financières).
• Alertes sur objets nouvellement classés "sensible" mais accessibles de manière trop large.

7.4 CORS et accès pré-signé

• CORS ouvert à * : revoir systématiquement, limiter aux origines métier.
• URLs pré-signées : durée courte (15 min max), ne jamais les logger en clair.
• Pas de "public bucket" utilisé comme CDN sans contrôle : préférer CloudFront/Cloud CDN avec OAI/OAC.

8. Posture Management - CSPM, CWPP, CNAPP

Ces trois acronymes couvrent des besoins différents mais complémentaires.

8.1 CSPM (Cloud Security Posture Management)

Scanne la configuration cloud en continu et détecte les dérives par rapport à des benchmarks (CIS, PCI-DSS, HIPAA, custom).

• Outils natifs : AWS Security Hub, GCP Security Command Center, Azure Defender for Cloud.
• Outils tiers : Prisma Cloud, Wiz, Orca, Lacework, Dome9 (Check Point).
• Exemples de findings : bucket public, security group 0.0.0.0/0:22, instance sans tag obligatoire, KMS key sans rotation.

8.2 CWPP (Cloud Workload Protection Platform)

Protection runtime des workloads : VMs, conteneurs, serverless.

• Agent sur VM + agent Kubernetes pour runtime syscalls.
• Détection d'exploits, crypto-miners, reverse shells, exfiltration.
• Intégration EDR + scanning de vulnérabilités + compliance.

8.3 CNAPP (Cloud-Native Application Protection Platform)

Terme Gartner pour la convergence CSPM + CWPP + CIEM + DSPM + supply chain.

• Vision unifiée : "un attaquant qui arrive ici via ce chemin peut accéder à ça".
• Graphe d'attaque modélisé à partir des configs IAM + exposition réseau + vulnérabilités + data sensibilité.
• Prioritisation par risque réel, pas par CVE score brut.

Leaders CNAPP 2025 : Wiz, Prisma Cloud, Orca, Lacework, SentinelOne Cloud.

9. Patterns d'attaque fréquents sur workloads cloud

9.1 Credentials stuffing depuis code source public

Attaquants scrapent GitHub, GitLab public, pastebin. Credentials AWS fuités = compromission en moyenne en 60 secondes, provisionnement de miners GPU dans les 5 minutes suivantes. Mitigation : secret scanning, rotation immédiate, CloudTrail + GuardDuty alertes sur CreateInstance inhabituel.

9.2 SSRF vers IMDS

Vu au §3.4. Mitigation : IMDSv2, validation d'URL serveur-side, WAF.

9.3 Role chaining

Un attaquant qui compromet un rôle peut l'utiliser pour assumer d'autres rôles si les trust policies sont trop larges. Mitigation : trust policies scopées au minimum (External ID, Source Account, MFA), CIEM pour détecter les chaînes d'escalade.

9.4 Bucket takeover via dangling DNS

Un bucket S3 supprimé dont le nom est encore référencé dans un DNS peut être recréé par un attaquant qui prend le contrôle du sous-domaine. Mitigation : audit des CNAME vers S3, re-création défensive avant suppression.

9.5 Serverless persistence

Un attaquant qui compromet un compte peut créer une Lambda avec EventBridge trigger planifié (par exemple "exfiltre les secrets chaque nuit"). Détection difficile car le trafic est léger et périodique. Mitigation : audit régulier des functions et triggers, GuardDuty detection de patterns de persistence.

9.6 Kubernetes node compromise pivoting

Compromission d'un nœud K8s → accès aux secrets montés sur le nœud → pivot vers IAM role du nœud → accès cloud. Mitigation : Pod Security pour empêcher privileged, Network Policies, node hardening (gVisor, Kata Containers pour workloads sensibles), rôle IAM node minimal.

10. Compliance et frameworks de référence

Selon le secteur, différentes grilles s'appliquent aux workloads cloud :

• CIS Benchmarks : AWS, Azure, GCP, chaque grand service (EKS, RDS, etc.).
• NIST SP 800-53 et SP 800-210 : contrôles sécurité cloud fédéraux US.
• ISO 27017 : sécurité cloud, complément de ISO 27001.
• PCI-DSS : si données cartes bancaires.
• HDS (France) : données de santé.
• DORA (EU finance, applicable janvier 2025).
• NIS 2 (EU, transposée France 2024).
• CNIL guides sectoriels : santé, collectivités, RGPD.

Les frameworks se mappent facilement sur les contrôles techniques : chiffrement, logging, IAM, backup. L'enjeu n'est pas de les connaître tous, c'est d'avoir un processus pour mapper un nouveau framework sur les contrôles déjà en place.

11. Checklist hardening workload cloud

Applicable à tout nouveau workload déployé en production, quel que soit son type.

Identité

• Identité workload liée à la plateforme (IRSA, Managed Identity, Workload Identity Federation)
• IAM role scoped au strict nécessaire, vérifié via Access Analyzer
• Rotation automatique des credentials
• Audit trail des accès vers SIEM

Réseau

• Pas d'exposition publique non justifiée
• Security group / NSG restrictif, source explicite
• VPC endpoints pour services cloud internes
• Bastion moderne pour accès admin (Session Manager, IAP, Azure Bastion)

Données

• Chiffrement au repos avec CMK
• Chiffrement en transit (TLS 1.2 minimum)
• Backup automatisé et testé (restore quarterly)
• Classification et inventaire des données sensibles

Code et images

• Image / artefact issu d'un build signé
• SBOM attaché et matching CVE
• Scan de vulnérabilités à jour
• Pas de secret en clair dans code/env/configs

Runtime

• Agent CWPP ou équivalent (sauf Fargate/Cloud Run)
• Logs d'application structurés centralisés
• Alertes configurées sur anomalies
• Limites de resources et concurrency définies

Posture

• CSPM activé avec benchmarks applicables
• Findings critiques triés sous 7 jours
• Revue IAM trimestrielle
• Audit log rétention conforme aux obligations

12. Roadmap sécurisation workloads sur 6 mois

Mois 1 - inventaire et baseline

• Inventaire complet : workloads actifs, classification par criticité.
• Activation CSPM natif (Security Hub, Defender, SCC).
• Audit IAM massif, identification des rôles surprivilégiés.
• Baseline des findings.

Mois 2 - quick wins IAM et réseau

• Suppression des rôles inutilisés.
• Correction des buckets publics, des SG trop ouverts.
• Activation Block Public Access, SCPs/Organization policies de verrouillage.
• MFA enforced sur tous les comptes root et admins.

Mois 3 - chiffrement et secrets

• Chiffrement des volumes et storage avec CMK.
• Migration des secrets hardcodés vers Secrets Manager / Vault.
• Rotation automatique des credentials DB.
• Audit logs bases de données.

Mois 4 - runtime et CWPP

• Déploiement agent CWPP sur workloads critiques.
• Activation runtime detection sur K8s (Falco/Tetragon).
• Intégration avec le SIEM, définition des règles de détection.

Mois 5 - serverless et supply chain

• Revue des Lambdas et fonctions avec rôles surprivilégiés.
• SBOM automatique sur tous les builds.
• Signatures Cosign sur images Docker, vérification à l'admission.

Mois 6 - CNAPP et processus

• Évaluation et déploiement d'une solution CNAPP.
• Définition d'un processus de priorisation basé graphe d'attaque.
• Exercices red team cloud pour valider les contrôles.

13. Verdict et posture Zeroday

Sécuriser des workloads cloud ne se résume pas à "activer un outil". C'est une discipline qui croise trois compétences : identité (IAM, workload identity, CIEM), infrastructure (réseau, chiffrement, runtime), et développement (secure coding, SBOM, signatures). Les ingénieurs rares sur ce marché sont ceux qui couvrent les trois.

La bonne nouvelle : les providers cloud fournissent 70 à 80 % des briques de base gratuitement ou à coût marginal. Le gros de l'investissement n'est pas dans l'outillage, c'est dans la discipline opérationnelle : patcher, roter, revoir, auditer, améliorer. C'est répétitif, souvent non glamour, et c'est ce qui distingue les organisations qui vivent un incident majeur de celles qui l'évitent.

Pour approfondir l'IAM cloud : IAM expliqué simplement. Pour commencer sur AWS : AWS security pour débutant. Pour le volet Kubernetes : sécurité Kubernetes : les bases.