Asigurarea unei proprietăți cloud pe care nu ai construit-o

Tocmai ți s-au dat cheile unei conturi cloud care crește fără supraveghere de trei ani. Nimeni nu a lăsat documentație. IAM are 40 de roluri cu permisiuni wildcard, există bucketuri S3 pe care nimeni nu-și amintește că le-a creat, și ultima persoană care înțelegea topologia rețelei a plecat din companie în 2022. Asta e mai frecvent decât admit cele mai multe anunțuri de angajare, și prima lună stabilește tonul pentru totul după aceea.

Fă o inventariere înainte să atingi ceva

Rezistă tentației de a începe imediat securizarea. Ai nevoie de o hartă mai întâi. Rulează aws resourcegroupstaggingapi get-resources peste fiecare regiune, nu doar us-east-1 — echipele iubesc să lanseze resurse de test în ap-southeast-2 și să le uite. Combină asta cu AWS Config dacă e deja activat, sau activează-l acum dacă nu. Pe Azure, az resource list --output table redirecționat într-o foaie de calcul merge bine pentru o primă trecere. Pe GCP, Cloud Asset Inventory's gcloud asset search-all-resources te dă aceeași vedere.

Compară cu facturile. Orice care costă bani ar trebui să apară în inventarul tău de resurse; orice din inventar cu zero activitate recentă e candidat pentru arhivare. Discrepanțele aici sunt în mod obișnuit locul unde se ascunde treaba înfricoșătoare — instanțe EC2 orfane cu IP-uri publice, snapshot-uri RDS uitate neencriptate, load balancer-e care indică spre nimic.

Auditează IAM ca și cum ar fi o scenă de crim

Extragi fiecare politică IAM și caută "Action": "*" combinat cu "Resource": "*". Combinația asta nu ar trebui să existe în afara unui mâner de roluri admin de ultimă soluție, și chiar și acelea ar trebui să aibă MFA enforcement și CloudTrail alerting ataşate. Folosește IAM Access Analyzer pentru a găsi roluri care acordă acces la conturi externe — asta detectează atât relații de trust cross-account intenționate cât și greșeli din testarea unui modul Terraform pe ID-ul de cont greșit.

Verifică access key-uri mai vechi de 90 de zile cu aws iam generate-credential-report. Proprietățile moștenite au aproape întotdeauna key-uri de lungă durată ataşate de conturi de serviciu, uneori hardcodate într-o variabilă de mediu Lambda sau o slujbă Jenkins. Rotește-le, dar pe etape — omorârea unui key pe care o slujbă batch nocturnă depinde de el la 2 AM e cum ajungi să fii apelat în prima ta săptămână.

Găsește expunerea publică înainte ca un atacator să o facă

Rulează o verificare de accesibilitate rețea peste VPC-urile tale. Grupuri de securitate cu 0.0.0.0/0 pe orice altceva decât 80/443 au nevoie de justificare, nu presupunere. Instrumente precum ScoutSuite sau Prowler vor trece printr-un cont în minute și vor scuipa un raport ordonat după severitate — începe cu asta în loc să-ți construiești propria listă de verificare de la zero.

Bucketurile S3 merită atenție specială pentru că sunt mina de mână a proprietăților moștenite clasice. Verifică atât politicile bucket cât și setările Block Public Access la nivel de cont; cineva poate fi dezactivase implicit-ul de cont acum ani pentru un site static unic și nu l-a reactivat niciodată. aws s3api list-buckets combinat cu o buclă care verifică get-bucket-acl și get-bucket-policy-status pe fiecare unu-i dă o imagine clară în sub zece minute pentru cele mai multe conturi.

Stabilește logging înainte să stabilești încredere

Dacă CloudTrail, VPC Flow Logs, sau GuardDuty nu rulează deja peste tot, activează-le acum, înainte de a face orice alte schimbări. Vrei un înregistrare a ceea ce se întâmplă de acum înainte, și vrei-o înainte să începi să ștergi lucruri, pentru că ștergerea e exact când se fac greșeli și se blamează pe persoana nouă. Trimite logu-ri către un cont sau abonament separat dacă e posibil, așa că o sarcină compromisă nu poate șterge și propria-i dovadă.

Configurează GuardDuty sau Azure Defender for Cloud cu alerting direcționat undeva pe care un om cu adevărat verifică — nu un canal Slack cu 400 de mesaje necitite. Valoarea instrumentelor de detectare e aproape zero dacă alertele cad într-o prăpastie.

Repară problemele cel mai strigătoare mai întâi, documentează totul

Nu vei repara o proprietate moștenită într-un sprint. Triază după rază de explozie: expunere de date publice mai întâi, apoi identități supraautorisate, apoi segmentarea rețelei, apoi totul restul. Notează ce găsești și ce schimbi, chiar și într-un Google Doc simplu, pentru că următoarea persoană care moștenește asta de la tine merită mai bine decât ce ai primit tu.

Așteptă-te la rezistență când strângi un grup de securitate și testul de integrare al unui dev începe să eșueze. Asta e normal — înseamnă că auditul funcționează. Vorbește cu echipa care deține sarcina înainte să schimbi ceva în producție, și ține gata un plan de rollback pentru primele două săptămâni.

Pentru mai mult pe instrumentele și raționamentul din spatele auditurilor de cloud, verifică segmentele Korra Studio pe IAM hardening și cloud detection engineering — ambele se potrivesc bine cu fluxul de lucru de mai sus.