
- •Контрольні запитання
- •Контрольні запитання
- •Які головні переваги реляційної моделі?
- •Які види ключів існують і навіщо вони потрібні?
- •Функціональна залежність
- •Найбільш простий вигляд оператора select
- •2. Використання секції where
- •2.1. Порівняння значення стовпчика із константою
- •2.2. Правила виконання однотабличних запитів на вибірку
- •3. Багатотабличні запити
- •3.1. Правила виконання багатотабличних запитів на вибірку
- •4. Використання псевдонімів таблиць
- •Секція order by – визначення порядку сортування
- •Групування записів
- •Правила виконання sql–запиту на вибірку (з врахуванням секції group by)
- •Кілька стовпчиків групування
- •8.3. Обмеження на запити з групуванням
- •8.4. Значення null в стовпчиках групування
- •Правила виконання sql–запиту на вибірку (з врахуванням секції having)
- •9.2. Обмеження на умову відбору груп
- •Значення null і умови відбору груп
- •Секція having без секції group by
- •Складні умови відбору у запитах на вибірку даних Використання логічних виразів
- •Порівняння
- •Перевірка на належність діапазону значень (between…and…)
- •Перевірка на належність множині значень (in)
- •Перевірка на рівність значенню null (is null)
- •Символ пропуску
- •2.1. Режими аутентифікації
- •2.2. Компоненти структури безпеки
- •2.3. Ролі сервера
- •2.4. Ролі баз даних
- •2.5. Ролі програми
- •2.6. Захист даних
- •Шифрування даних
- •Обмеження доступу до файлів sql server
- •3.1. Права доступу
- •3.2. Права на доступ до об'єктів баз даних
- •3.3. Заборона доступу
3.3. Заборона доступу
Система безпеки SQL Server має ієрархічну структуру. Це дозволяє ролям бази даних включати облікові записи і групи Windows NT, користувачів і ролі SQL Server. Користувач же, у свою чергу, може брати участь в декількох ролях. Наслідком ієрархічної структури системи безпеки є те, що користувач може одночасно мати різні права доступу для різних ролей. Якщо одна з ролей, в яких полягає користувач, має дозвіл на доступ до даним, то користувач автоматично має аналогічні права. Проте, може потрібно заборонити можливість доступу даним. Коли забороняється користувачеві доступ до даним або командам TRANSACT-SQL (deny access), тим самим анулюються всі дозволи на доступ, отримані користувачем на будь-якому рівні ієрархії. При цьому гарантується, що доступ залишиться забороненим незалежно від дозволів, наданих на більш високому рівні.
Хай, наприклад, потрібно створити в базі даних таблицю, доступ до якої за умовчанням наданий всім користувачам, але необхідно тимчасово обмежити доступ певних користувачів до цієї таблиці. Замість того щоб відкликати дозволи на доступ, можна створити роль, якою буде заборонений доступ до цієї таблиці, і включити користувачів в цю роль. Простіше контролювати декілька записів в ролі, яка забороняє доступ, чим маніпулювати безліччю розрізнених облікових записів, намагаючись пригадати, чи повернули права доступу користувачеві назад. При великій кількості користувачів такий підхід дозволяє спростити адміністрування системи безпеки.
Для заборони користувачеві доступу до об'єктів бази даних потрібно використовувати команду DENY:
DENY
(ALL [PRIVILEGES] | permission[,...n]}
{
[(columnC....n])] ON {table | view} | ON {table | vi ew} [-(columnC . . . n])] I ON {stored_procedure | extended_procedure}
TO security_account[....n] [CASCADE]
Для заборони виконання команд TRANSACT-SQL застосовується інша команда:
DENY {ALL | statement^... .n]} ТO security_account[....n]
Параметри даної команди аналогічні параметрам команди GRANT. Параметр CASCADE дозволяє відкликати права не тільки у даного користувача, але також і у всіх тих користувачів, кому він надав дані права. Пояснимо сенс вищесказаного на прикладі. Хай надано користувачеві Sheridan певні права:
GRANT CREATE TABLE
ТО Sheridan
WITH GRANT OPTION
Допустимо, Sheridan надає аналогічні права деяким користувачам. Якщо згодом потрібно буде відкликати дозволи у Sheridan, потрібно виконати команду:
DENY CREATE TABLE ТO Sheridan CASCADE
При цьому будуть відкликані і всі дозволи, які Sheridan надав іншим користувачам.