データベースのセキュリティ対策｜公開設定・アクセス権限・暗号化・監査ログ

データベースのセキュリティは、接続できる経路、アカウントの権限、通信と保存データの暗号化、操作の記録、バックアップや複製を読める人の5か所で守る。

IPAは2026年10月9日の注意喚起で、相次ぐ情報漏えいの起点に外部公開アプリケーションやアカウントの侵害がうかがえるとしている。

データベースのセキュリティ対策：接続経路と公開範囲

データベースのセキュリティ対策は、待ち受けポートにどこから接続できるかを確かめ、接続元を絞るところから始める。OWASPの『データベースセキュリティ・チートシート』も、ファイアウォールで接続元のホストを絞る方法などを挙げている。

データベースの公開エンドポイント

待ち受けの初期値は製品で違い、クラウドには公開の設定が別にある。PostgreSQL・MySQL・Amazon RDSの公式文書によれば、接続を受ける範囲を決める設定は次のとおりだ。

公開の設定と受信ルール、製品のバージョンをデータベースごとに一覧にする。検証用や移行用のインスタンスも数える。JPCERT/CCは2026年10月8日の注意喚起で、一連の攻撃が既知の脆弱性を悪用している可能性があるとして、修正済みのアップデートの適用を勧めている。BIツールや従業員向け管理システムからの漏えい例も挙げているので、接続情報を持つツールも入口の一覧に入れる。

データベースへの管理・アプリ接続

接続はアプリ用と管理者の保守用に分けて確かめる。PostgreSQLでは、接続元やユーザーごとの認証方式をpg_hba.confに書き、上から最初に一致した行が使われる。認証方式がtrustの行に一致すると、パスワードなしで任意のユーザーとしてログインできる。

OWASPのチートシートは、root・sa・SYSのような組み込みアカウントを使わないこと、接続情報をソースコードやリポジトリに入れないことを挙げている。アプリ用のアカウントはアプリのサーバーからだけ、管理者のアカウントは決めた保守用の端末からだけ接続できるかを確かめる。

クラウドでは公開設定やスナップショットの共有を管理画面やAPIから変えられるので、管理画面へのログインに多要素認証が効いているかも確かめる。IPAも多要素認証を挙げている。

一覧に書いた製品のバージョンに修正済みの脆弱性が見つかったら、公式勧告との照合から適用後の確認までの進め方を「ゼロデイ」と「N-day」の違いと対処法で確かめられる。

データベースのセキュリティ点検：権限・暗号化・監査ログ

権限・暗号化・監査ログの点検では、接続できたアカウントで何ができるか、データベースを通らずにデータを読めないか、操作を後から追えるかを見る。3つは受け持つ範囲が違い、互いに代わりにはならない。次の表に、3つの受け持ちを並べる。

データベースのアクセス制御と権限の確認

OWASPは、アプリ用のアカウントには最小限の権限だけを与え、権限昇格の脆弱性につながるのでデータベースの所有者にしないよう求めている。

点検では、アカウントごとに、読めるテーブル、更新・削除できるテーブル、他のアカウントに権限を付けられるかを書き出し、業務に要る範囲と比べる。使われなくなったアカウントも一覧に入れる。

顧客情報を表示するだけの画面に全テーブルを消せるアカウントを使うと、不備を1つ突かれたときの被害が広がる。SQLインジェクション自体は、OWASPの『SQLインジェクション対策チートシート』のとおり、パラメータ化したクエリで防ぐ。

データベースの通信・保存時暗号化

通信について、OWASPは、暗号化した接続だけを許可し、TLS 1.2以上で接続してクライアント側で証明書を検証するよう勧めている。PostgreSQLのpg_hba.confでは、hostの行は暗号化していない接続にも一致し、hostsslの行は暗号化した接続にだけ一致する。

PostgreSQLの文書「暗号化の選択肢」によれば、ディスクの暗号化は盗難には効くが、マウント中の攻撃は防がない。RDSでは、暗号化はインスタンスの作成時にしか有効にできない。既存のものは、暗号化したスナップショットのコピーから復元して移す。

データベース監査ログの対象操作

監査ログでは、データの読み取り、外への書き出し、権限の変更が記録の対象に入っているかを確かめる。読み取りの記録がなければ、内部の担当者による持ち出しも確かめられない。pgAuditの文書は、PostgreSQLの標準のログ設定では監査に詳しさが足りないとし、READ（SELECT・COPY）、WRITE、ROLE（GRANT・REVOKEなど）の種類で記録する。

クラウドでは、公開設定の変更やスナップショットの共有などRDSへのAPI呼び出しはAWS CloudTrailに、データベース内のSQLはデータベース側のログ設定（pgAuditなど）で記録する。

誰がどの頻度で記録を確かめ、大量の読み取りや書き出し、平時と違う接続元や時間帯の管理者ログインにどう気付くかを決めておく。IPAも、平時との差でログの異常を見分け、誰が調査できるかを把握しておくよう求めている。

データベースのセキュリティを保つバックアップと複製のアクセス制限

バックアップ、スナップショット、書き出したファイルを誰が読めるかは、元のデータベースとは別の権限と公開設定で決まるので、本番とは別に確かめる。JPCERT/CCも、一連の攻撃で環境設定ファイルやバックアップファイルが狙われている可能性を挙げている。

バックアップの接続先と管理権限

バックアップでは、保管先を誰が読めるかと、誰が消せるかを分けて確かめる。OWASPは、バックアップを適切な権限で保護し、できれば暗号化するよう求めている。CISAは『ランサムウェア対策ガイド』で、多くのランサムウェアは手の届くバックアップを削除または暗号化しようとするとし、オフラインの暗号化したバックアップ、削除保護、オブジェクトロックを勧めている。

点検では、本番の管理者アカウントを奪われたとき、同じ権限でバックアップまで消せないかを確かめる。

複製・共有データのアクセス制限

RDSの手動スナップショットは、指定した最大20のAWSアカウントと共有でき、暗号化していなければ「パブリック」にもできる。パブリックにすると、すべてのAWSアカウントが復元してデータにアクセスできる。

本番データを写した検証環境も複製に当たる。複製ごとに、保存場所、読める人、共有先、消す期限を一覧にする。JPCERT/CCは、法令や契約の保存期間を過ぎたデータや、利用目的を終えたデータを残さないよう求めている。

データベースのセキュリティ点検から決める改善の順序

データベースのセキュリティの改善は、誰でも試せる状態から先に閉じ、次に入られたときに取られる範囲を狭める順がよいと我々は考える。

1が見つかったら、設定を閉じるのと合わせて、公開されていた期間の接続記録を確かめる。IPAは、異常なログやアカウントが見つかったら速やかにインシデントと判定するよう求めている。

設定画面で分かる公開範囲は、受信ルールの例外や残った検証用インスタンスで実際とずれる。作った一覧は、外部から実際に接続を試した結果と突き合わせて確かめる。