Mimari ve çalışma modeli
systemd sandbox ayarları servisi ayrı bir container'a dönüştürmez; süreç kimliği, Linux capabilities, mount namespace, cihazlar, adres aileleri ve sistem çağrıları üzerinde katmanlı kısıtlar uygular. DynamicUser geçici UID/GID oluşturur ve kalıcı kullanıcı yönetimini azaltır. ProtectSystem=strict dosya sistemini çoğunlukla salt okunur yaparken StateDirectory, CacheDirectory ve LogsDirectory gerekli yazılabilir alanları kontrollü üretir.
CapabilityBoundingSet servisin kazanabileceği yeteneklerin üst sınırını düşürür; AmbientCapabilities yalnız gerçekten gerekli capability'yi root olmayan sürece aktarır. NoNewPrivileges yeni setuid/file capability yükseltmesini engeller. SystemCallFilter ve RestrictAddressFamilies işlevi daraltabilir fakat uygulamanın kütüphane, DNS, logging ve JIT davranışı sürüme göre test edilmelidir.
Kurulum önce gözlem, sonra kademeli sıkılaştırma olarak yürütülmelidir. systemd-analyze security puanı bir karşılaştırma sinyalidir, tek başına güvenlik kanıtı değildir. Servis yalnızca beklenen dosyalara, socket'lere ve ağ ailelerine erişebilmeli; başarısız istekler journal ve audit kayıtlarıyla işlevsel testlere bağlanmalıdır.
- 1Servis bağımlılık ve erişim envanteri
- 2Drop-in ile kademeli sandbox
- 3İşlevsel ve negatif erişim testleri
- 4Security skoru ve journal doğrulaması
Tasarım parametreleri
- Yazılabilir yollar
- StateDirectory/RuntimeDirectory ile açıkça tanımlayın; geniş ReadWritePaths istisnalarından kaçının.
- Capability kümesi
- `capsh --print` veya gerçek hata kanıtıyla gereken en küçük capability listesini belirleyin.
- Adres aileleri
- AF_UNIX, AF_INET/AF_INET6 gereksinimini DNS, logging ve local socket'lerle birlikte test edin.
- Sistem çağrıları
- Hazır filtre gruplarını ürün sürümünde pilotlayın; JIT veya eBPF kullanan servisleri ayrıca değerlendirin.
Hesap ve uygulama örneği
HTTP servisi 8080 portunda çalışıyor, `/var/lib/acme-api` yazıyor ve journald'a logluyorsa root ya da CAP_NET_BIND_SERVICE gerekmez. DynamicUser=yes, StateDirectory=acme-api, ProtectSystem=strict ve AF_UNIX/AF_INET/AF_INET6 yeterli olabilir. Port 443'e doğrudan bind edecekse capability eklemek veya ön proxy kullanmak ayrı tasarım kararıdır.
Sıkılaştırma öncesi 6,2/10 exposure puanı, sonrası 2,1/10 görülebilir; ancak kabul testi API fonksiyonları, yeniden başlatma sonrası state, DNS, log ve kontrollü yasak dosya yazma denemesini de içermelidir. Puan düşüşü işlevsel kapsama ve saldırı yüzeyi kanıtıyla birlikte raporlanır.
Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.
sudo systemctl edit acme-api.service
# [Service]
# DynamicUser=yes
# StateDirectory=acme-api
# ProtectSystem=strict
# ProtectHome=yes
# NoNewPrivileges=yes
# PrivateTmp=yes
# CapabilityBoundingSet=
# RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
systemd-analyze security acme-api.service
systemd-analyze verify /etc/systemd/system/acme-api.service.d/override.conf
journalctl -u acme-api.service -bHata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Read-only file system | Servis ProtectSystem altında tanımlanmamış bir yola yazıyor olabilir. | Journal hata yolunu bulun; StateDirectory veya dar ReadWritePaths ile gereksinimi belgelendirin. |
| Operation not permitted | Capability, syscall veya namespace kısıtı gerçek işlevi engelliyor olabilir. | Audit/journal olayını ilgili direktifle eşleyip tek ayarı kontrollü gevşetin. |
| DynamicUser sonrası dosya sahipliği değişiyor | Kalıcı veri elle oluşturulmuş path'te ve dinamik UID'ye bağlı olabilir. | StateDirectory ile systemd sahiplik yönetimini kullanın; sabit UID varsayımını kaldırın. |
Kabul ve doğrulama kontrolleri
- Servisin dosya, socket, cihaz ve ağ erişim envanterini çıkarın.
- `systemd-analyze security` temel ve son skorunu kaydedin.
- Pozitif işlev testlerini yeniden başlatma sonrası çalıştırın.
- Yasak `/etc` yazma ve gereksiz ağ ailesi için negatif test yapın.
- Journal/audit hatalarını her kısıt değişikliğiyle eşleyin.
- Unit drop-in ve geri dönüş adımını sürüm kontrolünde saklayın.
İlgili kavramlar
Servis yaşam döngüsü ve bağımlılıklar
Çalışan bir process, hizmetin kullanıcıya doğru yanıt verdiğini kanıtlamaz. Başlangıç sırası, ağ veya veritabanı bağımlılığı, ortam değişkenleri, dosya erişimi ve sağlık kontrolü birlikte incelenir. Servis yeniden başlatma döngüsü bazen gerçek nedeni gizler. Exit code, son loglar ve kaynak sınırlarını karşılaştırın. Uygulama dışında systemd veya container yönetim katmanının neden yeniden başlatma yaptığını da kaydedin. Kontrollü restart sonrasında oturum, veri yazma ve bağımlı servislerin davranışını doğrulayın.
İzolasyon ile sanallaştırma ayrımı
Container ve sanal makine aynı izolasyon sınırını sunmaz. Containerlar host çekirdeğini paylaşırken sanal makineler konuk işletim sistemi çalıştırır. Rootless kullanım, namespace ve capability kısıtları riski azaltabilir; yapılandırma ve host güvenliği yine önemlidir. Image, çalışan container ve kalıcı volume ayrı yaşam döngülerine sahiptir. Image güncellemek veriyi yedeklemez. Testte process izinlerini, mountları, ağ erişimini ve kalıcı verinin yeniden oluşturma sonrasında korunmasını ayrı ayrı doğrulayın.
En az yetki ve görev ayrımı
En az yetki, bir görevin gerektirdiği izinlerin belirli kaynak ve süreyle sınırlandırılmasıdır. Herkese aynı yönetici rolünü vermek, erişim incelemesini ve olay araştırmasını zorlaştırır. Günlük kullanıcı hesabı ile ayrıcalıklı hesabı ayırın; servis hesaplarının etkileşimli kullanımını ve gereksiz ağ erişimini kısıtlayın. Yetki matrisi, kimliğin kaynağa hangi işlemle eriştiğini göstermelidir. Bir izin kaldırıldığında uygulamanın çalışmayı sürdürmesi de test kapsamına girer: gereksiz yetkiler bazen yalnız kontrollü azaltma sırasında ortaya çıkar.
Dosya sistemi ve depolama katmanları
Uygulama dizini, mount point, mantıksal disk ve fiziksel depolama aynı katman değildir. Boş alan kadar inode tükenmesi, read-only mount ve dosya sistemi hataları da yazmayı durdurabilir. Snapshot genellikle aynı depolama arızasını paylaşır ve bağımsız yedek sayılmaz. Mount seçenekleri ve kapasite genişletme yöntemi dosya sistemine göre değişir. İşletim sistemi yeniden açıldığında doğru depolamanın doğru dizine bağlandığını doğrulayın; mount edilmeyen dizine yazılan veri yanlış diski doldurabilir.
Dosya izinleri ve servis kimliği
Dosya erişimi kullanıcı/grup, izin bitleri, ACL ve güvenlik politikalarının birleşimine bağlıdır. Bir uygulamanın root olarak çalışması izin sorununu gizleyebilir; üretim için gerekçeli ve sınırlı servis kimliği tercih edilir. Dizin üzerinde arama/geçiş izni ile dosya okuma izni farklıdır. Paylaşım katmanında verilen izin, dosya sistemindeki kısıtı her zaman aşmaz. Hata araştırmasında uygulamanın gerçekten hangi kullanıcıyla çalıştığını, dizin zincirini ve ACL’leri inceleyin. İzinleri topluca açmak yerine gereken erişimi dar kapsamda test edin.
Telemetri ve zaman eşleştirmesi
Telemetri, sistemin ne yaptığını açıklayan log, metrik ve olay kayıtlarının bütünüdür. Log bir olayın ayrıntısını, metrik zaman içindeki davranışı, dağıtık iz ise isteğin bileşenler arasındaki yolunu gösterir. Saat farkları aynı olayı farklı zamanlarda olmuş gibi gösterebilir. Merkezi zaman senkronizasyonu, kaynak kimliği ve tutarlı saat dilimi kullanın. Alarm tasarımında yalnız eşik değil, ne kadar sürdüğü ve kullanıcıya etkisi de değerlendirilmelidir. Kayıtların kesildiği durum ayrıca izlenmeli; günlük kaydı bulunmaması, olay yaşanmadığı şeklinde yorumlanmamalıdır.
Birincil teknik dokümantasyon
Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.