Odziedziczył(a)eś/Odziedziczył(a)ś Chaos w Chmurze. Gdzie Zacząć?

Właśnie przejąłeś/przejęłaś konto w chmurze (lub dziesięć), które ktoś budował przez trzy lata bez dokumentacji, ze zmienną obsadą wykonawców i kanałem Slack o nazwie #aws-help, który nie był aktywny od 2022 roku. To jedna z najczęstszych sytuacji w pracy bezpieczeństwa chmury, i jest niewygodna, bo jesteś odpowiedzialny za coś, czego jeszcze nie potrafisz wyjaśnić.

Oto jak przejść od zera widoczności do pozycji, którą można bronić, bez angażowania wszystkich dostępnych zasobów.

Przestań zgadywać i najpierw zdobądź inwentarz

Nie możesz zabezpieczyć tego, czego nie widzisz. Zanim dotkniesz jakąkolwiek politykę IAM, przeprowadź przejście inventaryzacyjne:

• AWS: aws organizations list-accounts aby zobaczyć pełną strukturę kont, następnie Steampipe lub AWS Config aggregators aby zebrać zasoby ze wszystkich kont w jeden widok, który można przeszukiwać.
• Azure: Zapytania Resource Graph (az graph query) we wszystkich subskrypcjach, ponieważ model tenant/subskrypcja Azure'a łatwo ukrywa rozprzestrzenienie.
• GCP: gcloud asset search-all-resources na poziomie organizacji.

Skrzyżuj to z danymi rozliczeń. Rozliczenia nie kłamią na temat tego, co uruchomione, nawet gdy tagi i dokumentacja to robią. Jeśli widzisz wydatki na usługę, którą nikt nie wspomniał podczas onboardingu, to twoje pierwsze ustalenie.

Znajdź kto może robić co, zanim znajdziesz co jest zepsute

Złe konfiguracje zdobywają nagłówki, ale tożsamość to miejsce, gdzie rzeczywista ekspozycja zwykle mieszka w odziedziczonym środowisku. Wyciągnij każdego użytkownika IAM, rolę i konto usługi i zadaj trzy pytania: czy to wciąż musi istnieć, czy ma dostęp, którego nie używa, i czy to człowiek czy maszyna.

Uruchom AWS IAM Access Analyzer lub narzędzia w stylu iam-lint aby oznaczyć nieużywane uprawnienia w ciągu ostatnich 90 dni. W praktyce, odziedziczone konta niemal zawsze mają przynajmniej jednego użytkownika IAM z długotrwałymi kluczami dostępu, które miały być