Подмена личности и безопасность интеграции CLR

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

Поставщик доступа к данным в процессе предоставляет интерфейс программирования приложений, SqlContext.WindowsIdentityкоторый можно использовать для получения маркера, связанного с текущим контекстом безопасности. Управляемый код и EXTERNAL_ACCESSUNSAFE сборки могут использовать этот метод для извлечения контекста и использования метода .NET Framework WindowsIdentity.Impersonate для олицетворения этого контекста. Следующие ограничения применяются при явном олицетворения пользовательского кода:

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

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

• Для управляемого кода, выполняющегося асинхронно (например, с помощью UNSAFE сборок создания потоков и асинхронного выполнения кода), доступ к данным в процессе никогда не допускается. Это верно, есть ли олицетворение.

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

Оба EXTERNAL_ACCESS сборки и UNSAFE сборки получают доступ к ресурсам операционной системы с учетной записью службы SQL Server, если они не добровольно олицетворяют текущий контекст безопасности, как описано ранее. Из-за этого авторы EXTERNAL_ACCESS сборок требуют более высокого уровня доверия, чем SAFE те сборки, которые задаются разрешением EXTERNAL ACCESS на уровень входа. Необходимо предоставить EXTERNAL ACCESS разрешение только для входа, доверенных для выполнения кода в учетной записи службы SQL Server.

См. также

Безопасность интеграции со средой CLR
Олицетворение и учетные данные для подключений