Dela via

Säkerhetsram: Kommunikationssäkerhet | Mitigations

Produkt/tjänst Artikel
Azure Event Hub
Dynamics CRM
Azure Data Factory
Identitetsserver
Webbapplikation
Databas
Azure Storage
Mobil klient
WCF
Webb-API
Azure Cache for Redis
IoT-fältgateway
IoT Cloud Gateway

Säker kommunikation till Händelsehubb med SSL/TLS

Titel Detaljer
Komponent Azure Event Hub
SDL-fasen Skapa
Tillämpliga tekniker Allmän
Attribut Inte tillgänglig
Referenser Översikt över autentisering och säkerhetsmodell för Event Hubs
Instruktioner Skydda AMQP- eller HTTP-anslutningar till Händelsehubb med SSL/TLS

Kontrollera tjänstkontobehörigheter och kontrollera att anpassade tjänster eller ASP.NET sidor respekterar CRM:s säkerhet

Titel Detaljer
Komponent Dynamics CRM
SDL-fasen Skapa
Tillämpliga tekniker Allmän
Attribut Inte tillgänglig
Referenser Inte tillgänglig
Instruktioner Kontrollera tjänstkontobehörigheter och kontrollera att anpassade tjänster eller ASP.NET sidor respekterar CRM:s säkerhet

Använda datahanteringsgateway när du ansluter lokal SQL Server till Azure Data Factory

Titel Detaljer
Komponent Azure Data Factory
SDL-fasen Driftsättning
Tillämpliga tekniker Allmän
Attribut Länkade tjänsttyper – Azure och lokalt
Referenser Flytta data mellan lokal och Azure Data Factory
Instruktioner

Verktyget Data Management Gateway (DMG) krävs för att ansluta till datakällor som skyddas bakom corpnet eller en brandvägg.

  1. Att låsa datorn isolerar DMG-verktyget och förhindrar att program som inte fungerar skadar eller snokar på datakälldatorn. (T.ex. de senaste uppdateringarna måste installeras, aktivera minsta nödvändiga portar, kontrollerad kontoetablering, granskning aktiverat, diskkryptering aktiverat osv.)
  2. Data Gateway-nyckeln måste roteras med jämna mellanrum eller när lösenordet för DMG-tjänstkontot förnyas
  3. Dataöverföringar via Link Service måste krypteras

Kontrollera att all trafik till identitetsservern är över HTTPS-anslutningen

Titel Detaljer
Komponent Identitetsserver
SDL-fasen Driftsättning
Tillämpliga tekniker Allmän
Attribut Inte tillgänglig
Referenser Inte tillgänglig
Instruktioner Som standard kräver IdentityServer att alla inkommande anslutningar kommer via HTTPS. Det är absolut obligatoriskt att kommunikationen med IdentityServer endast sker via skyddade transporter. Det finns vissa distributionsscenarier som TLS-avlastning där det här kravet kan lösas. Mer information finns på sidan för distribution av identitetsserver i referenserna.

Verifiera X.509-certifikat som används för att autentisera SSL-, TLS- och DTLS-anslutningar

Titel Detaljer
Komponent Webbapplikation
SDL-fasen Skapa
Tillämpliga tekniker Allmän
Attribut Inte tillgänglig
Referenser Inte tillgänglig
Instruktioner

Program som använder SSL, TLS eller DTLS måste fullständigt verifiera X.509-certifikaten för de entiteter som de ansluter till. Detta omfattar verifiering av certifikaten för:

  • Domännamn
  • Giltighetsdatum (både start- och förfallodatum)
  • Återkallandestatus
  • Användning (till exempel serverautentisering för servrar, klientautentisering för klienter)
  • Förtroendekedja. Certifikat måste länkas till en rotcertifikatutfärdare (CA) som är betrodd av plattformen eller uttryckligen konfigurerad av administratören
  • Nyckellängden för certifikatets offentliga nyckel måste vara >2 048 bitar
  • Hash-algoritmen måste vara SHA256 och senare

Konfigurera TLS/SSL-certifikat för anpassad domän i Azure App Service

Titel Detaljer
Komponent Webbapplikation
SDL-fasen Skapa
Tillämpliga tekniker Allmän
Attribut MiljöTyp – Azure
Referenser Aktivera HTTPS för en app i Azure App Service
Instruktioner Som standard aktiverar Azure redan HTTPS för varje app med ett jokerteckencertifikat för domänen *.azurewebsites.net. Men precis som alla jokerteckendomäner är det inte lika säkert som att använda en anpassad domän med eget certifikat. Refer Vi rekommenderar att du aktiverar TLS för den anpassade domän som den distribuerade appen kommer att nås via

Tvinga all trafik till Azure App Service via HTTPS-anslutning

Titel Detaljer
Komponent Webbapplikation
SDL-fasen Skapa
Tillämpliga tekniker Allmän
Attribut MiljöTyp – Azure
Referenser Framtvinga HTTPS på Azure App Service
Instruktioner

Även om Azure redan aktiverar HTTPS för Azure-apptjänster med ett jokerteckencertifikat för domänen *.azurewebsites.net, tillämpas inte HTTPS. Besökare kan fortfarande komma åt appen med HJÄLP av HTTP, vilket kan äventyra appens säkerhet och därför måste HTTPS tillämpas explicit. ASP.NET MVC-program bör använda filtret RequireHttps som tvingar fram att en oskyddad HTTP-begäran skickas på nytt via HTTPS.

Alternativt kan modulen URL Rewrite, som ingår i Azure App Service, användas för att framtvinga HTTPS. Med modulen URL Rewrite kan utvecklare definiera regler som tillämpas på inkommande begäranden innan begäranden skickas till ditt program. Url-omskrivningsregler definieras i en web.config fil som lagras i programmets rot

Exempel

Följande exempel innehåller en grundläggande URL-omskrivningsregel som tvingar all inkommande trafik att använda HTTPS

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

Den här regeln fungerar genom att returnera en HTTP-statuskod på 301 (permanent omdirigering) när användaren begär en sida med HTTP. 301 omdirigerar begäran till samma URL som besökaren begärde, men ersätter HTTP-delen av begäran med HTTPS. Till exempel HTTP://contoso.com skulle omdirigeras till HTTPS://contoso.com.

Aktivera strikt HTTP-transportsäkerhet (HSTS)

Titel Detaljer
Komponent Webbapplikation
SDL-fasen Skapa
Tillämpliga tekniker Allmän
Attribut Inte tillgänglig
Referenser OWASP HTTP Strikt transportsäkerhet fuskark
Instruktioner

HTTP Strict Transport Security (HSTS) är en valbar säkerhetsförbättring som anges av ett webbprogram med hjälp av ett särskilt svarshuvud. När en webbläsare som stöds tar emot den här rubriken förhindrar webbläsaren att kommunikation skickas via HTTP till den angivna domänen och i stället skickar all kommunikation via HTTPS. Det förhindrar också HTTPS-klick via prompter i webbläsare.

För att implementera HSTS måste följande svarshuvud konfigureras för en webbplats globalt, antingen i kod eller i konfiguration. Strict-Transport-Security: max-age=300; includeSubDomains HSTS hanterar följande hot:

  • Användarens bokmärken eller manuellt skriver https://example.com och utsätts för en man-in-the-middle-attack: HSTS omdirigerar automatiskt HTTP-begäranden till HTTPS för måldomänen
  • Webbprogram som är avsett att vara enbart HTTPS innehåller oavsiktligt HTTP-länkar eller hanterar innehåll via HTTP: HSTS omdirigerar automatiskt HTTP-begäranden till HTTPS för måldomänen
  • En man-in-the-middle-angripare försöker fånga upp trafik från en offeranvändare med ett ogiltigt certifikat och hoppas att användaren accepterar det felaktiga certifikatet: HSTS tillåter inte att en användare åsidosätter det ogiltiga certifikatmeddelandet

Säkra kryptering av SQL Server-anslutningar och verifiering av certifikat

Titel Detaljer
Komponent Databas
SDL-fasen Skapa
Tillämpliga tekniker SQL Azure
Attribut SQL-version – V12
Referenser Metodtips för att skriva säkra anslutningssträngar för SQL Database
Instruktioner

All kommunikation mellan SQL Database och ett klientprogram krypteras alltid med hjälp av TLS (Transport Layer Security), som tidigare kallades Secure Sockets Layer (SSL). SQL Database stöder inte okrypterade anslutningar. Om du vill verifiera certifikat med programkod eller verktyg begär du uttryckligen en krypterad anslutning och litar inte på servercertifikaten. Om programkoden eller verktygen inte begär en krypterad anslutning får de fortfarande krypterade anslutningar

De kanske dock inte verifierar servercertifikaten och är därför mottagliga för "man i mitten"-attacker. Om du vill verifiera certifikat med ADO.NET programkod anger du Encrypt=True och TrustServerCertificate=False i databasanslutningssträngen. Om du vill verifiera certifikat via SQL Server Management Studio öppnar du dialogrutan Anslut till server. Klicka på Kryptera anslutning på fliken Anslutningsegenskaper

Tvinga fram krypterad kommunikation till SQL Server

Titel Detaljer
Komponent Databas
SDL-fasen Skapa
Tillämpliga tekniker OnPrem
Attribut SQL-version – MsSQL2016, SQL-version – MsSQL2012, SQL-version – MsSQL2014
Referenser Aktivera krypterade anslutningar till databasmotorn
Instruktioner Om du aktiverar TLS-kryptering ökar säkerheten för data som överförs mellan nätverk mellan instanser av SQL Server och program.

Se till att kommunikationen till Azure Storage sker via HTTPS

Titel Detaljer
Komponent Azure Storage
SDL-fasen Driftsättning
Tillämpliga tekniker Allmän
Attribut Inte tillgänglig
Referenser Azure Storage-Transport-Level kryptering – använda HTTPS
Instruktioner För att säkerställa säkerheten för Azure Storage-data under överföring använder du alltid HTTPS-protokollet när du anropar REST-API:erna eller får åtkomst till objekt i lagringen. Signaturer för delad åtkomst, som kan användas för att delegera åtkomst till Azure Storage-objekt, innehåller också ett alternativ för att ange att endast HTTPS-protokollet kan användas när signaturer för delad åtkomst används, vilket säkerställer att alla som skickar ut länkar med SAS-token använder rätt protokoll.

Verifiera MD5-hash efter nedladdning av blob om HTTPS inte kan aktiveras

Titel Detaljer
Komponent Azure Storage
SDL-fasen Skapa
Tillämpliga tekniker Allmän
Attribut StorageType – blob
Referenser Översikt över Windows Azure Blob MD5
Instruktioner

Windows Azure Blob Service tillhandahåller mekanismer för att säkerställa dataintegritet både i program- och transportlagren. Om du av någon anledning behöver använda HTTP i stället för HTTPS och arbetar med blockblobar kan du använda MD5-kontroll för att verifiera integriteten för de blobar som överförs

Detta hjälper till med skydd mot nätverks-/transportskiktsfel, men inte nödvändigtvis med mellanliggande attacker. Om du kan använda HTTPS, som ger säkerhet på transportnivå, är md5-kontrollen redundant och onödig.

Använd SMB 3.x-kompatibel klient för att säkerställa datakryptering under överföring till Azure-filresurser

Titel Detaljer
Komponent Mobil klient
SDL-fasen Skapa
Tillämpliga tekniker Allmän
Attribut StorageType – fil
Referenser Azure Files, Azure Files SMB-stöd för Windows-klienter
Instruktioner Azure Files stöder HTTPS när du använder REST-API:et, men används oftare som en SMB-filresurs som är kopplad till en virtuell dator. SMB 2.1 stöder inte kryptering, så anslutningar tillåts endast inom samma region i Azure. SMB 3.x stöder dock kryptering och kan användas med Windows Server 2012 R2, Windows 8, Windows 8.1 och Windows 10, vilket ger åtkomst mellan regioner och till och med åtkomst på skrivbordet.

Implementera certifikat fästning

Titel Detaljer
Komponent Azure Storage
SDL-fasen Skapa
Tillämpliga tekniker Generisk, Windows Phone
Attribut Inte tillgänglig
Referenser Certifikat och offentlig nyckelpinning
Instruktioner

Kodning av certifikat skyddar mot MITM-attacker (Man-In-The-Middle). Att fästa är processen att associera en värd med deras förväntade X509-certifikat eller offentliga nyckel. När ett certifikat eller en offentlig nyckel har känts eller setts för en värd associeras certifikatet eller den offentliga nyckeln eller "fästs" på värden.

När en angripare försöker utföra en MITM-attack mot TLS, kommer nyckeln från angriparens server under TLS-handskakningen att skilja sig från den nyckel som är kopplad till det fastställda certifikatet, och begäran kommer att ignoreras. Detta förhindrar MITM-attacker genom att certifikatbindning kan uppnås genom att implementera ServicePointManagers ServerCertificateValidationCallback delegat.

Exempel

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

Aktivera HTTPS – säker transportkanal

Titel Detaljer
Komponent WCF (Windows Communication Foundation)
SDL-fasen Skapa
Tillämpliga tekniker NET Framework 3
Attribut Inte tillgänglig
Referenser MSDN, Fortify Kingdom
Instruktioner Programkonfigurationen bör se till att HTTPS används för all åtkomst till känslig information.
  • FÖRKLARING: Om ett program hanterar känslig information och inte använder kryptering på meddelandenivå bör det endast tillåtas att kommunicera via en krypterad transportkanal.
  • REKOMMENDATIONER: Se till att HTTP-transporten är inaktiverad och aktivera HTTPS-transport i stället. Ersätt till exempel <httpTransport/> med <httpsTransport/>-taggen. Förlita dig inte på en nätverkskonfiguration (brandvägg) för att garantera att programmet bara kan nås via en säker kanal. Ur filosofisk synvinkel bör programmet inte vara beroende av nätverket för sin säkerhet.

Ur praktisk synvinkel följer de personer som ansvarar för att skydda nätverket inte alltid programmets säkerhetskrav när de utvecklas.

WCF: Ange skyddsnivå för meddelandesäkerhet till EncryptAndSign

Titel Detaljer
Komponent WCF (Windows Communication Foundation)
SDL-fasen Skapa
Tillämpliga tekniker .NET Framework 3
Attribut Inte tillgänglig
Referenser MSDN-
Instruktioner
  • FÖRKLARING: När skyddsnivån är inställd på "ingen" inaktiveras meddelandeskyddet. Konfidentialitet och integritet uppnås med lämplig inställningsnivå.
  • REKOMMENDATIONER:
    • when Mode=None – Inaktiverar meddelandeskydd
    • when Mode=Sign – Signerar men krypterar inte meddelandet, bör användas när dataintegriteten är viktig
    • when Mode=EncryptAndSign – Signerar och krypterar meddelandet

Överväg att stänga av kryptering och endast signera ditt meddelande när du bara behöver verifiera informationens integritet utan att behöva bry dig om konfidentialitet. Detta kan vara användbart för åtgärder eller tjänstkontrakt där du behöver verifiera den ursprungliga avsändaren men inga känsliga data överförs. När du minskar skyddsnivån bör du vara försiktig så att meddelandet inte innehåller några personuppgifter.

Exempel

Konfiguration av tjänsten och åtgärden för att endast signera meddelandet visas i följande exempel. Exempel på tjänstkontrakt ProtectionLevel.Sign: Följande är ett exempel på hur du använder ProtectionLevel.Sign på servicekontraktsnivå:

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

Exempel

Operation Contract Example of ProtectionLevel.Sign (for Granular Control): Följande är ett exempel på användning ProtectionLevel.Sign på OperationContract-nivå:

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

WCF: Använd ett konto med minst privilegier för att köra WCF-tjänsten

Titel Detaljer
Komponent WCF (Windows Communication Foundation)
SDL-fasen Skapa
Tillämpliga tekniker .NET Framework 3
Attribut Inte tillgänglig
Referenser MSDN-
Instruktioner
  • FÖRKLARING: Kör inte WCF-tjänster under administratörskonto eller konto med hög behörighet. i händelse av att tjänster komprometteras kommer det att leda till stor påverkan.
  • REKOMMENDATIONER: Använd ett konto med minst privilegier för att vara värd för WCF-tjänsten eftersom det minskar programmets attackyta och minskar risken för skador om du attackeras. Om tjänstkontot kräver ytterligare åtkomstbehörigheter för infrastrukturresurser som MSMQ, händelseloggen, prestandaräknare och filsystemet, bör lämpliga behörigheter ges till dessa resurser så att WCF-tjänsten kan köras korrekt.

Om din tjänst behöver åtkomst till specifika resurser för den ursprungliga anroparens räkning använder du personifiering och delegering för att överföra anroparens identitet för en nedströms auktoriseringskontroll. I ett utvecklingsscenario använder du det lokala nätverkstjänstkontot, som är ett särskilt inbyggt konto som har nedsatt behörighet. I ett produktionsscenario skapar du ett konto för den anpassade domäntjänsten med minst privilegier.

Tvinga all trafik till webb-API:er via HTTPS-anslutning

Titel Detaljer
Komponent Webb-API
SDL-fasen Skapa
Tillämpliga tekniker MVC5, MVC6
Attribut Inte tillgänglig
Referenser Framtvinga SSL i en webb-API-kontrollant
Instruktioner Om ett program har både en HTTPS-bindning och en HTTP-bindning kan klienter fortfarande använda HTTP för att komma åt webbplatsen. För att förhindra detta använder du ett åtgärdsfilter för att säkerställa att begäranden till skyddade API:er alltid finns över HTTPS.

Exempel

Följande kod visar ett autentiseringsfilter för webb-API:et som söker efter 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);
        }
    }
}

Lägg till det här filtret i alla webb-API-åtgärder som kräver TLS:

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

Se till att kommunikationen till Azure Cache for Redis sker via TLS

Titel Detaljer
Komponent Azure-cache för Redis
SDL-fasen Skapa
Tillämpliga tekniker Allmän
Attribut Inte tillgänglig
Referenser Stöd för Azure Redis TLS
Instruktioner Redis-servern stöder inte TLS direkt, men Azure Cache for Redis har det. Om du ansluter till Azure Cache for Redis och klienten stöder TLS, till exempel StackExchange.Redis, bör du använda TLS. Som standard är icke-TLS-port inaktiverad för nya Azure Cache for Redis-instanser. Se till att de säkra standardvärdena inte ändras om det inte finns ett beroende av TLS-stöd för Redis-klienter.

Observera att Redis är utformat för att nås av betrodda klienter i betrodda miljöer. Det innebär att det vanligtvis inte är en bra idé att exponera Redis-instansen direkt på Internet eller, i allmänhet, för en miljö där ej betrodda klienter direkt kan komma åt Redis TCP-porten eller UNIX-socketen.

Säker kommunikation mellan enheter och fältgatewayer

Titel Detaljer
Komponent IoT-gateway för fält
SDL-fasen Skapa
Tillämpliga tekniker Allmän
Attribut Inte tillgänglig
Referenser Inte tillgänglig
Instruktioner För IP-baserade enheter kan kommunikationsprotokollet vanligtvis kapslas in i en SSL/TLS-kanal för att skydda data under överföring. För andra protokoll som inte stöder SSL/TLS undersöker du om det finns säkra versioner av protokollet som ger säkerhet på transport- eller meddelandenivå.

Skydda kommunikation mellan enheter och Cloud Gateway med SSL/TLS

Titel Detaljer
Komponent IoT Cloud Gateway
SDL-fasen Skapa
Tillämpliga tekniker Allmän
Attribut Inte tillgänglig
Referenser Välj ditt kommunikationsprotokoll
Instruktioner Skydda HTTP/AMQP- eller MQTT-protokoll med SSL/TLS.