SQL Server Güvenlik Kavramı

Sql Server güvenlik konusu son zamanlardaki hızla artan hacking olaylarından sonra iyice
önem kazanmıştır. Sql Server Windows işletim sistemleri üzerinde bir servis olarak
çalışmaktadır. Kullanıcılar yetkileri ve onlara atanmış olan haklar çerçevesinde SQL Server
üzerinde sunulan veritabanı ve diğer yönetim başlıklarında değişiklik yapabilirler. Bu
sebepten ötürü SQL Server güvenlik konusu ele alındığında sadece sunucu komponentlerinin
güncel olması yeterli olmaz buna ek olarak kullanıcı hareketlerinin denetlenmesi ve yeterli
miktarda saklanması da önemlidir. Bu başlık altında tabi ki SQL Server’ın tüm hizmetleri
sunmak üzere kurulu olduğu Windows sunucularına ait alt katman güvenliğinin de sağlanmış
olması gerekir.
İşletmelerde genellikle, Sql Server ile ilgili tüm konular yazılım bölümüne veya yazılımcıya
atanmıştır. Bölümler arası çekişmeler veya senin görevin / benim görevim, sen yaptın / ben
yaptım gibi anlaşmazlıklardan dolayı Sql Server’da ortaya çıkan sorunlar sahipsiz kalmakta,
sistem bilgisi olmayan yazılımcıların bildiği kadar tedbirler alınmaktadır. Sql Server yazılımı
bağımsız bir platformdur, herhangi bir yazılım dilinde yazılan bir program Sql Server’a veri
aktarabilir ve okuyabilir. Bu sebeple yazılım ile veriyi birbirinden güvenlik platform tasarımı
bakışı açısından ayırmak gerekir.
Bir yazılımın silinmesi/bozulması mı yoksa tüm veritabanınızın silinmesi mi işinizi
aksatacaktır? Kullandığınız bir paket programı, satın aldığınız yazılım firmasından tekrar
isteyip yükleyebilirsiniz. Kendi geliştirdiğiniz bir yazılımın kaynak kodları sizde olduğu için
tekrardan derleyip programı devreye alabilirsiniz. Fakat veritabanınızdaki veriler ve yedekler
çalındığı / hacklendiği zaman bunları geri getiremezsiniz. Sistem ve veritabanı yedekleri her
ne kadar bu tip durumlarda faydalı olsa da, bir saldırganın uzun süreli sunucunuza erişim
sağladığı ve yedeklenme işlemine verileni de bozduğu senaryoları da düşünün. Hiçbir
saldırgan sizin yazdığınız bir programın peşinde değildir, bu programın kaydettiği verilerin
peşindedir, ancak bu şekilde zarar verebilir ve kendisine kar sağlayabilir.
Bu makalede, Sql Server için alınabilecek güvenlik tedbirlerini, Sql Server’ın kurulu olduğu
sunucu ve sistemlerde ne gibi önlemler alınmalı gibi konuları anlatmaya çalışacağım.
Güvenlik konusu, sistem veya network konuları gibi kesin kuralları içermez, güvenlik
ürünlerden çok süreçlere bağımlı bir olgudur. Güvenlik için birikim, bilgi ve tecrübe çok
önemlidir. Bu makalede veya başka makale ve kitaplarda anlatılan Sql Server güvenliği
konuları ile, yüzde 100 güvenli olacağınızın garantisi verilmez. Güvenlik, içerisinde birden
çok rol içeren, ana unsurların düzgün ve kararlı çalışmasını sağlayan bir süreçtir. Bu süreç ne
kadar düzgün yönetilir ise, o kadar yeterli seviyede güvenli sistemler olacaktır. Bilgi
teknolojileri dünyasında güvenlik bir teknoloji değildir, teknolojilerin ortaya çıkardığı
zafiyetleri kapsayan genel bir konudur.
İlk olarak Sunucu ve Network güvenliğinde bahsedelim.
Sql Server Servis Hesabının Seçilmesi:
 
Sql Server bir Windows servisi olarak çalışır. Her Windows servisini çalıştıran bir kullanıcı
hesabı vardır. Sql Server içinde bu hesabı doğru seçmek güvenlik için önemlidir. Sql Server
kurulumunda, Sql Server’ı çalıştıracak hesabı değiştirmediyseniz, Sql Server Configuration
Manager’dan bu değişikliği yapabilirsiniz.
Sql Server’ı çalıştıran hesabı görüntülemek için Sql Server – Configuration Tools – SQL
Server Configuration Manager’ı açıyoruz
SSS-1
Sql Server Services – Sql Server (instance adınız) – Properties diyerek özellikler sayfasını
açıyoruz.

SSS-2
Logon ekranında Sql Server’ı çalıştıran hesabımızı görüyoruz. Nt Service olarak gözüküyor.
SSS-3
Sql Server, kurulu olduğu Windows Server üzerinde yönetici haklarına sahip olmayı
gerektirmez. Sadece veri tabanlarının, yedeklerin ve logların tutulduğu dizinlerde okuma-
yazma yetkisini arar.
Built-in account: Built-in hesapların şifreleri olmaz. İşletim sistemi tarafından yönetilen
hesaplardır. Local System hesabı, yönetici haklarına sahip yerel bir hesaptır. Active directory
üzerinden bu hesap ile network kaynalarına erişelebilinmektedir.
Network service, bu hesabın lokal makinada yetkileri biraz daha kısıtlıdır. Local system
hesabı gibi network kaynaklarına erişebilmektedir.
Local system ve Network Service dışında, bir domain hesabı da seçebilirsiniz. Fakat bu
hesaba password policy uygulanmaması gerekmektedir. Şifrenin süresi dolduğunda hesap
bloklanır ve Sql Server hizmeti çalışmaz hale gelir. Bir Built-in hesabı ile Sql Server’ı
çalıştırmak yerine, domain hesabı seçmek daha iyidir. Domain bir hesaba bu yetki verildikten
sonra, Local Sercurity Policy üzeriden de Log on as a service yetkisinin verilmesi
gerekmektedir. Built-in hesaplar servisler ile paylaşılan hesaplardır, bu sebeple saldırganlar
tarafından uzak komut istem ile Sql Server prosedürleri veya diğer servislerine müdahale
edebilirler.
Technet: http://technet.microsoft.com/en-us/library/cc756898(v=ws.10).aspx
 
Sql Servislerinin Güvenlik ID’lerinin Kontrol Edilmesi ve Yönetilmesi:
 
Sql Server’ı çalıştıran servis, güvenlik olarak bir Windows hesabına bağlıdır. Bu Windows
hesabına bağlı birden çok servis vardır. Bu hesapların diğer kaynaklara (dosyalar, klasörler
v.b.) erişiminde çakışma çıkmaması için, Windows her bir service Security Identifier dediği
Security ID numarası atar. Bu SID dediğimiz ID’ler Sql Server kurulumunda oluşturulur.
Sql Server servisinize SID’in atanıp atanmadığını öğrenmek için, komut satırını açın.
Aşağıdaki kodu komut satırınıza yazın.
“sc qsidtype mssqlserver”
Not: Buradaki mssqlserver, sizin sisteminizdeki Sql Server’ın instance adıdır.
Technet: http://blogs.technet.com/b/askperf/archive/2008/02/03/ws2008-windows-service-
hardening.aspx
SSS-4
En üst satırda Success olarak komut çalıştı. Service_name kısmında Sql Server’ın çalıştığı
servis adı geldi. Service_SID_type kısmında ise Unrestricted olarak SID tipimizin olduğun
gösteriyor. Unrestricted, servisimizin bir SID değerini aldığını belirtir. SID_type None
olsaydı, Sql Servisinin SID değeri olmadığını, SID_type – Restricted olursa, servisin bir SID
değeri olduğunu fakat sınırlı bir hakka sahip olduğunu belirtecekti.
Eğer SID değeri None olarak çıkar ise, yukarıdaki komutun yanına Unrestricted yazarak,
komutu tekrar çalıştırın. Böylelikle Sql Server servisinize bir Security ID değeri atamış
olursunuz.
SID değer olan bir Sql Server, çalıştığı makine üzerinde ekstra yetkilere sahip olur, yedekleri
diske yazma, import etme gibi. Sql server’da genel olarak yapılan export ve import işlerinde
başarılsızlık olur ise SID değerini kontrol etmekte fayda vardır.
SID değeri None olarak kalabilir, fakat Restricted olarak kalırsa Sql Server’ın erişmek istediği
kaynakları bloklar ve Sql Server hizmeti başlamaz.
 
Sql Servislerinde Virtual Service Hesabı Kullanılması:
 
Virtual service hesabı ilk olarak Server 2008 R2 ile duyuruldu. Şifre gerektirmeyen yerel bir
hesaptır. Network Service hesabı gibi çalışır. Network servisinden farklı en iyi özelliği her
service için farklı bir hesap ile çalışmasıdır. Virtual bir servisi oluşturamaz ve silemezsiniz.
 
Şekil SSS-3 te olduğu gibi, Log on ekranında “This Account”u seçip NT Service\(instace
adınız) yazıyorsunuz ve şfireyi boş bırakarak, Sql Server service’ini yeniden başlatarak bu
hesap ile çalıştırmaya başlayabilirsiniz. Şifre alanları boş olarak geçilmektedir.
Technet: http://technet.microsoft.com/en-us/library/dd548356(v=ws.10).aspx
 
Sql Bağlantılarının SSL ile Şifrelenmesi:
 
Sql Server bilindiği üzere server to client – client to server bir yapıdadır. Doğal olarak
network üzerinden haberleşerek veri girişleri ve veri sorgulamaları yapılır. Sql server ile
clientlar arasındaki haberleşme network üzerinde, sniffer dediğimiz araçlar ile izlenmesi gayet
kolaydır. Bir saldırganın bir sistemdeki Sql Serverları ve bu servera bağlı clientları tespit
etmesi oldukça kolaydır.
Microsoft Network Analyzer’ın yerini alan Message Analyzer ile Sql Server’ın ağ trafiğini
izlemeye başlayalım. İlk önce aşağıdaki linkten programı indiriyoruz. (İsterseniz Wireshark
programı ile de aynı işlemleri yapabilirsiniz)
https://www.microsoft.com/en-us/download/details.aspx?id=44226
Basit bir kurulumu var. Kurulumdan sonra Quick Trace kısmında ağ bağlantımıza tıklayarak
network trace’i başlatıyoruz.
SSS-5
Trace başladıktan sonra ikinci makinamdan Adventerworks2012  veri tabanındaki
PurchaseOrderDetail tablosuna select sorgusu atıyorum.

SSS-6
Bu sorgudan sonra Message Analyzer’a gelip bakalım.

SSS-7
Çok rahatlıkla hangi makinadan sorgu geliyor ve hangi Sql Server’a gidiyor tespit edebildik.
Eğer networkünüzdeki Sql Server’ın bu şekilde izlenip tespit edilmesini istemiyorsanız, bir
SSL sertifikası alıp bunun önüne geçebilirsiniz. SSL Sertifikasını Verisign, Digicert veya
Comodo gidi firmalardan temin edebilirsiniz.
Alınan bu sertifikayı Mmc konsolu açarak, Snap add ins den, yüklemelisiniz. Sertifikayı Sql
Server servisini çalıştıran kullanıcıya yüklemeniz gerektedir.
Sertifikayı yükledikten sonra, Sql Server Conf. Manager – Sql Server Network Configuration
– Protocols for Sql Server’ın properties ekranını açıyoruz.
Flags sekmesinde, Force Encryption’a yes diyoruz. Certificate kısmında da yüklediğiniz
sertifikayı seçip Ok diyoruz.
SSS-8
Sql Server Management Studio’ya bağlanırkende encrypt bağlantı sağlanabilir. SSMS
açıldıktan sonra Connect to Server ekranında Options ile özellikleri açıyoruz.

SSS-9
Connection Properties ekranında Encrpt Connection diyerek client ile Sql Server arasında
SSMS iletişimi encrypt edilebilmektedir.
SSS-10
Windows Firewall’un Yapılandırılması:
 
Güvenlik duvarı olarak Windows firewall kullanıyorsanız, Sql Server’a erişmek için gerekli
TCP ve UDP portlarını açmanız gerekmektedir. Windows firewall’u Server 2008 ile
varsayılan olarak açık gelmektedir.
Control Panel – Windows Firewall’u açalım. Advanced settings’e geliyoruz.
SSS-11
Inbound Rules ( Gelen Kuralları) sekmesinde, Action tabındaki “New Rule” ile yeni bir kural
oluşturacağız.

SSS-12
Rule type, rol tipinde Port’u seçiyoruz.
SSRS-13
Protocol and Port sekmesinde TCP ve Specific local port’u seçip, ports kısmında 1433
yazıyoruz.

SSS-14
Action sekmesini Allow the connecton- bağlantıya izin ver, olarak seçip devam ediyoruz.
SSS-15
Profile sekmesinde karşımıza 3 farklı seçenek çıkıyor. Domain, yapıda active directory var ise
sadece domain deki makinalara erişim verir. Private, domain olmayan yapılarda workgroup
olan yapılardaki bağlantılara izin verir. Public ise Sql Server’a dışarıdan erişimi sağlar.

SSS-16
Name kısmında kuralımız için isim verip Finish ile kural oluşturma işlemini tamamlıyoruz.
SSS-17
Kuralımız  Inbound Rules ekranına geldi. Eğer daha fazla kısıtlama ve sadece güvenli
makinaların erişmesini istiyorsak. Kuralımızın özellikler ekranını açarak, gerekli ayarlamaları
yapalım.

SSS-18
General sekmesindeki Action bölümünde “Allow the connetion if it is secure” (Eğer bağlantı
güvenli ise izin ver)seçeneğini seçiyoruz.

SSS-19
Sonrasında Remote Users ve Remote Computers sekmelerinden istediğimiz bilgisayar veya
kullanıcıyı seçerek izin veriyoruz.

SSS-20
Sql Server Browser’ın Devre Dışı Bırakılması:
 
Sql Server’ı yükledikten sonra Sql Server Browser hizmeti otomatik olarak devreye girer ve
çalışmaya başlar. Kullanıcı tarafındaki bilgisayarlara Sql Server’ın olduğunun bilgisini
gönderir. Network üzerinde hangi sunucularda Sql Server çalıştığı kolaylıkla Browser’ı açık
olan sunuculardan tespit edilebilmektedir. Sql Server Browser’ı kapatmak için Sql Server
Configuration Manager’ı açıyoruz (Şekil SSS-1).
Sql Server Services bölümünde Sql Server Browser hizmetine çift tıklayarak properties
ekranını açıyoruz. Stop butonuna tıklayarak Browser servisini durduruyoruz.
SSS-21
Sql Server yeniden başladığında Browser hizmetini tekrardan çalıştıracaktır, bu sebeple
Service sekmesinde, Browser hizmetinin başlangıç ayarlarını devre dışı bırakıyoruz.

SSS-22
Server – Client Arasında Extended Protection Yapılandırılması:
       
Sql Server ile client arasında kimlik doğrulama katmanlı bir bağlantı vardır. Client
bağlanacağı Sql Server’ı kayıtlı kimlik bilgilerinden bilir, her seferinde bağlanacağı Sql
Server’ı aramaz. Aynı şekilde server tarafında da benzer durum yaşanır. Client geçerli giriş
anahtarını ve şifresini sağladığı için server’a erişim hakkı sağlamıştır.
Bu bağlantı şeklinde, saldırgan server ve client arasına girerek, kendisini Sql Server olarak
gösterir. Client yemi yutmuş olur, Sql Server’a bağlandığını zanneder, aslında saldırganın
makinasına bağlanmıştır. Saldırganda client’tan Windows Authentication bilgilerini çalarak,
Sql Server’a bağlanmaya çalışır. Bu saldırı tipine Luring Attacks denir. Lure yem anlamına
gelmektedir, yemleme atakları da diyebiliriz.
Diğer saldırı şeklide, yaygınca bilinen Man-in-the-Middle atak diye tabir edilen, ortadaki
adam manasına gelen bu saldırı yönteminde, Dns yönlendirmesi veya Ip routing yapan
saldırgan Server ile client arasına girip dinleme yapar. Sql Server kimlik bilgilerini client
tarafında onayladığı sırada saldırgan bilgileri ele geçirmiş olur. Bu saldırı tipine de Spoofing
Attacks denmektedir.
Bu tip saldırılardan korunmak için Sql Server üzerinde Extended Protection özelliğini aktif
hale getirmemiz gerekmektedir.
Sql Server Configuration Manager – Sql Server Network Configuration – Protocols Sql
Server’ın Properties ekranını açıyoruz.

SSS-23
Advanced sekmesinde “Extended Protection” kısmında Allowed’u seçiyoruz.

SSS-24
Extended protection özelliği Windows7 ve Server 2008 R2 işletim sistemlerinde gelmektedir.
Eski sürümler için aşağıdaki güncellemeyi yüklemeniz gerekmektedir.
http://support.microsoft.com/kb/968389
Msdn: http://msdn.microsoft.com/en-us/library/ff487261.aspx
 
Veritabanı Dosyalarının Şifrelemesi:
 
Veritabanı dosyaları, Sql Server çalışırken kilitlenir ve mdf-ldf uzantılı dosyaları normal
şartlarda kopyalamayız. Kopyalayabilmek için Sql Server hizmetinin durdurulması
gerekmektedir. Fakat bu dosyaların Sql Server çalışırken kopyalanması Hobocopy gibi
programlarla mümkündür. Veritabanı dosyalarınızı ele geçiren bir saldırgan bu dosyaları
farklı bir sunucuda akitf edip, istediği verilere ulaşabilir.
Yukarıdaki durumu yaşamamak için veritabanı dosyalarını şifrelenmesi, bu dosyaların farklı
Sql Server’lar üzerinde açılmasını engelleyecektir. Çalınan veritabanı dosyalarını açmak için
bu şifrenin decrypt yani çözülmesi gerekmektedir. Bu şifreleme işlemine Transparent
Database Encryption denmektedir. Bu özellik Enterprise, Datacenter ve Developer
sürümlerinde geçerlidir.
Veritabanı dosyaları nasıl şifrelenir buna bakalım;
İlk olarak server encryption master key – ana anahtar oluşturmamız gerekmektedir. Yeni bir
sorgu ekranı açarak master key’i aşağıdaki gibi oluşturalım.
USE master;
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Guclu_Sifre';
 
Bu şifrelemenin hemen yedeklenmesi gerekmektedir. Eğer master veritabanınızı
kaybederseniz, şifrelenmiş veritabanınızın içeriğini hiçbir şekilde göremezsiniz. Yedek alınan
klasörü paylaşıma açın, ve klasör yolunu doğru yazdığınızda emin olun, aksi takdirde hata
verecektir, yedek almayacaktır. Yedek almak için aşağıdaki kodu yazıyoruz.
BACKUP MASTER KEY TO FILE = '\\YAVUZSONY\Yedek\
Yavuzsony_master.key'ENCRYPTION BY
PASSWORD = 'Guclu_bir_sifre_daha';
 
Eğer bir password policy kullanıyorsanız, örnek olarak en az 8 karater, en az bir büyük harf,
en az bir özel karakter gibi, şifrenizi bu policy’e göre vermeniz gerekmektedir.
Şimdi sıra server sertifikası üretmesine geldi, bu sertifika sunucuya özel bir sertifikadır.
Veritabanı dosyalarınızın şifrelenmesinde kullanılacaktır.
CREATE CERTIFICATE SqlSertifikasi WITH SUBJECT = 'Sql Sertifika';
 
Oluşturduğumuz sertifikayı yedekleyelim, hem de dosya olarak elimizde bulunsun.
BACKUP CERTIFICATE SqlSertifikasi TO FILE ='\\YAVUZSONY\Yedek\
SQL_SqlSertifikasi.cer'
WITH PRIVATE KEY (    FILE = '\\YAVUZSONY\Yedek\SQL_SqlSertifikasi.pvk',   
ENCRYPTION BY PASSWORD = 'Guclu_Sifre_Guclu_Sql' );
 
Oluştruduğumuz server sertifikası ile, veritabanı üzerinde encryption key oluştuyoruz.
USE SATIS;
GO
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_128
ENCRYPTION BY SERVER CERTIFICATE SqlSertifikasi;
 
Son olarak veritabanı şifrelemesini aktif hale getiriyoruz.
ALTER DATABASE SATIS
SET ENCRYPTION ON
 
Oluşturduğumuz key ve sertifika dosyalarına bakalım, bu dosyaların yedeğini almayı
unutmayın.

SSS-25
Güvenlik sertifikası, private key ve master key olarak 3 dosyayı veritabanı şifrelemesinde
kullandık.
Transparent Database Encryption, veritabanı mdf ve ldf dosyalarınızı görünmez bir şekilde
şifreledi. Bu dosyaların şifrelendiği bilgisi Sql Server üzerinde veya dosyaların özellik
sayfalarında gözükmez.
Şifrelenmiş bir veritabanını Sql Server’a geri eklemeniz için, ilk önce güvenlik sertifikasını ve
encryption key’i geri yüklemeniz gerekmektedir. Geri yüklerken şifreyi yazıyoruz.
USE master;
CREATE CERTIFICATE SqlSertifikasi FROM FILE ='\\YAVUZSONY\Yedek\
SQL_SqlSertifikasi.cer'
WITH PRIVATE KEY (    FILE = '\\YAVUZSONY\Yedek\SQL_SqlSertifikasi.pvk', 
DECRYPTION BY PASSWORD = 'Guclu_Sifre_Guclu_Sql')
 
Msdn: http://msdn.microsoft.com/en-us/library/bb934049.aspx
Xp_CmdShell Özelliklerinin Kısıtlanması:
 
Sql Server 2005’te güvenlik sorunları teşkil eden bazı özellikler, yeni Sql Server
versiyonlarında, kurulumda varsayılan olarak devre dışı bırakılıp getirilmiştir. Bunlardan en
önemlisi xp_cmdshell komutudur. Bu özelliklerin aktif etmek için Sql Server Management
Studio da instance adına sağ tıklayıp “Facets” bölümüne gelelim.

SSS-26
Facet alanından Surface Area Configuration’ı seçiyoruz.
SSS-27
AdHocRemoteQueriesEnabled, OleAutomationEnabled ve XPCmdShellEnabled alanlarının
False değerinde olması  gerekiyor, eğer değilse bu alanları False değerine getiriyoruz.

SSS-28
Sql Server’da Güvenlik makale dizisinin 1. Bölümünün sonuna geldik, 2. Bölümde görüşmek
üzere.
 

Sql Server Güvenlik Kavramı – Bölüm 2

İlk bölümde Sql Server’ın kurulu olduğu server ve network üzerindeki güvenlik ayarlarından
bahsettik. Bu bölümde, Sql Server’ın kendi içindeki güvenlik tanımlamalarından
bahsedeceğiz. Kimlik doğrulama seçenekleri, kullanıcı yönetimi, Sa kullanıcısının yetkileri,
kullanıcı rolleri ve veritabanı yetkileri hakkındaki detaylara bakacağız.
İlk olarak Sql Server’da kimlik doğrulama konusuna değinelim.
Kimlik Doğrulama:
               
Sql Server ile clientlar arasında iki çeşit kimlik doğrulama yöntemi vardır. Windows
Authentication ve Sql Server Authentication. Sql Server kurulumunda hangi yöntem ile
kimlik doğrulama yapacağınız size sorulur. Windows Authentication modu devre dışı
bırakılamaz. Tek olarak Windows Authentication veya Sql Server – Windows Authentication
modları bütünleşik olarak seçilebilir.
Kimlik doğrulama seçeneklerini görmek için, Sql Server Management Studio – Object
Explorer instance adınız üzerinde sağ klik Properties

SSS-29
Security sekmesine geliyoruz.
SSS-30
“Windows Authentication mode” Sadece Windows hesaplarından açılan oturumları kabul
eder.
“Sql Server and Windows Authentication mode” Hem Windows hem de Sql Server
hesaplarından açılan oturumları kabul eder.
Server Authentication kısmında yaptığınız kimlik doğrulama yöntemlerinden sonra Sql Server
servisinin yeniden başlatılması gerekmektedir.
Windows Authentication varsayılan olarak Sql Server kurulumunda seçili olarak gelmektedir.
Öngörülen ve daha güvenli olan kimlik doğrulama seçeneğidir. Kullanıcı Sql Server’a
kullanıcı adı ve şifre girmeden, Windows hesabı ile bağlanabilmektedir. Windows
Authentication devre dışı bırakılamaz. Mixed mode seçili olduğunda aynı zamanda Windows
Authentication kullanılabilmektedir.
Sql Server Authentication’ı dışarıdan erişecek ve domain yapınızın dışından erişecek
kullanıcılar için açabilirsiniz. Sql Server hesapları, Sql Server’ın içinden yönetilir, Windows
hesapları ile bir bağlantısı yoktur.
Msdn: http://msdn.microsoft.com/en-us/library/bb669066(v=vs.110).aspx
Sql Server Kullanıcı Hesapları:
 
Sql Server’daki kullanıcıların hesaplarına Logins denmektedir. Her bir login’e ayrı yetkiler
verilebilir, erişebileceği veri tabanları belirlenebilir. Sql Server’da güvenlik seviyesi iki
katmandan oluşur Server ve Veritabanı seviyesi. Login hesabı ilk önce server seviyesi
oluşturulur, daha sonra ilgili veri tabanına mapped denilen ataması yapılır ve veri tabanına
erişimi sağlanmış olur.
Sql Server üzerinde kullanıcı – login açmak için SS Management Studio – Security – Logins
üzerinde sağ klik “New Login” diyorurz.
Windows Authentication ile domain kullanıcısına Sql Server için yetki verilebilir. Search
kısmından yetki verilmek istenen kullanıcı seçilebilir.

Sql Server Authentication seçildiğinde kullanıcı adını yazabilirsiniz. Sql Server’ın yönettiği
hesaplar olduğu için Windows hesaplarından farklı olacaktır.
“Enforce password policy” – Domaindeki veya Windows işletim sisteminde password policy
kuralları geçerli olur.
“Enforce password expiration” - Domaindeki veya Windows işletim sisteminde şifre
geçerlilik süresi bu seçenek ile geçerli olur.
“User must change password at next login” – Kullanıcı bir sonraki oturumunda şifresini
değiştirmek zorunda kalır. SSMS ile bu şifre değiştirebilir.
“Default Database” – SSMS bağlanıldığında kullanıcı bazlı, çalışılacak olan veritabanı
otomatik olarak gelir.
“Default Language” – SSMS üzerindeki dil ayarları, format ve hata mesajları istenen dilde bu
seçenek ile ayarlanabilir.
Enforce password policy ve pasword expiration seçeneklerinin Sql logini için seçilmesi, basit
şifrelerin kullanılmasının önüne geçeceği gibi, uzun süre değiştirilmeyen şifreler içinde tedbir
olacaktır.
Domain Password Policy Technet: http://technet.microsoft.com/en-us/library/cc264456.aspx
T-Sql kodu ile Sql login aşağıdaki gibi oluşturulmaktadır.
USE [master]
GO
CREATE LOGIN [yavuzsql] WITH PASSWORD=N'Guclu_bir_sifre' MUST_CHANGE,
DEFAULT_DATABASE=[PLANLAMA],
DEFAULT_LANGUAGE=[Türkçe],
CHECK_EXPIRATION=ON,
CHECK_POLICY=ON
GO
 
Password policy seçili olan bir Sql hesabında, şifre denemesi aynı Windows hesabında olduğu
gibi geçerlidir. Yanlış girilen şifrelerden dolayı Sql hesabı kilitlenebilir. Sql hesabının kilidini
açmak için aşağdaki T-Sql kodu çalıştırılır.
ALTER LOGIN yavuzsql WITH PASSWORD = 'yeni_sifre' UNLOCK;
-- Şifre değiştirilmek istenmiyor ise, aşağıdaki komutlar ile çalıştırılır
ALTER LOGIN fred WITH CHECK_POLICY = OFF;
ALTER LOGIN fred WITH CHECK_POLICY = ON;
 
Bir Sql hesabını devre dışı bırakmak veya tekrar aktifleştirmek için aşağıdaki T-Sql kodu
kullanılır.
-- Hesabı devre dışı bırakır
ALTER LOGIN yavuzsql DISABLE;
-- Hesabı aktifleştirir
ALTER LOGIN yavuzsql ENABLE;
 
Bir Sql hesabını silince, bu hesabın tüm ayarları kaybolur, tekrar bu hesabı oluşturduğunuzda
tüm tanımları yeniden yapmanız gerekmektedir. Bu sebeple, hesabın Sql Server’a erişimimi
kapatarak, hesabı silmeden kullanıcının Sql Server’a erişimini engelleyebilirsiniz.
DENY CONNECT SQL TO yavuzsql;
 
Bu ayarları kullanıcının Properties sayfasındaki Status sekmesinden de yapabilirsiniz.
SSS-34
“Permission to connect database engine” – Kullanıcının Sql Server’a bağlanmasına izin/engel
vermesi.
“Login” – Kullanıcı hesabının devre dışı/aktif edilmesi.
“Sql Server Authentication – Login is locked out” – Kilitlenen Sql Server hesabı buradan
açılabilir.
Kullanıcı hesaplarının güvenlik ile alakalı kısımlarından bahsettik. Login – Properties’in diğer
sekmeleri olan Server Roles, User Mapping ve Securables bölümleri kullanıcının Sql Server
içindeki erişim izinleri ile alakalıdır.
Sql Login Msdn: http://msdn.microsoft.com/en-us/library/aa337562.aspx
 
Sql Saldırılarından Korunma Yöntemleri:
               
Windows sunucularına saldırdıkları gibi, Sql Server’a aynı şekilde Brute-force denilen saldırı
yöntemi ile ataklar sürekli olmaktadır. Windows tarafında kullanılan password policy eğer Sql
tarafında kullanılmıyorsa, Sql Server’ınızda güvenlik olarak büyük bir açığınız var demektir.
Sql login şifrelerini 12345 gibi basit şifreler koydu iseniz, kırılması sadece birkaç saniye
sürecektir. Önerilen en temel şifreleme policy’si en az bir rakam, en az bir büyük harf, en az
bir özel karakter olacak şekilde 8 karakterden az olmamak şartıdır. Şifrenizin ne kadar uzun
ve ne kadar çok karmaşık olması brute-force ataklarından sizi daha iyi koruyacaktır.
Şifrenin uzun ve karmaşık olmasının yanı sıra, belirli periyodlarla değiştirilmesi
gerekmektedir. Sürekli aylarca, yıllarca aynı kalan şifrelere uzun süren brute-force ataklar ile
kırılabilmektedir.
İlk olarak Sql Server’ımızda kaç tane login-hesabınımız var bakalım.
SELECT * FROM sys.sql_logins
 
Sys.sql_logins Sistem  tablosundan tüm loginlerimizi bize getiriyor. Loginlerimizde password
policy olmayan hesapları tespit etmemiz içn, SSMS üzerinde tek tek loginlerin özellikler
sayfasına girmek çok fazla vakit kaybı olacaktır. Sql_logins tablosunda password policy
olmayan hesapları tespit etmek için aşağıdaki sorguyu çalıştırıyoruz.
SELECT name, is_disabled
FROM sys.sql_logins
WHERE is_policy_checked = 0
 
İki tane Sql loginde password policy olmadığı gözüküyor.

SSS-35
Birden çok login hesabınız olduğunda password policyleri aktif etmeniz uzun sürecektir.
Aşağıdaki sorgu ile login veya loginlerin password policylerini aktif hale getirebilirsiniz.
ALTER LOGIN yavuzsql WITH CHECK_POLICY = ON,
CHECK_EXPIRATION = ON;
 
Check_Expiration ile de şifre değiştirme süresini aktif hale getirmiş olduk. Şifrenin süresinin
ne zaman dolacağınız aşağıdaki komut ile sorguluyoruz.
SELECT LOGINPROPERTY('yavuzsql', 'DaysUntilExpiration');
 
SSS-36
Şifreyi değiştirmek için 39 gün kaldığını gösteriyor.
Msdn: http://msdn.microsoft.com/en-us/library/ms161959.aspx
Sql hesabınıza şifre deneme saldırısı yapıldığında, bu denemeleri kendinize veya tanımlı
kişilere mail olarak bildirebilirsiniz.
İlk olarak Sql Server Management Studio – Management – Database Mail bölümünde tanımlı
bir Sql Database hesabı yapılandırmanız gerekiyor. Bunun Database maile sağ klik
“Configure Database Mail”

SSS-37
Wizard karşılama ekranını Next ile geçiyoruz.
Set up Database Mail by performing the following task seçeneğini seçip Next ilerliyoruz.
SSS_38
Profil adını yazdıktan sonra Add butonuna tıklıyoruz.

SSS-39
New Database Mail Account ekranını aşağıdaki gibi dolduruyoruz. Sisteminizde bir Smtp
server var ise, Smtp serverınızdan bir hesap ile Database mail oluşturabilirsiniz.

SSS-40
Ok dedikten sonra Manage Profile Security ekranında “Public Profiles” sekmesinde Public
check box’ını işaretliyor  ve “Default Profile”i Yes olarak ayarlıyoruz.
SSS-41
Database mail hesabımız tanımlanmış oldu. Mutlaka aşağıdaki gibi bir test maili gönderip,
Database mailin çalışıp çalışmadığını kontrol edin.

SSS-42
Mail tanımlarını yaptık, test mailini gönderdik. Sa hesabına şifre denemesi yapıldığında bize
mail gelmesini istiyoruz.
Sql Server Agent üzerinde sağ klik New – Alert diyoruz. Yeni bir uyarı tanımlayacağız.
SSS-43
New Alert ekranında tanımları aşağıdaki gibi yazıyoruz.

SSS-44
Bu tanımdan sonra mail gelmesi için Response sekmesinde Notify Operators seçeneğini
seçerek istenen kişilere mail gönderilmesi sağlanır. Eğer Operator tanımı yok ise New
Operator ile yeni bir operatör tanımlanır. Tanımlanan operatör Response ekranına gelecektir.
SSS-45
Tüm ayarları yaptıktan sonra Database mailin Sql Server Agent için aktif edilmesi
gerekmektedir. Database mail varsayılan olarak Sql Server içinde sys.send_mail prosedürü
tarafından kullanılmak üzere ayarlanmaktadır. Sql Server Agent için Database maili
aktifleştirmek içi, Sql Server Agent üzerinde sağ klik Properties ekranı açılır. Alert System
sekmesindeki Enable Mail Profile ile aktifleştirme işlemi tamamlanır.
SSS-46
Bu ayar yapılmazsa, Sql Server Agent üzerindeki Alert’lerden mailler gelmez.
Sa kullanıcısına şifre denemeleri yapalım.
SSS-47
18456 nolu hatayı aldık, bakalım bu deneme Sql Server tarafından bize mail atıldı mı,
mailimize gidip kontrol ediyoruz.

SSS-48
Operatöre Yahoo mailimi tanımlamıştım. Hatalı yapılan girişler mail olarak geldi.
 
Sa Hesabının Kısıtlanması:
 
Sa kullanıcısı ilk Sql Server çıktığından beri olan, System Administrator anlamına gelen, Sql
Server’ın sistem yöneticisi hesabıdır. Eski Sql Server sürümlerinde devre dışı bırakılması
mümkün değildi. Sql Server 2005 ile birlikte devre dışı bırakılması ve değiştirilmesi sağlandı.
Sa hesabını neden kapamalıyız veya neden kısıtlamalıyız, çünkü en çok saldırı alan Sql Server
hesabıdır. Saldırganlar tarafından ilk önce kontrol edilen hesaptır, sa hesabında sistem
yöneticiliği rolü olduğundan ilk önce bu hesap yoklanır. Birçok firmada sa hesapları aktif
haldedir. Ne yazık ki kobi dediğimiz küçük ve orta boy ölçekteki bir çok firmada ise durum
daha vahimdir. Bazı firmalarda halen sa hesabı aktif olup şifreside yoktur. Firma sahipleri
etkili bir atak yedikten sonra, verileri çalınıp şifrelendikten sonra tedbir almaya başlarlar.
Sa hesabını aşağıdaki komutla devre dışı bırakıyoruz.
ALTER LOGIN [sa] DISABLE
 
Sa hesabının adını aşağıdaki komut ile değiştirebilirsiniz.
ALTER LOGIN [sa] WITH NAME = [test_kullanici]
Sa hesabının Securtiy ID’si (SID) 1 olduğundan daha aşağıdaki sorgu ile sa hesabının adını
öğrenebilirsiniz.
SELECT * FROM sys.sql_logins WHERE principal_id = 1
 
Sa hesabını SSMS üzerinden devre dışı bırakmak için. SSMS – Security – Logins Sa hesabına
sağ tıklayıp özelliklerine giriyoruz.
Status sekmesinden aşağıdaki şekildeki gibi database engine için Deny, SSMS erişimi içinde
Login Disable yapıyoruz.

SSS-49
Sql Server kurulumunda Windoıws Authentication seçeneği seçilerek kurulum yapıldı ise, sa
devre dışı kalır. Sa şifresini hatırlamanıza gerek yoktur. Olabildiğince zor bir şifre koyarak sa
hesabının adını değiştirmek gerekmektedir.
Msdn: http://msdn.microsoft.com/en-us/library/ms188670.aspx
 
Sql Server Rolleri:
 
Bir Sql Server hesabı varsayılan olarak hiçbir yönetici yetkisi olmadan oluşturulur. Bu role
public rolü denir. Daha sonra hangi veritabanına erişmek istiyor ise Logins – Properties –
User Mapping sekmesinden veritabanı yetkileri atanır. Eğer bir kullanıcıya yönetici yetkileri
vermek istiyorsanız, Login’nin server roles sekmesinden gerekli rolü verebilirsiniz.
Sql Server’da roller aşağıdaki gibidir;
-          Bulk Admin: Bulk insert yapma yetkisine sahiptir. Bir dosyadan veritabanına kayıt
eklemek için kullanılır. Genellikle excelden veri çekmek için kullanılmaktadır.
-          Dbcreator: Herhangi bir veritabanını oluşturma, düzenleme ve kaldırma yetkisi
vardır. Yazılımcılara test amaçlı bu yetkiden verilebilir.
-          Processadmin: Sql proseslerini görme ve sonlandırma yetkisi vardır. Tüm çalışan
prosesleri görebilirler. Kill komutu ile istenen proses veya prosesleri
sonlandırabilirler.
-          Securityadmin: Sql hesabı oluşturup silebilirler. Server rolü oluşturma yetkileri
yoktur.
 -          Serveradmin: Sql server instance’ının özelliklerini değiştirebilir, yeniden
başlatabilir veya hizmeti durdurabilirler.
-          Setupadmin: Linked server oluşturma yetkileri vardır.
-          Sysadmin: Tüm yönetici yetkilerine sahip roldür.
Sql Server hesaplarına atanmış olan rolleri aşağıdaki sorgu ile görebilirsiniz.
SELECT role.name as role,role.is_fixed_role,login.name as login
FROM sys.server_role_members srm
JOIN sys.server_principals role ON srm.role_principal_id = role.principal_id
JOIN sys.server_principals login ON srm.member_principal_id = login.principal_id
 
SSMS üzerinde bir kullanıcının rolünü ayarlamak için,
SSMS – Security – Logins bölümünde kullanıcının Properties ekranından Server Roles
sekmesinden istenen rol kullanıcıya atanır.

SSS-50
Veritabanı Seviyesinde Kullanıcı Yetkisinin Yapılandırılması:
               
Sql Server’da kullanıcıya Server Roles verilmesi birçok yetkiyi de beraberinde getirir.
Kullanıcı sadece istenen veri tabanlarında yetki istediği zaman, login özelliklerinden User
Mapping sekmesinden istenen yetkiler atanabilir.
SSMS – Security – Logins kullanıcının properties sayfası açılır. User Mappings sekmesine
gelip, hangi veritabanında nasıl bir yetki isteniyor ise “Database role membership for:
<veritabanı_adi>” bölümünden ilgili yetkiler işaretlenir.
SSS-51
“Map” checkbox’I ile hangi veritabanında yetki verilecekse seçilir. Map seçildikten sonra
yetkiler açılır. User otomatik olarak gelir, istenirse “Default Schema” dan varsayılan şema
seçilebilir.
Veritabanı map edildikten sonra “ Database role membership for: “ alanından ilgili yetkiler
seçilir. Database rolleri nedir, bunları inceleyelim.
Database Roles:
-          Db_accessadmin: Veritabanına erişim için yetki verir.
-          Db_backupoperator: Veritabanının yedek alması için yetki verir. Sistem
yöneticilerine yedek alınan 3. Parti bir yazılımda kullanılmak üzere bu yetki
verilebilir.
-          Db_datareader: Tablolardaki verileri okuma yetkisi verir. Sadece Select sorgusu
kullanan ve Self Service raporlaama yapan son kullanıcılara bu yetki verilebilir.
-          Db_datawriter: Tablolardaki verileri düzenleme, silme veya ekleme yetkisi verir.
Server bazında yetki kısıtlanarak farklı programlardaki farklı kullanıcılara bu yetki
verilebilir.
-          Db_ddladmin: Veritabanı üzerinde DDL (Data Definition Language) komutlarını
çalıştırma izni verir.
-          Db_denydatareader: Veritabanı üzerinde okuma işlemi yetkisini engeller.
 -          Db_denydatawriter: Veritabanı üzerinde değiştirme, ekleme ve silme yetkisini
engeller.
-          Db_owner: Veritabanı üzerindeki tüm yapılandırma ve bakım yetkilerini verir.
Veritabanını drop etme yetkisine sahiptir. Owner, sahip anlamına gelmektedir.
-          Db_securityadmin: Veritabanı üzerindeki üyelikleri ve izinleri yönetme yetkisidir.
User Mapping Technet: http://technet.microsoft.com/en-us/library/ms178316(v=sql.105).aspx
Database Roles
Technet: http://technet.microsoft.com/en-us/library/ms189121(v=sql.105).aspx
Server Seviyesinde Kullanıcı Yetkisinin Yapılandırılması:
 
Sql Server’da kullanıcılara yetki verme ve yetki kısıtlamaları detaylı olarak sunulmuştur.
Doğru yapılandırıldığında sistem güvenliği daha da artaracaktır. Veritabanı seviyesindeki
yetkileri gördükten sonra, Server seviyesinde de Sql Server bize yetkilendirme imkanı
sunmaktadır.
SSMS – Security – Logins kullanıcının properties sayfasından Securables sekmesine
geliyoruz.
SSS-52
Bu ekrandan kullanıcıya yetkileri Grant ile verebilir, Deny ile de engelleyebiliriz.
T-Sql ile yapmak içinde,
GRANT ALTER ANY CONNECTION TO yavuzsql;
 
Loginin Securables sekmesine baktığınızda Alter Any Connection bölümünde Grant’ın seçili
olduğunu göreceksiniz.
Yetki verilen server permissionlarına aşağıdaki sorgu ile kontrol edilebilir.
SELECT * FROM sys.server_permissions
 

SSS-53
Kullanıcının izin verilen yetkileri aşağıdaki sorgu ile kontrol edilebilir.
SELECT SP.class_desc, SP.permission_name, SP.state_desc
FROM sys.server_permissions SP
JOIN sys.server_principals SPR
ON SP.grantee_principal_id = SPR.principal_id
WHERE SPR.name = 'yavuzsql'
 
SSS-54
Alter Any Connection için Grant yetkisi vermiştik, sorguda karşımıza çıkıyor.
Database level permission ile ilgili aşağıdaki posteri indirip detaylı inceleme yapabilirsiniz.
Sql 2008 R2 ve Sql 2012 için geçerlidir.
Technet Poster: http://social.technet.microsoft.com/wiki/cfs-file.ashx/__key/
communityserver-wikis-components-files/00-00-00-00-
05/5710.Permissions_5F00_Poster_5F00_2008_5F00_R2_5F00_Wiki.pdf
Msdn: http://msdn.microsoft.com/en-us/library/ms191291.aspx
 
Veritabanı Kullanıcısı Yönetimi:
 
Loginler Sql Server’daki kullanıcı hesaplarıdır. Yönetilmeleri de dikkat ister, yetkileri
detaylıdır. Database user yani veritabanı kullanıcısı ise sadece, ilgili veritabanındaki temel
güvenliğe bağlıdır. Sql Server’a server bazında bir yetkilendirme yapmaya gerek kalmadan
kullanabilir. Bu da gereksiz login açmaya gerek bırakmadan basit ve kolay bir güvenlik
sağlar. Varolan bir logine Database user bağlanabilir, böylelikle sürekli login açmaya gerek
kalmaz.
Veritabanı kullanıcısı açmak için SSMS – Databases – VeritabanıAdi – Security – Users
bölümde sağ klik – New User ile yeni veritabanı kullanıcısını açıyoruz.

SSS-55
Database user ekranında, ilk olarak General sekmesi karşımıza geliyor, User Type alanında
kullanıcının tipini seçiyoruz.
SSS-56
Kullanıcı tiplerine kısaca bakalım;
-          Sql user with login: Bir Sql login hesabına map edilmiş kullanıcı tipidir.
-          Sql user without login: Bir Sql login hesabına bağlanmamış kullanıcıdır, T-Sql de
execute as user komutları ile kullanılabilir.
-          User mapped to a certificate/an asymetric key: Bir signature key’e atanmış
kullanıcı tipidir.
-          Windows user: Windows Authentication hesabına map edilmiş kullanıcı tipidir.
Windows user’a map edilmiş bir kullanıcı oluşturalım. User Name kısmında kullanıcı adını
yazıyoruz.
Kullanıcı adını yazdıktan sonra, database user’ı Windows User’a atamamız gerekiyor. Login
name kısmından bu atamayı yapıyoruz.
SSS-57
İstenirse default schema da atanabilir.
Windows user map edilirken, domaindeki bir kullanıcıyı siz biliyor olabilirsiniz ama Sql
Server bunu bilemez, bu yüzden Windows user olarak domaindeki kullanıcınızı Logins
kısmından ilk önce Sql Server’a eklemeniz gerekmektedir. Browse for object dediğimizde
karşımıza sadece Logins ekranında eklediğimiz Windows kullanıcıları gelecektir.
Owned Schema ve Membership sekmelerinden rol yetkilerini verebiliriz.

Veri tabanlarına atanmış olan Database owner yani veritabanı sahibi olarak atanmış
kullanıcıları sorgulayarak, hangi veritabanında hangi kullanıcıların yetkileri var kontrol
edebilirsiniz. Gereksiz gördüğünüz ve kullanılmayan hesapları mutlaka kapatın veya devre
dışı bırakın.
Veri tabanlarındaki database owner ları görmek için aşağıdaki sorguyu çalıştırın.
SELECT SUSER_SNAME(owner_sid), name FROM sys.databases
SSS-59
Msdn: http://msdn.microsoft.com/en-us/library/aa337545.aspx
Sistem Fonksiyonları - Kullanıcı ve Login Bilgileri Kontrolü:
SSMS üzerinden kullanıcı ve loginleri ilgili ekranlara tek tek girerek incelemek
gerekmektedir. Böyle bir işlem çok fazla zaman alacağından, Sql Server’ın sistem
fonksiyonları ile kontrol edebiliriz.
Is_Member ile mevcut kullanıcının grup üyesi olup olmadığını kontrol edebilirsiniz.
SELECT IS_MEMBER('yavuzsony\yavuz');

SSS-60
 
Diğer fonksiyonlarda aşağıdaki gibidir;
-          SYSTEM_USER: Bağlı olan login hesabını gösterir
SELECT SYSTEM_USER veya SELECT SUSER_SNAME();
 

SSS-61
 
-          SUSER_ID(): Mevcut kullanıcının Security ID’sini gösterir.
SELECT SUSER_ID();

SSS-62
 
-          CURRENT_USER / SESSION_USER: Mevcut  Database kullanıcısını gösterir.
SELECT CURRENT_USER;
SELECT SESSION_USER;
SSS-63
 
-          ORIGINAL_LOGIN: Windows hesabındaki kullanıcı adını gösterir.
SELECT ORIGINAL_LOGIN();

SSS-64
 
-          HAS_DBACCESS('veritabani_adi'): Mevcut kullanıcının veritabanına erişimi olup
olmadığını gösterir. 1 Değeri döner ise erişim var demektir.
SELECT HAS_DBACCESS('ARGE');

SSS_65
 
Msdn: http://msdn.microsoft.com/en-us/library/ms186236.aspx
 
Kullanıcılardan ve Sql Hesaplarından Ana Verileri Gizleme:
Sql serverdaki veritabanları ve diğer nesneler, yetkisi az olan bir kullanıcıya da açık olarak
gelir. Gözükmesini istemediğiniz bu nesneler için engellemeler yapabilirsiniz. İlk olarak
yapılması gerek public rolü için View Any Databases özelliğini kapatmak olacaktır.
 
USE master;
GO
REVOKE VIEW ANY DATABASE TO public;
 
Public rolündeki kullanıcımla SSMS’e giriş yapıp kontrol ediyorum.
SSS-66
Görüldüğü gibi yavuzsql kullanıcısında sadece ARGE veritabanını görme yetkisi vardı,
Databases altında sadece ARGE gözüküyor.

SSS-67
 
Kullanıcı için bir veritabanındaki belli bir nesneye yetki vermek için, veritabanı içindeki
Security - Users özellikler sayfasında, Securables sekmesinden gerekli izinler atanabilir.
Örnek olarak bir stored procedure veya bir tablo bu ekrandan yetkilendirilebilir.
Kullanıcının üzerinde sağ klik Properties ekranına giriyoruz. Securables sekmesindeki
Search’e tıklıyoruz.
SSS-68
Search – Specify Objects

SSS-69
Object Types’a tıklayıp seçebilecek nesneleri göreceğiz.
SSS-70
Select Object Types ekranında veritabanındaki tüm nesnelerin ana grupları gözükmekte.
Örnek olarak View seçip Ok ile devam edelim.

SSS-71
Select Objects ekranında Browse diyoruz. Hangi nesne tipini seçersek, onunla ilgili kayıtlar
gelecektir.

SSS-72
Sistem viewleri dahil veritabanındaki tüm viewler geldi. Daha önce oluşturduğum
arge_view’i seçiyorum.

SSS-73
Select Objects ekranına view geldi, Ok ile devam ediyoruz.
Securables ekranına view geldi. Görüldüğü detaylı bir yetkilendirme var, sadece Select ve
View Definition’a Grant yetkisi verip Ok diyorum.
SSS-74
View üzerinde sağ klik Edit top 200 rows diyelim, verilerde değişiklik yapmaya çalışalım.
SSS_75
Edit yetkisi olmadığı için izin vermedi.
View’i komple silmeye çalışalım.

SSS_76
Yetki olmadığı için silmeye izin vermedi.
Technet: http://technet.microsoft.com/en-us/library/ms190785(v=sql.105).aspx
Sql Server’da kullanıcı yetkilerinin ne kadar detaylı olduğunu görmüş olduk. Genelde
uğraşmamak için loginlere sysadmin yetkisi verilir. Firmaya yeni bir yazılım alınır, yazılımcı
firma Sql de bir kullanıcı ister ve Sql kullanıcısı sysadmin olarak açılır. Genel senaryo bu
şekilde oluşur, siz farkında olmadan verilerinizi başka bir firmadaki kişiye teslim etmiş
oluyorsunuz. Bir yanlışlık yapıldığında da geri dönülmesi zor hatalara yol açabilir.
Saldırganlarda bu açıklardan faydalanarak, sql loginlerindeki yetkileri kontrol ederler. Gerekli
tedbirler alınmayan sistemlerde saldırgan, kıyıda köşede kalmış bir Sql hesabı ile istediği
zararı verebilir.