Bu özellik, kısmen de olsa SQL Server 2005' te SQL Trace gerçekleştirilebiliyordu.
Kısmen diyorum, çünkü "hangi veritabanına kimler erişmiş?" gibi denetimleri SQL Trace
ile yapamıyorduk. Bu tür denetimleri gerçekleştirmek için üçüncü parti programlar
kullanılıyor
veya alternatif yöntemlerle gerçekleştirilmeye çalışılıyordu. Fakat
artık, bu tür denetimler de SQL Server 2008 ile gerek veritabanı, gerekse
sunucu düzeylerinde yapabiliyor.
Denetim derken...?
Denetimden kasıt, "Veritabanımdaki bir tabloya\tablolara kim erişmiş?", "Kim
yeni kayıt eklemiş veya silmiş veya değişiklik yapmış?", "Kim yeni bir Login
oluşturmuş?" gibi sorulara ayrıntılı olarak cevap bulmanızdır. Sunucu veya veritabanı
düzeyinde, çeşitli denetimleri SQL Server 2008' in bu özelliği ile takip edebilirsiniz. İleriki bölümlerde ayrıntılı örneklerini
de göstereceğim.
Nasıl yapılır?
Önceki paragraflarda da belirttiğim gibi, denetim işlemi hem sunucu düzeyinde, hem
de veritabanı düzeyinde gerçekleştirilebilir.
Bir denetim işlemini başlatmadan önce, bu denetim kayıtlarının nerede, nasıl ve
hangi ayarlara göre saklanması gerektiğini ayarlamanız gerekiyor. Bunun için, ilk
önce sunucu düzeyinde bir Audit oluşturmalısınız. Ardından, eğer denetimi
sunucu düzeyinde yapmak istiyorsanız bir Server Audit Specification, eğer
denetimi veritabanı düzeyinde oluşturmak istiyorsanız o zaman da bir Database Audit
Specification oluşturmalısınız.
Bu elemanları ister T-SQL kullanarak, isterseniz de SQL Server 2008
ile birlikte gelen SQL Server Management Studio ile oluşturabilirsiniz. Örneklerimizde
ben iki yöntemi de kullanacağım. Böylece iki yöntem hakkında da fikriniz olacak.
Şimdi, aşağıda da listelediğim bu üç denetim elemanını nasıl oluşturacağınızı, bunların
ne olduğunu ve bu denetim sonucu oluşan raporu nasıl okuyacağınızı adım adım kendi
başlıkları altında inceleyelim.
- Audit : Denetim verilerinin saklanacağı konum ayarları.
- Server Audit Specification: Sunucu düzeyinde belirlenecek denetim
kuralları.
- Database Audit Specification: Veritabanı düzeyinde belirlenecek denetim
kuralları.
- Log Viewer - Audit: Audit nesnesinde tanımladığımız raporun okunması.
Yapacağımız örneklerde bir senaryo üzerinden gidersek, konunun ve bu denetim mekanizmasına
aşina olmayanların konuyu anlamasına yardımcı olacağını düşünüyorum. Senaryomuz
şöyle: Şirketimizde, bilişim işleriyle ilgili taşeron bir firma var. Bu firmadan
çalışanlar zaman zaman şirketimize geliyorlar ve SQL Server sunucumuzda bazı
çalışmalar yapıyorlar. Ayrıca, bu arkadaşların SQL Server Instance' ımıza
da erişim hakları var. SQL Server Instance' ımızdaki veriler bizim için çok
kritik ve önemli. Taşeron firmadan gelen arkadaşların yetkileri yüksek, bu nedenle
görmelerini istemediğimiz verilere erişme şansları var. Yaptığımız yazılı anlaşmalar
neticesinde, böyle bir şeyin olmayacağını garanti ediyorlar. Ama herkesin malûmu,
sonuçta ortada bir insan faktörü var ve biz veritabanı yöneticileri, güvenliği sıkı
tutmalıyız. Aksi takdirde hesap sorulacakların en üst sıralarında bizim de isimlerimizin
olduğunu çok iyi biliyoruz.
Özetle, şirketimize gelen taşeron firma çalışanlarının, "Muhasebe" isimli veritabanındaki
tablolarımıza erişim erişmediklerini sıkı bir şekilde kontrol edeceğiz.
Audit
Audit' in nasıl oluşturulduğuna geçmeden önce, Audit' in üç farklı
yere kaydedilebileceğini belirtmek istiyorum. Bunlar:
- Windows Event Log: Application Log' a
- Windows Event Log: Security Log' a
- Dosya sisteminde bir dosyaya.
Not: Security Log' a kayıt işlemi Windows XP' de gerçekleştirilemiyor.
Ayrıca, Security Log' a kayıt yaptırmak için ekstra ayarlar yapmanız gerekiyor.
Bu ekstra ayarlar konusunda daha fazla bilgi için
buraya tıklayın.
Biz örneğimizde, denetim verilerimizi bir dosyaya kaydedeceğiz.
T-SQL Yöntemiyle Audit Oluşturmak:
CREATE SERVER AUDIT [AuditTaseron] TO FILE
(FILEPATH = N'C:\Test\' ,
MAXSIZE = 500 MB ,
MAX_ROLLOVER_FILES = 5,
RESERVE_DISK_SPACE = OFF )
WITH
(QUEUE_DELAY = 1000 ,
ON_FAILURE = SHUTDOWN )
GO
Bir Audit nesnesi oluşturulduğunda, varsayılan olarak kullanılamaz (disabled)
şekilde oluşturulur. (bkz. Resim - 3)
Dikkatinizi çektiyse, FILEPATH ile bir dosya adı değil, klasör yolu belirttim.
Çünkü dosya adını, SQL Server kendi atayacak. MAXSIZE
ise, denetim dosyasının ulaşabileceği en büyük dosya boyutu olacak. Bu ayarı yapmakta
fayda var, çünkü zaten sunucunuzda bir çok kayıt dosyası sürekli doluyor ve büyüyor.
Bu tür büyümeleri kontrol altında tutarsanız, bir gün "Diskinizde boş yer kalmadı!"
gibi bir sürpriz ile karşılaşma olasılığınız azalır. MAX_ROLLOVER_FILES,
kaç tane dosyanın kaydedileceği bilgisidir. 0 değeri sınırsız anlamına gelir.
RESERVE_DISK_SPACE, MAXSIZE' da belirttiğiniz kadar alanı baştan
ayırmak için kullanılır; eğer değeri ON ise, o zaman bu alan baştan ayrılır,
eğer OFF ise, alan ihtiyaca göre ayrılır.
Audit işlemi, Service Broker temel alınarak yapılan bir işlemdir.
İşlemler istenirse eşzamanlı (synchronous), istenirse de
eşzamansız (asynchronous) olarak gerçekleştirilebilir. İşte bu ayar da QUEUE_DELAY
ile belirtilir. Eğer bu ayarın değeri 0 ise, denetim sırasında toplanan veriler,
kayıt yerine (Event Log' lara veya dosyaya) eşzamanlı olarak kaydedilir.
Eğer bu değer 1000 ise (ki bu değerler milisaniye bazındadır ve asgari değer 1000'
dir) o zaman biriktirilen denetim verileri, kayıt deposuna her bir saniyede bir
yazılır. Burada dikkate alınması gereken şey ise, eşzamanlı veya çok kısa aralıklı
yapılacak kayıt işlemlerinin belli bir oranda yük getirmesi olacaktır. Sisteminizin
durumuna göre bu kayıt aralığını hesaplamalısınız. Ayrıca şunu da unutmamalısınız
ki, eğer bu kayıt aralığını fazla uzun tutarsanız, kayıt deposuna kaydedilmemiş
denetim verilerini bir elektrik kesintisi veya bir donanım arızası yüzünden kaybetme
olasılığınız vardır.
ON_FAILURE ise iki değer alabilir, SHUTDOWN veya CONTINUE.
Eğer kayıt dosyasında yer kalmadıysa veya diskinizde yer kalmadıysa yani özetle
eğer denetim verileriniz kayıt deposuna kaydedilemiyorsa ve bu ayarın değeri de
SHUTDOWN ise, o zaman SQL Server Instance' ınız böyle bir durumda
kapanacaktır.
SQL Server Management Studio (SSMS) Kullanarak Audit Oluşturmak:
Denetimler, güvenlikle ilgili ve sunucu düzeyinde çalışan nesnelerdir. Bu nedenle
yeni bir Audit oluşturmak istediğinizde, SSMS' teki Object Explorer
penceresinden, Security->Audits bölümüne gidersiniz.
(bkz Resim 1)

Resim - 1
Resim-1 de de görüldüğü gibi, Audits düğümünün üzerinde fare ile sağ
tuşa tıkladığınızda "New Audit..." öğesini göreceksiniz.
Bu öğeye tıklayın, "Create Audit" penceresi açılacaktır.

Resim - 2
Yine bu başlık altında, T-SQL kullanarak oluşturduğumuz Audit in aynısı,
fakat bu sefer bu Audit' i SSMS kullanarak oluşturuyoruz. Resim - 2'
de gördüğünüz tüm ayarları zaten yukarıda açıklamıştım, bu nedenle tekrar açıklamaya
gerek yok. Biraz gözatarsanız zaten her şeyin aynı olduğunu göreceksiniz.
Daha önceden size yeni bir Audit nesnesi oluşturduğunuzda, bu nesnenin varsayılan
olarak kullanılamaz şekilde oluşturulduğunu söylemiştim. Şimdi bunu tekrar belirtmemin
nedeni ise, SSMS' te bu kullanılamazlığın görsel olarak
da belirtilmesidir. Bunun için Resim -3' e bakın. Daha belirgin olması için
kırmızı bir halka içine aldım.

Resim - 3
Bu nesneyi kullanılabilir hale getirmek için, üzerinde farenin sağ tuşuna tıklamanız
ve "Enable Audit" öğesini seçmeniz gerekiyor. Bu noktada şunu da belirtmek
istiyorum ki, daha sonraki başlıklarda oluşturacağımız Server Audit Specification
ve Database Audit Specification nesneleri de varsayılan olarak kullanılamaz
şekilde oluşturulur ve bu nesneler kullanılamaz durumdayken bu durum, Object Explorer'
da aynen Resim - 3' teki gibi aşağı kırmızı bir ok ile görsel olarak belirtilir
ve bu nesneleri kullanılabilir duruma getirmek için yine aynı şekilde bu nesnelerin
üzerinde fare ile sağ tıklayıp "Enable ..." öğesini seçmeniz gerekir.
Bu noktada, artık Audit oluşturma konusunda bir sıkıntı kalmadığını varsayıyorum.
Hadi, şimdi de Server Audit Specification nasıl oluşturulur onu inceleyelim!
Server Audit Specification
Bir Server Audit Specification nesnesi oluşturmadan önce, bu nesneyi oluştururken
kullanmak üzere bir Audit nesnesinin önceki başlıkta da anlatıldığı gibi
oluşturulması gerekiyor.
Bir Server Audit Specification nesnesi oluşturulduğunda, varsayılan olarak
kullanılamaz (disabled) şekilde oluşturulur.
T-SQL Yöntemiyle Server Audit Specification Nesnesi Oluşturma
Bu örneğimizdeki Server Audit Specification nesnesine , 4 tane Action Type
ekleyeceğim.
CREATE SERVER AUDIT SPECIFICATION [sasTaseron]
FOR SERVER AUDIT [AuditTaseron]
ADD (LOGIN_CHANGE_PASSWORD_GROUP),
ADD (SERVER_ROLE_MEMBER_CHANGE_GROUP),
ADD (SERVER_PRINCIPAL_CHANGE_GROUP),
ADD (DATABASE_CHANGE_GROUP)
GO
Bir Server Audit Specification nesnesini oluşturmak için öncelikle bir Audit
nesnesine ihtiyacımız olduğunu önceden de söylemiştim. İşte bu örneğimizde de önceki
Audit altbaşlığında oluşturmuş olduğumuz "AuditTaseron"
nesnesini kullanıyoruz. Daha sonra da, aşağıda listelediğim Action Type'
ları ekliyoruz:
- LOGIN_CHANGE_PASSWORD_GROUP: Bu olay, sp_password veya
ALTER LOGIN komutlarıyla bir Login' in şifresi değiştirildiğinde
tetiklenir.
- SERVER_ROLE_MEMBER_CHANGE_GROUP: Bu olay, bir Login, bir Server Fixed
Role' e eklenip veya çıkarıldığında tetiklenir.
- SERVER_PRINCIPAL_CHANGE_GROUP: Bu olay, örneğin bir Login'
in silinmesi veya yeni bir Login' in eklenmesi veya bir Login
üzerinde bir takım değişiklikler (örneğin Login' in varsayılan dilini
değiştirdiğinizde) yaptığınızda tetiklenir.
- DATABASE_CHANGE_GROUP: Bu olay, bir veritabanı silindiğinde, yeni bir
veritabanı oluşturulduğunda veya varolan bir veritabanında değişiklik yapıldığında
tetiklenir.
Biz örneğimizde sadece 4 tane Action Type kullandık, fakat bu Action Type'
lardan başka daha bir çok Action Type vardır. Diğer Action Type' lar
hakkında daha fazla bilgi almak için Books Online' a bakabilirsiniz:
http://msdn.microsoft.com/en-us/library/cc280663.aspx
SQL Server Management Studio (SSMS) Kullanarak Server Audit Specification
Oluşturmak:
Server Audit Specification nesnesi de Audit nesnesi gibi güvenlikle
alâkalı bir nesne olduğu için, SSMS' teki Object Explorer'
ın, Security düğümünün altında bulunur. (bkz Resim - 4)

Resim - 4
"New Server Audit Specification..." öğesine tıkladığınızda "Create Server
Audit Specification" penceresi açılacaktır. (bkz Resim - 5)

Resim - 5
Bu pencerede temel olarak yapacağınız işlem, bu Server Audit Specification
nesnesine bir isim vermek, önceden oluşturduğunuz Audit nesnesini, Audit
aşağı açılır kutusundan belirlemek ve Audit Action Type listesindeki aşağı
açılır kutulardan, ihtiyacınıza göre Action Type' lar eklemektir.
Aynı örneği yukarıda T-SQL ile yaparken size bir çok Action Type olduğunu
söylemiştim. Bu Action Type' ların listesini de bu şekilde görmüş oldunuz.
Bunların açıklamaları için yine yukarıda verdiğim Books Online adresinden
yararlanabilirsiniz. Books Online' nın maalesef bir Türkçe versiyonunun olmadığını
da bilmeyenler ve merak edenler için belirteyim.
Audit ve Server Audit Specifications açıklamalı ve adım adım uygulamış olduğumuz
örneklerden sonra sıra şimdi de Database Audit Specifications
konusunda!
Database Audit Specifications
Yine belirtmem gerekiyor ki, bir Database Audit Specification nesnesi oluşturmadan
önce, bu nesneyi oluştururken kullanmak üzere bir Audit nesnesinin
Audit başlığında da anlatıldığı gibi oluşturulması gerekiyor.
Ve yine belirtmekte fayda var ki, bir Database Audit Specification nesnesi
oluşturulduğunda, varsayılan olarak kullanılamaz (disabled) şekilde
oluşturulur.
Bu örnekte, öncelikle hayali taşeron firma için bir Login,
"Test" isimli veritabanımızda, oluşturacağımız "TestLogin" isimli Login
için "TestUser" isimli bir de User oluşturacağız. Daha
sonra, hayali "Alacaklar" isimli tablomuzda, bu "TestUser" kullanıcısı tarafından
bir SELECT, UPDATE, INSERT veya
DELETE komutunun çalıştırılmasığını
kontrol etmek için bir Database Audit Specification nesnesi oluşturacağız.
Diğer örneklerimizde olduğu gibi, bu örneği de hem T-SQL ile,
hem de SSMS kullanarak yapacağız.
T-SQL Yöntemiyle Database Audit Specification Nesnesi Oluşturma
Aşağıdaki T-SQL kodlarını çalıştırmadan önce, önceden oluşturmuş olduğumuz
"AuditTaseron" isimli Audit nesnesini ve "sasTaseron" isimli Server Audit
Specification nesnesini kullanılır (Enable) duruma getirdiğinizden
emin olun. Nedenini daha sonra söyleyeceğim.
-- "TestLogin" isimli Login' in oluşturulması
USE [master]
GO
CREATE LOGIN TestLogin WITH PASSWORD = 'Pa$$w0rd'
GO
-- Test için kullanılacak, "Test" isimli veritabanının oluşturulması
USE [master]
GO
CREATE DATABASE [Test]
GO
-- Test için kullanılacak "Alacaklar" isimli veritabanının oluşturulması
USE [Test]
GO
CREATE TABLE [Alacaklar]
(id int)
GO
/* "Test" isimli veritabanında işlem yapabilmesi için, taşeron firma çalışanı tarafından
kullanılacak "TestUser isimli kullanıcının oluşturulması */
USE [Test]
GO
CREATE USER [TestUser] FOR LOGIN [TestLogin]
WITH DEFAULT_SCHEMA=[dbo]
GO
-- "TestUser" isimli kullanıcının "db_owner" veritabanı rolüne eklenmesi
USE [test]
GO
EXEC sp_addrolemember N'db_owner', N'TestUser'
GO
/* "TestUser" isimli taşeron firma çalışanının "Alacaklar" tabloasuna karşı yapacağı
erişimleri takip etmek için kullanılacak "dasAuditTaseron" isimli Database Audit
Specification nesnesinin oluşturulması */
USE [Test]
GO
CREATE DATABASE AUDIT SPECIFICATION [dasAuditTaseron]
FOR SERVER AUDIT [AuditTaseron]
ADD (SELECT ON OBJECT::[dbo].[Alacaklar] BY [TestUser]),
ADD (DELETE ON OBJECT::[dbo].[Alacaklar] BY [TestUser]),
ADD (INSERT ON OBJECT::[dbo].[Alacaklar] BY [TestUser]),
ADD (UPDATE ON OBJECT::[dbo].[Alacaklar] BY [TestUser])
GO
Hemen bir önceki paragrafta örneğimizi anlattığım gibi, yukarıdaki T-SQL
diliyle de bu örneği SQL Server' a anlatmış oldum.
Server Audit Specification' da olduğu gibi, Database Audit Specification'
da da, bir çok Action Type bulunmaktadır. Bu Action Type' ların listesini
bir sonraki SSMS örneğimizdeki "Create
Database Audit Specification" isimli penceredeki Action Type aşağı açılır
kutularında zaten göreceksiniz. Bu Action Type' ların açıklamaları
için yine Books Online' dan yararlanabilirsiniz:
http://msdn.microsoft.com/en-us/library/cc280663.aspx
SQL Server Management Studio (SSMS) Kullanarak Database Audit Specification
Oluşturmak:
Evet! Tahmin edeceğiniz üzere yine aynı şeyi söyleyeceğim! Database Audit Specification
nesnesi de elbette güvenlikle alâka bir nesne. Bu nedenle bu nesneler, SSMS'
teki Object Explorer' ın Databases isimli düğümünün
altındaki veritabanınızın içinde bulunan Security düğümündeki Database Audit
Specifications içinde depolanıyor.
Kabul ediyorum, bu terimlere aşina olmayanlara biraz arapsaçı gibi görünmüş
olabilir. Ama beni önceden takip edenler bilir, hem de buraya kadar sabredip okumuşsanız
siz de görebilirsiniz ki, hiç üşenmeden resimlerle de örnek vermeyi çok severim
ben. Hemen aşağıdaki resimde (Resim - 6) Database Audit Specification düğümünü görebilirsiniz.

Resim - 6
"New Database Audit Specification..." öğesine tıkladığınızda
"Create Database Audit Specification" penceresi açılacaktır. (bkz Resim -
7)

Resim - 7
Eğer dikkatli bakarsanız, bu arayüzün de, "Create Server Audit Specification" penceresinin
arayüzüyle aynı olduğunu görürsünüz ve eğer o penceredeki Object Class,
Object, Object Name, Principal
alanlarındaki kutucukları kurcaladıysanız, herhangi bir değişiklik
yapamadığınızı görmüşsünüzdür. Tek arayüzde iki iş yaptırmaya çalışınca, böyle sonuçlar
çıkabiliyor elbette. Neyse ki, bu alanları "Create Database Audit Specification"
penceresinde kullanabiliyoruz.
Bildiğiniz üzere Audit Action Type alanında, ihtiyacınıza uygun
Action Type' ı seçiyorsunuz. Object Class alanında, seçebileceğiniz
üç tane seçenek var. Bunlar: Database, Object ve
Schema. (Bu kavramların anlamları ise başka bir konu olduğu ve konumuzun
kapsamında olmadığı için bunlara değinmiyorum.) Üzerinde denetim yapmak istediğiniz
nesneye göre, Object Class' ını seçersiniz. Meselâ biz örneğimizde "Alacaklar"
isimli tabloyu denetlemek istediğimiz için, Object Class olarak "Object"
i seçtik. Eğer "Test" isimli veritabanımızdaki tüm tabloları denetlemek isteseydik,
o zaman Object Class' ı "Database" olarak seçerdik, Object Name olarak da "Test" i seçerdik. Eğer belli bir kullanıcı veya
rolü değil de, tüm kullanıcı ve rolleri denetlemek isteseydik, o zaman
Principal alanında bir şey seçmezdik.
Audit, Server Audit Specification ve Database Audit Specification
nesneleri için geçerli olan şu kuralı da unutmamalısınız, bu nesnelerden birinde
bir değişiklik yapmadan önce, o nesneyi kullanılamaz (disable) duruma getirmeniz
gerekir. Aksi takdirde şu hata ile karşılaşırsınız: "Changes
to an audit specification must be done while the audit specification is disabled.
(Microsoft SQL Server, Error: 33229)".
Log Viewer - Audit
Önceki konu başlıklarında bir Audit' in nasıl oluşturulacağını, bu Audit'
in oluşturulmasının sebebi olan bir Server Audit Specification veya Database
Audit Specification nesnesinin nasıl ve ne gibi amaçlar için oluşturulabileceğini
anlattım. Şimdi sıra, yaptığımız bu otomatik denetim mekanizmasının ürettiği raporların
nasıl okunabileceğine geldi.
Bir Audit dosyasının ürettiği kayıt dosyasını okuyabilmek için kullanabileceğiniz
en pratik ve kısa yol, SSMS' teki Log Viewer' ı kullanmaktır.
Bunun için, SSMS' i açtıktan sonra Resim - 1' de gösterilen Audits
düğümü altında oluşturduğunuz Audit nesnesinin üzerinde farenin sağ tuşuna
tıklayıp "View Audit Logs" öğesine tıklayın. Bu sayede, Log Viewer
açılır ve ilgili Audit nesnenizin ürettiği kayıtları görebilirsiniz.
Yukarıda yaptığımız örneklerde hatırlarsanız "TestLogin" adında bir Login
oluşturmadan önce size "AuditTaseron" isimli Audit nesnesini
ve "sasTaseron" isimli Server Audit Specification nesnesini kullanılabilir
duruma getirin demiştim, bunun nedenini de daha sonra söyleyeceğim demiştim. İşte
şimdi söylüyorum; bunun nedeni, CREATE LOGIN komutuyla birlikte sunucu düzeyinde
bir işlem yapmamızdı. "Eee?" mi diyorsunuz? O zaman şunu da hatırlatayım, "sasTaseron"
ismiyle oluşturduğumuz Server Audit Specification nesnesinin içine bir de
SERVER_PRINCIPAL_CHANGE_GROUP Action Type' ı eklemiştik. Bu Action
Type' ın takip ettiği olaylardan biri de neydi? Login
oluşturulması! Yani eğer CREATE LOGIN komutuyla "TestLogin" Login'
ini oluşturmadan önce "AuditTaseron" ve "sasTaseron" isimli nesneleri kullanılabilir
duruma getirdiyseniz, "TestLogin" ismindeki Login' i oluşturduğunuz denetim
kayıtlarına geçmiş demektir. Sizi bilmiyorum, ama ben nizami şekilde kendi dediklerimi
uyguladım ve sonucunu görmek için Resim - 8' e bakabilirsiniz.

Resim - 8
Aslında kaydırma çubuğundan da anlaşılabileceği üzere, oldukça çok alan var ve bu
kadar alanı bu kadar küçük bir resme sığdırmak imkânsız. Sığdırsam bile herhalde
mikroskopla incelemeniz gerekirdi. Ama yine de bu resimde, elimden geldiğince çok
veriyi size göstermeye çalıştım. Alanlardan anlatmaya başlarsak, örneğin, bu komutun
çalıştırıldığı tarih ve saati görebilirsiniz. Hangi SQL Server Instance'
ında gerçekleştiği (EKREM-PC), hangi komutun çalıştırıldığı (CREATE) ve bu komut
ile hangi sınıf işlem yapıldığı (SQL LOGIN) ve daha bir çok bilgiyi görebilirsiniz.
Aşağıdaki ayrıntılı bilgi alanına bakarsak, ilk göze çarpacak bilgilerden birisi,
"CREATE LOGIN TestLogin WITH PASSWORD '*****'" tür sanırım. Hangi nesnenin hangi
komutla oluşturulduğu bilgisi oldukça değerli olabilir. Ayrıca bu nesneyi hangi
Login' in oluşturduğunu da görebilirsiniz (EKREM-PC\ekrem).
Bununla birlikte, yine Resim - 8' deki "File Name" bilgisi dikkatinizi çekti
mi? Hatırlarsanız, "AuditTaseron" isimli Audit nesnesini oluştururken dosya
adı değil, sadece dosya yolu belirtilir demiştim. Dosya adını ise, SQL Server,
Audit nesnesinin adı olarak belirlediğiniz bir ad ile birlikte bir
GUID (Globally Unique Identifier)' i birleştirerek ve uzantısını da ".sqlaudit"
yaparak verir. Bu resimde, bir çok bilgiyle birlikte bu dosya adını da görebiliyorsunuz.
Ayrıca, test etmek için şimdi gidip, "dasTaseron" ismiyle oluşturduğumuz Database
Audit Specification nesnesini de kullanılılabilir duruma
getirebilirsiniz. Bu nesneye ait kayıtlara da, "sasTaseron" isimli Server Audit Specification
nesnesinde olduğu gibi, o nesnenin bağlı olduğu
Audit nesnesinin üzerinde farenin sağ tuşuna tıklayarak
ve "View Audit Logs" öğesini seçerek ulaşabilirsiniz. "TestUser" isimli kullanıcının
"Alacaklar" isimli tabloya yapacağı SELECT, UPDATE,
DELETE ve INSERT (DML - Data Manipulation Language) işlemleri
yine bu kayıt dosyasında, aynen CREATE LOGIN işlemindeki gibi kaydedilecektir.
Fakat "dasTaseron" nesnesini test etmek için sunucuya "TestLogin" ile giriş yapmalı
ve bu Login' in "Test" isimli tablodaki bağlı olduğu kullanıcı olan "TestUser"
kullanıcısıyla "Alacaklar" tablosuna karşı bir DML işlemi yapmanız gerekiyor. Çünkü
hatırlarsanız, Database Audit Specification nesnemizi bu kriterlere göre
oluşturmuştuk. Eğer dediğim gibi "TestLogin" kullanıcısıyla bağlanıp "Alacaklar"
tablosuna bir sorgu çekerseniz, göreceksiniz ki "AuditTaseron" isimli Audit
kayıt dosyasınaki CREATE LOGIN komutunun üzerine bu yaptığınız işlemle
ilgili başka bir kayıt daha eklenecektir.
Özet
Çok beklenen ve SQL Server 2008 ile birlikte gelen bir çok özellikten biri
olan Auditing konusunu size anlatmaya çalıştım. Bu makaleye başlarken de
dediğim gibi, bu gereksinim gerek bazı üçüncü parti yazılımlarla, gerekse SQL Trace
ile giderilmeye çalışılıyordu. Fakat artık SQL Server 2008 ile birlikte,
arayüz desteğiyle de (SQL Trace özelliği için arayüz desteği yoktu) bu iş
oldukça kolaylaştırıldı.
Biz veritabanı yöneticilerinin ana sorumluluklarının başında güvenlik geliyor. "Kim,
hangi bilgiye ne zaman erişmiş?" veya "Bu tablodaki değişikliği kim yapmış?" gibi
sorulara her an yanıt verebilmeliyiz. Bu yeni Auditing özelliği sayesinde, bu konudaki
işimiz daha kolaylaşacak. Umarım bir gün sizin de işinize yarar.
Ekrem Önsoy