Podejścia architektoniczne do zarządzania tożsamością w rozwiązaniach multi-tenantowych

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

Uwierzytelnianie

Uwierzytelnianie to proces, który ustanawia tożsamość użytkownika. Podczas tworzenia rozwiązania wielodostępnego należy wziąć pod uwagę różne podejścia do różnych aspektów procesu uwierzytelniania.

Federacja

Może być konieczne zintegrowanie się z zewnętrznymi dostawcami tożsamości (IdPs). Federacja umożliwia włączenie następujących scenariuszy:

• Logowanie społecznościowe, które umożliwia użytkownikom logowanie się przy użyciu konta Google, Facebook, GitHub lub osobistego konta Microsoft

• Katalogi dedykowane, które umożliwiają dzierżawcom integrację aplikacji z własnymi dostawcami tożsamości, aby nie musieli zarządzać kontami w wielu miejscach.

Aby uzyskać więcej informacji, zobacz Wzorzec tożsamości federacyjnej.

Jeśli zdecydujesz się na obsługę dostawców tożsamości specyficznych dla danego najemcy, upewnij się, że wyjaśniasz, które usługi i protokoły obsługuje twoja aplikacja. Na przykład określ, czy należy obsługiwać protokół OpenID Connect i protokół Security Assertion Markup Language, czy też ograniczyć federację do wystąpień identyfikatorów Entra firmy Microsoft.

Podczas implementowania IdP (dostawcy tożsamości) rozważ kwestie skalowania i limity, które mogą mieć zastosowanie. Na przykład twój dostawca tożsamości może mieć możliwość federacji tylko z ograniczoną liczbą innych dostawców tożsamości.

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

Logowanie jednokrotne

Logowanie jednokrotne umożliwia 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 wykryje istniejącą sesję, generuje nowy token bez konieczności interakcji użytkowników z procesem logowania. Model tożsamości federacyjnej obsługuje logowanie jednokrotne, umożliwiając użytkownikom korzystanie z jednej tożsamości w wielu aplikacjach.

W rozwiązaniu wielodostępnym możesz włączyć inną formę logowania jednokrotnego. Jeśli użytkownicy mają uprawnienia dostępu do danych w wielu dzierżawach, może być konieczne zapewnienie bezproblemowego środowiska, gdy użytkownicy zmienią kontekst z jednej dzierżawy na inną. Zastanów się, czy rozwiązanie musi obsługiwać bezproblemowe przejścia między dzierżawami. Jeśli tak, rozważ, czy Dostawca tożsamości powinien ponownie wystawić tokeny z określonymi roszczeniami najemcy. Na przykład gdy użytkownik loguje się do witryny Azure Portal, może przełączać się między różnymi katalogami identyfikatorów Entra firmy Microsoft. To przejście wyzwala ponowne uwierzytelnianie i generuje nowy token z nowo wybranego wystąpienia Microsoft Entra ID.

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. Na przykład, jeśli masz najemców w wysoce regulowanej branży, mogą mieć różne profile ryzyka i wymagania niż najemcy pracujący w mniej regulowanych środowiskach. Możesz też zezwolić najemcom w wyższych przedziałach cenowych na określenie bardziej restrykcyjnych zasad logowania niż najemcom, którzy wykupują niższy przedział cenowy usług.

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 mógł 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, jeśli implementujesz je samodzielnie.

Alternatywnie w przypadku federacji z dostawcami tożsamości dzierżawców można zastosować ryzykowne zasady ograniczania ryzyka logowania, co pozwala im kontrolować zasady wymuszania i kontroli. Na przykład wymaganie dwóch wyzwań uwierzytelniania wieloskładnikowego, jednego od dostawcy tożsamości użytkownika i drugiego od własnego, może utrudnić proces logowania. Upewnij się, że rozumiesz, w jaki sposób federacja współdziała z poszczególnymi dostawcami tożsamości dzierżawy i zasadami, które zostały wprowadzone.

Personifikacja

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

Personifikacja jest ogólnie niebezpieczna i może być trudna do zaimplementowania i kontrolowania. Jednak w niektórych scenariuszach wymagana jest personifikacja. Jeśli na przykład pracujesz w środowisku oprogramowania jako usługi (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 zaimplementujesz personifikację, rozważ przeprowadzenie inspekcji jego użycia. Upewnij się, że dzienniki obejmują zarówno 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. Możesz na przykład dodać niestandardowe roszczenie w Microsoft Entra External ID dla identyfikatora użytkownika, dla którego odbywa się podszycie, lub zastąpić roszczenie identyfikatora podmiotu w wydawanych 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 IdP: Na przykład, jeśli używasz Microsoft Entra ID jako IdP, możesz korzystać z funkcji takich jak role aplikacji i grupy do przechowywania informacji o autoryzacji. Następnie aplikacja może wykorzystać powiązane twierdzenia tokenu do egzekwowania reguł autoryzacyjnych.

• 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 przechowywania. Następnie można zaprojektować szczegółowe kontrolki na potrzeby autoryzacji na poziomie ról lub zasobów.

W większości rozwiązań wielodostępnych klient lub najemca zarządza przypisaniami ról i uprawnień, a nie dostawca systemu wielodostępnego.

Dodanie tożsamości najemcy i informacji o roli do tokenów

Określ, które części rozwiązania powinny obsługiwać żądania autoryzacji. Oceń, czy zezwolić użytkownikowi na dostęp do danych z określonej dzierżawy.

Typowym podejściem jest to, że system tożsamości osadza żądanie identyfikatora dzierżawy w tokenie. Takie podejście umożliwia aplikacji sprawdzenie roszczenia i zweryfikowanie, że użytkownicy pracują z dzierżawcą, do którego mają uprawnienia dostępu. Jeśli korzystasz z modelu zabezpieczeń opartego na rolach, możesz rozszerzyć token, aby uwzględnić informacje o roli użytkownika w ramach najemcy.

Jeśli jednak jeden użytkownik może uzyskać dostęp do wielu dzierżaw, może być potrzebny sposób, aby użytkownicy mogli wskazać, z którą dzierżawą planują pracować podczas procesu logowania. Gdy użytkownik wybierze swojego aktywnego dzierżawcę, dostawca tożsamości może wystawić token zawierający prawidłowe oświadczenie identyfikatora dzierżawcy oraz rolę dla tego dzierżawcy. 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 kontrahentów. Użytkownicy są identyfikowani za pośrednictwem poświadczeń lub relacji federacyjnej. Tokeny nie zawierają oświadczenia o identyfikatorze dzierżawy. Oddzielna lista lub baza danych prowadzi rejestr, którzy użytkownicy mają przyznany dostęp do poszczególnych dzierżaw. Następnie warstwa aplikacji sprawdza, czy określony użytkownik ma uprawnienia dostępu do danych konkretnego najemcy na podstawie tej listy.

Używanie identyfikatora Entra firmy Microsoft lub identyfikatora zewnętrznego

Microsoft Entra ID i External ID to platformy tożsamości zarządzanej, których można używać we własnym wielozadaniowym rozwiązaniu.

Wiele wielodostępnych rozwiązań działa jako SaaS. Wybór korzystania z Microsoft Entra ID lub identyfikatora zewnętrznego zależy częściowo od tego, jak definiujesz swoją dzierżawę lub bazę klientów.

• Jeśli dzierżawy lub klienci są organizacjami, mogą już używać Microsoft Entra ID do usług takich jak Microsoft 365, Microsoft Teams lub dla własnych środowisk platformy Azure. Możesz utworzyć aplikację wielodostępną we własnym katalogu Microsoft Entra ID, aby udostępnić rozwiązanie innym katalogom identyfikatorów Entra firmy Microsoft. Możesz również 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 najemcy lub klienci nie używają Microsoft Entra ID, lub jeśli są osobami fizycznymi zamiast organizacjami, rozważ użycie External ID. Identyfikator zewnętrzny udostępnia funkcje umożliwiające kontrolowanie sposobu rejestrowania się i logowania użytkowników. Możesz na przykład ograniczyć dostęp do rozwiązania tylko do zapraszanych użytkowników lub włączyć rejestrację samoobsługową. Możesz użyć znakowania niestandardowego. Aby umożliwić swoim pracownikom logowanie, możesz zaprosić użytkowników z dzierżawy Microsoft Entra ID jako gości do zewnętrznego identyfikatora za pośrednictwem gościnnego dostępu. Identyfikator zewnętrzny umożliwia również federację z innymi dostawcami tożsamości.

• Niektóre rozwiązania wielodostępne są zaprojektowane z myślą o obu wymienionych wcześniej scenariuszach. Niektórzy najemcy mogą mieć własny identyfikator Entra firmy Microsoft, a inni najemcy mogą ich nie mieć. W tym scenariuszu można użyć identyfikatora zewnętrznego i skorzystać z federacji, aby umożliwić logowanie użytkownika z katalogu Microsoft Entra ID danej dzierżawy.

Antywzorce, których należy unikać

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

Tworzenie nowoczesnej platformy tożsamości jest złożone. Wymaga ona obsługi różnych protokołów i standardów, a nieprawidłowa implementacja może wprowadzać luki w zabezpieczeniach. Ponieważ standardy i protokoły zmieniają się, należy stale aktualizować system tożsamości, aby wyeliminować ataki i uwzględnić najnowsze funkcje zabezpieczeń. Ważne jest również, aby zapewnić odporność systemu tożsamości, ponieważ każdy przestój może mieć poważne konsekwencje dla pozostałej części rozwiązania. W większości scenariuszy implementacja IdP (dostawcy tożsamości) nie przynosi bezpośrednich korzyści firmie, ale jest konieczna do wdrożenia usługi wielodzielnej. Lepiej jest użyć wyspecjalizowanego systemu tożsamości, który eksperci tworzą, obsługują i zabezpieczają.

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ż osoby atakujące mają wystarczającą moc obliczeniową, aby potencjalnie naruszyć te poświadczenia.

Podczas uruchamiania systemu tożsamości odpowiadasz za generowanie i dystrybucję kodów MFA lub jednorazowych haseł. Potrzebujesz mechanizmu wysyłania tych kodów za pośrednictwem wiadomości SMS lub poczty e-mail. Odpowiadasz również za wykrywanie ataków ukierunkowanych i siłowych, ograniczanie prób logowania i utrzymywanie dzienników inspekcji.

Zamiast kompilować własny system tożsamości lub zarządzać nim, najlepiej użyć wstępnie utworzonej usługi lub składnika. Rozważmy na przykład platformy tożsamości zarządzanej, takie jak Microsoft Entra ID lub Identyfikator zewnętrzny. Dostawcy tych platform są odpowiedzialni za obsługę infrastruktury i zwykle zapewniają obsługę bieżących standardów tożsamości i uwierzytelniania.

Brak uwzględnienia wymagań najemców

Dzierżawcy często mają silne preferencje dotyczące sposobu zarządzania tożsamością w używanych przez nich rozwiązaniach. Na przykład wielu klientów korporacyjnych wymaga federacji z własnymi dostawcami tożsamości, aby umożliwić logowanie jednokrotne i uniknąć zarządzania wieloma zestawami poświadczeń. Inni najemcy mogą wymagać uwierzytelniania wieloskładnikowego lub dodatkowych środków zabezpieczeń dla logowania się. Jeśli nie uwzględnisz tych wymagań podczas projektowania, dodanie ich później może być trudne.

Zanim zakończysz projektowanie systemu tożsamości, upewnij się, że rozumiesz wymagania tożsamościowe swoich najemców. Aby uzyskać więcej informacji na temat określonych wymagań, zobacz Zagadnienia architektoniczne związane z tożsamością w rozwiązaniu wielodostępnym.

Łączenie użytkowników i najemców

Ważne jest, aby wyraźnie doprecyzować, w jaki sposób rozwiązanie definiuje użytkownika i najemcę. W wielu scenariuszach relacja może być złożona. Na przykład tenant może zawierać wielu użytkowników, a pojedynczy użytkownik może dołączyć do wielu tenantów.

Upewnij się, że masz jasny proces śledzenia kontekstu dzierżawy w aplikacji i żądaniach. W niektórych scenariuszach ten proces wymaga uwzględnienia identyfikatora dzierżawy w każdym tokenie dostępu i zweryfikowania go w każdym żądaniu. W innych przypadkach informacje o autoryzacji dzierżawy są przechowywane oddzielnie od tożsamości użytkowników. Takie podejście wymaga bardziej złożonego systemu autoryzacji do zarządzania użytkownikami, którzy mogą wykonywać określone operacje w każdej dzierżawie.

Ś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 ś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.

Łączenie roli i autoryzacji zasobów

Ważne jest, aby wybrać model autoryzacji pasujący do twojego rozwiązania. Zabezpieczenia oparte na rolach są proste do zaimplementowania, ale autoryzacja oparta na zasobach zapewnia bardziej szczegółową kontrolę. Oceń wymagania dzierżawy i ustal, czy muszą autoryzować niektórych użytkowników do uzyskiwania dostępu tylko do określonych części rozwiązania.

Nieudane zapisywanie 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 logi audytu tożsamości Twojego rozwiązania powinny być udostępnione najemcom do wglądu.

Współautorzy

Firma Microsoft utrzymuje ten artykuł. Następujący współautorzy napisali ten artykuł.

Główni autorzy

• John Downs | Główny inżynier oprogramowania, wzorce i praktyki platformy Azure
• Daniel Scott-Raynsford | Strateg ds. Technologii Partnerów
• Arsen Vladimirskiy | Główny inżynier klienta, fasttrack dla platformy Azure

Inni współautorzy:

• Jelle Druyts | Główny inżynier klienta, fasttrack dla platformy Azure
• Landon Pierce | Starszy inżynier klienta
• Sander van den Hoven | Starszy strateg technologii partnerskich
• Nick Ward | Starszy architekt rozwiązań w chmurze

Aby wyświetlić niepubliczne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Powiązany zasób

• Kwestie architektoniczne w zakresie tożsamości w rozwiązaniu wielodomenowym