Pseudonimisasi adalah teknik de-identifikasi yang mengganti nilai data sensitif dengan token yang dihasilkan secara kriptografis. Pseudonimisasi banyak digunakan di industri seperti keuangan dan layanan kesehatan untuk membantu mengurangi risiko penggunaan data, 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 akan diganti dengan token yang sesuai. Pseudonimisasi terkadang disebut sebagai tokenization atau penggantian surrogate.
Teknik pseudonimisasi mengaktifkan token satu arah atau dua arah. Token satu arah telah diubah secara permanen, sementara 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 yang aman.
Sebaiknya Anda memahami bagaimana pseudonimisasi dapat membantu melindungi data sensitif sekaligus memungkinkan operasi bisnis dan alur kerja analisis Anda mengakses dan menggunakan data yang diperlukan dengan mudah. Topik ini mempelajari konsep pseudonimisasi dan tiga metode kriptografi untuk mengubah data yang didukung Perlindungan Data Sensitif.
Untuk mengetahui petunjuk cara menerapkan metode pseudonimisasi ini dan untuk contoh penggunaan Perlindungan Data Sensitif lainnya, lihat Melakukan de-identifikasi data sensitif.
Metode kriptografi yang didukung dalam Perlindungan Data Sensitif
Perlindungan Data Sensitif mendukung tiga teknik pseudonimisasi, yang semuanya menggunakan kunci kriptografi. Berikut adalah metode yang tersedia:
- Enkripsi deterministik menggunakan AES-SIV: Nilai input akan diganti dengan nilai yang telah dienkripsi menggunakan algoritma enkripsi AES-SIV dengan kunci kriptografis, dienkode menggunakan base64, lalu diawali dengan anotasi surrogate jika ditentukan. Metode ini menghasilkan nilai yang di-hash, sehingga tidak mempertahankan himpunan karakter atau panjang nilai input. Nilai terenkripsi dan hash dapat diidentifikasi ulang menggunakan kunci kriptografis asli dan seluruh nilai output, termasuk anotasi surrogate. Pelajari lebih lanjut format nilai yang di-token menggunakan enkripsi AES-SIV.
- Enkripsi yang mempertahankan format: Nilai input diganti dengan nilai yang telah dienkripsi menggunakan algoritma enkripsi FPE-FFX dengan kunci kriptografis, lalu diawali dengan anotasi surrogate, jika ditentukan. Secara desain, himpunan karakter dan panjang nilai input dipertahankan dalam nilai output. Nilai terenkripsi dapat diidentifikasi ulang menggunakan kunci kriptografis asli dan keseluruhan nilai output, termasuk anotasi surrogate. (Untuk beberapa pertimbangan penting seputar penggunaan metode enkripsi ini, lihat Enkripsi format nanti dalam topik ini.)
- Hashing kriptografis: Nilai input diganti dengan nilai yang telah dienkripsi dan di-hash menggunakan Hash-based Message Authentication Code (HMAC)-Secure Hash Algorithm (SHA)-256 pada nilai input dengan kunci kriptografis. Output transformasi yang di-hash selalu sama dan tidak dapat diidentifikasi ulang. Pelajari lebih lanjut format nilai yang di-token menggunakan hash kriptografis.
Metode pseudonimisasi ini dirangkum dalam tabel berikut. Baris tabel dijelaskan mengikuti tabel.
| Enkripsi deterministik menggunakan AES-SIV | Enkripsi dengan mempertahankan format | Hashing kriptografis | |
|---|---|---|---|
| Jenis enkripsi | AES-SIV | FPE-FFX | HMAC-SHA-256 |
| Nilai input yang didukung | Minimal 1 karakter; tidak ada batasan himpunan karakter. | Minimal 2 karakter; harus dienkode sebagai ASCII. | Harus berupa nilai string atau bilangan bulat. |
| Anotasi surrogate | Opsional. | Opsional. | T/A |
| Penyesuaian konteks | Opsional. | Opsional. | T/A |
| Panjang himpunan dan himpunan karakter dipertahankan | ✗ | ✓ | ✗ |
| Balik | ✓ | ✓ | ✗ |
| Integritas referensi | ✓ | ✓ | ✓ |
- Jenis enkripsi: Jenis enkripsi yang digunakan dalam transformasi de-identifikasi.
- Nilai input yang didukung: Persyaratan minimum untuk nilai input.
- Anotasi surrogate: Anotasi yang ditentukan pengguna yang ditambahkan ke
nilai terenkripsi untuk memberikan konteks kepada pengguna dan memberikan informasi bagi
Perlindungan Data Sensitif untuk digunakan dalam identifikasi ulang nilai yang
dide-identifikasi. Anotasi surrogate diperlukan untuk identifikasi ulang
data yang tidak terstruktur. Atribut ini bersifat opsional saat mengubah kolom data terstruktur atau
tabular dengan
RecordTransformation. - Tweak 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 penyesuaian konteks. - Kumpulan karakter dan panjang yang dipertahankan: Apakah nilai yang dide-identifikasi terdiri dari kumpulan karakter yang sama dengan nilai asli, dan apakah panjang nilai yang dide-identifikasi cocok dengan nilai aslinya.
- Dapat dibatalkan: Dapat diidentifikasi ulang menggunakan kunci kriptografis, anotasi pengganti, dan penyesuaian konteks apa pun.
- Integritas referensial: Integritas referensi memungkinkan catatan untuk mempertahankan hubungannya satu sama lain bahkan setelah datanya dide-identifikasi satu per satu. Dengan kunci kripto dan tweet konteks yang sama, tabel data akan diganti dengan bentuk sama yang di-obfuscate yang sama setiap kali ditransformasi, yang memastikan bahwa koneksi antar-nilai (dan, dengan data terstruktur, catatan) dipertahankan, bahkan di seluruh tabel.
Cara kerja tokenisasi di Perlindungan Data Sensitif
Proses dasar tokenisasi adalah sama untuk ketiga metode yang didukung Perlindungan Data Sensitif.
Langkah 1: Perlindungan Data Sensitif memilih data untuk di-token. Cara paling umum untuk melakukannya adalah dengan menggunakan deteksi 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 kumpulan data.
Untuk mengetahui informasi selengkapnya tentang dua kategori transformasi—infoType dan transformasi data—lihat Transformasi de-identifikasi.
Langkah 2: Dengan menggunakan 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 direkomendasikan.)
- Dengan menggunakan kunci sementara, yang dihasilkan oleh Perlindungan Data Sensitif pada saat de-identifikasi, lalu dihapus. Kunci sementara hanya mempertahankan integritas per permintaan API. Jika Anda memerlukan integritas atau rencana untuk mengidentifikasi ulang data ini, jangan gunakan jenis kunci ini.
- Langsung dalam bentuk teks mentah. (Tidak disarankan.)
Untuk mengetahui detail selengkapnya, lihat bagian Menggunakan kunci kriptografis, nanti dalam topik ini.
Langkah 3 (Khusus hashing kriptografis dan enkripsi deterministik dengan AES-SIV): Perlindungan Data Sensitif mengenkode nilai terenkripsi menggunakan base64. Dengan hashing kriptografi, nilai yang dienkode dan dienkripsi ini adalah tokennya, dan proses dilanjutkan dengan Langkah 6. Dengan enkripsi deterministik menggunakan AES-SIV, nilai yang dienkode dan dienkripsi ini adalah nilai surrogate, yang hanya merupakan salah satu komponen token. Proses dilanjutkan dengan Langkah 4.
Langkah 4 (Format mempertahankan dan enkripsi deterministik hanya dengan AES-SIV): Perlindungan Data Sensitif menambahkan anotasi surrogate opsional ke nilai terenkripsi. Anotasi surrogate membantu mengidentifikasi nilai surrogate yang dienkripsi dengan menambahkan string deskriptif yang Anda tentukan. Misalnya, tanpa anotasi, Anda mungkin tidak dapat membedakan nomor telepon yang telah dide-identifikasi dan Jaminan Sosial yang telah dide-identifikasi atau nomor identifikasi lainnya. Selain itu,
untuk mengidentifikasi ulang nilai dalam data tidak terstruktur yang telah dide-identifikasi menggunakan
format yang mempertahankan enkripsi atau enkripsi deterministik, Anda harus
menentukan anotasi surrogate. (Anotasi surrogate tidak diperlukan saat
mengubah kolom data terstruktur, atau tabel, dengan
RecordTransformation.)
Langkah 5 (Format mempertahankan dan enkripsi deterministik hanya dengan AES-SIV data terstruktur): Perlindungan Data Sensitif dapat menggunakan konteks opsional dari kolom lain untuk "menyesuaikan" token yang dihasilkan. Dengan begitu, Anda dapat 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 "di-tweak" oleh ID kampanye. Cara ini akan memungkinkan seseorang menggabungkan data untuk pengguna yang sama dalam kampanye yang sama, tetapi tidak di berbagai kampanye yang berbeda. Jika penyesuaian konteks digunakan untuk membuat token, penyesuaian konteks ini juga diperlukan agar transformasi de-identifikasi dapat dikembalikan. Mempertahankan format dan enkripsi 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 dengan token
Bagian ini menunjukkan tampilan token standar setelah dide-identifikasi menggunakan masing-masing 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, jika perlu, setiap penyesuaian konteks yang ditentukan) dienkripsi menggunakan AES-SIV dengan kunci kriptografis, dienkode menggunakan base64, lalu secara opsional ditambahkan dengan anotasi surrogate, jika ditentukan. Metode ini tidak mempertahankan himpunan karakter (atau "alfabet") dari nilai input. Untuk menghasilkan output yang dapat dicetak, nilai yang dihasilkan dienkode dalam base64.
Token yang dihasilkan, dengan asumsi infoType surrogate telah ditentukan, akan berbentuk:
SURROGATE_INFOTYPE(SURROGATE_VALUE_LENGTH):SURROGATE_VALUE
Diagram yang dianotasi berikut menunjukkan token contoh, yaitu output operasi de-identifikasi yang menggunakan enkripsi deterministik dengan AES-SIV pada nilai 1-206-555-0123. infoType surrogate opsional telah ditetapkan ke NAM_PHONE_NUMB:
- Anotasi surrogate
- InfoType surrogate (ditentukan oleh pengguna)
- Panjang karakter dari nilai yang ditransformasi
- Nilai surrogate (ditransformasi)
Jika Anda tidak menentukan anotasi surrogate, token yang dihasilkan sama dengan
nilai yang ditransformasi, atau #4 dalam diagram yang dianotasi. Untuk mengidentifikasi ulang
data tidak terstruktur, seluruh token ini diperlukan, termasuk anotasi
surrogate. Saat mengubah data terstruktur seperti tabel, anotasi surrogate bersifat opsional; Perlindungan Data Sensitif dapat melakukan de-identifikasi dan identifikasi ulang di seluruh kolom menggunakan RecordTransformation tanpa anotasi surrogate.
Enkripsi dengan mempertahankan format
Dengan de-identifikasi menggunakan enkripsi yang mempertahankan format, nilai input (dan, secara opsional, setiap penyesuaian konteks tertentu) dienkripsi menggunakan mode enkripsi perlindungan format FFX ("FPE-FFX") dengan kunci kriptografis, kemudian ditambahkan secara opsional dengan anotasi surrogate jika ditentukan.
Tidak seperti metode tokenisasi lain yang dijelaskan dalam topik ini, nilai pengganti output memiliki panjang yang sama dengan nilai input, dan tidak dienkode menggunakan base64. Anda menentukan himpunan karakter—atau "alfabet"—yang terdiri dari nilai terenkripsi. Ada tiga cara untuk menentukan alfabet Perlindungan Data Sensitif yang akan digunakan dalam nilai output:
- Gunakan salah satu dari empat nilai terenumerasi yang mewakili empat himpunan 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 menyertakan semua karakter numerik, karakter alfa huruf besar, karakter alfa huruf kecil, dan karakter simbol. - Buat alfabet dengan mencantumkan karakter yang tepat untuk digunakan. Misalnya, menentukan
1234567890-*akan menghasilkan nilai surrogate yang hanya terdiri dari angka, tanda hubung, dan tanda bintang.
Tabel berikut mencantumkan empat himpunan karakter umum berdasarkan masing-masing
nilai terenumerasi
(FfxCommonNativeAlphabet),
nilai radix, dan daftar karakter kumpulan. Baris terakhir mencantumkan kumpulan
karakter lengkap, yang sesuai dengan nilai radix maksimum.
| Nama himpunan karakter/alfabet | 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 surrogate telah ditentukan, akan berbentuk:
SURROGATE_INFOTYPE(SURROGATE_VALUE_LENGTH):SURROGATE_VALUE
Diagram yang dianotasi berikut adalah output dari operasi de-identifikasi
Perlindungan Data Sensitif menggunakan enkripsi yang mempertahankan format pada nilai
1-206-555-0123 menggunakan radix 95. infoType surrogate opsional telah ditetapkan ke NAM_PHONE_NUMB:
- Anotasi surrogate
- InfoType surrogate (ditentukan oleh pengguna)
- Panjang karakter dari nilai yang ditransformasi
- Nilai surrogate (diubah)—panjangnya sama dengan nilai input
Jika Anda tidak menentukan anotasi surrogate, token yang dihasilkan sama dengan
nilai yang ditransformasi, atau #4 dalam diagram yang dianotasi. Untuk mengidentifikasi ulang
data tidak terstruktur, seluruh token ini diperlukan, termasuk anotasi
surrogate. Saat mengubah data terstruktur seperti tabel, anotasi surrogate bersifat opsional; Perlindungan Data Sensitif dapat melakukan de-identifikasi dan mengidentifikasi ulang di seluruh kolom menggunakan RecordTransformation tanpa surrogate.
{i>Hashing <i}kriptografis
Dengan de-identifikasi menggunakan hashing kriptografi, nilai input di-hash menggunakan HMAC-SHA-256 dengan kunci kriptografis, lalu dienkode menggunakan base64. Nilai yang dide-identifikasi selalu memiliki panjang yang seragam, bergantung pada ukuran kunci.
Tidak seperti metode tokenisasi lainnya yang dibahas dalam topik ini, hash kriptografi membuat token satu arah. Artinya, de-identifikasi menggunakan hash kriptografi tidak dapat dibatalkan.
Berikut adalah output dari operasi de-identifikasi menggunakan hashing kriptografi pada nilai 1-206-555-0123. Output ini adalah representasi nilai hash yang berenkode base64:
XlTCv8h0GwrCZK+sS0T3Z8txByqnLLkkF4+TviXfeZY=
Menggunakan kunci kriptografis
Ada tiga opsi kunci kriptografis yang dapat Anda gunakan dengan metode de-identifikasi kriptografi di Perlindungan Data Sensitif:
Kunci kriptografis gabungan 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 di Cloud Key Management Service. Jenis kunci ini disimpan di Cloud KMS untuk identifikasi ulang nanti. Untuk mengetahui informasi selengkapnya tentang cara membuat dan menggabungkan kunci dengan tujuan de-identifikasi dan mengidentifikasi ulang, lihat Panduan memulai: Melakukan de-identifikasi dan mengidentifikasi ulang teks sensitif.
Kunci kriptografis sementara: Kunci kriptografis sementara dihasilkan oleh Perlindungan Data Sensitif pada saat de-identifikasi, lalu dihapus. Karena alasan ini, jangan gunakan kunci kriptografis sementara dengan metode de-identifikasi kriptografi apa pun yang ingin Anda balikkan. Kunci kriptografis sementara hanya menyimpan integritas per permintaan API. Jika Anda memerlukan integritas di lebih dari satu permintaan API atau berencana mengidentifikasi ulang data Anda, jangan gunakan jenis kunci ini.
Kunci kriptografis yang belum digabungkan: Kunci yang tidak digabungkan adalah kunci kriptografis mentah berenkode base64, 128-, 192-, atau 256-bit, yang Anda berikan dalam permintaan de-identifikasi ke DLP API. Anda bertanggung jawab untuk menjaga keamanan kunci kriptografis ini untuk identifikasi ulang nanti. 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 ke nilai terenkripsi yang sama. Dalam situasi dengan data atau pola data berulang, risiko identifikasi ulang meningkat. Sebagai gantinya, agar nilai input yang sama selalu diubah ke nilai terenkripsi yang berbeda, Anda dapat menentukan tweet konteks yang unik.
Anda menentukan penyesuaian konteks (disebut hanya
context
dalam DLP API) saat mengubah data tabel, karena penyesuaian tersebut
secara efektif merupakan pointer ke kolom data, seperti ID.
Perlindungan Data Sensitif menggunakan nilai dalam kolom yang ditentukan oleh tweak konteks saat mengenkripsi nilai input. Untuk memastikan bahwa nilai yang dienkripsi
selalu berupa nilai unik, tentukan kolom untuk penyesuaian yang berisi ID
unik.
Pertimbangkan contoh sederhana ini. Tabel berikut menunjukkan beberapa rekam medis, beberapa di antaranya berisi 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 melakukan de-identifikasi ID pasien dalam tabel, fitur ini akan melakukan de-identifikasi ID pasien berulang ke nilai yang sama secara default, seperti yang ditunjukkan pada tabel berikut. Misalnya, kedua instance ID pasien "43789" dide-identifikasi menjadi "47222". (Kolom patient_id menunjukkan nilai token setelah pseudonimisasi menggunakan FPE-FFX dan tidak menyertakan anotasi surrogate. Lihat Format yang mempertahankan enkripsi 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 berada di seluruh set data.
Untuk mempersempit cakupan agar Anda dapat menghindari perilaku ini, tentukan penyesuaian konteks. Anda dapat menentukan kolom mana pun sebagai penyesuaian konteks, tetapi untuk menjamin bahwa setiap nilai yang dide-identifikasi bersifat unik, tentukan kolom yang setiap nilainya adalah 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 akan menentukan kolom icd10_codes sebagai penyesuaian konteks.
Tabel ini adalah tabel setelah melakukan de-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 yang dide-identifikasi keempat dan kelima (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 inilah yang Anda cari.
Untuk memutuskan integritas referensial sepenuhnya antara nilai patient_id dan
nilai icd10_codes, Anda dapat menggunakan kolom record_id sebagai penyesuaian
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 telah dide-identifikasi dalam tabel sekarang bersifat unik.
Untuk mempelajari cara menggunakan penyesuaian konteks dalam DLP API, perhatikan penggunaan
context dalam topik referensi metode transformasi berikut:
- Enkripsi yang mempertahankan format:
CryptoReplaceFfxFpeConfig - Enkripsi deterministik menggunakan AES-SIV:
CryptoDeterministicConfig - Pergeseran tanggal:
DateShiftConfig
Langkah selanjutnya
Pelajari contoh kode yang menunjukkan cara melakukan token data sensitif.
Pelajari cara melakukan de-identifikasi data menggunakan DLP API.