Az - Podstawowe informacje

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks

Hierarchia organizacji

https://www.tunecom.be/stg_ba12f/wp-content/uploads/2020/01/VDC-Governance-ManagementGroups-1536x716.png

Grupy zarządzające

  • Może zawierać inne grupy zarządzające lub subskrypcje.
  • Umożliwia to stosowanie kontroli zarządzania takich jak RBAC i Azure Policy raz na poziomie grupy zarządzającej, a następnie dziedziczenie ich przez wszystkie subskrypcje w grupie.
  • 10 000 grup zarządzających może być obsługiwanych w jednym katalogu.
  • Drzewo grup zarządzających może obsługiwać do sześciu poziomów głębokości. Ten limit nie obejmuje poziomu głównego ani poziomu subskrypcji.
  • Każda grupa zarządzająca i subskrypcja może mieć tylko jednego rodzica.
  • Nawet jeśli można utworzyć kilka grup zarządzających, istnieje tylko 1 główna grupa zarządzająca.
  • Główna grupa zarządzająca zawiera wszystkie inne grupy zarządzające i subskrypcje i nie może być przenoszona ani usuwana.
  • Wszystkie subskrypcje w jednej grupie zarządzającej muszą ufać temu samemu najemcy Entra ID.

https://td-mainsite-cdn.tutorialsdojo.com/wp-content/uploads/2023/02/managementgroups-768x474.png

Subskrypcje Azure

  • To kolejny logiczny kontener, w którym mogą być uruchamiane zasoby (VM, DB…) i za który będą naliczane opłaty.
  • Jego rodzicem jest zawsze grupa zarządzająca (może to być główna grupa zarządzająca), ponieważ subskrypcje nie mogą zawierać innych subskrypcji.
  • Ufa tylko jednemu katalogowi Entra ID
  • Uprawnienia stosowane na poziomie subskrypcji (lub dowolnego z jej rodziców) są dziedziczone przez wszystkie zasoby wewnątrz subskrypcji.

Grupy zasobów

Z dokumentacji: Grupa zasobów to kontener, który przechowuje powiązane zasoby dla rozwiązania Azure. Grupa zasobów może zawierać wszystkie zasoby dla rozwiązania lub tylko te zasoby, które chcesz zarządzać jako grupą. Zazwyczaj dodawaj zasoby, które mają ten sam cykl życia, do tej samej grupy zasobów, aby łatwo je wdrażać, aktualizować i usuwać jako grupę.

Wszystkie zasoby muszą być w obrębie grupy zasobów i mogą należeć tylko do jednej grupy, a jeśli grupa zasobów zostanie usunięta, wszystkie zasoby w niej również zostaną usunięte.

https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&ssl=1

Identyfikatory zasobów Azure

Każdy zasób w Azure ma identyfikator zasobu Azure, który go identyfikuje.

Format identyfikatora zasobu Azure jest następujący:

  • /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceProviderNamespace}/{resourceType}/{resourceName}

Dla maszyny wirtualnej o nazwie myVM w grupie zasobów myResourceGroup pod subskrypcją ID 12345678-1234-1234-1234-123456789012, identyfikator zasobu Azure wygląda następująco:

  • /subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM

Azure vs Entra ID vs Usługi domenowe Azure AD

Azure

Azure to kompleksowa platforma chmurowa Microsoftu, oferująca szeroki zakres usług, w tym maszyny wirtualne, bazy danych, sztuczną inteligencję i przechowywanie. Działa jako fundament do hostowania i zarządzania aplikacjami, budowania skalowalnych infrastruktur oraz uruchamiania nowoczesnych obciążeń w chmurze. Azure zapewnia narzędzia dla programistów i specjalistów IT do tworzenia, wdrażania i zarządzania aplikacjami i usługami w sposób bezproblemowy, zaspokajając różnorodne potrzeby, od startupów po duże przedsiębiorstwa.

Entra ID (wcześniej Azure Active Directory)

Entra ID to chmurowa usługa zarządzania tożsamością i dostępem, zaprojektowana do obsługi uwierzytelniania, autoryzacji i kontroli dostępu użytkowników. Umożliwia bezpieczny dostęp do usług Microsoftu, takich jak Office 365, Azure i wiele aplikacji SaaS innych firm. Oferuje funkcje takie jak jednolity dostęp (SSO), uwierzytelnianie wieloskładnikowe (MFA) i polityki dostępu warunkowego, między innymi.

Usługi domenowe Entra (wcześniej Azure AD DS)

Usługi domenowe Entra rozszerzają możliwości Entra ID, oferując zarządzane usługi domenowe zgodne z tradycyjnymi środowiskami Windows Active Directory. Obsługują starsze protokoły, takie jak LDAP, Kerberos i NTLM, umożliwiając organizacjom migrację lub uruchamianie starszych aplikacji w chmurze bez wdrażania lokalnych kontrolerów domeny. Usługa ta obsługuje również politykę grupową dla centralnego zarządzania, co czyni ją odpowiednią dla scenariuszy, w których obciążenia oparte na AD muszą współistnieć z nowoczesnymi środowiskami chmurowymi.

Zasady Entra ID

Użytkownicy

  • Nowi użytkownicy
  • Wskaźnik nazwy e-mail i domeny z wybranego najemcy
  • Wskaźnik nazwy wyświetlanej
  • Wskaźnik hasła
  • Wskaźnik właściwości (imię, tytuł zawodowy, dane kontaktowe…)
  • Domyślny typ użytkownika to “członek”
  • Użytkownicy zewnętrzni
  • Wskaźnik e-mail do zaproszenia i nazwy wyświetlanej (może być to e-mail niebędący e-mailem Microsoftu)
  • Wskaźnik właściwości
  • Domyślny typ użytkownika to “Gość”

Domyślne uprawnienia członków i gości

Możesz je sprawdzić w https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions, ale między innymi członek będzie mógł:

  • Czytać wszystkich użytkowników, grupy, aplikacje, urządzenia, role, subskrypcje i ich publiczne właściwości
  • Zapraszać gości (można wyłączyć)
  • Tworzyć grupy zabezpieczeń
  • Czytać nieukryte członkostwa grup
  • Dodawać gości do posiadanych grup
  • Tworzyć nowe aplikacje (można wyłączyć)
  • Dodawać do 50 urządzeń do Azure (można wyłączyć)

Note

Pamiętaj, że aby enumerować zasoby Azure, użytkownik potrzebuje wyraźnego przyznania uprawnienia.

Domyślne konfigurowalne uprawnienia użytkowników

  • Członkowie (dokumenty)
  • Rejestracja aplikacji: Domyślnie Tak
  • Ograniczenie użytkowników niebędących administratorami w tworzeniu najemców: Domyślnie Nie
  • Tworzenie grup zabezpieczeń: Domyślnie Tak
  • Ograniczenie dostępu do portalu administracyjnego Microsoft Entra: Domyślnie Nie
  • To nie ogranicza dostępu API do portalu (tylko web)
  • Zezwolenie użytkownikom na połączenie konta roboczego lub szkolnego z LinkedIn: Domyślnie Tak
  • Pokaż, aby użytkownik pozostał zalogowany: Domyślnie Tak
  • Ograniczenie użytkowników w odzyskiwaniu klucza BitLocker dla ich posiadanych urządzeń: Domyślnie Nie (sprawdź w Ustawieniach urządzenia)
  • Czytać innych użytkowników: Domyślnie Tak (za pośrednictwem Microsoft Graph)
  • Goście
  • Ograniczenia dostępu użytkowników gości:
  • Użytkownicy goście mają takie same uprawnienia jak członkowie.
  • Użytkownicy goście mają ograniczony dostęp do właściwości i członkostw obiektów katalogowych (domyślnie). Ogranicza to dostęp gości tylko do ich własnego profilu użytkownika. Dostęp do informacji o innych użytkownikach i grupach nie jest już dozwolony.
  • Dostęp użytkowników gości jest ograniczony do właściwości i członkostw ich własnych obiektów katalogowych jest najbardziej restrykcyjny.
  • Opcje zapraszania gości:
  • Każdy w organizacji może zapraszać użytkowników gości, w tym gości i nie-administratorów (najbardziej inkluzywne) - Domyślnie
  • Użytkownicy członkowie i użytkownicy przypisani do określonych ról administratorów mogą zapraszać użytkowników gości, w tym gości z uprawnieniami członkowskimi
  • Tylko użytkownicy przypisani do określonych ról administratorów mogą zapraszać użytkowników gości
  • Nikt w organizacji nie może zapraszać użytkowników gości, w tym administratorów (najbardziej restrykcyjne)
  • Użytkownik zewnętrzny opuszcza: Domyślnie Prawda
  • Zezwolenie użytkownikom zewnętrznym na opuszczenie organizacji

Tip

Nawet jeśli są ograniczeni domyślnie, użytkownicy (członkowie i goście) z przyznanymi uprawnieniami mogą wykonywać poprzednie działania.

Grupy

Istnieją 2 typy grup:

  • Zabezpieczenia: Ten typ grupy jest używany do przyznawania członkom dostępu do aplikacji, zasobów i przypisywania licencji. Użytkownicy, urządzenia, zasady usług i inne grupy mogą być członkami.
  • Microsoft 365: Ten typ grupy jest używany do współpracy, dając członkom dostęp do wspólnej skrzynki pocztowej, kalendarza, plików, witryny SharePoint itp. Członkowie grupy mogą być tylko użytkownikami.
  • Będzie miała adres e-mail z domeną najemcy EntraID.

Istnieją 2 typy członkostw:

  • Przypisane: Umożliwia ręczne dodawanie konkretnych członków do grupy.
  • Dynamiczne członkostwo: Automatycznie zarządza członkostwem za pomocą reguł, aktualizując włączenie grupy, gdy zmieniają się atrybuty członków.

Zasady usług

Zasada usługi to tożsamość stworzona do użytku z aplikacjami, hostowanymi usługami i narzędziami automatyzacji do uzyskiwania dostępu do zasobów Azure. Ten dostęp jest ograniczony przez przypisane role, co daje ci kontrolę nad tym, które zasoby mogą być dostępne i na jakim poziomie. Z powodów bezpieczeństwa zawsze zaleca się używanie zasad usług z narzędziami automatyzacji zamiast pozwalać im logować się za pomocą tożsamości użytkownika.

Możliwe jest bezpośrednie logowanie jako zasada usługi poprzez wygenerowanie jej sekretu (hasła), certyfikatu lub przyznanie federowanego dostępu do platform zewnętrznych (np. Github Actions).

  • Jeśli wybierzesz uwierzytelnianie hasłem (domyślnie), zapisz wygenerowane hasło, ponieważ nie będziesz mógł uzyskać do niego ponownie dostępu.
  • Jeśli wybierzesz uwierzytelnianie certyfikatem, upewnij się, że aplikacja będzie miała dostęp do klucza prywatnego.

Rejestracje aplikacji

Rejestracja aplikacji to konfiguracja, która pozwala aplikacji integrować się z Entra ID i wykonywać działania.

Kluczowe komponenty:

  1. Identyfikator aplikacji (Client ID): Unikalny identyfikator twojej aplikacji w Azure AD.
  2. URI przekierowania: URL-e, do których Azure AD wysyła odpowiedzi uwierzytelniające.
  3. Certyfikaty, sekrety i poświadczenia federacyjne: Możliwe jest wygenerowanie sekretu lub certyfikatu, aby zalogować się jako zasada usługi aplikacji lub przyznać jej dostęp federowany (np. Github Actions).
  4. Jeśli certyfikat lub sekret zostanie wygenerowany, możliwe jest, aby osoba zalogowała się jako zasada usługi za pomocą narzędzi CLI, znając identyfikator aplikacji, sekret lub certyfikat oraz najemcę (domena lub ID).
  5. Uprawnienia API: Określa, do jakich zasobów lub API aplikacja ma dostęp.
  6. Ustawienia uwierzytelniania: Definiuje obsługiwane przez aplikację przepływy uwierzytelniania (np. OAuth2, OpenID Connect).
  7. Zasada usługi: Zasada usługi jest tworzona, gdy aplikacja jest tworzona (jeśli jest to robione z konsoli internetowej) lub gdy jest instalowana w nowym najemcy.
  8. Zasada usługi otrzyma wszystkie żądane uprawnienia, z którymi została skonfigurowana.

Domyślne uprawnienia zgody

Zgoda użytkownika na aplikacje

  • Nie zezwalaj na zgodę użytkownika
  • Administrator będzie wymagany dla wszystkich aplikacji.
  • Zezwól na zgodę użytkownika dla aplikacji od zweryfikowanych wydawców, aplikacji wewnętrznych i aplikacji żądających tylko wybranych uprawnień (zalecane)
  • Wszyscy użytkownicy mogą wyrazić zgodę na aplikacje żądające tylko uprawnień klasyfikowanych jako “niski wpływ”, aplikacje od zweryfikowanych wydawców i aplikacje zarejestrowane w najemcy.
  • Domyślne uprawnienia o niskim wpływie (chociaż musisz zaakceptować, aby dodać je jako niskie):
  • User.Read - zaloguj się i odczytaj profil użytkownika
  • offline_access - utrzymuj dostęp do danych, do których użytkownicy udzielili dostępu
  • openid - loguj użytkowników
  • profile - wyświetl podstawowy profil użytkownika
  • email - wyświetl adres e-mail użytkownika
  • Zezwól na zgodę użytkownika dla aplikacji (domyślnie)
  • Wszyscy użytkownicy mogą wyrazić zgodę na dowolną aplikację, aby uzyskać dostęp do danych organizacji.

Prośby o zgodę administratora: Domyślnie Nie

  • Użytkownicy mogą prosić o zgodę administratora na aplikacje, na które nie mogą wyrazić zgody
  • Jeśli Tak: Możliwe jest wskazanie Użytkowników, Grup i Ról, które mogą wyrażać zgodę na prośby
  • Skonfiguruj również, czy użytkownicy otrzymają powiadomienia e-mail i przypomnienia o wygaśnięciu

Zarządzana tożsamość (metadane)

Zarządzane tożsamości w Azure Active Directory oferują rozwiązanie do automatycznego zarządzania tożsamością aplikacji. Te tożsamości są używane przez aplikacje w celu łączenia się z zasobami zgodnymi z uwierzytelnianiem Azure Active Directory (Azure AD). Umożliwia to usunięcie potrzeby twardego kodowania poświadczeń chmurowych w kodzie, ponieważ aplikacja będzie mogła skontaktować się z usługą metadanych, aby uzyskać ważny token do wykonywania działań jako wskazana zarządzana tożsamość w Azure.

Istnieją dwa typy zarządzanych tożsamości:

  • Przypisane do systemu. Niektóre usługi Azure pozwalają na włączenie zarządzanej tożsamości bezpośrednio na instancji usługi. Gdy włączysz zarządzaną tożsamość przypisaną do systemu, zasada usługi jest tworzona w najemcy Entra ID zaufanym przez subskrypcję, w której znajduje się zasób. Gdy zasób jest usuwany, Azure automatycznie usuwa tożsamość za Ciebie.
  • Przypisane przez użytkownika. Użytkownicy mogą również generować zarządzane tożsamości. Są one tworzone wewnątrz grupy zasobów w subskrypcji, a zasada usługi zostanie utworzona w EntraID zaufanym przez subskrypcję. Następnie możesz przypisać zarządzaną tożsamość do jednej lub więcej instancji usługi Azure (wiele zasobów). W przypadku zarządzanych tożsamości przypisanych przez użytkownika tożsamość jest zarządzana oddzielnie od zasobów, które jej używają.

Zarządzane tożsamości nie generują wiecznych poświadczeń (jak hasła czy certyfikaty) do uzyskania dostępu jako przypisana do niej zasada usługi.

Aplikacje korporacyjne

To po prostu tabela w Azure do filtrowania zasad usług i sprawdzania aplikacji, które zostały do nich przypisane.

Nie jest to inny typ “aplikacji”, nie ma żadnego obiektu w Azure, który jest “Aplikacją korporacyjną”, to tylko abstrakcja do sprawdzania zasad usług, rejestracji aplikacji i zarządzanych tożsamości.

Jednostki administracyjne

Jednostki administracyjne pozwalają na przyznawanie uprawnień z roli nad określoną częścią organizacji.

Przykład:

  • Scenariusz: Firma chce, aby regionalni administratorzy IT zarządzali tylko użytkownikami w swoim regionie.
  • Wdrożenie:
  • Utwórz jednostki administracyjne dla każdego regionu (np. “AU Ameryki Północnej”, “AU Europy”).
  • Wypełnij AU użytkownikami z ich odpowiednich regionów.
  • AU mogą zawierać użytkowników, grupy lub urządzenia
  • AU obsługują dynamiczne członkostwa
  • AU nie mogą zawierać AU
  • Przypisz role administratorów:
  • Przyznaj rolę “Administrator użytkowników” regionalnym pracownikom IT, ograniczoną do AU ich regionu.
  • Wynik: Regionalni administratorzy IT mogą zarządzać kontami użytkowników w swoim regionie, nie wpływając na inne regiony.

Role i uprawnienia Entra ID

  • Aby zarządzać Entra ID, istnieją pewne wbudowane role, które można przypisać do zasad Entra ID w celu zarządzania Entra ID
  • Sprawdź role w https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference
  • Role oznaczone jako PRIVILEGED przez EntraID powinny być przypisywane ostrożnie, ponieważ jak wyjaśnia Microsoft w dokumentacji: Przypisania ról uprzywilejowanych mogą prowadzić do podniesienia uprawnień, jeśli nie są używane w sposób bezpieczny i zamierzony.
  • Najbardziej uprzywilejowaną rolą jest Globalny administrator
  • Role grupują szczegółowe uprawnienia i można je znaleźć w ich opisach.
  • Możliwe jest tworzenie niestandardowych ról z pożądanymi uprawnieniami. Chociaż z jakiegoś powodu nie wszystkie szczegółowe uprawnienia są dostępne dla administratorów do tworzenia niestandardowych ról.
  • Role w Entra ID są całkowicie niezależne od ról w Azure. Jedynym związkiem jest to, że zasady z rolą Globalnego administratora w Entra ID mogą podnieść się do roli Administratora dostępu użytkowników w Azure.
  • Nie można używać symboli wieloznacznych w rolach Entra ID.

Role i uprawnienia Azure

  • Role są przypisywane do zasad w zakresie: principal -[HAS ROLE]->(scope)
  • Role przypisane do grup są dziedziczone przez wszystkich członków grupy.
  • W zależności od zakresu, do którego przypisano rolę, rola może być dziedziczona do innych zasobów wewnątrz kontenera zakresu. Na przykład, jeśli użytkownik A ma rolę w subskrypcji, będzie miał tę rolę we wszystkich grupach zasobów w subskrypcji i na wszystkich zasobach wewnątrz grupy zasobów.

Wbudowane role

Z dokumentacji: Azure role-based access control (Azure RBAC) ma kilka wbudowanych ról Azure, które możesz przypisać do użytkowników, grup, zasad usług i zarządzanych tożsamości. Przypisania ról to sposób, w jaki kontrolujesz dostęp do zasobów Azure. Jeśli wbudowane role nie spełniają specyficznych potrzeb twojej organizacji, możesz stworzyć własne niestandardowe role Azure.

Wbudowane role mają zastosowanie tylko do zasobów, do których są przeznaczone, na przykład sprawdź te 2 przykłady wbudowanych ról dla zasobów obliczeniowych:

Czytelnik kopii zapasowej dyskuUmożliwia uprawnienia do kopii zapasowej, aby wykonać kopię zapasową dysku.3e5e47e6-65f7-47ef-90b5-e5dd4d455f24
Logowanie użytkownika maszyny wirtualnejWyświetl maszyny wirtualne w portalu i zaloguj się jako zwykły użytkownik.fb879df8-f326-4884-b1cf-06f3ad86be52

Te role mogą być również przypisane do logicznych kontenerów (takich jak grupy zarządzające, subskrypcje i grupy zasobów), a zasady dotknięte będą miały je nad zasobami wewnątrz tych kontenerów.

Niestandardowe role

  • Możliwe jest również tworzenie niestandardowych ról
  • Tworzone są wewnątrz zakresu, chociaż rola może być w kilku zakresach (grupy zarządzające, subskrypcje i grupy zasobów)
  • Możliwe jest skonfigurowanie wszystkich szczegółowych uprawnień, które będzie miała niestandardowa rola
  • Możliwe jest wykluczenie uprawnień
  • Zasada z wykluczonym uprawnieniem nie będzie mogła go używać, nawet jeśli uprawnienie jest przyznawane gdzie indziej
  • Możliwe jest użycie symboli wieloznacznych
  • Używany format to JSON
  • actions odnosi się do uprawnień do operacji zarządzania zasobami, takich jak tworzenie, aktualizowanie lub usuwanie definicji i ustawień zasobów.
  • dataActions to uprawnienia do operacji danych w obrębie zasobu, umożliwiające odczyt, zapis lub usunięcie rzeczywistych danych zawartych w zasobie.
  • notActions i notDataActions są używane do wykluczania konkretnych uprawnień z roli. Jednak nie odmawiają ich, jeśli inna rola je przyznaje, zasada będzie je miała.
  • assignableScopes to tablica zakresów, w których rola może być przypisana (takich jak grupy zarządzające, subskrypcje lub grupy zasobów).

Przykład uprawnień JSON dla niestandardowej roli:

{
"properties": {
"roleName": "",
"description": "",
"assignableScopes": ["/subscriptions/9291ff6e-6afb-430e-82a4-6f04b2d05c7f"],
"permissions": [
{
"actions": [
"Microsoft.DigitalTwins/register/action",
"Microsoft.DigitalTwins/unregister/action",
"Microsoft.DigitalTwins/operations/read",
"Microsoft.DigitalTwins/digitalTwinsInstances/read",
"Microsoft.DigitalTwins/digitalTwinsInstances/write",
"Microsoft.CostManagement/exports/*"
],
"notActions": [
"Astronomer.Astro/register/action",
"Astronomer.Astro/unregister/action",
"Astronomer.Astro/operations/read",
"Astronomer.Astro/organizations/read"
],
"dataActions": [],
"notDataActions": []
}
]
}
}

Kolejność uprawnień

  • Aby podmiot miał dostęp do zasobu, musi mu zostać przyznana wyraźna rola (w jakikolwiek sposób) przyznająca mu to uprawnienie.
  • Wyraźne przyznanie odmowy ma pierwszeństwo przed rolą przyznającą uprawnienie.

https://link.springer.com/chapter/10.1007/978-1-4842-7325-8_10

Globalny administrator

Globalny administrator to rola z Entra ID, która przyznaje pełną kontrolę nad dzierżawą Entra ID. Jednak domyślnie nie przyznaje żadnych uprawnień do zasobów Azure.

Użytkownicy z rolą globalnego administratora mają możliwość ‘podniesienia’ do roli administratora dostępu użytkowników w grupie zarządzania Root. Tak więc globalni administratorzy mogą zarządzać dostępem w wszystkich subskrypcjach Azure i grupach zarządzania.
To podniesienie można wykonać na końcu strony: https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties

Warunki przypisania i MFA

Zgodnie z dokumentacją: Obecnie warunki mogą być dodawane do wbudowanych lub niestandardowych przypisań ról, które mają akcje danych w magazynie blob lub akcje danych w magazynie kolejki.

Przypisania odmowy

Podobnie jak przypisania ról, przypisania odmowy są używane do kontrolowania dostępu do zasobów Azure. Jednak przypisania odmowy są używane do wyraźnego odmawiania dostępu do zasobu, nawet jeśli użytkownik uzyskał dostęp poprzez przypisanie roli. Przypisania odmowy mają pierwszeństwo przed przypisaniami ról, co oznacza, że jeśli użytkownik uzyskał dostęp poprzez przypisanie roli, ale również wyraźnie odmówiono mu dostępu poprzez przypisanie odmowy, przypisanie odmowy będzie miało pierwszeństwo.

Podobnie jak przypisania ról, przypisania odmowy są stosowane w określonym zakresie, wskazując dotknięte podmioty i uprawnienia, które są odmawiane. Ponadto, w przypadku przypisań odmowy, możliwe jest zapobieżenie dziedziczeniu odmowy przez zasoby podrzędne.

Polityki Azure

Polityki Azure to zasady, które pomagają organizacjom zapewnić, że ich zasoby spełniają określone standardy i wymagania dotyczące zgodności. Umożliwiają one egzekwowanie lub audyt ustawień na zasobach w Azure. Na przykład, możesz zapobiec tworzeniu maszyn wirtualnych w nieautoryzowanym regionie lub upewnić się, że wszystkie zasoby mają określone tagi do śledzenia.

Polityki Azure są proaktywne: mogą powstrzymać tworzenie lub zmianę zasobów, które nie są zgodne. Są również reaktywne, umożliwiając znalezienie i naprawienie istniejących zasobów, które nie są zgodne.

Kluczowe pojęcia

  1. Definicja polityki: Zasada, napisana w JSON, która określa, co jest dozwolone lub wymagane.
  2. Przypisanie polityki: Zastosowanie polityki do określonego zakresu (np. subskrypcja, grupa zasobów).
  3. Inicjatywy: Zbiór polityk zgrupowanych razem w celu szerszej egzekucji.
  4. Efekt: Określa, co się dzieje, gdy polityka jest wyzwalana (np. “Odmów”, “Audyt” lub “Dodaj”).

Niektóre przykłady:

  1. Zapewnienie zgodności z określonymi regionami Azure: Ta polityka zapewnia, że wszystkie zasoby są wdrażane w określonych regionach Azure. Na przykład, firma może chcieć zapewnić, że wszystkie jej dane są przechowywane w Europie w celu zgodności z RODO.
  2. Egzekwowanie standardów nazewnictwa: Polityki mogą egzekwować konwencje nazewnictwa dla zasobów Azure. Pomaga to w organizacji i łatwej identyfikacji zasobów na podstawie ich nazw, co jest pomocne w dużych środowiskach.
  3. Ograniczenie niektórych typów zasobów: Ta polityka może ograniczyć tworzenie niektórych typów zasobów. Na przykład, polityka może być ustawiona, aby zapobiec tworzeniu drogich typów zasobów, takich jak niektóre rozmiary VM, w celu kontrolowania kosztów.
  4. Egzekwowanie polityk tagowania: Tagi to pary klucz-wartość związane z zasobami Azure używane do zarządzania zasobami. Polityki mogą egzekwować, że określone tagi muszą być obecne lub mieć określone wartości dla wszystkich zasobów. Jest to przydatne do śledzenia kosztów, własności lub kategoryzacji zasobów.
  5. Ograniczenie publicznego dostępu do zasobów: Polityki mogą egzekwować, że niektóre zasoby, takie jak konta magazynowe lub bazy danych, nie mają publicznych punktów końcowych, zapewniając, że są dostępne tylko w sieci organizacji.
  6. Automatyczne stosowanie ustawień zabezpieczeń: Polityki mogą być używane do automatycznego stosowania ustawień zabezpieczeń do zasobów, takich jak stosowanie określonej grupy zabezpieczeń sieciowych do wszystkich VM lub zapewnienie, że wszystkie konta magazynowe używają szyfrowania.

Należy zauważyć, że polityki Azure mogą być przypisane do dowolnego poziomu hierarchii Azure, ale są najczęściej używane w grupie zarządzania głównej lub w innych grupach zarządzania.

Przykład polityki Azure json:

{
"policyRule": {
"if": {
"field": "location",
"notIn": ["eastus", "westus"]
},
"then": {
"effect": "Deny"
}
},
"parameters": {},
"displayName": "Allow resources only in East US and West US",
"description": "This policy ensures that resources can only be created in East US or West US.",
"mode": "All"
}

Dziedziczenie uprawnień

W Azure uprawnienia mogą być przypisane do dowolnej części hierarchii. Obejmuje to grupy zarządzania, subskrypcje, grupy zasobów i poszczególne zasoby. Uprawnienia są dziedziczone przez zawarte zasoby podmiotu, do którego zostały przypisane.

Ta struktura hierarchiczna umożliwia efektywne i skalowalne zarządzanie uprawnieniami dostępu.

Azure RBAC vs ABAC

RBAC (kontrola dostępu oparta na rolach) to to, co już widzieliśmy w poprzednich sekcjach: Przypisanie roli do podmiotu w celu przyznania mu dostępu do zasobu.
Jednak w niektórych przypadkach możesz chcieć zapewnić bardziej szczegółowe zarządzanie dostępem lub uproszczenie zarządzania setkami przypisań ról.

Azure ABAC (kontrola dostępu oparta na atrybutach) opiera się na Azure RBAC, dodając warunki przypisania ról oparte na atrybutach w kontekście konkretnych działań. Warunek przypisania roli to dodatkowa kontrola, którą możesz opcjonalnie dodać do swojego przypisania roli, aby zapewnić bardziej szczegółową kontrolę dostępu. Warunek filtruje uprawnienia przyznawane jako część definicji roli i przypisania roli. Na przykład, możesz dodać warunek, który wymaga, aby obiekt miał określony tag, aby go odczytać.
Nie możesz wyraźnie odmówić dostępu do konkretnych zasobów za pomocą warunków.

Odniesienia

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks