Безпека об’єктів

Якщо користувачеві відкривається доступ до бази даних, йому автоматично надаються дозволи до всіх її обєктів Ці дозволи можуть бути відкриті безпосередньо для користувача також вони можуть бути призначені ролі, до якої належить користувач Користувач може бути призначений декільком ролям, тому від користувача до обєкта може існувати безліч ланцюжків дозволів

Дозволи рівня обєкта

Дозволи до обєкта призначаються за допомогою інструкцій SQL DCL GRANT, REVOKE і DENY Ці інструкції мають свою ієрархію: DENY має перевагу над GRANT, яка, в свою чергу, має перевагу над REVOKE, тобто інструкція GRANT дозволяє доступ до обєкта, якщо він не скасований інструкцією DENY

Існує кілька особливих типів дозволів

■ Дозвіл на відбір даних Ці дозволи можуть застосовуватися до окремих стовпців

■ Дозвіл на вставку даних

■ Дозвіл на оновлення даних Право на зміну існуючих даних вимагає наявності права на їх відбір Дозволи на оновлення можна встановлювати на рівні окремих стовпців

■ Право на видалення існуючих даних

■ Право на створення зовнішніх ключів, що використовують DRI

Дозволи на рівні обєктів застосовуються за допомогою трьох інструкцій DCL: GRANT, REVOKE і DENY Незалежно від того, звідки будуть управлятися дозволу, з інтерфейсу Management Studio або з програмного коду, важливо чітко розуміти особливості і взаємозвязок цих трьох інструкцій

Надання дозволів до обєкта взаємодіє з серверними ролями і ролями бази даних Нижче представлена ​​ієрархія ролей і дозволів, де кожен попередній номер має перевагу над подальшим

1&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Серверна роль sysadmin

2&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Заборона доступу до обєкта,

або роль бази даних db_denydatareader, або роль бази даних db_denydatawriter

3&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Дозвіл доступу до обєкта,

або права власності над обєктом, або роль бази даних db_datareader, або роль бази даних db_datawriter

4&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Відгук дозволів для обєкта

Існує простий спосіб тестування системи безпеки Для цього потрібно конфігурувати на півночі змішаний режим аутентифікації і створити тестову обліковий запис SQL Server За допомогою аналізатора запитів можна створити додаткові підключення як окремих користувачів – це набагато простіше, ніж кожного разу наново реєструватися на сервері в Management Studio або яким-небудь іншим способом

Якщо в середовищі, в якій ви працюєте, заборонено використання спільного режиму, для перевірки системи безпеки клацніть правою кнопкою миші в меню Пуск на ярликах утиліти Management Studio або Query Analyzer, виберіть у контекстному меню команду Run As і вкажіть імя користувача, від імені якого ви збираєтеся запустити утиліту Однак врахуйте, що це тягне за собою створення підставних користувачів в домені Windows

Надання дозволів з програмного коду

Налаштування дозволів до обєктів являє собою єдину область системи безпеки, в якій можна обійтися без виклику збережених процедур

GRANT дозвіл, дозвіл ON обєкт

ТО користувач / роль, користувач / роль WITH GRANT OPTION

Дозвіл може бути одним з наступних ключових слів: ALL, SELECT, INSERT, DELETE, REFERENCES, UPDATE і EXECUTE Роль і користувач вказують на імя користувача бази даних, на призначену для користувача або стандартну публічну роль У наступному прикладі користувачеві Den надається дозвіл на вибірку значень з таблиці Person:

GRANT Select ON Person TO Den

У наступному прикладі для ролі public відкриваються всі дозволи до таблиці Marriage: GRANT All ON Marriage TO Public

В одній інструкції може бути перераховано кілька імен користувачів і / або ролей, а також безліч дозволів до обєкта У наступному прикладі користувачам guest і LRN надається дозвіл на відбір і оновлення значень з таблиці Person: GRANT Select, Update ON Person to Guest, LRN

Параметр WITH GRANT OPTION дозволяє зазначеним в інструкції GRANT користувачам передавати свої повноваження іншим користувачам Наприклад, в наступній інструкції користувачеві Joe надаються дозволи вибірки значень з таблиці Person, яке він може передавати іншим користувачам

Параметр WITH GRANT OPTION може бути використаний тільки в програмному коді – у середовищі Management Studio він недоступний

Відгук прав і заборона доступу до обєкта в програмному коді

Інструкції відкликання і заборони прав доступу до обєкта використовують в основному той же синтаксис, що й надання прав У наступному прикладі право вибірки даних з таблиці Marriage відгукується у користувача Den:

REVOKE Select ON Marriage TO Den

Якщо дозволу надавалися з параметром WITH GRANT OPTION, то вони повинні відгукуватися і заборонятися з параметром CASCADE, щоб операція була застосована і до всіх користувачів, яким були делеговані права даним користувачем У наступному прикладі забороняється доступ до таблиці Person користувачеві Joe, а також усім, кому він сам надав дозволу

Стандартні ролі бази даних

Стандартні ролі бази даних іноді називають користувацькими Вони можуть бути створені будь-яким користувачем сервера, що має серверну роль sysadmin або ролі бази даних db_owner або security admins Ці ролі функціонально ідентичні групам користувачів в операційній системі Windows Стандартної ролі можуть бути надані дозволи та приладдя іншим ролям, і цій ролі можуть належати користувачі

Самий прозорий план захисту SQL Server передбачає призначення дозволів до обєктів і фіксованих ролей стандартної ролі і подальше призначення стандартної ролі користувачів

РОЛЬ public

Роль public є фіксованою, однак, подібно стандартної ролі, їй можна призначати дозволу до обєктів Кожен користувач автоматично стає членом ролі public, і цей звязок неможливо видалити Таким чином, роль public служить своєрідним мірилом мінімально допустимих дозволів

При призначенні дозволів ролі public будьте особливо обережні, оскільки Увага вони будуть застосовані до всіх користувачів, за винятком тих, хто належить серверної ролі sysadmin Надання прав позначиться на всіх користувачах, однак більш важливо те, що на них позначаться і заборони доступу, застосовані до ролі public (як ми вже говорили, це не стосується ролі sysadmin), – в тому числі і на власниках самих цих обєктів

Управління ролями в програмному коді

Створення стандартних ролей в програмному коді припускає використання системної збереженої процедури sp_addrole Імя ролі може складатися не більше ніж з 128 символів, не може включати в себе зворотну косу межу, не може бути порожнім рядком або порожнім значенням За замовчуванням ролі належать користувачеві dbo, в той же час власника ролі можна визначити явно в другому параметрі збереженої процедури У наступному прикладі створюється роль manager:

Ехес sp_addrole Manager

Ось результат:

New role added

Операцією, протилежної створенню ролі, є її видалення Роль не може бути вилучена, поки їй призначений хоча б один користувач Для видалення ролі з бази даних використовується збережена процедура sp_droprole:

Ехес sp_droprole Manager

Ось результат:

Role dropped

Після створення ролі вона може бути призначена користувачам за допомогою збереженої процедури sp_addrolemember У наступному прикладі роль manager призначається користувачеві Den:

Ехес sp_addrolemember Manager, Den

Ось результат:

‘Joe added to role Manager.

Аналогічно системна збережена процедура sp_droprolemember видаляє призначення користувача деякої ролі У наступній команді користувач Den буде звільнений від ролі manager:

Ехес sp_droprolemember Manager, Den

Ось результат:

‘Joe dropped from the role Manager.

Ієрархічна структура ролей

Якщо структура системи безпеки складна, то при організації структури дозволів можна скористатися ієрархічною структурою стандартних ролей бази даних

■ Робочий може мати обмежений доступ

■ Керуючий може мати всі права робочого плюс деякі права до таблиць класифікаторів

■ Адміністратор може мати всі права керуючого плюс право на виконання завдань адміністрування бази даних

Для створення структури такого типу виконайте наступні дії

1 Створіть роль робітника і надайте їй дозволу

2 Створіть роль керуючого і додайте її як користувача ролі робітника Надайте ролі керуючого додаткові дозволи

3 Створіть роль адміністратора і додайте її як користувача ролі керуючого Надайте ролі керуючого додаткові фіксовані серверні ролі

Перевага такої системи організації системи безпеки полягає в тому, що зміни на нижньому рівні ієрархії автоматично відбиваються і на більш високих рівнях В результаті адміністрування можна виконувати тільки на якомусь одному рівні, що не дублюючи його на десятці інших, повязаних з ним

Безпека обєктів і Management Studio

Дозволами рівня обєктів, застосовуваними до самим обєктам, а також до користувачів і ролям, можна управляти з різних місць, в тому числі і з Management Studio, і це вносить в управління системою безпеки певну плутанину

Управління зі списку обєктів

Для зміни дозволів обєкта виконайте наступні дії

1&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Клацніть правою кнопкою миші на імені обєкта у відповідному вузлі (tables, views тощо) вікна Object Browser і виберіть у контекстному меню пункт Properties Відкриється діалогове вікно параметрів цього типу обєктів

2&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Клацніть на кнопці Permissions, щоб відкрити діалогове вікно дозволів обєкта

Як і у випадку призначення дозволів за допомогою інструкцій, можна вибрати дозволу grant, with grant і deny Список всіх обєктів бази даних знаходиться у верхній частині діалогового вікна Цей список можна використовувати для швидкого перемикання між обєктами, не виходячи з вікна, та призначення їм тих чи інших дозволів

Кнопка Columns в нижній частині вікна служить для відкриття діалогового вікна Column Permissions Виберіть користувача, клацніть на цій кнопці і встановіть дозволу для цього користувача на рівні стовпців На рівні стовпців можуть бути призначені тільки дозволу на вибірку та оновлення, так як операції вставки і видалення застосовуються на рівні рядків

Управління зі списку користувачів

У списку користувачів бази даних утиліти Management Studio двічі клацніть на імені користувача або клацніть на ньому правою кнопкою і виберіть у контекстному меню пункт Properties Відкрилося діалогове вікно Database User Properties служить для призначення користувачів ролям

Клацніть на кнопці Properties, щоб відкрити діалогове вікно параметрів обраної ролі

Якщо тепер клацнути на кнопці Permissions, відкриється вкладка Permissions діалогового вікна Database User Properties Ця вкладка схожа з однойменної вкладкою діалогового вікна Database Object Properties

На жаль, список обєктів у цьому вікні не впорядкований, і відсортувати його неможливо за допомогою клацання на заголовку стовпця Це діалогове вікно гостро потребує функції select all та інших засобах, пропонованих формами дозволів програми Access

Управління зі списку ролей

Дозволами обєктів можна також управляти і зі списку ролей Для відкриття діалогового вікна Database Role Properties двічі клацніть на ролі або клацніть на ній правою кнопкою миші і виберіть у контекстному меною пункт Properties Це діалогове вікно використовується для призначення ролі користувачів і інших ролей, а також для видалення їх з ролі

Клацніть на кнопці Permissions, щоб відкрити діалогове вікно дозволів ролі Робота в цій формі аналогічна описаній в попередніх розділах, за винятком того, що вона організована з фокусом на роль

Ланцюжки приналежності

У базах даних SQL Server користувачі часто отримують доступ до даних, проходячи через кілька обєктів Ланцюжки приналежності застосовні до уявлень, збереженим процедурам і призначеним для користувача функціям Наприклад:

■ в Visual Basic програма може викликати збережену процедуру, яка витягує дані з таблиці

■ звіт може відбирати дані з уявлення, яке, в свою чергу, засноване на деякій таблиці

■ складні збережені процедури можуть у процесі роботи викликати кілька інших процедур

У всіх цих випадках користувач повинен мати дозволи для виклику збереженої процедури або відбору даних з уявлення Чи повинен користувач при цьому мати права доступу до підлягає таблицями цих процедур і уявлень, залежить від ланцюжка приналежності, що простягається від особи, якій користувачем обєкта до таблиці, в якій зберігаються дані

Якщо такий ланцюжок власності не розірвана, то збережена процедура може бути виконана за допомогою дозволу свого власника У цьому випадку користувачеві досить прав на виконання самої збереженої процедури – дозволи до вихідних таблиць йому не потрібні

Ланцюжки приналежності є прекрасним засобом реалізації структури системи безпеки, в якій користувачі не мають прямих повноважень на таблиці даних і виконують тільки дозволені їм збережені процедури

Якщо ланцюжок приналежності розірвана (тобто в ній зявляється інший власник обєкта), SQL Server перевіряє наявність дозволів до кожного з обєктів, до якого здійснюється доступ

Наведемо приклади

■ Ланцюжок приналежності від dbo А до dbo В і далі до dbo Person не розірвалася У цьому випадку dbo А може викликати dbo В і таким чином отримати доступ до dbo Person як dbo

■ Ланцюжок приналежності від dbo А до Sue С і далі до Joe Purchase розірвана, оскільки в ній присутні кілька різних власників обєктів У цьому випадку dbo А викликає Sue С, використовуючи дозволу Joe, і Sue З звертається до даних Joe Purchase, також використовуючи дозволу Joe

■ Ланцюжок приналежності від dbo А до dbo В і далі до Joe Person також розірвана Таким чином, dbo А викликає dbo В з використанням дозволів dbo, але dbo У може отримати доступ до Joe З тільки за допомогою дозволів Joe

Приклад простої моделі захисту

За прикладами організації дозволів звернемося до навчальній базі даних OBXKites У табл 401 представлені дозволу для стандартних ролей бази даних, а в табл 402 – список деяких користувачів цих ролей

Таблиця 401 Ролі бази даних OBXKites

Стандартна

роль

Ієрархічна Таблиці пер-Таблиці ста-структура ролей вичной файло-тичної файлової групи виття групи

Інші дозволу

IT

Серверна роль – sysadmin

Clerc

Дозвіл виконання кількох збережених процедур, які зчитують дані з оперативних таблиць і оновлюють їх

Admin

Фіксована –

роль бази даних

db_owner

Public

– Дозволи від– бору даних

Таблиця 402 Користувачі бази даних OBXKites

Користувач

Стандартна роль бази даних

Sammy

Admin

Joe

LRN

IT

Група Windows Clerc (користувачі Betty, Tom, Martha І Mary)

Clerc

У цій моделі системи безпеки наступні користувачі можуть виконувати завдання, описані нижче

■ Betty як член групи Clerc може виконувати додаток VB, яке виконує збережені процедури, извлекающие і обновляющие дані Оскільки Betty є членом ролі Public, він може виконувати запити вилучення даних

■ LRN як адміністратор і член групи IT може виконувати всі завдання в базі даних, оскільки він належить до фіксованої серверної ролі sysadmin

■ Joe як член ролі Public може виконувати запити вилучення даних

■ Будучи членом ролі Admin, Sammy може виконувати всі збережені процедури Він також може за допомогою запитів вручну модифікувати будь-які таблиці Як член групи Admin, що включає в себе роль db_owner, Sammy може виконувати будь-які завдання адміністрування даних і змінювати дані в будь-яких таблицях

■ Sammy може виконувати резервні копіювання, але тільки LRN має право відновлювати базу даних з архівів

Джерело: Нільсен, Пол Microsoft SQL Server 2005 Біблія користувача : Пер з англ – М: ООО ІД Вільямс , 2008 – 1232 с : Ил – Парал тит англ

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


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

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

Ваш отзыв

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

*

*