システム構築依頼の着眼点

 いきなりサーバやネットワークを構築して,「Webで情報発信しろ」とか,「メールをやり取りできるようにしろ」と言われた場合,やはり不安なのがセキュリティ面だ。数年前とは異なり,システム構築方法に関する書籍や記事で,セキュリティにまったく触れないことは少なくなってきたが,それでもまだ甘いところがある。書籍などの場合,どうしても一般論にならざるを得ないからだ。自サイトの要件に応じて,かつ安全に作ろう,と考えた場合には迷うポイントも多くなる。あるいは,これだけ「セキュリティ」という文字が躍っていると,質実剛健に自サイトを構築したいときに本当にどれを読めばよいのか,それがわからなくなってしまうということがあるのではないだろうか。

 こういった場合,システム構築サービスを利用するとよいだろう。

表2 セキュアなシステムを構築するための必要条件
 サーバ構築の場合,実施する作業内容は表2[拡大表示]のようなものになる。(1)~(2)がサーバ構築,(3)がネットワーク構築である。また,サーバ構築の場合は(5)あるいは(6)がオプション,ネットワーク構築の場合には(4)がオプションになるだろう。

表3 構築してもらったシステムのデキを調べるためのチェック・ポイント
 この手のサービスを依頼する場合は,作業内容が適正か,ということが焦点になる。一番良いのは事前に作業項目とその内容についてヒアリングし,それを精査することだ。ベンダを見極めるには,依頼側もある程度の技術的な知識が必要になる。また,作業後は表3[拡大表示]のような内容をチェックする。

 不要なサービスやデーモンを公開しているかは,WindowsやUNIXが標準で備えるnetstatコマンドなどを使えばよい。このコマンドで,ネットワークからのアクセスを待ち受けしているポートがわかる。開いているポート番号の一覧が出てくるが,それを見れば,どんなサービスが起動しているのかわかる。

 サーバを外部からネットワーク経由で調べるときは,ポート・スキャンと呼ばれる方法を用いる。ポート・スキャナというツールが無償で公開されており,それを使ってみる。これは,netstatを別のコンピュータからネットワーク経由で利用しているようなもので,同様に待ち受けポートの状況がわかる。開きポートの状況がわかれば,その開きポートを使って待ち受けている=稼働しているサービスが必要最小限かどうかをチェックすればよい。

 例えば,Webサーバなら一般に80番ポートだけを公開していればよい。しかし,なかには21番(ftp)とか23番(telnet)まで開けているケースがある。開いている場合は,その意図をベンダに細かく聞くべきだ。Webページの不正書き換えは,実は80番以外のポートが悪用されるケースが多い。

 弱点スキャナと呼ぶツールを使って,サーバの弱点を自分でチェックする方法もある。ポート・スキャナは公開ポート番号を検出するが,弱点スキャナは公開しているサービスの弱点まで検知してくれる。80番が開いていたら,Webサーバの種類,バージョンなどを調べて,その弱点情報を提供してくれるのだ。後述の侵入検査サービスなども,弱点スキャナを使っている場合が多い。これを自ら使ってしまうのだ。フリーのツールを使うだけでも,表3のチェック・ポイントをすべてカバーできる。

 ただし,これらのチェック作業をすべて自前でやる必要はない。気の利いたベンダであれば,構築後のチェックを自ら実施して報告してくれるからだ。逆に言えば,そうした報告が作業項目に含まれているのかどうか,含まれていなかった場合は要求してみてどういう反応になるか,をチェック・ポイントにしてもよいだろう。

 システム構築の作業量は,構築すべきサーバの種類(メール,Web,DNSなど)によって異なる。共通するのは,ヒアリングと設計で約1日,OS関連部分でおそらく約1日(ここは定型的な作業となる),フィルタ(ファイアウォール)導入で約1日,サービス・ソフトウェアの導入と設定構築で約2日かかることだろう。加えて,テストに約1日,現地調整作業が約1日,検査作業が約1日,作業記録文書作成で約1日と,作業日は最低でも9~10日は必要だ。規模によるが,価格は60万円程度からだろう。サービス・ソフトウェアのごくベーシックな設定に限った場合は,その半分程度で済むこともある。

表4 セキュリティ保守の主な作業内容

保守は構築ベンダに依頼すべきか

 セキュリティ保守とは,表4[拡大表示]のような作業になる。なかには,セキュリティという色分けではなく,一般的な保守作業に含まれているものもある。

 しかし,これらの作業すべてにセキュリティは絡んでくる。せっかくセキュリティを意識して構築したサーバやネットワークを,それを意識せず運用・メンテナンスすると台無しになってしまう。

 保守の作業内容のチェック・ポイントは,表3に示した構築時と同じである。チェック・ポイントに従って,構築時の状態が保たれているか,パッチを当てた部分が正しく動作しているのかを確認したい。

 陥りがちなパターンは,パッチは当てたが,チェックしたら思わぬところに穴が開いていたというものだ。ファイアウォールのポリシを更新して穴が開いてしまったら目も当てられない。ファイアウォールのポリシは極端な例だと思われるかもしれないが,残念ながらそうとばかりは言い切れない現場を筆者は見てきている。ことセキュリティとなると,ほんのささいなミスであっても致命的になってしまうことはよくあることだ。

 できれば,大きな更新作業を実施したあとは,その都度チェックしたい。公開サービスにかかわる変更などが,「大きな更新作業」に該当するだろう。

 保守の場合,一つポイントになるのは保守を引き受けるベンダが,自身の構築したシステム以外を引き受けたがらないことだ。もともと引き継ぎというものは,書類ベースだけでは困難な部分だが,自社で構築したものであればどうあがいても逃げられない。何かトラブルが起こった場合,今は無関係な開発プロジェクトのメンバを引っ張り込んででも対応しなくてはならない。逆に言えば,トラブルが発生しても自社内のどこかに聞けば何とかなる,ということでもあり,その意味では引き受けやすいとも言える。これに対し,他社のシステムなら最後には逃げることができるとも言えるが,トラブル・シューティングには手間暇がかかってしまうのは避けられない。動作しているものを引き受けて,保守した結果,動かなくなると困るという思惑もある。

 このため,システム構築ベンダと異なるベンダに保守を依頼する場合は,保守ベンダがどこまで面倒を見るのかを確認し,依頼者と保守ベンダがサービス・レベルについて合意・納得(SLA=Service Level Agreement)する必要がある。そうでないと,後でトラブルが発生する恐れがある。

 トラブルを避けるためには,引き継ぎとともに徹底的に調査させる,という手もある。作業費を払って調査を依頼すれば,「きちんと引き継ぎしていないから」いう言い訳はできなくなる。逆に,それがわかるだけに,調査する方も真剣にならざるを得ない。

 IT業界の平均的な作業費はおよそ1カ月で80~120万円(20日分)。セキュリティ業界の場合は知識技術コストが高めで,その1.5倍=120~180万円程度だろう。1人日で月5万~10万円だ。

ログ解析を頼むと高額に

 ただ,この価格は表4に示した(5)ログ解析を含んでいない。表4の(1)~(3)の作業はあまり頻繁には発生しない。もちろん使用するソフトウェアによるが,せいぜい月に1日(=8時間程度)程度の作業で済む。(4)OSのバージョンアップを含めても,月に2日程度の作業になるくらいだ。

 これに対して,ログ解析は保守作業員を長時間拘束する。理想的には,後述する監視サービスと同様,24時間365日行いたい。監視などの別サービスと併用した場合でも,1週間に1回はログ解析すべきだろう。

 ログにはさまざまな種類がある。システム(OS)のログ,サーバ・プログラムのログ,ファイアウォールのログなどだ。後述する監視サービスで用いるIDSのログもある。

 ログを解析することで,サーバ・プログラムやシステムに何かおかしな痕跡がないかを調べることができる注2)。もし,おかしなものがあれば,それをきっかけに今度はファイアウォールの許可ログ(アクセプト・ログ)と突き合せて,さらに詳しい記録をチェックする。取れるログはすべて取り,すべてを解析する。ベーシックなレベルなら,補助ツールによって機械的に解析できる部分もあるが,詳細に追うときは,どうしても人の眼に頼る部分が大きくなってしまう。詳細解析の場合,作業の手間も時間もさらにかかってしまう。

 価格は作業時間がベースになる。ログの総量によって作業時間は変動するが,補助ツールを使って機械的に解析し,かつ最小限のイベントを追いかけるだけなら,1回の解析に付き作業時間は半日~1日弱程度だろう。この場合,1回当たり10万円程度が相場だ。詳細に追いかける場合は,その数倍の20万~40万円が必要になるだろう。

 なお,ログ解析作業の品質は(1)解析精度は適切か,(2)解析の結果ベンダが適切な提言をするか,などをチェックする。例えば(1)では,おかしなアクセスをシミュレートするツールなどを持ち込み,どこまで検出するかを見てみる。後述の侵入検査サービスを頼む手もある。

 一方(2)のポイントでは,何かおかしなことが起こっていた場合,何をすべきかの提言をベンダがきちんと報告書に反映しているか,事実の報告だけにとどまっていないかなどをチェックする。

24時間の監視サービスは必要か

 監視サービスとは,侵入検知装置(IDS:Intrusion Detection System)などを導入し,そこで検知する情報を分析したり,事後対策するものだ。システムのログや監視装置(IDS)からの検知メール,IDSが残すログなどを定期的に分析する形態のサービスや,リアルタイムにシステムを監視・対応するサービスがある。

 24時間365日対応は,監視センタのような設備を持っているベンダでなければ対応できない。24時間のサービスを提供するには想像以上のコストがかかる。24時間365日こなすためには,約5倍のスタッフが必要になるのだ。平日は3交代で3人,土日で2人の合計5人というわけだ。

 監視センタは,ユーザ側に設置した監視装置を使って監視する。1人で,平均10~20サイトの監視装置の面倒を見るはずだ。となると,5人で20サイトをカバーし,100サイトを監視するには25人のスタッフが3交代+土日体制で勤務する。このロジックに基づいて料金体系を考えると,24時間365日の監視サービスを受ける場合,1サイト当たり月30万円程度は必要になる。年間で360万程度ということだ。

 これが,平日の9~17時の監視になると,必要な人材は減る。単純に考えると,月額10万前後になるだろう。

 このため,監視サービスを考える場合は,24時間365日の対応が必要かをまず決めたい。不正アクセスは,いつどこから来るかわからない。海外からの不正アクセスを考慮すると,そもそも時間は関係ない。むしろ,海外が活動する時間(=日本の夜中)の方が危険だったりする。となると,どうせ監視サービスを依頼するなら,24時間監視を選ぶのが望ましいだろう。

 ただ,この種のサービスを依頼するときによくありがちな誤解に,24時間365日監視してもらっているので,もうこれ以上何もやる必要がない,というものがある。サービス・メニューを考える場合,提供側はやはり定型的なサービスとして提供したいのだ。監視の場合に定型化できる部分というのは,IDSを使った不正アクセス検知と,その報告というところまでに過ぎない。せいぜいオプションとして,何らかの不正アクセスが実際に起こった場合,検知した通信セッションをファイアウォールなどで切断してしまうというような,緊急的な対処が付いてくるだけのはずだ。だから,頼む側としては「検知しました」と報告を受けて以降にどうするのか,ということをしっかり考えておかなければならないのだ。

 それはつまり,緊急時対処手順,連絡網を整備し,緊急的な対処を実施したあと,恒久的な対策を実施するまでにどうするか,業務(システム)停止時の対応をどうするか,などを決めておかなければならないということである。

 もちろん検知に伴って,暫定的な対策(例えば設定を一時的に変えておく,サービスを部分的にでも止めておくなど)および恒久的な対策(例えばパッチを当てる,設定を変更してしまう,システムやアプリケーションを作り変えるなど)についてのアドバイスは出てくるだろう。しかし,そこまでだ。その後どうするかは依頼する側の問題でしかありえない。そこを決めずにサービスを導入したところで,不正アクセスが検知されてからあたふたしなければならない。

 やはりここでも,サービス提供側にどこまで依頼するのか,それを受けて自分たちは何をどうすればよいのか,ということをシビアに見極める必要がある。

図4 監視サービスを提供するベンダを選ぶチェック・ポイント

監視サービスの品質とは

 では,監視サービス自体の品質はどのように見極めればいいのか(図4[拡大表示])。まず必要なのは,処理手順の確認だろう。

 処理手順とは,何か起こった場合にどうするのか,どこに連絡してどのような処置を行うのか,現場で手に余る場合はどうするのか,といったものだ。もちろん,どんな監視サービスでも,何かおかしなことが起こったときには必ずユーザの連絡窓口に連絡が入る。しかし,その後どうすればいいのかまで知らせてくれなければ,ユーザは困ってしまう。監視センタが適正な対処をしない場合,ユーザ自身で(1)セキュリティ専門家に連絡して至急対処してもらう,(2)汚染された(と思われる)サーバやネットワークをすべて破棄し新しいサーバやネットワークを一から作り直す,(3)無理矢理自分たちで復旧する,といった方策を採るしかない。

 監視サービスの品質を図るには,先に述べた(1)と(2)の方策を監視サービス・ベンダ自体がオプションとして用意しているかが一つの尺度になる。持っている場合は,ユーザに事実を知らせるだけなのか,それとも解決策のヒントを示すのか,という違いを見極めなければならない。

 もう一つ,ユーザへの報告内容のクオリティも尺度になる。どんな内容のレポートが,どういうタイミングで出てくるのか,という視点である。チェックするには,業者からサンプルをもらう必要がある。

 さらに,監視装置となるソフトウェア(IDS)の品質も重要だ。IDSには,大きくネットワーク型とホスト型の二つがある。ネットワーク型は,監視対象のサーバとは別のマシン上で動き,ネットワーク上を流れるデータを分析する。これに対して,ホスト型は監視対象のサーバ上で動き,監視対象サーバに対するアクセスを監視・分析する。監視対象となるサーバの詳細なログをもとに分析・検知する。ここでいうログとは,普通のシステム・ログだけではなく,システム・コール(OSのベース機能を呼び出す関数)単位でのログの場合もある。

表5 ネットワーク型とホスト型IDSの長所・短所
 ネットワーク型とホスト型の検知システムには,それぞれ表5[拡大表示]のような長所と短所がある。理想的には両方の仕組みを導入したいが,実際にはどちらかだけを導入するケースが多いはずだ。となると,検出精度をアップさせるノウハウを持っている監視センタが望ましい。ノウハウがあるかを調べるには,「ネットワーク型IDSを導入したが,トラフィックが想定より多くて,取りこぼしが多いようだ。この場合どうする」などと,インタビュしてみるとよいだろう。

 当然,監視センタがどのメーカのIDSを導入するかをチェックしておいた方がよい。同じネットワーク型IDSでも,製品によって検出精度が異なる場合がある。例えば,ネットワーク型IDSをだます手口はいくつか確立されている。この手口にひっかかるIDSとそうでないIDSがある。また,耐えられるトラフィック(通信データ量)にも違いがある。100Mビット/秒までなのか,1Gビット/秒にも耐えられるのかもチェックしておきたい。

 ただ,IDSメーカが公表しているデータだけで,本当のことはわからない。この種の製品比較データは,セキュリティ関連のメーリング・リストや米国の消費者団体系サイトなどを参照するのがよいだろう。

 また,ネットワーク型の検出精度を上げる試みとして,例えばファイアウォールから得られる情報と連携させたりする仕組みも出てきている。あるいは,トラフィック解析といったアプローチを援用し始めているところもある。だが,いろいろ現状を聞いている限りでは,いずれもまだまだ未成熟であり(IDS自体が成熟しているとは言えないが)コストに見合った成果を上げているようには思えない。

 ほかに,この関連では最近IDP(Intrusion Detection and Prevention=侵入検知・防御)システムと呼ばれる仕組みが出てきている。例えばIDSにも備わっていたような,ファイアウォールと連携して特定の攻撃パターンを検知したら通信切断などの防御を,連携して自動的に行うものだ。しかし,そもそもの検知精度が問題になる部分もあり,この種の「自動的」な仕組みを導入する場合にはさらに慎重なチューニングが必要となることは間違いない。また,それだけの手間をかけてどれだけの効果が得られるのか,正直なところそのあたりもまだよくわかっていない。引き続きトレースしていく必要があるだろう。

園田 道夫
筆者は株式会社アイ・ティ・フロンティアに勤務。現在は同社セキュリティソリューション部にてコンサルテーションを主に行っている。同社のサイト「プラスセック」(http://www.itfrontier.co.jp/sec/)にて各種読み物連続掲載中。また,日本ネットワークセキュリティ協会(JNSA)技術部会・不正アクセス調査ワーキンググループリーダーを務める。