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ę przy użyciu 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 klucza do uwierzytelniania za pomocą zewnętrznego interfejsu API innej firmy.

• Azure Queue Storage

  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 zestawy zasobów Azure (Key Vault i Storage)

• Jeden dla usługi zewnętrznej (API strony trzeciej)

Kluczowe wyzwania związane z uwierzytelnianiem

Tworzenie bezpiecznych aplikacji w chmurze wymaga starannej obsługi poświadczeń, zwłaszcza gdy jest zaangażowanych wiele 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. Taka sytuacja powoduje problem cykliczny: aplikacja potrzebuje poświadczeń w celu uzyskania dostępu do Key Vault, ale musisz bezpiecznie przechowywać te poświadczenia. Bez bezpiecznego rozwiązania ten problem może 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. Obchodź się z tym kluczem z najwyższą ostrożnością:

  • Nigdy nie zakoduj go w kodzie źródłowym lub plikach konfiguracji
  • Nigdy nie loguj go do dzienników stdout, stderr lub aplikacji
  • Przechowuj to tylko w pamięci i uzyskuj do niego dostęp w czasie wykonywania, tuż przed użyciem
  • Po zakończeniu żądania można go szybko usunąć

  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.

  To wymaganie oznacza:

  • Nie osadzaj w kodzie sekretów specyficznych dla środowiska
  • Nie przełączaj ręcznie poświadczeń ani ścieżek logiki
  • Korzystaj z uwierzytelniania opartego na tożsamości w sposób spójny we wszystkich środowiskach

Uwierzytelnianie oparte przede wszystkim na platformie Azure przy użyciu Microsoft Entra ID

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. Azure oferuje model tożsamości oparty na Azure za pośrednictwem Microsoft Entra ID, umożliwiając ujednolicone zarządzanie tożsamościami i bezproblemową integrację z usługami Azure na potrzeby 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 — Microsoft Entra ID 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

  Azure może automatycznie przypisywać tożsamość zarządzaną do aplikacji, dzięki czemu może bezpiecznie uzyskiwać dostęp do usług, takich jak Key Vault, Storage i SQL bez dodatkowych poświadczeń.

• Spójność środowiska

  Ten sam model kodu i tożsamości działa zarówno w lokalnych środowiskach programistycznych, jak i w środowiskach hostowanych na platformie Azure dzięki użyciu elementu DefaultAzureCredential z zestawu Azure SDK.

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. DefaultAzureCredential Azure SDK zapewnia tę spójność, automatycznie wybierając odpowiednią metodę tożsamości na podstawie środowiska.

Środowisko platformy Azure

Podczas wdrażania aplikacji w Azure:

• Aplikacja automatycznie otrzymuje tożsamość zarządzaną.
• Azure wewnętrznie zarządza wystawianiem tokenów i cyklem życia poświadczeń, więc nie musisz obsługiwać żadnych wpisów tajnych.
• Aplikacja uzyskuje dostęp do usług przy użyciu zasad dostępu Role-Based Access Control (RBAC) lub Key Vault.

Lokalne środowisko projektowe

Podczas lokalnego rozwoju:

• Nazwana jednostka usługi pełni funkcję tożsamości aplikacji.
• Deweloperzy uwierzytelniają się przy użyciu Azure CLI (az login), zmiennych środowiskowych lub integracji Visual Studio/VS Code.
• Ten sam kod aplikacji działa bez żadnych modyfikacji — zmienia się jedynie źródło tożsamości.

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

Najlepsze rozwiązania dotyczące bezpiecznego programowania

Chociaż można ustawić wpisy tajne jako zmienne środowiskowe (na przykład w ustawieniach aplikacji platformy Azure), takie podejście ma wady:

• Trzeba ręcznie replikować sekrety w środowiskach lokalnych.
• Istnieje ryzyko wycieku sekretów do systemu kontroli wersji.
• Może być potrzebna dodatkowa logika, aby odróżnić środowiska.

Zamiast tego należy użyć następującego podejścia:

• 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.
• Tego poświadczenia uwierzytelniającego używa się do utworzenia instancji 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.