Udostępnij za pośrednictwem

Podejścia architektury do obsługi tożsamości w rozwiązaniach wielodostępnych

  • Artykuł

Prawie wszystkie rozwiązania wielodostępne wymagają systemu tożsamości. W tym artykule omówiono typowe składniki tożsamości, w tym uwierzytelnianie i autoryzację, oraz omówiono sposób stosowania tych składników w rozwiązaniu wielodostępnym.

Uwaga

Zapoznaj się z zagadnieniami dotyczącymi architektury tożsamości w rozwiązaniu wielodostępnym, aby dowiedzieć się więcej o kluczowych wymaganiach i decyzjach, które należy podjąć, przed rozpoczęciem tworzenia systemu tożsamości dla rozwiązania wielodostępnego.

Uwierzytelnianie

Uwierzytelnianie to proces, za pomocą którego jest ustanawiana tożsamość użytkownika. Podczas tworzenia rozwiązania wielodostępnego istnieją specjalne zagadnienia i podejścia do kilku aspektów procesu uwierzytelniania.

Federacja

Może być konieczne sfederowanie z innymi dostawcami tożsamości (IdPs). Federacja może służyć do włączania następujących scenariuszy:

  • Logowanie społecznościowe, takie jak umożliwienie użytkownikom korzystania z konta Google, Facebook, GitHub lub osobistego konta Microsoft.
  • Katalogi specyficzne dla dzierżawy, takie jak umożliwienie dzierżawcom sfederowania aplikacji z własnymi dostawcami tożsamości, dzięki czemu nie muszą zarządzać kontami w wielu miejscach.

Aby uzyskać ogólne informacje na temat federacji, zobacz Wzorzec tożsamości federacyjnej.

Jeśli zdecydujesz się obsługiwać dostawców tożsamości specyficznych dla dzierżawy, upewnij się, że wyjaśnisz, które usługi i protokoły są potrzebne do obsługi. Czy na przykład będziesz obsługiwać protokół OpenID Connect i protokół SAML (Security Assertion Markup Language)? Czy też będziesz obsługiwać tylko federację z wystąpieniami firmy Microsoft Entra?

Podczas implementowania dowolnego dostawcy tożsamości należy wziąć pod uwagę każdą skalę i limity, które mogą mieć zastosowanie. Jeśli na przykład używasz usługi Azure Active Directory (Azure AD) B2C jako własnego dostawcy tożsamości, może być konieczne wdrożenie zasad niestandardowych w celu sfederowania z określonymi typami dostawców tożsamości dzierżawy. Usługa Azure AD B2C ogranicza liczbę zasad niestandardowych, które można wdrożyć, co może ograniczyć liczbę dostawców tożsamości specyficznych dla dzierżawy, z którymi można się sfederować.

Można również rozważyć udostępnienie federacji jako funkcji, która ma zastosowanie tylko do klientów w wyższej warstwie produktu.

Logowanie jednokrotne

Środowiska logowania jednokrotnego umożliwiają użytkownikom bezproblemowe przełączanie się między aplikacjami bez monitowania o ponowne uwierzytelnienie w każdym momencie.

Gdy użytkownicy odwiedzają aplikację, aplikacja kieruje ich do dostawcy tożsamości. Jeśli dostawca tożsamości widzi, że ma istniejącą sesję, wystawia nowy token bez konieczności interakcji użytkowników z procesem logowania. Model tożsamości federacyjnej obsługuje środowiska logowania jednokrotnego, umożliwiając użytkownikom korzystanie z jednej tożsamości w wielu aplikacjach.

W rozwiązaniu wielodostępnym możesz również włączyć inną formę logowania jednokrotnego. Jeśli użytkownicy mają uprawnienia do pracy z danymi dla wielu dzierżaw, może być konieczne zapewnienie bezproblemowego środowiska, gdy użytkownicy zmienią kontekst z jednej dzierżawy na inną. Zastanów się, czy musisz obsługiwać bezproblemowe przejścia między dzierżawami, a jeśli tak, czy dostawca tożsamości musi ponownie uruchomić tokeny z określonymi oświadczeniami dzierżawy. Na przykład użytkownik, który zalogował się do witryny Azure Portal, może przełączać się między różnymi katalogami firmy Microsoft Entra, co powoduje ponowne uwierzytelnienie, i ponownie generuje token z nowo wybranego wystąpienia firmy Microsoft Entra.

Ocena ryzyka związanego z logowaniem

Nowoczesne platformy tożsamości obsługują ocenę ryzyka podczas procesu logowania. Jeśli na przykład użytkownik loguje się z nietypowej lokalizacji lub urządzenia, system uwierzytelniania może wymagać dodatkowych kontroli tożsamości, takich jak uwierzytelnianie wieloskładnikowe (MFA), zanim umożliwi kontynuowanie żądania logowania.

Zastanów się, czy dzierżawcy mogą mieć różne zasady ryzyka, które należy zastosować podczas procesu uwierzytelniania. Jeśli na przykład masz niektóre dzierżawy w branży wysoce regulowanej, mogą mieć różne profile ryzyka i wymagania dla dzierżaw, którzy pracują w mniej regulowanych środowiskach. Możesz też zezwolić dzierżawcom na wyższe warstwy cenowe na określanie bardziej restrykcyjnych zasad logowania niż dzierżawcy, którzy kupują niższą warstwę usługi.

Jeśli musisz obsługiwać różne zasady ryzyka dla każdej dzierżawy, system uwierzytelniania musi wiedzieć, do której dzierżawy loguje się użytkownik, aby można było zastosować odpowiednie zasady.

Jeśli Dostawca tożsamości obejmuje te możliwości, rozważ użycie natywnych funkcji oceny ryzyka logowania dostawcy tożsamości. Te funkcje mogą być złożone i podatne na błędy, aby zaimplementować samodzielnie.

Alternatywnie, jeśli sfederujesz się z własnymi dostawcami tożsamości dzierżaw, można zastosować własne ryzykowne zasady ograniczania ryzyka logowania i mogą kontrolować zasady i mechanizmy kontroli, które powinny być wymuszane. Jednak ważne jest, aby uniknąć nieumyślnego dodawania niepotrzebnych obciążeń do użytkownika, takich jak wymaganie dwóch wyzwań związanych z uwierzytelnianiem wieloskładnikowym — jednego od dostawcy tożsamości głównej użytkownika i jednego od własnego. Upewnij się, że rozumiesz, w jaki sposób federacja współdziała z poszczególnymi dostawcami tożsamości dzierżawy i zastosowanymi przez nich zasadami.

Personifikacja

Personifikacja umożliwia użytkownikowi założenie tożsamości innego użytkownika bez użycia poświadczeń tego użytkownika.

Ogólnie rzecz biorąc, personifikacja jest niebezpieczna i może być trudna do zaimplementowania i kontrolowania. Jednak w niektórych scenariuszach personifikacja jest wymagana. Jeśli na przykład pracujesz z oprogramowaniem jako usługą (SaaS), personel pomocy technicznej może wymagać przyjęcia tożsamości użytkownika, aby mógł zalogować się jako użytkownik i rozwiązać problem.

Jeśli zdecydujesz się zaimplementować personifikację, rozważ sposób inspekcji jej użycia. Upewnij się, że dzienniki zawierają zarówno rzeczywistego użytkownika, który wykonał akcję, jak i identyfikator użytkownika, którego personifikowali.

Niektóre platformy tożsamości obsługują personifikację jako wbudowaną funkcję lub przy użyciu kodu niestandardowego. Na przykład w usłudze Azure AD B2C można dodać oświadczenie niestandardowe dla personifikowanego identyfikatora użytkownika lub zastąpić oświadczenie identyfikatora podmiotu w wystawionych tokenach.

Autoryzacja

Autoryzacja to proces określania, co użytkownik może zrobić.

Dane autoryzacji można przechowywać w kilku miejscach, w tym w następujących lokalizacjach:

  • W dostawcy tożsamości. Jeśli na przykład używasz identyfikatora Entra firmy Microsoft jako dostawcy tożsamości, możesz użyć funkcji takich jak role aplikacji i grupy do przechowywania informacji o autoryzacji. Następnie aplikacja może użyć skojarzonych oświadczeń tokenu, aby wymusić reguły autoryzacji.
  • W aplikacji. Możesz utworzyć własną logikę autoryzacji, a następnie przechowywać informacje o tym, co każdy użytkownik może zrobić w bazie danych lub podobnym systemie magazynu. Następnie można zaprojektować szczegółowe kontrolki na potrzeby autoryzacji na poziomie ról lub zasobów.

W większości wielodostępnych rozwiązań przypisania ról i uprawnień są zarządzane przez dzierżawę lub klienta, a nie przez Ciebie jako dostawcę systemu wielodostępnego.

Aby uzyskać więcej informacji, zobacz Role aplikacji.

Dodawanie tożsamości dzierżawy i informacji o roli do tokenów

Rozważ, która część lub części rozwiązania powinna wykonywać żądania autoryzacji, w tym określenie, czy użytkownik może pracować z danymi z określonej dzierżawy.

Typowym podejściem jest osadzanie oświadczenia identyfikatora dzierżawy w tokenie przez system tożsamości. Takie podejście umożliwia aplikacji sprawdzenie oświadczenia i sprawdzenie, czy użytkownicy pracują z dzierżawą, do której mają dostęp. Jeśli używasz modelu zabezpieczeń opartego na rolach, możesz rozszerzyć token z informacjami o roli, którą użytkownik ma w dzierżawie.

Jeśli jednak jeden użytkownik może uzyskać dostęp do wielu dzierżaw, może być potrzebny sposób na zasygnalizowanie dzierżawy, z którą dzierżawą planuje pracować podczas procesu logowania. Po wybraniu aktywnej dzierżawy dostawca tożsamości może uwzględnić prawidłowe oświadczenie i rolę identyfikatora dzierżawy dla tej dzierżawy w ramach wystawianych przez niego tokenów. Należy również rozważyć, jak użytkownicy mogą przełączać się między dzierżawami, co wymaga wystawiania nowego tokenu.

Autoryzacja oparta na aplikacji

Alternatywne podejście polega na tym, aby system tożsamości był niezależny od identyfikatorów i ról dzierżawy. Użytkownicy są identyfikowani przy użyciu poświadczeń lub relacji federacji, a tokeny nie zawierają oświadczenia identyfikatora dzierżawy. Oddzielna lista lub baza danych zawiera użytkowników, którym udzielono dostępu do każdej dzierżawy. Następnie warstwa aplikacji może sprawdzić, czy określony użytkownik powinien mieć dostęp do danych dla określonej dzierżawy, na podstawie wyszukiwania tej listy.

Używanie identyfikatora Entra firmy Microsoft lub usługi Azure AD B2C

Firma Microsoft udostępnia microsoft Entra ID, Tożsamość zewnętrzna Microsoft Entra i Azure AD B2C, które są platformami tożsamości zarządzanych, których można używać w ramach własnego rozwiązania wielodostępu.

Wiele rozwiązań wielodostępnych to oprogramowanie jako usługa (SaaS). Wybór, czy używać identyfikatora Entra firmy Microsoft, Tożsamość zewnętrzna Microsoft Entra lub usługi Azure AD B2C, zależy po części od sposobu definiowania dzierżaw lub bazy klientów.

  • Jeśli Dzierżawy lub klienci są organizacjami, mogą już używać identyfikatora Entra firmy Microsoft dla usług, takich jak Office 365, Microsoft Teams lub dla własnych środowisk platformy Azure. Możesz utworzyć aplikację wielodostępną we własnym katalogu firmy Microsoft Entra, aby udostępnić rozwiązanie innym katalogom firmy Microsoft Entra. Możesz nawet wyświetlić swoje rozwiązanie w witrynie Azure Marketplace i ułatwić dostęp do organizacji korzystających z identyfikatora Entra firmy Microsoft.
  • Jeśli dzierżawy lub klienci nie używają identyfikatora Entra firmy Microsoft lub jeśli są osobami fizycznymi, a nie organizacjami, rozważ użycie Tożsamość zewnętrzna Microsoft Entra lub usługi Azure AD B2C. Zarówno Tożsamość zewnętrzna Microsoft Entra, jak i Azure AD B2C udostępniają zestaw funkcji do kontrolowania sposobu rejestrowania się i logowania użytkowników. Możesz na przykład ograniczyć dostęp do rozwiązania tylko do użytkowników, których już zaprosiłeś, lub zezwolić na rejestrację samoobsługową. Użyj zasad niestandardowych w usłudze Azure AD B2C, aby w pełni kontrolować sposób interakcji użytkowników z platformą tożsamości. Możesz użyć znakowania niestandardowego i możesz sfederować usługę Azure AD B2C z własną dzierżawą firmy Microsoft Entra, aby umożliwić swoim pracownikom logowanie się. Usługa Azure AD B2C umożliwia również federację z innymi dostawcami tożsamości.
  • Niektóre rozwiązania wielodostępne są przeznaczone dla obu sytuacji wymienionych powyżej. Niektóre dzierżawy mogą mieć własne dzierżawy firmy Microsoft Entra, a inne mogą nie. W tym scenariuszu możesz również użyć usługi Azure AD B2C i użyć zasad niestandardowych, aby zezwolić na logowanie użytkownika z katalogu Microsoft Entra dzierżawy. Jeśli jednak używasz zasad niestandardowych do ustanawiania federacji między dzierżawami, upewnij się, że uwzględniasz limity liczby zasad niestandardowych, których może używać pojedynczy katalog usługi Azure AD B2C.

Aby uzyskać więcej informacji, zobacz Zagadnienia dotyczące korzystania z usługi Azure Active Directory B2C w architekturze wielodostępnej.

Antywzorzecy, aby uniknąć

Kompilowanie lub uruchamianie własnego systemu tożsamości

Tworzenie nowoczesnej platformy tożsamości jest złożone. Istnieje szereg protokołów i standardów do obsługi i łatwo zaimplementować protokół i uwidocznić lukę w zabezpieczeniach. Zmiany standardów i protokołów oraz ciągłe aktualizowanie systemu tożsamości w celu wyeliminowania ataków i obsługi najnowszych funkcji zabezpieczeń. Ważne jest również, aby zapewnić odporność systemu tożsamości, ponieważ wszelkie przestoje mogą mieć poważne konsekwencje dla pozostałej części rozwiązania. Ponadto w większości sytuacji implementacja dostawcy tożsamości nie dodaje korzyści dla firmy i jest to po prostu niezbędna część implementacji usługi wielodostępnej. Lepiej zamiast tego użyć wyspecjalizowanego systemu tożsamości, który jest zbudowany, obsługiwany i zabezpieczony przez ekspertów.

Po uruchomieniu własnego systemu tożsamości należy przechowywać skróty haseł lub inne formy poświadczeń, które stają się kuszące dla osób atakujących. Nawet skrótowanie i łączenie haseł jest często niewystarczającą ochroną, ponieważ moc obliczeniowa dostępna dla osób atakujących może umożliwić naruszenie tych form poświadczeń.

Podczas uruchamiania systemu tożsamości odpowiadasz również za generowanie i dystrybucję kodów uwierzytelniania wieloskładnikowego lub jednorazowego hasła (OTP). Te wymagania oznaczają wówczas, że potrzebny jest mechanizm dystrybucji tych kodów przy użyciu wiadomości SMS lub poczty e-mail. Ponadto odpowiadasz za wykrywanie ataków ataków ukierunkowanych i siłowych, ograniczanie prób logowania, inspekcję itd.

Zamiast kompilować lub uruchamiać własny system tożsamości, dobrym rozwiązaniem jest użycie gotowej usługi lub składnika. Rozważ na przykład użycie identyfikatora Entra firmy Microsoft lub usługi Azure AD B2C, które są platformami tożsamości zarządzanych. Dostawcy platformy tożsamości zarządzanej ponoszą odpowiedzialność za obsługę infrastruktury dla swoich platform i zwykle obsługują bieżące standardy tożsamości i uwierzytelniania.

Nie można wziąć pod uwagę wymagań dzierżawy

Dzierżawcy często mają silne opinie na temat sposobu zarządzania tożsamościami dla używanych przez nich rozwiązań. Na przykład wielu klientów korporacyjnych wymaga federacji z własnymi dostawcami tożsamości, aby włączyć środowiska logowania jednokrotnego i uniknąć zarządzania wieloma zestawami poświadczeń. Inne dzierżawy mogą wymagać uwierzytelniania wieloskładnikowego lub innych form ochrony wokół procesów logowania. Jeśli te wymagania nie zostały zaprojektowane, może to być trudne do modernizacji później.

Przed zakończeniem projektowania systemu tożsamości upewnij się, że rozumiesz wymagania dotyczące tożsamości dzierżawy. Zapoznaj się z zagadnieniami dotyczącymi architektury tożsamości w rozwiązaniu wielodostępnym, aby zrozumieć niektóre specyficzne wymagania, które często pojawiają się.

Conflating users and tenants (Łączenie użytkowników i dzierżaw)

Ważne jest, aby wyraźnie rozważyć, w jaki sposób rozwiązanie definiuje użytkownika i dzierżawę. W wielu sytuacjach relacja może być złożona. Na przykład dzierżawa może zawierać wielu użytkowników, a jeden użytkownik może dołączyć do wielu dzierżaw.

Upewnij się, że masz jasny proces śledzenia kontekstu dzierżawy w aplikacji i żądaniach. W niektórych sytuacjach ten proces może wymagać dołączenia identyfikatora dzierżawy do każdego tokenu dostępu i zweryfikowania identyfikatora dzierżawy w każdym żądaniu. W innych sytuacjach przechowujesz informacje o autoryzacji dzierżawy niezależnie od tożsamości użytkowników i używasz bardziej złożonego systemu autoryzacji, aby zarządzać użytkownikami, którzy mogą wykonywać operacje na których dzierżawach.

Śledzenie kontekstu dzierżawy użytkownika lub tokenu ma zastosowanie do dowolnego modelu dzierżawy, ponieważ tożsamość użytkownika zawsze ma kontekst dzierżawy w ramach rozwiązania wielodostępnego. Dobrym rozwiązaniem jest nawet śledzenie kontekstu dzierżawy podczas wdrażania niezależnych sygnatur dla jednej dzierżawy, która w przyszłości umożliwia weryfikację bazy kodu dla innych form wielodostępności.

Conflating role and resource authorization (Łączenie roli i autoryzacji zasobów)

Ważne jest, aby wybrać odpowiedni model autoryzacji dla rozwiązania. Podejścia do zabezpieczeń oparte na rolach mogą być proste do zaimplementowania, ale autoryzacja oparta na zasobach zapewnia bardziej szczegółową kontrolę. Weź pod uwagę wymagania dzierżawy i czy dzierżawcy muszą autoryzować niektórych użytkowników w celu uzyskania dostępu do określonych części rozwiązania, a nie innych części.

Nie można zapisać dzienników inspekcji

Dzienniki inspekcji to ważne narzędzie do zrozumienia środowiska i sposobu implementowania systemu przez użytkowników. Przeprowadzając inspekcję każdego zdarzenia związanego z tożsamością, często można określić, czy system tożsamości jest atakowany, i można sprawdzić, jak jest używany system. Upewnij się, że zapisujesz i przechowujesz dzienniki inspekcji w systemie tożsamości. Zastanów się, czy dzienniki inspekcji tożsamości rozwiązania powinny być udostępniane dzierżawcom do przejrzenia.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Autorzy zabezpieczeń:

Inni współautorzy:

Następne kroki

Przejrzyj zagadnienia dotyczące architektury dotyczące tożsamości w rozwiązaniu wielodostępnym.