Безпека SQL Server 2005 зсередини

  1. Спрощення адміністрування шляхом поділу концепцій користувача і схеми
  2. Контекст виконання програмних модулів
  3. Який параметр вибрати
  4. Поділ користувача і схеми
  5. зворотня сумісність
  6. Будь готовий
  7. Нове в DDL
Спрощення адміністрування шляхом поділу концепцій користувача і схеми

У статтях про безпеку в SQL 2000 я розповідала про обмеження, які мають місце при організації ланцюжків володіння, і додаткових питаннях безпеки, що виникають в процесі створення ланцюжків володіння при взаємодії між базами даних. Згадувалося і про плутанині, пов'язаної з моделлю безпеки SQL Server 2000, яка не поділяє концепції користувача і схеми. На цей раз ми розглянемо удосконалення в системі безпеки SQL Server 2005 (або Yukon), які стосуються даних обмежень.

У SQL Server 2005 розробники Microsoft зробили основний упор на безпеку, були посилені багато елементів системи безпеки, які були неповними в попередніх версіях. Найбільш суттєва зміна полягає в тому, що SQL Server 2005 поставляється з належним чином налагодженою системою безпеки, навіть якщо розгортати продукт з усіма установками за замовчуванням. Термінологія в системі безпеки SQL Server 2000 теж стала дещо іншою. Крім терміна «схема», ми обговоримо в цій статті такі поняття безпеки, як аутентифікація і авторизація. Ці два нових поняття є фундаментальними в моделі безпеки SQL Server 2005. Ми можемо уявити собі схему як контейнер, в якому розробник створює об'єкти бази даних. Звертаючись до об'єкта в SQL Server2005, ви посилаєтеся на схему, яка містить даний об'єкт, а не на власника об'єкта. Аутентифікація - це процес, за допомогою якого SQL Server підтверджує і встановлює особу при кожній спробі доступу до ресурсу. Авторизація - це процес, за допомогою якого SQL Server визначає, чи дозволений даному користувачеві доступ до ресурсу.

Контекст виконання програмних модулів

Організація ланцюжків володіння є питанням авторизації, за допомогою якого SQL Server автоматично авторизує одного користувача (наприклад, user1) для доступу до об'єктів іншого користувача (наприклад, user2), за умови що user1 має право на виконання програмних модулів (збережених процедур або функцій), якими володіє user2. Однак, крім механізму організації ланцюжків володіння, в SQL Server 2000 немає іншого механізму для управління аутентифікацією користувача під час доступу до залежних об'єктів. Користувач завжди виконує модуль від свого імені і може отримати доступ до залежних об'єктів тільки при виконанні одного з наступних умов.

  1. У залежних об'єктів той же самий власник, що і у виконуваного модуля.
  2. Користувач, який виконує модуль, має явні дозволу на дані об'єкти.

SQL Server 2005 дозволяє задати контекст виконання збережених процедур і функцій користувача (UDF) - виключаючи макрофункції всередині таблиць - за допомогою виразу EXECUTE AS, поміщеного в заголовок визначення модуля. Даний механізм надає розробнику додатків можливість більш суворого контролю аутентифікації, дозволяючи одному користувачеві виконувати дії всередині модуля так, ніби він аутентифікований як інший користувач.

Оператор EXECUTE AS корисний при використанні динамічного SQL всередині модуля. SQL Server 2000 завжди перевіряє дозволу для кожного оператора динамічного SQL, який виконується, ігноруючи умова № 1. Механізм організації ланцюжків володіння не застосовується. Якщо користувач, що викликає процедуру, не має дозволу на роботу з об'єктами, до яких звертається динамічний SQL, виконання припиняється з помилкою.

Однак в SQL Server 2005, якщо користувач створює процедуру, яка містить динамічний SQL, так, щоб вона виконувалася в контексті користувача, що має дозволи на об'єкти, що згадуються в процедурі, процедура виконається успішно.

У другій бета-версії SQL Server 2005 параметр EXECUTE AS мав три можливих значення для авторизації: CALLER (за замовчуванням), USER = ім'я користувача і SELF.

EXECUTE AS CALLER. Виконання від імені викликає користувача є значенням за замовчуванням і назад сумісно з SQL Server 2000. Коли програміст вказує EXECUTE AS CALLER, оператори всередині модуля виконуються в контексті користувача, який викликав процедуру. Тому користувач, що виконує процедуру, повинен мати відповідні дозволи не тільки на запуск процедури, але і на будь-які об'єкти бази даних, на які вона посилається. Користувачеві, що викликає процедуру, дозволу на такі об'єкти повинні бути дані явно або можуть бути неявними за рахунок ланцюжка володіння. В останньому випадку SQL Server 2005 обчислює дозволу на посилальні об'єкти, аналізуючи ланцюжок володіння між що викликають об'єктами і посилальними об'єктами точно так же, як це робить SQL Server 2000. Однак потрібно мати на увазі, що в SQL Server 2005 об'єкти не мають власників. Схеми ж мають власників і містять об'єкти.

EXECUTE AS USER =. Коли використовується значення EXECUTE AS USER =, процедура виконується в контексті того користувача, чиє ім'я зазначено в параметрі. Коли виконується процедура, SQL Server спочатку перевіряє, чи має користувач дозвіл EXECUTE на дану процедуру, потім перевіряє дозволу на оператори всередині процедури для користувача, наданого в секції EXECUTE AS USER. Довільно задати ім'я користувача під час виконання модуля неможливо. Для того щоб мати можливість вказати AS деякий ім'я користувача, необхідно мати спеціальні дозволи (наприклад, IMPERSONATE) або бути членом спеціальної ролі (sysadmin, або db_owner).

Припустимо, Сюзан створює збережену процедуру в своїй схемі за замовчуванням (схема, в якій вона є власником), з якої відбувається звернення до таблиці в схемі Джо (JoeSchema), власником якої вона не є. Сюзан повинна мати дозвіл на створення процедури в схемі Джо, якщо вона не є власником цієї схеми. А ось Мері має дозвіл SELECT на таблицю в схемі Джо. Сюзан вказує EXECUTE AS USER = Mary в операторі CREATE PROCEDURE, як показано нижче:

CREATE PROCEDURE AccessMyTable
WITH EXECUTE AS USER = Mary
AS SELECT * FROM JoeSchema.MyTable

Потім Сюзан надає дозвіл EXECUTE на дану процедуру користувачеві на ім'я Скотт. Коли Скотт виконує процедуру, SQL Server перевіряє, чи має Скотт дозвіл на виконання процедури, однак при зверненні до таблиці SQL Server перевіряє дозволу Мері. При такому сценарії, навіть якщо Скотт не має явного дозволу SELECT на цю таблицю, він може отримати доступ до даних через процедуру, тому що вона буде виконуватися в контексті Мері, а у Мері є права на таблицю.

EXECUTE AS SELF. EXECUTE AS SELF позначає «виконання від імені поточного користувача, який створює або змінює модуль». EXECUTE AS SELF аналогічно EXECUTE AS USER =, де ім'я користувача є ім'ям людини, що створює або змінює модуль. Каталог зберігає ідентифікатор користувача (UID) замість самого значення SELF.

Зауважу, що користувач, вказаний в параметрі SELF, не обов'язково повинен бути власником об'єкта. Насправді об'єкти в SQL Server 2005 не мають власників, але можна думати про власників схем так, як ніби вони володіють усіма об'єктами в схемах. Користувач може мати привілеї на створення об'єктів в схемах, власником яких він не є. Наприклад, Сюзан має дозвіл ALTER SCHEMA на схему, власником якої є Джо. Якщо Сюзан створює таблицю в схемі Джо, Джо є власником, а Сюзан - творцем; будь-яка процедура, створена Сюзан з параметром EXECUTE AS SELF, буде виконуватися в контексті Сюзан.

Який параметр вибрати

Вивчення нових можливостей займе якийсь час, тому нижче наводиться кілька рекомендацій з приводу застосування параметра EXECUTE AS в різних ситуаціях.

Отже, EXECUTE AS CALLER рекомендується застосовувати в наступних випадках:

  • якщо необхідно, щоб оператори в процедурі виконувалися від імені викликає користувача;
  • коли потрібно, щоб SQL Server перевіряв дозволу на оператори процедури для викликає користувача і покладався тільки на ланцюжок володіння для виключення перевірки дозволів на нижележащие об'єкти;
  • якщо ви посилаєтеся тільки на об'єкти в схемах, які мають одного власника, то можете покладатися на ланцюжок володіння для отримання доступу до залежних об'єктів.

Використовуйте EXECUTE AS USER = в наступних ситуаціях:

  • якщо необхідно, щоб оператори всередині процедури виконувалися в контексті певного користувача;
  • якщо ви не можете покладатися на ланцюжок володіння, щоб приховати базову схему (т. е. коли процедура звертається до об'єктів, які мають різних власників), і не хочете явно давати дозволу на об'єкти;
  • якщо необхідно створити набір власних дозволів.

Іноді може знадобитися видати дозволи, які зазвичай не надаються, такі як дозвіл TRUNCATE TABLE. Навіть в SQL Server 2005 не можна надати такий дозвіл. Однак власник бази може написати збережену процедуру, яка усікає таблицю. Якщо власник бази і власник таблиці - одне і те ж обличчя, то це безперервний ланцюжок володіння. Переваги використання ланцюжка володіння застосовні тільки до пропозицій мови маніпуляції даними (SELECT, INSERT, UPDATE, DELETE), тому користувач, який має дозвіл на виконання процедури, зіткнеться з відсутністю дозволу на виконання оператора усічення таблиці. Але якщо при створенні процедури задіяти оператор EXECUTE AS, користувач, який виконує процедуру, може під час виконання видати себе за іншого, і оператор TRUNCATE TABLE буде виконаний успішно.

Можна застосовувати EXECUTE AS SELF, коли у вас є додаток, яке створює усередині себе процедури, що викликаються користувачами, і потрібно, щоб ці процедури були створені в контексті виконання даних користувачів. В цьому випадку в момент розробки ім'я викликає користувача невідомо.

Поділ користувача і схеми

Наступне суттєва зміна в моделі безпеки SQL Server 2005 - це спрощення взаємовідносин між користувачами і об'єктами, що дозволяє додавати і видаляти користувачів, не піклуючись про об'єкти, якими ті володіють. Для відповідності ANSI SQL Server 2005 проводить відмінність між користувачами і схемами.

Стандарт ANSI SQL-92 визначає схему як колекцію об'єктів бази даних, що мають одного власника і знаходяться в одному просторі імен (набір об'єктів, які не можуть мати повторювані імена). Наприклад, дві таблиці можуть мати однакові імена, тільки якщо вони знаходяться в різних схемах; ніякі дві таблиці в одній схемі не можуть мати однакові імена. Нагадаю, що при роботі з інструментами бази даних схема звертається до інформаційного каталогу, який описує об'єкти в схемі або базі даних. А в Analysis Services схема описує багатовимірні об'єкти, такі як куби і розмірності.

У SQL Server 2005 немає прив'язки користувачів до схем; як первинні, так і вторинні принципалом можуть володіти схемами. Термін «принципал» в даному випадку означає сутність, яка може отримати доступ до захищених об'єктів. Первинний принципал представляє одного користувача (такого, як обліковий запис SQL Server або Windows); вторинний принципал представляє безліч користувачів (це може бути роль або група Windows). Інша зміна в SQL Server 2005 полягає в тому, що об'єкти не мають власників. Будь-який власник схеми «володіє» об'єктами цієї схеми. Важливо пам'ятати, що схема містить об'єкти, а не користувачів.

Кожна нова база даних, створена в SQL Server 2005, включає кілька схем. Так само як в базах SQL Server 2000 були «користувачі» dbo, INFORMATION_SCEMA, guest, в кожній новій базі SQL Server 2005 є схеми з такими ж іменами. Крім того, в кожній базі SQL Server 2005 існує схема з ім'ям sys, яка надає користувачам доступ до всіх системних таблиць і уявленням. І нарешті, кожна зумовлена ​​роль в базі SQL Server 2000 відповідає однойменної схемою в SQL Server 2005.

Можна призначити новому користувачеві схему за замовчуванням, яка може не існувати під час створення облікового запису даного користувача. Схема за замовчуванням використовується для розпізнавання імен під час створення об'єктів і при зверненні до об'єктів. Якщо не вказати схему за замовчуванням, то для користувача схемою за замовчуванням буде схема dbo. При зверненні до об'єктів SQL Server 2005 буде завжди перевіряти спочатку схему sys, незалежно від встановленої схеми за замовчуванням. Наприклад, якщо користувач Сью виконує запит Select * from table1, а схемою за замовчуванням для неї є SueSchema, то дозвіл імен відбуватиметься в такій послідовності:

  1. Пошук таблиці sys.table1
  2. Пошук таблиці SueSchema.table1
  3. Пошук таблиці dbo.table1

Даний пошуковий механізм застосовний до всіх операторам, навіть до ALTER і DROP. Нагадаю, що, коли системний адміністратор створює об'єкт і вказує одну частину імені (без схеми), схема завжди буде DBO. Однак системний адміністратор може явно вказати схему, в якій буде створено об'єкт.

зворотня сумісність

SQL Server 2000 не поділяє імена користувачів і схем, він навіть не включає в себе концепцію схеми. Тому SQL Server 2000 позначає будь-який об'єкт, створений користувачем, за допомогою імені користувача замість схеми. У SQL Server 2005 для забезпечення сумісності розробники Microsoft переписали збережені процедури sp_grantdbaccess і sp_adduser для використання нових операторів DDL, які розглядаються в урізанні «Нові оператори DDL». У SQL Server 2005 sp_grantdbaccess створює користувача і схему з тим же ім'ям і ID, як у користувача. Ця схема є для користувача схемою за замовчуванням, а користувач є власником даної схеми. Наприклад, якщо хтось виконує процедуру:

EXEC sp_grantdbaccess Susan, sue, db_datareader

SQL Server 2005 здійснює внутрішню трансляцію такого виклику в новий DDL, як показано в лістингу . Крім того, SQL Server 2005 переписує виклик

sp_revokedbaccess sue
як
DROP CHEMA sue
DROP USER sue

Зауважу, що SQL Server 2005 видаляє схему, якщо вона має такі ж ім'я і ID, як у користувача.

Потрібно мати на увазі, що якщо замість sp_grantdbaccess використовується CREATE USER і схема за замовчуванням не вказана, то схемою за замовчуванням стане DBO. SQL Server 2005 не створить нову схему з таким же ім'ям, як у користувача.

Будь готовий

Навіть якщо переходити на SQL Server 2005 відразу після його виходу не планується, рекомендую все ж почати думати про користувачів і схемах як про окремі сутності. Для SQL Server 2000 схема завжди має таке ж ім'я, як користувач, але, щоб не заплутатися, потрібно пам'ятати, що дозволи видаються користувачам, тоді як схеми містять (і уточнюють) об'єкти. Поділ схем і користувачів спрощує адміністрування. Основна перевага полягає в тому, що здійснювати управління користувачами, особливо видалення користувачів, буде набагато легше. Також можна буде встановлювати кілька користувачів в якості власників схеми за допомогою вторинних принципалів (т. Е. Груп і ролей). Крім того, кілька користувачів можуть мати одну схему за замовчуванням для загального дозволу імен.

Можливість задати користувача як виконавця для певного модуля дозволяє більш повно керувати доступом до об'єктів і дає багато переваг в порівнянні з механізмом ланцюжків володіння при взаємодії між базами даних, реалізованим в SQL Server 2000 Service Pack 3 (SP3). Механізм ланцюжків володіння між базами даних є рішенням, що працює за принципом «все або нічого»: ланцюжок володіння або застосовується, або ні. За допомогою додаткового управління в SQL Server 2005 розробник модулів може визначити, які модулі користувач має право запускати, а які - ні.

Розглянуті поліпшення - це тільки верхівка айсберга системи безпеки Yukon. Коли ми впритул наблизимося до моменту виходу SQL Server 2005, я повідаю всі подробиці щодо використання її особливостей.

Нове в DDL

У SQL Server 2005 реалізовано кілька нових операторів для роботи зі схемами. Щоб не займати багато місця описом повного синтаксису, я коротко представлю ці оператори, а коли ви встановите SQL Server 2005, то зможете звернутися за подробицями до електронної документації (BOL).

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

ALTER SCHEMA дозволяє змінити власника схеми. Одночасно у схеми може бути тільки один власник, але таким власником може бути користувач SQL Server, користувач Windows, група Windows або роль SQL Server. Тільки користувач з правом TAKE OWNERSHIP на схему може забрати право володіння схемою. Член ролі db_owner може поміняти власника схеми.

DROP SCHEMA проходить успішно, тільки якщо схема не містить будь-яких об'єктів. Якщо схема містить об'єкти, вона не буде видалена.

Крім того, SQL Server 2005 містить нові команди мови DDL для роботи з користувачами. Це відповідає новому стандарту використання операторів CREATE і ALTER замість застосування процедур. CREATE USER дозволяє вказати ім'я облікового запису користувача і ім'я для реєстрації для асоціації з обліковим записом даного користувача. Можна також вказати схему за замовчуванням. ALTER USER дозволяє змінити як ім'я користувача, так і схему користувача за замовчуванням.

Незалежний консультант та інструктор по SQL Server. Має сертифікати MCT і MCSE. Автор книги Inside SQL Server 2000 (Microsoft Press) [email protected]