👾

マルチテナントサービスのスプーフィングリスク

2024/06/09に公開

Azure

Security

クラウド

tech

先日、Tenable^[1] からセキュリティリスクに関する報告を受け、Microsoft は一部の Azure サービスのドキュメントを加筆・修正しました。経緯や詳細については、以下の公式ブログで公開されています。

自分も最初は「ああ、Azure の話か」と思っていたものの、読み進めてみると Azure に限らない話であることがわかりました。つまり、マルチテナントサービスを利用する任意のユーザーが警戒しなければならないリスクを説明しているに過ぎませんでした。

本稿では、なるべく Azure 用語を使わずに事象を説明してみるので、より多くの人に当該のリスク知ってもらうキッカケになれば幸いです。

TL;DR

結論を先に置いておきます。

マルチテナントサービスでは、IP アドレスにだけ頼るアクセス制御では不十分な場合がある
ゼロトラストあるいは多層防御の原則に基づいて、アプリレイヤーでも認証・認可を実施する
たとえば、リクエストのヘッダーを使ってクレデンシャルを送信し、サーバー側で検証する

想定シナリオ

マルチテナント型のクラウドサービスで、異なるアプリケーションを実行している複数のテナント (テナント A、B) が存在します。アプリケーションの実行基盤には、トラフィックのアクセス制御 (Access Control; ACL) の機能が備わっています。

また、クラウド内のある特定サービスから、アプリケーションに対してリクエストが発生するような状況です。たとえば、監視サービスからアプリケーションへの死活監視の通信や、サーバレスアーキテクチャのフロントからバックエンドへの連携などを想定してもらうと良いと思います。

そして、この特定サービスはマルチテナントサービスであり、リクエストの送信元として特定のグローバル IP アドレス範囲をランダムに利用する仕様となっています。

上はこれらの想定を図式化したものです。

テナント A の立場からすると、前段の「マルチテナントサービス」に対する構成・操作・リクエストの結果、最終的に「マルチテナントサービス」からテナント A が所有するアプリケーションにリクエストが行くものだと思っています。したがって、ACL の設定として、次のような構成をしました。

リクエストの送信元が「マルチテナントサービス」の IP 範囲であれば許可する
それ以外は拒否する

なにが問題か

上述の設定だけでは、マルチテナントサービスがスプーフィングに使われるリスクが考慮しきれていません。

想定しきれていなかったリクエストが、悪意あるユーザーによって生成されている様子を表したのが上図です。たとえば、攻撃者は次のような準備で攻撃を成功させることが出来ます。

マルチテナントサービスの例	攻撃者の準備
監視サービス	テナント A のアプリケーションを監視対象とする
CDN サービス	テナント A のアプリケーションをオリジンサーバーに設定する
イベントドリブン型のコンピューティングサービス	テナント A のアプリケーションにリクエストを発行するようコーディングする

どのように対処するか

根本原因は、マルチテナントサービスを全面的に信頼してしまっている点です。

リクエストが特定の IP アドレス範囲から来る場合でも、リクエストの内容をチェックしましょう。IP アドレスの境界に基づいたアクセス制御 (境界型セキュリティ) には限界があります。具体的な対処方法はサービスごとに異なるでしょうが、大まかな方針は変わりません。アプリケーションのレイヤーでも認証・認可を実施することです。これは、ゼロトラストや多層防御の考えと同じです。

より具体例がわかるように、Azure での対応例を２つ紹介します。

Azure Front Door

Azure Front Door は、Microsoft が所有するエッジロケーション^[2]のファシリティを使った、CDN サービスです。

Azure Front Door は、リソースごとに一意な値 (Front Door 識別子) が割り当てられており、これをリクエストヘッダー (X-Azure-FDID) としてオリジンサーバー側に伝達します。したがって、オリジンサーバー側ではこの情報を持つリクエストだけを許可することで、配信元のセキュリティを担保することが出来ます。

Azure Monitor (Application Insights)

Azure の監視機能の一つに、Application Insights 可用性テストがあります。これは、Web アプリケーションに対する可用性と応答性を監視するソリューションです。特定のエンドポイントに対して、定期的に HTTP/S のリクエストを発生させ、その応答状況を記録します。

監視の HTTP/S リクエストにユーザー独自のヘッダ/値を含めることができるので、スプーフィングの対策にはこの機能を使います。具体的な手順は、以下のドキュメントに記載があります。

まとめ

本記事では、マルチテナントサービスにおけるアクセス制御の課題とその解決策について解説しました。具体的には、単純にIPアドレスの範囲に基づいたアクセス制御では不十分であり、スプーフィングなどの攻撃に対して脆弱であることを説明しました。

これを防ぐためには、ゼロトラストや多層防御の原則に基づいて、アプリケーションレイヤーでも認証と認可を実施する必要があります。たとえば、Azure Front Doorではリクエストヘッダーを使って識別情報を検証し、Azure Monitorの可用性テストではカスタムヘッダーを利用して正当なリクエストであることを確認する手法を紹介しました。

クラウド環境でセキュリティを確保するためには、複数の対策を組み合わせてリスクを最小化することが重要です。今回紹介した方法を参考に、自社のセキュリティ対策を見直し、強化することを検討してみてください。

参考文献

脚注

脆弱性診断のソリューションを持つサイバーセキュリティの企業 (https://www.tenable.com/) ↩︎
現在 109 の都市に 192 のエッジロケーションがあります。https://learn.microsoft.com/ja-jp/azure/frontdoor/edge-locations-by-region ↩︎