Ролевое разграничение доступа основано на том соображении, что в реальной жизни организации ее сотрудники выполняют определенные функциональные обязанности не от своего имени, а в рамках некоторой занимаемой ими должности (или роли). Количество ролей в системе может не соответствовать количеству реальных пользователей - один пользователь, если на нем лежат различные обязанности, требующие различных полномочий, может выполнять (одновременно или последовательно) несколько ролей, а несколько пользователей могут пользоваться одной и той же ролью, если они выполняют одинаковую работу. Реализация ролевого разграничения доступа к объектам СУБД или компьютерной системы в целом требует разработки набора (библиотеки) ролей, определяемых как набор прав доступа к объектам информационной системы (прав на выполнение над ними определенного набора действий). Этот набор прав должен соответствовать выполняемым работником обязанностям.

Ролевое разграничение доступа оперирует следующими понятиями:

· субъекты и объекты доступа;

· привилегии - минимально возможные действия субъекта, требующие разрешения или запрещения этого действия;

· правила - объединение привилегии, подмножества объектов, для которых может быть определена данная привилегия, и признака разрешения или запрещения этой привилегии;

· роль - набор правил, соответственно определяющих, какими привилегиями и по отношению к каким объектам будет обладать субъект, если ему будет назначена эта роль;

· сессия - подмножество ролей, которые активировал субъект после входа в систему в течение определенного интервала времени.

При использовании ролевой политики управление доступом осуществляется в три стадии: во-первых, для каждой роли указывается набор полномочий, представляющий набор прав доступа к объектам, во-вторых, каждому пользователю назначается список доступных ему ролей, и, в-третьих, после авторизации пользователя в системе для него создается сессия. Полномочия назначаются ролям в соответствии с принципом наименьших привилегий, из которого следует, что каждый пользователь должен обладать только минимально необходимым для выполнения своей работы набором полномочий. При реализации ролевой модели может быть введен ряд ограничений: например, назначение роли главного администратора (суперпользователя) может быть предоставлено только одному пользователю, вводится запрет совмещения одним пользователем определенных ролей, ограничивается количество пользователей, одновременно выполняющих определенную роль и т.п.

Критерий безопасности системы при использовании ролевой модели можно сформулировать следующим образом: система считается безопасной, если любой пользователь в системе может осуществлять только те действия, которые требуют полномочий, входящих в совокупность полномочий всех ролей, доступных для него в данной сессии. В отличие от других моделей, ролевая модель управления доступом практически не гарантирует безопасность с помощью формальных доказательств, а только определяет характер ограничений, соблюдение которых и служит критерием безопасности системы.

Ролевая модель разграничения доступа сочетает элементы мандатного разграничения (объединение объектов и привилегий доступа в одном правиле) и дискреционного разграничения (назначение ролей отдельным субъектам). Этим обеспечивается жесткость правил разграничения доступа и гибкость настройки механизма разграничения в конкретных условиях применения. Преимущества ролевого разграничения доступа к объектам проявляются при организации коллективного доступа к ресурсам сложных информационных систем с большим количеством пользователей и объектов. К достоинству ролевого разграничения доступа следует также отнести наличие иерархии ролей, разделение обязанностей, возможность регистрации в системе с наименьшей ролью (принцип наименьших привилегий) и возможность запуска приложений, требующих фиксированного набора прав доступа, не зависящих от прав доступа пользователя, запустившего данное приложение, что возможно при назначении пользователю определенной роли. К недостаткам ролевого разграничения доступа относится отсутствие формальных доказательств безопасности компьютерной системы, возможность внесения дублирования и избыточности при предоставлении пользователям прав доступа и сложность конструирования ролей.

Наряду с дискреционной, ролевая модель разграничения доступа, реализована во множестве развитых коммерческих СУБД.



2. Архитектура системы безопасности SQL Server

Система безопасности MS SQL Server реализует дискреционный и ролевой подходы к управлению доступом и имеет два уровня: уровень сервера и уровень базы данных (рисунок 1). На уровне сервера разрешается или отклоняется доступ пользователей к самому серверу. На уровне базы данных пользователи, имеющие доступ на уровне сервера, получают доступ к объектам базы данных. Такой подход позволяет более гибко управлять доступом пользователей к базам данных.

Рисунок 1. Обобщенная схема безопасности СУБД MS SQL Server

На уровне сервера система безопасности оперирует следующими понятиями:

· аутентификация (authentication);

· учетная запись (login);

· встроенные роли сервера (fixed server roles).

На уровне базы данных используются понятия:

· пользователь базы данных (database user);

· фиксированная роль базы данных (fixed database role);

· пользовательская роль базы данных (users database role);

· роль приложения (application role). Следовательно, можно выделить две группы ролей:

· роли сервера (server role);

· роли базы данных (database role).

2.1 Система безопасности уровня сервера

SQL Server использует двухэтапную схему аутентификации. Вначале пользователь аутентифицируется сервером. Только после успешной аутентификации на сервере пользователю может быть предоставлен доступ к одной или нескольким БД. SQL Server хранит всю информацию о регистрационных записях в базе данных master.

SQL Server предлагает два режима аутентификации пользователей:

· Режим аутентификации средствами OS Windows. В этом режиме SQL Server полностью доверяет операционной системе при аутентификации пользователей;

· Смешанный режим аутентификации (Windows Authentication and SQL Server Authentication). В этом режиме системы аутентификации Windows и SQL Server существуют независимо друг от друга.

При установке SQL Server одним из первых решений, которые следует принять, является выбор используемого метода аутентификации. Установленный при инсталляции режим аутентификации можно изменить на странице Security диалогового окна SQL Server Properties в утилите Management Studio. В программном коде установленный режим аутентификации можно проверить с помощью системной хранимой процедуры xp_loginconfig:

EXEC xp_loginconfig 'login mode'

Результат выполнения этой процедуры выглядит следующим образом:

nameconfig_value login mode Mixed

Соответственно, пользователь должен быть идентифицирован сервером одним из следующих методов:

· с помощью учетной записи пользователя Windows (в общем случае принадлежащей некоторому домену или рабочей группе);

· на основе членства в одной из групп пользователей Windows;

· с помощью отдельной регистрационной записи SQL Server (если на сервере используется смешанная модель безопасности).

Не следует путать регистрационные записи SQL Server с учетными записями Windows в этом сервере баз данных. Эти два типа регистрации совершенно различны. Пользователям SQL Server не нужен доступ к каталогам, где хранятся файлы базы данных, или к любым другим файлам, так как реальный доступ к файлам осуществляет процесс SQL Server, а не сам пользователь. В то же время права доступа к файлам нужны самому процессу SQL Server, следовательно, ему нужна учетная запись Windows. Здесь также доступны два варианта:

· Учетная запись локального администратора. SQL Server может использовать эту учетную запись для получения доступа к компьютеру, на котором установлен. Этот вариант идентичен установке на обособленный сервер, так как в этом случае нет возможности поддерживать сетевую систему безопасности Windows, необходимую для распределенной обработки;

· Учетная запись пользователя домена (рекомендуется). SQL Server может использовать учетную запись пользователя домена Windows, созданную специально для него. Учетной записи пользователя SQL Server могут быть назначены административные привилегии для локального сервера, и посредством него он может получить доступ к сети для поддержания взаимодействия с другими серверами.

Набор ролей сервера строго ограничен. Никто, включая администратора сервера, не может создать новую или удалить существующую роль сервера. Поэтому они называются фиксированными ролями (fixed server roles). В таблице 2 приведен список некоторых фиксированных ролей сервера с кратким описанием каждой из них.

Таблица 2. Список фиксированных ролей сервера.

Sysadmin (System Administrators)	Члены этой роли имеют абсолютные права в SQL Server. Никто не имеет больших прав доступа, чем члены данной роли.
Setupadmin (Setup Administrators)	Этой роли предоставлены права управления связанными серверами, конфигурирования хранимых процедур, запускаемых автоматически при старте SQL Server, а также право добавлять учетные записи в роль setupadmin.
Serveradmin (Server Administrators)	Обычно в эту роль включаются пользователи, которые должны выполнять администрирование сервера. Имеют право на останов сервера (SHUTDOWN), изменять параметры работы служб (sp_conf igure), применять изменения (RECONFIGURE), управлять полнотекстовым поиском (sp_fulltext_service).
Securityadmin (Security Administrators)	Члены данной роли имеют возможность создавать новые учетные записи, которым они могут предоставлять права на создание баз данных и ее объектов, а также управлять связанными серверами, включать учетные записи в роль securityadmin и читать журнал ошибок SQL Server.
Dbcreator (Database Creators)	Члены этой роли могут создавать новые базы данных, удалять и переименовывать имеющиеся, восстанавливать резервные копии базы данных и журнала транзакций.

Для добавления учетной записи пользователя в ту или иную фиксированную роль сервера можно воспользоваться хранимой процедурой sp_addsrvrolemember, имеющей следующий синтаксис:

sp_addsrvrolemember [@loginame =] 'login' , [@rolename =] 'role'

Например, добавление учетной записи Windows с именем Admin компьютера STORAGE в фиксированную роль сервера sysadmin выглядит так:

EXEC sp_addsrvrolemember 'STORAGE\Admin', 'sysadmin'

Хотя в общем случае требуется, чтобы на сервере существовала учетная запись, которую предполагается включить в одну из фиксированных ролей, есть одно исключение. Дело в том, что пользователь Windows может получить доступ к SQL Server как член группы Windows, которой предоставлен доступ к серверу. Такие учетные записи можно включать в роли сервера без предварительного предоставления доступа непосредственно учетной записи. Для получения информации о том, какая учетная запись в какую фиксированную роль сервера включена, используется следующая системная хранимая процедура:

sp_helpsrvrolemember [ [@srvrplename =] 'role']

Если процедура вызывается без параметров, то выводится полный список учетных записей, включенных в любую из ролей сервера. Когда же необходимо получить список учетных записей, включенных в конкретную роль сервера, требуется указать имя роли. В приведенном ниже примере выводится информация о членах роли sysadmin:

EXEC sp_helpsrvrolemember 'sysadmin'

Для удаления учетной записи из фиксированной роли сервера предназначена системная хранимая процедура sp_dropsrvroiemember, имеющая синтаксис:

sp_dropsrvrolemember [@loginame =] 'login', [@rolename =] 'role'

Из приведенного списка ролей уровня сервера видно, что включение пользователей в эти роли позволяет определить только администраторов сервера, а не рядовых пользователей БД. Путь добавления обычных пользователей БД зависит от выбранного режима аутентификации пользователей.

2.1.1 Аутентификация Windows

Использование аутентификации Windows означает, что пользователю для доступа к SQL Server достаточно иметь учетную запись Windows. Идентификатор безопасности Windows передается из операционной системы на сервер баз данных. SQL Server предполагает, что процесс регистрации пользователей в сети достаточно защищен, и поэтому не выполняет никаких дополнительных проверок. Пользователь автоматически получает соответствующие права доступа к данным SQL Server сразу же после регистрации в домене. Такой метод предоставления доступа называется установлением доверительного соединения. Операционная система работает с учетными записями (logins), которые содержат все данные о пользователе, включая его имя, пароль, членство в группах, каталог по умолчанию и т. д. Каждая учетная запись имеет уникальный идентификатор (Login ID) или, как его называют по-другому, идентификатор безопасности (SID, Security Identification), с помощью которого пользователь регистрируется в сети.

Идентификатор представляет собой длинное (85-битовое) шестнадцатеричное число, которое генерируется случайным образом операционной системой во время создания учетной записи. Такой подход позволяет избежать подделки учетных записей пользователей. Если пользователь был удален из домена, то даже повторное создание пользователя с аналогичными характеристиками (имя учетной записи, пароль, членство в группе и т. д.) не даст возможности получить доступ к объектам, к которым имел доступ оригинальный пользователь. Применительно к SQL Server можно сказать, что если пользователь домена имел определенные права доступа, но был удален, то никто не сможет присвоить его права доступа.

Аутентификация Windows предусматривает сохранение в системной базе данных Master только идентификационного номера учетной записи пользователя в домене (SID). Информация об имени пользователя, его пароле и т. д. хранится в базе данных домена. Изменение имени пользователя или его пароля никак не отразится на правах доступа к SQL Server. Информация об учетной записи пользователя и его членстве в группах Windows считывается SQL Server из базы данных системы безопасности домена во время подключения пользователя. Если администратор внес какие-то изменения в учетную запись пользователя, например, исключил его из некоторой группы, то изменения отразятся только во время очередной регистрации пользователя в домене или в SQL Server в зависимости от категории сделанных изменений.

Аутентификация Windows дает определенные преимущества. На пользователях автоматически отражаются все правила политики безопасности, установленные в домене. Пользователю не приходится запоминать еще один пароль. Это повышает уровень общей защищенности данных. Например, автоматически контролируется минимальная длина пароля и срок его действия. Операционная система требует от пользователя периодической смены пароля. Дополнительно можно запретить пользователям установку паролей, уже указывавшихся ранее. Кроме того, Windows имеет встроенные средства защиты от подбора паролей. Аутентификация Windows работает также с группами пользователей. Ко гда имя группы Windows передается в SQL Server в качестве регистрационной записи, любой член этой группы может быть аутентифицирован сервером баз данных. SQL Server также известно истинное имя пользова теля Windows, входящего в группу, вследствие чего приложение может выполнять аудит на уровне пользователей, а также на уровне групп пользователей.

Для создания учетной записи пользователя или группы Windows в SQL Server в программном коде используется системная хранимая процедура sp_grantlogin. В качестве аргумента ей необходимо передавать полное имя пользователя, включающее имя домена, как в следующем примере:

EXEC sp_grantlogin 'RFE\Sidorov'

Для удаления учетной записи или группы Windows из SQL Server программным путем используется системная хранимая процедура sp_revokelogin:

EXEC sp_revokelogin 'RFE\Sidorov'

Разумеется, эта операция не удаляет данную учетную запись из операционной системы - произойдет всего лишь исключение пользователя из списка пользователей сервера баз данных.

Запрет учетной записи Windows можно произвести с помощью системной хранимой процедуры sp_denylogin. Следовательно, доступ любого пользователя в SQL Server может быть принудительно закрыт. Это полностью запрещает доступ пользователя к SQL Server, даже если он бал открыт с помощью другого метода.

EXEC sp_denylogin 'RFE\Sidorov'

Если пользователь Windows был добавлен в SQL Server, а затем был удален из домена Windows, он продолжает существовать как пользователь в севере баз данных, но считается уже осиротевшим. Это значит, что, несмотря на то, что пользователь формально имеет доступ к серверу, он не имеет доступа к ресурсам сети и, следовательно, ко всему комплексу средств SQL Server. Системная хранимая процедура sp_validatelogins позволяет найти "осиротевших" пользователей и возвращает их идентификаторы системы безопасности Windows NT и имена учетных записей. В следующем примере пользователю RFE\Joe был открыт доступ к SQL Server, после чего его учетная запись была удалена из Windows:

EXEC sp_validatelogins

SIDNT Login

Ox010500000000000515000000FCE31531A931RFE\Joe

Это нельзя считать брешью в системе безопасности. Не имея учетной записи Windows с таким идентификатором (невозможно повторно создать учетную запись и заданным SID), пользователь не сможет подключиться к SQL Server. Для разрешения проблемы "осиротевших" пользователей можно использовать следующий протокол:

1. Отзовите права доступа пользователя ко всем базам данных с помощью хранимой процедуры sp_revokedbaccess;

2. Отзовите право доступа данного пользователя к серверу с помощью sp_revokelogin;

3. Создайте для пользователя новую учетную запись;

4. Зарегистрируйте учетную запись на сервере.

2.1.2 Аутентификация SQL Server

Этот тип аутентификации реализуется на самом сервере SQL Server. В этом случае в системной базе Master хранится полная информация о пользователях включая имя пользователя и его пароль. Для каждого пользователя указывается имя учетной записи, уникальный идентификатор SQL Server, пароль и другая информация. При попытке пользователя подключиться к серверу система безопасности потребует ввести имя учетной записи и ее пароль. Затем система сравнивает введенные данные с информацией, хранящейся в системных таблицах. Если данные совпадают, то доступ предоставляется. В противном случае пользователь получает сообщение об ошибке, и соединение не устанавливается.

Наличие дополнительных регистрационных записей SQL Server уместно тогда, когда аутентификация Windows не доступна или не подходит для создаваемой системы. Эта регистрация имеет обратную совместимость с предыдущими версиями сервера, а также с приложениями, в которых регистрационная запись встроена в программный код. Аутентификация SQL Server в основном применяется клиентами, для которых недоступна регистрация в домене Windows. Например, пользователями

Novell NetWare, Unix и т. д. При подключении к SQL Server через Internet регистрация в домене не выполняется, поэтому в данном случае также необходимо использовать аутентификацию SQL Server.

В процессе инсталляции SQL Server и выборе смешанного режима аутентификации мастер установки создает специальную учетную запись sa (system administrator) с пустым паролем, являющийся членом фиксированной серверной роли sysadmin и имеющий все права доступа к серверу. Зачастую ему забывают присвоить пароль, и эти прямые ворота в системе безопасности открывают путь к серверу любому взломщику. Как правило, наличие такой бреши хакеры проверяют в первую очередь. Исходя из этого, прежде всего нужно задать пароль или просто отключить пользователя sa и назначить административной роли sysadmin какого-то другого пользователя (или создать дополнительные роли с административными привилегиями). Эта учетная запись оставлена для сохранения обратной совместимости с предыдущими версиями SQL Server. Ранее учетная запись была обязательной, имела абсолютные права по управлению сервером и не могла быть удалена. Пользователю sa в процессе установки всегда присваивается одинаковый на все компьютерах идентификатор безопасности 0x01.

Идентификатор безопасности хранится в столбце sid таблицы sysxlogins системной базы данных Master. В ней хранится информация об учетных записях как SQL Server, так и Windows. Для учетных записей SQL Server максимальный размер идентификатора безопасности составляет 16 байт, для учетных записей Windows - 28 байт. Каждая строка этой таблицы соответствует одной учетной записи. Таким образом, в таблице sysxlogins может содержаться довольно много строк с информацией об учетных записях. Для более удобной работы с локальными учетными записями можно использовать представление syslogins, включающее только те строки таблицы sysxlogins, которые имеют в столбце srvid (идентификационный номер сервера) значение NULL.

Для регистрации пользователя используется системная хранимая процедура sp_addlogin:

sp_addlogin 'имя', 'пароль', 'база_по_умолчанию', 'язык_по_умолчанию', 'идентификатор_пользователя_сервера', 'параметр_шифрования'

Среди передаваемых процедуре аргументов обязательным является только имя регистрационной записи. Так как в данном случае требуется настройка пользователя, а не просто выбор его из списка, данная задача более сложная, чем выполнение процедуры sp_grantlogin. Например, следующий программный код создает пользователя SQL Server с именем Hurs и назначает ему в качестве базы данных по умолчанию учебную базу test:

EXEC sp_addlogin 'Hurs', 'myoldpassword', 'test'

Параметр шифрования skip_encryption указывает серверу хранить пароль в системной таблице sysxlogins без всякого шифрования. В то же время SQL Server ожидает, что пароль обязательно будет зашифрован, поэтому он не распознает созданный таким образом пароль. Следовательно, следует избегать использования этого параметра.

Если некоторый пользователь создается на двух серверах как один и тот же, то для второго сервера следует явно задать идентификатор SID, присвоенный первым сервером. Для получения идентификатора SID используется представление sysserver_principals:

SELECT Name, SID FROM sysserver_principals WHERE Name = 'Den'

NameSID

Den0X1EFDC478DEB52 045B52D241B33B2CD7E

Пароль может быть изменен с помощью системной хранимой процедуры sp_password:

EXEC sp_password 'myoldpassword', 'mynewpassword', 'Den'

Если пароль пуст, то в хранимую процедуру вместо пустой строки (' ') передается NULL. Если параметр @sid опущен или для него указано значение NULL (также являющееся значением по умолчанию для параметра @sid), то хранимая процедура sp_addlogin самостоятельно сгенерирует идентификатор безопасности. Для примера создадим учетную запись с конкретным идентификатором безопасности и паролем:

USE pubs

EXEC sp_addlogin 'Andrey' ,'analitik', @sid = 0x0123456789ABCDEF0123456789ABCDEF

После создания учетной записи можно изменить идентификатор безопасности с помощью команды UPDATE, напрямую обратившись к системной таблице. При выборе значения для параметра @sid следует соблюдать требование уникальности идентификаторов безопасности. То есть на текущем сервере к моменту регистрации не должно быть учетных записей с идентификатором безопасности, равным выбранному значению. Список используемых идентификаторов безопасности локального сервера можно просмотреть с помощью следующего запроса:

SELECT sid FROM syslogins

Для удаления регистрационной записи SQL Server используется системная хранимая процедура sp_droplogin:

EXEC sp_droplogin 'Den'

Удаление учетной записи приводит к удалению и всех ее настроек безопасности.

2.2 Система безопасности уровня базы данных

Для того чтобы пользователь имел возможность выполнять те или иные действия с объектами базы данных, он должен предварительно получить необходимые права доступа. Владелец базы данных или конкретного объекта должен предоставить пользователям базы данных возможность обращения к объектам базы данных. Помимо прав доступа, выдаваемых пользователю явно, существует класс неявных прав доступа. Неявные права доступа предоставляются пользователю через членство в фиксированной роли сервера или базы данных. Например, нет никакой другой возможности предоставить пользователю право на создание баз данных, кроме как включить его в роль сервера dbcreator. Другим примером работы неявных прав доступа является получение владельцем объекта абсолютных прав на управление объектом владения. Если пользователь создал объект в базе данных, то ему автоматически предоставляются максимальные права по управлению этим объектом.

Таким образом, на уровне базы данных пользователю могут быть предоставлены привилегии с помощью прикрепления к фиксированной роли базы данных или путем явного назначения привилегий с помощью оператора SQL GRANT. Исключением являются пользователи, учетные записи которых включены в фиксированную роль сервера sysadmin. Члены данной роли имеют неограниченные права в пределах сервера, и, как следствие, полный доступ к любой базе данных, имеющейся на сервере.

В таблице 3 перечислены все фиксированные роли базы данных.

Таблица 3. Фиксированные роли базы данных.

db_securityadmin	Члены роли могут управлять правами доступа к объектам базы данных других пользователей и членством их в ролях
db_owner	Члены роли имеют права владельца, т. е. могут выполнять любые действия
db_denydatawriter	Членам этой роли запрещено изменение данных независимо от выданных им разрешений
db_denydatareader	Членам данной роли запрещен просмотр данных независимо от выданных им разрешений
db_ddladmin	Члены роли могут создавать, изменять и удалять объекты базы данных
db_datawriter	Пользователи, включенные в эту роль, могут изменять данные в любой таблице или представлении базы данных
db_datareader	Пользователи, включенные в эту роль, могут читать данные из любых таблиц и представлений базы данных
db_backupoperator	Члены роли выполняют резервное копирование базы данных
db accessadmin	Члены роли имеют право управлять пользователями базы данных: создавать, удалять и изменять

Пользовательские роли - это дополнительные роли, служащие в качестве групп. Роли может быть разрешен доступ к объекту базы данных, а пользователю может быть назначена пользовательская роль базы данных. Все пользователи автоматически становятся членами стандартной роли базы данных public.

Включение пользователей в роль реализует неявное назначение привилегий. Явные разрешения к объектам назначаются с помощью инструкций SQL GRANT, REVOKE, DENY и они достаточно детализированы. Существуют отдельные разрешения для каждого из возможных действий (SELECT, INSERT, UPDATE, RUN и т.д.) над любым объектом. Запрет привилегии замещает собой ее предоставление, а предоставление привилегии замещает собой ее отзыв. Пользователю может быть предоставлено множество разрешений к объекту (индивидуальных, наследованных от некоторой роли или обеспеченных принадлежностью к роли public). Некоторые фиксированные роли базы данных также влияют на доступ к объекту, например, управляя возможностью считывать информацию и записывать ее в базу данных. Вполне возможна ситуация, когда пользователь был распознан в SQL Server, но у него нет доступа ни к одной из его баз данных. Также возможно и обратное: пользователю открыт доступ к базам данных, но он не был распознан сервером. Перемещение базы данных и ее разрешений на другой сервер без параллельного перемещения регистрационных записей сервера может привести к возникновению таких "осиротевших" пользователей.

В любой базе данных автоматически создаются два пользователя:

1. dbo (database owner). Это специальный пользователь базы данных, являющийся ее владельцем. Владелец базы данных имеет абсолютные права по управлению ею. Пользователя dbo нельзя удалить. По умолчанию в пользователя dbo отображается учетная запись sa, которой тем самым предоставляются максимальные права в базе данных. Кроме того, все члены роли базы данных dbowner также считаются владельцами базы данных. Пользователь dbo включен в роль db_owner и не может быть удален из нее;

2. guest. Если учетной записи явно не предоставлен доступ к базе данных, то она автоматически отображается сервером в пользователя guest. С помощью этого пользователя можно предоставлять разрешения на доступ к объектам базы данных, необходимые любому пользователю. Разрешив доступ пользователю guest, вы, тем самым, даете аналогичные права доступа всем учетным записям, сконфигурированным на SQL Server. Для повышения безопасности хранящейся информации рекомендуется удалять пользователя guest из базы данных.

Информация о пользователях, созданных в базе данных, хранится в системной таблице sysusers. Информацию о пользователях текущей базы данных можно получить с помощью системной хранимой процедуры sp_helpuser:

USE pubs

EXEC sp_helpuser

Создание нового пользователя и связывание его с учетной записью выполняется с помощью одной из двух хранимых процедур:

· sp_adduser. Данная процедура оставлена для обеспечения совместимости с предыдущими версиями SQL Server и оперирует устаревшими понятиями.

· sp_grantdbaccess. Эта хранимая процедура полностью соответствует понятиям системы безопасности SQL Server и пришла на смену предыдущей процедуре, начиная с версии SQL Server 7.0.

Процедура sp_grantdbaccess имеет следующий синтаксис:

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

Правом вызова указанной хранимой процедуры обладают члены фиксированной роли сервера sysadmin и члены фиксированных ролей базы данных db_owner и db_accessadmin. Параметр @loginame определяет имя учетной записи, которой предполагается предоставить доступ к текущей базе данных. Указанная учетная запись должна существовать на сервере. С помощью параметра @name_in_db указывается имя, которое будет присвоено создаваемому пользователю. Это имя должно быть уникальным в пределах базы данных. Приведенный далее пример иллюстрирует использование хранимой процедуры sp_grantdbaccess. В базе данных pubs создается новый пользователь с именем Admin, который связывается с учетной записью STORAGE\Admin:

USE pubs

EXEC sp_grantdbaccess 'STORAGE\Admin', 'Admin'

Удаление пользователя выполняется с помощью системной хранимой процедуры sp_revokedbaccess, имеющей синтаксис:

sp_revokedbaccess [@name_in_db =] 'name'

Правом вызова указанной хранимой процедуры обладают члены фиксированной роли сервера sysadmin и члены фиксированных ролей базы данных db_owner и db_accessadmin. Единственный параметр процедуры определяет имя пользователя, которого необходимо удалить. Однако, прежде чем решиться на подобный шаг, следует убедиться, что пользователю не принадлежит никакой объект базы данных. Если же пользователь является владельцем одного из объектов базы данных, то следует либо удалить этот объект с помощью команды DROP, либо изменить владельца объекта с помощью системной хранимой процедуры sp_changeobjectowner. Например, для удаления пользователя Admin достаточно будет выполнить команду:

EXEC sp_revokedbaccess 'Admin'

Чтобы включить нового члена в фиксированную роль базы данных, необходимо вызвать системную хранимую процедуру sp_addrolemember, имеющую синтаксис:

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

С помощью параметра @rolename указывается имя роли, в которую требуется добавить нового члена. Указанная роль должна существовать в текущей базе данных. Например:

EXEC sp_addrolemember 'db_accessadmin', 'User1'

Для получения информаци о членстве во всех ролях текущей базы данных можно использовать процедуру sp_helprolemember. Например:

USE pubs

EXEC sp_helprolemember

Исключение из фиксированной роли выполняется с помощью процедуры sp_droprolemember. Например, для исключения из фиксированной роли db_accessadmin пользователя User1 необходимо выполнить следующую команду:

USE pubs

EXEC sp_droprolemember 'db_accessadmin', 'User1'

Если фиксированные роли предназначены для наделения пользователей специальными правами в базе данных, то пользовательские роли служат лишь для группировки пользователей с целью облегчения управления их правами доступа к объектам. Создание пользовательской роли выполняется с помощью системной хранимой процедуры sp_addrole, которая имеет синтаксис:

sp_addrole [@rolename =] 'role' [, [@ownername =] 'owner']

или просто CREATE ROLE <rolename>

Правом выполнения указанной хранимой процедуры обладают члены фиксированной роли сервера sysadmin и фиксированных ролей базы данных db_owner и db_securityadmin. По умолчанию владельцем роли становится владелец базы данных (пользователь dbo). Таким образом, пользователь dbo приобретает полный контроль над ролью. Если необходимо присвоить права владения ролью другому пользователю, то имя этого пользователя должно быть указано с помощью параметра @ownername. Указываемый пользователь должен иметься в базе данных. Владельцем пользовательской роли может также являться и роль приложения. В качестве примера рассмотрим создание пользовательской роли AccessDBUser, владельцем которой будет являться пользователь guest:

USE pubs

EXEC sp_addrole 'AccessDBUser', 'guest'

Удаление пользовательской роли осуществляется с помощью хранимой процедуры sp_droprole, имеющей следующий синтаксис:

sp_droprole [rolename =] 'role'

С помощью единственного параметра процедуры указывается имя пользовательской роли, которую необходимо удалить из текущей базы данных. Однако перед подобной операцией нужно удалить из нее всех членов, для чего можно использовать хранимую процедур sp_droprolemember. Если роль владеет одним или более объектами базы данных, то уничтожить такую роль будет невозможно. Прежде чем приступить к удалению, необходимо либо передать права владения соответствующими объектами с помощью хранимой процедуры sp_changeobjectowner, либо удалить эти объекты. С помощью приведенного ниже примера можно удалить пользовательскую роль

USE pubs

EXEC sp_droprole 'AccessDBUser'

Для просмотра списка явных прав доступа возможен запуск системной хранимой процедуры sp_helprotect, имеющей синтаксис:

sp_helprotect [[@name =] 'object_statement'] [, [@username

=] 'security_account'] [, [@grantorname =] 'grantor'] [, [@permissionarea =] 'type']

Например:

sp_helprotect Clients(для объекта Clients)

sp_helprotect @username = 'RFE\Joe' (дляпользователя RFE\Joe)

Данная процедура эффективна лишь для просмотра явных привилегий, назначенных с помощью оператора GRANT. Для просмотра всех привилегий, включая неявные, следует использовать следующий SQL запрос:

WHERE principal_type_desc <> 'DATABASE_ROLE' UNION

--role members

SELECT rm.member_principal_name, rm.principal_type_desc, p.class_desc, p.object_name, p.permission_name, p.permission_state_desc,rm.role_name

FROM perms_cte p right outer JOIN (

select role_principal_id, dp.type_desc as principal_type_desc, member_principal_id, user_name(member_principal_id) as member_principal_name, user_name(role_principal_id) as role_name--,*

from sys.database_role_members rm INNER JOIN sys.database_principals dp

ON rm.member_principal_id = dp.principal_id

) rm

ON rm.role_principal_id = p.principal_id order by 1



3. Реализация базы данных

3.1 Инструментарий разработки БД

Реализация БД велась в Microsoft SQL Server 2017. Microsoft SQL Server -- это семейство продуктов, разработанных для хранения данных в больших системах, осуществляющих обработку информации, и обслуживания коммерческих Web-узлов. Основной используемый язык запросов - Transact-SQL, создан совместно Microsoft и Sybase. Transact-SQL является реализацией стандарта ANSI/ISO по структурированному языку запросов (SQL) с расширениями. Используется для работы с БД размером от персональных до крупных баз данных масштаба предприятия; конкурирует с другими СУБД в этом сегменте рынка. SQL Server прост и удобен в использовании, он широко применяется как в сложных системах, с которыми работают сотни пользователей, так и в малом бизнесе. Он популярен также у отдельных пользователей, которым нужен надежный и удобный сервер БД. В состав SQL Server входят две основные службы, предназначенные для новой платформы Microsoft.NET и систем с традиционной двухуровневой клиент-серверной архитектурой. Первая служба, SQL Server -- это высокопроизводительное реляционное ядро БД, обеспечивающее прекрасную масштабируемость систем, созданных на его основе. Вторая -- SQL Server Analysis Services -- предоставляет множество средств анализа данных, которые размещаются в специальных хранилищах и киосках данных и используются системами принятия решений.

Microsoft SQL Server - это реляционная система управления базой данных. В реляционных базах данных данные хранятся в таблицах. Взаимосвязанные данные могут группироваться в таблицы, кроме того, могут быть установлены также и взаимоотношения между таблицами. Пользователи получают доступ к данным на сервере через приложения, а администраторы, выполняя задачи конфигурирования, администрирования и поддержки базы данных, производят непосредственный доступ к серверу. SQL Server является масштабируемой базой данных, это значит, что она может хранить значительные объемы данных и поддерживать работу многих пользователей, осуществляющих одновременный доступ к базе данных.

3.2 Создание базы данных

3.2.1 Описание предметной области

В настоящее время эффективное функционирование современного предприятия невозможно без применения информационных систем. Эта проблема актуальна как для крупных предприятий, так и для предприятий среднего и даже малого бизнеса. Информационные системы имеют ряд существенных отличий от стандартных прикладных программ. В зависимости от предметной области информационные системы могут сильно различаться по своей архитектуре и функциям.

При разработке базы данных «Банк. Область ИБ» было проведено обследование предметной области. В результате в БД «Банк. Область ИБ» используются следующие входные данные:

информация о сотрудниках;

информация об области работы сотрудников;

информация о помещениях.

Выходными данными являются выходные формы, запросы. Как же в выпускной квалификационной работе использовано ограничение на ввод данных, например, пользователю сообщается об ошибке, если он введет отрицательный номер кабинета.

3.2.2 Проектирование реляционной базы данных

Перечень атрибутов:

Таблица «Сотрудники» содержит:

· id_сотрудника - уникальный идентификатор сотрудника

· Фамилия - фамилия сотрудника

· Имя - имя сотрудника

· Отчество - отчество сотрудника

· Пол - пол сотрудника

· Должность - должность сотрудника

«Область работы» содержит:

· Название области работы - название области работы

· Детали - детали области работы

«Сотрудники и область их работы» содержит:

· id_сотдруника - уникальный номер сотрудника

· Название области работы - название области работы сотрудника

«Помещения» включает в себя:

· Номер помещения - уникальный номер помещения

· Название помещения - название помещения

«Помещения и сотрудники» содержит:

· Номер помещения - уникальный номер помещения

· id_сотрудника - уникальный норме сотрудника

3.2.3 Инфологическая модель базы данных

Цель инфологического моделирования - обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Поэтому инфологическую модель данных пытаются строить по аналогии c естественным языком, который не может быть использован в чистом виде из-за сложности компьютерной обработки текстов и неоднозначности любого естественного языка. Основными конструктивными элементами инфологических моделей являются сущности, связи между ними и их свойства (атрибуты).

Сущность - любой различимый, информацию о котором необходимо хранить в базе данных. Сущностями могут быть люди, места, самолёты, рейсы, вкус, цвет и т.д. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе.

Атрибут - поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности. Например, атрибуты используются для определения того, какая информация должна быть собрана о сущности. Абсолютное различие между типами сущностей и атрибутами отсутствует. Атрибут является таковым только в связи c типом сущности. В другом контексте атрибут может выступать как самостоятельная сущность.

Ключ - минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся атрибутам.

Связь - ассоциирование двух или более сущностей. Если бы назначением базы данных было только хранение отдельных, не связанных между собой данных, то ее структура могла бы быть очень простой. Однако одно из основных требований к организации базы данных - это обеспечение возможности отыскания одних сущностей по значениям других, для чего необходимо установить между ними определенные связи. A так как в реальных базах данных нередко содержатся сотни или даже тысячи сущностей, то теоретически между ними может быть установлено более миллиона связей. Наличие такого множества связей и определяет сложность инфологических моделей.

3.2.4 Описание связей

В базе данных определены отношения между таблицами которые указаны в таблице 4.

Таблица 4. Отношения между таблицами

Таблица «Сотрудники»	Таблица «Сотрудники и область их работы»
id	id
Тип отношений:	Один ко многим
Таблица «Помещения и сотрудники»	Таблица «Сотрудники»
id	id_cотрудника
Тип отношений:	Один ко многим
Таблица «Область работы»	Таблица «Сотрудники и область их работы»
Название области работы	Название области работы
Тип отношений:	Один ко многим
Таблица «Помещения»	Таблица «Помещения и сотрудники»
Номер помещения	Номер помещения
Тип отношений:	Один к одному

3.2.5 Даталогичеcкое проектирование БД

В этом разделе приводится состав таблиц БД. Для каждого поля таблицы указывается размер поля (количество символов), тип. Для первичных ключей необходимо ввести запрет неопределенных значений. Для остальных полей возможность запрета неопределенных значений определяется семантикой предметной области. Даталогичеcкая модель представлена в рисунке 2.

Рисунок 2. Даталогичеcкая модель базы данных.

Таблица 5. Помещения

Наименование атрибутов	Тип полей	Размер полей	Допустимость неопределенных значений
Номер помещения	tinyint		Not Null
Фамилия	Nvchar	50

Таблица 6. Помещения и сотрудники

Наименование атрибутов	Tип полей	Размер полей	Допустимость неопределенных значений
Номер помещения	tinyint	14	Not null
Id сотрудника	bigint	25

Таблица 7. Область работы

Наименование атрибутов	Тип полей	Размер полей	Допустимость неопределенных значений
Название области работы	Nvchar	100	Not null
Детали	Nvchar	MAX

Tаблица 8. Сотрудники

Наименование атрибутов	Тип полей	Размер полей	Допустимость неопределенных значений
Id	bigint		Not Null
Фамилия	Nvchar	20
Имя	Nvchar	20
Oтчеcтво	Nvchar	20
Пол	Nvchar	3
Должность	Nvchar	50
Наименование атрибутов	Тип полей	Размер полей	Допустимость неопределенных значений
Название области работы	Nvchar	100	Not null
Детали	Nvchar	MAX

3.2.6 Запроcы к БД

Одним из наиболее эффективных и универсальных способов выборки данных из таблиц базы данных является использование запросов SQL.

В разработанной базе данных предусмотрены запросы, отвечающие всем указанным требованиям, как по виду, так и по их количеству. Ниже приведены примеры некоторых запросов всех необходимых видов.

Запросы на SQL: инфологический аутентификация реляционный

· Запрос на количество женщин в коллективе

Use Bank Select пол, count(пол) as [женщин в коллективе] From Сотрудники where пол = 'жен' group by Пол order by пол

· Запрос на добавление и выделение

USE Bank Insert into Помещения (Помещение, [Название помещения]) Values 025, 'Столовая') SELECT TOP (1000) [Помещение], [Название помещения] FROM [Bank].[dbo].[Помещения]

· Запрос на просмотр сотрудника и его области работы

Use Bank select * from Сотрудники join [Сотрудники и область их работы] on Сотрудники.id = [Сотрудники и область их работы].[Id сотрудника]

Размещено на Allbest.ru