Belajar System Engineer - Compliance & Audit Sistem

#Pendahuluan

Setelah episode 19 mengendalikan akses, ada pertanyaan berikutnya: siapa yang mengawasi pengendalian itu? Di dunia enterprise, jawabannya bukan hanya manajemen — tetapi juga audit. Regulasi seperti ISO 27001, SOC 2, dan UU Pelindungan Data Pribadi (UU PDP) di Indonesia mewajibkan perusahaan membuktikan bahwa sistemnya dikelola dengan benar, dan bukti itu harus tersedia kapan saja.

Mengapa episode ini penting? Karena audit bukan acara tahunan yang bisa "disiapkan semalam" — ia adalah disiplin berkelanjutan yang menuntut bukti dari kebiasaan operasional harian. Episode ini membekali kalian: apa yang diaudit, bagaimana log audit yang benar dibangun, framework yang umum dipakai, dan bagaimana menyusun evidence tanpa panik di akhir tahun.

#Apa yang Diaudit dan Kenapa

Auditor bertanya: "Tunjukkan bukti bahwa kalian mengendalikan sistem ini." Area yang biasanya diaudit:

Pola yang harus kalian pegang: apa pun yang diklaim dalam kebijakan harus bisa dibuktikan dengan data. Kebijakan tanpa bukti = tidak ada.

#Audit Logs: Fondasi Bukti

#Mengumpulkan Log yang Benar

Log audit harus lengkap, tidak bisa diubah, dan tahan lama. Komponennya:

# Otentikasi & otorisasi
/var/log/auth.log        # login, sudo, su (Debian/Ubuntu)
/var/log/secure          # login, sudo (RHEL/Rocky)
 
# Aplikasi & service
/var/log/syslog          # pesan sistem umum
journald                  # log service (journalctl)
 
# Audit syscall (auditd)
/var/log/audit/audit.log  # akses file, exec, perubahan konfigurasi

#auditd untuk Audit Level Kernel

auditd merekam aktivitas di level kernel — siapa yang mengakses file, menjalankan program, atau mengubah konfigurasi:

sudo apt install -y auditd
sudo systemctl enable --now auditd

# Rekam eksekusi dari semua user (untuk forensic)
-w /usr/bin/sudo -p x -k sudo_exec
-w /etc/passwd -p wa -k user_accounts
-w /etc/ssh/sshd_config -p wa -k sshd_config
# Pantau seluruh syscall execve (gambar besar; sesuaikan beban)
-a always,exit -F arch=b64 -S execve -k exec_events

Log audit dibaca dengan ausearch dan aureport:

sudo ausearch -k user_accounts -ts today
sudo aureport -au --start today       # laporan autentikasi hari ini

#Proteksi Log dari Manipulasi

Bukti audit tidak berguna jika bisa diubah. Kunci praktiknya:

• Centralized logging — kirim log ke server log terpusat (episode 10); lebih sulit diubah.
• WORM/immutable storage — S3 Object Lock atau media append-only.
• Forward ke SIEM (Wazuh, Splunk) untuk korelasi dan alert.

#Regulatory Frameworks

#Yang Umum Dipakai

UU PDP (UU No. 27/2022) di Indonesia mewajibkan pengendali data menerapkan perlindungan teknis yang wajar — dari akses kontrol, enkripsi, sampai mekanisme pelaporan kebocoran data. Sebagai System Engineer, kalian yang menyediakan bukti teknis atas pemenuhan ini.

#Control Mapping: Kebijakan → Evidence

Teknik menyusun compliance: petakan setiap kontrol framework ke bukti teknis yang sudah kalian bangun di episode-episode sebelumnya.

Dengan peta ini, kalian tahu apa yang harus dikumpulkan setiap bulan, bukan dikejar di akhir tahun.

#Praktik: Audit Readiness

Buat rutinitas audit readiness bulanan:

# 1. Pastikan log terpusat masih menerima data
curl http://log-server:9200/_cat/indices | head
 
# 2. Cek auditd masih berjalan & menulis
systemctl is-active auditd
sudo aureport -au --start -30 days | tail
 
# 3. Review akses: siapa saja yang masih punya akses?
getent passwd | grep -v nologin
sudo grep sudo /etc/group
 
# 4. Laporan patch bulanan
apt list --upgradable | wc -l
 
# 5. Uji restore backup (lihat episode 11)
restic snapshots --latest
 
# 6. Simpan semua output ke folder evidence bulanan
mkdir -p /evidence/$(date +%Y-%m)
# ... salin laporan & log di atas ...

#Kesalahan Umum

1. Log hanya lokal — hilang saat server di-compromise; tidak bisa dijadikan bukti.
2. Audit log bisa diubah — tanpa centralized + immutable, bukti tidak valid.
3. Menyusun evidence "semalam" sebelum audit — data lama tidak ada, terpaksa mengarang.
4. Kebijakan tanpa bukti teknis — auditor meminta data, bukan janji.
5. Retensi log tidak diatur — log dipotong sebelum masa audit selesai.

#Penutup

Inti yang harus dibawa pulang:

• Audit menuntut bukti teknis untuk setiap klaim kebijakan.
• Bangun audit logs yang lengkap (auth, aplikasi, syscall), terpusat, immutable, dan beretensi jelas.
• Kenali framework: ISO 27001, SOC 2, GDPR, UU PDP — dan petakan kontrol → evidence.
• Jadikan audit readiness rutinitas bulanan, bukan acara tahunan.

Di episode 21 selanjutnya kita memastikan layanan tetap hidup saat komponen gagal: high availability & load balancing — clustering, keepalived, dan load balancer. Sampai jumpa di episode 21!