基本情報技術者 2014年 春期 午後 問01
情報資産についてのリスクアセスメントに関する次の記述を読んで、設問1〜3に答えよ。
Z社は、従業員数が500の中堅SIベンダである。Z社では、プロジェクト開始前に、プロジェクトで扱う情報資産について、図1に示す自社で定めた手順に従って、リスクアセスメントを実施している。このたび、新規に受注したプロジェクトYに対して、リスクアセスメントを実施することになった。

〔プロジェクトYの説明(抜粋)〕
(1) 顧客が利用する購買システムを開発する。
(2) 開発で利用するテストデータは顧客から提供される。
(3) 顧客のテストデータを格納した顧客のUSBメモリを、プロジェクトメンバが顧客から受け取って自社に持ち帰り、顧客のテストデータを開発用サーバに複写後、USBメモリから削除する。
(4) Z社から顧客の事務所を訪問するのに、電車で1時間30分ほど要する。
(5) 開発用PCでプログラムを開発し、適宜、開発用サーバにアップロードする。
〔Z社の開発環境(抜粋)〕
(1) プログラムの開発には、開発用サーバと開発用PCを利用する。
(2) 開発用サーバは、施錠されたサーバルームに設置されている。
(3) 開発用サーバは、アクセス管理がされており、プロジェクトメンバとシステム管理者だけがアクセスできる。
(4) 開発用PCは、プロジェクト開始時にシステム部から各プロジェクトメンバに貸与され、プロジェクト終了時に返却される。
〔Z社の開発標準(抜粋)〕
(1) 開発時、プロジェクトメンバは顧客のテストデータのうち必要なものだけを、開発用サーバから自分の開発用PCにダウンロードし、不要になったら削除する。
(2) プロジェクト終了時に、プロジェクトマネージャは開発用サーバの顧客のテストデータを削除し、全ての開発用PCから顧客のテストデータが削除されていることを確認する。
〔Z社のリスク値算出方法〕
Z社では、各情報資産のリスク値を、次の式で算出する。
リスク値 = 情報資産の価値 × 脅威 × 脆弱性
ここで、“情報資産の価値”とは情報資産が損なわれたときの影響の大きさを意味し、機密性(以下、Cという)、完全性(以下、Iという)、可用性(以下、Aという)の観点に対して、影響の大きさをそれぞれ1〜3の値で評価する。“脅威”は、発生の可能性の大きさを1〜3の値で評価する。“脆弱性”は、脅威が発生した場合に被害が顕在化する度合いの大きさを1〜3の値で評価する。ここで、各1〜3の値は大きい場合を3、小さい場合を1とする。
C、I、Aごとに算出したリスク値が全て12以下ならばリスクを受容し、そうでないならば追加のリスク対策を実施することにしている。
〔リスクの特定〕
① 情報資産の洗出し
プロジェクトYで扱う情報資産の洗出しを行った。その結果を、表1に示す。

② 情報資産の価値の数値化
表1の各情報資産に対して、C、I、Aのそれぞれについてその価値を評価した値と評価理由を、表2に示す。
③ 脅威の数値化
表2の情報資産のうち、情報資産No.4(顧客のテストデータ)について、脅威の内容と脅威の値を、表3に示す。

④ 脅威に対する脆弱性の数値化
表3の各脅威に対する脆弱性の低減策と脆弱性の値を、表4に示す。脆弱性の値は、システム、規則又は運用で、二つ以上対策済みなら1、一つだけなら2、未対策は3とする。
〔リスクの分析評価〕
表2〜4を基に情報資産No.4(顧客のテストデータ)のリスクの分析評価を行い、リスク値を算出した結果を、表5に示す。
プロジェクトYのプロジェクトマネージャは、リスクの分析評価の結果からリスク対応計画を作成した。その後、リスク対策を実施した。
設問1:
問題文を見る 表2中の(ⅱ)、(ⅲ)は、C、I、Aのいずれかの観点から“情報資産の価値”を評価した際の評価理由である。(ⅱ)、(ⅲ)に対応するC、I、Aの組合せとして適切な答えを、解答群の中から選べ。
解答群


模範解答
エ
解説
解答の導き方
この設問では、表2の評価理由(ii)、(iii)が、情報資産の価値をどの観点から評価したものかを見分けます。
まず、情報資産の価値を評価する観点は、C、I、Aの三つです。
- C(Confidentiality:機密性)は、情報を許可されていない人に見られないようにすることです。
- I(Integrity:完全性)は、情報が正確で、内容に食い違いがない状態を保つことです。
- A(Availability:可用性)は、必要なときに情報を利用できる状態を保つことです。
表2の(ii)には、「社外に漏れた場合、顧客からの信頼を失う」とあります。情報が社外に漏れることは、許可されていない人に情報を見られることです。そのため、(ii)は機密性、つまりCの観点です。
次に、(iii)には、「版管理が行われない場合、不整合によって、プロジェクトの進捗に影響を与える」とあります。版管理とは、プログラムの変更履歴や複数の版を管理することです。版管理が適切でないと、内容の異なるプログラムが混在して、情報に食い違いが生じることがあります。これは、情報を正確で一貫した状態に保つ完全性、つまりIの観点です。
したがって、(ii)がC、(iii)がIに当たる組合せを選びます。解答群では、これはエです。
なお、表2の(i)には「開発中のプログラムが利用できない場合」とあります。必要なときに利用できないという状況は可用性、つまりAの観点です。(i)も確認すると、三つの観点を区別しやすくなります。
誤りやすいポイント
- 「顧客からの信頼を失う」という影響だけに注目し、Cの観点を見落とすことがあります。判断の手掛かりは、その原因が「社外に漏れた場合」であることです。
- (iii)もプロジェクトの進捗に影響しますが、影響の内容だけでなく、その原因に注目します。原因は情報の不整合なので、Iの観点です。
- 情報が利用できないことと、情報の内容に食い違いがあることを混同しないようにします。前者はA、後者はIです。
FAQ
Q: 情報が漏れると、なぜ機密性の問題なのですか?
A: 機密性は、情報を許可された人だけが見られる状態を保つことだからです。社外に漏れると、許可されていない人に見られる可能性があります。
A: 機密性は、情報を許可された人だけが見られる状態を保つことだからです。社外に漏れると、許可されていない人に見られる可能性があります。
Q: 版管理が不十分だと、なぜ完全性の問題になるのですか?
A: 複数の版の内容に食い違いがあると、どの情報が正しいのか分からなくなるためです。情報を正確で一貫した状態に保つことが、完全性に当たります。
A: 複数の版の内容に食い違いがあると、どの情報が正しいのか分からなくなるためです。情報を正確で一貫した状態に保つことが、完全性に当たります。
Q: 「利用できない」場合は、いつも可用性の問題ですか?
A: 情報やシステムを必要なときに使えないことが問題なら、可用性の観点です。この設問の(i)も、プログラムが利用できないことによる影響を評価しています。
A: 情報やシステムを必要なときに使えないことが問題なら、可用性の観点です。この設問の(i)も、プログラムが利用できないことによる影響を評価しています。
関連キーワード: 機密性、完全性、可用性、情報資産、リスクアセスメント
設問2:
問題文を見る 情報資産No.4(顧客のテストデータ)に対するリスクの分析評価の結果、追加のリスク対策が必要になる脅威の数として正しい答えを、解答群の中から選べ。
解答群
ア:1
イ:2
ウ:3
エ:4
模範解答
イ
解説
解答の導き方
情報資産No.4(顧客のテストデータ)について、脅威ごとにリスク値を計算し、追加のリスク対策が必要な脅威を数えます。
リスク値は「情報資産の価値 × 脅威 × 脆弱性」で計算します。情報資産の価値は、C(Confidentiality:機密性)、I(Integrity:完全性)、A(Availability:可用性)の各観点で別々に計算します。
問題文には、C、I、Aごとのリスク値が「全て12以下ならばリスクを受容」し、それ以外の場合は追加のリスク対策を実施するとあります。したがって、脅威ごとに3つの値を確認し、1つでも12を超えていれば追加対策が必要です。
表5にある情報資産の価値は、Cが3、Iが2、Aが1です。脅威の値と脆弱性の値を掛けて、各観点のリスク値を求めます。
T1とT4では、Cのリスク値がどちらも18となり、基準の12を超えています。ほかの脅威は、C、I、Aの値が全て12以下です。
したがって、追加のリスク対策が必要になる脅威は、T1とT4の2つです。
誤りやすいポイント
- C、I、Aの値を合計して判定しないようにします。各観点を別々に計算し、どれか1つでも12を超えたら追加対策が必要です。
- リスク値がちょうど12の場合は、基準の「12以下」に含まれます。例えば、T1のIのリスク値は12ですが、これだけでは追加対策が必要とはなりません。
- 脅威の値だけで判定せず、情報資産の価値と脆弱性の値も掛け合わせます。
- 複数の脅威のリスク値を合計する問題ではありません。脅威ごとに判定し、追加対策が必要な脅威の数を数えます。
FAQ
Q: リスク値が12の場合も、追加のリスク対策が必要ですか?
A: 必要ありません。問題文では、C、I、Aごとのリスク値が全て12以下ならリスクを受容するとしています。12ちょうどは基準内です。
Q: T1はIのリスク値が12ですが、なぜ追加対策が必要なのですか?
A: T1はCのリスク値が18で、12を超えているからです。C、I、Aのうち1つでも12を超えると、追加対策が必要になります。
Q: 情報資産の価値と脅威の値だけでリスク値を計算できますか?
A: できません。問題文の式では、情報資産の価値に脅威と脆弱性の値を掛けます。脆弱性の値も含めて計算します。
関連キーワード: リスクアセスメント、リスク値、脅威、脆弱性、機密性・完全性・可用性
設問3:
問題文を見る 社内でのセキュリティ事故の発生と対策に関する次の記述中のに入れる適切な答えを、解答群の中から選べ。
プロジェクトYの終了後、新たに発足したプロジェクトXで利用している開発用PCに、プロジェクトYの顧客のテストデータが格納されている、とシステム部に連絡があった。調査した結果、このPCは、プロジェクトYで利用していた開発用PCであり、システム部に返却された後に、システム部からプロジェクトXに貸与されたものであることが判明した。そこで、Z社では、顧客のテストデータの漏えいというリスクに対処するために、a、bという対策を追加することにした。
解答群
ア:開発用サーバのアクセスログをシステム部が定期的に確認する
イ:顧客のテストデータを開発用PCにダウンロードして利用する場合は、管理台帳にダウンロード日、削除日、実施者を記入する
ウ:顧客のテストデータを開発用PCに保存する際に、警告メッセージが表示されるようにする
エ:プロジェクトごとに新たに開発用サーバを用意する
オ:プロジェクトメンバが開発用サーバ上の顧客のテストデータにアクセスする権限を参照だけに設定する
カ:返却された開発用PCは、システム部が全データを完全消去する工程を追加する
模範解答
a:イ、b:カ(順不同)
解説
解答の導き方
この設問では、プロジェクトYで使った顧客のテストデータが、プロジェクト終了後も開発用PCに残っていた問題に対して、どの対策を追加すればよいかを考えます。
まず、顧客のテストデータを扱う際のルールを確認します。Z社の開発標準には、プロジェクト終了時にプロジェクトマネージャが開発用PCからテストデータが削除されていることを確認するとあります。しかし、今回の調査では、プロジェクトYで使った開発用PCがシステム部に返却された後、プロジェクトXに貸与され、そこにテストデータが残っていました。
つまり、削除を確認するルールはあっても、確認漏れなどによってデータが残る可能性があります。別のプロジェクトのメンバがそのデータを見たり使ったりできる状態になれば、顧客の情報が関係のない人に渡るリスクがあります。
この問題を防ぐには、まず、開発用PCにデータを保存したときと削除したときの記録を残すことが有効です。解答群のイは、ダウンロード日、削除日、実施者を管理台帳に記入する対策です。誰がいつデータを保存し、削除したかを確認できるため、削除の確認漏れを見つけやすくなります。
さらに、PCが返却された後に、システム部が保存データを完全に消去する工程を加える必要があります。解答群のカなら、プロジェクト終了時の削除確認をすり抜けてデータが残っていても、次のプロジェクトに貸与する前に消去できます。
ほかの選択肢は、今回の原因に直接対応していません。たとえば、サーバのアクセスログを確認するアは、開発用PCに残ったデータを消去できません。開発用サーバをプロジェクトごとに用意するエや、サーバ上のデータを参照だけにするオも、PCにダウンロード済みのデータには対処できません。警告メッセージを表示するウだけでは、データが残っていないことを確認する仕組みになりません。
したがって、ダウンロードや削除の状況を記録するイと、返却されたPCのデータを完全に消去するカを追加するのが適切です。どちらをa、bに入れても順序は問いません。
誤りやすいポイント
-
開発用サーバの対策を選ぶこと
今回残っていたのは、サーバ上のデータではなく、開発用PCに保存されたデータです。対策も、PC上のデータが残る原因に向ける必要があります。 -
削除確認のルールがあるから問題ないと考えること
ルールがあっても、確認漏れなどでデータが残ることがあります。記録を残す対策と、返却時に完全消去する対策を組み合わせると、漏れを防ぎやすくなります。 -
警告を表示すれば十分だと考えること
警告は注意を促すだけで、データが実際に削除されたかまでは保証しません。
FAQ
Q: 管理台帳をつけるだけで、データの削除を保証できますか?
A: 台帳は、誰がいつデータを保存・削除したかを記録し、確認漏れを見つけやすくするものです。それだけで完全な削除を保証するわけではないため、返却時の完全消去も組み合わせます。
A: 台帳は、誰がいつデータを保存・削除したかを記録し、確認漏れを見つけやすくするものです。それだけで完全な削除を保証するわけではないため、返却時の完全消去も組み合わせます。
Q: なぜPCを返却するときに完全消去するのですか?
A: プロジェクト中の削除確認をすり抜けたデータが残っていても、次の人に貸し出す前に消去できるからです。
A: プロジェクト中の削除確認をすり抜けたデータが残っていても、次の人に貸し出す前に消去できるからです。
Q: 今回の問題でいう情報漏えいとは、社外にデータが出ることだけですか?
A: いいえ。顧客のテストデータを利用する必要のない別のプロジェクトの人が見られる状態になることも、情報が不適切に共有されるリスクにつながります。
A: いいえ。顧客のテストデータを利用する必要のない別のプロジェクトの人が見られる状態になることも、情報が不適切に共有されるリスクにつながります。
関連キーワード: リスクアセスメント、情報資産、脆弱性、アクセス制御、データ消去




