Erişim Gözden Geçirme Kanıtı: Periyodik Yetki Kontrolü Nasıl Belgelenir?

Erişim gözden geçirmesi, BGYS ve ITGC denetimlerinde neredeyse her seferinde örneklem alınan kontroldür; bulgu da en çok burada çıkar. Sebep çoğu zaman gözden geçirmenin hiç yapılmaması değildir. Yapılmıştır ama denetçi izini süremez: liste nereden geldi, kim baktı, “kaldırılsın” denen hesap gerçekten kapandı mı? Aşağıda kaynak rapordan aksiyon kapanışına kadar zinciri, denetçinin yeniden izleyebileceği biçimde nasıl kuracağınızı anlatıyoruz.

Erişim gözden geçirmesi neden sık bulgu konusu olur?

ISO/IEC 27001:2022 Ek A’da A.5.18 (Erişim hakları) erişim haklarının düzenli aralıklarla gözden geçirilmesini, A.8.2 (Ayrıcalıklı erişim hakları) ayrıcalıklı yetkilerin kısıtlanmasını ve yönetilmesini, A.5.3 ise görevler ayrılığını ele alır. ITGC tarafında aynı konu erişim kontrolleri başlığında test edilir; çerçevenin geneli için ITGC kontrolleri rehberine bakın. Denetçi iki şeye bakar: gözden geçirmenin tasarımına (kapsam, sıklık, sorumlu) ve dönem içinde gerçekten işletilip işletilmediğine. İkincisi daha zordur.

Sahada bulguya dönüşen tablo hemen hep aynıdır:

• Gözden geçirilen liste, kaynağı ve çekilme tarihi belli olmayan bir Excel dosyasıdır.
• BT yöneticisi kendi yönetici hesabını kendisi onaylamıştır.
• Formda “kaldırılsın” yazan hesap aylar sonra hâlâ aktiftir.
• Kapsamda yalnız Active Directory vardır; ERP, SaaS uygulamaları ve ağ cihazları unutulmuştur.
• Servis ve paylaşımlı hesaplar “kişiye ait değil” denerek listeden çıkarılmıştır.

Kapsam: hangi sistemler, hangi hesaplar?

Kapsamı varlık envanterindeki kritik sistemlerden türetin ve erişim kontrol politikasına yazın. Politikanın bu bölümünü nasıl kuracağınız erişim kontrol politikası yazım rehberinde ayrıntılı anlatılıyor. Aşağıdaki tablo orta ölçekli bir kuruluş için örnek çerçevedir; sıklıklar örnektir, kendi risk değerlendirmenize göre belirlenir.

Sistem	Kaynak rapor	Gözden geçiren	Örnek sıklık
Active Directory / Entra ID	Kullanıcı ve grup üyeliği dışa aktarımı	Birim yöneticileri; yönetici grupları için BGYS sorumlusu	6 ay; ayrıcalıklı gruplar 3 ay
ERP	Kullanıcı–rol ataması raporu	Süreç sahibi (finans, satın alma, üretim)	6 ay
SaaS (CRM, M365 yönetici rolleri)	Uygulamanın kullanıcı/rol dışa aktarımı	Uygulama sahibi	6 ay
Veritabanı ve sunucu yerel yöneticileri	Yerel grup ve DB rol listesi	BT yöneticisi dışında bir onaylayıcı	3 ay
Firewall, switch, hipervizör	Yerel kullanıcı ve AAA rol listesi	Altyapı sorumlusu + BGYS	3 ay

Hesap türlerini de tek tek yazın: kişisel hesaplar, ayrıcalıklı yönetici hesapları, servis hesapları, paylaşımlı veya ortak hesaplar, misafir ve tedarikçi hesapları, devre dışı bırakılmış ama silinmemiş hesaplar. Sonuncusu masum görünür. Değildir. Devre dışı hesap grup üyeliklerini korur; biri onu yeniden etkinleştirdiğinde eski yetkilerin hepsi geri gelir.

Kaynak raporun bütünlüğü ve tarihlenmesi

Denetçi, gözden geçirmenin dayandığı listeye güvenmek zorundadır. Kuruluşun ürettiği raporun eksiksiz ve doğru olduğunu göstermek, denetim literatüründe “kuruluş tarafından üretilen bilgi” (IPE) testinin konusudur. Sahadaki karşılığı basit: rapor hangi sistemden, hangi sorguyla, kim tarafından, ne zaman alındı — kayıtlı olacak. Gözden geçirene gittikten sonra da kimse dosyaya dokunmayacak.

Active Directory için tekrar üretilebilir bir dışa aktarım örneği (ActiveDirectory PowerShell modülü gerekir):

Get-ADUser -Filter * -Properties Enabled,LastLogonDate,whenCreated,Department,Manager |
  Select-Object SamAccountName,Name,Enabled,LastLogonDate,whenCreated,Department,Manager |
  Export-Csv -Path .\AD_Kullanicilar_2026-Q3.csv -NoTypeInformation -Encoding UTF8

Get-ADGroupMember -Identity "Domain Admins" -Recursive |
  Select-Object SamAccountName,objectClass |
  Export-Csv -Path .\AD_DomainAdmins_2026-Q3.csv -NoTypeInformation -Encoding UTF8

Get-FileHash -Path .\AD_*_2026-Q3.csv -Algorithm SHA256 |
  Export-Csv -Path .\AD_hash_2026-Q3.csv -NoTypeInformation

Komut metnini, çalıştırma tarihini ve hash değerlerini kayda alın; hash dosyasını kanıt klasöründen ayrı bir konumda ya da ilgili bilet kaydında saklayın. Böylece denetçi raporu yeniden üretebilir ve sonradan değişmediğini görür. Bir tuzak var: LastLogonDate, etki alanı denetleyicileri arasında çoğaltılan lastLogonTimestamp özniteliğinden gelir ve varsayılan güncelleme aralığı yüzünden gerçek son oturumun yaklaşık 9–14 gün gerisinde kalabilir. “Kullanılmayan hesap” kararını kesin bir tarihe bağlıyorsanız bu sınırı forma not düşün.

Eksiksizlik için mutabakat yapın. Rapordaki toplam kullanıcı sayısını sistemdeki sayıyla, aktif kullanıcı listesini İK’nın aynı tarihli aktif personel listesiyle karşılaştırın. İK listesinde karşılığı olmayan her aktif kişisel hesap ya bir açıklamaya (tedarikçi, stajyer) ya da kaldırma aksiyonuna bağlanır. Üçüncü seçenek yok.

Gözden geçiren kim olmalı? Görevler ayrılığı

Gözden geçiren, kullanıcının o yetkiye iş gereği ihtiyacı olup olmadığını bilen kişidir. Bu çoğunlukla BT değil, birim yöneticisi veya uygulama sahibidir. BT raporu üretir, teknik rol adlarını anlaşılır hale getirir ve kararları uygular. Denetimde doğrudan sorgulanan kurallar şunlar:

• Kimse kendi hesabının yetkisini onaylamaz; BT yöneticisinin ayrıcalıklı hesabına bir üst yönetici veya BGYS sorumlusu bakar.
• Yetkiyi atayan ile gözden geçiren aynı kişi olmaz; küçük ekipte bu mümkün değilse bağımsız bir ikinci kontrol tanımlanır.
• ERP’de çatışan rol kombinasyonları (örneğin tedarikçi kaydı oluşturma ve ödeme onayı) formda ayrı sütunda işaretlenir.

Kararların ve kaldırılan yetkilerin kanıtlanması

Formun her satırında bir karar olmalı: koru, kaldır veya değiştir. “Kaldır” ve “değiştir” bir değişiklik ya da hizmet talebi numarasına bağlanır. Yüzlerce satırın topluca “uygun” işaretlenmesi denetçinin gözüne ilk takılan şeydir. Hiç kaldırma kararı çıkmayan gözden geçirme de aynı soruyu doğurur.

Denetimde sorun çıkarmayan kanıt paketi şu sırayla dizilir:

1. Kapsam ve dönem tanımı: hangi sistemler, hangi tarih, hangi politika maddesi.
2. Kaynak rapor, rapor sorgusu ve hash kaydı.
3. Satır bazında karar ve gerekçe içeren gözden geçirme formu.
4. Gözden geçirenin onay kaydı (iş akışı onayı veya tarihli e-posta).
5. Kaldırma ve değişiklikler için talep kayıtları ve kapanış tarihleri.
6. Aksiyonlardan sonra yeniden alınan, kaldırılan yetkilerin artık bulunmadığını gösteren doğrulama raporu.

Altıncı adım en sık atlanandır ve kontrolün çalıştığını gösteren asıl kanıt odur. Kaldırma talebi açılmış olabilir; hesap yine de duruyor olabilir. Microsoft Entra ID Governance içindeki Access Reviews özelliği kararı ve gözden geçireni sistemde kaydeder, sonucu otomatik uygulayabilir; lisans gereksinimini güncel Microsoft dokümantasyonundan doğrulayın. Bu paketin kanıt matrisindeki yerini kanıt matrisi rehberindeki eşleme yöntemiyle tanımlayabilirsiniz.

Ayrıcalıklı ve servis hesapları için ek adımlar

Ayrıcalıklı hesaplara daha sık bakılır ve yalnız hesabın varlığına değil, kullanım şekline de bakılır. Active Directory’de Domain Admins, Enterprise Admins, Schema Admins ve Administrators gruplarını iç içe üyelikleriyle (-Recursive) inceleyin. Sahada en sık gözden kaçan nokta budur: doğrudan üye olmayan ama iç içe bir grup üzerinden yönetici yetkisi alan hesap. Konsolda ilk bakılacak yer de orasıdır. ERP’de tüm yetkiyi veren profiller (örneğin SAP’de SAP_ALL) ve acil durum erişimi kullanıldıysa o oturumların log incelemesi ayrıca belgelenir. Teknik sıkılaştırma tarafı için Active Directory güvenlik kontrolleri yazısı tamamlayıcıdır.

Servis hesapları için forma şu sütunları ekleyin: sorumlu kişi, kullanan uygulama, etkileşimli oturum açma izni, parolanın son değişim tarihi (PasswordLastSet) ve sahip olduğu gruplar. Sahibi bulunamayan servis hesabı tek başına bulgudur. Kimse sahiplenmiyorsa kimse de kapatamaz. Mümkün olan yerlerde parolası sistem tarafından yönetilen grup yönetilen hizmet hesaplarına (gMSA) geçin; parola yaşı sorusu formdan tamamen kalkar.

Gözden geçirmenin formaliteye dönüşmesini önlemek

Her dönem “imza at, geç” düzeyine inen bir gözden geçirme kâğıt üzerinde çalışır, riski azaltmaz. Aşağıdaki belirtiler, BGYS ekibinin dönem sonunda kendi kalite kontrolünü yapması için kullanılabilir:

Belirti	Önlem
Yüzlerce satır dakikalar içinde onaylanmış	Onay süresini izleyin; listeyi yöneticinin ekibine göre bölün
Hiçbir dönemde kaldırma kararı yok	BGYS ekibi küçük bir örneklemi bağımsız olarak yeniden değerlendirsin
Yönetici rol adlarını anlamıyor	Raporda teknik rol adının yanına iş dilinde açıklama ekleyin
Her dönem aynı tür hatalar çıkıyor	İşe giriş, görev değişikliği ve çıkış sürecinde kök neden arayın

Bağımsız yeniden değerlendirmede örneklem büyüklüğünü ve seçim yöntemini iç denetimde örneklem seçimi rehberindeki ilkelere göre belirleyin. Bu döngüyü dışarıdan bağımsız bir gözle test ettirmek isterseniz erişim yetkileri ve kullanıcı hesabı denetimi ile ITGC denetim hazırlığı hizmetlerimiz tam bu alana bakar.

Kontrol listesi

• Kapsamdaki sistemler ve hesap türleri politikada yazılı.
• Her sistem için sıklık ve gözden geçiren rolü tanımlı.
• Kaynak rapor sorgusu, çekilme tarihi ve hash değeri saklanıyor.
• Rapor, İK aktif personel listesiyle mutabık.
• Hiç kimse kendi yetkisini onaylamadı.
• Her satırda karar ve gerekçe var; kaldırmalar talep numarasına bağlı.
• Aksiyon sonrası doğrulama raporu alındı.
• Ayrıcalıklı gruplar iç içe üyelikleriyle incelendi.
• Servis hesaplarının sahibi ve amacı kayıtlı.
• Gecikmiş veya eksik dönem varsa nedeni ve telafisi kayıtlı.

Sık sorulan sorular

Erişim gözden geçirmesi ne sıklıkla yapılmalı?

ISO 27001 sabit bir sıklık vermez; A.5.18 düzenli aralıklarla gözden geçirme ister, aralığı risk değerlendirmesi ve erişim kontrol politikası belirler. Yaygın uygulama, ayrıcalıklı hesaplar ve kritik sistemler için daha kısa (örneğin üç aylık), diğerleri için altı aylık veya yıllık döngüdür. Denetimde asıl sorgulanan, politikaya yazdığınız sıklığa her dönem uyup uymadığınızdır.

Yöneticinin e-postayla “uygundur” yazması yeterli kanıt mı?

Tek başına genellikle yetmez. E-postanın hangi raporu, hangi tarihte, hangi kapsamla onayladığı belli olmalı; satır bazında koru veya kaldır kararı bulunmalı ve kaldırılan yetkilerin gerçekten kaldırıldığı ayrı bir kayıtla gösterilmelidir. Karar formunu ve kaynak raporu ekinde taşıyan e-posta onay kaydı olarak işe yarar.

Gözden geçirmede ayrılmış bir personelin aktif hesabı çıkarsa bu bir uygunsuzluk mudur?

Gözden geçirmenin hesabı yakalaması kontrolün çalıştığını gösterir; hesabın ayrılıştan beri açık kalması ise işten çıkış sürecinde bir açık olduğunu. Denetçi hesabın ayrılıştan sonra kullanılıp kullanılmadığını sorar. Son oturum bilgisini ve ilgili logları inceleyip sonucu kayda geçirin, işten çıkış sürecini de düzeltici faaliyet olarak ele alın.

Microsoft Entra Access Reviews gibi araçların çıktısı kanıt olarak kabul edilir mi?

Evet. Sistem tarafından üretilen ve gözden geçirenin kararını zaman damgasıyla saklayan kayıtlar güçlü kanıttır. Yine de aracın kapsamadığı sistemleri (ERP, yerel yönetici hesapları, ağ cihazları) ayrıca ele almanız ve kararların hedef sistemde uygulandığını doğrulamanız gerekir.