diff --git a/src/pentesting-cloud/azure-security/az-basic-information/README.md b/src/pentesting-cloud/azure-security/az-basic-information/README.md index c089c7e46..e8750d2fa 100644 --- a/src/pentesting-cloud/azure-security/az-basic-information/README.md +++ b/src/pentesting-cloud/azure-security/az-basic-information/README.md @@ -46,7 +46,7 @@ Dla maszyny wirtualnej o nazwie myVM w grupie zasobów `myResourceGroup` pod sub - `/subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM` -## Azure vs Entra ID vs Azure AD Domain Services +## Azure vs Entra ID vs Usługi domenowe Azure AD ### Azure @@ -54,25 +54,25 @@ Azure to kompleksowa **platforma chmurowa Microsoftu, oferująca szeroki zakres ### Entra ID (dawniej 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 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. +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. -### Entra Domain Services (dawniej Azure AD DS) +### Usługi domenowe Entra (dawniej Azure AD DS) -Entra Domain Services rozszerza możliwości Entra ID, oferując **zarządzane usługi domenowe zgodne z tradycyjnymi środowiskami Windows Active Directory**. Obsługuje 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. +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ę, stanowisko, dane kontaktowe…) +- Wskazanie nazwy e-mail i domeny z wybranego najemcy +- Wskazanie nazwy wyświetlanej +- Wskazanie hasła +- Wskazanie 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 Microsoftem) -- Wskaźnik właściwości +- Wskazanie e-maila do zaproszenia i nazwy wyświetlanej (może być to e-mail niebędący Microsoftem) +- Wskazanie właściwości - Domyślny typ użytkownika to “**Gość**” ### Domyślne uprawnienia członków i gości @@ -94,14 +94,14 @@ Możesz je sprawdzić w [https://learn.microsoft.com/en-us/entra/fundamentals/us - **Członkowie (**[**dokumentacja**](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** +- 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 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) +- Pokazanie, 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) +- Czytanie 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**. @@ -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żytkownik zewnętrzny opuszcza**: Domyślnie **Prawda** -- Zezwolenie użytkownikom zewnętrznym na opuszczenie organizacji +- **Użytkownicy zewnętrzni mogą odejść**: Domyślnie **Prawda** +- Zezwolenie użytkownikom zewnętrznym na odejście z 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,13 +123,13 @@ 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. -- **Dynamiczne członkostwo**: Automatycznie zarządza członkostwem za pomocą reguł, aktualizując włączenie grupy, gdy atrybuty członków się zmieniają. +- **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** @@ -137,7 +137,7 @@ Istnieją **2 typy członkostw**: 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 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 @@ -148,8 +148,8 @@ 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 federowane poświadczenia:** 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ę** (domenę lub ID). +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). +1. Jeśli **certyfikat** lub **sekret** zostanie wygenerowany, osoba może **zalogować się jako zasada usługi** za pomocą narzędzi CLI, znając **identyfikator aplikacji**, **sekret** lub **certyfikat** oraz **najemcę** (domenę 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). 6. **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. @@ -161,15 +161,15 @@ 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 dla aplikacji od zweryfikowanych wydawców, dla wybranych uprawnień (zalecane)** +- **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 o niskim wpływie (chociaż musisz zaakceptować, aby dodać je jako niskie): - User.Read - zaloguj się i przeczytaj profil użytkownika - offline_access - utrzymuj dostęp do danych, do których użytkownicy udzielili dostępu -- openid - loguj użytkowników +- 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)** +- **Zezwól na zgodę użytkownika na aplikacje (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** @@ -187,17 +187,17 @@ Istnieją dwa typy zarządzanych tożsamości: - **Przypisana przez system**. 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ą przez system, **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 zasada usługi do niej przypisana. +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. +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 -Jednostki administracyjne pozwalają na **przyznawanie uprawnień z roli nad określoną częścią organizacji**. +Jednostki administracyjne pozwalają na **przyznawanie uprawnień z roli nad konkretną częścią organizacji**. Przykład: @@ -214,26 +214,26 @@ Przykład: ### Role Entra ID -- Aby zarządzać Entra ID, istnieje kilka **wbudowanych ról**, które można przypisać do głównych Entra ID w celu zarządzania Entra ID +- Aby zarządzać Entra ID, istnieje kilka **wbudowanych ról**, 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) - Najbardziej uprzywilejowaną rolą jest **Globalny administrator** - W opisie roli można zobaczyć jej **szczegółowe uprawnienia** ## Role i uprawnienia -**Role** są **przypisywane** do **głównych** w **zakresie**: `principal -[HAS ROLE]->(scope)` +**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. -### **Klasyczne role** +### Klasyczne role | **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 | +| **Czytelnik** | • Wyświetlanie wszystkich zasobów | Wszystkie typy zasobów | +| **Administrator dostępu użytkowników** | | Wszystkie typy zasobów | ### Wbudowane role @@ -241,11 +241,11 @@ W zależności od zakresu, do którego przypisano rolę, **rola** może być **d **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 uprawnienie do kopii zapasowej, aby wykonać kopię zapasową 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 uprawnienie do skarbczyka kopii zapasowej do wykonywania kopii zapasowych 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 | +| [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świetlanie maszyn wirtualnych w portalu i logowanie 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 dotknięte zasady będą miały je **nad zasobami 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, 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**](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). @@ -253,14 +253,16 @@ Te role mogą **być również przypisane do logicznych kontenerów** (takich ja ### Niestandardowe role - Możliwe jest również tworzenie [**niestandardowych ról**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles) -- Są one tworzone wewnątrz zakresu, chociaż rola może być w kilku zakresach (grupy zarządzające, subskrypcje i grupy zasobów) +- 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ń -- Główny z wykluczonym uprawnieniem nie będzie mógł go używać, nawet jeśli uprawnienie jest przyznawane gdzie indziej +- 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` są do kontrolowania działań nad zasobem -- `dataActions` to uprawnienia do danych w obiekcie +- `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 na danych w obrębie zasobu, pozwalające na 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: ```json @@ -294,8 +296,8 @@ Przykład uprawnień JSON dla niestandardowej roli: ``` ### Kolejność uprawnień -- 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. +- 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

@@ -303,36 +305,53 @@ 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 główną**. 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**. Dzięki temu 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)
-### Polityki Azure +### Warunki przypisania i MFA -**Polityki Azure** to zasady, które pomagają organizacjom zapewnić, że ich zasoby spełniają określone standardy i wymagania 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. +Możliwe jest **ustalenie pewnych warunków, gdy rola jest przypisywana** do podmiotu. Powszechnym warunkiem do dodania jest wymóg MFA do uzyskania dostępu do niektórych uprawnień roli: +```bash +az role assignment create \ +--assignee \ +--role \ +--scope "/subscriptions/9291ff6e-6afb-430e-82a4-6f04b2d05c7f" \ +--condition "PrincipalClaims['amr'] contains 'mfa'" \ +--condition-version 2.0 +``` +### Deny Assignments -Polityki Azure są **proaktywne**: mogą zatrzymać tworzenie lub zmianę zasobów, które nie są zgodne. Są również **reaktywne**, pozwalając na znalezienie i naprawienie istniejących zasobów niezgodnych. +Podobnie jak przypisania ról, **deny assignments** są używane do **kontrolowania dostępu do zasobów Azure**. Jednak **deny assignments** są używane do **wyraźnego odmawiania dostępu** do zasobu, nawet jeśli użytkownik uzyskał dostęp poprzez przypisanie roli. **Deny assignments** mają pierwszeństwo przed **role assignments**, co oznacza, że jeśli użytkownik uzyskał dostęp poprzez przypisanie roli, ale również wyraźnie odmówiono mu dostępu poprzez deny assignment, deny assignment będzie miało pierwszeństwo. -#### **Kluczowe pojęcia** +Podobnie jak przypisania ról, **deny assignments** są stosowane w określonym zakresie, wskazując na dotknięte podmioty i uprawnienia, które są odmawiane. Co więcej, w przypadku deny assignments możliwe jest **zapobieżenie dziedziczeniu odmowy** przez zasoby podrzędne. -1. **Definicja polityki**: Zasada napisana w JSON, która określa, co jest dozwolone lub wymagane. -2. **Przydział 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"). +### Azure Policies -**Kilka przykładów:** +**Azure Policies** 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. -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. +Azure Policies są **proaktywne**: mogą zapobiegać tworzeniu lub zmianie 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. + +#### **Key Concepts** + +1. **Policy Definition**: Zasada, napisana w JSON, która określa, co jest dozwolone lub wymagane. +2. **Policy Assignment**: Zastosowanie zasady do określonego zakresu (np. subskrypcja, grupa zasobów). +3. **Initiatives**: Zbiór polityk zgrupowanych razem w celu szerszej egzekucji. +4. **Effect**: Określa, co się dzieje, gdy zasada jest wyzwalana (np. "Deny", "Audit" lub "Append"). + +**Some examples:** + +1. **Ensuring Compliance with Specific Azure Regions**: Ta zasada 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. **Enforcing Naming Standards**: 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. **Restricting Certain Resource Types**: Ta zasada może ograniczać 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. **Enforcing Tagging Policies**: 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. **Limiting Public Access to Resources**: 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. **Automatically Applying Security Settings**: 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 głównej grupie zarządzania** lub w innych grupach zarządzania. -Przykład polityki Azure json: +Azure policy json example: ```json { "policyRule": { @@ -364,7 +383,7 @@ Ta struktura hierarchiczna umożliwia efektywne i skalowalne zarządzanie uprawn 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**. +**Nie możesz** wyraźnie **odmówić** **dostępu** do konkretnych zasobów **za pomocą warunków**. ## Odniesienia