Repository navigation
MS_ResourceAccessStrategy
nishi_74322014 edited this page Aug 12, 2026
·
2 revisions
クライアントからWebサーバにアクセスした際に
Webサーバ上の各種リソースに「誰として」アクセスを行なうのかの方式。
推奨のセキュリティ モデルには以下のものがある。
| 比較項目 | サーバ信頼セキュリティ モデル | ベース クライアント セキュリティ モデル |
|---|---|---|
| 前提条件 | なし | あり ・Active Directoryドメイン環境 ・認証処理に必要なポートを開放 ・サーバは「偽装」と「委任」が必要（性能に影響） |
| エンドユーザの直接アクセス | 不可 | 可 |
| エンドユーザ名の把握 | 造り込めば把握可能 | 認証ユーザとして把握可能 |
| アクセス許可制御 | 造り込めば制御可能 | 認証ユーザのアクセス許可制御（管理の複雑化） |
| 監査ログ | 造り込めば制御可能 | 認証ユーザを監査する |
| 設定 | 容易 | 複雑 |
| 技術的問題 | なし | 組み合わせによっては不可能 |
| 適合するシステム | 殆どのシステム | 完全な監査ログの取得が望まれるシステム（シングルベンダ） |
| 比較項目 | サーバ信頼セキュリティ モデル | ベース クライアント セキュリティ モデル |
|---|---|---|
| コネクション プーリングの利用 | 可 | 不可（性能に影響） |
※ ベース クライアント モデルでは、接続文字列に含まれる資格情報が
ユーザごとに異なるため、コネクション プールがユーザ単位に分断される。
これが「コネクション プーリングの利用：不可（性能に影響）」の理由。
補足（最新化）: 元 Wiki が挙げている「偽装＋委任」による ベース クライアント セキュリティ モデルは、Windows 統合認証が前提。 クラウド／SPA／モバイルを含む現在の構成では、 OAuth 2.0 / OpenID Connect のトークンを用いた On-Behalf-Of フローが 同じ課題（下流リソースにエンドユーザとしてアクセスする）に対する一般的な解になる。 一方で「サーバ信頼モデル＋アプリ側で監査ログを造り込む」構成が 大半のシステムに適合する、という原文の判断は現在も妥当。
Tags: アーキテクチャ, セキュリティ, アカウント, Windows
このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。