プロンプトとスコープ
あるチームがPostgreSQL 18からPostgreSQL 19へのアップグレードを計画しています。現在のクラスタではRADIUSと一部のMD5パスワード認証が使用されており、クライアントにはアプリケーション、運用スクリプト、BIツールが含まれます。依存関係の洗い出し、代替手段の選定、クライアントの検証、および停止条件の定義をどのように行うか説明してください。
PostgreSQLの公式Beta通知にはプレリリース機能のプレビューであることが記載されており、本番環境での直接使用は推奨されていません。バージョン19のマイグレーションノートでは、RADIUSサポートが削除され、MD5認証成功後に警告が出力されるようになります。RADIUSはUDP経由でのみサポートされており、プロジェクト側はこれを根本的に修正不可能なほど安全ではないと説明しています。この質問では、すべての環境が影響を受けると決めつけることなく、エビデンスに基づいた認証移行プロセスをテストします。
面接官が評価するポイント
面接官は、プロトコルの削除、パスワード形式、クライアントの対応能力を切り分けること、完全な依存関係インベントリを構築すること、そして最小権限の代替策、可観測性のあるロールアウト、ロールバックを定義することを求めています。優れた回答では、Beta環境での結果は最終バージョンのコミットメントではないことを明記し、MD5の警告を即時接続禁止と誤解しないことも示されます。
回答前の明確化のための質問
- 現在および対象のPostgreSQLのバージョンは何ですか？また、最終リリースの予定時期はいつですか？
- どのエントリポイントがRADIUSを使用しており、どのユーザーや接続がまだMD5を使用していますか？
- ドライバ、接続プール、運用ツールはSCRAM、証明書、またはIDプロキシをサポートしていますか？
- 認証サーバー、ネットワークパス、監査要件、フェイルオーバー、緊急アカウントはどのように管理されていますか？
- 許容されるダウンタイム、ロールバックウィンドウ、セキュリティ責任者はどのようになっていますか？
30秒の回答フレームワーク
「Beta環境は隔離された検証対象として扱います。まず、すべてのpg_hba.confルール、パスワード形式、クライアント、RADIUSの依存関係を洗い出し、PostgreSQL 19のテストクラスタでSCRAM、証明書、または制御されたIDプロキシを検証します。接続の再生、フェイルオーバー、監査シナリオのテスト中は同一IDに対して新旧両方のパスを利用可能に保ち、認証失敗、レイテンシ、監査の欠落を監視しながら低リスクのテナントから段階的に移行します。ログイン失敗、権限拡大、監査ログの損失、ロールバック失敗が発生した場合はロールアウトを停止し、古いクラスタと認証パスを維持します。」
ステップごとの詳細な回答
1. 依存関係インベントリの構築
pg_hba.conf、ロール属性、パスワードストレージ、接続元、クライアントバージョン、接続プール、自動化スクリプトをエクスポートして確認します。RADIUS、MD5、SCRAM、証明書、外部プロキシを個別にマークし、すべてのルールについてユーザー、ネットワーク、データベース、ルールの優先度、オーナーを記録します。アプリケーションのリポジトリだけでなく、一時スクリプトやBIツールにも接続認証情報が含まれている可能性があるため確認します。
2. 機能削除と警告の切り分け
PostgreSQL 19のマイグレーションノートではRADIUSが削除されます。MD5認証の成功時には、md5_password_warningsで制御可能なクライアント警告が出力されます。警告は移行作業の必要性を示すものであり、現在の接続が即座に拒否されるわけではありません。アップグレード前にRADIUSへの依存を置き換え、MD5への依存についてはリスクを同一視せずにパスワードとルールの移行を計画します。
3. 代替手段の選定と権限の制限
クライアントのサポート状況、鍵のライフサイクル、ネットワーク境界、監査要件に基づいて、SCRAM-SHA-256、クライアント証明書、または既存のエンタープライズIDプロキシを評価します。共有のスーパーユーザーではなく、有効期限と所有者を設定した短期間の最小権限移行アカウントを作成し、新旧のアカウントを分離します。設計には、フェイルオーバー、リードレプリカ、運用時の緊急アクセス（break-glass）アカウント、オフライン復旧を含める必要があります。
4. 隔離環境での接続マトリクスの検証
匿名化されたデータと個別の認証情報を使用して本番トポロジを再現します。アプリケーション、プール、移行ツール、バックアップリストア、モニタリング、フェイルオーバーを1つずつテストします。各クライアントのドライババージョンを固定し、認証方式、TLS、接続時間、失敗理由、監査イベントを記録します。テスト中に1つのロールに対して新旧のログインパスを維持することは妥当ですが、テスト用の認証情報を本番環境で使用してはなりません。
psql "host=pg19-test dbname=app user=app_scram sslmode=verify-full" -c 'select 1'
psql "host=pg19-test dbname=app user=app_cert sslmode=verify-full" -c 'select 1'5. カナリアリリース、判定ゲート、およびロールバックの設計
低リスクのテナントまたは重要度の低いジョブから移行します。認証失敗率、接続レイテンシ、パスワードリセットの成功率、監査ログの完全性、フェイルオーバーの成功率にしきい値を設定し、権限拡大、ログイン失敗、監査の欠落、復旧の失敗が発生した場合は停止します。起動可能なPostgreSQL 18のコピー、古いルールバージョン、パスワードローテーション記録、ロールバック用スクリプトを保持し、古いクライアントがロールバックウィンドウ内に復旧できることを検証します。
6. Beta版の不確実性の記録
Beta版の挙動やインターフェースは変更される可能性があります。結論は、特定のクライアント、認証構成、テストデータセットに対する結果として文書化します。バージョン、設定ハッシュ、既知の問題を記録し、最終リリース後に最終承認を得ます。テストクラスタで成功したからといって、すべてのクライアントでの互換性が証明されたわけではありません。
高品質な回答例
PostgreSQL 18の認証ベースラインを凍結し、エントリポイントおよびオーナーごとにpg_hba.conf、ロール、クライアント、RADIUSの依存関係マトリクスを構築します。PostgreSQL 19でRADIUSが削除されるため、隔離されたクラスタで影響を受けるIDに対してSCRAM、証明書、またはエンタープライズIDプロキシを検証し、残りのMD5ユーザーは個別に処理します。MD5成功時の警告は移行タスクを示すものであり、全面的な拒否ではありません。アプリケーション、接続プール、スクリプト、バックアップリストア、フェイルオーバーを再生し、エラー、レイテンシ、監査、権限境界を観察します。低リスクのカナリアリリースがすべてのゲートを通過した後にのみ対象を拡大し、権限拡大、監査の欠落、ログイン失敗、ロールバック失敗が発生した場合はロールアウトを停止します。Betaでのエビデンスは最終バージョン承認のためのインプットとして位置づけます。
よくある間違い
- RADIUSの削除とMD5の警告を同一のイベントとして扱う → 一方はサポート終了、もう一方は移行作業の合図 → それぞれ個別にインベントリを作成して計画する。
- クライアントをテストせずに
pg_hba.confのみを変更する → ドライバやプールが未対応の場合がある → 完全なクライアントマトリクスを再生検証する。 - 本番環境のすべてのパスワードを一度にローテーションする → 障害およびロールバックの影響範囲が大きすぎる → 隔離し、一時的な最小権限アカウントを使用し、バッチごとに移行する。
- 緊急アクセス（break-glass）アカウントを無視する → 障害発生時に復旧用アクセスが失われるリスクがある → 制御され監査された緊急アクセスを準備する。
- Betaでの成功を最終的な互換性の保証として提示する → プレリリースの挙動は変更される可能性がある → 適用範囲を記録し、最終バージョンで再承認する。
フォローアップの質問と回答
アップグレードはどのような場合に停止すべきですか？
ログイン失敗、権限拡大、監査の欠落、重要なクライアントの非互換性、フェイルオーバーの失敗、またはウィンドウ内に完了できないロールバックが発生した場合は停止します。
なぜRADIUSを任意のパスワード方式に置き換えてはならないのですか？
認証強度、鍵のライフサイクル、ネットワーク境界、監査要件が異なるためです。代替手段はセキュリティポリシーを満たし、クライアントおよび障害シナリオをカバーする必要があります。
MD5の警告が出た場合、すべてのMD5ユーザーを直ちに切断する必要がありますか？
いいえ。警告は移行が必要なパスを顕在化させるものです。クライアントを特定し、認証情報をローテーションし、SCRAM、証明書、またはプロキシを検証して、バッチ単位で切り替えます。
隠れたクライアントの見落としがないことをどのように証明しますか？
一定期間にわたり、接続ログ、監査記録、ロールの使用状況、接続元ネットワーク、リポジトリ検索、運用担当者へのヒアリングを相互参照します。移行の前後で未知の接続元や認証失敗を監視します。
Beta版でテストされた変更はいつ本番環境に適用できますか？
最終リリース後、新しいバージョンおよびクライアントマトリクスの再検証、ロールバックおよび監査の訓練の成功、セキュリティ・データベース・ビジネスの各責任者による共同承認を経て、可観測性のあるカナリアリリースを実施した後に適用します。