データベースから重要なデータを誤って削除してしまった、あるいは開発環境のつもりで本番環境を消してしまった——そんな血の気が引く瞬間を経験したことはありませんか？しかも追い打ちをかけるように、バックアップが有効になっていなかったと気づく。多くの方にとって、決して他人事ではない状況です。DoiTにも、こうした内容のお問い合わせがほぼ毎週のように寄せられています。本記事では、こうした事態を二度と起こさないための方法をご紹介します。
まずは組織ポリシー（Organizational Policies）から見ていきましょう。
組織ポリシー（Organizational Policies）とは
その名のとおり、組織ポリシーは管理者がGCPの組織やプロジェクト内のリソースの挙動を管理・制御するための仕組みです。組織、フォルダ、プロジェクトの各レベルで設定されるルールで、対象範囲内のリソースに対してどのような操作を許可・禁止するかを定義します。セキュリティやコンプライアンス、運用ガイドラインを徹底するうえで欠かせない機能であり、今回のケースではCloudSQLのバックアップを強制する目的でも活用できます。
では、具体的にどう設定すればよいのでしょうか。残念ながらGCPの公式ドキュメントやガイドはあまり親切とは言えず、サンプルも動かなかったり、Common Expression Languageの知識がないと理解できなかったりします。筆者自身、お客様のトラブル対応をする中で偶然この方法にたどり着きました。順を追って解説していきます。ここではカスタム制約（Custom Constraints）を使い、ポイントインタイムリカバリ（PITR）が有効になっていないCloudSQLデータベースの作成・変更をブロックします。PITRとは、データの損失や破損が発生する直前など、特定の時点までデータベースを復元できるリカバリ手法です。
設定手順
ステップ1：カスタム制約を作成する
まずは、PITRが有効になっていないCloudSQLデータベースの作成や変更を拒否する制約を作成します。注意点として、PITRが有効になっていない既存のCloudSQLデータベースを変更しようとすると、PITRも同時に有効化しない限り、その変更はブロックされます。
- 組織ポリシーのコンソールを開く
Google Cloud Consoleにアクセスし、対象の組織を選択します。
2. カスタム制約を作成する
- CUSTOM CONSTRAINTをクリックします。
- 制約の名前と説明を入力します。後から識別しやすくするためです。
- Enforcement Typeで `sqladmin.googleapis.com/instance` を選択します。
- 制約を適用するアクションとしてCreateとUpdateを指定します。
- [define condition]横の鉛筆アイコンをクリックして条件を入力します。
3. 条件を定義する
- PITRバックアップを強制するため、以下の条件を入力します。
resource.settings.backupConfiguration.pointInTimeRecoveryEnabled == false
- Actionを `deny` に設定します。
ステップ2：制約を適用する
カスタム制約を作成したら、次は組織内に適用していきます。
1. 制約を開く：
まだ開いていない場合は、組織ポリシーのコンソールから先ほど作成した制約を開きます。
2. ポリシーを管理する：
- 制約ページ上部のMANAGE POLICYをクリックします。
- 既存のポリシーがある場合はOverride parent's policyを選択します。
- 適用ルールをOnにします。
- 下図のような状態になればOKです。
一部のCloud SQLデータベースだけにPITR要件を適用したい場合は、Conditionsを使って対象リソースを絞り込めます。
- ADD CONDITIONをクリックします。
- Tagなどの絞り込み条件を入力し、必要なValue pathを選択します。
既存リソースに意図せず影響を与えないよう（PITRを追加しないと既存のCloudSQLデータベースを変更できない、という前述の注意点を思い出してください）、まずはポリシーをテストすることをおすすめします。
- Test Policyをクリックし、検証が完了するまで待ちます。
- SIMULATION HISTORYページに移動し、結果が想定どおりかを確認します。
- 問題なければカスタム制約の画面に戻り、MANAGE POLICYを選択します。
- 変更がまだ反映されていない場合は、先ほどと同様にポリシーを設定します（上記参照）。SET POLICYをクリックし、表示される警告を承認します。
ステップ3：ポリシーの適用を検証する
ポリシーが意図どおりに機能するかを確認することは欠かせません。次の手順で動作を検証しましょう。
- ポリシーをテストする：
ポイントインタイムリカバリを有効にせずにCloud SQLインスタンスを作成・更新しようとすると、組織ポリシーによって拒否されるはずです。
- 以下のコマンドを実行します。
gcloud sql instances create test-instance --region=us-central1 --no-backup
- ポイントインタイムリカバリを有効にする必要がある旨のエラーが返るはずです。
2. ポリシーに準拠したCloud SQLインスタンスを作成する：
続いて、ポイントインタイムリカバリを有効にしたCloud SQLインスタンスを作成し、ポリシーに準拠していることを確認します。
- 以下のコマンドを実行します。
gcloud sql instances create compliant-instance — region=us-central1 — backup-start-time=23:00 — enable-point-in-time-recovery
こちらは正常に作成できるはずです。
以上の手順により、組織ポリシーにカスタム制約を作成・適用し、すべてのCloud SQLインスタンスでポイントインタイムリカバリのバックアップが確実に有効化されるようにできました。データ保護のベストプラクティスに沿うだけでなく、組織のクラウドリソース全体でコンプライアンスを担保することにもつながります。そして何より、誰かが重要なデータを「またしても」消してしまったときの大きな頭痛の種を未然に防げるのです。
慌てないでください
もしデータを失ってしまっても、あなただけではありません。DoiT Internationalは、データ復旧のサポートはもちろん、再発防止のためのCloud SQLバックアップ強制設定までお手伝いします。カスタマイズされたクラウドソリューションの構築を得意とする180名超のシニアクラウドエキスパートが、プロセスをスムーズに進め、コンプライアンスを確保しながら将来の要件にも効率よく応えられるよう、インフラの最適化を支援します。
Cloud SQLのバックアップポリシーをプロフェッショナルかつシームレスに管理するために、ぜひ今すぐお問い合わせください。お客様固有のニーズに合わせて、最適な意思決定と最良のソリューション実装をサポートいたします。Cloud SQLにとどまらず、AWS、GCP、Azureを横断したポリシー全体のレビューにも対応し、包括的なコンプライアンスとセキュリティを実現します。
DoiTのエキスパートが、戦略面のガイダンスから技術的な知見まで、あらゆる場面でお客様をサポートします。このポリシー適用フェーズにおいて、貴社にとって最適な進め方を一緒に検討し、堅牢でコンプライアンスに準拠し、ビジネスの成功を後押しするクラウドインフラを実現しましょう。