SQL Server повышенные разрешения со встроенным входом

Question

У меня есть приложение, работающее в IIS, которое подключается к экземпляру SQL Server 2008 R2, используя встроенную проверку подлинности Windows. Это приложение выполняет простые операции чтения/записи в db с использованием набора хранимых процедур. Я могу ограничить привилегии на SQL-сервере достаточно хорошо для этой комбинации входа/пользователя.

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

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

Я бы хотел использовать проверку подлинности на основе Windows ... SQL-аутентификация с двумя комбинациями пользователей и паролей не является вариантом.

Есть ли рекомендуемый способ достижения этого?

• Олицетворение в коде приложения, подключение к SQL Server с помощью встроенной системы безопасности от олицетворенного контекста (другой пользователь учетной записи/входа SQL) не нравится, так как я должен управлять второй логин/пароль
• SQL роли приложений сервера (требует приложения при условии, пароль я считаю) - действительно не нравится, так как мне нужно хранить пароли
• проверки подлинности SQL с двумя пользователями - не вариант
• создайте выделенные хранимые процедуры для «повышенного материала» и используйте execute as (должно работать, однако, не уверен, могу ли я создавать хранимые процедуры в целевом db)
• сложная идея: запустите процесс приложения, подключитесь к db, ограничьте приложение маркера, а затем открыть менее привилегированное соединение (будет работать?)
• использования COM + (a la Keith Brown's protocol transition), служба WCF или второй процесс для «повышенных» частей приложения (слишком сложных)

Я полагаю, что есть простое и аккуратное решение, которое мне не хватает ...

Answer 1

Использование подписи кода. Все ваши «повышенные» операции выполняются из хранимых процедур, которые подписаны, и доверие происходит от подписи процедуры. Это довольно эффективно и мощно, и чрезвычайно безопасный. Например, скажите, что вам нужен способ, я не знаю, создать очередь и службу, связанную с контрактом http://schemas.microsoft.com/SQL/Notifications/PostEventNotification. Таким образом, вы должны выполнить следующий код:

create queue myQueue; 
create service myService on queue myQueue (
[http://schemas.microsoft.com/SQL/Notifications/PostEventNotification]); 

Эти утверждения требует повышенных прав: CREATE QUEUE, CREATE SERVICE и справочником по договору EN.Вы можете включить эти заявления в процедуре, вы подписываете процедуру, создать пользователь из сертификата, используемого для входа процедуры, а затем вы предоставляете необходимые привилегии сертификата, полученного пользователь:

create procedure usp_createQueueAndService 
with execute as caller 
as 
begin 
    create queue myQueue; 
    create service myService on queue myQueue (
    [http://schemas.microsoft.com/SQL/Notifications/PostEventNotification]); 
end 
go 

create certificate [certificateToSign_usp_createQueueAndService] 
ENCRYPTION BY PASSWORD = 'Password#1234' 
with subject = 'Code signing for usp_createQueueAndService'; 
go 

ADD SIGNATURE TO OBJECT::[usp_createQueueAndService] 
BY CERTIFICATE [certificateToSign_usp_createQueueAndService] 
WITH PASSWORD = 'Password#1234'; 
go 

ALTER CERTIFICATE [certificateToSign_usp_createQueueAndService] 
REMOVE PRIVATE KEY; 
GO 

create user [certificateDerivedUser_usp_createQueueAndService] 
from certificate [certificateToSign_usp_createQueueAndService]; 
go 

grant create queue to [certificateDerivedUser_usp_createQueueAndService]; 
grant create service to [certificateDerivedUser_usp_createQueueAndService]; 
grant references on 
    contract::[http://schemas.microsoft.com/SQL/Notifications/PostEventNotification] 
    to [certificateDerivedUser_usp_createQueueAndService]; 
go 

Это 100% пуленепробиваемая безопасность. Все вызывающие, которые предоставили разрешение EXECUTE для процедуры, теперь могут создавать очередь и службу, потому что сама процедура получает необходимые права через подпись. Никто не может изменить процедуру, потому что ALTERing процедура теряет подпись и, таким образом, теряет привилегии. Никто не может злоупотреблять сертификатом, чтобы подписать другую процедуру, потому что закрытый ключ был сброшен и навсегда потерян (закрытый ключ не нужен для подтвердите существующих подписей).

Эта модель может быть расширена до любых привилегий, в которых вы нуждаетесь, включая привилегии на сервере (требуется регистрационный логин вместо пользователя, см. Signing and Activated Procedure).

Конечно, вы можете иметь usp_createQueueAndService принять имя очереди и службы как параметры, я оставил эту часть как простое упражнение для читателя. Если вы хотите играть с уведомлениями о событиях, такие упражнения должны быть тривиальными для вас;)

Answer 2

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

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