Безпека в Microsoft SQL Server 2005
- Авторизація та аутентифікація
- Шифрування трафіку і даних
- Ізоляція облікових записів від об'єктів бази даних
- Виконання коду з мінімальними привілеями
- аудит
- приховування метаданих
- Наступні оновлення засобів безпеки
- Порівняння з іншими СУБД
- Трохи загальних міркувань
Наталія Єлманова
Авторизація та аутентифікація
Шифрування трафіку і даних
Ізоляція облікових записів від об'єктів бази даних
Виконання коду з мінімальними привілеями
аудит
приховування метаданих
Наступні оновлення засобів безпеки
Порівняння з іншими СУБД
Трохи загальних міркувань
Як, можливо, вже відомо багатьом нашим читачам, на початку листопада відбувся офіційний вихід Microsoft SQL Server 2005. Ця подія, на наш погляд, важливе, бо системи управління базами даних традиційно відносяться до категорії продуктів, нові версії яких випускаються не дуже часто, оскільки підвищені вимоги до надійності програмного забезпечення подібного класу є причиною дуже ретельного підходу до його проектування, розробки та тестування. Випуск нової версії СУБД через п'ять років після попередньої, як це сталося з SQL Server, - явище цілком звичайне. І, оскільки питання безпеки за ці п'ять років стали чи не найактуальнішими у всіх областях людської діяльності (згадаймо щоденні повідомлення про зломи мереж і витоках конфіденційних і корпоративних даних), представляється логічним з'ясувати, що нового з цієї точки зору дана СУБД пропонує IT- менеджерам, адміністраторам і розробникам додатків. Тим більше що в порівнянні з SQL Server 2000 (дуже хорошим, на нашу думку, продуктом навіть за сучасними мірками) в модель безпеки SQL Server 2005 внесені істотні поліпшення.
Авторизація та аутентифікація
Аутентифікація - це процес перевірки права користувача на доступ до тієї чи іншої ресурсу, який найчастіше (хоча і не завжди) здійснюється за допомогою введення імені та пароля.
Як і попередні версії, SQL Server 2005 підтримує два режими аутентифікації: аутентифікація за допомогою Windows і аутентифікація за допомогою SQL Server.
Перший з режимів є рекомендованим: саме він дозволяє реалізувати рішення, засноване на одноразової реєстрації користувача і на єдиному паролі доступу до різних програм (Single Sign-On solution, SSO), що спрощує роботу користувачів, позбавляючи їх від запам'ятовування безлічі паролів і знижуючи ризик зберігання . Крім того, даний режим дозволяє використовувати доступні адміністраторам Windows механізми формування груп, застосування політик безпеки для доменів, таких як управління складністю пароля і часом його існування, блокування облікових записів, а також застосування захищених протоколів аутентифікації за допомогою шифрування паролів, наприклад Kerberos або NT LAN Manager (NTLM).
Аутентифікація за допомогою SQL Server призначена для клієнтських додатків, що функціонують на платформах, відмінних від Windows. Хоча цей спосіб і вважають за краще багато розробників додатків, він вважається менш безпечним, проте в новій версії SQL Server даний спосіб аутентифікації підтримує шифрування за допомогою сертифікатів, згенерованих сервером. Скористатися ним можна, якщо клієнтські програми застосовують нову версію MDAC (Microsoft Data Access Components) 2.8. Шифрування всіх повідомлень, якими обмінюються клієнт і сервер, також підвищує надійність цього способу аутентифікації.
Для облікового запису SQL Server можна вказати такі параметри команди CREATE / ALTER LOGIN, як необхідність змінити пароль при першому з'єднанні з сервером, необхідність перевірки терміну дії пароля, необхідність застосування локальної пральний політики Windows (рис. 1). Останні два параметри можна повноцінно використовувати, якщо SQL Server 2005 виконується під управлінням Windows Server 2003.
Мал. 1. Установка правил поведінки пароля користувача
Нарешті, тепер обов'язково потрібно непорожній пароль користувача sa - як не банальна помилка, пов'язана зі збереженням порожнього пароля, її занадто часто роблять адміністратори баз даних (і, зрозуміло, використовують різного роду зловмисники).
Після аутентифікації користувача відбувається процес авторизації, тобто визначення, до яких ресурсів даний користувач має право доступу. Контроль доступу до ресурсів за допомогою авторизації передбачає зберігання даних такого роду в надійному джерелі, причому, як правило, в зашифрованому вигляді.
Шифрування трафіку і даних
SQL Server 2005 містить вбудовані засоби шифрування, цифрового підпису та верифікації даних за допомогою симетричних ключів (підтримуються алгоритми шифрування RC4, RC2, DES, AES) і асиметричних ключів (алгоритм RSA).
Як вже було сказано, весь трафік між клієнтом і сервером за замовчуванням шифрується із застосуванням протоколів IP Security (IP SEC) і Secure Sockets Layer (SSL), і подібна функціональність доступна у всіх редакціях продукту. Протокол SSL підтримується за допомогою інтеграції зі службами Internet Information Services (IIS) або за допомогою сервера сертифікатів, що підтримує стандарт X.509v3 і входить до складу SQL Server 2005. Згенеровані сертифікати не тільки використовуються для створення SSL-з'єднань - їх застосовує і SQL Service Broker .
Відзначимо, що при необхідності можна визначити політику безпеки, повністю забороняє обмін незашифрованими даними між клієнтом і сервером, що знижує ризик витоку даних, отриманих шляхом перехоплення трафіку.
SQL Server 2005 також підтримує шифрування самих даних, що зберігаються, повністю інтегроване з інфраструктурою управління ключами. Для цього він містить шість вбудованих функцій: EncryptByCert, DecryptByCert, EncryptByKey, DecryptByKey, EncryptByAssym і DecryptByAssym, що дозволяють використовувати шифрування за допомогою сертифіката, симетричного і асиметричного ключів в коді Transact-SQL.
Ізоляція облікових записів від об'єктів бази даних
У більшості сучасних серверних СУБД у кожного об'єкта бази даних є користувач-власник, який може надавати іншим користувачам права доступу до об'єктів бази даних. Набір об'єктів, що належать одному і тому ж користувачеві, називається схемою. При цьому для серверних СУБД сьогодні стандартним є механізм ролей - наборів прав доступу до об'єктів бази даних, що привласнюються в сукупності того чи іншого користувача. Даний спосіб володіння об'єктами створював певні незручності адміністраторам і розробникам додатків: з одного боку, після звільнення співробітника, який створив об'єкти, що використовуються багатьма користувачами, при видаленні відповідної облікового запису доводилося вносити зміни в серверний код (а нерідко і в код клієнтського додатка), а з інший - далеко не всім користувачам потрібні власні схеми. Знаючи про потенційні проблеми супроводу схем і облікових записів, багато замовників рішень, що використовують бази даних, стали останнім часом наполягати на «наколінних» (не побоїмося цього слова!) Реалізаціях способів управління обліковими записами користувачів, аж до зберігання їх імен і паролів в звичайних таблицях, що різко підвищувало загрозу несанкціонованого доступу до даних і додатків.
У SQL Server 2005 концепція ролей розширена - ця СУБД дозволяє повністю відокремити користувача від схем і об'єктів бази даних. Тепер об'єкти бази даних належать не користувачеві, а схемою, яка не має стосунку до облікового запису користувача (рис. 2), тоді як користувач може бути асоційований зі схемою. Таким чином, схема стає не більше ніж механізмом угруповання об'єктів відповідно до розв'язуваної завданням, що спрощує надання користувачам та ролям прав на доступ до об'єктів. Крім того, подібний механізм спрощує дозвіл імен та дозволяє зберігати об'єкти загального користування в схемі, яка не має ніякого відношення до адміністративних привілеїв.
Мал. 2. Встановлення прав для схем даних
Виконання коду з мінімальними привілеями
Одним з базових принципів створення безпечних додатків є принцип надання мінімальних привілеїв, необхідних для вирішення поставленого завдання. Цей принцип реалізований в більш строгих, в порівнянні з попередніми версіями, настройках за умовчанням. Так, в новій версії SQL Server за замовчуванням вимкнено значна кількість функцій, наприклад застосування Microsoft .NET Framework в ядрі СУБД, функції SQL Service Broker Network Connectivity, доступ до аналітичних служб за допомогою протоколу HTTP. Такі служби, як SQL Server Agent, Data Transformation Services, засоби повнотекстового пошуку, після установки сервера знаходяться в режимі ручного запуску.
Ще одна новація SQL Server 2005, яка реалізує принцип мінімальних привілеїв, дозволяє виконувати збережені процедури і функції, визначені користувачем, з правами іншого користувача - для цієї мети є оператор EXECUTE AS. До того ж SQL Server 2005 дозволяє вказати контекст безпеки, в якому будуть виконуватися ті чи інші оператори програмного модуля, тобто облікового запису, що використовується при перевірці дозволів на об'єкти, на які посилається процедура або функція (наприклад, облікового запису користувача, який викликав процедуру, або облікового запису користувача, який створив процедуру, або іншого облікового запису).
Дана функціональність може застосовуватися в якості засобу забезпечення безпечного управління правами користувачів. Наприклад, рішення такої часто зустрічається завдання, як надання доступу до процедури без надання доступу до тієї таблиці, яку використовує дана процедура, вирішується за допомогою EXECUTE AS без необхідності надання користувачам процедури додаткових привілеїв.
Виконання .NET-коду в ядрі СУБД вимагає при завантаженні збірки вказівки одного з трьох рівнів безпеки: SAFE (доступ до зовнішніх ресурсів не допускається), EXTERNAL_ACCESS (доступ до файлів, мережевих ресурсів, реєстру, змінним оточення) або UNSAFE (доступ до всіх ресурсів , в тому числі до некерованого коду). Якщо збірка в процесі роботи вийде за зазначені при її завантаженні параметри безпеки, то Common Language Runtime згенерує виняток і виконання коду збірки припиниться.
аудит
Аудит - досить поширений спосіб виявлення некоректних або неавторизованих дій користувачів, особливо тих, хто має надлишкові привілеї.
SQL Server 2005 підтримує кілька способів підтримки аудиту (рис. 3). Зокрема, можна використовувати Windows Security EventLog (механізм відстеження звернень до об'єктів, застосування прав, спроб аутентифікації) і SQL Profiler (засіб здійснення детального аудиту спроб доступу до об'єктів БД).
Мал. 3. Вибір подій бази даних для аудиту
Для здійснення аудиту корисним може виявитися ще один новий механізм, що з'явився в SQL Server 2005, - це тригери, пов'язані зі зміною метаданих (DDL-тригери). Створення таких тригерів дозволяє відстежувати спроби зміни метаданих користувачами або повністю забороняти їх.
приховування метаданих
У SQL Server 2005 Системні об'єкти знаходяться в прихованій базі mssqlsystemresource, а користувачам доступні уявлення Catalog Views для звернення до системних таблиць, причому дані з цих уявлень фільтруються в залежності від того, хто робить запит. Є і спеціальний дозвіл VIEW DEFINITION, що дозволяє обійти приховування метаданих всієї БД, схеми або конкретного об'єкта.
Наступні оновлення засобів безпеки
При створенні сучасних СУБД, так само як і багатьох інших продуктів, виробники зазвичай планують, що з появою нових загроз засоби безпеки продуктів доведеться оновлювати. Оновлення безпеки SQL Server знайти і встановити нескладно, а якщо вибрати відповідну опцію, то ці оновлення будуть завантажуватися з сайту виробника і встановлюватися автоматично.
Порівняння з іншими СУБД
Звичайно, SQL Server - не єдина хороша серверна СУБД на ринку програмного забезпечення. Так, СУБД масштабу підприємства випускають IBM, Oracle, Sybase. Засоби забезпечення безпеки в SQL Server 2005 теж не унікальні, що ілюструється таблицею, в якій представлено наявність засобів забезпечення безпеки в SQL Server 2005 і в різних редакціях Oracle 10g.
Засоби забезпечення безпеки Oracle і SQL Server
Відзначимо, однак, що перераховані механізми безпеки і засоби їх адміністрування доступні у всіх редакціях SQL Server 2005, включаючи безкоштовну редакцію Express Edition і відносно недорогі версії Workgroup Edition і Standard Edition, які цілком під силу придбати навіть невеликим підприємствам, тоді як аналогічні механізми і утиліти Oracle 10g присутні тільки в найбільш дорогої редакції цієї СУБД.
Трохи загальних міркувань
Питання безпеки при використанні СУБД (як, втім, і питання безпеки в цілому) не є чисто технологічними - проблеми з їх рішенням часто виникають через недостатню компетентність і відповідальності людей, які застосовують технології (згадаємо хоча б паролі, записані на прикріплених до моніторів листочках ), так само як і через дії співробітників, свідомо порушують правила безпеки з метою отримання особистої вигоди. Крім того, забезпечення безпеки, як правило, ускладнює самим же співробітникам виконання завдань, перешкоджає доступу до потрібних їм для цього даних і функцій. Нерідко розумний компроміс між безпекою та доступністю функцій, додатків і даних виявляється набагато складнішим, ніж технологічна реалізація того чи іншого способу захисту даних, так що вміння адміністратора баз даних застосувати можливості сервера грає в цьому випадку важливу роль.
Некомпетентність чи неакуратність розробників додатків часом є значно більш серйозну загрозу безпеці, ніж легковажність кінцевих користувачів. Саме тому ми вважаємо доречним нагадати кілька базових принципів, що забезпечують безпеку додатків, які застосовують СУБД:
- відмова від динамічно сформованих запитів на користь збережених процедур або параметрезованих запитів;
- застосування регулярних виразів в клієнтських додатках для перевірки користувальницького введення до того, як він буде відправлений у СУБД;
- застосування екранування спеціальних символів;
- перевірка користувальницького введення засобами сервера;
- перевірка відповідності типів даних, що вводяться типам в СУБД;
- відмова від генерації команд, які виконуються на сервері, безпосередньо з введених користувачем даних.
Іншими словами, не дивлячись на те, що SQL Server 2005 задовольняє всім сучасним вимогам забезпечення безпеки, не варто тішити себе ілюзіями: саме по собі впровадження цього продукту не захистить компанію від усіх загроз. Але при грамотному застосуванні цей продукт дійсно спростить роботу і розробникам додатків, і адміністраторам баз даних.
КомпьютерПресс 11'2005