L'Art de Sécuriser une Infrastructure Cloud
Sécuriser le Cloud : Ma Méthode en 6 Piliers
La sécurité cloud n'est pas une checklist qu'on coche une fois. C'est un processus continu que j'ai affiné au fil de centaines de projets. Voici ma méthode, illustrée par des cas concrets.
1. Gestion des Identités et des Accès (IAM)
C'est le fondement de toute sécurité cloud. Le principe du moindre privilège est simple à énoncer, difficile à appliquer.
Sur un projet d'architecture AWS multi-compte, j'ai mis en place une structure IAM complète : un compte Identity avec AWS SSO, des rôles cross-account pour chaque environnement, et des SCPs (Service Control Policies) au niveau de l'Organization pour interdire les actions dangereuses (comme désactiver CloudTrail ou ouvrir des security groups).
Chez un client dans la Défense sur OVH, le RBAC Kubernetes était configuré avec une granularité par namespace : chaque équipe avait un rôle limité à son périmètre, et les opérations sensibles (suppression de PV, modification des NetworkPolicies) étaient réservées à un groupe restreint d'administrateurs.
2. Protection des Données
Le chiffrement est le minimum : chiffrement au repos (EBS encrypted, RDS encryption, S3 SSE) et en transit (TLS partout). Mais la vraie protection des données va au-delà du chiffrement.
Sur un projet HDS (Hébergement de Données de Santé), nous avons mis en place : chiffrement avec des clés gérées par le client (CMK), backup automatique avec rétention de 90 jours, test de restauration mensuel, et un DRP (Disaster Recovery Plan) testé trimestriellement.
3. Sécurisation Réseau
Les NetworkPolicies Kubernetes sont mon premier réflexe sur chaque cluster. Par défaut, tout le trafic inter-pods est autorisé dans Kubernetes. C'est inacceptable en production.
Mon approche : une politique deny-all par défaut, puis des règles explicites pour autoriser uniquement les flux nécessaires. Chez un client dans la Défense, chaque flux réseau entre services était documenté et autorisé individuellement. Le temps de mise en place est plus long, mais la surface d'attaque est réduite de façon drastique.
Au niveau cloud, les VPC avec des subnets privés, des NAT gateways pour l'accès sortant, et des security groups restrictifs sont le standard minimum.
4. Sécurisation des Applications
Les pods Kubernetes doivent tourner en non-root, avec des profils seccomp activés, et des security contexts restrictifs (pas de privilege escalation, filesystem read-only quand possible). Ce n'est pas de la théorie : sur chaque mission, je vérifie et corrige ces paramètres.
Le scan des images Docker dans la CI/CD est également systématique : Trivy ou Grype intégré au pipeline, avec un seuil de sévérité qui bloque le build si des CVE critiques sont détectées.
5. Monitoring et Détection
La sécurité sans visibilité est aveugle. Sur AWS, j'active systématiquement GuardDuty (détection de menaces), CloudTrail (audit des appels API), et Config (conformité continue). Sur Kubernetes, les logs d'audit du API server sont centralisés dans Loki et des alertes Grafana détectent les comportements anormaux.
Chez un client, une alerte sur des tentatives de connexion SSH depuis des IPs inhabituelles a permis de détecter un scan actif sur notre infrastructure. L'attaquant n'avait rien compromis grâce aux security groups, mais sans monitoring, nous n'aurions même pas su qu'il essayait.
6. Conformité et Audit
ISO 27001, HDS, SOC 2, RGPD... Chaque norme a ses exigences spécifiques, mais elles partagent des fondamentaux communs : documentation, traçabilité, contrôle d'accès, chiffrement, gestion des incidents.
Chez un client en conformité SecNumCloud avec Outscale pour la DGE, chaque composant de l'infrastructure était documenté, chaque accès tracé, et chaque changement passait par un processus de validation. C'est contraignant, mais c'est le prix de la confiance.
La sécurité cloud est un art qui s'apprend par la pratique. Et après plus de 100 projets, je continue à apprendre à chaque mission.