Používejte jenom schválené symetrické blokové šifry a délky klíčů.
Nadpis
Podrobnosti
Komponenta
Webová aplikace
Fáze SDL
Sestavení
Použitelné technologie
Obecné
Atributy
–
Reference
–
Kroky
Produkty musí používat pouze symetrické blokové šifry a přidružené délky klíčů, které byly výslovně 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é.
Pro zpětnou kompatibilitu se stávajícím kódem je přijatelné tříklíčové 3DES.
Produkty používající symetrické blokové šifry:
Pro nový kód se vyžaduje standard AES (Advanced Encryption Standard).
Třínásobný standard 3DES (Data Encryption Standard) se třemi klíči je pro zpětnou kompatibilitu v existujícím kódu povolený.
Všechny ostatní blokové šifry, včetně RC2, DES, 2 Key 3DES, DESX a Skipjack, mohou být použity pouze k dešifrování starých dat, a pokud se používají k šifrování, musí být nahrazeny.
Pro algoritmy šifrování symetrických bloků se vyžaduje minimální délka klíče 128 bitů. Jediný algoritmus blokového šifrování doporučený pro nový kód je AES (AES-128, AES-192 a AES-256 jsou přijatelné).
3DES se třemi klíči 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 z důvodu zpětné kompatibility a data by se měla znovu šifrovat pomocí doporučené blokové šifry.
Upozorňujeme, že všechny symetrické blokové šifry musí být použity se schváleným režimem šifrování, který vyžaduje použití vhodného inicializačního vektoru (IV). Vhodná hodnota IV je obvykle náhodné číslo a nikdy konstantní hodnota.
Použití starších nebo jinak neschválaných kryptografických algoritmů a menších délek klíčů ke čtení existujících dat (místo zápisu nových dat) může být povoleno po revizi kryptografické rady vaší organizace. Musíte však podat žádost o výjimku proti tomuto požadavku. Kromě toho v podnikových nasazeních by produkty měly zvážit upozornění správců, když se ke čtení dat použije 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é mít Zásady skupiny kontrolu nad používáním slabého kryptografického
Povolené algoritmy .NET pro agilitu spravovaného šifrování (v pořadí podle preferencí)
AesCng (kompatibilní se standardem FIPS)
AuthenticatedAesCng (kompatibilní se standardem FIPS)
AESCryptoServiceProvider (kompatibilní se standardem FIPS)
AESManaged (nekompatibilní se standardem FIPS)
Mějte na paměti, že žádný z těchto algoritmů nelze určit prostřednictvím SymmetricAlgorithm.Create metod nebo CryptoConfig.CreateFromName bez provedení změn machine.config souboru. Všimněte si také, že AES ve verzích rozhraní .NET starších než .NET 3.5 má název RijndaelManageda AesCng jsou >AuthenticatedAesCng k dispozici prostřednictvím CodePlexu a vyžadují CNG v základním operačním systému.
Použití schválených režimů blokových šifer a inicializačních vektorů pro symetrické šifry
Nadpis
Podrobnosti
Komponenta
Webová aplikace
Fáze SDL
Sestavení
Použitelné technologie
Obecné
Atributy
–
Reference
–
Kroky
Všechny symetrické blokové šifry se musí používat se schváleným režimem symetrického šifrování. Jedinými schválenými režimy jsou CBC a CTS. Je třeba se vyhnout zejména způsobu fungování elektronického adresáře (ECB). použití ECB vyžaduje kontrolu Kryptografické rady vaší organizace. Veškeré použití OFB, CFB, CTR, CCM a GCM nebo jakéhokoli jiného režimu šifrování musí zkontrolovat kryptografická rada vaší organizace. Opakované použití stejného inicializačního vektoru (IV) s blokovými šiframi v režimech šifer streamování, 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). Vhodné IV je kryptograficky silné, náhodné číslo a nikdy konstantní hodnota.
Použití schválených asymetrických algoritmů, délek klíčů a odsazení
Nadpis
Podrobnosti
Komponenta
Webová aplikace
Fáze SDL
Sestavení
Použitelné technologie
Obecné
Atributy
–
Reference
–
Kroky
Použití zakázaných kryptografických algoritmů představuje významné riziko pro zabezpečení produktů a je třeba se mu vyhnout. Produkty musí používat pouze kryptografické algoritmy a přidružené délky klíčů a odsazení, které byly výslovně schváleny kryptografickou tabulí vaší organizace.
RSA- se může použít pro šifrování, výměnu klíčů a podpis. Šifrování RSA musí používat pouze režimy odsazení OAEP nebo RSA-KEM. Stávající kód může používat režim odsazení PKCS #1 v1.5 pouze kvůli kompatibilitě. Použití odsazení s hodnotou null je explicitně zakázáno. Pro >nový kód se vyžaduje 2048 bitů. Stávající kód může podporovat klíče < 2048 bitů pouze pro zpětnou kompatibilitu po kontrole Kryptografickým panelem vaší organizace. Klíče < 1024 bitů lze použít pouze k dešifrování nebo ověřování starých dat, a pokud se používají pro operace šifrování nebo podepisování, musí být nahrazeny.
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, mohou být použity pouze po kontrole s kryptografickou tabulí vaší organizace.
ECDH- lze použít pouze pro výměnu klíčů. Pro nový kód se vyžaduje ECDH s >=256bitovými klíči. Výměna klíčů založená na ECDH musí používat jednu ze tří křivek schválených podle NIST (P-256, P-384 nebo P521). Křivky, které byly důkladně analyzovány, mohou být použity pouze po kontrole s kryptografickou tabulí vaší organizace.
DSA - může být přijatelné po kontrole a schválení kryptografické rady vaší organizace. Obraťte se na svého poradce pro zabezpečení a naplánujte kontrolu crypto boardu ve vaší organizaci. Pokud je vaše použití DSA schválené, mějte na paměti, že budete muset zakázat použití klíčů kratších než 2048 bitů. CNG od Windows 8 podporuje 2048bitové a větší délky klíčů.
Diffie-Hellman- se dá použít jenom pro správu klíče relace. Délka >klíče = 2048 bitů je vyžadována pro nový kód. Stávající kód může podporovat délku < klíčů 2048 bitů pouze kvůli zpětné kompatibilitě po kontrole kryptografickým panelem vaší organizace. Klíče < 1024 bitů nelze použít.
Použití schválených generátorů náhodných čísel
Nadpis
Podrobnosti
Komponenta
Webová aplikace
Fáze SDL
Sestavení
Použitelné technologie
Obecné
Atributy
–
Reference
–
Kroky
Produkty musí používat schválené generátory náhodných čísel. Pseudonáhodné funkce, jako je náhčíslo funkce modulu runtime jazyka C, třída System.Random rozhraní .NET Framework nebo systémové funkce jako GetTickCount, proto se v takovém kódu nesmí nikdy používat. Použití algoritmu generátoru náhodných čísel (DUAL_EC_DRBG) s dvojitou eliptickou křivkou je zakázáno.
CNG- BCryptGenRandom(použití příznaku BCRYPT_USE_SYSTEM_PREFERRED_RNG doporučeno, pokud se volající nespustí v jakémkoli prostředí 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 random, size_t count, uint8_t *bytes )
Apple OS X (<10.7) – K načtení náhodných čísel použijte /dev/random
Java (včetně kódu Google Android Java) – třída java.security.SecureRandom. Upozorňujeme, že pro Android 4.3 (Jelly Bean) musí vývojáři postupovat podle doporučeného alternativního řešení pro Android a aktualizovat své aplikace tak, aby explicitně inicializovaly PRNG pomocí entropie z /dev/urandom nebo /dev/random.
Nepoužívejte šifry symetrických datových proudů.
Nadpis
Podrobnosti
Komponenta
Webová aplikace
Fáze SDL
Sestavení
Použitelné technologie
Obecné
Atributy
–
Reference
–
Kroky
Nesmí se používat symetrické šifry datových proudů, například RC4. Místo symetrických šifer streamu by produkty měly používat blokovou šifru, konkrétně AES s délkou klíče nejméně 128 bitů.
Použití schválených hashovacích algoritmů MAC/HMAC/keyed
Nadpis
Podrobnosti
Komponenta
Webová aplikace
Fáze SDL
Sestavení
Použitelné technologie
Obecné
Atributy
–
Reference
–
Kroky
Produkty musí používat pouze schválené kódy MAC (Message Authentication Code) nebo HMAC (hash-based message authentication code).
Ověřovací kód zprávy (MAC) je informace připojená ke zprávě, která příjemci umožňuje ověřit pravost odesílatele i integritu zprávy pomocí tajného klíče. Použití mac založeného na hodnotě hash (HMAC) nebo mac založeného na šifrách bloku je přípustné, pokud jsou také schváleny všechny podkladové hash nebo symetrické šifrovací algoritmy; V současné době to zahrnuje funkce HMAC-SHA2 (HMAC-SHA256, HMAC-SHA384 a HMAC-SHA512) a blokové řadiče mac založené na šifrování založené na CMAC/OMAC1 a OMAC2 (ty 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 z tohoto postupu a projít kryptografickou kontrolou vaší organizace. Zkrácení HMAC na méně než 128 bitů není povoleno. Použití zákaznických metod k hashovat klíč a data není schváleno a před použitím musí projít kontrolou kryptografických tabulí vaší organizace.
Používejte jenom schválené kryptografické hashovací funkce.
Nadpis
Podrobnosti
Komponenta
Webová aplikace
Fáze SDL
Sestavení
Použitelné technologie
Obecné
Atributy
–
Reference
–
Kroky
Produkty musí používat řadu hashovacích algoritmů SHA-2 (SHA256, SHA384 a SHA512). Pokud je potřeba kratší hodnota hash, například 128bitová délka výstupu, aby se vešla do datové struktury navržené s ohledem na kratší hodnotu hash MD5, mohou produktové týmy zkrátit jednu 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ší.
Povolené hashovací algoritmy .NET pro agilitu spravovaných kryptografických dat (v pořadí podle priority):
SHA512Cng (kompatibilní s FIPS)
SHA384Cng (kompatibilní s FIPS)
SHA256Cng (kompatibilní s FIPS)
SHA512Managed (nekompatibilní se standardem FIPS) (jako název algoritmu použijte SHA512 ve voláních HashAlgorithm.Create nebo CryptoConfig.CreateFromName)
SHA384Managed (nekompatibilní se standardem FIPS) (použijte SHA384 jako název algoritmu ve volání hashAlgorithm.Create nebo CryptoConfig.CreateFromName)
SHA256Managed (nekompatibilní se standardem FIPS) (jako název algoritmu použijte SHA256 ve voláních HashAlgorithm.Create nebo CryptoConfig.CreateFromName)
SHA512CryptoServiceProvider (kompatibilní s FIPS)
SHA256CryptoServiceProvider (kompatibilní s FIPS)
SHA384CryptoServiceProvider (kompatibilní s FIPS)
Použití silných šifrovacích algoritmů k šifrování dat v databázi
Šifrovací algoritmy definují transformace dat, které neautorizovanými uživateli nelze snadno vrátit zpět. 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, 128 bitů 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é.
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 riskantní. Aby se zabránilo neoprávněné manipulaci s balíčky SSIS, měly by se používat digitální podpisy. Aby byla zajištěna důvěrnost balíčků během ukládání nebo přenosu, musí být balíčky SSIS šifrované.
Přidání digitálního podpisu do kritických zabezpečitelných databází
V případech, kdy je nutné ověřit integritu kritické databáze zabezpečitelné, by se měly použít digitální podpisy. Zabezpečitelné položky databáze, jako je uložená procedura, funkce, sestavení nebo trigger, 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 (ISV) poskytl podporu softwaru dodanému jednomu ze svých zákazníků. Před poskytnutím podpory chce výrobce softwaru zajistit, aby databáze, která je v softwaru zabezpečitelná, nebyla manipulována omylem nebo úmyslným pokusem. Pokud je zabezpečitelné digitálně podepsané, může výrobce softwaru ověřit svůj digitální podpis a ověřit jeho integritu.
Použití EKM SQL Serveru k ochraně šifrovacích klíčů
SQL Server Extensible Key Management umožňuje, aby se šifrovací klíče, které chrání databázové soubory, ukládaly na zařízení, jako je čipová karta, zařízení USB 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 jenom uživatel databáze v externím modulu EKM/HSM.
Použití funkce AlwaysEncrypted, pokud by se šifrovací klíče neměly odhalit databázovému stroji
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í v USA), uložená v Azure SQL Database nebo SQL Server databázích. 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). V důsledku toho 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
Nadpis
Podrobnosti
Komponenta
Zařízení IoT
Fáze SDL
Sestavení
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
Symetrické privátní klíče nebo certifikáty bezpečně v hardwarově chráněném úložišti, jako jsou čipy TPM nebo čipy Smart Card. Windows 10 IoT Core podporuje uživatele čipu TPM a je možné použít několik kompatibilních čipů TPM: diskrétní čip TPM (dTPM). Doporučuje se používat firmware nebo diskrétní čip TPM. Softwarový čip TPM by se měl používat pouze pro účely vývoje a testování. Jakmile je čip TPM k dispozici a zřídí se v něm klíče, měl by se kód, který token generuje, zapisovat bez pevného 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 je uložen v čipu TPM ve slotu 0. Zařízení TPM vygeneruje krátkodobý token SAS, který se pak použije pro připojení k IoT Hub.
Vygenerujte náhodný symetrický klíč s dostatečnou délkou, aby ověřování IoT Hub
Nadpis
Podrobnosti
Komponenta
Brána IoT Cloud
Fáze SDL
Sestavení
Použitelné technologie
Obecné
Atributy
Volba brány – Azure IoT Hub
Reference
–
Kroky
IoT Hub obsahuje registr identit zařízení a při zřizování zařízení automaticky vygeneruje náhodný symetrický klíč. Doporučujeme použít tuto funkci služby Azure IoT Hub Identity Registry k vygenerování klíče používaného k ověřování. 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čujeme vytvořit náhodný symetrický klíč nebo alespoň 256 bitů.
Ujistěte se, že jsou zavedeny zásady správy zařízení, které vyžadují použití KÓDU PIN a umožňují vzdálené vymazání dat.
Nadpis
Podrobnosti
Komponenta
Dynamics CRM Mobile Client
Fáze SDL
Nasazení
Použitelné technologie
Obecné
Atributy
–
Reference
–
Kroky
Ujistěte se, že jsou zavedeny zásady správy zařízení, které vyžadují použití KÓDU PIN a umožňují vzdálené vymazání dat.
Ujistěte se, že jsou zavedeny zásady správy zařízení, které vyžadují PIN kód, heslo nebo automatický zámek a šifrují všechna data (např. BitLocker).
Nadpis
Podrobnosti
Komponenta
Dynamics CRM Outlook Client
Fáze SDL
Sestavení
Použitelné technologie
Obecné
Atributy
–
Reference
–
Kroky
Ujistěte se, že jsou zavedeny zásady správy zařízení, které vyžadují PIN kód, heslo nebo automatický zámek a šifrují všechna data (např. BitLocker).
Ujistěte se, že se podpisové klíče při použití serveru identit přemístí.
Při použití serveru identit se ujistěte, že se podpisové klíče přemístí. 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 na serveru identity používají kryptograficky silné ID klienta a tajný klíč klienta.
Nadpis
Podrobnosti
Komponenta
Server identit
Fáze SDL
Sestavení
Použitelné technologie
Obecné
Atributy
–
Reference
–
Kroky
Ujistěte se, že se na serveru identit používá kryptograficky silné ID klienta a tajný klíč klienta. Při generování ID klienta a tajného klíče byste měli použít následující pokyny:
Vygenerování náhodného identifikátoru GUID jako ID klienta
Vygenerování kryptograficky náhodného 256bitového klíče jako tajného kódu
Připravujeme: V průběhu roku 2024 budeme postupně vyřazovat problémy z GitHub coby mechanismus zpětné vazby pro obsah a nahrazovat ho novým systémem zpětné vazby. Další informace naleznete v tématu: https://aka.ms/ContentUserFeedback.