情報セキュリティマネジメント 2017年 秋期 午前（科目A） 問25

最小権限原則【情報セキュリティマネジメント解説】

正解の理由

解法ステップ

1. まず各アカウントの目的を確認する。
   • データ構造の定義用（DDL用）：スキーマ設計・テーブル操作が目的。
   • データ入力・更新用（DML用）：日常のデータ操作が目的。
2. 各目的で本当に必要な権限だけを列挙する。
   • DDL用：テーブル作成・削除は必要、レコード単位の更新は不要。
   • DML用：レコードの更新は必要、テーブル作成・削除は不要（誤操作で全データ消失のリスク）。
3. 表の各行と照らし合わせ、必要な権限だけ与えている行を選ぶ。上の条件に合致するのが イ。

選択肢別の誤答解説

• ア：データ構造の定義用アカウントに「レコード更新権限：有」「テーブル作成・削除：無」。
  問題点：DDL用なのにテーブル作成・削除が無い一方でレコード更新がある。スキーマ変更権限がないのにレコード操作だけ可能という役割不整合で、最小権限になっていない（必要な権限が欠け、不要な権限がある）。
• イ：データ構造の定義用アカウントに「レコード更新：無」「テーブル作成・削除：有」。
  理想的：役割に対応した最小限の権限だけを付与している（DDL権限はDDL用に限定）。
• ウ：データの入力・更新用アカウントに「レコード更新：有」「テーブル作成・削除：有」。
  問題点：日常の入力アカウントにテーブル作成・削除を与えるのは危険。誤操作や不正でテーブルを作成・削除されるリスクが高まる。
• エ：データの入力・更新用アカウントに「レコード更新：無」「テーブル作成・削除：有」。
  問題点：入力用なのにレコード更新権限が無く、不要な（かつ危険な）DDL権限を持っている。役割が合っていない。

よくある誤解

1. 「管理者（DBA）が全部やるからユーザは何でも要らない」
   → 実務ではアプリや業務担当に必要な更新権限を与える必要があります。与え方は最小限に限り、ロール（役割）単位で管理します。
2. 「テーブルの作成・削除は稀だから権限を与えても問題ない」
   → 稀でも誤操作や不正で大事故につながります。変更は変更管理プロセス（承認・検証）を通した一時付与やDBA限定にします。

補足コラム

• 権限管理の実装例：
  • DBA（Database Administrator：データベース管理者）ロール：DDL権限を持つ。スキーマ変更は変更申請と承認プロセスを経て実施。
  • アプリケーション／業務ロール：DML権限のみ。業務ごとに細かいロールを作り、必要最小限のテーブル・列へのアクセスのみ許可する。
  • 一時昇格（Just-In-Time）：トラブル対応時のみ一時的に権限を付与し、作業後に自動で取り消す仕組みを導入すると安全性が高まります。
• 技術的には、SQLのGRANT/REVOKE（権限付与/取り消し）で実現します。監査ログ（操作履歴）を残し、誰がいつどの権限で何を行ったかを追跡できるようにしておきます。

FAQ