Megosztás a következőn keresztül:

Biztonsági keret: Kommunikációs biztonság | Enyhítése

  • Cikk
Termék/szolgáltatás Cikk
Azure Event Hub
Dynamics CRM
Azure Data Factory
Identitáskiszolgáló
Webalkalmazás
Adatbázis
Azure Storage
Mobilügyfél
WCF
Webes API
Azure Cache for Redis
IoT-mezőátjáró
IoT Cloud Gateway

Biztonságos kommunikáció az Event Hubtal SSL/TLS használatával

Cím Részletek
Komponens Azure Event Hub
SDL-fázis Build
Alkalmazható technológiák Általános
Attribútumok N/A
Hivatkozások Az Event Hubs-hitelesítés és a biztonsági modell áttekintése
Lépések AMQP- vagy HTTP-kapcsolatok védelme az Event Hubhoz SSL/TLS használatával

Ellenőrizze a szolgáltatásfiók jogosultságait, és ellenőrizze, hogy az egyéni szolgáltatások vagy ASP.NET lapok tiszteletben tartják-e a CRM biztonságát

Cím Részletek
Komponens Dynamics CRM
SDL-fázis Build
Alkalmazható technológiák Általános
Attribútumok N/A
Hivatkozások N/A
Lépések Ellenőrizze a szolgáltatásfiók jogosultságait, és ellenőrizze, hogy az egyéni szolgáltatások vagy ASP.NET lapok tiszteletben tartják-e a CRM biztonságát

Adatkezelési átjáró használata a helyszíni SQL Server és az Azure Data Factory összekapcsolása során

Cím Részletek
Komponens Azure Data Factory
SDL-fázis Üzembe helyezés
Alkalmazható technológiák Általános
Attribútumok Társított szolgáltatástípusok – Azure és helyszíni
Hivatkozások Adatok áthelyezése a helyszíni és az Azure Data Factory között
Lépések

A adatkezelés Átjáró (DMG) eszköz szükséges a corpnet vagy tűzfal mögött védett adatforrásokhoz való csatlakozáshoz.

  1. A gép zárolása elkülöníti a DMG eszközt, és megakadályozza, hogy a hibás programok kárt okozzanak vagy szaglást okozzanak az adatforrás-gépen. (Például a legújabb frissítéseket telepíteni kell, engedélyezni kell a minimálisan szükséges portokat, ellenőrzött fiókok kiépítését, naplózást engedélyezve, lemeztitkosítás engedélyezve stb.)
  2. A Data Gateway-kulcsot gyakran vagy a DMG szolgáltatásfiók jelszavának megújulásakor kell elforgatni
  3. A Link Szolgáltatáson keresztüli adatátvitelnek titkosítva kell lennie

Győződjön meg arról, hogy az Identity Server felé történő összes forgalom HTTPS-kapcsolaton keresztül van

Cím Részletek
Komponens Identitáskiszolgáló
SDL-fázis Üzembe helyezés
Alkalmazható technológiák Általános
Attribútumok N/A
Hivatkozások IdentityServer3 – Kulcsok, aláírások és titkosítás, IdentityServer3 – Üzembe helyezés
Lépések Alapértelmezés szerint az IdentityServer megköveteli, hogy az összes bejövő kapcsolat HTTPS-en keresztül jöjjön létre. Teljesen kötelező, hogy az IdentityServerrel való kommunikáció csak biztonságos átviteleken keresztül legyen végrehajtva. Vannak olyan üzembehelyezési forgatókönyvek, mint például a TLS kiszervezése, ahol ez a követelmény enyhíthető. További információkért tekintse meg az Identity Server üzembehelyezési oldalát a hivatkozások között.

Ssl-, TLS- és DTLS-kapcsolatok hitelesítéséhez használt X.509-tanúsítványok ellenőrzése

Cím Részletek
Komponens Webalkalmazás
SDL-fázis Build
Alkalmazható technológiák Általános
Attribútumok N/A
Hivatkozások N/A
Lépések

Az SSL-t, TLS-t vagy DTLS-t használó alkalmazásoknak teljes mértékben ellenőrizniük kell a hozzájuk csatlakozó entitások X.509-tanúsítványait. Ez magában foglalja a következő tanúsítványok ellenőrzését:

  • Tartománynév
  • Érvényességi dátumok (kezdő és lejárati dátumok)
  • Visszavonás állapota
  • Használat (például kiszolgálók kiszolgálói hitelesítése, ügyfelek ügyfélhitelesítése)
  • Megbízhatósági lánc. A tanúsítványoknak egy legfelső szintű hitelesítésszolgáltatóhoz (CA) kell láncolnia, amelyet a platform megbízhatónak vagy a rendszergazda explicit módon konfigurál
  • A tanúsítvány nyilvános kulcsának kulcshosszának 2048 bitnek kell lennie >
  • A kivonatolási algoritmusnak SHA256-os vagy újabbnak kell lennie

TLS/SSL-tanúsítvány konfigurálása egyéni tartományhoz a Azure-alkalmazás Szolgáltatásban

Cím Részletek
Komponens Webalkalmazás
SDL-fázis Build
Alkalmazható technológiák Általános
Attribútumok EnvironmentType – Azure
Hivatkozások HTTPS engedélyezése egy alkalmazáshoz a Azure-alkalmazás Szolgáltatásban
Lépések Alapértelmezés szerint az Azure már engedélyezi a HTTPS-t minden olyan alkalmazáshoz, amely helyettesítő tanúsítvánnyal rendelkezik a *.azurewebsites.net tartományhoz. Azonban, mint minden helyettesítő tartomány, ez sem olyan biztonságos, mint egy egyéni tartomány használata saját tanúsítvánnyal Hivatkozik. Javasoljuk, hogy engedélyezze a TLS-t ahhoz az egyéni tartományhoz, amelyen keresztül az üzembe helyezett alkalmazás elérhető lesz

Az összes forgalom kényszerítése a szolgáltatás Azure-alkalmazás HTTPS-kapcsolaton keresztüli használatára

Cím Részletek
Komponens Webalkalmazás
SDL-fázis Build
Alkalmazható technológiák Általános
Attribútumok EnvironmentType – Azure
Hivatkozások HTTPS kényszerítése Azure-alkalmazás szolgáltatásban
Lépések

Bár az Azure már engedélyezi a HTTPS-t az Azure-appszolgáltatásokhoz a *.azurewebsites.net tartomány helyettesítő tanúsítványával, nem kényszeríti a HTTPS-t. A látogatók továbbra is HTTP használatával érhetik el az alkalmazást, ami veszélyeztetheti az alkalmazás biztonságát, ezért a HTTPS-t explicit módon kell kikényszeríteni. ASP.NET MVC-alkalmazásoknak a RequireHttps szűrőt kell használniuk, amely egy nem biztonságos HTTP-kérést kényszerít a HTTPS-en keresztül történő újraküldésre.

Másik lehetőségként a Azure-alkalmazás szolgáltatás részét képező URL-átírási modul használható a HTTPS kényszerítésére. Az URL-átírási modul lehetővé teszi a fejlesztők számára, hogy olyan szabályokat határozzanak meg, amelyek a bejövő kérelmekre vonatkoznak, mielőtt a kéréseket átadják az alkalmazásnak. Az URL-átírási szabályok az alkalmazás gyökerében tárolt web.config fájlban vannak definiálva

Example

Az alábbi példa egy egyszerű URL-átírási szabályt tartalmaz, amely az összes bejövő forgalmat HTTPS használatára kényszeríti

<?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>

Ez a szabály úgy működik, hogy egy 301-alapú HTTP-állapotkódot (állandó átirányítást) ad vissza, amikor a felhasználó HTTP-t használó lapot kér. A 301 a kérést a látogató által kért URL-címre irányítja át, de a kérelem HTTP-részét HTTPS-ra cseréli. Például HTTP://contoso.com a rendszer átirányítja a következőre HTTPS://contoso.com: .

A HTTP szigorú átviteli biztonságának (HSTS) engedélyezése

Cím Részletek
Komponens Webalkalmazás
SDL-fázis Build
Alkalmazható technológiák Általános
Attribútumok N/A
Hivatkozások OWASP HTTP Strict Transport Security Cheat Sheet
Lépések

A HTTP Strict Transport Security (HSTS) egy olyan, a webalkalmazás által meghatározott, egy speciális válaszfejléc használatával megadott biztonsági fejlesztés. Ha egy támogatott böngésző megkapja ezt a fejlécet, a böngésző megakadályozza a http-en keresztüli kommunikációt a megadott tartományba, és ehelyett az összes kommunikációt HTTPS-en keresztül küldi el. Emellett megakadályozza a HTTPS-kattintást a böngészőkben megjelenő parancssorokban.

A HSTS implementálásához a következő válaszfejlécet globálisan kell konfigurálni egy webhelyhez kódban vagy konfigurációban. Szigorú-Transport-Security: max-age=300; az includeSubDomains HSTS a következő fenyegetéseket kezeli:

  • A felhasználói könyvjelzők vagy manuálisan típusok https://example.com , és egy középen belüli támadóra van kitéve: A HSTS automatikusan átirányítja a HTTP-kéréseket a céltartomány HTTPS-be
  • A kizárólag HTTPS-nek szánt webalkalmazás véletlenül HTTP-hivatkozásokat tartalmaz, vagy HTTP-n keresztül szolgálja ki a tartalmat: A HSTS automatikusan átirányítja a HTTP-kérelmeket a céltartomány HTTPS-be
  • A középső támadó egy érvénytelen tanúsítványt használó áldozatfelhasználó forgalmát próbálja elfogni, és reméli, hogy a felhasználó elfogadja a hibás tanúsítványt: A HSTS nem engedélyezi a felhasználónak az érvénytelen tanúsítványüzenet felülbírálását

Az SQL Server kapcsolattitkosításának és tanúsítványérvényesítésének biztosítása

Cím Részletek
Komponens Database
SDL-fázis Build
Alkalmazható technológiák SQL Azure
Attribútumok SQL-verzió – V12
Hivatkozások Ajánlott eljárások az SQL Database biztonságos Csatlakozás ion-sztringjeinek írásához
Lépések

Az SQL Database és az ügyfélalkalmazás közötti összes kommunikáció a Transport Layer Security (TLS) használatával van titkosítva, amely korábban Ssl néven ismert. Az SQL Database nem támogatja a titkosítatlan kapcsolatokat. A tanúsítványok alkalmazáskóddal vagy eszközökkel való érvényesítéséhez explicit módon kérjen titkosított kapcsolatot, és ne bízzon meg a kiszolgálótanúsítványokban. Ha az alkalmazás kódja vagy eszközei nem kérnek titkosított kapcsolatot, akkor is titkosított kapcsolatokat kapnak

Előfordulhat azonban, hogy nem ellenőrzik a kiszolgálótanúsítványokat, ezért "középen lévő ember" támadásokra lesznek érzékenyek. A tanúsítványok ADO.NET alkalmazáskóddal való érvényesítéséhez állítsa be Encrypt=True és TrustServerCertificate=False az adatbázisban kapcsolati sztring. A tanúsítványok SQL Server Management Studióval történő érvényesítéséhez nyissa meg a Csatlakozás a Kiszolgálóhoz párbeszédpanelt. Kattintson a Kapcsolat titkosítása elemre a Csatlakozás ion Properties (Tulajdonságok) lapon

Titkosított kommunikáció kényszerítve az SQL Serverrel

Cím Részletek
Komponens Database
SDL-fázis Build
Alkalmazható technológiák OnPrem
Attribútumok SQL-verzió – MsSQL2016, SQL-verzió – MsSQL2012, SQL-verzió – MsSQL2014
Hivatkozások Az adatbázismotorhoz titkosított kapcsolattal való csatlakozás engedélyezése
Lépések A TLS-titkosítás engedélyezése növeli az SQL Server példányai és az alkalmazások közötti hálózatokon keresztül továbbított adatok biztonságát.

Győződjön meg arról, hogy az Azure Storage-ral való kommunikáció HTTPS-en keresztül történik

Cím Részletek
Komponens Azure Storage
SDL-fázis Üzembe helyezés
Alkalmazható technológiák Általános
Attribútumok N/A
Hivatkozások Azure Storage transport-level Encryption – HTTPS használatával
Lépések Az Azure Storage-adatok átvitel közbeni biztonságának biztosítása érdekében mindig használja a HTTPS protokollt a REST API-k meghívásakor vagy a tárolóban lévő objektumok elérésekor. A közös hozzáférésű jogosultságkódok, amelyek az Azure Storage-objektumokhoz való hozzáférés delegálásához használhatók, megadható, hogy csak a HTTPS protokoll használható közös hozzáférésű jogosultságkódok használatakor, biztosítva, hogy bárki, aki SAS-jogkivonatokkal küld hivatkozásokat, a megfelelő protokollt használja.

MD5 kivonat ellenőrzése a blob letöltése után, ha a HTTPS nem engedélyezhető

Cím Részletek
Komponens Azure Storage
SDL-fázis Build
Alkalmazható technológiák Általános
Attribútumok StorageType – Blob
Hivatkozások A Windows Azure Blob MD5 áttekintése
Lépések

A Windows Azure Blob service olyan mechanizmusokat biztosít, amely biztosítja az adatok integritását mind az alkalmazás, mind az átviteli rétegek esetében. Ha bármilyen okból HTTP-t kell használnia a HTTPS helyett, és blokkblobokkal dolgozik, az MD5-ellenőrzéssel ellenőrizheti az átvitt blobok integritását

Ez segít a hálózati/átviteli réteg hibáival szembeni védelemben, de nem feltétlenül közvetítő támadásoknál. Ha az átviteli szintű biztonságot biztosító HTTPS-t használhatja, akkor az MD5-ellenőrzés használata redundáns és szükségtelen.

Az SMB 3.x-kompatibilis ügyfél használata az Azure-fájlmegosztásokra való átvitel közbeni adattitkosítás biztosításához

Cím Részletek
Komponens Mobilügyfél
SDL-fázis Build
Alkalmazható technológiák Általános
Attribútumok StorageType – Fájl
Hivatkozások Azure Files, Azure Files SMB-támogatás Windows-ügyfelek számára
Lépések Az Azure Files támogatja a HTTPS-t a REST API használatakor, de gyakrabban használják virtuális géphez csatolt SMB-fájlmegosztásként. Az SMB 2.1 nem támogatja a titkosítást, ezért a kapcsolatok csak ugyanabban a régióban engedélyezettek az Azure-ban. Az SMB 3.x azonban támogatja a titkosítást, és a Windows Server 2012 R2, a Windows 8, a Windows 8.1 és a Windows 10 rendszereken is használható, lehetővé téve a régiók közötti hozzáférést, és akár az asztali verzióhoz való hozzáférést is.

Tanúsítvány-rögzítés implementálása

Cím Részletek
Komponens Azure Storage
SDL-fázis Build
Alkalmazható technológiák Általános, Windows Phone-telefon
Attribútumok N/A
Hivatkozások Tanúsítvány- és nyilvánoskulcs-rögzítés
Lépések

A tanúsítványrögzítés védelmet nyújt a középen belüli (MITM) támadások ellen. A rögzítés a gazdagépnek a várt X509-tanúsítvánnyal vagy nyilvános kulccsal való társításának folyamata. Miután egy gazdagépen ismert vagy látható egy tanúsítvány vagy nyilvános kulcs, a tanúsítvány vagy a nyilvános kulcs a gazdagéphez lesz társítva vagy rögzítve.

Így amikor egy támadó megpróbál TLS MITM-támadást végrehajtani, a TLS-kézfogás során a támadó kiszolgálójának kulcsa eltér a rögzített tanúsítvány kulcsától, és a kérés el lesz vetve, így a MITM-tanúsítvány rögzítésének megakadályozása a ServicePointManager delegáltjának ServerCertificateValidationCallback implementálásával érhető el.

Example

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();
        }
    }
}

HTTPS engedélyezése – Biztonságos átviteli csatorna

Cím Részletek
Komponens WCF
SDL-fázis Build
Alkalmazható technológiák NET-keretrendszer 3
Attribútumok N/A
Hivatkozások MSDN, Fortify Kingdom
Lépések Az alkalmazáskonfigurációnak biztosítania kell, hogy a HTTPS minden bizalmas információhoz való hozzáféréshez használható legyen.
  • MAGYARÁZAT: Ha egy alkalmazás bizalmas információkat kezel, és nem használ üzenetszintű titkosítást, akkor csak titkosított átviteli csatornán keresztül kommunikálhat.
  • JAVASLATOK: Győződjön meg arról, hogy a HTTP-átvitel le van tiltva, és ehelyett engedélyezze a HTTPS-átvitelt. Cserélje le például a <httpTransport/> címkét <httpsTransport/> . Ne támaszkodjon hálózati konfigurációra (tűzfalra), hogy az alkalmazás csak biztonságos csatornán keresztül legyen elérhető. Filozófiai szempontból az alkalmazás nem függhet a hálózattól a biztonság szempontjából.

Gyakorlati szempontból a hálózat védelméért felelős személyek nem mindig követik az alkalmazás biztonsági követelményeit a fejlődésük során.

WCF: Az Üzenetbiztonság védelmi szintjének beállítása a EncryptAndSign értékre

Cím Részletek
Komponens WCF
SDL-fázis Build
Alkalmazható technológiák .NET-keretrendszer 3
Attribútumok N/A
Hivatkozások MSDN
Lépések
  • MAGYARÁZAT: Ha a védelmi szint "nincs" értékre van állítva, az letiltja az üzenetvédelmet. A bizalmasság és az integritás megfelelő beállítási szinttel érhető el.
  • AJÁNLÁSOK:
    • when Mode=None – Letiltja az üzenetvédelmet
    • mikor Mode=Sign – Jelek, de nem titkosítja az üzenetet; akkor kell használni, ha az adatintegritás fontos
    • when Mode=EncryptAndSign – Az üzenet aláírása és titkosítása

Fontolja meg a titkosítás kikapcsolását, és csak akkor írja alá az üzenetet, ha csak az információk integritását kell ellenőriznie a bizalmassági szempontok nélkül. Ez olyan műveletekhez vagy szolgáltatási szerződésekhez lehet hasznos, amelyekben ellenőriznie kell az eredeti feladót, de bizalmas adatok nem kerülnek továbbításra. A védelmi szint csökkentésekor ügyeljen arra, hogy az üzenet ne tartalmazzon személyes adatokat.

Example

Az alábbi példákban látható, hogy a szolgáltatás és a művelet csak az üzenet aláírására van konfigurálva. Példa szolgáltatási szerződésre ProtectionLevel.Sign: Az alábbi példa a ProtectionLevel.Sign szolgáltatásszerződés szintjén való használatára mutat be példát:

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

Example

Példa műveleti szerződésre ProtectionLevel.Sign (részletes vezérlő esetén): Az alábbiakban az OperationContract szintjén történő használatra ProtectionLevel.Sign mutatunk példát:

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

WCF: A WCF-szolgáltatás futtatásához használjon egy legkevésbé kiemelt fiókot

Cím Részletek
Komponens WCF
SDL-fázis Build
Alkalmazható technológiák .NET-keretrendszer 3
Attribútumok N/A
Hivatkozások MSDN
Lépések
  • MAGYARÁZAT: Ne futtasson WCF-szolgáltatásokat rendszergazdai vagy magas jogosultságú fiókban. ha a szolgáltatások biztonsága sérül, az nagy hatással lesz rá.
  • JAVASLATOK: Használjon egy legkevésbé kiemelt fiókot a WCF-szolgáltatás üzemeltetéséhez, mert az csökkenti az alkalmazás támadási felületét, és csökkenti a potenciális károkat, ha megtámadják. Ha a szolgáltatásfiók további hozzáférési jogosultságokat igényel az infrastruktúra-erőforrásokhoz, például az MSMQ-hoz, az eseménynaplóhoz, a teljesítményszámlálókhoz és a fájlrendszerhez, megfelelő engedélyeket kell adni ezeknek az erőforrásoknak, hogy a WCF szolgáltatás sikeresen fusson.

Ha a szolgáltatásnak bizonyos erőforrásokhoz kell hozzáférnie az eredeti hívó nevében, a megszemélyesítés és a delegálás használatával áramolhatja a hívó identitását egy alsóbb rétegbeli engedélyezési ellenőrzéshez. Fejlesztési forgatókönyv esetén használja a helyi hálózati szolgáltatásfiókot, amely egy speciális beépített fiók, amely csökkentett jogosultságokkal rendelkezik. Éles környezetben hozzon létre egy minimális jogosultságú egyéni tartományi szolgáltatásfiókot.

A webes API-k felé történő forgalom kényszerítése HTTPS-kapcsolaton keresztül

Cím Részletek
Komponens Webes API
SDL-fázis Build
Alkalmazható technológiák MVC5, MVC6
Attribútumok N/A
Hivatkozások SSL kényszerítése webes API-vezérlőben
Lépések Ha egy alkalmazás HTTPS- és HTTP-kötéssel is rendelkezik, az ügyfelek továbbra is HTTP-t használhatnak a webhely eléréséhez. Ennek megakadályozása érdekében használjon műveletszűrőt annak biztosítására, hogy a védett API-kra irányuló kérelmek mindig HTTPS-en keresztül legyenek.

Example

Az alábbi kód egy TLS-t ellenőrző webes API-hitelesítési szűrőt mutat be:

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);
        }
    }
}

Adja hozzá ezt a szűrőt a TLS-t igénylő webes API-műveletekhez:

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

Győződjön meg arról, hogy az Azure Cache for Redis felé irányuló kommunikáció TLS-en keresztül történik

Cím Részletek
Komponens Azure Cache for Redis
SDL-fázis Build
Alkalmazható technológiák Általános
Attribútumok N/A
Hivatkozások Az Azure Redis TLS támogatása
Lépések A Redis-kiszolgáló nem támogatja a TLS-t, de az Azure Cache for Redis igen. Ha az Azure Cache for Redishez csatlakozik, és az ügyfél támogatja a TLS-t (például StackExchange.Redis), akkor a TLS-t kell használnia. Alapértelmezés szerint a nem TLS-port le van tiltva az új Azure Cache for Redis-példányok esetében. Győződjön meg arról, hogy a biztonságos alapértelmezett értékek csak akkor változnak, ha a Redis-ügyfelek TLS-támogatásának függősége van.

Vegye figyelembe, hogy a Redist megbízható környezetekben lévő megbízható ügyfelek számára tervezték. Ez azt jelenti, hogy általában nem jó ötlet a Redis-példányt közvetlenül az interneten vagy általában olyan környezetben elérhetővé tenni, ahol a nem megbízható ügyfelek közvetlenül elérhetik a Redis TCP-portot vagy a UNIX-szoftvercsatornát.

Eszközök és mezők közötti átjáró közötti kommunikáció biztonságossá tétele

Cím Részletek
Komponens IoT-mezőátjáró
SDL-fázis Build
Alkalmazható technológiák Általános
Attribútumok N/A
Hivatkozások N/A
Lépések AZ IP-alapú eszközök esetében a kommunikációs protokoll általában egy SSL-/TLS-csatornába ágyazható az átvitel közbeni adatok védelme érdekében. Az SSL-t/TLS-t nem támogató egyéb protokollok esetében vizsgálja meg, hogy a protokollnak vannak-e olyan biztonságos verziói, amelyek biztonságot nyújtanak az átviteli vagy üzenetrétegben.

Eszközök és felhőátjárók közötti kommunikáció biztonságossá tétele SSL/TLS használatával

Cím Részletek
Komponens IoT Cloud Gateway
SDL-fázis Build
Alkalmazható technológiák Általános
Attribútumok N/A
Hivatkozások A kommunikációs protokoll kiválasztása
Lépések HTTP/AMQP vagy MQTT protokollok biztonságossá tételét SSL/TLS használatával.