Предоставление прав на объекты в базе данных

Работа с разрешениями производится одинаково для всех объектов базы данных:

· на вкладке «Разрешения» свойств этого объекта (эта вкладка предусмотрена не для всех объектов, для которых можно предоставить разрешения);

· на странице «Защищаемые объекты» окна свойств пользователя или роли;

· при помощи команд GRANT (предоставить разрешение), DENY (явно запретить что-то делать) и REVOKE (отменить явно предоставленное разрешение или запрет).

Начиная c версии 2005, в SQL Serve появилась возможность предоставлять разрешения на уровне схемы. К схеме в SQL Server могут относиться таблицы, представления, хранимые процедуры, пользовательские функции, ограничения целостности, пользовательские типы данных и другие объекты, на которые приходится предоставлять разрешения чаще всего. Если вы назначите пользователю разрешения на схему, то он получит разрешения на все объекты этой схемы.

Далее перечислены разрешения, которые можно предоставить на уровне схемы. Мы приведем только разрешения для этого объекта, поскольку разрешения схемы включают в себя разрешения, которые можно предоставить другим объектам, например, разрешения SELECT для таблиц и представлений и EXECUTE для хранимых процедур.

· ALTER — возможность вносить любые изменения в свойства объекта (за исключением смены владельца).

· CONTROL — тот, кому предоставлено такое разрешение, получает полные права как на сам объект, так и на информацию в нем.

· DELETE — возможность удалять существующую информацию в таблицах. Применяется к таблицам, представлениям и столбцам.

· EXECUTE — право запускать на выполнение. Применяется к хранимым процедурам и функциям.

· INSERT — право на вставку новых данных в таблицы. Применяется к таблицам, представлениям и столбцам.

· REFERENCES — разрешение, которое можно предоставить для проверки ограничений целостности. Например, пользователь может добавлять данные в таблицу с внешним ключом, а на таблицу с первичным ключом ему нельзя предоставлять права на просмотр. В этом случае на таблицу с первичным ключом ему можно предоставить право REFERENCES — и он сможет производить вставку данных в таблицу с внешним ключом, не получая лишних прав на главную таблицу. Это разрешение можно предоставлять на таблицы, представления, столбцы и функции.

· SELECT — право на чтение информации. Предоставляется для таблиц, представлений, столбцов и табличных функций.

· TAKE OWNERSHIP — право на принятие на себя владения данным объектом. Владелец автоматически обладает полными правами на свой объект. Такое право можно назначить для любых объектов.

· UPDATE — возможность вносить изменения в существующие записи в таблице. Предоставляется на таблицы, представления и столбцы.

· VIEW DEFINITION — право на просмотр определения для данного объекта. Предусмотрено для таблиц, представлений, процедур и функций.

Для каждого разрешения мы можем установить три значения:

· GRANT — разрешение предоставлено явно;

· WITH GRANT — разрешение не только предоставлено данному пользователю, но он также получил право предоставлять это разрешение другим пользователям. Можно предоставлять, конечно, только вместе с GRANT;

· DENY — явный запрет на выполнение действия, определенного данным разрешением. Как в любых системах безопасности, явный запрет имеет приоритет перед явно предоставленными разрешениями.

Из кода Transact-SQL разрешения можно предоставлять командами GRANT, DENY и REVOKE. Например, чтобы предоставить пользователю User1 возможность просматривать данные в таблице Table1 в схеме dbo, можно воспользоваться командой:

GRANT SELECT ON dbo.Table1 TO User1;

Лишить его ранее предоставленного права можно при помощи команды:

REVOKE SELECT ON dbo.Table1 TO User1;

Некоторые рекомендации, связанные с предоставлением разрешений:

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

· Существует общий принцип: не стоит обращаться из клиентского приложения к таблицам базы данных напрямую. Для изменения данных лучше использовать хранимые процедуры, а для запросов на чтение — хранимые процедуры или представления. Причина проста: если потребуется поменять структуру вашей базы данных (например, какую-то таблицу поделить на текущую и архивную или добавить новый столбец) не потребуется вносить изменения в клиентское приложение. Это следует помнить и при предоставлении разрешений. Отметим также, что при помощи хранимых процедур можно очень просто реализовать дополнительные проверки в добавление к обычным разрешениям;

· SQL Server позволяет настраивать разрешения на уровне отдельных столбцов. На практике лучше не пользоваться такими разрешениями из-за падения производительности и усложнения системы разрешений. Если пользователю можно видеть не все столбцы в таблице (например, ему не нужны домашние телефоны сотрудников), то правильнее будет создать представление или хранимую процедуру, которые будут отфильтровывать ненужные столбцы.

Задание для самостоятельной работы:

· Создайте логин SQL Server «Admin» и назначьте ей роль sysadmin;

· Создайте в базе данных роль «Saler» и назначьте ей разрешения на выборку данных из всех таблиц, изменение данных в таблицах Order, OrdItem и запуск хранимой процедуры spr_getOrders;

· Создайте логин SQL Server «Ivanov» и сопоставьте его с одноименным пользователем в базе данных Sales. Назначьте созданному пользователю роль Saler;

· Протестируйте созданные логины.

Дата добавления: 2014-12-08