Fondamentaux de la sécurité runtime¶

Shift-left vs sécurité runtime¶

L'approche shift-left consiste à détecter les problèmes de sécurité le plus tôt possible dans le cycle de développement (code review, scanning CI, admission control). C'est nécessaire mais insuffisant :

• Les vulnerabilites zero-day n'ont pas de signature connue au moment du build
• Un conteneur sain peut etre compromis apres déploiement (exploitation d'une API, credential vole)
• Les configurations drift en production (modification manuelle, misconfiguration)
• Les attaques supply chain injectent du code malveillant dans des dependances legitimes

La sécurité runtime est le dernier rempart : elle détecte ce qui a echappe a toutes les couches précédentes.

Defense in depth¶

La sécurité runtime s'inscrit dans une stratégie de defense en profondeur :

graph TD
    C1["Couche 1 : Code<br/>SAST, code review, secrets scan"] --> C2
    C2["Couche 2 : Build<br/>scanning images, SBOM, signing"] --> C3
    C3["Couche 3 : Deploy<br/>admission control, OPA"] --> C4
    C4["Couche 4 : Runtime<br/>Falco, eBPF, MAC"] --> C5
    C5["Couche 5 : Reseau<br/>NetworkPolicy, mTLS, WAF"] --> C6
    C6["Couche 6 : Donnees<br/>chiffrement, backup, audit"]

Chaque couche reduit la surface d'attaque. La couche runtime (couche 4) est critique car elle observe les comportements reels du système.

MITRE ATT&CK pour conteneurs¶

Le framework MITRE ATT&CK for Containers cartographie les techniques d'attaque spécifiques aux environnements conteneurises :

Accès initial¶

Execution¶

Persistence¶

Privilege escalation¶

Lateral movement¶

Menaces runtime courantes¶

Container escape¶

Un attaquant exploite une vulnérabilité du kernel ou du runtime (runc, containerd) pour sortir de l'isolation du conteneur et accéder au host.

Detection : Falco détecte les appels système anormaux (mount, ptrace, accès /proc/1).

Crypto mining¶

Un conteneur compromis est utilisé pour miner de la cryptomonnaie. Le symptome principal est une consommation CPU anormale.

Detection : metriques Prometheus (CPU > seuil), Falco (connexion vers des pools de mining connus).

Lateral movement¶

Depuis un pod compromis, l'attaquant pivote vers d'autres services du cluster en exploitant les tokens ServiceAccount, le réseau interne non segmente, ou les API Kubernetes.

Detection : NetworkPolicy strictes + Falco (connexions sortantes inattendues).

Approches de detection et d'enforcement¶

Policy-as-code (OPA / Rego)¶

L'Open Policy Agent (OPA) permet d'écrire des politiques de sécurité en code (langage Rego). Gatekeeper integre OPA dans Kubernetes comme admission controller.

# Interdire les conteneurs privilegies
package k8s.admission

deny[msg] {
  input.request.kind.kind == "Pod"
  container := input.request.object.spec.containers[_]
  container.securityContext.privileged == true
  msg := sprintf("Conteneur privilegie interdit : %s", [container.name])
}

Mode d'action : prevention a l'admission (le pod est rejete avant d'etre cree).

Detection comportementale (Falco / eBPF)¶

Falco utilise eBPF pour observer les appels système du kernel en temps reel. Il compare les comportements observes a des regles et génère des alertes.

# Regle Falco : detection de shell dans un conteneur
- rule: Terminal shell in container
  desc: Detect a shell spawned in a container
  condition: >
    spawned_process and container and
    proc.name in (bash, sh, zsh, dash) and
    proc.pname != entrypoint
  output: >
    Shell lance dans un conteneur
    (user=%user.name container=%container.name shell=%proc.name
     parent=%proc.pname image=%container.image.repository)
  priority: WARNING
  tags: [container, shell, mitre_execution]

Mode d'action : detection apres le fait (le comportement est observe et une alerte est générée).

Admission control vs runtime detection¶

Concepts cles a retenir¶