Ocena bezpieczeństwa środowisk AWS, Azure, Google Cloud i Kubernetes: tożsamości, ekspozycja sieciowa, magazyny danych i ścieżki od pierwszego przyczółka do pełnej kontroli.
W chmurze granicę bezpieczeństwa wyznacza dokument z polityką uprawnień. Rola, która może przekazać inną rolę, bucket czytelny dla każdego uwierzytelnionego użytkownika, usługa metadanych osiągalna z aplikacji webowej: każde z nich osobno wygląda niegroźnie, a razem tworzą ścieżkę z internetu do danych.
Przeglądamy konfigurację z dostępem tylko do odczytu, a potem sprawdzamy, co oznacza w praktyce: zaczynając z pozycji osoby z zewnątrz, przejętego komponentu i konta programisty, podążamy za uprawnieniami, aby zobaczyć, jak daleko można dotrzeć z każdej z nich.
01Zakres
Co testujemy
Zarządzanie tożsamością i dostępem: użytkownicy, role, polityki, federacja, konta usługowe
Ścieżki eskalacji uprawnień i zaufanie między kontami
Sieć: grupy zabezpieczeń, publiczne endpointy, peering, połączenia prywatne
Magazyny danych i bazy danych: dostęp publiczny, szyfrowanie, kopie zapasowe, migawki
Moc obliczeniowa: metadane instancji, funkcje serverless, obrazy kontenerów
Kubernetes: RBAC, bezpieczeństwo podów, polityki sieciowe, kontrola dopuszczania, sekrety
Sekrety i klucze: menedżery sekretów, rotacja, sekrety w kodzie i w zmiennych środowiskowych
Logowanie i wykrywanie: co atakujący może zrobić, nie zostawiając śladu w logach
Potok dostarczania: uprawnienia runnerów i ról wdrożeniowych
02Podejście
Jak przebiega praca
01
Przegląd konfiguracji
Z dostępem tylko do odczytu zbieramy konfigurację i porównujemy ją z CIS Benchmarks oraz z zaleceniami dostawcy.
02
Analiza ścieżek ataku
Uprawnienia modelujemy jako graf. Szukamy ścieżek, które prowadzą od tożsamości o niskich uprawnieniach do kontroli administracyjnej lub do danych.
03
Potwierdzenie w praktyce
Istotne ścieżki przechodzimy naprawdę, w granicach zasad prowadzenia testów, aby oddzielić to, co teoretyczne, od tego, co da się wykorzystać.
04
Testy z wnętrza komponentów
Z wnętrza kontenera lub funkcji sprawdzamy, do czego może dotrzeć przejęty komponent: do metadanych, sąsiednich usług, warstwy sterowania.
Duzi dostawcy publikują zasady, które pozwalają testować własne zasoby bez wcześniejszej zgody, z listą zakazanych działań, takich jak atak typu odmowa usługi (DoS). Przed testami sprawdzamy aktualne zasady Twojego dostawcy i działamy w ich granicach.
Czy wystarczy dostęp tylko do odczytu?
Do przeglądu konfiguracji tak. Aby potwierdzić ścieżki ataku, potrzebujemy tożsamości o niskich uprawnieniach, od których te ścieżki się zaczynają; są tworzone na potrzeby testu i usuwane po nim.
Korzystamy z narzędzia do oceny konfiguracji bezpieczeństwa chmury. Co jeszcze można znaleźć?
Takie narzędzia wymieniają błędy konfiguracji jeden po drugim. Rzadko pokazują, które trzy z nich składają się na ścieżkę do danych albo które z dwustu ostrzeżeń naprawdę ma znaczenie. Temu służy ta ocena bezpieczeństwa.