Dela via

Säkerhetsram: Kommunikationssäkerhet | Mitigations

  • Artikel
Produkt/tjänst Artikel
Azure Event Hubs
Dynamics CRM
Azure Data Factory
Identitetsserver
Webbprogram
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

Title Details
Komponent Azure Event Hub
SDL-fas Skapa
Tillämpliga tekniker Allmän
Attribut Inte tillgängligt
Referenser Översikt över Event Hubs-autentisering och säkerhetsmodell
Steg 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

Title Details
Komponent Dynamics CRM
SDL-fas Skapa
Tillämpliga tekniker Allmän
Attribut Inte tillgängligt
Referenser Inte tillgängligt
Steg 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

Title Details
Komponent Azure Data Factory
SDL-fas Distribution
Tillämpliga tekniker Allmän
Attribut Länkade tjänsttyper – Azure och lokalt
Referenser Flytta data mellan lokal och Azure Data Factory
Steg

Verktyget Datahantering 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

Title Details
Komponent Identitetsserver
SDL-fas Distribution
Tillämpliga tekniker Allmän
Attribut Inte tillgängligt
Referenser IdentityServer3 – Nycklar, signaturer och kryptografi, IdentityServer3 – distribution
Steg 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

Title Details
Komponent Webbprogram
SDL-fas Skapa
Tillämpliga tekniker Allmän
Attribut Inte tillgängligt
Referenser Inte tillgängligt
Steg

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

Title Details
Komponent Webbprogram
SDL-fas Skapa
Tillämpliga tekniker Allmän
Attribut EnvironmentType – Azure
Referenser Aktivera HTTPS för en app i Azure App Service
Steg 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. 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

Title Details
Komponent Webbprogram
SDL-fas Skapa
Tillämpliga tekniker Allmän
Attribut EnvironmentType – Azure
Referenser Framtvinga HTTPS på Azure App Service
Steg

Ä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 ska 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)

Title Details
Komponent Webbprogram
SDL-fas Skapa
Tillämpliga tekniker Allmän
Attribut Inte tillgängligt
Referenser OWASP HTTP Strikt transportsäkerhet fuskark
Steg

HTTP Strict Transport Security (HSTS) är en 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. Strikt transportsäkerhet: max-age=300; includeSubDomains HSTS hanterar följande hot:

  • Användarbokmärken eller manuellt typer https://example.com och är föremål för en man-in-the-middle-angripare: 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

Se till att SQL Server-anslutningskryptering och certifikatverifiering

Title Details
Komponent Databas
SDL-fas Skapa
Tillämpliga tekniker SQL Azure
Attribut SQL-version – V12
Referenser Metodtips för att skriva säkra Anslut ionssträngar för SQL Database
Steg

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 databasen anslutningssträng. Om du vill verifiera certifikat via SQL Server Management Studio öppnar du dialogrutan Anslut till server. Klicka på Kryptera anslutning på fliken egenskaper för Anslut ion

Tvinga krypterad kommunikation till SQL Server

Title Details
Komponent Databas
SDL-fas Skapa
Tillämpliga tekniker OnPrem
Attribut SQL-version – MsSQL2016, SQL-version – MsSQL2012, SQL-version – MsSQL2014
Referenser Aktivera krypterade anslutningar till databasmotorn
Steg 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

Title Details
Komponent Azure Storage
SDL-fas Distribution
Tillämpliga tekniker Allmän
Attribut Inte tillgängligt
Referenser Kryptering på transportnivå i Azure Storage – använda HTTPS
Steg 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

Title Details
Komponent Azure Storage
SDL-fas Skapa
Tillämpliga tekniker Allmän
Attribut StorageType – blob
Referenser Översikt över Windows Azure Blob MD5
Steg

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

Title Details
Komponent Mobil klient
SDL-fas Skapa
Tillämpliga tekniker Allmän
Attribut StorageType – fil
Referenser Azure Files, Azure Files SMB-stöd för Windows-klienter
Steg 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

Title Details
Komponent Azure Storage
SDL-fas Skapa
Tillämpliga tekniker Generic, Windows Telefon
Attribut Inte tillgängligt
Referenser Fäst certifikat och offentlig nyckel
Steg

Certifikatstiftning 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 TLS MITM-attack kommer nyckeln från angriparens server under TLS-handskakning att skilja sig från nyckeln för det fästa certifikatet och begäran ignoreras, vilket förhindrar att MITM-certifikatet fästs genom att implementera ServicePointManagers ServerCertificateValidationCallback ombud.

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

Title Details
Komponent WCF
SDL-fas Skapa
Tillämpliga tekniker NET Framework 3
Attribut Inte tillgängligt
Referenser MSDN, Fortify Kingdom
Steg 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 med <httpsTransport/> taggen<httpTransport/>. 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

Title Details
Komponent WCF
SDL-fas Skapa
Tillämpliga tekniker .NET Framework 3
Attribut Inte tillgängligt
Referenser MSDN
Steg
  • 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

Title Details
Komponent WCF
SDL-fas Skapa
Tillämpliga tekniker .NET Framework 3
Attribut Inte tillgängligt
Referenser MSDN
Steg
  • 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 flöda anroparens identitet för en underordnad 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

Title Details
Komponent Webb-API
SDL-fas Skapa
Tillämpliga tekniker MVC5, MVC6
Attribut Inte tillgängligt
Referenser Framtvinga SSL i en webb-API-kontrollant
Steg 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

Title Details
Komponent Azure Cache for Redis
SDL-fas Skapa
Tillämpliga tekniker Allmän
Attribut Inte tillgängligt
Referenser Stöd för Azure Redis TLS
Steg 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

Title Details
Komponent IoT-fältgateway
SDL-fas Skapa
Tillämpliga tekniker Allmän
Attribut Inte tillgängligt
Referenser Inte tillgängligt
Steg 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

Title Details
Komponent IoT Cloud Gateway
SDL-fas Skapa
Tillämpliga tekniker Allmän
Attribut Inte tillgängligt
Referenser Välj ditt kommunikationsprotokoll
Steg Skydda HTTP/AMQP- eller MQTT-protokoll med SSL/TLS.