AppArmor di Server

Bab 32 menutup dengan satu pengakuan jujur: Fail2ban berhenti berdaya persis pada titik Attacker benar-benar berhasil masuk lewat celah lain, karena tugasnya memang mencegah percobaan masuk yang berulang, bukan membatasi apa yang boleh dilakukan sebuah proses begitu ia sudah berjalan di dalam sistem. Bab ini masuk ke lapisan keempat pada peta defense in depth yang sudah kita susun di Bagian 30.1.2, yaitu AppArmor, melalui asumsi kerja yang justru berbeda dari tiga lapisan sebelumnya: bukan mencegah Attacker masuk, melainkan membatasi kerusakan yang bisa dibuat sebuah proses begitu berjalan, sekalipun proses tersebut berjalan sebagai root.

Skenarionya konkret dan sering ditemui di lapangan. Sebuah celah keamanan pada aplikasi PHP yang dikelola Developer, misalnya vulnerability upload file sembarangan, bisa dieksploitasi Attacker untuk menjalankan perintah arbitrary lewat proses PHP-FPM dari Bab 14. Tanpa AppArmor, proses PHP-FPM yang berjalan sebagai user www-data itu bebas membaca atau menulis file apa pun yang secara permission Linux biasa memang bisa diakses user www-data, termasuk direktori aplikasi lain yang kebetulan ikut memberi akses baca ke grup yang sama. AppArmor menutup celah ini melalui cara membatasi proses tersebut agar hanya boleh mengakses direktori, file, dan capability kernel yang benar-benar didaftarkan di profile-nya, sehingga permission Linux yang longgar sekalipun tidak lagi menjadi jalan bebas bagi proses yang sudah dibajak.

Kita akan mulai dari review konsep Mandatory Access Control dan anatomi profile AppArmor, dilanjutkan memeriksa profile bawaan yang sudah melindungi BIND9 sejak Bab 9 dan MariaDB sejak Bab 20, mengonfirmasi sendiri bahwa Nginx dan PHP-FPM justru berjalan tanpa profile bawaan sama sekali, melihat bagaimana Docker dan LXD justru sudah bersandar pada AppArmor sejak awal untuk mengisolasi container, memahami perbedaan mode enforce dan complain lewat praktik langsung berpindah mode, lalu ditutup dengan membangun profile kustom sederhana untuk Nginx dari nol memakai aa-genprof.

33.1 Review Konsep AppArmor

Sebelum masuk ke praktik memeriksa dan membuat profile, ada baiknya kita menyamakan dulu pemahaman soal apa sebenarnya yang dikerjakan AppArmor di balik layar, karena istilah-istilah pada bagian ini akan terus muncul di seluruh bab.

33.1.1 Mandatory Access Control: Kenapa Permission Linux Biasa Tidak Cukup

Permission Linux biasa, yaitu kombinasi owner, group, dan mode yang sudah kita kenal sejak Linux 101, termasuk model Discretionary Access Control (DAC). Disebut discretionary karena kendalinya ada di tangan pemilik file atau proses itu sendiri, dan hal yang paling penting, proses yang berjalan sebagai root nyaris selalu bisa melewati batasan DAC apa pun. Ini titik lemah mendasarnya: begitu sebuah proses berhasil dibajak Attacker dan proses itu kebetulan berjalan sebagai root, seperti beberapa daemon database atau DNS server yang butuh privilege tinggi saat startup, DAC sama sekali tidak berdaya membatasi apa yang bisa dilakukan proses tersebut selanjutnya.

Mandatory Access Control (MAC) mengambil pendekatan berbeda. Kebijakan akses ditentukan oleh administrator lewat kebijakan yang dipaksakan kernel, terlepas dari privilege pemilik proses, termasuk root sekalipun. AppArmor adalah implementasi MAC di Linux dalam bentuk Linux Security Module (LSM), kerangka kerja resmi kernel Linux yang memungkinkan modul keamanan menyisip di titik-titik krusial pemanggilan system call sebelum benar-benar dieksekusi. AppArmor bukan satu-satunya implementasi LSM; SELinux yang dipakai di keluarga distro Red Hat/Fedora adalah implementasi MAC lain dengan filosofi label-based yang jauh lebih rumit dikonfigurasi. Ubuntu dan seluruh keluarga Debian memilih AppArmor karena modelnya berbasis path, jauh lebih mudah dibaca dan ditulis manusia dibanding label SELinux, serta sudah terpasang dan aktif sejak instalasi awal di Bab 2.

Langkah Praktik

1. Konfirmasikan modul AppArmor benar-benar aktif di level kernel.

   cat /sys/module/apparmor/parameters/enabled

2. Periksa status service yang mengelola pemuatan profile saat boot.

   sudo systemctl status apparmor

Verifikasi dan Troubleshooting

• Output langkah pertama yang sehat menampilkan huruf Y, tanda kernel benar-benar memuat AppArmor sebagai LSM aktif. Ubuntu Server 26.04 memuat AppArmor secara default sejak instalasi, sehingga langkah ini semestinya tidak pernah menampilkan N kecuali ada pihak yang sengaja menonaktifkannya lewat parameter apparmor=0 di GRUB, sebuah tindakan yang jarang punya alasan sah di server produksi.
• systemctl status apparmor yang normal menampilkan active (exited), bukan active (running). Ini bukan tanda kegagalan; unit ini bertugas memuat seluruh profile ke kernel sekali saat boot lalu selesai, karena penegakan kebijakan setelahnya sepenuhnya ditangani kernel sendiri, bukan oleh proses daemon yang terus berjalan di userspace.

33.1.2 Anatomi Profile: Path Entries, Capability Entries, dan Lokasi di /etc/apparmor.d/

Satu profile AppArmor adalah file teks biasa yang mendefinisikan apa saja yang boleh diakses satu executable tertentu. Profile berisi dua jenis aturan utama. Path entries menentukan file atau direktori mana saja yang boleh diakses proses beserta mode aksesnya, seperti baca (r), tulis (w), atau eksekusi (x). Capability entries menentukan capability kernel Linux mana yang boleh dipakai proses tersebut, misalnya net_bind_service yang mengizinkan proses non-root membuka port di bawah 1024 seperti port 80 yang dipakai Nginx sejak Bab 12. Profile disimpan di direktori /etc/apparmor.d/, menggunakan konvensi penamaan lama yang menggantikan setiap karakter / pada path executable dengan tanda titik, misalnya profile untuk /usr/sbin/named milik BIND9 disimpan sebagai /etc/apparmor.d/usr.sbin.named.

Perintah aa-status, aa-genprof, aa-logprof, aa-complain, dan aa-enforce yang akan sering kita pakai sepanjang bab ini bukan bagian dari package apparmor dasar yang sudah aktif sejak Bab 2, melainkan disediakan lewat package terpisah bernama apparmor-utils yang tidak terpasang secara default.

Langkah Praktik

1. Pasang apparmor-utils untuk mendapatkan seluruh perintah aa-*.

   sudo apt install apparmor-utils

2. Lihat ringkasan seluruh profile yang sedang dimuat kernel beserta modenya.

   sudo aa-status

Verifikasi dan Troubleshooting

• Output aa-status pada instalasi baru Ubuntu Server 26.04 biasanya sudah menampilkan beberapa profile bawaan sistem seperti /usr/sbin/tcpdump atau profile terkait snapd, kira-kira berbentuk seperti berikut, meski jumlah persis profile bisa berbeda tergantung package apa saja yang sudah terpasang.

  apparmor module is loaded.
  15 profiles are loaded.
  12 profiles are in enforce mode.
     /usr/sbin/tcpdump
     ...
  3 profiles are in complain mode.
     ...
  0 processes have profiles defined.

• Baris processes have profiles defined yang masih nol adalah hal wajar pada tahap ini, karena service seperti Nginx atau PHP-FPM yang sedang berjalan di server kita memang belum punya profile sama sekali, persis isu yang kita bedah di Bagian 33.2.

33.2 Profile AppArmor untuk Service: Nginx, PHP-FPM, dan Database

Fondasi konsep sudah siap. Bagian ini membuktikan langsung sesuatu yang sempat dijanjikan sejak Bab 9, sekaligus meluruskan asumsi keliru yang wajar muncul: tidak semua service otomatis terlindungi AppArmor hanya karena modulnya aktif di kernel.

33.2.1 Service yang Sudah Terlindungi Sejak Awal: BIND9 dan MariaDB

Bagian 9.2.1 sempat menyinggung bahwa BIND9 di Ubuntu berjalan di bawah profil AppArmor yang membatasi direktori mana saja yang boleh diakses proses named, dan menjanjikan pembahasan lebih dalam di bab ini. Package bind9 memang menyertakan profile siap pakai di /etc/apparmor.d/usr.sbin.named yang otomatis aktif dalam mode enforce begitu package terpasang, tanpa perlu satu langkah konfigurasi tambahan apa pun dari kita.

MariaDB dari Bab 20 punya cerita yang lebih baru dan layak diketahui Sysadmin. Sejak MariaDB 11.8, komunitas MariaDB merilis ulang profile AppArmor untuk mariadbd yang jauh lebih matang dibanding profile lama, melalui setiap baris aturannya yang diuji lewat lebih dari 7.000 test case dari test suite resmi mariadb-test-run, jauh lebih banyak dibanding sekitar 1.000 test yang lazim dipakai jalur CI packaging Debian/Ubuntu pada umumnya. Hasilnya adalah profile setebal sekitar 200 baris yang disimpan di /etc/apparmor.d/mariadbd, tanpa konvensi titik pada namanya karena mengikuti gaya penamaan baru yang lebih ringkas, berbeda dari konvensi lama usr.sbin.named milik BIND9.

Langkah Praktik

1. Konfirmasikan profile named milik BIND9 benar-benar berjalan dalam mode enforce.

   sudo aa-status | grep -A1 named

2. Lakukan hal yang sama untuk profile mariadbd.

   sudo aa-status | grep -A1 mariadbd

3. Lihat jumlah baris profile MariaDB tanpa perlu membuka isinya satu per satu.

   sudo wc -l /etc/apparmor.d/mariadbd

Verifikasi dan Troubleshooting

• Kedua perintah aa-status | grep di atas semestinya menampilkan path profile diikuti keterangan bahwa proses named atau mariadbd sedang berjalan dalam mode enforce. Jika BIND9 atau MariaDB belum terpasang mengikuti Bab 9 atau Bab 20, baris ini wajar tidak muncul sama sekali.
• Profile mariadbd tergolong baru dirilis ulang oleh komunitas MariaDB, sehingga ada kemungkinan revisi packaging Ubuntu 26.04 yang terpasang di server kita masih menandainya complain mode alih-alih enforce sebagai sikap kehati-hatian sementara. Ini bukan tanda kerusakan. Jika ternyata demikian, pindahkan manual ke enforce lewat sudo aa-enforce /etc/apparmor.d/mariadbd mengikuti pola yang sama dengan Bagian 33.3.2.
• Catatan jujur dari lapangan: profile bawaan seperti mariadbd di atas dirancang untuk mendukung konfigurasi default packaging Debian/Ubuntu, termasuk lokasi data directory baku di /var/lib/mysql seperti dibahas di Bagian 20.1.1. Jika kelak Sysadmin memindahkan data directory MariaDB ke lokasi kustom di luar path baku tersebut, misalnya ke mount point disk tambahan dari Bab 7, profile ini bisa saja menolak akses ke lokasi baru itu meski permission Linux-nya sudah benar, sebuah gejala yang persis sama dengan yang sudah diperingatkan untuk BIND9 di Bagian 9.2.1.

33.2.2 Nginx dan PHP-FPM: Service yang Berjalan Tanpa Profile Bawaan

Berbeda dari BIND9 dan MariaDB, package Nginx maupun PHP-FPM dari Bab 12 dan Bab 14 sampai penulisan series ini tidak menyertakan profile AppArmor apa pun secara default. Hal ini bukan berarti keduanya lebih rentan secara desain, karena Nginx dan PHP-FPM tetap dilindungi lapisan permission Linux biasa serta prinsip least privilege lewat user www-data yang sudah berjalan sejak instalasi. Namun tanpa profile AppArmor, tidak ada lapisan MAC tambahan yang membatasi proses tersebut seandainya berhasil dibajak, celah yang justru kita tutup sendiri di Bagian 33.4 lewat profile kustom.

Langkah Praktik

1. Cari profile untuk Nginx atau PHP-FPM di direktori konfigurasi AppArmor.

   ls /etc/apparmor.d/ | grep -iE "nginx|php"

2. Konfirmasikan lewat aa-status bahwa proses keduanya benar-benar tidak tercatat sebagai proses berprofil.

   sudo aa-status | grep -iE "nginx|php-fpm"

Verifikasi dan Troubleshooting

• Kedua perintah di atas semestinya tidak menampilkan output apa pun, membuktikan Nginx dan PHP-FPM benar-benar berjalan tanpa lapisan MAC tambahan. Ini bukan error, melainkan konfirmasi kondisi awal yang jadi alasan Bagian 33.4 relevan dipraktikkan.
• Catatan yang sama juga berlaku untuk Apache dari Bab 13, seperti sempat disinggung di Bagian 17.3.3 saat membahas troubleshooting sertifikat: Apache di Ubuntu juga tidak berjalan di bawah profil AppArmor yang membatasi direktori secara ketat, sehingga penyebab error di Apache jauh lebih sering berasal dari permission Linux biasa yang keliru dibanding penolakan AppArmor.

33.2.3 AppArmor di Balik Layar Container: Docker dan LXD

Satu kesalahpahaman yang wajar muncul setelah dua bagian sebelumnya: menganggap AppArmor hanya relevan untuk service yang berjalan langsung di host. Faktanya, dua teknologi container yang sudah kita pakai sejak Bagian VII, yaitu Docker di Bab 26 dan LXD di Bab 29, sama-sama bersandar pada AppArmor sebagai salah satu lapisan isolasi utamanya, seringkali tanpa kita sadari.

Docker secara otomatis menerapkan profile bawaan bernama docker-default ke setiap container yang dijalankan, kecuali kita sengaja menimpanya lewat opsi --security-opt. Profile ini membatasi container agar tidak bisa melakukan aksi berisiko tinggi terhadap host, misalnya memuat modul kernel baru atau menulis langsung ke sebagian besar path di bawah /proc dan /sys. LXD mengambil pendekatan serupa tetapi lebih ketat: setiap instance container yang dijalankan lewat lxc launch sejak Bagian 29.3 otomatis dikurung AppArmor-nya sendiri-sendiri, dikombinasikan dengan user namespace pada container unprivileged yang menjadi default LXD, untuk mencegah satu container membaca proses atau mengirim sinyal ke container lain maupun ke host.

Langkah Praktik

1. Konfirmasikan profile AppArmor yang aktif pada sebuah container Docker yang sedang berjalan, ganti nama_container sesuai container nyata di server kita.

   docker inspect --format '{{.AppArmorProfile}}' nama_container

Verifikasi dan Troubleshooting

• Output yang sehat menampilkan docker-default. Jika hasilnya kosong atau bertuliskan unconfined, container tersebut dijalankan dengan --security-opt apparmor=unconfined atau flag --privileged, yang berarti seluruh lapisan MAC dari AppArmor dilepas sepenuhnya untuk container itu. Sysadmin perlu memastikan ada alasan kuat di balik konfigurasi ini, misalnya kebutuhan debugging sesaat, bukan sekadar jalan pintas menghindari error permission yang sebenarnya bisa diperbaiki dengan profile kustom.
• Poin penting yang jujur perlu ditekankan: profile docker-default dan pengurungan bawaan LXD dirancang untuk mengisolasi container dari host dan dari container lain, bukan untuk membatasi aplikasi spesifik yang berjalan di dalam container tersebut secara detail. Nginx atau PHP-FPM yang berjalan di dalam sebuah container Docker tetap tidak otomatis mendapat profile sedetail yang kita bangun manual di Bagian 33.4, karena profile docker-default beroperasi di level container secara keseluruhan, bukan di level proses individual di dalamnya.

33.3 Mode Enforce vs Complain

Bagian sebelumnya berulang kali menyebut kata "enforce". Bagian ini menuntaskan konsepnya secara utuh sekaligus mempraktikkan cara berpindah mode dengan aman, bekal wajib sebelum kita berani membuat profile kustom sendiri di Bagian 33.4.

33.3.1 Perbedaan Fundamental Kedua Mode

Sebuah profile AppArmor selalu berjalan dalam salah satu dari dua mode. Enforce mode berarti kebijakan pada profile benar-benar dipaksakan kernel; setiap akses yang tidak diizinkan langsung ditolak sekaligus dicatat ke log. Complain mode berarti kebijakan tidak dipaksakan sama sekali, setiap akses tetap diizinkan apa pun isi profile-nya, tetapi pelanggaran terhadap profile tetap dicatat ke log persis seperti pada mode enforce. Complain mode dirancang khusus untuk masa pengembangan profile, situasi saat kita belum yakin akses apa saja yang benar-benar dibutuhkan sebuah aplikasi agar berjalan normal, sedangkan enforce mode adalah kondisi akhir yang kita tuju begitu profile sudah cukup matang untuk benar-benar melindungi.

33.3.2 Praktik: Berpindah Mode pada Profile MariaDB

Profile mariadbd dari Bagian 33.2.1 menjadi bahan latihan paling aman untuk mencoba perpindahan mode, karena profilnya sudah matang dan teruji, sehingga risiko benar-benar mengganggu layanan database sangat kecil selama hanya dipindah sesaat untuk keperluan latihan.

Langkah Praktik

1. Pindahkan profile mariadbd ke complain mode.

   sudo aa-complain /etc/apparmor.d/mariadbd

2. Konfirmasikan perubahan mode lewat aa-status.

   sudo aa-status | grep -B2 mariadbd

3. Kembalikan ke enforce mode setelah selesai bereksperimen.

   sudo aa-enforce /etc/apparmor.d/mariadbd

Verifikasi dan Troubleshooting

• Baris hasil grep pada langkah kedua semestinya berpindah dari daftar profiles are in enforce mode ke daftar profiles are in complain mode, lalu kembali lagi setelah langkah ketiga dijalankan.
• Pelanggaran yang tercatat AppArmor, baik dalam mode complain maupun enforce, selalu masuk ke kernel audit log, bukan ke log aplikasi biasa. Pantau lewat perintah berikut untuk melihat baris mana saja pada profile mariadbd yang sempat tersentuh proses.

  sudo journalctl -k | grep -i apparmor | grep -i mariadb

• Jika di server produksi enforce mode pada sebuah profile ternyata memutus akses yang seharusnya sah, jangan mencopot profile-nya sama sekali sebagai jalan pintas. Pindahkan dulu ke complain mode lewat aa-complain, baca log denial-nya, lalu tambahkan aturan yang kurang lewat file local override di /etc/apparmor.d/local/mariadbd. Pola ini sengaja dibuat identik dengan pola jail.local pada Fail2ban di Bagian 32.2.2: file utama tidak pernah disunting langsung agar tidak tertimpa saat package di-upgrade, seluruh kustomisasi kita ditampung di file local yang terpisah.

33.4 Membuat Profile Kustom Sederhana untuk Nginx

Bagian penutup ini menuntaskan celah yang sudah dibuktikan sendiri di Bagian 33.2.2: Nginx berjalan tanpa profile AppArmor apa pun. Alih-alih menulis profile dari nol baris demi baris, yang rawan salah dan memakan waktu, kita memakai aa-genprof, tool yang mengamati perilaku nyata aplikasi lalu menyusun profile berdasarkan akses yang benar-benar terjadi.

33.4.1 Alur aa-genprof: Mengamati Nginx Sambil Berjalan

aa-genprof bekerja secara interaktif: begitu dijalankan, ia langsung menaruh Nginx ke complain mode dan menunggu kita "melatih" aplikasinya dengan cara memakainya secara normal di jendela terminal lain, persis kegunaan sesi tmux yang sudah kita kenal sejak Bagian 3.3.1. Setiap akses yang tercatat selama masa latihan itulah yang nantinya diusulkan aa-logprof untuk dimasukkan ke profile.

Langkah Praktik

1. Buka sesi tmux baru dan pecah menjadi dua pane, mengikuti kebiasaan dari Bagian 3.3.1.
2. Pada pane pertama, mulai proses pembuatan profile untuk binary Nginx.

   sudo aa-genprof /usr/sbin/nginx

   aa-genprof akan menampilkan pesan bahwa Nginx sudah dipindah ke complain mode dan menunggu kita menekan S untuk mulai memindai log setelah selesai "melatih" aplikasinya.
3. Tanpa menutup pane pertama, pindah ke pane kedua dan jalankan seluruh operasi normal yang biasa dilakukan Nginx di server kita, memakai virtual host example.local dari Bagian 12.2.1 dan konfigurasi HTTPS dari Bagian 17.3.2.

   curl http://example.local
   curl -k https://example.local
   sudo systemctl reload nginx
   sudo nginx -t

4. Kembali ke pane pertama, tekan S untuk memindai log akses yang baru saja terjadi.

Verifikasi dan Troubleshooting

• Jika pane pertama tidak kunjung menampilkan opsi (S)can, pastikan package apparmor-utils sudah terpasang seperti pada Bagian 33.1.2, karena aa-genprof adalah bagian dari package tersebut.
• Semakin lengkap operasi yang dicoba pada pane kedua, semakin lengkap pula profile yang dihasilkan. Jika ada fitur Nginx lain yang dipakai di server produksi, misalnya reverse proxy dari Bagian 12.3.2 atau rotasi log dari Bagian 12.4.2, ulangi operasi tersebut sebelum menekan S agar akses yang relevan ikut terekam.

33.4.2 aa-logprof: Meninjau Saran dan Mengaktifkan Enforce

Setelah pemindaian, aa-genprof memanggil aa-logprof di balik layar untuk menampilkan setiap akses yang tercatat sebagai usulan satu per satu, lengkap dengan beberapa pilihan mode akses yang bisa kita terima.

Langkah Praktik

1. Tinjau setiap usulan yang muncul. Bentuknya kira-kira seperti berikut untuk akses ke file log Nginx.

   Profile:  /usr/sbin/nginx
   Path:     /var/log/nginx/access.log
   New Mode: owner w
   
     [1 - owner w]
   (A)llow / [(D)eny] / (I)gnore / Audi(t) / Abo(r)t / (F)inish

   Tekan A untuk menyetujui akses yang memang wajar dibutuhkan Nginx, seperti akses tulis ke direktori log-nya sendiri di /var/log/nginx/, akses baca ke /etc/nginx/ beserta seluruh sites-enabled-nya, dan akses ke socket PHP-FPM di /run/php/php8.4-fpm.sock dari Bagian 14.3.1 seandainya Nginx di server kita meneruskan request PHP.
2. Setelah seluruh usulan habis ditinjau, tekan F untuk menyelesaikan proses. aa-genprof otomatis menuliskan profile final ke /etc/apparmor.d/usr.sbin.nginx dan langsung memindahkannya ke enforce mode.

Verifikasi dan Troubleshooting

• Konfirmasikan profile baru sudah tercatat dan berjalan dalam enforce mode.

  sudo aa-status | grep -A1 nginx

• Uji ulang seluruh akses yang tadi dipakai untuk "melatih" profile, sekarang dalam kondisi enforce sungguhan, bukan sekadar complain.

  curl http://example.local
  curl -k https://example.local

• Jika salah satu curl di atas gagal atau Nginx menampilkan error 500/502 yang sebelumnya tidak pernah muncul, profile yang baru dibuat kemungkinan besar melewatkan satu akses yang ternyata dibutuhkan. Jangan panik dan jangan langsung menghapus profile-nya. Pindahkan dulu ke complain mode agar layanan pulih seketika, baca log denial-nya, lalu ulangi aa-logprof /usr/sbin/nginx untuk menambahkan akses yang terlewat.

  sudo aa-complain /etc/apparmor.d/usr.sbin.nginx
  sudo journalctl -k | grep -i apparmor | grep -i nginx

• Setelah akses yang kurang ditambahkan dan dipastikan aman, kembalikan ke enforce mode.

  sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx

• Perlakukan profile kustom buatan sendiri secara lebih hati-hati dibanding profile bawaan seperti mariadbd dari Bagian 33.2.1. Profile mariadbd sudah teruji lewat ribuan test case resmi, sedangkan profile Nginx yang baru saja kita buat hanya seluas skenario yang sempat kita coba secara manual. Jika ada perubahan konfigurasi Nginx yang signifikan di kemudian hari, misalnya menambah virtual host baru dengan struktur direktori berbeda, ulangi siklus complain-latih-logprof di atas alih-alih berasumsi profile lama otomatis mencakup skenario baru.

Sampai di sini kita sudah menuntaskan lapisan keempat defense in depth dari Bagian 30.1.2: memahami AppArmor sebagai implementasi Mandatory Access Control yang bekerja lewat kombinasi path entries dan capability entries, membuktikan sendiri bahwa BIND9 dan MariaDB sudah terlindungi profile bawaan sejak awal sementara Nginx dan PHP-FPM ternyata tidak, mengenali AppArmor sebagai fondasi isolasi Docker dan LXD yang bekerja di level container alih-alih di level proses individual, mempraktikkan perpindahan aman antara complain dan enforce mode lewat profile mariadbd, hingga membangun profile kustom untuk Nginx dari nol memakai aa-genprof dan aa-logprof. AppArmor tetap punya batasan yang jujur perlu diakui: ia hanya sekuat cakupan profile yang dimilikinya, tidak bisa mencatat siapa pelakunya atau kapan persisnya sebuah akses mencurigakan terjadi di luar log denial teknis, dan tetap butuh Sysadmin yang disiplin memperbarui profile setiap kali konfigurasi aplikasi berubah signifikan. Bab 34 berikutnya menutup Bagian VIII lewat lapisan kelima sekaligus terakhir pada peta defense in depth kita, yaitu audit dan least privilege, mulai dari pengenalan auditd untuk mencatat jejak aktivitas sistem secara menyeluruh, prinsip least privilege di server multi-user, hingga checklist keamanan dasar yang layak dicentang satu per satu sebelum sebuah server benar-benar dinyatakan siap go-live.