Sécurité Infra Cloud : Le Péril des Développeurs Non Qualifiés
Quand Les Développeurs Gèrent l'Infra : Les Erreurs Que Je Vois en Audit
Je ne dis pas ça pour critiquer les développeurs -- j'en ai le plus grand respect. Mais après avoir audité des dizaines d'infrastructures cloud, je constate que les erreurs les plus graves sont systématiquement commises quand des développeurs sans formation infrastructure sont mis en charge du cloud. Voici ce que je vois le plus souvent, et pourquoi c'est dangereux.
Les Access Keys en Dur dans le Code
C'est l'erreur numéro un. Lors d'un audit AWS chez un éditeur de logiciels, j'ai trouvé des access keys AWS committées dans un dépôt Git privé. Ces clés avaient des droits administrateur sur le compte AWS. Un seul leak de ce dépôt et c'est tout le compte AWS qui est compromis : suppression de données, minage de crypto, exfiltration d'informations clients.
La solution : IAM Roles, pas des access keys. Et pour les cas où des credentials sont nécessaires, un gestionnaire de secrets comme Vault ou AWS Secrets Manager.
Les Security Groups en Mode "Allow All"
J'ai vu des security groups AWS avec des règles 0.0.0.0/0 sur tous les ports. La base de données PostgreSQL accessible depuis Internet. Le serveur Redis ouvert au monde. Quand j'ai demandé pourquoi, la réponse était : "On n'arrivait pas à faire communiquer les services, alors on a tout ouvert pour débloquer."
C'est l'approche inverse de la sécurité. Le bon réflexe : tout fermer par défaut, puis ouvrir chirurgicalement ce qui est nécessaire.
L'Absence de Séparation des Environnements
Un seul compte AWS pour le dev, le staging et la production. Les mêmes credentials partout. Un terraform destroy maladroit en dev peut impacter la production. Chez un client, un développeur a accidentellement supprimé une table DynamoDB de production en pensant être sur l'environnement de test.
Mon approche standard : AWS Organization avec des comptes séparés par environnement, SCPs restrictives, et des IAM roles cross-account pour les cas légitimes.
Les Images Docker Non Scannées
Des images Docker basées sur ubuntu:latest avec des centaines de CVE connues. Pas de scan de sécurité dans le pipeline CI/CD. Des binaires installés avec curl | bash dans le Dockerfile. Autant de portes d'entrée pour un attaquant.
L'Absence de Monitoring et de Logging
Pas de logs centralisés. Pas d'alertes. Quand un incident se produit, il est détecté par les utilisateurs, pas par l'équipe technique. Chez un de mes clients, une fuite de mémoire en production est restée non détectée pendant 3 semaines parce qu'il n'y avait aucun monitoring.
Le Coût de l'Ignorance
Les erreurs de sécurité ne sont pas juste des risques théoriques. J'ai vu un client dont le compte AWS a été compromis via des access keys leakées : 15 000 euros de facturation en 48h pour du minage de crypto. Un autre dont la base de données a été chiffrée par un ransomware à cause d'un port MongoDB exposé sur Internet.
La Solution : Séparer les Responsabilités
La solution n'est pas de former tous les développeurs à la sécurité cloud (même si une sensibilisation de base est souhaitable). C'est de confier l'infrastructure à des professionnels qui ont l'expérience et les compétences. C'est exactement le rôle de WizOps : sécuriser votre infrastructure pour que vos développeurs puissent se concentrer sur ce qu'ils font de mieux -- écrire du code.