Hasil vulnerability scanning bulan ini tidak menunjukkan temuan baru. Jumlah vulnerability tetap sama, tidak ada komponen kritis yang terdeteksi, dan seluruh layanan utama masih berfungsi sebagaimana mestinya.

Sekilas, tingkat keamanan aplikasi tampak tidak berubah.

Namun, sejak pemeriksaan terakhir, beberapa layanan internal telah dihubungkan ke API gateway. Service account mendapatkan izin tambahan. Data production mulai digunakan oleh platform analitik. Endpoint sementara untuk vendor juga belum dinonaktifkan.

Tidak ada vulnerability baru, tetapi jalur menuju aset penting telah bertambah. Inilah alasan keamanan aplikasi tidak dapat dinilai hanya dari jumlah temuan teknis.

Vulnerability menunjukkan kelemahan pada suatu komponen. Arsitektur menentukan siapa yang dapat menjangkaunya, data apa yang dapat diakses, dan seberapa besar dampaknya ketika kelemahan tersebut dieksploitasi.

Hasil Pemindaian yang Sama Tidak Menjamin Risiko Tetap Sama

Risiko keamanan dipengaruhi oleh banyak faktor. Keberadaan vulnerability hanya salah satunya.

Sebuah layanan yang memiliki kelemahan tetapi hanya dapat diakses dari jaringan terbatas tentu berbeda risikonya dengan layanan yang sama ketika dibuka melalui internet. Dampaknya juga berubah apabila layanan tersebut mulai memproses data sensitif atau terhubung dengan sistem penting lainnya.

Dengan kata lain, tingkat risiko dipengaruhi oleh kombinasi antara kelemahan, kemungkinan akses, kewenangan, dan dampak terhadap aset.

Risiko dapat meningkat ketika:

• layanan menjadi lebih mudah dijangkau;
• identitas teknis memperoleh kewenangan tambahan;
• data yang diproses menjadi lebih sensitif;
• jumlah dependensi bertambah;
• segmentasi jaringan melemah;
• kontrol keamanan dapat dilewati;
• sistem terhubung dengan pihak ketiga;
• jalur menuju aset penting menjadi lebih pendek.

Kondisi tersebut tidak selalu menghasilkan vulnerability baru yang dapat ditemukan oleh alat pemindai. Namun, perubahan itu tetap dapat memperburuk security posture aplikasi.

Arsitektur yang Disetujui Tidak Berlaku Selamanya

Arsitektur aplikasi biasanya dirancang dan ditinjau pada tahap awal pengembangan. Diagram menjelaskan komponen, data flow, integrasi, trust boundary, dan kontrol keamanan yang akan diterapkan.

Masalahnya, aplikasi tidak berhenti berubah setelah diagram disetujui.

Perubahan dapat muncul melalui sprint, hotfix, migrasi cloud, kebutuhan performa, integrasi vendor, penanganan insiden, atau permintaan bisnis yang mendesak. Sebagian perubahan tidak masuk dalam perencanaan arsitektur karena dianggap terlalu kecil untuk memerlukan evaluasi khusus.

Satu perubahan mungkin tidak memberikan dampak besar. Namun, akumulasi perubahan kecil dapat membuat arsitektur aktual bergerak menjauh dari desain awal. Kondisi inilah yang dikenal sebagai architecture drift.

Dalam praktiknya, sistem yang berjalan di production dapat memiliki hubungan, izin, dan jalur komunikasi yang berbeda dari dokumentasi. Tim masih mempercayai kontrol yang tergambar pada diagram lama, padahal sistem aktual telah membentuk struktur risiko yang baru.

Architecture Drift Sering Berawal dari Keputusan yang Masuk Akal

Architecture drift tidak selalu terjadi karena developer mengabaikan keamanan. Penyimpangan justru sering bermula dari keputusan yang memiliki alasan teknis atau bisnis.

Endpoint internal dibuka sementara agar vendor dapat menyelesaikan integrasi. Dua layanan menggunakan database yang sama untuk mempercepat pertukaran data. Firewall rule diperluas agar gangguan operasional segera teratasi.

Dalam situasi lain, service account menggunakan role yang sudah tersedia karena pembuatan role baru membutuhkan waktu. Komponen lama tetap dipertahankan untuk menjaga kompatibilitas selama migrasi. Aplikasi juga dapat melewati API gateway agar komunikasi antar layanan memiliki latensi lebih rendah.

Keputusan tersebut mungkin dapat diterima sebagai solusi sementara. Masalah muncul ketika tidak ada batas waktu, pemilik risiko, atau evaluasi ulang.

Solusi sementara kemudian menjadi bagian permanen dari sistem. Anggota tim baru menganggapnya sebagai desain resmi karena kondisi tersebut telah berjalan selama bertahun-tahun.

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

Akses yang awalnya dibuat untuk kebutuhan terbatas masih tetap aktif. Endpoint lama tidak lagi ditampilkan pada aplikasi, tetapi masih dapat dipanggil secara langsung. Service account juga sering memiliki kewenangan lebih luas daripada fungsi yang dijalankannya.

Architecture Drift Berbeda dari Configuration Drift

Architecture drift dan configuration drift sering dianggap sebagai kondisi yang sama. Keduanya memang saling berhubungan, tetapi memiliki fokus berbeda.

Configuration drift terjadi ketika konfigurasi aktual menyimpang dari baseline yang telah ditentukan. Contohnya adalah firewall rule production yang tidak sesuai Infrastructure as Code atau pengaturan server yang berbeda dari standar perusahaan.

Architecture drift terjadi ketika struktur dan hubungan sistem berubah dari desain awal. Misalnya, layanan yang sebelumnya hanya digunakan secara internal menjadi dapat diakses melalui gateway eksternal.

Technical debt juga berbeda. Istilah tersebut mengacu pada kompromi teknis yang menambah biaya atau kesulitan pada masa mendatang, seperti mempertahankan library lama karena migrasi belum selesai.

Sementara itu, architecture erosion menggambarkan penurunan kualitas struktur sistem yang lebih serius. Hubungan antarkomponen mulai melanggar prinsip arsitektur, batas tanggung jawab menjadi tidak jelas, dan perubahan semakin sulit dilakukan secara aman.

Keempat kondisi tersebut dapat muncul secara bersamaan. Configuration drift dapat mengubah jalur akses. Technical debt dapat membuat penyimpangan sulit diperbaiki. Jika dibiarkan, architecture drift dapat berkembang menjadi architecture erosion.

Sebuah systematic mapping study terhadap 73 penelitian mengenai software architecture erosion menemukan bahwa persoalan tersebut tidak hanya menimbulkan pelanggaran struktural. Dampaknya juga dapat memengaruhi kualitas perangkat lunak dan kemampuan sistem untuk terus berkembang.

Trust Boundary Dapat Berpindah tanpa Terlihat

Trust boundary merupakan batas ketika tingkat kepercayaan berubah. Batas tersebut dapat berada antara jaringan internal dan internet, aplikasi dengan layanan pihak ketiga, pengguna biasa dengan fungsi administrator, atau satu tenant dengan tenant lainnya.

Perubahan arsitektur dapat menciptakan trust boundary baru atau memindahkan batas yang sudah ada.

Sebagai contoh, sebuah layanan internal mungkin dibangun tanpa autentikasi kuat karena hanya dapat diakses dari jaringan tertentu. Ketika layanan tersebut dihubungkan ke API gateway, asumsi keamanannya seharusnya ikut berubah.

Masalah muncul ketika tim hanya mengubah konektivitas, tetapi tetap mempertahankan mekanisme keamanan lama.

Hal serupa dapat terjadi ketika aplikasi mulai terhubung dengan vendor. Sistem yang sebelumnya hanya memproses data internal kini mengirimkan informasi kepada pihak lain. Risiko tidak hanya bergantung pada keamanan aplikasi utama, tetapi juga pada perlindungan yang diterapkan di lingkungan penerima.

Jika diagram arsitektur dan threat model tidak diperbarui, tim masih mengevaluasi sistem berdasarkan trust boundary yang sudah tidak berlaku.

Identitas Antar Layanan Dapat Memperluas Dampak

Dalam arsitektur modern, komunikasi tidak hanya dilakukan oleh pengguna. Aplikasi juga menggunakan service account, API key, token, scheduler, pipeline, dan identitas mesin lainnya.

Identitas teknis tersebut sering memperoleh akses tambahan seiring bertambahnya kebutuhan integrasi.

Satu service account yang awalnya hanya digunakan untuk membaca data dapat memperoleh hak menulis. Token yang semula hanya berlaku untuk satu layanan mulai digunakan oleh beberapa sistem. Credential sementara juga dapat tetap aktif setelah proyek selesai.

Architecture drift pada identitas antar layanan dapat muncul ketika:

• satu service account digunakan oleh banyak aplikasi;
• scope token terus diperluas;
• credential lama tidak dicabut;
• layanan baru mewarisi role lama;
• komunikasi internal tidak memverifikasi identitas;
• permission dibuat terlalu umum;
• tidak ada pemilik yang bertanggung jawab atas akun teknis.

Ketika salah satu layanan mengalami kompromi, penyerang dapat menggunakan identitas tersebut untuk berpindah ke sistem lain. Vulnerability awal mungkin tidak berubah, tetapi dampaknya menjadi jauh lebih besar karena kewenangan yang terhubung dengannya telah berkembang.

Microservices Menambah Kecepatan Sekaligus Kompleksitas

Microservices dan cloud memungkinkan tim mengembangkan, memperbarui, dan menjalankan layanan secara lebih fleksibel. Namun, fleksibilitas tersebut juga menambah jumlah komponen yang harus dikelola.

Setiap layanan baru dapat membawa endpoint, dependensi, secret, konfigurasi, identitas teknis, dan jalur komunikasi sendiri. Perubahan juga dapat dilakukan tanpa menyentuh aplikasi utama.

Akibatnya, code review pada satu repository belum tentu memperlihatkan dampak perubahan terhadap keseluruhan sistem.

NIST melalui panduan DevSecOps untuk aplikasi cloud-native menekankan pentingnya pengujian, otomatisasi deployment, dan feedback berkelanjutan. Pendekatan ini dibutuhkan karena keamanan microservices tidak hanya ditentukan oleh kode setiap layanan, tetapi juga oleh hubungan antar layanan.

Microservices tidak otomatis lebih aman atau lebih berisiko. Tingkat keamanannya bergantung pada kemampuan perusahaan menjaga visibilitas, kontrol akses, segmentasi, dan konsistensi arsitektur.

Kontrol Keamanan Dapat Tetap Ada tetapi Kehilangan Fungsinya

Architecture drift tidak selalu menghapus kontrol keamanan. Dalam banyak kasus, kontrol tersebut masih aktif, tetapi tidak lagi melindungi seluruh jalur yang tersedia.

WAF masih berjalan, tetapi layanan dapat diakses langsung tanpa melewatinya. API gateway masih memeriksa autentikasi, tetapi endpoint lama tetap tersedia pada alamat lain.

Segmentasi jaringan masih diterapkan, tetapi integrasi baru membuat koneksi tambahan yang tidak masuk dalam kebijakan awal. Logging juga tetap aktif, tetapi trafik dari layanan baru tidak tercatat pada sistem monitoring.

Kondisi lain dapat terjadi ketika autentikasi masih digunakan, tetapi service account memiliki hak akses terlalu luas. Enkripsi tetap diterapkan, tetapi data sensitif disalin ke sistem yang tidak membutuhkannya.

Kontrol keamanan tidak harus dihapus untuk kehilangan efektivitasnya. Cukup dengan menciptakan jalur baru yang tidak melewati kontrol tersebut.

Vulnerability Scanner Tidak Melihat Seluruh Hubungan Sistem

Vulnerability scanning tetap penting untuk menemukan komponen rentan, konfigurasi umum yang lemah, versi perangkat lunak lama, dan pola vulnerability yang telah diketahui.

Namun, alat pemindai memiliki keterbatasan dalam memahami konteks bisnis dan hubungan antarkomponen.

Scanner belum tentu mengetahui bahwa suatu endpoint seharusnya hanya tersedia dari jaringan internal. Alat juga tidak selalu memahami bahwa sebuah service account memiliki akses lebih luas daripada kebutuhan bisnisnya.

Hubungan lain yang sulit dinilai melalui pemindaian otomatis meliputi:

• perubahan trust boundary;
• data yang menjadi lebih sensitif;
• kombinasi permission antar layanan;
• jalur alternatif menuju aset penting;
• ketergantungan bisnis;
• akses sementara yang menjadi permanen;
• sistem yang seharusnya sudah tidak digunakan;
• kontrol yang dapat dilewati melalui integrasi tertentu.

Karena itu, hasil scanning yang tidak berubah tidak dapat dijadikan satu-satunya bukti bahwa keamanan aplikasi tetap sama.

Threat Model yang Lama Menggambarkan Sistem yang Sudah Tidak Ada

Threat model membantu tim memetakan aset, data flow, komponen, trust boundary, kemungkinan ancaman, dan kontrol keamanan.

Namun, manfaat tersebut hanya berlaku selama modelnya masih sesuai dengan sistem aktual.

Threat model perlu dievaluasi kembali ketika:

• API internal mulai diakses pihak eksternal;
• aplikasi mulai memproses data pribadi;
• database digunakan oleh layanan tambahan;
• sistem menambahkan role baru;
• service account memperoleh akses tulis;
• komponen berpindah ke cloud;
• vendor baru masuk ke dalam alur data;
• workflow baru melewati proses persetujuan lama;
• arsitektur menambahkan teknologi yang belum pernah digunakan.

OWASP Secure-by-Design Framework merekomendasikan security architecture review ketika sistem memperkenalkan integrasi eksternal, trust boundary baru, data sensitif, atau perubahan yang dapat memengaruhi security posture.

Artinya, threat model tidak cukup diperbarui berdasarkan jadwal tahunan. Pembaruannya perlu dipicu oleh perubahan yang relevan terhadap risiko.

Tanda Architecture Drift Sering Muncul di Luar Tim Security

Architecture drift dapat dikenali melalui berbagai gejala operasional.

Beberapa tanda yang perlu diperhatikan antara lain:

• diagram arsitektur tidak sesuai dengan deployment;
• endpoint tidak tercatat dalam inventaris;
• komponen tidak memiliki pemilik;
• banyak akses berstatus sementara;
• firewall rule terus bertambah;
• service account memiliki banyak role;
• data production muncul di staging;
• satu database digunakan banyak aplikasi;
• layanan dapat melewati API gateway;
• dokumentasi masih mencatat komponen lama;
• tim tidak mengetahui konsumen suatu API;
• fitur dinonaktifkan hanya dari antarmuka;
• integrasi lama tetap menggunakan credential aktif.

Gejala tersebut tidak selalu ditemukan pertama kali oleh tim security. Developer, DevOps, QA Engineer, system analyst, dan tim operasional dapat melihatnya lebih awal.

Karena itu, menjaga keamanan arsitektur aplikasi merupakan tanggung jawab bersama.

Tidak Semua Perubahan Membutuhkan Review Penuh

Melakukan security architecture review secara menyeluruh pada setiap perubahan kecil bukan pendekatan yang realistis. Proses tersebut dapat memperlambat development tanpa memberikan peningkatan keamanan yang sebanding.

Perusahaan dapat menggunakan pemicu berbasis risiko.

Review lebih mendalam diperlukan ketika perubahan:

• membuka layanan ke jaringan baru;
• memperkenalkan integrasi eksternal;
• memindahkan data sensitif;
• mengubah autentikasi atau otorisasi;
• menambahkan service account;
• mengubah jalur komunikasi;
• memperkenalkan teknologi baru;
• menghubungkan staging dengan production;
• mengubah pemilik komponen;
• melewati kontrol keamanan yang sudah ada.

Perubahan berisiko lebih rendah dapat diperiksa menggunakan checklist, code review, policy as code, dan pengujian otomatis.

Tujuannya bukan menambah sebanyak mungkin proses persetujuan, melainkan memastikan perubahan yang memengaruhi security posture tidak diperlakukan sebagai perubahan teknis biasa.

Keputusan Arsitektur Perlu Memiliki Jejak

Architecture Decision Record dapat membantu tim mencatat alasan suatu keputusan dibuat. Dokumen ini tidak harus panjang atau penuh formalitas.

Informasi yang perlu dicatat dapat meliputi:

• keputusan yang diambil;
• kebutuhan bisnis;
• alasan teknis;
• alternatif yang dipertimbangkan;
• dampak keamanan;
• kontrol yang diperlukan;
• pemilik keputusan;
• masa berlaku solusi sementara;
• jadwal evaluasi ulang.

Pencatatan tersebut penting karena anggota tim dapat berganti. Keputusan yang awalnya dibuat sebagai pengecualian dapat dianggap sebagai standar apabila tidak ada dokumentasi yang menjelaskan konteksnya.

Jejak keputusan juga membantu tim membedakan perubahan yang memang direncanakan dengan penyimpangan yang tidak terkontrol.

Dokumentasi Harus Dibandingkan dengan Sistem Aktual

Diagram arsitektur yang rapi tidak memberikan banyak manfaat apabila tidak pernah dibandingkan dengan deployment sebenarnya.

Perusahaan perlu membangun proses rekonsiliasi melalui:

• inventaris layanan;
• API discovery;
• pemetaan dependensi;
• data flow diagram;
• pemeriksaan kebijakan IAM;
• Infrastructure as Code;
• policy as code;
• pemantauan trafik antar layanan;
• inventaris service account;
• pemeriksaan komponen tanpa pemilik;
• perbandingan diagram dan konfigurasi aktual.

NIST dalam implementasi Zero Trust menekankan pentingnya pemeriksaan kebijakan identitas, integrasi dengan CI/CD, dan continuous posture assessment. Prinsip tersebut relevan untuk mendeteksi perubahan yang membuat arsitektur aktual menjauh dari desain yang telah disetujui.

Penetration Testing Perlu Mengikuti Attack Path

Pengujian keamanan tidak cukup hanya melihat setiap komponen sebagai target yang berdiri sendiri. Hubungan antarkomponen juga perlu diuji.

Penetration testing berbasis attack path dapat memeriksa:

• apakah layanan internal dapat dijangkau dari luar;
• apakah API gateway dapat dilewati;
• apakah endpoint lama masih aktif;
• apakah satu service account dapat mengakses banyak sistem;
• apakah staging terhubung dengan production;
• apakah data sensitif tersebar ke aplikasi pendukung;
• apakah segmentasi benar-benar membatasi pergerakan;
• apakah vendor memiliki akses berlebihan;
• apakah kontrol pada diagram diterapkan pada seluruh jalur.

Pendekatan ini dapat menunjukkan bagaimana beberapa kondisi dengan risiko rendah apabila dilihat sendiri dapat membentuk jalur serangan yang serius ketika digabungkan.

Ukur Security Posture, Bukan Hanya Jumlah Vulnerability

Jumlah vulnerability tetap merupakan metrik penting. Namun, perusahaan juga perlu mengukur perubahan pada konteks dan struktur aplikasi.

Metrik yang dapat digunakan antara lain:

• jumlah layanan yang terekspos;
• endpoint yang tidak terinventarisasi;
• perubahan trust boundary;
• service account dengan akses berlebihan;
• integrasi sementara yang masih aktif;
• komponen tanpa pemilik;
• jalur yang melewati kontrol utama;
• ketidaksesuaian diagram dan deployment;
• threat model yang belum diperbarui;
• data sensitif yang berpindah ke sistem baru;
• temuan architecture review yang belum diselesaikan.

Metrik tersebut membantu perusahaan melihat risiko yang tidak muncul dalam laporan vulnerability scanning.

Tidak Ada Vulnerability Baru Bukan Berarti Tidak Ada Risiko Baru

Keamanan aplikasi dapat menurun meskipun tidak ada kode berbahaya atau vulnerability baru. Perubahan pada jalur akses, permission, integrasi, data, dan dependensi sudah cukup untuk mengubah tingkat risiko.

Architecture drift berkembang melalui keputusan kecil yang tampak masuk akal. Karena tidak selalu menyebabkan kegagalan fungsi, penyimpangannya dapat berlangsung lama tanpa memperoleh perhatian.

Perusahaan perlu memperbarui dokumentasi, threat model, dan pengujian ketika sistem mengalami perubahan yang relevan terhadap keamanan.

Tidak ada vulnerability baru bukan berarti tidak ada risiko baru. Aplikasi juga dapat menjadi lebih rentan ketika arsitektur lama masih dipercaya, padahal sistem aktual telah membentuk jalur serangan yang berbeda.

Evaluasi Keamanan Aplikasi Bersama Fourtrezz

Fourtrezz dapat membantu perusahaan mengevaluasi keamanan aplikasi, API, dan infrastruktur melalui layanan Penetration Testing dan Vulnerability Assessment.

Pengujian dapat disesuaikan dengan arsitektur sistem, teknologi, integrasi, role pengguna, service account, serta attack surface yang dimiliki perusahaan. Pendekatan ini membantu mengidentifikasi tidak hanya vulnerability, tetapi juga kemungkinan jalur serangan dan dampaknya terhadap sistem.

Fourtrezz juga menyediakan layanan IT Development untuk membantu perusahaan membangun dan mengembangkan sistem dengan mempertimbangkan kebutuhan bisnis serta aspek keamanan sejak tahap perancangan.

Hubungi Fourtrezz:

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