Дипломная работа: Управление доступом к ресурсам баз данных Microsoft Structured Query Language 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. Фиксированные роли базы данных.

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