ITパスポート 2009年 秋期 問76

データベースの機密性を考慮した表示制限【ITパスポート 解説】

正解の理由

• アクセス権：ある利用者があるデータを「見る」「編集する」などの操作を行う許可のこと。
• データベース：情報を整理して保存する仕組み。顧客リストや在庫表などを管理します。
• レコード：データベースの一行分の情報（例：顧客1人分の情報）。
• 列（データ項目）：レコード内の項目（例：氏名、電話番号）。

解法ステップ

1. 要件確認：どの利用者が、どのデータを見て良いかを明確にする。業務上の機密レベルで分類する（例：公開、社内秘、部署限定など）。
2. アクセスモデル選定：ACL（アクセス制御リスト）、RBAC（役割に基づくアクセス制御）、ABAC（属性に基づくアクセス制御）などから適切な方式を選ぶ。
   • ACL（Access Control List：誰にどのデータを許可するかを個別に管理）
   • RBAC（Role-Based Access Control：役割ごとに権限を設定し、利用者に役割を割り当てる）
   • ABAC（Attribute-Based Access Control：利用者属性や環境条件で柔軟に制御）
3. 実装方法の決定：データベース側での行レベル制御（Row-Level Security）やビュー（表示専用の仮想テーブル）を使うか、アプリケーション層で制御するか決める。
4. 実装・テスト：権限設定を反映して、利用者ごとに期待どおり見える/見えないを確認する。
5. 運用・監査：権限変更の手順を作り、アクセスログを記録して不正アクセスを検出する。

選択肢別の誤答解説

• ア: アクセス権を、データと利用者の組合せに対して設定する。
  → 正解。細かい組合せでの制御が可能で、現実の業務要件に合う。ACLや行レベル制御で実装できる。
• イ: 利用者ごとに限定されたデータベースの複製を配布する。
  → 不適切。複製を多数配布すると、データの整合性（最新状態を保つこと）が難しくなり、管理負荷と漏洩リスクが増える。業務での運用コストが非常に高くなる。
• ウ: 利用者ごとに専用のデータ項目（列）を設ける。
  → 不適切。利用者数が多い場合、列が膨大になりデータ設計として破綻します。列は項目（氏名や住所）を表すもので、利用者ごとの可視性管理には向きません。
• エ: レコードごとにパスワードを設定して保護する。
  → 不適切で非現実的。レコード単位でパスワード管理をすると運用が煩雑になり、ユーザー体験も悪くなります。パスワードは人に紐づく認証手段であり、アクセス制御（権限）とは別に考えるのが一般的です。

よくある誤解

1. 「データを別々に分ければ安全」
   • 誤解点：データを物理的に分割・複製する（選択肢イ）は一見安全だが、更新漏れや複製先での漏洩リスクが増える。通常は単一の信頼できるデータ保存とアクセス制御で管理する方が安全で効率的です。
2. 「パスワードで守れば十分」
   • 誤解点：認証（誰がアクセスするかの確認）と認可（何ができるかの許可）は別の仕組みです。パスワードだけでは、認可の細かい制御（例えば同じユーザでも特定の部署データだけ見せない）はできません。
3. 「列を作れば利用者ごとに分けられる」
   • 誤解点：列は属性（氏名、年齢など）を表すためのもので、利用者ごとに列を増やす設計はスケーラビリティも保守性も悪くなります。

補足コラム

• 行レベル制御（Row-Level Security：RLS）
  RLSはデータベースの機能で、クエリ実行時に「その利用者が行（レコード）を見てよいか」を自動で判定します。たとえば「部署が一致するレコードだけ表示する」といったポリシーを簡潔に実装できます。主要なDB（PostgreSQL、SQL Server、Oracleなど）でサポートされています。
• ログと監査の重要性
  アクセス権を設定しても、誰がいつどのデータにアクセスしたかのログを残しておくことが重要です。不正アクセスの検出や権限誤設定の発見に役立ちます。
• 権限設計のコツ（実務で覚えておくこと）
  1. まず業務単位で役割（ロール）を定め、RBACで基本の権限を付与する。
  2. 特殊ケースはACLやABACで例外的に対応する。
  3. 変更申請フロー、定期的な権限見直しを必ず設ける。

FAQ