Di era cloud-native, cara tim DevOps mengelola infrastruktur telah berubah total. Server tidak lagi dirakit secara manual satu per satu. Infrastructure as Code (IaC) memungkinkan tim mendefinisikan seluruh arsitektur cloud, mulai dari virtual machine, load balancer, hingga firewall, dalam bentuk file konfigurasi yang bisa di-version control seperti kode aplikasi. Namun di balik kemudahan ini, ada risiko besar yang sering luput dari perhatian: satu baris konfigurasi yang salah bisa membuka akses publik ke database produksi.
3| 4| 5| 6|Menurut laporan Cloud Security Alliance (CSA) tahun 2024, miskonfigurasi cloud, termasuk yang berasal dari template IaC, menjadi penyebab utama kebocoran data dalam tiga tahun terakhir. Kasus nyata terjadi pada Football Australia di tahun 2024, di mana developer secara tidak sengaja mengonfigurasi S3 bucket sebagai publik melalui template IaC mereka, mengekspos data sensitif lebih dari 100.000 pengguna. Kejadian ini menunjukkan bahwa keamanan harus dibangun dari tahap paling awal, bukan ditambahkan setelah infrastruktur berjalan.
7| 8| 9| 10|Artikel ini akan membahas secara lengkap apa itu IaC Security, mengapa ia menjadi krusial di era DevOps modern, risiko utama yang mengintai, praktik terbaik pengamanannya, serta tools yang bisa digunakan untuk memindai kerentanan sejak tahap pengembangan.
11| 12| 13| 14|Apa Itu Infrastructure as Code (IaC)?
15| 16| 17| 18|Infrastructure as Code (IaC) adalah praktik mengelola dan menyediakan infrastruktur komputasi melalui file konfigurasi yang dapat dibaca mesin, alih-alih melalui konfigurasi manual atau alat GUI interaktif. Dengan IaC, tim dapat mendefinisikan server, jaringan, storage, dan layanan cloud dalam file teks yang disimpan di repositori Git.
19| 20| 21| 22|Pendekatan ini membawa keuntungan besar: konsistensi, karena infrastruktur yang sama akan dihasilkan setiap kali file dijalankan; kecepatan, karena provisioning bisa dilakukan dalam hitungan menit; dan auditability, karena setiap perubahan tercatat di version control. Tools populer yang digunakan antara lain Terraform dari HashiCorp, AWS CloudFormation, Ansible, Pulumi, dan ARM Templates untuk Azure.
23| 24| 25| 26|Namun, kemudahan ini juga berarti bahwa kesalahan sekecil apa pun di file konfigurasi akan direplikasi secara massal. Jika template Terraform mendefinisikan security group dengan port 22 terbuka ke seluruh internet (0.0.0.0/0), maka ratusan server yang diprovisioning dari template tersebut akan memiliki celah keamanan yang identik. Inilah mengapa IaC Security menjadi prioritas dalam strategi DevSecOps modern.
27| 28| 29| 30|
34|Mengapa Keamanan IaC Sangat Penting di Era Cloud?
39| 40| 41| 42|Berdasarkan data dari berbagai laporan industri, setidaknya 70 persen pelanggaran keamanan cloud berawal dari miskonfigurasi, bukan dari eksploitasi kerentanan zero-day yang canggih. Miskonfigurasi ini sering kali berasal dari template IaC yang tidak melalui proses review keamanan sebelum diterapkan ke production.
43| 44| 45| 46|OWASP (Open Web Application Security Project) melalui IaC Security Cheat Sheet-nya menekankan bahwa file IaC harus diperlakukan dengan tingkat keamanan yang sama seperti kode aplikasi. Artinya, setiap perubahan harus melalui code review, static analysis, dan pengujian keamanan sebelum di-merge ke branch utama.
47| 48| 49| 50|Ada tiga alasan utama mengapa IaC Security menjadi kritis: pertama, skala ledakan kesalahan – satu miskonfigurasi bisa berdampak ke puluhan atau ratusan resource sekaligus. Kedua, kecepatan deployment – pipeline CI/CD modern bisa mendeploy perubahan dalam hitungan menit, termasuk perubahan yang berbahaya. Ketiga, kompleksitas multi-cloud – tim yang mengelola AWS, Azure, dan GCP secara bersamaan menghadapi permukaan serangan yang jauh lebih luas. Baca juga: Apa Itu Cloud Security? Panduan Lengkap Mengamankan Data dan Infrastruktur di Era Cloud untuk memahami fondasi keamanan cloud.
51| 52| 53| 54|Apa Saja Risiko Keamanan Utama dalam Infrastructure as Code?
55| 56| 57| 58|Risiko keamanan dalam IaC tidak selalu terlihat jelas. Tidak seperti kode aplikasi yang bisa diuji dengan penetration testing tradisional, kerentanan di file IaC sering kali bersifat silent, baru terdeteksi setelah infrastruktur berjalan di production. Berikut adalah risiko-risiko utama yang perlu diwaspadai:
59| 60| 61| 62|1. Over-Permissive IAM Roles dan Policy
63| 64| 65| 66|Risiko paling umum dalam file IaC adalah pemberian hak akses yang terlalu luas. Contoh klasik: mendefinisikan IAM policy dengan Action: “*” dan Resource: “*” untuk sebuah service account. Ini memberikan akses penuh ke seluruh resource di akun cloud, melanggar prinsip least privilege yang menjadi fondasi keamanan cloud.
67| 68| 69| 70|Dalam file Terraform, ini bisa terlihat sederhana namun mematikan. Satu blok aws_iam_role_policy dengan permission yang terlalu luas sudah cukup untuk memberi penyerang yang berhasil mengkompromikan service account tersebut akses penuh ke seluruh infrastruktur.
2. Storage Bucket dan Database Publik
75| 76| 77| 78|Kasus kebocoran data paling banyak disebabkan oleh storage bucket yang tidak sengaja dikonfigurasi sebagai publik. Dalam IaC, ini terjadi ketika atribut seperti acl = "public-read" atau public_access = true ditetapkan tanpa sengaja, atau ketika block public access settings tidak dikonfigurasi secara eksplisit.
Insiden Football Australia 2024 adalah contoh nyata dari risiko ini. Developer menggunakan template CloudFormation yang mendefinisikan S3 bucket tanpa mengaktifkan Block Public Access, dan template tersebut langsung diterapkan ke production tanpa review keamanan. Hasilnya: data lebih dari 100.000 pengguna terekspos ke internet publik.
83| 84| 85| 86|3. Hardcoded Secrets dan Kredensial
87| 88| 89| 90|Salah satu praktik paling berbahaya adalah menanamkan kredensial, API key, atau token akses langsung di file IaC. Ini sering terjadi ketika developer ingin mempercepat development, menulis password database atau secret key langsung di file Terraform, lalu lupa menghapusnya sebelum commit.
91| 92| 93| 94|File IaC disimpan di repositori Git. Begitu secret masuk ke version history, membersihkannya menjadi sangat sulit, bahkan setelah dihapus di commit terbaru. Penyerang yang mendapat akses ke repositori, baik melalui credential leak maupun insider threat, bisa menelusuri history commit dan menemukan kredensial yang masih valid. Baca juga: Apa Itu Secrets Management? Panduan Lengkap Mengamankan Kredensial dan API Key di Pipeline CI/CD untuk strategi pengelolaan kredensial yang aman.
95| 96| 97| 98|4. Security Group dan Firewall Rules Terlalu Terbuka
99| 100| 101| 102|Mendefinisikan security group dengan akses dari 0.0.0.0/0 (seluruh internet) ke port SSH (22) atau RDP (3389) adalah kesalahan klasik yang masih sering ditemukan di file IaC production. Ini pada dasarnya membuka pintu server ke seluruh dunia.
103| 104| 105| 106|Bahkan untuk port web seperti 80 dan 443, aturan inbound seharusnya hanya membuka akses ke load balancer, bukan langsung ke setiap instance. File IaC yang baik harus mendefinisikan security group dengan source yang spesifik, seperti IP office atau security group ID internal.
107| 108| 109| 110|5. Encryption yang Tidak Diaktifkan
111| 112| 113| 114|Banyak resource cloud secara default tidak mengaktifkan enkripsi. File IaC yang tidak secara eksplisit mengkonfigurasi enkripsi untuk database (RDS), storage (S3, EBS), atau message queue (SQS) akan meninggalkan data dalam keadaan tidak terenkripsi. Dalam konteks kepatuhan terhadap regulasi seperti UU PDP (Perlindungan Data Pribadi) di Indonesia, ini bisa berakibat sanksi serius.
115| 116| 117| 118|
122|Bagaimana Cara Mengamankan Infrastructure as Code?
127| 128| 129| 130|Mengamankan IaC membutuhkan pendekatan berlapis yang terintegrasi ke dalam pipeline development. NIST SP 800-204D, panduan dari National Institute of Standards and Technology, merekomendasikan integrasi keamanan ke setiap tahap siklus hidup development, termasuk saat infrastruktur didefinisikan sebagai kode. Berikut adalah langkah-langkah praktis yang bisa diterapkan:
131| 132| 133| 134|1. Terapkan Policy as Code
135| 136| 137| 138|Policy as Code (PaC) adalah pendekatan di mana aturan keamanan dan kepatuhan ditulis sebagai kode yang bisa diuji secara otomatis. Tools seperti Open Policy Agent (OPA) dan HashiCorp Sentinel memungkinkan tim mendefinisikan kebijakan seperti “tidak boleh ada S3 bucket yang public” atau “semua RDS instance wajib mengaktifkan enkripsi” dalam file yang bisa di-version control.
139| 140| 141| 142|Setiap kali developer membuat pull request yang mengubah file Terraform, pipeline CI/CD akan menjalankan OPA untuk memvalidasi bahwa perubahan tersebut tidak melanggar kebijakan keamanan yang telah ditetapkan. Jika melanggar, pipeline akan gagal secara otomatis, mencegah konfigurasi berbahaya mencapai production.
143| 144| 145| 146|2. Lakukan Static Analysis pada File IaC
147| 148| 149| 150|Sama seperti kode aplikasi yang diperiksa dengan SAST (Static Application Security Testing), file IaC juga bisa dipindai secara statis menggunakan tools khusus. Checkov dari Bridgecrew, TFSec, Terrascan, dan KICS adalah beberapa tools open source yang bisa mendeteksi miskonfigurasi keamanan di template Terraform, CloudFormation, Kubernetes, dan ARM.
151| 152| 153| 154|Tools ini memiliki aturan bawaan yang mencakup berbagai compliance framework seperti CIS Benchmarks, PCI DSS, dan HIPAA. Misalnya, Checkov akan otomatis mendeteksi jika sebuah file Terraform mendefinisikan security group dengan akses SSH terbuka ke 0.0.0.0/0 dan menandainya sebagai FAILED.
155| 156| 157| 158|3. Integrasikan Secret Scanning
159| 160| 161| 162|Secret scanning harus berjalan di dua titik: pre-commit (sebelum kode masuk ke repositori) dan di pipeline CI/CD. Tools seperti git-secrets, truffleHog, dan Gitleaks bisa dipasang sebagai git hook yang memindai setiap commit untuk mendeteksi pola kredensial seperti AWS Access Key, private key, atau token API.
163| 164| 165| 166|Di sisi pipeline, tools seperti GitGuardian atau Vault dari HashiCorp bisa melakukan pemindaian mendalam terhadap history repositori untuk mendeteksi secret yang mungkin sudah lama tersimpan. Jika ditemukan, sistem harus segera melakukan rotasi pada kredensial tersebut.
167| 168| 169| 170|4. Gunakan Version Control dan Code Review Wajib
171| 172| 173| 174|Semua file IaC harus disimpan di sistem version control seperti Git, dan setiap perubahan wajib melalui proses pull request dan code review. Reviewer harus memeriksa aspek keamanan secara spesifik: apakah ada IAM policy yang terlalu luas? Apakah storage bucket aman? Apakah enkripsi sudah diaktifkan?
175| 176| 177| 178|Praktik branch protection seperti mewajibkan minimal satu approval dari tim keamanan sebelum merge ke main branch adalah langkah sederhana namun sangat efektif. Pipeline CI/CD juga harus dikonfigurasi agar tidak bisa di-bypass.
179| 180| 181| 182|5. Pantau Drift Detection Secara Berkala
183| 184| 185| 186|Drift adalah kondisi di mana konfigurasi aktual infrastruktur di cloud tidak lagi sesuai dengan yang didefinisikan di file IaC. Ini bisa terjadi karena perubahan manual melalui console cloud, emergency fix yang tidak tercatat, atau bahkan aktivitas penyerang yang sudah masuk ke sistem.
187| 188| 189| 190|Tools seperti Terraform refresh dan AWS Config bisa secara berkala membandingkan state aktual dengan yang didefinisikan di kode. Setiap penyimpangan harus segera diinvestigasi dan diperbaiki. Drift yang tidak tertangani adalah celah keamanan yang menunggu untuk dieksploitasi.
191| 192| 193| 194|
198|Apa Saja Tools Open Source untuk IaC Security?
203| 204| 205| 206|Eksekusi praktik keamanan di atas membutuhkan tools yang tepat. Berikut adalah tools open source paling populer yang bisa langsung diintegrasikan ke pipeline CI/CD:
207| 208| 209| 210|- Checkov – Static analysis untuk Terraform, CloudFormation, Kubernetes, ARM, dan Helm. Mencakup lebih dari 750 aturan bawaan dan mendukung custom policy. Bisa diintegrasikan ke GitHub Actions, GitLab CI, Jenkins, dan CircleCI. 211| 212|
- Terrascan – Static code analyzer dari Tenable untuk IaC. Mendukung 500+ aturan keamanan dan compliance. Bisa dijalankan sebagai pre-commit hook atau di pipeline CI/CD. 213| 214|
- KICS (Keeping Infrastructure as Code Secure) – Open source project dari Checkmarx yang mendukung Terraform, Kubernetes, Docker, Ansible, dan CloudFormation. Memiliki lebih dari 2.000 query keamanan. 215| 216|
- TFSec – Static analysis khusus untuk Terraform dari Aqua Security. Fokus pada best practices keamanan AWS, Azure, dan GCP. 217| 218|
- OPA (Open Policy Agent) – Policy engine general-purpose yang memungkinkan tim menulis aturan keamanan sebagai kode menggunakan bahasa Rego. Bisa digunakan untuk validasi file Terraform, Kubernetes admission control, dan API authorization. 219| 220|
- truffleHog – Secret scanner yang mencari kredensial di repositori Git, termasuk di history commit. Menggunakan deteksi entropy dan regex untuk menemukan secret yang tidak sengaja tercommit.
Masing-masing tools ini bisa dijalankan secara lokal di mesin developer maupun di pipeline CI/CD. Kombinasi beberapa tools memberikan coverage yang lebih luas. Misalnya, Checkov untuk miskonfigurasi dan truffleHog untuk secret detection. Baca juga: Apa Itu DevSecOps? Panduan Lengkap Mengintegrasikan Keamanan dalam Pipeline Development untuk memahami cara mengintegrasikan tools ini ke dalam pipeline secara menyeluruh.
225| 226| 227| 228|Pertanyaan Umum tentang IaC Security
229| 230| 231| 232|Apakah IaC Security hanya relevan untuk perusahaan besar?
233| 234| 235| 236|Tidak. Startup dan UKM yang menggunakan cloud justru sering menjadi target karena biasanya memiliki praktik keamanan yang lebih longgar. Miskonfigurasi S3 bucket publik bisa terjadi di perusahaan dengan satu developer maupun seribu developer. Tools open source yang tersedia gratis membuat IaC Security bisa diterapkan oleh tim dengan ukuran apa pun.
237| 238| 239| 240|Apa perbedaan antara IaC Security scanning dan Cloud Security Posture Management (CSPM)?
241| 242| 243| 244|IaC Security scanning berfokus pada pencegahan – mendeteksi miskonfigurasi di file template sebelum di-deploy ke cloud. Sementara CSPM berfokus pada deteksi – memindai resource yang sudah berjalan di cloud untuk menemukan miskonfigurasi. Keduanya saling melengkapi: IaC scanning mencegah masalah, CSPM mendeteksi yang lolos.
245| 246| 247| 248|Bisakah saya hanya mengandalkan tools scanning tanpa code review manual?
249| 250| 251| 252|Tidak disarankan. Tools scanning otomatis sangat membantu, tetapi tidak bisa menangkap semua risiko kontekstual. Code review oleh engineer yang memahami arsitektur dan konteks bisnis tetap diperlukan untuk mengidentifikasi risiko yang tidak terdeteksi oleh aturan otomatis.
253| 254| 255| 256|Apakah Terraform dan CloudFormation memiliki risiko yang berbeda?
257| 258| 259| 260|Keduanya memiliki risiko yang serupa secara fundamental, yaitu potensi miskonfigurasi. Namun, Terraform menggunakan HCL (HashiCorp Configuration Language) yang memiliki fitur seperti variabel, modul, dan state management yang bisa menimbulkan celah spesifik, seperti state file yang mengandung secret jika tidak dikelola dengan benar. CloudFormation terintegrasi lebih ketat dengan AWS, tetapi tetap membutuhkan scanning yang sama ketatnya.
261| 262| 263| 264|Kesimpulan
265| 266| 267| 268|Infrastructure as Code telah mengubah cara tim membangun dan mengelola cloud. Namun kemampuannya untuk menduplikasi konfigurasi dalam skala besar juga berarti bahwa satu kesalahan kecil bisa berdampak masif. Keamanan IaC bukan sekadar best practice tambahan, melainkan fondasi yang harus dibangun sejak awal dalam pipeline DevSecOps.
269| 270| 271| 272|Implementasi Policy as Code, static analysis, secret scanning, code review wajib, dan drift detection adalah lima pilar utama yang membentuk strategi IaC Security yang solid. Dengan tools open source seperti Checkov, OPA, dan truffleHog yang tersedia secara gratis, tidak ada alasan bagi tim mana pun untuk menunda integrasi keamanan ke dalam pipeline infrastructure mereka.
273| 274| 275| 276|Keamanan infrastruktur dimulai dari baris pertama kode yang ditulis, bukan setelah server berjalan di production. Mulailah dengan mengintegrasikan satu tool scanning ke pipeline CI/CD tim, dan bangun dari sana secara bertahap.
277| 278| 279| 287|