Aplikasi telah dipindahkan ke lingkungan baru. Framework diperbarui, antarmuka terlihat lebih modern, dan infrastruktur mulai menggunakan layanan cloud. Dari sisi proyek, semua indikator tampak menunjukkan kemajuan.

Namun, perubahan tersebut belum tentu membuat aplikasi lebih aman.

Modernisasi memang dapat mengganti teknologi yang digunakan. Akan tetapi, proses ini tidak otomatis menghapus kelemahan pada kode, dependency, konfigurasi, data, dan mekanisme hak akses yang sudah terbentuk selama bertahun-tahun.

Apabila komponen tersebut dipindahkan tanpa pemeriksaan keamanan yang memadai, perusahaan sebenarnya tidak menghilangkan risiko. Perusahaan hanya memindahkan risiko lama ke lingkungan yang baru.

Sistem Berpindah, tetapi Asumsi Keamanannya Tetap Sama

Modernisasi aplikasi legacy dapat dilakukan melalui berbagai pendekatan. Perusahaan bisa memindahkan aplikasi ke cloud, mengganti sistem operasi, memperbarui framework, memecah monolith menjadi beberapa layanan, atau membangun ulang bagian tertentu.

Masing-masing pendekatan mempunyai tingkat perubahan yang berbeda.

Dalam strategi rehosting, misalnya, aplikasi dipindahkan ke infrastruktur baru dengan perubahan kode yang relatif terbatas. Cara ini dapat mempercepat migrasi, tetapi sebagian besar logika, konfigurasi, dan dependency lama biasanya tetap dipertahankan.

Masalah serupa juga dapat terjadi dalam refactoring. Struktur kode mungkin menjadi lebih rapi, tetapi mekanisme authorization, validasi input, pengelolaan sesi, dan pembatasan akses belum tentu ikut diperbaiki.

Artinya, kebaruan teknologi tidak dapat dijadikan bukti bahwa keamanan aplikasi juga telah diperbarui.

Ukuran yang lebih relevan adalah apakah perusahaan telah meninjau ulang asumsi keamanan yang digunakan oleh aplikasi. Siapa yang boleh mengakses data tertentu? Bagaimana sistem mengenali identitas pengguna? Komponen mana yang masih dipercaya? Jalur komunikasi apa yang sekarang terbuka?

Tanpa menjawab pertanyaan tersebut, sistem baru berpotensi menjalankan model keamanan lama dalam arsitektur yang lebih kompleks.

Kode Lama Dapat Membawa Kerentanan ke Lingkungan Baru

Salah satu tujuan modernisasi adalah mempertahankan fungsi bisnis yang sudah berjalan. Karena alasan tersebut, tim development sering menggunakan kembali sebagian kode, modul, dan logika dari aplikasi sebelumnya.

Keputusan ini dapat menghemat waktu. Namun, kode yang dipertahankan juga dapat membawa kelemahan yang belum pernah teridentifikasi.

Validasi input yang tidak memadai, pemeriksaan authorization yang lemah, pengelolaan sesi yang tidak aman, serta pesan kesalahan yang membuka informasi sensitif dapat tetap hidup meskipun aplikasi telah menggunakan framework yang lebih baru.

Risiko juga dapat tersembunyi di dalam fungsi yang jarang digunakan. Sebuah endpoint lama mungkin tidak lagi muncul pada antarmuka utama, tetapi masih dapat diakses melalui permintaan langsung. Modul administrasi dapat dianggap sudah tidak aktif, padahal rutenya belum benar-benar ditutup.

Kondisi ini membuat attack surface aplikasi lebih luas daripada yang terlihat dalam dokumentasi.

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

Dalam beberapa kasus, kerentanan bukan berasal dari fitur baru. Celah justru muncul dari fungsi lama yang dipindahkan agar aplikasi tetap kompatibel dengan proses bisnis sebelumnya.

Karena itu, proses migrasi kode seharusnya tidak hanya menanyakan apakah fungsi tersebut masih berjalan. Tim juga perlu memastikan apakah fungsi itu masih diperlukan, siapa yang boleh mengaksesnya, dan apakah kontrol keamanannya masih sesuai dengan arsitektur baru.

Dependency Lama Tidak Hilang Hanya karena Framework Utama Diperbarui

Sebuah aplikasi tidak hanya terdiri dari kode yang ditulis oleh tim internal. Di dalamnya terdapat library, package, plugin, SDK, container image, serta komponen pihak ketiga lainnya.

Ketika modernisasi dilakukan, perhatian biasanya tertuju pada framework utama. Padahal, kerentanan dapat berada pada dependency yang tidak terlihat langsung atau dipanggil melalui komponen lain.

Tim mungkin berhasil menggunakan versi framework yang lebih baru, tetapi masih membawa library pendukung yang sudah tidak menerima pembaruan. Package internal yang tidak mempunyai pemilik juga dapat dipindahkan karena masih dibutuhkan oleh proses tertentu.

Masalahnya tidak berhenti pada versi komponen. Perusahaan juga perlu mengetahui asal, fungsi, tingkat akses, dan status dukungan setiap dependency.

Tanpa inventaris yang jelas, perusahaan akan kesulitan menentukan apakah sebuah kerentanan memengaruhi aplikasinya. Tim keamanan harus menelusuri komponen secara manual, sementara proses perbaikan menjadi lebih lambat.

Software Composition Analysis dapat membantu mengidentifikasi dependency yang memiliki kerentanan diketahui. Namun, hasil pemindaian tetap perlu dianalisis berdasarkan konteks penggunaan. Tidak semua temuan mempunyai dampak yang sama, dan tidak semua risiko dapat diselesaikan hanya dengan memperbarui versi.

Konfigurasi Lama Sering Dipindahkan agar Sistem Baru Segera Berjalan

Selain kode dan dependency, konfigurasi merupakan bagian yang sering ikut bermigrasi.

Tim dapat menyalin environment variable, koneksi database, aturan firewall, akun layanan, sertifikat, atau API key agar sistem baru segera terhubung dengan layanan lain. Cara ini terlihat praktis, terutama ketika perusahaan harus menjaga kontinuitas operasional.

Namun, konfigurasi lama mungkin dibuat berdasarkan kondisi yang sudah berbeda.

Akun layanan yang sebelumnya hanya digunakan pada jaringan internal dapat memperoleh jangkauan lebih luas setelah aplikasi dipindahkan ke cloud. Firewall rule yang dahulu dianggap aman dapat membuka akses berlebihan ketika diterapkan pada arsitektur baru.

Credential juga dapat tersimpan di dalam source code, file konfigurasi, pipeline deployment, dokumentasi internal, atau backup lama. Apabila credential tersebut hanya disalin tanpa rotasi, pihak yang pernah mempunyai akses tetap berpotensi menggunakannya.

Setiap proses modernisasi perlu disertai inventaris identitas mesin, secret, certificate, dan hak akses. Credential lama sebaiknya tidak sekadar dipindahkan, tetapi dievaluasi, dirotasi, dibatasi, dan diberikan masa berlaku yang jelas.

Setelah migrasi selesai, seluruh akses sementara juga harus dicabut. Jika tidak, jalur yang awalnya dibuat untuk memudahkan transisi dapat berubah menjadi akses permanen yang tidak terpantau.

Data yang Berhasil Dipindahkan Belum Tentu Aman Digunakan

Keberhasilan migrasi data sering dinilai berdasarkan jumlah record, kesesuaian format, atau kemampuan aplikasi baru menampilkan informasi yang sama. Indikator tersebut penting, tetapi belum cukup untuk membuktikan keamanan data.

Data lama dapat membawa klasifikasi, hak akses, dan aturan retensi yang sudah tidak sesuai.

Sebagai contoh, pengguna yang sebelumnya mempunyai akses luas mungkin tetap memperoleh izin serupa setelah migrasi. Struktur role lama dapat diterapkan kembali tanpa mengevaluasi apakah kewenangan tersebut masih dibutuhkan.

Data sensitif juga dapat dipindahkan ke lingkungan pengujian untuk mempermudah validasi. Jika tidak dimasking atau dianonimkan, lingkungan non produksi dapat menyimpan informasi dengan tingkat sensitivitas yang sama seperti sistem produksi, tetapi dengan pengamanan yang lebih rendah.

Perusahaan juga perlu memperhatikan kualitas dan integritas data. Kesalahan pemetaan dapat menyebabkan data berada pada akun, unit, atau tenant yang salah. Dalam aplikasi multi-tenant, kesalahan semacam ini dapat berkembang menjadi kebocoran data antar pelanggan.

Validasi migrasi karena itu harus mencakup lebih dari sekadar kesesuaian jumlah record. Tim perlu memeriksa klasifikasi data, kepemilikan, hak akses, enkripsi, retensi, audit trail, serta hubungan antarentitas.

Masa Transisi Dapat Memperluas Attack Surface

Risiko modernisasi aplikasi legacy tidak hanya berada pada sistem lama atau sistem baru. Risiko juga muncul di antara keduanya.

Selama masa transisi, kedua sistem biasanya harus berjalan secara bersamaan. Perusahaan dapat memiliki dua jalur autentikasi, dua lingkungan produksi, middleware tambahan, mekanisme sinkronisasi data, serta API sementara untuk menjaga kompatibilitas.

Setiap komponen tambahan menciptakan jalur komunikasi dan hubungan kepercayaan baru.

Sebuah migration script mungkin diberikan akses penuh ke dua database. Service account dapat memperoleh hak baca dan tulis tanpa pembatasan yang memadai. API kompatibilitas mungkin tidak menggunakan kontrol keamanan yang sama dengan API utama.

Komponen tersebut sering disebut sementara. Dalam praktiknya, kebutuhan operasional dapat membuatnya tetap aktif jauh setelah proses cutover selesai.

Semakin lama sistem lama dan baru berjalan berdampingan, semakin sulit pula bagi perusahaan untuk memastikan sistem mana yang menjadi sumber data utama, akun mana yang masih dibutuhkan, dan jalur mana yang seharusnya sudah ditutup.

Oleh karena itu, masa transisi perlu diperlakukan sebagai fase berisiko tinggi. Akses harus dibatasi, aktivitas dicatat, sinkronisasi dipantau, dan setiap komponen sementara harus mempunyai pemilik serta tanggal penghentian yang jelas.

Pengujian Fungsional Tidak Membuktikan Aplikasi Sudah Aman

Setelah modernisasi selesai, tim biasanya menjalankan pengujian untuk memastikan login, transaksi, laporan, integrasi, dan proses bisnis tetap berfungsi.

Pengujian tersebut membuktikan bahwa aplikasi bekerja sesuai kebutuhan. Namun, hasilnya tidak menjawab apakah aplikasi dapat disalahgunakan.

Pengguna mungkin berhasil membuka data yang memang menjadi kewenangannya. Pertanyaan keamanannya adalah apakah pengguna yang sama juga dapat mengakses data milik pengguna lain.

API mungkin berhasil mengirim informasi kepada sistem tujuan. Akan tetapi, masih perlu dipastikan apakah token dapat digunakan ulang, parameter dapat dimanipulasi, atau endpoint dapat dipanggil tanpa izin yang tepat.

Kondisi inilah yang membuat security testing perlu dipisahkan dari pengujian fungsional.

Vulnerability assessment dapat membantu mengidentifikasi kerentanan umum, dependency rentan, konfigurasi lemah, dan permukaan serangan yang terlihat. Penetration testing kemudian menguji apakah kelemahan tersebut benar-benar dapat dimanfaatkan untuk memperoleh akses, meningkatkan kewenangan, atau mengambil data yang seharusnya dilindungi.

Security regression testing juga diperlukan untuk memastikan perubahan selama migrasi tidak menghidupkan kembali kerentanan yang sebelumnya sudah diperbaiki.

Strategi Modernisasi Hanya Mengubah Bentuk Risikonya

Tidak ada satu strategi modernisasi yang otomatis aman.

Rehosting dapat mempertahankan kode dan konfigurasi lama hampir tanpa perubahan. Platforming dapat mempertemukan kontrol aplikasi lama dengan konfigurasi platform yang belum dipahami sepenuhnya.

Refactoring membuka kesempatan memperbaiki struktur kode, tetapi perubahan tersebut juga dapat menimbulkan security regression. Rearchitecting menuju microservices dapat memperkecil beberapa batas sistem, sekaligus menambah API, service account, token, dan komunikasi antar layanan.

Membangun ulang aplikasi juga tidak menjamin seluruh risiko hilang. Tim baru dapat menerjemahkan logika bisnis secara berbeda atau melewatkan aturan keamanan yang sebelumnya tidak terdokumentasi.

Sementara itu, mengganti aplikasi dengan produk pihak ketiga memindahkan sebagian tanggung jawab kepada vendor. Risiko kemudian bergeser ke konfigurasi, integrasi, pengelolaan akses, supply chain, dan perlindungan data.

Perusahaan tidak perlu mencari strategi yang bebas risiko. Fokus yang lebih realistis adalah memahami risiko yang muncul dari setiap keputusan dan menentukan kontrol yang sesuai sejak tahap perencanaan.

Keamanan Harus Menjadi Bagian dari Program Modernisasi

Keamanan sebaiknya tidak ditempatkan sebagai pemeriksaan terakhir sebelum aplikasi digunakan. Pada tahap tersebut, perubahan mendasar biasanya sudah lebih sulit dan mahal dilakukan.

Sebelum migrasi dimulai, perusahaan perlu memetakan aset, dependency, data, API, akun, credential, serta hubungan aplikasi dengan sistem lain. Kerentanan yang sudah diketahui harus dicatat agar tidak ikut dipindahkan secara tidak sengaja.

Threat modeling dapat digunakan untuk melihat perubahan trust boundary dan jalur serangan pada arsitektur target. Perusahaan juga perlu menetapkan security acceptance criteria yang harus dipenuhi sebelum sistem memperoleh persetujuan untuk go-live.

Selama proses development, pemeriksaan keamanan dapat dilakukan melalui code review, Static Application Security Testing, Software Composition Analysis, secrets scanning, serta pengujian konfigurasi infrastruktur.

Authentication dan authorization perlu dirancang ulang berdasarkan prinsip least privilege. Tim tidak cukup hanya memastikan pengguna dapat masuk ke aplikasi, tetapi juga harus memeriksa tindakan dan data apa saja yang dapat diakses setelah pengguna berhasil diautentikasi.

Sebelum go-live, vulnerability assessment dan penetration testing perlu dilakukan terhadap arsitektur yang benar-benar akan digunakan. Cakupan pengujian harus meliputi aplikasi, API, integrasi, konfigurasi, hak akses, dan jalur administratif yang relevan.

Setelah temuan diperbaiki, retest diperlukan untuk memastikan jalur eksploitasi telah tertutup dan perubahan tidak menimbulkan masalah baru.

Go-Live Bukan Satu-Satunya Ukuran Keberhasilan

Modernisasi sering dianggap selesai ketika aplikasi baru sudah dapat digunakan. Padahal, sistem dapat beroperasi dengan baik sambil tetap menyimpan berbagai risiko.

Keberhasilan keamanan perlu dinilai melalui indikator yang lebih konkret.

Perusahaan perlu mengetahui berapa banyak dependency end-of-life yang berhasil dihapus, akun bersama yang dihentikan, credential yang dirotasi, dan hak akses berlebihan yang dikurangi.

Endpoint legacy, koneksi sementara, dan lingkungan lama juga harus diperiksa. Jika masih aktif tanpa kebutuhan yang jelas, proses modernisasi sebenarnya belum sepenuhnya selesai.

Dokumentasi arsitektur, data flow, inventaris aset, dan kepemilikan komponen perlu diperbarui. Logging dan monitoring juga harus mampu memberikan visibilitas terhadap aktivitas pada aplikasi baru serta komponen yang masih digunakan selama masa transisi.

Dengan ukuran tersebut, perusahaan tidak hanya dapat mengatakan bahwa aplikasi berhasil dipindahkan. Perusahaan juga dapat menunjukkan risiko apa yang dihapus, kontrol apa yang diperkuat, dan jalur lama mana yang benar-benar telah ditutup.

Jangan Memindahkan Utang Keamanan ke Sistem yang Baru

Modernisasi aplikasi legacy merupakan kesempatan untuk memperbaiki teknologi sekaligus meninjau kembali keputusan keamanan yang sudah bertahan terlalu lama.

Kesempatan tersebut akan hilang apabila perusahaan hanya mengejar kompatibilitas, kecepatan migrasi, dan keberhasilan go-live. Sistem mungkin terlihat baru, tetapi di dalamnya tetap terdapat kode rentan, dependency usang, hak akses berlebihan, serta konfigurasi yang tidak pernah dievaluasi.

Modernisasi yang aman membutuhkan pemetaan risiko sebelum migrasi, penerapan Secure SDLC selama pengembangan, pengujian keamanan sebelum go-live, dan penghentian jalur lama setelah cutover.

Sistem baru baru dapat disebut lebih aman ketika perusahaan mampu membuktikan bahwa kerentanan lama tidak sekadar dipindahkan, tetapi benar-benar ditemukan, diperbaiki, dan diuji kembali.

Pastikan Modernisasi Sistem Tidak Membawa Risiko Lama

Fourtrezz membantu perusahaan mengidentifikasi dan menguji risiko keamanan pada aplikasi, API, jaringan, serta server melalui layanan vulnerability assessment dan penetration testing.

Pengujian dapat dilakukan untuk mengevaluasi aplikasi legacy sebelum migrasi maupun memvalidasi keamanan sistem baru setelah modernisasi. Fourtrezz juga menyediakan layanan IT Development, Legacy System Transformation, System & API Integration, serta IT Architecture Design dengan pendekatan secure by design.

Melalui pengujian yang terarah, perusahaan dapat memperoleh gambaran mengenai kerentanan yang masih tersisa, kemungkinan jalur eksploitasi, dampaknya terhadap bisnis, serta rekomendasi perbaikan yang dapat ditindaklanjuti.

Diskusikan kebutuhan modernisasi dan pengujian keamanan perusahaan Anda bersama Fourtrezz.

Hubungi Fourtrezz:

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