Sebuah deployment baru saja melewati seluruh pemeriksaan keamanan.

Encryption aktif. Public access dinonaktifkan. Logging tersedia. Resource dibuat di region yang diperbolehkan. Naming convention sesuai standar. Infrastructure as Code lolos pemeriksaan tanpa pelanggaran.

Pipeline menunjukkan status hijau.

Secara teknis, semuanya terlihat benar.

Namun database yang baru dibuat tersebut menyimpan data sensitif pelanggan dan ternyata masih dapat diakses oleh beberapa workload yang tidak benar-benar membutuhkannya.

Tidak ada policy yang dilanggar.

Tetapi risiko tetap ada.

Situasi seperti inilah yang memperlihatkan keterbatasan mendasar dalam Policy-as-Code. Otomatisasi dapat memastikan aturan dijalankan secara konsisten, tetapi tidak dapat menjamin bahwa aturan yang dibuat sejak awal sudah memahami risiko bisnis yang sebenarnya ingin dicegah.

Dengan kata lain, cloud dapat patuh terhadap policy tetapi belum tentu aman.

Pipeline Hijau Tidak Berarti Risiko Sudah Hijau

Policy-as-Code membawa perubahan penting dalam cloud security.

Aturan yang sebelumnya berada dalam dokumen, spreadsheet, atau prosedur manual dapat diterjemahkan menjadi kode. Dengan pendekatan ini, perusahaan dapat melakukan pemeriksaan sebelum resource cloud dibuat atau sebelum perubahan konfigurasi masuk ke production.

Misalnya, organisasi dapat menentukan bahwa storage tidak boleh public, database harus menggunakan encryption, container tidak boleh berjalan dengan privilege tertentu, atau resource production hanya boleh dibuat pada region yang sudah disetujui.

Semua itu dapat diperiksa secara otomatis.

Masalah muncul ketika status PASS mulai diperlakukan sebagai bukti bahwa risiko juga telah terkendali.

Padahal policy engine hanya menjawab pertanyaan berdasarkan aturan yang diberikan kepadanya.

Jika sebuah organisasi tidak pernah membuat aturan mengenai siapa yang boleh mengakses database tertentu, policy engine tidak akan mempertanyakan akses tersebut.

Jika tidak ada rule mengenai hubungan antarsistem yang berbahaya, deployment dapat tetap dinyatakan berhasil.

Policy dapat bekerja dengan sempurna, sementara keputusan keamanan yang menjadi dasarnya masih belum lengkap.

Cloud Bisa Patuh terhadap Policy dan Tetap Memiliki Jalur Serangan

Bayangkan sebuah cloud storage yang berisi informasi penting perusahaan.

Policy mengharuskan resource tersebut tidak dapat diakses secara langsung dari internet.

Konfigurasinya memenuhi persyaratan.

Storage bersifat private.

Secara compliance, tidak ada persoalan.

Namun beberapa aplikasi internal memiliki permission untuk membacanya. Salah satu aplikasi tersebut memiliki vulnerability dan dapat diakses dari internet.

Dalam situasi seperti ini, attacker tidak perlu membuat storage menjadi public.

Cukup kompromikan aplikasi yang sudah memiliki akses.

Jalur serangannya menjadi:

Internet → Aplikasi → Identity → Cloud Storage

Tidak ada konfigurasi storage yang melanggar policy.

Namun data tetap dapat berada dalam risiko.

Contoh tersebut menunjukkan perbedaan antara configuration compliance dan security risk.

Security tidak hanya ditentukan oleh bagaimana satu resource dikonfigurasi. Risiko juga dipengaruhi oleh identity, dependency, network path, credential, authorization, serta hubungan antara satu komponen dan komponen lainnya.

Policy-as-Code yang hanya memeriksa konfigurasi individual dapat kehilangan konteks tersebut.

Policy Engine Tidak Tahu Mana Server Biasa dan Mana Sistem yang Menghentikan Bisnis

Dua database dapat terlihat hampir identik dari sisi konfigurasi.

Keduanya menggunakan encryption.

Keduanya private.

Keduanya memiliki logging.

Keduanya menjalankan database engine yang sama.

Namun Database A hanya digunakan untuk development.

Database B menyimpan data transaksi pelanggan yang dibutuhkan untuk menjalankan bisnis setiap hari.

Secara konfigurasi:

keduanya mungkin sama.

Secara risiko:

keduanya tidak sama.

Jika Database A berhenti selama satu jam, beberapa developer mungkin harus menunda pekerjaan.

Jika Database B berhenti selama satu jam, transaksi pelanggan dapat terganggu dan operasional bisnis berpotensi terdampak langsung.

Perbedaan inilah yang tidak otomatis dipahami oleh policy engine.

Mesin hanya mengetahui informasi yang diberikan kepadanya.

Jika organisasi tidak memasukkan klasifikasi aset, sensitivitas data, criticality, environment, atau ownership sebagai bagian dari keputusan policy, semua resource berpotensi diperlakukan dengan cara yang sama.

Padahal security yang baik membutuhkan prioritas.

Tidak semua server memiliki nilai yang sama.

Tidak semua data memiliki dampak yang sama jika bocor.

Tidak semua vulnerability harus mendapatkan respons dengan tingkat urgensi yang sama.

Dan tidak semua policy seharusnya diterapkan tanpa mempertimbangkan konteks tersebut.

Semakin Banyak Policy Tidak Selalu Berarti Semakin Aman

Ketika organisasi mulai mengadopsi cloud governance, jumlah policy biasanya berkembang.

Awalnya mungkin terdapat beberapa aturan dasar.

Kemudian bertambah menjadi puluhan.

Seiring pertumbuhan cloud environment, jumlahnya dapat meningkat menjadi ratusan.

Ada policy untuk networking.

Ada policy untuk IAM.

Ada policy untuk container.

Ada policy untuk encryption.

Ada policy untuk tagging.

Ada policy untuk region.

Ada policy untuk logging.

Jumlah rule yang semakin besar dapat memberikan kesan bahwa sistem semakin terlindungi.

Namun jumlah policy bukan ukuran langsung dari kualitas cloud security.

Organisasi dapat memiliki 500 rule dan tetap melewatkan satu jalur serangan yang sangat penting.

Sebaliknya, perusahaan dengan jumlah policy lebih sedikit tetapi disusun berdasarkan pemahaman risiko yang matang dapat memiliki kontrol yang lebih relevan.

Masalah semakin kompleks ketika policy mulai saling bertumpuk.

Beberapa rule mungkin tidak lagi relevan.

Sebagian memiliki tujuan yang mirip.

Sebagian lagi dibuat untuk memenuhi kebutuhan sementara tetapi tidak pernah ditinjau kembali.

Pada titik tertentu, perusahaan tidak hanya memiliki technical debt.

Mereka juga dapat memiliki policy debt.

Aturan terus bertambah, tetapi semakin sedikit orang yang memahami alasan mengapa aturan tersebut dibuat.

Policy yang Tidak Memahami Operasional Akan Melahirkan Exception

Aturan keamanan biasanya dibuat dengan niat yang baik.

Misalnya:

“Storage tidak boleh public.”

Untuk sebagian besar sistem, aturan tersebut tepat.

Namun kemudian muncul aplikasi yang memang membutuhkan beberapa file agar dapat diakses publik.

Tim meminta exception.

Beberapa bulan kemudian muncul proyek lain dengan kebutuhan berbeda.

Exception kedua dibuat.

Kemudian hadir aplikasi lama yang belum dapat mengikuti baseline baru.

Exception berikutnya diberikan.

Akhirnya struktur policy tidak lagi sesederhana:

Allow atau Deny.

Mulai muncul:

Allow if...

Except when...

Temporary approval...

Legacy system...

Special project...

Exception sendiri bukan sesuatu yang selalu buruk. Sistem bisnis memang memiliki kebutuhan yang berbeda.

Masalah terjadi ketika exception tidak dikelola sebagai risiko.

Sebuah pengecualian seharusnya memiliki alasan, pemilik, ruang lingkup, compensating control, tanggal evaluasi, dan masa berlaku.

Tanpa governance seperti itu, exception dapat bertahan jauh lebih lama dibandingkan kebutuhan awalnya.

Policy terlihat ketat di atas kertas, tetapi memiliki terlalu banyak pintu samping dalam implementasinya.

Policy yang Terlalu Ketat Juga Dapat Menjadi Risiko

Cloud security bukan kompetisi untuk membuat rule sebanyak dan seketat mungkin.

Policy yang terlalu longgar jelas berbahaya.

Namun policy yang terlalu ketat dan tidak sesuai dengan kebutuhan operasional juga dapat menghasilkan persoalan baru.

Bayangkan setiap deployment developer terus mengalami kegagalan karena policy yang sebenarnya tidak relevan dengan workload mereka.

Pada tahap awal, developer mungkin meminta penyesuaian.

Jika prosesnya terlalu lama, mereka dapat mulai mencari cara lain.

Muncul deployment manual.

Muncul temporary bypass.

Muncul environment yang dibuat di luar workflow standar.

Muncul resource yang sengaja dikonfigurasi dengan cara tertentu agar tidak terkena pemeriksaan.

Kontrol yang awalnya dibuat untuk meningkatkan keamanan justru mendorong terjadinya security workaround.

Karena itu policy perlu cukup kuat untuk membatasi risiko, tetapi juga cukup realistis untuk digunakan oleh tim engineering.

Guardrail yang baik seharusnya membantu developer mengambil keputusan yang aman, bukan sekadar menghentikan pekerjaan.

Compliance-as-Code Bisa Membuat Organisasi Terlalu Nyaman dengan Checklist

Automation sangat efektif untuk menjawab pertanyaan yang jelas.

Apakah encryption aktif?

Ya atau tidak.

Apakah storage public?

Ya atau tidak.

Apakah logging aktif?

Ya atau tidak.

Namun risiko bisnis jarang sesederhana itu.

Pertanyaan yang lebih penting sering kali berbentuk:

Siapa yang masih dapat membaca data setelah encryption aktif?

Apakah aktivitas berbahaya benar-benar dapat dideteksi dari audit log yang dikumpulkan?

Apakah compromised workload dapat mengakses database meskipun database tidak public?

Apakah service account memiliki privilege lebih besar daripada kebutuhan aplikasinya?

Seberapa jauh attacker dapat bergerak jika satu credential berhasil diperoleh?

Pertanyaan seperti ini membutuhkan konteks.

Inilah alasan mengapa compliance dan security tidak dapat diperlakukan sebagai hal yang sepenuhnya sama.

Compliance dapat membuktikan bahwa sebuah kontrol tersedia.

Security harus mempertanyakan apakah kontrol tersebut benar-benar mengurangi kemungkinan atau dampak serangan.

Masalah Sebenarnya Dimulai Sebelum Policy Ditulis

Dalam banyak implementasi, diskusi Policy-as-Code terlalu cepat masuk ke tool.

Tim memilih policy engine.

Kemudian membuat rule.

Rule dimasukkan ke repository.

Pipeline mulai melakukan enforcement.

Pendekatan tersebut terlihat efisien, tetapi ada satu lapisan penting yang dapat terlewat:

Mengapa policy tersebut diperlukan?

Sebelum sebuah rule ditulis, seharusnya sudah ada pemahaman mengenai aset yang ingin dilindungi.

Apa fungsi aset tersebut bagi bisnis?

Data apa yang disimpan?

Siapa yang membutuhkan akses?

Ancaman apa yang relevan?

Apa yang terjadi apabila kontrol gagal?

Bagaimana attacker mungkin mencapai aset tersebut?

Dari pertanyaan itulah security requirement seharusnya muncul.

Alurnya menjadi:

Business Context → Threat Modeling → Risk Assessment → Security Requirement → Policy → Automated Enforcement

Masalah terjadi ketika organisasi membalik urutannya:

Tool → Rule → Enforcement

kemudian berharap risiko bisnis secara otomatis ikut berkurang.

Automation tidak dapat menggantikan keputusan yang belum pernah dibuat.

Policy-as-Code Seharusnya Menjadi Hasil Risk Assessment, Bukan Penggantinya

Policy-as-Code bekerja paling baik ketika aturan yang diterapkan berasal dari pemahaman risiko.

Misalnya, perusahaan mengetahui bahwa sistem autentikasi merupakan komponen kritis.

Dari threat modeling diketahui bahwa kompromi terhadap identity yang memiliki akses administratif dapat memberikan dampak besar.

Dari situ muncul security requirement:

akses administratif harus sangat terbatas.

Requirement tersebut kemudian diterjemahkan menjadi policy yang dapat dieksekusi secara otomatis.

Dalam pola seperti ini, Policy-as-Code menjadi lapisan enforcement.

Ia menjaga agar keputusan keamanan yang telah dibuat tidak hanya tinggal dalam dokumen.

Sebaliknya, Policy-as-Code menjadi berbahaya jika organisasi menganggap policy engine dapat menentukan sendiri apa yang penting bagi bisnis.

Tool mengetahui rule.

Bisnis mengetahui dampak.

Keduanya harus dihubungkan.

Satu Policy Tidak Seharusnya Memperlakukan Semua Workload sebagai Risiko yang Sama

Standardisasi merupakan salah satu keuntungan besar cloud governance.

Namun standardisasi bukan berarti seluruh resource harus memiliki perlakuan yang identik.

Organisasi dapat menggunakan pendekatan berbasis tingkat risiko.

Misalnya, workload dengan kategori critical dapat mencakup sistem transaksi, authentication, data pelanggan, atau sistem inti operasional.

Sistem tersebut dapat memiliki persyaratan keamanan lebih ketat, seperti pembatasan IAM yang lebih kuat, akses jaringan terbatas, logging yang lebih lengkap, separation of duties, dan deployment identity dengan privilege minimum.

Sementara itu, workload development yang hanya menggunakan data dummy mungkin dapat memiliki ruang gerak yang sedikit lebih fleksibel.

Perbedaannya bukan karena keamanan development tidak penting.

Perbedaannya terletak pada dampak bisnis jika terjadi kegagalan.

Cloud governance yang matang tidak hanya berkata:

“Semua database harus mengikuti rule ini.”

Tetapi juga memahami:

“Database seperti apa yang sedang kita lindungi?”

Context-Aware Policy Lebih Bernilai daripada Sekadar Menambah Rule

Policy akan menjadi lebih efektif ketika konteks mulai dimasukkan ke dalam keputusan.

Tidak cukup hanya melihat:

resource type.

Policy idealnya juga dapat mempertimbangkan:

• environment;
• data classification;
• business criticality;
• owner;
• internet exposure;
• identity;
• dependency;
• serta kebutuhan operasional.

Misalnya, rule sederhana mengatakan:

“Database tidak boleh memiliki public endpoint.”

Rule berbasis konteks dapat lebih spesifik:

“Database production yang memproses data sensitif tidak boleh memiliki public endpoint dan hanya boleh diakses oleh workload yang telah ditentukan.”

Perbedaannya terlihat kecil, tetapi secara konseptual sangat besar.

Policy pertama memahami konfigurasi.

Policy kedua mulai memahami alasan keamanan di balik konfigurasi.

Inilah arah yang seharusnya dituju dalam cloud governance berbasis risiko.

Policy Harus Diuji seperti Software, tetapi Itu Belum Cukup

Salah satu keunggulan Policy-as-Code adalah policy dapat diperlakukan seperti software.

Perubahan dapat disimpan melalui version control.

Developer dan security engineer dapat melakukan review.

Policy dapat memiliki test.

Perubahan dapat dilacak.

Versi sebelumnya dapat dibandingkan.

Rule baru dapat diuji sebelum diterapkan.

Pendekatan ini jauh lebih baik dibandingkan kebijakan yang hanya tersimpan dalam dokumen dan bergantung pada pemeriksaan manual.

Namun ada perbedaan penting yang tidak boleh dilewatkan.

Test dapat membuktikan bahwa policy melakukan apa yang ditulis.

Test tidak otomatis membuktikan bahwa organisasi menulis policy yang benar.

Jika sebuah policy salah memahami kebutuhan bisnis, test yang sempurna hanya akan memastikan kesalahan tersebut diterapkan secara konsisten.

Karena itu review policy tidak boleh hanya menilai syntax dan logic.

Tim juga harus kembali mempertanyakan tujuan risikonya.

Policy yang Tidak Pernah Ditinjau Akan Menjadi Legacy Code Keamanan

Cloud environment tidak pernah benar-benar statis.

Arsitektur berubah.

Aplikasi bertambah.

Data berpindah.

Integrasi baru dibuat.

Cara pelanggan menggunakan layanan berubah.

Ancaman juga berkembang.

Policy yang relevan hari ini belum tentu memiliki prioritas yang sama dua tahun kemudian.

Karena itu policy membutuhkan lifecycle.

Create → Review → Test → Enforce → Observe → Reassess → Update atau Retire

Bukan:

Create → Enforce → Forget

Setiap policy idealnya memiliki ownership yang jelas.

Mengapa policy dibuat?

Risiko apa yang ingin dicegah?

Siapa yang bertanggung jawab mengevaluasinya?

Kapan terakhir ditinjau?

Masih relevankah rule tersebut?

Apakah terlalu banyak exception?

Apakah pernah menyebabkan workaround?

Pertanyaan ini membantu mencegah policy berubah menjadi legacy control yang dipertahankan hanya karena tidak ada seorang pun yang berani menghapusnya.

Risiko Baru Terlihat ketika Policy Dibandingkan dengan Jalur Serangan Nyata

Configuration scanner dapat mengatakan bahwa sebuah resource memenuhi baseline.

Namun attacker tidak melihat sistem sebagai kumpulan checklist.

Attacker melihat hubungan.

Aplikasi mana yang dapat diakses?

Credential apa yang dapat diperoleh?

Identity tersebut memiliki permission apa?

Dari sana dapat berpindah ke mana?

Resource apa yang akhirnya dapat dicapai?

Misalnya, aplikasi public telah memenuhi seluruh policy cloud.

Namun vulnerability pada aplikasi memungkinkan attacker mengambil credential workload.

Credential tersebut kemudian memiliki akses menuju resource internal.

Resource internal selanjutnya memiliki hubungan dengan sistem lain yang lebih kritis.

Setiap resource mungkin terlihat patuh ketika diperiksa secara terpisah.

Tetapi ketika dihubungkan, terbentuk attack path.

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

Kondisi tersebut menjadi alasan mengapa automated policy enforcement sebaiknya dilengkapi dengan pengujian keamanan yang melihat sistem dari perspektif serangan nyata.

Policy bertanya:

“Apakah konfigurasi ini diperbolehkan?”

Penetration testing dapat membantu mempertanyakan:

“Jika kontrol ini gagal, seberapa jauh sistem dapat ditembus?”

Keduanya menjawab persoalan berbeda.

Lima Pertanyaan Sebelum Membuat Policy Baru

Sebelum menambahkan puluhan rule baru ke cloud environment, perusahaan sebaiknya kembali kepada beberapa pertanyaan mendasar.

Risiko apa yang sebenarnya ingin dicegah?

Jangan berhenti pada konfigurasi yang ingin diblokir. Tentukan skenario ancamannya.

Aset apa yang sedang dilindungi?

Resource development dan sistem transaksi production tidak memiliki konsekuensi yang sama.

Apa dampaknya jika policy gagal?

Apakah hanya menimbulkan gangguan kecil, atau dapat menyebabkan kebocoran data dan terhentinya layanan utama?

Apakah tim engineering dapat mematuhi policy tanpa membutuhkan workaround?

Policy yang tidak realistis biasanya hanya menghasilkan exception.

Bagaimana exception akan dikendalikan?

Tetapkan owner, alasan, persetujuan, compensating control, serta kapan pengecualian tersebut harus dievaluasi kembali.

Lima pertanyaan ini lebih penting daripada sekadar menanyakan berapa banyak rule yang telah berhasil diotomatisasi.

Cloud Security yang Matang Tidak Hanya Mengotomatisasi Aturan

Policy-as-Code tetap merupakan bagian penting dari cloud security modern.

Ia membantu membuat enforcement lebih cepat, konsisten, terukur, dapat diuji, dan lebih mudah diterapkan dalam skala besar.

Namun automation memiliki batas yang sangat jelas.

Automation hanya dapat mengeksekusi keputusan yang sudah berhasil diterjemahkan menjadi aturan.

Jika keputusan tersebut berangkat dari pemahaman risiko yang matang, Policy-as-Code dapat memperkuat keamanan secara signifikan.

Namun jika policy hanya berasal dari checklist generik, automation akan membuat checklist tersebut berjalan lebih cepat tanpa menjamin bahwa risiko terpenting benar-benar dikendalikan.

Karena itu ukuran kedewasaan cloud security bukan seberapa banyak policy yang berhasil dibuat.

Pertanyaan yang lebih penting adalah:

Apakah policy tersebut benar-benar menjaga sesuatu yang penting bagi bisnis?

Dan ketika seluruh policy menunjukkan status hijau, organisasi masih perlu berani menanyakan satu pertanyaan tambahan:

Jika attacker menyerang hari ini, apakah jalur menuju aset kritis benar-benar sudah tertutup?

Validasi Keamanan Cloud Anda Bersama Fourtrezz

Policy-as-Code dapat membantu mencegah konfigurasi yang tidak sesuai standar, tetapi pengujian keamanan tetap diperlukan untuk mengetahui bagaimana sebuah kelemahan dapat dimanfaatkan dalam kondisi nyata.

Fourtrezz membantu perusahaan mengevaluasi keamanan sistem melalui layanan Penetration Testing dan Vulnerability Assessment, serta layanan cybersecurity dan pengembangan sistem dengan pendekatan keamanan.

Pengujian dapat membantu perusahaan melihat risiko yang tidak selalu muncul dari pemeriksaan compliance atau policy otomatis, mulai dari kelemahan aplikasi, kesalahan konfigurasi, kontrol akses, hingga kemungkinan terbentuknya jalur serangan menuju aset penting.

Jika perusahaan Anda menggunakan cloud infrastructure, aplikasi berbasis API, CI/CD, atau Infrastructure as Code dan ingin memastikan bahwa kontrol keamanan tidak hanya terlihat patuh tetapi juga mampu menghadapi skenario serangan nyata, Fourtrezz dapat menjadi partner untuk melakukan evaluasi tersebut.

Hubungi Fourtrezz:

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