enhancement cente r information-technology …...2013/12/11 · enhancement cente r...

Information-technology Promotion Agency, Japan

Software Reliability Enhancement CenterCopyright © 2012-2013 IPA, All Rights Reserved

S o f t w a r e R e l i a b i l i t yEn h an c emen t Cen t er

高いレジリエンスによるＩＴサービスの継続

～「高回復力システム基盤導入ガイド」解説～

独立行政法人情報処理推進機構（IPA）技術本部ソフトウェア高信頼化センター（SEC）

2013年12月11日

1Copyright © 2012-2013 IPA, All Rights Reserved Software Reliability Enhancement Center

目次

高いレジリエンスによるＩＴサービスの継続

1. ITサービス継続計画に関する現状

2. 「高回復力システム基盤導入ガイド」の概要

（１）背景と目的

（２）導入手順とガイドの構成

（３）ガイドの内容（活用方法）

（４）事例（調査に基づく）

3. 高レジリエンスの実現に向けて


ITサービス継続に関する現状

IPAの「情報システム基盤の復旧に関する対策の調査報告書」※

http://sec.ipa.go.jp/reports/20120725.html

を元にITサービス継続の現状を説明する。主な結果は次のとおり。・BCP（事業継続計画）/IT-BCP（ITの事業継続計画）の対策はあまり進んでいない。・IT-BCPの対策は立てても、教育訓練や見直しがされていない・システム障害は想定しているが、災害では津波や竜巻などは想定していない。・大企業ほどIT-BCPの取組が進んでいる。・復旧目標と対策が矛盾している場合もある。

※資本金1億円以上の企業3,000社を対象とするアンケート調査357件の回答に基づく



BCP（事業継続計画）とIT-BCPの策定状況

40.1%

33.1%

18.6%

6.2% 2.0%

策定済み未策定（検討中）未策定（予定なし）その他

24.8%

40.9% 27.4%

4.3% 2.6%

不明

<BCP (n=354)> <IT-BCP (n=347)>

・また、資本金や従業員の規模が大きいほど、策定している傾向が強い。・IT依存度が高いほど策定が進んでいる。

事業規模が大きくなればIT依存度が高くなり、結果的にBCPやIT-BCPの必要性が増してくるため、両計画を策定する企業の割合が増えるためと思われる。

<出典>「情報システム基盤の復旧に関する対策の調査」報告書，IPA，2012年。図4-3（資本金1億円以上の企業3,000社を対象とするアンケート調査の回答に基づく）


ITサービス継続計画策定時に想定するリスク

81.3%

74.2%

31.1%

25.3%

40.9%

51.6%

7.1%

32.4%

63.6%

42.2%

16.9%

56.9%

64.4%

14.2%

14.2%

4.0%

0.0%

1.3%

0% 20% 40% 60% 80% 100%

1.自然災害（直下型地震による局所被害）

2.自然災害（大規模地震による広域被害）

3.自然災害（津波）

4.自然災害（その他、竜巻や高潮等）

5.インフルエンザや感染症等によるパンデミック

6.建物や施設の破損・損失

7.原子力災害

8.社会的インフラの障害（通信回線関連以外）

9.ハードウェアの故障

10.ソフトウェアの不具合

11.システムの処理能力オーバーフロー

12.通信回線関連の故障

13.停電

14.外部コンピュータシステムの故障

15.テロやサイバー攻撃等の外部からの攻撃

16.特に定めていない

17.不明

18.その他

IT-BCPを「策定済み」または「未策定（検討中）」と回答した企業（225社）対象

<出典>「情報システム基盤の復旧に関する対策の調査」報告書，IPA，2012年．図4-8

東日本大震災の教訓を現実的に反映


52.2%

25.0%

28.1%

39.5%

19.7%

29.8%

17.1%

34.2%

29.8%

33.3%

44.3%

37.3%

44.3%

46.1%

11.8%

40.4%

35.5%

14.5%

40.4%

24.1%

33.3%

1.8%

4.8%

3.1%

1.8%

2.6%

1.8%

3.5%

0% 20% 40% 60% 80% 100%

1.事業継続のために必要なITサービスを特定

2.ビジネスインパクト分析（BIA）を実施

3.ITサービスの目標復旧時間等を策定

4.対策実施計画を策定

5.教育訓練計画を策定

6.事後対策計画や緊急時対応計画を策定

7.維持改善計画を策定

実施している実施を検討中実施していない不明

ITサービス継続への取組み状況

<出典>「情報システム基盤の復旧に関する対策の調査」報告書，IPA，2012年．図4-7（資本金1億円以上の企業3,000社を対象とするアンケート調査の回答に基づく）

ヒアリング調査では、ビジネスインパクト分析（BIA）の実施には膨大な稼働を要するとの意見もあった。

IT-BCPを「策定済み」または「未策定（検討中）」と回答した企業（228社）対象


情報システムの復旧目標設定の有無

21.1%

20.2%

18.8%

28.0%

29.0%

28.8%

37.9%

37.5%

38.2%

13.0%

13.2%

14.1%

0% 20% 40% 60% 80% 100%

RTO（n=346）

RLO（n=341）

RPO（n=340）

1.策定済み 2.未策定（検討中） 3.未策定（予定無し） 4.不明


復旧目標：目標復旧時間（RTO）、目標復旧レベル（RLO）、目標復旧時点（RPO）

復旧目標を設定している企業は2割程度！


事業継続戦略と情報システムの復旧目標

大規模災害や大規模システム障害により情報システムが停止した場合には，事業継続戦略に沿って復旧する．

災害などによって業務が中断した時点からいつまでに，どの程度で再開させるか，また，どの業務を優先させるかを決定．


目標復旧時間（RTO）とシステム冗長化の状況

<出典>「情報システム基盤の復旧に関する対策の調査」報告書，IPA，2012年．図4-26

62.5%

57.1%

75.0%

70.6%

69.6%

54.8%

50.0%

90.9%

20.0%

31.0%

14.3%

25.0%

23.5%

26.1%

35.5%

46.2%

9.1%

80.0%

2.6%

28.6%

3.2%

3.8%

3.9%

5.9%

4.3%

6.5%

0% 20% 40% 60% 80% 100%

合計（n=155）

1.1分程度～10分未満（n=7）

2.10分～30分程度（n=12）

3.30分～1時間未満（n=17）

4.1時間～6時間未満（n=46）

5.6時間～24時間未満（n=31）

6.1日～3日未満（n=26）

7.3日～1週間未満（n=11）

8.1週間～1か月未満（n=5）

a.冗長化している b.冗長化していない c.不明 d.その他

冗長化していないと、6時間以内のRTOの実現は困難。⇒ 事業継続性確保のためには、ITサービス継続戦略と対策の整合性の確保が重要


データの保管（バックアップ）の実施状況

92.7%

5.0%0.8% 1.4%

1.実施している

2.実施していない

3.不明

4.その他 36.1%

52.9%

10.9%

1.別拠点へのバックアップあり

2.同一拠点のみでバックアップ

3.不明またはバックアップなし

<データの保管（バックアップ）の実施状況>（n=357）

<バックアップの保管場所の分散度>（n=357）

<出典>「情報システム基盤の復旧に関する対策の調査」報告書，IPA，2012年．図4-27,4-32（資本金1億円以上の企業3,000社を対象とするアンケート調査の回答に基づく）

ほとんどの企業でデータのバックアップを実施しているものの、半数強が同一拠点のみでのバックアップにとどまっている。⇒ 大規模災害等によるデータ喪失のリスクあり


被災経験と震災後のデータの保管対策の変化

36.2%

45.4%

31.2%

27.6%

22.7%

30.3%

25.9%

28.6%

24.4%

9.1%

2.5%

12.7%

0% 20% 40% 60% 80% 100%

全体（n=340）

経験あり（n=119）

経験無し（n=221）

1.震災前の対策では不十分だと認識し、対策の検討を開始した2.震災前の対策では不十分だと認識したものの、対策の検討には至らなかった3.震災前の対策で十分だと認識し、現状維持とした4.不明5.その他


自らの被災経験によりデータのバックアップ対策の必要性を実感した企業は、データが毀損・滅失することを、より切実な問題として捉えている


システム復旧に有効であった技術・サービス

29.0%

14.8%

3.2%

1.3%

42.6%

10.3%

3.9%

19.4%

0% 10% 20% 30% 40% 50%

1.仮想化技術

2.クラウドサービス（SaaS、PaaS、IaaS）

3.RaaS

4.DaaS

5.データセンタ

6.無線等を使った通信サービス

7.省電力技術

8.その他

（n=155）


データセンタはシステム設置サイトの耐障害性を向上させるだけでなく、バックアップサイトとしての役割を果たす。仮想化技術やクラウドサービスには、引き続きその効果の発揮が期待される。


「高回復システム基盤導入ガイド」の背景

被災企業等では、一部の大手企業を除き、情報システムの災害対策や

被災時の対応手順等が十分に整備されていなかった。

東日本大震災を契機に企業等の中でIT-BCPへの意識は高まっている

が、IT-BCPの指針が難解で、未だ具体的な対策の着手に至っていな

いのが現状。

経営層のIT-BCPに対する投資の理解が不十分

初心者向けに、平易な内容で情報システムの継続に必要な考え方と導

入手順を解説（詳細なリスク分析等の手順を代替する方法を提示）

経営層へのIT-BCPの重要性の啓発

レジリエンス(回復力)底上げ


「高回復力システム基盤」とは？（１／２）

ハードウェア機器やネットワーク機器

ＯＳやミドルウェア

データ（ファイルシステム）

一般的なシステム基盤システム運用の仕組みや体制＋

製造EUC 物流会計分析販売

業務アプリケーション

高回復力システム基盤

電源、ネットワークサービス、設備・建物＋

業務データ

企業等の業務継続を支えるために必要な“レジリエンス”が確保されたシステム基盤＋α


「高回復力システム基盤」とは？（２／２）

大規模災害や大規模システム障害に対して情報システムが一定の強度を持つ（強度：情報システムを停止させないための対策が施されていること）

システムが停止した場合でも目標とする時間内に復旧できるように設計・構築されている

高回復力システム基盤

情報システムを停止させない対策

万一停止してしまった場合に迅速に復旧するための事前準備



システム運用の体制や仕組み

電源供給・ネットワークサービス

建物、設備

業務データ


システム基盤へのリスク

導入ガイドで対象とする脅威とリスク事象

脅威リスク事象

大規模災害

地震、水害、火災など

社会インフラ・施設・設備・機器・要員などが被災し、通常使用している情報処理施設での情報システムの提供が長期間できない状態

大規模システム

障害

ハードウェア障害、ネットワーク障害など

ハードウェアの故障やネットワークの切断が

発生し、通常使用しているハードウェアやネットワークでの情報システムの提供が長時間できない状態


リスク対応の基本的な考え方(1/2)

ITサービスを提供するに当たり必要な資源（構成要素）ごとに、リスク事象を想定

導入ガイドでは、想定したリスク事象に基づき、対応する基本的な考え方を解説

構成要素リスク事象基本的な考え方（抜粋・要約）

電源供給・ネットワークサービス

電力・通信・水道などが長時間利用不能となる

自家発電装置や貯水槽の設置、ライフライン供給経路の冗長化を図る。

建物，設備建物や設備など情報処理環境・基盤が損傷し、長時間利用不能となる

最低限として震度６弱の地震への耐震性を確保する。遠隔地にバックアップサイトを確保することを検討する。


ハードウェアが損傷し、長時間利用不能となる

ハードウェアの損傷，故障に備え、必要な範囲で代替機を持つ


リスク対応の基本的な考え方(2/2)

構成要素リスク事象基本的な考え方（抜粋・要約）


ハードディスクなどの損傷によりソフトウェアが消失し、長時間利用不能。

情報システムが復旧したときに、必要な状態で利用できるようバックアップを行う。遠隔地に保管する。

システム運用の体制や仕組み

運用する人材やスキルが不足。復旧対応において間違いが起こる。

必要な要員が確保できるように計画を策定する。必要な手順の文書化や訓練を行う。

ストレージなどに格納された業務アプリケーションや業務データ

ハードディスクなどの損傷により業務アプリケーションや業務データが消失し、長時間利用不能となる。

業務アプリケーション・業務データを必要な状態で利用できるよう、バックアップを行う。遠隔地に保管する。


事業継続戦略と情報システムの復旧目標

大規模災害や大規模システム障害により情報システムが停止した場合には，事業継続戦略に沿って復旧する．

災害などによって業務が中断した時点からいつまでに，どの程度で再開させるか，また，どの業務を優先させるかを決定．


高回復力システム基盤導入手順(1/2)

ActCheckDo

高回復力システム基盤を導入後，維持するプロセス

高回復力システム基盤を導入するプロセス

計画に従い，対策などを実施

リスクの変化や技術の進歩に対し，対策が適切に機能しているかどうかを評価

評価結果や組織の事業の状況などに合わせ，事業継続戦略や対策などを見直し

手順１手順２手順３手順４

検討対象の選定モデルシステムの選定要件定義導入計画策定

「高回復力システム基盤導入ガイド」で解説している導入手順

Plan

高回復力システム基盤の要件を決定

導入のための計画を策定

<参考> ITサービス継続ガイドライン（経済産業省 2012年5月改定）


高回復力システム基盤導入手順(2/2)

手順手順の概要

検討対象の選定

高回復力システム基盤の適用範囲を特定業務の重要性などに応じて対象とする業務システムやシステム基盤を選定

モデルシステムの選定

手順１で選定したシステム基盤について，適切な高回復力システム基盤のモデルを4つのモデルシステムから選択

要件定義選択したモデルシステムの要件を参照し，必要な調整を加えて、導入する高回復力システム基盤の要件を確定

導入計画の策定

手順３で定義した要件に基づく高回復力システム基盤を導入するための計画を策定

1. 検討対象の選定

2. モデルシステムの選定

3. 要件定義

4. 導入計画の策定

導入計画


凡例高回復力システム基盤の

導入ステップ高回復力システム基盤導入

ガイド（概要編）

2012年5月公開

高回復力システム基盤導入

ガイド（計画編）

2012年5月公開

高回復力システム基盤導入ガイド

（事例編）2012年7月公開

1. 検討対象の選定

2. “モデル”システムの選定

3. 要件定義（対策の選定）

4. 導入計画の策定

情報システムの導入計画

経営者が判断する（情報システム部門は支援）

情報システム部門が実施する（経営者は確認・承認）

高回復力システム基盤の導入ステップとガイド

経営者中心に幅広く

情報システム部門向け

高回復力システム基盤の必要性や導入方法の概要を紹介

対策となる高回復力システム基盤の要件を決定し導入計画を策定する手順を説明

文献調査やアンケート，インタビューの結果から有効な対策例を紹介


目次







3. 高レジリエンスに向けて（まとめに代えて）


ガイドの利用イメージ

モデルX

・・・・

・・・・

モデルを実現する対策（システム要件）を

リソース別に提示

モデル確定（経営層）

(情報システム部門) 自社の情報システムの導入や評価の際の参考として利用（情報システム部門）

高回復力システム基盤導入ガイド(概要編)

高回復力システム基盤導入ガイド(計画編)

業種業界により異なるシステム基盤に対する要求

要求対策レベル対応のモデルシステムの例示

投資額の概略見積り

(情報システム部門)情報システムの

現状把握(経営層)

モデル選定(経営層)

ステップ１

ステップ２ステップ３



高回復力システム基盤の適用範囲を決定するために明らかにすべき事項• 重要業務• その業務を支えるシステム基盤

重要業務を選定すると，その業務が利用する業務システムやそれが稼働するシステム基盤を検討対象にすることができる

ステップ１：検討対象の選定


高回復力システム基盤のモデル

モデル No 大規模システム障害時の回復要件大規模災害時の回復要件

１ 1 日から数日程度で復旧すれば，事

業の存続に影響が無い

比較的長期間を要しても，事業の存続

に致命的な影響が無い

２ 2 時間程度で復旧しなければ，業績

等に影響がある

比較的長期間を要しても，事業の存続

に致命的な影響が無い

３ 2 時間程度で復旧しなければ，業績

等に影響がある

１～７日程度で復旧しなければ，企業

の存続や業績に多大な影響がある

４ 2時間程度での復旧が社会的要請や

企業戦略上必要とされる

2 時間程度での復旧が社会的要請や企

業戦略上必要とされる

ITサービスの継続の取組みにおいては，一般的には、災害や障害が発生した場合の被害想定や事業への影響度分析を行い，業務における目標復旧時間等を決定し，それを実現するためにどのようなシステム基盤が必要かを検討するという手順を踏む．

しかし，業務の目標復旧時間がなかなか決まらない，目標復旧時間を達成するためのシステム基盤の設計後に，投資額が高いために目標復旧時間を再検討しなければならない等の弊害も生じている．

本ガイドでは，必要となるシステム基盤の強度や情報システムの復旧までの時間と，システム基盤構築のための投資規模から，高回復力システム基盤を4つのモデルに分類し，経営層等が組織の業務を支えるシステム基盤としてどのモデルが必要かを判断する．

ステップ２：モデルシステムの選定


高回復力システム基盤のモデルシステム（一覧）

モデルシステム

1 2 3 4

モデルシステムの特徴

➀ システム基盤の強度低中高高

② 復旧時間障害時 1～3日 2時間以内 2時間以内 2時間以内

災害時 1～6ヶ月 1～6ヶ月 1～7日 2時間以内

③ 投資規模低中高高

モデルシステム

の主要要件

➀バックアップ保有形態、取得間隔

非同期月次

非同期週次

非同期数回/日

非同期数回/時

② 機器などの冗長化なしありありあり

③ バックアップサイトなしなしありあり

(ホットスタンバイ)



高回復システム基盤のモデルの構成イメージ

モデル１（メインサイトのみ）

モデル3（バックアップサイト：ウォームスタンバイ）

モデル２（メインサイトのみ＋システム2重化）

モデル４（バックアップサイト：ホットスタンバイ）

本番システム

本番データ

メインサイト遠隔地

本番システム

本番データ

メインサイト

待機システム

本番データ

バックアップサイト

リアルタイムバックアップ

ホットスタンバイ

本番システム

本番データ

メインサイト遠隔地

本番システム

本番データ

本番システム

本番データ

メインサイトバックアップサイト

本番システム

本番データ

待機システム

本番データ

非同期バックアップ

ウォームスタンバイ

非同期バックアップ非同期バックアップ

モデルシステムにおいては，以下の３項目の組合せにより，システム基盤の強度や情報システム再開までの時間及び構築に必要となる投資規模が大きく異なる：① ソフトウェアやデータのバックアップの頻度や保有形態② 情報システムを構成する機器やネットワークの冗長化の有無③ 本番サイト被災時用のバックアップサイトの有無



高回復力システム基盤のモデルシステム（１）

モデル１（メインサイトのみ）

モデルシステム１の特徴

➀ システム基盤の強度低

②復旧時間

障害時 1～3日災害時 1～6ヶ月

③ 投資規模低

モデルシステムの主要要件

➀バックアップ形式，取得間隔

非同期月次

② 機器などの冗長化なし

③ バックアップサイトなし



高回復力システム基盤のモデルシステム（２）

モデルシステム２の特徴

➀ システム基盤の強度中

②復旧時間

障害時 2時間以内災害時 1～6ヶ月

③ 投資規模中


➀バックアップ形式、取得間隔

非同期週次

② 機器などの冗長化あり

③ バックアップサイトなし

モデル２（メインサイトのみ＋システム2重化）

※データの同期は，アプリケーションかストレージ，ＤＢＭＳ等の機能で行う．



高回復力システム基盤のモデルシステム（３）

モデルシステム３の特徴

➀ システム基盤の強度高

②復旧時間

障害時 2時間以内災害時 1～7日

③ 投資規模高



非同期数回/日


③ バックアップサイトあり

モデル３（バックアップサイト）



高回復力システム基盤のモデルシステム（４）

モデルシステム４の特徴

➀ システム基盤の強度高

②復旧時間

障害時 2時間以内災害時 2時間以内

③ 投資規模高



（非）同期数回/時


③ バックアップサイトあり(ホットスタンバイ)

モデル４（バックアップサイト：ホットスタンバイ）



ユーザ/ベンダ間で段階的に詳細化しながら非機能要求を確認するツール

段階① モデルシステムの選定：開発するシステムに最も近いモデルシステムを１つ選択

段階② 非機能要求項目のレベル決定

調整レベル36時間以内に復旧

レベル212時間以内に復旧

「社会的影響が限定されるシステム」における「目標復旧時間（RTO）」の例

要求を吟味し，レベル値を調整して決定

モデルシステムシート（グレード表）

Ａ．社会的影響が殆どないシステム

Ｂ．社会的影響が限定されるシステム

Ｃ．社会的影響が極めて大きいシステム

調整前（デフォルト）調整後

選択

グレード表・樹系図

モデルシステムシートを使用し開発システムに最も近いモデルシステムを選択

参考非機能要求グレード

大

項目

中

項目小項目メトリクス

レベル

０１２３４５

可用性

継続性

目標復旧水準（業務停止時）

RTO（目標復旧時間）

1営業日以上

1営業日以内

12時間以内

6時間以内2時間以内

RLO（目標復旧レベル）

システムの復旧

特定業務のみ

全ての業務例


非機能要求グレードを活用した要件選定ステップ３：要件定義

大項目

中項目

小項目メトリク

ス(指標)

レベル

0 1 2 3 4 5

可用性

対障害性

ストレージ

冗長化（機器）

非冗長構成

特定の機器のみ冗長化

全ての機器を冗長化

データバックアップ方式

バックアップ無し

オフラインバックアップ

オンラインバックアップ

オフラインバックアップ+オンラインバックアップ

災害対策

システム

復旧方針

復旧しない

限定された構成でシステムを再構築

同一の構成でシステムを再構築

限定された構成をDRサイトで構築

同一の構成をDRサイトで構築

非機能要求項目一覧（非機能要求グレード）

回復力に関わる項目を抽出したシートに，

モデル１モデル２モデル３モデル４

モデルとレベルを対応付けて提供

調整し，要件確定

…

ステップ２

ステップ３


要件定義のためのワークシート

要件定義作成者/更新者

作成日/更新日

0 1 2 3 4 5 1 2 3 4

A.1.2.2 サービス切替時間【要件】サービス切替時間とは、想定できる障害（例えばハードウェアの故障等により業務が

一時的中断するケースなど）に対して、対策を施すこと（例えばクラスタ構成でのサーバの切替えなど）により、業務再開までに要する時間を指す。

【運用コストへの影響】中断を許容する時間が長くなれば、復旧対策としてはシステムでの自動化から人員による手動での対処に比重が移るため、運用コストへの影響が出てくる。

24時間以上 24時間未満 2時間未満 60分未満 10分未満 60秒未満

A.1.2.3 業務継続の要求度【要件】

業務継続の要求度とは、発生する障害に対して、どこまで業務を継続させる必要があるかを示す考え方の尺度を示している。システムを構成する機器や部位には、単一障害点SPOF（Single Point Of Failure）

が多数存在し、システム停止となるリスクを多く含んでいる。これらのSPOFを許容するか、冗長化などの対策で継続性をどこまで確保するかが要求の分かれ目となる。

障害時の業

務停止を許容する

単一障害時

は業務停止を許容せず、処理を

継続させる

二重障害時

でもサービス切替時間の規定内で

継続する

A.2.5.1 冗長化（機器）【要件】NAS、iSCSI対応の装置を含む。

ただしNASやiSCSIはLANなどのネットワークに接続して利用するため、NASやiSCSIの接続環境の耐障害性対策は小項目A.2.4ネットワークに含まれる。

【レベル1】特定の機器のみとは、導入するストレージ装置に格納するデータの重要度に応じて、耐障害性の要求が装置毎に異なる場合を想定している。

非冗長構成➀

特定の機器のみ冗長化

全ての機器を冗長化

②③④

非冗長構成全ての機器を冗長化

← ←

A.2.5.2 冗長化（コンポーネ

ント）

【レベル1】

ストレージを構成するコンポーネントとして、ディスクを除く、CPUや電源、FAN、インターフェースなどを必要に応じて冗長化することを想定している。

非冗長構成特定のコン

ポーネントのみ冗長化➀②③④

全てのコン

ポーネントを冗長化

特定のコン

ポーネントのみ冗長化

← ← ←

A.2.6.1 バックアップ方式【重複項目】C.1.2.7。バックアップ方式は、バックアップ運用設計を行う上で考慮する必要があり、運用・保守性と重複項目としている。

【レベル】

オフラインバックアップとは、システム（あるいはその一部）を停止させてバックアップを行う方式、オンラインバックアップとはシステムを停止せず稼働中の状態でバックアップを行う方式を指す。

バックアップ無し

オフラインバックアップ➀②③

オンラインバックアップ④

オフラインバックアップ+オンライン

バックアップ

オフラインバックアップ

← ← オンラインバックアップOR オフラ

インバックアップ+オン

ラインバックアップ

A.2.6.3 データインテグリティ【要件】データに対して操作が正しく行えること、操作に対して期待した品質が得られること、

またデータへの変更が検知可能であることなどを物理レベルで保証する。

【レベル】仕組みの実装は、製品、業務アプリケーションによる検出を含む。

エラー検出無し

エラー検出のみ

エラー検出＆再試行

データの完全性を保障

（エラー検出＆訂正）

➀②③④

データの完全性を保障

（エラー検出＆訂正）

← ← ←

C.3.3.1 対応可能時間【要件】システムの異常検知時に保守員が作業対応を行う時間帯。

ベンダの営業時間内（例：9時～

17時）で対応を行う

➀

ユーザの指定する時間帯（例：18時

～24時）で対応を行う

②

24時間対応を行う③④

C.3.3.2 駆けつけ到着時間【要件】システムの異常を検出してから、指定された連絡先への通知、保守員が障害連絡を

受けて現地へ到着するまでの時間。

保守員の駆けつけ無し

保守員到着が異常検知

から数日中


からユーザの翌営業日中


からユーザの翌営業開始時まで

➀


から数時間内②③

保守員が常駐

④

C.5.5.1 一次対応役

割分担

一次対応のユーザ/ベンダの役割分

担、一次対応の対応時間、配備人数。

一次対応役割分担全てユーザ

が実施

一部ユーザ

が実施

全てベンダ

が実施

C.5.6.3 サポート要員

サポート体制に組み入れる要員の人数や対応時間、スキルレベルに関する項目。

ベンダ側対応者の要求スキルレベル

指定無し有識者の指導を受けて機器の操作

を実施できる

システムの構成を把握し、ログの収

集・確認が実施できる

システムの運用や保守作業手順に

習熟し、ハードウェア

やソフトウェアのメンテナンス作業

を実施できる

システムの開発や構築に携わり、

業務要件やユーザの事

情にも通じている

検討対象

ベース

備考項番大項目中項目小項目小項目説明要件備考レベルモデルシステム

要件内容

可用性継続性業務継続性可用性を保証するにあたり、要求される業務の範囲とその条件。

データデータの保護に対しての考え方。

耐障害性ストレージディスクアレイなどの外部記憶装置で発生する障害に対して、要求された

サービスを維持するための要求。

障害時運用システム異常検知時の対応

運用・保守性

サポート体

制

システムの異常を検知した際のベンダ側対応についての項目。

非機能要求項目一覧から高回復力要件に対応する37件を抽出

レベル参照部 : レベル毎の要件内容

モデルシステム参照部 : 各モデルシステムに既定の要件値

要件定義部 : 検討対象の要件等

検討対象の名称，概要，適用するモデルシステム等

要件定義の最終更新者氏名，最終更新日付

ステップ３：要件定義


事例一覧No. ID 業種最重要システム対策の特徴

モデルシステム1

1 製造業生産管理／顧客管理／財務・会計管理システム，メール・グループウェア等

・バックアップデータをメインサイトとは別の堅牢な建物の施錠キャビネット内に保管．

2 サービス業

メールシステム、顧客用開発システム（ファイルサーバ）等

・遠隔地にオンラインバックアップを実施．

3 地方公共団体

住民基幹系情報システム（住民記録・税・福祉）

・（東日本大震災で庁舎が津波により被災）遠隔地のバックアップデータで一部のデータを復旧．

モデルシステ

ム2

1 サービス業

Webサービス（情報提供），ブロガーを管理するプライベートSNS

・データセンタと本社を活用した遠隔地データバックアップを実施．

2 地方公共団体

住民情報系基幹システム・メインサイトは自設データセンタで冗長化，遠隔地バックアップを実施．

モデルシ

ステム3

1 その他契約者情報管理システム・阪神淡路大震災を契機に新規にシステムを構築し，同時に遠隔地にバックアップサイトを設置．

2 サービス業

ERP，メール・グループウェアシステム

・２箇所の民間データセンタを活用し，バックアップサイトを構築．クラウドサービスも活用．

モデル

システム4

1 サービス業

検査・認証情報データベース・サーバ仮想化技術採用し，遠隔にバックアップサイトを設置．・同期バックアップを行い，震災時にフェイルオーバーを実施．

2 金融・保険業

取引システム・システム障害対策のため，メインサイトは三重化を実施．

3 製造業製造・販売・管理システム，メール，CTIシステム等

・（水害によりサーバの水没を経験）仮想化技術採用し，遠隔地サイトに同期バックアップを実施．


モデルシステム1の事例（概要）

業種・組織概要業種サービス業業務内容主な事業内容は，エンジニアコンサルティング，システム開発，パッケージ販売．昨今では受託によるシステム開発事業の比重が高い．従業員数約600名検討対象の選定対象となるシステム基盤

重要業務・重要業務は，現BCPでは明確に定めていない．・結果的に，現状は基幹系のシステムは全て同じレベルで「重要」と位置付けられており，全てバックアップを行ってきた．これまでは，システム障害が発生する規模の災害は起こらなかったため，復旧の優先順位をつけるといった場面は発生しなかった．

・情報システム部門としては，社員とのコミュニケーション基盤の復旧が最重要だと考えている．次に，受託開発業務であり，開発中のソフトウェアを守る必要がある．

業務選定の理由

・当社の商品・サービスが社員の知識・ノウハウを形にして売る業種であることから考えると，被災時に顧客対応を早急に行うためには，社員とのコミュニケーション基盤の早期復旧が最重要だと考えている．また，開発中の顧客のシステムが保全されていないと事業が成り立たない．ただし，これは全社的な考えではなく情報システム部門としての考えである．

高回復力システム基盤構築の背景

経緯・遠隔地でのバックアップは，3年前のBCP策定時から行っている．バックアップは対策の中でも取り組みやすい部分であることから，ここから取り組み始めた．災害対策という観点だけでなく，開発中システムの障害対策としてもバックアップが必要であった．

投資額の決定，経営者の関与等

・情報システム部門が3業者から情報収集を行い，バックアップ方法や機器を選定．経営層の決裁を得て実施した．

対象システムの概要対象となるシステム基盤で稼働する業務の事業継続戦略(RTO等)

・ビジネスインパクト分析(BIA)を行っておらず，全社的な検討は行っていない．・情報システム部門としては，最優先に復旧すべきコミュニケーション基盤については，およそ以下の復旧が求められると考えている．[目標復旧時間（RTO）]

10～30分（システム障害時）、不明（災害時）［目標復旧レベル（RLO）］

障害・被災前より業務・機能を制限したレベル[目標復旧時点（RPO）]

障害・被災発生の直前まで復旧


バックアップサイト（九州の自社拠点）

システム

データ

メインサイト（関東地方の自社拠点）

インターネットVPN100Mb/s

・週次でバックアップ（毎日、分割してバックアップを実施）

バックアップデータ

・全重要システムは遠隔地データバックアップを実施．

・財務会計計管理システムは，開発環境を利用した待機系システムあり．

・建物の耐震強度震度６弱相当以上．

モデルシステム1の事例（構成）



業種・組織概要

業種地方公共団体

業務内容行政サービス等の地方自治業務

従業員数 5,000名強


対象となるシステム基盤

重要業務・住民窓口サービス（各種申請・届出等手続き、証明書発行業務等）


・全庁の震災時対応を想定したBCPにおいて「優先すべき通常業務」の一つとして窓口業務が定められている．・震災時対応を想定したIT-BCPでは，職員間のコミュニケーションや住民等への情報提供を重要業務としている．


経緯・従前は汎用機により運用していた住民情報系基幹システムについて，オープン化を実施した．・更改を検討していた当時の汎用機は，障害も少なく運用が安定していた．オープン化しても同等の可用性を確保できるよう，システムの冗長化等を実施した．


・情報システム所管課長を中心に情報システム所管課内で個々の案件について検討し，統括情報化責任者（政策経営部門長）が決定を行っている．

対象システムの概要

対象となるシステム基盤で稼働する業務の事業継続戦略(RTO等)

[目標復旧時間（RTO）]・システム障害では、規則等による定めはないが，4時間（半日）程度．業務時間内には復旧することが求められる．・災害時には，全庁BCPにおいて，2週間以内という目標復旧時間（RTO）が定められている．よって，住民情報系基幹システムも2週間以内に復旧することが求められる．・震災発生直後は，窓口業務に対する要求は少ない．しかし，2週間ぐらい経過した段階では，証明書発行等の要望が発生する．

[目標復旧レベル（RLO）]・規則等による定めはないが，通常時における処理能力の50%程度．

[目標復旧時点（RPO）]規則等による定めはないが，目標は障害発生時点．少なくとも前日の業務終了時点に復旧することが求められる．


システム待機系システム

データ

メインサイト（関東地方の自設拠点）

データ

・ホットスタンバイで冗長化．・建物の耐震強度震度６弱相当以上．

遠隔地（60ｋｍ以遠）

・住民基幹情報系については，媒体により遠隔地にバックアップを保管．

月次で媒体送付






業種その他

業務内容同一業界の複数企業が共同で利用するシステムの構築・運用等

従業員数約300名



重要業務・サービス利用者の契約者情報を管理するシステム．


・災害時に参照される情報を提供する業務であり，停止すると社会的影響が大きいことから，重要業務とした．


経緯・1995年の阪神・淡路大震災を機に当該システムに関連する業務の必要性を認識し，新規にシステムを構築した．その際，同時にバックアップサイトを構築した．


・費用は，システムを利用する各社が負担している．・方針の決定にあたっては，システムを利用している各社が構成員となっている委員会において実施している．



・目標は明確化していないが，大規模災害時にメインサイトが被害にあってもバックアップサイトで業務が継続できる必要があると考えている．



システム

メインサイト（近畿地方の商用データセンタ）

データ

データセンタ事業者の回線（100Mb/sの専用線）

日次でバックアップ

待機系システム


・建物の耐震強度震度7相当以上．・切替えはDNSの設定により、手動で実施．

・建物の耐震強度震度7相当以上．

サブサイト（関東地方の商用データセンタ）




業種サービス業

業務内容工業製品の品質，安全性検査や認証等

従業員数約300名



重要業務・最重要業務は，検査や認証等の管理業務である．・構築しているシステム基盤には，経理関係等の社内向けのシステムを除き，ほとんどの業務システムが搭載されている．


・ITディザスタリカバリー(DR)プランにおいて，システムの優先順位づけは決定されている．最も重要な業務は顧客への製品の認証に関する情報提供（オンラインのデータベースサービス）である．この情報がないと，お客様は製品の生産や販売することができない．止めることが許されないサービスである．

・検査や認証情報等の提供については，顧客とSLAを設定して契約している．当社としても，SLAを遵守しペナルティが発生しないよう，検査や認証等の管理業務の復旧優先順位は確実に高く保つ必要がある．


経緯・コスト，予算，顧客の要望等種々の要因はあるが，サーバ統合・集約化プロジェクトのスタートが契機となり，あわせてシステムの復旧対策を実現した．

・構築のために相当のコストがかかったが，運用コストは削減された．現在の運用要員人数は，メインサイトとバックアップサイトの拠点に各1名である．以前は各拠点に分散していたので，運用要員が5～6人必要であった．あわせて，サーバ台数も縮減できた．


・ITサービスの対策レベルは，当該業務で確保できる予算規模で決定される．業務の優先順位を社長が決定することは基本的にはないが，予算配分を決定する際に，結果的に社長とCFOが判断することはある．

・バックアップサイトの投資額については，震災発生当時のバックアップサイトの構築には，本社のサイトを１.0とすると0.3ほどの費用が発生した．



・目標復旧時間(RTO)は，最も高水準のサービスで5分である．・個々の顧客との契約（SLA）に応じて，契約単位で目標復旧時間(RTO)を設定している．・目標復旧時間(RTO)を5分より短くすると，大幅に費用（投資費用とそれに見合う顧客に請求する料金）が増加するため現実的ではないと判断し，最も高水準のもので５分と設定した．

・目標復旧レベル(RLO)，目標復旧時点(RPO)は設定していない．・このような内容は，社長は直接判断に関与しない．IT部門は，業務部門からの要求に基づいて対策を検討し，予算の範囲内で対応する．



バックアップサイト（100km以遠のデータセンタ）

システム

待機系システ

ム

データ

メインサイト（関東地方の自社拠点）

データ

専用線100Mb/s

・重要なものは最短5分間隔でデータ同期

・仮想化技術を利用し、ストレージベースのレプリケーションにより最短5分でフェイルオーバー可能





・メインサイトと同一の構成．・非常時にはバックアップサイト側からフェイルオーバー実施が可能．

・仮想化技術を導入．・高可用性構成．・建物の耐震強度震度６相当．・ストレージ二重化．

インターネットVPN（レプリケーション）


クラウドコンピューティングの活用

主な考慮事項

• コスト（運用、移行）

• セキュリティ

• 提供機能

サーバの外部管理方法

1. データセンターへのハウジング（移設）

2. サーバホスティング・サービス

3. クラウドコンピューティング・サービス（IaaS等）

⇒総合的な評価に基づいて判断

データバックアップ時の転送コスト？

障害発生時の切替え/回復後の切り戻し？


継続的な導入評価を

重要度/コストの評価は相対的

ビジネスの状況/技術の進展により評価結果は変わる

→適宜、見直し要

「災害対策と節電で飯は食えない」（日経BP社・谷島宣之氏）

「高回復力システム基盤導入ガイド」

が役立ちます．

But, . . .


ガイドはWebサイトで公開中




参考資料


ITサービス継続ガイドライン（経済産業省 2012年5月改定）

※ 経済産業省 ITサービス継続ガイドラインの「4. ITサービス継続マネジメント」のマネジメント体制の枠組み

4.2 ITサービス継続戦略（計画段階）

4.3 ITサービス継続計画（計画段階）

4.4 ITサービス継続体制の実装・運用・維持（実行段階）

4.5 ITサービスの継続体制の監査（評価・改善段階）

継続的改善

高回復力システム基盤導入ガイド（概要編）

2012年5月公開

高回復力システム基盤導入ガイド（計画編）

2012年5月公開

高回復力システム基盤導入ガイド（事例編）

2012年7月公開

参考

随時調整しつつ作成し，相互参照

「ITサービス継続ガイドライン」（ＭＥＴＩ）との関係


高回復力システム基盤の構成要素

改善や追加の対策

業務データ・業務アプリケーション(ソフトウェア）

遠隔地バックアップさらに，リアルタイムバックアップ

情報処理施設の代替バックアップサイトの所在地の見直しクラウドコンピューティングの利用

システム運用の体制や仕組み復旧の手順書の充実

ハードウェア機器やネットワーク機器や通信・電力等のサービス

システムの重要度と停止許容時間をもとにした冗長化の必要性の検討通信等のサービスが停止したときの事業継続方法の検討

参考高回復力システム基盤の構成要素についての対策

enhancement cente r information-technology …...2013/12/11 · enhancement cente r...

Documents