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

Автор: Пользователь скрыл имя, 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

Работа содержит 1 файл

Технічні рішення щодо захисту сервера баз даних SQL Server.doc

— 350.50 Кб (Скачать)

Після створення  базу даних потрібно використовувати  процедуру sp_grantdbaccess, що зберігається, для надання доступу групі DB_Name Users. Важливо, що не існує зворотної  по сенсу процедури sp_denydbaccess, так що не можливо заборонити доступ до бази таким же чином, як це робилося по відношенню до сервера. Якщо необхідно заборонити доступ до бази даних, то потрібно створити іншу глобальну групу на ім'я DB_Name Denied Users, надати їй доступ до бази даних, і зробити її членом ролей db_denydatareader і db_denydatawriter. Потрібно бути обережним при призначенні операторних дозволів, з огляду на те, що ці ролі обмежують тільки доступ до об'єктів, а не до інструкцій Data Definition Language (DDL).

Як і у  випадку з логінами, SQL Server надає користувачеві доступ до бази даних, якщо його SID в маркері співпадає із записом в системної таблиці Sysusers. Таким чином, можна надавати користувачам доступ до бази даних через їх персональний обліковий запис NT, що має свій SID, або через SID будь-якої групи NT, членом якої він є. Для простоти управління необхідно створити одну глобальну групу на ім'я DB_Name Users, яка матиме доступ до бази даних, і не варто надавати доступ до цієї бази іншим групам. Так можна буде дуже просто додавати, і видаляти користувачів бази даних, визначаючи їх приналежність до однієї глобальної групи.

5.5. Призначення  дозволів

Останній крок в настройці системи безпеки  сервера баз даних полягає  в створенні призначених для  користувача ролей баз даних  і призначенні ним дозволів. Найпростіший спосіб, це створити ролі з назвами, які відповідають іменам глобальних груп. Використовуючи приклад бухгалтерії: створені ролі по іменах: Accounting Data Entry Operators, Accounting Data Entry Managers, і так далі. Тут можна використовувати скорочені назви, тому що ролі в бухгалтерській базі даних, ймовірно, стосуються тільки бухгалтерії. Проте якщо ці імена повністю відповідають іменам глобальних групи, виникатиме менше плутанини, і можна буде легше визначати приналежність групи ролі бази даних.

Після створення  ролей можна буде призначати дозволи. На цьому кроці допустиме використання тільки стандартних дозволів GRANT, REVOKE, і DENY. Потрібно бути обережним з DENY, тому що воно має найвищий пріоритет  перед всіма іншими дозволам. SQL Server заборонить доступ користувачеві до об'єктів бази, якщо він є членом будь-якої ролі або групи зі встановленим дозволом DENY. Також, якщо модернізується використовувана в SQL Server 6.5 система безпеки, слід пам'ятати, що механізми призначення і застосування дозволів у SQL Server 7.0, і SQL Server 6.5 мають істотні відмінності.

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

Рекомендується  використовувати тільки дві вбудовані  ролі бази даних (db_securityadmin і db_owner). Причина  в тому, що вбудовані ролі звертаються  до бази даних в цілому, а не до її об'єктів. Наприклад, db_datareader надає дозвіл SELECT для кожного об'єкту бази даних. Можна було використовувати db_datareader для вибіркової заборони SELECT конкретним користувачам або групам, але цей метод чреватий тим, що можете просто забути встановити необхідні дозволи для деяких користувачів або об'єктів. Простіше кажучи, менш схильним помилкам методом є створення призначених для користувача ролей для певних категорій користувачів і призначення ним дозволів, через які вони дістануть доступ до тих об'єктів, в яких ці категорії має потребу.

5.6. Проста  система безпеки

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

Основні правила системи безпеки

1. Користувачі  дістають доступ сервера через групу SQL Server Users, а доступ до бази даних через групу DB_Name Users.

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

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

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

ВИСНОВОК

Підвищення  рівня захисту програм на основі Microsoft SQL Server 2000 є досить складним завданням і в значній мірі залежить від програми, що працює на його базі. Краще всього тут діяти за принципом “відключити все зайве і помалу включати, поки не запрацює”. Процес цей досить довгий і вимагає деякої практики, проте настроєні таким чином сервери можуть працювати роками, не вимагаючи додаткової уваги.

 

IPSec або  SSL v 3.0?

  • SSL підтримується клієнтськими бібліотеками SQL Server, відповідно може використовуватися будь-якій ОС сімейства Windows. IPSec підтримується Windows 2000 і вище.
  • SSL використовується для захисту трафіку SQL-сервера як програми. IPSec захищає взаємодію на мережевому рівні (наприклад, по певних портах). Тому у разі реконфігурації сервера (зміни настройок мережевих бібліотек) необхідно змінювати і настройки IPSec.
  • IPSec підтримує взаємну аутентифікацію клієнта і сервера. У разі використання IPSec можна додатково розмежовувати доступ за допомогою прав Windows. У SSL реалізована тільки аутентифікація сервера.

IPSec при використанні ESP підтримує два протоколи захисту  даних, DES і 3DES. SSL не дозволяє вибрати алгоритм захисту.




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