4. Права доступа. Управление правами доступа

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

Право доступа косвенно предоставляется владельцу или создателю объекта. Владелец объекта может затем сам принимать решение о предоставлении прав доступа другим пользователям или группам, как он считает нужным. Существует несколько ти­пов прав доступа к объектам базы данных:

• Право на выполнение инструкций SQL (statement permission) — определяет набор прав пользователя на выполне­ние выражений, например, на соз­дание базы данных.

• Право на работу с объектами (object permission) — определяет набор прав пользователя при работе с данными или выполнении хранимых процедур.

• Предопределенные права (predefined permission) — определяют набор дейст­вий, которые разрешено выполнять только пользователям, включенным в определенные стандартные роли, или владельцам объектов базы данных.

Право на выполнение выражений: Предположим, что нам надо создать базу данных. Для этого необходимо выполнить инструкцию CREATE DATA­BASE, даже если мы используем для этой целиSQLServerEn­terpriseManager. Система безопасностиSQLServerпредостав­ляет возможность запретить пользователям, не являющимся чле­нами ролейsysadmin, db_owner или db_ddladmin, выполнять такого рода ин­струкции, к которым относятся:

CREATE DATABASE CREATE DEFAULT CREATE

PROCEDURE CREATE RULE

CREATE TABLE CREATE VIEW BACKUP DATA­BASSE BACKUP LOG.

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

SP_CHANGEOBJECTOWNER объект, владелец.

Но в большинстве случаев это крайняя мера, свидетельст­вующая о том, что недостаточно четко продумана система безо­пасности. И лучше все-таки из­менить именно систему.

Право доступа к объектам (object permission) имеет отно­шение к таблицам и другим объектам базы данных, таким как хранимые процедуры и представ­ления.

Ниже приведен список и описание прав доступа к табли­цам:

• SELECT — дает возможность пользователю вы­брать или прочесть данные из таблицы или представления. Сле­дует заметить, что право доступа SELECT может быть предос­тавлено к индивидуальным столбцам, а не только ко всей таблице или представлению.

• INSERT — дает возможность пользователю доба­вить новые данные в таблицу или представление.

• UPDATE — дает возможность пользователю изме­нить данные в таблице или представлении.

• DELETE — дает возможность пользователю уда­лить данные из таблицы или представления.

• EXECUTE — дает возможность пользователю вы­полнить хранимую про­цедуру.

• DRI/REFERENCES — дает возможность пользова­телю добавить к табли­це условие на значение.

Для управления правами доступа интерфейс Transact-SQL SQL Server со­держит инструкции GRANT, DENY и RE­VOKE. С точки зрения системы раз­граничения доступа каждый пользователь может находиться в одном из трех состояний:

• Пользователь имеет право выполнять определенное действие.

• Пользователю запрещено выполнять определенное действие.

• Пользователь не имеет четко определенных разреше­ний и запретов.

Инструкция GRANT используется для предоставления прав доступа пользова­телям или ролям в SQL Server. Наличие определенного права доступа дает пользователю или роли воз­можность выполнять нужные действия. Синтак­сис инструкции GRANT для выражений и объектов:

GRANT {ALL | выражение [, ... n]}

ТО бюджет_безопасности [, ... n]

GRANT {ALL [PRIVILEGES] | список_прав_доступа [, ... n]}

{ [(список_столбцов[, ... n])]

ON [таблица | представление} | [ ... n]

[(список_ столбцов [, ... n])] |

ON {хранимая процедура | расширенная хранимая проце­дура}}

ТО бюджет__безопасности [, ... n]

[WITH GRANT OPTION]

[AS {rpynna_Windows_NT | роль}]

Инструкция DENY применяется для удаления права дос­тупа. В отличие от GRANT, инструкция DENY служит для уда­ления любого права доступа, предос­тавленного пользователю или роли. Кроме того, сервер отслеживает, чтобы в будущем пользователь или роль не унаследовали отобранные права от дру­гой роли. Синтаксис инструкции DENY для выражений и объек­тов:

DENY {ALL | выражение [, ... n]}

ТО бюджет_безопасности [, ... n]

DENY {ALL [PRIVILEGES] | список__прав_доступа [, ... n]}

{ [(список_столбцов [, ... n])]

ON {таблица | представление} | [... n]

[(список_столбцов [, ... n])] |

ON {хранимая процедура | расшире­нная_хранимая_процедура}}

ТО бюджет_безопасности [, ... n]

[CASCADE]

Инструкция REVOKE используется для удаления предос­тавленных ранее прав доступа пользователям или ролям в SQL Server. При этом информация о правах берется из соответствую­щей роли. Синтаксис инструкции REVOKE для выражений и объектов имеет, соответственно, следующий вид:

REVOKE {ALL | выражение [, ... n]}

ТО бюджет_безопасности [, ... n]

REVOKE {ALL [PRIVILEGES] | список_прав_доступа [, ... n]} { [(список столбцов [, .. n])]

ON (таблица | представление} | [...n]

[(список_столбцов [, ... n])] | ON

{хранимая_процедура | расширенная храни­мая_процедура}}

(ТО | FROM} бюджет_безопасности [, ... n]

[CASCADE]

[AS {группа_Wlndows_NT | роль}]

Инструкции GRANT, DENY и REVOKE имеют практи­чески идентичные параметры. Рассмотрим некоторые из них:

• список_прав_доступа — список прав доступа, кото­рые предоставляются или уничтожаются. Для отделения прав доступа в списке следует исполь­зовать запятую. Если указаны все права доступа (ALL), то данному поль­зователю или группе будут предоставлены права доступа того, кто их ус­танавливает;

• таблица, представление, хранимая__процедура и т. п. — имя объекта, право доступа к которому предоставляется или уничтожается;

• список - список имен пользователей или ролей, кото­рым предоставля­ются права доступа или права которых уничтожаются. Для отделения множества имен в списке следует использовать запятые.

К инструкции GRANT может быть присоединена опция WITH GRANT OPTION, позволяющая определить права дос­тупа, с которыми будет возможность предоставления аналогич­ных прав другим пользователям. Это очень удобная опция, но применять ее нужно с осторожностью. Из соображений безопас­ности лучше всего, если данную опцию будет использовать только систем­ный администратор.

Ниже приведен пример предоставления прав доступа SE­LECT и UPDATE к таблице Authors:

GRANT SELECT, UPDATE

ON Authors

TO PUBLIC

GO

Ниже приведен пример удаления права доступа DELETE к таблице Editors:

DENY DELETE

ON Editors

FROM PUBLIC

GO

Для каждого объекта базы данных можно получить ин­формацию о правах различных пользователей и ролей. Эти дан­ные могут быть получены с по­мощью хранимой процедурой SP_HELPROTECT.

Представления дают удобный способ улучшения безопас­ности, т.к. они ог­раничивают данные, доступные пользователям. Например, можно иметь группу пользователей, которым не доз­волено просматривать информацию по авторам, получающим бо­лее чем 50% гонорара. Эта информация доступ­на только главным менеджерам или другим работникам внутри компании. Ниже по­казано, как можно выполнить эту задачу с помощью Transact-SQL.

/* Сначала добавим роль */

SP_ADDROLE grp_junior_emp

GO

/* Теперь уничтожим право доступа SELECT

роли public к таблицам базы данных */

DENY SELECT ON TitleAuthors FROM public

GO

DENY SELECT ON Authors FROM public

GO

/* Теперь создадим представление, ограничивающее дос­туп */

CREATE VIEW View_Authors

AS

SELECT *

FROM Authors

WHERE au_id IN (SELECT au_id

FROM TitleAuthors

WHERE royaltyper <= 50)

GO

/* Предоставим членам роли grp_junior_emp право доступа SELECT к представлению View_Authors */

GRANT SELECT ON View_Authors TO grp_junior_emp

GO

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

Ниже показано, как выполняется скрытие данных, проде­монстрированное на примере предыдущего листинга. Но теперь доступ к информации огра­ничивается применением хранимой процедуры.

/* Сначала добавим роль */

SP_ADDROLE grp_junior_emp

GO

/* Теперь уничтожим право доступа SELECT группы pub­lic к таблицам базы данных */

DENY SELECT ON TitleAuthors FROM public

GO

DENY SELECT ON Authors FROM public

GO

/* Теперь создадим хранимые процедуры, ограничиваю­щие доступ */

CREATE PROCEDURE up__SelectAuthors

AS

SELECT *

FROM Authors

WHERE au_id IN (SELECT au_id

FROM TitleAuthors

WHERE royaltyper <= 50)

GO

/* Предоставим членам роли grp_junior_emp право доступа EXECUTE к хранимой процедуре up_SelectAuthors */

GRANT EXECUTE ON up_SelectAuthors TO grp_junior_emp

GO

Как видно из приведенного примера, младшие работники (grp_junior_emp) имеют возможность обновлять флаг contract таблицы Au­thors без дополнительных прав доступа к ней. Этот вид проце­дуры дает возможность скрыть от пользователей манипуляцию данными, в то же вре­мя они будут иметь ограниченные возмож­ности работы с доступными им данными на сервере.

/* Сначала добавим группу*/

SP_ADDGROUP grp_junior_emp

GO

/* Теперь уничтожим право доступа UPDATE, DELETE, INSERT группы public к таблице базы данных Authors */

DENY UPDATE, DELETE, INSERT ON Authors FROM public

GO

/*Теперь создадим хранимые процедуры, ограничивающие доступ */

CREATE PROCEDURE up_SetContractForAuthor

@nAu_Id id,

@bContract bit

AS

UPDATE Authors

SET contract = @bContract

WHERE au_id = @nAu_Id

PRINT "Автор заключил контракт"

GO

/* Предоставим членам группы grp_junior_emp право дос­тупа EXECUTE к хранимой процедуре up__SetContractForAuthor */

GRANT EXECUTE ON up_SetContractForAuthor TO grp_junior_emp

GO

Стратегия безопасности зависит от параметров инсталля­ции SQL Server. Оставляя бюджет системного администратора (SA) без па­роля, вы совершаете наиболее общую ошибку администраторов. Необходимо сразу же после окончания установки определить пароль этого бюджета. Никогда не позволяйте работникам применять бюджет SA для стандартной поддержки. Для выполнения необ­ходимых изменений в базах данных их проектов они могут ис­пользовать бюджет, основанный на правах доступа к базе.

Безопасность SQL Server — это комплексный набор мер, позволяющий контролировать доступ к базе данных на различных уровнях. Для того чтобы сделать систему безопас­ной или одновременно достаточно открытой, рекомендуется ком­бинировать различные технологии. При разработке системы безопасности всегда помните о всех возможных путях доступа, даже если они маловероятны. Это значит, что если сервер нахо­дится в системе, которая также соединена с Internet, обязательно примите во внимание необходимость мощной системы безопас­ности, предотвращающей доступ в систему неизвестных пользо­вателей. Если система доступна через Internet или через какой-либо другой внешний канал, ее безопасность должна быть чрез­вычайно жесткой.