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 аутентифікації, як основного засобу підтвердження прав користувачів на доступ до сервера баз даних.