Menurut Simson L. Garfinkel di Laboratorium Teknologi Informasi Divisi Akses Informasi NIST,
De-identifikasi bukanlah teknik tunggal, tetapi kumpulan pendekatan, algoritme, dan alat yang dapat diterapkan pada berbagai jenis data dengan tingkat efektivitas yang berbeda. Secara umum, perlindungan privasi meningkat karena teknik de-identifikasi yang lebih agresif digunakan, tetapi lebih sedikit utilitas yang tersisa dalam kumpulan data yang dihasilkan.
-De-Identifikasi Informasi Pribadi, NISTIR 8053
Penyembunyian data statis (SDM) adalah istilah yang diakui industri untuk berbagai cara de-identifikasi elemen data saat istirahat ini. Elemen biasanya kolom database atau nilai bidang file datar yang dianggap sensitif; dalam industri kesehatan, mereka disebut sebagai pengidentifikasi kunci. Khususnya yang berisiko adalah informasi pengenal pribadi (PII), informasi kesehatan yang dilindungi (PHI), nomor rekening utama (PAN), rahasia dagang, atau nilai sensitif lainnya.
Produk keamanan sentris data “titik awal” IRI FieldShield — atau produk IRI CoSort dan platform IRI Voracity yang mencakup kemampuan yang sama — menyediakan beberapa penemuan data dan fungsi SDM untuk berbagai sumber data. Fungsi masking per bidang/kolom yang tersedia meliputi:
- multiple, NSA Suite B dan algoritma enkripsi (dan dekripsi) yang sesuai dengan FIPS, termasuk mempertahankan format enkripsi
- Hashing SHA-1 dan SHA-2
- de-ID ASCII (sedikit mengacak)
- pengodean dan penguraian kode biner
- pengkaburan atau pengelompokan data (anonimisasi)
- generasi atau pemilihan acak
- redaksi (kebingungan karakter)
- nama samaran yang dapat dibalik dan tidak dapat dibalik
- logika ekspresi khusus (perhitungan / acak)
- pemfilteran atau penghapusan nilai bersyarat / parsial (penghilangan)
- pengganti nilai khusus
- pergeseran byte dan fungsi string
- tokenisasi (untuk PCI)
Anda juga dapat "menggulung sendiri" fungsi penyembunyian data eksternal. Ini memungkinkan Anda untuk memanggil rutin tingkat bidang yang ditulis khusus saat runtime alih-alih built-in.
Pertanyaannya tetap, fungsi masking mana yang harus saya gunakan (pada setiap item)? Itu tergantung pada kebutuhan dan aturan bisnis Anda, serta undang-undang privasi data yang berlaku. Pada tingkat teknis, itu biasanya berarti memutuskan bagaimana ciphertext (data terselubung) yang dihasilkan perlu muncul, jika perlu dapat dibalik atau unik, seberapa amannya, dan mungkin, jenis sumber daya komputasi dan waktu apa yang tersedia untuk proses tersebut. . Mari kita lihat kriteria keputusan umum ini secara mendetail:
Penampilan (Realisme)
Haruskah data yang baru disamarkan terlihat kurang lebih seperti data asli? Bagaimana dengan ukuran dan formatnya? Enkripsi pseudonim dan pelestarian format adalah dua cara paling umum untuk
mempertahankan tampilan dan nuansa masing-masing kata benda dan nomor alfa-digit akun atau telepon. Tetapi penyembunyian substring (a/k/a redaksi bidang parsial, mis., XXX-XX-1234) mungkin baik-baik saja untuk hal-hal seperti SSN. Pikirkan tentang kegigihan dan tampilan data untuk analitik, dll.
Terkait dengan hal tersebut, tampilan dan realisme ciphertext juga dapat menentukan usability dari hasil. Target aplikasi dan tabel database (utilitas beban) mungkin mengharuskan format data tidak hanya sesuai dengan struktur yang telah ditentukan sebelumnya, tetapi terus bekerja dalam kueri atau konteks operasional lainnya di hilir.
Dengan kata lain, jika data tertutup yang cantik dan/atau data fungsional diperlukan, jangan gunakan redaksi penuh, pengacakan, hashing, atau enkripsi langsung (yang memperlebar dan mengaburkan hasil). Anda mungkin dapat lolos dengan penyesuaian yang lebih kecil seperti penuaan dan manipulasi sub-string, tetapi pertimbangkan dampak dari pilihan ini pada kriteria keputusan Anda yang lain ...
Reversibilitas (Identifikasi Ulang)
Perlu data asli dipulihkan? Jawabannya mungkin bergantung pada apakah Anda membiarkan data sumber itu sendiri, seperti yang Anda lakukan dalam penyembunyian data dinamis, atau saat Anda menulis data terselubung ke target baru. Dalam kasus tersebut, jawabannya adalah tidak.
Jika jawabannya tidak, Anda mungkin masih membutuhkan realisme, dalam hal ini nama samaran yang tidak dapat dibalik mungkin merupakan pilihan terbaik Anda. Jika tidak dan penampilan tidak masalah, lanjutkan dengan redaksi karakter. Dan jika keduanya tidak benar, pertimbangkan untuk menghapus kolom sumber dari target.
Jika jawabannya ya, fungsi penyembunyian data IRI seperti enkripsi, pseudonimisasi atau tokenisasi yang dapat dibalik, penyandian, atau ID ulang ASCII (pengacakan bit) ditunjukkan. Dalam kasus penggunaan yang lebih lanjut, Anda mungkin juga memerlukan pembalikan diferensial; yaitu, ketika penerima yang berbeda dari target yang sama diberi wewenang untuk melihat hal yang berbeda dalam kumpulan data yang sama. Dalam kasus seperti itu, kunci enkripsi pribadi, skrip pekerjaan wahyu khusus pengguna, atau bahkan aplikasi khusus dapat digunakan.
Keunikan (Konsistensi)
Apakah nilai asli yang sama selalu perlu diganti dengan nilai pengganti yang sama, tetapi berbeda? Apakah data akan digabungkan, atau dikelompokkan berdasarkan, nilai penggantinya? Jika demikian, maka algoritme pengganti yang dipilih harus menghasilkan hasil yang unik dan dapat diulang untuk mempertahankan integritas referensial meskipun penyembunyian telah terjadi.
Ini dapat dicapai melalui enkripsi ketika algoritma dan frasa sandi (kunci) yang sama digunakan terhadap teks biasa yang sama. Klasifikasi data dan panduan perlindungan tabel silang di IRI Workbench IDE untuk FieldShield, Voracity, dll. memfasilitasi ini melalui aplikasi tabel silang (atau lebih global) dari aturan masking yang cocok. Dengan cara ini, nilai plaintext yang sama selalu mendapatkan hasil ciphertext yang sama terlepas dari lokasinya.
Namun, nama samaran lebih rumit di sini, karena kekurangan nama pengganti yang unik, nama asli duplikat, dan perubahan ( menyisipkan, memperbarui, atau menghapus) ke nilai asli dalam tabel atau file sumber. IRI membahas masalah pseudonimisasi lintas tabel yang konsisten dalam contoh alur kerja Voracity ini.
Kekuatan (Keamanan)
Melihat algoritme di dalam setiap fungsi dapat membantu Anda menentukan "kemampuan retak" relatifnya, dan menilainya berdasarkan pertimbangan ciphertext lainnya seperti penampilan dan kecepatan. Misalnya, fungsi AES256 IRI lebih kuat daripada opsi AES128, SHA2 lebih kuat dari SHA1, dan semuanya lebih kuat dari fungsi encode/decode base64 dan ASCII de-ID/re-ID function.
Menurut definisi, fungsi reversibel biasanya lebih lemah daripada yang tidak dapat dibalik. Misalnya, metode pseudonimisasi ireversibel (set pencarian asing) IRI lebih aman daripada metode pseudonim reversibel (set orisinal yang diacak). Meskipun demikian, algoritme enkripsi AES-256 bisa sangat sulit untuk dipecahkan jika kuncinya juga hilang.
Keamanan yang lebih kuat tentu saja penghilangan, diikuti oleh pengaburan karakter (redaksi), yang tidak dapat diubah. Tetapi kelemahannya adalah kurangnya kegunaan. Dalam konteks pelabuhan aman HIPAA, penghapusan pengidentifikasi kunci sesuai. Namun, jika Anda perlu menggunakan bagian mana pun dari data sumber untuk analisis, penelitian, pemasaran, atau demonstrasi, Anda akan memerlukan fungsi penyembunyian, dan seorang ahli untuk menentukan (dan menyatakan) bahwa teknik Anda memiliki statistik yang rendah. kemungkinan identifikasi ulang.
Sementara kami membahas masalah de-identifikasi HIPAA, ingatlah bahwa mungkin juga ada risiko yang terkait dengan apa yang disebut pengidentifikasi kuasi (seperti kode pos dan usia). Nilai-nilai tersebut dapat digunakan bersama dengan kumpulan data lain untuk menetapkan jejak identifikasi ulang, dan dengan demikian juga layak untuk ditutup-tutupi dalam banyak kasus; apakah dan bagaimana tunduk pada pertimbangan yang sama ini.
Komputasi (Kinerja)
Salah satu hal baik tentang pendekatan penyamaran data — bahkan ketika algoritma enkripsi intensif komputasi terlibat — adalah bahwa overhead relatif terhadap enkripsi broad-brush (dari seluruh jaringan, database, file/sistem, disk drive) jauh lebih rendah. Hanya elemen data (nilai kolom) yang Anda tetapkan untuk perlindungan yang perlu diserap, diproses oleh, dan dikembalikan dari, fungsi penyembunyian.
Secara umum, semakin kompleks (dan kuat) algoritme, semakin lama waktu yang dibutuhkan untuk diterapkan. Kecepatan penyamaran data juga akan bergantung pada jumlah fungsi yang diterapkan, jumlah kolom dan baris DB, jumlah batasan pencarian yang harus diperhatikan dalam proses (untuk integritas referensial), bandwidth jaringan, RAM, I/O, proses bersamaan, dan segera.
Bagan non-ilmiah berikut memecah sebagian besar atribut yang dijelaskan di atas untuk referensi yang nyaman, untuk beberapa (tetapi tidak semua!) mendukung kategori fungsional penyembunyian data IRI, dan secara umum relatif saja. Tak perlu dikatakan lagi, IRI menyangkal jaminan kesesuaian atau kewajiban apa pun untuk bagan ini!
Fungsi Penyembunyian Data IRI (di FieldShield &Voracity)
Baik Anda menggunakan fungsi penyembunyian data IRI bawaan, atau fungsi kustom yang Anda tentukan, idenya adalah untuk menerapkannya berdasarkan aturan bisnis Anda ke baris atau kolom tertentu dan/atau di seluruh tabel. Dan Anda akan melakukannya melalui aturan penyembunyian data yang dapat Anda tetapkan, simpan, dan gunakan kembali. Dimungkinkan juga (dan lebih disukai) untuk menerapkan fungsi penyembunyian data ini terhadap data yang diklasifikasikan secara otomatis sebagai aturan untuk kenyamanan dan konsistensi. Dan Anda dapat memanfaatkan beberapa di antaranya dalam aplikasi penyamaran data dinamis melalui panggilan API.
Pengguna FieldShield (atau Voracity) dapat membuat, menjalankan, dan mengelola pekerjaan penyembunyian data Anda dalam GUI gratis yang canggih, yang dibangun di atas Eclipse.™ Atau, mereka dapat mengedit dan menjalankan skrip 4GL yang kompatibel dan terdokumentasi sendiri. sumber/target data dan fungsi penyamaran, dan jalankan skrip tersebut pada baris perintah.
Untuk informasi selengkapnya, lihat https://www.iri.com/solutions/data-masking atau hubungi perwakilan IRI Anda.
