📝

GCPプロジェクトを削除せずに停止したことを証明するには？（監査・エビデンス編）

に公開
Google Cloud
Google Cloud
gha
auditlog
tech

サマリ

  • GCP プロジェクトを「削除」ではなく「停止」した際、何をもって停止と証明するかを整理した
  • GitHub Actions と GCP Audit Logs を突き合わせ、操作と結果を二重に裏付けた
  • ログ・画面・アクセス確認を組み合わせることで、後から説明可能なエビデンスを残した

なぜ「停止したことの証明」が必要だったのか

今回の作業では、GCP プロジェクトを「削除」するのではなく、「停止する」 という判断を取りました。

プロダクト自体は終了していますが、

  • 監査・証跡目的で保持すべきデータがある
  • GCS や Cloud SQL など、一部のリソースは残す必要がある
  • 将来、経緯や状態を説明する可能性がある

といった理由から、プロジェクトやすべてのリソースを完全に削除することはできませんでした。
このようなケースでは、単に「Google Cloudのプロジェクトを削除しました」と説明するだけでは不十分です。GCP 上には一部のリソースが残り続けるため、

  • 本当にアプリケーションは動いていないのか
  • 外部からアクセスできない状態になっているのか
  • 意図しないリソースが残っていないか

といった点を、第三者が後から確認できる状態にしておく必要があります。そのため今回の停止作業では、単にリソースを削除・停止するだけでなく、

「停止したことを、あとから証明できる状態にする」

こと自体を、作業の重要なゴールのひとつとして位置づけました。

「停止した」と言える状態をどう定義したか

「停止したことを証明する」ためには、まず 「停止している状態とは何か」 を明確に定義する必要があります。

今回は、次の観点をすべて満たしていることを「停止したと言える状態」としました。

  • アプリケーションが実行されていないこと
  • 外部からアクセスできないこと
  • 不要なリソースが削除されていること
  • 意図したリソースのみが残っていること

エビデンスとして使ったものの全体像

「停止したと言える状態」を証明するために、今回は 複数の種類のエビデンスを組み合わせる 方針を取りました。ひとつの証跡だけでは、

  • 操作はしたが、本当に反映されたか分からない
  • 設定は変わったが、実際に止まっているか分からない

といった不安が残るためです。そこで、エビデンスを次のように役割ごとに整理しました。

操作の事実を示すエビデンス

  • GitHub Actions の実行ログ
  • Terraform apply / destroy のログ

これらは、いつ/誰が/どの変更を加えたか、を示す 操作の証跡 になります。

Run terraform apply
Acquiring state lock...

VPC Subnetwork: Destroying...
VPC Access Connector: Destroying...

VPC Subnetwork: Still destroying... [30s elapsed]
VPC Access Connector: Still destroying... [1m elapsed]
VPC Access Connector: Still destroying... [3m elapsed]

VPC Subnetwork: Destruction complete
VPC Access Connector: Destruction complete

Apply complete! Resources: 0 added, 0 changed, 2 destroyed.

上記は、GitHub Actions 上で実行されたTerraform apply のログを簡略化したものです。
リソース削除が実行され、正常に完了していることが確認できます。

GCP 上での変更を裏付けるエビデンス

  • GCP Audit Logs（Admin Activity logs）
  • リソース削除・変更のログ

GitHub Actions のログだけでは、「GCP 側で本当に変更されたのか」までは分かりません。Audit Logs を合わせて確認することで、実際にどのAPIが呼ばれてリソースが削除・変更れたかを GCP 側の事実として裏付ける ことができます。

NOTICE 2025-12-05T08:34:50Z  Compute Engine / instanceTemplates.delete  (VPC Access Connector)
NOTICE 2025-12-05T08:35:42Z  Compute Engine / subnetworks.delete        (VPC Subnetwork)
NOTICE 2025-12-05T08:36:18Z  VPC Access     / connectors.delete         (VPC Access Connector)
NOTICE 2025-12-05T08:37:01Z  Cloud Logging  / sinks.delete              (Logging Sink)

上記は、GCP Audit Logs（Admin Activity logs）から、削除操作に関するログメッセージのみを簡略化して抜き出したものです。service / method / resource が分かる形で並べており、Terraform から実行された削除操作がGCP 側でも正式に記録されていることが分かります。

状態を直感的に示すエビデンス

  • GCP コンソールの画面キャプチャ
  • フロントエンドへのブラウザアクセス確認
  • API サーバーへの疎通確認（ping）

ログだけでは把握しづらい「今どういう状態なのか」を補足するために、実際の画面やアクセス結果も記録しました。特に、ブラウザからアクセスして表示されない、API に到達できない、といった結果は、第三者が見ても直感的に理解しやすい証跡になります。

作業の流れを示すエビデンス

  • 作業前の状態
  • 作業内容のログ
  • 作業後の状態

これらを 時系列で整理することで、何をして、何が変わり、今どうなっているか、を後から追えるようにしました。

まとめ

「止める」こと自体は簡単でしたが、「なぜ止まっているのか」を説明する責任は長く残ります。これから GCP プロジェクトの停止や縮退を行う場合は、ぜひ 作業そのものと同じくらい、証跡の残し方 を意識してみてください。

Discussion