Az - Basic Information
Hierarchia organizacji
Grupy zarządzające
Jeśli Twoja organizacja ma wiele subskrypcji Azure, możesz potrzebować sposobu na efektywne zarządzanie dostępem, politykami i zgodnością dla tych subskrypcji. Grupy zarządzające zapewniają zakres zarządzania ponad subskrypcjami.
Zauważ, że w jednej katalogu można obsługiwać 10 000 grup zarządzających, a drzewo grup zarządzających może obsługiwać do sześciu poziomów głębokości.
Z dokumentacji: Każdemu katalogowi przypisywana jest jedna grupa zarządzająca najwyższego poziomu zwana grupą zarządzającą główną. Grupa zarządzająca główna jest wbudowana w hierarchię, aby wszystkie grupy zarządzające i subskrypcje były do niej przypisane. Ta grupa zarządzająca główna umożliwia stosowanie globalnych polityk i przypisań ról Azure na poziomie katalogu. Azure AD Global Administrator musi początkowo podnieść swoje uprawnienia do roli Administratora dostępu użytkowników tej grupy głównej. Po podniesieniu dostępu, administrator może przypisać dowolną rolę Azure innym użytkownikom lub grupom katalogu, aby zarządzać hierarchią. Jako administrator możesz przypisać swoje własne konto jako właściciela grupy zarządzającej głównej.
Grupa zarządzająca główna nie może być przenoszona ani usuwana, w przeciwieństwie do innych grup zarządzających.
Grupy zarządzające zapewniają zarządzanie na poziomie przedsiębiorstwa w skali, niezależnie od rodzaju subskrypcji, które możesz mieć. Jednak wszystkie subskrypcje w jednej grupie zarządzającej muszą ufać temu samemu dzierżawcy Azure Active Directory (Azure AD).
Subskrypcje Azure
W Azure subskrypcja służy jako logiczny kontener w celu provisioning zasobów biznesowych lub technicznych. Ten kontener utrzymuje szczegóły zasobów takich jak maszyny wirtualne (VM), bazy danych i inne. Przy tworzeniu zasobu Azure, takiego jak VM, określa się subskrypcję z nim powiązaną. Ta struktura ułatwia delegację dostępu, wykorzystując mechanizmy kontroli dostępu oparte na rolach.
Grupy zasobów
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.
Jednostki administracyjne
Z dokumentacji: Jednostki administracyjne pozwalają Ci podzielić swoją organizację na dowolne jednostki, które chcesz, a następnie przypisać konkretnych administratorów, którzy mogą zarządzać tylko członkami tej jednostki. Na przykład, możesz użyć jednostek administracyjnych do delegowania uprawnień administratorom każdej szkoły na dużym uniwersytecie, aby mogli kontrolować dostęp, zarządzać użytkownikami i ustalać polityki tylko w Szkole Inżynierii.
Tylko użytkownicy, grupy i urządzenia mogą być członkami jednostki administracyjnej.
Dlatego jednostka administracyjna będzie zawierać pewnych członków, a inne podmioty będą miały przypisane uprawnienia do tej jednostki administracyjnej, które mogą wykorzystać do zarządzania członkami jednostki administracyjnej.
Azure vs Azure AD vs Azure AD Domain Services
Ważne jest, aby zauważyć, że Azure AD to usługa wewnątrz Azure. Azure to platforma chmurowa Microsoftu, podczas gdy Azure AD to usługa tożsamości przedsiębiorstwa w Azure. Ponadto, Azure AD nie jest jak Windows Active Directory, to usługa tożsamości, która działa w zupełnie inny sposób. Jeśli chcesz uruchomić Kontroler Domeny w Azure dla swojego środowiska Windows Active Directory, musisz użyć Azure AD Domain Services.
Podmioty
Azure obsługuje różne typy podmiotów:
Użytkownik: Zwykła osoba z poświadczeniami do dostępu.
Grupa: Grupa podmiotów zarządzana razem. Uprawnienia przyznane grupom są dziedziczone przez jej członków.
Service Principal/Enterprise Applications: To tożsamość stworzona do użytku z aplikacjami, usługami hostowanymi i narzędziami automatycznymi 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 podmiotów usługowych z narzędziami automatycznymi, zamiast pozwalać im logować się za pomocą tożsamości użytkownika.
Podczas tworzenia podmiotu usługowego możesz wybrać między uwierzytelnianiem hasłem a uwierzytelnianiem certyfikatem.
Jeśli wybierzesz uwierzytelnianie hasłem (domyślnie), zapisz wygenerowane hasło, ponieważ nie będziesz mógł uzyskać do niego dostępu ponownie.
Jeśli wybierzesz uwierzytelnianie certyfikatem, upewnij się, że aplikacja będzie miała dostęp do klucza prywatnego.
Zarządzana tożsamość (Metadane poświadczeń): 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). Dzięki wykorzystaniu zarządzanych tożsamości aplikacje mogą zabezpieczać tokeny Azure AD, eliminując potrzebę bezpośredniego zarządzania poświadczeniami. 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, tożsamość jest tworzona w Azure AD. Tożsamość jest powiązana z cyklem życia tej instancji usługi. Gdy zasób zostanie usunięty, Azure automatycznie usuwa tożsamość za Ciebie. Z założenia tylko ten zasób Azure może używać tej tożsamości do żądania tokenów z Azure AD.
Przypisane przez użytkownika. Możesz również stworzyć zarządzaną tożsamość jako samodzielny zasób Azure. Możesz utworzyć zarządzaną tożsamość przypisaną przez użytkownika i przypisać ją 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ą.
Role i uprawnienia
Role są przypisywane do podmiotów w zakresie: podmiot -[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 przez inne zasoby 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.
Klasyczne role
Właściciel |
| Wszystkie typy zasobów |
Współtwórca |
| 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
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, podmiotów usługowych 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:
Zapewnia uprawnienia do kopii zapasowej skarbczyka do wykonania kopii zapasowej dysku. | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 | |
Wyświetlanie maszyn wirtualnych w portalu i logowanie 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 podmioty, które są nimi objęte, będą miały je w odniesieniu do zasobów wewnątrz tych kontenerów.
Znajdź tutaj listę z wszystkimi wbudowanymi rolami Azure.
Znajdź tutaj listę z wszystkimi wbudowanymi rolami Azure AD.
Niestandardowe role
Azure pozwala również na tworzenie niestandardowych ról z uprawnieniami, których potrzebuje użytkownik.
Odrzucone uprawnienia
Aby podmiot miał dostęp do zasobu, musi mieć przyznaną mu wyraźną rolę (w jakikolwiek sposób) przyznając mu to uprawnienie.
Wyraźne przypisanie roli odrzucającej ma pierwszeństwo przed rolą przyznającą uprawnienie.
Globalny administrator
Użytkownicy z rolą Globalnego Administratora mają możliwość 'podniesienia' do roli Administratora dostępu użytkowników w grupie zarządzającej głównej. Oznacza to, że Globalny Administrator będzie mógł zarządzać dostępem do wszystkich subskrypcji Azure i grup zarządzających. To podniesienie można wykonać na końcu strony: https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties
Polityki Azure
Polityki Azure to zestaw reguł i przepisów w Microsoft Azure, usłudze chmurowej, które pomagają zarządzać i egzekwować standardy organizacyjne oraz oceniać zgodność na dużą skalę. Te polityki egzekwują różne zasady dotyczące Twoich zasobów Azure, zapewniając, że te zasoby pozostają zgodne z normami korporacyjnymi i umowami o poziomie usług.
Polityki Azure są kluczowe dla zarządzania chmurą i bezpieczeństwa, pomagając zapewnić, że zasoby są używane prawidłowo i efektywnie oraz że są zgodne z regulacjami zewnętrznymi i politykami wewnętrznymi. Oto 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, aby kontrolować koszty.
Egzekwowanie polityk tagowania: Tagi to pary klucz-wartość powią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. To jest 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.
Zauważ, że polityki Azure mogą być przypisane do dowolnego poziomu hierarchii Azure, ale są najczęściej używane w grupie zarządzającej głównej lub w innych grupach zarządzających.
Zakres uprawnień
W Azure uprawnienia mogą być przypisane do dowolnej części hierarchii. Obejmuje to grupy zarządzające, subskrypcje, grupy zasobów i poszczególne zasoby. Uprawnienia są dziedziczone przez zawarte zasoby podmiotu, do którego zostały przypisane.
Ta hierarchiczna struktura pozwala na efektywne i skalowalne zarządzanie uprawnieniami dostępu.
Azure RBAC vs ABAC
RBAC (kontrola dostępu oparta na rolach) to to, co już widzieliśmy w poprzednich sekcjach: Przypisanie roli do podmiotu, aby przyznać mu dostęp 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 określonych działań. Warunek przypisania roli to dodatkowa kontrola, którą możesz opcjonalnie dodać do 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 odrzucić dostępu do określonych zasobów za pomocą warunków.
Domyślne uprawnienia użytkownika
Podstawowy użytkownik będzie miał pewne domyślne uprawnienia do enumeracji niektórych części AzureAD:
Odczyt wszystkich użytkowników, grup, aplikacji, urządzeń, ról, subskrypcji i ich publicznych właściwości
Zapraszanie gości (może być wyłączone)
Tworzenie grup zabezpieczeń
Odczyt nieukrytych członkostw grup
Dodawanie gości do posiadanych grup
Tworzenie nowej aplikacji (może być wyłączone)
Dodawanie do 50 urządzeń do Azure (może być wyłączone)
Pełną listę domyślnych uprawnień użytkowników znajdziesz w dokumentacji. Ponadto zauważ, że na tej liście możesz również zobaczyć listę domyślnych uprawnień gości.
Pamiętaj, że aby enumerować zasoby Azure, użytkownik potrzebuje wyraźnego przyznania uprawnienia.
Zarządzanie tożsamościami uprzywilejowanymi (PIM)
Zarządzanie tożsamościami uprzywilejowanymi (PIM) w Azure to narzędzie, które zarządza, kontroluje i monitoruje uprzywilejowany dostęp w Azure Active Directory i Azure. Zwiększa bezpieczeństwo, zapewniając dostęp uprzywilejowany na żądanie i ograniczony czas, egzekwując procesy zatwierdzania i wymagając dodatkowej autoryzacji. Takie podejście minimalizuje ryzyko nieautoryzowanego dostępu, zapewniając, że podwyższone uprawnienia są przyznawane tylko wtedy, gdy jest to konieczne i na określony czas.
Tokeny uwierzytelniające
Istnieją trzy typy tokenów używanych w OIDC:
Tokeny dostępu: Klient przedstawia ten token serwerowi zasobów, aby uzyskać dostęp do zasobów. Może być używany tylko dla określonej kombinacji użytkownika, klienta i zasobu i nie może być unieważniony do momentu wygaśnięcia - co trwa 1 godzinę domyślnie. Wykrywalność jest niska przy użyciu tego.
Tokeny ID: Klient otrzymuje ten token od serwera autoryzacji. Zawiera podstawowe informacje o użytkowniku. Jest powiązany z określoną kombinacją użytkownika i klienta.
Tokeny odświeżania: Przyznawane klientowi wraz z tokenem dostępu. Używane do uzyskiwania nowych tokenów dostępu i ID. Jest powiązany z określoną kombinacją użytkownika i klienta i może być unieważniony. Domyślne wygaśnięcie to 90 dni dla nieaktywnych tokenów odświeżania i brak wygaśnięcia dla aktywnych tokenów.
Informacje o dostępie warunkowym są przechowywane wewnątrz JWT. Więc jeśli żądasz tokena z dozwolonego adresu IP, ten adres IP zostanie przechowany w tokenie, a następnie możesz użyć tego tokena z niedozwolonego adresu IP, aby uzyskać dostęp do zasobów.
Sprawdź następującą stronę, aby poznać różne sposoby żądania tokenów dostępu i logowania się z ich pomocą:
Az - AzureAD (AAD)Najczęstsze punkty końcowe API to:
Azure Resource Manager (ARM): management.azure.com
Microsoft Graph: graph.microsoft.com (Azure AD Graph, który jest przestarzały, to graph.windows.net)
Odnośniki
Last updated
