Praktik Terbaik untuk API Keamanan

Untuk membantu mengembangkan perangkat lunak yang aman, kami sarankan Anda menggunakan praktik terbaik berikut saat mengembangkan aplikasi. Untuk informasi selengkapnya, lihat Siklus Hidup Pengembangan Keamanan Microsoft.

Siklus Hidup Pengembangan Keamanan

Security Development Life Cycle (SDL) adalah proses yang menyelaraskan serangkaian aktivitas dan deliverable yang berfokus pada keamanan ke setiap fase pengembangan perangkat lunak. Kegiatan dan hasil ini meliputi:

• Mengembangkan model ancaman
• Menggunakan alat pemindaian kode
• Melakukan tinjauan kode dan pengujian keamanan

Untuk informasi selengkapnya tentang SDL, lihat Microsoft Security Development Lifecycle.

Model Ancaman

Melakukan analisis model ancaman dapat membantu Anda menemukan titik serangan potensial dalam kode Anda. Untuk informasi selengkapnya tentang analisis model ancaman, lihat Howard, Michael dan LeBlanc, David [2003], Writing Secure Code, 2d ed., ISBN 0-7356-1722-8, Microsoft Press, Redmond, Washington. (Sumber daya ini mungkin tidak tersedia di beberapa bahasa dan negara.)

Paket Layanan dan Pembaruan Keamanan

Lingkungan build dan pengujian harus mencerminkan tingkat paket layanan dan pembaruan keamanan yang sama dari basis pengguna yang ditargetkan. Kami menyarankan agar Anda menginstal paket layanan terbaru dan pembaruan keamanan untuk platform atau aplikasi Microsoft apa pun yang merupakan bagian dari lingkungan build dan pengujian Anda dan mendorong pengguna Anda untuk melakukan hal yang sama untuk lingkungan aplikasi yang sudah selesai. Untuk informasi selengkapnya tentang paket layanan dan pembaruan keamanan, lihat Update Windows dan Microsoft Security.

Otorisasi

Anda harus membuat aplikasi yang memerlukan hak istimewa sekecil mungkin. Menggunakan hak akses minimal mengurangi risiko kode berbahaya mengkompromikan sistem komputer Anda. Untuk informasi selengkapnya tentang menjalankan kode dalam tingkat privilese sesedikit mungkin, lihat Menjalankan dengan Privilese Khusus.

Praktik Terbaik Kriptografi

Saat menerapkan kriptografi dalam aplikasi Windows:

• Gunakan Cryptography API: Next Generation (CNG) untuk semua pengembangan baru. CryptoAPI dipertahankan hanya untuk kompatibilitas mundur.
• Rancang kelincahan kriptografi, dan rencanakan kesiapan pascakuantum. Jangan menebar pengenal algoritma yang di-hardcode atau ukuran kunci di seluruh kode Anda — pisahkan semuanya agar algoritma bisa diganti tanpa harus menulis ulang kode. Platform ini sedang beralih ke standar pascakuantum NIST, ML-KEM (FIPS 203) untuk pembentukan kunci dan ML-DSA (FIPS 204) untuk tanda tangan, jadi utamakan desain yang agile dari sekarang — terutama untuk data dengan jangka waktu kerahasiaan yang panjang, agar tahan terhadap serangan "kumpulkan sekarang, dekripsi nanti".
• Lebih suka enkripsi terautentikasi (AEAD). Gunakan AES-GCM sehingga enkripsi juga mendeteksi perubahan. Jika Anda harus menggunakan mode tanpa autentikasi seperti CBC, padankan dengan pemeriksaan integritas terpisah (encrypt-then-MAC) — kerahasiaan saja tidak memberikan perlindungan terhadap modifikasi.
• Jangan pernah menggunakan kembali nonce (IV) dengan kunci yang sama dalam AES-GCM. Penggunaan ulang nonce dalam GCM sangat berbahaya: hal ini dapat membocorkan kunci autentikasi dan memungkinkan pemalsuan pesan. Hasilkan nonce unik untuk setiap operasi enkripsi — misalnya, penghitung yang terus bertambah atau nilai acak 96-bit yang baru.
• Jangan pernah menggunakan mode cipher blok ECB. ECB mengenkripsi blok secara independen, sehingga pola dalam data plaintext dapat terlihat.
• Jangan pernah menanamkan kunci kriptografi secara langsung dalam kode sumber. Gunakan DPAPI untuk perlindungan kunci lokal atau Penyedia Penyimpanan Kunci CNG untuk kunci persisten.
• Hapus rahasia dari memori ketika Anda selesai dengannya. Timpa materi kunci kriptografis, kata sandi, dan buffer sensitif lain dengan SecureZeroMemory. Tidak seperti memset, hal tersebut tidak dihilangkan melalui optimasi oleh kompilator.
• Gunakan panjang kunci 256 bit untuk AES, 2048+ bit untuk RSA (3072+ pilihan), dan 256+ bit untuk ECDSA.
• Gunakan SHA-256 atau lebih kuat untuk hashing. Jangan gunakan MD5 atau SHA-1 untuk tujuan keamanan.
• Selalu periksa nilai pengembalian dari fungsi kriptografi. Panggilan enkripsi yang gagal secara diam-diam dapat membuat data disimpan dalam teks biasa.
• Hasilkan angka acak menggunakan BCryptGenRandom (CNG) — bukan rand() atau PRNG non-kriptografi lainnya. Berikan BCRYPT_USE_SYSTEM_PREFERRED_RNG untuk menggunakan generator yang dipilih sistem tanpa perlu mengelola handle algoritma.

Informasi Selengkapnya

Untuk informasi selengkapnya tentang praktik terbaik, lihat topik berikut ini.