京セラコミュニケーションシステム株式会社　郷間佳市郎（きょうま けいいちろう）

■はじめに

　セキュリティ対策の一つであるV A （ 脆弱性診断：Vulnerability Assessment）の分野では、スポット的に特定のサーバの「脆弱性」を知りたいというニーズだけでなく、大規模なシステム全体の「脆弱性」の情報を常に管理し、その変化を捉えたいというニーズが増えてきています。これにともない、各社のVA製品は、大規模システムを一元管理するため、これまでにはなかったさまざまな仕組みを実装してきています。
　本稿では、このような大規模システムに対応できる「スケーラビリティ」を実現するための、VA 製品における新しい仕組みや機能について紹介したいと思います。

■なぜVA の「スケーラビリティ」が問題となるのか

　これまで、ネットワークシステム全体を把握するセキュリティ対策というと、IDS（侵入検知システム： Intrusion Detection System）を中心にしたソリューションになっていました。これは、セキュリティの観点からネットワークシステム全体の状態を監視する仕組みが、これまではIDSくらいしか存在していなかったことに理由があります（＊1）。しかしIDSは、実際に発生している攻撃、あるいは攻撃準備行動の検知を行う、「事後対処」的な意味合いの強いデータを収集するプロダクトです。データの分析結果から問題点を見つけ出したとしても、その時には既に攻撃を許している、といったことが発生してしまう可能性が非常に高いという問題がありました（図１参照）。
　このため以前から、「攻撃」ではなく「攻撃」の原因となる「脆弱性」のレベルで問題を把握したいというニーズが出ていました。ところが従来のVA 製品は、診断時に対象のネットワーク機器に対して大きな負荷をかけてしまう等の問題があったため、稼動中のシステムを常時診断することが難しい状況にありました。このようなことから、これまではIDS中心の議論がなされてきたわけです。
　しかし最近、この状況に変化が生じてきています。「脆弱性」の診断技術の進歩により、診断対象に過度の負荷をかけず、安全に診断できる診断方法を実装したVA製品が出てきたからです。これにより、稼動中のシステムに対して常時脆弱性診断を行うことが可能になってきています。
　このような動きの中で問題になったのが、VA 製品の「スケーラビリティ」です。大規模システムを一元的に管理するニーズが生まれたことにより、これまでのVA製品の仕組みでは対応しきれない、大規模なシステム環境特有の問題が発生してきました。


　　　　　　　　図3 「事前予防」と「事後対処」

■最新のVA 製品が実装する大規模なシステム環境向けの機能

　では、実際に、大規模システムに対応するために、VA製品にどのような機能や仕組みが、提供されてきているのか、以下にその代表的な例を示してみたいと思います。

(1)「集中」と「分散」　−「管理」部分の集中化と「診断」部分の分散化−

　従来型のVA 製品は、単一のマシンにVA ソフトウェアをインストールする構成が主流でした。診断対象が限定されている小規模システムでは、このような構成でも問題はありません。しかし、大規模システムを一元的に診断する場合には、単一のマシンでVAを実現するシステム構成では、性能的に対応しきれないという問題が生じてきます。このため、「脆弱性診断」を行う部分と「診断結果を管理」する部分とを分離させた構成をもったVA製品が増えてきています。
　図２は、アプライアンスベースのVA製品の例ですが、大規模システム全体を集中管理する「管理アプライアンス」を中心に、ネットワーク上の各サブネット（本社・支社・事業所・部門といった単位）に、専用の「診断アプライアンス」を分散配置するシステム構成となっています。
　このように、「管理」を行う部分と「診断」を行う部分を分離し、診断部分を分散配置することで、大規模システムに対応できる「スケーラビリティ」を実現しているわけです。


　　　　　図2 「管理」部分の集中化と「診断」部分の分散化

(2)「権限」機能の細分化　−権限「限定化」の必要性−

　脆弱性の診断対象が、企業等の組織（本社・支社・事業所・部門といった単位）にマッピングされる場合、そこには、当然のことながら「権限」の区分けが必要となってきます。
　例えば、経理部門のシステムの診断結果を、他部門の「管理者」が閲覧できない仕組みが求められるわけです。また、実際に診断を行うユーザー（診断のための「設定」を変更できるユーザー）と、診断結果を「閲覧」することのみが許可される“read only”のユーザーといった区分けも必要となってきます。
　これまでのVA 製品には、「管理者」や「閲覧者」といった権限の区分けが不明確であり、また「管理者」についても、その権限範囲を限定する仕組みは実装されていませんでした。しかし、大規模なシステム環境における運用に対応するため、「権限」を細かく指定できる機能を実装したVA製品が出てきています。

(3)メンテナンス性の向上　−「ニア・ゼロ」メンテナンスを目指して−

　先に述べた「診断」部分の分散は、診断機器がシステム内の各所に配置されるという状況を生みました。このため、物理的に離れた場所に設置された機器の「メンテナンス」という問題が発生してきます。大規模なシステムであればあるほど、その物理的配置は多数かつ遠隔地となる場合が多く、いかにメンテナンス性を向上させるかが課題となってきたのです。
　このような課題に対して、米国nCircle（エヌサークル）社のIP360は、ユニークな解決策を実現しました。分散配置されるアプライアンスに、OSやアプリケーションのインストール作業が必要となるものを一切搭載しないという方式です。この方式は、クライアントマシンの実装方法として検討されてきている「シン・クライアント（Thin Client）」（＊2）の考え方を、アプライアンスに応用したものといえます。
　分散配置された「診断アプライアンス」は、起動前には必要最低限のデータ（IPアドレスやデフォルトゲートウェイ等）しか持っておらず、それ以外に必要なOSやアプリケーション、診断に必要な設定情報や検査ルールといったものについては、アプライアンスの起動時に、ネットワーク経由で「管理アプライアンス」から取得する仕組みになっています。さらに、先に述べた必要最低限のデータについても、CF（コンパクトフラッシュ）のメモリー内に書き込まれています。このため、もし不幸にしてアプライアンスが故障した場合でも、代替機にCFを差し替えるだけで、自動的に故障前と同じ状態に設定され、再起動することが可能となっています（図３参照）。

　　　　　　　　図3 「ニア・ゼロ」メンテナンスの実現

　また、このような仕組みは、正常稼動時においても、常に、最新のOS やアプリケーション、情報等をもとに、各アプライアンスが稼動する状況を作り出しており、メンテナンスにおけるTCOを削減する効果を発揮します。
　このようなnCircle社の試みは、「アプライアンス」という特長を最大限に活かした実装方式といえます。この試みは、単にサーバを箱の中に入れただけで「アプライアンス」と称している製品が多い中で、今後のアプライアンス製品の方向性を示す注目すべき点であるといえます。

(4)脆弱性の危険度の「数値化」　−共通言語としての「数値」の持つ意味−

　大規模システムにおいて脆弱性を管理する場合、検出された脆弱性の危険度を、どのようにして組織内に周知するかという問題が生じてきます。この対策として、危険度を「数値化」し、診断対象ごとに「レーティング」する方法が考えられます。図4は、実際のVA製品の出力結果ですが、脆弱性診断の結果を「数値化」することによって「点数」として扱い、「レーティング」を可能にしています（＊3）。


　　　　　　　　図4 数値化による「レーティング」

　また、このような「数値化」は、組織にまたがる「共通言語」となりえる点でも重要です。セキュリティ関連の専門用語は、経営者や一般の社員には難解であり、システム管理者がその危険性を訴えたとしても、その危険度を切実に受け取れるかどうか、という問題があったわけです。
　これに対して、「数値化」というアプローチを採用することによって、問題となっている対象がどれだけ危険なのか、他の部門と比べてどうなのかが、「数値」という共通言語で扱うことが可能になるわけです（図５参照）。


　　　　　　　図5 「数値」という共通言語を使ったアプローチ

　以上で述べてきたように、大規模システムに対応できる「スケーラビリティ」を実現するため、VA製品には、さまざまな新しい機能や仕組みが実装されてきています。
　この結果、VA の位置付けが、システムの構築時や一年あるいは半年に一回といった定期メンテナンス時に行われる「イベント的」なものから、日常的に脆弱性診断を行い、その結果を管理しながら、システムの安定運用のための情報として利用される「セキュリティ・インフラ」へと変化してきている点が注目されます（＊4）。
　今後、どのような新機能がVA に加わるかに関わらず、「セキュリティ・インフラ」としてのVA の位置付けは、さらに高まっていくと予想されます。

＊1：ファイアウォールやルータのログを定期的に監視するという方法もありますが、このログだけで、大規模システム下で十分な情報分析を行うことは、現実的に困難であるといえます。

＊2 ：シン・クライアント（Thin Client）については、以下のURLが参考になります。
　　　http://premium.nikkeibp.co.jp/e-gov/keyword/2003/key045.shtml

＊3：この「数値」は、脆弱性が発見されてからの期間や、脆弱性の持つ脅威（脆弱性がシステムに与えるインパクト）、どれだけ簡単に攻撃が可能なのかといった、いくつかの要素をもとに計算されます。

＊4：このような位置付けの変化から、「VA」ではなく「VM」（脆弱性管理：Vulnerability Management）と呼ぶ場合もあります。

執筆者プロフィール 鈴郷間　佳市郎（きょうまけいいちろう） 京セラコミュニケーションシステム株式会社 ネットワークシステム事業本部　 セキュリティシステム事業部　技術担当部長 ●1989年、信州大学大学院修士課程修了（農業経営学研究室）。同年、大手メーカー系ソフトウェア会社に入社。UNIX 上の基本ソフトウェアプログラム開発に従事。1991年、Windows-UNIX 間のクライアントサーバシステムの開発プロジェクトに参加。リーダーとしてデータベースとの通信を行う共通インタフェース層の開発に従事。1995年、日欧間共同開発プロジェクトに参加。日本側のコンタクトパーソンとしてグループウェア製品の開発に従事。1997年、官公庁系のイントラネット設計／構築業務に従事。1999年、大手メーカーの統合認証システムプロジェクトに参加。2000年、キャリア系のネットワークセキュリティ設計／構築業務に従事。e-コマースサイトのセキュリティ設計／構築を行う。2002年、京セラコミュニケーションシステム?に入社。現職に就任。2004 年、NetWorld+Interop NOC（Network Operations Center）チームに参加。コアメンバーとしてN+I 全体のネットワークセキュリティ運営に従事。現在に至る。