【ITニュース解説】Stealing from Google

この解説は、Google Cloudの環境で稼働するアプリケーションから、重要な情報がどのようにして不正に取得される可能性があるか、そしてそれを防ぐための方法について、システムエンジニアを目指す初心者に理解できるよう説明する。中心となるのは、悪意のある攻撃者がウェブアプリケーションの脆弱性を利用し、システム内部の機密情報にアクセスする手口である。

まず、Google CloudとCloud Runの基本的な概念から説明する。Google Cloudとは、Googleが提供するクラウドコンピューティングサービス群の総称だ。サーバやストレージ、データベース、機械学習など、ITインフラや開発に必要な多くのサービスをインターネット経由で利用できる。Cloud Runは、Google Cloudのサービスの一つで、開発者が作成したアプリケーションを「コンテナ」という形式でデプロイし、サーバの管理をほとんど意識することなく実行できる。コンテナとは、アプリケーションとその実行に必要なすべての要素（コード、ライブラリ、設定など）を一つにまとめた軽量で独立した実行環境のことである。Cloud Runはアプリケーションへのアクセスが増えると自動的に必要なリソースを増やし、アクセスが減ると自動的に減らすため、「サーバレス」なサービスとも呼ばれる。

アプリケーションがGoogle Cloud上の他のサービス（例えば、データを保存するストレージやデータベースなど）と連携する場合、そのアプリケーションには「誰であるか」「何ができるか」を証明する手段が必要となる。これが「サービスアカウント」と「認証情報」だ。サービスアカウントは、人間ではなくプログラムやアプリケーションがGoogle Cloudのリソースにアクセスするために使用する特別なアカウントである。このサービスアカウントには、特定の操作を行うための権限が与えられる。アプリケーションは、このサービスアカウントの「アクセストークン」や「IDトークン」と呼ばれる認証情報を使って、Google CloudのAPI（アプリケーションプログラミングインターフェース）を呼び出し、リソースにアクセスする。アクセストークンは、一時的に許可された操作を行うための「許可証」のようなもので、有効期限が短い場合が多い。IDトークンは、そのサービスアカウント（またはユーザー）の身元を証明するもので、認証と認可の両方に使われる。これらのトークンが、今回の攻撃の主な標的となる。

システム内部には、「メタデータサーバ」という特別な情報源が存在する。これは、Google Cloud上で動作する各インスタンス（例えばCloud Runで実行されるコンテナや仮想マシン）が、自分自身の情報や、紐付けられているサービスアカウントに関する情報を取得するために利用する内部のウェブサーバだ。このメタデータサーバには、インスタンスのID、IPアドレス、そして最も重要なサービスアカウントの認証情報などが格納されている。このサーバは、インスタンス内部からのみアクセス可能で、通常、外部からは直接到達できないようになっている。しかし、ある特定の脆弱性を悪用することで、この内部情報源に攻撃者がアクセスできてしまう場合がある。

その特定の脆弱性の一つが、「SSRF（Server-Side Request Forgery）」、日本語では「サーバサイドリクエストフォージェリ」と呼ばれるものだ。これは、ウェブアプリケーションがユーザーから指定されたURLに基づいて、サーバ側から外部（または内部）のリソースにリクエストを送信する機能を持つ場合に発生する可能性がある脆弱性である。例えば、ウェブサイトがユーザーから提供されたURLの画像を読み込んで表示する機能があるとする。この機能の実装が不適切だと、攻撃者は外部の画像URLではなく、システム内部の特別なアドレス（例えば、先に述べたメタデータサーバのアドレス）を送り込むことが可能になる。すると、ウェブアプリケーションは攻撃者が意図した内部アドレスに対してリクエストを送信してしまい、本来アクセスされるべきではない内部情報が外部に漏洩する可能性があるのだ。

Google Cloud環境におけるSSRF攻撃では、このメタデータサーバが狙われる。攻撃者は、脆弱性を持つウェブアプリケーションに対して、内部のメタデータサーバのアドレスである「http://metadata.google.com/computeMetadata/v1/」または特定のIPアドレス「http://169.254.169.254/」へのリクエストを強制する。さらに、メタデータサーバへのアクセスには、「Metadata-Flavor: Google」という特別なHTTPヘッダーを含める必要がある。もしアプリケーションがユーザー入力に十分な検証を行わず、この内部アドレスへのリクエストを許可し、かつ必要なヘッダーを付与してしまうと、メタデータサーバからサービスアカウントのアクセストークンやIDトークンが取得されてしまう。これは、まさに「許可証」や「身分証明書」が攻撃者の手に渡ることを意味する。

これらの認証情報が攻撃者の手に渡ると、そのサービスアカウントが持つ権限の範囲内で、Google Cloud上の様々なリソースが不正に操作される危険性がある。例えば、もしサービスアカウントがCloud Storageのデータにアクセスする権限を持っていれば、攻撃者はその権限を使って企業の機密データを読み取ったり、改ざんしたり、あるいは削除したりできる。さらに、仮想マシンを起動したり、ネットワーク設定を変更したり、データベースにアクセスしたりするなど、そのサービスアカウントが持つあらゆる権限を悪用されてしまう可能性がある。これは、単なる情報漏洩にとどまらず、サービス停止や経済的損失に直結する非常に深刻な事態を引き起こしかねない。

このような脅威からシステムを守るためには、複数のセキュリティ対策を講じることが不可欠だ。最も重要な対策の一つが「最小権限の原則」である。これは、サービスアカウントには、そのアプリケーションが必要とする機能のために、必要最小限の権限のみを付与するという原則だ。例えば、ストレージへの書き込みが不要なアプリケーションには、読み取り権限のみを付与するといった具体的な対応が求められる。これにより、万が一認証情報が漏洩したとしても、攻撃者が悪用できる範囲を限定できる。

次に、SSRF攻撃を直接防ぐための対策がある。これは、ウェブアプリケーションが外部から指定されたURLを処理する際に、そのURLが正規のものであるか、内部のリソースを指していないかを厳格に検証することである。特に、メタデータサーバのIPアドレスである「169.254.169.254」や内部ドメインへのアクセスは明確に禁止するべきだ。また、Cloud Runのようなマネージドサービスでは、細かなファイアウォールルールを設定することが難しい場合もあるが、可能な限り不要な通信は制限することが望ましい。さらに、Web Application Firewall (WAF) を導入することで、SSRFのような既知の攻撃パターンを検知し、ブロックする対策も有効だ。

最後に、認証情報の管理についても言及する。アクセストークンは比較的有効期限が短く、自動的にローテーションされることが多いが、IDトークンは有効期限が比較的長い場合があるため、その管理には特に注意が必要である。定期的な監査やセキュリティ診断を実施し、アプリケーションの脆弱性を早期に発見し修正する継続的な取り組みも欠かせない。

システムエンジニアを目指す上で、このようなセキュリティの脅威とその対策について深く理解することは非常に重要である。技術の進化とともに攻撃手法も巧妙化していくため、常に最新の情報を学び、セキュアなシステム設計と実装を心がけることが、信頼性の高いサービスを提供するための基盤となる。