Translated ['src/pentesting-cloud/azure-security/az-basic-information/RE

This commit is contained in:
Translator
2025-02-10 23:33:03 +00:00
parent 4aa57c8bff
commit d4fb3e457a
2 changed files with 64 additions and 57 deletions
@@ -15,7 +15,7 @@
- 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.**
- Wszystkie subskrypcje w jednej grupie zarządzającej muszą ufać **temu samemu najemcy Entra ID.**
<figure><img src="../../../images/image (147).png" alt=""><figcaption><p><a href="https://td-mainsite-cdn.tutorialsdojo.com/wp-content/uploads/2023/02/managementgroups-768x474.png">https://td-mainsite-cdn.tutorialsdojo.com/wp-content/uploads/2023/02/managementgroups-768x474.png</a></p></figcaption></figure>
@@ -24,7 +24,7 @@
- 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
- **Uprawnienia** stosowane na poziomie subskrypcji (lub dowolnego z jej rodziców) są **dziedziczone** przez wszystkie zasoby wewnątrz subskrypcji.
### Grupy zasobów
@@ -52,11 +52,11 @@ Dla maszyny wirtualnej o nazwie myVM w grupie zasobów `myResourceGroup` pod sub
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 (dawniej Azure Active Directory)
### 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 (dawniej Azure AD DS)
### 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.
@@ -71,7 +71,7 @@ Usługi domenowe Entra rozszerzają możliwości Entra ID, oferując **zarządza
- 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 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ść**”
@@ -92,14 +92,14 @@ Możesz je sprawdzić w [https://learn.microsoft.com/en-us/entra/fundamentals/us
### Domyślne konfigurowalne uprawnienia użytkowników
- **Członkowie (**[**dokumentacja**](https://learn.microsoft.com/en-gb/entra/fundamentals/users-default-permissions#restrict-member-users-default-permissions)**)**
- **Członkowie (**[**dokumenty**](https://learn.microsoft.com/en-gb/entra/fundamentals/users-default-permissions#restrict-member-users-default-permissions)**)**
- 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**
- Pokazanie, aby użytkownik pozostał zalogowany: 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**
@@ -112,8 +112,8 @@ Możesz je sprawdzić w [https://learn.microsoft.com/en-us/entra/fundamentals/us
- **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żytkownicy zewnętrzni mogą odejść**: Domyślnie **Prawda**
- Zezwolenie użytkownikom zewnętrznym na odejście z organizacji
- **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.
@@ -123,17 +123,17 @@ Możesz je sprawdzić w [https://learn.microsoft.com/en-us/entra/fundamentals/us
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.
- **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.
- **Członkostwo dynamiczne**: Automatycznie zarządza członkostwem za pomocą reguł, aktualizując włączenie grupy, gdy zmieniają się atrybuty członków.
- **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**, 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.
**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).
@@ -148,7 +148,7 @@ Możliwe jest **bezpośrednie logowanie jako zasada usługi** poprzez wygenerowa
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 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).
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).
1. 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).
4. **Uprawnienia API:** Określa, do jakich zasobów lub API aplikacja ma dostęp.
5. **Ustawienia uwierzytelniania:** Definiuje obsługiwane przez aplikację przepływy uwierzytelniania (np. OAuth2, OpenID Connect).
@@ -161,20 +161,20 @@ Możliwe jest **bezpośrednie logowanie jako zasada usługi** poprzez wygenerowa
- **Nie zezwalaj na zgodę użytkownika**
- Administrator będzie wymagany dla wszystkich aplikacji.
- **Zezwól na zgodę użytkownika na aplikacje 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 niskiego wpływu (chociaż musisz zaakceptować, aby dodać je jako niskie):
- **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 - zaloguj użytkowników
- 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 na aplikacje (domyślnie)**
- **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
- 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
@@ -184,8 +184,8 @@ Zarządzane tożsamości w Azure Active Directory oferują rozwiązanie do **aut
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ą**.
- **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.
@@ -193,7 +193,7 @@ Zarządzane tożsamości **nie generują wiecznych poświadczeń** (jak hasła c
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.
**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
@@ -214,20 +214,20 @@ Przykład:
### Role i uprawnienia Entra ID
- Aby zarządzać Entra ID, istnieją pewne **wbudowane role**, które można przypisać do głównych tożsamości Entra ID w celu zarządzania 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](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](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference): 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 tożsamości 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ć znaków wieloznacznych** w rolach Entra ID.
- 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 **tożsamości** w **zakresie**: `tożsamość -[MA ROLĘ]->(zakres)`
- **Role** są **przypisywane** do **zasad** w **zakresie**: `principal -[HAS ROLE]->(scope)`
- **Role** przypisane do **grup****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 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
@@ -235,14 +235,14 @@ Przykład:
**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 dysku](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#disk-backup-reader) | Umożliwia dostęp do skarbców kopii zapasowej w celu wykonania kopii zapasowej dysku. | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 |
| [Czytelnik kopii zapasowej dysku](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#disk-backup-reader) | Umożliwia uprawnienia do kopii zapasowej, aby wykonać kopię zapasową dysku. | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 |
| ----------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------ |
| [Użytkownik logowania do maszyny wirtualnej](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#virtual-machine-user-login) | Wyświetl maszyny wirtualne w portalu i zaloguj się jako zwykły użytkownik. | fb879df8-f326-4884-b1cf-06f3ad86be52 |
| [Logowanie użytkownika maszyny wirtualnej](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#virtual-machine-user-login) | 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 logicznych kontenerów** (takich jak grupy zarządzające, subskrypcje i grupy zasobów), a tożsamości, które są nimi objęte, będą miały je **w odniesieniu do zasobów wewnątrz tych kontenerów**.
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**.
- Znajdź tutaj listę [**wszystkich wbudowanych ról Azure**](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles).
- Znajdź tutaj listę [**wszystkich wbudowanych ról Entra ID**](https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference).
- Znajdź tutaj listę z [**wszystkimi wbudowanymi rolami Azure**](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles).
- Znajdź tutaj listę z [**wszystkimi wbudowanymi rolami Entra ID**](https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference).
### Niestandardowe role
@@ -250,12 +250,12 @@ Te role mogą **być również przypisane do logicznych kontenerów** (takich ja
- 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ń
- Tożsamość z wykluczonym uprawnieniem nie będzie mogła go używać, nawet jeśli uprawnienie jest przyznawane gdzie indziej
- Możliwe jest użycie znaków wieloznacznych
- 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ądzających na zasobach, takich jak tworzenie, aktualizowanie lub usuwanie definicji i ustawień zasobów.
- `dataActions` to uprawnienia do operacji na 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, tożsamość je otrzyma.
- `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:
@@ -299,14 +299,14 @@ Przykład uprawnień JSON dla niestandardowej roli:
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**. Dzięki temu globalni administratorzy mogą zarządzać dostępem w **wszystkich subskrypcjach Azure i grupach zarządzania.**\
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](https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties)
<figure><img src="../../../images/image (349).png" alt=""><figcaption></figcaption></figure>
### Warunki przypisania i MFA
Zgodnie z **[dokumentacją](https://learn.microsoft.com/en-us/azure/role-based-access-control/conditions-role-assignments-portal)**: Obecnie warunki mogą być dodawane do wbudowanych lub niestandardowych przypisań ról, które mają **akcje danych przechowywania blobów lub akcje danych przechowywania kolejek**.
Zgodnie z **[dokumentacją](https://learn.microsoft.com/en-us/azure/role-based-access-control/conditions-role-assignments-portal)**: 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
@@ -316,9 +316,9 @@ Podobnie jak przypisania ról, **przypisania odmowy** są stosowane w określony
### 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 zapewnić, że wszystkie zasoby mają określone tagi do śledzenia.
**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ą zapobiegać tworzeniu lub zmianie zasobów, które nie są zgodne. Są również **reaktywne**, umożliwiając znajdowanie i naprawianie istniejących zasobów, które nie są zgodne.
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**
@@ -327,7 +327,7 @@ Polityki Azure są **proaktywne**: mogą zapobiegać tworzeniu lub zmianie zasob
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").
**Kilka przykładów:**
**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.
@@ -358,7 +358,7 @@ Przykład polityki Azure json:
```
### Dziedziczenie uprawnień
W Azure **uprawnienia mogą być przypisane do dowolnej części hierarchii**. Obejmuje to grupy zarządzania, subskrypcje, grupy zasobów oraz poszczególne zasoby. Uprawnienia są **dziedziczone** przez zawarte **zasoby** podmiotu, do którego zostały przypisane.
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.
@@ -4,7 +4,7 @@
## Phishing aplikacji OAuth
**Aplikacje Azure** są konfigurowane z uprawnieniami, które będą mogły być używane, gdy użytkownik wyrazi zgodę na aplikację (takimi jak enumeracja katalogu, dostęp do plików lub wykonywanie innych działań). Należy pamiętać, że aplikacja będzie działać w imieniu użytkownika, więc nawet jeśli aplikacja może prosić o uprawnienia administracyjne, jeśli **użytkownik, który wyraża zgodę, nie ma tych uprawnień**, aplikacja **nie będzie mogła wykonywać działań administracyjnych**.
**Aplikacje Azure** są konfigurowane z uprawnieniami, które będą mogły być używane, gdy użytkownik wyrazi zgodę na aplikację (takimi jak enumerowanie katalogu, dostęp do plików lub wykonywanie innych działań). Należy pamiętać, że aplikacja będzie działać w imieniu użytkownika, więc nawet jeśli aplikacja mogłaby prosić o uprawnienia administracyjne, jeśli **użytkownik, który wyraża zgodę, nie ma tych uprawnień**, aplikacja **nie będzie mogła wykonywać działań administracyjnych**.
### Uprawnienia zgody aplikacji
@@ -14,27 +14,27 @@ Domyślnie każdy **użytkownik może wyrazić zgodę na aplikacje**, chociaż m
Jeśli użytkownicy nie mogą wyrażać zgody, **administratorzy** tacy jak `GA`, `Administrator aplikacji` lub `Administrator aplikacji w chmurze` mogą **wyrażać zgodę na aplikacje**, z których użytkownicy będą mogli korzystać.
Co więcej, jeśli użytkownicy mogą wyrażać zgodę tylko na aplikacje z **niskim ryzykiem** uprawnień, te uprawnienia to domyślnie **openid**, **profil**, **email**, **User.Read** i **offline_access**, chociaż możliwe jest **dodanie więcej** do tej listy.
Co więcej, jeśli użytkownicy mogą wyrażać zgodę tylko na aplikacje z użyciem **niskiego ryzyka** uprawnień, te uprawnienia to domyślnie **openid**, **profil**, **email**, **User.Read** i **offline_access**, chociaż możliwe jest **dodanie więcej** do tej listy.
A jeśli mogą wyrażać zgodę na wszystkie aplikacje, mogą wyrażać zgodę na wszystkie aplikacje.
### 2 Typy ataków
### 2 typy ataków
- **Nieautoryzowany**: Z zewnętrznego konta utwórz aplikację z **niskim ryzykiem** uprawnień `User.Read` i `User.ReadBasic.All`, na przykład, phishinguj użytkownika, a będziesz mógł uzyskać dostęp do informacji katalogowych.
- To wymaga, aby phishingowany użytkownik był **w stanie zaakceptować aplikacje OAuth z zewnętrznego najemcy**.
- Jeśli phishingowany użytkownik jest jakimś administratorem, który może **wyrażać zgodę na każdą aplikację z dowolnymi uprawnieniami**, aplikacja może również **żądać uprawnień uprzywilejowanych**.
- **Autoryzowany**: Po skompromitowaniu podmiotu z wystarczającymi uprawnieniami, **utwórz aplikację w ramach konta** i **phishinguj** jakiegoś **uprzywilejowanego** użytkownika, który może zaakceptować uprzywilejowane uprawnienia OAuth.
- **Nieautoryzowany**: Z zewnętrznego konta utwórz aplikację z **niskim ryzykiem uprawnień** `User.Read` i `User.ReadBasic.All`, na przykład, phishinguj użytkownika, a będziesz mógł uzyskać dostęp do informacji katalogowych.
- To wymaga, aby phished użytkownik był **w stanie zaakceptować aplikacje OAuth z zewnętrznego najemcy**.
- Jeśli phished użytkownik jest jakimś administratorem, który może **wyrażać zgodę na każdą aplikację z dowolnymi uprawnieniami**, aplikacja może również **żądać uprawnień uprzywilejowanych**.
- **Autoryzowany**: Po skompromitowaniu podmiotu z wystarczającymi uprawnieniami, **utwórz aplikację wewnątrz konta** i **phishinguj** jakiegoś **uprzywilejowanego** użytkownika, który może zaakceptować uprzywilejowane uprawnienia OAuth.
- W tym przypadku możesz już uzyskać dostęp do informacji katalogowych, więc uprawnienie `User.ReadBasic.All` nie jest już interesujące.
- Prawdopodobnie interesują Cię **uprawnienia, które wymagają zgody administratora**, ponieważ zwykły użytkownik nie może przyznać aplikacjom OAuth żadnych uprawnień, dlatego musisz **phishingować tylko tych użytkowników** (więcej na temat ról/uprawnień, które przyznają to uprawnienie później).
### Użytkownicy mogą wyrażać zgodę
Zauważ, że musisz wykonać to polecenie z konta użytkownika wewnątrz najemcy, nie możesz znaleźć tej konfiguracji najemcy z zewnętrznego. Następujące polecenie CLI może pomóc Ci zrozumieć uprawnienia użytkowników:
Należy pamiętać, że musisz wykonać to polecenie z konta użytkownika wewnątrz najemcy, nie możesz znaleźć tej konfiguracji najemcy z zewnętrznego. Następujące cli mo pomóc Ci zrozumieć uprawnienia użytkowników:
```bash
az rest --method GET --url "https://graph.microsoft.com/v1.0/policies/authorizationPolicy"
```
- Użytkownicy mogą wyrażać zgodę na wszystkie aplikacje: Jeśli w **`permissionGrantPoliciesAssigned`** znajdziesz: `ManagePermissionGrantsForSelf.microsoft-user-default-legacy`, to użytkownicy mogą akceptować każdą aplikację.
- Użytkownicy mogą wyrażać zgodę na aplikacje od zweryfikowanych wydawców lub twojej organizacji, ale tylko na uprawnienia, które wybierzesz: Jeśli w **`permissionGrantPoliciesAssigned`** znajdziesz: `ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-team`, to użytkownicy mogą akceptować każdą aplikację.
- Użytkownicy mogą wyrażać zgodę na wszystkie aplikacje: Jeśli w **`permissionGrantPoliciesAssigned`** znajdziesz: `ManagePermissionGrantsForSelf.microsoft-user-default-legacy`, to użytkownicy mogą zaakceptować każdą aplikację.
- Użytkownicy mogą wyrażać zgodę na aplikacje od zweryfikowanych wydawców lub twojej organizacji, ale tylko na uprawnienia, które wybierzesz: Jeśli w **`permissionGrantPoliciesAssigned`** znajdziesz: `ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-team`, to użytkownicy mogą zaakceptować każdą aplikację.
- **Wyłącz zgodę użytkownika**: Jeśli w **`permissionGrantPoliciesAssigned`** znajdziesz tylko: `ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-chat` i `ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-team`, to użytkownicy nie mogą wyrażać zgody na żadne.
Możliwe jest znalezienie znaczenia każdej z komentowanych polityk w:
@@ -61,8 +61,8 @@ az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles/0d60
Atak składa się z kilku kroków, które mają na celu zaatakowanie ogólnej firmy. Oto jak może się to rozwinąć:
1. **Rejestracja Domeny i Hosting Aplikacji**: Atakujący rejestruje domenę przypominającą zaufaną stronę, na przykład "safedomainlogin.com". Pod tą domeną tworzona jest subdomena (np. "companyname.safedomainlogin.com"), aby hostować aplikację zaprojektowaną do przechwytywania kodów autoryzacyjnych i żądania tokenów dostępu.
2. **Rejestracja Aplikacji w Azure AD**: Atakujący następnie rejestruje aplikację wielo-tenantową w swoim dzierżawcy Azure AD, nazywając ją imieniem docelowej firmy, aby wyglądała na legalną. Konfiguruje URL przekierowania aplikacji, aby wskazywał na subdomenę hostującą złośliwą aplikację.
1. **Rejestracja Domeny i Hosting Aplikacji**: Atakujący rejestruje domenę przypominającą zaufaną stronę, na przykład "safedomainlogin.com". Pod tą domeną tworzony jest subdomena (np. "companyname.safedomainlogin.com"), aby hostować aplikację zaprojektowaną do przechwytywania kodów autoryzacyjnych i żądania tokenów dostępu.
2. **Rejestracja Aplikacji w Azure AD**: Atakujący następnie rejestruje aplikację wielo-tenantową w swoim dzierżawcy Azure AD, nadając jej nazwę odpowiadającą docelowej firmie, aby wyglądała na legalną. Konfiguruje URL przekierowania aplikacji, aby wskazywał na subdomenę hostującą złośliwą aplikację.
3. **Ustawienie Uprawnień**: Atakujący ustawia aplikację z różnymi uprawnieniami API (np. `Mail.Read`, `Notes.Read.All`, `Files.ReadWrite.All`, `User.ReadBasic.All`, `User.Read`). Te uprawnienia, po przyznaniu przez użytkownika, pozwalają atakującemu na wyciąganie wrażliwych informacji w imieniu użytkownika.
4. **Dystrybucja Złośliwych Linków**: Atakujący tworzy link zawierający identyfikator klienta złośliwej aplikacji i dzieli się nim z docelowymi użytkownikami, oszukując ich, aby przyznali zgodę.
@@ -88,7 +88,7 @@ python3 azure_oauth_phishing_example.py --client-secret <client-secret> --client
```
5. **Wyślij URL do ofiary**
1. W tym przypadku `http://localhost:8000`
6. **Ofiary** muszą **zaakceptować monit:**
6. **Ofiary** muszą **zaakceptować komunikat:**
<figure><img src="../../../images/image (4).png" alt=""><figcaption></figcaption></figure>
@@ -125,9 +125,16 @@ https://graph.microsoft.com/v1.0/me/onenote/notebooks \
W zależności od żądanych uprawnień możesz być w stanie **uzyskać dostęp do różnych danych najemcy** (lista użytkowników, grup... lub nawet modyfikować ustawienia) oraz **informacji o użytkowniku** (pliki, notatki, e-maile...). Następnie możesz wykorzystać te uprawnienia do wykonania tych działań.
### Administrator aplikacji Entra ID
Jeśli udało ci się w jakiś sposób skompromitować główny identyfikator Entra ID, który może zarządzać aplikacjami w Entra ID, a są aplikacje używane przez użytkowników najemcy. Administrator mógłby **zmodyfikować uprawnienia, o które prosi aplikacja, i dodać nowy dozwolony adres przekierowania, aby ukraść tokeny**.
- Zauważ, że możliwe jest **dodanie URI przekierowania** (nie ma potrzeby usuwania prawdziwego) i następnie wysłanie linku HTTP z użyciem URI przekierowania atakującego, aby gdy użytkownik kliknie link, uwierzytelnienie odbywało się automatycznie, a atakujący otrzymuje token.
- Możliwe jest również zmienienie uprawnień, o które prosi aplikacja, aby uzyskać więcej uprawnień od użytkowników, ale w takim przypadku użytkownik będzie musiał **ponownie zaakceptować monit** (nawet jeśli był już zalogowany).
- Aby przeprowadzić ten atak, atakujący **NIE MUSI** kontrolować kodu aplikacji, ponieważ mógłby po prostu wysłać link do logowania w aplikacji do użytkownika z nowym URL w parametrze **`redirect_uri`**.
### Aplikacja po eksploatacji
Sprawdź sekcje Aplikacje i Główne zasady usługi na stronie:
Sprawdź sekcje Aplikacje i Główne Identyfikatory Usług na stronie:
{{#ref}}
../az-privilege-escalation/az-entraid-privesc/