 |
【特集】つぎはぎシステムを防ぐセキュリティアーキテクチャ
〜 ITアーキテクトによるセキュリティ設計 〜
日本ヒューレット・パッカード株式会社
2004/4/29
|
ITを設計する際に、セキュリティのことをアーキテクチャとして考慮しているだろうか？ 世の中の一般的なセキュリティ技術をただ単に模倣していたり、システムのビジネス要求との十分な整合性を取っていなかったり、ひどい場合にはセキュリティを後から取ってつけたりしていないだろうか？
|
ITアーキテクトの目的は、ITを体系的に構築することである。ITアーキテクトによって適切に設計されていないと、「つぎはぎだらけ」になり、そのシステムには「すき間」ができてしまい、セキュリティの弱い部分が露出して安全性を損なうことになる。そのような足りない部分があるにもかかわらず、一部の要素には偏重して無駄な余分ができたりもする。適切に設計していないと、各要素をバランスよく配分することもできず、また、出来上がったシステムについて、全体的に見渡すこともできないために見直しもままならないということになる。そのような「つぎはぎのすき間」と「無駄な重複」を防ぐのがITアーキテクトの役割である。システム設計において、ITアーキテクトは、設計を整然とさせるような付加価値的意味合いもあると思われるが、ことセキュリティの観点においては、不可欠なものといえる。
とはいえ、セキュリティについての要求は、発注者から具体的に仕様が示されなかったり、そのための費用を配慮してもらえなかったりするため、セキュリティについて懸念している人でも、実際のアーキテクチャでセキュリティを十分考慮できなかった場合も多かったのではないだろうか。
最近は情報セキュリティの問題が社会問題としても多く取り上げられていることもあり、セキュリティのスキルを磨くには、非常によい時期である。逆に、発注者が関心を示しているこの機会に習得しなければ、スキルを身に付ける機会を逸することにもなる。そして何より、ITアーキテクトを目指す者にとって、セキュリティの観点でシステム設計を行うことは、アーキテクチャの重要性を認識する際の具体的な演習となり、例外対処を取り扱うセキュリティの分野は、ITアーキテクトが能力や経験を発揮し差別化できる領域である。
|
セキュリティに着目した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記事一覧 |
- Windows起動前後にデバイスを守る工夫、ルートキットを防ぐ （2017/7/24）
Windows 10が備える多彩なセキュリティ対策機能を丸ごと理解するには、5つのスタックに分けて順に押さえていくことが早道だ。連載第1回は、Windows起動前の「デバイスの保護」とHyper-Vを用いたセキュリティ構成について紹介する。 - WannaCryがホンダやマクドにも。中学3年生が作ったランサムウェアの正体も話題に （2017/7/11）
2017年6月のセキュリティクラスタでは、「WannaCry」の残り火にやられたホンダや亜種に感染したマクドナルドに注目が集まった他、ランサムウェアを作成して配布した中学3年生、ランサムウェアに降伏してしまった韓国のホスティング企業など、5月に引き続きランサムウェアの話題が席巻していました。 - Recruit-CSIRTがマルウェアの「培養」用に内製した動的解析環境、その目的と工夫とは （2017/7/10）
代表的なマルウェア解析方法を紹介し、自社のみに影響があるマルウェアを「培養」するために構築した動的解析環境について解説する - 侵入されることを前提に考える――内部対策はログ管理から （2017/7/5）
人員リソースや予算の限られた中堅・中小企業にとって、大企業で導入されがちな、過剰に高機能で管理負荷の高いセキュリティ対策を施すのは現実的ではない。本連載では、中堅・中小企業が目指すべきセキュリティ対策の“現実解“を、特に標的型攻撃（APT：Advanced Persistent Threat）対策の観点から考える。
 |
|
|
|
|
