contents memorandum はてな

目次とメモを置いとく場

『ITリスクの考え方』(佐々木良一 岩波新書 2008)

著者:佐々木 良一 [ささき・りょういち](1947-) 
NDC:007.609 データ処理、情報処理


ITリスクの考え方 - 岩波書店



【目次】
はじめに――「リスク対リスク」の時代に [i-viii]
  変化する情報セキュリティ
  ITリスクに向き合う
目次 [ix-xii]


第1章 情報セキュリティからITリスクへ 001
1 情報セキュリティとは 002
  セキュリティへの脅威
  セキュリティ対策

2 取組みはどのように進んだか 009
  政府の情報セキュリティへの対応
  民間における情報セキュリティの一般的な動向
  新しい分野の情報セキュリティ
  証拠性の確保のためのデジタル・フォレンジック【Digital Forensics】の登場

3 情報セキュリティからITリスクへ 028


第2章 「二〇〇〇年問題」を再考する 033
1 一九九九年一二月三一日の風景 034

2「二〇〇〇年問題」とは何であったか 037

3 何を調査したか 040

4 政府、マスメディア、専門家などの対応 041
  政府の対応
  企業の対応
  マスメディアの対応
  専門家の対応
  住民の対応

5 「二〇〇〇年問題」の検証から 059


第3章 「リスク」を考えるということ 063
1 リスクとは何か 064

2 リスクへの基本的姿勢 069

3 リスク対策のために必要となるもの 073
  リスクマネジメント
  リスクアセスメント
  リスクコミュニケーション
  リスク研究

4 リスクアセスメント 077
  疫学的アプローチ
  量―反応関係(Dose-Response Relationship)分析
  影響モデル
  確率モデル
  評価基準モデル
    (1) 基準クリア型
    (2) リスク-ベネフィット型
    (3) リスク-リスク型
    (4) 単純リスク比較型
    (5) リスク-コスト比較型
    (6) リスク-コスト-ベネフィット比較型
    (7) その他の型
  確率論的リスク評価

5 リスクコミュニケーション 093


第4章 ITリスクの問題群 101
1 個人情報漏洩リスク 103
  プライバシー権の考え方
  漏洩はどのようにして起こるか

2 暗号の危殆化のリスク 115
  デジタル署名の仕組み
  危殆化のパターン
  必要な対策

3 サイバーテロのリスク 126
  サイバーテロの例
  クライスマネジメントと組み合わせて

4 大規模情報システム故障のリスク 132
  ITシステムに対応した依存する社会
  むずかしい「バグ」への対応
  ソフトウェア工学の発展


第5章 ITリスクへのアプローチ 141
1 ITリスクの特徴 142
  リスクを考えるときに
  ITリスクの特徴

2 ITリスク学へ 146
  ITリスク学を支える分野
  ITリスク学を構成するもの
  ITリスクマネジメントの従来の対応
  ITリスクコミュニケーション
  
3 ITリスクへの総合的アプローチの試み 164
  従来の対応の問題点
  多重リスクコミュニケータ(MRC)開発の背景
  MRCの概要
  MRCの適用手順
  合意形成実験の一例
  MRCの適用結果


終章 ITリスクに立ち向かう 185
  ITリスクへの対応を行う人
  専門家
  マスメディア関係者
  一般の人々


参考文献 [7-12]
索引 [1-6]





【抜き書き】


・リスク定義は分野ごとに異なる。
pp.64-65

1 リスクとは何か

 第2章までにおいて、リスクをひとまず「事故や被害や損失が生じる可能性」であり、「事故や被害や損失の規模だけでなくその発生確率の概念もいれて評価すべきもの」とし、通常は、「リスク=事故の発生確率×事故の影響の大きさ」と定義するということで扱ってきた。ここで、もう一度「リスクとは何か」ということをもう少しきちんと考察して見ることにする。
 リスクは、英語のRiskの訳であり、危険と訳される場合もある。英語のRiskという語が登場するのは一六六〇年代のことであるといわれている。ハザードや災いを意味するイタリア語risico からの転用であるという説が有力だ。〔……〕
 リスクについては、経済学、社会学、公衆衛生学、食品安全学、原子力工学などの分野で、社会経済リスク、グローバルリスク、都市災害リスク、食品医薬品リスク、廃棄物リスク、放射線での健康リスク、環境リスク、自然災害リスクなどが扱われてきた。地球温暖化問題や、新型インフルエンザなどは、現在非常に注目を集めているリスクである。
 リスクの定義は扱う分野によって少しずつ異なる。共通するのは、「事故や被害や損失が生じる可能性」であり、「被害の規模だけでなく確率の概念も扱う」という点であろう。リスク一般の評価指標は、通常、「想定される影響の規模」と「その影響が生じる確率」の二つで扱われる。たとえば、飛行機事故に例をとれば、一回の墜落事故で何人の死者が出るかというのは、想定される影響の規模である。一方、飛行何回につき墜落事故が何回起きるかという比率で表すのは、その影響が生じる確率である。



・「2000年問題」について。


pp.37-39

 確認の意味で繰り返すが、二〇〇〇年問題とは、「西暦年を下二桁で処理しているコンピュータシステムにおいて、西暦二〇〇〇年が「〇〇」年と処理されることにより、二〇〇〇年が一九〇〇年として認識されることが原因で発生する問題のこと」である。昔のコンピュータでは、西暦年を下二桁で表記することが通例であった。これには次のような理由があった。
 (1) 保存するデータ量を減らすため。一九六〇〜一九八〇年代のコンピュータの導入、普及時期においては、メモリやハードディスクは非常に高価であったため、保存するデータを少なくする必要があった。
 (2) 人力の手間を減らすため。これは、現在でも望ましい処置であり、入力ミスを減らすことにもなる。

 二〇〇〇年問題は一九七〇年代から認識されており、さらに途中から、技術的にもコスト的にも四桁で表示することに問題がなくなっていたのにも拘わらず、二〇〇〇年問題を有するプログラムは継続して使用された。この大きな理由は、コンピュータシステムにおける既存データの互換性確保や、修正に伴うバグの作りこみを恐れたためだと考えられる。
 二〇〇〇年問題によって起こりうる障害は、調査により、以下のように分類することができることがわかった。

①日付が設定できない
②期間計算に誤りが生じる:
   (a) 年数の計算
   (b) 閏年の計算
③必要なデータが抽出されない
④日付順にデータが正しく並ばない

 このようなことは確実に起こることであり、早い段階では、銀行などのメインフレーム(大型コンピュータ)に関する二〇〇〇年問題だけが注目され、対策が実施されてきた。しかし、一九九七年半ばに、マイコンなどを利用する組み込みチップにも日付のデータが含まれていることが確認されると、起こりうる障害が大幅に増え、問題が深刻になった。しかも、組み込みチップは数が極端に多く、限られた期間では対策しきれないという問題があった。
 日付の誤認識によって誘発される大規模な障害は、以下のように大別することができることがわかった。

①インフラの混乱:
   (a)発電機能の停止や誤作動とそれに伴う停電
   (b)銀行、株式市場など金融関連の機能停止
②事故発生:
   (a)飛行機の墜落
   (b)ミサイル誤発射
③世界経済への影響:
   (a)経済への大きな打撃
   (b)オイルショック

 一九九九年前半になると、組み込みチップによるミサイルの誤発射などの事故発生が大きな問題として議論されるようになった。



・「2038年問題」について。

 今後起こると考えられる二〇〇〇年問題と類似の問題として二〇三八年問題がある。二〇三八年問題とは、一部のOS(基本ソフト)やプログラミング言語処理系の仕様により、一部のコンピュータが西暦二〇三八年以降の日付や時刻を正しく扱えなくなることにより起こる問題である。
 古いUNIX - OSやC言語では、三一ビットのメモリを用いて、一九七〇年一月一日午前〇時(世界標準時)からの経過秒数で時刻を管理している。経過秒数が三一ビットのメモリで扱える能力の上限を超えるのは世界標準時で二〇三八年一月一九日午前三時一四分八秒であり、この時点を越えると符号が負になり、日付が一九〇一年一二月一四日に戻る。それによりシステムが正常に動作しなくなると考えられている。二〇〇〇年問題はアプリケーションの仕様とデータ形式の問題であったのに対し、二〇三八年問題はC言語の処理系の実装に関わる問題でありその影響は大きいと考えられる。パソコン内の時計を二〇三八年まで進めてみると、実際に、システムが誤動作したり、マウスが動かなくなることを確認している。
 まだだいぶ先の話であるが、列車などは三〇年以上使われることも多く、この列車に組み込みマイコンが含まれる場合には、将来問題になる可能性がある。したがって、この問題にどのように対応していくかもリスクコミュニケーションとして大切になる。まず、最初は、政府、専門家、企業間のリスクコミュニケーションが必要となり、このような問題が発生しないようにするために、業者やボランタリーの開発者に対しOSやプログラミング言語処理系のソフトを早めに修正するよう勧告すべきであろう。それができない場合は、政府はマイコンソフトなどの開発者に対して、問題のあるソフトを使っているかどうかを後から確認できるように記録するなどの指示を与えるべきである。住民との間のリスクコミュニケーションは二〇三七年に入ってからでよいと考えられる。