データベースのアカウント権限は用途別にどう与えるか
情報セキュリティマネジメント試験 平成31年度春期 午前 問25 ／ セキュリティ › セキュリティ実装技術
過去問にチャレンジ
データベースのアカウントの種類とそれに付与する権限の組合せのうち，情報セキュリティ上，適切なものはどれか。
- ア
データ構造の定義用アカウント，レコードの更新権限：有，テーブルの作成・削除権限：無
- イ
データ構造の定義用アカウント，レコードの更新権限：無，テーブルの作成・削除権限：有
- ウ
データの入力・更新用アカウント，レコードの更新権限：有，テーブルの作成・削除権限：有
- エ
アカウント：データの入力・更新用、レコード更新権限：無、テーブル作成・削除権限：有
会話形式の解説
講師この問題では、データベースのアカウントを用途ごとに分けたときに、どの権限を与えるのが適切かが問われています。表には「データ構造の定義用」と「データの入力・更新用」の2種類のアカウントがあって、それぞれにレコードの更新権限とテーブルの作成・削除権限の有・無が書かれています。
受験者私は最初、両方とも「有」になっている入力・更新用の行がいいと思いました。権限がそろっていれば、作業で困ることがないからです。
講師たしかに便利そうに見えますね。ただ、情報セキュリティでは「最小権限の原則」という考え方が基本です。アカウントには業務に必要な範囲の権限だけを与える、という原則です。この原則で見ると、両方「有」の行には何が足りないでしょうか。
受験者足りないものはなくて、むしろ多すぎるということですね。入力・更新の業務なら、テーブルを作ったり消したりする権限はいらないはずです。
講師そのとおりです。いらない権限まで付いていると、操作を誤ったときや不正に使われたときに、テーブルそのものが消されるおそれがあります。なので、この行は不適切です。
受験者では、用途ごとに必要な権限を整理してみます。データ構造の定義用アカウントは、テーブルを作ったり削除したりするのが仕事なので、テーブルの作成・削除権限が必要です。レコードの更新権限はいりません。
講師はい。データの入力・更新用アカウントはその逆で、レコードの更新権限が必要で、テーブルの作成・削除権限はいりません。構造を決める権限とデータを書き換える権限を、別々のアカウントに分けて持たせるということです。
受験者そうすると、定義用アカウントでレコード更新が「有」、テーブル作成・削除が「無」の行は逆になっていますね。本来の構造定義ができないうえに、いらない更新権限が付いています。
講師よく見えています。入力・更新用アカウントでレコード更新が「無」、テーブル作成・削除が「有」の行も同じで、必要な権限と不要な権限が入れ替わっています。これでは本来の入力・更新ができません。
受験者残るのは、定義用アカウントでレコード更新が「無」、テーブル作成・削除が「有」の行です。必要な権限だけがあって、不要な権限は外されているので、これが正解ですね。
講師正解です。この種の問題では、各行を「必要な権限があるか」と「不要な権限が付いていないか」の二つの観点で確かめると、確実に絞り込めます。両方「有」の選択肢は業務に困らないので魅力的に見えますが、セキュリティでは権限が多すぎること自体が問題になる、という点を押さえておいてください。
まとめ
この問題は、用途別に分けたデータベースのアカウントに、どの権限を与えるのが適切かを問うものです。最小権限の原則に従い、アカウントには業務に必要な範囲の権限だけを与えます。データ構造の定義用アカウントにはテーブルの作成・削除権限が必要で、レコードの更新権限はいりません。データの入力・更新用アカウントはその逆です。両方の権限が「有」の行は便利に見えますが、権限が多すぎるので不適切です。
解答・解説
正解はイです
この問題のテーマ
データベースのアカウントを用途ごとに分けたとき、それぞれにどの権限を与えるのが適切かを問う問題です。最小権限の原則と、構造定義とデータ更新の権限分離が論点です。
解き方の考え方
まず、アカウントの用途ごとに「業務に必要な権限」を考えます。データ構造の定義用アカウントの仕事はテーブルを作ったり削除したりすることなので、テーブルの作成・削除権限は必要ですが、レコードの更新権限は必要ありません。データの入力・更新用アカウントはその逆で、レコードの更新権限は必要ですが、テーブルの作成・削除権限は必要ありません。この基準と表の「有／無」を一行ずつ照らし合わせ、必要な権限がそろっていて不要な権限が付いていない行を選びます。
選択肢ごとの解説
- ×ア データ構造の定義用アカウント，レコードの更新権限：有，テーブルの作成・削除権限：無データ構造の定義用アカウントなのに、テーブルの作成・削除権限が「無」になっています。これでは本来の構造定義の作業ができません。そのうえ、構造定義には要らないレコードの更新権限が「有」になっていて、必要な権限と不要な権限が逆になっています。
- ○イ データ構造の定義用アカウント，レコードの更新権限：無，テーブルの作成・削除権限：有データ構造の定義用アカウントに、構造定義に必要なテーブルの作成・削除権限だけが与えられています。不要なレコードの更新権限は外されているので、業務上必要な範囲に権限を限るという考え方に合っています。
- ×ウ データの入力・更新用アカウント，レコードの更新権限：有，テーブルの作成・削除権限：有データの入力・更新用アカウントに必要なレコードの更新権限はあります。しかし、入力・更新の業務には要らないテーブルの作成・削除権限まで付いています。権限が過剰なので、誤った操作や不正利用があるとテーブルそのものが消されるおそれがあります。
- ×エ アカウント：データの入力・更新用、レコード更新権限：無、テーブル作成・削除権限：有データの入力・更新用アカウントなのに、レコードの更新権限が「無」になっています。これでは本来の業務ができません。さらに、不要なテーブルの作成・削除権限が付いていて、アと同じく必要な権限と不要な権限が逆になっています。
補足
ウのように両方の権限が「有」の選択肢は、業務が滞りなくこなせるので一見便利に見えます。ただ、セキュリティの面では権限が多すぎることが問題になります。この種の問題では「必要な権限があるか」と「不要な権限が付いていないか」の二つの観点で各行を確認すると、確実に絞り込めます。
POINT
- アカウントの権限は、業務上必要な範囲に限って与えます（最小権限の原則）。
- テーブルを作る・消すといった構造定義の権限と、レコードを更新する権限は、別々のアカウントに分けて持たせます。
- データ構造の定義用アカウントにはテーブルの作成・削除権限が必要で、レコードの更新権限は要りません。
- データの入力・更新用アカウントにはレコードの更新権限が必要で、テーブルの作成・削除権限は要りません。