GCP実践設計：Cloud Storage バケット公開配信・API制御・CI/CD

Professional Cloud Developer 認定試験では、「セキュリティ」「配信設計」「API管理」といった複数の観点を横断した設計力が求められます。

本記事では、Cloud Storageの安全なコンテンツ公開、Apigeeによるプラン別クォータ制御、そしてBinary AuthorizationによるセキュアなCI/CDパイプライン構築について解説します。

いずれも、実務でそのまま活用できる重要な設計パターンです。単なる機能理解にとどまらず、どのように組み合わせて使うかという視点で整理しています。試験対策と実践力の両方を高めるためのポイントを押さえていきましょう。

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

Cloud Storageのコンテンツを一般公開する設計
Apigeeによるプラン別クォータ制限の実装ガイド
Binary AuthorizationによるセキュアなCI/CDパイプライン構築
まとめ

Cloud Storageのコンテンツを一般公開する設計

Cloud Storage 上のコンテンツを一般公開する際は、「誰に・どこまで・どの期間」公開するかの設計が重要です。本記事では、ログイン不要でコンテンツを提供するための代表的な3つの方法を解説します。シンプルな公開設定から、期限付きアクセス、さらにエッジでの防御まで、用途に応じた最適な選択肢を整理します。セキュリティと利便性のバランスを取りながら、安全な配信設計を実現しましょう。

1. 最もシンプルな「公開アクセス（allUsers）」

特定のバケットやオブジェクトを完全に一般公開する方法です。Webサイトの静的資産（ロゴ、CSS、JS）や、誰が見ても問題ない公開資料に最適です。

設定のポイント

権限付与：バケットまたはオブジェクトに対して、allUsers という特別なエンティティに Storage Object Viewer（ストレージオブジェクト閲覧者） のロールを付与します。
アクセス方法：https://storage.googleapis.com/[BUCKET_NAME]/[OBJECT_NAME] というURLで誰でもアクセス可能になります。

⚠️ 注意：公開アクセス防止組織レベルやプロジェクトレベルで「公開アクセス防止（Public Access Prevention）」が有効になっている場合、この設定はできません。意図的に公開する場合は、この設定をオフにする必要があります。

2. 期間限定の「合鍵」を発行する：署名付きURL

「普段は非公開だが、特定のユーザーにだけ、特定の時間だけ見せたい」という場合に最強の武器となるのが署名付きURL（Signed URLs）です。

仕組みとメリット

署名付きURLは、URL自体に認証情報が含まれた「期間限定のチケット」のようなものです。

Google ID不要：ユーザーがGoogleアカウントを持っている必要はありません。URLを知っている人だけがアクセスできます。
時間制限：「発行から15分間だけ有効」といった細かい制御が可能です。
権限の委譲：アプリケーション（サービスアカウント）が持つ権限を、一時的にURLの保持者に貸し出すイメージです。

💡 コストについて：署名付きURLの生成自体に特別な料金は発生しません。ただし、IAM Credentials APIを使ったV4署名方式を採用する場合は、APIリクエスト料金が発生する場合があります。転送コストは通常の下り転送料と同様です。

いつ使うべきか？

有料コンテンツのダウンロードリンク
ユーザーがアップロードした個人用ファイルのプレビュー
一時的な共有リンクの発行

3. 配信をさらに守る：Load Blancer ＋Cloud CDN＋Cloud Armor

公開アクセスや署名付きURLを使っても、インターネットの荒波にそのまま晒すのは不安な場合があります。そこで役立つのが、外部HTTP(S)負荷分散（LB）+ Cloud CDN + Google Cloud Armor の組み合わせです。

⚠️ 重要：Cloud ArmorはGCSの公開URL（storage.googleapis.com）に直接適用することはできません。Cloud Armorを利用するには、GCSをバックエンドとするCloud LBを前段に配置する構成が必須です。

エッジで守る理由

セキュリティチェックをGoogleネットワークの入り口（エッジ地点）で行うことで、不正なリクエストをバックエンドに届く前に遮断できます。

IP制限・地理制限：「公開コンテンツだが、特定の国からのアクセスだけは拒否したい」「特定のオフィスIP以外はブロックしたい」といった制御が可能です。
WAF機能：SQLインジェクションやクロスサイトスクリプティング（XSS）などの攻撃からコンテンツを保護します。
コスト削減：不正なトラフィックをエッジで捨てることで、バックエンドへの負荷や下りデータ転送料金を節約できます。

比較：どの方法を選ぶべきか？

特徴	公開アクセス (allUsers)	署名付きURL
ユーザーのログイン	不要	不要
セキュリティ	低（URLを知れば誰でも）	高（期限付き・個別発行）
実装の複雑さ	非常に簡単（コンソールで完結）	中（バックエンドでURL生成が必要）
コスト	下り転送料のみ	下り転送料（V4署名使用時はAPIリクエスト料金が加わる場合あり）
推奨ユースケース	Webサイトの素材、公開マニュアル	マイページ内のPDF、期間限定リンク

※ Cloud Armorは上記いずれかの方法と組み合わせる「追加のセキュリティ層」です。LB経由の構成を採用する場合に適用できます。

構成案：安全な一般向け配信アプリケーション

これらを組み合わせた理想的な構成は以下の通りです。

ストレージ：GCSバケットを用意。
配信：外部HTTP(S)負荷分散（LB）と Cloud CDN をセットアップ。
セキュリティ：LBに Cloud Armor エッジポリシー を適用し、悪意のあるIPや地域をブロック。
認可
- 全公開ファイルは allUsers で公開。
- ユーザー固有のファイルは 署名付きURL をアプリケーションサーバーで生成して渡す。

Cloud Storageのコンテンツを一般公開する設計のまとめ

Cloud Storage の公開方法は、用途に応じて適切に使い分けることが重要です。完全公開はシンプルですがリスクがあり、署名付きURLは安全性と柔軟性に優れます。さらに、Cloud CDN や Cloud Armor を組み合わせることで、防御とパフォーマンスを強化できます。重要なのは単一の手法に頼らず、複数の仕組みを組み合わせることです。これにより、安全かつスケーラブルなコンテンツ配信が実現できます。

Apigeeによるプラン別クォータ制限の実装ガイド

GKE（Google Kubernetes Engine）は強力なコンピューティング基盤ですが、APIの「誰が」「どのくらい」使っているかを個別に追跡し、プランごとに制限をかける処理をアプリケーションコード内に記述するのは、保守性やセキュリティの観点から推奨されません。

そこで、APIの「玄関口」としてApigeeを配置するアーキテクチャが標準となります。

1. Apigeeとは何か？

Apigeeは、APIの公開、保護、分析、収益化を行うためのフルマネージドなAPI管理プラットフォームです。バックエンド（GKE）の前にプロキシとして立ち、以下のような役割を果たします。

認証・認可：APIキーやOAuthトークンの検証。
トラフィック管理：クォータ制限やレート制限の適用。
分析：どのプランのユーザーが最もAPIを利用しているかの可視化。

2. 「ベーシック」と「プレミアム」のクォータ制限（Quota Policy）

特定の期間（1日、1週間など）におけるリクエスト総数を制限するには、ApigeeのQuotaポリシーを使用します。今回のケースでは、ユーザーのサブスクリプション種別に応じて動的に上限値を切り替える設計が最適です。

実装のメカニズム

APIプロダクトの定義：「ベーシック用プロダクト」と「プレミアム用プロダクト」をApigee上で作成し、それぞれにクォータ上限値を設定します。
ポリシーの適用：プロキシのフローにQuotaポリシーを追加します。
変数の活用：ポリシー内で、APIキーに紐付けられたAPIプロダクトのクォータ設定値を参照するように設定します。

＜Quotaポリシーの設定例＞

<Quota name="CheckSubscriptionQuota">
    <Allow countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.limit"/>
    <Interval ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.interval">1</Interval>
    <TimeUnit ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.timeunit">day</TimeUnit>
    <Identifier ref="client_id"/>
</Quota>

💡 変数の説明
verifyapikey.VerifyAPIKey.apiproduct.developer.quota.limit ：APIプロダクトに設定したクォータ上限値を参照します。

Interval / TimeUnit も同様にAPIプロダクトの設定値を動的に参照することで、プロダクトごとの期間設定に対応できます。

<Identifier ref="client_id"/> ：ユーザー単位でカウントを管理します。

この設定により、同じAPIパスであっても、ベーシック会員は1日1,000回まで、プレミアム会員は1日10,000回までといった柔軟な制御がバックエンドのコード変更なしで実現できます。

3. システムを過負荷から守る（Spike Arrest Policy）

クォータ制限は「ビジネス上の約束（1日◯回まで）」を管理するものですが、それとは別に、短時間の急激なアクセス（スパイク）からGKEを守る必要があります。これにはSpike Arrest（スパイク阻止）ポリシーを使用します。

QuotaとSpike Arrestの違い

	Quota（クォータ）	Spike Arrest
制御の対象	長期的なリクエスト総数（例：1日100回）	短時間の瞬間的なトラフィック（例：30回/秒）
上限到達時の挙動	次の期間までブロック	トラフィックを平滑化して抑制
主な目的	ビジネス上のプラン管理	バックエンドの過負荷防止

ベストプラクティスとしての組み合わせ

ユーザーが「1日1万回」の権利を持っていても、それを1秒間に集中させてシステムを攻撃することは許すべきではありません。Apigeeのフローの最初にSpike Arrestを置き、その後にプラン別のQuotaを置くのが二段構えの鉄板構成です。

4. GKEとの連携：バックエンドの保護

ApigeeからGKEへの通信は、Private Service Connect (PSC) や VPC ピアリング を介してプライベートに行うのが一般的です。

認証の委譲：ApigeeでAPIキーを検証した後は、ApigeeからGKEへ「検証済みユーザー情報（プラン種別など）」をHTTPヘッダーなどで安全に引き渡します。
セキュリティ：GKEへの通信はApigeeからのプライベートトラフィックのみに限定するため、ファイアウォールルールでApigeeのIPレンジ以外からのアクセスを拒否するか、Kubernetes NetworkPolicyでPod間の通信を制御します。なお、Cloud ArmorはGoogle Cloud外部ロードバランサーに適用するサービスであり、Apigee〜GKE間のプライベート通信の制御には使用できません。

Apigeeによるプラン別クォータ制限の実装ガイドのまとめ

Apigeeを活用することで、APIの利用制御をアプリケーションコードから分離し、柔軟かつ安全に管理できます。特に、Quotaポリシーによりプラン別の利用上限を動的に制御できる点は大きな利点です。さらに、Spike Arrestを組み合わせることで、瞬間的な負荷からバックエンドを保護できます。これらを二段構えで適用することが、実運用におけるベストプラクティスです。加えて、GKEとの通信をプライベート化することで、セキュリティも強化されます。結果として、スケーラブルで安全なAPI基盤を実現できます。

Binary AuthorizationによるセキュアなCI/CDパイプライン構築

現代のセキュリティにおける「ゼロトラスト」の考え方は、ネットワークだけでなく、デプロイされる「コード（イメージ）」そのものにも適用されるべきです。たとえ社内のCI/CDパイプラインで作られたイメージであっても、それが本当にテストをパスしたものかどうかを、デプロイの瞬間に厳密に検証する必要があります。

1. 鍵となるコンポーネントの役割

このアーキテクチャを実現するために、以下の4つのサービスが連携します。

Cloud Build：コンテナのビルドから自動テストの実行、そして合格時の「署名」プロセスをオーケストレーションします。
Artifact Analysis：コンテナの脆弱性スキャン結果や、テスト合格の証明である「証跡（Attestation）」をメタデータとして保存します。
Binary Authorization：GKEやCloud Runへのデプロイ時に、「正しい署名があるか」をチェックするゲートキーパー（認可制御）です。
Cloud KMS (Key Management Service)：証跡に署名するための暗号鍵を安全に管理します。

2. セキュアなデプロイパイプラインの全体像

以下のステップで、テスト合格済みイメージのみを許可する環境を構築します。

ステップ1：KMSによる署名鍵の準備

まず、信頼の根源となる非対称署名鍵をCloud KMSで作成します。この鍵は、自動テストに合格した際に「このイメージは安全である」と証明するために使用されます。

ステップ2：認証者（Attestor）の作成

Binary Authorizationにおいて、証跡を検証する「認証者（Attestor）」を定義します。認証者は、Artifact Analysisに保存された証跡と、KMSの公開鍵を紐付ける役割を果たします。

ステップ3：Cloud Buildによる自動テストと署名

ここがパイプラインの心臓部です。Cloud Build構成ファイル（cloudbuild.yaml）に以下のステップを組み込みます。

ビルド：イメージをビルドし、Artifact Registryへプッシュ。
自動テスト：デプロイ前の環境で自動統合テスト・E2Eテストを実行。

⚠️ 用語の注意：CI/CDパイプライン内で自動実行されるテストは「自動統合テスト」や「自動E2Eテスト」と表現するのが正確です。UAT（User Acceptance Testing：ユーザー受け入れテスト）は業務担当者が手動で行う検証プロセスを指すため、「自動UAT」は用語として矛盾します。

証跡の作成（条件付き）：テストが成功した場合のみ、KMSの鍵を使用してイメージのダイジェストに対して署名を行い、その結果を「証跡」としてArtifact Analysisに記録します。

ステップ4：Binary Authorization ポリシーの設定

Binary Authorizationのポリシーを、「すべてのデプロイを拒否する」をデフォルトとし、「特定の認証者（ステップ2で作成したもの）による署名がある場合のみ許可する」というルールに設定します。

3. デプロイ時の挙動：なぜ安全なのか？

GKE・Cloud Runそれぞれのデプロイ操作（GKEの場合は kubectl apply、Cloud Runの場合は gcloud run deploy）が実行されると、Binary Authorizationが割り込みます。

検証：Binary Authorizationは、デプロイされようとしているイメージのダイジェストを特定します。
照合：Artifact Analysisを参照し、そのイメージに紐付いた署名（証跡）を探します。
暗号学的チェック：署名が見つかった場合、KMSの公開鍵を使ってそれが正当なものであるか（改ざんされていないか）を確認します。
判定：署名がない、あるいはテストに落ちて署名が作られなかったイメージの場合、デプロイは即座に拒否されます。

4. この構成を導入するメリット

ヒューマンエラーの排除：テストに落ちたイメージを誤って本番環境のコマンドでデプロイしようとしても、システム側で物理的にブロックされます。
責任の分離：「誰（どのシステム）がテストを承認したか」を暗号レベルで追跡可能です。
コンプライアンスの強化：規制の厳しい業界において、すべての実行イメージが所定のプロセスを通過したことを証明する強力なエビデンスとなります。

Binary AuthorizationによるセキュアなCI/CDパイプライン構築のまとめ

CI/CDパイプラインにおいて「安全なイメージだけを本番にデプロイする」ことは、ゼロトラスト時代の重要な要件です。本記事では、Binary Authorizationを中心に、テスト合格済みイメージのみを許可するセキュアな仕組みを解説します。Cloud Build、Artifact Analysis、Cloud KMSといったサービスを組み合わせ、信頼できるデプロイ基盤を構築します。ヒューマンエラーに依存しない設計により、セキュリティと運用性を両立する方法を整理します。