En Az Yetki İlkesi Nedir?

Zararın sınırını önceden çizmek

Güvenlikte “ihlal hiç yaşanmayacak” varsayımı gerçekçi değildir: bir parola sızar, bir eklentide açık bulunur, bir geliştiricinin dizüstü bilgisayarı çalınır. En az yetki ilkesi bu olayları engellemekten çok, gerçekleştiklerinde etki alanını (blast radius) daraltmayı hedefler. Yalnızca sipariş tablosunu okuyabilen bir raporlama hesabı ele geçirilse bile saldırgan müşteri parolalarına ya da ödeme ayarlarına ulaşamaz.

NIST'in sözlük tanımı fikri sade biçimde özetler: bir sistem, kullanıcılarının ve onlar adına çalışan süreçlerin erişim haklarını, verilen görev için gereken asgari düzeyle sınırlamalıdır. Tanımdaki “süreç” kelimesi önemlidir; ilke yalnızca insanlara değil, servis hesaplarına, zamanlanmış görevlere, CI/CD boru hatlarına ve yapay zekâ ajanlarına da uygulanır.

Tipik bir web projesinde nerelerde karşımıza çıkar?

• Veritabanı: Uygulama, tablo silme veya şema değiştirme hakkı olan yönetici kullanıcıyla değil, yalnızca ihtiyaç duyduğu tablolarda okuma ve yazma yapabilen ayrı bir kullanıcıyla bağlanır. Şema değişikliklerini yapan migration'lar başka bir hesapla çalışır.
• API anahtarları ve tokenlar: Bir API anahtarı mümkünse yalnızca gereken kapsamla (scope), tek bir ortam için ve sınırlı ömürle üretilir. Sadece ürün listesini okuyacak bir entegrasyona sipariş iptal etme yetkisi verilmez.
• CMS rolleri: İçerik giren bir editörün eklenti kurma veya kullanıcı yönetme yetkisi olmaz. WordPress'teki “Yönetici” rolü yalnızca siteyi gerçekten yöneten kişilere verilir.
• Sunucu süreçleri: Web sunucusu root olarak değil, kısıtlı bir sistem kullanıcısıyla çalışır; yazma izni yalnızca yükleme ve önbellek dizinlerinde bulunur.
• Bulut ve dağıtım: Deploy işlemini yapan servis hesabı yalnızca ilgili kaynaklara erişir; faturalama veya kimlik yönetimi yetkisi taşımaz.

Örnek: veritabanında rol ayrımı

-- Uygulamanın günlük çalışması için
CREATE ROLE app_rw LOGIN PASSWORD '...';
GRANT SELECT, INSERT, UPDATE ON orders, order_items TO app_rw;
GRANT SELECT ON products TO app_rw;

-- Raporlama aracı yalnızca okur
CREATE ROLE reporting_ro LOGIN PASSWORD '...';
GRANT SELECT ON orders, products TO reporting_ro;

Bu kurguda raporlama aracının bağlantı bilgileri sızsa bile veri değiştirilemez; uygulama hesabı ele geçirilse bile tablo silinemez ve yetki verilmemiş tablolar okunamaz. Parolaların kodun içine yazılmaması ise ayrı bir disiplin olan gizli bilgi yönetiminin konusudur.

Yetki birikmesi: ilkenin zamanla aşınması

Yetkiler kolayca eklenir ama nadiren geri alınır. Acil bir iş için verilen yönetici hakkı aylarca kalır, projeden ayrılan ajansın hesabı açık unutulur, test için oluşturulan geniş kapsamlı token canlı ortamda kullanılmaya başlanır. Bu birikmeye “privilege creep” denir ve en az yetki ilkesinin pratikteki en yaygın bozulma biçimidir. Önlemek için:

• Erişimler belirli aralıklarla gözden geçirilir; kullanılmayan hesaplar ve anahtarlar kapatılır.
• Kalıcı yönetici hakkı yerine, ihtiyaç anında verilen ve süresi dolunca kendiliğinden düşen geçici yetki (just-in-time access) tercih edilir.
• Kimin neye ne zaman eriştiği log kayıtlarıyla izlenebilir tutulur; böylece bir olay anında hangi hesabın neye dokunabildiği hızla anlaşılır.

Sık karıştırılan noktalar

Kimlik doğrulama ile yetkilendirme aynı şey değildir. Kimlik doğrulama “sen kimsin?” sorusunu, yetkilendirme ise “neye erişebilirsin?” sorusunu yanıtlar. En az yetki ilkesi ikinci sorunun cevabını olabildiğince dar tutmakla ilgilidir; güçlü parola veya çok faktörlü doğrulama tek başına bu ilkeyi sağlamaz.

“Herkese yönetici verelim, işler hızlansın.” Kısa vadede sürtünmeyi azaltır, ancak her hesabı tam yetkili bir saldırı noktasına çevirir. İlkeyi uygulamanın maliyeti çoğunlukla başlangıçta biraz daha dikkatli bir rol tasarımıdır; uygulamamanın maliyeti ise bir güvenlik olayı sırasında ortaya çıkar.