情報化された組織のセキュリティマネジメント WG 成果報告書

第1部「教育研究機関におけるICT 部門の事業計画」(BCP)

2012 年 5 月 11 日
サイエンティフィック・システム研究会
情報化された組織のセキュリティマネジメント WG
A グループWG メンバー■全体
担当幹事(まとめ役)

会員

推進委員(まとめ役)

賛助会員 推進委員
(富士通)

オブザーバ
■グループ別グループ
A グループB グループテーマ

氏名
長谷川 明生
山守 一徳
吉田 和幸
笠原 義晃
武蔵 泰雄
湯浅 富久子
鈴木 聡
只木 進一
西村 浩二
吉田 真和
山下 眞一郎
飯島 敏治
南場
進
山路 光昭
櫻井 秀志
田口 雅晴
須永 知之
山口 正雄

機関/所属(2012 年 3 月 31 日現在)
中京大学
三重大学
大分大学
九州大学
熊本大学
高エネルギー加速器研究機構
高エネルギー加速器研究機構
佐賀大学
広島大学
富士通(株)
富士通(株)
富士通(株)
富士通(株)
富士通(株)
富士通(株)(株)富士通九州システムズ(株)富士通ソーシアルサイエンスラボラトリ
富士通(株)

メンバー

BCP
情報漏えい

只木 進一 [班長]、湯浅 富久子、 西村 浩二、 山守 一徳、
山下 眞一郎、山路 光昭、櫻井 秀志、須永 知之

DNS鈴木 聡 [班長]、吉田 和幸、 笠原 義晃、 武藏 泰雄、 長谷川 明生、
吉田 真和、 飯島 敏治、 南場 進、 田口 雅晴

目次
第 1 部 教育研究機関における ICT 部門の事業計画
1. まえがき ··················································································· 1
2. 教育 ICT 部門にとっての BCP ·································································· 2
2.1 事前準備 ·············································································· 2
2.2 大規模災害以外への対応································································· 2
3. 教育研究機関 ICT 部門の特殊性································································ 3
4. BCP の基盤 ·················································································· 4
4.1 検討組織の構築 ········································································ 4
4.2 情報システム・サービスの現状把握 ······················································· 5
4.3 情報システム以外の施設設備の状況把握と対策 ············································· 7
4.4 重要情報バックアップ··································································· 8
4.5 初期行動計画立案······································································· 9
4.6 緊急連絡網 ············································································ 9
4.7 訓練 ················································································· 10
4.8 運用体制の構築と維持管理······························································ 10
5. 参考文献 ·················································································· 106. 添付資料について ·········································································· 11[添付資料]
 ○○大学の情報基盤業務継続のための基礎的対策計画 第 2 版（サンプル） 省電力への取り組み 〜事例紹介（広島大学）〜
 佐賀大学における電源管理事例
 スマートコンセント(FX‑5204PS)とゲートウェイ(FX‑5250GW/AD、FX‑5250GW/PE)による省エネ活動の促進
 IT 部門で考えるべき事業継続対策 〜大震災発生後の 1 年を振り返って〜 「東日本大震災発生時の情報管理部門の対応に関するアンケート‑アンケートまとめ‑アンケート集計結果‑アンケート依頼文■図表について冊子版は白黒のため見づらい図表がありますが、SS 研 Web サイトの PDF 版はカラーですので、詳細はそちらをご覧ください。
http://www.ssken.gr.jp/MAINSITE/ → 「資料ダウンロード」→ 「WG 関連資料」■登録商標について本書に記載されている会社名、機関名、製品名、各種名称などの固有名詞は、各社、各機関の商標または登録商標
です。

1

まえがき
事業継続計画 (BCP:Business Continuity Plan) とは、災害や事故で被害を受けた際に、重要業務をなるべく中断させず、中断したとしてもできるだけ早急に復旧させ、業務継続を実現させるための計画である。被害を想定し、その対策を行う、あるいはリスク評価の結果から対策を行わないなどの判断を行う、リスクマネジメント (Risk Management) とは異なり、災害が起こった後の対処計画である。
大学をはじめとする教育研究機関においては、多くの学生を抱え、学生の安否を速やかに把握し、教育業務が停止する期間を短く抑えることを目指すことが第一である。更に、大学は地域の中
核的公共機関であり、大学病院は地域医療の中心でもある。災害時には、大学は、地域医療だけでなく、避難及び災害復旧のセンターとして機能することが求められる。
情報化が進んでいる現在において、組織全体の BCP のなかでも、ネットワークやサーバを管理運営している情報 (ICT:Information and Communication Technology) 部門の復旧活動がキーとなることが予想される。広範囲の地域に及ぶ大地震や津波などの大規模災害の場合には、電力や水道などのライフライン復旧が第一に必要である。その後の復旧を円滑に進めるとともに、災害状
況、被災者の安否、支援体制、および復旧状況に関する情報の収集、情報交換、及び外部への情報提供の機能の基盤を ICT 部門が担うことになるであろう。したがって、組織全体の BCP が無くても、ICT 部門の BCP を事前に構築しておくことは、たいへん重要である。
本報告は、大学等の ICT 部門が BCP を策定するために必要な情報を提供することを目指すも
のである。

1

教育 ICT 部門にとっての BCP

2

大学全体の BCP の目的を明らかにしていくことで、様々な対処の優先順位を決める指針を定めておく必要がある。教職員、学生の安全確保が最優先であることは明らかである。また、復旧活動に様々な情報が不可欠であることから、ネットワーク等の情報基盤の復旧が重要となる。たとえば、認証データに基づいた安否確認、メールや Web を通じた情報伝達が災害直後に必要になる。また、
現在では、多くの業務がネットワークに依存し、様々なデータが電子媒体に保存されている。ICT
基盤の復旧は、大学全体の業務復旧の前提となる。つまり、大学全体の BCP の中で、ICT 部門のBCP は非常に重要であり、大学全体の BCP に取り組む一方で、ICT 部門だけでできる BCP を検討しておくことは、スムーズな復旧に欠かせない要件である。

2.1

事前準備

災害時等に迅速にサービスを復旧させるために以下の事前準備が必要である。

1. 体制の取り決め• 必要な人員の確保の仕方、BCP を発動させる基準を決める。
• 情報基盤の外部（ICT 部門以外の学内、業者など）への依存状況を整理する。
• 復旧作業などが外部に依存できない場合の対策を検討する。
2. 対象システムの把握• 全ての情報システムを同時に復旧することは不可能である。そのために、システム復旧の優先順位を事前に決める。
• システムの稼働条件を整理し、システム間の依存性を把握する。近年の分散型情報シス
テムの場合には、システムの依存関係が複雑になっている。
• システムの設置場所、電源やラックの状況についても把握する。
3. 準備可能な物• 災害時に備えた機材等の準備状況を確認し、整備する。

2.2

大規模災害以外への対応

大地震などの大災害の頻度は非常に少ない。しかし、そのための BCP を策定することで、日常的に発生する様々な災害・障害への準備が可能となる。

• 大規模災害以外にも、サイバー攻撃、予定外の停電、伝染病等による要員不足などにも対応できる準備が望ましい。

• サイバー攻撃では、攻撃を受けた場合だけなく、攻撃元になってしまった場合の対応も考えておかなければならない。
• 予定外の停電、電力会社の給電不足による計画停電の頻発、落雷や事故による電圧変動なども考えられる。
• 伝染病などによる、要員の不足の際の対応体制も整理が必要である。
2

3

教育研究機関 ICT 部門の特殊性
教育研究機関の ICT 部門には、以下の特殊性があり、BCP を検討する時に考慮する必要がある。

1. オープンソース化が進んでいる• 民間企業と比べると、オープンソース化が進んでいる。そのため、自組織によってメンテナンスしている割合が多く、自立性が高く、自力で復旧できる可能性がある。

• 同時に、復旧時に業者に応援していただくのが難しい可能性がある。
2. 多様・多数のサービス• 要員に対して、様々な多くのサービスを ICT 部門で稼働させている。しかし、その中でコアサービスの数は少ない可能性がある。

• コアサービスは何であるのか把握し、重要度・優先度を検討しておく必要がある。ネッ
トワーク、DNS、認証、Mail が最優先となるであろう。
3. 少ない人員• ICT 部門の人員は極めて少なく、日常的業務でも不足している。
• そのため、意思決定する時は容易ではある。
• 同時に、サービスの属人性が高い。キーとなる人材に頼りすぎているため、その人材が動けない場合には、事業継続が困難となりやすい。
• システム毎に複数の人員が対応できる準備ができていない場合もある。
4. 事務系との連携が悪い場合が多い• 大学では、命令系統が教学と事務に分かれ、教員職員と事務職員の間での連携が悪いことが多く、意志疎通がうまくいかない危険性がある。
• そのため、ICT 部門のセンターでできることが限られる。
• しかし、診療や事務もネットワークに依存しており、ICT 部門が、教学以外の重要情報システムを把握しておく必要がある。
• 大学病院は地域の中核医療施設であり、早急な復旧が必要である。病院の診療・業務は情報基盤に強く依存している。

5. わがままな利用者• 学内の利用者の方々から様々な要求が挙がり、わずかな人数の要求のためだけに振り回される可能性がある。

• 障害発生時の復旧のさせ方においても、恩恵を蒙る人数に応じて復旧されるとは限らない。
• BCP を作っておくことで、復旧の優先順位と範囲の学内合意形成が可能となる。

3

BCP の基盤

4

BCP の基盤として、以下の項目を検討する。
1. 検討組織の構築
2. 情報システム・サービスの現状把握
3. 情報システム以外の施設設備の状況把握と対策
4. 重要情報バックアップ
5. 初期行動計画立案
6. 緊急情報網
7. 訓練
8. 運用体制の構築と維持管理

4.1

検討組織の構築

まず初めに BCP の検討組織を作る。検討組織の構築に当たっては、以下のことに留意すべきである。

1. 全学的検討組織• ICT 部門の BCP ではあるが、ICT の恩恵を受けていない人は皆無であろう。
• 検討組織は一部の部門だけの寄せ集めではなく、全ての部門が関わることが望ましい。
ICT 部門の運営委員会などを通じて、学内の同意と学内への周知が必要である。
2. 全体を掌握しているコアメンバーで WG を作る。
• 検討事項が幅広いため、全体を掌握しているコアメンバーでワーキンググループを作る。
• 素案を十分に検討した後に、検討委員会で全体会議するのが望ましい。
3. センター定期打ち合わせなどで地道に策定• 素案作成は少しずつ行うことになる。
• ICT 部門の定期打ち合わせで議題に挙げ、地道に進める。
4. 大学や研究所むけ BCP のひな型があれば、活用する。

4

4.2

情報システム・サービスの現状把握

次に、以下の点に留意しながら、情報システム・サービスの現状把握を行う。

1. システム概要• システム構成の概要を把握する。
• 近年の分散型情報システムでは、後述するシステム間の依存性の把握も重要である。
2. 設置場所とその概要• サーバの設置場所とおおよそどういう場所なのかを把握する。
• ネットワークの経路やノードの設置場所もどういう場所なのかも把握する。
• ネットワークの線の経路およびその状況も普段より把握しておけば、災害時の断線推測する場合に役に立つ。
3. ハードウェア構成、保守業者• ハードウェア構成を把握し、保守業者に関する情報を収集する。
• 起動時に必要な電力や、稼働中のピーク電力を調べておく。
• 回線業者、機材ベンダー、保守業者等との関係を整理し、災害時の対応を協議しておくことが望ましい。
4. OS とアプリケーションのバックアップ状況• OS は何であるか、アプリケーションのバックアップはどのように行っているのかを調べる。
• 設定、データのバックアップ状態を調べる。
• バックアップの保管先・保管場所の調査も行う。
• 本当に必要なデータは何かを見極める。
5. システム停止・起動手順• システム間の依存関係に応じて、システムの停止及び稼働の順序を整理する。
• 各システムの停止及び稼働の手順を整理する。
6. 縮退運転の可能性• 計画停電や限られた電力の下での運転可能性を調査する。
• 残すサービスの洗い出し。
7. 再構築のコスト• 故障した場合、再構築するのにかかるコスト（費用、設備、時間）を把握する。
• 現実的時間でリストアできるかも考えておく。
8. 代替の可能性

5図 1: システムの依存性による階層化例• 代替えサーバで稼働させることが可能であるのかを調査する。
9. 当該システムが依存している他システム• 分散システムとなっているので、システム間の依存関係が重要である。
• 本システムが依存している他システムがないかを調べる。
• 復旧の順序を確かめる。
10. 本システムに依存している他システム• 本システムに依存している他システムがないかを調べる。復旧の重要度に影響する。
11. 作業できる職員• 復旧のために作業できる職員が誰であるかを調べる。
• 複数人が作業できるようになっていることが望ましい。
12. 全システムをやらなくても良い• 全システムを復旧させる必要がないかもしれない。災害時故障発生を機会に停止のままとなるシステムもあり得る。
図 1 には、システムの依存性による階層化の例を示す。停止時には、上から下へ、起動時には下から上へ作業する。また、縮退運転時には、下の三層と左端の「共通サービス」の重要なものを
残す。

6

4.3

情報システム以外の施設設備の状況把握と対策

情報システムは、稼働させるために電力などが必要であるため、以下の観点での調査把握が必要である。

1. 設置場所の環境• 設置場所の耐震性などを把握しておく。
• 災害時に状況推測しないといけない場合に役に立つ。
2. 主要設備• 設置場所は、何が整っている場所にあるのか。
• 建物設備についても把握しておく。
3. ラックの状況• ラックの耐震固定状況、ラックの中の空き状況などを把握しておく。
• 復旧時に必要な部品が推測しやすくなる。
4. 電力• 外部電源を使えるか。外部電源で稼働可能なシステム、時間を調べておく。非常用電源
を ICT 部門で保有することは困難な場合が多いが、外部電源を取り込む準備があるかを確認しておく。

• 個々のブレーカーに繋がっている装置はどれか、各コンセントはどのブレーカーに繋がっているのか、ブレーカーの最大アンペアなども調べておく。
• システム更新時には調査されているが、その後の変更が分からない可能性が高い。
5. 通信手段• 現場間で連絡を取って復旧作業に当たる必要がある。
• 固定電話や携帯電話などの通信手段を調べておく必要がある。
• トランシーバなど、携帯電話が使えない際の要員間の作業時の連絡手段を用意しておく。
6. 通信回線• 外部接続の回線の状況、キャリア、迂回路を確認しておく必要がある。
• 可能ならば、複数回線を持つ。とくに、病院はバックアップ回線が欲しい。
• 学内の建物・キャンパスを結ぶことができる無線 LAN 装置等を持っておくと安心。
表 1 は、電源とコンピュータを紐付けるための電源管理表の例を示す。

7

4.4

項目名

表 1: 電源管理表の項目
内容

根元電源

配電盤等、無停電電源装置への電源供給元

UPS 設置場所

無停電電源装置が置かれているラック名等

UPS 型番

無停電電源装置の製造元と型番

接続ホスト名

無停電電源装置に接続しているホスト名

ホスト用途

ホストの用途IP Address

ホストの IP アドレス

ハードウエア担当組織

当該ホストのハードウェア管理責任部署 (学外を含む)

学内管理者

ホストの学内での管理責任者

メーカー

ホストのハードウェア製造元

機種

ホストのハードウェア機種と型番

ホスト設置場所

ホストのハードウェアを設置している場所

電源定格

ホストのハードウェアの定格電力

備考

電源二重化などの情報を記載

重要情報バックアップ

バックアップが重要であることは明らかであるが、以下の点を再度確認する。

1. 現状把握と対策• 普段の運用状況を確認する。
• バックアップの不備が見つかれば対策を取る。
2. バックアップ方式• 媒体は何を用いているかを整理する。
• その媒体を読み取る装置自身の故障対策があるかを調べる。
3. バックアップの内容• バックアップに漏れはないのか、復旧させるのに必要なバックアップが揃っているかを確認する。
4. バックアップ頻度• バックアップの頻度は適切であるのかを確認する。
5. バックアップ保管場所• 保管場所自身の耐震性や防火性、防水性、盗難防止度合いなどの確認を行う。
• サーバと同じ場所ではなく、遠隔地への保管、大学間での相互保管などを検討する。

8

4.5

初期行動計画立案

災害時の初動活動を計画立案しておくことが重要である。

1. 緊急連絡体制• 緊急連絡網を取り決め、連絡が付かない場合の対処策まで用意しておくこと。
• 連絡網は伝達が途絶えることがあり得る。その対策が必要である。
2. 連絡先一覧• 全構成員が持ち歩けるような、個人情報を無くしたものも用意する。
• 出勤経路 (徒歩で来れるかなど) も把握しておく。
• 組織内だけでなく、業者への連絡先も複数人で一覧を管理していることが望ましい。
• コアメンバーが徒歩で参集できるかを確認しておく。
3. 事象、時間帯による体制• 発生事象によって、初期活動が異なる。
• 発生時刻の時間帯によっても、初期活動が異なる。
• 場合分けにより取り決め、周知しておく必要がある。
4. 被害・状況の把握内容と手順• 遠方からの僅かで不確かな情報しか入手できない場合が多い。
• 情報を出す側の技能レベルが期待できないだけでなく、情報を受ける側も人材不足から技術レベルが十分でない場合も想定される。

• 状況把握を行う手順を用意しておくと良い。
5. 復旧、代替の手順• 復旧の手順や代替品を用意する手順を取り決めておく必要がある。
• 命令を出す指揮系統も混乱していることが想定される。
• 手順が事前に用意されていれば、初動活動がスムーズに適切に行うことができる。

4.6

緊急連絡網

1. 安否確認システム• 全構成員に一斉メールを送る。
• 携帯電話アドレスをどうやって更新しておくかが課題となる。
• 緊急目的だけのシステムは、いざという時に使えない恐れがある。日常的に使用するシステムの一部としておくことで、携帯電話アドレスの更新を図り、稼働テストを日常的に行うことができる。

2. 緊急情報サイトの準備
9

4.7

訓練

日頃より訓練しておくことが必要である。訓練は、BCP の見直しの機会として有用である。

1. 机上訓練• 小さなグループ単位で、対応手順の確認を机上で行う。半日程度でも十分である。
2. システム復旧作業訓練• 再構築の実施をしてみると良い。
3. シナリオによる訓練• 災害時のシナリオを作って、業者も含めた連絡伝達訓練、故障原因調査訓練などを行う。
• シナリオは、訓練当日まで明かさない方が良い。

4.8

運用体制の構築と維持管理

BCP を策定しておくことは、日頃の運用体制の見直しや維持管理の仕方の決定に大変役立つ。
1. 役割確認• ICT 部門内での役割分担を明確化しておく。
2. 定期見直し• 組織変更時だけでなく、サポート業者内の人事異動時、ICT 部門内での人事異動時など、人的体制の確認を行う必要がある。

• システム更新時や、新規システム導入時、旧システム廃止時など、システム構成の見直
しを BCP の観点からも詳細に行う必要がある。

• 設置場所の変更やサポート業者内の変更など、環境要素に変更があった時に、維持管理の仕方や運用体制の見直しを行う必要がある。
3. バージョン管理• バージョンアップを行った時、確実にバージョン管理を行うこと。

5

参考資料• 内閣府「中央省庁業務継続計画」
http://www.bousai.go.jp/jishin/gyomukeizoku/• 総務省「地方公共団体における ICT 部門の業務継続計画 (BCP) 策定に関するガイドライン」
http://www.soumu.go.jp/menu_news/s-news/2008/080821_3.html• 中小企業庁「中小企業 BCP 策定運用指針」
http://www.chusho.meti.go.jp/bcp/• 経済産業省「事業継続計画 (BCP) 策定ガイドライン」
http://www.meti.go.jp/policy/netsecurity/downloadfiles/6_bcpguide.pdf
106

添付資料について• 「○○大学の情報基盤事業継続のための基礎的対策計画」– 総務省「地方公共団体における ICT 部門の業務継続計画 (BCP) 策定に関するガイドラ
イン」を基に、大学という組織や大学の情報基盤に対応できるように作成したサンプル• 電源管理・縮退運転の事例– 広島大学における省電力への取り組み、および、佐賀大学における電源管理事例• 富士通の電源管理ソリューション
– スマートコンセントとゲートウェイによる “消費電力の見える化” 実現で省エネを促進する方法の紹介• 富士通の「IT 部門で考えるべき事業継続対策」– 東日本大震災での富士通の対応やお客様の実態をふまえ、IT 部門で考えるべき事業継続対策をまとめたもの• 東日本大震災発生時の情報管理部門の対応に関するアンケート– アンケートまとめ– アンケート集計結果– アンケート依頼文

11

○○大学の情報基盤業務継続のための基礎的対策計画
第2版(サンプル)○○大学情報基盤センター
2011 年 4 月 1 日

1

表 1: 計画の改定一覧
内容
承認者

版

日付

暫定

2010/4/1

暫定的計画

センター長 佐賀太郎

初版

2010/10/1

初版

CIO 大学一男

第2版

2011/4/1

クラウドへ対応

CIO 大学一男(注意)• 本計画を改定 (一部改定を含む) した場合には、旧計画を速やかに回収し、新計画を配布するものとする。旧計画は情報基盤センター事務部門 (事務局情報企画室) にて保管する。
• 計画の改定は、上記履歴にて管理する。
• 本計画 (原本) の原本は情報基盤センター事務部門にて保管する。
• 本計画 (写し) は、情報基盤センター、情報基盤センター医学サブセンター、事務局情報企画室、事務局総務部総務課にて保管する。
• 本計画の写しを、センター長、副センター長、事務局情報企画室長、事務局総務部総務課長
が自宅に保管する。

• 自宅に本計画の写しを保管するものの異動があった場合には、速やかに後任者にひき継ぐ。

目次
第 1 章 趣旨・基本方針

1.1
1.2

1

趣旨 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
基本方針 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2.1

情報基盤センターの責務遂行

1.2.2
1.2.3

学生、来訪者、職員、関係者の安全確保 . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

計画の有効性の維持・改善 . . . . . . . . . . . . . . . . . . . . . . . . . . .

第 2 章 緊急対応

2.1

緊急時対応体制 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1.1
2.1.2

センター長 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
対応要員と参集ルール . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
外部事業者 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.3
4.4
4.5

3
3
3
3

緊急時における行動計画 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
緊急連絡リスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4
4
9

2.1.6

被害チェックリスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1011

リソースの現状 (脆弱性) と代替の有無 . . . . . . . . . . . . . . . . . . . . . . . .

第 4 章 業務継続計画の運用体制

4.1
4.2

1
2

2.1.3
2.1.4
2.1.5

第 3 章 被害を受ける可能性と事前対策計画

3.1

1
1
1

12

体制 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
見直し . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
見直しルール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
見直し項目

11

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

訓練計画 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

0

12
12
12
12
13

第1章

1.1

趣旨・基本方針趣旨「業務継続計画」とは、大規模な災害、事故、事件等（以下、「災害事故」と略称する。）で○○大学の校舎、職員等に相当の被害があっても、情報基盤センターの担う重要業務をなるべく中断させず、中断してもできるだけ早急に（あるいは、許容される時間内に）復旧させるために策定するものである。
○○大学情報基盤センターが平常時に提供しているサービスが長期間停止した場合、○○大学の教育、研究、診療、組織業務などの活動に大きな支障が生じる。また、災害・事故の発生時は、たとえ校舎、職員等に相当な被害が発生しても、地域の公共施設として、災害応急対応、災害復旧の業務を実施しなければならない。このため、災害・事故時においても○○大学の業務を実施・継続できるような周到な備えが不可欠である。
そして、このような○○大学の業務の実施・継続には、今日において、その業務を支える情報シ
ステムやネットワーク等の稼働が必要不可欠である。また、情報システムやネットワーク等は、あらかじめ対策を講じておかないと、災害・事故の発生後から対策を始めるのでは、必要な機能を稼動できないことはもとより、早期復旧も困難であるという特性を持つ。そこで、全学的な業務継続計画が必要との認識を持ちつつも、まずは「○○大学の情報基盤業務継続のための基礎的対策計画」を先行して策定し、災害事故時の重要業務の実施継続を行うための基盤を整えることとする。
また、初版においては地震を対象リスクとしているが、今後、対象リスクを広げて、どのような事象に対しても継続対応ができるように努めていく。

1.2

基本方針

1.2.1

情報基盤センターの責務遂行

災害・事故時の業務の継続早期復旧に当たっては、情報基盤センターとして基幹業務に必要なシステムを早期復旧する。

1.2.2

学生、来訪者、職員、関係者の安全確保

災害・事故時の業務の継続・早期復旧に当たっては、学生、来訪者、職員、契約先職員その他の関係者の安全確保を第一とする。

1

1.2.3計画の有効性の維持・改善

本計画は、毎年、適切に関係者に周知し、訓練を行い、また常に最新の状況を反映した計画となるよう点検を行う。そして、それらの結果を踏まえて是正措置を講ずるとともに、少なくとも年に1 度定期的に (前提条件に大きな変更があればその都度) 、計画の全般にわたる見直しを行う。

2

第2章

緊急対応

緊急時対応体制

2.1

大規模な災害・事故が発生した場合に、事前に定められた指揮命令系統にしたがって、正確に情報が収集・伝達され、的確に対応の指示や復命がなされるように、以下の組織体制で活動する。

2.1.1

センター長

本計画に従った緊急時対応の責任者として、以下の役割を担当する。

• 情報基盤センターの業務継続に関わる調査や対応活動の開始と終了の判断及び指示• 情報システムの業務継続に関する方針や方法の意思決定• ○○大学の災害対策本部への状況報告と本部決定事項の部門内への伝達1• 他の業務部門との調整の総括、支援依頼センター長が不在の場合は、副センター長が役割を担当する。センター長、副センター長がともに不在の場合は事務局情報企画室長が役割を担当する。

2.1.2

対応要員と参集ルール

全員参集
職員 (非常勤を除く) は、次の場合には、全員自動参集とし、全員が対応要員となる。

• ○○市内で震度５強以上の地震が発生した場合• 復旧見込みの立っていない大規模ネットワーク障害、停電が大学周辺で発生したことが報道
された場合
安否確認

• 安否確認担当者は、事務局情報企画室長、その代理は事務局情報企画室係長とする。
• 安否確認の作業は、就業時間内は執務室で行う。夜間休日の場合、執務室に出勤して行うことを原則とするが、校舎に入れない場合、参集ができない場合等については、自宅で行う。
1 CIO、CISO との関係の整理が必要

3

• 職員は、自動参集に該当する災害事故の発生時には、安否確認担当者に安否の連絡を行う。
• 安否確認担当者は、連絡のない職員に対して継続的に連絡を試みる。
• 安否確認の詳細は、安否確認マニュアルによるものとする。

初期対応による自動参集
震度 4 以上 5 弱以下の地震が発生した場合は、以下の初期対応要員が自動参集し、情報通信機器等の被害状況をセンター長に報告する。その後の対応は、センター長の指示に従う。
初期対応要員は鍋島次郎、嘉瀬一子とする。

その他
その他、時間外における、情報基盤センターの停電、外部からの不正侵入の検知などがあった場
合には、それらを検知した者がセンター長に報告し、その後の対応は、センター長の指示に従う。

2.1.3

外部事業者

A 社、B 社、及び C 社においては、○○市内で震度 6 強以上の地震が発災した場合は、自動的に自社に参集することとしている。外部事業者の連絡先の情報の確認及び支援の要請に関して事前に調整する。
年次の計画見直しにおいて、協力関係の維持に関して各社に確認すること。システム更新等により協力関係を結ぶ企業に変更があった場合は、同様の協力関係を構築するように努める。

4

2.1.4

緊急時における行動計画

参集要領
情報基盤センターの職員は、2.1.2 により参集し、システムの被害状況確認、対応活動を開始する。

実施項目 (初動対応項目)
就業時間内の場合

#

内容

確認

1

学生・来訪者・職員等の負傷者対応、誘導

備考

情報基盤センター内及び周辺の学生、来訪者、職員（契約先職員等を含む。以下同じ。）で負傷しているものへの応急措置を行う。また、重傷者以外の学生、来訪者については、次項の避難の必要性がない場合には、適切な場所へ誘導して集め、そこに当分の間、とどまるよう要請する。

2

校舎からの避難
避難指示があった場合又は校舎にとどまっていると危険と判断される場合には、学生、来訪者、職員を校舎の外の安全な場所に退避させる。学生、来訪者については、適切に誘導する。

3

初期消火、延焼防止措置等の二次被害防止策
情報基盤センター及びその周辺で火災が発生し、初期消火が有効であると判断される場合には、火災の発生を校舎管理部門に至急連絡するとともに、可能な範囲内で初期消火を行う。
校舎内で小規模な火災が発生し、緊急避難が必要でない場合には以下の措置を講ずる。

• 防火扉を閉鎖し、煙の侵入や延焼を防止する。鎮火後に、復旧等の対応活動を開始する。
• 緊急用システムを除くサーバ類を一旦停止する。
4

職員その他関係者の安否確認
避難の必要がなく、負傷者対応、二次災害の防止への対応以外に手が空く要員が確保でき次第、センター長又はその指名する者が、点呼により職員の安否状況を確認する。情報基盤センターへの来訪者についても、職員に誰が来訪していたか報告させ、漏れなく安否を確認すること。センター内に居た学生についても、○○に基づき、もれなく安否を確認すること。2

5

緊急連絡網

#

内容

確認

備考

外出者や休暇中の職員がいる場合は、固定電話、携帯電話又は携帯メールで連絡がつく範囲で安否確認を行う。ただし、至急連絡を取る必要がなければ、ある程度落ち着いてからでもよい。
外出者や休暇中の職員の安否が確認できない場合は、災害時伝言ダ
イヤル（171）を活用し、部門番号（0xx-xxx-xxxx）で登録された情報が無いかを確認する（なお、平常時より、171 は災害時に活用するよう職員に周知しておくこと）。
センター長は、災害対策本部へ情報基盤センターの安否確認結果を報告する。報告時間に定めがない場合、途中経過でよいので、本部の立上げを見計らって第一報をする。

5

重要書類・データ類の保護
情報基盤センターのフロアから退去が必要な場合（ただし、危険が迫り至急避難する場合を除く）、校舎の損傷で漏水等が懸念されるなど、重要書類、バックアップ媒体等が損傷するおそれのある場
合は、それらを校舎内の安全な場所に移動させるか、校舎外へ持ち出す。
重要書類やデータが損傷した場合、あらかじめ保管してあるバック
アップ媒体を活用して、業務継続に必要な情報の復元処置を行う。

6

外部事業者（保守ベンダ等）との連絡確保
保守ベンダ等の至急対応を要請すべき外部事業者との連絡手段を確連絡先一覧保する。固定電話、メール、災害対策本部の災害時優先電話、携帯
電話、携帯メールなどによる。そのほか、職員・外部事業者の従業員による直接の往来（状況によっては自転車等を利用）などあらゆる手段を使用する。
業務継続に必須の外部事業者の要員については、連絡先一覧を参照
して、連絡手段を必ず確保する。

7

被害状況の調査
被害チェックシートを使用して情報システム、インフラに関する被被害チェック

害を確認し、必要な報告を行う。

シート

倒壊の危険がある校舎、二次災害が発生している校舎の場合、情報基盤センターとしては、入館可能かどうか校舎管理部門に確認する。
被害状況は時間の経過により変化するため、継続的に監視を行う。

8

業務継続・代替復旧活動の開始判断
センター長は、被害情報の報告結果及び要員の参集状況を考慮して、どのような業務継続の対応活動を開始するかを判断する (一部の業
務継続の活動の開始の判断は、例えば情報が十分にそろうまで、後刻に先送りすることも考えられる)。

6

#

内容

確認

備考

確認

備考

全学の災害応急、復旧活動と整合を取りつつ、開始を決定した対応
活動に必要な要員を指名し、情報システムの業務継続の体制を確立する。
就業時間外の場合#

内容

1

自己及び家族の安全の確認
災害・事故発生時においては、自己及び家族の安全の確認後、自宅の火災発生などの二次災害の防止を講じた上、次項の自動参集対応に入る。
速やかに安否確認担当者に安否の連絡を行い、可能であれば出勤できる時間のメドも伝える。すぐにつながらない場合には、一定時間ごとに連絡を試みる。
自己又は家族が負傷した場合、自宅が大きく損傷した場合などは、参集できない旨を連絡する。

2

自動参集対応震度×以上の地震の場合、全員が自動参集する。震度はラジオ等で確認するが、確認できない場合、まずは参集を開始する。
参集に当たっては、通勤途上の安全に配慮し、靴、服装などに留意する。また、水、食糧を持参するよう努める。
規定の集合場所に自動参集する。集合場所から距離があり、公共交
通機関が途絶している場合、参集するかの判断は、別に定める基準に従う（別途、参集基準を定めておく）。
自宅周辺及び参集途上において、救助の必要がある被害者がいる場
合、参集すべきか救助に当たるべきかの判断は、別に定める基準に従う（別途、参集基準を定めておく）

3

職員、関係する要員の参集状況及び安否の確認
情報基盤センターの職員の参集状況及び未参集者の安否確認を行う。

• 安否確認担当者も出勤してに安否連絡を行う。
• 連絡がない職員には安否確認担当者が連絡を行う。
• 緊急連絡網に記述されている保守ベンダの責任者へも同様に連絡を行う。

2 センター内に居た学生の情報をどのように確保するか

7

緊急連絡網

#

内容

確認

備考

安否が確認できない職員がいる場合、災害時伝言ダイヤル（171）を活用し、部門番号（0xx-xxx-xxxx）で登録された情報が無いかを確認する（なお、平時より 171 は災害時に活用するよう、あらかじめ職員に周知すること）。
センター長は、災害対策本部へ情報基盤センターの安否確認結果を報告する。報告時間に定めがない場合、途中経過でよいので、本部の立上げを見計らって第一報をする。

4

重要書類・データ類の保護
情報基盤センターのフロアから退去が必要な場合（ただし、危険が迫り至急避難する場合を除く）、校舎の損傷で漏水等が懸念されるなど、重要書類、バックアップ媒体等が損傷するおそれのある場
合は、それらを校舎内の安全な場所に移動させるか、校舎外へ持ち出す。
重要書類やデータが損傷した場合、あらかじめ保管してあるバック
アップ媒体を活用して、業務継続に必要な情報の復元処置を行う。

5

二次被害防止策の実施
火災など二次災害が発生している場合は、一時的に緊急用システム
を除くサーバ類を一旦停止し、災害での混乱が落ち着いた後、復旧を開始する。

6

外部事業者（保守ベンダ等）との連絡確保
保守ベンダ等の至急対応を要請すべき外部事業者との連絡手段を確連絡先一覧保する。固定電話、メール、災害対策本部の災害時優先電話、携帯
電話、携帯メールなどによる。そのほか、職員・外部事業者の従業員による直接の往来（状況によっては自転車等を利用）などあらゆる手段を使用する。
業務継続に必須の外部事業者の要員については、連絡先一覧を参照
して、連絡手段を必ず確保する。

7

被害状況の調査
被害チェックシートを使用して情報システム、インフラに関する被被害チェック

害を確認し、必要な報告を行う。

シート

倒壊の危険がある校舎、二次災害が発生している校舎の場合、情報基盤センターとしては、入館可能かどうか校舎管理部門に確認する。
被害状況は時間の経過により変化するため、継続的に監視を行う。

8

業務継続・代替復旧活動の開始判断
センター長は、被害情報の報告結果及び要員の参集状況を考慮して、どのような業務継続の対応活動を開始するかを判断する (一部の業
務継続の活動の開始の判断は、例えば情報が十分にそろうまで、後刻に先送りすることも考えられる)。

8

#

内容

確認

備考

全学の災害応急、復旧活動と整合を取りつつ、開始を決定した対応
活動に必要な要員を指名し、情報システムの業務継続の体制を確立する。
就業時間外であって開館している場合• 職員が在室していた場合– 在室していた職員は「就業時間内の場合」初動手順 1 から 3 を実施する。その後、ただちにセンター長に報告する。

– 在室していない職員は、「就業時間外の場合」に従って、自動参集に対応する。
• 職員が在室していない場合– 職員は、「就業時間外の場合」に従って、自動参集に対応する。
– センター長は、開館のためのアルバイト学生に安否確認を行い、指示をする。

2.1.5

緊急連絡リスト「スタッフの状況と緊急連絡先」を別紙により作成する。また、個人情報を最小限とした「持ち出し用緊急連絡先」を別紙により作成し、携行する。

92.1.6

被害チェックリスト
分類

項目

被害

要員安否

死者

名

行方不明者

名

負傷者

名

参集者

名

参集予定者

名

ライフライン

情報基盤センター

情報基盤センター医学サブセンター

事務局情報企画室

電気

あり・なし

ガス

あり・なし

水道

あり・なし

電話

あり・なし

建物被害

あり・なし

サーバ室被害

あり・なし

電源設備

あり・なし

空調設備

あり・なし

通信設備

あり・なし

建物被害

あり・なし

サーバ室被害

あり・なし

電源設備

あり・なし

空調設備

あり・なし

通信設備

あり・なし

建物被害

あり・なし

サーバ室被害

あり・なし

電源設備

あり・なし

空調設備

あり・なし

通信設備

あり・なし

• 要員の個々の安否は「スタッフの状況と緊急連絡先」(別紙) で行う。
• 情報システム個々の被害状況は「システム状況一覧」(別紙) で行う。

10

第3章

3.1

被害を受ける可能性と事前対策計画

リソースの現状 (脆弱性) と代替の有無

別紙によりリソースの状況を整理し、更新する。

• システム状況一覧• 建物• ラックの設置状況• スタッフの状況と緊急連絡先• 業者一覧
• 現状の脆弱性と対策計画
• 問題点

11

第4章

4.1

業務継続計画の運用体制

体制

センター長は、情報基盤センターの事業用継続計画の運用の責任者であり、事業継続計画の立案、対策の実施と状況を確認するとともに、事業継続計画に関する教育・訓練を統括する。
情報基盤センターのメンバーは、平常時に事業継続計画の維持管理として、定期点検、見直しを行う。また、対策状況の把握、改善、及び確認を行う。教育・訓練に参加し、事業継続計画を実質
化する。

4.2

見直し

事業継続計画は、年度ごとに最新性と正確性を確認する。また、システム更新時に、全面的な確認及び見直しを行う。ただし、以下のように見直しの必要が生じた場合には、確認及び見直しを行う。

• 組織体制の変更• 制度等の改訂• システム更新以外のシステム構成の大幅な変更

4.3

見直しルール

年度ごとの見直しを行った場合には、センター長の承認の後、改訂記録に記述する。システム更新時及び大規模な見直しを行った場合には、センター長の確認の後、CIO の承認を得て、改訂記録に記述する。

4.4

見直し項目

年度ごとの見直し項目を表 4.1 に示す。人事異動及び外部事業者の担当者移動への対応は、逐次行うこと。
システム更新が行われた際の見直し項目を表 4.2 に示す。

12

表 4.1: 年度毎の見直し
チェック

項目

補足

人事異動や組織変更による事業継続要員の変更はないか
要員やベンダ等の電話番号やメールアドレスの変更はないか
計画書がすべて最新か
復旧用媒体、復旧手順が準備されているか
非常用電源、UPS、非常用通信手段が使用できるか
外部事業者との関係を確認する
机上訓練が実施されたか訓練によって判明した課題が解決されたか

表 4.2: システム更新時見直し
チェック

項目

補足

新システムに対応して変更は必要ないか検討された課題への対策・改善が実施されているか

予算等の課題外部事業者との関係の進捗を確認する

4.5

訓練計画

机上訓練：センター長、教員及び技術職員、常勤事務職員が参加し、事業継続計画書を読み合わ
せ、各要員が緊急時に行うべき行動を確認する。
システム復旧訓練:バックアップデータからリカバリできるか、及びそれに要する時間を確認する。

13

システム状況一覧
対象情報システム
名称

サービス
内容

主管部門

ネットワー コアスイッ 情報基盤
ク基盤
チ
センター

ハードウェア

設置場所
建物

機種名

情報基盤 Cisco
センター本 Catalyst
館
6509

再イン
ストー
代替機
ル可能 分類
ラック等 保守業者
性

○○ネッ
トワーク
なし 対象外 設定内容
ラック１
システム
ズ

ネットワー DNSサー
バ
ク基盤

情報基盤
可
××シス
情報基盤
Sun Fire
ラック１
なし
センター本
テム
センター
X2100
館
可

ユーザ
データ
ベース

△△コン
情報基盤
情報基盤
Sun Fire可センター本
ラック１ ピューティ なし
センター
X2100
ング
館
可

LDAP
主サーバ

情報基盤
△△コン
可
情報基盤
Sun Fire
センター本
ラック１ ピューティ あり
センター
X2100
館
ング
可

認証基盤

認証基盤

電子メール

IMAP
サーバ

利用者ファ
イル

メイン
ファイル
サーバ

バックアップ状況
バッ
ク
媒体 場所
アッ
プ
あり

CD

あり

CD

設定内容・データあり

CD

OS及びアプリCD

OS及びアプリ

あり

管理者
主

副

復旧手段

備考

情報基盤セ
鍋島次郎 三日月二郎
ンター本館
情報基盤セ
ンター本館
三日月二郎 鍋島次郎
情報基盤セ
ンター本館
情報基盤セ
ンター本館 三日月二郎 鍋島次郎

コアスイッ
チ
DNSサー
バ

設定内容・データなし
OS及びアプリあり

設定内容・データあり

可OS及びアプリ
情報基盤
△△コン
情報基盤
Sun Fire
センター本
ラック１ ピューティ あり
センター
X2100
可
設定内容
館
ング
対象外 データ
情報基盤
△△コン
情報基盤
可
OS及びアプリセンター本 NetApp ラック１ ピューティ なし
センター
館
ング
対象外 データ

CD
CD

あり

CD

あり

CD

他システムへの依存

情報基盤セ
ンター本館
佐賀太郎
情報基盤セ
ンター本館
情報基盤セ
ンター本館
情報基盤セ 鍋島次郎
ンター本館

鍋島次郎

嘉瀬一子

ユーザ
データ
ベース

ユーザデー
タベース内
に準備済み

旧機材あり

LDAP
主サーバ

なし
あり
なし

CD

情報基盤セ
ンター本館 鹿島末男

嘉瀬一子

DNSサー LDAP
バ
主サーバ

建物
名称
情報基盤センター本館
情報基盤センター医学部分館
事務局情報企画室

新耐震基
耐震診断 耐震改善 洪水の可
延焼の可 入退室管
耐震補強
防火設備
非常電源
準
結果
予定
能性
能性
理
1990 未対応 不明
問題なし なし
あり
通常
低
ICカード あり1990 未対応 済
問題なし なし
なし
通常
低ICカード あり
磁気カードなし
1980 未対応 不明
不明
なし
あり
通常
低

建築時期

ラックの設置状況
名称
ラック１
ラックM１
ラックR

設置場所
場所詳細 耐震
情報基盤センター本館
西側右端 ボルト止め
情報基盤センター医学部分館 北側
ボルト止め
情報基盤センター本館
東側中央 なし

UPS能力 電源取り出し
6000W
LP1
6000W
LP1
3000W
LP2

スタッフの状況と緊急連絡先
管理者氏名 職

メールアドレス佐賀太郎

センター長 taros@cc.****-u.ac.jp

鍋島次郎

准教授

jiron@cc.****-u.ac.jp

嘉瀬一子

係長

ichikok@cc.****-u.ac.jp

三日月二郎 技術職員

mikazuki@cc.****-u.ac.jp

鹿島末男

kasima@cc.****-u.ac.jp

准教授

勤務場所

職場電話

情報基盤セン
28-****
ター本館
情報基盤セン
28-****
ター医学部分館
事務局情報企28-****
画室
情報基盤セン
28-****
ター本館
情報基盤セン
28-****
ター本館

居住地
自宅電話
域

携帯電話

市内

090-****-**** taro@****.ne.jp taro@****.co.jp

0952-**-****

携帯メール

私用メール

福岡市 092-***-****

090-****-**** jjjs@***.ne.jp

小城市 092-***-****

090-****-**** ichikase@***.ne.jp

市内

0952-**-****

090-****-**** mikamika@***.ne.jp

市内

092-***-****

090-****-**** kasikasi@***.ne.jp

業者一覧

業者名

担当者

○○ネットワークシステムズ
福岡太郎
××システム佐賀一郎△△コンピューティング
長崎太郎

電話番号

地域

090-***-**** 福岡市
市内
長崎市

メールアドレス 携帯電話

契約状況
携帯メー
ル
災害時SLAの
対応責任
有無
なし
免責
あり
責任あり
なし
免責

サービス継続
への対応
あり
なし
なし

現状の脆弱性と対策計画
対策後のレベ 必要予算 (千
実施目標
ル
円)
情報基盤センター 耐震レベルが 施設課を通じ 耐震レベルの要調査
2011年度
本館
不明
て確認する
判明
耐震ボルト無 耐震ボルトに 耐震ボルト留ラックR
200 2011年度
しよる固定
め
ユーザデータベース
バックアップ態 定期バックアッないなし
2011年度のバックアップ
勢プが行われる
手回し充電器ない
購入と配布
3台
10 2012年度
主担当者が退 運用方法引き 主担当者の変
IMAPサーバの運用なし
2012年度
職予定
つき
更
対象

現状レベル

対策内容

担当者
佐賀太郎
三日月二郎
三日月二郎
嘉瀬一子
鍋島次郎

問題点
問題点の内容現状
電子メールシステムのハー
災害時のSLA契約がない
ドウェア保守業者との関係
データバックアップの場所 センター内にしかない

当面の対策と効果検討スケジュール

担当者

現状のSLの確認

平成23年度以降

鍋島次郎

サブセンターへの移送

平成23年度以降

鹿島末男

持ち出し用緊急連絡先
氏名
佐賀
鍋島
嘉瀬
三日月
鹿島

自宅電話
0952-**-****
092-***-****
092-***-****
0952-**-****
092-***-****

携帯電話
携帯メール
090-****-**** taro@****.ne.jp090-****-**** jjjs@***.ne.jp090-****-**** ichikase@***.ne.jp090-****-**** mikamika@***.ne.jp090-****-**** kasikasi@***.ne.jpੲਾ৲औोञੌ௶भ७य़গজॸॕঐॿ४ওথॺ:*ਛટਾઔછ੄ਗ਼ৡषभ਄ॉੌा‫ ع‬হ୻ງஂ‫ઁق‬ਣপ৾‫ع ك‬ઇ୘ଢ଼஢ਃঢ়पउऐॊহ঵ಲਢੑ઺ੁ৒प
਱ऐञ਄ॉੌा
ੲਾওॹॕ॔ઇ୘ଢ଼஢७থॱ‫ش‬

੄ਗ਼ৡषभ਄ॉੌाy තਗ਼ॳকঞথ४‫ઁق‬ਣপ৾भ੄ग़ॿৌੁ‫ك‬t KWWSZZZKLURVKLPDXDFMSWRSLQWURVHWVXGHQt ಒ਋ऊैಲਢघॊ਄ॉੌाٔ෈਋भ਄ॉੌाy ੲਾওॹॕ॔ઇ୘ଢ଼஢७থॱ‫ش‬दभ਄ॉੌा
t KWWSZZZPHGLDKLURVKLPDXDFMSQHZVHFRLQIRt ३५ॸ঒଑োभ੦ম্ଉy ਗ਼৕ੑ઴ਃ३५ॸ঒ಌৗ੦ম্ଉ‫ق‬਴ਛফাੁ৒‫ك‬पَ੄ग़ॿঝॠ‫ش‬ਃஓभ଑োउेल೽ਏपૢगञ१‫ش‬ংभೠ୐ઈૡُ
॑৥੶t ੄ਗ਼ৡ३५ॸ঒भ༎௮y ਴ਛফাेॉ‫ؚ‬ৗਗ਼৕ੑ઴ਃ३५ॸ঒༎௮র

t ఻৬ੁ‫ق‬਴ਛফাेॉದઃৰ઱‫ك‬y ಒ਋೬ၿ਋৑রभ१‫ش‬ংभೠ୐ઈૡy १‫ش‬ং஼पॿॵॺড‫ش‬ॡৌૢആဒ২ੑ॑ਝ઼ख‫ؚ‬૬৹भ૾ய॑
૰ଳ‫ق‬৯ఏக॑‫ع‬٦पਝ৒‫ك‬y ઇ୘৷ੲਾഈଜभ੄ਗ਼ৡਝ৒‫ق‬ঔॽॱ຤২‫ؚ॔‬ॖॻঝॱॖ
঒॔क़ॺী‫ڀك‬ഈଜ઎दዓ୾ྩমীभచ੖஍ટ


ੲਾ৲औोञੌ௶भ७य़গজॸॕঐॿ४ওথॺ:*

ਛટਾઔછ



ೠ୐ઈૡ
y ৰ઱਋৑‫؟‬ফা঩‫ع‬া঩t ੄ਗ਼ৡउेलੑ઺೿ਗ਼ৌੁभ঳୭धखथৰ઱
t ᅵশଡਛभ१‫ش‬ং॑೿ૃऔच‫ؚ‬ೠ୐ઈૡभুದधਝ৒भનੳy ৌ଴३५ॸ঒
t ਗ਼৕ੑ઴ਃ३५ॸ঒y $'‫ق‬$FWLYH'LUHFWRU\‫ك‬१‫ش‬ং‫؟‬઎‫ق‬઎র‫ك‬y /'$3१‫ش‬ং‫؟‬઎‫ق‬઎র‫ك‬y /'$3१‫ش‬ং‫ق‬ও‫ش‬ঝ৷‫؟ك‬઎‫ق‬઎র‫ك‬y 0/‫ط‬:HEও‫ش‬ঝ१‫ش‬ং‫؟‬઎‫ق‬઎র‫ك‬y ও‫ش‬ঝ५উ‫ش‬ঝ१‫ش‬ং‫؟‬઎‫ق‬઎র‫ك‬y টॢॖথ‫ط‬:HE'$9१‫ش‬ং‫؟‬઎‫ق‬઎র‫ك‬y ঃ५ড‫ॻش‬૗ಌ:HE१‫ش‬ং‫؟‬઎‫ق‬઎র‫ك‬t ઇ୘৷ੲਾഈଜ३५ॸ঒
y :LQGRZVঈ‫ॺش‬१‫ش‬ং‫؟‬઎‫ق‬઎র‫ك‬y /LQX[ঈ‫طॺش‬3UR[\१‫ش‬ং‫؟‬઎‫ق‬઎র‫ك‬

ੲਾ৲औोञੌ௶भ७य़গজॸॕঐॿ४ওথॺ:*

ਛટਾઔછ



ਗ਼৕ੑ઴ਃ‫ط‬ઇ୘৷ੲਾഈଜ३५ॸ঒
ॿॵॺড‫ش‬ॡଡਛ௕

ੲਾ৲औोञੌ௶भ७य़গজॸॕঐॿ४ওথॺ:*

ਛટਾઔછ



ਗ਼৕ੑ઴ਃ३५ॸ঒१‫ش‬ংଡਛ௕ೠ୐ઈૡपൣः೿ૃखञ१‫ش‬ংઈૡ॑ಲਢखञ१‫ش‬ংਹ৷঻ଵ৶१‫ش‬ংधभ৴௚೐੅
भञी೿ૃदऌऩः१‫ش‬ংઇ୘৷ੲਾഈଜ
ૐ৺५ॖॵॳ
ůŤŪ
ƗƄƊ

ůŤŪ

$'१‫ش‬ং $'१‫ش‬ং $'१‫ش‬ং $'१‫ش‬ং ଀෰ীങಎ઼ ƗƄƊঃ५ড‫ॻش‬
૗ಌ:HE
[
6,0

ƗƄƊ
଀෰ীങಎ઼ ƗƄƊ

931१‫ش‬ং 
931१‫ش‬ং ƗƄƊ੦ୌ१‫ش‬ংૐ৺५ॖॵॳ /'$3৴௚१‫ش‬ংਹ৷঻ଵ৶१‫ش‬ং'%ਹ৷঻ଵ৶१‫ش‬ং$3:HE

110॔উজॣ‫ش‬३ঙথ१‫ش‬ং
92'಩൸ଦਦ३५ॸ঒

੦ୌ१‫ش‬ংૐ৺५ॖॵॳ +3&ॢজॵॻ३५ॸ঒

1$6 ५ॺঞ‫ش‬४
1$6 १‫ش‬ংও‫ش‬ঝ५উ‫ش‬ঝ
[

/'$3
[

টॢॖথ
:HE'$9[/'$3ও‫ش‬ঝ৷['16७থॱ‫ش‬:HE[
0/:HEও‫ش‬ঝ[:HEঘ‫ش‬२৷
[ও‫ش‬ঝଛਦ
[ও‫ش‬ঝଦଛ
[঍५ॸॕথॢ
[ଵ৶৷५ॖॵॳ



ੲਾ৲औोञੌ௶भ७य़গজॸॕঐॿ४ওথॺ:*

ਛટਾઔછ



ઇ୘৷ੲਾഈଜ३५ॸ঒१‫ش‬ংଡਛ௕㻯㻵㻲㻿䝃䞊䝞䠍ྎ䛆㻯㻵㻲㻿䛇

ZFS㉳ື䜲䝯䞊䝆䠝
Windows7㉳ື䜲䝯䞊䝆䠞
Windows7

CIFS

㼃㼕㼚㼐㼛㼣㼟䝛䝑䝖䝤䞊䝖䝃䞊䝞䠍䠔ྎ䛆㻼㼂㻿䛇䛆㻿㻹㻭䛇୺䛺䝃䞊䝞䝇䝨䝑䜽
Windows䝛䝑䝖䝤䞊䝖䝃䞊䝞
Express5800/i120Ra-e1
L5410(ప㟁ᅽ∧䜲䞁䝔䝹(R) Xeon2.33GHz䠅 2CPU
䝯䝰䝸16GB 䝕䜱䝇䜽146.5GB䠄RAID1䚸SAS)
CIFS䝃䞊䝞Sun Storage 7110
䝯䝰䝸8GB 䝕䜱䝇䜽≀⌮ᐜ㔞 ⣙4TB䠄ZFS䠅
Linux䝛䝑䝖䝤䞊䝖䝃䞊䝞
Express5800/i120Ra-e1
L5410(ప㟁ᅽ∧䜲䞁䝔䝹(R) Xeon2.33GHz䠅 2CPU
䝯䝰䝸8GB 䝕䜱䝇䜽146.5GB䠄RAID1䚸SAS)
NFS䝃䞊䝞
iStorageNV3400S
䝕䜱䝇䜽≀⌮ᐜ㔞2TB䠄RAID6䚸SAS)઎೿ૃ㼃㼕㼚㼐㼛㼣㼟
䝤䞊䝖せồ䝷䜲䝉䞁䝇᝟ሗ
ไᚚ᝟ሗ㉳ື䜲䝯䞊䝆
ᕪศ䝕䞊䝍Windows7㉳ື䜲䝯䞊䝆ㄞ㎸᝟ሗ㻰㻴㻯㻼䝤䞊䝖䝯䝙䝳䞊

㻸㼕㼚㼡㼤䝛䝑䝖䝤䞊䝖䝃䞊䝞䠍䠌ྎ䛆㻰㻴㻯㻼䛇䛆㼀㻲㼀㻼䛇䛆㻼㻾㻻㼄㼅䛇

઎೿ૃ

㻸㼕㼚㼡㼤
䜹䞊䝛䝹䝻䞊䝗

㻺㻲㻿䝃䞊䝞㻝ྎ䛆㻺㻲㻿䛇䖃WindowsOS䛿XenDesktop䠄PVS)Linux䛿NFS䝃䞊䝞䜢฼⏝䛧䝛䝑䝖䝤䞊䝖䜢⾜䛖䖃Windows䛾㉳ື䜲䝯䞊䝆䛿䚸ึᅇ㉳ື᫬䛻䝛䝑䝖䝤䞊䝖䝃䞊䝞䛛䜙䝎䜴䞁䝻䞊䝗䛧䚸ㄞ㎸䜣䛰᝟ሗ䜢➃ᮎ䛾HDD䛻ಖᣢ

㻸㼕㼚㼡㼤㻺㼑㼠㻮㼛㼛㼠⏝㻺㻲㻿ੲਾ৲औोञੌ௶भ७य़গজॸॕঐॿ४ওথॺ:*

NFS

ਛટਾઔછ

Linux



১৒ਡਫ਼पൣअੑ઺೿ਗ਼y ৰ઱਋৑‫؟‬ফা঩ ‫ع‬t ূઁਣ৉યभाy ࿷‫૸ূ؞‬ি৉યमৢଞৢॉभञी‫ؚ‬੦ୌॿॵॺড‫ش‬ॡउेल੦
ୌ३५ॸ঒मઈ৷॑ಲਢ

t ਗ਼౺੤पेॊংॵॡ॔ॵউ
y .9$¼‫ق‬३५ॸ঒৷‫ك‬y .9$ٔ.9$‫ق‬૬৹৷‫ك‬y ংॵॡ॔ॵউৌ଴३५ॸ঒
t +,1(7३५ॸ঒y ॥॔ॿॵॺড‫ش‬ॡಎ઼‫ઁূؚ‬ਣय़কথঃ५ૐ৺५ॖॵॳ‫ؚ‬'+&3१‫ش‬ং‫ؚ‬5$',86१‫ش‬ংt ਗ਼৕ੑ઴ਃ३५ॸ঒y ೠ୐ઈૡ૾ଙ॑೐੅‫؛‬ञटख‫ؚ‬+3&ॢজॵॻ३५ॸ঒‫ؚ॔‬উজॣ‫ش‬३ঙথ१‫ش‬ং‫ؚ‬92'಩൸ଦਦ३५ॸ঒‫ؚ‬ਹ৷঻ଵ৶३५ॸ
঒‫ؚ‬ঃ५ড‫ॻش‬૗ಌ:HE१‫ش‬ংम೿ૃt ઇ୘৷ੲਾഈଜ३५ॸ঒y ೠ୐ઈૡ૾ଙ॑೐੅‫؛‬ञटख‫ઁূؚ‬ਣ৉યम१‫ش‬অ५೿ૃ

ੲਾ৲औोञੌ௶भ७य़গজॸॕঐॿ४ওথॺ:*

ਛટਾઔછ



੄ਗ਼ৡषभ਄ॉੌाभ஍ટ
াશ଎ાਗ਼ৡ‫ق‬ੲਾওॹॕ॔ઇ୘ଢ଼஢७থॱ‫ش‬মை‫ك‬



଎ાਗ਼ৡ >[N:K@





਴ਛফ২

਴ਛফ২
਴ਛফ২




া

া

া

া

া

া

া

া

া

া

া

া

ਫ਼ଉা

y ਴ਛফ‫ع‬াम‫ؚ‬଑ো੿঵द೮३५ॸ঒धధষ༎௮खञञी‫ؚ‬঳ৎ৓प଎ાਗ਼ৡऋੜਸy ਴ਛফ২ૻद৺‫ق‬਴ਛফ২‫ڀك‬৺‫ق‬਴ਛফ২‫ك‬

ੲਾ৲औोञੌ௶भ७य़গজॸॕঐॿ४ওথॺ:*

ਛટਾઔછ



బ㈡኱Ꮫ䛻䛚䛡䜛㟁※⟶⌮஦౛㟁※⟶⌮ᴫせ| 䝷䝑䜽䛸↓೵㟁㟁※䛾タ⨨᝟ሗ䜢ᢕᥱ䛩䜛| ྛᶵᮦ䛾᝟ሗ䜢ᢕᥱ䛩䜛y䝷䝑䜽䚸㟁※䚸౑㏵䚸⟶⌮⪅| 䝅䝇䝔䝮䛾౫Ꮡ㛵ಀ䜢ᩚ⌮䛩䜛| 䝅䝇䝔䝮೵Ṇ䞉㉳ື䛾㡰ᗎ䜢స䜛| ィ⏬೵㟁᫬䛾⦰㏥㐠㌿䜢ィ⏬䛩䜛䝷䝑䜽䛸㟁※䛾ᢕᥱ⥲ྜ᝟ሗᇶ┙䝉䞁䝍䞊䞉䝁䞁䝢䝳䞊䝍䝹䞊䝮
㻝㻝

㻞㻞㻜㻜

㻝㻠㻜㻜

㻡

䝷䝑䜽䞉Ჴ

㻞㻞㻜㻜

㻢

㻣

㻭

㻥

㻤

㻝

㻝㻡㻜㻜 㻣㻡㻜

䝕䝇䜽㻞㻟㻜㻜㻜㻌㻗㻌䝞䝑䝔
䝸䞊䝟䝑䜽

㻝㻜㻜㻜

㓄㟁┙䞉ᡂ➃⟽

㻟ᗋ⨨䛝ᆺ㼁㻼㻿

㻠

㻞㻜

㻞㻝

㻝㻜

㻞㻞

㻭㻼㻯㻙㼁㻼㻿
ศ㟁┙

✵ㄪタഛ

㻝㻡

㻞㻠

䝻䝑䜹䞊
㻞㻟

㻝㻠

㻞㻡

㻮
䝷䝑䜽ෆ㼁㻼㻿䛾᭷↓
㻝㻠㻚㻌䕿
㻝㻚㻌㽢
㻝㻡㻚㻌㽢
㻞㻚㻌㽢
㻝㻢㻚㻌䕿
㻟㻚㻌䕿
㻝㻣㻚㻌䕿
㻠㻚㻌䕿
㻝㻤㻚㻌䕿
㻡㻚㻌䕿
㻝㻥㻚㻌䕿
㻢㻚㻌䕿
㻣㻚㻌䕿
㻤㻚㻌䕿
㻥㻚㻌㽢
㻝㻜㻚㻌䕿
㻝㻝㻚㻌㽢
㻝㻞㻚㻌䕿
㻝㻟㻚㻌䕿

㻴㻼㻌㼀㻣㻜㻜

㻝㻡㻜㻜

㻝㻞
㻝㻟

㻝㻢

㻝㻣

㻝㻤

㻝㻥

㻯

ྛ䝅䝇䝔䝮䛾≧ἣᢕᥱ䠖䝃䞁䝥䝹⥲ྜ᝟ሗᇶ┙䝉䞁䝍䞊䚷䝃䞊䝞ᐊෆ㼁㻼㻿᥋⥆≧ἣㄪ
᰿ඖ㟁※

㼁㻼㻿
タ⨨ሙᡤ

㻭㻼㻯㻙㼁㻼㻿
ศ㟁┙㻌㻞㻭㻼㻯㻙㼁㻼㻿
ศ㟁┙㻌㻝

䝷䝑䜽㻝ୗ
ᗋୗ䝁䞁䝉䞁䝖
䝷䝑䜽㻝ୗᗋୗ䝁䞁䝉䞁䝖

㻭㻼㻯㻙㼁㻼㻿
ศ㟁┙㻌㻡

㼁㻼㻿ᆺ␒

㻞㻜㻝㻝㻛㻝㻝㻛㻝㻠㻵㻼㻌㻭㼐㼐㼞㼑㼟㼟䝝䞊䝗䜴䜵䜰
ไᚚᢸᙜ⤌⧊

Ꮫෆ⟶⌮⪅

䝯䞊䜹䞊

ᶵ✀

䝩䝇䝖
タ⨨ሙᡤ

㟁※ᐃ
᱁㻔㼃㻕

ഛ⪃

᥋⥆䝩䝇䝖ྡ

䝩䝇䝖⏝㏵

㼙㼟㼣㻜㻝

Ꮫෆእ䝯䜲䞁䝇䜲䝑䝏᝟ሗᇶ┙䝉䞁䝍䞊

㻝ෆ㻠㻜㻜㻜 ஧㔜㟁※ྑഃ㼙㼟㼣㻜㻝Ꮫෆእ䝯䜲䞁䝇䜲䝑䝏᝟ሗᇶ┙䝉䞁䝍䞊

㻝ෆ㻠㻜㻜㻜 ஧㔜㟁※ᕥഃ䝷䝑䜽㻝ୗᗋୗ䝁䞁䝉䞁䝖

㼚㻡㼗㻜㻝௬᝿䝃䞊䝞⏝䝇䜲䝑䝏㻝᝟ሗᇶ┙䝉䞁䝍䞊㻝ෆ㻞㻞㻡 ஧㔜㟁※ྑഃ䠄㻞㟁※䛷㻠㻡㻜㼃䠅

䚺

䚺

㼚㻡㼗㻜㻞

௬᝿䝃䞊䝞⏝䝇䜲䝑䝏㻞᝟ሗᇶ┙䝉䞁䝍䞊㻝ෆ㻞㻞㻡 ஧㔜㟁※ྑഃ䠄㻞㟁※䛷㻠㻡㻜㼃䠅㻭㻼㻯㻙㼁㻼㻿
ศ㟁┙㻌㻢

䝷䝑䜽㻝ୗ
ᗋୗ䝁䞁䝉䞁䝖

㼚㻡㼗㻜㻝௬᝿䝃䞊䝞⏝䝇䜲䝑䝏㻝᝟ሗᇶ┙䝉䞁䝍䞊㻝ෆ㻞㻞㻡 ஧㔜㟁※ᕥഃ䠄㻞㟁※䛷㻠㻡㻜㼃䠅

䚺

䚺

㼚㻡㼗㻜㻞

௬᝿䝃䞊䝞⏝䝇䜲䝑䝏㻞᝟ሗᇶ┙䝉䞁䝍䞊㻝ෆ㻞㻞㻡 ஧㔜㟁※ᕥഃ䠄㻞㟁※䛷㻠㻡㻜㼃䠅㻭㻼㻯㻙㼁㻼㻿
ศ㟁┙㻌㻞㻝

䝷䝑䜽㻝ୗᗋୗ䝁䞁䝉䞁䝖

㼢㼏㼚㻜㻝௬᝿⟶⌮䝃䞊䝞

᝟ሗᇶ┙䝉䞁䝍䞊㻝ෆ㻞㻝㻝 ஧㔜㟁※ᕥഃ䠄㻞㟁※䛷㻠㻝㻟㼃䠅

䚺

䚺

㼑㼟㼤㻜㻠

௬᝿䝃䞊䝞㻠

᝟ሗᇶ┙䝉䞁䝍䞊㻝ෆ㻞㻝㻝 ஧㔜㟁※ᕥഃ䠄㻞㟁※䛷㻠㻝㻟㼃䠅

䚺

䚺

㼑㼟㼤㻜㻡

௬᝿䝃䞊䝞㻡

᝟ሗᇶ┙䝉䞁䝍䞊㻝ෆ㻞㻝㻝 ஧㔜㟁※ᕥഃ䠄㻞㟁※䛷㻠㻝㻟㼃䠅

䚺

䚺

㼑㼟㼤㻜㻢

௬᝿䝃䞊䝞㻢

᝟ሗᇶ┙䝉䞁䝍䞊㻝ෆ㻞㻝㻝 ஧㔜㟁※ᕥഃ䠄㻞㟁※䛷㻠㻝㻟㼃䠅

䚺

䚺

㼑㼟㼤㻜㻣

௬᝿䝃䞊䝞㻣

᝟ሗᇶ┙䝉䞁䝍䞊㻝ෆ㻞㻝㻝 ஧㔜㟁※ᕥഃ䠄㻞㟁※䛷㻠㻝㻟㼃䠅㻭㻼㻯㻙㼁㻼㻿
ศ㟁┙㻌㻞㻞

䝷䝑䜽㻝ୗᗋୗ䝁䞁䝉䞁䝖

㼢㼏㼚㻜㻝௬᝿⟶⌮䝃䞊䝞

᝟ሗᇶ┙䝉䞁䝍䞊㻝ෆ㻞㻝㻞 ஧㔜㟁※ྑഃ䠄㻞㟁※䛷㻠㻝㻟㼃䠅

䚺

䚺

㼑㼟㼤㻜㻠

௬᝿䝃䞊䝞㻠

᝟ሗᇶ┙䝉䞁䝍䞊㻝ෆ㻞㻝㻞 ஧㔜㟁※ྑഃ䠄㻞㟁※䛷㻠㻝㻟㼃䠅

䚺

䚺

㼑㼟㼤㻜㻡

௬᝿䝃䞊䝞㻡

᝟ሗᇶ┙䝉䞁䝍䞊㻝ෆ㻞㻝㻞 ஧㔜㟁※ྑഃ䠄㻞㟁※䛷㻠㻝㻟㼃䠅

䚺

䚺

㼑㼟㼤㻜㻢

௬᝿䝃䞊䝞㻢

᝟ሗᇶ┙䝉䞁䝍䞊㻝ෆ㻞㻝㻞 ஧㔜㟁※ྑഃ䠄㻞㟁※䛷㻠㻝㻟㼃䠅

䚺

䚺

㼑㼟㼤㻜㻣

௬᝿䝃䞊䝞㻣

᝟ሗᇶ┙䝉䞁䝍䞊㻝ෆ㻞㻝㻞 ஧㔜㟁※ྑഃ䠄㻞㟁※䛷㻠㻝㻟㼃䠅௨ୗ┬␎䝅䝇䝔䝮䛾㝵ᒙ໬䠖౫Ꮡ㛵ಀᢕᥱእ㒊㟁※䜢⏝䛔䛯ィ⏬೵㟁ᑐ⟇| ẖᖺ䛾ィ⏬೵㟁䜈䛾ᑐᛂy䝛䝑䝖䝽䞊䜽ᇶ┙䛸ㄆドᇶ┙䜢↓೵Ṇ䛷ᥦ౪y እ㒊㟁※䜢ᑟධ䛩䜛䠄60kVA)|y䝇䝫䝑䝖䜽䞊䝷䞊䚸↷᫂䚸㏦㢼ᶵ䜒ᚲせ䛺ᶵᮦ䜢㞟୰㓄⨨䛩䜛| ᩍ⫋ဨ⏝䝯䞊䝹䛾እὀy┴ෆ䝕䞊䝍䝉䞁䝍䞊y 䛭䜜௨๓䛾䝃䞊䝡䝇䛾⥅⥆imaps, pops
| 䜴䜱䝹䝇ᑐ⟇䚸SPAM䝯䞊䝹ᑐ⟇|y䛔䛴䛷䜒䚸䝕䞊䝍䜢ྲྀ䜚ᡠ䛫䜛䠖䝕䞊䝍䛾ᡤ᭷ᶒ䜢☜ಖy 䛔䛴䛷䜒䚸䝻䜾䜢ཧ↷䛷䛝䜛6೵㟁ᑐᛂฎ⌮| 䝅䝇䝔䝮⟶⌮⾲సᡂ䠖䛚䜒䛻ಶู䝅䝇䝔䝮yᢸᙜ⪅䛜೵Ṇ䚸᚟ᪧ䜢䝏䜵䝑䜽䛩䜛y 䝉䞁䝍䞊㛗䛜㐍ᤖ䜢ᢕᥱ䛩䜛| సᴗ⥺⾲సᡂyᙜ᪥䛾సᴗᡭ㡰䜢☜ㄆ䛩䜛|䝉䞁䝍䞊⫋ဨ䛸䝧䞁䝎䞊y㐍ᤖ⟶⌮䛾䝏䜵䝑䜽䝫䜲䞁䝖䜢᫂☜䛻䛩䜛y 䝉䞁䝍䞊⟶⌮እ䛾䝅䝇䝔䝮䛾஦๓೵Ṇ䜢ᣦ♧| 㟁※⟶⌮⾲䛾ά⏝y䝅䝇䝔䝮೵Ṇ䛾☜ㄆ
y UPS䛾೵Ṇ
|

7

㟁※᚟ᖐ᫬䛾䝖䝷䝤䝹㜵Ṇᐇ㝿䛾೵㟁ᑐᛂ

䝇䝫䝑䝖Ỉ෭✵ㄪ⿦⨨ᗫ⇕䝎䜽䝖 ３．１１ 富士通の対応
 自然災害のリスクとその影響
 お客様の声と対策の方向性
 富士通でお手伝いできること『IT部門で考えるべき事業継続対策』～ 大震災発生後の１年を振り返って ～ ＢＣＰ策定／教育訓練
 コミュニケーション対策強化

2012年2月15日
富士通株式会社
サービスビジネス本部
安心安全ビジネス推進室

 ＩＣＴ対策強化

 お客様対策事例
 まとめ
Copyright 2012 FUJITSU LIMITED

1

Copyright 2012 FUJITSU LIMITED

東日本大震災２０１１年３月１１日１４時４６分１８秒
太平洋三陸沖を震源地としたＭ９．０の国内観測史上最大の地震が発生
発生直後に太平洋沿岸に大津波が襲来（最大４０ｍ超、浸水地域約４００平方キロ）
地震及び大津波により福島第一原発の冷却系が機能を喪失
１９時３分に原子力緊急事態宣言発令
東京都内でも震度５強の揺れを観測し、交通機関の停止により約５１５万人の帰宅困難者が発生

３．１１ 富士通の対応

2

Copyright 2012 FUJITSU LIMITED

過去の災害復旧対応 ～対策本部を設置した災害一覧～
主な災害

主な災害

対策本部設置日

対応件数

対策本部設置日

対応件数

1995年1月17日

2,751件

台風23号

2004年10月20日

402件

東海地区水害2000年9月11日

431件

新潟県中越地震

2004年10月23日

150件

鳥取県西部地震

2001年10月6日

42件

福岡県西方沖地震

2005年3月20日

122件

芸予地震

2001年3月24日

128件

宮城県沖地震2005年8月16日

66件

高知県西部大雨

2001年9月6日

19件

台風14号

2005年9月6日

177件

台風21号

2002年10月1日

17件

新潟/関西停電対策

2005年12月22日

113件

宮城県沖地震2003年5月26日

62件

長野・島根集中豪雨対策

2006年7月19日

62件

台風6号

2003年6月19日

2件

鹿児島集中豪雨対策

2006年7月24日

24件

宮城県北部地震

2003年7月26日

88件

東京・千葉・神奈川 地区停電

2006年8月14日

65件

台風10号

2003年8月8日

33件

石川県能登半島沖地震

2007年3月25日

161件

北海道十勝沖地震

2003年9月26日

104件

新潟県中越沖地震

2007年7月16日

53件

台風2号

2004年5月20日

1件

岩手・宮城内陸地震

2008年6月14日

51件

台風6号

2004年6月20日

18件

岩手県沿岸北部地震

2008年7月24日

17件

中部地区集中豪雨

2004年6月30日

30件

西日本集中豪雨被害

2009年7月27日

76件

新潟地区集中豪雨

2004年7月13日

85件

近畿/関東広域豪雨

2009年8月10日

56件

福井地区集中豪雨

2004年7月20日

68件

駿河湾沖地震2009年8月11日

13件

台風15号

2004年8月20日

27件

台風18号

2009年10月8日

139件

台風16号

2004年8月30日

378件

チリ地震津波

2010年2月28日

7件

台風18号

2004年9月6日

455件

東日本大震災2011年3月11日

5189件
5189件

台風21号

2004年9月29日

116件

台風12号・15号

2011年9月5日

224件

Copyright 2012 FUJITSU LIMITED

Copyright 2012 FUJITSU LIMITED

富士通社内の安否確認状況

阪神淡路地震4

3

Copyright 2012 FUJITSU LIMITED

３/１１地震発生当日の状況

 配 信 数

：約２万６千人へ配信 配信対象地域：東北・関東地域 １８都道県

 返信率 ：２時間半後 ７割
：５時間後

８割
＜返信例＞
あ：無事
か：負傷
さ：その他

 安否確認システムと緊急連絡網で並行に確認
5

Copyright 2012 FUJITSU LIMITED

1

被災地域のデータセンター状況
3/14
東北センター（宮城県仙台市）

東京1&2センター（東京都内）

横浜・港北センター（神奈川県横浜市）

震度５弱

震度５弱

停 電 発 生館林センター（群馬県館林市）

自家発電稼働

震度６強

3/11夜

自家発電稼働自然災害リスクとその影響
自家発電稼働自家発電稼働

震度４

 地震によるセンター内のお客様システムへの被害は無し。
 発生直後から停電が発生したが、各センターとも自家発電装置
にて運用を継続。
6

Copyright 2012 FUJITSU LIMITED

主な活断層型地震のリスク（発生確率）7

主な海溝型地震のリスク（発生確率）

出典:文部科学省研究開発局地震・防災研究課
8

Copyright 2012 FUJITSU LIMITED

出典:文部科学省研究開発局地震・防災研究課

Copyright 2012 FUJITSU LIMITED

9

Copyright 2012 FUJITSU LIMITED

グーテンベルク・リヒターの法則

首都圏直下型地震の発生確率がアップ？

Ｍが１上がると、地震の発生回数は１０分の１になる＝小さい地震が多発すると、大きい地震の発生確率も高まる

３．１１後、Ｍ３以上の地震の回数が急増！
Ｍ７級の発生確率が「４年以内に７０%」「３０年以内に９８％」

343回

47回

３．１１後、地震の発生回数が急増

出典：東京大学地震研究所
10

Copyright 2012 FUJITSU LIMITED

Copyright 2012 FUJITSU LIMITED

11

Copyright 2012 FUJITSU LIMITED

2

東日本大震災 交通機関の状況について

東日本大震災での電力復旧推移

道路被災による交通渋滞や鉄道の被害により、通勤困難が発生する可能性がある。
東日本大震災(津波の影響の無い内陸のエリア)の主要国道でも機能確保まで2～7日の期間がかかっている。

岩手県、宮城県、福島県は２０日以上たっても完全に回復せず

出典：土木学会

出典：東北大学による東日本大震災1ヶ月後緊急報告 会交通ネットワークの被害と復旧の状況
12

Copyright 2012 FUJITSU LIMITED

東日本大震災での断水復旧率推移

13

Copyright 2012 FUJITSU LIMITED

東日本大震災でのガス復旧率推移

岩手県、宮城県、福島県は２０日以上たっても完全に回復せず

岩手県、宮城県、福島県は２０日以上たっても完全に回復せず

出典：土木学会
14

出典：土木学会

Copyright 2012 FUJITSU LIMITED

15

Copyright 2012 FUJITSU LIMITED

東京都／神奈川県の被災時の交通規制

都市部における浸水
都市部における浸水は、都市機能の麻痺や地下街の浸水をもたらす等重大な被害につながる

首都圏大震災発生直後の第一次交通規制

多摩川、国道２４６号線および環状７号線を結ぶ内側は全面車両通行禁止
国道１６号線以東の都県境では都内へ車両の流入禁止平成15年 福岡市内浸水状況

平成２３年 台風１５号 品川駅

平成２３年 台風１５号 表参道

東京都災害時規制対象道路

南関東震災発生後の交通規制

第一京浜
第二京浜
中原街道
目黒通り
玉川通り
甲州街道
青梅・新青梅街道
目白通り
川越街道
中山道
北本通り
日光街道
水戸街道
京葉道路
蔵前橋通り
中央南北線
東八道路
五日市街道
井の頭通り
三鷹通り
小金井街道
府中街道
芋窪街道
残堀街道
志木街道
新奥多摩街道
吉野街道
滝山街道
町田街道
北野街道
川崎街道
多摩ニュータウン通り
八王子立川線
鎌倉街道
大和バイパス
小作北通り
高速道路（首都高速道路及び高速自動車国道）

平成12年 東海水害

平成２３年 台風１５号 隅田川

国道２４６、４６７、１号および県道２３号に囲まれた西側
区域が車両通行禁止

平成２３年１０月 タイ豪雨
■出典：警視庁，神奈川県警

出典：国土交通省関東地方整備局／ロイター／http://matome.naver.jp/odai/2131656514422671901
16

Copyright 2012 FUJITSU LIMITED

国道１６号線の西側から都心方向への車両
進入禁止

Copyright 2012 FUJITSU LIMITED

17

Copyright 2012 FUJITSU LIMITED

3経営層の関心が高まった課題
事業継続

震災後は

293%

コンプライアンス対応

お客様の声と対策の方向性

145%

事業継続への
関心が増加

コスト削減

151%

グローバル展開

136%

新規ビジネス創出

124%※記載の数値は、それぞれ震災前を“100%”とした場合の比較値です。
経営者618名からのアンケート回答

震災前
震災後

「IT導入関与者調査2011」より／調査機関：マクロミル
18

Copyright 2012 FUJITSU LIMITED

事業継続への関心の高まり（具体的な事業継続計画の見直しや強化など）
震災以降（注）「震災前年比」は震災前を“100%”とした場合の比較値です。

震災前後比

293%
203%
650%
600%
214%
600%
478%
300%
343%
286%
200%
167%
267%
243%
304%
282%
356%

全体
建設業
食品
繊維・衣服
ﾊﾟﾙﾌﾟ･紙･木材・石油・化学・ｶﾞﾗｽ･ｾﾒﾝﾄ

鉄鋼・金属
機械・電気機器・精密機器
輸送用機器
その他製造業
流通・商社
金融・保険・証券業
不動産業
運輸・倉庫
通信
情報処理・情報ｻｰﾋﾞｽ・ｿﾌﾄｳｪｱ
旅行･観光･その他ｻｰﾋﾞｽ
その他

0

5

10

15

20

20

25

30

35

Copyright 2012 FUJITSU LIMITED

情報ｼｽﾃﾑ部門からみた企業課題傾向と対応状況

震災後に事業継続への関心が大きく高まる（製造業で顕著）
震災以前

19

「事業継続/災害対策」は情報システム部門の最優先課題
67

BCP（事業継続対策）／災害対策
BCP（事業継続対策）／災害対策

現場業務の強化（業務改善全般）

4140

売上原価低減40

商品供給能力増強（生産・物流・販売）

40

28

商品力強化／ｻｰﾋﾞｽ事業強化

40

26

ﾋﾞｼﾞﾈｽ基盤の構築・整備

39

今後1、2年で対応優先度が高い

20%

1

36

事業・業務可視化（経営）基盤強化

0%

2

30

46

間接費低減

0

27

58

制度・法令への対応
制度・法令への対応

7

41

7

35

14

33

16
21
23

37
40%

中期的（3～5年後まで）に対応が必要

40

Copyright 2012 FUJITSU LIMITED

22

60

ｾｷｭﾘﾃｨ対策
ｾｷｭﾘﾃｨ対策

60%

13
80%

100%

優先順位は低い／対応予定なし

有効回答：89会員
21

出典：LSI研 IT白書 2011度版
Copyright 2012 FUJITSU LIMITED

対策の方向性更なる事業継続対策の強化に向けて、お客様の声と弊社の実践を踏まえ、以下のような対策が必要と考えます。
ＢＣＰ

今回の震災を踏まえてのＢＣＰ見直し人／組織／ｺﾐｭﾆｹｰｼｮﾝ

震災時でも有効なコミュニケーション手段の確立
ＩＣＴ／ファシリティ

堅牢なデータセンターの活用

・想定外リスク（津波、電力不足等）を踏まえてＢＣＰを見直しBCP・教育、訓練による対応能力強化

富士通でお手伝いできること

・緊急連絡用の安否確認サービスを検討
・リモートアクセスを活用した在宅勤務環境の強化
・連絡用のメールやグループウェア等の代替システムの準備
・自家発電装置を完備したデータセンタへの移設（基幹システムだけでなく、部門サーバも移設を検討）
・遠隔地へのデータバックアップを検討
・東日本と西日本の２センター化を検討
・耐震、免震による物理的被害の軽減
・自家発電装置やＵＰＳの導入
22

Copyright 2012 FUJITSU LIMITED

Copyright 2012 FUJITSU LIMITED

23

Copyright 2012 FUJITSU LIMITED

4

事業継続ソリューションマップ
診断

事前対策フェーズ 把握／対応フェーズ

簡易診断サービス（
無償）

事業継続コンサルティングサービス

守る対象

人・組織

ファシリティ

業
種共通復旧フェーズ

緊急連絡／安否確認サービス
CRMate
Web会議 Cisco WebEx Meeting Center
FENICSメール

ＢＣＰ策定／教育訓練

どこでもオフィス
ファシリティ対策サービス

・ＢＣＰトータルパック

1センター対策
データセンタアウトソーシングサービス
2センター対策
ディザスタリカバリセンターサービス
リモートバックアップサービス
オンサイトバックアップサービス
外部媒体保管サービス

情報
システム
(ICT)

ネットワーク対策
FENICSネットワークサービス
24

Copyright 2012 FUJITSU LIMITED

25

Copyright 2012 FUJITSU LIMITEDＢＣＰの策定や見直しのために～ＢＣＰトータルパック～ 今回の震災において各企業が対応した行動を整理・ 分析し、ベストプラクティスとした手順書テンプレートを基にBCPを策定・見直し
 さらにシミュレーション訓練により策定したBCPの実行性を検証＜サービス全体像＞
Step1
現状診断

Step2
手順書策定・見直し

Step3
BCPに基づく訓練

事業継続性診断シート

手順書テンプレート

シミュレーション訓練

拠点対 策本 部
時間

分

区分

他組織

本 部長・
副 本部 長

・安否確認・緊急連絡サービス
・ＣＲＭａｔｅ・どこでもオフィス

職場 組織

総 務部

人 事部
事 務局

被 害情 報
収 集班

従業員
支援班

来訪 者
支援 班

現地
支 援班

安 否確認 班人 事厚 生班

救 護班

避 難誘導 班
消火 係
（ 応急 救護班 と兼務） （ 安全 防護 班と兼務 ）フロア 責任者

地 震発 生安 全確 保

5

コミュニケーション対策強化

揺れの 安全が 収まるまで安 全な場所で待 機

0 行 動開 始□

対策 本部へ
急行□ 本部 設置、中央 対策 本部へ の報告行 動開 始□活動 指示□ 参集 ﾒﾝﾊﾞ による役 割分担□ 行動 記録 開 □ 担 当決定 ・始
役 割確認※ 5分 以内に実施□□ 担当 決定・
役割 確認□ 担 当決定 ・役 割確認□ 非常 用通 信 □ 情 報収集 開 □ 館内 放送実
手段 確保
始 （ﾒ ﾃﾞｨｱ） ・施
記 録開始□ ﾋ ﾞﾙ管理会 社と の通信 手段確 認
1 0 情 報収 集

□ 担当 決定・
役割 確認□ 衛 星拠点 状 □ 負傷 者確況 確認指 示認、搬 送支援開 始□ 担当決 定・
役割確 認

□ 担当 決定・
役割 確認□

担 当決定・
役 割確認□ 寮・ 社宅 被
害状 況確
認・ 集約

□

負 傷者確
認、搬 送支援 開始

ﾌﾛｱ組 織活動
開始

□

一次編 成

□ 担当 決定・ 役割
確認□

担当 決定・ 役割 確認□

人員点 呼開 始 □ 負傷 者救護、 不明者 捜索・ 救出開始□

緊急 措置（ 二次 災
害防 止、火気 停
止）□ 被災 時状況
確認 開始□ 職場 組織への作業 指示□ 建屋の 安全 □ 館 内状況 集 □ 入出 場制限
性情 報入 手約 開始

□ 安否確 認ｼｽ
ﾃﾑ発信
□ 来 訪者確認 ・不 明者確認□ 来 訪者誘
導・ 保護□ 1 階の 入出
場 制限開 始□ 情報 集約・ フロア □責任 者への報 告

情報 集約・フ ロア
責任 者への報 告□ 来 訪者対 応
報告
3 0 人 員確 認・ 被害状 況把 握

□報告 受理□ 収集 情報まと め・報 告6 0 帰 宅者 対応□

災害 対策会議招 集案内発信□ 災害 対策 会
議開 始準 備

1 2 0 滞 留者 対応□

災害 対策本部開 催□ 事 務局へ報告（ 第一 報）□ 事務 局へ報
告（ 第一報）□ 事 務局へ報告（ 第一 報）□ 帰宅 者用支援物 資手配□ 帰 宅者用 支援 物資手 配□ 事務 局へ報
告（ 第二報）□ 事 務局へ報告（ 第二 報）□ 待機 者用物
資配 付□ 待 機者用 物
資 配付□ 事務 局へ報
告（ 第一報）□ 安否確 認状
況(第一 報)□ 事務 局へ報告（ 第一 報）□事 務局へ報告（ 第一 報）□事 務局へ報告（ 第二 報）□

収集情 報を、□ フ ロア責任者 へ
従業員 支援 班
報告に報告□

フロア責 任者へ報告□フロア責 任者へ報告□ 支援 物資検討開 始□ 安否確 認状
況(第二 報)□ 帰宅 者把握・ 残留 者
把握
□ 一般 従業 員
帰宅 判断□ 帰宅 者用 支援物 資手 配□ 一般 従業 員
帰宅 指示□ 収集 情報まと め・報 告1 8 0 災 害対 策会議
開催□ 災害 対策 本
部開 催□ 事 務局へ報告（ 第二 報）□ 事務 局へ報
告（ 第二報）□ 事務 局へ報告（ 第二 報）□帰宅者 管理□収集情 報報 告 □ フ ロア責任者 へ
報告□

待機者 用物 資の必要 数把握□

物資の 受け取り□ 安否確 認状
況(第三 報)□ 安否確 認継
続・ＦＥＮＩＣＳⅡ ユニバーサルコネクト

最短2ヶ月

・Web会議 Cisco WebEx Meeting Center■参考価格：３００万～（個別見積）※注(注)現状診断から手順書策定、訓練まで含んだ価格となります。
作業範囲及び対象となる拠点数や事業規模により個別見積
26

Copyright 2012 FUJITSU LIMITED

従業員や学生の迅速な安否確認のために

27

災害時の情報収集・意思決定を迅速化するために～緊急連絡/安否確認サービス～～CRMate～★既存環境ですぐに運用開始！ 新規設備は不要★災害発生時の安否確認、各種停電・節電アナウンスと情報周知にも活用

安否確認の基本３機能＋αの役立つ機能

社員

1.メール配信

2.状況回答受信

自動一斉配信こだわりの回答•気象連携で迅速に配信•スケジュール配信で罹患状況収集•運用担当者の負荷軽減

3.状況把握•発災時、通信規制の影響を考慮した回答方法を採用•1文字入力で簡単操作、短時間回答
最小限のパケット数•ＷＥＢ回答も装備+αの役立つ機能

素早く状況確認

快適運用を支援•リアルタイムに自動集計•個人毎の回答状況が色分けで表示され一目瞭然•携帯電話でも状況確認•お客様毎に専用サイトを提供、外部からの攻撃にも配慮•管理者設定数は無制限•組織階層は１０階層以上•管理者機能の携帯ＷＥＢ対応•全キャリアに対応
28

Copyright 2012 FUJITSU LIMITED

災害発生時に、正確な状況や初動を把握することで適切な意思決定を支援。
情報収集
情報収集
整理
整理

意思決定者へ
思決定者へ
状況報告
状況報告

案件管理
案件管理

対策本部
対策本部
■受信メ ール■06/0 3/15 10:30■an pi @ ●●●.co m■[0806001]安否確認---------------------安否確認一斉点呼です。
下記項目を 選択し返信し て く だ さ い。

あ：無事
か：負傷
さ：その他

あ ： 無事か： 負傷
さ ： そ の他

メールで回答（推奨）

メール本文に「あ」の1文字を入力

対応指示
対応指示
各地区拠点
各地区拠点

状況確認
集計

報告

指示

対応確認

風水害発生時の各拠点の情報をすばやく検索し、状況を確認

データ一元管理
現地
被災状況

ライフライン
状況

建屋状況

現在の状況

要員
状況

設備状況

１文字で状況回答
Copyright 2012 FUJITSU LIMITED

地震発生時の各拠点の情報をすばやく検索し、状況を確認

PCとインターネットのみで、離れた拠点から状況報告

素早く状況を確認でき、迅速な対応指示が可能

安否回答（２種類用意）
携帯電話
WEBで回答Copyright 2012 FUJITSU LIMITED

29◆現地対策本部の追加報告や被害写真の情報などもインターネットを通じて共有できます。
◆日ごろの訓練に活用できます。
Copyright 2012 FUJITSU LIMITED

5従量課金で在宅勤務環境をご提供

セキュアな在宅勤務環境実現のために～ＦＥＮＩＣＳⅡ ユニバーサルコネクト～～どこでもオフィス～ 社外のリモートPCからセキュアにつなぐ環境をサービスでご提供。
許可されていない
アクセスはブロック！

・オフィスにPCあり・モバイルを試行
・安価に導入30万円～

画面転送

本格パターン
シンクライアント
画面転送

お客様拠点

モバらくだ

SSLVPN
ｿﾌﾄｳｪｱ事務所（WindowsPC）

認証

VPN
GW

SSL-VPN

ＦＥＮＩＣＳ
ネットワークサービス

インターネット

シンクライアント（Citrix, VMwareView）

お客様
業務システム等【オンデマンドプラン】
定常コストを必要最低限に抑え、超過時は追加契約の手間もなく、後日精算できます。

DaaS(Desktop as a Services)

画面転送

ｱｸｾｽ制御富士通※または
お客様ご準備のｲﾝﾀｰﾈｯﾄ接続環境

お客様ＰＣ

サービスパターン
DaaS
・PCも運用もアウトソースしたい・シンクライアントのスモールスタート
4千円/ID・月～

ＦＥＮＩＣＳⅡﾕﾆﾊﾞｰｻﾙｺﾈｸﾄ

初回接続時に自動インストール

ブラウザ
アプリ等

同時接続数

・高いセキュリティー
・高い運用性・アプリの一元管理
500万円/50ID～

モバイル・ネットワーク（ FENICSII）

お手軽パターン「モバらくだ」

仮想デスクトップサービス

各種サーバ

事業継続に最適です。

【費用比較】（100同時接続まで）

月度の最大同時接続数で課金
定額費用総額からの低減部分

オンデマンドプランでのお支払額
4

30

利用制限

Copyright 2012 FUJITSU LIMITED

5 6

7

8 9 10 11 12 1

2

3

月

31

Copyright 2012 FUJITSU LIMITED

33

Copyright 2012 FUJITSU LIMITEDＷｅｂ会議（ Cisco WebEx Meeting Center ）★Cisco WebEx Meeting CenterはSaaS型のWeb会議システムです。音声、ビデオによるコミュニケーションや、多彩な資料共有機能を、モバイルやグローバルなど
様々な環境から利用でき、効果的・効率的なコラボレーションを実現します。
ホワイトボード/アプリケーション/

デスクトップの共有機能
ビデオ会議/音声会議
チャット機能ＩＣＴ対策の強化等により効率的なコラボレーション
環境をご提供します
Cisco WebEx
データセンター
オフィスから
海外から

自宅から

出張先から

モバイルから32

Copyright 2012 FUJITSU LIMITED①リスクと被災シナリオの想定

ＩCT対策の検討項目
IＣＴの対策を実施するための前提として最低限、以下の項目を明確にします

内容

補足
電力不足のリスクも追加② 守るべき業務守る事業を洗い出します。
ﾋﾞｼﾞﾈｽをﾌﾟﾛｾｽで分解し、さらに下支えしているITを洗い出します。

事業分解した業務プロセスとリカバリの実力（現状）と目標復旧時間のボトルネックを可視化します。

③

守るもののなかから優先付けを行い守る時間との紐付けを明確にします。

ステークホルダへの影響、ＩＴ依存
度、収益への影響から優先付けを行います。

①
被災ｼﾅﾘｵ

優先度

加味する要素としてﾗｲﾌﾗｲﾝ､ﾍﾞﾝﾀﾞｰ対応、ｼｽﾃﾑ復元､最新化､ﾃﾞｰﾀ
復元、ﾛｽﾄの補完です。

④

3つのR
の確定

RTO(目標復旧時間）、RPO(目標復旧時点）、RLO(目標復旧レベル）の確定システムの災害対策方式を決定するために３つのRを確定させます。

⑤

DR方式

RTO目安に、各事業範囲毎に方式を選定します。

データセンターの活用、ストレージ技術の活用、仮想化、バックアップ・ミラーリングソフト等

⑥

サイト選定

被災リスクの確認や施設の堅牢性等を考慮してサイトを選定

一極集中を避ける必要がある
34

Copyright 2012 FUJITSU LIMITED

基本的にはお客様が検討
但し富士通もサポート可

内閣府は備えるﾘｽｸについて
は 「地震」等の広域災害を推奨。
被災ﾚﾍﾞﾙを想定し､そのﾘｽｸが発生した際の実力の復旧時間をｼﾅﾘｵとして整理します。

リスク

富士通
による提案
Copyright 2012 FUJITSU LIMITED平日未明 M8の地震が発生。本社、電算ｾﾝﾀｰが被災レベル4の影響を被る。
被災レベル

L1
回線断

L2
機器損傷

L3
機器損傷
停電

L4
マシン横転
停電

L5
センタ倒壊

ハード障害

部品障害

部品障害

部品障害

部品障害
新規機器用意

新規機器用意設置環境準備－ｼｽﾃﾑﾘｶﾊﾞﾘ
ﾃﾞｰﾀﾘｶﾊﾞﾘ

ｼｽﾃﾑﾘｶﾊﾞﾘ
ﾃﾞｰﾀﾘｶﾊﾞﾘ－

部品交換＋Ｓ

停電回復＋
部品交換＋Ｓ

外部媒体取寄ｼｽﾃﾑﾘｶﾊﾞﾘ
ﾃﾞｰﾀﾘｶﾊﾞﾘ
新規機器手配＋(外部媒体取寄せ)＋(停電回復)＋Ｓ

回線回復時間＋回線回復時間×１
倍

部品交換時間＋Ｎ×４倍(ﾃﾞｰﾀ補完)

停電回復時間＋部品交換時間＋ｼｽﾃﾑﾘｶﾊﾞﾘ時間＋
ﾃﾞｰﾀ復元時間＋
Ｎ×４倍

外部媒体取寄ｼｽﾃﾑﾘｶﾊﾞﾘ
ﾃﾞｰﾀﾘｶﾊﾞﾘ
設置環境準備＋(新規機器手配)＋(外部媒体取寄せ)＋(停電回復)＋Ｓ
設置環境手配時間＋(新規機器手配時間)＋
現調時間＋
ｼｽﾃﾑﾘｶﾊﾞﾘ時間＋
ﾃﾞｰﾀ復元時間＋
Ｎ×４倍（ｾﾝﾀ含む）

復旧方法
ﾘｶﾊﾞﾘﾎﾟｲﾝﾄ(N)ﾊﾞｯｸｱｯﾌﾟｻｲｸﾙ=S

復旧までの
想定時間
被災
ﾘｽｸ

予
兆

発現
時間

被災
ﾚﾍﾞﾙ

被災
場所

出勤
率

参集
時間
電力

関
東
北
部
地
震

電
算
室
×

非勤務
時間帯

L4

回線

広域災害時
45日

ボトルネック

被災ｼﾅﾘｵ

ｼｽﾃﾑ復元とﾊﾟｯﾁ/VLｱｯﾌﾟ含む

夜間に電算､本社が被災｡12時間後に参集率30%の要員
確保機器手配期間
中にﾗｲﾌﾗｲﾝが回復し続いて現調､ｼｽﾃﾑの復元､ﾊﾞｰｼﾞｮﾝｱｯ
ﾌﾟ､ﾃﾞｰﾀ復元後
RPO*4倍のﾛｽﾄﾃﾞｰﾀ
補完
を行う。

水道

30%

12h

機器手配

Sys data ﾃﾞｰﾀ補完

電力

本
社

新規機器手配時間＋（停電回復時間）＋
現調時間＋
ｼｽﾃﾑﾘｶﾊﾞﾘ時間＋
ﾃﾞｰﾀ復元時間＋
Ｎ×４倍

回線
ｸﾗｲｱﾝﾄ復旧
35

RPO+停止時間の4倍が目安

Copyright 2012 FUJITSU LIMITED6

②守るべき事業の検討③優先度の決定対策の対象範囲の可視化

事業の中断による経過時間毎の影響を分析し、現状のシステム復旧時間の確認と目標とすべき復旧時間（RTO）を検討していく。

書庫

書庫

在庫・仕入れ

書庫

子会社支援
ラック2

ラック4

ラック１

【参考】評価項目

分析結果をまとめＲＴＯを決定する①収益機会逸失による財務的な損失

Ａ事業

HAD650DLT

DLT

PRIMPOWER650PRIMPOWER 200
ＳｕｎＦｉｒｅ
V490

UPS
UPS

重要顧客との
取引関係

市場シェア
喪失

風評の発生

ﾃｰﾌﾟ
ﾃｰﾌﾟ
装置
装置
ETER
PRIMP NCR
NUS
OWER
GR710
200

切替器

苫小牧

3 000

営業支援

ルータ

ﾓﾃﾞﾙ 200

3500

ETERNU S

3 000
PRIMER GYﾓﾃﾞﾙ 80①② ③ ④ ⑤⑥⑦ ⑧

富士

RX200

ルータ
SunFir e

浜松

v490

PRIMPO WER
PRIMPO WER

データ交換

PRIMPO WER

6 50

ﾗｯｸ１２
UK

ルータ

250

200

PRIMPO WER

名古屋

250

ﾓﾃﾞﾑ
NCR

ルータ
NCR
COM
3430

ラック７
SystemDefenda

IP - VPN

ルータ

子会社支援

PRYMER
GY

NCR

UPS
1500

雇用継
続・・・
分電盤（200V）

特になし

1時間

問題なし

影響なし

北陸
ルータ

C200

連結会計

人事給与

ＰＣＡ会計

拠点サーバ

京都

契約書

Exchange/AD

ルータ

ラック９

ラック８
PROKY３和歌山

BARACUDA
Firewaii300
ISDN

ONU

発生なし

DMZ HUB
ＵＰＰ（30KVA）

PAC-２

ルータ

特になし

クレーム発生

影響なし

発生なし⑧環境破壊・汚損発生

1日

５００万円

強い復旧要請影響なし

発生なし⑨従業員の士気低下

1週間

７，０００万円

ペナルティ発生

他社への乗り換え発生

限定的にあり

1ヶ月

3億円

検討

３０％以内のシェア喪失

マスコミにて報道され風評被害拡大

取引停止及び他
社へ乗り換え５０％以上の
シェア喪失

広島

入口

Cisco 3600

PAC-１

PRIMER GY

PRIMER GY

PRIMER GY

PRIMER GY

PRIMER GY

PRIMER GY

PowerE dge

TX150

C150

C200

C200

TX150

TX200

830

事業継続対象ｼｽﾃﾑ

ルータ

DIMENS ION
1100

伊予三島
ルータ

Catalist
2900

OGNTER NET

12時間

ISDN

ISDN

Bフレッツ

ＦＵＪＩ

⑥市場シェア喪失

ETERNU S

StorEd ge

ＤＷＨ

PROKY1⑤風評による信用低下

C200

ルータ

予算・在庫・仕入・販売活動
清算・会計

UPS

人事給与

VSP2910G

PRIMER GY

TX150

ルータ
札幌

契約書管
理
①② ③ ④ ⑤⑥ ⑦ ⑧

PRIMER GY

東京

COMPAQ
WeBserve

予算

VSP3802

財務的損失

DNS
TOSHIBASENDMAIL

ＤＷＨ⑨

販売活動／清算・会計処
ラック10 理ﾗｯｸ１１

②重要顧客への取引影響④法規制の違反による操業停止

ラック５①DELL DIMENSION1100②DELL
POWEREdge830③④PRYMERGY C200
⑤Smart UPS1500 ×２⑥PRYMERGY C150
⑦SmertUPS700 ×２⑧PRYMERGY TX150⑨BUFFALO DMNUS

UPS

UPS

LP00
VSP4951
ページプリンタ③契約違反による提訴・違約金請求 時間の経過

HAD200

Ｓｕｎ LTO

Ｂ事業

IPCOM100
Ｓｕｎ LTOPRYMERGY RX200
PRYMERGY RX200
PRYMERGY RX200
ETERNUS 3000
ﾓﾃﾞﾙ80PRIMPOWER
250
UPS

事業継続対象ｼｽﾃﾑ
ETERNUS 3000
ﾓﾃﾞﾙ200

分電盤（100V）

ラッ ク６①COMPAQ PROLiant ML330②COMPAQ PROSIGNIA200③Mail-HUB④PRYMERGY TX150S4⑤PRYMERGY TX200S2⑥NCR⑦COMPAQ PROLiant ML330⑧PRYMERGY C200

書庫

ラック３

DWH
VSP3710

九州

HUB＊プリンタ記載省略

ルータ⑦雇用継続への影響

関係悪化

⑩その他

他社へ乗換え

10億円

3ヶ月

業務システムと復旧優先順位付け

長期間に渡り風評被害発生

36

業務名

ＲＴＯ

Sﾗﾝｸ

受発注、在庫管理、物流、社外Web、社内インフラ

1日

Aﾗﾝｸ

人事給与、子会社会計

３日

Bﾗﾝｸ

予算、DWH､社内Web

７日

Copyright 2012 FUJITSU LIMITED④３つのRの確定

37

Copyright 2012 FUJITSU LIMITED⑤ＤＲ方式の選択

RTO

本格復旧

仕掛り
システム
再構築 データ復元
通常運用

RLO
暫定復旧
（縮退運用）

運用ダウン▲▲
最終Backup 災害発生▲
運用再開（暫定）

平常時
復帰

ファシリティ対策
IDCを活用

データセンタアウトソーシング（ホスティング・ハウジング）

データ
バック
アップ
提供

２センタ対策

運用レベル

RPO

自社サイトの強化

１センタ対策

災害発生から暫定復旧、本格復旧までの流れ

システムの事業継続対策

業務の優先度（業務範囲／サービスレベル）を吟味し、継続業務のレベル(RLO)を決定
運用再開までの時間(RTO)、データ復旧レベル(RPO)の条件を踏まえた災害対策レベルの決定
災害対策レベルに応じたシステムの構築

時間

リモート
バックアップサービス

ｲﾒｰｼﾞﾊﾞｯｸｱｯﾌﾟ～200GB
ﾐﾗｰﾘﾝｸﾞ
200GB～5TB
ﾐﾗｰﾘﾝｸﾞ+重複排除

5TB～

ファイルサーバ/PC向け
外部媒体保管サービス
データセンタアウトソーシング冗長化（ホスティング・ハウジング）

スタンバイ
システム
提供

・RPO(Recovery Point Objective) どの時点までデータが戻るか・RTO(Recovery Time Objective) いつまでにシステムを復旧させるか・ RLO(Recovery Level Objective)
どのレベルで運用を継続させるか（業務範囲／サービスレベル）
38

業務
データ
向け

オンサイトバックアップ構築
ＤＲセンタ
サービス
（クラウド）

Copyright 2012 FUJITSU LIMITED

39

プライベート・専用
パブリック・共用
Copyright 2012 FUJITSU LIMITED

国内データセンター⑥サイトの選定
都内にお客様センタがある場合（例）

東北

群馬

東京

横浜

大阪

兵庫

福岡

(1)地震リスク

○

○

×

○

○

○

○

(2)堅牢地盤

△

○

△

○

○

○

○

(3)津波・液状化リスク

○

○

○

○

○

○

○

(4)関係者のｱｸｾｽ

×

×

○

○

×

×

×

(5)同時被災しない

◎

◎

×

△

◎

◎

◎

(6)施設の堅牢性

◎

◎

◎

◎

◎

◎

◎

(7)センタSEの常駐

○

△

×

◎

○

△

×

(8)ﾗｲﾌﾗｲﾝ復旧能力

○

○

×

○

○

○

○

(9)ﾊﾟｰﾂｾﾝﾀｰ/CE常駐

△

◎

△

◎

○

◎

△

(10)東西での冗長化

×

×

×

×

○

○

○

■施設の堅牢性■電力周波数とデータセンタの位置

TierⅠ

TierⅡ

TierⅢ

TierⅣ

１

１

1active
1Passive

2active

自家発電機（運転時間）

Ｎ

Ｎ＋１

Ｎ＋１

Ｎ＋２

-

24h

48h

72h

電源容量
（最大）

～320W/㎡～540W/㎡～645W/㎡～860W/㎡～320W/㎡～540W/㎡～1600W/㎡～1600W/㎡

空調設備

Ｎ

Ｎ＋１

Ｎ＋１

Ｎ＋２

Copyright 2012 FUJITSU LIMITED

地域センター

東京第1システムセンター

北海道データセンター

東京第2システムセンター

明石システムセンター
所在地：東京都内
サービス開始：2001年10月

東北データセンター

所在地：東京都内
所在地：兵庫県明石市

サービス開始：2007年12月

サービス開始：1997年9月

館林システムセンター
長野データセンター

中四国データセンター
九州データセンター

供給経路

40

全国66拠点にデータセンターを展開
富士通センター
FIPセンター

Copyright 2012 FUJITSU LIMITED

所在地：群馬県館林市
サービス開始：1995年12月

大阪データセンター

中部データセンター

41

ビジネスサポートセンター
ビジネスオペレーションセンター
東京データセンター
横浜データセンター
横浜港北データセンター

Copyright 2012 FUJITSU LIMITED7

ＤＣ間ネットワークについてNEW

グローバルデータセンタ－拠点
グローバルに１００以上のセンターを展開。

■ＦＪ/FIP主要５センタ間を高速ネットワークで接続■高品質な広域バックアップシステムを構築可能■データセンタ間連携時のオプションサービスとして提供開始

11年度
スウェーデン：1

デンマーク：2
オランダ：1
ドイツ：5
ドイツ第4
スイス：2

英国：9

08年4月
中国（華南） 予定
開設
データセンター
韓国
データセンター
中国：1(+1)

フィンランド：3

10年3月
開設

館林ＤＣ
10G×2

10G×2

明石ＤＣ

09年6月
日本：66

北ロンドン
データ
センター

08年6月
開設

米国(テキサス）
データセンター

米国：2

スペイン：1

10G×2

カナダ：2

韓国：1

データセンター

タイ：1

タイ
データ
センター

08年2月
開設

10年4月

米国データ 開設
センター増強シンガポール：3

10G×2
東京（第1,第2）ＤＣ
FIP千里

10G×2
南アフリカ：2

FIP横浜（新)

42

09年1月
開設

シンガポール
第３データセンター

オーストラリア：8

シドニー第４
データセンター

Copyright 2012 FUJITSU LIMITED

11年5月
開設

Copyright 2011 FUJITSU LIMITED

43

シンガポール・データセンター概要

海外ＤＣ間ネットワーク

シンガポールで３番目となる弊社保有の商用データセンター（2009年1月開設）です。
所在地：シンガポール東部チャンギ

2012年度、グローバル6DCをグローバルNWで接続（～100Mbps）
英国

マシンルーム面積

687.5 m2

UPS

冗長化構成 (2N)

発電機

自家発電機 (N+1)

空調

冗長化構成 (N+1)

消火設備

超高感度煙検知システム、スプリンクラー（乾式）、ガス消火設
備

セキュリティ

手のひら静脈認証、監視カメラ、
外周フェンス、24時間有人監視、
ICカード

床荷重

2t / ㎡接続可能な通信キャリア

マルチキャリア

米国

館林

ドイツ

z

シンガポール44

オーストラリア

Copyright 2012 FUJITSU LIMITED

NEW

45

オーガニックストレージⅡリモートミラーオプション

仮想テープライブラリサービス

 お客様のDR構成実現のためにファイルサーバを２拠点に展開し、リモートミラーを取得。
 従来のオーガニックストレージサービスⅡのオプションサービスとしてセンター間回線とバックアップ環境をセットにして提供。
 ２０１１年１０月１２日 提供開始。

 富士通データセンタ（館林Ｂ棟）の共用型仮想テープライブラリを低コストで利用できるサービス
 館林のVTLSを明石にバックアップするサービスを２０１２年４月（予定）から開始
 システムの拡張に合わせて、仮想テープライブラリ・仮想テープ本数を拡張可能

NEW

お客様
※仮想テープライブラリとは、ディスクアレイで構成する記憶プールに仮想的なテープボリュームを割り当ててデータを格納する仕組みです。

センター被災時はアクセス先をミラー先に切り替えて業務継続

本社

拠点

明石センタ

共用型仮想テープライブラリサービス提供範囲

館林センタ

ﾊﾞｯｸｱｯﾌﾟ環境

通常時のアクセス先A社用 仮想テープライブラリ
A社用 仮想テープライブラリ

明石センター
オーガニックストレージⅡ

館林センター
オーガニックストレージⅡ

A社様

バックアップ仮想ﾃｰﾌﾟ
仮想ｽﾛｯﾄ

仮想ﾃｰﾌﾟ

仮想ﾃｰﾌﾟ

仮想ﾃｰﾌﾟ

仮想ｽﾛｯﾄ

仮想ｽﾛｯﾄ

仮想ｽﾛｯﾄFC/iSCSI

仮想ﾄﾞﾗｲﾌﾞ

業務システムお客様
ボリュームB

ミラーリング
ＤＣ間ネットワーク

ﾊﾞｯｸｱｯﾌﾟｻｰﾊﾞ
リスト
ア

お客様
ボリュームA

お客様
ボリュームB

B社様

仮想ﾃｰﾌﾟ
仮想ｽﾛｯﾄ

仮想ﾃｰﾌﾟ

仮想ﾃｰﾌﾟ

仮想ｽﾛｯﾄ

仮想ｽﾛｯﾄ

仮想ｽﾛｯﾄ

仮想ﾃｰﾌﾟ
仮想ｽﾛｯﾄ

仮想ﾃｰﾌﾟ

仮想ﾃｰﾌﾟ

仮想ｽﾛｯﾄ

仮想ｽﾛｯﾄ

仮想ﾃｰﾌﾟ

B社用 仮想テープライブラリ

仮想ﾃｰﾌﾟ

仮想ﾃｰﾌﾟ

仮想ｽﾛｯﾄ

仮想ｽﾛｯﾄ

仮想ﾃｰﾌﾟ
仮想ｽﾛｯﾄ

仮想ﾃｰﾌﾟ
仮想ｽﾛｯﾄFC/iSCSI

業務システムＤＣ間
ネットワーク共用スイッチお客様
ボリュームA

アクセスノード

共用スイッチ

アクセスノード

仮想ﾄﾞﾗｲﾌﾞ

仮想ﾃｰﾌﾟ
仮想ｽﾛｯﾄ

仮想ﾃｰ
ﾌﾟ
仮想ｽﾛｯﾄ

仮想ﾃｰ
ﾌﾟ
仮想ｽﾛｯﾄ

仮想ﾃｰ
ﾌﾟ
仮想ｽﾛｯﾄ

仮想ﾃｰ
ﾌﾟ
仮想ｽﾛｯﾄ

仮想ﾃｰ
ﾌﾟ
仮想ｽﾛｯﾄ

仮想ﾃｰ
ﾌﾟ
仮想ｽﾛｯﾄ

仮想ﾃｰ
ﾌﾟ
仮想ｽﾛｯﾄ

仮想ﾃｰ
ﾌﾟ
仮想ｽﾛｯﾄ

仮想ﾃｰ
ﾌﾟ
仮想ｽﾛｯﾄ

仮想ﾃｰ
ﾌﾟ
仮想ｽﾛｯﾄ

仮想ﾃｰ
ﾌﾟ
仮想ｽﾛｯﾄ

B社用 仮想テープライブラリ

仮想ﾄﾞﾗｲﾌﾞ

仮想ﾄﾞﾗｲﾌﾞ

仮想ﾃｰ
ﾌﾟ
仮想ｽﾛｯﾄ

仮想ﾃｰ
ﾌﾟ
仮想ｽﾛｯﾄ

仮想ﾃｰ
ﾌﾟ
仮想ｽﾛｯﾄ

仮想ﾃｰ
ﾌﾟ
仮想ｽﾛｯﾄ

仮想ﾃｰ
ﾌﾟ
仮想ｽﾛｯﾄ

仮想ﾃｰ
ﾌﾟ
仮想ｽﾛｯﾄ

仮想ﾃｰ
ﾌﾟ
仮想ｽﾛｯﾄ

仮想ﾃｰﾌﾟ

ﾊﾞｯｸｱｯﾌﾟｻｰﾊﾞ

46

Copyright 2012 FUJITSU LIMITED

Copyright 2012 FUJITSU LIMITED

仮想ﾃｰﾌﾟ
仮想ｽﾛｯﾄ

仮想ｽﾛｯﾄ47

Copyright 2012 FUJITSU LIMITED

8

システムの事業継続対策レベル
システムの事業継続対策レベルを５段階で体系化

データ保証方式

リモート
二重化 （同期）二重化 （非同期） データ転送

データ

お客様対策事例

RPO

LevelⅤ

リアルタイムLevel Ⅲ

LevelⅡ

媒体外部保存1日

LevelⅠ

RTO: Recovery Time Objective
いつまでに業務を復旧させるか20日

Level0

200GB

110

1TB

万円～

万円～

170

2TB
新規提供

4TB

業務サーバ
・Windows

170

万円～

300

万円～

業務サーバ
・Windows

ETERNUS CS800 ｴﾝﾄﾘｰﾓﾃﾞﾙを活用した大容量ﾃﾞｰﾀﾊﾞｯｸｱｯﾌﾟの追加
50

年商：
約５４０億円ETERNUS NR1000FシリーズのSnapShotの二重化ソリューションETERNUS NR1000ﾌｧｲﾙｻｰﾊﾞの設置と、SnapShotによりデータ保護を行います。
ﾊﾞｯｸｱｯﾌﾟｻｲﾄにETERNUS NR1000Fを導入しWAN越しでSnapShotﾃﾞｰﾀをSnapMirror
ＲＴＯ

お客様データﾊﾞｯｸｱｯﾌﾟLAN

概算金額：①初期費用：３００万～（オンサイト、データセンタ、ネットワーク）②月額費用： ２５万～（ホスティング、ネットワーク）
51

Copyright 2011 FUJITSU LIMITED金融 仮想化システムの災害対策事例

LevelⅢ

お客様事業所

業務LAN

データ重複排除/圧縮後の差分ブロックのみを転送

Copyright 2011 FUJITSU LIMITED

製造 遠隔地NAS2重化

１．５ケ月

７日

導入後

１日

１時間

お客様サイト100

LevelⅣ

仮想技術を利用した災害対策システムを構築
災害対策を安価に実現（設置スペース、運用管理コストを削減）

ＲＰＯ

導入前

災害対策方針NR1000F

データ重複排除&データ圧縮
COPYツール等でのバックアップミラーリング＋
重複排除

ＥＴＥＲＮＵＳ ＣＳ８００
・ﾊﾞｯｸｱｯﾌﾟ領域：4.0TB

FENICS ﾋﾞｼﾞﾈｽVPN
ﾍﾞｽﾄｴﾌｫｰﾄ100M

業務サーバ
・Windows

万円～

20

万円～

リモートバックアップサービス提供範囲
ＥＴＥＲＮＵＳ ＣＳ８００
・ﾊﾞｯｸｱｯﾌﾟ領域：4.0TB

ミラーリング12万円～

リモートバックアップサイト

ﾊﾞｯｸｱｯﾌﾟ対象

9万円～

LevelⅡ→帯域の小さなネットワークでも転送可能

お客様サイトイメージ
バックアップ8170

Copyright 2011 FUJITSU LIMITED

データ量を重複排除機能で縮小

→高コスト

・
・
・

500GB

7
万円～

システム
49

→帯域の大きなネットワークが必要

方式

万円～

RTO

ホットスタンバイ

スタンバイ方式

大容量のデータを遠隔地にバックアップしたい※ネットワーク費用除く

月額

ノーダウン

ウォームスタンバイ～信頼性のある富士通ストレージで重複排除機能を実現～■ 業務データ向けに大容量バックアップを強化
初期費

コールドスタンバイ

CS800を活用したリモートバックアップ

LevelⅡ～災害や停電から重要データを守るために～対象
容量データ復旧 24時間

Copyright 2011 FUJITSU LIMITED

リモートバックアップサービス

Level Ⅳ

データ＋システム復旧
1時間

スタンバイなし

48

業務復旧

RPO: Recovery Point Objective
どの時点までデータが戻せるか

ＲＴＯ

ＲＰＯ

導入前

１．５ケ月

１０日

導入後

６時間

１時間

DRサイト

80

SnapShot

60

復旧計画の
策定･運用

ﾃﾞｰﾀ
ﾊﾞｯｸｱｯﾌﾟ

40
20
0

ﾊｰﾄﾞｳｪｱ/ｼｽﾃﾑ
の
災害対策

施設の
災害対策

WAN

SnapMirror
お客様別事業所内

災害対策方針
100

80
60

復旧計画の
策定･運用

退避ボリューム

40
20

ﾃﾞｰﾀの
ﾊﾞｯｸｱｯﾌﾟ

0

変更

NR1000F

運用ボリューム

代替システム構築
52

Copyright 2012 FUJITSU LIMITED

施設の
災害対策

ﾊｰﾄﾞｳｪｱ/ｼｽﾃﾑの災害対策
Copyright 2011 FUJITSU LIMITED

53

Copyright 2011 FUJITSU LIMITED

9

物流業 遠隔地スタンバイ対策事例 （レベルⅢ）

LevelⅤ•PRIMEQUEST/Linux/Symfoware Active DB Guard/ETERNUS800環境災害対策
ユーザ

年度売上：
約4000億円■特徴：PRIMEQUEST (Symfoware DB)環境の構成■スタンバイ方式：ホットスタンバイ■データバックアップ方式：ＲＥＣ 非同期
東京
顧客サイト

ｲﾝﾀｰﾈｯﾄ

大阪
顧客サイト

ＲＴＯ

ＲＰＯ

導入前

１．５ケ月

２週間

導入後

1時間

ﾉｰﾛｽﾄ

災害対策方針100

BX620 DMZ

社内ｼｽﾃﾑ
経理,購買
会計,人事

90
80
70

BX620 DMZ

60
50
40

復旧計画の
策定･運用

ｲﾝﾄﾗ
PRIMERGY BX620
ETERNUS4000

SA
N

リモートミラー（ＲEＣ 非同期）

PRIMEQUEST580
RHEL

施設の
災害対策

ﾊｰﾄﾞｳｪｱ/ｼｽﾃﾑの
災害対策

100
90
80
70
60
50
40
30
20
10
0

SA
SA
N

DB

復旧計画の
策定･運用

1Gbps×2

DB

RTO

RPO

ﾃﾞｰﾀの
ﾊﾞｯｸｱｯﾌﾟ

方式概要

DRレベル

縮退機を自社で保有
コールドスタンバイ
15分おきに東京のDBの変更履歴を記録したログをCIFSを使って沖縄に送り、バックアップのDBに反映

受発注

7日

1日

Ⅲ

情報サービスB社

情報サービ コールセンター業務
ス
株式連携 取引記録

1時間

15分

Ⅲ

6時間

2時間

Ⅲ

外部媒体保管ﾊﾞｯｸｱｯﾌﾟｻｲﾄに共用MF１台

1日

12時間

Ⅲ

遠隔地 差分ﾊﾞｯｸｱｯﾌﾟ/ﾘｶﾊﾞﾘｼｽﾃﾑ

流通Ｃ社

物流

受発注
生産管理

製造Ｄ社

化学製薬

受注、物流

流通Ｅ社

流通食品

受発注、物流→納品

製造Ｆ社

化学

情報系ｼｽﾃﾑ､CAD

1日

1日

Ⅲ

２４時間運用の商用データ
ベース

2日

1日

Ⅲ

受発注､財務会計､ﾒｰﾙ

3日

12時間

Ⅲ

コンサルティング
ｺﾝｻﾙﾃｨﾝｸﾞ
Ｇ社

SA
N

対象業務

製造自動車

Ⅲ

ﾃﾞｰﾀ
ﾊﾞｯｸｱｯﾌﾟ

30
20
10
0

災害対策方針ETERNUS8000
N
SN200M540(FCｽｨｯﾁ)
Symfoware ADBG

業種

製造A社

受注を東京､物流を大阪に 分散
取引先,商品ﾏｽﾀｰなどの情報を持つ
簡易ｱﾌﾟﾘをExcelとAccessで開発
ETERNUS NR1000F series、SnapMirror制御機構
ﾊﾞｯｸｱｯﾌﾟｼｽﾃﾑ能力を本番系５０％の縮退
環境
ﾊﾞｯｸｱｯﾌﾟ日時でｿﾌﾄｳｪｱﾊﾞｯｸｱｯﾌﾟ
ﾊﾞｯｸｱｯﾌｻｲﾄに縮退環境を構築

製造Ｈ社

化学

製造Ｉ社

製造自動車

受発注

10日

1日

Ⅲ

遠隔地ﾊﾞｯｸｱｯﾌﾟ

製造J

製造電機

HW設計､ｿﾌﾄ開発

3日

1日

Ⅲ

OSSV:遠隔地NASの差分ﾊﾞｯｸｱｯﾌﾟ
NAS⇒LT160にTSMﾊﾞｯｸｱｯﾌﾟ

富士通ではこの他にも200社以上の事業継続対策をお手伝いしております。
施設の
災害対策

ﾊｰﾄﾞｳｪｱ/ｼｽﾃﾑの災害対策

Copyright 2011 FUJITSU LIMITED

54

対策事例 （レベルⅣ、レベルⅤ）
ユーザ

業種

情報Ａ社

情報ｻｰﾋﾞｽ

製造業Ｂ社

製造

流通Ｃ社

物流

情報Ｄ社

メディア

製造業Ｅ社

製造

対象業務
ｺｰﾙｾﾝﾀｰ業務

RTO
1時間

受発注､生産管理､DMZ 1日
次期WEBｼｽﾃﾑ
社内ｼｽﾃﾑ 経理,購買 1時間
会計,人事
次期競馬ｼｽﾃﾑ
1日
競馬情報ｰ製版業務
基幹業務

1時間

RPO

DRレベル

数秒

Ⅳ

1時間

Ⅳ

数分

Ⅳ

数秒

Ⅳ

数秒

Ⅳ

製造業Ｆ社

製造(電機)

受発注・生産管理

1時間

数分

Ⅳ

製造業Ｇ社

化学

受発注・生産管理

3時間

数秒

Ⅳ

金融Ｈ社
金融Ｉ社
官公庁Ｈ

金融
金融
官公庁

法人向けインターネット
6時間
パンキングシステム1日

証券業務ｼｽﾃﾑ

数秒

財務報告書

1時間
4時間

30分

Ⅴ
Ⅴ
Ⅴ

55

Copyright 2011 FUJITSU LIMITED

事業継続対策の傾向

製造自動車

8

20,140

112

153.0

2ｾﾝﾀｰ
対策
ｻｲﾄ間
平均距離
(Km)
166.0

25.0

2.6

ｲﾝﾌﾗ、部品管理、販社連携

0.0056製造電機

18

19,375

542

28.0

196.4

39.0

3.1

受発注、生産管理、CAD

0.0280

建設

8

4,028

48

51.8

352.0

38.0

2.4

WEBEDI、図面CAD、施工管理

0.0119

自治体
*1

8

2,957

130

24.0

65.0

75.0

2.9

ｲﾝﾌﾗ、住民管理､電子入札、
公共設備管理0.0440

官公庁

8

-

200

18.5

765.0

38.0

3.5

ｲﾝﾌﾗ、各省庁関係ｼｽﾃﾑ

方式概要
ｽﾄﾚｰｼﾞﾐﾗｰ(REC)＋PRIMECLUSTER
DR edition
遠隔地ｽﾄﾚｰｼﾞﾐﾗｰﾘﾝｸﾞ方式
ｳｫｰﾑｽﾀﾝﾊﾞｲ
遠隔地ﾐﾗｰ(非同期)REC
遠隔地ﾐﾗｰ(非同期)SNAPMIRROR
遠隔地ﾐﾗｰﾘﾝｸﾞ
ｽﾄﾚｰｼﾞﾐﾗｰ非同期 Consistency
遠隔地ﾐﾗｰﾘﾝｸﾞ
ｽﾄﾚｰｼﾞﾐﾗｰ非同期 Consistency
遠隔地ﾐﾗｰﾘﾝｸﾞ
ｽﾄﾚｰｼﾞﾐﾗｰ非同期 Consistency

業種

ｻﾝﾌﾟﾙ
数

年商
(億円)

初年度
投資平均
(百万円)

RTO
平均
(h)

1ｾﾝﾀｰ
対策
割合
(%)

対策ﾚﾍﾞﾙ
平均
(5段階)

年商に
占める
投資率％
(投資額／年商)

対象業務

ｰ

金融

51

37,317

152

23.4

198.4

4.0

3.8

情報系、決済、一部勘定系

0.0041

医療・福祉

4

814

62

60.8

35.0

50.0

2.5

医事ｼｽﾃﾑ0.0762

化学・製薬

25

6,833

148

18.4

522.7

56.0

3.0

ｲﾝﾌﾗ、受発注、物流

0.0217

情報ｻｰﾋﾞｽ

12

738

122

32.2

902.9

42.0

3.0

ｺﾝﾃﾝﾂ､ﾅﾚｯｼﾞ、会計

0.1653

Oracle9i 4ノードRACのDBを
ETERNUS REC非同期

食品

16

2,998

108

34.7

621.0

50.0

3.1

ｲﾝﾌﾗ、情報系、受発注売掛、
物流

0.0360製造

57

10,248

227

45.8

224.0

41.0

2.9

受発注、入出在庫管理、物流

0.0222

遠隔地ｽﾄﾚｰｼﾞﾐﾗｰ(非同期)REC

物流

10

3,320

455

36.7

235.0

60.0

3.0

物流ﾄﾚｰｽ､会計、予約管理

0.1370

流通

41

3,268

129

31.2

418.1

61.0

3.0

ｲﾝﾌﾗ、売掛管理､物流

0.0395

メディア

3

1,371

310

16.1

470.0

0.0

3.7

紙面ﾃﾞｰﾀ､WEBｺﾝﾃﾝﾂ

0.2261

不動産

2

1,299

37

12.0

0.0

100.0

3.0

顧客管理、物件管理

ホットスタンバイ、
ストレージコピー機能ROPC,REC）

富士通ではこの他にも200社以上の事業継続対策をお手伝いしております。

0.0285

ｺﾝｻﾙ研究

4

1,158

118

36.0

380.0

3.0

0.0

ｲﾝﾌﾗ、ﾅﾚｯｼﾞ、人事給与

0.1019

合計

275

8,724

196

41

369

41.4

3.0

-

0.0225*1：自治体の場合の年商は税収
56

57 57

Copyright 2011 FUJITSU LIMITED

Copyright 2010 FUJITSU LIMITED

IT部門で考えるべき事業継続対策（まとめ） 重要データの保全 外部媒体保管/ リモートバックアップサービスを利用

 堅牢なデータセンターにサーバを配置

まとめ 自社センターの補強
 ベンダーが提供するデータセンター/ クラウドサービスを利用

 ネットワークの冗長化
 回線の冗長化とNW切替方式の検討

 有事の際の要員体制
 有事の際に切替の判断や対応ができる要員を分散
 ベンダー要員を含めた対応体制の整備
58

Copyright 2012 FUJITSU LIMITED

Copyright 2012 FUJITSU LIMITED

59
59

Copyright
2009
FUJITSU
Copyright
2012
FUJITSU LIMITEDLIMITED

10

対策検討は現状把握から最後に・・・・・
富士通グループは事業継続対策を検討したいが何から始めればいいだろうか・・・
まずは、事業継続レベルチェックで自社の脆弱性を把握してみませんか？
無償!!

２週間以内

詳しくはWebで・・・・・

事業継続 レベルチェック

検 索

60

Copyright 2012 FUJITSU LIMITED

62

Copyright 2012 FUJITSU LIMITED

Copyright 2012 FUJITSU LIMITED

国内No.1のDR構築実績

社内実践
高い技術力とノウハウ

事業継続対策は
是非、富士通にご相談ください61

Copyright 2012 FUJITSU LIMITED

11「東日本大震災発生時の情報管理部門の対応に関するア
ンケート」まとめ情報化された組織のセキュリティマネジメント WG A 班

2012 年 3 月

2011 年 3 月 11 日に東日本の広い範囲を襲った地震は、その後の大きな津波、そして福島第一原
子力発電所の過酷事故と続き、大きな被害をもたらしました。一年を経た現在でも、復興どころか復旧への道筋も見えていません。
情報化された組織のセキュリティマネジメント WG A 班では、地震の発生以前より、大学・研究機関の事業継続計画 (BCP) の検討を行っていました。今回の震災にあたって、被災された大学・研究機関がどのような対応をされたのかを知ることで、BCP 検討の参考にさせて頂きたく、アン
ケート調査をお願いいたしました。ご多忙の中、回答を頂いた情報系センター・担当課の皆様に、以下にお名前を挙げて感謝いたします。
回答頂いた、大学・研究所（順不動）
東北学院大学情報システム部情報システム課, 東北学院大学泉情報処理センター
東北学院大学多賀城情報処理センター, 東北学院大学土樋情報処理センター
東北工業大学情報センター, 東北大学サイバーサイエンスセンター
仙台白百合女子大学情報システム管理室, 宮城教育大学情報処理センター
福島大学総合情報処理センター, 岩手大学情報処理センター
山形大学情報ネットワークセンター, 秋田大学総合情報処理センター
弘前大学総合情報処理センター, 青森中央短期大学

図書館情報センター高エネルギー加速器研究機構（KEK）計算科学センター

J-PARC センター, 理化学研究所情報基盤センター
国立天文台天文データセンター, 筑波大学学術情報メディアセンター
東京工科大学コンピュータサイエンス学部, 工学院大学

情報科学センター

東洋大学情報システム部情報システム課
神奈川大学 メディア教育・情報システムセンター 情報システム推進部
総合研究大学院大学葉山情報ネットワークセンター
明治大学情報メディア部生田メディア支援事務室

1

1

発生時の対応1.1

安否確認

3 月 11 日の地震発生時の、避難と利用者、保守業者等の外来者、及び要員の安否確認の状況をお聞きしました。
ほとんどの大学・研究所において、保守業者等の確認が行われていました。また、幸いに授業期
間ではなかったために、利用者が少なく、誘導や確認が行われていました。
当日に勤務していた要員は、退避後、ただちに確認が行われていました。しかし、休暇や出張で不在であった要員の安否確認は、電力や通信の途絶によって、時間を要した事例がみられます。最
終的には、全員の安否が確認されています。
新聞等の報道でもありましたが、電話や PC メールよりも、携帯メールが有効であったようです。

1.2

基盤の状況

ガス、水道、電話、電力といった、基本的な基盤の被害状況をお聞きしました。
東北地方では、ガス・水道は使えなくなっていました。関東北部の大学・研究所では、断水が発生しています。ガスの元栓の操作などは、施設担当なので管理部門が実施した様子が分かります。
電話については、回線そのものが使えても、交換機のバッテリーが消耗したところで切断してしまった事例が多数報告されています。固定電話が使えなくなった後は、個人の携帯電話が通信手段として、主に使われたあります。しかし、それも非常につながりにくくなったことが報告されています。携帯メール、Skype、PC メールなどを使った事例も報告されています。アマチュア無線を非常用に準備していた大学や、緊急用衛星電話を有する大学もあります。
東北地方、関東北部では、全電源を喪失しました。復電時の漏電を防ぐために、多くの組織でブレカーの切断を行っています。

1.3

情報システムの状況

情報システムの被害状況をお聞きしました。
全電源を喪失した東北地方と関東北部の大学・研究所では、UPS でしばらく給電した後でシス
テムが停止しています。UPS が給電できた時間は 10 分程度から 2 時間と様々ですが、多くの組織
で、サーバ類等が正常終了されています。そのため、大きな障害を負った情報システムは非常に少なく済んでことがわかります。
物的被害は、クライアント PC の転落やラックの移動や歪みが報告されていますが、重要なサーバには物的被害がなかったようです。ラックマウントが、災害対策として非常に重要であることがわかります。
床置きいていた機材は、倒れて壊れるだけでなく、落ちてきた物でケーブルを切断するなどで、被害があったようです。また、ディスプレイの転倒も報告されています。

1.4

ネットワークの状況

ネットワークの状況をお聞きしました。

2

機材はケーブルの損傷は報告がありませんが、東北地方と関東北部の大学・研究所では、電源喪失によって通信が途絶えています。復電によって、概ね通信が再開されていますが、一部では、上流側の復電が遅れて、通信再開が遅れたところがありました。同様に、研究用のネットワークを大学・研究所にまたがって運用しているところでは、当該研究所の復電が遅れて、その研究用ネット
ワークの復旧が遅れたことも回答されています。学内ネットワークも、電源喪失以外は、概ね大丈夫であったようです。

震災当日にできたこと

1.5

東北地方と関東北部のほとんどの大学・研究所では、全電源を喪失しています。そのうちの一部
では、非常用電源を用いた作業が行われました。避難所用の照明・暖房、簡易な情報発信・収集、余震に備えた整理が報告されています。
また、当日は、復電に備えたブレーカ閉鎖、電源ケーブルの取り外し、落下物の整理、戸締りなどが行われています。
また、翌日 3 月 12 日は後期日程の入学試験でしたが、情報部門としては対応できなかったようです。

2発生後の対応2.1

体制

ほとんどの大学・研究所では、センター長や室長など情報部門の長を中心とした体制をとり、状況確認や復旧にあたっています。大学・研究所全体の対策担当との連絡も、概ね円滑であったようですが、一部ではうまく機能しなかったと報告されています。
緊急連絡網が作られていなかった大学・研究所が多くみられます。また、緊急連絡網には電話しか記載がなく、使えなかったという事例も報告されています。固定電話、携帯電話だけでなく、携
帯メールなど、複数の連絡手段の情報を集めておく必要があるでしょう。
利用者への通知は、掲示、臨時のホームページ開設などでの対応が報告されています。

2.2

ベンダーからの支援

年度末であったため、システム更新は保守のために、当日にベンダーが居り、すぐに対応が開始された事例が複数報告されています。残りの多くの大学・研究所でも、ベンダーとの連絡が円滑にとれ、復旧への対応が開始されています。

2.3

復旧への経緯全電源を喪失した大学・研究所では、早いところで 12 日、遅いところで 17 日に商用電源が復電しています。ある大学では、11 日の間は非常用電源を使っていたと報告されています。
復電に伴って、対外接続、ネットワーク、DNS、Web、認証、メールといった基本サービスが再開されています。地震発生によりハードウェアの損傷等が報告されていないのに対応して、非常に迅速に、基本サービスが復旧したことがわかります。

3

2.4

計画停電への対応

震災後、東北電力及び東京電力管内で計画停電が行われました。東北地方と関東北部の大学・研究所は、当初は停電が計画されていませんでしたが、実際には実施されていません。
一方、地震発生時に大きな被害の無かった関東地方の大学・研究所では、実際に計画停電が行われ、対応に苦労されたことが分かります。特に、早朝の計画停電に対応するための人の配置、停止・起動を繰り返したための機器の障害などです。
また、全体として、直前まで停電の実施・中止が分からず、要員の確保、非常用電源の確保で苦労され、また大きな疲労感があったことが分かります。

3

今後の対応
災害時への対応体制として、以下のような点が最優先に改善すべき点として挙げられました。

• 要員及び学生・利用者の安全確保• 緊急連絡網の整備、緊急連絡手段の確保• BCP• システムの状態監視、シャットダウン、復旧の手順についての情報共有、マニュアル化、職員のスキルアップ• 業務の属人性の低減• 緊急情報を提供できるだけの最低限の電力• 関係書類のペーパー化• データバックアップ
また、システム基盤については、以下のような改善点が挙げられています。

• 緊急用電源と燃料備蓄• 電力状況の可視化• 断水時の加湿機能• 耐震ラック• 安全な停止手段• 要員の安全と人数確保• 空調の耐震性
災害対策や事業継続の観点から、クラウドサービスなどの活用が謳われています。回答を頂いた
各大学・研究所でも、検討されているようです。しかし、セキュリティの確保、コストの面で課題を感じられているようです。
また、ある研究所ではデータセンターの活用を開始しており、今回の震災でも有効に機能したという回答がありました。

4

東日本大震災発生時の情報管理部門の対応に関するアンケート
集計
1. 発生時の対応
1.1.

安否確認

1.1.1. 状況
1.1.1.A. 地震発生直後に、来訪者・利用者の確認を行いましたか。


保守業者の確認を行った。
（東北地方の大学×５）



来校していた保守業者は、別の建物にいたため、避難場所での確認を行った。（東北地
方の大学）



揺れが収まってから、自習室に居た学生を避難させ、確認した。
（東北地方の大学 2 校）

地震発生直後、利用者の避難路確保のため、各演習室の扉を開放し、天井付近からの落下物を避けるよう注意喚起した。揺れが収まってから避難させ、確認した。（東北地
方の大学）



地震直後に避難場所で業者の現地責任者に確認をした。（東北地方の被学）コンピュータ演習室利用学生を中庭への避難呼び掛けを行った。人数も少数だったので、確認できた。
（東北地方の大学）



教室利用者は避難の呼びかけを行ったが、人数の確認はできなかった。
（東北地方の大学）



建物から避難するように促し、一緒に避難した。（東北地方の大学）



来所していた保守業者の確認を行ったが、人数の確認までは行わなかった。（東北地方の大学）

端末室利用者は避難の呼びかけを行ったが、人数の確認までは行わなかった。（東北地
方の大学）



利用者の避難後、館内に誰もいないことを確認した。人数の確認はできなかった。（東北地方の大学）

来所していた保守業者と実習室利用者の確認を行った。（東北地方の大学）



建屋内にいた学生、外部利用者を屋外に避難させ、避難していない者がいないか確認を行った。
（東北地方の大学）

来訪者はスパコンの工事現場の方であった。一緒に避難するように呼びかけた。スパ
コン工事担当職員が出張していたため人数確認などはできなかった。（関東地方の研究所）



当日、外部からの来訪者はいなかった。
（関東地方の研究所×２、関東地方の大学）

実習室の利用者（学生）は揺れが治まった時点で避難を呼びかけたが、人数の確認はしていない。
（関東地方の大学）



利用者はいなかった。
（関東地方の研究所）行った。
（関東地方の研究所×２、関東地方の大学×２）



行わなかった。
（関東地方の大学）

パソコン演習室利用学生の状況を確認した。（関東地方の大学）



地震による揺れは限定的。来訪者・利用者はいたが確認は行わず。（関東地方の大学）



リプレイス作業中であり、４業者３９名の来所者があったが、全員確認した。（関東地
方の大学）



利用者（学生）は避難所に誘導、コンピュータ室に残っていないことを確認した。
（関
東地方の大学）1.1.1.B. その手段はどのようなものでしたか。


避難場所での確認だったので、課員が声を掛け合って確認した。
（東北地方の大学）

センター職員が確認した。
（東北地方の大学×４）



保守業者は現場責任者が確認した。（東北地方の大学）



センター職員が見回りし確認した。（東北地方の大学×3）



目視確認。
（東北地方の被災大学×3）



保守業者は、業者現場責任者で確認した。（東北地方の大学）



建物の外に出て待機した。
（東北地方の大学）

保守業者は、保守業者どうしによる確認。（東北地方の大学）



屋外に避難させた上で、館内を目視確認した。
（東北地方の大学）



工事担当者不在で確認できなかった。（関東地方の研究所）



保守作業者、業務委託者は、避難時に備えて用意されているリストにより確認した。
人数 10 人以下。
（関東地方の被究所）



センター職員による口頭確認。
（関東地方の研究所）



揺れがおさまってから目視。
（関東地方の研究所）



現場で手分けして確認。
（関東地方の大学）

パソコン演習室業務委託担当者が実習室に出向いて確認を行った。（関東地方の大学）



業者現場責任者に名簿作成をして確認するよう依頼した。（関東地方の大学）

1.1.1.C. 全員の安全を確認できましたか。


確認できた。
（東北地方の大学×12、関東地方の研究所×2、関東地方の大学×4）



利用者が端末室等に居ないことを確認した。（東北地方の大学×4）



当日は不明であったが、後の問題は報告されていない。（関東地方の研究所）

1.1.2. 要員の確認
1.1.2.A. 地震発生直後に、要員の安否確認を行いましたか。
行った。
（東北地方の大学×12、関東地方の研究所×2、関東地方の大学×6）



出張者を除き行った。
（東北地方の大学、関東地方の研究所×2）



行わなかった。
（東北地方の大学、関東地方の大学）

1.1.2.B. その手段はどのようなものでしたか。


避難場所で集合確認した。
（東北地方の大学×9、関東地方の大学）



避難場所で点呼した。
（東北地方の大学×3、関東地方の研究所×3、関東地方の大学×6）



不在の者については電話確認。
（東北地方の大学、関東地方の研究所×2、関東地方の
大学×6）



停電対応のため事務室に集まって確認した。（東北地方の大学）



各業務区分毎に在室中の上席者が確認を行った。（関東地方の大学）



事務室にてセンター長が確認した。（関東地方の大学）



避難場所で点呼、名簿作成をした。（関東地方の大学）

1.1.2.C. 全員の安全を確認できましたか。


確認できた。
（東北地方の大学×13、関東地方の研究所×4、関東地方の大学×6）

1.1.2.D. 特に、当日、不在であった要員の安全確認まで要した日数を教えてください。


１日。携帯電話のメールで確認した。停電が続き、携帯電話の充電もできない状況であった。
（東北地方の大学）



・当日、休暇のため要員 4 名中 1 名不在であったが、翌日（中 1 日）、携帯電話の電子メールにて安全確認した。（東北地方の大学）

センターではなく，大学の教職員の安否確認の中で要員の安全確認をしたため，全員は一週間程度かかった。（東北地方の大学）



出向中の職員の確認に３日要した。（東北地方の大学）

出張中であった要員については、3 日経過した 14 日の電話復旧後の確認となった。
（東
北地方の大学）

休暇で不在であった者は、携帯電話のメールで確認した。（東北地方の大学）

出張中であったものには、震災翌日に電話確認できた。（東北地方の大学）

海外出張中の教員と停電からの復旧した 3 月 12 日に連絡がとれた。
（東北地方の大学）



翌日には確認できた。
（東北地方の大学）



電話により確認したが、出張中であり携帯電話でしか連絡がとれなかったが、携帯電話がつながりにくく 2 日目に確認がとれた。（関東地方の研究所）



休暇中１名が確認に３日かかった。それ以外は半日。（関東地方の研究所）



当日中に電話などで確認したが、帰宅できたか等は翌日に確認。
（関東地方の研究所）

不在であった要員の安否を電話で確認しようとしたが、電話が不通であったため、全員の安否確認ができたのは、３日後であった。
（関東地方の大学）



当日中に確認。（関東地方の大学）



当日中メールなどで確認（関東地方の大学）不在であった者は、当日中にメールで確認した（関東地方の大学）。



予定休暇で 2 名が不在、当日は特に確認せず。休暇明けに予定通り出勤して確認した。

（関東地方の大学）
1.2.

基盤の状況

1.2.1. ガスと水道
1.2.1.A. ガス及び水道の状況はどのようなものでしたか。


ガスは停止した。
（東北地方の大学×7、関東地方の研究所、関東地方の大学×6）



水道は停止した。
（東北地方の大学×5、関東地方の研究所×2、関東地方の大学×6）



水道は貯水槽にある分は利用できた。ただし、貯水槽への送水管が破損した。（東北地
方の大学）



学内の一部の水道は学内タンクのものが使えた。また，大学が給水所になったため，限定的に水は使えた。
（東北地方の大学）



受水槽により、センターでは水道を利用できた。（東北地方の大学）



水道：ポンプ式のため停電中は使用不可（東北地方の大学）

1.2.1.B. ガスの停止等を行う必要はありましたか。適切に実行できましたか。


大学本部がガス等の停止を実施した。（東北地方の大学）



ガスの元栓を閉じた。
（東北地方の大学）



管理課で一括対応。
（東北地方の大学）

地震発生直後念のためガスの元栓を止めた。（東北地方の大学）

1.2.2. 電話など通信基盤
1.2.2.A. 電話の状況はどのようなものでしたか。
親のシステム（交換機本体）はバッテリで給電されていても、子のシステムは、給電されず、職場のビジネスフォンの使用は復電（3/13）するまでできなかった。携帯は使用できた。
（東北地方の大学）



通常の電話は使えなくなり、携帯電話もつながりにくい状況であった。また、当日の夕方からは、ほとんど圏外となり、全く利用できなくなった。（東北地方の大学）



通常の電話は使えなくなり、携帯電話もつながりにくい状況であった。また、当日の夕方からは、ほとんど圏外となり、全く利用できなくなった。（東北地方の大学）



通常の電話は使えなくなり、携帯電話もつながりにくい状況であった。また、当日の夕方からは、携帯電話はほとんど圏外となり、全く利用できなくなった。
（東北地方の大学）



停電のため，学内の PBX が停止したため，固定電話は使えなかった。業務用携帯電話は使えた。
（東北地方の大学）



交換機のバッテリーが給電している数時間だけ使えた。その後使用できなくなった。
（東北地方の大学）



停電後使用不可。
（東北地方の大学）



当日はバッテリーにより使用できた。（災害時優先電話） 電話は使用できた。
（東北地
方の大学）



停電していたので、特に利用しようとは思わなかった。（東北地方の大学）



使用可能。
（東北地方の大学）



停電のため不通（東北地方の大学）



大学の内線は利用可能だった。
（東北地方の大学）



交換機のバッテリーで数時間は電話が使用可能であったが、翌未明から使用できなくなった。
（東北地方の大学）



直後は所内の PHS、電話ともに使えた。研究所全体の電源が喪失した後は使えなかった。携帯電話については不明。
（関東地方の研究所）



情報部門の居室では 当日は PHS、電話とも使用可能。 交換機のバッテリーが切れた
翌日から、つかえなくなった。研究所の一部では、ネットワークと共通回線でつないでいた施設の PHS、電話は SW への給電が停止した地震直後より不通（関東地方の研
究所）



使えた。
（関東地方の研究所×２）



一般の電話は不通となった。携帯電話は、まれに繋がる程度であった。
（関東地方の大学）

不通（関東地方の大学）



機器の故障などは無かったが、電話が通じづらかった。（関東地方の大学×2）

利用可能（関東地方の大学×3）

1.2.2.B. 代替の通信手段はありましたか。それは、使えましたか。


非常用に準備していたアマチュア無線設備を設置して、３キャンパス間の連絡に使用した。
（東北地方の大学）



業務用携帯電話を使った。（東北地方の大学）



EMOBILE 経由にてのインターネット接続のみ。（東北地方の大学）



個人の携帯のみで、代替通信手段は特になかった。また通話制限によりほぼ繋がらなかった。
（東北地方の大学×2）



個人の携帯電話は使えた。サイト契約をしている WiMAX は使えなかった。
（東北地方
の大学）



1 台のみ設置している受信専用の電話機が使用できた。（東北地方の大学）



代替なし。
（東北地方の大学×5）



ネットワーク回線で接続し、地震直後から不通となった施設には、最低一か所は通常の電話を用意していた。ISDN で引いていたところは停電のため使用不能。代替がなかった。
（関東地方の研究所）



電話が不通の地域でも Skype が可能であり役に立った。（関東地方の研究所）

電子メールが使えた。
（関東地方の研究所）



学内 PHS が使用できた。（関東地方の大学）



携帯電話（関東地方の大学）



電話やメールの利用が可能であったため、代替手段は必要ではなかった。
（関東地方の大学）

電話（固定電話・携帯電話）およびインターネット以外の代替の通信手段はない。
（関
東地方の大学）

キャンパスに緊急用の衛星電話があるが、必要となる場面はなかった。
（関東地方の大学）

1.2.3. 電力
1.2.3.A. 電力の状況はどのようなものでしたか。


全電源を喪失した。
（東北地方の大学×12、関東地方の研究所×2、関東地方の大学×2）



停電にならなかった。
（東北地方の大学、関東地方の研究所×2、関東地方の大学×5）



建物のブレーカーの閉鎖をした。（東北地方の大学×5、関東地方の研究所×2）



各機器については電源を切り、電源ケーブルを抜いていった。
（東北地方の大学）



停電後、非常用電源への切替のための分電盤の作業は契約している建物管理業者が行った。
（関東地方の大学）

1.3.

情報システム1.3.1. 電力
1.3.1.A. 電力消失によってシステムの停止はどのような状況でしたか。


自動停止した。
（東北地方の大学×3）



UPS の給電の後に停止した。
（東北地方の大学×9、関東地方の研究所×2、関東地方の
大学×2）



UPS にも異常が発生した異常終了した。（東北地方の大学）

1.3.1.B. 残った電力で正常に停止できましたか。


UPS に接続していた機器は停止した。
（東北地方の大学×12）



一部、異常終了した。
（東北地方の大学×3）



分電盤のブレーカーをおとしたことによる異常停止となった。（関東地方の研究所）



地震発生後、建物への立ち入りが制限されたため、停止作業ができなかった。UPS 停
止信号で、自動シャットダウンする機構は、それが必要な事態が今まで全くなく、誤動作を恐れ利用していなかった。（関東地方の研究所）

1.3.1.C. 無停電電源装置等で継続できた時間はどの程度でしたか。


10 分程度（8）

30 分程度（4）

2 時間以上（1）1.3.2. システム
1.3.2.A. システムの障害の状況はどのようなものでしたか。


システムは、ディスクの不整合があったものが数台あったが、全て稼働した。また、サーバで、倒れたものはなかった。（東北地方の大学）



ネットワーク通信機器のラックが大きく歪んだ。教室のプリンタが９台落下し破損した。クライアントは耐震ゲルのお陰でほとんど被害はなかった。
（東北地方の大学）

倒壊したシステムはなく、ラックが歪んだ程度であった。（東北地方の大学）

クライアント PC が数台転倒した以外、破損・倒壊したシステム等はなく無事だった。



情報センター管轄の機器はラックの位置がずれた程度で，実質の被害はなかった。（東北地方の大学）

物理的な破損等は多少あったが、システムの被害はなかった。（東北地方の大学）



ラック搭載機器（サーバ類、ネットワーク機器類）に被害はなかった。また、各演習室のディスプレイや PC が倒れたが、ケースの破損など軽微な被害であった。（東北地
方の大学）



タワー型サーバが落下したが、幸いシステムには影響がなかった。（東北地方の大学）



公式 Web サーバ及び WAF1 台が起動しなかったが、他のシステムは通常起動できた。



ラックマウントしていた NTP サーバに故障が起こったが、直接の原因は不明であった。
（東北地方の大学）

地震の揺れによる被害はなく，停電によるシステム停止のみ。



大きな被害はなし。並べていたラックが移動したが、ケーブル断はなかった。（東北地（東北地方の大学）

方の大学）
システムは全て耐震補強を施したラックにマウントしていたため、被害はなかった。
（関東地方の研究所）



ラックはかなり動いたが転倒はしなかった、ケーブル余長があり、切断しなかった。
機器はハードウェア的にはすべて健全。Oracle DB で停止手順を行えなかったものは、
DB の再構築が必要になった。
（関東地方の大学）

1.3.2.B. データの損失はありましたか。


データ送信はなし

1.3.2.C. システムのハードウェア的損害はありましたか。


ネットワーク通信ラックが破損した。
・教室のプリンタが９台落下し破損した。クライ
アントは耐震ゲルのお陰でほとんど被害はなかった。一部サーバのマザーボード、CPUで障害が発生した。（東北地方の大学）一部、ハードディスクやテープドライブの故障が発生していた。クライアント系では、
セキュリティワイヤのお陰で、床に落下することが免れたため、ほとんど被害がなかった。
（東北地方の大学）



演習用 PC のディスプレイが転倒，落下して傷がついたり，故障したものがあった。ドキュメントスキャナがレンズが割れたものがあった。（東北地方の大学）



サーバが 1 台故障したが冗長化を行っていたため問題なかった。
（東北地方の大学）



一部の機材に破損があった。（東北地方の大学）



各演習室のディスプレイや PC が倒れたが、ケースの破損など軽微な被害であった。
（東北地方の大学）

ファイルサーバのディスク 2 枚（Raid5＋ホットスペアｘ2）と Win サーバのディスク
1 枚（ミラー）、公式 Web サーバの電源、WAF が故障した。（東北地方の大学）



床置きにしていた機器の AC ケーブルが、落下してきた物により切断したもの一件があった。その他の機器すべて健全（関東地方の大学）



サーバ機器は損傷無し。情報教室 PC で若干ディスプレイの転倒や落下があった。
（関
東地方の大学）1.4.

ネットワークの状況

1.4.1. 上流側の状況


ケーブル切断はなし



電源喪失による通信断のみ

1.4.1.A. 論理的接続状況


復電後に通信可能となった。
（東北地方の大学×11、関東地方の研究所）



復電後も、3 月 13 日 14 時過ぎまで不通であった。
（東北地方の大学）

３月１１日１７時頃に非常用電源の給電をうけ、１８時頃最小限のネットワークを復旧させた。上流側への接続も問題なかった。（関東地方の大学）

1.4.2. 学内ネットワークの状況
1.4.2.A. 機材、ケーブルの状況


壁取り付けの情報コンセントが物の落下によって何箇所か破損した。機器やケーブルに損傷はなかった。（東北地方の大学）



壁面取付のフロアスイッチ用ラックが壁からはがれ、光ファイバで浮いている状態になったものがあった。機器やケーブルに損傷はなかった。（東北地方の大学）

フロアスイッチの一部に故障がみられた。ケーブルは被害なし。
（東北地方の大学）



１台、電源ケーブルが外れているものがあったが、機器の破損・ケーブルの切断はなかった。
（東北地方の大学）



一部建物のフロアスイッチが使用不能となった。（関東地方の大学）

POE スイッチの一部に故障があった。（関東地方の大学）

1.4.2.B. 論理的接続状況


東北地方の支所との接続に 3 日かかった。プロバイダの復旧待ち。
（関東地方の研究所）

1.5.

当日に可能であった復旧作業

1.5.1. 当日使用できる電力があった場合
1.5.1.A. 使用できた電力は通常のものですか。非常用ですか。非常用の場合、どのようなものですか。


ガソリンを使う非常用電源を使用した。
（東北地方の大学×3）



大学の非常用電源を、３月１１日１７時頃から、商用電源が復旧時（３月１２日６時頃）まで使用できた。
（関東地方の大学）

研究所としては非常用発電機による電源があったが、ネットワーク機器は利用できな
い。
（関東地方の研究所）

1.5.1.B. どのような作業ができましたか。


避難所の照明。
（東北地方の大学）

情報発信のための携帯電話用 Web コンテンツ作成。
（東北地方の大学）

小型ワンセグテレビに給電し、被害状況を確認した。（東北地方の大学）



ネットワークを稼働し、大学ホームページにより翌日の後期日程試験中止を始め震災関連情報を発信した。
（関東地方の大学）



システムの点検をする（余震があるので危険性がある箇所は除く）。 棚などから落ちた物を片付ける（余震で再度落ちないように注意）。
（関東地方の大学）

1.5.2. 当日使用できる電力が無かった場合
1.5.2.A. できた復旧作業等はありましたか。


復電後の状況を考え、UPS の停止やブレーカーの OFF 等の作業をした後、避難所のサ
ポートを行った。（東北地方の大学）



配電盤で電源を切った（東北地方の大学



翌日以降の体制の打ち合わせを行った。
（東北地方の大学）

各システムの電源停止と電源ケーブルの取り外し。
（東北地方の大学）



翌日以降の対応の打ち合わせを屋内で行った。
（東北地方の大学）



館内の目視点検と翌日以降の対応確認。
（東北地方の大学）

建屋の物理的被害の確認や、戸締まり等の一般的な確認にとどまった。
（東北地方の大学）



建屋に立ち入り禁止となったため、可能な作業は現場確認とブレーカー断のみ（関東地方の研究所）
1.5.3. 翌日（3 月 12 日）の後期日程入学試験への対応
1.5.3.A. 3 月 12 日は、後期日程入学試験の予定でした。情報部門として、対応できたことはありますか。


安否確認システムの正常動作確認。（携帯電話を使用）（東北地方の大学）

2. 発生後の対応
2.1.

体制の復旧

2.1.1. センター内
2.1.1.A. センターの対応体制はただちに確立できましたか。


上司（課長）との連絡が取れなかったため、課員で連絡を取り合い体制を決めた。
（東
北地方の大学）

キャンパスの建屋（号館）毎に復電作業を進めた。キャンパスに勤務する職員全員で毎朝作業予定について打合せるなどの体制をとった。（東北地方の大学）



被災者対応が最優先となっていたため、センター側の対応体制についてはしばらくの間留保された。機器の面での破損、不具合等の影響は小さかったが、設置室内の環境が大きな影響を受けたため、その復旧に時間を要した。（東北地方の大学）


センター長（情報システム部長）の指示のもと、出勤可能な役職者（課長補佐）と職員を中心に、情報システム課事務システム係、各情報システム係（各情報処理センター）にて被害把握・復旧作業と作業予定の打合せを行う体制をとった。
（東北地方の大学）



当日はセンター要因は全員すぐに帰宅した。日曜日から，副センター長と技術職員の 2名を中心に，復旧作業をおこなった。 センター災害対策支部を設置し、ただちに体制を確立した。
（東北地方の大学）



室長が毎朝対策本部のミーティングに参加し、その後室内にてミーティングを実施した。
（東北地方の大学）センター事務室に集まり、センターとしてできることの打合せを行った。 復 電 後 に最少構成でシステムを立ち上げる旨、申し合わせを行った。（東北地方の大学）



センター長が出張中だったため、理事と連絡を取りながら、対応した。
（東北地方の大学）



翌日にはセンターの職員が全員出勤し、復電後に復旧作業などを行った。
（東北地方の大学）

センター長を中心に毎日朝９時に集まり、作業報告と作業予定について打ち合わせるなどの体制をとった。
（関東地方の研究所）



被害がひどく、研究所全体の復電もかなり時間がかかると考えられたので、週明けに対策会議が開かれた。それまで自宅待機。（関東地方の研究所）

できた。
（関東地方の研究所）



通常の運用体制を維持した。（関東地方の研究所）



被害がひどく、研究所全体の復電もかなり時間がかかると考えられたので、週明けに対策会議が開かれた。それまで自宅待機。（関東地方の大学）

情報システム推進部長を中心に、随時打合せを行う体制をとった。（関東地方の大学）

2.1.1.B. 事前に緊急連絡網はありましたか。それは機能しましたか。


事前の緊急連絡網はありませんでした。復電後は、ネットワークが利用できたため、遠隔会議方式で、連絡網を確立した。（東北地方の大学）



緊急連絡網（携帯電話のメール）で、不在であった職員と連絡をとった。
（東北地方の大学）



要員の緊急連絡先一覧にて、不在であった職員等との連絡が可能であったため、時差はあったものの機能した。（東北地方の大学）



緊急連絡網は更新されていなかった。（東北地方の大学）



緊急連絡網はあったが、電話が通じにくく機能したとは言いにくい。
（東北地方の大学）

携帯メールを使用した緊急連絡メールを発信した（学生・教職員）（東北地方の大学）



連絡網は自組織内のものしかなく、特に必要なかった。（東北地方の大学）



緊急連絡網を通じて、不在であった職員との連絡をとった。（東北地方の大学）



緊急連絡網があり、不在者と連絡を取った。（東北地方の大学）



緊急連絡網は存在し，学生，附属学校の生徒への連絡に用いた。
（東北地方の大学）



緊急連絡網はあったが、不在者がいなかったため、使用しなかった。（東北地方の大学
×2）



緊急連絡報はなかった。（東北地方の大学×2）あった。不在の職員に特に連絡はしなかった。
（関東地方の研究所）



緊急連絡網を通じて、職員との連絡をとりあったが、数日は電話が非常につながりず
らい状況。自宅で個人で入っているメールで緊急に幹部のＭＬが作成され、それで連絡をとりあった。
（関東地方の研究所）



機能した。
（関東地方の研究所）



普段より携帯電話一覧を利用しており、繋がりにくいことを除いては通常通り活用した。
（関東地方の研究所）



緊急連絡網はあったが、教職員のほとんどがセンターにいたため、使用しなかった。
また電話による連絡網であったため、実際に使用しても機能しなかったと思われる。
（関東地方の大学）



緊急連絡網という位置づけのものはないが、通常の連絡網で十分機能した。（関東地方の大学）

職員、業務委託業者単位で存在し、機能した。
（関東地方の大学）



事前に用意していた連絡網は存在していたが、現場で所在確認ができたため使用せず。
（関東地方の大学）

2.1.1.C. 迅速に、対応体制は確立できましたか。


震災当日は、避難所としての対応体制が確立され対応した。



当日中に、キャンパス内の体制が確立され、速やかに避難所の支援が実施された。
（東
北地方の大学）

震災当日の夕刻には東北学院災害対策本部が設置され、その傘下にて情報システム課（情報処理センター担当職員）の体制が職員に周知された。（東北地方の大学）



震災翌日から副センター長と技術職員が連絡を取り合い，復旧体制を確立した。
（東北地方の大学）

センター災害対策支部により迅速に体制を確立できた。（東北地方の大学）

震災当日から体制の確立し情報収集等の作業を実施。（東北地方の大学）



震災当日の夜に体制を整備した。（東北地方の大学）



震災当日に出張中のセンター長に連絡がとれなかった。翌日、理事と連絡が取れた。
（東
北地方の大学）

担当技術職員と滞在中のベンダーの担当者で対応した。（東北地方の大学）



法人本部が中心となり、体制の確立を行った。
（東北地方の大学）確立できた。
（関東地方の研究所×3、関東地方の大学）



地震当日の１６時頃関係教職員により対応体制を整えた。また大学の災害対策本部へも連絡した。
（関東地方の大学）

2.1.2. 大学・研究所とセンターとの連携
2.1.2.A. 大学・研究所全体の対応体制との連携は十分でしたか。


組織毎に体制を取り、相互に連絡をした。また、定時で緊急対策委員会の会議が開催され参加した。（東北地方の大学）キャンパスの学部長が災害対策本部の会議に出席し、情報の共有と連携をとった。テ
レビ会議システムが使えるようになってからは、連絡が密に取れるようになった。
（東
北地方の大学）

キャンパスの学部長が災害対策本部の会議に出席し、情報の共有と連携をとった。ただし、ガソリン不足もあり、車での移動には限界が感じられた。テレビ会議システム
が使えるようになってからは、連絡が密に取れるようになった。
（東北地方の大学）



センター長の指示のもと、役職者（課長補佐）が、大学本部の会合に出席し各種情報を得るなどして連携した。（東北地方の大学）



副センター長が大学の対策本部と綿密に連絡をとりあった。（東北地方の大学）

大学本部とセンターが離れたキャンパスにあるため、連絡手段がなく十分な連携ができなかった。
（東北地方の大学）



室長が毎朝対策本部のミーティングに参加した。（東北地方の大学）

副課長が危機対策本部会議に出席して情報を共有して連携した。
（東北地方の大学）



大学の状況等が伝わってこなかった。（東北地方の大学）



災害対策本部には部長が出席し、事務部内で情報共有が行われ、担当ユニット長からセンター要員に伝達が行われた。（東北地方の大学）

支障はなかった。
（東北地方の大学×2）

不十分であった。（東北地方の大学×2）

センター長が、研究所災害対策本部の会合に出席して各種の情報を得るなどして連携した。
（関東地方の研究所）



情報セクションリーダーが研究グループの災害対策本部会合に出席し情報交換し連携した。研究グループは、研究所の対策会議に出席した。（関東地方の研究所）

十分であった。（関東地方の研究所）

センター長が研究所の対策本部長であった。（関東地方の研究所）

センター長等が逐次大学の災害対策本部を訪れ、連絡を密にした。（関東地方の大学）



ほぼ問題なし。
（関東地方の大学）

情報システム推進部長が、法人の災害対策本部の会合に出席して各種の情報を得るな
どして連携した。
（関東地方の大学）

2.1.2.B. 大学・研究所全体の対応窓口は明確でしたか。


震災当日に緊急対策本部が設置され、意思統一のため最初は全員参加で情報共有した。
また、学外対応窓口・電話・電子メールを公開し、連絡網を確立した。（東北地方の大学）



災害対策本部には、情報システム部長も参加した。
（東北地方の大学）

対策本部として、大学総務部総務課打合わせに出席し各種情報を得るなどして連携した。
（東北地方の大学）



大学に当日から対策本部が設置され，震災翌日から副センター長が対策本部と連絡をとりあった。朝昼晩と事務職員による会議があり，副センター長が参加した。（東北地
方の大学）



大学本部に災害対策本部が設置されたが、連絡手段がなく窓口としてうまく機能できなかった。
（東北地方の大学）

対策本部が設置され、室長も参加した。
（東北地方の大学）



事務部門にはあった。
（東北地方の大学）



危機対策本部が設置され、窓口となった。（東北地方の大学）



法人の対策本部が設置されていたが、詳しい情報は得られなかった。
（東北地方の大学）

対策本部が震災当日に設置されたが、センター要員は本部員には含まれていなかった。
（東北地方の大学）

支障はなかった。
（東北地方の大学×2、関東地方の研究所×4、関東地方の大学）



明確でなかった。
（東北地方の大学）

地震後直ちに大学の対策本部が設置され、センター長等が連絡をとりあった。（関東地方の大学）

2.1.2.C. センター側の大学・研究所全体の対応担当者は明確でしたか。


課長補佐を主担当として、課員で情報共有した。（東北地方の大学）

情報システム部長および情報システム課長補佐が担当した。（東北地方の大学）



センター長（情報システム部長）の指示のもと、出勤可能な役職者（課長補佐）が担当した。
（東北地方の大学）



副センター長対応した。（東北地方の大学）



明確ではなかったが、結果として情報基盤課長等がそれにあたった。
（東北地方の大学）



室長及び室員が担当した。（東北地方の大学）



窓口はあった。（東北地方の大学）

課長および副課長が担当した。
（東北地方の大学）



現場担当者（センター職員）が担当した。（東北地方の大学）



学術情報ユニット長が担当した。（東北地方の大学）



センター長が出張中であったため、専任教員が担当した。（東北地方の大学）



明確でなかったが，主に技術専門職員が担当した。
（東北地方の大学）

図書館情報センター職員全員が行った。
（東北地方の大学）

明確であった。
（関東地方の研究所×4）

センター長及び情報環境機構長が担当した。（関東地方の大学）



通常通りの態勢で対応した。（関東地方の大学）



センター教員(１名）
・事務職員(１名)が担当した。（関東地方の大学）

2.1.3. 利用者への通知は円滑に実行できましたか。


復電後は、HP で随時情報公開した。（東北地方の大学×6）



建物内の復旧作業が最優先の対応事項であり、その対応完了後から一般利用者への開放を実施した。
（東北地方の大学×2）



大学の対策本部を通して，学内に掲示をし，臨時大学 Web サイトを復電後から復旧させ情報公開を行った。また，Gmail を使い，Web サイトで連絡先として公開し，学外からの教職員，学生からの情報を受け付けた。
（東北地方の大学）



安全確認が確立されるまでは入口に立ち入り禁止の掲示を行った。震災により破損した PC・プリンタ等に関しては、状況写真を撮影し代替え案を検討した。（東北地方の大学）



特に行わなかった。
（東北地方の大学×2）

センター内各教室を閉鎖し、入り口に利用できない旨の張り紙をした。
（東北地方の大学×2）



復電までは、センターを利用できないことを館内に掲示した。学内ネットワーク復旧
後は、学外接続の復旧状態を、学科等のネットワーク管理者に、メーリングリストでアナウンスした。
（東北地方の大学）



復電からシステムの起動を行い，サービスが利用可能となるまでに時間を要することが利用者に認知されておらず，苦情や問い合わせがあった。（東北地方の大学）



復電までは建屋を立ち入り禁止とし、施錠した。（東北地方の大学）

特にセンターとして公式には行っていない。研究所内の各建物は、震災後 2 週間かけて徐々に電源を使用できるようにしていく方針がとられた。その期間は多くの職員（主たる利用者）が自宅待機となっていた。メールなどは VPN で利用できるようになっているので、必要な案内は各サービス担当者にまかせられていた。各建物で電気が使えるようになる度に、統括情報セキュリティ責任者がセキュリティパッチをあてることとウィルス定義ファイルを更新することを、全所放送で呼びかけた。（関東地方の研究所）



ネットワークを利用する各部署の施設の被害が大きく、それら施設の復電時にはネッ
トワークは復帰していた。一般利用者は立ち入り制限されていた。被災状況については早期に運転を開始した研究所の Web サイトを利用し広報した。（関東地方の研究所）



地震直後は正常運用であったので利用に関する通知の必要はなかった。輪番停電、計画停電がはじまった後は、共同利用室の貼紙や電子メールで停止／起動のお知らせを行った。特段の問題はなかった。復電後は緊急連絡メールにて学生・教職員に連絡事項を通達した。（関東地方の研究所）


建物への入館禁止を知らせる貼り紙をした。ネットワークやシステムの復旧状況等については、センターHP で広報した。（関東地方の大学）

ホームページ、学内ポータルを利用して通知を行った。（関東地方の大学）

障害が発生しなかったため、不具合等特段の通知は行わなかった。ただし大学公式ホームページで、安否確認を含む情報提供の窓口を設けた。（関東地方の大学）



平常時と同様の周知や作業を行った。（関東地方の大学）

2.2.

ベンダーとの連携

2.2.1. ベンダーとの連絡は直ちに取れましたか。


震災当日は連絡網が途絶えたが、3 月 14 日に携帯電話での状況確認がなされた。
（東北地方の大学）



震災翌週に連絡がとれた。（東北地方の大学）



震災発生直後から復電までの間はお互いの携帯電話でのやりとりが数回できた程度が精一杯だった。３月１４日の復電後よりメールでの連絡が可能となり、現状の共有が可能となった。
（東北地方の大学）



震災当日に保守業者が来室していたため、状況把握は正確に行われていた。（東北地方の大学）

復電した，14 日月曜日から携帯電話でベンダーと連絡をとった。
（東北地方の大学）

取れなかった。
（東北地方の大学）



震災後、ベンダーから連絡があった。（東北地方の大学）



復電時、自主的に来学してくれた。（東北地方の大学）

メールにて連絡を取った。（東北地方の大学）

３月１６日に連絡を取り、故障機器等の修理依頼を行った。（東北地方の大学）



当日作業中だったため、直に情報共有できた。
（東北地方の大学）



翌日、連絡が取れた。また、13 日の日曜日には、関係者に来学してもらい、対応を協議した。
（東北地方の大学）

ベンダー担当者がシステム更新作業により本学に滞在中だったため，直接打ち合わせを行うことができた。
（東北地方の大学）



翌日に電話で状況報告を説明した。（東北地方の大学）



連絡がとれた。
（関東地方の研究所）



常駐なので問題なし。
（関東地方の研究所）



ネットワークについては、問題なく復旧したため、特に連絡をとらなかった。また全学計算機システムについてはベンダーの担当者が常駐しているため、直ちに連絡がとれた。
（関東地方の大学）

当日中に CE より確認の電話がきた。（関東地方の大学）

2.2.2. ベンダーとの連絡は直ちに取れましたか。


3 月 15 日にハードウェアの点検が行ってもらった。
（東北地方の大学）



復電後のシステムの復旧作業は大学側で実施し、その後の機器動作の確認作業等についてリモートからの操作で支援いただいた。物理的な故障が発生した機器については
後日対応いただいた。
（東北地方の大学）



復電後のシステムの復旧作業は大学側で実施し、その後の機器動作の確認作業等についてリモートからの操作で支援いただいた。物理的な故障が発生した機器については
後日対応いただいた。
（東北地方の大学）



復電後、特段問題もなくシステムが正常稼働したため、ベンダーからの支援は必要なかった。
（東北地方の大学）



一社は 15 日に来て復旧作業をしてくれたが，他の業者からの支援は，携帯電話での支援のみであった。（東北地方の大学）



支援は得られなかった。（東北地方の大学）

多少時間がかかった。
（東北地方の大学）

一部業者からは得られた。（東北地方の大学）



直ちに支援してもらった。（東北地方の大学）



連絡後、直ちに対応してもらったが、一部、配送業者のサービス停止期間があり、対応が完了しなかった。
（東北地方の大学）



復電後、復旧を支援してもらった。（東北地方の大学）

得ることができた。
（東北地方の大学×2、関東地方の研究所×3）



実害がなかったが、あればできる範囲で対応してもらえたと思う。（東北地方の大学）



学内に分散配置している全学計算機システムについては復旧作業を支援してもらった。
（関東地方の大学）

2.3.

復旧への経緯（時間を追って記載してください）

2.3.1. 復旧の状況
2.3.1.A. 最小限の電力確保・サービス再開は、いつでしたか。


3 月 12 日に復電した。
（東北地方の大学）

3 月 12 日夜に復電した。
（東北地方の大学）

3 月 12 日に復電し、13 日に一部サービスを再開した。（東北地方の大学）

3 月 13 日に完全復電し、3 月 14 日午前中でサービスの再開ができた。（東北地方の大学×2）



3 月 14 日に復電した。
（東北地方の大学×4）



3 月 15 日に復電。
（東北地方の大学×4）



3 月 17 日に復電した。
（東北地方の大学×4）



サービスは停止しなかった。（東北地方の大学）

3 月 14 日（関東地方の研究所）



建屋への立ち入り制限解除 3/17 / UPS 系電源復帰 3/17 / 一般系電源復帰 3/22 /ネットワークサービスの復帰 3/22 （関東地方の研究所）



３月１１日１８時頃から非常用電源によりサービスを再開した。
（関東地方の大学）

2.3.1.B. そのときに、復旧できたサービスは何ですか。
キャンパスネットワークサービス、事務システムサービスのほぼ全部復旧した。
（東北地方の大学）



対外接続、DNS、HP、メールを復旧させた。これにより、テレビ会議システムが稼働できた。
（東北地方の大学）

対外接続、DNS、HP、メールを復旧させた。これにより、テレビ会議システムが稼働できた。
（東北地方の大学）

対外接続、DNS、HP、メールを復旧させた。これにより、テレビ会議システムが稼働できた。
（東北地方の大学）

DNS, Web サイト, インターネット接続 スーパーコンピュータを除くすべてのサービスを復旧した。
（東北地方の大学）（東北地方の大学）



対外接続、DNS、学内インフラ

Mail および DNS を復旧した。一部 Mac 系サーバを除き復旧。
（東北地方の大学）

対外接続、DNS、HP、認証、ファイル、Mail

概ねのシステムを復旧した。
（東北地

方の大学）


復電の翌朝から復旧作業をした（東北地方の大学）

全てのシステム。
（東北地方の大学）



順次サーバを起動し、すべてのサービスを再開した。（東北地方の大学）

基幹スイッチ、DNS サーバ、暫定版の HP、メールサービス、VPN サービス、研究用
対外ネットワーク等を再開した。（関東地方の研究所）



3/22 にほぼすべてのサービスを復旧した。 各建屋へのネットワークサービスは、各建屋における復電に応じて行った。（関東地方の研究所）



最小限のネットワーク、DNS、メールゲートウエイ、認証システム、大学公式 HP。
（関
東地方の大学）2.3.2. 縮退運転
2.3.2.A. 縮退であっても、基本的サービスを復旧できたのはいつでしたか。


復電の 2 日後（東北地方の大学×2）



復電の 2 日後に、スーパーコンピュータのログインサーバとファイルサーバの運用を開始した。
（東北地方の大学）



復電とともに制限つきながらもサービス復旧した。
（東北地方の大学）



復電の翌日（東北地方の大学×2）



復電の 8 日後、各建物に順次（日ごとに）復電開始となり、研究所内ネットワークが回復していった。
（関東地方の研究所）



建物への立ち入り解除の 7 日後（関東地方の研究所）



地震自体による影響はなかった。輪番停電、計画停電、節電によって３月１３日より縮退運転が始まった。
（関東地方の研究所）



３月１２日６時頃、商用電源が復電した。（関東地方の大学）

2.3.2.B. そのときに、復旧できたサービスは何ですか。


認証、メール、HP サービスを再開した。（東北地方の大学×3）

Web サイト（学外向け）,インターネット接続,認証システム,ポータルサイト,メール,Web
メール,アンチウィルスソフト配布（東北地方の大学）

スーパーコンピュータのファイル転送(データ、実行結果等) （東北地方の大学）



無線・VPN 以外の全サービス（東北地方の大学）



一部 Mac 系サーバを除き復旧。（東北地方の大学）



対外接続、DNS、HP、認証、ファイル、Mail（東北地方の大学）



復電した建物へのネットワーク接続を再開した。（関東地方の研究所）



インターネット接続、Web, メール等ほぼすべて（関東地方の研究所）



商用電源復電後、順次システムを復旧させ、１９時頃には全てのシステムを復旧させた。
（関東地方の大学）

2.3.3. 概ねのサービス復旧
2.3.3.A. 概ねのサービスはできましたか。それはいつでしたか。


3 月 12 日。
（東北地方の大学）

3 月 12 日午後。
（東北地方の大学）

3 月 13 日 14 時頃（東北地方の大学）

3 月 14 日午前中（東北地方の大学）

3 月 15 日に一部サービスを除き復旧。（東北地方の大学）

3 月 16 日に復旧（東北地方の大学）

3 月 23 日に全サービス復旧した。サーバ等の冗長化構成も復旧したのは，3 月 29 日。



3 月 24 日午前中に全てのサービスを復旧。
（東北地方の大学）

スーパーコンピュータについて、3 月 24 日に演算用サーバの一部を稼働し、5 月 9 日にすべての演算用サーバを稼働した。（東北地方の大学）

3 月 28 日から開館し、クライアント PC の一般利用を含めすべてのサービスを再開。
（東北地方の大学）



加湿器不具合が発覚し、3 月 25 日（金）夕方～28 日（月）朝までシステムを停止した。
平日は家庭用加湿器で加湿した。（東北地方の大学）



４月７日深夜の余震で再び停電となったため、４月９日に復電し、すべてのサービスが復旧した。
（東北地方の大学）

3 月 25 日に一部サービスを除いてほぼ復旧した。（関東地方の研究所）

2.3.3.B. 復旧できなかったサービスはありますか。


ディスクチェックが必要なサーバ（東北地方の大学）



無線・VPN（東北地方の大学）

故障した NTP サーバサービス。（東北地方の大学）

GRID サービスの一部、ハウジングサービス（関東地方の研究所）

各建屋で復電してない場所へのネットワークサービス（有線、無線）（関東地方の研究
所）

2.4.

計画停電への対応

2.4.1. 貴組織は計画停電の対象でしたか。


対象であった。
（東北地方の大学×6、関東地方の研究所×2、関東地方の大学×2）



対象であったが、実施されなかった。（東北地方の大学×3、関東地方の大学）



対象ではなかった。しかし、電力使用制限が厳しかったため、全サービスの再開には時間がかかった。
（関東地方の研究所）



最初は計画停電の対象であったが、被災地であったため、対象から除外された。
（関東地方の大学）



当初、計画停電の対象と連絡があったが、その後対象外であることが判明した。
（関東地方の大学）

2.4.2. 計画停電への対応のため、稼動・停止を繰り返したサービスはありましたか。


演算サービス用システムを対象として、しばらくの間サービスを停止した。（東北地方の大学）

計画停電が行われるか直前まで不明であったため，一度、全システムを停電開始時刻
前までに停止した。
（東北地方の大学）

スーパーコンピュータの縮退運用（関東地方の研究所）

あるキャンパス設置のサーバすべて。（関東地方の大学）



冗長化をしているため停電対象となったサーバは停止していた。
（関東地方の大学）あるキャンパス及び附属中・高において、計画停電が実施され、キャンパス毎に設置されているシステム/サービスのすべての停止・稼働を繰り返し行った。
（関東地方の大学）



事務業務システムを対象として稼働・停止を繰り返した。無線 LAN ネットワーク等を停止した。
（関東地方の大学）



初回の 3 月 14 日一回、実施した。
（関東地方の大学）

2.4.3. 稼働・停止の繰り返しのための要員確保は可能でしたか。


可能でした。
（東北地方の大学）

実際にはなかったが、可能であった。（東北地方の大学）可能であった（関東地方の研究所）



超勤なしには確保不能であった。要員の疲労度は大きかった。（関東地方の研究所）



非常に厳しかったが、何とか確保した。
（関東地方の大学）

早朝からの計画停電の場合には、担当者（職員、業務委託）が早出や泊り込みを行って対応した。
（関東地方の大学）

職員の早朝出勤や、業務時間内での停止・再起動の協力を要請した。
（関東地方の大学）

2.4.4. 稼働・停止の繰り返しで障害を誘発しましたか。


磁気ディスク、RAID-CM などの故障多数。
（関東地方の研究所）



ネットワーク機器の障害が発生した。（関東地方の大学）



サーバハードウェア１台の稼働が不良となった。（関東地方の大学）

2.4.5. 計画停電対応で、困ったこと、工夫したことがあれば、記載してください。


計画停電に備えて、UPS からの停止・起動スケジュールを検討した。
（東北地方の大学）



直前まで実施有無がわからないことが困った。
（東北地方の大学）



発電機不足のため確保するのに苦労した。（東北地方の大学）



実際にはなかったが、あった場合には、発電機もないので大変と思われる。（東北地方の大学）

計画停電に対応するため、発電機の借用を行った。
（東北地方の大学）

９月初旬まで発電機のレンタルを行い，計画停電や余震等による停電に備えた。
（東北地方の大学）



災害復旧工事のため、停電が何回かあり、その間にもサービスを停止しないために発電機を使ったが、リース機が払底しており確保が非常に大変だった。（関東地方の研究所）



要員確保に費用が発生。計画停電は実際には実施されなかった（毎回対象からはずれた）（関東地方の研究所）



日々時間帯がずれていくので要員の確保が困難。実際に停電するかしないか直前までわからないので困る。従前よりキャンパス間ネットワークノードとサーバ（クラウド）を設置して無停電運用を行っているが、今回はそれを十二分に活用した。
（関東地方の研究所）

早朝からの停電は対応に困る。4 月以降も行われていたら授業に支障がでた。（関東地
方の大学）



停電になるのかならないのかハッキリしなかったこと。（関東地方の大学）



当初、計画停電の対象区域の情報入手が困難であった。サーバの停止・復旧作業を伴うため、停電時間帯の前後を含め、各種サービスの利用ができない事態が発生した。
（関
東地方の大学）

早朝及び深夜対応が必要であった。個々のシステムの稼働スケジュールで、担当部署との調整を行うことが困難ではあった。
（関東地方の大学）

仮想化環境を使用しているが、手動によるシステム停止・開始手順が複雑で、ベンダーSE の支援が必要であった。
（関東地方の大学）

3. 今後の対応
3.1.

災害時への対応体制として、最優先に改善すべき事柄は何でしょうか。



担当者同士の緊急時の連絡網の確立とシステム起動・停止の情報共有です。また、バックアップ電源の確保。
（東北地方の大学）

身の安全を確保することと、学生の安全・避難を最優先に行うことが、何よりも重要なことだと考えます。情報システムのマニュアルがしっかり作成されているので、一人でも作業が可能な体制ができている。
（東北地方の大学）

センター要員の安否確認（東北地方の大学）



連絡手段の確保。
（東北地方の大学）



BCP 対策を先に作成すべきであり、年度末までには、一部導入予定である。
（東北地方
の大学）



幸い停電にならなかったため、障害は発生しなかったが、停電になった場合の対応を考える必要がある。
（東北地方の大学）



東日本大震災からの教訓は、第一に避難と安全確保である。この点を見直しておきたい。
（東北地方の大学）



システムの状態監視、シャットダウン、復旧の手順について広くセンター職員の間に情報共有をはかり、対応手順等をマニュアル化し、各職員の緊急時対応のスキルアップを図る。一部、職員、教員による運用の独占状態を改善する。
（東北地方の大学）

電源とネットワーク接続の確保（東北地方の大学）



電源構成，システム停止手順の共有が十分でないので，ドキュメント化を進めたい。
（東北地方の大学）

対応マニュアルや手順書の整備、学生や教職員に情報を提供できるシステムを稼働させるだけの電源の確保。
（東北地方の大学）

一部の担当職員だけが電源の構成、電力使用状況などを把握している状態で、震災当日も復旧時も手探りでの対応となった。この点を整備していくことが必要であると思われる。
（関東地方の研究所）



関係資料のペーパー化。資料がオンラインに保存されていたがアクセス不能。UPS 停
電信号による自動シャットダウン。DNS の NII セカンダリサービスの利用（関東地方
の研究所）



ＢＣＰ計画の確立（関東地方の研究所）



通常運用がかろうじて行える要員しかいないので、輪番停電、計画停電、節電に対応するには人手が足りない。
（関東地方の研究所）



特に大きな問題はなかったが、サーバ等のオペレーションノウハウを複数の職員で共有しておくことは重要。（関東地方の大学）



データバックアップの確保。
（関東地方の大学）

データ保全（関東地方の大学）



サーバ室の空調を含めた代替電力の確保が必要である。（関東地方の大学）



BCP を策定すること。
（関東地方の大学）

バックアップデータの安全な保管。電源喪失時に、システムが設計通りに動作するかどうかの検証（関東地方の大学）

3.2.

災害に対応できる情報システムの基盤（電力、耐震ラック、消火設備等）で、最優先に改善すべき点は何でしょうか。



バックアップ電源の確保と稼働保証・燃料備蓄（東北地方の大学×7、関東地方の大学）



電力の可視化と発電機の予算要求。（東北地方の大学、関東地方の研究所）



サーバを外部に設置することによる冗長化等（要検討、DNS サーバについては実施済）（東北地方の大学）

ラックの耐震性の向上。
（東北地方の大学×2）



水道が止まっている間の空調設備における加湿機能について対策を検討すること。
（東
北地方の大学）

設備も含めた安全な停止手順の確立（関東地方の研究所）



要員の安全（地震自体による被害がもっと大きかったら情報システム云々どころではない）と長期間にわたって作業継続できる人員体制。（関東地方の研究所）

電源。特に非常用電源への切替の迅速化。（関東地方の大学）



電源の喪失を防ぐ予備的設備の充実が必要で、具体的な導入作業を進めている。
（関東地方の大学）



継続性が強く要求される一部のサービスを完全に独立させること。（関東地方の大学）



空調設備の耐震性の点検、問題があれば改善。特に冷却水配管関係（関東地方の大学）

3.3.

データやシステムのバックアップとして、最優先に行うべきことは何でしょうか。



データセンターの活用（東北地方の大学、関東地方の大学×2）



遠隔地へのデータバックアップ（東北地方の大学×4、関東地方の研究所×3、関東地
方の大学）



クラウドの活用（東北地方の大学）



複数個所へのデータ保存。
（東北地方の大学）

他大学や学外データセンターへのデータバックアップ。（東北地方の大学）キャンパス間バックアップ（東北地方の大学、関東地方の大学）キャンパスに分散配置されたサーバ類の仮想化によるサービスの冗長性の確保（東北地方の大学）



仮想化によるサービスの冗長性の確保（東北地方の大学）

緊急連絡システム（東北地方の大学）



保管の 2 重化（関東地方の大学）

3.4.

システムの外注化やクラウド化は、事業継続として役に立つでしょうか。不安な点は何でしょうか。



利用ケースやサービスに毎に検討が必要である。（東北地方の大学）



事業継続性（特に電子メール、ウェブサービス等のコミュニケーションサービス等）
については、外部ホスティング、クラウドサービス等を積極的に導入すべきだと考えます。不安な点は外部ホスティング、クラウドサービスへのネットワーク経路の性能や経費負担があげられる。
（東北地方の大学）



外注の場合，被災地の中だと復旧に来てくれない。携帯電話などは意外と使えたので，クラウド化は事業継続には有効と考える。（東北地方の大学）



外注化－コスト。クラウド－サービスの質とセキュリティとコスト（東北地方の大学）



役に立つと思う。
（東北地方の大学）



Web サーバ、DNS サーバのクラウド化に伴うサービスの性能と経費。（東北地方の大学）



役立つと思われるが、本学のセキュリティポリシーに準拠できるかの懸念がある。
（東北地方の大学）

データへのアクセス権とセキュリティの管理（東北地方の大学）



役立つがセキュリティ確保と情報遅延が不安。
（東北地方の大学）

役立つと思われる。SLA，個人情報の取り扱い。（東北地方の大学）



役立つとは思う。セキュリティ面が不安。（東北地方の大学）



一般論としては有効だと思う。ただし、自組織については、得失調査が必要。不安な点は、セキュリティとコスト。
（関東地方の研究所）



非常に役に立つ。外部組織に機密情報をおくことの情報セキュリティ（関東地方の研究所）

ネットワーク経路の耐障害性やシステム全体のセキュリティ。（関東地方の研究所）



既設のプライベートクラウドシステムはたいへん役にたっている。（関東地方の研究所）



個人情報、重要情報の取り扱いについて検討すべき。（関東地方の大学）

役立つと思うが、経費が問題。
（関東地方の大学）

コスト面（関東地方の大学）



事業継続の手法として有効と考えられるが、ベンダーのセキュリティや、クラウド化に移行すべき情報の切り分け等が問題となりそうである。（関東地方の大学）



外注化、クラウド化を進めることは、電気が電力会社に拠点化集中化しているのと同じ方向に進むことになるが、それが良い方向なのかどうか。（関東地方の大学）

4. その他、災害発生時の対応に関するコメント等ありましたら、 ぜひご記入ください。


災害発生時の緊急対策は、人命が優先されることから、発生時のサーバやシステムの稼働確認や停止作業は、難しいと感じました。また、地震対策として免震架台や制震ラックを導入していたことから、機器の損壊がありませんでした。そのため復旧が迅速であったと思います。（東北地方の大学）


災害時の情報システムの復旧や対応については，事前に対策や訓練は全くしておらず，全てにおいてその場で判断して対応することとなった。情報センターの教員が，企業との共同研究で地震に関連する研究を実施していたため，震災後の対応について多少知見があったことは幸いであった。簡易 Web サイトによる臨時ホームページや学外のメールサービスによる対応などは，非常に有効であった。
なにより，情報センターとして大学内に一定以上の情報システム運用の技術力を持った人材がいたことが，本学における迅速な震災対応が可能であった最も重要な要因である。大震災発生直後は，情報システムの保守業者は，他のもっと重要な社会インフラの復旧作業を優先させたり、交通の混乱などで，本学まで作業員を派遣することが難しい状況であった。そのため，業者の到着を待たずに，携帯電話などで被災地から離れた業者の担当者から情報を入手しながら，復旧作業を行える要員が学内に存在したことが，迅速な情報システムの復旧には必要不可欠であった。
（東北地方の大学）



東日本大震災でもっとも被害の大きかった地域の職員として、被害がなかった他大学の皆様に対して、是非、事前の対策、BCP の立案をしておくべきだとご助言申し上げます。
以下は、大震災があって初めて気がついたことでした。
本学では、大学が存在する地域の全停電が起きたときに備え、最低限の緊急情報発信と、安否確認ができるよう、別の地域にクラウドサーバを借りるようにしました。年
度末には、本稼働します。
また、計画停電の対象なり、それが実施されれば、停電は３時間ですが、半日すべての業務が止まります。そうならないように、高額な発電機の導入が必要で、その実現に向けて予算要求をしたいと考えています。（東北地方の大学）

学内の業務も重要ではあるが、甚大な被害が学外で出ている場合には、一般への災害対応支援を積極的に行うことも必要と考えられる。場合によっては、大学等は住民の避難場所としても有用であると考えられる。（東北地方の大学）

当センターは、建物が古いにもかかわらず平屋建てのため機器が被害をうけることがほとんどなかったのは幸いだった。しかし、ちょうど導入のために設備工事をすすめていたスパコンは、運用開始時期の３ヶ月延期やデータセンターへの一時的な避難など大きな影響をうけた。また、研究所が運用する研究用ネットワークにつながっている大学は、研究所がインターネットへの出口となっているため、地震の被害のなかった地域の大学も研究所の停電の影響を受けた。3 月 11 日に停電となり、建物によっては 2 週間近く復電しなかったところがあったため、復電後にすぐ Windows Update とアンチウィルスソフトのアップデートを全所放送で促したのは良かったと思っている。
（関東地方の研究所）



外部ネットワーク接続の二重化（地域分散）を実施。メールサーバのデザスタリカバ
リ用システムを構築中。（関東地方の研究所）



だいぶ時間が経ってからのアンケートだったので、発生時の詳細に関する記憶が薄れている。
（関東地方の研究所）BCP(事業継続計画)の策定が必要である。
学内の情報インフラを活用し、災害発生時に地域にも情報提供を行える仕組みを検討
してはどうかとの意見が情報関連委員会で現在出されている。
今回の震災の際は、震災当日に USTREAM による NHK テレビニュースの中継を教室
にてプロジェクターで投影、帰宅困難者への情報提供手段とした。（関東地方の大学）

各システムは計画停電に対応するために、システム優先度や停止手順などがラベル化されている。しかし平常時とは異なる緊急時での対応において各システムの停止等は関係する大学の業務、教育ラインへの影響が大きく、情報センターのみでは判断できない問題である。大学として、緊急時にどのよう業務や教育を実施していくのかという方針や前提が不可欠であると感じる。
情報センターの機能としても、電気や建物施設といった安全確保がなされた後に機能する部署であるため、情報センター単独ではなく大学の施設利用の観点で BCP を策定する必要がある。
実際の災害発生時においては、大学から安否確認を行うより、各個人が大学から情報を得ることができるサービスを提供し続けることが必要である。
（関東地方の大学）



夏の電力使用制限令（１５％節電）のときに、サーバ室の空調確保に苦労した。
（関東地方の大学）

東日本大震災発生時の情報管理部門の対応に関するアンケート
依頼文------------------------------------------------------------------------------------------------------------------------

2011 年 12 月吉日
SS 研情報化された組織のセキィリティマネジメント WG
担当幹事 長谷川明生
まとめ役 山守一徳

東日本大震災時の情報系センターの対応に関するアンケートのお願い
情報系センターにおかれましては、この度の東日本大震災により多大な被害に遭遇され、衷心からお見舞いを申し上げます。
サイエンティフィック・システム研究会(SS 研)のワーキング・グループである「情報化された組織のセキィリティマネジメント WG」(*1)では、ネットワークセキュリティの対策向上を目指
し、2009 年 10 月より活動をすすめています。
現在当 WG では、情報系センターの BCP（Business Contingency Plan)のあり方を検討しており、すでに中間まとめを Web にて公開しております。
東日本大震災により、皆様方のお手元には、BCP 策定に必要な貴重な体験情報が蓄積されていることと思います。
そこで、アンケートにて、皆様の体験情報を収集させていただき、それを当 WG の報告書（2012年 3 月頃完成予定）に盛り込み、Web に公開することで、BCP 策定の有用な情報を広く全国の情報系センターへ提供してまいりたいと考えております。
お忙しいところ大変恐縮ですが、アンケートにご協力いただければ幸いです。
●回答方法
添付の Excel に回答を書き込み事務局までご返信くださいますようお願いします。
●希望期日【2012 年 1 月 16 日(月)】までにご返信くださいますようお願い致します。
# WG 報告書への掲載時には、記入者のお名前は記載せず、組織名も特定できないように整理いたします。
# アンケート用紙には、ご参考として記入例を掲載しています。
(*1)WG のページ
http://www.ssken.gr.jp/MAINSITE/activity/workinggroup/info-secmng/index.html------------------------------------------------------------------------------------------------------------------------