SPA の確保はチームスポーツです

私が長年にわたり注目してきた興味深い、そして最も苛立たしいことの 1 つは、ネットワーク エンジニアとアプリケーション開発者のアプリに対する見方の違いです。 これは、アプリケーションがネットワーク図に描かれる方法や、逆にネットワークがアプリケーション アーキテクチャ図に表示される方法で確認されています。 

言うまでもなく、両者は相手に対して非常に単純な見方をしています。 

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

本日の議論は SPA に焦点を当てます。 この特定の TLA が何の略なのか疑問に思っている人のために説明すると、これは「シングル ページ アプリケーション」の略です。 

SPA の紹介 

シングル ページ アプリケーションとは、まさにその名の通り、アプリケーション関連のすべてのタスクのフレームワークとして機能する単一の Web ページです。 このアーキテクチャは、ページ全体を再読み込みするのではなく、個々の DOM (Document Object Model) 要素を「更新」する方法として、Web 2.0 と AJAX の出現の時代を思い起こさせます。 この技術によりパフォーマンスが大幅に向上し、現代のシングルページ アプリケーションの先駆けとなりました。

これらのアプリは、モバイル アプリの動作をより忠実に反映しており、最初に開いたときにクライアント UI が読み込まれ、サーバーとの通信にはデータのみが含まれます。 つまり、サーバーへのすべての呼び出しにはデータのみが含まれ、UI の変更はクライアント上で行われます。 これにより、送受信されるデータの量が大幅に削減され、ご想像のとおり、パフォーマンスが向上します。 こうした種類のアプリは API を使用してデータを交換します。

一般的に、私たちはこれらの API のほとんどが REST 原則を使用して実装されているという前提で作業してきました。 つまり、各オブジェクト (通常は単一の UI 要素に関連付けられていると見なされます) には、CRUD (作成、読み取り、更新、削除) トランザクションを実行するために呼び出すことができる独自の API があります。 セキュリティの観点から見ると、特定の 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 呼び出しを処理する場合もあれば、少数の API 呼び出しを処理する場合もあります。 いずれの場合も、何らかの形式 (おそらく XML、おそらく JSON) でデータを保護する必要性に対処することになるでしょう。 つまり、コンテンツにはリスクが伴うことを認識する必要があるということです。 一部のデータは UI 要素を動的に生成するために使用される場合があり（またはクライアントで DOM を操作する場合もあります）、送信ごとに潜在的に悪意のあるコードを探して破壊することが重要です。 

セキュリティの断絶 

残念ながら、さまざまな機能のデータ交換に単一の URI を使用する場合、URI にポリシーを添付するという従来の方法は機能しません。 実際、このようなポリシーは特定のペイロード形式を想定するようにトレーニングされていることが多いため、セキュリティが侵害される可能性があります。 API ゲートウェイも、多くの場合、ポリシー (ルーティング、計測、アクセス) を特定の URI に結び付けます。つまり、さまざまなデータ形式を持つ多くの機能を処理するのに、ほんの数個の URI (API 呼び出し) を使用する方法は、既存のセキュリティを破る可能性があります。

これは、セキュリティと開発 (DevOps ではなく開発者) がコードの最初の行からデプロイメントまでより緊密に連携することがますます重要になっている理由の例です。 開発者が早い段階で実行できる対策はいくつかあり、セキュリティ担当者が適切な保護を導入しやすくなるように、適切なポリシーを実行できるようにするインジケーターを含む HTTP ヘッダーを挿入するなどです。 「X-Code: 'order'」のような単純なものでも、セキュリティ ソリューションがデータを識別し、その後スキャンして潜在的な脆弱性を探ることができるような方法でリクエストを充実させることができます。

アーキテクチャ的には、リクエストを適切なセキュリティ ソリューション (WAF、API ゲートウェイなど) にルーティングする前に、コードを抽出して URI を書き換えることができるスマート L7 プロキシが必要になる場合があります。 このアプローチは、スマート L7 プロキシが JSON などのデータ形式言語を話すことができ、開発者がすべての交換に書き換えて適切な場所にルーティングするために使用できるコードまたはエンドポイント名を含める場合にも機能します。 

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

セキュリティはチームスポーツ

一般的に、開発者がクライアントとサーバー間でさまざまな責任を分散する方法の変更は、アプリケーション サービス インフラストラクチャが後続の要求や応答と対話する方法に大きな影響を与えます。 セキュリティ、開発者、アプリケーション サービス インフラストラクチャ チームが SDLC 全体に関与することが重要です。アーキテクチャ ソリューションの実装にも時間がかかります。 「最後まで」残しておくと、市場に出すまでに数日、数週間、あるいは数か月も余計にかかることになります。 あるいは、セキュリティ サービスなしで市場に参入することになりますが、これには独自のリスク (および結果) が伴います。  

開発初日からのコラボレーションは、アプリが本番環境に導入されたときに利用可能で、高速で、安全であることを保証する最良かつ最速の方法です。