Pull request telah selesai. Fitur sudah digabungkan ke branch utama. Lingkungan preview yang sebelumnya digunakan untuk menguji perubahan aplikasi juga dianggap tidak lagi diperlukan.

Bagi tim development, siklus tersebut mungkin telah berakhir.

Namun, bagi penyerang, situasinya belum tentu demikian.

Sebuah environment dapat berhenti digunakan tanpa benar-benar berhenti menjadi bagian dari attack surface perusahaan. DNS record masih tersimpan, subdomain masih dapat ditemukan, resource cloud belum sepenuhnya dilepas, atau konfigurasi lama tetap menunjuk pada layanan yang sebenarnya sudah tidak lagi dikelola.

Di sinilah asumsi mengenai aset yang “sementara” mulai menjadi persoalan keamanan. Dalam cybersecurity, umur sebuah aset tidak hanya ditentukan oleh berapa lama developer menggunakannya. Umurnya juga ditentukan oleh berapa lama aset tersebut masih dapat ditemukan, diakses, atau dimanfaatkan oleh pihak lain.

Deployment Semakin Cepat, tetapi Attack Surface Juga Semakin Dinamis

Pengembangan aplikasi modern mendorong perusahaan untuk bergerak semakin cepat.

Tim development dapat membuat environment baru untuk sebuah feature branch, pull request, pengujian antarmuka, quality assurance, demonstrasi kepada pengguna internal, hingga eksperimen terhadap fitur baru.

Pendekatan seperti ini membawa keuntungan besar. Perubahan dapat diuji tanpa mengganggu production, kolaborasi menjadi lebih cepat, dan kesalahan dapat ditemukan sebelum fitur dirilis.

Namun, kemudahan membuat environment baru juga menciptakan persoalan lain yang sering kurang diperhatikan.

Semakin mudah sebuah resource dibuat, semakin banyak pula resource yang perlu dilacak hingga akhir siklus hidupnya.

Dalam praktiknya, perusahaan mungkin memiliki production environment yang terdokumentasi dengan baik, tetapi jauh lebih sedikit visibilitas terhadap puluhan atau ratusan subdomain, deployment sementara, resource cloud, serta endpoint yang pernah dibuat selama proses development.

OWASP bahkan memasukkan server development, staging environment, infrastruktur pengujian yang tertinggal, serta konfigurasi DNS yang tidak aman sebagai bagian dari persoalan attack surface yang harus diperhatikan organisasi.

Masalahnya bukan karena preview environment harus dihindari.

Masalah muncul ketika perusahaan mampu mengotomatisasi proses pembuatannya, tetapi tidak memiliki tingkat kedisiplinan yang sama ketika harus menghapusnya.

Environment Dihapus, Jejak Digital Belum Tentu Ikut Hilang

Salah satu kesalahan dalam memahami lifecycle sebuah environment adalah menganggap aplikasi dan seluruh komponen pendukungnya sebagai satu objek.

Padahal, satu preview deployment dapat bergantung pada banyak lapisan.

Sebuah subdomain dapat terhubung dengan DNS, content delivery network, layanan hosting, container, storage, API, sertifikat, secret, akun layanan, logging, hingga resource cloud lainnya.

Karena itu, ketika aplikasi dihentikan, belum tentu seluruh hubungan tersebut ikut terhapus secara otomatis.

Misalnya, perusahaan pernah menggunakan subdomain:

preview-124.perusahaan.co.id

Subdomain tersebut diarahkan ke sebuah layanan cloud selama proses pengujian. Setelah pengembangan selesai, resource cloud dihentikan karena tidak lagi dibutuhkan.

Masalah muncul ketika DNS record yang mengarah ke resource tersebut masih tersimpan.

Dari sudut pandang internal, preview environment sudah tidak ada.

Dari sudut pandang Internet, nama domain tersebut masih menunjukkan bahwa ada hubungan antara perusahaan dan sebuah resource tertentu.

Perbedaan perspektif inilah yang dapat membuka peluang serangan.

Penyerang Tidak Peduli Apakah Sebuah Sistem Hanya Digunakan untuk Testing

Perusahaan umumnya memiliki klasifikasi sendiri terhadap tingkat kepentingan sebuah sistem.

Production dianggap kritis.

Staging berada di bawahnya.

Development dan preview sering diperlakukan sebagai environment dengan risiko lebih rendah karena bukan sistem utama yang digunakan pelanggan.

Penyerang tidak perlu mengikuti klasifikasi tersebut.

Bagi mereka, seluruh aset yang dapat ditemukan adalah kandidat untuk diperiksa.

app.perusahaan.co.id

dan

preview-358.perusahaan.co.id

sama-sama merupakan bagian dari namespace perusahaan.

Jika subdomain kedua memiliki konfigurasi yang lebih lemah, kredensial lama, endpoint yang masih aktif, atau keterkaitan dengan resource yang sudah dilepas, justru environment tersebut dapat menjadi titik yang lebih menarik dibandingkan production.

Hal ini penting karena proses reconnaissance modern memungkinkan berbagai aset eksternal ditemukan melalui DNS enumeration, Certificate Transparency, pencarian hostname, hingga pemetaan layanan yang terlihat dari Internet.

Aset yang terlupakan oleh perusahaan belum tentu terlupakan oleh Internet.

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

Dalam beberapa kasus, aset yang bukan merupakan sistem utama justru memberikan informasi penting mengenai struktur aplikasi, teknologi yang digunakan, pola penamaan subdomain, endpoint API, maupun konfigurasi lain yang dapat memperluas pemahaman terhadap attack surface organisasi.

Dangling DNS Membuktikan bahwa Aset yang Mati Bisa Tetap Berisiko

Salah satu contoh paling jelas dari persoalan ini adalah dangling DNS.

Kondisi tersebut terjadi ketika DNS record masih menunjuk ke resource eksternal yang sudah tidak ada atau telah dilepas.

OWASP menjelaskan bahwa kondisi seperti ini dapat membuka peluang subdomain takeover apabila resource yang sebelumnya digunakan dapat diklaim kembali oleh pihak lain.

Microsoft juga memperingatkan bahwa organisasi yang sering membuat dan menghapus resource cloud perlu memberi perhatian khusus pada DNS record yang tertinggal. CNAME yang tetap mengarah ke layanan yang sudah dihapus dapat berubah menjadi jalur bagi pihak lain untuk mengambil alih subdomain terkait.

Risiko tersebut bukan sekadar kemungkinan teoretis.

Penelitian yang dipresentasikan pada 21st USENIX Symposium on Networked Systems Design and Implementation mengamati penyalahgunaan resource cloud yang telah dilepas tetapi masih memiliki DNS record yang mengarah kepadanya.

Penelitian tersebut mengidentifikasi lebih dari 20 ribu kasus resource yang diambil alih dan digunakan untuk konten berbahaya pada sejumlah platform cloud. Sebagian aktivitas bertahan lebih dari dua bulan.

Temuan itu memperlihatkan satu hal penting: resource yang tidak lagi dianggap bernilai oleh pemiliknya masih dapat memiliki nilai ekonomi bagi penyerang.

Reputasi Domain Bisa Lebih Berharga daripada Aplikasinya

Mengapa penyerang tertarik pada subdomain yang sudah tidak digunakan?

Jawabannya tidak selalu karena aplikasi di belakangnya.

Nilai terbesar terkadang justru terletak pada domain perusahaan yang masih melekat pada aset tersebut.

Bayangkan seorang pengguna menemukan halaman dengan alamat:

promo.perusahaan.co.id

Secara psikologis, alamat tersebut memiliki tingkat kepercayaan yang berbeda dibandingkan domain asing yang tidak memiliki hubungan dengan perusahaan.

Jika subdomain tersebut jatuh ke tangan pihak lain, reputasi domain perusahaan dapat menjadi modal untuk berbagai bentuk penyalahgunaan.

Penelitian USENIX mengenai dangling cloud resources menunjukkan bahwa sebagian besar penyalahgunaan yang mereka amati digunakan untuk praktik blackhat SEO. Para peneliti juga menemukan bentuk penyalahgunaan lain seperti pencurian cookie, sertifikat palsu, dan distribusi malware.

Artinya, aset lama tidak harus berisi data sensitif agar tetap berbahaya.

Selama masih membawa identitas organisasi, aset tersebut tetap mempunyai nilai.

Masalah Utamanya Bukan Sekadar Lupa Menghapus DNS

Menganggap persoalan ini hanya sebagai kesalahan teknis dalam membersihkan DNS terlalu menyederhanakan masalah.

Akar persoalannya berada pada asset lifecycle management.

Perusahaan sering memiliki proses yang sangat terstruktur ketika membuat sistem:

Create → Build → Test → Deploy

Namun, proses setelah penggunaan selesai sering kali jauh lebih longgar.

Idealnya, lifecycle tersebut berlanjut menjadi:

Create → Build → Test → Deploy → Decommission → Remove → Validate

Tahap terakhir sangat penting.

Menghapus resource belum cukup apabila perusahaan tidak memastikan bahwa seluruh referensi terhadap resource tersebut juga telah dibersihkan.

Pertanyaan yang perlu diajukan bukan hanya:

“Apakah servernya sudah dihapus?”

Tetapi juga:

“Apakah DNS record sudah dihapus?”

“Apakah secret dan token sudah dicabut?”

“Apakah endpoint masih dapat ditemukan?”

“Apakah storage terkait masih aktif?”

“Apakah sertifikat masih berlaku?”

“Apakah akun layanan masih memiliki hak akses?”

“Apakah resource tersebut benar-benar tidak lagi dapat digunakan?”

Pertanyaan-pertanyaan tersebut mengubah decommissioning dari pekerjaan administratif menjadi bagian dari keamanan sistem.

Temporary Environment Memerlukan Tanggal Kedaluwarsa

Preview environment biasanya memiliki waktu pembuatan yang jelas.

Ketika pull request dibuat, deployment otomatis muncul.

Namun, tidak semua organisasi memiliki mekanisme yang sama jelasnya untuk menentukan kapan environment tersebut harus dihentikan.

Konsep aset sementara seharusnya tidak berhenti pada label “temporary”.

Setiap environment sebaiknya memiliki sekurangnya beberapa atribut lifecycle:

• siapa pemiliknya;
• untuk kebutuhan apa environment dibuat;
• kapan dibuat;
• kapan harus berakhir;
• DNS atau hostname apa yang digunakan;
• resource cloud apa yang terkait;
• siapa yang bertanggung jawab terhadap proses decommissioning.

Dengan pendekatan tersebut, perusahaan tidak perlu mencari pemilik sebuah subdomain enam bulan setelah proyek selesai.

Status aset telah ditentukan sejak awal.

Prinsip ini menjadi semakin penting ketika perusahaan menggunakan infrastruktur cloud dan CI/CD dalam skala besar. Jumlah resource dapat berubah dengan sangat cepat sehingga pengelolaan manual semakin sulit dijadikan satu-satunya mekanisme kontrol.

Deployment Sudah Otomatis, Decommissioning Seharusnya Tidak Manual

Banyak organisasi telah menginvestasikan waktu untuk mempercepat proses deployment.

Kode yang masuk ke repository dapat menjalankan build, test, provisioning, hingga deployment secara otomatis.

Namun, proses kebalikannya terkadang masih bergantung pada seseorang yang harus mengingat bahwa resource tertentu perlu dihapus.

Kondisi tersebut menciptakan ketimpangan.

Perusahaan memiliki sistem otomatis untuk menambah attack surface, tetapi proses menguranginya masih manual.

Model yang lebih matang adalah menjadikan cleanup sebagai bagian dari pipeline.

Ketika sebuah pull request ditutup atau sebuah environment mencapai masa kedaluwarsa, proses dapat dirancang untuk menjalankan beberapa tindakan secara terstruktur, misalnya:

environment dihentikan → resource dihapus → DNS dibersihkan → secret dicabut → validasi dilakukan

Dengan demikian, decommissioning tidak lagi bergantung sepenuhnya pada ingatan anggota tim.

Otomatisasi bukan hanya digunakan untuk membuat sistem tersedia lebih cepat, tetapi juga untuk memastikan aset yang tidak lagi diperlukan benar-benar berhenti menjadi bagian dari attack surface.

Inventaris Aset Tidak Boleh Hanya Berisi Sistem yang Masih Aktif

Tantangan lain muncul ketika inventaris keamanan hanya mencatat aset yang diketahui masih digunakan.

Dalam praktik attack surface management, pertanyaan yang sama pentingnya adalah aset apa yang pernah dibuat dan apakah seluruh jejaknya sudah dihapus.

Production biasanya mudah ditemukan.

Server utama juga umumnya memiliki pemilik yang jelas.

Sebaliknya, sistem seperti:

old-api.perusahaan.co.id

staging.perusahaan.co.id

demo-2025.perusahaan.co.id

feature-test.perusahaan.co.id

dapat berada di luar perhatian ketika tidak lagi berhubungan dengan pekerjaan aktif.

Padahal, aset semacam inilah yang perlu diperiksa secara berkala.

Organisasi dapat menerapkan kombinasi antara asset inventory, pemantauan DNS, cloud resource inventory, external attack surface monitoring, serta pengujian keamanan untuk memastikan aset lama tidak berubah menjadi exposure yang tidak diketahui.

Pentest Perlu Memahami Attack Surface, Bukan Sekadar Satu URL

Penetration testing sering kali dimulai dari scope yang sangat spesifik.

Perusahaan memberikan satu domain aplikasi, beberapa IP address, atau sejumlah endpoint tertentu untuk diuji.

Pendekatan tersebut tetap penting agar pengujian terkontrol dan sesuai persetujuan.

Namun, dari perspektif manajemen risiko, perusahaan juga perlu memahami apakah masih terdapat aset lain yang secara eksternal diasosiasikan dengan organisasi.

Sebab serangan nyata tidak selalu dimulai dari sistem yang dianggap paling penting.

Jalur serangan dapat muncul dari staging server, development endpoint, cloud storage, subdomain lama, maupun integrasi yang sudah tidak lagi digunakan.

Karena itu, pemetaan attack surface dapat menjadi pelengkap penting bagi penetration testing.

Pengujian tidak hanya membantu menemukan vulnerability pada sistem aktif, tetapi juga memberikan gambaran apakah aset perusahaan yang terlihat dari luar masih sesuai dengan apa yang diketahui oleh tim internal.

Ketika kedua perspektif tersebut berbeda, organisasi memiliki blind spot.

“Sementara” Adalah Status Operasional, Bukan Status Keamanan

Lingkungan preview tetap merupakan bagian penting dari pengembangan aplikasi modern.

Tidak ada alasan untuk menghindarinya selama perusahaan mampu mengelola lifecycle dengan baik.

Hal yang perlu diubah adalah asumsi bahwa environment yang dibuat untuk kebutuhan sementara secara otomatis memiliki risiko yang juga sementara.

Sebuah resource dapat berhenti digunakan hari ini, tetapi DNS record-nya bertahan selama bertahun-tahun.

Server dapat dihentikan, tetapi subdomain tetap tercatat.

Proyek dapat selesai, tetapi endpoint masih dapat ditemukan oleh pihak luar.

Bagi tim development, lifecycle sebuah environment mungkin berakhir ketika pengujian selesai.

Bagi penyerang, lifecycle baru berakhir ketika aset tersebut benar-benar tidak lagi dapat ditemukan, diklaim, diakses, atau dimanfaatkan.

Karena itu, organisasi tidak seharusnya hanya bertanya:

“Apakah preview environment sudah dihapus?”

Pertanyaan yang lebih tepat adalah:

“Apakah seluruh jejak yang membuat environment tersebut masih menjadi bagian dari attack surface juga sudah benar-benar hilang?”

Evaluasi Attack Surface Perusahaan Bersama Fourtrezz

Kompleksitas aplikasi, cloud infrastructure, API, subdomain, dan sistem yang terus berubah dapat membuat perusahaan sulit memastikan apakah seluruh aset digitalnya masih berada dalam kontrol yang semestinya.

Fourtrezz, PT Tiga Pilar Keamanan, menyediakan layanan cybersecurity untuk membantu organisasi mengidentifikasi dan mengevaluasi risiko keamanan pada sistem digital. Layanan yang tersedia mencakup Penetration Testing, Vulnerability Assessment, Security Audit, Red Teaming, serta pengujian keamanan pada Web, Mobile, Cloud, dan Network.

Melalui pengujian keamanan yang terukur, perusahaan dapat memperoleh pemahaman yang lebih jelas mengenai vulnerability, salah konfigurasi, maupun attack surface yang berpotensi dimanfaatkan sebelum berkembang menjadi insiden.

Jika perusahaan Anda ingin mengevaluasi keamanan aplikasi, infrastruktur, maupun aset digital yang terekspos ke Internet, Fourtrezz dapat menjadi mitra untuk melakukan pengujian dan memberikan rekomendasi perbaikan berdasarkan risiko yang ditemukan.

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