Google Cloud Storage静的ホスティングでは足りない認証・期限管理をどう補うか

できること

GCSの静的ホスティング自体はHTTPSで高速にファイルを配信でき、Cloud CDNと組み合わせると世界中から安定して開けるページを低コストで維持できます。コンテンツを定期的に更新しながら同じURLを維持したい場合は、`gsutil rsync`コマンドでローカルのビルドディレクトリとバケットを同期する運用が効率的です。

Cloud Storageの均一バケットレベルアクセスを使うと、オブジェクト単位ではなくバケット単位でIAMポリシーを一元管理できます。社内ユーザーのGoogleアカウントグループに対してReader権限を与えることで、「特定のGoogleアカウントグループだけが閲覧できる」という制限は実現できます。

• 相手がログインなしで開ける状態か確認する
• PCとスマホで最低1回ずつ表示を確認する
• 内部情報・個人情報・不要な外部送信が残っていないか見る
• レビュー期限と修正時の差し替え方を決めておく

できないこと

Googleアカウントを持たない社外の人を特定して認証することがGCS単体ではできません。IAM条件式でIP範囲を制限することはできますが、固定IPを持たないリモートワーカーやクライアントには使えません。「このメールアドレスだけに見せたい」という要件はGCSの守備範囲外です。

公開期限の自動管理も弱点です。Object Lifecycleルールでオブジェクトを削除することは可能ですが、削除後はファイルが消えるだけで「期限切れのお知らせページ」を表示したり、アクセス者に期限切れを通知したりする仕組みは自前で構築しなければなりません。

認証と期限の違い

GCSに認証を追加する主な方法はCloud Identity-Aware Proxy（IAP）の利用です。IAPを使うとGoogleアカウントでの認証を要求するゲートを設けられますが、Load BalancerとBackend Bucketの設定が必要で、月額で数百〜数千円のコストが追加されます。また依然としてGoogleアカウントを持つユーザーしか認証できません。

ギガサイト便のような専用サービスはパスワード・メール認証・会社ドメイン認証を発行フォームで選択するだけで設定でき、インフラ構築が不要です。「認証が必要なレビューURLを月に数件発行する」程度の用途では、IAPを構築するよりも専用サービスを使う方が総コストが低くなるケースがほとんどです。

• 誰でも見てよい: URL共有のみでもよいが、検索除外は確認する
• 特定の相手だけ: パスワードまたはメール認証を使う
• 会社内だけ: 会社ドメイン認証を検討する
• 短期レビュー: 期限を設定して古いURLを残さない

差し替え・レビュー運用

GCSで認証なしで運用する場合でも、最低限の対策として「URLを推測されにくくする」方法があります。バケット名とパスに長いランダム文字列を含めることで、総当たりでURLを発見されるリスクを下げられます。ただしこれはセキュリティ対策ではなく「不便にする」だけなので、機密コンテンツには推奨しません。

差し替え頻度が高いレビュープロセスでは、CI/CDパイプライン（GitHub ActionsなどでGCSにデプロイ）を構築すると毎回手動アップロードする手間が省けます。ただしパイプライン構築にも初期コストがかかるため、月数件の単発レビューには過剰投資になりがちです。

• 確認してほしい観点を3つ以内に絞る
• 期限と返信先を明記する
• 修正後も同じURLで見られるか伝える
• 最終版と途中版が混ざらないようタイトルを付ける

向いているケース早見表

認証・期限の補完策として現実的な選択肢をまとめると、「社内のGoogleワークスペースユーザーだけに制限する」→ IAPが有効、「Googleアカウントのない社外ユーザーを認証したい」→ ギガサイト便等の専用サービス、「期限後に自動で非公開にしたい」→ 専用サービスかObject Lifecycle＋CloudFunctions、という整理になります。

複数の要件を同時に満たす必要がある場合、GCSに機能を追加するほどインフラが複雑になり保守コストが増えます。「レビュー専用URL」という用途に絞るなら、最初から専用サービスを使いGCSはプロダクション配信に特化させる役割分担が合理的です。