API ゲートウェイと API プロテクション:違いを理解して協調させるには?

API Gateway Security – What kind of security do API gateways offer?

2022/01/13 SecurityBoulevard — API は、最新のアプリケーションを構成する重要な要素であると同時に、企業の攻撃対象として最も急増している要素の1つでもある。当然のことながら、企業は、これらの資産が適切に管理され、プロビジョニングされ、脅威や攻撃者から保護されていることを確認する必要がある。API プロテクション・ソリューションと API ゲートウェイは、どちらも、この点で重要な役割を果たしており、場合によっては重複した機能を持つこともある。しかし、それは互換性があるということではなく、それぞれの技術を使用すべき場所とタイミングを正確に知ることで、余計な混乱を招く恐れもある。

ここでは、API スレット・プロテクションと API ゲートウェイのそれぞれの強みと、全体的な API セキュリティ戦略の一環として、どのように連携させるべきかを考えていこう。

API ゲートウェイ・セキュリティと API スレット・プロテクションの機能を比較

API スレット・プロテクションと API ゲートウェイには、いくつかの類似点があり、いくつかの重複する機能があるかもしれない。たとえば、どちらも一般的には API の前の入口地点に配備され、認証の制御/監視において重要な役割を果たす。

しかし、両者の主な目的や視点は大きく異なる。一言で言うなら、API スレット・プロテクションは、リスクのある行動や攻撃に焦点を当てる。その一方で、API ゲートウェイは、API を適切に稼働させるための運用面で優れている。次の図は、これらの違いを浮き彫りにしている。


たとえば、API ゲートウェイは、アクセス制御/RESTful リクエストの SOAP への変換/API にアクセスするトラフィックが急増した場合の弾力的なリソース・スケーリングなどの、さまざまな運用タスクをカバーしている。

その一方で、API スレット・プロテクションは、API における攻撃対象を理解し、増え続ける最新の API 脅威を検出/ブロックし、攻撃者が検出を回避するために使用する技術の変化に対応することに重点を置いている。進化する脅威に対応するためには、相当な専門知識と集中力が必要となる。

API ゲートウェイ・セキュリティ機能

  • 認証と暗号化
  • 速度制限
  • トランザクションロギング
  • ランタイムガバナンスポリシー

API スレット・プロテクション機能

  • API ディスカバリー
  • 攻撃対象の可視化
  • API スキーマのコンプライアンス
  • API 攻撃の検知と対応
  • リアルタイムの API リスク管理
  • キルチェーン分析

洗練された現代の攻撃者にフォーカスする API スレット・プロテクション

現代の脅威をめぐる状況は、信じられないほど多様であり、洗練されている。攻撃者たちは忍耐強く、従来のセキュリティ・シグネチャやレート・ベースのルールを回避することに長けている。時代遅れの WAF シグネチャを API ゲートウェイに貼り付けるだけでは、これらの攻撃者を退けることはほとんど不可能であり、価値よりも苦痛を感じることが多くなる。このようなシグネチャは、誤検知率が高く、常にチューニングやアップデートが必要なため、長年にわたってアプリケーションとセキュリティのチームを悩ませてきた。

攻撃者は、ボットや悪意の自動化を利用して、通常のユーザー・トラフィックに紛れ込に、アプリケーションの機能を悪用し、攻撃の本質を隠蔽する。攻撃者の多くは、レートベースのルールのしきい値を下回るようにしながら、防御の弱点を着実に探し、時間をかけて攻撃を展開することだろうが。

ThreatX の API プロテクション・ソリューションは、このような最新の脅威を発見し、阻止することを目的として構築されている。ThreatX は、従来の OWASP インジェクション攻撃やエクスプロイトをブロックするだけでなく、アプリケーションの行動分析/攻撃者のフィンガープリント/攻撃者の行動分析/アクティブな尋問/詐欺行為などに対抗するための、業界で最高の分析/防御テクノロジーを結集している。それにより、ThreatX は全てのイベントを多面的に捉え、イベントが良性/悪性について真の姿を把握できる。

また、ThreatX は、キルチェーンの複数のフェーズで、時間をかけて攻撃者を追跡する。ThreatX は独自の技術を用いて、攻撃者が IP アドレスやユーザー・エージェントなどを変更しても、フィンガープリントを作成して追跡する。また、すべての攻撃フェーズでインテリジェンスが自動的に相関し、統合された最新のリスク情報を提供する。これにより、セキュリティ・チームは、低レベルの攻撃や低速の攻撃に対しても、事前に準備したアクションを、適切なタイミングで実施できる。

高度な API 保護には、マルチ・クラウドのカバーとコンテキストが必要

API セキュリティは極めて重要であるため、API やクラウド・インフラのプロバイダーは、API を提供するだけでなく、何らかの形でセキュリティも提供する必要がある。しかし、このような「その場しのぎ」のセキュリティ対策では、必要な専門知識が不足しているだけではなく、攻撃対象の幅も狭く定義してしまう。この問題は、企業が利用する API プロバイダーが変わるたびに深刻化していく。ハイブリッド/マルチ・クラウド戦略は急速に標準化されつつあり、それぞれのクラウド・プロバイダーは独自の API プロテクションを持っている。Amazon のゲートウェイは、Google のゲートウェイと異なる機能を持っており、どちらも相手のコンテキストを把握していない。企業がマルチクラウド・アーキテクチャを採用し続けると、それぞれのプロバイダーによる独自ソリューションが堆積していく。

企業のセキュリティ戦略は、従来からの Web 資産と同様に API 資産を取り扱い、すべての API インフラを接続/サポートする必要がある。それは、各種のサービスやマイクロサービスについても同様だ。セキュリティは、攻撃者に焦点を当て、ある分野で弱点を探索していた攻撃グループが、別の分野でも探索しているなら、そのことを認識する必要がある。

現代の攻撃を撃退するためには、このような統合的なリスクの視点が不可欠となる。昔から言われていることだが、セキュリティは最も弱い部分でしか成り立たない。それが、現在の API における顕著な傾向である。この重要テクノロジーは、最新のアプリケーションにとって不可欠なものであり、アプリケーション・セキュリティにとって不可欠な部分として扱う必要がある。変化し続ける脅威に対応するためには、継続的な努力と専門知識を備えたセキュリティが必要である。また、どこに、どのように配置されているかに関わらず、一貫した保護が必要である。また、組織におけるセキュリティ・ツールの、総合的なインテリジェンスとコンテキストの恩恵を受ける必要がある。

API のセキュリティというと真っ先に思い出すのが、2021年10月の「OWASP API Top-10: API を脅かす脆弱性を分析して対策を講じる」です。その Top-10 の内訳は、以下のようになっています・・・

API #1: Broken Object-Level Authorization (オブジェクト・レベル認証の失敗)
API #2: Broken User Authentication (壊れたユーザー認証)
API #3: Excessive Data Exposure (過剰なデータ露出)
API #4: Lack of Resources & Rate Limiting (リソースの不足とレートの制限)
API #5: Broken Function-Level Authorization (関数レベルの認証の失敗)
API #6: Mass Assignment (マス・アサインメント)
API #7: Security Misconfiguration (セキュリティの設定ミス)
API #8: Injection (インジェクション)
API #9: Improper Assets Management (不適切な資産管理)
API #10: Insufficient Logging & Monitoring (不十分なロギングとモニタリング)

ぜひ、ご参照ください。

%d bloggers like this: