状況によっては、サーバー アプリケーションは、クライアントの代わりにアクセスするリソースにクライアントの ID を提示する必要があります。通常は、クライアントの ID に対してアクセス チェックまたは認証を実行する必要があります。 一定の範囲で、サーバーはクライアントの ID (クライアントの偽装と呼ばれるアクション) の下で動作できます。
偽装 は、スレッドを所有するプロセスとは異なるセキュリティ コンテキストで実行するスレッドの機能です。 サーバー スレッドは、クライアントの資格情報を表すアクセス トークンを使用します。これにより、クライアントがアクセスできるリソースにアクセスできます。
偽装を使用すると、サーバーはクライアントが実行できる操作を正確に実行できます。 クライアントが実行するアクセス許可に応じて、リソースへのアクセスが制限または拡張される場合があります。
データベースに接続するときにサーバーがクライアントの権限を借用し、データベースがクライアント自体を認証および承認できるようにすることもできます。 または、アプリケーションがセキュリティ記述子で保護されているファイルにアクセスし、クライアントがこれらのファイル内の情報への承認されたアクセスを取得できるようにする場合、アプリケーションはファイルにアクセスする前にクライアントを偽装できます。
偽装を実装する方法
偽装には、クライアントとサーバーの両方 (場合によってはシステム管理者) による参加が必要です。 クライアントは、サーバーが ID を使用できるようにする意欲を示す必要があり、サーバーはクライアントの ID をプログラムによって明示的に想定する必要があります。 詳細については、「偽装 Client-Side 要件」および「偽装 のServer-Side 要件」のトピックを参照してください。
Delegate-Level 偽装の管理要件
最も強力な形式の偽装 委任(ネットワーク経由のクライアントの偽装) を効果的に使用するには、次のように、クライアントとサーバーのユーザー アカウントを Active Directory サービスで適切に構成してサポートする必要があります (委任レベルの偽装を行う権限をクライアントに付与することに加えて)。
- サーバー ID は、Active Directory サービスで "委任に対して信頼済み" としてマークされている必要があります。
- Active Directory サービスでは、クライアント ID を "アカウントは機密性が高く、委任できません" としてマークすることはできません。
これらの構成機能により、ドメイン管理者は委任を高度に制御できます。これは、どの程度の信頼 (そのためセキュリティ リスク) が関係しているかを考えると望ましいものです。 委任の詳細については、「委任と偽装の」を参照してください。
クローキング
クライアントが権限借用レベルを通じてサーバーに付与する権限と共に、サーバーのクローキング機能によって、偽装の動作が大きく決まります。 クローキングは、クライアント自身またはクライアントに代わって呼び出しを行うときに、サーバーによって実際に提示される ID に影響します。 詳細については、クローキングを参照してください。
パフォーマンスへの影響
偽装は、パフォーマンスとスケーリングに大きな影響を与える可能性があります。 通常、呼び出しでクライアントを偽装する方が、直接呼び出しを行うよりもコストがかかります。 考慮すべき問題の一部を次に示します。
- 特に動的クローキングが有効になっている場合に、複雑なパターンで ID を渡す計算オーバーヘッド。
- 中間層で一元的に行うのではなく、多数の場所で冗長なセキュリティ チェックを適用する一般的な複雑さ。
- データベース接続などのリソースは、クライアントを偽装して開いたときに、複数のクライアントで再利用することはできません。これは、スケーリングの妨げとなる非常に大きな障害です。
場合によっては、問題の唯一の効果的な解決策は偽装を使用することですが、この決定は慎重に検討する必要があります。 これらの問題の詳細については、多層アプリケーション セキュリティ を参照してください。
キューに登録されたコンポーネント
キュー コンポーネント 偽装はサポートされていません。 クライアントがキューに登録されたオブジェクトを呼び出すと、実際にはレコーダーが呼び出され、メッセージの一部としてサーバーにパッケージ化されます。 その後、リスナーはキューからメッセージを読み取り、それをプレーヤーに渡します。これにより、実際のサーバー コンポーネントが呼び出され、同じメソッド呼び出しが行われます。 そのため、サーバーが呼び出しを受信すると、偽装によって元のクライアント トークンを使用できなくなります。 ただし、ロールベースのセキュリティは引き続き適用され、ISecurityCallContext インターフェイスを使用したプログラムによるセキュリティが機能します。 詳細については、「キューに登録されたコンポーネントのセキュリティ をする」を参照してください。
関連トピック
-
多層アプリケーション セキュリティ の
-
プログラム によるコンポーネントセキュリティ の
-
COM+ でのソフトウェア制限ポリシーの使用の