Az - Basic Information
Hierarchia Organizacyjna
Grupy Zarządzania
Jeśli twoja organizacja ma wiele subskrypcji Azure, możesz potrzebować sposobu efektywnego zarządzania dostępem, politykami i zgodnością dla tych subskrypcji. Grupy zarządzania zapewniają zakres zarządzania powyżej subskrypcji.
Należy zauważyć, że w jednym katalogu można obsłużyć 10 000 grup zarządzania, a drzewo grupy zarządzania może obsługiwać do sześciu poziomów głębokości.
Z dokumentacji: Każdy katalog otrzymuje pojedynczą nadrzędną grupę zarządzania o nazwie root. Grupa zarządzania root jest wbudowana w hierarchię, aby wszystkie grupy zarządzania i subskrypcje zagnieżdżały się w niej. Ta grupa zarządzania root umożliwia stosowanie globalnych polityk i przypisywanie ról Azure na poziomie katalogu. Globalny administrator Azure AD musi podnieść swoje uprawnienia do roli administratora dostępu użytkownika tej grupy root początkowo. Po podniesieniu uprawnień administrator może przypisać dowolną rolę Azure innym użytkownikom lub grupom katalogowym do zarządzania hierarchią. Jako administrator możesz przypisać swoje własne konto jako właściciela grupy zarządzania root.
Grupa zarządzania root nie może być przeniesiona ani usunięta, w przeciwieństwie do innych grup zarządzania.
Grupy zarządzania zapewniają zarządzanie na poziomie przedsiębiorstwa w skali, niezależnie od rodzaju subskrypcji, jakie możesz mieć. Jednakże wszystkie subskrypcje w ramach jednej grupy zarządzania muszą ufać temu samemu Azure Active Directory (Azure AD).
Subskrypcje Azure
W Azure subskrypcja służy jako kontener logiczny do dostarczania zasobów biznesowych lub technicznych. Ten kontener przechowuje szczegóły zasobów, takich jak maszyny wirtualne (VM), bazy danych, między innymi. Po utworzeniu zasobu Azure, takiego jak VM, określana jest powiązana z nim subskrypcja. Ta struktura ułatwia delegowanie 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 w Azure. Grupa zasobów może zawierać wszystkie zasoby dla rozwiązania lub tylko te zasoby, które chcesz zarządzać jako grupę. Zazwyczaj dodaje się zasoby, które mają ten sam cykl życia do tej samej grupy zasobów, aby można było je łatwo wdrażać, aktualizować i usuwać jako grupę.
Wszystkie zasoby muszą być wewnątrz 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ą podzielić twoją organizację na dowolne jednostki, które chcesz, a następnie przypisać określonym administratorom, którzy mogą zarządzać tylko członkami tej jednostki. Na przykład można użyć jednostek administracyjnych do delegowania uprawnień do administratorów każdej szkoły na dużej uczelni, aby mogli oni kontrolować dostęp, zarządzać użytkownikami i ustawiać polityki tylko w Wydziale Inżynierii.
Tylko użytkownicy, grupy i urządzenia mogą być członkami jednostki administracyjnej.
Dlatego jednostka administracyjna będzie zawierać pewne członków, a inni podmioty zostaną przypisane uprawnienia do tej jednostki administracyjnej, które mogą wykorzystać do zarządzania członkami jednostki administracyjnej.
Azure vs Azure AD vs Usługi domenowe Azure AD
Warto zauważyć, że Azure AD to usługa wewnątrz Azure. Azure to platforma chmurowa firmy Microsoft, podczas gdy Azure AD to usługa tożsamościowa dla przedsiębiorstw w Azure. Ponadto Azure AD nie jest jak Windows Active Directory, to usługa tożsamościowa, 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ć Usług domenowych Azure AD.
Podmioty
Azure obsługuje różne rodzaje podmiotów:
Użytkownik: Zwykła osoba z danymi uwierzytelniającymi do dostępu.
Grupa: Grupa podmiotów zarządzana razem. Uprawnienia przyznane grupom są dziedziczone przez jej członków.
Podmiot usługi/Aplikacje przedsiębiorstwa: To tożsamość utworzona do używania z aplikacjami, usługami hostowanymi i narzędziami automatyzacji do dostępu do zasobów Azure. Ten dostęp jest ograniczony przez przypisane role do podmiotu usługi, dając kontrolę nad które zasoby mogą być dostępne i na jakim poziomie. Z przyczyn bezpieczeństwa zawsze zaleca się używanie podmiotów usługi z narzędziami automatyzacji zamiast pozwalania im na logowanie się za pomocą tożsamości użytkownika.
Tworząc podmiot usługi możesz wybrać między uwierzytelnianiem hasłem lub uwierzytelnianiem certyfikatem.
Jeśli wybierzesz uwierzytelnianie hasłem (domyślnie), zapisz wygenerowane hasło, ponieważ nie będziesz mógł uzyskać do niego ponownie.
Jeśli wybierzesz uwierzytelnianie certyfikatem, upewnij się, że aplikacja będzie miała dostęp do klucza prywatnego.
Tożsamość zarządzana (Dane uwierzytelniające metadanych): Tożsamości zarządzane 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 z zasobami zgodnymi z uwierzytelnianiem Azure Active Directory (Azure AD). Korzystając z tożsamości zarządzanych, aplikacje mogą zabezpieczać tokeny Azure AD, eliminując konieczność bezpośredniego zarządzania danymi uwierzytelniającymi. Istnieją dwa rodzaje tożsamości zarządzanych:
Przypisane przez system. Niektóre usługi Azure pozwalają włączyć tożsamość zarządzaną bezpośrednio na instancji usługi. Po włączeniu przypisanej przez system tożsamości zarządzanej, tożsamość jest tworzona w Azure AD. Tożsamość jest związana z cyklem życia tej instancji usługi. Gdy zasób zostanie usunięty, Azure automatycznie usuwa dla ciebie tożsamość. Zgodnie z projektem, tylko ten zasób Azure może używać tej tożsamości do żądania tokenów od Azure AD.
Przypisane przez użytkownika. Możesz również utworzyć tożsamość zarządzaną jako samodzielny zasób Azure. Możesz utworzyć tożsamość zarządzaną przez użytkownika i przypisać ją do jednej lub więcej instancji usługi Azure (wiele zasobów). Dla tożsamości zarządzanych przez użytkownika, tożsamość jest zarządzana osobno od zasobów, które jej używają.
Role & Uprawnienia
Role są przypisywane do podmiotów na 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 została przypisana rola, 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 wewnątrz subskrypcji oraz we wszystkich zasobach wewnątrz grupy zasobów.
Role Klasyczne
Właściciel |
| Wszystkie typy zasobów |
Współtwórca |
| Wszystkie typy zasobów |
Czytelnik | • Przeglądaj wszystkie zasoby | Wszystkie typy zasobów |
Administrator dostępu użytkownika |
| Wszystkie typy zasobów |
Role Wbudowane
Z dokumentacji: Kontrola dostępu oparta na rolach Azure (Azure RBAC) posiada kilka wbudowanych ról Azure, które można przypisać do użytkowników, grup, podmiotów usługi i tożsamości zarządzanych. Przypisania ról są sposobem kontrolowania dostępu do zasobów Azure. Jeśli wbudowane role nie spełniają konkretnych potrzeb organizacji, można utworzyć własne role Azure.
Role Wbudowane dotyczą tylko zasobów, do których są przeznaczone, na przykład sprawdź te 2 przykłady ról wbudowanych dla zasobów obliczeniowych:
Zapewnia uprawnienia do kopii zapasowej dysku w celu wykonywania kopii zapasowych. | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 | |
Wyświetl maszyny wirtualne w portalu i zaloguj się jako zwykły użytkownik. | fb879df8-f326-4884-b1cf-06f3ad86be52 |
Te role mogą być również przypisane do kontenerów logicznych (takich jak grupy zarządzania, subskrypcje i grupy zasobów), a dotknięte nimi podmioty będą miały je nad zasobami wewnątrz tych kontenerów.
Znajdź tutaj listę wszystkich wbudowanych ról Azure.
Znajdź tutaj listę wszystkich wbudowanych ról Azure AD.
Role Niestandardowe
Azure pozwala również tworzyć role niestandardowe z uprawnieniami, których potrzebuje użytkownik.
Odmowa Uprawnień
Aby podmiot miał dostęp do zasobu, musi mieć przypisaną mu rolę, która mu to uprawnienie przyznaje.
Wyraźne przypisanie roli odmowy ma pierwszeństwo nad rolą przyznającą uprawnienie.
Administrator Globalny
Użytkownicy z rolą Administratora Globalnego mają możliwość 'awansowania' do roli Administratora Dostępu Użytkownika Azure do głównej grupy zarządzania. Oznacza to, że Administrator Globalny będzie mógł zarządzać dostępem do wszystkich subskrypcji i grup zarządzania Azure. Ten awans można dokonać na końcu strony: https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties
Zasady Azure
Zasady Azure to zestaw reguł i przepisów w usłudze chmury Microsoft Azure, które pomagają zarządzać i egzekwować standardy organizacyjne oraz oceniać zgodność na dużą skalę. Te zasady narzucają różne reguły na Twoje zasoby Azure, zapewniając, że te zasoby pozostają zgodne ze standardami korporacyjnymi i umowami o poziomie usług.
Zasady Azure są kluczowe dla zarządzania chmurą i bezpieczeństwa, pomagając zapewnić, że zasoby są używane właściwie i efektywnie, oraz że są zgodne z zewnętrznymi przepisami i wewnętrznymi zasadami. Przykłady:
Zapewnienie Zgodności z Konkretnymi Regionami Azure: Ta zasada zapewnia, że wszystkie zasoby są wdrożone w określonych regionach Azure. Na przykład firma może chcieć zapewnić, że wszystkie jej dane są przechowywane w Europie zgodnie z RODO.
Wymuszanie Standardów Nazewnictwa: Zasady mogą narzucać konwencje nazewnicze dla zasobów Azure. Pomaga to w organizowaniu i łatwym identyfikowaniu zasobów na podstawie ich nazw, co jest pomocne w dużych środowiskach.
Ograniczenie Określonych Typów Zasobów: Ta zasada może ograniczać tworzenie określonych typów zasobów. Na przykład zasada może być ustawiona, aby zapobiec tworzeniu drogich typów zasobów, takich jak określone rozmiary maszyn wirtualnych, w celu kontroli kosztów.
Wymuszanie Polityk Tagowania: Tagi to pary klucz-wartość powiązane z zasobami Azure używane do zarządzania zasobami. Zasady mogą wymuszać obecność określonych tagów lub określonych wartości dla wszystkich zasobów. Jest to przydatne do śledzenia kosztów, właścicieli lub kategoryzacji zasobów.
Ograniczenie Dostępu Publicznego do Zasobów: Zasady mogą wymuszać, aby niektóre zasoby, takie jak konta magazynowe lub bazy danych, nie miały publicznych punktów końcowych, zapewniając, że są one dostępne tylko w sieci organizacji.
Automatyczne Zastosowanie Ustawień Bezpieczeństwa: Zasady mogą być używane do automatycznego stosowania ustawień bezpieczeństwa do zasobów, takich jak stosowanie określonej grupy zabezpieczeń sieciowych do wszystkich maszyn wirtualnych lub zapewnienie, że wszystkie konta magazynowe używają szyfrowania.
Zauważ, że Zasady Azure mogą być dołączone do dowolnego poziomu hierarchii Azure, ale są często używane w głównej grupie zarządzania lub innych grupach zarządzania.
Zakres Uprawnień
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 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 w celu przyznania mu dostępu do zasobu. Jednak w niektórych przypadkach możesz chcieć zapewnić bardziej precyzyjne zarządzanie dostępem lub uproszczenie zarządzania setkami przypisań ról.
Azure ABAC (kontrola dostępu oparta na atrybutach) rozbudowuje Azure RBAC poprzez dodanie warunków przypisania roli opartych na atrybutach w kontekście konkretnych działań. Warunek przypisania roli to dodatkowa kontrola, którą opcjonalnie możesz dodać do przypisania roli w celu zapewnienia bardziej precyzyjnej kontroli dostępu. Warunek filtruje przyznane uprawnienia jako część definicji roli i przypisania roli. Na przykład możesz dodać warunek, który wymaga, aby obiekt miał określony tag, aby odczytać obiekt. Nie możesz wyraźnie odmówić dostępu do określonych zasobów korzystając z warunków.
Domyślne uprawnienia użytkownika
Podstawowy użytkownik będzie miał domyślne uprawnienia do wyliczenia 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 w grupach
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)
Możesz zobaczyć pełną listę domyślnych uprawnień użytkowników w dokumentacji. Ponadto, zauważ, że na tej liście można również zobaczyć listę domyślnych uprawnień gości.
Pamiętaj, żeby wyliczyć zasoby Azure, użytkownik potrzebuje wyraźnego udzielenia 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 dokładnie w odpowiednim czasie i na ograniczony czas, stosując przepływy zatwierdzania i wymagając dodatkowej autoryzacji. Ten podejście minimalizuje ryzyko nieautoryzowanego dostępu, zapewniając, że podwyższone uprawnienia są udzielane tylko wtedy, gdy są niezbędne i na określony czas.
Tokeny uwierzytelniające
Istnieją trzy rodzaje tokenów używanych w OIDC:
Tokeny dostępu: Klient prezentuje 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 zostać wycofany do momentu wygaśnięcia - domyślnie po 1 godzinie. 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: Udostępniane klientowi wraz z tokenem dostępu. Służą do uzyskiwania nowych tokenów dostępu i ID. Są powiązane z określoną kombinacją użytkownika i klienta i mogą zostać wycofane. Domyślny termin ważności 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. Dlatego jeśli żądasz tokena z dozwolonego adresu IP, to IP to będzie przechowywane w tokenie, a następnie możesz użyć tego tokenu z nieautoryzowanego IP do uzyskania dostępu do zasobów.
Sprawdź następującą stronę, aby dowiedzieć się różnych sposobów żądania tokenów dostępu i logowania się nimi:
pageAz - AzureAD (AAD)Najczęściej używane punkty końcowe API to:
Menedżer zasobów Azure (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
