これは

放送大学大学院文化科学研究科の「ソフトウェア工学」という授業で使われる「ソフトウェア工学」という教材書籍を自分なりにまとめたものです.

第 2 章では, ソフトウェアの不具合が社会に及ぼす影響について事例を挙げながら, 要因の整理と対策をザックリと書かれていましたが, 以下のような印象を持ちました.

  • 日本で発生した幾つかの不具合について, ソフトウェア起因かもしれないけど, 結局は人間のミスや組織内の連携不備が被害を大きくしてしまう点について興味深かった
  • ソフトウェアの不具合が人命をも奪ってしまう (セラック-25) 事例にゾッとした
  • 失敗事例から学ぶことは一杯ありそうなので, これらが纏めらた書籍は一度読んでみたい

尚, 本まとめについては, 以下の Github リポジトリで管理しており, 加筆修正はリポジトリのみ行います.

inokappa/software_engineering
software_engineering - 放送大学大学院文化科学研究科 / ソフトウェア工学
GitHub

github.com

2. ソフトウェアの不具合がもたらす社会的影響

はじめに

  • ソフトウェアは社会の基盤として使われているが, 普段はその存在は意識されていない
  • ソフトウェアの信頼性, 安全性を確保することは, 社会から要請されている大きな課題である
  • ソフトウェアの不具合がもたらす影響と, それらの要因を整理し, 対策について概観する

1. システム・エラーの影響

(1) 情報システムの不具合事例

  • みずほ銀行のシステム障害
    • 2011/03/15
    • 3.11 の被災地への義援金振り込みが大量発生したことをきっかっけに発生した障害
    • オンライン業務を開始する前に終了しているべきバッチ処理が終了しないことがきっかけ
    • 原因は, 振込口座の 1 日の振込数の上限値設定に人為的なミスがあり, その後の処理に組織体制的にも, システム的にも問題があった
    • 2002 年 4 月の合併時にも大きなトラブルを起こしている…
  • JR 東日本のシステム・トラブル
    • 2011/1/17 AM 8:00 ~
    • JR 東日本の列車運行管理システム COSMOS に不具合があり, 5 つの新幹線が全面運行停止となった
    • システム障害ではなく, ソフトウェアの仕様が現場に徹底されていなかった為, システム障害と判断され列車の運行が停められた…
    • 2008 年 12 月にも同様の障害が起こっている (システムの性能の問題と, システムの使用上での人間のミスの複合)
    • みずほ銀行の事例と類似
  • みずほ証券の誤発注と東証システムの不具合
    • 2005/12/8
    • ジェイコム株式会社が東証マザーズ市場へ上場初日
    • みずほ証券の発注ミスが発端, 注文を取り消せない東証の売買システムの不備

(2) 組み込みシステムの不具合事例

組み込みシステムは, 機械や交通機関等を直接制御する為, 不具合が発生した際には制御されている機器をはじめ, それらを利用する器物に危害を及ぼすだけではなく, 人命にも関わることがある.

  • ロケット・宇宙機器の不具合
    • ヨーロッパの衛星打ち上げロケット「アリアン 5 号」
  • 金星探査を目指して NASA が打ち上げた「マリナー 1 号」
    • 1962 年
    • ソフトウェアの不具合により起動制御不能となり, 打ち上げ 5 分後に自爆装置により破壊された
  • 火星北極探査機 (Mars Polar Lander)
    • 1999 年 12 月
    • ソフトウェアの不具合により地上との交信が普通となって, 期待した成果が得られなかった
  • セラック-25 事件
    • 1985 年 ~ 1987 年, カナダとアメリカ
    • セラック-25 という放射線治療機器
    • ソフトウェアのエラーにより 6 人の患者に過剰な放射線を照射してしまう事件が 6 件
    • PDP11 上で動作する独自 OS のもとで放射線照射を制御するソフトウェアを稼働させていた
    • 並行処理でしばしば発生する競合条件への対処に問題があった
  • パナマでの放射線治療機器過剰照射事件
    • 1999 年 ~ 2000 年
    • パナマでがん治療を受けた 28 人の患者に対して放射線が過剰照射
    • IAEA (国際原子力機関) の調査によれば, 原因は制御ソフトウェアのエラー

(3) 大きな社会的損失

  • コンピュータによる自動化
    • 人が行ってきた機械操作, 判断をソフトウェアに置き換えることによって, うっかりミスや不整合な判断等が生じることを防ぐ
  • システムの構造と動作が複雑化
    • 人に委ねられる操作や判断は抽象化され, 人と機械のインターフェースが複雑化
    • 異常発生時に人が取る行動にエラーが起こりやすく, その影響も大きい
  • ソフトウェアの設計・開発時に起きる人為的なエラーの影響
    • 人の操作が減って, そこで起こるエラーが減っても, その分の仕事はソフトウェア開発者が担うことになる

2. コンピュータ犯罪

(1). 不正アクセスと個人情報保護

  • 悪意を持った第三者がシステムに侵入し, 情報を窃取・改ざん, 誤動作するように仕掛けることも起きる
  • ソフトウェアの設計に際しては, そのような犯罪的行為への防御も十分に配慮する必要がある
  • プレーステーション・ネットワーク
    • 2011 年 4 月
    • 世界で 7700 万人の個人情報が流出
    • 一ヶ月以上のサービス停止
    • Anonymous というハッカー集団 (クラッカー集団)
  • ハッカーとクラッカー
    • 天才的なプログラマという意味の「ハッカー」, 善意のハッカー「白帽ハッカー」
    • コンピュータへの不正侵入等を行うのが「クラッカー」, 「黒帽ハッカー」
  • サイバー戦争, 組織犯罪の暗躍
    • 不正アクセスが企業だけではなく, FBI や CIA, 米国上院等に及んでいる
    • 愉快犯によるものだけではなく, サイバーテロや国家間のサイバー戦争状態である
    • 組織犯罪の暗躍
  • 日本では
    • 1999 年に不正アクセス禁止法 (不正アクセス行為の禁止等に関する法律)
    • 個人のプライバシー保護という観点では, 2003 年に公布, 2005 年に施行された個人情報保護法が関連している

(2). システムの脆弱性を突く攻撃手段

  • SQL 注入 (SQL インジェクション)
    • ユーザーから入力値を適切にエスケープしないまま, データベースの問い合わせに利用されてしまい, 意図しない情報が引き出されてしまう
    • ソニー・プレーステーション・ネットワークの情報流出は SQL インジェクションが原因とされている
    • ユーザーの入力値を適切にエスケープすることが対策
  • バッファ溢れ (バッファーオーバーフロー)
    • バッファ領域の大きさを超えるようなデータが入った場合, それが溢れでて隣の記憶域を書き換えてしまう
    • バッファ溢れを起こさせて, プログラムを破壊したり, 動作を誤った方向に誘導したりする
    • 特に C や C++ は記憶域保護の仕組みが備えられていないので, この攻撃の対象となりやすい

(3). 黒帽ハッカーたち

  • Kevin Mitnick
  • Robert Tappan Morris
  • Jonathan James
  • Kevin Poulsen

3. 安全性や信頼性に関する用語と概念

(1) エラーの用語

  • 故障 (failure)
    • ハードウェアの場合, システムの構成要素が摩耗等の経年変化でその機能を失うこと
    • ソフトウェアの場合, 初期の設計ミスやコーディングミスで生じる機能の喪失を故障と呼ぶことが多い
  • 障害 (fault)
    • 故障を原因として問題が外部に顕在化したものを呼ぶ使い方が一般的
    • ソフトウェアの場合, 故障と障害の使い分けについては厳密では無い
  • 誤り / エラー (error)
    • 故障が障害のもととなる設計上の, また操作上の, 人による過失
    • 設計のエラーが回路やプログラム上に現れたものもエラーという (欠陥 defect と呼ばれることもある)
  • 機能不全 (malfunctio), 異常 (anomaly) 等も障害や故障とほぼ同義に用いられる

(2) 依存可能性 (dependability)

  1. 安全性 (safety)
  2. セキュリティ (security)
  3. 信頼性 (reliablity)
  4. 可用性 (availability)
  5. 保守性 (maintainability)

上記の性質を統合して兼ね備え, システムやソフトウェアが安心して使えるというより上位の概念として 依存可能性 (dependability) という用語が使われることが多くなっている.

4. リスク対策

(1) リスク管理

  • リスク管理とは (以下, 書籍より引用)

リスク要因を識別し, それらが起こる確率を予想し, リスクが行った時に生じる損害を推定し, リスク発生の確率と生じる損害との積が大きいものを優先して回避するために, 事前評価と実態監視を行い, またいったんリスクが現実化して事故が起きたときに, その被害が最小となるような対策を取る, という一連のプロセスをいう.

  • システム設計開発時にリスク要因を識別するには, 類似のシステムが起こした事故データを分析するのは一つの方法
  • ソフトウェアは経年劣化するわけではないので, 故障確率を過去のデータから推定することが出来ない
  • セラック-25 は事前にリスク解析は行われていたが, 当初はソフトウェアリスクは無視されていた
  • 問題発生後はリスク解析が行われていたが, ソフトウェアが起こす事象の故障率は, 一律 10 の -4 乗 (0.0001) として計算されていた

(2) 耐障害性と故障安全システム

  • 耐障害 (fault tolerant) システム
    • 障害がおこってもその影響を回避するシステム
    • 二重化
      • まったく同じ処理を 2 台で行う (3 台以上で多数決を取るという実装方式もある)
      • 負荷を 2 台に分散する
      • 通常は 1 台で稼働し, もう 1 台は待機していて, もし 1 台が故障したら待機している 1 台が代替する
      • 2 台以上の処理系が同時に故障しては意味が無いので, 処理系間にある独立性を存在していることが仮定される
    • ソフトウェアの場合には独立性が認められない (保証されない)
  • 故障安全 (fail safe) システム
    • システムに故障が発生した際に, 制御が常に安全側に動作するように設計されたシステム
    • フェイルソフト (フェイルセーフと耐障害の中間に位置する概念)
      • 故障が起きても被害を最小限に抑えつつ, システムをすぐに停止させずに軟着陸させる
    • ソフトウェアの場合
      • 例外処理の書き方の工夫, 場合分け処理で論理的に起こりえない場合に対しても対応するコードを書いておくこと

参考リンク

以上

まとめでした.

元記事はこちら

「ソフトウェア工学 「第 2 章 ソフトウェアの不具合がもたらす社会的影響」のまとめ」