Belajar Cloud Security Engineer - CSPM & Misconfiguration

#Pendahuluan

Setelah di episode 6 kita mengunci data dengan KMS dan klasifikasi, ada pertanyaan jujur yang harus dijawab: bagaimana memastikan ribuan resource lain di organisasi juga mengikuti standar yang sama? Jawaban manusia — audit manual berkala — kalah cepat dari laju provisioning. Di sinilah CSPM (Cloud Security Posture Management) bekerja.

Mengapa topik ini penting? Karena mayoritas breach cloud modern bukan hasil eksploitasi zero-day, melainkan misconfigurasi sederhana: bucket publik, database tanpa enkripsi, SG terbuka ke dunia, log dimatikan. CSPM menemukan semuanya secara kontinu — pekerjaan kalian bergeser dari mencari masalah ke memutuskan prioritas dan memperbaiki.

#Mengapa Misconfiguration Mendominasi

Tiga alasan struktural kenapa misconfigurasi tak terhindarkan tanpa otomasi:

1. Kecepatan provisioning — ribuan resource lahir per minggu lewat IaC dan konsol; tidak ada reviewer yang sanggup membaca semuanya.
2. Default yang tidak aman — banyak layanan mudah dipakai dengan konfigurasi longgar (misal public IP otomatis).
3. Drift — konfigurasi berubah diam-diam lewat klik manual darurat saat insiden, lalu dilupakan.

Konsekuensinya: postur keamanan adalah keadaan yang membusuk, bukan status yang sekali diraih. CSPM adalah instrumen pengukur kontinunya.

#Tools CSPM Utama

Setiap provider punya layanan native; vendor pihak ketiga menyatukan lintas-cloud:

Untuk series ini kita pakai kombinasi Security Hub + Prowler: yang satu native production-grade, satunya open source yang bisa kalian jalankan gratis di lab.

#Benchmark CIS sebagai Baseline

CIS Benchmarks adalah checklist hardening yang diadopsi hampir semua tool CSPM sebagai standard bawaan. Struktur logisnya: setiap kontrol punya ID, deskripsi, remediation command, dan level (1 = dasar non-intrusif, 2 = lebih ketat berdampak fungsi).

Contoh beberapa kontrol CIS AWS yang paling sering gagal:

Nilai strategis CIS: kalian tidak perlu berdebat "apa yang aman" — benchmark sudah jadi bahasa bersama antara engineer, auditor, dan manajemen.

#Praktik: CSPM Scan Pertama

Jalankan Prowler di akun sandbox kalian:

prowler aws --region ap-southeast-1 --severity critical high

Output ringkasnya menampilkan check yang lolos dan gagal beserta severity. Lalu aktifkan Security Hub agar monitoring kontinu:

aws securityhub enable-security-hub \
  --enable-default-standards \
  --region ap-southeast-1
aws securityhub get-findings \
  --filters '{"SeverityLabel":[{"Comparison":"EQUALS","Value":"CRITICAL"}],"RecordState":[{"Comparison":"EQUALS","Value":"ACTIVE"}]}' \
  --max-items 20

Fokuskan energi pada finding ACTIVE + CRITICAL/HIGH — sisanya jangan biarkan menumpuk menjadi kebisingan yang membuat kalian kebal terhadap alert sungguhan.

#Triage Berbasis Eksposur, Bukan Severity Mentah

Severity tool tidak tahu konteks bisnis kalian. Framework triase yang pragmatis — urutan pertanyaannya penting:

1. Ter-eksposur internet? Resource publik = prioritas atas.
2. Berapa blast radius? Satu instance vs seluruh akun (misal SCP lemah).
3. Ada jalur menuju data terklasifikasi tinggi? Silangkan dengan tag klasifikasi dari episode 6.
4. Mudah dieksploitasi? Kredensial bocor > teori kerentanan rumit.

Hasil triage jatuh ke salah satu dari empat tindakan: fix sekarang, jadwalkan, terima risiko dengan dokumentasi, atau ubah arsitektur. Yang tidak boleh: menonaktifkan kontrol CSPM hanya agar angka jadi hijau.

#Remediation Otomatis

Untuk kelas temuan yang deterministik, remediation manual adalah pemborosan. Pola standar: EventBridge menangkap event → Lambda memperbaiki → notifikasi ke Slack/tiket.

Contoh auto-remediate bucket yang tiba-tiba jadi publik:

lambda_remediate_public_bucket.py

import boto3, os
 
def handler(event, context):
    detail = event["detail"]
    if detail.get("eventName") != "PutBucketPolicy":
        return
    bucket = detail["requestParameters"]["bucketName"]
    s3 = boto3.client("s3")
 
    # kunci kembali: cabut semua konfigurasi publik
    s3.put_public_access_block(
        Bucket=bucket,
        PublicAccessBlockConfiguration={
            "BlockPublicAcls": True, "IgnorePublicAcls": True,
            "BlockPublicPolicy": True, "RestrictPublicBuckets": True,
        },
    )
    sns = boto3.client("sns")
    sns.publish(
        TopicArn=os.environ["ALERT_TOPIC"],
        Message=f"[AUTO-REMEDIATED] {bucket} dikembalikan ke private",
        Subject="CSPM auto-fix: public bucket blocked",
    )

Event rule-nya difilter ke API call PutBucketPolicy/PutBucketAcl sehingga Lambda hanya bangun saat percobaan pembukaan publik terjadi. Pola lengkapnya (termasuk guardrail anti-loop) kita perdalam di episode 22 tentang AI-assisted remediation.

#Common Pitfalls

• Mematikan standard/check yang berisik alih-alih memperbaiki root cause — posture tampak hijau, risiko tetap.
• Menilai CSPM sekali lalu melupakan — nilai postur membusuk; pasang tren mingguan.
• Multi-akun dilupakan — pastikan CSPM agregat dari seluruh organization, bukan satu akun management saja.
• Finding tanpa owner — temuan yang tidak punya pemilik dan SLA akan menumpuk selamanya.

#Penutup

Inti yang harus dibawa pulang:

• Postur keamanan membusuk secara alami; CSPM mengukurnya kontinu — Security Hub, Defender, SCC, atau Prowler.
• CIS benchmark adalah bahasa bersama baseline hardening; fokuskan pada ACTIVE critical/high.
• Triase berdasar eksposur dan blast radius, bukan severity mentah.
• Otomatisasi remediation untuk temuan deterministik; jaga guardrail agar tidak jadi sumber insiden baru.

Di episode 8 selanjutnya kita beralih dari postur ke perilaku: cloud threat detection & monitoring — CloudTrail, GuardDuty, VPC Flow Logs, integrasi SIEM, dan detection rules pertama kalian. Sampai jumpa!