😣 👩‍💼 👯 Kerusakan seksual bukan hanya pengacakan 🐀 👰🏼 👨🏼‍⚕️

Ada masalah di bank: pengembang dan penguji perlu diberi akses ke database. Ada banyak data klien yang tidak dapat digunakan untuk pengungkapan ke departemen pengembangan dan pengujian sesuai dengan persyaratan PCI DSS dari Bank Sentral dan undang-undang data pribadi.

Tampaknya hanya mengubah segalanya menjadi hash asimetris sudah cukup dan semuanya akan baik-baik saja.

Jadi tidak akan.

Faktanya adalah bahwa database bank adalah seperangkat tabel yang saling berhubungan. Di suatu tempat mereka terhubung dengan nama dan nomor akun pelanggan. Di suatu tempat oleh pengidentifikasi uniknya. Di suatu tempat (di sini rasa sakit dimulai) melalui prosedur tersimpan yang menghitung pengenal pass-through berdasarkan ini dan tabel tetangga. Dll

Situasi yang biasa terjadi adalah bahwa pengembang versi pertama sistem telah mati atau pergi sepuluh tahun yang lalu, dan sistem kernel yang berjalan di hypervisor lama di dalam hypervisor baru (untuk memastikan kompatibilitas) masih ada di prod.

Artinya, sebelum menganonimkan semua ini, Anda harus terlebih dahulu memahami database.

Siapa yang melakukan depersonalisasi dan mengapa?

Mereka terlibat dalam depersonalisasi atau penyamaran karena ada hukum dan standar. Ya, jauh lebih baik untuk menguji "snapshot penjualan", tetapi regulator dapat mencabut lisensi untuk penerbangan semacam itu. Yaitu, untuk menutupi bisnis seperti itu.

Setiap depersonalisasi adalah lapisan yang agak mahal dan canggung antara sistem produktif dan pengujian pengembangan.

Tujuan dari proyek anonimisasi (penyembunyian) hampir selalu untuk mempersiapkan data uji yang sama mungkin dengan yang nyata disimpan dalam database produktif. Artinya, jika data mengandung kesalahan - alih-alih email, telepon tersumbat, bukan alfabet Cyrillic dalam nama keluarga Latin, dll., Maka data yang disamarkan harus memiliki kualitas yang sama, tetapi diubah tanpa bisa dikenali. Tujuan kedua adalah untuk mengurangi volume basis data yang digunakan dalam pengujian dan pengembangan. Volume penuh hanya tersisa untuk pengujian beban, dan untuk sisa tugas, irisan data tertentu biasanya dilakukan sesuai dengan aturan yang telah ditentukan - pemotongan basis data. Tujuan ketiga adalah untuk mendapatkan data terkait di berbagai basis data yang disamarkan dan terpotong. Ini berarti bahwa data dalam sistem yang berbeda, pada waktu yang berbeda, harus dianonimkan secara seragam.

Dalam hal kompleksitas komputasi, depersonalisasi hampir sama dengan beberapa arsip basis data dengan kompresi ekstrem. Algoritma ini kira-kira mirip. Perbedaannya adalah bahwa algoritma pengarsipan telah diasah selama bertahun-tahun dan telah mencapai efisiensi yang hampir maksimal. Dan algoritma depersonalisasi ditulis sehingga mereka setidaknya bekerja pada basis saat ini dan cukup universal. Dan perangkat lunak setelah depersonalisasi umumnya bekerja. Itu adalah hasil yang sangat baik - untuk menggiling 40 TB per malam. Kebetulan bahwa lebih murah bagi pelanggan untuk mengarahkan basis data ke depersonalisasi sekali setiap enam bulan selama seminggu di server yang lemah - juga sebuah pendekatan.

Bagaimana data diganti?

Setiap tipe data berubah sesuai dengan aturan yang dapat digunakan dalam kode. Misalnya, jika kita mengganti nama dengan hash acak dengan karakter dan angka khusus, maka validasi data pertama akan segera menghasilkan kesalahan dalam pengujian nyata.

Oleh karena itu, pertama-tama sistem depersonalisasi harus menentukan tipe data apa yang disimpan di lapangan. Bergantung pada vendor, pendekatan yang berbeda digunakan, dari markup manual hingga upaya menemukan basis data dan mendeteksi secara otomatis apa yang disimpan di sana. Kami memiliki praktik memperkenalkan semua solusi utama di pasar. Kami akan menganalisis salah satu opsi ketika ada wizard yang mencoba mencari data dan "menebak" jenis data apa yang disimpan di sana.

Tentu saja, untuk bekerja dengan perangkat lunak ini, Anda memerlukan akses ke data nyata (biasanya ini adalah salinan cadangan baru-baru ini dari basis data). Menurut pengalaman perbankan, kami pertama-tama menandatangani satu ton kertas selama dua bulan, dan kemudian kami datang ke bank, kami membuka pakaian, mencari dan berpakaian, kemudian kami pergi ke ruang terpisah, dikurung dengan kandang Faraday, di mana ada dua penjaga keamanan dan bernapas dengan hangat di belakang kepala kami.

Jadi, misalkan, setelah semua ini, kita melihat tabel di mana ada bidang "Nama". Wisaya telah menandainya untuk kami sebagai nama, dan kami hanya dapat mengonfirmasi dan memilih jenis depersonalisasi. Wisaya menawarkan pengganti acak untuk nama Slavik (ada pangkalan untuk berbagai wilayah). Kami setuju dan mendapatkan pengganti seperti Ivan Ivanov Petrenko - Joseph Albertovich Chingachguk. Jika ini penting, jenis kelamin dipertahankan, jika tidak, penggantian dilakukan di seluruh basis data nama.

Contoh penggantian:

. ->
->
->
->
-> -

Bidang selanjutnya adalah tanggal di Unixtime. Wizard juga menentukan hal ini, tetapi kita perlu memilih fungsi depersonalisasi. Biasanya, kurma digunakan untuk mengontrol urutan peristiwa, dan situasi ketika klien pertama kali melakukan transfer di bank dan kemudian membuka rekening, tidak ada yang benar-benar perlu menguji. Karena itu, kami menetapkan delta kecil - secara default, dalam waktu 30 hari. Masih akan ada kesalahan, tetapi jika ini penting, Anda dapat mengonfigurasi aturan yang lebih kompleks dengan menambahkan skrip Anda ke pemrosesan anonimisasi.

Alamat harus divalidasi, sehingga basis data alamat Rusia digunakan. Nomor kartu harus sesuai dengan angka sebenarnya dan divalidasi olehnya. Kadang-kadang tugasnya adalah untuk "membuat semua Visa Mastercard acak" - ini juga layak dalam beberapa klik.
Di bawah kap penyihir adalah profil. Profiling adalah pencarian data dalam database sesuai dengan aturan yang telah ditentukan (atribut, domain). Faktanya, kami membaca setiap sel dari basis data pelanggan, menerapkan serangkaian ekspresi reguler untuk setiap sel, membandingkan nilai-nilai dalam sel ini dengan kamus, dll. Sebagai hasilnya, kami memiliki serangkaian aturan yang dipicu pada kolom tabel database. Kami dapat mengonfigurasi profil, kami tidak dapat membaca semua tabel dalam database, kami hanya dapat mengambil sejumlah baris dari tabel atau persentase tertentu dari baris.

Apa yang sedang terjadi di dalam?

Untuk setiap entri dalam database, aturan depersonalisasi yang telah kami pilih berlaku. Dalam hal ini, tabel sementara dibuat selama durasi proses, di mana penggantian ditulis. Setiap catatan berikutnya dalam database dijalankan sesuai dengan tabel korespondensi penggantian ini, dan jika ada korespondensi di sana, itu diganti dengan cara yang sama seperti sebelumnya. Semuanya sebenarnya sedikit lebih rumit, tergantung pada skrip dan aturan pencocokan pola Anda (mungkin ada penggantian yang tidak akurat, misalnya, untuk melahirkan atau mengganti tanggal yang disimpan dalam format yang berbeda), tetapi ide umumnya adalah itu.

Jika ada korespondensi yang ditandai "namanya Cyrillic - namanya Latin", maka mereka harus ditunjukkan dengan jelas pada tahap pengembangan, dan kemudian di tabel substitusi mereka akan saling berhubungan. Artinya, nama tersebut akan dianonimkan dalam Cyrillic, dan kemudian entri yang dianonimkan ini akan dikonversi ke alfabet Latin, misalnya. Pada titik ini, kami bergerak menjauh dari pendekatan "jangan meningkatkan kualitas data dalam sistem", tetapi ini adalah salah satu kompromi yang harus Anda buat demi semacam kinerja sistem. Praktek menunjukkan bahwa jika stress, pengujian fungsional tidak melihat adanya kompromi dalam pekerjaannya, maka tidak ada apa-apa. Dan inilah titik penting bahwa depersonalisasi secara keseluruhan bukanlah enkripsi. Jika Anda memiliki beberapa yard entri dalam tabel, dan dalam sepuluh di antaranya TIN belum berubah, lalu apa? Tidak ada, sepuluh catatan ini tidak dapat ditemukan.

Setelah akhir proses, tabel konversi tetap dalam database yang dilindungi server depersonalisasi. Basis dipotong (terpotong) dan dilewatkan ke pengujian tanpa tabel konversi, dengan demikian, untuk tester, depersonalisasi menjadi ireversibel.

Basis data anonim lengkap diteruskan ke penguji untuk pengujian stres.

Ini berarti bahwa saat bekerja dengan database, tabel konversi "membengkak" (jumlah yang tepat tergantung pada pilihan penggantian dan jenisnya), tetapi basis kerja tetap ukuran asli.

Seperti apa prosesnya di antarmuka operator?

Tampilan umum IDE menggunakan salah satu vendor sebagai contoh:

Debugger:

Memulai transformasi dari IDE:

Mengkonfigurasi ekspresi untuk mencari data sensitif di profiler:

Halaman dengan seperangkat aturan untuk profiler:

Halaman profiler, halaman web dengan pencarian data:

Apakah semua data dalam database ditutup?

Tidak. Biasanya, daftar data untuk depersonalisasi diatur oleh undang-undang dan standar lingkup, ditambah pelanggan memiliki saran untuk bidang-bidang tertentu yang tidak seorang pun harus tahu tentang.

Logikanya adalah bahwa jika kita menutupi nama pasien di rumah sakit, Anda dapat menutupi atau tidak menutupi diagnosis - masih tidak ada yang akan tahu dari siapa dia berasal. Kami memiliki kasus ketika catatan tentang transaksi di bank hanya ditutupi dengan huruf acak. Ada catatan tingkat: "Pinjaman itu ditolak, karena klien mabuk, dia muntah ke bar." Dari sudut pandang debugging, itu hanya serangkaian karakter. Baiklah, biarkan dia tinggal.

Contoh strategi:

Tabel seed dinamis adalah tabel transcoding di mana kita menambahkan pengodean ulang yang telah terjadi. Hash bisa sangat berbeda dan dalam kasus TIN yang sama, lebih sering TIN acak baru dihasilkan dengan karakter pertama disimpan, dengan digit periksa.

Apakah mungkin mengubah data menggunakan DBMS itu sendiri?

Iya. Saat depersonalisasi data, ada dua pendekatan utama - mengubah data dalam database menggunakan database itu sendiri atau mengatur proses ETL dan mengubah data menggunakan perangkat lunak pihak ketiga.

Kunci plus dari pendekatan pertama adalah bahwa Anda tidak perlu mengeluarkan data dari basis data di mana pun, tidak ada biaya jaringan, dan alat basis data yang cepat dan dioptimalkan digunakan. Minus kunci adalah pengembangan terpisah untuk setiap sistem, kurangnya tabel konversi umum untuk sistem yang berbeda. Tabel konversi diperlukan untuk reproduktifitas depersonalisasi, integrasi data lebih lanjut antara sistem.

Keuntungan utama dari pendekatan kedua adalah bahwa tidak menjadi masalah basis data, sistem, file apa, atau semacam antarmuka web - setelah Anda menerapkan aturan, Anda dapat menggunakannya di mana saja. Kunci minusnya adalah Anda perlu membaca data dari database, memprosesnya dengan aplikasi terpisah, menulisnya kembali ke database.

Praktek menunjukkan bahwa jika pelanggan memiliki seperangkat beberapa sistem yang memerlukan integrasi lebih lanjut, maka hanya pendekatan kedua yang dapat diimplementasikan untuk biaya akhir dalam bentuk uang, serta untuk waktu pengembangan yang dapat diterima.

Yaitu, kita dapat melakukan apa pun yang kita inginkan, tetapi pendekatan ETL telah membuktikan dirinya dengan sangat baik di sektor perbankan.

Dan mengapa data tidak rusak secara manual?

Ini bisa dilakukan sekali. Seseorang akan duduk selama tiga hari, menghilangkan identitas sekelompok data dan menyiapkan basis data 500-1000 catatan. Kesulitannya adalah bahwa proses tersebut harus diulangi secara teratur (dengan setiap perubahan dalam struktur basis data dan tampilan bidang dan tabel baru) dan dalam volume besar (untuk berbagai jenis pengujian). Permintaan umum adalah untuk mengurangi 10-50 GB basis data pertama sehingga jumlah ini jatuh pada setiap tabel secara merata.

Apa yang harus dilakukan jika pemindaian dokumen disimpan dalam database?

Jika suatu dokumen dapat direduksi menjadi XML dan dikonversi kembali (misalnya, dokumen kantor), Anda juga dapat menghilangkan identitasnya. Namun terkadang ada binari seperti pemindaian paspor dalam PDF / JPG / TIFF / BMP. Dalam hal ini, praktik yang diterima secara umum adalah menyediakan dokumen yang serupa dengan skrip pihak ketiga dan mengganti yang asli dengan sampel dari pangkalan yang dihasilkan secara acak. Hal yang paling sulit adalah dengan foto, tetapi ada layanan seperti ini yang menyelesaikan masalah dengan cara yang hampir sama.

Siapa yang bertanggung jawab atas apa?

Saat memperbarui setelah mengubah perangkat lunak atau "mengejar ketinggalan", prosesnya lebih sederhana.

Tapi bagaimana jika ada yang salah dalam tes?

Ini biasanya terjadi. Pertama, penguji, setelah menjalankan depersonalisasi pertama, lebih tepatnya merumuskan persyaratan untuk database. Kita dapat mengubah aturan depersonalisasi atau menolak catatan seperti "di sini tindakan harus berjalan dalam urutan kronologis, dan bukan dalam kekacauan". Kedua, tergantung pada implementasinya, kami mendukung depersonalisasi saat database berubah, atau meninggalkan semua dokumentasi, deskripsi struktur database, dan jenis pemrosesan, mentransfer seluruh kode pemrosesan (aturan dalam xml / sql), dan melatih spesialis dari pelanggan.

Bagaimana cara menonton demo?

Cara termudah adalah dengan mengirim email kepada saya di PSemenov@technoserv.com.

Kerusakan seksual bukan hanya pengacakan