İçindekiler
Denetim tarihinin belli olması iyi haber sayılmaz. Çoğu kurumda o tarih, birkaç kişinin haftalarca ekran görüntüsü toplayacağı bir dönemin başlangıcıdır. Oysa denetimin istediği bilgi zaten kurumda vardır. Sorun bilginin yokluğu değil, kanıt haline getirilmesinin elle yapılmasıdır.
Denetim Hazırlığı Neden Projeye Dönüşür
Denetçi genellikle örneklem üzerinden ilerler: geçen yıl üretime giden değişikliklerden yirmi tanesini seçer ve her biri için aynı soruları sorar. Kim istedi, hangi kurala göre onaya gitti, kim onayladı, ne çalıştı, çalışan metin onaylanan metin miydi, sonuç ne oldu.
Bu soruların cevabı bilet sisteminde, dağıtım hattında, veritabanı günlüğünde ve e-postada ayrı ayrı durduğunda, her örnek için ayrı bir araştırma yapılır. Yirmi örnek yirmi araştırma demektir. Üstelik ortaya çıkan kanıt paketi ekran görüntülerinden oluşur ve denetçi haklı olarak sorar: bu görüntü ne zaman alındı, alındıktan sonra değişmiş olabilir mi?
Ekran görüntüsü neden zayıf kanıttır
Ekran görüntüsü, görüntüyü alan kişinin beyanıdır. Ne zaman alındığı, hangi filtrelerle alındığı ve alındıktan sonra düzenlenip düzenlenmediği görüntüden anlaşılmaz. Denetçi bunu reddetmez ama zayıf kanıt olarak işaretler ve daha fazla örnek ister. Kanıtın zayıflığı, denetimin süresini uzatan asıl nedendir.
Kanıt Dosyasında Ne Bulunmalı
Bir talebin kanıt dosyası, o talebin tüm yaşam döngüsünü tek dosyada anlatmalıdır. Denetçinin ek soru sormak zorunda kalmaması için şu kalemler bulunmalıdır.
- Talep kimliği ve bilet numarası. Kurumsal değişiklik kaydıyla bağ burada kurulur.
- Betiklerin tam metni. Özet değil, çalıştırılan metnin kendisi.
- Betik bütünlüğü durumu. Çalıştırma anında hesaplanan özet ile bugünkü metnin özeti karşılaştırılır: metin aynı mı, değişmiş mi, yoksa hiç çalıştırılmamış mı.
- Risk değerlendirmesi ve gerekçesi. Bandı hangi kuralın belirlediği yazılı olmalıdır.
- O gün yürürlükte olan kural seti. Sonradan yapılan politika değişiklikleri geçmiş kararı belirsizleştirmemelidir.
- Onay adımları. Her adımı kimin, ne zaman, hangi notla tamamladığı.
- Görevler ayrılığı özeti. Onaylayanlar ve çalıştıranın kim olduğu, aralarında çakışma olup olmadığı.
- Çalıştırma kaydı. Hangi sunucuda, ne zaman, kimin başlattığı ve sonucu; varsa hata metni.
- Acil durum bilgisi. Talep acil olarak ilan edildiyse kim ilan etti, sonradan gözden geçirildi mi, haklı bulundu mu.
- Denetim izi kayıtları. Talebe ait olayların zaman sıralı listesi ve zincirin doğrulanmış olması.
Dosyanın hem insan tarafından okunabilir hem de makine tarafından işlenebilir olması gerekir. Okunabilir bir PDF, denetçinin dosyayı klasörüne koymasını sağlar; aynı verinin yapısal bir kopyası ise başka bir sistemin veya bağımsız bir denetim aracının aynı dosyayı yeniden değerlendirmesini mümkün kılar.
Mühür: Dosya Sonradan Değişmedi mi
Kanıt dosyasının en kritik özelliği içeriği değil, içeriğinin doğrulanabilir olmasıdır. Dosya üretilirken içeriğinden matematiksel bir özet hesaplanır. Bu özet, dosyanın içine ve aynı anda denetim izine yazılır.
Doğrulama şöyle çalışır: dosya aylar sonra sisteme geri verilir, özet yeniden hesaplanır ve denetim izindeki kayıtla karşılaştırılır. İki değer eşitse dosya üretildiği günden beri değişmemiştir. Değilse dosya artık kanıt değildir ve bu da başlı başına bir bilgidir.
Bu zincirin gücü, karşılaştırma yapılan kaydın kendisinin korunmasına bağlıdır. Denetim izi gizli bir anahtarla imzalanmalı, anahtar veritabanında değil yapılandırma tarafında durmalı ve izin ikinci bir kopyası ayrı bir veritabanında tutulmalıdır. Veritabanına erişen kişinin anahtara erişememesi, zinciri tekrar üretilemez hale getiren şeydir.
Denetçinin sorduğu asıl soru
Deneyimli bir denetçi kayıtların içeriğinden çok şunu sorar: bu kaydı tutan ekip kaydı değiştirebilir mi? Cevap "evet ama yapmazlar" ise kontrol yoktur, güven vardır. Doğrulanabilir mühür, bu soruyu güven meselesi olmaktan çıkarır.
İstisnaların Gizlenmemesi
Kanıt dosyası bir pazarlama belgesi değildir. Her şeyin kusursuz göründüğü bir dosya denetçide güven değil şüphe uyandırır. Sağlıklı bir dosya kendi istisnalarını da yazar.
Talebi açan kişi kendi talebini çalıştırdıysa dosya bunu istisna olarak işaretler. Betik çalıştırıldıktan sonra değiştirilmişse bütünlük durumu bunu gösterir. Acil ilan edilmiş ama gözden geçirilmemiş bir talep, gözden geçirme alanı boş olarak görünür.
Yönetişimin ölçüsü ihlalin hiç olmaması değildir. Ölçü, ihlal olduğunda görünmesidir. Görünen bir istisna yönetilebilir; görünmeyen bir istisna denetimde bulunduğunda tüm sürecin güvenilirliğini tartışmaya açar.
Kanıt Üretmek de Bir Olaydır
Kanıt dosyası, talebin tüm ayrıntısını içerir: betiklerin tam metni, hangi sunucularda çalıştığı, kimlerin onayladığı. Bu, dışarı çıkabilen hassas bir pakettir. Bu yüzden dosyayı üretme yetkisi ayrı bir izin olarak yönetilmelidir ve herkese verilmemelidir.
İkinci kural, dosyanın üretilmesinin de denetim izine yazılmasıdır. Kim, hangi talep için, ne zaman kanıt dosyası çıkardı sorusunun cevabı kayıtta durmalıdır. Bu kayıt aynı zamanda mührün karşılaştırılacağı yerdir; yani dosyayı üretmek, dosyayı doğrulanabilir kılan işlemle aynı işlemdir.
Kendi Kanıt Dosyanızı Tasarlarken
Ürün kullanmadan da bu modele yaklaşmak mümkündür. Dört ilke yeterlidir.
- Tek kimlik. Üretime giden her işin doğduğu anda bir numarası olsun ve bu numara bütün aşamalarda taşınsın.
- Çalıştırma anında özet. Ne çalıştığını sonradan metinden değil, çalıştırma anında hesaplanan özetten kanıtlayın.
- Kural setinin donması. Talep açıldığı anda yürürlükteki kuralları talebe kopyalayın; politikayı yarın değiştirdiğinizde geçmiş kararlar okunabilir kalsın.
- Dışa aktarmanın kayıtlı olması. Kanıtı kimin ürettiğini kaydedin ve mührü o kayda yazın.
Bu dört ilke uygulandığında denetim hazırlığı bir projeden bir düğmeye iner. Kanıt, denetim için ayrıca hazırlanan bir şey olmaktan çıkar ve işin kendisinden üretilir.
Sık Sorulan Sorular
Kanıt dosyası bir rapordan farklı mıdır?
Evet. Rapor bir dönemin özetini verir ve genellikle yeniden çalıştırıldığında farklı sonuç üretir. Kanıt dosyası tek bir talebe aittir, üretildiği andaki durumu dondurur ve kendi mührünü taşır. Rapor yönetim içindir, kanıt dosyası denetim içindir.
Denetçi bizim ürettiğimiz dosyaya neden itibar etsin?
Dosyanın kaynağı değil doğrulanabilirliği önemlidir. Denetçi dosyayı sisteme geri verir, mühür yeniden hesaplanır ve denetim izindeki kayıtla karşılaştırılır. Ayrıca denetim izinin kendisi imzalıdır ve ayrı bir veritabanında ikinci kopyası tutulur. Denetçi buradaki iddiayı beyan olarak değil, tekrarlanabilir bir kontrol olarak değerlendirir.
Geçmiş taleplerimiz için de kanıt dosyası üretilebilir mi?
Kayıt hangi ayrıntıyı içeriyorsa dosya onu içerir. Geçmişte kural seti dondurulmamışsa o alan boş kalır, çalıştırma anında özet hesaplanmamışsa bütünlük durumu doğrulanamaz olarak görünür. Dosya eksik bilgiyi uydurmaz; eksik olduğunu yazar. Bu yüzden modele geçiş tarihi, kanıt kalitesinin de sınırıdır.
Bu dosyayı hazırlamak ne kadar sürer?
Model kurulduğunda hazırlık süresi yoktur; dosya talep detayından tek işlemle üretilir. Asıl süre modelin kurulmasında geçer ve o da denetimden önce bir kez ödenir. Denetim başına tekrar tekrar ödenen şey, elle kanıt toplama emeğidir.
Örnek kanıt dosyasını inceleyin
Bir talebin kanıt dosyasının içeriğini ve mührün nasıl doğrulandığını birlikte geçelim.
Demo Planlayın →