Een cloud-infrastructuur beveiligen die je niet hebt gebouwd

Je hebt zojuist de sleutels gekregen van een cloud-account die drie jaar lang onbeheerd is gegroeid. Niemand heeft documentatie achtergelaten. IAM heeft 40 rollen met wildcard-permissions, er zijn S3 buckets die niemand herinnert te hebben aangemaakt, en de laatste persoon die de netwerktopologie begreep, verliet het bedrijf in 2022. Dit komt veel vaker voor dan wat vacatureteksten erkennen, en de eerste maand bepaalt de toon voor alles daarna.

Maak eerst een inventaris voordat je iets aanraakt

Weersta de neiging om meteen dingen af te sluiten. Je hebt eerst een kaart nodig. Voer aws resourcegroupstaggingapi get-resources uit in elke regio, niet alleen us-east-1 — teams houden er van om testresources in ap-southeast-2 op te zetten en ze te vergeten. Combineer dat met AWS Config als het al ingeschakeld is, of zet het nu aan als dat niet het geval is. Op Azure werkt az resource list --output table via een spreadsheet prima voor een eerste ronde. Op GCP geeft Cloud Asset Inventory's gcloud asset search-all-resources je dezelfde weergave.

Vergelijk met facturering. Alles wat geld kost, hoort in je resource-inventaris; alles in de inventaris met nul recente activiteit is een kandidaat voor archivering. Discrepanties hier zijn meestal waar het enge spul zich verstopt — wezen EC2-instanties met publieke IP's, vergetene RDS-snapshots die onversleuteld liggen, load balancers die naar niets wijzen.

Audit IAM alsof het een misdaadscène is

Haal elk IAM-beleid op en zoek naar "Action": "*" gecombineerd met "Resource": "*". Deze combinatie mag niet bestaan buiten een handvol break-glass admin-rollen, en zelfs die moeten MFA-afdwinging en CloudTrail-waarschuwingen hebben. Gebruik IAM Access Analyzer om rollen te vinden die toegang verlenen aan externe accounts — dit vangt zowel opzettelijke cross-account vertrouwensrelaties als fouten van iemand die een Terraform-module tegen de verkeerde account-ID test.

Controleer toegangssleutels ouder dan 90 dagen met aws iam generate-credential-report. Overgenomen omgevingen hebben bijna altijd langdurig geldende sleutels gekoppeld aan serviceaccounts, soms hardcoded in een Lambda-omgevingsvariabele of een Jenkins-job. Roteer ze, maar in fasen — een sleutel doden waar een nachtelijke batch-job van afhangt om 2 uur 's nachts is hoe je in je eerste week in geroepen wordt.

Vind de publieke blootstelling voordat een aanvaller dat doet

Voer een netwerkbereikbaarheidscontrole uit in je VPC's. Security groups met 0.0.0.0/0 op iets anders dan 80/443 hebben rechtvaarding nodig, geen aanname. Tools als ScoutSuite of Prowler zullen een account in minuten doorwerken en een rapport uitspuwen gerangschikt naar ernst — begin daar in plaats van je eigen checklist van nul af aan op te bouwen.

S3 buckets verdienen speciale aandacht omdat ze het klassieke landmijn van overgenomen omgevingen zijn. Controleer zowel bucket-beleid als account-level Block Public Access-instellingen; iemand kan jaren geleden de account-standaard hebben uitgeschakeld voor een eenmalige statische site en het nooit meer hebben ingeschakeld. aws s3api list-buckets gecombineerd met een lus die get-bucket-acl en get-bucket-policy-status op elk controleert, geeft je in minder dan tien minuten een helder beeld voor de meeste accounts.

Zet logging in plaats voordat je vertrouwen stelt

Als CloudTrail, VPC Flow Logs of GuardDuty niet al overal draaien, zet ze nu aan, voordat je andere wijzigingen aanbrengt. Je wilt een record van wat hier vandaan gebeurt, en je wilt het voordat je dingen begint te verwijderen, want verwijdering is precies wanneer fouten worden gemaakt en aan de nieuwkomer worden toegeschreven. Stuur logs naar een afzonderlijk account of abonnement als dat mogelijk is, zodat een gecompromitteerde workload ook zijn eigen bewijs niet kan wissen.

Zet GuardDuty of Azure Defender for Cloud in met waarschuwingen gerouteerd naar een plek die een mens daadwerkelijk checkt — niet een Slack-kanaal met 400 ongelezen berichten. De waarde van detectietools is bijna nul als de waarschuwingen in een gat landen.

Repareer eerst de hardst krijsende problemen, documenteer alles

Je zult een overgenomen omgeving niet in een sprint repareren. Triage op explosieradius: blootstelling van openbare gegevens eerst, dan overberechtigde identiteiten, dan netwerksegmentatie, dan al het rest. Noteer wat je vindt en wat je veranderd hebt, zelfs in een gewoon Google Doc, want de volgende persoon die dit van jou overneemt verdient iets beters dan wat jij kreeg.

Verwacht tegenstand wanneer je een security group aanstelt en de integratietest van een dev begint te mislukken. Dat is normaal — het betekent dat de audit werkt. Praat met het team dat eigenaar is van de workload voordat je iets in productie verandert, en hou een terugdraaiplan klaar voor de eerste twee weken.

Voor meer informatie over de tools en redenering achter cloud audits, zie je Korra Studio's segmenten over IAM-versteviging en cloud-detectie-engineering — beide passen goed bij de workflow hierboven.