Автор: Пользователь скрыл имя, 17 Марта 2013 в 20:02, курсовая работа
Окрім крадіжки інформації є можливість її пошкодження внаслідок помилки оператора або неправильно написаного додатка. Наслідки таких дій можуть спричинити серйозні фінансові втрати. Наприклад, якщо дані про клієнтів будуть втрачені, доведеться наново збирати потрібну інформацію. А це втрата часу та фінансів.
1. ПРАВИЛА БЕЗПЕКИ 3
2. АРХІТЕКТУРА СИСТЕМИ БЕЗПЕКИ SQL SERVER 2000 6
2.1. РЕЖИМИ АУТЕНТИФІКАЦІЇ 7
2.2. КОМПОНЕНТИ СТРУКТУРИ БЕЗПЕКИ 10
2.3. РОЛІ СЕРВЕРА 15
2.4. РОЛІ БАЗ ДАНИХ 16
2.5. РОЛІ ПРОГРАМИ 19
2.6. ЗАХИСТ ДАНИХ 21
Шифрування даних 21
3. ОБМЕЖЕННЯ ДОСТУПУ ДО ФАЙЛІВ SQL SERVER 22
3.1. ПРАВА ДОСТУПУ 23
3.2. ПРАВА НА ДОСТУП ДО ОБ'ЄКТІВ БАЗ ДАНИХ 24
3.3. ЗАБОРОНА ДОСТУПУ 28
4. ПІДВИЩЕННЯ РІВНЯ ЗАХИСТУ MICROSOFT SQL SERVER 2000 30
4.1. ЗАХИСТ МЕРЕЖЕВОГО ОБМІНУ 31
4.2. ЗАХИСТ ОПЕРАЦІЙНОЇ СИСТЕМИ 35
4.3. ЗАХИСТ КОМПОНЕНТІВ БАЗИ ДАНИХ 39
4.4. АУДИТ СЕРВЕРА SQL SERVER 41
5. СТВОРЕННЯ ГНУЧКОЇ СИСТЕМИ БЕЗПЕКИ MS SQL SERVER 7.0/2000 43
5.1. ВИБІР СХЕМИ АУТЕНТИФІКАЦІЇ 43
5.2. WEB-АУТЕНТИФІКАЦИЯ 45
5.3. ЗБІР КОРИСТУВАЧІВ В ГРУПИ 47
5.4. НАДАННЯ ДОСТУПУ ДО БАЗ ДАНИХ 49
5.5. ПРИЗНАЧЕННЯ ДОЗВОЛІВ 50
5.6. ПРОСТА СИСТЕМА БЕЗПЕКИ 51
ВИСНОВОК 52
Як випливає з вищевикладеного, доступ можна надавати як на рівні всієї таблиці або уявлення, так і на рівні окремого стовпця. Зазвичай не практикується управління правами доступу на рівні конкретного стовпця. Якщо в таблиці є один або більш за стовпці, доступ користувачів до яких необхідно обмежити, то в базі даних часто створюється уявлення (view), що включає тільки ті стовпці початкової таблиці, доступ до яких дозволений.
Надати або відхилити доступ користувачеві бази даних до всіх об'єктів бази даних можна за допомогою вбудованих ролей бази даних. Наприклад, для дозволу читання даних зі всіх таблиць і представлень бази даних досить включити користувача у фіксовану роль db_datareader, а не змінювати права доступу користувача до кожної таблиці і уявлення окремо.
Потрібно використовувати команду GRANT для управління дозволами користувача на доступ до об'єктів бази даних:
GRANT (ALL [PRIVILEGES] | permiss1on[....n]} {[(column[,...n])] ON {table | view} | ON {table | view}[(column[,...n])] | ON {stored_procedure | extended_procedure} } TO security_account[,...n] [WITH GRANT OPTION] [AS {group | role}]
Призначення параметрів команди GRANT наступне:
Як приклад команди розглянемо наступну ситуацію. Необхідно надати права на використання команд INSERT і SELECT групі Engineer в таблиці Materials. При цьому потрібно, щоб надалі користувачі цієї групи могли самі надавати аналогічні права. Для цього слід виконати наступну команду:
GRANT SELECT. INSERT
ON Materials
TO Engineer
WITH GRANT OPTION
Згодом користувач Valentin, що є членом групи Engineer, може надати аналогічні права іншому користувачеві Liss:
GRANT SELECT, INSERT ON Materials ' TO Liss AS Engineer
В даному випадку необхідно підтвердити, на якій підставі Valentine надає права, тому застосовується параметр AS.
Потрібно обережно використовувати параметр WITH GRANT OPTION, оскільки при цьому втрачається контроль над наданням прав на доступ іншим користувачам. Краще всього обмежити коло людей, що мають можливість управляти призначенням прав.
Єдине право доступу, яке може бути надане для процедури, що зберігається, — це право на її виконання (EXECUTE). Природно, окрім цього власник процедури, що зберігається, може переглядати і змінювати її код.
Для функції можна видати право на її виконання, а, крім того, можна видати право REFERENCES, що забезпечить можливість скріплення функції з об'єктами, на які посилається функція. Таке скріплення дозволяє заборонити внесення змін до структури об'єктів, які могли б привести до порушення роботи функції.
Щоб надати право на виконання процедури, що зберігається, можна використовувати Enterprise Manager. Для цього потрібно вибрати в лівій панелі Enterprise Manager потрібну базу даних і відкрити в ній каталог Stored Procedures. У правій частині Enterprise Manager буде відображений список процедур, що зберігаються, вже створених в базі даних. Управління правами доступу можна здійснювати у вікні Object Properties (властивості об'єктів). Викликати це вікно можна або за допомогою кнопки Permissions (права) у вікні властивостей процедури, що зберігається, або вибравши в контекстному меню процедури, що зберігається, пункт АН Tasks > Manage Permissions (всі завдання > управління правами).
Щоб дозволити користувачеві виконувати процедуру, що зберігається, потрібно встановити напроти його імені галочку в полі ЕХЕС. Щоб заборонити доступ, потрібно поставити хрестик. Відсутність якого-небудь значка має на увазі неявне відхилення доступу. Детальніше про права доступу буде розказано далі в цьому розділі.
Управління правами доступу до функцій здійснюється аналогічно.
Інший спосіб управління правами доступу полягає в наданні прав конкретному користувачеві за допомогою вікна прав доступу користувача. Для цього слід у вікні Enterprise Manager вибрати необхідну базу даних, а потім каталог Users. Потім клацнути лівою кнопкою миші на вибраному користувачі. У вікні, що з'явилося, клацнути на кнопці Permissions (має рацію) і вказати необхідні права.
Система безпеки 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]} ТЕ security_account[....n]
Параметри даної команди аналогічні параметрам команди GRANT. Параметр CASCADE дозволяє відкликати права не тільки у даного користувача, але також і у всіх тих користувачів, кому він надав дані права. Пояснимо сенс вищесказаного на прикладі. Хай надано користувачеві Sheridan певні права:
GRANT CREATE TABLE
ТО Sheridan
WITH GRANT OPTION
Допустимо, Sheridan надає аналогічні права деяким користувачам. Якщо згодом потрібно буде відкликати дозволи у Sheridan, потрібно виконати команду:
DENY CREATE TABLE ТЕ Sheridan CASCADE
При цьому будуть відкликані і всі дозволи, які Sheridan надав іншим користувачам.
Сервери баз даних займають свою нішу в інформаційній інфраструктурі підприємства. Часто в них зберігається конфіденційна інформація, порушення доступності, цілісності або конфіденційності якої може привести до значних фінансових втрат.
Оскільки SQL Server є досить складним продуктом, підвищення рівня його захисту раціональніше проводити у декілька етапів. У даному розділі описується методика поетапної настройки сервера по рівнях інформаційної інфраструктури:
Рекомендації по захисту програм виходять за рамки даного розділу, оскільки у великій мірі залежать від конкретної програми. Загальний підхід до розмежування доступу до об'єктів бази даних описаний в розділі, присвяченому аудиту.
Для підвищення мережевої безпеки сервера SQL Server необхідно вирішити наступні завдання:
Настройка мережевих бібліотек. Настройка мережевих бібліотек сервера здійснюється через утиліту SQL Server Network Utility. При виборі мережевих бібліотек необхідно виходити із завдань, які вирішуватимуться сервером. Наприклад, якщо сервер встановлений на одному комп'ютері з сервером Web і його єдине завдання — надавати Web-серверу дані для створення динамічних сторінок, можна очистити список використовуваних протоколів. Подібна настройка позбавить сервер можливості обміну по мережі, відповідно він не буде схильний до мережевих атак.
Якщо в завдання сервера входить мережева взаємодія, бібліотеки необхідно вибирати виходячи з того, які типи клієнтів працюватимуть з сервером.
І останній критерій — це можливості, підтримувані тими або іншими бібліотеками. Так, бібліотека TCP/IP дозволяє серверу задіювати SSL для шифрування трафіку і протоколу аутентифікації Kerberos. Бібліотека Named Pipes використовується для підтримки протоколу аутентифікації NTLM при взаємодії із застарілими клієнтами. Підтримка сервером бібліотеки Multiprotocol (RPC) дає серверу можливість захищати мережевий обмін засобами операційної системи.
Стандартно рекомендується використовувати мережеву бібліотеку TCP/IP і видалити всі останні. Це пов'язано з можливістю використання зловмисником додаткових мережевих бібліотек для компрометації сервера. Наприклад, якщо в мережі використовується TCP/IP і фільтрація трафіку настроєна таким чином, що з'єднання з портами SQL Server дозволене тільки з певних комп'ютерів, зловмисник зможе обійти це обмеження і з'єднатися з сервером, використовуючи бібліотеку Named Pipes через порти 137, 139, 445.
У настройках бібліотеки TCP/IP для кожного екземпляра сервера SQL можна вказати номер TCP-порту, на якому працює екземпляр. Додатково можна “заховати” екземпляр сервера, встановивши перемикач Hide server. Після настройки цього режиму екземпляр сервера автоматично настроюється на роботу через порт 2433 і не публікується через службу SQL Server Resolution Service (SRS UDP 1434). Використання даної настройки можливе тільки для одного екземпляра SQL Server на сервері.
Якщо задіяна настройка Hide Server, то при напрямі клієнтом широкомовного запиту з метою визначення екземплярів SQL Server в даному сегменті екземпляр йому не відповість. Але якщо користувач знає номер порту, на якому працює “захований” екземпляр (тобто порт 2433), він зуміє з ним з'єднатися.
Набагато ефективнішим методом заховання сервера є настроювання бібліотек TCP/IP на використання нетипових номерів портів (наприклад, в діапазоні вище 5000) з подальшою фільтрацією трафіку SQL SRS. Таким чином, з'єднатися з сервером можна буде, тільки знаючи використовуваний ним номер порту. Для централізованої настройки клієнтів можна задіювати адміністративний шаблон групової політики, що настроює клієнтські бібліотеки на роботу з використовуваним сервером номером порту шляхом зміни значення параметра реєстру
HKLM\SOFTWARE\Microsoft\
Проте слід розуміти, що дані настройки є елементом “політики заплутування” і не гарантують захисту, якщо зловмисник зуміє з'єднатися з сервером і застосувати евристичні методи визначення служб спеціалізованих утиліт, таких як nmap або XSpider.
Фільтрація трафіку. Фільтрація трафіку дає можливість заблокувати взаємодію з сервером SQL по невживаних мережевих протоколах, що підвищує рівень його захисту від атак через інші мережеві служби. Для фільтрації трафіку і розмежування доступу можна скористатися політикою протоколу IPSec або іншими засобами фільтрації трафіку рівня вузла, наприклад персональним міжмережевим екраном Internet Connection Firewall.
Якщо на сервері реалізована ретельно продумана політика фільтрації трафіку, це істотно обмежує можливості зловмисника. Так, якщо витікаючі з'єднання з сервера заборонені, не працюватимуть механізми злому, що використовують технологію зворотного з'єднання (reverse shell), і, крім того, зловмисник не зуміє організувати з'єднання зі своїм сервером для завантаження додаткових інструментів.
Для безпечнішого
розмежування мережевого доступу можна
задіювати механізми взаємної аутентифікації
клієнта і сервера з