Aplikasi baru sudah masuk production.

Sebagian pengguna sudah berpindah. Infrastruktur cloud mulai menerima traffic. API baru sudah digunakan. Sistem autentikasi juga telah diperbarui.

Namun, aplikasi lama belum dapat dimatikan.

Sebagian proses bisnis masih bergantung padanya. Data belum seluruhnya dipindahkan. Integrasi dengan sistem lain masih menggunakan endpoint lama. Tim operasional bahkan mungkin masih membutuhkan sistem tersebut sebagai fallback jika aplikasi baru mengalami masalah.

Di sinilah muncul paradoks modernisasi sistem.

Perusahaan ingin meninggalkan teknologi lama yang dianggap sulit dikembangkan atau berisiko. Namun, selama masa transisi, organisasi justru memiliki dua sistem aktif sekaligus.

Artinya, attack surface tidak langsung berkurang ketika aplikasi baru mulai digunakan. Dalam banyak kasus, attack surface justru bertambah sebelum sistem lama benar-benar dihentikan.

Sistem Baru Menambah Attack Surface Sebelum Sistem Lama Menghilang

Modernisasi aplikasi sering dibayangkan sebagai perpindahan sederhana dari sistem lama menuju sistem baru.

Dalam praktiknya, perubahan tersebut jarang terjadi dalam satu waktu.

Perusahaan biasanya melakukan migrasi secara bertahap agar operasional tetap berjalan. Beberapa fungsi dipindahkan terlebih dahulu, sementara bagian lain masih tetap berada pada legacy application.

Sebelum modernisasi, sebuah aplikasi mungkin hanya terdiri atas:

Aplikasi lama → Database → Authentication → API

Ketika modernisasi dimulai, arsitekturnya dapat berubah menjadi:

Aplikasi lama + Aplikasi baru + API lama + API baru + Cloud + Integration Service + Migration Service

Komponen baru memang dapat membawa teknologi yang lebih modern.

Namun, komponen lama belum hilang.

Perusahaan akhirnya harus mengamankan dua generasi teknologi dalam waktu bersamaan.

Masalahnya bukan hanya jumlah aset yang meningkat. Hubungan antara aset-aset tersebut juga menciptakan jalur baru yang sebelumnya tidak tersedia.

Masa Transisi Mempertemukan Dua Generasi Keamanan

Legacy system sering dibuat berdasarkan kondisi teknologi dan kebutuhan keamanan pada masanya.

Sebuah aplikasi yang dikembangkan sepuluh tahun lalu mungkin masih mengandalkan username dan password lokal, koneksi internal, IP allowlist, database account bersama, atau asumsi bahwa pengguna di dalam jaringan perusahaan dapat dipercaya.

Aplikasi baru bisa memiliki model yang sangat berbeda.

Authentication menggunakan SSO.

MFA sudah diterapkan.

API berada di belakang gateway.

Identity dan access management lebih terstruktur.

Akses mengikuti prinsip Zero Trust.

Keduanya kemudian harus terhubung.

Di sinilah modernisasi bukan sekadar pertemuan dua teknologi, tetapi juga pertemuan dua model kepercayaan yang berbeda.

CISA menekankan bahwa legacy environment sering masih bergantung pada implicit trust, sedangkan pendekatan Zero Trust berusaha mengurangi ketergantungan terhadap asumsi kepercayaan berdasarkan lokasi jaringan atau atribut yang jarang dievaluasi kembali.

Artinya, aplikasi baru dapat menggunakan kontrol akses modern, tetapi tetap berkomunikasi dengan sistem lama yang menggunakan pola keamanan berbeda.

Keamanan sistem gabungan akhirnya tidak hanya ditentukan oleh komponen terbaru yang digunakan, tetapi juga oleh bagian lama yang masih dipercaya.

Sistem Lama Dapat Menjadi Jalan Memutar Menuju Sistem Baru

Perusahaan mungkin telah membangun aplikasi baru dengan authentication dan authorization yang lebih kuat.

Namun, aplikasi tersebut masih membutuhkan informasi dari legacy system.

Agar keduanya dapat berkomunikasi, dibuat sebuah integration service.

Alurnya menjadi:

Aplikasi Baru → Integration Service → Legacy API

Dari perspektif bisnis, integrasi tersebut diperlukan agar modernisasi tidak mengganggu operasional.

Dari perspektif cybersecurity, hubungan baru tersebut menciptakan trust relationship.

Jika legacy API memiliki kontrol keamanan yang lebih lemah, penyerang tidak selalu harus menyerang aplikasi baru secara langsung.

Mereka dapat mencari jalur melalui sistem yang lebih lama.

Dengan kata lain, aplikasi baru dapat mewarisi risiko legacy system hanya karena masih bergantung padanya.

Inilah alasan mengapa modernisasi sistem tidak dapat dinilai hanya berdasarkan seberapa aman teknologi baru yang digunakan.

Pertanyaan yang lebih penting adalah:

sistem lama apa saja yang masih dipercaya oleh sistem baru?

Integrasi “Sementara” Sering Bertahan Lebih Lama daripada Rencana

Proyek migrasi hampir selalu menghasilkan komponen sementara.

Contohnya:

• temporary API;
• migration account;
• data synchronization service;
• database bridge;
• compatibility endpoint;
• temporary VPN;
• shared credential;
• proxy untuk sistem lama.

Komponen tersebut biasanya dibuat dengan satu asumsi: setelah migrasi selesai, semuanya akan dihapus.

Masalahnya, proyek teknologi tidak selalu berjalan sesuai jadwal.

Migrasi yang direncanakan selesai tiga bulan dapat berkembang menjadi enam bulan.

Kemudian satu tahun.

Sistem lain ternyata masih bergantung pada endpoint lama.

Salah satu divisi belum siap berpindah.

Migrasi data membutuhkan validasi tambahan.

Pada akhirnya, komponen yang awalnya disebut sementara berubah menjadi bagian arsitektur yang digunakan jauh lebih lama dari perkiraan.

Di sinilah label “temporary” menjadi berbahaya.

Sementara sering menjelaskan niat ketika komponen dibuat, bukan umur sebenarnya dari komponen tersebut.

Jika kontrol keamanan terhadap integrasi sementara dibuat dengan asumsi bahwa ia hanya akan digunakan sebentar, risiko akan meningkat ketika komponen itu akhirnya bertahan dalam jangka panjang.

Data Dapat Berada di Dua Tempat pada Saat yang Sama

Modernisasi juga dapat memperluas permukaan risiko pada data.

Ketika migrasi dilakukan secara bertahap, perusahaan tidak selalu dapat langsung memindahkan seluruh informasi dari database lama ke database baru.

Selama masa transisi, data mungkin harus tersedia pada keduanya.

Data pelanggan berada di legacy database.

Data pelanggan juga mulai masuk ke database baru.

Kemudian sebuah synchronization service menjaga agar keduanya tetap konsisten.

Situasi ini memunculkan pertanyaan baru.

Database mana yang menjadi sumber data utama?

Apakah tingkat enkripsinya sama?

Apakah hak akses terhadap database lama sudah diperketat?

Apakah proses penghapusan data diterapkan pada keduanya?

Apakah backup lama masih menyimpan informasi yang sebenarnya sudah tidak diperlukan?

Apakah service account untuk sinkronisasi memiliki privilege terlalu besar?

Modernisasi dalam situasi seperti ini tidak sekadar memindahkan data.

Untuk sementara waktu, modernisasi justru dapat menggandakan lokasi keberadaan data.

Semakin banyak lokasi data berada, semakin banyak pula kontrol keamanan yang harus dijaga.

SSO Baru Tidak Otomatis Menghapus Jalur Login Lama

Salah satu bagian yang sering diperbarui ketika perusahaan melakukan modernisasi adalah authentication.

Aplikasi baru mulai menggunakan Single Sign-On dan Multi-Factor Authentication.

Secara keamanan, ini merupakan peningkatan penting.

Namun, legacy application mungkin masih memiliki sistem login sendiri karena belum seluruh pengguna berpindah.

Akhirnya perusahaan memiliki dua jalur akses:

Sistem Baru → SSO + MFA

dan

Sistem Lama → Username + Password

Jika keduanya masih dapat mengakses data atau proses bisnis yang berkaitan, penyerang tidak perlu memilih jalur dengan proteksi terbaik.

Mereka akan mencari jalur yang lebih lemah.

Karena itu, security posture pada masa transisi bukan ditentukan oleh mekanisme authentication terkuat yang dimiliki perusahaan.

Security posture ditentukan oleh jalur akses terlemah yang masih aktif dan tetap dipercaya sistem.

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

Sistem baru dapat mempunyai kontrol keamanan yang baik, tetapi keberadaan aplikasi lama, endpoint lama, atau akun yang belum dinonaktifkan masih dapat menciptakan attack path yang tidak terlihat apabila pengujian hanya berfokus pada aplikasi terbaru.

API Baru Tidak Membuat API Lama Berhenti Berisiko

Proses modernisasi sering menghasilkan API versi baru.

Misalnya:

/api/v2

API tersebut mungkin sudah berada di belakang API gateway, memiliki authorization yang lebih baik, rate limiting, monitoring, dan dokumentasi yang diperbarui.

Namun aplikasi lama masih menggunakan:

/api/v1

Endpoint tersebut tidak dapat langsung dimatikan karena masih ada sistem yang bergantung padanya.

Masalahnya, perhatian tim engineering dan security biasanya mulai berpindah ke sistem baru.

API lama perlahan kehilangan pemilik yang aktif.

Dokumentasi tidak lagi diperbarui.

Library yang digunakan semakin tua.

Monitoring tidak sebaik API baru.

Tetapi endpoint tetap hidup.

Dalam kondisi seperti ini, modernisasi dapat menghasilkan situasi yang ironis.

Perusahaan memiliki API baru dengan kontrol yang semakin kuat, tetapi API lama yang lebih lemah masih membuka akses ke resource yang sama.

Membangun API baru tidak menghapus risiko dari API lama.

Risiko baru benar-benar berkurang ketika jalur lama sudah dapat dihentikan dengan aman.

Sistem Baru Lebih Terlihat, Sistem Lama Justru Semakin Terlupakan

Platform modern biasanya hadir dengan kemampuan observability yang lebih baik.

Centralized logging.

Cloud monitoring.

SIEM.

API analytics.

Security alerting.

Endpoint protection.

Tim security mempunyai banyak informasi mengenai aktivitas sistem baru.

Legacy system belum tentu memiliki kemampuan yang sama.

Log mungkin hanya tersimpan secara lokal.

Audit trail terbatas.

Sebagian aktivitas tidak masuk ke centralized monitoring.

Sistem tetap berjalan, tetapi perhatian organisasi terhadapnya semakin menurun.

CISA memperingatkan bahwa legacy systems dapat membutuhkan usaha tambahan untuk dikelola, dipantau, dilacak, dilindungi, dideteksi, serta dipulihkan ketika terjadi insiden.

Karena itu, modernisasi dapat menciptakan blind spot yang tidak disadari.

Perusahaan merasa visibilitas keamanan meningkat karena platform baru jauh lebih mudah dipantau.

Namun, pada saat bersamaan, sistem lama yang masih aktif semakin tidak terlihat.

Antarmuka Modern Tidak Berarti Seluruh Dependency Sudah Modern

Modernisasi juga mudah dinilai dari bagian yang terlihat.

Frontend berubah.

Aplikasi berpindah ke cloud.

Container digunakan.

Database baru diterapkan.

User interface menjadi lebih modern.

Namun, di belakang aplikasi tersebut masih mungkin terdapat dependency lama.

Contohnya:

legacy middleware.

database driver lama.

file server.

service internal.

library yang sudah tidak dikembangkan.

authentication service terdahulu.

Komponen semacam ini mungkin tidak terlihat langsung oleh pengguna, tetapi tetap menjadi bagian dari jalur pemrosesan aplikasi.

Karena itu, modernisasi pada interface tidak selalu berarti modernisasi pada dependency.

Sistem baru dapat memiliki tampilan dan arsitektur modern, tetapi tetap bergantung pada teknologi lama yang membawa technical debt serta pola keamanan lama.

Parallel Running Memperbanyak Jalur Serangan

Sebelum modernisasi, pengguna mungkin hanya mempunyai satu jalur:

User → Legacy Application

Saat migrasi berlangsung, pola akses menjadi lebih kompleks:

User → Legacy Application

User → New Application

New Application → Legacy API

Legacy Application → New Service

Migration Service → Legacy Database

Migration Service → New Database

Setiap hubungan tersebut dapat menjadi trust boundary baru.

Semakin banyak hubungan, semakin banyak kemungkinan attack path yang perlu dipahami.

Karena itu, application modernization security seharusnya tidak hanya menguji apakah aplikasi lama aman dan apakah aplikasi baru aman.

Hubungan di antara keduanya juga perlu dievaluasi.

Service account yang terlalu luas.

Token integrasi yang tidak memiliki expiration.

Migration endpoint yang dapat diakses dari jaringan yang tidak semestinya.

Shared credentials.

Authorization yang berbeda antara API lama dan API baru.

Hal-hal semacam inilah yang dapat membuat fase coexistence mempunyai risiko berbeda dari kondisi sebelum maupun sesudah migrasi.

Modernisasi Mengubah Trust Boundary

Sistem lama mungkin dahulu hanya berada di jaringan internal.

Tidak terekspos langsung ke Internet.

Akses hanya tersedia dari jaringan kantor atau VPN.

Setelah modernisasi, aplikasi baru ditempatkan di cloud dan mulai berkomunikasi dengan legacy environment.

Secara tidak langsung, boundary berubah.

Sesuatu yang sebelumnya hanya menerima koneksi dari lingkungan internal sekarang mempunyai jalur komunikasi menuju komponen cloud.

Hal ini bukan berarti integrasi tersebut otomatis tidak aman.

Namun asumsi keamanan lama perlu dievaluasi kembali.

Konsep Zero Trust dari NIST menekankan bahwa keputusan akses sebaiknya tidak hanya bergantung pada lokasi jaringan atau asumsi bahwa perangkat dan pengguna di sisi tertentu otomatis dapat dipercaya.

Dalam konteks modernisasi, pertanyaan dasarnya menjadi:

siapa mempercayai siapa, dan berdasarkan kontrol apa kepercayaan tersebut diberikan?

Jika pertanyaan itu tidak dijawab kembali ketika arsitektur berubah, security boundary lama dapat terbawa ke sistem baru tanpa evaluasi yang memadai.

Decommissioning Adalah Bagian dari Security

Proyek modernisasi sering dianggap selesai ketika aplikasi baru sudah stabil.

Pengguna telah berpindah.

Data utama sudah dimigrasikan.

Fitur utama berjalan.

Namun dari perspektif keamanan, pekerjaan belum benar-benar selesai apabila sistem lama masih menjadi bagian dari attack surface.

Decommissioning perlu mencakup lebih dari sekadar mematikan satu server.

Perusahaan perlu memastikan:

• domain dan subdomain lama sudah diperiksa;
• API lama sudah dihentikan;
• akun legacy sudah dinonaktifkan;
• migration account sudah ditutup;
• token dan secret lama sudah dicabut;
• firewall rules sementara sudah dibersihkan;
• koneksi database lama sudah dihentikan;
• data dan backup lama sudah dikelola sesuai kebutuhan;
• monitoring memastikan tidak ada traffic yang masih bergantung pada sistem tersebut.

Dengan demikian, decommissioning bukan sekadar tahap administratif pada project closure.

Decommissioning adalah kontrol keamanan.

Modernisasi baru benar-benar mengurangi attack surface ketika sistem lama sudah berhenti menjadi bagian dari lingkungan yang dapat diakses dan dipercaya.

Pentest Sistem Lama dan Baru Secara Terpisah Belum Tentu Cukup

Sebuah perusahaan dapat melakukan penetration testing terhadap legacy application.

Kemudian melakukan penetration testing lagi terhadap aplikasi baru.

Keduanya penting.

Namun pendekatan tersebut belum tentu memperlihatkan risiko terbesar selama periode migrasi.

Attack path bisa muncul bukan sepenuhnya di aplikasi lama atau aplikasi baru.

Attack path dapat berada di antara keduanya.

Misalnya:

New App → Integration API → Legacy System

atau:

Legacy Account → Shared Service → New Infrastructure

Dalam situasi seperti ini, vulnerability individual hanya memberi sebagian gambaran.

Yang lebih penting adalah memahami bagaimana satu kelemahan dapat digunakan untuk berpindah dari satu komponen menuju komponen lainnya.

Karena itu, penetration testing pada fase modernisasi perlu mempertimbangkan aplikasi, API, authentication, infrastruktur, integrasi, hingga trust relationship yang muncul selama periode transisi.

“During Migration” Adalah Kondisi Keamanan Tersendiri

Organisasi biasanya melihat modernisasi sebagai dua kondisi:

sebelum migrasi

dan

sesudah migrasi.

Sebelumnya menggunakan legacy architecture.

Setelah selesai menggunakan modern architecture.

Padahal ada kondisi ketiga yang tidak kalah penting:

during migration.

Kondisi inilah yang sering menjadi paling kompleks.

Perusahaan memiliki kontrol lama.

Kontrol baru mulai diterapkan.

Kemudian muncul temporary control untuk menghubungkan keduanya.

Secara sederhana:

Old Controls + New Controls + Temporary Controls

Karena itu, fase migrasi seharusnya diperlakukan sebagai security state tersendiri.

Asset inventory perlu diperbarui.

Threat modeling perlu melihat hubungan baru.

Vulnerability assessment perlu mencakup komponen yang masih aktif.

Penetration testing perlu mempertimbangkan attack path lintas sistem.

Jika organisasi hanya mengevaluasi kondisi akhir, risiko yang muncul selama proses menuju kondisi tersebut dapat terlewat.

Sistem Baru Tidak Membuat Risiko Lama Hilang

Modernisasi tetap penting.

Legacy application memang perlu diperbarui ketika sudah menghambat perkembangan bisnis, sulit dipelihara, atau memiliki risiko keamanan yang tidak lagi dapat diterima.

Namun, modernisasi bukan proses yang secara otomatis membuat perusahaan lebih aman sejak hari pertama.

Ada masa ketika organisasi justru harus mengamankan:

sistem lama, sistem baru, dan seluruh hubungan yang dibangun di antara keduanya.

Inilah sebabnya modernisasi sistem perlu dilihat tidak hanya sebagai proyek pengembangan teknologi, tetapi juga sebagai perubahan attack surface.

Pertanyaannya bukan sekadar:

“Apakah aplikasi baru sudah aman?”

Pertanyaan yang lebih tepat adalah:

“Attack surface apa saja yang bertambah selama aplikasi lama belum benar-benar dimatikan?”

Sebab tujuan modernisasi bukan hanya memiliki teknologi yang lebih baru.

Tujuan akhirnya adalah memastikan teknologi lama tidak terus membawa risiko setelah fungsinya telah digantikan.

Evaluasi Keamanan Modernisasi Sistem Bersama Fourtrezz

Masa migrasi aplikasi dapat menciptakan attack surface yang lebih kompleks karena perusahaan harus mengelola legacy application, sistem baru, API, integration service, account sementara, hingga perubahan pada trust relationship secara bersamaan.

Fourtrezz (PT Tiga Pilar Keamanan) menyediakan layanan cybersecurity untuk membantu perusahaan mengevaluasi risiko keamanan pada aplikasi dan infrastruktur melalui Penetration Testing dan Vulnerability Assessment.

Melalui penetration testing, pengujian dapat diarahkan untuk mengevaluasi vulnerability pada aplikasi, API, authentication, konfigurasi, hingga kemungkinan attack path yang muncul akibat hubungan antara sistem lama dan sistem baru.

Sementara itu, Vulnerability Assessment dapat membantu organisasi mengidentifikasi kerentanan yang masih terdapat pada aset yang aktif selama proses modernisasi.

Pengujian semacam ini dapat membantu perusahaan memastikan bahwa investasi pada sistem baru tidak dibayangi oleh kelemahan dari legacy application atau jalur integrasi yang masih tertinggal.

Jika perusahaan Anda sedang melakukan application modernization, migrasi aplikasi, pengembangan sistem baru, atau membutuhkan evaluasi keamanan terhadap lingkungan yang masih menjalankan legacy system dan modern application secara bersamaan, Fourtrezz dapat menjadi mitra untuk membantu mengidentifikasi risiko sebelum berkembang menjadi insiden.

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