Güvenlik Denetimi: Evrak Değil, Kanıt Toplama

Sahadan: 214 talep ve son hafta

Denetim bizde yılda bir oluyor: bilgi sistemleri için düzenleyici denetim ve aynı dönemde ISO 27001 gözetim denetimi. Geçen yıla kadar ikisine de aynı şekilde hazırlanıyorduk: denetimden üç hafta önce uyum ekibi bir tablo gönderiyor, tabloda 214 satır var, her satır bir kanıt talebi. Dört mühendis üç hafta boyunca bu tabloyu dolduruyor. Toplam maliyet kabaca 260 saat.

Taleplerin çoğu kolaydı: “Parola politikasının yapılandırmasını göster.” Ekran görüntüsü, bitti. Zor olanlar geçmişi soranlardı: “Yıl içinden seçilen şu 25 canlı değişikliğin onay kaydını göster.” 25’in 7’sinin onayı bir mesajlaşma kanalında, “tamam, çık” cümlesiyle verilmişti. İkisinin hiç yoktu. Değişiklikler doğruydu, gözden geçirilmişti; ama bunu gösteren bir kayıt yoktu.

Denetimin sonunda 6 bulgu çıktı. 4’ü aynı cümlenin varyasyonuydu: kontrol çalışıyordu ama kanıtı yoktu. Kalan ikisi gerçekti ve beni daha çok rahatsız etti: ayrılan bir yüklenicinin hesabı 40 gün açık kalmıştı ve yedekten geri dönüş testini hiç yapmamıştık. Denetçi sormasa bir yıl daha yapmayacaktık.

Hata benimdi. Denetimi uyum ekibinin işi sanmıştım; biz sadece talep geldikçe ekran görüntüsü veren taraftık. Oysa sorulan her şey mühendisliğin ürettiği bir şeydi: onay, erişim, log, yedek. Kanıtı üreten sistemi biz tasarlıyorduk; sadece kanıt üretecek şekilde tasarlamamıştık.

Denetçi ne soruyor?

ISO 27001, SOC 2 ya da düzenleyici denetim: adları ve kontrol listeleri farklı ama mantıkları aynı. Denetçi üç şeye bakar:

1. Tasarım. Kontrol yazılı mı? “Canlıya çıkan her değişiklik, yazanından başka biri tarafından onaylanır.”
2. Uygulama. Kontrol gerçekten var mı? Branch kuralı açık mı?
3. Etkinlik. Kontrol yıl boyunca çalıştı mı? Burada örneklem gelir: rastgele 25 değişiklik, 25 onay.

İlk ikisi için ekran görüntüsü yeterli. Üçüncüsü için yetmez, çünkü soru geçmişle ilgili. Mayıs’taki erişim listesini Ocak’ta ekran görüntüsüyle kanıtlayamazsın. Ya o gün biri kaydetmiştir ya da hiç kimse kaydetmemiştir. Bütün mesele o kaydı insanın hatırlamasına bırakmamak.

Kanıt: işin yan ürünü

Oturup her kontrolün kanıtını nereden aldığımıza baktık. Şaşırtıcı olan şuydu: kanıtın neredeyse tamamı zaten üretiliyordu. PR onayı sistemde vardı. Erişim grupları kimlik sağlayıcıda (IdP) vardı. Deploy logu vardı. Sorun üretmek değil, saklamaktı: PR’lar squash edilip onay bilgisi kayboluyor, erişim grubu sadece bugünkü hâlini gösteriyor, deploy logu 30 gün sonra siliniyordu.

Tablonun her satırı bir mühendislik kararı. Uyum ekibi “erişim 24 saatte kapanır” kuralını yazabilir; ama İK sistemi ile kimlik sağlayıcıyı bağlayan sorguyu, farkı alarm yapan eşiği, kaydın nerede saklanacağını biz seçiyoruz.

Kanıt toplayıcı: her gece, tek iş

Hepsini tek bir gecelik işe bağladık. İşin yaptığı şey basit: her kontrol için kaynağı sorgula, sonucu tarihli bir dosyaya yaz, dosyayı değiştirilemez (object lock) bir depoya koy. Denetçi bir şey sorduğunda cevap bir klasör yolu.

# her gece 02:00. cikti: kanit/2025/05/14/ERISIM-01.json
# depo: degistirilemez (object lock), saklama suresi politikayla ayni
kontroller:
  - id: DEGISIKLIK-01        # onaysiz canli degisiklik yok
    kaynak: deploy logu -> commit sha -> PR -> onaylayan
    kural:  onaylayan != yazan
    ihlal:  alarm + kayit ac (acil duzeltme ise 24 saat sure)

  - id: ERISIM-01            # prod erisimi olanlar
    kaynak: idp grup "prod-erisim" uye listesi
    kural:  liste gunluk saklanir, degisiklik farki ayrica yazilir

  - id: AYRILIS-01           # ayrilan kisi 24 saatte kapanir
    kaynak: ik ayrilis tarihi - idp devre disi tarihi
    kural:  fark > 24 saat --> alarm (denetimde degil, O GUN)

  - id: LOG-01               # log saklama
    kaynak: her log kaynaginda en eski erisilebilir kaydin tarihi
    kural:  bugun - en_eski < politika suresi --> alarm

Toplayıcının asıl değeri denetim günü değil, yılın geri kalanında ortaya çıktı. Nisan’da ilk kez çalıştığı gece üç açık hesap buldu; en eskisi 19 gündür açıktı. Geçen yıl aynı şeyi denetçi bulmuştu, 40. günde. Bu yıl biz bulduk, ilk gece.

Üç mühendislik kararı

1. Acil düzeltme yolu

“Onaylayan yazandan farklı olmalı” kuralını branch korumasıyla zorunlu yaptığımız gün ilk soru geldi: gece 03:00’te tek başına düzeltme çıkarmak gerekirse? Kuralı esnetmek yerine ikinci bir yol yazdık. Acil düzeltme önceden onaysız çıkabilir, ama deploy aracı bunu işaretler, otomatik bir kayıt açar ve 24 saat içinde sonradan onay ister. 2025’te 9 acil çıkış oldu, dokuzu da 24 saat içinde onaylandı. Denetçi bu yolu sorunca kayıtları gösterdik; bulgu çıkmadı.

2. Kalıcı erişim yerine break-glass

Prod veritabanına kalıcı erişimi olan 9 kişi vardı. Çeyreklik gözden geçirmede her seferinde “hâlâ gerekli mi?” diye soruyorduk ve her seferinde “evet, nadiren ama gerekiyor” cevabı geliyordu. Soruyu değiştirdik: kalıcı erişim sıfır. Gerektiğinde kayıt numarasıyla break-glass erişim açılıyor, 4 saat sonra kendiliğinden kapanıyor ve oturum kaydediliyor. 2025’te 31 oturum açıldı. Her birinin gerekçesi kayıtta; denetçinin sorusu “kim erişti” olmaktan çıkıp “neden erişti” oldu ve cevabı zaten yazılıydı.

3. Politikayı yapabildiğin kadar yazmak

Eski politikamızda “her canlı değişiklik iki kişi tarafından onaylanır” yazıyordu. Kimse bunu yapmıyordu. Denetçi yazılı politikaya göre denetler; senin iyi niyetine göre değil. Kâğıtta iki onay, sahada bir onay: her örneklemde bulgu. Politikayı “bir onay + otomatik testlerin geçmesi” olarak yeniden yazdık, ikisinin de kanıtını %100 üretebildiğimiz için. Daha gevşek bir kural gibi görünüyor. Aslında daha sıkı, çünkü artık gerçekten uygulanıyor.

Nasıl bozuluyor?

Bu yıl ne değişti?

Bu ayın ortasında ikinci denetimi bitirdik. Talep sayısı 186’ya indi, çünkü bazı kontrolleri denetçi otomatik kanıt klasörüne bakarak kendisi kapattı. 186 talebin 141’i bir klasör yolu olarak gitti. Kalan 45’i hâlâ elle toplandı; çoğu politika dokümanı ve toplantı kaydı gibi zaten doğası gereği insan işi olan şeylerdi.

Tek bulgu öğreticiydi: VPN logları 14 ay saklanıyordu, politika 24 ay diyordu. O log kaynağı toplayıcıda yoktu, çünkü listeyi yaparken aklımıza gelmemişti. Ders basit: toplayıcıda olmayan kontrol, kanıtı olmayan kontroldür. Artık yeni bir log kaynağı açılırken toplayıcıya satır eklemek, açılışın bir adımı.

Bende işe yaramayanlar

• Hazır uyum aracı almak. İlk refleks buydu. Araç kontrolleri güzel listeledi ama kanıtı bizim sistemlerimizden çekmesi için yine her bağlantıyı biz kurduk. Asıl iş araç değil, bağlantıydı.
• Çeyreklik gözden geçirmeyi e-postayla yapmak. Yöneticilere liste gönderip “onaylıyor musunuz?” diye sorduk. Yarısı cevap vermedi, cevap verenlerin çoğu satırlara bakmadan “tamam” dedi. Kayıt sistemine taşıyıp her satıra ayrı “kalsın / kaldır” seçimi koyduk; ilk turda 11 erişim kaldırıldı.
• Deploy logunu uygulama logu gibi saklamak. 30 günlük saklama süresi uygulama logu için doğruydu, değişiklik kanıtı için değil. Deploy kayıtlarını ayrı bir akışa ve ayrı saklama süresine aldık.

Ne izlemeli?

Kontrol listesi

Sonuç

Geçen yılın o Pazartesi gecesi, dört mühendis 23:40’ta ekran görüntüsü alıyordu ve aldıkları şeylerin yarısı sorulan soruya cevap vermiyordu. Sorun çalışmamaları değildi; yanlış zamanda çalışıyorlardı. Kanıt, olayın olduğu gün toplanmalıydı.

Bu yıl denetimden önceki gece herkes evdeydi. Denetim daha kolay geçmedi, denetçi daha fazla şey sordu. Ama sorulan her şeyin cevabı yıl boyunca, kimse düşünmeden, kendiliğinden birikmişti. Aynı mantığı hata bütçesi yazısında da anlatmıştım: kuralı sakin bir günde yaz, yangında pazarlık etme.

Test şu: denetçi yarın sabah gelse, bu gece kimse geç saate kalır mı? Kalıyorsa elinde kanıt yok, sadece bir hazırlık telaşı var.