Zarządzanie tożsamościami aplikacji i dostępem
W tym artykule opisano zagadnienia i zalecenia, których właściciele aplikacji i deweloperzy mogą używać do projektowania zarządzania tożsamościami i dostępem dla aplikacji natywnych dla chmury.
Jeśli zespół migruje lub tworzy aplikacje natywne dla chmury, musisz wziąć pod uwagę wymagania dotyczące uwierzytelniania i dostępu dla aplikacji. Te wymagania określają sposób uwierzytelniania użytkowników w aplikacjach i sposobu uwierzytelniania zasobów aplikacji nawzajem, na przykład gdy aplikacja internetowa uzyskuje dostęp do bazy danych SQL.
W obszarze automatyzacji platformy i projektu DevOps zalecamy, aby zespół aplikacji przechodził obciążenia do sprzedaż abonamentów. W ramach procesu subskrypcji zespół aplikacji musi zapewnić zespołowi ds. tożsamości i dostępu wymagania dotyczące tożsamości i dostępu do zespołu platformy, aby mogli utworzyć odpowiednie subskrypcje. Właściciele aplikacji są odpowiedzialni za zarządzanie tożsamościami i dostępem poszczególnych aplikacji. Powinni zarządzać swoją aplikacją przy użyciu scentralizowanych usług zapewnianych przez zespół platformy.
Uwagi dotyczące projektowania
Aby zmniejszyć ryzyko nieautoryzowanego dostępu do aplikacji, uwzględnij następujące kwestie w projekcie.
Istnieje kilka standardów uwierzytelniania i autoryzacji, takich jak OAuth 2.0, OpenID Połączenie, tokeny internetowe JSON (JWTs) i SAML (Security Assertion Markup Language). Ustal, które standardy uwierzytelniania i autoryzacji mają być używane dla aplikacji.
Gdy zażądasz strefy docelowej aplikacji od zespołu platformy, możesz upewnić się, że tworzą odpowiednie subskrypcje, zadając im następujące pytania:
Jak użytkownicy końcowi będą uwierzytelniać się w aplikacji i uzyskiwać do jej dostępu?
KtoTo potrzebuje uprawnień kontroli dostępu opartej na rolach (RBAC) dla zasobów i usług używanych przez aplikację?
Czy istniejące wbudowane role obejmują wymagania dostępu RBAC zarówno dla płaszczyzny sterowania, jak i dostępu do płaszczyzny danych, czy też należy utworzyć nowe role niestandardowe?
Czy zespół platformy zaimplementował jakiekolwiek zasady zgodności, które mogą powodować problemy z aplikacją?
Które składniki aplikacji muszą komunikować się ze sobą?
Czy istnieją jakiekolwiek wymagania dotyczące uzyskiwania dostępu do udostępnionych zasobów, takich jak Microsoft Entra Domain Services, które są wdrażane w strefie docelowej platformy?
Usługa Azure Key Vault i tożsamości zarządzane
Naruszenia zabezpieczeń zasobów chmury publicznej często pochodzą z ujawnionych poświadczeń osadzonych w kodzie lub innym tekście. Za pomocą tożsamości zarządzanych i usługi Key Vault można zaimplementować dostęp programowy i zmniejszyć ryzyko kradzieży poświadczeń.
Jeśli aplikacja lub obciążenie wymaga usługi do bezpiecznego przechowywania poświadczeń, możesz użyć usługi Key Vault do zarządzania wpisami tajnymi, kluczami i certyfikatami.
Aby uniknąć posiadania poświadczeń w kodzie, możesz użyć tożsamości zarządzanych z maszynami wirtualnymi platformy Azure do uwierzytelniania w dowolnej usłudze obsługującej uwierzytelnianie identyfikatora Entra firmy Microsoft. Aby uzyskać więcej informacji, zobacz Używanie tożsamości zarządzanych dla zasobów platformy Azure na maszynie wirtualnej w celu uzyskania tokenu dostępu.
Tożsamości zarządzane zapewniają automatycznie zarządzaną jednostkę tożsamości używaną przez aplikacje i zasoby podczas nawiązywania połączenia z zasobami obsługującymi uwierzytelnianie identyfikatora Entra firmy Microsoft. Aplikacje mogą używać tożsamości zarządzanych do uzyskiwania tokenów identyfikatorów Entra firmy Microsoft bez konieczności zarządzania poświadczeniami.
Można użyć tożsamości zarządzanych przypisanych przez system lub przypisanych przez użytkownika.
Łatwo jest pomylić sposób uzyskiwania dostępu do zasobów platformy Azure przez jednostki usługi i tożsamości zarządzane. Aby zrozumieć różnicę między nimi, zobacz Demystifying service principals — Managed identities (Demystifying service principals — Managed identities).
Jeśli to możliwe, użyj tożsamości zarządzanych do obsługi uwierzytelniania, a nie używania jednostek usługi i rejestracji aplikacji Microsoft Entra ID. Aby utworzyć jednostki usługi i rejestracje aplikacji, musisz mieć role RBAC application Administracja istrator lub RBAC dla deweloperów aplikacji. Te uprzywilejowane role są zwykle przypisywane do zespołu platformy lub zespołu tożsamości. Użyj tożsamości zarządzanych, aby wyeliminować konieczność utworzenia jednostek usługi i rejestracji aplikacji dla zespołu aplikacji przez zespół platformy.
Tożsamości zarządzane umożliwiają uwierzytelnianie w dowolnej usłudze obsługującej uwierzytelnianie firmy Microsoft Entra. Jednak nie wszystkie usługi obsługują tożsamości zarządzane w celu uzyskania dostępu do innych usług. W przypadku niektórych usług może być konieczne przechowywanie poświadczeń. Należy bezpiecznie przechowywać poświadczenia, unikać udostępniania poświadczeń innym usługom i przestrzegać zasady najniższych uprawnień. Aby uzyskać więcej informacji, zobacz Usługi platformy Azure, które mogą używać tożsamości zarządzanych do uzyskiwania dostępu do innych usług.
Tożsamości zarządzane z maszynami wirtualnymi platformy Azure można używać do uwierzytelniania w dowolnej usłudze obsługującej uwierzytelnianie identyfikatora Entra firmy Microsoft. Aby uzyskać więcej informacji, zobacz Używanie tożsamości zarządzanych dla zasobów platformy Azure na maszynie wirtualnej w celu uzyskania tokenu dostępu.
Istnieją ograniczenia dotyczące przenoszenia zasobów z tożsamościami zarządzanymi między subskrypcjami i regionami. Na przykład możesz przenosić zasoby między subskrypcjami lub regionami w celu połączenia, przejęcia lub repatriacji zasobów ze względów niezależności danych.
Jeśli zasób platformy Azure ma tożsamości przypisane przez użytkownika lub przypisane przez system, nie można przenieść zasobu do innej subskrypcji lub regionu platformy Azure. Przed przeniesieniem zasobu należy usunąć tożsamości zarządzane. Po przeniesieniu należy ponownie utworzyć tożsamości zarządzane i przypisać je do zasobu. Aby uzyskać więcej informacji, zobacz Przenoszenie zasobów do nowej grupy zasobów lub subskrypcji.
Jeśli przeniesiesz subskrypcję z jednego katalogu do innego, tożsamości zarządzane nie zostaną zachowane. Należy przenieść zasób, a następnie ręcznie ponownie utworzyć tożsamości zarządzane.
Podobnie jak w przypadku przypisań ról RBAC użytkownika, należy postępować zgodnie z zasadą najniższych uprawnień podczas udzielania tożsamości zarządzanej dostępu do zasobu.
Użytkownicy zewnętrzni
Możesz ocenić scenariusze obejmujące konfigurowanie użytkowników zewnętrznych, klientów lub partnerów, aby mogli uzyskiwać dostęp do zasobów. Określ, czy te scenariusze obejmują konfiguracje usługi Microsoft Entra B2B lub Azure Active Directory B2C (Azure AD B2C). Aby uzyskać więcej informacji, zobacz Omówienie Tożsamość zewnętrzna Microsoft Entra.
Zalecenia dotyczące projektowania
Podczas projektowania tożsamości i zarządzania dostępem aplikacji należy wziąć pod uwagę następujące zalecenia.
OpenID Connect
Jeśli zespół aplikacji programowo wdraża aplikacje przy użyciu potoków ciągłej integracji i ciągłego dostarczania (CI/CD), skonfiguruj uwierzytelnianie openID Połączenie w usługach platformy Azure. OpenID Połączenie używa tymczasowego, bez poświadczeń tokenu do uwierzytelniania w usługach platformy Azure. Aby uzyskać więcej informacji, zobacz Federacja tożsamości obciążeń.
Jeśli Połączenie OpenID nie jest obsługiwana, utwórz jednostkę usługi i przypisz niezbędne uprawnienia, aby zezwolić na wdrożenie infrastruktury lub kodu aplikacji. Aby uzyskać więcej informacji, zobacz moduł szkoleniowy Uwierzytelnianie potoku wdrażania platformy Azure przy użyciu jednostek usługi.
Kontrola dostępu oparta na atrybutach
Aby jeszcze bardziej ograniczyć dostęp i zapobiec nieautoryzowanemu dostępowi do danych, użyj kontroli dostępu opartej na atrybutach (ABAC), gdzie jest obsługiwana, na przykład w usłudze Azure Blob Storage.
Dostęp do maszyny wirtualnej
Jeśli to możliwe, użyj tożsamości Microsoft Entra ID, aby kontrolować dostęp do maszyn wirtualnych platformy Azure. Użyj identyfikatora Entra firmy Microsoft zamiast uwierzytelniania lokalnego, aby zapewnić dostęp do maszyn wirtualnych, korzystając z dostępu warunkowego firmy Microsoft Entra, rejestrowania inspekcji i uwierzytelniania wieloskładnikowego firmy Microsoft (MFA). Ta konfiguracja zmniejsza ryzyko ataków wykorzystujących niezabezpieczone lokalne usługi uwierzytelniania. Aby uzyskać więcej informacji, zobacz Logowanie się do maszyny wirtualnej z systemem Linux na platformie Azure przy użyciu identyfikatora Entra firmy Microsoft i protokołu OpenSSH oraz Logowanie się do maszyny wirtualnej z systemem Windows na platformie Azure przy użyciu identyfikatora Entra firmy Microsoft, w tym bez hasła.
Platforma tożsamości firmy Microsoft
Podczas tworzenia aplikacji natywnej dla chmury deweloperzy powinni używać Platforma tożsamości Microsoft dla deweloperów jako dostawcy tożsamości dla swoich aplikacji. Platforma tożsamości Microsoft udostępnia usługę uwierzytelniania zgodną z standardami openID Połączenie, za pomocą których deweloperzy mogą uwierzytelniać kilka typów tożsamości, w tym:
Konta służbowe aprowidowane za pośrednictwem identyfikatora Entra firmy Microsoft
Osobiste konta Microsoft (Skype, Xbox, Outlook.com)
Konta społecznościowe lub lokalne przy użyciu identyfikatora Microsoft Entra ID
Lista kontrolna najlepszych rozwiązań i zaleceń Platforma tożsamości Microsoft zawiera wskazówki dotyczące efektywnego integrowania aplikacji z Platforma tożsamości Microsoft.
Tożsamości zarządzane
Aby włączyć dostęp między zasobami platformy Azure, które nie muszą używać poświadczeń, użyj tożsamości zarządzanych.
Nie należy udostępniać poświadczeń ani tożsamości zarządzanych między różnymi środowiskami lub aplikacjami. Na przykład nie używaj tożsamości dla zasobów produkcyjnych, a także w zasobach tworzenia i testowania, nawet w przypadku tej samej aplikacji. Utwórz oddzielne poświadczenia dla każdego wystąpienia aplikacji, aby zmniejszyć prawdopodobieństwo naruszenia zabezpieczeń wystąpienia testowego wpływającego na dane produkcyjne. Oddzielne poświadczenia ułatwiają również odwoływanie poświadczeń, gdy nie są już wymagane.
Jeśli istnieje wymóg używania tożsamości zarządzanych na dużą skalę, użyj tożsamości zarządzanej przypisanej przez użytkownika dla każdego typu zasobu w każdym regionie. Takie podejście uniemożliwia zmianę tożsamości. Na przykład agent usługi Azure Monitor wymaga tożsamości zarządzanej na monitorowanych maszynach wirtualnych platformy Azure, co może spowodować utworzenie (i usunięcie) przez identyfikator entra firmy Microsoft znacznej liczby tożsamości. Tożsamości zarządzane przypisane przez użytkownika można tworzyć raz i udostępniać je na wielu maszynach wirtualnych. Użyj usługi Azure Policy , aby zaimplementować to zalecenie.
Key Vault
Za pomocą usługi Key Vault można zarządzać wpisami tajnymi, kluczami, certyfikatami używanymi przez aplikacje.
Aby zarządzać dostępem do wpisów tajnych (płaszczyzny danych) i dostępu administracyjnego (płaszczyzny kontroli), użyj kontroli dostępu opartej na rolach.
Aby kontrolować dostęp aplikacji do usługi Key Vault, użyj tożsamości zarządzanych.
Należy użyć oddzielnych magazynów kluczy dla każdego środowiska aplikacji (programistycznego, przedprodukcyjnego, produkcyjnego) w każdym regionie. Kontrola dostępu oparta na rolach umożliwia zarządzanie dostępem do wpisów tajnych, kluczy i certyfikatów (operacji płaszczyzny danych) oraz dostępu do usługi Key Vault (płaszczyzny sterowania). Wdróż magazyny kluczy, które mają wpisy tajne aplikacji w strefach docelowych aplikacji.
Serwer proxy aplikacji Firmy Microsoft Entra
Aby uzyskać dostęp do aplikacji korzystających z uwierzytelniania lokalnego zdalnie za pośrednictwem identyfikatora Entra firmy Microsoft, użyj serwera proxy aplikacji Microsoft Entra. Serwer proxy aplikacji Entra firmy Microsoft zapewnia bezpieczny dostęp zdalny do lokalnych aplikacji internetowych, w tym aplikacji korzystających ze starszych protokołów uwierzytelniania. Po zalogowaniu jednokrotnym do usługi Microsoft Entra ID użytkownicy mogą uzyskiwać dostęp zarówno do aplikacji w chmurze, jak i lokalnych za pośrednictwem zewnętrznego adresu URL lub wewnętrznego portalu aplikacji.
Serwer proxy aplikacji Microsoft Entra można wdrożyć jako pojedyncze wystąpienie w dzierżawie microsoft Entra ID. Konfiguracja wymaga ról application Administracja istrator lub global Administracja istrator privileged Microsoft Entra ID. Jeśli Organizacja używa demokratyzacji subskrypcji jako modelu przypisania roli, właściciele aplikacji mogą nie mieć niezbędnych uprawnień do skonfigurowania serwera proxy aplikacji Firmy Microsoft Entra. W takim przypadku zespół platformy powinien skonfigurować serwer proxy aplikacji Microsoft Entra dla właściciela aplikacji.
Jeśli używasz potoków wdrażania ciągłej integracji/ciągłego wdrażania z wystarczającymi uprawnieniami, właściciele aplikacji mogą skonfigurować serwer proxy aplikacji Firmy Microsoft Entra przy użyciu interfejsu API programu Microsoft Graph.
Jeśli aplikacja używa starszych protokołów, takich jak Kerberos, upewnij się, że strefa docelowa aplikacji ma łączność sieciową z kontrolerami domeny w subskrypcji Platforma tożsamości Microsoft.