連載 アプリケーション・アーキテクチャ設計入門 第4回　セキュリティ、運用管理、および通信のポリシーとその設計 日本ユニシス　猪股 健太郎 2003/12/20
Page1 Page2 Page3 Page4

（2）承認

　承認は、許される動作を制限する機構だ。コンポーネントがある機能を提供しているとき、コンポーネントの呼び出し元に対して本当にその機能を使わせてもいいのかを判定する。呼び出し元の身元は2種類の方法で確認する。すなわち、「正しいユーザーかどうか」と「正しいプログラムかどうか」の2種類だ。正しいユーザーによる操作であっても、コンピュータ・ウイルスに代表される「悪意のあるプログラム」が実行されているのであれば、機密データや重要な機能にアクセスさせてはならない。よって、「正しいユーザーかどうか」と「正しいプログラムかどうか」の両方のチェックに通って初めて承認は成功する。.NET Frameworkでは、「正しいユーザーかどうか」の確認機能として「ロールベース・セキュリティ」が、「正しいプログラムかどうか」の確認には「コード・アクセス・セキュリティ」が提供されている。

　承認のロジックは、場合によっては複雑なものになる。例えば、「注文は、呼び出し元が“セールスマン”の役割にあるか、サービスがパートナー企業から呼び出されていて注文額が1000ドルを超えない場合か、または呼び出し元が“管理職”以上の役割である場合に成功する」などである。このように複雑なルールはアプリケーションのコードで実現するべきだろう。もっと簡単な場合はカスタム属性やアプリケーション構成などで実現できる。

●独自の承認機構

　承認情報をアプリケーションのデータ・ストアに保持する場合は、セキュリティ管理のユーザー・インターフェイスを提供する必要があるだろう。その際は以下のガイドラインに従うべきである。

• すべての承認ロジックはPrincipalオブジェクトを通して公開する。.NET Frameworkでは、アイデンティティのロールに基づく承認は、IPrincipalインターフェイスのIsInRoleメソッドを利用することになっているためである

• 承認情報のデータ・ストアへのアクセスは必ず認証する。通常のアカウントでは読み出し専用のアクセスにすべきだ

• Windows認証を使わないのであれば、承認情報のデータからユーザーIDやクレデンシャルを分離しておく

• パフォーマンスのために、承認情報をキャッシュせよ

• ネットワークに接続していないクライアントでも動作するようにせよ

• 承認のロジックは容易に取り替えられるようにせよ

• 自分のアセンブリだけがPrincipalオブジェクトを生成・利用できるようにするためにStrongNameIdentityPermission属性を使う

●信頼するアプリケーションやサービスでのユーザーとロール

　別のアプリケーションやサービスとやりとりする場合は、ユーザー・アカウントの定義とロールの定義は分けておくべきである。「一般パートナー」や「特別パートナー」といったロールを準備しておけば、呼び出し元の認証機構が変わったときにもスムーズに対応できる。もしあなたのサービスが外部のサービスとユーザー・アカウントを共有するのであれば、ユーザー情報はビジネス情報の一部として取り扱われるべきである。もしもビジネス情報が特定のユーザーから送られてきたことを確認したいのであれば、ビジネス情報に認証トークンを含めたり、ドキュメントにデジタル署名をしたりする必要があるだろう。

●各コンポーネントにおける承認の設計と実装

−プレゼンテーション層−

　ユーザー・インターフェイス・コンポーネントでは「特定のデータ・フィールドを表示するかどうか」および「特定の入力コントロールを操作させるかどうか」を承認することになるだろう。そして、ユーザー・プロセス・コンポーネントでは「特定のユーザー・プロセスを開始するかどうか」および「一連のユーザー･プロセスの中で特定の処理を省略するかどうか」を承認することになる。理想的には、ユーザー・インターフェイス・コンポーネントで特定のコントロールを利用不可にしておけばユーザー・プロセス・コンポーネントでの承認は不要になる。しかし現実的には、安全のためにユーザー・プロセス・コンポーネントでも承認を行うことになるだろう。

−ビジネス層−

　ビジネス・コンポーネントとビジネス・ワークフローでは、以下の3つに従う。

• アプリケーション・コンテキストに依存しない承認にすること

• ユーザーのアカウントではなく、ロールに基づいて承認すること

• メソッドにPrincipalPermission属性を適用する場合は、Identityオブジェクトで認証のタイプを確認すること

　サービス・インターフェイスで承認を実装する場合は、XML WebサービスであればASP.NETの認証機構が、メッセージ・キューであればWindowsのACL（アクセス・コントロール・リスト）が利用できる。

　ビジネス・エンティティ・コンポーネントで承認を実装する場合は、現在のアプリケーション・コンテキストを利用する。ただし、ビジネス・エンティティ・コンポーネントが内部的に呼び出すビジネス層やデータ層のコンポーネントでも承認する。

−データ層−

　完全には信頼できないビジネス・プロセスの開発者とデータ・アクセス・ロジック・コンポーネントを共有する場合や、データ･ストアが提供する強力な機能を制限したい場合は、この層で承認を実装する。

　データ・アクセス・ロジック・コンポーネントがデータ・ストアとセキュリティ・コンテキストを共有する場合は、データ・ストアの承認機構が利用できる。ただし、データ・ストアの承認機構を利用できるのは、データ・ストアへのアクセスで異なるロールを使い分けるか毎回偽装するかのどちらかの場合に限る。

（3）安全な通信

　ユーザーの認証や要求の承認に加えて、異なる物理層（ティア）間での通信を安全に保つ必要がある。安全な通信には、「通信チャネルをすべて安全に保つ」方法と、「データを安全に保つ」方法とに分けられる。

通信を安全に保つ2つの方法

安全な通信には、「通信チャネルをすべて安全に保つ」方法と、「データを安全に保つ」方法の2つがある。

　前者は、SSL、IPSec、暗号化を実装する独自の.NETリモート処理チャネル、そしてVPNなどが挙げられる。後者は、署名、メッセージ全体の暗号化、一部データの暗号化などが挙げられる。通信チャネルを安全に保つことはパフォーマンスに影響を与えるので、特別に高いセキュリティを確保しなければならない一部の通信に限ることを検討するのがよいだろう。

　各コンポーネントにおける実装において、特に注意すべきなのはデータ・アクセス・ロジック・コンポーネントだ。このコンポーネントで安全な通信を実現したい場合は、データアクセス・ヘルパー・コンポーネントを用意し、安全な通信のためのロジックを隠ぺいするとよい。

（4）プロファイル管理

　アプリケーションの振る舞いをユーザーに応じてカスタマイズするためには、ユーザーのプロファイルを必要とする。ユーザーのプロファイルにはPrincipalオブジェクトを通してアクセスするようにする。アプリケーションをオフラインで利用するためにはプロファイル情報をキャッシュしなければならないが、重要なデータは暗号化したりハッシュを取ったりして、データの漏えいや改ざんを防ぐようにする。

（5）監査

　監査は「安全なロギング」と見なすこともできる。つまり、確実にログを取ることでアプリケーションが不正な動作をしなかったかを確認することが監査である。もし独自の監査機構を実装するのであれば、監査ログが書き換え不能であるか、少なくとも不正な監査ログを確実に発見できる仕組みが必要である。

　監査のためのインターフェイスはユーティリティ・コンポーネントの機能として提供するか、Principalオブジェクトの機能として提供する。

　プレゼンテーション層での監査は、通常はセキュリティ例外だけを対象にすればよい。ビジネス層での監査は、ビジネス・プロセスと独立したトランザクションを利用し、ビジネス・プロセスがロールバックされても監査ログが残るようにする。データ層での監査はビジネス層と同様だが、場合によってはデータ・ストアの内部でも監査を行う。データ・ストアとしてSQL Server 2000を使っているのであれば、MSDNの「SQL Server 利用状況の監査」を参照のこと。

INDEX
	[連載] アプリケーション・アーキテクチャ設計入門
	第4回　セキュリティ、運用管理、および通信のポリシーとその設計
	1．セキュリティ・ポリシーに関する設計：認証
	2．セキュリティ・ポリシーに関する設計：承認、安全な通信、プロファイル管理、監査
	3．運用管理ポリシーに関する設計
	4．通信ポリシーにおける非同期通信と同期通信

　

「アプリケーション・アーキテクチャ設計入門」

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