0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

GCP触って1ヶ月で感じたこと

GCP(Google Cloud)を使ったプロジェクトに参画して、約1ヶ月が経ちました。
これまでAWSをメインで触ってきた身として、GCPのアーキテクチャやセキュリティに対する「思想の違い」に驚かされることが多々ありました。

今回は、特にCloud RunやVertex AIといったマネージドサービスを触る中で感じた**「GCPのセキュリティとネットワークの考え方」**について、AWSとの比較を交えながら整理してみます。

1. ネットワーク(VPC)で守るAWS、アイデンティティ(IAM)で守るGCP

一番のカルチャーショックはこれでした。

AWSでセキュアな環境を作る場合、まずは「VPCを切り、サブネットを分け、セキュリティグループ(SG)でインバウンドのポートとIPを絞る」というネットワーク境界での防御が基本中の基本です。

一方、GCPのマネージドサービス(特にCloud RunやVertex AI)では、そもそもユーザー側で細かいネットワークのインバウンド設定(セキュリティグループ的なもの)を書く機会がガクッと減ります。代わりに登場するのが**IAM(Identity and Access Management)**です。

GCPは「どこから来たか(ネットワーク)」よりも、**「誰がアクセスしているか(アイデンティティ)」**で弾くアプローチを強く取っています。

比較ポイント AWS (例: Amazon SageMaker / ECS) GCP (例: Vertex AI / Cloud Run)
防御の主軸 ネットワーク(VPC, SGによる物理的な隔離) アイデンティティ(IAMによる権限の隔離)
インバウンド制御 IPアドレスや特定のVPCからの通信を許可する 許可されたサービスアカウントからの呼び出しのみ許可する
デフォルトの環境 ユーザー管理のVPC内に配置して制御する Google管理の隔離されたVPC内で稼働する

2. セキュリティグループの定義がいらない?

今回、機械学習モデルの推論基盤(Vertex AI Endpoint → 今後Cloud Runへ移行予定)の構成を見ていて、ふと疑問に思いました。

「コンテナは80番ポート(HTTP)で待ち受けてるけど、これインバウンドの通信制限どうなってるの?」

AWSの感覚だと、SGで「特定のVPCからのみ80番を許可する」といった設定を入れたくなります。しかし、GCPの回答はこうでした。

  • コンテナ自体はインターネットから隔離されたGoogle管理の内部ネットワークにいる。
  • 入り口のAPIゲートウェイが、IAM権限を持たないリクエストをすべて強制ブロックする。
  • つまり、IAMの権限チェック(run.invoker など)が実質的なインバウンド定義として機能している。

GCPのこの「インフラの手前で強力なIAMの壁を作り、背後のコンテナはシンプルにHTTPで受けるだけ」という割り切った設計は、開発者体験(DX)としては非常に優れていると感じました。アプリ側に複雑な認証ロジックを書かなくても、強固なセキュリティが担保されるからです。

3. とはいえ「ゼロトラスト」を目指すなら

GCPのマネージドな境界防御は非常に強力ですが、「GCPの内部ネットワークまで到達した通信はすべて安全である」と信じ込んでしまう(盲信する)側面もあります。

近年話題の**ゼロトラスト(すべての通信を疑い、常に検証する)**の観点に立つと、「コンテナに到達した時点での通信経路自体の認証」が不足していることに気づきました。

もし今後、さらに高いセキュリティ水準(ゼロトラストアーキテクチャ)を目指すのであれば、インフラに任せきりにするのではなく、以下の対応が必要になります。

  1. アプリケーション層での OIDC トークン検証:
    GCPの入り口を突破してきたリクエストであっても、FastAPIなどのアプリケーション側で毎回「OIDC(OpenID Connect)トークン」をデコードし、Googleの署名や送信元が正しいかを検証する。
  2. 実行サービスアカウントの最小権限(Least Privilege):
    コンテナを動かすサービスアカウントに広範な権限を与えず、「特定のBigQueryのビューのSELECTのみ」といった極小の権限に絞る。
  3. VPC Service Controls による境界保護:
    万が一内部に侵入されても、外部へのデータ持ち出しをネットワークレベルで遮断する。

インフラ(IAM)による防壁と、アプリ(OIDC検証)による防壁。この二段構えにして初めて、真のゼロトラストに近づけるのだと学びました。

まとめ

GCPを1ヶ月触ってみて、**「AWSはネットワークの線を引く文化、GCPは身分証明書(IAM)で縛る文化」**という違いが肌感覚として分かってきました。

GCPの思想に乗っかれば、ネットワーク設計の複雑さをGoogle側にオフロードし、開発者はアプリケーションのロジックに集中できます。一方で、その裏側で「どうやって守られているのか」を正しく理解しておかないと、ゼロトラストのような次のステップに進む際に足元をすくわれるかもしれません。

まだまだGCP初心者ですが、この思想の違いを楽しみながら、よりクラウドネイティブな設計を学んでいきたいと思います。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?