Belajar Cloud Security Engineer - Cloud Compliance & Frameworks

#Pendahuluan

Sepuluh episode kita membangun kontrol teknis: IAM, network, workload, data, CSPM, deteksi, IR. Episode ini menjawab pertanyaan yang pasti muncul di dunia kerja: bagaimana membuktikan semua itu kepada auditor? Compliance sering dianggap beban administratif — padahal dikerjakan dengan benar, ia adalah cara kerja engineering yang terdokumentasi rapi.

Mengapa Cloud Security Engineer wajib paham framework? Karena kalian adalah orang yang menerjemahkan requirement ("akses harus direview berkala") menjadi kontrol teknis yang bisa dievaluasi mesin (IAM Access Analyzer findings = nol). Engineer yang bisa bicara dua bahasa — kontrol dan framework — menjadi jembatan paling bernilai antara tim teknis dan auditor/regulator.

#Peta Framework Utama

Empat framework yang paling sering kalian temui:

Catatan penting: tidak ada satu pun framework ini yang mensertifikasi "AWS itu aman" — sertifikasi selalu tentang sistem organisasi yang berjalan di atas cloud. AWS/GCP/Azure punya sertifikasi infrastruktur mereka (ISO 27001, SOC reports tersedia publik), dan itulah bahan berikutnya.

#Shared Responsibility Bertemu Audit

Shared responsibility dari episode 2 kini berdampak langsung ke audit melalui konsep inheritance of controls: banyak kontrol yang tidak perlu kalian buktikan sendiri karena sudah dicover provider.

Contoh konkret di audit ISO 27001/SOC 2:

• Kontrol fisik datacenter (pintu, CCTV, pendingin) → inherited dari provider; buktinya SOC 2 report AWS yang kalian lampirkan sebagai complementary control.
• Patch hypervisor, keamanan hardware → inherited.
• Konfigurasi IAM, enkripsi data, logging → milik kalian; auditor akan menanyakan bukti operasional, bukan niat baik.

Kesalahan klasik organisasi: membeli tool compliance, lalu mengisi checklist tanpa kontrol nyata. Auditor modern (dan regulator) makin pintu menembus gap antara dokumen dan realita teknis — dan justru di sanalah kalian sebagai engineer memberi nilai.

#Pemetaan Kontrol Teknis ke Requirement

Inti pekerjaan: satu kontrol teknis biasanya memenuhi banyak requirement sekaligus. Contoh pemetaan nyata dari series kita:

Perhatikan pola efisiensinya: sepuluh kontrol solid menutup puluhan requirement. Itulah alasan engineer yang merancang kontrol dengan mapping di kepala membuat audit murah — dan engineer yang tidak, membuat organisasi mengumpulkan screenshot tiap tahun.

Simpan pemetaan ini sebagai data, bukan spreadsheet mati — misal YAML di repo:

control_id: CT-001
name: MFA enforcement untuk akses sensitif
implementation: SCP deny tanpa aws:MultiFactorAuthPresent
owner: platform-security
evidence:
  automated: prowler check iam_mfa_console_access
  frequency: weekly
frameworks:
  nist_csf: [PR.AA-03]
  iso27001_2022: [A.5.17, A.8.5]
  soc2: [CC6.1]
  pci_dss: [8.4]

File semacam ini bisa digenerate menjadi laporan audit otomatis — fondasi compliance-as-code.

#Otomatisasi Audit Evidence

Evidence manual (screenshot konsol, export CSV sekali-setahun) punya dua cacat fatal: basi saat dipakai dan mahal untuk dikumpulkan. Pola modern: continuous compliance — evidence dikumpulkan otomatis, kontinu.

Opsi tooling:

• Native: AWS Audit Manager (generate assessment otomatis dari resource config), Azure Purview/Policy compliance dashboard, GCP Assured Workloads + SCC.
• Open source: Prowler dengan output compliance frameworks (--compliance cis_2.0_aws), OpenControl/Compliance Masonry untuk dokumentasi.
• Vendor: Vanta/Drata/Secureframe untuk SOC 2 startup-grade.

prowler aws --compliance cis_2.0_aws pci_dss --output-mode csv -o evidence/

Satu command menghasilkan CSV berisi status tiap kontrol benchmark — file itu adalah evidence yang bisa langsung dilampirkan auditor. Jadwalkan mingguan lewat CI, simpan output ke bucket dengan retensi panjang, dan audit tahunan berubah dari sprint menyiksa menjadi review rutin.

#Scope Reduction: Strategi Terpenting

Strategi compliance yang jarang diajarkan: perkecil scope audit. Semakin sedikit sistem yang menyentuh data regulated, semakin murah auditnya.

• Pisahkan workload PCI ke akun/VPC khusus (cardholder data environment terisolasi) — sisanya keluar dari scope PCI.
• Gunakan tokenisasi/provider payment (Stripe dsb.) agar nomor kartu tak pernah masuk sistem kalian.
• Data minimization: data yang tidak disimpan tidak bisa bocor dan tidak masuk scope GDPR/PCI.

Ini keputusan arsitektur yang dibuat oleh... Cloud Security Engineer. Episode 20 akan memperdalam sisi regulasi (GDPR/HIPAA/data residency) secara khusus.

#Common Pitfalls

• Mengobati framework sebagai proyek, bukan program — audit lulus, kontrol melapuk enam bulan kemudian.
• Salah pilih framework — SOC 2 untuk enterprise US, ISO 27001 untuk global/Eropa; jangan keduanya sebelum benar-benar dibutuhkan pasar.
• Evidence tanpa konteks waktu — auditor minta "bagaimana status 1 Juni?", screenshot bulan November tidak sah.
• Inheritance diabaikan — menghabiskan effort membuktikan kontrol fisik provider yang sudah tercover SOC 2 report mereka.

#Penutup

Inti yang harus dibawa pulang:

• Framework (NIST CSF, ISO 27001, SOC 2, PCI DSS) adalah bahasa untuk membuktikan kontrol; shared responsibility membuat sebagian besar kontrol fisik inherited.
• Satu kontrol teknis yang dirancang baik menutup puluhan requirement — petakan sebagai data, bukan spreadsheet.
• Continuous compliance mengubah evidence dari screenshot basi menjadi output otomatis mingguan.
• Scope reduction adalah strategi termurah untuk lolos audit.

Di episode 11 selanjutnya kita kembali ke kode: IaC security — scanning Terraform, policy-as-code dengan OPA, drift detection, dan membangun pipeline yang mencegah misconfigurasi lahir sejak pull request. Sampai jumpa!