Publiczny klient i poufne aplikacje klienckie
Biblioteka Microsoft Authentication Library (MSAL) definiuje dwa typy klientów; klienci publiczni i klienci poufni. Klient to jednostka oprogramowania, która ma unikatowy identyfikator przypisany przez dostawcę tożsamości. Typy klientów są rozróżniane przez możliwość bezpiecznego uwierzytelniania za pomocą serwera autoryzacji i przechowywania poufnych informacji dowodowych tożsamości, aby nie można było uzyskać do niego dostępu lub poznać użytkownika w zakresie jego dostępu.
| Publiczne aplikacje klienckie | Poufne aplikacje klienckie |
|---|---|
 Aplikacja klasyczna |
 Aplikacja internetowa |
 Interfejs API bez przeglądarki |
 Internetowy interfejs API |
 Aplikacja mobilna |
Usługa/demon |
Klient publiczny i autoryzacja klienta poufnego
Podczas badania publicznego lub poufnego charakteru danego klienta oceniamy możliwość potwierdzenia tożsamości tego klienta na serwerze autoryzacji. Jest to ważne, ponieważ serwer autoryzacji musi mieć możliwość zaufania tożsamości klienta w celu wystawienia tokenów dostępu.
Publiczne aplikacje klienckie działają na urządzeniach, takich jak klasyczne, bez przeglądarkowe interfejsy API, aplikacje przeglądarki mobilnej lub klienckiej. Nie mogą być zaufane, aby bezpiecznie przechowywać wpisy tajne aplikacji, dzięki czemu mogą uzyskiwać dostęp tylko do internetowych interfejsów API w imieniu użytkownika. Za każdym razem, gdy źródłowy lub skompilowany kod bajtowy danej aplikacji jest przesyłany w dowolnym miejscu, w jakim może być odczytywany, dezasemblowany lub w inny sposób sprawdzany przez niezaufane strony, jest to klient publiczny. Ponieważ obsługują one również tylko przepływy klientów publicznych i nie mogą przechowywać wpisów tajnych czasu konfiguracji, nie mogą mieć wpisów tajnych klienta.
Poufne aplikacje klienckie działają na serwerach, takich jak aplikacje internetowe, aplikacje internetowego interfejsu API lub aplikacje usługi/demona. Są one uważane za trudne do uzyskania dostępu przez użytkowników lub osoby atakujące i w związku z tym mogą odpowiednio przechowywać wpisy tajne w czasie konfiguracji w celu potwierdzenia tożsamości. Identyfikator klienta jest udostępniany za pośrednictwem przeglądarki internetowej, ale wpis tajny jest przekazywany tylko w kanale wstecznym i nigdy nie jest bezpośrednio udostępniany.
Kiedy należy włączyć przepływ klienta publicznego w rejestracji aplikacji?
Po określeniu typu aplikacji klienckiej, którą tworzysz, możesz zdecydować, czy włączyć publiczny przepływ klienta w rejestracji aplikacji. Domyślnie zezwalaj na publiczny przepływ klienta w rejestracji aplikacji powinien być wyłączony, chyba że tworzysz publiczną aplikację kliencką i korzystasz z następującego protokołu lub funkcji autoryzacji OAuth:
| Protokół autoryzacji OAuth/funkcja | Typ publicznej aplikacji klienckiej | Przykłady/notatki |
|---|---|---|
| Uwierzytelnianie natywne | Tożsamość zewnętrzna Microsoft Entra aplikacji, która wymaga pełnego dostosowania interfejsu użytkownika, w tym elementów projektu, umieszczania logo i układu, zapewniając spójny i markowy wygląd. | Uwaga: Uwierzytelnianie natywne jest dostępne tylko w przypadku rejestracji aplikacji w dzierżawach Tożsamość zewnętrzna Microsoft Entra. Dowiedz się więcej tutaj |
| Przepływ kodu urządzenia | Aplikacje uruchamiane na urządzeniach z ograniczonymi danymi wejściowymi, takimi jak smart TV, urządzenie IoT lub drukarka | |
| Przepływ poświadczeń hasła właściciela zasobu | Aplikacje, które obsługują hasła wprowadzane bezpośrednio przez użytkowników, zamiast przekierowywać użytkowników do witryny internetowej logowania hostowanej przez firmę Entra i umożliwiając aplikacji Entra obsługę hasła użytkownika w bezpieczny sposób. | Firma Microsoft zaleca, aby nie używać przepływu ROPC. W większości scenariuszy dostępne są bezpieczniejsze alternatywy, takie jak przepływ kodu autoryzacji, i zalecane. |
| Przepływ zintegrowanego uwierzytelniania systemu Windows | Aplikacje klasyczne lub mobilne uruchomione w systemie Windows lub na maszynie podłączonej do domeny systemu Windows (microsoft Entra ID lub Microsoft Entra joined) przy użyciu zintegrowanego przepływu uwierzytelniania systemu Windows zamiast menedżera kont sieci Web | Aplikacja klasyczna lub mobilna, która powinna zostać automatycznie zalogowana po zalogowaniu się użytkownika do systemu windows przy użyciu poświadczeń firmy Microsoft Entra |
Wpisy tajne i ich znaczenie w potwierdzaniu tożsamości
Poniżej przedstawiono kilka przykładów sposobu, w jaki klient może udowodnić swoją tożsamość na serwerze autoryzacji:
- Tożsamości zarządzane dla zasobów platformy Azure — w przypadku scenariuszy uwierzytelniania tylko dla aplikacji deweloperzy aplikacji i usług korzystający z platformy Azure mają możliwość odciążenia zarządzania wpisami tajnymi, rotacji i ochrony samej platformy. Dzięki tożsamościom zarządzanym tożsamości są udostępniane i usuwane z zasobami platformy Azure, a nikt, w tym administrator globalny, nie może uzyskać dostępu do podstawowych poświadczeń. Korzystając z tożsamości zarządzanych, można zapobiec ryzyku wycieku wpisów tajnych i umożliwić dostawcy obsługę zabezpieczeń.
- Identyfikator klienta i wpis tajny — w tym wzorcu para wartości jest generowana przez serwer autoryzacji podczas rejestrowania klienta. Identyfikator klienta jest wartością publiczną, która identyfikuje aplikację, podczas gdy wpis tajny klienta jest wartością poufnej używaną do udowodnienia tożsamości aplikacji.
- Potwierdzenie posiadania certyfikatu — infrastruktura kluczy publicznych (PKI), która obejmuje standardy, takie jak X.509, jest podstawową technologią, która umożliwia bezpieczną komunikację przez Internet i stanowi szkielet prywatności w Internecie. Infrastruktura kluczy publicznych służy do wystawiania certyfikatów cyfrowych, które weryfikują tożsamość stron zaangażowanych w komunikację online i jest podstawową technologią, która obsługuje protokoły, takie jak HTTPS, które są powszechnie używane do zabezpieczania ruchu internetowego. Podobnie certyfikaty mogą służyć do zabezpieczania komunikacji między usługami (S2S) na platformie Azure przez włączenie wzajemnego uwierzytelniania między usługami. Obejmuje to, aby każda usługa przedstawiała certyfikat innym jako środek dowodu tożsamości.
- Prezentacja podpisanej asercji — używana w federacji tożsamości obciążenia podpisanych asercji umożliwia wymianę zaufanego tokenu dostawcy tożsamości innej firmy z Platforma tożsamości Microsoft w celu uzyskania tokenów dostępu do wywoływania chronionych zasobów firmy Microsoft Entra. Federacja tożsamości obciążeń może służyć do włączania różnych scenariuszy federacji, w tym usług Azure Kubernetes Service, Amazon Web Services EKS, GitHub Actions i innych.
Kiedy potwierdzanie tożsamości klienta ma znaczenie?
Potwierdzanie tożsamości klienta ma znaczenie w przypadku konieczności zweryfikowania zarówno autentyczności, jak i autoryzacji aplikacji klienckiej przed udzieleniem dostępu do poufnych danych lub zasobów. Przykłady obejmują:
- Kontrolowanie dostępu do interfejsu API — jeśli masz interfejs API mierzony (np. na potrzeby rozliczeń) lub uwidacznia poufne dane lub zasoby, przed udzieleniem dostępu zweryfikujesz tożsamość klienta. Jest to ważne na przykład w przypadku zapewnienia, że tylko autoryzowane aplikacje mają dostęp do interfejsu API i że prawidłowy klient jest rozliczany za użycie mierzonego interfejsu API.
- Ochrona użytkowników przed personifikacją aplikacji — jeśli masz wdrożoną usługę, aplikację dostępną dla użytkowników (np. aplikację internetową opartą na zapleczu), która uzyskuje dostęp do poufnych danych lub usług, korzystając z wpisów tajnych klienta w celu ochrony zasobów używanych przez aplikację, może zapobiec personifikowaniu prawidłowego klienta użytkownikom i eksfiltrowaniu danych lub nadużyciom dostępu.
- Komunikacja typu lokacja-lokacja — jeśli masz wiele usług zaplecza (takich jak podrzędne interfejsy API), które muszą komunikować się ze sobą, możesz zweryfikować tożsamość każdej usługi, aby upewnić się, że są autoryzowani do uzyskiwania dostępu tylko do niezbędnych zasobów do wykonywania funkcji.
Ogólnie rzecz biorąc, potwierdzanie tożsamości klienta ma znaczenie, gdy istnieje potrzeba uwierzytelnienia i autoryzacji klienta niezależnie od użytkownika lub oprócz tego.
Poufne klienci: najlepsze rozwiązania dotyczące zarządzania wpisami tajnymi
Użyj tożsamości zarządzanych, aby uprościć wdrażanie i zabezpieczenia — tożsamości zarządzane zapewniają automatyczną tożsamość zarządzaną w usłudze Microsoft Entra ID dla aplikacji używanych podczas nawiązywania połączenia z zasobami obsługującymi uwierzytelnianie firmy Microsoft Entra. Aplikacje mogą używać tożsamości zarządzanych do uzyskiwania tokenów tylko aplikacji identyfikatora Entra firmy Microsoft bez konieczności zarządzania poświadczeniami. Może to usunąć wiele złożoności związanych z zarządzaniem wpisami tajnymi, jednocześnie zwiększając bezpieczeństwo i odporność. Jeśli używasz tożsamości zarządzanych, większość z poniższych najlepszych rozwiązań jest już dbać o Ciebie.
Używaj bezpiecznego magazynu — przechowuj wpisy tajne klienta w bezpiecznej lokalizacji, takiej jak usługa Key Vault lub zaszyfrowany plik konfiguracji. Unikaj przechowywania wpisów tajnych klienta w postaci zwykłego tekstu lub jako plików zaewidencjonowania w systemach kontroli wersji.
Ogranicz dostęp — ogranicz dostęp do wpisów tajnych klienta tylko autoryzowanym personelowi. Użyj kontroli dostępu opartej na rolach, aby ograniczyć dostęp do wpisów tajnych klienta tylko tym, którzy potrzebują go do wykonywania swoich obowiązków operacyjnych.
Rotacja wpisów tajnych klienta — rotacja wpisów tajnych klienta zgodnie z potrzebami lub zgodnie z harmonogramem może zminimalizować ryzyko użycia naruszonego wpisu tajnego w celu uzyskania nieautoryzowanego dostępu. Po zastosowaniu przedział czasu, w którym klucz jest sugerowany do pozostania w użyciu, jest pod wpływem siły używanego algorytmu kryptograficznego i/lub przestrzegania standardów lub praktyk zgodności z przepisami.
Używanie długich wpisów tajnych i silnego szyfrowania — ściśle związane z poprzednim punktem, przy użyciu silnych algorytmów szyfrowania dla danych przesyłanych (na przewodach) i magazynowanych (na dysku) pomaga zapewnić, że wpisy tajne o wysokim poziomie entropii pozostają mało prawdopodobne, aby były wymuszane przez atak siłowy. Algorytmy, takie jak AES-128 (lub nowsze), mogą pomóc w ochronie danych magazynowanych, podczas gdy RSA-2048 (lub wyższa) może pomóc wydajnie chronić dane podczas przesyłania. Ze względu na stale zmieniający się charakter cyberbezpieczeństwa, zawsze najlepszym rozwiązaniem jest skonsultowanie się z ekspertami ds. zabezpieczeń i okresowe przeglądanie wyboru algorytmów.
Unikaj kodowania wpisów tajnych — nie należy kodować na stałe wpisów tajnych klienta w kodzie źródłowym. Unikanie wpisów tajnych w kodzie źródłowym może zminimalizować wartość nieprawidłowych podmiotów uzyskujących dostęp do kodu źródłowego. Może również uniemożliwić przypadkowe wypchnięcie takich wpisów tajnych do niezabezpieczonych repozytoriów lub udostępnienie współautorom projektu, którzy mogą mieć dostęp do źródła, ale nie dostęp do wpisów tajnych.
Monitorowanie repozytoriów pod kątem wycieku wpisów tajnych — jest to niefortunny fakt, że podczas pracy z kodem źródłowym występują nieprawidłowe ewidencjonacje. Wstępnie zatwierdzane punkty zaczepienia usługi Git to sugerowany sposób zapobiegania przypadkowym ewidencjonowaniu, ale nie jest również zamiennikiem monitorowania. Automatyczne monitorowanie repozytoriów może identyfikować ujawnione wpisy tajne, a wraz z planem rotacji poświadczeń, których bezpieczeństwo zostanie naruszone, może pomóc zmniejszyć liczbę zdarzeń zabezpieczeń.
Monitorowanie podejrzanych działań — monitoruj dzienniki i dzienniki inspekcji pod kątem podejrzanych działań związanych z wpisami tajnymi klienta. Jeśli to możliwe, użyj zautomatyzowanych alertów i procesów reagowania w celu powiadamiania personelu i definiowania awaryjnych nietypowych działań związanych z wpisami tajnymi klienta.
Tworzenie architektury aplikacji z uwzględnieniem tajemnicy klienta — model zabezpieczeń jest tak silny, jak najsłabszy link w łańcuchu. Nie przekazuj poświadczeń zabezpieczeń ani tokenów z poufnych do klientów publicznych, ponieważ może to spowodować przeniesienie danych wpisów tajnych klienta do klienta publicznego, co umożliwia personifikację poufnego klienta.
Korzystanie z aktualnych bibliotek i zestawów SDK z zaufanych źródeł — Platforma tożsamości Microsoft udostępnia różne zestawy SDK klienta i serwera oraz oprogramowanie pośredniczące zaprojektowane w celu zwiększenia produktywności przy zachowaniu bezpieczeństwa aplikacji. Biblioteki, takie jak Microsoft.Identity.Web, upraszczają dodawanie uwierzytelniania i autoryzacji do aplikacji internetowych i interfejsów API w Platforma tożsamości Microsoft. Aktualizowanie zależności pomaga zapewnić, że aplikacje i usługi korzystają z najnowszych innowacji i aktualizacji zabezpieczeń.
Porównywanie typów klientów i ich możliwości
Poniżej przedstawiono pewne podobieństwa i różnice między publicznymi i poufnymi aplikacjami klienckimi:
- Oba typy aplikacji utrzymują pamięć podręczną tokenu użytkownika i mogą uzyskać token w trybie dyskretnym (gdy token jest obecny w pamięci podręcznej). Poufne aplikacje klienckie mają również pamięć podręczną tokenów aplikacji dla tokenów uzyskanych przez samą aplikację.
- Oba typy aplikacji mogą zarządzać kontami użytkowników i pobierać konto z pamięci podręcznej tokenu użytkownika, pobierać konto z jego identyfikatora lub usuwać konto.
- W przypadku biblioteki MSAL publiczne aplikacje klienckie mają cztery sposoby uzyskiwania tokenu za pośrednictwem oddzielnych przepływów uwierzytelniania. Poufne aplikacje klienckie mają tylko trzy sposoby uzyskiwania tokenu i jeden sposób obliczania adresu URL autoryzowanego punktu końcowego dostawcy tożsamości. Identyfikator klienta jest przekazywany raz w trakcie budowy aplikacji i nie musi być przekazywany ponownie, gdy aplikacja uzyskuje token. Aby uzyskać więcej informacji, zobacz Uzyskiwanie tokenów.
Klienci publiczni są przydatni do włączania dostępu delegowanego przez użytkownika do chronionych zasobów, ale nie są w stanie udowodnić własnej tożsamości aplikacji. Z drugiej strony klienci poufni mogą wykonywać zarówno uwierzytelnianie użytkowników, jak i aplikację oraz autoryzację i muszą zostać skompilowane z myślą o zabezpieczeniach, aby upewnić się, że ich wpisy tajne nie są udostępniane klientom publicznym ani innym firmom.
W niektórych przypadkach, takich jak komunikacja typu lokacja-lokacja, infrastruktura, taka jak tożsamości zarządzane, znacznie ułatwia opracowywanie i wdrażanie usług oraz eliminuje znaczną złożoność zwykle związaną z zarządzaniem wpisami tajnymi. Gdy tożsamości zarządzane nie mogą być używane, ważne jest, aby zasady, środki zapobiegawcze i awaryjne były stosowane w celu zabezpieczania wpisów tajnych i reagowania na zdarzenia związane z zabezpieczeniami.
Zobacz też
Aby uzyskać więcej informacji na temat konfiguracji aplikacji i tworzenia wystąpień, zobacz: