Zarządzanie tożsamościami i dostępem za pomocą serwerów z obsługą usługi Azure Arc

Zarządzanie tożsamością dla serwerów tradycyjnie obraca się wokół usługi Active Directory: serwery są przyłączone do domeny, administratorzy otrzymują konta domeny dodawane do administratorów lokalnych za pośrednictwem grup domen, a ustawienia systemu Windows są zarządzane przy użyciu zasad grupy. W modelu zarządzania chmurą firma Microsoft Entra staje się podstawą tożsamości i dostępu, podczas gdy usługa Active Directory (AD) może być nadal używana do uwierzytelniania aplikacji i starszych protokołów na lokalnych maszynach z systemem Windows.

Tożsamość natywna w chmurze w zarządzaniu serwerami jest osiągana przy użyciu firmy Microsoft Entra do uwierzytelniania administratorów i samych serwerów. Lokalne serwery przyłączone do domeny usługi AD nadal mogą być dostępne przez natywne dla chmury urządzenia z systemem Windows (stacja robocza) lub użytkowników na tych urządzeniach. Dzięki firmie Microsoft Entra uzyskujesz ujednolicone poświadczenia, ponieważ identyfikator Entra firmy Microsoft może zarządzać maszynami wirtualnymi, serwerami z obsługą usługi Arc, usługą Office 365 i nie tylko. Funkcje takie jak uwierzytelnianie wieloskładnikowe (MFA) i dostęp warunkowy zwiększają bezpieczeństwo. Serwery w środowisku hybrydowym mogą bezpiecznie uzyskiwać dostęp do zasobów przy użyciu systemu tożsamości platformy Azure. Te korzyści pozwalają skrócić czas spędzony na utrzymywaniu kont usług lub udzielaniu lokalnych praw administratora na maszynę. Jest to przejście, ale zgodne z w pełni zarządzanym przez chmurę ekosystemem.

Przyjrzyjmy się, w jaki sposób świat administratora systemu zmienia się dzięki korzyściom firmy Microsoft Entra.

Integracja z firmą Microsoft Entra

Microsoft Entra ID to oparta na chmurze usługa tożsamości. W przeciwieństwie do usług Active Directory Domain Services (AD DS), identyfikator Entra firmy Microsoft nie jest ustrukturyzowany w jednostkach organizacyjnych i nie koncentruje się na uwierzytelnianiu Kerberos. Zamiast tego identyfikator Entra firmy Microsoft zarządza tożsamościami użytkowników, aplikacjami i dostępem do zasobów firmy Microsoft, w tym platformy Azure, platformy Microsoft 365 oraz innych aplikacji i systemów operacyjnych obsługujących identyfikator Entra firmy Microsoft.

Serwery same w sobie nie "dołączają" do identyfikatora Entra firmy Microsoft w taki sposób, w jaki dołączają do domeny. Zamiast tego serwer z obsługą usługi Arc jest przyłączony do dzierżawy platformy Azure zarządzanej przez usługę Microsoft Entra ID podczas pierwszego łączenia się z platformą Azure. Za pomocą identyfikatora Entra firmy Microsoft użytkownicy mogą mieć przypisane role do wyznaczonego zakresu (lub dodanego do grupy z tymi uprawnieniami) przy użyciu kontroli dostępu na podstawie ról (RBAC) platformy Azure. Następnie użytkownicy z odpowiednimi uprawnieniami mogą używać połączenia pulpitu zdalnego w celu uzyskania dostępu do maszyn z systemem Windows Server lub uzyskać dostęp do systemu Linux za pomocą protokołu SSH.

Twoje "konto administratora" to tożsamość identyfikatora entra firmy Microsoft (lub zsynchronizowane konto usługi AD) z odpowiednimi rolami na platformie Azure. Na przykład w celu zarządzania serwerami z obsługą usługi Arc użytkownik identyfikatora Entra firmy Microsoft może mieć wbudowaną rolę Administratora maszyny wirtualnej platformy Azure lub niestandardowe przypisanie roli utworzone z odpowiednimi uprawnieniami. Zamiast mieć jedno konto administratora, które umożliwia pełny dostęp do każdego serwera, identyfikator Entra firmy Microsoft umożliwia określanie zakresu ról do określonego zestawu obciążeń platformy Azure, udzielając tylko uprawnień wymaganych do wykonywania niezbędnych zadań na serwerach z obsługą usługi Arc i natywnych zasobów platformy Azure.

Zarządzana tożsamość przypisana przez system

Serwery z obsługą usługi Arc wymagają tożsamości zarządzanej przypisanej przez system. Jest to typ aplikacji dla przedsiębiorstw, który reprezentuje tożsamość zasobu maszyny na platformie Azure. Zamiast przechowywać poświadczenia, aplikacje uruchomione na serwerze mogą używać tożsamości zarządzanej serwera do uwierzytelniania na platformie Azure. Agent maszyny połączonej z usługą Azure Arc uwidacznia punkt końcowy, którego aplikacja może użyć do żądania tokenu. Aplikacja nie musi uwierzytelniać się w usłudze sieci Web, która udostępnia tokeny inne niż prawidłowe formatowanie żądania (w tym nagłówek metadanych), dlatego oczekiwaną granicą zabezpieczeń jest maszyna wirtualna. Serwer lokalny może uzyskiwać bezpośredni dostęp do usług platformy Azure bez konieczności kodowania poświadczeń, ponieważ platforma Azure wie, że żądanie pochodzi z tego serwera i autoryzuje je tylko na podstawie ustawionych przypisań ról.

W przypadku administratora systemu jednym z typowych scenariuszy może być uruchomienie polecenia interfejsu wiersza polecenia platformy Azure na serwerze (z zainstalowanym interfejsem wiersza polecenia platformy Azure), które wywołuje usługę Azure Storage w celu pobrania artefaktu używanego przez skrypt automatyzacji. Ponieważ serwer ma autoryzowany dostęp do tego konta magazynu, żądanie jest wykonywane bez konieczności posiadania konta usługi lub osobistego tokenu dostępu (PAT).

Kontrola dostępu oparta na rolach (RBAC)

Model platformy Azure zachęca do szczegółowej kontroli dostępu opartej na rolach. Ponieważ różne wbudowane role umożliwiają różne typy dostępu, można przypisywać role z bardzo ograniczonymi uprawnieniami. Na przykład użytkownik może mieć rolę, która przyznaje tylko możliwość używania polecenia Uruchom na serwerach z obsługą usługi Arc lub zezwala na dostęp tylko do odczytu do konfiguracji i nic więcej.

Typową wbudowaną rolą używaną z usługą Azure Arc jest rola dołączania maszyny połączonej platformy Azure. Użytkownicy z tą rolą mogą dołączać serwery do usługi Azure Arc, ale nie mogą wykonywać większości innych zadań zarządzania, chyba że przyznano dodatkowe role. Podobnie można nadać właścicielom aplikacji role, które umożliwiają im wdrażanie poprawek na serwerach za pośrednictwem usługi Azure Automation bez udzielania im rzeczywistego dostępu do logowania systemu operacyjnego. Ten poziom dostrajania obsługuje "wystarczająco dużo" zasad administracyjnych.

Dostęp na czas

Aby dodatkowo kontrolować podwyższony poziom dostępu do serwerów z obsługą usługi Arc i innych zasobów platformy Azure, możesz włączyć usługę Microsoft Entra Privileged Identity Management (PIM). Usługa PIM może służyć do uzyskiwania dostępu just in time (JIT), dzięki czemu można wymagać jawnego podniesienia poziomu uprawnień do określonej roli w celu wykonywania zadań wymagających większego poziomu dostępu. Możesz wymagać od administratora zatwierdzenia tego dostępu i ustawienia automatycznych okresów wygaśnięcia dla roli z podwyższonym poziomem uprawnień. Usługa PIM zawiera również historię inspekcji, która umożliwia wyświetlanie wszystkich przypisań ról i aktywacji dla wszystkich ról uprzywilejowanych w ciągu ostatnich 30 dni (lub dłuższego skonfigurowanego okresu).

Korzystanie z usługi PIM pomaga zmniejszyć ciągły dostęp administratora i obsługuje zasadę najniższych uprawnień. Możesz na przykład użyć usługi PIM, aby przyznać niektórym użytkownikom możliwość podniesienia ich roli do administratora zasobów połączonej maszyny platformy Azure, umożliwiając im wykonywanie bardziej zaawansowanych zadań zarządzania na serwerach z obsługą usługi Arc.

Konfiguracje tożsamości hybrydowej

W praktyce wiele przedsiębiorstw uruchamia serwery z obsługą usługi Arc, które są również przyłączone do usługi AD. Nie wykluczają się one wzajemnie; uzupełniają się nawzajem. W razie potrzeby możesz zalogować się do serwera za pośrednictwem usługi AD, ale wykonywać zadania zarządzania na platformie Azure.

Na poszczególnych serwerach nadal można zarządzać kontami lokalnymi za pośrednictwem usługi AD, na przykład przy użyciu rozwiązania do stosowania hasła administratora lokalnego (LAPS) w celu rotacji hasła administratora lokalnego. Ponieważ usługa Azure Arc nie zarządza kontami lokalnymi, możesz nadal korzystać z tego procesu. Możesz nawet użyć usługi Azure Policy, aby upewnić się, że usługa LAPS jest włączona i przechowuje hasła w usłudze Microsoft Entra.

Istnieje duża elastyczność korzystania z możliwości firmy Microsoft Entra i platformy Azure, zachowując jednocześnie lokalne rozwiązania do obsługi tożsamości, które działają dla Ciebie. W czasie okaże się, że musisz wchodzić w interakcje mniej z utrzymywaniem kont usług lub udzielaniem uprawnień administratora lokalnego, ponieważ możesz mieć opcje zarządzania tożsamościami w chmurze.