プレスリリース
ブログ
ブログ
F5 Distributed Cloud Services で始める API Security ›
ブログ
アプリの新時代に向けてAPIセキュリティと運用を「驚くほど簡単」にする、新しいF5！ ›
ブログ
API保護の向上が金融サービスのセキュリティを強化する5つの分野 ›
ブログ
F5 Distributed Cloud Services で実現する Web/APIアプリケーションの脆弱性検知と保護 ›
プレスリリース
プレスリリース
F5、Enterprise Management AssociatesからAPI Security Visionaryに認定される ›
プレスリリース
F5、AIを活用した新型アプリとAPIセキュリティ機能でデジタルサービスを保護 ›
プレスリリース
F5、AI時代のアプリケーション セキュリティを変革 ›
以前、下記の記事でAPI Securityについてお伝えしましたが、読んで頂いた方がいらっしゃれば幸いでございます。
今回は上記記事内の「理想的なAPIプラットフォーム」の項目で掲載している下図の中にあるAPI Gatewayについて、なぜ「Outer」「Inner」と分かれているのか、NGINXがどういった理由で活用されているのか、についてお伝えします。
NGINXをベースとした多くのAPI Gateway製品
まず一般的なAPI Gateway製品について見てみたいと思います。世の中には多くのAPI Gateway製品があります。クラウドでのAPI Gateway機能や、ベンダーが提供しているAPI Gateway as a Service、製品としてのAPI Gateway等、提供形態は様々です。それらAPI Gatewayの多くは、NGINXをベースに構築されていることをご存知でしょうか。例えば下記のような製品があります。
「Kong」
API GatewayマーケットのリーダーであるKongですが、下記の通りNGINXをベースに開発されています。
記事の中でNGINXの性能について褒めて頂いておりますが、CloudflareのCDN基盤でもNGINXが採用されていると言及しています。
「Apigee」
Googleが提供しているAPI Gatewayですが、下記のように一部コンポーネントにNGINXが使用されています。
その他「Apigee NGINX」で検索するといくつか情報が見つかります。
「MuleSoft」
F5のページでも掲載していますが、NGINX OSSだけではなく有償版のNGINX Plusもご利用頂いています。
「3scale」
RedHatのブログですが、こちらもAPIトラフィックを処理する部分でNGINXをご利用頂いています。
いくつか挙げてみましたが、他のAPI Gateway製品・サービスでも実は中身はNGINXでした、というお話を聞くことがあります。
上記のようなAPI Gateway製品は、基本的には冒頭触れた図の中の「Outer API Gateway」として使われる製品となります。
OuterとInnerの役割
そもそも本記事にてAPI Gatewayを「Outer」「Inner」と分けている理由としては、GartnerのAPI Securityレポートの1つで言及されているアーキテクチャであり、アクセスコントロールの観点からそれぞれ下記のような役割を実行します。
Outer API Gateway（または Edge Gateway）
APIコールに対して、全体的な認証認可の制御を行います。例えば、あるAPIエンドポイントに対してユーザAが参照権限でアクセスできるかどうか等の認可処理を行い、必要な情報をJWT等のトークンに含め、後ろのInner API Gatewayに渡します。
Inner API Gateway（またはMicrogateways）
Outerが「全体的な」に対して、Innerは「詳細な」認可制御を行います。例えば、あるAPIエンドポイントにパラメーターが存在し、そこにユーザIDを指定して情報を取得するような動作をするとします。その際に、このユーザはこのIDを指定して情報を取得できるのか、他人のユーザIDを指定して情報を取得できるのか、といった、パラメータレベルでの細かい認可制御を行います。この認可制御に不備があると、下記のようなOWASP API TOP10のBOLAに該当する脆弱性が発生してしまいます。
上記のようなアクセスコントロール観点からの理由以外に、Outerは外部からのAPIコールを、Innerは内部アプリ同士のAPIコールを制御する、というケースもあります。
外部からのAPIコールを制御する場合、データトラフィックの制御だけでなく、例えば開発者ポータル、クウォーター管理、課金ログ等、APIサービスを実現する様々な機能が必要になります。実はこの開発者ポータル等、APIをサービスとして提供するために必要な管理系の機能がNGINXには実装されていませんが、データトラフィックを処理する機能についてはAPI Gatewayとして充分な機能が実装されています。
NGINXはAPI管理系の機能が実装されていないため、内部のアプリ同士のAPIコールを制御する部分で使われることが多くあります。内部アプリ同士のAPIコールを制御する場合、そういったAPIサービスに必要な管理機能よりも、より開発チームが使いやすい、CI/CDツール等との親和性が高く構成がシンプルなAPI Gatewayが求められているため、世の中で最も使われているWeb Server/Container/k8s IngressであるNGINXがInner API Gatewayとして使われるケースが多いのです。
もちろん、必ずしもAPI GatewayをOuter/Innerと分けなければならない、ということではありません。このアーキテクチャはGartnerが提唱する１つであり、API Gatewayは１つで構築している、というユーザも多くいます。その場合でもNGINXを採用して頂くケースもありますが、なぜNGINXなのか、という理由をもう少し見てみたいと思います。
コスト削減と性能向上
NGINXを採用する理由として、オープンソースであるため使いやすい、有償版のNGINX Plus場合は監視のためのメトリクスが豊富、OAuth/OIDCといった認証認可機能が実装されている、構成がシンプルになる、等ありますが、コスト削減と性能向上がTOP2の理由ではないか、と、実際のユーザの皆さまと話しをしていて感じます。
まずコスト削減ですが、オープンソースのNGINXであれば当然ソフトウェアのコストはかかりませんが、認証機能を開発する必要があったり、監視のためのメトリクスが少ない等、API Gatewayとして使用するためにはある程度自分達で開発する必要があります。一方で有償版のNGINX Plus場合は、API Gatewayとして有用な様々な機能が実装されています。よって、エンタープライズグレードのAPI Gatewayを構築する場合、自分達での開発やメンテナンスのコストを考えると、サポート付きの有償版のNGINX Plus方がコストメリットがあるケースもあります。
また、上記で紹介したAPI Gateway製品とNGINX Plusでコストを比較すると、多くの製品がトランザクション数でのライセンス体系であるのに対し、NGINX Plusの場合はトランザクション数でのライセンス体系ではないため、トランザクションが増えてもコストが増えることはありません。
結果として、NGINX PlusをInner API Gatewayとして利用して内部アプリ同士のAPIコールを制御することで、Outer API Gatewayを通るAPIコール数を削減してコストを抑えることができ、全体的なコスト削減に繋がるケースが多いのです。
もう一つは性能向上となります。NGINX自体が軽量で高速である、というメリットがあり、性能に関しては下記のように様々な記事で触れています。
API Gatewayとしての性能比較
上記記事では、KongとAmazon API Gatewayとの性能比較について記載されています。
最大で3秒近くのレイテンシーが発生するAPI Gateway製品に対し、NGINXは1.5ms未満にレイテンシーを抑えることができます。APIの場合は通常のWebアプリと比べ、レイテンシーに厳しい要件が課せられるケースが多く、NGINXでなければ対応できないケースもあります。
また更に性能に関してですが、セキュリティを適用すると遅くなる、セキュリティをとるのか性能をとるのか・・・という議論をよく耳にしますが、NGINXの場合はWAF機能をアドオンしたら遅くなる、ということはありません。
上記記事にて、クラウドWAFとの性能比較について記載されていますが、下図の通り他のWAFでは大きなレイテンシーが発生するのに対して、NGINXのWAF、NGINX App Protect WAFの場合は3ms以内にレイテンシーを抑えることができています。
NGINXがAPI Gatewayとして採用されるTOP2の理由として、コスト削減と性能向上についてお伝えしましたが、どちらも非常に重要な理由となります。API Gatewayの導入を検討されている方、今のAPI Gatewayで課題がある方は、ぜひNGINXをAPI Gatewayとして活用する方法もご検討ください
まとめ
API GatewayとしてのNGINXについてお伝えさせていただきましたが、今回の最後に、下記記事について紹介させて頂きます。NGINX PlusをAPI Gatewayとしてご採用頂いた事例となりますが、API Gatewayの構築をご検討されている方は必読の内容です。
記事の内容を簡単に説明すると、「API Gatewayの夢と本当に必要だったもの」というタイトルの通り、実際の現場ではAPI Gatewayにどんな機能を求めていたのか、なぜNGINX PlusがAPI Gatewayに適していたのか、について触れられています。API Gatewayの構築に限らず全般的にそうですが、ある程度検討が進んでしまうと後戻りすることが難しくなります。後戻りの事態を避けるためにも、下記のコメントが記事の最後の方にありますが、ぜひ今一度API Gatewayに必要な機能について考えてみてください。
先人達の知恵や経験を活かし、失敗を最小限に抑えるためにも、ぜひNGINX PlusをAPI Gatewayの１つの候補としてご検討頂けますと幸いです。
