Rekomendasi untuk melindungi rahasia aplikasi

  • Artikel

Berlaku untuk rekomendasi daftar periksa Azure Well-Architected Framework Security ini:

SE:09 Lindungi rahasia aplikasi dengan memperkuat penyimpanannya dan membatasi akses dan manipulasi serta dengan mengaudit tindakan tersebut. Jalankan proses rotasi yang andal dan teratur yang dapat meningkatkan rotasi untuk keadaan darurat.

Panduan ini menjelaskan rekomendasi untuk mengamankan informasi sensitif dalam aplikasi. Manajemen rahasia yang tepat sangat penting untuk menjaga keamanan dan integritas aplikasi, beban kerja, dan data terkait Anda. Penanganan rahasia yang tidak tepat dapat menyebabkan pelanggaran data, gangguan layanan, pelanggaran peraturan, dan masalah lainnya.

Kredensial, seperti kunci API, token Open Authorization (OAuth), dan kunci Secure Shell (SSH) adalah rahasia. Beberapa kredensial, seperti token OAuth sisi klien, dapat dibuat secara dinamis saat runtime. Rahasia dinamis masih perlu diamankan meskipun sifatnya sementara. Informasi noncredential, seperti sertifikat dan kunci tanda tangan digital, juga bisa sensitif. Persyaratan kepatuhan dapat menyebabkan pengaturan konfigurasi yang biasanya tidak dianggap rahasia untuk diperlakukan sebagai rahasia aplikasi.

Definisi 

Istilah Definisi
Sertifikat File digital yang menyimpan kunci publik untuk enkripsi atau dekripsi.
Kredensial Informasi yang digunakan untuk memverifikasi identitas penerbit atau konsumen di saluran komunikasi.
Pemindaian info masuk Proses memvalidasi kode sumber untuk memastikan rahasia tidak disertakan.
Enkripsi Proses di mana data dibuat tidak dapat dibaca dan dikunci dengan kode rahasia.
Kunci Kode rahasia yang digunakan untuk mengunci atau membuka kunci data terenkripsi.
Akses hak istimewa terkecil Prinsip Zero Trust yang bertujuan meminimalkan sekumpulan izin untuk menyelesaikan fungsi pekerjaan.
Identitas Terkelola Identitas yang ditetapkan ke sumber daya dan dikelola oleh Azure.
Nonsecret Informasi yang tidak membahmari postur keamanan beban kerja jika bocor.
Rotasi Proses memperbarui rahasia secara teratur sehingga, jika disusupi, rahasia hanya tersedia untuk waktu yang terbatas.
Rahasia Komponen rahasia sistem yang memfasilitasi komunikasi antar komponen beban kerja. Jika bocor, rahasia dapat menyebabkan pelanggaran.
X.509 Standar yang menentukan format sertifikat kunci publik.

Penting

Jangan perlakukan nonsecret seperti rahasia. Rahasia memerlukan kekakuan operasional yang tidak perlu untuk nonsecret dan itu mungkin mengakibatkan biaya tambahan.

Pengaturan konfigurasi aplikasi, seperti URL untuk API yang digunakan aplikasi, adalah contoh nonsecrets. Informasi ini tidak boleh disimpan dengan kode aplikasi atau rahasia aplikasi. Pertimbangkan untuk menggunakan sistem manajemen konfigurasi khusus seperti Azure App Configuration untuk mengelola pengaturan ini. Untuk informasi selengkapnya, lihat Apa itu Azure App Configuration?.

Strategi desain utama

Strategi manajemen rahasia Anda harus meminimalkan rahasia sebanyak mungkin dan mengintegrasikannya ke lingkungan dengan memanfaatkan fitur platform. Misalnya, jika Anda menggunakan identitas terkelola untuk aplikasi Anda, informasi akses tidak disematkan dalam string koneksi dan aman untuk menyimpan informasi dalam file konfigurasi. Pertimbangkan area perhatian berikut sebelum menyimpan dan mengelola rahasia:

  • Rahasia yang dibuat harus disimpan dalam penyimpanan yang aman dengan kontrol akses yang ketat.

  • Rotasi rahasia adalah operasi proaktif, sedangkan pencabutan bersifat reaktif.

  • Hanya identitas tepercaya yang harus memiliki akses ke rahasia.

  • Anda harus mempertahankan jejak audit untuk memeriksa dan memvalidasi akses ke rahasia.

Bangun strategi di sekitar titik-titik ini untuk membantu mencegah pencurian identitas, menghindari penolakan, dan meminimalkan paparan informasi yang tidak perlu.

Praktik aman untuk manajemen rahasia

Jika memungkinkan, hindari membuat rahasia. Temukan cara untuk mendelegasikan tanggung jawab ke platform. Misalnya, gunakan identitas terkelola bawaan platform untuk menangani kredensial. Lebih sedikit rahasia menghasilkan area permukaan yang berkurang dan lebih sedikit waktu yang dihabiskan untuk manajemen rahasia.

Kami menyarankan agar kunci memiliki tiga peran yang berbeda: pengguna, administrator, dan auditor. Perbedaan peran membantu memastikan bahwa hanya identitas tepercaya yang memiliki akses ke rahasia dengan tingkat izin yang sesuai. Mendidik pengembang, administrator, dan personel relevan lainnya tentang pentingnya manajemen rahasia dan praktik terbaik keamanan.

Kunci yang dibagikan sebelumnya

Anda dapat mengontrol akses dengan membuat kunci yang berbeda untuk setiap konsumen. Misalnya, klien berkomunikasi dengan API pihak ketiga menggunakan kunci yang telah dibagikan sebelumnya. Jika klien lain perlu mengakses API yang sama, mereka harus menggunakan kunci lain. Jangan bagikan kunci meskipun dua konsumen memiliki pola atau peran akses yang sama. Cakupan konsumen mungkin berubah dari waktu ke waktu, dan Anda tidak dapat memperbarui izin secara independen atau membedakan pola penggunaan setelah kunci dibagikan. Akses yang berbeda juga membuat pencabutan lebih mudah. Jika kunci konsumen disusupi, lebih mudah untuk mencabut atau memutar kunci tersebut tanpa memengaruhi konsumen lain.

Panduan ini berlaku untuk lingkungan yang berbeda. Kunci yang sama tidak boleh digunakan untuk lingkungan praproduksi dan produksi. Jika Anda bertanggung jawab untuk membuat kunci pra-bagi, pastikan Anda membuat beberapa kunci untuk mendukung beberapa klien.

Untuk informasi selengkapnya, lihat Rekomendasi untuk manajemen identitas dan akses.

Penyimpanan rahasia

Gunakan sistem manajemen rahasia, seperti Azure Key Vault, untuk menyimpan rahasia di lingkungan yang diperkeras, mengenkripsi saat tidak aktif dan dalam transit, serta mengaudit akses dan perubahan pada rahasia. Jika Anda perlu menyimpan rahasia aplikasi, simpan di luar kode sumber untuk rotasi yang mudah.

Sertifikat hanya boleh disimpan di Key Vault atau di penyimpanan sertifikat OS. Misalnya, menyimpan sertifikat X.509 dalam file PFX atau pada disk tidak disarankan. Jika Anda membutuhkan tingkat keamanan yang lebih tinggi, pilih sistem yang memiliki kemampuan modul keamanan perangkat keras (HSM) alih-alih penyimpanan rahasia berbasis perangkat lunak.

Tradeoff: Solusi HSM ditawarkan dengan biaya yang lebih tinggi. Anda mungkin juga melihat efek pada performa aplikasi karena lapisan keamanan yang ditambahkan.

Sistem manajemen rahasia khusus memudahkan untuk menyimpan, mendistribusikan, dan mengontrol akses ke rahasia aplikasi. Hanya identitas dan layanan resmi yang harus memiliki akses ke penyimpanan rahasia. Akses ke sistem dapat dibatasi melalui izin. Selalu terapkan pendekatan hak istimewa paling sedikit saat menetapkan izin.

Anda juga perlu mengontrol akses di tingkat rahasia. Setiap rahasia seharusnya hanya memiliki akses ke satu cakupan sumber daya. Buat batas isolasi sehingga komponen hanya dapat menggunakan rahasia yang dibutuhkannya. Jika komponen yang terisolasi disusupi, komponen tersebut tidak dapat mengontrol rahasia lain dan berpotensi seluruh beban kerja. Salah satu cara untuk mengisolasi rahasia adalah dengan menggunakan beberapa brankas kunci. Tidak ada biaya tambahan untuk membuat brankas kunci tambahan.

Menerapkan audit dan pemantauan untuk akses rahasia. Catat siapa yang mengakses rahasia dan kapan harus mengidentifikasi aktivitas yang tidak sah atau mencurigakan. Untuk informasi tentang pengelogan dari perspektif keamanan, lihat Rekomendasi tentang pemantauan keamanan dan deteksi ancaman.

Rotasi rahasia

Memiliki proses di tempat yang menjaga kebersihan rahasia. Umur panjang rahasia memengaruhi manajemen rahasia itu. Untuk mengurangi vektor serangan, rahasia harus dihentikan dan diganti dengan rahasia baru sesering mungkin.

Tangani token akses OAuth dengan hati-hati, dengan mempertimbangkan waktu hidup mereka. Pertimbangkan apakah jendela pencahayaan perlu disesuaikan dengan periode yang lebih singkat. Token refresh harus disimpan dengan aman dengan paparan terbatas pada aplikasi. Sertifikat yang diperbarui juga harus menggunakan kunci baru. Untuk informasi tentang token refresh, lihat Mengamankan token refresh On-Behalf-Of OAuth 2.0.

Ganti rahasia setelah mencapai akhir masa pakainya, tidak lagi digunakan oleh beban kerja, atau jika telah disusupi. Sebaliknya, jangan pensiun rahasia aktif kecuali itu darurat. Anda dapat menentukan status rahasia dengan melihat log akses. Proses rotasi rahasia seharusnya tidak memengaruhi keandalan atau performa beban kerja. Gunakan strategi yang membangun redundansi dalam rahasia, konsumen, dan metode akses untuk rotasi yang lancar.

Untuk informasi selengkapnya tentang cara Azure Storage menangani rotasi, lihat Mengelola kunci akses akun.

Proses rotasi harus diotomatisasi dan disebarkan tanpa interaksi manusia. Menyimpan rahasia di penyimpanan manajemen rahasia yang secara asli mendukung konsep rotasi dapat menyederhanakan tugas operasional ini.

Praktik aman untuk menggunakan rahasia

Sebagai generator atau operator rahasia, Anda harus dapat mendistribusikan rahasia dengan cara yang aman. Banyak organisasi menggunakan alat untuk berbagi rahasia dengan aman baik dalam organisasi maupun secara eksternal kepada mitra. Dengan tidak adanya alat, memiliki proses untuk menyerahkan kredensial dengan benar kepada penerima yang berwenang. Rencana pemulihan bencana Anda harus mencakup prosedur pemulihan rahasia. Memiliki proses untuk situasi di mana kunci disusupi atau bocor dan perlu diregenerasi sesuai permintaan. Pertimbangkan praktik terbaik berikut untuk keamanan saat menggunakan rahasia:

Mencegah hardcoding

Jangan melakukan hard code rahasia sebagai teks statis dalam artefak kode seperti kode aplikasi, file konfigurasi, dan alur build-deployment. Praktik berisiko tinggi ini membuat kode rentan karena rahasia diekspos ke semua orang dengan akses baca.

Anda dapat menghindari situasi ini dengan menggunakan identitas terkelola untuk menghilangkan kebutuhan untuk menyimpan kredensial. Aplikasi Anda menggunakan identitas yang ditetapkan untuk mengautentikasi terhadap sumber daya lain melalui Penyedia Identitas (IdP). Uji di lingkungan nonproduksi dengan rahasia palsu selama pengembangan untuk mencegah paparan rahasia nyata yang tidak disengaja.

Gunakan alat yang secara berkala mendeteksi rahasia yang terekspos dalam kode aplikasi Anda dan membangun artefak. Anda dapat menambahkan alat-alat ini sebagai kait prakomit Git yang memindai kredensial sebelum kode sumber menerapkan penyebaran. Tinjau dan bersihkan log aplikasi secara teratur untuk membantu memastikan bahwa tidak ada rahasia yang direkam secara tidak sengaja. Anda juga dapat memperkuat deteksi melalui ulasan serekan.

Catatan

Jika alat pemindaian menemukan rahasia, rahasia tersebut harus dianggap disusupi. Ini harus dicabut.

Merespons rotasi rahasia

Sebagai pemilik beban kerja, Anda perlu memahami rencana dan kebijakan rotasi rahasia sehingga Anda dapat menggabungkan rahasia baru dengan gangguan minimal pada pengguna. Ketika rahasia diputar, mungkin ada jendela ketika rahasia lama tidak valid, tetapi rahasia baru belum ditempatkan. Selama jendela tersebut, komponen yang coba dijangkau aplikasi tidak mengakui permintaan. Anda dapat meminimalkan masalah ini dengan membangun logika coba lagi ke dalam kode. Anda juga dapat menggunakan pola akses bersamaan yang memungkinkan Anda memiliki beberapa kredensial yang dapat diubah dengan aman tanpa memengaruhi satu sama lain.

Bekerja dengan tim operasi dan menjadi bagian dari proses manajemen perubahan. Anda harus memberi tahu pemilik kredensial ketika Anda menonaktifkan bagian dari aplikasi yang menggunakan kredensial yang tidak lagi diperlukan.

Integrasikan pengambilan dan konfigurasi rahasia ke dalam alur penyebaran otomatis Anda. Pengambilan rahasia membantu memastikan rahasia diambil secara otomatis selama penyebaran. Anda juga dapat menggunakan pola injeksi rahasia untuk memasukkan rahasia ke dalam kode aplikasi atau konfigurasi saat runtime, yang mencegah rahasia terekspos secara tidak sengaja ke log atau kontrol versi.

Fasilitasi Azure

Simpan rahasia dengan menggunakan Key Vault. Simpan rahasia di sistem manajemen rahasia Azure, Key Vault, Azure Managed HSM, dan lokasi lainnya. Untuk informasi selengkapnya, lihat Cara memilih solusi manajemen kunci yang tepat.

Mengintegrasikan kontrol akses berbasis identitas. id Microsoft Entra dan identitas terkelola membantu meminimalkan kebutuhan akan rahasia. Microsoft Entra ID menawarkan pengalaman yang sangat aman dan dapat digunakan untuk kontrol akses dengan mekanisme bawaan untuk menangani rotasi kunci, untuk anomali, dan banyak lagi.

Gunakan kontrol akses berbasis peran Azure (RBAC) untuk menetapkan izin kepada pengguna, grup, dan aplikasi pada cakupan tertentu.

Gunakan model akses untuk mengontrol brankas kunci, izin, dan rahasia. Untuk informasi selengkapnya, lihat Gambaran umum model akses.

Menerapkan deteksi paparan rahasia. Integrasikan proses dalam beban kerja Anda yang mendeteksi aktivitas mencurigakan dan secara berkala memeriksa kunci yang terekspos dalam kode aplikasi Anda. Beberapa opsi meliputi:

Jangan menyimpan kunci dan rahasia untuk jenis lingkungan apa pun dalam file konfigurasi aplikasi atau alur integrasi berkelanjutan dan pengiriman berkelanjutan (CI/CD). Pengembang harus menggunakan Visual Studio Connected Services atau file khusus lokal untuk mengakses kredensial.

Daftar periksa keamanan

Lihat kumpulan rekomendasi lengkap.

Daftar periksa keamanan