Semua artikel
// Artikel

Baseline Audit Logging Cloud: Cakupan, Perlindungan, Integritas

Dipublikasikan 18 Juli 2026

Audit logging adalah sistem bukti, bukan sekadar pengaturan console. Saat insiden, tim perlu menjawab siapa melakukan apa, perubahan apa terjadi, di mana, kapan, dan apakah catatan tetap terlindungi. Rancang cakupan, pengiriman, akses, retensi, integritas, dan pengambilan bukti sebagai kontrol terpisah.

Tentukan cakupan sebelum mengumpulkan volume

Cakup perubahan identitas, autentikasi dan federation, penggunaan role istimewa, perubahan control plane, network security, key management, storage policy, serta data-plane access yang dipilih. AWS CloudTrail management events mencakup operasi manajemen. Data events seperti operasi objek S3 tidak dicatat secara default dan dapat bervolume tinggi. Gunakan selector terfokus untuk bucket, prefix, atau operasi sensitif; dokumentasikan owner biaya.

Google Cloud Audit Logs membedakan Admin Activity, Data Access, System Event, dan Policy Denied. Admin Activity serta System Event selalu ditulis. Data Access, selain perilaku BigQuery yang dijelaskan Google, umumnya nonaktif secara default dan perlu konfigurasi eksplisit. Azure Activity Log mencakup operasi management/control plane secara default; resource logs mencakup data plane dan perlu diagnostic setting. Maka “Activity Log aktif” belum membuktikan akses data sensitif terlihat.

SumberSet event wajibBukti cakupanOwnerHasil
AWS CloudTrailmanajemen organisasi/account dan data events terpilihexport trail/selector; sample querykeamanan cloudpass/fail
Google CloudAdmin, System, Policy Denied; Data Access terpilihaudit config dan uji sinkowner platformpass/fail
AzureActivity Log dan resource diagnostic settingsdiagnostic setting dan event resourceowner subscriptionpass/fail
identity providersign-in, admin, MFA, federationtimestamp ekspor dan uji korelasiowner identitaspass/fail

Lindungi sink dari operator rutin

Kirim log ke account, project, subscription, atau workspace keamanan terpisah bila memungkinkan. Pisahkan kewenangan tulis, baca, retensi, dan hapus. Administrator workload rutin tidak boleh dapat menonaktifkan koleksi, mengubah tujuan, memperpendek retensi, atau menghapus catatan tanpa jalur privileged yang dipantau. Batasi policy sink untuk layanan logging dan responder tertentu; buat alert untuk perubahan trail, sink, diagnostic setting, bucket policy, atau retensi.

Enkripsi dan access control penting, tetapi storage terenkripsi tidak otomatis immutable. Integritas memerlukan mekanisme eksplisit: validasi provider bila tersedia, retensi append-only atau write-once, penghapusan dibatasi, arsip independen, dan verifikasi berkala. Google menyatakan entri Cloud Audit Log immutable, tetapi desain akses serta retensi tetap menentukan apakah responder dapat mengambilnya. Azure Activity Log disimpan 90 hari secara default; diagnostic setting dapat mengekspor untuk retensi lebih lama. Tetapkan retensi berdasarkan risiko, kebutuhan hukum, dan biaya.

Jalankan uji pengambilan dan perusakan

Untuk setiap event penting, buat uji terkendali: lakukan perubahan policy yang disetujui, akses objek atau secret terlindungi saat data-plane logging memang dituju, lalu ambil record berkorelasi dari tujuan utama dan tujuan terlindungi. Catat waktu kejadian, waktu penerimaan, pelaku atau principal, ID permintaan, ID sumber daya, operasi, hasil, sumber log, URI tujuan, kueri, dan pemeriksa. Pastikan waktu identity provider, cloud, aplikasi, serta SIEM tersinkronisasi.

Uji juga kondisi gagal: principal tanpa akses sink tidak dapat menghapus log; admin workload tidak dapat menonaktifkan delivery; alert muncul saat konfigurasi berubah; responder dapat membuka catatan historis melalui prosedur darurat; retensi mencegah penghapusan terlalu dini. Jangan memasukkan secret, presigned URL, token, atau payload pelanggan mentah ke application log demi investigasi.

Artefak selesai, pengecualian, perbaikan

KontrolElemen buktiPenanggung jawabStatus lulusPengecualianPerbaikan
Cakupanevent matrix, versi selector/config, sample eventowner keamananpass/failgap biaya data event, expiryaktifkan sumber terfokus
Sink terlindungitujuan, export policy akses, uji delete negatifowner loggingpass/failjendela migrasihapus kewenangan admin rutin
Retensidurasi, lock/kontrol, tanggal reviewowner risikopass/faillegal hold/biayaperpanjang atau arsipkan
Integritas/pengambilanhasil validasi, query, latihan korelasiowner insidenpass/failbatas providertambah arsip/pemeriksaan independen

Setiap pengecualian perlu approver, scope terbatas, kontrol kompensasi, expiry, owner perbaikan, dan tanggal retest. Validasi ulang setelah perubahan organisasi, onboarding service, akun/project/subscription baru, atau latihan insiden. Pengujian infrastruktur dapat memvalidasi kontrol logging yang disetujui.

Kasus kerja: rekonstruksi perubahan ditolak

Gunakan role terkendali untuk mencoba perubahan konfigurasi tanpa izin, lalu cari event audit yang dihasilkan melalui jalur investigasi normal. Output yang diharapkan menyimpan waktu, aktor, identitas sumber, target, tindakan, hasil, dan nilai korelasi yang diperlukan untuk merekonstruksi event; uji tidak bergantung pada screenshot console. Harapan keterlambatan dan retensi harus didokumentasikan sebagai sasaran operasional, bukan dianggap jaminan real-time. Bandingkan tujuan pusat dengan akun sumber serta pipeline alert, sambil mencatat gap pengiriman.

Uji query salah bentuk, klien clock skew, autentikasi gagal, dan perubahan konfigurasi oleh automasi disetujui. Paket penutupan berisi teks query, ID event, bukti retensi atau penyimpanan tak dapat diubah bila dikonfigurasi, status alert, dan sign-off owner. Jika pengecualian mematikan sumber atau filter, tetapkan deteksi kompensasi, masa berlaku, serta pemeriksaan independen bahwa logging sudah hidup kembali. Tutup hanya setelah uji recovery menunjukkan investigator dapat mengikuti bukti tanpa akses ad hoc berprivilege.

Serah-terima operasional: investigator mencatat rentang query, identitas asumsi, gap sumber, dan kesimpulan pada catatan kasus. Owner on-call menguji akses baca role yang ditetapkan sebelum insiden. Verifikasi retensi setelah tujuan berubah. Ini menjadikan logging bukti yang dapat dipakai, bukan klaim pengumpulan.

Saat drill, reviewer membandingkan event sumber, tujuan pusat, dan alert dengan rentang waktu sama. Output harus menunjukkan apakah event hilang, terlambat, atau terfilter serta siapa yang mengeskalasi gap. Simpan keputusan perbaikan dan jadwal retest bersama kasus.

Sources

Punya sistem yang perlu diuji?