SPAのセキュリティ確保はチーム戦

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

長年にわたって気づいた興味深い点の1つは、同時にもどかしく感じる点でもありますが、ネットワークエンジニアとアプリケーション開発者では、アプリに対する見方が異なることです。この違いは、ネットワーク図でのアプリケーションの描かれ方や、逆にアプリケーションアーキテクチャ図でのネットワークの示され方に表れています。

言うまでもなく、双方とも相手を非常に単純化して捉えています。

これはセキュリティにも当てはまります。ネットワークやアプリケーションだけでなく、事業そのものを保護するうえで、セキュリティの役割は極めて重要になっています。セキュリティチームがアプリケーションを真に理解するには、一般的なアーキテクチャ図の枠を越えて考えることが重要です。成功した攻撃のかなりの割合が、アプリケーション層で実行されています。さまざまな種類のアプリケーションに固有の特性を認識できない状態が長引くほど、それらのアプリケーションが脆弱な状態に置かれる期間も長くなります。

今回取り上げるのはSPAです。この3文字の略語は「Single Page Applications」（シングルページアプリケーション）を意味します。

SPA入門

シングルページアプリケーションとは、その名のとおり、アプリケーションに関連するすべての処理の基盤となる単一のWebページです。このアーキテクチャの起源はWeb 2.0の時代にさかのぼります。当時、ページ全体を再読み込みする代わりに、個々のDOM（Document Object Model）要素を「更新」する手法としてAJAXが登場しました。この手法によってパフォーマンスが大幅に向上し、今日のシングルページアプリケーションの先駆けとなりました。

これらのアプリは、モバイルアプリに近い動作をします。初回起動時にクライアントUIが読み込まれ、それ以降はデータのみがサーバーとの間でやり取りされます。つまり、サーバーへの各呼び出しに含まれるのはデータだけで、UIの変更はすべてクライアント側で行われます。これにより、送受信されるデータ量が大幅に削減され、パフォーマンスが向上します。この種のアプリでは、APIを使用してデータを交換します。

一般に、これらのAPIの大半はRESTの原則に基づいて実装されているという前提で考えてきました。つまり、各オブジェクト（通常は1つのUI要素に関連付けられていると見なされます）には固有のAPIがあり、それを呼び出してCRUD（作成、読み取り、更新、削除）処理を実行できます。セキュリティの観点では、特定のAPI（URI）呼び出しに対して特定の形式のデータを想定できるため、対応がやや容易になります。"/update/product/123"に送信されるデータは常に同じシリアル化オブジェクトですが、"/delete/order/4433"に送信されるデータは別のシリアル化オブジェクトになります。そのため、特定のURIに特定のポリシーを関連付ける従来の手法を使用して、そのAPIを保護できます。

単一URIパターン

SPAは、このパターンに従う場合もあれば、従わない場合もあります。SPAをめぐる新たな手法では、より従来型の機能とURIのマッピングに加え、同じAPIを使用してトランザクションを実行することも可能であり、実際に行われています。単一URIパターンのSPAでは、URIは変わりませんが、サーバーとの間で送受信されるシリアル化オブジェクトは変わります。

これは、単一のエンドポイント（URI）を使用して複数の機能を呼び出すSOA/XMLトランザクションを想起させます。対象となる機能（エンドポイント）は、シリアル化されたXMLデータ内に含まれるか、カスタムHTTPヘッダーに挿入されることもありました。このモデルにより、リクエストを受信し、呼び出される機能を特定してから、適切なエンドポイント（サーバー）にルーティングするSOA/XMLゲートウェイが必要になりました。

SPAでは、複数のAPI呼び出しを処理する場合もあれば、数回だけの場合もあります。いずれの場合も、何らかの形式（XMLの場合もありますが、多くはJSON）のデータを保護する必要が生じる可能性があります。つまり、コンテンツ自体にリスクが潜んでいることを認識する必要があります。一部のデータは、UI要素の動的な生成（またはクライアント側でのDOMの操作）に使用される可能性があるため、送信のたびに悪意のある可能性のあるコードを検出して排除することが重要です。

セキュリティの分断

残念ながら、さまざまな機能のデータ交換に単一のURIを使用する場合、URIにポリシーを関連付ける従来の手法は機能しません。実際、このようなポリシーは特定のペイロード形式を想定して学習されていることが多いため、セキュリティが損なわれる可能性があります。APIゲートウェイでも、ポリシー（ルーティング、メータリング、アクセス）を特定のURIに関連付けることがよくあります。つまり、わずかな数のURI（API呼び出し）で、異なるデータ形式を使用する多数の機能を処理する手法は、既存のセキュリティを損なう可能性があります。

これは、コードの最初の1行からデプロイに至るまで、セキュリティ担当者と開発者（DevOpsではなく、開発者）がより緊密に連携することの重要性が高まっている理由を示す一例です。適切なポリシーを実行できるようにする識別子をHTTPヘッダーに挿入するなど、開発者が早い段階で対応することで、セキュリティ担当者が適切な保護対策を導入しやすくなります。たとえば「X-Code: 'order'」のような単純な情報を付加するだけでもリクエストが拡充され、セキュリティソリューションがデータを識別し、潜在的なエクスプロイトがないかスキャンできるようになります。

アーキテクチャ上、コードを抽出してURIを書き換えたうえで、リクエストを適切なセキュリティソリューション（WAF、API Gatewayなど）にルーティングできるインテリジェントなL7プロキシが必要になる場合があります。このアプローチは、インテリジェントなL7プロキシがJSONなどのデータ形式を解釈でき、かつ開発者がすべての通信に、書き換えと適切な宛先へのルーティングに使用できるコードまたはエンドポイント名を含める場合にも有効です。

アプリケーション層のセキュリティをアプリ自体に組み込むことができれば、パフォーマンスとセキュリティの最適なバランスが得られます。しかし、常にそれが可能とは限らず、セキュリティという目標を達成するために、独創的なアーキテクチャ上の解決策が必要になる場合もあります。

セキュリティはチームで取り組むもの

一般に、開発者がクライアントとサーバーの間でさまざまな責任を分担する方法を変更すると、その後のリクエストやレスポンスに対するアプリケーションサービスインフラストラクチャの処理に大きな影響が及びます。セキュリティ、開発、アプリケーションサービスインフラストラクチャの各チームが、SDLC全体に関与することが重要です。アーキテクチャ上のソリューションの実装にも時間がかかります。「最後まで」先送りすると、市場投入までに数日、数週間、場合によっては数か月もの時間が余計にかかります。あるいは、セキュリティサービスを導入せずに市場投入することになり、それに伴う固有のリスク（および影響）が生じます。

開発初日から連携することが、アプリケーションを本番環境に移行する際の可用性、速度、セキュリティを確保するうえで、最善かつ最速の方法です。

著者について

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。

Lori Mac Vittieのその他のブログ記事