Ketika layanan otorisasi mengalami gangguan, hasilnya berubah. Pemeriksaan izin tidak berhasil diselesaikan, tetapi aplikasi tetap menampilkan laporan.

Dari sisi pemantauan operasional, layanan utama mungkin terlihat sehat. Halaman dapat dibuka, respons tetap cepat, dan jumlah transaksi yang berhasil tidak menurun. Namun, sebagian keberhasilan itu terjadi karena pemeriksaan keamanan tidak lagi menentukan keputusan akses.

Ilustrasi tersebut menunjukkan risiko desain fail-open: kegagalan suatu kontrol membuat sistem beralih ke keadaan yang lebih permisif.

Aplikasi yang tidak dapat memastikan kewenangan pengguna tidak memiliki dasar untuk menganggap permintaan tersebut telah diizinkan. Jika gangguan teknis justru membuka akses, ketersediaan layanan dipertahankan dengan mengorbankan batas perlindungan data.

Ketidakpastian Diubah Menjadi Persetujuan

Hasil pemeriksaan otorisasi perlu dibedakan dengan jelas. Permintaan dapat diizinkan, ditolak, atau tidak dapat diputuskan karena terjadi gangguan.

Keadaan terakhir dapat muncul akibat waktu tunggu yang terlampaui, koneksi terputus, respons tidak valid, atau layanan kebijakan tidak tersedia.

Masalah terjadi ketika aplikasi hanya mengenali dua hasil: berhasil dan gagal. Seluruh kegagalan teknis kemudian diarahkan ke jalur yang melanjutkan permintaan.

Akibatnya, kegagalan memperoleh keputusan diperlakukan seolah-olah merupakan keputusan mengizinkan.

MITRE menggolongkan perilaku beralih ke keadaan yang lebih lemah saat terjadi kegagalan dalam CWE-636, yaitu Not Failing Securely. Pada kontrol akses, dampaknya dapat berupa terlewatinya pembatasan yang seharusnya berlaku.

Perbedaan antara penolakan dan gangguan tetap penting bagi penanganan operasional. Penolakan menunjukkan kebijakan tidak memberikan izin, sedangkan gangguan menunjukkan keputusan belum dapat diperoleh. Keduanya tidak membenarkan pemberian akses terhadap sumber daya yang membutuhkan otorisasi.

Tekanan Menjaga Ketersediaan Dapat Menggeser Batas Keamanan

Fail-open dapat muncul dari keputusan yang terlihat masuk akal pada saat implementasi.

Tim ingin mencegah layanan pendukung menjadi penyebab terhentinya aplikasi utama. Ketika pemeriksaan izin terlambat, permintaan dilanjutkan agar pengguna tetap dapat bekerja.

Pilihan itu kemudian menjadi perilaku bawaan tanpa pembatasan yang memadai.

Dokumentasi Envoy memberikan contoh bahwa perilaku saat kegagalan dapat ditentukan melalui konfigurasi. Pada filter otorisasi eksternal, pengaturan failure_mode_allow dapat membuat permintaan diterima apabila komunikasi dengan layanan otorisasi gagal atau layanan tersebut mengembalikan kesalahan HTTP 5xx. Nilai bawaannya adalah false.

Keberadaan pengaturan tersebut tidak berarti setiap sistem yang menggunakannya pasti rentan. Risiko bergantung pada jalur permintaan, pemeriksaan lain yang tetap berjalan, dan sumber daya yang dilindungi.

Namun, contoh itu menegaskan bahwa perilaku saat gangguan merupakan keputusan keamanan yang nyata. Satu perubahan konfigurasi dapat mengubah cara aplikasi memperlakukan permintaan yang belum memperoleh keputusan izin.

Keputusan semacam ini perlu ditinjau bersama pemilik sistem dan tim keamanan, termasuk dampaknya terhadap data sensitif dan tindakan administratif.

Status Masuk Tidak Membuktikan Hak atas Setiap Tindakan

Salah satu alasan untuk melanjutkan permintaan ketika otorisasi gagal adalah pengguna sudah berhasil masuk ke aplikasi.

Padahal, identitas yang sah belum menjelaskan seluruh kewenangannya.

Seorang pegawai dapat memiliki akun aktif tanpa berhak mengakses laporan keuangan. Administrator pada satu unit juga belum tentu boleh mengubah pengguna di unit lain.

Autentikasi membantu memastikan identitas. Otorisasi menentukan apakah identitas tersebut boleh melakukan tindakan terhadap objek tertentu.

Jika layanan otorisasi gagal, aplikasi mungkin masih mengetahui siapa penggunanya. Namun, informasi itu belum cukup untuk membuktikan haknya atas permintaan yang sedang diproses.

Token yang valid pun harus dibaca sesuai cakupannya. Bukti identitas, masa berlaku, lingkup akses, dan kondisi kebijakan merupakan unsur yang perlu dievaluasi sesuai rancangan sistem.

Karena itu, jalur cadangan yang sekadar memeriksa status masuk dapat memperluas akses di luar batas yang semestinya.

Fail-Closed Tidak Harus Menghentikan Seluruh Aplikasi

Kekhawatiran terhadap fail-closed biasanya berkaitan dengan dampak bisnis. Jika layanan otorisasi gagal, apakah seluruh aplikasi harus berhenti?

Perusahaan dapat merancang pembatasan yang lebih terarah.

Halaman publik, panduan penggunaan, atau fungsi yang tidak bergantung pada keputusan izin yang gagal mungkin tetap tersedia. Sementara itu, pembukaan data terbatas, ekspor massal, perubahan hak akses, dan tindakan berdampak lainnya perlu memiliki dasar otorisasi yang sah.

Pembagian tersebut harus mengikuti kebutuhan setiap fungsi. Label “hanya membaca” tidak otomatis menjadikan tindakan aman, sebab membaca dokumen rahasia tetap dapat menyebabkan kebocoran.

Prinsip fail-safe defaults yang dibahas Jerome H. Saltzer dan Michael D. Schroeder dalam artikel ilmiah “The Protection of Information in Computer Systems” menempatkan pemberian izin sebagai dasar keputusan akses. Prinsip ini membantu perusahaan menetapkan keadaan bawaan yang konservatif ketika syarat pemberian akses belum terpenuhi.

Penerapannya dapat berupa penundaan tindakan, penolakan sementara, atau penyediaan fungsi terbatas yang telah ditentukan sebelumnya.

Pengguna perlu menerima pesan yang menjelaskan bahwa pemeriksaan kewenangan sedang tidak tersedia. Pada saat yang sama, tim operasional membutuhkan sinyal yang membedakan gangguan tersebut dari penolakan akses biasa.

Cache Izin Memerlukan Batas Kesegaran yang Jelas

Untuk mengurangi ketergantungan pada layanan pusat, aplikasi dapat menyimpan hasil keputusan otorisasi sementara.

Pendekatan ini membutuhkan aturan yang tegas. Keputusan yang sebelumnya mengizinkan akses dapat menjadi kedaluwarsa setelah pengguna berpindah peran, dikeluarkan dari grup, atau kehilangan hak atas objek.

Jika gangguan layanan membuat aplikasi terus memperpanjang penggunaan keputusan lama, pencabutan akses dapat tertunda tanpa batas yang dapat dipastikan.

Cache perlu mengikat keputusan pada identitas, tindakan, objek, dan konteks kebijakan yang relevan. Masa berlaku serta mekanisme pembatalannya juga harus ditentukan berdasarkan risiko.

Keputusan yang tidak ditemukan dalam cache tidak boleh otomatis dianggap mengizinkan. Demikian pula, hasil untuk satu objek tidak semestinya digunakan sebagai pembenaran mengakses objek lain.

Rekomendasi ini perlu diterjemahkan ke dalam kebijakan yang dapat diuji. Untuk sebagian tindakan sensitif, perusahaan dapat menetapkan bahwa keputusan baru tetap diperlukan meskipun keputusan lama tersedia.

Penggunaan cache kemudian menjadi pilihan yang terukur, dengan konsekuensi kesegaran izin yang dipahami.

Akses Darurat Harus Tetap Memiliki Dasar Kewenangan

Dalam keadaan tertentu, organisasi membutuhkan prosedur akses darurat agar kegiatan penting dapat dilanjutkan.

Prosedur tersebut perlu dirancang secara eksplisit, dengan identitas khusus, ruang lingkup terbatas, masa berlaku singkat, serta pencatatan dan peninjauan yang sesuai.

Aktivasi akses darurat juga harus memiliki dasar persetujuan yang jelas. Kegagalan komunikasi dengan layanan otorisasi tidak semestinya diam-diam mengaktifkan hak tambahan bagi seluruh pengguna.

Perbedaan ini penting bagi pertanggungjawaban. Organisasi harus dapat menjelaskan siapa yang menggunakan akses darurat, mengapa akses diberikan, dan tindakan apa yang dilakukan.

Apabila jalur cadangan tidak meninggalkan bukti tersebut, perusahaan akan kesulitan membedakan kebutuhan operasional yang sah dari penyalahgunaan selama gangguan.

Pengujian Harus Memasukkan Kegagalan Layanan Otorisasi

Pengujian kontrol akses sering dilakukan ketika seluruh komponen tersedia. Kondisi ini membuktikan perilaku normal, tetapi belum menunjukkan bagaimana aplikasi mengambil keputusan saat dependensinya gagal.

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

Untuk mengevaluasi risiko fail-open, pengujian perlu menggunakan lingkungan terkendali dan gangguan yang telah disepakati. Mulailah dengan permintaan yang seharusnya ditolak, kemudian amati apakah keputusan berubah ketika pemeriksaan izin mengalami masalah.

Skenario yang dapat dimasukkan meliputi:

• Layanan otorisasi tidak dapat dihubungi.
• Respons melewati batas waktu tunggu.
• Layanan mengembalikan kesalahan HTTP 5xx.
• Respons tidak lengkap atau tidak sesuai format.
• Keputusan cache telah kedaluwarsa.
• Hak pengguna dicabut sebelum gangguan terjadi.
• Mekanisme penghentian sementara koneksi atau circuit breaker aktif.
• Layanan pulih setelah aplikasi menjalankan jalur cadangan.

Masing-masing keadaan perlu diuji karena dapat melewati cabang penanganan yang berbeda.

Bukti pengujian harus menunjukkan apakah data benar-benar diberikan atau perubahan benar-benar terjadi. Kode status respons saja belum cukup. Aplikasi dapat menampilkan pesan gagal setelah tindakan berdampak telanjur dilakukan.

Periksa pula konsistensi antara gateway, API, dan layanan internal. Penolakan pada satu pintu masuk belum membuktikan perlindungan jika jalur lain dapat mencapai fungsi yang sama tanpa pemeriksaan setara.

Ukur Keamanan ketika Komponen Tidak Bekerja Normal

Pemantauan perlu membedakan permintaan yang lolos otorisasi dari permintaan yang diteruskan akibat mekanisme cadangan.

Jika keduanya hanya tercatat sebagai transaksi berhasil, gangguan kontrol akses dapat tersembunyi di balik angka ketersediaan yang baik.

Tim perlu mengetahui jumlah kegagalan pemeriksaan, tindakan yang tertunda, penggunaan keputusan cache, dan aktivasi akses darurat. Informasi ini membantu menilai dampak gangguan serta menelusuri aktivitas yang memerlukan pemeriksaan lanjutan.

Setelah pemulihan, perusahaan juga perlu memastikan perilaku sementara telah berakhir. Konfigurasi darurat yang tertinggal dapat memperpanjang risiko jauh setelah insiden operasional selesai.

Ketahanan aplikasi mencakup kemampuan mempertahankan batas keamanan ketika layanan pendukung bermasalah. Permintaan yang terus diproses harus tetap memiliki alasan otorisasi yang dapat dibuktikan.

Evaluasi Perilaku Kegagalan Aplikasi Bersama Fourtrezz

Fourtrezz menyediakan layanan Penetration Testing dan Vulnerability Assessment untuk aplikasi web, API, jaringan, serta server.

Diskusikan kerja sama dengan Fourtrezz untuk menyusun pengujian kontrol akses yang mencakup kondisi normal dan kegagalan layanan pendukung. Ruang lingkup dapat dibahas dengan mempertimbangkan dependensi otorisasi, konfigurasi gateway, mekanisme cache, serta jalur penanganan kesalahan.

Pengujian yang terarah membantu perusahaan memperoleh bukti tentang perilaku aplikasi saat keputusan izin tidak dapat diperoleh, kemudian menentukan prioritas perbaikannya.

Hubungi Fourtrezz:

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