Дипломная работа: Управление доступом к ресурсам баз данных Microsoft Structured Query Language Server

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

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. Список фиксированных ролей сервера.

Для добавления учетной записи пользователя в ту или иную фиксированную роль сервера можно воспользоваться хранимой процедурой 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, пароль и другая информация. При попытке пользователя подключиться к серверу система безопасности потребует ввести имя учетной записи и ее пароль. Затем система сравнивает введенные данные с информацией, хранящейся в системных таблицах. Если данные совпадают, то доступ предоставляется. В противном случае пользователь получает сообщение об ошибке, и соединение не устанавливается.