耐災害性を強化した情報システムの在り方等に 関する調査

耐災害性を強化した情報システムの在り方等に 関する調査

平成 24 年 3 月 株式会社三菱総合研究所

平成 23 年度

内閣官房情報セキュリティセンター委託調査

目次

0. 調査の概要 ... 1

0.1. 調査の目的と背景 ... 1

0.2. 調査方法... 1

1. 災害発生時における情報システムの影響と対策についての調査 ... 3

1.1. 調査方法... 3

1.2. ヒアリング調査結果 ... 5

1.3. ヒアリング調査結果から得られる要点 ... 10

2. 災害時に影響を受けるセキュリティ機能に対する対策と課題の整理 ... 22

2.1. 調査方法... 22

2.2. BCP に関する課題と対策 ... 22

2.3. 情報システムに関する課題と対策 ... 27

3. リスク・コミュニケーションに関する調査 ... 31

3.1. 調査方法... 31

3.2. ヒアリング結果 ... 32

3.3. 災害に関するリスク・コミュニケーションの在り方 ... 36

4. 情報セキュリティ人材育成に関する調査 ... 39

4.1. 災害時に情報セキュリティ対策を担う人材像 ... 39

4.2. 企業等が作成している情報セキュリティ人材育成計画 ... 41

4.3. 企業等の情報セキュリティ関連部署の組織体制、セキュリティ関連業務で求められている 知識・能力、推奨される資格・教育プログラムの関係 ... 52

4.4. 企業等におけるセキュリティ人材の不足感・育成方針・キャリアパス ... 65

4.5. 情報セキュリティ関連の資格制度の概要 ... 71

4.6. 情報セキュリティ関連資格制度、キャリアパス、処遇等の関係 ... 73

4.7. 大学及び大学院における情報セキュリティカリキュラムならびに学位 ... 83

4.8. 大学及び大学院における産学官連携による情報セキュリティ人材育成に対する取り組み ... 87

4.9. 情報セキュリティ関連コンテスト・表彰の実施状況 ... 90

4.10. 情報セキュリティ教育プログラム及びキャンプの実施状況 ... 91

5. まとめ ... 92

付録 A. 『4.5. 情報セキュリティ関連の資格制度の概要』の調査結果 ... 付- 1 付録 B. 『4.7. 大学及び大学院における情報セキュリティカリキュラムならびに学位』調査結果の 詳細 ... 付- 17 付録 C. 『4.8. 大学及び大学院における産学官連携による情報セキュリティ人材育成に対する取 り組み』調査結果の詳細 ... 付- 48 付録 D. 『4.9. 情報セキュリティ関連コンテスト・表彰の実施状況』 調査結果の詳細 ... 付- 60 付録 E. 『4.10. 情報セキュリティ教育プログラム及びキャンプの実施状況』 調査結果の詳細 ...

付- 74

付録 F. 情報セキュリティ人材育成に関する調査 ヒアリング・アンケート調査対象一覧 ... 付- 83

付録 G. 検討会の実施概要 ... 付- 84

0. 調査の概要

0.1. 調査の目的と背景

本調査は、災害発生時における情報システムのディペンダビリティを確保する情報セキュリティ 技術等に関する課題等の検討を行うために実施する。

大規模災害発生時には、情報システム障害、人為的要因及びサイバー攻撃等の影響により、

可用性以外の機密性、完全性、プライバシー保護等を考慮した対応が取れないケースもあり、事 業継続を困難とする情報セキュリティに関わる事故が発生する可能性もある。

そこで、以下の項目の調査により、政府の資料作成の参考にすることを目的とする。

・ 災害発生時における、情報システムのセキュリティを損なう事象の洗い出しと事業継続計 画＇BCP（を考慮するために必要な対策と課題の整理

・ 災害発生時に情報共有等を確実かつ正確に行い、合意形成を行うためのリスク・コミュニ ケーションの指針及び情報セキュリティ技術開発や適切な情報セキュリティ対策を支える人 材育成の状況

0.2. 調査方法

本調査の調査項目と調査方法は以下の通りとする。

(1) 調査項目

1) 災害発生時における情報システムの影響と対策に関する調査 (a) 災害発生時における情報システムの影響と対策についての調査 (b) 災害時に影響を受けるセキュリティ機能に対する対策及び課題の整理 2) リスク・コミュニケーション及び情報セキュリティ人材育成に関する調査

(a) リスク・コミュニケーションに関する調査 (b) 情報セキュリティ人材育成に関する調査

(2) 調査方法

1)(a)、1)(b)、2)(a)については企業＇ただし、重要インフラ分野を除く（に対するヒアリング調査を 中心とする。また、2)(b)については、有識者・関係機関等へのヒアリング・アンケート調査、文献 調査とする。

調査の進め方や視点については、別途設置する「耐災害性を強化した情報システムの在り方

等に関する調査検討会」の委員による意見を反映し、幅広い視点を含めた上でまとめる(図

0-1)。

(2)リスク・コミュニケーション及び 情報セキュリティ人材育成に関する調査 (1)災害発生時における情報システムの

影響と対策に関する調査

企 業 等 ヒア リ ング 調 査

(3)検討会の運営

(3)検討会の 運営

(4) 報告書とりまとめ

(b)情報セキュリティ人材 育成に関する調査

有 識 者

・関 係 者 等 ヒア リン グ

・文 献 調 査 (a)リスク・コミュニケーショ

ンに関する調査

(b)災害時に影響を受ける セキュリティ機能に対する 対策及び課題の整理 (a)災害発生時における情

報システムの影響と対策 についての調査

文 献 調 査

図 0-1 本調査のフロー

以下、第 1 章では、災害発生時における情報システムの影響と対策についてのヒアリング調査 として、東日本大震災における情報システムへの影響と情報システム利用・運用時の留意点、災 害発生時における情報システムのセキュリティ機能への影響や情報システムの扱いにおける事 業継続計画に関する検討項目等を記載する。

第 2 章では、第 1 章のヒアリング調査結果を踏まえ、災害時に影響を受けるセキュリティ機能と して、BCP、情報システムのそれぞれに関する課題と対策を整理する。

第 3 章では、災害発生時における、IT システムに関わるリスクに関するリスク・コミュニケーショ ンとして、社内における IT システムリスクに関わる情報共有と、ステークホルダー＇顧客、株主、

取引先等（や一般社会、地域住民等、対外への情報発信の観点から、実態と課題をまとめる。

第 4 章では、情報セキュリティ人材育成の観点から、災害時に情報セキュリティ対策を担う人

材像をまとめるとともに、情報セキュリティ人材を巡る、企業の取り組み、資格制度、大学・大学

院のカリキュラム、コンテスト等について情報を整理する。

1. 災害発生時における情報システムの影響と対策についての調査

1.1. 調査方法

災害発生時、情報システムの機能が著しく制限を受ける中で、優先度の高い活動を継続するた めに定めている BCP に準じた対応を行う中で、実際に生じた情報システムのセキュリティ機能へ の影響を調査し、災害発生時における情報システムの扱いにおける BCP の検討項目を整理し た。

調査方法は 20 組織＇重要インフラ事業者を除く（へのヒアリング調査とし、調査項目は災害発生 時における情報システムの影響と対策に関する調査＇25 項目（、リスク・コミュニケーションに関す る調査＇9 項目、3.1.1 節参照（、計 34 項目とした。組織属性に応じて、BCP 等へ反映する事項、災 害時に留意すべきセキュリティ要件等について整理を行った。

1.1.1. 調査項目

災害発生時における情報システムの影響と対策に関する調査項目全体＇34 項目（を表 1-1 に 示す。

表 1-1 災害発生時における情報システムの影響と対策に関する調査項目一覧

No 調査項目

災害発生時における情報システムの影響と対策に関する調査項目 (0) 企業の概要について

1 1) 拠点の状況＇被災地における拠点の有無、被災地で実施している業務 等（

2 2) 情報システムの設置場所＇社内サーバルーム／社外データセンター 等（

3 (1) 情報システムを考慮した事業継続計画＇BCP（の有無

(2) BCP がある場合はその概要、ない場合は災害発生時の態勢、権限の考え方 4 1) ＇BCP がある場合（BCP の発動基準・解除基準

5 2) 災害発生時の情報システムの稼働継続に関する意思決定者、対応態勢 (3) 通常時に情報システムに関して求められるセキュリティ要件やプライバシー要件 6 1) 重要な情報そのものや、情報システムに対するセキュリティ要件＇アクセス制御、

暗号化、バックアップ等（の考え方・セキュリティ確保の方法

7 2) 個人に関わる情報に対するプライバシー要件の考え方・プライバシー確保の方法 8 (4) 東日本大震災を受けた BCP の見直し、または新規策定の予定、内容

9 (5) 災害時に優先すべき業務と、関連する情報システム 10 (6) 災害時に優先すべき業務を遂行するために必要なリソース

(7) 東日本大震災時の情報システムの被災状況、業務への影響・対応 11 1) 影響を受けた情報システムの概要

12 2) 影響を受けた情報システムの管理場所

13 3) 情報システムに影響を与えた要因

14 4) 影響を受けた情報システムに対する復旧作業 15 5) 業務への影響

16 6) 業務への影響があった場合の対応

17 7) 全ての情報システムが復旧＇正常通り稼働（するまでの時間

(8) 東日本大震災時の情報システムのセキュリティ要件やプライバシー要件の遵守状況 18 1) 重要な情報そのものや、情報システムに対するセキュリティ要件＇アクセス制御、

暗号化、バックアップ等（の考え方・セキュリティ確保の方法について、変更せざる を得なかった点

19 2) 個人に関わる情報に対するプライバシー要件の考え方・プライバシー確保の方法 について、変更せざるを得なかった点

20 3) 電子化された個人情報について、平時とは異なる柔軟な管理方法に変更せざる を得なかった点、その際の技術面・マネジメント面でのニーズ、管理手段 (9) 東日本大震災時のサイバー攻撃の可能性

21 1) 東日本大震災時のサイバー攻撃＇DDoS 攻撃、標的型メール等（の有無、内容 22 2) サイバー攻撃があった場合の対応

23 3) 東日本大震災時でのサイバー攻撃で対応が困難だった点 (10) 東日本大震災の経験から情報システムに求める改善点

24 1) 情報システムへの直接の影響を踏まえた、＇情報システムに関連する（BCP の 見直し、新規策定の予定、内容

25 2) サービスそのものへの影響等を踏まえた、＇情報システムに関連する（BCP の 見直し、新規策定の予定、内容

リスク・コミュニケーションに関する調査項目 26 (1) 災害発生時に＇主に情報システムに関して（想定されるリスク

27 (2) 災害発生時に行う＇主に情報システムに関わる（リスク・コミュニケーションに参加す べき役割

28 (3) 災害発生時に想定している連絡手段

(4) 東日本大震災時の＇主に情報システムに関わる（リスク情報の共有方法 29 1) BCP 等発動フェーズにおける社内外関係者との情報共有方法 30 2) 業務再開フェーズにおける社内外関係者との情報共有方法 31 3) 業務回復フェーズにおける社内外関係者との情報共有方法 32 4) 全面復旧フェーズにおける社内外関係者との情報共有方法 33 (5) 東日本大震災時におけるリスク・コミュニケーション上発生した問題点

34 (6) 平時より行っている情報システムに関わるリスク等の情報共有や、災害発生時に円

滑に情報共有・伝達を行うための平時からの取り組み

1.1.2. 調査対象

調査対象は、東日本大震災において IT に何らかの影響があった、あるいは情報セキュリティ上 の柔軟な対応を行ったと想定される企業を、重要インフラ事業者を除く幅広い業種から抽出した。

製造業については、自動車、機械、食品等様々な形態があるため、件数を増やした。最終的なヒ アリング実施企業は、内閣官房情報セキュリティセンター＇NISC（と協議の上、決定した。

本調査でヒアリング調査を行った企業における業種と従業員規模は、以下の通りである。

表 1-2 ヒアリング実施企業

No 業種 本社 従業員数 国内拠点数

1

建設業 A 東京

人以上

箇所以上

建設業 B 大阪

人以上

箇所以上

3

製造業 A 東京

人以上

箇所以上

4

製造業 B 東京

人以上

箇所以上

製造業 C 東京

人以上

箇所以上

製造業 D 東京

人以上

箇所以上

7

製造業 E 東京

人以上

箇所以上

8

製造業 F 東京

人以上

箇所

製造業 G 東京

人以上

箇所

製造業 H 東京

人

箇所以上

通信業 A 東京

～

人

箇所以上

情報サービス業 A 東京

人以上

箇所以上

情報サービス業 B 東京

人

箇所

情報サービス業 C 東京

人

箇所

情報サービス業 D 神奈川

～

人

～

箇所

情報サービス業 E 東京

人

箇所

物流業 A

神奈川

人

箇所

卸売業 A 東京

人

箇所

小売業 A 東京

人以上

箇所以上

教育・学習支援業 A 東京

人

箇所以上

※「重要インフラの情報セキュリティ対策に係る第 2 次行動計画」＇2009 年 2 月 3 日情報セキュリティ政策会議決 定（において、流通業は大手事業者のみが重要インフラ事業者として定められている。ここでは、大手事業者で はないことから、NISC に確認の上、本調査の対象に含めた。

1.2. ヒアリング調査結果

企業における災害発生時における情報システムの影響と対策に関するヒアリング調査結果に

ついて、ヒアリング項目毎にまとめる。

1.2.1. IT システムを考慮した事業継続計画＇BCP（の有無

IT システムを考慮した BCP を持つ企業は 20 社中 9 社であったが、システムに何らかの影響が あった場合の対応手順について定められたドキュメントを保有している、もしくは BCP において一 部 IT システムについて触れられている企業＇5 社（も含めると、災害時に IT システムを稼働継続さ せるための何らかの指針を持つ企業は 20 社中 14 社であった。

1.2.2. 災害時の態勢、権限の考え方

BCP を保有する企業では、BCP で定められる基準や条件に基づき、BCP が発動され、BCP に 基づいた全社的な緊急対応体制が立ち上がっている。BCP の発動に関する判断で悩んだ、ある いは混乱したと回答した企業はなかった。

BCP が発動した場合、あるいは BCP はなくとも全社的な緊急対応体制が立ち上げられた場合、

情報システム部門責任者＇CIO（は全社的な緊急対応体制に組み込まれており、情報システム部 門と経営層が連携する対応体制が構築されていた。

全社的な緊急対応体制が立ち上がらなかった場合でも、IT システムを考慮した BCP や対応手 順が定められている企業では、情報システム部門で緊急対応体制を立ち上げ、迅速な対応を行 っている企業もあった。

1.2.3. 通常時に IT システムに関して求められているセキュリティ要件及びプライバシー要件 個人情報を保有しビジネスに利用する企業＇20 社中 15 社（のうち 10 社がプライバシーマークを 取得している。また、ISMS を取得している企業も 9 社あった。これらの認証を取得している企業で は、プライバシーマークや ISMS をベースとした管理を行っている。ID、パスワードによる情報に対 するアクセス権限の設定、重要な情報の物理的な保護＇入退室管理（等は多くの企業で行われて いた。

1.2.4. BCP の見直し、新規策定の予定

東日本大震災を機に、BCP の新規策定または見直しを行った企業は 20 社中 13 社であった。

見直しの内容は以下の通り様々であったが、指示命令系統を修正した企業が 2 社あった。また、

セキュリティレベルの緩和をルールとして設定した企業もあった。

・

IT を考慮した BCP を策定すべく検討中。BCP 本体は指示命令系統を修正。＇情報サービ ス業 E（

・

情報システムとしてはバックアップ回線を強化したが、業務部門には災害時にネットワーク

停止がありうることを前提で BCP の検討を依頼している。全社の BCP としては、バックアッ

プセンターを整備し、指示命令系統の再整備を行った。＇製造業 F（

・

BCP において、災害発生時に用意する情報システムの見直しとセキュリティレベルの緩和 をルールとして設定した。災害発生から半年後＇データセンターが被害を受けた状況（の対 応について BCP の視点から検討中。また、サイバー攻撃に関する検討についても着手し た。＇建設業 A（

・

BCP 見直しは、インフラ、データのバックアップ、セキュリティ等。＇卸売業 A（

・

メール確保と顧客の保守関係情報にアクセスできることを優先とし、データセンターの電源 に問題がありえるという前提で、BCP を見直し。＇通信業 A（

・

計画停電、電力総量規制への対応を BCP に追加予定。＇製造業 C（

・

関東と関西に分散したシステムのうち、関西が震災にあった場合の対応について検討。

＇製造業 D（

・

責任者の明確化。＇製造業 G（

・

災害発生時に必要な情報の整理のために、サーバ一覧や情報のまとめ方について整備。

＇製造業 E（

1.2.5. 災害時に優先すべき業務と、関連する IT システム

災害時に優先すべき業務として、20 社中 16 社が安否確認を挙げており、そのうち安否確認シ ステムを入れている企業は 9 社であった。災害時に優先すべき業務として安否確認を挙げた 16 社のうち 8 社で、携帯回線の輻輳のために安否確認作業が難航していた。また、安否確認システ ムを入れている企業のうち、登録したアドレスが受け取りにくいものだったり、システムの使い方が わからなかったりした場合など、返答率も悪いという企業もあった(2 社)。ただし、対象となる従業 員数が多い企業では、何割かでも返答があった場合は、個別に安否確認を行う手間が省けるた め、有効だったという意見もあった(2 社)。

安否確認以外の優先業務では、顧客対応、各拠点や現場からの情報収集、生産業務の継続 に関する情報収集等が挙げられた。顧客対応や、各拠点や現場からの情報収集では、通信手段 の確保が重要となっている。また、顧客対応として社内向け IT と同じ環境を用いて顧客にサービ スを提供している場合は、情報システム部門の優先業務として、サービス提供の継続、情報シス テム稼働のためのパーツの提供、運用人員の確保などが組み込まれていた。

1.2.6. 災害時に優先すべき業務を遂行するために必要なリソース

災害時に優先すべき業務を遂行するために必要なリソースは、安否確認の場合、作業を行うた

めの人員及びツール＇安否確認システム及び通信手段（であった。顧客対応や、各拠点や現場か

らの情報収集では、人員及び通信手段が必要である。さらに、1.2.5. に述べたような、社内向け IT

と同じ環境で顧客にサービス提供している場合は、情報システム部門では、社内業務に加え、顧

客対応のためにより多くの人員が必要となっていた。

1.2.7. 東日本大震災時における IT システムへの被災状況

東日本大震災によって IT システムに影響があったのは 20 社中 7 社であった。メインのデータセ ンターが本社や本社近くの首都近郊、被災地以外に設置していた企業が多く＇20 社中 19 社（、IT システムに対して影響を受けなかったものと見られる。

被災地に拠点を構える企業では、拠点の PC 損壊・流出、通信回線障害等、IT システムへの影 響が見られた。

東日本大震災において、大きな影響があった事例は以下の通りである。

・ 仙台のデータセンターが火災に見舞われ、6,000 件の顧客情報、建築系システムのデー タ等を全て失った。バックアップはセンター内だけで役に立たなかった。＇建設業 B（

・ ターミナルサービス＇シンクライアントのターミナルサーバ（が、停電で震災当日 2 万人が 使えなくなった。メール等、コミュニケーションの部分は全て使えなくなった。＇製造業 C（

また、震災後、計画停電において、IT システムに大きな影響があった事例は以下の通りであ る。

・ 都内の計算センターが計画停電の対象地域になり、サーバのシャットダウンとスタートア ップが必要になった。計画停電の間に顧客からの受発注データを一時大阪のセンターを バックアップとして利用したが、データを元環境に戻す際に、いくつかのデータが失われ、

復元するために、3 ヶ月程度を要した。＇製造業 B（

1.2.8. 東日本大震災時における IT システムのセキュリティ要件及びプライバシー要件の遵守状 況

東日本大震災において、IT システムのセキュリティ要件及びプライバシー要件について緩和措 置を取ったのは、20 社中 10 社であった。計画停電等によって出社できない社員のために、多くの 企業が在宅勤務制度を一時的に設けていた。これらの企業は、概ねリモートアクセス環境が既に 構築されており、それを一部拡大するだけでスムーズに対応できた。在宅勤務の制度がない企業 の場合は、制度がなくても運用で在宅勤務を一時的に認めるという柔軟な対応を行っている。

セキュリティ要件を大きく緩和した事例は以下の通りである。

・ PC の社外持ち出しは基本的に禁止しているが、被災地で建物の被害チェックをし、施設 の構造確認等を実施するためには、現場で PC を使用する必要があったために、PC の 持ち出しを情報システム部長として許可した。また、同様に施設の図面は、関係者以外 にアクセス禁止のデータであるが、情報システム部長の権限で許可を与えた。＇建設業 A（

・ 失ったデータ復旧作業のために、IT 部門は、2～3 週間ぐらい非常時体制が続いた。東北

地方のデータの HDD からの復旧・東京支社へのシステム移行は、ベンダの参集も十分

ではなく、本社で対応せざるを得なかった。時間がかかり、エラーも頻発したため、対応 が非常に大変だった。データへのアクセスはフリーにした。会社が回らないのが目に見え たので、早期に判断した。＇建設業 B（

・ 本社＇情報システム部門（からお客様に問い合わせをする場合は、現場からパスワード を聞いて対応した。テレビ電話で教え合ったりしていた。落ち着いた時期に、パスワード を変えて戻した。システムは、IT に強いグループ会社が管理しているため、アクセス権限 の変更に 2 日間かかる。＇小売業 A（

・ 緊急連絡できるように Skype のポートを開けた。社員の 20%が外国人で、帰国命令が出 た社員もいたため、海外にいる社員との連絡には、Skype は有効だった。その後も使える よう、Skype 利用の際の安全を確保し、ルールを整備した＇追認した（。＇情報サービス業 B（

・ ある顧客からの依頼で、緊急にアクセスするデータが必要であるということから、本来の FW の設定ポリシーを一時的に変更して、特定アドレスからのアクセスを許容する処置を 行った。この処置は、CIO と社長の判断と指示で実施された。＇通信業 A（

1.2.9. 東日本大震災時における IT システムのサイバー攻撃の可能性

今回調査対象とした企業の全てが、東日本大震災に関連したサイバー攻撃を受けていないと の回答を行っている。ただし、サイバー攻撃については気づいていない可能性も否定できない。

また、インターネットサービスを提供する情報サービス業からは、「震災に限らず常にサイバー 攻撃に晒されている」という回答があった。

1.2.10. 東日本大震災の経験から、IT システムに求める改善点

東日本大震災の経験から、IT システムに関して改善を実施、あるいは検討中という企業は 20 社中 16 社であった。実際に影響を受けた点の改善だけではなく、大規模広域な災害が発生する ことを踏まえた改善を実施・検討している企業も見られた。そのうち、5 社がバックアップを地理的 に離れた場所で実施するように見直し、データの集約を進める企業も 5 社見られた。

その他挙げられた主な改善点は以下の通りである。

・ 各地のデータセンターに分散させずに、顧客情報は一元化の予定＇海外のクラウド（。個 人情報なので外に出すかどうかは悩んだが、暗号化されるということであり、維持費以外 は削減可能であった。＇建設業 B（

・ データの保全、ネットワークに関して、影響が大きい障害点をなくしていくこと。非常時に、

指示を受けなくても、一定レベルまで自発的に動けるルールに変更すること。＇情報サー

ビス業 B（

1.3. ヒアリング調査結果から得られる要点

ヒアリング調査から判明した点について、東日本大震災における情報システムへの影響と情報 システム利用・運用時の留意点、情報システムのセキュリティ機能への影響、情報システムの扱 いにおける事業継続計画の検討項目について、以下に整理する。

1.3.1. 東日本震災における情報システムへの影響と情報システム利用・運用時の留意点 本調査において対象とした企業における情報システムの特徴は以下の通りである。

・

本社が関東近郊にある企業が多く、主要なデータセンターは被災地から離れている。

・

全国的に拠点が分散している場合、情報システムや情報も集約されておらず、自社で データセンターやサーバを運用している場合が多い。

東日本大震災における情報システムへの影響と業務へ与えた影響の特徴は以下の通りであ る。

・

社内外ともデータセンターが被災地に位置しないケースが多かったことから、情報シ ステムへの影響があった企業は尐なかった。

・

ただし、製造業における工場等、業務において重要な役割を果たす拠点とそれを支え る情報システムが被災地に存在する場合や、重要なデータセンターや拠点が計画停 電エリアに含まれた場合は、業務に対する影響があった。

・

停電＇計画停電を含む（や通信遮断・遅延の影響が大きかった。特に、計画停電では、

自家発電の容量不足、頻繁なサーバの立ち上げ/立ち下げ等の発生により、業務に 影響があった。

なお、今回の調査対象企業は、ある程度の企業規模を有し、IT を事業に活用している企業であ るが、重要インフラ事業者を除く業種であるため、業務と IT の特性という点で、＇一部のインターネ ット系サービスを提供する企業を除き（以下が特徴的であると想定される。

・

業務そのものが情報システムに直結するのではない場合も多いため、製造業におけ る生産管理システム等一部を除いて、社内において復旧優先度の高いシステムは、

社内外の情報共有システム＇メール、グループウェア等（である場合が多い。

・

情報システムの機密性・完全性も重要視しているが、顧客サービスの向上やコストと の兼ね合いにおいて、情報システムの可用性やシステム機能の充実の方が優先され ることが多い。

本調査における事例を基に、情報システムへの影響毎に、情報システム利用時・運用時の留

意点を整理すると、表 1-3 の通りとなる。

表 1-3 東日本大震災によるシステムへの影響と利用時・運用時の留意点 留意点

システム 状態

システムに影響 を与えた原因

利用時の留意点 運用時での留意点

稼働 － ○データセンターの立地考慮と

遠隔地でのバックアップ

・震災の影響がない場所のデー タセンター設置。＇複数（

・関西にバックアップを目的とし たディザスタリカバリセンターを 設置。＇通信業 A（

○人手の要らない運用環境構築

・障害が起こらない限り作業が必 要ないシステムの構築。＇情報サ ービス業 B（

○事前の注意喚起

・前日の地震の際、関係者に 注意喚起。＇情報サービス業 E（

○紙書類への考慮

・紙書類の取り扱い手順・保 護対策＇パスワード保存、自 動バックアップ、不要時の廃 棄（の見直し。＇卸売業 A（

停止 一部 停電 ○社内インフラシステムに対する

自家発電装置の導入

・メール・ネットワークの停電によ る利用不可⇒メールサーバ、ネ ットワークサーバの自家発電装 置導入。＇情報サービス業 d（

○縮退運転による燃料保持

・通信設備の自家発電の燃料 を保持するために、深夜は装 置を停止。＇建設業 A（

○移行環境を利用したデータ 回避

・サーバが利用不可となった が、移行途中のサーバにデー タを急遽移して対応。＇製造業 C（

計画停電 ○データの一元化とバックアップ

・拠点 PC が壊れ、データを消 失。情報の一元管理とバックアッ プ実施。＇教育・学習支援業 A（

○計画停電に合わせた機器 の停止/再起動

・計画停電に合わせ、機器の シ ャ ッ ト ダ ウ ン ・ 再 起 動 を 実 施。＇複数（

通信遮断・遅延 ○複数の通信回線・手段の確保

・通信回線の複数キャリア化 。

＇製造業 F、情報サービス業 A（

・テレビ会議システムを活用。＇製 造業複数（

○社内インフラシステムの外部 委託

・メールシステムを外部事業者に 委託。＇情報サービス業 C（

○新たな通信手段の暫定利 用

・Skype を利用可能とした。＇情 報サービス業 B（

全部 火災 ○顧客情報の集約・クラウド化

・社内データセンター火災のため 顧客情報を全消失。クラウドに顧 客情報を集約、バックアップを実 施。＇建設業 B（

－

計画停電 ○基幹システムの外部委託、社

内インフラシステムのクラウド化

・社内データセンターが計画停電 区域にあり、基幹システムが全 停止。段階的に外部データセン ターへ移行。＇製造業 D（

・グループウェアの稼働継続のた めクラウドへ移行。＇製造業 D（

－

1.3.1.1. 情報システムに影響がなかった事例

情報システムに全く影響がなかった事例は、自社あるいは社外でも震災の影響がない場所に

データセンターを設置していたケースであった。しかしこれは結果論であり、データセンターが被災

地や計画停電区域に入った事例では、情報システムに対して影響が発生したり、データセンター を耐震構造としていた場合でも、サーバが柱ごと倒壊したりしたケースもある。また、震災後、バッ クアップを目的としたディザスタリカバリセンターを、本社の東京から離した関西に設置した事例も 見られた。広域災害を念頭に置いた、地理的要素を加味したデータセンターの集約とバックアップ の実施方法については、大きな留意すべき点である。

また、今回調査対象とした企業のうち、高い可用性を要求されるインターネットサービスを行う 情報サービス業においては、元々障害が起こらない限り人手による作業が必要ないシステムを構 築していた。

運用時の留意点としては、東日本大震災前日の地震の時、関係者に「冷静に対応するように」

との注意喚起を行っていたケースが見られた。また、電子情報だけではなく、火災や津波等による 紙書類の紛失に備えて、紙書類の取り扱い手順と保護対策＇パスワード保存、自動バックアップ、

不要時の廃棄（の見直しを行う企業もあった。

1.3.1.2. 情報システムの一部に影響があった事例

停電による影響では、メールやネットワークが停電によって利用不可となった企業では、メール サーバ、ネットワークサーバの自家発電装置を導入したり、自家発電装置を導入していても、燃料 の保持のために深夜は装置を停止しながら運用していた事例が見られた。自家発電装置が接続 する機器の必要な運転継続時間と、自家発電装置の稼働継続時間の把握を行い、自家発電装 置の稼働継続時間が短い場合の、情報システムの優先稼働順位付けや縮退運転の方針につい て予め検討しておく必要がある。

また、停電によって、企業の基幹サーバが利用不可となった事例では、ちょうど移行途中のサ ーバの空きがあったため、データを急遽移して対応した事例もあった。これは、非常に大規模な企 業で、システムを一度に移行することが難しく、常に新しい環境と古い環境が混在する状況でシス テム運用が行われていたケースだが、新旧の環境をうまく活用することで、対応することも可能で ある。

計画停電では、複数の企業が、計画停電に合わせ、機器のシャットダウン・再起動を複数回実 施している。大規模なシステムが対象となった場合は、社外から応援の人員を調達した事例もあ った。さらに、計画停電の間のデータを一時別のセンターでバックアップとして利用したものの、デ ータを切り戻す際に、いくつかのデータが欠落したために、復元するのに数ヶ月を要した事例もあ る。基幹システムの場合は、自家発電装置を導入して対応した事例もあるが、複数回の計画停電 には対応できず、シャットダウン・再起動を実施せざるを得なかった企業もある。計画停電によっ て、拠点の PC が壊れ、データを消失したために、情報の一元管理とバックアップ実施を行った事 例もあった。計画停電対応は、前述した停電対応も合わせ、自家発電装置の導入や、データの集 約・バックアップの方法とともに検討する必要がある。

通信遮断や遅延については、通信回線の複数キャリア化によって問題なく対応できていた事例

もあった。しかし、被災地との連絡に支障が出たケースもあり、携帯電話、テレビ会議、社内メッセ

ンジャー、Twitter、Skype 等、複数の通信手段を用いることで対応していた。製造業等では、テレ ビ会議システムを活用していた事例が多かった＇製造業 3 社、建設業・小売業・情報サービス業各 1 社、計 6 社（。また、インターネット関連の情報サービス業では、平時から複数のインターネット系 の連絡手段を利用していたこともあり、Yammer

、Twitter 等の手段で情報伝達を円滑に行ってい た。東日本大震災時に、海外との連絡のために Skype を一時的に導入したが、便利であったため に後日社内ルールを変更して平時も利用可能とした事例もあった。通信遮断や遅延に備えては、

複数の連絡手段を日頃から準備しておくことが有効であり、また有効な連絡手段は平時から利用 可能とすることで、災害時も円滑に使えることが可能となる。また、メールシステムが計画停電対 象のエリアのルータを経由することで、自事業所は計画停電対象外でも、計画停電中メールが全 く使えないという事例があった。震災ではメールに直接影響なかったものの、その後の見直しで、

メールシステムの一箇所が壊れると全て使用不可になる構成であることが判明し、一括で外部委 託したという企業もあった。このように、メールシステム自体を外部事業者に委託する方法も 1 つ の選択肢であるが、それによって、社内の機密情報が社内の経路で閉じず社外に出てしまう点に ついても考慮する必要がある。

1.3.1.3. 情報システムの全てに影響があった事例

今回の調査対象では、被災地にあった社内データセンターの火災のため、顧客情報を全消失 した事例があった。地震を想定したサーバの柱へのくくり付けを行っていたが、想定を上回る揺れ のため、サーバが柱ごと倒れ、火災になったということである。紙は打ち出さない方針でほとんど 残っておらず、また、バックアップは同じデータセンター内に保存していたため、役に立たなかった。

この企業では、震災後、顧客情報を外部事業者のクラウド環境＇海外のデータセンター（に一元化 することとした。顧客情報を海外に置くことには社内でも議論があったが、暗号化がなされるという ことで、クラウド移行の決断を行っている。

社内データセンターが計画停電地域にあり、基幹システムが計画停電中全停止した企業＇製造 業（では、計画停電中から長期に渡ることを想定し、段階的に外部データセンターへ移行していた が、計画停電後も外部データセンターの利用を継続している。また、業務遂行上重要となるグル ープウェアも、稼働継続を確保するためクラウドへ移行した。

前者の事例の場合、東日本大震災では、東北が被災したため、人員的・システム的に体制の 充実した東京で支援を行うことが可能であったが、首都直下地震など、近隣に支援体制が望めな い場合も考えられる。また、後者の事例の場合、製造業の業務継続においては、社内インフラとし ての情報共有システム＇メール、グループウェア等（が稼働することが重要である。想定するリスク に対する対応が自社で難しい場合は、外部事業者のクラウド環境を利用することも一考に値する。

その場合は、現状指摘されているクラウドのリスクを考慮し、データの保管場所＇国内か否か（や 形態＇暗号化されているか否か（やバックアップ条件、SLA 等、確認の上で判断することが望まし

1

企業向けに提供されるソーシャルネットワーキングサービス＇SNS（の一種。情報共有ツールとして利用される。

い。

1.3.2. 東日本震災における情報システムのセキュリティ機能への影響

東日本大震災における情報システムのセキュリティ機能への影響は、事例として見られた点を 表 1-4 に整理する。

表 1-4 東日本大震災による情報システムのセキュリティ機能への影響

No 業種 対応 内容 シス

テム 環境

制 度 ・ 規則

責任 者の 承認

※ 終了 後の 扱い 1 建設業 A アクセス権限

の緩和

現場で PC を使用する必要があった ために、PC の持ち出しを許可。関係 者以外にアクセス禁止の施設図面 に対するアクセスを応援要員にも許 可。

× × ○ ○

4 製造業 B 入 退 室 制 限 の緩和

計画停電によるサーバのシャットダ ウンとスタートアップのための、ベン ダの応援要員のサーバルームへの 入退室は、事前申請ではなく、紙に 氏名と入退出の記録で行った。

× × ○ ○

11 通信業 A アクセス権限 の緩和

顧客依頼で緊急にアクセスするデー タが必要であることから、ファイアウ ォールの設定ポリシーを一時的に 変更して、特定アドレスからのアクセ スを許容する処置を行った。

× × ◎ ○

12 情報 サービス業 A

入 退 室 制 限 の緩和

地震後、コールセンターの入退室管 理システムが作動しなくなり、ドアを 開放した。夕方には復旧した。

× × × ○

13 情報 サービス業 B

Skype ポート の開放

海外の社員とも緊急連絡できるよう に Skype のポートを開けた。＇Skype は有効だったので、その後も使える よう安全を確保し、ルールを整備し た（。

× × ◎ ○

＇利用 可と した（

15 情報 サービス業 D

アクセス権限 の緩和

バックアップの復旧作業の際、担当 者が出社できない日があり、パスワ ードを使える人間を増やした。

○ × ○ ○

16 情報 サービス業 E

在宅勤務 計画停電の対象エリアの社員に対 して在宅勤務を認めた。申請ベース で利用可とし、認証システムのユー ザ数を追加した。

○ ○ ◎ ○

情報 サービス業 E

サービスの 年齢制限 一時緩和

安否確認のためにサービスの年齢 制限の一時緩和等を行った。

○ × ◎ ○

19 小売業 A アクセス権限 の緩和

顧客情報へのアクセスについて、対 象外の社員にも社員コードをパスワ ードとともに教えて迅速な対応を行 った。現在はパスワードを変更。

○ × × ○

アクセス権限 膨大なデータ復旧作業のために他 ○ × ○ ○

No 業種 対応 内容 シス テム 環境

制 度 ・ 規則

責任 者の 承認

※ 終了 後の 扱い

の緩和 支社やベンダから応援要員を確保

したため、データへのアクセスをフリ ーにした。会社が回らないのが目に 見えたので、早期に判断した。

在宅勤務 出社できない場合は、リモートアク セスを拡大して、在宅勤務にした。

○ ○ ○ ○ 20 教育、学習

支援業 A

在宅勤務 重要な業務担当者にノート PC と通 信カードを貸与して、在宅勤務を認 めた。現在もなし崩しで継続。

× × ◎ ×

アクセス権限 の緩和

拠点責任者の上長承認の下、拠点 責任者でなくとも情報が見られるよ うアクセス権限を変更した。現在は、

権限は戻している。

○ × ○ ○

※ ◎ 情報システム部門長以上の承認あり、○ 情報システム部門長の承認あり

多くは、復旧業務や顧客対応のための情報システムや情報へのアクセス制限の緩和や、計画 停電等に伴う在宅勤務の導入・対象者の拡大、入退室管理の緩和であった。情報システムや情 報へのアクセス制限の緩和については、既に当該情報システムや情報へのアクセス制限がかけ られている中、情報システム部門長の承認においてその制限を緩和・解除するという対応がなさ れており、対応についてやむを得ない状況下において、迅速に決定・実施されている。また、リモ ートアクセス環境や在宅勤務の制度が整っている企業では、在宅勤務の拡大が経営層で決定後、

その対象者を情報システム部門において拡大するという対応が、スムーズに実施されている。＇た だし、ノート PC の持ち出し環境にない企業では、ノート PC や通信カードを急遽調達している事例 もある。（入退室管理の緩和については、震災時の一時的な停電と想定される場合は、現場の判 断で緩和を行っていたが、計画停電で入退室管理の緩和が長期に渡る場合は、業務継続を優先 し、情報システム部門長の判断で紙をベースとした入退室チェックに変更していた。

これらの事例では、業務遂行上やむを得なく、一時的な対応である見通しが立っており、セキュ リティ要件変更の影響範囲も小さいことから、情報システム部門長の判断でスムーズに承認・実 施がなされている。特に、既にルールが確立していたり、システム環境が整備されていたりする場 合の実施については、円滑に進められている。また、多くは、平時の運用に戻されているが、一部 は緩和された環境が継続している場合もある。

しかし、顧客情報へのアクセスについて、対象外の社員にも社員コードをパスワードとともに教

えた事例＇表 1-4、19（では、システム権限の変更権限が自社にはなく、グループ会社にあり、円

滑な対応をできなかったことから、権限の拡大ではなく、ID とパスワードを共有し、運用をルーズ

にすることで対応している。ある社員の ID とパスワードが共有されることにより、他のシステムに

対してもアクセス権限が緩くなることや、入手した情報を悪用する可能性が高まり、単に ID とパス

ワードの拡大や一時的なシステム開放より、セキュリティレベルは低くなっていると言える。

一方、以下の事例においては、全社的なセキュリティ要件の緩和が必要なケースであり、いず れのケースも情報システム部門長以上の承認を得て、実施に踏み切っている。

・

顧客依頼で緊急にアクセスするデータが必要であることから、ファイアウォールの設 定ポリシーを一時的に変更して、特定アドレスからのアクセスを許容する処置を行っ た。＇表 1-4、11（

・

海外の社員とも緊急連絡できるように Skype のポートを開けた。＇Skype は有効だった ので、その後も使えるよう安全を確保し、ルールを整備した（。＇表 1-4、13（

・

安否確認のために提供する IT サービスの年齢制限の一時緩和等を行った。＇表 1-4、

16（

これらの点より、東日本震災における情報システムのセキュリティ機能への影響を踏まえ、以 下の点が留意点として上げられる。

・

災害時、ある情報システムや情報に対するアクセス権限の緩和を行うことが、業務継 続上有効であることが想定される場合は、その意思決定を情報システム部門長とす ること、アクセス権限を変更する手続きを簡易にしておくことで、災害時も円滑な対応 を行うことが可能である。システムやルール上の整備がなされていると、セキュリティ 要件の緩和と戻しについても円滑な運用が可能である。

・

ただし、セキュリティ要件の緩和の際には、影響範囲が限定される部分のみとし、全 社的な影響が大きい場合は、経営層の判断を仰ぐ仕組みを構築しておくことが必要で ある。

・

また、平時の運用に戻すタイミングと方法についても予め決定しておく必要がある。

・

アクセス権限を変更する手順が煩雑であると、かえってセキュリティレベルの低い運 用にならざるを得ないこともあるため、求められるセキュリティレベルを勘案の上、アク セス権限の変更手順を必要以上に厳密なものにしないことも必要である。

1.3.3. 災害発生時における情報システムの扱いにおける事業継続計画の検討項目 1.3.3.1. 災害時の情報システムの稼働継続に向けた対応について

東日本大震災において、災害時のシステムへの影響と効果的な技術的対策と組織的対策につ

いて表 1-5 に整理する。

表 1-5 災害時のシステムへの影響と効果的な対策

No システムへの影響 停止

範囲 種 類

対策

技術的対策 組織的対策 2 仙台のデータセンターが火災に見舞

われ、顧客情報、建築系システムのデ ータ 6,000 件を失った。サーバが柱ごと 倒れて発火したと見られる。バックアッ プも同センター内にあったため、役に 立たなかった。紙は打ち出さない方針 になっていたため、情報は一部しか残 っていなかった。

全面 停止

業 務

協力会社は誰でもアク セスできるように、期間 的な ID を使う等も考え ている。災害の際に は、できるだけ制約を なくし、個人情報関連 のみ権限を限定するシ ステムを考えている。

今後の対策として、顧 客情報は海外のクラウ ドに一元化する予定。

個人情報なので抵抗 感はあるが、暗号化す ることで転送可能。

災害の起きた時に対策 が取れるベンダに変更 した。

大きなシステムになる と、把握している人間 がいないので、ベンダ とのやり取りが適切に できる人材が必要。

3 IT 関係は基幹システムが壊れた訳で はないが、仙台のサーバは止まった。

一部 稼働

業 務

バックアップを持ってい るので、業務への影響 はなかった。

4 都内の計算センターが計画停電の対 象地域になっていたため、停電の度に サーバの停止と起動が必要になった。

計画停電の際、顧客からの受発注デ ータに、大阪のセンターにあるバックア ップを利用したが、データを切り戻す際 に、いくつかのチェーン店のデータが 停電の影響でドロップしていた。復元 に、3 ヶ月程度を要した。

全面 停止

業 務

社内要員だけでは対応

できないため、ベンダ 業者＇7 社（より、応援 要員として 50 名をお願 いした。

5 震災当日の停電のため、シンクライア ントのターミナルサーバが使えなくな り、2 万人に影響が出た。

全面 停止

イ ン フ ラ

震災をきっかけにデー タを集約の動きが加速 した。認証用 USB メモ リがあれば、どこからで もアクセスし、仕事がで きる。USB を紛失しても 5 分で再発行できる。

6 計画停電の当初は、100 台近いサー バのシャットダウンとスタートアップを 繰り返す必要があった。

全面 停止

業 務

・ イ ン フ ラ

計画停電の長期化に 備えて、緊急避難的に データセンターと契約 し、主要なサーバを移 設した。また、グループ ウェアが使えなくなるリ スクを回避するため、ク ラウドサービスへの移 行を進めている。

計画停電により、基幹の出荷配送のシ ステムが使えなくなるため、集荷のバ ッチ処理のタイミングを変更する必要 があった。東北地方の物流を変更して いたため、出荷・返品処理もシステム の改修が必要であった。

全面 停止

業 務

自社のシステムを開発

維持する体制を持って

いるので、速やかに対

処できた。

No システムへの影響 停止 範囲

種 類

対策

技術的対策 組織的対策 12 災害発生時、コールセンターの通信回

線が使えなくなった。受信はできるが、

発信ができなくなった。

全面 停止

業 務

すぐにバックアップ回線 に切り替えた。バックア ップ回線は発信方法が 異なるので、オペレータ ーにそれを指示した。

15 本社が計画停電エリアに入った。ネッ トワークが製造部から本社を介するの で、製造部門でもメール等が使えなく なった。

全面 停止

イ ン フ ラ

大規模 UPS を導入す べきか、ジェネレータで メールサーバとネットサ ーバをカバーすべきか 検討中。

本社では早期に帰宅さ せたが、製造部門では 前倒しで業務をする等 して対応した。

20 拠点の停電でネットワークが使えなく なった。安否と授業の状況について、

全て確認するのに夜中までかかった。

計画停電の際、各拠点に、機材が壊 れないように、停電前に電源を OFF に するよう指示したが、いきなり落ちて、

PC が壊れたケースが出た。

拠点内の 1 台の PC でファイルを管理 し、拠点内からアクセスする形態だっ たが、計画停電で PC が壊れため、元 のファイルが見られなくなった。

一部 稼働

業 務

・ イ ン フ ラ

自家発電装置を有する データセンターに移し た。共有フォルダの一 元管理も、ネットワーク フォルダで対応してお り、自動バックアップも 実施している。セキュリ ティも問題ない。

一部出社できない人が いたため、重要な業務 を担当している人には ノート PC と通信カード を貸与して、在宅勤務 を認めた。在宅勤務制 度はないが、現在もそ のまま使われている。

東日本大震災の一連の事象を通じて、情報システムの稼働維持に大きな影響を与えたのは、

被災によるデータの喪失やシステムの破壊、ネットワークの途絶といった情報資産の被害と、計 画停電であった。

前者については、可用性や完全性の維持が困難になる。特に、被災地区のデータの喪失は、

再現不可能なケースもあることから、バックアップの確保はもちろん、クラウドを活用したデータ管 理の一元化も検討されている。また、単一障害点となる箇所について多重化を図ることも必要で ある。

後者についても、煩雑なサーバ・PC の停止・起動を避けるため、データセンターの活用が検討・

導入されている。また、拠点単位の対処によりトラブルが発生する問題については、例えば機材 の死活をリモートで管理できるような仕組みが必要となる。また、停電の影響でデータ集約時にド ロップが発生する問題については、バッチ処理のタイミングを調整する形で解決できない場合にど のように対処すべきかが課題となる。

1.3.3.2. 災害時に特別に必要となる情報システムの稼働継続に向けた対応

災害時には、平時から利用している情報システムに加え、特別な業務が発生することで、新た

に稼働が必要な情報システムが存在する場合がある。東日本大震災における、このようなシステ

ムの状況と効果的な対策について、表 1-6 に整理する。

表 1-6 災害時に必要となる業務と必要となるシステムに対応する効果的な対策 No 災害時に

必要となる 業務

災害時に 必要となる

システム

種類 役割 停止 状況

対策

技術的対策 組織的対策 1 各拠点との

連絡

通信手段

＇Web、メー ル、電話、衛 星電話、テ レビ会議 等（

イン フラ

平時 稼働 ネットワークをデータ 系・音声系に分けて 二重化しており、2 回 線でも残ればテレビ 会議システムは利用 可能。

安否確認 安否確認シ ステム

安否 災害時 稼働 年に 4 回の訓練を実

施。＇ただし、東日本大 震災では事象が多発 し、どの事象に対する 確認メッセージかの対 応関係の把握に苦労（

現場の被害 状況の把握

被災状況把 握システム

業務 災害時 稼働 耐震設計がなされて いる DC で管理。

2 安否確認 通信手段 イン

フラ

平時 稼働 せず

携帯メールではなく、

端末問わずシステム に直接入力可能な 安否確認システムを 導入。

現場の情報 収集

営業管理シ ステム

業務 平時 稼働 商品＇家（の崩壊状 況は保証のために 重要な情報となるた め、災害時のデータ の迅速な収集のため に、クラウドに一元 化。

3 安否確認 安否確認シ ステム

安否 災害時 一部 稼働

負荷分散と二重化の ために、東日本と西 日 本 の 二 箇 所 に 設 置。

災害時の指 揮支援

発動基準対 応システム

災害 災害時 稼働 4 生産の継続 生産システ

ム

業務 平時 一部 稼働

被災地の工場で生 産不可となり、全国 の工場で代替生産を 行い、東北地方へ配 送した。計画停電時 の受発注データのや りくりは、都度処理を 変更して対応した。

計画停電のため、一部 データを大阪のセンタ ーに移して対応した。

＇データ欠落により切り 戻しで難航（

5 安否確認 安否確認シ ステム

安否 災害時 稼働 軽いシステムを構 築。携帯電話の輻輳 前にメールが届き、

携帯等を通じて Web からも入力可能。

訓練を頻繁に実施。

11 顧客対応 通信手段 イン フラ

平時 稼働 全社員がアクセス可能

な情報共有サーバを 立ち上げ、対策本部と 拠点の間でメーリング リストを公開。顧客と は、SE や営業が契約 上、連絡窓口を保有。

顧客情報シ ステム

業務 平時 稼働 関東のデータセンタ ーに設置。震災後、

関西のディザスタリ カバリセンターにも設 置。

No 災害時に 必要となる

業務

災害時に 必要となる

システム

種類 役割 停止 状況

対策

技術的対策 組織的対策 15 顧客対応 顧客情報シ

ステム 在庫システ ム

業務 平時 稼働 顧客及び関係部門と

別の手段で情報共有 できれば、システムが 稼働しなくても対応可 能。

16 安否確認 安否確認シ

ステム 安否 災害時 稼働 IT が壊れても、緊急連

絡網により、連絡が取 れる体制を構築。

17 安否確認 安否確認シ ステム

安否 災害時 一部 稼働

携帯電話がつながらな

い、登録情報が最新で ない、訓練が不十分な ど、有効に活用できな かった。

19 安否確認 安否確認シ ステム

安否 災害時 一部 稼働

年に数回の訓練を実

施。＇ただし、未返答も 常態化（

社用私用問わず、日 常保有する携帯電話 のアドレスを登録。

顧客状況の 確認

顧客情報シ ステム

業務 平時 稼働 IT に強いグループ会 社が、グループ統合 的に管理。

＇システムは稼働して いたが、権限を持たな い要員のために ID・パ スワードを共有（

(1)安否確認システム

多くの企業において、災害時に発生する最重要業務として、安否確認を挙げていた。安否確認 システムを導入している企業も多かったが、適切に稼働しないケースも見られた。その理由は、

「携帯メールが届きにくい状態であり、届いたのか届いていないのか、返信の有無がわからなかっ た」「＇無事であっても（返答がない社員がいた」というものであった。

安否確認システムは、携帯メールの円滑な送受信を前提としたものもあるが、広範囲の災害の 場合、長期的に輻輳状態が続くこともありうる。

そこで、安否確認システムを適切に稼働した事例を基に、以下の点に留意したシステムを構 築・利用することが有効であると考えられる。

・

携帯網の輻輳前にシステムからの安否確認メールを送信できること。

・

返信は携帯メールだけでなく、端末を問わず Web 等からも入力可能とすること。

・

＇多発する災害に備え（事象と返信の対応関係がわかりやすいシステムとすること。

また、運用では、以下の点に留意する必要がある。

・

訓練を実施し、災害時の返答を徹底すること。

・

確実に連絡の取れる連絡先を登録すること。＇最新のもの、外出時も連絡可能なも の（

・

携帯電話がつながらなくても、緊急連絡網により、連絡が取れる体制を構築すること。

(2)災害時に発生する業務におけるシステム

今回の調査対象では事例が尐なかったが、災害時に発生する業務への対応システムとして、

被災地の現場の状況把握するための「被災状況把握システム」や、災害時指揮支援のための「発 動基準対応システム」を立ち上げた事例があった。

これらのシステムに対しては、耐震設計のデータセンターや二重化された場所に設置されてい ることもあり、今回の震災では稼働したようだが、災害時のみに稼働するためのシステムについて は、いざというときに稼働しない、使い方がわからない等の問題も指摘されている。

技術的対応としては、平時から利用するシステムの延長として災害時のシステムを構築する、

定期的な稼働確認をする等の対策が必要である。

また、組織的対応としては、定期的な訓練を実施することで、利用者が使い方を熟知しておく必 要がある。

(3)災害時に発生する特別な業務に対するシステム改修

災害時に直接システムに影響はないものの、業務が影響を受けることで、システムに改修が発 生する場合がある。

このような場合に有効な技術的対応としては、システム改修が速やかに実施できるような仕様 としておくことが有効である。また、組織的対応としては、社内に情報システムの内容を理解し、改 修できる担当者を設置しておくこと、あるいはベンダとのコミュニケーションを円滑に行っておくこと、

が有効である。