MFA Berbasis Risiko Perbankan POJK 11/2022: Panduan Bank

Bagi bank umum di Indonesia, pertanyaan tentang MFA berbasis risiko perbankan POJK 11/2022 hampir selalu muncul dalam bentuk yang sama: apakah regulator mewajibkan teknologi autentikasi tertentu, dan apakah metode yang sudah dipakai hari ini masih memadai. Jawaban singkatnya, POJK Nomor 11/POJK.03/2022 tentang Penyelenggaraan Teknologi Informasi oleh Bank Umum tidak menyusun daftar belanja teknologi. Regulasi ini menetapkan kewajiban proses: bank harus mengidentifikasi risiko, menetapkan kontrol yang proporsional, lalu membuktikan kontrol itu bekerja. Artikel ini membedah cara membaca kerangka tersebut dan di mana security key hardware menempati posisi yang masuk akal. Untuk gambaran menyeluruh soal MFA yang tahan phishing di luar konteks POJK, lihat panduan lengkap MFA tahan phishing untuk enterprise dan perbankan.

Apa yang Diatur POJK 11/2022 dan Mengapa Pendekatannya Berbasis Risiko

POJK 11/2022 menggantikan POJK 38/POJK.03/2016 tentang Penerapan Manajemen Risiko dalam Penggunaan Teknologi Informasi oleh Bank Umum. Cakupannya lebih luas dari pendahulunya: tata kelola TI, manajemen risiko TI, pengamanan informasi, pengelolaan pusat data dan pusat pemulihan bencana, penyelenggaraan layanan perbankan elektronik, pemanfaatan pihak ketiga termasuk komputasi awan, serta kewajiban pelaporan kepada Otoritas Jasa Keuangan. Ketentuan teknis pelaksanaannya dituangkan dalam surat edaran turunan (SEOJK 29/SEOJK.03/2022), yang memberi rincian lebih operasional atas prinsip-prinsip dalam POJK.

Karakter utama regulasi ini adalah principle-based dan risk-based. Bank diminta menyelenggarakan pengamanan informasi yang mencakup, antara lain, pengendalian akses, autentikasi pengguna, kerahasiaan dan integritas data, serta pemantauan insiden. Namun tingkat kekuatan kontrol tidak diseragamkan untuk semua kanal dan semua pengguna. Bank berskala besar dengan kanal digital masif dan bank dengan profil risiko lebih sederhana tidak diharapkan menerapkan kontrol identik. Yang diharapkan sama adalah kualitas argumennya: ada asesmen risiko, ada keputusan kontrol yang tercatat, ada pengujian, dan ada evaluasi berkala.

Konsekuensi praktis bagi desain autentikasi

Karena kerangkanya berbasis risiko, kalimat “kami sudah memakai MFA” bukan jawaban yang cukup di hadapan auditor internal maupun pemeriksa. Pertanyaan lanjutannya selalu: MFA jenis apa, untuk pengguna mana, melindungi aset apa, dan dari skenario ancaman apa. MFA yang efektif menahan pencurian kata sandi belum tentu efektif menahan phishing real-time dengan proxy, SIM swap, atau MFA fatigue. Perbedaan itulah yang perlu Anda tuangkan secara eksplisit dalam dokumen asesmen risiko.

Menerjemahkan MFA Berbasis Risiko Perbankan POJK 11/2022 ke Desain Kontrol

Pendekatan yang paling mudah dipertahankan saat pemeriksaan adalah memetakan populasi pengguna dan jenis transaksi ke tingkat risiko, lalu menetapkan kekuatan autentikasi minimum per tingkat. Tabel berikut adalah contoh kerangka yang dapat Anda sesuaikan dengan selera risiko bank Anda; angka dan batasnya adalah keputusan internal, bukan kutipan regulasi.

Inti dari MFA berbasis risiko perbankan POJK 11/2022 bukan menyamaratakan kontrol terkuat ke seluruh populasi, melainkan memastikan tidak ada aset bernilai tinggi yang dilindungi oleh faktor yang lemah terhadap ancaman dominannya. Model risiko adaptif juga membantu pengalaman nasabah: gesekan ditambahkan hanya ketika sinyal risiko naik, misalnya perangkat baru, alamat IP asing, atau perubahan data penerima.

Peran Security Key dalam Bauran Autentikasi Bank

Security key hardware seperti YubiKey berperan sebagai autentikator kriptografis yang terikat pada domain. Kunci privat tidak pernah meninggalkan perangkat, dan protokol WebAuthn hanya mau menandatangani challenge untuk origin yang sesuai saat pendaftaran. Karakteristik itulah yang membuatnya menahan phishing secara struktural, bukan sekadar mempersulit penyerang. Penjelasan teknis mekanismenya dapat Anda baca pada ulasan cara kerja FIDO2 dan WebAuthn, sedangkan perbandingan ketahanannya terhadap kode sekali pakai dibahas pada artikel security key versus OTP SMS, dan perbandingan yang berfokus pada konteks perbankan tersedia pada security key vs OTP SMS untuk perbankan.

Dalam konteks perbankan, penempatan yang paling bernilai umumnya bukan di sisi nasabah ritel, melainkan pada populasi internal berisiko tinggi:

• Akses privileged dan administratif ke core banking, switching, basis data nasabah, serta konsol penyedia cloud.
• Akses jarak jauh pegawai melalui VPN atau ZTNA, termasuk vendor dan pihak ketiga yang mendapatkan akses terbatas.
• Rekayasa dan operasi: repositori kode, pipeline CI/CD, penandatanganan artefak, dan akses ke lingkungan produksi.
• Peran finansial sensitif seperti persetujuan pembayaran bernilai besar, treasury, dan pemeliharaan data master vendor yang kerap menjadi sasaran business email compromise.
• Akun break-glass pada penyedia identitas, yang justru paling sering luput dari kebijakan MFA organisasi.

Pertimbangan pengadaan dan sertifikasi

Untuk bank yang menuntut jejak sertifikasi pada modul kriptografi, tersedia varian yang divalidasi FIPS 140 (mis. seri YubiKey 5 FIPS). Perlu ditegaskan bahwa OJK tidak mewajibkan sertifikasi FIPS untuk autentikator; validasi tersebut berguna sebagai bukti pendukung dalam asesmen dan dokumen pengadaan, terutama ketika bank menjadi bagian dari grup dengan standar keamanan lintas entitas. Pemilihan bentuk faktor, antarmuka, dan model distribusi dibahas lebih rinci pada panduan memilih YubiKey untuk perusahaan.

Roadmap Implementasi Bertahap

Penerapan serentak untuk seluruh pengguna jarang berhasil di institusi perbankan. Urutan berikut biasanya lebih realistis. Fase 1: inventarisasi identitas dan aset, tentukan mana yang masuk kategori kritikal, dan catat metode autentikasi yang berlaku saat ini beserta kelemahannya. Fase 2: terapkan security key untuk administrator, akun break-glass, dan akses jarak jauh istimewa, dengan minimal dua kunci per pengguna agar ada cadangan. Fase 3: perluas ke populasi pegawai berisiko tinggi, integrasikan dengan penyedia identitas dan PAM, lalu tutup jalur pemulihan yang lemah, karena proses reset lewat helpdesk sering menjadi titik terlemah. Fase 4: kurangi ketergantungan pada kata sandi bagi populasi yang sudah siap, sebagaimana diuraikan pada pembahasan passwordless login untuk enterprise. Sepanjang keempat fase, dokumentasikan asesmen risiko, hasil pengujian keamanan, dan evaluasi berkala, karena artefak inilah yang diminta saat pemeriksaan.

Batas Klaim: Apa yang Tidak Dinyatakan Regulasi

Ada tiga kesalahpahaman yang sebaiknya dihindari dalam dokumen internal. Pertama, POJK 11/2022 tidak menyatakan FIDO2 atau security key sebagai kewajiban; keduanya adalah pilihan kontrol yang sah dan kuat, bukan mandat. Kedua, regulasi tidak melarang OTP melalui SMS. Yang perlu Anda lakukan adalah menilai apakah metode itu memadai untuk tingkat risiko tertentu, dan mendokumentasikan mitigasi bila tetap digunakan. Ketiga, kepatuhan pada POJK 11/2022 tidak otomatis memenuhi kewajiban lain. Perlindungan data pribadi nasabah tunduk pada UU 27/2022 tentang Pelindungan Data Pribadi dan PP 71/2019 tentang Penyelenggaraan Sistem dan Transaksi Elektronik, sementara aspek pembuktian elektronik merujuk pada UU ITE beserta perubahannya. Bagi bank yang menjadi bagian dari konglomerasi keuangan, tata kelola terintegrasi di bawah UU P2SK 4/2023 dan POJK 30/2024 menambah dimensi konsolidasi pelaporan yang perlu diselaraskan dengan kebijakan keamanan grup.

Pertanyaan yang sering diajukan

Apakah POJK 11/2022 mewajibkan multi-factor authentication? Regulasi mewajibkan bank menerapkan pengamanan informasi dan pengendalian akses yang memadai terhadap profil risikonya, termasuk mekanisme autentikasi pengguna. Untuk layanan perbankan elektronik dan akses istimewa, praktik yang lazim diterima adalah autentikasi lebih dari satu faktor. Namun bentuk faktornya adalah keputusan bank yang harus didasarkan pada asesmen risiko terdokumentasi.

Apakah bank harus mengganti seluruh OTP dengan security key? Tidak. Pendekatan yang lebih efisien adalah segmentasi: security key untuk populasi dan transaksi berisiko tinggi, dan mekanisme lain yang tetap dipantau untuk risiko lebih rendah. Penggantian menyeluruh biasanya sulit dijustifikasi secara biaya dan operasional pada kanal ritel berskala besar.

Bagaimana menangani kehilangan security key oleh pegawai? Terbitkan minimal dua kunci per pengguna sejak awal, dan definisikan prosedur pencabutan serta penerbitan ulang dengan verifikasi identitas setara pendaftaran awal. Jalur pemulihan yang lemah akan meniadakan manfaat autentikator kuat, sehingga proses ini perlu diuji dan diaudit seperti kontrol lainnya.

Bukti apa yang perlu disiapkan untuk pemeriksaan? Siapkan dokumen asesmen risiko TI, kebijakan dan prosedur pengendalian akses, matriks pemetaan risiko ke kontrol autentikasi, catatan penerbitan dan pencabutan autentikator, hasil pengujian keamanan berkala, serta bukti evaluasi dan tindak lanjut temuan. Konsistensi antara kebijakan tertulis dan konfigurasi sistem yang berjalan adalah hal yang paling sering diperiksa.