Makale Özeti

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.

Makale

Merhaba,

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