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

Pedoman untuk klien enkripsi C3R

Klien enkripsi C3R adalah alat yang memungkinkan organisasi untuk menyatukan data sensitif untuk mendapatkan wawasan baru dari analisis data. Alat ini secara kriptografis membatasi apa yang dapat dipelajari oleh pihak mana pun dan AWS dalam prosesnya. Meskipun ini sangat penting, proses pengamanan data secara kriptografis dapat menambah overhead yang signifikan baik dalam hal sumber daya komputasi maupun penyimpanan. Oleh karena itu, penting untuk memahami pengorbanan menggunakan setiap pengaturan dan cara mengoptimalkan pengaturan sambil tetap mempertahankan jaminan kriptografi yang diinginkan. Topik ini berfokus pada implikasi kinerja dari pengaturan yang berbeda dalam klien dan skema enkripsi C3R.

Semua pengaturan enkripsi klien enkripsi C3R memberikan jaminan kriptografi yang berbeda. Pengaturan tingkat kolaborasi paling aman secara default. Mengaktifkan fungsionalitas tambahan sambil membuat kolaborasi melemahkan jaminan privasi, memungkinkan aktivitas seperti analisis frekuensi dilakukan pada ciphertext. Untuk informasi lebih lanjut tentang bagaimana pengaturan ini digunakan dan apa implikasinya, lihatKomputasi Kriptografi untuk Clean Rooms.

Implikasi kinerja untuk jenis kolom

C3R menggunakan tiga jenis kolom:cleartext,fingerprint, dan. sealed Masing-masing jenis kolom ini memberikan jaminan kriptografi yang berbeda dan memiliki tujuan penggunaan yang berbeda. Pada bagian berikut, implikasi kinerja dari jenis kolom dibahas dan dampak kinerja dari setiap pengaturan.

Cleartextkolom

Cleartextkolom tidak diubah dari format aslinya dan tidak diproses secara kriptografi dengan cara apa pun. Jenis kolom ini tidak dapat dikonfigurasi dan tidak memengaruhi kinerja penyimpanan atau komputasi.

Fingerprintkolom

Fingerprintkolom dimaksudkan untuk digunakan untuk menggabungkan data di beberapa tabel. Untuk tujuan ini, ukuran ciphertext yang dihasilkan harus selalu sama. Namun, kolom ini dipengaruhi oleh pengaturan tingkat kolaborasi. Fingerprintkolom mungkin memiliki berbagai tingkat dampak pada ukuran file output tergantung pada yang cleartext terkandung dalam input.

Basis overhead untuk kolom fingerprint

Ada overhead dasar untuk fingerprint kolom. Overhead ini konstan dan menggantikan ukuran cleartext byte.

Data dalam fingerprint kolom diproses secara kriptografis melalui fungsi Kode Otentikasi Pesan berbasis Hash (HMAC), yang mengubah data menjadi kode otentikasi pesan 32 byte (MAC). Data ini kemudian diproses melalui encoder base64, menambahkan sekitar 33 persen ke ukuran byte. Ini pra-penandaan dengan penunjukan C3R 8 byte untuk menunjuk jenis kolom yang dimiliki data dan versi klien yang menghasilkannya. Hasil akhirnya adalah 52 byte. Hasil ini kemudian dikalikan dengan jumlah baris untuk mendapatkan total overhead basis (gunakan jumlah total null non-nilai jika preserveNulls disetel ke true).

Gambar berikut menunjukkan bagaimana BASE_OVERHEAD = C3R_DESIGNATION + (MAC * 1.33)

Output ciphertext dalam fingerprint kolom akan selalu 52 byte. Ini bisa menjadi penurunan penyimpanan yang signifikan jika cleartext data input rata-rata lebih dari 52 byte (misalnya, alamat jalan lengkap). Ini bisa menjadi peningkatan penyimpanan yang signifikan jika cleartext data input rata-rata kurang dari 52 byte (misalnya, usia pelanggan).

Pengaturan kolaborasi untuk fingerprint kolom

Setelan preserveNulls

Ketika pengaturan preserveNulls tingkat kolaborasi false (default), setiap null nilai diganti dengan 32 byte acak yang unik dan diproses seolah-olah tidak. null Hasilnya adalah bahwa setiap null nilai sekarang 52 byte. Ini dapat menambahkan persyaratan penyimpanan yang signifikan untuk tabel yang berisi data yang sangat jarang dibandingkan dengan saat pengaturan ini true dan null nilai dilewatkan sebagainull.

Jika Anda tidak memerlukan jaminan privasi dari pengaturan ini dan lebih memilih untuk mempertahankan null nilai dalam kumpulan data Anda, aktifkan preserveNulls pengaturan pada saat kolaborasi dibuat. preserveNullsPengaturan tidak dapat diubah setelah kolaborasi dibuat.

Contoh data untuk fingerprint kolom

Berikut ini adalah contoh kumpulan data input dan output untuk fingerprint kolom dengan pengaturan untuk mereproduksi. Pengaturan tingkat kolaborasi lainnya menyukai allowCleartext dan allowDuplicates tidak memengaruhi hasil dan dapat disetel sebagai true atau false jika mencoba mereproduksi secara lokal.

Contoh rahasia bersama: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

Contoh ID kolaborasi: a1b2c3d4-5678-90ab-cdef-EXAMPLE11111

allowJoinsOnColumnsWithDifferentNames: Pengaturan True ini tidak memengaruhi kinerja atau persyaratan penyimpanan. Namun, pengaturan ini membuat pilihan nama kolom tidak relevan saat mereproduksi nilai yang ditunjukkan dalam tabel berikut.

Kolom pemecahan masalah fingerprint

Mengapa ciphertext di fingerprint kolom saya beberapa kali lebih besar dari ukuran cleartext yang masuk ke dalamnya?

Ciphertext dalam fingerprint kolom selalu 52 byte panjangnya. Jika data input Anda kecil (misalnya, usia pelanggan), itu akan menunjukkan peningkatan ukuran yang signifikan. Ini juga bisa terjadi jika preserveNulls pengaturan diatur kefalse.

Mengapa ciphertext di fingerprint kolom saya beberapa kali lebih kecil dari ukuran cleartext yang masuk ke dalamnya?

Ciphertext dalam fingerprint kolom selalu 52 byte panjangnya. Jika data input Anda besar (misalnya, alamat jalan lengkap pelanggan), itu akan menunjukkan penurunan ukuran yang signifikan.

Bagaimana saya tahu jika saya membutuhkan jaminan kriptografi yang disediakan oleh? preserveNulls

Sayangnya, jawabannya adalah itu tergantung. Minimal, Parameter komputasi kriptografi harus ditinjau untuk bagaimana preserveNulls pengaturan melindungi data Anda. Namun, kami menyarankan Anda untuk mereferensikan persyaratan penanganan data organisasi Anda dan kontrak apa pun yang berlaku untuk kolaborasi masing-masing.

Mengapa saya harus mengeluarkan biaya overhead base64?

Untuk memungkinkan kompatibilitas dengan format file tabular seperti CSV, pengkodean base64 diperlukan. Meskipun beberapa format file seperti Parquet mungkin mendukung representasi biner data, penting bahwa semua peserta dalam kolaborasi mewakili data dengan cara yang sama untuk memastikan hasil kueri yang tepat.

Sealedkolom

Sealedkolom dimaksudkan untuk digunakan untuk mentransfer data antara anggota kolaborasi. Ciphertext dalam kolom ini bersifat non-deterministik dan memiliki dampak signifikan pada kinerja dan penyimpanan berdasarkan bagaimana kolom dikonfigurasi. Kolom ini dapat dikonfigurasi secara individual dan seringkali memiliki dampak terbesar pada kinerja klien enkripsi C3R dan ukuran file keluaran yang dihasilkan.

Basis overhead untuk kolom sealed

Ada overhead dasar untuk sealed kolom. Overhead ini konstan dan selain ukuran byte cleartext dan padding (jika ada).

Sebelum enkripsi apa pun, data dalam sealed kolom pra-pended dengan karakter 1 byte yang menunjuk jenis data apa yang terkandung. Jika padding dipilih, data kemudian empuk dan ditambahkan dengan 2 byte yang menyatakan ukuran pad. Setelah byte ini ditambahkan, data diproses secara kriptografi dengan menggunakan AES-GCM dan disimpan dengan IV (12 byte), (32 byte), dan nonce (16 byte). Auth Tag Data ini kemudian diproses melalui encoder base64, menambahkan sekitar 33 persen ke ukuran byte. Data pra-penandaan dengan penunjukan C3R 7 byte untuk menentukan jenis kolom apa yang dimiliki data dan versi klien yang digunakan untuk memproduksinya. Hasilnya adalah overhead basis akhir 91 byte. Hasil ini kemudian dapat dikalikan dengan jumlah baris untuk mendapatkan total overhead basis (gunakan jumlah total nilai non-null jika preserveNulls disetel ke true).

Gambar berikut menunjukkan bagaimana BASE_OVERHEAD = C3R_DESIGNATION + ((NONCE + IV + DATA_TYPE + PAD_SIZE + AUTH_TAG) * 1.33)

Pengaturan kolaborasi untuk sealed kolom

Setelan preserveNulls

Ketika pengaturan preserveNulls tingkat kolaborasi false (default), setiap null nilai unik, acak 32 byte dan diproses seolah-olah tidak. null Hasilnya adalah bahwa setiap null nilai sekarang 91 byte (lebih jika empuk). Ini dapat menambahkan persyaratan penyimpanan yang signifikan untuk tabel yang berisi data yang sangat jarang dibandingkan dengan saat pengaturan ini true dan null nilai dilewatkan sebagainull.

Jika Anda tidak memerlukan jaminan privasi dari pengaturan ini dan lebih memilih untuk mempertahankan null nilai dalam kumpulan data Anda, aktifkan preserveNulls pengaturan pada saat kolaborasi dibuat. preserveNullsPengaturan tidak dapat diubah setelah kolaborasi dibuat.

sealedKolom pengaturan skema: jenis padding

Jenis pad none

Memilih jenis pad none tidak menambahkan padding apa pun ke cleartext dan tidak menambahkan overhead tambahan ke overhead dasar yang dijelaskan sebelumnya. Tidak ada padding yang menghasilkan ukuran output yang paling hemat ruang. Namun, itu tidak memberikan jaminan privasi yang sama dengan tipe fixed dan max padding. Ini karena ukuran yang mendasarinya cleartext dapat dilihat dari ukuran ciphertext.

Jenis pad fixed

Memilih jenis pad fixed adalah ukuran pelestarian privasi untuk menyembunyikan panjang data yang terkandung dalam kolom. Hal ini dilakukan dengan padding semua cleartext ke yang disediakan pad_length sebelum dienkripsi. Setiap data yang melebihi ukuran itu menyebabkan klien enkripsi C3R gagal.

Mengingat bahwa padding ditambahkan ke cleartext sebelum dienkripsi, AES-GCM memiliki pemetaan 1-ke-1 untuk byte ciphertext. cleartext Pengkodean base64 akan menambah 33 persen. Overhead penyimpanan tambahan dari padding dapat dihitung dengan mengurangi panjang rata-rata dari cleartext dari nilai pad_length dan mengalikannya dengan 1,33. Hasilnya adalah overhead rata-rata padding per record. Hasil ini kemudian dapat dikalikan dengan jumlah baris untuk mendapatkan overhead padding total (gunakan jumlah total null non-nilai jika preserveNulls diatur ke). true

PADDING_OVERHEAD = (PAD_LENGTH - AVG_CLEARTEXT_LENGTH) * 1.33 * ROW_COUNT

Kami menyarankan Anda memilih minimum pad_length yang mencakup nilai terbesar dalam kolom. Misalnya, jika nilai terbesar adalah 50 byte, a pad_length dari 50 sudah cukup. Nilai yang lebih besar dari itu hanya akan menambah overhead penyimpanan tambahan.

Padding tetap tidak menambahkan overhead komputasi yang signifikan.

Jenis pad max

Memilih jenis pad max adalah ukuran pelestarian privasi untuk menyembunyikan panjang data yang terkandung dalam kolom. Hal ini dilakukan dengan padding semua cleartext ke nilai terbesar di kolom ditambah tambahan pad_length sebelum dienkripsi. Umumnya, max padding memberikan jaminan yang sama dengan fixed padding untuk satu kumpulan data sementara memungkinkan untuk tidak mengetahui nilai terbesar cleartext di kolom. Namun, max padding mungkin tidak memberikan jaminan privasi yang sama seperti fixed padding di seluruh pembaruan karena nilai terbesar dalam kumpulan data individu mungkin berbeda.

Kami menyarankan Anda memilih tambahan pad_length 0 saat menggunakan max padding. Panjang ini bantalan semua nilai menjadi ukuran yang sama dengan nilai terbesar di kolom. Nilai yang lebih besar dari itu hanya akan menambah overhead penyimpanan tambahan.

Jika cleartext nilai terbesar diketahui untuk kolom tertentu, kami sarankan Anda menggunakan jenis fixed pad sebagai gantinya. Menggunakan fixed padding menciptakan konsistensi di seluruh kumpulan data yang diperbarui. Menggunakan max padding menghasilkan setiap subset data yang diempuk ke nilai terbesar yang ada di subset.

Contoh data untuk sealed kolom

Berikut ini adalah contoh kumpulan data input dan output untuk sealed kolom dengan pengaturan untuk mereproduksi. Pengaturan tingkat kolaborasi lainnya sepertiallowCleartext,allowJoinsOnColumnsWithDifferentNames, dan allowDuplicates tidak memengaruhi hasil dan dapat disetel sebagai true atau false jika mencoba mereproduksi secara lokal. Meskipun ini adalah pengaturan dasar untuk mereproduksi, sealed kolom tidak deterministik dan nilai akan berubah setiap saat. Tujuannya adalah untuk menunjukkan byte dalam dibandingkan dengan byte keluar. Contoh pad_length nilai dipilih dengan sengaja. Mereka menunjukkan bahwa fixed padding menghasilkan nilai yang sama dengan max padding dengan pad_length pengaturan minimum yang disarankan atau ketika padding tambahan diinginkan.

Contoh rahasia bersama: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

Contoh ID kolaborasi: a1b2c3d4-5678-90ab-cdef-EXAMPLE11111

Jenis pad none

Jenis pad fixed (Contoh 1)

Dalam contoh ini, pad_length adalah 62 dan masukan terbesar adalah 62 byte.

Jenis pad fixed (Contoh 2)

Dalam contoh ini, pad_length adalah 162 dan masukan terbesar adalah 62 byte.

Jenis pad max (Contoh 1)

Dalam contoh ini, pad_length adalah 0 dan masukan terbesar adalah 62 byte.

Jenis pad max (Contoh 2)

Dalam contoh ini, pad_length adalah 100 dan masukan terbesar adalah 62 byte.

Kolom pemecahan masalah sealed

Mengapa ciphertext di sealed kolom saya beberapa kali lebih besar dari ukuran cleartext yang masuk ke dalamnya?

Ini tergantung pada beberapa faktor. Untuk satu, ciphertext dalam Cleartext kolom selalu setidaknya 91 byte panjangnya. Jika data input Anda kecil (misalnya, usia pelanggan), itu akan menunjukkan peningkatan ukuran yang signifikan. Kedua, jika preserveNulls disetel ke false dan data input Anda berisi banyak null nilai, masing-masing null nilai tersebut akan berubah menjadi 91 byte ciphertext. Akhirnya, jika Anda menggunakan padding, menurut definisi byte ditambahkan ke cleartext data sebelum dienkripsi.

Sebagian besar data saya di sealed kolom sangat kecil, dan saya perlu menggunakan padding. Bisakah saya menghapus nilai besar dan memprosesnya secara terpisah untuk menghemat ruang?

Kami tidak menyarankan Anda menghapus nilai besar dan memprosesnya secara terpisah. Melakukan hal itu mengubah jaminan privasi yang disediakan oleh klien enkripsi C3R. Sebagai model ancaman, asumsikan bahwa pengamat dapat melihat kedua kumpulan data terenkripsi. Jika pengamat melihat bahwa satu subset data memiliki kolom yang dilapisi secara signifikan lebih atau kurang dari subset lain, mereka dapat membuat kesimpulan tentang ukuran data di setiap subset. Misalnya, asumsikan fullName kolom diempuk dengan total 40 byte dalam satu file dan diempuk hingga 800 byte di file lain. Seorang pengamat mungkin dapat berasumsi bahwa satu kumpulan data berisi nama terpanjang di dunia747 byte).

Apakah saya perlu memberikan padding tambahan saat menggunakan tipe max padding?

Tidak. Saat menggunakan max padding, kami merekomendasikan bahwapad_length, juga dikenal sebagai padding tambahan di luar nilai terbesar di kolom, diatur ke 0.

Bisakah saya memilih yang besar pad_length saat menggunakan fixed padding untuk menghindari kekhawatiran jika nilai terbesar akan cocok?

Ya, tetapi panjang pad yang besar tidak efisien dan menggunakan lebih banyak penyimpanan dari yang diperlukan. Kami menyarankan Anda untuk memeriksa untuk melihat seberapa besar nilai terbesar dan menetapkan pad_length ke nilai itu.

Bagaimana saya tahu jika saya membutuhkan jaminan kriptografi yang disediakan oleh? preserveNulls

Sayangnya, jawabannya adalah itu tergantung. Minimal, Komputasi Kriptografi untuk Clean Rooms harus ditinjau untuk bagaimana preserveNulls pengaturan melindungi data Anda. Namun, kami menyarankan Anda untuk mereferensikan persyaratan penanganan data organisasi Anda dan kontrak apa pun yang berlaku untuk kolaborasi masing-masing.

Mengapa saya harus mengeluarkan biaya overhead base64?

Untuk memungkinkan kompatibilitas dengan format file tabular seperti CSV, pengkodean base64 diperlukan. Meskipun beberapa format file seperti Parquet mungkin mendukung representasi biner data, penting bahwa semua peserta dalam kolaborasi mewakili data dengan cara yang sama untuk memastikan hasil kueri yang tepat.

Memecahkan masalah peningkatan ukuran ciphertext yang tidak terduga

Katakanlah Anda mengenkripsi data Anda, dan ukuran data yang dihasilkan sangat besar. Langkah-langkah berikut dapat membantu Anda mengidentifikasi di mana peningkatan ukuran terjadi dan apa, jika ada, tindakan yang dapat Anda ambil.

Mengidentifikasi di mana peningkatan ukuran terjadi

Sebelum Anda dapat memecahkan masalah mengapa data terenkripsi Anda secara signifikan lebih besar daripada cleartext data Anda, Anda harus terlebih dahulu mengidentifikasi di mana peningkatan ukurannya. Cleartextkolom dapat diabaikan dengan aman karena tidak berubah. Lihatlah yang tersisa fingerprint dan sealed kolom, dan pilih salah satu yang tampak signifikan.

Mengidentifikasi alasan peningkatan ukuran terjadi

fingerprintKolom atau sealed kolom mungkin berkontribusi pada peningkatan ukuran.

Apakah peningkatan ukuran berasal dari fingerprint kolom?

Jika kolom yang paling berkontribusi terhadap peningkatan penyimpanan adalah fingerprint kolom, ini mungkin karena cleartext datanya kecil (misalnya, usia pelanggan). Setiap fingerprint ciphertext yang dihasilkan panjangnya 52 byte. Sayangnya, tidak ada yang bisa dilakukan tentang masalah ini column-by-column atas dasar. Untuk informasi selengkapnya, lihat Basis overhead untuk kolom fingerprint detail tentang kolom ini, termasuk dampaknya terhadap persyaratan penyimpanan.

Kemungkinan penyebab lain dari peningkatan ukuran dalam fingerprint kolom adalah pengaturan kolaborasi,preserveNulls. Jika pengaturan kolaborasi untuk preserveNulls dinonaktifkan (pengaturan default), semua null nilai dalam fingerprint kolom akan menjadi 52 byte ciphertext. Tidak ada yang bisa dilakukan untuk ini dalam kolaborasi saat ini. preserveNullsPengaturan diatur pada saat kolaborasi dibuat dan semua kolaborator harus menggunakan pengaturan yang sama untuk memastikan hasil kueri yang benar. Untuk informasi selengkapnya tentang preserveNulls pengaturan dan bagaimana pengaktifannya memengaruhi jaminan privasi data Anda, lihat. Komputasi Kriptografi untuk Clean Rooms

Apakah peningkatan ukuran berasal dari sealed kolom?

Jika kolom yang paling berkontribusi terhadap peningkatan penyimpanan adalah sealed kolom, ada beberapa detail yang dapat berkontribusi pada peningkatan ukuran.

Jika cleartext data kecil (misalnya, usia pelanggan), setiap sealed ciphertext yang dihasilkan setidaknya 91 byte panjangnya. Sayangnya, tidak ada yang bisa dilakukan tentang masalah ini. Untuk informasi selengkapnya, lihat Basis overhead untuk kolom sealed detail tentang kolom ini, termasuk dampaknya terhadap persyaratan penyimpanan.

Penyebab utama kedua untuk peningkatan penyimpanan sealed kolom adalah padding. Padding menambahkan byte ekstra ke cleartext sebelum dienkripsi untuk menyembunyikan ukuran nilai individual dalam kumpulan data. Kami menyarankan Anda mengatur padding ke nilai minimum yang mungkin untuk kumpulan data Anda. Minimal, pad_length untuk fixed padding harus diatur untuk mencakup nilai terbesar yang mungkin di kolom. Pengaturan yang lebih tinggi dari itu tidak menambahkan jaminan privasi tambahan. Misalnya, jika Anda tahu nilai terbesar yang mungkin dalam kolom bisa 50 byte, kami sarankan Anda menyetel pad_length ke 50 byte. Namun, jika sealed kolom menggunakan max padding, kami sarankan Anda mengatur pad_length ke 0 byte. Ini karena max padding mengacu pada padding tambahan di luar nilai terbesar di kolom.

Kemungkinan penyebab akhir dari peningkatan ukuran dalam sealed kolom adalah pengaturan kolaborasi,preserveNulls. Jika pengaturan kolaborasi untuk preserveNulls dinonaktifkan (pengaturan default), semua null nilai dalam sealed kolom akan menjadi 91 byte ciphertext. Tidak ada yang bisa dilakukan untuk ini dalam kolaborasi saat ini. preserveNullsPengaturan diatur pada saat kolaborasi dibuat, dan semua kolaborator harus menggunakan pengaturan yang sama untuk memastikan hasil kueri yang benar. Untuk informasi selengkapnya tentang pengaturan ini dan bagaimana cara mengaktifkannya memengaruhi jaminan privasi data Anda, lihat. Komputasi Kriptografi untuk Clean Rooms