Enkripsi yang dapat dicari - AWS Enkripsi Database SDK
Apakah beacon tepat untuk dataset saya?Skenario enkripsi yang dapat dicari

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Enkripsi yang dapat dicari

Pustaka enkripsi sisi klien kami diubah namanya menjadi Enkripsi AWS Database. SDK Panduan pengembang ini masih memberikan informasi tentang Klien Enkripsi DynamoDB.

Enkripsi yang dapat dicari memungkinkan Anda untuk mencari catatan terenkripsi tanpa mendekripsi seluruh database. Ini dilakukan dengan menggunakan beacon, yang membuat peta antara nilai plaintext yang ditulis ke bidang dan nilai terenkripsi yang sebenarnya disimpan dalam database Anda. Enkripsi AWS Database SDK menyimpan suar di bidang baru yang ditambahkan ke catatan. Bergantung pada jenis suar yang Anda gunakan, Anda dapat melakukan penelusuran pencocokan persis atau kueri kompleks yang lebih disesuaikan pada data terenkripsi Anda.

catatan

Enkripsi yang dapat dicari dalam Enkripsi AWS Database SDK berbeda dari enkripsi simetris yang dapat dicari yang didefinisikan dalam penelitian akademis, seperti enkripsi simetris yang dapat dicari.

Beacon adalah tag Kode Otentikasi Pesan Berbasis Hash (HMAC) terpotong yang membuat peta antara plaintext dan nilai terenkripsi bidang. Saat Anda menulis nilai baru ke bidang terenkripsi yang dikonfigurasi untuk enkripsi yang dapat dicari, Enkripsi AWS Database SDK menghitung nilai teks biasaHMAC. HMACOutput ini adalah kecocokan satu-ke-satu (1:1) untuk nilai plaintext dari bidang itu. HMACOutputnya terpotong sehingga beberapa nilai plaintext yang berbeda dipetakan ke tag terpotong yang sama. HMAC Positif palsu ini membatasi kemampuan pengguna yang tidak sah untuk mengidentifikasi informasi yang membedakan tentang nilai plaintext. Saat Anda menanyakan suar, Enkripsi AWS Database SDK secara otomatis menyaring positif palsu ini dan mengembalikan hasil teks biasa dari kueri Anda.

Jumlah rata-rata positif palsu yang dihasilkan untuk setiap suar ditentukan oleh panjang suar yang tersisa setelah pemotongan. Untuk bantuan menentukan panjang suar yang sesuai untuk implementasi Anda, lihat Menentukan panjang suar.

catatan

Enkripsi yang dapat dicari dirancang untuk diimplementasikan dalam database baru yang tidak terisi. Setiap suar yang dikonfigurasi dalam database yang ada hanya akan memetakan catatan baru yang diunggah ke database, tidak ada cara bagi suar untuk memetakan data yang ada.

Topik

Apakah beacon tepat untuk dataset saya?

Menggunakan beacon untuk melakukan kueri pada data terenkripsi mengurangi biaya kinerja yang terkait dengan database terenkripsi sisi klien. Saat Anda menggunakan beacon, ada tradeoff yang melekat antara seberapa efisien kueri Anda dan seberapa banyak informasi yang terungkap tentang distribusi data Anda. Beacon tidak mengubah status lapangan yang dienkripsi. Saat Anda mengenkripsi dan menandatangani bidang dengan Enkripsi AWS DatabaseSDK, nilai plaintext dari bidang tersebut tidak pernah terpapar ke database. Basis data menyimpan nilai bidang yang dienkripsi secara acak.

Beacon disimpan di samping bidang terenkripsi tempat mereka dihitung. Ini berarti bahwa meskipun pengguna yang tidak sah tidak dapat melihat nilai teks biasa dari bidang terenkripsi, mereka mungkin dapat melakukan analisis statistik pada beacon untuk mempelajari lebih lanjut tentang distribusi kumpulan data Anda, dan, dalam kasus ekstrim, mengidentifikasi nilai teks biasa yang dipetakan oleh beacon. Cara Anda mengkonfigurasi beacon Anda dapat mengurangi risiko ini. Secara khusus, memilih panjang suar yang tepat dapat membantu Anda menjaga kerahasiaan kumpulan data Anda.

Keamanan vs Kinerja

  • Semakin pendek panjang suar, semakin banyak keamanan yang dipertahankan.

  • Semakin panjang panjang suar, semakin banyak kinerja yang dipertahankan.

Enkripsi yang dapat dicari mungkin tidak dapat memberikan tingkat kinerja dan keamanan yang diinginkan untuk semua kumpulan data. Tinjau model ancaman, persyaratan keamanan, dan kebutuhan kinerja Anda sebelum mengonfigurasi suar apa pun.

Pertimbangkan persyaratan keunikan kumpulan data berikut saat Anda menentukan apakah enkripsi yang dapat dicari tepat untuk kumpulan data Anda.

Distribusi

Jumlah keamanan yang dipertahankan oleh suar tergantung pada distribusi kumpulan data Anda. Saat Anda mengonfigurasi bidang terenkripsi untuk enkripsi yang dapat dicari, Enkripsi AWS Database SDK menghitung nilai teks biasa yang HMAC ditulis ke bidang tersebut. Semua beacon yang dihitung untuk bidang tertentu dihitung menggunakan kunci yang sama, dengan pengecualian database multitenant yang menggunakan kunci berbeda untuk setiap penyewa. Ini berarti bahwa jika nilai plaintext yang sama ditulis ke bidang beberapa kali, HMAC tag yang sama dibuat untuk setiap instance dari nilai plaintext tersebut.

Anda harus menghindari membangun beacon dari bidang yang berisi nilai yang sangat umum. Misalnya, pertimbangkan database yang menyimpan alamat setiap penduduk negara bagian Illinois. Jika Anda membangun suar dari City bidang terenkripsi, suar yang dihitung di atas “Chicago” akan terwakili secara berlebihan karena persentase besar populasi Illinois yang tinggal di Chicago. Bahkan jika pengguna yang tidak sah hanya dapat membaca nilai terenkripsi dan nilai suar, mereka mungkin dapat mengidentifikasi catatan mana yang berisi data untuk penduduk Chicago jika suar mempertahankan distribusi ini. Untuk meminimalkan jumlah informasi pembeda yang terungkap tentang distribusi Anda, Anda harus memotong suar Anda dengan cukup. Panjang suar yang diperlukan untuk menyembunyikan distribusi yang tidak merata ini memiliki biaya kinerja yang signifikan yang mungkin tidak memenuhi kebutuhan aplikasi Anda.

Anda harus hati-hati menganalisis distribusi dataset Anda untuk menentukan berapa banyak beacon Anda perlu dipotong. Panjang suar yang tersisa setelah pemotongan secara langsung berkorelasi dengan jumlah informasi statistik yang dapat diidentifikasi tentang distribusi Anda. Anda mungkin perlu memilih panjang suar yang lebih pendek untuk meminimalkan jumlah informasi pembeda yang terungkap tentang kumpulan data Anda.

Dalam kasus ekstrim, Anda tidak dapat menghitung panjang suar untuk kumpulan data terdistribusi tidak merata yang secara efektif menyeimbangkan kinerja dan keamanan. Misalnya, Anda tidak boleh membuat suar dari bidang yang menyimpan hasil tes medis untuk penyakit langka. Karena NEGATIVE hasil diharapkan secara signifikan lebih umum dalam kumpulan data, POSITIVE hasil dapat dengan mudah diidentifikasi dengan seberapa jarang hasilnya. Sangat menantang untuk menyembunyikan distribusi ketika bidang hanya memiliki dua nilai yang mungkin. Jika Anda menggunakan panjang suar yang cukup pendek untuk menyembunyikan distribusi, semua nilai plaintext dipetakan ke tag yang sama. HMAC Jika Anda menggunakan panjang suar yang lebih panjang, jelas beacon mana yang memetakan ke nilai teks biasa. POSITIVE

Korelasi

Kami sangat menyarankan agar Anda menghindari pembuatan beacon yang berbeda dari bidang dengan nilai yang berkorelasi. Beacon yang dibangun dari bidang berkorelasi memerlukan panjang suar yang lebih pendek untuk meminimalkan jumlah informasi yang terungkap tentang distribusi setiap kumpulan data ke pengguna yang tidak sah. Anda harus menganalisis kumpulan data Anda dengan cermat, termasuk entropi dan distribusi gabungan dari nilai yang berkorelasi, untuk menentukan berapa banyak beacon Anda perlu dipotong. Jika panjang suar yang dihasilkan tidak memenuhi kebutuhan kinerja Anda, maka beacon mungkin tidak cocok untuk kumpulan data Anda.

Misalnya, Anda tidak boleh membuat dua beacon terpisah dari City dan ZIPCode bidang karena ZIP kode kemungkinan akan dikaitkan dengan hanya satu kota. Biasanya, positif palsu yang dihasilkan oleh suar membatasi kemampuan pengguna yang tidak sah untuk mengidentifikasi informasi yang membedakan tentang kumpulan data Anda. Tetapi korelasi antara ZIPCode bidang City dan berarti bahwa pengguna yang tidak sah dapat dengan mudah mengidentifikasi hasil mana yang positif palsu dan membedakan kode yang berbeda. ZIP

Anda juga harus menghindari pembuatan beacon dari bidang yang berisi nilai plaintext yang sama. Misalnya, Anda tidak boleh membuat suar dari mobilePhone dan preferredPhone bidang karena kemungkinan memiliki nilai yang sama. Jika Anda membuat beacon yang berbeda dari kedua bidang, Enkripsi AWS Database SDK membuat beacon untuk setiap bidang di bawah kunci yang berbeda. Ini menghasilkan dua HMAC tag berbeda untuk nilai plaintext yang sama. Dua beacon yang berbeda tidak mungkin memiliki positif palsu yang sama dan pengguna yang tidak sah mungkin dapat membedakan nomor telepon yang berbeda.

Bahkan jika kumpulan data Anda berisi bidang yang berkorelasi atau memiliki distribusi yang tidak merata, Anda mungkin dapat membangun beacon yang menjaga kerahasiaan kumpulan data Anda dengan menggunakan panjang suar yang lebih pendek. Namun, panjang suar tidak menjamin bahwa setiap nilai unik dalam kumpulan data Anda akan menghasilkan sejumlah positif palsu yang secara efektif meminimalkan jumlah informasi pembeda yang terungkap tentang kumpulan data Anda. Panjang suar hanya memperkirakan jumlah rata-rata positif palsu yang dihasilkan. Semakin terdistribusi kumpulan data Anda secara tidak merata, panjang suar yang kurang efektif dalam menentukan jumlah rata-rata positif palsu yang dihasilkan.

Pertimbangkan dengan cermat distribusi bidang tempat Anda membangun suar dan pertimbangkan berapa banyak yang Anda perlukan untuk memotong panjang suar untuk memenuhi persyaratan keamanan Anda. Topik-topik berikut dalam Bab ini mengasumsikan bahwa beacon Anda didistribusikan secara seragam dan tidak mengandung data yang berkorelasi.

Skenario enkripsi yang dapat dicari

Contoh berikut menunjukkan solusi enkripsi yang dapat dicari sederhana. Dalam aplikasi, bidang contoh yang digunakan dalam contoh ini mungkin tidak memenuhi rekomendasi keunikan distribusi dan korelasi untuk beacon. Anda dapat menggunakan contoh ini untuk referensi saat Anda membaca tentang konsep enkripsi yang dapat dicari di bagian ini.

Pertimbangkan database bernama Employees yang melacak data karyawan untuk perusahaan. Setiap record dalam database berisi bidang yang disebut EmployeeId LastName, FirstName, dan Address. Setiap bidang dalam Employees database diidentifikasi oleh kunci utamaEmployeeID.

Berikut ini adalah contoh catatan plaintext dalam database.

{
    "EmployeeID": 101,
    "LastName": "Jones",
    "FirstName": "Mary",
    "Address": {
                "Street": "123 Main",
                "City": "Anytown",
                "State": "OH",
                "ZIPCode": 12345
    }
}

Jika Anda menandai LastName dan FirstName bidang seperti ENCRYPT_AND_SIGN dalam tindakan kriptografi Anda, nilai dalam bidang ini dienkripsi secara lokal sebelum diunggah ke database. Data terenkripsi yang diunggah sepenuhnya acak, database tidak mengenali data ini sebagai dilindungi. Itu hanya mendeteksi entri data yang khas. Ini berarti bahwa catatan yang sebenarnya disimpan dalam database mungkin terlihat seperti berikut.

{
    "PersonID": 101,
    "LastName": "1d76e94a2063578637d51371b363c9682bad926cbd",
    "FirstName": "21d6d54b0aaabc411e9f9b34b6d53aa4ef3b0a35",
    "Address": {
                "Street": "123 Main",
                "City": "Anytown",
                "State": "OH",
                "ZIPCode": 12345
    }
}

Jika Anda perlu menanyakan database untuk kecocokan persis di LastName bidang, konfigurasikan suar standar bernama LastNameuntuk memetakan nilai teks biasa yang ditulis ke LastName bidang ke nilai terenkripsi yang disimpan dalam database.

Beacon ini menghitung HMACs dari nilai plaintext di lapangan. LastName Setiap HMAC output terpotong sehingga tidak lagi cocok dengan nilai plaintext. Misalnya, hash lengkap dan hash terpotong untuk Jones mungkin terlihat seperti berikut ini.

Hash lengkap

2aa4e9b404c68182562b6ec761fcca5306de527826a69468885e59dc36d0c3f824bdd44cab45526f70a2a18322000264f5451acf75f9f817e2b35099d408c833

Hash terpotong

b35099d408c833

Setelah suar standar dikonfigurasi, Anda dapat melakukan pencarian kesetaraan di lapangan. LastName Misalnya, jika Anda ingin mencariJones, gunakan LastNamesuar untuk melakukan kueri berikut.

LastName = Jones

Enkripsi AWS Database SDK secara otomatis menyaring positif palsu dan mengembalikan hasil plaintext dari kueri Anda.