Cloud Runセキュリティ入門

1. Cloud Runでもセキュリティ運用が必要な理由

Cloud Runでは、基盤となるサーバーやOSの管理をGoogle Cloudが担当します。ただし、フルマネージドサービスであっても、利用者側のセキュリティ運用が不要になるわけではありません。

例えば、意図せずインターネットからアクセスできる状態になっていないか、必要以上に強い権限が付与されていないか、想定していないコンテナイメージがデプロイされていないかを継続的に確認する必要があります。

Cloud Runを安全に運用するためには、どの設定を確認するのか、どのログに操作やアクセスが記録されるのか、問題が発生した場合に誰が対応するのかを整理しておくことが重要です。

図1 Cloud Runセキュリティ運用の全体像

2. Cloud Runで確認したい主な設定

Cloud Runのセキュリティ運用では、ネットワーク上の到達範囲、呼び出し権限、実行時の権限、デプロイ内容、機密情報を中心に点検します。特に公開範囲は、Ingress（どこから到達できるか）とIAM／認証（誰が呼び出せるか）を分けて確認することが重要です。

Ingressと認証（公開範囲）

Cloud RunのIngressには、Internal、Internal and Cloud Load Balancing、Allの3つの設定があります。Ingressは「どこからサービスのエンドポイントへ到達できるか」を制御する設定で、IAMによる呼び出し認証とは別に評価されます。

Cloud Runサービスは、呼び出し時のInvoker IAM checkが既定で有効であるため、認証の観点では非公開が基本です。一方、Ingressの既定値はAllで、ネットワーク上はインターネットからエンドポイントへ到達できます。そのため、「インターネットから到達できるか」と「未認証で呼び出せるか」を同じ意味として扱わないようにします。

一般公開するWebサイトやAPIでは未認証アクセスを許可する場合があります。現在は、公開サービスにする方法としてInvoker IAM checkを無効化する方法が推奨されており、allUsersへCloud Run Invokerロールを付与する方法も利用できます。社内APIなどでは、IngressとIAMの両方を用途に合わせて制限します。外部Application Load Balancer経由に限定したい場合は、Internal and Cloud Load Balancingを利用することで、IAPやCloud Armorなどのロードバランサ機能と組み合わせられます。

図2 Cloud Runの公開範囲はIngressとIAM・認証を分けて確認

IAMポリシー

IAMポリシーでは、Cloud Runサービスを呼び出せる主体だけでなく、設定変更、デプロイ、IAMポリシー変更などの管理操作を行える主体も確認します。必要以上に広い範囲へ権限を付与すると、意図しないユーザーやサービスから操作される可能性があります。

権限を確認する際は、誰に、どのロールが、どの範囲で付与されているかを整理します。一時的な作業のために付与した権限が残っていないか、利用していないアカウントへ権限が付与されていないかも確認します。

実行サービスアカウント

Cloud Runのコンテナは、設定されたサービスアカウントをサービスIDとして利用し、Google Cloud APIへアクセスします。実行サービスアカウントに強い権限が付与されていると、アプリケーションが侵害された場合の影響範囲が大きくなる可能性があります。

サービスアカウントを明示的に指定しない場合は、Compute Engineのデフォルトサービスアカウントが利用されます。Googleは、用途ごとにユーザー管理のサービスアカウントを作成し、必要最小限の権限を付与することを推奨しています。複数のサービスで同じサービスアカウントを使い回さず、影響範囲を分離できる設計も検討します。

機密情報の扱い

APIキー、データベースのパスワード、証明書などの機密情報を、ソースコードや通常の環境変数へ直接保存することは避けます。Cloud RunではSecret Managerを利用し、必要なシークレットだけを実行サービスアカウントから参照できるようにします。シークレットを環境変数として渡す場合は、意図しない値の切り替わりを避けるため、特定のシークレットバージョンへ固定することも検討します。

コンテナイメージとリビジョン

Cloud Runでは、サービスをデプロイした場合や構成を変更した場合に、変更内容を保持する不変（immutable）の新しいリビジョンが作成されます。新しいリビジョンへすべてのトラフィックを送るだけでなく、複数リビジョンへの分割、段階的な移行、以前のリビジョンへのロールバックも可能です。

現在どのリビジョンへトラフィックが割り当てられているか、想定したコンテナイメージが使用されているか、誰がいつ変更したかを確認できる状態にしておきます。より厳格に信頼済みイメージだけをデプロイしたい場合は、Binary Authorizationによるデプロイ時のポリシー適用も選択肢です。

3. Cloud Runで確認できる主なログ

設定だけでなく、管理操作やアクセスの状況をログから確認することも重要です。Cloud Runでは、リクエストログ、コンテナログ、システムログなどがCloud Loggingへ送信されます。これらとCloud Audit Logsを目的に応じて使い分けます。

図3 Cloud Runのログを目的別に使い分ける

リクエストログ

リクエストログはCloud Runサービスへのリクエストに対して自動的に生成されます。リクエストURL、HTTPメソッド、応答ステータス、レイテンシ、送信元IPアドレスなどを手掛かりに、アクセス状況やエラーの増加を調査できます。

ただし、公開サービスへの未認証リクエストでは、リクエストログだけから利用者本人を特定できるとは限りません。認証済みユーザーやアプリケーションの主体まで確認したい場合は、利用している認証方式やアプリケーションログなど、関連情報と組み合わせて調査します。

コンテナログ

コンテナログは、アプリケーションが標準出力や標準エラーなどへ出力したログです。アプリケーションの処理状況、エラー、独自に記録したイベントなどを確認できます。調査で必要な情報を取得できるように、何をどの形式で出力するかを設計します。

ただし、認証情報や個人情報などの機密情報を不用意に出力しないよう注意が必要です。ログへ記録する情報と、記録しない情報を事前に整理します。

システムログ

システムログは、Cloud Runのプラットフォーム側で生成されるワークロード関連のログです。アプリケーションが出力するコンテナログだけでは把握できない、実行環境の状態やプラットフォーム側のイベントを調査する際に利用します。

Cloud Audit Logs

Admin Activity監査ログには、Cloud Runサービスの作成、更新、削除、IAMポリシーの変更など、構成や権限に関する管理操作が記録されます。Admin Activity監査ログは常に有効で、無効化できません。

Data Access監査ログは、構成やデータを読み取るAPI操作などを記録しますが、BigQueryの一部を除き既定では無効です。必要に応じて有効化し、ログ量とコストも考慮します。また、公開されたCloud Runサービスへの未認証リクエストを確認する目的では、Cloud Audit Logsだけに頼らず、リクエストログを中心に確認します。

設定変更を調査する場合は、Cloud Runだけでなく、関連するIAMやサービスアカウントの操作も合わせて確認します。単独の変更だけで判断せず、同じ時間帯に行われた関連操作を追うことが重要です。

4. 注意したい設定変更とイベント

Cloud Runでは、変更が行われたこと自体が直ちに不正を意味するわけではありません。通常の保守作業やリリースでも設定は変更されます。そのため、運用上の影響が大きいイベントを整理し、担当者や作業時間帯、変更申請などの情報と照らし合わせて確認します。

• Ingressが意図せずAllへ変更され、到達範囲が広がった
• 認証が必要なサービスでInvoker IAM checkが無効化された、または意図しない公開設定になった
• 想定していないユーザー、グループ、サービスアカウントへ呼び出し権限が付与された
• 管理権限やデプロイ権限が追加された
• 実行サービスアカウントが変更された、または強い権限が追加された
• Secret Managerの参照権限や参照するシークレットが想定外に変更された
• 想定していないコンテナイメージやリビジョンがデプロイされた
• トラフィックの割り当て先が想定外のリビジョンへ変更された
• 通常とは異なるアクセス元や時間帯からリクエストが発生した
• 認証エラーやサーバーエラーが急増した

これらのイベントを調査する際は、変更を行った主体、操作元、対象サービス、変更前後の設定、関連するIAM操作、変更後のアクセス状況を確認します。

5. 運用を始めるためのチェックポイント

最初からすべてのログや設定を監視しようとすると、点検項目が増えすぎて運用が続かない可能性があります。まずは重要なサービスから対象を絞り、基本的な確認項目を決めます。

• サービスの用途と想定利用者が整理されているか
• Ingressの到達範囲とIAM／認証の設定を分けて確認したか
• 未認証アクセスを許可するかどうかが設計どおりになっているか
• IAMポリシーに不要なプリンシパルや強すぎる権限がないか
• 実行サービスアカウントが用途ごとに分離され、必要最小限の権限になっているか
• APIキーやパスワードなどの機密情報をSecret Managerで管理しているか
• 使用しているコンテナイメージ、リビジョン、トラフィック割り当てを把握できるか
• 必要に応じてBinary Authorizationなどのデプロイ制御を検討したか
• 管理操作をCloud Audit Logsで確認できるか。必要なData Access監査ログを有効化しているか
• リクエストログやコンテナログに調査で必要な情報が記録されているか
• 機密情報がログへ出力されていないか
• 問題発生時の担当者と連絡方法が決まっているか

確認項目を決めた後は、テスト用の設定変更やアクセスを行い、必要なログが記録されるかを検証します。ログの保存期間、閲覧権限、通知方法も合わせて整理しておくと、問題発生時に調査を始めやすくなります。

6. まとめ

Cloud Runはフルマネージドサービスですが、Ingressと認証、IAMポリシー、実行サービスアカウント、機密情報、コンテナイメージ、リビジョンなどは、利用者側で適切に管理する必要があります。特に公開範囲は、「どこから到達できるか」と「誰が呼び出せるか」を分けて確認することが重要です。

あわせて、リクエストログ、コンテナログ、システムログ、Cloud Audit Logsを目的に応じて使い分け、重要な設定変更やアクセスを継続的に確認します。未認証アクセスの調査はリクエストログ、管理操作の追跡はAdmin Activity監査ログというように、調査目的に応じて見るログを整理しておくと効率的です。

まずは重要なCloud Runサービスを一つ選び、Ingress、認証、権限、実行サービスアカウント、デプロイ履歴、ログの記録状況を確認するところから始めると、無理なく運用を整えられます。確認結果をもとに対象や手順を広げ、継続可能な運用につなげます。

次回は、Cloud RunのログをGoogle SecOpsへ取り込み、重要な設定変更の検知、影響範囲の調査、ケース管理、初動対応へつなげる流れを紹介します。

7. 参考情報

• Security design overview
• Restrict network endpoint ingress for Cloud Run
• Authentication overview
• Allowing public (unauthenticated) access
• Cloud Run service identity
• Configure secrets for services
• Manage revisions
• Use Binary Authorization
• Logging and viewing logs in Cloud Run
• Cloud Run audit logging
• Cloud Audit Logs overview