Güvenlik Mimarisi ve Entegrasyonlar

Kurulum modeli belirleyicidir

SQL Change Guard kurumun kendi ağında çalışır. Bulut hizmeti değildir. Yönetilen veritabanlarınıza bağlantıyı sizin ağınızdaki uygulama sunucusu kurar; betikleriniz ve sorgu sonuçlarınız üçüncü taraf bir servise gönderilmez. Ürünün kendi kayıtları da sizin veritabanı sunucunuzda durur. Ürün veriyi kendiliğinden dışarı göndermez; sorgu sonucu yalnız onaylı alıcıya, şifreli paketle gider ve alıcı adresinin onayı kurumun kararıdır.

Dışarıya giden bağlantılar. Ürünün kurulumla birlikte açık gelen tek dış çağrısı RFC 3161 zaman damgasıdır: ayar dosyası ücretsiz, herkese açık bir otoriteye işaret eder, böylece kurulum ilk gün uçtan uca çalışır. Bu çağrıda dışarıya giden tek şey bir SHA-256 özetidir; betik, sorgu sonucu ya da kayıt içeriği gönderilmez. Üretimde bu adres kurumun kendi otoritesiyle değiştirilmeli ya da özellik tek ayarla kapatılmalıdır. Diğer bağlantılar (e-posta sunucusu, bilet sistemi, kimlik sağlayıcı, dizin) varsayılan olarak kapalıdır ve adresini kurum verir; SIEM gönderimi ise uç adresi kurum tarafından tanımlanmadan başlamaz. Bunlardan biri bulut hizmetiyse (örneğin Jira Cloud ya da Entra ID) o hizmete giden bilgi, bağlantının işi kadardır: bilet numarası ve not metni ya da oturum açma akışı.

Kimlik Doğrulama ve Oturum

Kontrol	Bugünkü uygulama
Yerel hesap parolaları	BCrypt ile özetlenir. Parola hiçbir yerde geri çevrilebilir biçimde saklanmaz; veritabanına erişen bir kişi bile parolaları okuyamaz.
Dizin entegrasyonu	LDAP ile kurumsal dizine bağlanabilir (LDAPS ya da StartTLS). Parola doğrulaması dizinde yapılır ve üründe parola tutulmaz. Roller dizin gruplarından gelir. Dizinde kapatılan hesap, arka plandaki eşitleme ile ürüne de erişemez hale gelir.
Kurum hesabıyla giriş (SSO)	OpenID Connect (PKCE ile) ve SAML 2.0. Parola ürüne gelmez; kimlik sağlayıcının imzalı cevabı doğrulanır. Rol kimlik sağlayıcıdaki gruptan atanır; sistem yöneticisi rolü hiçbir eşlemeyle verilmez. SSO açıkken yerel parolayla girilirse bu ayrı bir olay olarak yazılır ve SOC'a alarm olarak gider. Ayrıntı.
Çok faktörlü doğrulama	Zaman tabanlı tek kullanımlık kod desteklenir ve kurum genelinde açılır. Kaydolmak ayrıca zorunlu tutulabilir: bu ayar açıkken kaydolmamış kullanıcı giriş yapar ancak oturumu yalnız kurulum adımına yarar, başka hiçbir işlem çalışmaz. Kural sunucu tarafında uygulanır. Kaç kullanıcının kaydolduğu tanılama ekranında oran olarak görünür.
Oturum jetonları	Kısa ömürlü erişim jetonu ve ayrı yenileme jetonu kullanılır. Yenileme jetonları iptal edilebilir; bir kullanıcının tüm oturumları anında sonlandırılabilir.
Deneme sınırlaması	Başarısız giriş denemeleri sayılır ve eşik aşıldığında hesap kilitlenir. Uygulama arayüzü ayrıca istek hızı sınırlaması uygular.
Parola değiştirme zorunluluğu	Yönetici tarafından oluşturulan hesaplar ilk girişte parola değiştirmeye zorlanır; değiştirmeden hiçbir işlem yapılamaz.

Yetki çekilmesi anında etkilidir

Bir kullanıcının yetkisi kaldırıldığında elindeki jeton geçerliliğini korusa bile işlem reddedilir. Yetki kontrolü yalnız jetonun içeriğine değil, isteğin geldiği anda veritabanındaki güncel duruma bakar. Bu ayrıntı önemlidir: birçok sistemde yetki değişikliği ancak kullanıcı yeniden giriş yaptığında etkili olur ve aradaki süre bir açıklıktır.

Yetkilendirme Modeli

Arayüzde bir düğmenin görünmemesi bir kontrol değildir. Her işlem, arayüzden bağımsız olarak sunucu tarafında yeniden yetkilendirilir.

İzin bazlı yetkilendirme

Yetkiler rolden değil izinden okunur. Roller izin demetleridir; bir kullanıcının ne yapabileceği, rol adına değil elindeki izinlere bakılarak belirlenir. Böylece kurum kendi rol yapısını kurabilir.

Görevler ayrılığı

Üç ayrı ayar vardır: talep sahibi kendi talebini onaylayabilir mi, onaylayan çalıştırabilir mi, çok adımlı onayda aynı kişi ikinci adımı kapatabilir mi. Üçü de kurum tercihine göre açılıp kapatılabilir; hiçbirini kapatılamaz diye tanıtmıyoruz. Kurulum varsayılanında üçü de gevşektir: talep sahibi kendi talebini onaylayıp çalıştırabilir ve onaylayan çalıştırabilir; Yönetişim Kurulum Kontrolü ekranı bunları ayrı satırlarda gösterir ve kurum sıkılaştırır.

Kontrol, ayarın kendisinde değil değiştirilme biçimindedir. Bu üç ayar "kontrol ayarı" olarak sınıflandırılmıştır: değişmeleri sıradan bir ayar güncellemesi değil, eski ve yeni değeriyle ayrı adlı bir kontrol değişikliği olayıdır ve ayar onayı (dört göz) açıksa ikinci bir yetkilinin onayına düşer; dört göz kurulum varsayılanında kapalıdır. Sınıflandırma listesi bilinçli olarak kodda durur, veritabanında değil; aksi halde biri önce kaydı listeden çıkarıp sonra korumayı onaysız kapatabilirdi.

Ayarın talep anındaki hali talebe dondurulur, bu yüzden sonradan yapılan bir gevşetme geçmiş kararları etkilemez. Engellenen onay girişimi de ayrıca kaydedilir: kontrolün gerçekten çalıştığının kanıtı, ürettiği red kayıtlarıdır.

Ayar değişikliğinde dört göz

Dört göz açıldığında kontrolü zayıflatabilecek ayarlar (ya da kurumun seçimine göre bütün ayarlar) tek kişiyle değiştirilemez. Değişiklik ayrı bir kayda alınır, canlı ayara dokunulmaz ve ancak ikinci bir yetkili onayladığında uygulanır.

Şifreleme ve Sır Yönetimi

Ne	Yöntem	Neden bu yöntem
Kullanıcı parolaları	BCrypt	Geri çevrilmesi gerekmeyen veri şifrelenmez, özetlenir. Kasıtlı olarak yavaş bir algoritmadır; deneme yanılma saldırısını pahalı kılar.
Sunucu bağlantı parolaları	AES-256-GCM	Bu parolaların kullanılabilmesi için geri çözülmesi gerekir, bu yüzden şifrelenir. GCM kipi hem gizliliği hem bütünlüğü sağlar: şifreli metin kurcalanırsa çözme başarısız olur.
Sorgu sonucu teslim paketi	AES-256 ZIP	Üretimden çıkan veri AES-256 ile şifreli ZIP paket olarak teslim edilir; paket parolası veritabanında AES-256-GCM ile şifreli saklanır. Paket parolası e-postayla gönderilmez; talep sahibi portalde gerekçesiyle görüntüler.
Denetim kayıtları	SQL Server ledger	Kayıtlar SQL Server 2022'nin append-only ledger tablosunda durur; veritabanı motoru değiştirmeyi ve silmeyi herkes için reddeder. Defter özeti varsayılan olarak saatte bir alınır; imza anahtarı ve dış depo klasörü tanımlı kurulumda imzalanıp kurumun değiştirilemez deposuna yazılır, böylece veritabanı yeniden kurulsa bile fark doğrulamada görünür. Bu iki ayar yapılmazsa dış dosya yazılmaz ve Yönetişim Kurulum Kontrolü ekranı bunu gösterir.
Denetim dosyası mührü	SHA-256	Dışa aktarılan kanıt paketindeki her dosyanın SHA-256 özeti künyeye yazılır. Özet, dosyanın değişip değişmediğini gösterir; kimden çıktığını ise aşağıdaki imza gösterir.
Kanıt paketi imzası	RSA, SHA-256	İmza anahtarı tanımlı kurulumda paketin künyesi ve defter özeti dosyaları asimetrik olarak imzalanır (3072 bit anahtar önerilir) ve doğrulama için gereken açık anahtar paketin içine konur; anahtarın doğru anahtar olduğu, kurumun ayrıca yayımladığı parmak iziyle kontrol edilir. Doğrulayan tarafın özel anahtara ihtiyacı yoktur; bu yüzden denetçi kurumdan hiçbir sır istemeden imzayı kendi makinesinde kontrol edebilir. Adımlar ve komutlar.

Şifreleme anahtarları uygulama yapılandırmasında tutulur ve kurumun kendi anahtar yönetimi disiplinine tabidir. Anahtar kurum tarafından belirlenir; üründe gömülü bir anahtar yoktur. Anahtarı değiştirmeden önce mevcut şifreli değerlerin yeniden şifrelenmesi gerekir; bu, kurulum dokümanında ayrıca anlatılır.

Üretim Verisinin Ele Alınışı

Değişiklik tarafında ürün veri okumaz. Veri yalnızca üretim sorgu talebi akışında görülür ve o akışın tamamı kontrol altındadır.

Hassas kolon tespiti

Kolon adı tek başına yeterli sayılmaz. İçerik de değerlendirilir ve kimlik numarası, kart numarası ve IBAN gibi alanlar biçim doğrulamasıyla teyit edilir. Böylece on bir haneli her sayı kimlik numarası sayılmaz; adı ipucu vermeyen bir kolon da, sonuçtan alınan örneklemde değerlerin belirli bir oranı bir kalıba uyuyorsa hassas sayılır. Ad ve adres gibi kalıbı olmayan alanlar kolon adı kataloğuna dayanır; tespit süresi dolarsa kalan kolonlar maskelenir.

Maskesiz erişim ayrı bir karardır

Varsayılan maskelidir. Maskesiz veri isteniyorsa gerekçe yazılır ve ek onay gerekir. Kurum, maskesiz kolon isteğini kurum genelinde tamamen kapatabilir; bu ayarda maskesiz istek açılmaz. Sunucu tanımında ise maskeleme rejimi seçilir: varsayılan sıkı rejim kolon adını ve veri desenini birlikte kullanır, gerekçeyle seçilen yalnız içerik rejimi kolon adına bakmaz.

İndirme gerekçesi kaydedilir

Sonucun indirilmesi ayrı bir olaydır ve gerekçesiyle birlikte kaydedilir. "Veriye kim, ne zaman, neden ulaştı" sorusunun cevabı talebin kendisinde durur.

Sırlar kayıtlara sızmaz

Denetim kaydına yazılan yük içinde parola ve benzeri alanlar maskelenir. Bir ayar değişikliğinin izi tutulurken değişen sırrın kendisi kayda geçmez.

Denetim Kaydının Bütünlüğü

Denetim kayıtları ürün veritabanındaki tek bir tabloda, SQL Server 2022'nin append-only ledger tablosunda tutulur. Veritabanı motoru bu tabloda kayıt değiştirmeyi ve silmeyi herkes için reddeder, veritabanı yöneticisi dahil. Kayıtlar tek bir yordamla yazılır; olay zamanını uygulama değil o yordam verir ve olay, yaptığı işle aynı transaction'da commit edilir. Kanıt yazılamazsa iş de yapılmaz.

Ürün bu yazma sınırını varsayılan olarak 15 dakikada bir denetler: kanıt tablosunda tetikleyici olmamalı, yazma yordamı yayımlanan sürümle aynı olmalı, kanıt şemasında beklenmeyen nesne bulunmamalıdır. Sınır bozulursa değişiklik işlemleri durur ve olay kaydedilir. API ve Worker veritabanına ayrı, kısıtlı hesaplarla bağlanabilir; defter her kaydı hangi hesabın yazdığını kendisi tutar.

Defter veritabanının içinde durduğu için tek başına yetmez: veritabanını eski bir yedeğe döndüren ya da dosyayı doğrudan değiştiren biri ona karşı da bir şey yapabilir. Bu yüzden defter özeti varsayılan olarak saatte bir alınır. İmza anahtarı ve dış depo klasörü tanımlı kurulumda özet kurumun RSA anahtarıyla imzalanır ve kurumun değiştirilemez deposuna dosya olarak yazılır; bu iki ayar kurulumda yapılmazsa dış dosya yazılmaz ve Yönetişim Kurulum Kontrolü ekranı bunu gösterir. Özeti API üretir ve imzalar; Worker yalnız turu başlatır ve imza anahtarına erişmez. Denetçi, kurumun kendi ortamında bir yedekten geri yüklenmiş kopyada SQL Server'ın kendi yordamıyla bu özetlere karşı doğrular; yedek kurumdan çıkmaz. Denetçinin bunu nasıl yaptığı ayrı sayfada anlatılıyor.

Ürün tablolarındaki satır değişiklikleri ayrıca tetikleyicilerle kaydedilir: veritabanı girişi, makine, uygulama adı, eski ve yeni değer. Bu kayıt bir ipucudur; denetim dosyası, defterle uyuşmayan bir alanı kimin değiştirdiğini bulmak için ona bakar.

Kanıt bir kopyasını sizin sisteminizde de bırakır. Denetim olayları ve defter özeti olayları syslog (TLS, TCP, UDP) ya da dosya ile kurumun SOC toplayıcısına akıtılabilir; işaretli akışta gönderim başarısız olursa bir sonraki tur aynı yerden devam eder (UDP'de tek pakete sığmayan mesaj kaybolabilir, bu yüzden TLS önerilir). Kurum kapsamı daraltabilir ama daralttığını gizleyemez: süzgeçteki her değişiklik SOC'a ayrı olay olarak düşer. Ayrıntı.

Dürüst sınır

Hiçbir yazılım, sunucuya tam yetkiyle erişen bir kişinin her şeyi yapmasını engelleyemez. Defterin verdiği güvence silinmezlik değil, fark edilirliktir: dışarı yazılmış özetten sonra değiştirilen ya da silinen kayıt doğrulamada ortaya çıkar. İki sınırı açıkça söylüyoruz. Birincisi, güven sınırı uygulama kimliğidir: uygulama hesabının parolasına sahip biri yazma yordamından tutarlı görünen bir olay yazabilir; buna karşı kontrol hedefteki bağımsız izleme (DAM ya da SQL Server Audit) kayıtlarının yürütme pencereleriyle eşleştirilmesidir. İkincisi, özet dosyalarının silinmemesi kurumun deposundaki saklama kilidine dayanır; ürün bu kilidi kendisi sağlamaz. Bu sayfada bundan fazlasını vaat etmiyoruz.

Denetim modelinin tamamı ve denetçiye teslim edilen kanıt paketi için denetim kaydı ve kanıt sayfasına bakabilirsiniz.

Entegrasyon	Bağlandığı sistemler	Ne yapar
Bilet sistemi (ITSM)	ServiceNow, Jira, genel REST	Kayıtta ve çalıştırma anında bileti sorar, kapalı ya da onaysız bilette durur, olayları bilete not olarak yazar.
Kurum hesabıyla giriş (SSO)	OIDC: Entra ID, Keycloak, Okta SAML 2.0: AD FS, Entra ID, Keycloak	Parola ürüne gelmez. Ürün rolü kimlik sağlayıcıdaki gruptan atanır.
Kurum dizini (LDAP) ve ikinci faktör	Active Directory, genel LDAP dizinleri	Parola dizinde doğrulanır, roller gruptan gelir, dizinde kapatılan hesap ürüne de giremez. Zaman tabanlı kodla ikinci faktör açılabilir.
SOC ve SIEM	Syslog (TLS, TCP, UDP) ve dosya CEF, LEEF, RFC 5424, JSON	Denetim olaylarını TLS ya da TCP üzerinden akıtır; gönderilemeyen olay atlanmaz, bir sonraki turda yeniden denenir. Kapsamı daraltmak serbesttir, daralttığınızı SOC'tan gizlemek serbest değildir.

Bilet, kimlik ve dizin bağlantıları varsayılan olarak kapalı gelir; SIEM gönderimi ise uç adresi tanımlanmadan başlamaz. Yönetişim Kurulum Kontrolü ekranı her birinin durumunu gösterir. Açmak kurumun kararıdır.

Bilet sistemi

Bilet onaylandı. Peki çalışan iş o bilete mi bağlı?

Değişiklik kurulu (CAB) bir bileti onaylar; ama biletin içinde çalışacak betik yoktur ve onaydan sonra kayıt kapatılmış ya da geri çekilmiş olabilir. Ürün bu boşluğu iki noktada kapatır.

1. Talep kaydedilirken

Girilen numara bilet sistemine sorulur. Kayıt yoksa, türü yanlışsa ya da kapanmışsa talep kaydedilmez. Kip üçtür: kapalı, uyar, engelle. Varsayılan engellemedir.

2. Çalıştırma anında

Aynı bilet bir kez daha sorulur. Önbellek kullanılmaz, çünkü onay kuyruğa alındıktan sonra geri çekilmiş olabilir. Değişiklik kaydı çalıştırılabilir durumda değilse iş başlamaz. Talep ölmez: onaylı kalır ve kayıt uygun hale gelince yeniden çalıştırılır.

Her talep türü ITSM'de karşılığına bağlanır

Ürün içindeki talep	ITSM'deki kayıt	Kural
Değişiklik	Değişiklik kaydı	Var, doğru türde ve çalıştırılabilir durumda olmalı. Planlanan aralık zorunluluğu isteğe bağlıdır.
Sorgu sonucu (veri çıkarma)	Hizmet talebi	Var, doğru türde ve kapanmamış olmalı. Veri istemek bir değişiklik değildir, bu yüzden değişiklik kurulu onayı aranmaz.
Acil talep	Olay kaydı	Acil değişikliğin onayı çoğu kurumda sonradan verilir, bu yüzden değişiklik kurulu onayı aranmaz. Kapanmış ya da bulunamayan değişiklik kaydı yine durdurur; olay numarasının denetimi ise varsayılan olarak uyarı kipindedir ve engellemeye alınabilir. Geçen her acil çalıştırma istisna olarak kayda yazılır.
Geri alma	Kaynak değişikliğin kaydı	Kapıdan muaftır: kaynak kayıt kapanmış olabilir ve geri almayı kilitlemek üretimdeki bozulmanın düzeltilmesini engellerdi. Muafiyet kayda yazılır.

Yazma yönü: ürünün yaptığı, bilet sisteminde görünür

Talep açıldığında, onaylandığında, reddedildiğinde, zamanlandığında, çalıştırıldığında ya da çalıştırma başarısız olduğunda ilgili bilete kısa bir not düşer (ServiceNow'da iş notu, Jira'da yorum). Not metni sabit ve sadedir: betik metni, sonuç verisi ve parola içermez. Bilet sistemine ulaşılamazsa not kaybolmaz; bir sonraki turda aynı yerden devam edilir. Uzun süre gönderilemeyen not varsa bu tek seferlik bir alarm olayı olarak SOC'a gider.

Bilet sistemi kapalı ya da ulaşılamaz olduğunda ne olur

Kapalıyken talep bilet numarasını yalnız biçim kuralına göre doğrular. Entegrasyon varsayılan olarak kapalı gelir.
Ulaşılamazsa kurum iki seçenekten birini belirler: işlemi durdur, ya da işlem sürsün ama doğrulamanın yapılamadığı kayda geçsin ve SOC'a alarm gitsin. Varsayılan ikincisidir. Bilet sistemine ulaşılamaması acil talebi kilitlemez.
Zamanlanan iş için, çalışma saatinde kapının kesin olarak durduracağı durumlar zamanlama sırasında yakalanır; gece duran bir işi sabah e-postayla öğrenmezsiniz.

Denetçiye ne gösterir

Ürünün bilet sisteminde o an gördüğü kayıt (durum, tür, onay alanı) denetim kaydına olduğu gibi dondurulur. Bilet sistemindeki kayıt sonradan değişse bile "o gün ne görüldü" sorusunun cevabı kaybolmaz. Kurala uymayan bilet, doğrulanamayan kayıt, kapıda duran ya da kurul onayı aranmadan geçen çalıştırma ve gönderilemeyen notlar ayrı olay adlarıyla yazılır ve süzgeçten etkilenmeden SOC'a gider.

Bağlayıcılar ve kurulum

ServiceNow: Table API üzerinden değişiklik, olay ve hizmet talebi kayıtları. Jira: REST v2 ve v3; bulutta e-posta ve API anahtarı, veri merkezi kurulumunda kişisel erişim anahtarı. Genel REST: sorgu ve not adresleri şablon olarak tanımlanır, başka bir bilet sistemi için de kullanılabilir. Bağlantı ayarları uygulama ayar dosyasındadır, sırlar yalnız API sunucusunda durur, sertifika doğrulaması varsayılan olarak açıktır. Ayarlar > ITSM ekranında "Bağlantıyı test et" ile gerçek bir kayıt sorgulanır. Bağlayıcılar, bu üç sistemin gerçek yanıt biçimlerini taklit eden bir laboratuvar simülatörüyle uçtan uca sınandı; kurumunuzdaki gerçek örnekle ilk kurulumda birlikte doğrularız.

Kurum hesabıyla giriş

Parola ürüne gelmez, yetki gruptan gelir

Giriş ekranında "Kurum hesabıyla giriş yap" düğmesi çıkar. Kullanıcı parolasını ve ikinci adımını kimlik sağlayıcının kendi sayfasına yazar; ürün yalnızca imzalı cevabı doğrular.

İki protokol

OpenID Connect (yetki kodu akışı, PKCE ile): Microsoft Entra ID, Keycloak, Okta. SAML 2.0 (HTTP-POST): AD FS, Microsoft Entra ID, Keycloak. Birden fazla sağlayıcı aynı anda tanımlanabilir; hatalı bir sağlayıcı kullanılmaz ve diğerlerini ya da yerel girişi etkilemez.

Rol gruptan atanır

Kimlik sağlayıcıdaki gruplar ürün rollerine eşlenir. Birden fazla grup eşleşirse en yüksek rol kazanır. Eşleşme yoksa kişi içeri girmez. Sistem yöneticisi rolü hiçbir eşlemeyle verilmez; bu rol her zaman ürün içinde bilinçli olarak atanır. Rolü elle yönetmek isteyen kurum eşlemeyi kapatabilir.

İşten ayrılan tek yerden kapanır

Kimlik sisteminde hesap kapandığında yeni oturum açılamaz. Ürün tarafında bir kullanıcının oturumları kapatıldığında elde kalan erişim jetonu da bir sonraki istekte reddedilir; oturumun sürenin dolmasını beklemesi gerekmez.

Acil durum girişi görünür kalır

Kurum hesabıyla giriş açıkken yerel parolayla girilirse bu ayrı bir olay olarak yazılır ve SOC'a alarm olarak gider. Denetçi "SSO varken yerel hesapla kim girdi" sorusunu tek satırda görür.

Kurulum ve doğrulama durumu

Sağlayıcılar uygulama ayar dosyasında tanımlanır; değişiklik için API yeniden başlatılır. İlk girişte hesabın otomatik açılması, oturum süresi ve kimlik sağlayıcıdan çıkış ayarlanabilir. Adresler ve SAML üst verisi kurulum ekranında kopyalanabilir biçimde görünür. OpenID Connect ve SAML, yerel bir Keycloak ile uçtan uca ve otomatik testlerle doğrulandı. Entra ID ve AD FS için kurulum adımları hazırdır ve aynı standart protokolleri kullanırlar; kurumunuzun kiracısıyla ilk kurulumda birlikte doğrularız.

Dizin ve ikinci faktör

Kurum dizininiz kimliğin kaynağı olarak kalır

Kimlik sağlayıcınız yoksa ya da dizinle doğrudan konuşmak istiyorsanız Active Directory ve genel LDAP dizinleri desteklenir. Bağlantı, LDAPS ve StartTLS ile bir test dizinine karşı uçtan uca ve otomatik testlerle sınandı; Active Directory ile ilk kurulumda birlikte doğrularız.

Parola dizinde doğrulanır. Üründe tutulmaz. Bağlantı LDAPS ya da StartTLS ile şifrelenir; sertifika doğrulaması yalnız açıkça izin verilirse atlanır. Boş parola dizine hiç gönderilmez, çünkü birçok dizinde boş parolalı bağlantı anonim giriş sayılır ve başarılı döner.
Roller gruptan gelir. İç içe gruplar okunur; bir okuma hatasında rol düşürülmez, çünkü eksik okunmuş bir liste yetkiyi sessizce azaltırdı. Eşleme tam ad ya da kısa ad ile yapılabilir.
Dizinde kapatılan hesap ürüne de giremez. Arka plandaki bir eşitleme işi dizinde kapalı ya da bulunamayan hesapları erişimsiz hale getirir. Son sistem yöneticisi bu yolla kapatılmaz. Eşitleme toplu kapatma sınırına takılırsa ya da dizine ulaşamazsa iş hiçbir değişiklik yapmadan durur ve bu SOC'a alarm olarak gider.
İkinci faktör. Zaman tabanlı tek kullanımlık kod (kimlik doğrulayıcı uygulama) desteklenir. "İkinci faktör açık" ile "herkes kullanıyor" aynı şey değildir: kayıt zorunluluğu ayrı bir ayardır. O ayar açıkken kaydolmamış kullanıcının oturumu yalnız kurulum adımına yarar, başka hiçbir işe yaramaz.

SOC ve SIEM

Kanıt iki ayrı yerde durur: üründe ve SOC'unuzda

Denetim kaydı zaten yalnız ekleme yapılabilen bir defter tablosunda durur. SOC entegrasyonu bunun bir kopyasını kurumun kendi güvenlik sistemine, kurumun kendi biçiminde akıtır. Karar üründe verilir, kaydı güvenlik ekibiniz kendi platformunda da görür; ürünün kaydına güvenmek zorunda kalmaz.

Dört akış, iki mekanizma

Denetim (Audit) ve defter özeti (Anchor) akışları denetim kaydı tablosundan okunur ve "buraya kadar gönderdim" işaretiyle ilerler. Gönderim başarısız olursa işaret ilerlemez, bir sonraki tur aynı yerden devam eder: kayıp yoktur. (UDP bunun dışındadır: tek pakete sığmayan mesajı kaybeder ve kaybettiğini söylemez, bu yüzden TLS önerilir.) Uygulama günlüğü bellekteki bir kuyruktan gider ve kuyruk dolarsa en eski kayıt düşer: bu akışta kayıp mümkündür ve bilinçlidir. Nabız canlılık işaretidir.

Beş biçim, iki taşıyıcı: syslog ve dosya

Biçim: RFC 5424 ile JSON (varsayılan), CEF (ArcSight), LEEF (QRadar), düz JSON ve RFC 5424 yapılandırılmış veri. Taşıyıcı: TLS üzerinden syslog (önerilen), TCP ve UDP; ayrıca toplayıcısı olmayan kurumlar için satır satır JSON dosyası. Birden fazla uç tanımlanabilir ve her biri kendi işaretini tutar. TLS'te sunucu sertifikasının parmak izi verilmişse tutmayan bağlantı reddedilir ve sessizce düz metne düşülmez.

Kapsamı daraltabilirsiniz, gizleyemezsiniz

SIEM lisansları hacme göre fiyatlanır, bu yüzden hangi akışların ve hangi ciddiyet eşiğinin gideceğini kurum seçer. Ama beş sınıf eşik ne olursa olsun gider: kontrolleri değiştiren ya da gevşeten işlemler (kimlik ve yetki değişiklikleri dahil), acil müdahaleler ile bilet sistemi istisnaları, reddedilen yetkiler ile başarısız girişler, defter özeti olayları (yayımlanan ya da üretilemeyen özet, geri yükleme) ve kanıt yazma sınırının bozulması ya da yeniden sağlanması. Süzgeçte yapılan her değişiklik SOC'a ayrı bir duyuru olarak da düşer.

Kurum dışına ne çıkar, ne çıkmaz

Mesaja yalnız izin verilen alanlar girer; tanınmayan hiçbir alan gitmez. Hangi sunucu, hangi risk bandı, kaç ifade gibi olayı sınıflandırmaya yarayan bilgiler gider; hangi satırların döndüğü gitmez. Betik metni varsayılan olarak SOC'a gönderilmez, göndermek ayrı bir ayardır.

Tanılama, SOC ve SIEM ekranı: tanımlı uçlar, hedef, biçim, akışlar, eşik, gecikme ve son gönderim zamanı — **Uçların durumu** Her uç için hedef, biçim, akışlar, eşik, gecikme ve son gönderim zamanı.

SOC toplayıcısına düşen iki syslog satırı: Siem.FilterChanged olayı, süzgecin hangi akışları kapattığını ve geri açtığını gösteriyor — **Daraltmanın duyurusu** Süzgeçten bir akış çıkarıldığında toplayıcıya Siem.FilterChanged olayı düşer: eski ve yeni değer birlikte.

Konu	Nasıl çalışır
Ayar yeri	Bağlantı bilgileri (adres, protokol, sırlar) uygulama ayar dosyasındadır. Süzgeç ve politika kararları Ayarlar ekranındaki parametrelerdedir; değiştirilince denetim kaydına yazılır ve ayar onayı açıksa dört göz onayından geçer.
Kurulum kontrolü	Yönetişim Kurulum Kontrolü ekranı, her entegrasyonun açık mı kapalı mı olduğunu ve ayar hatalarını listeler. Hatalı bir ayar sessizce kullanılmaz.
Kurulum süresi	Adım adım kurulum ve entegrasyon ayarları Kurulum ve İşletim dokümanında anlatılır. Ön hazırlık listesi hangi hesapların, sertifikaların ve portların gerektiğini önceden söyler.

Yol Haritası: Henüz Uygulanmamış Olanlar

Aşağıdakiler bugün üründe yoktur. Değerlendirmenizi bunlara göre yapmayın; sormanız gereken şeyleri sormanız için buraya yazıyoruz.

Dinamik SQL'in çalıştırdığı ifadenin kaydı. Bir betik çalışma anında metin üretip çalıştırıyorsa (EXEC, sp_executesql) ürün bunu yüksek riskli bir bulgu olarak işaretler, ancak gerçekte çalışan ifadeyi göremez ve denetim kaydına yazamaz. Bu, ayrıştırmanın doğasından gelen bir sınırdır.
Dağıtım hatları için servis hesabı ve erişim anahtarı. Ürüne bugün yalnız insanlar girer. Jenkins, Azure DevOps, GitLab CI ve GitHub Actions için ayrı hesap ve süreli erişim anahtarı yol haritasının ilk sırasındadır.
Bilet açma ve kullanıcı sağlama. Ürün bilet sistemine not yazar ama bilet açmaz ve bilet durumunu değiştirmez. Kimlik sağlayıcıdan otomatik kullanıcı sağlama protokolü (SCIM) sunmaz; hesap ilk girişte açılır.
Ürünün kendi kayıt veritabanı yalnız SQL Server'dır. Bu bir tercih değil, bugünkü sınırdır: PostgreSQL ve Oracle kayıt veritabanı olarak desteklenmez ve seçenek olarak da sunulmaz. Denetim kayıtlarının tutulduğu ledger tablosu da bu nedenle SQL Server 2022 ister. Yönetilen hedef veritabanlarını etkilemez: hedef olarak SQL Server, PostgreSQL ve Oracle üçü de bugün desteklenir, her biri kendi dilbilgisiyle ayrıştırılır ve kendi bağlantı katmanıyla çalıştırılır.
Bağımsız güvenlik sertifikasyonu. Ürün herhangi bir sertifikasyona sahip değildir ve olduğunu iddia etmiyoruz. Buna karşılık kurumunuzun kendi güvenlik değerlendirmesine tam açıklık sağlıyoruz: mimari, veri akışı ve kontrol listesi paylaşılır.