SQL Server Audit: Kurulum, Yapılandırma ve İzleme Rehberi

Bir güvenlik olayının ardından sorulan ilk sorular hemen her zaman aynıdır: Bu değişikliği kim yaptı, ne zaman yaptı, hangi makineden bağlandı ve başka neye erişti? KVKK, BDDK düzenlemeleri, iç denetim ya da ISO 27001 kapsamındaki denetimlerde de benzer sorular, bu kez kanıt beklentisiyle birlikte gelir. SQL Server Audit, bu soruların cevabını veritabanı motorunun kendisinden, ek bir ürün gerektirmeden üretmenizi sağlayan özelliktir.

Ancak audit’in değeri, açık olmasından değil doğru yapılandırılmasından gelir. Yanlış olayları izleyen, disk dolduğunda sessizce kayıt üretmeyi bırakan ya da sysadmin yetkisine sahip herkesin silebileceği bir klasörde duran bir audit, ihtiyaç anında beklenen güvenceyi vermez. Bu rehberde SQL Server Audit’in mimarisini, hedef ve hata davranışı seçimlerini, hangi olayların izlenmesi gerektiğini, Always On ortamlarındaki kritik ayrıntıyı ve kayıtların okunup SIEM’e aktarılmasını üretim ortamı bakış açısıyla ele alıyoruz.

SQL Server Audit Nasıl Çalışır?

SQL Server Audit, Extended Events altyapısı üzerine kurulmuştur ve üç bileşenden oluşur:

• Server audit: Kayıtların nereye yazılacağını (hedef) ve hedefe yazılamadığında ne olacağını belirleyen instance düzeyindeki nesnedir. Bir instance üzerinde birden fazla server audit tanımlanabilir.
• Server audit specification: Login, yetki değişikliği, yedekleme gibi sunucu düzeyindeki olay gruplarını tanımlar. Her server audit için bir adet oluşturulabilir.
• Database audit specification: Belirli bir veritabanındaki olayları, örneğin bir tablo üzerindeki SELECT ya da UPDATE işlemlerini tanımlar. Her veritabanında, her server audit için bir adet oluşturulabilir.

Server audit oluşturulduğunda kapalı durumdadır ve hiçbir kayıt üretmez; specification’lar ile birlikte açıkça etkinleştirilmesi gerekir. Sunucu düzeyindeki audit tüm SQL Server sürümlerinde mevcuttur. Veritabanı düzeyindeki audit ise SQL Server 2016 SP1’den itibaren Standard dahil tüm sürümlerde desteklenir; daha önce yalnızca Enterprise sürümünde kullanılabiliyordu.

Audit Ne Değildir?

Audit, bir işlemi kimin, ne zaman ve nereden yaptığını kaydeder; değiştirilen verinin eski ve yeni değerlerini kaydetmez. Ayrıca sorgu işlemcisi bir sorguyu parametreli hâle getirdiğinde, kayıtta gerçek değerler yerine parametre adları görünebilir. Bu nedenle audit’ten beklentiyi doğru konumlandırmak ve gerekirse diğer mekanizmalarla tamamlamak gerekir:

Hedef Seçimi: Dosya mı, Windows Event Log mu?

Audit kayıtları üç hedeften birine yazılabilir. Seçim, kayıtların ne kadar korunacağını ve nasıl toplanacağını doğrudan belirler.

Security log hedefini kullanmak için SQL Server servis hesabını yerel güvenlik politikasında (secpol.msc) “Generate security audits” hakkına eklemeniz ve “Application Generated” alt kategorisini başarılı ve başarısız olaylar için etkinleştirmeniz gerekir:

auditpol /set /subcategory:"application generated" /success:enable /failure:enable

Pratikte en sık kullandığımız yapı, yüksek hacimli olaylar için dosya hedefi, düşük hacimli ancak kritik güvenlik olayları için Security log hedefidir. Dosya hedefi kullanıldığında, dosyaların SIEM ajanı ya da düzenli bir kopyalama işiyle sunucu dışına taşınması gerekir.

Dosya Boyutu, Saklama ve Hata Davranışı

Dosya hedefinde dört ayar, audit’in ne kadar geriye dönük kayıt tutacağını ve disk dolduğunda nasıl davranacağını belirler:

• MAXSIZE: Tek bir audit dosyasının en fazla büyüyebileceği boyuttur. Varsayılan değer UNLIMITED‘dır ve bu durumda dosya disk dolana kadar büyür. Bu nedenle her zaman bir üst sınır belirleyin.
• MAX_ROLLOVER_FILES: Mevcut dosyaya ek olarak tutulacak dosya sayısıdır. Sınıra ulaşıldığında en eski dosya silinir. Örneğin 256 MB ve 40 dosya, yaklaşık 10 GB’lık dönen bir kayıt alanı anlamına gelir.
• MAX_FILES: MAX_ROLLOVER_FILES‘ın alternatifidir; sınıra ulaşıldığında eski dosyalar silinmez ve audit edilen işlemler hata vermeye başlar. Kaydın hiçbir koşulda kaybolmaması gereken ortamlar içindir.
• QUEUE_DELAY: Kayıtların hedefe yazılmadan önce bellekte bekleyebileceği süredir. Varsayılan 1000 milisaniyedir. 0 senkron yazma anlamına gelir ve her audit edilen işlemin kaydın yazılmasını beklemesine neden olur; yoğun sistemlerde varsayılanı korumanızı öneririz.

En kritik karar ise ON_FAILURE ayarıdır. Bu ayar, audit hedefine yazılamadığında, örneğin disk dolduğunda ya da ağ paylaşımına erişilemediğinde, SQL Server’ın ne yapacağını belirler:

• CONTINUE (varsayılan): Veritabanı çalışmaya devam eder, ancak sorun giderilene kadar kayıt üretilmez. Kesintisiz çalışmanın eksiksiz kayıttan daha önemli olduğu sistemler içindir.
• FAIL_OPERATION: Audit kaydı üretecek işlemler hata alır, diğer işlemler devam eder. Örneğin yalnızca hassas tablolara erişim audit ediliyorsa, bu tablolara erişim kayıt yazılamadığı sürece engellenir.
• SHUTDOWN: Audit kaydı yazılamazsa SQL Server instance’ı kapanır. Kaydın eksiksiz olmasının sistemin çalışmasından daha önemli olduğu ortamlar içindir ve oluşturan login’in SHUTDOWN yetkisine sahip olmasını gerektirir.

Neyi Audit Etmeli?

Her şeyi audit etmeye çalışmak, kimsenin okumadığı terabaytlarca kayıt ve ölçülebilir bir performans maliyeti üretir. Daha doğru yaklaşım, olayları hacim ve bilgi değerine göre ayrı audit’lere bölmektir.

1. Güvenlik temeli: her sunucuda sürekli açık

Başarısız login denemeleri, yetki ve rol değişiklikleri, login ve kullanıcı yönetimi, yedekleme ve geri yükleme işlemleri ile audit yapılandırmasının kendisindeki değişiklikler düşük hacimli, ancak bilgi değeri çok yüksek olaylardır. SQL Server güvenlik sıkılaştırma rehberimizde yer alan temel yapıyı biraz daha genişleterek şu şekilde kurgulamanızı öneririz:

USE master;
CREATE SERVER AUDIT [Audit_Guvenlik]
    TO FILE (FILEPATH = N'E:\SQLAudit\', MAXSIZE = 256 MB, MAX_ROLLOVER_FILES = 40)
    WITH (QUEUE_DELAY = 1000, ON_FAILURE = CONTINUE);

CREATE SERVER AUDIT SPECIFICATION [AuditSpec_Guvenlik]
    FOR SERVER AUDIT [Audit_Guvenlik]
    ADD (FAILED_LOGIN_GROUP),
    ADD (LOGIN_CHANGE_PASSWORD_GROUP),
    ADD (SERVER_PRINCIPAL_CHANGE_GROUP),
    ADD (SERVER_ROLE_MEMBER_CHANGE_GROUP),
    ADD (SERVER_PERMISSION_CHANGE_GROUP),
    ADD (SERVER_OBJECT_PERMISSION_CHANGE_GROUP),
    ADD (SERVER_PRINCIPAL_IMPERSONATION_GROUP),
    ADD (DATABASE_PRINCIPAL_CHANGE_GROUP),
    ADD (DATABASE_ROLE_MEMBER_CHANGE_GROUP),
    ADD (DATABASE_PERMISSION_CHANGE_GROUP),
    ADD (DATABASE_OBJECT_PERMISSION_CHANGE_GROUP),
    ADD (SCHEMA_OBJECT_PERMISSION_CHANGE_GROUP),
    ADD (DATABASE_OWNERSHIP_CHANGE_GROUP),
    ADD (DATABASE_CHANGE_GROUP),
    ADD (SERVER_OBJECT_CHANGE_GROUP),
    ADD (SERVER_STATE_CHANGE_GROUP),
    ADD (BACKUP_RESTORE_GROUP),
    ADD (AUDIT_CHANGE_GROUP)
    WITH (STATE = ON);

ALTER SERVER AUDIT [Audit_Guvenlik] WITH (STATE = ON);

SUCCESSFUL_LOGIN_GROUP bilinçli olarak listede yer almıyor. Connection pooling kullanan uygulamalarda her havuz bağlantısı bir olay ürettiği için bu grup yoğun sistemlerde günde milyonlarca kayıt oluşturabilir. Başarılı girişlerin izlenmesi gerekiyorsa, uygulama login’lerini dışarıda bırakan ayrı ve filtrelenmiş bir audit kullanmak daha doğru olur.

2. Şema değişiklikleri

Tablo, view ve stored procedure değişikliklerini izlemek, “dün akşam bu procedure’ü kim değiştirdi?” sorusunun cevabıdır. Bunun için SCHEMA_OBJECT_CHANGE_GROUP ve DATABASE_OBJECT_CHANGE_GROUP kullanılır. Gece çalışan index bakım işleri de ALTER INDEX olayları ürettiği için, bakım işlerinin çalıştığı servis hesabını WHERE koşuluyla dışarıda bırakmak gürültüyü önemli ölçüde azaltır:

USE master;
CREATE SERVER AUDIT [Audit_SemaDegisiklik]
    TO FILE (FILEPATH = N'E:\SQLAudit\', MAXSIZE = 256 MB, MAX_ROLLOVER_FILES = 20)
    WITH (ON_FAILURE = CONTINUE)
    WHERE ([server_principal_name] <> N'CORP\svc_sqlagent');

CREATE SERVER AUDIT SPECIFICATION [AuditSpec_SemaDegisiklik]
    FOR SERVER AUDIT [Audit_SemaDegisiklik]
    ADD (SCHEMA_OBJECT_CHANGE_GROUP),
    ADD (DATABASE_OBJECT_CHANGE_GROUP)
    WITH (STATE = ON);

ALTER SERVER AUDIT [Audit_SemaDegisiklik] WITH (STATE = ON);

WHERE koşulu server audit düzeyinde tanımlanır ve bu audit’e bağlı tüm specification’lara uygulanır. sys.fn_get_audit_file tarafından döndürülen alanların çoğu filtrelenebilir; event_time, file_name ve audit_file_offset bu kapsamın dışındadır. action_id ve class_type ise filtrede metin değil sayısal değerlerle kullanılmalıdır.

3. Hassas veriye erişim

Kişisel ya da finansal veri içeren tablolara kimin eriştiğini kaydetmek için database audit specification kullanılır. Audit edilecek nesneyi tablo, şema ya da tüm veritabanı düzeyinde tanımlayabilirsiniz:

USE master;
CREATE SERVER AUDIT [Audit_HassasVeri]
    TO FILE (FILEPATH = N'E:\SQLAudit\', MAXSIZE = 256 MB, MAX_ROLLOVER_FILES = 40)
    WITH (ON_FAILURE = CONTINUE)
    WHERE ([server_principal_name] <> N'MusteriApp');
ALTER SERVER AUDIT [Audit_HassasVeri] WITH (STATE = ON);
GO

USE MusteriDB;
CREATE DATABASE AUDIT SPECIFICATION [AuditSpec_HassasVeri]
    FOR SERVER AUDIT [Audit_HassasVeri]
    ADD (SELECT, INSERT, UPDATE, DELETE ON OBJECT::dbo.Musteri BY public),
    ADD (SELECT ON SCHEMA::Finans BY public),
    ADD (EXECUTE ON OBJECT::dbo.usp_MusteriDisaAktar BY public)
    WITH (STATE = ON);

BY public veritabanındaki tüm kullanıcıları kapsar. Yalnızca yönetici faaliyetlerini izlemek istediğiniz durumlarda, sysadmin üyelerinin her veritabanında dbo kullanıcısı olarak göründüğünü hatırlatmak isteriz; bu durumda BY dbo kullanabilirsiniz. Örnekteki WHERE koşulu ise uygulama login’ini dışarıda bırakır. Uygulamanın bu tablolara yaptığı milyonlarca erişim, hem disk hem performans açısından ciddi bir yük oluşturacağı için, uygulama tarafındaki erişimin uygulamanın kendi loglarıyla izlenmesi çoğu zaman daha gerçekçi bir yaklaşımdır.

SQL Server 2022 ve sonrasında, veri sınıflandırması ile etiketlenmiş kolonlara dokunan sorguları SENSITIVE_BATCH_COMPLETED_GROUP ile kaydedebilirsiniz. Bu grup, tablo tablo tanım yapmak yerine sınıflandırma etiketlerini temel alır. Farklı bir veritabanından gelen sorguların da yakalanması için grubun veritabanı yerine sunucu düzeyinde tanımlanması gerekir.

4. Uygulama dışı kullanıcıların sorguları

DBA’lerin, geliştiricilerin ve raporlama kullanıcılarının doğrudan çalıştırdığı sorgular, bir olay incelemesinde en çok ihtiyaç duyulan kayıtlardır. SQL Server 2022 ve sonrasında BATCH_COMPLETED_GROUP ile batch metninin tamamı kaydedilebilir. Bu audit’i uygulama login’lerini dışarıda bırakan bir WHERE koşuluyla kurmanız hacmi kontrol altında tutar; örnek yapılandırmayı güvenlik sıkılaştırma rehberimizin yedinci adımında bulabilirsiniz.

Always On Ortamlarında Audit: AUDIT_GUID Ayrıntısı

Always On availability group ortamlarında sık atlanan bir ayrıntı vardır. Database audit specification veritabanının içinde saklanır ve veritabanıyla birlikte secondary replikalara taşınır. Server audit ve server audit specification ise instance düzeyindeki nesnelerdir ve replikalar arasında eşitlenmez. Database audit specification, server audit’e adıyla değil GUID’iyle bağlıdır. Secondary replikada aynı GUID’e sahip bir server audit yoksa, failover sonrasında veritabanı düzeyindeki audit hiçbir kayıt üretmeden çalışmaya devam eder.

Bu nedenle server audit’i önce primary replikada oluşturup GUID’ini alın, ardından tüm secondary replikalarda aynı GUID ile oluşturun:

-- Primary replikada:
SELECT name, audit_guid FROM sys.server_audits WHERE name = N'Audit_HassasVeri';

-- Her secondary replikada, aynı GUID ile:
CREATE SERVER AUDIT [Audit_HassasVeri]
    TO FILE (FILEPATH = N'E:\SQLAudit\', MAXSIZE = 256 MB, MAX_ROLLOVER_FILES = 40)
    WITH (ON_FAILURE = CONTINUE, AUDIT_GUID = '5d0a8a5e-6f3c-4c1b-9a51-2f7e3b9c1d42')
    WHERE ([server_principal_name] <> N'MusteriApp');
ALTER SERVER AUDIT [Audit_HassasVeri] WITH (STATE = ON);

Audit Kayıtlarını Okumak

Dosya hedefindeki kayıtlar sys.fn_get_audit_file fonksiyonuyla okunur. Bu fonksiyonu kullanmak için SQL Server 2019 ve öncesinde CONTROL SERVER, SQL Server 2022 ve sonrasında ise VIEW SERVER SECURITY AUDIT yetkisi gerekir. Okurken dikkat edilmesi gereken üç nokta vardır: event_time UTC olarak tutulur, action_id dört karakterlik bir koddur ve client_ip ile application_name alanları SQL Server 2017 ve sonrasında gelir. Aşağıdaki sorgu son 24 saatin kayıtlarını Türkiye saatine çevirir ve işlem kodlarını okunabilir adlarla gösterir:

SELECT
    SWITCHOFFSET(CAST(af.event_time AS datetimeoffset), '+03:00') AS olay_zamani,
    da.name AS islem,
    af.succeeded,
    af.session_server_principal_name AS ilk_login,
    af.server_principal_name AS login,
    af.client_ip,
    af.application_name,
    af.database_name,
    af.schema_name,
    af.object_name,
    af.statement
FROM sys.fn_get_audit_file(N'E:\SQLAudit\Audit_Guvenlik_*.sqlaudit', DEFAULT, DEFAULT) AS af
LEFT JOIN (SELECT DISTINCT action_id, name FROM sys.dm_audit_actions) AS da
    ON da.action_id = af.action_id
WHERE af.event_time >= DATEADD(HOUR, -24, SYSUTCDATETIME())
ORDER BY af.event_time DESC;

session_server_principal_name ile server_principal_name arasındaki fark, EXECUTE AS ile kimlik değiştiren oturumları incelerken önemlidir: ilki oturumu açan asıl login’i, ikincisi işlemin çalıştığı anki kimliği gösterir. Ayrıca fonksiyonun her çağrıda eşleşen tüm dosyaları okuduğunu, WHERE koşulunun ise okuma sonrasında uygulandığını unutmayın. Büyük audit klasörlerinde bu sorgular yavaşlar; düzenli analiz için kayıtları merkezi bir tabloya aktarmak daha verimlidir.

Kayıtları merkezi bir tabloya aktarmak

sys.fn_get_audit_file, okumaya belirli bir dosya ve konumdan başlamayı destekler. Son okunan dosya ve konum bir kontrol tablosunda tutulursa, bir SQL Server Agent job’ı yalnızca yeni kayıtları aktarabilir:

DECLARE @dosya nvarchar(260), @konum bigint;

SELECT @dosya = son_dosya, @konum = son_konum
FROM AuditArsiv.dbo.OkumaDurumu
WHERE audit_adi = N'Audit_Guvenlik';

SELECT event_time, action_id, succeeded, server_principal_name, client_ip,
       application_name, database_name, object_name, statement, file_name, audit_file_offset
INTO #yeni
FROM sys.fn_get_audit_file(N'E:\SQLAudit\Audit_Guvenlik_*.sqlaudit', @dosya, @konum);

INSERT INTO AuditArsiv.dbo.AuditKayit
SELECT * FROM #yeni;

SELECT TOP (1) @dosya = file_name, @konum = audit_file_offset
FROM #yeni
ORDER BY event_time DESC, audit_file_offset DESC;

IF @@ROWCOUNT > 0
    UPDATE AuditArsiv.dbo.OkumaDurumu
    SET son_dosya = @dosya, son_konum = @konum
    WHERE audit_adi = N'Audit_Guvenlik';

Job’ın çalışma aralığını, en eski dosya rollover ile silinmeden önce okunacak şekilde belirleyin; aksi hâlde başlangıç dosyası bulunamadığında okuma hata verir. Microsoft, audit raporlamasının yalnızca audit yöneticilerinin ve okuyucularının erişebildiği ayrı bir instance üzerinden yapılmasını önerir. Bu durumda audit dosyalarını o instance’ın erişebildiği, yetkileri kısıtlanmış bir paylaşıma kopyalayıp aynı yöntemi orada uygulayabilirsiniz.

Audit’in Kendisini Korumak

Audit’in en zayıf noktası, en güçlü yetkilere sahip kişilerin onu değiştirebilmesidir. sysadmin rolündeki her login audit bileşenlerini değiştirebilir veya kapatabilir; db_owner üyeleri de veritabanı düzeyindeki specification’ları değiştirebilir. Bu riski ortadan kaldıramazsınız, ancak görünür hâle getirebilirsiniz:

• Kayıtları sunucudan çıkarın. Security log hedefi ya da dosyaları toplayan bir SIEM ajanı, sunucu üzerindeki bir yöneticinin kayıtları silmesini anlamsız hâle getirir.
• Audit klasörünün yetkilerini daraltın. SQL Server servis hesabı okuma ve yazma, audit yöneticileri okuma ve yazma, audit okuyucuları yalnızca okuma yetkisine sahip olmalıdır.
• Audit dosyalarını kimin okuduğunu da kaydedin. master.sys.fn_get_audit_file üzerine tanımlanacak bir audit, kayıtlara SQL Server üzerinden kimin baktığını gösterir.
• Audit durumunu izleyin. Aşağıdaki sorguyu düzenli çalışan bir job’a ya da izleme aracınıza ekleyerek, durumu STARTED olmayan audit’ler için alarm üretin.

SELECT name, status_desc, status_time, audit_file_path, audit_file_size
FROM sys.dm_server_audit_status;

SIEM tarafında ise özellikle şu durumlar için alarm tanımlanmasını öneririz: yeni bir sysadmin üyeliği, bir audit’in kapatılması veya specification’ının değiştirilmesi, kısa sürede art arda gelen başarısız login denemeleri, mesai dışında hassas tablolara yapılan erişimler ve beklenmeyen bir RESTORE veya yedekleme işlemi.

Ortak Uygulama Login’i Arkasındaki Kullanıcıyı Görmek

Çoğu kurumsal uygulama veritabanına tek bir login ile bağlanır. Bu durumda audit kayıtlarında yalnızca uygulama login’i görünür; ekranda müşteri kartını açan gerçek kullanıcı veritabanı tarafından bilinmez. Uygulama tarafında değişiklik yapılabiliyorsa, kritik işlemleri gerçekleştiren stored procedure’lere sp_audit_write çağrısı ekleyerek uygulama kullanıcısını audit kaydına taşıyabilirsiniz:

-- İlgili specification'a USER_DEFINED_AUDIT_GROUP eklenmiş olmalıdır
-- Uygulamada @UygulamaKullanici ve @MusteriId, procedure'ün parametrelerinden gelir
DECLARE @UygulamaKullanici sysname = N'ayilmaz', @MusteriId int = 42;

DECLARE @bilgi nvarchar(4000) =
    CONCAT(N'uygulama_kullanici=', @UygulamaKullanici,
           N'; islem=MusteriKartiGoruntuleme; musteri_id=', @MusteriId);

EXEC sys.sp_audit_write
    @user_defined_event_id = 1001,
    @succeeded = 1,
    @user_defined_information = @bilgi;

USER_DEFINED_AUDIT_GROUP ilgili server ya da database audit specification’a eklenmemişse sp_audit_write çağrıları hata vermeden yok sayılır. Bu yüzden yapılandırmadan sonra bir test kaydı üretip okuyarak doğrulama yapmanız gerekir.

Uygulama Kontrol Listesi

• Audit dosyaları veri ve log dosyalarından ayrı bir diskte tutuluyor ve bu disk izleniyor.
• Tüm audit’lerde MAXSIZE ve dosya sayısı tanımlı; ON_FAILURE kararı bilinçli olarak verilmiş.
• Güvenlik temeli her sunucuda açık ve AUDIT_CHANGE_GROUP içeriyor.
• Hassas tablolar ve uygulama dışı kullanıcılar ayrı, filtrelenmiş audit’lerle izleniyor.
• Always On replikalarında server audit’ler aynı GUID ile oluşturulmuş; failover sonrası kayıt üretildiği test edilmiş.
• Kayıtlar sunucu dışına, SIEM’e ya da ayrı bir arşiv instance’ına aktarılıyor ve kritik olaylar için alarm tanımlı.
• sys.dm_server_audit_status düzenli olarak kontrol ediliyor.