「障害復旧」から企業のリスク管理としての「事業継続」へ：ディザスタリカバリで強い企業を作る（3/4 ページ）

[JPCERT/CC，ITmedia]

BCPの実施「体制」を作る

　ディザスタ発生時の最高意思決定機関として、BCPの指揮を取るための「対策本部」を設置し、各部署ごとにBCPの実行状況を監督する全社的な体制を構築する。具体的には、経営層をトップとした「対策本部」を本社に設置することになるだろう。

　次に、その指示を受ける「部署」としては、平常時の組織機構（体制）で対応してもよい。だが、例えば情報システムの障害といったディザスタの場合は、情報システムの復旧作業のために要員を必要に応じてほかの部署から確保しなければならない場合もありうる。このように通常の組織機構ではなく、非常時を想定した機能別の「チーム」体制を構築することが望ましい。

　例えば、対策本部の構成図の例としては以下のようなものがある。

図3●BCP対策本部の構成例

　BCPを実際に運用していく上で最も重要なことは、部署（チーム）間の情報連携である。どんなに立派なBCPを策定し、訓練しても、BCPを実行するのが感情を持った人間である以上、実際にディザスタが発生した場合、情報の交錯などのパニックが発生することは否めない。結果として、情報の交錯が対応の遅延につながり、ひいては被害の拡大、復旧の遅延に至ってしまうのである。

　これを防ぐためには、まず「情報の交錯」をなくすことが重要だ。つまり、どのチームでどのような被害が発生しているのか、また各チームの復旧状況（BCP実施状況、ステータス）といった情報を共有しておくことである。

　そのために、情報共有のための連絡体制をあらかじめ整理しておく。具体的には各チームに担当者（および不在の場合の代理）を定める。

　このような非常時の体制は、CSIRT（Computer Security Incident Response Team）の体制と全く同じである。既に自然災害などのディザスタに対する対策体制がある場合は、その体制にCSIRTの機能を加えるのがよいであろう。

　参考までに、CSIRTに必要な体制（担当）として、次のような典型例を紹介する。

脆弱性対策担当

　常に脆弱性情報を収集し、自社システムの脅威につながる情報がある場合は、その問題を解決するために必要な対応作業を社内に展開する。情報収集源としては、JPCERT/CCやIPAセキュリティセンター、米国US-CERT、英国NISCCなどの公的CSIRTやセキュリティベンダーなどがある。

インシデント対応担当

実際に発生している、または発生する可能性のあるインシデントに対応する。具体的には以下のような作業を行う。

担当の作業	作業内容とその効果
日常的なインシデント関連情報の収集	万が一のインシデント発生後の復旧作業に必要な情報となる
外部からの通報受付および対応	自社システムが第三者への攻撃の踏み台に使われているといった自社がかかわるインシデントに関する情報（通報）を受け付け、まず事実確認のために必要な社内展開を行う
	事実確認の結果を通報者へ連絡する
	必要に応じてインシデントにかかわっている可能性のあるサイトへ情報を伝達し、協力を依頼する。これは、一般的にインシデントにかかわっている（可能性のある）サイトと情報交換することにより、原因の究明を促すことができるばかりでなく、結果として復旧作業を円滑に進められる可能性が高くなるためである
	（主に情報システム部門と連携して）原因の追及、復旧作業、再発防止策の検討と実施を行う（または支援する）

　上記の作業については、セキュリティベンダーなどの有料アウトソーシングサービスを利用することも有効だ。また外部、特に海外の企業、組織との連絡調整に際しては、公的CSIRTであるJPCERT/CCに協力を依頼することで円滑に進む場合がある。

顧客対応担当

　大量の顧客情報などの漏えいが発生した場合、被害の拡大や二次被害を防ぐためにインシデントの内容（事実関係）を顧客へ開示する、また必要に応じて公開（プレス発表、記者会見など）する。

　開示および公開に伴う顧客などからの問い合わせ窓口を設置する。

参考文献

JPCERT/CC 技術メモ - コンピュータセキュリティインシデントへの対応

http://www.jpcert.or.jp/ed/2002/ed020002.txt

JPCERT/CC 技術メモ - 関係サイトとの情報交換

http://www.jpcert.or.jp/ed/2002/ed020001.txt