Sécuriser une infrastructure cloud que vous n'avez pas construite

Vous venez de recevoir les clés d'un compte cloud qui s'est développé sans surveillance pendant trois ans. Personne n'a laissé de documentation. IAM compte 40 rôles avec des permissions utilisant des wildcards, il y a des buckets S3 que personne ne se souvient d'avoir créés, et la dernière personne qui comprenait la topologie réseau a quitté l'entreprise en 2022. C'est plus courant que la plupart des offres d'emploi ne l'admettent, et le premier mois donne le ton pour tout ce qui suit.

Faites un inventaire avant de toucher à quoi que ce soit

Résistez à l'envie de commencer à verrouiller les choses immédiatement. Vous avez d'abord besoin d'une carte. Exécutez aws resourcegroupstaggingapi get-resources dans chaque région, pas seulement us-east-1 — les équipes adorent créer des ressources de test dans ap-southeast-2 et les oublier. Combinez cela avec AWS Config s'il est déjà activé, ou activez-le maintenant s'il ne l'est pas. Sur Azure, az resource list --output table redirigé vers une feuille de calcul fonctionne bien pour une première passe. Sur GCP, Cloud Asset Inventory avec gcloud asset search-all-resources vous donne la même vue.

Croisez les informations avec la facturation. Tout ce qui coûte de l'argent doit apparaître dans votre inventaire de ressources ; tout ce qui est dans l'inventaire sans activité récente est un candidat pour l'archivage. Les divergences ici sont généralement l'endroit où se cachent les choses inquiétantes — des instances EC2 orphelines avec des IPs publiques, des snapshots RDS oubliés non chiffrés, des équilibreurs de charge pointant vers rien.

Auditez IAM comme si c'était une scène de crime

Extraites toutes les politiques IAM et cherchez "Action": "*" combiné avec "Resource": "*". Cette combinaison ne devrait pas exister en dehors d'une poignée de rôles administrateur de dernier recours, et même ceux-ci devraient avoir l'application de MFA et les alertes CloudTrail attachées. Utilisez IAM Access Analyzer pour trouver les rôles qui accordent l'accès à des comptes externes — cela capture à la fois les relations de confiance inter-comptes intentionnelles et les erreurs de quelqu'un testant un module Terraform contre le mauvais ID de compte.

Vérifiez les clés d'accès plus anciennes que 90 jours avec aws iam generate-credential-report. Les environnements hérités presque toujours des clés longue durée attachées aux comptes de service, parfois codées en dur dans une variable d'environnement Lambda ou un travail Jenkins. Faites-les tourner, mais en les préparant — tuer une clé sur laquelle un travail batch nocturne dépend à 2 heures du matin, c'est comme ça qu'on se fait appeler pendant sa première semaine.

Trouvez l'exposition publique avant un attaquant

Exécutez une vérification de la disponibilité du réseau sur vos VPC. Les groupes de sécurité avec 0.0.0.0/0 sur autre chose que 80/443 ont besoin d'une justification, pas d'une supposition. Des outils comme ScoutSuite ou Prowler vont traiter un compte en minutes et cracher un rapport classé par sévérité — commencez par là au lieu de construire votre propre checklist à partir de zéro.

Les buckets S3 méritent une attention particulière car ce sont les mines classiques des environnements hérités. Vérifiez à la fois les politiques de bucket et les paramètres de blocage d'accès public au niveau du compte ; quelqu'un a peut-être désactivé le paramètre par défaut du compte il y a des années pour un site statique unique et ne l'a jamais réactivé. aws s3api list-buckets combiné avec une boucle vérifiant get-bucket-acl et get-bucket-policy-status sur chacun vous donne une vue claire en moins de dix minutes pour la plupart des comptes.

Établissez la journalisation avant d'établir la confiance

Si CloudTrail, VPC Flow Logs ou GuardDuty ne fonctionnent pas déjà partout, activez-les maintenant, avant d'effectuer tout autre changement. Vous voulez un enregistrement de ce qui se passe à partir de ce moment, et vous le voulez avant de commencer à supprimer les choses, car la suppression est exactement le moment où les erreurs se font et sont blâmées sur la nouvelle personne. Envoyez les journaux vers un compte ou une souscription séparé si c'est du tout possible, de sorte qu'une charge de travail compromise ne puisse pas aussi effacer ses preuves.

Configurez GuardDuty ou Azure Defender for Cloud avec des alertes acheminées quelque part qu'un humain vérifie réellement — pas un canal Slack avec 400 messages non lus. La valeur des outils de détection est proche de zéro si les alertes atterrissent dans un vide.

Corrigez les problèmes les plus évidents en premier, documentez tout

Vous ne corrigerez pas un environnement hérité en un sprint. Triez par rayon de souffle : exposition de données publiques en premier, puis identités surprivilégiées, puis segmentation réseau, puis tout le reste. Notez ce que vous avez trouvé et ce que vous avez changé, même dans un Google Doc simple, car la personne suivante qui héritera ceci de vous mérite mieux que ce que vous avez reçu.

Attendez-vous à une résistance quand vous resserrez un groupe de sécurité et que le test d'intégration d'un dev commence à échouer. C'est normal — cela signifie que l'audit fonctionne. Parlez à l'équipe qui possède la charge de travail avant de changer quoi que ce soit en production, et gardez un plan de restauration prêt pour les deux premières semaines.

Pour plus d'informations sur les outils et le raisonnement derrière les audits cloud, consultez les segments de Korra Studio sur le renforcement d'IAM et l'ingénierie de détection cloud — les deux se marient bien avec le workflow ci-dessus.