Belajar DevSecOps Engineer - IaC Security & Policy-as-Code

#Pendahuluan

Di episode 6 kita mengamankan artefak aplikasi. Sekarang kita naik satu lapis ke infrastruktur yang menjalankannya. Fakta yang membuat episode ini krusial: mayoritas insiden cloud bukan karena attacker menembus pertahanan canggih, melainkan karena S3 bucket publik, security group 0.0.0.0/0, atau database tanpa enkripsi — semua diketik oleh engineer sendiri, lalu di-apply tanpa ada yang memeriksa.

Kabar baiknya: jika infrastruktur adalah kode, maka pemeriksaannya juga bisa menjadi kode — otomatis, konsisten, dan berjalan sebelum terraform apply menyentuh cloud sungguhan. Di sinilah dua tool utama episode ini masuk: scanner IaC (Trivy config / Checkov) untuk baseline, dan OPA/Rego untuk policy custom organisasi kalian.

#Mengapa Misconfig Bocor Lewat Review Manusia

Review PR memang menyaring sebagian besar kesalahan, tetapi punya tiga titik butuh sistematis:

1. Reviewer tidak hafal ratusan aturan compliance — apakah KMS rotation wajib? Apakah ALB harus drop invalid header?
2. Fatigue — diff 800 baris infrastruktur direview dalam 5 menit.
3. Konteks terputus — reviewer mungkin tidak tahu resource itu menghadap internet publik.

Otomasi menutup ketiganya: aturan didefinisikan sekali, dieksekusi setiap PR, dengan hasil deterministik.

#Layer 1: Scanner IaC

Dua opsi open source terbaik saat ini:

trivy config --severity HIGH,CRITICAL --exit-code 1 ./infra/

checkov -d ./infra/ --framework terraform --soft-fail-on MEDIUM

Contoh temuan yang akan langsung tertangkap — S3 bucket publik:

resource "aws_s3_bucket" "data" {
  bucket = "company-prod-data"
}
 
resource "aws_s3_bucket_public_access_block" "data" {
  bucket                 = aws_s3_bucket.data.id
  block_public_acls      = false
  ignore_public_acls     = false
  block_public_policy    = true
  restrict_public_buckets = true
}

Scanner membaca HCL statis (dan bahkan plan file) lalu mencocokkan dengan ratusan check bawaan — CIS AWS benchmark, PCI-DSS, hingga best practices umum. Untuk gate CI, jalankan pada plan output (terraform show -json) supaya evaluasi memakai nilai final, termasuk variabel.

#Layer 2: Policy Custom dengan OPA/Rego

Scanner bawaan menangkap kesalahan umum; organisasi kalian punya aturan sendiri: "resource production hanya boleh di region tertentu", "setiap bucket harus punya tag cost-center". Di sinilah OPA (Open Policy Agent) dengan bahasa Rego masuk — mesin evaluasi policy generik yang bekerja atas data JSON apa pun.

Policy pertama kalian — tolak S3 tanpa enkripsi:

package terraform.s3
 
deny[msg] {
  r := input.resource_changes[_]
  r.type == "aws_s3_bucket"
  not has_encryption(r)
 
  msg := sprintf(
    "%s: bucket harus punya server-side encryption",
    [r.address],
  )
}
 
has_encryption(r) {
  some c in r.configurations[_]  # placeholder struktur plan
}

Inti Rego mudah dibaca: blok deny[msg] dievaluasi untuk setiap resource; jika kondisi terpenuhi, pesan ditambahkan dan evaluasi dianggap gagal. Semakin banyak policy, semakin banyak blok deny — tidak ada logika pipeline yang berubah.

#Menjalankan Policy di CI dengan conftest

conftest adalah wrapper OPA yang nyaman untuk CI: ia membaca plan/config, menjalankan seluruh direktori policy, dan exit non-zero jika ada deny:

jobs:
  iac-security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Terraform init & plan
        run: |
          terraform init -backend=false
          terraform plan -out=tfplan.bin
          terraform show -json tfplan.bin > tfplan.json
      - name: Scanner bawaan
        run: trivy config --exit-code 1 --severity HIGH,CRITICAL .
      - name: Policy organisasi (OPA)
        run: |
          conftest test tfplan.json \
            --policy policy/ \
            --fail-on-warn

Output conftest di PR akan berbunyi seperti: FAIL - tfplan.json - aws_s3_bucket.data: bucket harus punya server-side encryption — feedback spesifik, actionable, dan konsisten untuk semua tim.

#Preventive vs Detective Guardrails

Penting memahami dua mode pengamanan:

Strategi sehat: preventive untuk aturan keras sedikit jumlahnya (public access, no encryption), detective untuk sisanya (drift, unused resources, anomali). Jangan jadikan semua hal preventive — gerbang yang menolak 40% PR akan dicari celah bypass-nya.

#Pitfall Umum

• Scan source tapi apply lewat pintu lain — console manual atau script ad-hoc melewati semua gate; kunci via IAM permission boundary.
• Policy terlalu agresif di awal — mulai mode audit (lapor saja) selama beberapa minggu, analisis volume temuan, baru aktifkan blocking.
• Ignore tanpa jejak — pengecualian harus inline berjustifikasi (# checkov:skip=CKV_AWS_18:log ke CloudFront) agar tereview.
• Lupa drift detection — infrastruktur yang diubah di luar Git diam-diam keluar dari jangkauan policy; jadwalkan terraform plan -detailed-exitcode berkala.

#Penutup

Inti yang harus dibawa pulang:

• Insiden cloud didominasi misconfigurasi yang bisa ditangkap sebelum apply.
• Dua layer: scanner bawaan (Trivy config / Checkov) untuk baseline + OPA/Rego untuk policy organisasi.
• conftest menjadikan policy sebagai gate CI yang deterministic; uji policy seperti kode.
• Preventive untuk aturan keras, detective untuk sisanya — jangan blokir segalanya.

Di episode 8 selanjutnya kita masuk ke runtime platform: Kubernetes Security — model 4C, Pod Security Admission level restricted, RBAC least privilege, NetworkPolicy default-deny, dan admission control dengan Kyverno/Gatekeeper. Cluster kind di lab kalian akhirnya dipakai serius. Sampai jumpa!