View a markdown version of this page

Enkripsi yang dapat dicari - AWS SDK Enkripsi Basis Data
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 SDK Enkripsi AWS Database. 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. AWS Database Encryption SDK menyimpan beacon 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 SDK Enkripsi AWS Database berbeda dari enkripsi simetris yang dapat dicari yang didefinisikan dalam penelitian akademis, seperti enkripsi simetris yang dapat dicari.

Beacon adalah tag Kode Otentikasi Hash-Based Pesan (HMAC) terpotong yang memetakan nilai bidang teks biasa ke pengenal terenkripsi dan dapat dicari. Saat Anda menulis nilai ke bidang terenkripsi yang dikonfigurasi untuk enkripsi yang dapat dicari, SDK Enkripsi AWS Database menghitung HMAC di atas nilai teks biasa. Output HMAC ini adalah kecocokan satu-ke-satu (1:1) untuk nilai plaintext dari bidang itu. SDK sengaja memotong output HMAC sehingga beberapa nilai plaintext yang berbeda bertabrakan pada suar yang sama. Tabrakan ini (positif palsu) membatasi kemampuan pengguna yang tidak sah untuk menyimpulkan informasi sensitif dari pola frekuensi. Saat Anda menanyakan suar, SDK Enkripsi AWS Database secara otomatis menyaring positif palsu ini dan mengembalikan hasil teks biasa dari kueri Anda. Untuk mengatasi lebih lanjut masalah kebocoran frekuensi ini, beacon dipartisi, memungkinkan nilai plaintext identik untuk menghasilkan nilai beacon yang berbeda di seluruh partisi. Ketika tabel hanya menggunakan satu partisi, perilaku ini secara alami cocok dengan beacon tradisional yang tidak dipartisi.

Jumlah rata-rata positif palsu untuk setiap suar tergantung pada panjang suar yang tersisa setelah pemotongan dan jumlah partisi. 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 AWS Database Encryption SDK, nilai plaintext 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. Konfigurasi suar yang tepat sangat penting untuk mengurangi risiko ini. Memilih panjang suar yang sesuai dan skema partisi menjaga kerahasiaan dengan memastikan tabrakan yang cukup dan mengurangi serangan berbasis frekuensi dengan membatasi konsentrasi nilai dalam setiap suar tunggal.

Keamanan vs Kinerja

  • Panjang suar yang lebih pendek dan jumlah partisi yang lebih tinggi meningkatkan keamanan dengan meningkatkan tabrakan dan mengurangi kebocoran frekuensi,

  • Panjang suar yang lebih panjang dan partisi yang lebih sedikit meningkatkan kinerja dengan mengurangi positif palsu dan penggemar kueri.

Dalam banyak skenario praktis, konfigurasi yang dipilih dengan baik dapat menyeimbangkan tujuan yang bersaing ini. Namun, enkripsi yang dapat dicari mungkin tidak dapat memberikan tingkat keamanan dan kinerja yang diinginkan untuk setiap kumpulan data.

Sebelum mengonfigurasi suar apa pun, tinjau model ancaman, persyaratan keamanan, dan kebutuhan kinerja Anda dengan cermat, dan pertimbangkan karakteristik keunikan kumpulan data Anda untuk menentukan apakah enkripsi yang dapat dicari adalah pilihan yang tepat.

Distribusi

Properti keamanan beacon bergantung pada distribusi data yang mendasarinya dan bagaimana suar dikonfigurasi, termasuk berapa banyak partisi yang digunakan. Saat Anda mengonfigurasi bidang terenkripsi untuk enkripsi yang dapat dicari, SDK Enkripsi AWS Database menghitung HMAC atas setiap nilai teks biasa yang ditulis ke bidang itu dan memperoleh suar menggunakan kunci kriptografi. Beacon dihitung dalam konteks partisi, yang memungkinkan nilai plaintext identik untuk menghasilkan nilai beacon yang berbeda di seluruh partisi. Ketika tabel hanya menggunakan satu partisi, nilai plaintext identik selalu memetakan ke tag HMAC terpotong yang sama, yang dapat mempertahankan pola frekuensi dari kumpulan data asli.

Bidang dengan distribusi yang sangat miring membutuhkan perawatan khusus. Misalnya, pertimbangkan database yang menyimpan kota tempat tinggal untuk semua penduduk Illinois. Jika Anda membangun suar dari City bidang terenkripsi, nilai “Chicago” akan terjadi jauh lebih sering daripada kota-kota lain. Bahkan jika pengguna yang tidak sah hanya dapat mengakses item terenkripsi dan nilai suar, ketidakseimbangan ini memungkinkan mereka untuk menyimpulkan catatan mana yang sesuai dengan penduduk Chicago dengan mengamati suar yang terwakili secara berlebihan. Memotong suar dapat mengurangi kebocoran ini dengan memaksa lebih banyak tabrakan, tetapi panjang suar yang diperlukan untuk menyembunyikan kemiringan yang cukup parah dapat menyebabkan kinerja overhead yang signifikan karena peningkatan positif palsu.

Untuk mengkonfigurasi beacon dengan aman, Anda harus menganalisis distribusi frekuensi data Anda dan memahami bagaimana pemotongan dan partisi berinteraksi. Jumlah bit yang disimpan dalam suar menentukan berapa banyak informasi statistik yang diekspos, sedangkan jumlah partisi membatasi seberapa terkonsentrasi nilai suar tunggal dapat menjadi. Panjang suar yang lebih pendek dan lebih banyak partisi mengurangi kebocoran frekuensi tetapi meningkatkan positif palsu dan kipas kueri. Panjang suar yang lebih panjang dan partisi yang lebih sedikit meningkatkan efisiensi kueri tetapi mengekspos lebih banyak informasi tentang distribusi yang mendasarinya.

Dalam beberapa kasus ekstrim, beban kerja tidak layak ketika tabel hanya menggunakan satu partisi. Atribut dengan populasi yang sangat kecil atau hasil biner yang sangat tidak seimbang—seperti hasil tes medis di mana nilai NEGATIF mendominasi — tidak dapat dilindungi dengan menggunakan pemotongan saja. Dengan satu partisi, suar yang cukup pendek untuk menyembunyikan distribusi menciutkan semua nilai menjadi satu tag, sementara suar yang lebih panjang membuat nilai langka mudah diidentifikasi. Dalam kasus ini, beacon yang dipartisi diperlukan untuk membuat enkripsi yang dapat dicari menjadi layak. Dengan mendistribusikan nilai yang terlalu terwakili di beberapa partisi, pendekatan ini mengurangi ukuran kelas ekivalensi dan membatasi kebocoran frekuensi dengan cara yang tidak mungkin dilakukan saat menggunakan satu partisi.

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 kode ZIP 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 ZIP yang berbeda.

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, AWS Database Encryption SDK akan membuat beacon untuk setiap bidang di bawah kunci yang berbeda. Ini menghasilkan dua tag HMAC yang 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.

Hati-hati mengevaluasi distribusi bidang yang Anda pilih untuk mercusuar dan tentukan berapa banyak pemotongan yang diperlukan untuk memenuhi persyaratan keamanan Anda. Topik-topik berikut dalam Bab ini mengasumsikan bahwa, dalam setiap partisi, nilai beacon didistribusikan secara seragam dan bahwa data yang mendasarinya tidak memperkenalkan korelasi yang akan melemahkan asumsi ini.

Skenario enkripsi yang dapat dicari

Contoh berikut menunjukkan solusi enkripsi yang dapat dicari dan menggambarkan konsep inti yang dibahas dalam Bab ini. Dalam skenario ini, nilai bidang tertentu terjadi sangat sering, yang akan menyebabkan kelas ekivalensi besar dan peningkatan kebocoran frekuensi jika satu partisi digunakan. Untuk mengatasi hal ini, konfigurasi menggunakan beberapa partisi sehingga nilai yang sangat sering didistribusikan lebih merata, mengurangi kebocoran sambil mempertahankan kemampuan untuk melakukan pencarian kesetaraan yang efisien.

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 HMAC dari nilai plaintext di lapangan. LastName Setiap output HMAC 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

Dalam kumpulan data dengan banyak karyawan, nama belakang tertentu seperti Jones, Smith, atau Johnson mungkin muncul jauh lebih sering daripada yang lain. Untuk mengurangi kebocoran frekuensi dan membatasi ukuran kelas kesetaraan suar, Anda harus mengkonfigurasi LastNamesuar untuk menggunakan lebih dari satu partisi.

Ketika partisi diaktifkan, setiap item ditugaskan ke partisi pada waktu penulisan, dan nomor partisi dimasukkan ke dalam derivasi suar. Akibatnya, karyawan dengan nama belakang yang sama dapat memetakan ke nilai suar yang berbeda di seluruh partisi. Ini menyebarkan nama yang sangat sering di beberapa partisi, mengurangi representasi berlebihan dari nilai suar tunggal apa pun.

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

Saat menanyakan nama belakang frekuensi tinggi tertentu, seperti Jones, aplikasi harus mengeluarkan satu kueri per partisi menggunakan suar. LastName AWS Database Encryption SDK kemudian mendekripsi hasil dan secara otomatis menyaring positif palsu, mengembalikan catatan plaintext yang benar.