db_ddladmin vs db_owner
Z tego, co mogę powiedzieć na podstawie tego, co przetestowałem i przeczytałem, w przeważającej części twoja lista wygląda na dokładną, z wyjątkiem tego, db_ddladminże pozwala CREATE SCHEMA. Potwierdziłem, że inne wymienione przez ciebie uprawnienia bezpieczeństwa zostały rzeczywiście odrzucone.
Odmowa tylko za pomocą DDLADMIN:
[ALTER ANY USER]
[BACKUP DATABASE], [BACKUP LOG],[CHECKPOINT]
[ALTER ANY APPLICATION ROLE], [ALTER ANY ROLE]
[DROP DATABASE]
Zauważając, że. . .
db_datareaderpozwoli na SELECTdostęp do wszystkich tabeldb_datarwriterpozwoli INSERT, UPDATEi DELETEdostęp do wszystkich tabeldb_executorpozwoli na EXECUTEdostęp do wszystkich wykonywalnych obiektów
Dodatkowo posiadanie uprawnień roli db_ddladmin może oznaczać. . .
Uwaga: Ponieważ masz tak wiele różnych wersji SQL Server z lat 2005-2014, być może najlepiej będzie, jeśli mały zestaw użytkowników przetestuje to na początku, aby zobaczyć, kto krzyczy, aby usunąć wszelkie zagięcia itp.
Obiekty, które posiadają z tą rolą, nie będą własnością DBO, więc być może będziesz musiał poradzić sobie z problemami związanymi ze zmianą własności, jeśli kiedykolwiek będzie jakiś problem z czymś na tym poziomie. Nie jestem w 100% pewien, że byłby to problem, ale warto wspomnieć na wszelki wypadek.
Źródło: Łańcuchy własności
Dzięki tej roli (mogą się różnić w zależności od wersji SQL Server) mogą oni dodawać zasady bezpieczeństwa SQL zdefiniowane w bieżącej bazie danych do obiektów, które wciąż posiadają, tylko nie wszystkie obiekty (te, których nie mają), ani dodawać nowego serwera -poziom zdefiniowany główny do poziomu DB.
Ponadto brak uprawnień do roli DBO może oznaczać. . .
Uwaga: Ponieważ masz tak wiele różnych wersji SQL Server z lat 2005-2014, być może najlepiej będzie, jeśli mały zestaw użytkowników przetestuje to na początku, aby zobaczyć, kto krzyczy, aby usunąć wszelkie zagięcia itp.
Brak roli DBO może uniemożliwić niektóre interfejsy GUI projektanta SSMS (różniąca się wersja SQL Server) bez wypełniania lub otwierania bez błędów (np. Podczas modyfikowania tabel lub kolumn za pomocą GUI), nawet jeśli robi to za pomocą T-SQL i uprawnienia są na miejscu . W niektórych wersjach SQL Server można to rozwiązać, dopuszczając, GRANT VIEW DEFINITIONgdzie jest to problem, i może to być tylko ostrzeżenie tylko w niektórych wersjach SQL Server.
Zasoby
Nie jesteś zalogowany jako właściciel bazy danych lub użytkownik będący członkiem roli db_owner. Nie będziesz mógł zapisać zmian w tabelach, których nie jesteś właścicielem.
db_ddladmin Rola nie pozwala na korzystanie z funkcji „projektowania” w SSMS
„Staramy się zapobiegać udostępnianiu użytkownikom / programistom dbo w ich bazach danych QA w jak największym stopniu. Jednym z problemów jest to, że nadal muszą być w stanie tworzyć i modyfikować obiekty bazy danych, takie jak tabele użytkowników. Wielu deweloperów jest nowością w MS SQL, a zatem mają tendencję do trzymania się GUI (SSMS) do tego rodzaju pracy. Problem pojawia się, gdy przyznamy im db_ddladmin (nie dbo) i nie są już w stanie modyfikować tabel ani kolumn za pomocą GUI projektanta tabel. muszą poświęcić dodatkowy czas na naukę poleceń TSQL i ich składni (których nigdy więcej nie będą potrzebować) lub zaangażować zespół DBA, który zabiera trochę czasu innym naszym działaniom.
Nie wiem, czy jest to błąd, czy żądanie funkcji, ale uważam to za błąd, ponieważ użytkownik ma wystarczające uprawnienia do zmiany tabeli za pomocą TSQL, ale GUI daje im komunikaty z następującymi informacjami:
„ Nie jesteś zalogowany jako właściciel bazy danych lub administrator systemu. Zapisywanie zmian w tabelach, których nie jesteś właścicielem, może być niemożliwe.” ORAZ „Tabela [schema].[table]jest ustawiona tylko do odczytu, użytkownik nie ma wystarczających uprawnień do tej tabeli ”.
Śledzenie zdaje się wskazywać, że sprawdzeniem jest is_member („właściciel_bazy_db”), co wyklucza członków db_ddladmin, mimo że w rzeczywistości mają uprawnienia do modyfikowania obiektu. Microsoft SQL Server Management Studio ”
Wysłany przez agenta DBA w dniu 25.01.2010 o 07:06
Miałem podobny problem i udało mi się go rozwiązać, wykonując następujący grant
GRANT view definition on schema:: <schemaname> to <username>
Inne uwagi
Ponieważ stwierdzasz, że jest to sprawdzane indywidualnie dla każdego przypadku
Jednym z obecnie ograniczanych uprawnień są uprawnienia db_owner.
To uprawnienie jest sprawdzane indywidualnie dla każdego przypadku, ale częstą zmianą jest zastąpienie uprawnień db_owner następującymi:
- db_datareader
- db_datawriter
- db_ddladmin
- db_executor
Czy zastanawiałeś się nad utworzeniem dodatkowych niestandardowych ról dla większego dostępu na poziomie bazy danych „wszystkich obiektów”, których potrzebuje każda osoba, zamiast przyznania im db_ddladminroli, ponieważ prawdopodobnie zapewni im to więcej, niż faktycznie potrzebuje obiektów na poziomie bazy danych.
Zazwyczaj daję to, co jest potrzebne i nic więcej, aby mogli wykonać swoją pracę, a jeśli istnieje „zwykła” lub „standardowa” potrzeba dostępu do obiektów na poziomie bazy danych do wszystkich obiektów w bazie danych, tworzę niestandardową rolę bazy danych, taką jak db_executorale zobacz mój poniższy przykład. W ten sposób możesz przyznać ludziom to, czego naprawdę potrzebują, do WSZYSTKIEGO obiektu DB w konkretnej bazie danych, jeśli poziom ochrony nie jest jawny w swoich bazach danych.
----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
Chciałem również udostępnić rolę db_DDLAdmin_Restriction, którą możesz rozważyć, aby rozważyć utworzenie inaczej z jawnym DENYograniczeniem tego, co db_ddladmindaje dostęp, abyś mógł przynajmniej utworzyć to w bazach danych, gdzie przyznajesz im tę rolę i ustawić jawne DENYdla rzeczywistych typów obiektów itp., do których nie chcesz mieć dostępu.
Na przykład, jeśli wiesz, że na pewno będzie tworzenie procedur składowanych i funkcji można wykluczyć 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
