【具体例】情報システム業務継続計画 - アプリケーションの障害許容時間
前回お話した機器のレベル分け以外に、情報システム事業継続計画で対象とするアプリケーションと、その障害時の許容時間および注意事項に関して定義しておく必要があります。
許容可能な遅れについては、会計期間での災害発生日によって異なる可能性があります。
【許容可能な最大停止時間】
補足事項：
局所的障害： サーバルーム、データセンター、ネットワークおよびデータ通信の喪失。
地域的障害： 震災等による地域障害と、運用および管理のための資産の喪失。
上記許容時間は、アプリケーション使用者の営業日換算としています。
このアプリケーションの区分けをきちんと行っておくと、実際に障害が発生した際に、何が組織として重要なのか、さらに、その復旧までに暫定措置として行っておくべきことを事前に想定できます。
使用者の声としては、自分が関わっているシステムの完全復旧が個別としての優先事項なのでしょうが、組織としての全体的なレベルを保ち、その復旧に資源を集中することが最も重要です。
この事業継続計画書では、それを組織横断型のドキュメントとして、明示することにより、その優先事項を利害関係者全員に知らしめる意味があります。
【具体例】情報システム業務継続計画 - 危機のレベル分け
けんぢが作成した情報システム事業継続計画では、危機のレベルを、軽危機の第1レベルから、重大危機の第4レベルまでの4段階で定義しています。
また、危機レベルを、その危機分類別に定義することにより、緊急時の行動計画における判断材料とすることができます。
これらの危機レベルについては、必ずしも4段階のすべてを対応定義に取り入れる必要はなく、障害・災害種別や、その影響範囲などの、その危機の特性から、4段階より少ない定義レベルに集約することもあります。
【PC、可搬情報媒体等の紛失、盗難】
第4レベル： PC、可搬情報媒体等が盗難に遭い、紛失した。PC、可搬情報媒体等とともに、会社および顧客の非常に重要な機密情報が紛失した。
第3レベル： PC、可搬情報媒体等が盗難に遭い、紛失した。PC、可搬情報媒体等とともに、会社および顧客の機密情報が紛失した。
第2レベル： PC、可搬情報媒体等が盗難に遭い、紛失した。
第1レベル： 未定義。
補足事項：機密情報のレベル分けも必要です。具体的には、個人情報保護や、商取引の健全性の保護の観点から、レベル分けを行うとよいでしょう。
【情報の漏洩、および紛失】
第4レベル： 情報資産機密性の重要レベル4以上のものが漏洩した。
第3レベル： 情報資産機密性の重要レベル3のものが漏洩した。
第2レベル： 情報資産機密性の重要レベル1または2のものが漏洩した。
第1レベル： 未定義。
【電源の障害】
第4レベル： 数日間にわたって復旧する見込みがない。
第3レベル： 8時間以内に復旧する見込みがない。
第2レベル： 8時間以内に復旧する見込みである。
第1レベル： 一部のみの障害である。
補足事項：上記には、建物の法定停電等の計画停電は含みません。また、「一部のみの障害」とは、電源の他からの供給や、機器類の移動で回避できる場合も含まれる。
【空調の障害（サーバルームやパッチケーブルラック周辺）】
第4レベル： 1週間以上にわたって復旧する見込みがない。
第3レベル： 4日間以上復旧する見込みがない。
第2レベル： 2～3日停止後、復旧する見込みである。
第1レベル： 24時間停止後、復旧する見込みである。
補足事項：上記には、建物の法定停電等の計画停電による空調の停止や、定期メンテナンス等による停止は含みません。
【サーバの故障、ネットワークの障害・停止】
第4レベル： 数日間にわたって復旧する見込みがない。
第3レベル： 12時間以内に復旧する見込みがない。
第2レベル： 12時間以内に復旧する見込みである。
第1レベル： 一部のみの障害である。
補足事項：上記には、建物の法定停電等の計画停電によるサーバ、およびネットワークの停止や、定期メンテナンス等による停止は含みません。
【地震や火災等の災害】
第4レベル： 震度6以上の地震、外部から放水を受けるほどの火災、防災機関から避難命令があった場合。
第3レベル： 震度5の地震、軽微なもの含む火災。
第2レベル： 震度4の地震。
第1レベル： 震度1～3の地震。
補足事項：上記レベルの選定には、公的な第三者が、そのレベルの適用を進言した場合も含みます。
【災害等による長時間のサービス停止】
第4レベル： 数日間にわたって復旧する見込みがない。
第3レベル： 12時間以内に復旧する見込みがない。
第2レベル： 12時間以内に復旧する見込みである。
第1レベル： 一部のみの障害である。
補足事項：上記には、建物の法定停電等の計画停電によるサーバ、およびネットワークの停止に帰するサービス停止や、定期メンテナンス等による停止は含みません。
【テロや暴動、破壊、侵入等の犯罪】
第4レベル： 当組織の従業員の生命にかかわる事態の発覚。
第3レベル： 未定義。
第2レベル： 未定義。
第1レベル： 未定義。
補足事項：上記レベルの選定には、関係当局の指導や、公的な第三者が、そのレベルの適用を進言した場合も含みます。
【コンプライアンス違反】
第4レベル： 組織の存続にかかわる事態の発覚や、反社会的行為、故意によるコンプライアンス違反、従業員による情報の漏洩。
第3レベル： 過失によるコンプライアンス違反。
第2レベル： 未定義。
第1レベル： 未定義。
補足事項：上記レベルの選定には、公的な第三者が、そのレベルの適用を進言した場合も含みます。
以上、それぞれの危機ごとにそのレベル分けを行ないました。
ここで使用したパラメータ（4時間や1週間、数日、震度等）については、それぞれの組織および稼働している情報システムの種類によって変化させる必要があります。
【具体例】情報システム業務継続計画 - 対応方針原則
以下の方針および優先順位に沿って、障害対応にあたり、事業継続を図るものとします。
【障害時の対応方針】
① 緊急事態の宣言
第3レベル（レベル分けについては、次回に触れます）以上の障害が発生した場合、10分以内に対策室を設置の上、各部門長に通知する。
② 従業員および従業員の家族の安全確保
従業員、およびその家族の安全を最優先とした対応を行う。
また、災害発生後12時間以内に、全従業員の安否確認を済ませる。
③ 対顧客の業務の継続
最優先業務は24時間以内に再稼働させる。
④ 企業活動の維持、継続
ネットワーク通信は72時間以内に再稼働させる。
⑤ 二次災害等への対応
自社に起因する二次災害が周辺におよぶことを阻止する。
⑥ 自社資産の保全
混乱時の不祥事および犯罪を防止する。
⑦ 最優先で再開すべき業務
顧客および利害関係者への通知を行う。
⑧ 比較的優先すべき業務
決済業務、その他期限に余裕のある業務
まず重要なことは、従業員およびその家族の安全確保です。
情報システムは大切かもしれませんが、命を落としてしまっては何にもなりません。
次にお客様にできる限りご迷惑がかからないよう、配慮することも必要です。
お客様は、こちらの製品やサービスを待っているかもしれませんし、それが滞る事により、お客様のお客様にご迷惑がかかってしまうことも十分にあります。
そして最後に自社の業務復旧、という手順になります。
顧客第一主義を、組織内のミッションに掲げているのであれば、業務復旧計画もそれに沿ったものでなければなりません。
【具体例】情報システム業務継続計画 - 対象範囲
けんぢが以前に作成した、情報システム業務継続計画では、以下の組織としての情報システムに対する危機を事業継続計画の対象としています。
1. PCや、可搬情報媒体の紛失、盗難
2. 情報の漏洩および紛失
3. 電源の障害
4. 空調の障害（サーバルームやパッチケーブルラック周辺）
5. サーバの故障、ネットワークの障害・停止
6. 地震や火災などの災害
7. テロや暴動、破壊、侵入等の犯罪
8. コンプライアンス違反
災害、というと天変地異やテロ、火事等に限定して考えがちですが、情報システムを使用した業務の継続を阻害する要因をここで列記しておくことが大切です。
『従業員の情報システムに対する理解の低さ』が、実業務の阻害要因になることもあるかもしれませんが、それは継続計画ではなく、従業員への教育計画でカバーすべきことです。
そのため、そのようなことはここでは入れておりません。
もちろん、そのような『理解の低さ』が、危機を引き起こす（電源コードを抜いてしまった・・・とか）ことはありますが・・・
ここでは、危機が起きてしまったらどうする、というところに主眼を起き、全体を構成、作成してみてください。
【具体例】情報システム業務継続計画 - 全体の構成
現在では、情報システムはある程度年中無休で活動している感があります。
また、PCや携帯電話、スマートフォン等の媒体の爆発的な増加に伴って、それらが使用する情報システムサービスは、継続して提供されることが当然のようなご時世です。
しかしながら、事故は当然起こるもので、その有事の際に、いかに速やかに情報システムを基軸とした業務を復活させるか、情報システム部門の腕の見せ所となっています。
情報システム部門に従事していらっしゃる方々、今後も頑張ってください。
今回は、その情報システムの復旧活動の指針となる計画書の作成について書いてみます。
情報システム業務復旧計画書とは、組織が、不慮の災害や事故、あるいは障害等により、重大な損害を被り、その業務遂行が困難になった際に、その損害の範囲と業務への影響を最小化し、迅速かつ効率的に業務の復旧を行うための計画を定めたものです。
計画書には下記の項目別に、その詳細内容を記載していくと良いでしょう。
また、情報システムだけではない、組織全体の業務復旧計画がある場合は、その内容を基軸として、全体の構成をそれに合わせ、整合性を保つことも非常に重要です。
【構成】
1. 情報システム危機に対する業務継続計画の対象範囲（どのような危機を想定しているか）
2 .障害時の対応方針原則
3. 危機のレベル分け
4. 対象アプリケーション
5. 対策本部の設置に関する原則
6. 緊急時の行動手順と対策
7. 試験と更新
8. 連絡体制
普段から、上記のようなことは、何気なく理解しているかもしれません。
しかしながら、その理解度や優先順位は、組織で働く従業員個人個人で当然違った形で捉えられ、有事の際には、それが基で混乱を招く、といったことが少なくありません。
ここで重要なことは、手順を明文化し、それをできればすべての従業員が理解しており、有事の際に勝手な行動を取らない、ということが徹底されている、ということです。
できれば有事は起きてほしくないものですが、起きてしまった後の対応の良さが、CSRの向上にもつながります。
ネガティブなようですが、「備えあれば憂いなし」と言う諺もあります。ぜひ、当計画書の作成に挑戦してみてください。
次回は、上記の構成を各項目ごとに、具体的（けんぢの経験ですが）に書いていきます。
【具体例】災害復旧 - 雛形
今回は、前回お話した災害復旧のテストに向け、その計画書に記載しておくと良い項目を雛形を使用し、お話しておきます。
計画書に必要となる項目
【重要アプリケーションおよびシステム】
すべての重要アプリケーションのリストを作成し、以下の情報を併記してください。
i. 復旧の際の優先順位リスト
ii. 復旧の際の指針となる各アプリケーション別の詳細情報
1. 許容可能な遅れ（会計期間や締め日の関係で、災害発生日によって異なる可能性がある）
2. 関連するシステムデータ
3. 各重要アプリケーションから、システム、アプリケーションサーバ、データベースへのリンク
【情報システム基盤の説明】
重要アプリケーションを支援するための、すべての重要機器および情報について調査して、文書化しておく必要があります。
i. 現行情報システム基盤の既存のスキーマ
ii. すべての機器、ネットワーク、構成のリスト
iii. 以下の情報を含む機器の提供サプライヤとの契約情報
1. 電話番号、契約書名
2. サービスレベル（交換に要する時間を含む）
iv. バックアップのスケジュールおよび手順（頻度、支援、場所など）
v. 復旧
1. テスト結果
2. バックアップ・メディアからの復元方法
vi. バックアップ・リスト（バックアップ・メディアすべてかどうか）
また、復旧に必要なインフラストラクチャのリストも作成しておくとよいでしょう。
【災害発生時の組織】
a. 連絡先
b. 適格者リスト（氏名と電話番号を含む）
c. サプライヤへの連絡方法
d. 責任者
e. 通信手段
f. 連絡元と連絡先
g. 情報システム災害復旧チームと、他の関連組織（本社や代替場所等）内危機対応チームのつながりの説明
次回は、具体的な業務継続計画に関して、もう少し掘り下げてみましょう。
災害復旧
2001年9月11日、ニューヨークおよびワシントンで同時多発テロが発生し、多くの尊い生命が奪われてから9年が過ぎました。
その当時、けんぢは現在の会社でなく、前の会社（外資系）に在籍しており、その本社はニューヨーク・マンハッタン島にありました。
日本からも何人かの同僚が、駐在や研修でニューヨーク本社に行っており、その安否確認や、的確な状況把握が遅々として進まず、気を揉んだことを思い出します。
さて、今回は情報システムの復旧について、何回かに分け、その内部統制上の意義やポイント、さらには具体的な計画書の内容について書いていこうと思います。
9月は関東大震災や、上記の同時多発テロ等、どうしても災害というものに対して考えてしまいます。
起こってはならないことですが、それが起こってしまったときに対する備えも必要です。
これを機会に、実現可能は計画を立ててみてはいかがでしょうか？
内部統制上の観点から、災害時への備えとして押さえておくべきことは、下記のようなものになります。
まず、重要システムが失われた場合に、情報システム運用を継続するための緊急時計画を定めて、それを実施可能な状態にするため、テストしなければなりません。
もちろん、そのテストの際には、重要アプリケーションに関する、全データの復元と完全性を証明済みであることが前提条件となります。以前に書いたバックアップに関する記述を参考にしてください。
その前提条件が満たされた上で、災害復旧計画およびテストでは、災害発生時に効率的に行動することができる組織が存在すること、また代替場所や予備機器で、重要アプリケーションとそのシステム基盤およびネットワーク接続を再構築し、組織および事業にとって許容できるレベルのパフォーマンスで動作することの証明のいずれにも焦点が置かれます。
テストでは再構築したものが適切に動作するだけでなく、そのパフォーマンスが事業運営の継続に十分なものであると検証されていることを現実的に示す必要があります。
多くの場合は、予備機器で再構築したアプリケーション、およびデータ通信のパフォーマンスは、通常稼動時よりも低い許容可能なレベルに留まりますが、緊急時の運営継続に十分なものであることを証明しなければなりません。
そのため、ユーザーとともに緊急時サービスレベルを定義し、事業ユーザーがこれをテストするための現実的な方法を決定する必要があります。
災害復旧計画には以下の手順を含め、そのプロセスを文書化して、テスト活動の記録を保管しなければなりません。
これは、プロセスに従っていることを証明し、プロセスの有効性をレビューするための証拠を提供することで改善点を識別するためです。
1. リスク評価
リスク評価の目的ですが、組織としての事業運営の継続に不可欠と看做されるアプリケーションのリストを作成することと、事業にとって許容可能な時間内に確実に復旧するための技術的アプローチを決定することです。
理想的には、これは、まず存在しうるあらゆる脆弱性と、それによって事業が被りうる影響を識別する体系的なアプローチであるべきです。
次に、上記の各脆弱性が害を及ぼす可能性について判断を下し、リスク低減策の策定が可能な脆弱性の優先順位のリストを作成します。
ただし実際には、リスクに関する主観的な想定でプロセスが開始し、簡略化されたリスク評価の取り組みにつながる場合が多々あります。
そのような場合、災害復旧計画が正式な客観的プロセスの結果として作成されたものではなくても、リスクに関する記述を含めておくと良いでしょう。
2. 重要アプリケーションの決定
事業の災害復旧のニーズを満たすために、どんな技術基盤が必要かを明確に理解できるよう、重要な事業アプリケーションのリストを用意しておくことが重要です。
情報システム部門は、重要な事業アプリケーションや、災害発生後の許容可能な最大復旧時間を判断できないため、独力ではこのプロセスの策定は困難です。
財務アプリケーションであれば、財務担当役員がというように、実際には事業アプリケーションの「所有者」がこれを決定するべきです。。
しかし、多くの場合、どのアプリケーションが不可欠か、つまりどのアプリケーションを復旧できないと事業運営が不可能になったり、重大な経済的損失を被るかを判断するのは困難です。
現実には、何らかのアプリケーションで実行される自動機能等がある場合、その実行を遅らせたり、手作業で行ったりすることもできます。
したがって、優先順位と許容可能な復旧時間を確認するために、戦略レベルで重要リストをレビューする必要があります。
高度に一元化された技術環境では、全アプリケーションを同時に復旧させる方が、優先順位に基づいて個々のアプリケーションを復旧させるよりも速い可能性があります。
しかしこの場合も、復旧チームが緊急時の作業の優先順位を判断するための枠組みとして、優先順位リストを用意しておくことは非常に有益なことです。
3. 技術リスクの低減
正式または略式のリスク評価に基づき、重要アプリケーションが決定され把握されたら、次にデータセンター等のシステムの設置場所にアクセスできないことで発生する技術リスクの低減方法を検討します。
まず、予備機器（代替場所にある複製や、専門会社との契約に基づくもの）にアクセスするための最適な方法を決定します。
同時に、災害発生時にデータ、ソフトウェア、ネットワーク接続の復旧をより迅速かつ確実にするための技術基盤の変更についても検討しなければなりません。
4. コンポーネントテスト
災害復旧基盤に対しては、個々のテストを定期的（年1回が好ましいとされています）に実施し、その記録を保管しなければなりません。
そのテスト活動を証明するほか、管理層がそれらの記録から得られる結論をレビューして、改善点を見つけ出して、承認や補完活動を行えるようにするためです。
このテストには、個々のサーバおよび重要アプリケーション、ネットワーク、データ通信コンポーネントを予備機器で再構築することを含めなければなりません。
コンポーネントテストでは、テスト用サーバ上のデータベースに接続することによって、予備機器にアプリケーションを再構築したことを証明すれば良いとされています。
5. 完全テスト
完全テストでは、その対応を行う担当者と対応の手段、その意思決定を行う組織計画を証明できるように計画されていなければなりません。
また、重要アプリケーションおよびデータが予備機器で適切に復旧し、ユーザーが許容可能なレベルのパフォーマンスでアクセスできることも証明する必要があります。
この完全テストの成功はテストでしか実証できないため、熟考したテスト計画の作成が、この前段階の非常に重要な部分となります。
注意事項となりますが、すべての重要アプリケーションを復旧させてテストすると事業の支障となる（場合によっては取引先に多大な影響を及ぼします）ため、これは困難ですし、不用意に行うべきではありません。
完全テストでは、いくつかの選択した、重要アプリケーションを完全に復旧させてテストすれば十分です。
ただし、完全な再構築に必要なすべての技術環境を網羅するよう、これらのアプリケーションの選択は慎重に行う必要があります。
また、実際の災害の不確実性を多少再現するため、テストを開始するまで、リストは機密扱いにすることも有益となります。
次回は、その計画書の項目別雛形を使用し、具体的に説明します。
【具体例】ユーザー導入教育 - 印刷物を出力するときの注意
【文言】
業務上、印刷物を出力することは非常に大切です。
しかしながら、不必要な出力や、出力後の印刷物の放置を行うことは、機密保持の観点からも問題があります。
電子メールやポータルの使用、プロジェクター等を利用した会議、使用後のシュレッダー処理等、適切な処理をお願いいたします。
また、コスト削減の観点からも、印刷物の抑止は非常に重要です。
現在、弊社が主契約している機器で説明しますが、下記の費用がランニング費用として発生します。
<< 出力1枚あたりの費用 >>
・白黒印刷 2.0円
・フルカラー印刷 13.0円 （白黒の6.5倍の費用です！）
白黒印刷やトナーセーブ設定をする事で、大幅なトナーの節約による経費節減に繋がります。フルカラー印刷を行う必要のない書面の印刷については、「白黒印刷」および「トナーセーブ設定」を設定して下さい。
--------------------
どうしても業務上、紙の印刷物は必要です。
しかし、無駄な印刷物も多いのではないでしょうか？
日常の習慣から、とりあえず印刷し、後で目を通す、ということを行われている方々も多いでしょう。
これは、組織内での業務だから、という理由を付け容認してしまう、ということから来ています。
自宅でメール等を見る場合はどうでしょうか？
毎回印刷する人はあまりいないでしょう。プリンタのインクや紙の費用もかかりますしね。
自宅の場合に抑制できて、組織内での業務の場合は抑制できない、ということにはあまり明確な理由を見つけられません。
ここで言いたいことは、すべての印刷物をなくす、ということではありません。
必要なものは必要なので、きちんと印刷する。
一時的な作業用紙等であれば、その後きちんと適切な処理をする。
無駄なものは印刷しない。
このことに尽きます。
前回書いてみました悪役の考えが今回も必要ですね。
組織が前に進むために必要な苦言と考え、悪役になりきってください。
次回は、教育関連ではないですが、内部統制上の業務復旧計画について書いてみます。
【具体例】ユーザー導入教育 - 携帯電話の使用について
【文言】
弊社では、許可された者に対し、携帯電話を通信手段として貸与しております。当携帯電話機は、業務上の通話のために貸与しておりますので、その通信履歴は、会社として、的確に把握しております。業務以外の使用につきましては、お控えください。
携帯電話用メールアドレスも設定しております。音声通話にふさわしくない状況（電車の中等）での、通信コミュニケーションの際にご利用ください。
また、携帯電話機はレンタル品であるため、本体および付属品が入っていた箱、および内容物については、保管しておいてください。
------------------
けんぢの会社では、固定電話をできる限り廃止し、その代替として、全従業員に対し、携帯電話を支給しています。
もちろん、それなりに費用は掛かっているのですが、固定電話と比較して、その低減が実証されているので、導入に踏み切ったわけです。
また、上記の費用低減だけでなく、機会損失の低減や、即時対応によるサービス向上もその背景にあります。
携帯電話は非常に便利な機器ですが、それと同時に、いろいろな情報を小さな個体の中に内蔵した、非常にリスクの高い機器である、ということも言えます。
基本的に業務上の理由のみに使用してもらいたいものですが、やはり個人的な使用も散見されています。
そのような行動を抑止するために、使用状況サポートを毎月全従業員に発信し、できる限り個人攻撃のようなことを避け、集団心理による抑止力を高めています。
具体的には、下記のような項目を毎月取得、集計しています。
・時間帯（0時～24時まで、1時間ごと）別の発信通話時間やその料金
・曜日別の発信通話時間やその料金
・国別の国際電話の発信通話時間やその料金
上記のことを行うことにより、身に覚えのある従業員は、『管理されている』ことを理解し、同じような行動を取ることを避けるようになります。
もちろん、そのようなことを全く感じない、『肝の座った』従業員もいます。
その場合に、初めて個人にアプローチし、その改善を促すようにしています。
小さなことかもしれませんが、それを一度許してしまうと、全従業員が模倣（やはり原則は平等であるべきですから）し、本来の目的が達成できず、結果として、全従業員の身にその後始末が降りかかってきます。
情報システム部門は縁の下の力持ちですが、それ以外に、憎まれ役であることも必要です。
正義の味方を活かすためには、それを引き立てる悪役も必要です。
そのような慈愛に満ちた心でユーザーをサポートしてみてください。
次回は、印刷物の出力に関する注意について、書いてみます。