SQL Server 2005’te sistem metadatasina erisim ve güvenlik mimarisi

Data bildiginiz gibi, bir veritabaninin tablolarinda dogrudan tutulan bilgiye deniyor. Ya da veri… Metadata ise, tablolarin içindeki asil bilgiler degil, bu bilgileri tutmayla ilgili bilgilerdir. Yani veri hakkindaki veriler. Birkaç örnek sayacak olursak: Bir veritabanindaki tablo ya da görüntülerin (view) sayilari, bir tablonun kolonlari hakkinda bilgiler, bir tablo için tanimli kisit ve indekslerle ilgili bilgiler, kullanicilar ve girislerle ilgili bilgiler gibi konular hep metadataya girer.
SQL Server 2000, SQL-92 standartlarina uygun olarak metadaya erisim için INFORMATION_SCHEMA görüntüleri, sunucu ve veritabani seviyesinde sistem tablolari ve sistem yüklü yordamlari ile pek çok olanak sunuyordu. Ama birtakim sorunlar da vardi:
• Her ne kadar tavsiye edilmese de, SQL Server 2000 sistem nesnelerinde dogrudan degisiklik yapilmasina izin veriyordu.
• Bir kullanici, bir nesneye erisim izinleri olmadigi halde o nesne ile ilgili metadataya yukarida bahsedilen yöntemlerle erisebiliyordu.
• Sistem tablolarindaki karmasik gösterimleri sökmek için veritabani yöneticilerinin ve gelistiricilerinin hayli çaba sarf etmesi gerektigi durumlar oluyordu.
• Son olarak, yükseltmeler ve servis paketleri sistem nesnelerinin yok edilip tekrar olusturulmasini gerektiriyordu. Bu hem fazla zaman alan bir yöntemdi, hem de bir servis paketini geri almayi imkansizlastirmasa da çok zorlastiriyordu.
SQL Server 2005’te metadata erisimi bastan düsünülmüs ve güvenlik unsurlari da göz önünde bulundurularak tamamen yeniden tasarlanmistir. Resource adli yeni bir veritabaninin kullanilmasi, sistem metadatasina erisimle ilgili kisitlamalar ve semalar bu yeni tasarimin önemli unsurlari olarak karsimiza çikar.

Resource veritabani

Resource, bu sürümle kullanilmaya baslayan yeni bir veritabanidir. SQL Server 2005’e dahil tüm sistem nesnelerini içerir, gizlidir ve sadece okunabilirdir. Bu bilgiler eskiden Master veritabaninda yer alirdi. Resource veritabaninda yer alan sistem nesneleri, fiziksel olarak burada yer almakla birlikte tüm veritabanlarinda da mantiksal olarak var görünürler. Bu sistem nesnelerine veritabanlarinda sys adli semada erisebiliriz. Resource veritabani grafiksel yönetim araçlarinda ya da sys.databases katalog görüntüsüne eristiginizde gözükmez. Fiziksel veritabani dosyalari ise (mssqlsystemresource.mdf ve mssqlsystemresource.ldf) master veritabani dosyalarinin yer aldigi klasörde yer alirlar. Resource veritabani dosyasinin yerini ya da ismini degistirirseniz, SQL Server baslamaz. Ayrica performans kayiplarinin olusmamasi ve sürüm güncellemelerde olasi sorunlar yasamamak için, Resource veritabanini NTFS dosya sisteminde sikistirilmis ya da sifrelenmis klasörlere koymayin.
Dikkat edilmesi gereken bir nokta, Resource veritabaninin herhangi bir kullanici verisi ya da kullanici metadatasi içermemesidir. Bir SQL Server kurulumuna iliskin sistem seviyesindeki bilgiler yine Master veritabaninda tutulur. Bu sebeple, (dogrudan Resource veritabanina yönelik Microsoft’un yönlendirdigi özel bir çalisma yapilmadikça) Resource veritabanini yedeklemek gerekli degildir.
Resource veritabani SQL Server’in yeni bir sürümüne terfi etmeyi çok daha hizli ve kolay yapabilmeyi mümkün kilar. Önceki sürümlerde terfi, sistem nesnelerini yok etmeyi ve yeniden olusturmayi gerektirirdi. Resource veritabani tüm sistem nesnelerini içerdiginden, bir terfi sadece Resource veritabaninin yeni bir sürümünü yerel sürücüye kopyalamakla mümkündür. Bu ayni zamanda, bir yükseltmeyi geri almak için tüm yapilmasi gerekenin yeni Resource veritabanini istenen sürümdeki Resource veritabani ile geri degistirmek olmasini getirir.
Resource veritabaninin sürümünü ve en son ne zaman güncellendigi bilgisini almak için su sorgulari kullanabilirsiniz:
SELECT SERVERPROPERTY(‘ResourceVersion’);
SELECT SERVERPROPERTY(‘ResourceLastUpdateTime’);
Bu sorgular benim sistemimde, 9.00.1399 ve Null degerlerini veriyor.
Resource veritabanina erismenin tek yolu, SQL Server’i –m baslangiç parametresini kullanarak tek-kullanici admin modunda baslatmak ve sonra da USE mssqlsystemresource SQL ifadesini kullanmaktir. Bunu yaptiktan sonra, master veritabanindaki ve herhangi bir kullanici veritabanindaki temel sistem tablolarini dogrudan sorgulayabilirsiniz. Bunlar aslinda master’da ya da kullanici veritabanlarinda dogrudan yer almazlar. Sistem tablolarinin yerine geriye dönük destek amaçli görüntüler kullanilmistir. Asil temel tablolar Resource veritabanindadir.

Metadata erisimi ve görünürlük

SQL Server 2005’teki yeni metadata mimarisi sunlari saglar:
• Sistem metadatasina erismek için basit, tutarli, güvenli ve etkin bir yol.
• Sistem tablolarina dogrudan güncellemenin engellenmesi
• Olabilecek en iyi geriye dönük destek
• Metadataya erisimin izinler bazinda kisitlanmasi
Bunu saglamak için SQL Server 2005’de uygulanmis çesitli yöntemlerden bahsetmeye baslayalim:

Katalog görüntüleri
Eski sürümlerde yer alan tüm sistem tablolari bu sürümde geriye dönük destek amaçli görüntüler olarak sunulurlar ve kullanimlari tavsiye edilmez. Bunun yerine yeni bir kavram olarak katalog görüntüleri getirilmistir. Bu görüntüler sistem metadatasina erisim için tavsiye edilen yöntemdirler. SQL Server 2005’te 4 degisik çesit görüntü vardir: Katalog görüntüleri, geriye dönük destek görüntüleri, DMVler (dynamic management views, dinamik yönetim görüntüleri) ve information_schema görüntüleri. Katalog görüntülerini kullanmak en etkin ve tavsiye edilen metadata erisim seklidir ve Service Broker gibi yeni özelliklerle iliskin olarak zaten kullanilabilecek tek yöntemdir. Geriye dönük destek için saglanan görüntüler ve information_schema görüntüleri SQL Server 2005’le birlikte gelen yeni özellikler için gelistirilmemistir. Adi üstünde, sadece önceki sürümlerdeki kullanimi destekleyen ve gelecegi konusunda da süphe duymakta hakli olacaginiz olanaklardir bunlar.
Yaklasik 286 sistem metadata görüntüsü vardir ve bu sayi katalog görüntülerini, DMVleri, information_schema görüntülerini, geriye dönük destek görüntülerini içerir. Asagidaki sorguyla tüm sistem metadata görüntülerinin bir listesini alabilirsiniz:
SELECT * FROM sys.all_views
WHERE is_ms_shipped = 1
ORDER BY [name];
Tüm sistem metadata nesneleri sys veya INFORMATION_SCHEMA semalarina aittir. Katalog görüntülerinde isimlendirme standartlari vardir. sys.% görüntüleri bir kullanicinin metadatasini, sys.system_% görüntülerini sistem nesnelerini, sys.all_% nesneleri de sistem nesneleri ve kullanici nesnelerinin birlesimini verir. sys.server_% görüntüleri ise sunucu seviyesinde metadatayi tanimlar.
Örnek olarak su SQL ifadelerini düsünelim:
USE [AdventureWorks];
SELECT * FROM sysobjects ORDER BY [name];
-- Bu kullanim, eskiye benzemekle birlikte sysobjects bir sistem tablosu degil, geriye dönük destek görüntüsüdür.
SELECT * FROM dbo.sysobjects ORDER BY [name];
SELECT * FROM sys.sysobjects ORDER BY [name];
-- Bu geriye dönük görüntüyü dbo ya da sys semasi altindan kullanabiliriz.
SELECT * FROM sys.objects ORDER BY [name];
-- Bu sürümle gelen katalog görüntüsü kullanilmaktadir.
SELECT * FROM sys.all_objects ORDER BY [name];
SELECT * FROM sys.system_objects ORDER BY [name];
-- Bu iki sorguda da yine bu sürümle gelen yeni görüntüler kullanilmaktadir. Bunlarin sistem tablolari gerçekte Resource veritabanindadir, ama herhangi bir veritabanindan da bu görüntüler yoluyla Resource veritabanindaki metadata bilgilerine erisme imkani bulunmaktadir.
Katalog görüntülerinde daha temel olan tablolar az sayida kolon ama fazla sayida satir içerir. Daha özellesmis tablolarda ise daha az satir olmakla birlikte bunlarla ilgili daha fazla kolon yer alir. Mesela sys.objects tablosu sys.tables’a göre daha fazla satir döndürür. Ama bu satirlarla ilgili verilen bilgi sayisi (yani kolonlarin sayisi) azdir. Oysa sys.tables sadece tablolarla ilgili bilgi verdiginden daha az satir içerir ve her bir satirla ilgili bilgi sayisi çok daha fazladir.

Katalog güvenligi

SQL Server 2005 metadata güvenligi konusunda ANSI SQL-99 standartlarina göre bir çözüm getirmistir: Erisime sahip oldugunuz nesneler için metadataya da erisebilirsiniz, erisimine sahip olmadiginiz nesnelerin metadatalari da size bos küme olarak döner. Metadata erisiminin önüne bir güvenlik katmani eklenmistir ve tüm metadata sorgulari bu katmandan geçer. Böylelikle erisime sahip olmadiginiz bir nesne için metadata bilgilerine de erisemezsiniz.
Önceki sürümlere göre güvenlik adina büyük bir iyilestirme oldugunu söyleyebiliriz. Verinin kendisine olmasa bile, metadaya o veriyle ilgili yetkisi olmayan kisilerin erismesi, olasi güvenlik sorunlari açisindan sakincali bir durumdu.
sa hesabi tüm sistem metadatasina, dbo da tüm veritabani metadatasina erisebilir. Bazi bilgiler de tüm veritabani kullanicilari tarafindan hala erisilebilir durumdadir. Bunlar tipik olarak dosya gruplari gibi, haklarinda izin atamasi yapilamayan nesnelerle ilgili metadatalardir.

Allow updates seçenegi

Sistem tablolarina dogrudan güncelleme desteklenmedigi için, “allow updates” sistem ayar seçenegi SQL Server 2005’te anlamsizdir.

Kullanici/Sema ayrimi

SQL Server’in güvenlik ve yönetim açisindan 2005’teki en önemli degisikliklerinden biri de kullanici ve sema kavramlarinin birbirlerinden ayrilmasidir. ANSI SQL-92 standartlarina uygun sekilde, semanin amaci bir isim alani gibi davranarak iliskili veritabani nesnelerini bir arada tutmak ve isim çakismalarini önlemektir. Tüm satis nesnelerini, ya da tüm insan kaynaklari nesnelerini bu is için olusturulmus bir sema altina toplayabilirsiniz. Ya da eger iki tablonuzun isminin ayni olmasi gerekiyorsa, farkli semalar altinda olmak sartiyla bu kullanim size izin verir.
SQL Server’in önceki sürümlerinde kullanicilar isim alani olusturmak ve nesnelerde isim çakismasini önlemek amaciyla kullanilirdi. Bir nesneyi tam tanimlayarak isimlendirmede sunucu isminden sonra veritabani ismi ve kullanici ismi kullanilirdi. (myServer.Northwind.dbo.products gibi). Kullanicilarin böyle sema yerine degerlendirilmesi önemli yönetim sikintilarina sebep olabiliyordu.
Bir kullaniciyi silmek istediginizi düsünün. Bunu yapmadan önce o kullanicinin sahip oldugu tüm nesneleri ya silmeniz ya da sahipligini baska kullanicilara devretmeniz gerekirdi. Ilki pek tercih edilen bir çözüm degildir. Ikincisi ise genellikle, veritabanina erisen kimi uygulama kodlarinin degistirilmesini gerektirir ki, bazi durumlarda çok zaman ve kaynak kaybina yol açabilir. Bu sebeple de nesnelerin dbo altinda yaratilmasi tercih edilir ki, bu durumda da sema islevi ortadan kalkmis olur.
SQL Server 2005 için kullanicilar ve semalar birbirinden ayri iki seydir. Semalar kendileriyle ilgili güvenlik izinleri atanan nesnelerken, kullanicilar neye nasil erisilecegi izinlerle belirlenen varliklardir. Artik nesne isimleri sahip.nesne seklinde degil sema.nesne seklindedir. Sema olusturmak için CREATE SCHEMA diye yeni bir DDL ifadesi kullanilir ve semalarin sahipleri veritabani kullanicilaridir. Nesne olusturma iznine sahip kullanicilar semalarda nesneler olusturabilirler. Bir kullaniciyi silmek için artik tüm yapmaniz gereken, sahip oldugu semalarin sahipligini bir baska kullaniciya devretmektir. Yüzlerce nesne yerine sadece bir iki semanin sahipligini degistirmek isinizi çözecektir. Veritabanini kullanan uygulamalarda bir degisiklik yapmaya gerek olmaz, çünkü semanin kullanicisi degisse de sema ismi ayni kalacaktir. Nesne isimlendirirken, nesnenin kime ait oldugu, uygulamalar için önemli degildir.
Her kullanicinin isim çözümleme için kullanilan varsayilan bir semasi vardir. Yeni kullanici için varsayilan bir sema belirtmezseniz, SQL Server varsayilan sema olarak dbo’yu kullanir. Bu kullanicinin yaptigi bir sorguda eger nesne isminin tamamiyla belirtilmemisse, SQL Server nesneyi kullanicinin varsayilan semasinda arar. Eger burada bulamazsa, dbo semasina bakar.
Tüm bu yeni özelliklerle, SQL Server’in güvenlik alaninda da 2005’te önemli yenilikler getirdigini görüyoruz. Tabii güvenlikle ilgili gelen yeni özellikler sadece bunlar degil..