Требования к системе безопасности

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

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

База содержит таблицу со сведениями о работниках таблицу с категориями

зарплат aries) и адресами (Lo ns). Работники обращаются к таблице Employees и мании о расположении офисов в таблице Locations. Таблица Salaries и домашние адреса из Locations доступны лишь небольшой группе - им разрешено добав-

лять, удалять и модифицировать эти данные. Еще один пользователь отвечает за создание

Занятие 2 Планирование безопасности баз данных

Теперь, когда вы имеете представление об архитектуре системы БД, мы

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

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

как правило, наблюдают за проектированием всей системы безопасности. В этом занятии рассказано, как создать план системы безопасности БД и как архитектура системы безопасности связана с разработкой эффективного плана.

Изучив материал этог ия, вы сможете:

вывести из системных требования к системе безопасности БД;

v спроектировать систему безопасности для БД SQL Server 2000;

решить, какие привилегии пользователям, а какие - группам и ролям;

рассказать о назначении владения и формировании иерархии системы

безопасности путем использования вложенных групп и ролей.

Продолжительность занятии - около 25 минут.

занятие 2 Планирование безопасности бзз данных 391

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

Для этого простого примера можно сформулировать следующие требования к системе

безопасности БД:

всем работникам разрешено исполнять операторы SELECT в таблице Employees;

всем работникам разрешено исполнять операторы SELECT иис Locations для извлечения сведений о местонахождения офиса;

небольшая группа работников может исполнять операторы INSERT, DELETE, и UPDATE на всех каждой из трех

мвателк) выполняющему каждую ночь резервное копирование и общее администрирование БД, необходим полный доступ к серверу;

некоторая группа пользователей исполняет операторы CREATE и DROR Также составим список пользователей, имеющих доступ к этой БД:

все работники входят в класс пользователей, представленный ролью Public на уровне БД;

членам группы Human Resources необходим ограниченный доступ к БД;

учетное имя JDoe принадлежи i раюру БД;

разработчики БД компании создают и удаляют объекты в SQL Server.

На основе предоставленной информации создается список соответствий пользователь -

действие .

Учетная запись, группа или роль Вид действий

Public Доступ только чтения

к таблице Employees

Public (роль) Доступ только чтения к столбцам со сведениями

о местонахождения офиса uiut: Location

DOMAlN01\HumanResources Полный доступ к таблицам Employees, Location

(группа) и Salaries

DOMAIN01\Jdoe Полный доступ к БД

DOMAIN01\dbDev Создание БД

Дополнительные примеры планирования системы безопасности приводятся в разделе Planning Security в SQL Server Boolts Online, a также в упражнении к этому занятию.

Вложенные роли и цепочки владения

Существует множество способов реализации системы безопасности в SQL Server. От разработчика требуется обеспечить максимальную эффективность при реализации системы безопасности, но не за счет снижения уровня безопасности. Например, если НИ пользователям требуется одинаковый уровень доступа к БД, рациональнее всего использовать группы и роли, а не конфигурировать систему безопасности для каждого пользователя в Оба способа дают одинаковые результаты, но группы и роли легче сопровождать, кроме того, этот способ быстрее ствить. Вложенные ли. цепочки владения и предопределенные роли позволяют сконструировать рациональный план системы безопасности.

392 Система безопасности SQL Server 2000 Вложенные группы

Использование вложенных ролей и групп позволяет избежать лишней работы по назначению разрешений. Например, разрешение SELECT для таблиц, доступных всем прошедшим аутентификацию пользователям, следует назначить роли Public. Разрешения на работу с защищаемыми объектами и на выполнение операторов в этом случае лучше назначить группе (GroupOl в этом примерз). Затем следует назначить специальные разрешения отдельным пользователям или меньшей группе (SpecialGroupOl). Все пользователи, группы (в том числе GroupOl ЮюирО!) и роли являются членами роли Public. Группа SpecialGroupOl входит в группу GrojpOl, поэтому SpecialGroupOl наследует разрешения. назначенные для GroupOl, а члены SpecialGroupOl наследуют специальные разрешения, назначенные для этой группы.

Стандартные домены Windows 2000 также поддерживают вложенные группы.

Цепочки владения

Членство в предопределенных ролях и владение объектами предполагает наличие ряда привилетий. Нредполатаемые pa3peinenH!-i позволяют минимизировать ручную работу по назначению привилегий, необходимую для выполнения требований к системе безопасности. Согласованное владение объектами и формирование цепочек владения также эффективно ограничивают объем и консолидацию назначаемых разрешений. Когда набор вложенных объектов и исходный объект принадлежат одному и тому же пользователю и располагаются в одной и той же БД, говорят о создании цепочки и.тдсиип (ownership chain). Если у пользователей БД есть хотя бы разрешение на работу с вызывающим объектом (хранимой процедурой или представлением), то по цепочке они смогут

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

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

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

вызываемые объекты принадлежат тому же владельцу, что и вызывающий объект, формируется цепочка владения. Владельцем всех объектов, созданных хранимой процедурой, является владелец процедуры, а не запустивший ее. Цепочки владения можно применять лишь к операторам SELECT, INSERT, UPDATE и DELETE.

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

требуют одинаковых разрешений).

Если из-за несогласованности объектами цепочка не сформирована,

Server проверяет разрешения для объекта в цепочке, у которого следующая связь

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