Microsoft SDL Şifreleme Öneriler

Makale
02/07/2024

Giriş

Bu belge, Microsoft platformlarında şifrelemeyi kullanmaya yönelik öneriler ve en iyi yöntemleri içerir. Buradaki içeriğin büyük bölümü, Microsoft'un Güvenlik Geliştirme Yaşam Döngüsü oluşturmak için kullanılan kendi iç güvenlik standartlarından alınmış veya toplanmıştır. Microsoft'un kendi ürün ve hizmetleri için gerektirdiği API'leri, algoritmaları, protokolleri ve anahtar uzunluklarını kullanacak şekilde ürün tasarlarken başvuru olarak kullanılması amaçlanmaktadır.

Windows dışı platformlardaki geliştiriciler de bu önerilerden yararlanabilir. API ve kitaplık adları farklı olsa da algoritma seçimi, anahtar uzunluğu ve veri koruması gibi en iyi yöntemler platformlar arasında benzerdir.

Güvenlik Protokolü, Algoritma ve Anahtar Uzunluğu Öneriler

SSL/TLS sürümleri

Ürün ve hizmetler SSL/TLS'nin şifreleme açısından güvenli sürümlerini kullanmalıdır:

TLS 1.2 etkinleştirilmelidir
Yalnızca geriye dönük uyumluluk için TLS 1.1 ve TLS 1.0 etkinleştirilmelidir
SSL 3 ve SSL 2 varsayılan olarak devre dışı bırakılmalıdır

Simetrik Blok Şifrelemeleri, Şifreleme Modları ve Başlatma Vektörleri

Şifrelemeleri Engelle

Simetrik blok şifrelemesi kullanan ürünler için:

Yeni kod için Gelişmiş Şifreleme Standardı (AES) önerilir.
Geriye dönük uyumluluk için mevcut kodda üç anahtarlı üçlü Veri Şifreleme Standardı (3DES) kullanılabilir.
RC2, DES, 2 Anahtarlı 3DES, DESX ve Skipjack gibi diğer tüm blok şifreleri yalnızca eski verilerin şifresini çözmek için kullanılmalıdır ve şifreleme için kullanıldığında değiştirilmelidir.

Simetrik blok şifreleme algoritmaları için en az 128 bit anahtar uzunluğu önerilir. Yeni kod için önerilen tek blok şifreleme algoritması AES'dir (AES-128, AES-192 ve AES-256' nın tümü kabul edilebilirdir, AES-192'nin bazı işlemcilerde iyileştirme eksikliği olduğuna dikkat edin). Mevcut kodda zaten kullanılıyorsa üç anahtarlı 3DES şu anda kabul edilebilir; AES'ye geçiş önerilir. DES, DESX, RC2 ve Skipjack artık güvenli olarak kabul edilmez. Bu algoritmalar yalnızca geriye dönük uyumluluk amacıyla mevcut verilerin şifresini çözmek için kullanılmalı ve veriler önerilen bir blok şifrelemesi kullanılarak yeniden şifrelenmelidir.

Şifreleme Modları

Simetrik algoritmalar, çoğu düz metin ve şifreleme metninin ardışık bloklarındaki şifreleme işlemlerini birbirine bağlayan çeşitli modlarda çalışabilir.

Simetrik blok şifrelemeleri aşağıdaki şifreleme modlarından biriyle kullanılmalıdır:

Şifreleme Blok Zincirleme (CBC)
Şifreleme Metni Çalma (CTS)
Şifreleme Metni Çalma ile XEX Tabanlı Tweaked-Codebook (XTS)

Aşağıda yer alanlar gibi diğer bazı şifreleme modlarında, bunların yanlış kullanılma olasılığını daha yüksek hale getiren uygulama tuzakları vardır. Özellikle Elektronik Kod Defteri (ECB) çalışma modundan kaçınılmalıdır. CTR gibi "akış şifreleri modlarında" blok şifreleri ile aynı başlatma vektörü (IV) yeniden kullanmak şifrelenmiş verilerin ortaya alınmasına neden olabilir. Aşağıdaki modlardan herhangi biri kullanılıyorsa ek güvenlik incelemesi önerilir:

Çıkış Geri Bildirimi (OFB)
Şifreleme Geri Bildirimi (CFB)
Sayaç (CTR)
CBC-MAC (CCM) ile sayaç
Galois/Sayaç Modu (GCM)
Yukarıdaki "önerilen" listede bulunmayan diğer her şey

Başlatma Vektörleri (IV)

Tüm simetrik blok şifreleri, başlatma vektöru olarak kriptografik olarak güçlü rastgele bir sayı ile de kullanılmalıdır. Başlatma vektörleri hiçbir zaman sabit bir değer olmamalıdır. Kriptografik olarak güçlü rastgele sayılar oluşturma önerileri için bkz. Rastgele Sayı Oluşturucuları.

Birden çok şifreleme işlemi gerçekleştirilirken başlatma vektörleri hiçbir zaman yeniden kullanılmamalıdır. Bu, özellikle Çıkış Geri Bildirimi (OFB) veya Sayaç (CTR) gibi akış şifreleme modlarını kullanırken şifrelenen veriler hakkında bilgi ortaya çıkarabileceği için.

Asimetrik Algoritmalar, Anahtar Uzunlukları ve Doldurma Modları

RSA

Şifreleme, anahtar değişimi ve imzalar için RSA kullanılmalıdır.
RSA şifrelemesi OAEP veya RSA-PSS doldurma modlarını kullanmalıdır. Mevcut kod yalnızca uyumluluk için PKCS #1 v1.5 doldurma modunu kullanmalıdır.
Null doldurma kullanılması önerilmez.
Anahtarlar >= 2048 bit önerilir

ECDSA

= 256 bit anahtarlı >ECDSA önerilir
ECDSA tabanlı imzalar NIST onaylı üç eğriden birini kullanmalıdır (P-256, P-384 veya P521).

ECDH

= 256 bit anahtarlı >ECDH önerilir
ECDH tabanlı anahtar değişimi, NIST onaylı üç eğriden (P-256, P-384 veya P521) birini kullanmalıdır.

Tamsayı Diffie-Hellman

Anahtar uzunluğu >= 2048 bit önerilir
Grup parametreleri iyi bilinen bir adlandırılmış grup olmalıdır (örn. RFC 7919) veya güvenilir bir taraf tarafından oluşturulmuş ve kullanımdan önce kimliği doğrulanmış olmalıdır

Anahtar Yaşam Süreleri

Tüm asimetrik anahtarların en fazla beş yıllık ömrü olmalıdır, önerilen bir yıllık ömür.
Tüm simetrik anahtarların maksimum üç yıllık ömrü olmalıdır; bir yıllık kullanım ömrü önerilir.
Sınırlı etkin kullanım ömrü elde etmek için bir mekanizma sağlamalı veya anahtarları değiştirme işleminiz olmalıdır. Etkin ömrü sona erdikten sonra, yeni veri üretmek için anahtar kullanılmamalıdır (örneğin, şifreleme veya imzalama için), ancak yine de verileri okumak için kullanılabilir (örneğin, şifre çözme veya doğrulama).

Rastgele Sayı Oluşturucular

Rastgelelik gerektiğinde tüm ürün ve hizmetler kriptografik olarak güvenli rastgele sayı oluşturucular kullanmalıdır.

CNG

BCryptGenRandom'ı BCRYPT_USE_SYSTEM_PREFERRED_RNG bayrağıyla kullanma

CAPI

Rastgele değerler oluşturmak için CryptGenRandom kullanın.

Win32/64

Eski kod, çekirdek modunda RtlGenRandom kullanabilir
Yeni kod BCryptGenRandom veya CryptGenRandom kullanmalıdır.
C işlevi Rand_s() de önerilir (Windows'ta CryptGenRandom'ı çağırır )
Rand_s(), Rand() için güvenli ve performanslı bir değiştirmedir. Rand() herhangi bir şifreleme uygulaması için kullanılmamalıdır, ancak yalnızca iç test için uygundur.
SystemPrng işlevi çekirdek modu kodu için önerilir.

.NET

RNGCryptoServiceProvider kullanma

Windows Mağazası Uygulamaları

Mağaza Uygulamaları CryptographicBuffer.GenerateRandom veya CryptographicBuffer.GenerateRandomNumber kullanabilir.

Önerilmez

Rastgele sayı oluşturmayla ilgili güvenli olmayan işlevler arasında rand,System.Random (.NET), GetTickCount ve GetTickCount64 bulunur
İkili eliptik eğri rastgele sayı oluşturucu ("DUAL_EC_DRBG") algoritmasının kullanılması önerilmez.

Windows Platformu tarafından desteklenen Şifreleme Kitaplıkları

Microsoft, Windows platformunda işletim sisteminde yerleşik olarak bulunan şifreleme API'lerinin kullanılmasını önerir. Diğer platformlarda geliştiriciler platform dışı şifreleme kitaplıklarını kullanmak üzere değerlendirmeyi tercih edebilir. Genel olarak, platform şifreleme kitaplıkları bir uygulamayla paketlenmek yerine bir işletim sisteminin parçası olarak gönderildiğinden daha sık güncelleştirilir.

Platform ile platform dışı şifrelemeyle ilgili tüm kullanım kararları aşağıdaki gereksinimlere göre yönlendirilmelidir:

Kitaplık, bilinen güvenlik açıklarından arınan güncel bir destek içi sürüm olmalıdır
En son güvenlik protokolleri, algoritmalar ve anahtar uzunlukları desteklenmelidir
(İsteğe bağlı) Kitaplığın yalnızca geriye dönük uyumluluk için eski güvenlik protokollerini/algoritmalarını destekleyebilecek durumda olması gerekir

Yerel Kod

Crypto Primitives: Sürümünüz Windows veya Windows Telefon'daysa mümkünse CNG kullanın. Aksi takdirde CryptoAPI'yi kullanın (Windows Vista'dan itibaren Windows'ta eski bir bileşen olarak desteklenen CAPI olarak da adlandırılır).
SSL/TLS/DTLS: WinINet,WinHTTP,Schannel,IXMLHTTPRequest2 veya IXMLHTTPRequest3.
- TLS 1.2'yi desteklemek için WinHTTP uygulamaları WinHttpSetOptionile derlenmelidir
Kod imzası doğrulaması: WinVerifyTrust , Windows platformlarında kod imzalarını doğrulamak için desteklenen API'dir.
Sertifika Doğrulama (kod imzalama veya SSL/TLS/DTLS için kısıtlanmış sertifika doğrulamasında kullanılan): CAPI2 API; örneğin, CertGetCertificateChain ve CertVerifyCertificateChainPolicy

Yönetilen Kod

Şifreleme Temel Bilgileri: System.Security.Cryptography ad alanında tanımlanan API'yi kullanın--- CNG sınıfları tercih edilir.
Kullanılabilir .Net Framework'ün en son sürümünü kullanın. En azından bu .Net Framework sürüm 4.6 olmalıdır. Daha eski bir sürüm gerekiyorsa, "SchUseStrongCrypto" kayıt defteri anahtarının söz konusu uygulama için TLS 1.2'yi etkinleştirecek şekilde ayarlandığından emin olun.
Sertifika Doğrulama: System.Security.Cryptography.X509Certificates ad alanı altında tanımlanan API'leri kullanın.
SSL/TLS/DTLS: System.Net ad alanı (örneğin, HttpWebRequest) altında tanımlanan API'leri kullanın.

Anahtar Türetme İşlevleri

Anahtar türetmesi, paylaşılan bir gizli diziden veya mevcut bir şifreleme anahtarından şifreleme anahtarı malzemesi türetme işlemidir. Ürünler önerilen anahtar türetme işlevlerini kullanmalıdır. Kullanıcı tarafından seçilen parolalardan anahtar türetme veya kimlik doğrulama sistemindeki depolama için parolaları karmalama, bu kılavuzda ele alınmayan özel bir durumdur; geliştiriciler bir uzmana danışmalıdır.

Aşağıdaki standartlar kullanım için önerilen KDF işlevlerini belirtir:

NIST SP 800-108: Pseudorandom işlevleri kullanılarak anahtar türetme önerisi. Özellikle, HMAC'nin sahte bir işlev olarak olduğu sayaç modunda KDF
NIST SP 800-56A (Düzeltme 2): Ayrık Logaritma Şifrelemesi Kullanan ÇiftEşli Anahtar Oluşturma Düzenleri için Öneri. Özellikle Bölüm 5.8.1'deki "Tek Adımlı Anahtar Türetme İşlevi" önerilir.

Mevcut anahtarlardan anahtar türetmek için algoritmalardan biriyle BCryptKeyDerivation API'sini kullanın:

BCRYPT_SP800108_CTR_HMAC_ALGORITHM
BCRYPT_SP80056A_CONCAT_ALGORITHM

Paylaşılan bir gizli diziden anahtar türetmek için (anahtar sözleşmesinin çıktısı) aşağıdaki algoritmalardan biriyle BCryptDeriveKey API'sini kullanın:

BCRYPT_KDF_SP80056A_CONCAT
BCRYPT_KDF_HMAC

Sertifika Doğrulaması

SSL, TLS veya DTLS kullanan ürünler, bağlandıkları varlıkların X.509 sertifikalarını tam olarak doğrulamalıdır. Bu, sertifikaların doğrulanmasını içerir:

Etki alanı adı.
Geçerlilik tarihleri (hem başlangıç hem de son kullanma tarihleri).
İptal durumu.
Kullanım (örneğin, sunucular için "Sunucu Kimlik Doğrulaması", istemciler için "İstemci Kimlik Doğrulaması").
Güven zinciri. Sertifikalar, platform tarafından güvenilen veya yönetici tarafından açıkça yapılandırılan bir kök sertifika yetkilisine (CA) zincirlenmelidir.

Bu doğrulama testlerinden herhangi biri başarısız olursa ürün varlıkla bağlantıyı sonlandırmalıdır.

"Otomatik olarak imzalanan" sertifikalara güvenen istemciler (örneğin, varsayılan yapılandırmada exchange sunucusuna bağlanan bir posta istemcisi), sertifika doğrulama denetimlerini yoksayabilir. Ancak, otomatik olarak imzalanan sertifikalar doğal olarak güven iletmez, iptali desteklemez veya anahtar yenilemeyi desteklemez. Kendinden imzalı sertifikalara yalnızca başka bir güvenilir kaynaktan (örneğin, kimliği doğrulanmış ve bütünlük korumalı bir aktarım üzerinden sertifika sağlayan güvenilir bir varlık) aldıysanız güvenmelisiniz.

Şifreleme Karma İşlevleri

Ürünler, SHA-2 karma algoritmaları ailesini (SHA256, SHA384 ve SHA512) kullanmalıdır. Güvenlik amacıyla şifreleme karmalarının 128 bitten az olacak şekilde kesilmesi önerilmez.

MAC/HMAC/anahtarlı karma algoritmalar

İleti kimlik doğrulama kodu (MAC), alıcısının gizli anahtar kullanarak hem gönderenin orijinalliğini hem de iletinin bütünlüğünü doğrulamasını sağlayan iletiye eklenmiş bir bilgi parçasıdır.

Karma tabanlı MAC (HMAC) veya blok şifreleme tabanlı MAC kullanımı, temel alınan tüm karma veya simetrik şifreleme algoritmalarının da kullanılması önerilir; şu anda bu HMAC-SHA2 işlevlerini (HMAC-SHA256, HMAC-SHA384 ve HMAC-SHA512) içerir.

HMAC'lerin 128 bitten kısa bir süreye kesilmesi önerilmez.

Tasarım ve operasyonel konular

Gerektiğinde şifreleme anahtarlarını değiştirmek için bir mekanizma sağlamalısınız. Anahtarlar, etkin yaşamlarının sonuna ulaştıktan veya şifreleme anahtarının gizliliği ihlal edildikten sonra değiştirilmelidir. Bir sertifikayı her yenilediğinizde, sertifikayı yeni bir anahtarla yenilemeniz gerekir.
Verileri korumak için şifreleme algoritmaları kullanan ürünler, gelecekte farklı algoritmalara geçişi desteklemek için bu içerikle birlikte yeterli meta veri içermelidir. Bu, kullanılan algoritmayı, anahtar boyutlarını, başlatma vektörlerini ve doldurma modlarını içermelidir.
- Şifreleme Çevikliği hakkında daha fazla bilgi için bkz . MSDN'de Şifreleme Çevikliği.
Ürünler, mevcut olduğu durumlarda bunları yeniden uygulamak yerine yerleşik, platform tarafından sağlanan şifreleme protokollerini kullanmalıdır. Bu, imzalama biçimlerini içerir (örneğin, standart, mevcut bir biçim kullanın).
RC4 gibi simetrik akış şifreleri kullanılmamalıdır. Simetrik akış şifreleri yerine, ürünler en az 128 bit anahtar uzunluğuna sahip bir blok şifrelemesi, özellikle de AES kullanmalıdır.
Şifreleme işlemi hatalarını son kullanıcılara bildirmeyin. Bir uzak çağırana hata döndürürken (örneğin, bir istemci-sunucu senaryosunda web istemcisi veya istemci), yalnızca genel bir hata iletisi kullanın.
- Doğrudan aralık dışı veya geçersiz uzunluk hatalarını raporlama gibi gereksiz bilgiler sağlamaktan kaçının. Yalnızca sunucuda ayrıntılı hataları günlüğe kaydetme ve yalnızca ayrıntılı günlük kaydı etkinse.
Aşağıdakileri içeren tüm tasarımlar için ek güvenlik incelemesi önerilir:
- Öncelikli olarak güvenliğe odaklanan yeni bir protokol (kimlik doğrulaması veya yetkilendirme protokolü gibi)
- Yeni veya standart olmayan bir şekilde şifreleme kullanan yeni bir protokol o Örnek konular şunlardır:
  - Protokolü uygulayan bir ürün, protokol uygulamasının bir parçası olarak herhangi bir şifreleme API'sini veya yöntemini çağıracak mı?
  - Protokol, kimlik doğrulaması veya yetkilendirme için kullanılan başka bir protokole bağlı mı?
  - Protokol anahtarlar gibi şifreleme öğeleri için depolama biçimlerini tanımlayacak mı?
Üretim ortamları için otomatik olarak imzalanan sertifikalar önerilmez. Ham şifreleme anahtarı kullanımı gibi otomatik olarak imzalanan bir sertifikanın kullanılması, kullanıcılara veya yöneticilere güven kararı vermek için herhangi bir temel sağlamaz.
- Buna karşılık, güvenilen bir sertifika yetkilisinde kök salmış bir sertifikanın kullanılması, ilişkili özel anahtara güvenmenin temelini netleştirir ve bir güvenlik hatası durumunda iptal ve güncelleştirmeleri etkinleştirir.

hassas verileri Depolama önce şifreleme

DPAPI/DPAPI-NG

Sistem yeniden başlatmalarında kalıcı olması gereken veriler için:

Cryptprotectdata
Cryptunprotectdata
NCryptProtectSecret (Windows 8 CNG DPAPI)

Sistem yeniden başlatmalarında kalıcı olması gerekmeyen veriler için:

CryptProtectMemory
CryptUnprotectMemory

Birden çok etki alanı hesabı ve bilgisayar tarafından kalıcı hale getirmek ve bu verilere erişmek için:

NCryptProtectSecret (CNG DPAPI'de, Windows 8 itibarıyla kullanılabilir)
Microsoft Azure KeyVault

SQL Server TDE

Hassas verileri korumak için SQL Server Saydam Veri Şifrelemesi (TDE) kullanabilirsiniz.

SDL şifreleme algoritması ve anahtar gücü gereksinimlerini karşılayan bir TDE veritabanı şifreleme anahtarı (DEK) kullanmalısınız. Şu anda yalnızca AES_128, AES_192 ve AES_256 önerilir; TRIPLE_DES_3KEY önerilmez.

SQL TDE'nin kullanımıyla ilgili dikkate alınması gereken bazı önemli noktalar vardır:

TDE etkinleştirildiğinde bile SQL Server FILESTREAM verileri için şifrelemeyi desteklemez.
TDE, veritabanına gelen veya veritabanından gelen veriler için otomatik olarak şifreleme sağlamaz; Sql Server veritabanına şifreli bağlantıları da etkinleştirmeniz gerekir. Şifrelenmiş bağlantıları etkinleştirme yönergeleri için lütfen Bkz. Veritabanı Altyapısı'nda (SQL Server Yapılandırma Yöneticisi) Şifrelenmiş Bağlan'leri etkinleştirme.
TDE korumalı bir veritabanını farklı bir SQL Server örneğine taşırsanız, TDE Veri Şifreleme Anahtarını (DEK) koruyan sertifikayı da taşımanız ve hedef SQL Server örneğinin ana veritabanına yüklemeniz gerekir. Daha fazla ayrıntı için lütfen TDEKorumalı Veritabanını Başka bir SQL Server'a Taşıma TechNet makalesine bakın.

Kimlik Bilgisi Yönetimi

Parola ve kimlik bilgileri verilerini korumak için Windows Kimlik Bilgileri Yöneticisi API'sini veya Microsoft Azure KeyVault'u kullanın.

Windows Mağazası Uygulamaları

Gizli dizileri ve hassas verileri korumak için Windows.Security.Cryptography ve Windows.Security.Cryptography.DataProtection ad alanları içindeki sınıfları kullanın.

ProtectAsync
ProtectStreamAsync
UnprotectAsync
UnprotectStreamAsync

Parola ve kimlik bilgisi verilerini korumak için Windows.Security.Credentials ad alanında sınıfları kullanın.

.NET