Cuma 16:37 — denetim toplantısında retention çelişkisi

Cuma öğleden sonra video call: CEO, hukuk müşaviri, IT ekibi. Ekrandaki Excel tablosunda 12 müşteri projesinin compliance gereksinimleri. "Finans firması A — BDDK düzenlemesi, 1 yıl event log saklama zorunlu. Yazılım şirketi B — 90 gün yeterli, disk maliyeti düşürülmeli. Hepsi aynı ShamashAi sunucusunda."

IT yöneticisi şu soruyu soruyor: "Global retention 90 gün yaparsak A'nın denetimi geçemeyiz. 365 gün yaparsak B'nin 20 GB günlük verisi 9 ay boyunca boşuna yer kaplayacak. ShamashAi'da proje bazında farklı saklama süreleri tanımlayabilir miyiz?"

Yanıt: evet. ShamashAi 1.3 sürümünden itibaren per-project retention yapılandırması sunar. Tek bir SIEM altyapısında her proje (şube, müşteri, iş birimi) kendi event saklama süresini taşır; gece çalışan otomatik cleanup job her projeye göre silme işlemini yapar.

ShamashAi retention mimarisi: dbo.projects.retention_days

ShamashAi'da her proje SQL Server'da dbo.projects tablosunda bir satırla temsil edilir:

sql SELECT project_id, name, retention_days, -- integer, default 90 created_at FROM dbo.projects WHERE active = 1;

retention_days kolonu projeye ait event'lerin (dbo.events) kaç gün saklanacağını belirler. Default değer 90 gündür; proje oluşturulurken POST /projects API'si bu değeri sistem varsayılanından alır.

Retention değerini değiştirme

Web UI'da Admin → Projeler → [Proje Adı] → Ayarlar → Retention bölümünden veya REST API üzerinden:

javascript // Node.js + Fastify client örneği const response = await fetch('https://shamashai.local/api/v1/projects/proj_8a3c/retention', { method: 'PUT', headers: { 'Authorization': Bearer ${apiToken}, 'Content-Type': 'application/json' }, body: JSON.stringify({ retention_days: 365 }) });

const result = await response.json(); console.log(result); // { project_id: "proj_8a3c", retention_days: 365, updated_at: "2026-09-21T09:15:17Z" }

API endpoint: PUT /projects/:id/retention

Body parametresi:

retention_days (integer, zorunlu): 30-730 arası değer (1 ay ile 2 yıl).

Yanıt:

HTTP 200 → güncelleme başarılı; yeni değer dönülür.
HTTP 400 → değer 30'dan küçük veya 730'dan büyükse hata.
HTTP 403 → kullanıcı retention yönetme yetkisine sahip değil (MANAGE_PROJECTS scope gerekli).

Otomatik cleanup job: gece 02:00'de event silme

ShamashAi, her gece saat 02:00'de (sunucu saatine göre) retention job'u çalıştırır. Job şu mantıkla çalışır:

sql -- Proje bazında eski event'leri bul ve sil DELETE e FROM dbo.events e INNER JOIN dbo.projects p ON e.project_id = p.project_id WHERE e.timestamp < DATEADD(DAY, -p.retention_days, GETUTCDATE()) AND p.active = 1;

Her proje için timestamp < NOW - retention_days koşulunu sağlayan event'ler silinir. Örnek:

Proje A retention_days = 365 → 2025-09-21'den eski event'ler silinir.
Proje B retention_days = 90 → 2026-06-23'ten eski event'ler silinir.

Silme işlemi DELETE komutuyla gerçekleşir; veriler SQL Server tarafından fiziksel olarak silinir (GDPR/KVKK Madde 7 uyumlu "unutulma" prensibi). Transaction log ve index rebuild süreci nedeniyle silme işlemi 1-5 dakika sürebilir.

Manuel cleanup tetikleme

Otomatik job'u beklemek istemiyorsanız — örneğin retention değerini 365 günden 90 güne düşürdükten hemen sonra disk alanı kazanmak için — manuel cleanup başlatabilirsiniz:

bash curl -X POST https://shamashai.local/api/v1/retention/run \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "project_id": "proj_8a3c" }'

Endpoint: POST /retention/run

Body (opsiyonel):

project_id (string): belirtilirse sadece o proje için cleanup. Boş bırakılırsa tüm aktif projeler işlenir.

Yanıt:

{ "job_id": "cleanup_20260921_091520", "started_at": "2026-09-21T09:15:20Z", "status": "running" }

Job arka planda çalışır; tamamlandığında dbo.audit_log tablosuna RETENTION_CLEANUP_COMPLETED event'i yazar:

sql SELECT TOP 5 event_type, metadata, created_at FROM dbo.audit_log WHERE event_type = 'RETENTION_CLEANUP_COMPLETED' ORDER BY created_at DESC;

Örnek metadata:

{ "project_id": "proj_8a3c", "deleted_rows": 1847293, "duration_seconds": 124, "oldest_remaining_timestamp": "2025-09-21T00:00:00Z" }

Retention istatistikleri: GET /retention/stats

Web UI'da Admin → Retention Durumu sayfası veya API üzerinden:

javascript const stats = await fetch('https://shamashai.local/api/v1/retention/stats', { headers: { 'Authorization': Bearer ${apiToken} } }).then(r => r.json());

console.log(stats);

Örnek yanıt:

{ "last_cleanup_at": "2026-09-21T02:00:14Z", "last_cleanup_duration_seconds": 187, "total_deleted_rows": 3821047, "projects": [ { "project_id": "proj_8a3c", "name": "Finans Firması A", "retention_days": 365, "event_count": 12847392, "oldest_event": "2025-09-22T03:14:01Z", "disk_usage_mb": 4821 }, { "project_id": "proj_2f1b", "name": "Yazılım Şirketi B", "retention_days": 90, "event_count": 3102841, "oldest_event": "2026-06-23T08:22:14Z", "disk_usage_mb": 1147 } ] }

disk_usage_mb, SQL Server'da sp_spaceused stored procedure kullanılarak hesaplanan tahmini değerdir (index dahil).

Retention-immune tablolar: audit_log, soar_actions, maintenance_windows

Retention silme işlemi sadece dbo.events tablosuna uygulanır. Aşağıdaki tablolar retention politikasından muaf tutulur:

1. dbo.audit_log: tüm kullanıcı ve sistem aktiviteleri (login, config değişiklikleri, retention cleanup job kayıtları). KVKK Madde 12 ve ISO 27001:2022 Annex A.5.33 uyumlu denetim kaydı amacıyla silinmez.

2. dbo.soar_actions: SOAR Engine tarafından tetiklenen otomatik aksiyonlar (IP blok, kullanıcı devre dışı, e-posta gönderimi). Incident response zincirinin delili olarak kalıcıdır.

3. dbo.maintenance_windows: planlı bakım pencereleri. Event akışını değil, operasyonel takvimi tutar; retention dışında bırakılmıştır.

Bu tabloların büyümesi genelde sınırlıdır (audit_log yıllık ~500 MB, soar_actions ~100 MB). Eğer manuel arşivleme gerekirse SQL Server native backup/restore kullanılabilir; ShamashAi web UI'da bu tablolar için ayrı retention yönetimi henüz sunulmamaktadır.

KVKK Madde 12 ve 5651 Kanunu uyumu

KVKK Madde 12: veri saklama süresi

KVKK Madde 12, kişisel verilerin "işleme amacının gerektirdiği süre kadar" saklanmasını şart koşar. ShamashAi event logları IP adresi, kullanıcı adı, cihaz hostname gibi kişisel veri içerebileceğinden, her müşterinin yasal danışmanıyla belirleyeceği süre projeye özel retention_days ile eşleştirilmelidir.

Örnek:

Finans sektörü: BDDK düzenlemesi 1 yıl log saklama → retention_days = 365.
E-ticaret: KVKK veri işleme amacı sona erince imha → retention_days = 90.
Kamu: Devlet Arşiv Hizmetleri Hakkında Yönetmelik çerçevesinde kurumsal değerlendirme → retention_days proje özelinde tanımlanır.

5651 Kanunu: 2 yıl trafik kaydı saklama

5651 sayılı İnternet Ortamında Yapılan Yayınların Düzenlenmesi ve Bu Yayınlar Yoluyla İşlenen Suçlarla Mücadele Edilmesi Hakkında Kanun, İnternet Erişim Sağlayıcıları ve Yer Sağlayıcıları için 2 yıl (730 gün) trafik log saklama zorunluluğu getirir.

ShamashAi v1.5 roadmap'te (Q4 2026 hedef), 5651 uyumlu yasal arşiv modu planlanmaktadır:

projects.legal_archive = true flag'i aktif projelerde event'ler 730 gün boyunca silinmez.
Arşiv sonrası event'ler dbo.events_archive tablosuna taşınır (read-only).
Adli talep durumunda GET /compliance/evidence endpoint'i arşivden veri çıkarır.

Şu anda (v1.4) 5651 gereksinimi için manuel çözüm: retention_days = 730 olarak ayarlanır; ancak performans ve disk kapasitesi planlaması müşteri sorumluluğundadır. ShamashAi dokümantasyonu 5651 arşiv modülü için daha fazla bilgi vermiyor; pilot kapsamında detay paylaşılır.

Senaryo: iki farklı müşteri, bir ShamashAi instance

Müşteri A — finansal hizmetler:

Proje adı: proj_fin_alpha
Cihaz sayısı: 220
Günlük event: ~80.000
Retention gereksinimi: 1 yıl (BDDK)
Ayar: PUT /projects/proj_fin_alpha/retention { retention_days: 365 }
Beklenen disk kullanımı: 80.000 × 365 × 2 KB ≈ 58 GB

Müşteri B — yazılım geliştirme:

Proje adı: proj_dev_beta
Cihaz sayısı: 80
Günlük event: ~25.000
Retention gereksinimi: 3 ay (KVKK minimum gereklilik)
Ayar: PUT /projects/proj_dev_beta/retention { retention_days: 90 }
Beklenen disk kullanımı: 25.000 × 90 × 2 KB ≈ 4.5 GB

Aynı ShamashAi sunucusunda toplam event tablosu boyutu ~62.5 GB; global 365 gün retention olsaydı 58 + 18.25 = 76.25 GB olacaktı. Per-project retention 13.75 GB tasarruf sağlar.

Gece 02:00'deki cleanup job: sql -- Müşteri A için DELETE FROM dbo.events WHERE project_id = 'proj_fin_alpha' AND timestamp < '2025-09-21'; -- ~0 satır silinir (1 yıl dolmadı)

-- Müşteri B için DELETE FROM dbo.events WHERE project_id = 'proj_dev_beta' AND timestamp < '2026-06-23'; -- ~25.000 satır silinir (dünkü event'ler 90. günü geçti)

Retention değişikliği audit log'a yazılır

Retention ayarını değiştirdiğinizde ShamashAi otomatik olarak dbo.audit_log tablosuna kayıt düşer:

sql SELECT event_type, user_email, metadata, created_at FROM dbo.audit_log WHERE event_type = 'PROJECT_RETENTION_UPDATED' ORDER BY created_at DESC;

Örnek satır:

{ "event_type": "PROJECT_RETENTION_UPDATED", "user_email": "admin@ornek.com", "metadata": { "project_id": "proj_8a3c", "old_retention_days": 90, "new_retention_days": 365, "reason": "BDDK denetim gereksinimi" }, "created_at": "2026-09-21T09:15:17Z" }

Bu kayıt, KVKK Madde 12 uyumlu "veri işleme süresi değişikliği" belgelendirmesi için kullanılabilir. ISO 27001:2022 Annex A.5.33 (information security event logging) gereksinimini karşılar.

C# .NET agent'tan retention sorgulaması

ShamashAi Windows Agent (.NET 8), merkezi API'dan proje retention ayarını periyodik olarak çeker ve lokal cache'ler. Agent kendi event buffer'ındaki eski event'leri göndermeden önce şu kontrolü yapar:

csharp using System.Net.Http.Json;

var client = new HttpClient(); client.DefaultRequestHeaders.Add("Authorization", $"Bearer {agentToken}");

var response = await client.GetAsync("https://shamashai.local/api/v1/projects/proj_8a3c"); var project = await response.Content.ReadFromJsonAsync<ProjectInfo>();

Console.WriteLine($"Retention: {project.RetentionDays} gün");

// Event timestamp kontrolü var cutoffDate = DateTime.UtcNow.AddDays(-project.RetentionDays); var eventsToSend = localBuffer .Where(e => e.Timestamp >= cutoffDate) .ToList();

Console.WriteLine($"{eventsToSend.Count} event gönderilecek, eski event'ler atlandı.");

Agent lokal disk'te retention süresinden eski event'leri göndermez; bu sayede bant genişliği ve sunucu yükü optimize edilir. Ancak agent'ın kendi lokal log dosyaları (C:\ProgramData\ShamashAI\logs) retention politikasına tabi değildir; agent config'de log_retention_days (default 7) ayrı yönetilir.

Limitler ve dürüst notlar

1. Retention minimum 30 gün: ShamashAi API 30 günden kısa retention_days değerini kabul etmez (HTTP 400). Bunun nedeni, behavioral anomaly detection modülünün (dbo.behavior_baselines) en az 21 gün öğrenme periyodu gerektirmesidir. Daha kısa süre anomaly tespitini bozar.

2. Silinen event'ler geri getirilemez: DELETE işlemi transaction log'a yazılır ama SQL Server RECYCLE BIN benzeri mekanizma yoktur. Retention değerini düşürmeden önce mevcut event'lerin dışa aktarılması (GET /reports/evidence-pack) önerilir.

3. 5651 yasal arşiv henüz yok: v1.5 roadmap'te; şu anda 730 gün retention manuel ayarlanmalı. Arşivlenen event'lerin adli talep sürecine özel arama/filtreleme UI'ı hazır değildir.

4. Audit log retention yönetimi yok: dbo.audit_log tablosu retention dışında; yıllarca büyüyebilir. Şu anda manuel SQL arşivleme gerekebilir (örn. 3 yıldan eski satırları ayrı tabloya taşıma).

5. Cleanup job tek thread: gece 02:00 job'u sırayla her projeyi işler. 10+ proje ve milyonlarca satır varsa job 10-15 dakika sürebilir; bu sürede DELETE kilit nedeniyle INSERT yavaşlayabilir (ancak pratik etkisi düşüktür, gece trafiği azdır).

Per-project retention, çok kiracılı SIEM mimarisinin olmazsa olmazıdır. ShamashAi'da her müşteri kendi KVKK değerlendirmesine göre saklama süresini ayarlayabilir; global bir retention değeri yüzünden uyumsuzluk veya gereksiz disk maliyeti riski ortadan kalkar.

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

Paylaş

ShamashAi'da Proje Bazlı Retention: Her Müşteri Kendi Saklama Süresini Belirler