Microsoft Defender security assessments for Azure Database for PostgreSQL は、Azure Database for PostgreSQL のセキュリティ状態を継続的に評価し、構成ミスや潜在的な脆弱性を推奨事項として見つけやすくする Public Preview です。結論から言うと、管理者は「Azure Database for PostgreSQL Flexible Server が対象に含まれているか」「Defender CSPM の推奨事項に新しい指摘が出ていないか」「ネットワーク、TLS、監査ログ、バックアップ設定を変更してもアプリが止まらないか」を優先して確認すべきです。Azure Updates では本件が Public Preview として案内されており、Azure の “In preview” は全 Azure 顧客が非本番用途やテスト用途で利用できる段階として説明されています。(マイクロソフト Azure)
今回のポイントは、Microsoft Defender が「攻撃らしい動きを検知する」だけでなく、「PostgreSQL の設定が安全な状態になっているか」を継続評価しやすくなったことです。特に、Azure Database for PostgreSQL を本番システムで使っている組織では、脆弱性対応だけでなく、構成の標準化、監査証跡、ネットワーク公開範囲の見直しに直結します。
今回の変更点：PostgreSQL の設定不備を継続評価しやすくなる
今回の Public Preview では、Microsoft Defender security assessments for Azure Database for PostgreSQL により、Azure Database for PostgreSQL のセキュリティ姿勢を継続的に評価し、脆弱性や構成ミスを把握しやすくなります。Microsoft Defender for Cloud は CNAPP として、CSPM、DevSecOps、CWPP を組み合わせてクラウド環境のセキュリティ状態を可視化・改善するサービスです。CSPM はクラウドリソースのセキュリティ姿勢をチェックし、推奨事項を通じて改善につなげる役割を持ちます。(Microsoft Learn)
従来の Defender for Open-Source Relational Databases は、異常なデータベースアクセスや不審なクエリパターンなど、脅威検知・アラートの側面が中心でした。一方、今回の security assessments は、設定値や構成の健全性を評価し、管理者が予防的に修正できる情報を出す点が重要です。(Microsoft Learn)
| 観点 | 脅威検知・アラート | セキュリティ評価・推奨事項 |
|---|---|---|
| 主な目的 | 不審なアクセスや攻撃兆候を検知する | 危険な設定や構成ミスを事前に見つける |
| 対応タイミング | 事象発生後の調査・対応が中心 | 事前対策、標準化、監査対応が中心 |
| 出力される情報 | セキュリティアラート、調査情報、推奨アクション | Defender CSPM の推奨事項、セキュリティ評価 |
| 担当者 | SOC、セキュリティ運用、DBA | クラウド管理者、DBA、インフラ担当、開発チーム |
| 実務上の価値 | 侵害や攻撃の早期発見 | 設定不備によるリスクの低減 |
影響範囲：Azure Database for PostgreSQL Flexible Server を重点確認する
Microsoft Learn の更新履歴では、Defender CSPM の一部として Azure Database for PostgreSQL Flexible Servers 向けの複数の推奨事項がプレビューで追加されています。したがって、まず確認すべき対象は Azure Database for PostgreSQL Flexible Server です。既存の PostgreSQL 環境をすべて同じ対象とみなすのではなく、サブスクリプション、リソースグループ、サーバー種別、ネットワーク構成ごとに整理してください。(Microsoft Learn)
また、Defender for Open-Source Relational Databases の保護対象として、Azure Database for PostgreSQL の Flexible Server は全価格レベルが対象とされています。一方で、この Defender プランは Azure Arc 対応マシン上のデータベースには対応しないと説明されています。クラウド上の PaaS PostgreSQL と、VM・Arc・オンプレミス上の PostgreSQL を混同しないことが重要です。(Microsoft Learn)
影響を受けやすいのは、次のような環境です。
| 環境 | 確認すべき理由 |
|---|---|
| インターネット公開または広い IP 許可を使っている PostgreSQL | Public IP access や Private Endpoint 関連の推奨事項が出やすい |
| 監査ログを最小限にしている環境 | pgaudit やログ保持日数に関する推奨事項への対応が必要になる |
| 古いアプリや古い DB ドライバーが接続している環境 | TLS 設定の見直しで接続エラーが発生する可能性がある |
| DR 要件が明確でない環境 | geo 冗長バックアップの必要性を再評価する必要がある |
| IaC や Azure Policy で設定を固定している環境 | 推奨設定と既存テンプレートの差分確認が必要になる |
追加・関連する主な推奨事項
Microsoft Learn の更新履歴では、Azure Database for PostgreSQL Flexible Servers 向けに、2026年3月から5月にかけて複数の推奨事項がプレビューとして追加されています。主な内容は、通信の暗号化、ネットワーク分離、監査ログ、バックアップ、接続防御に関するものです。(Microsoft Learn)
| 分類 | 推奨事項の例 | 管理者が見るべきポイント |
|---|---|---|
| 通信の暗号化 | require_secure_transport を “on” にする | アプリ側の接続文字列、DB ドライバー、証明書検証設定を確認する |
| バックアップ | geo 冗長バックアップを有効にする | RPO/RTO、リージョン障害時の復旧方針、コストを確認する |
| ネットワーク | Private Endpoint を構成する | DNS、NSG、ルートテーブル、オンプレミス接続を含めて検証する |
| ネットワーク | “Allow access to Azure services” を無効にする | Azure 内の他サービスや運用端末からの接続経路を洗い出す |
| ネットワーク | Public IP access を無効にする | BI ツール、CI/CD、踏み台、外部監視の接続断に注意する |
| 監査ログ | pgaudit.log_statement や pgaudit.log_statement_once を有効化する | SQL 実行ログの量、保存先、個人情報・機密情報の扱いを確認する |
| 監査ログ | pgaudit.log に role、ddl、misc を含める | 権限変更、DDL、その他重要操作を追跡できるか確認する |
| 監査ログ | logfiles.retention_days を 3 より大きくする | 調査・監査に必要な保存期間とコストを調整する |
| 接続防御 | connection_throttle を “on” にする | 認証試行や接続失敗が多いアプリで影響がないか確認する |
ここで重要なのは、推奨事項をそのまま一括適用しないことです。たとえば Public IP access を無効化すればセキュリティは高まりますが、パブリック経由で接続しているアプリ、管理者端末、外部監視、CI/CD ジョブは接続できなくなる可能性があります。セキュリティ改善と可用性維持を両立するには、接続元を棚卸ししてから段階的に切り替える必要があります。
管理者が最初に確認すべき設定
Defender CSPM の推奨事項に PostgreSQL が出ているか確認する
最初に、Defender for Cloud または Microsoft Defender ポータルで、Azure Database for PostgreSQL Flexible Server に関する推奨事項が表示されているか確認します。Defender for Cloud のセキュリティ推奨事項は、クラウドリソースの設定がセキュリティポリシーに違反していないかを示し、修正によりセキュアスコア改善にもつながります。(Microsoft Learn)
確認時は、次の観点でフィルターすると作業しやすくなります。
| 確認項目 | 見るポイント |
|---|---|
| 対象リソース | Azure Database for PostgreSQL Flexible Server に絞る |
| 状態 | Unhealthy、または未対応の推奨事項を優先する |
| 重大度 | 外部公開、暗号化、認証、監査に関わるものを優先する |
| 所有者 | DBA、アプリ担当、ネットワーク担当、セキュリティ担当に振り分ける |
| 修正方法 | すぐ変更できる設定か、設計変更が必要かを分ける |
ネットワーク公開範囲を棚卸しする
PostgreSQL のセキュリティ評価で最も影響が大きいのはネットワークです。Private Link を使うと、Azure Database for PostgreSQL Flexible Server にプライベートエンドポイントを作成し、仮想ネットワーク内のプライベート IP 経由で接続できます。Microsoft の説明では、Private Link によりサービスをパブリックインターネットへ公開する必要がなくなり、トラフィックは Microsoft のバックボーンネットワークを通ります。(Microsoft Learn)
ただし、Private Endpoint は作成すれば終わりではありません。DNS 解決、NSG、ルートテーブル、VPN、ExpressRoute、ピアリング先 VNet からの到達性まで確認が必要です。特に、アプリ側のホスト名は同じでも、名前解決先がプライベート IP に変わらないと意図した経路になりません。
よくある失敗は次の通りです。
| 失敗例 | 原因 | 対策 |
|---|---|---|
| Private Endpoint 作成後もパブリック経由で接続している | Private DNS ゾーンがリンクされていない | privatelink.postgres.database.azure.com の名前解決を確認する |
| アプリから接続できなくなる | NSG またはルートテーブルで 5432 番ポートの通信が遮断されている | サブネット、NSG、UDR、Firewall の経路を確認する |
| オンプレミスからだけ接続できない | オンプレミス DNS が Private Endpoint の名前解決に対応していない | 条件付きフォワーダーや Private DNS Resolver を設計する |
| Public IP access を無効化して運用ツールが止まる | 管理端末、BI、CI/CD の接続元を把握していない | 無効化前に接続元一覧を作る |
TLS とクライアント接続を確認する
Azure Database for PostgreSQL は、クライアント接続に TLS を要求し、TLS 1.2 と TLS 1.3 を安全なバージョンとして扱います。推奨構成では、可能であれば ssl_min_protocol_version を TLSv1.3 に設定し、PostgreSQL 接続では sslmode=verify-all または sslmode=verify-ca を使って証明書検証を行うことが推奨されています。(Microsoft Learn)
管理者が注意すべきなのは、サーバー側だけでなくアプリ側の設定です。古いライブラリ、古いルート証明書ストア、証明書検証を無効化した接続文字列が残っていると、セキュリティ評価への対応時に接続障害や検証漏れが起きます。
確認すべき例は次の通りです。
| 対象 | 確認内容 |
|---|---|
| .NET / Npgsql | Windows の信頼されたルート証明機関に必要なルート証明書が入っているか |
| Java | JDBC URL の SSL 設定、トラストストア、証明書検証の有無 |
| Python | psycopg 系ドライバーの sslmode、証明書ファイル、実行環境の CA ストア |
| Node.js | pg などの SSL オプション、証明書検証の扱い |
| レガシーアプリ | TLS 1.0 / 1.1 前提の古いミドルウェアが残っていないか |
pgaudit とログ保存先を確認する
Azure Database for PostgreSQL のデータベースアクティビティ監査ログは、pgaudit 拡張機能を通じて利用できます。pgaudit は詳細なセッション監査ログやオブジェクト監査ログを提供し、Azure Database for PostgreSQL ではログを Azure Storage、Event Hubs、Azure Monitor ログなどへ送信する構成も可能です。(Microsoft Learn)
ただし、監査ログを強化すると、ログ量が増えます。特に DDL、ロール変更、管理操作、アプリの大量クエリがある環境では、Log Analytics コストや保存期間、検索性能、機密情報の扱いを事前に設計してください。
pgaudit 周りで失敗しやすいポイントは次の通りです。
| 注意点 | 具体的な確認 |
|---|---|
| ログ量の増加 | 1日あたりのログ増加量を検証環境で測る |
| 機密情報の混入 | SQL 文やオブジェクト名に個人情報・業務情報が含まれないか確認する |
| 保存期間の不足 | インシデント調査や監査要件に必要な日数を決める |
| メジャーバージョンアップ時の設定 | pgaudit 拡張機能の構成が保持されるかを事前に確認する |
| アラート疲れ | すべてを通知せず、重要な操作に絞って検知ルールを作る |
Microsoft Learn では、PostgreSQL のメジャーバージョンアップ中に pgaudit 拡張機能が自動的に削除され、アップグレード後に再作成される一方、pgaudit.log などのカスタム構成は自動的には保持されないと説明されています。アップグレード作業が近い環境では、監査設定の再適用手順を必ず作っておきましょう。(Microsoft Learn)
開発者が確認すべきアプリ側の影響
この更新は管理者向けのセキュリティ評価に見えますが、実際には開発者にも影響します。特に、ネットワーク経路、TLS、監査ログ、CI/CD の接続方式はアプリケーションの実行やデプロイに直結します。
| 開発者が見る項目 | 確認すべきこと |
|---|---|
| 接続文字列 | sslmode、ホスト名、ポート、証明書検証設定を確認する |
| DB ドライバー | TLS 1.2 / 1.3 と証明書検証に対応したバージョンか確認する |
| CI/CD | マイグレーションやシード処理が Private Endpoint 経由で実行できるか確認する |
| ローカル開発 | Public IP access 無効化後の接続手段を用意する |
| DB マイグレーション | DDL が pgaudit に記録される前提で実行計画を整理する |
| エラーハンドリング | 接続失敗時にリトライが過剰にならないか確認する |
特に注意したいのは、開発者の手元 PC から直接 DB に接続しているケースです。Public IP access を無効にし、Private Endpoint に寄せると、ローカルからの直接接続は基本的にできなくなります。代替として、VPN、Azure Bastion、踏み台 VM、VNet 統合された開発環境、または一時的な管理経路を用意する必要があります。
展開時のおすすめ手順
Preview 機能である以上、いきなり全本番環境に対して推奨事項を一括修正するのは避けるべきです。Azure Updates の “In preview” は非本番用途・テスト用途で利用できる段階として説明されているため、まず検証環境で評価結果と修正影響を確認し、本番は段階的に展開するのが安全です。(マイクロソフト Azure)
| フェーズ | 実施内容 | 成果物 |
|---|---|---|
| 現状把握 | PostgreSQL Flexible Server の一覧、接続元、重要度を整理する | 対象リソース台帳 |
| 評価確認 | Defender CSPM の推奨事項を確認する | 未対応項目リスト |
| 優先度付け | 外部公開、TLS、監査、バックアップに分類する | 対応ロードマップ |
| 検証 | 開発・ステージングで設定変更を試す | 接続試験結果、戻し手順 |
| 本番展開 | メンテナンス時間帯に段階適用する | 変更記録、承認記録 |
| 継続運用 | Azure Policy、IaC、監視に組み込む | 標準設定、運用ルール |
実務では、次の順序で進めると失敗しにくくなります。
- すべての PostgreSQL Flexible Server を一覧化する
- Public IP access、Private Endpoint、TLS、pgaudit、バックアップの現状を確認する
- Defender CSPM の推奨事項と実設定の差分を取る
- 外部公開や暗号化などリスクの高い項目から優先順位を付ける
- アプリ接続、CI/CD、運用ツールへの影響を検証する
- 修正内容を IaC や Azure Policy に反映する
- 定期レビューで推奨事項の再発を確認する
優先度の判断基準
すべての推奨事項を同じ優先度で扱うと、対応が進みにくくなります。まずは「攻撃面を狭める設定」と「接続や運用に大きな影響がある設定」を分けて考えましょう。
| 優先度 | 対応項目 | 判断基準 |
|---|---|---|
| 高 | Public IP access の無効化、Private Endpoint 化 | インターネット公開や広い IP 許可がある場合は最優先 |
| 高 | require_secure_transport、TLS 設定 | 古いクライアントがないか確認したうえで早期対応 |
| 中 | “Allow access to Azure services” の無効化 | Azure 内部の運用ツールや連携サービスの接続経路を確認してから対応 |
| 中 | pgaudit、ログ保持日数 | 監査要件、ログコスト、保存先設計を決めてから対応 |
| 中 | connection_throttle | 認証失敗が多いアプリやバッチがないか確認してから対応 |
| 中〜低 | geo 冗長バックアップ | システム重要度、復旧要件、コストに応じて判断 |
外部公開、暗号化、管理者権限に関する項目は、インシデントに直結しやすいため優先度を高く設定します。一方、監査ログや geo 冗長バックアップは、要件によって最適解が変わります。セキュリティチームだけで判断せず、DBA、アプリ担当、インフラ担当、事業部門を含めて調整してください。
移行・運用で注意したいポイント
既存の自動化と衝突しないか確認する
Terraform、Bicep、ARM テンプレート、Azure CLI、独自スクリプトで PostgreSQL の設定を管理している場合、手動修正しても次回デプロイで元に戻る可能性があります。Defender の推奨事項で設定を変える前に、IaC 側の既定値を確認してください。
推奨事項の “例外” を放置しない
業務上どうしても Public IP access を残す、または監査ログ設定を一部変更できない場合があります。その場合は、理由、期限、代替策、承認者を記録します。「今は変えられない」を恒久的な例外にしないことが大切です。
本番 DB の変更はメンテナンス計画に入れる
ネットワーク、TLS、監査ログ、バックアップの変更は、アプリケーションの停止や性能影響につながることがあります。特に Private Endpoint への移行は、DNS と経路変更を伴うため、DB 側だけで完結しません。本番適用時は、接続試験、監視、ロールバック手順をセットで用意しましょう。
セキュリティ評価を月次レビューに組み込む
security assessments は一度見て終わりではなく、継続的な設定ドリフト検知に使うべきです。新しい PostgreSQL サーバーを作成したとき、アプリ移行を行ったとき、メジャーバージョンアップを行ったとき、ネットワーク構成を変えたときは、Defender の推奨事項を再確認してください。
今日やるべきこと
Microsoft Defender security assessments for Azure Database for PostgreSQL は、PostgreSQL のセキュリティ設定を継続的に見直すきっかけになります。まずは Azure Database for PostgreSQL Flexible Server の一覧を作り、Defender CSPM の推奨事項で未対応項目を確認してください。そのうえで、Public IP access、Private Endpoint、TLS、pgaudit、バックアップの順に影響を整理し、検証環境から段階的に適用するのが安全です。
本番環境では、推奨事項を「すぐ修正するもの」「設計変更が必要なもの」「例外管理するもの」に分けましょう。セキュリティ評価を運用レビューや IaC の標準設定に組み込めば、PostgreSQL の構成ミスを早期に発見し、監査・障害対応・セキュリティ対策を一体で改善できます。
コメント