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

дата  і час події;

обліковий запис користувача;

тип події;

результат виконання дії (успішно чи ні);

місце події (наприклад, ім'я комп'ютера);

ім'я  об'єкту, до якого здійснювався доступ;

текст SQL-запроса (за винятком паролів).

Умовно їх можна  розділити на дві групи — події  управління і події роботи з об'єктами.

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

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

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

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

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

5. СТВОРЕННЯ ГНУЧКОЇ СИСТЕМИ БЕЗПЕКИ

 MS SQL SERVER 7.0/2000

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

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

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

Перший крок у формування системи безпеки  здійснюється на етапі інсталяції сервера  баз даних, коли вибирається механізм   аутентифікації для доступу користувачів до SQL Server. Аутентифікація SQL Server заснована на перевірці таких атрибутів облікового запису користувача, як account і password (пароль), які зберігаються в таблиці Sysxlogins бази даних master. Механізм аутентифікації Windows NT/2000 вимагає, щоб санкціонованість права доступу користувача перевіряв контролер домена. Взагалі, автор рекомендує завжди використовувати аутентифікацію Windows NT /2000 для інсталяцій, де сервер баз даних має мережеве підключення до контролера домена. Контролер домена може бути, як Win2K, так і NT сервер, тому що в обох випадках SQL Server аналізує спеціальний маркер доступу, який супроводжує список SID користувача, сформований протягом його аутентифікації, і SID групи домена, в яку користувач входить. Далі в документі буде показано, як SID використовується при доступі до бази даних SQL Server і при призначенні дозволів до об'єктів сервера. Особлива увага звертається на те, що абсолютно не важливе, як ОС формує маркер доступу. SQL Server використовує SID тільки в маркері доступу, не звертаючи увагу на те, який сервер йому цю інформацію надає. Можна використовувати будь-які поєднання SQL Server, 2000, SQL Server 7.0, Win2K і NT. Результат буде - той же самий.

Єдина вигода використання механізму власної аутентифікації SQL Server, це – простота її настройки  через Enterprise Manager. Головний недолік  такого механізму в тому, що аутентифікація SQL сервера локальна для кожного сервера баз даних, що створює труднощі у разі декількох обслуговуваних серверів SQL. Менший, але все ще істотніший недолік останнього механізму аутентифікації в тому, що користувач повинен управляти дозволами для кожної бази даних індивідуально. Якщо користувач потребує однакових дозволів для двох базах даних, потрібно буде призначати ці  дозволи уручну або формувати спеціальний сценарій, щоб призначати їх автоматично. Якщо не багато користувачів (менше 25-ти), і зміни відбуваються не часто, власна аутентифікація SQL Server може бути прийнятна. У всіх інших випадках (виключаються тільки випадки застосування спеціальних прикладних програм, які управляють захистом самостійно), значні труднощі адміністрування і управління логінами повністю перекривають вигоди власної аутентифікації SQL сервера.

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

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

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

Якщо використовується Microsoft IIS 5.0 або IIS 4.0, у адміністратора є чотири “важелі” для підтвердження  прав користувачів. Перший, повинен  бути спеціальним обліковим записом NT сервера для анонімних користувачів, причому для кожного сайту і віртуального каталогу. Всі програми використовуватимуть цей контекст захисту при зверненні до SQL серверу. Надаючи обліковому запису анонімного користувача NT відповідні дозволи, можна забезпечити ревізію дій цього облікового запису засобами ОС і отримаєте ті, що є у NT функціональні можливості управління обліковими записами.

Другий “важіль” - це наявність у кожного сайту  механізму основної аутентифікації, коли користувачі з Інтернет повинні  вводити в діалогове вікно  дійсні імена і паролі, перш ніж IIS надасть їм доступ на читання сторінки. IIS перевіряє відповідність права доступу кожного такого логіна правам в базі даних захисту NT сервера, яка може розміщуватися локально або на контролері домена. Коли користувач виконує програму або сценарій, який звертається до SQL серверу, IIS передає серверу баз даних права доступу цього користувача, допущеного до проглядання сторінки. Якщо використовується такий механізм, слід пам'ятати, що передача імені користувача і пароля між IIS і браузером не зашифрована і може бути перехоплена звичайним сніфером. Тому, необхідно забезпечити Secure Sockets Layer (SSL) на будь-якому Web сайті, який використовує основну аутентифікацію.

Якщо користувачі  використовують Microsoft Internet Explorer 5.0/4.0 або 3.0, адміністратор має третій “важіль”: аутентифікація NT спільно з аутентифікацією на Web-сайтах і віртуальних каталогах. IE передає IIS права доступу користувача, що реєструється на комп'ютері, а IIS використовує ці права всякий раз, коли користувач пробує звернутися до даних SQL сервера. Цим простим способом можна аутентифікувати користувачів в домені віддаленого сайту, якщо вони реєструватимуться в домені, який має трастові відношення з доменом Web сервера. Нарешті четвертий “важіль”. Якщо користувачі мають персональні цифрові посвідчення, то можна буде відображати ці посвідчення на облікові записи NT в локальному домені. Що базується на тій же самій технології, що і сервер цифрових посвідчень, персональний сертифікат перевіряє достовірність прав користувача і може замінити алгоритм аутентифікації (Виклику/відповіді) NT. У такому механізмі, користувач не повинен звертатися до домена, який знаходиться з ним в довірчих відносинах і навіть може не знати нічого про домен, в якому знаходиться IIS. Netscape navigator і IE автоматично посилають сертифікати до IIS з кожним запитом Web-сторінки. У постачання IIS входить інструментарій, який дозволяє адміністраторові відображати на обліковий запис NT цифрові сертифікати, замінюючи звичайний процес реєстрації за допомогою імені і пароля.

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

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

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

Найпростіший  шлях адміністрування дозволів доступу  груп користувачів, це створення глобальної групи домена, в яку входять  всі групи користувачів. Можна  створювати окремі групи для кожної прикладної програми або створювати групи, ширші категорії, що охоплюють, які присутні. Переважно створювати групи, які відносяться до прикладних програм так, щоб можна було точно знати, що можуть робити їх користувачі. Використовуючи приклад звичайної бухгалтерії, можна створити групи по іменах: 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 - ім'я бази даних на сервері). Також можна створювати і будь-які інші групи, якщо в них є потреба.

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

Для надання прав групам, які не мають явних логінів в системній таблиці Sysxlogins не можна використовувати Enterprise Manager, тому що він дозволяє здійснювати вибір тільки із списку існуючих логінів, а не з повного списку груп домена. Щоб звертатися до всіх груп, потрібно використовувати для надання необхідних привілеїв Query Analyzer і процедури sp_addsrvrolemember і sp_addrolemember, що зберігаються. (подробиці див. в SQL Server Books Online — BOL).

Для груп, об'єднуючих операторів серверів баз даних, використовуючи sp_addsrvrolemember, слід додати кожен їх логін відповідної ролі сервера. Логін групи SQL Server Administrators стає членом ролі Sysadmins, SQL Server DB Creators стає членом ролі Dbcreator, і SQL Server Security Operators стає членом ролі Securityadmin. Важливо пам'ятати, що другий параметр sp_addsrvrolemember вимагає повного найменування облікового запису. Наприклад, JOES в домені BigCo повинен бути названий bigco\joes. (Якщо використовуються локальні облікові записи, ім'я виглядало б так: server_name\joes.).

Щоб створювати користувачів, які автоматично заводитимуться у всіх нових базах даних, необхідно  використовувати базу Model. SQL Server автоматично  копіює все, що створюється для Model в  нові бази даних. Це значно спрощує  роботу адміністратора. Якщо правильно використовувати Model не потрібно буде настроювати кожну нову базу даних після її створення. Далі, використовуючи sp_addrolemember, потрібно додасте SQL Server Security Operators до db_securityadmin, а SQL Server Developers до db_owner ролі.

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

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

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

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