DB〜セキュリティと監査【H19午後1問3】

ここでは、データベーススペシャリスト試験の対策として、『セキュリティと監査』の問題を扱った過去問の解説を紹介します。対象は、平成19年度午後1問3の問題となります。

【設問1】ビューを使用したアクセス制御

設問1ー（1）

ビューは、実テーブルへ影響を与えずにセキュリティを実現する方法である。
ビューを用いて、従業員が”従業員個人”テーブルの自分のデータだけをアクセス可能にするためのアクセス権限は、実テーブルへは行わず、個々の従業員のレコードだけが表示されるビューを作成し、そのビューに対するアクセス権を個々の従業員に設定すれば良い。したがって、『アクセス権をテーブルに対して付与せず、ビューだけに付与する』

＜ポイント＞
・標準SQLの権限管理は「テーブル or カラム」単位であり、行単位では制御できない。
・行単位で制御したいならビューを作り、ユーザにはそのビューのみ権限を与える必要がある。
・実務ではRLS機能を持つDBMSなら元テーブルでも可能だが、試験解答は「ビューを用いる」でOK。

設問1ー（2）

USER関数を使用すると効率が良い理由について問われる問題です。
USER関数は、現在ログインしているユーザー名を自動的に返す組み込み関数です。
この関数を用いることにより、利用者ごとにビューを作らなくてもよくなります。
例えば、WHERE 社員ID = 'E001' のように 個別のIDを固定すると、従業員の人数分ビューを作る必要があります。100人社員がいれば100個のビューが必要 → 管理が大変。
➡️ WHERE 社員ID = USER にすれば 1つのビューで全員に共通化できる。

したがって、『従業員ごとにビューを作成する必要がなくなるから』となります。

【設問2】ロールとSQL

設問2ー（1）；ロールを付与するSQL文

ロールとは、ある目的や役割に応じて、アクセス権限などを纏めて設定したものです。

①ロールの作成
　CREATE ROLE ロール名
②アクセス顕現をロールに付与
　GRANTE 権限　ON テーブル名（又はビュー名）　TO ロール名
③ロールにロールを付与
　GRANTE ロール名　TO ロール名
④ユーザーにロールを付与
　GRANTE ロール名　TO　ユーザー名

＜SQL文＞
1行目；【a；CREATE ROLE】　営業1課長ロール＝（ロールの作成）
2行目；GRANT ALL PRIVILEGES ON 従業員人事営業1課長ビュー　【ｂ；TO 営業1課長ロール】
　　　　＝（ロールに権限付与）
3行目；GRANT　1課長ロール　【ｃ；TO　B111】＝（ロールをユーザーに付与）

4行目；【a；CREATE ROLE】　営業部長ロール＝（ロールの作成）
5行目；GRANT 営業1課長ロール，営業2課長ロール　TO　営業部長ロール
6行目；GRANT　営業部長ロール　【ｄ；TO　B110】＝（ユーザーにロールを付与）

設問2ー（2）

SQL文には、権限の移動やコピーを行う構文はない。
そのため、変更になった場合は、①権限の削除（REVOKE）と②権限の追加（GRANT）が必要になる。
したがって、『ユーザID”B110”から営業部長ロールのアクセス権限を削除して、ユーザID”B130”に営業部長ロールのアクセス権限付与を行う』

【設問3】監査証拠

監査機構に関しては、〔RDBMSの仕様と人事データベースの設定内容〕で下記のように記載されている。

（ア）今から3ヶ月前に、一部の従業員の基本データが外部に漏洩した。
（イ）今から2ヶ月前に、ある従業員の人事データが改竄された。
（ウ）今から半年前に、更新権限のない従業員が給与データを更新しようとした

（ア）今から3ヶ月前に、一部の従業員の基本データが外部に漏洩した。
従業員基本データへのアクセスは、全従業員が可能である。そのため、様々な従業員が従業員基本データにアクセスした一覧を表示することはできると考えられる。
監査証跡では、操作名とオブジェクト名（テーブル名）は保存されるが、実行したSQL文は保存されない。したがって、漏洩した従業員の一覧を出力するSQL文を発行したユーザIDを特定することはできない。

（イ）今から2ヶ月前に、ある従業員の人事データが改竄された。
”従業員人事”テーブルは、人事担当者と営業部長が更新することができる。そのため、人事データを更新したユーザーの一覧を出力することは可能であると考えられる。しかし、実行したSQL文は分からないため、誰が更新したかは分かるが、どのように更新したか？、改竄したか？を判断する、改竄内容のSQL文を実行したユーザーまでかは分からない。
したがって、『複数の従業員から更新することが可能なので、特定できない』。

＜ポイント＞
イ）人事データ改竄のケース
・その更新が「正当な業務による更新」か「改竄」だったか

監査証跡に残る情報
・操作名（UPDATE）
・テーブル名（従業員人事）
・ユーザーID（人事担当者や営業部長の誰か）

分かること
・誰が「更新操作」を行ったか（ユーザーID）
・いつ「従業員人事テーブル」が更新されたか

分からないこと

・実行したSQL文の内容（どの列・どの行を変更したか）
・変更前と変更後のデータの違い

（ウ）今から半年前に、更新権限のない従業員が給与データを更新しようとした
「更新権限がないユーザーからのアクセス」はエラーとなる。監査機構の仕様に記載のある「操作の実行結果（SQLSTATE）」でエラーとなったものの内、アクセス顕現がないユーザーからのUPDATE文を出力することで、特定できる。

＜ポイント＞

（ウ）更新権限のない従業員が給与データを更新しようとしたケース

• 監査証跡に残る情報
  • 操作名（UPDATE）
  • テーブル名（給与データ）
  • ユーザーID（権限のない従業員）
  • 実行結果（SQLSTATE → エラーコード）
• 動作の特徴
  • 更新権限がないため、UPDATE文はエラーとなり実行されない。
  • 監査証跡には「失敗したSQL操作」として記録される。
  • SQLSTATE から「権限がないため拒否されたアクセス」であることが分かる。
• 分かること
  • 誰がアクセスしようとしたか（ユーザーID）
  • どのテーブルに対してか（給与データ）
  • UPDATE 操作が拒否されたこと（エラーSQLSTATE）
• 結論（回答要旨）
  「更新権限がないユーザーからのアクセス」はエラーとして監査証跡に残る。
  したがって、エラー結果（SQLSTATE）を手がかりに、権限のないユーザーからの不正な UPDATE 試行を特定することができる。

ポイントまとめ

ビューによる行レベルのアクセス制御

ポイント	解説
ビューの役割	実テーブルの特定の行（レコード）や列のみを表示する仮想的なテーブルとして機能します。
セキュリティ	標準SQLでは行単位のアクセス制御ができないため、ビューを用いて「自分のデータのみ」を抽出するようフィルタリング（WHERE句）を設定します。
権限付与	従業員には実テーブルへのアクセス権限は与えず、フィルタリング済みのビューにのみアクセス権を付与することで、行レベルのセキュリティを実現します。

USER関数の活用

ポイント	解説
USER関数の機能	現在データベースにログインしているユーザーID（またはユーザー名）を自動的に返します。
効率性	従業員一人ひとり（例：E001, E002, …）のIDを固定したビューを人数分作る代わりに、WHERE 社員ID = USERという条件を設定した単一のビューを作成できます。
結論	従業員ごとにビューを作成する必要がなくなり、管理の手間が大幅に削減されるため効率的です。

ロールによる権限管理

項目	説明/SQLコマンドの構成	試験でのポイント（なぜ使うのか）
定義	複数のアクセス権限（SELECT, UPDATEなど）を束ねた論理的な役割。	権限設定をユーザーごとではなく役割ごとに行うことで、管理の手間を大幅に削減できる。
① ロールの作成	CREATE ROLE ロール名;	権限のまとまりである**「役割」を定義**する最初のステップ。
② ロールへの権限付与	GRANT 権限 ON オブジェクト名 TO ロール名;	ロールが持つべき権限を確定させる。ユーザーではなくロールに付与するのが特徴。
③ ユーザーへのロール付与	GRANT ロール名 TO ユーザー名;	ユーザーにその役割を与える（ユーザーがロールの権限を使えるようになる）。
権限の変更	REVOKE（削除）と**GRANT（付与）のセット**が必要。	SQLには権限を移動・コピーする単一の構文はない。人事異動などで権限者が変わる際は、必ず「旧ユーザーからREVOKE → 新ユーザーにGRANT」の2操作が必要。
最大のメリット	管理負荷の軽減、セキュリティポリシーの一貫性。	組織変更や異動があっても、ユーザーへのロール付与/剥奪のみで済み、テーブルごとの権限設定（GRANT）を変更する必要がない。

権限変更時の操作

ポイント	解説
権限の移動/コピー	SQLには「権限を他のユーザーへそのまま移す」ための専用構文はありません。
必要な操作	ユーザーID “B110” から “B130” へ「営業部長ロール」を異動させる場合、次の2ステップが必要です。
① 削除（剥奪）	旧ユーザーからロールを削除：REVOKE 営業部長ロール FROM B110;
② 追加（付与）	新ユーザーにロールを付与：GRANT 営業部長ロール TO B130;
結論	ユーザID”B110″から営業部長ロールのアクセス権限を削除し、ユーザID”B130″に営業部長ロールのアクセス権限付与を行う必要があります。

監査証跡調査：試験の核となる考え方

この表は、監査証跡に「何が残り、何が残らないか」を基に、試験問題で問われた際の**「特定の可否」とその理由**を整理したものです。

SQL操作	問われる事象	ログに残る情報（特定できること）	ログに残らない情報（特定できない理由）	試験の解答ポイント
SELECT	情報漏洩の調査	✅ 誰がアクセスしたか（ユーザーID）、✅ どのテーブルにアクセスしたか。	❌ SELECT文のWHERE句の内容（どのデータを見たか）。❌ 抽出された具体的なデータ値。	「漏洩したデータの中身（一覧）」までは特定できない。
UPDATE	データ改竄の調査	✅ 誰が更新操作をしたか（ユーザーID）、✅ どのテーブルを更新したか。	❌ UPDATE文のSET句の内容（変更した値）。❌ 変更前後の具体的なデータ値。	「更新内容が正当か改竄か」を判断したり、「改竄された中身」を特定したりはできない。
GRANT/REVOKE	権限変更の調査	✅ 誰が権限を付与/剥奪したか、✅ どの権限に対して操作したか。		権限管理の操作履歴は明確に特定可能。
権限エラー	権限のない操作試行	✅ 操作の結果がエラーであること（SQLSTATE）、✅ エラーを試みたユーザーID。		権限外の操作を試みたユーザーは、エラーログによって特定可能。
全体的な限界	セキュリティ監査	操作の履歴（誰がいつ何を）と試行/失敗の記録。	データの中身（参照値、更新前後の値）やSQL文の具体的な条件。	監査証跡は操作者の特定には役立つが、データの中身の検証にはトリガなどの別機能が必要。