Безпека SQL Server 2005 зсередини, Криптографія, Security & Hack, статті

У статтях про безпеку в 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 рекомендується застосовувати в наступних випадках:



Використовуйте 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 дозволяє змінити як ім’я користувача, так і схему користувача за замовчуванням.


Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*