Udostępnij za pośrednictwem

Ramka zabezpieczeń: Uwierzytelnianie | Czynniki

  • Artykuł
Produkt/usługa Artykuł
Aplikacja internetowa
Baza danych
Azure Event Hub
Granica zaufania platformy Azure
Granica zaufania usługi Service Fabric
Serwer tożsamości
Granica zaufania maszyny
WCF
Internetowy interfejs API
Tożsamość Microsoft Entra
Brama pola IoT
Brama chmury IoT
Azure Storage

Rozważ użycie standardowego mechanizmu uwierzytelniania do uwierzytelniania w aplikacji internetowej

Tytuł Szczegóły
Składnik Aplikacja internetowa
Faza SDL Tworzenie
Odpowiednie technologie Ogólna
Atrybuty Nie dotyczy
Dokumentacja Nie dotyczy
Szczegóły

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
  • Formularze oparte na formularzach
  • Federacja — usługi ADFS
  • Federacja — Microsoft Entra ID
  • Federacja — serwer tożsamości

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

Aplikacje muszą bezpiecznie obsługiwać scenariusze uwierzytelniania, które zakończyły się niepowodzeniem

Tytuł Szczegóły
Składnik Aplikacja internetowa
Faza SDL Tworzenie
Odpowiednie technologie Ogólna
Atrybuty Nie dotyczy
Dokumentacja Nie dotyczy
Szczegóły

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

    Włączanie uwierzytelniania krokowego lub adaptacyjnego

    Tytuł Szczegóły
    Składnik Aplikacja internetowa
    Faza SDL Tworzenie
    Odpowiednie technologie Ogólna
    Atrybuty Nie dotyczy
    Dokumentacja Nie dotyczy
    Szczegóły

    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

    Upewnij się, że interfejsy administracyjne są odpowiednio zablokowane

    Tytuł Szczegóły
    Składnik Aplikacja internetowa
    Faza SDL Tworzenie
    Odpowiednie technologie Ogólna
    Atrybuty Nie dotyczy
    Dokumentacja Nie dotyczy
    Szczegóły Pierwszym rozwiązaniem jest przyznanie dostępu tylko z określonego źródłowego zakresu adresów IP do interfejsu administracyjnego. Jeśli to rozwiązanie nie będzie możliwe, zawsze zaleca się wymuszenie krokowego lub adaptacyjnego uwierzytelniania w celu zalogowania się do interfejsu administracyjnego

    Bezpieczne implementowanie funkcji zapomnianych haseł

    Tytuł Szczegóły
    Składnik Aplikacja internetowa
    Faza SDL Tworzenie
    Odpowiednie technologie Ogólna
    Atrybuty Nie dotyczy
    Dokumentacja Nie dotyczy
    Szczegóły

    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 hasła zostało ustawione w toku, wyświetlany komunikat powinien być uogólniony, aby zapobiec wyliczaniu nazwy użytkownika. Po czwarte, zawsze nie zezwalaj na używanie starych haseł i implementowanie silnych zasad haseł.

    Upewnij się, że zostały zaimplementowane zasady haseł i kont

    Tytuł Szczegóły
    Składnik Aplikacja internetowa
    Faza SDL Tworzenie
    Odpowiednie technologie Ogólna
    Atrybuty Nie dotyczy
    Dokumentacja Nie dotyczy
    Szczegóły

    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 przez minutę, aby spowolnić proces ataku siłowego, co czyni je mniej opłacalne, aby osoba atakująca mogła kontynuować. 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ę.

    Implementowanie kontrolek w celu zapobiegania wyliczaniu nazwy użytkownika

    Tytuł Szczegóły
    Składnik Aplikacja internetowa
    Faza SDL Tworzenie
    Odpowiednie technologie Ogólna
    Atrybuty Nie dotyczy
    Dokumentacja Nie dotyczy
    Kroki Wszystkie komunikaty o błędach powinny być uogólnione, aby zapobiec wyliczaniu nazwy użytkownika. Czasami nie można również uniknąć wycieku informacji w funkcjach, takich jak strona rejestracji. W tym miejscu należy użyć metod ograniczania szybkości, takich jak CAPTCHA, aby zapobiec automatycznemu atakowi atakującemu.

    Jeśli to możliwe, użyj uwierzytelniania systemu Windows do nawiązywania połączenia z programem SQL Server

    Tytuł Szczegóły
    Składnik baza danych
    Faza SDL Tworzenie
    Odpowiednie technologie Lokalne
    Atrybuty Wersja SQL — wszystkie
    Dokumentacja SQL Server — wybieranie trybu uwierzytelniania
    Kroki Uwierzytelnianie systemu Windows używa protokołu zabezpieczeń Kerberos, zapewnia wymuszanie zasad haseł w odniesieniu do walidacji złożoności silnych haseł, zapewnia obsługę blokady konta i obsługuje wygaśnięcie hasła.

    Jeśli to możliwe, użyj uwierzytelniania entra firmy Microsoft do Połączenie do usługi SQL Database

    Tytuł Szczegóły
    Składnik baza danych
    Faza SDL Tworzenie
    Odpowiednie technologie SQL Azure
    Atrybuty Wersja SQL — wersja 12
    Dokumentacja Połączenie do usługi SQL Database przy użyciu uwierzytelniania entra firmy Microsoft
    Kroki Minimalna wersja: usługa Azure SQL Database w wersji 12 wymagana do umożliwienia usłudze Azure SQL Database używania uwierzytelniania usługi Microsoft Entra w katalogu Microsoft

    Gdy jest używany tryb uwierzytelniania SQL, upewnij się, że zasady konta i hasła są wymuszane na serwerze SQL

    Tytuł Szczegóły
    Składnik baza danych
    Faza SDL Tworzenie
    Odpowiednie technologie Ogólna
    Atrybuty Nie dotyczy
    Dokumentacja Zasady haseł programu SQL Server
    Kroki W przypadku korzystania z uwierzytelniania programu SQL Server nazwy logowania są tworzone w programie SQL Server, które nie są oparte na kontach użytkowników systemu Windows. Zarówno nazwa użytkownika, jak i hasło są tworzone przy użyciu programu SQL Server i przechowywane w programie SQL Server. Program SQL Server może używać mechanizmów zasad haseł systemu Windows. Może ona stosować te same zasady złożoności i wygasania używane w systemie Windows do haseł używanych w programie SQL Server.

    Nie używaj uwierzytelniania SQL w zawartych bazach danych

    Tytuł Szczegóły
    Składnik baza danych
    Faza SDL Tworzenie
    Odpowiednie technologie Lokalne, Usługi SQL Azure
    Atrybuty Wersja SQL — MSSQL2012, wersja SQL — wersja 12
    Dokumentacja Najlepsze rozwiązania w zakresie zabezpieczeń zawarte bazy danych
    Kroki Brak wymuszonych zasad haseł może zwiększyć prawdopodobieństwo ustanowienia słabego poświadczenia w zawartej bazie danych. Korzystanie z uwierzytelniania systemu Windows.

    Używanie poświadczeń uwierzytelniania na urządzeniu przy użyciu tokenów SaS

    Tytuł Szczegóły
    Składnik Azure Event Hubs
    Faza SDL Tworzenie
    Odpowiednie technologie Ogólna
    Atrybuty Nie dotyczy
    Dokumentacja Omówienie uwierzytelniania i modelu zabezpieczeń usługi Event Hubs
    Kroki

    Model zabezpieczeń usługi Event Hubs jest oparty na kombinacji tokenów sygnatury dostępu współdzielonego (SAS) i wydawcó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 przy użyciu obiektu źródłowego po stronie usługi, co umożliwia wykrywanie prób fałszowania źródła ładunku. Podczas uwierzytelniania urządzeń wygeneruj token SaS dla każdego urządzenia o określonym zakresie dla unikatowego wydawcy.

    Włączanie uwierzytelniania wieloskładnikowego firmy Microsoft dla usługi Azure Administracja istrators

    Tytuł Szczegóły
    Składnik Granica zaufania platformy Azure
    Faza SDL Wdrożenie
    Odpowiednie technologie Ogólna
    Atrybuty Nie dotyczy
    Dokumentacja Co to jest uwierzytelnianie wieloskładnikowe firmy Microsoft?
    Kroki

    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ś (biometryczne)

      Ograniczanie dostępu anonimowego do klastra usługi Service Fabric

      Tytuł Szczegóły
      Składnik Granica zaufania usługi Service Fabric
      Faza SDL Wdrożenie
      Odpowiednie technologie Ogólna
      Atrybuty Środowisko — Azure
      Dokumentacja Scenariusze zabezpieczeń klastra usługi Service Fabric
      Kroki

      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.

      Upewnij się, że certyfikat klient-węzeł usługi Service Fabric różni się od certyfikatu typu węzeł-węzeł

      Tytuł Szczegóły
      Składnik Granica zaufania usługi Service Fabric
      Faza SDL Wdrożenie
      Odpowiednie technologie Ogólna
      Atrybuty Środowisko — Azure, Środowisko — autonomiczne
      Dokumentacja Zabezpieczenia certyfikatu klient-węzeł usługi Service Fabric Połączenie do bezpiecznego klastra przy użyciu certyfikatu klienta
      Kroki

      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.

      Używanie identyfikatora Entra firmy Microsoft do uwierzytelniania klientów w klastrach usługi Service Fabric

      Tytuł Szczegóły
      Składnik Granica zaufania usługi Service Fabric
      Faza SDL Wdrożenie
      Odpowiednie technologie Ogólna
      Atrybuty Środowisko — Azure
      Dokumentacja Scenariusze zabezpieczeń klastra — zabezpieczenia Rekomendacje
      Kroki Klastry działające na platformie Azure mogą również zabezpieczyć dostęp do punktów końcowych zarządzania przy użyciu identyfikatora Entra firmy Microsoft, oprócz certyfikatów klienta. W przypadku klastrów platformy Azure zaleca się używanie zabezpieczeń firmy Microsoft Entra do uwierzytelniania klientów i certyfikatów na potrzeby zabezpieczeń typu node-to-node.

      Upewnij się, że certyfikaty usługi Service Fabric są uzyskiwane z zatwierdzonego urzędu certyfikacji

      Tytuł Szczegóły
      Składnik Granica zaufania usługi Service Fabric
      Faza SDL Wdrożenie
      Odpowiednie technologie Ogólna
      Atrybuty Środowisko — Azure
      Dokumentacja Certyfikaty X.509 i usługa Service Fabric
      Kroki

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

      Niektóre ważne kwestie, które należy wziąć pod uwagę podczas korzystania z certyfikatów w sieci szkieletowych usług:

      • 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

      Używanie standardowych scenariuszy uwierzytelniania obsługiwanych przez serwer tożsamości

      Tytuł Szczegóły
      Składnik Serwer tożsamości
      Faza SDL Tworzenie
      Odpowiednie technologie Ogólna
      Atrybuty Nie dotyczy
      Dokumentacja IdentityServer3 — duży obraz
      Kroki

      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
      • Internetowe interfejsy API komunikują się z internetowymi interfejsami API (czasami samodzielnie, czasami w imieniu użytkownika)

      Zastąp domyślną pamięć podręczną tokenów usługi Identity Server skalowalną alternatywą

      Tytuł Szczegóły
      Składnik Serwer tożsamości
      Faza SDL Wdrożenie
      Odpowiednie technologie Ogólna
      Atrybuty Nie dotyczy
      Dokumentacja Wdrażanie serwera tożsamości — Buforowanie
      Kroki

      Usługa IdentityServer ma prostą wbudowaną pamięć podręczną w pamięci. 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 tożsamości z skalowalną alternatywą, taką jak Azure Cache for Redis

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

      Tytuł Szczegóły
      Składnik Granica zaufania maszyny
      Faza SDL Wdrożenie
      Odpowiednie technologie Ogólna
      Atrybuty Nie dotyczy
      Dokumentacja Nie dotyczy
      Kroki Upewnij się, że pliki binarne wdrożonej aplikacji są podpisane cyfrowo, aby można było zweryfikować integralność plików binarnych

      Włączanie uwierzytelniania podczas nawiązywania połączenia z kolejkami MSMQ w programie WCF

      Tytuł Szczegóły
      Składnik WCF
      Faza SDL Tworzenie
      Odpowiednie technologie Ogólne, NET Framework 3
      Atrybuty Nie dotyczy
      Dokumentacja MSDN
      Kroki Program nie może włączyć uwierzytelniania podczas nawiązywania połączenia z kolejkami MSMQ. Osoba atakująca może anonimowo przesyłać komunikaty do kolejki w celu przetworzenia. Jeśli uwierzytelnianie nie jest używane do nawiązywania połączenia z kolejką MSMQ używanej do dostarczania komunikatu do innego programu, osoba atakująca może przesłać anonimową wiadomość, która jest złośliwa.

      Przykład

      Element <netMsmqBinding/> poniższego pliku konfiguracji programu WCF instruuje program WCF, aby wyłączyć uwierzytelnianie podczas nawiązywania połączenia z kolejką MSMQ na potrzeby dostarczania komunikatów.

      <bindings>
    <netMsmqBinding>
        <binding>
            <security>
                <transport msmqAuthenticationMode=""None"" />
            </security>
        </binding>
    </netMsmqBinding>
</bindings>

      Skonfiguruj usługę MSMQ tak, aby wymagać uwierzytelniania domeny lub certyfikatu systemu Windows przez cały czas dla dowolnych komunikatów przychodzących lub wychodzących.

      Przykład

      Element <netMsmqBinding/> poniższego pliku konfiguracji programu WCF instruuje program WCF, aby umożliwić uwierzytelnianie certyfikatów podczas nawiązywania połączenia z kolejką MSMQ. Klient jest uwierzytelniany przy użyciu certyfikatów X.509. Certyfikat klienta musi znajdować się w magazynie certyfikatów serwera.

      <bindings>
    <netMsmqBinding>
        <binding>
            <security>
                <transport msmqAuthenticationMode=""Certificate"" />
            </security>
        </binding>
    </netMsmqBinding>
</bindings>

      WCF-Nie ustawiaj elementu clientCredentialType komunikatu na wartość none

      Tytuł Szczegóły
      Składnik WCF
      Faza SDL Tworzenie
      Odpowiednie technologie .NET Framework 3
      Atrybuty Typ poświadczeń klienta — brak
      Dokumentacja MSDN, Fortify
      Kroki Brak uwierzytelniania oznacza, że każdy może uzyskać dostęp do tej usługi. Usługa, która nie uwierzytelnia swoich klientów, umożliwia dostęp do wszystkich użytkowników. Skonfiguruj aplikację do uwierzytelniania przy użyciu poświadczeń klienta. Można to zrobić, ustawiając dla klienta komunikatuCredentialType wartość Windows lub Certyfikat.

      Przykład

      <message clientCredentialType=""Certificate""/>

      WCF-Nie ustawiaj klienta transportuCredentialType na wartość none

      Tytuł Szczegóły
      Składnik WCF
      Faza SDL Tworzenie
      Odpowiednie technologie Generic, .NET Framework 3
      Atrybuty Typ poświadczeń klienta — brak
      Dokumentacja MSDN, Fortify
      Kroki Brak uwierzytelniania oznacza, że każdy może uzyskać dostęp do tej usługi. Usługa, która nie uwierzytelnia swoich klientów, umożliwia wszystkim użytkownikom dostęp do jej funkcji. Skonfiguruj aplikację do uwierzytelniania przy użyciu poświadczeń klienta. Można to zrobić, ustawiając klienta transportuCredentialType na Windows lub Certyfikat.

      Przykład

      <transport clientCredentialType=""Certificate""/>

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

      Tytuł Szczegóły
      Składnik Internetowy interfejs API
      Faza SDL Tworzenie
      Odpowiednie technologie Ogólna
      Atrybuty Nie dotyczy
      Dokumentacja Uwierzytelnianie i autoryzacja w internetowym interfejsie API ASP.NET, zewnętrzne usługi uwierzytelniania za pomocą interfejsu API sieci Web ASP.NET (C#)
      Kroki

      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
      • Formularze oparte na formularzach
      • Federacja — usługi ADFS
      • Federacja — Microsoft Entra ID
      • Federacja — serwer tożsamości

      Linki w sekcji odwołania zawierają szczegółowe informacje na temat sposobu implementacji każdego schematu uwierzytelniania w celu zabezpieczenia internetowego interfejsu API.

      Używanie standardowych scenariuszy uwierzytelniania obsługiwanych przez identyfikator Entra firmy Microsoft

      Tytuł Szczegóły
      Składnik Microsoft Entra ID
      Faza SDL Tworzenie
      Odpowiednie technologie Ogólna
      Atrybuty Nie dotyczy
      Dokumentacja Scenariusze uwierzytelniania dla identyfikatora Entra firmy Microsoft, przykłady kodu firmy Microsoft Entra, przewodnik dewelopera firmy Microsoft Entra
      Kroki

      Identyfikator entra firmy Microsoft upraszcza uwierzytelnianie dla deweloperów, zapewniając tożsamość jako usługę, z obsługą standardowych protokołów branżowych, takich jak OAuth 2.0 i OpenID Połączenie. 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
      • Internetowy interfejs API aplikacji internetowej: aplikacja internetowa musi pobierać zasoby z internetowego interfejsu API zabezpieczonego przez identyfikator entra firmy Microsoft
      • Demon lub aplikacja serwera do internetowego interfejsu API: aplikacja demona lub aplikacja serwera bez interfejsu użytkownika sieci Web musi pobierać zasoby z internetowego interfejsu API zabezpieczonego przez identyfikator Entra firmy Microsoft

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

      Zastąp domyślną pamięć podręczną tokenów BIBLIOTEKI MSAL rozproszoną pamięcią podręczną

      Tytuł Szczegóły
      Składnik Microsoft Entra ID
      Faza SDL Tworzenie
      Odpowiednie technologie Ogólna
      Atrybuty Nie dotyczy
      Dokumentacja Serializacja pamięci podręcznej tokenu w MSAL.NET
      Kroki

      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 Comsos DB. Implementację rozproszonej pamięci podręcznej tokenów można znaleźć w następującym samouczku: Rozpoczynanie pracy z ASP.NET Core MVC.

      Upewnij się, że funkcja TokenReplayCache jest używana w celu uniknięcia ponownego odtwarzania tokenów uwierzytelniania biblioteki MSAL

      Tytuł Szczegóły
      Składnik Microsoft Entra ID
      Faza SDL Tworzenie
      Odpowiednie technologie Ogólna
      Atrybuty Nie dotyczy
      Dokumentacja Nowoczesne uwierzytelnianie przy użyciu identyfikatora Entra firmy Microsoft dla aplikacji internetowych
      Kroki

      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ść nonce w openID Połączenie może ograniczyć, ale nie w pełni wyeliminować okoliczności, w których atak może zostać pomyślnie uchwalony. Aby chronić swoje aplikacje, deweloperzy mogą zapewnić implementację ITokenReplayCache i przypisać wystąpienie do tokenReplayCache.

      Przykład

      // ITokenReplayCache defined in MSAL
public interface ITokenReplayCache
{
bool TryAdd(string securityToken, DateTime expiresOn);
bool TryFind(string securityToken);
}

      Przykład

      Oto przykładowa implementacja interfejsu ITokenReplayCache. (Dostosuj i zaimplementuj strukturę buforowania specyficznego dla projektu)

      public class TokenReplayCache : ITokenReplayCache
{
    private readonly ICacheProvider cache; // Your project-specific cache provider
    public TokenReplayCache(ICacheProvider cache)
    {
        this.cache = cache;
    }
    public bool TryAdd(string securityToken, DateTime expiresOn)
    {
        if (this.cache.Get<string>(securityToken) == null)
        {
            this.cache.Set(securityToken, securityToken);
            return true;
        }
        return false;
    }
    public bool TryFind(string securityToken)
    {
        return this.cache.Get<string>(securityToken) != null;
    }
}

      Zaimplementowana pamięć podręczna musi być przywoływała w opcjach OIDC za pośrednictwem właściwości "TokenValidationParameters" w następujący sposób.

      OpenIdConnectOptions openIdConnectOptions = new OpenIdConnectOptions
{
    AutomaticAuthenticate = true,
    ... // other configuration properties follow..
    TokenValidationParameters = new TokenValidationParameters
    {
        TokenReplayCache = new TokenReplayCache(/*Inject your cache provider*/);
    }
}

      Należy pamiętać, że aby przetestować skuteczność tej konfiguracji, zaloguj się do lokalnej aplikacji chronionej przez funkcję OIDC i przechwyć żądanie do "/signin-oidc" punktu końcowego w narzędziu fiddler. Gdy ochrona nie jest włączona, ponowne wykonanie tego żądania w narzędziu fiddler spowoduje ustawienie nowego pliku cookie sesji. Po ponownym odtworzeniu żądania po dodaniu ochrony TokenReplayCache aplikacja zgłosi wyjątek w następujący sposób: SecurityTokenReplayDetectedException: IDX10228: The securityToken has previously been validated, securityToken: 'eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1uQ19WWmNBVGZNNXBPWWlKSE1iYTlnb0VLWSIsImtpZCI6Ik1uQ1......

      Używanie bibliotek BIBLIOTEK MSAL do zarządzania żądaniami tokenów od klientów OAuth2 do identyfikatora Entra firmy Microsoft (lub lokalnej usługi AD)

      Tytuł Szczegóły
      Składnik Microsoft Entra ID
      Faza SDL Tworzenie
      Odpowiednie technologie Ogólna
      Atrybuty Nie dotyczy
      Dokumentacja BIBLIOTEKA MSAL
      Kroki

      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.

      Biblioteka MSAL zapewnia wiele sposobów uzyskiwania tokenów przy użyciu spójnego interfejsu API dla wielu platform. Nie ma potrzeby bezpośredniego używania bibliotek lub kodu OAuth względem protokołu w aplikacji i może uzyskiwać tokeny w imieniu użytkownika lub aplikacji (jeśli ma to zastosowanie do platformy).

      Biblioteka MSAL obsługuje również pamięć podręczną tokenów i odświeża tokeny, gdy zbliżają się do wygaśnięcia. Biblioteka MSAL może również pomóc w określeniu odbiorców, którzy mają się zalogować, oraz ułatwiają konfigurowanie aplikacji z plików konfiguracji oraz rozwiązywanie problemów z aplikacją.

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

      Tytuł Szczegóły
      Składnik Brama pola IoT
      Faza SDL Tworzenie
      Odpowiednie technologie Ogólna
      Atrybuty Nie dotyczy
      Dokumentacja Nie dotyczy
      Kroki Upewnij się, że każde urządzenie jest uwierzytelniane przez bramę Field Gateway przed zaakceptowaniem danych z nich i przed ułatwieniem komunikacji nadrzędnej z bramą w chmurze. Upewnij się również, że urządzenia łączą się z poświadczeniami poszczególnych urządzeń, aby można było jednoznacznie zidentyfikować poszczególne urządzenia.

      Upewnij się, że urządzenia łączące się z bramą w chmurze są uwierzytelnione

      Tytuł Szczegóły
      Składnik Brama chmury IoT
      Faza SDL Tworzenie
      Odpowiednie technologie Generic, C#, Node.JS,
      Atrybuty Nie dotyczy, wybór bramy — Azure IoT Hub
      Dokumentacja N/A, usługa Azure IoT Hub z platformą .NET, wprowadzenie do centrum IoT i środowiska Node JS, zabezpieczanie IoT przy użyciu sygnatury dostępu współdzielonego i certyfikatów, repozytorium Git
      Kroki
      • Ogólne: Uwierzytelnianie urządzenia przy użyciu protokołu Transport Layer Security (TLS) lub IPSec. Infrastruktura powinna obsługiwać używanie klucza wstępnego (PSK) na tych urządzeniach, które nie mogą obsługiwać pełnej kryptografii asymetrycznej. Skorzystaj z identyfikatora Entra firmy Microsoft, protokołu Oauth.
      • C#: Podczas tworzenia wystąpienia DeviceClient domyślnie metoda Create tworzy wystąpienie DeviceClient, które używa protokołu AMQP do komunikowania się z usługą IoT Hub. Aby użyć protokołu HTTPS, użyj zastępowania metody Utwórz, które pozwala na określenie protokołu. Jeśli używasz protokołu HTTPS, należy również dodać Microsoft.AspNet.WebApi.Client pakiet NuGet do projektu, aby uwzględnić System.Net.Http.Formatting przestrzeń nazw.

      Przykład

      static DeviceClient deviceClient;

static string deviceKey = "{device key}";
static string iotHubUri = "{iot hub hostname}";

var messageString = "{message in string format}";
var message = new Message(Encoding.ASCII.GetBytes(messageString));

deviceClient = DeviceClient.Create(iotHubUri, new DeviceAuthenticationWithRegistrySymmetricKey("myFirstDevice", deviceKey));

await deviceClient.SendEventAsync(message);

      Przykład

      Node.JS: Uwierzytelnianie

      Klucz symetryczny

      • Tworzenie centrum IoT na platformie Azure
      • Tworzenie wpisu w rejestrze tożsamości urządzeń 
        var device = new iothub.Device(null);
device.deviceId = <DeviceId >
registry.create(device, function(err, deviceInfo, res) {})
      • Tworzenie symulowanego urządzenia 
        var clientFromConnectionString = require('azure-iot-device-amqp').clientFromConnectionString;
var Message = require('azure-iot-device').Message;
var connectionString = 'HostName=<HostName>DeviceId=<DeviceId>SharedAccessKey=<SharedAccessKey>';
var client = clientFromConnectionString(connectionString);

        Token sygnatury dostępu współdzielonego

      • Pobiera wewnętrznie generowane podczas korzystania z klucza symetrycznego, ale możemy je również wygenerować i użyć jawnie
      • Zdefiniuj protokół : var Http = require('azure-iot-device-http').Http;
      • Utwórz token sygnatury dostępu współdzielonego: 
        resourceUri = encodeURIComponent(resourceUri.toLowerCase()).toLowerCase();
var deviceName = "<deviceName >";
var expires = (Date.now() / 1000) + expiresInMins * 60;
var toSign = resourceUri + '\n' + expires;
// using crypto
var decodedPassword = new Buffer(signingKey, 'base64').toString('binary');
const hmac = crypto.createHmac('sha256', decodedPassword);
hmac.update(toSign);
var base64signature = hmac.digest('base64');
var base64UriEncoded = encodeURIComponent(base64signature);
// construct authorization string
var token = "SharedAccessSignature sr=" + resourceUri + "%2fdevices%2f"+deviceName+"&sig="
+ base64UriEncoded + "&se=" + expires;
if (policyName) token += "&skn="+policyName;
return token;
      • Połączenie przy użyciu tokenu sas:
        Client.fromSharedAccessSignature(sas, Http);

        Certyfikaty

      • Generowanie certyfikatu X509 z podpisem własnym przy użyciu dowolnego narzędzia, takiego jak OpenSSL, w celu wygenerowania plików cert i .key do przechowywania certyfikatu i klucza odpowiednio
      • Aprowizuj urządzenie, które akceptuje zabezpieczone połączenie przy użyciu certyfikatów. 
        var connectionString = '<connectionString>';
var registry = iothub.Registry.fromConnectionString(connectionString);
var deviceJSON = {deviceId:"<deviceId>",
authentication: {
    x509Thumbprint: {
    primaryThumbprint: "<PrimaryThumbprint>",
    secondaryThumbprint: "<SecondaryThumbprint>"
    }
}}
var device = deviceJSON;
registry.create(device, function (err) {});
      • Połączenie urządzenia przy użyciu certyfikatu
        var Protocol = require('azure-iot-device-http').Http;
var Client = require('azure-iot-device').Client;
var connectionString = 'HostName=<HostName>DeviceId=<DeviceId>x509=true';
var client = Client.fromConnectionString(connectionString, Protocol);
var options = {
    key: fs.readFileSync('./key.pem', 'utf8'),
    cert: fs.readFileSync('./server.crt', 'utf8')
};
// Calling setOptions with the x509 certificate and key (and optionally, passphrase) will configure the client //transport to use x509 when connecting to IoT Hub
client.setOptions(options);
//call fn to execute after the connection is set up
client.open(fn);

      Używanie poświadczeń uwierzytelniania poszczególnych urządzeń

      Tytuł Szczegóły
      Składnik Brama chmury IoT
      Faza SDL Tworzenie
      Odpowiednie technologie Ogólna
      Atrybuty Wybór bramy — Azure IoT Hub
      Dokumentacja Tokeny zabezpieczające usługi Azure IoT Hub
      Kroki Użyj poświadczeń uwierzytelniania na urządzeniu przy użyciu tokenów SaS opartych na kluczu urządzenia lub certyfikacie klienta zamiast zasad dostępu współdzielonego na poziomie usługi IoT Hub. Zapobiega to ponownemu używaniu tokenów uwierzytelniania jednego urządzenia lub bramy pola przez inne

      Upewnij się, że tylko wymagane kontenery i obiekty blob mają anonimowy dostęp do odczytu

      Tytuł Szczegóły
      Składnik Azure Storage
      Faza SDL Tworzenie
      Odpowiednie technologie Ogólna
      Atrybuty StorageType — obiekt blob
      Dokumentacja Zarządzanie anonimowym dostępem do odczytu do kontenerów i obiektów blob, sygnatur dostępu współdzielonego, część 1: Opis modelu sygnatur dostępu współdzielonego
      Kroki

      Domyślnie kontener i wszystkie obiekty blob w nim mogą być dostępne tylko przez właściciela konta magazynu. Aby przyznać anonimowym użytkownikom uprawnienia do odczytu do kontenera i jego obiektów blob, można ustawić uprawnienia kontenera, aby zezwolić na 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ć obiekty blob w kontenerze za pośrednictwem żądania anonimowego, ale nie mogą wyliczać kontenerów na koncie magazynu.
      • 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ć obiektów blob w kontenerze za pośrednictwem żądania anonimowego
      • Brak publicznego dostępu do odczytu: dane kontenera i obiektu blob mogą być odczytywane tylko przez właściciela konta

      Dostęp anonimowy jest najlepszy w scenariuszach, w których niektóre obiekty blob powinny być zawsze dostępne dla anonimowego dostępu do 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 mają przypadkowego dostępu anonimowego

      Udzielanie ograniczonego dostępu do obiektów w usłudze Azure Storage przy użyciu sygnatury dostępu współdzielonego lub SAP

      Tytuł Szczegóły
      Składnik Azure Storage
      Faza SDL Tworzenie
      Odpowiednie technologie Ogólna
      Atrybuty Nie dotyczy
      Dokumentacja Sygnatury dostępu współdzielonego, część 1: Opis modelu sygnatur dostępu współdzielonego, część 2: Tworzenie sygnatur dostępu współdzielonego i używanie go z usługą Blob Storage, Jak delegować dostęp do obiektów na koncie przy użyciu sygnatur dostępu współdzielonego i przechowywanych zasad dostępu
      Kroki

      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 parametry zapytania wszystkie informacje niezbędne do uwierzytelnionego dostępu do zasobu magazynu. 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.

      Sygnaturę dostępu współdzielonego można użyć, jeśli chcesz zapewnić dostęp do zasobów na koncie magazynu klientowi, któremu nie można ufać za pomocą 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ż używanie sygnatury dostępu współdzielonego pochodzącej z zasad dostępu przechowywanego zapewnia możliwość natychmiastowego odwoływanie tej sygnatury dostępu współdzielonego, zalecane jest, aby zawsze używać przechowywanych zasad dostępu, jeśli to możliwe.