Forensik Cloud — Panduan Investigasi di AWS, GCP, dan Azure untuk Pemula

Coba lo hitung: berapa banyak infrastruktur organisasi lo yang ada di cloud? Kalau jawabannya "nggak tau persis" atau "banyak banget" — selamat datang di realita tahun 2026. Hampir semua organisasi sekarang punya setidaknya sebagian infrastruktur di cloud: website di AWS EC2, database di RDS, file di S3, email di Google Workspace, dokumen di SharePoint Online.

Tapi ada masalah besar: ketika insiden terjadi di cloud, gimana lo investigasinya? Lo nggak bisa colokin write blocker ke hard drive AWS. Lo nggak bisa imaging server GCP pakai FTK Imager. Paradigma forensik tradisional nggak berlaku di cloud.

Di artikel ini, kita bakal bahas forensik cloud dari dasar. Ini topik yang jarang dibahas dalam bahasa Indonesia — dan justru karena itulah lo harus baca.

Kenapa Forensik Cloud Berbeda?

Forensik tradisional mengasumsikan lo punya AKSES FISIK ke bukti. Lo bisa pegang hard drive-nya. Lo bisa colokin write blocker. Lo bisa imaging. Di cloud, lo nggak punya akses fisik. Lo harus bekerja dengan APA YANG DISEDIAKAN oleh provider cloud: log, snapshot, API responses.

Model Shared Responsibility: Ini konsep PALING PENTING dalam keamanan cloud. Provider dan customer berbagi tanggung jawab: Provider bertanggung jawab atas physical, infrastructure, dan hypervisor. Customer bertanggung jawab atas OS, middleware, application, dan data. Untuk forensik, ini berarti: lo hanya bisa mengakses bukti di layer yang jadi tanggung jawab lo. AWS nggak akan ngasih lo access log hypervisor-nya.

Sumber Bukti di Cloud

Meskipun lo nggak bisa imaging server cloud, lo masih punya banyak sumber bukti. 1. Cloud Audit Logs — ini sumber PALING PENTING. AWS CloudTrail merekam setiap API call: siapa login, kapan, dari IP mana, ngapain. GCP Cloud Audit Logs dan Azure Activity Log mirip. 2. VPC Flow Logs — merekam traffic jaringan di Virtual Private Cloud. Mirip NetFlow. 3. Database Logs — RDS Enhanced Monitoring, Cloud SQL query logging, Azure SQL audit log. 4. Load Balancer Logs — setiap request ke aplikasi lo. 5. Storage Access Logs — S3 Server Access Logs mencatat siapa akses bucket, file apa, kapan. 6. OS-Level Logs (kalau bisa akses VM) — /var/log/auth.log, Windows Event Log, memory dump.

Teknik Akuisisi Bukti di Cloud

Di cloud, lo nggak bisa imaging. Tapi lo bisa: EBS Snapshot (AWS) — snapshot block-level dari disk, bisa di-share ke akun forensik untuk analisis. Persistent Disk Snapshot (GCP) dan Managed Disk Snapshot (Azure) mirip. Snapshot ini bisa di-attach ke VM forensik sebagai secondary disk lalu dianalisis dengan Autopsy.

Prosedur: Stop VM terdampak (kalau memungkinkan), buat snapshot dari semua disk, JANGAN langsung analisis di environment yang sama — share ke akun forensik TERPISAH, di akun forensik buat volume dari snapshot dan attach ke VM forensik, analisis dengan tools standar.

Memory Acquisition di Cloud: Memory dump di cloud itu tricky. AWS: pakai SSM Run Command untuk menjalankan tools memory dump di VM, simpan hasil ke S3. GCP: pakai gcloud compute ssh. Azure: pakai Run Command. Peringatan: memory dump di cloud lebih terbatas karena hypervisor modern.

Log Collection: CloudTrail, VPC Flow Log, S3 Access Log — semua harus SUDAH AKTIF sebelum insiden terjadi. Kalau logging belum aktif saat insiden, lo kehilangan data itu selamanya.

Tools Forensik Cloud

Native Cloud Tools (Gratis): AWS CloudTrail + Athena — query CloudTrail logs dengan SQL. AWS GuardDuty — deteksi ancaman otomatis. GCP Security Command Center. Azure Sentinel — SIEM cloud-native.

Open Source: CloudMapper — visualisasi dan audit AWS environment. Prowler — audit keamanan AWS multi-account. ScoutSuite — audit multi-cloud (AWS, GCP, Azure). CloudForensics — toolkit forensik cloud dari Google. dfTimewolf — orchestrator forensik digital.

Tools Analisis Umum: Autopsy untuk snapshot disk, Volatility untuk memory dump, Wireshark untuk VPC Flow logs, Log2timeline/Plaso untuk timeline.

Perbedaan Forensik Antar Cloud Provider

AWS: CloudTrail adalah raja — aktifkan di SEMUA region dengan log file validation. S3 Access Logs per bucket. GuardDuty untuk deteksi. EBS Snapshot untuk akuisisi. SSM Agent untuk remote command.

GCP: Cloud Audit Logs — 3 tipe: Admin Activity (default ON), Data Access (default OFF — harus diaktifkan!), System Event. VPC Flow Logs per subnet. Persistent Disk Snapshot. OS Login untuk melacak SSH access.

Azure: Activity Log — operasi subscription-level. Azure Monitor — metrics dan diagnostics. Azure Defender — deteksi ancaman. Managed Disk Snapshot. Run Command untuk remote execution.

Cloud Forensics untuk SaaS

Untuk SaaS seperti Google Workspace, Microsoft 365, atau Salesforce: lo bahkan nggak punya akses ke OS. Semua yang lo punya adalah audit log provider. Google Workspace: Admin Console Reporting Audit Log, Google Vault untuk eDiscovery. Microsoft 365: Unified Audit Log, Microsoft Purview untuk compliance, Defender for Office 365. Kemampuan lo sangat bergantung pada tier subscription.

Studi Kasus: Investigasi Data Breach di AWS

Perusahaan e-commerce mendeteksi download massal dari S3 bucket data pelanggan. CloudTrail menunjukkan user backup_admin mengakses bucket dari IP 198.51.100.25 jam 3 pagi — mencurigakan. Investigasi lebih lanjut: CreateAccessKey dibuat 2 hari sebelumnya dari IP berbeda. S3 Access Logs menunjukkan 3 file CSV didownload dalam 1 menit. VPC Flow Logs mengkonfirmasi 2.1 GB traffic keluar ke IP attacker. Kesimpulan: kredensial bocor dan dipakai attacker. IOCs: IP 198.51.100.25, 203.0.xxx, user backup_admin, Access Key dikompromikan. Tindakan: nonaktifkan user, rotasi kredensial, notifikasi breach, perkuat IAM policy.

Checklist Keamanan Cloud untuk Investigator

Pastikan environment SIAP diinvestigasi: CloudTrail diaktifkan di SEMUA region dengan log validation, VPC Flow Logs aktif, S3 Access Logs untuk bucket sensitif, GuardDuty aktif, IAM MFA mandatory untuk semua user, semua access key lama dihapus, log disimpan ke bucket immutable, akun forensik terpisah dengan read-only access, kontak security terdaftar.

Penutup

Forensik cloud adalah skill yang semakin kritis. Organisasi yang dulu cuma punya 1-2 server di awan sekarang bisa punya ratusan VM. Ketika insiden terjadi, investigator yang paham cloud akan jauh lebih efektif. Ingat: Log adalah raja — tanpa CloudTrail yang aktif lo buta. Snapshot adalah imaging lo — share ke akun terpisah. Model shared responsibility — lo cuma bisa forensik di layer lo. Cloud forensics adalah frontier baru dalam investigasi digital. Semakin banyak organisasi pindah ke cloud, semakin besar kebutuhan akan investigator yang paham. Jadilah yang terdepan. Mulai dari sekarang, pelajari dashboard AWS CloudTrail, eksplorasi GCP Audit Logs, dan biasakan diri dengan Azure Sentinel. Ilmu ini akan sangat berharga dalam 3-5 tahun ke depan.

Studi Kasus Lengkap: Investigasi Breach AWS

Biar lo punya gambaran nyata, gue kasih skenario investigasi lengkap. Perusahaan e-commerce mendeteksi download massal dari S3 bucket customer data. Begini alur investigasi forensik cloud-nya:

Pertama, buka CloudTrail. Filter event di sekitar waktu kejadian. Dari sini lo temukan bahwa user bernama backup_admin melakukan GetObject ke bucket customer-data-prod pada jam 03:15 UTC dari IP address 198.51.100.25. Ini anomali besar — akses di tengah malam, dari IP yang tidak dikenal di infrastruktur perusahaan.

Kedua, perluas pencarian CloudTrail. Cek semua aktivitas user backup_admin dalam 30 hari terakhir. Lo temukan bahwa 2 hari sebelumnya, ada event CreateAccessKey yang dilakukan dari IP address yang berbeda (203.0.113.xxx). Ini menunjukkan bahwa kredensial user kemungkinan telah dikompromikan — attacker membuat access key baru untuk dirinya sendiri.

Ketiga, periksa S3 Server Access Logs. Dari sini lo dapat detail file apa saja yang didownload: customers_2025.csv, customers_2026.csv, dan transactions.csv — semuanya didownload dalam waktu kurang dari 1 menit. Total volume sekitar 2.1 GB.

Keempat, periksa VPC Flow Logs. Konfirmasi traffic keluar dari subnet internal ke IP 198.51.100.25 pada port 443 sebesar 2.1 GB — sesuai dengan data yang di-download dari S3.

Kesimpulan investigasi: Kredensial backup_admin dikompromikan, attacker membuat Access Key, dan menggunakannya untuk men-download data pelanggan. Total data yang bocor: ~2.1 GB file CSV berisi data pelanggan.

Tindakan yang diambil: Nonaktifkan user backup_admin dan hapus semua Access Key miliknya. Rotasi semua kredensial IAM di akun AWS. Blokir IP 198.51.100.25 dan 203.0.113.xxx di security group. Laporkan breach ke regulator sesuai UU PDP dalam 3x24 jam. Perkuat IAM policy: mandatory MFA untuk semua user, least privilege access.

Pelajaran dari kasus ini: Tanpa CloudTrail yang aktif, lo tidak akan tahu apa yang terjadi. Tanpa S3 Access Logs, lo tidak akan tahu file apa yang di-download. Logging adalah fondasi forensik cloud — dan harus diaktifkan SEBELUM insiden terjadi. Sekali insiden terjadi tanpa logging... lo buta total.

Perbandingan Forensik On-Premise vs Cloud

Biar makin jelas bedanya, gue kasih perbandingan langsung. On-premise: lo punya akses fisik ke server, bisa colokin write blocker, bisa imaging hard drive penuh dengan FTK Imager. Akses ke RAM via hardware, capture traffic via SPAN port. Cloud: lo tidak punya akses fisik sama sekali. Tidak bisa imaging — harus pakai snapshot API. Memory dump terbatas karena hypervisor. Traffic capture terbatas — harus pakai VPC Flow Logs yang tidak selengkap PCAP.

Tapi cloud punya kelebihan yang tidak dimiliki on-premise: API logging yang sangat detail (CloudTrail mencatat setiap API call), immutable storage (S3 dengan versioning dan Object Lock), dan kemampuan snapshot yang instan tanpa perlu shutdown (tergantung konfigurasi).

Keduanya punya tempat. Investigator yang baik menguasai keduanya — karena kebanyakan organisasi sekarang hybrid.

Pendekatan forensik cloud memang berbeda secara fundamental dari forensik tradisional. Di forensik tradisional, lo bisa melakukan dead acquisition — mematikan sistem, mencabut hard drive, menghubungkan ke write blocker, dan melakukan imaging bit-by-bit yang forensikally sound. Di cloud, konsep "mematikan" itu sendiri berbeda. Ketika lo "stop" sebuah EC2 instance, data di disk (EBS volume) tetap ada — lo tidak kehilangan data persistent. Tapi data di memory (RAM) langsung hilang. Ini sama seperti di on-premise, tapi dengan satu perbedaan besar: di cloud, lo tidak bisa seenaknya melakukan memory dump karena lo tidak punya akses ke hypervisor. Lo hanya bisa melakukan apa yang diizinkan oleh API cloud provider tersebut. Inilah kenapa memahami API dan layanan masing-masing cloud provider menjadi sangat krusial untuk investigator cloud.

Ambil contoh konkret: di AWS, jika lo ingin melakukan disk forensics terhadap sebuah EC2 instance yang dicurigai terinfeksi malware, langkah-langkahnya adalah: pertama, jangan langsung terminate instance tersebut. Kedua, lakukan snapshot terhadap semua EBS volume yang terpasang — ini bisa dilakukan saat instance masih berjalan (live snapshot) walaupun idealnya instance dihentikan dulu untuk meminimalkan perubahan data. Ketiga, share snapshot tersebut ke AWS account forensik yang terpisah — ini penting untuk menjaga integritas chain of custody dan mencegah kontaminasi evidence di environment produksi. Keempat, di account forensik, buat EBS volume baru dari snapshot tersebut. Kelima, attach volume itu ke EC2 instance forensik yang sudah dipersiapkan dengan tools seperti Autopsy, Sleuth Kit, dan Volatility. Keenam, lakukan analisis forensik seperti biasa — bedanya sekarang lo bekerja di cloud, tapi tools dan metodologinya sama.

Yang menarik dari pendekatan ini adalah lo bisa melakukan semua langkah di atas tanpa pernah menyentuh data center fisik, tanpa perlu datang ke lokasi, dan tanpa perlu berinteraksi dengan hardware sama sekali. Semua dilakukan via AWS Console atau CLI. Ini adalah kekuatan forensik cloud yang sesungguhnya: aksesibilitas dan kecepatan. Tapi di sisi lain, ini juga berarti bahwa investigator harus sangat berhati-hati dengan permission dan akses — jangan sampai investigator sendiri yang menjadi celah keamanan karena aksesnya terlalu luas. Log adalah segalanya di cloud forensics. Tanpa CloudTrail, tanpa VPC Flow Logs, tanpa S3 Access Logs, investigator cloud hanyalah orang buta yang mencari jarum di tumpukan jerami yang bahkan tidak bisa ia lihat. Investasikan waktu dan resource untuk memastikan logging diaktifkan di seluruh environment cloud Anda — setiap region, setiap service, setiap bucket. Karena suatu hari, ketika insiden terjadi, log-log inilah yang akan menjadi saksi bisu yang menceritakan apa yang sebenarnya terjadi. Dan dalam investigasi forensik, saksi yang bisa diandalkan adalah segalanya. Dalam perjalanan forensik cloud, lo akan menemui banyak tantangan yang tidak ada di buku teks. Setiap cloud provider punya quirks sendiri. Setiap environment punya konfigurasi unik. Setiap insiden punya karakteristik berbeda. Tidak ada playbook yang bisa mencakup semua kemungkinan. Tapi dengan fondasi yang kuat — pemahaman tentang shared responsibility model, kemampuan membaca CloudTrail/Audit Logs, dan keterampilan dalam snapshot dan log analysis — lo bisa menghadapi berbagai skenario dengan percaya diri. Cloud forensics bukan masa depan — ia adalah masa kini yang sudah berlangsung. Organisasi yang belum menyiapkan kemampuan forensik cloud-nya sedang bertaruh dengan keberuntungan. Cloud forensics adalah frontier baru dalam investigasi digital. Jadilah yang terdepan dalam mempelajari dan menguasainya. Semoga artikel ini menjadi titik awal perjalanan Anda dalam menguasai forensik cloud. Dunia menanti kontribusi Anda. Sampai jumpa di artikel ForenDigi berikutnya! Stay safe in the cloud.