包括的な API セキュリティ戦略の 6 つの原則

仮に試したとしても、現時点では環境内のすべての API エンドポイントを識別できない可能性が非常に高いです。 残念ながら、悪意のある行為者については同じことが言えないかもしれません。 エンドポイントが存在する場合、それは侵入経路として、または重要なビジネス機能を妨害する手段として使用される可能性があります。

さらに、API を公開すると、さまざまな顧客、パートナー、アプリからのクエリを受け取ることができるようになります。 この露出により組織が侵害される可能性も高まるため、API を理解して監視することが重要です。 API がもたらす脆弱性や、侵害やダウンタイムにつながる可能性のある潜在的な脅威から組織を保護するために、考慮する必要があるリスク管理がいくつかあります。

あらゆる防御者にとって、API の検出は API を保護するための最初の重要なステップです。 言うまでもないかもしれませんが、「見えないものを守ることはできない」という言葉ほど真実なものはありません。 完全な API インベントリを持つことは、API セキュリティ体制を開発または改善するための出発点となり、API の脅威の表面全体を理解して定量化するのに役立ちます。 これは以下の基準として機能します。

• 可視性: 利用可能なすべての API をカタログ化することで、脆弱性、機密データの漏洩、許可されていないエンドポイントや忘れられたエンドポイントなど、API の脅威の状況に関する洞察が向上します。
• バージョン管理: インベントリを確立するとバージョン管理に役立ちます。API の履歴とさまざまなバージョンを把握しておくと、古くなったバージョンや脆弱なバージョンを廃止したり、適切に保護したりするのに役立ちます。
• 監視： 一元化された完全な API インベントリにより、API の使用状況をより適切に監視および記録できるようになり、疑わしいアクティビティ (異常) や潜在的なセキュリティ イベントの検出と対応が容易になります。さらに、インシデントが発生した場合には、明確なインベントリが対応に役立ちます。
• 一貫したセキュリティ制御とポリシー: 完全な API インベントリを含むこの可視性により、API 脅威サーフェス全体にわたって制御とポリシーを効果的に実装できます。

それは典型的な闘争です。 一方では、大胆に行動し、限界を押し広げ、競合他社ができないことをやろうという意欲は、あらゆる成功するビジネスの基礎となります。 しかし一方で、セキュリティを維持することは必ずしも最新のイノベーションとうまく連携できるとは限りません。

バランスをとるための鍵は次の 3 つです。

• 適切なセキュリティ制御を設定するために、API の種類ごとに API ガバナンス戦略を設計します。
• API が展開される場所に関係なく一貫して適用できる API セキュリティ ポリシーを実装します。
• AI を使用して、新たな脅威、異常な動作、APL を悪用または悪用しようとする悪意のあるユーザーに適応し、セキュリティ チームの負担を軽減します。

業界に応じてコンプライアンス基準は異なり、業界によっては他の業界よりも厳格なセキュリティが求められるものもあります。 いずれにせよ、API セキュリティ体制が、脅威ベクトルの集中攻撃に対処できるほど堅牢であることが不可欠です。

API セキュリティ テストは 1 回限りの作業ではありません。 展開前、展開中、展開後のテストは重要です。 開発のあらゆる段階にテストを組み込むことで、侵害が発生する前に弱点や脆弱性を特定する機会が大幅に増えます。 セキュリティ固有のテスト ツールは優れていますが、セキュリティ ユース ケースのモデリングも忘れないでください。

セキュリティは、アプリ自体と同じ継続的なライフサイクル内で実行される必要があり、CI/CD パイプライン、サービス プロビジョニング、イベント監視エコシステム内で緊密に統合される必要があります。

私たちに完全な栄養を与えてくれる単一の食べ物が存在しないのと同様に、API を完全に保護できる単一のセキュリティ管理は存在しません。 代わりに、総合的なアプリおよび APIセキュリティ アーキテクチャの一部として、包括的なツールのエコシステムを採用する戦略を開発する必要があります。 これには検出とインライン強制が含まれており、API の動作を制御し、望ましくないまたは悪意のあるアクティビティを制限し、機密データの公開をブロックする機能を提供します。

これには、次のような機能とツールの組み合わせが含まれる場合があります。

• APIゲートウェイ
• アプリのセキュリティ テスト (SAST および DAST)
• ウェブアプリケーションファイアウォール（WAF）
• データ損失防止 (DLP)
• ボット管理
• DDoS緩和

API ゲートウェイは堅牢なインベントリおよび管理機能を提供しますが、レート制限などの基本的なセキュリティしか提供しないため、高度な攻撃を阻止することはできません。 さらに、API の急増により、API ゲートウェイの拡大を含むツールの拡大が進んでいます。

アプリのセキュリティ テストは常に重要ですが、開発中の堅牢なapplicationセキュリティを実現するシフト レフト手法は、シールド ライトのプラクティス、つまり運用中の API エンドポイントのセキュリティ保護によって強化される必要があります。 

Webapplicationファイアウォールは、シグネチャを使用してapplicationの脆弱性の悪用を軽減するための重要な一時しのぎを提供します。 API は、サポートするapplicationsと同じ種類のインジェクション攻撃（意図しないコマンドの実行やデータへのアクセスの試み）の影響を受けます。 しかし、WAF には通常、未知の (シャドウまたはゾンビ) API や、API の動作異常、ビジネス ロジックの潜在的な悪用などの問題を継続的に検出するために必要な動的検出機能が欠けています。

機密データ検出機能とデータ損失防止機能は、個人を特定できる情報 (PII) や財務情報などの機密性の高い重要なデータを検出してマスキングすることで、API と API がアクセスおよび送信するデータを保護するのに役立ちます。 これにより、組織はデータ保護ルールを作成してデータ転送を制限またはマスクし、API エンドポイントによるデータ公開を完全にブロックできるため、API 経由のデータ漏洩を防ぐことができます。

API のボット管理では、多要素認証 (MFA) や CAPTCHA などの一般的に使用されているセキュリティ制御に依存することはできません。これは、API トラフィックは通常、マシン間で行われ、API ベースのシステムへのユーザー インターフェイス内を除いて、人間による直接的なやり取りがないためです。 

従来の DDoS 緩和策はネットワーク攻撃とボリューム攻撃に重点を置いていますが、API は重要なビジネス ロジックを悪用する標的型レイヤー 7 攻撃の対象となる可能性があります。 最終結果は同じで、パフォーマンスが低下し、ダウンタイムが発生する可能性があります。

動的 API 検出、スキーマの適用 (ポジティブ セキュリティ)、アクセス制御、機械学習に基づく自動異常検出と保護は、API を防御するための重要なエコシステム機能として登場しました。 API プロトコルに精通し、適切な API 動作の強制と API 保護ルールの作成を可能にするツールを 1 つまたは複数用意することが重要です。 組織は、API と API の動作を具体的に管理するカスタム ルールを作成できる必要があります。 これには、許可リストと拒否リストの制御、レート制限、地理 IP フィルタリング、機密データのマスキング、特定の API エンドポイントまたはグループの一致および要求制約基準を含む API 要求を処理するカスタム ルールの作成が含まれます。

API の急増により、ハイブリッドおよびマルチクラウド環境全体で、耐え難いほどのアーキテクチャの無秩序な拡散が進んでいます。 また、多くのセキュリティ ツールがデータ センター、プライベート/パブリック クラウド、エッジなどの複数のアーキテクチャにわたって一貫したセキュリティを提供できないため、API の無秩序な増加によって API ゲートウェイの無秩序な増加が発生しています。 デジタル エコシステム全体にわたる API トラフィックの可視性と制御は、次の重大な脆弱性を軽減し、エンドポイントが異なるクラウド プロバイダーに分散されている場合に発生する可能性のある誤った構成を防ぐために不可欠です。