Udostępnij przez

Ramka zabezpieczeń: Zabezpieczenia komunikacji | Środki zaradcze

Produkt/usługa Artykuł
Centrum zdarzeń platformy Azure
Dynamics CRM
Azure Data Factory
Serwer tożsamości
Aplikacja internetowa
Baza danych
Azure Storage
Klient mobilny
WCF
Internetowy interfejs API
Azure Cache for Redis
Brama polowa IoT
Bramka chmury IoT

Bezpieczna komunikacja z centrum zdarzeń przy użyciu protokołu SSL/TLS

Nazwa Szczegóły
Składnik Centrum zdarzeń Azure
Faza SDL Zbuduj
Zastosowalne technologie Generyczny
atrybutów N/A
Dokumentacja Omówienie uwierzytelniania i modelu zabezpieczeń usługi Event Hubs
Etapy Zabezpieczanie połączeń PROTOKOŁU AMQP lub HTTP z centrum zdarzeń przy użyciu protokołu SSL/TLS

Sprawdź uprawnienia konta usługi i sprawdź, czy usługi niestandardowe lub strony ASP.NET przestrzegają zabezpieczeń programu CRM

Nazwa Szczegóły
Składnik Dynamics CRM
Faza SDL Zbuduj
Zastosowalne technologie Generyczny
atrybutów N/A
Dokumentacja N/A
Etapy Sprawdź uprawnienia konta usługi i sprawdź, czy usługi niestandardowe lub strony ASP.NET przestrzegają zabezpieczeń programu CRM

Używanie bramy zarządzania danymi podczas łączenia lokalnego programu SQL Server z usługą Azure Data Factory

Nazwa Szczegóły
Składnik Azure Data Factory
Faza SDL Wdrożenie
Zastosowalne technologie Generyczny
atrybutów Połączone typy usług — platforma Azure i lokalna
Dokumentacja Przenoszenie danych między środowiskiem lokalnym i usługą Azure Data Factory
Etapy

Narzędzie Data Management Gateway (DMG) jest wymagane do łączenia się ze źródłami danych, które są chronione za wewnętrzną siecią korporacyjną lub zaporą.

  1. Blokowanie maszyny izoluje narzędzie DMG i uniemożliwia wadliwym działającym programom uszkodzenie lub szpiegowanie maszyny, która jest źródłem danych. (Np. należy zainstalować najnowsze aktualizacje, włączyć minimalną wymaganą liczbę portów, aprowizować kontrolowane konta, włączyć inspekcję, włączyć szyfrowanie dysków itp.)
  2. Klucz bramy danych musi być obracany w częstych odstępach czasu lub za każdym razem, gdy hasło konta usługi DMG jest odnawiane
  3. Dane przesyłane za pośrednictwem usługi linku muszą być szyfrowane

Upewnij się, że cały ruch do usługi Identity Server odbywa się za pośrednictwem połączenia HTTPS

Nazwa Szczegóły
Składnik Serwer tożsamości
Faza SDL Wdrożenie
Zastosowalne technologie Generyczny
atrybutów N/A
Dokumentacja N/A
Etapy Domyślnie usługa IdentityServer wymaga, aby wszystkie połączenia przychodzące pochodziły za pośrednictwem protokołu HTTPS. Absolutnie obowiązkowe jest, aby komunikacja z usługą IdentityServer odbywała się tylko za pośrednictwem zabezpieczonych transportów. Istnieją pewne scenariusze wdrażania, takie jak odciążanie protokołu TLS, w których to wymaganie może zostać złagodzone. Aby uzyskać więcej informacji, zobacz stronę wdrażania programu Identity Server w dokumentacji.

Weryfikowanie certyfikatów X.509 używanych do uwierzytelniania połączeń SSL, TLS i DTLS

Nazwa Szczegóły
Składnik Aplikacja internetowa
Faza SDL Zbuduj
Zastosowalne technologie Generyczny
atrybutów N/A
Dokumentacja N/A
Etapy

Aplikacje korzystające z protokołu SSL, TLS lub DTLS muszą w pełni zweryfikować certyfikaty X.509 jednostek, z którymi się łączą. Obejmuje to weryfikację certyfikatów dla:

  • Nazwa domeny
  • Daty ważności (daty rozpoczęcia i wygaśnięcia)
  • Stan odwołania
  • Użycie (na przykład uwierzytelnianie serwera dla serwerów, uwierzytelnianie klienta dla klientów)
  • Łańcuch zaufania. Certyfikaty muszą być powiązane z głównym urzędem certyfikacji zaufanym przez platformę lub jawnie skonfigurowanym przez administratora
  • Długość klucza publicznego certyfikatu musi wynosić >2048 bitów
  • Algorytm haszowania musi być SHA256 lub wyższy

Konfigurowanie certyfikatu TLS/SSL dla domeny niestandardowej w usłudze Azure App Service

Nazwa Szczegóły
Składnik Aplikacja internetowa
Faza SDL Zbuduj
Zastosowalne technologie Generyczny
atrybutów EnvironmentType — Azure
Dokumentacja Włączanie protokołu HTTPS dla aplikacji w usłudze Azure App Service
Etapy Azure domyślnie włącza protokół HTTPS dla każdej aplikacji z certyfikatem wieloznacznikowym dla domeny *.azurewebsites.net. Jednak podobnie jak wszystkie domeny z symbolami wieloznacznymi, nie jest tak bezpieczne, jak używanie domeny niestandardowej z własnym certyfikatem Refer. Zaleca się włączenie protokołu TLS dla domeny niestandardowej, do której będzie uzyskiwany dostęp wdrożona aplikacja

Wymuszenie całego ruchu sieciowego do usługi Azure App Service za pośrednictwem połączenia HTTPS

Nazwa Szczegóły
Składnik Aplikacja internetowa
Faza SDL Zbuduj
Zastosowalne technologie Generyczny
atrybutów EnvironmentType — Azure
Dokumentacja Wymuszanie protokołu HTTPS w usłudze Azure App Service
Etapy

Chociaż platforma Azure już włącza protokół HTTPS dla usług aplikacji platformy Azure z certyfikatem wieloznacznikowym dla domeny *.azurewebsites.net, nie wymusza protokołu HTTPS. Odwiedzający mogą nadal uzyskiwać dostęp do aplikacji przy użyciu protokołu HTTP, co może naruszyć bezpieczeństwo aplikacji, dlatego protokół HTTPS musi być wymuszany jawnie. ASP.NET aplikacje MVC powinny używać filtru RequireHttps , który wymusza ponowne wysyłanie niezabezpieczonego żądania HTTP za pośrednictwem protokołu HTTPS.

Alternatywnie moduł ponownego zapisywania adresów URL, który jest dołączony do usługi Azure App Service, może służyć do wymuszania protokołu HTTPS. Moduł ponownego zapisywania adresów URL umożliwia deweloperom definiowanie reguł stosowanych do żądań przychodzących przed przekazaniem żądań do aplikacji. Reguły ponownego zapisywania adresów URL są definiowane w pliku web.config przechowywanym w katalogu głównym aplikacji

Przykład

Poniższy przykład zawiera podstawową regułę ponownego zapisywania adresów URL, która wymusza używanie protokołu HTTPS przez cały ruch przychodzący

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="Force HTTPS" enabled="true">
          <match url="(.*)" ignoreCase="false" />
          <conditions>
            <add input="{HTTPS}" pattern="off" />
          </conditions>
          <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" appendQueryString="true" redirectType="Permanent" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

Ta reguła działa, zwracając kod stanu HTTP 301 (trwałe przekierowanie), gdy użytkownik żąda strony przy użyciu protokołu HTTP. Element 301 przekierowuje żądanie do tego samego adresu URL co żądany użytkownik, ale zastępuje część HTTP żądania protokołem HTTPS. Na przykład HTTP://contoso.com zostanie przekierowany do HTTPS://contoso.com.

Włączanie protokołu HTTP Strict Transport Security (HSTS)

Nazwa Szczegóły
Składnik Aplikacja internetowa
Faza SDL Zbuduj
Zastosowalne technologie Generyczny
atrybutów N/A
Dokumentacja OWASP Przewodnik HTTP Strict Transport Security
Etapy

HTTP Strict Transport Security (HSTS) jest dobrowolnym rozszerzeniem bezpieczeństwa, które jest określane przez aplikację internetową poprzez wykorzystanie specjalnego nagłówka odpowiedzi. Gdy obsługiwana przeglądarka odbierze ten nagłówek, przeglądarka uniemożliwi wysyłanie jakiejkolwiek komunikacji za pośrednictwem protokołu HTTP do określonej domeny i zamiast tego wyśle całą komunikację za pośrednictwem protokołu HTTPS. Zapobiega to również kliknięciu protokołu HTTPS za pośrednictwem monitów w przeglądarkach.

Aby zaimplementować moduł HSTS, następujący nagłówek odpowiedzi musi być skonfigurowany globalnie dla witryny internetowej w kodzie lub w konfiguracji. Strict-Transport-Security: max-age=300; includeSubDomains HSTS rozwiązuje następujące zagrożenia:

  • Zakładki użytkownika lub ręcznie wpisuje https://example.com i są narażeni na atak typu man-in-the-middle: HSTS automatycznie przekierowuje żądania HTTP do protokołu HTTPS dla domeny docelowej
  • Aplikacja internetowa przeznaczona wyłącznie do niezamierzonego stosowania protokołu HTTPS zawiera linki HTTP lub udostępnia zawartość za pośrednictwem protokołu HTTP: usługa HSTS automatycznie przekierowuje żądania HTTP do protokołu HTTPS dla domeny docelowej
  • Atakujący typu man-in-the-middle próbuje przechwycić ruch ofiary przy użyciu nieprawidłowego certyfikatu, mając nadzieję, że użytkownik zaakceptuje zły certyfikat: HSTS nie zezwala użytkownikowi na zastąpienie komunikatu o nieprawidłowym certyfikacie.

Upewnij się, że połączenia z SQL Server są szyfrowane i certyfikaty są weryfikowane.

Nazwa Szczegóły
Składnik Baza danych
Faza SDL Zbuduj
Zastosowalne technologie SQL Azure
atrybutów Wersja SQL — wersja 12
Dokumentacja Najlepsze rozwiązania dotyczące pisania bezpiecznych parametrów połączenia dla usługi SQL Database
Etapy

Cała komunikacja między usługą SQL Database a aplikacją kliencką jest szyfrowana przy użyciu protokołu Transport Layer Security (TLS), wcześniej znanego jako Secure Sockets Layer (SSL), przez cały czas. Usługa SQL Database nie obsługuje niezaszyfrowanych połączeń. Aby zweryfikować certyfikaty przy użyciu kodu aplikacji lub narzędzi, jawnie zażądaj zaszyfrowanego połączenia i nie ufaj certyfikatom serwera. Jeśli kod aplikacji lub narzędzia nie żądają zaszyfrowanego połączenia, nadal będą odbierać szyfrowane połączenia

Mogą jednak nie weryfikować certyfikatów serwera i w związku z tym będą podatne na ataki typu "człowiek w środku". Aby zweryfikować certyfikaty za pomocą kodu aplikacji ADO.NET, ustaw Encrypt=True i TrustServerCertificate=False w parametrach połączenia bazy danych. Aby zweryfikować certyfikaty za pośrednictwem programu SQL Server Management Studio, otwórz okno dialogowe Łączenie z serwerem. Kliknij pozycję Szyfruj połączenie na karcie Właściwości połączenia

Wymuszanie zaszyfrowanej komunikacji z serwerem SQL

Nazwa Szczegóły
Składnik Baza danych
Faza SDL Zbuduj
Zastosowalne technologie Lokalny
atrybutów Wersja sql — MsSQL2016, wersja SQL — MsSQL2012, wersja SQL — MsSQL2014
Dokumentacja Włącz szyfrowane połączenia z silnikiem bazy danych
Etapy Włączenie szyfrowania TLS zwiększa bezpieczeństwo danych przesyłanych między sieciami między wystąpieniami programu SQL Server i aplikacji.

Upewnij się, że komunikacja z usługą Azure Storage odbywa się za pośrednictwem protokołu HTTPS

Nazwa Szczegóły
Składnik Azure Storage
Faza SDL Wdrożenie
Zastosowalne technologie Generyczny
atrybutów N/A
Dokumentacja Szyfrowanie Transport-Level usługi Azure Storage — korzystanie z protokołu HTTPS
Etapy Aby zapewnić bezpieczeństwo przesyłanych danych usługi Azure Storage, zawsze używaj protokołu HTTPS podczas wywoływania interfejsów API REST lub uzyskiwania dostępu do obiektów w magazynie. Ponadto sygnatury dostępu współdzielonego, które mogą służyć do delegowania dostępu do obiektów usługi Azure Storage, zawierają opcję określenia, że można używać tylko protokołu HTTPS podczas korzystania z sygnatur dostępu współdzielonego, zapewniając, że każda osoba wysyłająca linki z tokenami SAS będzie używać odpowiedniego protokołu.

Zweryfikuj skrót MD5 po pobraniu pliku, jeśli nie można włączyć HTTPS

Nazwa Szczegóły
Składnik Azure Storage
Faza SDL Zbuduj
Zastosowalne technologie Generyczny
atrybutów Typ przechowywania - Blob
Dokumentacja Omówienie usługi Windows Azure Blob MD5
Etapy

Usługa Windows Azure Blob Service udostępnia mechanizmy zapewniające integralność danych zarówno w warstwach aplikacji, jak i transportu. Jeśli z jakiegokolwiek powodu musisz użyć protokołu HTTP zamiast protokołu HTTPS i pracujesz z blokowymi obiektami blob, możesz użyć sprawdzania MD5, aby pomóc zweryfikować integralność przesyłanych obiektów blob

Pomoże to w ochronie przed błędami warstwy sieci/transportu, ale niekoniecznie przed atakami pośredniczącymi. Jeśli możesz użyć protokołu HTTPS, który zapewnia zabezpieczenia na poziomie transportu, użycie sprawdzania MD5 jest nadmiarowe i niepotrzebne.

Użyj zgodnego klienta SMB 3.x, aby zapewnić szyfrowanie danych przesyłanych do udziałów plików platformy Azure

Nazwa Szczegóły
Składnik Klient mobilny
Faza SDL Zbuduj
Zastosowalne technologie Generyczny
atrybutów StorageType - Plik
Dokumentacja Azure Files, obsługa protokołu SMB usługi Azure Files dla klientów z systemem Windows
Etapy Usługa Azure Files obsługuje protokół HTTPS podczas korzystania z interfejsu API REST. Jednak częściej wykorzystuje się ją jako udział plików SMB, który jest dołączany do maszyny wirtualnej. Protokół SMB 2.1 nie obsługuje szyfrowania, więc połączenia są dozwolone tylko w tym samym regionie na platformie Azure. Jednak protokół SMB 3.x obsługuje szyfrowanie i może być używany z systemami Windows Server 2012 R2, Windows 8, Windows 8.1 i Windows 10, umożliwiając dostęp między regionami, a nawet dostęp na pulpicie.

Implementacja przypinania certyfikatu

Nazwa Szczegóły
Składnik Azure Storage
Faza SDL Zbuduj
Zastosowalne technologie Ogólne, Windows Phone
atrybutów N/A
Dokumentacja Przypinanie certyfikatu i klucza publicznego
Etapy

Przypinanie certyfikatu broni przed atakami man-in-The-Middle (MITM). Przypinanie to proces przypisywania hostowi oczekiwanego certyfikatu X509 lub klucza publicznego. Gdy certyfikat lub klucz publiczny jest znany lub widoczny dla hosta, certyfikat lub klucz publiczny jest skojarzony lub "przypięty" do hosta.

W związku z tym, gdy osoba atakująca próbuje przeprowadzić atak TLS MITM, podczas uzgadniania protokołu TLS klucz z serwera atakującego będzie inny niż klucz przypiętego certyfikatu. W wyniku tego żądanie zostanie odrzucone, co zapobiega atakom typu MITM. Przypinanie certyfikatów można osiągnąć poprzez zaimplementowanie delegata programu ServicePointManager ServerCertificateValidationCallback.

Przykład

using System;
using System.Net;
using System.Net.Security;
using System.Security.Cryptography;

namespace CertificatePinningExample
{
    class CertificatePinningExample
    {
        /* Note: In this example, we're hardcoding the certificate's public key and algorithm for 
           demonstration purposes. In a real-world application, this should be stored in a secure
           configuration area that can be updated as needed. */

        private static readonly string PINNED_ALGORITHM = "RSA";

        private static readonly string PINNED_PUBLIC_KEY = "3082010A0282010100B0E75B7CBE56D31658EF79B3A1" +
            "294D506A88DFCDD603F6EF15E7F5BCBDF32291EC50B2B82BA158E905FE6A83EE044A48258B07FAC3D6356AF09B2" +
            "3EDAB15D00507B70DB08DB9A20C7D1201417B3071A346D663A241061C151B6EC5B5B4ECCCDCDBEA24F051962809" +
            "FEC499BF2D093C06E3BDA7D0BB83CDC1C2C6660B8ECB2EA30A685ADE2DC83C88314010FFC7F4F0F895EDDBE5C02" +
            "ABF78E50B708E0A0EB984A9AA536BCE61A0C31DB95425C6FEE5A564B158EE7C4F0693C439AE010EF83CA8155750" +
            "09B17537C29F86071E5DD8CA50EBD8A409494F479B07574D83EDCE6F68A8F7D40447471D05BC3F5EAD7862FA748" +
            "EA3C92A60A128344B1CEF7A0B0D94E50203010001";


        public static void Main(string[] args)
        {
            HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://azure.microsoft.com");
            request.ServerCertificateValidationCallback = (sender, certificate, chain, sslPolicyErrors) =>
            {
                if (certificate == null || sslPolicyErrors != SslPolicyErrors.None)
                {
                    // Error getting certificate or the certificate failed basic validation
                    return false;
                }

                var targetKeyAlgorithm = new Oid(certificate.GetKeyAlgorithm()).FriendlyName;
                var targetPublicKey = certificate.GetPublicKeyString();
                
                if (targetKeyAlgorithm == PINNED_ALGORITHM &&
                    targetPublicKey == PINNED_PUBLIC_KEY)
                {
                    // Success, the certificate matches the pinned value.
                    return true;
                }
                // Reject, either the key or the algorithm does not match the expected value.
                return false;
            };

            try
            {
                var response = (HttpWebResponse)request.GetResponse();
                Console.WriteLine($"Success, HTTP status code: {response.StatusCode}");
            }
            catch(Exception ex)
            {
                Console.WriteLine($"Failure, {ex.Message}");
            }
            Console.WriteLine("Press any key to end.");
            Console.ReadKey();
        }
    }
}

Włączanie protokołu HTTPS — bezpieczny kanał transportu

Nazwa Szczegóły
Składnik WCF (Windows Communication Foundation)
Faza SDL Zbuduj
Zastosowalne technologie NET Framework 3
atrybutów N/A
Dokumentacja MSDN, Fortify Kingdom
Etapy Konfiguracja aplikacji powinna zapewnić, że protokół HTTPS jest używany do uzyskiwania dostępu do poufnych informacji.
  • WYJAŚNIENIE: Jeśli aplikacja obsługuje poufne informacje i nie używa szyfrowania na poziomie komunikatów, powinno być dozwolone tylko komunikowanie się za pośrednictwem szyfrowanego kanału transportu.
  • ZALECENIA: Upewnij się, że transport HTTP jest wyłączony i włącz zamiast tego transport HTTPS. Na przykład zastąp element tagiem <httpTransport/><httpsTransport/> . Nie należy polegać na konfiguracji sieci (zapory), aby zagwarantować, że dostęp do aplikacji można uzyskać tylko za pośrednictwem bezpiecznego kanału. Z filozoficznego punktu widzenia aplikacja nie powinna zależeć od sieci w celu zapewnienia jej bezpieczeństwa.

Z praktycznego punktu widzenia osoby odpowiedzialne za zabezpieczanie sieci nie zawsze śledzą wymagania dotyczące zabezpieczeń aplikacji w miarę ich rozwoju.

WCF: ustaw poziom zabezpieczeń komunikatów na EncryptAndSign

Nazwa Szczegóły
Składnik WCF (Windows Communication Foundation)
Faza SDL Zbuduj
Zastosowalne technologie .NET Framework 3
atrybutów N/A
Dokumentacja MSDN
Etapy
  • WYJAŚNIENIE: Po ustawieniu poziomu ochrony na wartość "none" zostanie wyłączona ochrona komunikatów. Poufność i integralność są osiągane przy użyciu odpowiedniego poziomu ustawienia.
  • ZALECENIA:
    • when Mode=None — wyłącza ochronę komunikatów
    • when Mode=Sign — podpisuje, ale nie szyfruje wiadomości. Należy użyć, gdy ważna jest integralność danych.
    • when Mode=EncryptAndSign — podpisuje i szyfruje komunikat

Rozważ wyłączenie szyfrowania i podpisywanie wiadomości tylko wtedy, gdy wystarczy zweryfikować integralność informacji bez obaw o poufność. Może to być przydatne w przypadku operacji lub kontraktów usług, w których trzeba zweryfikować oryginalnego nadawcę, ale nie są przesyłane żadne poufne dane. Podczas zmniejszania poziomu ochrony należy zachować ostrożność, że wiadomość nie zawiera żadnych danych osobowych.

Przykład

Konfiguracja usługi i operacji tak, aby tylko podpisywać komunikat, jest pokazana w poniższych przykładach. Przykład kontraktu usługi : ProtectionLevel.SignPoniżej przedstawiono przykład użycia elementu ProtectionLevel.Sign na poziomie kontraktu usługi:

[ServiceContract(Protection Level=ProtectionLevel.Sign] 
public interface IService 
  { 
  string GetData(int value); 
  }

Przykład

Przykład kontraktu operacji ProtectionLevel.Sign (dla szczegółowego sterowania): Poniżej przedstawiono przykład użycia ProtectionLevel.Sign na poziomie OperationContract:

[OperationContract(ProtectionLevel=ProtectionLevel.Sign] 
string GetData(int value);

WCF: uruchamianie usługi WCF przy użyciu konta z najniższymi uprawnieniami

Nazwa Szczegóły
Składnik WCF (Windows Communication Foundation)
Faza SDL Zbuduj
Zastosowalne technologie .NET Framework 3
atrybutów N/A
Dokumentacja MSDN
Etapy
  • WYJAŚNIENIE: Nie uruchamiaj usług WCF w ramach konta administratora lub konta z wysokim poziomem uprawnień. w przypadku naruszenia zabezpieczeń usług będzie to miało duży wpływ.
  • ZALECENIA: Użyj konta z najniższymi uprawnieniami, aby hostować usługę WCF, ponieważ zmniejszy ona obszar ataków aplikacji i zmniejszy potencjalne szkody w przypadku ataku. Jeśli konto usługi wymaga dodatkowych praw dostępu do zasobów infrastruktury, takich jak MSMQ, dziennik zdarzeń, liczniki wydajności i system plików, odpowiednie uprawnienia powinny zostać przyznane tym zasobom, aby usługa WCF mogła działać pomyślnie.

Jeśli Usługa musi uzyskać dostęp do określonych zasobów w imieniu oryginalnego obiektu wywołującego, użyj personifikacji i delegowania, aby przekazać tożsamość obiektu wywołującego do kontroli autoryzacji podrzędnej. W scenariuszu programistycznym użyj lokalnego konta usługi sieciowej, które jest specjalnym wbudowanym kontem z ograniczonymi uprawnieniami. W scenariuszu produkcyjnym utwórz niestandardowe konto usługi domeny z najniższymi uprawnieniami.

Wymuszanie całego ruchu do internetowych interfejsów API za pośrednictwem połączenia HTTPS

Nazwa Szczegóły
Składnik Internetowe API
Faza SDL Zbuduj
Zastosowalne technologie MVC5, MVC6
atrybutów N/A
Dokumentacja Wymuszanie protokołu SSL w kontrolerze internetowego interfejsu API
Etapy Jeśli aplikacja ma zarówno protokół HTTPS, jak i powiązanie HTTP, klienci nadal mogą używać protokołu HTTP do uzyskiwania dostępu do lokacji. Aby temu zapobiec, użyj filtru akcji, aby upewnić się, że żądania do chronionych interfejsów API są zawsze za pośrednictwem protokołu HTTPS.

Przykład

Poniższy kod przedstawia filtr uwierzytelniania internetowego interfejsu API, który sprawdza protokół TLS:

public class RequireHttpsAttribute : AuthorizationFilterAttribute
{
    public override void OnAuthorization(HttpActionContext actionContext)
    {
        if (actionContext.Request.RequestUri.Scheme != Uri.UriSchemeHttps)
        {
            actionContext.Response = new HttpResponseMessage(System.Net.HttpStatusCode.Forbidden)
            {
                ReasonPhrase = "HTTPS Required"
            };
        }
        else
        {
            base.OnAuthorization(actionContext);
        }
    }
}

Dodaj ten filtr do dowolnych akcji internetowego interfejsu API, które wymagają protokołu TLS:

public class ValuesController : ApiController
{
    [RequireHttps]
    public HttpResponseMessage Get() { ... }
}

Upewnij się, że komunikacja z usługą Azure Cache for Redis odbywa się za pośrednictwem protokołu TLS

Nazwa Szczegóły
Składnik Usługa Azure Cache dla Redis
Faza SDL Zbuduj
Zastosowalne technologie Generyczny
atrybutów N/A
Dokumentacja Obsługa protokołu TLS w usłudze Azure Redis
Etapy Serwer Redis nie obsługuje gotowego protokołu TLS, ale usługa Azure Cache for Redis nie obsługuje protokołu TLS. Jeśli łączysz się z usługą Azure Cache for Redis, a klient obsługuje protokół TLS, taki jak StackExchange.Redis, należy użyć protokołu TLS. Domyślnie port inny niż TLS jest wyłączony dla nowych wystąpień usługi Azure Cache for Redis. Upewnij się, że bezpieczne wartości domyślne nie zostaną zmienione, chyba że istnieje zależność od obsługi protokołu TLS dla klientów redis.

Należy pamiętać, że usługa Redis jest przeznaczona do uzyskiwania dostępu przez zaufanych klientów w zaufanych środowiskach. Oznacza to, że zwykle nie jest dobrym pomysłem wystawiać instancję Redis bezpośrednio na zewnątrz, na przykład do Internetu, lub, ogólnie rzecz biorąc, do środowiska, w którym niezaufani klienci mogą bezpośrednio uzyskać dostęp do portu TCP lub gniazda UNIX usługi Redis.

Zabezpieczanie komunikacji urządzenia z usługą Field Gateway

Nazwa Szczegóły
Składnik Brama pola IoT
Faza SDL Zbuduj
Zastosowalne technologie Generyczny
atrybutów N/A
Dokumentacja N/A
Etapy W przypadku urządzeń opartych na adresach IP protokół komunikacyjny może być zwykle hermetyzowany w kanale SSL/TLS w celu ochrony danych przesyłanych. W przypadku innych protokołów, które nie obsługują protokołu SSL/TLS, należy zbadać, czy istnieją bezpieczne wersje protokołu zapewniające zabezpieczenia w warstwie transportu lub komunikatów.

Zabezpieczanie komunikacji urządzenia z usługą Cloud Gateway przy użyciu protokołu SSL/TLS

Nazwa Szczegóły
Składnik Bramka chmurowa IoT
Faza SDL Zbuduj
Zastosowalne technologie Generyczny
atrybutów N/A
Dokumentacja Wybieranie protokołu komunikacyjnego
Etapy Zabezpieczanie protokołów HTTP/AMQP lub MQTT przy użyciu protokołu SSL/TLS.
  • Last updated on