Cloud SQL PostgreSQL log_statementフラグ設定の有効化について

このブログシリーズ 「クラウドセキュリティ 実践集」 では、一般的なセキュリティ課題を取り上げ、「なぜ危険なのか?」 というリスクの解説から、 「どうやって直すのか?」 という具体的な修復手順(コンソール、gcloud CLI、Terraformなど)まで、分かりやすく解説します。
この記事では、Cloud SQL PostgreSQLインスタンスの「log_statement」データベースフラグが適切に設定されていないについて、リスクと対策を解説します。

ポリシーの説明
Cloud SQL PostgreSQLインスタンスの「log_statement」フラグは、どのSQLステートメントをログに記録するかを制御する重要なパラメータです。このフラグを適切に設定することで、データベースへのアクセスや操作を監査し、セキュリティインシデントの調査やコンプライアンス要件への対応が可能になります。
log_statementの設定値とパフォーマンスへの影響
- none: ログ記録なし(パフォーマンスへの影響なし、但し監査不可)
- ddl: CREATE/ALTER/DROPのみ記録(パフォーマンスへの影響最小、基本的な監査可能)
- mod: DDL+DML(INSERT/UPDATE/DELETE)を記録(中程度の影響、データ変更の追跡可能)
- all: 全クエリを記録(高負荷環境では5-15%のパフォーマンス低下、完全な監査証跡)
ストレージコストへの影響
- ログ量はクエリの種類と頻度に依存
- “all”設定では、月間数GB〜数百GBのログが発生する可能性あり
- Cloud Loggingの保持期間設定により、長期保存コストを最適化可能
実運用での推奨設定
環境 | 推奨設定 | 理由 |
---|---|---|
開発環境 | all | デバッグとトラブルシューティングに必要 |
ステージング環境 | mod | 本番環境と同等の監査レベルで動作確認 |
本番環境(一般) | ddl | スキーマ変更を追跡しつつパフォーマンスを維持 |
本番環境(高セキュリティ) | mod/all | コンプライアンス要件に応じて選択 |
修復方法
コンソールでの修復手順
Google Cloud コンソールを使用して、log_statementフラグを適切に設定します。
- Google Cloud Consoleにログイン
- Cloud SQLインスタンスページに移動します
- 対象のPostgreSQLインスタンスを選択
- 設定を変更したいPostgreSQLインスタンス名をクリックします
- 編集画面を開く
- インスタンスの詳細ページで「編集」ボタンをクリックします
- データベースフラグセクションに移動
- 設定画面を下にスクロールし、「フラグ」セクションを見つけます
- 「データベースフラグ」の「項目を追加」をクリックします
- log_statementフラグを設定
- フラグのドロップダウンメニューから「log_statement」を選択します
- 値として以下のいずれかを選択します:
none
: SQLステートメントを記録しない(推奨されません)ddl
: データ定義言語(CREATE、ALTER、DROP等)のみ記録mod
: DDLおよびデータ変更文(INSERT、UPDATE、DELETE等)を記録all
: すべてのSQLステートメントを記録(最も詳細)
- 組織のポリシーに基づいて選択
- 一般的な推奨設定:
- 開発環境:
mod
またはall
(デバッグ用) - 本番環境:
ddl
またはmod
(パフォーマンスと監査のバランス) - 高セキュリティ環境:
all
(完全な監査証跡)
- 開発環境:
- 一般的な推奨設定:
- その他の関連フラグも設定
- 包括的なログ記録のため、以下のフラグも設定することを推奨します:
log_min_duration_statement
: 遅いクエリを記録(例:1000ms)log_connections
: 接続情報を記録(on)log_disconnections
: 切断情報を記録(on)
- 包括的なログ記録のため、以下のフラグも設定することを推奨します:
- 変更を保存
- ページ下部の「保存」ボタンをクリックして設定を適用します
- 注意: 設定変更によりインスタンスが短時間再起動される場合があります
Terraformでの修復手順
Cloud SQL PostgreSQLインスタンスのlog_statementフラグを適切に設定するTerraformコードと、主要な修正ポイントを説明します。
# Cloud SQL PostgreSQLインスタンスの設定
resource "google_sql_database_instance" "postgresql_audited" {
>>> Skip
settings {
# 重要: log_statementフラグの設定
database_flags {
name = "log_statement"
value = "ddl"
}
}
}
ベストプラクティス
- 段階的な導入: 本番環境では”ddl”から始め、必要に応じて”mod”や”all”に移行
- ログ保持期間の設定: Cloud Loggingで適切な保持期間を設定し、ストレージコストを管理
- 定期的なレビュー: ログ内容を定期的にレビューし、異常なパターンを検出
- アラートの設定: DDL操作や大量クエリに対するアラートを設定
最後に
この記事では、Cloud SQL PostgreSQLインスタンスの「log_statement」データベースフラグが適切に設定されていないについて、リスクと対策を解説しました。
この問題の検出は弊社が提供するSecurifyのCSPM機能で簡単に検出及び管理する事が可能です。 運用が非常に楽に出来る製品になっていますので、ぜひ興味がある方はお問い合わせお待ちしております。 最後までお読みいただきありがとうございました。この記事が皆さんの役に立てば幸いです。