Keamanan data nasabah BPR perlu didukung pengaturan hak akses yang membatasi siapa dapat melihat, mengubah, menyetujui, dan mengekspor informasi. Pembatasan tersebut harus mengikuti kewenangan kerja serta berlaku pada aplikasi, dokumen, laporan, dan jalur integrasi yang terkait.
Sebagai ilustrasi, seorang petugas hanya menangani pengajuan di cabangnya, tetapi dapat membuka dokumen cabang lain melalui tautan yang diterima. Tombol menu mungkin sudah dibatasi, sementara pemeriksaan pada dokumen belum berjalan. Kondisi ini menunjukkan bahwa hak akses perlu diuji sampai ke objek data, bukan hanya dari tampilan layar.
Artikel ini membahas penerapan kontrol pada aplikasi internal. Pengaturan akses merupakan bagian dari pelindungan data dan tata kelola bank; penerapannya perlu mengikuti kebijakan serta penilaian hukum yang relevan.
Hubungkan Pengaturan Akses Dengan Kebutuhan Bank
Pasal 15 pada POJK 34 Tahun 2025 mengatur pengamanan informasi dan pengendalian otorisasi. Pasal 35–36 membahas pengelolaan data serta pelaksanaan prinsip pelindungan data pribadi sesuai peraturan perundang-undangan.
Ketentuan tersebut perlu diterjemahkan ke proses nyata. Siapa yang membutuhkan data lengkap untuk pemeriksaan? Peran mana yang cukup melihat ringkasan? Siapa yang boleh melakukan koreksi? Jawaban tidak boleh hanya mengikuti kemampuan bawaan aplikasi.
Untuk gambaran kewajiban terkait, gunakan panduan POJK 34 Tahun 2025 untuk BPR. Rincian berikut merupakan rekomendasi implementasi yang perlu ditetapkan bank, bukan daftar fitur yang seluruhnya disebut secara harfiah dalam pasal tersebut.
Matriks Akses Untuk Keamanan Data Nasabah BPR
Matriks akses perlu menghubungkan peran dengan tindakan dan cakupan data. Jabatan saja dapat terlalu umum. Tambahkan kondisi yang relevan, seperti cabang, penugasan pengajuan, status proses, atau masa berlaku kewenangan.
Contoh berikut hanya menggambarkan cara menyusun kebutuhan. Bank perlu menetapkan sendiri kewenangan final dan pengecualiannya.
| Peran Ilustratif | Kebutuhan Akses | Pembatasan Yang Perlu Dibahas |
|---|---|---|
| Petugas pengajuan | Mengisi dan memperbarui pengajuan yang ditugaskan | Batas revisi setelah pemeriksaan |
| Pemeriksa | Membaca serta memberi hasil pemeriksaan | Larangan mengubah keputusan di luar kewenangan |
| Pemberi persetujuan | Mengambil keputusan pada cakupan yang ditetapkan | Batas delegasi dan konflik peran |
| Pengguna laporan | Membaca ringkasan yang relevan | Pembatasan rincian identitas dan ekspor |
| Administrator teknis | Menjalankan pengelolaan aplikasi | Akses data bisnis tidak otomatis tanpa batas |
Sertakan pihak yang menyetujui matriks. Pengembang membutuhkan keputusan yang jelas untuk menerapkannya dan menulis skenario uji.
Periksa Kewenangan Pada Setiap Permintaan
Aplikasi perlu memeriksa apakah pengguna berwenang melakukan tindakan pada objek yang diminta. Menyembunyikan tombol berguna untuk pengalaman pengguna, tetapi pembatasan harus tetap berlaku ketika pengguna mengakses tautan atau mengirim permintaan melalui jalur lain.
OWASP Authorization Cheat Sheet merekomendasikan pembatasan hak sesuai kebutuhan, penolakan secara default, dan pemeriksaan izin pada setiap permintaan. Prinsip teknis ini membantu merancang aplikasi; bukan bukti bahwa bank otomatis memenuhi seluruh ketentuan regulasi.
Uji dengan akun yang memiliki kewenangan berbeda. Jika pengguna cabang A mencoba membuka objek cabang B, sistem harus mengikuti matriks yang disepakati. Hasilnya perlu diperiksa pada data dan dokumen, termasuk respons yang dikirim sebelum ditampilkan pada layar.
Bedakan Melihat Data Dengan Mengekspor Data
Pengguna yang berhak membaca informasi tertentu belum tentu perlu mengunduh seluruh kumpulan data. Ekspor membuat salinan yang dapat berpindah ke perangkat, folder bersama, atau saluran komunikasi lain. Karena itu, evaluasi ekspor sebagai tindakan tersendiri.
Tentukan kolom, cakupan, tujuan kerja, dan pihak yang menyetujui bila diperlukan. Laporan rutin dapat memakai informasi yang disamarkan atau diringkas sesuai kebutuhan. Hindari menyediakan tombol “unduh semua” hanya karena fitur tersebut mudah dibuat.
Catat aktivitas ekspor yang penting beserta konteksnya. Periksa pula berkas yang dihasilkan: apakah memuat kolom tersembunyi atau data di luar pilihan pengguna? Pengujian antarmuka saja dapat melewatkan informasi berlebih pada hasil unduhan.
Terapkan Masking Sesuai Kebutuhan Proses
Masking membantu membatasi tampilan sebagian informasi. Misalnya, pengguna laporan mungkin hanya membutuhkan pengenal internal atau sebagian nomor identitas. Namun, penyamaran pada layar tidak cukup jika nilai lengkap tetap tersedia dalam respons aplikasi tanpa kebutuhan yang sah.
Bedakan penyamaran tampilan, pembatasan data yang dikirim, dan perlindungan penyimpanan. Masing-masing menjawab risiko berbeda. Tentukan kapan data lengkap dapat dibuka, oleh siapa, serta apakah tindakan tersebut perlu dicatat.
Enkripsi juga membutuhkan pengelolaan kunci dan akses. Klaim “database terenkripsi” belum menjelaskan siapa yang dapat membaca data melalui aplikasi. Evaluasi perlindungan sebagai rangkaian kontrol, bukan memilih satu fitur lalu menganggap seluruh jalur telah aman.
Kelola Akses Saat Pegawai Masuk, Pindah, Dan Keluar
Pemberian akses perlu mengikuti kebutuhan yang disetujui. Ketika pegawai berpindah jabatan atau cabang, tinjau akses lama sebelum menambah kewenangan baru. Akumulasi hak akses dapat terjadi jika setiap perpindahan hanya menghasilkan penambahan peran.
Saat pegawai keluar, bank perlu memiliki proses penutupan akses yang mencakup aplikasi terkait. Periksa akun integrasi atau akun bersama yang mungkin diketahuinya sesuai kebijakan. Akses terhadap dokumen dan laporan di luar aplikasi utama juga perlu ditinjau.
Lakukan pencocokan berkala antara pengguna aktif dan pihak yang masih berwenang. Frekuensi serta cakupannya ditetapkan berdasarkan risiko dan ketentuan bank. Simpan keputusan peninjauan agar pengecualian tidak terus bertahan tanpa penanggung jawab.
Batasi Akses Vendor Dan Dukungan Teknis
Vendor mungkin membutuhkan akses untuk menangani gangguan, tetapi cakupannya harus jelas. Tetapkan lingkungan, tujuan, masa berlaku, pemberi persetujuan, dan pencatatan aktivitas. Hindari akses produksi permanen yang tidak diketahui pemilik proses.
Gunakan data sintetis atau data yang telah disamarkan ketika pekerjaan tidak memerlukan identitas nyata. Jika penggunaan data sebenarnya memang diperlukan, tentukan kewenangan, cara akses, perlindungan, serta tanggung jawabnya melalui proses resmi bank.
Pasal 27 memuat ketentuan terkait kerahasiaan dan pengawasan penyedia jasa TI. Pertanyaan kontraknya dapat dibaca pada panduan memilih vendor TI BPR. Pembahasan dengan vendor harus mencakup akses dukungan, bukan hanya akses pengguna aplikasi.
Hubungkan Persetujuan Dan Pelindungan Data Dengan Prosesnya
Pasal 36 menyebut pemrosesan data pribadi dengan memperhatikan persetujuan nasabah atau calon nasabah sesuai ketentuan perundang-undangan. Implementasi perlu melibatkan fungsi berwenang untuk menilai tujuan, dasar pemrosesan, pemberitahuan, serta dokumentasi yang dibutuhkan.
Checkbox pada aplikasi dapat membantu mencatat tindakan pengguna, tetapi tidak sendirian membuktikan seluruh persyaratan terpenuhi. Jika dokumentasi persetujuan digunakan, tetapkan versi informasi, waktu, konteks, dan hubungan dengan data atau proses yang relevan.
Tentukan pula penanganan permintaan terkait data melalui prosedur bank. Jangan membuat keputusan hukum otomatis dari asumsi pengembang, misalnya menghapus semua catatan begitu permintaan diterima tanpa memeriksa kewajiban penyimpanan yang berlaku.
Catat Perubahan Akses Dan Aktivitas Penting
Riwayat pemberian serta pencabutan kewenangan membantu menjelaskan siapa memiliki akses pada suatu waktu. Catat aktor, tindakan, objek, waktu, hasil, dan alasan yang diperlukan. Untuk tindakan istimewa, hubungkan catatan dengan permintaan atau persetujuan terkait.
Log sendiri dapat berisi informasi pribadi sehingga membutuhkan pembatasan. Jangan memasukkan kata sandi atau token akses ke dalam catatan. Tetapkan pihak yang boleh memeriksa serta mengekspor bukti sesuai kebijakan.
Kebutuhan ini berkaitan dengan audit trail sistem BPR. Kemampuan menelusuri aktivitas tidak menggantikan pencegahan akses yang tidak sah; keduanya perlu dinilai sebagai kontrol yang saling mendukung.
Uji Akses Dengan Skenario Yang Jelas
Gunakan data sintetis dan lingkungan yang disetujui. Uji pengguna dengan peran berbeda, objek di luar cabang, dokumen yang tidak ditugaskan, ekspor, perubahan status, serta akun yang kewenangannya sudah dicabut. Tetapkan hasil yang diharapkan dari matriks akses.
Periksa jalur aplikasi yang berbeda, termasuk dokumen dan layanan integrasi. Jika salah satu jalur belum diuji, catat sebagai cakupan terbuka. Pengujian terhadap satu menu tidak membuktikan seluruh aplikasi telah terlindungi.
Skenario tersebut perlu masuk kriteria penerimaan dalam pengembangan aplikasi BPR. Untuk aplikasi lama yang belum memiliki matriks jelas, assessment TI BPR dapat menjadi tahap pemetaan sebelum perubahan dimulai.
Membenahi Pengaturan Akses Bersama Layana.id
Siapkan alur kerja, daftar peran, cakupan cabang, serta tindakan yang menimbulkan risiko. Mulailah dari keputusan yang perlu diterapkan aplikasi, lalu tentukan perubahan konfigurasi atau pengembangan yang diperlukan. Pemilik kewenangan bank perlu menyetujui kebutuhan tersebut.
Layana.id dapat diajak membahas implementasi melalui layanan custom development. Ruang lingkup sebaiknya memuat matriks akses, jalur yang diperiksa, skenario uji, dokumentasi, serta batas keterlibatan vendor lain.
Diskusikan pengaturan keamanan data nasabah BPR bersama Layana.id menggunakan contoh proses tanpa membuka data sensitif. Hasil yang dicari adalah pembatasan akses yang dapat dijalankan dan dibuktikan pada sistem, dengan kebijakan serta pengawasan tetap ditetapkan oleh bank.
Aplikasi Finance Karya Layana
Aplikasi nasabah, alur pengajuan kredit, dan web admin untuk KB Bukopin Finance, BPR CMA, serta BPR MSA.
KB Bukopin Finance
Dari Simulasi Ke Pengajuan Pembiayaan
Aplikasi Android dan web admin untuk informasi produk, simulasi pembiayaan, serta pengumpulan pengajuan calon nasabah. Lingkup proyek mencakup perancangan integrasi e-KYC Privy.ID, skor kredit pihak ketiga CLIK, dan pengembangan skoring berbasis data internal.
BPR CMA
Alur Kredit Dalam Genggaman Tim
Aplikasi mobile dan web admin untuk pengajuan serta survei kredit. Cakupannya membantu marketing dan komite kredit mengelola pengecekan data, exposure, serta analisis jaminan. Pengajuan dan status pekerjaan menjadi bagian dari alur yang dapat ditelusuri tim.
MSA On Hand
Layanan Nasabah Dan Komunitas UMKM
Aplikasi BPR Madani Sejahtera Abadi untuk pengajuan kredit, pembukaan rekening dan deposito, pembayaran, serta forum komunitas. Lingkup proyek Layana juga mencakup web admin, pengelolaan pengajuan oleh marketing dan notaris, serta laporan operasional.
MSA on Hand tersedia di Google Play dengan PT. Layana Computindo Sentratama tercantum sebagai developer.
Cakupan pengguna pada proyek tersebut menjadi konteks pembahasan hak akses, bukan bukti sertifikasi keamanan atau kepatuhan. Pada sistem bank yang akan dibangun, matriks akses, pembatasan dokumen, pengujian otorisasi, dan penanganan data perlu ditetapkan sesuai kebutuhannya.
Bicarakan Aplikasi BPR Anda
Ceritakan proses yang masih manual, sistem yang digunakan, dan fitur yang ingin dibuat. Tim Layana dapat membantu membahas kebutuhan, batas integrasi, dan tahapan pengembangan.
Referensi
- POJK Nomor 34 Tahun 2025, khususnya Pasal 15, 27, 35–36, dan 40.
- OWASP Authorization Cheat Sheet, rekomendasi teknis otorisasi aplikasi.