Дозволи дозволу DDL_admin проти db_owner

Я переймаю проект, який передбачає видалення та обмеження дозволів усіх користувачів бази даних по всій фермі серверів. (веселі часи)

Один з дозволів, які наразі обмежені, - це права доступу db_owner.
Цей дозвіл переглядається в кожному конкретному випадку, але загальною зміною є заміна дозволів db_owner на таке:

db_datareader
db_datawriter
db_ddladmin
db_executor

Я хотів би визначити точну різницю між цими двома (повідомити клієнтів).
Однак, наскільки я можу сказати, різниця між ними повинна бути:

db_accessadmin дозволи
Дозволу db_backupoperator
db_securityadmin дозволи

Таким чином , в дійсності вони втратять:
[ALTER ANY USER]
[CREATE SCHEMA]
[BACKUP DATABASE], [BACKUP LOG], [CHECKPOINT]
[ALTER ANY APPLICATION ROLE],[ALTER ANY ROLE]
[DROP DATABASE]

Чи є щось інше, що користувач втрачає, коли db_owner замінюється на чотири ролі вище?
Чи насправді це служить значною мірою безпекою безпеки?

sql-server permissions

— Реалії
джерело

Відповіді:

db_ddladmin vs db_owner

З того, що я можу сказати з того, що я тестував і читав, здебільшого ваш список виглядає точним, за винятком випадків, чи db_ddladminдозволяєте ви CREATE SCHEMA. Я підтвердив, що в інших дозволах безпеки, які ви перераховували, насправді було відхилено.

Заборонено лише DDLADMIN:

[ALTER ANY USER]

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

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

[DROP DATABASE]

Зазначаючи, що. . .

db_datareaderдозволить SELECTотримати доступ до всіх таблиць
db_datarwriterдозволить INSERT, UPDATEі DELETEдоступ до всіх таблиць
db_executorдозволить EXECUTEотримати доступ до всіх виконуваних об’єктів

Крім того, наявність дозволів на роль db_ddladmin може означати. . .

Примітка. Оскільки у 2005–2014 рр. У вас так багато різних версій SQL Server, можливо, найкраще буде невеликий набір користувачів тестувати це спочатку, щоб побачити, хто кричить, щоб виправити будь-які перегини тощо.

Об'єкти, які їм належать з цією роллю, не будуть належати DBO, тому вам, можливо, доведеться мати справу з проблемами зміни власності, якщо коли-небудь буде проблема з чимось на цьому рівні. Я не на 100% впевнений, що це буде проблемою, але це варто згадати про всяк випадок.

Джерело: Ланки власності
Завдяки цій ролі (може змінюватися залежно від версії SQL Server) вони можуть мати змогу додавати принципи безпеки SQL, визначені в поточній БД, до об'єктів, якими вони ще володіють, тільки не всі об'єкти (ті, якими вони не володіють), або додавати новий сервер -рівень, визначений головним до рівня БД.

Крім того, відсутність дозволів на роль DBO може означати. . .

Примітка. Оскільки у 2005–2014 рр. У вас так багато різних версій SQL Server, можливо, найкраще буде невеликий набір користувачів тестувати це спочатку, щоб побачити, хто кричить, щоб виправити будь-які перегини тощо.

Відсутність ролі DBO може перешкоджати заповненню чи відкриттю певних інтерфейсів інтерфейсу дизайнера SSMS (варіюється версія SQL Server) без помилок (наприклад, при зміні таблиць або стовпців через GUI), навіть якщо це робиться через T-SQL і працює, і дозволи мають місце . У деяких версіях SQL Server це може бути вирішено, якщо дозволити, GRANT VIEW DEFINITIONде це проблема, і це може бути лише попередженням лише для певних версій SQL Server.

Ресурси
- Ви не ввійшли в систему як власник бази даних або як користувач, який є членом ролі db_owner. Ви не зможете зберегти зміни в таблицях, якими ви не володієте.
- Роль db_ddladmin не дозволяє використовувати функції "дизайну" в SSMS
  _{"Ми намагаємось не допустити надання користувачам / розробникам dbo у свої бази QA наскільки це можливо. Однією з проблем цього є те, що їм все ще потрібно мати можливість створювати та змінювати об'єкти бази даних, такі як користувацькі таблиці. Багато розробників нові для MS SQL і, таким чином, прагнуть дотримуватися графічного інтерфейсу (SSMS) для такої роботи. Проблема виникає, коли ми надаємо їм db_ddladmin (не dbo), і вони більше не можуть змінювати таблиці або стовпці за допомогою GUI дизайнера таблиць. їм потрібно зайняти додатковий час, щоб вивчити команди TSQL та їх синтаксис (який їм більше ніколи не знадобиться) або залучити команду DBA, яка забирає час від інших наших заходів.}
  
  _{Я не знаю, чи це помилка чи запит на функцію, але я вважаю це помилкою, оскільки користувач має достатньо дозволів для зміни таблиці через TSQL, але графічний інтерфейс передає їм повідомлення про те, що:}
  
  _{" Ви не ввійшли в систему як власник бази даних або системний адміністратор. Можливо, ви не зможете зберегти зміни в таблицях, які у вас не є." ТА "Таблиця [schema].[table]встановлена лише для читання, користувач не має достатньо прав на цю таблицю. "}
  
  _{Слід, схоже, вказує на те, що чек є is_member ('db_owner'), який буде виключати членів db_ddladmin, хоча вони насправді мають дозвіл на зміну об'єкта. Майстерня управління Microsoft SQL Server "}
  
  _{_{Опубліковано агентом DBA 25.01.2010 о 7:06 ранку}}
  
  _{У мене виникло подібне питання, і мені вдалося вирішити його, виконавши наступний грант}
```
GRANT view definition on schema:: <schemaname> to <username>
```

Інші міркування

Оскільки ви заявляєте, що це перевіряється в кожному конкретному випадку

Один з дозволів, які наразі обмежені, є дозволами db_owner.

Цей дозвіл переглядається в кожному конкретному випадку, але загальною зміною є заміна дозволів db_owner на таке:

db_datareader

db_datawriter

db_ddladmin

db_executor

Чи ви розглядали можливість створення додаткових спеціальних ролей для отримання більш доступного для всіх "об'єктів" рівня DB, а не надання їм db_ddladminролі, оскільки це, ймовірно, дасть їм більше, ніж їм потрібно для об'єктів рівня БД.

Зазвичай я даю саме те, що потрібно, і більше нічого, щоб вони виконували свою роботу, і якщо є "звичайна" або "стандартна" потреба в доступі до об'єктів рівня БД до всіх об'єктів у БД, я створюю власну роль БД на зразок db_executorале дивіться мій нижній приклад. Таким чином, ви можете надати людям те, що їм насправді потрібно, для ВСІХ об’єктів DB у певній БД, якщо ви не отримуєте явного рівня об’єктів у ваших БД для їх безпеки.

----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

Я також хотів поділитися роллю db_DDLAdmin_Restriction, яку ви можете розглянути як створити інакше з явним DENYобмеженням db_ddladminдоступу, щоб ви могли принаймні створити це в БД, де ви надаєте їм цю роль і встановите явне DENYдля фактичних типів об'єктів тощо. ви не хочете, щоб вони мали доступ.

Наприклад, якщо ви знаєте , що вони, безумовно , буде створювати збережені процедури і функції, ви можете виключити 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

— Pimp Juice IT
джерело

Використовуючи SQL Script для переліку всіх дозволів, я перейшов і створив користувачів для кожного випадку.

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

Потім я порівняв результати та потрапив до наступного списку з документацією здебільшого msdn (будь-які цитати, на які конкретно не посилаються, посилаються на посилання msdn).
Нижче наведені деякі з документації я використовував , щоб інформувати людей , які будуть програшні дозволу ДБО , що саме вони втрачають.

АЛЬТЕР

Містить можливість змінювати властивості, за винятком власності, на певний захищений. Якщо надано область застосування, ALTER також надає можливість змінювати, створювати або відміняти будь-які захищені дані, що містяться в цій області. Наприклад, дозвіл ALTER на схемі включає можливість створення, зміни та скидання об'єктів зі схеми.

АЛЕ ЯКІ-небудь РОЛІ
ЗАЯВЛЕННЯ АЛЬТИ БУДЬ-ЯКОГО АУДИТУ
ДАТАБАЗИ ПІД ЧАС ЯКИЙ РОЛЬ,
АБО СКЛАДЬ будь-який користувач

Забезпечує можливість СТВОРИТИ, ВИПУСКУВАТИ або Зняти окремі екземпляри бази даних Securable. Наприклад, ПОЛІТЬ ЯКЩО СХЕМА надає можливість створювати, змінювати або відкидати будь-яку схему в базі даних.

Ролі додатків - це основні бази даних, які дозволяють програмі запускатися із власними дозволами, схожими на користувача.

Аудит екземпляра SQL Server або бази даних SQL Server включає відстеження та реєстрацію подій, які відбуваються в системі. Об'єкт Специфікації аудиту рівня бази даних належить до аудиту. Ви можете створити одну специфікацію аудиту бази даних для кожної бази даних SQL Server за аудитом.

Ролі баз даних використовуються для легкого управління дозволами у ваших базах даних, SQL Server надає кілька ролей, які є принципами безпеки, які групують інші принципи. Вони схожі на групи в операційній системі Microsoft Windows. Ролі рівня баз даних є загальнодоступними в межах сфери їх дозволу.

Аутентифікат
Знайдено у msdn.

Дозвіли AUTHENTICATE & AUTHENTICATE SERVER використовуються лише при використанні EXECUTE AS у сценаріях крос-бази даних та доступу до сервера (відповідно).

Журнал резервного копіювання даних

ПІДКЛЮЧИТЕ ЗАМОВЛЕННЯ

Використовується для дозволів на реплікацію бази даних .

КОНТРОЛЬ

Використовує можливості власника на одержувача. Одержувач коштів фактично має всі визначені дозволи на захищений. Принципова особа, якій було надано КОНТРОЛЬ, також може надати дозволи на захищене.

СТВОРИТИ РОЛЬ

Має на увазі грант можливість створення бази даних Securable.

SHOWPLAN

Дозволи на Showplan використовуються для різних параметрів оператора Showplan SET, коли вони використовуються з пакетами Transact-SQL .

ЗАПИСАТИ ЗАПИТАННЯ ЗА ПИТАННЯМ ЗАПИТАННЯ

Документація про сповіщення про запити.

Побудований на основі інфраструктури Service Broker, сповіщення про запити дозволяють повідомляти програми, коли дані змінюються. Ця функція особливо корисна для додатків, які надають кеш інформації з бази даних, наприклад, веб-програми, про яку потрібно повідомити, коли змінено вихідні дані.

ВПРАВЛІТЬ ВЛАСНІСТЬ

Дозволяє одержувачу отримувати право власності на захищене право, на яке він наданий.

ГОЛОВНЕ ДЕРЖАВНІ ДАНІ

Використовується для перегляду переглядів та функцій динамічного управління (Transact-SQL) .

ПОЗНАЧЕННЯ ВИЗНАЧЕННЯ

Документація щодо дозволів на визначення перегляду.

Дозвіл VIEW DEFINITION дозволяє користувачеві бачити метадані, які можна отримати, на яких надано дозвіл. Однак дозвіл VIEW DEFINITION не надає доступу до самого захищеного. Наприклад, користувач, якому надано лише дозвіл VIEW DEFINITION на таблиці, може переглядати метадані, пов'язані з таблицею, у вікні каталогу sys.objects. Однак без додаткових дозволів, таких як SELECT або CONTROL, користувач не може читати дані з таблиці.

— Реалії
джерело