Seorang supervisor memiliki kewenangan untuk menyetujui transaksi dalam batas nominal tertentu. Pada layanan pesanan, persetujuan tersebut berhasil diproses. Pada layanan pembayaran, permintaan yang sama justru ditolak. Namun, ketika proses dilakukan melalui endpoint internal, transaksi di atas batas kewenangannya malah dapat disetujui.

Penggunanya sama. Perannya sama. Kebijakan perusahaan juga tidak berubah. Perbedaannya hanya terletak pada microservice yang menerima permintaan.

Situasi semacam ini memperlihatkan persoalan yang sering tersembunyi dalam arsitektur microservices. Sistem telah berhasil dipecah menjadi layanan-layanan yang lebih kecil, tetapi aturan otorisasinya ikut terpecah menjadi banyak versi.

Ketika setiap layanan menafsirkan hak akses secara mandiri, perusahaan tidak lagi mempunyai satu kebijakan otorisasi. Perusahaan memiliki banyak interpretasi atas kebijakan yang seharusnya sama.

Microservices Membagi Sistem, Bukan Kebijakan Perusahaan

Arsitektur microservices memungkinkan aplikasi dikembangkan dan dikelola sebagai sekumpulan layanan yang lebih kecil. Setiap tim dapat mengembangkan, menguji, dan menerapkan perubahan tanpa harus menunggu seluruh aplikasi diperbarui.

Pendekatan ini memberikan fleksibilitas yang sulit diperoleh dari sistem monolitik. Kapasitas layanan dapat ditingkatkan secara terpisah, gangguan lebih mudah diisolasi, dan perubahan pada satu domain tidak selalu memengaruhi bagian lainnya.

Namun, keuntungan tersebut dapat menimbulkan masalah ketika aturan hak akses ikut disimpan secara terpisah pada setiap service.

Sebuah ketentuan bahwa manajer hanya boleh menyetujui transaksi pada cabangnya dapat ditulis ulang pada layanan pesanan, pembayaran, pelaporan, dan notifikasi. Meskipun berasal dari kebijakan yang sama, setiap implementasi dapat menggunakan data, kondisi, dan versi aturan yang berbeda.

Saat kebijakan perusahaan berubah, belum tentu seluruh layanan diperbarui pada waktu yang sama. Satu service mungkin sudah menggunakan aturan baru, sedangkan service lain masih menjalankan kebijakan sebelumnya.

Arsitektur boleh terdistribusi. Namun, sumber kebenaran mengenai siapa yang boleh melakukan tindakan tertentu tetap perlu dikendalikan secara konsisten.

Token yang Valid Tidak Selalu Berarti Akses Diizinkan

Banyak sistem berhenti pada pemeriksaan bahwa pengguna telah berhasil login dan membawa token yang valid. Padahal, token tersebut hanya membantu memastikan identitas pihak yang mengirimkan permintaan.

Keputusan otorisasi membutuhkan konteks yang lebih luas.

Sistem perlu memeriksa tindakan yang diminta, resource yang dituju, hubungan pengguna dengan data, status proses, batas kewenangan, serta kondisi bisnis pada saat permintaan dibuat.

Seorang staf mungkin boleh melihat dokumen, tetapi tidak boleh mengubahnya. Seorang supervisor mungkin dapat menyetujui transaksi, tetapi hanya untuk cabang tertentu. Administrator dapat mengelola akun pengguna, tetapi belum tentu boleh membaca seluruh data transaksi.

Masalah muncul ketika microservice hanya membaca nama role dari token, kemudian menganggap seluruh pengguna dengan role yang sama mempunyai hak identik terhadap semua resource.

Model tersebut terlalu sederhana untuk aplikasi perusahaan yang memiliki banyak cabang, unit, jenis data, dan tahapan persetujuan.

Otorisasi seharusnya tidak hanya menjawab siapa pengguna tersebut. Otorisasi juga harus menjawab apa yang ingin dilakukan, terhadap resource mana, dan dalam kondisi seperti apa.

Inkonsistensi Hak Akses Tumbuh Bersama Sistem

Perbedaan keputusan otorisasi jarang muncul secara tiba-tiba. Masalah biasanya berkembang perlahan seiring bertambahnya service, endpoint, dan tim pengembang.

Pada tahap awal, aturan akses mungkin masih sederhana. Setiap service hanya memeriksa beberapa role dan permission. Ketika kebutuhan bisnis berkembang, muncul pengecualian berdasarkan cabang, nilai transaksi, jenis pelanggan, kepemilikan data, atau status proses.

Aturan yang awalnya mudah dipahami kemudian berubah menjadi rangkaian kondisi pada banyak codebase.

Satu tim menafsirkan role supervisor sebagai pihak yang boleh menyetujui semua transaksi. Tim lain membatasi role tersebut berdasarkan cabang. Sementara itu, service ketiga masih menggunakan definisi lama karena belum menerima pembaruan.

Inkonsistensi juga dapat muncul karena jadwal deployment berbeda. Service yang telah diperbarui menggunakan kebijakan terbaru, sedangkan service lain masih menggunakan versi sebelumnya.

Selain itu, informasi dalam token dapat menjadi tidak sesuai dengan keadaan terbaru. Pengguna mungkin sudah dipindahkan ke unit lain atau kehilangan kewenangan tertentu, tetapi token lama masih memuat role sebelumnya.

Semakin banyak aturan yang disalin, semakin besar kemungkinan munculnya authorization policy drift.

Broken Access Control Tidak Selalu Terlihat seperti Serangan

Kegagalan otorisasi sering dibayangkan sebagai endpoint terbuka yang dapat diakses tanpa login. Dalam praktiknya, masalah dapat terlihat seperti aktivitas aplikasi biasa.

Pengguna telah melakukan login secara sah. Permintaan dikirim melalui antarmuka resmi. Sistem juga memberikan respons normal. Namun, pengguna tersebut berhasil membaca atau mengubah resource yang seharusnya tidak berada dalam kewenangannya.

Contohnya dapat berupa:

• staf melihat data milik cabang lain;
• pengguna mengubah objek milik pengguna lain;
• supervisor menyetujui transaksi di atas batas kewenangannya;
• service memperoleh data yang tidak diperlukan;
• akun yang telah dinonaktifkan masih menggunakan token lama;
• proses internal melewati pemeriksaan yang berlaku bagi pengguna;
• administrator aplikasi memperoleh akses ke data bisnis sensitif;
• endpoint versi lama tidak menerapkan aturan terbaru.

OWASP menempatkan broken access control sebagai salah satu risiko utama keamanan aplikasi. Pada API, salah satu bentuk yang paling sering dibahas adalah Broken Object Level Authorization, yaitu ketika sistem menerima identifier suatu objek tanpa memastikan bahwa pengguna memang berhak mengakses objek tersebut.

Risiko ini menjadi lebih sulit ditemukan dalam arsitektur microservices karena satu proses bisnis dapat melewati beberapa service dengan mekanisme pemeriksaan yang berbeda.

API Gateway Tidak Memiliki Seluruh Konteks Bisnis

API gateway sering dijadikan pusat autentikasi dan pengendalian trafik. Pendekatan ini penting karena gateway dapat memvalidasi token, membatasi request, mencatat akses, dan menolak permintaan yang tidak memenuhi aturan dasar.

Namun, API gateway tidak selalu memiliki informasi yang cukup untuk mengambil keputusan otorisasi secara detail.

Gateway mungkin mengetahui bahwa pengguna memiliki role supervisor. Akan tetapi, gateway belum tentu mengetahui apakah transaksi berada pada cabang yang sama, apakah nilainya melewati batas kewenangan, atau apakah status transaksi masih memungkinkan untuk diubah.

Sebagian konteks hanya diketahui oleh service yang menguasai resource tersebut.

Gateway juga tidak selalu dilewati oleh seluruh komunikasi. Permintaan dapat berasal dari service internal, message queue, scheduled job, webhook, atau proses administratif. Jika service tujuan sepenuhnya mempercayai pemeriksaan di gateway, jalur alternatif tersebut dapat menjadi celah.

Karena itu, API gateway sebaiknya digunakan untuk aturan umum dan perlindungan awal. Keputusan yang berkaitan dengan objek dan konteks bisnis tetap perlu ditegakkan dekat dengan resource.

Permintaan Internal Tidak Otomatis Dapat Dipercaya

Anggapan bahwa komunikasi internal selalu aman merupakan salah satu sumber masalah pada keamanan microservices.

Sebuah service mungkin menerima permintaan dari service lain tanpa memeriksa kembali identitas dan kewenangannya. Alasannya, kedua layanan berada di jaringan yang sama atau telah melewati gateway.

Kepercayaan tersebut dapat dimanfaatkan jika salah satu service berhasil disusupi. Penyerang dapat menggunakan identitas service itu untuk memanggil layanan lain dan mengakses data yang lebih sensitif.

Identitas service hanya menjelaskan workload mana yang mengirimkan permintaan. Identitas tersebut belum menjawab apakah workload diperbolehkan melakukan tindakan tertentu pada resource yang diminta.

Karena itu, autentikasi antara layanan tetap perlu diikuti dengan otorisasi. Setiap service harus memperoleh hak minimum sesuai fungsi yang dijalankan.

Prinsip Zero Trust juga menekankan bahwa lokasi jaringan tidak seharusnya menjadi satu-satunya dasar kepercayaan. Setiap permintaan perlu dinilai berdasarkan identitas, resource, tindakan, dan konteksnya.

Sentralisasi Bukan Berarti Semua Permintaan Menuju Satu Server

Konsistensi sering diterjemahkan sebagai kewajiban untuk mengirimkan seluruh keputusan otorisasi ke satu layanan pusat. Pendekatan tersebut memang dapat menyatukan kebijakan, tetapi juga membawa konsekuensi.

Jika semua request harus menunggu respons dari satu authorization server, latensi dapat meningkat. Ketika server tersebut mengalami gangguan, banyak layanan dapat kehilangan kemampuan untuk mengambil keputusan akses.

Hal ini menciptakan titik kegagalan baru pada sistem yang sebelumnya dirancang agar terdistribusi.

Sebaliknya, meletakkan seluruh aturan di setiap microservice memang mengurangi ketergantungan jaringan, tetapi meningkatkan duplikasi dan risiko perbedaan kebijakan.

Pilihan yang lebih seimbang adalah memusatkan pengelolaan kebijakan, sementara keputusan dan penegakannya dapat didistribusikan sesuai kebutuhan arsitektur.

Organisasi dapat memiliki satu sumber untuk mendefinisikan role, permission, atribut, dan aturan akses. Kebijakan tersebut kemudian didistribusikan kepada policy engine yang berjalan dekat dengan setiap service.

Dengan pola ini, aturan tidak perlu ditulis ulang dalam banyak codebase. Service tetap dapat mengambil keputusan dengan cepat tanpa selalu menghubungi pusat otorisasi.

Tantangannya adalah memastikan seluruh service menggunakan versi kebijakan yang benar dan memperoleh pembaruan tepat waktu.

Tiga Fungsi Otorisasi Perlu Dipisahkan dengan Jelas

Pengelolaan otorisasi microservices menjadi lebih terarah ketika organisasi memisahkan tiga fungsi utama.

Pertama, terdapat fungsi pengelolaan kebijakan. Bagian ini digunakan untuk membuat, meninjau, menguji, dan memperbarui aturan akses.

Kedua, terdapat fungsi pengambilan keputusan. Komponen ini mengevaluasi identitas, resource, tindakan, dan konteks untuk menentukan apakah permintaan diizinkan.

Ketiga, terdapat fungsi penegakan. Komponen ini memastikan keputusan benar-benar diterapkan pada jalur menuju resource.

Pemisahan tersebut dikenal melalui konsep Policy Administration Point, Policy Decision Point, dan Policy Enforcement Point. Pola ini juga digunakan dalam pedoman OWASP dan arsitektur Zero Trust NIST.

Ketiganya tidak harus berjalan di satu aplikasi yang sama. Pengelolaan kebijakan dapat dilakukan secara terpusat, pengambilan keputusan dapat berlangsung secara lokal atau eksternal, dan penegakan tetap dilakukan dekat dengan resource.

Yang terpenting adalah setiap fungsi mempunyai tanggung jawab, sumber data, dan mekanisme audit yang jelas.

Policy as Code Mengurangi Banyak Versi Kebenaran

Aturan hak akses sering tersimpan dalam dokumen kebijakan, tiket pengembangan, dan kondisi if pada source code. Ketika ketiganya tidak diperbarui secara bersamaan, organisasi kesulitan menentukan aturan mana yang sebenarnya berlaku.

Policy as code dapat membantu mengurangi persoalan tersebut.

Kebijakan disimpan dalam format yang dapat dibaca sistem, dimasukkan ke version control, dan melalui proses review seperti perubahan kode lainnya. Setiap perubahan memiliki riwayat, pemilik, alasan, serta versi yang dapat ditelusuri.

Pendekatan ini memungkinkan organisasi:

• meninjau perubahan kebijakan sebelum diterapkan;
• menjalankan pengujian otomatis;
• membandingkan kebijakan antar-environment;
• mendeteksi service yang menggunakan versi lama;
• mengembalikan kebijakan jika terjadi kesalahan;
• memastikan aturan tidak berubah tanpa persetujuan.

Namun, policy as code bukan sekadar mengganti dokumen menjadi file konfigurasi. Perusahaan tetap perlu memastikan aturan teknis benar-benar mencerminkan kebijakan bisnis.

Tim keamanan, pengembang, dan pemilik proses bisnis perlu menyepakati arti setiap role, permission, atribut, dan pengecualian.

Role Saja Tidak Selalu Cukup

Role-Based Access Control atau RBAC memberikan cara yang relatif sederhana untuk mengelompokkan hak akses. Pengguna memperoleh role, lalu role tersebut mempunyai sekumpulan permission.

Model ini efektif ketika aturan akses stabil dan tidak terlalu bergantung pada konteks.

Pada aplikasi yang lebih kompleks, role dapat bertambah sangat banyak. Organisasi dapat memiliki role supervisor cabang, supervisor regional, supervisor sementara, supervisor proyek, dan berbagai variasi lainnya.

Jumlah role terus bertambah karena setiap pengecualian dibuat sebagai role baru. Kondisi ini sering disebut role explosion.

Attribute-Based Access Control atau ABAC dapat digunakan untuk mengevaluasi atribut pengguna, resource, tindakan, dan lingkungan. Misalnya, akses diberikan jika cabang pengguna sama dengan cabang transaksi dan nilai transaksi berada di bawah batas kewenangannya.

Pendekatan berbasis atribut dapat menghasilkan aturan yang lebih fleksibel. Namun, kualitas keputusan bergantung pada ketersediaan dan keakuratan data atribut.

Jika data cabang, status akun, atau kepemilikan resource tidak diperbarui, keputusan otorisasi tetap dapat salah meskipun kebijakannya telah dirancang dengan baik.

Cache Dapat Mempertahankan Hak yang Seharusnya Sudah Dicabut

Untuk menjaga kinerja, keputusan otorisasi sering disimpan sementara dalam cache. Service tidak perlu mengevaluasi atau meminta keputusan baru untuk setiap request.

Langkah ini dapat mengurangi latensi, tetapi juga menimbulkan risiko.

Seorang pengguna mungkin telah kehilangan role. Sebuah transaksi dapat berubah status. Akses sementara mungkin telah berakhir. Namun, cache masih menyimpan keputusan lama yang mengizinkan tindakan tersebut.

Risiko yang sama muncul pada token berumur panjang. Informasi role dan permission yang tersimpan dalam token dapat tetap digunakan sampai token kedaluwarsa, meskipun hak pengguna sudah berubah pada sistem utama.

Karena itu, perusahaan perlu menetapkan masa berlaku cache berdasarkan tingkat risiko. Keputusan untuk membaca data umum mungkin dapat disimpan lebih lama daripada keputusan untuk menghapus data atau menyetujui transaksi bernilai besar.

Untuk tindakan sensitif, keputusan terbaru sebaiknya dievaluasi kembali. Sistem juga perlu memiliki mekanisme untuk membatalkan cache ketika role, status akun, atau kebijakan berubah.

Keputusan Akses Harus Dapat Dijelaskan

Audit otorisasi tidak cukup hanya mencatat bahwa sebuah endpoint memberikan respons berhasil atau ditolak.

Perusahaan perlu mengetahui alasan di balik keputusan tersebut.

Catatan otorisasi idealnya mencakup:

• identitas pengguna atau service;
• resource yang diminta;
• tindakan yang dilakukan;
• atribut yang digunakan;
• hasil keputusan;
• versi kebijakan;
• service yang menegakkan keputusan;
• waktu pengambilan keputusan;
• alasan akses diberikan atau ditolak.

Informasi tersebut diperlukan ketika perusahaan melakukan investigasi insiden, audit kepatuhan, atau evaluasi kebijakan.

Audit juga dapat membantu menemukan inkonsistensi. Jika dua service memberikan hasil berbeda untuk pengguna, tindakan, resource, dan konteks yang sama, organisasi dapat menyelidiki kemungkinan policy drift.

Tanpa catatan keputusan yang memadai, perbedaan baru diketahui setelah pengguna melaporkan masalah atau kerentanan berhasil dimanfaatkan.

Pengujian Tidak Boleh Berhenti pada Skenario Normal

Pengujian aplikasi sering memastikan pengguna yang sah dapat menjalankan fitur sesuai role. Skenario tersebut penting, tetapi belum cukup untuk menguji keamanan otorisasi.

Tim juga perlu mencoba kondisi yang seharusnya ditolak.

Pengujian dapat dilakukan dengan mengubah identifier objek, menggunakan token milik pengguna lain, memanggil endpoint secara langsung, mengakses service melalui jalur internal, atau mengulangi permintaan setelah role dicabut.

Skenario lintas cabang, lintas unit, dan lintas tenant juga perlu diperiksa. Pengguna mungkin diizinkan membaca satu objek, tetapi tidak seharusnya memperoleh akses ke seluruh objek dengan tipe serupa.

Berita keamanan pada 2026 kembali memperlihatkan bahwa kesalahan validasi otorisasi pada API masih ditemukan pada platform pengembangan berskala besar. Hal ini menunjukkan bahwa pemeriksaan akses bukan persoalan yang selesai hanya dengan menambahkan token atau middleware autentikasi.

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

Pada beberapa aplikasi, pemeriksaan hak akses telah diterapkan di halaman utama, tetapi tidak konsisten pada endpoint lain, API versi lama, fungsi administratif, atau komunikasi antar layanan. Pengguna biasa kemudian dapat mengakses data atau tindakan yang seharusnya dibatasi.

Matriks Hak Akses Perlu Mengikuti Proses Bisnis

Perusahaan dapat mengurangi ketidakkonsistenan dengan membuat matriks hak akses yang menghubungkan pengguna, tindakan, resource, dan konteks.

Matriks tersebut tidak cukup hanya berisi daftar role dan menu. Aturan perlu diturunkan sampai ke operasi penting dan objek yang dilindungi.

Contohnya:

• siapa yang boleh melihat transaksi;
• siapa yang boleh mengubah transaksi;
• siapa yang boleh memberikan persetujuan;
• batas nominal yang diperbolehkan;
• unit atau cabang yang dapat diakses;
• status proses yang masih dapat diubah;
• pihak yang boleh mengekspor data;
• kondisi yang membutuhkan persetujuan tambahan.

Matriks kemudian dapat menjadi dasar untuk pengembangan kebijakan, pengujian otomatis, dan penetration testing.

Ketika proses bisnis berubah, matriks perlu diperbarui sebelum perubahan diterapkan ke berbagai microservice.

Langkah Menyatukan Otorisasi Microservices

Perbaikan sebaiknya dimulai dengan inventarisasi. Organisasi perlu memetakan service, endpoint, role, permission, identitas service, serta aturan akses yang saat ini digunakan.

Setelah itu, identifikasi aturan yang ditulis berulang kali dan kemungkinan perbedaan implementasinya. Perhatian khusus perlu diberikan pada API lama, endpoint internal, message consumer, scheduled job, dan proses administratif.

Langkah berikutnya adalah menyepakati model bersama untuk subjek, resource, tindakan, dan atribut. Istilah yang sama tidak boleh memiliki arti berbeda pada setiap tim.

Kebijakan kemudian dikelola melalui satu sumber yang memiliki versioning, proses review, dan pengujian. Organisasi dapat memilih pola pengambilan keputusan terpusat, lokal, atau gabungan sesuai kebutuhan kinerja dan ketersediaan.

Penegakan tetap harus berada dekat dengan resource. Setiap service perlu memeriksa bahwa keputusan yang diterima berlaku untuk objek dan tindakan yang sedang diproses.

Terakhir, keputusan otorisasi harus dicatat dan diuji secara berkelanjutan. Pengujian tidak hanya dilakukan ketika fitur pertama kali dibuat, tetapi juga setiap kali role, alur bisnis, endpoint, atau integrasi berubah.

Konsistensi Otorisasi Adalah Tanggung Jawab Arsitektur

Microservices dirancang untuk memberikan otonomi kepada layanan dan tim pengembang. Namun, otonomi tersebut tidak boleh menghilangkan akuntabilitas atas keputusan akses.

Perusahaan tidak harus menempatkan seluruh keputusan pada satu server. Namun, perusahaan perlu mempunyai satu model kebijakan, sumber kebenaran yang jelas, mekanisme distribusi yang terkendali, serta penegakan yang dekat dengan resource.

Tanpa hal tersebut, pengguna yang sama dapat memperoleh keputusan berbeda hanya karena permintaannya diproses oleh service yang berbeda.

Otorisasi microservices perlu diperlakukan sebagai bagian dari arsitektur dan Secure SDLC. Aturan akses harus dirancang, diuji, diaudit, dan diperbarui dengan disiplin yang sama seperti komponen penting lainnya.

Fourtrezz membantu perusahaan mengevaluasi keamanan aplikasi dan infrastruktur melalui layanan vulnerability assessment serta penetration testing. Pengujian dapat membantu menemukan broken access control, perbedaan validasi antar-endpoint, eskalasi hak akses, dan kelemahan pada komunikasi antar layanan sebelum dimanfaatkan oleh pihak yang tidak bertanggung jawab.

Untuk mendiskusikan kebutuhan pengujian keamanan dan peluang kerjasama, silakan menghubungi Fourtrezz.

Hubungi Fourtrezz:

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