本記事のサマリ
Cloud Runのゼロトラストセキュリティを触ってみて、正直「え、こんなに簡単なの？」と衝撃を受けました。長年AWSでVPCやセキュリティグループと格闘してきた私にとって、--iapフラグ一つで強固なセキュリティが実現できるGoogle Cloud（旧GCP）のアプローチは、まさに「セキュリティの考え方が根本から違う」という感覚でした。この記事では、AWSの伝統的なネットワーク境界ベースのセキュリティと、Google Cloudが提唱するBeyondCorpによるアイデンティティベースのアプローチを比較しながら、なぜこんなにも違いが生まれるのかを解説していきます。
AWSユーザーだった私がGoogle Cloudに触れて感じた違和感
今までAWSで、EC2インスタンスをプライベートサブネットに配置して、ALBで負荷分散して、セキュリティグループで細かくポート制御して...という感じの、いわゆる「AWSらしい」インフラ構築に慣れ親しんできました。
そんな中、最近Cloud Runを触り始めたんですよね。なんと、--iap（Identity-Aware Proxy）フラグを一つ付けるだけで、VPN不要かつ強固なアクセス制御が実現できてしまうと！
gcloud beta run deploy my-service \
--region=asia-northeast1 \
--image=gcr.io/my-project/my-app \
--no-allow-unauthenticated \
--iap
正直少し戸惑いました。「セキュリティグループは？VPCの設定は？ルートテーブルは？」。AWSだったら最低でも30分はかかる設定が、フラグ一つで終わってしまうんですね。
でも使ってみて分かったのは、これって単に「設定が楽になった」っていう表面的な話じゃないんですよね。Google Cloudが長年培ってきた「ゼロトラスト」という、セキュリティに対する根本的な考え方の違いがありました。
ゼロトラストとBeyondCorpの思想：「誰も信用しない」という発想
そもそもゼロトラストって何なのか。Google Cloudの公式ドキュメントを見ると、こう書いてあります。
「no person or device should be trusted by default（誰も、どのデバイスもデフォルトで信頼すべきではない）」
これ、最初読んだ時は「厳しすぎない？」と思ったんですが、よく考えると理にかなってるんですよね。
従来のセキュリティモデルって、「城壁モデル」って呼ばれてて。ネットワークの境界をガチガチに固めて、「内側にいる人は信頼できる」という前提で動いてたんです。でもこれはこれで、致命的な問題があって。一度内部ネットワークに侵入されちゃうと、攻撃者は比較的自由に横方向へ移動（ラテラルムーブメント）ができてしまうんですね！？
そこで、Googleが提唱するBeyondCorpは、この問題を解決するためにゼロトラストアーキテクチャを実装したと。基本原則がこれです：
「Access to services must not be determined by the network from which you connect（サービスへのアクセスは、接続元のネットワークによって決定されるべきではない）」
これ言われてみればそうだなーですよね。「社内ネットワークからアクセスしてるから安全」という考えを完全に捨てるんですね。代わりに、どこからアクセスしようと、毎回ユーザーとデバイスの認証・認可を行って、必要最小限のアクセスのみを許可する。
VPNで社内ネットワークに繋げば後は自由、みたいな世界とは真逆の発想ですよね。
AWSとGoogle Cloudのセキュリティモデルの根本的な違い
さて、ここからが本題です。AWSとGoogle Cloudのセキュリティアプローチは、表面的な違いじゃなく、設計思想レベルで全然違うようです！
AWSのネットワーク境界ベースのアプローチ：「壁を作る」発想
AWSのセキュリティは、責任共有モデルの上に築かれてるんです。AWSが物理インフラを担当して、ユーザーがその上のセキュリティ設定を行うという分担です。AWSを学習し始めると、そんな図を必ず見るかと思います。
具体的には、VPC（Virtual Private Cloud）でネットワークを論理的に分離して、セキュリティグループでインスタンスレベルのファイアウォール制御を行います。セキュリティグループは、「どのIPアドレスから、どのポートへのアクセスを許可するか」を細かく制御する仮想ファイアウォール。
例えばWebアプリケーションを安全に公開しようと思ったら、こんな感じの設定が必要になります：
- パブリックサブネットにALBを配置
- プライベートサブネットにEC2インスタンスを配置
- ALBからEC2への通信のみを許可するセキュリティグループを設定
- EC2からRDSへの通信のみを許可する別のセキュリティグループを設定
- 管理者アクセス用の踏み台サーバーまたはVPN接続の設定
これ、確実ですけど、複雑なんですよね… しかも、「内部ネットワークにいるから安全」という前提に立ってるので、内部からの脅威には弱いんです。踏み台サーバーの認証情報が漏れたら、もうアウト。
Google Cloudのアイデンティティベースのアプローチ：「人を見る」発想
一方、Google CloudのBeyondCorpアプローチは全然違います。ネットワークの場所じゃなくて、アイデンティティに基づいてアクセス制御します。その中核を担ってるのがIdentity-Aware Proxy（IAP）。
IAPが何をするかっていうと、アプリケーションへのすべてのリクエストを一度受け取って、ユーザーの認証状態、デバイスの状況、アクセスポリシーなんかを総合的に判断してアクセスを許可または拒否するんです。つまり、どこからアクセスしようが、毎回きちんと認証・認可を行うわけです。
この違い、AWSは「信頼できるネットワーク」を作ることに重点を置いてて、Google Cloudは「信頼できるアイデンティティ」を検証することに重点を置いてる。アプローチが真逆なんです。
具体的なケースで比較してみる
ここで、実際の開発でよくあるシナリオを3つ取り上げて、AWSとGoogle Cloudでどう実装するのか比較してみます。この違いが、めちゃくちゃ分かりやすいんですよ。
ケース1：開発PCからプライベートなデータベースにアクセスしたい
AWSの場合：踏み台サーバー方式
AWSでプライベートサブネットのRDSにアクセスしようと思ったら、こんな感じになります：
- パブリックサブネットにEC2踏み台サーバー（Bastion Host）を配置
- 踏み台サーバーのセキュリティグループで、開発者のIPアドレスからSSH（ポート22）を許可
- RDSのセキュリティグループで、踏み台サーバーのセキュリティグループからの接続のみ許可
- 開発者はSSHトンネリングでRDSに接続
これ、踏み台サーバーの管理が必要ですし、複数の開発者がいるとSSHキーの管理も大変なんですよね。
Google Cloudの場合：Cloud SQL Auth Proxy
一方、Google Cloudだとこうなります：
# ローカルPCでCloud SQL Auth Proxyを実行
cloud-sql-proxy --private-ip PROJECT:REGION:INSTANCE
これだけだそうです！Cloud SQL Auth Proxyをローカルで実行して、IAM認証で接続します。サービスアカウントに Cloud SQL Clientロールを付与するだけで、VPN不要、踏み台サーバー不要で安全に接続できちゃう。開発者個人のGoogle認証情報を使えるので、アクセス管理もIAMで一元化できるんです。
ケース2：コンテナアプリからデータベースに接続したい
AWSの場合：二重のアクセス制御
FargateからRDSに接続する場合、実は2つのアプローチがあります：
-
セキュリティグループのみ（従来型）
- Fargateタスクにセキュリティグループを割り当て
- RDSのセキュリティグループで、Fargateのセキュリティグループからの接続（ポート3306など）を許可
- データベース認証はユーザー名/パスワード
-
IAM Database Authentication（推奨）
- FargateタスクにIAMロールを割り当て
- RDSでIAM認証を有効化
- IAMで認証トークンを生成（15分有効）
- ただし、セキュリティグループの設定も依然として必要
重要なのは、AWSではIAM認証を使ってもネットワーク層のセキュリティグループ設定は必須という点です。つまり、「どこから（ネットワーク）」と「誰が（IAM）」の二重チェックが必要になります。
Google Cloudの場合：構成により異なる
Cloud Runの場合：
gcloud run deploy my-app \
--add-cloudsql-instances=PROJECT:REGION:INSTANCE
Cloud Runにサービスアカウントをアタッチして、サービスアカウントに Cloud SQL Clientロールを付与します。
ただし、ネットワーク設定も構成により必要です：
- Public IP接続の場合: 承認済みネットワーク（Authorized Networks）でIPレンジを設定する必要がある
- Private IP接続の場合: VPCコネクタまたはDirect VPC egressの設定が必要
何が違うのか
- AWS: ネットワーク層のアクセス制御（セキュリティグループ）が必須。IAM認証は追加のセキュリティレイヤー
- Google Cloud: IAM認証が中心だが、Public IP/Private IPの選択によりネットワーク設定も必要
両クラウドとも「誰が（IAM）」と「どこから（ネットワーク）」の組み合わせでセキュリティを担保します。Google Cloudの方が若干設定項目が少ないですが、ネットワーク設定がゼロになるわけではありません。
ケース3：マイクロサービス間の通信を制御したい
AWSの場合：複数の選択肢がある
APIサーバーへのアクセスをフロントエンドサーバーからのみ許可したい場合、いくつかの方法があります：
-
セキュリティグループのみ（従来型）
- ALBのセキュリティグループで、フロントエンドのセキュリティグループからのみ接続を許可
- VPC内部でのみ通信を許可する設定
-
API Gateway + IAM認証
- API GatewayでIAM認証を有効化
- 呼び出し側（Fargate等）のIAMロールに、API実行権限を付与
- 呼び出し側はSigV4署名でリクエストを送信
- ただし、ネットワークアクセス制御（VPCエンドポイント、セキュリティグループ等）も併用されることが多い
AWSでもIAMベースの認証は可能ですが、実運用ではネットワーク層の制御と組み合わせるパターンが一般的です。
Google Cloudの場合：IAMが中心
Cloud Runでは、IAMで制御します：
# 受信側API（backend-api）に、呼び出し側（frontend）のサービスアカウントを追加
gcloud run services add-iam-policy-binding backend-api \
--member='serviceAccount:frontend@PROJECT.iam.gserviceaccount.com' \
--role='roles/run.invoker'
フロントエンド側は、自動的にID tokenを取得してAuthorizationヘッダーに含めます。
何が違うのか
両クラウドともIAMベースの認証は可能です。違いは：
- AWS: IAM認証とネットワーク層の制御を併用するのが一般的
- Google Cloud: Cloud Runの場合、IAM認証のみで完結することが多い（ただしIngressの設定でネットワーク制御も可能）
どちらもアイデンティティベースの認証をサポートしていますが、AWSの方が従来のネットワークベースの設計との併用を前提としている傾向があります。
まとめ：セキュリティの考え方が変わった
Cloud RunでIAPを触ってみて、正直「AWSとGoogle Cloudって、こんなに考え方が違うのか」と実感しました。
AWSのアプローチは、確実で細かい制御ができる。ネットワーク管理者にとっては馴染みやすいし、オンプレミスからの移行もスムーズ。でも、設定が複雑になりがちで、ゼロトラストを実現しようと思うと結構大変。
一方、Google CloudのBeyondCorpアプローチは、シンプルな設定で強固なゼロトラストセキュリティを実現できる。でも、従来の「内部ネットワークは安全」っていう概念から頭を切り替える必要がある。
どっちが優れてるかという話じゃないのですが、組織の要件や既存システムとの親和性を考えて選択するのが大事ですね！
ただ、個人的には、Google Cloudのゼロトラスト思想とその実装の簡便さには、めちゃくちゃ魅力を感じてます！是非積極的にGoogle Cloudを使っていこうと思います！
株式会社StellarCreate（stellar-create.co.jp）のエンジニアブログです。 プロダクト指向のフルスタックエンジニアを目指す方募集中です！ カジュアル面談で気軽に雑談しましょう！→ recruit.stellar-create.co.jp/
Discussion