Mapuj żądania do dzierżaw w rozwiązaniu wielodostępnym

Azure

Za każdym razem, gdy żądanie dotrze do aplikacji, musisz określić kontekst dzierżawy, czyli dzierżawę wysyłającą żądanie. Jeśli masz infrastrukturę specyficzną dla dzierżawy, która może być nawet hostowana w różnych regionach geograficznych, musisz dopasować przychodzące żądanie do dzierżawy. Następnie należy przekazać żądanie do infrastruktury fizycznej, która hostuje zasoby tej dzierżawy, jak pokazano poniżej:

Wiele aplikacji wielodostępnych ma również uprawnienia oparte na użytkownikach. Mapowanie dzierżawy to osobne działanie. Musisz znać zarówno użytkownika, który wysyła żądanie, jak i dzierżawę, w której pracuje.

Ten artykuł zawiera wskazówki dla osób podejmujących decyzje techniczne dotyczące podejść, które można wziąć pod uwagę, aby mapować żądania do odpowiedniej dzierżawy oraz kompromisy związane z podejściami.

Uwaga / Notatka

Na tej stronie omówiono głównie aplikacje oparte na protokole HTTP, takie jak witryny internetowe i interfejsy API. Jednak wiele z tych samych podstawowych zasad dotyczy aplikacji wielodostępnych korzystających z innych protokołów komunikacyjnych.

Podejścia do identyfikowania dzierżaw

Istnieje wiele sposobów identyfikowania dzierżawy dla żądania przychodzącego. Każde podejście wymaga sprawdzenia pewnego aspektu żądania przychodzącego.

Nazwy domen

Jeśli używasz nazw domen lub domen podrzędnych specyficznych dla dzierżawy, prawdopodobnie żądania mogą być łatwo mapowane na dzierżawy przy użyciu Host nagłówka, X-Forwarded-Host nagłówka lub innego nagłówka HTTP zawierającego oryginalną nazwę hosta dla każdego żądania.

Należy jednak wziąć pod uwagę następujące pytania:

• Jak użytkownicy będą wiedzieć, która nazwa domeny ma być używana do uzyskiwania dostępu do usługi?
• Czy masz centralny punkt wejścia, taki jak strona docelowa lub strona logowania, którego używają wszyscy dzierżawcy? W jaki sposób użytkownicy będą wybierać dzierżawę, z którą pracują?
• Jakich innych informacji używasz do weryfikowania dostępu do zasobów dzierżawy, takich jak tokeny autoryzacji? Czy tokeny autoryzacji zawierają nazwy domen specyficznych dla dzierżawy?

Właściwości żądania HTTP

Jeśli nie używasz nazw domen specyficznych dla dzierżawy, nadal może być możliwe użycie aspektów żądania HTTP w celu zidentyfikowania dzierżawy, dla której znajduje się określone żądanie. Rozważmy na przykład żądanie HTTP, które identyfikuje nazwę dzierżawy jako tailwindtraders. Może to być przekazywane przy użyciu jednej z następujących metod:

• Struktura ścieżki adresu URL, taka jak https://app.contoso.com/tailwindtraders/.
• Ciąg zapytania w adresie URL, taki jak https://contoso.com/app?tenant=tailwindtraders.
• Niestandardowy nagłówek żądania HTTP, taki jak Tenant-Id: tailwindtraders.

Ważne

Niestandardowe nagłówki żądań HTTP nie są przydatne, gdy żądania HTTP GET są wystawiane z przeglądarki internetowej lub gdy żądania są obsługiwane przez niektóre typy serwerów proxy sieci Web. Niestandardowe nagłówki HTTP należy używać tylko w przypadku operacji GET podczas tworzenia interfejsu API lub jeśli kontrolujesz klienta, który wystawia żądanie i nie ma internetowego serwera proxy zawartego w łańcuchu przetwarzania żądań, który może modyfikować lub usuwać nagłówki.

W przypadku korzystania z tego podejścia należy wziąć pod uwagę następujące pytania:

• Czy użytkownicy będą wiedzieć, jak uzyskać dostęp do usługi? Jeśli na przykład używasz ciągu zapytania do identyfikowania dzierżaw, centralna strona docelowa musi skierować użytkowników do odpowiedniej strony dzierżawy przez dodanie ciągu zapytania?
• Czy masz centralny punkt wejścia, taki jak strona docelowa lub strona logowania, którego używają wszyscy dzierżawcy? Jeśli tak, w jaki sposób użytkownicy będą wybierać dzierżawę, do której potrzebują dostępu?
• Czy aplikacja udostępnia interfejsy API? Czy na przykład aplikacja internetowa jest aplikacją jednostronicową (SPA), czy aplikacją mobilną z zapleczem interfejsu API? Jeśli tak jest, możesz użyć bramy interfejsu API lub zwrotnego serwera proxy do wykonania mapowania dzierżawy.

Roszczenia tokenu

Wiele aplikacji używa protokołów uwierzytelniania i autoryzacji opartych na oświadczeniach, takich jak OAuth 2.0 lub SAML. Te protokoły udostępniają klientom tokeny autoryzacji. Token zawiera zestaw oświadczeń, które są informacjami o aplikacji klienckiej lub użytkowniku. Oświadczenia mogą służyć do przekazywania informacji, takich jak adres e-mail użytkownika. System może następnie dołączyć adres e-mail użytkownika, wyszukać mapowanie typu użytkownik-dzierżawa, a następnie przekazać żądanie do odpowiedniego wdrożenia. Możesz nawet uwzględnić mapowanie dzierżawy w systemie tożsamości i dodać oświadczenie o identyfikatorze dzierżawy do tokenu.

Jeśli używasz oświadczeń do mapowania żądań do dzierżaw, należy wziąć pod uwagę następujące pytania:

• Czy użyjesz oświadczenia, aby zidentyfikować dzierżawę? Którego oświadczenia użyjesz?
• Czy użytkownik może być członkiem wielu dzierżaw? Jeśli jest to możliwe, w jaki sposób użytkownicy będą wybierać dzierżawę, z którą chcą pracować dla określonego żądania?
• Czy istnieje centralny system uwierzytelniania i autoryzacji dla wszystkich dzierżaw? Jeśli nie, w jaki sposób zapewnisz, że wszystkie urzędy tokenów wystawiają spójne tokeny i oświadczenia?

Klucze interfejsu API

Wiele aplikacji uwidacznia interfejsy API. Mogą one być przeznaczone do użytku wewnętrznego w organizacji lub do użytku zewnętrznego przez partnerów lub klientów. Typową metodą uwierzytelniania interfejsów API jest użycie klucza interfejsu API. Klucze interfejsu API są dostarczane z każdym żądaniem. Jeśli zarejestrujesz identyfikator dzierżawy, dla którego został wystawiony klucz, możesz wyszukać identyfikator dzierżawy po użyciu klucza.

Uwaga / Notatka

Klucze interfejsu API nie zapewniają wysokiego poziomu zabezpieczeń, ponieważ muszą być tworzone ręcznie i zarządzane, są one długotrwałe i często używane, a ponieważ nie zawierają oświadczeń. Bardziej nowoczesne i bezpieczne podejście polega na użyciu mechanizmu autoryzacji opartej na oświadczeniach z tokenami krótkotrwałymi, takimi jak OAuth 2.0 lub OpenID Connect.

Klucze interfejsu API można wygenerować na kilka sposobów. Poniżej przedstawiono dwa typowe podejścia:

• Wygeneruj kryptograficznie losową wartość i zapisz ją w tabeli odnośników wraz z identyfikatorem dzierżawy. Po odebraniu żądania system znajdzie klucz interfejsu API w tabeli odnośników, a następnie dopasuje go do identyfikatora dzierżawy.
• Utwórz znaczący ciąg z dołączonym identyfikatorem dzierżawy. Cyfrowo podpisz klucz przy użyciu podejścia takiego jak HMAC. Podczas przetwarzania każdego żądania należy zweryfikować podpis, a następnie wyodrębnić identyfikator dzierżawy.

Weź pod uwagę następujące pytania:

• Jak będą generowane i wystawiane klucze interfejsu API?
• Jak klienci interfejsu API będą bezpiecznie odbierać i przechowywać klucz interfejsu API?
• Czy potrzebujesz kluczy interfejsu API, aby wygasnąć po upływie okresu? Jak będzie obracać klucze interfejsu API klientów bez powodowania przestojów?
• Czy klucze interfejsu API generowane przez klienta zapewniają odpowiedni poziom zabezpieczeń dla interfejsów API?

Uwaga / Notatka

Klucze interfejsu API nie są takie same jak hasła. Klucze interfejsu API muszą być generowane przez system i muszą być unikatowe we wszystkich dzierżawach, aby każdy klucz interfejsu API mógł być unikatowo mapowany na jedną dzierżawę. Bramy interfejsu API, takie jak usługa Azure API Management, mogą generować klucze interfejsu API i zarządzać nimi, weryfikować klucze żądań przychodzących i mapować klucze do poszczególnych subskrybentów interfejsu API.

Certyfikaty klienta

Uwierzytelnianie certyfikatu klienta, nazywane czasem wzajemnym protokołem TLS (mTLS), jest często używane do komunikacji między usługami oraz w przypadku urządzeń nienadzorowanych lub kiosków używanych przez nieuwierzytelnionych użytkowników. Certyfikaty klienta zapewniają bezpieczny sposób uwierzytelniania klientów. Podobnie jak w przypadku tokenów i oświadczeń, certyfikaty klienta udostępniają atrybuty , których można użyć do określenia dzierżawy. Na przykład podmiot certyfikatu może zawierać adres e-mail użytkownika, który może służyć do wyszukiwania dzierżawy.

Podczas planowania używania certyfikatów klienta do mapowania dzierżawy należy wziąć pod uwagę następujące kwestie:

• Jak bezpiecznie wydasz i odnowisz certyfikaty klienta, które są zaufane przez usługę? Certyfikaty klienta mogą być złożone do pracy, ponieważ wymagają specjalnej infrastruktury do zarządzania certyfikatami i wystawiania ich. W przypadku nieprawidłowego obsługi te złożoność może zmniejszyć bezpieczeństwo zamiast go zwiększać.
• Czy certyfikaty klienta będą używane tylko do początkowych żądań logowania, czy dołączone do wszystkich żądań do usługi?
• Czy proces wystawiania certyfikatów i zarządzania nimi stanie się niezarządzany, gdy masz dużą liczbę klientów?
• Jak wdrożysz mapowanie między certyfikatem klienta a dzierżawą?

Odwrotne serwery proxy

Zwrotny serwer proxy, nazywany również serwerem proxy aplikacji, może służyć do kierowania żądań HTTP. Zwrotny serwer proxy akceptuje żądanie z punktu końcowego ruchu przychodzącego i może przekazywać żądanie do jednego z wielu punktów końcowych zaplecza. Odwrotne serwery proxy są przydatne w przypadku aplikacji wielodostępnych, ponieważ mogą wykonywać mapowanie między niektórymi informacjami żądania, odciążając zadanie z infrastruktury aplikacji.

Wiele zwrotnych serwerów proxy może użyć właściwości żądania, aby podjąć decyzję o routingu dzierżawy. Mogą sprawdzić docelową nazwę domeny, ścieżkę adresu URL, ciąg zapytania, nagłówki HTTP, a nawet oświadczenia w tokenach lub częściach treści żądania.

Na platformie Azure są używane następujące typowe serwery proxy odwrotne:

• Usługa Azure Front Door to globalny moduł równoważenia obciążenia i zapora aplikacji internetowej. Używa globalnej sieci brzegowej firmy Microsoft do tworzenia szybkich, bezpiecznych i wysoce skalowalnych aplikacji internetowych. Za pomocą zestawów reguł można wyodrębnić identyfikatory dzierżawy i umieścić je w innej części żądania.
• Usługa Azure Application Gateway to zarządzany internetowy moduł równoważenia obciążenia ruchu, który jest wdrażany w tym samym regionie fizycznym co usługa zaplecza.
• Usługa Azure API Management jest zoptymalizowana pod kątem ruchu interfejsu API. Usługa Azure API Management udostępnia kompleksowy aparat zasad , który zapewnia dużą elastyczność w zakresie wyodrębniania informacji dzierżawy z żądań.
• Technologie komercyjne i open-source (które hostujesz samodzielnie) obejmują nginx, Traefik i HAProxy.

Weryfikacja żądania

Ważne jest, aby aplikacja sprawdzała, czy wszystkie odbierane żądania są autoryzowane dla dzierżawy. Jeśli na przykład aplikacja używa niestandardowej nazwy domeny do mapowania żądań do dzierżawy, aplikacja musi nadal sprawdzać, czy każde żądanie odebrane przez aplikację jest autoryzowane dla tej dzierżawy. Mimo że żądanie zawiera nazwę domeny lub inny identyfikator dzierżawy, nie oznacza to, że należy automatycznie udzielać dostępu. Jeśli używasz protokołu OAuth 2.0, przeprowadzasz walidację, sprawdzając oświadczenia odbiorców i zakresów .

Uwaga / Notatka

Jest to część zasady projektowania zabezpieczeń Zero Trust w programie Microsoft Azure Well-Architected Framework.

Podczas implementowania weryfikacji żądania należy wziąć pod uwagę następujące kwestie:

• Jak autoryzujesz wszystkie żądania do aplikacji? Musisz autoryzować żądania, niezależnie od podejścia, które jest używane do mapowania ich na infrastrukturę fizyczną.
• Używaj zaufanych, powszechnie używanych i dobrze utrzymywanych struktur uwierzytelniania i autoryzacji oraz oprogramowania pośredniczącego zamiast samodzielnego implementowania całej logiki weryfikacji. Na przykład nie twórz logiki weryfikacji podpisu tokenu ani bibliotek kryptograficznych certyfikatów klienta. Zamiast tego użyj funkcji platformy aplikacji (lub znanych zaufanych pakietów), które zostały zweryfikowane i przetestowane.

Wydajność

Logika mapowania dzierżawy jest prawdopodobnie uruchamiana na każdym żądaniu do aplikacji. Zastanów się, jak dobrze proces mapowania dzierżawy będzie skalowany w miarę rozwoju rozwiązania. Jeśli na przykład wykonasz zapytanie dotyczące tabeli bazy danych w ramach mapowania dzierżawy, baza danych będzie obsługiwać dużą ilość obciążenia? Jeśli mapowanie dzierżawy wymaga odszyfrowywania tokenu, wymagania dotyczące obliczeń staną się zbyt wysokie w czasie? Jeśli ruch jest dość skromny, prawdopodobnie nie wpłynie to na ogólną wydajność. Jeśli jednak masz aplikację o dużej skali, obciążenie związane z tym mapowaniem może stać się znaczące.

Pliki cookie sesji

Jednym z podejść do zmniejszenia obciążenia związanego z wydajnością logiki mapowania dzierżawy jest użycie plików cookie sesji. Zamiast wykonywać mapowanie na każde żądanie, rozważ obliczenie informacji tylko w przypadku pierwszego żądania dla każdej sesji. Następnie aplikacja udostępnia klientowi plik cookie sesji. Klient przekazuje plik cookie sesji z powrotem do usługi ze wszystkimi kolejnymi żądaniami klienta w ramach tej sesji.

Uwaga / Notatka

Wiele usług sieciowych i aplikacji na platformie Azure może wystawiać pliki cookie sesji.

Weź pod uwagę następujące pytania:

• Czy możesz użyć plików cookie sesji, aby zmniejszyć obciążenie związane z mapowaniem żądań do dzierżaw?
• Jakich usług używasz do kierowania żądań do wdrożeń fizycznych dla każdej dzierżawy? Czy te usługi obsługują sesje oparte na plikach cookie?

Migracja dzierżawy

Dzierżawy często muszą być przenoszone do nowej infrastruktury w ramach cyklu życia dzierżawy. Po przeniesieniu dzierżawy do nowego wdrożenia punkty końcowe HTTP, do których uzyskują dostęp, mogą ulec zmianie. W takim przypadku należy wziąć pod uwagę, że proces mapowania dzierżawy musi ulec zmianie. Może być konieczne rozważenie następujących czynników:

• Jeśli aplikacja używa nazw domen do mapowania żądań, może również wymagać zmiany DNS w czasie migracji. Zmiana DNS może zająć trochę czasu na propagację do klientów, w zależności od czasu wygaśnięcia (TTL) wpisów DNS w usłudze DNS.
• Jeśli migracja zmieni adresy wszystkich punktów końcowych podczas procesu migracji, rozważ tymczasowe przekierowanie żądań dzierżawy do strony konserwacji, która zostanie automatycznie odświeżona.

Współautorzy

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

Główny autor:

• Daniel Scott-Raynsford | Partner Technologiczny Strateg

Inni współautorzy:

• John Downs | Główny inżynier oprogramowania
• Paolo Salvatori | Główny inżynier klienta, FastTrack dla Platformy Azure
• Arsen Vladimirskiy | Główny inżynier ds. klientów, FastTrack dla Azure

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

Dalsze kroki

Dowiedz się więcej o zagadnieniach dotyczących pracy z nazwami domen w aplikacji wielodostępnej.

Za każdym razem, gdy żądanie dotrze do aplikacji, musisz określić kontekst dzierżawy, czyli dzierżawę wysyłającą żądanie. Jeśli masz infrastrukturę specyficzną dla dzierżawy, która może być nawet hostowana w różnych regionach geograficznych, musisz dopasować przychodzące żądanie do dzierżawy. Następnie należy przekazać żądanie do infrastruktury fizycznej, która hostuje zasoby tej dzierżawy, jak pokazano poniżej:

Wiele aplikacji wielodostępnych ma również uprawnienia oparte na użytkownikach. Mapowanie dzierżawy to osobne działanie. Musisz znać zarówno użytkownika, który wysyła żądanie, jak i dzierżawę, w której pracuje.

Ten artykuł zawiera wskazówki dla osób podejmujących decyzje techniczne dotyczące podejść, które można wziąć pod uwagę, aby mapować żądania do odpowiedniej dzierżawy oraz kompromisy związane z podejściami.

Uwaga / Notatka

Na tej stronie omówiono głównie aplikacje oparte na protokole HTTP, takie jak witryny internetowe i interfejsy API. Jednak wiele z tych samych podstawowych zasad dotyczy aplikacji wielodostępnych korzystających z innych protokołów komunikacyjnych.

Podejścia do identyfikowania dzierżaw

Istnieje wiele sposobów identyfikowania dzierżawy dla żądania przychodzącego. Każde podejście wymaga sprawdzenia pewnego aspektu żądania przychodzącego.

Nazwy domen

Jeśli używasz nazw domen lub domen podrzędnych specyficznych dla dzierżawy, prawdopodobnie żądania mogą być łatwo mapowane na dzierżawy przy użyciu Host nagłówka, X-Forwarded-Host nagłówka lub innego nagłówka HTTP zawierającego oryginalną nazwę hosta dla każdego żądania.

Należy jednak wziąć pod uwagę następujące pytania:

• Jak użytkownicy będą wiedzieć, która nazwa domeny ma być używana do uzyskiwania dostępu do usługi?
• Czy masz centralny punkt wejścia, taki jak strona docelowa lub strona logowania, którego używają wszyscy dzierżawcy? W jaki sposób użytkownicy będą wybierać dzierżawę, z którą pracują?
• Jakich innych informacji używasz do weryfikowania dostępu do zasobów dzierżawy, takich jak tokeny autoryzacji? Czy tokeny autoryzacji zawierają nazwy domen specyficznych dla dzierżawy?

Właściwości żądania HTTP

Jeśli nie używasz nazw domen specyficznych dla dzierżawy, nadal może być możliwe użycie aspektów żądania HTTP w celu zidentyfikowania dzierżawy, dla której znajduje się określone żądanie. Rozważmy na przykład żądanie HTTP, które identyfikuje nazwę dzierżawy jako tailwindtraders. Może to być przekazywane przy użyciu jednej z następujących metod:

• Struktura ścieżki adresu URL, taka jak https://app.contoso.com/tailwindtraders/.
• Ciąg zapytania w adresie URL, taki jak https://contoso.com/app?tenant=tailwindtraders.
• Niestandardowy nagłówek żądania HTTP, taki jak Tenant-Id: tailwindtraders.

Ważne

Niestandardowe nagłówki żądań HTTP nie są przydatne, gdy żądania HTTP GET są wystawiane z przeglądarki internetowej lub gdy żądania są obsługiwane przez niektóre typy serwerów proxy sieci Web. Niestandardowe nagłówki HTTP należy używać tylko w przypadku operacji GET podczas tworzenia interfejsu API lub jeśli kontrolujesz klienta, który wystawia żądanie i nie ma internetowego serwera proxy zawartego w łańcuchu przetwarzania żądań, który może modyfikować lub usuwać nagłówki.

W przypadku korzystania z tego podejścia należy wziąć pod uwagę następujące pytania:

• Czy użytkownicy będą wiedzieć, jak uzyskać dostęp do usługi? Jeśli na przykład używasz ciągu zapytania do identyfikowania dzierżaw, centralna strona docelowa musi skierować użytkowników do odpowiedniej strony dzierżawy przez dodanie ciągu zapytania?
• Czy masz centralny punkt wejścia, taki jak strona docelowa lub strona logowania, którego używają wszyscy dzierżawcy? Jeśli tak, w jaki sposób użytkownicy będą wybierać dzierżawę, do której potrzebują dostępu?
• Czy aplikacja udostępnia interfejsy API? Czy na przykład aplikacja internetowa jest aplikacją jednostronicową (SPA), czy aplikacją mobilną z zapleczem interfejsu API? Jeśli tak jest, możesz użyć bramy interfejsu API lub zwrotnego serwera proxy do wykonania mapowania dzierżawy.

Roszczenia tokenu

Wiele aplikacji używa protokołów uwierzytelniania i autoryzacji opartych na oświadczeniach, takich jak OAuth 2.0 lub SAML. Te protokoły udostępniają klientom tokeny autoryzacji. Token zawiera zestaw oświadczeń, które są informacjami o aplikacji klienckiej lub użytkowniku. Oświadczenia mogą służyć do przekazywania informacji, takich jak adres e-mail użytkownika. System może następnie dołączyć adres e-mail użytkownika, wyszukać mapowanie typu użytkownik-dzierżawa, a następnie przekazać żądanie do odpowiedniego wdrożenia. Możesz nawet uwzględnić mapowanie dzierżawy w systemie tożsamości i dodać oświadczenie o identyfikatorze dzierżawy do tokenu.

Jeśli używasz oświadczeń do mapowania żądań do dzierżaw, należy wziąć pod uwagę następujące pytania:

• Czy użyjesz oświadczenia, aby zidentyfikować dzierżawę? Którego oświadczenia użyjesz?
• Czy użytkownik może być członkiem wielu dzierżaw? Jeśli jest to możliwe, w jaki sposób użytkownicy będą wybierać dzierżawę, z którą chcą pracować dla określonego żądania?
• Czy istnieje centralny system uwierzytelniania i autoryzacji dla wszystkich dzierżaw? Jeśli nie, w jaki sposób zapewnisz, że wszystkie urzędy tokenów wystawiają spójne tokeny i oświadczenia?

Klucze interfejsu API

Wiele aplikacji uwidacznia interfejsy API. Mogą one być przeznaczone do użytku wewnętrznego w organizacji lub do użytku zewnętrznego przez partnerów lub klientów. Typową metodą uwierzytelniania interfejsów API jest użycie klucza interfejsu API. Klucze interfejsu API są dostarczane z każdym żądaniem. Jeśli zarejestrujesz identyfikator dzierżawy, dla którego został wystawiony klucz, możesz wyszukać identyfikator dzierżawy po użyciu klucza.

Uwaga / Notatka

Klucze interfejsu API nie zapewniają wysokiego poziomu zabezpieczeń, ponieważ muszą być tworzone ręcznie i zarządzane, są one długotrwałe i często używane, a ponieważ nie zawierają oświadczeń. Bardziej nowoczesne i bezpieczne podejście polega na użyciu mechanizmu autoryzacji opartej na oświadczeniach z tokenami krótkotrwałymi, takimi jak OAuth 2.0 lub OpenID Connect.

Klucze interfejsu API można wygenerować na kilka sposobów. Poniżej przedstawiono dwa typowe podejścia:

• Wygeneruj kryptograficznie losową wartość i zapisz ją w tabeli odnośników wraz z identyfikatorem dzierżawy. Po odebraniu żądania system znajdzie klucz interfejsu API w tabeli odnośników, a następnie dopasuje go do identyfikatora dzierżawy.
• Utwórz znaczący ciąg z dołączonym identyfikatorem dzierżawy. Cyfrowo podpisz klucz przy użyciu podejścia takiego jak HMAC. Podczas przetwarzania każdego żądania należy zweryfikować podpis, a następnie wyodrębnić identyfikator dzierżawy.

Weź pod uwagę następujące pytania:

• Jak będą generowane i wystawiane klucze interfejsu API?
• Jak klienci interfejsu API będą bezpiecznie odbierać i przechowywać klucz interfejsu API?
• Czy potrzebujesz kluczy interfejsu API, aby wygasnąć po upływie okresu? Jak będzie obracać klucze interfejsu API klientów bez powodowania przestojów?
• Czy klucze interfejsu API generowane przez klienta zapewniają odpowiedni poziom zabezpieczeń dla interfejsów API?

Uwaga / Notatka

Klucze interfejsu API nie są takie same jak hasła. Klucze interfejsu API muszą być generowane przez system i muszą być unikatowe we wszystkich dzierżawach, aby każdy klucz interfejsu API mógł być unikatowo mapowany na jedną dzierżawę. Bramy interfejsu API, takie jak usługa Azure API Management, mogą generować klucze interfejsu API i zarządzać nimi, weryfikować klucze żądań przychodzących i mapować klucze do poszczególnych subskrybentów interfejsu API.

Certyfikaty klienta

Uwierzytelnianie certyfikatu klienta, nazywane czasem wzajemnym protokołem TLS (mTLS), jest często używane do komunikacji między usługami oraz w przypadku urządzeń nienadzorowanych lub kiosków używanych przez nieuwierzytelnionych użytkowników. Certyfikaty klienta zapewniają bezpieczny sposób uwierzytelniania klientów. Podobnie jak w przypadku tokenów i oświadczeń, certyfikaty klienta udostępniają atrybuty , których można użyć do określenia dzierżawy. Na przykład podmiot certyfikatu może zawierać adres e-mail użytkownika, który może służyć do wyszukiwania dzierżawy.

Podczas planowania używania certyfikatów klienta do mapowania dzierżawy należy wziąć pod uwagę następujące kwestie:

• Jak bezpiecznie wydasz i odnowisz certyfikaty klienta, które są zaufane przez usługę? Certyfikaty klienta mogą być złożone do pracy, ponieważ wymagają specjalnej infrastruktury do zarządzania certyfikatami i wystawiania ich. W przypadku nieprawidłowego obsługi te złożoność może zmniejszyć bezpieczeństwo zamiast go zwiększać.
• Czy certyfikaty klienta będą używane tylko do początkowych żądań logowania, czy dołączone do wszystkich żądań do usługi?
• Czy proces wystawiania certyfikatów i zarządzania nimi stanie się niezarządzany, gdy masz dużą liczbę klientów?
• Jak wdrożysz mapowanie między certyfikatem klienta a dzierżawą?

Odwrotne serwery proxy

Zwrotny serwer proxy, nazywany również serwerem proxy aplikacji, może służyć do kierowania żądań HTTP. Zwrotny serwer proxy akceptuje żądanie z punktu końcowego ruchu przychodzącego i może przekazywać żądanie do jednego z wielu punktów końcowych zaplecza. Odwrotne serwery proxy są przydatne w przypadku aplikacji wielodostępnych, ponieważ mogą wykonywać mapowanie między niektórymi informacjami żądania, odciążając zadanie z infrastruktury aplikacji.

Wiele zwrotnych serwerów proxy może użyć właściwości żądania, aby podjąć decyzję o routingu dzierżawy. Mogą sprawdzić docelową nazwę domeny, ścieżkę adresu URL, ciąg zapytania, nagłówki HTTP, a nawet oświadczenia w tokenach lub częściach treści żądania.

Na platformie Azure są używane następujące typowe serwery proxy odwrotne:

• Usługa Azure Front Door to globalny moduł równoważenia obciążenia i zapora aplikacji internetowej. Używa globalnej sieci brzegowej firmy Microsoft do tworzenia szybkich, bezpiecznych i wysoce skalowalnych aplikacji internetowych. Za pomocą zestawów reguł można wyodrębnić identyfikatory dzierżawy i umieścić je w innej części żądania.
• Usługa Azure Application Gateway to zarządzany internetowy moduł równoważenia obciążenia ruchu, który jest wdrażany w tym samym regionie fizycznym co usługa zaplecza.
• Usługa Azure API Management jest zoptymalizowana pod kątem ruchu interfejsu API. Usługa Azure API Management udostępnia kompleksowy aparat zasad , który zapewnia dużą elastyczność w zakresie wyodrębniania informacji dzierżawy z żądań.
• Technologie komercyjne i open-source (które hostujesz samodzielnie) obejmują nginx, Traefik i HAProxy.

Weryfikacja żądania

Ważne jest, aby aplikacja sprawdzała, czy wszystkie odbierane żądania są autoryzowane dla dzierżawy. Jeśli na przykład aplikacja używa niestandardowej nazwy domeny do mapowania żądań do dzierżawy, aplikacja musi nadal sprawdzać, czy każde żądanie odebrane przez aplikację jest autoryzowane dla tej dzierżawy. Mimo że żądanie zawiera nazwę domeny lub inny identyfikator dzierżawy, nie oznacza to, że należy automatycznie udzielać dostępu. Jeśli używasz protokołu OAuth 2.0, przeprowadzasz walidację, sprawdzając oświadczenia odbiorców i zakresów .

Uwaga / Notatka

Jest to część zasady projektowania zabezpieczeń Zero Trust w programie Microsoft Azure Well-Architected Framework.

Podczas implementowania weryfikacji żądania należy wziąć pod uwagę następujące kwestie:

• Jak autoryzujesz wszystkie żądania do aplikacji? Musisz autoryzować żądania, niezależnie od podejścia, które jest używane do mapowania ich na infrastrukturę fizyczną.
• Używaj zaufanych, powszechnie używanych i dobrze utrzymywanych struktur uwierzytelniania i autoryzacji oraz oprogramowania pośredniczącego zamiast samodzielnego implementowania całej logiki weryfikacji. Na przykład nie twórz logiki weryfikacji podpisu tokenu ani bibliotek kryptograficznych certyfikatów klienta. Zamiast tego użyj funkcji platformy aplikacji (lub znanych zaufanych pakietów), które zostały zweryfikowane i przetestowane.

Wydajność

Logika mapowania dzierżawy jest prawdopodobnie uruchamiana na każdym żądaniu do aplikacji. Zastanów się, jak dobrze proces mapowania dzierżawy będzie skalowany w miarę rozwoju rozwiązania. Jeśli na przykład wykonasz zapytanie dotyczące tabeli bazy danych w ramach mapowania dzierżawy, baza danych będzie obsługiwać dużą ilość obciążenia? Jeśli mapowanie dzierżawy wymaga odszyfrowywania tokenu, wymagania dotyczące obliczeń staną się zbyt wysokie w czasie? Jeśli ruch jest dość skromny, prawdopodobnie nie wpłynie to na ogólną wydajność. Jeśli jednak masz aplikację o dużej skali, obciążenie związane z tym mapowaniem może stać się znaczące.

Pliki cookie sesji

Jednym z podejść do zmniejszenia obciążenia związanego z wydajnością logiki mapowania dzierżawy jest użycie plików cookie sesji. Zamiast wykonywać mapowanie na każde żądanie, rozważ obliczenie informacji tylko w przypadku pierwszego żądania dla każdej sesji. Następnie aplikacja udostępnia klientowi plik cookie sesji. Klient przekazuje plik cookie sesji z powrotem do usługi ze wszystkimi kolejnymi żądaniami klienta w ramach tej sesji.

Uwaga / Notatka

Wiele usług sieciowych i aplikacji na platformie Azure może wystawiać pliki cookie sesji.

Weź pod uwagę następujące pytania:

• Czy możesz użyć plików cookie sesji, aby zmniejszyć obciążenie związane z mapowaniem żądań do dzierżaw?
• Jakich usług używasz do kierowania żądań do wdrożeń fizycznych dla każdej dzierżawy? Czy te usługi obsługują sesje oparte na plikach cookie?

Migracja dzierżawy

Dzierżawy często muszą być przenoszone do nowej infrastruktury w ramach cyklu życia dzierżawy. Po przeniesieniu dzierżawy do nowego wdrożenia punkty końcowe HTTP, do których uzyskują dostęp, mogą ulec zmianie. W takim przypadku należy wziąć pod uwagę, że proces mapowania dzierżawy musi ulec zmianie. Może być konieczne rozważenie następujących czynników:

• Jeśli aplikacja używa nazw domen do mapowania żądań, może również wymagać zmiany DNS w czasie migracji. Zmiana DNS może zająć trochę czasu na propagację do klientów, w zależności od czasu wygaśnięcia (TTL) wpisów DNS w usłudze DNS.
• Jeśli migracja zmieni adresy wszystkich punktów końcowych podczas procesu migracji, rozważ tymczasowe przekierowanie żądań dzierżawy do strony konserwacji, która zostanie automatycznie odświeżona.

Współautorzy

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

Główny autor:

• Daniel Scott-Raynsford | Partner Technologiczny Strateg

Inni współautorzy:

• John Downs | Główny inżynier oprogramowania
• Paolo Salvatori | Główny inżynier klienta, FastTrack dla Platformy Azure
• Arsen Vladimirskiy | Główny inżynier ds. klientów, FastTrack dla Azure

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

Dalsze kroki

Dowiedz się więcej o zagadnieniach dotyczących pracy z nazwami domen w aplikacji wielodostępnej.