Ramka zabezpieczeń: Zabezpieczenia komunikacji | Czynniki

Artykuł
10/20/2023

Produkt/usługa	Artykuł
Azure Event Hub	Bezpieczna komunikacja z centrum zdarzeń przy użyciu protokołu SSL/TLS
Dynamics CRM	Sprawdź uprawnienia konta usługi i sprawdź, czy usługi niestandardowe lub strony ASP.NET przestrzegają zabezpieczeń programu CRM
Azure Data Factory	Używanie bramy zarządzania danymi podczas łączenia lokalnego programu SQL Server z usługą Azure Data Factory
Serwer tożsamości	Upewnij się, że cały ruch do usługi Identity Server odbywa się za pośrednictwem połączenia HTTPS
Aplikacja internetowa	Weryfikowanie certyfikatów X.509 używanych do uwierzytelniania połączeń SSL, TLS i DTLS Konfigurowanie certyfikatu TLS/SSL dla domeny niestandardowej w usłudze aplikacja systemu Azure Wymuszanie całego ruchu do usługi aplikacja systemu Azure za pośrednictwem połączenia HTTPS Włączanie protokołu HTTP Strict Transport Security (HSTS)
Baza danych	Upewnij się, że szyfrowanie połączeń z programem SQL Server i walidacja certyfikatu Wymuszanie zaszyfrowanej komunikacji z serwerem SQL
Azure Storage	Upewnij się, że komunikacja z usługą Azure Storage odbywa się za pośrednictwem protokołu HTTPS Zweryfikuj skrót MD5 po pobraniu obiektu blob, jeśli nie można włączyć protokołu HTTPS Użyj zgodnego klienta SMB 3.0, aby zapewnić szyfrowanie danych przesyłanych do udziałów plików platformy Azure
Klient mobilny	Implementowanie przypinania certyfikatu
WCF	Włączanie protokołu HTTPS — bezpieczny kanał transportu WCF: ustaw poziom ochrony zabezpieczeń komunikatów na Wartość EncryptAndSign WCF: uruchamianie usługi WCF przy użyciu konta z najniższymi uprawnieniami
Internetowy interfejs API	Wymuszanie całego ruchu do internetowych interfejsów API za pośrednictwem połączenia HTTPS
Azure Cache for Redis	Upewnij się, że komunikacja z usługą Azure Cache for Redis odbywa się za pośrednictwem protokołu TLS
Brama pola IoT	Zabezpieczanie komunikacji urządzenia z usługą Field Gateway
Brama chmury IoT	Zabezpieczanie komunikacji urządzenia z usługą Cloud Gateway przy użyciu protokołu SSL/TLS

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

Stanowisko	Szczegóły
Składnik	Centrum zdarzeń Azure
Faza SDL	Kompilacja
Odpowiednie technologie	Ogólny element
Atrybuty	Nie dotyczy
Dokumentacja	Omówienie uwierzytelniania i modelu zabezpieczeń usługi Event Hubs
Kroki	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

Stanowisko	Szczegóły
Składnik	Dynamics CRM
Faza SDL	Kompilacja
Odpowiednie technologie	Ogólny element
Atrybuty	Nie dotyczy
Dokumentacja	Nie dotyczy
Kroki	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

Stanowisko	Szczegóły
Składnik	Azure Data Factory
Faza SDL	Wdrażanie
Odpowiednie technologie	Ogólny element
Atrybuty	Połączone typy usług — platforma Azure i lokalna
Dokumentacja	Przenoszenie danych między środowiskiem lokalnym i usługą Azure Data Factory
Kroki	Narzędzie Zarządzanie danymi Gateway (DMG) jest wymagane do łączenia się ze źródłami danych chronionymi za siecią corpnet lub zaporą. Blokowanie maszyny izoluje narzędzie DMG i uniemożliwia nieprawidłowe działanie programów przed uszkodzeniem lub snoopingiem na maszynie źródła 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.) 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 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

Stanowisko	Szczegóły
Składnik	Serwer tożsamości
Faza SDL	Wdrażanie
Odpowiednie technologie	Ogólny element
Atrybuty	Nie dotyczy
Dokumentacja	IdentityServer3 — klucze, podpisy i kryptografia, IdentityServer3 — wdrażanie
Kroki	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

Stanowisko	Szczegóły
Składnik	Aplikacja internetowa
Faza SDL	Kompilacja
Odpowiednie technologie	Ogólny element
Atrybuty	Nie dotyczy
Dokumentacja	Nie dotyczy
Kroki	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 wyznaczania wartości skrótu musi być sha256 i nowszy

Konfigurowanie certyfikatu TLS/SSL dla domeny niestandardowej w usłudze aplikacja systemu Azure

Stanowisko	Szczegóły
Składnik	Aplikacja internetowa
Faza SDL	Kompilacja
Odpowiednie technologie	Ogólny element
Atrybuty	EnvironmentType — Azure
Dokumentacja	Włączanie protokołu HTTPS dla aplikacji w usłudze aplikacja systemu Azure Service
Kroki	Domyślnie platforma Azure obsługuje już protokół HTTPS dla każdej aplikacji z certyfikatem wieloznacznymi 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

Wymuszanie całego ruchu do usługi aplikacja systemu Azure za pośrednictwem połączenia HTTPS

Stanowisko	Szczegóły
Składnik	Aplikacja internetowa
Faza SDL	Kompilacja
Odpowiednie technologie	Ogólny element
Atrybuty	EnvironmentType — Azure
Dokumentacja	Wymuszanie protokołu HTTPS w usłudze aplikacja systemu Azure
Kroki	Chociaż platforma Azure już włącza protokół HTTPS dla usług aplikacji platformy Azure z certyfikatem wieloznacznymi 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 dołączony do usługi aplikacja systemu Azure 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 nastąpi przekierowanie do HTTPS://contoso.com.

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

Stanowisko	Szczegóły
Składnik	Aplikacja internetowa
Faza SDL	Kompilacja
Odpowiednie technologie	Ogólny element
Atrybuty	Nie dotyczy
Dokumentacja	Ściągawka OWASP HTTP Strict Transport Security
Kroki	Http Strict Transport Security (HSTS) to rozszerzenie zabezpieczeń, które jest określane przez aplikację internetową za pomocą 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 typy `https://example.com` i podlegają osobie atakującej typu man-in-the-middle: usługa 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 Osoba atakująca typu man-in-the-middle próbuje przechwycić ruch od użytkownika ofiary przy użyciu nieprawidłowego certyfikatu i ma nadzieję, że użytkownik zaakceptuje zły certyfikat: usługa HSTS nie zezwala użytkownikowi na zastąpienie nieprawidłowego komunikatu o certyfikacie

Upewnij się, że szyfrowanie połączeń z programem SQL Server i walidacja certyfikatu

Stanowisko	Szczegóły
Składnik	Baza danych
Faza SDL	Kompilacja
Odpowiednie technologie	SQL Azure
Atrybuty	Wersja SQL — wersja 12
Dokumentacja	Najlepsze rozwiązania dotyczące pisania bezpiecznych ciągów Połączenie ion dla usługi SQL Database
Kroki	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 przy użyciu kodu aplikacji ADO.NET, ustaw `Encrypt=True` i `TrustServerCertificate=False` w parametry połączenia bazy danych. Aby zweryfikować certyfikaty za pośrednictwem programu SQL Server Management Studio, otwórz okno dialogowe Połączenie na serwer. Kliknij pozycję Szyfruj połączenie na karcie Właściwości Połączenie ion

Wymuszanie zaszyfrowanej komunikacji z serwerem SQL

Stanowisko	Szczegóły
Składnik	Baza danych
Faza SDL	Kompilacja
Odpowiednie technologie	Lokalny
Atrybuty	Wersja sql — MsSQL2016, wersja SQL — MsSQL2012, wersja SQL — MsSQL2014
Dokumentacja	Włączanie szyfrowanych połączeń z aparatem bazy danych
Kroki	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

Stanowisko	Szczegóły
Składnik	Azure Storage
Faza SDL	Wdrażanie
Odpowiednie technologie	Ogólny element
Atrybuty	Nie dotyczy
Dokumentacja	Szyfrowanie na poziomie transportu usługi Azure Storage — korzystanie z protokołu HTTPS
Kroki	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 obiektu blob, jeśli nie można włączyć protokołu HTTPS

Stanowisko	Szczegóły
Składnik	Azure Storage
Faza SDL	Kompilacja
Odpowiednie technologie	Ogólny element
Atrybuty	StorageType — obiekt blob
Dokumentacja	Omówienie usługi Windows Azure Blob MD5
Kroki	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 z 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

Stanowisko	Szczegóły
Składnik	Klient mobilny
Faza SDL	Kompilacja
Odpowiednie technologie	Ogólny element
Atrybuty	StorageType — plik
Dokumentacja	Azure Files, obsługa protokołu SMB usługi Azure Files dla klientów z systemem Windows
Kroki	Usługa Azure Files obsługuje protokół HTTPS podczas korzystania z interfejsu API REST, ale jest częściej używana jako udział plików SMB dołączony 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.

Implementowanie przypinania certyfikatu

Stanowisko	Szczegóły
Składnik	Azure Storage
Faza SDL	Kompilacja
Odpowiednie technologie	Generic, Windows Telefon
Atrybuty	Nie dotyczy
Dokumentacja	Przypinanie certyfikatu i klucza publicznego
Kroki	Przypinanie certyfikatu broni przed atakami Man-In-The-Middle (MITM). Przypinanie to proces kojarzenia hosta z oczekiwanym certyfikatem X509 lub kluczem publicznym. 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 wykonać atak TLS MITM, podczas uzgadniania protokołu TLS klucz z serwera osoby atakującej będzie inny niż przypięty certyfikat, a żądanie zostanie odrzucone, uniemożliwiając tym samym osiągnięcie przypinania certyfikatu MITM przez zaimplementowanie delegata `ServerCertificateValidationCallback` programu ServicePointManager.

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

Stanowisko	Szczegóły
Składnik	WCF
Faza SDL	Kompilacja
Odpowiednie technologie	NET Framework 3
Atrybuty	Nie dotyczy
Dokumentacja	MSDN, Fortify Kingdom
Kroki	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 zamiast tego włącz 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 ochrony zabezpieczeń komunikatów na Wartość EncryptAndSign

Stanowisko	Szczegóły
Składnik	WCF
Faza SDL	Kompilacja
Odpowiednie technologie	.NET Framework 3
Atrybuty	Nie dotyczy
Dokumentacja	MSDN
Kroki	WYJAŚNIENIE: Gdy poziom ochrony jest ustawiony na wartość "none", wyłączy ochronę 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` — znaki, ale nie szyfrują komunikatu; należy użyć, gdy integralność danych jest ważna 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

Skonfigurowanie usługi i operacji podpisywania komunikatu jest wyświetlane tylko 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 (dla kontrolki ProtectionLevel.Sign szczegółowej): 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

Stanowisko	Szczegóły
Składnik	WCF
Faza SDL	Kompilacja
Odpowiednie technologie	.NET Framework 3
Atrybuty	Nie dotyczy
Dokumentacja	MSDN
Kroki	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

Stanowisko	Szczegóły
Składnik	Internetowy interfejs API
Faza SDL	Kompilacja
Odpowiednie technologie	MVC5, MVC6
Atrybuty	Nie dotyczy
Dokumentacja	Wymuszanie protokołu SSL w kontrolerze internetowego interfejsu API
Kroki	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

Stanowisko	Szczegóły
Składnik	Azure Cache for Redis
Faza SDL	Kompilacja
Odpowiednie technologie	Ogólny element
Atrybuty	Nie dotyczy
Dokumentacja	Obsługa protokołu TLS w usłudze Azure Redis
Kroki	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, aby uwidocznić wystąpienie usługi Redis bezpośrednio w Internecie lub ogólnie w środowisku, w którym niezaufani klienci mogą bezpośrednio uzyskać dostęp do portu TCP usługi Redis lub gniazda system UNIX.

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

Stanowisko	Szczegóły
Składnik	Brama pola IoT
Faza SDL	Kompilacja
Odpowiednie technologie	Ogólny element
Atrybuty	Nie dotyczy
Dokumentacja	Nie dotyczy
Kroki	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

Stanowisko	Szczegóły
Składnik	Brama chmury IoT
Faza SDL	Kompilacja
Odpowiednie technologie	Ogólny element
Atrybuty	Nie dotyczy
Dokumentacja	Wybieranie protokołu komunikacyjnego
Kroki	Zabezpieczanie protokołów HTTP/AMQP lub MQTT przy użyciu protokołu SSL/TLS.

Udostępnij za pośrednictwem

Ramka zabezpieczeń: Zabezpieczenia komunikacji | Czynniki

Bezpieczna komunikacja 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

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

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

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

Konfigurowanie certyfikatu TLS/SSL dla domeny niestandardowej w usłudze aplikacja systemu Azure

Wymuszanie całego ruchu do usługi aplikacja systemu Azure za pośrednictwem połączenia HTTPS

Przykład

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

Upewnij się, że szyfrowanie połączeń z programem SQL Server i walidacja certyfikatu

Wymuszanie zaszyfrowanej komunikacji z serwerem SQL

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

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

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

Implementowanie przypinania certyfikatu

Przykład

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

WCF: ustaw poziom ochrony zabezpieczeń komunikatów na Wartość EncryptAndSign

Przykład

Przykład

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

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

Przykład

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

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

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

Opinia

Dodatkowe zasoby