DDL_admin vs db_owner izinleri

Sunucu grubumuzdaki tüm veritabanı kullanıcılarının izinlerini kaldırma ve sınırlama içeren bir projeyi ele alıyorum. (eğlenceli zamanlar)

Şu anda sınırlı olan izinlerden biri db_owner izinleridir.
Bu izin, duruma göre incelenmektedir, ancak ortak bir değişiklik, db_owner izinlerini aşağıdaki ile değiştirmektir:

• db_datareader
• db_datawriter
• db_ddladmin
• db_executor

İkisi arasındaki kesin farkı tanımlamak istiyorum (müşterileri bilgilendirmek için).
Ancak, söyleyebildiğim kadarıyla, ikisi arasındaki fark şöyle olmalıdır:

• db_accessadmin izinleri
• db_backupoperator izinleri
• db_securityadmin izinleri

Yani yürürlükte onlar kaybedecek:
[ALTER ANY USER]
[CREATE SCHEMA]
[BACKUP DATABASE], [BACKUP LOG], [CHECKPOINT]
[ALTER ANY APPLICATION ROLE],[ALTER ANY ROLE]
[DROP DATABASE]

Db_owner, yukarıdaki dört rolle değiştirildikten sonra kullanıcının kaybedeceği başka bir şey var mı?
Bu aslında akıllıca bir amaca hizmet eder mi?

db_ddladmin vs db_owner

Test ettiğim ve okuduğum şeyden anlatabildiğim kadarıyla, listeniz doğru görünüyor, ancak db_ddladminizin vermeniz dışında CREATE SCHEMA. Listelediğiniz diğer güvenlik izinlerinin gerçekten reddedildiğini onayladım.

Yalnızca DDLADMIN ile reddedildi:

[ALTER ANY USER]

[BACKUP DATABASE], [BACKUP LOG],[CHECKPOINT]

[ALTER ANY APPLICATION ROLE], [ALTER ANY ROLE]

[DROP DATABASE]

Dikkat çeken. . .

1. db_datareaderSELECTtüm tablolara erişime izin verecek
2. db_datarwritertüm tablolara izin verir INSERT, UPDATEve DELETEerişir
3. db_executorEXECUTEtüm yürütülebilir nesnelere erişime izin verir

Ayrıca, db_ddladmin rol izinlerine sahip olmak anlamına gelebilir. . .

Not: 2005 - 2014 arasında SQL Server'ın birçok farklı sürümüne sahip olduğunuzdan, küçük bir kullanıcı grubunun başlangıçta bunu test etmek için kimin çığlık attığını görmek için en iyisi olabilir.

• Bu rolle sahip oldukları nesneler DBO'ya ait olmayacaktır, bu nedenle bu düzeyde bir sorunla karşılaşırsanız sahiplik değiştirme sorunlarıyla uğraşmanız gerekebilir. Bunun bir sorun olacağından% 100 emin değilim ama durumdan bahsetmeye değer.

  Kaynak: Mülkiyet Zincirleri

• Bu rolle (SQL Server sürümüne bağlı olarak değişebilir) , geçerli DB'de tanımlanan SQL güvenlik ilkelerini, sahip oldukları nesnelere ekleyebilir, yalnızca tüm nesnelere (sahip olmadıklarına) veya yeni bir sunucu ekleyebilir -düzeyinde tanımlanan düzey DB düzeyi.

Ayrıca, DBO rol izinlerine sahip olmama anlamına gelebilir. . .

Not: 2005 - 2014 arasında SQL Server'ın birçok farklı sürümüne sahip olduğunuzdan, küçük bir kullanıcı grubunun başlangıçta bunu test etmek için kimin çığlık attığını görmek için en iyisi olabilir.

• DBO rolüne sahip olmamanız , T-SQL çalışmaları aracılığıyla yapılmasına rağmen bazı SSMS tasarımcı GUI arabirimlerinin (SQL Server sürümü değişir) hatasız olarak doldurulmasını veya açılmasını önleyebilir (örn. GUI aracılığıyla tabloları veya sütunları değiştirirken) ve izinler yerinde . SQL Server'ın bazı sürümlerinde GRANT VIEW DEFINITIONbu, sorunun nerede olduğu ve bu nedenle yalnızca SQL Server'ın belirli sürümlerinde bir uyarı olabilmesiyle çözülebilir .

  kaynaklar

  • Veritabanı sahibi veya db_owner rolünün üyesi olan bir kullanıcı olarak oturum açmadınız. Sahip olmadığınız tablolarda yapılan değişiklikleri kaydedemezsiniz.

  • db_ddladmin Rolü, SSMS'de "tasarım" işlevlerinin kullanılmasına izin vermez

    _{"Kullanıcılara / geliştiricilere KG veritabanlarında dbo verebildiğimiz kadar vermemeye çalışıyoruz. Bununla ilgili sorunlardan biri, kullanıcı tabloları gibi veritabanı nesneleri oluşturmaları ve değiştirmeleri gerektiğidir. Birçok geliştirici yeni MS SQL ve böylece bu tür bir çalışma için GUI (SSMS) ile sopa eğilimindedir.Sorun onlara db_ddladmin (dbo değil) vermek ve artık tablo tasarımcısı GUI aracılığıyla tabloları veya sütunları değiştirmek mümkün olduğunda ortaya çıkar. TSQL komutlarını ve sözdizimlerini (bir daha asla ihtiyaç duymayacakları) öğrenmek veya diğer faaliyetlerimizden zaman alan DBA ekibine katılmak için ek zaman ayırmalıdırlar.}

    _{Bu bir hata veya bir özellik isteği olup olmadığını bilmiyorum ama kullanıcı TSQL üzerinden tablo değiştirmek için yeterli izinlere sahip ama GUI onlara belirten iletileri verir çünkü bir hata olarak kabul:}

    _{" Veritabanı sahibi veya sistem yöneticisi olarak oturum açmadınız. Sahip olmadığınız tablolardaki değişiklikleri kaydedemeyebilirsiniz." AND "Tablo [schema].[table]salt okunur olarak ayarlandı, kullanıcının bu tabloda yeterli hakları yok. "}

    _{Bir izleme, gerçekte nesneyi değiştirme izinlerine sahip olmalarına rağmen, db_ddladmin üyelerini engelleyecek bir is_member ('db_owner') olduğunu gösteriyor. Microsoft SQL Server Management Studio "}

    ---

    _{Ajan DBA tarafından 1/25/2010 tarihinde 07:06 tarihinde gönderildi}

    _{Benzer bir sorunum vardı ve aşağıdaki hibeyi uygulayarak çözmeyi başardım}

    GRANT view definition on schema:: <schemaname> to <username>

Diğer Hususlar

Bunun duruma göre incelendiğini belirttiğiniz için

Şu anda sınırlı olan izinlerden biri db_owner izinleridir.

Bu izin, duruma göre incelenmektedir, ancak ortak bir değişiklik, db_owner izinlerini aşağıdaki ile değiştirmektir:

• db_datareader
• db_datawriter
• db_ddladmin
• db_executor

db_ddladminMuhtemelen onlara aslında DB seviye nesnelerine ihtiyaç duyduklarından daha fazlasını verecekleri rol vermek yerine, her kişinin ihtiyaç duyduğu daha fazla "tüm nesne" DB düzeyinde erişim için ek özel roller oluşturmayı düşündünüz mü?

Genellikle tam olarak neye ihtiyaç duyulduğunu verir ve işlerini yapmaları için daha fazla bir şey vermez ve bir DB'deki tüm nesnelere DB düzeyinde nesne erişimi için "olağan" veya "standart" bir gereksinim varsa, db_executorama aşağıdaki örneğime bakın. Bu şekilde, DB'lerinizde güvenlik için nesne düzeyinde açık bir şekilde alamıyorsanız, insanlara belirli bir DB'deki TÜM DB nesnesine gerçekten ihtiyaç duydukları şeyi verebilirsiniz.

----Custom Database Roles

/* CREATE A NEW ROLE  -- Execute to all stored procs including newly created ones*/
-- Database specific
CREATE ROLE db_All_StoredProc_Execute
GRANT EXECUTE TO db_All_StoredProc_Execute

/* CREATE A NEW ROLE  -- Alter to all stored procs including newly created ones*/
-- Database specific
CREATE ROLE db_All_StoredProc_Alter
GRANT ALTER ANY SCHEMA TO db_All_StoredProc_Alter

/* CREATE A NEW ROLE  -- View Definition to all stored procs including newly created ones*/
-- Database specific
CREATE ROLE db_All_StoredProc_View
GRANT VIEW DEFINITION TO db_All_StoredProc_View

/* CREATE A NEW ROLE - Any schema alter and create procedure permissions */
-- Database specific
CREATE ROLE db_All_CreateProc_AlterSchema
GRANT ALTER ANY SCHEMA TO db_All_CreateProc_AlterSchema
GRANT CREATE PROCEDURE TO db_All_CreateProc_AlterSchema
GO

/* CREATE A NEW ROLE - Any schema alter and create table permissions */
-- Database specific
CREATE ROLE db_All_CreateTable_AlterSchema
GRANT ALTER ANY SCHEMA TO db_All_CreateTable_AlterSchema
GRANT CREATE TABLE TO db_All_CreateTable_AlterSchema

/* CREATE A NEW ROLE - Any schema alter and create function permissions */
-- Database specific
CREATE ROLE db_All_CreateFunction_AlterSchema
GRANT ALTER ANY SCHEMA TO db_All_CreateFunction_AlterSchema
GRANT CREATE FUNCTION TO db_All_CreateFunction_AlterSchema

/* CREATE A NEW ROLE - Any schema alter and create aggregate permissions */
-- Database specific
CREATE ROLE db_All_CreateAggregate_AlterSchema
GRANT ALTER ANY SCHEMA TO db_All_CreateAggregate_AlterSchema
GRANT CREATE AGGREGATE TO db_All_CreateAggregate_AlterSchema

/* CREATE A NEW ROLE - Any schema alter and create view permissions */
-- Database specific
CREATE ROLE db_All_CreateView_AlterSchema
GRANT ALTER ANY SCHEMA TO db_All_CreateView_AlterSchema
GRANT CREATE VIEW TO db_All_CreateView_AlterSchema

/* CREATE A NEW ROLE - Any schema alter and create schema permissions */
-- Database specific
CREATE ROLE db_All_CreateSchema_AlterSchema
GRANT ALTER ANY SCHEMA TO db_All_CreateSchema_AlterSchema
GRANT CREATE SCHEMA TO db_All_CreateSchema_AlterSchema

Ayrıca , en azından onlara bu rolü verdiğiniz ve gerçek nesne türleri için açık olarak ayarlayabileceğiniz DB'lerde bu öğeye erişim vermeyi DENYkısıtlamak için açıkça oluşturmayı düşünmek isteyebileceğiniz bir db_DDLAdmin_Restriction rolünü paylaşmak istedim. vb. erişmelerini istemezsiniz.db_ddladminDENY

Örneğin, biliyorsanız onlar kesinlikle saklı prosedürler ve fonksiyonlar yaratmak olun, hariç tutabilir olacak DENY CREATE FUNCTION, DENY CREATE PROCEDURE, DENY ALTER ANY SCHEMA.

---Create ddladmin restriction custom DB role
DENY ALTER ANY ASSEMBLY                    TO db_DDLAdmin_Restriction
DENY ALTER ANY ASYMMETRIC KEY              TO db_DDLAdmin_Restriction
DENY ALTER ANY CERTIFICATE                 TO db_DDLAdmin_Restriction
DENY ALTER ANY CONTRACT                    TO db_DDLAdmin_Restriction
DENY ALTER ANY DATABASE DDL TRIGGER        TO db_DDLAdmin_Restriction
DENY ALTER ANY DATABASE EVENT NOTIFICATION TO db_DDLAdmin_Restriction
DENY ALTER ANY DATASPACE                   TO db_DDLAdmin_Restriction
DENY ALTER ANY FULLTEXT CATALOG            TO db_DDLAdmin_Restriction
DENY ALTER ANY MESSAGE TYPE                TO db_DDLAdmin_Restriction
DENY ALTER ANY REMOTE SERVICE BINDING      TO db_DDLAdmin_Restriction
DENY ALTER ANY ROUTE                       TO db_DDLAdmin_Restriction
DENY ALTER ANY SCHEMA                      TO db_DDLAdmin_Restriction
DENY ALTER ANY SERVICE                     TO db_DDLAdmin_Restriction
DENY ALTER ANY SYMMETRIC KEY               TO db_DDLAdmin_Restriction
DENY CHECKPOINT                            TO db_DDLAdmin_Restriction
DENY CREATE AGGREGATE                      TO db_DDLAdmin_Restriction
DENY CREATE DEFAULT                        TO db_DDLAdmin_Restriction
DENY CREATE FUNCTION                       TO db_DDLAdmin_Restriction
DENY CREATE PROCEDURE                      TO db_DDLAdmin_Restriction
DENY CREATE QUEUE                          TO db_DDLAdmin_Restriction
DENY CREATE RULE                           TO db_DDLAdmin_Restriction
DENY CREATE SYNONYM                        TO db_DDLAdmin_Restriction
DENY CREATE TABLE                          TO db_DDLAdmin_Restriction
DENY CREATE TYPE                           TO db_DDLAdmin_Restriction
DENY CREATE VIEW                           TO db_DDLAdmin_Restriction
DENY CREATE XML SCHEMA COLLECTION          TO db_DDLAdmin_Restriction
DENY REFERENCES                            TO db_DDLAdmin_Restriction
GO

Tüm izinleri listelemek için bir SQL Script kullanarak, her vaka için kullanıcılar oluşturdum.

EXECUTE AS USER = 'test_user'
SELECT 
    permission_name 
FROM fn_my_permissions(null, 'DATABASE')
ORDER BY subentity_name, permission_name
REVERT;

Daha sonra sonuçları karşılaştırdım ve aşağıdaki listeye, öncelikle msdn'den (özellikle referans edilmeyen herhangi bir alıntı msdn bağlantısından) belgelerle geldim .
Aşağıda, dbo izinlerini kaybedecek olan kişileri tam olarak ne kaybettiklerini bildirmek için kullandığım bazı belgeler var .

alter

Belirli bir güvenli olanın mülkiyeti hariç özelliklerini değiştirme yeteneği kazandırır. Bir kapsamda verildiğinde, ALTER, bu kapsamda bulunan herhangi bir güvenilirliği değiştirme, oluşturma veya bırakma yeteneğini de verir. Örneğin, bir şemadaki ALTER izni, şemadan nesne oluşturma, değiştirme ve bırakma yeteneğini içerir.

HERHANGİ BİR UYGULAMA ROLÜ
DEĞİŞTİRME HERHANGİ BİR VERİTABANI DENETİMİ
HERHANGİ BİR ROLÜ
HERHANGİ BİR KULLANICI DEĞİŞTİR

Güvenli Veritabanı tek tek örnekleri OLUŞTURMA, ALTER veya DROP yeteneği sunar. Örneğin, ALTER ANY SCHEMA veritabanında herhangi bir şema oluşturma, değiştirme veya bırakma yeteneği sağlar.

Uygulama rolleri , uygulamanın kendi kullanıcı benzeri izinleriyle çalışmasını sağlayan veritabanı ilkeleridir.

SQL Server veya SQL Server veritabanının bir örneğini denetlemek , sistemde meydana gelen olayları izleme ve günlüğe kaydetmeyi içerir. Veritabanı Düzeyinde Denetim Belirtimi nesnesi bir denetime aittir. Denetim başına SQL Server veritabanı başına bir veritabanı denetim belirtimi oluşturabilirsiniz.

Veritabanı Rolleri , veritabanlarınızdaki izinleri kolayca yönetmek için kullanılır; SQL Server, diğer ilkeleri gruplandıran güvenlik ilkeleri olan birkaç rol sağlar. Microsoft Windows işletim sistemindeki gruplar gibidirler. Veritabanı düzeyinde roller, izinler kapsamında veritabanı çapındadır.

ÖZET msdn'de
bulundu.

KİMLİK DOĞRULAMA VE KİMLİK SERVER izinleri yalnızca çapraz veritabanı ve sunucu erişimi (sırasıyla) senaryolarında EXECUTE AS kullanıldığında kullanılır.

YEDEK VERİTABANI
YEDEKLEME GÜNLÜĞÜ

BAĞLANTI TEKRARLAMA

Veritabanı çoğaltma izinleri için kullanılır .

KONTROL

Yetkilendirilene sahiplik benzeri özellikler kazandırır. Yetkilendirilen, güvenli bir şekilde tanımlanmış tüm izinlere sahiptir. CONTROL verilen bir müdür güvenli hale getirilebilir.

ROL OLUŞTUR

Güvenceye Alınan Veritabanını Güvenli Oluşturma yeteneği verir.

SHOWPLAN

Showplan izinleri, Transact-SQL toplu işleriyle kullanıldığında çeşitli Showplan SET deyimi seçenekleri için kullanılır .

ABONELİK SORGULAMA BİLDİRİMLERİ

Sorgu bildirimleriyle ilgili belgeler.

Service Broker altyapısı üzerine kurulmuş olan sorgu bildirimleri, veriler değiştiğinde uygulamaların bildirilmesine izin verir. Bu özellik, özellikle Web uygulaması gibi bir veritabanından bilgi önbelleği sağlayan ve kaynak veriler değiştirildiğinde bildirilmesi gereken uygulamalar için kullanışlıdır.

SAHİPLİĞİNİ ALMAK

Hibe alan kişinin kendisine verildiği güvenilirliğin sahipliğini almasını sağlar.

VERİTABANI DEVLETİNİ GÖRÜNTÜLE

Görüntülemek için kullanılır Dinamik yönetimi görünümler ve işlevler (Transact-SQL) .

TANIMI GÖRÜNTÜLEYİN

Görünüm tanımı izinleriyle ilgili belgeler .

GÖRÜNÜM TANIMI izni, kullanıcının izin verilen güvenliğin meta verilerini görmesini sağlar. Ancak, GÖRÜNÜM TANIMI izni güvenli olanın kendisine erişim sağlamaz. Örneğin, bir tabloda yalnızca VIEW DEFINITION izni olan bir kullanıcı, sys.objects katalog görünümünde tabloyla ilgili meta verileri görebilir. Ancak, SELECT veya CONTROL gibi ek izinler olmadan, kullanıcı tablodan veri okuyamaz.