NTFS İzinleri (Security Permissions), Inheritance ve Sahiplik

NTFS (New Technology File System) izinleri, Windows'ta dosya ve klasör düzeyinde erişimi belirleyen güvenlik modelidir. Bir klasörü açmak, dosya oluşturmak, içeriği değiştirmek ya da silmek istediğimde Windows bu talebi hedef nesnenin üzerindeki izin listesine göre değerlendirir ve izin verir ya da reddeder. Network üzerinden gelen erişimde bu karara Share izinleri de katılır. Nesnenin Owner'ı ve SeBackupPrivilege, SeRestorePrivilege, SeTakeOwnershipPrivilege gibi User Rights ayrıcalıkları da izin listesinin dışında kalan haklar sağlar.

Sahada karşılaştığım izin sorunlarının çoğu, izin listesinde görünenle kullanıcının gerçekte yapabildiği arasındaki farktan doğuyor. Erişim verildiği halde işlem yapamayan bir kullanıcının arkasından çoğu zaman üye olduğu bir grup üzerinden gelen Deny kaydı çıkıyor. Erişim verilmediği düşünülen bir kullanıcının içeriğe ulaşabilmesi ise genellikle dolaylı grup üyelikleri, Nested Group yapıları veya üst klasörden gelen Inheritance (miras) ile açıklanıyor. Bu davranışları okuyabilmek için izinlerin hangi parçalardan oluştuğunu ve Windows'un erişim kararını hangi sırayla verdiğini bilmek gerekiyor.

Bu makalede önce erişim kararının arkasındaki mekanizmayı, ardından temel ve gelişmiş izinleri tek tek anlatıyorum. Sonrasında Share ve NTFS izinlerinin birlikte nasıl değerlendirildiğini bir File Server üzerinde uygulamalı olarak gösteriyor, Special Permissions, Inheritance ve Ownership konularıyla devam ediyorum. File Server rolünün kurulumu ve paylaşım oluşturmanın ayrıntıları kapsam dışında. Anlattığım izin modeli Windows Server ve Windows Client sürümlerinde aynı şekilde çalışır.

1- NTFS Erişim Denetimi Nasıl Çalışır?

Her NTFS nesnesi bir Security Descriptor taşır. Erişim kararı, bu Security Descriptor ile isteği yapan kullanıcının Access Token'ı karşılaştırılarak verilir. Karşılaştırmayı Windows çekirdeğinde çalışan Security Reference Monitor (SRM) bileşeni yapar ve bu işleme Access Check denir. Kullanıcı bir dosyayı açmak istediğinde hangi erişimi istediğini (okuma, yazma, silme gibi) belirtir, SRM de bu istenen erişimin tamamının verilip verilemeyeceğine bakar.

Security Descriptor, Owner, DACL ve SACL

Security Descriptor dört bileşen taşır: Owner, Primary Group, DACL ve SACL. Primary Group, Windows dosya erişim denetiminde rol oynamaz. Erişim kararında belirleyici olan Owner ve DACL'dir, SACL ise erişim vermez, denetim kaydını tanımlar. Owner, nesnenin sahibidir ve ACL'de hiçbir izni olmasa bile nesnenin izinlerini okuyup değiştirebilir. DACL (Discretionary Access Control List), kimin hangi erişimi alacağını veya hangi erişimin reddedileceğini belirleyen listedir, Security sekmesinde gördüğüm izinler bu listedir. SACL (System Access Control List) ise erişim vermez, hangi erişim denemelerinin Security Log'a yazılacağını belirler.

DACL'deki her satır bir ACE (Access Control Entry)'dir. Her ACE bir SID, Allow veya Deny türü, verilen ya da reddedilen hakları tutan bir Access Mask ve ACE'nin alt nesnelere nasıl ineceğini belirleyen Inheritance bayraklarını içerir. Nesnenin üzerinde doğrudan tanımlanan ACE'ler Explicit, üst klasörden gelenler Inherited olarak işaretlenir. DACL'de kullanıcıyla eşleşen hiçbir ACE yoksa erişim reddedilir.

Access Token ve Grup Üyelikleri

Kullanıcı oturum açtığında Windows bu kullanıcı için bir Access Token oluşturur. Token; kullanıcının Security Identifier (SID)'ini, Nested Group'lar dahil üye olduğu tüm grupların SID'lerini, Everyone ve Authenticated Users gibi yerleşik grupların SID'lerini ve kullanıcıya atanmış ayrıcalıkları içerir. Access Check sırasında SRM bu SID'lerin tamamını DACL'deki ACE'lerle karşılaştırır. Kullanıcıya doğrudan verilmiş gibi görünen bir iznin aslında bir grup üyeliğinden gelebilmesinin nedeni budur.

Network üzerinden erişimde istemcideki Token kullanıcının kendi oturumunda kalır. File Server ise SMB oturumu kurulurken yapılan kimlik doğrulamanın sonucunda, erişim denetiminde kullanacağı ayrı bir Token oluşturur. File Server'ın bulunduğu Domain'deki Domain Local grup üyelikleri de bu Token'da yer alır.

ACE Değerlendirme Sırası ve Deny Önceliği

Windows'un ACL düzenleyicisi ACE'leri belirli bir sırada tutar. Explicit ACE'ler her zaman Inherited ACE'lerden önce gelir. Her grup içinde Deny, Allow'dan önce yer alır. Inherited ACE'ler de en yakın üst klasörden başlayarak sıralanır.

Explicit ACE'ler
  1. Deny
  2. Allow
Inherited ACE'ler (bir üst klasörden)
  3. Deny
  4. Allow
Inherited ACE'ler (iki üst klasörden)
  5. Deny
  6. Allow
  ...

SRM ACE'leri bu sırayla okur ve yalnızca Token'daki SID'lerle eşleşenleri işler. Allow ACE'lerindeki haklar birikir. Bir Deny ACE'si, istenen haklardan henüz verilmemiş olan birini reddediyorsa erişim reddedilir. İstenen hakların tamamı verildiğinde değerlendirme biter.

Bu sıralamanın sahada üç sonucu var. Kullanıcının kendi izinleri ile gruplarından gelen izinler toplanır. Explicit Deny en güçlü kayıttır. Nesneye doğrudan verilmiş bir Explicit Allow ise üst klasörden miras gelen Deny'dan önce okunduğu için onu geçersiz kılar, aynı şekilde yakın üst klasörden gelen bir Allow da daha uzaktan gelen bir Deny'dan önce değerlendirilir.

2- Temel İzinler (Basic Permissions)

Temel İzinler (Basic Permissions), Security sekmesinde gördüğüm altı onay kutusudur. Her biri, bir grup gelişmiş iznin hazır bir paketi gibi çalışır. Örneğin bir kullanıcıya Modify verdiğimde, oluşan ACE'nin Access Mask'ına Modify'ın kapsadığı gelişmiş izinlerin tamamı yazılır.

İzin verirken ihtiyacı karşılayan en dar temel izni seçiyorum. Least Privilege (en az ayrıcalık) prensibi burada somut olarak şu anlama geliyor: içeriği yalnızca okuyacak bir gruba Modify vermek, o grubun her üyesine silme hakkı da vermek demektir. Hiçbir temel izin ihtiyaca tam uymuyorsa gelişmiş izinlere iniyorum.

✅ Read

Read, bir klasörün içeriğini listeleme, dosya içeriğini okuma ve dosya ya da klasörün Attribute'larını ve izinlerini görüntüleme hakkı verir. Bu izinle kullanıcı klasörde hangi dosya ve alt klasörlerin bulunduğunu görebilir, dosyaları açıp okuyabilir, ancak hiçbir değişiklik yapamaz.

Read; List Folder / Read Data, Read Attributes, Read Extended Attributes ve Read Permissions gelişmiş izinlerini kapsar.

✅ List Folder Contents

List Folder Contents yalnızca klasörlerde bulunur, dosyalarda bu seçenek görünmez. Kapsadığı gelişmiş izinler Read and Execute ile aynıdır: Traverse Folder / Execute File, List Folder / Read Data, Read Attributes, Read Extended Attributes ve Read Permissions.

İki izin arasındaki tek fark Inheritance kapsamıdır. List Folder Contents yalnızca klasöre ve alt klasörlere uygulanır, dosyalara inmez. Bu nedenle kullanıcı klasör yapısında gezinip içeriği listeleyebilir, ancak dosyaları açıp okuyabilmesi için dosyalara inen ayrı bir izin gerekir.

✅ Read and Execute

Read and Execute, Read'in sağladığı haklara ek olarak çalıştırılabilir dosyaları başlatma ve klasörler arasında geçiş yapma hakkı verir. Execute hakkı, .exe ve .dll gibi işletim sistemi tarafından doğrudan yüklenen dosyalar için anlamlıdır. .bat ve .ps1 gibi Script'ler ise cmd.exe veya PowerShell tarafından okunarak çalıştırıldığı için bunlarda belirleyici olan okuma hakkıdır.

Read and Execute; Traverse Folder / Execute File, List Folder / Read Data, Read Attributes, Read Extended Attributes ve Read Permissions gelişmiş izinlerini kapsar. Yazma veya silme için ek izin gerekir.

✅ Write

Write, bir klasöre yeni dosya ve klasör oluşturma, dosyaların içeriğine yazma ve Attribute'ları değiştirme hakkı verir. Kullanıcı başka bir dizinden klasöre içerik kopyalayabilir. Write, Delete hakkı içermediği için dosya veya klasör silinemez ve yeniden adlandırılamaz. Read hakkı da içermediği için klasör içeriği listelenemez ve dosyalar okunamaz.

Write; Create Files / Write Data, Create Folders / Append Data, Write Attributes, Write Extended Attributes ve Read Permissions gelişmiş izinlerini kapsar. Tek başına Write verilmiş bir kullanıcının yapabildikleri ve yapamadıkları şöyle:

Write'ı tek başına, kullanıcının ya da uygulamanın klasöre içerik bırakması istenen ama içeriği görmesi ve sonradan müdahale etmesi istenmeyen yapılarda bilinçli olarak kullanıyorum.

✅ Modify

Modify, bir dosya veya klasör üzerinde okuma, çalıştırma, oluşturma, içerik değiştirme, yeniden adlandırma ve silme hakkı verir. Günlük kullanımda içerikle çalışan kullanıcılar için verdiğim en geniş izin budur.

Modify; Traverse Folder / Execute File, List Folder / Read Data, Read Attributes, Read Extended Attributes, Create Files / Write Data, Create Folders / Append Data, Write Attributes, Write Extended Attributes, Delete ve Read Permissions gelişmiş izinlerini kapsar. Delete Subfolders and Files, Change Permissions ve Take Ownership bu pakette yoktur. Kullanıcı izinleri değiştiremez ve sahipliği alamaz.

✅ Full Control

Full Control, bir dosya veya klasör üzerindeki tüm işlemlere izin verir. Kullanıcı içerik oluşturabilir, okuyabilir, değiştirebilir, silebilir, nesnenin izinlerini düzenleyebilir ve sahipliğini alabilir.

Full Control; Traverse Folder / Execute File, List Folder / Read Data, Read Attributes, Read Extended Attributes, Create Files / Write Data, Create Folders / Append Data, Write Attributes, Write Extended Attributes, Delete, Delete Subfolders and Files, Read Permissions, Change Permissions ve Take Ownership olmak üzere tüm gelişmiş izinleri kapsar. Change Permissions hakkı nedeniyle Full Control alan bir kullanıcı kendine veya başkasına yeni izin verebilir, yöneticilerin izinlerini de kaldırabilir. Bu yüzden son kullanıcılara Full Control vermiyorum.

3- Gelişmiş İzinler (Advanced Permissions)

Gelişmiş İzinler (Advanced Permissions), Advanced Security Settings penceresinde bir ACE'yi düzenlerken gördüğüm on üç ayrı haktır. Temel izinler bu hakların hazır gruplarıdır. Hiçbir temel izin ihtiyaca tam uymadığında, örneğin kullanıcının dosya silebilmesi ama klasörün kendisini silememesi istendiğinde, gelişmiş izinlerle çalışıyorum.

Gelişmiş izinlerle çalışırken her ACE'nin iki ayarı var: hangi hakları verdiği ve bu hakların hangi nesnelere uygulandığı. İkinci ayar Applies to alanıdır.

Applies to ve İzin Kapsamı

Permission Entry penceresindeki Applies to alanı, ACE'nin tanımlandığı klasörde mi kalacağını yoksa alt klasör ve dosyalara da ineceğini belirler. Klasörlerde varsayılan değer This folder, subfolders and files'dır.

Aynı penceredeki Only apply these permissions to objects and/or containers within this container seçeneği işaretlendiğinde ACE yalnızca bir alt seviyeye iner, daha derindeki nesnelere ulaşmaz. List Folder Contents'ın dosyalara inmemesi de bu Applies to mantığına dayanır.

✅ Traverse Folder / Execute File

Bu izin, uygulandığı nesneye göre iki farklı hak taşır. Klasörde Traverse Folder olarak çalışır ve kullanıcının klasörün içeriğini listeleme yetkisi olmadan klasör hiyerarşisi boyunca ilerleyip bir alt nesneye ulaşmasını sağlar. Dosyada Execute File olarak çalışır ve .exe, .dll gibi dosyaların çalıştırılmasına izin verir.

Traverse Folder hakkının belirleyici olabilmesi için önemli bir koşul var. Windows bu kontrolü, kullanıcının Token'ında Bypass traverse checking (SeChangeNotifyPrivilege) ayrıcalığı yoksa yapar. Bu ayrıcalık varsayılan olarak Everyone grubu dahil geniş gruplara atanmıştır. Varsayılan yapılandırmada kullanıcı tam yolu biliyorsa, aradaki klasörlerde hiçbir izni olmasa da hedef nesneye ulaşabilir. Traverse Folder izni, bu ayrıcalık kullanıcılardan kaldırıldığında belirleyici hale gelir.

Traverse Folder / Execute File izninin tipik kullanım senaryosu, GPO ile masaüstüne dağıtılan bir Shortcut'ın sunucudaki belirli bir uygulamayı hedeflemesidir. Kullanıcının uygulamayı çalıştırabilmesi istenirken klasör yapısının geri kalanını görmesi istenmez. Aşağıdaki örnekte bir kullanıcının Network üzerindeki LogoGo3.exe uygulamasını çalıştırabilmesi için klasör hiyerarşisi boyunca tanımladığım izinleri gösteriyorum.

\\srvdhcp-1\IT\Applications\FinanceTools\Logo\GO3\Client\LogoGo3.exe

IT klasöründe Inheritance'ı kapatıp yalnızca Traverse Folder / Execute File tanımladığım için Applications, FinanceTools, Logo ve GO3 klasörleri bu izni miras alıyor ve kullanıcı bu klasörlerin içeriğini göremiyor. Bypass traverse checking varsayılan atamasıyla duruyorsa, bu ara klasörlerdeki Traverse kontrolü zaten yapılmaz. Uygulamanın çalışmasını asıl sağlayan, Client klasöründeki ACE'dir. Bu ACE'nin Applies to değeri dosyaları kapsıyorsa LogoGo3.exe dosyası Execute File ve Read Data haklarını alır ve uygulama çalışır. Uygulama aynı klasördeki DLL veya yapılandırma dosyalarına ihtiyaç duyuyorsa bu dosyalar da aynı ACE'den okuma hakkı alır. Ayrıca kullanıcının IT paylaşımında Share izni olması gerekir.

✅ List Folder / Read Data

List Folder / Read Data, ACL'de tek bir satırdır ve uygulandığı nesnenin türüne göre farklı davranır. Klasörde List Folder olarak çalışır ve kullanıcının klasörde hangi dosya ve alt klasörlerin bulunduğunu görmesini sağlar. Dosyada Read Data olarak çalışır ve dosya içeriğinin okunmasına izin verir. İki hak ayrı ayrı atanmaz, tek bir tanım yapılır ve davranışı nesnenin türü belirler. Bu iznin dosyalara inip inmeyeceğini ACE'nin Applies to değeri belirler.

Bu izin yoksa kullanıcı klasörü açtığında içeriği listeleyemez. Traverse ile tam yolu bildiği bir nesneye ulaşabilmesi ise bundan bağımsızdır.

✅ Read Attributes

Read Attributes, bir dosya ya da klasörün Read-only, Hidden, Archive ve System gibi standart Attribute'larını ve zaman damgalarını görüntüleme hakkı verir. İçeriğe erişim sağlamaz, Attribute'ları değiştirme hakkı da vermez.

Bu izin yoksa bazı komut satırı araçları ve Script'ler dosyanın Attribute bilgisini okuyamadığı için hata verebilir.

✅ Read Extended Attributes

Read Extended Attributes, bir dosyaya uygulamalar tarafından eklenen Extended Attribute'ların okunmasına izin verir. Extended Attribute'lar, dosya içeriğinden ayrı tutulan ad-değer çiftleridir ve Explorer'da görünen bir karşılıkları yoktur. Örneğin WSL, Windows diskleri üzerindeki dosyalar için Linux sahiplik ve izin bilgilerini bu alanlarda tutar.

Dosya özelliklerindeki Advanced penceresinde görünen Archive, Index, Compress ve Encrypt seçenekleri ise Extended Attribute değildir. Bunlar standart dosya Attribute'larıdır ve Read Attributes ile Write Attributes izinlerine bağlıdır.

✅ Create Files / Write Data

Create Files / Write Data, klasörde Create Files olarak çalışır ve klasör içine yeni dosya oluşturulmasına izin verir. Dosyada Write Data olarak çalışır ve dosyanın içeriğinin değiştirilmesine ya da üzerine yazılmasına izin verir. Klasör oluşturma hakkı vermez, bu davranış Create Folders / Append Data iznine bağlıdır.

Bu izin, başka bir dizinden dosya kopyalamak için de gereklidir. Dosyayı aynı Volume içinde başka bir klasöre taşımak ise kaynak tarafta ayrıca silme hakkı gerektirir. Bu hak dosyanın Delete izninden ya da kaynak klasördeki Delete Subfolders and Files izninden gelebilir. Bir dosyanın adını veya uzantısını değiştirmek de bu izne bağlı değildir. Yeniden adlandırma için dosya üzerinde Delete hakkı (ya da üst klasörde Delete Subfolders and Files) gerekir.

✅ Create Folders / Append Data

Create Folders / Append Data, klasörde Create Folders olarak çalışır ve yeni alt klasör oluşturulmasına izin verir. Dosyada Append Data olarak çalışır ve mevcut içeriği değiştirmeden dosyanın sonuna veri eklenmesine izin verir. Bir Log dosyasına yeni satır eklemek buna örnektir. İçeriği değiştirmek ya da yeni dosya oluşturmak için Create Files / Write Data izni gerekir.

Klasörde yalnızca bu izin tanımlıysa başka bir dizinden dosya içeren bir klasör kopyalandığında hedefte klasör oluşturulur, ancak içindeki dosyalar oluşturulamadığı için işlem yarıda kalır. Oluşturulan bir klasörün adını değiştirmek için de bu izin yeterli değildir. Klasör üzerinde Delete ya da üst klasörde Delete Subfolders and Files hakkı gerekir.

✅ Write Attributes

Write Attributes, bir dosya ya da klasörün Read-only, Hidden, Archive gibi standart Attribute'larının ve zaman damgalarının değiştirilmesine izin verir. İçerikte herhangi bir değişiklik yapmaz. Bu izin tanımlı değilse kullanıcı dosyanın içeriğini değiştirebiliyor olsa bile Read-only Attribute'unu kaldıramaz. Bu durumda dosyayı kaydetmeye çalıştığında hata alır.

✅ Write Extended Attributes

Write Extended Attributes, uygulamaların dosyaya eklediği Extended Attribute'ların yazılmasına ve değiştirilmesine izin verir. Bu izin olmadan, dosyanın kendisine yazabilen bir kullanıcı bile bu alanlara veri ekleyemez. Extended Attribute kullanan özel uygulamalarda bu izin eksikse işlem hata ile sonuçlanabilir.

Microsoft Office dosyalarındaki Author, Title, Company ve Comments gibi bilgiler bu kapsamda değildir. Bu bilgiler dosyanın kendi içinde saklanır ve dosya kaydedilirken Write Data hakkıyla yazılır.

✅ Delete

Delete, bir dosya veya klasörün silinmesine izin verir. Bu izin silinecek nesnenin üzerinde tanımlıysa kullanıcı, içeriğe erişim hakkı olmasa bile nesneyi silebilir. Yeniden adlandırma ve aynı Volume içinde taşıma da silme hakkı gerektirir. Bu hak nesnenin kendi Delete izninden ya da aşağıda anlattığım üst klasör izninden gelebilir.

Silme hakkı başka bir yoldan da gelebilir. Silinecek nesnede Delete izni yoksa, bulunduğu üst klasördeki Delete Subfolders and Files izni aynı işlemi mümkün kılar. Windows silme sırasında bu iki izni ayrı ayrı değerlendirir ve birinin varlığı yeterlidir.

✅ Delete Subfolders and Files

Delete Subfolders and Files yalnızca klasörlerde bulunur ve klasörün içindeki dosya ve alt klasörlerin silinmesine izin verir. Bu izin üst klasörde varsa, alt nesnenin kendi ACL'inde Delete hakkı olmasa da alt nesne silinebilir.

İçi dolu bir alt klasörün silinebilmesi için önce içindeki her nesnenin silinebilmesi gerekir. Bu nedenle izin yalnızca üst klasörde kalıyorsa alt klasörün doğrudan içeriğini kapsar. İznin alt klasörlere de miras yoluyla inmesi durumunda alt klasör içeriğiyle birlikte silinebilir.

✅ Read Permissions

Read Permissions, bir dosya veya klasör üzerinde tanımlı izinlerin görüntülenmesine izin verir. Bu izin varsa kullanıcı Security sekmesini açıp hangi kullanıcıya veya gruba hangi izinlerin verildiğini görebilir.

İzin tanımlı değilse kullanıcı, içeriğe erişebiliyor olsa bile Security sekmesini açtığında izinleri göremez ve okuma izni olmadığını belirten bir uyarı alır. Nesnenin Owner'ı ise bu izin olmadan da izinleri görebilir.

✅ Change Permissions

Change Permissions, bir dosya veya klasör üzerindeki izinlerin düzenlenmesine izin verir. Bu izinle kullanıcı Security sekmesinden mevcut izinleri değiştirebilir, yeni kullanıcı veya grup ekleyebilir ve var olan kayıtları kaldırabilir.

Bu izin nesnenin sahipliği üzerinde bir değişiklik yapmaz. Owner bilgisini değiştirmek için Take Ownership izni gerekir.

✅ Take Ownership

Take Ownership, bir dosya veya klasörün sahipliğinin alınmasına izin verir. Bu izinle kullanıcı Advanced Security Settings penceresindeki Owner satırından nesnenin sahipliğini kendi hesabına ya da Token'ında Owner olarak atanabilen bir gruba (yöneticiler için Administrators grubu gibi) geçirebilir. Owner alanına başka bir kullanıcı veya grubu doğrudan atamak ise bu izinle mümkün değildir, bunun için SeRestorePrivilege ayrıcalığı gerekir ve bu ayrıcalık varsayılan olarak Administrators grubundadır.

Kullanıcı içeriğe erişemese bile bu izin varsa sahipliği üstlenebilir. Sahipliği aldıktan sonra Owner'ın örtük hakları sayesinde izinleri de düzenleyebilir, ayrıca Change Permissions iznine ihtiyaç duymaz.

4- Temel ve Gelişmiş İzinler Arasındaki Bağlantı

Aşağıdaki tabloda her temel iznin hangi gelişmiş izinleri içerdiği görülüyor. Bir temel izin seçildiğinde, tabloda o sütunda işaretli olan gelişmiş izinler ACE'ye birlikte yazılır.

Temel izinler tam bir hiyerarşi oluşturmaz. Read and Execute, Read'i kapsar. Write ise Read'i kapsamaz, kendi başına ayrı bir pakettir. Modify seçildiğinde Read and Execute, List Folder Contents, Read ve Write izinleri ile bunlara bağlı gelişmiş izinler, üzerine de Delete eklenmiş olarak etkin hale gelir. Full Control buna Delete Subfolders and Files, Change Permissions ve Take Ownership izinlerini ekler.

5- Share ve NTFS İzinlerinin Birlikte Değerlendirilmesi

Bir klasöre hangi yoldan erişildiği, hangi izinlerin devreye gireceğini belirler. Klasöre yerel yol üzerinden (örneğin D:\COMPANY) erişildiğinde yalnızca NTFS izinleri geçerlidir. Aynı bilgisayarda bile klasöre \\localhost\COMPANY ile SMB üzerinden erişilirse iki katman birlikte değerlendirilir. Klasöre Network üzerinden, UNC (Universal Naming Convention) Path ile erişildiğinde ise önce Share Permissions (Read, Change, Full Control), ardından NTFS Permissions değerlendirilir. Kullanıcı bu iki tarafın kesişimi kadar erişim alır, yani ikisi arasında en kısıtlayıcı olan uygulanır.

File Server'lara erişim neredeyse her zaman UNC Path üzerinden yapıldığı için iki tarafı birlikte kurgulamak gerekiyor. Saha tecrübeme dayanan tavsiyem, Share tarafında Authenticated Users (ya da Everyone) grubuna Full Control verip tüm kısıtlamaları NTFS tarafında yapılandırmak yönünde. Böylece izinler tek bir yerde yönetilir ve bir kullanıcının neden erişemediğini ararken iki ayrı listeyi karşılaştırmak zorunda kalmam. Varsayılan Share izni Everyone için Read olduğundan bu ayarı paylaşımı açarken değiştirmek gerekir.

Aşağıdaki uygulamalarda en kısıtlayıcı iznin nasıl belirlendiğini göstermek için Share tarafında Everyone grubuna bilerek Change veriyorum. Bu tercihin etkisi Uygulama-4'te ortaya çıkıyor.

Ön Kontrol

Uygulamaların sonuçlarının ekran görüntüleriyle aynı çıkması için ortamın şu durumda olması gerekiyor:

İlk satırın nedeni şu: Volume kökünün varsayılan ACL'i BUILTIN\Users grubuna klasör oluşturma hakkı verir. Domain Users grubu, Domain'e üye sunucularda BUILTIN\Users grubunun üyesidir. COMPANY klasörü bu ACE'yi miras alıyorsa User100, Security tarafında yalnızca Read verilmiş olsa bile klasör oluşturabilir ve Uygulama-1'in sonucu değişir.

Kullanıcının gerçekte hangi erişime sahip olduğunu görmek için klasör özelliklerinde Security, Advanced, Effective Access sekmesini kullanıyorum. Select a user ile User100'ü seçip View effective access butonuna tıkladığımda, gruplardan ve mirastan gelen izinler dahil her gelişmiş iznin sonucu listelenir. Klasör paylaşıma açıksa, bir iznin Share tarafından kısıtlandığı da Access limited by sütununda görünür.

Uygulama-1 - Read

1- File Server'da COMPANY adında bir klasör oluşturup bu klasörü paylaşıma açıyorum. Paylaşıma açarken Permissions butonuna tıklayarak Everyone grubuna Allow bölümünde Change yetkisi veriyorum.



2- Sıra COMPANY klasöründe NTFS izin atamasına geliyor. Security sekmesinde User100 kullanıcısı için Allow bölümünde Read yetkisi veriyorum.





3- User100 ile oturum açtığım istemciden UNC Path üzerinden paylaşım klasörüne erişip Yeni Klasör (New Folder) oluşturmaya çalıştığımda, bu işlem için yetkim olmadığı uyarısını alıyorum.

Share tarafında Everyone grubu için Change tanımlamıştım, bu tek başına klasör oluşturmaya yeterdi. Ancak User100, Everyone grubunun üyesi olmasına rağmen NTFS tarafında yalnızca Read iznine sahip. İki taraf arasında en kısıtlayıcı olan Read olduğu için yalnızca okuma yapabiliyorum. "En kısıtlayıcı olan uygulanır" ifadesinin pratikteki karşılığı budur.

Kontrol Noktası
COMPANY klasörünün Effective Access sekmesinde User100 için yalnızca okuma ile ilgili gelişmiş izinler Allowed görünmeli. Create Files / Write Data ve Create Folders / Append Data satırları izin verilmemiş olarak listelenmeli.

Uygulama-2 - Write

1- Aynı COMPANY klasöründe aynı User100 kullanıcısı için NTFS tarafındaki yetki seviyesini Write olarak güncelliyorum.




2- İstemciden UNC Path üzerinden paylaşım klasörüne erişip Yeni Klasör (New Folder) oluşturuyorum. Klasör oluşuyor, ancak Enter tuşuna basmadan ya da boş alana tıklamadan adını değiştirmeye çalıştığımda yetkim olmadığı uyarısını alıyorum.

Bir dosya veya klasörün adını değiştirmek, o nesne üzerinde Delete ya da üst klasörde Delete Subfolders and Files hakkı gerektirir. Write temel izninde bu iki haktan hiçbiri bulunmadığı için klasörü oluşturabiliyor, ancak adını değiştiremiyorum.



3- Tek başına Write izniyle klasör içindeki dosya ve klasörlerin adlarını değiştiremiyorum. Ancak başka bir dizinden (örneğin Desktop) paylaşım klasörüne Cut ve Paste ya da Drag & Drop yöntemiyle dosya veya klasör kopyalayabiliyorum.

Kontrol Noktası
Kopyalanan içerik hedefte oluşmalı, ancak klasör içeriği listelenememeli ve yeniden adlandırma reddedilmeli. Effective Access'te Delete satırı izin verilmemiş olarak görünmeli.

Uygulama-3 - Modify

1- Aynı COMPANY klasöründe aynı User100 kullanıcısı için NTFS tarafındaki yetki seviyesini Modify olarak güncelliyorum.



2- Modify ile kullanıcı artık Delete hakkına da sahip olduğu için oluşturduğu dosya ve klasörlerin adını değiştirebiliyor. Bana zaman zaman yeniden adlandırmanın hangi gelişmiş izne bağlı olduğu soruluyor. Nesne üzerindeki Delete ya da üst klasördeki Delete Subfolders and Files hakkı yeterlidir. Modify'da Delete bulunduğu için bu uygulamada ilk yol devreye giriyor.

Share tarafındaki Change yetkisi de okuma, yazma ve silmeyi kapsadığı için bu uygulamada iki taraf arasında bir kısıtlama oluşmuyor.

Kontrol Noktası
Kullanıcı klasör oluşturup yeniden adlandırabilmeli ve silebilmeli. Effective Access'te Delete satırı Allowed görünmeli.

Uygulama-4 - Full Control

1- Aynı COMPANY klasöründe aynı User100 kullanıcısı için NTFS tarafındaki yetki seviyesini Full Control olarak güncelliyorum.




2- Kullanıcıya NTFS tarafında Full Control verilmiş olmasına rağmen, Full Control'ün getirdiği Change Permissions ve Take Ownership haklarını Network üzerinden kullanamıyor. Bunun nedeni Share tarafında Everyone grubu için tanımladığım Change yetkisidir. Network erişiminde Share tarafındaki Change ile NTFS tarafındaki Full Control'ün kesişimi, pratikte Modify seviyesine denk düşüyor.

Bu noktada NTFS tarafında hangi kullanıcıya Full Control verirsem vereyim, Network üzerinden erişimde Share tarafındaki en kısıtlayıcı yetki olan Change geçerli olacak ve Full Control'ün fazlası etkisiz kalacaktır. Aynı kullanıcı klasöre File Server üzerinde yerel yol üzerinden erişseydi Share izni devreye girmeyeceği için Full Control'ün tamamını kullanabilirdi.

Kontrol Noktası
Effective Access'te User100 için Change Permissions ve Take Ownership satırlarında Access limited by sütunu Share değerini göstermeli.

6- Special Permissions (Özel İzinler)

Her temel izin, bir grup gelişmiş iznin karşılığıdır. Bir ACE, hiçbir temel iznin paketiyle birebir örtüşmediğinde Security sekmesinde Special Permissions olarak etiketlenir. Bu iki şekilde olur. Birincisi, bir temel iznin içerdiği gelişmiş izinlerden bir ya da birkaçının kaldırılmasıdır. Örneğin Full Control'den Take Ownership iznini kaldırdığımda kullanıcının izni artık Full Control değil, Special Permissions olarak görünür. İkincisi, ACE'nin Applies to değerinin varsayılandan farklı seçilmesidir. Örneğin Modify'ı This folder only kapsamıyla verdiğimde de Special Permissions işaretlenir.









ACL'de bir kullanıcı ya da grup için Special Permissions işaretli görüyorsam, ya bir temel iznin gelişmiş izinlerinden bir kısmı kaldırılmıştır ya da ACE farklı bir Applies to kapsamıyla tanımlanmıştır. Hangisi olduğunu Advanced Security Settings penceresinde ilgili satırın Access ve Applies to sütunlarından görüyorum.

7- Inheritance (Miras)

Bir klasörde kullanıcı ya da gruba NTFS izni atadığımda, varsayılan Applies to değeri nedeniyle bu izin tüm alt klasör ve dosyalara da iner. Security sekmesinde bir kullanıcıya ait onay kutularının siyah ve değiştirilebilir olması, iznin o klasörde doğrudan tanımlandığını (Explicit) gösterir. Onay kutularının gri olması ise iznin üst klasörden miras geldiğini gösterir. Advanced Security Settings penceresindeki Inherited from sütunu, miras gelen her iznin hangi klasörden geldiğini ayrıca belirtir.

Inheritance'ın Devre Dışı Bırakılması

Alt klasörlerde farklı kullanıcılar veya gruplar için farklı yetkilendirme ihtiyacı doğduğunda, o alt klasörde mirası devre dışı bırakıyorum.

1- Klasör özelliklerinde Security sekmesindeki Advanced butonuna tıklıyorum.

2- Açılan Advanced Security Settings penceresinin alt kısmındaki Disable inheritance butonuna tıklıyorum.

3- Karşıma iki seçenek çıkıyor.

Sahada çoğunlukla ilk seçeneği kullanıyor, ardından gereksiz izinleri tek tek kaldırıyorum. Böylece miras kesildiği anda hiçbir kullanıcının erişimi beklenmedik şekilde değişmiyor.

İzinlerin Yeniden Yapılandırılması ve ACL Yedeği

Bir klasör ağacındaki izinlerin tamamen karışması ve yönetilemez hale gelmesi, danışmanlık verdiğim kurumlarda sık karşılaştığım bir durum. Plansız verilen izinler biriktikçe hangi kullanıcının neden erişebildiğini bulmak neredeyse imkansızlaşıyor. Böyle bir durumda Replace all child permission entries with inheritable permission entries from this object seçeneğini kullanıyorum. Bu seçenek, alt klasör ve dosyalardaki tüm Explicit izinleri siler, mirası devre dışı bırakılmış alt klasörlerde mirası yeniden açar ve seçildiği klasördeki miras verilebilir izinleri ağacın tamamına uygular.

Yedeği, File Server'da yükseltilmiş (Run as administrator) bir komut isteminde icacls ile alıyorum. {Klasör Yolu} yerine düzenleme yapacağım klasörün tam yolunu, {Yedek Dosyası} yerine yedeğin yazılacağı dosyanın tam yolunu yazmak gerekiyor. /t parametresi alt nesneleri de kapsar, /c ise erişilemeyen bir nesnede işlemin durmadan devam etmesini sağlar.

icacls "{Klasör Yolu}" /save "{Yedek Dosyası}" /t /c

1- İzinleri yeniden yapılandırmak için düzenlemeyi başlatacağım üst klasörü seçiyorum.



2- Klasör özellikleri penceresinde Advanced butonuna tıklıyorum.



3- Advanced Security Settings penceresinin alt kısmındaki Replace all child permission entries with inheritable permission entries from this object seçeneğini işaretliyor ve OK butonuna tıklıyorum.



4- Bu klasördeki izinlerin tüm alt nesnelere uygulanacağını ve alt nesnelerdeki Explicit izinlerin değiştirileceğini belirten uyarıda Yes butonuna tıklıyorum.



5- FILES klasörü altındaki FOLDER-3 klasöründe mirası daha önce devre dışı bırakmıştım. İşlem sonrasında bu klasörde miras yeniden açılmış, izinleri de FILES klasöründeki miras verilebilir izinlerle aynı hale gelmiş.

Kontrol Noktası
Alt klasörlerin Advanced Security Settings penceresinde tüm satırların Inherited from sütununda üst klasör görünmeli ve Enable inheritance yerine Disable inheritance butonu yer almalı.

Sonuç beklendiği gibi değilse önceki ACL'leri yedekten geri yüklüyorum. icacls, yedeği alınan klasörün yolunu üst klasöre göre kaydettiği için /restore komutunu yedeği alınan klasörün kendisinde değil, bir üst klasörde çalıştırmak gerekiyor. Örneğin yedek D:\FILES için alındıysa {Üst Klasör Yolu} değeri D:\ olur.

icacls "{Üst Klasör Yolu}" /restore "{Yedek Dosyası}" /c

Taşıma ve Kopyalamada İzin Davranışı

Miras davranışı, bir dosyanın klasöre nasıl geldiğine göre de değişiyor. Kopyalanan dosya veya klasör yeni bir nesne olarak oluşturulduğu için hedef klasörün izinlerini miras alır. Aynı Volume içinde taşınan nesne ise yeni oluşturulmaz, mevcut izinlerini korur ve hedef klasörün izinlerini almaz. Farklı bir Volume'a taşıma, arka planda kopyalama ve silme olarak yapıldığı için hedefin izinlerini alır.

Bu fark, izinleri kısıtlı bir klasöre taşınan dosyanın eski klasördeki geniş izinleriyle kalmasına yol açabiliyor. Böyle bir durumda taşınan nesnede Advanced Security Settings penceresinden mirası kontrol ediyorum.

8- Klasör Sahipliği (Folder Ownership)

Varsayılan Owner

Bir dosya veya klasör oluşturulduğunda, oluşturan hesabın Token'ında tanımlı varsayılan Owner nesnenin sahibi olur. Normal bir kullanıcı için bu, kullanıcının kendi hesabıdır. Administrators grubunun üyelerinde ise sonuç, System objects: Default owner for objects created by members of the Administrators group ilkesine ve oturumun yükseltilmiş olup olmadığına bağlıdır. Bu nedenle bir yöneticinin oluşturduğu klasörde Owner olarak çoğu zaman Administrators grubunu görüyorum.

Klasör sahipliği pratikte önemsiz gibi görünse de birkaç durumda doğrudan iş görüyor.

Roaming Profile klasörlerine yönetici erişimi. Roaming Profile (gezici profil) klasörlerinde varsayılan olarak yalnızca kullanıcının kendisi ve SYSTEM erişime sahiptir. Bu klasörlerden Mandatory Profile (zorunlu profil) oluşturmak için yöneticinin önce klasörün sahipliğini alması gerekir.

Silinmiş kullanıcıların klasörleri. Active Directory'den hesabı silinen bir kullanıcı, sahibi olduğu klasörlerde çözümlenemeyen bir SID olarak kalır. Bu klasörlerin sahipliğinin aktif bir Active Directory kullanıcı nesnesi ya da yönetici grubu üzerine geçirilmesi gerekir.

Owner'ın örtük hakları. Bir klasörün sahibi, ACL'de yalnızca Read izni olsa bile klasörün izinlerini yönetebilir. OWNER RIGHTS ACE'si tanımlanmadıkça bu hak ACL'den kaldırılamaz.

1- FILES klasörü altındaki FOLDER-1 klasörünün sahibinin Administrators grubu olduğunu görüyorum.



2- Yönetici hesabıyla FILES klasörü altında FOLDER-1-1 adında yeni bir klasör oluşturduğumda, bu klasörün sahibi de otomatik olarak Administrators grubu oluyor.



3- User100 kullanıcısı FILES klasörü altında FOLDER-1-2 adında bir klasör oluşturduğunda ise klasörün sahibi otomatik olarak User100 oluyor.

Sahipliğin Alınması

1- Sahibi Administrators grubu olan FOLDER-1-1 klasörünün sahipliğini User100 ile almak için Advanced Security Settings penceresinde Owner satırındaki Change bağlantısına tıklıyor ve User100 hesabını seçiyorum.

Alt Nesnelerde Owner Değişikliği

1- Sahipliği aldıktan sonra Replace owner on subcontainers and objects seçeneğini işaretlediğimde, alt klasör ve dosyaların sahipliği de üst klasörde seçtiğim hesaba geçiyor.

Kontrol Noktası
Alt klasörlerin Advanced Security Settings penceresinde Owner satırında seçilen hesap görünmeli.

Owner alanına doğrudan başka bir kullanıcı veya grup atamak, örneğin silinmiş bir kullanıcının klasörlerini o işi devralan kullanıcıya geçirmek, SeRestorePrivilege gerektirir. Bu işlemi File Server'da yükseltilmiş bir komut isteminde icacls ile yapıyorum. {Klasör Yolu} yerine klasörün tam yolunu, {Domain}\{Hesap} yerine sahipliğin verileceği kullanıcı veya grubu yazmak gerekiyor.

icacls "{Klasör Yolu}" /setowner "{Domain}\{Hesap}" /t /c

Sonucu PowerShell'de Get-Acl ile kontrol ediyorum. Owner satırında yeni hesap görünmelidir.

Get-Acl -Path "{Klasör Yolu}" | Format-List Path, Owner, AccessToString

9- İzin Tasarımı ve Denetim

NTFS izinlerinde karşılaştığım karmaşanın büyük kısmı, izinlerin tek tek kullanıcılara verilmesinden kaynaklanıyor. Kullanıcı bazlı izinler arttıkça bir kullanıcının neden erişebildiğini bulmak için her klasörün ACL'ini ayrı ayrı incelemek gerekiyor. Bu yüzden Active Directory ortamlarında izinleri AGDLP modeline göre kuruyorum.

Account (Kullanıcı hesabı)
   │  üyesi olduğu
   ▼
Global Group (rol veya departman grubu)
   │  üyesi olduğu
   ▼
Domain Local Group (kaynak ve izin seviyesi grubu)
   │  ACL'de yer alan
   ▼
Permission (NTFS izni)

Bu modelde ACL'de yalnızca Domain Local gruplar yer alır ve her grup tek bir kaynak ile tek bir izin seviyesini temsil eder. Örneğin COMPANY klasörü için biri Read, biri Modify veren iki Domain Local grup oluşturup departman gruplarını bunların içine ekliyorum. Kullanıcının erişimi değiştiğinde ACL'e dokunmuyor, yalnızca grup üyeliğini değiştiriyorum. Grup üyeliğindeki değişikliğin kullanıcının yeni oturumunda geçerli olduğunu da hesaba katıyorum.

Hassas klasörlerde izinlerin nasıl kullanıldığını izlemek için Audit yapılandırıyorum. Bunun için iki ayarın birlikte yapılması gerekiyor. Klasörün SACL'ine izlenecek kullanıcı veya grup ve işlem türü (örneğin Delete) eklenir, ayrıca Group Policy ile Advanced Audit Policy altındaki Object Access, Audit File System ilkesi açılır. İki ayar da yapıldığında ilgili erişimler Security Log'a 4663 olay kimliğiyle yazılır.

Düzenli denetim için PowerShell ile klasör ağacındaki Explicit izinleri listeliyorum. Miras yoluyla gelmeyen her izin bilinçli bir karar olmalı. IdentityReference sütununda bir hesap adı yerine S-1-5-21 ile başlayan bir SID görüyorsam, bu silinmiş bir hesaptan kalan ve temizlenmesi gereken bir kayıttır.

Get-ChildItem -Path "{Klasör Yolu}" -Directory -Recurse | ForEach-Object {
    $Folder = $_.FullName
    (Get-Acl -Path $Folder).Access |
        Where-Object { -not $_.IsInherited } |
        Select-Object @{Name='Path';Expression={$Folder}}, IdentityReference, FileSystemRights, AccessControlType
}

Bir klasör yapısının izinlerini doğru kurduğumu şu ölçütlerle anlıyorum: test kullanıcılarının Effective Access sonuçları tasarladığım izinlerle örtüşüyor, Explicit izinler yalnızca planladığım klasörlerde bulunuyor, ACL'lerde çözümlenmemiş SID kalmıyor ve son kullanıcılara Full Control verilmemiş oluyor. Bu noktaya geldikten sonra yeni klasörleri aynı grup modeline göre açıyor ve izin değişikliklerini yalnızca grup üyelikleri üzerinden yapıyorum.

Faydalı olması dileğiyle...