Veritabanı Altyapısı izinlerini kullanmaya başlama

Şunlar için geçerlidir:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsAnalitik Platform Sistemi (PDW)Microsoft Fabric'te SQL veritabanı

Bu makalede bazı temel güvenlik kavramları gözden geçirilip izinlerin tipik bir uygulaması açıklanmaktadır. Veritabanı Altyapısı'ndaki izinler, oturum açma bilgileri ve sunucu rolleri aracılığıyla sunucu düzeyinde , veritabanı düzeyinde ise veritabanı kullanıcıları ve veritabanı rolleri aracılığıyla yönetilir.

Microsoft Fabric'teki SQL Veritabanı ve SQL Veritabanı her veritabanında aynı seçenekleri sunar, ancak sunucu düzeyindeki izinler mevcut değildir.

• SQL Veritabanı'nda Öğretici: Azure SQL Veritabanı'nda veritabanının güvenliğini sağlama bölümüne bakın. Microsoft Entra Id kimlik doğrulaması önerilir. Daha fazla bilgi için bkz . Öğretici: Microsoft Entra uygulamalarını kullanarak Microsoft Entra kullanıcıları oluşturma.

• Microsoft Fabric'teki SQL veritabanında veritabanı kullanıcıları için desteklenen tek kimlik doğrulama yöntemi Microsoft Entra Id'dir. Sunucu düzeyinde roller ve izinler kullanılamaz. Daha fazla bilgi için bkz. Microsoft Fabric SQL veritabanında yetkilendirme.

Note

Microsoft Entra Id daha önce Azure Active Directory (Azure AD) olarak biliniyordu.

Güvenlik sorumluları

Güvenlik sorumlusu, SQL Server'ın kullandığı kimliktir ve eylem gerçekleştirme izni atanabilir. Güvenlik sorumluları genellikle kişi veya kişi gruplarıdır, ancak kişiymiş gibi davranan diğer varlıklar olabilir. Güvenlik sorumluları, bu makalede gösterilen Transact-SQL örnekleri kullanılarak veya SQL Server Management Studio kullanılarak oluşturulabilir ve yönetilebilir.

Logins

Oturum açma bilgileri , SQL Server Veritabanı Altyapısı'nda oturum açmak için tek tek kullanıcı hesaplarıdır. SQL Server ve SQL Veritabanı, Windows kimlik doğrulamasına dayalı oturum açma bilgilerini ve SQL Server kimlik doğrulamasına dayalı oturum açma bilgilerini destekler. İki oturum açma türü hakkında bilgi için bkz. Kimlik doğrulama modu seçme.

Sunucu rolleri düzeltildi

SQL Server'da sabit sunucu rolleri , sunucu düzeyinde izinlerden oluşan kullanışlı bir grup sağlayan önceden yapılandırılmış bir rol kümesidir. Girişler, ALTER SERVER ROLE ... ADD MEMBER deyimi kullanılarak rollere eklenebilir. Daha fazla bilgi için bkz. ALTER SERVER ROLE. SQL Veritabanı sabit sunucu rollerini desteklemez, ancak veritabanında sunucu rolleri gibi davranan iki rol master (dbmanager ve loginmanager) vardır.

Kullanıcı tanımlı sunucu rolleri

SQL Server'da kendi sunucu rollerinizi oluşturabilir ve bunlara sunucu düzeyinde izinler atayabilirsiniz. Oturum açma bilgileri, deyimi kullanılarak ALTER SERVER ROLE ... ADD MEMBER sunucu rollerine eklenebilir. Daha fazla bilgi için bkz. ALTER SERVER ROLE. SQL Veritabanı, kullanıcı tanımlı sunucu rollerini desteklemez.

Veritabanı kullanıcıları

Bir veritabanında oturum açma erişimi vermek için, bu veritabanında bir veritabanı kullanıcısı oluşturur ve veritabanı kullanıcısını oturum açma bilgileriyle eşlersiniz. Veritabanı kullanıcı adı genellikle kurala göre oturum açma adıyla aynıdır, ancak aynı olması gerekmez. Her veritabanı kullanıcısı tek bir girişle bağlanır. Oturum açma bilgileri veritabanındaki yalnızca bir kullanıcıyla eşlenebilir, ancak birkaç farklı veritabanında veritabanı kullanıcısı olarak eşlenebilir.

Buna karşılık gelen oturum açma bilgileri olmayan veritabanı kullanıcıları da oluşturulabilir. Bu kullanıcılar , bağımsız veritabanı kullanıcıları olarak adlandırılır. Microsoft, veritabanınızı farklı bir sunucuya taşımayı kolaylaştırdığından, bağımsız veritabanı kullanıcılarının kullanılmasını teşvik eder. Oturum açma gibi, sınırlı veritabanı kullanıcısı da Windows kimlik doğrulaması veya SQL Server kimlik doğrulaması kullanabilir. Daha fazla bilgi için bkz. Veritabanınızı kapsanan veritabanlarını kullanarak taşınabilir hale getirme.

Kimlik doğrulaması ve kimleri temsil ettikleri konusunda küçük farkları olan 12 kullanıcı türü vardır. Kullanıcıların listesini görmek için bkz. CREATE USER.

Veritabanı rolleri düzeltildi

Veritabanı rolleri , veritabanı düzeyinde izinlerden oluşan kullanışlı bir grup sağlayan önceden yapılandırılmış roller kümesidir. Veritabanı kullanıcıları ve kullanıcı tanımlı veritabanı rolleri, deyimi kullanılarak ALTER ROLE ... ADD MEMBER sabit veritabanı rollerine eklenebilir. Daha fazla bilgi için bkz. ALTER ROLE.

Kullanıcı tanımlı veritabanı rolleri

İzine CREATE ROLE sahip kullanıcılar, ortak izinlere sahip kullanıcı gruplarını temsil etmek için yeni kullanıcı tanımlı veritabanı rolleri oluşturabilir. Genellikle izinler rolün tamamına verilir veya reddedilir; bu da izin yönetimini ve izlemeyi basitleştirir. Veritabanı kullanıcıları, veritabanı rollerine ALTER ROLE ... ADD MEMBER komutunu kullanarak eklenebilir. Daha fazla bilgi için bkz. ALTER ROLE.

Diğer sorumlular

Burada tartışılmayan diğer güvenlik sorumluları arasında uygulama rolleri, sertifikalara veya asimetrik anahtarlara dayalı oturum açma bilgileri ve kullanıcılar yer alır.

Windows kullanıcıları, Windows grupları, oturum açma bilgileri ve veritabanı kullanıcıları arasındaki ilişkileri gösteren bir grafik için bkz. Veritabanı kullanıcısı oluşturma.

Tipik senaryo

Aşağıdaki örnek, izinleri yapılandırmak için yaygın ve önerilen bir yöntemi temsil eder.

Windows Active Directory'de veya Microsoft Entra Id'de

1. Her kişi için bir kullanıcı oluşturun.
2. İş birimlerini ve iş işlevlerini temsil eden Windows grupları oluşturun.
3. Windows kullanıcılarını Windows gruplarına ekleyin.

Kullanıcı birçok veritabanına bağlanacaksa

1. Windows grupları için oturum açma bilgileri oluşturun. (SQL Server kimlik doğrulamasını kullanıyorsanız Active Directory adımlarını atlayın ve burada SQL Server kimlik doğrulaması oturum açma bilgileri oluşturun.)

2. Kullanıcı veritabanında, Windows gruplarını temsil eden oturum açma bilgileri için bir veritabanı kullanıcısı oluşturun.

3. Kullanıcı veritabanında, her biri benzer bir işlevi temsil eden bir veya daha fazla kullanıcı tanımlı veritabanı rolü oluşturun. Örneğin, finansal analist rolünüz ve satış analisti rolünüz olabilir.

4. Veritabanı kullanıcılarını bir veya daha fazla kullanıcı tanımlı veritabanı rolüne ekleyin.

5. Kullanıcı tanımlı veritabanı rollerine izinler verin.

Kullanıcı yalnızca bir veritabanına bağlanıyorsa

1. Kullanıcı veritabanında, Windows grubu için bir bağımsız veritabanı kullanıcısı oluşturun. (SQL Server kimlik doğrulaması kullanıyorsanız Active Directory adımlarını atlayın ve burada bağımsız veritabanı kullanıcısı SQL Server kimlik doğrulaması oluşturun.)

2. Kullanıcı veritabanında, her biri benzer bir işlevi temsil eden bir veya daha fazla kullanıcı tanımlı veritabanı rolü oluşturun. Örneğin, finansal analist rolünüz ve satış analisti rolünüz olabilir.

3. Veritabanı kullanıcılarını bir veya daha fazla kullanıcı tanımlı veritabanı rolüne ekleyin.

4. Kullanıcı tanımlı veritabanı rollerine izinler verin.

Bu noktada elde edilen tipik sonuç, bir Windows kullanıcısının bir Windows grubunun üyesi olmasıdır. Windows grubunun SQL Server veya SQL Veritabanı'nda oturum açma bilgileri vardır. Oturum açma, kullanıcı veritabanındaki bir kullanıcı kimliğiyle eşlenir. Kullanıcı bir veritabanı rolünün üyesidir. Şimdi role izin eklemeniz gerekir.

İzin atama

İzin deyimlerinin çoğu aşağıdaki biçime sahiptir:

<authorization> <permission> ON <securable>::<name> TO <principal>;

• <authorization> GRANT olmalıdır, REVOKE, veya DENY.

• , <permission> izin ettiğiniz veya yasakladığınız eylemi oluşturur. TAM izin sayısı SQL Server ile Azure SQL Veritabanı arasında farklılık gösterir. İzinler hakkında bilgi için İzinler (Veritabanı Altyapısı) bölümüne bakın ve bu makalenin devamındaki grafiğe bakın.

• ON <securable>::<name> , güvenli hale getirilebilir (sunucu, sunucu nesnesi, veritabanı veya veritabanı nesnesi) türü ve adıdır. Bazı izinler, bağlam içinde açık veya uygun olmadığı için <securable>::<name> gerektirmez. Örneğin, CREATE TABLE izin yan tümcesini <securable>::<name> gerektirmez (GRANT CREATE TABLE TO Mary; Mary'nin tablo oluşturmasına izin verir).

• <principal> , izni alan veya kaybeden güvenlik sorumlusudur (oturum açma, kullanıcı veya rol). Mümkün olduğunda rollere izin verin.

Aşağıdaki örnek deyim, UPDATE şemasında yer alan Parts tablosu veya görünümüne Production iznini PartsTeam adlı role verir.

GRANT UPDATE ON OBJECT::Production.Parts TO PartsTeam;

Aşağıdaki örnek deyim, UPDATE şeması üzerinde ve bu şemanın içinde yer alan herhangi bir tablo veya görünüm üzerinde Production iznini, adı ProductionTeam olan role verir. Bu, tek tek nesne düzeyinde izin vermekten daha etkili ve ölçeklenebilir bir izin atama yaklaşımıdır.

GRANT UPDATE ON SCHEMA::Production TO ProductionTeam;

güvenlik sorumlularına (oturum açma bilgileri, kullanıcılar ve roller) deyimi kullanılarak GRANT izinler verilir. DENY komutu kullanılarak izinler açık bir şekilde reddedilir. Daha önce verilen veya reddedilen izin, REVOKE deyimi kullanılarak kaldırılır. İzinler kümülatiftir; kullanıcı kullanıcıya, oturum açma bilgilerine ve tüm grup üyeliklerine verilen tüm izinleri alır; ancak herhangi bir izin reddi tüm izinleri geçersiz kılar.

Caution

Yaygın bir hata, GRANT yerine DENY kullanarak REVOKE öğesini kaldırmaya çalışmaktır. Bu durum, bir kullanıcı birden çok kaynaktan izin aldığında sorunlara neden olabilir ve bu yaygın bir senaryo olabilir. Aşağıdaki örnekte ilke gösterilmektedir.

Satış grubu, SELECT deyimi aracılığıyla OrderStatus tablosunda GRANT SELECT ON OBJECT::OrderStatus TO Sales; izinlerini alır. Kullanıcı Jae rolün Sales bir üyesidir. Jae'ye, kendi kullanıcı adı altında tablo SELECT için OrderStatus ifadesi aracılığıyla GRANT SELECT ON OBJECT::OrderStatus TO Jae; izni de verilmiştir. Yöneticinin GRANT öğesini Sales rolünden çıkarmak istediğini varsayın.

• Yönetici REVOKE SELECT ON OBJECT::OrderStatus TO Sales; komutunu doğru şekilde yürütürse, Jae kendi bireysel SELECT deyimi aracılığıyla OrderStatus tablosuna GRANT erişimi korur.

• Eğer yönetici DENY SELECT ON OBJECT::OrderStatus TO Sales;’i yanlış şekilde yürütürse, Sales rolünün bir üyesi olarak Jae'ye SELECT’ün DENY’e öncelik tanıması nedeniyle Sales izni verilmez; bu, Jae'nin kendi bireysel GRANT’ini geçersiz kılar.

Note

İzinler Management Studio kullanılarak yapılandırılabilir. Nesne Gezgini'nde güvenli hale getirilebilir öğesini bulun, güvenli hale getirilebilene sağ tıklayın ve özellikler'i seçin. İzinler sayfasını seçin. İzin sayfasını kullanma hakkında yardım için bkz. İzinler veya Güvenlik Öğeleri Sayfası.

İzin hiyerarşisi

İzinlerin ebeveyn/çocuk hiyerarşisi vardır. Bir veritabanında SELECT izni verirseniz, bu izin veritabanındaki tüm (alt) şemalar üzerinde SELECT iznini içerir. Bir şemada SELECT izni verirseniz, bu şemadaki tüm (alt) tablolar ve görünümler üzerinde SELECT iznini içerir. İzinler geçişli: Bir veritabanına SELECT izni verdiğinizde, bu SELECT izin tüm (alt) şemalar ve tüm (çocuk-alt) tablolar ve görünümler için de geçerlidir.

İzinlerin örtüştüğü izinler de vardır. Bir CONTROL nesne üzerindeki izin normalde nesne üzerinde diğer tüm izinleri verir.

Hem üst/alt hiyerarşi hem de kapsayan hiyerarşi aynı izne göre hareket ettiğinden, izin sistemi karmaşık olabilir. Örneğin, bir veritabanındaki (Region) bir şemada (Customers) bir tabloyu (SalesDB) ele alalım.

• CONTROL tablosundaki Region izni, Region tablodaki diğer tüm izinleri, ALTER, SELECT, INSERT, UPDATE, DELETE ve bazı diğer izinler de dahil olmak üzere içerir.

• SELECT şema üzerinde Customers sahibi olduğu Region tablo, SELECT tablosu üzerindeki Region iznini içerir.

Bu nedenle SELECT tablo üzerindeki Region izin şu altı deyimden herhangi biri aracılığıyla elde edilebilir:

GRANT SELECT ON OBJECT::Region TO Jae;

GRANT CONTROL ON OBJECT::Region TO Jae;

GRANT SELECT ON SCHEMA::Customers TO Jae;

GRANT CONTROL ON SCHEMA::Customers TO Jae;

GRANT SELECT ON DATABASE::SalesDB TO Jae;

GRANT CONTROL ON DATABASE::SalesDB TO Jae;

En az izin ver

Daha önce listelenen ilk izin (GRANT SELECT ON OBJECT::Region TO Jae;), en ayrıntılı izindir. Bu deyim, SELECT'e verilen mümkün olan en az izindir. Alt nesnelere yönelik izinler onunla birlikte gelmez. Her zaman mümkün olan en az izni vermek iyi bir ilkedir, ancak verme sistemini basitleştirmek için daha yüksek düzeylerde izin vermeyi düşünmelisiniz.

Bu nedenle, Jae'nin şemanın tamamı için izne ihtiyacı varsa, izni şema düzeyinde bir kez SELECT olarak verin, tabloda veya görünüm düzeyinde SELECT olarak birçok kez vermek yerine. Veritabanının tasarımı, bu stratejinin ne kadar başarılı olabileceğini önemli ölçüde etkileyebilir. Bu strateji, veritabanınız aynı izinlere ihtiyaç duyan nesnelerin tek bir şemaya eklenmesi için tasarlandığında en iyi sonucu verir.

Tip

Bir veritabanını ve nesnelerini tasarlarken, uygulamaların ve kullanıcıların bu nesnelere nasıl eriştiği baştan planlayın. Şemaları kullanarak tablolara, görünümlere, işlevlere ve saklı yordamlara erişimi denetlemek için bu bilgileri kullanın. Şemalar, erişim türlerini daha kolay gruplandırmanıza olanak sağlar.

İzinlerin diyagramı

Aşağıdaki görüntüde izinler ve birbirleriyle ilişkileri gösterilmektedir. Üst düzey izinlerden bazıları (CONTROL SERVERgibi) birçok kez listelenir. Bu makalede poster okunamayacak kadar küçük. Tam boyutlu Veritabanı Altyapısı İzinleri Posteri PDF biçiminde indirebilirsiniz.

Veritabanı Altyapısı sorumluları ile sunucu ve veritabanı nesneleri arasındaki ilişkileri gösteren bir grafik için bkz. İzinler Hiyerarşisi (Veritabanı Altyapısı).

İzinler ile sabit sunucu ve sabit veritabanı rolleri karşılaştırması

Sabit sunucu rollerinin ve sabit veritabanı rollerinin izinleri ayrıntılı izinlere benzer ancak tam olarak aynı değildir. Örneğin, sysadmin sabit sunucu rolünün üyeleri, izinle CONTROL SERVER oturum açma işlemleri gibi SQL Server örneğinde de tüm izinlere sahiptir.

Ancak, CONTROL SERVER izninin verilmesi bir oturum açma işlemine sysadmin sabit sunucu rolü üyeliği kazandırmaz ve oturum açma işlemini sysadmin sabit sunucu rolüne eklemek oturum açma işlemine CONTROL SERVER iznini açıkça vermez. Bazen saklı yordam, detaylı izni denetlemeden yalnızca sabit rolü kontrol ederek izinleri denetler.

Örneğin, veritabanını ayırmak için db_owner sabit veritabanı rolüne üyelik gerekir. CONTROL DATABASE Eşdeğer izin yeterli değildir. Bu iki sistem paralel olarak çalışır ancak nadiren birbirleriyle etkileşim kurar. Microsoft mümkün olduğunda sabit roller yerine daha yeni, ayrıntılı izin sisteminin kullanılmasını önerir.

İzinleri izleme

Aşağıdaki görünümler güvenlik bilgilerini döndürür. Güvenlikle ilgili tüm görünümler için bkz. Güvenlik Kataloğu Görünümleri (Transact-SQL).

View	Description
sys.server_principals 1	Bir sunucuda oturum açma bilgileri ve kullanıcı tanımlı sunucu rolleri
sys.database_principals	Veritabanındaki kullanıcılar ve kullanıcı tanımlı roller
sys.server_permissions 1	Oturum açma bilgilerine ve kullanıcı tanımlı sabit sunucu rollerine verilen izinler
sys.database_permissions	Kullanıcılara verilen izinler ve kullanıcı tanımlı sabit veritabanı rolleri
sys.database_role_members	Veritabanı rol türü üyeliği
sys.server_role_members 1	Sunucu rolü üyeliği

¹ Bu görünüm SQL Veritabanı'nda kullanılamaz.

Examples

Aşağıdaki ifadeler izinler hakkında yararlı bilgiler sağlar.

A. Her kullanıcı için veritabanı izinleri listesi

Veritabanında (SQL Server ve SQL Veritabanı) verilen veya reddedilen açık izinleri döndürmek için veritabanında aşağıdaki Transact-SQL deyimini çalıştırın.

SELECT perms.state_desc AS State,
       permission_name AS [Permission],
       obj.name AS [on Object],
       dp.name AS [to User Name]
FROM sys.database_permissions AS perms
     INNER JOIN sys.database_principals AS dp
         ON perms.grantee_principal_id = dp.principal_id
     INNER JOIN sys.objects AS obj
         ON perms.major_id = obj.object_id;

B. Sunucu rolü üyelerini listeleme

Sunucu rollerinin üyelerini döndürmek için (yalnızca SQL Server), aşağıdaki deyimi çalıştırın.

SELECT roles.principal_id AS RolePrincipalID,
       roles.name AS RolePrincipalName,
       server_role_members.member_principal_id AS MemberPrincipalID,
       members.name AS MemberPrincipalName
FROM sys.server_role_members AS server_role_members
     INNER JOIN sys.server_principals AS roles
         ON server_role_members.role_principal_id = roles.principal_id
     LEFT OUTER JOIN sys.server_principals AS members
         ON server_role_members.member_principal_id = members.principal_id;

C. Veritabanı düzeyinde bir rolün üyesi olan tüm veritabanı sorumlularını listeleme

Veritabanı rollerinin (SQL Server ve SQL Veritabanı) üyelerini döndürmek için veritabanında aşağıdaki deyimi çalıştırın.

SELECT dRole.name AS [Database Role Name],
       dp.name AS [Members]
FROM sys.database_role_members AS dRo
     INNER JOIN sys.database_principals AS dp
         ON dRo.member_principal_id = dp.principal_id
     INNER JOIN sys.database_principals AS dRole
         ON dRo.role_principal_id = dRole.principal_id;

İlgili içerik

• SQL Server Veritabanı Altyapısı ve Azure SQL Veritabanı Güvenliği
• Güvenlik İşlevleri (Transact-SQL)
• Güvenlikle İlgili Dinamik Yönetim Görünümleri ve İşlevleri (Transact-SQL)
• Güvenlik Kataloğu Görünümleri (Transact-SQL)
• sys.fn_builtin_permissions (Transact-SQL)
• Geçerli Veritabanı Altyapısı izinlerini belirleme
• Öğretici: Veritabanı Altyapısını Kullanmaya Başlama
• 1. Ders: Veritabanı nesneleri oluşturma ve sorgulama
• SQL Server Management Studio Eğitimi
• Eğitici: Transact-SQL deyimleri yazma