Belajar Cloud Engineer - Cloud Security & Compliance

#Pendahuluan

Di episode 14 kita memasang pipeline CI/CD yang men-deploy aplikasi otomatis. Tapi ada satu hal yang saya singgung sebagai kesalahan umum: "credential di YAML". Kenapa itu dilarang? Karena satu file pipeline yang bocor bisa membuka seluruh akun cloud kalian. Di episode inilah celah itu ditutup.

Episode 15 membahas cloud security & compliance: shared responsibility model, encryption (data at rest dan in transit), secrets management (KMS dan Secret Manager), hingga compliance (SOC2, GDPR). Kalian juga akan melakukan security audit untuk infrastruktur yang telah dibangun sejak episode 3 — dan kalian akan terkejut berapa banyak lubang yang selama ini terbuka.

#Shared Responsibility Model

Aturan pertama keamanan cloud adalah memahami siapa bertanggung jawab atas apa. Jawabannya dibagi antara provider dan kalian:

Kalimat yang wajib diingat: provider menjaga keamanan cloud, kalian menjaga keamanan di dalam cloud. VM yang kalian buat di episode 3 dengan default security group "buka semua port" adalah tanggung jawab kalian — bukan provider. Kesalahan memahami model ini adalah akar dari hampir semua insiden kebocoran data.

#Praktik Keamanan Dasar (Security Best Practices)

Sebagian besar praktik baik sudah kalian sentuh di episode-episode sebelumnya. Sekarang kita rangkai menjadi satu pola:

1. Least privilege (episode 6) — setiap user, role, dan service hanya punya akses minimum. Tidak ada yang "punya semua permission".
2. Jaringan terkunci (episode 5) — security group hanya membuka port yang dibutuhkan; database tidak pernah terbuka ke internet.
3. MFA untuk semua user — password saja tidak cukup; kombinasi password + kode dari perangkat.
4. Secrets di store, bukan di kode — bahan utama episode ini.
5. Enkripsi di mana pun data berada — dibahas berikutnya.
6. Audit log aktif (episode 9) — semua aktivitas tercatat; tidak bisa diklaim "tidak tahu" jika tidak ada log.

#Encryption: Data At Rest dan In Transit

Enkripsi bekerja di dua sisi: at rest (data tersimpan di disk/object storage/database) dan in transit (data bergerak antar-komponen).

#Data At Rest

Provider mengenkripsi storage secara default — S3, EBS, Cloud Storage, semuanya. Yang penting dipahami adalah kunci enkripsi dan siapa yang memegangnya:

• AWS KMS — membuat dan mengelola customer managed keys; setiap key punya kunci turunan untuk tiap data.
• GCP Cloud KMS dan Azure Key Vault — padanan yang sama: satu tempat untuk membuat, memutar, dan mencabut kunci.

Prinsip penting: enkripsi default itu gratis dan otomatis — jangan pernah mematikannya. Keahlian kalian bukan di "menyalakan enkripsi", melainkan di mengelola kunci dan memutar (rotate) kunci secara berkala.

#Data In Transit

Semua lalu lintas web harus memakai TLS (HTTPS). Hal yang sering terlewat: koneksi internal antara aplikasi dan database juga harus dienkripsi. Banyak arsitektur aman di luar tapi terbuka lebar di dalam.

aws s3api get-bucket-encryption \
  --bucket lab-static-assets \
  --query ServerSideEncryptionConfiguration

Jika perintah di atas mengembalikan error, bucket tidak terenkripsi — langsung perbaiki. Untuk HTTPS, pastikan load balancer kalian (episode 5) menerima koneksi HTTP saja di port 443, dan redirect port 80.

#Secrets Management: KMS, Secret Manager, Key Vault

Secrets adalah password, access key, token API, dan kredensial database. Aturannya satu: tidak pernah di kode, di config, atau di repository. Ketiga provider punya layanan khusus:

Pola pemakaiannya sama di semua provider: tulis secret sekali, aplikasi membaca saat runtime — bukan saat build. Contoh di AWS:

aws secretsmanager create-secret \
  --name lab-db-credentials \
  --secret-string '{"username":"app","password":"P@ssw0rd_Lab!"}'
 
aws secretsmanager get-secret-value \
  --secret-id lab-db-credentials \
  --query SecretString

Penting: --secret-string di atas hanya untuk latihan. Di produksi, nilai secret masuk lewat console atau Terraform dengan referensi yang terenkripsi, tidak pernah terlihat di terminal.

Kembali ke episode 14: pipeline yang tadi menaruh credential di YAML harus diubah memakai referensi secret. Ini contoh mengubah environment variable di container memakai nilai dari Secrets Manager:

# Sebelum (SALAH) - credential tertulis di YAML
# env:
#   DB_PASSWORD: "P@ssw0rd_Lab!"
 
# Sesudah (BENAR) - ambil dari secret store saat runtime
env:
  DB_PASSWORD: '{{resolve:secretsmanager:lab-db-credentials:SecretString:password}}'

#Compliance: SOC2, GDPR, dan Lainnya

Compliance adalah bukti bahwa sistem kalian memenuhi standar keamanan tertentu. Tiga yang paling sering ditemui di industri:

• SOC 2 — standar keamanan untuk perusahaan SaaS; klien enterprise memintanya sebelum mengandalkan layanan kalian.
• GDPR — aturan perlindungan data pribadi warga Uni Eropa; berlaku untuk siapa pun yang memproses data mereka, di mana pun server berada.
• ISO 27001 — standar internasional manajemen keamanan informasi.

Yang wajib dipahami: compliance adalah proses dan bukti, bukan sekadar menyalakan fitur. Buktinya berasal dari:

1. Audit log — CloudTrail (AWS), Cloud Audit Logs (GCP), Azure Activity Log — mencatat siapa melakukan apa di akun kalian.
2. Kebijakan — dokumen yang menyatakan bagaimana data diperlakukan (retensi, akses, enkripsi).
3. Kontrol teknis — yang sudah kita bangun: IAM, enkripsi, logging.

GDPR menekankan pada hak untuk dihapus — sistem harus bisa menghapus data user secara tuntas. Ini berdampak langsung ke desain storage: jangan menyebarkan data user di 10 tempat tanpa peta. Data inventory adalah syarat compliance.

#Praktik: Security Audit Cloud

Mari audit infrastruktur yang sudah kalian bangun sejak episode 3. Checklist audit:

1. Inventarisasi — daftarkan semua resource: VM, bucket, database, function. Tidak ada yang "terlupakan".
2. Cek akses publik — mana yang terbuka ke internet? Security group VM, bucket policy, database. Publik = harus dibenarkan secara tegas.
3. Audit IAM — siapa punya akses apa? Hapus user tanpa MFA dan kunci yang tidak dipakai.
4. Cek secrets — git grep -i "password\|access_key" di repository; hapus yang bocor dan rotasi.
5. Verifikasi enkripsi — semua storage dan database terenkripsi (cek dengan perintah KMS di atas).
6. Periksa audit log aktif — CloudTrail/Cloud Logging/Activity Log menyala dan log tidak dihancurkan dalam 30 hari.
7. Uji restore backup — keamanan tanpa backup yang bisa dipulihkan adalah ilusi (episode 20).

git grep -n -i -E "password|secret|access_key|BEGIN (RSA|OPENSSH) PRIVATE KEY"

Semua temuan audit dicatat, diprioritaskan (kritis/lagi/sedang), dan diperbaiki bertahap. Pola "temukan → catat → perbaiki → verifikasi" ini akan kalian pakai terus di dunia kerja nyata.

#Kesalahan Umum (Common Pitfalls)

1. Menyimpan secret di kode/repo — pelanggaran paling umum dan paling mahal; selalu pakai Secret Manager.
2. Mematikan enkripsi "biar cepat" — biaya performa sangat kecil, risiko bocor sangat besar.
3. Credential root dipakai untuk operasi harian — gunakan IAM user/role dengan scope terbatas (episode 6).
4. Log audit nonaktif — tanpa jejak, audit compliance mustahil dan investigasi insiden buntu.
5. Security group "terbuka semua" — default 0.0.0.0/0 di semua port; tutup port yang tidak dipakai (episode 5).
6. Mengabaikan rotasi kunci — kunci lama yang bocor tetap berlaku; rotasi otomatis wajib untuk secret penting.

#Penutup

Inti yang harus dibawa pulang:

• Shared responsibility: provider amankan cloud, kalian amankan yang ada di dalam cloud.
• Enkripsi at rest dan in transit adalah default — kelola kuncinya, jangan pernah matikan.
• Secrets hidup di Secret Manager/KMS/Key Vault, tidak pernah di kode atau YAML pipeline.
• Compliance (SOC2/GDPR) = proses + bukti: kebijakan, kontrol teknis, dan audit log.
• Security audit adalah kebiasaan rutin, bukan acara sekali jalan.

Di episode 16 selanjutnya kita akan membahas topik yang tak kalah penting untuk kelangsungan hidup cloud kalian: cost optimization & FinOps — right-sizing, reserved/savings plans, tagging, dan cost monitoring, lalu mengaudit serta memangkas tagihan infrastruktur kalian. Sampai jumpa di episode 16!