Проект «Розробка та впровадження типових рішень щодо комплексної системи захисту інформації в АІС НАНУ»

При створенні  бази даних для неї визначаються стандартні ролі бази даних, які, так само як і стандартні ролі сервера, не можуть бути змінені або видалені. Стандартні ролі баз даних (fixed database role) і їх права приведені в табл. 2.

Таблиця 2

Вбудована роль баз даних	Призначення
db__owner	Має всі права в базі даних
db_accessadmin	Може додавати або видаляти користувачів
db_securityadmin	Управляє всіма  дозволами, об'єктами, ролями і членами  ролей
db_ddladmin	Може виконувати будь-які команди DDL, окрім GRANT, DENY і REVOKE
db_backupoperator	Може виконувати команди DBCC, CHECKPOINT і BACKUP
db_datareader	Може проглядати будь-які дані в будь-якій таблиці  БД
db_datawriter	Може модифікувати будь-які дані в будь-якій таблиці  БД
db_denydatareader	Забороняється проглядати дані в будь-якій таблиці
dbjjenydatawriter	Забороняється модифікувати дані в будь-якій таблиці

 

Окрім вказаних вище ролей існує ще одна — public. Ця роль має спеціальне призначення, оскільки її членами є всі користувачі, що мають доступ до бази даних. Не можна явно встановити членів цієї ролі, тому що всі користувачі і так автоматично є її членами. Цю роль слід використовувати для надання мінімального доступу користувачам, для яких права доступу до об'єктів не визначені явно. Якщо в базі даних дозволений користувач guest, то встановлений для publiс доступ матимуть всі користувачі, що дістали доступ до SQL Server. Роль public є у всіх базах даних, включаючи системні бази даних master, tempdb, msdb, model, і не може бути видалена.

Групи Windows NT можуть бути використані аналогічно ролям SQL Server. Можна створити один обліковий запис (login) для групи Windows NT і включати відповідних користувачів замість ролі в групу Windows NT. Вибір методу адміністрування залежить від вас.

2.5. Ролі програми

Система безпеки SQL Server реалізована на найнижчому рівні  — рівні бази даних. Це якнайкращий, найбільш дієвий метод контролю діяльності користувачів незалежно від програм, використовуваних ними для підключення до SQL Server. Проте, зустрічаються ситуації, коли необхідний постійний набір має право для доступу до бази даних із програмою. Особливо це стосується роботи з великими базами даних, що мають безліч складних взаємозв'язаних таблиць з тисячами або мільйонами записів. Найчастіше для роботи з такими базами даних створюються спеціальні програми.

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

SQL Server вирішує  перераховані проблеми шляхом використання ролі програми, створюваної на рівні бази даних. Відмінності між стандартними ролями і роллю застосування фундаментальні. Роль застосування не має членів. Користувачі SQL Server або Windows NT не можуть бути додані в цю роль. Роль активізується, коли програма встановлює з'єднання. Користувач, що працює в цей час із програмою, не є членом ролі — тільки його програма використовує встановлене з'єднання.

Перед використанням  ролі програми необхідно спочатку створити її. При створенні ролі потрібно вказати її ім'я і пароль для доступу. Створення ролі засобами TRANSACT-SQL виконується за допомогою наступної системної процедури, що зберігається:

sp_addappro1e [ @rolename = ] 'role' . [ (^password = ] 'password'

Перший параметр визначає ім'я, яке матиме створювана роль програми, другий — пароль, який використовуватиметься для активізації ролі.

Створення ролі програми засобами Enterprise Manager виконується за допомогою вікна Database Role Properties — New Role (властивості ролей баз даних — нова роль), яке також використовується для створення звичайних призначених для користувача ролей. Щоб створювана роль була роллю програми, досить встановити перемикач Application role (роль програми) і ввести пароль. Робота з вказаним вікном буде розглянута в одному з наступних розділів цього документу.

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

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

sp_setapprole  [(Еготепате  =]   'role' [^password =] (Encrypt N 'password'}  |  'password' [.[^encrypt =] 'encrypt_style']

Докладніший огляд параметрів:

• role— ім'я ролі програми, яке визначене в базі даних;
• password— пароль, який програма повинна передати серверу для активізації ролі програми;
• encrypt_style — вживана схема шифрування паролів. Даний параметр може мати два значення: none (шифрування не застосовується) і odbc (шифрування із застосуванням функції ODBC encrypt).

Коли роль програми активізується, всі права доступу, встановлені в межах сеансу для користувача, груп або ролей, втрачаються до закінчення роботи програми. З'єднання отримує права, встановлені для ролі програми в базі даних, в якій ця роль існує. Те, що тимчасове “забуває” прав доступу, привласнених користувачеві, що встановив з'єднання, потрібне для усунення конфліктів доступу. Інакше, якщо користувачеві заборонено читання даних, а програмі необхідно рахувати дані, доступ був би відхилений, оскільки заборона доступу має переваги над наданням доступу.

Оскільки роль програми має права тільки в тій базі даних, в якій вона створена, а всі дозволи для облікових записів, груп і ролей, до яких належить користувач, втрачаються, то доступ до інших баз даних можливий тільки під гостьовим ім'ям guest. Отже, якщо ім'я guest в базі даних не існує, то з'єднання не зможе дістати доступ даним. Якщо ж ім'я guest не видалене з бази даних, з'єднання зможе дістати доступ до об'єктів бази тільки в тому випадку, якщо дозволи явно видані для користувача guest. Перед встановленням з'єднання з використанням ролі програми користувачеві спочатку потрібно дістати доступ до SQL Server. Для цього допустимі обидва режими аутентифікації користувачів.

Якщо програма спроектоване для виконання різних завдань з використанням разных прав доступу, необхідно створити окрему роль для кожного виконуваного завдання. Програма повинна сама поклопотатися про перемикання ролей.

2.6. Захист  даних

Як би добре  не була спланована система безпеки SQL Server 2000, залишається можливість копіювання файлів з даними і перегляду їх на іншому комп'ютері. Крім того, з використанням спеціальних пристроїв дані можуть бути перехоплені при передачі їх по мережі. Необхідно продумати засоби фізичного захисту даних. Дані у файлах бази даних зберігаються у відкритій формі, тобто їх можна проглянути в текстовому редакторові. Звичайно, вони не будуть структуровані, але все таки частину інформації можна буде прочитати.

Шифрування  даних

Шифрування — це метод, використовуваний SQL Server для зміни даних до нечитабельної форми. Шифрування гарантує, що цінна конфіденційна інформація не буде проглянута ким би то не було. Можна скопіювати дані, але не можна нічого з ними зробити. Для проглядання даних авторизованими користувачами використовується дешифровка. SQL Server дозволяє шифрувати наступні дані:

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

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

Якщо код тригера, уявлення або процедури, що зберігається, містить дані або алгоритм, які необхідно зберегти в таємниці, використовуйте шифрування цих об'єктів.

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

Якщо необхідно  шифрувати дані при передачі їх по мережі, необхідно використовувати  мережеву бібліотеку Multiprotocol Net-Library.

3. ОБМЕЖЕННЯ ДОСТУПУ ДО ФАЙЛІВ SQL SERVER

У своїй роботі SQL Server створює і використовує безліч файлів — бази даних, журнали помилок, резервні копії, файли для експорту і імпорту даних і багато що інше. Служби SQL Server на рівні операційної  системи виконуються у вигляді процесів. Для нормальної роботи SQL Server необхідно, щоб ці процеси мали повний доступ до всіх вказаних вище файлів на рівні файлової системи. Для цього на рівні операційної системи потрібно надати відповідні права обліковим записам, які використовуються для запуску SQL Server. Краще всього управляти правами доступу безпосередньо на рівні файлів і каталогів. Для цього сервер повинен працювати під управлінням операційної системи Windows NT і мати файлову систему NTFS.

Якщо сервер стартує як служба, необхідно надати повні права доступу обліковим записам, використовуваним для запуску служб. Якщо ж старт SQL Server виконується з командного рядка або на комп'ютері під управлінням Windows 98, то сервер матиме права доступу облікового запису користувача, що виконав запуск. Якщо для запуску сервера використовується обліковий запис локальної системи, то доступ повинен надаватися користувачеві SYSTEM.

З метою обмеження  можливостей неавторизованого доступу  для файлів SQL Server необхідно встановити заборону на читання, видалення, модифікацію і виконання всім користувачам, окрім безпосередньо SQL Server.

3.1. Права доступу

Коли користувачі  підключаються до SQL Server, дії, які  вони можуть виконувати, визначаються правами (дозволами), виданими їх обліковому запису, групі або ролі, в якій вони полягають.

Права в SQL Server можна розділити на три категорії:

• права на доступ до об'єктів баз даних;
• права на виконання команд TRANSACT-SQL;
• неявні права (дозволи).

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

Права користувачеві видаються адміністратором або власниками баз даних або конкретних об'єктів баз даних. Для надання користувачеві певного набору прав можна використовувати ролі. Створивши декілька ролей і надавши їм необхідні права доступу, адміністратор бази даних може просто включати користувачів у відповідні ролі. Користувач автоматично отримує всі права доступу, визначені для ролі. Стандартні ролі бази даних вже мають певний набір прав. Наприклад, члени ролі db_datareader можуть проглядати будь-які дані в будь-якій таблиці.

Важливо бути обережним  з наданням дозволів на доступ до даним. Необхідно уважно контролювати права  доступу, що видаються користувачеві як безпосередньо, так і через членство в групах Windows NT і ролях SQL Server. Особливо це стосується великих систем безпеки з тисячами користувачів і десятками груп. Потрібно бути упевненим, що існуюча система безпеки дає можливість користувачеві виконувати будь-які необхідні дії, але обмежує доступ до інформації, яка не потрібна йому для виконання своїх обов'язків.

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

Аналогічні  рекомендації стосуються дозволів на виконання команд TRANSACT-SQL. Можна спроектувати базу даних таким чином, що виконувати конкретні дії — створення таблиць, уявлень, правил, резервних копій і так далі — будуть строго певні користувачі.

3.2. Права на  доступ до об'єктів баз даних

Робота з  даними і виконання процедур, що зберігаються, вимагає наявність  класу доступу, званого правами на доступ до об'єктів баз даних. Під об'єктами маються на увазі таблиці, стовпці таблиць, уявлення, процедури, що зберігаються. Права на доступ до об'єктів баз даних контролюють можливість виконання користувачами, наприклад, команд SELECT, INSERT, UPDATE і DELETE для таблиць і уявлень. Таким чином, якщо користувачеві необхідно додати нові дані в таблицю, йому слід надати право INSERT (вставка записів в таблицю). Надання ж користувачеві права EXECUTE дозволяє йому виконання яких-небудь процедур, що зберігаються.

Для різних об'єктів  застосовуються різні набори прав доступу  до них:

• SELECT, INSERT, UPDATE, DELETE, REFERENCES – ці права можуть бути застосовані для таблиці або уявлення;
• SELECT і UPDATE — ці права можуть бути застосовані до конкретного стовпця таблиці або уявлення;
• EXECUTE— це право застосовується тільки до процедур, що зберігаються, і функцій. Нижче приводиться докладніший опис кожного з цих прав.
• INSERT. Це право дозволяє вставляти в таблицю або уявлення нові рядки. Як наслідок, право INSERT може бути видане тільки на рівні таблиці або уявлення і не може бути видано на рівні стовпця.
• UPDATE. Це право видається або на рівні таблиці, що дозволяє змінювати всі дані в таблиці, або на рівні окремого стовпця, що дозволяє змінювати дані тільки в межах конкретного стовпця.
• DELETE. Це право дозволяє видаляти рядки з таблиці або уявлення. Як і право INSERT, право DELETE може бути видане тільки на рівні таблиці або уявлення і не може бути видано на рівні стовпця.
• SELECT. Вирішує вибірку даних. Може видаватися як на рівні таблиці, так і на рівні окремого стовпця.
• REFERENCES. Можливість посилатися на вказаний об'єкт. Стосовно таблиць дозволяє користувачеві створювати зовнішні ключі, що посилаються на первинний ключ або унікальний стовпець цієї таблиці. Стосовно уявлень право REFERENCES дозволяє пов'язувати уявлення з схемами таблиць, на основі яких будується уявлення. Це дозволяє відстежувати зміни структури початкових таблиць, які можуть вплинути на роботу уявлення. Право REFERENCES не існувало в попередніх версіях SQL Server.