Dela via

Säkerhetsram: Kryptografi | Förmildrande omständighet

Produkt/tjänst Artikel
Webbapplikation
Databas
IoT-enhet
IoT Cloud Gateway
Mobil klient för Dynamics CRM
Dynamics CRM Outlook-klient
Identitetsserver

Använd endast godkända symmetriska blockchiffer och nyckellängder

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

Produkter får endast använda de symmetriska blockchiffer och tillhörande nyckellängder som uttryckligen har godkänts av Crypto Advisor i din organisation. Godkända symmetriska algoritmer på Microsoft innehåller följande blockchiffer:

  • För ny kod är AES-128, AES-192 och AES-256 acceptabla
  • För bakåtkompatibilitet med befintlig kod är 3DES med tre tangenter acceptabla
  • För produkter som använder symmetriska block chiffer:
    • AES (Advanced Encryption Standard) krävs för ny kod
    • 3DES (Three-Key Triple Data Encryption Standard) är tillåten i befintlig kod för bakåtkompatibilitet
    • Alla andra blockchiffer, inklusive RC2, DES, 2 Key 3DES, DESX och Skipjack, får endast användas för att dekryptera gamla data och måste bytas ut om de används för kryptering
  • För algoritmer för symmetrisk blockkryptering krävs en minsta nyckellängd på 128 bitar. Den enda blockkrypteringsalgoritmen som rekommenderas för ny kod är AES (AES-128, AES-192 och AES-256 är alla acceptabla)
  • 3DES med tre tangenter är för närvarande acceptabelt om det redan används i befintlig kod. övergång till AES rekommenderas. DES, DESX, RC2 och Skipjack anses inte längre vara säkra. Dessa algoritmer får endast användas för att dekryptera befintliga data för bakåtkompatibilitetens skull, och data bör krypteras på nytt med hjälp av ett rekommenderat blockchiffer

Observera att alla symmetriska blockchiffer måste användas med ett godkänt chifferläge, vilket kräver användning av en lämplig initieringsvektor (IV). En lämplig IV är vanligtvis ett slumptal och aldrig ett konstant värde

Användning av äldre eller på annat sätt icke godkända kryptoalgoritmer och mindre nyckellängder för att läsa befintliga data (i stället för att skriva nya data) kan tillåtas efter organisationens Crypto Board-granskning. Du måste dock ansöka om ett undantag från detta krav. I företagsdistributioner bör produkter dessutom överväga att varna administratörer när svag kryptering används för att läsa data. Sådana varningar bör vara förklarande och genomförbara. I vissa fall kan det vara lämpligt att låta grupprincip styra användningen av svag krypto

NET-algoritmer för hanterad krypto flexibilitet (i prioritetsordning)

  • AesCng (FIPS-kompatibel)
  • AuthenticatedAesCng (FIPS-kompatibel)
  • AESCryptoServiceProvider (FIPS-kompatibel)
  • AESManaged (icke-FIPS-kompatibel)

Observera att ingen av dessa algoritmer kan anges via SymmetricAlgorithm.Create metoderna eller CryptoConfig.CreateFromName utan att göra ändringar i machine.config-filen. Observera också att AES i versioner av .NET före .NET 3.5 heter RijndaelManagedoch AesCng och AuthenticatedAesCng är >tillgängliga via CodePlex och kräver CNG i det underliggande operativsystemet

Använda godkända blockchiffermoder och initieringsvektorer för symmetriska chiffer

Titel Detaljer
Komponent Webbapplikation
SDL-fasen Skapa
Tillämpliga tekniker Allmän
Attribut Inte tillgänglig
Referenser Inte tillgänglig
Instruktioner Alla symmetriska blockchiffer måste användas med ett godkänt symmetriskt chifferläge. De enda godkända lägena är CBC och CTS. I synnerhet bör man undvika att använda den elektroniska kodboken (ECB). Användning av ECB kräver att din organisation granskar Crypto Board. All användning av OFB, CFB, CTR, CCM och GCM eller något annat krypteringsläge måste granskas av din organisations Crypto Board. Återanvändning av samma initieringsvektor (IV) med blockchiffer i "strömmande chifferlägen", till exempel CTR, kan leda till att krypterade data avslöjas. Alla symmetriska blockchiffer måste också användas med en lämplig initieringsvektor (IV). Ett lämpligt IV är ett kryptografiskt starkt, slumpmässigt tal och aldrig ett konstant värde.

Använd godkända asymmetriska algoritmer, nyckellängder och utfyllnad

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

Användningen av förbjudna kryptografiska algoritmer medför en betydande risk för produktsäkerheten och måste undvikas. Produkter får endast använda de kryptografiska algoritmer och tillhörande nyckellängder och utfyllnad som uttryckligen har godkänts av organisationens Crypto Board.

  • RSA- kan användas för kryptering, nyckelutbyte och signatur. RSA-kryptering får endast använda utfyllnadslägena OAEP eller RSA-KEM. Befintlig kod kan endast använda PKCS #1 v1.5 utfyllnadsläge för kompatibilitet. Användning av null-utfyllnad är uttryckligen förbjuden. Nycklar >= 2048 bitar krävs för ny kod. Befintlig kod kan endast ha stöd för nycklar < på 2048 bitar för bakåtkompatibilitet efter en granskning av organisationens Crypto Board. Nycklar < 1024 bitar får endast användas för dekryptering/verifiering av gamla data och måste bytas ut om de används för kryptering eller signering
  • ECDSA - får endast användas för underskrift. ECDSA med >=256-bitars nycklar krävs för ny kod. ECDSA-baserade signaturer måste använda en av de tre NIST-godkända kurvorna (P-256, P-384 eller P521). Kurvor som har analyserats noggrant får endast användas efter en granskning med din organisations Crypto Board.
  • ECDH - får endast användas för nyckelutbyte. ECDH med >=256-bitars nycklar krävs för ny kod. ECDH-baserat nyckelutbyte måste använda en av de tre NIST-godkända kurvorna (P-256, P-384 eller P521). Kurvor som har analyserats noggrant får endast användas efter en granskning med din organisations Crypto Board.
  • DSA - kan vara acceptabelt efter granskning och godkännande från din organisations Crypto Board. Kontakta din säkerhetsrådgivare för att schemalägga din organisations Crypto Board-granskning. Om din användning av DSA är godkänd, observera att du måste förbjuda användning av nycklar som är mindre än 2048 bitar långa. CNG stöder 2048-bitars och större nyckellängder från och med Windows 8.
  • Diffie-Hellman – får endast användas för hantering av sessionsnycklar. Nyckellängd >= 2048 bitar krävs för ny kod. Befintlig kod kan endast ha stöd för nyckellängder < på 2048 bitar för bakåtkompatibilitet efter en granskning av organisationens Crypto Board. Nycklar < 1024 bitar får inte användas.

    Använd godkända slumptalsgeneratorer

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

    Produkter måste använda godkända slumptalsgeneratorer. Pseudoslumpmässiga funktioner som C-körningsfunktionen rand, .NET Framework-klassen System.Random eller systemfunktioner som GetTickCount får därför aldrig användas i sådan kod. Det är förbjudet att använda algoritmen för DUAL_EC_DRBG slumptalsgenerator (Dual elliptic Curve Random Number Generator)

    • CNG- BCryptGenRandom(användning av BCRYPT_USE_SYSTEM_PREFERRED_RNG-flaggan rekommenderas om inte anroparen kan köras på någon IRQL som är större än 0 [det vill säga PASSIVE_LEVEL])
    • CAPI- cryptGenRandom
    • Win32/64- RtlGenRandom (nya implementeringar bör använda BCryptGenRandom eller CryptGenRandom) * rand_s * SystemPrng (för kernelläge)
    • . – Herr talman, NET- RNGCryptoServiceProvider eller RNGCng
    • Windows Store-appar- Windows.Security.Cryptography.CryptographicBuffer.GenerateRandom eller . GenereraSlumptal
    • Apple OS X (10.7+)/iOS(2.0+)- int SecRandomCopyBytes (SecRandomRef random, size_t antal, uint8_t *bytes )
    • Apple OS X (<10.7) - Använd /dev/random för att hämta slumptal
    • Java (inklusive Google Android Java-kod) - java.security.SecureRandom klass. Observera att för Android 4.3 (Jelly Bean) måste utvecklare följa den rekommenderade Android-lösningen och uppdatera sina program för att uttryckligen initiera PRNG med entropi från /dev/urandom eller /dev/random

    Använd inte chiffer för symmetrisk ström

    Titel Detaljer
    Komponent Webbapplikation
    SDL-fasen Skapa
    Tillämpliga tekniker Allmän
    Attribut Inte tillgänglig
    Referenser Inte tillgänglig
    Instruktioner Symmetriska strömchiffer, till exempel RC4, får inte användas. I stället för symmetriska strömchiffer bör produkter använda ett blockchiffer, särskilt AES med en nyckellängd på minst 128 bitar.

    Använd godkända MAC/HMAC/nyckelade hash-algoritmer

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

    Produkter får endast använda MAC-algoritmer (Message Authentication Code) eller HMAC-algoritmer (Hash-based Message Authentication Code).

    En kod för meddelandeautentisering (MAC) är en information som är kopplad till ett meddelande som gör att mottagaren kan verifiera både avsändarens äkthet och meddelandets integritet med hjälp av en hemlig nyckel. Det är tillåtet att använda antingen en hashbaserad MAC (HMAC) eller blockchifferbaserad MAC så länge alla underliggande hash- eller symmetriska krypteringsalgoritmer också är godkända för användning. För närvarande inkluderar detta de HMAC-SHA2 funktionerna (HMAC-SHA256, HMAC-SHA384 och HMAC-SHA512) och CMAC/OMAC1- och OMAC2-blockchifferbaserade MAC:er (dessa är baserade på AES).

    Användning av HMAC-SHA1 kan vara tillåten för plattformskompatibilitet, men du kommer att behöva lämna in ett undantag från denna procedur och genomgå din organisations Crypto-granskning. Trunkering av HMAC:er till mindre än 128 bitar är inte tillåten. Att använda kundmetoder för att hasha en nyckel och data godkänns inte och måste genomgå organisationens Crypto Board-granskning innan den används.

    Använd endast godkända kryptografiska hashfunktioner

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

    Produkter måste använda SHA-2-familjen av hash-algoritmer (SHA256, SHA384 och SHA512). Om en kortare hash behövs, till exempel en 128-bitars utdatalängd för att passa en datastruktur som utformats med den kortare MD5-hashen i åtanke, kan produktteamen trunkera en av SHA2-hasharna (vanligtvis SHA256). Observera att SHA384 är en trunkerad version av SHA512. Trunkering av kryptografiska hashvärden av säkerhetsskäl till mindre än 128 bitar är inte tillåten. Ny kod får inte använda hashalgoritmerna MD2, MD4, MD5, SHA-0, SHA-1 eller RIPEMD. Hashkollisioner är beräkningsmässigt genomförbara för dessa algoritmer, vilket effektivt bryter dem.

    Tillåtna .NET hash-algoritmer för hanterad krypto flexibilitet (i prioritetsordning):

    • SHA512Cng (FIPS-kompatibel)
    • SHA384Cng (FIPS-kompatibel)
    • SHA256Cng (FIPS-kompatibel)
    • SHA512Managed (icke-FIPS-kompatibel) (använd SHA512 som algoritmnamn i anrop till HashAlgorithm.Create eller CryptoConfig.CreateFromName)
    • SHA384Managed (icke-FIPS-kompatibel) (använd SHA384 som algoritmnamn i anrop till HashAlgorithm.Create eller CryptoConfig.CreateFromName)
    • SHA256Managed (icke-FIPS-kompatibel) (använd SHA256 som algoritmnamn i anrop till HashAlgorithm.Create eller CryptoConfig.CreateFromName)
    • SHA512CryptoServiceProvider (FIPS-kompatibel)
    • SHA256CryptoServiceProvider (FIPS-kompatibel)
    • SHA384CryptoServiceProvider (FIPS-kompatibel)

    Använd starka krypteringsalgoritmer för att kryptera data i databasen

    Titel Detaljer
    Komponent Databas
    SDL-fasen Skapa
    Tillämpliga tekniker Allmän
    Attribut Inte tillgänglig
    Referenser Välja en krypteringsalgoritm
    Instruktioner Krypteringsalgoritmer definierar dataomvandlingar som inte enkelt kan ångras av obehöriga användare. SQL Server gör det möjligt för administratörer och utvecklare att välja mellan flera algoritmer, inklusive DES, Triple DES, TRIPLE_DES_3KEY, RC2, RC4, 128-bitars RC4, DESX, 128-bitars AES, 192-bitars AES och 256-bitars AES

    SSIS-paket ska vara krypterade och digitalt signerade

    Titel Detaljer
    Komponent Databas
    SDL-fasen Skapa
    Tillämpliga tekniker Allmän
    Attribut Inte tillgänglig
    Referenser Identifiera källan till paket med digitala signaturer, hot- och sårbarhetsreducering (integrationstjänster)
    Instruktioner Källan till ett paket är den person eller organisation som skapade paketet. Det kan vara riskabelt att köra ett paket från en okänd eller ej betrodd källa. För att förhindra obehörig manipulering av SSIS-paket bör digitala signaturer användas. För att säkerställa paketens konfidentialitet under lagring/transport måste SSIS-paket krypteras

    Lägg till digital signatur i kritiska databasskyddsbara objekt

    Titel Detaljer
    Komponent Databas
    SDL-fasen Skapa
    Tillämpliga tekniker Allmän
    Attribut Inte tillgänglig
    Referenser LÄGG TILL SIGNATUR (Transact-SQL)
    Instruktioner I de fall där integriteten hos en kritisk databas som kan skyddas måste verifieras bör digitala signaturer användas. Skyddsbara databaser, till exempel en lagrad procedur, funktion, sammansättning eller utlösare, kan signeras digitalt. Nedan följer ett exempel på när detta kan vara användbart: Låt oss säga att en ISV (Independent Software Vendor) har tillhandahållit support för en programvara som levererats till en av deras kunder. Innan ISV:en ger support vill den se till att en databas som kan skyddas i programvaran inte har manipulerats av misstag eller genom ett skadligt försök. Om den skyddsbara signaturen är digitalt signerad kan ISV:en verifiera dess digitala signatur och validera dess integritet.

    Använda SQL Server EKM för att skydda krypteringsnycklar

    Titel Detaljer
    Komponent Databas
    SDL-fasen Skapa
    Tillämpliga tekniker Allmän
    Attribut Inte tillgänglig
    Referenser SQL Server EKM (Extensible Key Management),hantering av utökningsbara nycklar med hjälp av Azure Key Vault (SQL Server)
    Instruktioner SQL Server Extensible Key Management gör att krypteringsnycklarna som skyddar databasfilerna kan lagras på en extern enhet, till exempel ett smartkort, en USB-enhet eller en EKM/HSM-modul. Detta möjliggör även dataskydd från databasadministratörer (förutom medlemmar i sysadmin-gruppen). Data kan krypteras med hjälp av krypteringsnycklar som endast databasanvändaren har åtkomst till på den externa EKM/HSM-modulen.

    Använd funktionen AlwaysEncrypted om krypteringsnycklar inte ska visas för databasmotorn

    Titel Detaljer
    Komponent Databas
    SDL-fasen Skapa
    Tillämpliga tekniker SQL Azure, OnPrem
    Attribut SQL-version – v12, msSQL2016
    Referenser Always Encrypted (databasmotor)
    Instruktioner Always Encrypted är en funktion som är utformad för att skydda känsliga data, till exempel kreditkortsnummer eller nationella/regionala identifieringsnummer (t.ex. amerikanska personnummer), som lagras i Azure SQL Database- eller SQL Server-databaser. Always Encrypted gör att klienter kan kryptera känsliga data i klientprogram och aldrig avslöja krypteringsnycklarna för databasmotorn (SQL Database eller SQL Server). Därför ger Always Encrypted en separation mellan de som äger data (och kan visa dem) och de som hanterar data (men inte bör ha någon åtkomst)

    Lagra kryptografiska nycklar säkert på IoT-enhet

    Titel Detaljer
    Komponent IoT-enhet
    SDL-fasen Skapa
    Tillämpliga tekniker Allmän
    Attribut Enhetsoperativsystem – Windows IoT Core, enhetsanslutning – SDK:er för Azure IoT-enheter
    Referenser TPM på Windows IoT Core, Konfigurera TPM på Windows IoT Core, Azure IoT Device SDK TPM
    Instruktioner Symmetriska eller privata certifikatnycklar på ett säkert sätt i en maskinvaruskyddad lagring som TPM- eller smartkortskretsar. Windows 10 IoT Core stöder användaren av en TPM och det finns flera kompatibla TPM:er som kan användas: Diskret TPM (dTPM). Vi rekommenderar att du använder en fast programvara eller en diskret TPM. En TPM för programvara bör endast användas i utvecklings- och testningssyfte. När en TPM är tillgänglig och nycklarna har etablerats i den ska koden som genererar token skrivas utan att hårdkoda känslig information i den.

    Exempel

    TpmDevice myDevice = new TpmDevice(0);
// Use logical device 0 on the TPM 
string hubUri = myDevice.GetHostName(); 
string deviceId = myDevice.GetDeviceId(); 
string sasToken = myDevice.GetSASToken(); 

var deviceClient = DeviceClient.Create( hubUri, AuthenticationMethodFactory. CreateAuthenticationWithToken(deviceId, sasToken), TransportType.Amqp);

    Som du kan se finns inte enhetens primärnyckel i koden. I stället lagras den i TPM:en på plats 0. TPM-enheten genererar en kortlivad SAS-token som sedan används för att ansluta till IoT Hub.

    Generera en slumpmässig symmetrisk nyckel med tillräcklig längd för autentisering till IoT Hub

    Titel Detaljer
    Komponent IoT Cloud Gateway
    SDL-fasen Skapa
    Tillämpliga tekniker Allmän
    Attribut Gatewayval – Azure IoT Hub
    Referenser Inte tillgänglig
    Instruktioner IoT Hub innehåller ett enhetsidentitetsregister och genererar automatiskt en slumpmässig symmetrisk nyckel när du etablerar en enhet. Vi rekommenderar att du använder den här funktionen i Azure IoT Hub Identity Registry för att generera nyckeln som används för autentisering. IoT Hub gör det också möjligt att ange en nyckel när enheten skapas. Om en nyckel genereras utanför IoT Hub under enhetsetableringen rekommenderar vi att du skapar en slumpmässig symmetrisk nyckel eller minst 256 bitar.

    Se till att det finns en princip för enhetshantering som kräver en PIN-kod för användning och tillåter fjärradering

    Titel Detaljer
    Komponent Mobil klient för Dynamics CRM
    SDL-fasen Driftsättning
    Tillämpliga tekniker Allmän
    Attribut Inte tillgänglig
    Referenser Inte tillgänglig
    Instruktioner Se till att det finns en princip för enhetshantering som kräver en PIN-kod för användning och tillåter fjärradering

    Se till att det finns en enhetshanteringspolicy som kräver en PIN-kod/lösenord/autolås och krypterar alla data (t.ex. BitLocker)

    Titel Detaljer
    Komponent Dynamics CRM Outlook-klient
    SDL-fasen Skapa
    Tillämpliga tekniker Allmän
    Attribut Inte tillgänglig
    Referenser Inte tillgänglig
    Instruktioner Se till att det finns en enhetshanteringspolicy som kräver en PIN-kod/lösenord/autolås och krypterar alla data (t.ex. BitLocker)

    Se till att signeringsnycklarna överförs när du använder Identity Server

    Titel Detaljer
    Komponent Identitetsserver
    SDL-fasen Driftsättning
    Tillämpliga tekniker Allmän
    Attribut Inte tillgänglig
    Referenser Inte tillgänglig
    Instruktioner Se till att signeringsnycklarna återställs när du använder Identity Server. Länken i referensavsnittet förklarar hur detta ska planeras utan att orsaka avbrott i program som förlitar sig på Identity Server.

    Se till att kryptografiskt starkt klient-ID, klienthemlighet används i Identity Server

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

    Se till att kryptografiskt starkt klient-ID, klienthemlighet används i Identity Server. Följande riktlinjer bör användas när du genererar ett klient-ID och en hemlighet:

    • Generera ett slumpmässigt GUID som klient-ID
    • Generera en kryptografiskt slumpmässig 256-bitars nyckel som hemlighet