Last updated
Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
Może zawierać inne grupy zarządzające lub subskrypcje.
Umożliwia to stosowanie kontroli zarządzających 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 ramach jednej grupy zarządzającej muszą ufać temu samemu najemcy Entra ID.
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
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.
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 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 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 Microsoft, 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 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.
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 nie-Microsoft)
Wskaźnik właściwości
Domyślny typ użytkownika to “Gość”
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ć)
Pamiętaj, że aby enumerować zasoby Azure, użytkownik potrzebuje wyraźnego przyznania uprawnienia.
Członkowie (dokumentacja)
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 przyznaje domyślnie wszystkie uprawnienia użytkowników członków użytkownikom gości.
Użytkownicy goście mają ograniczony dostęp do właściwości i członkostw obiektów katalogowych (domyślnie) ogranicza 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.
Goście mogą zapraszać
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
Nawet jeśli domyślnie ograniczone, użytkownicy (członkowie i goście) z przyznanymi uprawnieniami mogą wykonywać powyższe działania.
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łonkami grupy mogą być tylko użytkownicy.
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.
Członkostwo dynamiczne: Automatycznie zarządza członkostwem za pomocą reguł, aktualizując włączenie grupy, gdy atrybuty członków się zmieniają.
Zasada usługi to tożsamość stworzona do użytku z aplikacjami, usługami hostowanymi i narzędziami automatyzacji do uzyskiwania dostępu do zasobów Azure. Ten dostęp jest ograniczony przez przypisane role do zasady usługi, 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) nad nią.
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.
Rejestracja aplikacji to konfiguracja, która pozwala aplikacji integrować się z Entra ID i wykonywać działania.
Identyfikator aplikacji (Client ID): Unikalny identyfikator twojej aplikacji w Azure AD.
URI przekierowania: URL-e, do których Azure AD wysyła odpowiedzi uwierzytelniające.
Certyfikaty, sekrety i poświadczenia federowane: Możliwe jest wygenerowanie sekretu lub certyfikatu, aby zalogować się jako zasada usługi aplikacji lub przyznać jej dostęp federowany (np. Github Actions).
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).
Uprawnienia API: Określa, do jakich zasobów lub API aplikacja ma dostęp.
Ustawienia uwierzytelniania: Definiuje obsługiwane przez aplikację przepływy uwierzytelniania (np. OAuth2, OpenID Connect).
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.
Zasada usługi otrzyma wszystkie żądane uprawnienia, z którymi została skonfigurowana.
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, dla wybranych uprawnień (zalecane)
Wszyscy użytkownicy mogą wyrazić zgodę na uprawnienia klasyfikowane jako "niski wpływ", dla aplikacji od zweryfikowanych wydawców lub aplikacji zarejestrowanych w tej organizacji.
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 - zaloguj 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, do których 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ą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:
Przypisana 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.
Przypisana przez użytkownika. Użytkownicy mogą również generować zarządzane tożsamości. Są one tworzone wewnątrz grupy zasobów w ramach 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.
To po prostu tabela w Azure do filtrowania zasad usług i sprawdzania aplikacji, które zostały 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 pozwalają na przyznawanie uprawnień z roli nad konkretną 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.
Aby zarządzać Entra ID, istnieją pewne wbudowane role, które można przypisać do zasad Entra ID w celu zarządzania Entra ID
Najbardziej uprzywilejowaną rolą jest Global Administrator
W opisie roli można zobaczyć jej szczegółowe uprawnienia
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 ramach subskrypcji i na wszystkich zasobach wewnątrz grupy zasobów.
Właściciel |
| Wszystkie typy zasobów |
Współtwórca |
| Wszystkie typy zasobów |
Czytelnik | • Wyświetl wszystkie zasoby | Wszystkie typy zasobów |
Administrator dostępu użytkowników |
| Wszystkie typy zasobów |
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:
Umożliwia uprawnienie do kopii zapasowej, aby wykonać kopię zapasową dysku. | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 | |
Wyś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 kontenerów logicznych (takich jak grupy zarządzające, subskrypcje i grupy zasobów), a zasady, które są nimi objęte, będą miały je nad zasobami wewnątrz tych kontenerów.
Znajdź tutaj listę wszystkich wbudowanych ról Azure.
Znajdź tutaj listę wszystkich wbudowanych ról Entra ID.
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 w innym miejscu
Możliwe jest użycie symboli wieloznacznych
Używany format to JSON
actions służą do kontrolowania działań nad zasobem
dataActions to uprawnienia do danych w obiekcie
Przykład uprawnień JSON dla niestandardowej roli:
Aby podmiot miał dostęp do zasobu, musi mieć przyznaną wyraźną rolę (w jakikolwiek sposób) przyznającą mu to uprawnienie.
Wyraźne przyznanie roli odmowy ma pierwszeństwo przed rolą przyznającą uprawnienie.
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
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żna zapobiec tworzeniu maszyn wirtualnych w nieautoryzowanym regionie lub zapewnić, że wszystkie zasoby mają określone tagi do śledzenia.
Polityki Azure są proaktywne: mogą zatrzymać 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.
Definicja polityki: Zasada, napisana w JSON, która określa, co jest dozwolone lub wymagane.
Przydział polityki: Zastosowanie polityki do określonego zakresu (np. subskrypcja, grupa zasobów).
Inicjatywy: Zbiór polityk zgrupowanych razem w celu szerszej egzekucji.
Efekt: Określa, co się dzieje, gdy polityka jest wyzwalana (np. "Odmów", "Audyt" lub "Dodaj").
Kilka przykładów:
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.
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.
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.
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.
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.
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 root lub w innych grupach zarządzania.
Przykład polityki Azure json:
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.
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 przyznane 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.
Zarządzanie tożsamością uprzywilejowaną (PIM) w Azure to narzędzie, które zarządza, kontroluje i monitoruje uprzywilejowany dostęp w Azure Active Directory i Azure. Zwiększa bezpieczeństwo, zapewniając dostęp uprzywilejowany na żądanie i ograniczony czasowo, wymuszając procesy zatwierdzania i wymagając dodatkowej autoryzacji. Takie podejście minimalizuje ryzyko nieautoryzowanego dostępu, zapewniając, że podwyższone uprawnienia są przyznawane tylko wtedy, gdy jest to konieczne i na określony czas.
Istnieją trzy typy tokenów używanych w OIDC:
Tokeny dostępu: Klient przedstawia ten token serwerowi zasobów, aby uzyskać dostęp do zasobów. Może być używany tylko dla konkretnej kombinacji użytkownika, klienta i zasobu i nie może być unieważniony do momentu wygaśnięcia - co domyślnie wynosi 1 godzinę.
Tokeny ID: Klient otrzymuje ten token od serwera autoryzacji. Zawiera podstawowe informacje o użytkowniku. Jest powiązany z konkretną kombinacją użytkownika i klienta.
Tokeny odświeżania: Przyznawane klientowi wraz z tokenem dostępu. Używane do uzyskiwania nowych tokenów dostępu i ID. Jest powiązany z konkretną kombinacją użytkownika i klienta i może być unieważniony. Domyślny czas wygaśnięcia to 90 dni dla nieaktywnych tokenów odświeżania i brak wygaśnięcia dla aktywnych tokenów.
Informacje o dostępie warunkowym są przechowywane wewnątrz JWT. Jeśli więc zażądajesz tokena z dozwolonego adresu IP, ten IP zostanie przechowany w tokenie, a następnie możesz użyć tego tokena z niedozwolonego IP, aby uzyskać dostęp do zasobów.
W zależności od działania, które chcesz wykonać, "aud" tokena dostępu musi być autoryzowane do kontaktu z adresem URL API, z którym będziesz się kontaktować.
Polecenie az account get-access-token --resource-type [...] obsługuje następujące typy, a każdy z nich doda konkretny "aud" w wynikowym tokenie dostępu:
Zauważ, że poniższe to tylko API obsługiwane przez az account get-access-token, ale jest ich więcej.
aad-graph (Azure Active Directory Graph API): Używane do uzyskiwania dostępu do przestarzałego Azure AD Graph API (deprecjonowane), które pozwala aplikacjom na odczyt i zapis danych katalogowych w Azure Active Directory (Azure AD).
https://graph.windows.net/
arm (Azure Resource Manager): Używane do zarządzania zasobami Azure za pośrednictwem API Azure Resource Manager. Obejmuje operacje takie jak tworzenie, aktualizowanie i usuwanie zasobów, takich jak maszyny wirtualne, konta magazynowe i inne.
https://management.core.windows.net/ lub https://management.azure.com/
batch (Azure Batch Services): Używane do uzyskiwania dostępu do Azure Batch, usługi, która umożliwia efektywne uruchamianie aplikacji obliczeniowych w chmurze na dużą skalę i o wysokiej wydajności.
https://batch.core.windows.net/
data-lake (Azure Data Lake Storage): Używane do interakcji z Azure Data Lake Storage Gen1, które jest skalowalną usługą przechowywania danych i analityki.
https://datalake.azure.net/
media (Azure Media Services): Używane do uzyskiwania dostępu do Azure Media Services, które oferują usługi przetwarzania i dostarczania mediów w chmurze dla treści wideo i audio.
https://rest.media.azure.net
ms-graph (Microsoft Graph API): Używane do uzyskiwania dostępu do Microsoft Graph API, zjednoczonego punktu końcowego dla danych usług Microsoft 365. Umożliwia dostęp do danych i informacji z usług takich jak Azure AD, Office 365, Enterprise Mobility i usługi bezpieczeństwa.
https://graph.microsoft.com
oss-rdbms (Azure Open Source Relational Databases): Używane do uzyskiwania dostępu do usług baz danych Azure dla otwartych silników baz danych, takich jak MySQL, PostgreSQL i MariaDB.
https://ossrdbms-aad.database.windows.net
Sprawdź następującą stronę, aby poznać różne sposoby żądania tokenów dostępu i logowania się z nimi:
Az - Entra ID (formerly AzureAD - AAD)Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
