Belajar Cloud Security Engineer - Cloud Security Fundamentals & Shared Responsibility

#Pendahuluan

Setelah di episode 1 kita memahami peran, karir, dan konteks pasar Cloud Security Engineer, sekarang kita bangun fondasi konseptual yang menopang seluruh series: shared responsibility model. Ini bukan slide teori yang sekadar dihafal untuk interview — ia adalah alat kerja harian yang menentukan batas antara "itu masalah provider" dan "ini pekerjaan kita".

Mengapa fondasi ini penting? Karena kesalahpahaman terhadap model ini adalah akar dari mayoritas breach cloud: tim yang menganggap provider mengamankan segalanya tidak akan mengaktifkan enkripsi, logging, maupun MFA — dan tetap merasa aman. Sebaliknya, engineer yang paham batasnya bisa menjawab auditor dan manajemen dengan presisi.

#Shared Responsibility: Konsep Inti

Prinsipnya sederhana namun implikasinya luas:

Provider bertanggung jawab atas keamanan dari cloud (security of the cloud); pelanggan bertanggung jawab atas keamanan di dalam cloud (security in the cloud).

Analogi apartemen: pemilik gedung mengamankan struktur, pintu utama, dan satpam; penyewa tetap yang mengunci pintu unitnya sendiri. Tidak ada penyewa waras yang berkata "gedung ini ada satpamnya, jadi saya tak perlu kunci pintu."

100%

Garis batas itu — compliance boundary — adalah tempat audit dimulai: provider menyediakan sertifikasi (ISO 27001, SOC reports) sampai garis itu; sisanya dibuktikan oleh kalian dengan kontrol dari episode 10 nanti.

#Spektrum Tanggung Jawab: IaaS ke SaaS

Porsi pelanggan mengecil semakin managed servicenya:

Model	Kalian Amankan	Provider Amankan	Contoh
On-premise	Semuanya	Tidak ada	Datacenter sendiri
IaaS	Data, IAM, OS, aplikasi, network config	Fisik, hardware, hypervisor	EC2, Compute Engine
PaaS	Data, IAM, konfigurasi	Plus OS & runtime	RDS, App Service
Serverless	Data, IAM, kode, konfigurasi	Plus semua infrastruktur	Lambda, Cloud Functions
SaaS	Data, identitas & akses	Hampir semuanya	Microsoft 365, Salesforce

Dua insight praktis dari tabel ini:

Pindah ke managed = turunkan beban, tapi jangan salah baca: porsi data, IAM, dan konfigurasi tetap milik kalian di semua baris. Database RDS yang di-patch provider tetap bisa bocor jika kalian matikan enkripsi dan pakai password lemah.
SaaS bukan zona aman: pada SaaS, sisa tanggung jawab kalian — identitas dan data — persis dua hal yang paling sering diserang (episode 19).

#Lapisan Keamanan di Sisi Pelanggan

Defense in depth versi cloud — lima lapisan yang menjadi kerangka series ini:

100%

Setiap lapisan punya satu episode (atau lebih) khusus: identity → ep 3/19, network → ep 4/16, workload → ep 5/12/13, data → ep 6/14/20, detection → ep 8/9/24. Ketika kalian merancang atau me-review sistem, jalankan checklist kelapisan ini secara berurutan — gap apa pun akan tertangkap.

#Praktik: Memetakan Tanggung Jawab per Service

Kemampuan inti yang harus terbentuk hari ini: melihat nama service dan langsung tahu pembagian tanggung jawabnya. Latihan dengan tabel nyata:

Service	Milik Provider	Milik Kalian (Wajib Dikerjakan)
EC2	Hardware, hypervisor, isolasi	AMI hardening, patch OS, SG, IMDSv2
S3	Durabilitas, infrastruktur	Bucket policy, block public access, enkripsi key, logging
RDS	Patch engine, failover	Enkripsi at rest, parameter group, network, user DB
Lambda	Runtime, scaling, isolation	Execution role, input validation, secret handling
EKS	Control plane	Node group hardening, RBAC, pod security, network policy

Perhatikan kolom kanan — panjangnya konsisten di semua baris. Itulah wilayah kerja Cloud Security Engineer: tidak pernah nol, di service mana pun.

Latihan mandiri: ambil satu layanan yang dipakai organisasi kalian (atau sandbox), tulis tabel serupa, lalu cek konfigurasi aktualnya lewat CLI:

Verifikasi cepat sisi pelanggan di sandbox

aws ec2 describe-instances \
  --query 'Reservations[].Instances[].{id:InstanceId,pub:PublicIpAddress,imds:MetadataOptions.HttpTokens}' \
  --output table
aws s3api list-buckets --query 'Buckets[].Name' --output text | tr '\t' '\n' | while read b; do
  echo "== $b"; aws s3api get-bucket-encryption --bucket "$b" >/dev/null 2>&1 || echo "   BELUM TERENKRIPSI eksplisit"
done

Output inilah "peta tanggung jawab" versi faktual: instance tanpa required pada IMDS dan bucket tanpa enkripsi eksplisit adalah pekerjaan rumah kalian — bukan milik provider.

#Common Pitfalls

"Cloud-nya AWS, pasti aman" — sertifikasi provider mencakup infrastruktur mereka; konfigurasi kalian tidak termasuk.
Menganggap default = aman — banyak default dirancang untuk kemudahan migrasi, bukan security (public IP otomatis, log nonaktif).
Compliance boundary dipakai sebagai alasan — "provider sudah ISO" tidak menjawab pertanyaan auditor tentang kontrol kalian.
Lupa sisa tanggung jawab SaaS — MFA dan review akses Microsoft 365/Salesforce adalah pekerjaan kalian juga.

Important

Uji pemahaman kalian dengan satu kalimat: "Jika terjadi breach, bagian mana yang dituntut provider dan bagian mana yang jatuh ke tim kita?" Jika jawaban itu belum tajam, baca ulang spektrum IaaS-SaaS di atas — ia akan muncul lagi di setiap interview.

#Penutup

Inti yang harus dibawa pulang:

Shared responsibility: provider mengamankan cloud-nya, kalian mengamankan apa yang ada di dalamnya — dengan compliance boundary sebagai garis audit.
Spektrum IaaS→SaaS mengubah ukuran porsi, tapi data + IAM + konfigurasi selalu milik kalian.
Lima lapisan pertahanan (identity, network, workload, data, detection) adalah kerangka series dan kerangka review.
Peta tanggung jawab per-service adalah skill praktis — verifikasi dengan CLI, bukan asumsi.

Di episode 3 selanjutnya kita turun ke lapisan pertama sekaligus paling menentukan: cloud IAM & identity — users, roles, policies, least privilege, service accounts, dan praktik setup IAM yang benar. Sampai jumpa!