- •Определение основных терминов
- •Основные требования, предъявляемые к банкам данных
- •Компоненты банка данных
- •Пользователи бд и субд
- •Краткие итоги
- •Классификация баз данных
- •Классификация субд
- •Состав субд и работа бд
- •Основные функции субд
- •1. Непосредственное управление данными во внешней памяти
- •2. Управление буферами оперативной памяти
- •3. Управление транзакциями
- •4. Журнализация
- •5. Поддержка языков бд
- •Функциональные возможности субд
- •Краткие итоги
- •(Отношения и таблицы
- •(Понятия базы данных, системы баз данных, системы управления базами данных
- •Реляционные объекты данных
- •3.1. Централизованная архитектура
- •3.2. Технология с сетью и файловым сервером (архитектура "файл-сервер")
- •Технология "клиент – сервер"
- •3.4. Трехзвенная (многозвенная) архитектура "клиент – сервер".
- •Краткий обзор субд
- •3.5.1. Настольные субд
- •3.5.2. Серверные субд
- •Ms sql Server
- •Серверы баз данных компании ibm
- •(Логические и Физические Структуры базы данных
- •Базы данных, Табличные пространства и Файлы данных
- •Табличные пространства
- •Блоки данных
- •Экстенты
- •Сегменты
- •О командах ddl
- •Команды dml
- •(Журнализация изменений бд
- •Модели восстановления баз данных sql Server
- •(Типы резервного копирования
- •Методы резервного копирования
- •Среда sql Server Management Studio
- •Мастер планов обслуживания
- •(Платформа баз данных повышенной безопасности
- •Ценная возможность
- •Главные нововведения
- •Управление доступом. Общие сведения Авторизация и аутентификация
- •Схемы, не имеющие отношения к пользователям
Схемы, не имеющие отношения к пользователям
Вот уже не первый десяток лет принцип распределения прав доступа к объектам баз данных в большинстве серверных СУБД основан на наличии у каждого объекта базы данных пользователя-владельца, который может предоставлять другим пользователям права доступа к объектам базы данных. При этом набор объектов, принадлежащих одному и тому же пользователю, называется схемой. Данный способ владения объектами создавал определенные неудобства при сопровождении приложений, использующих базы данных. Так, при увольнении сотрудника, создавшего объекты, используемые многими пользователями, и удалении соответствующей учетной записи приходилось вносить изменения в серверный код (а нередко и в код клиентского приложения). Понимание возможности возникновения этих проблем привело к распространению небезопасных, но простых в применении способов управления учетными записями пользователей. Вплоть до хранения их имен и паролей в обычных таблицах, что резко повышало угрозу несанкционированного доступа к данным и приложениям.
В SQL Server 2005 концепция ролей расширена: эта СУБД позволяет полностью отделить пользователя от схем и объектов базы данных. Теперь объекты базы данных принадлежат не пользователю, а схеме, не имеющей никакого отношения ни к каким учетным записям и тем более к административным привилегиям. Таким образом, схема становится механизмом группировки объектов, упрощающим предоставление пользователям прав на доступ к объектам.
Рис. 2. Установка прав для схем данных
Роли
Для упрощения управления правами доступа в большинстве серверных СУБД применяется механизм ролей — наборов прав доступа к объектам базы данных, присваиваемых некоторой совокупности пользователей. При использовании ролей управление распределением прав доступа к объектам между пользователями, выполняющими одинаковые функции и применяющими одни и те же приложения, существенно упрощается: создание роли и однократное назначение ей соответствующих прав осуществляется намного быстрее, нежели определение прав доступа каждого пользователя к каждому объекту. SQL Server 2005 позволяет создавать так называемые вложенные роли, то есть присваивать одной роли другую со всеми ее правами. Это упрощает управление не только правами пользователей, но и самими ролями, создавая, к примеру, сходные между собой группы ролей.
SQL Server 2005 также поддерживает так называемые роли для приложений (application roles), которые могут использоваться для ограничения доступа к объектам базы данных в тех случаях, когда пользователи обращаются к данным с помощью конкретных приложений. В отличие от обычных ролей, роли для приложений, как правило, неактивны и не могут быть присвоены пользователям. Их применение оказывается удобным в том случае, когда требования безопасности едины для всех пользователей, при этом не требуется аудит или иная регистрация деятельности конкретных пользователей в базе данных.
)