Sebuah perusahaan dapat menutup port yang tidak diperlukan, membatasi akses administratif, memasang web application firewall, dan memastikan seluruh server telah diperbarui. Dari sisi jaringan, lingkungan tersebut mungkin terlihat cukup aman. Namun, satu akun dengan hak akses berlebihan masih dapat membuka jalan menuju penyimpanan data, database, secret, hingga sistem lain yang tidak pernah terekspos langsung ke internet.

Kondisi inilah yang membuat cloud pentest tidak dapat diperlakukan seperti pengujian jaringan konvensional.

Dalam pengujian infrastruktur tradisional, jumlah IP publik sering menjadi salah satu dasar untuk menentukan ruang lingkup pekerjaan. Pendekatan tersebut masih relevan untuk menilai layanan yang dapat dijangkau dari internet. Masalahnya, lingkungan cloud tidak hanya dibangun dari server, port, dan alamat IP.

Cloud bekerja melalui identitas, API pengelolaan, policy, role, service account, hubungan kepercayaan, serta konfigurasi antar layanan. Sebuah sumber daya bahkan dapat berada sepenuhnya di jaringan privat, tetapi tetap dapat diakses ketika kredensial atau izin tertentu berhasil disalahgunakan.

Karena itu, pertanyaan yang perlu diajukan sebelum melakukan cloud penetration testing bukan hanya “berapa jumlah IP publik yang diuji?”, tetapi juga “identitas apa yang tersedia, izin apa yang dimiliki, dan seberapa jauh akses tersebut dapat berkembang?”

Cara Lama Menentukan Scope Pentest Tidak Selalu Sesuai untuk Cloud

Pengujian keamanan jaringan biasanya dimulai dengan pemetaan aset yang terlihat dari luar. Tim penguji mengidentifikasi IP publik, domain, subdomain, port terbuka, sistem operasi, dan layanan yang berjalan. Dari informasi tersebut, penguji mencari kerentanan yang dapat digunakan untuk memperoleh akses lebih jauh.

Pendekatan ini tetap dibutuhkan dalam cloud pentest. Aplikasi, API, load balancer, virtual machine, dan layanan yang menghadap internet tetap harus diperiksa. Namun, menjadikan aset publik sebagai satu-satunya dasar ruang lingkup dapat menghasilkan gambaran keamanan yang tidak lengkap.

Satu akun cloud dapat menampung puluhan hingga ratusan sumber daya. Di dalamnya terdapat workload aplikasi, storage, database, container, fungsi serverless, pipeline deployment, secret manager, serta sistem logging. Masing-masing komponen dapat memiliki hubungan akses yang berbeda.

Sebuah aplikasi, misalnya, mungkin hanya memiliki satu endpoint publik. Akan tetapi, aplikasi tersebut dapat menjalankan role yang memiliki izin untuk membaca object storage, mengambil secret, mengakses database, atau menjalankan fungsi tertentu. Apabila role itu memiliki permission berlebihan, satu kelemahan pada aplikasi dapat berkembang menjadi akses ke berbagai layanan lain.

Dengan demikian, satu IP publik tidak selalu merepresentasikan satu target. IP tersebut bisa menjadi pintu masuk menuju ekosistem cloud yang jauh lebih luas.

Dalam Cloud, Identitas Dapat Lebih Bernilai daripada Eksploitasi Server

Penyerang tidak selalu harus menemukan remote code execution atau mengambil alih server untuk memperoleh dampak besar. Dalam banyak serangan cloud, kredensial yang valid justru lebih bernilai daripada eksploitasi teknis yang rumit.

Kredensial tersebut dapat berasal dari akun pengguna, service account, access key, token sementara, pipeline CI/CD, workload identity, atau role yang melekat pada aplikasi. Apabila identitas tersebut memiliki izin terlalu luas, penyerang dapat melakukan tindakan yang terlihat seperti aktivitas sah.

Inilah salah satu tantangan utama keamanan cloud. Permintaan yang menggunakan kredensial resmi belum tentu berasal dari pengguna atau workload yang semestinya.

Identitas manusia bukan satu-satunya yang perlu diperiksa

Perusahaan umumnya telah memberi perhatian pada akun administrator dan pengguna internal. Kebijakan kata sandi, autentikasi multifaktor, serta proses pemberian akses biasanya diterapkan untuk identitas manusia.

Namun, lingkungan cloud juga dipenuhi identitas non manusia. Aplikasi menggunakan service account. Virtual machine menggunakan role. Fungsi serverless membutuhkan akses ke database. Pipeline deployment memperoleh izin untuk membuat atau memperbarui sumber daya.

Jumlah identitas mesin dapat tumbuh lebih cepat daripada jumlah karyawan. Sebagian dibuat untuk kebutuhan sementara, tetapi tetap aktif setelah proyek selesai. Sebagian lainnya memperoleh permission luas agar proses integrasi dapat berjalan tanpa hambatan.

Situasi ini menimbulkan risiko baru. Identitas yang tidak lagi dipantau dapat tetap memiliki akses ke sistem penting. Access key lama mungkin belum dicabut. Service account dapat memiliki izin yang tidak sesuai dengan fungsi awalnya. Hubungan kepercayaan yang dibuat untuk integrasi sementara dapat berubah menjadi jalur akses permanen.

Karena itu, cloud security testing perlu mengevaluasi identitas manusia dan mesin secara bersamaan.

Permission berlebihan membentuk jalur serangan tersembunyi

Permission berlebihan tidak selalu berbentuk hak administrator penuh. Risiko sering muncul dari kombinasi beberapa izin yang sekilas terlihat tidak berbahaya.

Sebuah role mungkin tidak dapat membaca data sensitif secara langsung. Namun, role tersebut memiliki izin untuk mengubah konfigurasi fungsi serverless. Fungsi itu menggunakan identitas lain yang dapat mengakses database. Dengan memodifikasi fungsi tersebut, penyerang dapat menggunakan hak akses yang lebih tinggi secara tidak langsung.

Pada skenario lain, seorang pengguna tidak memiliki akses ke secret. Namun, pengguna tersebut dapat membuat versi baru suatu workload dan menentukan service account yang digunakan. Apabila service account mempunyai akses ke secret, batasan pada akun pengguna menjadi tidak efektif.

Pengujian yang hanya memeriksa nama policy atau keberadaan wildcard dapat melewatkan hubungan semacam ini. Cloud pentest harus menilai apa yang benar-benar dapat dilakukan oleh suatu identitas, termasuk kemungkinan mengubah resource, mengasumsikan role lain, membuat kredensial baru, atau menjalankan workload dengan hak akses berbeda.

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

Permasalahan utamanya bukan selalu karena perusahaan memberikan akses administrator secara terang-terangan. Risiko justru sering tersembunyi dalam hubungan permission yang kompleks, diwariskan, dan tidak lagi dipahami secara utuh oleh tim pengelola.

Salah Konfigurasi Dapat Menjadi Kerentanan meskipun Tidak Memiliki CVE

Banyak organisasi terbiasa mengukur risiko berdasarkan daftar kerentanan perangkat lunak. Sistem diperiksa untuk mencari versi yang sudah usang, patch yang belum dipasang, atau celah yang memiliki nomor Common Vulnerabilities and Exposures.

Pendekatan tersebut penting, tetapi tidak cukup untuk lingkungan cloud.

Sebuah cloud service dapat menggunakan versi perangkat lunak terbaru dan tidak memiliki kerentanan publik yang diketahui. Namun, layanan itu tetap berbahaya apabila dikonfigurasi secara keliru.

Storage yang dapat diakses publik, security group yang terlalu terbuka, role dengan wildcard permission, secret yang tersimpan dalam source code, atau logging yang dapat dinonaktifkan oleh pengguna biasa tidak selalu memiliki CVE. Meskipun demikian, dampaknya dapat sama seriusnya dengan eksploitasi kerentanan perangkat lunak.

Storage terbuka bukan satu-satunya bentuk salah konfigurasi

Ketika membahas cloud misconfiguration, perhatian sering langsung mengarah pada bucket atau object storage yang terbuka ke internet. Kasus tersebut memang penting karena dapat menyebabkan data sensitif diakses tanpa otorisasi.

Namun, kesalahan konfigurasi storage tidak selalu berarti akses publik penuh.

Resource policy dapat memberikan akses kepada akun yang tidak relevan. Hak tulis mungkin diberikan kepada pihak yang hanya membutuhkan hak baca. File cadangan dapat tersimpan bersama data operasional. Link akses sementara dapat berlaku terlalu lama. Data sensitif mungkin tidak terenkripsi dengan mekanisme yang sesuai.

Selain itu, storage dapat menjadi bagian dari rantai serangan. Akses tulis terhadap bucket yang digunakan untuk deployment, misalnya, dapat memungkinkan perubahan pada file aplikasi atau artefak sistem. Dampaknya tidak lagi terbatas pada kebocoran data, tetapi dapat berkembang menjadi manipulasi aplikasi.

Security group yang rapi belum tentu konsisten

Aturan jaringan cloud dapat berubah dengan cepat. Tim operasional terkadang membuka port tertentu untuk troubleshooting, integrasi, migrasi, atau kebutuhan vendor. Setelah pekerjaan selesai, aturan sementara tersebut tidak selalu dihapus.

Masalah lain muncul ketika aturan diterapkan secara berbeda antar-environment. Lingkungan production mungkin dikendalikan dengan ketat, sementara staging memiliki akses lebih terbuka. Padahal, staging dapat menggunakan salinan data production, kredensial serupa, atau koneksi ke layanan internal yang sama.

Cloud pentest perlu memeriksa apakah segmentasi benar-benar membatasi pergerakan penyerang. Pengujian tidak cukup dengan memastikan bahwa sebuah database tidak memiliki IP publik. Penguji juga perlu menilai workload mana yang dapat menjangkau database tersebut dan identitas apa yang digunakan ketika koneksi berlangsung.

Jaringan privat bukan jaminan bahwa sumber daya aman. Apabila workload yang telah disusupi dapat mengaksesnya, layanan privat tetap menjadi bagian dari attack path.

Secret dapat bocor melalui proses yang dianggap rutin

Access key, token API, kata sandi database, certificate, dan credential lain seharusnya dikelola melalui sistem penyimpanan secret yang terkontrol. Namun, dalam praktiknya, informasi tersebut masih dapat ditemukan dalam source code, file konfigurasi, environment variable, container image, log aplikasi, atau pipeline deployment.

Risiko meningkat ketika satu secret digunakan oleh beberapa layanan. Tim keamanan akan kesulitan mengetahui sumber kebocoran dan menentukan sistem mana saja yang terdampak.

Secret yang tidak pernah dirotasi juga memperpanjang masa eksploitasi. Sekalipun kebocoran terjadi beberapa bulan sebelumnya, penyerang tetap dapat menggunakan kredensial tersebut selama belum dicabut.

Oleh sebab itu, pengujian cloud perlu mencakup cara secret dibuat, disimpan, digunakan, dicatat, dirotasi, dan dinonaktifkan. Tujuannya bukan hanya mencari credential yang terbuka, tetapi memahami dampak yang dapat terjadi apabila credential tersebut jatuh ke pihak yang tidak berwenang.

Satu Kesalahan Kecil Dapat Berkembang Menjadi Attack Path

Temuan keamanan cloud jarang berdiri sendiri. Dampak yang besar sering muncul ketika beberapa kelemahan digabungkan.

Bayangkan sebuah aplikasi memiliki celah yang memungkinkan penyerang mengakses informasi tertentu dari lingkungan runtime. Informasi tersebut memuat token sementara milik workload. Role workload tidak mempunyai akses administrator, tetapi dapat membaca beberapa secret.

Salah satu secret berisi kredensial database. Dari database, penyerang menemukan konfigurasi integrasi dengan sistem lain. Kredensial integrasi tersebut kemudian digunakan untuk mengakses akun dengan permission yang lebih luas.

Apabila setiap temuan dinilai secara terpisah, tingkat risikonya mungkin terlihat sedang. Namun, ketika dirangkai sebagai jalur serangan, dampaknya dapat mencakup pencurian data, perpindahan antar-environment, perubahan konfigurasi, atau pengambilalihan layanan.

Di sinilah perbedaan antara pemeriksaan konfigurasi dan penetration testing menjadi terlihat. Pemeriksaan konfigurasi dapat menunjukkan bahwa sebuah role memiliki izin berlebihan. Penetration testing berusaha membuktikan bagaimana izin tersebut dapat digunakan, sumber daya mana yang dapat dicapai, dan dampak bisnis apa yang mungkin muncul.

Laporan cloud pentest yang baik tidak hanya menyatakan bahwa suatu policy menggunakan wildcard. Laporan tersebut perlu menjelaskan bagaimana policy itu dapat dimanfaatkan untuk memperoleh hak lebih tinggi atau mengakses data yang seharusnya berada di luar kewenangan identitas tersebut.

Cloud Pentest Harus Menjangkau Control Plane

Sebagian besar aplikasi beroperasi pada data plane. Di lapisan ini, pengguna mengirim permintaan, aplikasi memproses data, database menyimpan informasi, dan API menghubungkan berbagai layanan.

Namun, lingkungan cloud juga memiliki control plane. Lapisan ini digunakan untuk membuat resource, mengubah konfigurasi, mengatur jaringan, memberikan permission, mengelola secret, serta mengaktifkan atau menonaktifkan logging.

Apabila pengujian hanya dilakukan pada aplikasi dan endpoint publik, kelemahan pada control plane dapat terlewat.

Pengguna yang tidak dapat membaca database secara langsung mungkin dapat mengubah security group database. Identitas yang tidak mempunyai akses ke storage mungkin dapat mengganti resource policy. Akun yang tidak boleh membuka secret mungkin dapat membuat workload baru dengan role yang memiliki akses tersebut.

Control plane menentukan bagaimana seluruh sumber daya cloud dikelola. Karena itu, kompromi terhadap lapisan ini dapat memberi dampak yang lebih luas daripada eksploitasi terhadap satu aplikasi.

Cloud pentest perlu menguji hubungan antara data plane, control plane, dan identity plane. Ketiganya tidak dapat dinilai secara terpisah karena serangan modern dapat berpindah dari satu lapisan ke lapisan lainnya.

Ruang Lingkup Cloud Pentest yang Lebih Relevan

Menentukan scope cloud pentest memerlukan informasi yang lebih lengkap daripada daftar IP dan domain.

Organisasi perlu memetakan penyedia cloud yang digunakan, jumlah akun atau project, lingkungan production dan non production, workload kritis, model identitas, integrasi pihak ketiga, arsitektur jaringan, serta jenis data yang diproses.

Beberapa area berikut sebaiknya dipertimbangkan dalam ruang lingkup pengujian.

Permukaan serangan eksternal

Pengujian tetap perlu mencakup domain, subdomain, IP publik, API, load balancer, storage endpoint, serta layanan manajemen yang dapat dijangkau dari internet.

Tujuannya adalah menemukan aset yang terekspos, konfigurasi yang tidak semestinya, serta layanan yang dapat digunakan sebagai titik masuk awal.

IAM dan kemungkinan privilege escalation

Penguji perlu mengevaluasi policy, role, service account, trust relationship, federasi identitas, akses lintas akun, dan permission yang memungkinkan pembuatan kredensial baru.

Fokusnya bukan hanya mencari akun administrator. Pengujian juga perlu mencari kombinasi izin yang memungkinkan identitas biasa memperoleh hak lebih tinggi secara langsung maupun tidak langsung.

Konfigurasi sumber daya cloud

Virtual machine, object storage, database, container registry, fungsi serverless, Kubernetes, message queue, secret manager, dan layanan lain perlu diperiksa sesuai konteks penggunaannya.

Konfigurasi default tidak selalu sesuai dengan kebutuhan keamanan organisasi. Selain itu, pengaturan yang awalnya aman dapat berubah setelah beberapa kali deployment atau penambahan integrasi.

Segmentasi jaringan

Security group, network access control, routing, peering, private endpoint, VPN, serta koneksi antar environment perlu diuji untuk memastikan segmentasi benar-benar bekerja.

Tujuan segmentasi bukan sekadar menyembunyikan resource dari internet. Segmentasi harus membatasi akses apabila satu workload atau identitas berhasil dikompromikan.

Pengelolaan secret

Pengujian perlu menilai apakah credential disimpan secara aman, menggunakan masa berlaku yang sesuai, dapat dirotasi, dan tidak tersebar dalam repository, log, image, maupun pipeline.

Identitas mesin sebaiknya menggunakan kredensial sementara ketika memungkinkan, sehingga kebocoran tidak memberikan akses dalam jangka panjang.

Logging dan kemampuan deteksi

Keberadaan log belum tentu berarti organisasi dapat mendeteksi serangan. Log mungkin hanya aktif pada sebagian layanan, tidak dikirim ke sistem terpusat, atau dapat dihapus oleh akun yang sedang disalahgunakan.

Pengujian perlu menilai apakah perubahan IAM, penggunaan role istimewa, pengambilan data dalam jumlah besar, dan upaya menonaktifkan kontrol keamanan dapat terdeteksi.

Cloud Security Assessment dan Cloud Pentest Memiliki Tujuan Berbeda

Cloud security assessment umumnya berfokus pada evaluasi postur keamanan. Tim pemeriksa membandingkan konfigurasi aktual dengan baseline, standar, kebijakan internal, dan praktik keamanan yang direkomendasikan.

Proses tersebut dapat menemukan storage yang terbuka, logging yang belum aktif, akun tanpa autentikasi multifaktor, permission berlebihan, atau resource yang tidak mengikuti standar organisasi.

Cloud pentest melangkah lebih jauh dengan memvalidasi kemungkinan eksploitasi. Penguji mencoba mengetahui apakah salah konfigurasi dapat digabungkan, apakah permission dapat digunakan untuk privilege escalation, dan apakah penyerang dapat berpindah menuju data atau sistem yang lebih sensitif.

Assessment menjelaskan apa yang tidak sesuai. Penetration testing menunjukkan apa yang dapat terjadi karena ketidaksesuaian tersebut.

Keduanya tidak perlu dipertentangkan. Organisasi dapat menggunakan assessment untuk memperoleh cakupan konfigurasi yang luas, kemudian menggunakan penetration testing untuk membuktikan risiko pada jalur serangan yang paling kritis.

Laporan Tidak Boleh Berhenti pada Daftar Kesalahan Konfigurasi

Laporan yang hanya menampilkan daftar policy, port, atau konfigurasi bermasalah belum tentu membantu perusahaan menentukan prioritas remediasi.

Pernyataan seperti “IAM policy menggunakan wildcard” memang menjelaskan adanya kelemahan. Namun, manajemen juga perlu mengetahui identitas mana yang memiliki policy tersebut, tindakan apa yang dapat dilakukan, resource mana yang berpotensi terdampak, serta apakah kelemahan itu dapat dikombinasikan dengan temuan lain.

Laporan cloud pentest yang relevan perlu menjelaskan prasyarat serangan, tahapan eksploitasi, kemungkinan privilege escalation, dampak terhadap data, dan kemampuan organisasi untuk mendeteksi aktivitas tersebut.

Informasi ini membantu tim teknis membedakan konfigurasi yang sekadar tidak ideal dari kelemahan yang dapat menjadi jalur kompromi nyata.

Prioritas perbaikan tidak seharusnya hanya ditentukan dari tingkat keparahan satu temuan. Perusahaan perlu melihat posisi temuan tersebut dalam keseluruhan attack path.

IP Publik yang Aman Baru Menunjukkan Lapisan Pertama

Mengamankan IP publik tetap menjadi bagian penting dalam keamanan cloud. Port yang tidak diperlukan harus ditutup. Layanan administratif perlu dibatasi. Sistem harus diperbarui. Aplikasi yang menghadap internet juga harus diuji secara berkala.

Namun, kontrol jaringan tidak dapat menggantikan kontrol identitas.

Firewall tidak dapat memperbaiki IAM policy yang terlalu luas. Web application firewall tidak dapat mencegah penyalahgunaan access key yang valid. Private subnet tidak dapat melindungi database apabila service account yang telah dikompromikan memiliki izin untuk mengaksesnya.

Demikian pula, autentikasi multifaktor pada akun karyawan tidak menyelesaikan risiko identitas mesin. Service account, workload role, token otomatisasi, dan credential integrasi memerlukan tata kelola yang berbeda.

Keamanan cloud membutuhkan kombinasi perlindungan jaringan, pengelolaan identitas, konfigurasi yang konsisten, pengamanan secret, logging, dan pengujian jalur serangan.

Pertanyaan yang Tepat Bukan Lagi Sekadar “Berapa IP yang Diuji?”

Cloud tidak selalu ditembus dengan mengeksploitasi server secara langsung. Penyerang dapat memanfaatkan identitas yang terlalu dipercaya, permission yang tidak dibatasi, secret yang bocor, atau hubungan antar layanan yang tidak pernah dievaluasi kembali.

Oleh sebab itu, cloud pentest tidak seharusnya hanya dihitung berdasarkan jumlah IP publik. Ruang lingkup pengujian perlu mencerminkan arsitektur nyata, termasuk akun cloud, workload, role, service account, API, storage, database, integrasi, dan jalur akses lintas sistem.

Perusahaan juga perlu memastikan bahwa hasil pengujian tidak berhenti pada daftar salah konfigurasi. Pengujian harus mampu menunjukkan apakah kelemahan dapat dieksploitasi, seberapa jauh akses dapat berkembang, dan aset bisnis apa yang berpotensi terdampak.

IP publik yang aman memang penting. Namun, dalam lingkungan cloud, keamanan yang sesungguhnya ditentukan oleh siapa yang dapat mengakses sumber daya, apa yang dapat dilakukan oleh identitas tersebut, serta bagaimana satu kesalahan dapat membuka jalan menuju sistem lain.

Perkuat Keamanan Cloud Bersama Fourtrezz

Fourtrezz membantu perusahaan mengidentifikasi dan memvalidasi risiko keamanan melalui layanan penetration testing dan vulnerability assessment. Pengujian dilakukan untuk menilai kelemahan pada aplikasi, API, jaringan, infrastruktur, serta hubungan antarkomponen yang dapat membentuk jalur serangan.

Dengan pendekatan yang disesuaikan terhadap arsitektur dan kebutuhan bisnis, Fourtrezz membantu organisasi memperoleh gambaran risiko yang lebih relevan, rekomendasi remediasi yang terarah, serta laporan pengujian yang dapat digunakan sebagai dasar peningkatan keamanan.

Bagi perusahaan yang sedang mengadopsi cloud, mengembangkan aplikasi, mempersiapkan audit, atau ingin mengevaluasi ketahanan sistem secara menyeluruh, Fourtrezz dapat menjadi mitra untuk merancang ruang lingkup pengujian yang sesuai dengan kondisi aktual lingkungan teknologi perusahaan.

Hubungi Fourtrezz:

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