ホーム
お役立ち
Google Service
2021最新機能を搭載した Cloud Run で高次元なセキュリティ対策を実現！

2021最新機能を搭載した Cloud Run で高次元なセキュリティ対策を実現！

Cloud
Cloud Run
セキュリティ対策
最新機能

公開年月日: 2021.07.06

更新年月日: 2024.09.26

2021最新機能を搭載した Cloud Run で高次元なセキュリティ対策を実現！

本記事は、2021年5月26日に開催された Google の公式イベント「 Google Cloud Day : Digital ’21 」において、 Google Cloud アプリケーションモダナイゼーションスペシャリストの頼兼孝幸氏が講演された「最新機能を適用した Secured Cloud Run 2021」のレポート記事となります。

今回は Cloud Run を活用したセキュリティ対策について

認証
VPC 連携
アクセス制限

の3つに大きく分けて、 Cloud Run の最新機能を交えながらご説明します。

なお、本記事内で使用している画像に関しては Google Cloud Day : Digital ’21 「最新機能を適用した Secured Cloud Run 2021」を出典元として参照しております。

それでは、早速内容を見ていきましょう。

Cloud Run とは？

Cloud Run はサーバーレスで提供されているサービスであり、フルマネージドなコンテナの実行環境です。コンテナとは、 OS （オペレーティング・システム）上に「アプリケーション本体」「必要なライブラリ」「設定ファイル」などをひとまとめにしたものです。

本来、コンテナを扱うためには「 Kubernetes （オープンソースのコンテナーオーケストレーションツール）」を学ぶ必要があり、学習するための時間やコストが発生してしまいます。

単純にコンテナを扱うだけであれば Kubernetes がなくても問題ありませんが、オーケストレーション（設定や管理などの自動化）を行うためには Kubernetes の知識が必要不可欠です。

しかし、 Cloud Run を使えば、コンテナイメージを構築して Cloud Run の上に乗せるだけで、 Kubernetes が提供している様々な機能・強みを享受することができます。

Cloud Run は数秒でデプロイが完了するほか、 HTTPS に対応しておりカスタムドメインも利用可能です。また、言語やライブラリに依存せず、クラスタの管理が不要な点も大きなメリットだと言えます。

なお、 Google Cloud (GCP)では Cloud Run を含めた様々なコンピューティングサービスを提供しています。

Cloud Functions
App Engine
Cloud Run
Kubernetes Engine
Compute Engine

最適な選択の方法に関して理解を深めたい方は以下の記事がオススメです。

わかりやすい！自社に合った GCP コンピューティングの選択方法とは？

Cloud Run の特徴

高速に自動スケーリングできる

スケーリングとは、リソース使用量を自由に増減することです。 Cloud Run は外部からのアクセスがない場合はコンテナのインスタンスが 0 になり、外部からアクセスが発生すると、自動的に必要な量までスケールします。このように、 Cloud Run は自社でインスタンスの調整を行う必要がないため、業務効率化に直結します。

誰でも容易にデプロイできる

Cloud Run のデプロイは非常にシンプルであり、一つのコマンドで簡単にデプロイできます。例えば、コンテナイメージのパスを指定し、「 gcloud run deploy 」のコマンドを実行するか、もしくは、ソースが存在するルートのフォルダで「 gcloud beta run deploy 」のコマンドでパスを指定する方法が挙げられます。なお、本記事を執筆した2021年6月現在では、コマンド内に beta を入れる必要があります。

上記のコマンドを利用してデプロイするだけで固有の URL が自動的に発行され、外部からアクセス可能なアプリケーションを公開できます。さらに、アプリケーションの特性に応じて、 CPU やメモリ、オートスケーリングの最大（最小）インスタンス数などを自由に調整できます。

言語やライブラリの制約がない

Cloud Run はコンテナのアプリケーションであるため、言語やライブラリなどの制約はありません。そのため、どのような言語でも Cloud Run のサービス上に乗せて利用できます。また、サーバーレスで提供されるサービスのため、自社でサーバーを管理する必要がなく、生産性の高い業務に集中できます。

ポータビリティが高い

Cloud Run はオープンソースの Knatve な API を利用して構築されています。 Knative とは、 Kubernetes のイベント駆動型プログラミングを実現しやすくするソフトウェアです。

そのため、 Cloud Run で動かしているアプリケーションを利用したい場合でも、 Kubernetes のクラスタにオープンソースの Knative の基盤を作り、そこに対してコンテナのアプリケーションを展開することで、 Cloud Run を利用した場合と同等の開発が可能になります。

Cloud Run のセキュリティ対策（認証）

容易にデプロイできる点は Cloud Run の大きなメリットですが、誰でもアクセスできることはセキュリティリスクにも繋がります。そのため、 Cloud Run は安全にサービスを利用するための認証機能が搭載されています。

以下、代表的なものをご紹介します。

サービス間通信の認証

Cloud Run では、サービス間通信の認証を必須化する機能が存在します。認証を必須化することで、 Cloud Run サービスにアクセスする際、 authorization ヘッダ（リクエストヘッダ）が必須になるため、このヘッダを付与していないユーザーが Cloud Run のエンドポイントにアクセスしようとすると「403 HTTP エラー」を返します。

次に、「呼び出し側で実際にアクセスするクライアント」について、 Cloud Run のサービスが2つあり「フロントエンド」と「バックエンド」という構成になっているケースでご説明します。

この場合、フロントエンドにある Cloud Run は認証を必須とせずに、バックエンドの Cloud Run を実行するサービスアカウントに対して、「 Cloud Run Invoker 」というロールを付与します。これにより、フロントエンドの Cloud Run サービスがバックエンドの Cloud Run サービスに対してアクセスできる権限を持ち、ヘッダに ID トークンを含めてサービス間通信を行います。

サービス間認証

Google Cloud （ GCP ）間の認証

Google Cloud （ GCP ）間において、 Cloud Run を非同期で実行する場合は、 Cloud Tasks 、 Pub / Sub 、 Cloud Scheduler などの他サービスから Cloud Run を呼び出す形になります。

その場合でも、それぞれのサービスアカウントに対して Cloud Run Invoker のロールを付与することで Cloud Run の認証をクリアできるようになります。

GCPプロダクト間の認証

エンドユーザーの認証

エンドユーザーの認証には「 Identity Platform 」を利用します。 Identity Platform を使ってユーザーにログインを求めることで、ログイン時にトークンが発行されます。

このトークンをクライアントからリクエストヘッダに付与してリクエストを行うことで、 Identity Platform を経由したユーザー認証が可能になります。

エンドユーザーの認証

Cloud Run のセキュリティ対策（ VPC 連携）

VPC とは「 Virtual Private Cloud 」の略であり、特定のユーザーしかアクセスできない専用のクラウド環境を意味する言葉です。

Cloud Run は特定の VPC に展開されるわけではないため、アクセス先のファイアウォール設定によってはアクセスができないケースが存在します。また、 Cloud Run から Google Cloud （ GCP ）外のオンプレミスシステムにアクセスを試みた際、 IP が固定されていないために IP 制限で拒絶されてしまう可能性もあります。

本章では、このような課題を解決するための Cloud Run の VPC 連携についてご説明します。

VPC 内のリソースへの接続

VPC 内のリソースへ Cloud Run を接続する場合は、「サーバーレス VPC アクセス」を使用します。サーバーレス VPC アクセス経由で接続することで、 VPC の中にあるリソースにアクセス可能になります。また最近では、 VPC に加えて Shared VPC への接続も実現できるようになりました。

VPC内のリソースへの接続

Cloud Run 発の通信の IP アドレスを固定する

Cloud Run 発の通信の IP アドレス固定は、サーバーレス VPC アクセスと Cloud NAT との連携で実現可能です。 Cloud Run 発のすべての通信をサーバーレス VPC アクセスに向けた上で、 Cloud NAT で Cloud Run の egress （通信の出口）をすべてプロキシすることで、全通信の IP アドレスを固定できます。

これにより、 Cloud Run 発の通信の IP アドレスを固定化でき、通信先のファイアウォールでアクセスを制御することが可能になります。

Croud Run 発の通信の IP アドレス固定

Cloud Run のセキュリティ対策（アクセス制限）

Cloud Run はオープンな URL が発行されるため、外部からサイバー攻撃を仕掛けられるリスクがありますが、 Cloud Run 単体では VPC 内にサービスを構築したり、ファイアウォールによる制御を行う機能は搭載されていません。

では、どのようにアクセス制限を実現するのでしょうか。本章では、 Cloud Run への外部からのアクセスを制限する方法をご紹介します。

外部からのトラフィック制御

外部からのトラフィック制御は、ネットワークエンドポイントグループ（ NEG ）と Google Cloud ロードバランサ（ GCLB ）の連携で実現します。

一つの Cloud Run に対して一つの NEG を登録し、その NEG を GCLB のバックエンドサービスと連携させることで、バックエンドサービスに複数の NEG を設定できます。これにより、リージョンごとに Cloud Run サービスを稼働させ、 GCLB の機能でエンドユーザーに最も近いリージョンの Cloud Run に対してリクエストをルーティングできます。

このように、 GCLB を前段に置くことで、外部からのトラフィック制御を柔軟に行うことができます。

また、2021年5月に Identity-Aware Proxy の機能も Cloud Run をサポートするというリリースがありました。まだプレビューの機能にはなりますが、このアップデートによって認証だけでなく認可を行うことができるようになり、特定ユーザーのアクセス制御も可能になりました。

ロードバランサ連携

DDoS 対策

GCLB を利用することで、 Cloud Run と Cloud Armor が連携できるようになります。 Cloud Armor は特定の IP アドレスに対するフィルタリングはもちろんのこと、地理情報をベースとしたフィルタリングを行うことも可能です。

そのため、 Cloud Armor の機能を利用することで、特定の国や地域からのアクセスを制限するなど、セキュリティを高めるための柔軟な運用を実現することができます。

DDoS対策

Cloud Run に対するダイレクトリクエストの制御

Cloud Run に対してダイレクトに届くリクエストを制御する場合は、「 --ingress internal-and-cloud-load-balancing」という Cloud Run のデプロイオプションを利用します。このオプションを使えば、 GCLB 経由でのみリクエストを受け付けることが可能になります。

このように、オプションを活用することで、 Cloud Run へのアクセスを GCLB または内部 VPC 経由のみに制限することができます。こちらは最近実装された新しい機能になっています。

ダイレクトリクエストの制御

VPC 内のリクエストのみに限定する制御

GCLB 経由でのリクエストも許可せず、 VPC 内のリクエストのみに限定したい場合は「 --ingress internal 」というデプロイオプションを利用します。

これにより、同一プロジェクトの VPC からのみリクエストを受け付けることが可能になり、さらに強力なアクセス制御を実現できます。この機能も最近実装された最新のものです。

VPCリクエスト制御

細かいセキュリティ設定

プロダクトレベルでの制御など、細かいセキュリティ設定を行いたい場合は、「 VPC Service Controls 」を利用します。 VPC Service Controls でサービス境界を細かく定義することで、自由度の高い Cloud Run 通信の制御や保護を実現できます。

ただし、 VPC Service Controls を適用するためには、組織閲覧者と Access Context Manager の編集者ロールが必要になる点は注意が必要です。

細かいセキュリティ設定

Cloud Run に関する質問

Q . Cloud Run と GKE を比較すると、よりセキュアなのはどちらですか？

A . GKE は特定の VPC へ展開できる点や Kubernetes のレイヤーで細かい制御ができるといった観点から、 GKE の方がより柔軟に制御することが可能かと思います。ロードバランサーのレイヤーにおける制御や、認証などは本セッションにある通り Cloud Run でも実現でき、用途によって基盤を選択すると良いと思います。

Q . Cloud Functions と Cloud Run の使い分けはどう考えればいいですか？

A . Cloud Run は対応言語やバージョンの縛りが無いといったメリットや、同時接続が複数できるというメリットがあります。一方、 Cloud Functions の方が各サービスとのイベントドリブンな連携が多いため、そういった用途では Cloud Functions の方が向いているケースがあるかと思います。