Лекция №18

3. Лекция: Управление доступом к базам данных SQL Server: версия для печати и PDA  Данная лекция содержит материалы по управлению доступом к базам данных SQL Server, в частности рассматривается управление пользователями базы данных, включение пользователя guest, создание ролей базы данных, предоставление разрешений на базу данных и добавление пользователя базы данных

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

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

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

Пользователи базы данных - это участники уровня базы данных. Все имена входа, за исключением серверной роли sysadmin, должны быть сопоставлены пользователям, которые, в свою очередь, сопоставлены базе данных, к которой им нужен доступ. Члены роли sysadmin сопоставлены пользователю dbo во всех базах данных сервера.

Добавляем пользователя базы данных

Добавить пользователя базы данных можно при помощи инструкции CREATE USER. Следующий пример кода Transact-SQL создает имя входа Peter и сопоставленного с ним пользователя в базе данных Adventure Works:

• Создаем имя входа Peter

CREATE LOGIN Peter WITH PASSWORD='Tyu87IOR0';

• Изменяем контекст соединения на базу данных AdventureWorks.

• USE AdventureWorks;

GO

• Добавляем пользователя базы данных Peter, который сопоставлен имени входа Peter в БД AdventureWorks.

CREATE USER Peter FOR LOGIN Peter;

Управляем пользователями базы данных

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

SELECT HAS_DBACCESS('AdventureWorks');

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

Если нужно временно отключить доступ пользователя к базе данных, можно отозвать разрешение CONNECT для этого пользователя. Следующий пример отзывает разрешение CONNECT для пользователя Peter:

• Изменяем контекст соединения на базу данных AdventureWorks.

• USE AdventureWorks;

GO

• Отзываем разрешение connect для Peter в AdventureWorks.

REVOKE CONNECT TO Peter;

Удалить пользователя в базы данных можно при помощи инструкции DROP USER.

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

Управляем пользователями, утратившими связь с именами входа

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

• Изменяем контекст соединения на базу данных AdventureWorks.

• USE AdventureWorks;

GO

• Составляем отчет обо всех пользователях базы данных, утративших связь с именем входа

EXECUTE sp_change_users_login @Action='Report';

В SQL Server 2005 допускается создание пользователя, не сопоставленного имени входа, с помощью фразы WITHOUT LOGIN. Пользователи, созданные с помощью фразы WITHOUT LOGIN, не считаются пользователями, утратившими связь с именем входа. Эта возможность может быть очень полезна в ситуации, когда необходимо изменить контекст выполнения какого-либо модуля. О контексте выполнения рассказывается далее в этой лекции. Следующий пример создает пользователя, не сопоставленного имени входа.

• Изменяем контекст соединения на базу данных AdventureWorks.

• USE AdventureWorks;

GO

• Создаем пользователя базы данных Paul в базе данных AdventureWorks

• не сопоставляя с ним имени входа в данном экземпляре SQL Server instance

CREATE USER Paul WITHOUT LOGIN;

Включаем пользователя guest

Когда имя входа, которое не имеет сопоставленного пользователя, пытается соединиться с базой данных, SQL Server предпринимает попытку подключения с использованием пользователяGuest. Пользователь Guest создается по умолчанию без предоставления разрешений. Можно включить пользователя guest, предоставив ему разрешение CONNECT, как показано ниже.

• Изменяем контекст соединения на базу данных AdventureWorks.

• USE AdventureWorks;

GO

• Предоставляем пользователю Guest доступ к базе данных AdventureWorks.

GRANT CONNECT TO Guest;

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

Предоставление разрешений на базу данных

Создав пользователей базы данных, необходимо управлять разрешениями для этих пользователей. Это можно осуществить, добавляя пользователей в роли базы данных или предоставляя самим пользователям гранулярные разрешения.

Создаем роли базы данных

Роли базы данных - это участники уровня базы данных. Роли базы данных можно использовать для назначения разрешений базы данных группе пользователей. В SQL Server 2005 по умолчанию создается набор ролей базы данных. Эти роли по умолчанию перечислены в табл. 3.1.

Можно добавлять роли базы данных, если нужно сгруппировать пользователей в соответствии с требованиями определенных разрешений. Следующий пример кода создает роль базы данных с именем Auditors и добавляет пользователя Peter в эту новую роль.

• Изменяем контекст соединения на базу данных AdventureWorks.

• USE AdventureWorks;

GO

• Создаем роль Auditors в базе данных AdventureWorks.

• CREATE ROLE Auditors;

GO

• Добавляем пользователя Peter к роли Auditors

EXECUTE sp_addrolemember "Auditors", "Peter";

Управляем ролями базы данных

Выполнив запрос системной функции IS_MEMBER, можно проверить, принадлежит ли текущий пользователь к какой-либо роли базы данных. В следующем примере мы проверим, принадлежит ли текущий пользователь к роли базы данных db_owner.

• Изменяем контекст соединения на базу данных AdventureWorks.

• USE AdventureWorks;

GO

• Проверяем, принадлежит ли текущий пользователь к роли db_owner

SELECT IS_MEMBER ("db_owner");

Совет. Системную функцию IS_MEMBER можно использовать для проверки того, принадлежит ли текущий пользователь также к определенной группе Windows, как показано в следующем примере:

• Изменяем контекст соединения на базу данных AdventureWorks.

• USE AdventureWorks;

GO

• Проверяем, принадлежит ли текущий пользователь к группе Managers в домене ADVWORKS

SELECT IS_MEMBER ("[ADVWORKS\Managers]");

Удалить пользователей из роли базы данных можно при помощи системной хранимой процедуры sp_droprolemember. Если нужно удалить роль базы данных, то используется инструкцияDROP ROLE. Следующий код удаляет пользователя Peter из роли базы данных Auditors, а затем удаляет роль Auditors.

• Изменяем контекст соединения на базу данных AdventureWorks.

• USE AdventureWorks;

GO

• Удаляем пользователя Peter из роли Auditors

EXECUTE sp_droprolemember "Auditors", "Peter";

• Удаляем роль Auditors из текущей базы данных

DROP ROLE Auditors;

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

Предоставляем гранулярные разрешения базы данных

В качестве альтернативы использованию фиксированных ролей базы данных можно предоставлять гранулярные разрешения пользователям и ролям базы данных. Разрешениями можно управлять при помощи инструкций GRANT, DENY и REVOKE. В следующем примере мы предоставим разрешение BACKUP DATABASE пользователю Peter:

• Изменяем контекст соединения на базу данных AdventureWorks.

• USE AdventureWorks;

GO

• Предоставляем разрешения пользователю базы данных Peter

• на резервное копирование базы данных AdventureWorks.

GRANT BACKUP DATABASE TO Peter;

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

Передовой опыт. Чтобы уменьшить затраты времени и усилий на обслуживание структуры разрешений, следует назначать разрешения ролям базы данных, а не отдельным пользователям базы данных.

Управление ролями приложения

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

Создаем роли приложения

Роль приложения можно создать при помощи инструкции CREATE APPLICATION ROLE. Этот код имеется в файле примеров ApplicationRoles.sql.

• Изменяем контекст соединения на базу данных AdventureWorks.

• USE AdventureWorks;

GO

• Создаем роль приложения FinancialRole в текущей базе данных

CREATE APPLICATION ROLE FinancialRole WITH PASSWORD = "Pt86Yu$$R3";

Используем роли приложения

Роли приложений перед использованием необходимо активизировать. Это можно сделать, выполнив системную хранимую процедуру sp_setapprole. После того, как роль приложения активизирована в текущем соединении, она остается активной до тех пор, пока не будет закрыто соединение или выполнена системная хранимая процедура sp_unsetapprole. Хотя роли приложения предназначены для использования из клиентских приложений, их можно также использовать из особых пакетов T-SQL. Следующая процедура (ее можно найти в файлах примеров под именем ApplicationRolesUse.sql ) описывает, как активизировать роль Financial Role и отменить эту активизацию.

• Изменяем контекст соединения на базу данных AdventureWorks.

• USE AdventureWorks;

GO

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

DECLARE @context varbinary (8000);

• Активируем роль приложения и сохраняем текущий контекст соединения

• EXECUTE sp_setapprole "FinancialRole", "Pt86Yu$$R3",

@fCreateCookie = true, @cookie = @context OUTPUT;

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

SELECT CURRENT_USER;

• Деактивируем роль приложения, и восстанавливаем предыдущий контекст соединения.

• EXECUTE sp_unsetapprole @context;

GO

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

• SELECT CURRENT_USER;

GO

Удаляем роли приложения

Если нужно удалить роль приложения, используйте инструкцию DROP APPLICATION ROLE, как показано в следующем примере (этот код имеется в файле примеров ApplicationRoles.sql):

• Изменяем контекст соединения на базу данных AdventureWorks.

• USE AdventureWorks;

GO

• удаляем роль приложения FinancialRole из текущей базы данных

DROP APPLICATION ROLE FinancialRole;

Управление доступом к схемам

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

<Server>.<Database>.<Schema>.<Object>.

Введение в схемы

Схемы базы данных можно создавать при помощи инструкции CREATE SCHEMA. Создавая схему, можно создать объекты базы данных и назначить разрешения в пределах одной транзакции, которая вызывается инструкцией CREATE SCHEMA. Следующий пример (он есть в файлах примеров под именем ManagingAccessToSchemas01.sql ) создает схему с именем Accounting, назначает пользователя Peter владельцем схемы и создает таблицу с именем Invoices. В этом примере также предоставляется разрешение select роли базы данных public.

• Изменяем контекст соединения на базу данных AdventureWorks.

• USE AdventureWorks;

GO

• Создаем схему Accounting с владельцем Peter.

• CREATE SCHEMA Accounting

• AUTHORIZATION Peter;

GO

• Создаем таблицу Invoices в схеме Accounting.

• CREATE TABLE Accounting.Invoices (

• InvoiceID int,

• InvoiceDate smalldatetime,

• ClientID int);

GO

• Предоставляем разрешение SELECT на новую таблицу роли public.

• GRANT SELECT ON Accounting.Invoices

TO public; GO

• Добавляем строку данных в новую таблицу.

• Обратите внимание на двухкомпонентное имя, которое мы используем для обращения к таблице в текущей базе данных.

• INSERT INTO Accounting.Invoices

VALUES (101,getdate(),102);

Удалить схему можно при помощи инструкции DROP SCHEMA. В SQL Server 2005 не допускается удаление схемы, если в схеме есть объекты. Информацию о схемах можно получить, выполнив запрос к представлению каталога sys.schemas. Следующий пример выполняет запрос к представлению каталога sys.schemas, чтобы получить информацию о схеме:

SELECT *

FROM sys.schemas;

Следующий код (который можно найти в файлах примеров под именем ManagingAccessToSchemas02.sql ) показывает, как удалить существующую схему, выполнив запрос к объектам, которые содержатся в этой схеме, и удалить сначала эти объекты.

• Изменяем контекст соединения на базу данных AdventureWorks.

• USE AdventureWorks;

GO

• Извлекаем информацию о схеме Accounting.

• SELECT s.name AS "Schema",

o.name AS "Object" FROM sys.schemas s INNER JOIN sys.objects o ON s.schema_id=o.schema_id WHERE s.name='Accounting'; GO

• Удаляем таблицу Invoices из схемы Accounting.

• DROP TABLE Accounting.Invoices;

GO

• Удаляем схему Accounting.

DROP SCHEMA Accounting;

Отделяем пользователей от схем

Одним из преимуществ схем является отделение пользователей от объектов. В SQL Server 2005 все объекты принадлежат к схемам, поэтому можно изменять и удалять пользователей базы данных без какого-либо влияния на объекты базы данных или ссылки на эти объекты из приложений базы данных. Эта абстракция позволяет владеть одними и теми же объектами нескольким пользователям, поскольку можно создать схему, владельцем которой будет роль базы данных.

Используем схему по умолчанию

Когда приложение ссылается на объект базы данных, не уточняя схемы, SQL Server осуществляет попытку найти объект в схеме, заданной для текущего пользователя по умолчанию. Если объект не содержится в схеме по умолчанию, SQL Server пытается обнаружить объект в схеме dbo. В следующем примере (который можно найти в файлах примеров под именемManagingAccessToSchemas03.sql ) демонстрирует, как создать схему и назначить ее в качестве схемы по умолчанию для пользователя.

• Создаем имя входа SQL Server в данном экземпляре SQL Server.

• CREATE LOGIN Sara

WITH PASSWORD='TUT87rr$$'; GO

• Изменяем контекст соединения на базу данных AdventureWorks.

• USE AdventureWorks;

GO

• Создаем пользователя Sara в базе данных AdventureWorks и сопоставляем этого пользователя имени входа Sara

• CREATE USER Sara

FOR LOGIN Sara; GO

• Создаем схему Marketing, владелец - пользователь Peter.

• CREATE SCHEMA Marketing

AUTHORIZATION Peter; GO

• Создаем таблицу Campaigns в только что созданной схеме.

• CREATE TABLE Marketing.Campaigns (

CampaignID int, CampaignDate smalldatetime, Description varchar (max)); GO

• Предоставляем разрешение SELECT пользователю Sara на новую таблицу.

• GRANT SELECT ON Marketing.Campaigns TO Sara;

GO

• Объявляем схему Marketing схемой по умолчанию для пользователя Sara

• ALTER USER Sara

WITH DEFAULT_SCHEMA=Marketing;

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

Таблица и столбцы хранят данные, которые извлекают и создают приложения. Управление доступом к этим данных осуществляется через иерархию разрешений SQL Server 2005. Управлять этой иерархией разрешений можно при помощи инструкций GRANT, DENY и REVOKE.

GRANT. Разрешает роли или пользователю выполнять операции, определенные в момент предоставления разрешения.

DENY. Запрещает пользователю или роли определенные разрешения и предотвращает наследование этих разрешений от других ролей..

REVOKE. Отзывает ранее запрещенные или предоставленные разрешения.

Изменение прав доступа к таблице

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

Предоставляем доступ к таблице

Доступ пользователям базы данных и ролям можно предоставить с помощью инструкции GRANT. В следующем примере разрешения SELECT, INSERT и UPDATE на таблицу Sales.Customer предоставляются пользователю Sara (код для управления доступом к таблицам в этом и следующих разделах имеется в файлах примеров под именем ManagingAccessToTables.sql.).

• Изменяем контекст соединения на базу данных AdventureWorks.

• USE AdventureWorks;

GO

• Предоставляем пользователю Sara некоторые разрешения

• для таблицы Sales.Customer table.

• GRANT SELECT,INSERT,UPDATE

ON Sales.Customer TO Sara;

Ограничиваем доступ к таблице

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

• Изменяем контекст соединения на базу данных AdventureWorks.

• USE AdventureWorks;

GO

• Отзываем разрешение SELECT на таблицу Sales.Customer у Sara.

• REVOKE SELECT

ON Sales.Customer TO Sara;

Однако пользователь может сохранить отозванное разрешение вследствие принадлежности к роли, которой предоставлено данное разрешение. В этом случае необходимо использовать инструкцию DENY, чтобы запретить доступ этому пользователю. Например:

• Изменяем контекст соединения на базу данных AdventureWorks.

• USE AdventureWorks;

GO

• Запрещаем пользователю Sara разрешение DELETE на таблицу Sales.Customer. независимо от того, какие разрешения этот пользователь мог унаследовать от роли.

• DENY DELETE

ON Sales.Customer TO Sara;

Предоставление доступа к отдельным столбцам

В SQL Server 2005 есть возможность предоставить или отклонить доступ к отдельным столбцам, вместо того, чтобы работать со всей таблицей. Эта возможность предоставляет гибкость в отклонении доступа, например, к конфиденциальным данным в некоторых столбцах. Разрешения, которыми можно управлять для столбцов таблицы, перечислены в табл. 3.3.

Предоставляем доступ к столбцам

Доступ к отдельным столбцам можно предоставить с помощью инструкции GRANT. В следующем примере разрешения SELECT и UPDATE предоставляются пользователю Sara на столбцыDemographics и Modified Date таблицы Sales.Individual. (Код для управления доступом к столбцам таблицы в этом и следующих разделах имеется в файлах примеров под именемManagingAccessToColumns. sql.)

• Изменяем контекст соединения на базу данных AdventureWorks.

• USE AdventureWorks;

GO

• Предоставляем разрешения SELECT и UPDATE пользователю Sara на определенные столбцы таблицы Sales.Individual

• GRANT SELECT,UPDATE (

Demographics, ModifiedDate) ON Sales.Individual TO Sara;

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

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

• Изменяем контекст соединения на базу данных AdventureWorks.

• USE AdventureWorks;

GO

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

• REVOKE UPDATE (Demographics)

ON Sales.Individual TO Sara;

Управление доступом к программируемым объектам

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

Управление безопасностью для хранимых процедур

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

Выполняем хранимую процедуру

Когда приложение совершает вызов для выполнения хранимой процедуры, SQL Server проверяет, имеет ли текущий пользователь базы данных разрешение EXECUTE для этой хранимой процедуры. В следующем примере разрешение EXECUTE для хранимой процедуры dbo.uspGetBillOfMaterials предоставляется пользователю Sara. (Код в этом и следующих разделах можно найти в файлах примеров под именем ManagingAccessToProgrammableObjects.sql.)

• Изменяем контекст соединения на базу данных AdventureWorks.

• USE AdventureWorks;

GO

• Предоставляем пользователю Sara разрешение EXECUTE для хранимой процедуры.

GRANT EXECUTE On dbo.uspGetBillOfMaterials TO Sara;

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

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

Определяемые пользователем функции - это программируемые объекты, как и хранимые процедуры. Существует два основных вида определяемых пользователем функций: функции, возвращающие скалярное значение, которые возвращают одно значение, и функции, которые возвращают табличное значение. В зависимости от типа определяемой пользователем функции, вам придется предоставить одно из двух разрешений - EXECUTE или SELECT (см. табл. 3.5).

Выполняем функции, возвращающие табличное значение

Когда пользователь выполняет функцию, возвращающую табличное значение, SQL Server проверяет, имеет ли этот пользователь разрешение SELECT для данной таблицы. Эти разрешения для функции можно предоставить тем же способом, каким предоставляется разрешение SELECT для таблиц. В следующем примере пользователю Sara предоставляется разрешение SELECTна определяемую пользователем функцию dbo.ufnGetContactInformation.

• Изменяем контекст соединения на базу данных AdventureWorks.

• USE AdventureWorks;

GO

• Предоставляем Sara разрешение на выполнение пользовательской функции.

GRANT SELECT ON dbo.ufnGetContactInformation TO Sara;

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

Выполняем функцию, которая возвращает скалярное значение

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

• Изменяем контекст соединения на базу данных AdventureWorks.

• USE AdventureWorks;

GO

• Предоставляем Sara разрешение на выполнение пользовательской функции.

GRANT EXECUTE ON dbo.ufnGetStock TO Sara;

Управление безопасностью для сборок

SQL Server 2005 предоставляет возможность включать сборки .NET (объекты, которые ссылаются на файлы .dll ) в механизм базы данных и вызывать эти сборки в хранимых процедурах и функциях. Для сборок можно задать те же разрешения, что и для хранимых процедур. Смотрите список разрешений в табл. 3.4.

Определяем набор разрешений

Для создания сборки вам необходимо определить набор разрешений. Этот набор разрешений определяет набор разрешений на доступ к коду, который предоставляется сборке в SQL Server. Существует три различных набора разрешений:

• SAFE. Код, выполняемый сборкой, не может обращаться к внешним системным ресурсам. SAFE - это самый ограничительный набор разрешений, который установлен по умолчанию..

• EXTERNAL_ACCESS. Сборка может обращаться к внешним системным ресурсам.

• UNSAFE. Сборка может выполнять неуправляемый код.

SAFE является рекомендуемым набором разрешений для сборок, которые не нуждаются в доступе к внешним ресурсам.

Дополнительная информация.Дополнительную информацию о безопасности доступа кода можно получить по следующей ссылке:http://msdn.microsoft.com/library/default.asp?url=/ library/en-us/secmod/html/ secmod116.asp.

Выполняем сборку

Когда приложение пытается обратиться к объекту внутри сборки, механизм базы данных проверяет, имеет ли текущий пользователь разрешение EXECUTE. Следующий код используется для предоставления разрешения EXECUTE для сборки пользователю Sara.

• Изменяем контекст соединения на базу данных AdventureWorks.

• USE AdventureWorks;

GO

• Предоставляем пользователю Sara разрешение на выполнение сборки.

• GRANT EXECUTE ON <AssemblyName>

TO Sara;

Предоставляя разрешение EXECUTE для сборки, вы предоставляете пользователю разрешение EXECUTE для всех объектов сборки.

Управление цепочками владения

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

При обращении к объекту в цепочке, SQL Server сначала сравнивает владельца вызываемого объекта и владельца вызывающего объекта. Если у объектов один владелец, то разрешения вызываемого объекта не оцениваются. Эта функция очень полезна для управления разрешениями объектов. Предположим, например, что Sara создает таблицу с именемPerson.SupplierContacts и хранимую процедуру Person.InsertSupplierContacts, c помощью которой Sara добавляет строки в таблицу PersonSupplierContacts. Поскольку у этих объектов один владелец, Sara, то для того, чтобы предоставить другим пользователям разрешение EXECUTE для таблицы PersonSupplierContacts, достаточно предоставить разрешениеEXECUTE на хранимую процедуру Person.InsertSupplierContacts. Нет необходимости предоставлять другим пользователям разрешения для таблицы.

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

Управление контекстом выполнения

Имя входа и пользователь, подключившиеся на время сеанса или выполняющие процедуру, определяют контекст выполнения. Маркеры имени входа и пользователя предоставляют SQL Server информацию, необходимую для оценки разрешений объектов. SQL Server 2005 предоставляет возможность изменить контекст выполнения при помощи инструкции EXECUTE AS. Эта операция называется переключением контекста.

Выполняем инструкцию EXECUTE AS

Инструкция EXECUTE AS позволяет явно определить контекст выполнения для текущего соединения. EXECUTE AS можно использовать для того, чтобы изменить имя входа пользователя для текущего соединения. Изменение контекста выполнения действительно до тех пор, пока не будет сделано другое изменение контекста, или пока не будет закрыто подключение или выполнена инструкция REVERT. В следующем примере инструкция EXECUTE AS используется для изменения контекста выполнения на пользователя Sara.

• Изменяем контекст соединения на базу данных AdventureWorks.

• USE AdventureWorks;

GO

• Изменяем контекст выполнения на пользователя Sara.

EXECUTE AS USER='Sara';

• Следующая инструкция будет выполнена с учетными данными пользователя Sara.

TRUNCATE TABLE dbo.ErrorLog;

Только что рассмотренный код завершится с ошибкой, поскольку Sara не имеет разрешения на удаление всех строк в таблице без записи в журнал. Следующий код для удаления всех строк в таблице без записи в журнал будет успешно выполнен.

• Снова изменяем контекст выполнения, возвращая его к исходному состоянию REVERT ;

• Теперь следующая инструкция будет выполнена в исходном контексте выполнения.

TRUNCATE TABLE dbo.ErrorLog;

Управляем переключением контекста

Кроме управления контекстом выполнения для пакетов (групп инструкций T-SQL, отправленных серверу на выполнение, как в примере TRUNCATE TABLE, рассмотренном выше), можно управлять контекстом выполнения для хранимых процедур и пользовательских функций. Переключая контекст в этих модулях, вы можете управлять тем, какая учетная запись пользователя будет использоваться для доступа к объекту, на который ссылается хранимая процедура или функция. Для выполнения этой задачи можно использовать инструкциюEXECUTE AS со следующими изменениями:

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

• SELF. Инструкции выполняются в контексте пользователя, создавшего или изменившего хранимую процедуру или функцию.

• OWNER. Инструкции выполняются в контексте текущего владельца хранимой процедуры или функции..

• <User>or< Login >. Инструкции выполняются в контексте определенного пользователя или имени входа.

В следующем примере создается хранимая процедура, которая переключает контекст на пользователя dbo. Затем она предоставляет разрешение EXECUTE для хранимой процедуры и изменение контекста выполнения хранимой процедуры пользователю Sara.

• Создаем хранимую процедуру для выполнения инструкций -' в контексте dbo.

• CREATE PROCEDURE dbo.usp TruncateErrorLog

• WITH EXECUTE AS "dbo"

• AS

• TRUNCATE TABLE dbo.ErrorLog;

GO

• Предоставляем разрешения на выполнение процедуры пользователю Sara.

GRANT EXECUTE ON dbo.usp_TruncateErrorLog TO Sara

• Изменяем контекст выполнения этого пакета на пользователя Sara.

EXECUTE AS [USER=]'Sara'

• Выполняем хранимую процедуру.

EXECUTE dbo.usp_TruncateErrorLog

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

Заключение

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

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

Получение доступа к экземпляру SQL Server означает доступ только для выполнения специфичных для сервера операций, для чего можно применить определенные разрешения через использование фиксированных ролей или назначения определенных разрешений именам входа.

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

Доступ к объектам базы данных контролируется различными способами, в зависимости от типа объекта. Эти разрешения могут применяться к отдельным пользователям или ролям базы данных, которые могут быть фиксированными или создаваться при необходимости для удовлетворения требований бизнеса.

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

Управление контекстом выполнения также предоставляет способ разрешить пользователям выполнять операции, которыми нельзя управлять через разрешения.

Краткий справочник по 2-3 лекции