ShamashAi Sites: HQ, Şube, DR ve Colo'yu Tek Konsoldan Yönetme

Pazartesi 08:45: HQ'dan İzmir şubesi için alert geldi, ama hangi sistemden?

Holding IT yöneticisi Murat'ın ekranında yeni bir BRUTE_FORCE_DETECTED event'i yanıyor. Event detayında device_name: izmir-branch-fw01 yazıyor ama hangi şube, hangi bölge, hangi network segmentinde olduğu net değil. Birkaç ay önce yeni açılan İzmir ofisi mi, yoksa İzmir colo tesisindeki DR sunucuları mı? Murat Slack'ten İzmir IT sorumlusuna soruyor, o da "Bizde böyle bir cihaz yok, belki DR ekibi bilir" diyor. 20 dakika telefon trafiğinden sonra anlaşılıyor: cihaz DR lokasyonunda, ama SIEM'de site bilgisi olmadığı için kimse sahiplenemiyor.

Bu senaryo, çok lokasyonlu firmaların %70'inde yaşanıyor. Merkez ofis (HQ), 5-10 şube, bir DR tesisi, belki bir colocation ortamı var. Geleneksel SIEM'lerde ya her lokasyon için ayrı instance kurulur (lisans ve bakım maliyeti kat kat artar), ya da hepsi tek bir "flat" yapıda toplanır ama hangi cihazın hangi site'a ait olduğu manuel tag'lerle yönetilmeye çalışılır. ShamashAi Sites modülü bu sorunu mimari seviyede çözer: her lokasyon dbo.sites tablosunda bir kayıt, parent-child hiyerarşi ile organize, device/event/rapor her şey site bazında filtrelenebilir.

ShamashAi Sites tablosu: 6 lokasyon tipi

ShamashAi'da bir "site", fiziksel veya mantıksal bir lokasyonu temsil eder. dbo.sites tablosunda her site için şu sütunlar tutulur:

sql CREATE TABLE dbo.sites ( id INT PRIMARY KEY IDENTITY, name NVARCHAR(100) NOT NULL, type NVARCHAR(50) NOT NULL, -- on_prem_hq, branch, dr, colo, cloud_region, home_office parent_id INT NULL FOREIGN KEY REFERENCES dbo.sites(id), location NVARCHAR(200), -- "İstanbul Maslak" veya "AWS eu-central-1" created_at DATETIME2 DEFAULT GETDATE() );

Type alanı 6 değer alır:

• on_prem_hq: Merkez ofis, tipik olarak diğer tüm site'ların parent'ı.
• branch: Şube ofisleri. HQ'ya veya bölgesel bir hub'a bağlanır.
• dr: Disaster Recovery tesisi. Genelde HQ'nun çocuğu.
• colo: Colocation tesisi (örneğin Türk Telekom, Interworks vb.).
• cloud_region: AWS eu-central-1, Azure West Europe gibi cloud region'lar.
• home_office: Uzaktan çalışan kullanıcıların bağlandığı mantıksal site. VPN endpoint'leri burada gruplandırılabilir.

parent_id sütunu hiyerarşi kurmayı sağlar. Örneğin:

[1] HQ (İstanbul Maslak) — parent_id: NULL ├─ [2] DR (Ankara) — parent_id: 1 ├─ [3] Branch (İzmir Bornova) — parent_id: 1 └─ [4] Colo (Türk Telekom Gayrettepe) — parent_id: 1

Bu hiyerarşi sayesinde "HQ'yu seçince DR + tüm branch'ler de dahil" gibi cascade görünüm mümkün olur.

Header SiteSelector: URL ile site değiştirme

Next.js web arayüzünde header'da bir SiteSelector dropdown'ı var. Kullanıcı buradan site seçtiğinde, tarayıcı URL'sine ?site_id=3 parametresi eklenir. Bu parametre session'da kalır ve tüm sayfa geçişlerinde korunur.

Örneğin:

https://shamashai.example.com/events?site_id=3 https://shamashai.example.com/topology?site_id=3 https://shamashai.example.com/reports/compliance?site_id=3

Bu URL parametresi şu modülleri filtreler:

• Topology (Topoloji): Sadece o site'a ait device node'ları gösterilir.
• Events (Olaylar): dbo.events tablosundan device_id IN (SELECT id FROM dbo.devices WHERE site_id = @SiteId) şartıyla filtreleme.
• Devices (Cihazlar): Doğrudan dbo.devices.site_id sütunuyla eşleşir.
• Raporlar: Compliance report, SOC raporu, evidence pack — hepsi site_id filtreli SQL sorguları kullanır.

Bu sayede İzmir şubesi IT sorumlusu login olduğunda sadece kendi site'ını görür, HQ yöneticisi ise tüm site'ları veya birini seçerek detaya inebilir.

Site bazında envanter ve raporlama

dbo.devices tablosunda her cihaz bir site'ye bağlı:

sql ALTER TABLE dbo.devices ADD site_id INT NULL FOREIGN KEY REFERENCES dbo.sites(id);

Agent kurulumunda veya manuel device ekleme sırasında site seçilir. Örneğin İzmir şubesine yeni bir firewall eklerken:

http POST /devices Content-Type: application/json

{ "hostname": "izmir-branch-fw01", "ip": "10.20.30.1", "device_type": "firewall", "site_id": 3 }

Bu device artık dbo.events tablosunda oluşan her event'te de device_id üzerinden site ilişkisi taşır. Rapor çekerken:

sql SELECT e.event_type, COUNT(*) AS cnt FROM dbo.events e JOIN dbo.devices d ON e.device_id = d.id WHERE d.site_id = 3 AND e.created_at >= '2026-09-01' GROUP BY e.event_type;

Bu sorgu sadece İzmir şubesine ait event'leri sayar. Compliance raporu oluştururken de aynı filtre uygulanır:

http GET /compliance/evidence?site_id=3&start_date=2026-09-01&end_date=2026-09-28

Dönüş:

{ "site_name": "Branch (İzmir Bornova)", "period": "2026-09-01 / 2026-09-28", "event_count": 12450, "critical_incidents": 3, "auth_failures": 89, "backup_failed_count": 0, "cert_expiring_count": 1 }

Bu sayede her lokasyon için ayrı ayrı KVKK Madde 12 uyumluluk kanıtı (log denetim kayıtları, incident özeti) toplanabilir. ISO 27001:2022 Annex A.8.15 (kayıt tutma) ve A.12.4 (log yönetimi) gereksinimlerini site bazında karşılamış olursunuz.

Parent-child hiyerarşi ve cascade silme

Parent-child ilişkisi iki ana işlevi yerine getirir:

1. Aggregate görünüm: HQ seçildiğinde, API backend parent_id = 1 olan tüm site'ları da dahil edecek şekilde recursive sorgu çalıştırır. Böylece HQ yöneticisi "tüm şirket" görünümünü tek tıkla alır. 2. Cascade silme: Bir parent site silinirse, child site'lar da otomatik silinir (SQL ON DELETE CASCADE constraint ile). Bu durum nadirdir; tipik olarak site sadece pasife çekilir (gelecek sürümde is_active flag planlanıyor).

Örneğin DR tesisi kapatılıp yeni bir yere taşınırsa, eski DR site'ı silinir:

http DELETE /sites/2

Bu işlem dbo.audit_log tablosuna kaydedilir:

{ "action": "SITE_DELETED", "user_email": "murat@example.com", "site_id": 2, "site_name": "DR (Ankara)", "timestamp": "2026-09-28T09:15:19Z" }

Silme öncesi o site'a ait cihazların başka bir site'ye taşınması veya devre dışı bırakılması önerilir. ShamashAi dokümantasyonu bu konuda daha fazla bilgi vermiyor; pilot kapsamında detay paylaşılır.

Son site silindiğinde: instance reset

ShamashAi kurulumunda en az 1 site zorunludur. Eğer kullanıcı tüm site'ları siler (veya script hatasıyla siler), sistem otomatik olarak onboarding wizard'a döner. dbo.sites tablosu boşaldığında, Next.js middleware şu kontrolü yapar:

javascript // middleware.js (Next.js) export async function middleware(req) { const siteCount = await db.query('SELECT COUNT(*) AS cnt FROM dbo.sites'); if (siteCount.cnt === 0) { return NextResponse.redirect(new URL('/onboarding', req.url)); } }

Onboarding wizard kullanıcıdan ilk site'ı (tipik olarak HQ) oluşturmasını ister. Bu koruma, sistemin site'sız çalışarak event/device atamalarında hata vermesini engeller.

License kapasitesi: site sayısı advisory, device count enforced

ShamashAi lisansı device sayısı ile sınırlanır (örneğin 500 device). Site sayısı için hard limit yok, ama advisory bir üst sınır var. Pilot dokümantasyonunda "makul site sayısı: 20" notu düşülmüş. 20'den fazla site oluşturulursa web UI uyarı gösterir:

⚠️ Site sayısı advisory limiti (20) aştı. Performans sorunları yaşanabilir.

Ancak API, site oluşturmayı bloke etmez. Device count ise enforced:

http POST /devices

Dönüş (429 Too Many Requests):

{ "error": "DEVICE_LIMIT_EXCEEDED", "message": "Lisans kapasitesi 500 device. Şu an 500 aktif cihaz mevcut.", "current_count": 500, "license_limit": 500 }

Site sayısı çok olursa SQL sorgu planlarında JOIN maliyeti artabilir (özellikle recursive parent-child sorguları). 100+ site senaryosu için ShamashAi mühendisleri index optimizasyonu önerir.

Gerçek dünya senaryosu: holding IT ekibi kullanımı

Bir holding firması şu yapıyı kurdurdu:

[1] HQ (İstanbul Maslak) ├─ [2] DR (Ankara Teknokent) ├─ [3] Branch (İzmir Bornova) — 45 device ├─ [4] Branch (Antalya Lara) — 30 device ├─ [5] Colo (Interworks Maslak) — 12 device └─ [6] Cloud Region (Azure West Europe) — 8 VM

Her şube IT sorumlusu kendi site_id'si ile login oluyor (gelecekte RBAC ile bu zorunlu hale gelecek). İzmir sorumlusu sadece site_id=3 olan event'leri görüyor. HQ SOC analisti ise dropdown'dan "Tümü" seçerek aggregate view alıyor.

Bir gün İzmir'de BRUTE_FORCE_DETECTED event'i oluşuyor. SOC analisti event detayında site_name: "Branch (İzmir Bornova)" görüyor ve doğrudan İzmir IT'yi arıyor. 20 dakikalık "hangi sistem?" araştırması ortadan kalkıyor.

Ayın sonunda compliance raporu çekilirken:

http GET /reports/evidence-pack?site_id=3&month=2026-09

Rapor sadece İzmir şubesine ait:

• AUTH_FAIL_USER event'lerini (KVKK Madde 12 erişim denemeleri)
• BACKUP_FAILED event'lerini (ISO 27001 A.12.3 backup günlükleri)
• CERT_EXPIRING uyarılarını (ISO 27001 A.14.1 sertifika yönetimi)

içeriyor. Holding merkezi her şubenin raporunu ayrı ayrı alıp denetim dosyasında tutuyor.

Topology ve site filtreleme

Topoloji modülü (cytoscape.js tabanlı network haritası) site filtresini destekler. Kullanıcı header'da "Branch (İzmir Bornova)" seçtiğinde, harita sadece o site'a ait device node'larını gösterir:

javascript // Fastify backend app.get('/topology/nodes', async (req, reply) => { const { site_id } = req.query; const nodes = await db.query(` SELECT id, hostname, device_type, ip FROM dbo.devices WHERE site_id = @site_id `, { site_id }); return nodes.map(d => ({ data: { id: d.id, label: d.hostname, type: d.device_type } })); });

Bu sayede büyük bir network'te 500 cihaz arasında kaybolmak yerine, sadece ilgili şubenin 45 cihazını görürsünüz. Alert takibi ve incident response sırasında hangi cihazın hangi segment'te olduğu hemen anlaşılır.

SOAR action'lar ve site bağlamı

ShamashAi SOAR engine, bir event'e otomatik yanıt verirken device'ın hangi site'a ait olduğunu biliyor. Örneğin:

{ "event_type": "KNOWN_BAD_IP", "device_id": 87, "site_id": 3, "src_ip": "203.0.113.50" }

SOAR playbook:

IF event_type == KNOWN_BAD_IP AND site_id IN [3,4] -- sadece şubeler THEN POST /soar/block { "device_id": 87, "ip": "203.0.113.50" }

Bu kural sadece şube site'larında otomatik blok yapar, HQ'da ise alert oluşturur (false positive riski daha yüksek). dbo.soar_actions tablosunda action kaydı:

sql INSERT INTO dbo.soar_actions (event_id, action_type, target_device_id, site_id, executed_at) VALUES (12345, 'BLOCK_IP', 87, 3, GETDATE());

Raporda "İzmir şubesinde otomatik bloke edilen IP sayısı" gibi metrikler site bazında çıkar.

AI investigation ve site context

ShamashAi AI modülü (ChatGPT tabanlı incident investigation), bir event soruşturulurken site context'ini kullanır:

http POST /ai/investigate-event Content-Type: application/json

{ "event_id": 12345 }

Backend, event'in hangi site'a ait olduğunu öğrenir ve prompt'a ekler:

javascript const event = await db.queryOne('SELECT * FROM dbo.events WHERE id = @id', { id: 12345 }); const device = await db.queryOne('SELECT * FROM dbo.devices WHERE id = @device_id', { device_id: event.device_id }); const site = await db.queryOne('SELECT * FROM dbo.sites WHERE id = @site_id', { site_id: device.site_id });

const prompt = ` Event: ${event.event_type} Site: ${site.name} (${site.type}) Device: ${device.hostname} Aynı site'taki son 24 saatteki benzer event'ler var mı? `;

AI, "Bu event İzmir şubesinde ilk kez görülüyor, ancak geçen hafta Antalya şubesinde benzer pattern vardı" gibi site-aware analiz yapabilir.

Limitler ve dürüst notlar

• Site-based RBAC henüz yok: Şu an tüm kullanıcılar tüm site'ları görebilir. Header dropdown'dan manuel seçim yapıyorlar. Gelecek sürümde kullanıcı hesabına allowed_site_ids atanacak.
• Site sayısı 20+ olursa performans testi yapılmadı: Advisory limit var ama hard limit yok. 50 site açarsanız recursive parent-child sorguları yavaşlayabilir. Pilot kapsamında test edilebilir.
• Site silme işlemi geri alınamaz: ON DELETE CASCADE nedeniyle child site'lar ve device ilişkileri silinir. Backup alınması önerilir. Gelecekte "soft delete" (is_active flag) planlanıyor.
• Geo-location harita entegrasyonu yok: location alanı serbest metin. "İstanbul Maslak" yazarsınız ama haritada pin gösterilmez. Gelecekte koordinat desteği gelebilir.
• Multi-tenancy değil: Site'lar aynı SQL Server database içinde mantıksal olarak ayrılır. Farklı müşteriler için farklı instance gerekir (SaaS değil, on-prem lisans modelinde bu normaldir).

Sonuç

ShamashAi Sites modülü, çok lokasyonlu Türk firmalarının SIEM altyapısını merkezi yönetip lokasyon bazında detay görmesini sağlar. HQ, şube, DR, colo, cloud region, home office — 6 site tipi ve parent-child hiyerarşi ile her lokasyonun envanteri, event'leri, topolojisi, compliance raporu ayrı ayrı veya topluca izlenebilir. Header SiteSelector ile URL'e ?site_id= parametresi push edilerek tüm modüller (Topology, events, devices, raporlar) otomatik filtre uygulanır. dbo.sites tablosu ve SQL foreign key ilişkileri sayesinde her cihaz, her event, her SOAR action bir site'ye bağlı. License kapasitesi device sayısı ile sınırlı; site sayısı advisory. Son site silindiğinde sistem onboarding'e döner.

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