NGINX Plus でセキュリティ脆弱性を迅速かつ簡単に軽減

NGINX は、世界中の何百万もの組織が当社のソフトウェアを信頼し、自社の Web サイトやアプリ配信インフラストラクチャを強化していることを誇りに思っています。 ユーザーが NGINX にどれほど依存しているかを考えると、今日のインターネットで非常に一般的になっている共通脆弱性識別子 (CVE) などのセキュリティ脆弱性に対する修正を含む最新バージョンを実行することの重要性についてユーザーがあまり考慮していないことを認めると、私たちは驚きます。

もちろん、セキュリティの脅威に対する防御について考えるだけでは十分ではありません。脆弱性を追跡し、脆弱性が明らかになったらすぐに保護を実施するための、明確に定義されたプロセスを実装する必要があります。 オープンソース ソフトウェアの場合のように、すべてを自分で行う必要がある場合、どれだけの時間と労力がかかるかを過小評価しがちです。 実際、セキュリティの脅威から自分自身を素早く簡単に保護できることは、NGINX Plus のような商用サポート付きソフトウェアの見過ごされがちな利点です。

このブログでは、オープンソース ソフトウェアを保護する際の課題を探り、NGINX Plus によって CVE やその他のセキュリティ脅威の軽減がいかに迅速かつ容易になるかを説明します。

オープンソースソフトウェアの脆弱性への対処

すべての開発者が完璧なコードを書いていると考えたいとしても、バグのないソフトウェアは存在しません。 開発者は、厳格な品質コンプライアンス プロセスの一環として、ほとんどのバグが開発中に検出され、アプリの寿命中の通常の使用中に表面化するバグはごくわずかであることを期待しています。最悪の場合、バグは悪意のある悪意のあるユーザーによって発見されます。

複数のオープンソース ツール、プログラミング言語、プラットフォームからアプリケーション スタックを構築すると、バグの影響は大幅に増大します。 バグがないことを確認するには、各コンポーネントを個別にレビューする必要があります。 オープンソース ソフトウェアでバグが発見された場合、バグを検証、テストし、(可能な場合は) 修正するためのポリシーを定義することが重要です。

オープンソース ソフトウェアのポリシーには、少なくとも次の 3 つのプロセスを含める必要があります。

1. 定期的なレビューとテスト
2. 脆弱性を追跡し、社内に報告する
3. 脆弱性をタイムリーに修復する

脆弱性の報告

セキュリティ上の脆弱性が発見された場合、それを公開するための標準的な一連のイベントがあります。 最初のステップは、ソフトウェアの作成者またはベンダーに詳細なレポートを提出することです。 報告者と作成者は共同で、脆弱性をいつどのように公開するかを決定します。通常は、 Common Vulnerabilities and Exposures (CVE) データベースに記録する形式になります。 慣例により、著者は開示前に 90 日以内に問題を解決する必要がありますが、交渉によりさらに時間を延長することも可能です。

NGINX と CVE

NGINX は、オープンソース ソフトウェアのプロバイダーおよび商用ソフトウェアのベンダーとして、 NGINX Open SourceやNGINX Plus 、その他の商用製品 (執筆時点では NGINX Controller [現在はF5 NGINX Management Suite ] 、 NGINX App Protect 、 NGINX Ingress Controllerなど)、および無料のオープンソース製品 ( NGINX Service Mesh 、 NGINX Unit 、 NGINX Amplifyなど) に影響する CVE やその他の脆弱性の報告および修復プロセスに積極的に参加しています。

NGINX Plus は NGINX Open Source をベースにしているため、NGINX Open Source のユーザーはメリットを享受できます。NGINX Plus は、NGINX Plus のお客様に対してエンタープライズ レベルのサポートとプロセス標準を提供することに注力しているからです。 これらの標準には、コア ソフトウェア、依存関係、サポート対象モジュールのいずれについても、パッチが準拠する必要があるバグ修正およびテスト手順を規定する、お客様とのサービス レベル契約 (SLA) が含まれます。 SLA は、顧客が規制に準拠し、脆弱性の悪用にさらされるリスクを最小限に抑えるのに役立ちます。

NGINX オープンソースのもう一つの特徴は、多くのサードパーティ技術がこれを活用して自社製品に組み込んでいることです。 これらのテクノロジーのプロバイダーは、ソフトウェアの脆弱性が発見されたときにそれを開示し、修正するための独自のプロセスを持っています。 次のセクションで説明するように、NGINX Open Source のパッチのリリースとサードパーティのテクノロジーの対応するパッチのリリースの間には、かなり大きな遅れが生じることがあります。

NGINX Plusが加入者を脆弱性から保護する方法

はじめに、NGINX Plus の見過ごされがちな利点として、お客様が脆弱性から自分自身をより迅速かつ容易に保護できることについて触れました。 オープンソース ソフトウェアの脆弱性に対処することは、多くの人が考えるよりもはるかに時間がかかり、したがってコストもかかる可能性があります。

次のセクションでは、NGINX Plus 加入者が脆弱性をより迅速かつ容易に解決するための 5 つの具体的な方法について説明します。

NGINX は NGINX Plus 加入者にパッチについて積極的に通知します

NGINX Open Source および NGINX Plus のセキュリティ パッチがリリースされると、NGINX Plus のお客様に電子メールで事前にお知らせします。 ほとんどのパッチが利用可能になったことを発表するブログも公開していますが、NGINX オープンソース ユーザーに直接連絡する方法はありません。 これにより、CVE やその他の脆弱性データベースを監視し、定期的にブログを確認するという負担が彼らにかかります。

F5 SIRT が攻撃を受けている NGINX Plus 加入者にリアルタイムの支援を提供

NGINX Plus 加入者を含む F5 のお客様が攻撃の被害に遭った場合、 F5 セキュリティ インシデント レスポンス チーム(SIRT) がリアルタイムで支援を提供します。 SIRT は、攻撃を効果的に軽減し、システムを復旧させるために迅速に対応します。 彼らは攻撃が止んだ後もお客様と協力し続けます。「報告されたインシデントの先を見据えて、組織への全体的な被害を軽減し、将来の脅威を理解し、予測し、阻止します」。

NGINX App Protect がアプリケーション保護を強化

NGINX App Protect は、 F5 の 20 年にわたるセキュリティの経験を活かし、NGINX Plus 動的モジュールとして導入されたエンタープライズ グレードの Web アプリケーション ファイアウォール (WAF) です。 バックエンド アプリケーション サーバーのさらに多くの CVE に対するアプリケーション固有の保護により、NGINX Plus のレイヤー 7 セキュリティが強化されます。 NGINX と F5 は、特定の攻撃キャンペーンに関連するシグネチャを提供することに取り組んでいます。 結果？ NGINX App Protect により、NGINX Plus 加入者は独自のシグネチャを構築したり、複数の誤検知に対処したりする手間が省けます。

NGINX PlusはJWTベースとOpenID Connect認証をサポート

パッチを必要とする特定の脆弱性がない場合でも、高度な認証プロトコルにより、悪意のある人物がアプリやインフラストラクチャにアクセスするのを防ぐことができます。 NGINX Open Source で利用可能な方法に加えて、NGINX Plus は、 Web クライアントとAPIクライアントの両方に対して、 JSON Web Token (JWT) とOpenID Connectに基づく認証をサポートしています。

NGINX Plus加入者はすぐにパッチを入手

「脆弱性の報告」で説明されているように、脆弱性が NGINX ソフトウェアに影響する場合、通常は CVE として公開される前に通知されます。 事前警告により、公開前にパッチを準備することができ、通常は公開当日（場合によっては数日以内に）にパッチをリリースします。 この修正は、パッチを適用したバイナリの形式で NGINX Plus のお客様に提供されます。 NGINX オープンソース ユーザーには、サポートされている OS 用の修正されたソース コードとパッチ適用されたバイナリの形で提供されますが、前述のとおり、NGINX オープンソース ユーザーに直接通知する方法はありません。

NGINX オープンソースを活用または組み込むサードパーティのテクノロジーは、脆弱性が公開される前にその脆弱性に気付かない可能性があります。 たとえそうであったとしても、私たちの経験では、彼らのパッチは NGINX のパッチより数か月遅れる可能性があります。 これは、特にボランティアによって保守されることが多いオープンソース ソフトウェアの場合、理解できますが、脆弱性が公開されるとインフラストラクチャが保護されず、ハッカーによる悪用を受ける可能性があります。

一例として、2018 年秋に HTTP/2 の脆弱性に関する 2 つの CVE ( CVE-2018-16843とCVE-2018-16844 ) が発見されました。 これに応じて、 NGINX Plus R16および NGINX Open Source 1.15.6 にセキュリティ パッチを適用しました。 NGINX オープンソースを基盤として NGINX Plus の一部の機能を提供する人気の OpenResty ソフトウェアは、 2019 年 3 月 3 日に初めてこれらのパッチを組み込んだリリース候補版を発行しました。これは、NGINX からのパッチから 4 か月後のことでした。OpenResty 上に構築されたソリューションでは、コード ベースにパッチを適用するのに通常さらに長い時間がかかります。

場合によっては、脆弱性のステータスが明確でなかったり、潜在的な攻撃ベクトルを構成しているにもかかわらず、ソフトウェア プロバイダーがパッチが必要ないと考えていることがあります。 このような状況は、最も広く使用されているオープンソース WAF ソフトウェアである ModSecurity で 2020 年に発生しました。 OWASP ModSecurity Core Rule Set (CRS) を管理するチームは、ModSecurity v3 が正規表現のグローバル マッチングを実行する方法により、OWASP CRS チームがサービス拒否の脆弱性( CVE-2020-15598 ) と見なす結果になる可能性があることを発見しました。 ModSecurity 自体を管理する組織である Trustwave は、この動作がセキュリティ上の問題であると主張し、パッチの発行を拒否しました。

NGINX ModSecurity WAF は、 ModSecurity v3 上に構築された NGINX Plus の動的モジュールです。 NGINX チームは、 CVE-2020-15598に記載されている動作が DoS 脆弱性を引き起こす可能性が高いと判断し、2020 年 9 月にパッチを発行しました。 パッチを発表したブログで説明したように、オープンソースの ModSecurity ビルドのユーザー (NGINX Open Source ユーザーを含む) は、OWASP CRS チームからのパッチを適用するか、Trustwave からのパッチ未適用のソフトウェアを使い続けて Trustwave が提案する緩和策を実施するかを自分で決定する必要があります。

[編集者注– NGINX ModSecurity WAF は、2022 年 4 月 1 日をもって正式に販売終了となり、 2024 年 3 月 31 日をもってサポート終了となります。 詳細については、弊社ブログの「F5 NGINX ModSecurity WAF はサポート終了に移行しています<.htmla>」をご覧ください。

結論

競争が激化する今日のビジネス環境において、ソフトウェア チームは、最も革新的なサービスを提供するために、新しいコードや更新されたコードをできるだけ早く提供しなければならないというプレッシャーにさらされています。 同時に、インフラストラクチャやアプリケーションに対する高度な攻撃が増加しているため、脆弱性を追跡してできるだけ早く軽減することが重要になっていますが、これは面倒で時間のかかる作業です。

NGINX Plus サブスクリプションは、その負担を軽減し、組織をセキュリティの脆弱性から保護しながら、アプリケーション チームが主なミッションであるコードの高速配信に集中できるようにします。

NGINX Plus の高度な機能をすべてお試しください。今すぐ30 日間の無料トライアルを開始するか、弊社にお問い合わせの上、使用事例についてご相談ください。