【特集】つぎはぎシステムを防ぐセキュリティアーキテクチャ

〜 ITアーキテクトによるセキュリティ設計 〜

佐藤慶浩
日本ヒューレット・パッカード株式会社
2004/4/29



 ITアーキテクトでのセキュリティの位置付け

 ITを設計する際に、セキュリティのことをアーキテクチャとして考慮しているだろうか? 世の中の一般的なセキュリティ技術をただ単に模倣していたり、システムのビジネス要求との十分な整合性を取っていなかったり、ひどい場合にはセキュリティを後から取ってつけたりしていないだろうか?


本記事は、「ITアーキテクト」と@ITの各フォーラムが展開する、分析/設計工程に焦点を絞った『ITアーキテクト連動企画』記事です。

 ITアーキテクトの目的は、ITを体系的に構築することである。ITアーキテクトによって適切に設計されていないと、「つぎはぎだらけ」になり、そのシステムには「すき間」ができてしまい、セキュリティの弱い部分が露出して安全性を損なうことになる。そのような足りない部分があるにもかかわらず、一部の要素には偏重して無駄な余分ができたりもする。適切に設計していないと、各要素をバランスよく配分することもできず、また、出来上がったシステムについて、全体的に見渡すこともできないために見直しもままならないということになる。そのような「つぎはぎのすき間」と「無駄な重複」を防ぐのがITアーキテクトの役割である。システム設計において、ITアーキテクトは、設計を整然とさせるような付加価値的意味合いもあると思われるが、ことセキュリティの観点においては、不可欠なものといえる。

 とはいえ、セキュリティについての要求は、発注者から具体的に仕様が示されなかったり、そのための費用を配慮してもらえなかったりするため、セキュリティについて懸念している人でも、実際のアーキテクチャでセキュリティを十分考慮できなかった場合も多かったのではないだろうか。

 最近は情報セキュリティの問題が社会問題としても多く取り上げられていることもあり、セキュリティのスキルを磨くには、非常によい時期である。逆に、発注者が関心を示しているこの機会に習得しなければ、スキルを身に付ける機会を逸することにもなる。そして何より、ITアーキテクトを目指す者にとって、セキュリティの観点でシステム設計を行うことは、アーキテクチャの重要性を認識する際の具体的な演習となり、例外対処を取り扱うセキュリティの分野は、ITアーキテクトが能力や経験を発揮し差別化できる領域である。

 SLAに見るセキュリティの位置付け

 セキュリティに着目したITアーキテクチャとしては、「基礎」「トラスト」「制御機構」の3ブロックを考えることができよう(図1)。

図1 基本3ブロック(システム技術、システム運用およびマネジメント)

 それぞれ、「マネジメント」「システム技術」「システム運用」に深く関係する。本稿では、システム開発者に関係の深い、「トラスト」ブロックを特に説明することにする*1

*1
全体やほかのブロックについては、http://yosihiro.com/go/security-architectureを参照いただきたい。

 「トラスト」ブロックで考慮しなければいけないことは「ITを安心して使う」ということであり、3つのキーワードで考えることができる。それは、性能と可用性、セキュリティである(図2)。性能は期待した応答時間で処理結果を得られること、可用性はサービスの停止時間が期待した時間内に収まっていること、などが挙げられる。これらは、ITの開発現場では、SLA(サービス・レベル・アグリーメント)として発注者から示されることが多い。

図2 システム開発者に関係の深い、トラスト・ブロックの考え方

 セキュリティについては、これまであまり明確ではない場合が多く、「十分なセキュリティ対策が施されていること」などのような記載にとどまっていたかもしれない。しかし、ITがイネーブリング(enabling)して、支えているサービスの重要性が日々高まるにつれ、情報セキュリティ問題への関心は高まっている。このため、今後はSLAにセキュリティが含まれてくることになるであろう。

 セキュリティとほかの課題の特徴を整理してみよう。SLAには本来さまざまな要素が入るが、ここでは性能と可用性について、セキュリティとの差異に着目してみる。

性能と可用性 セキュリティ
・レベルの達成度を定量化しやすい ・レベルの達成度を定量化しにくい
・レベルの達成目標を発注者が明示しやすい ・レベルの達成目標を発注者が明示しにくい
・レベルの向上は、ハードウェア機器などのスケーラビリティでも達成できる場合が多い ・レベルの向上は、スケーラビリティよりも機能追加などで達成する場合が多い
・レベルの向上は、ITがイネーブリングしているサービスの向上につながる ・レベルの向上は、ITがイネーブリングしているサービスの向上に必ずしもならない

 性能や可用性が、処理件数や停止時間といった定量的な尺度で目標設定し、ある時点での達成度を計測できるのに対して、セキュリティの達成度を定量化するのは一般的には困難である。

 要件が定量化しにくいことにより、発注者がサービスレベルを明示しにくいという副作用が生じる。これまでは、「十分なセキュリティ対策が施されていること」などで済まされていた場合もあるであろう。しかし、昨今は情報セキュリティへの関心が高まっているため、それでは済まされない。かといって、発注者に十分な知識がないことが多いので、受注者が逆に提案を求められることが予想され、ITアーキテクトは、結果的にITイネーブリングしている業務サービスのセキュリティ要件を理解し整理するスキルが求められることになるかもしれない。

 性能と可用性を向上させるためには、ソフトウェアの設計での配慮は不可欠のものであるが、これらの設計手法は成熟しており、そのセオリーに沿っていれば、主としてハードウェアなどの機器構成のスケーラビリティで性能と可用性を向上させることができる。当初目標が後から見直されても、機器構成の増設によって対応しやすい。それに比べて、セキュリティに関しては、ITアーキテクチャそのものに大きく依存する可能性が高く、システム設計時点での不備は、セキュリティ要件を満たせなくなる可能性があり、体系立てたアーキテクチャの必要性が高まるものと思われる。

 近年のソフトウェア開発は、ウオータフォール型の開発ではなく、RAP(Rapid Application Prototype)やRAD(Rapid Application Development)などのスパイラル型の手法になっているが、性能や可用性については、これらの向上が、ITがイネーブリングしている業務サービスそのものの向上にも貢献するため、すべてをポジティブ・フィードバックで推進することができる。しかし、セキュリティの向上は、時として、性能や可能性、あるいは、そのほかの利便性、管理性といった側面において、必ずしもポジティブにはならない場合がある。このことは、設計初期の段階での十分な設計がされていないと、後からほかのサービスレベルに負の影響を与えかねない。

 以上のようなことから、セキュリティの課題を解決するために、構造的で体系的な設計が不可欠であり、ITアーキテクトの重要性が増すのである。

 
1/2
「セキュリティ要件の5つのA」へ

Index
つぎはぎシステムを防ぐセキュリティアーキテクト
Page1
ITアーキテクトでのセキュリティの位置付け
SLAに見るセキュリティの位置付け
   Page2
セキュリティ要件の5つのA
アイデンティティ・マネジメント
プロビジョニング

Security&Trust記事一覧


Security&Trust フォーラム 新着記事
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Security & Trust 記事ランキング

本日 月間