2.1. Режими аутентифікації

SQL Server 2000 може використовувати два режими аутентифікації користувачів:

• режим аутентифікації засобами Windows (Windows Authentication);

• змішаний режим аутентифікації (Windows Authentication and SQL Server Authentication).

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

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

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

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

Режим аутентифікації SQL Server

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

При роботі з аутентифікацією SQL Server доступ також надається на основі облікових записів. Але в цьому випадку використовуються облікові записи SQL Server, а не Windows.

Для аутентифікації засобами SQL Server член стандартної ролі сервера sysadmin або securityadmin повинен створити і сконфігурувати для користувача обліковий запис, в який входить ім'я облікового запису, унікальний ідентифікатор SQL Server і пароль. Вся ця інформація зберігатиметься в системній базі master. Створюваний обліковий запис не має відношення до облікових записів Windows.

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

Аутентифікація SQL Server може застосовуватися в наступних випадках:

• для користувачів Novell NetWare, Unix і т. д.;

• при підключенні до SQL Server 2000 через Інтернет, коли реєстрація в домені не виконується;

• під управлінням операційної системи Windows 98.

В цьому випадку адміністратор SQL Server 2000 сам повинен періодично попереджати користувачів про необхідність змінити пароль, щоб забезпечити систему від несанкціонованого доступу, оскільки на відміну від Windows NT, в SQL Server відсутні подібні засоби системи безпеки.

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

Після установки SQL Server створюються дві стандартні облікові записи BUILTINNAdministrators і sa:

BUILT INNAdministrators — це обліковий запис Windows NT, що забезпечує автоматичний доступ всім членам групи Administrators до SQL Server. Обліковий запис BUILTINNAdministrators за умовчанням є членом вбудованої ролі сервера sysadmin. Таким чином, системні адміністратори дістають повний доступ до всіх баз даних. За ситуації, коли функції системного адміністратора і адміністратора баз даних виконують різні люди, швидше за все, слід виключити цей обліковий запис з ролі sysadmin, а можливо, і взагалі видалити.

sa — це спеціальний обліковий запис SQL Server для адміністратора. За умовчанням він привласнений вбудованій системній ролі сервера sysadmin і не може бути змінений. Цей обліковий запис збережений в цій версії SQL Server для збереження сумісності із програмами, написаними для попередніх версій. Хоча sа і має адміністративні права, її не рекомендується використовувати в SQL Server 2000. Замість цього слід створити нових користувачів і включити їх в адміністративну групу sysadmin. Обліковий запис sа потрібно залишити на крайній випадок, коли облікові записи адміністраторів виявляться недоступними або буде загублений пароль.

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