Глава 2. Управление правами доступа в MS SQL Server 2008

Тюменский государственный университет
Институт математики и компьютерных наук
Кафедра информационной безопасности
Курсовая работа
на тему «Организация управления правами доступа в современных СУБД
Oracle10g и MS SQL Server 2008»
Выполнили:
Студенты группы № 367
Митрофанов Андрей
Прилуцкий Константин
Научные руководители:
Доцент, к.т.н.
Широких Андрей Валерьевич,
Нестерова Ольга Андреевна
Дата сдачи: ___________
Оценка: ______________
Тюмень, 2009 г.
Содержание
Введение ..................................................................................................................... 4
Глава 1. Управление правами доступа в Oracle 10g .............................................. 6
1.1 Общие сведения ................................................................................................... 6
1.1.1 Роли ................................................................................................................... 6
1.1.2 Привилегии ....................................................................................................... 7
1.2 Представления, защищающие базу данных ...................................................... 8
1.2.1 DBA_USERS ..................................................................................................... 9
1.2.2 DBA_ROLES................................................................................................... 11
1.2.3 DBA_ROLE_PRIVS ....................................................................................... 13
1.2.4 DBA_SYS_PRIVS........................................................................................... 14
1.2.5 DBA_TAB_PRIVS .......................................................................................... 15
Глава 2. Управление правами доступа в MS SQL Server 2008 ........................... 16
2.1 Пользователь и пароль ...................................................................................... 17
2.1.1 Хранение информации о пользователе и пароле ........................................ 17
2.1.2 Настройки безопасности ............................................................................... 18
2.1.3 Система безопасности SQL Server ............................................................... 19
2.1.4 Создание нового регистрационного имени в SQL Server .......................... 20
2.1.5 Интегрированная система безопасности Windows NT .............................. 23
2.2 Права пользователя............................................................................................ 24
2.2.1 Предоставление доступа к определенной базе данных ............................. 25
2.2.2 Предоставление доступа к определенным объектам таблицы .................. 26
2.3 Серверные роли и роли базы данных .............................................................. 31
2.3.1 Серверные роли .............................................................................................. 33
2.3.2 Роли базы данных .......................................................................................... 35
Глава 3. Разработка программного приложения для управления правами
доступа........................................................................................................................ 37
3.1 Выбор инструментальных средств................................................................... 37
3.2 Структура и функциональность программного комплекса. .......................... 38
3.3 Руководство пользователя программы «OracleAdmin» ................................. 39
3.4 Руководство пользователя программы «MSSQLAdmin» .............................. 42
2
Заключение .............................................................................................................. 45
Список литературы ................................................................................................. 46
3
Введение
В настоящее время для построения информационных систем
применяются различные системы управления базами данных (СУБД),
различающиеся как своими возможностями, так и требованиями к
вычислительным ресурсам. Ведущие позиции на рынке СУБД в настоящее
время занимают такие многопользовательские СУБД как Oracle и MS SQL
Server.
Наиболее важным аспектом работы с СУБД является управление
правами доступа к объектам базы данных, а также защита информации от
несанкционированного доступа. Стандартные средства управления правами
доступа, такие как “SQL Server Management Studio” в MS SQL Server и
“Enterprice Manager Console” в Oracle требуют определенной квалификации
пользователя и не всегда поставляются с ядром СУБД. Зачастую, предприятия,
использующие данные СУБД, вынуждены нанимать квалифицированных
специалистов для администрирования базы данных стандартными средствами.
Для того, чтобы сотрудник компании, не имеющий навыков в управлении
правами доступа, мог эффективно выполнять обязанности администратора базы
данных в области распределения прав доступа среди сотрудников предприятия,
существует необходимость в программном обеспечении, которое имело бы
интуитивно понятный пользовательский интерфейс, ограничивала пользователя
от возможности критических изменений в настройках доступа к БД.
Итак, выполняя курсовую работу, нами преследовались следующие
цели и задачи:
Цель:
Разработать программный комплекс для управления правами доступа
в СУБД Oracle10g и MS SQL Server 2008.
Задачи:
1. Разработать приложение для управления правами доступа в Oracle
10g, что требует изучения организации управления доступом в
данной СУБД.
4
2. Разработать приложение для управления правами доступа в MS
SQL Server 2008, что требует изучения организации управления
доступом в данной СУБД.
5
Глава 1. Управление правами доступа в Oracle 10g
1.1 Общие сведения
Oracle занимает лидирующие позиции на рынке СУБД и, что особенно
важно, лидирует на платформах Unix и Windows. В России также обозначилось
лидерство Oracle, особенно в области крупномасштабных информационных
систем государственных структур.
Последняя версия Oracle 10g, на сегодняшний день считается самой
быстрой СУБД. Среди основных свойств СУБД Oracle следует отметить такое,
как высочайшая надежность, что достигается возможность гибко настроить
параметры доступа пользователей к базе данных.
Стандартными средствами управления доступом к БД являются роли и
привилегии.
1.1.1 Роли
Роли появились в Oracle начиная с версии 6. Они предназначались для
упрощения администрирования системы пользователей и объектных привилегий.
При наличии ролей администратору БД не обязательно предоставлять и отменять
привилегии на прикладные объекты (таблицы, представления, процедуры,
функции и т.д.) для каждого пользователя, который в них нуждается. Вместо
прямого предоставления привилегий каждому пользователю можно предоставить
эти привилегии роли, а затем назначить эту роль пользователям. При добавлении
нового объекта достаточно разрешить доступ к роли, и все пользователи с этой
ролью автоматически получат доступ к объекту. А при увольнении пользователя
администратору БД вообще не потребуется отменять права доступа. При
правильном управлении роли могут намного облегчить жизнь администратору
БД. Если привилегии сгруппированы в роли, их предоставление или отмена
выполняется с помощью одного оператора:
grant <имя_роли> to <имя_пользователя (роли)>
6
1.1.2 Привилегии
Привилегии – права на манипулирование данными или на выполнение
действий. Привилегии на манипулирование данными называются объектными
привилегиями (object privileges), а привилегии на выполнение действий
называются системными привилегиями (system privileges).
Объектные привилегии дают право на выполнение следующих операций:
 Просмотр строк и столбцов в таблицах и представлениях (select)
 Добавление новых строк (insert)
 Обновление существующих строк (update)
 Удаление информации (delete)
 Выполнение хранимых программ (execute)
Системные привилегии позволяют выполнять действия, влияющие на общее
состояние базы данных. При наличии этих привилегий пользователи могут
изменять структуру базы данных.
Несколько простых действий, разрешаемых системными привилегиями:
 Создание таблицы, индекса, представления или моментального
снимка
 Удаление таблицы, индекса, представления или моментального
снимка
 Создание сеанса базы данных, что позволяет соединятся с базой
данных для выполнения работы
Объектные привилегии – это права, которые вы предоставляете другим
пользователям на доступ к своим объектам. Можно предоставлять разные
привилегии разным пользователям, позволяя одним только выбирать данные, а
другим – изменять их. Можно также предоставлять привилегии с параметром with
grant option, позволяющим передавать эти привилегии другим пользователям.
Системные привилегии позволяют соединяться с базой данных,
воздействовать на объекты базы данных, например на сегменты отката и
табличные пространства, а также создавать пользовательские объекты, такие, как
таблицы, представления, индексы и хранимые процедуры.
7
Если привилегия предоставляется кому-либо в режиме wit admin option, а
затем отменяется, то все, кто получил эту привилегию от данного лица, сохраняет
ее.
- grant <имя_привилегии> to <имя_пользвателя (роли)> with admin option
1.2 Представления, защищающие базу данных
Эти представления позволяют управлять защищенной областью (security
domain) – набором атрибутов, определяющих пределы разрешенных
пользователям действий, квоты выделяемой дисковой памяти и ресурсы.
Таблица 1.1. Представления DBA_, используемые для защиты
базы данных
Представление
Описание
DBA_PROFILES
Все профили и их ограничения
DBA_ROLES
Все роли, существующие в базе
данных
DBA_ROLES
Все роли, существующие в базе
данных
Роли, назначенные пользователям и
другим ролям
Системные привилегии,
предоставленные
пользователям и ролям
Все разрешения (grants) на объекты
базы данных
Информация обо всех пользователях
базы данных
Квоты в табличных пространствах
для всех
пользователей
DBA_ROLE_PRIVS
DBA_SYS_PRIVS
DBA_TAB_PRIVS
DBA_USERS
DBA_TS_QUOTAS
8
1.2.1 DBA_USERS
Таблица 1.2. Представление DBA_USER
Столбец
Описание
USERNAME
Имя пользователя
USER_ID
Идентификационный номер
пользователя
PASSWORD
Пароль в зашифрованном виде
ACCOUNT_STATUS
Показывает состояние учетной
записи: заблокирована,
действительна или
разблокирована
Дата блокировки учетной записи
LOCK_DATE
(если Учетная запись
заблокирована)
Дата, после которой учетная
EXPIRY_DATE
запись
становится недействительной
Табличное пространство по
DEFAULT_TABLESPACE
умолчанию для данных
Табличное пространство по
TEMPORARY_TABLESPACE
умолчанию для временных
сегментов
CHEATED
Дата создания пользователя
PROFILE
Имя профиля ресурсов
пользователя
INITIAL_RSRC_CONSUMER_GROU
Группа потребителей ресурсов, в
которую
P
9
изначально входит пользователь
Внешнее имя пользователя
EXTERNAL_NAME
Рассмотрим столбцы, используемые чаще всего. Название Username говорит
само за себя — это имя учетной записи, под которым пользователь входит в базу
данных. Имя пользователя может состоять из букв алфавита, цифр,
специальных символов — подчеркивания (_), знака доллара ($) или знака номера
(#). Столбец User_ID содержит уникальный идентификатор пользователя,
состоящий из цифр от 0 до 9. Но и в столбце Username также должно содержаться уникальное (правда, уже алфавитно-цифровое) значение. Когда
пользователь создает объект и при этом не указывает табличное пространство, в
котором этот объект создается, Oracle создаст его в табличном пространстве,
которое было назначено по умолчанию (Default_Tablespace).
Столбец Temporary_Tablespace содержит имя табличного пространства для
пользователя, которое Oracle использует в тех случаях, когда для выполнения
оператора SQL необходимо произвести сортировку.
Столбец Password содержит зашифрованные значения паролей для учетных
записей. Создадим пользователя с именем RACHEL:
-> Create user RACHEL identified by TEST default tablespace USERS temporary tablespace TEMP;
User created.
Столбец Асcount_Status сообщает, имеют ли пользователи доступ к своим
учетным записям, и если нет, то почему. Lock_Date содержит дату блокировки
учетной записи, вызванной серией неудачных попыток ввода пароля (количество
попыток устанавливается в профиле пользователя). Expiry_Date — это дата
стечения срока действия пароля. Перед принудительной сменой пароля можно
установить период отсрочки, на протяжении которого пользователи смогут
входить по старому паролю. Два оставшихся столбца в представлении DBA_USERS
– это Created, содержащий дату создания учетной записи, и Profile, в котором указан
10
профиль, используемый при проверке ограничений ресурсов для данного
пользователя.
1.2.2 DBA_ROLES
Представление DBA_ROLES содержит информацию обо всех
определенных в базе данных ролях. При создании базы данных в версиях 9 и 10
Oracle создает несколько стандартных ролей. Столбцы этого представления
перечислены в таблице 1.3.
Таблица 1.3. Представление DBA_ROLES
Столбец
Описание
ROLE
Имя роли
PASSWORD_REQUIRED
Показывает, требуется ли пароль для
разрешения роли
До Oracle6 пользователям можно было присвоить только три роли:
■ CONNECT
■ RESOURCE
Позволяет пользователю обращаться к базе данных
Дает пользователю возможность создавать объекты и
использовать пространство в базе данных
■ DBA
Позволяет выполнять любые действия в базе данных
Фактически это были даже не роли, а наборы привилегий, хранившиеся в
ядре Oracle, которые можно было предоставлять пользователям. Настоящие, роли
появились в Oracle6. Начиная с Oracle7, администратор получил возможность
комбинировать группы системных и объектных привилегий, а также создавать
нестандартные роли, отвечающие потребностям приложений.
Роли CONNECT, RESOURCE и DBA Oracle сохраняет для обратной
совместимости, но не гарантирует, что они будут присутствовать всегда.
Предопределенные роли могут меняться от версии к версии, поэтому, как и для
самих представлений DBA_, нужно всегда проверять, какие роли были добавлены,
а какие удалены.
11
Необходимо помнить, что вместе с ролью RESOURCE пользователь получает привилегию unlimited tablespace, которая позволяет создавать объекты не
только в табличном пространстве по умолчанию, но и в других табличных
пространствах, причем без какой-либо квоты. Квота (quota) — это объем пространства, которое может быть выделено пользователю в табличном пространстве.
Столбец Password_Required показывает, должен ли вводиться пароль, когда
пользователь или приложение разрешает роль. Если пароль необходим, он
указывается в команде set role. Из этого правила есть одно исключение. Если роль,
требующая пароля, назначена пользователю как роль по умолчанию, она будет
автоматически разрешена при входе пользователя в базу данных, и ему не нужно
будет вводить пароль. Может быть более одной роли по умолчанию, но все они
должны быть назначены как части одного оператора SQL. Увидеть роли,
разрешенные в текущем сеансе, можно с помощью следующего SQL-оператора:
select * from SESSION_ROLES;
Чтобы создать роль, нужно иметь либо привилегию create role, либо роль,
которой была предоставлена эта привилегия/Роль создается следующим образом:
create role TESTROLE;
Для добавления к роли привилегий необходимо для каждой из этих привилегий
ввести соответствующий оператор. Допустим, нужно, чтобы роль TESTROLE
имела привилегию create role. Это делается следующим образом:
grant CREATE ROLE to TESTROLE;
Grant succeeded.
Если теперь назначить роль TESTROLE какому-либо пользователю, он сможет
создавать роли в базе данных.
12
1.2.3 DBA_ROLE_PRIVS
В предыдущем разделе было показано, как определить, какие роли
существуют в базе данных. Представление DBA_ROLE_PRIVS расскажет, каким
пользователям (или ролям) и с какими административными привилегиями были
назначены эти роли. Столбцы этого представления перечислены в таблице 1.4.
Таблица 1.4. Представление DBA_ROLE_PRIVS
Столбец
Описание
GRANTEE
Имя получателя роли — пользователя
или другой роли
GRANTED_ROLE
Имя назначенной роли
ADMIN_OPTION
Показывает, что роль была назначена с
опцией ADMIN
DEFAULT_ROLE
Показывает, что роль назначена
пользователю как роль по умолчанию
Чтобы вновь созданную роль можно было использовать, ее необходимо
назначить пользователю или другой роли. Представление DBA_ROLE__PRIVS
позволяет увидеть, кому какие роли были назначены. Столбец Grantee содержит
имя пользователя или роли, которые получили возможность доступа к роли. Роли
нельзя назначать по кругу. Это означает, что если вы создали роли CLERK и
MANAGER, а затем назначили роль CLERK роли MANAGER, то уже нельзя
назначить роль MANAGER роли CLERK, поскольку в этом случае роль MANAGER
будет ссылаться сама на себя. Столбец Granted_Role полностью аналогичен столбцу
Role представления DBA_ROLES. Столбец Admin_Option показывает, может ли
пользователь, получивший роль, назначать ее другим, а столбец Default_Role
показывает, будет ли данная роль автоматически разрешена при входе
пользователя в базу данных.
Чтобы увидеть, какие роли были назначены пользователю и будут ли они
автоматически разрешены, можно ввести следующий запрос:
13
select Grantee, Granted_Role, Default_Role from DBA_ROLE_PRIVS where Grantee not in ('SYS'.'SYSTEM') order by
Grantee;
Если нужно посмотреть, назначались ли кому-нибудь роли, требующие пароля, достаточно соединить таблицы DBA_ROLES и DBA_ROLE_PRIVS:
select Grantee, Granted_Role from DBA_ROLES a, DBA_ROLE_PRIVS D where a.Role = b.Granted_Role and
a.Password_Required='YES';
1.2.4 DBA_SYS_PRIVS
Представление DBA_SYS_PRIVS показывает, какие привилегии системного
уровня были предоставлены пользователям или ролям. Такие привилегии позволяют манипулировать средой базы данных, создавая, удаляя или изменяя
объекты. Столбцы этого представления перечислены в таблице 1.5.
Таблица 1.5. Представление DBA_SYS_PRIVS
Столбец
Описание
GRANTEE
Имя получателя привилегии — пользователя или роли
PRIVILEGE
Системная привилегия
ADMIN_OPTION
Показывает, что роль была предоставлена с опцией
ADMIN.
Следует проверять количество и типы системных привилегий в каждой новой версии базы данных. С добавлением новых возможностей появляются и
новые привилегии, позволяющие ими управлять.
Для того, чтобы узнать какие системные привилегии были даны пользователю
или роли необходимо выполнить следующий SQL-запрос:
select * from DBA_SYS_PRIVS where Grantee = 'имя_пользователя(роли)';
14
1.2.5 DBA_TAB_PRIVS
Представление DBA_TAB_PRIVS (см. таблицу 5.8) дает информацию обо
всех привилегиях на все объекты базы данных.
Таблица 5.8. Представление DBA_TABS_PRIVS
Столбец
Описание
GRANTEE
Пользователь, которому предоставлен доступ
OWNER
Владелец объекта
TABLE_NAME
Имя объекта
GRANTOR
Пользователь, который разрешает доступ
PRIVILEGE
Привилегия на таблицу
GRANTABLE
Показывает, может ли привилегия предоставляться другому
пользователю
HIERARCHY
Привилегия предоставляется с опцией иерархичности
(hierarchy)
Глядя на сочетание "TAB" в имени представления, можно подумать, что
оно содержит информацию только о табличных привилегиях. Однако на самом
деле здесь представлена информация о правах доступа ко всем объектам в базе
данных. Объект — это то, чем может владеть пользователь. Хотя привилегии
можно
предоставить
на
большинство
объектов,
существует
несколько
исключений. Индексы, триггеры и синонимы считаются объектами, но к ним
нельзя обращаться непосредственно. Если вы получили доступ к таблице, то
автоматически будете иметь доступ к ее индексам и триггерам. Oracle запускает
триггер, если он относится к выполняемому над таблицей действию, и при
необходимости модифицирует индекс таблицы или осуществляет к нему доступ.
Синоним — это просто псевдоним, поэтому для его использования привилегии не
требуются.
Столбец Grantee ссылается на пользователя, которому была выдана данная
привилегия. Owner — это владелец самого объекта. Table_Name содержит имя
объекта, a Grantor - это пользователь, который предоставляет привилегию.
15
Привилегия представляет собой право доступа, и столбец Grantable показывает,
может ли пользователь, получивший привилегию, передать ее кому-либо еще.
Поскольку владелец объекта может передавать другому пользователю право
предоставления доступа к объекту, для прослеживания всей этой цепочки
необходимы оба столбца — Owner и Grantor.
Один из лучших способов защитить базу данных — это потратить немного
времени на то, чтобы разобраться, какие привилегии в действительности нужны
каждой из групп пользователей, а затем построить и предоставить роли,
обеспечивающие именно такой доступ и ничего более. Конечно, проще всего
предоставить всем пользователям привилегии grant all to public на все объекты,
но все-таки это не выход.
Предоставляя пользователю привилегию с параметром with grant option,
важно помнить, что если владелец таблицы впоследствии отменит эту привилегию
для первого пользователя, то ее потеряют и все остальные пользователи.
Глава 2. Управление правами доступа в MS SQL Server 2008
Вероятно, на свете существует столько же способов обеспечения
безопасности
программистов.
сколько
компьютерных
программ,
сколько
существует
Однако данная проблема относиться к тем проблемам, для
которых может и не существовать единственного верного пути, зато имеется
несколько заведомо неверных.
Первое, что следует понять - не существует приложений, которые могли бы
гарантировать абсолютную безопасность. Если вы знаете, как обеспечить
безопасность приложения, точно также кто-то другой может знать, как обойти
вашу защиту и “взломать” систему.
16
2.1 Пользователь и пароль
2.1.1 Хранение информации о пользователе и пароле
В большинстве случаев для организации хранения профайла пользователя и
пароля вам не придется слишком напрягать интеллект, тем не менее, о некоторых
вещах стоит призадуматься,
Поскольку вам нужна информация с самого начала, придется выбрать одно
из следующих решений:
- Внедрить пароль непосредственно в клиентское приложение либо
компонент (и убедиться, что корректный логин и пароль созданы на каждом
сервере, на котором было установлено данное приложение).
- Сохранить имя и пароль в реестре и заставить ваше приложение
извлекать его оттуда.
- Установить два пароля - один для доступа пользователя к обычной
информации о пароле, а другой - для доступа к реальному приложению. Однако
для пользователя требования завести два логина, как правило, неприемлемы, в
итоге мы вынуждены вернуться к предыдущим двум вариантам.
Если вы выбрали сценарий работы с двумя паролями, то доступ к первому
логину, по возможности, должен предоставляться только хранимым процедурам.
Таким способом вы позволяете первому логину провести необходимую проверку
достоверности прав доступа, не раскрывая в то же время никакой информации
тому, кто пытается загрузиться через Query Analyzer. Дайте вашей хранимой
процедуре принять регистрационное имя пользователя и его пароль, а затем
просто возвратите булево значение (может он загрузиться или нет) либо выведите
список, перечисляющий, к каким диалоговым окнам и функциям пользователь
будет иметь доступ с клиентского приложения. Если вы примените простой
оператор SELECT, то не сможете ограничить список доступной информации.
Если вы собираетесь хранить в системе информацию о паролях - зашифруйте ее!
Не стоит и говорить, насколько это важно. Большинство пользователей
используют пароли более чем один раз - поэтому отсутствие необходимости
запоминать
их
несколько
облегчает
жизнь.
17
Зашифровав
данные
перед
размещением их в базе данных, вы будете уверены в том, что никто, даже
случайно, не обнаружит информацию о пароле» Данная информация может быть
видна, но ею нельзя будет воспользоваться без соответствующего ключа для
расшифровки.
2.1.2 Настройки безопасности
При использовании встроенных средств, вам доступны только два варианта
настройки безопасности под SQL Server. Ранее, до версии 7.0, вариантов выбора
было три. Поэтому, исключительно из соображений совместимости, приведем все
три разновидности механизма контроля безопасности, существовавших в SQL
Server 6.x.
-
Интегрированная система безопасности Win NT/2000 - пользователь
регистрируется в самой NT-системе, а не в SQL Server, Аутентификация
осуществляется через доверительное соединение NT.
- Стандартная система безопасности: пользователь подключается к SQL
Server независимо от входа в ОС NT. Аутентификация производится самим SQL
Server.
-
Смешанная
система безопасности:
окружение,
в котором часть
пользователей использует интегрированную систему безопасности NT, а другие стандартную систему безопасности.
В настоящее время доступными являются только первая и последняя опции. Вы
по-прежнему можете выбрать опцию безопасности, позволяющую вам работать
подобно стандартной системе безопасности в версиях 6.5 и более ранних - просто
вы также должны выбрать опцию безопасности NT, Другими словами, сейчас вы
можете выбирать из следующих пунктов:
- интегрированная система безопасности NT (или Win 2000);
- смешанная система безопасности NT и SQL Server.
Теперь вы не сможете воспользоваться старой системой безопасности
опирающейся исключительно на SQL Server.
18
Давайте же рассмотрим две доступные опции безопасности для SQL Server
версии 7.0 и выше.
2.1.3 Система безопасности SQL Server
Начнем наше обсуждение со встроенной в SQL Server логической модели,
которая похожа на старую систему безопасности NT.
Используя систему безопасности SQL Server, вы создаете регистрационное имя
пользователя, абсолютно не связанное с вашим сетевым именем и паролем.
Некоторые аргументы в пользу системы безопасности SQL Server:
- пользователю необязательно принадлежать к данному домену, чтобы
получить доступ к системе;
- легче осуществлять программный контроль над информацией о
пользователе;
- в прошлом ее гораздо легче было поддерживать, чем смешанную систему
безопасности или интегрированную систему безопасности NT.
Справедливости ради приведем некоторые контраргументы:
- пользователю приходится вводить два и более паролей - первый для
получения доступа к сети и по одному для каждого соединения с SQL Server
отдельного приложения;
- два регистрационных имени требуют больших затрат на поддержку со
стороны администратора;
- с паролями можно легко запутаться, что может привести к полному хаосу.
(Не кажется ли вам знакомым вопрос: "Так, посмотрим, какой пароль нужен для
этого
имени?").
Примером использования системы безопасности SQL Server может быть
бюджет sa, которым вы наверняка пользуетесь во время работы над примерами из
книги. Не имеет значения, каким образом вы вошли в сетевое окружение, к SQL
Server вы подключаетесь при помощи логина sa и отдельного пароля.
19
Вы вряд ли пожелаете каждый день входить, используя регистрационное имя sa.
Почему? Я думаю, вам хватит пары минут, чтобы представить, что вы в
состоянии натворить, воспользовавшись абсолютными правами доступа бюджета
sa. Абсолютный доступ означает, что вы можете делать что угодно, и случайно
примененный операнд DROP TABLE немного не к той базе данных, сделает
именно то, о чем вы его попросили - удалит таблицу!!! Вам останется только
воскликнуть: "Ой, что я наделал!".
Даже если вы хотите всегда обладать полной свободой действий,
воспользуйтесь бюджетом sa для создания постоянного пользовательского
бюджета, являющегося членом серверной роли sysadmins. Благодаря этому вы
будете иметь ту же свободу действий, что и для бюджета sa, но при этом будет
обеспечена дополнительная безопасность за счет использования отдельного
пароля и мониторинга (в Profiler либо путем просмотра системной активности)
пользователей, подключенных к системе в данный момент.
2.1.4 Создание нового регистрационного имени в SQL Server
Существующие способы создания нового регистрационного имени в SQL Server:
- при помощи хранимой процедуры sp_addlogin;
- при помощи Enterprise Manager;
- используя инструментальные средства управления средой Windows
(Windows Management Instrumentation - WMI).
sp_addlogin
Как следует из ее названия, данная хранимая процедура добавляет новое
регистрационное имя. Обязательным для нее является только один параметр, но
большую часть времени вы будете использовать два или три ее параметра.
Существует также несколько дополнительных опций, которые, однако, редко
находят себе применение. Хранимая процедура имеет следующий синтаксис:
EXEC sp_addlogin [@loginame =] <'регистрационное имя'>
[,[@passwd =] <'пароль'>
20
[,[@defdb =] <'база_данных'>
[,[@deflanguage =] <'язык'>
[,[@sid =] 'sid'
[,[@encryptopt =] <'опция_шифрования'>
Параметр
Описание
@loginame
Здесь задается регистрационное имя, используемое
впоследствии
@passwd
Пароль, который будет использоваться вместе с
вышеупомянутым именем
@defdb
Назначаемая по умолчанию база данных. В данном
параметре задается первая база данных, к которой
получает доступ пользователь при подключении к
системе. Обычно, в ее качестве выступает главная база
данных, используемая приложением. Именно она
назначается, если данная опция не определена явно
(чаще всего вы не захотите, чтобы пользователь
попадал непосредственно в главную базу данных,
поэтому не забудьте указать значение опции)
@deflanguage
Язык пользователя по умолчанию. Данный параметр
может применяться для переопределения стандартного
языка системы, если ваше приложение поддерживает
локализацию
21
@sid
Двоичное число, которое будет использоваться в
качестве системного идентификатора (system identifier
— SID) для данного имени пользователя. Если вы не
зададите SID, SQL Server сгенерирует его для вас
автоматически. Поскольку должна обеспечиваться
уникальность SID, любой SID, задаваемый вами, не
должен совпадать с уже имеющимся в системе.
Иметь дело с собственноручно определенными SID
может быть удобно при восстановлении базы данных с
другого сервера или при ином переносе
регистрационной информации
@encryptopt
Регистрационное имя пользователя и пароль хранятся
в таблице sysusers главной базы данных приложения.
Опция @encryptopt определяет в каком виде эта
информация находится в главной базе данных зашифрованном или нет. По умолчанию (или при
задании значения NULL для этой опции) пароль
хранится в зашифрованном виде. Другие возможные
опции - skip_encryption, означающая, что пароль
зашифрован не будет; и skip_encryption_old, которая
используется исключительно для обеспечения
совместимости при резервном копировании
Хранимая процедура sp_addlogin позволяет создавать пакетные файлы для
добавления групп пользователей либо писать сценарии непосредственно в рамках
клиентских инструментов администратора.
sp_password
После создания учетной записи для пользователя вам может понадобиться
механизм изменения пароля. Если вы хотите осуществлять смену пароля в TSQL, то можете сделать это при помощи хранимой процедуры sp_password. Ее
синтаксис очевиден:
22
sp_password
[@new =]
[[@old =]
<'старый пароль'>,]
<'новый пароль'>
[, [@loginame =]
< ' имя пользователя'>]
Параметры задания старого и нового пароля, конечно, используются именно так,
как и следовало ожидать. Вам необходимо получить их от пользователя и
передать хранимой процедуре. Обратите внимание, что параметр loginame
является необязательным. Если вы его явно не зададите, предполагается, что
пароль, под которым осуществлено данное соединение будет для пользователя
изменен. Заметьте также, что процедураsp password не может быть выполнена в
качестве части транзакции.
2.1.5 Интегрированная система безопасности Windows NT
Что такое система безопасности Windows NT?
Система безопасности NT представляет собой модель, в которой используются
существующие в доменах NT бюджеты (учетные записи) пользователей или их
групп и им предоставляются права непосредственного доступа к SQL Server,
вместо того, чтобы заставлять их заводить отдельные пароли и имена для
получения соответствующих прав. Рассмотрим несколько примеров как для TSQL, так и для Enterprise Manager.
Предоставление доступа к пользовательским бюджетам NT.
Вообще-то данная задача решается очень просто и весьма похоже на решение
подобной задачи для системы безопасности SQL Server. Единственный момент вам придется задавать полный путь, включая имя домена, к пользовательскому
профайлу, которому вы хотите предоставить права доступа» Это можно сделать
следующим образом:
23
sp_grantlogin [@loginame=]
'<имя_домена>\<имя_пользователя_в_NT>'
Зачем использовать систему безопасности NT?
До версии 7,0 интегрированную систему безопасности NT воспринимали как
какую-то запоздалую мысль. Она являлась изгнанником, которого никто не
принимал всерьез. Начиная с версии 7.0, появилась возможность по-настоящему
использовать эту систему. Корпорация Microsoft продолжала настаивать на
переходе большего количества серверов к интегрированной системе безопасности
NT. С приходом эры Windows 2000 точка зрения пользователей действительно
переместилась в сторону безопасного интегрированного окружения. И это не
лишено смысла - чем меньшее количество регистрационных имен используется,
тем надежнее и проще обеспечивать безопасность, особенно при длительной
работе.
Система безопасности NT позволяет:
- осуществлять контроль всех прав пользователя из одного места;
- предоставлять права доступа к SQL Server при помощи простого
добавления пользователя к группе NT (это означает, что в большинстве случаев
вам даже не придется заходить на SQL Server для присвоения прав пользователю);
- вашим клиентам достаточно будет помнить только одно имя и пароль.
Суть всего вышесказанного заключается в том, что теперь система безопасности
NT наконец-то работает так, как должна была работать изначально.
2.2 Права пользователя
Простейшее определение, что такое права пользователя (user rights), звучит
как: ''Что пользователь может делать, а что ему делать запрещено". В данном
случае самое простое определение самое удачное.
Пользовательские права делятся на три категории:
24
-права подключения к системе;
-права доступа к определенным базам данных;
-права на выполнение определенных действий над отдельными объектами в
базе данных.
2.2.1 Предоставление доступа к определенной базе данных
Если вы хотите, чтобы пользователь имел доступ к конкретной базе данных,
необходимо предоставить ему соответствующие права. Вы можете осуществить
предоставление прав в Enterprise Manager, добавив пользователя к элементу Users
узла Databases вашего сервера. Чтобы сделать то же самое при помощи T-SQL,
необходимо воспользоваться процедурой:
sp_grantdbaccess [@loginame
=] <'имя пользователя'>
[@name in db =] <'имя в данной базе'>
Обратите внимание, что доступ будет назначен к текущей базе данных, поэтому
прежде, чем выполнять вышеуказанную хранимую процедуру, убедитесь, что вы
хотите предоставить пользователю права доступа именно к этой базе данных.
Регистрационным именем является действующее имя пользователя, под которым
он подключается к SQL Server. Параметр name_in_db
позволит вам всегда
однозначно идентифицировать данного пользователя в базе данных. Внутреннее
имя служит исключительно целям определенной базы данных - во всех остальных
базах данных для идентификации данного пользователя будет по-прежнему
применяться его регистрационное имя, в независимости от того, какое имя вы
назначили пользователю здесь. Присвоение внутреннего имени влияет на
идентифицирующую
функцию
USER_NAME
(),
Функции,
производящие
идентификацию на системном уровне, такие как SYSTEM USER будут
возвращать основное регистрационное имя пользователя.
Лишение прав доступа производится практически аналогично - для этого
придется воспользоваться системной хранимой процедурой sp_revokedbaccess:
sp_revokedbaccess [@name_in_db =] <'имя пользователя'>
25
2.2.2 Предоставление доступа к определенным объектам таблицы
Итак, пользователь получил регистрационное имя и доступ к базе данных,
который вы пожелали ему предоставить, и все как будто выполнено? Если бы все
было так просто! На самом деле нам еще есть над чем поработать.
SQL Server дарует нам широкие возможности контроля над правами доступа
пользователей. Как правило, в вашей базе данных может содержаться
информация, к которой пользователю позволено обращаться, но в той же самой
базе данных могут присутствовать данные, доступ к которым со стороны
определенного пользователя нежелателен. К примеру, у вас может работать
человек
для
выполнения
заявок
покупателей,
которому
необходимо
просматривать и редактировать информацию о заказах - в то же время, вы вряд ли
захотите, чтобы он имел доступ к данным об окладах. Обратное также верно - вам
нужны люди, которые будут заниматься редактированием записей о служащих
компании, но вы вряд ли позволите, чтобы они могли предоставлять скидки
определенным клиентам.
SQL Server позволяет назначить свой набор прав доступа для каждого объекта
SQL Server. Объектами, для которых могут быть назначены отдельные права,
являются таблицы, представления и хранимые процедуры. Права доступа к
триггерам резервируются за их создателями.
Права пользователей на те или иные объекты делятся на шесть различных
категорий:
Права пользователя
Описание
SELECT
Разрешает пользователям просматривать
данные. Если пользователь обладает данным
правом, он может применять оператор SELECT
к любой таблице либо представлению, на
26
которые распространяется это право
INSERT
Предоставляет пользователю возможность
вносить новые данные. Таким образом,
пользователь может применять оператор
INSERT. Обратите внимание, что в отличие от
большинства систем, привилегии на
выполнение оператора INSERT не обязательно
подразумевают права на использование
оператора SELECT
UPDATE
Предоставляет пользователю возможность
редактировать существующие данные.
Пользователь с данными правами может
применять оператор UPDATE. Аналогично
ситуации с оператором INSERT, наличие
привилегий на выполнение оператора UPDATE не
обязательно подразумевает права на
использование оператора SELECT
DELETE
Разрешает пользователю удалять данные.
Пользователь с данными правами может
применять оператор DELETE. Опять-таки,
привилегии на выполнение оператора DELETE
не предоставляют автоматически прав на
использование оператора SELECT
REFERENCES
Позволяет пользователю вставлять записи в
таблицу, имеющую ограничения внешнего
ключа, ссылающегося на таблицу, по
отношению к которой пользователь не обладает
27
правами на применение оператора SELECT
EXECUTE
Предоставляет пользователю право выполнять
хранимые процедуры
Вы можете использовать различные сочетания прав доступа к отдельным
таблицам, представлениям или хранимым процедурам для предоставления их
конечному пользователю.
Назначить соответствующие права можно в Enterprise Manager, перейдя к опции
Logins в узле Security для вашего сервера. Просто щелкните правой кнопкой
мыши на имени пользователя и выберите Properties, Перед вами появится
диалоговое окно, в зависимости от того, какой узел в дереве был выбран - базы
данных целиком либо узел безопасности. В последнем случае вы сможете
установить разрешения на доступ. Назначить привилегии при помощи T-SQL
столь же просто, даже если вы привыкли присваивать права в ЕМ, поскольку
здесь используется та же терминология. В T-SQL для этого имеются три команды.
GRANT
GRANT предоставляет определенному пользователю либо роли права доступа,
назначенные для объекта, указываемого в выражении GRANT.
Синтаксис выражения GRANT выглядит следующим образом:
GRANT
ALL [PRIVILEGES]| <разрешение>[,...n]
ON
<имя_таблицы_или_представления> [(<имя столбца>[,...n])]
| <имя_стандартной_или_расширенной_хранимой_процедуры>
TO <имя_пользователя_либо_роли> [,...n]
28
[WITH GRANT OPTION]
[AS <имя_роли>]
Ключевое слово ALL свидетельствует о том, что вы собираетесь предоставить
все возможные права доступа к данному объекту (применение оператора
EXECUTE не имеет смысла для таблицы). Если вы не зададите ALL, вам
необходимо будет указать одно или несколько определенных прав доступа к
данному объекту.
PRIVILEGES - новое ключевое слово, не выполняющее никакой функции и
добавленное исключительно с целью совместимости со стандартом ANSI-92.
Ключевое слово ON определяет объект (который указывается после него), к
которому будут применены вышеупомянутые привилегии. Кстати, обратите
внимание, если вы предоставляете доступ к таблице, то можете назначить особые
права доступа вплоть до отдельных столбцов (их необходимо перечислить в
списке). Если столбцы не указаны, то по умолчанию процедура применяется ко
всей таблице.
Выражение ТО определяет, кому необходимо присвоить данный уровень
доступа. Можно
задать имя пользователя либо роль.
WITH GRANT OPTION дает возможность пользователю, получившему
определенные привилегии, передавать их другим пользователям.
И последнее, но не по важности, ключевое слово AS. Оно определяет статус
пользователя, входящего в состав нескольких ролей.
DENY
Оператор DENY явно запрещает доступ пользователям к целевому объекту.
Ключевое слово DENY отменяет все привилегии, предоставленные ранее
оператором GRANT. Поскольку пользователь может принадлежать к нескольким
ролям, то возможна ситуация, в которой пользователю с одной стороны
оператором GRANT предоставлены права доступа к данному объекту (например,
как члену какой-то роли), а с другой - наложен запрет оператором DENY, в таком
случае всегда побеждает оператор DENY, Другими словами, если пользователь
либо роль, к которой он относится, имеет запрет на доступ к данному объекту,
29
пользователь не сможет воспользоваться привилегиями, дарованными с другой
стороны.
DENY
ALL [PRIVILEGES] | <разрешеиие>[,...n]
ON
<имя_таблицы_или_представления> [(<имя_столбца> [,...n ])]
| <имя_стандартной_или_расширенной_хранимой_процедуры>
TO <имя_пользователя_либо_роли> [,...n]
[CASCADE]
Ключевое слово ALL точно также означает, что отменяются все права,
применимые к объекту данного типа (право EXECUTE не применимо к таблице).
Вы можете задать одно или несколько прав, применение которых вы хотите
запретить для этого объекта.
PRIVILEGES не обладает никакой функциональностью и добавлено в качестве
нового ключевого слова в целях совместимости с ANSI-92.
После слова ON следует имя объекта, к которому применяется оператор DENY.
Все вышеупомянутые параметры работают аналогично оператору GRANT.
Отличие
можно
увидеть
в
опции
CASCADE
которая,
однако,
по
функциональности совпадает с параметром WITH GRANT OPTION. Задание
опции CASCADE сообщает SQL Server о вашем намерении лишить прав доступа
всех пользователей, которым данный пользователь предоставил привилегии в
соответствии с параметром WITH GRANT OPTION.
REVOKE
Оператор REVOKE отменяет результаты предшествующей команды DENY
или GRANT.
По производимому эффекту он очень напоминает применяемый к объектам
оператор Undo.
Синтаксис представляет собой сочетание синтаксиса выражений DENY и
GRANT:
30
REVOKE [GRANT OPTIONS FOR]
ALL [PRIVILEGES] | <список_прав>[,...n]
ON
<имя_таблицы_или__представления>[(<имя
столбца>[,...n])]
| <имя_стандартной_или_расширенной_хранимой_процедуры>
TO | FROM <имя_пользователя_либо_роли> [,...n]
[CASCADE]
[AS <имя_роли>]
Ключевое слово ALL говорит об аннулировании всех прав, применимых к
объекту данного типа. Если вы не используете опцию ALL, вам придется
перечислить конкретные права, которые вы хотите аннулировать для данного
объекта.
PRIVILEGES не обладает никакой функциональностью и добавлено в качестве
нового ключевого слова в целях совместимости со стандартом ANSI-92.
За ключевым словом ON следует имя объекта, для которого отменяются те или
иные привилегии.
Ключевое слово CASCADE соответствует опции GRANT WITH OPTION
в выражении GRANT и сообщает SQL Server об аннулировании доступа для всех
пользователей, которые получили данное право от этого пользователя (в
соответствии с параметром GRANT WITH OPTION).
Ключевое слово AS опять-таки определяет, к какой роли вашего
пользователя применяется оператор REVOKE.
2.3 Серверные роли и роли базы данных
До версии 7.0 в SQL Server наличествовала концепция групп - объединений
пользователей, обладающих определенным набором прав, которые вы могли в
совокупности назначить новому пользователю, просто сделав его членом данной
группы. Такая концепция в корне отличалась от принятой в NT, где каждый
пользователь мог принадлежать более чем к одной группе, что позволяло сочетать
при необходимости различные права. В SQL Server 6.5 (и более ранних версиях)
31
каждый пользователь мог принадлежать только к одной группе определенной
базы данных.
В итоге во времена, предшествующие появлению SQL Server 7.0, все группы в
SQL Server делились на три категории:
- группы с часто изменяемыми правами доступа пользователей;
- группы с небольшими отличиями от главной группы;
- группы, обладающие большим количеством прав, чем необходимо (что
облегчало жизнь администратора базы данных).
Зачастую, группы являлись одной большой проблемой, хотя от этого не
становились менее нужными.
Роль представляет собой набор прав доступа, которые могут быть
назначены пользователю все в совокупности, путем присоединения пользователя
к данной роли.
На этом схожесть ролей с группами заканчивается. В отличие от групп,
пользователь может принадлежать одновременно к нескольким ролям. Такой
подход бывает весьма удобен, поскольку вы можете поделить права доступа
между мельчайшими логическими группами, а затем совместить их наиболее
подходящим для нужд пользователя образом.
Роли бывают двух видов:
- серверные роли (server roles);
- роли базы данных (database roles).
Серверные роли ограничены перечнем встроенных в SQL Server ролей,
которые изначально предназначены для поддержки системы и обеспечения
возможностей выполнения операций, не связанных с конкретными базами
данных, как, например, создание новых пользователей или связанных серверов.
Подобно серверным ролям, существует некоторое количество встроенных (или
фиксированных) ролей баз данных, но в этом случае вы можете также определять
собственные роли для ваших конкретных нужд. Роли баз данных используются
для настройки и группировки пользователей с одинаковым набором прав в одной
определенной базе данных.
32
2.3.1 Серверные роли
Все серверные роли являются фиксированными и, в принципе, это
изначально оправдано -поскольку все серверные роли, которые только могут вам
понадобиться, уже реализованы и существуют на вашей системе с момента
инсталляции SQL Server.
Роль
Сущность
sysadmin
Данная роль предполагает возможность выполнения
любых действий на вашем SQL Server. Любой пользователь,
принадлежащий к данной роли, является, тем самым,
пользователем sa для вашего сервера. Появление этой роли
подразумевает исчезновение бюджета sa в будущем - и
действительно, в онлайновом справочнике вы можете
встретить
упоминание
о
намерениях
Microsoft
в
дальнейшем его ликвидировать.
Очевидно, что группа Administrators в NT связывается с
ролью sysadmin на SQL Server автоматически. Это означает,
что всякий, кто является членом группы администраторов
вашего сервера, также имеет права доступа sa к данным
SQL Server. При желании, вы можете удалить группу
администраторов NT из роли sysadmin чтобы обезопасить
систему и избавиться от лишней лазейки
33
serveradmin
Эта
роль
охватывает
сферу опций
настройки
или
отключения сервера. Хотя она несколько ограничена в
наборе прав по сравнению с предыдущей ролью, однако
функции, контролируемые членами данной роли, могут
существенно повлиять на производительность сервера
setupadmin
Данная роль ограничена возможностями управления
связанными серверами и процедурами запуска
securityadmin
Данная роль чрезвычайно удобна для пользователей,
ориентированных исключительно на управление другими
пользователями,
просмотр
протоколов
ошибок
и
выполнение оператора CREATE DATABASE. Во многих
смыслах это одна из классических ролей системного
оператора - с возможностью управления большинством
однодневной информации, но без глобальных прав доступа,
дарованных привилегированным пользователям
processadmin
Обладает право управлять процессами, выполняемыми на
SQL Server - с ее помощью при необходимости можно
уничтожить какой-то слишком долго выполняющийся
процесс
dbcreator
Возможности
этой
роли
ограничены
созданием
и
изменением баз данных
diskadmin
Члены данной роли управляют файлами на диске
(контроль того, с какими файлами связана данная группа,
подключение и отсоединение баз данных и так далее)
bulkadmin
Данная роль является несколько странной. Она явно
задается для
предоставления прав на выполнение команды BULK
INSERT,
которая
в
противном
случае
может
быть
выполнена только лицом с правами sysadmin. Привилегии
на использование этого оператора действительно нельзя
34
передать с помощью команды GRANT, Помните также о
том, что добавление пользователя в группу bulkadmin
предоставляет ему права только на выполнение оператора
BULK INSERT, но само по себе не дает возможности
применять его к конкретным таблицам. Из этого следует,
что помимо разрешения на выполнение задачи BULK
INSERT, пользователю также необходимо предоставить
разрешение на применение оператора INSERT к каждой
таблице, для которой требуется выполнить оператор BULK
INSERT, Кроме того, вам необходимо убедиться, что члены
данной
роли
обладают
необходимыми
правами
на
применение оператора SELECT для всех нужных вам
таблиц
2.3.2 Роли базы данных
Применение ролей базы данных ограничено областью единственной базы
данных - то, что пользователь принадлежит к роли cib_datareader в одной базе
данных, еще не означает, что он будет принадлежать к этой роли в другой базе
данных. Роли базы данных делятся в свою очередь на две подкатегории:
фиксированные и определяемые пользователем.
Фиксированные роли базы данных
Также как и для серверных ролей, существует несколько встроенных ролей
базы данных. Некоторые из них созданы для специальных целей, и вам не удастся
их продублировать с помощью обычных операторов (то есть вы не сможете
создать определенную пользователем роль базы данных с аналогичной
функциональностью). Однако большинство из этих ролей было создано для
облегчения работы в наиболее часто встречающихся ситуациях.
Определяемые пользователем роли базы данных
Приведенные выше фиксированные роли служат только для облегчения начала
работы. Реальной основой безопасности должно стать создание определяемых
35
пользователем ролей базы данных. Для этих ролей вы сами решаете, какими
привилегиями они будут обладать.
Для определяемых пользователем ролей вы можете предоставлять, аннулировать
либо отменять те или иные права подобно тому, как вы делали это для отдельных
пользователей. Благодаря наличию ролей все пользователи могут быть поделены
на категории в соответствии с необходимыми уровнями доступа. Вам достаточно
будет внести изменение в одном месте, и оно отразится на всех пользователях с
аналогичными правами (по крайней мере, на тех, которые принадлежат к данной
роли).
36
Глава 3. Разработка программного приложения для управления правами
доступа.
3.1 Выбор инструментальных средств
В качестве среды разработки программного обеспечения была выбрана
CodeGear RAD Studio 2009 - новая версия среды быстрой разработки приложений
(RAD) для Microsoft Windows. Это единственная интегрированная среда
разработки (IDE), которая поддерживает быструю разработку как Windows, так и
.NET-приложений для Microsoft Windows 2000, XP и Vista. Подобная
универсальность позволяет разработчикам строить Web, клиент/серверные и
десктоп Windows-приложения для всех трех ОС и использовать такие приложения
на любой из этих платформ. CodeGear RAD Studio дает разработчикам гибкость в
выборе операционной системы, которая наиболее полно удовлетворяет их
требованиям при создании приложения для нескольких ОС Windows, включая
программы для Windows Vista и Web-приложения.
Возможности выбранной среды разработки:
- Поддержка языка Delphi для разработки в среде Microsoft .NET 2.0 (совместимо
с .NET 3.0) и ASP.NET 2.0. ASP.NET представляет собой набор технологий в
рамках .NET framework для создания Web-приложений и XML Web-сервисов.
- Delphi для .NET имеет поддержку параметризованных типов, позволяющую
разработчикам .NET применять Delphi для создания и использования классов,
используя любой тип структуры данных в качестве параметров.
- Обновленная архитектура доступа к базам данных dbExpress 4 с поддержкой
ADO.NET 2.0. dbExpress 4 - это единое решение для доступа к базам данных для
.NET и Windows с поддержкой ADO.NET.
Соединение с базой данных, как с Oracle так и MS SQL Server, производится
с помощью компонентов ADO.
Преимущества ADO по сравнению с другими технологиями.
37
Технология ADO предлагает разработчику удобный прикладной интерфейс
для OLE DB. ADO удобна в обращении, так как предоставляет объекты
Automation, скрывающие интерфейсы OLE DB, что позволяет программисту
уделять основное внимание решаемым задачам, а не сложностям технологии OLE
DB. ADO-объекты разрешается применять на любой платформе, которая
поддерживает СОМ и Automation, включая языки сценария Microsoft Visual Basic
Scripting Edition (VBScript) и Microsoft JScript. А это означает, что ADO доступна
как в приложениях для Интернета - через технологии типа Active Server Pages
(ASP), так и в средах разработки персональных приложений.
ADO-набор данных допустимо отсоединять от источника данных и
передавать другим приложениям, при этом возможно изменение данных набора в
отрыве от сети и источника данных. В объектной модели ADO существенно
меньше объектов, и он проще в обращении по сравнению с другими объектами
доступа данным, например DAO или RDO.
3.2 Структура и функциональность программного комплекса.
Разработанный программный комплекс состоит из двух независимо
работающих программ: «OracleAdmin» (для работы с правами доступа в СУБД
Oracle) и «MSSQLAdmin» (для работы с правами доступа в СУБД MS SQL
Server), включает в себя следующий функционал:
 Создание, удаление, изменение пользователей,
 Создание, удаление, изменение ролей,
 Назначение системных привилегий пользователю или роли,
 Назначение объектных привилегий пользователю или роли,
 Фильтрация списка пользователей и ролей.
 Название пользователей и ролей символами кириллицы.
38
3.3 Руководство пользователя программы «OracleAdmin»
Главное окно программы «OracleAdmin» (рис. 1) содержит информацию о всех
пользователях СУБД. Нажимая левую кнопку мыши по одному из пользователей,
находящемся в списке, на вкладке «Общие» отображается общая информация,
относящаяся к данному пользователю: Логин, ФИО, Телефонный номер,
Описание (поле, предназначенное для хранения дополнительной информации о
пользователе: № паспорта, должность, отдел и т.д.). Для редактирования или
изменения информации, необходимо внести изменения в соответствующие поля
формы.
Рис. 1 «Главное окно программы OracleAdmin»
На вкладке «Роли» (рис. 2) содержится информация, о всех ролях, присвоенных
пользователю. На форме пользователь может просмотреть доступные
пользователю роли, какие роли предоставлены. Галочка напротив
предоставленной роли говорит о том, что роль была предоставлена с параметром
«Admin Option», т.е. обладатель роли может предоставлять данную роль другим
39
пользователям БД. С помощью кнопок «\/» и «/\» можно изменять набор
предоставленных ролей. Для того, чтобы предоставить роль пользователю,
необходимо выбрать нужную роль из списка «Доступные» и нажать кнопку «\/».
Соответственно, для удаления роли из списка «Предоставленные» необходимо
выбрать предоставленную роль и нажать на кнопку «/\».
Рис. 2 «Роли пользователя»
и нажать на кнопку «Применить», иначе изменения не вступят в силу. Кнопка
«Отменить» служит для отмены внесения изменений.
На вкладке «Системные привилегии» (рис. 3) производятся аналогичные
операции, как и на вкладке «Роли».
40
Рис. 3 «Системные привилегии»
На вкладке «Объектные привилегии» (рис. 4) перед пользователем появляется
информация в виде дерева о всех объектах СУБД: Схемы, типы, таблицы,
просмотры, процедуры, функции, синонимы, последовательности.
Рис. 4 «Объектные привилегии»
При нажатии на объекте, в поле «Доступные привилегии» появляется список
привилегий, которые можно предоставить пользователю. Для этого необходимо
выбрать нужный объект, привилегию, и нажать на кнопку «\/», после чего
предоставленная привилегия появится в таблице «Предоставленные», в которой
41
отображаются: название привилегии (столбец привилегия), название схемы
(столбец «Схема»), в которой находится объект, и название самого объекта
(столбец «Объект»), на который предоставлена привилегия.
3.4 Руководство пользователя программы «MSSQLAdmin»
Первая закладка программы «MSSQLAdmin» (рис. 5) содержит
информацию о всех пользователях СУБД. Для того чтобы внести изменения
необходимо выделить в таблице нужного вам пользователя, и в поля заполнения
внести новые значения. Также в правом верхнем углу существует динамический
поиск по логину, имени, телефону и комментарию. В данной таблице вы можете
посмотрь имя логина в базу данных, имя пользователя, телефон и
комментарий(поле, предназначенное для хранения дополнительной информации о
пользователе: № паспорта, должность, отдел и т.д.).
42
Рис.5 Информация о пользователе
На вкладке «Доб.Роли» (Рис.6) Вы имеете возможность для создания
объектной роли. Для того чтобы создать роль вам необходимо ввести имя новой
роли, возможное пояснение, выбрать базу данных, тип объекта и объект, также
выбираем те возможности которые мы хотим предоставить пользователю
(Delete,Insert,Update).
Для удаление роли необходимо выбрать роль из таблицы и нажать кнопку
«удалить»
Для изменения роли необходимо выбрать роль из таблицы ввести те
значения, которые необходимо изменить и нажать кнопку изменить.
Рис. 6 Добавление роли
43
В вкладке Присвоение роли (рис. 7) мы может присвоить ранее созданную
роль какому либо пользователю. Для того чтобы присвоить роль пользователю
необходимо выбрать пользователя , выбрать роль и нажать кнопку добавить.
Таким образом необходимый пользователь будет добавлен в роль.
Рис 7. Присвоение роли
44
Заключение
В результате проделанной работы было изучено управление правами
доступа в CУБД Oracle 10g и MS SQL Server 2008.
Организация безопасности в Oracle позволяет гибко настроить права
доступа среди пользователей системы. Для этого в СУБД хранятся привилегии,
а также существует возможность создавать пользовательские наборы
привилегий – роли. Все данные, касающиеся безопасности содержатся в
представлениях DBA_ и являются глобальными, хранятся в самом ядре Oracle.
Записи в представлениях DBA_ содержат исчерпывающую информацию о
хранимых объектах. Для получения данных о привилегиях, пользователях или
объектах базы данных достаточно обратиться с помощью SQL-запроса к
соответствующему представлению.
В отличие от Oracle 10g, в MS SQL Server данные о ролях и привилегиях
на объекты непосредственно хранятся в базе данных, к которой принадлежит
объект, что усложняет сбор сведений о предоставленных ролях и привилегиях
определенному пользователю. Для того чтобы, получить список возможных
привилегий, ролей, принадлежностей роль-пользователь необходимо
выполнить целый ряд SQL-запросов.
Для упрощения администрирования БД, был написан программный
комплекс, состоящий из 2-х утилит, позволяющих управлять правами доступа в
Oracle и MS SQL Server. Для работы с программой не требуется знание языка
запросов SQL, а также его процедурного расширения PL/SQL . Включена
возможность фильтрования списка пользователей, ролей, привилегий.
Поддерживается название пользователей и ролей символами кириллицы.
Утилиты могут найти свое применение на любом предприятии, использующем
Oracle или MS SQL.
Таким образом, все задачи выполнены, цели достигнуты.
45
Список литературы
1. Архангельский А. Я. «Программирование в Delphi 6» – М.:ЗАО
«Издательство БИНОМ», 2003.
2. Терьо М., Кармайкл Р. «Oracle 9i, Администрирование баз данных» –
М.:Издательство «Лори», 2005.
3. Роберт Вьейра «SQL Server 2005, программирование» - М.: БИНОМ.
Лаборатория знаний, 2006.
4. Microsoft TechNet. SQL Server 2008, Документация.
[http://technet.microsoft.com/ru-ru/library/ms130214.aspx ]. (20.04.2009)
5. Горнштейн Д., Тамаркин Б. Возможности, достоинства и слабости СУБД
MS SQL Server 2005 (Yukon) и Oracle 10g. (17.04.2007). [http://www.kpress.ru/cs/2006/1/MSSQLvsORA/MSSQLvsORA.asp]. (13.05.2009)
46