データベースセキュリティ（アクセス制御・透過的暗号化TDE・監査ログ）

DBセキュリティでは、誰が何を操作できるか、通信と保存媒体をどう守るか、操作を後から検証できるかを分けて設計します。暗号化だけでアクセス制御が不要になるわけではなく、権限を付けたユーザーの不正操作をTDEだけで防ぐこともできません。脅威と対策の対応を具体的に確認します。

最小権限と職務に応じたロール

アプリの接続ロール、バッチ、移行作業、DB管理、監査閲覧を区別します。通常のアプリにスキーマ変更やロール管理が不要なら、その権限を与えません。すべての接続を管理者で実行すると、SQLの誤りや接続情報の漏洩がDB全体へ波及します。

ロールに必要な権限をまとめて所属を管理すると、異動や退職時の見直しを行いやすくなります。通常作業と特権作業のアカウントを分け、特権の利用を記録します。接続情報の管理、ネットワーク経路の制限、アプリ側のパラメータ化SQLも合わせて検討します。

行レベル制御と、共有接続ユーザーの注意

RLSは、同じ表でもロールやポリシーに応じて参照・変更できる行を制御する仕組みです。アプリの各SQLへ条件を書く方式の漏れを減らせますが、設定、権限、ユーザーのコンテキストが正しいことが前提です。100%の漏洩防止を保証するものではありません。

PostgreSQLではスーパーユーザーやBYPASSRLSを持つロールはRLSを回避し、表の所有者も通常は回避します。所有者を対象にするFORCE ROW LEVEL SECURITYなどの設定を含めて確認します。全利用者が同じapp_userで接続するなら、DBロール名だけでは個々の利用者を区別できません。改ざんできない利用者情報を設定し、接続プール返却時の状態の残留も防ぐ必要があります。

暗号化は、通信・保存・利用時で分ける

TDEはエンジンが保存データを暗号化・復号するため、通常のSQLを大きく変えずに媒体の持出しに対処できます。ただし適用されるファイル、ログ、バックアップの方式、エクスポートの扱いは製品に依存します。平文へ出力したCSVなどまで自動的に暗号化する仕組みではありません。

鍵の保管と復旧を同時に設計する

データを暗号化する鍵を別の鍵や証明書で保護する構成があります。保護する鍵が必ず外部KMSにあるわけではなく、DBMSや構成によってローカルの鍵階層も使われます。データファイルと復号に必要な鍵を同じ権限で持ち出せる配置は、暗号化の効果を弱めます。

鍵・証明書のバックアップ、権限、更新、紛失時の対応を定め、別環境で復元を試します。暗号化済みバックアップがあっても、必要な鍵を失うと復元できません。一方、正規権限で平文を取得できる利用者や侵害されたアプリへの対策には、認可や監視が別途必要です。

監査の信頼性を守る

監査には、利用者、接続元、時刻、対象、操作、成功・失敗、権限・設定変更を必要に応じて記録します。共有接続のDBユーザーだけでは実利用者を特定できない場合があるため、アプリの監査情報との対応を持たせます。ログ自体に機密値が入る場合は、閲覧権限や保存範囲も管理します。

DB管理者と監査管理者の責任・権限を分け、外部ログ基盤へ転送し、削除や変更を制限します。WORMや保持ロックは改ざん抑止に有効ですが、保持期間、設定変更、転送前の欠落や停止まで検討します。強い管理者権限が残る環境で「ログ削除権限だけ剥奪すれば完全」と考えず、監査停止の検知も設計します。

演習1：TDEの保護範囲

条件：DBファイルはTDEで暗号化され、アプリには機密表のSELECT権限がある。

問い：侵害されたアプリの正規SELECTによる流出をTDEだけで防げるか。

解答例：防げない。DBエンジンが復号した結果を返すため。

根拠：保存媒体の保護と、利用者への認可・結果の持出しは別の対策が必要。

演習2：監査ログの隠蔽を防ぐ

条件：DB管理者はDB操作とローカルログの変更を行える。

問い：監査運用の対策を説明しよう。（35字以内）

解答例：監査管理を分離し変更を制限した外部基盤へ転送する。（25字）

根拠：転送の停止や欠落も検知する。

復習で確かめること

例の数値や業務条件を変えて同じ結論になるか確認してください。用語の定義だけでなく、問題文のどの条件から、どの制約・SQL・対策を選んだのかを自分の言葉で説明できれば、次の過去問に進みます。

出典と仕様を確認する

IPA：DBシラバス Ver.4.1

PostgreSQL 18：行レベルセキュリティ

PostgreSQL 18：ロール

Microsoft：SQL Serverの透過的データ暗号化

関連するテーマ

データベースレプリケーションと高可用性設計（アクティブ/スタンバイ）