Az - Basic Information
Organization Hierarchy
Management Groups
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ądzania zapewniają zakres zarządzania powyżej subskrypcji.
Należy zauważyć, że 10 000 grup zarządzania może być obsługiwanych w jednym katalogu, a drzewo grup zarządzania może obsługiwać do sześciu poziomów głębokości.
Z dokumentacji: Każdy katalog otrzymuje jedną grupę zarządzania najwyższego poziomu, zwaną grupą główną. Grupa główna jest wbudowana w hierarchię, aby wszystkie grupy zarządzania i subskrypcje były do niej przypisane. Ta grupa główna umożliwia stosowanie globalnych polityk i przypisywanie ról Azure na poziomie katalogu. Azure AD Global Administrator musi podnieść swoje uprawnienia do roli User Access Administrator tej grupy głównej początkowo. Po podniesieniu uprawnień, administrator może przypisywać dowolne role Azure innym użytkownikom lub grupom katalogu do zarządzania hierarchią. Jako administrator, możesz przypisać swoje własne konto jako właściciela grupy głównej.
Grupa główna nie może być przenoszona ani usuwana, w przeciwieństwie do innych grup zarządzania.
Grupy zarządzania zapewniają zarządzanie na poziomie przedsiębiorstwa, niezależnie od rodzaju posiadanych subskrypcji. Jednak wszystkie subskrypcje w jednej grupie zarządzania muszą ufać temu samemu tenantowi Azure Active Directory (Azure AD).
Azure Subscriptions
W Azure, subskrypcja służy jako logiczny kontener do celów udostępniania 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ślana jest subskrypcja z nim związana. Ta struktura ułatwia delegowanie dostępu, wykorzystując mechanizmy kontroli dostępu oparte na rolach.
Resource Groups
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órymi chcesz zarządzać jako grupą. Zazwyczaj dodaj 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ć 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.
Administrative Units
Z dokumentacji: Jednostki administracyjne pozwalają podzielić organizację na dowolne jednostki, które chcesz, a następnie przypisać określonych 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 ustawiać 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 inni pryncypałowie będą mieli 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ć Domain Controller w Azure dla swojego środowiska Windows Active Directory, musisz użyć Azure AD Domain Services.
Principals
Azure obsługuje różne typy pryncypałów:
User: Zwykła osoba z poświadczeniami do dostępu.
Group: Grupa pryncypałó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 automatyzacji do dostępu do zasobów Azure. Ten dostęp jest ograniczony przez role przypisane do service principal, dając kontrolę nad które zasoby mogą być dostępne i na jakim poziomie. Ze względów bezpieczeństwa zawsze zaleca się używanie service principals z narzędziami automatyzacji zamiast pozwalania im na logowanie się za pomocą tożsamości użytkownika.
Podczas tworzenia service principal 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ł go ponownie uzyskać.
Jeśli wybierzesz uwierzytelnianie certyfikatem, upewnij się, że aplikacja będzie miała dostęp do klucza prywatnego.
Managed Identity (Metadata Creds): 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 do łączenia się z zasobami zgodnymi z uwierzytelnianiem Azure Active Directory (Azure AD). Korzystając z zarządzanych tożsamości, aplikacje mogą zabezpieczać tokeny Azure AD, eliminując potrzebę bezpośredniego zarządzania poświadczeniami. Istnieją dwa rodzaje zarządzanych tożsamości:
System-assigned. Niektóre usługi Azure pozwalają na włączenie zarządzanej tożsamości bezpośrednio na instancji usługi. Gdy włączysz system-assigned managed identity, tożsamość jest tworzona w Azure AD. Tożsamość jest powiązana z cyklem życia tej instancji usługi. Gdy zasób jest usuwany, 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.
User-assigned. Możesz również utworzyć zarządzaną tożsamość jako samodzielny zasób Azure. Możesz utworzyć user-assigned managed identity i przypisać ją do jednej lub więcej instancji usługi Azure (wiele zasobów). Dla user-assigned managed identities, tożsamość jest zarządzana oddzielnie od zasobów, które jej używają.
Roles & Permissions
Role są przypisywane do pryncypałów na 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 przez inne zasoby wewnątrz kontenera zakresu. Na przykład, jeśli użytkownik A ma rolę na subskrypcji, będzie miał tę rolę na wszystkich grupach zasobów wewnątrz subskrypcji i na wszystkich zasobach wewnątrz grupy zasobów.
Classic Roles
Owner |
| Wszystkie typy zasobów |
Contributor |
| Wszystkie typy zasobów |
Reader | • Przeglądanie wszystkich zasobów | Wszystkie typy zasobów |
User Access Administrator |
| Wszystkie typy zasobów |
Built-In roles
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, service principals i managed identities. 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 custom roles Azure.
Wbudowane role dotyczą tylko zasobów, do których są przeznaczone, na przykład sprawdź te 2 przykłady wbudowanych ról dla zasobów Compute:
Zapewnia uprawnienia do backup vault do wykonywania kopii zapasowych dysków. | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 | |
Przeglądanie 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 logicznych kontenerów (takich jak grupy zarządzania, subskrypcje i grupy zasobów), a pryncypałowie, których to dotyczy, będą mieli 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.
Custom Roles
Azure pozwala również na tworzenie custom roles z uprawnieniami, których potrzebuje użytkownik.
Permission Denied
Aby pryncypał miał dostęp do zasobu, potrzebuje wyraźnego przypisania roli, która przyznaje mu to uprawnienie.
Wyraźne przypisanie roli odmowy ma pierwszeństwo przed rolą przyznającą uprawnienie.
Global Administrator
Użytkownicy z rolą Global Administrator mają możliwość 'podniesienia' do roli User Access Administrator Azure do grupy głównej. Oznacza to, że Global Administrator będzie mógł zarządzać dostępem do wszystkich subskrypcji Azure i grup zarządzania. To podniesienie można wykonać na końcu strony: https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties
Azure Policies
Polityki Azure to zestaw zasad i regulacji 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 nad Twoimi zasobami Azure, zapewniając, że te zasoby pozostają zgodne z korporacyjnymi standardami 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 zewnętrznymi regulacjami i wewnętrznymi politykami. Przykłady:
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ć, aby wszystkie jej dane były przechowywane w Europie dla zgodności z GDPR.
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.
Ograniczanie określonych typów zasobów: Ta polityka może ograniczać tworzenie określonych typów zasobów. Na przykład, polityka może być ustawiona, aby zapobiec tworzeniu drogich typów zasobów, takich jak określone rozmiary VM, w celu kontrolowania kosztów.
Egzekwowanie polityk tagowania: Tagowanie 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 zas
Last updated
