Root Yetkisi Vermeden Linux Sistem Yönetimi: Sudo ile En Az Yetki

Root erişimi olmadan Linux sistem yönetimi, sudo'yu doğru yapılandırıp en az yetki prensibine uyduğunuzda tamamen mümkün. Benim ortamımda root şifresini kimseye vermem ve root olarak direkt giriş yapılmasına izin vermem. Bunun yerine, belirli kullanıcılara sadece ihtiyaç duydukları komutları çalıştırma yetkisi veririm ve tüm bunları tam loglama ile yaparım. İşte ben nasıl yapıyorum.

Daha önce işletim sistemi seçimini karşılaştırırken (https://furkanikkan.com/urun/linux-mu-windows-server-mi-gercek-senaryolara-gore-dogru-os-secimi-39) dediğim gibi, Linux size izinler üzerinde ince taneli kontrol sunar — ama sadece bunu gerçekten kullanırsanız. Varsayılan sudo ALL=(ALL:ALL) ALL yetkisi kullanışlıdır ama güvenlik için berbattır.

Neden Direkt Root Girişini Devre Dışı Bırakmalısınız

İlk adım, kimsenin root olarak SSH ile giriş yapamadığından emin olmak. Bu, herkesi sudo üzerinden geçmeye zorlar, yani her yetkili işlem loglara gerçek bir kullanıcı adıyla düşer.

/etc/ssh/sshd_config dosyasını düzenleyin ve şunu ayarlayın:

PermitRootLogin no

Sonra SSH daemon'unu yeniden başlatın:

systemctl restart sshd

Artık her yönetimsel işlem bir kişiye izlenebilir, on kişinin kullandığı ve kimsenin sahiplenmediği paylaşımlı bir root hesabına değil.

Sudoers Yapılandırması: Doğru Yol

Gördüğüm en büyük hata, adminlerin /etc/sudoers dosyasını direkt düzenlemesi. Yapmayın. Tek bir sözdizimi hatası ve yetki yükseltme işlemlerinden tamamen kilitlenirsiniz. Her zaman visudo kullanın:

visudo -f /etc/sudoers.d/webops

/etc/sudoers.d/ içindeki dosyaları kullanmak işleri modüler tutar. Her takım veya uygulama için tek bir dosya atayabilirsiniz ve 200 satırlık bir yapılandırma içinde avlanmak yerine tek bir dosyayı silerek erişimi kaldırabilirsiniz.

İşte benim ortamımdan gerçek bir örnek. Web operasyon takımının nginx'i yeniden başlatması ve PHP-FPM'i reload etmesi gerekiyor, ama başka hiçbir şey:

Cmnd_Alias WEBOPS = /bin/systemctl restart nginx, /bin/systemctl reload nginx, /bin/systemctl restart php-fpm

%webops ALL=(ALL) WEBOPS

Artık o grup tam olarak şu üç komutu root yetkileriyle çalıştırabilir. Paket yükleyemezler, sudoers dosyasını düzenleyemezler veya başka hiçbir şeye dokunamazlar.

Pratik En Az Yetki Örnekleri

İşte en sık kullandığım kısıtlama desenleri:

Yedek operatörleri: Belirli yollara rsync ve tar izni verin, başka hiçbir şey
Veritabanı takımı: systemctl restart postgresql ve postgres kullanıcısı olarak psql izni verin, ama genel root değil
İzleme kullanıcısı: Belirli log dosyalarını okuma ve izlenen servislerde systemctl status çalıştırma izni verin
Deploy kullanıcısı: Uygulama servisini yeniden başlatma ve cache dizinini temizleme izni verin, paket yönetimi yok

Bir veritabanı admini örneği:

dbadmin ALL=(postgres) /usr/bin/psql, /bin/systemctl restart postgresql

(postgres) kısmına dikkat edin — o kullanıcı komutları postgres sistem kullanıcısı olarak çalıştırabilir, root olarak değil. Bu çok büyük bir fark. Birisi o hesabı ele geçirirse, veritabanı seviyesinde erişim elde eder, tam sistem kontrolü değil.

Sudo Loglama ve Denetim

Loglama olmadan en az yetki sadece bir öneridir. Sudo, Debian tabanlı sistemlerde /var/log/auth.log'a ve RHEL tabanlı sistemlerde /var/log/secure'a varsayılan olarak loglar. Kontrol edin:

grep sudo /var/log/auth.log | tail -20

Çalıştırılan her komutu, kimin çalıştırdığını ve nereden çalıştırdığını göreceksiniz. Birden fazla sunucu yönetiyorsanız, bu logları merkezi bir syslog sunucusuna veya SIEM'e gönderin. Benim kurulumumda, sudo loglarını merkezi bir rsyslog toplayıcısına iletiyorum böylece tüm makinelerde tek seferde arama yapabiliyorum.

Daha sıkı bir denetim istiyorsanız, sudoers dosyanıza şunu ekleyin:

Defaults log_input, log_output
Defaults iolog_dir=/var/log/sudo-io

Bu, her sudo oturumunun tam girdi ve çıktısını kaydeder. Detaylıdır ama sabah 3'te bir şey bozulduğunda, tam olarak ne olduğunu tekrar oynatabildiğiniz için minnettar olursunuz.

Kaçınılması Gereken Yaygın Hatalar

Bu hataların en az yetki kurulumlarını birden fazla kez bozduğunu gördüm:

Joker karakter komutları: Sudoers içinde /bin/systemctl * yazmak güvenli görünür ama kullanıcıların makineyi kapatmak dahil her servisi yeniden başlatmasına izin verir. Açık olun.
Shell escape'leri unutmak: Birinin vim veya less'i root olarak çalıştırmasına izin verirseniz, bu programların içinden bir shell açıp tam root erişimi alabilirler. NOEXEC kullanın veya interaktif araçlara yetki vermekten kaçının.
Grup kayması: Bir gruba erişim verirsiniz, insanlar takımdan ayrılır ve kimse onları gruptan çıkarmaz. Grup üyeliğini düzenli olarak denetleyin.
Her yerde NOPASSWD: Şifresiz sudo otomasyon için kullanışlıdır ama interaktif kullanıcılar için tehlikelidir. Sadece belirli servis hesapları için ayırın.

Otomasyon hesaplarını yönetmenin daha güvenli bir yolu:

deploy ALL=(ALL) NOPASSWD: /bin/systemctl restart myapp, /usr/local/bin/clear-cache.sh

İki komuta kilitli, şifre gerekmez, shell escape mümkün değil.

Sudoers Kurulumunuzu Test Etme

Oturumunuzu kapatmadan önce yeni yapılandırmayı test edin. Kısıtlı kullanıcı olarak sudo -l çalıştırın ve tam olarak ne yapabileceklerini görün:

sudo -l -U webops_user

Ve sudoers dosyanızın sözdizimini doğrulayın:

visudo -c

Bu bir parse hatası döndürürse, kimse ona güvenmeden önce düzeltin. Ben sudoers düzenlerken her zaman ayrı bir terminalde bir root shell açık tutarım, her ihtimale karşı.

Sonuç Yerine

Linux'ta en az yetki zor değildir ama disiplin gerektirir. Root girişini devre dışı bırakın, visudo kullanın, modüler sudoers dosyaları oluşturun, her şeyi loglayın ve güvenmeden önce test edin. Kesin bir sudoers kuralı yazmak için harcadığınız beş dakika, birinin ihtiyacı olmayan ALL yetkisi yüzünden root olarak rm -rf çalıştırdığı sabah 3'teki olaydan sizi kurtarır.

Benim ortamımda, her yeni sunucu üretime geçmeden önce bu muameleyi görür. İstisnasız.

Kapak görseli: personalgraphic.official · CC0 (Openverse / kamu malı) · https://www.flickr.com/photos/198895458@N04/53097628210