Pour un RSSI, la visibilité est le socle de la défense. Pourtant, avec l’agilité poussée à l’extrême par le DevOps et le « Cloud-First », un phénomène insidieux ronge la surface d’attaque des entreprises : le Shadow Cloud.
Contrairement au Shadow IT classique (un employé utilisant un SaaS non autorisé), le Shadow Cloud concerne des ressources d’infrastructure réelles (instances EC2, buckets S3, bases de données RDS) créées au sein des comptes de l’entreprise, mais échappant à toute gouvernance, monitoring ou politique de sécurité.
Voici comment détecter, quantifier et neutraliser ces actifs fantômes qui représentent aujourd’hui l’une des plus grandes menaces pour votre conformité et votre résilience.
1. Pourquoi le Shadow Cloud est le cauchemar du RSSI
L’élasticité du Cloud est une force pour l’innovation, mais une faiblesse pour l’inventaire. Le Shadow Cloud naît souvent d’intentions louables :
- Le POC (Proof of Concept) oublié : Une instance lancée pour un test rapide, jamais éteinte, et dont l’OS n’est plus patché depuis 18 mois.
- L’environnement « Orphelin » : Des ressources créées par un consultant ou un employé ayant quitté l’entreprise.
- Le « Quick-fix » en production : Une modification manuelle hors pipeline CI/CD pour résoudre une urgence, créant une dérive (drift) par rapport au code.
L’équation du risque
Le risque lié au Shadow Cloud peut se résumer ainsi :
Risque = (Invisibilité × Vulnérabilité) + Coût inutile
Ces ressources sont rarement rattachées à vos outils de détection (EDR, SIEM) et deviennent des points d’entrée idéaux pour un mouvement latéral, notamment via l’exploitation de l’IMDS comme nous l’avons vu dans nos articles précédents.
2. Guide de détection : Comment débusquer l’invisible ?
Pour reprendre le contrôle, le RSSI doit adopter une approche multi-vectorielle. Voici les trois piliers de la détection :
A. L’analyse des journaux et de la facturation (L’approche financière)
La manière la plus efficace de détecter du Shadow Cloud est souvent de suivre l’argent.
- Exploration des Cost and Usage Reports (CUR) : Recherchez des pics de consommation sur des régions AWS où vous n’êtes pas censés opérer.
- Analyse CloudTrail : Identifiez les API calls
RunInstancesouCreateBucketeffectués par des utilisateurs ou des rôles qui ne passent pas par vos outils d’Infrastructure as Code (Terraform, CloudFormation).
B. Le scan de la surface d’attaque externe (EASM)
Utilisez les lunettes de l’attaquant. Des outils d’External Attack Surface Management permettent de découvrir :
- Des buckets S3 exposés publiquement qui n’apparaissent pas dans votre inventaire officiel.
- Des endpoints d’API ou des interfaces de gestion (SSH, RDP) ouverts sur des adresses IP appartenant à vos ranges mais non documentés.
C. La détection des « Zombie Assets » via le tagging
Une ressource sans tag est, par définition, une ressource hors gouvernance.
- Audit des Tags : Identifiez toutes les ressources n’ayant pas de tags obligatoires (
Project,Owner,Environment). Sur AWS, l’outil Tag Editor est un premier pas, mais des scripts personnalisés sont souvent nécessaires pour une vision globale.
3. Matrice de criticité du Shadow Cloud
| Type de Ressource | Risque Principal | Impact Business |
| Bucket S3 Orphelin | Fuite de données (Data Leak) | Majeur (RGPD / NIS2) |
| Instance EC2 non patchée | Point d’entrée / Ransomware | Critique (Disponibilité) |
| Snapshots de DB oubliés | Vol de propriété intellectuelle | Élevé |
| Clés IAM inactives | Persistance d’un attaquant | Critique |
4. Le plan d’action pour une gouvernance durable
Détecter est une chose, pérenniser la visibilité en est une autre. Voici la stratégie de remédiation que nous préconisons :
- Imposer le « Tagging or Die » : Configurez des Service Control Policies (SCP) sur AWS pour interdire la création de toute ressource qui ne possède pas les tags requis.
- Automatiser la mise au rebut : Implémentez des outils (comme Cloud Custodian) qui terminent automatiquement les instances sans activité ou sans tags après un délai de prévenance de 48h.
- Centraliser via AWS Organizations : Assurez-vous qu’aucun compte « Shadow » ne peut être créé en dehors de l’organisation centrale, garantissant que CloudTrail est activé partout par défaut.
- Réaliser des Pentests périodiques : Un test d’intrusion ne doit pas se limiter à vos applications connues. Demandez explicitement à votre prestataire de réaliser une phase de reconnaissance pour identifier ce que vous ne voyez pas.
Conclusion
Le Shadow Cloud n’est pas une fatalité technique, c’est un défaut de gouvernance. Pour le RSSI moderne, la sécurité ne s’arrête plus au périmètre du réseau, elle s’étend à chaque ligne de code et chaque actif provisionné en un clic.
Réduire votre Shadow Cloud, c’est réduire mécaniquement votre surface d’attaque et vos coûts opérationnels, tout en renforçant votre conformité aux réglementations comme NIS2.
Voulez-vous assainir votre infrastructure Cloud ? Je peux vous accompagner dans la mise en place d’un audit de visibilité complet.