Je hebt een Cloud Chaos Geërfd. Waar Begin Je?

Je hebt zojuist een cloud-account (of tien) overgenomen die iemand anders over drie jaar heeft opgebouwd zonder documentatie, met een wisselende groep aannemers, en een Slack-kanaal genaamd #aws-help dat sinds 2022 niet actief is geweest. Dit is een van de meest voorkomende situaties in cloud security werk, en het is oncomfortabel omdat je verantwoordelijk bent voor iets wat je nog niet kunt uitleggen.

Hier is hoe je van nul zichtbaarheid naar een verdedigbare positie komt zonder je helemaal in het moeras vast te rijden.

Stop met gokken en maak eerst een inventarisatie

Je kunt niet beveiligen wat je niet kunt zien. Voordat je een enkel IAM-beleid aanraakt, voer je een inventarisatieronde uit:

• AWS: aws organizations list-accounts om de volledige accountstructuur te zien, dan Steampipe of AWS Config aggregators om resources over accounts heen in één querybare weergave te trekken.
• Azure: Resource Graph queries (az graph query) over abonnementen, omdat Azure's tenant/subscription model expansie gemakkelijk verbergt.
• GCP: gcloud asset search-all-resources op organisatieniveau.

Vergelijk dit met je factureringsgegevens. Facturering liegt niet over wat draait, zelfs niet wanneer tags en documentatie dat doen. Als je uitgaven ziet voor een service die niemand in de onboarding heeft genoemd, is dat je eerste bevinding.

Ontdek wie wat kan doen voordat je ontdekt wat kapot is

Misconfiguraties krijgen de koppelingen, maar identiteit is waar de echte blootstelling meestal in een overgenomen omgeving leeft. Trek elke IAM-gebruiker, rol en service account en stel drie vragen: heeft dit nog nodig te bestaan, heeft het toegang die het niet gebruikt, en is het menselijk of machine.

Voer AWS IAM Access Analyzer uit of tooling in de stijl van iam-lint om ongebruikte machtigingen in de afgelopen 90 dagen aan te vlaggen. In de praktijk hebben overgenomen accounts bijna altijd minstens één IAM-gebruiker met langdurige toegangssleutels die zouden moeten