Pour un RSSI, la visibilité est le socle de la défense. Pourtant, avec l’agilité du DevOps et l’approche cloud-first, un phénomène insidieux élargit la surface d’attaque : le shadow cloud.
Contrairement au shadow IT classique (SaaS non autorisé souscrit par un utilisateur), le shadow cloud concerne des ressources d’infrastructure (EC2, S3, RDS…) créées dans les comptes de l’entreprise mais hors gouvernance, monitoring ou politique de sécurité homogène.
Voici comment détecter, prioriser et réduire ces actifs fantômes.
1. Pourquoi le shadow cloud inquiète les RSSI
L’élasticité du cloud favorise l’innovation, mais complique l’inventaire permanent. Le shadow cloud naît souvent de situations bénignes au départ :
- POC oublié : instance lancée pour un test, jamais éteinte, OS non patché depuis des mois.
- Environnement orphelin : ressources créées par un prestataire ou un salarié parti, sans passation.
- Correctif d’urgence : changement manuel hors pipeline IaC pour « débloquer » la prod, créant une dérive par rapport au code.
Une lecture du risque
On peut résumer l’enjeu ainsi : risque élevé quand l’invisibilité se combine à des vulnérabilités connues et à des coûts qui continuent de couler. Ces ressources échappent parfois aux outils habituels (EDR, SIEM) et deviennent des points d’appui pour un mouvement latéral.
2. Détection : trois leviers
A. Facturation et journaux (l’angle financier)
Souvent, suivre l’argent révèle ce que l’inventaire ne montre pas.
- Cost and Usage Reports (CUR) : pics sur des régions ou des comptes où vous ne pensez pas opérer.
- CloudTrail : appels
RunInstances,CreateBucketpar des identités qui ne passent pas par votre Terraform / CloudFormation habituel.
B. Surface d’attaque externe (EASM)
Adopter la vue attaquant : outils ou prestations d’EASM pour découvrir buckets exposés, API ou services d’administration ouverts sur des plages IP vous appartenant mais non référencés.
C. Tagging et « zombie assets »
Une ressource sans tags obligatoires est souvent hors processus.
- audits de tags (
Owner,Project,Environment, etc.) ; - sur AWS, Tag Editor en premier niveau ; scripts ou AWS Config pour aller plus loin.
3. Matrice de criticité (exemple)
| Type de ressource | Risque principal | Impact business typique |
|---|---|---|
| Bucket S3 orphelin | fuite de données | majeur (RGPD, NIS2) |
| EC2 non patchée | ransomware, pivot | critique (disponibilité) |
| Snapshots oubliés | fuite d’IP / données | élevé |
| Clés IAM inactives | persistance attaquant | critique |
4. Plan d’action durable
- Tagging exigeant : politiques (voire SCP) pour empêcher la création de ressources sans tags requis - en adaptant les exceptions.
- Automatisation du nettoyage : outils type Cloud Custodian (ou équivalent) pour arrêter ou signaler les ressources sans activité ni conformité après délai de grâce.
- Organizations : éviter les comptes créés en dehors du cadre central ; CloudTrail et contrôles par défaut.
- Pentests : inclure une phase de reconnaissance pour repérer ce que l’inventaire interne ne voit pas - voir nos services.
Conclusion
Le shadow cloud n’est pas une fatalité technique : c’est souvent un défaut de gouvernance. Réduire l’ombre, c’est réduire la surface d’attaque et les coûts inutiles, tout en facilitant la conformité (NIS2, etc.).
Pour un audit de visibilité ou un pentest adapté : contact.