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

Національна академія наук України

Інститут  програмних систем НАН України

ЗАТВЕРДЖЕНО

05540149.90000.043.И3-01-АЗ

Програма  інформатизації НАН України

Проект  «Розробка та впровадження типових  рішень

щодо  комплексної системи захисту  інформації в АІС НАНУ»

Шифр –КСЗІ  АІС НАНУ

Технічні  рішення щодо захисту  сервера баз даних

 SQL Server 

05540149.90000.043.И3-03

2008

Зміст

1. ПРАВИЛА БЕЗПЕКИ

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

Аналогічні  вимоги існують і щодо розмежування доступу до інформації усередині підприємства. Деяка інформація може бути доступна всьому персоналу, можливо, навіть і клієнтам. Інша частина інформації не повинна виходити за рамки відділу. Наприклад, доступ до всієї інформації по заробітній платі співробітників повинен мати тільки працівник бухгалтерії, що займається її нарахуванням. Решта всіх співробітників підприємства в цьому випадку володіє інформацією тільки про розмір своєї заробітної плати. Третя категорія інформації є строго конфіденційною і повинна бути доступна тільки певним людям. Прикладом може служити відомості про власні оригінальні розробки і технології, які організація прагне вберегти від конкурентів. Вихід такої інформації за межі організації може принести великі збитки.

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

У сучасних умовах, коли інформація має величезне значення, вживання заходів для запобігання  несанкціонованому доступу, попередження втрати або пошкодження інформації стають невід'ємною частиною роботи будь-якої організації. За даними статистики, в США 80 % компаній, що втратили інформацію, припиняли свою діяльність протягом року. Серед тих 20-%, що залишилися, близько половини проіснувала не більше 4 років.

Останнім часом  все більше підприємств відмовляються  від паперових сховищ інформації і переходять до комп'ютерної обробки документів. Система зберігання інформації повинна бути максимально захищена як від випадкового, так і від зловмисного пошкодження або спотворення інформації. При створенні бази даних розробник повинен спланувати її так, щоб будь-який користувач не міг зробити що-небудь, не маючи на це відповідних прав. Не слід сподіватися на компетентність користувача і його порядність. Можливе виправлення або видалення даних не по злому наміру, а просто із-за неуважності або помилки. Система, наскільки це можливо, повинна перешкоджати подібним діям.

Система управління базами даних Microsoft SQL Server 2000 має різноманітні засоби забезпечення захисту даних.

Загальні правила розмежування доступу

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

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

Другий етап планування системи безпеки полягає у визначенні дій, які може виконувати в базі даних конкретний користувач. Повний доступ до бази даних і всіх її об'єктів має адміністратор, який є свого роду господарем бази даних, — йому дозволено все. Друга людина після адміністратора — це власник об'єкту. При створенні будь-якого об'єкту в базі даних йому призначається власник, який може встановлювати права доступу до цього об'єкту, модифікувати його і видаляти. Третя категорія користувачів має права доступу, видані їм адміністратором або власником об'єкту.

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

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

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

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

2. АРХІТЕКТУРА СИСТЕМИ БЕЗПЕКИ SQL SERVER 2000

Система безпеки SQL Server 2000 базується на користувачах і облікових записах. Користувачі проходять наступні два етапи перевірки системою безпеки. На першому етапі користувач ідентифікується по імені облікового запису і паролю, тобто проходить аутентифікацію. Якщо дані введені правильно, користувач підключається до SQL Server. Підключення до SQL Server, або реєстрація, не дає автоматичного доступу до баз даних. Для кожної бази даних сервера реєстраційне ім'я (або обліковий запис — login) повинне відображатися в ім'я користувача бази даних (user). На другому етапі, на основі прав, виданих користувачеві як користувачеві бази даних (user), його реєстраційне ім'я (login) отримує доступ до відповідної бази даних. У різних базах даних login одного і того ж користувача може мати однакові або різні імена user з різними правами доступу.

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

Отже, на рівні  сервера система безпеки оперує наступними поняттями:

• аутентифікація (authentication);
• обліковий запис (login);
• вбудовані ролі сервера (fixed server roles).

На рівні  бази даних використовуються наступні поняття:

• користувач бази даних (database user);
• фіксована роль бази даних (fixed database role);
• призначена для користувача роль бази даних (users database role);
• роль програми (application role).

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 під час установки сервера, і цей пароль завжди був порожнім.

2.2. Компоненти  структури безпеки

Фундаментом системи  безпеки SQL Server 2000 є облікові записи(login), користувачі (user), ролі (role) і групи (group). Користувач, що підключається до SQL Server, повинен ідентифікувати себе, використовуючи обліковий запис. Після того, як клієнт успішно пройшов аутентифікацію, він дістає доступ до SQL Server. Для діставання доступу до будь-якої бази даних обліковий запис користувача (login) відображається в користувача даної бази даних (user). Об'єкт “користувач бази даних” застосовується для надання доступу до всіх об'єктів бази даних: таблицям, уявленням, процедурам, що зберігаються, і так далі. В користувача бази даних може відображатися:

• обліковий запис Windows;
• група Windows;
• обліковий запис SQL Server.

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

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

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

Користувачі

Після того, як користувач пройшов аутентифікацію і отримав ідентифікатор облікового запису (login ID), він вважається зареєстрованим і йому надається доступ до сервера. Для кожної бази даних, до об'єктів якої користувачеві необхідно дістати доступ, обліковий запис користувача (login) асоціюється з користувачем (user) конкретної бази даних. Користувачі виступають як спеціальні об'єкти SQL Server, за допомогою яких визначаються всі дозволи доступу і володіння об'єктами в базі даних.

Ім'я  користувача може використовуватися для надання доступу, як конкретній людині, так і цілій групі людей (залежно від типу облікового запису).

При створенні  бази даних визначаються два стандартні користувачі: dbо і guest.

Якщо обліковий  запис (login) не зв'язується явно з користувачем (user), останньому надається неявний доступ з використанням гостьового імені guest. Тобто всі облікові записи, що дістали доступ до SQL Server 2000, автоматично відображаються в користувачів guest у всіх базах даних. Якщо буде видалений з бази даних користувач guest, то облікові записи, що не мають явного відображення облікового запису в ім'я користувача, не зможуть дістати доступу до бази даних. Проте, guest не має автоматичного доступу до об'єктів. Власник об'єкту повинен сам вирішувати, дозволяти користувачеві guest цей доступ чи ні. Зазвичай користувачеві guest надається мінімальний доступ в режимі “тільки читання”.

Для забезпечення максимальної безпеки можна видалити користувача guest з будь-якої бази даних, окрім системних баз даних master і Tempdb. У першій з них guest використовується для виконання системних процедур, що зберігаються, звичайними користувачами, тоді як в другій дозволяє створювати будь-яким користувачам тимчасові об'єкти.

Власник бази даних (DataBase Owner, DBO) — спеціальний користувач, що володіє максимальними правами в базі даних. Будь-який член ролі sysadmin автоматично відображається в користувача dbo. Якщо користувач, що є членом ролі sys admin, створює який-небудь об'єкт, то власником цього об'єкту призначається не даний користувач, а dbo. Наприклад, якщо Liliya, член адміністративної групи, створює таблицю Таblеa, то повне ім'я таблиці буде не Liliya.ТаblеA, а dbo.ТаblеA. В той же час, якщо Liliya, не будучи учасником ролі сервера sysadmin, полягає в ролі власника бази даних db_owner, то ім'я таблиці буде LiIiуа.ТаblеA.

Користувача dbo не можна видалити.

Для пов'язання облікового запису (login) з певним ім'ям користувача (user) можна скористатися наступною процедурою, що зберігається:

sp_adduser [@loginame =]  'login' [,[@name_in_db =] 'user'] [.[@grpname =] 'role']

Нижче дається  пояснення використовуваних в ній параметрів:

• login — ім'я облікового запису, який необхідно пов'язати з ім'ям користувача бази даних;
• user — ім'я користувача бази даних, з яким асоціюється даний обліковий запис (у базі даних заздалегідь не повинно існувати користувача з вказаним ім'ям);
• role — цей параметр визначає роль, в яку даний користувач буде включений (докладніше про ролі буде розказано пізніше). Процедура sp_grantdbaccess, що зберігається, дозволяє відобразити обліковий запис Windows NT в ім'я користувача:

sp_grantdbaccess [@loginame =]   'login' [,[@name_in_db =] 'user']

Параметри означають  наступне:

• login — ім'я облікового запису користувача або групи користувачів Windows NT, яким необхідно надати доступ до бази даних. Ім'я повинне забезпечуватися посиланням на домен, в якому обліковий запис визначений. Вказаному обліковому запису не обов'язково повинен бути наданий персональний доступ до SQL Server. Цілком можливо, що з'єднання з сервером встановлюється унаслідок членства в групі Windows NT, яка має доступ до сервера;
• user — ім'я користувача бази даних, з яким асоціюється даний обліковий запис.

Користувач, який створює об'єкт в базі даних, наприклад  таблицю, процедуру, що зберігається, або  уявлення, стає власником об'єкту. Власник об'єкту (database object owner) має всі права доступу до створеного ним об'єкту. Щоб користувач міг створити об'єкт, власник бази даних (dbo) повинен надати користувачеві відповідні права. Повне ім'я створюваного об'єкту включає ім'я користувача, що створив його. Якщо користувач хоче звернутися до таблиці, використовуючи тільки її ім'я і не указуючи власника, SQL Server застосовує наступний алгоритм пошуку:

1. Шукається таблиця, створена користувачем, що виконує запит;
2. Якщо таблиця не знайдена, то шукається таблиця, створена власником бази даних (dbo).

Допустимо, користувач Liss намагається звернутися до таблиці Liliya.TableA, просто використовуючи ім'я TablеА. Оскільки таблиця, створена Liliya, не відповідає ні першому, ні другому критерію пошуку, то таблиця TableA знайдена не буде і користувач отримає повідомлення про помилку. Для діставання доступу до таблиці необхідно ввести ім'я, що включає власника об'єкту, тобто Liliya.TableA.

Власник об'єкту не має ніякого спеціального пароля або особливих прав доступу. Він неявно має повний доступ, але повинен явно надати доступ іншим користувачам.

SQL Server дозволяє  передавати права володіння від  одного користувача іншому. Щоб  видалити власника об'єкту з  бази даних, спочатку необхідно  видалити всі об'єкти, які він  створив, або передати права  на їх володіння іншому користувачеві. Для цього можна використовувати процедуру sp_changeobjectowner, що має наступний синтаксис, що зберігається:

sp_changeobjectowner      [  @objname =  ]   'object', [  (Pnewowner  =   ]   'owner'

Тут за допомогою  першого параметра указується ім'я об'єкту, а за допомогою другого — ім'я користувача, який стане новим власником вказаного об'єкту.

2.3. Ролі сервера

Роль  — це могутній інструмент, доданий в SQL Server 7.0, щоб замінити групи, які використовувалися в попередніх версіях. Роль дозволяє об'єднувати користувачів, що виконують однакові функції, для спрощення адміністрування системи безпеки SQL Server.

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

У попередніх версіях SQL Server для адміністрування сервера  можна було використовувати тільки обліковий запис sa або його аналог. Інакше кажучи, можна було дати або всі права, або ніяких. Тепер в SQL Server ця проблема вирішена шляхом додавання ролей сервера (server role), які дозволяють надати операторам сервера тільки ті права, які адміністратор порахує можливим надати. Ролі сервера не мають відношення до адміністрування баз даних. Можна включити будь-який обліковий запис SQL Server (login) або обліковий запис Windows NT в будь-яку роль сервера.

Стандартні  ролі сервера (fixed server role) і їх права  приведені в табл. 1.

Таблиця 1

2.4. Ролі баз  даних

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

У роль бази даних  можна включати:

користувачів SQL Server;

ролі SQL Server

користувачів Windows NT;

групи Windows NT, яким заздалегідь наданий доступ до потрібної бази даних.

Засоби Enterprise Manager дозволяють додавати в роль бази даних  тільки користувачів бази даних (user). Потрібно використовувати процедуру sp_addrolemember, що зберігається, щоб задіяти всі можливості SQL Server 2000:

sp_addrolemember  [@ro1ename =]   'role', [@membername =] 'security_account'

Тут параметри  означають наступне:

• role— назва ролі SQL Server в поточній базі даних;
• security_account — ім'я того об'єкту системи безпеки, який необхідно включити в роль. Як такий об'єкт можуть виступати як облікові записи SQL Server, так і користувачі і групи Windows NT, яким наданий доступ до сервера баз даних.