MS_ResourceAccessStrategy

リソース アクセス ストラテジ

• 戻る（アカウント、アーキテクチャ設計）
  • リソース アクセス ストラテジ
  • 委任
  • SPN

概要

クライアントからWebサーバにアクセスした際に
Webサーバ上の各種リソースに「誰として」アクセスを行なうのかの方式。

推奨のセキュリティ モデル

推奨のセキュリティ モデルには以下のものがある。

• サーバ信頼セキュリティ モデル
• ベース クライアント セキュリティ モデル

セキュリティ モデルの比較表

基本

比較項目	サーバ信頼セキュリティ モデル	ベース クライアント セキュリティ モデル
前提条件	なし	あり ・Active Directoryドメイン環境 ・認証処理に必要なポートを開放 ・サーバは「偽装」と「委任」が必要（性能に影響）
エンドユーザの直接アクセス	不可	可
エンドユーザ名の把握	造り込めば把握可能	認証ユーザとして把握可能
アクセス許可制御	造り込めば制御可能	認証ユーザのアクセス許可制御（管理の複雑化）
監査ログ	造り込めば制御可能	認証ユーザを監査する
設定	容易	複雑
技術的問題	なし	組み合わせによっては不可能
適合するシステム	殆どのシステム	完全な監査ログの取得が望まれるシステム（シングルベンダ）

データプロバイダ

（ADO.NETデータプロバイダ: MS_ADONETDataProvider.md）

比較項目	サーバ信頼セキュリティ モデル	ベース クライアント セキュリティ モデル
コネクション プーリングの利用	可	不可（性能に影響）

※ ベース クライアント モデルでは、接続文字列に含まれる資格情報が
ユーザごとに異なるため、コネクション プールがユーザ単位に分断される。
これが「コネクション プーリングの利用：不可（性能に影響）」の理由。

補足（最新化）: 元 Wiki が挙げている「偽装＋委任」による ベース クライアント セキュリティ モデルは、Windows 統合認証が前提。 クラウド／SPA／モバイルを含む現在の構成では、 OAuth 2.0 / OpenID Connect のトークンを用いた On-Behalf-Of フローが 同じ課題（下流リソースにエンドユーザとしてアクセスする）に対する一般的な解になる。 一方で「サーバ信頼モデル＋アプリ側で監査ログを造り込む」構成が 大半のシステムに適合する、という原文の判断は現在も妥当。

参考

• Microsoft patterns & practices セキュリティ ガイダンス
• ［How To］：ASP.NET 2.0で偽装と委任を使用する方法

---

Tags: アーキテクチャ, セキュリティ, アカウント, Windows