Seorang pegawai yang berpindah divisi biasanya akan mengalami penyesuaian hak akses. Ketika keluar dari perusahaan, akunnya dinonaktifkan. Aktivitasnya juga dapat ditelusuri melalui identitas pribadi yang digunakan.

Namun, service account yang dibuat beberapa tahun lalu dapat terus bekerja tanpa perhatian serupa. Tidak selalu ada pihak yang mengetahui siapa pemiliknya, mengapa aksesnya masih diperlukan, atau sistem apa saja yang dapat dijangkaunya.

Service account memang tidak memiliki manusia yang duduk di belakang layar. Meski demikian, akun tersebut dapat membaca database, mengambil dokumen, menjalankan deployment, mengubah konfigurasi, dan berkomunikasi dengan sistem lain.

Karena itu, service account bukan sekadar kredensial teknis. Ia merupakan pengguna tanpa manusia yang tetap memiliki identitas, hak akses, dan kemampuan untuk melakukan tindakan di dalam sistem.

Tidak Ada yang Login, tetapi Sistem Tetap Memberikan Akses

Aplikasi modern menjalankan banyak proses tanpa interaksi langsung dari pengguna. Microservice memanggil microservice lain, pipeline melakukan deployment, aplikasi mengambil data dari storage, dan background job memproses transaksi secara otomatis.

Seluruh aktivitas tersebut tetap membutuhkan identitas.

Sistem tujuan perlu mengetahui pihak yang melakukan permintaan dan tindakan yang diizinkan. Service account kemudian digunakan untuk mewakili aplikasi, workload, script, API, atau proses otomatis.

Google Cloud dan Microsoft mengategorikan service account sebagai identitas non manusia. Artinya, akun tersebut perlu diperlakukan sebagai bagian dari identity and access management, bukan hanya sebagai konfigurasi agar aplikasi dapat berjalan.

Tidak adanya pengguna yang login bukan berarti tidak ada identitas yang sedang bekerja. Identitasnya hanya berpindah dari manusia kepada mesin.

Service Account Menjadi Berisiko ketika Dianggap Sekadar Kredensial

Dalam proses development, service account sering dibuat karena aplikasi perlu segera terhubung dengan sistem lain. Tim menghasilkan client secret, certificate, API key, atau file kredensial, kemudian memasukkannya ke dalam konfigurasi.

Selama integrasi berhasil, pekerjaan dianggap selesai.

Pendekatan tersebut mengabaikan dua sisi penting dari service account. Pertama, service account merupakan identitas yang dapat diberikan izin. Kedua, service account merupakan aset yang dapat dicuri, digunakan, atau ditiru oleh pihak lain.

Apabila kredensialnya bocor, penyerang tidak hanya memperoleh rangkaian karakter rahasia. Penyerang memperoleh seluruh kewenangan yang melekat pada akun tersebut.

Service account yang memiliki akses ke storage sensitif memiliki nilai yang hampir sama dengan data di dalam storage. Akun yang dapat melakukan deployment juga bernilai setara dengan akses terhadap lingkungan production.

Dengan kata lain, semakin besar kegunaan sebuah service account, semakin menarik pula identitas tersebut sebagai target serangan.

Hak Akses Mesin Dibentuk oleh Arsitektur Aplikasi

Batas akses service account berkaitan erat dengan cara aplikasi dirancang.

Aplikasi monolitik mungkin menggunakan satu identitas untuk mengakses database, storage, email, dan API eksternal. Dalam arsitektur microservices, setiap service dapat memiliki kebutuhan yang berbeda.

Service untuk laporan hanya perlu membaca data tertentu. Service pembayaran membutuhkan akses ke transaksi. Background job mungkin hanya perlu memproses antrean. Pipeline deployment memerlukan izin terhadap infrastruktur.

Jika seluruh komponen menggunakan satu service account, identitas tersebut harus mengumpulkan gabungan izin dari semua kebutuhan. Akibatnya, kompromi terhadap satu komponen dapat membuka akses ke sumber daya lain yang tidak berkaitan.

Masalah ini tidak dapat diselesaikan hanya dengan mengganti password atau merotasi key. Akar persoalannya terletak pada batas tanggung jawab yang tidak dirancang dengan jelas.

Batas hak akses mesin tidak dapat lebih baik daripada batas fungsi yang dibentuk oleh arsitektur aplikasi.

Satu Service Account untuk Banyak Layanan Menghapus Akuntabilitas

Menggunakan satu service account untuk beberapa aplikasi dapat terlihat lebih sederhana. Tim hanya perlu mengelola satu kredensial dan satu konfigurasi akses.

Kemudahan tersebut memiliki konsekuensi besar.

Ketika beberapa aplikasi menggunakan identitas yang sama, semuanya mewarisi izin yang sama. Jika satu aplikasi disusupi, penyerang dapat menggunakan service account tersebut untuk menjangkau sumber daya yang sebenarnya diperuntukkan bagi aplikasi lain.

Aktivitas juga menjadi lebih sulit ditelusuri. Log hanya menunjukkan nama service account tanpa menjelaskan workload mana yang menjalankan tindakan.

Rotasi kredensial pun menjadi rumit karena perubahan dapat mengganggu banyak sistem sekaligus. Akibatnya, perusahaan cenderung menunda rotasi atau mempertahankan kredensial lebih lama daripada yang seharusnya.

Setiap aplikasi atau fungsi dengan kebutuhan akses berbeda sebaiknya menggunakan identitas yang terpisah. Pemisahan ini membatasi dampak serangan dan meningkatkan kemampuan investigasi.

Izin Bertambah Seiring Aplikasi Berkembang

Pada awal pengembangan, sebuah service account mungkin hanya membutuhkan akses membaca database. Setelah fitur baru ditambahkan, akun tersebut memperoleh izin menulis. Integrasi berikutnya menambah akses ke storage, email, atau sistem eksternal.

Izin terus bertambah agar aplikasi dapat menjalankan fungsi baru. Namun, izin lama jarang dievaluasi kembali.

Kondisi ini disebut sebagai akumulasi hak akses. Service account perlahan memiliki kewenangan yang lebih luas daripada tujuan awalnya.

Panduan resmi penyedia cloud juga menyoroti kecenderungan tersebut. Ketika fungsi aplikasi bertambah, service account sering menerima semakin banyak akses. Pada saat yang sama, izin yang tidak lagi digunakan dapat terlupakan.

Masalah biasanya tidak langsung terlihat karena semua permintaan tetap menggunakan kredensial yang sah. Sistem tidak menganggapnya sebagai serangan meskipun akun tersebut sebenarnya memiliki kewenangan berlebihan.

Least Privilege Harus Dimulai dari Kebutuhan Aplikasi

Penerapan least privilege tidak cukup dilakukan dengan memilih role yang terdengar paling mendekati kebutuhan.

Role umum seperti Editor, Contributor, atau Administrator memang mempercepat deployment. Namun, role tersebut dapat memberikan banyak permission yang tidak pernah digunakan aplikasi.

Perancangan hak akses sebaiknya dimulai dari beberapa pertanyaan:

• Tindakan apa yang harus dilakukan aplikasi?
• Sumber daya mana yang benar-benar diperlukan?
• Apakah aplikasi hanya membaca atau juga mengubah data?
• Apakah akses dibutuhkan terus-menerus?
• Lingkungan mana yang boleh dijangkau?
• Apakah satu fungsi membutuhkan identitas terpisah?
• Apa dampaknya jika service account diambil alih?

Jawaban atas pertanyaan tersebut harus diterjemahkan menjadi permission yang spesifik.

Aplikasi yang hanya membaca satu storage bucket tidak memerlukan akses ke seluruh proyek. Background job yang memperbarui satu tabel tidak harus menjadi administrator database. Pipeline yang melakukan deployment pada satu layanan tidak perlu mengendalikan seluruh infrastruktur.

Least privilege bukan tentang memberikan izin sekecil mungkin tanpa mempertimbangkan fungsi. Tujuannya adalah memberikan akses yang tepat, pada sumber daya yang tepat, selama benar-benar diperlukan.

Development dan Production Tidak Boleh Menggunakan Identitas yang Sama

Service account yang sama kadang digunakan pada development, staging, dan production untuk mempermudah konfigurasi.

Praktik tersebut dapat menghubungkan lingkungan yang seharusnya dipisahkan.

Development biasanya digunakan oleh lebih banyak pengembang, tools, dan proses eksperimen. Kode belum stabil dan konfigurasi lebih sering berubah. Jika identitas development juga memiliki akses ke production, kompromi pada lingkungan yang lebih terbuka dapat menjadi jalur menuju aset penting.

Setiap lingkungan perlu mempunyai:

• service account terpisah;
• kredensial berbeda;
• resource scope berbeda;
• permission sesuai kebutuhan;
• logging terpisah;
• proses persetujuan berdasarkan tingkat risiko.

Pemisahan ini juga membantu mencegah kesalahan operasional. Script yang seharusnya dijalankan pada data pengujian tidak dapat secara tidak sengaja mengubah data production.

Kredensial Statis Dapat Menjadi Password Permanen Mesin

Client secret, API key, certificate, dan file kredensial sering memiliki masa berlaku panjang. Selama belum dicabut, siapa pun yang memilikinya dapat bertindak sebagai service account.

Kredensial tersebut dapat bocor melalui berbagai tempat:

• source code repository;
• file konfigurasi;
• environment variable;
• log aplikasi;
• container image;
• artefak build;
• backup;
• workstation pengembang;
• pesan internal;
• pipeline CI/CD.

Risiko bertambah ketika kredensial yang sama digunakan oleh banyak sistem. Perusahaan mungkin tidak mengetahui seluruh lokasi penyimpanannya sehingga proses rotasi tidak benar-benar menghilangkan salinan lama.

Kredensial berumur panjang juga mempersulit atribusi. Log dapat menunjukkan bahwa service account melakukan perubahan, tetapi belum tentu dapat menjelaskan siapa yang menggunakan key tersebut.

Karena itu, service account key sebaiknya digunakan hanya ketika tidak tersedia mekanisme autentikasi yang lebih aman.

Managed Identity Mengurangi Ketergantungan pada Secret

Managed identity dan workload identity dapat mengurangi kebutuhan menyimpan kredensial statis di dalam aplikasi.

Dengan mekanisme tersebut, identitas dikaitkan dengan workload atau resource tertentu. Platform dapat mengelola penerbitan dan rotasi token tanpa memberikan secret permanen kepada pengembang.

Beberapa pendekatan yang dapat digunakan meliputi:

• managed identity;
• workload identity;
• workload identity federation;
• service account impersonation;
• short-lived token;
• certificate yang dikelola otomatis.

Microsoft merekomendasikan managed identity ketika tersedia karena kredensial dapat dikelola dan dirotasi oleh platform. Pada identitas yang terikat langsung dengan resource, lifecycle identitas juga dapat mengikuti lifecycle resource tersebut.

Namun, managed identity bukan solusi otomatis untuk seluruh persoalan keamanan service account. Jika identitas tetap diberikan role yang terlalu luas, dampak kompromi tidak banyak berubah.

Metode autentikasi yang aman harus disertai desain otorisasi yang tepat.

CI/CD Pipeline Dapat Menjadi Jalur Tidak Langsung

Service account dengan hak istimewa sering digunakan oleh CI/CD pipeline untuk membangun aplikasi, mengunggah artefak, dan melakukan deployment.

Dalam kondisi ini, akses ke pipeline dapat menjadi akses tidak langsung terhadap service account.

Seorang pengguna mungkin tidak memiliki izin untuk mengubah production. Namun, jika ia dapat memodifikasi script pipeline yang menggunakan service account production, pengguna tersebut berpotensi menjalankan tindakan melalui identitas pipeline.

Jalur serangannya dapat berlangsung sebagai berikut:

1. Penyerang memperoleh akses ke repository atau sistem CI/CD.
2. Konfigurasi pipeline dimodifikasi.
3. Pipeline menjalankan kode yang telah diubah.
4. Kode menggunakan identitas yang melekat pada runner.
5. Service account mengakses resource production.

Setiap tindakan tetap terlihat sah karena menggunakan kredensial resmi.

Oleh sebab itu, keamanan service account tidak dapat dipisahkan dari keamanan repository, runner, build script, approval, artefak, dan proses deployment.

Impersonation Dapat Membuka Privilege Escalation

Service account dapat digunakan melalui mekanisme impersonation. Pengguna atau aplikasi memperoleh token sementara untuk bertindak sebagai identitas tersebut.

Jika dirancang dengan benar, mekanisme ini lebih aman daripada membagikan key permanen. Aktivitas pengguna yang melakukan impersonation juga dapat dicatat.

Namun, izin impersonation tetap harus dibatasi.

Jika pengguna dengan hak rendah dapat meniru service account yang lebih istimewa, ia memperoleh kewenangan akun tersebut. Penyerang juga dapat berpindah dari satu service account ke identitas lain apabila terdapat rantai permission yang tidak dirancang dengan baik.

MITRE ATT&CK menempatkan penyalahgunaan akun cloud yang sah sebagai teknik yang dapat mendukung akses awal, persistence, privilege escalation, dan defense evasion.

Hal tersebut menunjukkan bahwa kredensial sah tidak selalu menandakan tindakan yang sah. Sistem perlu memahami pihak yang memperoleh token, tujuan penggunaannya, dan resource yang diakses.

Service Account Tanpa Pemilik Akan Menjadi Identitas Terlupakan

Service account sering memiliki lifecycle lebih panjang daripada aplikasi atau tim yang membuatnya.

Identitas dapat tertinggal ketika:

• aplikasi dihentikan;
• vendor tidak lagi digunakan;
• pipeline diganti;
• proyek migrasi selesai;
• pengembang berpindah tim;
• resource utama telah dihapus;
• dokumentasi tidak diperbarui.

Akun yang tidak lagi digunakan belum tentu kehilangan permission. Key dan tokennya juga mungkin masih berlaku.

Setiap service account perlu memiliki informasi minimum berupa:

• pemilik teknis;
• pemilik bisnis;
• tujuan penggunaan;
• aplikasi atau workload terkait;
• lingkungan;
• permission yang diberikan;
• metode autentikasi;
• tanggal evaluasi;
• masa berlaku;
• prosedur penghentian.

Microsoft juga menekankan pentingnya mencatat pemilik, tujuan, scope, permission, durasi, penggunaan, serta proses deprovisioning service account.

Tanpa data tersebut, organisasi akan kesulitan menentukan apakah suatu akun masih diperlukan atau aman untuk dihapus.

Audit Log Harus Menunjukkan Mesin dan Proses yang Bertindak

Log yang hanya menampilkan nama service account belum tentu memberikan akuntabilitas yang memadai.

Apabila satu identitas digunakan oleh banyak workload, tim keamanan tidak dapat langsung mengetahui aplikasi mana yang melakukan tindakan tertentu.

Audit trail yang baik perlu menghubungkan:

• service account yang digunakan;
• workload yang menjalankan tindakan;
• pengguna atau pipeline yang memicu proses;
• versi aplikasi;
• resource yang diakses;
• permission yang digunakan;
• waktu dan asal akses;
• perubahan yang dilakukan;
• hasil tindakan.

Informasi tersebut membantu perusahaan membedakan aktivitas normal, kesalahan aplikasi, penyalahgunaan internal, dan kompromi kredensial.

Monitoring juga perlu mencari perubahan pola. Service account yang biasanya hanya membaca data tetapi tiba-tiba melakukan penghapusan harus menghasilkan alert, meskipun tindakan tersebut secara teknis diizinkan.

Hak Akses Mesin Harus Menjadi Security Requirement

Persoalan service account sering diserahkan kepada tim infrastruktur setelah aplikasi hampir selesai. Pada tahap tersebut, arsitektur dan pola integrasi sudah terbentuk sehingga pembatasan akses menjadi lebih sulit.

Hak akses mesin seharusnya dirancang sejak development.

Security requirement untuk service account dapat mencakup:

• identitas yang digunakan setiap komponen;
• resource yang boleh diakses;
• operasi yang diizinkan;
• pemisahan antar lingkungan;
• larangan hard-coded secret;
• metode penyimpanan kredensial;
• masa berlaku token;
• prosedur rotasi;
• kebutuhan logging;
• pemilik identitas;
• proses decommissioning.

Pengembang perlu terlibat karena mereka memahami API yang dipanggil, data yang digunakan, dan tindakan yang dilakukan aplikasi.

IAM bukan hanya pekerjaan administratif. Keputusan mengenai hak akses merupakan bagian dari desain keamanan aplikasi.

Security Review Harus Mengikuti Perubahan Fitur

Hak akses service account tidak dapat ditentukan sekali lalu dibiarkan tanpa evaluasi.

Setiap perubahan fitur dapat menambah atau mengurangi kebutuhan akses. Fitur ekspor mungkin memerlukan storage baru. Integrasi vendor dapat membutuhkan API eksternal. Background job baru dapat mengubah kebutuhan database.

Security review perlu dilakukan ketika:

• service baru ditambahkan;
• aplikasi mengakses jenis data baru;
• izin read berubah menjadi write;
• pipeline deployment dimodifikasi;
• integrasi pihak ketiga digunakan;
• workload dipindahkan ke cloud;
• mekanisme impersonation ditambahkan;
• sistem lama dihentikan.

Review tidak hanya memastikan izin baru sesuai kebutuhan. Tim juga perlu menghapus permission yang sudah tidak digunakan.

Penetration Testing Perlu Memeriksa Jalur Penyalahgunaan Identitas Mesin

Pengujian keamanan service account tidak cukup hanya dengan mencari secret yang terekspos.

Penetration testing juga perlu menilai apakah identitas tersebut dapat digunakan untuk privilege escalation, impersonation, atau lateral movement.

Beberapa skenario yang perlu diperiksa meliputi:

• service account dengan izin berlebihan;
• kredensial yang dapat diambil dari aplikasi;
• token yang dapat digunakan kembali;
• akses lintas lingkungan;
• kemampuan melakukan impersonation;
• jalur dari CI/CD menuju production;
• akses lintas proyek atau tenant;
• pemisahan identitas antarservice;
• akun lama yang masih aktif;
• kemampuan audit log mengidentifikasi sumber tindakan;
• dampak kompromi satu workload terhadap resource lain.

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

Aplikasi mungkin telah menggunakan autentikasi yang kuat untuk pengguna manusia. Namun, akses antarsistem masih bergantung pada service account bersama, key berumur panjang, atau role yang terlalu luas.

Kondisi tersebut memungkinkan penyerang bergerak menggunakan kredensial sah setelah berhasil menguasai satu bagian aplikasi.

Mesin Tidak Membutuhkan Nama Manusia untuk Menjadi Pengguna Istimewa

Service account tidak dapat mengundurkan diri atau meminta penambahan hak akses. Namun, aplikasi yang menggunakannya terus berubah.

Tanpa pemilik dan evaluasi berkala, identitas mesin dapat mengumpulkan kewenangan jauh melampaui tujuan awalnya. Kredensialnya dapat tersebar, sedangkan aktivitasnya sulit dibedakan dari proses normal.

Karena itu, keamanan service account harus dirancang sejak development. Setiap identitas perlu memiliki tujuan, batas akses, metode autentikasi yang aman, audit trail, dan akhir lifecycle yang jelas.

Service account memang tidak memiliki manusia. Namun, dampak dari tindakannya tetap harus dapat dipertanggungjawabkan.

Evaluasi Keamanan Service Account Bersama Fourtrezz

Fourtrezz membantu perusahaan mengidentifikasi celah keamanan melalui layanan Vulnerability Assessment serta Penetration Testing Blackbox dan Greybox.

Pengujian dapat dilakukan terhadap web application, desktop application, aplikasi Android dan iOS, API, jaringan, serta server. Evaluasi dapat mencakup keamanan autentikasi, otorisasi, service account, API, kredensial, konfigurasi, dan jalur privilege escalation sesuai ruang lingkup sistem.

Hasil pengujian disertai laporan terperinci, rekomendasi perbaikan, konsultasi, dan pengujian ulang sesuai ruang lingkup layanan.

Hubungi Fourtrezz untuk mendiskusikan kebutuhan dan menentukan scope pengujian keamanan yang sesuai dengan aplikasi serta infrastruktur perusahaan Anda.

Hubungi Fourtrezz:

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