Comments
Description
Transcript
「2012年度重要インフラの共通脅威分析に関する調査」 の結果について
参考資料５ 「２０１２年度重要インフラの共通脅威分析に関する調査」 の結果について 2013年3月14日 内閣官房情報セキュリティセンター（NISC） １． ２０１２年度の分析テーマと活動内容について 分析テーマ 重要インフラ分野における同時多発型ＩＴ障害時の復旧対応について 【 背景 】 東日本大震災では、電力や情報通信と言った重要インフラ分野間の相互依存性の他、非常用発電機用の燃料や復旧に必要な資材 の確保や要員の参集等、重要インフラ分野間以外の阻害要因が重要インフラサービス及び重要システムの維持・復旧に対して大きな 影響を与えることが顕在化した。 これらは、重要インフラ分野内ではどうすることもできない外部依存性と捉えることができる。その中でも、分野共通性が認められる要 因に関しては、有事に、そのようなリソースへの一極集中の脅威を生み出すことが懸念され、一つの共通脅威として考えることができる。 このリソースとしては、燃料・資材・要員等の他に重要システム復旧に係るシステムベンダーやＩＴベンダーの対応能力等も含めたさま ざまな要素があると考えることができる。これらをＩＴという観点で抽出・調査・分析し、重要インフラ分野共通の外部依存性を明らかにす ることは、過去の解析では得られなかった新たな気付きに繋がる可能性が高い。 一方、重要インフラ分野間の相互依存性に関しては、２００７年度に実施された解析結果を再確認する時期になっている。東日本大震 災等の環境変化も踏まえて比較確認することによって、相互依存性の変化についても再確認すべきと考える。 【 活動内容 】 （１）過去の相互依存性解析結果の再確認 （２）外部依存性の調査 （３）重要インフラ分野における同時多発型ＩＴ障害時の復旧対応（ベンダへの外部依存性に関するベストプラクティス） ※ 「外部依存性」とは、本分析において重要インフラ分野間以外から生じた要因に よる重要インフラサービス及び重要システムへの波及性を意味する。 2 ２． 過去の相互依存性解析結果の再確認（１） （１）NISCにおける相互依存性解析の検討範囲と他の防災関連文献における検討範囲の違い 以下の防災関連文献における相互依存性検討結果を取り上げ、2007年度のNISCにおける相互依存性解析結果との差異について傾向を分析した。 岐阜大学 能島暢呂教授関連 国土交通省国土技術政策総合研究所関連 TNO(オランダ応用科学研究機構)関連 NISCの結果と、防災関連文献での検討結果に違いがあることがわかった。この理由としては、主に次の前提が異なるためだと考えられる。 NISCでは重要システムのIT障害を扱っているため、下図のようにインフラAのサービスが、インフラBの重要システムに影響を与えたか、という 観点に基づいている。（図中①） 一方、防災関連文献の検討では、インフラAのサービスが、インフラBのサービスに影響を与えたか、という観点に基づいている。（図中②） 加えて、インフラAのサービスが、インフラBの復旧に影響がある場合にも「依存性あり」と判断している。（図中③） そのほか、防災関連の検討では、事例の有無によって依存性を判断している場合も有り、結果が異なる原因となっていると考えられる。 上記の観点の違いにより、独立性が高い分野に対する波及に関しては、NISCと防災関連文献の相互依存性の結果が異なっている。 また、依存性の有無が同じ場合でも、防災関連文献では「復旧への支障」を含めているため、NISCの結果とは理由が異なっている。 NISCの検討範囲 ①インフラAのサービスが、インフラBの重要 システムに影響を与えたか、という観点 インフラB インフラAの サービス インフラBの 重要システム 独立性高い IT障害 独立性低い 操業レベル インフラBの サービス 時間 復旧曲線 防災関連文献の検討範囲 ②インフラAのサービスが、インフラBの サービスに影響を与えたか、という観点 ③インフラAのサービスの障害が、インフラBのサービス の復旧に影響がある場合にも「依存性あり」と判断。 3 ２． 過去の相互依存性解析結果の再確認（２） （２）2012年度の重要インフラ事業者等へのアンケート・ヒアリング調査結果 前項の「（１）NISCにおける相互依存性解析の検討範囲と他の防災関連文献における検討範囲の違い」では、NISCの相互依存性解析 の結果の定期的な検証のために、防災関連文献の検討結果を流用することは困難であると判断した。 このため、本年度の重要インフラ事業者等へのアンケート・ヒアリングでは、従来の相互依存性の分析結果の再確認のための項目を含 めた。 アンケート・ヒアリングでは、２００７年度相互依存性解析報告書の該当する分野の分析結果を参照していただき、現時点で変化のあっ た箇所を確認した。 【 アンケート・ヒアリング調査内容 】 Q.1 重要システムの定義の見直しについて 現状のシステム構成を踏まえて、自分野の重要システムの定義の見直し（システムの追加・変更・削除）の必要性を感じていますか？ Q.2 独立性について 自分野サービスの重要システムからの独立性の高低について見直しに必要性を感じていますか？ Q.3 他分野から波及を受ける相互依存性について 他分野から波及を受ける相互依存性について、新たに分野間で依存性が生じたことや既存の依存関係で内容の変化があったことなどに よって、内容の見直しの必要性を感じていますか？ Q.4 自分野から波及を与える相互依存性について 自分野から波及を与える相互依存性について、内容の見直しの必要性を感じていますか？ 【 アンケート・ヒアリング調査結果まとめ 】 「重要システムの定義」、「独立性」、「自分野から波及を与える相互依存性」については、すべての回答が「見直しの必要なし」 であった。 「他分野から波及を受ける相互依存性」については、一部分野から「見直しの必要あり」とコメントがあったが、その後のヒアリ ングで確認した結果、個別の事業者では変化がある場合もあるが、分野全体として同様とは言えないため、今回の結果により 見直すことは妥当でないと判断した。 例：非常用発電で水冷式を廃止したケース。当該事業者では水道分野からの波及が無くなっているが、同じ分野の別の事業者では依 然として水道分野からの波及が有るという回答で有った。 4 ３． 外部依存性の調査（１） （１）調査の方向性 分野共通によるリソースの集中を共通脅威と考えるが、予想される項目のうち、非常用燃料や水や非常用通信(衛星電話)の問題は、内 閣府中央防災会議などで、防災の観点で論議されている。また、内閣官房のIT戦略本部主催でIT防災の観点でも論議されている。 本調査では、重要インフラに係るIT障害を扱うことを前提としているため、防災の観点では論議が活発になされていない分野に絞り、特 に同時多発的IT障害時のリソース集中が考えられる外部依存性に焦点をあてることとする。 外部依存性の中で、優先的に調査分析すべき対象候補として、「特定のIT技術・構成要素」と「ITベンダ（構造や要員）」が考えられる。 文献調査、有識者ヒアリングでは、特定のIT技術・構成要素やITベンダに関する課題を確認する。 重要インフラ事業者等に対するアンケート調査・ヒアリング調査では、特定のIT技術・構成要素やITベンダに関する課題を中心に、重要 インフラ分野における状況を把握する。 ベンダ企業へのヒアリングでは、重要インフラ事業者等に対するアンケート調査・ヒアリング調査で確認した状況及び課題について、対応 するベンダ側の状況及び認識を把握する。 【参考】重要システムに影響を与える構成要素の想定 【参考】調査の方向性に関する有識者ヒアリングの結果 アウトソーシングしているＩＴベンダ等の構造について • 元請から下請けへとピラミット構造となっている。 • 裾野の下請けがフィールドサービスの請負業者と考えられる。 • 業種毎に元請ベンダは異なり、複数のピラミットが存在するが、下 請けは重複している可能性がある。特に、スキルのある人材が希 少と考えられる。 • システム運用については、マニュアルのみで下請けが対応する体 制にも問題がある。有事の際にはマニュアル通りの対応では限界 がある。 特定のIT技術・構成要素などに関する課題について • 特定技術（ネットワーク機器、基盤ソフト、特定開発言語など）への 依存により、それらが障害からの復旧時にボトルネックとなる可能 性がある。 例：COBOL言語技術者の不足、特定ネットワーク機器ベンダへの 依存、特定基盤ソフトウェアへの依存、など 対応策の方向性について • ブラックボックスとなりがちなシステム仕様や保守契約内容の見え る化が必要。 • ＳＬＡの確立や第三者機関による認証 • 技術者の認定制度 5 ３． 外部依存性の調査（２） （２）重要システムの分類 同時多発型IT障害時の重要システム復旧の迅速さに対するベンダ対応に依存する度合いを評価するため、さまざまな分類を試みた。 その結果、傾向を顕著に示す分類の軸として「サービス独立性」「運用保守の主体」「ベンダの常駐」の３つの指標を採用し、重要システ ムを以下の６つのグループに分類した。 重要インフラ事業者等に対するアンケート・ヒアリング調査結果から傾向を抽出して分析する上で、この分類を活用した。 サービス独立性 過去の動的相互依存性解析における「重要システムとサービスの独立性」の分析結果を用いた。 アンケート・ヒアリング調査にて、サービス独立性の高低について見直しの必要性を確認したが、全ての分野について「見直しの必要なし」との結果であった。 サービス独立性が高いグループ（A-1/A-2/A-3）では、同時多発型IT障害発生時にも、重要システムの復旧を待たずに、インフラサービスを提供し続けられる可能性 が高い。 サービス独立性が低いグループ（B-1/B-2/B-3）では、同時多発型IT障害発生時には、重要システムが復旧しないと、インフラサービスが再開できない可能性が高い。 運用保守の主体 アンケート・ヒアリング結果から、運用及び保守の両方を自社または子会社を主体に実施しているか、保守（場合によっては運用も）をベンダ主体で実施しているかで 分類した。 自社または子会社が主体のグループ（A-1/B-1）では、ベンダの力を借りずに重要システムを復旧できる可能性が高い。 ベンダが主体のグループ（A-2/A-3/B-2/B-3）では、重要システムの復旧にはベンダの対応が欠かせない。 ベンダの常駐 保守（場合によっては運用）をベンダ主体で実施している重要システムに関しては、アンケート・ヒアリング結果から、ベンダ常駐の有無によりさらに細分化した。 ベンダ常駐が有りのグループ（A-2/B-2）では、ベンダが重要システムの復旧にすぐに着手できる。 ベンダ常駐が無しのグループ（A-3/B-3）では、重要システムの復旧にはベンダの到着を待つ必要がある。 6 ４． 重要インフラ分野における同時多発型IT障害時の復旧対応（１） 重要インフラ分野における同時多発型IT障害時に復旧対応について、本調査の分析テーマであるベンダへの外部依存性に絞って検討 を行った。 具体的には、重要インフラ事業者等に対するアンケートの単純集計結果による傾向、グループ分類による集計結果による傾向、及び、ヒ アリングで得られた情報を元に、重要システム運用保守の状況を総合的に判断したベンダへの外部依存性に関する状況と課題（想定）ご とにベストプラクティスを抽出した。 また、ベンダへのヒアリングは、重要システムの運用保守を担う大手ベンダ（制御系や情報系の数社）に対して実施し、重要インフラ事業 者の視点からベストプラクティスと考えられる内容を抽出した。 以下に、重要インフラ事業者等及びベンダへのアンケート・ヒアリングで抽出したベストプラクティスを示す。 ■ ベンダへの外部依存性に関するベストプラクティス 重要システムの状況と課題（想定） 重要インフラ事業者等へのアンケート・ヒアリングで 得られたベストプラクティス ベンダへのヒアリングで得られた ベストプラクティス （１）運用保守の主体 サービスの独立性が低い事業者では、ベンダ 側の対応により復旧対応が大きく左右される。 （背景など) 独立性が低い場合、重要システム復旧の緊急 度が高いため、ベンダ側の対応により復旧対 応が大きく左右される。 【自社による保守運用範囲の拡大】 開発から運用保守に移る段階で、ベンダ対応部分を自社に 徐々に移行し、運用開始から数年で、自社対応の比重を高 める。 （該当なし） 運用保守の主体がベンダの場合、その傾向が 顕著である。 ベンダ常駐の有無によっても、復旧対応に差が 出る。 7 ４． 重要インフラ分野における同時多発型IT障害時の復旧対応（２） ■ ベンダへの外部依存性に関するベストプラクティス（つづき） 重要システムの状況と課題（想定） 重要インフラ事業者等へのアンケート・ヒアリングで 得られたベストプラクティス ベンダへのヒアリングで得られた ベストプラクティス （２）ベンダの階層構造 階層構造の下位ベンダの要員が障害対応時 に欠かせない。 （背景など) IT技術が複雑化したために、ベンダでも分業が 進み、運用保守の階層構造が多層化、複雑化 している。 このため、階層構造の下位ベンダの要員まで 十分に把握できなくなっている。 下位階層のベンダの要員が特別な技術を持っ ており、障害対応時にその要員が欠かせなく なっている。 【ベンダ要員の所属の確認】 【ベンダ階層の制限】 より深い階層の要員については、事前の申請や身分証で確 認している。 システム開発において、契約により階層を 再々委託先までと限定している。このことが 運用保守における障害対応の不透明さを軽 減する。 【ベンダへの監査】 全ての委託先を年1回実査している。 データセンターへの視察を行い、ベンダの要員を把握してい る。 【ベンダ階層の制限】 契約や仕様書で、原則再委託を禁止し、必要な場合には届 け出をさせる。 （３）ベンダ要員スキルの把握 復旧対応が可能なベンダ要員のスキルが把握で きておらず、障害時に駆け付けたベンダ要員では 十分に対応出来ない。 【ベンダ要員のスキル確認と向上】 SLAや調達仕様書で要員のスキルを規定している。 （背景など) プロジェクトマネージャ個人には、業務知識と類似システムの 経験を求める。 IT技術が複雑化したために、ベンダ要員でも専 門化・分業が進んでいる。 基本契約書で、若年層を起用する場合に適切な対応を求め ている。 （該当なし） 複合的な障害が発生した場合に、専門知識を 持つ多くのベンダ要員が必要となる。 8 ４． 重要インフラ分野における同時多発型IT障害時の復旧対応（３） ■ ベンダへの外部依存性に関するベストプラクティス（つづき） 重要システムの状況と課題（想定） 重要インフラ事業者等へのアンケート・ヒアリングで 得られたベストプラクティス ベンダへのヒアリングで得られた ベストプラクティス （４）復旧対応体制 復旧対応が契約書などで明文化されていないた め、同時多発型IT障害が発生したときに、ベンダ 側で十分な体制がとれない。 【復旧対応の契約への明文化】 【ベンダの対応範囲の明確化】 首都直下型への対応を含めて、今後は契約書や覚え書きで 明文化する方向で検討している。 （背景など) 業務を委託する際に、自社の業務継続計画に則って依頼し ている。 大規模災害時の対応として、顧客側のBCP に基づいたベンダの対応範囲を定めて所管 省庁に報告する。 重要システムの障害対応について、契約書な どで十分に明文化されておらず、口頭での約束 に依存している。 IT化による効率化を進めたために、自社要員を 削減した結果、手作業等による代替が困難に なっている。 復旧対応において、ベンダの対応まで把握して 計画がなされていない。 【契約書・仕様書に記載する復旧対応の内容】 障害の原因を特定せずに、開発仕様書でシステム復旧時間 を定めている。 障害対応のレベルを4～5段階設定しておき、 障害の内容によって意思決定のレベル（役 員レベル、部署レベル、など）をエスカレー ションする。 要件定義の段階で、バックアップや復旧目標を指定している。 【ベンダの対応範囲の明確化】 サービスの独立性が低い事業者では、重要システムの維持 のために、ベンダ要員を含めたBCPを策定している。 （５）ベンダ対応時間 障害復旧に必要なベンダ要員が現場に到着する 時間が遅れて、重要システムの復旧が遅れる。 【ベンダ駆け付けの迅速化】 【ベンダ対応体制の強化】 （背景など) 重要拠点の近くにベンダ拠点があるためすぐに駆けつけられ る。 障害発生時にベンダが駆け付ける時間につい て、事業者の期待と実態が乖離している。 仕様書に定める駆けつけ時間を満たすために、ベンダ側で 自発的に常駐要員を配置している。 契約によって障害時の保守対応開始までの 時間を指定する。保守コストの増加要因で あるが、これによって、ベンダ側の対応体制 整備が可能となる。 同時多発型IT障害発生時に、交通事情やリ ソース不足などの複合的な理由により、復旧対 応が遅れるケースがある。 ベンダが運営するデータセンターでシステムを運用している。 障害の原因が複雑な場合には、SEなど専門技 術をもつベンダ要員が必要となる。 【連絡体制の確立】 ソフトウェアについては、常駐要員が対応出来ない場合はリ モートログインで対応する。 24時間常駐の保守契約に加えて、ベンダとの緊急連絡ルー トも確立している。 【ベンダ対応時間の改善】 修理に時間がかかった場合には報告を求めて、改善活動に 繋げている。 9 ４． 重要インフラ分野における同時多発型IT障害時の復旧対応（４） ■ ベンダへの外部依存性に関するベストプラクティス（つづき） 重要システムの状況と課題（想定） 重要インフラ事業者等へのアンケート・ヒアリングで 得られたベストプラクティス ベンダへのヒアリングで得られた ベストプラクティス （６）自社対応範囲 複雑な障害の場合にはベンダの対応が必須となり、 【事業者要員の能力強化】 自社のみでの復旧が難しい。 子会社要員については、ITスキル標準（ITSS）に基づくスキ （背景など) ル向上教育や、スキル強化の要望を行っている。 ＩＴ化が進むに伴い、ベンダへの依存度が高 まっており、自社で重要システムを全て把握す ることが難しくなってきている。 本社と子会社で人事交流を行うことで本社・子会社の要員の スキルアップを図っている。 ベンダが常駐している場合でも、常駐要員のス キルに依存する。 ベンダの要員の活動を前提に業務継続計画を作成している。 【復旧対応における事業者とベンダの協力】 原因切り分けや原因究明も、自社とベンダの要員が一緒に 対応する。 【復旧対応パターンの詳細化】 今までの障害の経験を踏まえて、障害規模 に応じた運用保守体制のパターンを増やし た。 【事業者とベンダが共同で行う復旧対応訓練】 事業者とベンダが共同で障害対応訓練を行 う。 【事業者要員の能力強化】 ベンダから自社保守要員に対する教育サー ビスを受ける。 （７）人的リソース集中の認識 同時多発型IT障害により、広範囲に多くの分野の 重要システムに障害が発生した場合には、対応に あたるベンダ要員が不足する。 【ベンダ要員の確保】 障害時には自社システムを理解している技 術者がキーとなることから、自社システムに 必ず複数のベンダ側技術者が対応できるよ うにベンダに要請する。 （背景など) 平常時では足りていたベンダ要員リソースが、 同時多発型IT障害では不足する。 特に複雑な障害が発生した場合に、対応でき る技術を持ったベンダ要員が限られているため、 復旧に時間がかかる。 （該当なし） 同時多発型IT障害の際には、下位階層のベン ダ要員の確保が難しく、復旧対応が遅れる。 10 ４． 重要インフラ分野における同時多発型IT障害時の復旧対応（５） ■ ベンダへの外部依存性に関するベストプラクティス（つづき） 重要システムの状況と課題（想定） 重要インフラ事業者等へのアンケート・ヒアリングで 得られたベストプラクティス ベンダへのヒアリングで得られた ベストプラクティス （８）機器の調達 多数の代替機器が必要となった場合に、ベンダが 確保している機器の在庫が不足する。 【代替機器の在庫確保】 【代替機器の在庫確保】 （背景など） ベンダに在庫がないものについては、システムを多重化（3重 化）することで対応している。 予備品の在庫が重要システムの近くにないた めに、復旧が遅れる。 主要部品は自社やベンダで在庫をシステム拠点にストックし ている。 専用品は自社で在庫を持つ、型番のある汎 用品はベンダで在庫を持つというようにベン ダとの役割分担で機器の在庫を確保する。 特に海外製品の場合、国内在庫が限られてい るために、不足した場合には調達に時間がか かる。 【代替機器調達の容易化】 調達が容易な汎用品を使っている。 販社を複数としている。 海外製品は調達に時間がかかることを考慮 して自社で在庫を保有している。機器ベンダ 側は販売在庫しか保有していない場合が多 いため、品薄になりそうな製品は先行発注 している。 海外製品について、複数の調達ルートを保持している。 同一機能を実現するのに、異なるメーカの機器を使って構成 を変えている。 【機器の長期利用への対応】 システムを長期間使用する前提でベンダと契約している。 部品の生産終了時に代替品への交換とそのコストをベンダ 側から通知する。 【定期的な機器交換】 故障発生に備えて、定期メンテナンス時に古い部品を予防的 に交換している。 サポート切れや部品不足をベンダに確認して、新しい部品や 汎用部品に切り替えている。 11 ４． 重要インフラ分野における同時多発型IT障害時の復旧対応（６） ■ ベンダへの外部依存性に関するベストプラクティス（つづき） 重要システムの状況と課題（想定） 重要インフラ事業者等へのアンケート・ヒアリングで 得られたベストプラクティス ベンダへのヒアリングで得られた ベストプラクティス （９）システム構成上の対策 ネットワークや電源の2重化、バックアップシステム やデータのバックアップなど、システムの耐障害性 を高める対策が不足している。 （背景など) コストの問題や重要システムの性質の違いな どにより、ネットワークや電源の2重化、バック アップシステム等が、必ずしもすべての重要シ ステムで備えられていない可能性がある。 【異なるメーカー機器によるシステムの2重化】 【異なるメーカー機器によるシステムの2重化】 同一の機能に対してメーカを変えてシステムを構成する。 システムを2重化する場合に、それぞれを異 なるメーカーの製品で2重化する。 複数の電力会社、複数の通信キャリアを利用する。 【保守・開発用システムを含めた多重化】 システムをメイン／バックアップ以外に、保守用、開発用など を組み合わせて多重化する。 ネットワークや電源の2重化、バックアップシス テムやデータのバックアップなどについて、同 時多発型IT障害を想定した備えが十分でない 可能性がある。 ⇒システムの2重化による備えは多くの重要シス テムで対応が取られていたことが確認できた。 12 ４． 重要インフラ分野における同時多発型IT障害時の復旧対応（７） ■ ベンダへの外部依存性に関するベストプラクティス（つづき） 重要システムの状況と課題（想定） 重要インフラ事業者等へのアンケート・ヒアリングで 得られたベストプラクティス ベンダへのヒアリングで得られた ベストプラクティス （１０）オープンシステム対応 重要システムのハードウェア・ソフトウェアの汎用 化・オープン化によるブラックボックス化が進み、 障害原因の特定が自社では難しくなっている。 【設計開発段階での品質管理】 （背景など) EA（エンタープライズ・アーキテクチャ）※に基づく選定を行っ ている。 重要システムを構成するハードウェア・ソフト ウェアの汎用化、オープン化が進んだため、障 害原因の特定が難しくなっている。 設計開発時には、品質確保のために開発標準・ガイドライン を用いて標準化などを行っている。 【テスト段階での品質管理】 実地環境をベンダに用意させるなど、ベンダ側で十分なテス トを実施している。 社内の関係部署が品質検査に大勢関わることにより、品質 の評価を行っている。 オープンシステムのインタフェース調整のために、関係者を 集めた調整会議を開催している。 （該当なし） 【構成部品選定時の障害対応への考慮】 ベンダに対して、実績のある製品を使うように要求している。 汎用品を使う際には、技術的に枯れたもの（成熟したもの）、 保守期間が長いものを採用する。 ハードウェアとソフトウェアを一体として調達することで、オー プン化をしないようにしている。 システムを内製化することで、ブラックボックス化を防いでい る。 13 ５． 2012年度共通脅威分析のまとめ（１） ■ 相互依存性解析について 相互依存性に関する文献調査を行い、NISCにおける相互依存性解析の結果と他の防災関連文献との比較を行っ た。その結果、防災関連の相互依存性解析の取り組みに対して、NISCにおけるIT障害に特化した結果との相違が 確認できた。 分野間の相互依存性について、分野委員へのアンケート調査・ヒアリング調査および文献調査により、環境の変化 などに伴う見直しの必要性の有無を確認した。 その結果、個別の事業者では変化がある場合もあるが、分野全体としては現時点では見直しの必要はなしと判断 した。 【今後求められる対応】 個別事業者における取り組みが、他事業者や他分野へ波及することも考えられる。将来の変化に対応するため にも、今後も分野・事業者の動向及び相互依存性に及ぼす影響を定期的に確認すると共に、重要インフラ分野 間での情報共有を行う必要がある。 14 ５． 2012年度共通脅威分析のまとめ（２） ■ 重要インフラ分野における同時多発型ＩＴ障害時の復旧対応について （ベンダへの外部依存性について） 同時多発型IT障害を想定した重要システムの復旧対応における、ベンダへの外部依存性について、分野委員への アンケート調査・ヒアリング調査、有識者・ベンダ企業へのヒアリング調査、および文献調査により、状況と課題、分 野・事業者におけるベストプラクティスを確認した。 その結果、同時多発型IT障害時の重要システム復旧の迅速さに対するベンダ対応への依存度は、分野や重要シ ステムの特徴により違いがあるものの、重要システムにはベンダへの外部依存性が存在することが確認できた。 【今後求められる対応】 本調査で抽出したベストプラクティスについて、各分野・各事業者において適用可能な内容については、今後の 重要システムの運用保守等に取り入れることを検討することが望ましい。特に、今回実施した重要システムの分 類（6グループ）については、各重要システムが該当するグループに関する課題やベストプラクティスのみならず、 他のグループで先進的に発現している課題やベストプラクティスについても検討することが望ましい。 また、本調査で抽出した状況と課題から読み取れたような事業者とベンダ間の意識の相違にも留意することが 望ましい。 以上を踏まえた上で、ベンダへの外部依存性によるリスクを軽減するためには、事業者とベンダの重要システ ム復旧に向けた連携体制の強化や情報共有の確立を進めることが望ましい。 事業者とベンダの重要システム復旧に向けた連携体制の強化 （例） • 障害の想定レベルとベンダ対応の明確化 • 復旧対応の契約への明文化と予算の確保 • ベンダを含めた復旧対応訓練による実効性の検証 • 同時多発型IT障害を想定した保守部品の調達体制の整備 • ベンダ企業に対する監査内容の充実、など 事業者とベンダの情報共有の確立 （例） • 障害発生時のベンダとの連絡体制（保守要員のスキル等を含む）の定期的な確認・更新 • 定期的な事業者とベンダの情報共有会議の開催、など 15