sudo ve sudoers ile Yetkilendirme

Bir Linux sunucusunda yönetici işleri yapmanın en tehlikeli yolu, sürekli root olarak oturum açıp komutları o güçle çalıştırmaktır. root her şeyi yapabilir; hiçbir izin duvarı onu durduramaz. Bu, tek bir yazım hatasının (rm -rf /var yerine yanlışlıkla rm -rf / var) tüm sistemi silebileceği, ele geçirilen bir oturumun anında sınırsız yetki kazandığı ve kimin ne yaptığının kayıt altına alınamadığı bir çalışma biçimidir. İşte sudo (superuser do) tam olarak bu sorunu çözmek için vardır: sıradan bir kullanıcının, gerektiğinde ve yalnızca izin verilen komutlarda geçici olarak yükseltilmiş yetki almasını, üstelik her adımın kayda geçmesini sağlar.

Bu rehberde sudo'nun perde arkasında nasıl çalıştığını, kuralların yazıldığı sudoers dosyasını visudo ile neden ve nasıl güvenle düzenlemeniz gerektiğini, kullanıcı ile grup tabanlı yetkilendirmeyi, bir kullanıcıya yalnızca belirli komutları açmayı, parolasız (NOPASSWD) kullanımın nerede yeri olup nerede tehlike doğurduğunu ele alacağız. Ayrıca modern yönetimin standardı olan sudoers.d dizinini, tekrar eden kuralları sadeleştiren alias yapılarını ve tüm bu araçların hizmet ettiği asıl felsefeyi — en az yetki ilkesini — somut örneklerle inceleyeceğiz. Konuya girmeden önce, izinlerin temelini oluşturan Linux dosya izinleri yazımıza göz atmanız, buradaki örneklerin daha net oturmasını sağlayacaktır.

sudo Neden root Oturumundan Daha Güvenlidir?#

sudo ile doğrudan root olmak arasındaki fark, sadece bir kolaylık meselesi değil; bir güvenlik felsefesi meselesidir. Doğrudan root oturumu açtığınızda o pencerede attığınız her adım tam yetkiyle çalışır ve bu yetki, siz oturumu kapatana kadar sürer. sudo ise yetkiyi komut bazında, geçici olarak ve denetlenebilir biçimde verir. Bunun getirdiği üç somut kazanç vardır.

Birincisi hesap verebilirlik. sudo ile çalıştırılan her komut, hangi kullanıcının hangi dizinde neyi çalıştırdığı bilgisiyle birlikte sistem günlüğüne yazılır. Üç kişilik bir ekipte sunucuya kim sudo systemctl restart nginx dediğini journalctl veya /var/log/auth.log üzerinden geriye dönük görebilirsiniz — paylaşılan tek bir root parolasında bu izlenebilirlik tümüyle kaybolur.

İkincisi saldırı yüzeyinin daralması. Kişilerin kendi kullanıcı hesaplarıyla çalışması, root ile SSH girişini tamamen kapatmanıza olanak tanır (PermitRootLogin no). Böylece kaba kuvvet saldırıları evrensel olarak bilinen root kullanıcı adını değil, önce tahmin edilmesi gereken bir kullanıcı adını hedeflemek zorunda kalır. Üçüncüsü ise hata payının küçülmesi: sudo her komutta bilinçli bir "şimdi yönetici yetkisiyle çalışıyorum" anı yaratır, bu da körlemesine tehlikeli komut çalıştırma olasılığını azaltır. Bu ilkelerin genel bir çerçevesi için sunucu güvenliği temelleri yazımız bütünleyici bir okuma olacaktır.

sudo Nasıl Çalışır?#

sudo bir komut çalıştırdığınızda arka planda birkaç adım gerçekleşir. Önce sizi kimliğinizle tanır, ardından sudoers kural setine bakarak bu komutu bu hedef kullanıcı olarak çalıştırma yetkiniz olup olmadığını denetler. Yetkiniz varsa parolanızı ister (kendi parolanızı, root parolasını değil), doğrularsa komutu hedef kullanıcının — varsayılan olarak root'un — kimliğiyle çalıştırır.

# Tek bir komutu root olarak çalıştır
sudo systemctl restart nginx

# Başka bir kullanıcı kimliğiyle çalıştır (-u)
sudo -u www-data php /var/www/site/artisan queue:work

# root için etkileşimli bir kabuk aç (mümkünse kaçının)
sudo -i

Parolayı bir kez girdikten sonra sudo kısa bir süre (çoğu dağıtımda 15 dakika) sizi yeniden sormaz; bu süre, aynı terminalde arka arkaya birkaç komut çalıştırırken kolaylık sağlar. sudo -k komutuyla bu önbelleği hemen sıfırlayabilir, sudo -v ile de zaman aşımını tazeleyebilirsiniz. Bir kullanıcının hangi yetkilere sahip olduğunu görmek isterseniz en pratik komut şudur:

sudo -l

Bu komut, o kullanıcının çalıştırmasına izin verilen komutları, hangi kullanıcı olarak ve parola gerekip gerekmediğiyle birlikte listeler — bir yetkilendirmeyi denetlerken ilk başvuracağınız araçtır.

visudo ile sudoers Dosyasını Güvenle Düzenlemek#

Tüm kurallar /etc/sudoers dosyasında (ve /etc/sudoers.d/ dizinindeki parçalarda) tanımlanır. Bu dosyayı asla nano /etc/sudoers gibi doğrudan bir metin düzenleyiciyle açmayın. Bunun yerine her zaman visudo kullanın:

sudo visudo

visudo'nun kritik farkı şudur: dosyayı kaydetmeden önce söz dizimini denetler. sudoers dosyasında geçersiz bir satır bırakırsanız sudo tümüyle çalışmayı reddedebilir — ve kendinizi sudo yetkisinden mahrum bırakırsanız, artık hatayı düzeltmek için gereken yetkiye de erişemezsiniz. Bu, uzaktaki bir sunucuda başınıza gelebilecek en can sıkıcı durumlardan biridir. visudo, hatalı bir kaydı algıladığında sizi uyarır ve düzeltme, kaydetmeden çıkma ya da yine de kaydetme seçenekleri sunar:

>>> /etc/sudoers: syntax error near line 42 <<<
What now?
Options are:
  (e)dit sudoers file again
  e(x)it without saving changes to sudoers file
  (Q)uit and save changes to sudoers file (DANGER!)

Hata gördüğünüzde her zaman e ile düzenlemeye dönün; asla Q demeyin. visudo varsayılan olarak sistemin EDITOR düzenleyicisini kullanır; alışkın olduğunuz düzenleyiciyle açmak isterseniz sudo EDITOR=nano visudo diyebilirsiniz. Bir de altın kural: sudoers üzerinde çalışırken ikinci bir açık SSH oturumunu daima yedekte tutun. Böylece bir hata yaparsanız, halihazırda yetkili olan diğer oturumdan geri dönüp düzeltebilirsiniz.

sudoers Söz Dizimi: Kullanıcı ve Grup Tabanlı Kurallar#

sudoers dosyasındaki bir yetki satırı temelde şu yapıya sahiptir:

kullanıcı  makine = (çalışacağı_kullanıcı:grup)  komutlar

Alanları tek tek okuyalım. En yaygın "tam yetki" satırı şudur ve bir kullanıcıya her komutu çalıştırma izni verir:

# ahmet, bu makinede, herhangi bir kullanıcı olarak, her komutu çalıştırabilir
ahmet   ALL=(ALL:ALL) ALL

Buradaki ALL sözcükleri sırasıyla "her makine", "her hedef kullanıcı", "her hedef grup" ve "her komut" anlamına gelir. Tek kullanıcı yerine bir grubu yetkilendirmek çok daha ölçeklenebilir bir yaklaşımdır; grup adının önüne % işareti konur:

# 'sudo' grubundaki herkes tam yetkilidir (Debian/Ubuntu varsayılanı)
%sudo   ALL=(ALL:ALL) ALL

# 'wheel' grubundaki herkes tam yetkilidir (RHEL/AlmaLinux/Rocky varsayılanı)
%wheel  ALL=(ALL) ALL

Bu grup mantığı sayesinde yeni bir yöneticiye yetki vermek için sudoers dosyasına dokunmanıza bile gerek kalmaz; kullanıcıyı ilgili gruba eklemek yeterlidir:

# Debian/Ubuntu
sudo usermod -aG sudo yenikullanici

# RHEL tabanlı sistemler
sudo usermod -aG wheel yenikullanici

Kullanıcı bir sonraki oturumunda yetkisini kazanır. Dağıtımlar arasındaki bu grup farkını akılda tutmakta fayda var — hangi dağıtımı seçeceğinize dair genel bir bakış için sunucu için Linux dağıtımı seçimi yazımıza bakabilirsiniz. Aşağıdaki tablo alanların anlamını özetler:

Belirli Komutlara İzin Vermek#

sudoers'ın asıl gücü, "her şeye izin ver" satırlarından değil, dar kapsamlı yetkilendirmeden gelir. Diyelim ki deploy adlı bir kullanıcının yalnızca web sunucusunu yeniden başlatmasına ve günlükleri okumasına izin vermek, ama sistemin geri kalanına dokunamamasını istiyorsunuz. ALL yerine komutların tam yollarını yazarsınız:

# deploy yalnızca bu üç komutu root olarak çalıştırabilir
deploy  ALL=(ALL) /usr/bin/systemctl restart nginx, /usr/bin/systemctl reload nginx, /usr/bin/tail -f /var/log/nginx/error.log

Burada iki önemli ayrıntı var. Birincisi, komutları mutlak yollarıyla yazmanız gerekir (which systemctl ile yolu bulabilirsiniz); aksi halde kullanıcı PATH'ini değiştirip başka bir systemctl çalıştırarak kuralı atlatabilir. İkincisi, komuta argüman belirttiğinizde kullanıcı yalnızca o argümanı kullanabilir. Örneğin yukarıdaki kuralla deploy, sudo systemctl restart nginx diyebilir ama sudo systemctl restart mysql diyemez. Argüman verirken dikkatli olun — argümansız bir komut, o komuta ait tüm argümanları serbest bırakır:

# TEHLİKELİ: bu satır, restart dahil systemctl'in HER alt komutuna izin verir
deploy  ALL=(ALL) /usr/bin/systemctl

# GÜVENLİ: yalnızca belirtilen hizmete belirtilen eylem
deploy  ALL=(ALL) /usr/bin/systemctl restart nginx

Argümanları hiç istemiyorsanız komuttan sonra "" yazarak "argümansız çalıştırılabilir" kısıtı koyabilirsiniz. Kısıtlı komut yetkilendirirken sık gözden kaçan bir tuzak da kabuk erişimi sağlayan komutlardır: vi, less, tar, find gibi araçlar içlerinden komut çalıştırma özelliği taşıdığından, bunları sudo ile açmak dolaylı olarak tam yetki verebilir. Bir editörü sudo ile açmak yerine, dosyayı özel bir komuta yönlendiren daha dar yetkiler tasarlamak daha güvenlidir.

NOPASSWD: Parolasız sudo ve Riskleri#

Varsayılan olarak sudo her komutta (önbellek süresi dışında) parola ister. NOPASSWD etiketi bu istemi kaldırır ve komutu parolasız çalıştırılabilir kılar:

# jenkins kullanıcısı bu betiği parolasız çalıştırabilir
jenkins  ALL=(ALL) NOPASSWD: /opt/scripts/deploy.sh

Bunun meşru bir kullanım alanı vardır: etkileşimsiz otomasyon. Bir CI/CD işçisi, cron görevi ya da bir yapılandırma yönetim aracı komutu çalıştırırken karşısında parola isteyecek bir insan olmaz; bu durumda NOPASSWD bir zorunluluktur. Ancak riski açıkça anlamak gerekir: parolasız verilen yetki, o komutu çalıştırabilen herkesin — ya da o hesabı ele geçiren herhangi bir saldırganın — hiçbir engelle karşılaşmadan o gücü kullanabilmesi demektir.

Bu yüzden NOPASSWD'yi asla ALL ile birleştirmeyin. Aşağıdaki iki satır arasındaki fark, güvenli bir otomasyonla açık bir arka kapı arasındaki farktır:

# ÇOK TEHLİKELİ: hesap ele geçirilirse tüm sistem parolasız düşer
otomasyon  ALL=(ALL) NOPASSWD: ALL

# KABUL EDİLEBİLİR: yalnızca tek, denetlenmiş bir betik parolasız
otomasyon  ALL=(ALL) NOPASSWD: /opt/scripts/backup.sh ""

Parolasız çalıştırdığınız betiğin kendisinin de kilitli olması gerekir: betik dosyası yalnızca root tarafından yazılabilir olmalı (chmod 755, sahibi root), aksi halde onu çalıştırma yetkisi olan kullanıcı betiğin içeriğini değiştirerek dolaylı olarak tam yetki elde eder. NOPASSWD kullandığınız her yerde kendinize "bu hesap ele geçirilirse saldırgan bu komutla ne yapabilir?" diye sorun; cevap "sınırlı ve zararsız" değilse kapsamı daraltın.

sudoers.d Dizini ve Alias Kullanımı#

Modern sistem yönetiminde ana /etc/sudoers dosyasına elle satır eklemek yerine, kuralları /etc/sudoers.d/ dizini altında ayrı dosyalara koymak tercih edilir. Ana dosyanın sonundaki @includedir /etc/sudoers.d satırı, bu dizindeki tüm dosyaları otomatik olarak yükler. Bu yaklaşımın avantajı düzendir: her ekip ya da rol için ayrı bir dosya tutar, paket güncellemelerinin ana dosyayı ezme riskini ortadan kaldırır ve yapılandırmayı kolayca sürüm kontrolüne alırsınız.

Bu dizindeki dosyaları da düzenlerken visudo'nun denetim özelliğini -f bayrağıyla kullanın:

sudo visudo -f /etc/sudoers.d/deploy-ekibi

Dizin içindeki dosyaların adında nokta veya ~ bulunmamalıdır; sudo bunları görmezden gelir (bu aslında .rpmnew gibi artık dosyaların kazara yüklenmesini önleyen bir güvenlik önlemidir). Kural sayısı arttıkça tekrarları azaltmak için alias yapıları devreye girer. Dört tür alias vardır: kullanıcı (User_Alias), komut (Cmnd_Alias), makine (Host_Alias) ve hedef kullanıcı (Runas_Alias). En çok işinize yarayacak olanlar kullanıcı ve komut aliaslarıdır:

# Kullanıcı ve komut gruplarını bir kez tanımla
User_Alias  WEBADMIN = ahmet, mehmet, ayse
Cmnd_Alias  WEBSERVIS = /usr/bin/systemctl restart nginx, \
                        /usr/bin/systemctl reload nginx, \
                        /usr/bin/systemctl status nginx

# Sonra tek satırda kullan
WEBADMIN  ALL=(ALL) WEBSERVIS

Bu yapı, ileride bir kişiyi ekibe katmak istediğinizde tek yapmanız gerekenin WEBADMIN aliasına bir isim eklemek olması demektir — yetki kuralının kendisine hiç dokunmazsınız. Aynı şekilde ekibin yönetebileceği hizmetleri genişletmek için sadece WEBSERVIS komut listesine ekleme yaparsınız. Aliaslar, sudoers dosyanızı büyük altyapılarda okunabilir ve bakımı kolay tutmanın anahtarıdır.

En Az Yetki İlkesi ve Pratik Öneriler#

Buraya kadar anlattığımız her şey aslında tek bir ilkeye hizmet eder: en az yetki ilkesi (principle of least privilege). Bu ilke, her kullanıcıya ve sürece işini yapmak için gereken en küçük yetkiyi vermeyi, fazlasını değil, söyler. Pratikte bu, refleksle ALL=(ALL) ALL yazmak yerine "bu kişi gerçekten neyi çalıştırmalı?" sorusunu sormak demektir.

Somut bir örnek üzerinden düşünelim. Bir yedekleme betiği çalıştıran servis hesabına tüm sistemde tam yetki vermek yerine, yalnızca ilgili komutları açmak hem işi görür hem de olası bir sızıntının etkisini o komutlarla sınırlar:

# Yedekleme hesabına yalnızca gereken araçlar
Cmnd_Alias  YEDEK = /usr/bin/rsync, /bin/tar, /usr/bin/find /var/backups
backup-svc  ALL=(root) NOPASSWD: YEDEK

Bu yaklaşımı destekleyen birkaç somut alışkanlık şunlardır: kişileri değil rolleri düşünüp grup/alias tabanlı kurallar yazın; her sudo yetkisini periyodik olarak sudo -l ile gözden geçirin; kabuk açabilen komutlara (vi, less, env, find -exec) parolasız yetki vermekten kaçının; Defaults logfile=/var/log/sudo.log gibi bir satırla sudo etkinliğini ayrı bir günlüğe alın. Yetkilendirmeyi doğru kurgulasanız bile, sunucunuzun genel savunmasını WAF ve DDoS koruma gibi katmanlarla desteklemek, düzenli yedekleme almak bütünsel güvenliğin ayrılmaz parçalarıdır. Tüm bu yapılandırmayı kendiniz üstlenmek istemiyorsanız sunucu yönetimi hizmetimizle bu işi uzman ekibimize bırakabilirsiniz.

Sıkça Sorulan Sorular#

sudo ve su komutu arasındaki fark nedir?#

Her ikisi de yetki yükseltmeye yarar ama yaklaşımları farklıdır. su komutu sizi tümüyle başka bir kullanıcıya (genelde root) dönüştürür ve bunun için hedef kullanıcının parolasını ister; oturum kapanana kadar o kimlikle çalışırsınız. sudo ise komut bazında geçici yetki verir, sizin kendi parolanızı ister ve her işlemi kaydeder. Modern sistem yönetiminde denetlenebilirlik ve dar kapsam nedeniyle sudo tercih edilir.

sudoers dosyasını yanlışlıkla bozarsam ne olur ve nasıl kurtarırım?#

Eğer visudo kullandıysanız zaten kaydetmenize izin vermez, bu yüzden bu durum çoğunlukla dosyayı doğrudan düzenleyenlerin başına gelir. Bozulmuş bir sudoers ile sudo çalışmayı reddederse, halihazırda açık ve yetkili bir oturumunuz varsa oradan düzeltebilirsiniz. Böyle bir oturumunuz yoksa çözüm, sunucuyu kurtarma (recovery) moduyla ya da sağlayıcının konsolu üzerinden root olarak başlatıp visudo ile hatalı satırı düzeltmektir; bu yüzden düzenleme sırasında hep yedek bir oturum tutmak kritik önemdedir.

NOPASSWD kullanmak güvenli midir?#

Doğru kapsamla kullanıldığında güvenlidir, gelişigüzel kullanıldığında değil. NOPASSWD yalnızca tek ve iyi tanımlı bir komuta ya da yalnızca root tarafından yazılabilen bir betiğe verildiğinde makul bir risk taşır ve etkileşimsiz otomasyon için gereklidir. Ancak NOPASSWD: ALL yazmak, o hesabı ele geçiren herkese parolasız tam yetki vermek anlamına geldiğinden ciddi bir güvenlik açığıdır ve kaçınılması gerekir.

Bir kullanıcıya yalnızca tek bir servisi yeniden başlatma yetkisi nasıl veririm?#

visudo ile sudoers dosyasına, komutun tam yolunu ve argümanını belirten bir satır eklersiniz; örneğin deploy ALL=(ALL) /usr/bin/systemctl restart nginx satırı, deploy kullanıcısına yalnızca Nginx'i yeniden başlatma izni verir. Argümanı da yazdığınız için kullanıcı başka bir servise dokunamaz. Komutun tam yolunu which systemctl ile bulmayı ve mutlaka mutlak yol kullanmayı unutmayın.

sudo komutlarının kaydını nerede görebilirim?#

Dağıtıma göre değişmekle birlikte, Debian ve Ubuntu'da sudo etkinliği /var/log/auth.log, RHEL tabanlı sistemlerde ise /var/log/secure dosyasında tutulur. journalctl _COMM=sudo komutuyla da systemd günlüğünden filtreleyebilirsiniz. Daha temiz bir kayıt istiyorsanız sudoers içine Defaults logfile=/var/log/sudo.log satırı ekleyerek sudo işlemlerini ayrı bir dosyaya yönlendirebilirsiniz.

root ile SSH girişini kapatıp yalnızca sudo kullanmak mantıklı mı?#

Evet, bu güvenlik açısından önerilen bir uygulamadır. Kendi kullanıcınızı sudo/wheel grubuna ekledikten ve sudo erişiminizi doğruladıktan sonra, SSH yapılandırmasında PermitRootLogin no ayarını yapıp root ile doğrudan girişi kapatabilirsiniz. Böylece saldırganların hedeflediği evrensel root kullanıcı adı devre dışı kalır ve tüm yönetici işlemleri, izlenebilir kişisel hesaplar üzerinden sudo ile yapılır. Değişiklikten önce mutlaka sudo erişiminizin çalıştığından emin olun.

Kapanış#

sudo ve sudoers, bir Linux sunucusunda yetkiyi kontrollü, izlenebilir ve gerektiği kadar dağıtmanın standart yoludur. Doğru kurgulandığında hem ekibinizin işini rahatça yapmasını sağlar hem de tek bir hatanın ya da ele geçirilen bir hesabın tüm sistemi düşürmesini engeller. Özetle: her zaman visudo ile düzenleyin, kuralları grup ve alias tabanlı yazın, komutları tam yoluyla ve mümkün olduğunca dar tanımlayın, NOPASSWD'yi yalnızca kilitli betiklerle sınırlayın ve her yetkiyi en az yetki ilkesiyle sorgulayın.

Bu tür ince ayarları özgürce yapabilmeniz için sunucunuza tam root erişimine sahip olmanız gerekir; bunu paylaşımlı bir ortamda değil, ancak kendi sanal ya da fiziksel sunucunuzda elde edersiniz. Kendi sudoers politikanızı sıfırdan tasarlayabileceğiniz, tam kontrol sunan VDS ve sanal sunucu seçeneklerimizi inceleyebilir, kurulum ve sıkılaştırmayı bize bırakmak isterseniz sunucu yönetimi hizmetimizle ilgili detayları sunucu çözümleri sayfamızda bulabilirsiniz.