Статьи

Основи системи безпеки SQL Server

  1. Основи системи безпеки SQL Server

Навігація XServer.ru

Основи системи безпеки SQL Server

Багатьом системним адміністраторам Windows 2000 і Windows NT доводиться освоювати кілька спеціальностей, в тому числі займатися обслуговуванням Microsoft SQL Server. Розробники Microsoft автоматизували багато операцій SQL Server 7.0, тому керівники організацій, як правило, покладають виконання обов'язків DBA (адміністратора бази даних) на адміністраторів Windows 2000 і NT. У той же час обсяг конфіденційної інформації, що зберігається компаніями в базах даних SQL Server, збільшується. Тому, хто тільки починає працювати в якості DBA, ймовірно, буде корисно більше дізнатися про моделі безпеки SQL Server і про те, як правильно налаштувати конфігурацію захисту.

Модель безпеки SQL Server 7.0 значно змінилася в порівнянні з попередніми версіями продукту - вона більше нагадує систему безпеки Windows 2000 і NT. Я рекомендую SQL Server 7.0 всім компаніям, які використовують SQL Server 6.5, але не мають професійного адміністратора DBA, тому що з нею працювати набагато простіше. При підготовці статті була використана СУБД SQL Server 7.0 на NT 4.0, але все рекомендації відносяться і до Windows 2000. Цей матеріал актуальний і для SQL Server 2000, і для SQL Server 7.0, оскільки між ними немає суттєвих відмінностей, за винятком декількох діалогових вікон з позначенням 'Windows NT / 2000' замість 'Windows NT'.


У SQL Server передбачено три рівня безпеки. По-перше, користувачі повинні бути зареєстровані в SQL Server або мати дійсну обліковий запис в NT, з правом доступу SQL Server. Реєстрація в SQL Server не дає користувачам права звертатися до жодної з баз даних SQL Server. Дозвіл на доступ до БД видається користувачам на другому рівні захисту. На третьому рівні адміністратор може призначати права доступу до об'єктів в базі даних; наприклад, можна вказати, які таблиці та подання даних відкриті користувачеві і які процедури, що можуть виконувати члени групи. Ті ж три рівні безпеки передбачені в Windows 2000 і NT, тому знання про систему безпеки Windows застосовні і до SQL Server.

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

Щоб перевірити або змінити режим безпеки для системи SQL Server, слід відкрити оснастку SQL Server Enterprise Manager консолі Microsoft Management Console (MMC), натиснути правою кнопкою миші на імені сервера і вибрати пункт Properties. Потім потрібно вибрати закладку Security, як показано на Екрані 1. Щоб змінити режим безпеки, необхідно зупинити і перезапустити SQL Server (заново перезавантажувати комп'ютер не потрібно). У програмній папці SQL Server є утиліта Service Manager, якою можна скористатися для зупинки і перезапуску служби SQL Server, а також перезапуску служби SQL Server Agent (при зупинці сервера зупиняється і агент).

Екран 1
Екран 1. Вибір методу аутентифікації в змішаному режимі.

У SQL Server 7.0 групі NT можна призначити відповідну обліковий запис SQL Server. Призначати обліковий запис для кожного користувача не потрібно. Члени групи NT, яка має право звертатися до SQL Server, вдається з'єднатися, не вводячи ім'я і пароль. SQL Server відстежує користувачів за індивідуальними ідентифікаторами NT SID, а не по груповим SID, тому визначити автора конкретного зміни в SQL Server можна, навіть працюючи з групами, а не з окремими користувачами. Нові користувачі групи NT автоматично отримують доступ до SQL Server, а користувачі, віддалені з групи, втрачають права доступу до бази даних.

З огляду на можливі зв'язки між групами NT і SQL Server, для організації захисту SQL Server перш за все необхідно продумати стратегію доступу груп і користувачів NT. Слід організувати глобальні групи і розподілити користувачів по групах точно так же, як при призначенні дозволів в NTFS. Потім, щоб задати обліковий запис SQL Server для групи, слід відкрити оснастку SQL Server Enter-prise Manager. Якщо параметри безпеки SQL Server встановлені за замовчуванням, то адміністратор NT може зареєструватися в SQL Server як DBA.

У лівій панелі вікна Enterprise Manager слід відкрити папку Microsoft SQL Servers, розгорнути групу SQL Server Group, потім елемент для сервера, в якому потрібно задати обліковий запис, і потім папку Security. Далі я розповім, як за допомогою елемента Logins встановити відповідність між групами і користувачами NT і обліковими записами SQL Server і як призначати імена та паролі користувачам ОС відмінних від Windows.

Відразу ж під Logins знаходиться елемент Server Roles. Перш ніж додавати облікові записи, слід клацнути на Server Roles і познайомитися з різними ролями (див. Екран 2). Ці ролі схожі на спеціальні локальні групи NT (наприклад, оператори сервера і оператори резервного копіювання) тим, що підготовлені заздалегідь і мають задані права і привілеї. Не можна додати нові серверні ролі або змінити ролі, певні в SQL Server. Серверні ролі можна розглядати як локальні групи, в яких можуть розміщуватися глобальні групи Windows.


Екран 2. Знайомство з серверними ролями SQL Server.

Відкривши діалогове вікно з закладками подвійним клацанням миші на конкретній ролі, можна переглянути список наявних користувачів, доповнити його новими іменами і переглянути повноваження ролі. Роль System Administrators відповідає 'суперкористувачеві', який має право виконувати будь-які операції з SQL Server. Цю роль слід відвести тому, хто дійсно потребує адміністративних повноважень вищого рівня. Програмістам потрібно призначити роль Database Creators, щоб вони могли будувати тестові бази даних. Молодшим адміністраторам можна відвести роль Security Administrators і Server Administrators, щоб вони могли управляти властивостями і безпекою сервера, не маючи всіх прав системного адміністратора.

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

Щоб призначити обліковий запис групі або користувачеві NT, потрібно натиснути правою кнопкою миші на Logins і вибрати New Login, відкривши діалогове вікно SQL Server Login Properties - New Login, як показано на Екрані 3. На закладці General потрібно ввести з клавіатури ім'я. Список, звідки можна було б вибрати імена груп або користувачів NT, відсутня. Це упущення виправлено в SQL Server 2000, але поки ім'я доведеться ввести вручну. Якщо вказані група або користувач NT, то із списку слід вибрати ім'я домену, в який входить група або користувач. Після цього ім'я домену також з'явиться в поле Name, уточнюючи введене ім'я групи або користувача.

Екран 3
Екран 3. Призначення процедури реєстрації SQL Server.

Закладка General використовується також для дозволу або заборони доступу до SQL Server. Якщо один з членів групи не повинен мати доступу до SQL Server, то можна надати право на доступ групі, відмовивши в ньому одній особі. Як і в NT, будь-яка заборона доступу скасовує всі повноваження, отримані користувачем індивідуально або в складі групи.

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


Другий рівень захисту SQL Server - управління доступом до баз даних. SQL Server дозволяє працювати з декількома БД на сервері, тому, ймовірно, адміністратор забажає дозволити більшості користувачів доступ до одних баз даних, але заборонити звернення до інших. Рахунок в SQL Server не дає права на доступ до БД до тих пір, поки даної облікового запису користувача присвоєно право доступу до цієї бази даних. До вирішення цього завдання можна підійти з боку користувача або з боку бази даних. За допомогою діалогового вікна Login Properties користувача можна зареєструвати в декількох базах даних. Ними ж можна звернутися до бази даних, відкрити діалогове вікно New Database User і додати облікові записи тих користувачів, яким необхідний доступ до бази даних. На Екрані 4 показано, як надати користувачеві право на доступ до однієї або декількох баз даних за допомогою закладки Database Access діалогового вікна Login Properties.

Екран 4
Екран 4. Надання користувачеві права доступу до бази даних.

Додаючи облікові записи користувачів бази даних, їх можна поміщати в ролі БД - нова можливість, реалізована в SQL Server 7.0. Ролі бази даних, подібно до серверним ролям, можна розглядати як аналог локальним групам, в які поміщаються облікові записи SQL Server, в свою чергу, схожі на глобальні групи Windows. Роль бази даних, як і серверна роль, наділена набором заздалегідь визначених повноважень. Повноваження можна надати безпосередньо користувачам, але в багатьох випадках просте призначення користувачеві відповідної ролі дає йому всі необхідні права. Користувач може бути членом декількох груп і накопичувати повноваження різних ролей. Заборона, отриманий в будь-якій ролі, скасовує всі повноваження інших ролей. Як і серверні ролі, заздалегідь певні ролі бази даних змінити не можна. Можна створювати ролі баз даних з будь-якими повноваженнями, але зазвичай адміністратори намагаються комбінувати існуючі ролі, щоб забезпечити користувачеві саме той рівень доступу, який йому потрібен. Належність ролі можна змінити в будь-який момент; задаючи обліковий запис в базі даних, немає необхідності призначати їй все ролі.

Загальна роль public бази даних схожа на Everyone в NT. SQL Server поміщає в цю роль будь-який обліковий запис, якій дозволено доступ до бази даних. Не можна видалити користувачів з цієї ролі або знищити саму роль. За замовчуванням, роль public не має прав доступу до жодної зі створених адміністратором БД. Виняток становить база даних Northwind, зображена на Екрані 4; це тестова база даних, і передбачається, що інформацію в ній можуть переглядати всі бажаючі.

Облікові записи користувачів, яким необхідно отримувати інформацію з бази даних, поміщаються в роль db_datareader. Облікові записи користувачів, яким потрібна змінювати дані, повинні бути включені як в роль db_datareader, так і в роль db_datawriter. Якщо потрібно надати право доступу до бази даних всій групі, крім одного з її членів, можна помістити обліковий запис SQL Server для групи в ролі db_datareader і db_datawriter, а обліковий запис 'отказника' - в ролі db_denydatareader і db_denydatawriter.

Із застосуванням ролей db_datareader і db_datawriter пов'язана одна потенційна проблема. У деяких базах даних для підвищення безпеки використовуються уявлення (views). Подання - заздалегідь складений список елементів, які дозволено бачити користувачеві. Наприклад, поданням може бути підмножина даних в таблиці, що показує лише частина стовпців. Коли для посилення захисту застосовуються уявлення, користувачі не мають прямого доступу до таблиць бази даних. Замість цього їм призначаються спеціальні дозволи для доступу до уявлень. При цьому ролі db_datareader і db_datawriter використовувати не можна, так як вони забезпечують доступ до всіх таблиць бази даних.

Адміністратор може побажати делегувати частину своїх повноважень з управління базою даних. Дві ролі бази даних передають обмежені повноваження будь-якого члена цих ролей. Член ролі db_accessadmin може додати існуючий обліковий запис SQL Server до бази даних в якості користувача. Потім член ролі db_securityadmin може призначити будь-якому користувачеві бази даних конкретні повноваження по відношенню до таких об'єктів, як таблиці та подання. Якщо потрібно, щоб одна людина виконував обидва завдання, його можна зареєструвати в обох ролях.

Роль db_backupoperator концептуально не відрізняється від групи NT Backup Operator. Члени цієї ролі можуть читати базу даних тільки для резервного копіювання і не мають інших прав доступу до даних. Роль db_backupoperator дає право на створення резервної копії даних, але не на її відновлення. Це завдання для DBA або власника бази даних.

Для роботи з тестовою або проектованої базою даних, а також в разі, якщо програмісти вносять зміни в робочу базу даних, слід використовувати роль db_ddladmin. Члени цієї ролі можуть створювати, змінювати і видаляти об'єкти бази даних. У роль db_owner нікого включати не потрібно. Кожен об'єкт SQL Server має власника, і за замовчуванням власником бази даних стає користувач, який створив її.

За допомогою оснащення SQL Server Enterprise Manager можна з'ясувати повноваження кожної ролі бази даних. Пояснення ролей наведені в оперативному підпорядкуванні SQL Server Books Online (BOL). Доступ до BOL можна отримати з програмної папки SQL Server 7.0 або за допомогою підказок Help в Enterprise Manager. Якщо заздалегідь визначених ролей недостатньо, адміністратор може або призначити повноваження безпосередньо користувачам, або ввести власні ролі бази даних, наділити їх необхідними повноваженнями і потім призначити користувачів для цих ролей. Щоб додати роль з Enterprise Manager, потрібно розгорнути базу даних, натиснути правою кнопкою миші на Roles і вибрати пункт New Database Role. У діалоговому вікні слід ввести ім'я нової ролі, вибрати пункт Standard Role і перерахувати користувачів, чиї облікові записи повинні бути включені в цю роль. Перш ніж визначати повноваження, необхідно вийти з діалогового вікна і створити роль. Потім слід двічі клацнути на ролі і призначити повноваження. Безумовно, до цієї операції можна повернутися пізніше і змінити як склад ролі, так і призначені їй права.


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

Щоб призначити повноваження користувачеві, слід розкрити дерево в SQL Server Enterprise Manager і вибрати елемент Users для потрібної бази даних. У правій панелі потрібно двічі клацнути на імені користувача і відкрити діалогове вікно Database User Properties. Щоб вивести на екран користувача повноваження для об'єкта бази даних, потрібно клацнути на кнопці Permissions. Діалогове вікно показано на Екрані 5. Слід пам'ятати, що в цьому інтерфейсі показані лише повноваження, надані даному користувачеві індивідуально. У вікні не наводяться повноваження, якими користувач має як член однієї або декількох ролей або груп NT. Насправді, отримати повний список повноважень користувача в SQL Server непросто.

Щоб надати користувачеві право на читання таблиці або подання даних, потрібно встановити прапорець SELECT. Якщо користувач повинен змінювати дані, то звичайно треба відзначити прапорці INSERT, UPDATE і DELETE. Співробітникам, відповідальним за введення даних, можна надати право вводити записи, але не змінювати або видаляти їх. Видалення записів можна довірити більш досвідченому співробітнику, який наділений відповідними посадовими повноваженнями. Щоб заблокувати надходження видаляти дані, потрібно двічі клацнути на прапорці DELETE, після чого в ньому з'являється червоний значок X, як показано на Екрані 5. Питання для користувача повноважень варто обговорити з програмістами; якщо вони вбудували в додатки захисні механізми, задіяні в процесі оновлення бази даних, то, ймовірно, адміністратору не потрібно дублювати їх зусилля. Однак вбудовані засоби захисту бази даних надійніше, так як користувач не може отримати доступ до даних, обійшовши або змінивши додатки. Як видно з таблиці Permissions, користувач Caesar може вибрати з таблиці Customer і додати або оновити дані про споживачів, але не може видалити запис про споживача. Крім того, Caesar не в змозі оновлювати запис Employe Territories, але він може належати до групи, що володіє таким правом.

Екран 5
Екран 5. Призначення повноважень корістувачеві.

У стовпці EXEC табліці Permissions вказані права на Виконання Збереження процедур. Збережені процедури - це складені на мові T-SQL підпрограми SQL Server, які можуть бути викликані з додатків для виконання операцій в базі даних. Вони дуже ефективні і забезпечують додатковий рівень безпеки. Якщо збережені процедури складені, то деяким користувачам слід надати право Execute для їх запуску.

Як правило, стовпець Declarative Referential Integrity (DRI - декларативна посилальна цілісність) можна ігнорувати, якщо тільки програмісти не дають інших рекомендацій. Іноді користувач вводить дані в одну з таблиць, а SQL Server повинен перевірити дані в іншій таблиці. Наприклад, якщо користувач вводить номер елемента в таблицю замовлень, то SQL Server повинен звернутися до таблиці продуктів для перевірки введеного номера. Щоб перевірка була можлива, користувач повинен мати повноваження Select в таблиці продуктів і повноваження Insert в таблиці замовлень. У деяких випадках користувачі можуть потребувати повноваження для посилань на іншу таблицю, щоб перевірити елемент даних, але не повинні мати права на читання таблиці безпосередньо. У цих випадках користувачеві необхідно замість Select мати повноваження DRI.

Сподіваюся, що пропонований огляд системи безпеки SQL Server допоможе читачам в розробці стратегії безпеки власної бази даних. Наступним кроком може бути створення сценарію SQL Server. Клацнувши правою кнопкою миші на базі даних в оснащенні SQL Server Enterprise Manager, слід вибрати елементи All Tasks і Generate SQL Scripts. Ця функція будує сценарій, яким можна скористатися для регенерації бази даних, в тому числі і політики безпеки. Потім слід з'ясувати, як запускати сценарії у вікні Query Analyzer. При необхідності можна виконати лише частину сценарію, призначену для управління параметрами безпеки. За допомогою сценарію можна всього за кілька секунд завершити роботу, виконання якої в оснащенні SQL Server Enterprise Manager зайняло б кілька годин.

Майкл Д. Рейлі - позаштатний редактор Windows 2000 Magazine і SQL Server Magazine, співзасновник і віце-президент компанії Mount Vernon Data Systems.


Література по SQL Server

Новости