Cloud Build で実現する SLSA レベル 3 とプロベナンス、Cloud Run Functions でラベルの設定を行う方法、スケーラブルなデータ分析基盤の構築を説明

今回から、Professional Cloud Developer 認定の取得を目指す中で、私自身が学習した内容を整理し、アウトプットしていきます。
試験対策としての知識整理はもちろんですが、実務にもそのまま活かせる視点を意識してまとめていく予定です。

本記事ではその中でも、近年特に重要性が高まっているソフトウェアサプライチェーンのセキュリティに関連するトピックとして、Cloud Build を用いた SLSA レベル 3 の実現方法とプロベナンスについて解説します。
あわせて、サーバーレス開発に欠かせない Cloud Run Functions におけるラベル設定の考え方と具体的な設定方法、さらにスケーラブルなデータ分析基盤をどのように設計・構築するかについても取り上げます。

いずれも Professional Cloud Developer 試験で問われやすいテーマであり、設計思想やベストプラクティスを理解しておくことが重要な分野です。
これから認定資格に挑戦する方や、Google Cloud を使った開発・運用の理解を一段深めたい方にとって、参考になる内容を目指しています。

是非、最後までご覧いただけると嬉しいです。

Cloud Build で実現する SLSA レベル 3 とプロベナンス
Cloud Run Functions でラベルの設定を行う方法
スケーラブルなデータ分析基盤の構築
まとめ

Cloud Build で実現する SLSA レベル 3 とプロベナンス

近年、ソフトウェアのビルドプロセスを狙ったサプライチェーン攻撃が急増しています。これに対抗するため、Google Cloud では SLSA（サルサ）と呼ばれるフレームワークを提唱し、ビルドの信頼性を客観的に証明する仕組みを提供しています。

本記事では、Cloud Build と Binary Authorization を組み合わせて、SLSA レベル 3 相当のセキュリティと改ざん不可能なビルドプロベナンスを実現する方法を解説します。

1. SLSA レベル 3 とは何か？

SLSA は、ソフトウェアの完全性を確保するためのチェックリスト形式の規格です。その中で「レベル 3」を達成するには、主に以下の要件が求められます。

ビルドプラットフォームの信頼性：ビルドが専用の信頼できる環境で実行されること。
改ざん不可能なプロベナンス：ビルドの「出自（Provenance）」が、ビルドを実行したユーザー自身ではなく、信頼できるビルドサービスによって自動生成され、後から変更できないこと。
隔離されたビルド：各ビルドが他のプロセスから隔離されていること。

Cloud Build は、マネージドサービスとしてこれらの要件をネイティブにサポートしています。

2. 改ざん不可能な「ビルドプロベナンス」の生成

ビルドプロベナンスとは、その成果物が「いつ、どこで、どのソースコードから、どのような手順でビルドされたか」を記録した証明書です。

Cloud Build による自動生成

Cloud Build でコンテナイメージをビルドし Artifact Registry に格納すると、ビルド完了時に自動的にプロベナンスが生成されます。

このプロベナンスは以下の特徴を持ちます。

サービス生成：ビルドプロセスの外部（Cloud Build サービス自体）で生成されるため、ビルドスクリプト内で悪意のあるコードが実行されても、プロベナンスの内容を偽装することはできません。
署名付き：Google が管理する鍵でデジタル署名されており、内容の正当性が保証されます。

生成される情報の例

ソースリポジトリの URI とコミット SHA
使用されたビルドステップと引数
ビルド出力（イメージのダイジェスト値）
ビルドの開始・終了時刻

3. SLSA レベル 3 を実現するための構成ステップ

具体的に、Google Cloud 上で SLSA レベル 3 相当のパイプラインを構築する手順は以下の通りです。

ステップ 1：Cloud Build でのビルド実行

Cloud Build を使用して Artifact Registry にイメージをプッシュするように構成します。cloudbuild.yaml を使用して、標準的なビルドフローを定義します。

ステップ 2：プロベナンスの検証（Attestation）

Cloud Build が生成したプロベナンスは、そのままでは単なる「記録」です。これをデプロイ時の判断基準（アテステーション）として利用可能にします。 Cloud Build には、ビルド完了時に自動的にプロベナンスを検証し、SLSA レベルの要件を満たしているかを確認する機能が備わっています。

ステップ 3：Binary Authorization による強制

ここが最も重要なステップです。Binary Authorization（バイナリ認証） を使用して、検証済みのプロベナンスを持たないイメージのデプロイを拒否するポリシーを設定します。

アテスターの設定：「Cloud Build によってビルドされ、署名されたもの」を信頼するアテスターを作成します。
ポリシーの適用：GKE (Google Kubernetes Engine) や Cloud Run のデプロイメントにおいて、「このアテスターの署名がないイメージは実行を許可しない」というポリシーを強制します。

これにより、開発者が手元の PC でビルドした未検証のイメージや、悪意のある第三者が差し替えたイメージが本番環境で動作することを物理的に防ぐことができます。

4. なぜこの構成が強力なのか？

信頼の起点（Root of Trust）：開発者個人の端末ではなく、Google Cloud のインフラそのものを信頼の起点にできます。
可視性と監査可能性：万が一脆弱性が発見された際も、プロベナンスを辿ることで「どのソースコードから作られたものか」を即座に特定できます。
運用の自動化：セキュリティチェックを人間が行うのではなく、プラットフォームが自動で検証・拒否を行うため、開発スピードを落とさずに安全性を確保できます。

Cloud Build で実現する SLSA レベル 3 とプロベナンスのまとめ

Cloud Build と Binary Authorization を組み合わせることで、SLSA レベル 3 が提唱する「改ざん不可能で検証可能なサプライチェーン」を容易に構築できます。

コンテナ化が進む現代のアプリケーション開発において、イメージの出自を証明するプロベナンスは、単なるメタデータではなく、システム全体の安全を守る「パスポート」のような役割を果たします。まずは Cloud Build のデフォルト機能であるプロベナンス生成から活用を始めてみてはいかがでしょうか。

Cloud Run Functions でラベルの設定を行う方法

Google Cloud のリソース管理において、ラベルは「キー」と「値」のペアで構成されるメタデータです。Cloud Run Functions に一貫したラベルを付与することで、コスト分析、監査ログのフィルタリング、そして複雑なトリガー構成の整理が劇的に容易になります。

1. なぜ「ラベル」が必要なのか？

ラベルを設定する主なメリットは以下の2点です。

監査の効率化 (Audit Logging 対応)：Cloud Audit Logs を確認する際、ログエントリにはリソース情報が含まれます。ラベルを設定しておくことで、大量のログの中から「特定のチーム」や「特定の環境（prod/dev）」の操作ログだけを素早く抽出できます。
呼び出し元・トリガーの識別 (Calling Functions 対応)：関数の呼び出し方法は、HTTP、Pub/Sub、Cloud Storage など多岐にわたります。ラベルに trigger_type: pubsub や source: internal_app と記述しておくことで、関数の役割を一目で判別できます。

2. Cloud Functions へのラベル設定方法

関数を作成または更新する際に、以下の方法でラベルを付与できます。

gcloud コマンドでの設定

デプロイ時に --update-labels フラグを使用するのが最も効率的です。

gcloud functions deploy YOUR_FUNCTION_NAME \
  --gen2 \
  --runtime python310 \
  --trigger-http \
  --update-labels team=marketing,env=prod,service=notification

Terraform での一括設定（推奨）

IaC（Infrastructure as Code）を利用している場合、リソースブロック内で一括管理が可能です。

# Cloud Function (Gen 2)
resource "google_cloudfunctions2_function" "function" {
  name     = "my-function"
  location = "asia-northeast1"

  description = "HTTP-triggered function"

  build_config {
    runtime     = "nodejs16"
    entry_point = "helloWorld"

    source {
      storage_source {
        bucket = google_storage_bucket.source_bucket.name
        object = google_storage_bucket_object.function_source_object.name
      }
    }
  }

  service_config {
    available_memory   = "256M"
    timeout_seconds    = 60
    ingress_settings   = "ALLOW_ALL"
    all_traffic_on_latest_revision = true

    labels = {
      env         = "prod"
      team        = "marketing"
      service = "notification"
    }
  }

3. 監査ログでのラベル活用術

監査ログのドキュメントにあるように、Cloud Run Functions の作成や削除はすべて記録されます。

ログエクスプローラで以下のようにクエリを記述すると、特定のラベルが付いたリソースに関する操作だけを追いかけることができます。

resource.type="cloud_run_revision"
labels.env="prod"

ラベルは resource.labels ではなく、ログエントリの labels フィールドとして格納されるため、
labels.<key>=<value> の形式でフィルタリングします。

4. 推奨されるラベル設計のベストプラクティス

「すべてのリソースにラベルをつける」という目標を達成するために、以下の共通キーを定義することをお勧めします。

キー名	値の例	用途
`env`	`prod`, `staging`, `dev`	環境の識別
`team`	`billing`, `frontend`	所有チームの特定
`managed_by`	`terraform`, `manual`	管理手段の特定
`service`	`payment-api`	関連するビジネスロジック名

Cloud Run Functions でラベルの設定を行う方法のまとめ

Cloud Functions の呼び出し(Calling)が増え、システムの規模が大きくなるほど、ラベルのないリソースは「野良リソース」化し、コストやセキュリティのリスクとなります。

すべてのデプロイパイプライン（CI/CD）にラベル付与を組み込むこと
監査ログを確認する際のフィルタ条件としてラベルを活用すること

この2点を徹底するだけで、Google Cloud 上のガバナンスは大幅に向上します。

スケーラブルなデータ分析基盤の構築

モダンなデータ基盤には、単にデータを貯めるだけでなく、刻々と変化するストリームデータを「即座に意味のある形に変える」能力が求められます。Google Cloud では、Pub/Sub、Dataflow、Cloud Run Functions を連携させることで、この課題を解決します。

1. データ収集の要：Pub/Sub による高スループットな取り込み

大規模システムの入り口を担うのが Pub/Sub です。

• パブリッシャー（発行元）の役割：アプリケーションやデバイス（パブリッシャー）は、トピックに対してメッセージを送信します。Pub/Sub はメッセージを複数のレプリカに保存し、高い可用性を保証します。

• 非同期による疎結合化：パブリッシャーは「誰がデータを処理するか」を気にする必要がありません。これにより、スパイク（急激なトラフィック増）が発生しても、後続のシステムをパンクさせることなくデータを安全にバッファリングできます。

2. ストリーム処理の心臓部：Dataflow による高度な分析

収集したデータをリアルタイムで分析・加工するのが Dataflow です。

特に重要なのが「ウィンドウ（Windowing）」の概念です。ストリーミングデータは無限に続くため、分析するには「時間」で区切る必要があります。ウィンドウの種類特徴活用例固定時間（Tumbling）5分ごとなど、重なりのない一定間隔で区切る。1時間ごとの売上合計の算出スライディング（Sliding）10分間のデータを5分ごとに計算するなど、重なりを持たせる。過去5分間の移動平均の算出セッション（Session）ユーザーの活動が途切れるまでを一つの区切りとする。

ユーザーが離脱するまでのアプリ操作ログ分析 Dataflow は Apache Beam モデルを採用しており、同じコードでバッチ処理とストリーム処理の両方を実行できるため、運用コストを大幅に削減できます。

3. 軽量な処理と連携：Cloud Functions によるイベント駆動

すべての処理が重厚なパイプラインである必要はありません。Cloud Run Functions は、特定のイベントに反応してコードを実行する「接着剤」のような役割を果たします。

• トリガー連携：Pub/Sub にメッセージが届いた瞬間に起動したり、Cloud Storage にファイルが保存された瞬間にデータの検証（バリデーション）を行ったりするのに最適です。

• サーバーレスの利点：インフラの管理が一切不要で、実行された時間分しかコストが発生しません。データの簡単な整形や、外部 API への通知、アラートの発報などに非常に効果的です。

4. 理想的なアーキテクチャ・フロー

大規模データ分析基盤の標準的なフローは以下のようになります。

Ingest (収集)：アプリから Pub/Sub へメッセージをパブリッシュ。
Process (加工)：Dataflow がストリームデータを受け取り、ウィンドウ処理を用いてリアルタイム集計。
React (反応)：異常値を検知した場合、Cloud Functions をトリガーして管理者に Slack 通知。
Store/Analyze (蓄積)：最終的なデータを BigQuery に流し込み、BI ツールで可視化。

スケーラブルなデータ分析基盤の構築のまとめ

この構成の最大の強みは、「データ量に応じて勝手にスケールする」点にあります。Pub/Sub は毎秒数百万のメッセージを処理でき、Dataflow は負荷に応じてワーカーの数を自動調整します。「将来、データが今の100倍になっても壊れない基盤」を作りたいのであれば、これらマネージドサービスの組み合わせが最短ルートです。

まとめ

今回は、下記３点について説明しました。

Cloud Build で実現する SLSA レベル 3 とプロベナンス
Cloud Run Functions でラベルの設定を行う方法
スケーラブルなデータ分析基盤の構築

本記事では、Professional Cloud Developer 試験でも重要となる「セキュリティ」「ガバナンス」「スケーラビリティ」という3つの観点から、実践的なトピックを整理しました。

Cloud Build と Binary Authorization を活用することで、SLSA レベル 3 が求める検証可能なサプライチェーンを現実的な構成で実現できることを確認しました。また、Cloud Run Functions におけるラベル設計は、リソース管理やコスト管理、監査対応の品質を大きく左右する重要な要素です。CI/CD にラベル付与を組み込むだけでも、Google Cloud 全体のガバナンスは確実に向上します。
さらに、Pub/Sub と Dataflow を組み合わせたデータ分析基盤は、将来のデータ増加を前提とした堅牢なアーキテクチャとして非常に有効です。

いずれのトピックも、試験対策にとどまらず、実務でそのまま活かせる考え方ばかりです。
Professional Cloud Developer では、こうした「なぜその構成を選ぶのか」という判断力が問われます。
本記事が、理解を深めるきっかけとなれば幸いです。

これからも、Macのシステムエンジニアとして、日々、習得した知識や経験を発信していきますので、是非、ブックマーク登録してくれると嬉しいです！

それでは、次回のブログで！