接続の権限借用と資格情報

  • [アーティクル]

適用対象:SQL Server

SQL Server共通言語ランタイム (CLR) 統合では、Windows 認証の使用は複雑ですが、SQL Server認証を使用するよりも安全です。 Windows 認証を使用する場合には、次の点を考慮してください。

Windows に接続する SQL Server プロセスは、SQL Server Windows サービス アカウントのセキュリティ コンテキストを既定で取得します。 ただし、CLR 関数をプロキシ ID にマッピングすることにより、その発信接続に対し、Windows サービス アカウントとは異なるセキュリティ コンテキストを設定することができます。

場合によっては、サービス アカウントとして実行するのではなく 、SqlContext.WindowsIdentity プロパティを使用して呼び出し元を偽装することが必要になる場合があります。 WindowsIdentity インスタンスは、呼び出し元のコードを呼び出したクライアントの ID を表し、クライアントが Windows 認証を使用した場合にのみ使用できます。 WindowsIdentity インスタンスを取得したら、Impersonate を呼び出してスレッドのセキュリティ トークンを変更し、クライアントの代わりに ADO.NET 接続を開くことができます。

SQLContext.WindowsIdentity.Impersonate を呼び出した後は、ローカル データにアクセスできず、システム データにアクセスできません。 データに再度アクセスするには、WindowsImpersonationContext.Undo を呼び出す必要があります。

次の例は、 SqlContext.WindowsIdentity プロパティを使用して呼び出し元を偽装する方法を示しています。

Visual C#

WindowsIdentity clientId = null;  
WindowsImpersonationContext impersonatedUser = null;  
  
clientId = SqlContext.WindowsIdentity;  
  
// This outer try block is used to protect from   
// exception filter attacks which would prevent  
// the inner finally block from executing and   
// resetting the impersonation.  
try  
{  
   try  
   {  
      impersonatedUser = clientId.Impersonate();  
      if (impersonatedUser != null)  
         return GetFileDetails(directoryPath);  
         else return null;  
   }  
   finally  
   {  
      if (impersonatedUser != null)  
         impersonatedUser.Undo();  
   }  
}  
catch  
{  
   throw;  
}

注意

偽装での動作の変更については、「SQL Server 2016 のデータベース エンジン機能の破壊的変更」を参照してください。

さらに、Microsoft Windows ID インスタンスを取得した場合、既定では、そのインスタンスを別のコンピューターに伝達することはできません。Windows セキュリティ インフラストラクチャでは、既定で制限されています。 ただし、"委任" というメカニズムを使用すると、信頼関係のある複数のコンピューターに Windows ID を反映できるようになります。 委任の詳細については、TechNet の記事「Kerberos プロトコルの移行と制約付き委任」を参照してください。

参照

SqlContext オブジェクト