NTFS Permission Tasarımı: AGDLP Modeli ile Kurumsal Yetkilendirme Rehberi
Kurumsal ortamlarda NTFS permission tasarımı, dosya sunucularının güvenli, sürdürülebilir ve yönetilebilir şekilde çalışması için kritik bir bileşendir. Yanlış yapılandırılmış izinler; veri sızıntısına, yetki karmaşasına, hatalı erişimlere ve operasyonel zorluklara neden olabilir.
Özellikle büyük yapılarda kullanıcı bazlı yetki vermek yerine, grup tabanlı bir model kullanmak çok daha sağlıklı sonuç üretir. Bu noktada AGDLP modeli, Active Directory tabanlı ortamlarda en çok tercih edilen kurumsal yetkilendirme yaklaşımıdır. Bu rehberde NTFS permission tasarımı, share ve NTFS izin farkı, AGDLP modeli ve en iyi uygulamalar adım adım ele alınmaktadır.
NTFS Permission Nedir?

NTFS permission, Windows işletim sistemlerinde dosya ve klasörlere erişim yetkilerini belirleyen güvenlik mekanizmasıdır. Bu yapı sayesinde bir kullanıcının veya grubun ilgili kaynağa hangi seviyede erişeceği tanımlanabilir.
Temel izin türleri şunlardır:
- Read: Dosya ve klasörleri görüntüleme
- Write: Yeni içerik oluşturma veya veri yazma
- Modify: Okuma, yazma, değiştirme ve silme
- Full Control: Tüm işlemler ve izin yönetimi
NTFS izinleri kullanıcı veya grup bazlı uygulanabilir. Ancak kurumsal yapılarda önerilen yaklaşım, doğrudan kullanıcıya yetki vermek yerine grup tabanlı yetkilendirme modelini kullanmaktır.
Daha fazla teknik detay için Microsoft’un resmi dokümantasyonuna göz atabilirsiniz:
NTFS permissions documentation.
Share ve NTFS Permission Farkı
Windows File Server ortamlarında iki temel yetkilendirme katmanı bulunur: Share Permission ve NTFS Permission. Bu iki yapı birbirini tamamlar ancak görevleri farklıdır.
Share Permission
Share permission, ağ üzerinden paylaşıma erişim seviyesini belirler. Kullanıcı paylaşıma network üzerinden bağlandığında ilk olarak bu katman devreye girer.
NTFS Permission
NTFS permission ise dosya ve klasör seviyesinde daha detaylı erişim kontrolü sağlar. Asıl güvenlik ve yetkilendirme yönetimi çoğu kurumsal ortamda burada yapılır.
En yaygın ve doğru yaklaşım şu şekildedir:
- Share permission: Geniş ve sade yapı
- NTFS permission: Detaylı ve kontrollü yetkilendirme
Örnek yapı:
Share Permission
Domain Users → Change
Bu modelde gerçek erişim kontrolü NTFS tarafında yapılır. Böylece yönetim sadeleşir ve hata riski azalır.
AGDLP Modeli Nedir?
AGDLP modeli, Microsoft tabanlı ortamlarda önerilen kurumsal yetkilendirme yaklaşımıdır. Açılımı şu şekildedir:
- A: Accounts
- G: Global Groups
- DL: Domain Local Groups
- P: Permissions
Bu modelin mantığı şudur: Kullanıcı doğrudan klasöre yetki almaz. Önce bir global gruba üye olur, bu global grup ilgili domain local gruba bağlanır ve izinler domain local grup üzerinden kaynağa verilir.
AGDLP Modelinin Çalışma Mantığı
Kullanıcı → Global Group → Domain Local Group → NTFS Permission
Örnek senaryo:
Ahmet
↓
GG_Muhasebe
↓
DL_Muhasebe_Modify
↓
NTFS Modify
Bu yapı sayesinde yetkiler kullanıcı bazlı değil, grup bazlı yönetilir. Bu da özellikle büyük yapılarda ciddi kolaylık sağlar.
NTFS Permission Tasarımında Neden AGDLP Kullanılmalı?
NTFS permission tasarımı yapılırken AGDLP modelinin tercih edilmesinin temel nedeni yönetilebilirlik ve sürdürülebilirliktir. Kullanıcı sayısı arttıkça doğrudan kullanıcı bazlı izin yapıları hızla karmaşık hale gelir.
1. Yönetilebilirlik
Kullanıcı işten ayrıldığında, departman değiştirdiğinde veya yeni biri eklendiğinde sadece grup üyeliği güncellenir. Klasör izinlerine tek tek müdahale edilmez.
2. Ölçeklenebilirlik
Büyük organizasyonlarda yüzlerce klasör ve binlerce kullanıcı olabilir. AGDLP modeli bu yapıyı merkezi ve düzenli biçimde yönetmeyi kolaylaştırır.
3. Güvenlik
Least privilege yani minimum yetki prensibinin uygulanmasını kolaylaştırır. Böylece kullanıcı yalnızca ihtiyaç duyduğu kaynağa erişir.
4. Denetlenebilirlik
Yetki yapısının grup bazlı olması audit, raporlama ve erişim incelemelerinde büyük avantaj sağlar.
Kurumsal NTFS Permission Tasarım Örneği
Kurumsal bir file server yapısında örnek klasör mimarisi aşağıdaki gibi olabilir:
FileServer
├─ Finance
├─ HR
├─ Projects
Her klasör için ihtiyaçlara göre okuma ve değiştirme grupları oluşturulabilir:
DL_Finance_Read
DL_Finance_Modify
DL_HR_Read
DL_HR_Modify
DL_Projects_Read
DL_Projects_Modify
Bu gruplara NTFS izinleri atanır. Kullanıcılar ise doğrudan bu gruplara değil, ilgili global gruplara dahil edilir. Örnek:
Kullanıcılar → GG_Finance_Users
GG_Finance_Users → DL_Finance_Modify
DL_Finance_Modify → Finance klasörü üzerinde Modify yetkisi
Bu tasarım uzun vadede çok daha temiz bir yapı oluşturur.
NTFS Permission Best Practices
Kurumsal ortamlarda NTFS yetkilendirme best practice yaklaşımı için aşağıdaki kurallar önerilir:
- Kullanıcılara doğrudan yetki verilmemeli
- Yetkiler mümkün olduğunca grup üzerinden atanmalı
- Full Control yalnızca gerçekten gerekli hesaplara verilmeli
- Inheritance yapısı dikkatli planlanmalı
- Paylaşım ve NTFS izinleri karıştırılmamalı
- Departman bazlı ve rol bazlı grup isimlendirme standardı oluşturulmalı
- Audit log mekanizması aktif tutulmalı
- Düzenli yetki kontrolü yapılmalı
En Sık Yapılan Hatalar
- Everyone veya Authenticated Users grubuna gereğinden fazla yetki vermek
- Doğrudan kullanıcı hesabına Modify veya Full Control vermek
- Aynı klasörde hem karmaşık share hem karmaşık NTFS izinleri kullanmak
- Departman değişikliklerinde eski grup üyeliklerini temizlememek
Inheritance Yönetimi Neden Önemlidir?
NTFS izinlerinde inheritance, üst klasörde tanımlanan izinlerin alt klasörlere otomatik aktarılması anlamına gelir. Bu mekanizma doğru kullanıldığında yönetimi kolaylaştırır; yanlış kullanıldığında ise erişim hatalarına yol açabilir.
Özellikle hassas veri içeren klasörlerde inheritance durumu dikkatle kontrol edilmelidir. Her alt klasörün ayrı bir güvenlik ihtiyacı varsa, kalıtım yapısı bilinçli şekilde düzenlenmelidir.
PowerShell ile NTFS Permission Denetleme
Yetki kontrolü için PowerShell kullanmak oldukça faydalıdır. Aşağıdaki komut, ilgili klasör üzerindeki izinleri görüntüler:
Get-Acl "D:\Finance"
Bu komut ile klasöre atanmış erişim kuralları incelenebilir. Düzenli denetim yapmak, hatalı veya gereksiz izinlerin erken fark edilmesini sağlar.
PowerShell içeriklerine ilgi duyuyorsanız, benzer yönetim senaryoları için diğer sistem yönetimi yazılarıma da göz atabilirsiniz.
Gerçek Hayat Senaryosu
Bir kurumda kullanıcılar doğrudan klasörlere yetkilendirilmişti. Başlangıçta bu yöntem kolay görünse de kullanıcı sayısı arttıkça izin yapısı kontrol edilemez hale geldi. Kimin hangi klasöre neden yetkili olduğu net biçimde takip edilemedi.
Daha sonra AGDLP modeline geçildi ve yapı yeniden tasarlandı. Bu geçiş sonrasında:
- Yetki yönetimi sadeleşti
- Hatalı erişimler azaldı
- Departman geçişleri daha hızlı yönetildi
- Denetim süreçleri kolaylaştı
Bu örnek, doğru NTFS permission tasarımı yapılmadığında oluşabilecek operasyonel yükü net biçimde göstermektedir.
Sonuç
NTFS permission tasarımı, Windows File Server yönetiminin en kritik parçalarından biridir. Güvenli, sürdürülebilir ve yönetilebilir bir yapı kurmak için kullanıcı bazlı değil, grup tabanlı bir yaklaşım benimsenmelidir.
AGDLP modeli, Active Directory ortamlarında bu ihtiyacı karşılayan en doğru yapılardan biridir. Share ve NTFS izinlerinin doğru ayrıştırılması, grup isimlendirme standardı, inheritance kontrolü ve düzenli denetim süreçleri ile çok daha profesyonel bir permission mimarisi kurulabilir.
Bu konuda daha geniş bir güvenlik bakışı için File Server güvenliğini güçlendirmek için hazırladığım File Server Hardening makalesi ile bu içeriği birlikte değerlendirmeniz faydalı olacaktır.
Sık Sorulan Sorular
NTFS permission doğrudan kullanıcıya verilir mi?
Kurumsal ortamlarda bu yaklaşım önerilmez. Yetkilerin grup üzerinden verilmesi daha güvenli ve daha yönetilebilir bir model sunar.
AGDLP modeli neden kullanılır?
AGDLP modeli, yetkilendirme yapısını standartlaştırmak, erişim yönetimini kolaylaştırmak ve güvenliği artırmak için kullanılır.
NTFS ve Share permission hangisi daha önemlidir?
Detaylı erişim kontrolü çoğunlukla NTFS permission üzerinden yapılır. Share permission ise ağ erişim katmanını kontrol eder.
Full Control yetkisi kimlere verilmelidir?
Full Control yalnızca gerçekten ihtiyaç duyan yönetici hesaplara veya özel servis senaryolarına verilmelidir. Son kullanıcılar için genellikle gerekli değildir.


