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

Page1 Page2 Page3 Page4

1.2 認証（Authentication）と許可制御（Authorization）

　業務的なセキュリティ制御とは「あるユーザがある作業を行ってよいのか否かを判断すること」であるが、この判断は、実際には以下の2段階に分けて実施される※4（図1-5）。　

・ 認証（Authentication）
	・ 作業を行おうとしているユーザが、確かに本人であることを確認すること。
・ 許可制御（Authorization）※5
	・ そのユーザが、実際に作業を行ってよいのか否かを確認すること。

　

※4 AuthenticationとAuthorizationの2つの英単語はさまざまなところに現れるため、日本語だけでなく英語でも覚えておくとよい。また、これらの単語は海外では「AuthN」や「AuthZ」などと略されて書かれていることも多い。

※5 許可制御（Authorization）は、「認定」「認可」「承認」「許可」と呼ばれることもある（.NET Frameworkのドキュメント内やMSDNドキュメント内でも訳語にブレがある）。これらの単語は別の意味を想起しやすく、他の訳語と重なる場合もあるため、本書では最も誤解の恐れが少ない訳語として「許可制御」という訳語を利用することにした。

　

図1-5 認証と許可制御の流れ

　この2つのステップのどちらで失敗しても結果はアクセス拒否となるが、両者は本質的に別物である。例えば以下のような例を考えてみて欲しい。

・ 本人を確認する方法は一通りとは限らない
	・ 本人を確認する手段として最も代表的な手段はパスワード確認であるが、これ以外にもデジタル証明書を利用する、代理人による証明など、いくつかの確認手段があるはずである。
・ 許可制御のタイミングでは、パスワード情報は要らない
	・ 許可制御には「当該ユーザが誰なのか」さえ分かれば十分であり、パスワードなどの本人確認情報は不要である。

　このように、ユーザの業務的なセキュリティ制御は、「認証」と「許可制御」の組み合わせによって実施されている。

　なおセキュリティ関連の専門書では、より一般的な用語として表1-2のような単語が利用される場合もある。本書では馴染みやすい単語である「ユーザ」と「パスワード」を利用するが、他のリファレンスマテリアルを参照する場合には注意する必要がある。

用語	意味	主な例	単に言うと…
プリンシパル	セキュリティ制御において「主体」となるもののこと。	ユーザ、コンピュータ、アプリケーションなど。	ユーザ、またはその名前
クレデンシャル	プリンシパルの正当性を証明するもの。	パスワード、デジタル証明書、トークン、チケットなど。	パスワード情報
表1-2 セキュリティの専門用語との対応関係

1.3 ロールベースセキュリティ（RBS）

　次に、許可制御の際に利用される「ロール」について解説する。

1.3.1 許可制御（Authorization）とロール（Role）

　一般的に、ユーザアプリケーションにおける許可制御（ある業務を行ってよいか否か）は、ユーザそのものではなく、そのユーザが所属するグループ情報によって確認される。この業務的なセキュリティ制御のために利用されるユーザグループのことを、ロールと呼ぶ。

図1-6 ロールに基づいた許可制御の例

　図1-6のように、エンドユーザをグループ化したロールを用いて業務的な許可制御を行うことを、ロールベースセキュリティ（Role-based Security、RBS）と呼ぶ※6。許可制御をエンドユーザ個人単位で行うのではなく、グループ単位で制御することにより、運用時のエンドユーザの追加や削除といった作業を簡単にするわけである。

※6 これに対して、ユーザアプリケーションの身元（製造者やファイルのダウンロード元など）に基づいてその挙動に制限を加えるセキュリティ制御のことを、コードアクセスセキュリティ（Code Access Security、CAS）と呼ぶ。.NET Frameworkには全くコンセプトの異なる、RBSとCASの2種類のセキュリティ制御を持っており、場合により使い分けられたり、併用されたりする。Webアプリケーションの業務的セキュリティ制御はRBSにより行われるため、本書ではCASの解説は行わない。CASの概要については本シリーズ第1巻「.NET Framework導入編」を、その詳細については製品ドキュメントやpatterns & practicesガイドラインを参照のこと。

　なおユーザアプリケーションを作るにあたり、どのようなロールが必要となるのかを検討するのはドメインエキスパート（業務SE）のミッションである。ドメインエキスパートは業務設計と並行して、表1-3のような業務の実施可否を決定するマトリクスを作成しなければならない。

		業務
		ユーザ管理業務	経費申請業務	経費承認業務
ロール	システム管理者グループ	○	×	×
	一般ユーザグループ	×	○	×
	マネージャグループ	×	○	100 万円まで可
	シニアマネージャグループ	×	○	全額可
表1-3 ロール別の業務利用可否の設計例

　このようなロール設計に関しては、一般的に以下のような点に注意する必要がある。

• ロールの長期的な安定性
• フラットなロール構成

A. ロールの長期的な安定性

　詳細は後述するが、ユーザアプリケーション内で業務的なセキュリティ判断を行う場合には、プログラム中にリスト1-1のようなコードを記述することになる。通常、ここで利用されるロール名はプログラム中にハードコードされるため、アプリケーションリリース後に修正を加えることは困難である。

C#の場合 if (HttpContext.Current.User.IsInRole("Managers") == true) {    // ... マネージャにのみ許可される処理を実施する } VB.NETの場合 If (HttpContext.Current.User.IsInRole("Managers") = True) Then    ' ... マネージャにのみ許可される処理を実施する End If

リスト1-1 ロールに基づいた業務的なセキュリティ判断を行うコードの例

　また、運用開始後にロールの新規追加や削除が発生すると、既存のユーザ情報のメンテナンスが発生するため非常に面倒である。

　このように、ロールはアプリケーションの開発終了後に追加・削除することが困難である。アプリケーション設計時点で、「長期的に安定しており変更が加わりにくい」ようなロールを識別しておくことが重要となる※7。

※7 一般的に、ユーザのグルーピング方法（ロール設計）は業務設計時に検討が手薄になりがちな部分であり、また要件がなかなか固まりにくい部分でもある。その結果として、「後からでもロール（セキュリティグループ）を自由に追加・削除できる」といった業務設計をしがちである。しかし、そのような設計は実際の運用に耐えられないケースが多い。ロール情報（セキュリティグループ）のメンテナンスが、運用者にとって大きな負担にならないように、長期的に安定性の高いロールを正しく識別することが求められる。

B. フラットなロール構成

　アプリケーションのユーザ管理機能に拡張性を持たせるために、ロールの階層化やネストを可能とする設計※8を行うことはなるべく避けた方がよい。理由は以下の2つである。

• ロールをネスト可能として設計すると、ユーザ管理の自由度が高まる半面、運用担当者の実作業が複雑化する。また、ユーザ管理用のUI設計や実装も複雑化する

• ASP.NETをはじめとする多くのアプリケーションインフラは、ロールの階層化やネスト機能をサポートしていない

※8 例えば業務的な許可制御上、マネージャとシニアマネージャの2つが必要な場合でも、「シニアマネージャロールのメンバであれば自動的にマネージャロールのメンバとして取り扱われる」ような設計・実装はしないようにする。マネージャでありシニアマネージャであるユーザAさんについては、それぞれのロールに個別に登録を行う必要があるように設計する。

　以上から分かるように、ある程度の割り切りを行って必要十分なロール設計をすることが、ドメインエキスパートの腕の見せ所となる。ロール設計はオーバスペックになりがちなので、十分な注意を払う必要がある。

1.3.2 アプリケーションインフラが提供するロールベースセキュリティ（RBS）機能の活用

　さて、ロールベースセキュリティ（RBS）の制御機能をゼロから開発することは非常に大変であるが、Windows OSやJ2EEランタイム、ASP.NETランタイムなどには、RBSを効率的に実装するための機能があらかじめ用意されている。これらを利用すると、RBSを使った業務的セキュリティ制御機能を、比較的容易にアプリケーションに導入することができる。

　また、アプリケーションインフラが提供するRBS機能を利用すると、（条件次第ではあるが）自動的な認証情報のフローを行ってくれるケースもある。

　例えばASP.NET Webアプリケーションの場合、Webページ上で行われた認証（Authentication）の結果は、図1-7のように、HttpContextオブジェクトを利用して※9バックエンドのビジネスロジックコンポーネントやデータアクセスコンポーネントへと自動的に引き継がれる。このため、メソッドパラメータを用いて明示的にユーザ情報を引き渡さなくても、ビジネスロジックコンポーネントやデータアクセスコンポーネントの中から、エンドユーザの名前情報などを直接拾うことができる。これは、背後のコンポーネントの中でセキュリティ制御や監査処理を行おうとする際に非常に便利である。

※9 技術的な詳細については、第3巻「ASP.NET応用編」の「第2章　アプリケーションの状態管理」内のHttpContextに関する解説を参照のこと。

　つまり、アプリケーションインフラがRBS機能を提供している場合には、なるべくそれを活用してアプリケーションを設計・実装することが望ましい、というわけである。

図1-7 HttpContextオブジェクトによる暗黙的な認証結果の引継ぎ

　

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

　

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

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