Ramy bezpieczeństwa: Uwierzytelnianie | Zabezpieczenia

• Rozważ użycie standardowego mechanizmu uwierzytelniania do uwierzytelniania w aplikacji internetowej
• Aplikacje muszą bezpiecznie obsługiwać scenariusze uwierzytelniania, które zakończyły się niepowodzeniem
• Włączanie uwierzytelniania krokowego lub adaptacyjnego
• Upewnij się, że interfejsy administracyjne są odpowiednio zablokowane
• Bezpieczne implementowanie funkcji zapomnianych haseł
• Upewnij się, że zostały zaimplementowane zasady haseł i kont
• Implementowanie kontrolek w celu zapobiegania wyliczaniu nazwy użytkownika

• Jeśli to możliwe, użyj uwierzytelniania systemu Windows do nawiązywania połączenia z programem SQL Server
• Jeśli to możliwe, użyj uwierzytelniania entra firmy Microsoft do nawiązywania połączenia z usługą SQL Database
• Gdy jest używany tryb uwierzytelniania SQL, upewnij się, że zasady konta i hasła są wymuszane na serwerze SQL
• Nie używaj uwierzytelniania SQL w zawartych bazach danych

• Użycie poświadczeń uwierzytelniania na urządzenie z wykorzystaniem tokenów SaS

• Włączanie uwierzytelniania wieloskładnikowego firmy Microsoft dla administratorów platformy Azure

• Ograniczanie dostępu anonimowego do klastra usługi Service Fabric
• Upewnij się, że certyfikat klient-węzeł usługi Service Fabric różni się od certyfikatu typu węzeł-węzeł
• Używanie identyfikatora Entra firmy Microsoft do uwierzytelniania klientów w klastrach usługi Service Fabric
• Upewnij się, że certyfikaty związane z Service Fabric są uzyskiwane od zatwierdzonego urzędu certyfikacji (CA)

• Używanie standardowych scenariuszy uwierzytelniania obsługiwanych przez serwer tożsamości
• Zastąp domyślną pamięć podręczną tokenów usługi Identity Server skalowalną alternatywą

• Upewnij się, że pliki binarne wdrożonej aplikacji są podpisane cyfrowo

• Włączanie uwierzytelniania podczas nawiązywania połączenia z kolejkami MSMQ w programie WCF
• WCF-Nie ustawiaj pola clientCredentialType dla komunikatu na wartość "none"
• WCF-Nie ustawiaj klienta transportuCredentialType na wartość none

• Upewnij się, że standardowe techniki uwierzytelniania są używane do zabezpieczania internetowych interfejsów API

• Używanie standardowych scenariuszy uwierzytelniania obsługiwanych przez identyfikator Entra firmy Microsoft
• Zastąp domyślną pamięć podręczną tokenów MSAL pamięcią podręczną rozproszoną
• Upewnij się, że funkcja TokenReplayCache jest używana w celu zapobiegania ponownemu odtwarzaniu tokenów uwierzytelniania przychodzącego
• Używanie bibliotek MSAL do zarządzania żądaniami tokenów od klientów OAuth2 do Microsoft Entra ID (lub lokalnego AD)

• Uwierzytelnianie urządzeń łączących się z usługą Field Gateway

• Upewnij się, że urządzenia łączące się z bramą w chmurze są uwierzytelnione
• Używanie poświadczeń uwierzytelniania poszczególnych urządzeń

• Upewnij się, że tylko wymagane kontenery i obiekty blob mają anonimowy dostęp do odczytu
• Udzielanie ograniczonego dostępu do obiektów w usłudze Azure Storage przy użyciu sygnatury dostępu współdzielonego (SAS) lub SAP

Uwierzytelnianie to proces, w którym jednostka potwierdza swoją tożsamość, zazwyczaj za pośrednictwem poświadczeń, takich jak nazwa użytkownika i hasło. Dostępnych jest wiele protokołów uwierzytelniania, które mogą być brane pod uwagę. Poniżej wymieniono niektóre z nich:

• Certyfikaty klienta
• Oparte na systemie Windows
• Oparte na formularzach
• Federacja — ADFS
• Federacja — Microsoft Entra ID
• Federacja — serwer tożsamości

Rozważ użycie standardowego mechanizmu uwierzytelniania w celu zidentyfikowania procesu źródłowego

Aplikacje, które jawnie uwierzytelniają użytkowników, muszą bezpiecznie obsługiwać scenariusze uwierzytelniania, które zakończyły się niepowodzeniem. Mechanizm uwierzytelniania musi:

• Odmowa dostępu do uprzywilejowanych zasobów w przypadku niepowodzenia uwierzytelniania
• Wyświetlanie ogólnego komunikatu o błędzie po nieudanym uwierzytelnieniu i odmowie dostępu

Testowanie dla:

• Ochrona uprzywilejowanych zasobów po nieudanych logowaniach
• Ogólny komunikat o błędzie jest wyświetlany w przypadku nieudanych zdarzeń uwierzytelniania i odmowy dostępu
• Konta są wyłączone po nadmiernej liczbie nieudanych prób

Sprawdź, czy aplikacja ma dodatkową autoryzację (np. uwierzytelnianie przyrostowe lub adaptacyjne, za pośrednictwem uwierzytelniania wieloskładnikowego, takiego jak wysyłanie protokołu OTP w wiadomości SMS, wiadomości e-mail lub monitowanie o ponowne uwierzytelnienie), dlatego użytkownik jest kwestionowany przed udzieleniem dostępu do poufnych informacji. Ta reguła dotyczy również wprowadzania krytycznych zmian na koncie lub akcji

Oznacza to również, że dostosowanie uwierzytelniania musi zostać zaimplementowane w taki sposób, aby aplikacja prawidłowo wymuszała autoryzację kontekstową, aby nie zezwalać na nieautoryzowane manipulowanie za pomocą na przykład manipulowania parametrami

Pierwszą rzeczą jest sprawdzenie, czy nie pamiętasz hasła, a inne ścieżki odzyskiwania wysyłają link, w tym token aktywacji ograniczony czasowo, a nie hasło. Dodatkowe uwierzytelnianie na podstawie tokenów nietrwałych (np. tokenu SMS, natywnych aplikacji mobilnych itp.) może być wymagane, jak również przed wysłaniem linku. Po drugie, nie należy blokować konta użytkowników, podczas gdy proces uzyskiwania nowego hasła jest w toku.

Może to prowadzić do ataku typu "odmowa usługi" za każdym razem, gdy osoba atakująca zdecyduje się celowo zablokować użytkowników za pomocą zautomatyzowanego ataku. Po trzecie, za każdym razem, gdy nowe żądanie zmiany hasła jest w toku, wyświetlany komunikat powinien być uogólniony, aby zapobiec ujawnieniu nazwy użytkownika. Po czwarte, zawsze nie zezwalaj na używanie starych haseł i implementowanie silnych zasad haseł.

Należy zaimplementować zasady haseł i kont zgodnie z zasadami organizacyjnymi i najlepszymi rozwiązaniami.

Aby bronić przed atakami siłowymi i słownikowymi, należy zaimplementować silne zasady haseł w celu zapewnienia, że użytkownicy tworzą złożone hasło (np. minimalna długość 12 znaków, alfanumeryczne i znaki specjalne).

Zasady blokady konta można zaimplementować w następujący sposób:

• Miękkie blokowanie: może to być dobra opcja ochrony użytkowników przed atakami siłowymi. Na przykład za każdym razem, gdy użytkownik wprowadzi nieprawidłowe hasło trzy razy, aplikacja może zablokować konto na minutę, aby spowolnić proces ataku metodą brute force, czyniąc atak mniej opłacalnym dla osoby atakującej. W przypadku zaimplementowania twardych środków zaradczych blokady w tym przykładzie można osiągnąć "DoS", trwale blokując konta. Alternatywnie aplikacja może wygenerować OTP (jednorazowe hasło) i wysłać ją poza pasmem (za pośrednictwem poczty e-mail, wiadomości SMS itp.) do użytkownika. Innym podejściem może być zaimplementowanie capTCHA po osiągnięciu progu liczby nieudanych prób.
• Blokada twarda: tego typu blokada powinna być stosowana za każdym razem, gdy wykryjesz, że użytkownik atakuje aplikację i przeciwdziała im za pomocą trwałego blokowania konta, dopóki zespół odpowiedzi nie miał czasu na wykonanie swoich badań kryminalistycznych. Po wykonaniu tego procesu możesz zdecydować się na udzielenie użytkownikowi zwrotu konta lub podjęcie dalszych działań prawnych przeciwko nim. Takie podejście uniemożliwia atakującemu dalsze penetrację aplikacji i infrastruktury.

Aby bronić się przed atakami na konta domyślne i przewidywalne, sprawdź, czy wszystkie klucze i hasła są zamienialne i są generowane lub zastępowane po czasie instalacji.

Jeśli aplikacja musi automatycznie generować hasła, upewnij się, że wygenerowane hasła są losowe i mają wysoką entropię.

Model zabezpieczeń w usłudze Event Hubs jest oparty na kombinacji tokenów Shared Access Signature (SAS) i publikatorów zdarzeń. Nazwa wydawcy reprezentuje identyfikator urządzenia, który odbiera token. Pomoże to skojarzyć tokeny wygenerowane z odpowiednimi urządzeniami.

Wszystkie komunikaty są oznaczane nadawcą po stronie usługi, co umożliwia wykrywanie prób fałszowania źródła wewnątrz ładunku. Podczas uwierzytelniania urządzeń wygeneruj unikalny dla każdego urządzenia token SaS przypisany do jedynego wydawcy.

Uwierzytelnianie wieloskładnikowe (MFA) to metoda uwierzytelniania, która wymaga więcej niż jednej metody weryfikacji i dodaje krytyczną drugą warstwę zabezpieczeń do logowania i transakcji użytkownika. Działa to przez wymaganie co najmniej dwóch następujących metod weryfikacji:

• Coś, co znasz (zazwyczaj hasło)
• Coś, co masz (zaufane urządzenie, które nie jest łatwo zduplikowane, jak telefon)
• Coś, co jesteś (biometria)

Klastry powinny być zawsze zabezpieczone, aby uniemożliwić nieautoryzowanym użytkownikom nawiązywanie połączenia z klastrem, zwłaszcza gdy ma uruchomione obciążenia produkcyjne.

Podczas tworzenia klastra usługi Service Fabric upewnij się, że tryb zabezpieczeń jest ustawiony na "bezpieczny" i skonfiguruj wymagany certyfikat serwera X.509. Utworzenie klastra "niezabezpieczonego" umożliwi każdemu anonimowemu użytkownikowi nawiązanie z nim połączenia, jeśli uwidacznia punkty końcowe zarządzania z publicznym Internetem.

Zabezpieczenia certyfikatów typu klient-węzeł są konfigurowane podczas tworzenia klastra za pośrednictwem witryny Azure Portal, szablonów usługi Resource Manager lub autonomicznego szablonu JSON przez określenie certyfikatu klienta administratora i/lub certyfikatu klienta użytkownika.

Określone certyfikaty klienta administracyjnego i klienta użytkownika powinny być inne niż certyfikaty podstawowe i pomocnicze określone dla zabezpieczeń typu Node-to-node.

Usługa Service Fabric używa certyfikatów serwera X.509 do uwierzytelniania węzłów i klientów.

Ważne kwestie do rozważenia podczas korzystania z certyfikatów na platformach usługowych:

• Certyfikaty używane w klastrach z obciążeniami produkcyjnymi powinny być tworzone przy użyciu poprawnie skonfigurowanej usługi certyfikatów systemu Windows Server lub uzyskane z zatwierdzonego urzędu certyfikacji. Urząd certyfikacji może być zatwierdzonym zewnętrznym urzędem certyfikacji lub prawidłowo zarządzaną wewnętrzną infrastrukturą kluczy publicznych (PKI)
• Nigdy nie używaj żadnych tymczasowych lub testowych certyfikatów w środowisku produkcyjnym, które są tworzone za pomocą narzędzi, takich jak MakeCert.exe
• Możesz użyć certyfikatu z podpisem własnym, ale należy to zrobić tylko w przypadku klastrów testowych, a nie w środowisku produkcyjnym

Poniżej przedstawiono typowe interakcje obsługiwane przez usługę Identity Server:

• Przeglądarki komunikują się z aplikacjami internetowymi
• Aplikacje internetowe komunikują się z internetowymi interfejsami API (czasami samodzielnie, czasami w imieniu użytkownika)
• Aplikacje oparte na przeglądarce komunikują się z internetowymi interfejsami API
• Aplikacje natywne komunikują się z internetowymi interfejsami API
• Aplikacje oparte na serwerze komunikują się z internetowymi interfejsami API
• Interfejsy API sieci Web komunikują się z innymi interfejsami API sieci Web (czasami samodzielnie, czasami w imieniu użytkownika)

Usługa IdentityServer ma prostą wbudowaną pamięć podręczną. Chociaż jest to dobre dla aplikacji natywnych na małą skalę, nie jest ona skalowana dla aplikacji w warstwie środkowej i zapleczu z następujących powodów:

• Dostęp do tych aplikacji jest uzyskiwany przez wielu użytkowników jednocześnie. Zapisanie wszystkich tokenów dostępu w tym samym magazynie powoduje problemy z izolacją i stwarza wyzwania związane z działaniem na dużą skalę: wielu użytkowników, z których każdy ma tyle tokenów, jak zasoby, do których aplikacja uzyskuje dostęp w ich imieniu, może oznaczać ogromne liczby i bardzo kosztowne operacje wyszukiwania
• Te aplikacje są zwykle wdrażane w topologiach rozproszonych, w których wiele węzłów musi mieć dostęp do tej samej pamięci podręcznej
• Buforowane tokeny muszą przetrwać odtwarzanie i dezaktywacje procesów
• Ze wszystkich powyższych powodów, podczas implementowania aplikacji internetowych zaleca się zastąpienie domyślnej pamięci podręcznej tokenów serwera Identity na skalowalną alternatywę, taką jak Azure Cache for Redis

Uwierzytelnianie to proces, w którym jednostka potwierdza swoją tożsamość, zazwyczaj za pośrednictwem poświadczeń, takich jak nazwa użytkownika i hasło. Dostępnych jest wiele protokołów uwierzytelniania, które mogą być brane pod uwagę. Poniżej wymieniono niektóre z nich:

• Certyfikaty klienta
• Oparte na systemie Windows
• Oparte na formularzach
• Federacja — ADFS
• Federacja — Microsoft Entra ID
• Federacja — serwer tożsamości

Linki w sekcji odnośników zawierają szczegółowe informacje techniczne na temat sposoby implementacji każdego schematu uwierzytelniania w celu zabezpieczenia interfejsu API w sieci.

Microsoft Entra ID upraszcza proces uwierzytelniania dla deweloperów, oferując tożsamość jako usługę z obsługą standardowych protokołów branżowych, takich jak OAuth 2.0 i OpenID Connect. Poniżej przedstawiono pięć podstawowych scenariuszy aplikacji obsługiwanych przez identyfikator firmy Microsoft Entra:

• Przeglądarka internetowa do aplikacji internetowej: użytkownik musi zalogować się do aplikacji internetowej zabezpieczonej przez identyfikator Entra firmy Microsoft
• Aplikacja jednostronicowa (SPA): użytkownik musi zalogować się do aplikacji jednostronicowej zabezpieczonej przez identyfikator Firmy Microsoft Entra
• Natywny interfejs API do sieci Web: aplikacja natywna działająca na telefonie, tablecie lub komputerze musi uwierzytelnić użytkownika w celu uzyskania zasobów z internetowego interfejsu API zabezpieczonego przez identyfikator Entra firmy Microsoft
• Aplikacja internetowa do interfejsu API: Aplikacja internetowa musi pobierać zasoby z internetowego interfejsu API zabezpieczonego przez Microsoft Entra ID.
• Demon lub aplikacja serwera do API internetowego: aplikacja demona lub aplikacja serwera bez interfejsu użytkownika sieciowego musi pobierać zasoby z API internetowego zabezpieczonego przez Microsoft Entra ID.

Zapoznaj się z linkami w sekcji referencyjnej, aby uzyskać szczegółowe informacje o implementacji niskiego poziomu

Domyślna pamięć podręczna używana przez bibliotekę MSAL (Biblioteka uwierzytelniania firmy Microsoft) to pamięć podręczna w pamięci i jest skalowalna. Istnieją jednak różne opcje, których można użyć jako alternatywy, takich jak rozproszona pamięć podręczna tokenów. Mają one mechanizmy L1/L2, gdzie L1 znajduje się w pamięci, a L2 jest implementacją rozproszonej pamięci podręcznej. Można je odpowiednio skonfigurować tak, aby ograniczać pamięć L1, szyfrować lub ustawiać zasady eksmisji. Inne alternatywy to pamięci podręczne Redis, SQL Server lub Azure Cosmos DB. Implementację rozproszonej pamięci podręcznej tokenów można znaleźć w następującym samouczku: Rozpoczynanie pracy z ASP.NET Core MVC.

Właściwość TokenReplayCache umożliwia deweloperom zdefiniowanie pamięci podręcznej odtwarzania tokenu, magazynu, który może służyć do zapisywania tokenów w celu sprawdzenia, czy nie można używać tokenu więcej niż raz.

Jest to środek przeciwko powszechnemu atakowi, trafnie nazywanemu atakiem ponownego odtwarzania tokenu: osoba atakująca przechwycąc token wysłany podczas logowania może spróbować wysłać go ponownie do aplikacji ("powtórzenie" w celu ustanowienia nowej sesji). Na przykład w przepływie udzielania kodu OIDC po pomyślnym uwierzytelnieniu użytkownika żądanie do punktu końcowego "/signin-oidc" jednostki uzależnionej jest wykonywane z parametrami "id_token", "code" i "state".

Jednostka uzależniona weryfikuje to żądanie i ustanawia nową sesję. Jeśli przeciwnik przechwytuje to żądanie i odtwarza je, może ustanowić pomyślną sesję i sfałszować użytkownika. Obecność wartości nonce w OpenID Connect może ograniczyć, ale nie całkowicie wyeliminować okoliczności, w których atak może zostać pomyślnie przeprowadzony. Aby chronić swoje aplikacje, deweloperzy mogą dostarczyć implementację ITokenReplayCache i przypisać instancję do TokenReplayCache.

Biblioteka Microsoft Authentication Library (MSAL) umożliwia deweloperom uzyskiwanie tokenów zabezpieczających z Platforma tożsamości Microsoft w celu uwierzytelniania użytkowników i uzyskiwania dostępu do zabezpieczonych internetowych interfejsów API. Może służyć do zapewnienia bezpiecznego dostępu do programu Microsoft Graph, innych interfejsów API firmy Microsoft, internetowych interfejsów API innych firm lub własnego internetowego interfejsu API. Biblioteka MSAL obsługuje wiele różnych architektur aplikacji i platform, takich jak .NET, JavaScript, Java, Python, Android i iOS.

Domyślnie kontener i wszystkie zawarte w nim blob-y mogą być dostępne wyłącznie dla właściciela konta magazynu. Aby przyznać anonimowym użytkownikom uprawnienia do odczytu kontenera i jego obiektów blob, można ustawić uprawnienia kontenera, umożliwiając dostęp publiczny. Użytkownicy anonimowi mogą odczytywać obiekty blob w publicznie dostępnym kontenerze bez uwierzytelniania żądania.

Kontenery udostępniają następujące opcje zarządzania dostępem do kontenerów:

• Pełny publiczny dostęp do odczytu: dane kontenerów i obiektów blob można odczytywać za pośrednictwem żądania anonimowego. Klienci mogą wyliczać bloby w kontenerze za pośrednictwem żądania anonimowego, ale nie mogą wyliczać kontenerów na koncie magazynowym.
• Publiczny dostęp do odczytu tylko dla obiektów blob: dane obiektów blob w tym kontenerze mogą być odczytywane za pośrednictwem żądania anonimowego, ale dane kontenera nie są dostępne. Klienci nie mogą wyliczać blobów w kontenerze bez żądania anonimowego.
• Brak publicznego dostępu do odczytu danych: dane kontenerów i obiektów BLOB mogą być odczytywane tylko przez właściciela konta

Dostęp anonimowy jest najlepszy w scenariuszach, w których niektóre bloby powinny być zawsze dostępne dla anonimowego odczytu. W przypadku bardziej szczegółowej kontroli można utworzyć sygnaturę dostępu współdzielonego, która umożliwia delegowanie ograniczonego dostępu przy użyciu różnych uprawnień i w określonym przedziale czasu. Upewnij się, że kontenery i obiekty blob, które mogą potencjalnie zawierać poufne dane, nie są przypadkowo udostępniane anonimowo

Użycie sygnatury dostępu współdzielonego (SAS) to zaawansowany sposób udzielania ograniczonego dostępu do obiektów na koncie magazynu innym klientom bez konieczności uwidaczniania klucza dostępu do konta. Sygnatura dostępu współdzielonego jest identyfikatorem URI obejmującym wszystkie parametry zapytania niezbędne do uwierzytelnionego dostępu do zasobu magazynowego. Aby uzyskać dostęp do zasobów magazynu przy użyciu sygnatury dostępu współdzielonego, klient musi przekazać sygnaturę dostępu współdzielonego tylko do odpowiedniego konstruktora lub metody.

Możesz użyć sygnatury dostępu współdzielonego (SAS), jeśli chcesz zapewnić dostęp do zasobów na koncie magazynu klientowi, któremu nie można powierzyć klucza konta. Klucze konta magazynu obejmują zarówno klucz podstawowy, jak i pomocniczy, który udziela dostępu administracyjnego do konta i wszystkich zasobów w nim. Uwidacznianie jednego z kluczy konta powoduje otwarcie konta na możliwość złośliwego lub nieumyślnego użycia. Sygnatury dostępu współdzielonego zapewniają bezpieczną alternatywę, która umożliwia innym klientom odczytywanie, zapisywanie i usuwanie danych na koncie magazynu zgodnie z udzielonymi uprawnieniami i bez konieczności używania klucza konta.

Jeśli masz logiczny zestaw parametrów, które są podobne za każdym razem, użycie zasad dostępu przechowywanego (SAP) jest lepszym pomysłem. Ponieważ korzystanie z SAS pochodzącego z przechowywanej zasady dostępu daje możliwość natychmiastowego odwołania tego SAS, zalecane jest, aby zawsze używać przechowywanych zasad dostępu, kiedy to możliwe.