耐災害性を強化した情報システムの在り方等に関する調査
報告書（概要版）
1
0. 調査の概要
•
本調査は、災害発生時における情報システムのディペンダビリティを確保する情報セキュリティ技術等に関する課題等 の検討を行うために実施する•
大規模災害発生時には、情報システム障害、人為的要因及びサイバー攻撃等の影響により、可用性以外の機密性、完 全性、プライバシー保護等を考慮した対応が取れないケースもあり、事業継続を困難とする情報セキュリティに関わる事 故が発生する可能性もある•
以下の項目の調査により、政府の資料作成の参考にすることを目的とする-
災害発生時における、情報システムのセキュリティを損なう事象の洗い出しと事業継続計画（BCP
）を考慮するために必 要な対策と課題の整理-
災害発生時に情報共有等を確実かつ正確に行い、合意形成を行うためのリスク・コミュニケーションの指針及び情報セ キュリティ技術開発や適切な情報セキュリティ対策を支える人材育成の状況(2)リスク・コミュニケーション及び 情報セキュリティ人材育成に関する調査 (1)災害発生時における情報システムの
影響と対策に関する調査
企 業等
ヒア リン グ調 査
(3)検討会の運営
(3)検討会の 運営
(4) 報告書とりまとめ
(b)情報セキュリティ人材 育成に関する調査
有 識者
・関 係 者等 ヒア リン グ・ 文献 調 査 (a)リスク・コミュニケーショ
ンに関する調査
(b)災害時に影響を受ける セキュリティ機能に対する
対策及び課題の整理 (a)災害発生時における情
報システムの影響と対策 についての調査 文献
調査
1. 災害発生時における情報システムの影響と対策
3
1.1. 調査方法・調査対象
No 業種 本社 従業員数 国内拠点数
1 建設業A 東京 5,001人以上 51箇所以上
2 建設業B 大阪 5,001人以上 51箇所以上
3 製造業A 東京 5,001人以上 51箇所以上
4 製造業B 東京 5,001人以上 51箇所以上
5 製造業C 東京 5,001人以上 51箇所以上
6 製造業D 東京 5,001人以上 51箇所以上
7 製造業E 東京 5,001人以上 51箇所以上
8 製造業F 東京 5,001人以上 11～50箇所
9 製造業G 東京 5,001人以上 2～5箇所
10 製造業H 東京 301～1,000人 51箇所以上
11 通信業A 東京 1,001～5,000人 51箇所以上
12 情報サービス業A 東京 5,001人以上 51箇所以上
13 情報サービス業B 東京 1,001～5,000人 11～50箇所 14 情報サービス業C 東京 1,001～5,000人 2～5箇所 15 情報サービス業D 神奈川 301～1,000人 11～50箇所
16 情報サービス業E 東京 301～1,000人 2～5箇所
17 物流業A
※神奈川 1,001～5,000人 11～50箇所
18 卸売業A 東京 51～300人 11～50箇所
19 小売業A 東京 5,001人以上 51箇所以上
20 教育・学習支援業A 東京 301～1,000人 51箇所以上
※「重要インフラの情報セキュリティ対策に係る第2次行動計画」（2009 年2月3日情報セキュリティ政策会議決定）において、流通業は大手事業者のみが重要インフ ラ事業者として定められている。ここでは、大手事業者ではないことから、NISCに確認の上、本調査の対象に含めた。
下記の調査対象
20
組織（重要インフラ事業者を除く）へのヒアリング調査とし、調査項目は災害発生時における情報システ ムの影響と対策に関する調査（25
項目）、リスク・コミュニケーションに関する調査（9
項目、3.1.1
節参照）、計34
項目とした。1.2. ヒアリング調査結果①
1.2.1. IT
システムを考慮した事業継続計画（BCP
）の有無•災害時に IT
システムを稼働継続させるための何らかの指針を持つ企業は20
社中14
社を占める- IT
システムを考慮したBCP
を持つ企業は20
社中9
社-
システムに影響があった場合の対応手順を定めたドキュメントを保有、もしくはBCPに一部ITシステムについて触 れられている企業（5社）1.2.2. 災害時の態勢、権限の考え方
• BCP
保有企業では、BCP
で定められる基準や条件に基づきBCP
が発動され、BCP
に基づいた全社的な緊急対応体制 が立ち上がっている• BCP
の発動に関する判断で悩んだ、あるいは混乱したと回答した企業はない• BCPが発動した場合、あるいはBCPはなくとも全社的な緊急対応体制が立ち上げられた場合
-
情報システム部門責任者（CIO
）は全社的な緊急対応体制に組み込まれており、情報システム部門と経営層が連 携する対応体制が構築されていた•
全社的な緊急対応体制が立ち上がらなかった場合- IT
システムを考慮したBCP
や対応手順が定められている企業では、情報システム部門で緊急対応体制を立ち上 げ、迅速な対応を行っている企業もあった1.2.3.
通常時にIT
システムに関して求められているセキュリティ要件及びプライバシー要件5
1.2. ヒアリング調査結果②
1.2.4. BCPの見直し、新規策定の予定
•東日本大震災を機に、 BCP
の新規策定または見直しを行った企業は20
社中13
社•見直しの内容は様々 :
（例） 指示命令系統を修正
セキュリティレベルの緩和をルールとして設定
1.2.5. 災害時に優先すべき業務と、関連するITシステム
•
災害時に優先すべき業務として、20
社中16
社が「安否確認」を挙げた うち安否確認システムを入れている企業は9
社•
災害時に優先すべき業務として「安否確認」を挙げた16
社のうち8
社で、携帯回線の輻輳のために安否確認作業が難 航した•
安否確認システムを入れている9社のうち、-
登録したアドレスが受け取りにくい、システムの使い方がわからない等の理由で返答率が悪い(2
社)
-
従業員数が多い企業では、何割かでも返答があれば、個別に安否確認を行う手間が省けるため、有効(2
社)
•
安否確認以外の優先業務：顧客対応、各拠点や現場から情報収集、生産業務の継続等•
顧客対応では、社内向けと顧客向けで同じIT環境を利用する場合、情報システム部門にも優先業務が課せられる•
顧客対応、各拠点や現場から情報収集では、通信手段の確保が重要1.2.6.
災害時に優先すべき業務を遂行するために必要なリソース•安否確認の遂行に必要なリソース： 作業を行うための人員及びツール（安否確認システム及び通信手段）
•顧客対応、各拠点や現場からの情報収集等に必要なリソース： 人員及び通信手段
※ 社内向け IT
と同じ環境で顧客にサービス提供している場合には、情報システム部門の人員がより必要となる。1.2. ヒアリング調査結果③
1.2.7.
東日本大震災時におけるIT
システムへの被災状況•IT
システムに影響があったのは20
社中7
社-
データセンターが本社や本社近くの首都近郊、被災地以外に設置していた企業が多い（20社中19社）-
被災地に拠点を構える企業では、拠点のPC損壊・流出、通信回線障害等、ITシステムへの影響が見られた1.2.8.
東日本大震災時におけるIT
システムのセキュリティ要件及びプライバシー要件の遵守状況• IT
システムのセキュリティ要件及びプライバシー要件について緩和措置を取ったのは20
社中10
社•
計画停電等によって出社できない社員のために、多くの企業が在宅勤務制度を一時的に設けていた-
これらの企業は、概ねリモートアクセス環境が構築済、一部拡大するだけでスムーズに対応できた- 在宅勤務の制度がない企業では、在宅勤務を一時的に認めるという柔軟な対応を実施
1.2.9. 東日本大震災時におけるITシステムのサイバー攻撃の可能性
•
今回調査対象とした企業の全てが、「東日本大震災に関連したサイバー攻撃を受けていない」と回答-
サイバー攻撃に気づいていない可能性も否定できない•
インターネットサービスを提供する情報サービス業は「震災に限らず常にサイバー攻撃に晒されている」東日本大震災の経験から、 システムに求める改善点
7
1.3. ヒアリング調査結果から得られる要点①
1.3.1.
東日本震災における情報システムへの影響と情報システム利用・運用時の留意点＜調査対象企業における情報システムの特徴＞
＜東日本大震災における情報システムへの影響と業務へ与えた影響の特徴＞
＜調査対象企業における業務とITの特性＞
•
本社が関東近郊にある企業が多く、主要なデータセンターは被災地から離れている•
全国的に拠点が分散している場合、情報システムや情報も集約されておらず、自社でデータセンターやサーバを 運用している場合が多い•
社内外ともデータセンターが被災地に位置しないケースが多かったことから、情報システムへの影響があった企業 は尐なかった•
製造業における工場等、業務において重要な役割を果たす拠点とそれを支える情報システムが被災地に存在す る場合や、重要なデータセンターや拠点が計画停電エリアに含まれた場合は、業務に対する影響があった•
停電（計画停電を含む）や通信遮断・遅延の影響が大きかった。特に、計画停電では、自家発電の容量不足、頻繁 なサーバの立ち上げ/
立ち下げ等の発生により、業務に影響があった•
業務そのものが情報システムに直結しない場合、一部を除き、社内において復旧優先度の高いシステムは、社内 外の情報共有システム（メール、グループウェア等）である場合が多い•
情報システムの機密性・完全性も重要視しているが、顧客サービスの向上やコストとの兼ね合いにおいて、情報 システムの可用性やシステム機能の充実を優先することが多い1.3. ヒアリング調査結果から得られる要点②
1.3.1.1.
情報システムに影響がなかった事例データ センター
•
自社あるいは社外でも震災の影響がない場所にデータセンターを設置 していた•
震災後、バックアップを目的としたディザスタリカバリセンターを、本社 の東京から離した関西に設置したシステム
•
高い可用性を要求されるインターネットサービスを行う情報サービス業 においては、元々障害が起こらない限り人手による作業が必要ないシ ステムを構築していたその他
•
東日本大震災前日の地震の時、関係者に「冷静に対応するように」と の注意喚起を行っていた•
火災や津波等による紙書類の紛失に備えて、紙書類の取り扱い手順と 保護対策（パスワード保存、自動バックアップ、不要時の廃棄）の見直 しを行った•
広域災害を念頭に置い た、地理的要素を加味し たデータセンターの集約•
バックアップの実施方法•
システムに関する人手 をかけない工夫•
注意喚起•
事前準備9
1.3. ヒアリング調査結果から得られる要点③
自家発電 装置
•
メールやネットワークが停電によって利用不可となった企業では、メー ルサーバ、ネットワークサーバの自家発電装置を導入したり、燃料の保 持のために深夜は自家発電装置を停止しながら運用した1.3.1.2. 情報システムの一部に影響があった事例
•
情報システムの優先稼 働順位、縮退運転の方 針データ移 行
•
停電によって、企業の基幹サーバが利用不可となった事例では、移行 途中のサーバの空きがあったため、データを急遽移して対応した。非常 に大規模な企業で、システムを一度に移行することが難しく、常に新し い環境と古い環境が混在する状況でシステム運用が行われていた 停止・再起動
•
複数の企業が計画停電に合わせ、機器の停止・再起動を複数回実施•
大規模システムが対象となった時は、社外から応援の人員を調達した•
データを切り戻す際に、データが欠落し、復元に数ヶ月を要した•
基幹システム向けに自家発電装置を導入したが、複数回の計画停電 には対応できず、停止・再起動を実施せざるを得なかった•
計画停電によって、拠点のPC
が壊れ、データを消失したために、情報 の一元管理とバックアップの実施を行った通信
•
被災地との連絡に支障が出た。携帯電話、テレビ会議、社内メッセンジャー、
Skype
等、複数の通信手段を用いて対応した•
製造業等では、テレビ会議システムを活用していた事例が多かった•
インターネット関連の情報サービス業では、Yammer
1、•
東日本大震災時にSkype
を一時的に導入、後日社内ルールを変更して 通常も利用可能とした•
新旧の環境をうまく活用 することで、対応するこ とも可能•
計画停電対応は、自家 発電装置の導入や、データの集約・バック アップの方法とともに検 討する
•
複数の連絡手段を日頃 から準備しておくことが 有効•
有効な連絡手段は平時 から利用可能とすること で、災害時も円滑に使え る1 企業向けに提供されるソーシャルネットワーキングサービス（SNS）の一種。情報共有ツールとして利用される。
1.3. ヒアリング調査結果から得られる要点④
データの 喪失
•
被災地の社内データセンターの火災のため、顧客情報を全消失した。紙は打ち出さない方針でほとんど残っておらず、また、バックアップは 同じ建物に保存していたため、役に立たなかった。震災後、顧客情報を 外部事業者のクラウド環境（海外のデータセンター）に一元化することと した
基幹シス テムの停 止
•
社内データセンターが計画停電地域にあり、基幹システムが計画停電 中全停止した。計画停電中から長期に渡ることを想定し、段階的に外 部データセンターへ移行し、計画停電後も外部データセンターの利用を 継続。グループウェアも、稼働継続を確保するためクラウドへ移行した•
製造業の業務継続においては、社内インフラとしての情報共有システ ム（メール、グループウェア等）が稼働することが重要1.3.1.3. 情報システムの全てに影響があった事例
•
外部事業者のクラウド環 境の利用を検討する場 合、クラウドのリスクを考 慮し、データの保管場所 や形態、バックアップ条 件、SLA
等を確認し判断 することが望ましい•
東日本大震災では東京 での支援が可能であっ たが、首都直下地震は 近隣に支援体制が望め ない場合も考えられる メールシステム
•
ルータが計画停電の対象エリアにあり、停電中メールが使えなかった•
震災の見直しで、メールシステムの一箇所が壊れると全て使用不可に なる構成であることが判明し、一括で外部委託することにした•
外部委託も選択肢の1
つ、社内情報が社外に出て しまう点は要検討
1.3.1.2.
情報システムの一部に影響があった事例（続き）11
1.3. ヒアリング調査結果から得られる要点⑤
1.3.2.
東日本震災における情報システムのセキュリティ機能への影響情報シス テムや情 報へのア クセス制 限の緩和
•
情報システム部門長の承認において情報システムや情報へのアクセス 制限を緩和・解除するという対応がなされており、やむをえない状況下 において、迅速に決定・実施されている•
顧客情報へのアクセスについて、システム権限の変更権限が自社には なく、グループ会社にあり、円滑な対応をできなかったことから、ID
とパ スワードを共有し、運用をルーズにすることで対応した在宅勤務 の導入・
対象者の 拡大
•
リモートアクセス環境や在宅勤務の制度が整っている企業では、在宅 勤務の拡大が経営層で決定後、その対象者を情報システム部門にお いて拡大するという対応が、スムーズに実施されている入退室管 理の緩和
•
震災時の一時的な停電と想定される場合は、現場の判断で緩和を行っ ていたが、計画停電で入退室管理の緩和が長期に渡る場合は、業務 継続を優先し、情報システム部門長の判断で紙をベースとした入退室 チェックに変更していた•
災害時、情報システム や情報に対するアクセ ス権限を緩和する場合 は、その意思決定を情 報システム部門長とす ること、アクセス権限を 変更する手続きを簡易 にしておく•
システムやルール上の 整備がなされていると、セキュリティ要件の緩和 と戻しについても円滑な 運用が可能
•
セキュリティ要件の緩和 の際には、影響範囲が 限定される部分のみとし、影響が大きい場合は、
経営層の判断を仰ぐ仕 組みを構築しておく
•
平時の運用に戻すタイミ ングと方法についても予 め決定しておく全体
•
業務遂行上やむを得なく、一時的な対応である見通しが立っており、セ キュリティ要件変更の影響範囲も小さいことから、情報システム部門長 の判断でスムーズに承認・実施がなされている•
多くは、平時の運用に戻されているが、一部は緩和された環境が継続 している場合もある1.3. ヒアリング調査結果から得られる要点⑥
1.3.3.
災害発生時における情報システムの扱いにおける事業継続計画の検討項目1.3.3.1. 災害時の情報システムの稼働継続に向けた対応について
東日本大震災の一連の事象を通じて、情報システムの稼働維持に大きな影響を与えたのは、被災によるデータの喪 失やシステムの破壊、ネットワークの途絶といった情報資産の被害と、計画停電であった。
情報資産 の被害
•
被災によるデータの喪失やシステムの破壊、ネットワークの途絶により、可用性や完全性の維持が困難になる
•
特に、被災地区のデータの喪失は、再現不可能なケースもある•
バックアップの確保•
クラウドを活用したデー タ管理の一元化•
単一障害点となる箇所 について多重化を図る 計画停電•
煩雑なサーバ・PC
の停止・起動を避ける•
拠点単位の対処によりトラブルが発生する•
停電の影響で、データ集約時にドロップが発生する•
データセンターの活用•
機材の死活をリモートで 管理できるような仕組み•
バッチ処理のタイミング の調整、解決できない 場合が課題13
1.3. ヒアリング調査結果から得られる要点⑦
1.3.3.2.
災害時に特別に必要となる情報システムの稼働継続に向けた対応災害時には、平時から利用している情報システムに加え、特別な業務が発生することで、新たに稼働が必要な情報シ ステムが存在する場合がある。
安否確認 システム
•
多くの企業において、災害時に発生する最重要業務 として、安否確認を挙げていた。安否確認システムを 導入している企業も多かったが、適切に稼働しない ケースも見られた＜適切に稼働しなかった理由＞
-
携帯メールが届きにくく、届いたのか届いていな いのか、返信の有無がわからなかった-
（無事であっても）返答がない社員がいた•
安否確認システムは、携帯メールの円滑な送受信を 前提としたものもあるが、広範囲の災害の場合、長期 的に輻輳状態が続くこともありうる<
構築・利用の留意点>
•
携帯網の輻輳前にシステムからの安否 確認メールを送信できる•
返信は、端末を問わず入力可能•
事象と返信の対応関係がわかりやすい<運用の留意点>
•
訓練を実施し、災害時の返答を徹底する•
確実に連絡の取れる連絡先を登録する•
携帯電話がつながらなくても、連絡が取 れる体制を構築する災害時に 発生する 業務にお けるシス テム
•
被災地の現場の状況把握するための「被災状況把握 システム」や、災害時指揮支援のための「発動基準対 応システム」を立ち上げた•
耐震設計のデータセンターや二重化された場所に設 置されており、今回の震災では稼働したが、いざとい う時に稼働しない、使い方がわからない等の問題も指 摘されている<
技術的対応>
•
平時から利用するシステムの延長として 災害時のシステムを構築•
定期的な稼働を確認<組織的対応>
•
定期的な訓練を実施1.3. ヒアリング調査結果から得られる要点⑧
災害時に 発生する 特別な業 務に対す るシステ ム改修
•
災害時に直接システムに影響はないものの、業務が 影響を受けることで、システムに改修が発生する場合 がある<
技術的対応>
•
システム改修が速やかに実施できる仕様<組織的対応>
•
情報システムの内容を理解し、改修でき る担当者の設置•
ベンダとのコミュニケーションの円滑化1.3.3.2.
災害時に特別に必要となる情報システムの稼働継続に向けた対応（続き）2. 災害時に影響を受けるセキュリティ機能に関する対策と課題
分野 課題 概要 2.2.1.
情報システムの可 用性・完全性の維 持
(1) バックアップ の確保 情報システムの可用性・完全性を維持する上で顕著な課題として、バックアップの問 題が挙げられる。具体的には、発災時にデータを喪失したトラブルが見られる。
(2) 単一障害点の排除 情報システムやネットワークの可用性維持のために、システムやネットワークの構成 上の単一障害点を可能な限り排除する必要がある。
2.2.2.
災害時の認証の在 り方
(1) リモートアクセス、在 宅勤務
災害時の対応として、業務継続のため、リモートアクセスや在宅勤務を認めることを 想定する必要がある。
(2) アクセス権管理 緊急事態においては、事業継続のため、一部の担当者のみに割りつけていたアクセ ス権を他の人に広げることを考慮する必要がある。
2.2.3.
情報システムの利 用環境の考慮
(1) 入退室管理 緊急事態においては、停電の影響等で、サーバルーム等の自動的な入退室管理が 困難になることを想定する必要がある。
(2) 代替手段の確保 情報システムやネットワークが利用できない場合、業務継続のため、印刷物や手作 業（ PC による手入力を含む）により業務を代替することを考慮する必要がある。
2.2.4.
災害時の個人情報 管理
(1) 災害時の個人情報の 保護と活用のバランス
災害時には、安否確認や被災者保護の観点から、個人情報の利活用を優先する状 況が起こりうる。
2.1. 災害時に影響を受けるセキュリティ機能に関する課題①
東日本大震災の実事例や一般的な災害時のセキュリティ機能の問題等を基に、
BCP
、情報システムのそれぞれの観 点から、災害時に影響を受けるセキュリティ機能に関する課題を挙げる。(1) BCP
に関する課題17
分野 課題 概要
2.3.1.
回復力の高い情報 システム、ネット ワーク構成
(1) 円滑なデータバック アップを前提にした情報 システム
災害時にデータを喪失する事態をいかに回避するかという課題は重要である。しかし、
平時にデータのバックアップを取得する作業は、現場に大きな負荷を課すことや、コ ストの増大につながることから、本来あるべき頻度や形態では対応できていない状況 も考えられる。
(2) ネットワークの複数経 路の確保
災害時には、情報システムの死活確認を迅速に行う必要があるが、LAN/WANや外 部ネットワークの状況によってはそうした確認も困難である可能性がある。また、停電 等により一部の経路の断絶が全体に影響を及ぼすことも起きている。
(3) 非常時の運用負荷の 抑制
計画停電の影響により、様々な企業で機器のシャットダウンと再起動を繰り返す事態 に陥った。また、可用性を高めることで、運用すべきシステムやネットワークは多様化 し、運用に係る負荷は増大する。
2.3.2.
セキュリティポリ シーの緩和を想定 したシステム機能
(1) ユーザ負荷の尐ない 認証方式
災害時のアクセス権限の管理では、正当なアクセス権を有するユーザであることを認 証する方法が課題となる。ただし、緊急事態により正規の手続きが行えない場合に、
アクセス権限の拡大等も想定する必要がある。
(2) 私用端末の活用 災害の影響で在宅勤務を適用する場合、セキュリティの観点から見れば、業務用に
用途を限定し、安全性を高めた社用 PC 等が利用できない場合、私用 PC 等の活用も 想定する必要がある。
(3) 情報システムと代替 手段の整合
災害により情報システムが失われた状況で、事業を継続するため、紙による手作業 で代替することも考えられる。その場合、情報システムを復旧する前に紙に記載した 情報を電子化しなければならない。また、得られた発災後のデータと発災前のデータ を統合する作業も慎重に行う必要がある。
2.1. 災害時に影響を受けるセキュリティ機能に関する課題②
(2)
情報システムに関する課題2.2. BCPに関する課題と対策①
2.2.1.
情報システムの可用性・完全性の維持(1)
バックアップの確保情報システムの可用性・完全性を維持する上で顕著な課題として、バックアップの問題が挙げられる。具体的には、
発災時にデータを喪失したトラブルが見られる。
•重要データのバックアップが確保されておらず、大きなトラブルを招いたケースが見られた
•管理の容易さから同じ拠点内でバックアップを保管するケースや、遠隔地保管しているがバックアップを取る頻度が
十分でないケースも問題になる課 題
対 策
•
適切なバックアップの確保は、災害を前提にしたIT
システムの可用性や完全性の観点から不可欠な対応である•
機密性の観点から、バックアップデータに関するアクセス権はオリジナルデータの機密性に準じる必要があるが、非 常時における運用も考慮する必要がある。例えば、非常時専用の共用ID
・パスワードを事前に用意しておき、平時 は厳重に管理しておくなど、平時と非常時の適切な使い分けを可能にする運用が想定される19
2.2. BCPに関する課題と対策②
2.2.1.
情報システムの可用性・完全性の維持(2)
単一障害点の排除情報システムやネットワークの可用性維持のために、システムやネットワークの構成上の単一障害点を可能な限り排 除する必要がある。
課 題
•
発災時の情報システムの可用性を検討する上で、単一障害点となりうる箇所を検出し、二重化等の対策を適用する ことは重要である。ただし、そうした対策はコスト増につながる可能性もあり、全ての単一障害点を排除できるとは限 らない•
サーバのみに着目した結果、発災時にクライアントPCやオフィスLANのルータの電源を喪失し、システム全体が使 えなくなる可能性にも考慮する必要がある•
災害時に代替用のIT
環境を調達する場合には、サーバの代替機だけでなく、クライアント機器やルータ、さらにそれ らの電源についても考慮する必要がある対 策
2.2. BCPに関する課題と対策③
2.2.2.
災害時の認証の在り方(1)
リモートアクセス、在宅勤務災害時の対応として、業務継続のため、リモートアクセスや在宅勤務を認めることを想定する必要がある。
課 題
対 策
•
災害時には、可用性を優先し、機密性を低下させることも検討する必要がある•
平時からリモートアクセスを運用していない組織では、災害時にリモートアクセスを許容することにより、新たなリス クが発生する点を十分考慮すること、また、災害時対応の完了に伴い、リモートアクセスの運用を終了して通常の状 態に戻すタイミングについて検討することが重要である•
平時からリモートアクセスを運用されている組織では、災害時にリモートアクセスの利用者が急増する可能性を考 慮し、処理能力の許容量について検討することが望まれる21
2.2. BCPに関する課題と対策④
2.2.2.
災害時の認証の在り方(2)
アクセス権管理緊急事態においては、事業継続のため、一部の担当者のみに割りつけていたアクセス権を他の人に広げることを考 慮する必要がある。
課 題
対 策
•
データやアプリケーションへのアクセス範囲の拡大は、無制限に行われるべきものではなく、一定の条件に合致した 範囲のユーザを対象に、データ・アプリケーションへのアクセスをコントロールするべきである。つまり、アクセス権管 理は、管理者のニーズに合わせて、詳細かつ柔軟に調整可能であることが望ましい•
災害時には迅速に変更できること、平時に復帰する際には一時的に拡大したアクセス範囲を戻し、共用化したパス ワードは変更することも求められる2.2. BCPに関する課題と対策⑤
2.2.3.
情報システムの利用環境の考慮(1)
入退室管理 課 題対 策
緊急事態においては、停電の影響等で、サーバルーム等の自動的な入退室管理が困難になることを想定する必要 がある。
•
停電時には、サーバルーム等入退室管理を行う部屋は、安全性を考慮し原則として開放される構造であることから、入退室管理の手段として、予め施錠可能な部屋を活用する、停電時には警備員を配置するなどの物理的な安全管 理策で対応する方法が考えられる
•
災害時に入退室の記録を取る等の対応は完全ではないが、一定のリスクを低減する効果が期待できる•
顔写真を撮影してインスタントのIDカードを発行する手段を確保することにより、代替する方法も考えられる23
2.2. BCPに関する課題と対策⑥
2.2.3.
情報システムの利用環境の考慮(2)
代替手段の確保 課 題対 策
情報システムやネットワークが利用できない場合、業務継続のため、印刷物や手作業（
PC
による手入力を含む）によ り業務を代替することを考慮する必要がある。•
情報システムやネットワークが利用できないことを前提として、代替手段で業務を行う場合の条件や許容停止時間、さらにデータの整合性確保に関する方策等について検討すべきである
•
例えば災害から復旧した後に、手書き等の記録からデータを円滑に入力する方法等を検討することが望ましい2.2. BCPに関する課題と対策⑦
2.2.4.
災害時の個人情報管理(1)
災害時の個人情報の保護と活用のバランス 課 題対 策
災害時には、安否確認や被災者保護の観点から、個人情報の利活用を優先する状況が起こりうる。
災害時における個人情報の保護と利活用の最適なバランスについて十分に検討する必要がある。
•
一般財団法人日本情報経済社会推進協会(JIPDEC)
では、JIS Q 15001
2において「本人の同意がなくても例外事項（人の生命、身体または財産の保護のために必要がある場合であって、本人の同意を得ることが困難である時）に 該当する場合は、本人の個人情報を提供できる」と規定されている点を踏まえ、震災で負傷した社員の個人情報を 提供するケースや行方不明の社員の安否確認のため通信会社の「災害・消息情報サービス」サイトに掲載する ケースの妥当性について、示している
•
通信会社の「災害・消息情報サービス」サイトに掲載する場合には、不特定多数が閲覧可能である点を考慮し掲載 内容を決めることが望ましい25
2.2. BCPに関する課題と対策⑧
2.2.4.
災害時の個人情報管理(2)
在宅勤務と個人情報保護 課 題対 策
プライバシーマーク制度の観点からは、在宅勤務の場合もオフィスで作業するのと同様のリスク対策が必要であると 指摘されている3。従って、災害時に在宅勤務で個人情報を扱う可能性がある場合には適切な安全管理措置が求め られる。
•
通常、在宅勤務を許容していない場合であっても、災害時を想定し、在宅勤務を実施した場合のセキュリティポリ シーの扱いについて考慮すべきである•
在宅勤務のIT
環境について、ウイルス対策、ユーザーアカウントの設定、外部記録媒体の取り扱い、暗号化、シン クライアント化などの対策を事前に検討しておくことが望まれる3 http://privacymark.jp/privacy_mark/faq/disaster.html
2.3. 情報システムに関する課題と対策①
2.3.1.
回復力の高い情報システム、ネットワーク構成(1)
円滑なデータバックアップを前提にした情報システム 課 題対 策
災害時にデータを喪失する事態をいかに回避するかという課題は重要である。しかし、平時にデータのバックアップを 取得する作業は、現場に大きな負荷を課すことや、コストの増大につながることから、本来あるべき頻度や形態では 対応できていない状況も考えられる。
•
大きなコストをかけずに、データのバックアップ処理を合理的・効率的に実施できる、新しい情報システムの構成を 検討する•
バックアップデータを活用する際にも、トラブルの発生可能性を抑え、円滑に切り替えられる仕組みが求められる。そのためには、業務プロセスとの整合、正確なバックアップや切り替え処理の自動化などを検討する必要がある
27
2.3. 情報システムに関する課題と対策②
2.3.1.
回復力の高い情報システム、ネットワーク構成(2)
ネットワークの複数経路の確保 課 題対 策
災害時には、情報システムの死活確認を迅速に行う必要があるが、
LAN/WAN
や外部ネットワークの状況によっては そうした確認も困難である可能性がある。また、停電等により一部の経路の断絶が全体に影響を及ぼすことも起きて いる。•
ネットワークを多経路化し、回線の死活状況に応じて柔軟に接続を維持できるように、ネットワーク構成を設計する•
ルータやDNSを高信頼かつ合理的に配置する•
複数の通信事業者を活用する場合に、結節点が単一障害点とならないよう、構成に配慮することが望まれる2.3. 情報システムに関する課題と対策③
2.3.1.
回復力の高い情報システム、ネットワーク構成(3)
非常時の運用負荷の抑制 課 題対 策
計画停電の影響により、様々な企業で機器のシャットダウンと再起動を繰り返す事態に陥った。また、可用性を高め ることで、運用すべきシステムやネットワークは多様化し、運用に係る負荷は増大する。
•
計画停電への対応として、データセンターに預ける方策もあるが、コスト面の考慮から、例えば、仮想化OS
等を利用 してシャットダウンをせずにフリーズしたまま再起動することで効率化を図り、運用負荷を軽減する方向も考えられる•
社内インフラの設計をアウトソーシングしやすい構成にして災害時等の負荷の状況に応じてアウトソーシングを一時 的に活用するなど、柔軟なモデルを実現できる技術が求められる29
2.3. 情報システムに関する課題と対策④
2.3.2.
セキュリティポリシーの緩和を想定したシステム機能(1)
ユーザ負荷の尐ない認証方式 課 題対 策
災害時のアクセス権限の管理では、正当なアクセス権を有するユーザであることを認証する方法が課題となる。ただ し、緊急事態により正規の手続きが行えない場合に、アクセス権限の拡大等も想定する必要がある。
•
災害時とはいえ、機密性のレベルをやみくもに緩和することは適切ではない。必要に応じてアクセス権の設定を柔 軟に変更することが可能で、ユーザに負担を強いることなく認証することができる方式が求められる•
例えば、製造業Cの事例（USBメモリによる認証方式）のように、アクセス権限を一元的に管理しつつ、認証子の再 発行等にも柔軟に対応できる仕組みが有用である2.3. 情報システムに関する課題と対策⑤
2.3.2.
セキュリティポリシーの過度な緩和の回避(2)
私用端末の活用 課 題対 策
災害の影響で在宅勤務を適用する場合、セキュリティの観点から見れば、業務用に用途を限定し、安全性を高めた 社用
PC
等が利用できない場合、私用PC
等の活用も想定する必要がある。•
シンクライアント技術を活用するなどして、従業員の個人所有の機器をクライアント端末として使用し、安全な在宅 勤務を実現する方向が考えられる31
2.3. 情報システムに関する課題と対策⑥
2.3.2.
セキュリティポリシーの緩和を想定したシステム機能(3)
情報システムと代替手段の整合 課 題対 策
災害により情報システムが失われた状況で、事業を継続するため、紙による手作業で代替することも考えられる。そ の場合、情報システムを復旧する前に紙に記載した情報を電子化しなければならない。また、得られた発災後のデー タと発災前のデータを正確に統合する作業も慎重に行う必要がある。
•
情報システムが使えない場合の代替手段として紙等による手作業を検討する場合、以下の取り組みが求められる-
手書きの情報を効率良く電子化するための工夫-
正確な電子化-
発災前のバックアップデータ、発災前のバックアップから発災までの処理情報（ログ等）、発災後の処理分を適 切に統合する仕組み3. リスク・コミュニケーションに関する調査
3.1. リスク・コミュニケーションの定義
33
•
リスク・コミュニケーションについては、ISO 31000:2009 "Risk management - Principles and guidelines
（リスクマネジメン ト－原則及び指針）"
に規定されている。基本的な考え方は、『リスクに関係のあるステークホルダーへの情報伝達・交 換など情報の共有化を図り、必要に応じて専門家からの助言を受けるなど都度実施する 』※ことにより解決策を模索 するというものである。例えばBCPやセキュリティポリシーを規定する際の部門間や社外ステークホルダーとの調整プ ロセスなどを想定している•
リスク・コミュニケーションを意識して実施している人・組織は現実には多くないことが想定されるため、災害時に行った リスク情報の共有（クライシス・コミュニケーション）についても含めて調査対象とした•
リスクに対する認識をどう情報共有すべきだったのかという観点で、災害時に伝えられないが事前に伝えておくべきこ と、などの整理をした。これは、今後セキュリティポリシーやBCP
が策定・更新される際に、現実の災害を経験した結果 どのような議論をしていくことになるかに対する調査であり、今後企業等で行われるリスク・コミュニケーションの実態を 把握する上で有用と考えられるリスクコミュニケーションについての一般的な考え方
本調査におけるリスク・コミュニケーションの扱い
※( 出典: ISO NETWORK, JQA, 2011,
http://www.jqa.jp/service_list/management/iso_info/iso_network/vol22/pdf/ISO_NETWORK_22_all.pdf )
3.2. リスク・コミュニケーションに関する調査結果① - 参加すべき役割等
•
固定電話、携帯電話（通話・メール）、PHS
、FAX
、社内イントラ（メッセージ、掲示板、社内SNS
）、及び直接面談•
定常的に利用している場合- TV
会議システム、音声会議システム、Skype
等•
物理的破壊（サーバ、データセンター、社屋）、通信遮断、停電、物流遮断-
計画停電については、東日本大震災を経験するまで、想定していない場合が多い•
要員の確保-
顧客先に常駐してシステムの運用にあたる社員を派遣する企業が、派遣する人員を確保できなくなる場合-
高速道路無料化など、制度変更への対応により、開発の人員を確保できなくなる場合•
社内： 経営層、情シスユーザ、社員•
社外： お客様、IT
ベンダ・情シス子会社、調達関係の業者、官公庁・公的機関、マスコミ、警察・消防•
その他-
緊急時指揮支援システムに発災時のコミュニケーション先まで含めている例や、IT
ベンダ・キャリアベンダ・電気 設備業者とインフラ周りに必要な会社に器具を設置し、有事の際にはそれを使ってもらうという取り組みをしてい る事例もあった災害発生時に想定される
IT
システムに関わるリスク災害発生時に行う（主に情報システムに関わる）リスク・コミュニケーションに参加すべき役割
災害発生時に想定している連絡手段
35
3.2. リスク・コミュニケーションに関する調査結果② - 共有方法
•
社員の安否確認は、発災直後から安否確認システム（個人の携帯電話、固定電話等）を利用し、それでも把握できな い場合については、人海戦術で携帯電話、固定電話にかけ続けるという傾向があった•
被災地の関連施設の被害状況確認は、発災直後に電話での確認ができなかったために、現地に人を派遣したという 回答があった•
災害対策本部を設置した事例では、発災直後から、テレビ会議や携帯電話を用いて被災地との情報共有を実施して いた。TV会議が設定されていない営業所には、TV会議の内容をストリーミング形式にして情報を流して共有する態勢 を取ったという事例もあった•
社員のレベルでの情報共有については、外部Web
に社員専用の口を作って情報共有ができる仕組みを構築した事例 や、社内SNSを用いて、被災地での効率的な移動方法、電源、出張者スペース等の情報交換をしたという事例があっ た•
発災直後からから復旧段階に入るころには、計画停電への対応のため、拠点のサーバ電源入/
切の連絡をFAX
で実 施するという事例があった。計画停電の期間は、全社のBBS
を使って、停電の1
時間前には告知するようにしていたと いう事例もあった•
福島原発に、安否を確認して資材を入れるという業務を請け負った事例では、仕入れ先が例えば福島の場合、工場 の稼働、他の工場との移動距離、原発との距離、などを確認の上、積み荷を東京電力に渡したという回答があった 東日本大震災時の（主に情報システムに関わる）リスク情報の共有方法3.2. リスク・コミュニケーションに関する調査結果③ - 発生した問題点
東日本大震災におけるリスク・コミュニケーション上発生した問題点 安否確認
•
電話がつながらないので人を派遣した• 15%
の社員の安否を会社からは確認できなかった•
連絡先が古く情報の更新に手間取った情報共有
•
時系列で整理した情報を共有できない-
情報収集の際に、複数の経路から現場に異なるタイミングで照会をしたため、情報が錯綜 した-
発生事象と安否情報の対応が不明瞭になった結果、情報の整理が付けられなくなった•
管理者層にとって必要な情報を抽出しづらい-
情報システム部門としては情報を共有できていたが、災害対策本部などの管理者層から、情報共有環境に対する要望が出た
•
普段利用している情報共有方式が局所的だった-
得意先からの情報収集ツールが地区毎に異なったために集約に苦慮した-
サプライヤーの支援に行った社員との情報共有が、ネットワーク環境の違いで苦慮した37
3.2. リスク・コミュニケーションに関する調査結果④ - 平時からの取り組み
災害発生時に円滑なリスク・コミュニケーションを実施するために平時から実施している取り組み
訓練
•
システム関係の訓練-
データ復旧（遠隔地のデータセンターからのバックアップ復旧）-
緊急対応としての仮想環境の活用（あるサービスが停止した際、別のサービスと同じハー ドウェアに配備）-
リモートアクセス（社員の遠隔勤務）-
安否確認（社員や家族も含める）-
システムのリスタート訓練（ディザスタリカバリの位置付けで訓練）•
避難等を伴う防災訓練-
顧客との防災訓練-
社内の指揮系統の確認を含めた防災訓練システム 強化
•
全ての支店・営業所に衛星携帯や自家発電装置を用意し、必要な情報システム環境を構築できる ようにしている•
平時からリスク対策本部がテロ情報やタイの水害情報など、あらゆる災害に対して情報集約を実施 している•
災害時の情報共有システムを導入。災害時に情報が一覧表示されるSNS
のような仕様の 携帯アプリを開発したリスク・コ ミュニ ケーショ ン
•
発災時に最低限必要な要員の数をお客様に聞いている（要員をお客様の環境に派遣する業務）•
事業部に対して、災害時は情報システムが止まることが前提として、最低限継続すべき業務を定め てもらっている（情報システム部から事業部への依頼）• ベンダとはBCPを作成する過程で、災害時にマシンを調達する手順も確認している
3.3. 災害に関するリスク・コミュニケーションの在り方(まとめ)
•
情報システム部門が、災害発生時にリスク・コミュニケーションを行う対象の役割としては、経営層、IT
ベンダ、情報シ ステムのユーザ（現業部門、顧客）、所管省庁、マスコミ等(
下線部は特に重要な役割）- ITベンダを活用している企業では、平時からITベンダとのコミュニケーションを図ることで、災害発生時のシステ
ム改修に関して円滑な対応ができていた
-
情報システムのユーザとは、災害発生時、業務継続の観点から頻繁なやり取りを行いながら、対応を行っていく 必要がある。しかし、その前提として、平時からのコミュニケーションを行い、BCP
に関して連動して対応できるこ とが円滑な災害対応に結び付いている•
特に、情報システムのユーザとは、平時から災害発生時に優先される業務とIT
の関係から、IT
サービスに関して求め られる品質について合意を図り、災害発生時においても、優先順位に応じた、復旧作業を行うことが、ユーザにとって 業務継続を行う上で最も重要である•
平時からの取り組みとして、訓練、システム強化、リスク・コミュニケーションを行うことで、災害発生時の情報システム の稼働継続に係る円滑な対応が可能になる•
リスク・コミュニケーションをきちんとできないことのリスクについても認識する必要がある-
「東日本大震災の際にはBCPが非現実的だった」、「BCP策定当時の担当者からの引き継ぎが不十分だった」、リスク・コミュニケーションに参加すべき役割
合意形成のために共有・伝達すべき情報
その他留意事項
4. 情報セキュリティ人材育成に関する調査
4.1. 災害時に情報セキュリティ対策を担う人材像
•
組織的な対応・判断ができる人材•
社外の情報セキュリティ担当者と橋渡しができる人材•
リスクを想定できる人材•
システムの全体的な情報を持つ人材•
可用性・機密性・完全性のバランス感覚のある人材•
技術力、コミュニケーション力のある人材•
多くの情報システムの現場では、災害時に情報セキュリティ対策を担う人材について、情報セキュリティの技能・知識 等の面で、特別な人材は求められてはいない•
組織の業務や情報システムに関する知識を有し、災害時に業務が滞らないように動くことができる人材が求められて いる•
災害時に情報セキュリティの責任者と連絡を取れないような状況においても業務が滞らないよう、BCP
を策定・更新す ること、情報システムを見直すこと、複数の人員で情報セキュリティに取組むこと等が重要であると考えられている•
我が国の情報セキュリティ人材は全般的に不足していることから、災害発生時における情報システムのディペンダビリ ティ確保のためにも、情報セキュリティ人材の育成が必要である企業ヒアリングから想定される「災害時に情報セキュリティ対策を担う人材像」
人材育成の重要性
