Zarządzanie tożsamościami i dostępem dla obciążeń SaaS na platformie Azure

Tożsamość aplikacji jest krytycznym obszarem dla obciążeń SaaS, ponieważ służy jako pierwsza linia obrony do ochrony danych. Często jest pomijany dopiero pod koniec projektu, ale wiele decyzji dotyczących innych elementów aplikacji zależy od solidnej strategii tożsamości. Nie lekceważ znaczenia tożsamości w ochronie danych klientów.

W kontekście obciążeń SaaS istnieją dwa różne typy tożsamości.

• Tożsamość aplikacji, znana również jako tożsamość klienta i zarządzanie dostępem (CIAM), umożliwia użytkownikom końcowym uwierzytelnianie i używanie aplikacji SaaS. Istnieją dwie główne metody logowania użytkowników do dostawcy tożsamości aplikacji:

  • Tożsamości federacyjne. Użytkownicy logują się przy użyciu istniejących poświadczeń obsługiwanych przez innego dostawcę tożsamości. Ten dostawca może być dostawcą tożsamości społecznościowych, takim jak Google, Facebook lub LinkedIn, albo dostawcą tożsamości przedsiębiorstwa używanym przez klientów, takim jak Microsoft Entra lub Okta. Konserwacja konta użytkownika jest obowiązkiem dostawcy tożsamości federacyjnej.

  • Tożsamości lokalne. Użytkownicy tworzą konto tylko dla aplikacji. Konto jest zabezpieczone za pomocą nazwy użytkownika i hasła, klucza dostępu lub innych metod uwierzytelniania. Konserwacja konta użytkownika jest Twoim obowiązkiem.

• Tożsamość przedsiębiorstwa to rozwiązanie tożsamości używane do uwierzytelniania użytkowników wewnętrznych i obciążeń w narzędziach zwiększających produktywność firmy, wewnętrznych narzędziach lub usługach oraz usługach platformy Azure. Używasz rozwiązania do obsługi tożsamości przedsiębiorstwa dla użytkowników wewnętrznych i obciążeń, aby uwierzytelnić je w narzędziach zwiększających produktywność firmy, wewnętrznych narzędziach lub usługach i usługach platformy Azure.

  Zapoznaj się z tematem SE:05 Identity and access management (Zarządzanie tożsamościami i dostępem).

Tożsamości aplikacji i przedsiębiorstwa służą różnym celom i mogą używać różnych dostawców tożsamości. Ten artykuł koncentruje się na zagadnieniach projektowych dotyczących tożsamości aplikacji, chociaż oba typy prawdopodobnie będą obecne w środowisku obciążenia SaaS.

Zarządzanie tożsamościami obejmuje dwa powiązane problemy: uwierzytelnianie (weryfikowanie tożsamości użytkownika) i autoryzację (udzielanie uprawnień na podstawie tożsamości). Pierwsze trzy sekcje tego artykułu koncentrują się na uwierzytelnianiu w modelu SaaS. W ostatniej sekcji opisano zagadnienia dotyczące autoryzacji dla dostawców SaaS.

Tożsamość w aplikacji wielodostępnej

Przechowywanie danych dzierżawy oddzielnie w aplikacji wielodostępnej ma kluczowe znaczenie. Ta segmentacja jest oparta na wyborze efektywnego uwierzytelniania i autoryzacji użytkownika. Ponadto wybór modelu dzierżawy znacząco wpływa na decyzje dotyczące dostawcy tożsamości. Określanie priorytetów tożsamości jako obwodu podstawowego.

Zapoznaj się z tematem SE:04 Recommendations for segmentation (Zalecenia dotyczące segmentacji).

Uwagi dotyczące projektowania

Omówienie modeli dzierżawy i wdrażania dla aplikacji. Mogą istnieć niuanse wpływające na strategię tożsamości. Na przykład jest to błędne przekonanie, że wzorzec sygnatur wdrożenia wymaga dostawcy tożsamości w każdej sygnaturze. W przypadku większości dostawców tożsamości często można użyć alternatywnego modelu izolacji.

Po wybraniu dostawcy tożsamości na potrzeby wielodostępności należy ocenić wpływ awarii. Błędy konfiguracji mogą potencjalnie spowodować wyłączenie całej aplikacji dla wszystkich dzierżaw. Rozważ koszty narzutowe na ryzyko potencjalnego promienia wpływu.

Jeśli wdrożysz rozwiązanie w środowisku platformy Azure klienta i zarządzasz nim w ich imieniu, może być konieczne zintegrowanie z dostawcą tożsamości przedsiębiorstwa. Należy jasno zrozumieć te aspekty:

• Typy użytkowników i ich wymagania dotyczące dostępu podczas interakcji z dzierżawami aplikacji. Na przykład użytkownik A może potrzebować dostępu tylko do logowania się do dzierżawy 1, ale użytkownik B może potrzebować dostępu do logowania się do dzierżawy 1 i dzierżawy 2.
• Zgodność z przepisami dotyczącymi rezydencji danych, jeśli mają zastosowanie do dostawcy tożsamości. W niektórych przypadkach dane przechowywane przez dostawcę tożsamości mogą podlegać przepisom. Wielu dostawców tożsamości udostępnia konkretne wskazówki i możliwości dla tego scenariusza. Oceń, czy ten scenariusz jest odpowiedni dla Ciebie i podejmij niezbędne kroki w celu zapewnienia zgodności.

Zalecenia dotyczące projektowania

Zalecenie	Korzyści
Postępuj zgodnie z najlepszymi rozwiązaniami i wytycznymi dostawcy tożsamości dotyczącymi partycjonowania rozwiązania dla wielu dzierżaw.	Izolacja dzierżawy pomaga osiągnąć cele dotyczące zabezpieczeń i zgodności.
Unikaj posiadania wielu kont dla tego samego użytkownika. Użytkownik powinien mieć jedno konto z jednym zestawem poświadczeń, nawet jeśli potrzebują dostępu do wielu dzierżaw. Udziel dostępu do każdej dzierżawy zgodnie z potrzebami, zamiast tworzyć wiele kont dla tego samego użytkownika.	Utworzenie wielu kont dla tego samego użytkownika zwiększa ryzyko bezpieczeństwa i może mylić użytkowników, którzy muszą pamiętać wiele nazw użytkowników i haseł dla tego samego oprogramowania.
Podczas rozważania rezydencji danych zaplanuj przechowywanie danych użytkowników w osobnych lokalizacjach. W przypadku wdrożenia oddzielnej sygnatury wdrożenia dla użytkowników w innych lokalizacjach geograficznych może być również konieczne użycie oddzielnych dostawców tożsamości. Upewnij się, że masz sposób identyfikowania miejsca przechowywania danych użytkowników, aby można było skierować je do odpowiedniego regionu logowania, jeśli zajdzie taka potrzeba.	Będziesz mieć możliwość obsługi wymagań dotyczących zgodności i ulepszania środowiska użytkownika przez kierowanie użytkowników do środowiska logowania, które jest odpowiednie dla ich lokalizacji.

Wybór dostawcy tożsamości

Każdy dostawca tożsamości oferuje unikatowe funkcje, ograniczenia, modele cenowe i wzorce implementacji. Microsoft Entra i Okta to popularne opcje tożsamości jako usługi (IDaaS). Istnieją również inni dostawcy typu open source, tacy jak Keycloak i Authentik.

Uwagi dotyczące projektowania

• Dokumentowanie wymagań dotyczących tożsamości. Zacznij od wyświetlania listy funkcji, których potrzebuje twoja aplikacja i będzie potrzebna w przyszłości. Typowe funkcje, które należy wziąć pod uwagę, obejmują:

• • Obsługa dostawcy tożsamości federacyjnych w celu integracji z rozwiązaniami do obsługi tożsamości klientów. Ta funkcja pozwala uniknąć tworzenia nowych tożsamości.
  • Dostosowywalny przepływ logowania/rejestracji w celu zmodyfikowania wyglądu i działania w celu utrzymania znakowania. Ta funkcja umożliwia również wprowadzanie niestandardowej logiki biznesowej do procesu logowania/rejestracji.
  • Rozdzielenie danych dzierżawy na odrębne silosy w celu zachowania izolacji dzierżawy.
  • Obsługa inspekcji w celu zachowania lub wyeksportowania dzienników logowania na potrzeby zarządzania zabezpieczeniami.

  Ważne

  Podczas oceniania kosztów rozwiązania do obsługi tożsamości należy wziąć pod uwagę planowany wzrost użytkowników. Rozwiązanie może nie pozostać opłacalne lub skalowalne w dłuższej perspektywie, ale na razie może być przydatne. Jeśli zajdzie taka potrzeba, masz plan migracji, którego możesz użyć.

  Na przykład rozwiązanie może być przystępne dla 500 użytkowników, ale niezrównane dla 5 milionów. Jeśli wymaga minimalnej konfiguracji i jest przyjazny dla użytkownika i łatwy do migracji, nadal może to być właściwy wybór, dopóki skalowanie kosztów nie uzasadnia przełączenia do innego rozwiązania.

• Dokładnie zbadaj możliwości dostawcy tożsamości. Upewnij się, że rozwiązanie do obsługi tożsamości jest zgodne z listą wymaganych funkcji. Nawet jeśli obecnie nie potrzebujesz złożonych scenariuszy, takich jak tożsamość federacyjna, rozważ przyszłe potrzeby. W przypadku rozwiązań SaaS typu business-to-business (B2B) tożsamość federacyjna prawdopodobnie będzie konieczna w końcu.

• Czynniki związane z zarządzaniem. Różni dostawcy tożsamości wymagają różnych poziomów obciążenia związanego z zarządzaniem. Dobrze znane rozwiązania IDaaS zwykle mają mniejsze obciążenie, ponieważ obsługują hosting, konserwację i zabezpieczenia. Jednak dodatkowe obciążenie związane z rozwiązaniem typu open source może być opłacalne, jeśli rozwiązanie jest lepiej dopasowane do potrzeb wyspecjalizowanych.

Zalecenia dotyczące projektowania

Zalecenie	Korzyści
Nie twórz własnego rozwiązania do obsługi tożsamości. Tożsamość to wysoce wyspecjalizowany obszar, a tworzenie rozwiązania do obsługi tożsamości jest skomplikowane i kosztowne. Trudno jest utworzyć rozwiązanie do obsługi tożsamości, które jest bezpieczne i niezawodne.	Unikasz antywzorzec tworzenia własnego dostawcy i zwiększasz bezpieczeństwo, niezawodność i wydajność operacyjną rozwiązania.
Utwórz macierz możliwości funkcji oferowanych przez dostawców tożsamości i zamapuj ją na wymagania dotyczące tożsamości.	Zapewnisz możliwość rozwoju bez ograniczenia ograniczonego zestawu funkcji tożsamości.
Preferuj opcje IDaaS dla rozwiązań typu open source. Hostowanie rozwiązania typu open source samodzielnie wiąże się ze znacznym obciążeniem operacyjnym i ryzykiem bezpieczeństwa. Można jednak wybrać tę opcję, aby spełnić określone wymagania dotyczące zgodności, rezydencji danych lub niezawodności, których dostawca nie może spełnić. Aby uzyskać więcej informacji, zobacz Dostawcy tożsamości IDaaS.	Korzystając z dostawcy tożsamości IDaaS, unikasz niepotrzebnej złożoności i możesz skoncentrować swoje wysiłki na podstawowej firmie.

Tożsamość federacyjna

Tożsamość federacyjna, znana również jako logowanie jednokrotne (SSO), umożliwia użytkownikom logowanie się przy użyciu poświadczeń, których już używają w innym miejscu. Tożsamość federacyjna jest włączana przez ustanowienie relacji zaufania między dostawcą tożsamości aplikacji a istniejącym dostawcą tożsamości klienta. Tożsamość federacyjna jest typowym wymaganiem dla rozwiązań SaaS, zwłaszcza w przypadku B2B, ponieważ klienci wolą swoich pracowników używać poświadczeń firmowych. Oferuje ona kilka korzyści dla rozwiązań B2B, takich jak scentralizowane zarządzanie tożsamościami i automatyczne zarządzanie cyklem życia. W produktach B2C SaaS integracja z dostawcami tożsamości społecznościowych jest powszechna, aby umożliwić użytkownikom logowanie się przy użyciu istniejących poświadczeń.

Kompromis: Złożoność i wydajność operacyjna. Pracując z dostawcami tożsamości federacyjnych, odciążasz złożoność zarządzania tożsamościami użytkowników. Jednak poniesiesz koszt integracji z innym dostawcą tożsamości. Zdecyduj, gdzie chcesz skupić swoje działania operacyjne.

Chociaż wdrażanie tożsamości federacyjnej jest początkowo proste, staje się bardziej złożone, ponieważ liczba obsługiwanych dostawców tożsamości wzrasta. Dokładne planowanie jest niezbędne, zwłaszcza jeśli każdy klient korzysta z unikatowego dostawcy tożsamości. Nawet jeśli używają tego samego dostawcy tożsamości, unikatowe relacje zaufania są często wymagane dla każdego klienta z powodu określonych szczegółów konfiguracji.

Ten obraz przedstawia relację między aplikacją, dostawcą tożsamości aplikacji i dostawcami tożsamości podrzędnych, które można wdrożyć przy użyciu federacji tożsamości.

Uwagi dotyczące projektowania

• Szacowanie typów i liczby dostawców tożsamości, których potrzebujesz do obsługi. Może być potrzebna statyczna liczba dostawców tożsamości społecznościowych lub może być potrzebny unikatowych dostawców tożsamości federacyjnych dla każdego klienta. Należy wiedzieć, czy klienci będą używać protokołu OpenID Connect (OIDC), języka SAML (Security Assertion Markup Language) lub obu tych elementów na potrzeby integracji.

• Mapuj środowisko logowania. Wizualizowanie przepływu użytkownika procesu rejestracji i logowania. Należy pamiętać o wszelkich specjalnych wymaganiach, które mogą zmienić projekt przepływu użytkownika. Na przykład:

  • Znakowanie niestandardowe. Białe etykietowanie lub niestandardowe domeny logowania na klienta.

  • Informacje niestandardowe. Zbieranie dodatkowych informacji o użytkowniku podczas rejestracji lub logowania, takich jak wybór dzierżawy dla użytkowników z dostępem do wielu dzierżaw.

  • Wybór dostawcy tożsamości. Jeśli używasz pojedynczego dostawcy tożsamości aplikacji, który ma wielu zaufanych dostawców tożsamości federacyjnych, zdecyduj, jak wybrać dostawcę. Ten wybór można wykonać ręcznie za pomocą przycisku lub automatycznie na podstawie znanych informacji o użytkowniku. Wraz ze wzrostem liczby dostawców wybór automatyczny staje się bardziej praktyczny. Ta funkcja jest znana jako Odnajdywanie obszaru głównego.

Zalecenia dotyczące projektowania

Zalecenie	Korzyści
Wybierz dostawcę tożsamości, który może być skalowany, aby uwzględnić wymaganą liczbę dostawców tożsamości federacyjnych. Należy pamiętać o twardych limitach dostawcy, których nie można przekroczyć.	Upewnij się, że rozwiązanie tożsamości może być skalowane w miarę rozwoju.
Zaplanuj dołączanie każdego dostawcy tożsamości federacyjnej i jak najwięcej automatyzuj proces. Ten wspólny wysiłek między organizacją a klientami obejmuje wymianę informacji w celu ustanowienia relacji zaufania, zazwyczaj za pośrednictwem protokołów OIDC lub SAML.	Integracja tożsamości może zająć trochę czasu i wysiłku zarówno dla Ciebie, jak i Twoich klientów. Planując ten proces, poprawisz wydajność operacyjną.
Odzwierciedla złożoność i koszt tożsamości federacyjnej w cenach i modelu biznesowym. Umożliwienie klientom korzystania z własnego dostawcy tożsamości zwiększa złożoność operacyjną i koszty ze względu na obciążenie związane z utrzymywaniem wielu relacji zaufania tożsamości federacyjnych. W rozwiązaniach SaaS często przedsiębiorstwa płacą za wyższą warstwę, która umożliwia logowanie federacyjne.	Federowanie z dostawcą tożsamości klienta może być ukrytym kosztem w rozwiązaniach SaaS. Planując to, należy unikać nieoczekiwanych kosztów podczas wdrażania.
Zaplanuj sposób wyboru dostawcy tożsamości użytkownika podczas przepływu logowania. Rozważ użycie odnajdywania obszaru głównego. Identyfikator Entra firmy Microsoft udostępnia wbudowane odnajdywanie obszaru głównego.	Usprawnisz środowisko klienta i upewnisz się, że użytkownicy są kierowani do odpowiedniego procesu logowania.

Autoryzacja

Autoryzacja użytkownika ma kluczowe znaczenie dla aplikacji SaaS, które często przechowują dane dla wielu dzierżaw. Jasno zdefiniuj sposób, w jaki użytkownicy będą autoryzowani do uzyskiwania dostępu tylko do swoich danych bez nieumyślnego uzyskiwania dostępu do danych innych dzierżaw. Ponadto należy zapewnić szczegółową autoryzację w ramach dzierżawy, umożliwiając użytkownikom odczytywanie lub uzyskiwanie dostępu do określonych informacji przy jednoczesnym ograniczeniu aktualizacji lub dostępu do innych danych.

Uwagi dotyczące projektowania

• Wybierz odpowiedni model autoryzacji dla przypadku użycia. Istnieją dwa główne typy:

  • Autoryzacja oparta na rolach. Użytkownicy mają przypisane role lub grupy, a określone funkcje są ograniczone do określonych ról. Na przykład administratorzy mogą wykonać dowolną akcję, ale użytkownicy w innych rolach mają ograniczone uprawnienia.
  • Autoryzacja oparta na zasobach. Każdy zasób ma własny zestaw uprawnień. Użytkownik może być administratorem jednego zasobu, ale nie ma dostępu do innego.

• Zdecyduj, gdzie mają być przechowywane dane autoryzacji. Dane autoryzacji dla aplikacji mogą być przechowywane w:

  • Dostawca tożsamości. Korzystaj z wbudowanych grup lub ról, wystawiając uprawnienia jako oświadczenia w tokenie wystawionym dla aplikacji. Aplikacja może następnie wymuszać reguły autoryzacji przy użyciu tych oświadczeń tokenu.
  • Aplikacja. Twórz własną logikę autoryzacji i przechowuj uprawnienia użytkownika w bazie danych lub podobnym systemie, co pozwala na szczegółowe mechanizmy autoryzacji oparte na rolach lub na poziomie zasobów.

  Kompromis: złożoność, elastyczność i bezpieczeństwo. Przechowywanie danych autoryzacji u dostawcy tożsamości i wyświetlanie ich za pośrednictwem oświadczeń tokenów jest zwykle prostsze niż zarządzanie własnym systemem autoryzacji. Jednak autoryzacja oparta na oświadczeniach ogranicza elastyczność i musisz zaakceptować, że oświadczenia są odświeżane tylko wtedy, gdy token zostanie ponownie wystawiony, co może spowodować opóźnienie w stosowaniu zmienionych uprawnień.

• Ocena wpływu zarządzania delegowanego. W większości aplikacji SaaS, zwłaszcza w aplikacjach B2B, rola i zarządzanie uprawnieniami są delegowane do klientów. Bez tej funkcji możesz zwiększyć obciążenie związane z zarządzaniem, jeśli klienci często zmieniają uprawnienia użytkowników.

• Ocena dostępu wielodostępu. W niektórych systemach jeden użytkownik może potrzebować dostępu do danych z wielu dzierżaw. Na przykład doradcy mogą potrzebować dostępu do danych z wielu dzierżaw. Zaplanuj, w jaki sposób klienci będą udzielać dostępu tym użytkownikom i jak przepływ logowania będzie obsługiwał wybieranie i przełączanie się między dzierżawami.

Zalecenia dotyczące projektowania

Zalecenie	Korzyści
Uniemożliwiaj użytkownikom uzyskiwanie dostępu do danych przez granice dzierżawy, chyba że dostęp jest jawnie dozwolony.	Nieautoryzowany dostęp do danych innej dzierżawy, nawet przypadkowy dostęp, może być postrzegany jako poważny incydent zabezpieczeń i ujedno zaufanie klientów do platformy. Blokowanie niepotrzebnego dostępu pomoże uniknąć tych sytuacji.
Jeśli dane są statyczne i zmieniają się rzadko, zapisz je u dostawcy tożsamości. Jeśli podczas korzystania z oprogramowania są wymagane częste zmiany, zapisz dane autoryzacji w aplikacji.	Wybranie najlepszego magazynu danych dla danych autoryzacji zwiększy wydajność operacyjną i pomoże Ci spełnić wymagania dotyczące skalowalności.
Jeśli delegujesz zarządzanie uprawnieniami do klientów, podaj wyraźną metodę zarządzania uprawnieniami. Na przykład utwórz portal internetowy, który jest dostępny tylko dla administratorów dzierżawy w celu zmiany uprawnień użytkownika.	Zapewnisz większą kontrolę swoim klientom i unikniesz niepotrzebnego obciążenia operacyjnego twojego zespołu pomocy technicznej.

Dodatkowe zasoby

Multitenancy to podstawowa metodologia biznesowa projektowania obciążeń SaaS. Te artykuły zawierają więcej informacji na temat zarządzania tożsamościami i dostępem:

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

Następny krok

Dowiedz się więcej na temat wybierania modelu hostingu obliczeniowego, aspektów operacyjnych i sposobu optymalizacji opcji technologicznych, aby ułatwić spełnienie umów i celów dotyczących poziomu usług.

Obszar projektowania: obliczenia dla obciążeń SaaS na platformie Azure