Cała załoga miała dostęp do magazynu z sekretami. Wystarczyła jedna reguła grupy

Kontekst

Zaczęło się od czegoś, co w raportach zwykle chwalimy. Klient przeniósł jeden z magazynów kluczy Azure Key Vault na rekomendowany przez Microsoft model autoryzacji Azure RBAC. Dokładnie tak, jak każą dobre praktyki.

Chwilę później patrzyliśmy na regułę grupy dynamicznej, która nadawała odczyt sekretów w tym magazynie. Reguła brzmiała: każdy użytkownik typu Member. W praktyce znaczyło to, że każdy nowy pracownik dostawał dostęp do sekretów i certyfikatów automatycznie, w dniu założenia konta. Kilkuset osób. Nikt tego nie nadawał świadomie. Grupa po prostu robiła to, co miała wpisane w regule.

To typowy moment w audytach konfiguracji chmury. Ktoś zrobił rzecz zgodnie z podręcznikiem, a i tak zostawił szeroko otwarte drzwi, bo dwa dobre pomysły spotkały się w złym miejscu. Dopiero potem doszliśmy do reszty: z czym klient się do nas zgłosił, jak wyglądało środowisko i dlaczego akurat konto z prawem do odczytu wystarczyło, żeby to wszystko zobaczyć.

Środowisko było typowe dla organizacji, która urosła szybciej niż jej porządki w chmurze. Tenant Entra ID, jedna produkcyjna subskrypcja Azure, kilkaset kont, siedem magazynów kluczy, dwa środowiska Synapse Analytics, kilka kont Azure Storage z danymi produkcyjnymi. Audyt prowadziliśmy według CIS Microsoft Azure Foundations Benchmark v5.0.0, łącząc testy automatyczne z manualnym przeglądem konfiguracji.

Wyzwanie

Chmura rzadko przegrywa przez jedną spektakularną dziurę. Przegrywa przez stos drobiazgów, z których każdy z osobna wydaje się do przeżycia.

Trzeba było też oddać sprawiedliwość drugiej stronie. Zabezpieczenia tożsamości nie były głupie. Część vaultów działała na Azure RBAC, dostęp bywał rozdzielony na grupy odczytu i administracji, backup w ogóle istniał. Problem nie polegał na tym, że nikt się nie starał. Polegał na tym, że kilka pojedynczych ustawień, każde ustawione „na później”, odbierało tym staraniom całą wartość.

Nasze zadanie sprowadzało się do pytania, które zadaje sobie każdy CISO po nocnym telefonie: gdyby napastnik przejął jedno zwykłe konto, jak daleko by zaszedł, zanim ktokolwiek by to zauważył. Odpowiedź, którą znaleźliśmy, była niewygodna. Daleko. I raczej by tego nie zauważono, bo audyt zapytań i wykrywanie zagrożeń w hurtowni były wyłączone.

Co zrobiliśmy

Dostaliśmy jedno konto z trzema rolami do odczytu: Reader, Key Vault Reader, Log Analytics Reader. Żadnych uprawnień do zmiany czegokolwiek. Enumerowaliśmy z niego tożsamości w Entra ID, przypisania RBAC na subskrypcji i zasobach, konfigurację sieciową usług oraz ustawienia magazynów kluczy i kont Storage. Potem układaliśmy z tego ścieżki, którymi poszedłby ktoś nieproszony.

Trzy z nich warto pokazać w całości.

Pierwsza to grupa dynamiczna od sekretów. Magazyn kluczy siedział na poprawnym modelu RBAC, ale grupa z prawem odczytu miała regułę członkostwa obejmującą wszystkich zwykłych pracowników. Do tego publiczny dostęp sieciowy do vaultu ze wszystkich sieci. Poświadczenia jednej dowolnej osoby, użyte z dowolnego miejsca na świecie, otwierały zawartość magazynu.

Druga to produkcyjna hurtownia danych na Synapse Analytics. Reguła zapory wpuszczała ruch z całej publicznej przestrzeni adresowej. Trzy ustawienia, które napędzały pierwsze dwie ścieżki, sprowadzały się do tego:

# Reguła zapory workspace'u hurtowni (Synapse Analytics)
name       startIP        endIP
allowAll   0.0.0.0        255.255.255.255

# Reguła członkostwa grupy dynamicznej z odczytem sekretów (Entra ID)
user.userType -eq "Member"     # trafia tu każde konto pracownika, automatycznie

# Uwierzytelnianie środowiska Synapse
azureADOnlyAuthentication = False   # aktywne lokalne konto administratora SQL

Interfejsy dostępowe hurtowni były więc osiągalne z każdego adresu na świecie, a obok nich działało lokalne konto administratora SQL. Takie logowanie omija Conditional Access, wymuszanie MFA i cały aparat tożsamości Entra ID. Kto zna albo zgadnie to hasło, wchodzi do danych produkcyjnych bez żadnego ograniczenia sieciowego. A ponieważ audyt zapytań był wyłączony, wchodzi po cichu.

Trzecia ścieżka to martwe konta z aktywnymi uprawnieniami. Wyłączone konto byłego pracownika wciąż trzymało rolę Właściciela na workspace hurtowni i na koncie Storage. Do tego dochodziły konta gości zewnętrznego podwykonawcy z dostępem do produkcyjnej hurtowni, z imiennymi regułami zapory wpuszczającymi ich prywatne adresy, w tym jedno konto od dawna nieaktywne, a mimo to nadal wpuszczone do środowiska produkcyjnego.

Całość spinaliśmy mapowaniem na MITRE ATT&CK, bo to najczytelniejszy język dla zespołu blue team po drugiej stronie:

Rezultat

Środowisko nie spełniło 60 ze 155 kontrolek CIS, a kolejne 82 wypadły z ostrzeżeniem. Dwie rzeczy oznaczyliśmy jako krytyczne, do naprawy w siedem dni: otwartą na cały Internet zaporę produkcyjnej hurtowni oraz grupę dynamiczną dającą całej załodze dostęp do sekretów. Łączne ryzyko projektu uplasowało się w górnej połowie skali, ale sednem jest tu co innego niż liczba. Żadne z tych znalezisk nie wymagało zero-daya. Wszystkie były włączonymi lub wyłączonymi przełącznikami, które ktoś kiedyś zostawił w domyślnej pozycji.

Ryzyko przetłumaczyliśmy na język, którym zarząd rozmawia o pieniądzach. Magazyn sekretów otwarty dla wszystkich to jeden przejęty laptop dzielący napastnika od kluczy do integracji i baz. Hurtownia bez ograniczeń sieciowych i z lokalnym logowaniem SQL to droga do danych produkcyjnych z pominięciem MFA. Backup bez trybu Locked i bez autoryzacji wieloosobowej to scenariusz, w którym ransomware najpierw kasuje kopie, a dopiero potem szyfruje. 96 procent sekretów bez daty wygaśnięcia to poświadczenia, które zostają ważne bezterminowo, także te, które dawno wyciekły albo poszły w niepamięć.

Rekomendacje zostawiliśmy w formie, którą da się odhaczyć, z terminem i priorytetem przy każdej:

• Usunąć regułę wpuszczającą cały Internet do hurtowni i ograniczyć dostęp do zaufanych sieci albo wdrożyć Private Endpoint. To pierwsze siedem dni.
• Zawęzić grupę dynamiczną od sekretów do osób z realną potrzebą, zamiast reguły obejmującej wszystkich pracowników. Również pierwsze siedem dni.
• Wyłączyć lokalne uwierzytelnianie SQL na hurtowni i przejść wyłącznie na tożsamość Entra ID, żeby dostęp objąć MFA i Conditional Access.
• Odebrać wszystkie przypisania ról wyłączonemu kontu i zweryfikować dostęp kont gości zewnętrznego podwykonawcy, w tym usunąć imienne reguły zapory.
• Włączyć audyt zapytań i wykrywanie zagrożeń w obu środowiskach hurtowni, z wysyłką logów do Sentinela, oraz podnieść w Defenderze przynajmniej ochronę Key Vault i Storage.
• Przypisać daty wygaśnięcia sekretom i dołożyć politykę Azure Policy, która blokuje tworzenie sekretów bez terminu ważności.

Retest po wdrożeniu potwierdzi, że kontrolki wróciły na właściwe pozycje. To akurat dobra wiadomość w audytach konfiguracji: skoro problem był w ustawieniach, to i naprawa jest w ustawieniach, a nie w przepisywaniu połowy architektury.

Ile z tych ustawień w twojej chmurze stoi dziś w pozycji „na później”? Jeśli nie wiesz, kto ma dostęp do twoich sekretów, albo z jakiego adresu można wejść do twojej hurtowni, możemy to sprawdzić na uprawnieniach do odczytu, tak samo jak tutaj.