Управление пользователями в среде MS SQL Server

Управление пользователями в среде MS SQL Server

Рассмотрим вопрос создания пользователей в среде MS SQL Server.

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

В системе SQL-сервер организована двухуровневая настройка ограничения  доступа к данным. На первом уровне необходимо создать так называемую учетную запись пользователя (login), что позволяет ему подключиться к самому серверу, но не дает автоматического доступа к базам данных. На втором уровне для каждой базы данных SQL-сервера на основании учетной записи необходимо создать запись пользователя. На основе прав, выданных пользователю как пользователю базы данных (user), его регистрационное имя (login) получает доступ к соответствующей базе данных. В разных базах данных login одного и того же пользователя может иметь одинаковые или разные имена user с разными правами доступа. Иначе говоря, с помощью учетной записи пользователя осуществляется подключение к SQL-серверу, после чего определяются его уровни доступа для каждой базы данных в отдельности.

В системе SQL-сервер существуют дополнительные объекты – роли, которые определяют уровень доступа  к объектам SQL-сервера. Они разделены  на две группы: назначаемые для  учетных записей пользователя сервера  и используемые для ограничения  доступа к объектам базы данных.

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

• аутентификация ;
• учетная запись ;
• встроенные роли сервера.

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

• пользователь базы данных;
• фиксированная роль базы данных;
• пользовательская роль базы данных.

Режимы аутентификации

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

• режим аутентификации средствами Windows NT/2000;
• смешанный режим аутентификации (Windows NT Authentication and SQL Server Authentication).

Администрирование системы безопасности

Для создания пользователя в среде MS SQL Server следует предпринять следующие шаги:

1. Создать в базе данных учетную запись пользователя, указав для него пароль и принятое по умолчанию имя базы данных (процедура sp_addlogin ).
2. Добавить этого пользователя во все необходимые базы данных (процедура sp_adduser ).
3. Предоставить ему в каждой базе данных соответствующие привилегии (команда GRANT ) .

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

sp_addlogin

[@login=] 'учетная_запись'

[, [@password=] 'пароль']

[, [@defdb=] 'база_данных_по_умолчанию']

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

sp_adduser

[@loginame=] 'учетная_запись'

[, [@name_in_db=] 'имя_пользователя']

[, [@grpname=] 'имя_роли']

Отобразить учетную запись Windows NT в имя пользователя позволяет хранимая процедура:

sp_grantdbaccess

[@login=] ‘учетная_запись’

[, [@name_in_db=]‘имя_пользователя’]

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

Владелец объекта не имеет  специального пароля или особых прав доступа. Он неявно имеет полный доступ, но должен явно предоставить доступ другим пользователям.

SQL Server позволяет передавать права владения от одного пользователя другому с помощью процедуры:

sp_changeobjectowner

[@objname=] ‘имя_объекта’

[@newowner=] ‘имя_владельца’

Роль позволяет объединить в одну группу пользователей, выполняющих  одинаковые функции.

В SQL Server реализовано два вида стандартных ролей: на уровне сервера и на уровне баз данных. При установке SQL Server создаются фиксированные роли сервера (например, sysadmin с правом выполнения любых функций SQL-сервера) и фиксированные роли базы данных (например, db_owner с правом полного доступа к базе данных или db_accessadmin с правом добавления и удаления пользователей ). Среди фиксированных ролей базы данных существует роль public, которая имеет специальное назначение, поскольку ее членами являются все пользователи, имеющие доступ к базе данных.

Можно включить любую учетную  запись SQL Server (login) или учетную запись Windows NT в любую роль сервера.

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

В роль базы данных можно  включить пользователей SQL Server, роли SQL Server, пользователей Windows NT.

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

• создание новой роли:
• sp_addrole
• [@rolename=] 'имя_роли'

[, [@ownername=] 'имя_владельца']

• добавление пользователя к роли:
• sp_addrolemember
• [@rolename=] 'имя_роли',

[@membername=] 'имя_пользователя'

• удаление пользователя из роли:
• sp_droprolemember
• [@rolename=] 'имя_роли',

[@membername=] 'имя_пользователя'

• удаление роли:
• sp_droprole

[@rolename=] 'имя_роли'

Управление доступом к данным

Определение привилегий в стандарте языка

Каждая СУБД должна поддерживать механизм, гарантирующий, что доступ к базе данных смогут получить только те пользователи, которые имеют соответствующее  разрешение. Язык SQL включает операторы GRANT и REVOKE, предназначенные для организации  защиты таблиц в базе данных. Механизм защиты построен на использовании идентификаторов  пользователей, предоставляемых им прав владения и привилегий.

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

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

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

• SELECT – право выбирать данные из таблицы;
• INSERT – право вставлять в таблицу новые строки;
• UPDATE – право изменять данные в таблице;
• DELETE – право удалять строки из таблицы;
• REFERENCES – право ссылаться на столбцы указанной таблицы в описаниях требований поддержки целостности данных;
• USAGE – право использовать домены, проверки и наборы символов.

Привилегии INSERT и UPDATE могут  ограничиваться лишь отдельными столбцами  таблицы, в этом случае пользователю разрешается модифицировать значения только указанных столбцов. Аналогичным  образом привилегия REFERENCES может  распространяться исключительно на отдельные столбцы таблицы, что  позволит использовать их имена в  формулировках требований защиты целостности  данных – например, в предложениях CHECK и FOREIGN KEY, входящих в определение  других таблиц, тогда как применение для подобных целей остальных  столбцов будет запрещено.

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

Создавая представление  с помощью оператора CREATE VIEW, пользователь автоматически становится владельцем этого представления и также  получает полный набор прав. Для  создания представления пользователю достаточно иметь привилегию SELECT для  всех входящих в него таблиц и привилегию REFERENCES для всех столбцов, упоминаемых  в определении этого представления. Привилегии INSERT, UPDATE и DELETE в отношении  созданного представления пользователь получит только в том случае, если имеет соответствующие привилегии в отношении всех используемых в  представлении таблиц.

Предоставление  привилегий пользователям

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

<предоставление_привилегий>::=

GRANT {<привилегия>[,...n] |

    ALL PRIVILEGES}

ON имя_объекта

TO {<идентификатор_пользователя>

    [,...n]| PUBLIC}

[ WITH GRANT OPTION]

Параметр <привилегия> представляет собой:

<привилегия>::=

{SELECT | DELETE | INSERT

    [(имя_столбца[,...n])]

| UPDATE [(имя_столбца[,...n])]}

| REFERENCES [(имя_столбца[,...n])] |

    USAGE }

Из соображений упрощения  в операторе GRANT можно указать  ключевое слово ALL PRIVILEGES, что позволит предоставить указанному пользователю все существующие привилегии без  необходимости их перечисления. Кроме  того, в этом операторе может указываться  ключевое слово PUBLIC, означающее предоставление доступа указанного типа не только всем существующим пользователям, но также  и всем тем, кто будет определен  в базе данных впоследствии.

Параметр имя_объекта может использоваться как имя таблицы базы данных, представления, домена, набора символов, проверки.

Благодаря параметру WITH GRANT OPTION, указанные в операторе GRANT пользователи имеют право передавать все предоставленные  им в отношении указанного объекта  привилегии другим пользователям, которые, в свою очередь, будут наделены точно  таким же правом передачи своих полномочий. Если данный параметр не будет указан, получатель привилегии не сможет передать свои права другим пользователям. Таким  образом, владелец объекта может  четко контролировать, кто получил  право доступа к объекту и  какие полномочия ему предоставлены.

Отмена предоставленных  пользователям привилегий

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

<отмена_привилегий>::=

REVOKE[GRANT OPTION FOR]

    {<привилегия>[,...n]

    | ALL PRIVILEGES}

ON имя_объекта

FROM {<идентификатор_пользователя>

    [,...n]| PUBLIC}

[RESTRICT | CASCADE]

Ключевое слово ALL PRIVILEGES означает, что для указанного пользователя отменяются все привилегии, предоставленные  ему ранее тем пользователем, который ввел данный оператор. Необязательная фраза GRANT OPTION FOR позволяет для всех привилегий, переданных в исходном операторе GRANT фразой WITH GRANT OPTION, отменять возможность их передачи независимо от самих привилегий.

Если в операторе указано  ключевое слово RESTRICT, успешное выполнение команды REVOKE возможно лишь в том  случае, когда перечисленные в  операторе привилегии не могут послужить причиной появления у каких-либо других пользователей так называемых "оставленных" привилегий. С помощью параметра CASCADE удаляются все привилегии, которые иначе могли бы остаться у других пользователей.

"Оставленными" являются  привилегии, сохранившиеся у пользователя, которому они в свое время  были предоставлены с помощью  параметра GRANT OPTION.

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

Привилегии, которые были предоставлены указанному пользователю другими пользователями, не могут  быть затронуты оператором REVOKE. Следовательно, если другой пользователь также предоставил  данному пользователю удаляемую  привилегию, то право доступа к  соответствующей таблице у указанного пользователя сохранится. Например, пусть  пользователь A и пользователь Е имели право INSERT на таблицу Товар. Пользователь А предоставил пользователю B привилегию INSERT для таблицы Товар, причем с указанием WITH GRANT OPTION (этап 1). Пользователь B передал эту привилегию пользователю C (этап 2). Затем пользователь C получил ее же от пользователя E (этап 3). Далее пользователь C предоставил упомянутую привилегию пользователю D (этап 4). Когда пользователь A отменяет привилегию INSERT для пользователя B, она не может быть отменена и для пользователя C, поскольку ранее он уже получил ее от пользователя E. Если бы пользователь E не предоставил данной привилегии пользователю C, то удаление привилегии пользователя B имело бы следствием каскадное удаление привилегий для пользователей C и D