Udostępnij za pośrednictwem

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

  • Artykuł

W tym artykule możesz skorzystać z naszego doświadczenia w pracy z dużymi klientami. Możesz wziąć pod uwagę te zalecenia dotyczące projektowania i implementacji usług.

Biblioteka uwierzytelniania firmy Microsoft

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

Deweloperzy mogą 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. Zamiast tego należy używać dobrze znanych bibliotek.

Optymalizowanie odczytów i zapisów katalogu

Usługa katalogowa Azure AD B2C obsługuje miliardy uwierzytelnień dziennie z wysoką szybkością 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: unikaj wykonywania 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. Nie wymagaj zapisu podczas każdego logowania. Warunki wstępne w podróży użytkownika to:

    <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. Istnieje więcej limitów szybkości dla operacji Odczytu/GET, Zapisu/POST, Update/PUT i Delete/DELETE. Każda operacja ma różne limity.

    • Zapis podczas logowania należy do wpisu POST dla nowych użytkowników lub PUT dla bieżących użytkowników.
    • Niestandardowe zasady, które tworzą lub aktualizują użytkownika podczas każdego logowania, mogą osiągać 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). Przetestuj system usługi Azure AD B2C i aplikację pod kątem szczytowego ruchu. Usługa Azure AD B2C może obsługiwać obciążenie bez ograniczania przepustowości, gdy aplikacje lub usługi podrzędne 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 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. Upewnij się, że pozostaje ona 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 zapewnić brak 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 AD B2C.

Okresy istnienia tokenu

Jeśli usługa uwierzytelniania usługi Azure AD B2C nie może ukończyć nowych rejestracji i logowania się, zapewnij ograniczenie ryzyka dla użytkowników, którzy są zalogowani. W przypadku konfiguracji użytkownicy zalogowani mogą używać aplikacji bez zakłóceń do momentu wylogowania się z aplikacji lub limitu czasu sesji z braku aktywności.

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

Rozszerzanie okresów istnienia tokenu

  • Aplikacje internetowe: w przypadku aplikacji internetowych, w których token uwierzytelniania jest weryfikowany podczas logowania, aplikacja zależy od pliku cookie sesji, aby nadal rozszerzać ważność sesji. Umożliwia użytkownikom pozostanie zalogowanym przez zaimplementowanie kroczącego czasu sesji, które są odnawiane na podstawie aktywności użytkownika. Jeśli występuje długotrwała awaria wystawiania tokenów, te czasy sesji można zwiększyć jako jednorazową konfigurację 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. W przypadku umów SPA zalecamy użycie przepływu kodu autoryzacji z przepływem proof key for Code Exchange (PKCE) jako opcją umożliwiającą użytkownikowi kontynuowanie korzystania z aplikacji. Jeśli SPA korzysta z niejawnego przepływu, rozważ migrację do przepływu kodu autoryzacji za pomocą PKCE. Przeprowadź migrację aplikacji z MSAL.js 1.x do MSAL.js 2.x, aby zrealizować odporność aplikacji internetowych. Niejawny przepływ 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 ma aktywną sesję z usługą Azure AD B2C. W przypadku umów SPA istnieje kilka opcji, które umożliwiają użytkownikowi dalsze korzystanie z aplikacji.
    • Rozszerz czas ważności tokenu dostępu.
    • 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. Sesja uwierzytelniania między bramą interfejsu API a klientem jest utrzymywana przy użyciu pliku cookie uwierzytelniania. Brama interfejsu API obsługuje interfejsy API przy użyciu tokenu uzyskanego przez bramę interfejsu API lub inną metodę bezpośredniego uwierzytelniania, taką jak certyfikaty, poświadczenia klienta lub klucze interfejsu API.
    • Przejdź do zalecanej opcji. Migrowanie spa z niejawnego udzielenia do przepływu przyznawania kodu autoryzacji za pomocą klucza dowodowego dla wymiany kodu (PKCE) i współużytkowania zasobów między źródłami (CORS).
    • W przypadku aplikacji mobilnych rozszerz okres istnienia tokenu odświeżania i dostępu.
  • Aplikacje zaplecza lub mikrousług: aplikacje zaplecza (demona) nie są interakcyjne i nie znajdują się w kontekście użytkownika, dlatego perspektywa kradzieży tokenu jest zmniejszana. Naszym zaleceniem jest zachowanie równowagi między zabezpieczeniami a okresem istnienia i ustawieniem długiego okresu istnienia tokenu.

Logowanie jednokrotne

Przy użyciu logowania jednokrotnego użytkownicy logować się raz przy użyciu konta i uzyskiwać dostęp do aplikacji: aplikacji internetowej, mobilnej lub jednostronicowej (SPA), niezależnie od nazwy platformy lub domeny. Gdy użytkownik zaloguje się do aplikacji, usługa Azure AD B2C będzie utrwalać 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 zalogowanie się. Jeśli logowanie jednokrotne jest skonfigurowane z ograniczonym zakresem w zasadach lub aplikacji, później dostęp do innych zasad i aplikacji wymaga nowego uwierzytelniania.

Konfigurowanie logowania jednokrotnego

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ęstsze zakłócenia usługi to zmiany kodu i konfiguracji. Wdrażanie procesów i narzędzi ciągłej integracji i ciągłego wdrażania (CICD) umożliwia wdrażanie na dużą skalę i zmniejsza błędy człowieka podczas testowania i wdrażania. 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, skrypty między witrynami, zdalne wykonywanie kodu i inne udokumentowane w OWASP Top-10. Wdróż zaporę aplikacji internetowej w celu obrony przed typowymi programami wykorzystującymi luki w zabezpieczeniach i lukami w zabezpieczeniach.

Wpisy tajne

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) odnosi się do zakresu czasu autoryzacji klucza, używanego przez uprawnione jednostki, jako kryptografię. Wybierz wymaganą długość cryptoperiods. Ustaw wygasanie i obracanie wpisów tajnych przed ich wygaśnięciem.

Implementowanie rotacji 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 kluczy i certyfikatów skonfigurowanych w usłudze Azure AD B2C. Ta lista może zawierać klucze używane w zasadach niestandardowych, interfejsach API, tokenach identyfikatora podpisywania i certyfikatach dla języka SAML (Security Assertion Markup Language).
  • Korzystając z CICD, obracaj wpisy tajne, które wygasają w ciągu dwóch miesięcy od przewidywanego sezonu szczytowego. Zalecana maksymalna kryptografia kluczy prywatnych skojarzonych z certyfikatem wynosi jeden rok.
  • Monitorowanie i obracanie poświadczeń dostępu do interfejsu API, takich jak hasła i certyfikaty.

Testowanie interfejsu API REST

W celu zapewnienia odporności testowanie interfejsów API REST musi obejmować weryfikację kodów HTTP, ładunku odpowiedzi, nagłówków i wydajności. Nie używaj tylko testów szczęśliwej ścieżki i upewnij się, że interfejs API obsługuje scenariusze problemów w sposób bezproblemowy.

Plan testu

Zalecamy, aby plan testu obejmował kompleksowe testy interfejsu API. W przypadku wzrostów z powodu podwyższenia poziomu lub ruchu wakacyjnego popraw testowanie obciążenia przy użyciu nowych szacunków. Przeprowadź testowanie obciążenia interfejsu API i usługę Content Delivery Network (CDN) w środowisku deweloperskim, a nie w środowisku produkcyjnym.

Następne kroki