Bayangkan sebuah perusahaan mengalami gangguan pada identity provider. Administrator tidak dapat login. Multifactor authentication tidak merespons. Kebijakan Conditional Access tetap bekerja, tetapi justru membuat seluruh administrator kehilangan akses ke sistem yang harus segera diperbaiki.

Dalam kondisi seperti ini, kontrol keamanan yang biasanya melindungi perusahaan dapat berubah menjadi penghalang operasional.

Karena itu, banyak organisasi menyediakan break-glass account atau emergency access account. Akun ini menjadi jalur terakhir untuk memperoleh kembali akses administratif ketika mekanisme normal tidak dapat digunakan.

Masalahnya, agar tetap dapat bekerja dalam keadaan darurat, akun tersebut memang sengaja dirancang berbeda dari akun administrator biasa.

Ia mungkin tidak bergantung pada identity provider yang sama. Ia dapat dikecualikan dari kebijakan tertentu yang berpotensi menyebabkan lockout. Hak aksesnya pun biasanya sangat tinggi agar mampu memulihkan kontrol terhadap sistem.

Semua karakteristik tersebut dibutuhkan untuk menjaga business continuity.

Namun karakteristik yang sama juga membuat break-glass account menjadi salah satu identitas paling sensitif di perusahaan.

Akses yang dirancang sebagai penyelamat dapat berubah menjadi privileged path permanen apabila tidak dikendalikan dengan baik.

Akun Darurat Harus Tetap Berfungsi ketika Sistem Normal Gagal

Administrator biasa umumnya berada di bawah sejumlah lapisan keamanan.

Login dapat bergantung pada federation, multifactor authentication, device compliance, Conditional Access, Privileged Identity Management, atau mekanisme identity governance lainnya.

Semakin matang keamanan perusahaan, semakin banyak kontrol yang bekerja sebelum seseorang memperoleh privileged access.

Namun pendekatan tersebut menciptakan persoalan ketika salah satu komponen utama mengalami gangguan.

Jika seluruh administrator menggunakan identity provider yang sama dan identity provider tersebut gagal, perusahaan dapat kehilangan kemampuan untuk mengelola sistemnya sendiri.

Di sinilah emergency access dibutuhkan.

Break-glass account harus memiliki cukup independensi agar tidak ikut gagal ketika jalur authentication utama terganggu.

Namun independensi tersebut tidak boleh diterjemahkan sebagai pengecualian tanpa batas.

Prinsipnya seharusnya jelas:

dependency boleh berbeda, tetapi tingkat perlindungan tidak boleh menjadi lebih lemah.

Masalah Dimulai ketika Emergency Access Berubah Menjadi Permanent Privilege

Break-glass account biasanya memiliki hak istimewa yang sangat tinggi.

Hal tersebut masuk akal. Dalam kondisi darurat, organisasi mungkin membutuhkan kemampuan untuk memperbaiki konfigurasi identity, mengaktifkan kembali administrator, atau mengubah policy yang menyebabkan lockout.

Namun privilege tinggi menimbulkan risiko ketika akun tersebut selalu aktif, jarang ditinjau, dan tidak memiliki governance yang ketat.

Sebuah akun dapat dibuat lima tahun lalu untuk keperluan darurat.

Administrator yang membuatnya mungkin sudah tidak bekerja di perusahaan.

Dokumentasinya mungkin tidak lagi diperbarui.

Credential-nya mungkin masih sama.

Tidak ada yang benar-benar mengetahui kapan terakhir akun tersebut diuji.

Namun privilege-nya tetap aktif.

Dalam kondisi seperti ini, perusahaan sebenarnya memiliki sebuah identitas dengan akses sangat luas yang hidup di luar aktivitas administratif sehari-hari.

Justru karena jarang digunakan, akun tersebut mudah terlupakan.

Akun yang Jarang Digunakan Seharusnya Mendapat Monitoring Paling Ketat

Ada paradoks menarik pada emergency access account.

Akun biasa digunakan setiap hari. Karena itu, aktivitas login dalam jumlah tertentu adalah hal normal.

Break-glass account seharusnya hampir tidak pernah digunakan.

Artinya, satu login saja sebenarnya merupakan kejadian yang sangat signifikan.

Ketika akun darurat melakukan authentication pada pukul 02.00, Security Operations Center seharusnya tidak melihatnya sebagai login administrator biasa.

Pertanyaan harus langsung muncul:

Siapa yang menggunakan akun tersebut?

Apakah sedang ada insiden?

Apakah penggunaan sudah mendapat persetujuan?

Apakah login berasal dari workstation yang seharusnya?

Apa yang dilakukan setelah berhasil masuk?

Dengan pola ini, kondisi normal break-glass account sebenarnya sederhana:

tidak ada aktivitas.

Setiap penyimpangan seharusnya menghasilkan high-priority alert.

Jika organisasi baru mengetahui emergency account digunakan beberapa hari setelah login terjadi, kontrol monitoring belum cukup kuat.

Credential Darurat yang Disimpan Terlalu Lama Dapat Menjadi Risiko Tersembunyi

Karena break-glass account jarang digunakan, ada kecenderungan untuk tidak menyentuh credential-nya.

Logikanya cukup masuk akal.

Jika password atau authentication method terlalu sering diubah, ada kekhawatiran credential tidak tersedia ketika benar-benar dibutuhkan.

Namun strategi “jangan diubah agar tetap aman” juga memiliki kelemahan.

Credential dapat diketahui oleh administrator lama.

Salinan dapat tersimpan pada dokumen internal.

Password mungkin pernah dikirim melalui pesan.

Perangkat authentication dapat berada di lokasi yang tidak lagi diketahui dengan jelas.

Semakin lama credential hidup, semakin sulit memastikan siapa saja yang pernah memiliki akses terhadapnya.

Karena itu, keamanan break-glass account tidak hanya bergantung pada kekuatan password.

Aspek yang lebih penting adalah credential custody.

Organisasi harus mengetahui:

• siapa yang memiliki kewenangan membuka credential;
• di mana credential disimpan;
• bagaimana akses dicatat;
• siapa yang melakukan review;
• bagaimana credential diperbarui setelah digunakan.

Authentication yang tahan phishing juga menjadi penting, khususnya ketika akun memiliki privilege tingkat tinggi.

Shared Identity Membuat Audit Menjadi Lebih Sulit

Emergency account biasanya tidak seharusnya melekat pada satu karyawan.

Tujuannya adalah memastikan akun tetap tersedia meskipun seorang administrator sedang tidak dapat dihubungi.

Namun desain tersebut menciptakan persoalan audit.

Log mungkin mencatat:

EmergencyAdmin logged in

Tetapi log tersebut belum menjawab siapa manusia di balik aktivitas itu.

Apakah administrator infrastruktur?

Security engineer?

Head of IT?

Atau seseorang yang mendapatkan credential tanpa izin?

Karena itu, audit tidak boleh berhenti pada authentication log.

Break-glass procedure perlu memiliki mekanisme tambahan untuk mencatat identitas manusia yang menggunakan akun.

Setidaknya organisasi perlu mengetahui:

• siapa yang meminta akses;
• alasan penggunaan;
• siapa yang memberikan approval;
• siapa yang membuka credential;
• kapan sesi dimulai;
• tindakan apa yang dilakukan;
• kapan akses dihentikan.

Dengan demikian, emergency account tetap dapat bersifat non-personal tanpa menghilangkan accountability.

Break-Glass Account Adalah High-Value Target

Dari sudut pandang attacker, emergency access account memiliki karakteristik yang sangat menarik.

Privilege tinggi.

Jarang digunakan.

Harus selalu tersedia.

Berpotensi memiliki pengecualian tertentu dari mekanisme normal.

Kombinasi tersebut membuat credential break-glass jauh lebih bernilai dibandingkan akun user biasa.

Jika akun staf biasa berhasil dikompromikan, attacker mungkin masih perlu melakukan privilege escalation.

Jika akun administrator utama dikompromikan, beberapa kontrol lain masih dapat membatasi aktivitasnya.

Namun apabila credential emergency administrator berhasil diperoleh, penyerang berpotensi memiliki jalur langsung menuju kontrol administratif tingkat tinggi.

Karena itu, break-glass account seharusnya diperlakukan sebagai critical identity asset, bukan sekadar akun cadangan.

Backdoor Tidak Selalu Dibuat oleh Penyerang

Istilah backdoor biasanya identik dengan malware, hidden account, atau mekanisme akses rahasia yang sengaja dibuat attacker.

Break-glass account tentu bukan backdoor dalam pengertian tersebut.

Akun ini sah dan dibutuhkan.

Namun dari perspektif risiko, sebuah jalur resmi dapat memiliki karakteristik menyerupai backdoor apabila:

• memiliki privilege sangat tinggi;
• melewati sebagian kontrol normal;
• jarang diawasi;
• credential-nya tidak dikelola dengan baik;
• penggunaannya tidak menghasilkan alert;
• tidak ada prosedur approval.

Karena itu, istilah “backdoor resmi” lebih tepat dipahami sebagai peringatan terhadap governance yang lemah.

Break-glass account bukan backdoor ketika dirancang dengan benar. Ia mulai menyerupai backdoor ketika organisasi mempertahankan jalur istimewa tetapi kehilangan kontrol atas siapa, kapan, dan mengapa jalur tersebut digunakan.

Pengecualian Conditional Access Tidak Berarti Keamanan Authentication Boleh Diturunkan

Emergency account sering perlu dikecualikan dari Conditional Access policy tertentu agar tidak ikut terkunci ketika terjadi kesalahan konfigurasi.

Namun pengecualian tersebut harus dipahami secara hati-hati.

Tujuannya bukan membuat akun lebih mudah digunakan.

Tujuannya adalah menghindari ketergantungan pada kontrol yang sedang mengalami gangguan.

Karena itu, authentication tetap perlu kuat.

Metode yang tahan phishing seperti FIDO2 atau certificate-based authentication dapat menjadi pilihan yang lebih tepat daripada hanya bergantung pada password.

Ini menciptakan perbedaan penting:

break-glass account boleh memiliki jalur autentikasi yang berbeda, tetapi tidak boleh memiliki authentication security yang lebih lemah.

Redundansi Dibutuhkan, tetapi Jumlah Akun Harus Tetap Terbatas

Satu emergency account saja dapat menjadi single point of failure.

Jika perangkat authentication hilang, credential rusak, akun tidak sengaja dinonaktifkan, atau konfigurasi berubah, perusahaan kembali menghadapi risiko lockout.

Karena itu, organisasi biasanya memerlukan lebih dari satu emergency account.

Namun redundansi bukan berarti membuat banyak akun darurat.

Semakin banyak akun dengan privilege ekstrem, semakin besar permukaan risiko yang harus dikelola.

Tujuannya adalah memiliki jalur cadangan yang cukup untuk memastikan availability tanpa menciptakan kumpulan privileged account permanen.

Setiap akun tambahan harus memiliki alasan yang jelas.

Break-Glass Account yang Tidak Pernah Diuji Bisa Gagal Saat Benar-Benar Dibutuhkan

Ada kesalahan lain yang terlihat aman pada permukaan:

“Jangan pernah login ke akun darurat kecuali benar-benar ada insiden.”

Masalahnya, organisasi kemudian tidak mengetahui apakah akun tersebut masih dapat digunakan.

Authentication method dapat berubah.

Policy dapat berubah.

Device dapat kedaluwarsa.

Credential dapat tidak lagi valid.

Administrator yang memahami prosedurnya bisa sudah pindah tim.

Ketika krisis benar-benar terjadi, baru diketahui bahwa emergency access tidak berfungsi.

Karena itu, akun darurat perlu diuji secara berkala.

Pengujian dapat memastikan:

• authentication tetap berhasil;
• privilege masih sesuai;
• dokumentasi masih benar;
• credential tersedia;
• personel memahami prosedur;
• monitoring bekerja.

Emergency account yang hanya tersedia di dalam dokumen belum tentu benar-benar tersedia ketika perusahaan membutuhkannya.

Pengujian Juga Harus Menguji Alarm

Saat melakukan break-glass drill, organisasi seharusnya tidak hanya memeriksa kemampuan login.

Monitoring juga harus ikut diuji.

SOC sebaiknya mengetahui bahwa simulasi sedang dilakukan.

Namun alert tetap harus muncul.

Authentication log tetap dicatat.

Activity log tetap tersedia.

Jika emergency account berhasil digunakan tetapi SIEM tidak mendeteksi aktivitas apa pun, pengujian tersebut menemukan masalah yang sama pentingnya dengan kegagalan login.

Dengan demikian, satu drill menguji dua hal sekaligus:

availability akses darurat dan kemampuan deteksi penyalahgunaannya.

Perusahaan Perlu Menentukan Kapan “Kaca” Benar-Benar Boleh Dipecahkan

Tidak semua kendala administratif dapat disebut emergency.

Jika definisinya terlalu luas, break-glass account dapat berubah menjadi shortcut.

Seorang administrator lupa password.

Approval PIM membutuhkan waktu.

Administrator utama sedang cuti.

Conditional Access dianggap merepotkan.

Tanpa aturan yang jelas, kondisi seperti ini dapat dijadikan alasan menggunakan emergency account.

Padahal, akun tersebut seharusnya digunakan ketika jalur administratif normal benar-benar tidak tersedia.

Contohnya:

• identity provider outage;
• tenant lockout;
• kegagalan authentication infrastructure;
• seluruh administrator kehilangan metode authentication;
• kesalahan konfigurasi yang memblokir semua privileged account.

Batas ini perlu ditulis secara eksplisit dalam prosedur.

Emergency tidak boleh ditentukan berdasarkan kenyamanan.

Setiap Penggunaan Harus Dianggap sebagai Security Event

Ketika break-glass account digunakan, organisasi sebaiknya menjalankan proses yang mirip dengan penanganan insiden.

Alurnya dapat berbentuk:

Login → Alert → Verification → Approval Record → Monitoring → Review

Hal tersebut tetap berlaku meskipun penggunaan sepenuhnya sah.

Tujuan monitoring bukan mencurigai administrator.

Tujuannya adalah memastikan jalur yang memiliki privilege ekstrem tidak pernah digunakan secara diam-diam.

Setiap penggunaan idealnya meninggalkan jejak yang mudah ditelusuri kembali.

Keamanan Tidak Berhenti setelah Login Berhasil

Break-glass account mungkin memiliki akses ke berbagai konfigurasi kritis.

Karena itu, perangkat dan session yang digunakan juga perlu dikendalikan.

Menggunakan akun tersebut dari laptop pribadi atau perangkat yang tidak dikelola dapat meningkatkan risiko.

Perusahaan dapat mempertimbangkan dedicated secure workstation atau Privileged Access Workstation untuk penggunaan privileged identity.

Selain itu, aktivitas setelah login perlu tetap diaudit.

Apa yang diubah?

Role apa yang diberikan?

Policy apa yang dinonaktifkan?

Akun apa yang dibuat?

Apakah logging sempat dihentikan?

Dalam konteks emergency access, authentication hanyalah langkah pertama.

Risiko terbesar justru dapat terjadi setelah authentication berhasil.

Setelah Emergency Selesai, Akses Tidak Boleh Langsung Dilupakan

Sebuah insiden dinyatakan selesai.

Administrator kembali dapat menggunakan akun normal.

Operasional kembali berjalan.

Namun lifecycle break-glass account belum selesai.

Perusahaan masih perlu melakukan post-use review.

Pertanyaan yang perlu diperiksa antara lain:

Apakah credential perlu dirotasi?

Siapa saja yang mengetahui authentication material selama insiden?

Apakah ada konfigurasi sementara yang belum dikembalikan?

Apakah role tertentu masih aktif?

Apakah seluruh aktivitas sudah diaudit?

Apakah prosedur emergency masih sesuai?

Jika satu penggunaan break-glass melibatkan banyak administrator, credential sebaiknya dianggap memiliki exposure yang lebih besar dibandingkan sebelumnya.

Karena itu, post-incident review merupakan bagian penting dari privileged access management.

Penetration Testing Perlu Melihat Jalur Privileged Access Alternatif

Security assessment sering berfokus pada login pengguna biasa, authorization aplikasi, privilege escalation, API, serta infrastructure exposure.

Namun privileged access alternatif juga perlu mendapat perhatian.

Akun yang sengaja dibuat berbeda dari jalur authentication normal dapat menjadi titik penting ketika mengevaluasi security posture perusahaan.

Area yang perlu diperhatikan tidak hanya break-glass account, tetapi juga:

• local administrator;
• service account;
• backup administrator;
• legacy account;
• privileged API key;
• PAM bypass;
• emergency credential.

Pertanyaannya bukan sekadar apakah akun tersebut ada.

Yang lebih penting adalah apakah organisasi mengetahui siapa yang dapat menggunakannya, bagaimana credential diamankan, dan apakah penyalahgunaannya dapat terdeteksi.

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

Dalam sejumlah lingkungan, kontrol keamanan utama sudah cukup baik. Namun jalur akses alternatif yang dibuat untuk kebutuhan operasional justru memiliki governance yang lebih longgar dibandingkan akun administrator reguler.

Kesenjangan seperti ini dapat memberikan attacker jalan yang lebih mudah untuk mempertahankan atau meningkatkan privileged access.

Break-Glass Account yang Aman Harus Sulit Digunakan tanpa Diketahui

Sebelum menganggap mekanisme emergency access sudah aman, perusahaan sebaiknya mampu menjawab sejumlah pertanyaan.

Siapa yang berhak membuka credential?

Dalam kondisi apa akun boleh digunakan?

Apakah authentication tahan terhadap phishing?

Apakah setiap login langsung memicu alert?

Apakah aktivitas masuk ke SIEM?

Apakah akun pernah digunakan di luar kondisi emergency?

Kapan terakhir kali mekanismenya diuji?

Apakah administrator memahami prosedurnya?

Siapa yang melakukan review setelah akun digunakan?

Apa yang terjadi jika credential dianggap terekspos?

Jawaban terhadap pertanyaan tersebut lebih penting daripada sekadar memiliki akun bernama EmergencyAdmin.

Break-glass account yang aman bukan akun yang mudah digunakan ketika darurat. Ia adalah akun yang tetap dapat digunakan ketika seluruh jalur normal gagal, tetapi sangat sulit digunakan tanpa diketahui perusahaan.

Business continuity memang membutuhkan jalur darurat.

Namun jalur tersebut harus diimbangi dengan authentication yang kuat, monitoring, audit, governance, prosedur penggunaan, serta evaluasi berkala.

Tanpa kontrol tersebut, emergency account yang dibuat untuk menyelamatkan operasional justru dapat menjadi privileged access permanen yang menunggu untuk disalahgunakan.

Evaluasi Privileged Access dan Keamanan Sistem Bersama Fourtrezz

Break-glass account hanyalah salah satu contoh bahwa risiko keamanan tidak selalu berasal dari mekanisme yang dirancang dengan buruk. Dalam banyak kasus, risiko justru muncul dari mekanisme yang sah tetapi memiliki privilege terlalu luas atau kontrol yang tidak lagi sesuai dengan kondisi sistem.

Fourtrezz menyediakan layanan Penetration Testing untuk membantu perusahaan mengidentifikasi kerentanan dan mengevaluasi keamanan pada Web Application, Desktop Application, Android, iOS, API, jaringan, dan server. Pengujian tersedia melalui pendekatan Greybox maupun Blackbox dengan laporan terperinci, rekomendasi perbaikan, dan pengujian ulang.

Untuk kebutuhan pembangunan maupun modernisasi sistem, Fourtrezz juga menyediakan layanan IT Development yang mencakup Custom Enterprise Solution, System & API Integration, Legacy System Transformation, dan IT Architecture Design dengan pendekatan Secure by Design.

Pendekatan tersebut membantu perusahaan memastikan kontrol akses, arsitektur sistem, dan keamanan aplikasi tidak hanya berfungsi dalam kondisi normal, tetapi juga tetap terkendali ketika organisasi harus menggunakan jalur darurat.

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