ShamashAi Audit Log: Append-Only Mimari ile Forensics Kanıt Zinciri

Salı 14:37'de gelen telefon ve kayıp log senaryosu

Ekim 2026, salı öğleden sonra. IT yöneticiniz arar: "Haziran'da kim dc01 sunucusuna RDP açtı? Mali Müfettişlik soruyor, 120 gün geçmiş."

Siz ShamashAi panel'i açarsınız, dbo.audit_log tablosuna bakar, action prefix device.rdp_enable ile filtrelersiniz. Timestamp: 2026-06-12 08:23:11. Actor: mehmet.kaya@firma.local. Target: dc01.firma.local. Detail JSON içinde hangi portun açıldığı, hangi IP'den işlemin yapıldığı duruyor. CSV export ile dosyayı Mali Müfettişlik'e iletirsiniz. Süre: 90 saniye.

Klasik SIEM'lerde bu senaryo "log retention doldu, veri yok" cevabıyla sonuçlanır. 90 günlük hot storage, 180 günlük cold storage, sonrası silindi. Olay 120. günde ortaya çıktığında forensics için gerekli iz zaten silinmiştir. Compliance Officer "denetim yapılamıyor" raporu yazar; dış denetçi bulgu açar.

ShamashAi audit_log tablosu bu soruna mimari düzeyde çözüm getirir: append-only tasarım, retention politikası yok, proje silme işlemi bile audit kayıtlarına dokunmaz. Forensics kanıt zinciri için sonsuz yaşam döngüsü.

Append-only mimari: silme operasyonu olmayan tablo

ShamashAi'nin dbo.audit_log tablosu klasik event tablosu dbo.events ile yapısal olarak ayrılır. Event'ler retention temizliğine tabidir (disk tasarrufu için); audit kayıtları ise asla silinmez.

Her kayıt şu alanları içerir:

• timestamp: UTC timezone'da olay zamanı (milisecond precision).
• actor: İşlemi yapan kişinin email adresi (örn. admin@firma.local, system@shamashai — sistem operasyonları için).
• action: Nokta notasyonlu eylem tipi (device.create, device.delete, soar.block, soar.unblock, project.archive, user.role_change, compliance.evidence_export).
• target_type: Hedef nesne türü (device, user, rule, soar_action, report).
• target_id: Hedef nesne SQL Server internal ID (integer).
• target_name: İnsan okunabilir hedef ismi (fw01.istanbul, Brute-Force Blocker Rule).
• detail: JSON formatında ek bilgi (IP adresi, değişen ayar, eski/yeni değer karşılaştırması).
• ip: İşlemin başlatıldığı IP adresi (web panelinden yapılan işlemler için client IP, agent'tan gelenler için agent IP).

Örnek audit kaydı:

{ "timestamp": "2026-10-05T09:15:33.127Z", "actor": "ali.veli@firma.local", "action": "soar.block", "target_type": "device", "target_id": 482, "target_name": "laptop-sales-05", "detail": { "reason": "BRUTE_FORCE_DETECTED", "rule_id": 78, "block_duration_minutes": 60, "blocked_protocols": ["RDP", "SMB"] }, "ip": "10.20.5.14" }

Bu kayıt asla silinmez. 5 yıl sonra bile dbo.audit_log tablosunda aynen durur.

Retention politikalarından bağımsızlık: Event vs Audit ayrımı

ShamashAi'de iki ayrı veri havuzu vardır:

1. dbo.events — operasyonel log, retention var

• BRUTE_FORCE_DETECTED, AUTH_FAIL_USER, M365_RISKY_SIGNIN gibi güvenlik event'leri.
• Default retention: 180 gün (hot), 365 gün (cold archive).
• Disk tasarrufu için eski kayıtlar temizlenir.
• Grafik, dashboard, anomaly detection burada çalışır.

2. dbo.audit_log — denetim kaydı, retention yok

• Yönetici eylemi (cihaz ekleme, kural değiştirme, SOAR aksiyonu, kullanıcı rol değişikliği).
• Hiçbir temizlik job'ı bu tabloya dokunmaz.
• Forensics, compliance, yasal inceleme için sonsuz yaşam döngüsü.
• Dashboard veya grafik yok; sadece filtre ve export.

Bu ayrım sayesinde operasyonel performans (event tablosu hafif kalır) ile forensics gereksinimi (audit asla silinmez) dengelenir.

Proje silme durumunda bile audit korunur

ShamashAi'de bir "project" (şube, bölge, müşteri organizasyonu) silindiğinde:

• İlgili dbo.devices kayıtları soft-delete olur (bayrak is_deleted=1).
• İlgili dbo.events tablosu kayıtları retention politikasına göre zamanla temizlenir.
• Ancak dbo.audit_log tablosundaki kayıtlar aynen kalır.

Örneğin:

• 2025-03-10: "İstanbul Şube" project'i oluşturuldu → audit kaydı: project.create.
• 2025-08-22: Şube kapatıldı, project silindi → audit kaydı: project.delete, actor: yonetim@firma.local.
• 2026-10-05: Mali denetim, "İstanbul Şube'de 2025 yılında hangi cihazlar eklendi?" sorusu.

Siz dbo.audit_log tablosunda action = 'device.create' ve detail JSON'da project_name='İstanbul Şube' filtresi yaparsınız. Tüm kayıtlar hala orada. Proje silinmiş olsa da denetim zinciri korunmuştur.

Filtreleme ve CSV export: forensics araştırma akışı

ShamashAi web panelinde Audit Log sayfası (URL: /audit) şu filtreleri sunar:

• Action prefix: device.*, soar.*, user.*, compliance.* gibi nokta notasyonlu prefix. Örnek: soar.block ve soar.unblock kayıtlarını birlikte görmek için soar. prefix'i kullanılır.
• Target type: device, user, rule, soar_action, report gibi hedef nesne türü.
• Actor email: Belirli bir kullanıcının tüm eylemlerini görmek için.
• Date range: Başlangıç-bitiş tarihi (default: son 30 gün, ancak tarih sınırı yok — 5 yıl önceki kayıt da sorgulanabilir).

Default olarak son 500 entry gösterilir (performans nedeniyle). Daha fazla kayıt için tarih aralığı daraltılmalı veya CSV export kullanılmalı.

CSV export butonu tüm filtre kriterlerine uyan kayıtları .csv dosyasına aktarır:

timestamp,actor,action,target_type,target_id,target_name,detail,ip 2026-10-05T09:15:33.127Z,ali.veli@firma.local,soar.block,device,482,laptop-sales-05,"{"reason":"BRUTE_FORCE_DETECTED"}",10.20.5.14 2026-10-04T14:22:01.883Z,admin@firma.local,device.create,device,483,fw02.ankara,,192.168.1.50

Bu CSV dosyası forensics raporu eki veya dış denetim kanıt paketi olarak kullanılabilir.

KVKK Madde 12 alt 6: İşleme faaliyetlerinin denetimi

KVKK Madde 12/6: "Veri sorumlusu, kişisel verilerin işlenme faaliyetlerini denetleme yetkisine sahiptir."

Bu madde, veri sorumlusunun kimlerin hangi kişisel veriye eriştiğini, hangi işlemleri yaptığını, ne zaman yaptığını denetleyebilmesini gerektirir.

ShamashAi audit_log bu gereksinimi karşılar:

• Actor alanı: Erişimi kim yaptı?
• Action + target: Hangi cihaz/kullanıcı/veri üzerinde işlem yapıldı?
• Timestamp: Ne zaman?
• IP: Nereden?
• Detail JSON: İşlem detayı (örn. hangi kullanıcı bilgisi export edildi, hangi rapor indirildi).

Örnek senaryo: KVKK başvurusu sonrası kişisel veri export işlemi audit kaydı:

{ "timestamp": "2026-09-18T11:05:22.441Z", "actor": "kvkk.sorumlusu@firma.local", "action": "compliance.evidence_export", "target_type": "user", "target_id": 91, "target_name": "ahmet.yilmaz@firma.local", "detail": { "export_format": "PDF", "included_events": ["AUTH_FAIL_USER", "M365_RISKY_SIGNIN"], "request_id": "KVKK-2026-091" }, "ip": "10.10.1.5" }

Bu kayıt, ilgili kişi veya denetim otoritesi tarafından sorgulandığında "kişisel veri işleme faaliyeti kimler tarafından yapıldı?" sorusuna kanıt niteliğinde cevap verir.

Forensics kanıt zinciri: zaman damgası ve değişmezlik

Adli bilişim (forensics) incelemesinde kanıt zinciri (chain of custody) kritiktir. Bir log kaydının:

• Ne zaman oluştuğu,
• Kim tarafından oluşturulduğu,
• Sonradan değiştirilip değiştirilmediği kanıtlanmalıdır.

ShamashAi audit_log append-only mimarisi sayesinde:

• Kayıt eklenir, güncellenmez veya silinmez. SQL Server seviyesinde UPDATE/DELETE operasyonu yok.
• Timestamp UTC timezone'da milisecond precision ile kaydedilir.
• Actor değeri sistem tarafından otomatik doldurulur (kullanıcı müdahale edemez).

Örneğin bir SOAR aksiyonu (örn. cihaz karantinaya alma) sonrası:

1. dbo.soar_actions tablosuna aksiyon kaydı yazılır. 2. dbo.audit_log tablosuna soar.quarantine kaydı eklenir. 3. Aksiyon geri alındığında (quarantine kaldırıldığında) soar.unquarantine kaydı eklenir. 4. Her iki kayıt da kalır; tarihsel sıralama korunur.

Bu sayede "Cihaz ne zaman karantinaya alındı, kim tarafından, ne zaman kaldırıldı?" sorusu kesin tarih ve actor bilgisi ile cevaplanır.

SQL Server seviyesinde immutability kontrolü

ShamashAi audit_log tablosu SQL Server'da şu kısıtlamalara sahiptir:

• Trigger: AFTER UPDATE → ROLLBACK: Eğer bir UPDATE operasyonu denerse, SQL trigger devreye girer ve işlemi geri alır.
• Trigger: AFTER DELETE → ROLLBACK: Silme denemesi de aynı şekilde engellenir.
• Sadece INSERT permission: Uygulama kullanıcısı (ShamashAi API service account) sadece INSERT yetkisine sahiptir; UPDATE/DELETE yok.

Bu sayede yanlışlıkla veya kötü niyetle audit kaydı manipülasyonu engellenir.

DBA (database administrator) yetkisine sahip kişi teorik olarak trigger'ı devre dışı bırakıp kayıt silebilir; ancak bu durumda SQL Server audit log'u (eğer aktifse) DBA eylemini kaydeder. Çok katmanlı koruma.

Event ile audit arasındaki ilişki: incident_groups ve kanıt zinciri

Bir güvenlik olayı (incident) gerçekleştiğinde:

1. dbo.events tablosuna olay kaydedilir (örn. BRUTE_FORCE_DETECTED). 2. ShamashAi SOAR engine otomatik aksiyon tetikler (örn. IP engelleme). 3. dbo.soar_actions tablosuna aksiyon kaydedilir. 4. dbo.audit_log tablosuna soar.block kaydı düşer. 5. Olay ve aksiyon dbo.incident_groups tablosunda gruplanır.

Forensics incelemesinde:

• dbo.events tablosu "ne oldu?" sorusuna cevap verir (ancak retention nedeniyle zamanla silinebilir).
• dbo.audit_log tablosu "kim ne yaptı?" sorusuna sonsuz süre cevap verir.

Örneğin 6 ay sonra incident incelemesi:

• Event kaydı silinmiş olabilir (retention 180 gün).
• Ancak audit kaydı hala var: "2026-04-10 tarihinde admin@firma.local, 203.0.113.5 IP'sini soar.block aksiyonu ile engellemiş."
• detail JSON içinde event_id referansı varsa, event silinmiş olsa bile incident ID üzerinden bağlantı kurulabilir.

Bu hibrid yaklaşım hem operasyonel performans (event tablosu hafif) hem forensics gereksinimi (audit sonsuz) dengeler.

.NET agent ve API entegrasyonu: audit kaydı nasıl oluşur?

ShamashAi .NET 8 agent'ları (Windows/Linux sunucularda çalışan) ve web paneli (Next.js) aynı Node.js Fastify API'sine bağlanır.

Audit kaydı oluşturma akışı:

Web panelinden manuel aksiyon

1. Kullanıcı ShamashAi web panelinde "Block Device" butonuna basar. 2. Next.js frontend, JWT token ile POST /soar/block endpoint'ine istek gönderir. 3. Fastify API, JWT'den actor email'ini çıkarır (req.user.email). 4. API, dbo.soar_actions tablosuna aksiyon kaydeder, dbo.audit_log tablosuna audit kaydı ekler:

javascript // Node.js Fastify API - POST /soar/block const auditEntry = { timestamp: new Date().toISOString(), actor: req.user.email, action: 'soar.block', target_type: 'device', target_id: deviceId, target_name: device.hostname, detail: JSON.stringify({ reason: 'BRUTE_FORCE_DETECTED', block_duration_minutes: 60 }), ip: req.ip };

await sql.query` INSERT INTO dbo.audit_log (timestamp, actor, action, target_type, target_id, target_name, detail, ip) VALUES (${auditEntry.timestamp}, ${auditEntry.actor}, ${auditEntry.action}, ${auditEntry.target_type}, ${auditEntry.target_id}, ${auditEntry.target_name}, ${auditEntry.detail}, ${auditEntry.ip}) `;

Agent tarafından otomatik aksiyon

1. .NET agent, anomaly detection sonrası POST /soar/quarantine endpoint'ine istek gönderir. 2. API, JWT token yerine agent API key üzerinden actor belirler (system@shamashai veya agent hostname). 3. Audit kaydı aynı şekilde oluşur, actor alanı agent:dc01.firma.local gibi kaydedilir.

Bu sayede hem insan hem sistem eylemleri aynı audit tablosunda izlenir.

Compliance evidence export: GET /compliance/evidence endpoint'i

ShamashAi API, audit kayıtlarını dış denetim veya yasal inceleme için export etmek üzere endpoint sunar:

GET /compliance/evidence?start_date=2026-01-01&end_date=2026-12-31&actor=&action_prefix=soar

Response:

{ "export_id": "exp_20261005_091533", "generated_at": "2026-10-05T09:15:33.127Z", "criteria": { "start_date": "2026-01-01", "end_date": "2026-12-31", "action_prefix": "soar" }, "record_count": 1842, "records": [ { "timestamp": "2026-10-05T09:15:33.127Z", "actor": "ali.veli@firma.local", "action": "soar.block", "target_type": "device", "target_name": "laptop-sales-05", "detail": {"reason": "BRUTE_FORCE_DETECTED"}, "ip": "10.20.5.14" } ] }

Bu JSON paketi veya CSV export, dış denetçiye veya yasal merciye kanıt olarak sunulabilir.

Limitler ve dürüst notlar

• Audit kaydı detay seviyesi her action için aynı değil. Bazı action'lar (örn. device.create) minimal JSON içerir; bazıları (örn. soar.block) zengin detay içerir. ShamashAi dokümantasyonu hangi action'ın hangi detail alanlarını içerdiğini detaylandırmıyor; pilot kapsamında detay paylaşılır.
• Audit tablosu sonsuz büyüdüğünde performans sorunu olabilir. 10 milyon satırın üzerinde full-text arama yavaşlar. ShamashAi şu an index optimizasyonu yapıyor; büyük tablo senaryoları için partitioning planlanıyor (henüz yok).
• Audit kaydı real-time değil, async yazılır. API response döndükten sonra audit kaydı arka planda SQL'e yazılır (performans için). Çok nadir durumlarda (API crash) audit kaydı eksik kalabilir.
• DBA yetkisine sahip kişi SQL Server üzerinden audit kaydını silebilir. Mimari koruma var (trigger, permission), ancak DBA override edebilir. Çok kritik ortamlar için SQL Server Audit (Microsoft native feature) ile ek koruma katmanı önerilir.
• Audit kaydı içinde민 kişisel veri (email, IP) vardır. KVKK Madde 12/6 gereği bu veriler saklanmalı, ancak ilgili kişi "verilerimi sil" başvurusu yaparsa audit kaydı anonimleştirilmeli mi tartışmalı. ShamashAi şu an anonimleştirme özelliği sunmuyor.

Sonuç: Forensics için sonsuz yaşam döngüsü

ShamashAi audit_log tablosu, klasik SIEM retention sorununa mimari çözüm getirir: append-only, retention yok, proje silme durumunda bile kayıtlar korunur. KVKK Madde 12/6 uyumlu denetim zinciri, forensics kanıt zinciri, compliance evidence export tek çatı altında.

Yönetici eylemlerinin, SOAR aksiyonlarının, kullanıcı rol değişikliklerinin tamamı dbo.audit_log tablosunda sonsuz süre saklanır. 5 yıl sonra bile "kim ne yaptı?" sorusuna milisecond hassasiyetle cevap verebilirsiniz.

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