Uwierzytelnianie w usłudze Azure Key Vault

Uwierzytelnianie za pomocą usługi Key Vault działa w połączeniu z identyfikatorem Entra firmy Microsoft, który jest odpowiedzialny za uwierzytelnianie tożsamości dowolnego podmiotu zabezpieczeń.

Podmiot zabezpieczeń to obiekt reprezentujący użytkownika, grupę, usługę lub aplikację żądającą dostępu do zasobów platformy Azure. Platforma Azure przypisuje unikatowy identyfikator obiektu do każdego podmiotu zabezpieczeń.

• Zasada bezpieczeństwa użytkownika identyfikuje osobę, która ma profil w Microsoft Entra ID.

• Podmiot zabezpieczeń grupy identyfikuje zestaw użytkowników utworzonych w identyfikatorze Entra firmy Microsoft. Wszystkie role lub uprawnienia przypisane do grupy są przyznawane wszystkim użytkownikom w grupie.

• Główny obiekt usługi jest typem podmiotu zabezpieczeń, który identyfikuje aplikację lub usługę, czyli fragment kodu, a nie użytkownika lub grupy. Identyfikator obiektu jednostki usługi działa jak jego nazwa użytkownika; wpis tajny klienta jednostki usługi działa jak jego hasło.

W przypadku aplikacji istnieją dwa sposoby uzyskania zasady usługi:

• Zalecane: włącz tożsamość zarządzaną przypisaną przez system dla aplikacji.

  Dzięki tożsamości zarządzanej platforma Azure wewnętrznie zarządza jednostką usługi aplikacji i automatycznie uwierzytelnia aplikację przy użyciu innych usług platformy Azure. Tożsamość zarządzana jest dostępna dla aplikacji wdrożonych w różnych usługach.

  Aby uzyskać więcej informacji, zobacz Omówienie tożsamości zarządzanej. Zobacz również usługi platformy Azure obsługujące tożsamość zarządzaną, które zawierają linki do artykułów opisujących sposób włączania tożsamości zarządzanej dla określonych usług (takich jak App Service, Azure Functions, Virtual Machines itp.).

• Jeśli nie możesz używać tożsamości zarządzanej, zamiast tego zarejestruj aplikację w dzierżawie firmy Microsoft Entra zgodnie z opisem w przewodniku Szybki start: rejestrowanie aplikacji za pomocą platformy tożsamości platformy Azure. Rejestracja tworzy również drugi obiekt aplikacji, który identyfikuje aplikację wśród wszystkich dzierżawców.

Scenariusze uwierzytelniania usługi Key Vault

Podczas tworzenia magazynu kluczy w subskrypcji platformy Azure jest on automatycznie skojarzony z dzierżawą Microsoft Entra, która jest częścią subskrypcji. Wszystkie osoby wywołujące w obu płaszczyznach muszą zarejestrować się w tej dzierżawie i uwierzytelnić się w celu uzyskania dostępu do magazynu kluczy. Aplikacje mogą uzyskiwać dostęp do usługi Key Vault na trzy sposoby:

• Tylko dla aplikacji: aplikacja reprezentuje pryncypał usługi lub tożsamość zarządzaną. Ta tożsamość jest najbardziej typowym scenariuszem dla aplikacji, które okresowo muszą uzyskiwać dostęp do certyfikatów, kluczy lub tajemnic z magazynu kluczy. Aby ten scenariusz działał w przypadku korzystania z zasad dostępu (starsza wersja), aplikacja musi być określona w zasadach dostępu, a applicationId nie może być określony lub musi mieć wartość null. W przypadku korzystania z kontroli dostępu opartej na rolach platformy Azure przypisz odpowiednie role do tożsamości zarządzanej aplikacji lub głównego użytkownika usługi.

• Tylko użytkownik: użytkownik uzyskuje dostęp do magazynu kluczy z dowolnej aplikacji zarejestrowanej w ramach dzierżawy. Przykłady tego typu dostępu obejmują program Azure PowerShell i witrynę Azure Portal. Aby ten scenariusz działał podczas korzystania ze starszych zasad dostępu, objectId użytkownik musi być określony w zasadach dostępu, a applicationIdnie może być określony lub musi mieć wartość null. W przypadku korzystania z kontroli dostępu opartej na rolach platformy Azure przypisz odpowiednie role do użytkownika.

• Aplikacja plus-użytkownik (czasami nazywana tożsamością złożoną): użytkownik musi uzyskać dostęp do magazynu kluczy przez określoną aplikację, a aplikacja musi korzystać z przepływu uwierzytelniania w imieniu (OBO) w celu personifikacji użytkownika. W tym scenariuszu, aby działać z zasadami dostępu (starsza wersja), zarówno applicationId, jak i objectId muszą być określone w zasadach dostępu. Element applicationId identyfikuje wymaganą aplikację i objectId identyfikuje użytkownika. Obecnie ta opcja nie jest dostępna dla płaszczyzny danych RBAC platformy Azure.

We wszystkich typach dostępu aplikacja uwierzytelnia się za pomocą identyfikatora Microsoft Entra. Aplikacja używa dowolnej obsługiwanej metody uwierzytelniania na podstawie typu aplikacji. Aplikacja uzyskuje token dla zasobu w płaszczyźnie w celu udzielenia dostępu. Zasób jest punktem końcowym na płaszczyźnie zarządzania lub danych w środowisku Azure. Aplikacja używa tokenu i wysyła żądanie interfejsu API REST do usługi Key Vault. Aby dowiedzieć się więcej, przejrzyj cały przepływ uwierzytelniania.

Model pojedynczego mechanizmu uwierzytelniania w obu płaszczyznach ma kilka korzyści:

• Organizacje mogą centralnie kontrolować dostęp do wszystkich magazynów kluczy w swojej organizacji.
• Jeśli użytkownik odejdzie, natychmiast traci dostęp do wszystkich skarbców kluczy w organizacji.
• Organizacje mogą dostosowywać uwierzytelnianie przy użyciu opcji w identyfikatorze Entra firmy Microsoft, takich jak włączenie uwierzytelniania wieloskładnikowego na potrzeby dodatkowych zabezpieczeń.

Konfigurowanie zapory usługi Key Vault

Domyślnie usługa Key Vault zezwala na dostęp do zasobów za pośrednictwem publicznych adresów IP. W celu zwiększenia bezpieczeństwa można również ograniczyć dostęp do określonych zakresów adresów IP, punktów końcowych usługi, sieci wirtualnych lub prywatnych punktów końcowych.

Aby uzyskać więcej informacji, zobacz Uzyskiwanie dostępu do usługi Azure Key Vault za zaporą.

Przepływ operacji żądania usługi Key Vault z uwierzytelnianiem

Uwierzytelnianie usługi Key Vault odbywa się w ramach każdej operacji żądania w usłudze Key Vault. Po pobraniu tokenu można go ponownie użyć do kolejnych wywołań. Przykład przepływu uwierzytelniania:

1. Żądanie tokenu do uwierzytelnienia za pomocą identyfikatora Entra firmy Microsoft, na przykład:

   • Zasób platformy Azure, taki jak maszyna wirtualna lub aplikacja usługi App Service z tożsamością zarządzaną, kontaktuje się z punktem końcowym REST w celu uzyskania tokenu dostępu.
   • Użytkownik loguje się do witryny Azure Portal przy użyciu nazwy użytkownika i hasła.

2. Jeśli uwierzytelnianie przy użyciu identyfikatora Entra firmy Microsoft zakończy się pomyślnie, podmiot zabezpieczeń otrzymuje token OAuth.

3. Wywołanie interfejsu API REST usługi Key Vault za pośrednictwem punktu końcowego usługi Key Vault (URI).

4. Zapora usługi Key Vault sprawdza następujące kryteria. Jeśli każde kryterium zostanie spełnione, wywołanie jest dozwolone. W przeciwnym razie wywołanie zostanie zablokowane i zostanie zwrócona niedozwolona odpowiedź.

   • Zapora jest wyłączona, a publiczny punkt końcowy usługi Key Vault jest dostępny z publicznego Internetu.
   • Obiekt wywołujący jest zaufaną usługą Key Vault, co pozwala mu ominąć zaporę.
   • Obiekt wywołujący jest wymieniony w zaporze według adresu IP, sieci wirtualnej lub punktu końcowego usługi.
   • Obiekt wywołujący może nawiązać połączenie z usługą Key Vault za pośrednictwem skonfigurowanego połączenia łącza prywatnego.

5. Jeśli zapora zezwala na wywołanie, usługa Key Vault wywołuje identyfikator Firmy Microsoft Entra w celu zweryfikowania tokenu dostępu podmiotu zabezpieczeń.

6. Usługa Key Vault sprawdza, czy podmiot zabezpieczeń ma niezbędne uprawnienia do żądanej operacji. Jeśli tak nie jest, usługa Key Vault zwraca niedozwoloną odpowiedź.

7. Usługa Key Vault wykonuje żądaną operację i zwraca wynik.

Na poniższym diagramie przedstawiono proces aplikacji wywołującej interfejs API "Get Secret" usługi Key Vault:

Uwierzytelnianie do Key Vault w kodzie aplikacji

Zestaw SDK usługi Key Vault korzysta z biblioteki klienta tożsamości platformy Azure, która umożliwia bezproblemowe uwierzytelnianie w usłudze Key Vault w środowiskach z tym samym kodem

Biblioteki klienta tożsamości platformy Azure

Więcej informacji na temat najlepszych rozwiązań i przykładów dla deweloperów znajduje się w temacie Uwierzytelnianie w usłudze Key Vault w kodzie

Dalsze kroki

• Przewodnik dla deweloperów Key Vault

• Przypisywanie zasad dostępu usługi Key Vault przy użyciu witryny Azure Portal

• Przypisz rolę RBAC platformy Azure do Key Vault

• Rozwiązywanie problemów z zasadami dostępu usługi Key Vault

• Kody błędów interfejsu API REST usługi Key Vault

• Co to jest kontrola dostępu oparta na rolach na platformie Azure (Azure RBAC)?