Authentication ile authorization farkı: Kimliğini kanıtlamak neden erişim izni değildir?

1. Core Mechanism / Temel mekanizma

Bu ders authentication ile authorization arasındaki sınırı kurar: authentication kimliği kanıtlar ve bir access token üretir; authorization o token'ı belirli bir nesnenin DACL'iyle, belirli bir istenen hak için karşılaştırır. Grupların token'a nasıl toplandığı 05.01'de; security descriptor/DACL/ACE'nin okunması 05.03'te; allow/deny/inheritance'ın sıralı değerlendirilmesi 05.04'te ele alınır. Buradaki odak, 'kimliğini kanıtladım' ile 'bu işlemi yapmaya iznim var' arasındaki farkın neden mekanizma düzeyinde ayrı olduğudur.

Arabirimler ve belirtimler

• Authentication: bir principal'ın iddia ettiği kimliği kanıtlaması (interactive logon, Kerberos ticket, credential doğrulaması); sonucu bir logon session ve access token'dır.
• Access token: authentication'ın çıktısı ve authorization'ın girdisi; kullanıcı SID'i ve grup SID'lerini taşır.
• Authorization / access check: sistemin token'daki SID'leri hedef nesnenin DACL'indeki ACE'lerle, istenen access mask için karşılaştırıp erişimi verme/reddetme kararı.
• Requested access mask: erişim isteğinin hangi hakları (ör. FILE_READ_DATA, FILE_WRITE_DATA) talep ettiğini belirten bit kümesi; access check bu maskeye göre yürütülür.
• Per-resource kararı: her nesnenin kendi security descriptor'ı vardır; aynı token bir nesnede yetkiliyken başka nesnede yetkisiz olabilir.
• Kerberos ticket: kimlik kanıtı taşır; bir ticket'a sahip olmak kaynak yetkilendirmesini içermez, yalnız authentication tarafını karşılar.

İki ayrı soru: kimsin ve ne yapabilirsin

Authentication tek bir soruyu yanıtlar: 'iddia ettiğin kimlik gerçekten sen misin?' Bunu bir interactive logon, bir Kerberos ticket veya bir credential doğrulaması sağlar. Başarılı olduğunda sistem sana bir logon session ve bu session'a bağlı bir access token verir. Bu noktada henüz hiçbir kaynağa erişim verilmemiştir; yalnız kimliğin kanıtlanmıştır.

Authorization bambaşka bir soruyu yanıtlar: 'bu belirli nesnede bu belirli işlemi yapmaya iznin var mı?' Bu karar, kimliğin değil, o nesnenin security descriptor'ının işidir. Yani authentication 'kim' sorusunu bir kez cevaplar; authorization 'ne yapabilir' sorusunu her nesne ve her istenen hak için ayrı ayrı cevaplar.

Köprü: access token

İki soruyu birbirine bağlayan yapı access token'dır. Authentication başarıyla tamamlandığında sistem kullanıcının SID'ini ve tüm grup SID'lerini token'a koyar; bu token kimliğin taşınabilir bir özetidir. Authorization ise bu token'ı okur: access check sırasında token'daki SID'ler nesnenin ACE'lerindeki trustee'lerle karşılaştırılır.

Kritik nokta şudur: token bir 'anahtar' değil, bir 'iddia kümesi'dir. İçinde 'şu kaynağa erişebilirim' yazmaz; yalnız 'ben bu SID'lerim' yazar. Erişip erişemeyeceğine, o SID'leri kendi ACE'lerinde nasıl karşıladığına bakarak her kaynak ayrı karar verir. Bu yüzden geçerli bir token'a sahip olmak, herhangi bir kaynağa erişimi garanti etmez.

Access check istenen hakka göre çalışır

Bir thread bir nesneye eriştiğinde sistem ya erişimi verir ya reddeder. Nesnenin DACL'i yoksa (NULL DACL) sistem erişimi verir; DACL varsa, token'daki SID'lere uyan ACE'leri istenen access mask için sırayla inceler. Eşleşen bir access-denied ACE istenen haklardan birini reddederse erişim reddedilir; bir veya daha çok access-allowed ACE istenen tüm hakları verirse erişim verilir; tüm ACE'ler incelendiğinde hâlâ verilmemiş bir istenen hak kalıyorsa erişim implicit olarak reddedilir.

Bunun sonucu, authorization'ın 'hep ya da hiç' değil, hak-bazlı olmasıdır. Aynı nesnede aynı kullanıcı Read için yetkili, Write için yetkisiz olabilir; çünkü access check her istenen hakkı ayrı değerlendirir. 'Authenticated olmak' bu değerlendirmeye hiçbir hak eklemez; yalnız token'ın hangi SID'leri taşıdığını belirler.

Bu dersin Read/Write örneği, ilgili bypass privilege’ı etkin olmayan sıradan bir token ve normal dosya erişimi içindir. Token yalnız SID taşımaz; privilege’lar da içerir. Örneğin etkin SeBackupPrivilege veya SeRestorePrivilege, kendilerine tanımlı dosya işlemlerinde normal ACL kontrollerini etkileyebilir. Bu yüzden DACL sonucu tek başına bütün Windows erişim yollarını anlatmaz.

Ticket authentication'ı karşılar, authorization'ı değil

Kerberos'ta bir kullanıcı authenticate olduğunda kimlik kanıtı taşıyan ticket'lar alır. Bu ticket'lar 'sen kimsin' sorusunu yanıtlar ve hangi grup SID'lerinin token'a gireceğini belirler. Ama bir ticket'a sahip olmak, herhangi bir dosya, paylaşım veya dizin nesnesinde belirli bir hakkı içermez; o hak yalnız hedef kaynağın DACL'i tarafından verilir.

Bu ayrım güvenlik açısından da belirleyicidir: authentication tarafı ele geçirilse bile (ör. bir credential/ticket kötüye kullanılsa), elde edilen erişim yine token'ın SID'lerinin her kaynağın DACL'inde ne kadar karşılık bulduğuyla sınırlıdır. Yani authentication kapıyı açar, ama her odanın kilidini authorization ayrı tutar.

Durum ve veri akışı

1. u.arin geçerli biçimde authenticate olur (başarılı logon / geçerli Kerberos ticket); sistem token'ına kendi SID'ini ve Analysts (RID 2701) dahil grup SID'lerini koyar.
2. u.arin \\FS01\Reports\q3.xlsx dosyasına yazmak için FILE_WRITE_DATA içeren bir access isteği yapar.
3. Access check dosyanın DACL'ini token SID'leri için, istenen yazma hakkına göre değerlendirir.
4. DACL Analysts grubuna yalnız File Read/Execute veren bir allow ACE içerir; yazma hakkı için eşleşen bir allow ACE yoktur.
5. Tüm ACE'ler incelendiğinde istenen FILE_WRITE_DATA hâlâ verilmemiştir; erişim implicit olarak reddedilir — kullanıcı tümüyle authenticated olmasına rağmen.
6. Aynı kullanıcı aynı dosyayı okumak isteseydi, Read için eşleşen allow ACE bulunacağından erişim verilirdi; karar hak-bazlıdır.

2. Exploitation / İstismar

Broken trust assumption

Kırılan varsayım: Geçerli bir credential/ticket veya başarılı bir logon, erişim demektir — 'authenticate oldum, öyleyse yetkiliyim.' Gerçekte authentication yalnız kimliği ve token'ın SID'lerini belirler; her kaynak istenen hakkı kendi DACL'i üzerinden ayrı verir.

Technical prerequisites

• Başarılı authentication'ın (geçerli ticket, başarılı logon) erişim izniyle eşitlenmesi; per-resource, per-right access check'in atlanması ya da yanlış yorumlanması.
• Kaynak DACL'lerinin token'ın grup SID'lerine gereğinden geniş hak vermesi (over-broad ACE), böylece authentication'ın sağladığı SID'lerin tesadüfen yetki taşıması.
• Yetkilendirmenin 'kullanıcı domain'de geçerli mi' düzeyinde bırakılıp nesne düzeyinde daraltılmaması.
• Authentication tarafındaki bir kötüye kullanımın (çalınan/yanlış verilen credential) etkisinin, kaynak DACL'leri geniş olduğunda büyümesi.

Exploitation mechanism / İstismar mekanizması

Bu örnekte geçerli kimlik, dosya hakkı anlamına gelmez. Normal dosya isteğinde token’ın SID’leri hedef DACL’de karşılık bulur; gereksiz geniş ACE’ler bir kimlik hatasının etkisini büyütür. Envanterde yalnız logon başarısını değil, kaynak haklarını ve token’ın ilgili privilege’larını da incele. Buradaki Read/Write karşılaştırması bypass privilege’ı etkin olmayan token içindir; bütün Windows yetkilendirmesini yalnız DACL’e indirgemez.

Token bir anahtar değil, bir iddiadır

'Domain'de geçerli bir hesabım var, öyleyse bu paylaşıma erişebilirim' çıkarımı mekanizma düzeyinde yanlıştır. Geçerli hesap yalnız token'ın hangi SID'leri taşıyacağını belirler; erişim, o SID'lerin hedef kaynağın DACL'inde eşleşen allow ACE'ler bulup bulmadığına bağlıdır. Bu yüzden bir authentication başarısı, ilgili nesnedeki bir access check başarısını asla kanıtlamaz.

Least-privilege DACL, bu normal erişim yolunda etkiyi daraltır. Ancak backup/restore gibi ayrı privilege gerektiren yolları da hesaba katmalısın. “Geçerli hesap” ile “bu işlemi yapabilen security context” aynı soru değildir.

3. Defense & Detection / Savunma ve tespit

Telemetry scope

• 4624, hedef hostta başarılı bir logon session oluşturulduğunu gösterir; herhangi bir dosya hakkının verildiğini göstermez. DC’deki Kerberos ticket olayları da kaynak erişim kararının yerine geçmez.
• Audit Detailed File Share açıksa 5145, paylaşım düzeyindeki access check için kanıt sağlar. AccessMask ve AccessList istenen hakları, AccessReason ise her hak için grant/deny sonucunu ve ilgili ACE gerekçesini gösterir.
• Aynı host ve boot kapsamındaki 4624.TargetLogonId = 5145.SubjectLogonId eşleşmesi, logon session ile paylaşım isteğini ilişkilendirir. 5145 paylaşım düzeyinde ret gösteriyorsa başarılı logon’a rağmen bu isteğin reddedildiğini anlayabilirsin; NTFS sonucu ayrıca incelenir.
• 5145 Failure olayları önemli bir kısıtla üretilir: reddetme yalnız file share düzeyinde olduğunda; NTFS (file system) düzeyinde reddedilen erişim 5145 Failure üretmez, bu yüzden yokluk 'reddedilmedi' anlamına gelmez.

Events and relevant fields

• 4624.TargetLogonId yeni session’ın LUID değeridir. 5145.SubjectLogonId ile aynı host/boot kapsamında eşleştir; farklı hostlardaki aynı hex değerini aynı session sayma.
• 5145.AccessMask ve AccessList/Accesses istek alanlarıdır. AccessReason/Access Check Results, istenen hak için paylaşım düzeyindeki sonucu ve onu açıklayan ACE’yi taşır. Bu alanlar tam DACL’i veya NTFS kararını içermez.
• 5145'in ShareName/RelativeTargetName alanları hangi paylaşım nesnesinin denendiğini verir; aynı token farklı nesnelerde farklı sonuç aldığında bu alanlar per-resource kararı ayrıştırır.
• Authentication olaylarının varlığı authorization'ı ima etmez; bir korelasyon kuralı 'çok sayıda başarılı authentication + tekrarlayan denied object access' desenini authentication/authorization ayrımına göre yorumlamalıdır.

İki olayı ayrı ama birlikte oku

Önce soruyu ayır: kimlik doğrulandı mı, istenen işlem bu kaynakta kabul edildi mi? 4624 ilk soruda, 5145 paylaşım düzeyindeki ikinci soruda işe yarar. Session’ı ilişkilendirmek için aynı host ve boot kapsamında 4624.TargetLogonId ile 5145.SubjectLogonId değerini karşılaştır. Sonra ShareName, RelativeTargetName, istenen haklar ve AccessReason sonucunu oku.

Başarılı logon görmek erişimin verildiğini söylemez. Ret görmek de kimliğin sahte olduğunu söylemez. Paylaşım kontrolü geçse bile NTFS kontrolü isteği reddedebilir; böyle bir ret 5145 Failure üretmez. Olayı göremediğinde önce audit kapsamını ve hangi katmanın karar verdiğini sor.

Detection logic · Sigma

title: Share-level denial candidate from a single 5145 event
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 5145
    AccessReason|contains: 'Access denied'
  condition: selection
fields:
  - SubjectUserSid
  - SubjectLogonId
  - ShareName
  - RelativeTargetName
  - AccessMask
  - AccessList
  - AccessReason
falsepositives:
  - Normal erişim denemelerinde beklenen tekil ret olayları
level: low

Query assumptions

• logsource windows/security ve alan adları (AccessReason, AccessList, SubjectLogonId) SIEM'in 5145'i bu Data Name'lerle düzleştirdiğini varsayar; backend eşlemesi doğrulanmalıdır.
• Kural yalnız file share düzeyindeki access check'i görür; NTFS düzeyinde reddedilen erişim 5145 üretmediğinden bu kural onları yakalamaz.
• 'Access denied' metni AccessReason'daki ret göstergesine dayanır; gerçek dağıtımda ret, sabit bir mesaj yerine %%-kodlu bir sebep dizgesi olarak görünebilir ve mapping'e göre uyarlanmalıdır.
• Bu örnek yalnız tekil 5145 aday kaydını seçer. 4624 join, tekrar sayısı veya zaman penceresi hesaplamaz. Host/boot ve alan mapping’i doğrulanmış bir collector üzerinde ayrıca kurulmalı; gerçek Windows/SIEM çalıştırması yapılmadı.

False positives

• Kullanıcıların yanlış paylaşıma tıklaması veya yetkisi olmayan bir dosyayı denemesi sık ve meşru bir ret üretir.
• Uygulamaların bir kaynağı yoklaması (probe) tek tek ret olayları oluşturabilir; tek olay kötü niyet göstermez.
• Read verilip Write reddedilen normal iş akışları (salt-okunur paylaşımlar) beklenen retlerdir.
• Olayın yokluğu authorization'ın çalışmadığını değil, reddin NTFS düzeyinde olduğunu veya Audit Detailed File Share alt kategorisinin kapalı olduğunu da gösterebilir.

Hardening

• Yetkilendirmeyi 'kullanıcı domain'de geçerli mi' düzeyinde bırakma; her kaynakta least-privilege DACL uygula, böylece authentication'ın sağladığı SID'ler otomatik geniş hak taşımasın.
• Salt-okunur ihtiyaçlarda yalnız Read hakkı ver; Write/Modify'ı ayrı ve gerekçeli gruplara bağla ki hak-bazlı authorization envanterde görünür olsun.
• Object access auditing'i (Audit Detailed File Share ve gerekiyorsa Audit File System) yüksek değerli paylaşımlarda etkinleştir; retlerin yalnız share mı NTFS mi düzeyinde olduğunu bilerek izle.
• Kontrolleri uygulamadan önce pilot kapsamda gürültü ve iş etkisini ölç; least-privilege daraltmasının meşru erişimleri kırmadığını doğrula ve geri dönüş planı tut.

Örnekler üzerinde oku / Read the examples

O:BAG:DUD:(A;;FRFX;;;S-1-5-21-1002233445-2244556677-3366778899-2701)(A;;FA;;;BA)(A;;0x1200a9;;;S-1-5-21-1002233445-2244556677-3366778899-513)

İki yanlış kanı / Two reality checks

Sanılan: Domain'de geçerli bir hesapla giriş yaptıysam (authenticate olduysam) paylaşımlara ve dosyalara erişebilirim demektir.

Gerçekte: Authentication yalnız kimliği kanıtlar ve access token'a hangi SID'lerin gireceğini belirler. Bir dosya veya paylaşımda belirli bir işlemi yapabilmek, o nesnenin DACL'inin token'daki SID'lere istenen hakkı verip vermediğine bağlı ayrı bir access check kararıdır. Bu yüzden geçerli bir logon, herhangi bir nesnede belirli bir erişimi garanti etmez; aynı kimlik bir nesnede yetkili, diğerinde yetkisiz olabilir.

Sanılan: Geçerli bir Kerberos ticket'a sahip olmak, o ticket'ın ait olduğu kaynakta tam erişim sağlar.

Gerçekte: Ticket authentication tarafını karşılar: kimliği kanıtlar ve token'ın grup SID'lerini belirler. Kaynak erişimi ise hedef nesnenin security descriptor'ı tarafından, istenen hak için ayrı verilir. Bir ticket'a sahip olmak 'kimsin' sorusunu yanıtlar; 'bu nesnede şunu yapabilir misin' sorusunu her nesnenin DACL'i, istenen access mask'e göre yanıtlar. Bu örnekte ilgili bypass privilege’ı etkin değildir; privilege ve diğer uygulanabilir kontroller ayrı değerlendirilir.

Kaynaklar / Sources

• Microsoft · Kerberos authentication overview
  Kerberos authentication kimliği kanıtlar; ticket kimlik kanıtı taşır ve kaynak yetkilendirmesi ayrı bir access check'tir
• Microsoft · Access tokens
  Access token authentication'ın çıktısıdır; kullanıcı ve grup SID'lerini taşır ve access check'te kullanılır
• Microsoft · How AccessCheck Works
  DACL yoksa erişim verilir; ACE'ler istenen haklar için sırayla incelenir; access-denied reddeder, access-allowed'lar tüm hakları verir, aksi halde implicit deny
• Microsoft · Access Rights and Access Masks
  İstenen access mask; generic ve standard hakların istek maskesinde toplanması ve access check'in bu maskeye göre çalışması
• Microsoft · ACE strings
  SDDL ACE sözdizimi; A (access-allowed) türü ve FR/FW/FX/FA file rights kısaltmaları
• Microsoft · 4624(S) An account was successfully logged on
  Başarılı logon (authentication kanıtı); TargetLogonId ile sonraki nesne erişim olaylarına korelasyon
• Microsoft · 5145(S, F) A network share object was checked to see whether client can be granted desired access
  AccessMask/AccessList/AccessReason alanları (hak-bazlı karar); Failure yalnız share düzeyinde reddedildiğinde; Audit Detailed File Share
• Microsoft · Managing privileges in a file system
  Caller holds and enables privilege; SeBackupPrivilege/SeRestorePrivilege defined file operations, not a universal DACL-only outcome.