Bölüm 25: Audit Logs ve SIEM Entegrasyonu

Audit Logs Sayfasına Genel Bakış

Audit Logs (panelde Denetim Kayıtları) sayfası, Arceris'in tüm güvenlik ve yönetim olaylarını merkezi olarak görüntülediği ana denetim yüzeyidir. Üç sekmeden oluşur:

• İstek Olayları (Request Events): Engellenen, reddedilen, maskelenen ve izin verilen istekler — PII block, injection block, policy deny, rate limit, Model Erişimi reddi, MCP kararları ve maliyet limiti dahil.
• Yanıt Taraması (Response Scan): Yanıt tarafında taranan olaylar; eşleşme bulunanlar (Temiz / Engellendi / Maskelendi / Kaydedildi sonuçlarıyla).
• Denetim Kaydı (Audit Log): Yapısal denetim olayları (giriş/çıkış, yönetim işlemleri, yapılandırma değişiklikleri, erişim kararları).

Sayfanın tek bir Yenile denetimi vardır ve filtre çubuğunda yer alır: açık satırı açık tutarak her seferinde listeyi, Yanıt Taraması bulgularını ve eşleşen deny olaylarını yeniden okur.

İstek Olayları Sekmesi

Bu sekme her istek için bir satır gösterir. Sütunlar:

• Kullanıcı: İsteği yapan kullanıcı (adı yoksa kullanıcı ID'si).
• Sağlayıcı: Kullanılan AI sağlayıcısı / modeli.
• Araç: İsteği yapan istemci aracı. Kimliği çözülemeyen satırlarda uyarı renkli ANON etiketi, kayıtlı cihazdan gelen satırlarda DEV etiketi görünür.
• Politika: Kararı veren kontrol (PII Kuralları, Prompt Guard, Model Erişimi, Path Filtreleri, MIME Filtreleri, OCR Filtreleri, Kurumsal Veri Denetçisi, Maliyet / Kullanım Limiti, MCP politikaları vb.).
• Kural: İsteği engelleyen kural ve kısaca kullanıcıya ulaştığı yol (ayrıntı aşağıda, "Engelleyen Kural ve Atama Zinciri").
• Kaynak: Trafiğin geldiği yüzey (API, Ağ Geçidi, Tarayıcı Proxy, CLI / Araç, MCP Hook).
• Sonuç: Engellendi, Reddedildi, Maskelendi, Tespit Edildi, Karantinada, İzin Verildi gibi sonuç etiketi.
• Zaman ve Referans: Olay zamanı ve kopyalanabilir engelleme referansı (req-…). Arama kutusuna bu referansı yapıştırmak ilgili olayı bulur.

Satır genişletildiğinde şu detaylar gösterilir:

• Neden / Engelleme Nedeni: Engellemenin açıklaması.
• İstek Kimliği, Sağlayıcı, Araç, Cihaz: Olayın teknik bağlamı.
• Payload: İsteğin tam içeriği ("Audit Full Payload" açık ise). "Tüm Yükü Görüntüle" butonu ile tam içerik ayrı bir modal'da görüntülenebilir.
• Engelleyen kural ve atama zinciri: Hangi kuralın, hangi yollarla kullanıcıya ulaştığı (aşağıda).
• Karar: Karar süresi, aşaması ve kontrol başına süreler (aşağıda).
• Kimlik: İsteğin kimlikle ilişkilendirilme provenansı (aşağıda).
• İlgili denetim kayıtları: Aynı isteğin Denetim Kaydı'ndaki satırları.

Filtreler:

• Arama: Metin araması (neden, kullanıcı, politika ID'si, kural adı, grup adı) veya bir engelleme referansı yapıştırma.
• Tüm Kaynaklar: Kaynak türüne göre filtreleme (API, Ağ Geçidi, Tarayıcı Proxy, CLI / Araç, MCP Hook).
• Olay türü: PII Kuralları, Prompt Guard, MIME Filtresi, OCR Filtresi, Dosya Üst Verisi, Path Filtresi, Model Erişimi, Maliyet Limiti.
• Sonuç: Engellendi, İzin Verildi, Maskelendi, Tespit Edildi, Karantinada.
• Tarih Aralığı: Son 6 saat / 24 saat / 7 gün / 30 gün veya özel aralık.

Notlar:

• Explicit proxy'de bir engelleme artık tek bir iz bırakır: host+path ve özgün payload'ı taşıyan tek bir kayıt yazılır; istemcinin aynı isteği tekrar tekrar göndermesi (Codex ve benzeri istemcilerin engellenen istekleri ısrarla yeniden denemesi) tek satırda birleştirilir.
• Yerel LLM proxy'si (/local/) satırları artık diğer kanallar gibi kullanıcı adı taşır; kullanıcı adı olmadan yazılmış eski satırlar da aynı şekilde gösterilir, aranır ve sayılır.
• Yanıt taraması tarafından reddedilen bir model cevabı, coding-agent (explicit proxy) ve /local/ yollarında da İstek Olayları'na düşer (daha önce yalnızca Denetim Kaydı'na satır yazılıyordu ve raporların "Engellendi" sayısı bu retleri göremiyordu — bkz. Bölüm 27). Coding-agent yolunda istemci aynı reddedilen cevabı yeniden denedikçe kayıt iki dakikada bir yazılır.

Kimlik Provenansı

Bir Model Erişimi reddi görüldüğünde ilk soru genellikle "bu istek neden bu kullanıcıya bağlandı?" olur. Her Model ACL reddi satırı ve eşleşen İstek Olayları satırı, isteğin kimlik provenansını taşır:

identity_source	Panel etiketi	Anlamı
session	Oturum	Tanınmış bir oturumdan tanımlandı
ip_session	IP oturumu	IP tabanlı oturumla ilişkilendirildi
device_relay	Kayıtlı cihaz (relay)	Kayıtlı cihazın relay bağlantısı üzerinden tanımlandı
credential	İstekle gelen kimlik bilgisi (belirteç/anahtar)	İstekle sunulan belirteç/anahtar çözümlendi
credential_rejected	Kimlik bilgisi reddedildi	Sunulan kimlik bilgisi geçersiz bulundu
anonymous	Kimliği belirlenemedi	İstek hiçbir kullanıcıya bağlanamadı

Yanına ikincil bilgiler eklenir:

• Kimlik doğrulama yöntemi: parola, SSO, OIDC, Kerberos, LDAP, API anahtarı, bearer belirteci, proxy belirteci, cihaz belirteci, gateway anahtarı, ajan belirteci, captive IP oturumu vb.
• Oturum çerezi durumu (şeffaf proxy): oturum çerezi yok / var / süresi dolmuş-tanınmayan.
• Cihaz relay durumu: kullanıldı; var ama "Kayıtlı Cihazla Otomatik Giriş" kapalı; ya da reddedildi (giriş kapısı kapalı, kullanıcı askıda, cihaz iptal edilmiş, cihaz başka kullanıcıya ait, belirteçte cihaz yok, cihaz kaydı doğrulanamadı gibi reddin nedeniyle).

Listede kimliği çözülemeyen satırlar ANON etiketiyle işaretlenir; satırın üzerindeki ipucu, buradaki bir Model ACL reddinin bir kural sorunu değil kimlik sorunu olabileceğini hatırlatır. Detayda Kimlik bloğu bu provenansı tümüyle listeler.

Cihaz sahibi ipucu: Kimliği belirlenemeyen ama bir cihaz ID'si taşıyan satırlarda "Cihaz sahibi: \<kullanıcı> (ipucu — bu isteğin kimliği değildir)" satırı gösterilir. Bu bir ipucudur, kayıt sırasında saklanmaz ve aranamaz.

Reddedilen kimlik bilgileri de denetlenir: Cihaz relay bağlantısı 407 ile reddedildiğinde ve explicit proxy'de sunulan bir belirteç reddedildiğinde bir auth_login_fail satırı yazılır (neden: süresi dolmuş / iptal edilmiş / askıda / belirteçte cihaz yok). Aynı (neden, kullanıcı, IP) üçlüsü 10 dakikada bir kez kaydedilir; belirtecin kendisi asla loglanmaz. Yerel LLM proxy'sindeki bir Model ACL reddi artık ayrıca Denetim Kaydı'na da access_denied satırı olarak düşer. Explicit proxy'deki MCP reddi satırları (sunucu reddi, karantina, yüksek riskli araç, rug-pull) da isteğin kendi referansını taşır; bu sayede ilgili denetim kayıtları doğru istekle eşleşir.

Dille ilgili kural: Kimlik etiketleri dahil tüm panel cümleleri panel dilini (Türkçe) izler; saklanan satırlar ve SIEM çıktısı İngilizce kalır. Bir kullanıcı kimliğini kaybettiğinde (cihaz oturumu bozulduğunda) yazılan machine_user_credential satırları ve Makineler sayfasındaki rozetler Bölüm 13'te anlatılır; "kullanıcısı kimliğini kaybeden makineler" uyarı eşiği Bölüm 6'daki uyarı ayarlarından yapılandırılır.

Engelleyen Kural ve Atama Zinciri

"Bu isteği hangi kural engelledi ve bu kural bu kullanıcıya nasıl ulaştı?" sorusunun cevabı artık satırın kendisinde taşınır:

• İstek Olayları listesinde Kural sütunu, engelleyen kuralın adını ve kısaca kullanıcıya ulaştığı yolu gösterir.
• Satır detayında tam zincir listelenir: kural türü, kural ID'si ve adı (bir atama kopyasıysa kaynak kurala çözümlenir), eşleşen atama ve kuralın kullanıcıya ulaştığı tüm yollar:
• doğrudan atama,
• rol üzerinden,
• LDAP grubu üzerinden,
• yerel grup üzerinden (iç içe zinciriyle),
• IP üzerinden,
• ve kuralın üretildiği Kural Seti.
• Bağlama (binding) üç şekilde belirtilir: atanmış (Access Management'tan bir atamayla), genel ayar (kurulum geneli bir kontrol — atama yok, gösterilecek grup da yok) ve eşleşen kural yok (kullanıcıya bu modeli izin veren bir kural bulunamadı; Model Erişimi varsayılan olarak reddetti).
• Zincir blok anındaki durumun anlık görüntüsüdür: sonradan yapılan grup veya atama değişiklikleri bu satırı değiştirmez. Kaynak çözümlenemediyse nedeni belirtilir (kimlik yok — kaynak çözülemedi / güncel bir atama bulunamadı). Kimliği belirlenememiş bir istek asla bir gruba atfedilmez.
• Birleşik ağ geçidinde hiçbir kuralla eşleşmeyen Model ACL reddi, politika ID'si olarak artık boş yerine gateway-acl taşır.

Kuralın kullanıcıya hangi yerel gruplar üzerinden ulaştığı ayrıca Model Erişimi reddleri, sistem promptu enjeksiyonu, DLP ve içerik denetimi satırlarında ve OCR / dosya üst verisi satırlarında via_local_groups alanıyla kaydedilir. MIME filtresi, prompt guard ve path filtresi satırları bu alanı henüz taşımaz.

Atama zincirinin kaynağı olarak Effective Policy görünümünün kendisi Bölüm 11'de anlatılır; kural türlerinin tanımı için de aynı bölüme bakınız.

Karar İzi

Engellenen ve reddedilen satırlar, kararın nasıl verildiğini de taşır:

• Karar süresi: İsteğin gelişinden karara kadar gateway tarafındaki bekleme (yanıt tarafı kararda modelin tüm turu dahildir).
• Karar aşaması: İstek üzerinde karar verildi (hiçbir şey iletilmeden önce) veya sağlayıcının cevabı üzerinde karar verildi (prompt iletilmişti).
• Sağlayıcıya giden: Hiçbir şey gitmedi / yalnızca içeriksiz bir politika bildirimi gitti / prompt sağlayıcıya gitti.
• Kontrol başına süre: Prompt Guard, PII, konu sınıflandırıcı, Kurumsal Veri Denetçisi, ICAP DLP, içerik moderasyonu, OCR ve sağlayıcı gibi her kontrolün harcadığı süre.

Aynı bilgiler CSV dışa aktarımında da yer alır. Kontrollerin hangi sırayla çalıştığı ve erken durdurma (ilk bloklayan katmanın adının geçmesi) Bölüm 20'de anlatılır.

Yanıt Taraması Sekmesi

Bu sekme, yanıt tarafında tarama yapılan olayları listeler. İstek Olayları ile aynı yapıya sahiptir. Tarama, Settings → Response Scanning bölümünde "Scan for PII" veya "Scan for Injection" açık olduğunda oluşur ve şeffaf proxy'nin yanı sıra birleşik ağ geçidi (/gateway/v1) ve yerel LLM proxy'si (/local/) yanıtlarını da kapsar; sıkıştırılmış bir cevap çözülüp taranır, okunamayan bir cevap Maskelle/Engelle modunda asla "temiz" diye geçirilmez.

Sonuç etiketleri: Temiz (eşleşme yok), Engellendi (eşleşen cevap istemciye verilmedi), Maskelendi (hassas değerler maskelenerek iletildi), Kaydedildi (yalnızca kaydedildi, cevap değiştirilmeden iletildi).

Detayda Tespit Edilen paneli eşleşen değerleri listeler; maskelenmiş cevaplarda hem Orijinal yanıt (maskeleme öncesi) hem de İletilen yanıt (maskeleme sonrası) gösterilir — böylece maskenin gerçekten uygulandığı doğrulanabilir.

Sağlayıcı Geri Çekmesi Olayları

Gemini web'de sağlayıcının akıttığı cevabı kendi sunucu filtresiyle değiştirmesi ("cevap yazmaya başlıyor, sonra siliniyor, yerine 'Ben yalnızca bir dil modeliyim…' geliyor") artık Audit Log'ta görünebilir. Bu bir Arceris engeli değildir; tespit cevabın tek byte'ına dokunmaz. Turun İstek Olayları satırı açıldığında "ilgili denetim kayıtları" arasında Sağlayıcı cevabı geri çekti (provider_retraction) satırı belirir — hangi politika altında ve sohbetin kaçıncı enjeksiyonunda tetiklendiğiyle birlikte. Kayıt yalnızca biçim ölçüleriyle yazılır (metin, parça veya hash içermez); biçim tanınmadıysa, akış tamamlanmadıysa veya cevabı Arceris'in kendisi blokladıysa yazılmaz. ChatGPT ve claude.ai'de bu tespit henüz yapılmamaktadır.

Denetim Kaydı Sekmesi

Bu sekme, Arceris'in yapısal denetim olaylarını listeler. Sütunlar: Kullanıcı, İşlem, Önem, Zaman Damgası, Referans. Her olay genişletildiğinde "Ne oldu" özet cümlesi ve olay kimliği, türü, önemi, rolü, IP adresi, kaynak, işlem ve ayrıntılar (JSON) gösterilir.

Filtreler: Önem (Denetim / Bilgi / Uyarı / Hata / Kritik), Olay Türü, Sonuç (İzin Verildi, Maskelendi, Kaydedildi, Tespit Edildi, Reddedildi, Engellendi, Başarılı, Başarısız), Kaynak, serbest metin araması ve tarih aralığı.

Panel dili: Audit Log'un türettiği her cümle ve etiket (yönetici işlem cümleleri, olay başlıkları, detay anahtarları, sonuç açıklamaları, kimlik provenansı, makine bildirimleri) panel dilini izler. Karşılığı olmayan bir kod varsa ham kod gösterilir; saklanan satırlar ve SIEM çıktısı İngilizce kalır.

Denetim İzi Bütünlüğü: Sekmenin altındaki panel, kaydedilen her olayın bir öncekine SHA-256 özeti ile bağlandığı hash zincirini Zinciri Doğrula butonuyla baştan sona doğrular; değiştirilen, silinen veya araya sıkıştırılan kayıtlar tam kırıldığı noktada raporlanır. Doğrulamanın kendisi de denetim kaydına yazılır.

Severity (Önem Seviyeleri)

Her olay bir önem seviyesiyle etiketlenir:

• Denetim (Audit): Denetim amaçlı kaydedilen yönetim işlemleri (yapılandırma değişikliği, kural güncelleme, kullanıcı oluşturma vb.). Kurumsal uyumluluk için önemlidir.
• Bilgi (Info): Bilgi düzeyinde olaylar (başarılı giriş, başarılı istek, istemcinin iptal ettiği akış vb.). Operasyonel görünürlük sağlar.
• Uyarı (Warning): Dikkat gerektiren durumlar (PII tespiti, injection engeli, erişim reddi, hız sınırı). Güvenlik ekibinin incelemesi gerekebilir.
• Hata (Error): Sistem hataları (kimlik doğrulama hatası, upstream bağlantı hatası vb.). Operasyon ekibinin müdahalesi gerekebilir.
• Kritik (Critical): Kritik güvenlik olayları. Acil müdahale gerektirir.
• Hata Ayıklama (Debug): Geliştirme ve sorun giderme amaçlı ayrıntılı olaylar. Üretimde genellikle kapalıdır.

Event Types (Olay Türleri)

Event Type	Panel etiketi	Açıklama
auth_login	Giriş	Başarılı kullanıcı girişi
auth_login_fail	Giriş Başarısız	Başarısız giriş denemesi; reddedilen cihaz relay / proxy belirteci satırları da buraya düşer
auth_logout	Çıkış	Kullanıcı çıkışı
admin_action	Yönetici İşlemi	Yönetici işlemi (kural silme, kullanıcı güncelleme vb.)
config_change	Yapılandırma Değişikliği	Sistem yapılandırma değişikliği
user_request	Kullanıcı İsteği	Kullanıcı API isteği
access_denied	Erişim Reddedildi	Erişim reddedildi (Model ACL, scope uyuşmazlığı; /local/ reddleri dahil)
pii_detected	PII Tespit Edildi	PII eşleşmesi tespit edildi
injection_block	Enjeksiyon Engellendi	Prompt injection engellendi
rate_limited	Hız Sınırlandı	Rate limit aşıldı
policy_denied	Politika Reddetti	Politika kuralı tarafından reddedildi
exfiltration_detected	Sızdırma Tespit Edildi	Yanıtta veri sızdırma tespit edildi
session_threat	Oturum Tehdidi	Çok turlu oturum tehdidi ilişkilendirildi
enforcement_gap	—	Ağ düzeyi uygulama kararı değişti
os_user_mismatch	OS Kullanıcı Uyuşmazlığı	Ajan check-in'inde OS kullanıcısı uyuşmazlığı
browser_direct	Tarayıcı Doğrudan Bağlantısı	Tarayıcının AI sitesine doğrudan bağlantısı
upstream_unreachable	Yapay zekâ host'una ulaşılamadı	DNS / bağlantı / TLS hatası
system_prompt_injection	Politika Sistem İstemi	Politika sistem komutu enjekte edildi
provider_retraction	Sağlayıcı cevabı geri çekti	Sağlayıcı (Gemini) cevabı kendi filtresiyle değiştirdi
system_error	Sistem Hatası	Sistem hatası
auth_error	Kimlik Doğrulama Hatası	Kimlik doğrulama hatası

SIEM kuralı uyaranı: Gateway injection engelleri artık injection_block olarak kaydedilir (eskiden injection_blocked idi ve hiçbir SIEM eşlemesi bu dizgiyi tanımıyordu). Eski dizgiye kilitli bir SIEM kuralı güncellenmelidir.

Export (Dışa Aktarma)

Filtre çubuğundaki Dışa Aktar menüsü üç seçenek sunar:

• Filtreye uyan tüm olaylar — CSV: Sunucu tarafında, o anki filtrelerle eşleşen tüm olaylar.
• Filtreye uyan tüm olaylar — JSON: Aynı kapsamın JSON biçimi.
• Yalnızca bu sayfa — JSON: Görünen sayfa (audit-logs-<sekme>-<tarih>.json).

Dışa aktarımdan önce eşleşen olay sayısı gösterilir; sayı üst sınırı aşarsa yalnızca ilk bölüm aktarılır ve dosyanın son satırı eksikliği belirtir — eksiksiz bir dosya için filtreler veya zaman aralığı daraltılmalıdır. "İstem/yanıt içeriklerini dahil et" seçeneği yalnızca Audit Full Payload açıkken içeriği dışa aktarır.

İstek Olayları dışa aktarımları, mevcut sütunların sonuna şunları ekler: kural zinciri sütunları (rule_type, rule_id, rule_name, rule_binding, rule_source_status, rule_via), kimlik sütunları (identity_source, identity_auth_method, identity_session, identity_device_relay) ve engellenen satırlarda karar alanları.

Source (Kaynak Türleri)

Deny ve response scan olayları, trafiğin nereden geldiğini belirten bir kaynak etiketi taşır:

• API: Doğrudan API çağrısı (explicit proxy dahil).
• Ağ Geçidi: Birleşik ağ geçidi (/gateway/v1) üzerinden gelen istekler.
• Tarayıcı: Transparent proxy üzerinden gelen tarayıcı trafiği.
• CLI / Araç: Transparent/explicit proxy üzerinden gelen geliştirici aracı (coding agent) trafiği.
• MCP Hook: PreToolUse hook'undan gelen araç çağrısı kararları.
• Yönetici / arceris-dev CLI / Bağlantı Portalı: Yönetim düzlemi ve cihaz kaynaklı olaylar.

Bu bilgi, olayın hangi yüzeyden geldiğini hızlıca anlamayı sağlar.

Audit Full Payload

Varsayılan olarak audit olaylarında ve deny olaylarında payload (istek/yanıt içeriği) kaydedilmez. Settings → Audit Full Payload toggle'ı etkinleştirildiğinde, tüm istek ve yanıtların tam metni audit kayıtlarına eklenir.

Dikkat: Bu özellik açıkken, prompt ve yanıtlardaki hassas veri (PII) loglarda görünebilir. Gerekmedikçe açık bırakılmamalıdır. Yalnızca sorun giderme ve derinlemesine analiz gerektiğinde geçici olarak açılmalıdır.

Akış Kesintileri ve İptaller

Birleşik ağ geçidinde stream edilen bir cevap koptuğunda veya istemci akışı yarıda bıraktığında, audit satırı stream_outcome ile ne olduğunu söyler:

• upstream_cut: Sağlayıcı akışı kesti. Gateway cevabı normal bitirmiş gibi kapatmaz; bitiş işareti olmadan bağlantıyı kapatır (istemci beklenmedik EOF görür), böylece yarım cevap tamamlanmış sayılmaz. Maliyet ve audit satırı kaydedildikten sonra kapatma yapılır.
• client_cancelled: İstemci akışı yarıda bıraktı. Eskiden her terk edilmiş akış bir hata satırı yazıyordu; artık tek bir bilgi (Info) satırıdır. Gerçek bir sağlayıcı veya çeviri hatası hâlâ hata olarak kaydedilir.

Kiracı Kapsamlı Roller

TenantAdmin ve SecurityAuditor gibi kiracı kapsamlı roller, kiracı damgalı veri tutan veya kiracı filtresi alan sayfalarda yalnızca kendi kiracılarının satırlarını görür: Denetim Kaydı, İstek Olayları (liste ve dışa aktarım), panelin son engellemeleri, oturum tehditleri ve kural sayfaları. Bu roller kendi kiracının satırlarına ek olarak kiracı taşımayan satırları da görür (sistem ve yönetici olayları, tek kiracılı trafik). Başka bir kiracı adlandırılırsa istek 403 ile reddedilir ve bu reddin kendisi tenant_scope_denied olarak denetim kaydına yazılır.

SIEM Entegrasyonu

Arceris, audit olaylarını kurumun merkezi güvenlik izleme sistemine (SIEM) gönderebilir. Bu entegrasyon, Settings → Syslog Integration bölümünden yapılandırılır.

Taşıma (Transport): Olayların gönderileceği iletişim protokolü:

• HTTP Webhook: Olayları JSON payload olarak HTTP POST isteğiyle gönderir. Modern SIEM araçları (Splunk HEC, Elastic, Datadog) için uygundur.
• UDP Syslog/CEF: Olayları UDP üzerinden iletir. Hızlı ama teslim garantisi yoktur. Düşük hacimli ortamlar için uygundur.
• TCP Syslog/CEF: Olayları TCP üzerinden iletir. Teslim garantisi vardır. Üretim ortamları için önerilir.

Uç Nokta (Endpoint): Olayların gönderileceği hedef adres. HTTP için tam URL, syslog için host:port biçimi. Uç nokta boş bırakıldığında SIEM iletimi devre dışı kalır.

Biçim (Format): Gönderilecek olayların çıktı biçimi:

• JSON: Yapılandırılmış JSON formatı. En ayrıntılı ve makine-okunabilir formattır.
• Syslog (RFC 5424): Standart syslog mesaj formatı. Mevcut SIEM altyapısına kolay entegrasyon sağlar.
• CEF (Common Event Format): ArcSight ve benzeri SIEM araçları için optimize edilmiş format. Önceden tanımlı alan adlarıyla yapılandırılmış olay gönderir.

Minimum Önem (Min Severity): İletim için minimum önem seviyesi. Yalnızca bu seviye ve üzeri olaylar gönderilir. Örneğin "WARNING" seçildiğinde yalnızca Warning, Error, Critical ve Audit seviyesindeki olaylar iletilir; Info ve Debug filtrelenir.

Token: HTTP webhook için opsiyonel bearer token. Authorization: Bearer <token> header'ı ile gönderilir. UDP/TCP syslog'da kullanılmaz.

SIEM'e giden ek alanlar: Engellenen ve reddedilen olaylar, SIEM'de de korelasyonu besleyen ek alanlar taşır:

• Kimlik provenansı: identity_source, identity_auth_method, identity_session, identity_device_relay.
• Engelleyen kural: block_rule_type, block_rule_id, block_rule_name, block_rule_binding, block_rule_via.
• Karar ölçüleri: decision_latency_ms, decision_stage, decision_timings.

CEF biçiminde identity_source kendi etiketli yuvasına (flexString1) ve block_rule_name flexString2'ye yazılır; kalan kimlik ve kural alanları msg içine gider — mevcut CEF eşlemelerinin hiçbir yuvası kaymaz.

Dayanıklı Teslimat (Spool & Yeniden Deneme): "Teslim edilemeyen olayları diske yaz" ayarı açıken (önerilir ve varsayılanıdır) teslim edilemeyen olaylar yerel diske yazılır, gruplanır ve artan bekleme süreleriyle SIEM onaylayana kadar yeniden denenir; tek bir başarısız istek veya bir SIEM kesintisi olay kaybettirmez. Grup boyutu 1'in üzerine çıkarılırsa gerçek bir çoklu olay grubu JSON dizisi olarak gönderilir (tek olay her zaman tek JSON nesnesi olarak kalır). Spool dolduğunda önce en eski olaylar atılır. Ayarlar sayfasındaki Teslimat durumu kartı bekleyen/teslim edilen/yeniden denenen/düşen sayıları ve son hatayı gösterir; "diskte bekleyen" sayısının 0'da kalması gerekir.

SIEM ayarları veritabanında saklanır ve kaydedildiğinde anında uygulanır (yeniden başlatma gerektirmez).

SIEM Yapılandırma Örnekleri

Splunk HTTP Event Collector (HEC):

• Transport: HTTP Webhook
• Endpoint: https://splunk.corp.com:8088/services/collector/event
• Format: JSON
• Token: Splunk HEC token

Elastic Filebeat / Logstash:

• Transport: TCP Syslog
• Endpoint: logstash.corp.com:514
• Format: JSON veya Syslog (RFC 5424)

ArcSight / Micro Focus:

• Transport: TCP Syslog
• Endpoint: arcsight.corp.com:514
• Format: CEF

İnceleme ve Denetim Senaryoları

Audit görünürlüğü yalnızca olay toplamak için değil; olayları anlamlandırmak için kullanılır. Yaygın senaryolar:

• Erişim engeli sorunu: Bir kullanıcının "Erişim Reddedildi" aldığını görmek için İstek Olayları filtrelenir. Kural sütunu ve detaydaki atama zinciri hangi kuralın engellediğini ve kuralın kullanıcıya hangi yolla ulaştığını gösterir; payload inceleyerek eşleşen içerik bulunur.
• "Bu istek neden anonim?": ANON etiketli bir Model ACL reddinde detaydaki Kimlik bloğu, isteğin neden kullanıcıya bağlanamadığını söyler (oturum çerezi yok, reddedilen belirteç, kapalı cihaz relay'i…); varsa cihaz sahibi ipucu soruşturmaya başlangıç verir.
• PII sızıntı kontrolü: "PII Tespit Edildi" olay türü filtrelenerek hangi kullanıcıların PII gönderdiği ve hangi veri sınıflarının tetiklediği incelenir; Yanıt Taraması sekmesi cevap tarafındaki sızıntıları gösterir.
• Prompt injection analizi: "Enjeksiyon Engellendi" olayları zaman çizelgesinde incelenerek saldırı örüntüleri tespit edilir.
• Yapılandırma değişikliği denetimi: "Yapılandırma Değişikliği" ve "Yönetici İşlemi" olayları filtrelenerek kimin ne zaman hangi değişikliği yaptığı izlenir.
• Başarısız giriş izleme: "Giriş Başarısız" olayları izlenerek brute-force denemeleri ve reddedilen cihaz/proxy belirteçleri tespit edilir.

Zaman içindeki eğilimler ve kural bazlı sayımlar için Bölüm 26'daki Analytics sayfalarına, düzenli raporlar için Bölüm 27'ye bakınız; uyarı eşikleri ve uyarı bildirimleri Bölüm 6'daki ayarlardan yapılandırılır.