Archi
New member
- Katılım
- 22 Ocak 2006
- Mesajlar
- 15
- Reaction score
- 0
- Puanları
- 0
SQL Server 2005te sistem metadatasına erişim ve güvenlik mimarisi
Data bildiğiniz gibi, bir veritabanının tablolarında doğrudan tutulan bilgiye deniyor. Ya da veri Metadata ise, tabloların içindeki asıl bilgiler değil, bu bilgileri tutmayla ilgili bilgilerdir. Yani veri hakkındaki veriler. Birkaç örnek sayacak olursak: Bir veritabanındaki tablo ya da görüntülerin (view) sayıları, bir tablonun kolonları hakkında bilgiler, bir tablo için tanımlı kısıt ve indekslerle ilgili bilgiler, kullanıcılar ve girişlerle ilgili bilgiler gibi konular hep metadataya girer.
SQL Server 2000, SQL-92 standartlarına uygun olarak metadaya erişim için INFORMATION_SCHEMA görüntüleri, sunucu ve veritabanı seviyesinde sistem tabloları ve sistem yüklü yordamları ile pek çok olanak sunuyordu. Ama birtakım sorunlar da vardı:
Her ne kadar tavsiye edilmese de, SQL Server 2000 sistem nesnelerinde doğrudan değişiklik yapılmasına izin veriyordu.
Bir kullanıcı, bir nesneye erişim izinleri olmadığı halde o nesne ile ilgili metadataya yukarıda bahsedilen yöntemlerle erişebiliyordu.
Sistem tablolarındaki karmaşık gösterimleri sökmek için veritabanı yöneticilerinin ve geliştiricilerinin hayli çaba sarf etmesi gerektiği durumlar oluyordu.
Son olarak, yükseltmeler ve servis paketleri sistem nesnelerinin yok edilip tekrar oluşturulmasını gerektiriyordu. Bu hem fazla zaman alan bir yöntemdi, hem de bir servis paketini geri almayı imkansızlaştırmasa da çok zorlaştırıyordu.
SQL Server 2005te metadata erişimi baştan düşünülmüş ve güvenlik unsurları da göz önünde bulundurularak tamamen yeniden tasarlanmıştır. Resource adlı yeni bir veritabanının kullanılması, sistem metadatasına erişimle ilgili kısıtlamalar ve şemalar bu yeni tasarımın önemli unsurları olarak karşımıza çıkar.
Resource veritabanı
Resource, bu sürümle kullanılmaya başlayan yeni bir veritabanıdır. SQL Server 2005e dahil tüm sistem nesnelerini içerir, gizlidir ve sadece okunabilirdir. Bu bilgiler eskiden Master veritabanında yer alırdı. Resource veritabanında yer alan sistem nesneleri, fiziksel olarak burada yer almakla birlikte tüm veritabanlarında da mantıksal olarak var görünürler. Bu sistem nesnelerine veritabanlarında sys adlı şemada erişebiliriz. Resource veritabanı grafiksel yönetim araçlarında ya da sys.databases katalog görüntüsüne eriştiğinizde gözükmez. Fiziksel veritabanı dosyaları ise (mssqlsystemresource.mdf ve mssqlsystemresource.ldf) master veritabanı dosyalarının yer aldığı klasörde yer alırlar. Resource veritabanı dosyasının yerini ya da ismini değiştirirseniz, SQL Server başlamaz. Ayrıca performans kayıplarının oluşmaması ve sürüm güncellemelerde olası sorunlar yaşamamak için, Resource veritabanını NTFS dosya sisteminde sıkıştırılmış ya da şifrelenmiş klasörlere koymayın.
Dikkat edilmesi gereken bir nokta, Resource veritabanının herhangi bir kullanıcı verisi ya da kullanıcı metadatası içermemesidir. Bir SQL Server kurulumuna ilişkin sistem seviyesindeki bilgiler yine Master veritabanında tutulur. Bu sebeple, (doğrudan Resource veritabanına yönelik Microsoftun yönlendirdiği özel bir çalışma yapılmadıkça) Resource veritabanını yedeklemek gerekli değildir.
Resource veritabanı SQL Serverın yeni bir sürümüne terfi etmeyi çok daha hızlı ve kolay yapabilmeyi mümkün kılar. Önceki sürümlerde terfi, sistem nesnelerini yok etmeyi ve yeniden oluşturmayı gerektirirdi. Resource veritabanı tüm sistem nesnelerini içerdiğinden, bir terfi sadece Resource veritabanının yeni bir sürümünü yerel sürücüye kopyalamakla mümkündür. Bu aynı zamanda, bir yükseltmeyi geri almak için tüm yapılması gerekenin yeni Resource veritabanını istenen sürümdeki Resource veritabanı ile geri değiştirmek olmasını getirir.
Resource veritabanının sürümünü ve en son ne zaman güncellendiği bilgisini almak için şu sorguları kullanabilirsiniz:
SELECT SERVERPROPERTY(ResourceVersion);
SELECT SERVERPROPERTY(ResourceLastUpdateTime);
Bu sorgular benim sistemimde, 9.00.1399 ve Null değerlerini veriyor.
Resource veritabanına erişmenin tek yolu, SQL Serverı m başlangıç parametresini kullanarak tek-kullanıcı admin modunda başlatmak ve sonra da USE mssqlsystemresource SQL ifadesini kullanmaktır. Bunu yaptıktan sonra, master veritabanındaki ve herhangi bir kullanıcı veritabanındaki temel sistem tablolarını doğrudan sorgulayabilirsiniz. Bunlar aslında masterda ya da kullanıcı veritabanlarında doğrudan yer almazlar. Sistem tablolarının yerine geriye dönük destek amaçlı görüntüler kullanılmıştır. Asıl temel tablolar Resource veritabanındadır.
Metadata erişimi ve görünürlük
SQL Server 2005teki yeni metadata mimarisi şunları sağlar:
Sistem metadatasına erişmek için basit, tutarlı, güvenli ve etkin bir yol.
Sistem tablolarına doğrudan güncellemenin engellenmesi
Olabilecek en iyi geriye dönük destek
Metadataya erişimin izinler bazında kısıtlanması
Bunu sağlamak için SQL Server 2005de uygulanmış çeşitli yöntemlerden bahsetmeye başlayalım:
Katalog görüntüleri
Eski sürümlerde yer alan tüm sistem tabloları bu sürümde geriye dönük destek amaçlı görüntüler olarak sunulurlar ve kullanımları tavsiye edilmez. Bunun yerine yeni bir kavram olarak katalog görüntüleri getirilmiştir. Bu görüntüler sistem metadatasına erişim için tavsiye edilen yöntemdirler. SQL Server 2005te 4 değişik çeşit görüntü vardır: 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 erişim şeklidir ve Service Broker gibi yeni özelliklerle ilişkin olarak zaten kullanılabilecek tek yöntemdir. Geriye dönük destek için sağlanan görüntüler ve information_schema görüntüleri SQL Server 2005le birlikte gelen yeni özellikler için geliştirilmemiştir. Adı üstünde, sadece önceki sürümlerdeki kullanımı destekleyen ve geleceği konusunda da şüphe duymakta haklı olacağınız olanaklardır bunlar.
Yaklaşık 286 sistem metadata görüntüsü vardır ve bu sayı katalog görüntülerini, DMVleri, information_schema görüntülerini, geriye dönük destek görüntülerini içerir. Aşağıdaki 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 şemalarına aittir. Katalog görüntülerinde isimlendirme standartları vardır. sys.% görüntüleri bir kullanıcının metadatasını, sys.system_% görüntülerini sistem nesnelerini, sys.all_% nesneleri de sistem nesneleri ve kullanıcı nesnelerinin birleşimini verir. sys.server_% görüntüleri ise sunucu seviyesinde metadatayı tanımlar.
Örnek olarak şu SQL ifadelerini düşünelim:
USE [AdventureWorks];
SELECT * FROM sysobjects ORDER BY [name];
-- Bu kullanım, eskiye benzemekle birlikte sysobjects bir sistem tablosu değil, 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 şeması altından kullanabiliriz.
SELECT * FROM sys.objects ORDER BY [name];
-- Bu sürümle gelen katalog görüntüsü kullanılmaktadır.
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 kullanılmaktadır. Bunların sistem tabloları gerçekte Resource veritabanındadır, ama herhangi bir veritabanından da bu görüntüler yoluyla Resource veritabanındaki metadata bilgilerine erişme imkanı bulunmaktadır.
Katalog görüntülerinde daha temel olan tablolar az sayıda kolon ama fazla sayıda satır içerir. Daha özelleşmiş tablolarda ise daha az satır olmakla birlikte bunlarla ilgili daha fazla kolon yer alır. Mesela sys.objects tablosu sys.tablesa göre daha fazla satır döndürür. Ama bu satırlarla ilgili verilen bilgi sayısı (yani kolonların sayısı) azdır. Oysa sys.tables sadece tablolarla ilgili bilgi verdiğinden daha az satır içerir ve her bir satırla ilgili bilgi sayısı çok daha fazladır.
Katalog güvenliği
SQL Server 2005 metadata güvenliği konusunda ANSI SQL-99 standartlarına göre bir çözüm getirmiştir: Erişime sahip olduğunuz nesneler için metadataya da erişebilirsiniz, erişimine sahip olmadığınız nesnelerin metadataları da size boş küme olarak döner. Metadata erişiminin önüne bir güvenlik katmanı eklenmiştir ve tüm metadata sorguları bu katmandan geçer. Böylelikle erişime sahip olmadığınız bir nesne için metadata bilgilerine de erişemezsiniz.
Önceki sürümlere göre güvenlik adına büyük bir iyileştirme olduğunu söyleyebiliriz. Verinin kendisine olmasa bile, metadaya o veriyle ilgili yetkisi olmayan kişilerin erişmesi, olası güvenlik sorunları açısından sakıncalı bir durumdu.
sa hesabı tüm sistem metadatasına, dbo da tüm veritabanı metadatasına erişebilir. Bazı bilgiler de tüm veritabanı kullanıcıları tarafından hala erişilebilir durumdadır. Bunlar tipik olarak dosya grupları gibi, haklarında izin ataması yapılamayan nesnelerle ilgili metadatalardır.
Allow updates seçeneği
Sistem tablolarına doğrudan güncelleme desteklenmediği için, allow updates sistem ayar seçeneği SQL Server 2005te anlamsızdır.
Kullanıcı/Şema ayrımı
SQL Serverın güvenlik ve yönetim açısından 2005teki en önemli değişikliklerinden biri de kullanıcı ve şema kavramlarının birbirlerinden ayrılmasıdır. ANSI SQL-92 standartlarına uygun şekilde, şemanın amacı bir isim alanı gibi davranarak ilişkili veritabanı nesnelerini bir arada tutmak ve isim çakışmalarını önlemektir. Tüm satış nesnelerini, ya da tüm insan kaynakları nesnelerini bu iş için oluşturulmuş bir şema altına toplayabilirsiniz. Ya da eğer iki tablonuzun isminin aynı olması gerekiyorsa, farklı şemalar altında olmak şartıyla bu kullanım size izin verir.
SQL Serverın önceki sürümlerinde kullanıcılar isim alanı oluşturmak ve nesnelerde isim çakışmasını önlemek amacıyla kullanılırdı. Bir nesneyi tam tanımlayarak isimlendirmede sunucu isminden sonra veritabanı ismi ve kullanıcı ismi kullanılırdı. (myServer.Northwind.dbo.products gibi). Kullanıcıların böyle şema yerine değerlendirilmesi önemli yönetim sıkıntılarına sebep olabiliyordu.
Bir kullanıcıyı silmek istediğinizi düşünün. Bunu yapmadan önce o kullanıcının sahip olduğu tüm nesneleri ya silmeniz ya da sahipliğini başka kullanıcılara devretmeniz gerekirdi. İlki pek tercih edilen bir çözüm değildir. İkincisi ise genellikle, veritabanına erişen kimi uygulama kodlarının değiştirilmesini gerektirir ki, bazı durumlarda çok zaman ve kaynak kaybına yol açabilir. Bu sebeple de nesnelerin dbo altında yaratılması tercih edilir ki, bu durumda da şema işlevi ortadan kalkmış olur.
SQL Server 2005 için kullanıcılar ve şemalar birbirinden ayrı iki şeydir. Şemalar kendileriyle ilgili güvenlik izinleri atanan nesnelerken, kullanıcılar neye nasıl erişileceği izinlerle belirlenen varlıklardır. Artık nesne isimleri sahip.nesne şeklinde değil şema.nesne şeklindedir. Şema oluşturmak için CREATE SCHEMA diye yeni bir DDL ifadesi kullanılır ve şemaların sahipleri veritabanı kullanıcılarıdır. Nesne oluşturma iznine sahip kullanıcılar şemalarda nesneler oluşturabilirler. Bir kullanıcıyı silmek için artık tüm yapmanız gereken, sahip olduğu şemaların sahipliğini bir başka kullanıcıya devretmektir. Yüzlerce nesne yerine sadece bir iki şemanın sahipliğini değiştirmek işinizi çözecektir. Veritabanını kullanan uygulamalarda bir değişiklik yapmaya gerek olmaz, çünkü şemanın kullanıcısı değişse de şema ismi aynı kalacaktır. Nesne isimlendirirken, nesnenin kime ait olduğu, uygulamalar için önemli değildir.
Her kullanıcının isim çözümleme için kullanılan varsayılan bir şeması vardır. Yeni kullanıcı için varsayılan bir şema belirtmezseniz, SQL Server varsayılan şema olarak dboyu kullanır. Bu kullanıcının yaptığı bir sorguda eğer nesne isminin tamamıyla belirtilmemişse, SQL Server nesneyi kullanıcının varsayılan şemasında arar. Eğer burada bulamazsa, dbo şemasına bakar.
Tüm bu yeni özelliklerle, SQL Serverın güvenlik alanında da 2005te önemli yenilikler getirdiğini görüyoruz. Tabii güvenlikle ilgili gelen yeni özellikler sadece bunlar değil...
Data bildiğiniz gibi, bir veritabanının tablolarında doğrudan tutulan bilgiye deniyor. Ya da veri Metadata ise, tabloların içindeki asıl bilgiler değil, bu bilgileri tutmayla ilgili bilgilerdir. Yani veri hakkındaki veriler. Birkaç örnek sayacak olursak: Bir veritabanındaki tablo ya da görüntülerin (view) sayıları, bir tablonun kolonları hakkında bilgiler, bir tablo için tanımlı kısıt ve indekslerle ilgili bilgiler, kullanıcılar ve girişlerle ilgili bilgiler gibi konular hep metadataya girer.
SQL Server 2000, SQL-92 standartlarına uygun olarak metadaya erişim için INFORMATION_SCHEMA görüntüleri, sunucu ve veritabanı seviyesinde sistem tabloları ve sistem yüklü yordamları ile pek çok olanak sunuyordu. Ama birtakım sorunlar da vardı:
Her ne kadar tavsiye edilmese de, SQL Server 2000 sistem nesnelerinde doğrudan değişiklik yapılmasına izin veriyordu.
Bir kullanıcı, bir nesneye erişim izinleri olmadığı halde o nesne ile ilgili metadataya yukarıda bahsedilen yöntemlerle erişebiliyordu.
Sistem tablolarındaki karmaşık gösterimleri sökmek için veritabanı yöneticilerinin ve geliştiricilerinin hayli çaba sarf etmesi gerektiği durumlar oluyordu.
Son olarak, yükseltmeler ve servis paketleri sistem nesnelerinin yok edilip tekrar oluşturulmasını gerektiriyordu. Bu hem fazla zaman alan bir yöntemdi, hem de bir servis paketini geri almayı imkansızlaştırmasa da çok zorlaştırıyordu.
SQL Server 2005te metadata erişimi baştan düşünülmüş ve güvenlik unsurları da göz önünde bulundurularak tamamen yeniden tasarlanmıştır. Resource adlı yeni bir veritabanının kullanılması, sistem metadatasına erişimle ilgili kısıtlamalar ve şemalar bu yeni tasarımın önemli unsurları olarak karşımıza çıkar.
Resource veritabanı
Resource, bu sürümle kullanılmaya başlayan yeni bir veritabanıdır. SQL Server 2005e dahil tüm sistem nesnelerini içerir, gizlidir ve sadece okunabilirdir. Bu bilgiler eskiden Master veritabanında yer alırdı. Resource veritabanında yer alan sistem nesneleri, fiziksel olarak burada yer almakla birlikte tüm veritabanlarında da mantıksal olarak var görünürler. Bu sistem nesnelerine veritabanlarında sys adlı şemada erişebiliriz. Resource veritabanı grafiksel yönetim araçlarında ya da sys.databases katalog görüntüsüne eriştiğinizde gözükmez. Fiziksel veritabanı dosyaları ise (mssqlsystemresource.mdf ve mssqlsystemresource.ldf) master veritabanı dosyalarının yer aldığı klasörde yer alırlar. Resource veritabanı dosyasının yerini ya da ismini değiştirirseniz, SQL Server başlamaz. Ayrıca performans kayıplarının oluşmaması ve sürüm güncellemelerde olası sorunlar yaşamamak için, Resource veritabanını NTFS dosya sisteminde sıkıştırılmış ya da şifrelenmiş klasörlere koymayın.
Dikkat edilmesi gereken bir nokta, Resource veritabanının herhangi bir kullanıcı verisi ya da kullanıcı metadatası içermemesidir. Bir SQL Server kurulumuna ilişkin sistem seviyesindeki bilgiler yine Master veritabanında tutulur. Bu sebeple, (doğrudan Resource veritabanına yönelik Microsoftun yönlendirdiği özel bir çalışma yapılmadıkça) Resource veritabanını yedeklemek gerekli değildir.
Resource veritabanı SQL Serverın yeni bir sürümüne terfi etmeyi çok daha hızlı ve kolay yapabilmeyi mümkün kılar. Önceki sürümlerde terfi, sistem nesnelerini yok etmeyi ve yeniden oluşturmayı gerektirirdi. Resource veritabanı tüm sistem nesnelerini içerdiğinden, bir terfi sadece Resource veritabanının yeni bir sürümünü yerel sürücüye kopyalamakla mümkündür. Bu aynı zamanda, bir yükseltmeyi geri almak için tüm yapılması gerekenin yeni Resource veritabanını istenen sürümdeki Resource veritabanı ile geri değiştirmek olmasını getirir.
Resource veritabanının sürümünü ve en son ne zaman güncellendiği bilgisini almak için şu sorguları kullanabilirsiniz:
SELECT SERVERPROPERTY(ResourceVersion);
SELECT SERVERPROPERTY(ResourceLastUpdateTime);
Bu sorgular benim sistemimde, 9.00.1399 ve Null değerlerini veriyor.
Resource veritabanına erişmenin tek yolu, SQL Serverı m başlangıç parametresini kullanarak tek-kullanıcı admin modunda başlatmak ve sonra da USE mssqlsystemresource SQL ifadesini kullanmaktır. Bunu yaptıktan sonra, master veritabanındaki ve herhangi bir kullanıcı veritabanındaki temel sistem tablolarını doğrudan sorgulayabilirsiniz. Bunlar aslında masterda ya da kullanıcı veritabanlarında doğrudan yer almazlar. Sistem tablolarının yerine geriye dönük destek amaçlı görüntüler kullanılmıştır. Asıl temel tablolar Resource veritabanındadır.
Metadata erişimi ve görünürlük
SQL Server 2005teki yeni metadata mimarisi şunları sağlar:
Sistem metadatasına erişmek için basit, tutarlı, güvenli ve etkin bir yol.
Sistem tablolarına doğrudan güncellemenin engellenmesi
Olabilecek en iyi geriye dönük destek
Metadataya erişimin izinler bazında kısıtlanması
Bunu sağlamak için SQL Server 2005de uygulanmış çeşitli yöntemlerden bahsetmeye başlayalım:
Katalog görüntüleri
Eski sürümlerde yer alan tüm sistem tabloları bu sürümde geriye dönük destek amaçlı görüntüler olarak sunulurlar ve kullanımları tavsiye edilmez. Bunun yerine yeni bir kavram olarak katalog görüntüleri getirilmiştir. Bu görüntüler sistem metadatasına erişim için tavsiye edilen yöntemdirler. SQL Server 2005te 4 değişik çeşit görüntü vardır: 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 erişim şeklidir ve Service Broker gibi yeni özelliklerle ilişkin olarak zaten kullanılabilecek tek yöntemdir. Geriye dönük destek için sağlanan görüntüler ve information_schema görüntüleri SQL Server 2005le birlikte gelen yeni özellikler için geliştirilmemiştir. Adı üstünde, sadece önceki sürümlerdeki kullanımı destekleyen ve geleceği konusunda da şüphe duymakta haklı olacağınız olanaklardır bunlar.
Yaklaşık 286 sistem metadata görüntüsü vardır ve bu sayı katalog görüntülerini, DMVleri, information_schema görüntülerini, geriye dönük destek görüntülerini içerir. Aşağıdaki 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 şemalarına aittir. Katalog görüntülerinde isimlendirme standartları vardır. sys.% görüntüleri bir kullanıcının metadatasını, sys.system_% görüntülerini sistem nesnelerini, sys.all_% nesneleri de sistem nesneleri ve kullanıcı nesnelerinin birleşimini verir. sys.server_% görüntüleri ise sunucu seviyesinde metadatayı tanımlar.
Örnek olarak şu SQL ifadelerini düşünelim:
USE [AdventureWorks];
SELECT * FROM sysobjects ORDER BY [name];
-- Bu kullanım, eskiye benzemekle birlikte sysobjects bir sistem tablosu değil, 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 şeması altından kullanabiliriz.
SELECT * FROM sys.objects ORDER BY [name];
-- Bu sürümle gelen katalog görüntüsü kullanılmaktadır.
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 kullanılmaktadır. Bunların sistem tabloları gerçekte Resource veritabanındadır, ama herhangi bir veritabanından da bu görüntüler yoluyla Resource veritabanındaki metadata bilgilerine erişme imkanı bulunmaktadır.
Katalog görüntülerinde daha temel olan tablolar az sayıda kolon ama fazla sayıda satır içerir. Daha özelleşmiş tablolarda ise daha az satır olmakla birlikte bunlarla ilgili daha fazla kolon yer alır. Mesela sys.objects tablosu sys.tablesa göre daha fazla satır döndürür. Ama bu satırlarla ilgili verilen bilgi sayısı (yani kolonların sayısı) azdır. Oysa sys.tables sadece tablolarla ilgili bilgi verdiğinden daha az satır içerir ve her bir satırla ilgili bilgi sayısı çok daha fazladır.
Katalog güvenliği
SQL Server 2005 metadata güvenliği konusunda ANSI SQL-99 standartlarına göre bir çözüm getirmiştir: Erişime sahip olduğunuz nesneler için metadataya da erişebilirsiniz, erişimine sahip olmadığınız nesnelerin metadataları da size boş küme olarak döner. Metadata erişiminin önüne bir güvenlik katmanı eklenmiştir ve tüm metadata sorguları bu katmandan geçer. Böylelikle erişime sahip olmadığınız bir nesne için metadata bilgilerine de erişemezsiniz.
Önceki sürümlere göre güvenlik adına büyük bir iyileştirme olduğunu söyleyebiliriz. Verinin kendisine olmasa bile, metadaya o veriyle ilgili yetkisi olmayan kişilerin erişmesi, olası güvenlik sorunları açısından sakıncalı bir durumdu.
sa hesabı tüm sistem metadatasına, dbo da tüm veritabanı metadatasına erişebilir. Bazı bilgiler de tüm veritabanı kullanıcıları tarafından hala erişilebilir durumdadır. Bunlar tipik olarak dosya grupları gibi, haklarında izin ataması yapılamayan nesnelerle ilgili metadatalardır.
Allow updates seçeneği
Sistem tablolarına doğrudan güncelleme desteklenmediği için, allow updates sistem ayar seçeneği SQL Server 2005te anlamsızdır.
Kullanıcı/Şema ayrımı
SQL Serverın güvenlik ve yönetim açısından 2005teki en önemli değişikliklerinden biri de kullanıcı ve şema kavramlarının birbirlerinden ayrılmasıdır. ANSI SQL-92 standartlarına uygun şekilde, şemanın amacı bir isim alanı gibi davranarak ilişkili veritabanı nesnelerini bir arada tutmak ve isim çakışmalarını önlemektir. Tüm satış nesnelerini, ya da tüm insan kaynakları nesnelerini bu iş için oluşturulmuş bir şema altına toplayabilirsiniz. Ya da eğer iki tablonuzun isminin aynı olması gerekiyorsa, farklı şemalar altında olmak şartıyla bu kullanım size izin verir.
SQL Serverın önceki sürümlerinde kullanıcılar isim alanı oluşturmak ve nesnelerde isim çakışmasını önlemek amacıyla kullanılırdı. Bir nesneyi tam tanımlayarak isimlendirmede sunucu isminden sonra veritabanı ismi ve kullanıcı ismi kullanılırdı. (myServer.Northwind.dbo.products gibi). Kullanıcıların böyle şema yerine değerlendirilmesi önemli yönetim sıkıntılarına sebep olabiliyordu.
Bir kullanıcıyı silmek istediğinizi düşünün. Bunu yapmadan önce o kullanıcının sahip olduğu tüm nesneleri ya silmeniz ya da sahipliğini başka kullanıcılara devretmeniz gerekirdi. İlki pek tercih edilen bir çözüm değildir. İkincisi ise genellikle, veritabanına erişen kimi uygulama kodlarının değiştirilmesini gerektirir ki, bazı durumlarda çok zaman ve kaynak kaybına yol açabilir. Bu sebeple de nesnelerin dbo altında yaratılması tercih edilir ki, bu durumda da şema işlevi ortadan kalkmış olur.
SQL Server 2005 için kullanıcılar ve şemalar birbirinden ayrı iki şeydir. Şemalar kendileriyle ilgili güvenlik izinleri atanan nesnelerken, kullanıcılar neye nasıl erişileceği izinlerle belirlenen varlıklardır. Artık nesne isimleri sahip.nesne şeklinde değil şema.nesne şeklindedir. Şema oluşturmak için CREATE SCHEMA diye yeni bir DDL ifadesi kullanılır ve şemaların sahipleri veritabanı kullanıcılarıdır. Nesne oluşturma iznine sahip kullanıcılar şemalarda nesneler oluşturabilirler. Bir kullanıcıyı silmek için artık tüm yapmanız gereken, sahip olduğu şemaların sahipliğini bir başka kullanıcıya devretmektir. Yüzlerce nesne yerine sadece bir iki şemanın sahipliğini değiştirmek işinizi çözecektir. Veritabanını kullanan uygulamalarda bir değişiklik yapmaya gerek olmaz, çünkü şemanın kullanıcısı değişse de şema ismi aynı kalacaktır. Nesne isimlendirirken, nesnenin kime ait olduğu, uygulamalar için önemli değildir.
Her kullanıcının isim çözümleme için kullanılan varsayılan bir şeması vardır. Yeni kullanıcı için varsayılan bir şema belirtmezseniz, SQL Server varsayılan şema olarak dboyu kullanır. Bu kullanıcının yaptığı bir sorguda eğer nesne isminin tamamıyla belirtilmemişse, SQL Server nesneyi kullanıcının varsayılan şemasında arar. Eğer burada bulamazsa, dbo şemasına bakar.
Tüm bu yeni özelliklerle, SQL Serverın güvenlik alanında da 2005te önemli yenilikler getirdiğini görüyoruz. Tabii güvenlikle ilgili gelen yeni özellikler sadece bunlar değil...
