Bingkai Keamanan: Kriptografi | Mitigasi

Produk/Layanan Artikel
Aplikasi Web
Basis data
Perangkat IoT
IoT Cloud Gateway
Klien Seluler Dynamics CRM
Klien Outlook Dynamics CRM
Server Identitas

Gunakan hanya cipher blok simetris dan panjang kunci yang disetujui

Judul Detail lebih lanjut
Komponen Aplikasi Web
Fase SDL Membangun
Teknologi yang Berlaku Umum
Atribut Tidak tersedia
Referensi Tidak tersedia
Langkah-langkah

Produk hanya boleh menggunakan sandi blok simetris dan panjang kunci terkait yang telah secara eksplisit disetujui oleh Crypto Advisor di organisasi Anda. Algoritma simetris yang disetujui di Microsoft mencakup cipher blok berikut:

  • Untuk kode baru AES-128, AES-192, dan AES-256 dapat diterima
  • Untuk kompatibilitas mundur dengan kode yang ada, tiga kunci 3DES dapat diterima
  • Untuk produk yang menggunakan cipher blok simetris:
    • Standar Enkripsi Tingkat Lanjut (AES) diperlukan untuk kode baru
    • Standar Enkripsi Data tiga kunci (3DES) diizinkan dalam kode yang ada untuk kompatibilitas mundur
    • Semua sandi blok lainnya, termasuk RC2, DES, 2 Key 3DES, DESX, dan Skipjack, hanya dapat digunakan untuk mendekripsi data lama, dan harus diganti jika digunakan untuk enkripsi
  • Untuk algoritma enkripsi blok simetris, diperlukan panjang kunci minimum 128 bit. Satu-satunya algoritma enkripsi blok yang direkomendasikan untuk kode baru adalah AES (AES-128, AES-192 dan AES-256 semuanya dapat diterima)
  • Tiga kunci 3DES saat ini dapat diterima jika sudah digunakan dalam kode yang ada; transisi ke AES disarankan. DES, DESX, RC2, dan Skipjack tidak lagi dianggap aman. Algoritma ini hanya dapat digunakan untuk mendekripsi data yang ada demi kompatibilitas mundur, dan data harus dienkripsi ulang menggunakan cipher blok yang direkomendasikan

Harap dicatat bahwa semua cipher blok simetris harus digunakan dengan mode sandi yang disetujui, yang memerlukan penggunaan vektor inisialisasi (IV) yang sesuai. IV yang sesuai, biasanya merupakan angka acak dan tidak pernah menjadi nilai konstanta

Penggunaan algoritma kripto warisan atau yang tidak disetujui dan panjang kunci yang lebih kecil untuk membaca data yang ada (dibandingkan dengan menulis data baru) dapat diizinkan setelah tinjauan Papan Kripto organisasi Anda. Namun, Anda harus mengajukan pengecualian terhadap persyaratan ini. Selain itu, dalam implementasi perusahaan, produk harus mempertimbangkan untuk memperingatkan administrator ketika kripto lemah digunakan untuk membaca data. Peringatan tersebut harus jelas dan dapat ditindaklanjuti. Dalam beberapa kasus, mungkin tepat untuk memiliki Kebijakan Grup mengontrol penggunaan kripto yang lemah

Algoritma .NET yang diizinkan untuk kelincahan kripto terkelola (dalam urutan preferensi)

  • AesCng (sesuai dengan FIPS)
  • AuthenticatedAesCng (sesuai dengan FIPS)
  • AESCryptoServiceProvider (sesuai dengan FIPS)
  • AESManaged (tidak mematuhi FIPS)

Harap dicatat bahwa tidak ada algoritma ini yang dapat ditentukan melalui SymmetricAlgorithm.Create metode atau CryptoConfig.CreateFromName tanpa membuat perubahan pada file machine.config. Perhatikan juga bahwa AES dalam versi .NET sebelum .NET 3.5 diberi nama RijndaelManaged, dan AesCngAuthenticatedAesCng>tersedia melalui CodePlex dan memerlukan CNG di OS yang mendasar

Gunakan mode cipher blok yang disetujui dan vektor inisialisasi untuk cipher simetris

Judul Detail lebih lanjut
Komponen Aplikasi Web
Fase SDL Membangun
Teknologi yang Berlaku Umum
Atribut Tidak tersedia
Referensi Tidak tersedia
Langkah-langkah Semua cipher blok konten harus digunakan dengan mode sandi simetris yang disetujui. Satu-satunya mode yang disetujui adalah CBC dan CTS. Secara khusus, mode operasi buku kode elektronik (ECB) harus dihindari; penggunaan ECB memerlukan tinjauan Papan Kripto organisasi Anda. Semua penggunaan OFB, CFB, CTR, CCM, dan GCM atau mode enkripsi lainnya harus ditinjau oleh Crypto Board organisasi Anda. Menggunakan kembali vektor inisialisasi (IV) yang sama dengan cipher blok dalam "mode sandi streaming," seperti CTR, dapat menyebabkan data terenkripsi terungkap. Semua cipher blok konten juga harus digunakan dengan vektor inisialisasi (IV) yang sesuai. IV yang sesuai adalah angka acak yang kuat secara kriptografis dan tidak pernah merupakan nilai konstanta.

Gunakan algoritma asimetris, panjang kunci, dan padding yang disetujui

Judul Detail lebih lanjut
Komponen Aplikasi Web
Fase SDL Membangun
Teknologi yang Berlaku Umum
Atribut Tidak tersedia
Referensi Tidak tersedia
Langkah-langkah

Penggunaan algoritma kriptografi yang dilarang menimbulkan risiko signifikan terhadap keamanan produk dan harus dihindari. Produk harus hanya menggunakan algoritma kriptografi dan panjang kunci serta padding yang secara eksplisit telah disetujui oleh Dewan Kripto organisasi Anda.

  • RSA- dapat digunakan untuk enkripsi, pertukaran kunci, dan tanda tangan. Enkripsi RSA hanya boleh menggunakan mode OAEP atau RSA-KEM padding. Kode yang ada dapat menggunakan mode padding PKCS #1 v1.5 untuk kompatibilitas saja. Penggunaan padding null secara eksplisit dilarang. >Kunci = 2048 bit diperlukan untuk kode baru. Kode yang ada mungkin hanya akan mendukung kunci < 2048 bit demi kompatibilitas mundur, setelah ditinjau dan disetujui oleh Dewan Kripto organisasi Anda. < Kunci 1024 bit hanya dapat digunakan untuk mendekripsi/memverifikasi data lama, dan harus diganti jika digunakan untuk operasi enkripsi atau penandatanganan
  • ECDSA- hanya dapat digunakan untuk tanda tangan. ECDSA dengan kunci 256-bit> diperlukan untuk kode yang baru. Tanda tangan berbasis ECDSA harus menggunakan salah satu dari tiga kurva yang disetujui NIST (P-256, P-384, atau P521). Kurva yang telah dianalisis secara menyeluruh dapat digunakan hanya setelah peninjauan dengan Crypto Board organisasi Anda.
  • ECDH- hanya dapat digunakan untuk pertukaran kunci. ECDH dengan kunci 256-bit diperlukan untuk kode baru. Pertukaran kunci berbasis ECDH harus menggunakan salah satu dari tiga kurva yang disetujui NIST (P-256, P-384, atau P521). Kurva yang telah dianalisis secara menyeluruh dapat digunakan hanya setelah peninjauan dengan Crypto Board organisasi Anda.
  • DSA- mungkin dapat diterima setelah ditinjau dan disetujui dari Dewan Kripto organisasi Anda. Hubungi penasihat keamanan Anda untuk menjadwalkan tinjauan Dewan Kripto organisasi Anda. Jika penggunaan DSA Anda disetujui, perhatikan bahwa Anda harus melarang penggunaan kunci yang panjangnya kurang dari 2048 bit. CNG mendukung panjang kunci 2048-bit dan lebih besar pada Windows 8.
  • Diffie-Hellman- hanya dapat digunakan untuk manajemen kunci sesi. Panjang kunci >= 2048 bit diperlukan untuk kode baru. Kode yang ada dapat mendukung panjang kunci < 2048 bit hanya demi kompatibilitas mundur setelah ditinjau oleh Crypto Board organisasi Anda. < Kunci 1024 bit mungkin tidak digunakan.

    Menggunakan generator angka acak yang disetujui

    Judul Detail lebih lanjut
    Komponen Aplikasi Web
    Fase SDL Membangun
    Teknologi yang Berlaku Umum
    Atribut Tidak tersedia
    Referensi Tidak tersedia
    Langkah-langkah

    Produk harus menggunakan generator angka acak yang disetujui. Fungsi pseudorandom seperti fungsi runtime C, kelas .NET Framework System.Random, atau fungsi sistem seperti GetTickCount oleh karena itu, tidak boleh digunakan dalam kode tersebut. Penggunaan algoritma generator angka acak kurva elips ganda (DUAL_EC_DRBG) dilarang

    • CNG- BCryptGenRandom(penggunaan bendera BCRYPT_USE_SYSTEM_PREFERRED_RNG yang direkomendasikan kecuali pemanggil mungkin berjalan pada IRQL apa pun yang lebih besar dari 0 [yaitu, PASSIVE_LEVEL])
    • CAPI- cryptGenRandom
    • Win32/64- RtlGenRandom (implementasi baru harus menggunakan BCryptGenRandom atau CryptGenRandom) * rand_s * SystemPrng (untuk mode kernel)
    • . NET- RNGCryptoServiceProvider atau RNGCng
    • Aplikasi Windows Store- Windows.Security.Cryptography.CryptographicBuffer.GenerateRandom atau .GenerateRandomNumber
    • Apple OS X (10.7+)/iOS(2.0+)- int SecRandomCopyBytes (SecRandomRef acak, jumlah size_t, uint8_t *byte )
    • Apple OS X (<10.7)- Gunakan /dev/random untuk mengambil angka acak
    • Java(termasuk kode Google Android Java)- kelas java.security.SecureRandom. Perhatikan bahwa untuk Android 4.3 (Jelly Bean), pengembang harus mengikuti solusi yang direkomendasikan Android dan memperbarui aplikasi mereka untuk secara eksplisit menginisialisasi PRNG dengan entropi dari /dev/urandom atau /dev/random

    Jangan gunakan cipher aliran simetris

    Judul Detail lebih lanjut
    Komponen Aplikasi Web
    Fase SDL Membangun
    Teknologi yang Berlaku Umum
    Atribut Tidak tersedia
    Referensi Tidak tersedia
    Langkah-langkah Cipher aliran simetris, seperti RC4, tidak boleh digunakan. Alih-alih sandi aliran simetris, produk harus menggunakan cipher blok, khususnya AES dengan panjang kunci setidaknya 128 bit.

    Gunakan algoritma hash MAC/HMAC/keyed yang disetujui

    Judul Detail lebih lanjut
    Komponen Aplikasi Web
    Fase SDL Membangun
    Teknologi yang Berlaku Umum
    Atribut Tidak tersedia
    Referensi Tidak tersedia
    Langkah-langkah

    Produk hanya boleh menggunakan kode autentikasi pesan (MAC) yang disetujui atau algoritma kode autentikasi pesan berbasis hash (HMAC).

    Kode autentikasi pesan (MAC) adalah bagian dari informasi yang dilampirkan ke pesan yang memungkinkan penerimanya memverifikasi keaslian pengirim dan integritas pesan menggunakan kunci rahasia. Penggunaan MAC berbasis hash (HMAC) atau MAC berbasis block-cipher diizinkan selama semua hash yang mendasari atau algoritma enkripsi simetris juga disetujui untuk digunakan; saat ini termasuk fungsi HMAC-SHA2 (HMAC-SHA256, HMAC-SHA384 dan HMAC-SHA512) dan MAC berbasis sandi blok CMAC/OMAC1 dan OMAC2 (ini didasarkan pada AES).

    Penggunaan HMAC-SHA1 mungkin diizinkan untuk kompatibilitas platform, tetapi Anda akan diminta untuk mengajukan pengecualian ke prosedur ini dan menjalani tinjauan Kripto organisasi Anda. Pemotongan HMAC menjadi kurang dari 128 bit tidak diizinkan. Menggunakan metode kustom untuk membuat hash pada kunci dan data tidak disetujui, dan harus menjalani tinjauan Dewan Kripto organisasi Anda sebelum digunakan.

    Gunakan hanya fungsi hash kriptografi yang disetujui

    Judul Detail lebih lanjut
    Komponen Aplikasi Web
    Fase SDL Membangun
    Teknologi yang Berlaku Umum
    Atribut Tidak tersedia
    Referensi Tidak tersedia
    Langkah-langkah

    Produk harus menggunakan keluarga algoritma hash SHA-2 (SHA256, SHA384, dan SHA512). Jika hash yang lebih pendek diperlukan, seperti panjang output 128-bit agar sesuai dengan struktur data yang dirancang dengan hash MD5 yang lebih pendek, tim produk dapat memotong salah satu hash SHA2 (biasanya SHA256). Perhatikan bahwa SHA384 adalah versi SHA512 yang dipotong. Pemangkasan hash kriptografi untuk tujuan keamanan hingga di bawah 128 bit tidak diizinkan. Kode baru tidak boleh menggunakan algoritma hash MD2, MD4, MD5, SHA-0, SHA-1, atau RIPEMD. Tabrakan hash dapat secara komputasi dilakukan untuk algoritma ini, yang secara efektif mematahkan algoritma tersebut.

    Algoritma hash .NET yang diizinkan untuk kelincahan kripto terkelola (dalam urutan preferensi):

    • SHA512Cng (sesuai dengan FIPS)
    • SHA384Cng (sesuai dengan FIPS)
    • SHA256Cng (sesuai dengan FIPS)
    • SHA512Managed (tidak mematuhi FIPS) (gunakan SHA512 sebagai nama algoritma dalam panggilan ke HashAlgorithm.Create atau CryptoConfig.CreateFromName)
    • SHA384Managed (tidak mematuhi FIPS) (gunakan SHA384 sebagai nama algoritma dalam panggilan ke HashAlgorithm.Create atau CryptoConfig.CreateFromName)
    • SHA256Managed (tidak mematuhi FIPS) (gunakan SHA256 sebagai nama algoritma dalam panggilan ke HashAlgorithm.Create atau CryptoConfig.CreateFromName)
    • SHA512CryptoServiceProvider (sesuai dengan FIPS)
    • SHA256CryptoServiceProvider (sesuai dengan FIPS)
    • SHA384CryptoServiceProvider (sesuai dengan FIPS)

    Menggunakan algoritma enkripsi yang kuat untuk mengenkripsi data dalam database

    Judul Detail lebih lanjut
    Komponen Basis data
    Fase SDL Membangun
    Teknologi yang Berlaku Umum
    Atribut Tidak tersedia
    Referensi Memilih algoritma enkripsi
    Langkah-langkah Algoritma enkripsi menentukan transformasi data yang tidak dapat dengan mudah dibalik oleh pengguna yang tidak sah. SQL Server memungkinkan administrator dan pengembang untuk memilih dari beberapa algoritma, termasuk DES, Triple DES, TRIPLE_DES_3KEY, RC2, RC4, RC4 128-bit, DESX, AES 128-bit, AES 192-bit, dan AES 256-bit

    Paket SSIS harus dienkripsi dan ditandatangani secara digital

    Judul Detail lebih lanjut
    Komponen Basis data
    Fase SDL Membangun
    Teknologi yang Berlaku Umum
    Atribut Tidak tersedia
    Referensi Identifikasi Sumber Paket dengan Tanda Tangan Digital, Mitigasi Ancaman dan Kerentanan (Layanan Integrasi)
    Langkah-langkah Sumber paket adalah individu atau organisasi yang membuat paket. Menjalankan paket dari sumber yang tidak diketahui atau tidak tepercaya mungkin berisiko. Untuk mencegah perubahan paket SSIS yang tidak sah, tanda tangan digital harus digunakan. Selain itu, untuk memastikan kerahasiaan paket selama penyimpanan/transit, paket SSIS harus dienkripsi

    Tambahkan tanda tangan digital ke objek database kritis yang dapat diamankan.

    Judul Detail lebih lanjut
    Komponen Basis data
    Fase SDL Membangun
    Teknologi yang Berlaku Umum
    Atribut Tidak tersedia
    Referensi TAMBAHKAN TANDA TANGAN (Transact-SQL)
    Langkah-langkah Dalam kasus di mana integritas database penting yang dapat diamankan harus diverifikasi, tanda tangan digital harus digunakan. Keamanan database seperti prosedur tersimpan, fungsi, perakitan, atau pemicu dapat ditandatangani secara digital. Di bawah ini adalah contoh kapan hal ini dapat berguna: Katakanlah ISV (Vendor Perangkat Lunak Independen) telah memberikan dukungan kepada perangkat lunak yang dikirimkan kepada salah satu pelanggan mereka. Sebelum memberikan dukungan, ISV ingin memastikan bahwa database yang dapat diamankan dalam perangkat lunak tidak dirusak baik secara tidak sengaja atau oleh upaya berbahaya. Jika securable ditandatangani secara digital, ISV dapat memverifikasi tanda tangan digitalnya dan memvalidasi integritasnya.

    Menggunakan EKM server SQL untuk melindungi kunci enkripsi

    Judul Detail lebih lanjut
    Komponen Basis data
    Fase SDL Membangun
    Teknologi yang Berlaku Umum
    Atribut Tidak tersedia
    Referensi SQL Server Extensible Key Management (EKM), Extensible Key Management menggunakan Azure Key Vault (SQL Server)
    Langkah-langkah SQL Server Extensible Key Management memungkinkan kunci enkripsi yang melindungi file database untuk disimpan dalam perangkat di luar kotak seperti smartcard, perangkat USB, atau modul EKM/HSM. Ini juga memungkinkan perlindungan data dari administrator database (kecuali anggota grup sysadmin). Data dapat dienkripsi dengan menggunakan kunci enkripsi yang hanya dapat diakses pengguna database pada modul EKM/HSM eksternal.

    Gunakan fitur AlwaysEncrypted jika kunci enkripsi tidak boleh diungkapkan ke mesin Database

    Judul Detail lebih lanjut
    Komponen Basis data
    Fase SDL Membangun
    Teknologi yang Berlaku SQL Azure, OnPrem
    Atribut Versi SQL - V12, MsSQL2016
    Referensi Selalu Terenkripsi (Mesin Database)
    Langkah-langkah Always Encrypted adalah fitur yang dirancang untuk melindungi data sensitif, seperti nomor kartu kredit atau nomor identifikasi nasional/regional (misalnya nomor jaminan sosial AS), yang disimpan dalam database Azure SQL Database atau SQL Server. Always Encrypted memungkinkan klien mengenkripsi data sensitif di dalam aplikasi klien dan tidak pernah mengungkapkan kunci enkripsi ke Mesin Database (SQL Database atau SQL Server). Akibatnya, Always Encrypted menyediakan pemisahan antara mereka yang memiliki data (dan dapat melihatnya) dan mereka yang mengelola data (tetapi seharusnya tidak memiliki akses)

    Simpan Kunci Kriptografi dengan aman di Perangkat IoT

    Judul Detail lebih lanjut
    Komponen Perangkat IoT
    Fase SDL Membangun
    Teknologi yang Berlaku Umum
    Atribut OS Perangkat - Windows IoT Core, Konektivitas Perangkat - SDK perangkat Azure IoT
    Referensi TPM di Windows IoT Core, Siapkan TPM di Windows IoT Core, Azure IoT Device SDK TPM
    Langkah-langkah Simpan secara aman Kunci Privat Simetris atau Kunci Privat Sertifikat dalam penyimpanan yang dilindungi perangkat keras seperti chip TPM atau Smart Card. Windows 10 IoT Core mendukung pengguna TPM dan ada beberapa TPM kompatibel yang dapat digunakan: Discrete TPM (dTPM). Disarankan untuk menggunakan firmware atau TPM diskrit. TPM Perangkat Lunak hanya boleh digunakan untuk tujuan pengembangan dan pengujian. Setelah TPM tersedia dan kunci disediakan di dalamnya, kode yang menghasilkan token harus ditulis tanpa pengodean keras informasi sensitif apa pun di dalamnya.

    Contoh

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

    Seperti yang dapat dilihat, kunci primer perangkat tidak ada dalam kode. Sebagai gantinya, itu disimpan di TPM di slot 0. Perangkat TPM menghasilkan token SAS berumur pendek yang kemudian digunakan untuk terhubung ke IoT Hub.

    Membuat kunci simetris acak dengan panjang yang cukup untuk autentikasi ke IoT Hub

    Judul Detail lebih lanjut
    Komponen IoT Cloud Gateway
    Fase SDL Membangun
    Teknologi yang Berlaku Umum
    Atribut Pilihan gateway - Azure IoT Hub
    Referensi Tidak tersedia
    Langkah-langkah IoT Hub berisi Registri Identitas perangkat dan saat memprovisikan perangkat, secara otomatis menghasilkan kunci Simetris acak. Disarankan untuk menggunakan fitur Azure IoT Hub Identity Registry ini untuk menghasilkan kunci yang digunakan untuk autentikasi. IoT Hub juga memungkinkan kunci ditentukan saat membuat perangkat. Jika kunci dihasilkan di luar IoT Hub selama provisi perangkat, disarankan untuk membuat kunci simetris acak atau setidaknya 256 bit.

    Pastikan kebijakan manajemen perangkat tersedia yang memerlukan PIN penggunaan dan memungkinkan penghapusan jarak jauh

    Judul Detail lebih lanjut
    Komponen Klien Seluler Dynamics CRM
    Fase SDL Penyebaran
    Teknologi yang Berlaku Umum
    Atribut Tidak tersedia
    Referensi Tidak tersedia
    Langkah-langkah Pastikan kebijakan manajemen perangkat tersedia yang memerlukan PIN penggunaan dan memungkinkan penghapusan jarak jauh

    Pastikan kebijakan manajemen perangkat tersedia yang memerlukan PIN/kata sandi/kunci otomatis dan mengenkripsi semua data (misalnya BitLocker)

    Judul Detail lebih lanjut
    Komponen Klien Dynamics CRM Outlook
    Fase SDL Membangun
    Teknologi yang Berlaku Umum
    Atribut Tidak tersedia
    Referensi Tidak tersedia
    Langkah-langkah Pastikan kebijakan manajemen perangkat tersedia yang memerlukan PIN/kata sandi/kunci otomatis dan mengenkripsi semua data (misalnya BitLocker)

    Pastikan bahwa kunci penandatanganan diperbarui saat menggunakan Pusat Identitas

    Judul Detail lebih lanjut
    Komponen Server Identitas
    Fase SDL Penyebaran
    Teknologi yang Berlaku Umum
    Atribut Tidak tersedia
    Referensi Tidak tersedia
    Langkah-langkah Pastikan bahwa kunci penandatanganan diperbarui saat menggunakan Server Identitas. Tautan di bagian referensi menjelaskan bagaimana ini harus direncanakan tanpa menyebabkan pemadaman pada aplikasi yang mengandalkan Server Identitas.

    Pastikan ID klien dan rahasia klien yang kuat secara kriptografis digunakan di Server Identitas

    Judul Detail lebih lanjut
    Komponen Server Identitas
    Fase SDL Membangun
    Teknologi yang Berlaku Umum
    Atribut Tidak tersedia
    Referensi Tidak tersedia
    Langkah-langkah

    Pastikan bahwa ID klien dan rahasia klien yang kuat secara kriptografis digunakan di Server Identitas. Panduan berikut harus digunakan saat membuat ID klien dan rahasia:

    • Membuat GUID acak sebagai ID klien
    • Hasilkan kunci 256-bit acak kriptografis sebagai rahasia
    • Last updated on