Peraturan BSSN terkait Authentication untuk Instansi Pemerintah

Apa yang dapat ditunjukkan instansi ketika diminta menjelaskan bagaimana akses ke aplikasi SPBE diautentikasi, dibatasi, dan ditinjau? Jawabannya perlu lebih konkret daripada menyebut aplikasi sudah memakai kata sandi. Peraturan BSSN Nomor 4 Tahun 2021 memberi landasan teknis keamanan SPBE yang relevan untuk autentikasi aplikasi web dan mobile.

Namun, membaca kewajiban secara tepat sama pentingnya dengan memilih teknologi. Ketentuan tentang fungsi dan prosedur autentikasi tidak otomatis berarti setiap aplikasi pemerintah diwajibkan memakai autentikasi multifaktor (MFA) atau kunci keamanan fisik. MFA dapat menjadi kontrol yang tepat berdasarkan risiko dan arsitektur instansi, tetapi dasar keputusan itu perlu dicatat sebagai keputusan implementasi, bukan dikutip seolah-olah bunyi peraturan.

Panduan ini membantu pimpinan TI dan CISO memisahkan dua hal tersebut: apa yang tertulis dalam aturan keamanan SPBE dan apa yang dapat dipilih untuk mengurangi risiko. Fokusnya adalah pemetaan kontrol, bukti audit, dan langkah praktis sebelum instansi mengubah sistem autentikasi.

Daftar Isi

Ringkasnya

• Peraturan BSSN 4/2021 mengatur fungsi keamanan aplikasi SPBE, termasuk autentikasi; Pasal 27 memerinci prosedur autentikasi aplikasi web, sementara Pasal 28 membahas autentikasi dan manajemen sesi aplikasi mobile.
• Teks yang dirujuk tidak boleh disederhanakan menjadi mandat MFA universal atau kewajiban memakai kunci perangkat keras.
• Pilihan MFA sebaiknya mengikuti risiko akun, data, akses jarak jauh, dan kemampuan pemulihan.
• Bukti implementasi, pengujian, pemantauan, dan tindak lanjut membantu tim menjelaskan kontrol saat audit keamanan SPBE.

Peran BSSN dalam keamanan SPBE

Badan Siber dan Sandi Negara (BSSN) menjalankan fungsi pemerintahan di bidang keamanan siber dan persandian. Bagi instansi pusat maupun pemerintah daerah, keamanan aplikasi SPBE menjadi bagian dari tata kelola layanan digital, bukan pekerjaan konfigurasi yang selesai saat aplikasi diluncurkan. Pengelola perlu memastikan kontrol sesuai konteks layanan dan tetap berjalan ketika sistem, pengguna, atau ancaman berubah.

Peraturan BSSN Nomor 4 Tahun 2021 berjudul Pedoman Manajemen Keamanan Informasi Sistem Pemerintahan Berbasis Elektronik dan Standar Teknis dan Prosedur Keamanan Sistem Pemerintahan Berbasis Elektronik. Pasal 17 menyatakan instansi pusat dan pemerintah daerah menerapkan keamanan SPBE. Untuk aplikasi, Pasal 25 menetapkan ruang lingkup standar teknis keamanan aplikasi berbasis web dan mobile. Pasal 26 kemudian memuat fungsi keamanan aplikasi berbasis web, termasuk autentikasi, manajemen sesi, kontrol akses, validasi masukan, kriptografi, pencatatan dan penanganan kesalahan, perlindungan data, serta keamanan komunikasi.

Rujukan resmi penting karena istilah “authentication” di kalender atau materi vendor mungkin lebih sempit daripada kewajiban keamanan aplikasi secara keseluruhan. Pengelola perlu membaca pasal dalam konteks jenis aplikasi, fungsi, dan prosedur yang disebut, lalu menghubungkannya dengan kebijakan internal dan arsitektur layanan.

Untuk pimpinan, hasil praktisnya adalah peta yang dapat diperiksa: aplikasi apa yang masuk ruang lingkup, siapa pemilik kontrol, bagaimana autentikasi dikonfigurasi, dan dokumen apa yang menunjukkan penerapannya. Peta ini juga membantu menyusun prioritas perbaikan tanpa menganggap semua layanan mempunyai tingkat paparan dan dampak yang sama.

Instansi yang sedang menyusun tata kelola lebih luas dapat menggunakan panduan kepatuhan digital Indonesia sebagai titik navigasi internal untuk menghubungkan pembahasan autentikasi dengan kebijakan dan kontrol lain.

Apa yang diatur dalam pedoman BSSN tentang autentikasi

Pasal 26 mencantumkan autentikasi sebagai salah satu fungsi keamanan aplikasi web. Pasal 27 menjabarkan prosedur pengamanan autentikasi aplikasi web. Pokok yang perlu ditelaah oleh tim mencakup pengelolaan kata sandi, verifikasi pada sisi server, kebijakan kata sandi, pembatasan kegagalan autentikasi, pemulihan autentikasi, perlindungan kriptografis, dan komunikasi yang aman. Untuk aplikasi mobile, Pasal 28 membahas autentikasi dan manajemen sesi. Instansi sebaiknya merujuk langsung pada naskah untuk memetakan butir yang berlaku pada sistemnya.

Istilah pencarian BSSN Authentication sering dipakai untuk mencari pedoman ini, tetapi naskah resminya perlu dibaca berdasarkan nama peraturan dan pasal, bukan ringkasan kata kunci.

Daftar tersebut memberikan dasar untuk menilai desain dan bukti kontrol. Contohnya, kebijakan kata sandi perlu memiliki pemilik dan mekanisme penerapan; pembatasan percobaan gagal perlu diuji agar membantu mengurangi penyalahgunaan tanpa membuat pemulihan layanan tidak terkendali; dan prosedur pemulihan perlu mencegah proses reset menjadi jalan pintas yang lebih lemah daripada proses masuk.

Peraturan tersebut membahas autentikasi sebagai fungsi dan prosedur keamanan. Jangan mengubahnya menjadi klaim bahwa setiap pengguna, setiap aplikasi, atau setiap transaksi wajib memakai dua faktor, kecuali ada ketentuan lain yang secara spesifik berlaku dan telah diverifikasi. Demikian pula, penyebutan perlindungan kriptografis tidak dengan sendirinya berarti aturan mewajibkan produk atau bentuk autentikator tertentu.

Batas interpretasi: bedakan persyaratan yang tertulis dalam pasal, kontrol yang dipilih instansi untuk memenuhi risiko, dan fitur produk yang tersedia. Catat sumber dan alasan untuk masing-masing.

Menentukan MFA berdasarkan risiko

MFA menambahkan lebih dari satu bukti autentikasi ke proses masuk. Pertimbangkan faktor risiko, bukan sekadar tren: nilai dan sensitivitas data, kewenangan akun, paparan layanan ke internet, akses dari luar jaringan, kemampuan yang diberikan akun istimewa, serta akibat jika kredensial dicuri. Akun administrator dan akun yang dapat mengubah konfigurasi atau menyetujui transaksi mungkin memerlukan perlindungan lebih kuat daripada akun dengan akses terbatas, tetapi keputusan akhir harus sesuai analisis instansi.

Mulailah dengan inventaris identitas dan jalur akses. Petakan akun manusia, akun layanan, administrator, akun darurat, akses vendor, federasi identitas, dan sistem lama yang tidak mendukung faktor tambahan. Tandai titik masuk yang mengakses data sensitif atau dapat memperluas hak akses. Lalu tentukan cakupan penerapan dan pengecualian dengan alasan, pemilik, serta tanggal evaluasi ulang.

Evaluasi pula seluruh siklus autentikasi, bukan hanya layar masuk. Registrasi faktor, perubahan perangkat, kehilangan faktor, bantuan help desk, pemulihan akun, dan pencabutan akses dapat menjadi celah jika lebih lemah daripada login normal. Pengguna perlu mengetahui pilihan pemulihan, sementara petugas layanan harus bisa memverifikasi permintaan tanpa mengandalkan data yang mudah ditebak atau diperoleh pihak lain.

Uji dampak operasional sebelum penerapan luas. Pastikan alur bekerja pada perangkat dan jaringan yang digunakan, termasuk kondisi konektivitas terbatas bila relevan. Periksa aksesibilitas, kebutuhan pengguna, integrasi dengan penyedia identitas, pencatatan peristiwa, dan prosedur untuk akun yang tidak dapat memakai faktor tertentu. Rencana dukungan dan pemulihan harus tersedia sebelum kontrol menjadi syarat akses.

Keputusan akhirnya sebaiknya dapat dijelaskan: risiko apa yang hendak dikurangi, siapa yang tercakup, mengapa metode dipilih, bagaimana keberhasilan diuji, dan kapan kontrol ditinjau. Dengan demikian, MFA menjadi kontrol berbasis risiko yang terukur oleh instansi, bukan klaim kepatuhan otomatis.

Tim yang perlu memetakan pilihan ini bersama bukti dan pemilik kontrol dapat menjajaki Konsultasi BSSN Readiness setelah cakupan dan kanal layanan dikonfirmasi.

Sebagai pembanding teknis, NIST SP 800-63-4 membahas pedoman identitas digital dan autentikasi untuk konteks federal Amerika Serikat. Gunakan sebagai referensi rekayasa bila sesuai; dokumen NIST itu bukan peraturan Indonesia dan tidak menggantikan penilaian terhadap ketentuan SPBE yang berlaku.

Kunci keamanan sebagai salah satu pilihan

Kunci keamanan fisik dapat menjadi salah satu pilihan autentikasi tahan phishing, bergantung pada standar dan konfigurasi yang didukung oleh penyedia identitas serta aplikasi. Sebelum memilih perangkat tertentu, verifikasi dokumentasi produsennya, protokol yang benar-benar digunakan, kompatibilitas dengan sistem instansi, mekanisme registrasi, serta cara mengelola kunci cadangan. Nama merek saja tidak cukup untuk menyimpulkan perangkat cocok atau memenuhi kewajiban tertentu.

Uji skenario yang berisiko: pengguna kehilangan kunci, berganti jabatan, bekerja di lokasi dengan keterbatasan jaringan, atau perlu akses darurat. Pastikan pencabutan kunci yang hilang dapat dilakukan, faktor cadangan tidak menurunkan keamanan secara drastis, dan help desk mempunyai proses yang dapat diaudit. Sediakan inventaris pemegang dan status perangkat dengan perlindungan data yang proporsional.

Kunci fisik juga bukan satu-satunya cara menerapkan faktor tambahan. Pilihan lain dapat meliputi aplikasi autentikator atau mekanisme yang dikelola platform identitas, sesuai dukungan dan hasil penilaian risiko. Bandingkan ancaman yang ditangani, ketergantungan perangkat, kemudahan pemulihan, biaya operasional, dan kesiapan pengguna. Jangan menjanjikan bahwa satu pilihan menghapus seluruh risiko phishing atau menjamin kepatuhan.

Jika perangkat menjadi pilihan, tetapkan pula proses pengadaan, penggantian, dan pemusnahan sesuai kebijakan aset instansi. Catatan serial atau identitas perangkat harus dibatasi aksesnya dan tidak memuat rahasia autentikasi.

Sebelum memilih perangkat: buktikan kompatibilitas pada lingkungan sasaran dan jalankan uji pemulihan. Hasil uji serta keputusan pengecualian perlu disimpan bersama pemilik kontrol.

Autentikasi berbeda dari tanda tangan digital

Autentikasi membantu sistem menilai apakah seseorang atau entitas yang mencoba masuk memiliki bukti yang sah. Tanda tangan digital digunakan dalam alur dokumen untuk mengaitkan penandatangan dengan dokumen dan mendeteksi perubahan sesuai proses dan layanan yang digunakan. Keduanya dapat muncul dalam satu perjalanan layanan, tetapi fungsi dan bukti yang dihasilkan berbeda.

Karena itu, tanda tangan digital bukan faktor MFA untuk login aplikasi. Sebaliknya, MFA tidak dengan sendirinya membuktikan bahwa suatu dokumen telah ditandatangani atau bahwa tanda tangan pada dokumen valid. Arsitektur perlu menjelaskan titik ketika pengguna diautentikasi, kewenangan yang diberikan, tindakan yang disetujui, serta bukti yang disimpan untuk transaksi dokumen.

Tilaka berfokus pada alur tanda tangan digital dan layanan identitas yang dijelaskan dalam dokumentasi resminya. Evaluasi kapabilitas yang relevan terhadap kebutuhan dokumen secara terpisah; jangan menganggap layanan tersebut menggantikan penyedia autentikasi atau MFA instansi. Pelajari layanan tanda tangan digital sebagai bagian dari evaluasi alur tanda tangan.

Jika instansi menghubungkan login, persetujuan, dan penandatanganan, lakukan pemisahan peran serta catat keterkaitan peristiwa tanpa mengekspos data pribadi yang tidak diperlukan. Pengujian harus memeriksa apakah perubahan status dokumen tercatat, apakah pengguna memahami tindakan yang disetujui, serta apakah bukti dapat ditelusuri ke proses yang benar.

Pemisahan tersebut memudahkan investigasi ketika login berhasil tetapi persetujuan dokumen dipersoalkan, atau ketika dokumen ditandatangani melalui proses yang berbeda dari autentikasi aplikasi. Tetapkan identitas transaksi yang dapat menghubungkan log tanpa menyimpan isi data berlebihan.

Menyiapkan bukti audit keamanan SPBE

Peraturan BSSN Nomor 8 Tahun 2024 menetapkan standar dan tata cara pelaksanaan audit keamanan SPBE. Instrumen ini memberi konteks untuk menata proses audit, kriteria, bukti, dan pelaporan; instansi perlu membaca naskah lengkap untuk menentukan kewajiban yang tepat bagi objek auditnya. Audit bukan alasan untuk mengumpulkan tangkapan layar sebanyak mungkin. Bukti harus relevan dengan kontrol, dapat ditelusuri, memiliki konteks waktu, dan dilindungi sesuai klasifikasinya.

Bukti yang berguna menjawab tiga pertanyaan: kontrol apa yang ditetapkan, bagaimana penerapannya dibuktikan, dan apa yang dilakukan ketika pengujian menemukan kelemahan?

Untuk autentikasi, siapkan satu paket yang terhubung. Mulai dari kebijakan dan standar konfigurasi yang disetujui; inventaris aplikasi serta pemiliknya; diagram alur identitas; daftar peran dan akses; konfigurasi yang menunjukkan kontrol relevan; hasil uji autentikasi dan sesi; prosedur reset dan akses darurat; serta catatan pemantauan dan penanganan insiden yang terkait. Rekam versi, lingkungan uji atau produksi, tanggal, pelaksana, dan persetujuan agar bukti tidak kehilangan makna.

Hubungkan setiap temuan dengan tindak lanjut. Catat tingkat prioritas menurut metode instansi, penanggung jawab, target penyelesaian, bukti perbaikan, dan keputusan penerimaan risiko jika ada. Jangan mengubah status temuan menjadi “selesai” hanya karena tiket ditutup; simpan hasil verifikasi bahwa kontrol telah diperbaiki atau risiko telah disetujui pejabat berwenang.

Batasi akses terhadap log dan artefak audit. Tetapkan masa simpan sesuai kebijakan yang berlaku, lindungi data sensitif, dan pastikan pihak yang meninjau bukti memiliki kewenangan. Saat diminta auditor, berikan bukti yang relevan beserta penjelasan hubungan antara kriteria audit, sistem, periode, dan kontrol. Peraturan BSSN 8/2024 dapat ditelaah melalui catatan resmi JDIH BPK; cocokkan interpretasi dengan teks lengkap serta tata kelola audit instansi.

Pertanyaan yang sering diajukan

Langkah berikutnya

Mulai dengan memilih aplikasi SPBE yang paling penting bagi layanan dan memetakan jalur autentikasinya. Cocokkan implementasi web atau mobile dengan Pasal 26–28 Peraturan BSSN 4/2021, dokumentasikan risiko akun dan data, lalu tetapkan apakah faktor tambahan diperlukan. Uji pula registrasi, pemulihan, pencabutan, pencatatan, dan akses darurat. Terakhir, susun bukti beserta pemilik kontrol dan jadwal peninjauannya.

Dalam rapat tinjauan, pastikan pemilik aplikasi, keamanan informasi, operasi, dan pengelola identitas memahami keputusan yang sama. Catat pengecualian dan dependensi sistem lama, lalu beri tanggal untuk menilai ulang kontrol setelah perubahan arsitektur, ancaman, atau layanan.

Jika instansi membutuhkan pendampingan untuk memetakan kontrol, menilai bukti, dan menyusun ruang lingkup kesiapan, Konsultasi BSSN Readiness dapat menjadi langkah awal setelah cakupan layanan dan kanalnya dikonfirmasi. Untuk mengenali lingkup perusahaan, lihat profil Docotel. Penilaian, keputusan kontrol, dan persetujuan kepatuhan tetap berada pada instansi.

Disusun oleh: Tim Solution Architects Docotel
Dipublikasikan: 2026-11-13
Terakhir diperbarui: 2026-11-13