Главная » Microsoft SQL Server, Базы данных » Концепции защиты

0

Модель защиты SQL Server большая и сложная. В некотором роде она даже более сложная, чем в Windows. Так как концепции защиты тесно переплетены между собой, лучше начать их рассмотрение с общего обзора модели.

Система безопасности SQL Server основана на концепции защищаемых объектов (securables), т.е. объектов, на которые можно назначать разрешения, и принципалов (principles), т.е. объектов, которым можно назначать разрешения. Принципалами могут быть пользователи и роли. Пользователи назначаются ролям; при этом как пользователям, так и ролям могут предоставляться разрешения на доступ к объектам (рис. 40.1) Каждый объект имеет своего владельца, и права собственности также влияют на разрешения.

Система безопасности уровня сервера

Пользователь в первую очередь должен быть идентифицирован сервером одним из следующих методов:

?               с помощью учетной записи пользователя Windows;

?               на основе членства в одной из групп пользователей Windows;

?               с помощью отдельной регистрационной записи SQL Server (если на сервере используется смешанная модель безопасности).

На уровне сервера пользователь распознается по своему идентификатору (LoginlD), который может быть либо регистрационной записью SQL Server, либо именем домена и пользователя Windows.

Рис. 40.1. Обобщенная схема системы безопасности SQL Server. Показано, как пользователи вначале аутентифицируются сервером, затем базой данных и объектами базы данных. В кружках представлены элементы идентификации пользователя

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

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

Система безопасности уровня базы данных

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

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

Разрешения к объектам назначаются с помощью инструкций GRANT (предоставить), REVOKE (отозвать) и DENY (запретить). Запрет привилегии замещает собой ее предоставление, а предоставление привилегии замещает собой ее отзыв. Пользователю может быть предоставлено множество разрешений к объекту (индивидуальных, наследованных от роли, обеспеченных принадлежностью к роли public). Если какая-либо из этих привилегий запрещена, для пользователя блокируется доступ к объекту. В противном случае, если какая- либо из привилегий предоставляет разрешение, пользователь получает доступ к объекту.

Разрешения объекта достаточно детализированы; существуют отдельные разрешения для каждого из возможных действий (SELECT, INSERT, UPDATE, RUN и т.д.) над объектом. Некоторые фиксированные роли базы данных также влияют на доступ к объекту, например, управляя возможностью считывать информацию и записывать ее в базу данных.

Вполне возможна ситуация, когда пользователь был распознан в SQL Server, но у него нет доступа ни к одной из его баз данных. Также возможно и обратное: пользователю открыт доступ к базам данных, но он не был распознан сервером. Перемещение базы данных и ее разрешений на другой сервер без параллельного перемещения регистрационных записей сервера может привести к возникновению таких “осиротевших” пользователей.

Права собственности на объект

Заключительным аспектом в этом обзоре модели безопасности SQL Server является право собственности на объект. Владельцем любого объекта является схема. Схемой по умолчанию является dbo, которую не следует путать с ролью dbo.

В предыдущих версиях владельцами объектов являлись пользователи (точнее, Новинка ^ владелец сам представлял собой схему). По сравнению с этим модель SQL 2005 d     Server 2005 в виде база данных-схема-объекты имеет целый ряд преимуществ.

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

Большая часть операций управления системой безопасности выполняется в утилите Management Studio. В программном коде управление системой безопасности выполняется с помощью инструкций DDL GRANT, REVOKE и DENY, а также нескольких хранимых процедур.

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

По теме:

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