本ブログは Scaling Dynamic Application Security Testing (DAST) の抄訳版です。最新の情報は原文を参照してください。
はじめに
マイクロソフトのエンジニアリングチームは、セキュリティ開発ライフサイクルを使用してマイクロソフトの Secure Future Initiative (セキュリティ原則 : Secure by Design、Secure by Default、Secure Operations) に則り製品を開発しています。
セキュリティ開発ライフサイクルの重要な要素のひとつは、敵対者がセキュリティの脆弱性を悪用する前に、セキュリティの脆弱性を発見し軽減することを目的としたセキュリティテストです。多くの企業では、コードレビュー、ペネトレーションテスト、レッドチームなどの手動プロセスや、静的アプリケーションセキュリティテスト (SAST) などの自動化プロセスに対応した確立されたソリューションを導入しています。しかし、API Webサービスの保護に関しては、動的アプリケーションセキュリティテスト(DAST) に苦労することがあります。これは、SAST ツールはサービスの開発者が追加作業をしなくても DevSecOps チームがサービスの CI/CD パイプラインに簡単に統合できるのに対し、DAST ツールの統合は困難だからです。
最近の BlueHat にて、マイクロソフトの Azure Edge & Platform チームが、DAST を大規模に実行するためのセキュリティ自動化について講演しました。本ブログでは、その講演を振り返ります。この取り組みは、マイクロソフト自身が作成、所有、管理する、つまり ファースト パーティのアプリケーションまたはサービスのポートフォリオ全体で、数千の内部および外部 の API Web サービスを対象としています。
多くの企業が DAST の拡張に課題を抱えている理由
DAST は、ソフトウェアの実行時にテストをすることで、セキュリティの脆弱性または弱点を引き出そうとするソフトウェアのテストプロセスです。Web アプリケーションや Web サービスのテストでは、通常、ファジングなどの手段を使用して不正な形式の Web 要求を送信し、要求に対する Web サーバーの応答に基づいてバグを特定します。Web アプリケーションのスキャンに利用できる多くの優れた商用およびオープンソースの DAST ツールがあり、マイクロソフトの RESTler もその1つです。Web サーバーをスキャンする場合、利用する DAST ツールの数によらず、ツールは Web エンドポイントを認識する必要があり、Web サーバーのエンドポイントロジックはリクエストを処理する必要があります。また、Web サービスの API 仕様と有効な認証情報にアクセスする必要があります。つまり、安全な方法で大規模にテストするには、開発者が手動で作業する必要があります。
Web エンドポイントの検出
従来、DAST ツールに必要な入力は、スキャンする対象である Web サーバーのアドレスのみでした。DAST ツールは、ホームページから特定のサイトを自動的にクロールし、HTML に埋め込まれたリンクをたどってすべてのサイトページを検出します。これにより、DAST ツールは、ユーザーからの入力を受け入れるページ、つまり URL のコンテキストで、サイトが提供するすべての動的機能を検出します。
上記の図で示す例では、DAST ツールはホームページ https://www.contoso.com からリンクをたどり、クロールを開始します。https://www.contoso.com/contact.html の URL パラメーターやリクエストボディを介してユーザーからの入力を受け付ける問い合わせフォーム https://www.contoso.com/contact/inquiry.asp を発見します。DAST ツールは、動的なページにおける入力処理のセキュリティ脆弱性を発見するために、不正な値でページにリクエストを送信します。
一般に、このようなクロールの方法は、従来の Web サイトでは十分に機能します。しかし、機能が API を介してのみ公開される Web サービスでは使用できません。次の図では、モバイル アプリが REST API Web サービス https://api.fabrikam.com/ と通信します。
この例では、モバイルアプリには、REST API エンドポイント /login , /products , /cart , /logout がアプリにハードコードされています。DAST スキャナーが https://api.fabrikam.com/ を開こうとすると、エラーが発生します。
このシナリオに対応するため、最新の DAST ツールでは、OpenAPI 仕様 (Swagger 仕様) としてユーザーはエンドポイントのリストを入力します。この仕様は、Web サービスの API URL の詳細なリスト、各 API で受け付けるすべてのパラメーター、および各パラメーターの予想される形式をメタデータで列挙します。OpenAPI 仕様では、NSwag および swagger-core をパッケージで生成します。パッケージを使用するには、特定のサービスのソースコードと作業ビルド環境の両方にアクセスする必要があります。そのため、開発者はソリューションを Web サービス プロジェクトに手動で統合する必要があります。これは小規模な組織にとっては良いアプローチかもしれません。
しかし、企業のセキュリティチームが自社の開発者全員にソリューションを Web サービスプロジェクトに統合するように指示した場合、各プロジェクトのコードとビルド構成を手動で更新する必要があります。このプロセスには莫大なコストがかかるため、経営層や開発者から反発を受けることは間違いありません。
拡張性のある OpenAPI 仕様の自動生成ソリューション
OpenAPI 仕様では、サービスごとの開発者による手作業が不要な、自動的に生成する手法がいくつかあります。
1 つの解決策は、対象の Web サーバーに送信されたリクエストを監視し、リクエストに基づいて OpenAPI 仕様をリアルタイムで推定する方法です。この監視は、クライアント側、サーバー側、または API ゲートウェイ、ロードバランサーなどの中間で実行できます。つまり、各開発者の作業を必要としない、スケーラブルで自動化することができるソリューションです。しかし、このアプローチでは、実行時間によっては、すべての Web エンドポイントを包括的に識別できない可能性があります。たとえば、/logout エンドポイントを呼び出したユーザーがいない場合、/logout エンドポイントは OpenAPI 仕様によって自動生成されません。
他の解決策は、Web サービスのソース コードを静的に分析し、自動的にソース コードから取得できる定義済みの API エンドポイント ルートに基づいて OpenAPI 仕様を生成することです。マイクロソフトは、このソリューションのプロトタイプを社内で作成し、動作するビルド環境にアクセスせずに抽象的な構文ツリーを解析しました。しかし、すべての API エンドポイント ルートおよびパラメーターを確実に検出することは困難でした。また、このソリューションでは、動的に登録された API ルート エンドポイント ハンドラーのシナリオは対応できません。加えて、マイクロソフトは、LLM を使用してソース コードから OpenAPI 仕様を派生させる静的分析ソリューションを社内で検討しました。いくつかの有望な結果は得られましたが、残念ながら、解決策は非決定論的でした。
何千もの Web サービスに対して DAST を完璧に拡張するには、OpenAPI 仕様を自動的に、包括的に、そして決定論的に生成する必要があります。このようなソリューションを導入した場合でも、テストしたサービスの機能を DAST ツールが実行できることを確認する必要があります。
認証と認可
ほとんどのエンタープライズ Web サービスでは認証が必要なため、Web サービスの全機能を実行するには DAST ツールに認証情報を提供する必要があります。また、Web サービスは、DAST ツールがサービスに要求を送信するための権限を付与する必要もあります。テスト環境では、通常、サービスごとに一意のテスト アカウントを使用するか、包括的なテスト アカウントを使用して DAST ツールを構成します。前者は、サービスごとに DAST ツールの実行を調整する必要があるため非常に複雑であり、後者は妥協点です。どちらの方法も、各サービス所有者が手動で構成を変更する必要があります。同様に、OpenAPI 仕様の生成について、経営層と開発者に莫大なコストがかかります。
拡張性のある DAST ソリューション
クラウド サービス プロバイダーとして、マイクロソフトは Web サービスを実行する IaaS と PaaS プラットフォームを所有しています。このプラットフォームは、ファースト パーティ サービスのインベントリを生成し、サービスにカスタム セキュリティ ツールを展開することができます。マイクロソフトのエッジコンピューティングとオペレーティング システムを担当する Azure Edge & Platform チームは、すべての IaaS ベースおよび PaaS ベースの Web サービスの非運用のテストインスタンスに展開できるエージェントを開発しました。このエージェントは、デプロイ機能によって、ソリューションを作成します。非運用インスタンスは、運用インスタンスと同じコードを共有します。非運用環境で DAST を実行することで、運用環境のデータを確実に保護します。DAST エージェントは、大規模で統合された DAST プラットフォームの1つのコンポーネントです。Web サービスのビルド環境にアクセスする必要がなく、開発者が新機能をサービスの CI/CD パイプラインに手動で統合する手間を省くことができます。エージェントは、Web サービスの実行中のプロセスに完全にアクセスできるため、メモリを検査し、新しいコードを実行中のプロセスにロードすることができます。
Web エンドポイントの検出
一般的な Web サーバーは、受信した要求を管理するため、URL ルートとルート ハンドラーのマッピングを維持します。エージェントは、実行時に Web サーバーのプロセスのメモリを検査してルート マッピングを検出し、検出されたマッピングから OpenAPI 仕様を生成することで、このアーキテクチャを活用します。
多くのマイクロソフトのWebサービスは ASP.NET で書かれており、リクエスト処理パイプラインを使用して受信した要求を処理します。
上図の各ブロックは、ミドルウェア コンポーネントです。パイプライン内の次のコンポーネントに渡す前に、リクエストを処理します。 (または残りのミドルウェア コンポーネントを短縮します。)
パイプラインの最後のミドルウェア コンポーネントは、エンドポイント コンポーネントです。Microsoft.AspNetCore.Builder.EndpointRoutingApplicationBuilderExtensions.UseEndpoints() のドキュメントには、
“Microsoft.AspNetCore.Routing.EndpointRoutingMiddleware は、ルーティングの決定が行われるミドルウェア パイプライン内のポイントを定義し、エンドポイントが HttpContext に関連付けられる。“と記載されています。Microsoft.AspNetCore.Routing.EndpointRoutingMiddleware の ソースコード を調べると、_endpointDataSource というフィールドがあります。これは、Microsoft.AspNetCore.Routing.EndpointDataSource オブジェクトで、それ自体に エンドポイント というプロパティがあります。ドキュメント には、エンドポイントプロパティは “読み取り専用の エンドポイント インスタンス コレクションである”と記載があります。各 エンドポイント インスタンスには、メタデータ収集 が含まれており、ルート エンドポイントの詳細を保持しています。
Web エンドポイントを検出するためのソリューションでは、エージェントが実行時に Web サーバープロセスのメモリ内のリクエスト処理パイプラインを自動的に検出し、上記の オブジェクト フィールド に従ってすべての エンドポイント オブジェクト インスタンス を検索します。その後、自動化されたエージェントは、各インスタンスに関連付けられたメタデータを処理し、Microsoft.OpenApi.Writers.OpenApiJsonWriter を使用して、すべての API エンドポイントと詳細なパラメーターを含む Web サービスの完全な OpenAPI 仕様を動的に生成します。OpenAPI 仕様は、対象の Web サービスをスキャンするための DAST ツールへの入力として使用できます。
上記の詳細は ASP.NET Core 固有のものですが、ランタイム メモリ インスペクションによるルート検出の同じアプローチは、ASP.NET Framework、PHP、Node.js などの他のフレームワークで記述された Web サービスでも活用することができます。
認証と認可
テストアカウントを使用して DAST ツールが認証されたリクエストを Web サービスに送信することには、課題とリスクがあります。これを解消するために、実行時に認証および認可を行うミドルウェアコンポーネントをフックします。これにより、テストアカウントが不要になります。
認証と認可の課題を解決するための手法は、Transparent Auth と呼ばれます。この手法では、Authentication コンポーネント と Authorization コンポーネントの前に新しいデリゲートを挿入します。これにより、エージェントがメモリ内のリクエスト処理パイプラインを自動的に探索し、実行時に新しいデリゲートを挿入します。
Transparent Auth は ASP.NET Core でのみ利用できますが、実行中に認証と認可をフッキングする同じアプローチは、ASP.NET Framework、PHP、Node.js などの他のフレームワークで記述した Web サービスでも活用できます。
認証フック
パイプラインの認証コンポーネントの前に挿入するフックにて、クライアントのリクエストを検査して、統合された DAST ツールからのリクエストかどうかを判断します。プロセス外のコンポーネントを使用して、統合された DAST ツールから送信されたすべてのリクエストを追跡し、フックはそのコンポーネントと通信して、リクエストが実際に統合された DAST ツールから発信されたものであることを確認します。フックが統合された DAST ツールからのリクエストではないと判断した場合、リクエストを元の認証コンポーネントに渡し、元の認証コンポーネントがリクエストを通常どおり処理します。
一方、フックが統合された DAST ツールからのリクエストであると判断した場合、追加の作業を行います。元の認証コンポーネントをスキップするだけでは、他のミドルウェア コンポーネントが要求に関連付けられた ID を使用すると問題が発生する可能性があり、スキップはできません。例えば、認証されたリクエストに 「Hello, <username> 」 と応答するWebサービスを想像してください。リクエストのコンテキストの ID に関連付けられたユーザー名がない場合、機能は例外を発生させます。これに対処するため、フックは新しい ClaimsPrincipal と ClaimsPrincipal を現在のリクエストのコンテキストに関連付けます。ClaimsPrincipal は、次のコレクションで構成され、Claim オブジェクトは、模擬ユーザーの名前、メールアドレスなどの値を使用して、モックユーザーのアイデンティティを具体化します。
リクエストのコンテキストが新しい ClaimsPrincipal で更新されると、フックは元の Authentication コンポーネントをスキップし、元の Authentication コンポーネントの直後にリクエストデリゲートを呼び出します。
認可フック
パイプラインの Authorization コンポーネントの開始前に挿入するフックは、Authentication フックと同様に開始されます。クライアントからのリクエストが統合された DAST からのものでもあることを確認し、そうでない場合はリクエストを元の Authorization コンポーネントに渡します。
フックが統合された DAST ツールからのリクエストであると判断した場合、通常は認可が成功したときに行われるリクエストのコンテキストに対して軽微な更新をします。次に、元の Authorization コンポーネントをスキップし、元の Authorization コンポーネントの直後に要求デリゲートを呼び出すため、認可チェックが回避され、サービスのエンドポイント ロジックが要求を処理できるようになります。
統合された DAST プラットフォームのアーキテクチャについて
これまで紹介したエージェントの機能は、統合された DASTプラットフォームのアーキテクチャ全体に当てはまります。以下に大まかに示します。
マイクロソフトのセキュリティ拡張機能を導入するメカニズムでは、エージェントをファーストパーティのマイクロソフト Web サーバーに展開します。次に、エージェントは、OpenAPI Specification Generator モジュールと Transparent Auth モジュールを Web サーバー上で実行している各 Web サービスのプロセスに挿入します。OpenAPI Specification Generator モジュールは、Web サービスの OpenAPI 仕様を生成し、エージェントによって起動された DAST プロキシ をプロセスに渡します。DAST プロキシは、リモートで Confidential コンテナー を起動し、OpenAPI 仕様をコンテナーに送信し、これに基づいてコンテナー内で調整した DAST ツールを実行します。
Confidential コンテナーを使用する理由はいくつかあります。まず、Trusted Execution Environments では、攻撃者がAzureのContainer Instancesサービス を侵害した場合でも、コンテナー内のコードやデータを改ざんできません。また、Confidential コンテナーを使用すると、エージェントは通信相手のコンテナーの 構成証明レポート を確認して、コンテナーが公式の DAST コンテナー イメージからビルドされたこと、コンテナーに適用されている セキュリティ ポリシー が公式の DAST コンテナー セキュリティ ポリシーであることを確認できます。対象の Web サービスごとに 1 つのコンテナーを使用し、各コンテナーは独自のポッドで動作します。そのため、DAST コンテナーは相互に通信できません。各ポッドは、アウトバウンド接続を防止し、ポッドのコンテナーを起動したエージェントからのみインバウンド接続が許可されるように、ファイアウォールで保護します。この統合された保護により、攻撃者が認証や認可を回避したり、統合された DAST ツールになりすましたり、DAST のスキャン結果を取得するのを防ぎます。
DAST プロキシは、DAST ツールからの要求を対象の Web サービス プロセス に転送します。Transparent Authモジュールは、各要求を受信し、DAST プロキシで要求を検証します。DAST プロキシが統合された DAST ツールからのリクエストであることを確認した場合、Transparent Auth モジュールは標準の認証および認可をスキップし、エンドポイント コンポーネントが要求を処理します。その後、DAST プロキシは Web サービスの応答を DAST ツールに転送します。DAST ツールのスキャンが完了すると、DAST プロキシは結果を収集し、セキュリティ結果を中央で管理しているバグ追跡システムに送信します。集約されたセキュリティ検出結果は、サービス所有者、セキュリティ保証チーム、および関連するリスク管理チームが活用できます。
まとめと今後の展望
この先の数か月、マイクロソフトの Azure Edge & Platform チームは、エージェントの開発とファーストパーティサービスへの展開を続けます。また、エージェントアーキテクチャを活用して、コードカバレッジの監視や DAST セキュリティ検出結果を脆弱なコードブロックに関連付けるなど、より高度な DAST 関連の概念をサポートすることも検討します。私たちは、複数の DAST ツール間で調査結果の収束および重複の排除し、AI を活用して誤検知を特定し、リスクの信頼性を向上します。
まとめに、この取り組みは、マイクロソフト サービスのセキュリティとお客様のデータを保護するための、マイクロソフトの献身的な取り組みです。ハイパースケーラー分野において、マイクロソフトはセキュリティのリーダーシップです。私たちは、マイクロソフト以外のセキュリティ専門家が、自社のサービスを大規模に保護するために同様の戦略を採用するきっかけになることを願っています。
Jason Geffner
プリンシパル セキュリティ アーキテクト