ShamashAi Maintenance Windows: Planlı bakımda alarm yok, log kaybı yok

Pazar 02:47'de gelen SMS: "DC01 erişilemez, CRITICAL"

Senaryoyu biliyor musunuz? Pazar gecesi 02:30'da Active Directory domain controller'ınız için Windows Update planlamışsınız. Makine restart atıyor, 15 dakika offline. Bu sırada ShamashAi'nizin heartbeat kuralı tetikliyor: "dc01.firma.local 5 dakikadır heartbeat göndermiyor, severity=CRITICAL". SMS ile IT Müdürü'nü uyandırıyorsunuz, o da sysadmin'i arıyor. Herkes uyanık, herkes telaşlı. Sonra hatırlıyorlar: "Ha, bu gece planlı bakımdı zaten."

Alternatif senaryo daha kötü: Bakım öncesi "o zaman SIEM'i kapatalım, alarm gelmesin" diyorsunuz. Agent'ları durduruyorsunuz veya firewall'da 514 portunu kapatıyorsunuz. Bakım 3 saat sürüyor. Bu 3 saat içinde başka bir sunucuda gerçek bir brute-force saldırısı başlıyor. Siz onu sabah 09:00'da fark ediyorsunuz, 6 saat geç.

ShamashAi'nin Maintenance Windows özelliği bu iki felakete de çözüm getirir: Planlı bakım penceresini tanımlarsınız, alert değerlendirmesi atlanır, ama ingest devam eder. Veri kaybı yok, yanlış alarm yok.

Maintenance windows nedir, nasıl çalışır?

Maintenance window, ShamashAi'de dbo.maintenance_windows tablosunda saklanan, başlangıç-bitiş zamanı olan sessiz penceredir. Şu üç scope'ta tanımlanabilir:

• project: Tüm sistem (ShamashAi instance'ının izlediği her şey) sessiz olur.
• site: Belirli bir site (örn. "Ankara Veri Merkezi") sessiz olur. Site altındaki tüm cihazlar etkilenir.
• device: Tek bir cihaz (örn. dc01.firma.local) sessiz olur.

Window aktifken ShamashAi'nin alert rule evaluator motor'u, kapsama giren cihazlardan gelen event'leri işler, dbo.events tablosuna yazar, ama alert kurallarını skip eder. Yani:

• event_type=HEARTBEAT_MISSING tetiklenmez.
• event_type=BRUTE_FORCE_DETECTED tetiklenmez.
• event_type=CERT_EXPIRING tetiklenmez.
• SOAR action'ları çalışmaz (çünkü alert yok).

Ama event'in kendisi dbo.events'e yazılır, zaman damgası korunur, sonradan sorgulayabilirsiniz. Dashboard'da da görebilirsiniz, sadece alarm üretilmez.

Window bittiğinde (ends_at timestamp'i geçtiğinde) sistem normal operasyona döner, sonraki event'lerde alert kuralları tekrar değerlendirilir.

Teknik detay: POST /maintenance-windows

Maintenance window oluşturmak için ShamashAi API'sine şu şekilde istek atarsınız:

javascript // Node.js örnek (Fastify client) const response = await fetch('https://shamashai.firma.local/maintenance-windows', { method: 'POST', headers: { 'Authorization': Bearer ${sessionToken}, 'Content-Type': 'application/json' }, body: JSON.stringify({ scope: 'device', // 'project' | 'site' | 'device' scope_id: 'dc01.firma.local', // device hostname veya site_id starts_at: '2026-10-06T02:00:00Z', ends_at: '2026-10-06T05:00:00Z', reason: 'Windows Server 2022 Cumulative Update KB5034129', created_by: 'ahmet.yilmaz@firma.com.tr' }) });

const window = await response.json(); console.log('Window ID:', window.id);

Parametreler:

• scope: project, site, veya device. Project seçerseniz scope_id boş bırakılır veya null gönderilir.
• scope_id: Device hostname'i (örn. dc01.firma.local) veya site UUID'si. Scope=project ise gerekli değil.
• starts_at / ends_at: ISO 8601 UTC timestamp. ShamashAi sunucusu bu zaman aralığını kullanır. Başlangıç geçmişte olabilir ("bakım başladı ama window açmayı unuttum" durumu için), bitiş mutlaka gelecekte olmalı.
• reason: Serbest metin. Audit log'da ve UI'da görünür. Örn. "Oracle Database 19c patch", "F5 BigIP firmware upgrade", "Network switch reboot".
• created_by: Kullanıcı e-posta veya username. Audit için.

Yanıt:

{ "id": "mw_2026100612873", "scope": "device", "scope_id": "dc01.firma.local", "starts_at": "2026-10-06T02:00:00Z", "ends_at": "2026-10-06T05:00:00Z", "reason": "Windows Server 2022 Cumulative Update KB5034129", "created_by": "ahmet.yilmaz@firma.com.tr", "created_at": "2026-10-02T09:15:21Z", "status": "scheduled" }

Status değerleri:

• scheduled: Henüz başlamadı (şu anki zaman < starts_at).
• active: Şu an aktif (şu anki zaman >= starts_at ve <= ends_at).
• completed: Bitti (şu anki zaman > ends_at).

Alert rule evaluator'da window kontrolü

ShamashAi'nin alert motoru her yeni event için şu kontrolü yapar:

csharp // .NET 8 Alert Evaluator (C#) public async Task<bool> ShouldEvaluateAlert(Event evt) { var now = DateTime.UtcNow; var activeWindows = await _db.MaintenanceWindows .Where(w => w.StartsAt <= now && w.EndsAt >= now) .ToListAsync();

foreach (var window in activeWindows) { if (window.Scope == "project") return false; // Tüm sistem sessiz

if (window.Scope == "site" && evt.SiteId == window.ScopeId) return false; // Bu site sessiz

if (window.Scope == "device" && evt.DeviceHostname == window.ScopeId) return false; // Bu cihaz sessiz }

return true; // Window yok, alert kural değerlendirmesi yap }

Yani event dbo.events'e yazıldıktan sonra, alert kuralları çalıştırılmadan önce bu fonksiyon çalışır. False dönerse alert atlanır, event session_id ile ilişkilendirilmez, dbo.incident_groups'a eklenmez.

Site ve project scope kullanım örnekleri

Site scope: Ankara veri merkezi planlı elektrik kesintisi

Ankara ofisinizdeki tüm sunucular aynı UPS'e bağlı. Cumartesi 14:00-16:00 arası elektrik panosu bakımı var, UPS test edilecek. Tüm sunucular 10 dakika kapatılacak. Site UUID'si site_ankara_dc olsun:

javascript await fetch('https://shamashai.firma.local/maintenance-windows', { method: 'POST', headers: { 'Authorization': Bearer ${token}, 'Content-Type': 'application/json' }, body: JSON.stringify({ scope: 'site', scope_id: 'site_ankara_dc', starts_at: '2026-10-05T11:00:00Z', // Türkiye 14:00 = UTC 11:00 ends_at: '2026-10-05T13:00:00Z', // Türkiye 16:00 = UTC 13:00 reason: 'Ankara DC elektrik panosu bakımı, UPS testi', created_by: 'mehmet.kaya@firma.com.tr' }) });

Bu pencere aktifken Ankara'daki tüm cihazlardan gelen HEARTBEAT_MISSING, BACKUP_FAILED, DISK_FULL gibi alert'ler atlanır. İstanbul veya İzmir site'lerindeki cihazlar etkilenmez.

Project scope: Yıllık DR testi

Yılda bir disaster recovery testi yapıyorsunuz. Tüm sistemleri kapatıp yedek data center'dan başlatıyorsunuz. Test 4 saat sürüyor. Bu süre boyunca "her şey patlıyor" alarmı istemiyorsunuz:

javascript await fetch('https://shamashai.firma.local/maintenance-windows', { method: 'POST', headers: { 'Authorization': Bearer ${token}, 'Content-Type': 'application/json' }, body: JSON.stringify({ scope: 'project', scope_id: null, // veya göndermeyin starts_at: '2026-12-15T06:00:00Z', ends_at: '2026-12-15T10:00:00Z', reason: 'Yıllık DR testi - production down', created_by: 'cto@firma.com.tr' }) });

Bu window aktifken ShamashAi hiçbir alert üretmez. Ama ingest devam eder, yani DR test sırasında yedek DC'den gelen loglar dbo.events'e yazılır, sonra analiz edebilirsiniz.

Geçmiş window'lar: audit ve retention-immune

Window bitiş zamanı (ends_at) geçtikten sonra status=completed olur. ShamashAi'nin retention policy (örn. "90 günden eski event'leri sil") bu window kayıtlarını silmez. Çünkü maintenance window bir audit kaydıdır, KVKK Madde 12 ve ISO 27001:2022 Annex A.12.4.1 (log retention) kapsamında saklanmalıdır.

Geçmiş window'ları dbo.audit_log tablosunda da görebilirsiniz:

sql SELECT al.timestamp, al.action, al.user_email, al.details FROM dbo.audit_log al WHERE al.action = 'MAINTENANCE_WINDOW_CREATED' AND al.timestamp >= '2026-09-01' ORDER BY al.timestamp DESC;

Çıktı örnek:

2026-10-02 09:15:21 MAINTENANCE_WINDOW_CREATED ahmet.yilmaz@firma.com.tr {"scope":"device","scope_id":"dc01.firma.local","starts_at":"2026-10-06T02:00:00Z","reason":"Windows Update"} 2026-09-28 14:32:10 MAINTENANCE_WINDOW_CREATED mehmet.kaya@firma.com.tr {"scope":"site","scope_id":"site_ankara_dc","starts_at":"2026-10-05T11:00:00Z","reason":"Elektrik panosu bakımı"}

Bu sayede denetimde "15 Ekim'de neden 3 saat alarm yoktu?" sorusuna "Maintenance window vardı, işte audit kaydı" diyebilirsiniz.

Dashboard ve bildirim

ShamashAi web arayüzünde (Next.js frontend) Maintenance sekmesi altında aktif ve gelecekteki window'ları görebilirsiniz:

• Aktif pencereler: Kırmızı badge, "ŞU AN AKTİF" yazısı. Scope ve kalan süre görünür.
• Planlanan pencereler: Gri badge, başlangıç zamanına kalan süre (örn. "4 gün 2 saat sonra").
• Geçmiş pencereler: Yeşil badge, "TAMAMLANDI" yazısı, süre bilgisi.

Window başladığında ShamashAi dbo.events tablosuna event_type=MAINTENANCE_WINDOW_STARTED kaydı atar. Bu event'i kurallarınıza ekleyerek Slack/Teams bildirimi gönderebilirsiniz (örn. "Ankara DC bakımı başladı, 2 saat alarm yok").

Window bittiğinde event_type=MAINTENANCE_WINDOW_ENDED event'i oluşur, benzer şekilde bildirim yapabilirsiniz.

İptal ve düzenleme

Window henüz başlamamışsa (status=scheduled) DELETE /maintenance-windows/:id ile iptal edebilirsiniz. Window aktif veya tamamlanmışsa silinemez, audit integrity için.

Window zamanını değiştirmek isterseniz (örn. "bakım 1 saat uzadı") PATCH /maintenance-windows/:id endpoint'i kullanılır:

javascript await fetch(https://shamashai.firma.local/maintenance-windows/${windowId}, { method: 'PATCH', headers: { 'Authorization': Bearer ${token}, 'Content-Type': 'application/json' }, body: JSON.stringify({ ends_at: '2026-10-06T06:00:00Z', // 1 saat uzattık reason: 'Windows Server 2022 Cumulative Update KB5034129 - patch rollback gerekti, +1 saat' }) });

ShamashAi dokümantasyonu PATCH sınırlamaları hakkında daha fazla bilgi vermiyor; pilot kapsamında detay paylaşılır. Muhtemelen window aktifken sadece ends_at ve reason güncellenebilir, starts_at ve scope değiştirilemez.

SOAR action'ları ve maintenance windows

Maintenance window aktifken alert üretilmediği için dbo.soar_actions tablosuna da kayıt düşmez. Yani:

• POST /soar/block çağrılmaz (brute-force tespit edilse bile).
• POST /soar/quarantine çağrılmaz (malware event'i olsa bile).

Bu çoğu zaman istenen davranıştır (bakım sırasında SOAR'ın cihazı karantinaya almasını istemezsiniz). Ama bazı durumlarda "maintenance'teyiz ama kritik güvenlik event'lerini yine de işle" isterseniz, ShamashAi şu an bunu desteklemiyor. Bu bir limitasyondur, aşağıda detaylı anlatacağız.

Compliance ve kanıt değeri

KVKK Madde 12 (Veri Güvenliğine İlişkin Yükümlülükler) ve ISO 27001:2022 Annex A.12.4.1 (Event logging) gereği, bakım pencerelerinin kim tarafından, ne zaman, neden oluşturulduğu kanıtlanabilir olmalıdır.

ShamashAi'nin GET /compliance/evidence endpoint'i maintenance window kayıtlarını da içerir:

javascript const evidence = await fetch('https://shamashai.firma.local/compliance/evidence?start_date=2026-09-01&end_date=2026-09-30', { headers: { 'Authorization': Bearer ${token} } }).then(r => r.json());

console.log(evidence.maintenance_windows); // [ // { id: 'mw_...', scope: 'device', reason: '...', created_by: '...', hash: 'sha256:...' } // ]

Her window kaydı SHA-256 hash ile imzalanır, sonradan değiştirilmediğini kanıtlar. Denetim sırasında bu hash'i SQL Server'dan direkt çekip karşılaştırabilirsiniz.

Limitler ve dürüst notlar

• Kısmi scope yok: "dc01.firma.local için sadece HEARTBEAT_MISSING alert'lerini atla, BRUTE_FORCE devam etsin" yapamazsınız. Window aktifse o scope'taki tüm alert'ler atlanır.
• Çakışan window'lar: Aynı cihaz için iki window tanımlarsanız (örn. site-level + device-level), ShamashAi her ikisini de kontrol eder, biri aktifse alert atlanır. Fakat bu durumda hangi window'un "kazandığı" audit log'da açık değildir.
• SOAR bypass yok: Maintenance window aktifken kritik güvenlik event'leri (örn. KNOWN_BAD_IP) için "yine de SOAR çalıştır" seçeneği şu an yok. Gelecek sürümlerde bypass_soar: false parametresi eklenebilir.
• Geriye dönük window: Başlangıç zamanı geçmişte olan window açabilirsiniz, ama geçmiş event'lere etki etmez. Sadece şu andan itibaren alert atlanır.
• Zaman dilimi karmaşası: ShamashAi backend UTC ile çalışır. Frontend Türkiye saati gösterir ama API'ye gönderirken UTC'ye çevirmelisiniz, yoksa 3 saat fark olur.

Sonuç

ShamashAi'nin Maintenance Windows özelliği, planlı bakım senaryolarında hem yanlış alarm yükünü hem de log kaybı riskini ortadan kaldırır. Scope granularity (project / site / device) sayesinde esnek planlama yaparsınız. Alert değerlendirmesi atlanır, ama event ingest devam eder, audit kaydı korunur.

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