Построение защищенных Web-приложений на основе IIS и MS SQL Server

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

Например, рассмотрим две базы данных на одном сервере, принадлежащие разным владельцам. Database1 принадлежит Бобу, а Database2 — Фреду. Боб не хочет, чтобы у Фреда был доступ к его базе данных, и наоборот. Как владелец Database1 Боб может создать в своей базе данных пользователя для Фреда, и, имея все разрешения внутри Database 1, Боб может олицетворить пользователя Фред. Однако накладываемые SQL Server ограничения безопасности не позволяют Бобу получить доступ к базе данных Фреда в контексте олицетворения. Без наличия этих ограничений по умолчанию Боб получил бы анонимный доступ к данным Фреда. Именно поэтому область олицетворений уровня базы данных ограничена по умолчанию базой данных.

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

Рассмотрим случай маркетингового приложения, которое вызывает хранимую процедуру с именем GetSalesProjections в базе данных Marketing. В этой хранимой процедуре задан переключатель контекста выполнения. Хранимая процедура запрашивает в базе данных Sales сведения о продажах из таблицы SalesStats. По умолчанию этот сценарий не сработает, поскольку контекст выполнения, установленный внутри одной базы данных, является недопустимым вне этой базы данных. Однако разработчики маркетингового приложения не предоставляют пользователям этого приложения прямой доступ к базе данных Sales или права на какой-либо объект внутри нее. Идеальным решением будет олицетворение пользователя, обладающего необходимыми разрешениями в базе данных Sales, с помощью предложения EXECUTE AS в хранимой процедуре. Однако текущие ограничения по умолчанию это запрещают. Таким образом, вопрос состоит в том, как разработчики могут решить эту проблему.

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

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

Рассмотрим случай, когда пользователь явно переключает контекст на уровне сервера с помощью инструкции EXECUTE AS LOGIN. Для этого обязательно наличие разрешений на олицетворение на уровне сервера. Эти разрешения позволяют участнику, вызвавшему инструкцию EXECUTE AS LOGIN, олицетворять указанное имя входа в пределах всего экземпляра SQL Server. Следовательно, эта инструкция позволяет ему имитировать вход в систему под олицетворенным именем входа. Владелец разрешений области уровня сервера — sysadmin, который является обладателем экземпляра SQL Server. При олицетворении уровня сервера средство проверки подлинности — это sysadmin или сам экземпляр SQL Server.

Однако рассмотрим случай, когда  контекст устанавливается инструкцией EXECUTE AS USER или предложением EXECUTE AS в  модуле области базы данных. В этих случаях проверяются разрешения на олицетворение внутри области базы данных. Область по умолчанию разрешений IMPERSONATE для пользователей — это сама база данных, владельцем которой является dbo. Кроме того, владелец базы данных является средством проверки подлинности этих олицетворений. Именно владелец базы данных устанавливает подлинность олицетворенного пользователя и подтверждает его подлинность. Поскольку владельцу базы данных принадлежит вся база данных, олицетворенный контекст считается подлинным внутри всей указанной базы данных. Однако вне этой базы данных олицетворенный контекст является недопустимым.

С помощью средств проверки подлинности  проверяется допустимость установленного контекста внутри определенной области. Чаще всего средствами проверки подлинности являются системный администратор (SA), экземпляр SQL Server, а также dbo (при работе с базами данных). Средство проверки подлинности — это, в конечном итоге, владелец области, внутри которой установлен контекст для отдельного пользователя или имени входа. Сведения о средстве проверки подлинности получаются из информации о маркере, поддерживаемой для имени входа и пользователя, и доступны через представления sys.user_token и sys.login_token.

Контекст выполнения, принадлежащий  владельцу области как ее средству проверки подлинности, действителен внутри всей этой области. Это обусловлено тем, что владелец области, например базы данных, является неявно доверенным для всех сущностей внутри области. Контекст так же действителен в других областях, например в других базах данных или непосредственно экземплярах SQL Server, в которых средство проверки подлинности является доверенным. Следовательно, действительность олицетворенного пользовательского контекста вне области базы данных зависит от того, является ли средство проверки подлинности доверенным для контекста внутри целевой области. Эта «доверенность» устанавливается путем выдачи средству проверки подлинности разрешения AUTHENTICATE, если целевая область является другой базой данных, или путем выдачи разрешения AUTHENTICATE SERVER, если целевая область — экземпляр SQL Server.

Для расширения области олицетворения  от текущей базы данных до целевой области, например до другой базы данных или экземпляра SQL Server, необходимо выполнить следующие условия:

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

На основании предыдущего примера  с базами данных Sales и Marketing ниже показано, как хранимая процедура GetSalesProjections в базе данных Marketing обрабатывает данные из таблицы SalesStats в базе данных Sales. Хранимая процедура содержит предложение EXECUTE AS USER MarketingExec. Владельцем базы данных Sales является SalesDBO, владельцем базы данных Marketing — MarketingDBO. Общая картина представлена на рисунке 38.

Рисунок 38 – Доверие средству проверки подлинности

Если хранимая процедура GetSalesProjections вызывается пользователем, то предложение EXECUTE AS неявно переключает контекст выполнения хранимой процедуры с вызвавшего пользователя на пользователя MarketingExec. Средством проверки подлинности для этого контекста является MarketingDBO — владелец базы данных Marketing. По умолчанию процедура имеет доступ к любым ресурсам внутри базы данных Marketing, к которой разрешен доступ пользователю MarketingExec. Однако, чтобы получить доступ к таблице базы данных Sales, база данных Sales должна доверять средству проверки подлинности MarketingDBO.

Для этого в базе данных Sales нужно создать пользователя с именем MarketingDBO, сопоставленным с именем входа MarketingDBO, и выдать пользователю разрешение AUTHENTICATE в базе данных Sales. В результате внутри базы данных действительным является любой контекст выполнения, средство проверки подлинности которого обладает этим разрешением. Поскольку средству проверки подлинности MarketingDBO предоставлено разрешение AUTHENTICATE в базе данных Sales, контекст для пользователя MarketingExec, установленный предложением EXECUTE AS в хранимой процедуре GetSalesProjections в базе данных Marketing, является доверенным в базе данных Sales.

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

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

Предположим, что участник MarketingDBO является владельцем другой базы данных с именем Conference. Предположим также, что владельцу базы данных с именем MarketingDBO нужно, чтобы контексты выполнения, указанные внутри базы данных Marketing, обладали доступом к ресурсам в базе данных Sales. Однако при этом у контекстов, установленных в базе данных Conference, не должно быть доступа к базе данных Sales.

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

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

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

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

Именно для этого предназначено свойство TRUSTWORTHY. Например, предположим, что олицетворенные контексты из базы данных Database 1 должны быть доверенными, тогда как контексты из другой базы данных, Database 2, не должны быть доверенными, и все они принадлежат одному владельцу, который является доверенным средством проверки подлинности целевой области. Свойству TRUSTWORTHY можно присвоить значение ON для Database 1 и OFF для Database 2; таким образом, модули в Database 2 не будут иметь доступа к ресурсам вне этой базы данных.

Ниже приведен пример управления доступом к ресурсам вне области базы данных-источника с помощью свойства TRUSTWORTHY. Пользователь MarketingDBO обладает разрешениями AUTHENTICATE в базе данных Sales и является владельцем баз данных Marketing и Conference. Хранимая процедура GetSalesProjections в базе данных Marketing может успешно обращаться к базе данных Sales, поскольку она соответствует двум требованиям безопасности: средство проверки подлинности MarketingDBO является доверенным в целевой области, а база данных-источник Marketing заслуживает доверия. Попытки обратиться к базе данных Sales из базы данных Conference запрещаются, поскольку при этом выполняется только одно требование: средство проверки подлинности MarketingDBO является доверенным в целевой области (рисунок 39).

Рисунок 39 – Управление доступом с помощью свойства TRUSTWORTHY

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

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

Может потребоваться уровень доверия  с более высокой гранулярностью. Предположим, что необходимо доверять только небольшому числу модулей  в базе данных-источнике, при этом доступ к целевому ресурсу осуществляется с помощью предложения EXECUTE AS, а  база данных-источник является доверенной не целиком. Например, допустим, что пользователю SalesDBO нужно установить доступ хранимой процедуры GetSalesProjections к таблице SalesStats только от имени пользователя MarketingExec, но при этом у любого другого пользователя базы данных Marketing с правами на олицетворение MarketingExec не должно быть доступа к базе данных Sales. Для этого недостаточно сделать пользователя MarketingDBO доверенным и пометить базу данных Marketing как заслуживающую доверия. Для выполнения этого требования доверительная модель обеспечивает дополнительный уровень гранулярности, позволяя использовать в качестве средств проверки подлинности сертификаты или асимметричные ключи. Это дает техническое преимущество, обеспечиваемое электронной подписью. Дополнительные сведения об электронной подписи см. в разделе ADD SIGNATURE (Transact-SQL).