Запрет доступа пользователям

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

• отключение имени входа:

ALTER LOGIN Mary DISABLE;

• включение имени входа:

ALTER LOGIN Mary ENABLE;

• выполнение запроса к системному представлению каталога:

SELECT * FROM sys.sql_logins WHERE is_disabled=1; GO

В SQL Server Management Studio отключённые имена входа помечаются красной стрелкой. Эта стрелка отображается в правом нижнем углу значка имени входа, который находится в папке Безопасность/Имена входа (Security/Logins) в панели Обозревателя объектов (Object Explorer). С другой стороны, если необходимо удалить имя входа из данного экземпляра, следует использовать инструкцию DROP LOGIN. Следующий пример удаляет имя входа.

DROP LOGIN Mary;

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

Рекомендации по управлению доступом

Ниже следует ряд несложных рекомендаций, касающихся применения средств управления доступом при создании и развертывании решений на основе SQL Server 2005.

Применение схем и ролей. Общие принципы

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

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

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