mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-29 07:00:29 -07:00
Translated ['src/pentesting-cloud/azure-security/az-basic-information/RE
This commit is contained in:
@@ -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.
|
||||
|
||||
@@ -123,7 +123,7 @@ 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łonkowie grupy mogą być tylko użytkownikami.
|
||||
- **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**:
|
||||
@@ -133,7 +133,7 @@ Istnieją **2 typy członkostw**:
|
||||
|
||||
### **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** 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).
|
||||
|
||||
@@ -149,7 +149,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).
|
||||
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).
|
||||
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ę** (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).
|
||||
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.
|
||||
@@ -164,7 +164,7 @@ Możliwe jest **bezpośrednie logowanie jako zasada usługi** poprzez wygenerowa
|
||||
- **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
|
||||
- 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
|
||||
@@ -197,7 +197,7 @@ To po prostu **tabela w Azure do filtrowania zasad usług** i sprawdzania aplika
|
||||
|
||||
### Jednostki administracyjne
|
||||
|
||||
Jednostki administracyjne pozwalają na **przyznawanie uprawnień z roli nad konkretną częścią organizacji**.
|
||||
Jednostki administracyjne pozwalają na **przyznawanie uprawnień z roli nad określoną częścią organizacji**.
|
||||
|
||||
Przykład:
|
||||
|
||||
@@ -232,8 +232,8 @@ W zależności od zakresu, do którego przypisano rolę, **rola** może być **d
|
||||
| **Właściciel** | <ul><li>Pełny dostęp do wszystkich zasobów</li><li>Może zarządzać dostępem dla innych użytkowników</li></ul> | Wszystkie typy zasobów |
|
||||
| ----------------------------- | ---------------------------------------------------------------------------------------- | ------------------ |
|
||||
| **Współtwórca** | <ul><li>Pełny dostęp do wszystkich zasobów</li><li>Nie może zarządzać dostępem</li></ul> | Wszystkie typy zasobów |
|
||||
| **Czytelnik** | • Wyświetlanie wszystkich zasobów | Wszystkie typy zasobów |
|
||||
| **Administrator dostępu użytkowników** | <ul><li>Wyświetlanie wszystkich zasobów</li><li>Może zarządzać dostępem dla innych użytkowników</li></ul> | Wszystkie typy zasobów |
|
||||
| **Czytelnik** | • Wyświetl wszystkie zasoby | Wszystkie typy zasobów |
|
||||
| **Administrator dostępu użytkowników** | <ul><li>Wyświetl wszystkie zasoby</li><li>Może zarządzać dostępem dla innych użytkowników</li></ul> | Wszystkie typy zasobów |
|
||||
|
||||
### Wbudowane role
|
||||
|
||||
@@ -241,9 +241,9 @@ 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 skarbczyka kopii zapasowej do wykonywania kopii zapasowych 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 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świetlanie maszyn wirtualnych w portalu i logowanie 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świetl maszyny wirtualne w portalu i zaloguj się jako zwykły użytkownik. | fb879df8-f326-4884-b1cf-06f3ad86be52 |
|
||||
|
||||
Te role mogą **być również przypisane do logicznych kontenerów** (takich jak grupy zarządzające, subskrypcje i grupy zasobów), a zasady, które są nimi objęte, będą miały je **nad zasobami wewnątrz tych kontenerów**.
|
||||
|
||||
@@ -253,7 +253,7 @@ 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)
|
||||
- Tworzone są wewnątrz zakresu, chociaż rola może być w kilku zakresach (grupy zarządzające, subskrypcje i grupy zasobów)
|
||||
- Są one tworzone wewnątrz zakresu, chociaż rola może być w kilku zakresach (grupy zarządzające, subskrypcje i grupy zasobów)
|
||||
- Możliwe jest skonfigurowanie wszystkich szczegółowych uprawnień, które będzie miała niestandardowa rola
|
||||
- Możliwe jest wykluczenie uprawnień
|
||||
- Zasada z wykluczonym uprawnieniem nie będzie mogła go używać, nawet jeśli uprawnienie jest przyznawane gdzie indziej
|
||||
@@ -305,53 +305,46 @@ 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
|
||||
|
||||
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 <user-or-service-principal-id> \
|
||||
--role <custom-role-id-or-name> \
|
||||
--scope "/subscriptions/9291ff6e-6afb-430e-82a4-6f04b2d05c7f" \
|
||||
--condition "PrincipalClaims['amr'] contains 'mfa'" \
|
||||
--condition-version 2.0
|
||||
```
|
||||
### Deny Assignments
|
||||
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**.
|
||||
|
||||
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.
|
||||
### Przypisania odmowy
|
||||
|
||||
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.
|
||||
Podobnie jak przypisania ról, **przypisania odmowy** są używane do **kontrolowania dostępu do zasobów Azure**. Jednak **przypisania odmowy** są używane do **wyraźnego odmawiania dostępu** do zasobu, nawet jeśli użytkownik uzyskał dostęp poprzez przypisanie roli. **Przypisania odmowy** mają pierwszeństwo przed **przypisaniami ról**, co oznacza, że jeśli użytkownik uzyskał dostęp poprzez przypisanie roli, ale również wyraźnie odmówiono mu dostępu poprzez przypisanie odmowy, przypisanie odmowy będzie miało pierwszeństwo.
|
||||
|
||||
### Azure Policies
|
||||
Podobnie jak przypisania ról, **przypisania odmowy** są stosowane w określonym zakresie, wskazując dotknięte podmioty i uprawnienia, które są odmawiane. Ponadto, w przypadku przypisań odmowy, możliwe jest **zapobieżenie dziedziczeniu odmowy** przez zasoby podrzędne.
|
||||
|
||||
**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.
|
||||
### Polityki Azure
|
||||
|
||||
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.
|
||||
**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.
|
||||
|
||||
#### **Key Concepts**
|
||||
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.
|
||||
|
||||
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").
|
||||
#### **Kluczowe pojęcia**
|
||||
|
||||
**Some examples:**
|
||||
1. **Definicja polityki**: Zasada, napisana w JSON, która określa, co jest dozwolone lub wymagane.
|
||||
2. **Przypisanie polityki**: Zastosowanie polityki do określonego zakresu (np. subskrypcja, grupa zasobów).
|
||||
3. **Inicjatywy**: Zbiór polityk zgrupowanych razem w celu szerszej egzekucji.
|
||||
4. **Efekt**: Określa, co się dzieje, gdy polityka jest wyzwalana (np. "Odmów", "Audyt" lub "Dodaj").
|
||||
|
||||
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.
|
||||
**Kilka przykładów:**
|
||||
|
||||
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.
|
||||
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 policy json example:
|
||||
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:
|
||||
```json
|
||||
{
|
||||
"policyRule": {
|
||||
@@ -382,8 +375,8 @@ Ta struktura hierarchiczna umożliwia efektywne i skalowalne zarządzanie uprawn
|
||||
**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**.
|
||||
Azure **ABAC** (kontrola dostępu oparta na atrybutach) opiera się na Azure RBAC, dodając **warunki przypisania ról oparte na atrybutach** w kontekście konkretnych działań. _Warunek przypisania roli_ to **dodatkowa kontrola, którą możesz opcjonalnie dodać do swojego przypisania roli**, aby zapewnić bardziej szczegółową kontrolę dostępu. Warunek filtruje uprawnienia przyznawane jako część definicji roli i przypisania roli. Na przykład, możesz **dodać warunek, który wymaga, aby obiekt miał określony tag, aby go odczytać**.\
|
||||
Nie **możesz** wyraźnie **odmówić** **dostępu** do konkretnych zasobów **za pomocą warunków**.
|
||||
|
||||
## Odniesienia
|
||||
|
||||
|
||||
Reference in New Issue
Block a user