Belajar Cloud Security Engineer - Multi-Cloud Security

#Pendahuluan

Sebelas episode kita hidup nyaman di AWS — dengan singgahan kecil ke GCP dan Azure. Realita enterprise 2026: organisasi besar jarang satu cloud. Akuisisi, regulasi data, negosiasi harga vendor, dan ketahanan layanan mendorong multi-cloud — dan bersama itu, tantangan baru: tiga model identitas berbeda, tiga sistem log, tiga tempat salah konfigurasi.

Mengapa episode ini penting? Karena multi-cloud yang buruk bukan dua kali pekerjaan — ia bisa jadi lima kali pekerjaan dengan setengah kualitas. Engineer yang paham apa yang harus disamakan (kontrol) dan apa yang harus dibiarkan beda (implementasi) menjaga kompleksitas tetap terkendali.

#Tiga Model Identitas yang Harus Kalian Kuasai

Perbedaan filosofi IAM antar-provider adalah sumber kebingungan nomor satu:

Aspek	AWS IAM	GCP IAM	Microsoft Entra ID
Unit utama	Account	Project	Tenant + Subscription
Struktur	Flat + Organizations/OU	Folder hierarchy (mirip resource tree)	Management group hierarchy
Policy	Dokumen JSON eksplisit (allow/deny)	Binding role ke member pada resource	RBAC roles + Entra ID conditions
Identitas workload	Role + STS	Service account + Workload Identity	Managed identity
Guardrail	SCP	Organization policy	Azure Policy

Tiga insight praktis:

GCP mewarisi turun — binding di folder berlaku ke semua project di bawahnya; mudah, tapi satu kesalahan menyebar luas.
AWS policy eksplisit tapi verbose — default deny semua; policy harus menyebut segalanya.
Entra adalah identity provider penuh — bukan hanya IAM infrastruktur; user, aplikasi SaaS, dan kondisi akses (device compliance, lokasi) tinggal satu atap. Inilah kenapa episode 19 khusus membahas ancamannya.

#Federation: Satu Identitas, Banyak Cloud

Prinsip anti-kelelahan: jangan bikin user terpisah per-cloud. Federasikan dari satu sumber kebenaran:

100%

Manfaat konkret federation:

Joiner/mover/leaver otomatis: karyawan keluar → satu disable di IdP mematikan akses ke semua cloud.
MFA & conditional access konsisten — kebijakan dari episode 19 berlaku ke semua platform.
Audit tunggal — jejak siapa login ke apa ada di satu tempat.

Untuk identitas workload antar-cloud, pola sama dengan episode 14: token ephemeral via OIDC/SAML exchange, nol secret statis lintas-platform.

#Sentralisasi Logging dan Deteksi

Deteksi multi-cloud gagal jika evidence tersebar di tiga silo. Dua strategi yang umum dipakai:

Strategi A - agregasi ke satu lakehouse: semua cloud mengalirkan log ke satu penyimpanan (misal S3 sebagai tujuan akhir, atau Amazon Security Lake dengan format OCSF) — Athena/SIEM kueri lintas-cloud dengan schema sama.

Strategi B - SIEM eksternal sebagai titik temu: Splunk/Elastic/Sentinel menerima semuanya; parsing per-sumber di pipeline ingest.

Kriteria pemilihan sederhana: kalau tim kalian kuat engineering dan volume log besar, Strategi A murah dan fleksibel. Kalau tim SOC sudah matang di sebuah SIEM, Strategi B lebih cepat bernilai.

Di sisi deteksi, aktifkan managed detection di tiap provider (GuardDuty, SCC Event Threat Detection, Defender plans) — lalu samakan penanganan temuan: semua finding dikirim ke tiket yang sama dengan format OCSF bila memungkinkan.

#Baseline Per-Cloud: Normalisasi, Bukan Seragam Paksa

CIS punya benchmark spesifik per provider — struktur kontrolnya mirip, implementasinya wajib beda. Cara menjaga sanity:

Definisikan baseline kontrol abstrak milik organisasi ("semua disk terenkripsi", "log tersentral & immutable", "tanpa akses publik default").
Petakan ke mekanisme native masing-masing: encryption by default EBS ↔ disk default CMEK GCP ↔ Microsoft.Compute policy encrypt-at-host Azure.
Jalankan scanner yang bicara bahasa organisasi: Prowler mendukung AWS/GCP/Azure dalam satu CLI.

Audit multi-cloud dengan Prowler

prowler aws --compliance cis_2.0_aws -M csv -o out/aws
prowler gcp --compliance cis_2.0 -M csv -o out/gcp
prowler azure --compliance cis_2.0_azure -M csv -o out/azure

Laporan CSV ini masuk pipeline compliance dari episode 10 — framework mapping organisasi tetap satu, meski implementasi bertiga.

#Tool Abstraksi Multi-Cloud: Kapan Layak

Pasar menawarkan lapisan abstraksi: Terraform untuk provisioning, CSPM/CNAPP untuk posture (episode 21), Steampipe untuk query inventory. Aturan keputusannya:

Provisioning (Terraform): hampir selalu layak — satu workflow PR seperti episode 11 untuk semua cloud.
Posture monitoring (CSPM): layak begitu jumlah akun/project/subscription melewati belasan; manual triage tak sanggup lagi.
Abstraksi IAM/network penuh (tool yang "menyamakan" policy): sering jadi utang — leaky abstraction yang membuat tim tidak paham native behavior saat insiden. Gunakan hemat.

Important

Jangan multi-cloud demi fashion: setiap cloud tambahan = permukaan serangan, biaya konteks-switch, dan beban audit baru. Multi-cloud dibenarkan oleh kebutuhan nyata (regulasi, resilience, akuisisi) — bukan slide marketing.

#Baseline Minimum Multi-Cloud

Checklist yang bisa langsung kalian pakai:

Satu IdP untuk semua human access; SCIM on; MFA/conditional access konsisten.
Nol long-lived credential lintas cloud — semua workload pakai federation.
Log audit semua cloud mengalir ke satu penyimpanan immutable.
Baseline kontrol organisasi terdokumentasi abstrak + petakan native per-cloud.
Scanner multi-cloud terjadwal; output masuk satu pipeline triage.
Tagging konsisten (env, owner, data-class) agar CSPM bisa menegakkan sesuai klasifikasi.

#Penutup

Inti yang harus dibawa pulang:

Kuasai tiga model identitas: AWS explicit-deny JSON, GCP inheritance tree, Entra conditional access.
Federation dari satu IdP membuat joiner/mover/leaver aman otomatis lintas-cloud.
Sentralisasi log (lakehouse OCSF atau SIEM) adalah prasyarat deteksi multi-cloud.
Baseline kontrol didefinisikan abstrak, diimplementasi native — dinormalisasi lewat scanner, bukan diseragamkan paksa.
Terraform dan CSPM layak; abstraksi IAM penuh biasanya jadi utang.

Di episode 16 selanjutnya kita kembali ke network dengan lensa modern: zero trust — ZTNA vs VPN, microsegmentasi, SSE/SASE, dan desain akses internal yang tidak percaya lokasi jaringan. Sampai jumpa!