モノリシックシステムからマイクロサービスへの移行に伴って、アプリケーションは以前よりも早く開発されるようになりました。競争力を維持するためにはスピードが必要であり、APIはこのような迅速なモダナイゼーションの先頭に立ちます。しかし、アプリケーションのモダナイゼーションのためのAPIが普及することはアプリケーションセキュリティにとって重要な意味を持ちます。APIは脆弱な攻撃対象であり、アプリケーションのロジックや機密データを他のアプリケーションにさらす可能性が有ります。APIの利用が増加するほど、APIゲートウェイの必要性も高まります。
F5の2021 State of Application Strategy Reportによると、組織はモダナイズのために様々な方法を用いており、APIに関する主要なモダナイゼーションの取り組みは以下でした。
- モダンなユーザーインタフェースを利用できるようにするために58%がAPIのレイヤーを追加
- 51%がモダンアプリケーションのコンポーネントを追加 (例: Kubernetes)
- 47％がリファクタリングを実施 (アプリケーションのコードを更新)
- 40％がモダナイゼーションせずにパブリッククラウドへの移行を実施(リフト＆シフト)
組織が大きくなるに従い、API ゲートウェイを導入することがAPIに関連するリスクの緩和につながります。F5の2022 State of Application Strategy Reportで、API Gatewayはエッジやその近辺で最高のパフォーマンスを発揮することがわかりました。ここで、APIゲートウェイはネットワーク全体に影響が波及する前に攻撃を阻止し、複数のAPIに均一かつ一貫した保護を提供することができます。APIゲートウェイはアプリケーションの内部構造をカプセル化し、クライアントとAPIの間の通信を効率化します。特別なサービスを呼び出すのではなく、クライアントは単にAPIゲートウェイに接続するだけです。これによりクライアントに特定のAPIを提供し、クライアントとAPI間のラウンドトリップ数を減らし、クライアントコードを簡素化できます。
F5 NGINXのお客様は分散環境におけるAPIゲートウェイの導入に成功しています。しかし、もしAPIゲートウェイが安全でなければ、攻撃者が侵入する可能性がでてきます。NGINXでは、変化し続ける環境の中で、APIゲートウェイの背後にあるアプリケーションをセキュアにするための強力なツールを用意しています。
APIの増加に伴い攻撃対象も増加
APIは新しいものではありません。WebベースのAPIは1990年代にさかのぼり、今日私たちが知るインターネット以前の小さく分散したネットワークの間の通信でも利用されたAPIのバージョンがありました。我々が今見ている状況、この仕組みを変えたもの、それはAPIを使ったモダンなアーキテクチャです。
APIがモダナイゼーションを加速するのに重要な役割を果たすのと同時に、その悪用もより簡単にできるようになりました。マイクロサービスアーキテクチャでは単一のAPIは数百ものエンドポイントを持つことがあり、あるアプリケーションは、互いにAPIで接続する多くのマイクロサービスから構成されることがあります。単一のエントリポイントをセキュアにすれば良かったかつてのモノリシックなアプリケーションとは異なります。各マイクロサービスは複数のAPIエンドポイントを公開するため、潜在的な攻撃対象は10倍にもなっています。
F5の2022年のレポートでは、多くの組織は200-1000のアプリケーションを持っており、77%が複数のクラウドで動作していることが報告されています。分散環境におけるアプリケーションやAPIが増加すると攻撃対象は増加する可能性が有ります。
OWASP API Security Top 10 脆弱性
特徴的なのはAPIがオープンであり、機密データを公開する可能性が有ることです。Open Web Application Security Project (OWASP)は、OWASP API Security Top 10 project で一般的な脆弱性を取り上げています。
API2. ユーザー認証の不備
API3. データの過剰な公開
API4. リソース不足とレート制限
API5. 機能レベルの認可の不備
API6. 一括割り当て
API7. セキュリティの設定ミス
API8. インジェクション
API9. 不適切な資産管理
API10. 不十分なロギングとモニタリング
今日のビジネスでは開発サイクルを促進するために、機敏さとスピードが求められます。API駆動形の環境におけるこれらの脆弱性に対するセキュリティソリューションは、適応性が有り、軽量でAPIの自動展開プロセスの一部として組み込まれる必要があります。
APIセキュリティをF5 NGINX Plusで始める
APIを使った攻撃は定期的に話題になります。2019年ライドシェア会社のUberがAPIで重大なバグを見つけました。脆弱なAPIエンドポイントは、乗客の認証トークンを含む重要なデータを攻撃者が盗める状態になっていました。幸いなことにこのバグは被害が出る前に発見されました。2021年のLinkedInは不幸でした。 APIの脆弱性のため、攻撃者は7億以上のLinkedInのユーザー情報を盗み、ダークWebに売りに出しました。
F5 NGINX PlusをAPIゲートウェイとして導入することで、APIのルーティングと配信を処理する際に高いパフォーマンスを提供する迅速なAPI環境を実現することができます。独立系調査分析会社のGigaOmがNGINXを他のAPI Gatewayソリューションと比較してベンチマークを行いました。ベンチマークの結果は、NGINXが秒間30,000リクエストを30ms以内のレイテンシで処理できており、これはハイパースケーラーのAPIゲートウェイの1000倍小さいレイテンシです。
NGINX Plusは、OWASP API脆弱性だけでなく、不正なCookie、JSON、XMLのチェック、ファイルタイプや、レスポンスのステータスコードの検証など追加のセキュリティ機能もすぐに利用できます。HTTPのRFCに準拠していることも確認でき、攻撃をマスクするために使われる回避テクニックも検知することができます。
NGINX PlusはAPIリクエストを迅速にルーティングし、APIクライアントの認証認可を行うことでAPIのセキュリティを確保し、レート制限をかけることでAPIベースのサービスを過負荷から保護します。これらのツールはOWASP API Security Top 10脆弱性からAPIを保護します:
- 認証と認可のメカニズム適切なアクセス権限を持つクライアントのみがAPIを利用できるようにします。その一つがJSON Web Tokens (JWT)による仕組みです。これは、OWASP API セキュリティ トップ10の複数の脆弱性に対応します。: オブジェクト・レベル認可の不備 (API1)、ユーザー認証の不備 (API2)、機能レベルの認可の不備 (API5)、不十分なロギングとモニタリング (API10)
- レート制限のポリシー – APIゲートウェイが定義された時間内にAPIクライアントからのリクエストを受ける数を制限することにより、APIを過負荷から保護し、DDoS攻撃を緩和します。NGINX Plusでは、ソースごとにレート制限を指定できるため (例えば、JWT Claimの値に基づいて)、有効なユーザーには影響はありません。これは、リソース不足とレート制限 (API4)に対応します。
APIをF5 NGINX App Protect WAFで防御する
APIゲートウェイをF5 NGINX App Protect WAFで保護することで追加のAPIセキュリティを提供でき、インジェクション (API8)のようなOWASP で示された攻撃に対しても対策できます。OWASP API Protectionで示される最低限の機能しか持たない他のAPIゲートウェイや管理プロバイダーとは異なり、NGINX App Protect WAFはリモートコード実行(RCE)やクロスサイトスクリプティング(XSS)等の脆弱性や他の攻撃ベクターのような追加の保護機能を提供します。NGINX App Protect WAFは不十分なロギングとモニタリング (API10)に対して必要となる攻撃の可視化も提供します。ログに記録された攻撃の詳細は、追加の解析のために、Security Information and Event Management (SIEM)のシステムやお客様が利用するデータレイクに送ることができます。
もしNGINX PlusをAPIゲートウェイとロードバランサー(外部の開発者やパートナー向けにインターネットに公開する必要のあるAPIのルーティングのために)を利用しているのであれば、NGINX App Protect WAFを導入するのが最適になります。APIトラフィックのホップが一つ減ることにより最小限の複雑さとレイテンシで保護を追加することができます。
特定の業界で機密データ(Personally Identifying Information: 個人を特定できる情報: PII)を扱うためのPCIコンプライアンスの要求では、ペイロードはオープンでパブリックなネットワークではエンドツーエンドで暗号化されていなければなりません。NGINX App Protect WAFをAPIゲートウェイとしてロードバランサーやCDNの後ろに設置すると、ペイロードはAPIゲートウェイで復号されるまで完全に暗号化されています。このようにしてAPIを保護しながら機密データを扱う時の要求を満たします。
F5 NGINX App Protect WAFを用いたマルチレイヤ保護
ロードバランサーやその上にF5 Advanced WAFのようなWAFをもっていると思います。これらの後ろにAPIゲートウェイを導入します。ロードバランサー上にWAFがあるのになぜAPIゲートウェイ上にもWAFが必要になるのでしょうか。
エッジ側のロードバランサーとWAFの組み合わせから内部環境のAPIゲートウェイとWAFの組み合わせに移行することの主なメリットは、セキュリティに対してより厳密できめ細かい制御ができることです。セキュリティの責任をAPIチームに委ねて、よりAPIに特化したポリシーにすることができます。
2階層の構造により、最速のAPI開発及びリリースサイクルにおいてもAPIを確実に保護します。
OpenAPIスキーマ検証による積極的なセキュリティの追加
APIに特化した保護が必要な重要な分野はSwaggerのOpenAPI仕様による検証です。OpenAPIのスキーマは各APIで固有であり、APIバージョンごとに変更されます。OpenAPIスキーマをベースにしたAPIの保護は他のAPIやアプリケーションの予期しない影響を避けるためのテストや許可を必要とするようなITチームの管理する集中型のWAFによるセキュリティコントロールの更新を待つことはできません。
NGINX App Protect WAFはOpenAPIスキーマを検証でき、リクエストがAPIをサポートしていること (メソッド、エンドポイント、パラメータ等)に準拠していることを確認できます。このことにより、ロードバランサー上の中央集中型WAFの後ろにNGINX App Protect WAF がAPIゲートウェイに積極的なセキュリティを提供することが理想的です。
API導入に対応した“Security as Code”
CI/CDパイプラインはセキュリティではなく、スピードのために構築されます。APIはかつてのアプリケーションに比べてより頻繁に公開されています。これが、APIドリブンの環境でシフトレフトの動きが起こっている理由です。シフトレフトやアプリケーション開発のライフサイクルでセキュリティの管理を早く適用することにより、DevOpsはセキュリティもコードとして扱おうとするDevSecOpsに向かっています。
WAFをAPIゲートウェイかロードバランサーか両方に配置する場合でもAPIバージョンの変更に対応するために、WAFの構成は自動的に設定される必要があります。組織がシフトレフトのカルチャーを適用してCI/CDパイプラインの中に”Security as code”を統合すると、セキュリティを後付けするのではなく、アプリケーションとAPIの開発の各段階でセキュリティを構築できるようになります。
セキュリティポリシーや設定がコードとして扱われることで多くの利点があります。
- コードはソースコードレポジトリから簡単に引き出すことができます。
- SecOpsチームはビジネスを保護するために必要な制御を可能とする宣言的なセキュリティポリシーを作成、管理できます。
- 宣言的ポリシーは、新しいアプリケーションとAPIの中に繰り返してコード化できます。
- セキュリティはCI/CDパイプラインの中で自動化されます。
APIスキーマを自動化するとき、ファイルの中の設定とコードをアップデートする必要があります。繰り返しですが、自動化が鍵になります。シフトレフトや”セキュリティファースト”の哲学が完全に適用されたら、開発者がリポジトリからコードを簡単に取得できるようになり、俊敏性の維持、速度の向上、市場投入までの時間の短縮が可能になります。
APIを高パフォーマンスで保護
APIを保護するWAFをどこに配置するかにかかわらず、高パフォーマンスと低レイテンシは豊かな顧客体験のためにAPIが迅速に対応することを可能とするのに必要な要件です。NGINX App Protect WAFの軽量なアーキテクチャはこの高パフォーマンスと低レイテンシをクラウド上で極めて低いコンピューティングリソースで提供します。
High-Performance Application Security Testing Reportの中で、GigaOmはNGINX App Protect WAFとAWS WAFとAzure WAFとオープンソースのModSecurityのWAFでパフォーマンステストを行いました。GigaOmは、NGINX App Protect WAFがNGINX上のModSecurity OSS WAFに比べて4.7倍、低レイテンシであり、高いパフォーマンスを必要とするアプリケーションでAWS WAFに比べて128倍低レイテンシであることを示しました。
NGINXはNGINX APIゲートウェイの中にWAFを埋め込める唯一のベンダーで、結果として、APIトラフィックのホップを1つ少なくすることができます。レイヤー間のホップが少ないことでレイテンシ、複雑さ、障害ポイントを減らすことができます。これはWAFを統合していない一般的なAPI管理ソリューション(WAFを別途導入し、設定を行い、その後APIトラフィックはWAFとAPI ゲートウェイのそれぞれを通過する)とは全く対照的です。NGINXの緊密な統合はセキュリティを妥協することなく高いパフォーマンスを実現します。
まとめ
NGINXでは、NGINXとNGINX App Protect WAFで強力なセキュリティを提供します。NGINXの軽量なスケーラビリティとF5のAdvanced WAFエンジンの堅牢性により、モダンなアプリケーションの安全性に確信をもってAPIドリブンの世界に入ることができます。
NGINXのコアバリューと同等にNGINX App Protect WAFはプラットフォームに依存しない最新のアプリケーションソフトウェアのセキュリティソリューションで、フリクションを排除してセキュリティの導入を加速させる一般的なDevOpsのツールチェインとシームレスに統合します。宣言型の設定の特性としてセキュリティはCI/CDパイプラインとSoftware Development Life Cycle (SDLC) 全体を自動化することができます。これは、リリースの速度を上げるだけではなく、組織が信頼性の高い保護されたAPIを構築し、DevOpsとSecOpsの間のギャップを埋めて、DevSecOpsへの文化的な転換を可能にします。
NGINX App Protect WAFを試したいですか？今すぐ30日間の無料トライアルをお試しいただけます。お客様のユースケースにつきましてはF5までお問い合わせ下さい。
