Sdílet prostřednictvím


Bezpečnostní rámec: Kryptografie | Zmírnění

Produkt/služba Článek
Webová aplikace
Databáze
Zařízení IoT
Cloudová brána IoT
Mobilní klient Dynamics CRM
Klient aplikace Dynamics CRM Outlook
Server identit

Používejte pouze schválené symetrické blokové šifry a délky klíčů.

Titulek Podrobnosti
Komponenta Webová aplikace
Fáze SDL Stavět
Použitelné technologie Obecná
Atributy není k dispozici
Odkazy není k dispozici
Kroky

Produkty musí používat pouze ty symetrické blokové šifry a přidružené délky klíčů, které byly explicitně schváleny kryptografickým poradcem ve vaší organizaci. Schválené symetrické algoritmy v Microsoftu zahrnují následující blokové šifry:

  • Pro nový kód AES-128, AES-192 a AES-256 jsou přijatelné.
  • Kvůli zpětné kompatibilitě s existujícím kódem je přijatelné 3DES se třemi klíči.
  • Pro produkty používající symetrické blokové šifry:
    • Pro nový kód se vyžaduje Advanced Encryption Standard (AES).
    • Tříklíčový trojnásobný standard šifrování dat (3DES) je v existujícím kódu povolený kvůli zpětné kompatibilitě.
    • Všechny ostatní blokové šifry, včetně RC2, DES, 2 Key 3DES, DESX a Skipjack, se můžou používat jenom k dešifrování starých dat a musí být nahrazeny, pokud se používají k šifrování.
  • Pro šifrovací algoritmy symetrického bloku je vyžadována minimální délka klíče 128 bitů. Jediný blokový šifrovací algoritmus doporučený pro nový kód je AES (AES-128, AES-192 a AES-256 jsou všechny přijatelné).
  • Tříklíčový 3DES je v současné době přijatelný, pokud se již používá v existujícím kódu; doporučuje se přechod na AES. DES, DESX, RC2 a Skipjack se už nepovažují za bezpečné. Tyto algoritmy je možné použít pouze k dešifrování existujících dat kvůli zpětné kompatibilitě a data by se měla znovu zašifrovat pomocí doporučeného blokového šifrování.

Upozorňujeme, že všechny symetrické blokové šifry musí být použity se schváleným režimem šifry, který vyžaduje použití vhodného inicializačního vektoru (IV). Odpovídající IV je obvykle náhodné číslo a nikdy konstantní hodnota

Použití starších nebo jinak neschválené kryptografických algoritmů a menších délek klíčů ke čtení existujících dat (na rozdíl od zápisu nových dat) může být povoleno po kontrole crypto boardu vaší organizace. Musíte však podat výjimku proti tomuto požadavku. Navíc by produkty v podnikových nasazeních měly upozornit správce, když je při čtení dat použito slabé šifrování. Taková upozornění by měla být vysvětlující a použitelná. V některých případech může být vhodné, aby zásady skupiny řídily použití slabého šifrování.

Povolené algoritmy .NET pro spravovanou kryptografickou flexibilitu (v pořadí podle preferencí)

  • AesCng (kompatibilní se standardem FIPS)
  • AuthenticatedAesCng (kompatibilní se standardem FIPS)
  • AESCryptoServiceProvider (kompatibilní se standardem FIPS)
  • AESManaged (nevyhovující standardu FIPS)

Upozorňujeme, že žádný z těchto algoritmů nelze specifikovat prostřednictvím SymmetricAlgorithm.Create metod nebo CryptoConfig.CreateFromName metod bez provedení změn v souboru machine.config. Všimněte si také, že AES ve verzích .NET starších než .NET 3.5 má název RijndaelManageda AesCngAuthenticatedAesCng je >k dispozici prostřednictvím CodePlexu a vyžaduje CNG v podkladovém operačním systému.

Použití schválených režimů blokových šifer a inicializačních vektorů pro symetrické šifry

Titulek Podrobnosti
Komponenta Webová aplikace
Fáze SDL Stavět
Použitelné technologie Obecná
Atributy není k dispozici
Odkazy není k dispozici
Kroky Všechny symetrické blokové šifry musí být použity se schváleným režimem symetrické šifry. Jedinými schválenými režimy jsou CBC a CTS. Zejména by se měl vyhnout režimu elektronické knihy kódu (ECB); použití ECB vyžaduje revizi kryptografické komise vaší organizace. Veškeré využití OFB, CFB, CTR, CCM a GCM nebo jakéhokoli jiného režimu šifrování musí být zkontrolováno kryptografickou radou vaší organizace. Opětovné používání stejného inicializačního vektoru (IV) s blokovými šiframi v režimech streamovaných šifer, jako je CTR, může způsobit odhalení šifrovaných dat. Všechny symetrické blokové šifry musí být také použity s odpovídajícím inicializačním vektorem (IV). Správné IV je kryptograficky silné náhodné číslo, které nikdy není konstantní hodnotou.

Používejte schválené asymetrické algoritmy, délky klíčů a vyplňování.

Titulek Podrobnosti
Komponenta Webová aplikace
Fáze SDL Stavět
Použitelné technologie Obecná
Atributy není k dispozici
Odkazy není k dispozici
Kroky

Použití zakázaných kryptografických algoritmů představuje významné riziko pro zabezpečení produktů a musí se jim vyhnout. Produkty musí používat pouze ty kryptografické algoritmy a přidružené délky klíčů a vycpávání, které byly explicitně schváleny Radou pro kryptografii vaší organizace.

  • RSA- lze použít pro šifrování, výměnu klíčů a podpis. Šifrování RSA musí používat pouze režimy OAEP nebo RSA-KEM paddingu. Pro kompatibilitu může existující kód používat vycpávací režim PKCS #1 v1.5. Použití vyplňování nulami je explicitně zakázáno. Klíče >= 2048 bitů se vyžadují pro nový kód. Stávající kód může podporovat klíče < o délce 2048 bitů pouze kvůli zpětné kompatibilitě po přezkumu crypto výborem vaší organizace. Klíče < 1024 bitů lze použít pouze k dešifrování/ověřování starých dat a musí být nahrazeny, pokud se používají pro operace šifrování nebo podepisování.
  • ECDSA- lze použít pouze pro podpis. Pro nový kód se vyžaduje ECDSA s > = 256bitovými klíči. Podpisy založené na ECDSA musí používat jednu ze tří křivek schválených nist (P-256, P-384 nebo P521). Křivky, které byly důkladně analyzovány, se můžou použít až po kontrole v kryptografické tabuli vaší organizace.
  • ECDH- lze použít pouze pro výměnu klíčů. Pro nový kód je vyžadován ECDH s klíči >=256 bitů. Výměna klíčů založená na ECDH musí používat jednu ze tří křivek schválených pro NIST (P-256, P-384 nebo P521). Křivky, které byly důkladně analyzovány, se můžou použít až po kontrole v kryptografické tabuli vaší organizace.
  • DSA – může být přijatelné po přezkoumání a schválení od Kryptografické rady vaší organizace. Obraťte se na svého poradce pro zabezpečení a naplánujte kontrolu crypto boardu vaší organizace. Pokud je vaše použití DSA schválené, nezapomeňte, že budete muset zakázat použití klíčů o délce méně než 2048 bitů. CNG podporuje 2048bitové a větší délky klíčů jako Windows 8.
  • Diffie-Hellman- se dá použít jenom pro správu klíčů relací. Pro nový kód se vyžaduje délka >klíče = 2048 bitů. Stávající kód může podporovat délku klíče 2048 bitů < pouze kvůli zpětné kompatibilitě po kontrole crypto boardem vaší organizace. Klíče < 1024 bitových nelze použít.

    Použití schválených generátorů náhodných čísel

    Titulek Podrobnosti
    Komponenta Webová aplikace
    Fáze SDL Stavět
    Použitelné technologie Obecná
    Atributy není k dispozici
    Odkazy není k dispozici
    Kroky

    Produkty musí používat schválené generátory náhodných čísel. Pseudonáhodné funkce, jako je například funkce modulu runtime jazyka C, třída .NET Framework System.Random nebo systémové funkce, jako je GetTickCount, proto se v tomto kódu nikdy nepoužívají. Použití algoritmu generátoru náhodných čísel na základě dvojité eliptické křivky (DUAL_EC_DRBG) je zakázáno.

    • CNG- BCryptGenRandom(použití příznaku BCRYPT_USE_SYSTEM_PREFERRED_RNG je doporučeno, pokud volající nemusí běžet na jakékoli úrovni IRQL větší než 0 [to znamená PASSIVE_LEVEL])
    • CAPI – cryptGenRandom
    • Win32/64- RtlGenRandom (nové implementace by měly používat BCryptGenRandom nebo CryptGenRandom) * rand_s * SystemPrng (pro režim jádra)
    • . NET- RNGCryptoServiceProvider nebo RNGCng
    • Aplikace pro Windows Store – Windows.Security.Cryptography.CryptographicBuffer.GenerateRandom nebo . GenerateRandomNumber
    • Apple OS X (10.7+)/iOS(2.0+)- int SecRandomCopyBytes (SecRandomRef náhodný, počet size_t, uint8_t *bajtů)
    • Apple OS X (<10.7)- K načtení náhodných čísel použijte /dev/random
    • Java (včetně kódu Java pro Google Android) třída java.security.SecureRandom. Všimněte si, že pro Android 4.3 (Jelly Bean) musí vývojáři postupovat podle doporučeného řešení pro Android a aktualizovat své aplikace tak, aby explicitně inicializovali PRNG entropií z /dev/urandom nebo /dev/random.

    Nepoužívejte šifry symetrických datových proudů.

    Titulek Podrobnosti
    Komponenta Webová aplikace
    Fáze SDL Stavět
    Použitelné technologie Obecná
    Atributy není k dispozici
    Odkazy není k dispozici
    Kroky Symetrické šifry datových proudů, například RC4, se nesmí používat. Místo symetrických šifer datových proudů by produkty měly používat blokovou šifru, konkrétně AES s délkou klíče nejméně 128 bitů.

    Používejte schválené algoritmy MAC, HMAC a hash s klíčem.

    Titulek Podrobnosti
    Komponenta Webová aplikace
    Fáze SDL Stavět
    Použitelné technologie Obecná
    Atributy není k dispozici
    Odkazy není k dispozici
    Kroky

    Produkty musí používat pouze schválené ověřovací kódy zpráv (MAC) nebo algoritmy HMAC (hash-based message authentication code).

    Ověřovací kód zprávy (MAC) je část informací připojená ke zprávě, která umožňuje příjemci ověřit pravost odesílatele i integritu zprávy pomocí tajného klíče. Použití mac (HMAC) nebo blokového šifrování mac založeného na hodnotě hash je přípustné, pokud jsou pro použití schváleny také všechny základní algoritmy hash nebo symetrické šifrování; v současné době to zahrnuje funkce HMAC-SHA2 (HMAC-SHA256, HMAC-SHA384 a HMAC-SHA512) a řadiče MAC založené na blokech CMAC/OMAC1 a OMAC2 (jsou založené na AES).

    Použití HMAC-SHA1 může být přípustné z důvodu kompatibility platformy, ale budete muset podat výjimku pro tento postup a projít kryptografickou kontrolou vaší organizace. Zkrácení HMAC na méně než 128 bitů není povoleno. Použití metod zákazníka k hashování klíče a dat není schváleno a před použitím musí projít kontrolou kryptografických tabulí vaší organizace.

    Používejte pouze schválené kryptografické funkce hash.

    Titulek Podrobnosti
    Komponenta Webová aplikace
    Fáze SDL Stavět
    Použitelné technologie Obecná
    Atributy není k dispozici
    Odkazy není k dispozici
    Kroky

    Produkty musí používat řadu hash algoritmů SHA-2 (SHA256, SHA384 a SHA512). Pokud potřebujete kratší hodnotu hash, například 128bitovou výstupní délku, aby se přizpůsobila datové struktuře navržené s kratší hodnotou hash MD5, můžou produktové týmy zkrátit jeden z hodnot hash SHA2 (obvykle SHA256). Všimněte si, že SHA384 je zkrácená verze SHA512. Zkrácení kryptografických hodnot hash pro účely zabezpečení na méně než 128 bitů není povoleno. Nový kód nesmí používat hashovací algoritmy MD2, MD4, MD5, SHA-0, SHA-1 nebo RIPEMD. Kolize hodnot hash jsou pro tyto algoritmy výpočetně proveditelné, což je efektivně narušuje.

    Povolené hashovací algoritmy .NET pro spravovanou kryptografickou flexibilitu (v pořadí podle preference):

    • SHA512Cng (kompatibilní se standardem FIPS)
    • SHA384Cng (kompatibilní se standardem FIPS)
    • SHA256Cng (kompatibilní se standardem FIPS)
    • SHA512Managed (nekompatibilní se standardem FIPS) (použití SHA512 jako názvu algoritmu ve volání hashAlgorithm.Create nebo CryptoConfig.CreateFromName)
    • SHA384Managed (nekompatibilní se standardem FIPS) (použití SHA384 jako názvu algoritmu ve volání hashAlgorithm.Create nebo CryptoConfig.CreateFromName)
    • SHA256Managed (nekompatibilní se standardem FIPS) (použití SHA256 jako názvu algoritmu ve volání hashAlgorithm.Create nebo CryptoConfig.CreateFromName)
    • SHA512CryptoServiceProvider (kompatibilní se standardem FIPS)
    • SHA256CryptoServiceProvider (kompatibilní se standardem FIPS)
    • SHA384CryptoServiceProvider (kompatibilní se standardem FIPS)

    Použití silných šifrovacích algoritmů k šifrování dat v databázi

    Titulek Podrobnosti
    Komponenta Databáze
    Fáze SDL Stavět
    Použitelné technologie Obecná
    Atributy není k dispozici
    Odkazy Volba šifrovacího algoritmu
    Kroky Šifrovací algoritmy definují transformace dat, které nelze snadno převrátit neoprávněnými uživateli. SQL Server umožňuje správcům a vývojářům vybírat z několika algoritmů, včetně DES, Triple DES, TRIPLE_DES_3KEY, RC2, RC4, 128bitových RC4, DESX, 128bitových AES, 192bitových AES a 256bitových AES.

    Balíčky SSIS by měly být šifrované a digitálně podepsané.

    Titulek Podrobnosti
    Komponenta Databáze
    Fáze SDL Stavět
    Použitelné technologie Obecná
    Atributy není k dispozici
    Odkazy Identifikace zdroje balíčků pomocí digitálních podpisů, hrozeb a zmírnění ohrožení zabezpečení (Integrační služby)
    Kroky Zdrojem balíčku je jednotlivec nebo organizace, která balíček vytvořila. Spuštění balíčku z neznámého nebo nedůvěryhodného zdroje může být rizikové. Aby se zabránilo neoprávněné manipulaci s balíčky SSIS, měly by se používat digitální podpisy. Aby se zajistila důvěrnost balíčků během ukládání a přenosu, musí být balíčky SSIS zašifrované.

    Přidejte digitální podpis ke kritickým zabezpečovaným objektům databáze

    Titulek Podrobnosti
    Komponenta Databáze
    Fáze SDL Stavět
    Použitelné technologie Obecná
    Atributy není k dispozici
    Odkazy PŘIDAT PODPIS (Transact-SQL)
    Kroky V případech, kdy je potřeba ověřit integritu kritické databáze, by se měly používat digitální podpisy. Databázové zabezpečitelné objekty, jako je uložená procedura, funkce, sestavení nebo spoušť, mohou být digitálně podepsány. Níže je příklad, kdy to může být užitečné: Řekněme, že nezávislý výrobce softwaru (nezávislý dodavatel softwaru) poskytl podporu softwaru dodanému jednomu ze svých zákazníků. Před poskytnutím podpory by ISV chtěl zajistit, aby zabezpečitelná databáze v softwaru nebyla zmanipulována buď omylem, nebo zlým úmyslem. Pokud je chráněný objekt digitálně podepsaný, může ISV ověřit jeho digitální podpis a zajistit jeho integritu.

    Ochrana šifrovacích klíčů pomocí EKM SQL Serveru

    Titulek Podrobnosti
    Komponenta Databáze
    Fáze SDL Stavět
    Použitelné technologie Obecná
    Atributy není k dispozici
    Odkazy SQL Server Extensible Key Management (EKM) a rozšiřitelná správa klíčů pomocí služby Azure Key Vault (SQL Server)
    Kroky SQL Server Extensible Key Management umožňuje ukládání šifrovacích klíčů, které chrání databázové soubory, na externí zařízení, jako je čipová karta, USB zařízení nebo modul EKM/HSM. To také umožňuje ochranu dat před správci databáze (s výjimkou členů skupiny sysadmin). Data je možné šifrovat pomocí šifrovacích klíčů, ke kterým má přístup pouze uživatel databáze v externím modulu EKM/HSM.

    Pokud by se šifrovací klíče neměly odhalit databázovému stroji, použijte funkci AlwaysEncrypted.

    Titulek Podrobnosti
    Komponenta Databáze
    Fáze SDL Stavět
    Použitelné technologie SQL Azure, OnPrem
    Atributy Verze SQL – V12, MsSQL2016
    Odkazy Always Encrypted (Databázový mechanismus)
    Kroky Funkce Always Encrypted je funkce určená k ochraně citlivých dat, jako jsou čísla platebních karet nebo národní/regionální identifikační čísla (např. čísla sociálního pojištění USA), uložená v databázích Azure SQL Database nebo SQL Serveru. Funkce Always Encrypted umožňuje klientům šifrovat citlivá data v klientských aplikacích a nikdy neodhalovat šifrovací klíče databázovému stroji (SQL Database nebo SQL Server). Díky tomu funkce Always Encrypted poskytuje oddělení mezi těmi, kdo vlastní data (a mohou je zobrazit) a těmi, kdo data spravují (ale neměli by mít přístup).

    Bezpečné ukládání kryptografických klíčů na zařízení IoT

    Titulek Podrobnosti
    Komponenta Zařízení IoT
    Fáze SDL Stavět
    Použitelné technologie Obecná
    Atributy Operační systém zařízení – Windows IoT Core, připojení zařízení – Sady SDK pro zařízení Azure IoT
    Odkazy TPM ve Windows IoT Core, Nastavení TPM ve Windows IoT Core, Sada SDK TPM pro zařízení Azure IoT
    Kroky Symetrické nebo certifikátové privátní klíče bezpečně v hardwarovém chráněném úložišti, jako jsou čipy TPM nebo Čipové karty. Windows 10 IoT Core podporuje uživatele čipu TPM a existuje několik kompatibilních čipů TPM, které je možné použít: Diskrétní čip TPM (dTPM). Doporučujeme použít firmware nebo diskrétní čip TPM. Software TPM by se měl používat jenom pro účely vývoje a testování. Jakmile je čip TPM dostupný a klíče se v něm zřídí, kód, který generuje token, by se měl psát bez kódování citlivých informací.

    Příklad

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

    Jak je vidět, primární klíč zařízení není v kódu. Místo toho se uloží do čipu TPM ve slotu 0. Zařízení TPM vygeneruje krátkodobý token SAS, který se pak použije k připojení ke službě IoT Hub.

    Vygenerování náhodného symetrického klíče dostatečné délky pro ověřování ve službě IoT Hub

    Titulek Podrobnosti
    Komponenta Cloudová brána IoT
    Fáze SDL Stavět
    Použitelné technologie Obecná
    Atributy Volba brány – Azure IoT Hub
    Odkazy není k dispozici
    Kroky IoT Hub obsahuje registr identit zařízení a při zřizování zařízení automaticky generuje náhodný symetrický klíč. K vygenerování klíče používaného k ověřování se doporučuje použít tuto funkci registru identit služby Azure IoT Hub. IoT Hub také umožňuje zadat klíč při vytváření zařízení. Pokud se klíč generuje mimo IoT Hub během zřizování zařízení, doporučuje se vytvořit náhodný symetrický klíč nebo alespoň 256 bitů.

    Ujistěte se, že jsou zavedené zásady správy zařízení, které vyžadují pin kód a umožňují vzdálené vymazání.

    Titulek Podrobnosti
    Komponenta Mobilní klient Dynamics CRM
    Fáze SDL Nasazení
    Použitelné technologie Obecná
    Atributy není k dispozici
    Odkazy není k dispozici
    Kroky Ujistěte se, že jsou zavedené zásady správy zařízení, které vyžadují pin kód a umožňují vzdálené vymazání.

    Ujistěte se, že jsou zavedené zásady správy zařízení, které vyžadují PIN kód, heslo nebo automatické uzamčení a šifrují všechna data (např. BitLocker).

    Titulek Podrobnosti
    Komponenta Klient aplikace Dynamics CRM Outlook
    Fáze SDL Stavět
    Použitelné technologie Obecná
    Atributy není k dispozici
    Odkazy není k dispozici
    Kroky Ujistěte se, že jsou zavedené zásady správy zařízení, které vyžadují PIN kód, heslo nebo automatické uzamčení a šifrují všechna data (např. BitLocker).

    Ujistěte se, že při použití Serveru identit jsou podpisové klíče obnovovány.

    Titulek Podrobnosti
    Komponenta Server identit
    Fáze SDL Nasazení
    Použitelné technologie Obecná
    Atributy není k dispozici
    Odkazy není k dispozici
    Kroky Při použití Identity Serveru se ujistěte, že se podpisové klíče pravidelně obměňují. Odkaz v části Reference vysvětluje, jak by se to mělo naplánovat, aniž by to způsobilo výpadky aplikací závislých na serveru identit.

    Ujistěte se, že se kryptograficky silné ID klienta, tajný klíč klienta používá na serveru identit.

    Titulek Podrobnosti
    Komponenta Server identit
    Fáze SDL Stavět
    Použitelné technologie Obecná
    Atributy není k dispozici
    Odkazy není k dispozici
    Kroky

    Ujistěte se, že se kryptograficky silné ID klienta, tajný klíč klienta používá na serveru identit. Při generování ID klienta a tajného klíče by se měly použít následující pokyny:

    • Vygenerování náhodného identifikátoru GUID jako ID klienta
    • Vygenerování kryptografického náhodného 256bitového klíče jako tajného klíče