Концепції захисту

Модель захисту SQL Server велика і складна У деякому роді вона навіть складніша, ніж в Windows Так як концепції захисту тісно переплетені між собою, краще почати їх розгляд із загального огляду моделі

Система безпеки SQL Server заснована на концепції захищених обєктів (securables), тобто обєктів, на які можна призначати дозволи, і принципалів (principles), тобто обєктів, для яких призначено дозволу Принципалами можуть бути користувачі і ролі Користувачі призначаються ролям при цьому як користувачам, так і ролям можуть надаватися дозволи на доступ до обєктів (рис 401) Кожен обєкт має свого власника, і права власності також впливають на дозволи

Система безпеки рівня сервера

Користувач в першу чергу повинен бути ідентифікований сервером одним з таких методів:

■ за допомогою облікового запису користувача Windows

■ на основі членства в одній з груп користувачів Windows

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

На рівні сервера користувач розпізнається за своїм ідентифікатором (LoginlD), який може бути або реєстраційної записом SQL Server, або імям домену та користувача Windows

Рис 401 Узагальнена схема системи безпеки SQL Server Показано, як користувачі спочатку автентифіковані сервером, потім базою даних і обєктами бази даних У гуртках представлені елементи ідентифікації користувача

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

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

Система безпеки рівня бази даних

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

У той же час користувач поки не має доступу до даних Для цього йому повинні бути надані дозволи до окремих обєктів бази даних (наприклад, таблицями, збереженим процедурам, уявленням і функціям) Користувальницькі ролі – це додаткові ролі, що служать як груп Ролі може бути дозволений доступ до обєкта бази даних, а користувачеві може бути призначена для користувача роль бази даних Всі користувачі автоматично стають членами стандартної ролі бази даних public

Дозволи до обєктів призначаються за допомогою інструкцій GRANT (надати), REVOKE (відкликати) і DENY (заборонити) Заборона привілеї заміщає собою її надання, а надання привілеї заміщає собою її відгук Користувачеві може бути надано безліч дозволів до обєкта (індивідуальних, успадкованих від ролі, забезпечених приналежністю до ролі public) Якщо яка-небудь з цих привілеїв заборонена, для користувача блокується доступ до обєкта В іншому випадку, якщо яка-або із привілеїв надає дозвіл, користувач отримує доступ до обєкту

Дозволи обєкта досить деталізовані існують окремі дозволи для кожного з можливих дій (SELECT, INSERT, UPDATE, RUN і тд) над обєктом Деякі фіксовані ролі бази даних також впливають на доступ до обєкта, наприклад, керуючи можливістю зчитувати інформацію і записувати її в базу даних

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

Права власності на обєкт

Заключним аспектом в цьому огляді моделі безпеки SQL Server є право власності на обєкт Власником будь-якого обєкта є схема Схемою за умовчанням є dbo, яку не слід плутати з роллю dbo

У попередніх версіях власниками обєктів були користувачі (точніше, Новинка ^ власник сам представляв собою схему) У порівнянні з цим модель SQL 2005 dServer 2005 у вигляді база даних-схема-обєкти має цілий ряд переваг

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

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

Джерело: Нільсен, Пол 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>

*

*