Bagikan melalui


Enkripsi sisi klien untuk antrean

Pustaka klien Azure Queue Storage untuk .NET dan Python mendukung enkripsi data dalam aplikasi klien sebelum mengunggah ke Azure Storage, dan mendekripsi data saat mengunduh ke klien. Pustaka klien juga mendukung integrasi dengan Azure Key Vault untuk manajemen kunci akun penyimpanan.

Penting

Azure Storage mendukung enkripsi sisi layanan dan sisi klien. Untuk sebagian besar skenario, Microsoft merekomendasikan penggunaan fitur enkripsi sisi layanan untuk kemudahan penggunaan dalam melindungi data Anda. Untuk mempelajari selengkapnya tentang enkripsi sisi layanan, lihat Enkripsi Azure Storage untuk data tidak aktif.

Tentang enkripsi sisi klien

Pustaka klien Azure Queue Storage menggunakan AES untuk mengenkripsi data pengguna. Ada dua versi enkripsi sisi klien yang tersedia di pustaka klien:

Peringatan

Menggunakan versi 1 enkripsi sisi klien tidak lagi disarankan karena kerentanan keamanan dalam penerapan mode CBC pustaka klien. Untuk informasi selengkapnya tentang kerentanan keamanan ini, lihat Azure Storage memperbarui enkripsi sisi klien di SDK untuk mengatasi kerentanan keamanan. Jika saat ini menggunakan versi 1, sebaiknya perbarui aplikasi Anda untuk menggunakan versi 2 dan migrasikan data Anda. Lihat bagian berikut, Mengurangi kerentanan keamanan di aplikasi Anda, untuk panduan selengkapnya.

Mengurangi kerentanan keamanan di aplikasi Anda

Karena kerentanan keamanan yang ditemukan dalam penerapan mode CBC pustaka klien Queue Storage, Microsoft menyarankan Anda untuk segera melakukan satu atau beberapa tindakan berikut:

  • Pertimbangkan untuk menggunakan fitur enkripsi sisi layanan, bukan enkripsi sisi klien. Untuk informasi selengkapnya tentang fitur enkripsi sisi layanan, lihat Enkripsi Azure Storage untuk data tidak aktif.

  • Jika Anda perlu menggunakan enkripsi sisi klien, migrasikan aplikasi Anda dari enkripsi sisi klien v1 ke enkripsi sisi klien v2.

Tabel berikut ini meringkas langkah-langkah yang perlu Anda ambil jika Anda memilih untuk memigrasikan aplikasi Anda ke enkripsi sisi klien v2:

Status enkripsi sisi klien Tindakan yang disarankan
Aplikasi menggunakan enkripsi sisi klien versi pustaka klien yang hanya mendukung enkripsi sisi klien v1. Perbarui aplikasi Anda untuk menggunakan versi pustaka klien yang mendukung enkripsi sisi klien v2. Lihat Matriks dukungan SDK untuk enkripsi sisi klien untuk daftar versi yang didukung.

Perbarui kode Anda untuk menggunakan enkripsi sisi klien v2.
Aplikasi menggunakan enkripsi sisi klien dengan versi pustaka klien yang mendukung enkripsi sisi klien v2. Perbarui kode Anda untuk menggunakan enkripsi sisi klien v2.

Selain itu, Microsoft menyarankan Anda mengambil langkah-langkah berikut untuk membantu mengamankan data:

  • Konfigurasikan akun penyimpanan Anda untuk menggunakan titik akhir privat guna mengamankan semua lalu lintas antara jaringan virtual (VNet) dan akun penyimpanan Anda melalui tautan pribadi. Untuk informasi selengkapnya, lihat Menggunakan titik akhir privat untuk Azure Storage.
  • Batasi akses jaringan ke jaringan tertentu saja.

Matriks dukungan SDK untuk enkripsi sisi klien

Tabel berikut menunjukkan versi pustaka klien untuk .NET dan Python yang mendukung versi enkripsi sisi klien:

.NET Python
Enkripsi sisi klien v2 dan v1 Versi 12.11.0 dan yang lebih baru Versi 12.4.0 dan yang lebih baru
Khusus enkripsi sisi klien v1 Versi 12.10.0 dan sebelumnya Versi 12.3.0 dan sebelumnya

Jika aplikasi Anda menggunakan enkripsi sisi klien dengan versi pustaka klien .NET atau Python sebelumnya, Anda harus terlebih dahulu meningkatkan kode Anda ke versi yang mendukung enkripsi sisi klien v2. Selanjutnya, Anda harus mendekripsi dan mengenkripsi ulang data dengan enkripsi sisi klien v2. Jika perlu, Anda dapat menggunakan versi pustaka klien yang mendukung enkripsi sisi klien v2 secara berdampingan dengan versi pustaka klien yang lebih lama saat Anda memigrasikan kode Anda.

Cara kerja enkripsi sisi klien

Pustaka klien Azure Queue Storage menggunakan enkripsi amplop untuk mengenkripsi dan mendekripsi data Anda di sisi klien. Enkripsi amplop mengenkripsi kunci dengan satu atau beberapa kunci tambahan.

Pustaka klien Queue Storage mengandalkan Azure Key Vault guna melindungi kunci yang digunakan untuk enkripsi sisi klien. Untuk mengetahui informasi selengkapnya tentang Azure Key Vault, lihat Apa itu Azure Key Vault?.

Enkripsi dan dekripsi melalui teknik amplop

Teknik enkripsi melalui amplop bekerja sebagai berikut:

  1. Pustaka klien Azure Storage menghasilkan kunci enkripsi konten (CEK), yang merupakan kunci simetris sekali pakai.

  2. Data pengguna dienkripsi menggunakan CEK.

  3. CEK kemudian dibungkus (dienkripsi) menggunakan kunci enkripsi kunci (KEK). KEK diidentifikasi oleh pengidentifikasi kunci dan dapat berupa pasangan kunci asimetris atau kunci simetris. Anda dapat mengelola KEK secara lokal atau menyimpannya di Azure Key Vault.

    Pustaka klien Azure Storage sendiri tidak pernah memiliki akses ke KEK. Pustaka tersebut hanya memanggil algoritma pembungkus kunci yang disediakan oleh Key Vault. Pelanggan dapat memilih untuk menggunakan penyedia layanan kustom untuk pembungkusan/pembongkaran jika ingin.

  4. Data terenkripsi kemudian diunggah ke Azure Queue Storage. Kunci yang dibungkus bersama dengan beberapa metadata enkripsi tambahan diinterpolasi dengan data terenkripsi.

Teknik dekripsi melalui amplop bekerja sebagai berikut:

  1. Pustaka klien Azure Storage mengasumsikan bahwa pengguna mengelola KEK baik secara lokal atau di Azure Key Vault. Pengguna tidak perlu mengetahui kunci spesifik yang digunakan untuk enkripsi. Sebagai gantinya, pemecah kunci yang menyelesaikan pengidentifikasi kunci yang berbeda ke kunci dapat diatur dan digunakan.
  2. Pustaka klien mengunduh data terenkripsi bersama dengan materi enkripsi apa pun yang disimpan di Azure Storage.
  3. CEK yang dibungkus) kemudian dibuka (didekripsi) menggunakan KEK. Pustaka klien tidak memiliki akses ke KEK selama proses ini, tetapi hanya memanggil algoritma pembukaan Azure Key Vault atau penyimpanan kunci lainnya.
  4. Pustaka klien menggunakan CEK untuk mendekripsi data pengguna terenkripsi.

Enkripsi/dekripsi pesan

Karena pesan antrean dapat berformat apa pun, pustaka klien menentukan format kustom yang menyertakan Vektor Inisialisasi (IV) dan kunci enkripsi konten (CEK) terenkripsi dalam teks pesan.

Selama enkripsi, pustaka klien menghasilkan IV acak 16 byte bersama dengan CEK acak 32 byte dan melakukan enkripsi amplop teks pesan antrean menggunakan informasi ini. CEK yang dibungkus dan beberapa metadata enkripsi tambahan lalu ditambahkan ke pesan antrean terenkripsi. Pesan yang dimodifikasi ini disimpan pada layanan.

<MessageText>{"EncryptedMessageContents":"6kOu8Rq1C3+M1QO4alKLmWthWXSmHV3mEfxBAgP9QGTU++MKn2uPq3t2UjF1DO6w","EncryptionData":{…}}</MessageText>

Selama dekripsi, kunci yang dibungkus diekstrak dari pesan antrean dan dibongkar. IV juga diekstrak dari pesan antrean dan digunakan bersama dengan kunci terbongkar untuk mendekripsi data pesan antrean. Metadata enkripsi kecil (di bawah 500 byte), jadi meskipun dihitung terhadap batas 64 KB untuk pesan antrean, dampaknya harus dapat dikelola. Pesan terenkripsi dikodekan Base64, seperti yang ditunjukkan pada cuplikan di atas, yang memperluas ukuran pesan yang dikirim.

Karena sifat pesan berumur pendek dalam antrean, mendekripsi dan mendekripsi ulang pesan antrean setelah memperbarui ke enkripsi sisi klien v2 seharusnya tidak diperlukan. Setiap pesan yang kurang aman diputar selama konsumsi antrean normal.

Enkripsi dan performa sisi klien

Ingatlah bahwa mengenkripsi data penyimpanan Anda menghasilkan overhead performa tambahan. Saat menggunakan enkripsi sisi klien dalam aplikasi Anda, pustaka klien harus membuat CEK dan IV dengan aman, mengenkripsi konten itu sendiri, berkomunikasi dengan keystore pilihan Anda untuk pembungkusan kunci, dan memformat serta mengunggah metadata tambahan. Overhead ini bervariasi tergantung pada jumlah data yang dienkripsi. Kami menyarankan agar pelanggan selalu menguji performa aplikasi selama pengembangan.

Langkah berikutnya