
- •Хранимые процедуры Управление процессом компиляции хранимых процедур
- •Управление автоматическим выполнением хранимых процедур
- •Использование индексов
- •Планирование использования индексов
- •Создание индексов средствами t-sql
- •Использование курсоров
- •Динамические курсоры
- •Последовательные курсоры
- •Ключевые курсоры
- •Управление курсорами.
- •Работа с триггерами
- •Пример триггера
- •Система безопасности sql Server
- •Общие правила разграничения доступа
- •Аутентификация и интеграция с доменом Windows
- •Режим аутентификации Wondows
- •Режим аутентификации sql Server
- •Права доступа
- •Компоненты системы безопасности sql Server
- •Создание пользователей
- •Роли приложения
- •Защита данных в sql Server
- •Управление правами доступа к объектам базы данных средствами t-sql
- •Репликация данных
- •Понятие репликации данных
- •Издатель
- •Подписчик
- •Дистрибьютор
- •Механизмы репликации
Роли приложения
Система безопасности SQL Server реализована на самом низком уровне, на уровне базы данных. Это наилучший, наиболее действенный метод контроля деятельности пользователей независимо от приложений, используемый пользователями для подключения к SQL Server. Однако встречаются ситуации, когда необходимо использовать специальный набор прав для доступа к базе данных из приложения. Особенно это касается работы с большими базами данных, имеющими множество сложных взаимосвязанных таблиц с очень большим количеством записей. Чаще всего для работы с такими базами данных создаются специальные приложения. Кроме того, иногда необходимо, чтобы пользователи получали доступ к базе данных только с помощью определённого приложения и не имели возможности напрямую обращаться к данным, например, мобильные пользователи могут использовать специальную клиентскую программу, посредством которой они оперируют данными, устанавливая связь с сервером через незащищённые глобальные коммуникации.
SQL Server решает перечисленные проблемы путём использования роли приложения, создаваемой на уровне базы данных.
Отличие между стандартными ролями и ролью приложения следующие:
Пользователи SQL Server и Windows не могут быть добавлены в эту роль.
Роль активируется, когда приложение устанавливает соединение.
Пользователь, работающий с приложением, не является представителем роли приложения. Он просто использует установленное приложением соединение.
Перед использованием роли приложения необходимо сначала создать её. При создании роли приложения указывается её имя и пароль для доступа. Приложение может быть спроектировано так, чтобы работающий с ним пользователь должен был вводить пароль для активации роли приложения. Однако чаще всего пароль прописывается в самом приложении незаметно для пользователя. Дополнительно, для обеспечения максимальной безопасности пароль может быть зашифрован перед отправкой на SQL Server по сети. В процессе подключения приложение должно активировать роль, передав пароль, ассоциированный с данной ролью. Когда роль приложения активизируется, все права доступа, установленные в пределах сеанса для пользователя, групп и ролей теряются до окончания работы приложения. Соединение получает права, установленные для роли приложения в базе данных, в которой эта роль существует. Временное отключение прав доступа присвоенных установившему соединение пользователю используется для того, чтобы избежать конфликтов доступа. В противном случае, если пользователю запрещено чтение данных, а приложению необходимо прочитать данные, доступ был бы отключён, так как запрещение доступа имеет преимущество над предоставлением доступа.
Поскольку роль приложения имеет права только в той базе данных, в которой она создана, а все разрешения для учётной записи групп и ролей, к которым принадлежит пользователь, теряются, то доступ к другим базам данных возможен только под гостевым именем guest. Следовательно, если имя guest в базе данных не существует, то соединение не сможет получить доступ к данным. Если имя guest не удалено из базы данных, соединение сможет получить доступ к объектам базы данных только в том случае, если разрешения явно выданы для пользователя guest.
Перед установлением соединения с использованием роли приложения, пользователю сначала нужно получить доступ к SQL Server, а для этого можно использовать любой из режимов аутентификации пользователя. Если приложение спроектировано для выполнения различных задач с использованием разных прав доступа, необходимо создать отдельную роль для каждой выполняемой задачи. А приложение в свою очередь должно позаботиться о переключении ролей при переключении задач.