Первая страница
Наша команда
Контакты
О нас

    Головна сторінка



N держреєстрації

N держреєстрації




Сторінка13/18
Дата конвертації10.03.2017
Розмір1.8 Mb.
1   ...   10   11   12   13   14   15   16   17   18

2.1.10. Роль вузла-бастіону


Цей розділ присвячений зміцненню безпеки вузлів-бастіонів з Microsoft® Windows Server™ 2003 з пакетом оновлення 1 (SP1). Вузли-бастіони — це захищені загальнодоступні комп'ютери, розташовані на зовнішній стороні демілітаризованої зони організації. Ця зона також відома як проміжна підмережа. Вузли-бастіони повністю відкриті для атак, оскільки вони не захищені ні брандмауерами, ні маршрутизаторами, що фільтрують.
Маршрутиза́тор, або ро́утер (англ. router) - електронний пристрій, що використовується для поєднання двох або більше мереж і керує процесом маршрутизації, тобто на підставі інформації про топологію мережі та певних правил приймає рішення про пересилання пакетів мережевого рівня (рівень 3 моделі OSI) між різними сегментами мережі.
Щоб звести до мінімуму вірогідність зламу, вузли-бастіони необхідно ретельно проектувати і настроювати.

Такі вузли часто використовуються як веб-сервери, DNS-сервери, FTP-сервери, SMTP-сервери і NNTP-сервери. Рекомендується призначати вузлам-бастіонам тільки одну з вказаних функцій. Чим більше функцій виконує сервер, тим більше вірогідність залишити непоміченою слабке місце в системі безпеки. Забезпечити захист однієї служби на одному вузлі-бастіоні простіше, ніж якщо таких служб декілька. Мережева архітектура з декількома вузлами-бастіонами надає організаціям додаткові переваги.

Протокол передачі файлів (англ. File Transfer Protocol, FTP) - дає можливість абоненту обмінюватися двійковими і текстовими файлами з будь-яким комп'ютером мережі, що підтримує протокол FTP. Установивши зв'язок з віддаленим комп'ютером, користувач може скопіювати файл з віддаленого комп'ютера на свій, або скопіювати файл зі свого комп'ютера на віддалений.
З метою стандартизації взаємодії компонентів комп’ютерних мереж (принципів та правил) була розроблена модель мережевої архітектури під назвою «еталонна модель взаємодії відкритих систем» (OSI). OSI базується на моделі, яка була запропонована Міжнародним інститутом стандартів (ISO).

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

У наступних розділах даного розділу приводиться опис різних параметрів безпеки, що дозволяють укріпити безпеку вузлів-бастіонів в будь-якому середовищі. В розділі також описуються дії, необхідні для створення вузла-бастіону SMTP. Для діставання додаткових можливостей необхідно внести зміни до файлів конфігурації, поширювані з даним керівництвом.

Ролі серверів, описані раніше в даному документі, використовують групову політику для настройки серверів. Проте групову політику не можна застосувати до серверів вузлів-бастіонів, оскільки вони настроєні як ізольовані вузли, що не входять в домен служби каталогів Active Directory®. Такі сервери відкриті і не захищені за допомогою яких-небудь пристроїв. Тому існує тільки один варіант забезпечення безпеки серверів вузлів-бастіонів для трьох середовищ, що розглядаються в даному керівництві. Параметри безпеки, описані в цьому розділі, засновані на базовій політиці рядових серверів для середовища SSLF. Відомості про MSBP див. в розділі 3 «Базова політика рядових серверів». Ці параметри містяться в шаблоні безпеки, який необхідно застосувати до локальної політики кожного вузла-бастіону (BHLP).

Середовище застарілих клієнтів

Середовище корпоративних клієнтів

Спеціальне безпечне середовище з обмеженою функціональністю

SSLF-Bastion Host.inf

SSLF-Bastion Host.inf

SSLF-Bastion Host.inf

Таблиця 11.1. Шаблони безпеки для сервера вузла-бастіону

Параметри політики аудиту BHLP для вузлів-бастіонів містяться у файлі SSLF-Bastion Host.inf. Значення цих параметрів співпадають із значеннями, вказаними у файлі SSLF-Member Server Baseline.inf . Додаткові відомості про політика MSBP див. в розділі 3 «Базова політика рядових серверів». Параметри політики BHLP забезпечують ведення журналу аудиту на всіх серверах вузлів-бастіонів із записом тих, що всіх відносяться до безпеки даних.

2.2. Захист SQL Server

2.2.1. Загальні положення


Система управління базами даних Microsoft SQL Server 2000 має різноманітні засоби забезпечення захисту даних. Цей розділ присвячений детальному знайомству з системою безпеки SQL Server 2000.

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

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

Інжене́рія (від лат. ingenium - здібність, винахідливість; син. - інжиніринг, рідше вживають «інженерна справа», ще рідше «інженерство») - галузь людської інтелектуальної діяльності по застосуванню досягнень науки до вирішення конкретних проблем людства.
Ло́гіка (грец. λογιχη від грец. logos - слово, значення, думка, мова) - наука про закони і різновиди мислення, способи пізнання та умови істинності знань і суджень.
Щоб дозволити цим користувачам звертатися до сервера, необхідно створити для них облікові записи в SQL Server або надати їм доступ за допомогою облікових записів в домені, якщо використовується система безпеки Windows NT. Дозвіл доступу до сервера не дає автоматично доступу до бази даних і її об'єктів.

Другий етап планування системи безпеки полягає у визначенні дій, які може виконувати в базі даних конкретний користувач. Повний доступ до бази даних і всіх її об'єктів має адміністратор, який є свого роду господарем бази даних, — йому дозволено все.

Господа́р або Госуда́р (давньорус. господаръ; лат. dominus; рос. государь) - слов'янський титул правителя. Використовувався монархами Східної Європи - воєводами Молдовського князівства, правителями Волощини, князями Галицько-Волинського князівства, Великого князівства Литовського і Великого князівства Московського.
Струсі (пол. Strusiowie) - шляхетський рід у Польському Королівстві, згодом Речі Посполитій. Рід походить з Коморова (тоді Белзьке князівство). В документах представники роду згадуються як Струсі з Коморова (наприклад, Миколай Струсь з Коморова).
Друга людина після адміністратора — це власник об'єкту. При створенні будь-якого об'єкту в базі даних йому призначається власник, який може встановлювати права доступу до цього об'єкту, модифікувати його і видаляти. Третя категорія користувачів має права доступу, видані їм адміністратором або власником об'єкту.

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

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

Повнова́ження - офіційно надане кому-небудь право певної діяльності, ведення справ.
Не зайвим також буде передбачити додаткові засоби захисту, наприклад, не дозволяти видаляти дані, якщо термін їх зберігання не закінчився, тобто вони не втратили актуальність. Можна також надавати службовцям, які недавно влаштувалися на роботу, мінімальний доступ або доступ тільки в режимі читання. Пізніше їм можна буде вирішити і зміну даних.

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

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

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


2.2.2. Архітектура системи безпеки SQL Server


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

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

Отже, на рівні сервера система безпеки оперує наступними поняттями:


  • аутентифікація (authentication);

  • обліковий запис (login);

  • вбудовані ролі сервера (fixed server roles).

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

  • користувач бази даних (database user);

  • фіксована роль бази даних (fixed database role);

  • призначена для користувача роль бази даних (users database role);

  • роль програми (application role).

2.2.3. Компоненти структури безпеки


Фундаментом системи безпеки SQL Server 2000 є облікові записи(login), користувачі (user), ролі (role) і групи (group). Користувач, що підключається до SQL Server, повинен ідентифікувати себе, використовуючи обліковий запис. Після того, як клієнт успішно пройшов аутентифікацію, він дістає доступ до SQL Server. Для діставання доступу до будь-якої бази даних обліковий запис користувача (login) відображається в користувача даної бази даних (user). Об'єкт “користувач бази даних” застосовується для надання доступу до всіх об'єктів бази даних: таблицям, уявленням, процедурам, що зберігаються, і так далі. В користувача бази даних може відображатися:

  • обліковий запис Windows NT;

  • група Windows NT;

  • обліковий запис SQL Server.

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

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

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

Користувачі

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



Ім'я користувача може використовуватися для надання доступу, як конкретній людині, так і цілій групі людей (залежно від типу облікового запису).

При створенні бази даних визначаються два стандартні користувачі: dbо і guest.

Якщо обліковий запис (login) не зв'язується явно з користувачем (user), останньому надається неявний доступ з використанням гостьового імені guest. Тобто всі облікові записи, що дістали доступ до SQL Server 2000, автоматично відображаються в користувачів guest у всіх базах даних. Якщо буде видалений з бази даних користувач guest, то облікові записи, що не мають явного відображення облікового запису в ім'я користувача, не зможуть дістати доступу до бази даних. Проте, guest не має автоматичного доступу до об'єктів. Власник об'єкту повинен сам вирішувати, дозволяти користувачеві guest цей доступ чи ні. Зазвичай користувачеві guest надається мінімальний доступ в режимі “тільки читання”.

Для забезпечення максимальної безпеки можна видалити користувача guest з будь-якої бази даних, окрім системних баз даних master і Tempdb. У першій з них guest використовується для виконання системних процедур, що зберігаються, звичайними користувачами, тоді як в другій дозволяє створювати будь-яким користувачам тимчасові об'єкти.



Власник бази даних (DataBase Owner, DBO) — спеціальний користувач, що володіє максимальними правами в базі даних. Будь-який член ролі sysadmin автоматично відображається в користувача dbo. Якщо користувач, що є членом ролі sys admin, створює який-небудь об'єкт, то власником цього об'єкту призначається не даний користувач, а dbo. Наприклад, якщо Liliya, член адміністративної групи, створює таблицю Таblеa, то повне ім'я таблиці буде не Liliya.ТаblеA, а dbo.ТаblеA. В той же час, якщо Liliya, не будучи учасником ролі сервера sysadmin, полягає в ролі власника бази даних db_owner, то ім'я таблиці буде LiIiуа.ТаblеA.

Користувача dbo не можна видалити.

Для пов'язання облікового запису (login) з певним ім'ям користувача (user) можна скористатися наступною процедурою, що зберігається:

sp_adduser [@loginame =] 'login' [,[@name_in_db =] 'user'] [.[@grpname =] 'role']

Нижче дається пояснення використовуваних в ній параметрів:


  • login — ім'я облікового запису, який необхідно пов'язати з ім'ям користувача бази даних;

  • user — ім'я користувача бази даних, з яким асоціюється даний обліковий запис (у базі даних заздалегідь не повинно існувати користувача з вказаним ім'ям);

  • role — цей параметр визначає роль, в яку даний користувач буде включений (докладніше про ролі буде розказано пізніше). Процедура sp_grantdbaccess, що зберігається, дозволяє відобразити обліковий запис Windows NT в ім'я користувача:

sp_grantdbaccess [@loginame =] 'login' [,[@name_in_db =] 'user']

Параметри означають наступне:



  • login — ім'я облікового запису користувача або групи користувачів Windows NT, яким необхідно надати доступ до бази даних. Ім'я повинне забезпечуватися посиланням на домен, в якому обліковий запис визначений. Вказаному обліковому запису не обов'язково повинен бути наданий персональний доступ до SQL Server. Цілком можливо, що з'єднання з сервером встановлюється унаслідок членства в групі Windows NT, яка має доступ до сервера;

  • user — ім'я користувача бази даних, з яким асоціюється даний обліковий запис.

Користувач, який створює об'єкт в базі даних, наприклад таблицю, процедуру, що зберігається, або уявлення, стає власником об'єкту. Власник об'єкту (database object owner) має всі права доступу до створеного ним об'єкту. Щоб користувач міг створити об'єкт, власник бази даних (dbo) повинен надати користувачеві відповідні права. Повне ім'я створюваного об'єкту включає ім'я користувача, що створив його.
Ство́рення (англ. Creation, нім. Schöpfung, івр. בריאת העולם‎) - доктринальна позиція у багатьох релігіях та філософських системах вірувань, яка твердить, що за створенням всесвіту стоїть Божество. Богословські пояснення створення всесвіту можуть мати різноманітні форми, однією з основних є релігійна догма створення.
Якщо користувач хоче звернутися до таблиці, використовуючи тільки її ім'я і не указуючи власника, SQL Server застосовує наступний алгоритм пошуку:

    1. Шукається таблиця, створена користувачем, що виконує запит;

    2. Якщо таблиця не знайдена, то шукається таблиця, створена власником бази даних (dbo).

Допустимо, користувач Liss намагається звернутися до таблиці Liliya.TableA, просто використовуючи ім'я TablеА. Оскільки таблиця, створена Liliya, не відповідає ні першому, ні другому критерію пошуку, то таблиця TableA знайдена не буде і користувач отримає повідомлення про помилку. Для діставання доступу до таблиці необхідно ввести ім'я, що включає власника об'єкту, тобто Liliya.TableA.

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

SQL Server дозволяє передавати права володіння від одного користувача іншому.

Пра́во володі́ння (лат. ius possidendi) - забезпечена законом можливість мати у себе певну річ, утримувати її у своєму господарському підпорядкуванні (фактично тримати річ, зараховувати на баланс та ін.)
Щоб видалити власника об'єкту з бази даних, спочатку необхідно видалити всі об'єкти, які він створив, або передати права на їх володіння іншому користувачеві. Для цього можна використовувати процедуру sp_changeobjectowner, що має наступний синтаксис, що зберігається:

sp_changeobjectowner [ @objname = ] 'object', [ (Pnewowner = ] 'owner'

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

Си́нтаксис (дав.-гр. σύνταξις - "побудова, порядок, складання", від σύν - "з, разом" і ταξις - "впорядкування") - розділ граматики, що вивчає граматичну будову словосполучень та речень у мові.

2.2.4. Ролі сервера


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

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

У попередніх версіях SQL Server для адміністрування сервера можна було використовувати тільки обліковий запис sa або його аналог. Інакше кажучи, можна було дати або всі права, або ніяких. Тепер в SQL Server ця проблема вирішена шляхом додавання ролей сервера (server role), які дозволяють надати операторам сервера тільки ті права, які адміністратор порахує можливим надати. Ролі сервера не мають відношення до адміністрування баз даних. Можна включити будь-який обліковий запис SQL Server (login) або обліковий запис Windows NT в будь-яку роль сервера.

Стандартні ролі сервера (fixed server role) і їх права приведені в табл. 2.14.

Таблиця 2.14

Вбудована роль сервера

Призначення

Sysadmin

Може виконувати будь-які дії в SQL Server

Serveradmin

Виконує конфігурацію і виключення сервера

Setupadmin

Управляє зв'язаними серверами і процедурами, що автоматично запускаються при старті SQL Server

Securityadmin

Управляє обліковими записами і правами на створення бази даних, також може читати журнал помилок

Processadmin

Управляє процесами, запущеними в SQL Server

Dbcreator

Може створювати і модифікувати бази даних

Diskadmin

Управляє файлами SQL Server

Bulkadmin(Bulk Insert administrators)

Ця роль не існувала в SQL Server 7.0. Члени ролі Bulkadmin можуть вставляти дані з використанням засобів масивного копіювання, не маючи безпосереднього доступу до таблиць

2.2.5. Ролі баз даних


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

У роль бази даних можна включати:



  • користувачів SQL Server;

  • ролі SQL Server;

  • користувачів Windows NT;

  • групи Windows NT, яким заздалегідь наданий доступ до потрібної бази даних.

Засоби Enterprise Manager дозволяють додавати в роль бази даних тільки користувачів бази даних (user). Потрібно використовувати процедуру sp_addrolemember, що зберігається, щоб задіяти всі можливості SQL Server 2000:

sp_addrolemember [@ro1ename =] 'role', [@membername =] 'security_account'

Тут параметри означають наступне:


  • role— назва ролі SQL Server в поточній базі даних;

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

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

Таблиця 2.15.



Вбудована роль баз даних

Призначення

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.2.5. Ролі програми


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

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

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.2.6. Захист даних


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

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

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

  • будь-які дані, передавані між сервером і клієнтом по мережі;

  • паролі облікових записів SQL Server або ролей програми;

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

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

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

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

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


2.2.3. Обмеження доступу до файлів SQL Server


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

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

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

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


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

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



  • права на доступ до об'єктів баз даних;

  • права на виконання команд TRANSACT-SQL;

  • неявні права (дозволи).

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

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

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

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

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

2.2.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.

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

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


2.2.3.3. Заборона доступу


Система безпеки SQL Server має ієрархічну структуру.
Ієра́рхія (грец. ίεράρχίά, від ίερσς - священний, та άρχή - влада) - поділ на вищі й нижчі посади, чини; суворий порядок підлеглості нижчих щодо посади або чину осіб вищим. В ієрархії між її членами діють вертикальні зв'язки - відносини субординації.
Це дозволяє ролям бази даних включати облікові записи і групи Windows NT, користувачів і ролі SQL Server. Користувач же, у свою чергу, може брати участь в декількох ролях. Наслідком ієрархічної структури системи безпеки є те, що користувач може одночасно мати різні права доступу для різних ролей. Якщо одна з ролей, в яких полягає користувач, має дозвіл на доступ до даним, то користувач автоматично має аналогічні права. Проте, може потрібно заборонити можливість доступу даним. Коли забороняється користувачеві доступ до даним або командам TRANSACT-SQL (deny access), тим самим анулюються всі дозволи на доступ, отримані користувачем на будь-якому рівні ієрархії. При цьому гарантується, що доступ залишиться забороненим незалежно від дозволів, наданих на більш високому рівні.

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


2.2.4. Підвищення рівня захисту Microsoft SQL Server


Сервери баз даних займають свою нішу в інформаційній інфраструктурі підприємства.
Інформаці́йна інфраструкту́ра (англ. information infrastructure) - комплекс програмно-технічних засобів, організаційних систем та нормативних баз, який забезпечує організацію взаємодії інформаційних потоків, функціонування та розвиток засобів інформаційної взаємодії та інформаційного простору країни або організації.
Часто в них зберігається конфіденційна інформація, порушення доступності, цілісності або конфіденційності якої може привести до значних фінансових втрат.

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



  • захист мережевого обміну;

  • захист операційної системи;

  • захист компонентів бази даних;

  • захист програм, що використовують базу даних.

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

2.2.4.1. Захист мережевого обміну


Для підвищення мережевої безпеки сервера 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.


2.2.4.2. Захист операційної системи


При підвищенні рівня захисту базової операційної системи необхідно вирішити наступні завдання:

  • налаштувати системні служби;

  • налаштувати права користувачів і дозволи файлової системи;

  • налаштувати шифрування файлів бази даних.

Настройка системних служб і прав користувачів. Microsoft SQL Server встановлюється і функціонує як декілька системних служб. Для кожного екземпляра бази даних створюється служба з ім'ям, утвореним по схемі MSSQL$<имя екземпляра>. Так само створюються екземпляри SQL Server Agent (SQLAgent$< ім'я екземпляра>), що відповідають за виконання періодичних завдань, таких як автоматична архівація, підтримка бази даних і так далі.
Преса - друковані засоби масової інформації (періодичні друковані видання), які виходять під постійною назвою, з періодичністю один і більше номерів (випусків) протягом року. Під пресою розуміють газети, журнали, альманахи, збірки, бюлетені, рідше книги, листівки, що мають визначений наклад.

Крім того, для сервера в цілому створюються служби Microsoft Search (відповідає за індексування і пошук документів в тому випадку, якщо включена підтримка повнотекстового пошуку) і DTS (служба, що відповідає за підтримку розподілених транзакцій).

Служба MSSQL може працювати в контексті облікового запису Local System або від імені облікового запису користувача (доменного або локального). Дуже небажано застосовувати для запуску служб обліковий запис LocalSystem, як і будь-який інший обліковий запис з адміністративними повноваженнями. Це пов'язано з тим, що у разі компрометації сервера всі дії в системі проводитимуться від імені цього запису, тобто зловмисник працюватиме з адміністративними привілеями.

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

На сервері бажано відключити служби, які для роботи SQL Server не потрібні. Їх список приведений в табл. 2.16.

Таблиця 2.16.





Шифрування баз даних. Для захисту файлів бази даних на фізичному рівні має сенс зашифрувати їх. У операційній системі Windows 2000/2003 передбачена можливість шифрування бази даних за допомогою шифруючої файлової системи. Encrypting File System — надбудова над NTFS, що дозволяє в прозорому для користувача режимі шифрувати і розшифровувати файли на жорсткому диску комп'ютера.
Тверди́й диск або Тверди́й магні́тний диск, або Накопичувач на магнітних дисках (англ. Hard (magnetic) disk drive, англ. HDD), у комп'ютерному сленгу - «вінчестер» (від англ. winchester), - магнітний диск, основа якого виконана з твердого матеріалу.

Для використання цієї можливості необхідно:



  1. Налаштувати службу SQL Server на запуск від імені облікового запису користувача.

  2. Увійти до системи, використовуючи даний обліковий запис.

  3. Використовуючи “Провідник”, відкрити властивості теки Program Files\microsoft sql server\<имя экземпляра>\Data або інший, де збережені бази даних.

  4. Встановити для каталогу атрибут (Properties — Advanced — Encrypt contents to secure data).

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

2.2.4.3. Захист компонентів бази даних


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

Потім необхідно вирішити, чи будуть члени групи локальних адміністраторів мати доступ до сервера бази даних з привілеями системних адміністраторів.

Систе́мний адміністра́тор (від англ. system administrator, systems administrator) - працівник, посадові обов’язки якого передбачають забезпечення роботи комп’ютерної техніки, комп’ютерної мережі і програмного забезпечення в організації.
Автоматично створюваний серверний обліковий запис Bultin/Administrators рекомендується видалити. Ця рекомендація зв'язана, перш за все, з обов'язковою присутністю в даній групі облікового запису локального адміністратора, чий пароль може бути вмить змінений у разі наявності у зловмисника фізичного доступу або підібраний по мережі. Після того, як зловмисник дістане доступ до системи від імені цього облікового запису, він зможе обійти всі захисні механізми, включаючи шифрування баз даних за допомогою EFS.

З обліковим записом локального адміністратора зв'язані і інші проблеми, дізнатися про яких докладніше можна із статті “Локальная угроза” опублікованою в Windows & .NET Magazine/RE №3 за 2003 рік. Перед видаленням облікового запису Bultin/Administrators необхідно створити серверний обліковий запис на основі доменної групи і привласнити їй роль System Administrator.

Наступним етапом є видалення стандартних баз даних, що входять в дистрибутив як приклади.

Дистрибутив (англ. distribute - розповсюджувати) - форма розповсюдження програмного забезпечення.
До них відносяться бази даних NorthWind і pubs. Дані бази містять ряд помилок, мають слабкі дозволи і часто використовуються зловмисниками для атак.

Потім необхідно заборонити виконання запитів типу AdHoc. Такі запити (OPENROWSET, OPENQUERY і OPENDATASOURCE) дозволяють серверу встановлювати з'єднання із зовнішнім сервером і зберігати на нім свої дані. Вони дуже рідко використовуються в програмах, але можуть бути застосовані зловмисником для видаленого отримання інформації з баз даних сервера. Прикладом застосування подібної техніки є програма Data Thief, що використовує метод впровадження SQL-кода (SQL Injection) для виконання запитів AdHoc.

2.2.4.4. Аудит сервера SQL Server


Існує декілька різних методів настройки аудиту в базах даних SQL Server. Кращим рішенням є використання комбінацій даних методів залежно від вирішуваних завдань. За умовчанням аудит на сервері не активізований.

Аудит аутентифікації сервера дозволяє відстежувати спроби аутентифікації на сервері SQL. Включити його можна через Enterprise Manager або шляхом модифікації параметра реєстру HKLM\Software\Microsoft\MSSQLServer\MSSQLServer\ Audit Level. Можливі значення 0...3.

Нульове значення параметра означає відключення аудиту, 1 — запис вдалих спроб аутентифікації, 2 — невдалих. При значенні параметра 3 включається аудит всіх спроб реєстрації.

Реєстра́ція - запис, фіксація фактів або явищ з метою обліку та надання їм статусу офіційно визнаних актів (реєстрація народження або шлюбу); внесення в список, в книгу обліку.

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

Інший тип аудиту відноситься до подій сервера баз даних. Настроювати і відстежувати їх можна за допомогою утиліти SQL Profiler.

2.2.5. Створення гнучкої системи безпеки MS SQL Server


Захист SQL Server повинен бути простий для адміністрування. У нових версіях SQL Server, з'явився цілий набір гнучких і могутніх методів управління доступом користувачів до ресурсів SQL Server і базам даних. Ці нововведення викликали якесь замішання адміністраторів серверів баз даних, оскільки вони пробували перенести на нову версію сервера модель захисту SQL Server 6.5. Не повне розуміння відмінностей механізмів захисту SQL Server 7.
Розумі́ння - психологічний стан, який виражає собою правильність ухваленого рішення і супроводжуваний відчуттям упевненості в точності сприйняття або інтерпретації якої-небудь події, явища, факту.
0/2000 і SQL Server 6.5 привело до того, що в бізнес програмах з'явилися “дірки” для не санкціонованого доступу до даних.

2.2.5.1. Вибір схеми аутентифікації


Слід звернути увагу на принципову відмінність термінів “аутентифікація” і “авторизація”. Аутентифікація – це підтвердження наявності права у користувача. Авторизація – це визначення можливості допуску користувача до операцій над об'єктами, до набору яких він пройшов аутентифікацію. В даному випадку, аутентифікація відбувається тоді, коли користувач підключається до SQL Server, а авторизація відбуваються всякий раз, коли користувач намагається звертатися до даних або виконує команди.

Перший крок у формування системи безпеки здійснюється на етапі інсталяції сервера баз даних, коли вибирається механізм   аутентифікації для доступу користувачів до SQL Server. Аутентифікація SQL Server заснована на перевірці таких атрибутів облікового запису користувача, як account і password (пароль), які зберігаються в таблиці Sysxlogins бази даних master.


2.2.5.2. Web-аутентифікация


Мабуть, найбільшою небезпекою несанкціонованого доступу до даних є уявлення їх в Web-сторінках по запиту користувачів до SQL Server з Інтернет. Особливої ролі тут набуває організація правильної Web-аутентифікації. На жаль, типовим способом аутентифікації з Інтернет полягає в тому, щоб упровадити логін до SQL Server і його пароля в Web-server-based програму, таку, як: Active Server Pages (ASP) або Common Gateway Interface сценарій (CGI).
Active Server Pages (ASP, укр. активні серверні сторінки) - це технологія від компанії Microsoft, що дозволяє динамічно формувати автоматично оновлювані веб-сторінки з боку веб-сервера. Технологія подається у формі додатку до веб-серверу Internet Information Services (IIS).
Сервер Web бере на себе відповідальність за аутентифікацію користувача, тоді, як програма використовує її власний логін (часто це або systems administrator або логін в Sysadmin ролі сервера) щоб звернутися до даним сервера для надання звіту користувачеві в Інтернет.

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

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

2.2.5.3. Збір користувачів в групи


Наступний крок у формуванні системи безпеки полягає у виділенні груп, в які будуть поміщені облікові записи користувачів, схожих за типом доступу до даних або об'єднаних використанням однієї програми. Зазвичай, прикладна програма має таких користувачів, як: оператори введення даних, адміністратори введення даних, укладачі звітів, бухгалтери, ревізори, і адміністратори доступу.
Бухга́лтер (нім. Buchhalter, Buch - книга, Halter - тримач) - керівник операційних робітників, контролер законності і правильності здійснення операцій у банку, організатор технології цих операцій не тільки у своєму відділенні банку, але і на підприємствах та в організаціях, які обслуговує даний банк.
Застосунок, застосовна програма, прикладна програма (англ. application, application software; пол. aplikacja; рос. приложение, прикладная программа) - користувацька комп'ютерна програма, що дає змогу вирішувати конкретні прикладні задачі користувача.
Кожна група потребує різних прав доступу до бази даних.

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

Грýпа перв́инна - група, в якій відбувається первинна соціалізація індивідів і відносини носять інтимний, особовий, неформальний характер. Основною метою членів групи є взаємне спілкування.
Як правило, рекомендуються наступні групи: SQL Server Administrators, SQL Server Users, SQL Server Denied Users, SQL Server DB Creators, SQL Server Security Operators, SQL Server Database Security Operators, SQL Server Developers, і DB_Name Users (де DB_Name - ім'я бази даних на сервері). Також можна створювати і будь-які інші групи, якщо в них є потреба.


2.2.5.4. Надання доступу до баз даних


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

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


2.2.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, а також індивідуальні облікові записи.

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

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


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


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

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

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

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

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

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

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

1   ...   10   11   12   13   14   15   16   17   18



  • 2.2.1. Загальні положення
  • 2.2.2. Архітектура системи безпеки SQL Server
  • 2.2.3. Компоненти структури безпеки
  • 2.2.4. Ролі сервера
  • 2.2.3. Обмеження доступу до файлів SQL Server
  • 2.2.3.1. Права доступу
  • 2.2.3.2. Права на доступ до обєктів баз даних
  • 2.2.3.3. Заборона доступу
  • 2.2.4. Підвищення рівня захисту Microsoft SQL Server
  • 2.2.4.1. Захист мережевого обміну
  • 2.2.4.2. Захист операційної системи
  • 2.2.4.3. Захист компонентів бази даних
  • 2.2.4.4. Аудит сервера SQL Server
  • 2.2.5. Створення гнучкої системи безпеки MS SQL Server
  • 2.2.5.1. Вибір схеми аутентифікації
  • 2.2.5.2. Web-аутентифікация
  • 2.2.5.3. Збір користувачів в групи
  • 2.2.5.4. Надання доступу до баз даних
  • 2.2.5.5. Призначення дозволів
  • 2.2.5.6. Проста система безпеки