Главная » Microsoft SQL Server, Базы данных » Безопасность объектов

0

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

Разрешения уровня объекта

Разрешения к объекту назначаются с помощью инструкций SQL DCL GRANT, REVOKE и DENY. Эти инструкции имеют свою иерархию: DENY имеет превосходство над GRANT, которая, в свою очередь, имеет превосходство над REVOKE, т.е. инструкция GRANT разрешает доступ к объекту, если он не отменен инструкцией DENY.

Существует несколько особых типов разрешений.

?               Разрешение на отбор данных. Эти разрешения могут применяться к отдельным столбцам.

?               Разрешение на вставку данных.

?               Разрешение на обновление данных. Право на изменение существующих данных требует наличия права на их отбор. Разрешения на обновление можно устанавливать на уровне отдельных столбцов.

?               Право на удаление существующих данных.

?               Право на создание внешних ключей, использующих DRI.

Разрешения на уровне объектов применяются с помощью трех инструкций DCL: GRANT, REVOKE и DENY. Независимо от того, откуда будут управляться разрешения, из интерфейса Management Studio или из программного кода, важно четко понимать особенности и взаимосвязь этих трех инструкций.

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

1.              Серверная роль sysadmin.

2.              Запрещение доступа к объекту,

или роль базы данных db_denydatareader, или роль базы данных db_denydatawriter.

3.              Разрешение доступа к объекту,

или права собственности над объектом, или роль базы данных db_datareader, или роль базы данных db_datawriter.

4.              Отзыв разрешений для объекта.

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

Если в среде, в которой вы работаете, запрещено использование совместного режима, для проверки системы безопасности щелкните правой кнопкой мыши в меню Пуск на ярлыках утилиты Management Studio или Query Analyzer, выберите в контекстном меню команду Run As и укажите имя пользователя, от имени которого вы собираетесь запустить утилиту. Однако учтите, что это влечет за собой создание подставных пользователей в домене Windows.

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

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

GRANT разрешение, разрешение ON объект

ТО пользователь/роль, пользователь/роль WITH GRANT OPTION

Разрешение может быть одним из следующих ключевых слов: ALL, SELECT, INSERT, DELETE, REFERENCES, UPDATE и EXECUTE. Роль и пользователь указывают на имя пользователя базы данных, на пользовательскую или стандартную публичную роль. В следующем примере пользователю Den предоставляется разрешение на выборку значений из таблицы Person:

GRANT Select ON Person TO Den

В следующем примере для роли public открываются все разрешения к таблице Marriage: GRANT All ON Marriage TO Public

В одной инструкции может быть перечислено несколько имен пользователей и/или ролей, а также множество разрешений к объекту. В следующем примере пользователям guest и LRN предоставляется разрешение на отбор и обновление значений из таблицы Person: GRANT Select, Update ON Person to Guest, LRN

Параметр WITH GRANT OPTION позволяет указанным в инструкции GRANT пользователям передавать свои полномочия другим пользователям. Например, в следующей инструкции пользователю Joe предоставляются разрешения выборки значений из таблицы Person, которое он может передавать остальным пользователям.

Параметр WITH GRANT OPTION может быть использован только в программном коде — в среде Management Studio он недоступен.

Отзыв прав и запрет доступа к объекту в программном коде

Инструкции отзыва и запрета прав доступа к объекту используют в основном тот же синтаксис, что и предоставление прав. В следующем примере право выборки данных из таблицы Marriage отзывается у пользователя Den:

REVOKE Select ON Marriage TO Den

Если разрешения предоставлялись с параметром WITH GRANT OPTION, то они должны отзываться и запрещаться с параметром CASCADE, чтобы операция была применена и ко всем пользователям, которым были делегированы права данным пользователем. В следующем примере запрещается доступ к таблице Person пользователю Joe, а также всем, кому он сам предоставил разрешения.

Стандартные роли базы данных

Стандартные роли базы данных иногда называют пользовательскими. Они могут быть созданы любым пользователем сервера, имеющим серверную роль sysadmin или роли базы данных db_owner или security admins. Эти роли функционально идентичны группам пользователей в операционной системе Windows. Стандартной роли могут быть предоставлены разрешения и принадлежности другим ролям, и этой роли могут принадлежать пользователи.

Самый “прозрачный” план защиты SQL Server предполагает назначение разрешений к объектам и фиксированных ролей стандартной роли и последующее назначение стандартной роли пользователей.

РОЛЬ public

Роль public является фиксированной, однако, подобно стандартной роли, ей можно назначать разрешения к объектам. Каждый пользователь автоматически становится членом роли public, и эту связь невозможно удалить. Таким образом, роль public служит своеобразным мерилом минимально допустимых разрешений.

При назначении разрешений роли public будьте особо осторожны, поскольку Внимание! они будут применены ко всем пользователям, за исключением тех, кто принадлежит серверной роли sysadmin. Предоставление прав скажется на всех пользователях, однако более важно то, что на них скажутся и запреты доступа, примененные к роли public (как мы уже говорили, это не касается роли sysadmin), — в том числе и на владельцах самих этих объектов.

Управление ролями в программном коде

Создание стандартных ролей в программном коде предполагает использование системной хранимой процедуры sp_addrole. Имя роли может состоять не более чем из 128 символов, не может включать в себя обратную косую черту, не может быть пустой строкой или пустым значением. По умолчанию роли принадлежат пользователю dbo, в то же время владельца роли можно определить явно во втором параметре хранимой процедуры. В следующем примере создается роль manager:

ЕХЕС sp_addrole ‘Manager’

Вот результат:

New role added.

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

ЕХЕС sp_droprole ‘Manager’

Вот результат:

Role dropped.

После создания роли она может быть назначена пользователям с помощью хранимой процедуры sp_addrolemember. В следующем примере роль manager назначается пользователю Den:

ЕХЕС sp_addrolemember ‘Manager’, Den

Вот результат:

‘Joe’ added to role ‘Manager’.

Аналогично системная хранимая процедура sp_droprolemember удаляет назначение пользователя некоторой роли. В следующей команде пользователь Den будет освобожден от роли manager:

ЕХЕС sp_droprolemember ‘Manager’, Den

Вот результат:

‘Joe’ dropped from the role ‘Manager’.

Иерархическая структура ролей

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

?               Рабочий может иметь ограниченный доступ.

?               Управляющий может иметь все права рабочего плюс некоторые права к таблицам классификаторов.

?               Администратор может иметь все права управляющего плюс право на выполнение задач администрирования базы данных.

Для создания структуры такого типа выполните следующие действия.

1.              Создайте роль рабочего и предоставьте ей разрешения.

2.              Создайте роль управляющего и добавьте ее как пользователя роли рабочего. Предоставьте роли управляющего дополнительные разрешения.

3.              Создайте роль администратора и добавьте ее как пользователя роли управляющего. Предоставьте роли управляющего дополнительные фиксированные серверные роли.

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

и Management Studio

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

Управление из списка объектов

Для изменения разрешений объекта выполните следующие действия.

1.              Щелкните правой кнопкой мыши на имени объекта в соответствующем узле (tables, views и т.п.) окна Object Browser и выберите в контекстном меню пункт Properties. Откроется диалоговое окно параметров этого типа объектов.

2.              Щелкните на кнопке Permissions, чтобы открыть диалоговое окно разрешений объекта.

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

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

Управление из списка пользователей

В списке пользователей базы данных утилиты Management Studio дважды щелкните на имени пользователя или щелкните на нем правой кнопкой и выберите в контекстном меню пункт Properties. Открывшееся диалоговое окно Database User Properties служит для назначения пользователей ролям.

Щелкните на кнопке Properties, чтобы открыть диалоговое окно параметров выбранной роли.

Если теперь щелкнуть на кнопке Permissions, откроется вкладка Permissions диалогового окна Database User Properties. Эта вкладка сходна с одноименной вкладкой диалогового окна Database Object Properties.

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

Управление из списка ролей

Разрешениями объектов можно также управлять и из списка ролей. Для открытия диалогового окна Database Role Properties дважды щелкните на роли или щелкните на ней правой кнопкой мыши и выберите в контекстном меною пункт Properties. Это диалоговое окно используется для назначения роли пользователей и других ролей, а также для удаления их из роли.

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

Цепочки принадлежности

В базах данных SQL Server пользователи часто получают доступ к данным, проходя через несколько объектов. Цепочки принадлежности применимы к представлениям, хранимым процедурам и пользовательским функциям. Например:

?               в Visual Basic программа может вызывать хранимую процедуру, которая извлекает данные из таблицы;

?               отчет может отбирать данные из представления, которое, в свою очередь, основано на некоторой таблице;

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

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

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

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

Если цепочка принадлежности разорвана (т.е. в ней появляется другой владелец объекта), SQL Server проверяет наличие разрешений к каждому из объектов, к которому осуществляется доступ.

Приведем примеры.

?               Цепочка принадлежности от dbo .А к dbo. В и далее к dbo. Person не разорвана. В этом случае dbo. А может вызвать dbo. В и таким образом получить доступ к dbo. Person как dbo.

?               Цепочка принадлежности от dbo. А к Sue . С и далее к Joe . Purchase разорвана, поскольку в ней присутствует несколько разных владельцев объектов. В этом случае dbo .А вызывает Sue. С, используя разрешения Joe, и Sue. С обращается к данным Joe . Purchase, также используя разрешения Joe.

?               Цепочка принадлежности от dbo. А к dbo. В и далее к Joe . Person также разорвана. Таким образом, dbo. А вызывает dbo. В с использованием разрешений dbo, но dbo. В может получить доступ к Joe. С только с помощью разрешений Joe.

Пример простой модели защиты

За примерами организации разрешений обратимся к учебной базе данных OBXKites. В табл. 40.1 представлены разрешения для стандартных ролей базы данных, а в табл. 40.2 — список некоторых пользователей этих ролей.

Таблица 40.1. Роли базы данных OBXKites

Стандартная

роль

Иерархическая Таблицы пер- Таблицы ста- структура ролей вичной файло- тичной файловой группы вой группы

Прочие разрешения

IT

Серверная роль — — sysadmin

Clerc

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

Admin

Фиксированная — —

роль базы данных

db_owner

Public

— Разрешения от- — бора данных

Таблица 40.2. Пользователи базы данных OBXKites

Пользователь

Стандартная роль базы данных

Sammy

Admin

Joe

LRN

IT

Группа Windows Clerc (пользователи Betty, Tom, Martha И Mary)

Clerc

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

?               Betty как член группы Clerc может выполнять приложение VB, выполняющее хранимые процедуры, извлекающие и обновляющие данные. Поскольку Betty является членом роли Public, он может выполнять запросы извлечения данных.

?               LRN как администратор и член группы IT может выполнять все задачи в базе данных, поскольку он принадлежит к фиксированной серверной роли sysadmin.

?               Joe как член роли Public может выполнять запросы извлечения данных.

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

?               Sammy может выполнять резервные копирования, но только LRN имеет право восстанавливать базу данных из архивов.

Источник: Нильсен, Пол. Microsoft SQL Server 2005. Библия пользователя. : Пер. с англ. — М. : ООО “И.Д. Вильямс”, 2008. — 1232 с. : ил. — Парал. тит. англ.

По теме:

  • Комментарии