Subscribe to DeepL Pro to translate larger documents.
Visit www.DeepL.com/pro for more information.
Artikel
Otorisasi Pengguna dalam Aplikasi Berbasis Layanan Mikro
Niklas Sänger * dan Sebastian Abeck
Kutipan: Sänger, N.; Abeck, S.
Otorisasi Pengguna dalam Aplikasi
Berbasis Layanan Mikro. Perangkat
Lunak 2023, 2,
400-426. https://doi.org/10.3390/
software2030019
Editor Akademik: Manuel Mazzara
Diterima: 11 Agustus 2023
Direvisi: 31 Agustus 2023
Diterima: 5 September 2023
Diterbitkan: 19 September 2023
Hak Cipta: © 2023 oleh penulis.
Pemegang lisensi MDPI, Basel,
Swiss. Artikel ini adalah artikel akses
terbuka yang didistribusikan di bawah
syarat dan ketentuan lisensi Creative
Commons Atribusi (CC BY) (https://
creativecommons.org/licenses/by/
4.0/).
Kelompok Penelitian Kerjasama & Manajemen, Institut Teknologi Karlsruhe, 76131 Karlsruhe, Jerman;
sebastian.abeck@kit.edu
* Korespondensi: niklas.saenger@kit.edu
Abstrak: Layanan mikro telah muncul sebagai gaya arsitektur yang lazim dalam pengembangan
perangkat lunak modern, menggantikan arsitektur monolitik tradisional. Penguraian fungsionalitas
bisnis menjadi layanan mikro terdistribusi menawarkan banyak manfaat, tetapi memperkenalkan
peningkatan kompleksitas pada aplikasi secara keseluruhan. Akibatnya, kompleksitas otorisasi dalam
aplikasi berbasis layanan mikro membutuhkan pendekatan komprehensif yang mengintegrasikan
otorisasi sebagai komponen yang melekat sejak awal. Makalah ini menyajikan pendekatan
sistematis untuk mencapai otorisasi pengguna yang baik dengan menggunakan Kontrol Akses
Berbasis Atribut (ABAC). Pendekatan yang diusulkan menekankan pada pelestarian struktur,
memfasilitasi penelusuran di berbagai fase pengembangan aplikasi. Hasilnya, artefak otorisasi
dapat ditelusuri dengan mulus dari fase analisis awal hingga fase implementasi berikutnya. Salah
satu kontribusi yang signifikan adalah pengembangan bahasa untuk merumuskan persyaratan dan
kebijakan otorisasi bahasa alami. Kebijakan otorisasi bahasa alami ini kemudian dapat
diimplementasikan menggunakan bahasa kebijakan Rego. Dengan memanfaatkan analisis artefak
perangkat lunak, pendekatan yang diusulkan memungkinkan pembuatan kebijakan otorisasi yang
komprehensif dan disesuaikan.
Kata kunci: layanan mikro; otorisasi berbutir halus; ABAC; teknik; pelestarian struktur
1. Pendahuluan
Arsitektur layanan mikro telah menjadi gaya arsitektur yang sangat populer di dunia
pencarian dan industri [1-3]. Aplikasi berbasis layanan mikro menggantikan aplikasi
monolitik dengan membagi logika bisnis menjadi layanan-layanan yang lebih kecil yang
melakukan tugas yang terdefinisi dengan baik dan relatif kecil [4]. Setiap layanan
mengekspos fungsionalitasnya melalui Application Programming Interface (API) web.
Ada beberapa paradigma API web, seperti Representational State Transfer (REST) [5]
atau Remote Procedure Calls (RPC) [6], dengan spesifikasi yang paling populer adalah
OpenAPI [7] dan gRPC [8]. Dengan spesifikasi API yang dirancang dengan baik, layanan mikro
memungkinkan pembuatan layanan yang dapat digunakan kembali. Dalam makalah ini,
kami mengikuti gaya arsitektur yang dipresentasikan oleh Hippchen dkk. [9] dan Sidler
dkk. [10]. Fungsionalitas bisnis diimplementasikan dalam sebuah layanan mikro yang
berada di lapisan aplikasi. Sebuah frontend yang berada di lapisan presentasi mengakses
layanan mikro yang bersangkutan. Namun, dengan distribusi logika bisnis di beberapa
layanan mikro, kompleksitas keseluruhan layanan mikro manajemen meningkat [4]. Hal
ini termasuk integrasi mekanisme kontrol akses.
Open Web Application Security Project (OWASP) sering mempublikasikan daftar
risiko keamanan pada aplikasi web. Dalam daftar tahun 2021, kontrol akses yang rusak
terdaftar sebagai risiko keamanan nomor satu [11]. Dalam arsitektur layanan mikro,
kompleksitas kontrol akses semakin meningkat dengan adanya distribusi layanan dan
tanggung jawabnya. Seperti yang dilaporkan oleh de Almeida dan Canedo [12],
komunikasi, kepercayaan, dan kontrol akses antara layanan mikro merupakan tantangan
utama. Otentikasi dan otorisasi adalah aspek dari kontrol akses [13]. Otentikasi melibatkan
proses verifikasi identitas subjek, sementara otorisasi menentukan tingkat akses yang
diberikan kepada subjek yang diautentikasi.
Otorisasi untuk aplikasi berbasis layanan mikro telah diteliti terutama sebagai aspek
teknis untuk mengevaluasi dan menegakkan keputusan otorisasi dalam layanan mikro

Perangkat Lunak 2023, 2, 400-426. https://doi.org/10.3390/software2030019 https://www.mdpi.com/journal/software

Perangkat 401
Lunak 2023, 2

arsitektur [14,15]. Kopling longgar dari layanan mikro menawarkan pemisahan masalah
antara logika bisnis dan logika otorisasi. Hal ini memungkinkan modifikasi logika
otorisasi tanpa mengubah logika bisnis. Dalam makalah ini, kami menerapkan ABAC
untuk melakukan keputusan otorisasi karena melengkapi kopling longgar layanan mikro
dengan menambahkan komponen otorisasi ke arsitektur keseluruhan [16].
Selain tantangan arsitektural, pertanyaan mengenai apa yang harus diotorisasi dan bagaimana
au- torisasi dapat dirumuskan secara sistematis dan secara konsekuen ditegakkan belum
sepenuhnya ditangani. Hal ini menyiratkan perubahan pada proses pengembangan
perangkat lunak untuk aplikasi berbasis layanan mikro. Otorisasi, sebagai bagian dari
keamanan komputer, adalah persyaratan non-fungsional [13] yang sering dilakukan
sebagai renungan dalam rekayasa perangkat lunak [17]. Untuk mengatasi hal ini,
otorisasi harus dikumpulkan selama analisis kebutuhan dan selanjutnya direalisasikan
selama desain dan implementasi. Namun, tidak ada prosedur yang ditetapkan secara luas
untuk mendefinisikan kebijakan otorisasi. Meskipun ada pendekatan berbasis model untuk
mendapatkan kebijakan ABAC berdasarkan model Unified Modeling Language (UML)
[18,19], namun masih sedikit penelitian mengenai pendekatan untuk mendapatkan
kebijakan ABAC sebagai bagian integral dari proses rekayasa perangkat lunak. Hal ini
juga berlaku untuk definisi dan pembuatan persyaratan otorisasi, yang diperlukan untuk
mendefinisikan apa yang perlu diotorisasi dan tidak memiliki struktur yang sistematis
[20].
Kami mengidentifikasi integrasi otorisasi berbutir halus menggunakan ABAC dalam
pengembangan aplikasi berbasis layanan mikro sebagai kesenjangan penelitian utama.
Untuk mengatasi kesenjangan ini, kami membuat empat pertanyaan penelitian yang
diselidiki dalam makalah ini:

RQ1 Bagaimana kebijakan ABAC dapat dirumuskan secara

sistematis? RQ2 Bagaimana persyaratan untuk otorisasi dapat
dirumuskan?
RQ3 Bagaimana kita dapat menerapkan kebijakan otorisasi secara sistematis?
RQ4 Bagaimana kita dapat mengintegrasikan otorisasi ke dalam pengembangan aplikasi
berbasis layanan mikro?

Pertanyaan penelitian utama adalah perumusan kebijakan ABAC (RQ1) sebagai artefak
otorisasi utama. Definisi kebijakan ABAC mempengaruhi apa yang harus dikumpulkan selama
analisis kebutuhan (RQ2) dan bagaimana kebijakan dapat diimplementasikan (RQ3). Integrasi
holistik ke dalam pengembangan (RQ4) tergantung pada artefak otorisasi. Untuk
menjawab pertanyaan-pertanyaan penelitian tersebut, kontribusi dari makalah ini adalah
sebagai berikut
ing: Pertama, kami mengusulkan sebuah bahasa kebijakan otorisasi untuk menyediakan
struktur untuk perumusan kebijakan otorisasi bahasa alami. Hal ini dilakukan dengan
Augmented Backus-Naur Form (ABNF) yang menata aspek-aspek yang diperlukan dari ABAC.
Kedua, sebuah subset dari bahasa kebijakan otorisasi disediakan untuk menetapkan
formalisasi untuk definisi persyaratan otorisasi selama fase analisis. Ketiga, kami
menyediakan struktur untuk mengimplementasikan kebijakan otorisasi menggunakan
bahasa kebijakan Rego. Keempat, kami menyediakan ekstensi otorisasi untuk proses
pengembangan aplikasi berbasis layanan mikro yang mencakup fase analisis, desain, dan
implementasi serta pengujian.
Dalam pekerjaan ini, kami fokus pada aplikasi berbasis layanan mikro yang menggunakan
API RESTful, karena mereka memiliki serangkaian operasi yang tetap mengikuti penggunaan
operasi Create, Read, Update, dan Delete (CRUD) [5]. Lebih lanjut, otentikasi tidak dibahas
dalam makalah ini. Dengan kata lain, hal ini mengasumsikan bahwa pengguna manusia
sudah terotentikasi (misalnya, melalui Open ID Connect) dan dapat membuktikannya
(misalnya, melalui JSON Web Token (JWT) yang valid [21]).
Sisa dari artikel ini disusun sebagai berikut: Bagian 2 menyajikan pekerjaan terkait
tentang otorisasi dan keadaan terkini dari otorisasi (fine-grained) dalam aplikasi (berbasis
layanan mikro). Pada Bagian 3, bahasa kebijakan otorisasi, implementasi kebijakan
otorisasi, dan perluasan otorisasi untuk proses pengembangan diperkenalkan. Untuk
menunjukkan kontribusi dari pekerjaan ini, Bagian 4 memperkenalkan sebuah studi kasus
Perangkat 402
Lunak 2023, 2
yang menggunakan artefak otorisasi dan ekstensi otorisasi dalam proses pengembangan.
Hasilnya dibahas di Bagian 5. Akhirnya, Bagian 6 merangkum pekerjaan ini.
Perangkat 403
Lunak 2023, 2

2. Pekerjaan Terkait
2.1. Latar Belakang
Kontrol akses adalah aspek fundamental dari keamanan dalam sistem TI [13]. Ini
terdiri dari tiga aspek: otentikasi, otorisasi, dan audit [22]. Dalam kontrol akses, sebuah
subjek (manusia atau non-manusia) selalu berusaha untuk melakukan suatu tindakan
pada sebuah objek. Sebuah subjek harus diautentikasi sebelum permintaan akses dapat
diotorisasi atau tidak. Permintaan akses dicatat untuk tujuan audit. Dalam pekerjaan ini,
hanya istilah subjek dan objek yang digunakan untuk memberikan terminologi umum
dan untuk menghindari kesalahpahaman (misalnya, penggunaan subjek dan bukan
pengguna).
Otorisasi sering kali dibagi menjadi otorisasi berbutir kasar dan berbutir halus [23].
Kontrol akses berbutir kasar memberikan akses ke sistem atau sumber daya kepada
subjek yang lebih luas. Sebaliknya, kontrol akses berbutir halus memungkinkan hak
akses yang fleksibel ke sumber daya tertentu untuk pengguna individu [24,25]. Gambaran
umum yang menyajikan karakteristik otorisasi berbutir halus dan berbutir kasar
disediakan pada Tabel 1. Paradigma otorisasi yang populer adalah Role-Based Access
Control (RBAC) dan ABAC. RBAC mengaitkan satu set izin (misalnya, membaca atau menulis
ke folder) dengan peran yang dapat diberikan ke subjek [26]. Dengan demikian, RBAC
biasanya digunakan untuk melakukan otorisasi yang agak kasar. RBAC masih
memungkinkan untuk membuat peran untuk sumber daya atau pengguna individu.
Namun, hal ini dapat menyebabkan fenomena yang disebut ledakan peran, yang
mengimplikasikan jumlah peran yang tidak dapat diatur dalam sistem kontrol akses [27].

Tabel 1. Perbandingan tingkat perincian otorisasi yang diadaptasi dari [28].

Karakteristik Berbutir halus Berbutir Kasar

Perincian Kontrol yang sangat detail Kontrol yang lebih luas dan umum
dan spesifik
Cakupan Mengontrol akses ke sumber Mengelola akses di tingkat yang
daya atau tindakan individu lebih tinggi (misalnya, fungsi,
layanan)
Fleksibilitas Tinggi Rendah
Pengelolaan Kompleks Sederhana
Menguba
Sederhana Kompleks
h Hak
Istimewa
ABAC RBAC
Paradigm
a Populer

ABAC dapat melakukan keputusan otorisasi berdasarkan sekumpulan atribut yang

dapat diterima dari subjek, objek, atau lingkungan [29]. Atribut-atribut tersebut dapat
dirumuskan sebagai sekumpulan kondisi. Untuk melakukan otorisasi, kondisi-kondisi
tersebut dikumpulkan dalam sebuah kebijakan otorisasi yang kemudian dapat ditegakkan.
Pengumpulan atribut dan kondisi memungkinkan pembuatan kebijakan akses berbutir
halus yang sangat kompleks [30]. Kebijakan ABAC dapat diimplementasikan dalam bahasa
kebijakan seperti eXtensible Access Control Markup Language (XACML) [31]. Untuk
menegakkan kebijakan ABAC, ada arsitektur referensi yang terdiri dari empat komponen
utama [29]: Policy Enforcement Point (PEP), Policy Decision Point (PDP), Policy
Information Point (PIP), dan Policy Administration Point (PAP). PEP menerima
permintaan otorisasi dari klien (misalnya, browser web) dan meneruskannya ke PDP,
yang memutuskan apakah akan mengizinkan atau menolak permintaan tersebut. Hasilnya
dikembalikan ke PEP dan permintaan dikabulkan atau ditolak ke sumber daya. Untuk
memutuskan apakah permintaan tersebut valid, PDP dapat menggunakan PIP, yang
menyediakan atribut yang diperlukan untuk membuat keputusan. PAP memungkinkan
perumusan kebijakan otorisasi. Meskipun ABAC memungkinkan pembuatan kebijakan
otorisasi berbutir halus, kompleksitas untuk memperkenalkannya ke dalam aplikasi dan
Perangkat mengelolanya tinggi, sebagian karena sifatnya yang terdistribusi [28]. 404
Lunak 2023, 2
Untuk mendefinisikan kebijakan otorisasi, Formulir Backus-Naur yang Ditambah
(Augmented Backus-Naur Form, ABNF) digunakan dalam makalah ini. ABNF adalah
versi modifikasi dari Formulir Backus-Naur (Backus-Naur
Perangkat 405
Lunak 2023, 2

Formulir) [32]. ABNF disusun menggunakan aturan dan elemen yang mewakili tata bahasa
suatu bahasa. Setiap aturan terdiri dari sebuah nama, diikuti dengan tanda sama dengan
"=", dan elemen-elemen yang mendefinisikan aturan tersebut. Elemen dapat berupa
simbol terminal (literal) atau referensi ke aturan lain. Notasi ini memungkinkan adanya
elemen opsional, pengulangan, dan pengelompokan, sehingga lebih fleksibel daripada
BNF tradisional. ABNF digunakan dalam spesifikasi protokol internet. Sebagai contoh,
spesifikasi protokol HTTP [33] atau OAuth 2.0 [34] menggunakan ABNF.
Daftar 1 menyajikan kutipan dari spesifikasi HTTP 1.1. Aturan Request-Line (baris
1) mengacu pada lima aturan lain yang diikuti oleh Carriage Return Line Feed (CRLF).
Baris 3 menyajikan aturan yang mendefinisikan bagaimana versi HTTP ditentukan,
misalnya, HTTP 1.1. Terakhir, aturan Method pada baris 4 mendefinisikan metode
HTTP yang tersedia, misalnya GET.

Daftar 1. Kutipan dari spesifikasi HTTP 1.1 [33].

1 Request-Line = Metode SP Request-URI SP HTTP-Version~CRLF 2

3 Versi HTTP = "HTTP" "/" 1*DIGIT "." 1*DIGIT
4 Metode = "OPSI" | "GET" | "HEAD" | "POST" | ...
5 ..

2.2. Keadaan Seni

Mengintegrasikan otorisasi ke dalam aplikasi berbasis layanan mikro membahas
bagian dari keamanan yang berfokus pada lapisan aplikasi [35]. Ada beberapa
pendekatan dan solusi untuk mengintegrasikan otorisasi ke dalam aplikasi berbasis
layanan mikro. Banati dkk. [36] mengusulkan orkestrator otorisasi menggunakan token
web JSON, OAuth, dan OpenID. Setiap layanan mikro memiliki modul IAM yang
berkomunikasi dengan orkestrator otorisasi dan memberlakukan keputusan. Sauwens
dkk. [15] menjelaskan middleware otorisasi terdistribusi yang disebut ThunQ yang dapat
melakukan keputusan otorisasi lebih awal (yaitu, ketika layanan pertama tercapai) dan
malas (yaitu, mengevaluasi keputusan hanya jika memungkinkan). ThunQ
memungkinkan keputusan otorisasi dibuat pada tingkat layanan mikro dengan
menyertakan pengubah kueri. Nehme dkk. [14] menyajikan solusi kontrol akses untuk
arsitektur layanan mikro berdasarkan kombinasi teknologi OAuth 2.0 dan XACML. Solusi
mereka membutuhkan server kontrol akses terpusat yang menyimpan data yang
diperlukan untuk mengevaluasi permintaan. Hal ini bertentangan dengan penggabungan
layanan mikro yang longgar. Lebih lanjut, solusi yang disajikan berfokus pada
implementasi teknis otorisasi dalam aplikasi berbasis layanan mikro. Solusi-solusi
tersebut menjawab pertanyaan tentang bagaimana mengimplementasikan otorisasi dalam
arsitektur layanan mikro. Namun, solusi-solusi ini mengabaikan pertanyaan tentang apa
yang harus diotorisasi. Untuk menjawab pertanyaan ini, kebijakan otorisasi harus dibuat
berdasarkan kebutuhan pengguna. Proses pembuatan kebijakan otorisasi juga disebut
rekayasa kebijakan.
Das dkk. [37] memberikan klasifikasi untuk pendekatan rekayasa untuk kebijakan
ABAC. Kelas yang ditekankan adalah pendekatan top-down dan bottom-up.
Pendekatan bottom-up membuat kebijakan berdasarkan penambangan permintaan akses
masa lalu, memeriksa log, atau menambang matriks peran yang ada. Pendekatan bottom-
up membutuhkan data yang ada untuk menambang kebijakan. Pendekatan top-down
dimulai dari awal, tanpa data sebelumnya selain dokumen kebijakan bahasa alami yang
ada. Kompleksitas yang melekat pada pendekatan ini adalah transformasi dokumen
bahasa alami ke dalam kebijakan otorisasi. Oleh karena itu, penulis mengidentifikasi
pembuatan kebijakan otorisasi berdasarkan dokumen bahasa alami sebagai sesuatu
yang tidak tepat.
Brossard dkk. [20] mengusulkan siklus hidup yang sistematis untuk
mengimplementasikan ABAC berdasarkan pengalaman perusahaan. Pendekatan ini
menyusun pengembangan kebijakan otorisasi ke dalam fase-fase proses pengembangan
perangkat lunak. Hal ini termasuk mengumpulkan persyaratan otorisasi, mengidentifikasi
atribut yang relevan, mengimplementasikan dan menguji kebijakan, dan penerapan.
Untuk mendefinisikan persyaratan otorisasi, penulis menyarankan penggunaan kasus
Perangkat 406
Lunak 2023, 2
penggunaan. Persyaratan otorisasi ditulis dalam format bahasa alami. Para penulis
menggunakan XACML untuk mengimplementasikan kebijakan otorisasi. Proses yang
dilakukan oleh Brossard dkk. [20] menyediakan struktur yang menjanjikan untuk
mengembangkan kebijakan otorisasi. Namun, prosesnya agak kasar dan kurang detail
tentang cara membuat artefak secara sistematis. Sebagai contoh,
Perangkat 407
Lunak 2023, 2

penulis tidak menyediakan struktur untuk pembuatan persyaratan otorisasi atau

kebijakan otorisasi. Alohaly dkk. [38] fokus pada otomatisasi ekstraksi atribut
berdasarkan yang disajikan oleh Bossard dkk. dengan menggunakan pemrosesan
bahasa alami.
Pendekatan lain untuk mengotomatisasi pengembangan kebijakan ABAC disajikan
oleh Narouei dkk. [39], yang menggambarkan kerangka kerja rekayasa kebijakan untuk
mendapatkan kebijakan ABAC dari dokumen bahasa alami menggunakan pemrosesan
bahasa alami. Mirip dengan [20], penulis menggunakan dokumen persyaratan yang ada
untuk mengidentifikasi dan mengekstrak elemen kebijakan yang relevan (misalnya,
subjek dan objek). Atribut kemudian diekstraksi dari elemen-elemen tersebut dan
diformat ke dalam kebijakan XACML. Pendekatan Narouei et al. tidak menyertakan
definisi bagaimana persyaratan otorisasi didokumentasikan dalam analisis persyaratan.
Zolotas dkk. [19] menyajikan RESTSec, yang memungkinkan pembuatan layanan RESTful
yang aman dengan menggunakan kode yang rendah. Para penulis menggunakan rekayasa
berbasis model dengan metamodel Unified Modeling Language (UML) untuk ABAC
untuk menghasilkan kebijakan XACML. Fatemian dkk. [40] juga mengusulkan
pendekatan rekayasa berbasis model yang menggunakan metamodel UML untuk ABAC
untuk menghasilkan kebijakan XACML. Pendekatan ini memungkinkan pembuatan
kebijakan XACML berdasarkan transformasi metamodel UML. Para penulis
menyediakan antarmuka grafis untuk membuat kebijakan yang kemudian dapat
ditransformasikan. Pendekatan ini membutuhkan definisi manual dari persyaratan
otorisasi. Selain itu, persyaratan otorisasi masih harus dianalisis untuk objek, tindakan,
dan atributnya, yang menyisakan ruang untuk ketidakakuratan. Pendekatan Brossard
dkk., Narouei dkk., Zolotas dkk., dan Fatemian dkk.
dapat diklasifikasikan sebagai kebijakan top-down karena membutuhkan dokumen yang
sudah ada untuk mengekstrak informasi yang relevan. Selain itu, Brossard dkk.
mengabaikan proses pembuatan dokumen bahasa alami yang dibutuhkan. Pendekatan
penambangan bottom-up diusulkan oleh Talukdar dkk. [41]. Para penulis memeriksa
permintaan akses yang ada dan membuat aturan otorisasi yang sesuai. Untuk
pengembangan aplikasi berbasis layanan mikro yang baru, pendekatan penambangan
bottom-up tidak dapat diterapkan, karena tidak ada data yang ada untuk mendapatkan
kebijakan. Namun, pembuatan kebijakan otorisasi tambahan berdasarkan, misalnya, log,
dapat lebih memperkuat keamanan aplikasi berbasis layanan mikro.

3. Otorisasi dalam Aplikasi Berbasis Layanan Mikro

Pembuatan kebijakan otorisasi dapat dilakukan dalam beberapa bentuk. Menurut
[29], Natural Language Policies (NLPs) dan Digital Policies (DPs) harus
dipertimbangkan. NLPs adalah pernyataan yang mengatur manajemen dan akses objek
yang dapat dibaca manusia, yang kemudian dapat ditransformasikan ke dalam kebijakan
kontrol akses yang dapat ditegakkan oleh mesin. Kebijakan digital adalah aturan kontrol
akses yang dapat dikompilasi ke dalam kode yang dapat dieksekusi oleh mesin [29].
Subjek, objek, atribut, dan aturan adalah blok bangunan untuk kebijakan digital.
Kebijakan digital dapat ditegakkan oleh PDP. Sepanjang fase pengembangan aplikasi
berbasis layanan mikro, informasi yang tersedia mengenai otorisasi berubah dalam hal
kejelasan dan struktur. Kami mengatasi hal ini dengan memperkenalkan tiga artefak yang
berkisar dari kebijakan bahasa alami hingga kebijakan digital.
Gambar 1 memberikan gambaran umum tentang artefak yang diperkenalkan dalam masing-
masing fase pengembangan. Persyaratan otorisasi adalah NLP yang dibuat dalam fase
analisis. Untuk membuat persyaratan otorisasi, kami mengusulkan Augmented Backus-
Naur Form (ABNF) yang menyediakan struktur untuk kalimat yang alami dan dapat
dibaca oleh manusia. Dengan fase desain, pengetahuan mengenai otorisasi lebih
terkonsolidasi dan istilah-istilah ABAC yang relevan (misalnya, subjek dan objek)
diketahui. Oleh karena itu, kami memperkenalkan kebijakan otorisasi artefak yang
merupakan persyaratan otorisasi yang didefinisikan lebih lanjut yang berisi blok
bangunan untuk kebijakan digital. Serupa dengan persyaratan otorisasi, kami
mengusulkan ABNF yang berisi aturan yang lebih terstruktur untuk membuat kebijakan
otorisasi yang lebih terstruktur. Dengan demikian, kami mengklasifikasikan kebijakan
otorisasi sebagai kebijakan bahasa alami dan artefak perantara ke kebijakan digital.
Perangkat 408
Lunak 2023, 2
Terakhir, pada tahap implementasi dan pengujian, kebijakan otorisasi diubah menjadi
kebijakan digital dengan mengimplementasikan kebijakan tersebut menggunakan Rego.
Perangkat 409
Lunak 2023, 2

Jenis Polis Kebijakan Bahasa Alami Kebijakan Digital

Persyaratan Kebijakan Implement

Artefak
Otorisasi Otorisasi asi Kebijakan

Bahasa ABNF ABNF Rego

Tahap Implementasi
Pengembangan
Analisis Desain
dan
Pengujian
Gambar 1. Klasifikasi jenis kebijakan dan artefak kebijakan.

Karena kebijakan otorisasi merupakan artefak perantara antara NLP dan DP, pertama-tama
kami memperkenalkan ABNF untuk kebijakan otorisasi di Bagian 3.1. Berdasarkan
kebijakan otorisasi, kami memperkenalkan ABNF untuk persyaratan otorisasi sebagai
kebijakan otorisasi yang disederhanakan di Bagian 3.2. Implementasi di Rego berdasarkan
diperkenalkan di Bagian 3.3. Terakhir, integrasi ke dalam proses pengembangan
diperkenalkan di Bagian 3.4.
Melengkapi pengenalan artefak otorisasi yang diusulkan, kami memperkenalkan
dua contoh yang sedang berjalan:
1. Alice bekerja di bagian keuangan di sebuah perusahaan cabang Berlin. Dia hanya
diizinkan untuk mengambil daftar proyek yang menjadi tanggung jawabnya.
Mengikuti pedoman perusahaan, Alice hanya diizinkan mengakses catatan dari
Jerman.
2. Bob ingin melihat gambaran umum sebuah buku horor di perpustakaan buku
digital. Untuk melakukan permintaan tersebut, Bob harus memiliki utang kurang
dari EUR 10 di perpustakaan dan memenuhi batasan usia buku yang diminta.
Contoh-contoh ini dibuat untuk mencakup akses ke satu objek dan juga akses ke
sekumpulan objek. Keduanya umumnya terjadi pada aplikasi berbasis layanan mikro
ketika menggunakan RESTful API.

3.1. ABNF untuk Kebijakan Otorisasi

Tujuan dari ABNF untuk kebijakan otorisasi adalah untuk menyediakan struktur
yang seragam untuk kebijakan otorisasi bahasa alami. Kebijakan otorisasi yang
ditetapkan menggunakan bahasa ini merupakan langkah peralihan sebelum penerapan
kebijakan ABAC menggunakan bahasa kebijakan yang sesuai.
Daftar 2 menyediakan kebijakan otorisasi untuk contoh yang sedang berjalan
menggunakan ABNF yang diperkenalkan di Daftar 3. Pada kebijakan otorisasi pertama,
yang ditunjukkan pada baris 2, subjek ingin melihat setiap proyek yang ditugaskan
kepadanya. Ada dua kondisi subjek untuk kebijakan ini. Kondisi pertama
membandingkan departemen subjek dengan sebuah nilai; kondisi kedua membandingkan
cabang tempat subjek bekerja dengan sebuah lokasi. Tindakan diatur ke DAPATKAN.
Karena sekumpulan proyek sedang diakses, teks setiap objek digunakan untuk mencatat
bahwa aturan otorisasi diterapkan pada setiap proyek yang merupakan bagian dari objek.
Objek disetel ke jalur HTTP tempat proyek dapat dijangkau (misalnya, /projects). Untuk
memeriksa kepemilikan proyek, ID subjek dibandingkan dengan atribut penerima hak
milik objek. Terakhir, lokasi tempat permintaan dibuat diperiksa, yang sama dengan
Jerman. Kebijakan otorisasi kedua mengevaluasi apakah hutang subjek kurang dari 10
dan tindakan yang dilakukan adalah DAPAT. Objeknya adalah objek tunggal yang terletak di jalur
/buku/{id}. Terakhir, peringkat atribut objek dibandingkan dengan usia subjek.
Untuk membuat bahasa kebijakan, pertama-tama kita harus mengidentifikasi aspek-
aspek yang dibutuhkan oleh ABAC. Menurut [29], kita perlu membahas aspek-aspek
subjek, tindakan, objek, dan atributnya. Karena kebijakan merupakan representasi dari
aturan dan hubungan, maka aturan juga harus didefinisikan. Selain itu, kondisi
lingkungan juga harus didefinisikan dalam bahasa kebijakan. Bahasa kebijakan disajikan
dalam Daftar 3. Struktur umum kebijakan otorisasi ditulis dalam bahasa alami dan
dengan demikian dapat dibaca oleh pengembang
Perangkat 410
Lunak 2023, 2

tanpa sepengetahuan sebelumnya. Baris 1 mewakili aturan ABNF awal dari kebijakan
otorisasi. Tujuannya adalah untuk mendefinisikan apa yang dapat dilakukan oleh subjek
terhadap suatu objek yang diberikan seperangkat kondisi.

Daftar 2. Contoh kebijakan otorisasi.

1 #KebijakanOtorisasi1
2 Sebuah subjek dengan subject.department == Finance AND subject.branch == Berlin
dapat melakukan aksi GET pada setiap objek di /projects dimana subject.id =
object.assignee AND environment.location == Germany
3 #Kebijakan Otorisasi2
4 Sebuah subjek dengan subject.debt < 10 dapat melakukan tindakan GET pada /book/{id}
IF object.rating <= subject.age

Daftar 3. Formulir Backus-Naur yang ditambah untuk kebijakan

otorisasi.

1 KebijakanOtorisasi = "Sebuah subjek " subAtribut " dapat melakukan tindakan " aksi
" pada " kondisi objekKeputusan
2 action = "GET" / "POST" / "PUT" / "PATCH" / "DELETE"
3 objek = * VChar
4 operator = "<" / "<=" / "==" / ">" / ">=" / "is" / "not" / "contains" / ..
5 atribut = *VCHAR
6 nilai = *VCHAR
7
8 subAtribut = "" / "dengan" subKondisi
9 subCond = "subjek." nilai operator atribut
10 subKondisi =/ subKondisi " AND " subKondisi / subKondisi " OR " subKondisi / " ( "
subKondisi " OR " subKondisi " ) " / " ( " subCond " AND " subCond " ) "
11
12 objectDecision = object / object "JIKA" / "setiap object dalam "object" yang ~"
13
14 kondisi = "" / kondisi " DAN " kondisi / kondisi " ATAU " kondisi / " ( " kondisi " ATAU
" kondisi " ) " / " ( " kondisi " DAN " kondisi " ) "
15 kondisi =/- "subjek. "operator atribut "objek. "atribut / "objek. "nilai operator atribut
16 kondisi =/- "lingkungan." nilai operator atribut

Aturan pertama disebut subAtribut dan digunakan untuk mengidentifikasi atribut subjek.
Sebuah sub-objek dapat tidak memiliki atribut atau satu atribut atau lebih. Pembedaan ini
dibuat di baris 8. Jika satu atribut subjek digunakan, aturan lain yang disebut subKondisi
digunakan. Seperti yang ditunjukkan pada baris 9, sebuah struktur untuk kondisi atribut
subjek disediakan. Atribut subjek dengan notasi "subjek." atribut. Atribut aturan ditunjukkan
pada baris 5. Dalam ABNF, *VCHAR memungkinkan kita untuk menulis kumpulan karakter
yang dapat dicetak (VCHAR) yang panjangnya sewenang-wenang (*). Subjek pada
atribut harus dibandingkan dengan sebuah nilai. Dengan demikian, operator aturan dan nilai
dibuat. Operator aturan disajikan pada baris 4. Operator ini berisi sekumpulan operator
perbandingan seperti <, >, atau ==. Terakhir, nilai aturan mirip dengan atribut aturan,
yang menampilkan jumlah karakter yang dapat dicetak secara sewenang-wenang. Dengan
menggunakan aturan-aturan ini, atribut subjek dapat dibandingkan dengan sebuah nilai.
Namun, jika beberapa atribut subjek diperlukan, subkondisi aturan yang digambarkan pada baris 9
tidak cukup. ABNF memungkinkan sebuah aturan untuk diperluas dengan menyediakan
alternatif kenaikan, yang disajikan dengan notasi "=/". Baris 10 menyajikan alternatif
untuk kondisi subjek yang menyediakan operator logika seperti AND dan OR.
Menerapkan operator logika memungkinkan pembuatan rantai pernyataan yang kompleks untuk
mendeskripsikan atribut subjek. Sebagai contoh, pernyataan (subject.age > 10 AND subject.age <
18) ATAU subject.age > 30 - membatasi akses dalam sebuah kebijakan pada rentang usia
tertentu.
Mengikuti atribut subjek, kebijakan otorisasi memiliki aksi aturan. Karena bahasa
kebijakan otorisasi dibuat untuk RESTful API, aksi aturan yang disajikan di baris 2
menyediakan operasi HTTP (misalnya, GET, POST). Menggunakan operasi HTTP
dalam kebijakan otorisasi memungkinkan penyederhanaan implementasi dalam bahasa
Perangkat 411
Lunak 2023, 2
kebijakan.
Perangkat 412
Lunak 2023, 2

Selanjutnya, objek perlu didefinisikan. Oleh karena itu, aturan objectDecision

digunakan. Dalam API REST-full, permintaan selalu dilakukan pada sumber daya tunggal
yang mengembalikan objek tunggal atau sekumpulan objek. Sebagai contoh, endpoint GET
/projects mengembalikan daftar proyek, sedangkan endpoint GET /projects/{id}
mengembalikan proyek tertentu. Perilaku ini harus diperhitungkan saat membuat kebijakan
ABAC. Secara umum, sebuah subjek hanya boleh melakukan tindakan (misalnya, melihat)
pada objek yang memiliki akses. Untuk itu, aturan objectDecision menyediakan tiga
alternatif. Pertama, permintaan hanya dilakukan untuk satu objek tanpa kondisi. Kedua,
permintaan dilakukan pada sebuah objek dengan kondisi yang dikarakterisasi dengan IF.
Ketiga, permintaan dilakukan pada sekumpulan objek yang ditandai dengan pernyataan
"setiap objek dalam "objek" yang". Serupa dengan definisi atribut dan nilai, objek aturan
(baris 3) mendefinisikan nama objek sebagai sekumpulan karakter yang dapat dicetak.
Terakhir, kondisi untuk keputusan akses harus didefinisikan. Untuk hal ini, ABNF
menyediakan kondisi aturan (baris 14 hingga 16). Serupa dengan kondisi atribut subjek,
kondisi objek dapat digabungkan menggunakan operasi logika seperti dan dan atau.
Selain itu, kondisi tersebut memungkinkan untuk membandingkan atribut subjek dengan
atribut objek, atau atribut objek dengan nilai tertentu. Kondisi-kondisi tersebut
menggunakan operator aturan dan nilai yang disajikan pada baris 4 dan 6. Terakhir,
kondisi lingkungan (baris 16) dapat dibuat dengan membandingkan atribut dengan nilai
tertentu.

3.2. Bahasa Persyaratan Otorisasi

Selama fase analisis proyek pengembangan perangkat lunak, persyaratan
fungsional dan non-fungsional dikumpulkan. Persyaratan fungsional menggambarkan
apa yang harus dapat dilakukan oleh sebuah sistem [42]. Pada tahap proyek ini, detail
yang tepat tidak didefinisikan dan agak kasar. Biasanya, detail ditambahkan selama fase
desain. Namun, selama analisis kebutuhan, penting untuk memikirkan tindakan apa
yang dapat dilakukan oleh pengguna dalam keadaan apa. Hal ini dapat dilakukan dengan
menggunakan kasus penggunaan [43]. Firesmith menyebut kumpulan persyaratan
tersebut sebagai persyaratan otorisasi [44].
Untuk mendukung penangkapan persyaratan otorisasi di seluruh tahap analisis, kami
mengusulkan formalisasi lebih lanjut menggunakan ABNF yang disajikan dalam Daftar
4. Dibandingkan dengan kebijakan otorisasi, ABNF untuk persyaratan otorisasi hanya
menyediakan struktur kasar yang dapat digunakan dalam fase desain untuk merumuskan
kebijakan otorisasi. Untuk tujuan ini, ABNF untuk persyaratan otorisasi dapat dilihat
sebagai bagian dari ABNF kebijakan otorisasi. Aturan awal dari persyaratan otorisasi
disajikan pada baris 1. Persyaratan otorisasi menyediakan struktur bahasa alami yang
mirip dengan [20]. Tujuan utama dari persyaratan otorisasi adalah untuk menangkap
tindakan, objek, dan kondisi. Dengan demikian, untuk masing-masing aspek ini, aturan
terpisah dibuat. Tindakan (baris 2) adalah karakter yang dapat dicetak dalam jumlah yang
sewenang-wenang (*VCHAR). Dibandingkan dengan kebijakan otorisasi, aksi dibuat
secara terbuka. Pada fase analisis, operasi HTTP tidak diketahui. Dengan demikian,
sebuah aksi bisa berupa penambahan atau pembaruan. Struktur objek (baris 3) sama
dengan aksi (yaitu, *VCHAR). Sebagai contoh, sebuah objek dapat berupa proyek atau
buku. Terakhir, kondisi bisa berupa sejumlah karakter (baris 5) atau gabungan beberapa
kondisi menggunakan operator logika and dan or.

Daftar 4. Formulir Backus-Naur yang ditambah untuk persyaratan otorisasi.

1 OtorisasiPersyaratan = "Subjek dapat melakukan tindakan " tindakan " pada objek " objek "
JIKA " kondisi
2 action = *VCHAR
3 objek = * VChar
4 kondisi = * VChar
5 kondisi =/ kondisi " DAN " kondisi / kondisi " ATAU " kondisi / " ( " kondisi " ATAU "
kondisi " ) "
Perangkat 413
Lunak 2023, 2

Daftar 5 berisi dua persyaratan otorisasi untuk contoh yang sedang berjalan.
Persyaratan otorisasi pertama disajikan di baris 2. Subjek hanya dapat melihat proyek
mereka jika mereka ditugaskan untuk proyek tersebut, bekerja di departemen
keuangan, dan melakukan permintaan dari Jerman. Dibandingkan dengan kebijakan
otorisasi yang disajikan pada Daftar 2, persyaratan otorisasi kurang formal dan
terutama menyusun konten artefak analisis. Persyaratan otorisasi kedua disajikan pada
baris 5. Seperti yang dapat dilihat dari persyaratan otorisasi, di seluruh tahap analisis,
nama-nama atribut yang tepat, misalnya, sebagai artefak desain yang diperlukan, belum
tersedia. Namun, persyaratan otorisasi memungkinkan pengumpulan persyaratan
selama fase analisis, yang kemudian dapat ditransfer ke kebijakan otorisasi.

Daftar 5. Persyaratan otorisasi yang patut dicontoh dengan menggunakan ABNF.

1 #Persyaratan Otorisasi1
2 Sebuah subjek dapat melakukan tindakan mengambil pada daftar objek proyek IF subjek
berada di departemen keuangan AND subjek ditugaskan ke proyek AND tindakan
dilakukan dari ~ Jerman
3
4 #Persyaratan Otorisasi2
5 Subjek dapat melakukan tindakan membaca pada buku objek JIKA utang subjek memiliki
utang kurang dari EUR 10 DAN subjek memenuhi batasan usia

3.3. Implementasi Kebijakan Otorisasi

Kebijakan otorisasi menggunakan ABNF yang disajikan dalam Daftar 3 dapat
diimplementasikan secara langsung dalam bahasa kebijakan. Kami menggunakan Open
Policy Agent (OPA), sebuah mesin kebijakan sumber terbuka yang didukung oleh Cloud
Native Computing Foundation (CNCF) [45]. OPA menyediakan bahasa kebijakan Rego,
yang memungkinkan kebijakan ditulis sebagai artefak kode [46]. Ketika menggunakan OPA
sebagai PDP, proxy seperti Envoy [47] atau Traefik [48] dapat digunakan sebagai PEP
karena menyediakan integrasi untuk OPA. Hal ini memungkinkan kita untuk mengakses
detail permintaan HTTP dalam format JSON.
Daftar 6 menyajikan struktur untuk mengimplementasikan kebijakan otorisasi.
Setiap kebijakan otorisasi dienkapsulasi oleh pernyataan allow (baris 1 dan 13), yang
menjadi benar jika semua pernyataan yang dilampirkan benar. Struktur dari kebijakan
otorisasi dapat ditransfer untuk mengimplementasikan kebijakan otorisasi di Rego. Baris
2 hingga 4 mengevaluasi atribut subjek. Kemudian, tindakan dievaluasi di baris 6 diikuti
oleh objek di baris 8. Terakhir, setiap kondisi dari kebijakan otorisasi dapat dievaluasi.

Daftar 6. Kebijakan otorisasi yang diterapkan di Rego.

1 mengizinkan {
2 Ketentuan Subjek # Ketentuan Subjek
3 subject.attribute1 == X
4 Y di subject.attribute2
5 # Action
6 action == input.attributes.request.http
7 # Object
8 objek := input.attributes.request.path
9 # Ketentuan
10 # kondisi1
11 data[object.id].owner == subject.id
12 # alternatif
13 response := http.send({
14 "method" : "GET",
15 "url": <PIP>
16 })
17 response.owner == subject.id
18 }
Perangkat 414
Lunak 2023, 2

Di Rego, dimungkinkan untuk mendefinisikan variabel di luar pernyataan allow.

Dalam kasus ini, subjek (baris 3) adalah variabel yang berisi atribut subjek, misalnya,
dengan mengekstrak konten JWT. Aksi dapat diterima dari variabel input (baris 6), yang
berisi konten permintaan HTTP yang dilakukan oleh klien (yaitu pengguna). Isi
permintaan HTTP disediakan oleh PEP (misalnya, Envoy). Pada baris 6, operasi HTTP diambil
dari variabel input.attributes.request.http. Pada baris 7 dan 8, objek dievaluasi dengan
mencocokkan jalur HTTP. Mulai dari baris 9, kondisi dievaluasi, misalnya, dengan
membandingkan pemilik objek dengan pengenal subjek (baris 11). Untuk melakukan
evaluasi, data atribut objek harus diketahui. Dalam ABAC, atribut disediakan oleh PIP
[29]. OPA menyediakan beberapa opsi untuk mengakses data atribut. Salah satu opsi
adalah menyimpan data yang diperlukan dalam format JSON di dalam OPA itu sendiri,
yang digunakan pada baris 11 melalui data variabel. Alternatif lainnya adalah melakukan
permintaan HTTP ke PIP khusus seperti yang ditampilkan pada baris 13 hingga 16.
Hasilnya kemudian dapat dibandingkan dengan pengenal subjek (baris 17).
Menggunakan fungsi pembantu di Rego memungkinkan pembuatan implementasi
kebijakan yang lebih canggih dengan membuat fungsi untuk logika umum yang dapat
digunakan kembali. Daftar 7 menunjukkan ikhtisar fungsi-fungsi pembantu. Sebagai
contoh, untuk mengidentifikasi subjek, JSON Web Token (JWT) dapat digunakan [21].
JWT dapat diverifikasi di Rego dengan memeriksa tanda tangannya. Klaim JWT dapat
diekstraksi dari payload JWT (baris 14 sampai 22). Hal ini memungkinkan pembuatan
pernyataan seperti subjectIsInFinanceDepartment (baris 5 sampai 7) yang dapat
digunakan dalam beberapa kebijakan. Contoh lain termasuk pernyataan untuk suatu
tindakan (baris 1 sampai 3) atau metode untuk penentuan penugasan proyek (baris 9
sampai 12). Dengan menggunakan fungsi-fungsi pembantu, kebijakan otorisasi dapat
disusun dengan cara yang lebih sederhana dan ringkas. Sebagai contoh, kebijakan
otorisasi yang dijelaskan pada Listing 2 diimplementasikan dengan menggunakan fungsi-
fungsi pembantu pada Listing 8.

Daftar 7. Fungsi-fungsi pembantu yang diimplementasikan di Rego.

1 actionIsGet {
2 "GET" = http_request.method
3 }
4
5 subjectIsInFinanceDepartment {
6 claims.department == "Keuangan"
7 }
8
9 subjectIsAssignedToProject {
10 input.parsed_path = ["projects", projectid]
11 data[projectid].assignee == claims.sub
12 }
13
14 klaim := muatan {
15 [_, payload, _] := io.jwt.decode(bearer_token)
16 }
17
18 bearer_token := t {
19 vs := http_request.headers.authorization
20 startwith(v, "Pembawa ")
21 t := substring(v, count("Pembawa "), -1)
22 }
Perangkat 415
Lunak 2023, 2

Daftar 8. Contoh implementasi kebijakan otorisasi dengan menggunakan fungsi pembantu.

1 #KebijakanOtorisasi1
2 mengizinkan {
3 subjekDiDepartemenKeuangan
4 subjekCabangIsBerlin
5 actionIsGET
6 objectIsProjects
7 subjekDitugaskanUntukProyek
8 lokasiIsGermany
9 }
10 #Kebijakan Otorisasi2
11 mengizinkan {
12 subjekHutangKurangDari10
13 actionIsGET
14 objectIsBooks
15 PeringkatObjekLebihKecilUmurSubjekSama
16 }

3.4. Integrasi Proses Pengembangan

Untuk mengintegrasikan otorisasi halus ke dalam pengembangan aplikasi berbasis
layanan mikro, proses pengembangan untuk membuat aplikasi semacam itu harus
disesuaikan. Pengembangan aplikasi semacam itu sangat individual dan akan bervariasi di antara
pengembang yang berbeda. Untuk mendukung pengembang dalam menggunakan artefak
otorisasi yang telah disajikan sebelumnya, kami mengusulkan sebuah ekstensi pada
proses pengembangan yang sudah ada.
Gambar 2 memberikan gambaran umum tentang proses pengembangan aplikasi
berbasis layanan mikro yang meliputi fase analisis, desain, dan implementasi serta
pengujian. Pengembangan aplikasi berbasis layanan mikro menciptakan artefak analisis
(misalnya, kasus penggunaan) selama fase analisis. Pada fase desain, artefak analisis
digunakan untuk menyusun aplikasi berbasis layanan mikro menjadi sekumpulan layanan
mikro [9]. Selain itu, artefak desain seperti spesifikasi API atau diagram kelas dibuat
untuk setiap layanan mikro. Terakhir, pada tahap implementasi dan pengujian, artefak
desain diimplementasikan dalam bahasa pemrograman dan diuji (misalnya, uji unit, uji
komponen, dan uji E2E) [49].

Implementasi
Analisis Desain
Layanan Mikro #1
dan
Layanan Mikro #1
Layanan Mikro #1 Pengujian
API Diagram Pengujian
Pengembanga Artefak
Layanan Mikro #1
Kode Sumber
Kelas
n Aplikasi Artefak Desain Kode Sumber
Analisis Spesifikasi
Layanan Tes
Mikro
Kebijakan Implementasi
Persyaratan Kebijakan
Otorisasi Implementas
Kebijakan
Perpanjangan Otorisasi Otorisasi i Kebijakan
Otorisasi

Tabel Dukungan
masukan

Gambar 2. Analisis dan desain aplikasi berbasis layanan mikro dengan artefak untuk perpanjangan
otorisasi.

Untuk memperluas pengembangan dengan otorisasi, setiap fase dilengkapi dengan

artefak otorisasi yang disajikan. Selama fase analisis, persyaratan otorisasi dibuat. Seperti
yang dijelaskan di Bagian 3.2, persyaratan otorisasi menyediakan
Perangkat 416
Lunak 2023, 2

struktur dasar untuk merumuskan persyaratan otorisasi dalam bahasa alami. Untuk
menulis kebijakan otorisasi seperti itu, artefak analisis dapat digunakan sebagai masukan, karena
artefak analisis harus mendefinisikan apa yang dapat dilakukan aplikasi dalam keadaan
apa [42]. Berdasarkan persyaratan otorisasi, kebijakan otorisasi dibuat untuk setiap wakil
mikro. Selain itu, kami mengusulkan penggunaan tabel dukungan yang berisi informasi
tentang atribut antara beberapa layanan mikro. Terakhir, kebijakan-kebijakan tersebut
diimplementasikan dalam tahap implementasi dan pengujian.
Untuk membuat artefak otorisasi yang disajikan pada Gambar 2, satu atau beberapa
langkah harus dilakukan di setiap fase pengembangan. Gambar 3 memberikan gambaran
umum tentang tugas-tugas yang harus dilakukan. Pada fase analisis, persyaratan otorisasi
harus dieksplorasi untuk memahami apa saja yang perlu diotorisasi. Hal ini dilakukan
dengan menerapkan proses pada artefak analisis yang ada untuk mengekstrak informasi
yang dibutuhkan. Pada fase desain, atribut yang diperlukan untuk menerapkan
persyaratan otorisasi dengan kebijakan ABAC diekstraksi dari artefak desain.
Selanjutnya, persyaratan otorisasi diubah menjadi kebijakan otorisasi. Terakhir, pada
tahap implementasi, kebijakan tersebut diimplementasikan di Rego. Kami mengusulkan
untuk mempertahankan struktur dalam integrasi otorisasi ke dalam pengembangan
dengan membuat satu kebijakan otorisasi untuk satu persyaratan otorisasi dan membuat
satu implementasi kebijakan untuk satu kebijakan otorisasi.

Artefak
Mengidentifika Analisis
si
Analisis
Subjek/Objek/Tindaka
n Identifikasi Kondisi
Persyaratan
Otorisasi
Identifikasi Kepemilikan Ekstraksi Atribut dari
Objek 1
Desain 1 Persyaratan Otorisasi
Merumuskan Persyaratan
Otorisasi Kebijakan Artefak Desain Peta
Otorisasi
1
Implementasi Merumuskan Kebijakan
dan Tes 1 Otorisasi
Implementa
si Kebijakan

Gambar 3. Pengembangan artefak otorisasi.

3.4.1. Analisis
Sisi kiri dari Gambar 3 menunjukkan proses derivasi untuk membuat kebutuhan
otorisasi. Dasar dari persyaratan otorisasi adalah artefak analisis dari pendekatan
rekayasa perangkat lunak. Kualitas dan kelengkapan persyaratan otorisasi sangat
bergantung pada informasi yang ada dalam artefak analisis. Langkah pertama adalah
mengidentifikasi aspek-aspek yang diperlukan dari ABAC. Seperti yang dijelaskan pada
Bagian 3.2, subjek, objek, dan tindakan perlu diidentifikasi. Kedua, kondisi untuk
permintaan akses harus didefinisikan. Hal ini termasuk kondisi yang terkait dengan
subjek, objek, atau lingkungan, yang harus diidentifikasi dari artefak analisis. Ketiga,
kepemilikan objek harus diidentifikasi; meskipun ini adalah kondisi itu sendiri,
kepemilikan adalah atribut penting untuk mengelola akses ke suatu objek [29]. Dengan
demikian, pengembang harus menentukan apakah pengguna tunggal atau kelompok besar
yang mengakses suatu objek. Bergantung pada hal ini, keputusan desain tentang
penempatan atribut harus dibuat dalam fase desain. Akhirnya, persyaratan otorisasi dapat
dirumuskan dengan menggunakan ABNF untuk persyaratan otorisasi.
Perangkat 417
Lunak 2023, 2

3.4.2. Desain
Setelah persyaratan otorisasi dibuat, aspek otorisasi harus dimasukkan ke dalam
desain aplikasi untuk mempertahankan struktur keseluruhan. Sisi kanan Gambar 3
mengilustrasikan tugas-tugas untuk membuat kebijakan otorisasi. Untuk setiap
persyaratan otorisasi yang dibuat pada tahap analisis, satu kebijakan otorisasi dibuat. Hal
ini memungkinkan kita untuk mempertahankan struktur selama pengembangan.
Selanjutnya, jika persyaratan otorisasi berubah, kebijakan otorisasi dan implementasi
kebijakan dapat diubah. Sebelum kebijakan otorisasi dapat diformulasikan, penghargaan
diekstraksi dari persyaratan otorisasi, seperti yang juga diusulkan dalam [20,38]. Kondisi
dari persyaratan otorisasi berisi nama-nama atribut. Sebagai contoh, kondisi usia subjek
lebih dari 13 tahun mengimplikasikan atribut usia subjek. Kondisi subjek ditugaskan ke
proyek menyiratkan atribut penerima tugas untuk proyek objek. Ekstraksi atribut berdasarkan
persyaratan otorisasi bersifat individual dan tergantung pada formulasi persyaratan
otorisasi ini. Langkah kedua adalah memetakan persyaratan otorisasi ke artefak desain
layanan mikro. Langkah ini diperlukan karena nama-nama yang digunakan mungkin
berbeda antara fase analisis dan fase desain, misalnya, karena pemangku kepentingan
yang berbeda yang bertanggung jawab untuk setiap fase. Sebagai contoh, diagram kelas
atau spesifikasi API dapat berisi atribut projectAssignee, sementara atribut tersebut hanya
diberi nama assignee dalam persyaratan otorisasi. Selain itu, nama-nama objek dapat bervariasi
di antara fase-fase tersebut. Sebagai contoh, sebuah objek disebut buku dalam analisis, disebut
BookEntity dalam diagram kelas, dan dapat diakses melalui titik akhir API /books/{id}.
Terakhir, kebijakan otorisasi dapat diformulasikan dengan menerapkan ABNF untuk
setiap komponen persyaratan otorisasi. Kami mengusulkan penggunaan tabel dukungan
untuk menyimpan data (misalnya, atribut dan contoh) yang diperlukan untuk perumusan
persyaratan otorisasi. Tabel-tabel tersebut memberikan gambaran umum untuk semua
pengembang yang berpartisipasi. Daftar atribut juga diusulkan oleh Brossard dkk. [20],
yang memperkenalkan tabel tunggal yang mencakup nama pendek, ruang nama, kategori,
tipe data, dan rentang nilai. Namun, dibandingkan dengan Brossard dkk., kami
mengusulkan penggunaan satu tabel pendukung untuk setiap jenis atribut (yaitu, subjek,
objek, dan lingkungan). Format untuk tabel dukungan objek dapat ditemukan pada Tabel 2
dan berisi empat baris: Yang pertama adalah objek, yang berisi nama objek seperti yang
ditemukan dalam artefak desain (misalnya, spesifikasi API) dari layanan mikro. Yang kedua
adalah jalur ke titik akhir REST dari layanan mikro yang menyediakan objek. Yang
ketiga adalah nama atribut seperti yang ditentukan dalam artefak desain. Keempat adalah
contoh nilai untuk atribut. Atribut untuk subjek dan lingkungan disimpan dalam tabel
terpisah. Tabel-tabel tersebut berisi nama atribut dan contoh
nilai untuk memberikan informasi kepada pengembang.

Tabel 2. Struktur tabel dukungan objek.

Objek Path Atribut Contoh

Proyek / proyek - -
Proyek /project/{id} menugaskan subject@mail.com
Buku /buku/{id} peringkat 12
... ... ... ...

3.4.3. Implementasi dan Penyebaran

Kebijakan otorisasi apa pun dapat diimplementasikan dalam bahasa kebijakan
otorisasi. Seperti yang dijelaskan di Bagian 3.3, kami mengusulkan implementasi
menggunakan bahasa kebijakan Rego. Untuk menerapkan layanan mikro dengan
ABAC, arsitektur penerapan perlu diperluas dengan komponen logis yang diperlukan
untuk menerapkan keputusan otorisasi. Gambar 4 menunjukkan arsitektur perangkat
lunak yang menyertakan komponen logis ABAC yang diperlukan. PEP berkomunikasi
dengan PDP, yang meminta data atribut yang diperlukan dari PIP. PEP memberlakukan
keputusan dan meneruskan permintaan ke layanan mikro. PAP memberikan kebijakan yang
diperlukan kepada PDP. Aspek perangkat lunak
Perangkat 418
Lunak 2023, 2

arsitektur untuk aplikasi berbasis layanan mikro membutuhkan pekerjaan tambahan di

masa mendatang. Hal ini memengaruhi jumlah PEP, PDP, atau PIP yang ada dalam
arsitektur, yang dapat memengaruhi skalabilitas atau konsumsi sumber daya secara
keseluruhan.

... Poin Administrasi Kebijakan

Poin Penegakan Kebijakan Titik Keputusan Kebijakan

Layanan mikro Poin Informasi Kebijakan

...

Gambar 4. Arsitektur perangkat lunak yang patut dicontoh termasuk komponen otorisasi logis.

4. Studi Kasus: Manajemen Armada

Untuk memvalidasi penggunaan artefak otorisasi dan perluasan proses
pengembangan yang diperkenalkan, kami melakukan studi kasus [50]. Dalam studi kasus
kami, kami mengembangkan aplikasi mobil terkoneksi yang menyediakan beberapa fungsi
bisnis. Salah satu fungsi bisnis adalah manajemen armada, yang dipilih sebagai contoh
untuk menggambarkan implementasi otorisasi yang sistematis di bagian ini. Arsitektur
yang ditargetkan dari aplikasi mobil terhubung adalah arsitektur layanan mikro.
Fungsionalitas bisnis pengelolaan armada disediakan oleh layanan mikro
FleetManagement.

4.1. Analisis
Untuk analisis kebutuhan, kami menerapkan kasus penggunaan sebagai artefak
analisis utama untuk merumuskan kebutuhan pengguna. Sebagai alternatif, jenis
artefak analisis kebutuhan lainnya dapat digunakan, asalkan mengandung informasi
yang diperlukan untuk otorisasi. Fungsionalitas layanan mikro FleetManagement
ditunjukkan dalam diagram kasus penggunaan yang disajikan pada Gambar 5. Secara
keseluruhan, terdapat dua aktor, FleetAdministrator dan Fleet-Manager, dan empat
kasus penggunaan. FleetAdministrator dapat membuat armada baru untuk
sekumpulan armada yang sudah ada. FleetManager dapat melihat gambaran umum armada
yang berafiliasi dengan mereka. Jika FleetManager memiliki armada yang berafiliasi,
mereka dapat melihat gambaran umum dari mobil-mobil di dalam armada. Sebuah
mobil dapat dihapus dari armada oleh FleetManager. Kasus penggunaan Melihat Armada
ditunjukkan pada Listing 9. Kondisi tambahan adalah bahwa permintaan harus
dilakukan dari lokasi yang sama di mana armada berada (baris 6). Kasus penggunaan
ini tidak menyertakan kondisi pasca yang relevan untuk otorisasi (baris 8). Alur utama
pada baris 10 dihilangkan. Namun, aktor meminta untuk melihat semua armada (langkah 1).
Akibatnya, sistem akan mencari armada milik aktor (langkah 2) dan menampilkan hasilnya
kepada aktor (langkah 3).
Perangkat 419
Lunak 2023, 2

Manajemen Armada

Tambahkan Armada
ke Armada

Meli Arma
Administrator
hat da
Armada
Meli Arm Ikhtisar
hat ada

"memper

panjang" Hapus Mobil

Manajer
Armada
dari Armada

Gambar 5. Diagram kasus penggunaan untuk sistem FleetManagement.

Daftar 9. Deskripsi kasus penggunaan "Lihat Armada".

1 Judul Lihat Armada

2 Aktor Utama: Manajer Armada
3 Aktor Sekunder: -
4 Prasyarat:
5 - Aktor hanya dapat melihat armada yang mereka kelola
6 - Permintaan dilakukan di lokasi yang sama dengan lokasi armada
7 Pasca kondisi:
8 - ...
9 Aliran Utama:
10 ...

Untuk setiap kasus penggunaan yang ditunjukkan pada diagram kasus

penggunaan pada Gambar 5, permintaan ulang otorisasi dibuat pada Daftar 10. Objek
utama, ditandai dengan warna biru, adalah armada dan sekumpulan armada yang
disebut armada. Aksi-aksi yang ditandai dengan warna kuning dapat diidentifikasi
sebagai tambah, lihat, dan hapus. Aktor utama ditandai dengan warna hijau. Syaratnya
adalah bahwa subjek adalah FleetAdministrator (baris 1) atau subjek adalah manajer
dari armada yang menjadi objek tindakan (baris 2 sampai 4). Untuk kasus penggunaan
Lihat Armada, hanya armada dari lokasi permintaan yang harus dikembalikan.

Daftar 10. Persyaratan otorisasi studi kasus.

1 AuthZReq-10: Sebuah subjek dapat melakukan aksi Menambah objek Fleets JIKA
subjek tersebut adalah FleetAdministrator
2 AuthZReq-20: Sebuah subjek dapat melakukan aksi Lihat pada objek Armada JIKA
subjek adalah FleetManager untuk Armada ini DAN lokasi sama dengan
lokasi Armada
3 AuthZReq-30: Sebuah subjek dapat melakukan aksi Lihat pada objek Armada JIKA subjek adalah
FleetManager untuk Armada ini
4 AuthZReq-40: Subjek dapat melakukan tindakan Hapus pada objek Armada JIKA subjek
adalah FleetManager untuk Armada ini

4.2. Desain
Diagram kelas untuk layanan mikro FleetManagement disajikan pada Gambar 6.
FleetCollection berisi sekumpulan armada. Selanjutnya, ini berisi fungsi-fungsi untuk
kasus penggunaan Tambahkan Armada ke Armada, Lihat Armada, dan Lihat Ikhtisar Armada.
Perangkat 420
Lunak 2023, 2
Armada berisi pengenal dan
Perangkat 421
Lunak 2023, 2

atribut untuk FleetManager, lokasi, dan sekumpulan mobil yang dikelola oleh armada.
Armada juga berisi fungsi untuk menghapus untuk kasus penggunaan Hapus Mobil dari
Armada.

Koleksi Armada
armada: Armada[]
AddFleetToFleets(Armada f)
ViewFleets(String fleetManager)
:Armada[] ViewFleetOverview(String
fleetid): Armada

1
*
Armada
fleetID: String Mobil
fleetManager: String vin: String
fleetLocation: String ..
1 *
mobil: Mobil[]
..
HapusMobil(Mobil c): Boolean

Gambar 6. Diagram kelas untuk layanan mikro FleetManagement.

Mengikuti perluasan proses yang diperkenalkan pada Bagian 3.4, atribut pertama
kali diekstrak dari persyaratan otorisasi sebelum kebijakan otorisasi dibuat. Tabel
dukungan digunakan untuk menyimpan atribut subjek dan objek yang diekstrak dan
memberikan gambaran umum yang koheren tentang atribut di antara para pengembang.
Tabel dukungan objek untuk studi kasus disajikan pada Tabel 3. Objek yang diidentifikasi
dari persyaratan otorisasi adalah armada dan armada yang masing-masing disebut
FleetCollection dan Fleet dalam diagram kelas. Objek FleetCollection tidak memiliki
atribut yang diperlukan untuk otorisasi. Objek Fleet memiliki atribut fleetManager yang
menyimpan pengenal subjek. Selanjutnya, atribut lokasi disebut fleetLocation dalam
diagram kelas. Jalur untuk objek FleetCollection dan Fleet berasal dari spesifikasi API
dan ditambahkan sebagai /fleets dan /fleets/{fleetID}, masing-masing.

Tabel 3. Tabel dukungan objek.

Objek Path Atribut Contoh

Koleksi Armada / armada - -
fleetManager subject@mail.com
Armada /fleets/{fleetID}
fleetLocation Jerman

Tabel 4 menyajikan tabel dukungan subjek, yang berisi atribut yang diperlukan oleh
persyaratan otorisasi. Karena persyaratan otorisasi mewajibkan pemeriksaan untuk
menentukan apakah subjek adalah FleetManager untuk armada (mis., AuthZReq-30),
sangat penting untuk mengidentifikasi subjek secara akurat. Ada beberapa opsi yang tersedia
untuk mengakses atribut subjek, yang bergantung pada teknologi yang digunakan. Selama
perancangan studi kasus, keputusan dibuat untuk menggunakan JWT yang disediakan
oleh Manajemen Identitas dan Akses (IAM). JWT berisi pengenal yang disebut sebagai sub,
yang sesuai dengan alamat email subjek. Hasilnya, sub atribut telah dimasukkan ke dalam
tabel dukungan subjek. Selain itu, untuk tujuan ilustrasi, sebuah contoh alamat email
telah disertakan dalam tabel dukungan. Mengingat bahwa kasus penggunaan
Menambahkan Armada ke Armada hanya dapat dieksekusi oleh FleetAdministrator,
maka perlu untuk menetapkan peran untuk identifikasi subjek. JWT juga dilengkapi
dengan bidang yang disebut peran, yang dapat mencakup penunjukan peran untuk
FleetAdministrator. Konfigurasi sistem IAM yang tepat sangat penting untuk
memastikan penyediaan peran yang sesuai. Dalam konteks studi kasus ini, peran
dilambangkan sebagai cs-fleetAdm, dan entri untuk peran telah dibuat dalam tabel
dukungan subjek. Mengingat sebuah subjek dapat memiliki beberapa peran, peran atribut
mencakup nilai contoh yang direpresentasikan menggunakan notasi larik yang diapit oleh
tanda kurung siku (yaitu, []). Atau,
Perangkat 422
Lunak 2023, 2

Atribut seperti departemen dapat digunakan jika semua karyawan dalam suatu departemen
dianggap sebagai administrator armada.

Tabel 4. Tabel dukungan subjek.

Atribut Contoh Nilai

sub fleet@manager.com
peran [cs-fleetAdm]
departemen Departemen Armada

Dengan menggunakan persyaratan otorisasi dan informasi yang ada di tabel

pendukung, kebijakan otorisasi dapat dirumuskan. Kebijakan otorisasi untuk setiap
persyaratan otorisasi disajikan dalam Daftar 11. Kebijakan otorisasi pertama, yang
ditunjukkan pada baris 1, membutuhkan peran atribut subjek, tetapi tidak ada kondisi
lain. Kebijakan otorisasi kedua bertujuan untuk mengembalikan sekumpulan armada
yang dapat diakses oleh subjek dengan mempertimbangkan lokasi. Untuk setiap armada,
kondisi apakah subjek adalah fleetManager dicentang. Kebijakan otorisasi pada baris 3
dan 4 juga mensyaratkan bahwa fleetManager sama dengan pengenal subjek untuk
melakukan operasi yang bersangkutan.

Daftar 11. Kebijakan otorisasi dari studi kasus.

1 AuthZPolicy-10: Subjek dengan FleetAdministrator di subject.roles POST pada objek /fleets

2 AuthZPolicy-20: Sebuah subjek dapat melakukan aksi GET pada setiap armada objek di objek
/fleets IF fleet.fleetManager == subject.sub AND environment.loc ==
fleet.fleetLocation
3 AuthZPolicy-30: Sebuah subjek dapat melakukan aksi GET pada objek /fleets/{fleetID} IF
armada. fleetManager == subject.id
4 AuthZPolicy-40: Sebuah subjek dapat melakukan tindakan DELETE pada objek /fleets/{fleetID}
IF armada. fleetManager == subject.id

4.3. Implementasi
Berdasarkan kebijakan otorisasi pada Daftar 11, kebijakan otorisasi
diimplementasikan dalam bahasa kebijakan Rego pada Daftar 12. Tepat satu kebijakan
Rego diimplementasikan untuk setiap kebijakan otorisasi bahasa alami. Kebijakan
otorisasi diwakili oleh pernyataan allow. Dalam sebuah pernyataan mengizinkan,
beberapa pernyataan harus dievaluasi menjadi benar agar kebijakan menjadi benar.
Dalam kebijakan yang disajikan dalam Daftar 12, nilai default untuk allow adalah false
(lihat baris 1). Seperti yang dijelaskan pada Bagian 3.3, fungsi pendukung digunakan
untuk mengimplementasikan kebijakan dengan melepaskan fungsionalitas umum.
Sebagai contoh, pernyataan actionIsPost memeriksa apakah operasi HTTP adalah POST.
Untuk kebijakan otorisasi pertama, hanya peran FleetAdministrator yang harus ada
di JWT subjek yang diwakili oleh pernyataan pembantu subjectIsFleetAdministrator.
Mengenai kebijakan otorisasi kedua, layanan mikro harus mengembalikan hanya armada
yang benar-benar dimiliki oleh subjek. Ada beberapa opsi untuk mengimplementasikan
perilaku seperti itu, tergantung pada tingkat eksternalisasi otorisasi dan manajemen
atribut. Dalam kasus kebijakan yang disajikan pada baris 7 hingga 12, header HTTP yang
berisi pengenal subjek dikembalikan. Ini disebut evaluasi parsial dan memungkinkan
layanan mikro yang sebenarnya untuk melakukan pemfilteran dan mengembalikan objek
armada yang benar (lihat [15]). Pilihan lainnya adalah memberi tahu layanan mikro objek
mana yang akan dikembalikan dengan melakukan penyaringan dengan Rego di dalam
OPA. Hal ini berpotensi menyebabkan latensi yang lebih tinggi dan peningkatan
kompleksitas ketika mengevaluasi permintaan yang lebih kompleks [46]. Dua kebijakan
otorisasi terakhir pada baris 13 dan 17 mengevaluasi operasi HTTP dan manajer armada,
yang disediakan oleh pernyataan pembantu (baris 21 sampai 25).
Perangkat 423
Lunak 2023, 2

Daftar 12. Kebijakan otorisasi yang diterapkan di Rego.

1 default izinkan = false

2 allow { # AuthZPolicy-10
3 subjekApakahAnggotaAngkatan
4 actionIsPost
5 objectIsFleets
6 }
7 allow { # AuthZPolicy-20
8 actionIsGet
9 objectIsFleets
10 object.fleetLocation == input.loc
11 response_headers_to_add["x-fleetManager] := subject.id
12 }
13 allow { # AuthZPolicy-30
14 actionIsGet
15 subjekApakahManajerAngkutan
16 }
17 allow { # AuthZPolicy-40
18 actionIsDelete
19 subjekApakahManajerAngkutan
20 }
21 subjectIsManagerOfFleet {
22 fleetID := getFleetID(input)
23 armada := data[fleetID]
24 subject.id == armada.fleetManager
25 }
26 ..

4.4. Excursus: Penerapan dan Evaluasi Kinerja

Bagian ini memberikan contoh arsitektur penerapan dan evaluasi kinerja melalui
pengujian latensi. Namun, kami tidak membahas proses penerapan aplikasi berbasis
layanan mikro termasuk komponen ABAC yang diperlukan. Pipeline Continuous
Integration and Continuous Deployment (CICD) dapat menyederhanakan proses
penyebaran ke cluster Kubernetes [51]. Mengingat bahwa Kubernetes mendeskripsikan
deployment dalam file manifes, biasanya dalam format YAML, manifes yang diperlukan
dapat dibuat dengan menggunakan diagram Helm di dalam pipeline [52]. Pendekatan ini
memungkinkan pembuatan konfigurasi penerapan tunggal yang tetap dapat beradaptasi
dengan beberapa layanan mikro. Selanjutnya, pipeline CICD dapat menerapkan bagan Helm
ke cluster menggunakan Helm (yaitu, "helm install"). Selain itu, setiap kebijakan otorisasi
yang diterapkan dapat secara otomatis disalin ke OPA oleh CICD pipeline.
Memanfaatkan pipeline CICD bersama dengan bagan Helm secara efektif
menyederhanakan kompleksitas penerapan dan konfigurasi, memfasilitasi peluncuran
perubahan baru dengan cepat, termasuk pembaruan kebijakan otorisasi.
Node yang disajikan pada Gambar 7 dapat digunakan dalam klaster Kubernetes dalam satu
pod Kubernetes. Hal ini dapat dilakukan dengan menggunakan pola sespan [53].
Layanan mikro FleetManagement berjalan sebagai kontainer utama, dan fungsinya
diperluas oleh sespan Envoy dan Open Policy Agent. Envoy proxy bertindak sebagai
PEP dan menyediakan plugin otorisasi yang dapat merutekan permintaan HTTP [54].
Envoy meneruskan permintaan ke Agen Kebijakan Terbuka PDP yang memegang
kebijakan otorisasi dari Daftar 12. OPA mengevaluasi permintaan dan mengembalikan
hasilnya ke Envoy. Bergantung pada hasilnya, permintaan diarahkan ke layanan mikro
FleetManagement. Jika hasilnya positif, Envoy dapat menambahkan header tambahan
pada permintaan jika diperlukan seperti pada kebijakan otorisasi di baris 11 pada Daftar
12. Node terakhir adalah load generator k6, yang memungkinkan penulisan tes beban
menggunakan JavaScript.
Perangkat 424
Lunak 2023, 2

"generator
beban" k6

Kubernetes Pod

HTTP "pdp"
Agen Kebijakan
Terbuka
Utusan HTTP2
Kebijakan
"semangat
"

Data
HTTP

"layanan mikro" Manajemen

Armada

Gambar 7. Penerapan studi kasus.

Untuk mengevaluasi dampak otorisasi terhadap latensi layanan mikro

FleetManagement, tiga implementasi dibandingkan. Pertama, sebagai dasar, layanan
mikro FleetManagement diimplementasikan tanpa otorisasi. Kedua, implementasi
otorisasi yang naif di dalam kode layanan mikro FleetManagement dijalankan. Ketiga,
otorisasi berbutir halus menggunakan envoy dan OPA diimplementasikan. Untuk uji
beban, kasus penggunaan Lihat Gambaran Umum Armada digunakan. Fungsionalitas
untuk uji beban diambil melalui titik akhir REST GET /fleets/{fleet-id}, masing-masing.
Layanan mikro FleetManage- ment diimplementasikan di Golang. Basis data PostgreSQL
digunakan untuk menyimpan data yang diperlukan oleh layanan mikro dan terdiri dari
dua tabel. Tabel pertama berisi informasi tentang armada, termasuk ID armada sebagai
kunci utama, bersama dengan manajer armada. Tabel kedua didedikasikan untuk
menyimpan data mobil, yang mencakup atribut seperti ID (kunci utama), Nomor
Identifikasi Kendaraan (VIN), merek, dan referensi ke armada yang sesuai melalui ID
armada (yaitu kunci asing). Basis data relasional dipilih untuk memodelkan hubungan antara
mobil dan armada. Pilihan lain, seperti MongoDB, juga dapat digunakan. Namun,
dampak dari basis data pada hasil keseluruhan harus sebanding. Basis data yang sama
digunakan di semua implementasi.
Uji beban menyajikan beban sintetis yang dimaksudkan untuk menghasilkan hasil
yang sebanding untuk implementasi yang berbeda. Tujuannya bukan untuk menguji
throughput maksimum layanan mikro, melainkan untuk menangkap latensi rata-rata
untuk implementasi otorisasi. Untuk memberikan hasil yang sebanding, setiap pengujian
beban berisi konfigurasi yang sama dan berlangsung selama 30 detik. Tingkat target
ditetapkan menjadi 100 permintaan per detik. Sumber daya dipilih sesuai dengan beban
sintetis yang diterapkan padanya. Untuk memastikan komparabilitas, setiap komponen
lingkungan uji beban, termasuk generator beban, dijalankan dalam kontainer dengan
serangkaian sumber daya tetap dalam cluster Kubernetes yang disajikan pada Tabel 5.
Selama pengujian beban, kontainer ditugaskan ke node Kubernetes yang sama untuk
memastikan latensi yang konsisten. Basis data PostgreSQL (v15.2) memiliki empat inti
CPU dan 20 GB RAM. Layanan mikro FleetMangement memiliki tiga inti CPU dan 5 GB
RAM. Proxy En- voy (v1.23) memiliki 2,5 inti CPU dan 5 GB RAM. OPA (v0.51.0)
memiliki 2,5 inti CPU dan 5 GB RAM. Terakhir, untuk menghindari kemacetan pada load
generator k6 (v0.43.1), enam core CPU dan 20 GB RAM dialokasikan. Selama pengujian
beban, beban pada sumber daya yang dialokasikan dipantau dan ternyata cukup untuk
melakukan 100 permintaan per detik tanpa mengalami kemacetan sumber daya. Basis
data diisi dengan 2.500 pengguna untuk percobaan ini. Setiap pengguna bertanggung jawab
atas empat armada, dengan total 10.000 armada. Setiap armada berisi empat mobil. Untuk
implementasi awal layanan mikro FleetManagement, database hanya berisi empat armada
dengan masing-masing empat mobil. Jika tidak, layanan mikro akan mengembalikan
semua 10.000 armada, menghasilkan hasil yang tak tertandingi.
Perangkat 425
Lunak 2023, 2

Tabel 5. Parameter untuk komponen pengujian beban.

Komponen CPU RAM Versi

Manajemen Armada 3 5 GB -
PostgreSQL 4 20 GB 15.2
Utusan 2.5 5 GB 1.23
OPA 2.5 5 GB 0.51.0
k6 6 20 GB 0.43.1

Hasil uji beban ditunjukkan pada Gambar 8. Sumbu x menunjukkan waktu yang
telah berlalu dari uji beban dalam detik. Sumbu y menunjukkan waktu respons uji beban
dalam milidetik. Untuk setiap arsitektur otorisasi, uji beban dijalankan sebanyak 25 kali
dan sebuah garis diplot yang menunjukkan waktu respons rata-rata untuk jangka waktu
tersebut. Median dipilih untuk menghilangkan pencilan dengan waktu respons yang
sangat tinggi atau rendah. Rona di sekitar setiap waktu respons median mewakili kuantil
90% (Q90) dari latensi respons. Tabel 6 melengkapi hasil yang ditunjukkan pada Gambar
8 dengan kuantil 95% (Q95) dan Permintaan Per Detik (RPS). Implementasi awal (biru)
tanpa otorisasi memiliki latensi rata-rata 2,2 ms. Otorisasi naif (oranye) memiliki latensi rata-
rata 8,152 ms, yang merupakan peningkatan yang signifikan dari implementasi awal.
Peningkatan latensi ini dapat dijelaskan oleh jumlah data yang lebih besar yang harus disaring
oleh layanan mikro. Selain itu, layanan mikro juga harus memvalidasi JWT untuk
mengesahkan permintaan. Dibandingkan dengan implementasi naif, otorisasi yang
dieksternalisasi (hijau) menambahkan ≈2 ms ke latensi rata-rata. Peningkatan ini
disebabkan oleh komponen tambahan yang diperlukan untuk otorisasi menggunakan
OPA.

14 Tidak ada
otorisasi Naif
12 OPA

10
Latensi (ms)

0 5 10 15 20 25 30
Waktu (s)

Gambar 8. Hasil uji beban yang dilakukan pada layanan mikro FleetManagement.

Tabel 6. Hasil yang menyajikan latensi respons untuk pengujian beban yang dijalankan.

Implementasi Median Q90 Q95 RPS

Tidak Ada
2,207 ms 2,579 ms 2,698 ms 100.001
Otorisasi
Naif 8,152 ms 10,831 ms 11,280 ms 100.012
OPA 10,243 ms 12,934 ms 13,594 ms 100.010

k6 mengumpulkan metrik tambahan, termasuk jumlah data yang dikirim dan

diterima selama uji beban. Metrik ini disajikan pada Tabel 7. Untuk semua implementasi,
≈77.500 pencarian ulang dikirim selama uji beban. Perbedaan terjadi pada data yang
dikirim oleh implementasi yang berbeda. Karena implementasi baseline tidak memerlukan
token JWT, maka over-load
Perangkat 426
Lunak 2023, 2

semua data yang dikirim hanya sebesar 7,36 MB. Sebaliknya, baik implementasi naif dan OPA
mengirimkan
26,89 MB dan 26,96 MB. Perbedaan data yang dikirim antara implementasi naif dan
OPA kemungkinan besar muncul karena pemilihan token JWT secara acak yang dapat
memiliki ukuran yang sedikit berbeda. Data yang diterima untuk implementasi baseline
dan naif berjumlah ≈62 MB. Dibandingkan dengan implementasi lainnya, implementasi
OPA mengembalikan data tambahan sebesar 4 MB. Hal ini kemungkinan disebabkan
oleh data tambahan (misalnya, header) yang ditambahkan oleh proxy Envoy. Sepanjang
uji beban untuk implementasi naif dan OPA, setiap permintaan individu mengalami
otorisasi yang sukses.

Tabel 7. Metrik lebih lanjut untuk uji beban yang dijalankan.

Total Permintaan
Implementasi Data Terkirim Data yang Diterima
HTTP
Tidak Ada Otorisasi 77501 7.36 MB 62.07 MB
Naif 77509 26.89 MB 62.25 MB
OPA 77508 26.96 MB 66.26 MB

5. Diskusi
Dalam makalah ini, kami menyelidiki otorisasi pengguna dalam pengembangan
aplikasi berbasis layanan mikro. Untuk menjawab bagaimana kebijakan ABAC dapat
dirumuskan secara sistematis (RQ1), kami mengusulkan ABNF untuk menyusun kebijakan
otorisasi. Metodologi menggunakan ABNF memungkinkan seseorang untuk membuat
kebijakan otorisasi dengan menyusun aspek-aspek ABAC untuk mengotorisasi
permintaan pengguna. Hal ini termasuk subjek, objek, tindakan, dan atribut masing-
masing. Ini menyediakan artefak bahasa alami bagi pengembang. Persyaratan otorisasi
adalah artefak teknologi-agnostik menengah. Untuk perumusan persyaratan otorisasi
(RQ2), sintaks untuk persyaratan otorisasi diperkenalkan untuk menangkap aspek
otorisasi selama fase analisis persyaratan. Persyaratan otorisasi diformulasikan
menggunakan ABNF; sementara proses menurunkan persyaratan otorisasi akan sangat
individual dan bergantung pada pemangku kepentingan individu, persyaratan otorisasi
menyediakan struktur di antara para pengembang. Selain itu, dengan menggunakan
persyaratan otorisasi, memungkinkan penurunan lebih lanjut dari kebijakan otorisasi.
Untuk menerapkan kebijakan otorisasi secara sistematis (RQ3), kami mengusulkan
implementasi sistematis dengan menggunakan OPA dan bahasa kebijakan sebagai kode,
Rego. Dengan menggunakan kebijakan otorisasi yang didefinisikan dengan ABNF kami,
konten implementasi otorisasi dapat diturunkan selangkah demi selangkah. Untuk
menjawab integrasi otorisasi yang sistematis ke dalam pengembangan aplikasi berbasis
layanan mikro (RQ4), kami mengusulkan perluasan otorisasi ke pendekatan
pengembangan umum untuk aplikasi berbasis layanan mikro. Perpanjangan ini berkisar
dari analisis hingga fase implementasi dan pengujian dan menempatkan artefak otorisasi
yang diperkenalkan di masing-masing fase. Selain itu, sebuah prosedur untuk
menurunkan artefak otorisasi diperkenalkan.
Dengan melakukan pendekatan yang diperkenalkan dalam sebuah studi kasus, kami
menunjukkan bahwa pendekatan ini layak dengan menggunakan diagram kasus
penggunaan UML dan deskripsi kasus penggunaan. Selain itu, kami menyajikan
perbandingan antara implementasi otorisasi, yang menunjukkan bahwa eksternalisasi
logika otorisasi dari layanan mikro menggunakan OPA dan Envoy adalah pilihan
yang layak. Peningkatan latensi secara keseluruhan dapat diterima dan tidak akan
menghalangi kinerja aplikasi berbasis layanan mikro.
Dibandingkan dengan karya sebelumnya tentang otorisasi dalam aplikasi berbasis
layanan mikro, yang mempertahankan fokus utama teknis dalam melakukan otorisasi,
kami menyediakan pendekatan sistematis untuk membuat artefak otorisasi [14,15].
Pendekatan ini dapat mendukung pengembang dalam mengurangi kompleksitas ABAC
yang dilaporkan [28] sambil mendapatkan pemahaman yang seragam tentang apa yang
harus diotorisasi. Pembuatan kebijakan berdasarkan model UML adalah area penelitian
yang menarik [40]. Namun demikian, untuk membuat model berkualitas tinggi,
Perangkat 427
Lunak 2023, 2
pengembang harus memiliki pemahaman yang kuat tentang apa yang harus diotorisasi,
dimulai dari analisis persyaratan. Memiliki artefak otorisasi persyaratan khusus akan
memberikan dukungan dan mencegah integrasi otorisasi sebagai renungan. Dengan
munculnya teknologi besar yang canggih
Perangkat 428
Lunak 2023, 2

model bahasa seperti ChatGPT, perumusan kebijakan otorisasi, seperti yang diuraikan
dalam pendekatan oleh [39], kemungkinan akan menjadi lebih canggih dan dapat
diandalkan. Namun, mengingat bahwa otorisasi adalah aspek yang sangat sensitif dalam
hal keamanan, faktor manusia (yaitu, pengembang) kemungkinan akan tetap menonjol.
Hal ini, pada gilirannya, menggarisbawahi pentingnya memiliki pemahaman yang baik
tentang apa yang membutuhkan otorisasi.

5.1. Ancaman terhadap Validitas

Sesuai dengan penelitian yang dilakukan oleh Wohlin dkk. [50], kami mengakui
dan mengatasi ancaman-ancaman berikut terhadap validitas sehubungan dengan
rekayasa perangkat lunak empiris dan implementasi temuan kami dalam studi kasus
khusus kami.

Validitas Konstruk. Perhatian utama terkait konstruksi studi kasus terletak pada potensi
kurangnya kompleksitas secara keseluruhan. Ada kemungkinan bahwa contoh yang
diberikan mungkin terlalu kecil, sehingga mengabaikan kasus-kasus tertentu yang tidak
dipertimbangkan selama pembuatan persyaratan otorisasi atau kebijakan otorisasi.
Hal ini dapat berdampak pada kelengkapan dan efektivitas kebijakan otorisasi yang
diturunkan. Dalam kasus ini, ABNF dari persyaratan otorisasi atau kebijakan
otorisasi tidak memiliki kelengkapan dan ABNF yang bersangkutan dapat
diperpanjang.
Validitas Internal. Selama pengembangan kebijakan otorisasi, terdapat ketergantungan
yang kuat antara berbagai artefak otorisasi; meskipun saling ketergantungan ini
diperlukan untuk mendapatkan kebijakan otorisasi yang efektif, artefak analisis
yang tidak benar atau tidak terdefinisi dengan baik dapat menghasilkan kebijakan
yang tidak memadai, misalnya, kondisi yang tidak terpenuhi. Oleh karena itu,
pengalaman dan kemahiran pengembang dalam melakukan analisis persyaratan
yang menyeluruh dan tepat menjadi ancaman bagi validitas internal.
Validitas Eksternal. Keberhasilan penerapan kebijakan otorisasi dalam konteks eksternal
bergantung pada kesamaan struktur proses pengembangan. Namun, variasi
dalam proses pengembangan, termasuk pembuatan artefak pengembangan,
mungkin ada. Akibatnya, artefak tertentu yang diperlukan oleh proses tersebut
mungkin tidak ada, dan adopsi metode pengembangan yang gesit seperti Scrum
berpotensi berdampak pada pengembangan kebijakan. Meskipun dimungkinkan
untuk mengadaptasi proses ke pendekatan pengembangan layanan mikro yang
berbeda, penurunan kebijakan otorisasi tidak akan langsung dan akan
memerlukan modifikasi.
Keandalan. Konsistensi hasil ketika menerapkan ekstensi otorisasi pada proses
pengembangan idealnya tidak bergantung pada pengembang individu. Namun,
karena adanya keputusan subjektif di sepanjang proses (misalnya, struktur aplikasi
dan konvensi penamaan untuk artefak pengembangan), pengembang yang berbeda
dapat memberikan hasil yang berbeda-beda. Namun demikian, jumlah keseluruhan
kebijakan harus tetap konstan, karena prinsip pelestarian struktur memastikan
bahwa setiap persyaratan otorisasi pada akhirnya sesuai dengan satu kebijakan
otorisasi yang diimplementasikan. Namun, jumlah persyaratan otorisasi akan
tunduk pada masing-masing pengembang, karena penurunan persyaratan otorisasi
tidak ditentukan dan tergantung pada analisis persyaratan.

5.2. Keterbatasan
Makalah ini mengasumsikan pendekatan pengembangan terstruktur untuk
aplikasi berbasis layanan mikro. Definisi artefak analisis adalah topik yang sangat
individual. Oleh karena itu, penurunan persyaratan otorisasi juga sangat individual,
yang akan mengarah pada hasil yang berbeda di antara para pengembang. Artefak
analisis harus berisi semua informasi yang diperlukan mengenai otorisasi. Lebih
lanjut, perluasan proses pengembangan yang diusulkan tidak dapat memberikan solusi
untuk setiap kasus tepi. Namun, ini menyediakan struktur yang dapat diperluas dengan
artefak atau turunan yang sesuai. Lebih jauh lagi, ABNF dan Rego mengizinkan
seseorang untuk menulis kebijakan dengan kompleksitas yang berubah-ubah. Dalam
Perangkat 429
Lunak 2023, 2
kondisi saat ini, penggunaan REST API membatasi tindakan yang mungkin
dilakukan saat membuat kebijakan otorisasi. Paradigma API lain seperti gRPC atau
GraphQL tidak didukung oleh hasil penelitian ini.
Perangkat 430
Lunak 2023, 2

bekerja. Untuk menggunakan API tersebut, perubahan pada artefak otorisasi harus
diselidiki dan (mungkin) dilakukan.
Keseluruhan kompleksitas dalam memperkenalkan kontrol akses berbasis atribut ke aplikasi
berbasis layanan mikro meningkat dibandingkan dengan menyematkan keputusan otorisasi
ke dalam kode layanan mikro. Dengan demikian, muncul pertanyaan apakah
menggunakan ABAC merupakan pilihan yang sesuai. Untuk proyek-proyek kecil,
kompleksitas ABAC kemungkinan besar akan lebih besar daripada manfaatnya. Ketika
bekerja dalam proyek perusahaan dengan tim yang besar, kompleksitas secara
keseluruhan akan memiliki efek yang kurang signifikan terhadap beban kerja secara
keseluruhan.
Dalam skenario perusahaan di dunia nyata, kompleksitas yang diperkenalkan oleh ABAC
dalam arsitektur mikro dapat menghadirkan beberapa tantangan dalam operasi; sementara
ekskursi hanya menghadirkan sedikit peningkatan dalam latensi tambahan, pengelolaan
arsitektur secara keseluruhan kemungkinan akan meningkat karena adanya komponen
tambahan. Hal ini juga akan berdampak pada faktor-faktor seperti skalabilitas dan
pemeliharaan, yang sangat relevan dalam lingkungan cloud modern.

5.3. Pekerjaan di Masa Depan

Untuk lebih mendukung pengembang yang menggunakan pendekatan yang
disajikan dalam makalah ini, otomatisasi proses harus diselidiki untuk mengurangi
kompleksitas secara keseluruhan. Sebagai contoh, mengeksplorasi pembuatan otomatis
persyaratan otorisasi yang berasal dari deskripsi kasus penggunaan dapat menjadi sesuatu
yang berharga. Hal ini akan membutuhkan pemrosesan bahasa alami untuk
mengidentifikasi aspek-aspek yang relevan untuk otorisasi seperti subjek, objek, atau
kondisi. Selain itu, pembuatan kebijakan otorisasi berdasarkan persyaratan otorisasi juga
harus diselidiki karena struktur ABNF serupa. Hal ini juga dapat mencakup pembuatan
tabel dukungan. Terakhir, kita harus mempelajari eksplorasi implementasi Rego yang
dihasilkan dari kebijakan otorisasi terstruktur. Dengan cara ini, pengembang tidak
memerlukan pemahaman yang luas tentang Rego.
Untuk mengimplementasikan pendekatan yang diusulkan dalam lingkungan
perusahaan yang sudah mencakup berbagai protokol, alat, dan praktik keamanan yang
sudah mapan, diperlukan penelitian tambahan. Sebagai contoh, penggunaan atribut
subjek kemungkinan besar akan bergantung pada solusi IAM yang ada, yang secara
bersamaan berfungsi sebagai sarana untuk otentikasi. Dalam studi kasus, kami
menggunakan token JWT yang dikeluarkan oleh penyedia OAuth. Dengan demikian,
mengeksplorasi potensi penggabungan protokol lain, seperti Security Assertion Markup
Language (SAML) yang digunakan secara luas dalam konteks perusahaan, harus dibahas
dalam penelitian di masa depan.
Selain itu, kami telah mengidentifikasi tiga tantangan untuk berhasil
mengintegrasikan au- thorisasi pengguna ke dalam pengembangan aplikasi berbasis
layanan mikro. Tantangan-tantangan ini harus diatasi dalam pekerjaan di masa depan.
Pertama, untuk melakukan otorisasi berdasarkan ABAC, atribut-atribut sangat penting
dan harus diketahui. Hal ini biasanya dilakukan melalui Policy Information Point. Ketika
menggunakan Agen Kebijakan Terbuka sebagai PEP, akses ke data atribut yang
diperlukan untuk otorisasi harus diatur. Hal ini menimbulkan beberapa pertanyaan,
seperti di mana menyimpan data atribut, bagaimana cara mengakses data, dan seberapa
mutakhir data t e r s e b u t . Dalam konteks ini, hubungan antara logika bisnis dan logika
otorisasi harus diselidiki. Tergantung pada tingkat penggabungan yang diinginkan,
komponen yang terlibat dan arsitektur keseluruhan dapat berubah. Untuk
mendistribusikan perubahan atribut dalam arsitektur, komponen tambahan mungkin
diperlukan. Kedua, ada beberapa cara untuk mengintegrasikan komponen ABAC yang
diperlukan ke dalam penerapan aplikasi berbasis layanan mikro. Sebagai contoh, proxy
API tunggal dapat digunakan sebagai titik penegakan kebijakan untuk semua layanan
mikro. Sebaliknya, contoh penerapan yang disajikan pada Gambar 7 memiliki satu PEP
dan PDP untuk setiap penerapan layanan mikro. Hal ini dapat berimplikasi pada penskalaan,
serta ketersediaan dan topikalitas atribut di berbagai penerapan. Dengan demikian,
penelitian di masa depan harus mengeksplorasi arsitektur penerapan yang berbeda untuk
otorisasi dalam aplikasi berbasis layanan mikro. Ketiga, publikasi ini berfokus pada
Perangkat 431
Lunak 2023, 2
otorisasi pengguna. Namun, dalam arsitektur layanan mikro, permintaan antar layanan
mikro juga perlu diotorisasi. Hal ini sangat penting ketika mengimplementasikan
arsitektur zero-trust yang membutuhkan penghapusan kepercayaan implisit di antara layanan
mikro [55]. Antara l a i n , layanan ke layanan
Perangkat 432
Lunak 2023, 2

Otorisasi layanan memerlukan penentuan sumber daya apa yang dapat diakses oleh layanan mikro
dan siapa yang memiliki sumber daya tersebut. Dalam konteks ABAC, permintaan yang
dilakukan ke komponen otorisasi (misalnya, PIP) juga harus diotorisasi.

6. Kesimpulan
Pengembangan aplikasi berbasis layanan mikro dan penggunaan platform cloud
untuk mendistribusikannya telah menjadi praktik yang mapan dalam rekayasa perangkat
lunak modern. Namun, integrasi mekanisme keamanan seperti autentikasi dan otorisasi
tetap menjadi tantangan utama dalam pengembangan aplikasi tersebut.
Dalam makalah ini, kami mengusulkan sintaks untuk persyaratan otorisasi dan
kebijakan otorisasi serta proses top-down yang sistematis untuk integrasi otorisasi ke
dalam pengembangan aplikasi berbasis layanan mikro. Untuk menerapkan otorisasi
pengguna yang komprehensif, keputusan otorisasi yang baik harus dibuat, misalnya,
memberikan akses ke sebuah objek hanya untuk pengguna tertentu. Untuk menegakkan
keputusan tersebut, ABAC digunakan dengan proses yang sistematis. ABAC dan
mekanisme yang dibutuhkan sesuai dengan gaya arsitektur layanan mikro terdistribusi
dengan memisahkan komponen-komponen yang diperlukan. Hal ini memungkinkan
eksternalisasi otorisasi untuk layanan mikro dengan menghapus logika otorisasi dari
implementasi layanan mikro, yang pada gilirannya mengurangi layanan mikro untuk
menyediakan fungsionalitas bisnis intinya. Selain itu, eksternalisasi memungkinkan aspek
otorisasi diubah tanpa harus mengubah logika layanan mikro, sehingga memberikan
fleksibilitas yang lebih besar. Pengembangan otorisasi mencakup semua fase
pengembangan dan memungkinkan kebijakan otorisasi diturunkan dari artefak
pengembangan yang ada. Pada fase analisis, persyaratan otorisasi dibuat. Berdasarkan
persyaratan otorisasi, kebijakan otorisasi dibuat pada fase desain dengan menggunakan
tabel dukungan. Terakhir, pada fase implementasi, kebijakan otorisasi diimplementasikan
di Rego. Dengan melakukan hal ini, kami mengatasi masalah yang secara inheren
kompleks dalam mengintegrasikan otorisasi berbutir halus ke dalam aplikasi berbasis
layanan mikro. Pendekatan kami dapat menjadi titik awal bagi para pengembang
perangkat lunak untuk menangani topik ini secara sistematis untuk menciptakan
perangkat lunak yang andal dan aman.

Kontribusi Penulis: Konseptualisasi, NS dan SA; metodologi, NS; perangkat lunak, NS; validasi,
NS; investigasi, NS; kurasi data, NS; penyusunan draf awal, NS; tinjauan dan penyuntingan, NS;
supervisi, SA; administrasi proyek, SA. Semua penulis telah membaca dan menyetujui versi naskah
yang diterbitkan.
Pendanaan: Penelitian ini tidak menerima dana eksternal.
Pernyataan Dewan Peninjau Institusi: Tidak berlaku.
Pernyataan Persetujuan Berdasarkan Informasi
(Informed Consent): Tidak berlaku.
Pernyataan Ketersediaan Data: Data yang disajikan dalam penelitian ini tersedia secara terbuka di
KITopen di https://doi.org/10.35097/1744.
Ucapan terima kasih: Para penulis mengucapkan terima kasih kepada Rudy Ailabouni dan David
Boschert atas diskusi yang berharga dan kontribusinya terhadap karya ini.
Konflik Kepentingan: Para penulis menyatakan tidak memiliki konflik kepentingan.

Singkatan
Singkatan-singkatan berikut ini digunakan dalam naskah ini:

ABAC Kontrol Akses Berbasis Atribut

ABNF Augmented Backus-Naur Form
API Antarmuka Pemrograman Aplikasi
BNF Formulir Backus-Naur
CICD Integrasi Berkelanjutan Penerapan Berkelanjutan
Perangkat 433
Lunak 2023, 2

CNCF Cloud Native Computing Foundation

CRLF Umpan Jalur Pengangkutan Kembali
CRUD Buat Baca Perbarui Hapus
IAM Manajemen Identitas dan Akses
JWT Token Web JSON
NLP Kebijakan Bahasa Alami
OPA Agen Kebijakan
Terbuka
PAP Titik Administrasi Kebijakan
PDP Titik Keputusan
Kebijakan PEP Titik Penegakan
Kebijakan PIP Titik Informasi
Kebijakan
Q9090% Kuantil
Q9595% Kuantil
RBAC Kontrol Akses Berbasis Peran
REST Representational State Transfer
RPC Panggilan Prosedur Jarak Jauh
RPS Permintaan Per Detik
SAML Bahasa Markup Penegasan
Keamanan UML Bahasa Pemodelan Terpadu
NIK Nomor Identifikasi Kendaraan
XACML Bahasa Markup Kontrol Akses yang Dapat Diperluas

Referensi
1. Swoyer, M.; Loukides, S. Adopsi Layanan Mikro pada tahun 2020. Tersedia secara online:
https://www.oreilly.com/radar/microservices- adoption-in-2020/ (diakses pada tanggal 20 Juni 2023).
2. Berardi, D.; Giallorenzo, S.; Mauro, J.; Melis, A.; Montesi, F.; Prandini, M. Keamanan Layanan Mikro: Tinjauan Literatur yang
Sistematis.
PeerJ Comput. Sains. 2022, 7, e779. CrossRef] [PubMed] [PubMed]
3. solo.io. Tren Adopsi Layanan Mikro, Kubernetes, dan Istio-2022. Tersedia secara online: https://www.solo.io/resources/
infographic/microservices-kubernetes-and-istio-2022-adoption-trends/pdf/ (diakses pada tanggal 24 Agustus 2023).
4. Newman, S. Membangun Layanan Mikro: Merancang Sistem Berbutir Halus, 1st ed.; O'Reilly Media: Beijing, Cina; Sebastopol,
CA, USA, 2015.
5. Fielding, R.T. Gaya Arsitektur dan Desain Arsitektur Perangkat Lunak berbasis Jaringan. Tesis Ph.D., University of
California, Irvine, CA, USA, 2000.
6. Birrell, A.D.; Nelson, B.J. Menerapkan Panggilan Prosedur Jarak Jauh. ACM Trans. Comput. Syst. 1984, 2, 39-59. [CrossRef]
7. Inisiatif API Terbuka. Spesifikasi API Terbuka-v3.1.0. Tersedia secara online: https://spec.openapis.org/oas/v3.1.0 (diakses
pada 24 Agustus 2023).
8. Google LLC Semua. Dokumentasi Penyangga Protokol. Tersedia secara online: https://protobuf.dev/programming-
guides/proto3/ (diakses pada 24 Agustus 2023).
9. Hippchen, B.; Giessler, P.; Steinegger, R.H.; Schneider, M.; Abeck, S. Merancang Aplikasi Berbasis Layanan Mikro dengan
Menggunakan Pendekatan Desain Berbasis Domain . Int. J. Adv. Softw. 2017, 10, 432-445.
10. Sidler, J.; Braun, E.; Schmitt, C.; Schlachter, T.; Hagenmeyer, V. Arsitektur Berbasis Layanan Mikro untuk Integrasi Backend
Data dan Aplikasi Dasbor dalam Domain Energi dan Lingkungan. Dalam Kemajuan dan Tren Baru dalam Informatika
Lingkungan; Wohlgemuth, V., Naumann, S., Behrens, G., Arndt, HK, Eds.; Penerbitan Internasional Springer: Cham, Swiss, 2022; hlm.
37 - 48. [CrossRef]
11. Yayasan OWASP. OWASP Top 10:2021. Tersedia secara online: https://owasp.org/Top10/ (diakses pada 15 Juli 2023).
12. de Almeida, M.G.; Canedo, E.D. Otentikasi dan Otorisasi dalam Arsitektur Layanan Mikro: Tinjauan Literatur Sistematis .
Appl. Appl. Sci. 2022, 12, 3023. [CrossRef]
13. Gollmann, D. Keamanan Komputer. WIREs Comput. Stat. 2010, 2, 544 - 554. [CrossRef]
14. Nehme, A.; Jesus, V.; Mahbub, K.; Abdallah, A. Kontrol Akses Berbutir Halus untuk Layanan Mikro. Dalam Prosiding
Simposium Internasional ke-11 (FPS 2018), Montreal, QC, Kanada, 13-15 November 2018; Zincir-Heywood, N., Bonfante, G., Debbabi,
M., Garcia-Alfaro, J., Eds.; Penerbitan Internasional Springer: Cham, Swiss, 2019; Volume 11358, hlm. 285-300.
15. Sauwens, M.; Heydari Beni, E.; Jannes, K.; Lagaisse, B.; Joosen, W. ThunQ: Middleware Otorisasi Terdistribusi dan Mendalam
untuk Penegakan Kebijakan Awal dan Malas dalam Aplikasi Layanan Mikro. Dalam Prosiding Konferensi Internasional ke-19
(ICSOC 2021), Acara Virtual, 22-25 November 2021; Hacid, H., Kao, O., Mecella, M., Moha, N., Paik, H.Y., Eds.; Springer
International Penerbitan: Cham, Swiss, 2021; Volume 13121, hlm. 204-220.
16. Yarygina, T.; Bagge, A.H. Mengatasi Tantangan Keamanan dalam Arsitektur Layanan Mikro. Dalam Prosiding IEEE 2018
Simposium Rekayasa Sistem Berorientasi Layanan (SOSE), Bamberg, Jerman, 26 - 29 Maret 2018; hlm. 11 - 20. [CrossRef]
17. Devanbu, P.; Stubblebine, S. Rekayasa Perangkat Lunak untuk Keamanan: Sebuah Peta Jalan. Dalam Prosiding Konferensi
Masa Depan Rekayasa Perangkat Lunak, Limerick, Irlandia, 4-11 Juni 2000; hal. 227-239.
Perangkat 434
Lunak 2023, 2

18. Busch, M.; Koch, N.; Masi, M.; Pugliese, R.; Tiezzi, F. Menuju Pengembangan Kebijakan Kontrol Akses Berbasis Model
untuk Aplikasi Web. Dalam Prosiding Lokakarya Keamanan Berbasis Model, Innsbruck, Austria, 1-5 Oktober 2012; hlm. 1 -
6. [CrossRef]
19. Zolotas, C.; Chatzidimitriou, K.C.; Symeonidis, A.L. RESTsec: Platform Kode Rendah untuk Menghasilkan Layanan Secure by
Design Enterprise . Enterp. Inf. Syst. 2018, 12, 1007-1033. [CrossRef]
20. Brossard, D.; Gebel, G.; Berg, M. Pendekatan Sistematis untuk Menerapkan ABAC. Dalam Prosiding Lokakarya ACM 2nd di
Kontrol Akses Berbasis Atribut-ABAC '17, Scottsdale, AZ, AS, 24 Maret 2017; hlm. 53 - 59. [CrossRef]
21. RFC 7519; JSON Web Token (JWT). Gugus Tugas Rekayasa Internet, Fremont, CA, AS, 2015. Tersedia secara online: https:
//www.rfc-editor.org/rfc/rfc7519 (diakses pada 15 Juni 2023). [CrossRef]
22. Sandhu, R.; Samarati, P. Kontrol Akses: Prinsip dan Praktik. IEEE Commun. Mag. 1994, 32, 40-48. [CrossRef]
23. Kizza, J.M. Kontrol Akses dan Otorisasi. Dalam Panduan Keamanan Jaringan Komputer; Springer: London, Inggris, 2015; hlm.
185 - 204. [CrossRef]
24. Goyal, V.; Pandey, O.; Sahai, A.; Waters, B. Enkripsi Berbasis Atribut untuk Kontrol Akses Berfokus pada Data Terenkripsi.
Dalam Prosiding Konferensi ACM ke-13 tentang Keamanan Komputer dan Komunikasi, Alexandria, VA, AS, 30 Oktober
2006;
Hal. 89-98. [CrossRef]
25. Ghotbi, S.H.; Fischer, B. Kontrol Akses Berbasis Peran dan Atribut untuk Aplikasi Web. Dalam Perangkat Lunak dan
Teknologi Data; Cordeiro, J.; Hammoudi, S.; van Sinderen, M., Eds.; Springer: Berlin/Heidelberg, Jerman, 2013; Volume 411,
Hal. 171-187. [CrossRef]
26. Sandhu, R.; Coyne, E.; Feinstein, H.; Youman, C. Model Kontrol Akses Berbasis Peran. Komputer 1996, 29, 38 - 47. [CrossRef]
27. Elliott, A.; Knight, S. Ledakan Peran: Mengakui Masalah. Dalam Prosiding Konferensi Internasional 2010 di Software
Engineering Research & Practice (SERP 2010), Las Vegas, NE, USA, 12-15 Juli 2010; hal. 349-355.
28. Aftab, M.U.; Qin, Z.; Zakria; Ali, S.; Pirah; Khan, J. Evaluasi dan Analisis Perbandingan Model Kontrol Akses Berbasis Peran dan
Kontrol Akses Berbasis Atribut. Dalam Prosiding Konferensi Komputer Internasional 15th 2018 tentang Wavelet Aktif Teknologi
Media dan Pemrosesan Informasi (ICCWAMTIP), Chengdu, Cina, 14-16 Desember 2018; hlm. 35 - 39. [CrossRef]
29. Hu, V.C.; Ferraiolo, D.; Kuhn, R.; Schnitzer, A.; Sandlin, K.; Miller, R.; Scarfone, K. Panduan untuk Definisi dan Pertimbangan
Kontrol Akses Berbasis Atribut (ABAC); Laporan Teknis NIST SP 800-162; National Institute of Standards and Technology:
Gaithersburg, MD, AS, 2014. [CrossRef]
30. Yuan, E.; Tong, J. Attributed Based Access Control (ABAC) untuk Layanan Web. Dalam Prosiding Konferensi Internasional IEEE
tentang Layanan Web (ICWS'05), Orlando, FL, AS, 11 - 15 Juli 2005; hal. 569. [CrossRef]
31. eXtensible Access Control Markup Language (XACML) Versi 3.0. Standar OASIS. 22 Januari 2013. Tersedia secara online:
http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html (diakses pada tanggal 20 Juni 2023).
32. RFC 5234; BNF yang Ditambah untuk Spesifikasi Sintaks: ABNF. Satuan Tugas Rekayasa Internet, Fremont, CA, AS, 2008.
Tersedia online: https://www.rfc-editor.org/rfc/rfc5234.html (diakses pada 22 Maret 2023). [CrossRef].
33. RFC 2616; Hypertext Transfer Protocol-HTTP/1.1. Internet Engineering Task Force, Fremont, CA, USA, 1999. Tersedia online:
https://www.rfc-editor.org/rfc/rfc2616?data1=dwnsb4B&data2=abmurltv2b (diakses pada 20 Juli 2023). [CrossRef]
34. RFC 6749; Kerangka Kerja Otorisasi OAuth 2.0. Gugus Tugas Rekayasa Internet, Fremont, CA, Amerika Serikat, 2012. Tersedia
online: https://www.rfc-editor.org/rfc/rfc6749 (diakses pada 15 Juni 2023). [CrossRef].
35. Chandramouli, R. Strategi Keamanan untuk Sistem Aplikasi Berbasis Layanan Mikro; Laporan Teknis NIST SP 800-204; Institut
Standar dan Teknologi Nasional , Gaithersburg, MD, AS, 2019. [CrossRef]
36. Banati, A.; Kail, E.; Karoczkai, K.; Kozlovszky, M. Otentikasi dan Orkestrator Otorisasi untuk Arsitektur Perangkat Lunak Berbasis
Layanan Mikro. Dalam Prosiding Konvensi Internasional ke-41 2018 tentang Teknologi Informasi dan Komunikasi, Elektronik dan
Mikroelektronika (MIPRO), Opatija, Kroasia, 21 - 25 Mei 2018; hlm. 1180 - 1184. [CrossRef]
37. Das, S.; Mitra, B.; Atluri, V.; Vaidya, J.; Sural, S. Rekayasa Kebijakan dalam RBAC dan ABAC. Dalam Dari Basis Data ke
Keamanan Siber; Samarati, P., Ray, I., Ray, I., Eds.; Penerbitan Internasional Springer: Cham, Swiss, 2018; Volume 11170, hlm. 24
- 54. [CrossRef]
38. Alohaly, M.; Takabi, H.; Blanco, E. Ekstraksi Atribut Otomatis dari Kebijakan Kontrol Akses Berbasis Atribut Bahasa Alami
(ABAC). Keamanan siber 2019, 2, 2. [CrossRef]
39. Narouei, M.; Khanpour, H.; Takabi, H.; Parde, N.; Nielsen, R. Menuju Kerangka Kerja Rekayasa Kebijakan Top-down untuk
Kontrol Akses berbasis Atribut. Dalam Prosiding ACM 22nd tentang Simposium tentang Model dan Teknologi Kontrol Akses,
Indianapolis, IN, AS, 21 - 23 Juni 2017; hlm. 103 - 114. [CrossRef]
40. Fatemian, A.; Zamani, B.; Masoumi, M.; Kamranpour, M.; Ladani, B.T.; Rahimi, S.K. Pembuatan Kode XACML Otomatis
Menggunakan Pendekatan Berbasis Model. Dalam Prosiding Konferensi Internasional ke-11 2021 tentang Teknik Komputer
dan Pengetahuan (ICCKE), Mashhad, Iran, 28 - 29 Oktober 2021; hlm. 206 - 211. [CrossRef]
41. Talukdar, T.; Batra, G.; Vaidya, J.; Atluri, V.; Sural, S. Penambangan Bottom-Up yang Efisien untuk Kebijakan Kontrol Akses Berbasis
Atribut. Dalam Prosiding Konferensi Internasional IEEE 3rd IEEE tentang Kolaborasi dan Komputasi Internet (CIC) 2017, San
Jose, CA, AS, 15 - 17 Oktober 2017; hlm. 339 - 348. [CrossRef]
42. Lethbridge, T.C.; Laganiere, R. Rekayasa Perangkat Lunak Berorientasi Objek; McGraw-Hill: New York, NY, USA, 2005; Volume 11.
43. Cockburn, A. Menulis Kasus Penggunaan yang Efektif; Pearson Education India: Noida, India, 1999.
44. Firesmith, D. Persyaratan Keamanan Teknik. J. Object Technol. 2003, 2, 53. [CrossRef]
Perangkat 435
Lunak 2023, 2

45. Yayasan Komputasi Awan (Cloud Native Computing Foundation). Agen Kebijakan Terbuka (Open Policy Agent (OPA)).
Tersedia secara online: https://www.cncf.io/projects/open-policy- agent-opa/ (diakses pada 16 Maret 2023).
46. Yayasan Komputasi Awan (Cloud Native Computing Foundation). Agen Kebijakan Terbuka: Dokumentasi. Tersedia secara
online: https://www.openpolicyagent. org/docs/latest/ (diakses pada 16 Maret 2023).
47. Proyek Envoy. Dokumentasi Envoy: Apa itu Envoy? Tersedia secara online: https://www.envoyproxy.io/docs/envoy/latest/
intro/what_is_envoy (diakses pada 24 April 2023).
48. Traefik Enterprise Middleware: OPA-Traefik Enterprise. Tersedia secara online: https://doc.traefik.io/traefik-enterprise/
middlewares/opa/ (diakses pada 4 Juli 2023).
49. Schneider, M.; Zieschinski, S.; Klechorov, H.; Brosch, L.; Schorsten, P.; Abeck, S.; Urbaczek, C. Konsep Pengujian untuk
Pengembangan Aplikasi Berbasis Layanan Mikro. Dalam Prosiding Konferensi Internasional Keenam Belas Rekayasa Perangkat
Lunak Advances (IARIA), Barcelona, Spanyol, 3-7 Oktober 2021; hlm. 88-97.
50. Wohlin, C.; Runeson, P.; Höst, M.; Ohlsson, MC; Regnell, B.; Wesslén, A. Eksperimentasi dalam Rekayasa Perangkat Lunak;
Springer: Berlin / Heidelberg, Jerman, 2012. [CrossRef]
51. Throner, S.; Hutter, H.; Sanger, N.; Schneider, M.; Hanselmann, S.; Petrovic, P.; Abeck, S. Lingkungan DevOps Tingkat
Lanjut untuk Aplikasi Berbasis Layanan Mikro. Dalam Prosiding Konferensi Internasional IEEE 2021 tentang Sistem
Berorientasi Layanan Teknik (SOSE), Oxford, Inggris, 23-26 Agustus 2021; hlm. 134 - 143. [CrossRef]
52. Cloud Native Computing Foundation. Dokumentasi Helm. Tersedia secara online: https://helm.sh/docs/ (diakses pada 24
Agustus 2023).
53. Burns, B.; Oppenheimer, D. Pola Desain untuk Sistem Terdistribusi Berbasis Kontainer. Dalam Prosiding Lokakarya
USENIX ke-8 tentang Topik-Topik Populer dalam Komputasi Awan (HotCloud 16), Denver, CO, AS, 20-21 Juni 2016.
54. Proyek Envoy. Dokumentasi Envoy: Filter HTTP-Otorisasi Eksternal. Tersedia secara online: https://www.envoyproxy.io/
docs/envoy/v1.26.3/api-v3/extensions/filters/network/ext_authz/v3/ext_authz.proto, (diakses pada tanggal 29 Maret
2023).
55. Teerakanok, S.; Uehara, T.; Inomata, A. Bermigrasi ke Arsitektur Zero Trust: Ulasan dan Tantangan. Secur. Commun. Netw.
2021, 2021, 9947347. [CrossRef]

Penafian/Catatan Penerbit: Pernyataan, opini, dan data yang terkandung dalam semua publikasi adalah milik masing-masing
penulis dan kontributor dan bukan milik MDPI dan/atau editor. MDPI dan/atau editor tidak bertanggung jawab atas cedera pada
orang atau properti yang diakibatkan oleh ide, metode, instruksi, atau produk apa pun yang dirujuk dalam konten.