API がハッカーの理想的なターゲットである理由とは?
グローバルなデジタル経済では、アプリケーションベースのサービスを顧客、消費者、パートナー、従業員に接続するためのアプリケーション プログラミング インターフェイス (API) が必要です。 レガシー、最新、および新しいアプリケーションは、アプリケーション開発を加速し、市場投入までの時間を短縮するために、API ベースのアーキテクチャへと進化しています。 アプリケーションの機能を顧客の近くに移動して摩擦を減らすことが、分散型アーキテクチャと API ファーストの動きの起源です。
残念ながら、アプリケーション開発において API を通じて得られる効率性は、IT 企業にもたらされるリスクによって影が薄くなりつつあります。 ハッカーは、API が軽度に保護されていたり、保護されていない場合は、API を侵害するのは簡単であることを知っています。 API に安全なプラクティスが必要であることに異論を唱える人はいないでしょう。しかし、API を保護する最善の方法については業界のコンセンサスがありません。 以下は、API が通常よりも強力な保護を必要とする主な理由の一部です。
API の脆弱性はほとんど対処されていない
API の可視性とセキュリティの低さに起因する重大なセキュリティ侵害は増加しており、今後も継続すると思われます。1 組織のデジタル化に向けた競争により、適切に保護されていない API がさらに多く実稼働環境に組み込まれることになります。 多くの組織は、設計とコーディングを改善することで API の脆弱性を解決しようとしますが、一般的なアプリケーションと同じセキュリティ上の欠陥に気付くだけです。これは、一般的なアプリケーション開発者にとってセキュリティが中核的な能力ではなく、セキュリティ チームが環境内のすべてのサードパーティの相互接続を認識していない可能性があるためです。
API の拡散は驚くほど広範囲に及んでいる
API の無秩序な拡大の根本にあるのは、ガバナンスとベスト プラクティスを含む総合的な戦略の欠如です。 アジャイル アプリケーション開発では、API バージョン管理の利点を活用せずに、同じ API の複数のバージョンが作成されます。 マイクロサービスに移行すると、数十の API で構成されるアプリケーションが生まれます。
管理されていない API は、不正な API、シャドウ API、ゾンビ API を作成します。 API は 2030 年までに 20 億に近づき、問題はさらに悪化するでしょう。2
API ゲートウェイは複雑なエコシステム内の API を保護するには不十分です
分散クラウド環境での運用は今日では標準となっています。 ただし、セキュリティを制御するための単一のエントリ ポイントとして専用の API ゲートウェイを使用すると、単一障害点やパフォーマンスの低下などの制限が生じます。 今日の API ゲートウェイは API インフラストラクチャの重要なコンポーネントであるため、API の普及により API ゲートウェイの導入が増加し、API ゲートウェイの無秩序な増加につながることが明らかになりました。
Web アプリケーション ファイアウォール (WAF) は API を部分的にしか保護しません
最新の WAF は、GraphQL や gRPC などの API プロトコルに対して強力な保護とセキュリティを提供し、重大なソフトウェアの脆弱性に対する一時的な対策を提供しますが、ハイブリッドおよびマルチクラウド アーキテクチャ全体にわたる高度な脅威を検出するために必要な API の観測性を提供しないことがよくあります。 多くの WAF には、動的な API 検出、自動検出と脅威の軽減、テスト、OpenAPI ドキュメント仕様の自動化と適用の機能が欠けています。
ハッカーが API を好む理由がわかったところで、どうすれば API を保護できるでしょうか?
規制と標準を活用して API 保護プロジェクトのサポートを獲得する
規制当局は API によってもたらされるリスクに注目し、第三者を含む IT 企業全体でリスクを軽減するよう企業に奨励しています。 米国 財務省と消費者金融保護局 (CFPB) は、API を保護する必要がある準拠組織に対して強力なガイダンスを発行しました。 標準の観点から見ると、PCI DSS v4 要件 6.3.2 では API セキュリティが要求されており、2007 年以降の NIST 800-95 セキュア Web サービス ガイドの推奨事項と、マイクロサービス ベースのアプリケーション システムの 800-24 セキュリティ戦略では、セキュアな API 管理が指定されています。
アーキテクチャに焦点を当てる
API セキュリティ アーキテクチャでは、マルチクラウド、地域エッジ、サービス層などの分散 IT エンタープライズとの統合を考慮する必要があります。 ソリューションは、あらゆるハードウェア、仮想化環境、Docker、Kubernetes などに展開可能である必要があります。 ソリューションでは、セキュリティ ポリシーがエコシステム全体を通じて API に準拠できるようにする必要があります。 以下は、API を保護するためのリファレンス アーキテクチャの例です。
最後に
ハッカーは、API が、認証や承認の制御が弱いなど、Web アプリケーションと同じセキュリティ上の問題を抱えていることを長い間認識してきました。 攻撃者は、API の脆弱性を悪用し、ビジネス ロジックを悪用し、ゼロデイ エクスプロイトを作成して、ほとんど抵抗を受けずに IT 企業にアクセスすることに長けています。
個人データは、アプリケーションやサービスプロバイダーの所有物ではなく、個人の所有物です。 デジタル経済はオープンなデータ共有を促進します。 API により、プライベート、パブリック、パートナー、サードパーティのデータとサービスが有効になります。 データ プライバシー規制に準拠するには、API にプライバシー保護テクノロジを適用する必要があります。
API セキュリティ ソリューションを導入するには、インフラストラクチャの統合とコネクタが必要であり、IT 資産に適切に導入するにはいくつかのカスタマイズが必要です。 展開の複雑さを理解するには、アーキテクチャ計画が必要です。 既存の IT エンタープライズ アーキテクチャ内ですぐに使用できるソリューションを選択すると、展開時間が短縮されます。
API 攻撃に対する防御について詳しくは、F5 の委託による最近のレポート「API セキュリティ ソリューション評価ガイド」をご覧ください。 このレポートでは、API 保護ソリューションを選択する際の最も重要な考慮事項について説明します。
著者: Tari Schreider、C|CISO、CRISC – Datos Insights 戦略アドバイザー