Shadow Admin (Gölge Yönetici) Nedir? Nasıl Tespit Edilir?

Shadow Admin (gölge yönetici), ayrıcalıklı bir gruba üye olmadığı hâlde pratikte yönetici yetkisi taşıyan hesaptır. Yetki, grup üyeliğiyle değil doğrudan bir nesnenin izin listesiyle verilmiştir; bu yüzden “kurumun yöneticileri kimler?” diye sorulduğunda o hesap listede hiç görünmez.

Bir şirketin imza sirkülerini düşünün. O belge, kurum adına kimin imza atabileceğini gösteren resmî listedir: bankaya gidersiniz, listeye bakılır, adı yazan imzalar, yazmayan atamaz. Şimdi listede adı olmayan birinin fiilen geçerli imza atabildiğini fark ettiğinizi düşünün. Belge yanlış değildir, sahte de değildir; sadece yalan söylemektedir, çünkü gerçekte yetki taşıyan birini göstermiyor. Shadow Admin tam olarak budur: kurumun “yöneticiler bunlar” dediği liste ile gerçekte yönetebilenler arasındaki fark.

Bu yazı boyunca o iki listeyi birlikte takip edeceğiz: kurumun gösterdiği liste ve gerçeğin listesi. Konu BT Danışmanlık hizmetimizin risk tespiti koluna girer, çünkü buradaki tehlike bir yetkinin var olması değil, kurumun onu görmüyor olmasıdır. Kardeş yazılarımız gölge BT ve gölge yapay zekâ aynı ailenin başka kollarını ele alıyor; ortak kök hepsinde aynı: kayıtta olmayan bir şeyin sessizce iş görmesi.

Shadow Admin (Gölge Yönetici) Nedir?

Shadow Admin, yetkisini bir gruba üye olarak değil, tek tek nesnelerin izin listesinden alan hesaptır. Klasik bir yönetici hesabı Domain Admins gibi bir gruba eklenir ve yetkisini o üyelikten alır; gölge yöneticinin böyle bir üyeliği yoktur, ama bir dosya, bir kullanıcı hesabı, bir grup ya da bir dizin bölümü üzerinde o nesneyi yönetmesine yetecek bir izni vardır.

Aradaki fark denetim açısından her şeyi değiştirir. Grup üyeliği merkezî ve görünürdür: tek bir yerden, tek bir komutla listelenir. Nesne izni ise dağınık ve yereldir: her nesnenin kendi izin listesinde durur ve o listeye tek tek bakılmadıkça ortaya çıkmaz. İki hesap pratikte aynı kapıyı açar, ama biri kurumun baktığı listede yazar, öteki yazmaz.

Bu ayrım, ismindeki “gölge” kelimesinin nereden geldiğini de açıklıyor. Hesabın kendisi gizli değildir, dizinde açıkça durur ve normal bir kullanıcı gibi görünür. Gizli olan şey yetkisidir: o yetki, herkesin baktığı yerde değil, kimsenin bakmadığı yerde durur.

İki Anlam, Aynı Mekanizma: Dosya Sunucusu ve Dizin

Shadow Admin iki farklı yerde karşımıza çıkar ve ikisi de aynı mantığa dayanır. Birincisi dosya sunucusudur: bir kullanıcı, bir paylaşım klasörü üzerinde onu yönetmeye yetecek bir izin taşır, ama hiçbir yönetici grubunda değildir. İkincisi Active Directory dizinidir: bir kullanıcı, ayrıcalıklı bir grup ya da hesap nesnesi üzerinde onu değiştirmeye yetecek bir izin taşır, yine hiçbir yönetici grubunda görünmeden.

Bu yazı önce dosya sunucusu tarafını sonuna kadar örer, çünkü orada mekanizma en çıplak hâliyle görülür ve sahadan gerçek bir vaka tam oradan geliyor. Dizin tarafını ise ayrı bir bölümde ele alırız; mantık birebir aynıdır, yalnız nesnenin türü değişir.

Yetki Nasıl Görünmez Olur? İzni Değiştirme Yetkisi

Gölge yöneticinin çekirdeğinde tek bir devir vardır: birine yetkinin kendisi değil, yetkiyi değiştirme yetkisi verilir. İmza sirküleri örneğine dönersek, bu iki ayrı şeydir. Birincisi, listede adınızın olması: imza atabilirsiniz. İkincisi, listeyi güncelleyen kalemin sizde olması: adınızı listeye kendiniz yazabilirsiniz. İkincisini eline geçiren, birincisine zaten sahiptir; çünkü istediği anda kendi adını ekler.

Windows dünyasında bu “listeyi güncelleyen kalem” bir izin adı taşır: Change Permissions (izinleri değiştirme), teknik karşılığıyla WriteDACL. Bir kullanıcıya bir klasör üzerinde bu izin verilmişse, o kullanıcı klasörün verisini okuyamıyor bile olsa, klasörün izin listesini yeniden yazabilir ve o listeye kendisi için tam erişim ekleyebilir. Erişimi almadı, erişimi belirleyen listeyi ele geçirdi.

Bu, mekanizmanın en sinsi yanını da açıklıyor: gölge yönetici, klasörü o an açamıyor olabilir. Denetime bakan biri “bu kullanıcının bu klasöre okuma izni yok” diye kaydeder ve içi rahat eder. Oysa okuma izninin olmaması bir güvence değildir; kullanıcı o izni kendisine bir komutla yazabiliyorsa, “şu an okuyamıyor” ile “istediği an okur” arasındaki mesafe sıfırdır.

İzni Değiştirme Hakkı Oraya Nasıl Geliyor?

Bu hakların çoğu kötü niyetle verilmez, sessizce oraya sızar ve nasıl sızdığını bilmek onları önlemenin ilk adımıdır. Üç yol ötekilerden daha sık görülür.

Birincisi kalıtımdır (inheritance): bir üst klasöre geniş bir izin verilir, altındaki bütün klasörler o izni sessizce devralır. Kök paylaşımda birine tanınan bir hak, kimsenin fark etmediği bir alt klasörde de yürürlüktedir.

İkincisi fazla cömert bir izin seviyesidir ve buradaki incelik önemli. Windows’ta bir kullanıcıya sık verilen Modify (değiştirme) seviyesi izinleri değiştirme hakkını içermez; onu içeren yalnızca Full Control’dür. Yani bir yardım masası personeline ya da bir gruba, Modify yeterken alışkanlıkla Full Control verildiğinde, kimsenin niyet etmediği “izinleri değiştirme” hakkı da o hesaba geçmiş olur.

Üçüncüsü ve en sinsisi sahipliktir (ownership). Bir nesnenin sahibi, izin listesinde hiç yazmasa bile o listeyi her zaman değiştirebilir; sahiplik, izin değiştirme hakkını örtük olarak taşır. Klasörü oluşturan kullanıcı sahibi olarak kaldığında, izin listesinde adı hiç görünmese de gölge yönetici olur. Bu, Get-Acl çıktısına bakan bir gözün bile kaçırabileceği tek durumdur, çünkü yetki bir izin satırında değil, nesnenin sahibi alanında saklıdır.

Neden Grup Üyeliği Raporu Bunu Kaçırır?

Kurumların ayrıcalıklı hesapları denetlerken ilk baktığı yer grup üyeliğidir ve bunun iyi bir sebebi vardır: orası merkezîdir, tek komutla listelenir ve çoğu yetki gerçekten oradan gelir. Sorun, bu raporun yalnızca grup üyeliğini görmesidir. Bir hesabın yetkisi bir nesnenin izin listesinden geliyorsa, o hesap Domain Admins çıktısında yoktur, çünkü gerçekten o grubun üyesi değildir.

Yani grup raporu yanlış değildir, eksiktir. Sorduğu soru “kim bu grupların üyesi?” sorusudur; oysa güvenlik açısından sorulması gereken soru “kim yönetici gibi davranabilir?” sorusudur. İkisi çoğu zaman aynı cevabı verir, ama gölge yönetici tam olarak ikisinin ayrıştığı yerde durur. Bu ayrımın sahada nasıl göründüğünü şimdi ölçülmüş bir örnekle görelim.

Sahada: Kendine Maaş Klasörünü Açan Kullanıcı

Şimdi mekanizmayı lafta bırakmayıp gösterelim. Aşağıdaki ölçüm, laboratuvar ortamındaki bir domain controller (Windows Server 2025) üzerinde yapıldı. Sahne, sahadan gelen gerçek bir vakanın birebir kurulumu: bir dosya sunucusunda maaş bordrolarını tutan bir klasör ve o klasör üzerinde yalnızca “izinleri değiştirme” hakkı verilmiş, hiçbir yönetici grubunda olmayan standart bir kullanıcı.

Kullanıcı bordro.op, standart bir Domain User. Klasör C:\Bordro, içinde bir maaş dosyası var. Kullanıcıya verilen izin şu:

icacls C:\Bordro

C:\Bordro NT AUTHORITY\SYSTEM:(OI)(CI)(F)
          BUILTIN\Administrators:(OI)(CI)(F)
          SISTEMKUSU\bordro.op:(OI)(CI)(Rc,WDAC,S)

Son satırdaki bordro.op izni, dosya sunucusundaki bütün meselenin özetidir. Kısaltmaları açalım:

• Rc (Read Permissions), izin listesini okuma hakkı: kullanıcı kimin ne erişimi olduğunu görebilir.
• WDAC (Write DAC), izin listesini değiştirme hakkı: yani “izinleri değiştirme”, WriteDACL. Mesele burada.
• S (Synchronize), teknik bir bayrak, güvenlik açısından önemsiz.

Dikkat edilecek şey burada olmayan izindir: R (okuma) ya da W (yazma) yok. Yani bordro.op maaş dosyasını açamaz. En azından şu an açamaz.

Beklenti, Ölçüm, Sonuç

Bu noktada denetime bakan birinin vereceği standart cevap şudur: “bu kullanıcının klasöre okuma izni yok, üstelik hiçbir yönetici grubunda değil, dolayısıyla veri güvende.” İkinci yarısını da ekleyelim, çünkü esas yanılgı orada: Domain Admins üyeleri sorulduğunda bordro.op gerçekten çıkmaz. Ölçtüm. Kullanıcının kendi bağlamında sırayla üç şey yaptım: maaş dosyasını okumayı denemek, kendine tam erişim yazmak, tekrar okumayı denemek.

whoami = SISTEMKUSU\bordro.op
1) OKUMA        -> ERİŞİM REDDEDİLDİ
2) SELF-GRANT   -> başarılı (kendine FullControl yazdı)
3) TEKRAR OKUMA -> OKUNDU: GIZLI: Genel Mudurluk maas bordrolari 2026

Üç satır, gölge yöneticinin bütün hikâyesini anlatıyor:

1. Başta okuma reddedildi. Kullanıcının veri okuma izni yoktu, sistem doğru şekilde kapıyı kapattı. Denetimin gördüğü ve güvendiği durum tam olarak bu.
2. Kendine tam erişim yazması başarılı oldu. Kullanıcı hiçbir yönetici yetkisi kullanmadı; yalnızca elindeki “izinleri değiştirme” hakkıyla, izin listesine kendisi için FullControl ekledi. Sistem bunu reddetmedi, çünkü kullanıcının bunu yapmaya hakkı vardı.
3. İkinci okuma başarılı oldu. Az önce kapalı olan kapı şimdi açık, çünkü kilidi belirleyen listeyi kullanıcının kendisi yeniden yazdı.

İşlem bittiğinde iznin son hâli şu; bordro.op artık kendi yazdığı tam erişimle orada:

SISTEMKUSU\bordro.op:(OI)(CI)(F)

Buradaki asıl öğretici nokta, “kullanıcı dosyayı okudu” değil. Asıl nokta, bunun hiçbir yönetici grubuna dokunmadan olmasıdır. Domain Admins listesi ölçümün başında neyse sonunda da odur; oraya bakan bir denetim, olan biteni hiç görmez. Yetki grup üyeliğinde değil, klasörün kendi izin listesinde saklıydı ve orada da kaldı.

Bu vakanın bir de hukuki yüzü var ve önemsenmeyecek gibi değil. Maaş bilgisi kişisel veridir; ona yetkisiz erişim, KVKK açısından bir güvenlik ihlalidir. Kanunun teknik tedbir yükümlülüğünü ve bunun sahadaki karşılığını KVKK teknik uyum yazımızda ele alıyoruz. Buradaki bağ şu: kurum yalnızca sızıntıdan değil, o erişime dair hiçbir kaydı bulunmadığı için savunmasız kalmasından da sorumludur.

Nasıl Tespit Edilir? Grup Raporu Değil, Etkin İzin Taraması

Gölge yöneticiyi bulmanın yolu, aradığınız yeri değiştirmekten geçer. Grup üyeliği raporu onu yapısı gereği kaçırır; onu yakalayan şey etkin izin taramasıdır, yani “kim hangi nesne üzerinde ne yapabilir?” sorusunu grup üyeliğinden değil, nesnelerin kendi izin listelerinden cevaplayan tarama. Farkı yan yana koyalım; aynı kullanıcı, iki farklı denetimde iki farklı sonuç veriyor.

Önce klasik yol, grup üyeliği raporu:

Get-ADGroupMember "Domain Admins" -Recursive | Select-Object SamAccountName

sistemkusuadm
ilker.pehlivan
svc-bckup-ops
da

Bu listede bordro.op yok. Klasik denetim burada durur ve “ayrıcalıklı hesaplar temiz” der.

Şimdi etkin izin taraması. Klasör ağacındaki her izin listesine bakıp, ayrıcalıklı olmayan bir hesabın “izinleri değiştirme”, “sahiplik alma” ya da “tam erişim” taşıdığı satırları çıkarıyoruz:

Get-ChildItem 'C:\' -Directory | ForEach-Object {
  (Get-Acl $_.FullName).Access | Where-Object {
    $_.AccessControlType -eq 'Allow' -and
    $_.FileSystemRights -match 'ChangePermissions|TakeOwnership|FullControl' -and
    $_.IdentityReference.Value -notmatch 'SYSTEM|Administrators|CREATOR OWNER|Domain Admins'
  } | Select-Object @{n='Klasör';e={$_.PSParentPath}}, IdentityReference, FileSystemRights
}

Klasör : C:\Bordro
IdentityReference  : SISTEMKUSU\bordro.op
FileSystemRights   : ReadPermissions, ChangePermissions, Synchronize

Aynı kullanıcı, ilk taramada yok, ikincisinde var. Fark, taramanın sorduğu sorudadır: birincisi “kim bu grubun üyesi?” diye sorar ve gölge yönetici üye olmadığı için görünmez; ikincisi “kim izinleri değiştirebilir?” diye sorar ve tam da bu hakkı taşıdığı için yakalanır. Aradığınız şey bir üyelik değil bir yetenek olduğunda, bakılacak yer grup değil nesnedir.

Bu taramanın tek başına görmediği bir durum var ve mekanizma bölümünde geçmişti: sahiplik. İzin listesi bir hesabı hiç saymasa bile, o hesap nesnenin sahibiyse listeyi yine değiştirebilir. Bu yüzden etkin izin denetimi izin satırlarına bakmakla bitmez, aynı taramada sahibi ayrıcalıklı olmayan bir hesap olan nesneleri de (Get-Acl çıktısındaki Owner alanı) ayrıca çıkarmak gerekir.

Bu iki soru arasındaki fark, bu makalenin tek cümlelik özeti sayılır: gölge yöneticiyi bir grup listesinde değil, bir yetki haritasında bulursunuz.

Active Directory Nesne İzinleri: Aynı Mantık Dizinde

Buraya kadar dosya sunucusundaydık. Aynı mekanizma Active Directory dizininde de birebir çalışır, yalnız nesnenin türü değişir: bir klasör yerine bir grup, bir kullanıcı hesabı ya da bir dizin bölümü. Terimin literatürdeki asıl kökeni de burasıdır; “shadow admin” ilk kez dizin nesnelerinin izin listeleri üzerinden tarif edildi.

Mekanizma aynı olduğu için tekrarını yazmaya gerek yok, yalnız karşılıklarını verelim. Dosya sunucusundaki “izinleri değiştirme” hakkının dizindeki karşılıkları şunlardır: bir nesne üzerinde tam denetim (GenericAll), izin listesini yazma (WriteDacl), sahipliği alma (WriteOwner), bir grubun üyeliğini değiştirme (WriteProperty member) ya da bir hesabın parolasını sıfırlama. Bunlardan birini ayrıcalıklı bir nesne üzerinde taşıyan hesap, o gruba üye olmadan grubun kapısını açabilir; tıpkı klasörde olduğu gibi.

Dizinde bu hakların en sık kaynağı yetki devridir (delegation). Bir OU üzerinde birine kullanıcı yönetme yetkisi vermek meşru ve gerekli bir işlemdir; yetki modelinin doğru kurulmasını Active Directory kullanıcı, grup ve OU yönetimi yazısında ele alıyoruz. Sorun, devrin kapsamının zamanla genişlemesi ya da geri alınması unutulan bir yetkinin ayrıcalıklı bir nesneye dokunacak kadar uzanmasıdır. Bir grup nesnesinin izin listesini de aynı Get-Acl mantığıyla, dizin sürücüsü üzerinden okuyabilirsiniz:

$dn = (Get-ADGroup "Domain Admins").DistinguishedName
(Get-Acl "AD:\$dn").Access | Where-Object {
  $_.AccessControlType -eq 'Allow' -and
  $_.ActiveDirectoryRights -match 'GenericAll|WriteDacl|WriteOwner|WriteProperty'
} | Select-Object IdentityReference, ActiveDirectoryRights

Bu taramanın bir inceliği var ve atlanırsa yanlış alarma yol açar: dizindeki ayrıcalıklı nesnelerin izin listesinde varsayılan olarak bulunan, sistemin kendi işleyişi için gereken haklar vardır. Denetimin işi, bu varsayılanları elemek ve geriye kalan, yani oraya sonradan ve elle eklenmiş olanı ayırt etmektir. Kısaca: dizin tarafında ham çıktı tek başına suçlama değildir, elenmiş çıktı ipucudur.

Nasıl Önlenir? En Az Yetki ve İzin Devrinin Denetimi

Gölge yöneticiyi tespit etmek, onu bulduktan sonra ne yapacağınızı bilmek demek değildir. Kalıcı çözüm tespitte değil, o yetkinin hiç birikmemesini sağlayan disiplindedir ve üç ayağı vardır.

Birincisi en az yetki ilkesidir: bir hesaba, işini yapması için gereken en dar izin verilir, “ihtiyaç olursa dursun” diye fazlası değil. İzinleri değiştirme, sahiplik alma ve tam erişim gibi haklar, ihtiyaç kanıtlanmadıkça hiçbir standart kullanıcıya verilmez.

İkincisi yetki devrinin süreli olmasıdır: bir proje ya da ihtiyaç için verilen izin, o ihtiyaç bitince geri alınır; verildiği gün silineceği tarihi de yazılmayan izin, kalıcı izindir. Üçüncüsü periyodik etkin izin denetimidir: yukarıdaki taramaların düzenli aralıklarla çalıştırılması, çünkü izinler bir kez temizlenmekle temiz kalmaz, zamanla yeniden birikir.

Bu disiplin daha geniş bir çerçevenin parçasıdır. Ayrıcalıklı hesapların bütününü sıkılaştırmayı, katmanlı yönetici modelini ve korunan grupların denetimini Active Directory güvenlik sıkılaştırması yazısında ele alıyoruz. Orada anlatılan AdminSDHolder mekanizması tam da bu makalenin kör noktasına oturur ve ilişkiyi netleştirmek gerekir: AdminSDHolder, Domain Admins gibi korunan grupların izin listesini düzenli olarak varsayılan şablona geri yazar, yani o grupların ACL’ine yapılan yetkisiz eklemeleri temizler.

Ama koruduğu şey grubun kendi nesnesidir; grubun dışındaki bir klasörün ya da sıradan bir kullanıcının izin listesini görmez. Yani AdminSDHolder ayrıcalıklı grubu korurken, ayrıcalıklı grupta hiç görünmeyen gölge yöneticiye dokunmaz. İkisi komşu iki iştir: biri listeyi temiz tutar, öteki listede hiç olmayanı arar.

Aynı denetim disiplini bir standardın da gereğidir. ISO 27001 ayrıcalıklı erişim haklarının kısıtlanmasını ve düzenli gözden geçirilmesini ayrı bir kontrol olarak sayar; etkin izin taraması, o kontrolün kâğıt üzerinde değil sahada yapılmış hâlidir.

Sonuç: Shadow Admin’i Grup Listesi Değil İzin Taraması Bulur

Shadow Admin, yeni bir saldırı türü değil, eski bir denetim boşluğunun adıdır. Kurumlar ayrıcalığı grup üyeliğiyle ölçmeye alışkındır, çünkü orası merkezî ve görünürdür. Oysa yetki, bir grubun üyeliğinde durabildiği gibi tek tek nesnelerin izin listelerinde de durur ve orada durduğunda hiçbir grup raporunda görünmez.

Bu yüzden doğru soru “yöneticilerimiz kimler?” değil, “kim yönetici gibi davranabilir?” sorusudur. İlkini grup listesi cevaplar; ikincisini yalnızca nesnelerin izin listelerine bakan bir etkin izin taraması cevaplayabilir. Aradaki fark, imza sirkülerindeki isimlerle o belgeyi güncelleyebilen kalem arasındaki farktır: birini görürsünüz, ötekini görmek için bakmayı bilmeniz gerekir.

Yazan İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştürür. Buradaki rehberleri kendi laboratuvarında kurup ölçerek yazar.

LinkedIn