.NETエンタープライズ Webアプリケーション開発技術大全 Webアプリケーションのセキュリティデザイン基礎 マイクロソフト コンサルティング本部 赤間 信幸 2004/09/16

Page1 Page2 Page3 Page4

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

　実際のWebシステムでは、前述した認証と許可制御に加えて、さらにリソースアクセスストラテジについても検討を行う必要がある。

　例えば、図1-8のような物理2階層型システムについて考えてみよう。SQL Serverをはじめとする各種のDBサーバは、それ自身もWebサーバとは別の認証・許可制御機能を持っている。このため、WebサーバからさらにDBサーバにアクセスするためには、DBサーバから改めて認証を受けなければならない。

図1-8 物理2階層型システムにおけるリソースアクセスストラテジ

　さて、この図1-8においてDBサーバにアクセスしているのは、直接の対話相手である「Webサーバ」であるともみなせるし、あるいはベースクライアント※10である「Aさん」であるともみなせる。このため、WebサーバからDBサーバをはじめとする各種のリソースにアクセスする際には、「誰として」アクセスを行うのかをあらかじめ決めておかなければならないのである。この選択のことを、リソースアクセスストラテジと呼ぶ。

※10 リクエストの発生源となっているクライアントのことをベースクライアントと呼ぶ。通常のWebシステムの場合には、エンドユーザに相当する。以下、文脈により「ベースクライアント」と「エンドユーザ」の2つの単語を使い分けているが、分かりにくければとりあえずは同じものと考えて適宜読み替えて頂いても構わない。

1.4.1 2つのリソースアクセスストラテジ

　前述の2つのリソースアクセスストラテジは、それぞれ「サーバ信頼セキュリティモデル」、「ベースクライアントセキュリティモデル」と呼ばれている※11※12。

※11 これらはpatterns & practicesのガイドラインの中ではそれぞれ信頼サブシステムモデル（Trusted Subsystem Model）、偽装/委任モデル（Impersonation / Delegation Model）と呼ばれている。 ※12 解説を分かりやすくするため、上記の物理2階層型Webシステムを例にとって説明するが、物理3階層型システムの場合にも考え方は変わらない。

A. サーバ信頼セキュリティモデル

　DBサーバに対して、「Webサーバとして」アクセスするモデルである。この戦略を採用した場合には、図1-9のように、ベースクライアントが誰であろうとも、常に固定的なユーザアカウントを使ってDBサーバにアクセスすることになる。

図1-9 サーバ信頼セキュリティモデルによるリソースへのアクセス

B. ベースクライアントセキュリティモデル

　DBサーバに対して、「ベースクライアントとして」アクセスするモデルである。この戦略を採用した場合には、図1-10のように、ベースクライアントに応じて、接続に利用するユーザアカウントを切り替えながらDBサーバにアクセスすることになる。

図1-10 ベースクライアントセキュリティモデルによるリソースへのアクセス

　このように、リソースアクセスストラテジには2通りの選択肢が存在するが※13、ほとんどの物理2階層型Webシステムでは、サーバ信頼セキュリティモデルが利用されている。

※13 なおWindows系でのシステムの場合には、ここに述べた2通りのアクセスIDの選択に加えて、利用する認証方式の選択方法（Windows統合認証あるいは非Windows統合認証）を加味し、2×2 = 4通りの選択肢の中から選択することになる。詳細は「2.4.4 実際のシステムにおけるリソースアクセスストラテジの選択方法」を参照のこと。

1.4.2 サーバ信頼セキュリティモデルを採用する理由

　サーバ信頼セキュリティモデルを採用するメリットのうち、特に重要なものは以下の3つである。

・ パフォーマンス、スケーラビリティに優れる
	・ 常に接続アカウントが同一であるため、Webアプリケーション上でコネクションプーリングを利用することができる。
	・ データベース製品やアプリケーション特性にも依存するが、一般的にはコネクションプーリングの利用可否によりパフォーマンスやスケーラビリティが大きく変わる。
・ バックエンドリソース（DBサーバ）の認証・許可制御の設定作業が容易である
	・ ベースクライアントセキュリティモデルでは、DBサーバ上でのロール定義やユーザ管理などが複雑化しやすい。
	・ サーバ信頼セキュリティモデルの場合、Webサーバ上で主だった業務的セキュリティ制御が行われるため、DBサーバ上での設定作業は比較的少なくて済む。
・ エンドユーザのバックエンドリソース（DBサーバ）に対する直接アクセスを防げる
	・ ベースクライアントセキュリティモデルを利用する場合、設定方法によってはエンドユーザが直接DBサーバにアクセスできてしまう恐れがある。ネットワーク構成の工夫などにより、これを防がなければならない。

　半面、デメリットとしては以下のような点が挙げられる。

・ DBサーバ上での完全な監査ログが取得できない
	・ DBサーバ上で、実行されたSQL文と実行ユーザを記録する（監査ログを取る）場合、サーバ信頼セキュリティモデルではエンドユーザ名を記録することができない。
・ DBサーバ側の立場からすると、Webアプリケーションの作りを完全に信頼する必要がある
	・ DBサーバ上でエンドユーザ名が必要な場合には、パラメータとして明示的に引き渡す必要がある※14。

　

※14 例えば以下のように、ストアドプロシージャのパラメータの1つとしてエンドユーザ名を引き渡す方法が考えられる。sp_SelectAuthors('123-4567', 'Nobuyuki')

　サーバ信頼セキュリティモデルにもデメリットはあるが、ベースクライアントセキュリティモデルにはパフォーマンスやスケーラビリティの問題、および技術的な制約などが数多くあること※15から、ほとんどの物理2階層型Webシステムではサーバ信頼セキュリティモデルが利用されている（図1-11）。

※15 特に偽装/委任を利用する場合には注意が必要である。詳細はpatterns & practices 「セキュリティ保護されたASP.NET アプリケーションの構築: 認証、認定、および通信のセキュリティ保護」（http://www.microsoft.com/japan/msdn/net/security/SecNetch03.asp）の「第3章認証と認定」のリソースアクセスモデルの選択の項を参照のこと。

　

図1-11 サーバ信頼セキュリティモデルのメリットとデメリットのまとめ

　参考までに、サーバ信頼セキュリティモデルとベースクライアントセキュリティモデルの比較を表1-4に示す。本書では、これらのうちサーバ信頼セキュリティモデルに絞った解説を行うが、ベースクライアントセキュリティモデルが必要とされる場合には、patterns & practicesをはじめとする各種のガイドライン類を参照して頂きたい。

	サーバ信頼セキュリティモデル	ベースクライアント セキュリティモデル
コネクションプーリングの利用	可	不可
DB へのエンドユーザの直接アクセス	不可	可であるため、何らかの対策が必要
DB 上におけるエンドユーザ名の把握	クエリなどを利用した明示的な引渡しが必要	認証したユーザ名として把握することができる
DB 上での監査ログの取得	ベースクライアント名を記録できない	ベースクライアント名まで含めて記録できる
DB 上での許可制御の利用	粗い粒度でしかかけられず、基本的には Web アプリ上行われた許可制御を信頼する必要がある	ベースクライアントに応じた許可制御が可能なので、水際での歯止めが可能
DB 上の許可制御設定の維持	簡単	複雑
技術的な問題点	ほとんどない	利用する認証方式によっては利用できないケースがある
適したシステムの例	一般的な物理 2 階層型の Web システム	完全な監査ログの取得が要求される、金融系システムなどの一部のシステム
表1-4 2つのリソースアクセスストラテジの比較

1.4.3 実際のシステムにおけるサーバ信頼セキュリティモデルの使われ方

　サーバ信頼セキュリティモデルとは、図1-12のようにWebサーバとDBサーバを図太いパイプでつないでしまうようなものである。これをそのままの形で実際のシステムに適用すると、「Webアプリからは何でもできてしまう」状態になり、非常に危険である※16。

※16 その中でも、ユーザ情報（顧客情報）を格納したテーブルに対するアクセスに関しては危険度が高いため、きちんと制限をかけておくべきである。万が一、個人情報が漏洩した場合の打撃は計り知れないものがある。具体的な方法については、「第3章　SQL Serverデータベースセキュリティ基礎」を参照のこと。

　

図1-12 完全なサーバ信頼セキュリティモデルの危険性

　このため実際のシステムでは、サーバ信頼セキュリティモデルを利用する場合であっても、DBサーバへの接続アカウントを複数個用意し、適宜使い分けることもある。例えば図1-13のように、エンドユーザのロールに応じて接続アカウントを切り替えるようにし、データベース上で、個々の接続アカウントごとに読み書き可能な範囲を絞っておくと、Webアプリケーション内部にバグや問題があった場合のリスクを多少なりとも軽減することができる。

図1-13 ロールごとに接続アカウントを切り替えたサーバ信頼セキュリティモデル

　昨今よく問題となっている顧客情報の漏洩に関しても、顧客マスタテーブルへのアクセスが完全にフリーになっている状況は安全とはいえない※17。図1-14にあるように、顧客マスタテーブルには専用の接続アカウントでないとアクセスできないようにし、普段利用する接続アカウントとは分けておくといった工夫も有効であろう※18。

※17 このような構成は、特に複数の企業やベンダが集まって合同でアプリケーションを開発している場合や、各チームが開発したアプリケーションを比較的自由にホスティングできるようなシステムの場合に良く見られる。 ※18 ただし、この方式を採用する場合でも細かく接続アカウントを分離しすぎないように注意する。接続アカウントを細かく分けすぎると、アプリケーション開発が面倒になる。利用するとしても、顧客情報やユーザデータベースのように、特に情報セキュリティを確保したい部位に限ってピンポイント的に利用するのが望ましい。また、図中ではテーブル単位に接続アカウントを分けているが、同一SQL Server内に複数のデータベースを用意し、それぞれに各テーブルを分けて入れておき、データベース単位に接続アカウントを使い分けるという方法もある。

　

図1-14 アプリケーション内部の部位によって接続アカウントを切り替えるサーバ信頼セキュリティモデル

　システムのセキュリティ要求レベルにも依存するが、いずれにせよ、完全なベースクライアントセキュリティモデルと完全なサーバ信頼セキュリティモデルのみで考えるのは危険である。これらに適宜アレンジを加えながら、最小特権の原則※19になるべく近づけるようにアプリケーションを設計することが望ましい。

※19 アプリケーションやシステムを設計する際のセキュリティ原則の1つ。そのアプリケーションやシステムが必要とする「最小限」の権限のみを与えるようにすることで、不正動作のリスクを軽減する。その他のセキュリティ原則については、本シリーズ第2巻「ASP.NET基礎編」の「第3部　セキュアプログラミング」を参照のこと。

　

INDEX
	.NETエンタープライズWebアプリケーション 開発技術大全
	Webアプリケーションのセキュリティデザイン基礎
	1．Webアプリケーションのセキュリティデザイン基礎
	2．認証（Authentication）と許可制御（Authorization）
	3．ロールベースセキュリティ（RBS）／リソースアクセスストラテジ
	4．Webサーバにおけるセキュリティデザインの構成要素

　

「.NETエンタープライズWebアプリケーション開発技術大全」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）