Menu

Data uji PCI DSS: mengapa lingkungan uji tetap diatur

Data uji PCI DSS tidak boleh berasal dari kartu asli. Kenali aturan penyimpanan, pemaskeran, dan tokenisasi yang membuat pengujian tetap aman dan legal.

Diterbitkan

  • data uji
  • kepatuhan
  • keamanan

Ada keyakinan lama di banyak tim bahwa data uji PCI DSS berada di zona bebas aturan. Menurut keyakinan itu, lingkungan pengembangan adalah tempat santai: salinan basis data produksi boleh dipakai, nomor kartu asli boleh disimpan demi kenyamanan, dan tidak ada auditor yang akan mengetuk pintu. Anggapan itu keliru, dan biaya memperbaikinya jauh lebih besar daripada biaya menyiapkan data uji yang benar sejak awal.

Apa yang dimaksud dengan data uji PCI DSS

PCI DSS adalah standar keamanan data industri kartu pembayaran yang berlaku bagi siapa pun yang menyimpan, memproses, atau meneruskan data pemegang kartu. Versi utama yang berlaku saat ini berada di seri 4, dan isinya terus diperbarui seiring perubahan teknologi pembayaran.

Istilah data uji PCI DSS merujuk pada dua hal sekaligus: kumpulan data yang Anda pakai untuk menguji sistem, dan seperangkat aturan tentang data seperti apa yang boleh berada di lingkungan uji. Kesimpulan praktisnya sederhana, yaitu lingkungan pengujian tidak boleh berisi data pemegang kartu yang asli.

Apakah lingkungan pengujian termasuk ruang lingkup?

Ya. Justru lingkungan pengujian sering menjadi titik terlemah, karena di sanalah salinan data berpindah tanpa pengawasan ketat. Data dari produksi disalin untuk memudahkan penelusuran bug, diletakkan di server yang tidak diaudit, lalu terlupakan selama berbulan-bulan.

Cakupan audit ikut melebar setiap kali data asli masuk ke sistem baru. Setiap salinan menambah satu tempat lagi yang harus dilindungi, dipantau, dan dibuktikan keamanannya. Menghindari data asli sejak awal jauh lebih murah daripada menambah kontrol keamanan di banyak lingkungan sekaligus.

Data apa saja yang tidak boleh disimpan

Aturan yang paling sering dibahas menyangkut data autentikasi yang sensitif. Kelompok ini tidak boleh disimpan setelah otorisasi selesai, sekalipun dalam bentuk terenkripsi. Isinya mencakup kode keamanan kartu dan data yang terbaca dari jalur magnetik, karena keduanya bisa dipakai untuk membuat transaksi baru.

Sementara itu, data rekening yang memang perlu disimpan untuk keperluan bisnis boleh dipertahankan, tetapi wajib dilindungi dan wajib ditampilkan dalam bentuk yang disamarkan. Bentuk penyamaran yang lazim adalah menampilkan sebagian digit di depan dan sebagian di belakang, sedangkan bagian tengahnya diganti penanda. Penjelasan mengapa kode keamanan mendapat perlakuan khusus bisa dibaca di halaman penjelasan CVV.

Kejelasan soal berapa lama data boleh disimpan sama pentingnya. Tetapkan batas waktu yang masuk akal untuk setiap jenis data, lalu hapus data yang sudah tidak diperlukan lagi. Salinan cadangan tidak terkecuali: berkas cadangan yang dibuat bertahun-tahun lalu sering masih memuat data yang seharusnya sudah lama hilang dari sistem utama, dan justru salinan seperti itu yang paling jarang diperiksa.

Mengapa data sintetis lebih baik daripada data asli?

Data sintetis adalah data yang dibuat sendiri dan tidak merujuk pada orang atau rekening mana pun. Untuk pengujian perangkat lunak, ia punya beberapa keunggulan yang sulit ditandingi data asli:

  • Cakupan audit tidak melebar, karena tidak ada data pemegang kartu yang berpindah ke lingkungan baru.
  • Boleh disimpan di repositori, sehingga tim dapat memakai kumpulan uji yang sama dari mana saja.
  • Bisa dirancang untuk kasus langka, misalnya panjang tidak lazim atau jaringan yang jarang dipakai.
  • Tidak kedaluwarsa, dan tidak menimbulkan masalah ketika ada karyawan yang berhenti.
  • Aman dibagikan, bahkan kepada vendor luar yang sedang membantu penelusuran bug.

Kalau data uji Anda berasal dari produksi, semua keunggulan itu hilang sekaligus.

Tokenisasi dan penyamaran: dua cara melindungi data

Pendekatan pertama adalah penyamaran untuk keperluan tampilan. Nomor aslinya tetap tersimpan, tetapi apa yang muncul di layar hanya sebagian digit. Ini menjawab kebutuhan operasional sehari-hari tanpa membuka akses ke nomor lengkap.

Pendekatan kedua adalah tokenisasi, yaitu mengganti nomor kartu dengan rujukan yang diterbitkan penyedia pembayaran. Sistem Anda menyimpan rujukan itu, sementara nomor aslinya berada di pihak penyedia. Bila basis data Anda bocor, yang hilang hanya rujukan yang tidak bisa dipakai di luar konteksnya.

Keduanya bisa dipakai bersamaan, dan pilihan di antaranya biasanya ditentukan oleh seberapa dalam sistem Anda perlu mengenali kartu pelanggan. Untuk pengujian, keduanya juga berarti satu hal: masukan yang dipakai sebaiknya bukan data nyata.

Membuat data uji yang aman di generator kartu virtual

Generator kartu virtual di situs ini menghasilkan nomor beserta masa berlaku dan kode keamanan contoh yang sah secara struktur tetapi tidak pernah diterbitkan oleh bank mana pun. Karena tidak terhubung ke rekening siapa pun, data seperti ini aman disimpan di repositori pengujian dan aman dibagikan kepada anggota tim.

Yang perlu Anda pastikan adalah konsistensinya: pakai kumpulan data yang sama setiap kali pengujian berjalan, dan catat dari mana angka itu berasal. Data yang dibuat sekali lalu disimpan biasanya lebih berguna daripada data yang dibuat ulang setiap kali, karena hasil pengujian menjadi bisa dibandingkan antar waktu. Pola ini dibahas lebih jauh di halaman nomor kartu untuk pengujian.

Catatan untuk pengembang: memisahkan lingkungan uji dan produksi

Pemisahan yang baik bersifat teknis, bukan sekadar kesepakatan lisan. Tiga hal berikut paling sering menjadi sumber masalah:

  1. Kredensial. Kunci uji dan kunci langsung harus berada di berkas yang berbeda, dengan nama yang eksplisit, dan tidak pernah tercampur.
  2. Data. Jangan pernah menyalin basis data produksi ke lingkungan uji. Kalau penelusuran bug benar-benar memerlukan bentuk data yang mirip, buat versi sintetis dengan struktur yang sama.
  3. Catatan sistem. Berkas catatan dari lingkungan uji sering diabaikan, padahal berkas itu bisa memuat isi formulir. Perlakukan berkas catatan sebagai data sensitif pula.

Tambahkan pemeriksaan otomatis yang memastikan lingkungan uji tidak memuat nilai yang menyerupai data kartu asli. Pemeriksaan semacam itu murah dibuat dan akan langsung memberi tahu Anda ketika ada yang menyalin data dari tempat yang salah. Rangkaian pemeriksaan sebelum peluncuran secara umum bisa dilihat di checklist pengujian formulir pembayaran.

Langkah berikutnya

Periksa hari ini apakah ada data kartu asli di lingkungan pengujian Anda; kalau ada, ganti dengan data sintetis sebelum hal lain dikerjakan. Setelah itu tetapkan satu kumpulan data uji tetap yang bisa dipakai siapa saja di tim, dan buat isinya dari halaman generator agar tidak ada yang tergoda menyalin dari produksi.

Lanjut membaca

Artikel tentang Generator nomor kartu kredit palsu