Pseudonimisasi adalah teknik de-identifikasi yang mengganti nilai data sensitif dengan token yang dihasilkan secara kriptografis. Pseudonymization banyak digunakan di industri seperti keuangan dan layanan kesehatan untuk membantu mengurangi risiko data yang digunakan, mempersempit cakupan kepatuhan, dan meminimalkan eksposur data sensitif ke sistem sekaligus mempertahankan utilitas dan akurasi data.
Perlindungan Data Sensitif mendukung tiga teknik pseudonimisasi de-identifikasi, dan menghasilkan token dengan menerapkan salah satu dari tiga metode transformasi kriptografis ke nilai data sensitif asli. Setiap nilai sensitif asli kemudian diganti dengan token yang sesuai. Pseudonimisasi terkadang disebut sebagai tokenisasi atau penggantian surrogate.
Teknik pseudonimisasi memungkinkan token satu arah atau dua arah. Token satu arah telah diubah secara permanen, sedangkan token dua arah dapat dibalik. Karena token dibuat menggunakan enkripsi simetris, kunci kriptografis yang sama yang dapat menghasilkan token baru juga dapat membalikkan token. Untuk situasi saat Anda tidak memerlukan reversibilitas, Anda dapat menggunakan token satu arah yang menggunakan mekanisme hashing aman.
Sebaiknya pahami bagaimana pseudonimisasi dapat membantu melindungi data sensitif sekaligus memungkinkan operasi bisnis dan alur kerja analisis Anda mudah mengakses dan menggunakan data yang mereka butuhkan. Topik ini membahas konsep pseudonimisasi dan tiga metode kriptografi untuk mengubah data yang didukung Perlindungan Data Sensitif.
Untuk petunjuk tentang cara menerapkan metode pseudonimisasi ini dan untuk contoh penggunaan Perlindungan Data Sensitif lainnya, lihat De-identifikasi data sensitif.
Metode kriptografis yang didukung di Sensitive Data Protection
Perlindungan Data Sensitif mendukung tiga teknik pseudonimisasi, yang semuanya menggunakan kunci kriptografis. Berikut adalah metode yang tersedia:
- Enkripsi deterministik menggunakan AES-SIV: Nilai input diganti dengan nilai yang telah dienkripsi menggunakan algoritma enkripsi AES-SIV dengan kunci kriptografis, yang dienkode menggunakan base64, lalu ditambahkan dengan anotasi pengganti, jika ditentukan. Metode ini menghasilkan nilai hash, sehingga tidak mempertahankan kumpulan karakter atau panjang nilai input. Nilai yang dienkripsi dan di-hash dapat diidentifikasi ulang menggunakan kunci kriptografi asli dan seluruh nilai output, termasuk anotasi pengganti. Pelajari lebih lanjut format nilai yang ditokenisasi menggunakan enkripsi AES-SIV.
- Enkripsi yang mempertahankan format: Nilai input diganti dengan nilai yang telah dienkripsi menggunakan algoritma enkripsi FPE-FFX dengan kunci kriptografi, lalu ditambahkan dengan anotasi pengganti, jika ditentukan. Secara desain, himpunan karakter dan panjang nilai input dipertahankan dalam nilai output. Nilai terenkripsi dapat diidentifikasi ulang menggunakan kunci kriptografis asli dan seluruh nilai output, termasuk anotasi pengganti. (Untuk beberapa pertimbangan penting terkait penggunaan metode enkripsi ini, lihat Enkripsi yang mempertahankan format nanti dalam topik ini.)
- Hashing kriptografis: Nilai input diganti dengan nilai yang telah dienkripsi dan di-hash menggunakan Kode Autentikasi Pesan Berbasis Hash (HMAC)-Algoritma Hash Aman (SHA)-256 pada nilai input dengan kunci kriptografis. Output hash dari transformasi selalu memiliki panjang yang sama dan tidak dapat diidentifikasi ulang. Pelajari lebih lanjut format nilai yang di-tokenisasi menggunakan hashing kriptografis.
Metode pseudonimisasi ini dirangkum dalam tabel berikut. Baris tabel dijelaskan setelah tabel.
| Enkripsi deterministik menggunakan AES-SIV | Enkripsi yang mempertahankan format | Hashing kriptografis | |
|---|---|---|---|
| Jenis enkripsi | AES-SIV | FPE-FFX | HMAC-SHA-256 |
| Nilai input yang didukung | Panjang minimal 1 karakter; tidak ada batasan kumpulan karakter. | Panjang minimal 2 karakter; harus dienkode sebagai ASCII. | Harus berupa nilai string atau bilangan bulat. |
| Anotasi pengganti | Opsional. | Opsional. | T/A |
| Penyesuaian konteks | Opsional. | Opsional. | T/A |
| Kumpulan karakter dan panjang dipertahankan | ✗ | ✓ | ✗ |
| Dapat dikembalikan | ✓ | ✓ | ✗ |
| Integritas referensial | ✓ | ✓ | ✓ |
- Jenis enkripsi: Jenis enkripsi yang digunakan dalam transformasi de-identifikasi.
- Nilai input yang didukung: Persyaratan minimum untuk nilai input.
- Anotasi pengganti: Anotasi yang ditentukan pengguna yang ditambahkan di awal
nilai terenkripsi untuk memberikan konteks kepada pengguna dan memberikan informasi untuk
Perlindungan Data Sensitif yang akan digunakan dalam identifikasi ulang nilai
yang dide-identifikasi. Anotasi pengganti diperlukan untuk identifikasi ulang
data tidak terstruktur. Hal ini bersifat opsional saat mentransformasi kolom data terstruktur, atau
tabel, dengan
RecordTransformation. - Penyesuaian konteks: Referensi ke kolom data yang "menyesuaikan" nilai input
sehingga nilai input yang identik dapat dide-identifikasi ke nilai output
yang berbeda. Penyesuaian konteks bersifat opsional saat mengubah kolom data terstruktur atau tabel dengan
RecordTransformation. Untuk mempelajari lebih lanjut, lihat Menggunakan tweak konteks. - Himpunan karakter dan panjang dipertahankan: Apakah nilai yang dide-identifikasi terdiri dari kumpulan karakter yang sama dengan nilai aslinya, dan apakah panjang nilai yang dide-identifikasi cocok dengan nilai aslinya.
- Dapat dikembalikan: Dapat diidentifikasi ulang menggunakan kunci kriptografis, anotasi pengganti, dan tweak konteks apa pun.
- Integritas referensial: Integritas referensial memungkinkan kumpulan data mempertahankan hubungannya satu sama lain meskipun datanya telah dide-identifikasi satu per satu. Dengan kunci kripto dan penyesuaian konteks yang sama, tabel data akan diganti dengan bentuk yang di-obfuscate yang sama setiap kali ditransformasikan, yang memastikan bahwa koneksi antara nilai (dan, dengan data terstruktur, data) dipertahankan, bahkan di seluruh tabel.
Cara kerja tokenisasi di Perlindungan Data Sensitif
Proses dasar tokenisasi sama untuk ketiga metode yang didukung Perlindungan Data Sensitif.
Langkah 1: Sensitive Data Protection memilih data yang akan di-tokenisasi. Cara paling umum untuk melakukannya adalah menggunakan detector infoType bawaan atau kustom untuk mencocokkan nilai data sensitif yang diinginkan. Jika memindai data terstruktur (seperti tabel BigQuery), Anda juga dapat melakukan tokenisasi pada seluruh kolom data menggunakan transformasi catatan.
Untuk informasi selengkapnya tentang dua kategori transformasi—infoType dan transformasi kumpulan data—lihat Transformasi de-identifikasi.
Langkah 2: Dengan kunci kriptografis, Perlindungan Data Sensitif mengenkripsi setiap nilai input. Anda dapat memberikan kunci ini dengan salah satu dari tiga cara berikut:
- Dengan menggabungkannya menggunakan Cloud Key Management Service (Cloud KMS). (Untuk keamanan maksimum, Cloud KMS adalah metode yang lebih disukai.)
- Dengan menggunakan kunci sementara, yang dibuat oleh Perlindungan Data Sensitif pada saat de-identifikasi, lalu dihapus. Kunci sementara hanya mempertahankan integritas per permintaan API. Jika Anda memerlukan integritas atau berencana mengidentifikasi ulang data ini, jangan gunakan jenis kunci ini.
- Langsung dalam bentuk teks mentah. (Tidak direkomendasikan.)
Untuk mengetahui detail selengkapnya, lihat bagian Menggunakan kunci kriptografis, nanti dalam topik ini.
Langkah 3 (Hash kriptografis dan enkripsi deterministik hanya dengan AES-SIV): Perlindungan Data Sensitif mengenkode nilai terenkripsi menggunakan base64. Dengan hashing kriptografis, nilai terenkripsi yang dienkode ini adalah token, dan prosesnya dilanjutkan dengan Langkah 6. Dengan enkripsi deterministik menggunakan AES-SIV, nilai yang dienkode dan dienkripsi ini adalah nilai pengganti, yang merupakan salah satu komponen token. Prosesnya dilanjutkan dengan Langkah 4.
Langkah 4 (Enkripsi yang mempertahankan format dan deterministik hanya dengan AES-SIV):
Sensitive Data Protection menambahkan anotasi pengganti opsional ke nilai
teracak. Anotasi pengganti membantu mengidentifikasi nilai pengganti terenkripsi dengan
menambahkan string deskriptif yang Anda tentukan. Misalnya, tanpa
anotasi, Anda mungkin tidak dapat membedakan nomor telepon yang dide-identifikasi
dan nomor Jaminan Sosial atau nomor identifikasi lainnya yang dide-identifikasi. Selain itu,
untuk mengidentifikasi ulang nilai dalam data tidak terstruktur yang telah dide-identifikasi menggunakan
enkripsi yang mempertahankan format atau enkripsi deterministik, Anda harus
menentukan anotasi pengganti. (Anotasi pengganti tidak diperlukan saat
mentransformasi kolom data terstruktur atau tabel dengan
RecordTransformation.)
Langkah 5 (Enkripsi yang mempertahankan format dan deterministik dengan AES-SIV dari data terstruktur saja): Perlindungan Data Sensitif dapat menggunakan konteks opsional dari kolom lain untuk "menyesuaikan" token yang dihasilkan. Hal ini memungkinkan Anda mengubah cakupan token. Misalnya, Anda memiliki database data kampanye pemasaran yang menyertakan alamat email dan ingin membuat token unik untuk alamat email yang sama yang "disesuaikan" oleh ID kampanye. Hal ini akan memungkinkan seseorang menggabungkan data untuk pengguna yang sama dalam kampanye yang sama, tetapi tidak di seluruh kampanye yang berbeda. Jika tweak konteks digunakan untuk membuat token, tweak konteks ini juga diperlukan agar transformasi de-identifikasi dapat dibalik. Enkripsi yang mempertahankan format dan deterministik menggunakan konteks dukungan AES-SIV. Pelajari lebih lanjut cara menggunakan penyesuaian konteks.
Langkah 6: Perlindungan Data Sensitif mengganti nilai asli dengan nilai yang dide-identifikasi.
Perbandingan nilai yang ditokenisasi
Bagian ini menunjukkan tampilan token standar setelah dide-identifikasi menggunakan setiap dari tiga metode yang dibahas dalam topik ini. Contoh nilai data sensitif adalah nomor telepon Amerika Utara (1-206-555-0123).
Enkripsi deterministik menggunakan AES-SIV
Dengan de-identifikasi menggunakan enkripsi deterministik dan AES-SIV, nilai input (dan, secara opsional, tweak konteks yang ditentukan) dienkripsi menggunakan AES-SIV dengan kunci kriptografis, dienkode menggunakan base64, lalu secara opsional ditambahkan dengan anotasi pengganti, jika ditentukan. Metode ini tidak mempertahankan set karakter (atau "alfabet") dari nilai input. Untuk menghasilkan output yang dapat dicetak, nilai yang dihasilkan dienkode dalam base64.
Token yang dihasilkan, dengan asumsi infoType pengganti telah ditentukan, dalam format:
SURROGATE_INFOTYPE(SURROGATE_VALUE_LENGTH):SURROGATE_VALUE
Diagram beranotasi berikut menunjukkan contoh token—output dari
operasi de-identifikasi menggunakan enkripsi deterministik dengan AES-SIV pada
nilai 1-206-555-0123. InfoType surrogate opsional telah ditetapkan ke
NAM_PHONE_NUMB:
- Anotasi pengganti
- infoType surrogate (ditentukan oleh pengguna)
- Panjang karakter nilai yang ditransformasi
- Nilai pengganti (ditransformasi)
Jika Anda tidak menentukan anotasi pengganti, token yang dihasilkan akan sama dengan
nilai yang ditransformasi, atau #4 dalam diagram yang dianotasi. Untuk mengidentifikasi ulang
data tidak terstruktur, seluruh token ini diperlukan, termasuk anotasi pengganti. Saat mengubah data terstruktur seperti tabel, anotasi pengganti
adalah opsional; Perlindungan Data Sensitif dapat melakukan
de-identifikasi dan re-identifikasi pada seluruh kolom menggunakan
RecordTransformation
tanpa anotasi pengganti.
Enkripsi yang mempertahankan format
Dengan de-identifikasi menggunakan enkripsi yang mempertahankan format, nilai input (dan, secara opsional, tweak konteks yang ditentukan) dienkripsi menggunakan mode FFX enkripsi yang mempertahankan format ("FPE-FFX") dengan kunci kriptografis, lalu secara opsional diawali dengan anotasi pengganti, jika ditentukan.
Tidak seperti metode tokenisasi lainnya yang dijelaskan dalam topik ini, nilai pengganti output memiliki panjang yang sama dengan nilai input, dan tidak dienkode menggunakan base64. Anda menentukan kumpulan karakter—atau "alfabet"—yang terdiri dari nilai terenkripsi. Ada tiga cara untuk menentukan alfabet yang akan digunakan Perlindungan Data Sensitif dalam nilai output:
- Gunakan salah satu dari empat nilai yang dihitung yang mewakili empat kumpulan karakter/alfabet yang paling umum.
- Gunakan nilai radix, yang menentukan ukuran alfabet. Menentukan
nilai radix minimum
2akan menghasilkan alfabet yang hanya terdiri dari0dan1. Menentukan nilai radix maksimum95akan menghasilkan alfabet yang mencakup semua karakter numerik, karakter alfa huruf besar, karakter alfa huruf kecil, dan karakter simbol. - Buat alfabet dengan mencantumkan karakter yang akan digunakan. Misalnya,
menentukan
1234567890-*akan menghasilkan nilai pengganti yang hanya terdiri dari angka, tanda hubung, dan tanda bintang.
Tabel berikut mencantumkan empat set karakter umum berdasarkan nilai
yang dihitung
(FfxCommonNativeAlphabet),
nilai radix, dan daftar karakter set. Baris terakhir mencantumkan kumpulan
karakter lengkap, yang sesuai dengan nilai radix maksimum.
| Nama alfabet/himpunan karakter | Radix | Daftar karakter |
|---|---|---|
NUMERIC |
10 |
0123456789 |
HEXADECIMAL |
16 |
0123456789ABCDEF |
UPPER_CASE_ALPHA_NUMERIC |
36 |
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ |
ALPHA_NUMERIC |
62 |
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz |
| - | 95 |
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz~`!@#$%^&*()_-+={[}]|\:;"'<,>.?/ |
Token yang dihasilkan, dengan asumsi infoType pengganti telah ditentukan, dalam format:
SURROGATE_INFOTYPE(SURROGATE_VALUE_LENGTH):SURROGATE_VALUE
Diagram beranotasi berikut adalah output operasi penghapusan identitas
Sensitive Data Protection menggunakan enkripsi yang mempertahankan format pada nilai
1-206-555-0123 menggunakan radix 95. InfoType surrogate opsional telah
ditetapkan ke NAM_PHONE_NUMB:
- Anotasi pengganti
- infoType surrogate (ditentukan oleh pengguna)
- Panjang karakter nilai yang ditransformasi
- Nilai pengganti (ditransformasi)—panjangnya sama dengan nilai input
Jika Anda tidak menentukan anotasi pengganti, token yang dihasilkan akan sama dengan
nilai yang ditransformasi, atau #4 dalam diagram yang dianotasi. Untuk mengidentifikasi ulang
data tidak terstruktur, seluruh token ini diperlukan, termasuk anotasi pengganti. Saat mengubah data terstruktur seperti tabel, anotasi pengganti
adalah opsional; Perlindungan Data Sensitif dapat melakukan
de-identifikasi dan identifikasi ulang pada seluruh kolom menggunakan
RecordTransformation
tanpa pengganti.
Hashing kriptografi
Dengan de-identifikasi menggunakan hashing kriptografis, nilai input di-hash menggunakan HMAC-SHA-256 dengan kunci kriptografis, lalu dienkode menggunakan base64. Nilai yang di-de-identifikasi selalu memiliki panjang yang seragam, bergantung pada ukuran kunci.
Tidak seperti metode tokenisasi lainnya yang dibahas dalam topik ini, hashing kriptografis membuat token satu arah. Artinya, penghapusan identitas menggunakan hashing kriptografis tidak dapat dibalik.
Berikut adalah output operasi de-identifikasi menggunakan hashing
kriptografis pada nilai 1-206-555-0123. Output ini adalah representasi nilai hashing berenkode base64:
XlTCv8h0GwrCZK+sS0T3Z8txByqnLLkkF4+TviXfeZY=
Menggunakan kunci kriptografis
Ada tiga opsi untuk kunci kriptografis yang dapat Anda gunakan dengan metode de-identifikasi kriptografis di Perlindungan Data Sensitif:
Kunci kriptografis yang digabungkan Cloud KMS: Ini adalah jenis kunci kriptografis paling aman yang tersedia untuk digunakan dengan metode de-identifikasi Perlindungan Data Sensitif. Kunci gabungan Cloud KMS terdiri dari kunci kriptografis 128-, 192-, atau 256-bit yang telah dienkripsi menggunakan kunci lain. Anda memberikan kunci kriptografis pertama, yang kemudian digabungkan menggunakan kunci kriptografis yang disimpan Cloud Key Management Service. Jenis kunci ini disimpan di Cloud KMS untuk identifikasi ulang nanti. Untuk informasi selengkapnya tentang cara membuat dan menggabungkan kunci untuk tujuan de-identifikasi dan identifikasi ulang, lihat Panduan memulai: Melakukan de-identifikasi dan identifikasi ulang teks sensitif.
Kunci kriptografis sementara: Kunci kriptografis sementara dibuat oleh Perlindungan Data Sensitif pada saat de-identifikasi, lalu dihapus. Oleh karena itu, jangan gunakan kunci kriptografis sementara dengan metode de-identifikasi kriptografis yang ingin Anda balik. Kunci kriptografis sementara hanya mempertahankan integritas per permintaan API. Jika Anda memerlukan integritas di lebih dari satu permintaan API atau berencana untuk mengidentifikasi ulang data, jangan gunakan jenis kunci ini.
Kunci kriptografis yang tidak digabungkan: Kunci yang tidak digabungkan adalah kunci kriptografis 128, 192, atau 256-bit berenkode base64 mentah yang Anda berikan di dalam permintaan de-identifikasi ke DLP API. Anda bertanggung jawab untuk menjaga keamanan jenis kunci kriptografis ini untuk identifikasi ulang di lain waktu. Karena risiko kebocoran kunci secara tidak sengaja, jenis kunci ini tidak direkomendasikan. Kunci ini dapat berguna untuk pengujian, tetapi untuk beban kerja produksi, sebaiknya gunakan kunci kriptografis yang digabungkan dengan Cloud KMS.
Untuk mempelajari lebih lanjut opsi yang tersedia saat menggunakan kunci kriptografis, lihat
CryptoKey
dalam referensi DLP API.
Menggunakan penyesuaian konteks
Secara default, semua metode transformasi kriptografi de-identifikasi memiliki integritas referensial, baik token output bersifat satu arah maupun dua arah. Artinya, dengan kunci kriptografis yang sama, nilai input selalu diubah menjadi nilai terenkripsi yang sama. Dalam situasi saat data berulang atau pola data mungkin terjadi, risiko identifikasi ulang akan meningkat. Sebagai gantinya, agar nilai input yang sama selalu diubah menjadi nilai terenkripsi yang berbeda, Anda dapat menentukan penyesuaian konteks yang unik.
Anda menentukan tweak konteks (hanya diberi nama
context
di DLP API) saat mengubah data tabel, karena tweak tersebut
secara efektif merupakan pointer ke kolom data, seperti ID.
Perlindungan Data Sensitif menggunakan nilai di kolom yang ditentukan oleh tweak
konteks saat mengenkripsi nilai input. Untuk memastikan bahwa nilai terenkripsi
selalu merupakan nilai unik, tentukan kolom untuk tweak yang berisi ID
unik.
Perhatikan contoh sederhana ini. Tabel berikut menunjukkan beberapa rekam medis, beberapa di antaranya menyertakan ID pasien duplikat.
| record_id | patient_id | icd10_code |
|---|---|---|
| 5437 | 43789 | E11.9 |
| 5438 | 43671 | M25.531 |
| 5439 | 43789 | N39,0, I25.710 |
| 5440 | 43766 | I10 |
| 5441 | 43766 | I10 |
| 5442 | 42989 | R07.81 |
| 5443 | 43098 | I50.1, R55 |
| ... | ... | ... |
Jika Anda menginstruksikan Perlindungan Data Sensitif untuk mende-identifikasi ID pasien dalam
tabel, tindakan ini akan mende-identifikasi ID pasien berulang ke nilai yang sama secara default, seperti
yang ditunjukkan dalam tabel berikut. Misalnya, kedua instance ID pasien
"43789" dide-identifikasi menjadi "47222". (Kolom patient_id menampilkan
nilai token setelah pseudonimisasi menggunakan FPE-FFX dan tidak menyertakan
anotasi pengganti. Lihat Enkripsi yang mempertahankan format untuk mengetahui informasi
selengkapnya.)
| record_id | patient_id | icd10_codes |
|---|---|---|
| 5437 | 47222 | E11.9 |
| 5438 | 82160 | M25.531 |
| 5439 | 47222 | N39,0, I25.710 |
| 5440 | 04452 | I10 |
| 5441 | 04452 | I10 |
| 5442 | 47826 | R07.81 |
| 5443 | 52428 | I50.1, R55 |
| ... | ... | ... |
Artinya, cakupan integritas referensial mencakup seluruh set data.
Untuk mempersempit cakupan agar Anda menghindari perilaku ini, tentukan tweak konteks. Anda dapat menentukan kolom apa pun sebagai tweak konteks, tetapi untuk memastikan bahwa setiap nilai yang dideidentifikasi bersifat unik, tentukan kolom yang setiap nilainya bersifat unik.
Misalnya, Anda ingin melihat apakah pasien yang sama muncul per nilai icd10_codes, tetapi tidak jika pasien yang sama muncul dalam nilai icd10_codes yang berbeda. Untuk
melakukannya, Anda harus menentukan kolom icd10_codes sebagai tweak konteks.
Ini adalah tabel setelah membatalkan identifikasi kolom patient_id menggunakan
kolom icd10_codes sebagai penyesuaian konteks:
| record_id | patient_id | icd10_codes |
|---|---|---|
| 5437 | 18954 | E11.9 |
| 5438 | 33068 | M25.531 |
| 5439 | 76368 | N39,0, I25.710 |
| 5440 | 29460 | I10 |
| 5441 | 29460 | I10 |
| 5442 | 23877 | R07.81 |
| 5443 | 96129 | I50.1, R55 |
| ... | ... | ... |
Perhatikan bahwa nilai patient_id keempat dan kelima yang dide-identifikasi (29460) sama karena tidak hanya nilai patient_id asli yang identik, nilai icd10_codes kedua baris juga identik. Karena Anda perlu menjalankan analisis dengan ID pasien yang konsisten dalam cakupan nilai icd10_codes, perilaku ini adalah yang Anda cari.
Untuk sepenuhnya memutuskan integritas referensi antara nilai patient_id dan
nilai icd10_codes, Anda dapat menggunakan kolom record_id sebagai tweak
konteks:
| record_id | patient_id | icd10_code |
|---|---|---|
| 5437 | 15826 | E11.9 |
| 5438 | 61722 | M25.531 |
| 5439 | 34424 | N39,0, I25.710 |
| 5440 | 02875 | I10 |
| 5441 | 52549 | I10 |
| 5442 | 17945 | R07.81 |
| 5443 | 19030 | I50.1, R55 |
| ... | ... | ... |
Perhatikan bahwa setiap nilai patient_id yang dide-identifikasi dalam tabel kini bersifat unik.
Untuk mempelajari cara menggunakan tweak konteks di DLP API, perhatikan penggunaan
context dalam topik referensi metode transformasi berikut:
- Enkripsi dengan mempertahankan format:
CryptoReplaceFfxFpeConfig - Enkripsi deterministik menggunakan AES-SIV:
CryptoDeterministicConfig - Pergeseran tanggal:
DateShiftConfig
Langkah selanjutnya
Lihat contoh kode yang menunjukkan cara membuat token data sensitif.
Pelajari cara menghapus identitas data menggunakan DLP API.