En Az Yetki (Least Privilege) Prensibi Nedir?

Bir sunucuda çalışan her kullanıcı, her servis ve her uygulamaya "ne kadar yetki verelim?" sorusunun tek doğru cevabı vardır: işini yapabilmesi için gereken en az yetki, ne bir tık fazlası. En az yetki (least privilege) prensibi tam olarak bunu söyler. Kulağa fazla katı gelebilir ama arkasındaki mantık son derece pratiktir; çünkü verdiğiniz her fazladan izin, bir gün bir yerde ters gittiğinde saldırganın ya da hatalı bir komutun elindeki hasar potansiyelini büyütür. Bir web sunucusu neden tüm diski silme yetkisine sahip olsun? Bir yedekleme betiği neden veritabanındaki tabloları değiştirebilsin? Bir uygulama kullanıcısı neden başka müşterilerin dosyalarını okuyabilsin?

Bu rehberde en az yetki prensibini soyut bir güvenlik sloganı olmaktan çıkarıp, kendi sunucunuzda bugün uygulayabileceğiniz somut adımlara dönüştüreceğiz. root yerine sudo, her servis için ayrı sistem kullanıcısı, veritabanında yetkileri kısıtlanmış hesaplar, doğru dosya izinleri ve düzenli yetki gözden geçirmesi; hepsi aynı fikrin farklı katmanlardaki yansımasıdır. Kıdemli bir sistem yöneticisinin gözünden, hangi kararın neden alındığını ve bir ihlalin etkisini nasıl küçülttüğünü tek tek göreceksiniz.

En Az Yetki Prensibi Nedir?#

En az yetki prensibi, bir kimliğin (kullanıcı, servis, süreç, uygulama, hatta bir API anahtarı) yalnızca kendi görevini yerine getirebilmesi için kesinlikle gerekli olan izinlere sahip olması gerektiğini söyleyen bir güvenlik ilkesidir. "İhtiyaç olursa lazım olur" mantığıyla peşinen geniş yetki vermek bu prensibin tam tersidir ve pratikte en sık yapılan hatadır.

Prensibi anlamanın en kolay yolu, gündelik bir benzetmedir. Bir otelde temizlik görevlisine tüm odaların ana kartını vermezsiniz; ona yalnızca o gün temizleyeceği katın kartını verirsiniz. Muhasebeciye kasanın anahtarını verirsiniz ama sunucu odasının anahtarını değil. Bunu yapmanızın sebebi çalışanlarınıza güvenmemeniz değildir; kartlardan biri kaybolduğunda ya da kötü niyetli birinin eline geçtiğinde zararın yalnızca o katla sınırlı kalmasını istemenizdir. Sunucu güvenliği de birebir aynı mantıkla işler.

Burada kritik nokta şudur: en az yetki bir "yasak listesi" değil, bir "varsayılan" meselesidir. Yani her şeyi açıp sonra tehlikeli olanları tek tek kapatmaya çalışmazsınız (bu yaklaşım daima bir şeyi atlar); tam tersine her şey kapalı başlar, yalnızca gerçekten gereken kapıları tek tek açarsınız. Bu "varsayılan reddet" (default deny) tutumu, sunucu güvenliğinin temel taşlarından biridir ve güvenlik duvarından dosya izinlerine kadar her katmanda aynı biçimde karşınıza çıkar.

İhlalin Etki Alanını Nasıl Küçültür?#

Güvenlikte hiçbir önlem yüzde yüz koruma vaat edemez. Bir gün bir açık istismar edilebilir, bir parola sızabilir, bir bağımlılık kütüphanesine zararlı kod bulaşabilir. En az yetki prensibinin asıl gücü, saldırıyı önlemekten çok, saldırı gerçekleştiğinde saldırganın ulaşabileceği alanı daraltmaktır. Bu alana güvenlikte "patlama yarıçapı" (blast radius) denir.

Somut bir örnekle bakalım. Sunucunuzda çalışan bir PHP uygulamasında uzaktan kod çalıştırma (RCE) açığı bulunduğunu düşünün. Saldırgan bu açığı kullandığında, uygulamanın çalıştığı kullanıcının yetkileriyle komut çalıştırabilir hale gelir. İşte tam bu noktada iki senaryo tamamen ayrışır:

Aynı açık, aynı saldırgan, ama sonuç arasında uçurum var. Birinci senaryoda tek bir sitenin zafiyeti tüm sunucuyu, üzerindeki diğer müşterileri ve veritabanlarını riske atarken; ikinci senaryoda hasar tek bir dizine hapsolur. Saldırgan yatay olarak ilerleyemez, yetki yükseltemez, komşu hesaplara sıçrayamaz. En az yetki prensibini uygulamak, işte bu "sıçrama" yolunu peşinen kapatmaktır. Bir olayı tamamen engellemeseniz bile, onu felaketten önemsiz bir olaya indirgersiniz.

root Yerine Her Zaman sudo Kullanın#

En az yetki prensibinin en görünür ilk adımı, günlük işleri root hesabıyla yapmayı bırakmaktır. root, Linux'ta hiçbir sınırı olmayan süper kullanıcıdır; yanlış yazılmış tek bir komut tüm sistemi geri dönüşsüz silebilir ve root üzerinden gelen bir saldırı, daha ilk saniyede tam kontrolü teslim eder. Bunun yerine sınırlı yetkiye sahip normal bir kullanıcıyla çalışır, yalnızca gerektiğinde sudo ile geçici olarak yükselirsiniz.

Ayrı bir yönetici kullanıcı oluşturup ona sudo yetkisi vermek yalnızca birkaç komuttur:

adduser cloutr
usermod -aG sudo cloutr

sudo yaklaşımının iki büyük kazancı vardır. Birincisi, tüm gün yıkıcı yetkiyle dolaşmazsınız; yetki yalnızca o komut için, o an devreye girer. İkincisi ve çoğu zaman gözden kaçanı, her yetkili işlemin izinin /var/log/auth.log içinde kayıt altına alınmasıdır; yani "kim, ne zaman, hangi komutu çalıştırdı" sorusunun cevabı vardır. Paylaşılan root parolasında böyle bir hesap verilebilirlik yoktur.

En az yetkiyi bir adım öteye taşımak isterseniz, /etc/sudoers.d/ altında kullanıcıya yalnızca ihtiyaç duyduğu belirli komutları verebilirsiniz. Örneğin bir operatörün yalnızca web servisini yeniden başlatabilmesi ama başka hiçbir yönetici işlemi yapamaması gerekiyorsa:

# /etc/sudoers.d/web-operator
deploy  ALL=(ALL) NOPASSWD: /bin/systemctl restart nginx, /bin/systemctl reload nginx

Bu satır deploy kullanıcısına yalnızca Nginx'i yeniden başlatma/yeniden yükleme yetkisi verir; sudo su ya da başka bir komut çalıştırma kapısını açık bırakmaz. Herkese topluca ALL=(ALL) ALL vermek yerine bu tür daralttılmış kurallar yazmak, en az yetki prensibinin sudo katmanındaki karşılığıdır. Dosyayı düzenlerken sözdizimi hatası sunucudan kilitlenmenize yol açabileceği için mutlaka visudo aracını kullanın.

Her Servis İçin Ayrı Kullanıcı#

Sunucuda çalışan servisler (web sunucusu, veritabanı, uygulama işçileri, arka plan görevleri) asla root ile ve asla ortak tek bir kullanıcıyla çalıştırılmamalıdır. Her servisin kendi adına ayrılmış, oturum açması ve kabuk kullanması engellenmiş bir sistem kullanıcısı olmalıdır. Böylece bir servis ele geçirilirse saldırgan yalnızca o servisin dünyasında kalır; komşu servislere ve sistemin geri kalanına uzanamaz.

Modern Linux dağıtımlarında Nginx www-data, MySQL/MariaDB mysql, Redis redis gibi kendi servis kullanıcılarıyla gelir. Bu iyi bir başlangıçtır ama tek başına yeterli değildir; özellikle aynı sunucuda birden fazla site barındırıyorsanız hepsini tek www-data altında çalıştırmak, bir sitenin açığının diğerlerini de tehlikeye atması demektir. Her site ya da uygulama için ayrı bir sistem kullanıcısı açmak çok daha güvenlidir:

# Uygulamaya özel, kabuğu ve girişi kısıtlı bir sistem kullanıcısı
useradd --system --no-create-home --shell /usr/sbin/nologin appuser

--system bu hesabın bir insan değil bir servis hesabı olduğunu, --shell /usr/sbin/nologin ise bu kullanıcıyla kimsenin interaktif oturum açamayacağını belirtir. Bu iki bayrak, kullanıcının yalnızca kendi servisini çalıştırmak için var olmasını, başka hiçbir işe yaramamasını sağlar.

Bir uygulamayı systemd ile çalıştırırken hangi kullanıcı altında koştuğunu servis dosyasında açıkça belirtin ve systemd'nin izolasyon özelliklerinden faydalanın:

# /etc/systemd/system/uygulama.service
[Service]
User=appuser
Group=appuser
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
ReadWritePaths=/var/www/uygulama/storage
PrivateTmp=true

Buradaki NoNewPrivileges servisin çalışırken yetki yükseltmesini tamamen engeller; ProtectSystem=strict tüm dosya sistemini salt-okunur yaparken yalnızca ReadWritePaths ile izin verdiğiniz dizine yazmaya izin verir. Yani uygulama, kendi çalışması için gereken tek klasör dışında hiçbir yeri değiştiremez. Konteyner kullanıyorsanız aynı ilke geçerlidir; imajınızı asla root ile çalıştırmayın:

# docker-compose.yml
services:
  web:
    image: benim-uygulamam:latest
    user: "1000:1000"   # root (0) değil, yetkisiz bir kullanıcı
    read_only: true

Servisleri birbirinden ve sistemden yalıtmak, tek bir zafiyetin domino etkisiyle tüm sunucuya yayılmasını engelleyen en etkili yöntemlerden biridir. Bu izolasyon işini kendiniz kurmakla uğraşmak istemiyorsanız, sunucu yönetim hizmetimiz bu tür sertleştirmeleri sizin adınıza yapılandırır.

Veritabanında Kısıtlı Kullanıcı Yetkileri#

En sık ihmal edilen alan veritabanıdır. Pek çok uygulama, veritabanına root ya da tüm yetkilere (ALL PRIVILEGES) sahip bir hesapla bağlanır. Bu, en az yetki prensibinin en açık ihlallerinden biridir; çünkü uygulamada bir SQL enjeksiyonu açığı bulunduğunda saldırgan yalnızca veri okumakla kalmaz, tabloları silebilir, yeni yönetici hesapları oluşturabilir, hatta dosya sistemine erişmeye çalışabilir.

Doğru yaklaşım, her uygulama için yalnızca kendi veritabanına ve yalnızca gerçekten ihtiyaç duyduğu işlemlere yetkili ayrı bir kullanıcı tanımlamaktır. Tipik bir web uygulaması okuma, ekleme, güncelleme ve silme yapar; ama tablo yapısını değiştirme (DROP, ALTER) ya da başka kullanıcı yaratma yetkisine neredeyse hiç ihtiyaç duymaz:

-- Yalnızca kendi veritabanı, yalnızca gereken işlemler
CREATE USER 'uygulama'@'localhost' IDENTIFIED BY 'guclu-ve-benzersiz-parola';
GRANT SELECT, INSERT, UPDATE, DELETE ON uygulama_db.* TO 'uygulama'@'localhost';
FLUSH PRIVILEGES;

Bu hesapla giren bir saldırgan, en kötü ihtimalle tek bir veritabanının içeriğine dokunabilir; başka veritabanlarına geçemez, kullanıcı oluşturamaz, şemayı yok edemez. Yalnızca rapor üreten, veriyi hiç değiştirmeyen bir servis için ise yetkiyi daha da daraltıp yalnızca okumaya indirebilirsiniz:

GRANT SELECT ON uygulama_db.* TO 'rapor'@'localhost';

localhost kısıtlaması da bu tablonun önemli bir parçasıdır: kullanıcının yalnızca sunucunun kendi üzerinden bağlanabilmesini, dışarıdan doğrudan erişilememesini sağlar. Uygulama ve veritabanı aynı makinedeyse, veritabanı portunu (3306) dış dünyaya hiç açmayın. Bu prensibin ayrıntılı uygulamasını Linux dosya izinleri rehberimizdeki mantıkla birlikte düşünmek, hem dosya hem de veritabanı katmanında tutarlı bir güvenlik duruşu kurmanızı sağlar.

Dosya İzinleri ve En Az Yetki#

Dosya izinleri, en az yetki prensibinin işletim sistemi düzeyindeki en somut aracıdır. Linux'ta her dosya ve dizinin bir sahibi, bir grubu ve üç düzeyde (sahip, grup, diğerleri) okuma-yazma-çalıştırma izni vardır. Buradaki en yaygın ve en tehlikeli hata, "çalışmıyor, herhalde izin sorunudur" deyip her şeye 777 vermektir; bu, kapıyı ardına kadar açıp anahtarı da üstünde bırakmak demektir.

Doğru yaklaşım, her dosyaya işlevi için gereken en dar izni vermektir. Web dosyaları için tipik ve güvenli bir yapı şöyledir:

# Dizinler 755, dosyalar 644; sahip uygulama kullanıcısı
sudo chown -R appuser:appuser /var/www/uygulama
sudo find /var/www/uygulama -type d -exec chmod 755 {} \;
sudo find /var/www/uygulama -type f -exec chmod 644 {} \;

Burada dizinler 755 (sahip her şeyi yapabilir, diğerleri yalnızca okuyup içine girebilir), dosyalar 644 (sahip yazabilir, diğerleri yalnızca okuyabilir) olur. Kritik nokta şudur: web sunucusunun çalıştığı kullanıcının çoğu dosyaya yalnızca okuma yetkisi olması yeterlidir; yazma yetkisi sadece gerçekten yazması gereken dizinlerle (yükleme klasörü, önbellek, oturum) sınırlanmalıdır.

Özellikle yapılandırma dosyaları ve gizli bilgiler barındıran dosyalar için izinleri iyice daraltın. Veritabanı parolasını içeren bir .env dosyasının herkes tarafından okunabilir olması, düz metin bir sızıntı davetiyesidir:

# Sadece sahip okuyup yazabilsin, başka kimse göremesin
chmod 600 /var/www/uygulama/.env

Aşağıdaki tablo, en sık kullanılan izin değerlerinin ne anlama geldiğini ve en az yetki açısından nerede kullanılması gerektiğini özetler:

En az yetki mantığını dosya izinlerine uyguladığınızda temel soru hep aynıdır: "Bu dosyaya bu kullanıcının gerçekten yazması gerekiyor mu, yoksa okuması yeterli mi?" Cevap "okuması yeterli" ise yazma yetkisini asla vermeyin. İzin modelinin tüm ayrıntısı için Linux dosya izinleri rehberimize göz atabilirsiniz.

Rol Tabanlı Erişim ve Düzenli Yetki Gözden Geçirmesi#

Sunucu sayısı ve ekip büyüdükçe, her kullanıcıya tek tek izin atamak yönetilemez hale gelir ve hatalar kaçınılmaz olur. Bu noktada rol tabanlı erişim kontrolü (RBAC) devreye girer: izinleri kişilere değil rollere bağlarsınız, kişileri de rollere atarsınız. "Geliştirici", "operatör", "salt-okunur denetçi" gibi roller tanımlar, her role o işin gerektirdiği en az yetkiyi verirsiniz. Yeni bir ekip üyesi geldiğinde ona uygun rolü atamanız yeterli olur; izinleri sıfırdan kurmak zorunda kalmazsınız.

Linux tarafında bunun en pratik uygulaması gruplardır. Ortak bir kaynağa erişmesi gereken kullanıcıları bir grupta toplar, izni gruba verirsiniz:

groupadd web-editors
usermod -aG web-editors ahmet
usermod -aG web-editors mehmet
chgrp -R web-editors /var/www/uygulama
chmod -R 2775 /var/www/uygulama   # setgid: yeni dosyalar da gruba ait olur

Ancak roller ve izinler "kur ve unut" edilecek şeyler değildir. Zamanla izinler birikir: bir projede geçici olarak verilen yetki kaldırılmaz, işten ayrılan bir çalışanın hesabı kapatılmaz, artık kullanılmayan bir servisin kullanıcısı sistemde kalır. Bu birikime güvenlikte "yetki sürüklenmesi" (privilege creep) denir ve en az yetki prensibini sessizce çürütür. Bu yüzden düzenli yetki gözden geçirmesi şarttır. Belirli aralıklarla (örneğin üç ayda bir) şu soruları sorun ve gereksizleri temizleyin:

# sudo yetkisi olan kullanıcılar kim?
getent group sudo

# Sisteme oturum açabilen (kabuğu olan) hesaplar hangileri?
grep -vE '/(nologin|false)$' /etc/passwd

# Hangi veritabanı kullanıcısının hangi yetkileri var?
# (MySQL/MariaDB içinde)
SELECT user, host FROM mysql.user;

Her gözden geçirmede tek bir ilkeyi uygulayın: "Bu yetkinin hâlâ neden gerektiğini açıklayabiliyor muyum?" Açıklayamıyorsanız, o yetki muhtemelen kaldırılmalıdır. Kullanılmayan bir hesap, unutulmuş bir sudo kuralı ya da hâlâ açık duran eski bir API anahtarı, saldırganların en sevdiği giriş noktalarıdır. Bu disiplini bir alışkanlığa dönüştürmek, en az yetki prensibini tek seferlik bir kurulum olmaktan çıkarıp sürekli yaşayan bir güvenlik pratiğine dönüştürür.

Uygulama Kontrol Listesi#

Aşağıdaki kısa liste, en az yetki prensibini kendi sunucunuzda uygularken bir denetim listesi olarak kullanabileceğiniz maddeleri toplar. Her maddeyi "evet" diyene kadar geçmeyin:

Bu tablonun tamamı yeşil olduğunda, sunucunuzdaki tek bir zafiyetin tüm sisteme yayılma ihtimalini ciddi biçimde düşürmüş olursunuz. Unutmayın; amaç mükemmel bir güvenlik değil (öyle bir şey yoktur), her olası hatanın etkisini olabildiğince küçük bir alana hapsetmektir.

Sıkça Sorulan Sorular#

En az yetki prensibi ekibime güvenmediğim anlamına mı gelir?#

Hayır, prensip güven meselesi değil, risk yönetimi meselesidir. En dikkatli, en dürüst çalışan bile yanlış bir komut yazabilir, kimlik bilgileri çalınabilir ya da kullandığı bir aracın açığından etkilenebilir. En az yetki, bu kaçınılmaz kazaların etkisini sınırlar; kişilerin niyetiyle değil, olası hataların büyüklüğüyle ilgilenir. Aslında iyi tasarlanmış bir yetki sistemi, çalışanları "yanlışlıkla büyük hasar verme" korkusundan da kurtarır.

Her uygulama için ayrı kullanıcı açmak yönetimi zorlaştırmaz mı?#

İlk kurulumda birkaç dakika ek iş çıkarır ama uzun vadede işleri kolaylaştırır. Bir sorun çıktığında hangi servisin sorumlu olduğunu kullanıcı adından anında görürsünüz, günlükler daha okunabilir olur ve bir servisi durdurmak/kaldırmak diğerlerini hiç etkilemez. Otomasyon araçları (Ansible, betikler) kullanıcı oluşturmayı standart bir adıma dönüştürdüğünde bu maliyet neredeyse sıfıra iner; kazancı ise bir güvenlik olayı yaşadığınız gün katbekat geri döner.

Uygulamam veritabanında tablo oluşturması gereken bir kurulum adımı içeriyorsa ne yapmalıyım?#

Kurulum ve göç (migration) işlemleri için ayrı, daha yetkili bir veritabanı hesabı kullanabilir; günlük çalışma için ise kısıtlı hesaba dönebilirsiniz. Yani ALTER ve CREATE gibi şema yetkilerini yalnızca göç sırasında kullandığınız bir hesaba verir, uygulamanın normal çalışma zamanındaki bağlantısını SELECT/INSERT/UPDATE/DELETE ile sınırlı tutarsınız. Böylece güçlü yetki yalnızca gerektiği kısa an için var olur, sürekli açık kalmaz.

777 izni neden bu kadar tehlikeli?#

777 izni, dosyaya ya da dizine sunucudaki herkesin okuma, yazma ve çalıştırma yetkisi verir. Bu, web sunucusunun çalıştığı kullanıcı ele geçirilirse ya da aynı sunucuda başka bir hesap zafiyet içeriyorsa, o dosyanın değiştirilmesinin ya da zararlı kodla değiştirilmesinin önünü tamamen açar. Bir izin sorununu çözmek için 777 kullanmak, çoğu zaman gerçek sorunu (yanlış sahiplik) gizler ve yerine çok daha büyük bir güvenlik açığı koyar; doğru çözüm neredeyse her zaman doğru chown ve 644/755 izinleridir.

En az yetki prensibini yönetilen (managed) hosting kullanırken de düşünmem gerekir mi?#

Paylaşımlı hosting ya da tam yönetilen sunucularda işletim sistemi ve servis düzeyindeki izolasyonu büyük ölçüde sağlayıcı üstlenir; her müşteri zaten ayrı hesaplara ve kısıtlı yetkilere yerleştirilir. Ancak kendi uygulamanızın veritabanı kullanıcısı, dosya izinleri ve panel içi alt kullanıcı yetkileri hâlâ sizin sorumluluğunuzdadır. Root erişimine sahip bir VDS ya da sanal sunucu kullanıyorsanız, bu rehberdeki her katman baştan sona sizin elinizdedir ve tümünü uygulamanız gerekir.

Yetki gözden geçirmesini ne sıklıkla yapmalıyım?#

Küçük ve az değişen bir kurulumda üç ayda bir yeterlidir; ekibin ya da servis sayısının sık değiştiği ortamlarda ayda bir daha uygundur. Bunun dışında iki olayı her zaman tetikleyici olarak kabul edin: bir kişi ekipten ayrıldığında hesabını ve yetkilerini aynı gün kaldırın, yeni bir servis eklediğinizde de ona verdiğiniz izinleri en dar biçimde tanımlayın. Düzenli takvimli denetim ile olay bazlı temizliği birlikte yürütmek, yetki birikiminin önüne geçmenin en sağlam yoludur.

Kapanış#

En az yetki prensibi, tek bir araç ya da ayar değil; sunucunuzdaki her karara sinen bir düşünce alışkanlığıdır. "Bu kimliğe gerçekten bu kadar yetki gerekli mi?" sorusunu her seferinde sormak, zamanla sizi çok daha dayanıklı bir altyapıya götürür. root yerine sudo, ortak kullanıcı yerine servise özel hesaplar, ALL PRIVILEGES yerine kısıtlı veritabanı yetkileri, 777 yerine dar dosya izinleri ve düzenli yetki temizliği; bunların hepsi aynı ilkenin farklı yüzleridir ve bir araya geldiklerinde bir ihlalin tüm sistemi vurmasını neredeyse imkânsız hale getirirler.

Bu prensibi baştan sona kendi denetiminizde uygulamak istiyorsanız, root erişimi sunan güçlü bir altyapıya ihtiyacınız var. VDS sunucularımızı veya esnek sanal sunucu paketlerimizi inceleyerek işe başlayabilir, sertleştirme ve izolasyon adımlarını sizin adınıza kuralım isterseniz sunucu yönetim hizmetimize göz atabilirsiniz. Güvenlik yolculuğunuza devam etmek için sunucu güvenliği temelleri ve Linux dosya izinleri rehberlerimiz de yanınızda.