Część 2. Wymagania dotyczące uwierzytelniania w tym przykładowym scenariuszu

poprzedniej części: wprowadzenie i tło

W tym przykładowym scenariuszu główna aplikacja ma trzy odrębne wymagania dotyczące uwierzytelniania:

• Azure Key Vault

  Aplikacja musi uwierzytelniać się w usłudze Azure Key Vault, aby pobrać bezpiecznie przechowywany klucz interfejsu API potrzebny do wywołania usługi innej firmy.

• Interfejs API innej firmy

  Po pobraniu klucza interfejsu API aplikacja używa go do uwierzytelniania za pomocą zewnętrznego interfejsu API innej firmy.

• Azure Queue Storage (kolejka magazynowa w Azure)

  Po przetworzeniu żądania aplikacja musi uwierzytelniać się w usłudze Azure Queue Storage, aby zapisać komunikat w kolejce na potrzeby przetwarzania asynchronicznego lub odroczonego.

Te zadania wymagają, aby aplikacja zarządzała trzema zestawami poświadczeń:

• Dwa dla zasobów platformy Azure (Key Vault i Storage)

• Jeden dla usługi zewnętrznej (interfejs API innej firmy)

Kluczowe wyzwania związane z uwierzytelnianiem

Tworzenie bezpiecznych aplikacji w chmurze wymaga starannej obsługi poświadczeń — szczególnie w przypadku angażowania wielu usług. Ten przykładowy scenariusz przedstawia kilka krytycznych wyzwań:

• Zależność cykliczna od usługi Key Vault

  Aplikacja używa usługi Azure Key Vault do bezpiecznego przechowywania wpisów tajnych, takich jak klucze interfejsu API innych firm lub poświadczenia usługi Azure Storage. Jednak aby pobrać te tajemnice, aplikacja musi najpierw się uwierzytelnić z usługi Key Vault. Powoduje to problem cykliczny: aplikacja potrzebuje poświadczeń w celu uzyskania dostępu do usługi Key Vault, ale te poświadczenia muszą być przechowywane bezpiecznie. Bez bezpiecznego rozwiązania może to prowadzić do zakodowanych na stałe poświadczeń lub niezabezpieczonych konfiguracji w środowiskach deweloperskich.

• Bezpieczna obsługa kluczy interfejsu API innych firm

  Po pobraniu klucza interfejsu API z usługi Key Vault aplikacja musi używać go do wywoływania zewnętrznej usługi innej firmy. Ten klucz musi być traktowany z szczególną ostrożnością.

  • Nigdy nie zakodowane w kodzie źródłowym lub plikach konfiguracji
  • Nigdy nie zalogowano się do dzienników stdout, stderr lub aplikacji
  • Przechowywane tylko w pamięci i dostępne w czasie wykonywania, tuż przed użyciem
  • Usuwanie natychmiast po zakończeniu żądania

  Nieuprawnione stosowanie tych rozwiązań zwiększa ryzyko wycieku poświadczeń lub nieautoryzowanego użycia.

• Zabezpieczanie poświadczeń usługi Azure Queue Storage

  Aby zapisywać komunikaty w usłudze Azure Queue Storage, aplikacja zazwyczaj potrzebuje parametrów połączenia lub tokenu dostępu współdzielonego. Poświadczenia te:

  • Musi być przechowywany w bezpiecznej lokalizacji, takiej jak usługa Key Vault
  • Nie wolno pojawiać się w dziennikach, logach stosu ani w narzędziach deweloperskich
  • Powinny być dostępne tylko za pośrednictwem bezpiecznych mechanizmów środowiska uruchomieniowego
  • Wymaga się prawidłowej konfiguracji kontroli dostępu opartej na rolach w przypadku korzystania z tożsamości zarządzanej

• Elastyczność środowiska

  Aplikacja musi działać niezawodnie zarówno w lokalnych środowiskach deweloperskich, jak i w środowisku produkcyjnym w chmurze, przy użyciu tej samej bazy kodu i minimalnej logiki warunkowej.

  Oznacza to:

  • Brak tajnych danych specyficznych dla środowiska w kodzie
  • Nie trzeba ręcznie przełączać poświadczeń ani ścieżek logiki
  • Spójne korzystanie z uwierzytelniania opartego na tożsamościach w różnych środowiskach

Azure-First uwierzytelnianie za pomocą identyfikatora Entra firmy Microsoft

Ponieważ aplikacje w chmurze są skalowane w złożoności i integrowane z większą większa ilością usług, bezpieczeństwo i usprawnione uwierzytelnianie staje się niezbędne. Platforma Azure oferuje model tożsamości „Azure-przede wszystkim” za pośrednictwem Microsoft Entra ID, umożliwiając ujednolicone zarządzanie tożsamościami i bezproblemową integrację z usługami Azure dla bezpiecznego uwierzytelniania bez poświadczeń.

Zamiast ręcznie zarządzać wpisami tajnymi lub osadzać poświadczenia w kodzie aplikacji — praktyka podatna na zagrożenia bezpieczeństwa — identyfikator Entra firmy Microsoft umożliwia aplikacjom bezpieczne uwierzytelnianie przy użyciu tożsamości zarządzanych.

Najważniejsze korzyści wynikające z tożsamości zarządzanych Microsoft Entra są następujące:

• Brak wpisów tajnych w kodzie

  Aplikacje nie wymagają już zakodowanych na stałe parametrów połączenia, wpisów tajnych klienta ani kluczy.

• Wbudowana tożsamość dla aplikacji

  Platforma Azure może automatycznie przypisywać tożsamość zarządzaną do aplikacji, umożliwiając bezpieczny dostęp do usług, takich jak Key Vault, Storage i SQL bez dodatkowych poświadczeń.

• Spójność środowiska

  Ten sam kod i model identyfikacji działają zarówno w środowiskach programowania lokalnego, jak i hostowanego na platformie Azure, przy użyciu DefaultAzureCredential z SDK platformy Azure.

Przepływ tożsamości specyficzny dla środowiska

Aplikacje korzystające z identyfikatora Entra firmy Microsoft do uwierzytelniania korzystają z elastycznego modelu tożsamości, który bezproblemowo działa zarówno w środowiskach deweloperskich hostowanych na platformie Azure, jak i w lokalnych środowiskach deweloperskich. Ta spójność jest osiągana przy użyciu zestawu Azure SDK DefaultAzureCredential, który automatycznie wybiera odpowiednią metodę tożsamości na podstawie środowiska.

Środowisko platformy Azure

Po wdrożeniu aplikacji na platformie Azure:

• Tożsamość zarządzana jest automatycznie przypisywana do aplikacji.
• Platforma Azure obsługuje wystawianie tokenów i cykl życia poświadczeń wewnętrznie — nie są wymagane żadne ręczne wpisy tajne.
• Aplikacja używa zasad dostępu Role-Based Access Control (RBAC) lub Key Vault w celu uzyskania dostępu do usług

Lokalne środowisko projektowe

Podczas lokalnego rozwoju:

• Główna jednostka zarządzania usługą pełni rolę identyfikatora aplikacji.
• Deweloperzy uwierzytelniają się przy użyciu interfejsu wiersza polecenia platformy Azure (az login), zmiennych środowiskowych lub integracji programu Visual Studio/VS Code.
• Ten sam kod aplikacji jest uruchamiany bez modyfikacji — zmienia się tylko źródło tożsamości.

W obu środowiskach zestawy SDK platformy Azure używają DefaultAzureCredentialelementu , który abstrahuje od źródła tożsamości i automatycznie wybiera właściwą metodę.

Najlepsze rozwiązania dotyczące bezpiecznego programowania

Chociaż istnieje możliwość ustawienia tajemnic jako zmiennych środowiskowych (na przykład za pośrednictwem ustawień aplikacji Azure), takie podejście ma wady:

• Trzeba ręcznie replikować sekrety w środowiskach lokalnych.
• Istnieje ryzyko wycieku tajnych informacji do systemu zarządzania wersjami.
• Do odróżnienia środowisk może być wymagana dodatkowa logika.

Zamiast tego zalecane jest następujące podejście:

• Użyj usługi Key Vault do przechowywania kluczy API innych firm i sekretów.
• Przypisz tożsamość zarządzaną do wdrożonej aplikacji.
• Zastosuj głównego użytkownika usługi do rozwoju lokalnego i przypisz jej te same prawa dostępu.
• Użyj DefaultAzureCredential w kodzie do abstrakcji logiki uwierzytelniania.
• Unikaj przechowywania lub rejestrowania poświadczeń.

Przepływ uwierzytelniania w praktyce

Oto jak działa uwierzytelnianie w czasie wykonywania:

• Kod tworzy instancję DefaultAzureCredential.
• To poświadczenie służy do instancjowania klienta (na przykład SecretClient, QueueServiceClient).
• Gdy aplikacja wywołuje metodę (na przykład get_secret()), klient używa poświadczeń do uwierzytelnienia żądania.
• Platforma Azure weryfikuje tożsamość i sprawdza, czy ma ona prawidłową rolę lub zasady do wykonania operacji.

Ten przepływ zapewnia, że aplikacja może bezpiecznie uzyskiwać dostęp do usług platformy Azure bez osadzania wpisów tajnych w kodzie lub plikach konfiguracji. Umożliwia również bezproblemowe przełączanie się między lokalnym programowaniem i wdrażaniem w chmurze bez konieczności zmieniania logiki uwierzytelniania.

część 3 — implementacja interfejsu API innej firmy >>>