Bayangkan skenario ini. Anda sedang membangun aplikasi dan membutuhkan kunci API untuk terhubung ke layanan kata sandi basis data atau kunci akun penyimpanan. Jadi Anda memasukkannya langsung ke dalam kode mungkin diberkas konfigurasi atau variabel lingkungan.

Dan begitu saja, rahasia Anda tidak lagi menjadi rahasia. Jika kode itu jatuh ke tangan yang salah, seluruh sistem Anda akan terekspos. Nah, Azure Key Vault adalah alat yang memperbaiki masalah tersebut. Ini memberi Anda tempat aman untuk menyimpan rahasia agar tidak pernah berakhir di kodean. Namun inilah hal yang sering diselapami banyak orang. Hanya memiliki Key Vault tidak serta-merta membuat Anda aman. Cara Anda mengaturnya, mengontrol akses, dan menetapkan izin juga sama pentingnya. Di akhir episode ini, Anda akan tahu apa itu Key Vault sebenarnya. Apa yang bisa disimpan di dalamnya, cara kerja akses, dan kesalahan terbesar yang bisa membuat rahasia Anda terekspos. Semua dalam bahasa yang sederhana tanpa jargon, hanya poin-poin yang Anda butuh. Jadi apa sebenarnya Azure Key Vault itu? Apa itu Azure Key Vault? Berikut adalah alat definisi paling sederhana. Azure Key Vault adalah perangkas digital berbasis cloud untuk rahasia.

Ini adalah layanan terkola dari Microsoft untuk kunci API, kata sandi basis data, string koneksi, kunci enkripsi, dan sertifikat di satu tempat terpusat. Anda tidak perlu khawatir tentang infrastruktur karena Azure menangani pembaruan waktu operasional dan keamanannya. Anda cukup menggunakan. Bayangkan seperti sebuah gedung perkantor. Anda memiliki ruang kerja, ruang rapat, dan lemari arsip. Tetapi di suatu tempat di ruang bawah tanah terdapat ruang berangkas aman tempat Anda menyimpan hal penting. Kunci utama, uang tunai dokumen hukum. Tidak ada yang bisa masuk tanpa izin dan autentikasi. Dan setiap kali seseorang membuka pintunya, itu akan dicat. Telah Key Vault. Ruangan aman di ruang bawah tanah arsitektur Azure Anda. Sekarang bandingkan ditunai cara langsung. 20 tahun lalu, jika Anda membutuhkan kata sandi basis data, Anda akan menulisnya langsung di berkas konfigurasi, mungkin di variabel lingkungan, atau lebih buruk lagi, membiarkannya dalam teks biasa di kode sumber.

Jika seseorang mendapatkan akses ke server itu, mereka memiliki sebuah. Dan jika Anda perlu mengganti kata sandi tersebut, Anda harus memperbarunya di mana. Setiap berkas konfigurasi, setiap lingkungan, setiap penerapan, itu adalah mimpi buruk. Key Vault mengubah semua itu. Alih-alih menyebar rahasia di seluruh kode dan berkas konfigurasi Anda menyimpannya di satu tempat terpusat. Aplikasi Anda memintanya saat waktu proses runtime hanya ketika membutuhkan. Dan karena semuanya terpusat, Anda dapat merotasi rahasia di satu tempat, dan setiap aplikasi yang menggunakannya akan mengambil nilai baru secara otomatis tanpa perubahan kode atau penyebaran ulang. Namun masalahnya, Key Vault bukan sekadar pengelola kata sandi untuk aplikasi Anda. Ini adalah layanan keamanan ini. Setiap layanan Azure dapat berintegrasi dengannya. App Service, Functions, AKS, Data Factory, Synapse, Logic Apps, dan Pipeline DevOps semuanya tahu cara berkomunikasi dengan Key Vault.

Ini menjadi tulang punggung arsitektur cloud Anda yang aman. Dan setelah Anda mengaturnya dengan benar, Anda tidak perlu lagi memikirkan manajemen kredensial. Apa saja yang bisa Anda simpulkan? Sekarang setelah Anda tahu apa itu Key Vault, mari kita bahas apa yang sebenarnya bisa Anda masukkan ke dalamnya. Anda memiliki tiga kategori utama, rahasia, kunci, dan sertifikat. Masing-masing memiliki fungsi berbeda dan memahami perbedaannya yang membantu Anda menggunakan Key Vault dengan cara yang tepat. Mari kita mulai dengan rahasi. Ini adalah hal paling umum yang disimpan orang. Rahasia mencakup string koneksi, kunci API, kata sandi basis data, kunci akun penyimpanan, pada dasarnya semua kredensial sehari-hari yang dibutuhkan aplikasi Anda untuk berbicara dengan layanan light. Alih-alih menyimpannya di kode atau file konfigurasi yang Anda menaruhnya di Key Vault. Aplikasi Anda mengambilnya saat runtime dan tidak ada yang melihatnya dalam bentuk text base.

Bayangkan ini seperti laci terkunci di lemari R-SHIP digital Anda. Rah kunci. Ini adalah kunci encryption untuk data address. Jika Anda menggunakan kunci yang dikelola pelanggan untuk Azure Storage, basis data SQL, atau mengenkripsi disk mesin virtual, kunci tersebut dapat disimpan di Key Vault. Itu memberi Anda kendali penuh atas siapa yang dapat menggunakannya dan kapan. Dan jika Anda memerlukan kunci berbasis perangkat keras untuk kepatuhan, tingkat premium menyediakannya dengan perlindungan. Dan kita memiliki sertifikat. Sertifikat TLS dan SSL untuk aplikasi web API dan layanan internal Anda. Key Vault dapat menyimpannya, mengelola siklus hidupnya, bahkan memperbarunya secara otomatis saat mendekati masa. Ini sangat membantu bagi siapapun yang pernah mengalami sertifikat gelaluarsa pada pukul 3 pagi di hari minggu. Berikut contoh nyata. Bayangkan Anda memiliki aplikasi web yang membutuhkan string koneksi basis data dan kunci API untuk layanan pihak ketiga.

Cara lama Anda akan memasukkan keduanya ke dalam file JSON pengaturan aplikasi Anda. Kemungkinan besar jika file tersebut masuk ke repository Anda, siapapun yang memiliki akses ke kode tersebut dapat melihat kredensial basis data Anda. Dengan Key Vault, Anda menyimpan kedua nilai tersebut sebagai rahsia. Aplikasi Anda mengambilnya saat startup dan nilai tersebut tidak pernah muncul di kode sumber. Perlu merotasi kata sandi basis data? Perbarui saja di Key Vault. Aplikasi akan mengambil nilai baru tersebut secara otomatis pada saat dimulai ulang berikut. Tidak ada perubahan kode, tidak ada redeplot. Satu hal yang sering mengejutkan orang adalah fitur pembuatan versi yang sudah baru. Saat Anda memperbarui rahasia, Key Vault tidak menyimpan nilai yang lama. Sistem membuat versi baru. Versi lama tetap disimpan agar Anda bisa melakukan pemulihan jika terjadi kesalahan. Ini sangat berguna saat terjadi insiden.

Anda dapat dengan cepat kembali ke rahasia sebelumnya tanpa perlu mengingat nilai lamanya. Anda bisa menyimpan ketiganya, rahasia, kunci, dan sertifikat, di dalam vault yang sama. Namun praktik terbaiknya adalah misalkannya berdasarkan lingkungan. Gunakan satu vault untuk pengembangan, satu untuk produksi, satu untuk produksi. Ini mencegah seseorang tidak sengaja menggunakan rahasia produksi di lingkungan dev dan membatasi risiko jika satu vault disusupi, jika satu vault disusupi. Tidak menyimpan rahasia hanya setengah dari cerita. Pertanyaan sebenarnya adalah siapa yang boleh mengaksesnya. Cara kerja kontrol akses. Mari kita bahas siapa saja yang bisa masuk. Key vault punya dua cara berbeda untuk mengontrol akses dan pilihan Anda sangat berpengaruh. Modal pertama adalah kebijakan akses warisan. Ini adalah cara yang lama. Anda membuat kebijakan langsung pada vault dan menetapkan izin ke pengguna atau grup tertentu untuk jenis data tertentu, rahasia, kunci, atau sertifikat.

Masalahnya, kebijakan ini terikat langsung dengan vault tersebut. Jika Anda memiliki banyak vault, Anda harus menolak kebijakan di tiap vault secara terbisa. Itu tidak bisa ditingkatkan emisi. Microsoft kini tidak menyarankan penggunaannya karena ada masalah keamanan yang diketahui. Kebijakan ini tidak mendukung manajemen identitas istimewa dan bisa menciptakan jalur eskalasi hak akses yang tak terduga. Modal kedua adalah Azure RBC, kontrol akses berbasis peran. Ini adalah cara yang modern. Cara ini menggunakan identitas intra-ID dan konsisten dengan cara Anda mengelola izin di tempat lain di Azure. Jika Anda sudah tahu cara memberi akses ke akun penyimpanan atau mesin virtual, Anda sudah tahu cara memberi akses ke key vault. Sistem yang sama, pola yang sama. Inilah aturan emasnya, hak akses minimum. Berikan akses minimum yang diperlukan seseorang, tidak lebih. Jika seseorang hanya perlu membaca rahasia, jangan beri izin untuk membuat atau menghapusnya.

Jika seseorang hanya perlu mengelola sertifikat, jangan beri akses ke kunci. Mari saya jelaskan benar-benar. Ada key vault reader. Ini memungkinkan seorang melihat daftar rahasia tetapi tidak bisa membaca. Key vault secret user. Ini memungkinkan seseorang benar-benar membaca nilai rahasia. Dan key vault secret officer. Ini memungkinkan seseorang membuat, memperbarui, dan menghapus rahasia. Perhatikan polanya. Setiap peran spesifik untuk data di dalam vault bukan untuk vault itu sendiri. Sekarang, bandingkan itu dengan peran umum pemilik kontributor pembaca. Peran ini berlaku untuk vault sebagai sumber daya, bukan untuk data di dalam. Seorang pemilik dapat menghapus seluruh. Seorang kontributor dapat mengubah pengaturan. Namun, tidak ada satupun dari peran ini yang memberikan akses ke rahasia di dalamnya. Itu adalah lapisan izin yang terpisah dan itulah poin kuncinya. Kontrol akses adalah sebuah tingkat.

Anda memerlukan akses ke vault itu sendiri, itulah lapisan pertama. Dan Anda memerlukan akses ke data di dalam vault itulah lapisan kedua. Keduanya harus diberikan secara terpisah. Kebanyakan pemula hanya memikirkan lapisan pertama dan merupakan lapisan kedua. Disitulah masalah dimulai. Salahan keamanan nomor satu. Begini masalahnya. Kebanyakan orang melihat peran kontributor key vault dan menganggapnya amat. Mereka melihat kata kontributor dan berasumsi mereka bisa mengelola pengaturan vault tetapi tidak bisa menyentuh rahasia di dalam. Dokumentasi Microsoft sendiri awalnya mengatakan hal yang sama persis. Peran ini tidak mengizinkan Anda untuk mengakses rahasia kunci atau sertifikat. Hanya saja itu tidak sepenuhnya. Pengguna dengan peran kontributor key vault dapat mengubah kebijakan akses pada vault. Dan jika vault tersebut masih menggunakan kebijakan akses warisan yang banyak dilakukan, maka mereka cukup memberikan diri mereka akses baca penuh ke setiap rahasia kunci dan sertifikat di dalamnya.

Tidak perlu eksploitasi khusus, tidak ada kerentanan yang perlu diperbaiki. Begitulah cara kerja izin tersebut. Peneliti keamanan di Datadoc membuktikan hal ini pada tahun 2020. Mereka menunjukkan bahwa kontributor dapat meningkatkan hak akses ke akses data penuh di vault manapun yang menggunakan kebijakan akses warisan. Tanggapan Microsoft cukup menarik. Mereka mengatakan ini bukan kerentanan karena kontributor dirancang untuk mengelola kebijakan akses. Tetapi mereka juga memperbarui dokumentasi untuk secara eksplisit memperingatkan bahwa peran tersebut dapat memperingatkan bahwa peran tersebut dapat memberikan akses data kepada dirinya sendiri. Jadi ini bukan bug di key vault itu sendiri, melainkan jebakan konfigurasi. Dan ini menjebak tim yang berpengalaman sekalipun karena nama perannya terdengar tidak berbahaya. Kontributor tidak terdengar seperti seseorang yang bisa membaca kata sandi bahasi data Anda.

Tetapi dalam prakteknya mereka bisa. Pikirkan risikonya. Jika penyerang mengkompromikan akun dengan peran kontributor pada key vault Anda, mereka tidak perlu membobol vault tersebut. Mereka tidak perlu mecahkan enkripsi. Mereka hanya mengubah kebijakan akses, memberikan diri mereka akses baca, dan secara diam-diam mencuri setiap rahasia yang Anda simpan, string koneksi, kunci API, sertifikat, semuanya. Dan karena perubahan kebijakan akses adalah aktivitas administratif yang normal, hal itu mungkin tidak memicu peringatan apa-apa. Apa solusinya? Gunakan Azure RBAC untuk akses bidang data alih-alih kebijakan akses warisan. RBAC memisahkan pengelolaan vault dari data di dalamnya. Kedua, jangan pernah memberikan peran kontributor key vault kepada siapapun yang tidak benar-benar membutuhkan. Ketiga, jika Anda sudah memiliki pengguna dengan peran tersebut, segera audit mereka hari. Ganti peran kontributor dengan peran yang lebih spesifik seperti pengguna rahasia key vault atau petugas rahasia key vault.

Ada kesalahan kedua yang memperparah hal ini, yaitu menaruh semua rahasia Anda dalam satu vault. Jika Anda memiliki satu vault untuk semuanya, dev, test, staging, produksi, semua aplikasi Anda, dan vault itu disusupi, semuanya akan terekspos. Itu adalah titik kegagalan itu. Kita akan membahas lebih lanjut tentang strategi multi vault sebentar lagi. Tetapi prinsipnya sederh. Jangan menaruh semua telur dalam satu keranjang, terutama jika keranjang itu memegang kunci seluruh infrastruktur Anda. Identitas terkelola, standar emasnya. Jadi bagaimana cara melakukan ini? Mari kita bahas secara terbaik untuk mengakses key vault. Ada masalah mendasar. Untuk mendapatkan kredensial dari key vault, aplikasi Anda perlu mengautentikasi diri. Tetapi untuk mengautentikasi aplikasi butuh kredensial. Di mana Anda menyimpan kredensial yang digunakan aplikasi Anda untuk mendapatkan kredensial? Ini adalah masalah ayam dan telur.

Jawaban lama adalah service prinsipal dengan client secret. Tetapi client secret itu harus ada di suatu tempat. Mungkin di file konfigurasi, varia melingkungan, atau pipeline penyebaran, atau pipeline penyebaran. Dan sekarang Anda kembali ke masalah yang sama. Anda hanya memindahkan rahasia itu ke tempat lain. Identitas terkelola menyelesaikan masalah ini. Begini cara kerjanya. Saat Anda mengaktifkan identitas terkelola pada sumber daya Azure, misalnya web app, function, atau virtual machine, Azure otomatis membuat identitas untuk sumber daya tersebut di Entra ID. Identitas itu dikelola sepenuhnya oleh Azure. Tidak ada kredensial untuk dibuat. Tidak ada rahasia untuk dirotasi. Tidak ada yang perlu disimpan. Sumber daya tersebut hanya memiliki identitas yang diketahui oleh Azure. Ada dua jenis. Identitas terkelola yang ditetapkan sistem terikat pada satu sumber daya tertentu. Jika Anda menghapus sumber daya tersebut, identitasnya pun negenir.

Keduanya berbagi siklus hidup yang sama yang membuat administrasi menjadi sederhan. Identitas terkelola yang ditetapkan pengguna adalah identitas mandiri yang dapat Anda tetapkan ke beberapa sumber daya. Identitas ini tidak berbagi siklus hidup dengan salah satunya, sehingga berguna jika Anda membutuhkan identitas yang sama di beberapa layanan. Begini tampilannya dalam prakteknya. Anda memiliki aplikasi web yang perlu membaca string koneksi database dari Key Vault. Anda mengaktifkan identitas terkelola yang ditetapkan sistem pada aplikasi web tersebut. Kemudian Anda berikan identitas tersebut peran pengguna rahasia Key Vault pada Vault Anda. Tidak ada string koneksi di kode, tidak ada klien secret di file konfigurasi. Aplikasi web melakukan autentikasi ke Key Vault menggunakan identitas terkelolanya dan Azure menangani semua manajemen kredensial di latar belakang. Ini adalah hal yang paling mendekati autentikasi tanpa kredensial di Azure.

Ini adalah terobosan bagi keamanan, karena menghilangkan vektor serangan paling umum, yaitu pencurian kredensial. Jika tidak ada kredensial untuk dicuri, tidak ada yang bisa dikompromikan oleh penyerang. Izinkan saya memberikan contoh dunianya. Bayangkan jalur data di Synapse yang perlu mengakses akun penyimpanan. Cara lama, Anda akan menyimpan kunci akun penyimpanan dalam konfigurasi jalur data. Jika seseorang mendapatkan akses ke jalur data itu, mereka memiliki kunci. Dengan identitas terkelola, ruang kerja Synapse memiliki identitas. Identitas itu diberi akses ke Key Vault tempat kunci akun penyimpanan disimpan. Jalur data mengambil kunci saat runtime, menggunakannya, dan tidak pernah menyimpannya di mana pun. Tidak ada kunci dalam kode, tidak ada rahasia dalam konfigurasi jalur data. Ketika Anda menggabungkan identitas terkelola dengan RBAC dan hak akses paling rendah, Anda mendapatkan fondasi aman untuk beban kerja Azure.

Aplikasi Anda melakukan autentikasi tanpa kredensial. Aplikasi tersebut hanya mengakses apa yang diperlukan, dan setiap akses dicatat dan dapat. Ini adalah pola yang direkomendasikan Microsoft untuk hampir setiap skenario. Setelah Anda mulai menggunakannya, Anda akan bertanya-tanya mengapa Anda pernah melakukan channel. Biaya dan strategi multifalk. Jadi, mari kita bicara tentang biaya. Di sinilah sebagian besar orang terkejut. Berapa sebenarnya biaya Azure Key Vault? Mode penetapan harganya sederhana. Tidak ada biaya penyimpanan perhasil. Anda tidak membayar untuk setiap kredensian di atau kunci api yang ada simp. Sebaliknya, Anda membayar per operasi. Untuk tingkat standar, biayanya sekitar 3 sen untuk setiap 10 ribu operasi. Panggilan untuk mendapatkan rahasia dihitung sebagai satu operasi. Begitu juga dengan membuat rahasia atau mencantumkan apa yang ada dalam. Untuk aplikasi kecil hingga menengah, jumlahnya hanya beberapa sen per bulan.

Beberapa sen? Bandikan itu dengan AWS Secrets Manager. Mereka mengenakan biaya 40 sen per rahasia per bulan hanya untuk menyimpannya ditambah biaya tambahan untuk panggilan api. Jika Anda memiliki 100 rahasia, itu berarti 40 hal per bulan bahkan sebelum Anda membaca satu. Dengan Azure Key Vault, 100 rahasia dengan penggunaan moderat mungkin hanya menghabiskan 15 sen. Perbedaannya berkembang yang cepat dalam skala. Ada tingkat premium. Ini menambahkan kunci berbasis HSM untuk beban kerja yang memerlukan tingkat jaminan kriptografi tertinggi. Bayangkan transaksi keuangan, data kesehatan, sistem pemerintah. Biaya per operasi lebih tinggi, sekitar 15 sen per 10 ribu operasi untuk jenis kunci. Lanjutan ditambah biaya bulanan per kunci HSM. Namun bagi sebagian besar aplikasi, tingkat standar sudah lebih dari cukup. Inilah kejutan biaya yang seringkali membuat orang tidak siap. Untuk aplikasi web biasa, dengan segelintir rahasia dan beberapa ribu operasi per bulan, key vault menghabiskan biaya kurang dari 1 dolar.

Anda akan menghabiskan lebih banyak uang untuk kopi yang dibindung saatnya. Namun, ada strategi yang lebih penting daripada biaya. Seberapa banyak vault yang ada? Pendekatan cerdasnya adalah strategi multi-vault. Gunakan vault terpisah untuk pengembangan, pengujian, staging, dan produksi. Ini mencegah kecelakaan yang paling umum terjadi. Seseorang menjalankan skrip uji yang secara tidak sengaja membaca basis data produksi karena string koneksinya berada di vault yang sama. Saat lingkungan dipisahkan, kesalahan tersebut menjadi mustahil terjadi. Anda juga harus memisahkan berdasarkan unit bisnis atau domain kepatu. Jika Anda menangani data kartu pembayaran, simpan rahasia tersebut di vault miliknya sendiri. Beban kerja bisnis umum di vault lain, data kesehatan di vault ketiga. Ini bukan tentang mempersulit, tetapi tentang membatasi dampak kerusakan. Jika satu vault disusupi, hanya rahasia di dalam vault itu yang terekspos.

Infrastruktur Anda yang lain tetap aman. Dan dua jaring pengaman bawaan yang harus selalu anaktif. Sob delete berarti jika seseorang menghampus rahasia, rahasia itu tidak hilang secara permanen. Rahasia tersebut masuk ke status yang dapat dipulihkan selama periode retensi yang Anda pilih hingga 90 hari. Bridge protection melangkah lebih jauh. Tidak seorang pun dapat menghapus vault atau isinya secara permanen sampai periode retensi berakhir. Bersama-sama, fitur ini mencegah jenis kehilangan data tak disengaja yang membuat tim keamanan sulit tidur. Bagaimana semuanya, Tuan? Mari kita rangkaian semua ini dan lihat bagaimana bagian-bagiannya saling. Key Vault bukanlah pula yang tersewas. Ini adalah sistem syarat pusat untuk rahasia dalam arsitektur Azure Anda. Saat Anda memahami bagaimana seluruh sistem mengalir, semuanya akan terasa masuk akal. Inilah yang terjadi ketika sebuah aplikasi memerlukan rahasia.

Aplikasi memintanya menggunakan identitas terkelolanya. Identitas tersebut sudah terdaftar di Enter ID. Azure membuatnya secara otomatis saat Anda mengaktifkan identitas terkelola pada sumber Rek. Enter ID memvalidasi bahwa identitas tersebut sah, lalu meneruskan permintaan ke key vault. Key vault memeriksa izin RBS yang telah Anda tetapkan. Jika identitas memiliki peran yang tepat, misalnya key vault secret user, rahasia akan dikembalikan. Semua ini terjadi dalam hitungan midgeting. Aplikasi tidak pernah melihat kredensial. Aplikasi tidak pernah menyimpan rahasia. Aplikasi yang tidak dibutuhkannya. Sekarang pikirkan berapa banyak layanan Azure yang bisa terhubung ke sini. App Service, Functions, AKS, Data Factory, Synapse, Logic Apps, DevOps, Pipeline, semuanya tahu. Cara berkomunikasi dengan key vault. Anda dapat mengonfigurasi aplikasi web untuk mereferensikan rahasia secara langsung di pengaturan aplikasinya.

Anda dapat menyiapkan pipeline data factory untuk mengambil kunci akun penyimpanan dari key vault saat rangta. Anda dapat mengonfigurasi kluster kubernetes untuk menarik rahasia menggunakan driver CSE key vault. Setiap layanan terintegrasi dengan cara yang sama. Menggunakan sistem identitas yang sama, peran RBAC yang sama, dan pencatatan audit yang sama. Pola CI plus CD sangatlah kuat. Pipelines Anda mengambil rahasia dari key vault saat waktu penerapan dibutuh. Mereka tidak pernah menyimpannya dalam variabel pipeline atau rahasia repositor. Jika Anda perlu merotasi kata sandi basis data, Anda cukup memperbaruinya di key vault. Saat pipeline Anda berjalan berikutnya, sistem akan mengambil nilai baru tersebut secara tenang. Tidak ada perubahan pipeline, tidak ada perubahan kode, tidak ada penerapan ulang. Inilah hal yang membuat semuanya masuk akal. Setelah Anda mengatur key vault dengan identitas terkelola dan RBAC, Anda tidak perlu lagi memikirkan manajemen kredensial.

Aplikasi Anda akan langsung berjalan. Rahasia diperbarui tanpa disadari oleh siak apa. Sertifikat diperbarui tanpa keadaan darurat dengan malam. Sistem menangani semuanya di latar belakang. Inilah postur keamanan yang sesungguhnya. Identitas adalah perimeter, bukan jaringan. Tidak masalah apakah seseorang berada di dalam jaringan virtual Anda atau di luar. Yang terpenting adalah apakah mereka memiliki identitas yang valid dengan izin yang tukar. Key vault memperlakukan hal ini secara desain. Setiap permintaan akses melalui autentikasi intra-ID dan otorisasi RBAC dari manapun permintaan itu berasal. Dan semuanya dicatat, setiap pembaca rahasia, setiap operasi kunci, setiap pengambilan sertifikat, Anda dapat melihat siapa yang mengakses aparan. Jika ada yang terlihat mencurigakan, Anda memiliki data untuk menyelidikinya. Ini sangat penting untuk kepatuhan, respons insiden, dan mengetahui apa yang terjadi di lingkungan Anda.

Itulah keindari semuanya. Key vault, intra-ID, RBAC, dan identitas terkelola bekerja bersama sebagai kerangka kerja keamanan yang terpadu. Setiap bagian memperkuat bagian lainnya. Dan ketika semuanya diatur dengan benar, Anda memiliki sistem manajemen kredensial yang lebih aman dan lebih mudah dioperasikan daripada yang bisa Anda bangun sendiri. Poin pentingnya dapat ditirin. Jadi apa yang harus Anda lakukan sekarang? Mari kita ubah pengetahuan ini menjadi tindak. Berikut adalah hal-hal yang dapat Anda kerjakan. Mulailah dengan model izin Anda. Buka key vault Anda di portal, buka konfigurasi akses, dan periksa apa yang tertulis di sana. Jika Anda melihat kebijakan akses vault-to-vaul akses polisi, itu adalah cara. Anda sebaiknya menggunakan kontrol akses berbasis peran Azure-Azure RBS. Negasi sangat sederhana. Ubah model izin dan tetapkan peran RBAC kepada orang yang sama yang sebelumnya memiliki kebijakan akses akun ini.

Microsoft merekomendasikannya, dan penelitian yang kita bahas menunjukkan alasan tepatnya. Selanjutnya, audit akun apapun yang menggang peran kontributor keyboard. Buka panel IAM di vault Anda dan lihat siapa saja yang memiliki akses kontributor. Setiap orang dengan peran tersebut harus memiliki alasan yang sebagian besar waktu mereka tidak melakukan. Ganti kontributor dengan sesuatu yang lebih spesifik. Jika seseorang hanya perlu membaca rahasia, berikan mereka key vault secrets user. Jika mereka perlu mengelola rahasia, gunakan key vault secrets officer. Tujuannya adalah menutup jalur eskalasi itu sepenuhnya. Kemudian manfaatkan identitas identiti. Setiap layanan Azure yang membutuhkan akses ke key vault harus menggunakannya. Jika Anda memiliki aplikasi web fungsi data factory atau mesin virtual yang masih menggunakan perwakilan layanan, dengan rahasia klien beralihlah ke manajat identiti.

Ini lebih sederhana, lebih aman, dan memicahkan masalah ayam dan telur yang kita bahas. Azure menangani pengelolaan kredensial untuk Anda di balik layar. Satu hal lagi, aktifkan penghapusan lunak dan perlindungan pembersihan di setiap vault. Penghapusan lunak aktif secara default untuk vault baru, tetapi perlindungan pembersihan tidak. Aktifkan pengaturan itu mencegah siapapun menghapus vault atau isinya secara permanen selama periode retensi. Setelah menyelamatkan lebih dari satu tim dari kesalahan yang fatal. Inilah ajakan untuk bertindak lagi. Lihat pendekatan pengelolaan rahasia Anda setelah. Temukan satu rahasia masih ada di file konfigurasi, variabel lingkungan, atau di hardcode dalam kode. Pindahkan ke key vault minggu ini. Hanya satu. Setelah Anda melihat betapa sederhananya hal itu, Anda akan sisanya. Keamanan bukanlah pengaturan sekali. Dari sebuah praktik. Key vault membuat praktik itu lebih mudah, tetapi hanya jika Anda menggunakannya yang benar.

Al-alannya sudah tersedia. Pola-pelanya sudah terbukti. Sekarang terserah Anda untuk menerapkannya. Itulah sistemnya. Key vault adalah berangkas digital Anda, tetapi hanya akan seaman kontrol akses yang Anda terapkan di sekitarnya. Mulai dengan audit yang baru saja saya jelaskan. Periksa model izin Anda, periksa penugasan kontributor Anda, dan pindahkan satu rahasia ke dalam vault minggu ini. Berlangganan untuk tips keamanan kode lainnya dalam bahasa yang sederhana, dan bagikan ini dengan seseorang yang masih menyimpan rahasia di file konfigurasi.