東日本大震災におけるBCPの問題点
2011.05.18更新
情報セキュリティ大学院大学 原田研究室

No

検討項目

ページ

1BCPの発動

1

2

BCPの不備1

3DRPの問題

2

4インフラの問題

2

5

通信インフラの問題

2

6

サプライチェーン

3

7

自社のセキュリティ環境の問題

3

8

要員の問題

3

9

計画停電の影響

4

10

外部電源

4

11

個人情報の取り扱い

512

情報漏えい

513

バックアップ5

東日本大震災におけるBCPの問題点
2011.05.18更新
情報セキュリティ大学院大学 原田研究室
No

検討項目

1 BCPの発動

問題点

対応策①BCP、IT-BCPを発動する指揮命令系統が震災で機能しなかった（発動者や担当者が死亡したため、BCPを実施できなかった）①BCPが機械的に発動できるように、マニュアル、取り決めなどを実施する②BCPの発動を連絡するための通信インフラが不十分で、安否確認や被害状況の把握に手間取り、これに基づいたBCPの発動を速やかに行えなかった②本社のBCPの発動を待たなくてもよいように、現地に権限移譲しておく③BCP、IT-BCPの文書が(停電や津波で）行方不明となり、BCPを発動できなかった③本社レベルのBCPと支社、現場レベルのBCPを階層化する。
各レベルで個別にBCPが発動できるようにする④一般社員がBCPとくに、IT-BCPを十分に内容を理解していないため、必要な措置がとれなかった④BCPに関する文書類はオフィスが消滅してもアクセスできるようにする（クラウドに保管する、音声メッセージでアクセスできるように準備しておくなど）⑤津波や原子力発電所からの避難のため、必要なBCPを実施できなかった⑥震災の全体像を把握するのに時間を要して、BCPの発動が遅れた①BCP、IT-BCPの検討が十分でなく、使えなかった①BCPを策定するとき、「初期対応」「暫定対応」「本格対応」にフェーズ分けするのがよいのではないか②BCPの発動を連絡するための通信インフラが不十分で、取引先（サプライチェーン）と連携がとれず、適切なBCPを実施できなかった③BCPで想定しなかった規模の災害のため、BCPで想定していない対応をとれなかった
2 BCPの不備④BCP、IT-BCPが(停電や津波で）広域被害を想定していなかった②BCPでは、通常、事業ができなくなるようなシナリオを想定しない。しかし、想定するシナリオとは別に最悪のケースを分けて考えておく必要がある③BCPを策定しても、現実に確かめるのは難しいので、BCPを点検するために、第三者による評価などがあるとよい④BCPの機器は、連続運転が可能か、また制限事項を事前に確かめる⑤風評被害や二次被害などを考慮していなかった⑥BCPでは、バックアップ電源装置は、数時間の利用しか考えていないため、連続運転が可能か分からなかった1

東日本大震災におけるBCPの問題点
2011.05.18更新
情報セキュリティ大学院大学 原田研究室
No

検討項目

問題点

対応策

①BCPとDRを別のものととらえている①DRはBCPの一部として、復旧の部分だけを具体化したものと考えるとよい②DRについては、自社の被災を中心に考えているが、担当する従業員、機器の提供元、電源、通信インフラなどが得られない場合についての想定が甘かった②DRに必須の機器については、複数のチャンネルから調達できるようにしておく
3 DRP(復旧計画)の問題 ③すべてを喪失した際のDRを考えていない④DRのための復旧用の資材や設備が地震で壊れたり津波で流失したが、調達が困難であった①早期にインフラが復旧すると想定（1週間程度）していたが、その通りにならない①BCPに必要な機器を搬入するルートを複数確保しておく（道路が使えないとき、空輸する手段を検討する）②広域にインフラが損壊して、代替手段をとることができない
4 インフラの問題②インフラがネックの場合には、立地を変更することも考える（最低限必要なBCPについては、インフラまで検討事項に含③電気が連続して利用できない（計画停電や総量規制）ことを考えていなかった めておく）④不意の停電で、IT機器が故障しないような対策が必要となった①通信インフラが、事業者の装置の故障、広域の震災のため広域に輻輳が広がり、ネットワークにアクセスできない状況が続いた

5 通信インフラの問題①被災地側での状況と、被災地以外での状況を把握できるよ
うに、MCAやPHS、アマチュア無線など、多重の通信手段を用意しておく②企業のネットワークがIP-VPNを利用しているところは、IPネットワークの輻輳のため、帯域が制限された（BCPのTV会議ができなかった）②非常時には音声ではなく、Webによる連絡など、多重の連絡手段を用意しておく③携帯電話のネットワークは、基地局が故障してアクセス回線が少なくなった。スマートフォンなどの利用も進み、パケットネットワークも輻輳して、制限さ ③セキュリティから無線LANを禁止している企業が多いが、非れた
常時には、無線ルータ＋ノートPCの構成でインターネットへのアクセスを確保するなどの対策を用意しておく（情報セキュリティを解除することもBCPに記載しておく）

2

東日本大震災におけるBCPの問題点
2011.05.18更新
情報セキュリティ大学院大学 原田研究室
No

検討項目

6 サプライチェーン

問題点

対応策

①取引先の絞り込みのため部品などが代替ができないため、被害にあったITが復 ①自分の事業に合わせて、どのようなサプライチェーンと旧できなかったなっているのかを分析して、それに対応した対策を考えておく②復旧用のIT資材や設備が津波で流失し、その調達も困難であったこと②バックアップの電源用に必要な燃料のサプライについて③ITに関する契約やITサービスのSLAが実施されないも、複数のルートを用意しておく。自社の他地域から転送することができるように面的な備蓄も考慮する必要がある）④燃料などのサプライを十分に考えていないため、発電機を連続運転できなかった①個人情報を管理していたサーバ室が崩壊したり、津波で流されて流出した。
（これは、セキュリティインシデントとして扱うべきか？）7

自社のセキュリティ環境の問題①非常時には、情報セキュリティを解除できるような仕組みを考えておく②シンクライアントの活用等によって、セキュリティレベルは高かったものの、 ②人命（人間）に関するセキュリティは、フェイルセーフで対応する
これによって、自宅等で業務を継続することが出来なかった③セキュリティはICカードの入室管理システムは電気を前提としているため、停 ③情報資産については、非常時でも機密保持が必要な場合には、災害で喪失する場合を想定した管理（常時暗号化）など電時のセキュリティを保持できないが必要（津波でサーバが流出してもデータが解読されないよ④監視カメラなどが地震で壊れたり、電源が提供されないため、監視できていな うにする）
い（監視カメラに対する災害要件が必要）①スキルのある要員を多数失った（津波で行方不明となった）①要員について、「初期対応」、「暫定対応」、「本格対応」のフェーズに分けて、適切に配置できるように計画する②道路の損壊で、バックアップ要員が駆け付けることができない②計画では、要員ごとに、スキル（非常時のリーダシップ、非常時の柔軟性）、住所、駆けつけ（家族のけがや住宅の損壊で駆けつけられない）のリスク評価③放射能汚染で、要員が駆け付けることができない
8 要員の問題④要員の家族が不明で、要員の稼働を保証できない⑤取引先などに要員派遣を要請しても、要員を手当できない⑥計画停電のためにITの停止と動作のために要員を手当てが必要となるが、災害復旧で要員が不足しており、十分にITを動作させられない

3③計画停電や急な停電の際の要員計画をする（サーバの停止、再稼働には待機要員が必要）

東日本大震災におけるBCPの問題点
2011.05.18更新
情報セキュリティ大学院大学 原田研究室
No検討項目

問題点対応策①ITは、電気の連続供給を前提としていることを自明としていた（サーバの空①停電による自社の影響を分析しておく
調、ネットワークを含めた全体に電気が必要であるが、発電機の容量が不足しているため、重要なサーバしか動作させられない）②非常時電源で動作させられる機器を選び、配線を変更しておき、それだけを動作させられるようにする（全てを動作さ②サーバのある箇所と、PCのある事業所が計画停電で異なる場合、サーバを前提 せると、大規模な発電機器が必要となる）
として運用ができない③企業の場合、小規模な停電の場合には、車の電源を利用し③多くの企業の処理がサーバ運用を前提としているため、企業活動がサーバとPC て、PC+携帯による最低限の通信環境が確保できるようにするの動作時間に限定される
9 計画停電の影響④企業のビジネスの処理の多くがワークフローとなっているため、サーバやPCが計画停電のため、承認などが遅れる（例外処理とすると、J-SOXでの内部統制を見直さなければならない）⑤サーバの頻繁な動作、停止の手順ができていない（無停電での運用を前提としている）⑥取引先と受発注がITで連携されているが、計画停電で連携がスムーズにできないケースがある①企業内部のネットワークインフラ全体をカバーする外部電源の用意ができてい ①複数の企業で、外部電源を利用できるような体制を考えるない （特定のサーバを動作されることはできるが、端末まで含めたIT全体を動②EV車の蓄電池を利用できるような仕組みを考えておく
作させるまでの外部電源の用意がない）

10 外部電源②バッテリの定期的な充放電は想定されていないため、いつまで持つかわからな ③クラウド＋携帯＋ipadのような最小限のシステムで必要となる電気容量を事前に把握しておき、停電の際に使えるよういにする③UPSは、計画停電のような長時間（3時間）の停電のための設計がされていないため、いつまで持つか分からない④ディーゼルエンジンがあっても、燃料が必要となるが、この燃料を十分に手当てできない4

東日本大震災におけるBCPの問題点
2011.05.18更新
情報セキュリティ大学院大学 原田研究室
No

検討項目

問題点

対応策

①個人情報の開示がないため、不明者の特定に時間がかかった
11 個人情報の取り扱い①非常時の個人情報の取り扱いについての法制度を詰めておく②避難した場合の個人情報の開示の基準がないため、HPなどで流すまでに時間を要したため、連絡をとる手段を提供できなかった①ハードディスクは津波程度では、復元が可能、第三者にNC機器、PCやサーバが ①リスク分析を行って、緊急時でも機密性の保持が必要であ拾得された場合を想定していない
れば、常時データベースは暗号化する。
12 情報漏えい②津波なのでIT機器が流出して、情報が漏えいすることを考えていなかった②サーバ機器は、停電するとハード的な扱いがないとデータを取り出せないようにする①バックアップを遠隔地に設置するのは、同じ災害の影響を同時に受けないため ①センターとバックアップセンター間の距離を見直す（同一の対策であるが、今回の震災の範囲が広く、バックアップを含めて喪失したケー の地震で被害を受けない→同一の災害で被害を受けない広域の分散を検討する）
スがある。
13 バックアップ②バックアップサイトが停電のため、バックアップとして機能しなかった③バックアップが週1回のため、3.4-3.11の更新データが消失した（リアルタイムバックアップが必要→クラウドへの条件）④バックアップはDailyやWeeklyのため、喪失したデータがある

5②重要なデータベースの場合には、リアルタイムバックアップを検討する③クラウドのインタフェースを標準化して、どのクラウドでもバックアップを受けてもらえるようにして、複数への分散バックアップが容易にできるようにする