SEC - IPASEC Software Engineering for Mo･No･Zu･Ku･Ri Software Engineering Center...

Software Engineering Center

Information-technology Promotion Agency, Japan


安心を築く、高いレジリエンスによるITサービスの継続

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

独立行政法人情報処理推進機構(IPA) 技術本部ソフトウェア・エンジニアリング・センター(SEC)

山下博之

エンタプライズ系総合セミナー第2日：「ITサービスを取り巻く環境と要求」

2013年3月5日

SEC Software Engineering for Mo･No･Zu･Ku･Ri


プロローグ（１／２）

エンタプライズ系総合セミナー, 2013-03-05 Copyright © 2012-2013 IPA, All Rights Reserved. 2

自分の居住/勤務地域で，近いうちに，

地震や火山噴火などの自然災害が発生するかもしれない

と思いますか？

自分自身がよく利用する／自分の会社が提供する

サービスが，システム障害により停止することが

向こう1年以内にあると思いますか？

一生のうちで，自分自身が交通事故に遭うかもしれない



Software Engineering Center エンタプライズ系総合セミナー, 2013-03-05 Copyright © 2012-2013 IPA, All Rights Reserved. 3

全国地震動予測地図２０１０年版 http://www.jishin.go.jp/main/chousa/10_yosokuchizu/k_sanko.pdf

参考確率の数値を受け止める上での参考情報



プロローグ（２／２）


発生確率より，（発生時の）影響の大きさが問題では？

自分自身/自分の会社が被災する（大きな被害を受ける）


自分（自社）だけは交通事故に遭わない，被害がない，

自然災害や事故が起こっても，自分（自社）だけは助かる，

と（何の根拠も無しに）思っていませんか？

人の性：「自分だけは大丈夫」と思う … 正常化の偏見※

※ 人はなぜ「自分は大丈夫」と思うのか，防災研究家の片田群馬大学教授に聞く，ITpro 2007/04/11 http://itpro.nikkeibp.co.jp/article/Interview/20070409/267753/



目次


1. 「安心できるサービス」とは？

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

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

（１）背景と目的

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

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

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

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



「安心できるサービス」とは？


「安心できるサービス」の条件

1. 基本的な信頼感（期待通りの結果）がある

2. （環境が変わっても）継続して使い続けられる

（事業/サービスの）「サステナビリティ」（持続可能性）



環境の変化と，変化への対応


変化への対応

アーキテクチャ

アルゴリズム

エンジニアリング

オペレーション

マネジメント

環境の変化

急激 →発生時対策の事前計画

緩やか →早期予測と俊敏な対応

アーキテクチャアルゴリズムエンジニアリン

グオペレーションマネジメント

基本的信頼性

○誤操作レスUI

○各種SE技法

○通常運用 ○開発プロジェクト管理

環境変化対応

急激 ○冗長構成 ○リカバリ ○バックアップ

・復旧作業 ○事前計画

緩やか ○拡張容易性 ○拡張容易性 ○俊敏開発 ○変化予測 ○柔軟化(*)

(*) 平成22年度経済産業省委託調査：「IT経営普及促進に向けた調査研究」報告書，社団法人日本情報システム・ユーザー協会，平成23年2月． http://www.meti.go.jp/meti_lib/report/2011fy/0022948.pdf



レジリエンス


システム障害や災害等，急激な環境変化に対しても，

事業の持続可能性（サステナビリティ）を確保するために，

ITシステム（サービス）として準備しておくこととその方法

レジリエンス（柔軟な回復力）



情報システム基盤の復旧に関する対策の調査


報告書 http://sec.ipa.go.jp/reports/20120725.html

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

＜サマリ＞

・BCP（事業継続計画）/IT-BCP（ITの事業継続計画）の対策はあまり進んでいない．

・IT-BCPの対策は立てても，教育訓練や見直しがされていない．

・システム障害は想定しているが，災害では津波や竜巻などは想定していない．

・大企業ほどIT-BCPの取組みが進んでいる

・復旧目標と対策が矛盾している場合もある．



BCPを策定して

いる10.4%

BCPを知ってい

るが、策定して

いない

50.8%

BCPを知らない

24.8%

わからない

13.9%

n=10,713

BCPの策定状況


○調査対象：・2011年4月調査：TDB景気動向調査登録企業22,240社、回答10,769社・2012年2月調査：TDB景気動向調査登録企業23,651社、回答10,713社

7.8%

10.4%

21.5%

30.9%

6.5%

8.6%

29.2%

50.8%

31.4%

45%

29.1%

51.4%

0% 20% 40% 60% 80%

2011年4月調査

2012年2月調査

2011年4月調査

2012年2月調査

2011年4月調査

2012年2月調査

全体

大企

業中

小企

業

BCPを策定している BCPを知っているが、策定していない

<出典> （※1）帝国データバンク「BCP(事業継続計画)についての企業の意識調査」(2012年3月) （掲載URL：http://www.tdb.co.jp/report/watching/press/p120308.html）（※2）IPA/SEC「情報システム基盤の復旧に関する対策の調査報告書」（2012年7月25日）（掲載URL：http://sec.ipa.go.jp/reports/20120725.html）

東日本大震災を経て，・BCPの認知率は増加・実際の策定企業は微増・中小企業では， BCP策定済みは少数

N=10,713

（※1）

（※2）

http://www.tdb.co.jp/report/watching/press/p120308.html





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

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



図：DR計画の策定状況

<参考記事>

日本の中小企業、災害復旧計画策定はわずか2割--最多理由は「必要性がない」田中好伸（編集部） 2012年06月13日 http://japan.zdnet.com/it-management/analysis/35018127/

DR計画の策定状況（世界と日本の比較）


出典: シマンテック2012年版中小規模企業を対象とした災害対策調査http://www.symantec.com/content/ja/jp/about/download/news_release/20120613/2012DisasterPrepar

ednessTopicalSurvey-Global_vs_Japan.pdf

無計画でも何とかなる？ ↑



DR（災害復旧）対策予算の状況


国内企業のDR（災害復旧）対策予算は大企業中心に増加傾向

出典： IDC Japanプレスリリース「国内企業のデータ保護／DR対策の分析とクラウドサービスへの移行に関する調査結果を発表」（2012年6月5日）

増加横ばい

減少



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


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.維持改善計画を策定

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

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

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

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



ビジネス上の重要度に応じたデータのクラス分け


Figure 11. Classification of Primary Data, by Business Value

Of your immediate organization’s total amount of primary data, please indicate the approximate

breakout of that data as outlined below. (Mean, N=510)

Source: 2010 Data Protection Trends Executive Summary, Enterprise Strategy Group, 2010.

http://www.esg-global.com/research-reports/research-report-2010-data-protection-trends/

ESG のクラス分け例

Tier-3 (24%) 通常はアーカイブされたデータパフォーマンスはそれほど重視されないが，データの取り出しが可能であることが必要

Tier-2 (28%) 良好なパフォーマンス及び信頼性が求められるデータ及びアプリケーションだが，ミッションクリティカルレベルではないデータ重要性の低いアプリケーションデータと古いミッションクリティカルデータの混在が含まれる

・ Tier-1 (48%) 可用性及びパフォーマンスの両面で要件が最も厳しいミッションクリティカルなデータ及びアプリケーション

→それぞれの階層のアプリケーションやデータごとにリスクを査定



停止時間に対する許容度


<出典> 市場レポート：システムレベルの保護でデータバックアップおよびリカバリを補完, By Lauren Whitehouse, 2011年3月, Enterprise Strategy Group (ESG).

（回答者：北米の従業員数100～999人の中規模企業，N=206，2010年調査）

データの重要度に応じ，停止時間に対する許容度は異なる

ESG の調査

・中規模企業の過半数（52%）がミッションクリティカルなデータ（Tier-1）に関して耐えられる停止時間は、わずか 1 時間

・次のやや重要なデータ（Tier-2）に関して、約半数（49%）は 3 時間以下の停止に耐えられる

・その他のデータ（Tier-3）に関しては、43% が 9 時間まで耐えられる



リカバリ要件設定の有無


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）とシステム冗長化の状況


事業継続性確保のためには，ITサービス継続戦略と対策の整合性の確保が重要

<出典> 「情報システム基盤の復旧に関する対策の調査」報告書，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.その他



中小企業におけるバックアップの意識（１／３）


Q1 現在、運用しているのは、下記のうちどれですか？（複数回答可）

中小企業の業務継続は，業務の要であるファイルを守ること

<出典> 2011年シマンテック中堅中小IT担当者400人への意識実態調査

中小企業におけるバックアップの意識はどのように変わったのか， 2011年9月にZDNet Japanで実施したオンラインアンケート（総回答421件から抽出した従業員数1000名未満の285件）



中小企業におけるバックアップの意識（２／３）


Q4 バックアップやシステム復旧の重要性を，震災前より意識するようになりましたか？





中小企業におけるバックアップの意識（３／３）


Q5 Q4で「意識が強まった」と回答した方に，具体的にどんなアクションをとりましたか。（複数回答可／任意）





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


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）


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



最近の状況（１／２）


<出典> JUAS: 「企業IT動向調査2013」調査結果速報プレスリリース第２弾，2013年2月13日 http://www.juas.or.jp/servey/it13/it13_BCP.pdf

2012年10月29日～11月19日，東証一部上場企業とそれに準じる企業の計4000社を対象．

想定リスク別BCP策定状況

http://www.juas.or.jp/servey/it13/it13_BCP.pdf



最近の状況（２／２）


1年前と比較し，全ての想定リスクにおいてBCPの「策定済み」企業の割合が増加．特に伸びたのが，「システム障害」（13.3ポイント増），「電力・通信等の社会インフラの停止」（13.3ポイント増），「自然災害（津波による被害）」（12.6ポイント増）．

BCP「策定済み」企業の割合の変化（対前年比）



背景

エンタプライズ系総合セミナー, 2013-03-05 31

東日本大震災により、社会や企業を支える情報通信や情報システムの

停止、データの喪失等により長期にわたって業務停止に追い込まれた

地方公共団体や企業があった。

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

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

震災を契機に企業等の中で事業継続への意識は高まっているが、従来

の指針が難解で、未だ具体的な対策の着手に至っていないのが現状。

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

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

東日本大震災による情報システムの被災状況を調査し、教訓や復旧に

活用された新しい技術やサービスの事例等を紹介

Copyright © 2012-2013 IPA, All Rights Reserved.

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



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


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

ＯＳやミドルウェア

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

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

製造 EUC 物流会計分析販売

業務アプリケーション

高回復力システム基盤

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

業務データ

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



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

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

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

高回復力システム基盤

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

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



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

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

建物、設備

業務データ

エンタプライズ系総合セミナー, 2013-03-05 33 Copyright © 2012-2013 IPA, All Rights Reserved.



システム基盤へのリスク

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

脅威リスク事象

大規模災害

地震，水害，火災など

社会インフラ，施設，設備，機器，要員などが被災し，通常使用している情報処理

施設での情報システムの提供が長期間できない状態

大規模システム

障害

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

ハードウェアの故障やネットワークの切断が発生し，通常使用しているハードウェアやネットワークでの情報システムの提供が

長時間できない状態

エンタプライズ系総合セミナー, 2013-03-05 Copyright © 2012-2013 IPA, All Rights Reserved.



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

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

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

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

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

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

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

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

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


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

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




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

36

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


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

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

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

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

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

ハードディスクなどに格納された業務アプリケーション・業務データ

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

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




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

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

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




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

Act Check Do

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

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

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

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

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

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

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

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

Plan

高回復力システム基盤の要件を決定導入のための計画を策定

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




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

手順手順の概要

検討対象の選定

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

モデルシステムの選定

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

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

導入計画の策定

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

1. 検討対象の選定

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

3. 要件定義

4. 導入計画の策定

導入計画


注) モデルシステム：代表的なシステムのパターン（後に説明）



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

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

ガイド（概要編）

2012年 5月公開

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

ガイド（計画編）

2012年 5月公開

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

（事例編） 2012年7月公開

1. 検討対象の選定

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

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

4. 導入計画の策定

情報システムの導入計画

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

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

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

経営者中心に幅広く

情報システム部門向け

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

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

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




ガイドの利用イメージ


モデル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時間以内

③ 投資規模高



非同期数回/時


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

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





ユーザ/ベンダ間で段階的に詳細化しながら非機能要求を確認するツール段階① モデルシステムの選定：開発するシステムに最も近いモデルシステムを１つ選択

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

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

レベル2 12時間以内に復旧

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

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

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

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

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

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

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

選択

グレード表・樹系図

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

参考非機能要求グレード


大

項目

中

項目小項目メトリクス

レベル

０１２３４５

可用性

継続性

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

RTO（目標復旧時間）

1営業日以上

1営業日以内

12時間以内

6時間以内 2時間以内

RLO（目標復旧レベル）

システムの復旧

特定業務のみ

全ての業務例

52



非機能要求グレードを活用した要件選定


ステップ３：要件定義

大項目

中項目

小項目メトリク

ス (指標)

レベル

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件を抽出

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

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

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

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

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


ステップ３：要件定義



調査対象システムの高回復力レベル（モデル）

エンタプライズ系総合セミナー, 2013-03-05 56

34.9%

32.6%

26.4%

6.2%

モデルシステム1




№ カテゴリ件数 % 1 モデルシステム1 45 34.9% 2 モデルシステム2 42 32.6% 3 モデルシステム3 34 26.4% 4 モデルシステム4 8 6.2% 129

＜遠隔地でのデータバックアップを実施している企業のガイドにおけるモデルシステムとの対応状況＞

Copyright © 2012-2013 IPA, All Rights Reserved.



事例一覧


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）] 障害・被災発生の直前まで復旧



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

システム

データ

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

インターネットVPN 100Mb/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, . . .



安心を築くために


1. 基本的な信頼感（期待通りの結果）がある

2. （環境が変わっても）継続して使い続けられる

再び，「安心できるサービス」とは？

信頼感→主にベンダが頑張る

安心感→主にユーザが頑張る

同業仲間や業界で助け合うことも重要（例：困った時にシステムを貸す） → データ保持が前提事が起きた後に状況を見極め，臨機応変の回復計画を，オンデマンドで

策定・実施 → 見識と行動力



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


http://www.ipa.go.jp/about/press/20120508_2.html

http://www.ipa.go.jp/about/press/20120725.html

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

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



IPA/SECホームページ： http://sec.ipa.go.jp/index.html

ご清聴，ありがとうございました




関連記事


IPA「災害に対応する IT システム検討プロジェクトチーム」の活動結果について報告

～東日本大震災による情報処理の現場の状況と復旧対応について～

2013年1月28日独立行政法人情報処理推進機構

http://www.ipa.go.jp/about/press/20130128_2.html

進まないIT-BCPの現状と策定までの道筋

キーマンズネット，2013年2月19日

http://www.keyman.or.jp/at/sec/other/30005298/

システム障害対策と災害対策の実態

日経SYSTEMS，2012年11月



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サービス継続ガイドライン」（ＭＥＴＩ）との関係



ITサービス継続戦略（4.2）

ITサービス継続戦略（4.2）

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

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

ITサービス継続体制の実装・運用・維持

（4.4.1）

ITサービス継続体制の実装・運用・維持

（4.4.1）

ITサービス継続体制の監査（4.4.2）

ITサービス継続体制の監査（4.4.2）

その他規程類その他規程類

継続的改善

業務のIT依存度分析（4.2.1）

業務のIT依存度分析（4.2.1）

リスク評価結果（4.2.3）

リスク評価結果（4.2.3）

全社BCP全社BCP

技術的対策運用的対策（5.）

技術的対策運用的対策（5.）

教育訓練記録（受講記録）

教育訓練記録（受講記録）テスト結果報告テスト結果報告

監査報告監査報告

ITサービス継続の

要件定義（4.2.2）

ITサービス継続の

要件定義（4.2.2）

ITサービス継続戦略※

（4.2.4）

ITサービス継続戦略※

（4.2.4）

ITサービス継続計画（4.3.2）

ITサービス継続計画（4.3.2）

技術的対策実績運用的対策実績

技術的対策実績運用的対策実績

※費用の明確化を含む

図 4.1-1 ITサービス継続マネジメントのフレームワーク

ITサービス継続ガイドライン改訂案，平成24年5月，経済産業省． http://www.meti.go.jp/policy/netsecurity/docs/secgov/2011_IoformationSecurityServiceManagementGuidelineKaiteiban.pdf

付録 ITサービス継続マネジメントのフレームワーク



③-1・重要業務の調査(重要度)

・提供サービスの重要性の調査

ＩＴサービス継続計画チーム＝［情報システム部門］＋[事業部門システム担当〕

フェーズ１

調査・分析

フェーズ２

計画立案・策定

③-2 システム状況の調査（業務システム、マシンルーム）

全社ＢＣＰチーム＝［経営・業務・事業部門］

⑧-2 ＩＴサービス継続計画の策定(IT関連）

⑨ BCＰの策定(全体見直し）

④ 重要業務とシステムの調査結果統合

② 「主要業務洗い出し」と「調査対象業務の絞込み」

⑥-1 対応策の整理（部門対応の課題）

⑧-1 BCＰの策定(部門関連）

情報システム対策の実施については、各事業部との調

整が必要

① プロジェクトの立上げ

⑥-2 対応策の整理（ﾘｿｰｽ確保、復旧手順）

⑦ 基本的な計画方針の策定

⑤ 対策方針の整理

図 4.2-3 全社BCP＆ITサービス継続計画の連携例


付録全社BCP＆ITサービス継続計画の連携例



ITサービス継続計画

事前準備計画事後対応計画（緊急時対応計画）

対策実施計画教育訓練計画維持改善計画

図4.3-1 ITサービス継続計画の構造


付録 ITサービス継続計画の構造



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

レベル0 非冗長構成

レベル1 特定のサーバで冗長化

レベル2 すべてのサーバで冗長化

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

段階② 非機能要求のうち重要項目のレベル決定：樹系図で全体を俯瞰し、グレード表でレベル値を決定

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

レベル2 12時間以内に復旧

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

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

冗長化（機器）

・・・

耐障害性

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

段階③ 重要項目以外のレベル決定：項目一覧で非機能要求項目の要求レベル値を決定

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

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

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

「可用性」の重要項目以外の非機能要求項目を検討する例

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

選択

サーバ

中項目小項目メトリクス（指標）

・・・

・・・

選択

グレード表・樹系図

項目一覧・樹系図災害対策システム復旧方針

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

高

低

付録非機能要求グレード（１／３）




レベルによる非機能要求項目の共通認識メトリクス毎に実現上必要となるコストや実装上のアーキテクチャの難易度が大

きく変わるポイントで『レベル』を設定。

レベル０からレベル５までの６段階で設定。レベル値が大きいほど実現難易度は高くなり、一般に開発コストは増加。

レベルで示す値はユーザ／ベンダ間で合意形成を図る出発点とし、最終的に具体的な数値として合意することを想定。

大項目中項目小項目メトリクスレベル

０１２３４５

可用性継続性業務継続性

（可能性を保証するにあたり、要求される業務の範囲とその条件）

対象業務範囲

内部向けバッチ系業務

内部向けオンライン系業務

内部向け全業務

外部向けバッチ系業務

外部向けオンライン系業務

全ての業務

サービス切替時間

２４時間以上

２４時間未満

２時間未満

６０分未満

１０分未満

６０秒未満

業務継続の要求度

障害時の業務停止を許容する。

単一障害時は業務停止を許容せずに処理を継続させる

二重障害時でもサービス切替時間の規定内で業務継続

レベルの例非機能要求を提示しやすいユーザ

ベンダ非機能要求を確認しやすい

付録非機能要求グレード（２／３）




「重要項目」の要求レベルの設定例を用いて、より「早期に」判断

「重要」な非機能要求項目（抜粋）要求レベルの設定例

重要項目例メトリクス(指標) レベル選択時の条件

業務継続性ｻｰﾋﾞｽ切替時間 3 60分未満

目標復旧水準 RTO(目標復旧時間) 2 12時間以内

稼働率稼働率 4 99.99%

大規模災害時ｼｽﾃﾑ再開目標 3 1週間以内

業務処理量同時ｱｸｾｽ数 1 上限が決まっている

ﾊﾞｯﾁ処理件数 0 件数が決まっている

業務量増大度ｵﾝﾗｲﾝ件数増大率 1 1.2倍

ｵﾝﾗｲﾝﾚｽﾎﾟﾝｽ通常時ﾚｽﾎﾟﾝｽ順守率 3 90%

運用時間運用時間(通常) 4 若干の停止有り

内部統制対応対応実施有無 1 既存の社内規定での対応実施

移行ｽｹｼﾞｭｰﾙｼｽﾃﾑ停止可能日時 4 夜間など

ｾｷｭﾘﾃｨﾘｽｸ分析ﾘｽｸ分析範囲 1 重要資産

地域的広がり地域的広がり 0 拠点内

（１）重要項目毎に、該当モデルにおける標準レベルを選択した条件を示す。（２）レベルを調整する際の条件を示す。

レベルダウン夜間停止：夜間要員不要

レベルアップ順守率：95%以上

レベルアップ復旧時間：6時間以内

仮決め稼働率：後日最終決定

付録非機能要求グレード（３／３）


SEC - IPASEC Software Engineering for Mo･No･Zu･Ku･Ri Software Engineering Center...

Documents

Transcript of SEC - IPASEC Software Engineering for Mo･No･Zu･Ku･Ri Software Engineering Center...