Главная Обратная связь

Дисциплины:






Отзываем доступ к столбцам



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

Отзываем ранее предоставленные или запрещенные разрешения на столбец Ocenka для пользователя Student.

 

REVOKE UPDATE (Ocenka) ON Progress TO Student;

 

Рассмотрим еще несколько моментов, связанных с предоставлением разрешений:

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

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

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

o в SQL Server 2005 появилась замечательная кнопка Effective Permissions(она расположена на вкладке Permissions). Эта кнопка позволяет посмотреть итоговые разрешения для пользователя или роли базы данных (поскольку разрешения от разных ролей базы данных, назначенных этому пользователю, суммируются).

 

Роли приложений

Альтернативный метод предоставления разрешений в базе данных SQL Server 2008 — воспользоваться ролью приложения (application role). Отличием этого метода является то, что разрешения предоставляются не пользователю, а приложению, из которого пользователь подключается к базе данных.



Применение этого способа выглядит так:

· пользователь от имени любого логина (которому должен соответствовать какой-нибудь объект пользователя в базе данных с правом CONNECT) подключается к серверу и делает нужную базу данных текущей;

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

· после того, как необходимость в правах роли приложения закончилась, пользователь может опять переключиться на свою исходную учетную запись (и получить соответствующие ей права). Эта новая возможность SQL Server 2005 обеспечивается при помощи хранимой процедуры sp_unsetapprole.

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

· гарантируется, что приложение будет обладать необходимыми правами в базе данных;

· администратору достаточно создать любой логин и любую учетную запись в базе данных, без необходимости настраивать требуемые разрешения.

Однако у ролей приложений имеются также и недостатки. В первую очередь, они связаны с тем, что пароль роли приложения передается по сети открытым текстом (предусмотрена возможность использования функции ODBC Encrypt, но реальной защиты она не обеспечивает). Как правило, этот пароль можно извлечь и из двоичного кода клиентского приложения.

Стоит ли использовать роли приложений? Все зависит от ситуации. Если приложение будет работать только на одном предприятии и обслуживаться квалифицированным администратором, то проще использовать обычные средства предоставления разрешений. Если же приложение будет устанавливаться на десятках и сотнях предприятий и за квалификацию администратора вы поручиться не можете, то применение роли приложения может быть очень удачным решением. Часто в качестве альтернативы разработчики требуют предоставлять всем пользователям права владельца базы данных, а иногда и системного администратора сервера, что, конечно, является намного большим злом.

Создание роли приложения производится точно так же, как и создание обычных ролей — из контейнера Имя_базы_данных | Security | Roles | Application Roles. Главное отличие заключается в том, что назначить пользователей этой роли невозможно, зато ей нужно будет указать пароль, который будет использоваться при активизации. Команда Transact-SQL на создание роли приложения может выглядеть так:

 





sdamzavas.net - 2019 год. Все права принадлежат их авторам! В случае нарушение авторского права, обращайтесь по форме обратной связи...