Az - Basic Information
Last updated
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ą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 mogą 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, informacje 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 przed tworzeniem 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 przed odzyskiwaniem klucza BitLocker dla ich posiadanych urządzeń: Domyślnie Nie (sprawdź w Ustawieniach urządzenia)
Czytać innych użytkowników: Domyślnie Tak (poprzez Microsoft Graph)
Goście
Ograniczenia dostępu użytkowników gości
Użytkownicy goście mają takie same uprawnienia jak członkowie, co domyślnie przyznaje 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.
Dynamiczne członkostwo: 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, 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 mu 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, 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:
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 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 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 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.
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 Globalny administrator
W opisie roli można zobaczyć jej szczegółowe uprawnienia
Role są przypisywane do zasad w zakresie: zasada -[MA ROLĘ]->(zakres)
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
Pełny dostęp do wszystkich zasobów
Może zarządzać dostępem dla innych użytkowników
Wszystkie typy zasobów
Współtwórca
Pełny dostęp do wszystkich zasobów
Nie może zarządzać dostępem
Wszystkie typy zasobów
Czytelnik
• Wyświetl wszystkie zasoby
Wszystkie typy zasobów
Administrator dostępu użytkowników
Wyświetl wszystkie zasoby
Może zarządzać dostępem dla innych 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ę z wszystkimi wbudowanymi rolami Azure.
Znajdź tutaj listę z wszystkimi wbudowanymi rolami 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 niezgodnych.
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.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
