Cuma günü saat 14:32'de gelen şikâyet
Yönetici paneline giriş yaptığınız an Slack'ten bir mesaj geliyor. Müşteri A'nın hukuk müşaviri, geçen ay imzalanan sözleşmeyi hatırlatıyor: "KVKK kapsamında erişim loglarını 180 gün saklamakla yükümlüyüz, ama sistemde sadece 90 günlük veri görüyorum." Aynı gün başka bir müşteri, Müşteri B'nin IT sorumlusu, tam tersi talepte bulunuyor: "Biz SaaS şirketi olarak disk maliyetlerini kısmak istiyoruz; 30 günlük event yeterli." İki müşteri, iki farklı gereksinim; ama ShamashAi'ın eski sürümünde tek bir global retention ayarı vardı. Her iki müşterinin de aynı on-prem instance'da bulunduğunu varsayarsak, bir taraf memnuniyetsiz kalıyordu.
Bu senaryo, çok kiracılı (multi-tenant) veya çok projeli SIEM dağıtımlarında klasik bir baş ağrısıdır. KVKK Madde 12, kişisel verilerin işlenme amacı ortadan kalktığında veya ilgili mevzuatta öngörülen saklama süresi dolduğunda silinmesini, yok edilmesini ya da anonim hâle getirilmesini gerektirir. Ancak "ilgili mevzuat" sektörden sektöre değişir: Bankacılık Kanunu bazı logları 5 yıl saklamayı emreder, sağlık sektöründe hasta kayıtları 15 yıl tutulur, e-ticaret şirketlerinde ise fatura kayıtları 10 yıldır. Tek bir retention politikası, tüm müşterilere uymaz.
ShamashAi'nin
per-project retention özelliği tam bu sorunu çözer: Her proje (projects tablosundaki her satır) kendi
retention_days değerine sahip olabilir. Varsayılan 90 gün, ama PUT /projects/:id/retention çağrısıyla dilediğiniz projeyi 30, 180, 365 hatta 730 güne çıkarabilirsiniz. Gece çalışan scheduled job,
dbo.events tablosundaki kayıtları
project_id bazında süzer ve
timestamp < NOW() - retention_days koşulunu sağlayan satırları siler. Sonuç: Müşteri A'nın event'leri 180 gün kalır, Müşteri B'ninki 30 günde temizlenir; disk ve lisans maliyetleri optimize edilir, uyumluluk sağlanır.
Mimari: projects.retention_days kolonu ve gece cleanup job'ı
ShamashAi'ın SQL Server veritabanında
dbo.projects tablosu, her müşteri projesini bir satırda tutar. Bu tabloya eklenen
retention_days INT NOT NULL DEFAULT 90 kolonu, proje bazlı saklama süresini belirler. Örneğin:
sql
SELECT project_id, name, retention_days
FROM dbo.projects;
-- Sonuç:
-- project_id | name | retention_days
-- 1 | BankaA_Prod | 180
-- 2 | SaasB_Dev | 30
-- 3 | HastaneC_Main | 365
Her gece saat 02:00'de (sistem zaman dilimi Europe/Istanbul) çalışan Node.js scheduled job (
src/jobs/retention-cleanup.js) şu mantığı işletir:
javascript
// ShamashAi Node.js retention cleanup job (Fastify zamanlanmış görev)
const sql = require('mssql');
const { logger } = require('../utils/logger');
async function runRetentionCleanup() {
const conn = await sql.connect();
const projects = await conn.request()
.query('SELECT project_id, retention_days FROM dbo.projects WHERE retention_days > 0');
let totalDeleted = 0;
for (const proj of projects.recordset) {
const cutoffDate = new Date();
cutoffDate.setDate(cutoffDate.getDate() - proj.retention_days);
const result = await conn.request()
.input('projectId', sql.Int, proj.project_id)
.input('cutoff', sql.DateTime2, cutoffDate)
.query(`
DELETE FROM dbo.events
WHERE project_id = @projectId AND timestamp < @cutoff
`);
totalDeleted += result.rowsAffected[0];
logger.info(
Project ${proj.project_id}: deleted ${result.rowsAffected[0]} events older than ${proj.retention_days} days);
}
// Son cleanup zamanını ve toplam satır sayısını dbo.system_stats'a yaz
await conn.request()
.input('lastRun', sql.DateTime2, new Date())
.input('deletedRows', sql.Int, totalDeleted)
.query(`
UPDATE dbo.system_stats
SET last_retention_cleanup = @lastRun,
last_cleanup_deleted_rows = @deletedRows
WHERE stat_key = 'retention'
`);
await conn.close();
return totalDeleted;
}
module.exports = { runRetentionCleanup };
Bu job, sadece
dbo.events tablosunu temizler.
dbo.audit_log,
dbo.soar_actions ve
dbo.maintenance_windows tabloları
retention-immune kabul edilir; çünkü audit_log ISO 27001:2022 Annex A.8.15 (Logging) ve KVKK Madde 12 gereği "silme işleminin kendisinin de kanıtı" niteliğindedir ve sınırsız saklanmalıdır. SOAR aksiyonları (örneğin bir IP'yi bloke etme kararı) ve bakım pencereleri de benzer şekilde organizasyonun operasyonel hafızasıdır ve retention kapsamı dışındadır.
PUT /projects/:id/retention ile retention süresini ayarlama
ShamashAi web panelinde, Settings → Projects → [Proje Adı] → Retention Policy ekranından veya doğrudan API üzerinden retention günü değiştirebilirsiniz:
bash
curl -X PUT https://shamashai.local/api/projects/2/retention \
-H "Authorization: Bearer <token>" \
-H "Content-Type: application/json" \
-d '{ "retention_days": 30 }'
Yanıt:
{
"project_id": 2,
"name": "SaasB_Dev",
"retention_days": 30,
"updated_at": "2026-08-14T09:15:48.123Z",
"updated_by": "admin@shamashai.local"
}
API endpoint'i,
retention_days değerini 1 ile 3650 (yaklaşık 10 yıl) arasında kabul eder. Sıfır değeri girilirse sistem default 90 güne döner. Değişiklik hemen
dbo.projects tablosuna yazılır, ancak asıl cleanup o gece saat 02:00'deki scheduled job çalışana kadar gerçekleşmez. Eğer acil bir temizlik yapmanız gerekiyorsa (örneğin disk alanı kritik seviyeye yaklaştıysa), manuel tetikleyici endpoint'i kullanabilirsiniz:
bash
curl -X POST https://shamashai.local/api/retention/run \
-H "Authorization: Bearer <token>"
Bu endpoint, gece job'ını anında çalıştırır ve yanıtta temizlenen toplam satır sayısını döndürür:
{
"status": "completed",
"deleted_rows": 142389,
"duration_ms": 8234,
"timestamp": "2026-08-14T09:17:12.456Z"
}
GET /retention/stats ile retention durumunu izleme
Retention politikalarının işleyişini takip etmek için ShamashAi'nin
GET /retention/stats endpoint'i, her proje için mevcut event sayısını, en eski event tarihini ve son cleanup zamanını raporlar:
bash
curl -X GET https://shamashai.local/api/retention/stats \
-H "Authorization: Bearer <token>"
Yanıt:
{
"last_cleanup_run": "2026-08-14T02:00:15.789Z",
"last_cleanup_deleted_rows": 142389,
"projects": [
{
"project_id": 1,
"name": "BankaA_Prod",
"retention_days": 180,
"current_event_count": 8234567,
"oldest_event_timestamp": "2026-02-15T14:23:11.000Z",
"disk_usage_mb": 3421
},
{
"project_id": 2,
"name": "SaasB_Dev",
"retention_days": 30,
"current_event_count": 123456,
"oldest_event_timestamp": "2026-07-15T09:12:33.000Z",
"disk_usage_mb": 87
}
]
}
Bu istatistik, capacity planning ve maliyet optimizasyonu için kritiktir. Örneğin BankaA_Prod projesinin 3,4 GB disk kullandığını görüp, diğer projelerle kıyaslayarak donanım yükseltme kararı alabilirsiniz.
Audit log ve retention-immune tablolar
KVKK Madde 12 ve ISO 27001:2022 Annex A.8.15, "veri silme işleminin kendisinin de denetlenebilir olmasını" gerektirir. Bu nedenle
dbo.audit_log tablosundaki kayıtlar (örneğin "Admin kullanıcısı retention_days değerini 90'dan 30'a düşürdü" gibi)
asla silinmez. Benzer şekilde:
- dbo.soar_actions: SOAR motoru tarafından alınan otomatik aksiyonlar (IP bloke, hesap kilitleme, ticket açma) organizasyonun güvenlik tepki geçmişidir; 5 yıl boyunca saklanmalıdır.
- dbo.maintenance_windows: Planlı bakım pencereleri sırasında bazı alarmlar susturulur; bu kararın kendisi de denetim kapsamındadır.
- dbo.behavior_baselines: Davranış anomalisi modellerinin eğitim verileri; silinirse model yeniden baseline öğrenmek zorunda kalır.
Bu tablolar retention job'ının WHERE koşuluna dahil edilmez. Sadece
dbo.events tablosu (ham SIEM event'leri) ve
dbo.incident_groups tablosu (tetiklenen alarmların gruplanmış halleri) temizlenir.
dbo.incident_groups için de ayrı bir
retention_days_incidents kolonu planlanıyor; şu an incident'ler event'lerle aynı retention'a tabi.
5651 sayılı kanun ve 2 yıllık yasal arşiv (v1.5 roadmap)
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", internet servis sağlayıcılarını ve içerik sağlayıcılarını trafik loglarını
2 yıl süreyle saklamaya mecbur eder. Bu gereksinim, özellikle Türkiye'de faaliyet gösteren SaaS platformları, hosting firmaları ve telekom operatörleri için geçerlidir.
ShamashAi'ın mevcut per-project retention özelliği, 730 güne (2 yıl) kadar retention_days ayarına izin verse de,
5651 yasal arşiv modülü henüz ayrı bir feature olarak sunulmuyor. v1.5 roadmap'inde planlanan özellik şöyle çalışacak:
1.
dbo.projects tablosuna
legal_archive_enabled BIT kolonu eklenir.
2.
legal_archive_enabled = 1 olan projeler için, retention job normal event'leri silerken, belirli
event_type değerlerine sahip kayıtları (örneğin AUTH_FAIL_USER, M365_RISKY_SIGNIN, KNOWN_BAD_IP)
dbo.legal_archive tablosuna taşır.
3. Legal archive tablosu, sıkıştırılmış (compressed) ve salt okunur (read-only) bir yapıda tutulur; disk maliyetini %70 azaltır.
4. Adli talep geldiğinde
GET /compliance/evidence?project_id=X&start_date=...&end_date=... endpoint'i, hem canlı
dbo.events hem de
dbo.legal_archive tablolarını birleştirerek 2 yıllık veriyi sunar.
Şu an bu modül yoktur; 2 yıllık arşiv gereksinimi olan müşteriler,
retention_days=730 ayarlayarak tüm event'leri canlı tabloda tutmalıdır. Bu durum disk maliyetini artırır; pilot kapsamında detay paylaşılacaktır.
KVKK Madde 12 uyumluluğu ve silme kanıtı
KVKK Madde 12, "veri sorumlusu, kişisel verileri silme yükümlülüğünü yerine getirdiğini kanıtlamakla sorumludur" der. ShamashAi, her retention cleanup job'ı sonrasında
dbo.audit_log tablosuna bir kayıt düşer:
sql
INSERT INTO dbo.audit_log (action, user_id, project_id, details, timestamp)
VALUES (
'RETENTION_CLEANUP',
NULL, -- Otomatik job, kullanıcı yok
1,
'142389 satır silindi (cutoff: 2026-02-15)',
GETDATE()
);
Eğer bir veri sahibi (data subject) "verilerimin silindiğini kanıtlayın" talebinde bulunursa,
GET /compliance/evidence?user_id=... endpoint'i, o kullanıcıya ait event'lerin hangi tarihte silindiğini audit_log kayıtlarından çekerek bir PDF rapor oluşturur. Bu rapor, KVKK Madde 13 kapsamındaki "veri sahibi hakları" yanıtının bir parçasıdır.
Proje bazlı retention'ın yan etkileri: join sorguları ve raporlama
Farklı projeler farklı retention süreleri kullandığında, cross-project raporlar (örneğin "Tüm projelerde son 120 günde en çok brute-force saldırısı olan IP'ler") tutarsız sonuçlar verebilir. Örneğin Proje A'nın retention'ı 180 gün, Proje B'ninki 30 günse, sorgu Proje B'den sadece 30 günlük veriyi görür; bu da istatistiksel karşılaştırmayı bozar.
ShamashAi'ın raporlama modülü (
GET /reports/evidence-pack), her projenin
retention_days değerini rapor metadata'sına ekler ve kullanıcıyı uyarır:
{
"report_id": "rpt_20260814_091548",
"projects_included": [
{ "project_id": 1, "name": "BankaA_Prod", "retention_days": 180, "data_coverage": "full" },
{ "project_id": 2, "name": "SaasB_Dev", "retention_days": 30, "data_coverage": "partial (30 days only)" }
],
"warning": "Projeler arasında retention farklılıkları var; istatistikler tutarsız olabilir."
}
Bu şeffaflık, yanlış yorumlamayı önler.
Limitler ve dürüst notlar
- 5651 yasal arşiv modülü henüz yok: 2 yıllık yasal arşiv için şu an tüm event'leri
retention_days=730 ile canlı tabloda tutmalısınız; disk maliyeti artar. v1.5'te sıkıştırılmış legal archive tablosu gelecek.
- Incident'ler için ayrı retention yok:
dbo.incident_groups tablosu şu an event'lerle aynı retention'a tabi. Bazı müşteriler "event'leri 30 gün, ama incident kayıtlarını 1 yıl tutmak" ister; bu özellik roadmap'te.
- Cross-project raporlar tutarsız olabilir: Farklı retention sürelerine sahip projeler arasında karşılaştırmalı raporlar hazırlarken, "data_coverage" uyarılarına dikkat edin.
- Manuel cleanup disk I/O yükü:
POST /retention/run endpoint'i senkron çalışır ve büyük event tablolarında (10M+ satır) 30-60 saniye sürebilir; production saatlerinde dikkatli kullanın.
- Timezone: Europe/Istanbul sabit: Scheduled job saat 02:00 İstanbul saatinde çalışır; farklı timezone'da deployment yapılırsa job saatini manuel ayarlamanız gerekir.
Sonuç: Uyumluluğu esnek tut, maliyeti optimize et
ShamashAi'nin per-project retention özelliği, çok müşterili veya çok bölümlü SIEM dağıtımlarında hayat kurtarır. Bankacılık müşteriniz 180 gün, SaaS müşteriniz 30 gün retention istediğinde, tek bir ayar dosyasına sığmaya çalışmak yerine, her projeye kendi retention_days değerini verirsiniz. Gece job otomatik temizler, audit_log her şeyi kaydeder, GET /retention/stats ile durumu izlersiniz. KVKK Madde 12 uyumluluğu sağlanır, disk maliyetleri optimize edilir.
Pilot programı 30 gün ücretsiz: shamashai.com.tr/iletisim
