Birçok kurum sunucu sertleştirmesini SSH ayarları, paket güncellemeleri ve firewall kurallarıyla sınırlar. Bunlar gereklidir; ancak uygulama sürecinin neye erişebileceğini kısıtlamadığınız sürece ihlal sonrası hareket alanı geniş kalır. AppArmor, özellikle Ubuntu ve Debian tabanlı altyapılarda bu boşluğu kapatmak için pratik bir araçtır. Gücü, çekirdeğe büyük bir güvenlik çerçevesi eklemesinden değil; servis bazında okunabilir kısıtlar tanımlayabilmesinden gelir.
AppArmor hangi problem için uygundur?
Şu senaryolarda ciddi fayda sağlar:
- Reverse proxy, job worker veya ajan gibi belirli süreçlerin dosya erişimini daraltmak
- Beklenmeyen komut çalıştırma yollarını kapatmak
- Servisin sadece ihtiyaç duyduğu ağ ve dosya alanıyla çalışmasını sağlamak
- Güvenlik ihlalinde yatay hareketi zorlaştırmak
Amaç her şeyi yasaklamak değil, normal davranışı tanımlayıp bunun dışına çıkan hareketi görünür ve engellenebilir hâle getirmektir.
Audit moduyla başlamak neden önemlidir?
Doğrudan enforce moduna geçmek küçük servislerde bile kırılgan olabilir. Önce profilin deneme modunda çalışması, gerçek erişim desenini görmek için kritiktir. Tipik başlangıç akışı şudur:
- Servis için temel profil üret
complainmodunda çalıştır- Audit kayıtlarını incele
- Meşru erişimleri profile ekle
- Sonra
enforcemoduna geçir
Bu sıra, “güvenlik açtık ama servis niye durdu” sürprizlerini azaltır.
Basit bir profil örneği
Aşağıdaki örnek, /usr/local/bin/report-exporter adlı bir servisin yalnızca kendi konfigürasyonunu okuyup belirli dizine yazabilmesini hedefleyen sade bir başlangıç verir:
# /etc/apparmor.d/usr.local.bin.report-exporter
abi <abi/4.0>,
include <tunables/global>
/usr/local/bin/report-exporter {
include <abstractions/base>
/usr/local/bin/report-exporter mr,
/etc/report-exporter/config.yaml r,
/var/lib/report-exporter/** rwk,
/var/log/report-exporter/** rw,
deny /home/** rwklx,
deny /root/** rwklx,
deny /etc/shadow r,
deny /bin/sh x,
deny /usr/bin/curl x,
}Bu profil iki önemli fikir taşır: süreç yalnızca ihtiyaç duyduğu yolları açar ve özellikle shell ya da key dosyalarına erişim açıkça reddedilir.
Loglar nasıl okunmalı?
Profil devreye alındığında asıl öğretici alan audit kayıtlarıdır. Özellikle şu desenleri arayın:
- Beklenmeyen dosya açma denemeleri
- Shell veya yardımcı ikili çalıştırma girişimleri
- Geçici dizinlerde gereksiz yazma denemeleri
- Servisin normalde erişmemesi gereken gizli anahtar yolları
Bu kayıtlar bazen saldırı denemesi, bazen de yıllardır fark edilmeyen gereksiz bağımlılık anlamına gelir. Her iki durumda da değer üretir.
Operasyon ekipleri için pratik yaklaşım nedir?
Ben AppArmor’u merkezi bir baseline yerine servis sınıfı bazında ele almayı öneriyorum:
- Proxy ve edge servisleri
- Arka plan işleyicileri
- Gözlemlenebilirlik ajanları
- Yönetim yardımcı araçları
Her sınıf için tekrar kullanılabilir profil kalıpları oluşturmak, yeni sunucu açıldığında güvenliği hızlandırır. Böylece AppArmor bir kere açılıp unutulan araç değil, altyapı standardının parçası olur.
Hangi hatalar sık görülür?
En yaygın hata, kırılan meşru erişimleri çözmek için profili hızla genişletip yine anlamsız hâle getirmektir. İkinci hata ise tüm servisler için tek profil mantığı kurmaktır. Güvenli ve sürdürülebilir yaklaşım, dar kapsamlı ama anlaşılır profilleri çoğaltmaktır.
Sonuç
AppArmor ile servis bazlı Linux sertleştirme, klasik sunucu güvenliğini süreç seviyesine taşır. Dosya, komut ve çalışma davranışı sınırlandığında saldırganın hareket alanı belirgin biçimde azalır. Kurumsal altyapılarda gerçek değer, bu profilleri birkaç kritik servis üzerinde sessizce çalıştırmakta değil; onları gözlemlenebilir ve tekrar kullanılabilir operasyon standardına dönüştürmektedir.