planetscale-postgres-safety-review

Postgres の安全性レビュー

目的

PlanetScale Postgres データベースのベストプラクティスを提案します。可用性の保護、アプリケーションの分離、復旧、安全な自動化、可観測性に重点を置きます。変更は適用しないでください。

ブランチとスキーマのワークフロー

PlanetScale Postgres のブランチでは、Vitess 形式のデプロイリクエストは使用しません。スキーマの変更は各ブランチに直接加え、本番のスキーマ変更は、ブランチ検証ステップを含むアプリケーションの通常のマイグレーションワークフローで管理してください。

確認事項：

• 開発ブランチまたはテストブランチが存在するかどうか。
• ブランチが空か、バックアップから復元されたものかどうか。
• 本番適用前に、ブランチに対してマイグレーションがテストされているかどうか。
• アプリケーションのマイグレーションを元に戻せるか、またはロールバック戦略が文書化されているかどうか。
• 本番の DDL が手動でレビューされているかどうか。

推奨事項：

• マイグレーションのテストには、本番以外のブランチを作成または使用してください。
• そのブランチに対して、マイグレーションの検証とアプリケーションのテストを実行してください。
• 本番へのマイグレーション適用は、人間が明示的に承認するデプロイステップとして扱ってください。
• PITR／バックアップ復元ブランチはインシデント復旧に使用し、自動ロールバックの仕組みとしては使用しないでください。

承認なしにブランチを作成したり、マイグレーションを実行したり、バックアップを復元したりしないでください。

ロールと最小権限

アプリケーションがデフォルトロールで接続しているか確認してください。その場合は、安全性の問題として指摘してください。

推奨事項：

• アプリケーションサーバーではデフォルトロールではなく、ユーザー定義のアプリケーションロールを使用してください。
• サービス、環境、アクセスパターンごとにロールを分離してください。
• 書き込みが不要な分析、ダッシュボード、レポート、エージェントには読み取り専用ロールを使用してください。
• 自動化には、有効期間が短いロールまたは目的を限定したロールを使用してください。
• Terraform で PlanetScale Postgres のロールを管理する場合、パスワードを Terraform の状態に残さないロールには planetscale_postgres_redacted_branch_role を優先して使用してください。パスワードは API またはダッシュボードからリセットし、 チームのシークレットマネージャーに保存してください。
• アプリケーションを停止せずに認証情報をローテーションする手順を文書化してください。

承認なしにロールを作成、リセット、削除、ローテーションしないでください。

pg_strict

アプリケーションロールで pg_strict が有効になっているか確認してください。

本番のアプリケーションロールでは、WHERE を指定しない危険な UPDATE または DELETE をブロックしてもワークロードに支障がない場合、pg_strict を有効にすることを推奨します。

推奨されるロールアウト手順：

1. 可能であれば、警告モードを有効にするか、本番以外の環境で評価します。
2. ブロックされるクエリを修正します。
3. アプリケーションロールで厳格なブロックを有効にします。
4. 承認済みの一時的な例外手順を文書化します。

新しい接続が確立された後にアプリケーションのクエリがブロックされる可能性があるため、承認なしに pg_strict を有効にしないでください。

Query Insights と pginsights

確認事項：

• 実行が遅いクエリ。
• 読み取り行数の多いクエリ。
• CPU 使用率が高いクエリパターン（Insights API での sort=cpuTime または sort=percentCpuTime）。
• 頻繁に実行されるクエリ。
• エラーが発生しているクエリ。
• アクティブな異常。
• クエリタグ。
• リテラル／生クエリの収集が有効になっているかどうか。

生クエリの収集は pginsights.raw_queries クラスターパラメーターによって制御され、ダッシュボードの Extensions タブでブランチごとに設定します。データベース API オブジェクトにも insights_raw_queries フィールドがありますが、両者の値が異なる場合、実際の収集状態を決めるのはクラスターパラメーターです。実効状態のみを報告してください。2 つの設定画面について、矛盾または不整合があると説明してはいけません。

推奨事項：

• ../planetscale-query-insights-and-tags/SKILL.md に従い、生クエリの収集は機能として扱ってください。パターンレベルのデータでは異常な呼び出しを特定できない場合、それを可能にするのが生クエリの収集です。顧客のデータ取り扱い要件で制約される場合、対象を限定した有効化（インシデント期間、明確な保持期間）と、収集を無効のままにすることのどちらも妥当な選択肢です。その理由を記録してください。
• 帰属の特定にはタグを、呼び出し単位の詳細調査には生クエリの収集を使用してください。これらは相互に補完する手段です。
• デプロイ SHA とルート／ジョブのタグを使用して、アプリケーションのデプロイとリグレッションを関連付けてください。

クエリタグ

SQL コメントに構造化された SQLCommenter タグが含まれているかを評価します。

Insights と Traffic Control の両方に対応するタグを推奨します。

• application
• service
• 具体的な URL ではなく、正規化されたルートテンプレートを使った route
• 関連する場合は controller と action
• バックグラウンドワーカーには job または queue
• エクスポートやレポートなど、負荷の高い機能には feature
• environment
• release_sha
• カーディナリティが制限されている場合に限り tenant_tier
• エージェント、スクリプト、BI ツール、インテグレーション、MCP には source

カーディナリティが高いタグや機密性の高いタグは避けてください。

• ユーザー ID
• リクエスト ID
• メールアドレス
• セッション ID
• テナント ID（明示的に制限され、承認されている場合を除く）
• 識別子を含む生の URL パス
• アクセストークン、シークレット、API キー

データベース Traffic Control

Postgres で次のいずれかのパターンがある場合は、Traffic Control を推奨します。

• 公開されている、または顧客が実行できる負荷の高い機能。
• エクスポート、レポート、分析、アドホック検索が OLTP データベースを共有している。
• 対話型トラフィックを圧迫する可能性のあるバックグラウンドジョブ。
• クエリ量が予測できないサードパーティインテグレーション。
• エージェントが生成するクエリ。
• 既知のクエリフィンガープリントが、ときどき制御不能になる。
• データベースリソースの使用量を制限する必要があるテナントまたはルートのクラス。

デフォルトの推奨事項：

• 予算は warn モードで開始します。
• 可能な場合はクエリタグを使用します。
• 既知の問題のあるクエリには、フィンガープリント固有のルールを使用します。
• 警告を確認し、重要なトラフィックがブロックされないことを確認してから、enforce モードを使用します。
• 緊急時に無効化する手順を整備します。

承認なしに予算や強制ルールを作成しないでください。

バックアップと PITR

次の項目を確認してください。

• 自動バックアップのスケジュール。
• 保持期間。
• WAL/PITR が利用可能かどうか。
• 削除を妨げる手動バックアップ。
• リストア訓練の履歴。
• 復旧手順書。

次のことを推奨します。

• デフォルトのバックアップが顧客の RPO/RTO を満たしていることを確認します。
• 顧客の復旧期間がデフォルトを超える場合は、保持期間を延長するか、バックアップスケジュールを追加します。
• Terraform が顧客の信頼できる情報源である場合、保持期間やスケジュールの変更がインフラストラクチャコードの他の変更とともにレビューされるよう、バックアップポリシーを Terraform で管理します。
• 新しいブランチに対してリストア訓練を実施します。
• リストア後のアプリケーション切り替え手順を正確に文書化します。

承認なしにリストアや緊急バックアップの作成を行わないでください。緊急バックアップはパフォーマンスに影響する可能性があるため、運用作業として扱う必要があります。

接続、プーリング、ネットワークの安全性

次の項目を確認してください。

• アプリが直接ポート 5432 を使っているか、PgBouncer のポート 6432 を使っているか。
• 接続プールのサイズがランタイムとデプロイモデルに合っているか。
• サーバーレス環境やエッジ環境で接続集中が発生する可能性があるか。
• pscale branch connections top によるライブ接続数とセッションの逼迫状況。アクティブなインシデントの診断時には、ブロッカーやアイドル状態のトランザクションセッションも確認します。
• プライベート接続が設定されているか。
• IP 制限が設定されているか。
• 意図せずパブリックアクセスが引き続き可能になっていないか。

次のことを推奨します。

• トランザクションプーリングの制約が許容できる場合は、接続の変動が激しいアプリケーション接続に PgBouncer を使用します。
• PgBouncer のトランザクションモードではサポートできない、セッションに依存する機能には直接接続を使用します。
• プライベートネットワークが必要な場合は、AWS PrivateLink または GCP Private Service Connect を使用します。
• パブリックな露出を減らすために IP 制限を使用します。
• プライベート接続を設定しても、自動的にパブリックアクセスが遮断されるわけではありません。プライベート専用の状態にするには、IP 制限または同等の制御が必要であることを明示します。

承認なしにネットワーク制限を変更しないでください。ネットワークの変更によって、アプリケーションの接続が切断される可能性があります。

拡張機能

安全性と可観測性に関連する、有効化済みおよび利用可能な拡張機能を確認してください。

• pginsights
• pg_strict
• pg_stat_statements
• auto_explain
• pg_squeeze
• pg_cron
• pg_partman_bgw
• pg_hint_plan
• 時系列機能が関係する場合は TimescaleDB

ユースケースが明確な場合にのみ、拡張機能を推奨してください。auto_explain は PlanetScale Postgres で利用でき、auto_explain.log_min_duration などのパラメーターを設定すると、低速クエリの実行計画をログに記録できます。低速クエリの実行計画を取得することで診断が大幅に改善され、ログ量も許容できる場合は、これを推奨してください。Terraform が顧客の信頼できる情報源である場合、Postgres のブランチパラメーターとサポート対象の拡張機能は Terraform で管理できますが、パラメーターや拡張機能の変更にも、ダッシュボードでの変更と同じ承認および再起動への影響の確認が必要です。一部の拡張機能の有効化には、ダッシュボードでの変更とデータベースの再起動が必要です。承認なしに有効化しないでください。

Postgres の Webhook に関する推奨事項

以下の Webhook を評価し、推奨してください。

• branch.anomaly
• branch.out_of_memory
• branch.primary_promoted
• branch.ready
• branch.start_maintenance
• cluster.storage
• database.access_request
• 利用可能な場合は branch.schema_recommendation
• 設定の検証用に webhook.test

推奨する自動化の動作：

• アラート：異常、メモリ不足、プライマリの昇格、ストレージ、メンテナンス。
• エージェントの受付：異常、スキーマの推奨。
• 人による承認：生成された Traffic Control、スキーマ、ロール、またはネットワークの変更すべて。

出力

以下を返してください。

• 現在の Postgres の安全性の状況。
• 可用性に関する最もリスクの高いギャップ。
• 推奨する Traffic Control の計画。
• 推奨するロールと pg_strict の計画。
• 推奨するバックアップ／PITR の計画。
• 推奨するネットワーク構成の計画。
• 推奨するクエリタグ付けの計画。
• 承認が必要な変更案。

最後に、次の文を記載してください。

「Postgres の変更は適用されていません。」