OWASP Top 10 de Sécurité des Applications Cloud-Native

1�E�⃣ CNAS-1 - Configuration Insécurisée du Cloud, des Conteneurs ou de l'Orchestration

Vue d'ensemble

Les services cloud, conteneurs et orchestrateurs mal configurés sont la principale cause de violations dans les environnements cloud-native. Cela inclut l'exécution de conteneurs en tant que root, l'utilisation de configurations par défaut, l'exposition publique du serveur API Kubernetes et l'absence d'activation de la journalisation d'audit sur les ressources cloud.

Exemple de Code Vulnérable

# Running container as root with no resource limits
FROM ubuntu:latest
RUN apt-get update && apt-get install -y curl wget
COPY app /app
# No USER directive  Eruns as root!
CMD ["/app/server"]

Exemple de Code Sécurisé

FROM gcr.io/distroless/static:nonroot
COPY --chown=65534:65534 app /app
USER 65534:65534
EXPOSE 8080
ENTRYPOINT ["/app/server"]

Liste de Contrôle pour l'Atténuation

• Utiliser des images de base minimales, distroless et ne jamais exécuter de conteneurs en tant que root
• Activer et appliquer les Pod Security Standards (restricted) dans Kubernetes
• Analyser l'infrastructure-as-code (Terraform, Helm) avec des outils comme Checkov ou tfsec
• Restreindre l'accès aux endpoints de métadonnées cloud (169.254.169.254) et au serveur API Kubernetes

2�E�⃣ CNAS-2 - Failles d'Injection (Couche Applicative, Événements Cloud, Services Cloud)

Vue d'ensemble

Les applications cloud-native reçoivent des entrées non seulement à partir de requêtes HTTP traditionnelles, mais également à partir d'événements cloud (SQS, Pub/Sub, EventBridge), de déclencheurs serverless et de communications inter-services. Les failles d'injection dans l'un de ces vecteurs peuvent conduire à l'exécution de commandes, à l'exfiltration de données ou à l'escalade de privilèges.

Exemple de Code Vulnérable

# Lambda function processing S3 event without sanitizing filename
import os

def handler(event, context):
    bucket = event['Records'][0]['s3']['bucket']['name']
    key = event['Records'][0]['s3']['object']['key']
    # Command injection via crafted filename!
    os.system(f"aws s3 cp s3://{bucket}/{key} /tmp/{key}")

Exemple de Code Sécurisé

import boto3, re
from urllib.parse import unquote_plus

def handler(event, context):
    s3 = boto3.client('s3')
    bucket = event['Records'][0]['s3']['bucket']['name']
    key = unquote_plus(event['Records'][0]['s3']['object']['key'])

    # Validate key against allowlist pattern
    if not re.match(r'^[\w\-./]+$', key):
        raise ValueError(f"Invalid S3 key: {key}")

    # Use SDK instead of shell commands
    s3.download_file(bucket, key, f'/tmp/{key.split("/")[-1]}')

Liste de Contrôle pour l'Atténuation

• Valider et assainir toutes les entrées provenant d'événements cloud, de files d'attente et de déclencheurs
• Utiliser des appels SDK/API au lieu de commandes shell (éviter os.system, subprocess avec shell=True)
• Appliquer des schémas de validation d'entrée aux charges utiles d'événements (JSON Schema, protobuf)
• Implémenter le filtrage de sortie pour empêcher le SSRF depuis les fonctions serverless

3�E�⃣ CNAS-3 - Authentification et Autorisation Inappropriées

Vue d'ensemble

Les environnements cloud-native impliquent plusieurs couches d'identité : IAM cloud, RBAC Kubernetes, mTLS de service mesh et authentification au niveau de l'application. Des politiques mal configurées ou trop permissives à n'importe quelle couche peuvent permettre des déplacements latéraux, l'escalade de privilèges ou l'accès non autorisé à des ressources sensibles.

Exemple de Code Vulnérable

# Overly permissive ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: default-admin
subjects:
- kind: ServiceAccount
  name: default          # Default SA  Eshared by all pods!
  namespace: default
roleRef:
  kind: ClusterRole
  name: cluster-admin    # Full cluster access!
  apiGroup: rbac.authorization.k8s.io

Exemple de Code Sécurisé

# Dedicated ServiceAccount with minimal Role
apiVersion: v1
kind: ServiceAccount
metadata:
  name: order-service
  namespace: production
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456:role/order-svc
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: order-service-role
  namespace: production
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get"]

Liste de Contrôle pour l'Atténuation

• Utiliser des ServiceAccounts dédiés par charge de travail avec un RBAC au privilège minimum
• Implémenter IAM Roles for Service Accounts (IRSA/Workload Identity) au lieu de credentials au niveau du nœud
• Appliquer le TLS mutuel (mTLS) pour toutes les communications service-à-service
• Auditer régulièrement les liaisons RBAC et supprimer les permissions inutilisées

4�E�⃣ CNAS-4 - Failles du Pipeline CI/CD et de la Chaîne d'Approvisionnement Logicielle

Vue d'ensemble

Les pipelines CI/CD sont des cibles de grande valeur car ils ont un accès en écriture aux environnements de production. Compromettre un pipeline de build permet des attaques de la chaîne d'approvisionnement, l'injection de code malveillant et le déploiement d'images avec des portes dérobées. Les configurations de pipeline insécurisées, les images de base empoisonnées et les artefacts non signés contribuent tous à ce risque.

Exemple de Code Vulnérable

# Insecure CI pipeline  Eunpinned actions, no image signing
name: Deploy
on: push
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@main   # Unpinned  Ecould be compromised!
    - run: |
        docker build -t myapp:latest .
        docker push myregistry/myapp:latest  # No signing!
        kubectl apply -f deploy.yaml         # No admission control!

Exemple de Code Sécurisé

name: Secure Deploy
on: push
permissions:
  id-token: write
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@a5ac7e51b41094c92402da3b24376905380afc29  # Pinned SHA
    - run: |
        docker build -t myregistry/myapp:${{ github.sha }} .
        cosign sign myregistry/myapp:${{ github.sha }}  # Sign image
    - run: trivy image myregistry/myapp:${{ github.sha }} --exit-code 1
    - run: kubectl apply -f deploy.yaml  # Admission controller verifies signatures

Liste de Contrôle pour l'Atténuation

• Épingler les actions et dépendances CI/CD aux hachages SHA exacts, pas aux branches ou tags
• Signer les images de conteneurs avec Cosign/Notary et appliquer la vérification de signature à l'admission
• Analyser les images pour les vulnérabilités (Trivy, Grype) avant le déploiement
• Utiliser le framework SLSA pour garantir la provenance et l'intégrité des artefacts de build

5�E�⃣ CNAS-5 - Stockage Insécurisé des Secrets

Vue d'ensemble

Les secrets tels que les clés API, les identifiants de base de données et les certificats TLS sont souvent codés en dur dans le code source, stockés dans des ConfigMaps en texte clair ou intégrés dans les images de conteneurs. Les Secrets Kubernetes ne sont encodés qu'en base64 par défaut, non chiffrés, offrant une protection minimale.

Exemple de Code Vulnérable

# Secrets in plaintext environment variables
apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: app
    env:
    - name: DB_PASSWORD
      value: "SuperSecret123!"   # Plaintext in manifest!
    - name: AWS_SECRET_KEY
      value: "AKIA..."             # Cloud credentials in YAML!

Exemple de Code Sécurisé

# Use External Secrets Operator with a vault backend
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: my-app-secrets
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: my-app-secrets
  data:
  - secretKey: db-password
    remoteRef:
      key: secret/data/myapp
      property: db-password

Liste de Contrôle pour l'Atténuation

• Ne jamais stocker de secrets dans le code source, les Dockerfiles ou les ConfigMaps en texte clair
• Utiliser un gestionnaire de secrets (Vault, AWS Secrets Manager, GCP Secret Manager) avec rotation automatique
• Activer le chiffrement au repos pour les Secrets Kubernetes (fournisseur KMS)
• Analyser les dépôts et images pour détecter les secrets divulgués (git-secrets, TruffleHog, Trivy)

6�E�⃣ CNAS-6 - Politiques Réseau Trop Permissives ou Insécurisées

Vue d'ensemble

Par défaut, Kubernetes permet à tous les pods de communiquer entre eux sans restriction. Des NetworkPolicies manquantes ou trop permissives, des groupes de sécurité et des règles de pare-feu permettent les déplacements latéraux au sein du cluster et entre les services cloud.

Exemple de Code Vulnérable

# No NetworkPolicy  Eall pods can talk to everything
apiVersion: v1
kind: Namespace
metadata:
  name: production
# No NetworkPolicy resources defined
# All ingress and egress traffic is allowed by default

Exemple de Code Sécurisé

# Default-deny all traffic, then allow only what's needed
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes: ["Ingress", "Egress"]
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-api
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api-server
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - port: 8080

Liste de Contrôle pour l'Atténuation

• Implémenter des NetworkPolicies par défaut de refus pour tous les namespaces
• Autoriser uniquement le trafic requis entre les services en utilisant des sélecteurs d'étiquettes
• Restreindre le trafic de sortie pour empêcher l'exfiltration de données et la communication C2
• Utiliser un plugin CNI prenant en charge l'application des NetworkPolicy (Calico, Cilium)

7�E�⃣ CNAS-7 - Utilisation de Composants avec des Vulnérabilités Connues

Vue d'ensemble

Les applications cloud-native s'appuient fortement sur des images de base open-source, des bibliothèques et des opérateurs Kubernetes. L'exécution de composants obsolètes ou non corrigés avec des CVE connus expose l'application à des exploits bien documentés. Les images de conteneurs incluent souvent des centaines de packages, chacun étant une vulnérabilité potentielle.

Exemple de Code Vulnérable

# Using outdated base image with known CVEs
FROM node:14                    # EOL version with known vulns
COPY package.json .
RUN npm install                 # No audit, no lockfile verification
COPY . .
CMD ["node", "server.js"]

Exemple de Code Sécurisé

# Use current, slim base image with vulnerability scanning
FROM node:22-slim AS build
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --only=production    # Reproducible install from lockfile
RUN npm audit --audit-level=high # Fail on high+ vulns

FROM gcr.io/distroless/nodejs22-debian12
COPY --from=build /app /app
CMD ["/app/server.js"]

Liste de Contrôle pour l'Atténuation

• Analyser en continu les images de conteneurs pour les CVE dans le CI/CD et à l'exécution
• Utiliser des images de base minimales (distroless, Alpine) pour réduire la surface d'attaque
• Automatiser les mises à jour de dépendances avec Dependabot, Renovate ou des outils similaires
• Maintenir un SBOM et suivre les versions de composants dans tous les déploiements

8�E�⃣ CNAS-8 - Gestion Inappropriée des Actifs

Vue d'ensemble

Les environnements cloud-native facilitent le lancement de ressources mais rendent difficile leur suivi. Les conteneurs orphelins, les namespaces oubliés, les ressources cloud obsolètes et les déploiements informatiques parallèles créent une surface d'attaque non gérée. Sans inventaire d'actifs approprié, les équipes de sécurité ne peuvent pas protéger ce qu'elles ne savent pas exister.

Exemple de Code Vulnérable

# Resources created without tagging or lifecycle management
resource "aws_instance" "test_server" {
  ami           = "ami-0abcdef1234567890"
  instance_type = "t3.medium"
  # No tags  Ewho owns this? What's it for?
  # No lifecycle policy  Eruns forever
}

resource "aws_s3_bucket" "temp_data" {
  bucket = "temp-data-2024"
  # No expiration, no access logging
}

Exemple de Code Sécurisé

resource "aws_instance" "test_server" {
  ami           = "ami-0abcdef1234567890"
  instance_type = "t3.medium"

  tags = {
    Name        = "test-server"
    Owner       = "platform-team"
    Environment = "staging"
    ManagedBy   = "terraform"
    ExpiresAt   = "2026-04-30"
  }
}

resource "aws_s3_bucket" "temp_data" {
  bucket = "temp-data-2024"

  tags = {
    Owner     = "data-team"
    ManagedBy = "terraform"
  }

  lifecycle_rule {
    enabled = true
    expiration { days = 90 }
  }
}

Liste de Contrôle pour l'Atténuation

• Maintenir un inventaire en temps réel de toutes les ressources cloud, clusters et namespaces
• Appliquer des politiques de balisage obligatoires (propriétaire, environnement, expiration) pour toutes les ressources
• Automatiser la détection et le nettoyage des ressources orphelines (AWS Config, GCP Asset Inventory)
• Implémenter l'infrastructure-as-code pour empêcher la création manuelle de ressources non suivies

9�E�⃣ CNAS-9 - Limites de Quota de Ressources de Calcul Inadéquates

Vue d'ensemble

Sans quotas de ressources et limites appropriés, une seule charge de travail défaillante ou compromise peut consommer tout le CPU, la mémoire ou le stockage disponible, provoquant un déni de service pour d'autres applications. Les attaques de cryptojacking sont particulièrement courantes dans les environnements sans limites de ressources.

Exemple de Code Vulnérable

# Pod with no resource limits
apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: app
    image: myapp:latest
    # No resources block  Ecan consume unlimited CPU/memory!

Exemple de Code Sécurisé

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: app
    image: myapp:1.2.3
    resources:
      requests:
        cpu: "100m"
        memory: "128Mi"
      limits:
        cpu: "500m"
        memory: "512Mi"
---
# Namespace-level quota
apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-quota
  namespace: production
spec:
  hard:
    requests.cpu: "10"
    requests.memory: "20Gi"
    limits.cpu: "20"
    limits.memory: "40Gi"

Liste de Contrôle pour l'Atténuation

• Définir des requêtes/limites de CPU et de mémoire sur chaque conteneur
• Appliquer des ResourceQuotas et LimitRanges au niveau du namespace
• Surveiller l'utilisation des ressources et alerter sur les modèles de consommation anormaux
• Utiliser l'autoscaler de cluster avec des limites de nœuds maximales pour empêcher la mise à l'échelle illimitée

🔟 CNAS-10 - Journalisation et Surveillance Inefficaces

Vue d'ensemble

Les environnements cloud-native génèrent des journaux sur plusieurs couches : application, runtime de conteneur, orchestrateur, service mesh et plateforme cloud. Sans journalisation centralisée, corrélation entre ces couches et détection de menaces à l'exécution, les incidents de sécurité passent inaperçus ou sont découverts trop tard.

Exemple de Code Vulnérable

# No audit policy, no log forwarding
apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: app
    image: myapp:latest
    # Logs go to stdout only  Elost when pod restarts
    # No audit logging configured on the cluster
    # No runtime security monitoring

Exemple de Code Sécurisé

# Kubernetes audit policy for security events
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: RequestResponse
  resources:
  - group: ""
    resources: ["secrets", "configmaps"]
- level: Metadata
  resources:
  - group: "rbac.authorization.k8s.io"
    resources: ["clusterroles", "clusterrolebindings"]
- level: Metadata
  verbs: ["create", "delete", "patch"]
# Deploy Falco for runtime threat detection
# Forward logs to SIEM via Fluent Bit / Fluentd

Liste de Contrôle pour l'Atténuation

• Activer la journalisation d'audit Kubernetes et transférer vers un SIEM centralisé
• Déployer des outils de sécurité à l'exécution (Falco, Sysdig) pour la détection de menaces en temps réel
• Utiliser l'agrégation de journaux (Fluent Bit, Loki) pour conserver les journaux de conteneurs au-delà du cycle de vie du pod
• Créer des alertes pour les événements critiques de sécurité : accès aux secrets, modifications RBAC, exec dans les pods

📊 Tableau Récapitulatif