Bagikan melalui

Enkripsi dengan kunci yang dikelola pelanggan di Microsoft Cloud for Sovereignty

  • Artikel

Pelanggan yang berencana untuk menerapkan Microsoft Cloud for Sovereignty mungkin memerlukan penggunaan fitur enkripsi data untuk memenuhi persyaratan kedaulatan data. Pelanggan dengan persyaratan kedaulatan data yang ketat harus mengembangkan rencana untuk menerapkan manajemen kunci di cloud. Artikel ini memandu arsitek cloud, pemilik sistem kriptografi, dan pembuat keputusan teknis lainnya untuk mengembangkan rencana penerapan enkripsi tingkat platform di Azure. Perencanaan untuk enkripsi di tingkat platform biasanya melibatkan identifikasi persyaratan manajemen utama, membuat pilihan teknologi, dan memilih desain dan pilihan konfigurasi untuk layanan Azure yang akan digunakan. Proses ini melibatkan pengambilan keputusan teknis di tiga domain:

  • Tentukan persyaratan manajemen utama: Apa yang perlu dilakukan organisasi Anda untuk melindungi data pelanggan yang sensitif dan materi kriptografi yang sensitif?
  • Pilih fitur enkripsi data untuk melindungi data pelanggan: Bagaimana, di mana, dan kapan Anda harus mengenkripsi data pelanggan di Azure?
  • Pilih solusi manajemen kunci untuk melindungi kunci pelanggan: Penyimpanan kunci apa yang harus Anda gunakan untuk melindungi kunci enkripsi data yang digunakan untuk mengenkripsi data pelanggan di Azure?

Menentukan persyaratan manajemen utama

Persyaratan untuk manajemen kunci dapat mencakup persyaratan teknis tentang layanan kriptografi yang digunakan dan persyaratan operasional yang terkait dengan kinerja, keamanan, dan kedaulatan. Titik awal yang direkomendasikan untuk membuat keputusan tentang kapan dan bagaimana mengenkripsi data dalam beban kerja Azure adalah sistem klasifikasi data organisasi. Dengan menyelaraskan persyaratan enkripsi dengan klasifikasi data, daripada sistem atau solusi tertentu, organisasi memiliki lebih banyak fleksibilitas untuk memilih tingkat enkripsi optimal selama perencanaan migrasi beban kerja.

Mendasarkan persyaratan enkripsi pada klasifikasi data juga memungkinkan pendekatan berjenjang, di mana beban kerja dengan kekritisan yang lebih rendah dapat memanfaatkan solusi yang lebih sederhana sambil memesan konfigurasi paling kompleks untuk beban kerja dengan tingkat risiko bawaan yang lebih tinggi. Contoh dari pendekatan ini adalah mengizinkan penggunaan kunci yang dikelola Microsoft untuk mengenkripsi akun penyimpanan untuk lingkungan pengembangan sambil mengharuskan akun penyimpanan produksi untuk menggunakan kunci enkripsi yang dikelola Pelanggan.

Setelah organisasi memahami dengan jelas bagaimana persyaratan enkripsi mereka terkait dengan klasifikasi data mereka, mereka dapat memulai proses pemilihan fitur untuk layanan Azure yang akan mereka konsumsi. Beberapa fitur ini dapat beroperasi secara berbeda dari sistem lokal serupa, sehingga organisasi didorong untuk membiasakan diri dengan cara kerja enkripsi di Azure dan meninjau rekomendasi dan praktik terbaik untuk merancang solusi enkripsi. Artikel berikut memberikan perspektif tambahan tentang beberapa pilihan teknis yang perlu dibuat pelanggan dan dapat menjadi titik awal yang berguna untuk memulai percakapan tentang tujuan manajemen kunci cloud organisasi.

Pilih fitur enkripsi data

Banyak layanan Azure memungkinkan enkripsi menggunakan kunci yang dihasilkan, disimpan, dan dikelola sepenuhnya oleh Azure, tanpa interaksi pelanggan. Kunci yang Dikelola Platform ini dapat membantu organisasi menerapkan enkripsi dengan sedikit overhead operasional. Namun, pelanggan dengan persyaratan kedaulatan data yang ketat mungkin perlu memilih fitur enkripsi platform tertentu untuk melindungi data sensitif saat tidak aktif di layanan Azure tertentu.

Untuk data yang sangat sensitif, banyak layanan Azure yang umum digunakan memungkinkan pelanggan menerapkan enkripsi ganda menggunakan Kunci yang Dikelola Pelanggan (CMK). Menerapkan kunci yang dikelola pelanggan di layanan Azure dapat membantu pelanggan melindungi data yang disimpan di layanan tersebut dari akses yang tidak sah.

Menerapkan kunci yang dikelola pelanggan di Azure dapat meningkatkan biaya dan kompleksitas beban kerja, sehingga organisasi didorong untuk mengevaluasi kebutuhan fitur ini untuk setiap beban kerja dan tingkat klasifikasi data. Menerapkan kunci yang dikelola pelanggan hanya untuk beban kerja dan tipe data yang memerlukannya dapat membantu mengurangi overhead operasional untuk beban kerja yang tidak menangani data sensitif.

Jika Kunci yang Dikelola Pelanggan diperlukan, kunci tersebut harus dikonfigurasi untuk setiap layanan Azure masing-masing. Organisasi dapat membantu merampingkan upaya perencanaan penyebaran atau migrasi dengan menetapkan standar di seluruh organisasi dan pola desain berulang untuk menerapkan fitur ini. Artikel berikut ini menyediakan informasi selengkapnya tentang cara enkripsi data tidak aktif dikonfigurasi di Azure:

Pelajari cara mengonfigurasi layanan Azure yang umum digunakan untuk mengenkripsi data tidak aktif menggunakan kunci yang Dikelola Pelanggan:

Pilih solusi manajemen utama

Sementara fitur seperti enkripsi ganda dengan kunci yang dikelola pelanggan dapat membantu melindungi data pelanggan yang dipertahankan dalam layanan Azure, solusi manajemen kunci berbasis cloud membantu melindungi kunci enkripsi dan materi kriptografi lainnya yang digunakan untuk mengenkripsi data sensitif. Pelanggan dengan persyaratan kedaulatan data yang ketat harus memilih solusi manajemen kunci yang sesuai berdasarkan kebutuhan jaminan mereka dan profil risiko beban kerja mereka.

Beban kerja yang menangani data sensitif mungkin mendapat manfaat dari jaminan tambahan yang disediakan oleh solusi seperti yang disediakan Azure Managed HSM, termasuk modul keamanan perangkat keras tervalidasi FIPS-140-2 Level-3 yang menampilkan kontrol keamanan ekstra untuk melindungi materi kriptografi yang disimpan.

Artikel berikut memberikan panduan yang dapat digunakan pelanggan untuk memilih penyimpanan kunci yang sesuai untuk skenario yang teridentifikasi. Ini juga memberikan informasi tentang bagaimana Microsoft mengelola layanan kriptografi yang digunakan oleh pelanggan sebagai bagian dari solusi enkripsi mereka.

Model operasi untuk manajemen kunci

Azure Key Vault menerapkan kontrol akses berbasis peran dengan cara yang berbeda, tergantung pada apakah Anda menggunakan tingkat Standar/Premium Azure Key Vault atau Azure Key Vault Managed HSM. Perbedaan dalam kontrol akses ini dapat memengaruhi cara organisasi menggunakan fitur ini. Bagian ini menjelaskan perbedaan-perbedaan ini, dan bagaimana mereka dapat memengaruhi cara organisasi memilih untuk merancang proses operasional mereka untuk manajemen kunci cloud.

Batasan kepatuhan untuk validasi FIPS-140 Level-3

FIPS-140 Validasi level-3 memerlukan identifikasi operator berbasis identitas. Perlindungan ini disebarkan dan divalidasi dalam perangkat keras HSM yang mendasari yang mendukung layanan Key Vault di Azure. Akibatnya, fitur RBAC di Azure Key Vault bergantung pada kemampuan RBAC dari perangkat keras yang mendasarinya.

Azure Key Vault Managed HSM memanfaatkan penugasan RBAC lokal yang diterapkan di tingkat perangkat keras dan memungkinkan penetapan peran di lingkup domain keamanan (misalnya, lebar HSM) atau per kunci. Ini berarti bahwa pembuatan kunci memerlukan izin administratif atas seluruh domain keamanan, karena izin tidak dapat ditetapkan untuk kunci yang belum ada. Dampak dari desain ini adalah bahwa siapa pun yang perlu menyimpan kunci dalam instance mHSM harus memiliki izin penuh untuk semua kunci yang disimpan dalam domain keamanan tersebut, atau meminta kunci dari tim terpusat yang memiliki izin yang diperlukan tersebut melalui domain keamanan. Ini merupakan pergeseran dari panduan untuk Azure Key Vault yang merekomendasikan pembuatan brankas kunci terpisah untuk setiap aplikasi.

Operasi manajemen kunci di Azure Key Vault Azure Managed HSM

Untuk mengembangkan proses operasional untuk manajemen kunci, pelanggan harus menentukan apakah mereka memerlukan Azure Key Vault Managed HSM sebagai bagian dari arsitektur solusi mereka. Organisasi yang berencana untuk menggunakan HSM terkelola harus terlebih dahulu membiasakan diri dengan model kontrol akses yang digunakan untuk operasi administrasi dan kriptografi, dan memahami bagaimana kontrol akses berbasis peran ditetapkan.

Pelajari selengkapnya tentang kontrol akses di Azure Managed HSM:

Organisasi yang berencana menggunakan Azure Key Vault HSM harus meninjau daftar peran RBAC bawaan dan operasi yang diizinkan untuk Azure Managed HSM dan secara khusus merencanakan untuk menangani skenario operasi berikut:

  • Pembuatan kunci baru dalam Azure Managed HSM
  • Operasi manajemen kunci yang ada menggunakan bidang kontrol, seperti pembaruan kunci atau rotasi kunci
  • Penggunaan data plane dari kunci yang ada oleh aplikasi atau layanan

Saat ini, satu-satunya cara untuk menetapkan izin untuk membuat kunci baru adalah dengan menetapkan peran seperti Crypto User itu juga mencakup izin lain seperti rotasi dan penghapusan kunci. Akibatnya, memberikan izin yang diperlukan kepada anggota tim aplikasi untuk membuat kunci mereka sendiri di Azure Managed HSM kemungkinan dapat melanggar prinsip hak istimewa paling sedikit, karena pengguna tersebut juga akan memiliki izin administratif untuk semua kunci di HSM. Masalah ini dapat diselesaikan dengan memperkenalkan tim terpusat dengan izin yang ditingkatkan yang dapat memfasilitasi permintaan pembuatan kunci, atau memperkenalkan otomatisasi yang dapat memfasilitasi permintaan pembuatan kunci baru melalui proses manajemen layanan TI yang memanfaatkan REST API Azure Managed HSM.

Konten terkait