Data pelanggan sering dijaga ketat ketika berada di lingkungan production. Aksesnya dibatasi, aktivitas dicatat, jaringan dipisahkan, dan setiap perubahan harus melalui proses persetujuan.

Perlindungan tersebut dapat berubah ketika database yang sama disalin ke staging.

Nama, alamat, nomor telepon, riwayat transaksi, dokumen, hingga informasi keuangan kemudian berada di lingkungan yang digunakan oleh lebih banyak orang. Kontrol aksesnya belum tentu seketat production, sementara monitoring dan pembaruan keamanannya sering tidak menjadi prioritas utama.

Secara teknis, penyalinan tersebut mempercepat pengujian. Namun, dari sudut pandang keamanan, perusahaan baru saja menciptakan lokasi tambahan yang menyimpan data bernilai tinggi.

Data tidak menjadi kurang sensitif hanya karena dipindahkan ke environment non-production.

Data Production Memang Membuat Pengujian Lebih Realistis

Keputusan menggunakan data production biasanya muncul dari kebutuhan yang wajar. Tim developer dan quality assurance membutuhkan data yang cukup beragam untuk menguji aplikasi dalam kondisi yang mendekati penggunaan sebenarnya.

Data production memiliki pola yang sulit dibuat secara manual. Hubungan antartabel sudah terbentuk, volume transaksi lebih representatif, dan berbagai kasus tidak umum dapat ditemukan di dalamnya.

Beberapa bug juga hanya muncul pada kombinasi data tertentu. Masalah migrasi, perhitungan, duplikasi, integrasi, dan performa sering lebih mudah direproduksi menggunakan data yang berasal dari sistem sebenarnya.

Karena alasan tersebut, menyalin database production terlihat sebagai cara paling cepat untuk menyiapkan staging environment.

Persoalannya bukan pada kebutuhan untuk melakukan pengujian realistis. Risikonya muncul ketika seluruh database disalin tanpa menilai data mana yang benar-benar diperlukan.

Satu Salinan Baru Berarti Satu Target Baru

Ketika database production disalin, risiko tidak hanya berpindah. Risiko tersebut ikut bertambah.

Salinan baru membutuhkan tempat penyimpanan, akun pengguna, credential, backup, snapshot, log, dan prosedur pemeliharaan. Setiap komponen tersebut dapat menjadi jalur akses terhadap data.

Jika database production hanya dapat diakses oleh tim tertentu, salinan staging mungkin dapat diakses oleh developer, quality assurance, vendor aplikasi, konsultan, atau anggota tim lain yang terlibat dalam pengujian.

Jumlah orang yang dapat melihat data bertambah, meskipun tujuan awalnya hanya mempercepat perbaikan aplikasi.

Setiap salinan juga dapat menghasilkan turunan lain. Database staging mungkin dicadangkan secara otomatis, diekspor ke file SQL, disalin ke perangkat developer, atau digunakan untuk membuat environment tambahan.

Akibatnya, satu database production dapat berubah menjadi banyak salinan yang tidak lagi memiliki pemilik, masa retensi, dan kontrol akses yang jelas.

Staging Sering Memiliki Perlindungan yang Lebih Lemah

Lingkungan production umumnya menjadi fokus utama keamanan perusahaan karena secara langsung mendukung layanan dan operasional bisnis.

Staging tidak selalu memperoleh perhatian yang sama.

Patch pada server staging dapat dilakukan lebih lambat. Monitoring keamanannya mungkin terbatas. Password dapat digunakan bersama, sementara akses lama tidak segera dicabut ketika anggota tim berpindah peran.

Dalam beberapa kasus, subdomain staging dapat diakses melalui internet tanpa pembatasan jaringan. Aplikasi mungkin hanya dilindungi halaman login sederhana atau bahkan menggunakan credential default untuk memudahkan pengujian.

Konfigurasi lain yang sering meningkatkan risiko meliputi:

• akses database dari jaringan publik;
• firewall yang terlalu longgar;
• akun administrator yang digunakan bersama;
• Multi-Factor Authentication yang belum diterapkan;
• secret tersimpan dalam source code atau file konfigurasi;
• API staging tanpa pembatasan akses memadai;
• audit log yang tidak ditinjau;
• backup tanpa enkripsi;
• bucket penyimpanan dengan izin terlalu luas;
• software yang sudah tidak mendapat pembaruan.

Ketika data production masuk ke dalam kondisi tersebut, staging memiliki nilai data setara production tanpa memperoleh perlindungan yang setara.

Data Sensitif Tidak Hanya Berada pada Kolom Identitas

Proses pengamanan sering dimulai dengan menyamarkan nama, alamat email, nomor telepon, dan nomor identitas. Langkah tersebut penting, tetapi belum tentu mencakup seluruh data sensitif.

Informasi pribadi dapat muncul di banyak lokasi yang tidak langsung terlihat.

Kolom catatan layanan pelanggan dapat berisi alamat, kondisi kesehatan, nomor rekening, atau penjelasan masalah pribadi. Lampiran dokumen dapat memuat kartu identitas, kontrak, bukti pembayaran, dan tanda tangan.

Data sensitif juga dapat berada dalam:

• percakapan pengguna;
• payload API;
• audit log;
• error message;
• metadata dokumen;
• foto profil;
• alamat pengiriman;
• riwayat transaksi;
• token reset password;
• file ekspor;
• rekaman aktivitas;
• data keluarga;
• informasi pekerjaan;
• lokasi pengguna.

Masking berbasis daftar kolom dapat melewatkan informasi yang berada dalam teks bebas, lampiran, atau struktur data tidak terorganisasi.

Karena itu, perusahaan perlu melakukan klasifikasi data sebelum membuat salinan. Tanpa klasifikasi, organisasi tidak mengetahui bagian mana yang harus dihapus, dibatasi, atau ditransformasikan.

Masking Belum Tentu Membuat Data Menjadi Anonim

Data masking sering dianggap telah menyelesaikan seluruh persoalan privasi. Setelah nama dan nomor telepon diganti, dataset diperlakukan seolah-olah tidak lagi berhubungan dengan individu nyata.

Asumsi tersebut perlu ditinjau kembali.

Masking menyembunyikan atau mengganti nilai tertentu. Pseudonymization mengganti identitas dengan penanda lain yang masih dapat dikaitkan kembali melalui informasi tambahan. Tokenization menggunakan token sebagai pengganti nilai sensitif.

Anonimisasi memiliki tujuan yang lebih kuat, yaitu membuat individu tidak dapat diidentifikasi kembali secara wajar.

Perbedaan tersebut penting karena seseorang tidak selalu diidentifikasi melalui nama.

Kombinasi usia, lokasi, jabatan, waktu transaksi, jenis layanan, dan pola aktivitas dapat mempersempit identitas seseorang. Penelitian akademik mengenai re-identification telah menunjukkan bahwa dataset yang tampak anonim masih dapat dikaitkan kembali dengan individu apabila tersedia informasi pembanding yang cukup.

Penelitian lain mengenai synthetic data juga mengingatkan bahwa data buatan tidak otomatis bebas risiko privasi. Jika model pembuatnya terlalu dekat dengan dataset asal, pola atau catatan tertentu masih berpotensi terungkap.

Artinya, mengganti beberapa kolom belum cukup. Perusahaan perlu menilai kemungkinan identifikasi ulang berdasarkan keseluruhan dataset.

Masking yang Tidak Tepat Dapat Merusak Hasil Pengujian

Menghapus atau mengacak seluruh data juga bukan solusi sederhana.

Aplikasi bergantung pada hubungan antartabel, format, aturan validasi, serta pola bisnis tertentu. Jika proses masking merusak hubungan tersebut, kegagalan pengujian dapat terjadi karena kualitas data yang buruk, bukan karena masalah pada aplikasi.

Sebagai contoh, penggantian nomor identitas tetap harus mempertahankan format yang diterima sistem. Relasi antara pengguna, pesanan, pembayaran, dan pengiriman juga harus tetap konsisten.

Masking yang baik perlu menjaga beberapa karakteristik berikut:

• referential integrity;
• panjang dan format data;
• aturan validasi;
• hubungan akun dan transaksi;
• konsistensi nilai antarsistem;
• distribusi data yang dibutuhkan;
• kasus ekstrem untuk pengujian;
• keunikan nilai tertentu.

Tantangannya adalah mempertahankan kegunaan data tanpa mempertahankan identitas asli.

Oleh sebab itu, data masking perlu dirancang sebagai bagian dari test data management, bukan sebagai pekerjaan manual yang dilakukan setelah database disalin.

Data Nyata Dapat Menghasilkan Dampak Nyata

Risiko staging tidak hanya berkaitan dengan pihak yang membaca database. Data production juga dapat memicu proses yang berhubungan dengan pengguna sebenarnya.

Aplikasi staging mungkin masih terhubung ke layanan email, gateway SMS, push notification, payment gateway, webhook, atau sistem pihak ketiga.

Ketika pengujian dilakukan menggunakan data pelanggan nyata, sistem dapat mengirim pesan kepada alamat email dan nomor telepon yang sebenarnya. Pelanggan kemudian menerima notifikasi pengujian, tautan reset password, invoice, atau informasi transaksi yang tidak pernah mereka lakukan.

Dampaknya dapat berkembang menjadi kebingungan pelanggan, keluhan, gangguan reputasi, hingga insiden privasi.

Risiko serupa muncul ketika staging masih terhubung dengan:

• sistem ERP;
• layanan pengiriman;
• platform analitik;
• customer relationship management;
• sistem absensi;
• layanan pembayaran;
• penyimpanan dokumen;
• aplikasi mitra;
• API internal.

Karena itu, pengamanan staging tidak cukup hanya dengan melindungi databasenya. Seluruh integrasi keluar juga harus dipetakan dan dibatasi.

Endpoint pihak ketiga perlu diganti dengan layanan simulasi. Email dan SMS sebaiknya diarahkan ke akun pengujian, sedangkan transaksi finansial harus menggunakan sandbox yang disediakan oleh penyedia layanan.

Salinan Sementara Sering Berubah Menjadi Penyimpanan Permanen

Database staging umumnya dibuat untuk kebutuhan tertentu, seperti pengujian fitur, migrasi, atau investigasi bug.

Setelah pengujian selesai, salinan tersebut tidak selalu dihapus.

Tim mungkin mempertahankannya untuk kebutuhan berikutnya. Beberapa bulan kemudian, tidak ada lagi pihak yang mengetahui alasan database dibuat, siapa pemiliknya, atau apakah data di dalamnya masih digunakan.

Penghapusan database utama juga belum menyelesaikan seluruh persoalan. Salinan dapat tetap berada dalam:

• snapshot cloud;
• backup otomatis;
• object storage;
• file ekspor;
• perangkat developer;
• pipeline artifact;
• server vendor;
• virtual machine image;
• media penyimpanan lokal.

Jika kebijakan retensi hanya berlaku pada database utama, data sensitif dapat bertahan jauh lebih lama melalui salinan tidak langsung.

Setiap proses penyalinan perlu memiliki tujuan, pemilik, tanggal kedaluwarsa, dan mekanisme penghapusan. Backup dan snapshot juga harus dimasukkan dalam siklus hidup tersebut.

Lingkungan Non-Production Tetap Termasuk dalam Pemrosesan Data

Undang-Undang Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi mengatur pemrosesan dan kewajiban perlindungan data pribadi. Tanggung jawab tersebut tidak hanya berlaku ketika data berada di aplikasi production.

Penyalinan, penyimpanan, penggunaan, pemberian akses, pemindahan, serta penghapusan merupakan bagian dari rangkaian pengelolaan data yang perlu dikendalikan.

Label seperti development, testing, quality assurance, atau staging tidak mengubah sifat data pribadi yang terdapat di dalamnya.

Sebelum menyalin data production, organisasi perlu menjawab beberapa pertanyaan:

• Untuk tujuan apa data digunakan?
• Apakah seluruh database benar-benar diperlukan?
• Kolom mana yang relevan dengan pengujian?
• Siapa yang akan memperoleh akses?
• Apakah vendor eksternal ikut mengakses?
• Berapa lama data disimpan?
• Di lokasi mana data dan backup ditempatkan?
• Bagaimana data dihapus setelah pengujian?
• Bagaimana aktivitas akses dicatat?
• Apa yang dilakukan jika terjadi kebocoran?

Pertanyaan tersebut membantu organisasi memperlakukan staging sebagai bagian dari tata kelola data, bukan sekadar fasilitas teknis milik tim development.

Data Realistis Tidak Harus Menggunakan Identitas Asli

Tujuan pengujian seharusnya menentukan jenis data yang digunakan.

Jika tim hanya ingin menguji fungsi formulir, tidak ada alasan menggunakan identitas pelanggan sebenarnya. Jika kebutuhan pengujian berfokus pada performa, volume dan distribusi data mungkin lebih penting daripada isi data asli.

Beberapa pendekatan dapat digunakan sebagai alternatif.

Synthetic Data

Synthetic data dibuat untuk meniru karakteristik tertentu tanpa menyalin langsung identitas pengguna.

Pendekatan ini cocok untuk pengujian fungsi umum, otomatisasi, performa, dan berbagai skenario yang dapat didefinisikan sebelumnya.

Namun, kualitas synthetic data perlu dievaluasi. Data yang terlalu sederhana dapat gagal merepresentasikan kondisi sebenarnya, sedangkan proses pembentukan yang terlalu dekat dengan data sumber dapat membawa risiko privasi.

Data Subsetting

Data subsetting hanya mengambil sebagian catatan dan kolom yang diperlukan.

Jika pengujian hanya berkaitan dengan transaksi tertentu, perusahaan tidak perlu menyalin seluruh riwayat pelanggan. Pengurangan volume juga membantu memperkecil dampak jika staging mengalami kebocoran.

Masked Production Data

Data production masih dapat digunakan setelah elemen sensitif ditransformasikan. Metode ini membantu mempertahankan struktur, distribusi, dan hubungan yang dibutuhkan dalam pengujian.

Proses masking harus dilakukan secara konsisten dan mencakup data terstruktur maupun tidak terstruktur.

Tokenization

Nilai sensitif diganti dengan token yang tidak memiliki arti di luar sistem pengelola token. Pendekatan ini dapat membantu mempertahankan hubungan tertentu tanpa memberikan nilai asli kepada pengguna staging.

Data Virtualization

Data virtualization dapat memberikan representasi atau akses terkontrol tanpa membuat salinan penuh untuk setiap environment. Pendekatan ini tetap membutuhkan kontrol akses, pemantauan, dan pembatasan tujuan yang jelas.

Prinsip utamanya adalah lingkungan pengujian membutuhkan data yang representatif, bukan seluruh database production.

Transformasi Sebaiknya Dilakukan Sebelum Data Dipindahkan

Sebagian perusahaan menyalin database production terlebih dahulu, kemudian menjalankan masking di staging.

Cara tersebut masih menciptakan periode ketika data mentah berada di lingkungan yang lebih lemah. Jika proses masking gagal, berhenti di tengah jalan, atau hanya mencakup sebagian tabel, data asli tetap tersimpan.

Alur yang lebih aman dapat dilakukan melalui langkah berikut:

1. Mengklasifikasikan data pada sumbernya.
2. Menentukan skenario pengujian.
3. Memilih tabel dan kolom yang diperlukan.
4. Menghapus data yang tidak relevan.
5. Melakukan masking atau tokenization.
6. Memeriksa kemungkinan identifikasi ulang.
7. Memvalidasi hubungan antardata.
8. Memindahkan hasil transformasi ke staging.
9. Menetapkan pemilik dan masa retensi.
10. Memverifikasi penghapusan setelah pengujian selesai.

Dengan pendekatan tersebut, data mentah tidak perlu melewati batas environment apabila tidak benar-benar diperlukan.

Jika Data Asli Harus Digunakan, Staging Perlu Diperlakukan sebagai Environment Sensitif

Dalam kondisi tertentu, organisasi mungkin tidak dapat sepenuhnya mengganti data production. Investigasi insiden, reproduksi bug kompleks, atau pengujian migrasi dapat membutuhkan data yang sangat mendekati kondisi sebenarnya.

Jika data asli tetap digunakan, perlindungannya tidak boleh lebih rendah hanya karena environment tersebut bukan production.

Kontrol yang perlu diterapkan meliputi:

• persetujuan dan tujuan penggunaan yang terdokumentasi;
• pembatasan dataset;
• least privilege;
• akun individual;
• Multi-Factor Authentication;
• network segmentation;
• pembatasan akses publik;
• enkripsi saat disimpan dan dikirim;
• encryption key yang terpisah;
• audit log;
• monitoring akses;
• pembatasan ekspor;
• Data Loss Prevention;
• pengelolaan vendor;
• masa retensi;
• penghapusan otomatis;
• vulnerability assessment;
• penetration testing.

Staging yang menyimpan data sensitif harus dimasukkan ke dalam inventaris aset dan pemantauan keamanan perusahaan.

Risiko Perlu Diukur Berdasarkan Jumlah Salinan

Organisasi sering mengetahui lokasi database production, tetapi tidak mengetahui berapa banyak salinannya.

Tata kelola data staging perlu memiliki ukuran yang dapat dipantau, antara lain:

• jumlah salinan database production;
• lokasi setiap salinan;
• usia data;
• pemilik environment;
• tujuan penggunaan;
• jumlah pengguna yang memiliki akses;
• jumlah vendor yang terlibat;
• persentase kolom yang telah di masking;
• jumlah snapshot dan backup;
• environment yang dapat diakses publik;
• jumlah integrasi keluar yang masih aktif;
• waktu yang diperlukan untuk menghapus data;
• jumlah ekspor yang tidak terkelola.

Jika perusahaan tidak dapat menjawab berapa banyak salinan data yang dimiliki, perusahaan juga akan kesulitan memastikan seluruh salinan telah terlindungi.

Penetration Testing Perlu Mencakup Staging

Pengujian keamanan sering difokuskan pada aplikasi production karena sistem tersebut digunakan langsung oleh pelanggan.

Pendekatan tersebut dapat melewatkan jalur serangan dari environment non-production.

Staging biasanya memiliki struktur aplikasi yang hampir sama dengan production. Di dalamnya dapat ditemukan dokumentasi, konfigurasi integrasi, endpoint API, source map, credential, dan data yang membantu penyerang memahami sistem utama.

Analisis ini sering kami temukan saat melakukan penetration testing pada perusahaan di Indonesia.

Subdomain staging dapat terbuka ke internet tanpa pembatasan. Aplikasi juga dapat menjalankan versi kode yang belum diperbarui atau memiliki fungsi debugging yang masih aktif.

Jika staging terhubung dengan jaringan internal, environment tersebut dapat digunakan sebagai titik awal untuk mengakses sistem lain.

Penetration testing terhadap staging dapat membantu mengidentifikasi:

• authentication yang lemah;
• access control yang tidak sesuai;
• database yang terekspos;
• API tanpa otorisasi;
• file backup yang dapat diunduh;
• secret dalam konfigurasi;
• directory listing;
• debug mode;
• akses ke sistem internal;
• integrasi dengan layanan production;
• data sensitif dalam respons aplikasi.

Pengujian harus dilakukan dengan ruang lingkup dan koordinasi yang jelas agar tidak mengganggu proses pengembangan.

Pengujian Cepat Tidak Seharusnya Dibayar dengan Risiko Privasi

Menyalin data production memang dapat mempercepat persiapan staging. Tim tidak perlu membuat data secara manual dan dapat langsung menguji aplikasi dalam kondisi yang lebih realistis.

Namun, waktu yang dihemat dapat berubah menjadi utang keamanan apabila salinan data tidak diklasifikasikan, dibatasi, dimasking, dipantau, dan dihapus.

Perusahaan tidak perlu memilih antara pengujian berkualitas dan perlindungan data. Keduanya dapat dicapai melalui test data management yang terencana.

Pertanyaan yang perlu diajukan bukan hanya, “Apakah data ini membuat pengujian lebih realistis?”

Perusahaan juga perlu mempertanyakan, “Apakah seluruh identitas dan informasi sensitif di dalamnya benar-benar diperlukan untuk membuktikan fungsi aplikasi?”

Semakin sedikit data sensitif yang masuk ke staging, semakin kecil pula dampak yang harus ditanggung ketika environment tersebut mengalami kebocoran.

Evaluasi Keamanan Aplikasi Bersama Fourtrezz

Fourtrezz membantu perusahaan mengidentifikasi kerentanan melalui layanan Vulnerability Assessment dan Penetration Testing.

Pengujian dapat dilakukan terhadap aplikasi web, aplikasi desktop, Android, iOS, API, jaringan, dan server. Fourtrezz menyediakan metode penetration testing blackbox dan greybox, laporan terperinci, rekomendasi perbaikan, pengujian ulang, serta konsultasi untuk membantu perusahaan memahami risiko keamanan secara lebih menyeluruh.

Bagi perusahaan yang memiliki environment development, staging, dan production, pengujian keamanan dapat membantu menemukan paparan data, kelemahan konfigurasi, access control yang tidak tepat, serta jalur serangan yang belum teridentifikasi.

Hubungi Fourtrezz:

Website: www.fourtrezz.co.id
Telepon/WhatsApp: +62 857-7771-7243
Email: [email protected]