Zabezpieczanie infrastruktury chmurowej, którą nie zbudowałeś

Właśnie dostałeś dostęp do konta chmurowego, które przez trzy lata rosło bez kontroli. Nikt nie zostawił dokumentacji. IAM ma 40 ról z uprawnieniami wildcard, są buckety S3, które nikt nie pamięta, że stworzył, a ostatnia osoba, która rozumiała topologię sieci, opuściła firmę w 2022 roku. To jest bardziej powszechne niż większość ogłoszeń o pracę przyznaje, a pierwszy miesiąc wyznacza ton wszystkemu, co następuje.

Zrób inwentaryzację zanim cokolwiek dotkniesz

Oprzecz sobie pokusie natychmiastowego blokowania rzeczy. Najpierw potrzebujesz mapy. Uruchom aws resourcegroupstaggingapi get-resources we wszystkich regionach, nie tylko us-east-1 — zespoły uwielbiają uruchamiać testowe zasoby w ap-southeast-2 i o nich zapominać. Połącz to z AWS Config, jeśli jest już włączony, lub włącz go teraz, jeśli nie. Na Azure az resource list --output table przekierowany do arkusza kalkulacyjnego działa dobrze jako pierwszy przegląd. Na GCP, Cloud Asset Inventory z gcloud asset search-all-resources daje ci ten sam widok.

Zweryfikuj dane względem rozliczeń. Wszystko, co kosztuje pieniądze, powinno pojawić się w twoim spisie zasobów; cokolwiek w spisie bez niedawnej aktywności to kandydat do archiwizacji. Rozbieżności tutaj to zwykle miejsce, gdzie kryje się niepokojące rzeczy — opuszczone instancje EC2 z publicznymi IP, zapomniane snapshoty RDS bez szyfrowania, moduły równoważenia obciążenia wskazujące na nic.

Audytuj IAM jak scenę zbrodni

Zdobądź wszystkie zasady IAM i szukaj "Action": "*" w połączeniu z "Resource": "*". Ta kombinacja nie powinna istnieć poza kilkoma rolami admin break-glass, a nawet te powinny mieć wymuszone MFA i alerty CloudTrail. Użyj IAM Access Analyzer, aby znaleźć role dające dostęp do zewnętrznych kont — to wyłapuje zarówno zamierzone relacje zaufania między kontami, jak i błędy kogoś testującego moduł Terraform na złym ID konta.

Sprawdź klucze dostępu starsze niż 90 dni z aws iam generate-credential-report. Odziedziczone środowiska prawie zawsze mają długowieczne klucze przypisane do kont usług, czasem zapisane na stałe w zmiennej środowiska Lambda lub zadaniu Jenkins. Obróć je, ale etapowo — zabicie klucza, od którego zależy nocne zadanie wsadowe o 2 w nocy, to jak się zostaje strona podczas pierwszego tygodnia.

Znajdź publiczną ekspozycję zanim znajdzie ją atakujący

Uruchom sprawdzenie osiągalności sieci w twoich VPC. Grupy bezpieczeństwa z 0.0.0.0/0 na czymkolwiek innym niż 80/443 potrzebują uzasadnienia, nie założenia. Narzędzia takie jak ScoutSuite lub Prowler przejdą przez konto w minuty i wypluą raport uszeregowany według ważności — zacznij tam zamiast budować własną listę kontrolną od zera.

Buckety S3 zasługują na szczególną uwagę, ponieważ są klasyczną miną odziedziczonego środowiska. Sprawdź zarówno polityki bucketu, jak i ustawienia Block Public Access na poziomie konta; ktoś mógł wyłączyć domyślne ustawienia konta lata temu dla jednorazowej statycznej witryny i nigdy ich nie włączył. aws s3api list-buckets w połączeniu z pętlą sprawdzającą get-bucket-acl i get-bucket-policy-status na każdym daje ci czysty obraz w mniej niż dziesięć minut dla większości kont.

Ustanów logowanie zanim ustanowisz zaufanie

Jeśli CloudTrail, VPC Flow Logs lub GuardDuty nie działają już wszędzie, włącz je teraz, zanim dokonasz jakichkolwiek innych zmian. Chcesz rekord tego, co się dzieje od tego momentu, i chcesz go zanim zaczniesz usuwać rzeczy, bo usuwanie to dokładnie wtedy, kiedy zdarzają się błędy i obwinia się nowego człowieka. Wyślij logi na osobne konto lub subskrypcję, jeśli to możliwe, aby skompromitowane obciążenie pracą również nie mogło wymazać dowodów.

Skonfiguruj GuardDuty lub Azure Defender for Cloud z alertami przekierowanymi gdzieś, gdzie człowiek faktycznie sprawdza — nie kanał Slack z 400 nieprzeczytanymi wiadomościami. Wartość narzędzi detekcji jest bliska zeru, jeśli alerty lądują w pustce.

Napraw najpilniejsze problemy najpierw, udokumentuj wszystko

Nie naprawisz odziedziczonego środowiska w sprint. Triażuj według promienia rażenia: publiczna ekspozycja danych najpierw, potem nadmiernie uprzywilejowane tożsamości, potem segmentacja sieci, potem wszystko inne. Zanotuj, co znalazłeś i co zmieniłeś, nawet w zwykłym Google Doc, bo następna osoba, która to odziedziczy po tobie, powinna mieć lepiej niż to, co dostałeś.

Spodziewaj się sprzeciwu, gdy zaciśniesz grupę bezpieczeństwa i test integracyjny dewelopera zacznie się nie powodzić. To jest normalne — oznacza to, że audyt działa. Porozmawiaj z zespołem, który zarządza obciążeniem pracą zanim cokolwiek zmienisz w produkcji, i miej gotowy plan wycofania przez pierwsze dwa tygodnie.

Więcej o narzędziach i logice stojącej za audytami chmury, sprawdź segmenty Korra Studio dotyczące wzmacniania IAM i cloud detection engineering — oba dobrze łączą się z powyższym przepływem pracy.