Share via

Odporność za pomocą najlepszych rozwiązań dla deweloperów

  • Artykuł

W tym artykule udostępnimy pewne informacje, które są oparte na naszym doświadczeniu z pracy z dużymi klientami. Możesz rozważyć te zalecenia w projekcie i implementacji usług.

Image shows developer experience components

Korzystanie z biblioteki Microsoft Authentication Library (MSAL)

Biblioteka Microsoft Authentication Library (MSAL) i biblioteka uwierzytelniania sieci Web tożsamości firmy Microsoft dla ASP.NET upraszczają uzyskiwanie, buforowanie i odświeżanie tokenów, których wymaga aplikacja. Te biblioteki są zoptymalizowane specjalnie pod kątem obsługi tożsamości firmy Microsoft, w tym funkcji zwiększających odporność aplikacji.

Deweloperzy powinni wdrażać najnowsze wersje biblioteki MSAL i być na bieżąco. Zobacz , jak zwiększyć odporność uwierzytelniania i autoryzacji w aplikacjach. Jeśli to możliwe, unikaj implementowania własnego stosu uwierzytelniania i używania dobrze znanych bibliotek.

Optymalizowanie odczytów i zapisów katalogu

Usługa katalogowa Azure AD B2C obsługuje miliardy uwierzytelnień dziennie. Jest on przeznaczony do wysokiej szybkości operacji odczytu na sekundę. Zoptymalizuj zapisy, aby zminimalizować zależności i zwiększyć odporność.

Jak zoptymalizować odczyty i zapisy katalogu

  • Unikaj zapisywania funkcji w katalogu podczas logowania: nigdy nie wykonuj zapisu podczas logowania bez warunków wstępnych (klauzula if) w zasadach niestandardowych. Jeden przypadek użycia, który wymaga zapisu podczas logowania, to migracja haseł użytkowników just in time. Unikaj każdego scenariusza wymagającego zapisu podczas każdego logowania. Warunki wstępne w podróży użytkownika będą wyglądać następująco:

    <Precondition Type="ClaimEquals" ExecuteActionsIf="true"> 
<Value>requiresMigration</Value>
...
<Precondition/>

  • Omówienie ograniczania przepustowości: katalog implementuje reguły ograniczania na poziomie aplikacji i dzierżawy. Istnieją dalsze limity szybkości dla operacji Odczytu/GET, Zapisu/POST, Update/PUT i Delete/DELETE, a każda operacja ma różne limity.

    • Zapis w momencie logowania będzie należeć do wpisu POST dla nowych użytkowników lub PUT dla istniejących użytkowników.
    • Niestandardowe zasady, które tworzą lub aktualizują użytkownika podczas każdego logowania, mogą potencjalnie osiągnąć limit liczby żądań PUT lub POST na poziomie aplikacji. Te same limity mają zastosowanie podczas aktualizowania obiektów katalogu za pośrednictwem identyfikatora Entra firmy Microsoft lub programu Microsoft Graph. Podobnie sprawdź odczyty, aby zachować liczbę odczytów przy każdym logowaniu do minimum.
    • Szacowanie szczytowego obciążenia w celu przewidywania szybkości zapisu w katalogu i uniknięcia ograniczania przepustowości. Szacunki dotyczące szczytowego ruchu powinny obejmować oszacowania dotyczące akcji, takich jak rejestracja, logowanie i uwierzytelnianie wieloskładnikowe (MFA). Pamiętaj, aby przetestować zarówno system usługi Azure AD B2C, jak i aplikację pod kątem szczytowego ruchu. Istnieje możliwość, że usługa Azure AD B2C może obsłużyć obciążenie bez ograniczania przepustowości, gdy aplikacje podrzędne lub usługi nie będą obsługiwane.
    • Omówienie i planowanie osi czasu migracji. Podczas planowania migracji użytkowników do usługi Azure AD B2C przy użyciu programu Microsoft Graph należy wziąć pod uwagę limity aplikacji i dzierżawy, aby obliczyć czas potrzebny do ukończenia migracji użytkowników. Jeśli podzielisz zadanie tworzenia użytkownika lub skrypt przy użyciu dwóch aplikacji, możesz użyć limitu dla poszczególnych aplikacji. Nadal musi pozostać poniżej progu dzierżawy.
    • Omówienie wpływu zadania migracji na inne aplikacje. Rozważ ruch na żywo obsługiwany przez inne aplikacje uzależnione, aby upewnić się, że nie powoduje ograniczania przepustowości na poziomie dzierżawy i głodu zasobów dla aplikacji na żywo. Aby uzyskać więcej informacji, zobacz Wskazówki dotyczące ograniczania przepustowości programu Microsoft Graph.
    • Użyj przykładu testu obciążeniowego, aby symulować rejestrację i logowanie.
    • Dowiedz się więcej o limitach i ograniczeniach usługi Azure Active Directory B2C.

Rozszerzanie okresów istnienia tokenu

W mało prawdopodobnym przypadku, gdy usługa uwierzytelniania usługi Azure AD B2C nie może ukończyć nowych rejestracji i logowania, nadal można zapewnić środki zaradcze dla użytkowników, którzy są zalogowani. Dzięki konfiguracji można zezwolić użytkownikom, którzy są już zalogowani, aby nadal korzystać z aplikacji bez żadnych zauważalnych zakłóceń, dopóki użytkownik nie wyloguje się z aplikacji lub limit czasu sesji z powodu braku aktywności.

Wymagania biznesowe i żądane środowisko użytkownika końcowego będą dyktować częstotliwość odświeżania tokenów dla aplikacji internetowych i jednostronicowych (SPA).

Jak przedłużyć okresy istnienia tokenu

  • Aplikacje internetowe: w przypadku aplikacji internetowych, w których token uwierzytelniania jest weryfikowany na początku logowania, aplikacja zależy od pliku cookie sesji, aby nadal rozszerzać ważność sesji. Umożliwia użytkownikom pozostanie zalogowanym przez zaimplementowanie kroczących czasów sesji, które będą nadal odnawiać sesje na podstawie aktywności użytkownika. Jeśli występuje długotrwała awaria wystawiania tokenów, te czasy sesji można zwiększyć w miarę jednorazowej konfiguracji aplikacji. Zachowaj okres istnienia sesji do maksymalnej dozwolonej wartości.
  • SPAs: SPA może zależeć od tokenów dostępu do wywołań do interfejsów API. SPA tradycyjnie używa niejawnego przepływu, który nie powoduje tokenu odświeżania. SPA może używać ukrytego iframe do wykonywania nowych żądań tokenu względem punktu końcowego autoryzacji, jeśli przeglądarka nadal ma aktywną sesję z usługą Azure AD B2C. W przypadku umów SPA dostępnych jest kilka opcji umożliwiających użytkownikowi dalsze korzystanie z aplikacji.
    • Rozszerz czas ważności tokenu dostępu, aby spełnić wymagania biznesowe.
    • Skompiluj aplikację, aby używać bramy interfejsu API jako serwera proxy uwierzytelniania. W tej konfiguracji SPA ładuje się bez uwierzytelniania, a wywołania interfejsu API są wykonywane do bramy interfejsu API. Brama interfejsu API wysyła użytkownika za pośrednictwem procesu logowania przy użyciu udzielenia kodu autoryzacji na podstawie zasad i uwierzytelnia użytkownika. Następnie sesja uwierzytelniania między bramą interfejsu API a klientem jest utrzymywana przy użyciu pliku cookie uwierzytelniania. Interfejsy API bramy usług interfejsów API przy użyciu tokenu uzyskanego przez bramę interfejsu API (lub innej metody uwierzytelniania bezpośredniego, takiej jak certyfikaty, poświadczenia klienta lub klucze interfejsu API).
    • Migrowanie spa z niejawnego udzielenia do przepływu udzielania kodu autoryzacji przy użyciu klucza dowodowego dla wymiany kodu (PKCE) i współużytkowania zasobów między źródłami (CORS). Przeprowadź migrację aplikacji z MSAL.js 1.x do MSAL.js 2.x, aby zrealizować odporność aplikacji internetowych.
    • W przypadku aplikacji mobilnych zaleca się wydłużenie okresu istnienia tokenu odświeżania i dostępu.
  • Aplikacje zaplecza lub mikrousług: ponieważ aplikacje zaplecza (demona) nie są interakcyjne i nie znajdują się w kontekście użytkownika, perspektywa kradzieży tokenów jest znacznie zmniejszona. Zaleca się zachowanie równowagi między zabezpieczeniami a okresem istnienia i ustawieniem długiego okresu istnienia tokenu.

Konfigurowanie logowania jednokrotnego

W przypadku logowania jednokrotnego użytkownicy logować się raz przy użyciu jednego konta i uzyskiwać dostęp do wielu aplikacji. Aplikacja może być aplikacją internetową, mobilną lub jednostronicową (SPA), niezależnie od platformy lub nazwy domeny. Gdy użytkownik początkowo loguje się do aplikacji, usługa Azure AD B2C utrzymuje sesję opartą na plikach cookie.

Po kolejnych żądaniach uwierzytelniania usługa Azure AD B2C odczytuje i weryfikuje sesję opartą na plikach cookie i wystawia token dostępu bez monitowania użytkownika o ponowne zalogowanie. Jeśli logowanie jednokrotne jest skonfigurowane z ograniczonym zakresem w zasadach lub aplikacji, później dostęp do innych zasad i aplikacji będzie wymagał nowego uwierzytelniania.

Jak skonfigurować logowanie jednokrotne

Skonfiguruj logowanie jednokrotne dla całej dzierżawy (ustawienie domyślne), aby umożliwić wielu aplikacjom i przepływom użytkowników w dzierżawie współużytkowania tej samej sesji użytkownika. Konfiguracja dla całej dzierżawy zapewnia największą odporność na nowe uwierzytelnianie.

Praktyki bezpiecznego wdrażania

Najczęstszymi zakłóceniami usługi są zmiany kodu i konfiguracji. Wdrażanie procesów i narzędzi ciągłej integracji i ciągłego wdrażania (CICD) ułatwia szybkie wdrażanie na dużą skalę i zmniejsza błędy człowieka podczas testowania i wdrażania w środowisku produkcyjnym. Wdrażanie CICD w celu zmniejszenia, wydajności i spójności błędów. Usługa Azure Pipelines to przykład CICD.

Ochrona przed botami

Chroń aplikacje przed znanymi lukami w zabezpieczeniach, takimi jak ataki DDoS (Distributed Denial of Service), iniekcje SQL, wykonywanie skryptów między witrynami, zdalne wykonywanie kodu i wiele innych, jak opisano w OWASP Top 10. Wdrożenie zapory aplikacji internetowej (WAF) może bronić przed typowymi programami wykorzystującymi luki w zabezpieczeniach i lukami w zabezpieczeniach.

Rotacja wpisów tajnych

Usługa Azure AD B2C używa wpisów tajnych dla aplikacji, interfejsów API, zasad i szyfrowania. Wpisy tajne zabezpieczają uwierzytelnianie, interakcje zewnętrzne i magazyn. National Institute of Standards and Technology (NIST) nazywa przedział czasu, w którym określony klucz jest autoryzowany do użytku przez legalne podmioty kryptograficzne. Wybierz odpowiednią długość cryptoperiod , aby zaspokoić potrzeby biznesowe. Deweloperzy muszą ręcznie ustawić wygasanie i obracać wpisy tajne przed wygaśnięciem.

Jak zaimplementować rotację wpisów tajnych

  • Użyj tożsamości zarządzanych dla obsługiwanych zasobów, aby uwierzytelnić się w dowolnej usłudze obsługującej uwierzytelnianie firmy Microsoft Entra. W przypadku korzystania z tożsamości zarządzanych można automatycznie zarządzać zasobami, w tym rotacją poświadczeń.
  • Utwórz spis wszystkich kluczy i certyfikatów skonfigurowanych w usłudze Azure AD B2C. Ta lista może zawierać klucze używane w zasadach niestandardowych, interfejsach API, tokenie identyfikatora podpisywania i certyfikatach dla języka SAML.
  • Korzystając z CICD, obracaj tajemnice, które wkrótce wygasną w ciągu dwóch miesięcy od przewidywanego sezonu szczytowego. Zalecana maksymalna kryptografia kluczy prywatnych skojarzonych z certyfikatem wynosi jeden rok.
  • Proaktywne monitorowanie i obracanie poświadczeń dostępu do interfejsu API, takich jak hasła i certyfikaty.

Testowanie interfejsów API REST

W kontekście odporności testowanie interfejsów API REST musi obejmować weryfikację kodów HTTP, ładunku odpowiedzi, nagłówków i wydajności. Testowanie nie powinno zawierać tylko testów szczęśliwej ścieżki, ale także sprawdzić, czy interfejs API obsługuje scenariusze problemów bezproblemowo.

Jak przetestować interfejsy API

Zalecamy, aby plan testowy obejmował kompleksowe testy interfejsu API. Jeśli planujesz nadchodzący wzrost z powodu promocji lub ruchu wakacyjnego, musisz skorygować testowanie obciążenia przy użyciu nowych szacunków. Przeprowadź testowanie obciążenia interfejsów API i usługi Content Delivery Network (CDN) w środowisku deweloperskim, a nie w środowisku produkcyjnym.

Następne kroki