Vous avez hérité d'un chaos cloud. Par où commencer ?

Un plan pragmatique des 90 premiers jours pour sécuriser un environnement AWS, Azure ou GCP que vous n'avez pas conçu et que vous ne comprenez pas encore complètement.

Vous venez de reprendre un compte cloud (ou dix) qu'une autre personne a construit au fil de trois ans sans documentation, avec une équipe de contractants qui changeait sans cesse, et un canal Slack appelé #aws-help qui n'a pas été actif depuis 2022. C'est l'une des situations les plus courantes dans le travail de sécurité cloud, et elle met mal à l'aise parce que vous êtes responsable de quelque chose que vous ne pouvez pas encore expliquer.

Voici comment passer d'une visibilité nulle à une position défendable sans vous noyer dans le processus.

Arrêtez de deviner et obtenez d'abord un inventaire

Vous ne pouvez pas sécuriser ce que vous ne voyez pas. Avant de toucher à la moindre politique IAM, lancez un passage d'inventaire :

AWS : aws organizations list-accounts pour voir la structure complète des comptes, puis Steampipe ou les agrégateurs AWS Config pour récupérer les ressources dans tous les comptes en une vue interrogeable.
Azure : Les requêtes Resource Graph (az graph query) sur les abonnements, car le modèle tenant/abonnement d'Azure masque facilement la prolifération.
GCP : gcloud asset search-all-resources au niveau de l'organisation.

Croisez cela avec les données de facturation. La facturation ne ment pas sur ce qui s'exécute, même quand les étiquettes et la documentation le font. Si vous voyez des dépenses sur un service que personne n'a mentionné à l'intégration, c'est votre première découverte.

Trouvez qui peut faire quoi avant de trouver ce qui est cassé

Les erreurs de configuration font les gros titres, mais l'identité est généralement l'endroit où réside la vraie exposition dans un environnement hérité. Extrayez chaque utilisateur IAM, rôle et compte de service et posez trois questions : cela a-t-il toujours besoin d'exister, dispose-t-il d'accès qu'il n'utilise pas, et s'agit-il d'humain ou de machine.

Exécutez AWS IAM Access Analyzer ou un outil de style iam-lint pour signaler les permissions inutilisées au cours des 90 derniers jours. En pratique, les comptes hérités ont presque toujours au moins un utilisateur IAM ayant des clés d'accès longue durée qui auraient supposément

Rédigé avec l'aide de l'IA, relu et publié par Michal Pilch (CISSP), Korra Studio.