Least privilege ilkesi nedir; TR7 kullanıcı yönetiminde nasıl karşılanır?

Kısa cevap

Least privilege ilkesi, her kullanıcıya ve her hesaba yalnızca görevini yapmak için gereken en dar yetkinin verilmesidir (NIST · Least Privilege). Bir hesap ele geçirildiğinde ya da yanlışlıkla hatalı bir işlem yapıldığında zararın o hesabın yetkisiyle sınırlı kalmasını sağlar. TR7'nin yönetim kullanıcısı modeli bu ilkeye dayanır (Yetkilendirme ve Erişim Modeli): Device Users formundaki User Type kullanıcının erişebileceği alanları ve düzeyi belirler, yetkisi olmayan menüler gizlenir; Read-only User, Monitor User, Traffic User, WAF User ve Traffic+WAF User rollerinde User vServices ile kullanıcı belirli vService'lerle sınırlandırılır, Backend Service Permission ve Certificate Selection gibi alanlar ek izinleri ayrı ayrı açar. Add formunda User type varsayılan olarak Admin gelir ve Access CLI over WEB açıktır; bu yüzden her kullanıcı için göreve uygun en dar rol ve yalnızca gereken erişimler bilinçli olarak seçilir. Automatic User Creation açıkken LDAP, RADIUS ya da TACACS+ ile ilk girişte otomatik oluşturulan kullanıcılara ise varsayılan olarak Read-only user atanır.

TR7'de Nerede Kullanılır

Nerede	Alan / etiket	Ne için
Settings → User Management → Device Users	User Type	Göreve uygun en dar rolün seçilmesi
Aynı form	User vServices, Backend Service Permission, Certificate Management, Certificate Selection	Rolün kapsadığı vService'lerin daraltılması ve rolün içindeki ek izinlerin yalnızca gerektiğinde açılması
Aynı form	Access CLI over SSH (varsayılan kapalı), Access CLI over WEB (Add formunda varsayılan açık)	Komut satırı erişiminin yalnızca gerekene verilmesi
Settings → User Management → Device Users → User Management Settings	Automatic User Creation, Default User Type to Create (varsayılan Read-only user)	Harici kaynaktan ilk kez giren kullanıcının en düşük yetkiyle başlaması
Settings → System Logs → User Logs	User Logs	Verilen yetkilerin nasıl kullanıldığının izlenmesi

TR7'de Uygulanışı

• Yalnızca izleme yapacak kişiye Monitor User ya da Read-only User rolü verilir; gerekiyorsa User vServices ile görebileceği vService'ler sınırlanır (Yalnızca izleme yetkisi olan veya yalnızca belirli vService'leri yönetebilen kullanıcılar tanımlayabilir miyim?).
• Tek bir uygulamadan sorumlu kişiye Traffic User (WAF da gerekiyorsa Traffic+WAF User) verilir ve User vServices'te yalnızca o uygulamanın vService'leri seçilir; Backend Service Permission ve Certificate Selection yalnızca gerekiyorsa açılır (Bir kullanıcının yalnızca kendisine atanan vService'leri düzenlemesini, Kurum Servislerine ve sertifikalara dokunmamasını nasıl sağlarım?).
• Günlük işlerde Admin yerine göreve özel roller kullanılır; yönetim girişine Management Access'teki Two-factor Authentication (2FA) ile ikinci faktör eklenir.

Sık Karıştırılan Noktalar

• "Admin rolünü vermek daha pratiktir." Geniş yetki, hatalı bir işlemde ya da hesap ele geçirildiğinde etkilenen alanı büyütür; User Type görevle sınırlı seçilir.
• "Least privilege bir kez ayarlanır." Görevler değiştikçe roller ve kapsam alanları gözden geçirilir; ayrılan kişilerin hesapları kaldırılır.
• "Otomatik oluşturulan kullanıcılar yetkili gelir." Automatic User Creation ile oluşturulan kullanıcıya Default User Type to Create değeri atanır; değer değiştirilmediği sürece Read-only User'dır. Bu kullanıcılar Access CLI over WEB açık olarak oluşturulur; gerekmiyorsa kullanıcının düzenleme formunda kapatılır.

Dokümantasyonda nasıl yapılır

• Device Users · Yetkilendirme ve Erişim Modeli
• Device Users · Yetki / Kapsam Alanları
• Device Users · Automatic User Creation

İlgili sorular

• RBAC (Role-Based Access Control) nedir; TR7'de nasıl uygulanır?
• Authentication ile authorization arasındaki fark nedir?
• Bir kullanıcının yalnızca kendisine atanan vService'leri düzenlemesini, Kurum Servislerine ve sertifikalara dokunmamasını nasıl sağlarım?