Ekran Görüntüsü mü Sistem Raporu mu? Kanıt Türleri ve Güvenilirlik

Aynı kontrol için hazırlanmış iki kanıttan biri denetçiyi tek bakışta ikna eder, diğeri ek soruya ve canlı gösterim talebine yol açar. Fark çoğu zaman içerikte değil, kanıtın türündedir ve kendini ne kadar açıkladığındadır. Tarihi, sunucu adı ve filtresi görünmeyen bir ekran görüntüsü, denetçinin gözünde bir iddiadır. Aşağıda kanıt türlerini güvenilirlik ve tekrar üretilebilirlik açısından karşılaştırıyor; geçerli ekran görüntüsünün unsurlarını, dışa aktarılan raporun bütünlüğünü ve kişisel veri içeren kanıtların maskelenmesini anlatıyoruz.

Kanıt türleri ve güvenilirlik sıralaması

ISO 19011:2018, denetim ilkeleri arasında kanıta dayalı yaklaşımı sayar: denetim sonucu doğrulanabilir bilgiye dayanmalıdır. Finansal denetimde kullanılan ISA 500 standardı da benzer genel ilkeler verir: bağımsız kaynaktan gelen kanıt kuruluş içi kanıttan, denetçinin doğrudan elde ettiği kanıt dolaylı kanıttan, belgeye dayalı kanıt sözlü beyandan daha güvenilirdir. Bu ilkeleri BGYS denetimlerindeki tipik kanıt türlerine uyguladığımızda şu tablo çıkar:

Kanıt türü	Güvenilirlik	Tekrar üretilebilirlik	Tipik kullanım
Sistem raporu / dışa aktarım	Yüksek	Yüksek (aynı sorguyla)	Kullanıcı listesi, yedekleme iş geçmişi
Yapılandırma çıktısı	Yüksek	Yüksek	Parola politikası, SSH ayarı, firewall kuralı
Sistem tarafından üretilen kayıt	Yüksek	Orta	Log, iş akışı onayı, bilet geçmişi
Elle tutulan kayıt	Orta	Düşük	Ziyaretçi defteri, Excel takip listesi
Ekran görüntüsü	Orta–düşük	Düşük	Raporu alınamayan ayarlar
Gözlem	Yüksek (o an için)	Yok	Temiz masa, kapı kontrolü
Görüşme	Destekleyici	Yok	Farkındalık, süreç bilgisi

Görüşme tek başına bir kontrolü kanıtlamaz; diğer kanıtları doğrular ya da sorgulatır. Hangi kontrol için hangi türün birincil kanıt olacağını kanıt matrisinde önceden belirleyin. Denetim günü tür tartışması yapılmaz.

Gözlem ve görüşme nasıl kayda geçer?

Gözlem ve görüşme denetçinin kendi elde ettiği kanıtlardır; kuruluşun dosya olarak sunduğu bir şey değildir. Yine de kuruluş bu kanıtların oluşmasını kolaylaştırabilir. Saha turunda gözlenen kontrollerin (kilitli kabin, refakatli ziyaretçi, ekran kilidi) dayandığı kayıtları hazır tutun; denetçi gözlemini bir kayıtla eşleştirebildiğinde bulgu riski düşer. Görüşmede çalışanın anlattığı süreç, yazılı prosedür ve sistem kaydıyla tutarlı olmalıdır. Prosedürde iki onay yazarken çalışanın tek onayla işlem yaptığını söylemesi gibi bir çelişki, denetçinin en çok derinleştiği noktadır. Aynı üçlü karşılaştırmayı iç denetimde kendiniz yapın; çelişkiyi denetçiden önce yakalarsınız.

Ekran görüntüsünün sınırları

Ekran görüntüsü hızlı ve her sistemde alınabildiği için en çok kullanılan kanıttır. Dört yapısal zayıflığı var:

• Anlıktır: Ayarın o saniyedeki durumunu gösterir; dönem boyunca böyle olduğunu göstermez. İşletim etkinliği için tek başına yetmez.
• Bağlamı eksiktir: Hangi sunucu, hangi kiracı, hangi filtreyle alındığı çoğu zaman görünmez.
• Kapsamı belirsizdir: Kaydırma gerektiren bir listenin yalnızca ilk sayfası görünür.
• Değiştirilmesi kolaydır: Görüntü iz bırakmadan düzenlenebilir; denetçi bunu bilir.

Tasarım ve işletim etkinliği ayrımı için kontrol etkinliği testi yazısına bakın. Pratik karşılığı şu: ekran görüntüsü çoğu zaman tasarımı gösterir. İşletimi göstermek için dönem içinde tekrarlanan kayıtlar gerekir.

Geçerli bir ekran görüntüsünün unsurları

Ekran görüntüsü kaçınılmazsa, kendi başına anlaşılır olacak şekilde alın. Denetimde soru doğurmayan bir ekran görüntüsü şunları taşır:

1. Tarih ve saat: Tercihen uygulamanın kendi zaman bilgisi; yoksa görev çubuğu saati görünür olmalı. Saatin güvenilirliği, ISO 27001 Ek A’daki A.8.17 (Saat senkronizasyonu) kontrolüne dayanır.
2. Kaynak: Adres çubuğu, sunucu adı, kiracı adı veya cihaz adı görünür olmalı.
3. Kimlik: Oturum açmış kullanıcı görünüyorsa kimin aldığı da anlaşılır.
4. Filtre ve parametreler: Liste filtrelenmişse filtre alanı ekranda kalmalı.
5. Kırpılmamış pencere: Bağlamı koparan kırpmalar şüphe uyandırır.
6. Açıklayıcı dosya adı ve not: Kontrol, sistem, tarih ve alan kişiyi taşıyan bir ad; örneğin A8.13_Yedekleme_SRV-FS01_2026-10-14_mkaya.png.

Sistem raporu ve yapılandırma çıktısının avantajları

Yapılandırma çıktısı ekran görüntüsünden hem daha eksiksiz hem de tekrar üretilebilirdir: denetçi aynı komutun canlı oturumda çalıştırılmasını isteyerek sonucu doğrular. Çıktının başına sistem adı ve tarih eklemek, ekran görüntüsündeki bağlam sorununu da çözer.

# Linux: SSH sunucusunun geçerli (etkin) ayarları, sistem adı ve UTC tarihle
{ hostname; date -u +%Y-%m-%dT%H:%M:%SZ; sudo sshd -T | grep -Ei '^(passwordauthentication|permitrootlogin|pubkeyauthentication) '; } > sshd_kanit.txt
sha256sum sshd_kanit.txt

# Windows: etki alanı parola politikası ve denetim ilkesi
Get-ADDefaultDomainPasswordPolicy | Out-File .\parola_politikasi.txt
auditpol /get /category:* > .\denetim_ilkesi.txt
Get-FileHash .\parola_politikasi.txt, .\denetim_ilkesi.txt -Algorithm SHA256

# Cisco IOS: VTY hatlarının yapılandırması
show running-config | section line vty

sshd -T yapılandırma dosyasını değil, include’lar ve varsayılanlar dahil sunucunun fiilen uyguladığı ayarları gösterir. Bu yüzden dosyanın kendisinden daha güçlü kanıttır. Sahada sık rastlanan durum: sshd_config içinde PasswordAuthentication no yazar, ama sshd_config.d altındaki bir dosya onu ezer; dosyayı gösteren ekran görüntüsü yanlış bilgi verir, sshd -T vermez. Komut root yetkisi ister; yapılandırmada Match blokları varsa belirli bir kullanıcı veya kaynak için geçerli ayarı görmek üzere -C user=…,host=…,addr=… parametresiyle çalıştırın. Aynı mantıkla yedekleme yazılımının iş geçmişi raporu, tek bir başarılı iş ekranından çok daha fazlasını kanıtlar; bu konu yedekleme ve geri yükleme denetim kanıtları yazısında ayrıntılı işleniyor.

Kanıtın bütünlüğü: tarih, kaynak, değiştirilemezlik

Bütünlük, kanıtın oluşturulduğu andan denetime sunulduğu ana kadar değişmediğinin gösterilebilmesidir. Kontrolün önemine göre artan düzeylerde önlem alınabilir:

• Sürüm geçmişi ve erişim kaydı tutan depo: Çoğu kanıt için yeterlidir; SharePoint gibi platformlarda sürüm geçmişi ve saklama etiketleri bu işi görür.
• Kriptografik özet (hash): Dosya oluşturulduğunda alınan SHA-256 değeri ayrı bir kayda yazılır; sonradan aynı hesaplama yapılarak dosyanın değişmediği gösterilir. Windows’ta Get-FileHash, Linux’ta sha256sum kullanılır.
• Zaman damgası: Bir dosyanın belirli bir anda var olduğunu bağımsız bir otoriteyle kanıtlamak için RFC 3161 zaman damgası protokolü kullanılır. Türkiye’de 5070 sayılı Elektronik İmza Kanunu kapsamındaki elektronik sertifika hizmet sağlayıcıları zaman damgası hizmeti sunar.

Hash değerini kanıtla aynı klasörde ve aynı yetkiyle saklamak, işe yaramaz bir önlemdir: dosyayı değiştirebilen kişi hash’i de değiştirebilir. Hash kaydını ayrı bir konumda veya bilet kaydında tutun. Kanıt deposunun yapısı ve izinleri için SharePoint ile denetim kanıt yönetimi hizmeti, log tabanlı kanıtların merkezi toplanması için loglama, izleme ve denetim kanıtı yönetimi hizmeti ilgilidir.

Kişisel veri içeren kanıtların maskelenmesi

Kullanıcı listeleri, erişim kayıtları, ziyaretçi defterleri ve olay kayıtları kişisel veri içerir. 6698 sayılı KVKK’nın işlendikleri amaçla bağlantılı, sınırlı ve ölçülü olma ilkesi, denetçiye kontrolü doğrulamak için gereken veriden fazlasının gösterilmemesini gerektirir. Pratik kurallar:

• Orijinal kanıtı değiştirmeyin; maskeli kopyayı ayrı üretin ve hangi orijinalden türediğini kaydedin.
• Önce sütun azaltın: TC kimlik numarası veya telefon kontrol için gerekli değilse çıkarın.
• Kısmi maskeleme kaydın tekilliğini korur (örneğin sicil numarasının son dört hanesi).
• Maskeleme kanıtın değerini bozmamalı; erişim gözden geçirmesinde kişi ile rol ilişkisi görünür kalmalı.
• PDF’de metnin üzerine siyah kutu çizmek metni silmez; alttaki metin kopyalanabilir. Gerçek redaksiyon özelliği olan bir araç kullanın veya veriyi kaynağında çıkarın.

Son madde sahada en çok yakılan noktadır. Siyah kutu, maskeleme değildir.

Kanıt türü seçimi için karar tablosu

Kontrol sorusu	Birincil kanıt	Destekleyici kanıt
Parola politikası yapılandırıldı mı?	Yapılandırma çıktısı	GPO raporu, ekran görüntüsü
Yedekler dönem boyunca alındı mı?	İş geçmişi raporu	Geri yükleme testi kaydı
Erişimler gözden geçirildi mi?	İş akışı kaydı ve kaynak rapor	Kaldırma talepleri
Loglar merkezi toplanıyor mu?	SIEM sorgu sonucu	Kaynak listesi, saklama ayarı
Ziyaretçiler kaydediliyor mu?	Ziyaretçi kaydı	Gözlem
Personel olay bildirimini biliyor mu?	Görüşme	Eğitim kaydı, olay bildirim kayıtları

Erişim gözden geçirmesinin kanıt paketinin nasıl kurulacağı erişim gözden geçirme kanıtı rehberinde ayrıca anlatılıyor. Genel kural basit: birincil kanıt tekrar üretilebilir olmalı; ekran görüntüsü yalnız raporu alınamayan bilgiler için ve kendi başına anlaşılır biçimde kullanılmalı.

Sık sorulan sorular

Denetçi ekran görüntüsünü kabul etmek zorunda mı?

Hayır. Denetçi kanıtın yeterli ve güvenilir olup olmadığına mesleki muhakemesiyle karar verir. Tarih, kaynak ve bağlam içermeyen bir ekran görüntüsü reddedilebilir ya da denetçi aynı bilginin canlı sistemde gösterilmesini isteyebilir. Ekran görüntüsünü mümkünse bir rapor veya yapılandırma çıktısıyla destekleyin; kabul olasılığı artar.

Her kanıt dosyası için hash veya zaman damgası gerekir mi?

Gerekmez; kontrolün kritikliğine göre karar verin. Çoğu kanıt için sürüm geçmişi ve erişim kaydı tutan bir doküman deposu yeterli bütünlük sağlar. Hash değeri, raporun gözden geçirmeye gönderildikten sonra değişmediğini göstermek gereken erişim gözden geçirmesi gibi durumlarda; nitelikli zaman damgası ise hukuki uyuşmazlık riski olan kayıtlarda işe yarar.

Kişisel veri içeren bir raporu denetçiye nasıl göstermeliyim?

Orijinali değiştirmeden saklayın; denetçiye kontrolü doğrulamak için gereken sütunları ve satırları içeren maskeli bir kopya sunun. Maskeli kopyanın hangi orijinalden üretildiğini dosya adı ve not ile ilişkilendirin. Denetçi tek bir kaydı doğrulamak isterse ilgili satır orijinalden kontrollü olarak gösterilebilir.

Elle tutulan Excel kayıtları zayıf kanıt mı sayılır?

Kendiliğinden geçersiz değildir, ama değiştirilmesi kolay olduğu için güvenilirliği sistem kaydına göre düşüktür. Dosyayı sürüm geçmişi tutan bir depoda saklamak, satırlarda tarih ve kaydı yapan kişiyi bulundurmak ve mümkünse kaynak sistemle örneklem bazında karşılaştırmak kanıt değerini artırır.