Uzyskiwanie autoryzacji dostępu do zasobów
Ten artykuł pomoże Ci, jako deweloper, zrozumieć, jak najlepiej zapewnić zero trust podczas uzyskiwania uprawnień dostępu do zasobów dla aplikacji. Aby uzyskać dostęp do chronionych zasobów, takich jak poczta e-mail lub dane kalendarza, aplikacja wymaga autoryzacji właściciela zasobu. Właściciel zasobu może wyrazić zgodę na żądanie aplikacji lub go odrzucić. Aplikacja otrzyma token dostępu, gdy właściciel zasobu udzieli zgody; Aplikacja nie otrzyma tokenu dostępu, gdy właściciel zasobu odmówi dostępu.
Przegląd koncepcyjny
Za pomocą Platforma tożsamości Microsoft możesz uwierzytelnić i autoryzować aplikacje oraz zarządzać uprawnieniami i zgodą. Zacznijmy od niektórych pojęć:
Uwierzytelnianie (czasami skracane do AuthN) to proces potwierdzania, że żądana tożsamość jest dokładna. Platforma tożsamości Microsoft używa protokołu OpenID Połączenie do obsługi uwierzytelniania. Autoryzacja (czasami skrócona do Uwierzytelniania) przyznaje uwierzytelnionej osobie uprawnienie do wykonywania czegoś. Określa, do jakich danych może uzyskać dostęp uwierzytelniona strona. Platforma tożsamości Microsoft używa protokołu OAuth2.0 do obsługi autoryzacji. Opcje autoryzacji obejmują listy kontroli dostępu (ACL), kontrolę dostępu opartą na rolach i kontrolę dostępu atrybutów (ABAC). Uwierzytelnianie jest często czynnikiem autoryzacji.
Aby uzyskać dostęp do danych, aplikacja może korzystać z delegowanego dostępu (działającego w imieniu zalogowanego użytkownika) lub bezpośredniego dostępu (działającego tylko jako tożsamość własna aplikacji). Dostęp delegowany wymaga uprawnień delegowanych (nazywanych również zakresami); klient i użytkownik muszą być autoryzowane oddzielnie, aby wysłać żądanie. Bezpośredni dostęp może wymagać uprawnień aplikacji (nazywanych również rolami aplikacji); gdy role aplikacji są przyznawane aplikacjom, mogą być nazywane uprawnieniami aplikacji.
Delegowane uprawnienia, używane z delegowanym dostępem, umożliwiają aplikacji działanie w imieniu użytkownika, uzyskiwanie dostępu tylko do tego, do czego użytkownik może uzyskać dostęp. Uprawnienia aplikacji, używane z bezpośrednim dostępem, umożliwiają aplikacji dostęp do dowolnych danych, z którymi jest skojarzone uprawnienie. Tylko administratorzy i właściciele jednostek usługi mogą wyrazić zgodę na uprawnienia aplikacji.
Aplikacje otrzymują uprawnienia za pośrednictwem zgody; użytkownicy lub administratorzy autoryzować aplikację w celu uzyskania dostępu do chronionego zasobu. Monit o wyrażenie zgody zawiera listę uprawnień wymaganych przez aplikację wraz z informacjami o wydawcy.
Właściciele aplikacji zasobów mogą wstępnie uwierzytelniać aplikacje klienckie (w witrynie Azure Portal lub przy użyciu programu PowerShell i interfejsów API, takich jak Microsoft Graph). Mogą udzielać uprawnień do zasobów bez konieczności wyświetlania monitu o wyrażenie zgody dla zestawu uprawnień, które zostały wstępnie uwierzytelnione.
Różnica między uprawnieniami delegowanymi a uprawnieniami aplikacji
Aplikacje działają w dwóch trybach: gdy użytkownik jest obecny (uprawnienia delegowane) i gdy nie ma użytkownika (uprawnienia aplikacji). Gdy użytkownik jest przed aplikacją, musisz działać w imieniu tego użytkownika; Nie należy działać w imieniu samej aplikacji. Gdy użytkownik kieruje aplikację, pełnisz rolę pełnomocnika dla tego użytkownika. Otrzymujesz uprawnienia do działania w imieniu użytkownika, który identyfikuje token.
Aplikacje typu usługi (zadania w tle, demony, procesy serwer-serwer) nie mają użytkowników, którzy mogą się identyfikować ani wpisywać hasła. Wymagają one uprawnienia aplikacji do działania w imieniu siebie (w imieniu aplikacji usługi).
Najlepsze rozwiązania dotyczące autoryzacji aplikacji Zero Trust
Metoda autoryzacji będzie miała uwierzytelnianie jako składnik podczas nawiązywania połączenia z użytkownikiem obecnym w aplikacji i z wywoływanym zasobem. Gdy aplikacja działa w imieniu użytkownika, nie ufamy aplikacji wywołującej, aby poinformować nas, kim jest użytkownik, lub pozwolić aplikacji zdecydować, kim jest użytkownik. Identyfikator entra firmy Microsoft zweryfikuje i przekaże bezpośrednio informacje o użytkowniku w tokenie.
Jeśli musisz zezwolić aplikacji na wywoływanie interfejsu API lub autoryzowanie aplikacji tak, aby aplikacja mogła uzyskać dostęp do zasobu, nowoczesne schematy autoryzacji mogą wymagać autoryzacji za pośrednictwem struktury uprawnień i zgody. Zapoznaj się z najlepszymi rozwiązaniami dotyczącymi zabezpieczeń właściwości aplikacji, które obejmują identyfikator URI przekierowania, tokeny dostępu (używane w przypadku przepływów niejawnych), certyfikaty i wpisy tajne, identyfikator URI identyfikatora aplikacji i własność aplikacji.
Następne kroki
- Dostosowywanie tokenów opisuje informacje, które można otrzymywać w tokenach firmy Microsoft Entra oraz jak dostosować tokeny w celu zwiększenia elastyczności i kontroli przy jednoczesnym zwiększeniu zabezpieczeń zerowego zaufania aplikacji z najniższymi uprawnieniami.
- Konfigurowanie oświadczeń grup i ról aplikacji w tokenach pokazuje, jak skonfigurować aplikacje przy użyciu definicji ról aplikacji i przypisać grupy zabezpieczeń do ról aplikacji w celu zwiększenia elastyczności i kontroli przy jednoczesnym zwiększeniu zabezpieczeń zerowego zaufania aplikacji z najmniejszymi uprawnieniami.
- Opracowanie strategii uprawnień delegowanych ułatwia zaimplementowanie najlepszego podejścia do zarządzania uprawnieniami w aplikacji i opracowywania przy użyciu zasad zero trust.
- Opracowywanie strategii uprawnień aplikacji ułatwia podjęcie decyzji o podejściu uprawnień aplikacji do zarządzania poświadczeniami.
- Podawanie poświadczeń tożsamości aplikacji, gdy nie ma użytkownika , wyjaśnia, dlaczego najlepsze praktyki poświadczeń klienta Zero Trust dla usług (aplikacji innych niż użytkownicy) na platformie Azure to Tożsamości zarządzane dla zasobów platformy Azure.
- Najlepsze rozwiązania dotyczące autoryzacji pomagają zaimplementować najlepsze modele autoryzacji, uprawnień i zgody dla aplikacji.
- Użyj najlepszych rozwiązań dotyczących tworzenia tożsamości zero trust i zarządzania dostępem w cyklu tworzenia aplikacji, aby utworzyć bezpieczne aplikacje.
- Tworzenie aplikacji z podejściem Zero Trust do tożsamości jest kontynuowane w artykule Zero Trust identity and access management development best practices (Najlepsze rozwiązania dotyczące tworzenia tożsamości i zarządzania dostępem do zarządzania dostępem), aby ułatwić korzystanie z podejścia Zero Trust do tożsamości w cyklu życia tworzenia oprogramowania (SDLC).
Opinia
https://aka.ms/ContentUserFeedback.
Dostępne już wkrótce: W 2024 r. będziemy stopniowo wycofywać zgłoszenia z serwisu GitHub jako mechanizm przesyłania opinii na temat zawartości i zastępować go nowym systemem opinii. Aby uzyskać więcej informacji, sprawdź:Prześlij i wyświetl opinię dla