Salı 02:58'de telefon çalar: "ShamashAi – CRITICAL: dc01.intra.firma.local DOWN"
Sistem yöneticisi telefonunu açar, gözlerini ovuşturur. Takvimde gece 03:00–05:00 arası dc01 üzerinde Windows Server yama bakımı not edilmiş. Planlı reboot, planlı servis duruşu. Ama ShamashAi bu bilgiyi bilmiyor; heartbeat kesildiğinde DEVICE_DOWN eventi tetikliyor, rule engine devreye giriyor, SMS ile PagerDuty'ye push gidiyor. Yönetici "Bakım var, normal" diye PagerDuty'de incident'ı suppress eder, tekrar uyumaya çalışır. 03:14'te ikinci alarm: "dc01 – HIGH CPU detected". Sunucu yeni açılmış, Windows Update çalışıyor. Üçüncü alarm 03:27: "dc01 – DISK_WRITE_SPIKE". Dördüncü... Telefonu susturur, sabahı bekler. Sabah mesai başında güvenlik sorumlusu başka bir dert yaşar: "Gece 03:00–05:00 arası dc01 loglarını neden göremiyorum? Eğer gerçek bir saldırı olduysa nasıl bileceğim?" Çünkü bazı SIEM'ler bakım penceresi için "o cihazdan ingest durdur" modeli sunar. Veri gelmesin, alarm çıkmasın. Ama log kaybı, compliance delili kaybı demektir. ShamashAi bu iki kötü senaryoyu birden çözmek için maintenance_windows modülünü tasarladı. Prensip basit: bakım penceresi sırasında alert evaluation atlanır, ingest devam eder. Sessizlik sağlanır, veri kaybı olmaz.Maintenance windows mantığı: scope, ingest, alert evaluation
ShamashAi'de bir maintenance window üç bileşenden oluşur:- Scope (kapsam):
project(tüm deployment),site(örn. "Ankara DC"),device(tek bir sunucu/switch)
- Zaman aralığı:
starts_at(ISO 8601, UTC+3 timezone ShamashAi SQL Server'da saklanır),ends_at
- Reason (sebep): "Windows Update", "Firewall Firmware Upgrade", "Network Switch Reboot"
.NET 8 agent, rsyslog forward, Winlogbeat, M365 webhook — her kaynaktan gelen log ShamashAi'nin /ingest/raw endpoint'ine POST edilir. dbo.events tablosuna yazılır, retention politikası normal işler.
2. Alert rule evaluator: Rule engine her 60 saniyede bir (configurable) dbo.events üzerinde rule'ları execute eder. Evaluator önce dbo.maintenance_windows tablosunu sorgular: "Bu event'in device_id veya site_id active bir window içinde mi?" Cevap evet ise rule evaluation skip edilir. Event tabloya yazılır, ama alarm tetiklenmez.
Yani gece 03:00–05:00 arası dc01'in DEVICE_DOWN, HIGH_CPU, DISK_WRITE_SPIKE, SERVICE_STOP event'leri dbo.events'e kaydedilir, ama bunlar için alarm çıkmaz. Sabah 05:01'de window kapanır, normal evaluation döner.
Maintenance window oluşturma: POST /maintenance-windows
ShamashAi Web Console'da Maintenance menüsü altında form var. Arka planda şu API call yapılır: javascript // Node.js Fastify – /maintenance-windows endpoint fastify.post('/maintenance-windows', { schema: { body: { type: 'object', required: ['scope', 'starts_at', 'ends_at', 'reason'], properties: { scope: { type: 'string', enum: ['project', 'site', 'device'] }, scope_id: { type: 'string' }, // site UUID veya device UUID, scope=project ise null starts_at: { type: 'string', format: 'date-time' }, ends_at: { type: 'string', format: 'date-time' }, reason: { type: 'string', maxLength: 500 } } } } }, async (request, reply) => { const { scope, scope_id, starts_at, ends_at, reason } = request.body; const user_id = request.user.id; // Zaman validasyonu const start = new Date(starts_at); const end = new Date(ends_at); if (end <= start) { return reply.code(400).send({ error: 'ends_at must be after starts_at' }); } // SQL Server'a kayıt const result = await sql.query` INSERT INTO dbo.maintenance_windows (id, scope, scope_id, starts_at, ends_at, reason, created_by, created_at) VALUES (NEWID(), ${scope}, ${scope_id}, ${start}, ${end}, ${reason}, ${user_id}, GETUTCDATE()) `; return reply.code(201).send({ message: 'Maintenance window created', id: result.recordset[0].id }); }); Parametreler:- scope:
"project"tüm ShamashAi deployment'ı susturur (nadiren kullanılır, tüm altyapı değişikliği senaryosu)."site"bir veri merkezi veya şubeyi susturur."device"tek bir cihazı susturur.
- scope_id: scope=device ise
dbo.devicestablosundakidevice_idUUID'si. scope=site isedbo.sitestablosundakisite_id. scope=project iseNULL.
- starts_at / ends_at: ISO 8601 formatında UTC zaman. ShamashAi dahili olarak SQL Server'da
DATETIMEOFFSETkullanır, ama Türkiye deployment'larında timezone Europe/Istanbul sabitlenmiş.
- reason: Serbest metin. Audit log'da görünür, compliance raporu oluştururken "Bu pencerede neden alarm yok?" sorusuna cevap.
device_id=a7f3c891-... için alert evaluation'ı durdurur.
Alert rule evaluator: window kontrolü
ShamashAi'nin rule engine C# .NET 8 worker service (background task). Her dakikadbo.events tablosunda son 60 saniyedeki event'leri tarar, dbo.alert_rules tanımlarını apply eder.
Şu pseudocode mantık çalışır:
csharp
// .NET 8 Worker Service – AlertEvaluatorService.cs
foreach (var evt in newEvents)
{
// 1) Active maintenance window var mı?
var activeWindow = await _db.MaintenanceWindows
.Where(w => w.StartsAt <= DateTime.UtcNow && w.EndsAt >= DateTime.UtcNow)
.Where(w =>
(w.Scope == "project") ||
(w.Scope == "site" && w.ScopeId == evt.SiteId) ||
(w.Scope == "device" && w.ScopeId == evt.DeviceId)
)
.FirstOrDefaultAsync();
if (activeWindow != null)
{
// Event tabloya yazıldı, ama rule evaluation SKIP
_logger.LogDebug($"Event {evt.Id} in maintenance window {activeWindow.Id}, skipping alert evaluation");
continue;
}
// 2) Normal rule evaluation
var matchedRules = await _ruleEngine.EvaluateEvent(evt);
foreach (var rule in matchedRules)
{
await _alertService.CreateAlert(evt, rule);
}
}
Dikkat: Window kontrolü event seviyesinde yapılır, rule seviyesinde değil. Yani bir device maintenance'daysa o device'ın HİÇBİR event'i alarm üretmez. Rule'da "sadece BRUTE_FORCE_DETECTED susturulsun" gibi granüler kontrol şu an yok. Eğer ihtiyaç varsa rule bazlı maintenance ("sadece HIGH_CPU rule'unu sustur") feature talebi olarak kaydedilir.
Geçmiş window'lar: audit-immune retention
Maintenance window kapandıktan sonradbo.maintenance_windows tablosunda ends_at < GETUTCDATE() olan kayıtlar silinmez. Çünkü bu kayıtlar audit kanıtıdır: "22 Ağustos 2026 00:00–06:00 arası dc01 için alarm neden çıkmadı?" sorusuna cevap.
ShamashAi'nin genel retention politikası (örn. 90 gün event tutma) maintenance_windows tablosunu etkilemez. Bu kayıtlar "retention-immune" olarak işaretlenmiş. Yıl boyunca tüm geçmiş pencereler saklanır. KVKK Madde 12 ve ISO 27001:2022 A.8.10 (log deletion) uyumluluğu için "X tarihinde alarm neden yok?" sorusu compliance audit'te çıkabilir. ShamashAi o tarihe ait maintenance window kaydını gösterir, soru kapanır.
Web Console'da Maintenance > History sekmesinde tüm geçmiş pencereler listelenir:
sql
-- SQL Server sorgusu
SELECT
mw.id,
mw.scope,
mw.scope_id,
d.hostname AS device_name,
s.name AS site_name,
mw.starts_at,
mw.ends_at,
mw.reason,
u.email AS created_by_email
FROM dbo.maintenance_windows mw
LEFT JOIN dbo.devices d ON mw.scope = 'device' AND mw.scope_id = d.id
LEFT JOIN dbo.sites s ON mw.scope = 'site' AND mw.scope_id = s.id
LEFT JOIN dbo.users u ON mw.created_by = u.id
WHERE mw.ends_at < GETUTCDATE()
ORDER BY mw.ends_at DESC;
Her kayıt için "Kim oluşturdu", "Ne zaman", "Neden" bilgileri görünür. Compliance raporu hazırlanırken GET /compliance/evidence endpoint'i bu tabloyu da okur, PDF'e ekler.
Scope seçenekleri: project, site, device
Scope = project
Tüm ShamashAi deployment'ı için alert evaluation durur. Çok nadir kullanılır: örneğin ShamashAi server'ın kendisi cluster node switch yapıyorsa veya SQL Server bakımı varsa. Bu durumda tüm device/site'lar için alarm çıkmaz. Ingest de etkilenir çünkü ShamashAi API down olabilir, ama agent'lar local buffer'da tutar, API ayağa kalkınca flush eder (loss yok).Scope = site
dbo.sites tablosunda her fiziksel lokasyon ("Ankara DC", "İstanbul Şube", "Bulut Ortamı AWS eu-central-1") tanımlı. Örneğin Ankara DC network switch firmware upgrade yapılıyor, tüm site 15 dakika offline. scope=site, scope_id=ankara_site_uuid ile window aç. O site'a bağlı tüm device'ların event'leri alert üretmez.
Scope = device
Tek bir sunucu, switch, firewall. En sık kullanılan mod. "dc01 üzerinde Windows Update" senaryosu bu kapsama girer. scope=device, scope_id=dc01_device_uuid. Overlap: Aynı device için birden fazla window açılmışsa (örn. manuel hata), evaluator "any active window" kontrolü yapar. Birisi varsa skip. Window'lar overlap edebilir, sorun değil.Log kaybı yok, compliance güvenli
Bazı SIEM'lerde maintenance mode "o cihazdan gelen log'ları ignore et" anlamına gelir. ShamashAi'de ingest asla durdurulamaz. Neden? 1. KVKK Madde 12 (Log kayıtlarının saklanması): Kişisel veri işleme log'ları silinmemeli. Eğer bakım sırasında bir kullanıcı DC'ye RDP ile bağlanıp yetkisiz işlem yaptıysa, o log compliance audit'te aranır. "Maintenance'daydı, almadık" cevabı kabul görmez. 2. ISO 27001:2022 A.8.15 (Logging): Kesintisiz loglama. Bakım penceresi log toplama durdurma gerekçesi olamaz. 3. Forensics: Saldırgan planlı bakım saatini biliyor olabilir, o pencereyi kullanarak saldırı yapabilir. Log yoksa tespit imkansız. ShamashAi bakım sırasında event'leridbo.events'e yazar, sadece alarm evaluation'ı skip eder. Sabah güvenlik analisti dbo.events tablosunda "maintenance window sırasında anomali var mı?" diye manuel sorgulayabilir:
sql
-- 22 Ağustos 2026 00:00–06:00 arası dc01'deki tüm event'ler
SELECT
event_id,
event_type,
source_ip,
username,
timestamp
FROM dbo.events
WHERE device_id = 'a7f3c891-22b4-4d8e-9c1a-5e3f8a90b2c7'
AND timestamp BETWEEN '2026-08-22 00:00:00' AND '2026-08-22 06:00:00'
ORDER BY timestamp;
Eğer 03:14'te BRUTE_FORCE_DETECTED event'i varsa, bu event tabloda durur, ama alarm gönderilmemiştir. Analist bunu görür, manuel inceleme yapar.
Örtüşen window'lar ve öncelik
Eğer bir device hem site-level hem device-level window'a giriyorsa? Evaluator "any active window" mantığı kullandığı için her ikisi de aynı etkiyi yapar. Öncelik sorunu yok, çünkü sonuç her durumda "skip alert evaluation". Window silinebilir mi? Evet, henüz başlamamış window DELETE edilebilir. Ama aktif veya geçmiş window'lar silinemez (audit koruma). Web Console'da "Cancel" butonustarts_at > GETUTCDATE() için aktif.
SOAR entegrasyonu: maintenance sırasında otomatik aksiyon durur
ShamashAi SOAR enginePOST /soar/block veya POST /soar/quarantine gibi endpoint'lerle otomatik aksiyon tetikler. Örnek rule: "Bir kullanıcı 10 dakika içinde 5 farklı IP'den RDP girişi yaptıysa, hesabı AD'de kilitle".
Bu rule evaluation maintenance window sırasında skip edildiği için SOAR aksiyonu da tetiklenmez. Yani bakım sırasında yanlışlıkla admin hesabı kilitlenmez, IP bloklanmaz. Bakım bittikten sonra normal kurallar devreye girer.
Önemli not: Eğer bir event maintenance window dışında tetiklendi ve SOAR aksiyonu kuyruğa eklendi (dbo.soar_actions tablosu, status=pending), sonra o device maintenance'a girerse? Şu anki implementasyonda kuyruk işlenir, çünkü aksiyon event anında oluşturulmuştu. Gelecek minor release'de "maintenance window varsa pending action'ları defer et" özelliği eklenebilir. Şu an dokümantasyonda bu durum için özel mantık yok; pilot deployment sırasında ihtiyaç üzerine tartışılır.
Kullanım senaryoları
Senaryo 1: Haftalık Windows Update (site-wide)
Her Cuma 22:00–02:00 arası tüm Windows sunucuları WSUS'tan patch alıyor. IT Manager her hafta manuel olarak: bash curl -X POST https://shamashai.firma.local/maintenance-windows \ -H "Authorization: Bearer $TOKEN" \ -d '{ "scope": "site", "scope_id": "ankara-dc-site-uuid", "starts_at": "2026-08-22T22:00:00+03:00", "ends_at": "2026-08-23T02:00:00+03:00", "reason": "Haftalık Windows Update (WSUS)" }' O site'a bağlı 80 sunucunun 4 saat boyunca reboot, service stop, high CPU event'leri alarm üretmez.Senaryo 2: Firewall firmware upgrade (device)
Ağ yöneticisi pfsense firewall'a 23:00–23:30 firmware yüklüyor: { "scope": "device", "scope_id": "pfsense-fw01-uuid", "starts_at": "2026-08-21T23:00:00+03:00", "ends_at": "2026-08-21T23:30:00+03:00", "reason": "pfSense 2.7.2 upgrade" } 23:10'da firewall reboot olur, ShamashAiDEVICE_DOWN eventi alır, ama alarm çıkmaz. 23:30'da window kapanır, 23:31'de heartbeat gelmezse tekrar alarm verir.
Senaryo 3: Veri merkezi UPS testi (project-wide)
Yılda bir kez tüm DC elektrik kesilip UPS testi yapılıyor. Tüm ekipman 15 dakika down: { "scope": "project", "scope_id": null, "starts_at": "2026-09-15T14:00:00+03:00", "ends_at": "2026-09-15T14:20:00+03:00", "reason": "Veri merkezi UPS failover testi" } Bu süre tüm ShamashAi alert evaluation durur. Kritik senaryo olduğu için nadiren kullanılır.Web Console: maintenance takvimi
Next.js frontend'de Maintenance menüsünde FullCalendar benzeri görünüm var. Önümüzdeki window'lar takvimde gösterilir:- Yeşil: Gelecek window (henüz başlamadı)
- Sarı: Aktif window (şu an devam ediyor)
- Gri: Geçmiş window
Limitler ve dürüst notlar
- Rule bazlı granüler sessizlik yok: Şu an "sadece HIGH_CPU rule'unu sustur, BRUTE_FORCE tetiklensin" yapılamıyor. Window tüm rule'ları etkiler. Feature talebi kaydediliyor.
- Recurring window yok: Her hafta Cuma 22:00–02:00 için manuel pencere açman gerekir. Gelecek release'de "recurring schedule" eklenebilir, şu an yok.
- Pending SOAR action'lar maintenance'da defer edilmiyor: Event tetiklendikten sonra device maintenance'a girse bile, kuyruktaki SOAR aksiyonu işlenir. Bu durum edge case, pilot sürecinde davranış netleştirilir.
- Timezone manuel: ShamashAi SQL Server'da UTC saklıyor, ama Türkiye deployment'larında timezone Europe/Istanbul sabit. Çok timezone'lu global firma varsa manuel conversion gerekir.
- Overlap validasyonu yok: Aynı device için 10 tane overlap eden window açabilirsin, sistem "any active window" dediği için çalışır ama temiz değil. UI'da "Bu device zaten maintenance'da" uyarısı gelecek release'de eklenebilir.
Planlı bakım sessizliği için telefon susturucu değil, compliance-safe log yönetimi gerekiyorsa ShamashAi maintenance_windows modülü kullanıma hazır. Pilot programı 30 gün ücretsiz: shamashai.com.tr/iletisim