適用対象:
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を呼び出す必要があります。
次の C# の例は、SqlContext.WindowsIdentity プロパティを使用して呼び出し元を偽装する方法を示しています。
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;
}
Note
偽装での動作の変更については、「SQL Server 2016のデータベース エンジン機能の破壊的変更」を参照してください。
さらに、Windows ID インスタンスを取得した場合、既定では、そのインスタンスを別のコンピューターに伝達することはできません。Windows セキュリティ インフラストラクチャでは、既定で制限されます。 ただし、委任 と呼ばれるメカニズムがあり、複数の信頼されたコンピューター間で Windows ID を伝達できます。 委任の詳細については、「Kerberos プロトコルの移行と制約付き委任の」を参照してください。
関連コンテンツ
- SqlContext オブジェクト を
する