Ketika membicarakan keamanan identitas, perhatian perusahaan biasanya langsung tertuju pada pengguna. Siapa yang boleh masuk ke sistem, siapa yang memiliki hak administrator, apakah multi-factor authentication sudah diterapkan, dan apakah akses karyawan yang mengundurkan diri telah dicabut.

Masalahnya, sistem digital modern tidak hanya digunakan oleh manusia.

Di balik satu aplikasi bisnis dapat terdapat banyak identitas lain yang bekerja tanpa pernah membuka halaman login. Backend harus mengakses database. Microservice perlu berkomunikasi dengan API lain. Pipeline CI/CD harus mengirim aplikasi ke production. Scheduled job mengambil data secara otomatis. Sistem monitoring membaca informasi dari berbagai server.

Semua aktivitas tersebut membutuhkan identitas.

Service account, API key, application identity, service principal, workload identity, token, hingga berbagai bentuk non-human identity kini menjadi bagian yang tidak terpisahkan dari arsitektur aplikasi.

Persoalannya bukan sekadar jumlahnya semakin banyak. Identitas mesin juga dapat memiliki akses yang sangat luas, bekerja selama 24 jam, dan bertahan jauh lebih lama dibandingkan akun pengguna biasa.

Inilah sebabnya risiko identitas dalam pengembangan sistem mulai bergeser.

Kita Terlalu Lama Menganggap Identitas Selalu Berarti Manusia

Sistem Identity and Access Management selama bertahun-tahun banyak dibangun dengan pola pikir yang berpusat pada manusia.

Ketika seorang karyawan bergabung, perusahaan membuat akun.

Ketika berpindah divisi, hak akses diperbarui.

Ketika meninggalkan perusahaan, akun seharusnya dinonaktifkan.

Kontrol tambahan seperti password policy, multi-factor authentication, Single Sign-On, dan review akses berkala kemudian digunakan untuk mengurangi risiko.

Namun, mekanisme yang sama tidak selalu dapat diterapkan secara langsung kepada identitas mesin.

Sebuah backend service tidak dapat memasukkan OTP setiap kali membutuhkan koneksi ke database. Pipeline deployment juga tidak dapat menunggu seseorang melakukan autentikasi manual setiap kali proses otomatis berjalan.

Karena itu, sistem membutuhkan mekanisme autentikasi lain.

Di sinilah service account dan machine identity mengambil peran.

Masalah keamanan mulai muncul ketika perusahaan memiliki tata kelola yang sangat ketat terhadap pengguna manusia, tetapi tidak memiliki visibilitas yang sama terhadap identitas yang digunakan oleh aplikasi dan proses otomatis.

Service Account Bukan Teknologi Baru, tetapi Skala Penggunaannya Telah Berubah

Service account sebenarnya bukan konsep baru.

Sistem telah lama menggunakan akun khusus untuk menjalankan aplikasi, mengakses database, melakukan backup, menjalankan scheduler, atau menghubungkan layanan.

Yang berubah adalah arsitektur sistemnya.

Dahulu sebuah aplikasi mungkin berbentuk satu sistem monolitik dengan beberapa komponen utama. Sekarang satu layanan digital dapat terdiri dari puluhan microservices, container, API, cloud resource, serverless function, automation script, dan pipeline deployment.

Setiap komponen dapat membutuhkan identitasnya sendiri.

Semakin banyak layanan saling berkomunikasi, semakin banyak pula hubungan kepercayaan yang harus dibangun.

Pertumbuhan cloud computing, API integration, DevOps, containerization, Infrastructure as Code, serta otomatisasi membuat machine identity berkembang menjadi bagian penting dari lingkungan perusahaan.

Kehadiran AI agent bahkan menambah lapisan baru. Sistem otomatis tidak lagi sekadar menjalankan instruksi sederhana, tetapi mulai diberikan kemampuan untuk mengakses aplikasi, mencari informasi, menjalankan workflow, hingga mengambil tindakan melalui API.

Akibatnya, keamanan identitas tidak lagi cukup menjawab pertanyaan:

“Siapa yang memiliki akses?”

Perusahaan juga perlu mengetahui:

“Aplikasi, service, atau mesin apa yang memiliki akses?”

Masalah Terbesarnya Bukan Credential, tetapi Kewenangan di Baliknya

Kebocoran sebuah API key sering dianggap sebagai persoalan credential.

Padahal dampaknya sangat bergantung pada apa yang dapat dilakukan oleh identitas di balik credential tersebut.

Bayangkan dua service account.

Service account pertama hanya memiliki izin membaca satu folder tertentu.

Service account kedua dapat membaca database production, mengubah cloud storage, menjalankan deployment, dan mengakses beberapa sistem internal.

Jika credential keduanya bocor, tingkat risikonya jelas berbeda.

Karena itu, service account security tidak seharusnya berhenti pada pertanyaan apakah password, token, atau key sudah disimpan dengan aman.

Perusahaan juga harus memahami blast radius dari identitas tersebut.

Apa yang dapat dibaca?

Apa yang dapat diubah?

Sistem mana yang dapat diakses?

Bisakah identitas tersebut membuat credential baru?

Apakah akses dapat digunakan untuk berpindah menuju sistem lain?

Dalam banyak kasus, sebuah credential terlihat kecil karena hanya berupa rangkaian karakter. Namun, di balik rangkaian karakter itu dapat terdapat izin yang setara dengan administrator.

Hak Akses yang Membesar Sedikit demi Sedikit

Salah satu masalah klasik dalam service account adalah permission accumulation.

Ketika sebuah aplikasi pertama kali dikembangkan, developer mungkin memberikan beberapa hak akses dasar.

Misalnya:

Aplikasi hanya membutuhkan akses membaca cloud storage.

Beberapa bulan kemudian muncul fitur baru yang membutuhkan kemampuan menulis data.

Permission ditambahkan.

Kemudian aplikasi perlu berkomunikasi dengan database.

Permission kembali ditambahkan.

Setelah itu dibutuhkan integrasi dengan sistem lain.

Hak akses kembali diperluas.

Masalahnya, permission lama hampir tidak pernah diperiksa kembali.

Pada akhirnya, service account yang awalnya dibuat untuk satu fungsi sederhana dapat memiliki akses yang jauh lebih luas dibandingkan kebutuhan aktualnya.

Prinsip least privilege terdengar sederhana secara teori. Dalam lingkungan production yang terus berkembang, penerapannya jauh lebih sulit.

Tim development biasanya memiliki motivasi kuat untuk memastikan aplikasi terus berjalan. Ketika terjadi kegagalan akibat masalah permission, solusi tercepat sering kali adalah memberikan akses tambahan.

Aplikasi kembali bekerja.

Tiket ditutup.

Permission yang terlalu luas kemudian bertahan selama bertahun-tahun.

Service Account Sering Tidak Memiliki Pemilik yang Jelas

Akun pengguna memiliki satu keunggulan: biasanya terdapat manusia yang dapat dimintai pertanggungjawaban.

Nama akun dapat dikaitkan dengan karyawan, divisi, jabatan, dan atasan.

Service account tidak selalu demikian.

Nama seperti:

svc-production

api-integration

backend-system

deployment-user

mungkin terlihat jelas saat pertama kali dibuat.

Namun tiga tahun kemudian situasinya bisa berubah.

Developer yang membuat account tersebut sudah tidak bekerja di perusahaan.

Aplikasi telah mengalami beberapa kali migrasi.

Tim berganti.

Dokumentasi tidak diperbarui.

Tidak ada seorang pun yang benar-benar yakin apakah account tersebut masih digunakan.

Karena khawatir menyebabkan gangguan, account akhirnya dibiarkan aktif.

Situasi seperti ini dapat melahirkan orphaned identity, yaitu identitas yang masih ada dan mungkin masih memiliki akses, tetapi tidak lagi memiliki ownership atau kebutuhan bisnis yang jelas.

Akun manusia biasanya mengikuti pola:

Join → Change → Leave

Machine identity sering kali mengikuti pola yang berbeda:

Create → Use → Forget

Ketika jumlahnya masih puluhan, masalah tersebut mungkin dapat dikelola secara manual.

Ketika jumlahnya menjadi ribuan, pendekatan yang sama mulai kehilangan efektivitas.

Credential Berumur Panjang Membuat Kebocoran Bertahan Lebih Lama

Service account sering bergantung pada password, secret, API key, private key, certificate, atau token.

Semua credential tersebut perlu berada di suatu tempat agar aplikasi dapat menggunakannya.

Di sinilah risiko berikutnya muncul.

Credential dapat tersimpan dalam configuration file, environment variable, CI/CD platform, developer workstation, container image, source code repository, secret manager, atau bahkan dokumentasi internal.

Semakin sering credential berpindah, semakin besar pula kemungkinan terjadinya eksposur.

Masalah menjadi lebih serius ketika organisasi menggunakan static credential dengan masa berlaku sangat panjang.

Sebuah secret yang bocor tetapi hanya berlaku beberapa menit memiliki karakter risiko yang berbeda dibandingkan credential yang masih valid selama bertahun-tahun.

Sayangnya, credential service account sering sulit dirotasi.

Tim development khawatir perubahan credential menyebabkan aplikasi gagal terhubung.

Tidak jarang sebuah credential akhirnya dipertahankan hanya karena tidak ada seorang pun yang yakin apa yang akan terjadi apabila credential tersebut diganti.

Pada kondisi ini, technical dependency berubah menjadi security risk.

CI/CD Dapat Memiliki Kekuasaan Lebih Besar daripada Developer

Pipeline CI/CD merupakan contoh menarik mengenai perubahan model identitas dalam pengembangan sistem modern.

Banyak perusahaan telah membatasi developer agar tidak memiliki akses langsung ke production.

Secara prinsip, keputusan tersebut tepat.

Developer membuat perubahan melalui repository. Perubahan melalui review. Pipeline kemudian melakukan build, testing, dan deployment secara otomatis.

Namun muncul pertanyaan lain:

Identitas apa yang digunakan pipeline tersebut?

Pipeline mungkin membutuhkan kemampuan untuk:

• membaca source code;
• mengambil dependency;
• membuat artifact;
• mengirim container image;
• mengakses cloud environment;
• mengubah konfigurasi;
• serta melakukan deployment ke production.

Dengan kata lain, developer mungkin tidak memiliki hak deployment secara langsung, tetapi machine identity di dalam pipeline memilikinya.

Jika credential pipeline memiliki permission terlalu luas atau berhasil dikompromikan, kontrol yang membatasi developer tidak lagi memberikan perlindungan yang sama.

Inilah contoh mengapa keamanan service account perlu dipandang sebagai bagian dari application security dan DevSecOps, bukan sekadar pekerjaan administratif IAM.

Menggunakan Satu Service Account untuk Banyak Sistem Memang Praktis, tetapi Mahal Saat Terjadi Insiden

Dalam pengembangan aplikasi, efisiensi sering menjadi pertimbangan utama.

Membuat satu service account kemudian menggunakannya pada beberapa aplikasi memang lebih mudah daripada membuat dan mengelola banyak identitas berbeda.

Namun efisiensi tersebut memiliki konsekuensi keamanan.

Bayangkan satu credential digunakan oleh:

• aplikasi backend;
• sistem reporting;
• scheduler;
• data processing;
• dan aplikasi integrasi.

Ketika credential tersebut bocor, attacker tidak hanya memperoleh akses terhadap satu aplikasi.

Ia berpotensi memperoleh jalur menuju seluruh sistem yang menggunakan identitas yang sama.

Selain memperbesar blast radius, penggunaan credential bersama juga mempersulit investigasi.

Ketika aktivitas mencurigakan muncul dalam audit log, perusahaan harus menentukan sistem mana yang sebenarnya menggunakan credential tersebut.

Apabila lima aplikasi memakai identitas yang sama, jejak aktivitas menjadi lebih sulit dipisahkan.

Karena itu, pemisahan identitas bukan sekadar persoalan kerapian arsitektur. Pemisahan tersebut berpengaruh langsung terhadap kemampuan perusahaan membatasi dampak dan melakukan investigasi ketika terjadi insiden.

MFA Tidak Menyelesaikan Masalah Identitas yang Tidak Pernah Login Seperti Manusia

Multi-factor authentication telah menjadi salah satu kontrol penting untuk melindungi akun pengguna.

Namun machine identity memiliki karakteristik berbeda.

Backend tidak membuka aplikasi authenticator.

Container tidak memasukkan OTP.

Scheduled task tidak melakukan verifikasi biometrik sebelum menjalankan proses.

Karena itu, organisasi tidak dapat hanya mengambil strategi keamanan akun manusia kemudian menerapkannya kepada workload identity.

Kontrolnya harus berbeda.

Beberapa pendekatan yang semakin penting antara lain penggunaan managed identity, workload identity, short-lived credential, credential federation, pembatasan permission, secret management, serta monitoring terhadap penggunaan identitas.

Prinsip dasarnya sederhana:

Jika aplikasi dapat membuktikan identitasnya tanpa menyimpan static credential, maka jumlah secret yang harus dijaga dapat dikurangi.

Perubahan ini penting karena salah satu cara terbaik melindungi secret adalah tidak menciptakan secret jangka panjang apabila memang tidak diperlukan.

Risiko Service Account Baru Terlihat ketika Jalur Serangannya Diuji

Daftar service account dan permission dapat terlihat rapi dalam dokumentasi.

Namun kondisi sebenarnya baru terlihat ketika hubungan antaridentitas dianalisis sebagai bagian dari attack path.

Misalnya, attacker menemukan satu credential dari aplikasi dengan tingkat kepentingan rendah.

Credential tersebut ternyata dapat membaca repository tertentu.

Repository berisi konfigurasi deployment.

Konfigurasi tersebut mengarah kepada credential lain.

Credential berikutnya memiliki akses terhadap environment production.

Dalam situasi seperti ini, masalah sebenarnya bukan hanya satu secret yang bocor.

Masalahnya adalah hubungan antara identitas, permission, dan resource telah membentuk jalur serangan.

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

Temuan yang terlihat sederhana pada permukaan dapat memiliki dampak yang jauh lebih besar ketika penguji mengikuti akses tersebut menuju sistem lain.

Itulah sebabnya penetration testing tidak seharusnya hanya berfokus mencari vulnerability pada halaman aplikasi.

Authorization, credential exposure, service account, API access, cloud configuration, dan hubungan antar-sistem juga perlu diperhatikan sesuai dengan ruang lingkup pengujian.

Inventaris Aset Saja Tidak Cukup, Perusahaan Juga Membutuhkan Inventaris Identitas

Sebagian besar perusahaan telah memahami pentingnya mengetahui server, endpoint, aplikasi, database, dan cloud resource yang mereka miliki.

Namun inventaris machine identity sering belum mendapat perhatian yang sama.

Perusahaan seharusnya mampu menjawab beberapa pertanyaan sederhana:

Berapa banyak service account yang aktif?

Aplikasi apa yang menggunakan setiap account?

Siapa pemiliknya?

Permission apa yang diberikan?

Kapan terakhir digunakan?

Jenis credential apa yang digunakan?

Kapan credential terakhir dirotasi?

Apakah identitas tersebut masih dibutuhkan?

Apa yang terjadi jika credential-nya berhasil dicuri?

Apakah account tersebut dapat mengakses sistem lain?

Pertanyaan tersebut terlihat mendasar, tetapi jawabannya dapat menjadi sangat kompleks pada sistem yang telah berkembang bertahun-tahun.

Karena itu, service account lifecycle management harus mulai diperlakukan dengan disiplin yang sama seperti user lifecycle management.

Pengembangan Sistem Modern Membutuhkan Security untuk Manusia dan Mesin

Pergeseran menuju cloud, API, microservices, automation, CI/CD, dan AI membuat batas antara pengguna dan mesin semakin tidak relevan dari perspektif keamanan.

Sistem tidak peduli apakah permintaan berasal dari manusia atau aplikasi.

Sistem hanya melihat identitas, credential, dan permission yang diberikan.

Karena itu, perusahaan perlu melihat identity security secara lebih luas.

Jangan hanya menanyakan siapa administrator aplikasi.

Periksa pula aplikasi mana yang dapat bertindak seperti administrator.

Jangan hanya mengevaluasi password pengguna.

Periksa pula API key dan token yang mungkin telah digunakan selama bertahun-tahun.

Jangan hanya menonaktifkan akun karyawan yang keluar.

Periksa pula service account dari sistem yang sudah tidak digunakan.

Dan jangan hanya mengamankan halaman login.

Perhatikan bagaimana backend, API, pipeline, container, dan berbagai workload lainnya membuktikan identitas ketika berkomunikasi satu sama lain.

Semakin banyak keputusan dan proses yang diserahkan kepada software, semakin penting pula memastikan setiap identitas mesin memiliki kewenangan yang jelas, terbatas, dapat diawasi, dan dapat dicabut.

Pada akhirnya, pertanyaan keamanan identitas tidak lagi cukup berhenti pada:

“Siapa yang dapat masuk ke sistem?”

Pertanyaan yang lebih relevan untuk pengembangan sistem modern adalah:

“Identitas apa saja yang dapat bertindak di dalam sistem, seberapa besar kewenangannya, dan apa yang terjadi jika salah satunya jatuh ke tangan yang salah?”

Uji Risiko Identitas dan Keamanan Sistem Bersama Fourtrezz

Service account dengan privilege berlebihan, credential yang tidak terkelola, kelemahan authorization, hingga hubungan akses antar-sistem dapat menciptakan jalur serangan yang tidak selalu terlihat dari pemeriksaan konfigurasi biasa.

Fourtrezz dapat membantu perusahaan mengevaluasi keamanan sistem digital melalui layanan cybersecurity seperti Penetration Testing, Vulnerability Assessment, Red Teaming, konsultasi keamanan, serta pendekatan IT Development berbasis cybersecurity.

Melalui pengujian yang terarah, perusahaan dapat memahami bukan hanya vulnerability yang terdapat pada sistem, tetapi juga bagaimana kelemahan tersebut dapat dimanfaatkan dan seberapa jauh dampaknya terhadap aset digital perusahaan.

Jika perusahaan Anda sedang mengembangkan aplikasi, menggunakan API dan cloud environment, atau ingin mengetahui apakah service account dan kontrol akses yang ada dapat menjadi jalur serangan, diskusikan kebutuhan pengujian bersama Fourtrezz.

Hubungi Fourtrezz:

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