Salı 14:37 – Proje silindi, audit zinciri kaldı
Şirketin yeni IT yöneticisi, devraldığı ShamashAi ortamında eski bir pilot projeyi temizlemeye karar verdi. "IstanbulDC-Pilot" adlı site silindiğinde altındaki 120 cihaz, 800 bin event kaydı ve ilişkili SOAR workflow'ları da temizlendi. Retention politikası aktif; 90 günlük event logları zaten haftalardır temizleniyordu. Üç ay sonra Mali Suçları Araştırma Kurulu, o pilot proje kapsamında altı ay önce tetiklenen bir SOAR bloklama aksiyonunun detaylarını istedi: "kim, ne zaman, hangi cihazı engelledi, kaynak IP ne?". Kurumun compliance sorumlusu sorgusunu çalıştırdı:
SELECT * FROM dbo.audit_log WHERE action = 'soar.block' AND detail LIKE '%IstanbulDC-Pilot%' – 47 satır döndü. Proje silinmiş, event tablosu boşalmış, ama audit kaydı hâlâ oradaydı. O anı yaşayan CTO şunu fark etti: ShamashAi'nin audit_log tablosu append-only mimaride çalışıyor ve retention politikası bu tabloya dokunmuyor.
Bu yazıda ShamashAi'nin audit_log mekanizmasının teknik yapısını, forensics senaryolarındaki değerini ve KVKK Madde 12 yükümlülüklerini nasıl karşıladığını anlatacağız.
Append-only mimari: silme yetkisi yok
ShamashAi'de iki tür log katmanı vardır:
event log ve
audit log. Event log tablosu (
dbo.events) gelen telemetriyi tutar; retention politikasına bağlıdır ve varsayılan olarak 90 gün sonra silinir. Audit log tablosu (
dbo.audit_log) ise her türlü sistem içi aksiyonun tarih damgasını, kim tarafından yapıldığını, hangi nesneye dokunulduğunu ve o aksiyonun detay JSON'unu tutar –
ve hiçbir şekilde silinmez.
Append-only tasarım, SQL Server tarafında
INSERT hakkı verip
UPDATE ve
DELETE haklarını kısıtlayarak sağlanmıştır. ShamashAi API'si (Node.js Fastify) audit satırı yazarken şu yapıyı kullanır:
javascript
// Fastify route: POST /soar/block
await sql.query`
INSERT INTO dbo.audit_log (timestamp, actor, action, target_type, target_id, target_name, detail, ip)
VALUES (GETUTCDATE(), ${actorEmail}, 'soar.block', 'device', ${deviceId}, ${deviceName}, ${JSON.stringify(detailObj)}, ${requestIp})
`;
Bu kayıt yazıldıktan sonra ShamashAi içinde silme veya düzenleme endpoint'i yoktur. Manuel SQL sorgusuyla bile silmeye kalkan kullanıcı, veritabanı izninin kısıtlı olduğunu görür. Bu, kasıtlı sabotaj veya yanlışlıkla toplu silme senaryolarına karşı mimarinin ilk savunma hattıdır.
Retention politikası audit_log'a dokunmaz
ShamashAi'nin genel ayarlarında retention süresi (örneğin 90 gün) tanımlıyken, bu süre yalnızca
dbo.events tablosuna uygulanır. Haftalık çalışan SQL Agent job şu sorguyu çalıştırır:
sql
DELETE FROM dbo.events WHERE timestamp < DATEADD(day, -90, GETUTCDATE());
Aynı job içinde
dbo.audit_log için silme bloğu yoktur. Bu, kasıtlı bir tasarım kararıdır: compliance yükümlülükleri 1–3 yıl geriye dönük denetim zinciri gerektirebilir, ama ham event'ler disk maliyeti nedeniyle uzun süre tutulamaz. Audit log'un boyutu çok daha küçüktür (her event için audit yok, yalnızca ShamashAi içinde yapılan aksiyon için audit var) ve bu sayede on-prem disk kapasitesi üzerinde baskı oluşturmadan sonsuz süre saklanabilir.
Pilot ortamlarımızda 200 cihazlı bir müşterinin 9 aylık audit_log tablosu 1.2 GB civarında kaldı; aynı sürede
dbo.events tablosu 340 GB büyümüştü. Retention sayesinde event tablosu 90 günde sabitlenirken, audit tablosu doğrusal büyümeye devam etti. Ancak yıllık büyüme hızı bile makul seviyede kaldı.
Proje silinse bile audit zinciri kalır
ShamashAi'de organizasyon "site" altında gruplandırılır (
dbo.sites). Bir site silindiğinde altındaki cihazlar (
dbo.devices) ve bu cihazlardan gelen event kayıtları (
dbo.events) da silinir. Ama audit_log'da o site ile ilgili hangi kullanıcının ne zaman cihaz eklediği, hangi SOAR kuralını tetiklediği, hangi dashboard'u export ettiği bilgisi saklanır.
Örneğin:
{
"timestamp": "2026-03-15T11:22:09Z",
"actor": "ahmet.yilmaz@ornek.com.tr",
"action": "device.create",
"target_type": "device",
"target_id": "d8a9c2e1-4f6a-4b3c-9e1d-2a3b4c5d6e7f",
"target_name": "dc01.ist.ornek.com.tr",
"detail": {"site_id": "s123", "site_name": "IstanbulDC-Pilot", "agent_version": "1.4.2"},
"ip": "10.20.30.40"
}
Altı ay sonra bu site silinse bile audit_log'daki bu satır kalır. Forensics ekibi "dc01.ist.ornek.com.tr cihazı kim ekledi, ne zaman, hangi IP'den?" sorusuna cevap bulabilir. Bu, iç tehditlere veya kötü niyetli admin davranışına karşı korunma mekanizmasıdır.
Tutulan audit action türleri
ShamashAi audit_log şu action prefix'leri kullanır:
- device.create / device.update / device.delete: Cihaz yönetimi.
- soar.block / soar.quarantine / soar.unblock: SOAR Engine aksiyonları (manuel veya otomatik).
- user.login / user.logout / user.create / user.password_reset: Kimlik yönetimi.
- report.export / compliance.evidence_download: CSV/PDF export işlemleri.
- site.create / site.delete: Site CRUD.
- config.update: Genel sistem ayarı değişiklikleri (retention süresi, SMTP, vb.).
Her action
detail JSON'unda o aksiyona özel alanlar tutar. Örneğin
soar.block aksiyonu:
{
"rule_id": "r45",
"rule_name": "M365 Risky Sign-In Auto Block",
"event_type": "M365_RISKY_SIGNIN",
"blocked_ip": "203.0.113.42",
"duration_minutes": 60,
"automatic": true
}
Bu detay forensics analizinde kritik; hangi SOAR kuralının otomatik tetiklendiği, ne kadar süre blok uygulandığı gibi bilgiler dava dosyasında kanıt olabilir.
KVKK Madde 12 alt 6 denetim yükümlülüğü
KVKK Madde 12/6: "Veri sorumlusu, kişisel verilerin hukuka aykırı olarak işlenmesini önlemek, verilere hukuka aykırı erişilmesini önlemek ve verilerin muhafazasını sağlamak amacıyla uygun güvenlik düzeyini temin etmeye yönelik gerekli her türlü teknik ve idari tedbirleri almak zorundadır." Rehberde bu "tedbirlerin denetlenebilir olması" vurgulanır.
ShamashAi audit_log, bu denetim zincirini sağlar:
1.
Kim, ne zaman, hangi kişisel veri kaynağına (cihaza) eriş hakkı verdi? →
device.create kayıtları.
2.
Otomatik SOAR aksiyonu bir kullanıcıyı engellediyse, bunun sebebi kaydedildi mi? →
soar.block +
detail.event_type.
3.
Rapor export edildiğinde kişisel veri içeriyorsa kim indirdi? →
report.export +
detail.report_type.
4.
Retention politikası değiştirildi mi, kim değiştirdi? →
config.update +
detail.old_value / new_value.
KVKK denetimleri sırasında Kurul, "son 12 ayda kişisel veri içeren logları kimin export ettiğini gösterin" dediğinde aşağıdaki sorgu yeterli:
sql
SELECT timestamp, actor, target_name, detail, ip
FROM dbo.audit_log
WHERE action LIKE 'report.%'
AND timestamp >= DATEADD(month, -12, GETUTCDATE())
ORDER BY timestamp DESC;
Sonuç CSV olarak export edilir (
GET /audit/export endpoint'i mevcut) ve denetim dosyasına eklenir. Bu, retention politikası nedeniyle esas event'lerin silinmiş olması durumunda bile geçerlidir; çünkü audit kaydı silinmemiştir.
Filtre ve export özellikleri
ShamashAi web arayüzünde (Next.js) Audit sayfası şu filtreleri destekler:
- Action prefix: Örneğin "soar." yazarak tüm SOAR aksiyonları listelenir.
- Target: Cihaz adı veya site adı içeren kayıtlar.
- Actor (email): Belirli bir kullanıcının yaptığı tüm aksiyonlar.
- Tarih aralığı: ISO 8601 formatında (UTC).
Varsayılan görünüm
son 500 kayıttır. Daha fazla kayıt için backend pagination (
GET /audit?offset=500&limit=500) kullanılır. Export için
GET /audit/export?format=csv&filters=... endpoint'i çağrılır; bu da bir audit kaydı oluşturur:
{
"action": "report.export",
"target_type": "audit",
"target_name": "audit_export_2026-09-09.csv",
"detail": {"row_count": 1247, "filters": {"action_prefix": "soar."}}
}
Bu meta-audit ("export işleminin kendisi de loglanır") forensics zincirinde şeffaflığı artırır: kim, ne amaçla audit log export etti?
Forensics senaryosu: iç tehdit analizi
Bir güvenlik olayı anında klasik event log'lar yetmeyebilir. Örneğin, saldırgan admin yetkisi ele geçirmişse ShamashAi'de cihaz eklemiş veya SOAR kuralını devre dışı bırakmış olabilir. Audit log bu aksiyonları gösterir:
1.
Cihaz ekleme:
device.create kaydı → actor email, IP adresi, zaman damgası.
2.
SOAR kuralı devre dışı:
config.update kaydı →
detail.old_value: {"soar_rule_r12_enabled": true},
new_value: {"soar_rule_r12_enabled": false}.
3.
Toplu event silme denemesi: Audit log'da
DELETE hakkı olmadığı için bu aksiyon başarısız olur, ama deneme bile audit_log'a yazılmaz çünkü SQL seviyesinde reddedilir. Ancak eğer admin doğrudan veritabanına erişip denerse, SQL Server audit trail (ayrı bir katman) bu denemayı kaydeder.
Bu zincir, olay sonrası timeline oluşturmak için kullanılır. ISO 27001:2022 Annex A.12.4.1 (event logging) gereksinimini karşılar.
SQL Server row-level güvenlik (isteğe bağlı)
ShamashAi dokümantasyonu şu anda row-level security (RLS) desteğini belirtmiyor, ancak pilot ortamlarda SQL Server RLS ile audit_log üzerinde ek kısıtlama yapılabilir. Örneğin, yalnızca CISO rolündeki kullanıcılar tüm audit kayıtlarını görebilir; diğer kullanıcılar yalnızca kendi
actor değerine sahip satırları görebilir:
sql
CREATE FUNCTION dbo.fn_AuditSecurityPredicate(@actor NVARCHAR(255))
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN SELECT 1 AS result
WHERE @actor = USER_NAME() OR IS_MEMBER('CISO_Role') = 1;
CREATE SECURITY POLICY AuditPolicy
ADD FILTER PREDICATE dbo.fn_AuditSecurityPredicate(actor) ON dbo.audit_log
WITH (STATE = ON);
Bu, çok kiracılı ortamlarda veya büyük şirketlerde denetim yetkisinin kademeli olarak dağıtılması için kullanılabilir. ShamashAi dokümantasyonu bu detayı vermediği için pilot kapsamında SQL DBA ile birlikte yapılandırılmalıdır.
Performans ve indeksleme
Audit_log tablosu append-only olduğundan
INSERT performansı kritiktir. ShamashAi varsayılan kurulumda şu indeksi kullanır:
sql
CREATE CLUSTERED INDEX IX_AuditLog_Timestamp ON dbo.audit_log(timestamp DESC);
CREATE NONCLUSTERED INDEX IX_AuditLog_Actor ON dbo.audit_log(actor);
CREATE NONCLUSTERED INDEX IX_AuditLog_Action ON dbo.audit_log(action);
Büyüyen tablolarda (5–10 milyon satır üzeri)
detail JSON sütunu için full-text index eklenmesi önerilir:
sql
CREATE FULLTEXT CATALOG AuditCatalog;
CREATE FULLTEXT INDEX ON dbo.audit_log(detail) KEY INDEX PK_AuditLog ON AuditCatalog;
Bu, "SOAR bloklama yapan tüm kayıtları detail içinde 'brute_force' kelimesiyle ara" gibi sorguları hızlandırır. Ancak ShamashAi şu anda bu indeksi otomatik oluşturmuyor; manuel SQL komutla eklenmelidir.
Limitler ve dürüst notlar
- Disk büyümesi: Append-only tasarım disk tüketir. 500 cihazlı ortamda yılda ~5–8 GB büyüme beklenir. 5 yıl sonra 40 GB civarı. On-prem SSD/HDD kapasitesi buna göre planlanmalı.
- Silme mekanizması yok: Yasal bir "unutulma hakkı" talebi gelirse (KVKK Madde 7), audit log'dan ilgili actor email'inin maskesini manuel SQL ile güncellemeniz gerekir. ShamashAi arayüzünde "audit kaydı sil/gizle" özelliği yok.
- JSON detail yapısı değişebilir: ShamashAi versiyonları arasında
detail JSON şeması değişirse, eski kayıtlar eski şemada kalır. Forensics sorgularında JSON parse hatası riski var; JSON_VALUE yerine ISJSON kontrolü yapın.
- Çoklu tenant desteği: Şu anda audit_log tek tenant (tek müşteri) için tasarlandı. Aynı veritabanını birden fazla müşteri paylaşıyorsa (MSP senaryosu), row-level security manuel kurulmalı.
- AI analiz entegrasyonu henüz yok:
POST /ai/investigate-event endpoint'i şu anda audit_log ile entegre değil. Yapay zeka anomali tespiti yalnızca dbo.events üzerinde çalışıyor.
Sonuç
ShamashAi audit_log tablosu, retention politikasının dokunmadığı, append-only mimaride sonsuz forensics zinciri sağlar. KVKK Madde 12/6 denetim yükümlülüğünü karşılar, proje silinse bile olay zinciri kalır ve CSV export ile denetim dosyalarına kolayca aktarılır. Orta ölçekli Türk firmalarında compliance ve güvenlik ekipleri için kritik kanıt altyapısıdır.
Pilot programı 30 gün ücretsiz: shamashai.com.tr/iletisim