参考資料５「２０１２年度重要インフラの共通脅威分析に関する調査」の結果について

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