NGINX App Protect による gRPC API の保護

初めにモノリスがありました。 これは長い間ソフトウェア開発者に役立っており、一部のユースケースでは現在でも役立っています。 しかし、applicationsが大きくなるにつれて、モノリスの開発、セキュリティ保護、保守が扱いにくくなりました。 マイクロサービス 代替手段として登場したのが、モノリスです。モノリスは、単一のビジネス機能を実行し、ネットワークを介して通信してapplicationの完全な機能を提供する、小さくて自律的なサービスに分割されます。 当初、Web 開発者は通信プロトコルとしてSOAPを使用し、データのエンコードにはXML を使用していましたが、その組み合わせは扱いにくく、遅いと感じた人も多くいました。 これにより、 RESTベースのアーキテクチャへの切り替えと、プロトコルとデータシリアル化方法としてそれぞれHTTPとJSONが広く採用されるようになりました。

しかし、テクノロジーではよくあることですが、開発者は、SOAP や REST のテキストベースの方向性に固有の制限を克服するなど、applicationsを設計するためのさらに優れた方法を模索し続けました。 そうしたシステムの 1 つがgRPCです。これは Google が自社の膨大な数の独立した自律的なサービスを接続するために開発したシステムです。gRPC は、構造化データをシリアル化するためのプラットフォームおよび言語に依存しないメカニズムとしてプロトコル バッファ(protobufs) を使用し、通信プロトコルとして HTTP/2 を使用します。

gRPC の利点

gRPC が他の API フレームワークよりも優れている点としては、低レイテンシのスループット、複数言語のサポート、コンパクトなデータ表現、リアルタイム ストリーミングなどがあり、これらにより gRPC はマイクロサービス間の通信や低電力、低帯域幅のネットワークでの通信に特に適しています。 gRPC の人気は近年大幅に高まっています。これは、信頼性とスケーラビリティが高く、クライアントとサーバーの両方で言語に依存しない新しいサービスをより迅速かつ効率的に構築できるためです。

gRPC の利点の顕著な例はオープン バンキングです。オープン バンキングでは、オープン ソース テクノロジを使用して API を構築および提供し、サードパーティの開発者が銀行やその他の金融機関の顧客に追加のサービスを提供できるようになります。 オープン バンキングの基盤全体は、金融情報をより効果的かつ効率的に配信するという理想の上に構築されています。gRPC は、プロトコル バッファーのコンパクトな形式と HTTP/2 の多重化により、特定のペイロードの転送が REST API よりもはるかに高速になるため、この目標の達成に役立ちます。データ受信時はおよそ 7 倍、データ送信時はおよそ 10 倍高速です。 その結果、金融機関はサービス間の通信に gRPC を採用し、より高速で、より効率的、信頼性が高く、大規模なサービスを提供しています。

gRPC の速度が大きな利点となる具体的なユースケースの 1 つは、オープン バンキングの成功に最も重要である顧客オンボーディング プロセスです。 他の API フレームワークでは、金融機関と顧客の両方にとって、新しいアカウントの作成は面倒で時間のかかる作業になる可能性があります。 gRPC を使用すると、データ転送が高速になり、顧客は数分で新しいアカウントを作成できます。 これにより、顧客満足度が大幅に向上し、金融機関のコストが大幅に削減されます。

gRPC のセキュリティ保護

gRPC 標準とプロトコル バッファー形式は、オープン ソース ライブラリとして実装されています。 プロトコル バッファは、ライブラリ パーサーが不正なリクエストを拒否し、ライブラリの動作をより慎重に調べるため、他のデータ表現よりもサイバー攻撃に対して安全であると考えられています。

しかし、gRPC に対する攻撃の不安な機会がいくつか残っています。 たとえば、パーサーは次のようになります。

• キーワードストリームなしでメッセージのストリームを送信できます
• フィールドが繰り返し可能として宣言されていない場合でも、メッセージ内のフィールドの複数回出現を許可します。
• マップフィールド内の重複キーはチェックされません。キーの最後の出現のみが考慮されます。
• 複合型の1 つをチェックせず、複数のフィールドが存在することを許可します。

攻撃者は、gRPC プロトコルのこれらのギャップを悪用してapplicationを侵害する可能性があります。 プロトコル バッファを使用すると、メッセージ定義で定義されていないフィールドを作成することもできます。 これにより、設計の拡張性が確保され、メッセージの将来の拡張バージョンとの互換性が可能になりますが、applicationsが密輸攻撃に対して脆弱になる可能性もあります。密輸攻撃では、攻撃者はapplicationで許可されていると明示的にコード化されていないフィールドをリクエストに組み込みます。

NGINX App Protect が gRPC API を保護

NGINX App Protect は、サービスapplicationに近い最新の gRPC ベースのapplicationsを保護するように設計されています。 これにより、AppDev、DevOps、DevSecOps チームは、applicationセキュリティをコードとして管理し、ネイティブ ツールを活用できるようになります。

たとえば、NGINX App Protect は、金融機関とそのサービスがサービス間通信に gRPC を実装する際に、オープン バンキング標準に準拠していることを保証します。 NGINX App Protect のエンジンは、ワイヤ リクエスト上の gRPC メッセージの詳細な検査を実行し、プロトコル バッファー メッセージを解析し、ネストされた複雑なデータ構造を含むメッセージ ヘッダーとペイロード内の悪意のあるデータを検出します。 検査はあらゆるリクエストに対して実行され、各 API 呼び出しパラメータに対して攻撃検出メカニズムが適用されます。

gRPC API では、gRPC インターフェースを使用して、タイプ ライブラリ ファイル (IDL ファイル) とプロトコル バッファーの proto 定義ファイルにセキュリティ ポリシーを設定します。 更新されたファイルがロードされると、NGINX App Protect は、構成を変更することなく、新しいセキュリティ ポリシーの適用を直ちに開始します。gRPC proto ファイルは CI/CD パイプラインの一部として頻繁に更新されるため、セキュリティ ポリシーを更新してもプロセスが中断されたり、オーバーヘッドが追加されたりすることはなく、applicationsは常に最新のポリシーによって保護されます。

NGINX App Protect は、gRPC ベースのマイクロサービス間の東西トラフィックを保護するだけでなく、公開されている資産間の南北トラフィックも保護します。

gRPC はサービス間通信の速度、効率、規模を向上させますが、API データ (URL、ヘッダー、ペイロード) と gRPC API を公開するapplicationサービスを保護し、セキュリティで保護することが重要です。 そのため、NGINX App Protect は最新のapplicationアーキテクチャにとって不可欠です。

NGINX App Protect を使用した gRPC の詳細については、ライトボード ビデオをご覧ください。

NGINX App Protectを無料でお試しください

NGINX App Protect での gRPC サポートの詳細については、ドキュメントを参照してください。

gRPC API で NGINX Plus と NGINX App Protect を試すには、 30 日間の無料トライアルを開始するか、お問い合わせの上、ユースケースについてご相談ください。