Cuma 19:23, altı ay sonra başlayan soruşturma

Cuma akşamı 19:23'te bir kullanıcı hesabı silinmiş. Hesap sahibi ertesi hafta işe geldiğinde sistemlere erişememiş, destek ekibine ticket açmış. "Hesabınız bulunmuyor" cevabını almış. İK ile görüşmüş, sistemde hiçbir işten çıkarma talebi yok. Konu üç hafta boyunca IT ve İK arasında ping-pong olmuş. Sonunda unutulmuş.

Altı ay sonra şirket, aynı dönemde birkaç kullanıcı hesabının yetkisiz silindiğini fark ediyor. Delil toplamak için log kayıtlarına bakıldığında klasik cevap geliyor: "30 günlük retention politikamız var, o tarihler silinmiş." Kimin ne zaman hangi hesabı sildiği artık bilinemez. Olay raporlanamaz, denetim kuruluna ibraz edilecek iz zinciri yok. Şirket avukatı "log olmadan sorumluluk atfedilemez" diyor.

ShamashAi'nin audit_log tablosu tam da bu senaryoya karşı tasarlandı: hiçbir retention politikası, hiçbir otomatik temizlik, hiçbir silme komutu audit kayıtlarına dokunmaz. İlk günden itibaren her işlem — kullanıcı ekleme, cihaz silme, SOAR aksiyonu tetikleme, proje kapatma — kalıcı bir zincir oluşturur. Altı ay sonra, iki yıl sonra, beş yıl sonra bile "kim ne yaptı" sorusuna kesin cevap verebilirsiniz.

Klasik log'ların retention tuzağı

SIEM ve log management platformlarında olaylar genellikle events veya benzeri tablolarda saklanır. Bu tablolar disk dolmasını önlemek için retention kurallarına tabidir: 30 gün, 90 gün, 1 yıl gibi. Süre dolunca kayıtlar arşive alınır veya kalıcı olarak silinir.

Sorun şu: bir güvenlik olayı tespit edildiğinde geçmişe dönük araştırma (forensics) yapmak istersiniz. Ancak retention periyodunun dışına çıktıysanız, kritik detaylar gitmiş olabilir:

Kimin hangi hesabı eklediği (device.create, user.create)
Hangi admin'in hangi SOAR aksiyonunu tetiklediği (soar.block, soar.quarantine)
Hangi kullanıcının hangi kritik ayarı değiştirdiği (settings.update, project.delete)

Oysa KVKK Madde 12'nin altıncı fıkrası, "işlenen verilerin denetimi için gerekli kayıt ve belgelerin tutulmasını" zorunlu kılar. ISO 27001:2022 Annex A.5.3 (Records) de benzer şekilde denetim kayıtlarının yeterli süre muhafaza edilmesini gerektirir. Klasik event retention, compliance gereksinimlerini karşılamaya yetmez; çünkü işlem logları (kim ne yaptı) ile güvenlik olayları (hangi saldırı tespit edildi) farklı kategorilerdir.

ShamashAi audit_log: append-only, retention-free tablo

ShamashAi'de dbo.audit_log tablosu, retention politikalarından tamamen izole edilmiştir. Bu tablo:

Append-only: Yalnızca INSERT işlemi yapılır. UPDATE veya DELETE desteklenmez.
Retention'sız: Hiçbir scheduled job, otomatik arşivleme veya purge politikası bu tabloya dokunmaz.
Project-bağımsız: Bir proje silinse bile o projeye ait audit kayıtları tabloda kalır. target_type='project' ve action='project.delete' kaydı orada durur.

Her audit kaydı şu alanları içerir:

sql SELECT timestamp, -- 2026-10-07T09:15:37.123Z (UTC) actor, -- ahmet.yilmaz@firma.com.tr action, -- device.create, soar.block, project.delete... target_type, -- device, user, soar_rule, project target_id, -- 12345 (ilgili kaydın ID'si) target_name, -- 'dc01.firma.local' veya 'SOAR Kural #42' detail, -- JSON: {"ip":"10.5.2.100","old_role":"viewer","new_role":"admin"} ip -- İşlemi yapan kullanıcının IP adresi FROM dbo.audit_log ORDER BY timestamp DESC;

Örnek kayıt:

{ "timestamp": "2026-10-07T09:15:37.123Z", "actor": "mehmet.kara@firma.com.tr", "action": "soar.block", "target_type": "soar_action", "target_id": 9876, "target_name": "Block IP 203.0.113.45", "detail": { "blocked_ip": "203.0.113.45", "reason": "BRUTE_FORCE_DETECTED", "duration_seconds": 3600 }, "ip": "10.5.2.15" }

Bu kayıt, Mehmet Kara'nın 07 Ekim 2026 09:15:37'de 203.0.113.45 IP adresini brute-force tespiti nedeniyle 1 saatliğine engellediğini gösterir. İki yıl sonra bile bu satır aynı şekilde okunabilir.

Hangi işlemler audit_log'a düşer?

ShamashAi, yalnızca kullanıcı müdahalesi gerektiren veya sistemin otomatik olarak kritik bir aksiyon tetiklediği işlemleri audit_log'a yazar. Örnek action prefix'leri:

device.* → device.create, device.update, device.delete
user.* → user.invite, user.role_change, user.disable
soar.* → soar.block, soar.quarantine, soar.allow, soar.notify
project.* → project.create, project.archive, project.delete
settings.* → settings.update_retention, settings.update_smtp
auth.* → auth.login_success, auth.login_fail, auth.logout

Her action alanı nokta ile ayrılmış prefix yapısına sahiptir. Web arayüzünde "Filter by action prefix" seçeneği ile soar.* yazarsanız tüm SOAR aksiyonlarını görebilirsiniz.

Web arayüzü: Last 500 entry default, CSV export

ShamashAi web panelinde Audit menüsü altında audit log görüntülenir. Varsayılan olarak son 500 kayıt gösterilir. Bu sayfa sayfalanmaz; daha eski kayıtları görmek için filtre kullanmanız gerekir:

Action prefix filtresi: device.* veya soar.block
Target type filtresi: user, device, project
Actor filtresi: ahmet.yilmaz@firma.com.tr
Tarih aralığı: 01.01.2025 - 31.12.2025

Filtre sonuçları CSV export butonuyla indirilir. CSV formatı:

csv timestamp,actor,action,target_type,target_id,target_name,detail_json,ip 2026-10-07T09:15:37.123Z,mehmet.kara@firma.com.tr,soar.block,soar_action,9876,Block IP 203.0.113.45,"{""blocked_ip"":""203.0.113.45""}",10.5.2.15

CSV dosyası, mahkeme veya denetim kurumlarına ibraz için doğrudan kullanılabilir. Dosya adı audit_log_2026-10-07_09-15.csv formatındadır.

KVKK Madde 12 alt 6: Denetim zinciri kanıtı

KVKK'nın 12. maddesinin altıncı fıkrası, veri sorumlusunun "kişisel verilerin işlenmesinde denetimi sağlayacak yeterli önlemleri almak" zorunda olduğunu belirtir. Bu, teknik olarak şu anlama gelir:

Kim hangi kullanıcının kişisel verisine erişti? → dbo.audit_log tablosunda action='user.view' veya benzeri kayıt olmalı.
Kim hangi kullanıcıyı sildi? → action='user.delete', actor, timestamp ve ip alanları dolu.
Sistemde yapılan değişikliklerin iz kaydı var mı? → Her CRUD işlemi audit_log'a düşer.

KVKK denetimleri sırasında Kurul, "Son iki yıl içinde kullanıcı silme işlemlerini gösterir misiniz?" gibi bir talep iletebilir. ShamashAi'de bu sorguyu şu şekilde cevaplarsınız:

sql SELECT timestamp, actor, target_name, detail, ip FROM dbo.audit_log WHERE action = 'user.delete' AND timestamp >= '2024-10-01' ORDER BY timestamp DESC;

Sonuç, tarih ve saatine, işlemi yapan kişiye, hedef kullanıcı adına ve IP adresine kadar detay sunar. Bu kanıt zinciri, KVKK uyumluluğunun teknik dayanağıdır.

Forensics senaryosu: Project silindi, kim yaptı?

Bir şirket, eski bir projeyi temizlemek için "Archive" yerine yanlışlıkla "Delete" butonuna basmış. Proje silinince o projeye bağlı tüm cihazlar, alarm kuralları ve SOAR konfigürasyonları da gitmiş. Üç hafta sonra IT yöneticisi "o projedeki firewall loglarına ihtiyacım var" diyor. Proje geri gelmez, ancak kim sildi sorusu cevaplanmalı.

ShamashAi audit_log:

sql SELECT timestamp, actor, action, target_name, detail FROM dbo.audit_log WHERE target_type = 'project' AND action = 'project.delete' ORDER BY timestamp DESC;

Sonuç:

timestamp | actor | action | target_name | detail 2026-09-15T14:32:11.456Z | ayse.demir@firma.com.tr | project.delete | Eski Firewall Projesi | {"project_id":7,"device_count":12}

Ayşe Demir, 15 Eylül 2026 14:32'de 12 cihaz içeren projeyi silmiş. Proje geri gelmez ama kim yaptı, ne zaman yaptı, hangi IP'den yaptı soruları kesin cevaplandı. Bu bilgi, iç disiplin süreci veya sigorta tazminat talebi için kullanılabilir.

Teknik mimari: Neden UPDATE/DELETE yok?

Append-only tablo tasarımı, veritabanı seviyesinde trigger veya constraint ile korunmaz. Bunun yerine ShamashAi API katmanı, dbo.audit_log tablosuna yalnızca INSERT izni veren bir servis hesabı kullanır. Fastify API endpoint'leri:

javascript // Node.js Fastify - Audit log ekleme (internal) fastify.post('/internal/audit/append', { schema: { body: { type: 'object', required: ['actor', 'action', 'target_type', 'target_id'], properties: { actor: { type: 'string', format: 'email' }, action: { type: 'string', pattern: '^[a-z_]+\\.[a-z_]+$' }, target_type: { type: 'string' }, target_id: { type: 'integer' }, target_name: { type: 'string' }, detail: { type: 'object' }, ip: { type: 'string', format: 'ipv4' } } } } }, async (request, reply) => { const { actor, action, target_type, target_id, target_name, detail, ip } = request.body; await sql.query` INSERT INTO dbo.audit_log (timestamp, actor, action, target_type, target_id, target_name, detail, ip) VALUES (GETUTCDATE(), ${actor}, ${action}, ${target_type}, ${target_id}, ${target_name}, ${JSON.stringify(detail)}, ${ip}) `; reply.code(201).send({ ok: true }); });

Bu endpoint yalnızca ShamashAi backend servisleri tarafından çağrılır; kullanıcı web arayüzünden doğrudan erişemez. UPDATE veya DELETE endpoint'i yoktur.

CSV export ve mahkeme dosyası

Bir şirket, eski bir çalışanın yetkisiz erişim yaptığını düşünüyor ve hukuki süreç başlatıyor. Avukat, "Şu kullanıcının son altı ay içinde hangi işlemleri yaptığını gösteren belge" talep ediyor. ShamashAi web arayüzünde:

1. Audit menüsü → Filter by actor → eski.calisan@firma.com.tr 2. Date range: 01.04.2026 - 01.10.2026 3. Export CSV butonu

İndirilen dosya:

csv timestamp,actor,action,target_type,target_id,target_name,detail_json,ip 2026-09-20T11:23:45.000Z,eski.calisan@firma.com.tr,device.view,device,88,srv-db01.firma.local,"{}",10.5.2.99 2026-09-19T16:10:12.000Z,eski.calisan@firma.com.tr,user.view,user,55,ali.veli@firma.com.tr,"{}",10.5.2.99

Bu CSV, mahkeme dosyasına eklenir. Tarih damgası UTC formatında olduğundan uluslararası geçerliliği vardır. ip alanı, işlemi yapan kişinin fiziksel konumunu (VPN, ofis ağı) gösterir.

Limitler ve dürüst notlar

Performans sorunu: Audit_log tablosu milyonlarca satıra ulaşırsa, timestamp sütununda index olsa da sorgu yavaşlayabilir. Pilot kapsamında 1 milyon satır üstü senaryolar test edilmemiştir.
Disk dolması riski: ShamashAi, dbo.audit_log tablosu için disk kotası tanımlamaz. Süresiz büyüme kabul edilir; ancak disk dolması izlenmez. IT ekibinin SQL Server disk alarmı kurması önerilir.
Action semantiği standardize değil: soar.block ve soar.allow action'ları tanımlıdır; ancak gelecekte firewall.block gibi yeni prefix'ler eklenirse CSV export'unuzdaki filtreler güncellenmeli.
Tarih aralığı UI sınırı: Web arayüzünde tarih filtresi maksimum 2 yıl geriye gidebilir. Daha eski kayıtları görmek için doğrudan SQL sorgusu gerekir (admin rolü).
Detail JSON şeması dökümante değil: detail alanı serbest JSON'dur. Her action için hangi alanların dolu olacağına dair şema dokümantasyonu henüz yayınlanmadı; pilot kapsamında detay paylaşılır.

ShamashAi'nin append-only audit_log tablosu, klasik SIEM retention politikalarının aksine sonsuz forensics zinciri sunar. KVKK Madde 12 denetim gereksinimlerini, ISO 27001 kayıt saklama kontrollerini ve mahkeme kanıt taleplerine cevabı tek bir tabloda toplar. Altı ay sonra, iki yıl sonra bile "kim ne yaptı" sorusuna kesin cevap verebilirsiniz.

Pilot programı 30 gün ücretsiz: shamashai.com.tr/iletisim

Paylaş

ShamashAi Audit Log — Silinmeyen Kayıtlar, Sonsuz Forensics Zinciri