Audit dan Compliance Dasar

Bab 33 menutup dengan pengakuan jujur bahwa AppArmor punya satu keterbatasan mendasar: profilnya hanya mencatat pelanggaran akses secara teknis, tanpa pernah menjawab pertanyaan yang justru paling sering ditanyakan auditor atau tim investigasi insiden, yaitu siapa yang login, perintah apa saja yang dijalankan, dan file mana saja yang diubah pada rentang waktu tertentu. Bab ini menutup Bagian VIII melalui lapisan kelima sekaligus terakhir pada peta defense in depth yang sudah kita susun di Bagian 30.1.2, yaitu audit dan least privilege, lapisan yang bekerja dengan asumsi berbeda dari empat lapisan sebelumnya: bukan mencegah maupun membatasi Attacker, melainkan memastikan setiap aktivitas di server benar-benar tercatat dan setiap akun hanya memegang hak akses yang benar-benar dibutuhkan perannya.

Skenarionya juga konkret. Suatu pagi, Sysadmin menemukan baris asing di /etc/sudoers.d/ yang tidak pernah dibuat siapa pun di tim, atau sebuah file konfigurasi Nginx di Bab 12 yang tiba-tiba berubah tanpa ada Developer yang mengaku melakukannya. Tanpa audit log yang memadai, pertanyaan "siapa dan kapan" nyaris mustahil dijawab, karena log aplikasi biasa seperti yang akan kita bahas mendalam di Bab 39 hanya mencatat apa yang terjadi dari sudut pandang aplikasi itu sendiri, bukan siapa user Linux yang memicunya lewat proses lain. auditd menutup celah ini melalui pencatatan di level kernel yang mengikat setiap system call ke identitas user yang memicunya, sementara prinsip least privilege memastikan jumlah akun yang bisa memicu aktivitas mencurigakan itu sekecil mungkin sejak awal.

Kita akan mulai dari pengenalan auditd dan alasan log kernel ini berbeda dari log aplikasi biasa, dilanjutkan menulis audit rule untuk memantau file sensitif seperti /etc/passwd dan /etc/sudoers, mempraktikkan cara membaca hasilnya melalui ausearch dan aureport, meninjau ulang prinsip least privilege yang sebenarnya sudah kita praktikkan sejak Bab 4 melalui sudut pandang audit, memeriksa akun dan binary SUID yang berpotensi jadi celah, sampai akhirnya menutup Bagian VIII secara keseluruhan melalui checklist keamanan dasar yang merangkum seluruh lapisan sejak Bab 30.

34.1 Log Audit dengan auditd: Pengenalan

Sebelum masuk ke praktik menulis rule, ada baiknya kita menyamakan dulu pemahaman tentang posisi auditd dibanding log yang sudah kita kenal, karena keduanya sering tertukar padahal menjawab pertanyaan yang berbeda.

34.1.1 Kenapa Log Aplikasi Biasa Tidak Cukup untuk Kebutuhan Audit

journalctl dan log aplikasi seperti /var/log/nginx/access.log mencatat apa yang terjadi dari sudut pandang masing-masing aplikasi: request HTTP mana yang masuk, service mana yang gagal start. Log semacam ini sangat berguna untuk troubleshooting seperti yang sudah kita praktikkan berulang kali sejak Bab 12, tetapi tidak dirancang untuk menjawab pertanyaan bergaya audit atau compliance: user Linux mana persisnya yang membaca file /etc/shadow tadi malam, atau proses siapa yang mengubah isi /etc/sudoers.d/10-developer dari Bagian 4.2.2.

auditd (Linux Audit Daemon) bekerja pada lapisan yang jauh lebih dalam, yaitu langsung di kernel melalui subsistem Linux Audit Framework. Setiap kali sebuah proses memanggil system call yang diawasi, seperti membuka file tertentu atau menjalankan execve, kernel mencatat kejadian itu lengkap dengan UID, PID, dan waktu presisi, terlepas dari aplikasi apa yang memicunya. Karena pencatatannya terjadi di kernel, bukan di ruang aplikasi, audit log jauh lebih sulit dipalsukan dibanding log aplikasi biasa, sebuah karakteristik yang membuat auditd sering menjadi syarat wajib pada standar compliance seperti PCI DSS atau CIS Benchmark untuk server yang menyimpan data sensitif milik Client.

Satu hal penting yang perlu jujur disampaikan sejak awal: auditd murni bertugas mencatat, bukan mencegah atau memblokir apa pun. Perannya melengkapi, bukan menggantikan, empat lapisan yang sudah kita bangun dari Bab 30 sampai Bab 33. Firewall dari Bab 31 menyaring trafik, Fail2ban dari Bab 32 memblokir IP mencurigakan, AppArmor dari Bab 33 membatasi tindakan proses, sementara auditd hanya memastikan seluruh aktivitas itu, termasuk aktivitas yang lolos dari empat lapisan sebelumnya, tetap tercatat rapi untuk investigasi maupun laporan audit di kemudian hari.

34.1.2 Instalasi dan Komponen auditd

Paket auditd tidak terpasang secara default di Ubuntu Server 26.04 LTS. Paket ini membawa tiga komponen utama yang akan sering kita pakai: daemon auditd sendiri yang menulis kejadian ke log, auditctl untuk mengelola rule secara langsung, serta sepasang tool pencarian ausearch dan aureport untuk membaca hasil pencatatan tanpa perlu mem-parsing log mentah secara manual.

Langkah Praktik

1. Pasang paket auditd.

   sudo apt update
   sudo apt install auditd

2. Periksa status service setelah instalasi selesai.

   sudo systemctl status auditd

3. Konfirmasikan modul audit benar-benar aktif di level kernel.

   sudo auditctl -s

Verifikasi dan Troubleshooting

• Instalasi paket auditd otomatis mengaktifkan dan menjalankan service-nya, sehingga langkah kedua semestinya langsung menampilkan active (running) tanpa perlu perintah enable atau start tambahan.
• Output auditctl -s yang sehat menampilkan baris enabled 1, menandakan kernel sedang menerima dan mencatat event audit. Jika baris ini menampilkan enabled 0, kemungkinan besar ada parameter kernel audit=0 yang sengaja ditambahkan di GRUB, sebuah kondisi yang jarang punya alasan sah di server produksi yang perlu memenuhi kebutuhan compliance.
• Berbeda dari AppArmor pada Bagian 33.1.1 yang menampilkan active (exited) karena tugasnya selesai begitu profil dimuat, auditd memang harus tetap active (running) selamanya, karena daemon ini terus-menerus menerima dan menuliskan event dari kernel ke disk selama server menyala.

34.1.3 Menulis Audit Rule: Memantau File Sensitif

Tanpa rule, auditd terpasang tetapi tidak mencatat apa pun yang spesifik. Audit rule menentukan file, direktori, atau syscall mana saja yang diawasi. Rule berbasis file disebut watch, ditulis dengan flag -w untuk path yang diawasi, -p untuk jenis akses yang dicatat (kombinasi r baca, w tulis, x eksekusi, a perubahan atribut), dan -k untuk memberi label pencarian pada rule tersebut agar mudah ditelusuri nanti melalui ausearch.

Rule yang ditambahkan melalui auditctl secara langsung hanya berlaku sampai reboot berikutnya. Untuk rule yang perlu bertahan permanen, seperti kebutuhan audit di server produksi, kita menuliskannya ke file di direktori /etc/audit/rules.d/, mengikuti pola direktori terpisah yang sama seperti sudoers.d/ pada Bagian 4.2.2 dan jail.local pada Bagian 32.2.2, lalu memuatnya melalui augenrules.

Langkah Praktik

1. Tambahkan rule sementara untuk mencoba memantau perubahan pada /etc/passwd.

   sudo auditctl -w /etc/passwd -p wa -k identity_changes

2. Buat file rule permanen yang memantau beberapa target sensitif sekaligus: file akun (/etc/passwd, /etc/shadow, /etc/group), aturan sudoers dari Bagian 4.2.2, dan konfigurasi SSH dari Bab 3.

   sudo nano /etc/audit/rules.d/50-identity-access.rules

   Isi file tersebut dengan baris berikut.

   -w /etc/passwd -p wa -k identity_changes
   -w /etc/shadow -p wa -k identity_changes
   -w /etc/group -p wa -k identity_changes
   -w /etc/sudoers -p wa -k privilege_changes
   -w /etc/sudoers.d/ -p wa -k privilege_changes
   -w /etc/ssh/sshd_config -p wa -k sshd_changes

3. Muat ulang seluruh rule dari /etc/audit/rules.d/ agar permanen dan aktif melewati reboot.

   sudo augenrules --load

4. Konfirmasikan seluruh rule, baik yang sementara maupun permanen, sudah termuat di kernel.

   sudo auditctl -l

Verifikasi dan Troubleshooting

• Output auditctl -l semestinya menampilkan setiap baris rule persis seperti yang ditulis di file .rules, ditandai label -k masing-masing.
• Uji satu rule secara langsung dengan memicu perubahan kecil pada file yang diawasi, misalnya menambah komentar di /etc/ssh/sshd_config melalui sudo nano /etc/ssh/sshd_config lalu menyimpannya, dan pastikan kejadian ini muncul saat mencari log berdasarkan key sshd_changes pada Bagian 34.1.4 berikutnya.
• Jika augenrules --load menampilkan pesan error terkait sintaks, periksa kembali setiap baris di file .rules: flag -p hanya menerima kombinasi huruf r, w, x, a tanpa spasi, dan setiap baris hanya boleh berisi satu rule.
• Jumlah rule watch yang terlalu banyak, terutama pada direktori yang sangat aktif seperti /var/www/, bisa membebani performa server karena setiap akses ke path tersebut memicu pencatatan kernel. Fokuskan watch hanya pada file dan direktori yang benar-benar krusial untuk kebutuhan audit, bukan seluruh filesystem.

34.1.4 Membaca Log Audit dengan ausearch dan aureport

Log mentah auditd tersimpan di /var/log/audit/audit.log dalam format yang bisa dibaca manusia tetapi cukup padat, berisi pasangan kunci-nilai seperti uid=, exe=, dan key= pada setiap baris. ausearch dan aureport menyaring log ini menjadi bentuk yang jauh lebih mudah ditelusuri, tanpa kita perlu memakai grep manual pada file yang terus bertumbuh.

Langkah Praktik

1. Cari seluruh event yang tercatat dengan key privilege_changes dari rule yang sudah dibuat pada Bagian 34.1.3.

   sudo ausearch -k privilege_changes

2. Cari event berdasarkan rentang waktu, misalnya seluruh aktivitas dalam satu jam terakhir.

   sudo ausearch -k identity_changes --start recent

3. Tampilkan ringkasan otentikasi dalam bentuk tabel yang lebih ringkas dibanding output ausearch.

   sudo aureport -au

4. Tampilkan ringkasan seluruh file yang tercatat diakses berdasarkan rule watch kita.

   sudo aureport -f

Verifikasi dan Troubleshooting

• Setiap event dari ausearch menampilkan baris type=PATH dan type=SYSCALL berpasangan; baris SYSCALL memuat uid pelaku sekaligus success=yes atau success=no, sedangkan baris PATH memuat path file yang tersentuh. Untuk menerjemahkan UID numerik menjadi nama user yang lebih terbaca, tambahkan flag -i pada ausearch.

  sudo ausearch -k privilege_changes -i

• Jika ausearch maupun aureport tidak menampilkan hasil apa pun padahal rule sudah aktif, konfirmasikan dulu bahwa file yang diawasi memang benar-benar sudah tersentuh sejak rule dimuat. Rule yang ditambahkan setelah sebuah file diubah tidak bisa mencatat kejadian yang sudah lewat.
• Catatan jujur dari lapangan: pada server dengan trafik tinggi, file audit.log bisa bertumbuh sangat cepat. Konfigurasi rotasi dan batas ukurannya ada di /etc/audit/auditd.conf melalui parameter max_log_file dan max_log_file_action, terpisah dari mekanisme logrotate yang akan kita bahas untuk log aplikasi biasa di Bab 39, karena auditd mengelola rotasi log miliknya sendiri secara internal.
• Efek samping yang jujur perlu diketahui Sysadmin: begitu auditd terpasang dan aktif, daemon ini pada umumnya mengambil alih kepemilikan socket audit kernel dari systemd-journald. Artinya, denial AppArmor dari Bab 33 yang sebelumnya kita telusuri lewat journalctl -k | grep -i apparmor pada Bagian 33.3.2 berpotensi tidak lagi muncul di sana setelah bab ini, dan perlu ditelusuri lewat sudo ausearch -i | grep -i apparmor sebagai gantinya. Jika di server kita ternyata event tersebut masih tetap muncul di kedua tempat, itu bukan tanda ada yang salah, sekadar perbedaan default antar versi kernel dan paket.

34.2 Prinsip Least Privilege di Server Multi-User

Audit log yang rapi hanya menjawab pertanyaan setelah sebuah kejadian terjadi. Bagian ini bergerak selangkah lebih awal: mengecilkan sebanyak mungkin akun yang punya potensi memicu kejadian mencurigakan sejak awal, prinsip yang sebenarnya sudah kita praktikkan sepotong-sepotong sejak Bab 4 tanpa pernah menyebutnya secara eksplisit.

34.2.1 Least Privilege Sebagai Prinsip, Bukan Sekadar Tool

Least privilege berarti setiap akun, baik milik manusia maupun service, hanya diberi hak akses minimum yang benar-benar dibutuhkan untuk menjalankan tugasnya, tidak lebih. Prinsip ini bukan satu tool tunggal yang dipasang sekali lalu selesai, melainkan kebiasaan yang berjalan lintas bab: role-based access melalui group pada Bagian 4.3.1, kebijakan sudoers granular per user pada Bagian 4.2.2, sampai profil AppArmor yang membatasi capability kernel per proses pada Bab 33. Bagian ini menyatukan kebiasaan-kebiasaan itu melalui satu pertanyaan audit yang sama: dari seluruh akses yang sudah diberikan sepanjang series ini, mana saja yang ternyata lebih luas dari yang benar-benar dibutuhkan?

34.2.2 Audit Hak Akses yang Sudah Diberikan

Server yang sudah berjalan lama, apalagi yang dikelola bergantian oleh beberapa Sysadmin, cenderung menumpuk hak akses yang tidak pernah dicabut kembali. Seorang Developer yang sudah pindah tim tetapi masih tercatat di group sudo, atau baris lama di sudoers.d/ yang tidak ada yang ingat lagi alasannya, adalah temuan yang lazim muncul saat audit hak akses pertama kali dilakukan di server produksi.

Langkah Praktik

1. Daftar seluruh user yang tergabung di group sudo, sumber akses administratif paling luas di server.

   getent group sudo

2. Tinjau ulang seluruh file kustom di sudoers.d/ yang sudah dibuat sejak Bagian 4.2.2, satu per satu.

   sudo ls -la /etc/sudoers.d/
   sudo cat /etc/sudoers.d/*

3. Cari akun user yang punya UID 0 selain root, tanda akses setara root yang sering luput dari perhatian.

   awk -F: '$3 == 0 {print $1}' /etc/passwd

4. Cari akun yang tidak pernah login sama sekali, salah satu sinyal akun yang layak ditinjau ulang keberadaannya.

   sudo lastlog | grep -i "never logged in"

Verifikasi dan Troubleshooting

• Langkah ketiga semestinya hanya menampilkan root saja. Jika ada nama user lain yang ikut muncul, itu tanda serius bahwa akun tersebut punya privilege setara root penuh tanpa perlu sudo sama sekali, sebuah kondisi yang nyaris tidak pernah punya alasan sah dan perlu segera diperbaiki melalui usermod.
• Output langkah keempat wajar menampilkan cukup banyak akun service seperti www-data atau postgres, karena akun-akun ini memang tidak pernah dirancang untuk login interaktif. Abaikan baris-baris tersebut selama shell login-nya sudah nologin seperti dibahas di Bagian 34.2.3, dan fokuskan perhatian pada akun manusia yang muncul di daftar ini sekaligus tercatat di group sudo pada langkah pertama, karena kombinasi keduanya adalah kandidat paling kuat untuk ditinjau ulang atau dicabut aksesnya.
• Untuk setiap akun yang ternyata sudah tidak aktif namun masih tercatat di group sudo, cabut keanggotaannya melalui sudo deluser nama_user sudo alih-alih menghapus akunnya secara langsung, terutama jika akun tersebut masih memiliki file atau proses milik owner lain yang perlu ditelusuri dulu jejaknya melalui audit log dari Bagian 34.1.4.
• Jadwalkan audit hak akses semacam ini secara berkala, bukan hanya sekali sebelum go-live. Tim yang berubah, project yang selesai, dan Developer yang berpindah peran membuat daftar akses yang sah hari ini bisa jadi sudah kedaluwarsa beberapa bulan kemudian.

34.2.3 Membatasi Akun Service dan Binary SUID

Least privilege tidak hanya berlaku untuk akun manusia. Akun service seperti www-data milik Nginx dari Bab 12 atau postgres milik PostgreSQL dari Bab 18 semestinya tidak pernah bisa login interaktif ke shell, karena akun-akun ini hanya ada untuk menjalankan proses service, bukan untuk digunakan siapa pun masuk secara langsung. Selain akun, binary dengan bit SUID juga layak diaudit karena binary semacam ini berjalan dengan privilege pemilik file, biasanya root, terlepas dari siapa user yang mengeksekusinya, menjadikannya target favorit Attacker begitu berhasil mendapat akses awal ke server.

Langkah Praktik

1. Periksa shell login yang tercatat untuk akun service utama di server kita.

   grep -E "^(www-data|postgres|mysql):" /etc/passwd

2. Jika ditemukan akun service yang shell-nya masih /bin/bash atau /bin/sh, gantikan dengan nologin agar tidak bisa dipakai login interaktif.

   sudo usermod -s /usr/sbin/nologin www-data

3. Cari seluruh binary dengan bit SUID aktif di seluruh sistem.

   sudo find / -xdev -perm -4000 -type f 2>/dev/null

Verifikasi dan Troubleshooting

• Akun service bawaan Ubuntu Server seperti www-data pada instalasi baru biasanya sudah memakai /usr/sbin/nologin secara default sejak awal, sehingga langkah kedua umumnya hanya relevan jika ada pihak lain yang pernah mengubahnya secara manual, misalnya demi kemudahan debugging sesaat yang lupa dikembalikan.
• Hasil find pada langkah ketiga biasanya menampilkan belasan binary standar seperti /usr/bin/sudo, /usr/bin/passwd, atau /usr/bin/su, karena binary-binary ini memang butuh privilege root secara sah untuk fungsinya. Kewaspadaan justru perlu diarahkan pada binary SUID yang tidak dikenal atau berada di luar direktori sistem standar seperti /usr/bin/ dan /usr/sbin/, misalnya di /home/ atau /tmp/, karena kombinasi bit SUID dengan lokasi yang tidak lazim adalah pola umum yang dipakai Attacker untuk menanam backdoor setelah berhasil membobol sebuah server.
• Jangan mencabut bit SUID dari binary sistem standar tanpa memahami dampaknya. Mencabut SUID dari /usr/bin/sudo, misalnya, langsung membuat seluruh mekanisme sudo dari Bab 4 berhenti berfungsi bagi user biasa.

34.3 Checklist Keamanan Dasar Sebelum Go-Live

Bagian penutup ini menyatukan seluruh lapisan defense in depth dari Bagian 30.1.2 menjadi satu checklist yang layak dicentang satu per satu sebelum sebuah server benar-benar dinyatakan siap menerima trafik produksi.

34.3.1 Checklist Berdasarkan Lapisan Defense in Depth

Tabel berikut merangkum poin verifikasi minimum dari setiap lapisan yang sudah kita bangun sejak Bab 3, disusun berurutan sesuai lapisan pertahanannya. Checklist ini bukan daftar lengkap seluruh standar compliance formal seperti CIS Benchmark, melainkan titik awal praktis yang mengikat kembali setiap bab yang sudah kita selesaikan.

34.3.2 Audit Mandiri: Script Verifikasi Checklist

Meninjau tujuh baris di atas satu per satu secara manual setiap kali server hendak go-live cukup memakan waktu dan rawan terlewat. Script bash sederhana berikut menjalankan pengecekan otomatis untuk sebagian besar poin pada tabel, sebagai langkah awal sebelum kita mempelajari shell scripting untuk automasi server secara lebih mendalam di Bab 35.

Langkah Praktik

1. Buat file script baru.

   nano ~/golive_check.sh

2. Isi dengan pengecekan berikut.

   #!/bin/bash
   echo "=== SSH ==="
   grep -E "^PermitRootLogin" /etc/ssh/sshd_config.d/*.conf /etc/ssh/sshd_config 2>/dev/null
   
   echo "=== Firewall (UFW) ==="
   sudo ufw status | head -1
   
   echo "=== Fail2ban ==="
   sudo systemctl is-active fail2ban
   
   echo "=== AppArmor ==="
   sudo aa-status --enabled && echo "AppArmor aktif"
   
   echo "=== auditd ==="
   sudo systemctl is-active auditd
   sudo auditctl -l | wc -l
   
   echo "=== unattended-upgrades ==="
   sudo systemctl is-active unattended-upgrades.service 2>/dev/null || echo "cek timer via systemctl list-timers"
   
   echo "=== Akun UID 0 selain root ==="
   awk -F: '$3 == 0 {print $1}' /etc/passwd

3. Beri izin eksekusi dan jalankan.

   chmod +x ~/golive_check.sh
   ./golive_check.sh

Verifikasi dan Troubleshooting

• Baris PermitRootLogin yang sehat menampilkan nilai no, sesuai konfigurasi yang kita terapkan di Bagian 3.2.1. Baris ufw status semestinya menampilkan Status: active, dan kedua service fail2ban serta auditd semestinya menampilkan active juga.
• Jika salah satu output menampilkan inactive atau unknown, itu bukan berarti script-nya salah, melainkan tanda jujur bahwa satu lapisan pertahanan dari bab terkait belum diterapkan di server ini. Kembali ke bab yang bersangkutan sebelum melanjutkan proses go-live.
• Script ini sengaja ditulis sederhana dan hanya mencakup pengecekan status, bukan pengecekan isi rule secara mendetail. Untuk kebutuhan audit compliance yang lebih formal dan terstandarisasi, pertimbangkan tool seperti lynis atau benchmark resmi dari CIS (Center for Internet Security) yang mencakup ratusan poin pemeriksaan, jauh melampaui cakupan checklist dasar ini.

Sampai di sini Bagian VIII resmi tuntas. Lima lapisan defense in depth dari Bagian 30.1.2 sudah terbangun secara berurutan: reduksi attack surface dan patching rutin di Bab 30, filtering trafik jaringan melalui firewall di Bab 31, deteksi dan respons otomatis melalui Fail2ban di Bab 32, mandatory access control melalui AppArmor di Bab 33, hingga audit dan least privilege pada bab ini melalui auditd yang mencatat jejak aktivitas di level kernel, peninjauan ulang hak akses yang sudah menumpuk sejak Bab 4, dan checklist go-live yang mengikat seluruh lapisan menjadi satu kesatuan yang bisa diverifikasi. Server yang sudah melewati kelima lapisan ini bukan berarti kebal sepenuhnya, karena tidak ada sistem yang benar-benar tidak bisa dibobol, tetapi jauh lebih siap menahan dan mendeteksi upaya Attacker dibanding server yang baru saja selesai instalasi dasar di Bab 2. Bagian IX berikutnya beralih fokus dari keamanan ke efisiensi kerja Sysadmin sehari-hari, dimulai dari Bab 35 yang mengangkat shell scripting untuk automasi server, termasuk menuntaskan janji pada Bagian 34.3.2 melalui penulisan script yang lebih rapi dengan error handling dan logging yang layak, sebelum masuk ke Ansible dan cloud-init sebagai Infrastructure as Code pada dua bab setelahnya.