Comments
Description
Transcript
システム障害事例情報の分析に基づく 教訓・対策を共有する仕組み
一般財団法人関西情報センター(KIIS)主催 独立行政法人情報処理推進機構(IPA)共催 ビジネスイノベーションセミナー システム障害事例情報の分析に基づく 教訓・対策を共有する仕組み ～智の共有が安心・安全社会を創る～ 重要インフラセキュリティセミナー 2014年12月4日 独立行政法人情報処理推進機構（ＩＰＡ） 技術本部 ソフトウェア高信頼化センター（ＳＥＣ） 山下 博之 Information-technology Promotion Agency, Japan Software Reliability Enhancement Center (SEC) Copyright © 2013-2014 IPA, All Rights Reserved Software Reliability Enhancement Center プロローグ Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 2 背景 背景１ ソフトウェアは，それ自身，複雑化・大規模化し， システム間連携により，複雑化は一層進展 停止・異常動作等のリスクの増大 ∵ 市民生活や社会経済活動がＩＴシステムに大きく依存 Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 3 データ例 増大するソフトウェアの複雑性 情報処理システ ムのソフトウェ アは，製品・ サービスの多様 化・高度化に伴 う複雑化，大規 模化等が進展 コード量（ＬＯＣ） （ × 100万LOC） Microsoft Windows 成長の足あと 45 40 35 30 25 20 15 10 5 0 Ｗｉｎ 3.1 (1990) Ｗｉｎ NT (1995) Ｗｉｎ 95 (1997) Copyright © 2013-2014 IPA, All Rights Reserved Ｗｉｎ NT4.0 (1998) Ｗｉｎ 98 (1999) KIISセミナー Ｗｉｎ NT5.0 (2000) Ｗｉｎ 2000 (2001) Ｗｉｎ XP (2002) （データ出所 EXPLOITING “How to Break Code” by Greg Hoglund/Gary McGraw) Software Reliability Enhancement Center 4 データ例 重要インフラ間の相互依存 重要インフラは 相互に依存し， システム間の ネットワーク連 携による複雑化 が一層進展 相互依存の事例 （災害時） <出典> 片岡正次郎，鶴田舞，小路泰広：重要インフラ間の相互依存構造のモデル化と地震被害波及シ ミュレーション，国総研資料 第 510 号，国土技術政策総合研究所（国総研），平成21年2月．P73 http://www.nilim.go.jp/lab/bcg/siryou/tnn/tnn0510.htm Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 5 背景 背景２ ひとたびシステム障害が発生した場合， 社会に及ぼす影響範囲は拡く，その深刻度も大きい Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 6 データ例 ＩＴ障害を引き起こす脅威（要因） IT障害を引き起こす脅威（要因）としては，意図的要因（情報セキュリ ティ関連）と非意図的要因（システム障害関連），災害等がある． ここでの注目 <出典> NISC: 重要インフラの情報セキュ リティ対策に係る第２次行動計画 Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 7 データ例 システム障害の３大原因 システム障害の３大原因として，ハードウェア障害，ヒューマンエラー，ソフトウェア 障害を挙げ，これらはコンピュータウィルスを上回るものとなっているとの報告あり． 個々の事業者等の単独の対策のみでは大規模・複雑化するシステムの障害対応に 限界があり，業種や分野を超えた連携が必要． システム停止に至る障害の3大原因 ソフトウェア障害と ヒューマンエラーを 合わせて，4割超 <出典> 日常でも、いざという時にも役立つバックアップとは？，ITmedia，2013.3.28 http://www.itmedia.co.jp/enterprise/articles/1303/28/news003.html Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 8 データ例 グローバル・リスク 財政危機 大 ← 重要インフラの ITシステム障害 生物多様性 損失と 生態系崩壊 水危機 気候変動 失業・不完全雇用 受容できないリスク 異常気象 影 響 度 所得格差 サイバー攻撃 影 響 度 リスクの低減 発生確率 受容できるリスク 発生確率 → 大 Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー <出典> Global Risks 2014 Ninth Edition, the World Economic Forum Figure 1.1: The Global Risks Landscape 2014 Software Reliability Enhancement Center 9 データ例 過去の情報処理システムの障害事例 ひとたびシステム障害が発生した場合， 社会に及ぼす影響範囲が拡大し，その深刻度も増大 過 去 の 事 故 事 例 （ ソ フ ト ウ ェ ア 起 因 ） 人身事故 経済事故 Therac-25による放射線過剰被爆事故（1985～87年） エアバスA320の墜落事故（1988～93年） 名古屋空港で中華航空機が着陸に失敗炎上（1994年） 携帯情報端末の発熱－実はソフトの不具合（2009年） 電子カルテシステムの不具合（2010年） 新幹線運行管理システムの障害（2008年，2011年） 銀行オンラインシステムの障害（2011年） 株式売買システムの障害（2012年） レンタルサーバーのデータ消失（2012年） Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 10 背景 背景３ システム障害の発生は，近年，増加傾向 Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 11 データ例 情報処理システム障害の発生状況 社会に大きな影響を与えた システム障害の発生件数 2009年以降で増加傾向 件 多大な影響を与えたITサービス障害の 発生件数（報道ベース）の推移 60 50 新聞やテレビなどのメディアでは， 幾度となく以下のようなニュースが 世間を賑わせている： 40 30 20 ・△△でリコール、国内で数十万台 …理由は、制御プログラムに不具合が発見された 10 ためという。 ・○○システムで障害か、終日つながりにくく 0 …原因は、法律改正直前の駆け込み需要と期末の 締め処理とが重なり、想定外の大量入力にシステ ムの性能が耐えられなかった模様。 ・□□システムで障害、午前中のサービス停止 …原因は、システムは本番装置の故障により予備 装置に自動的に切り替わるようになっていたが、 その切替えが失敗したためという。 Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー (出典) SEC Journal 情報システムの障害状況 類似障害の発生 Software Reliability Enhancement Center 12 データ例 類似障害の発生状況 ◆処理量の増大・環境変化に対する対処遅れ 1. みずほ銀行の障害…2011.3.15～3.24 東日本大震災義援金の受付けが携帯電話を利用した送金サービスの口座に集中し，その処 理を行う夜間バッチの件数が上限を超えたことをきっかけに，事後対応のまずさもあり，長期間 にわたりサービス停止の事態に． 2. アフラックの障害…2013.4.4 一部の保険料金が4月から上がるのに伴い，3月末に駆込みの契約が増えたために処理量が 増大し，夜間バッチが想定の時間内に終了しなかった可能性大． 3. NTTドコモの障害…2011.8.16, 2011.12.20 スマートフォンの急激な普及により通信の質が変化すると共に量も増大し，設備の容量を超え たために，通信しにくい状況に．このことが別の障害も誘発． 4. KDDI（ａｕ）の障害…2013.4.16～18 スマートフォンによるメールの送受信等が使用できない状況が断続的に発生したが，利用の急 増に対応するための設備増強の遅れが根本原因と報道されている．(4/18 日経電子版) ◆二重化システムにおける待機系への切替え失敗 日本生命（2014.4.7），JR九州（2013.7.18），KDDI（2013.4.16），東京証券取引所 (2012.2, 2012.8)，富士通データセンター(2012.6)，住信SBIネット銀行（2011.9），気象 業務支援センター(2009.3)，NTT東日本(2008.11)，JR東日本(2008.9) Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 13 背景 背景４ 情報処理システムの信頼性向上のために， システム運用時の様々なリスクへの対応が必要 Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 14 データ例 情報処理システムの信頼性向上 システムの 構築時→初期リスク（故障）回避 ソフトウェア・エンジニアリング技法の活用 はるかに長期間 システムの 運用時→様々なリスクに対応 体系的な取組みが必要 着目点は．．． Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 15 データ例 システム運用時に想定されるリスク ＜環境変化＞ 新サービス追加 法制度改正 利用増大(量) 利用形態変化(質) 故 障 率 初期故障期 偶発故障期（安定期） 摩耗故障期 <故障率曲線の原図> "Bathtub curve" by en:User:Wyatts - U.S. Army document. Licensed under Public domain via ウィキメディア・コモンズ http://commons.wikimedia.org/wiki/File:Bathtub_curve.jpg#mediaviewer/File:Bathtub_curve.jpg Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 16 データ例 リスクへの対応 ハードウェアは劣化する→故障 冗長構成，など ソフトウェアは劣化しない ソフトウェアは相対的に劣化する 使われる環境の変化 ビジネス方針，ニーズ 組織・人（慣れによる過信・ 油断，交代による技術/ノ ウハウ継承無し） 利用者増，技術進展，他 リスク要因 Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー 教訓の活用 網 羅 的 な 事 前 抽 出 が 困 難 障害事例に基づく 教訓・対策の共有 失敗に学ぶ Software Reliability Enhancement Center 17 リスク低減のための体系的な取組み （障害事例）情報の共有 経験を共有し、みんなの力でIT社会の安全・安心を 築くしくみ 情報処理システム障害の事例情報を収集・分析 それにより得られた教訓と対策を整理・体系化 教訓と対策を業界を越えて横断的に広く共有 Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 18 参考 「他山の石」 「他山の石」の意味※ 他人の誤った言行やつまらない出来事でも それを参考にしてよく用いれば， 自分の修養の助けとなる 失敗に学ぶ → 類似障害の発生を防止できる 「対岸の火事」 ※(出典) 文化庁月報 平成23年10月号(No.517) http://www.bunka.go.jp/publish/bunkachou_geppou/2011_10/series_08/series_08.html Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 19 参考 各社でやるだけでよいのでは？ 経験豊富でも，すべてをカバーできますか？ Ａ社のカバーエリア Ｂ社のカバーエリア Ｃ社のカバーエリア ３社によるカバーエリア Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 20 参考 みんなの力で全体をカバー ITサービスの機能やシステムが複雑化す ると，単一事業者のカバーする知見の範 囲は，相対的に狭くなる． 広 高信頼化 1事業者に囲われた経験と情報を幅広 く社会全体で共有し、障害対策などに 有効活用できることが重要． カ バ ー 範 囲 率 社会全体 1社のみ 狭 低 高 ITサービス機能・システム複雑度 時代の流れ Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 21 背景 背景５ 個人・組織の経験を出し合い， それらを“社会智”として共有する世の中を!! Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 22 参考 「情けは人のためならず」 「情けは人のためならず」の意味※1 人に対して情けを掛けておけば， 巡り巡って自分に良い報いが返ってくる “社会間接互恵性” ※2 ある個体が利他行動(他者に親切にする行動)を行った結 果、その個体の評価が高まり、他者に行った利他行動が回 り回って別の他者から返ってくる仕組み 「ヒト」は，日常生活で困っている他人を見ると，それが自分の知らない人で あっても助けたい衝動にかられ，多くの場合何らかの親切を行う性質を持つ ※1 (出典) 文化庁月報 平成24年3月号(No.522) http://www.bunka.go.jp/publish/bunkachou_geppou/2012_03/series_08/series_08.html ※2 (出典) 大阪大学大学院人間科学研究科の実証実験成果から 2013年8月8日 http://www.osaka-u.ac.jp/ja/news/ResearchRelease/2013/08/20130808_1 Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 23 参考 相互に結びつくITサービス/製品機器 国民生活・社会経済活動 医療機器 金融系 情報処理システム 制御機器 制御機器 エネルギー系 情報処理/制御システム 交通系 情報処理システム データセンター/クラウド 情報通信系 情報処理/制御システム 他サービス/製品機器の障害は， 自サービス/製品機器にも 影響が及び得る ・あるITサービス/製品機器は，他のITサー ビス/製品機器に依存することがある． ・ITシステムの中に，製品機器を含むこと がある． 相互に依存 Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 24 参考 障害事例の公開なんて出来ない！ 社会（の人々）は思ったより成熟している 社会の在るべき姿 信頼できる企業とは？ “コミュニティ” オープンソース，ソーシャルネットワーク，など 貢献と尊敬・信頼 Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 25 参考 アンケート例（1/3） 障害事例情報共有の取組みについて、 どのように思われますか？ （回答者76名） 0.0% 10.5% 0.0% 1.3% 3.9% 25.0% 59.2% １．社会にとって有用であり、成果は自 社に役立つだろう ２．社会にとって有用であるが、成果は 自社に役立つか不明 ３．社会にとって有用であるが、成果は 自社には役立たない ４．社会にとって有用かどうかは分から ない ５．社会にとって有用とは思われない ６．分からない 無回答 Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー ＜アンケート回答者（計76名）＞ ET2013（2013年11月） ソフトウェアジャパン（2014年2月） Software Reliability Enhancement Center 26 参考 アンケート例（2/3） 社会として、どうあるべきと思われますか？ （回答者76名） 0.0% 10.4% 2.6% 28.6% 58.4% １．基準を設定し、それ以上の影響があった障害事 例に基づく教訓は、広く社会で共有されるべきであ り、各当事者が対応するのがよい ２．基準以上の障害事例に基づく教訓は、広く社会 で共有されるべきであり、所定のルールの下で、関 連公的機関が取りまとめるのがよい ３．障害事例に基づく教訓は、社会で共有される必 要はない ４．その他 無回答 Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー ＜アンケート回答者（計76名）＞ ET2013（2013年11月） ソフトウェアジャパン（2014年2月） Software Reliability Enhancement Center 27 参考 アンケート例（3/3） 障害事例情報を公開する企業に対して、どのように思 われますか？（回答者76名） １．障害を発生させていることから、信 頼できない 2.6% 11.8% 0.0% ２．積極的に情報公開をすることから、 公開しない企業に比べて信頼できる 2.6% ３．特に何とも思わない ４．その他 82.9% 無回答 ＜アンケート回答者（計76名）＞ ET2013（2013年11月） ソフトウェアジャパン（2014年2月） Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 28 具体的にはどうやればよいの？ 本日の主題： システム障害事例情報の分析に基づく 教訓・対策を共有する仕組み Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 29 内 容 1. IPA/SECの概要…省略（「参考」参照） 2. IPA/SECの取組み 「重要インフラ等システム障害対策」など 3. これまでの成果概要 ITサービス高信頼化“教訓集” システム障害事例の分析に基づく対策・教訓の共有の仕組み 4. “教訓”の内容 5. 今後の取組み 業界を超えた“教訓”共有の仕組みの展開 6. まとめ Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 30 ２．IPA/SECの取組み 重要インフラ分野における高信頼化対策（IPA） ◇重要インフラ分野等のシステム障害への対策 経験を共有し、みんなの力でIT社会の安全・安心を築くしくみ 具体的には， 重要インフラ分野*等のシステム障害の事例を分析し，それにより得られた 教訓と対策を整理・体系化した上で，再発防止策を，業界を越えて横断 的に広く共有する仕組みの構築を目指す． http://www.ipa.go.jp/sec/system/index.html * 情報通信，金融，航空，鉄道，電力，ガス，政府・行政サービス，医療，水道，物流，クレジット，石油，化学 Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 31 ２．IPA/SECの取組み 情報セキュリティ 教訓共有の取組みの目指す方向 航空 現状（教訓の共有なし） 原子力 金融 障害に基づく教訓の共有による信頼性向上のしくみ 社会 社会 より高い安全・安心な 製品機器/ITサービスの提供 重要インフラ等 重要インフラ等 信 頼 性 信 頼 性 製品機器/ ITサービス (Ａ社) 障害 製品機器/ ITサービス (Ｂ社) 障害 対 策 実 施 教 訓 Ａ 信 頼 性 信 頼 性 製品機器/ ITサービス (Ｃ社) 障害 対 策 実 施 原因分析 対策検討 教 訓 Ｂ 対 策 実 施 原因分析 対策検討 教 訓 Ｃ 原因分析 対策検討 信 頼 性 製品機器/ 製品機器/ 製品機器/ ITサービス ITサービス ITサービス (Ａ社) (Ｂ社) (Ｃ社) 障害 障害 障害 対策実施 対策実施 対策実施 教訓 教訓 教訓 教 訓教 Ａ訓教 Ｂ訓 Ｃ 原因分析・対策検討 一般化・抽象化・普遍化 体系的整理 機密保持等 のルール 専門家，有識者のご協力を得て IPA/SECや業界団体等が担う共有活動 類似障害の発生 Copyright © 2013-2014 IPA, All Rights Reserved 信 頼 性 KIISセミナー Software Reliability Enhancement Center 32 ２．IPA/SECの取組み IPAにおける事例分析，教訓の共有活動 （実績） 2014年5月13日公開 http://www.ipa.go.jp/about/press/20140513.html ＜特徴＞ ①業界・分野を超えて活用可能な普遍化された教訓。 ②機密保持ルールの下で詳細情報の提供を受けた深い議論。 ③蓄積されたソフトウェア・エンジニアリングに関する知見の活用。 Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 33 ３．これまでの成果概要 「教訓集」の構成 情報処理システム高信頼化教訓集 （ITサービス編）の本体 PART Ⅰ 教訓集（本編） PART Ⅱ 障害対策手法・事例集 PART Ⅲ 障害分析手法・事例集 付録A 障害情報の取扱いルール 障害情報を報告・記録する共通 様式と、それらの収集・公開に 際しての機密保持等のルールを まとめたもの Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー 教訓集中の各教訓を実践するため に必要な手法を整理したもの 今回の活動の中で実施した、障 害の分析手法・事例の調査結果 をまとめたもの Software Reliability Enhancement Center 34 ３．これまでの成果概要 教訓一覧（製品・制御システム） 教訓番号 1 シ ス テ ム 要 求 定 義 教訓タイトル 複雑な条件式のロジック変更を行う場合は、デシジョンテーブル等による検証が有効である ア ー キ シ テ ス ク テ チ ム ャ 設 計 ア ー ソ キ フ テ ト ク ウ チ ャェ ア 設 計 ア ー （キ ソ 変 フ テ 更 ト ク 設 ウ チ 計 ェ ャ ）設ア 計 ○ ○ ○ ○ （ コ ー デ実 ィ装 ン グ レ ビ ュ ー シ ス テ ム テ ス ト 教 育 マプ ネロ ジジ メェ ン ク ト ト 運 用 ） 条件が整理されていない状態で、トータルの条件数が100を超えるような機能、または10個以上の条 件を有する機能を修正する場合、関連する条件を全て洗い出して整理し不整合がないことを確認す 複雑な条件式のロジッ 2 る ク変更を行う場合は、デ 複数機能モジュールを統合する場合、統合前の条件数の総和と統合後の条件数を比較し差がある 3 場合は、条件の抜けがないか確認する。 シジョンテーブル等によ 変数値域が広く、組合せバリエーションが非常に多くなる場合には、値域を適切な大きさに分割した 4 上で境界値テストを実施する る検証が有効である 5 内蔵電池を使用する場合には、深放電時の起動シーケンスを考慮すること 6 フラッシュメモリを使用する場合には、書き込み寿命回数を考慮すること 7 消費電力の多い機能を追加する場合には、一時的な電圧降下による影響（リセット、フリーズ等）や 電源の種類、電池の場合は残量を考慮すること 8 想定可能な例外を形式的に漏れなく分析する 9 ○ ○ ○ ○ ○ ○ ○ ○ システムを二重化する場合は、同期すべきデータ領域を適切に設定する ○ 制御対象のハードウェアが同一でも、運用条件が変わるときは、ハードウェア仕様を再確認する 歩留りのある製品の良 10 プロセス間、スレッド間でデータを共有（引き渡し）する場合は、排他・同期処理が正しく行われている 品／不良品を検査する 11 か、あるいはデッドロックが発生していないかどうか注意する 装置では、全てが良品 歩留りのある製品の良品／不良品を検査する装置では、全てが良品あるいは、不良品との検査結果 12 は異常と判断すべきである あるいは、不良品との 既存ソフトウェアの性能改善を実施する際には、アイドリングタイムの発生、処理の同期ずれの発生 13 等と影響を確認する 検査結果は異常と判断 ・大量のデータを通信経由で扱う場合、一連の処理の流れの中にボトルネックを作りこまないように 14 すべきである 注意する ・時間帯による負荷変動について考慮する 15 納入したあと、お客様が運用するような業務システムでは、業務シーケンス中のあらゆる異常操作（リ セット、電源断、放置も含め）、への対応を考える 16 障害解析時の保守メンテ用ログ処理であっても、仕様書を作成し、影響評価を実施すること 17 判断処理は、必要条件だけでなく、制限すべき条件も漏れなく抽出する 18 ログファイルの断片化に注意する Copyright © 2013-2014 IPA, All Rights Reserved ○ ○ ○ ○ ○ 消費電力の多い機 ○ ○ ○ 能を追加する場合 ○ ○ には、一時的な電 圧降下による影響 （リセット、フリーズ 等）や電源の種類、 ○ ○ 電池の場合は残 ○ ○ 量を考慮すること ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ KIISセミナー Software Reliability Enhancement Center 35 ３．これまでの成果概要 教訓一覧（ITサービス） No 領域 ＩＤ 1 ガバナン ス／マネ ジメント Ｇ１ 2 Ｇ２ 3 Ｔ１ 4 Ｔ２ 5 Ｔ３ 技術 6 Ｔ４ 7 Ｔ５ 8 Ｔ６ 9 Ｔ７ 教訓概要 システム開発を情シス部門だけの仕事にせず、 各事業部門が自分のこととして捉える「態勢」をつくることが大切 発注者は要件定義に責任を持ってシステム構築にかかわるべし サービスの継続を優先するシステムにおいては、 疑わしき構成要素を積極的にシステムから切り離せ （“フェールソフト”の考え方） 蟻の目だけでなく、 システム全体を俯瞰する鳥の目で総合的な対策を行うべし！ 現場をよく知り、現場の知識を集約し、 現場の動きをシミュレートできるようにすべし！ システム全体に影響する変化点を明確にし、 その管理ルールを策定せよ！ サービスの視点で、 「変更管理」の仕組み作りと「品質管理責任」の明確化を！ テスト環境と本番環境の差異を体系的に整理し、 障害のリスク対策を練るべし バックアップ切替えが失敗する場合を考慮すべし ガバナンス/マネジメント 技術 組織連携 発注者責任 要求 設計 製造 試験 運用 ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ 各教訓の説明 Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 36 ４．“教訓”の内容 各教訓の構成 [教訓ＩＤ] 教訓概要(タイトル) 問題：障害事例の内容 原因：問題を引き起こした要因の 分析結果 対策：問題の原因を取り除き再発 を防止するための方法 効果：対策の実施により見られた ／期待される効果 教訓：得られた教訓の内容説明・ 補足 あらかじめ実施 しておくべき対策 はないか？ 類似の障害は 起きないか？ http://www.ipa.go.jp/about/press/20140513.html Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 37 ４．“教訓”の内容 例：教訓の概要（１） 教訓G1：システム開発を情シス部門だけの仕事にせず、 各事業部門が自分のこととして捉える「態勢」をつくることが大切 システムトラブルの8割は、上流の要件定義局面でのコミュニケーション・ギャップから 問題が生じていることが判明 →システム開発におけるビジネスサイドの役割と責任を明確化し、コミュニケーションの 質を高める態勢「アプリケーション・オーナー制度」 •システム開発は、情シス部門に 任せきりにすべき仕事ではなく、 自分の考えた商品や施策を具体 化するために行う自分自身の仕 事であるという「オーナーシッ プ」の考え方を持たせる。 •事業部門に、要件の詳細が固ま るまで、情シス部門と対話を繰 り返す責任を持たせ、要件定義 の最終責任を負わせる。 •事業部門に、要件定義どおりに システムが出来たかどうか受入 れテストを実施する責任を負わ せる。 アプリケーション・オーナー制度：責任と役割分担（東京海上日動火災株式会社の例） Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 38 ４．“教訓”の内容 例：教訓の概要（２） 教訓G2：発注者は要件定義に責任を持ってシステム構築にかかわるべし システム開発・運用をITベンダに外部委託するケースで、開発案件の増加に伴い任せる業務 が徐々に拡大し、要件定義や受入れテスト等、発注者としての役割を果たし切れていない 1) 要件定義書の中身と受入れテストについての責任は発注者とする 2) 開発プロセス標準を見直し、上流の要件定義を押さえる（上流工程完璧主義） 改革後 改革前 ベンダー任せ 要件定義前の 見積もりで契約し 変更はなし 要件定義 発注者が責任を持ち 主体的に実施。 ベンダーには委任契約で発注 要件定義書を変更したら 仕様変更書を作成し 契約を見直し システム 設計・開発 ベンダー任せ 受入れ テスト 発注者が責任を持ち 主体的に実施。 ベンダーには委任契約で発注 要件漏れ等の上流工程に起因する 品質上の問題が著しく減少 プロジェクトの透明性が増し、組 織同士の継続的な信頼関係が向上 Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー 改革前 改革後 企画 （プロジェクト企画書作成） 要件定義（１） RFPの作成 要件定義書の作成 企画 （プロジェクト企画書作成） ①要件定義書の記述レベル の詳細化を図り、記載内 容の網羅性チェックを徹 底する 要件定義（２） 要件確認書の作成 要件定義 RFPの作成 ※RFPの詳細化 要件定義書の作成 ※ 要件定義書の詳細化 と網羅性チェック システム・ソフトウェア 要件定義 システム・ソフトウェア 要件定義 システム・ソフトウェア 方式設計 システム・ソフトウェア 方式設計 システム・ソフトウェア 実装とテスト システム・ソフトウェア 実装とテスト 発注側担当 受入れテスト 受入れテスト ベンダ担当 ②受け入れテストのテスト ケースを上流工程で作成 ③発注者自らが、要件定義 が設計書に反映されたこ とを確認し、要件定義書 と 設計書のズレをなくす Software Reliability Enhancement Center 39 ４．“教訓”の内容 例：教訓の概要（３） 教訓T1：サービスの継続を優先するシステムにおいては、 疑わしき構成要素を積極的にシステムから切り離せ （“フェールソフト”の考え方） １）自身のヘルスチェックの場合 業務内容に基づいて、システム毎にポリシーを作 成した上で、フェールソフトの考え方を適用。 ①異常を通知 現用 ﾉｰﾄﾞA ハードウェア機器の故障、ソフトウェアの処理プ ロセスの異常等があった場合には、その部位を積 極的に停止させることでシステムから切り離す、 場合によってはその系全体を放棄するといった考 え方のもとに処理・対応する。 一方、そのような状況下で一部の部位や系をシス テムから切り離しても、システム全体としての サービスは継続できるように、フェールソフトの 考え方に基づいて設計・運用する。 というのは、機器やソフトウェアそれぞれの動作 継続を優先しすぎてしまうと、予期せぬ障害の場 合にサービスへの影響がかえって大きくなってし まう場合があり、サービスの継続を優先させるた めには、むしろ積極的に関連する部分をシステム から切り離す方が良い場合が多いからである。 Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー 待機 ﾉｰﾄﾞB ②停止コマンドで切り離し ２）他系のヘルスチェックの場合 待機 ﾉｰﾄﾞB 現用 ﾉｰﾄﾞA ①ヘルスチェック ②停止コマンドで切り離し ３）自動停止できない場合は手動による停止で切り離し 現用 ﾉｰﾄﾞA 待機 ﾉｰﾄﾞB Software Reliability Enhancement Center 40 ４．“教訓”の内容 例：教訓の概要（４） 教訓T2：蟻の目だけでなく、 システム全体を俯瞰する鳥の目で総合的な対策を行うべし！ 制御系システムの下位にある制御装置の稼働系に故障が発生し、 自動的に待機系に切り替わるところが切り替わらず、 上位の監視端末からの指示による系切替えを実施したが、失敗。 障害が下位で起きた場合、障害を起こ した下位だけの対策を考えがちである が、蟻の目（下位）の対策だけでなく、 システム全体の視点で、鳥の目（上 位）対策を活用することでシステムの 安定稼働が保たれる。 Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 41 ４．“教訓”の内容 例：教訓の概要（５） 教訓T3：現場をよく知り、現場の知識を集約し、 現場の動きをシミュレートできるようにすべし！ 特定ケースで制御信号が正しく出力されず、列車が停止 【原因１】有識者（ベテラン社員を含む）による以下の機能確認を行っても、まだ洗い出 せていない機能が存在する。（機能要件漏れ） 【原因２】列車の動き、システムの動作などを総合的にテストできる環境、つまり、組込 みソフトウェアを持った制御システムと列車などの動作の全てのテストが行え るテスト環境ができていない。 【原因１】については、一度設計された 「機器の動き（列車の運転）」のパ ターンを知識データベースとして蓄 積し、そこに、追加登録していく。 ①A列車が折返し出発 駅 【原因２】については、制御系システム のシミュレーション・システムの開 発を行うためには、現実の制御装置 のプロセスを分かりやすく可視化し、 ②駅を出発したのに プロセスの骨子を見極めて「モデ もかかわらず制御 ル」化（モデリング）する。 信号が出続ける Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー ④A列車の制御信号が 出続けているため、B 列車への制御信号が 出なかった A列車 B列車 ③B列車の進路を構成 Software Reliability Enhancement Center 42 ４．“教訓”の内容 例：教訓の概要（６） 教訓T4：システム全体に影響する変化点を明確にし、 その管理ルールを策定せよ！ 表示項目数がシステムの上限値を超えたため、全画面表示が消え，オペレータが混乱 ↳システム構築当初から決まっていた上限値について、外部仕様変更に伴う見直しを未実施 原因の本質は、全体に影響する変化点（この場合、予測時間、列車運転本数）が不明確 【原因１】予測時間を4H⇒24Hに変更した際、そのよう な要件変更があったにもかかわらず、「修正箇 所数」の上限値の増加などシステム全体の機能 要件変更を未実施 【原因２】列車の本数が年々増加しており、本来ならば（ 運転本数の増加の都度）上限値を超えた際のシ ステムの挙動を見直す必要があったにもかかわ らず、未実施 ②ダイヤ 修正発生 実績ダイヤ KIISセミナー 予測ダイヤ ①抑止入力 制御系システムの変化点の管理ルールを明確にし、その ルールを守る仕組みを構築 ・システムが監視・制御する対象と仕様の変化点を網羅 ・変化点管理のルールとそれを守る仕組みを構築 ・変化点管理で使用する管理指標を関係部門で共有し、 「変化点の見落とし」を防止 Copyright © 2013-2014 IPA, All Rights Reserved ③修正箇所が上 限値を超過 修正箇所 現在時刻 ④予測ダイヤの表示 ができなくなった Software Reliability Enhancement Center 43 ４．“教訓”の内容 例：教訓の概要（７） 教訓T5：サービスの視点で、 「変更管理」の仕組み作りと「品質管理責任」の明確化を！ 本店ホスト／サーバから請求データを端末に転送し請求書を印刷するシステムにおいて、 端末として、営業員が持ち歩くHT（ハンディ・ターミナル）を新規に導入したところ、 そのシステムから出力される請求書の金額が誤ったまま顧客に渡ってしまい、個別謝罪・ 請求書の再発行に追われた． システムへの新たな要件追加、 使用方法の変更があると、今ま で正常に稼働していたシステム が突如障害となる 変更があった時にシステム 全体のプログラムの整合性、 データの整合性、テスト仕 様の整合性を保つための変 更管理を確実に実施 システム全体の整合性を確 認する人を決め、品質管理 責任を明確にし、開発 フェーズ毎の検証を実施 Copyright © 2013-2014 IPA, All Rights Reserved 事業所サーバ 本店ホスト/サーバ ホ ス ト Ｐ Ｇ 顧客 ﾃﾞｰﾀﾍﾞｰｽ 請求予定 配 信 Ｐ Ｇ 請求予定 使用料 調整単価 Ｈ Ｔ 送 信 Ｐ Ｇ 営業HT 営業HT Ｈ Ｔ ・ Ｐ Ｇ 障害 業務部門と情シス部門 でテスト仕様作成・実施 請求書作成 情シス部門でテスト仕様作 成・実施→業務部門も参加 データ整合性 プログラム整合性 テスト仕様整合性 要件定義 設計・開発 受入れテスト サービスの視点で、「変更管理」 「品質管理責任」 KIISセミナー Software Reliability Enhancement Center 44 ４．“教訓”の内容 例：教訓の概要（８） 教訓T6：テスト環境と本番環境の差異を体系的に整理し、 障害のリスク対策を練る テスト環境と本番環境とに相違があり、テスト環境でうまくいったソフトウェアのリリー スであるが、本番環境で障害が発生 ①テスト環境と本番 環境の差異分析 ②テスト環境で確認 できない項目、機 能に対し、関係者 でリスク分析 ③リスク分析結果を 基に、コンティン ジェンシープラン ④本番環境のリスク をステークホルダ で共有 ⑤大きいリスクは経 営トップが判断 環境差異 分析 テスト環境 機 能 要 件 本番環境 AP ・ ・ ・ ①テスト環境と本番環境の環境差異を洗い出す テスト環境で検証できる ・異なる項目 HW テスト環境 Copyright © 2013-2014 IPA, All Rights Reserved ﾐﾄﾞﾙ ｳェｱ データ 量・質 ②テスト環境で検証 出来ない項目を 抜き出す。 テスト環境で検証できない 項目 テスト環境で検証できる ・異なる項目 非 機 能 要 件 テスト環境で 検証できない ③リスク対策/コンティ ンジェンシープランを 作成（３者で検討） テスト環境で検証できる ・異なる項目 OS 本番環境 テスト環境で検証できない テスト環境で検証できる ・異なる項目 テスト環境で検証できない テスト環境で検証できる ・異なる項目 リスク対策/コンティン ジェンシープラン 1 2 3 4 テスト環境で検証できない テスト環境で検証できる 性能 ・異なる項目 テスト環境で検証できない テスト環境で検証できる NW ・異なる項目 テスト環境で検証できない ④３者の検討結果は、経営トップ、 製品ベンダ等のステークホルダで 共有する。 ⑤大きいリスクは、経営トップが判断する。 KIISセミナー Software Reliability Enhancement Center 45 ４．“教訓”の内容 例：教訓の概要（９） 教訓T7：バックアップ切替えが失敗する場合を考慮すべし 冗長構成を取っているにも関わらず、バックアップ切替えが失敗しシステム障害とな るケースが多い。下図に示されるさまざまな失敗原因にあらかじめ配慮してシステムの 開発・運用を行うことにより、過去に発生した障害と類似の障害の発生を防ぐことがで きる。 (5)手動切替え失敗 (9) 切替え失敗 (7) 待機系システムの障害 （操作ミス） （保守作業ミス） （稼働系と同一原因） (4)切替え失敗 （切替えソフトウェア不具合） (2)待機系システムの障害 （構成不備） (1）稼動系システムの 障害未検知 (3)待機系システムの障害 （アプリケーション不備） 稼働系 待機系/ 分散稼働 アプリケーション OS等 ハードウェア (6)切替え後動作不安定 （性能不足） (10) ネットワークの 自動切替えに失敗 (8) 切替え後動作不安定 （データ不正） データ データ (11)電源装置の 自動切替えに失敗 電源装置 (予備) Copyright © 2013-2014 IPA, All Rights Reserved アプリケーション OS等 ハードウェア KIISセミナー 電源装置 (現用) ネット ワーク 現用 ネット ワーク 予備 Software Reliability Enhancement Center 46 ４．“教訓”の内容 例：製品・制御システム編の教訓例（１） ※以下、直接の対策と恒久対策に続く Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 47 ４．“教訓”の内容（番外） 整理・体系化：分析と議論を通して分かったこと（例） 1. 多忙時や例外対応時に起こしやすい「ルール逸脱」 システム運用の厳格なルールが定められているにもかかわら ず，多忙のために，あるいは，例外的事象発生時の対応のため に，そのルールで規定されていない簡易な方法（例：ローレベ ルの強力コマンドの使用）で操作することにより，重大事故を 引き起こし易い．ベテラン技術者でも起こし得る． 過信して，油断して，「叱られたくない」ために，等々． 2. システム停止中の「人手」による業務手順の規定要（IT-BCP） 迅速な顧客対応が必要な業務等については，システム停止時 には，可能な範囲で，人手等で対応する計画（IT-BCP）をあら かじめ策定し，訓練しておくことが重要． Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 48 参考 人間系の要因分析(1/2) ＜出典＞ 太田氏（株式会社ジャステック） の調査検討資料 Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 49 参考 人間系の要因分析(2/2) ＜出典＞ 太田氏（株式会社ジャステック） の調査検討資料 Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 50 参考 人間系の組織能力成熟度 ＜出典＞ 太田氏（株式会社ジャステック） の調査検討資料 Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 51 今後の取組み 態勢 “教訓”を活用した，システマティックな活動が重要 Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 52 ５．今後の取組み 教訓の共有（社会で）と活用（各組織で） 有識者・専門家 による機論 高 一般化・抽象化 された教訓 ★ 各分野で展開 抽 象 レ ベ ル 共通コンテキスト 普遍化 共有 事例と ★ 根本原因 対策 コンテキスト ★ 対策 ★：本質 “想像力”が重要 Copyright © 2013-2014 IPA, All Rights Reserved 対策 ★ 対策 コンテキスト コンテキスト コンテキスト Ａ分野 Ａ分野 ★ Ｂ分野 低 Ｃ分野 各組織での活用時，システマティックな取組み： 教訓と共に提供されるコンテキストと 自身のコンテキストとを比較・照合し， 適用可能な教訓について，具体的対策を検討 KIISセミナー Software Reliability Enhancement Center 53 データ例 優れた品質保証体制の組織のプロダクトは信頼性が高い 品質保証体制の専門スタッフがいるプロジェクトの方が， そうでないプロジェクトに比べ，プロダクトの信頼性が高い 統計データ例 N=63 (37+26) 低 システマティック な取組みの効果 ← 信 頼 性 12.2 → 約2.5倍 高 4.8 優れた品質保証体制の組織 * FP発生不具合密度：ファンクションポイント（機能規模）当たりに発生する不具合（バグ）の数 出典：「ソフトウェア開発データ白書2014-2015」(IPA/SEC) Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 54 誰が，どう使う？ 部署等／ 経営層 （事例に基づく）教訓の活用例 役割（ロール） 社長 組織に“安全文化”を醸成 担当役員 部門長 業務部門 業務推進担当 システム推進担当 組織・ 体制 の 整備 関連会社 運用 手順 の 整備 開発 手順 の 整備 部門長 情報 システム 部門 システム開発担当 システム子会社 元請けベンダ ベンダ アウトソーサ 社内教育 サブベンダ 調達 時の 指示 事項 調達 時の 確認 事項 ﾚﾋﾞｭｰ ・試験 項目 類似 事例 トラブ ル発 生時 の 原因 推定 ＜出典（縦軸）＞ SEC BOOKS 「経営者が参画する要求 品質の確保 ～ 超上流から攻めるIT化の勘どころ ～」，p.37 の 3.2（１）項、p.41 の 4.1 Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 55 参考 参考：教訓の一例(1/5) 【教訓タイトル】 ★：本質 ＜抽象的な表現の例＞ システムの部分変更（に伴う新旧混在）時に（非変更部分との）整合性を確認する． ＜具体的な表現の例＞ 変化に対応して（プログラム／システム定義データ中の）定数をチェックする． 【説明】 共通コンテキスト 交換（部分変更）する構成要素（ソフトウェアを含む）は，交換前のものと互換 性があるという仕様になっていても，機能やインタフェースが一部異なっている かもしれない．特に，新機能が追加されていることがよくある．異なる技術が用 いられている場合には，設計思想そのものが異なっていることもある．また，機 能は同じでも，性能等の非機能特性が異なるケースは多い． したがって，交換する構成要素と，システムの他の部分（交換しない部分）とが 整合するかについて，様々な視点から確認する必要がある． 特に，性能差がある場合，タイマ監視等を行う処理においては，監視タイマ値の 妥当性を入念にチェックし，チューニングをやり直す必要がある．特に，新しい 構成要素の特性が性能に影響する場合を見逃してはならない． Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 56 参考 参考：教訓の一例(2/5) 【問題（障害事例）】 (個別)コンテキスト ◆概要 2013年7月18日，ある鉄道会社にて，列車運行を管理するシステムのうち， ダイヤに基づき各駅の信号機を自動制御する「自動列車進路制御装置(PRC)」の 保守時に異常が発生．その後バックアップ系統への切替えに失敗し、装置が停止． 管轄する3路線の鉄道が2時間以上運行できなくなり，385本が運休，約11.1万 人に影響． ◆状況 午前4時，装置の部品（今回の要因となった部品とは別のもの）の交換作業を 始めると，アラームが鳴動し動作停止． 復旧のため，機器内に２つある処理系統のうち上記部品交換を行ったのとは別 の系統（バックアップ系統）を起動させようとしたものの，起動せず． 交換対象の部品を戻して再起動する等を試みたが，装置は復旧せず． ５時半頃に予備の装置を使ってシステム全体の復旧に取り掛かり，６時54分 に復旧．７時半頃から順次運転を再開． <参考> 新聞等の報道記事 Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 57 参考 参考：教訓の一例(3/5) 【（直接の）原因】 (個別)コンテキスト 自動列車進路制御装置(PRC)のディスクとして，もとはHDDが使用されていた が，2010年からSSDに交換されていた．（交換当時は，現用・待機両系停止の 状態で装置を起動する試験のみを実施し，潜在リスクを発見できず．） その後，PRC内部のある故障部品を交換する必要が生じ，現用系のみを停止し て実施することとした．工場での事前確認では，同じ装置がなかったため，HDD 搭載装置での試験を行い，SDD搭載装置ではできなかった．このような状況で， 現場で実際の交換作業において，PRCの現用系停止状態で待機系を起動させた． 装置の仕様上，初期起動時に，CPU上のOSがディスクにリセット要求を行い， その完了をタイマ監視（タイマ値=200ms）で待つ．HDDの場合には1msで完 了するが，今回の装置に搭載されていたSSDでは300msが必要であった． したがって，タイムアウトを検出したOSはディスクの異常と判断して停止要求 を行い，SSDはそれを不正コマンドとして受け付けず，外部からのコマンドを拒 否するモードに移行． 【今回の対処】 OSの監視タイマ値を200msから360msに変更． Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー <参考> (1) 日経エレクトロニクス，2013.8.9. (2) 日経コンピュータ，2013.9.10. Software Reliability Enhancement Center 58 参考 参考：教訓の一例(4/5) 【対策（例）】 共通コンテキスト ◆コンポーネント・レベル ・ミスを起こさない：特にメンテナンス時における，ハード担当と制御ソフト担 当とのコミュニケーションの徹底（気づかせるための会議，文書の工夫等） ・ミスを逃さない ：試験時の思い込み（“互換性”への過信）排除（第三者の関 与等）．標準規格の規定事項/規定外事項の明確化 ◆システム・レベル ・ミスを起こさない：変化点を捉えた，俯瞰的かつ系統的な設計レビュー ・ミスを逃さない ：試験時における，本番環境との相違点に関するリスク評価 【教訓活用時のコンテキスト】 (1) 比較的大規模なシステムにおいて，システムの構築あるいは更改を段階的に 行う場合，版や性能等の異なる構成要素が混在することになるケース (2) 比較的長期間使用しているシステムにおいて，あるいは技術進展の激しい分 野において，一部の部品を当時の最新の（or 通常出回っている）ものと交換 するケース Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 59 参考 参考：教訓の一例(5/5) (個別)コンテキスト 【教訓の活用（例） 】 (1) 比較的大規模なシステムにおいて，システムの構築あるいは更改を段階的に 行う場合，版や性能等の異なる構成要素が混在することになるケース 多数のサーバと端末装置から成るシステムにおいて，当初は全体を一括で構 築したものの，端末の更改を，毎年一部ずつ順に行うような場合，新規端末の性 能が当初端末より高い場合には，サーバとの通信における応答待ちタイマ値等を チューニングし直す必要があるかどうか，検討する． (2) 比較的長期間使用しているシステムにおいて，あるいは技術進展の激しい分 野において，一部の部品を当時の最新の（or 通常出回っている）ものと交換 するケース 装置内のメモリを増量のために大容量チップに交換する際，大容量のために 前のものよりアクセス時間が若干長い仕様となっている場合，CPUやDMAデバイ スとの整合性を確認する． Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 60 ５．今後の取組み 障害事例情報に基づく教訓共有の仕組みの展開（案） 各分野・業界の団体等 目指す社会に向けて 参加者：業界内（会員)企業 目的：障害事例情報に関する 分析と対策等の共有 IPA/SEC，地域団体，応用分野等 参加者：多様な業界からの企業等 事例紹介（一部） 業界横断的視点からのコメント 他業界の教訓等の ナレッジを共有 目的：障害事例情報に関する 分析と対策等の共有 公開された 教訓集，等 教訓の説明 フィードバック 事例群 取りまとめ 事例群 取りまとめ 教訓集（例） 必要に応じ 取込み 相互に参照できるような仕組み 教訓集 または 各業界向け (各業界団体等内での公開) Copyright © 2013-2014 IPA, All Rights Reserved 業界を超えて活用できるよう普遍化 全業界向け （一般公開） KIISセミナー Software Reliability Enhancement Center 61 ５．今後の取組み 障害事例情報に基づく教訓共有の仕組みの展開イメージ 目指す社会に向けて 企業 a4 企業 a3 企業 a5 企業 a6 分野・業界Ａ内 の情報共有 企業 a2 企業 a1 企業 b2 ・・・ 分野・業界Ｂ内 の情報共有 企業 b1 分野・業界にまた がる情報共有 教訓 企業 d1 企業 d2 分野・業界Ｄ内 の情報共有 応用分野に関す る情報共有 企業 e1 企業 d3 企業 e2 企業 e3 企業 g1 ・・・ 企業 c1 企業 c2 ・・・ 分野・業界Ｃ内 の情報共有 地域団体による 情報共有 企業 h1 企業 f1 企業 f2 分野・業界Ｆ内 の情報共有 企業 f5 企業 f3 企業 f4 分野・業界Ｅ内 の情報共有 Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 62 ６．まとめ（に代えて） 共有活動への参加者の声，参加予定者からの期待等 ・自社事例を“教訓”化するための議論の中で，“気づき”を得ることが あった． ・他分野の事例紹介では，鉄道の線路を送電線に置き換えて考えてい る． ・他分野の事例の中に参考になるところがあった． ・他分野の事例ではあるが，今回の障害に関連する情報として，（特に 外国製の）パッケージ利用における留意点を知りたい． ・クラウドの活用が拡がりつつある中で，まだあまり事例が多くない障害 情報の共有ができればありがたい． ・今回の自身の障害の教訓としては，システム停止時の手動での業務 のやり方を決めて，普段から訓練しておく必要がある，ということ． Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 63 ６．まとめ（に代えて） お願い 失敗に学ぶ，システムの信頼性向上のために， 経験の共有にご理解とご協力をお願いします 一般財団法人関西情報センター(KIIS)による 障害事例情報共有の取組みに期待します！ 情報処理システム高信頼化教訓集－2013年度版－ （ITサービス編） http://www.ipa.go.jp/sec/reports/20140513.html （製品・制御システム編） http://www.ipa.go.jp/sec/reports/20140513_2.html Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 64 ご清聴，ありがとう ございました アンケートへのご協力を よろしくお願いいたします． http://www.ipa.go.jp/sec/index.html Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 65 Windows Server 2003のサポート終了に伴う注意喚起 Windows Server 2003のサポートが、2015年7月15日に終了します。 サポート終了後は修正プログラムが提供されなくなり、脆弱性を悪用した攻撃が成功す る可能性が高まります。 サポートが継続しているOSへの移行検討とOS移行に伴う周辺ソフトウェアの 影響調査や改修等について計画的に迅速な対応をお願いします。 業務システム・サービスの停止・破壊 重要な情報の漏えい データ消去 ホームページの改ざん 脆弱性を 悪用した攻撃 脆弱性が 未解決なサーバ 他のシステムへの攻撃に悪用 会社の事業に悪影響を及ぼす被害を受ける可能性があります 詳しくは IPA win2003 検索 ■WindowsXPを利用されている方は、サポートが継続しているOSへの移行検討をお願いします Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー IPA XP移行 検索 Software Reliability Enhancement Center 66 国家試験 iパスは、IT化された社会で働く すべての社会人が備えておくべき ITに関する基礎知識を証明する国 家試験です。 日本の元気 をiパスで！ 公式キャラクター 上峰 亜衣 ｉパス Copyright © 2013-2014 IPA, All Rights Reserved 検索 KIISセミナー Software Reliability Enhancement Center 67 IPA ソフトウェア高信頼化センター(SEC) Software Reliability Enhancement Center , Information-technology Promotion Agency , Japan Twitterで、 で、 IPA/SECの最新情報をCatch！ IPA/SECの事業内容やセミナー動画をCheck！ https://twitter.com/IPA_SEC ●SECセミナーオンデマンド http://sec.ipa.go.jp/seminar/ondemand/ ●SEC事業紹介 http://www.ipa.go.jp/sec/about/index.html アカウント名：＠IPA_SEC IPA/SECウェブサイトで利用者登録！ SWE iPediaで、 IPA/SECの事業成果をSearch！ 探したい情報を IPA/SECウェブサイトから利用者登録（無料）をすると、 メルマガ ・DMの購読や、セミナーの参加申込み、ツールの 利用などができます。 是非、ご登録ください！ https://sec.ipa.go.jp/entry/index.html 分類やキーワードで検索！ ↓詳しくは、SECウェブサイトをClick！ http://sec.ipa.go.jp/sweipedia/ 検索 Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー ソフトウェア高信頼化センター Software Reliability Enhancement Center 68 以降，参考 Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 69 １．IPA/SECの概要 IPA，及びSECについて IPA: 信頼性，セキュリティ，人材育成の一体的取組み 本日の 対象 Ｊ－ＣＳＩＰ（サイバー情報共有） 制御機器のＥＤＳＡ認証制度 脆弱性対策情報（ＪＶＮ） セキュリティ被害の届出・相談 暗号技術 重要インフラ等高信頼化対策 ソフトウェア品質説明力強化 ソフトウェア・サプライチェーン ソフトウェア工学先導研究支援 文字情報基盤、共通語彙基盤 情報処理技術者試験（ｉ-パス） 未踏IT人材育成 セキュリティ・キャンプ ＩＴ人材白書 SEC（ソフトウェア高信頼化 センター）の事業項目 (参考：過去の活動) ソフトウェアエンジニアリングの成果 Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 70 １．IPA/SECの概要 IPA/SECの活動 H24年度まで：ソフトウェア・エンジニアリング H25年度から：情報処理システム・ソフトウェア障害の対策，教訓共有等 重点：生産性・信頼性向上から安全・安心へ 対象：企業・業界レベルから国民レベルへ 学会 大学 SEC 開発競争力強化 から高信頼化へ 産業界 連携の場 ベンダ企業 ・ ベスト・プラクティスの収集・普及 ・ 開発手法・技術の開発と実証実験 研究機関・ 研究団体 Copyright © 2013-2014 IPA, All Rights Reserved ユーザ企業 ・ 現場課題に基づく共同研究，など 業界団体 KIISセミナー Software Reliability Enhancement Center 71 １．IPA/SECの概要 エンタプライズ系を中心とする取組みの全体像 GQM+Strategies® 「共通フレーム」 「高回復力 システム基 盤導入ガイ ド」 「非機能要 求グレード」 「機能要件 の合意形成 ガイド」 ラ イ フ ・ サ イ ク ル ・ プ ロ セ ス と 関 係 「超上流」の開発プロセス 共有化 システム化 構想，計画 「ITプロジェクト の見える化」 シリーズ 環境 変化 対応 利害関係者 要件 システム 要件定義 要求工学 見積り プ ロ セ ス に 共 通 「続 定量的品質予測のススメ」 Copyright © 2013-2014 IPA, All Rights Reserved 国際標準化 運用テスト 保守 保守開発 (改良開発/ 要求発展型開発) システム 適格性確認テスト トレーサビリティ システム 方式設計 <CoBRA見積りツール>の開発・公開 「プロセス改善 ナビゲーション ガイド」シリーズ 投資効果， 業務効果 システム結合 ソフトウェア 要件定義 ソフトウェア 方式設計 ソフトウェア 適格性確認テスト 設計開発 ソフトウェア 技術 結合 詳細設計・作成 見積り (改良開発) プロセス改善 プロジェクトの「見える化」 定量的プロジェクト管理 高信頼化手法 クラウド・コ ンピューティ ング 運用 非ウォーター フォール型 開発 <定量的プロジェクト管理 ツール>の開発・公開 <各種プロジェクト診断 ツール>の開発・公開 <信頼性自己診断 ツール>の開発・公開 「高信頼化ソフトウェアのた 「ソフトウェア開発データ白書」 めの開発手法ガイドブック」 KIISセミナー Software Reliability Enhancement Center 72 １．IPA/SECの概要 ソフトウェア・エンジニアリング関連の成果 ＜H24年度までの主な成果＞ ◇エンタプライズ系 • 経営者が参画する要求品質の確保 ～超上流から攻めるITの勘どころ～ • ITプロジェクトの「見える化」 • ソフトウェア開発データ白書 • ソフトウェア開発見積りガイドブックシリーズ • 共通フレーム • 機能要件の合意形成ガイド • 非機能要求グレード • プロセス改善手法（SPEAK-IPA，SPINA3CH） • アジャイル開発関連報告書 • GQM+Strategies • 高回復力システム基盤導入ガイド • 高信頼化ソフトウェア開発手法ガイドブック • 重要インフラ情報システム信頼性研究会関連報告書 など ◇組込み系 • 高品質な組込みソフトウェア開発（ESxRシリーズ） • 組込みスキル標準（ETSSシリーズ） など Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 73 過去の障害発生事例 組込みソフトウェアの不具合事例 Therac-25による放射線過剰被爆事故 ソフトウェア制御の放射線治療を行なう医療装置 4つの医療センターで6名の患者が莫大な被爆をし、 少なくとも5名が死亡 （1985～1987） 原因：ソフトウェアのバグ、不十分な検査 エアバスA320の墜落事故 初めて全面的なフライバイワイヤ （電気信号による自動操縦） を 採用した航空機A320 4機が墜落事故を起こす （1988～1993） 原因：コンピュータの接地検出ミス （当初は、パイロットミスと見られていた） Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 74 過去の障害発生事例 名古屋空港で中華航空機が着陸に失敗炎上 出典： 畑村創造工学研究所・ 失敗知識データベース http://www.sozogaku.com /fkd/cf/CA0000621.html 中華航空140便(エアバスA300-600R)はアウターマーカー通過、着陸態勢に入った。 自動操縦装置がゴー・アラウンド・モードになり、パイロットによる操縦輪の操作とオートマチック・フライト・ システム(AFS)の作動が相反しトリマブル・ホリゾンタル・スタビライザー(THS)がアウト・オブ・トリム状況に 陥り、パイロットが懸命に機首を下げようとする意図に反してコンピュータに制御された水平尾翼が機首 上げの方向に反発し続けたため失速、墜落炎上した。 自動操縦と手動操縦の二つの系統の制御コンフリクトが、この重大事故の根源をなすもので、 人間とコンピュータのどちらの命令が優先されるかが焦点となる。 Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 75 過去の障害発生事例 発熱 ー 実はソフトの不具合 （ＭＥＴＩ製品安全ガイド ＨＰ より） 「docomo PRO series BlackBerry® BoldTM」の発熱事象 に関する対処方法および販売再開のお知らせ 2009年4月7日 … 携帯電話が発熱するという事象が確認されました。 この度、本事象の原因が、電源を制御するソフトウェアの不具合 によるものであると明らかになり、… https://www.nttdocomo.co.jp/info/notice/page/090407_00.html Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 76 過去の障害発生事例 電子カルテシステムの不具合 事務連絡 平成22 年12 月27 日 都道府県 各 保健所を設置する市 特別区 衛生主管部（局）御中 厚生労働省医政局総務課 厚生労働省医政局政策医療課 診療システム（電子カルテ）不具合による薬剤誤投与について （注意喚起） 今般、医療機関において、診療システム（電子カルテ）の不具合により、医師の意図とは異なる内 容の処方指示が作成され、誤った投薬が行われた事例が発生致しました。 （別紙参照） つきましては、下記の留意事項について、貴管下医療機関への注意喚起方よろしくお願いします 記 １． 医療情報システムについて、導入時に入念な検証を行うとともに、定期的に内部監査を実施 する等、当該機器が正常に動作するよう適切な管理を行うこと。 ２． 医療情報システムの誤作動を認めた場合は、速やかにシステム管理業者に連絡を行うこと。 Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 77 過去の障害発生事例 新幹線運行管理システムの障害（１） 2008.12.29 東北、秋田、山形、上越、長野の各新幹線が止まる、13万人に影響 JR東日本の東北、上越、山形、秋田の各新幹線は29 日、運行管理システムに障害があり、始発から運転を見 合わせた。 同社によると、障害があったのは東京都千代田区丸の 内の新幹線運行本部内にあるコスモス(COSMOS)と呼ば れる運行を管理するメインシステム。29日午前0時から午 後6時までのシステム切り替え作業中に障害が発生し、 システム内の日付が切り替わらなくなったと見られる。前 日までに悪天候や車両トラブルの影響でダイヤの乱れが 相次いだことで入力作業に時間がかかったらしい。 JR東日本でトラブルの原因が、ソフトウェアの不具合な のか、人的要因によるものなのか、詳しく調査している が、午前9時までに全線で運転を再開した。 出典：MSN産経ニュース，2008年12月29日 Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 78 過去の障害発生事例 新幹線運行管理システムの障害（２） JR東日本の全新幹線でシステム障害、約1時間に亘り不通に 【2011年1月17日】 朝日新聞・読売新聞によると、1月17日（UTC+9）午前8時20分（朝日では 午前8時23分）頃、JR東日本の全新幹線を管理するシステムで障害が発生 し、東北・上越・長野・山形・秋田の各新幹線が全線で運転がストップした。 朝日新聞によると、一時、列車8本が立ち往生し、1時間15分後には全線で運行再開したが、 昼過ぎまで運休や遅れが生じ、8万1,000人以上の利用客が影響を受けた。 読売新聞が同社の話として伝えたところによると、障害が発生したのは、新幹線の運行をコン ピュータで一括管理するシステム・『COSMOS（コスモス）』。東京に設けられている新幹線運行 本部内のディスプレイ計22台に於いて、運行ダイヤを管理するデータの一部の表示が、画面か ら一時的に消失するなどした。同社は安全が確保できないとして、同社管内の全新幹線の運転 をストップさせた。その後システムの動作確認作業を実施したところ、画面の表示が正常な状態 に戻ったため、運行を再開した。 朝日新聞によると、『COSMOS』は、同社管内で新幹線の路線が増加したことを受け、1995年 から使用開始。運行管理や情報監視など7種類のサブシステムから構成され、新幹線の運行に 関係する全業務を一元管理している。今回のトラブルでは、サブシステムの一部がダウンした のみだったため、短時間で復旧できた模様である。 出典：ウィキニュース Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 79 過去の障害発生事例 銀行オンラインシステムの障害 2011/03/18 朝日新聞 みずほ ＡＴＭ障害止まらず きょうも一部停止 4日連続 2011/03/22 日経新聞 みずほ銀，遅れる完全復旧 コンビニＡＴＭや融資，午後から … サービス一部 なお制限 2011/04/02 週刊ダイヤモンド 震災のさなかにシステム障害 機能不全に陥ったみずほ銀の窮地 Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 80 過去の障害発生事例 株式売買システムの障害 ２月２日午前７時３８分、株式売買システムで一部の銘柄の相場情報が配信できないという事象 が発生。 その後、同システムのうち、相場情報を配信する情報配信ゲートウェイサーバー８台のうちの１台 で、同日午前１時２７分に発生したハード障害を契機とした予備系への切替え処理が正常に完了 していないことが原因であることが判明。 同システム障害の原因は、サーバーを三重化することによって高い信 頼性を確保すること、 障害診断ツールを整備して確実に障害を検知する仕組みを構築する こと等の取組みから、システムの信頼性を過信していたため、職員が 主体的にシステムの状態を確認せず、問題なしと判断したこと。 本来であれば、本システムの稼働状況を、常時、監視及び確認できる 体制を敷くべきが、深夜・早朝時間帯の十分な監視体制が未整備。ま た、業務に影響を与える可能性がある障害が発生した場合には、経営 陣まで報告すべきが、業務に影響があると確定した場合に経営陣まで 報告するルールとなっていたため、障害発生時の報告体制に不備あり。 出典：東京証券取引所「株式売買システムの障害発生に関する再発防止措置等について」(2012年2月16日) http://www.tse.or.jp/news/03/b7gje6000002bfdr-att/b7gje6000002bfkq.pdf Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 81 過去の障害発生事例 レンタルサーバーのデータ消失、混乱続く ヤフーの子会社「ファーストサーバ」（ 大阪市） が提供する レンタルサーバーで６月、５千を超す企業などのデータが消 失した問題は、復旧作業中に顧客のデータが他の顧客に流 出するなど混乱が続いている。クラウドサービスへの依存が 高まる中でのトラブルに、専門家は「サービスのリスクを、利 用者にも分かりやすく示すしくみが必要」と指摘する。 原因は６月20日夕に行ったサーバーの安全対策のための アップデート作業。このプログラムに不具合があり、特定 サーバーの一部のファイルを削除するはずが、同じネット ワーク内のサーバーの全データが削除された。提供サー バーのデータは毎朝１回、別のサーバーにバックアップを とっていたが、同様のアップデート作業を行ったため、こちら もすべて削除してしまったという。 同社は消失データを復旧させるプログラムを使った復元 データを、21日から順次、顧客に提供した。ところが、今度 は復元データに複数の顧客のデータが混入し、情報漏出し ていたことが判明、22日に提供を中止した。2308件の顧客 のデータが145件の別の顧客データに混入した可能性があ るという。 出典：朝日新聞(2012年7月7日) Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー 図の出典：ファーストサーバ株式会社 http://support.fsv.jp/urgent/report.html Software Reliability Enhancement Center 82 H26年度発生の主な重要インフラシステム障害（報道） 4/7 4/22 4/25 4/30 6/5 6/25 8/4 日本生命査定システム障害 三井住友銀行ATM障害 八十二銀行ATM障害 三菱東京UFJ銀行自動送金サービス障害 JAL重量バランスシステム障害 スカパーシステム障害 世田谷区役所システム障害 各事業者の窓口に連絡しても，ほとんど情報は得られない． 報告が公開された場合にも，情報はあまり詳しくなく，参考とはなりにくい． 個人的なルートで情報を入手しても，公のためには役立てられない． Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 83 他所での障害事例に対する意識 自分たちのシステムは大丈夫（障害は発生しない） その根拠は？ その障害は，自分たちのシステムとは関係ない そのように思う理由は？ その障害事例は，自分たちの参考にはならない もっとよく考えてみましょう Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 84 「正常化の偏見」 人の性：「自分だけは大丈夫」と思う … 正常化の偏見※ → 確かに大丈夫，という確認が必要 ※ (出典)人はなぜ「自分は大丈夫」と思うのか，防災研究家の片田群馬大学教授に聞く，ITpro 2007/04/11 http://itpro.nikkeibp.co.jp/article/Interview/20070409/267753/ Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 85 もう一つの効果（目的）：経験の継承 メインフレーム → 分散（Ｃ／Ｓ）システム → クラウドコンピューティング 自分は先輩と同じような間違いを犯していないか？ 後輩は自分と同じような間違いを犯しはしないか？ → 他所のシステム障害にも目を向ける Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 86 社会智（１／４） 『津波てんでんこ』 東北地方を中心に語られる防災教訓の一つ 「津波が来たら、各自てんでんばらばらに高台へと逃げろ」 昔から津波の多かった三陸沿岸地域で語り継がれてきた内容（体験 に基づくもの） この教訓の精神に基づいて、日頃の備えや訓練を行っておくことによ り、津波の被害から免れることができる 東日本大震災における「釜石の奇跡」と呼ばれる事例で実証済 Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 87 社会智（２／４） 医療・医学における知見例 数多くの協力者からの収集データの分析によりまとめられたもの 生涯を通した喫煙量と乳がんとの関係 (非喫煙者のリスクを１とする) 禁煙者 非喫煙者 喫煙指数 20未満 喫煙指数 20～34.9 喫煙指数 35以上 喫煙継続者 (＊＊) 乳がん再発 1 0.98 (*) 1.22 1.37 1.41 乳がん死亡 1 0.99 (*) 1.14 (*) 1.54 1.61 総死亡 1 0.97 (*) 1.26 1.68 2.17 (*) 誤差範囲に留まる結果 (**) 喫煙継続者の喫煙指数の平均は３９ 出典：乳がんと喫煙――「いつやめるか？」「今でしょ！」と言いたくなるデータ (朝日新聞，2014.1.14) Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 88 社会智（３／４） ＜ポイント＞ 暗黙知の形式知化 経験をデータに基づいて見える化，整理・体系化 社会智 社会にとって役立つ知見 智の運用 知見に基づき行動する，知見を継承するための，不断の努力 情報の(セミ)オープン化 智の共有による，社会（自身もその一員）への恩恵 多様な意見に基づく，ブレークスルー/イノベーションの創出 Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 89 社会智（４／４） 知とその共有に関する進化 見える化 形式知 （知識） 暗黙知 個有 分析・体系的整理 個人が 目指すところ 現状 組織 形式知 （智恵） 企業が 目指すところ 現状 共有 社会 現状 当面の マイルストーン 人類が 目指すところ ＜参考文献＞ 山下: 社会の“インテリジェンス”活用推進に向けた考察, SEC journal, No.23. Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 90 データに基づく管理の分類 データ 手法 見える化ツール 作業日報等 ビッグデータ解析 (分析) なし 定 失敗事例 性 障害事例 定 開発データ 量 運用データ 主な活用方法 因果関係確認等 (分析) チェックリスト (2)(3) 妥当性確認(問題 （例:信頼性自己診断ツール） 点抽出) (分析) 教訓集 (1)(2) 再発防止策 定量的プロジェクト管 異常の予兆検知 インプロセス計測 (4) 比較による計画策 理ツール (*) (5) 定・妥当性確認 ベンチマーキング (分析) データ白書 ビッグデータ解析 (分析) なし 障害予兆検知等 (*) 定量的品質予測，等 ソフトウェア リポジトリ データマイニング (1) 情報システムの障害状況の整理 (3) 信頼性自己診断ツール (4) 定量的プロジェクト管理ツール(EPM-X) Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー 活用（確認・対策等)のための 知見の抽出 (2) 障害情報の収集・分析に基づく教訓の共有 (5) ソフトウェア開発データ白書 Software Reliability Enhancement Center 91 H25年度の「教訓集」概要 障害対策手法・事例の分類 障害対策手法と参考文献 領域 ① ② 超上流工程での要求 トレーサビ 品質管理 リティ管理 ・ユーザ企業内の事業 対策事例 部門と情シス部門との に対応す 連携 る教訓ID ・ユーザ企業とベンダ 企業の連携、 合意形成 参照SEC BOOKS等⇒ 文献１、文献２ ガバナンス /マネジメン ト領域 技術領域 Ｇ１ Ｇ２ 文献３ ③ ④ ⑤ 「見える化」 要求獲得 変更管理 手法 手法 ・暗黙知の 整備・有 効活用 ・俯瞰図 ⑥ ⑦ フェール 網羅的テスト技法 ソフト ・テスト環境の リスク管理 ・シミュレーション 手法 関連対策を含めて体系的 に理解する際に有効 文献４ 文献５ ⑧ ⑨ 可用性管理 非機能要 ・システムの冗長 求グレード 化設計 ・シングルポイント の洗出し ・障害運用マニュ アルの整備と 訓練 文献6、文献7 文献８ ○ ○ Ｔ１ Ｔ２ Ｔ３ Ｔ４ Ｔ５ Ｔ６ Ｔ７ Copyright © 2013-2014 IPA, All Rights Reserved ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ KIISセミナー Software Reliability Enhancement Center ○ 92 H25年度の「教訓集」概要 情報の流れのモデルと機密保持等のルールの適用局面 情報の流れのモデル 情報提供者 情報管理者 （IPA） 共有グループ （部会） 教訓利用者 ルールの適用局面（義務を負う者） 情報提供者か ら預かった障 害情報の管理 （情報管理者） 共有グループへ の情報開示時 （情報管理者） 共有グループ での議論時 （共有グループ メンバ） 教訓の公開時 （情報管理者） 1 情報管理者が、個別ヒア リング等により提供された 障害情報を取り扱う場合 情報提供者と の間で、機密 保持のルール を適用 情報提供者と の間で、加工情 報の共有に係 るルールを適用 情報管理者と の間で、機密 保持のルール を適用 情報提供者と の間で、公開 のための情報 加工のルール を適用 適用なし 適用なし 2 共有グループのメンバが、 障害情報をグループ内に 直接開示した場合 共有メンバ間 で、機密保持 のルールを適 用 情報提供者と の間で、公開 のための情報 加工のルール を適用 No. 収集方法 (注)ここでは、情報管理者をIPA、共有グループをIPA内に設置された部会として説明する。 また、共有グループの運用を情報管理者が行うことを前提としている。 情報管理者は共有グループのメンバでもある。 これらは、本ルールの適用先に応じ、適切な組織・会議体に置き換えることになる。 Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 93 参考 「サイバーセキュリティ戦略」 出典： NISC ,「サイバーセキュリティ2013」（案）について,平成25年6月27日,P4 Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 94 参考 重要インフラの情報セキュリティ対策に係る 第３次行動計画の概要 出典： NISC ,重要インフラの情報セキュリティ対策に係る第３次行動計画の概要,平成26年10月10日,P2 Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 95 参考：セキュリティ サイバーセキュリティ情報共有活動 ［J-CSIP］ 2013年度 実施件数 Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 96 参考：航空 航空安全情報自発報告制度 [ VOICES ](1/2) 2014年度から国土交通省航空局の「航空安全プロ グラム」が開始されたことに伴い始まった安全情 報の報告制度 法令等で定められた事故やインシデント等に関す る義務的な報告制度だけでは捉えきれない多くの 情報を収集し、航空の安全向上のために活用 航空活動に直接携わっておられる方々（個人また はその所属する事業者等の組織）から，自ら経験 または視認した航空の安全上の支障を及ぼす可能 性があったと思われる事象（いわゆるヒヤリハッ ト）についての報告を収集し，業務実施者間で情 報を共有するとともに，それらの情報を分析して 必要と思われる改善を提案することにより，航空 の安全向上に寄与 そのヒヤリ！ さっきのハット！を 役立てます！ 出典： 航空安全情報自発報告制度（VOICES) について http://www.jihatsu.jp/index.html 報告者保護の観点から，航空安全当局（国土交通省航空局）や報告者の所属する組織以外 の第三者機関が運営を行う． 航空安全当局は，報告者の個人，会社名等が特定される情報の提供を制度運営者に対し求 めない，本制度に提供された情報を行政処分等の不利益処分の根拠として使用しない． Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 97 参考：航空 航空安全情報自発報告制度 [ VOICES ](2/2) 公益財団法人 航空輸送技術研究センター（ATEC）が運営 航空安全情報自発報告サイト https://asicss.cab.mlit.go.jp/voluntary/ 報告の受付け 分析担当者によるヒアリング 情報の秘匿化 分析作業とフィードバック VOICESポータルサイト にて周知，等 Copyright © 2013-2014 IPA, All Rights Reserved 出典：航空安全情報自発報告制度（VOICES) について http://www.jihatsu.jp/FAQ/index.html#pageLink02 KIISセミナー Software Reliability Enhancement Center 98 参考：原子力 原子力施設情報公開ライブラリー ［NUCIA］ (1/2) 原子力施設情報公開ライブラリーを意味する英語の名称 NUClear Information Archives の頭文字をとった略 称で、国内原子力発電所や原子燃料サイクル施設の運 転に関する情報を広く共有化するためのサイトです。 http://www.nucia.jp/index.html Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 99 参考：原子力 原子力施設情報公開ライブラリー ［NUCIA］(2/2) トラブル情報等 「トラブル情報」 「保全品質情報」 Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 100 参考：金融 金融ISAC (1/1) 金融機関間のサイバーセキュリティに関する情報を共有するための組織 http://www.f-isac.jp/index.html （2014年8月1日設立） 高度化するサイバー攻撃に対抗するため、フィッシング被害、不正送金被害、 APT攻撃、DDoS攻撃、脆弱性・ゼロディの脅威等のサイバーセキュリティに関 する情報を、会員である金融機関で共有し連携して対策に当たる。 すでに米国には同様の組織があり（FS-ISAC：Financial Services Information Sharing and Analysis Center）、4,600社を超える金融機関が会員となって活 動しているが、金融ISACはFS-ISACとも連携し、情報共有を促進。また、国内 の組織とも積極的に連携していく予定。 出典： 一般社団法人 金融ISACの設立について http://www.f-isac.jp/new4.html 参考： 米国のセキュリティ情報共有組織（ISAC）の状況と運用実態に関する調査 平成22年3月 株式会社 三菱総合研究所 http://www.nisc.go.jp/inquiry/pdf/fy21-isac.pdf IT-ISAC, Chemical ISAC, Communication ISAC, ES-ISAC(エネルギー), FS-ISAC(政府施設), MS-ISAC等がある．ES-ISACのみ，システム障害情報も共有． Copyright © 2013-2014 IPA, All Rights Reserved KIISセミナー Software Reliability Enhancement Center 101