Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Лаб админ инф сист2.doc
Скачиваний:
12
Добавлен:
26.03.2015
Размер:
2.05 Mб
Скачать

Пользовательские роли базы данных

Если фиксированные роли предназначены для наделения пользователей специальными правами в базе данных, то пользовательские роли служат лишь для группировки пользователей с целью облегчения управления их правами доступа к объектам. Если в базе данных существуют пользователи, которым необходимы одинаковые права доступа, то лучше объединить их в единую административную единицу, чем управлять каждым из них по отдельности. Если сотрудник переходит в другой отдел, то достаточно исключить его из одной роли и добавить и другую, а не просматривать все объекты базы данных и корректировать права доступа пользователя к ним. Пользовательские роли в SQL Server 2000 можно сравнить с группами SQL Server 6.x и группами Windows NT

Рис. 3.3. Папка Roles

Список ролей базы данных можно просмотреть в папке Roles (рис. 3.3) базы данных средствами Enterprise Manager. Информация о ролях базы данных отображается в двух столбцах:

Name - имя роли

Role Type - типроли. Допускаются типы Standard (стандартная роль) и Application (роль приложения)

Для создания новой пользовательской роли средствами Enterprise Manager нужно в контекстном меню папки Roles выбрать команду New Database Role. В открывшемся диалоговом окне Database Role Properties- New Role (рис. 9.1З) в поле Name необходимо указать имя роли, уникальное в пределах базы данных. С помощью переключателей группы Database role type необходимо выбрать тип создаваемой роли. Если установлен переключатель Standard role, с помощью кнопки Add можно сразу же добавить нужных пользователей в создаваемую роль. Выбрав переключатель Application role, необходимо указать пароль, с помощью которого будет инициализироваться роль.

Рис. 3.4. Окно создания новой роли

Роли приложения

Если с базой данных работают сотни и тысячи пользователей, то управление их правами доступа к объектам БД становиться большой проблемой. Стандартные роли базы не всегда могут снять проблему. В этом случае SQL Server 2000 предлагает обратиться к роли приложения (application role). Даже для работы с большими базами данных, содержащими миллионы записей, к которым обращаются сотни пользователей, бывает достаточно ограниченного набора программных продуктов из двух-трех приложений. Роли приложения в SQL Server 2000 позволяют выдавать права доступа не конкретному пользователю или их группе, а приложению в целом. При этом не важно, какой именно пользователь работает с приложением, и какие права доступа к базе данных он имеет. Получив доступ к приложению, пользователь может выполнять все действия, разрешенные роли приложения. Упрощая управление правами доступа пользователей к базам данных, администратор перекладывает контроль за работой пользователей не на систему безопасности SQL Server 2000, а на возможности самого приложения.

Создание роли приложения с помощью Enterprise Manager было описано в предыдущем подразделе. Роль приложения не содержит членов. Пользователь, работающий с приложением, не является членом роли приложения. Он лишь использует возможности приложения. При конфигурировании роли приложения следует указать только ее имя и пароль, необходимые приложению при установлении соединения. Данный пароль приложение может вводить само, но может и требовать его ввода у пользователя. Конкретная реализация зависит от разработчика приложения. Безопасность при отправке пароля роли приложения по сети можно обеспечить шифрованием. Сначала пользователь должен установить соединение с сервером. Для этого необходимо предварительно создать для него учетную запись SQL Server или предоставить учетной записи пользователя в домене Windows NT доступ к SQL Server 2000. Учетная запись пользователя может отображаться в пользователя базы данных, имеющего определенные права доступа (или запрещение доступа). После того как пользователь получил доступ к серверу, он может начинать работу с программой. Программа активизирует роль приложения выполнением специальной хранимой процедуры, в которой указывается имя роли и ее пароль. Если введены верные данные, то SQL Server 2000 предоставляет приложению соответствующие права. Права доступа, полученные через роль приложения, могут конфликтовать с правами доступа пользователя, работающего с приложением. Чтобы этого не происходило, система безопасности SQL Server 2000 аннулирует все права в текущем сеансе соединения, выданные учетной записи, пользователю базы данных или любой из ролей. Происходит как бы потеря информации о личности пользователя. Такой подход позволяет со стопроцентной гарантией избежать конфликтов доступа и обеспечить приложение правами доступа, независимыми от пользователя, работающего с приложением. После завершения работы приложения права доступа пользователя восстанавливаются. Если пользователь одновременно открыл несколько сеансов, то права доступа будут потеряны только в соединении, из которого была инициализирована роль. В других сеансах он будет иметь обычные права доступа. Поскольку в соединении, в котором была инициирована роль приложения, теряется вся информация о личности пользователя, то пропадает и возможность установления соединения с серверами и базами данных с правами, выданными работающему с приложением пользователю. Если во внешней базе данных удален пользователь guest, то получение доступа к данным невозможно. Чтобы предоставить приложению возможность работы с данными во внешних базах данных, необходимо создать в этих базах пользователя guest. Приложение будет иметь права доступа, выданные пользователю guest непосредственно или как члену роли public. Чтобы приложение имело различные права доступа к базе данных, требуется создать отдельную роль для каждой задачи и наделить ее необходимыми правами. Кроме того, если приложению нужен доступ к различным базам данных, и администратор не желает прибегать к созданию пользователя guest, то также следует создать отдельную роль приложения для каждой базы данных. Приложение само должно заботиться о переключении ролей.