20年以上前、ジェフ・ベゾス氏はアマゾンの全チームに例外なく「サービスインターフェースを通じてデータや機能を公開する」ことを義務付けると宣言しました。このメモ(現在では「API Mandate(API勅令)」として知られています)は、本質的にアプリケーション・プログラミング・インターフェース(API)はオプションではないと述べたものであり、それによって開発者たちは世界中でAPIを介してすべてをつなぐ競争を引き起こしました。しかし、多くの組織のAPIセキュリティはAPIの展開ペースの速さに追い付いていません。
最近の2024年APIセキュリティおよび管理レポートによると、現在のAPI関連のトラフィックは動的インターネットトラフィック全体の大半(約57%)を占めていると報告されています。しかし、企業は一般的に以下のような課題に頭を悩ませています:
目に見えない保護されていない攻撃対象領域:IT部門とセキュリティ部門は見えないものを守ることはできません。組織にはIT部門やセキュリティ部門が管理していないAPIである「シャドーAPI」が存在します。これらはデータ流出、ラテラルムーブメント、その他のサイバーリスクを引き起こす可能性があります。
過度に寛容な認可:本来は読み取り専用に設定すべきAPIに付与された「書き込み」権限が悪用されると、システムは攻撃や潜在的なデータ損失に対して脆弱な状態に陥ります。しかし、60%近くの組織が、自社APIの半分以上に「書き込み」権限を許可しています。
API関連のエラーの原因を見落としたり、誤って分類してしまうことがよくあります:すべてのAPIエラーが攻撃によって引き起こされるわけではありません。また、APIに対するすべての攻撃を同じ方法で軽減できるわけでもありません。エラーや脆弱性を見逃したり誤った診断をしてしまうと、ユーザーエクスペリエンスの低下を招き、最悪の場合、サイバー攻撃につながる恐れも生じます。
推定2億の公開・非公開APIが使われており、その数は増え続けています。これらの(そして将来の)APIの能力を安全に活用するために、組織にはAPIの管理に特化したアプローチが必要です。これには、以下の3つの「すべきこと」と「すべきでないこと」を組み込んむ必要があります。
Acme病院が、シームレスなモバイル遠隔医療からAIによる記録処理まで、患者や医療提供者が喜ぶデジタルイニシアチブを提供しているとします。ある日、Acmeの開発者の一人が、適切な文書なしに請求システムのAPIに「書き込み」権限を与えました。数か月後、このベンダーはハッキングされ、その後、攻撃者はラテラルムーブメントを通じて、Acmeの公開APIを悪用して病院の患者記録への侵入に成功しました。
Acmeに以下を自動的に行う機能があれば、もっと早くこのシナリオを自動的に検出して緩和することができたはずです:
すべての公開APIエンドポイント(認証されていないAPIを含む)と関連するトラフィックの検出
APIスキーマ(有効なAPIリクエストとレスポンスの仕様を定義するメタデータ)の検出
APIに対する攻撃バリエーションの検出
機械学習モデルを活用した、IT、セキュリティ、開発者間の手作業による「特定時点」のやり取りを必要としないAPIセキュリティソリューションを使用しましょう。
例えば、機械学習を利用したAPIディスカバリーやAPIスキーマ検出は、Acmeのような組織にAPIのより完全なインベントリ(これらのAPIがどんなものか?どのようなデータやシステムにアクセスしているのか ?いつ、どこからアクセスされているのか?誰が「読み取り専用」と「書き込み」の権限を付与されているのか?)を提供することができます。
この種のデータは、シャドウAPIの増殖を防ぐために重要です。新しい顧客機能(多くの場合、最初にインターネット向けのAPIとして公開されます)を開発する過程において、そのAPIに関するドキュメント作成とセキュリティの「ベストプラクティス」については、通常、個々の開発者の裁量に任されています。多くの場合、セキュリティチームを参加させるための十分な時間やリソースがありません。
組織は見えないものを守ることができません。ここに、セキュリティの課題が生じる理由があります。実際、Cloudflareの機械学習モデルは、組織が自己申告したよりも31%多いAPIエンドポイントを発見しました。これは、APIの約3分の1が実質的にシャドウAPIであることを示唆しています。
シャドーAPI(頻繁なコード変更の際に導入されることが多い)は、本質的に悪意があるものではありません。しかし、開発者の86%がアプリのセキュリティを最優先事項と考えていないことを考えると、シャドーAPIは最大の脅威となります。悪用された場合、データの暴露、パッチ未適用の脆弱性、データコンプライアンス違反、その他の脅威につながる可能性があります。機械学習は、これらのシャドウAPIを暗闇から引き出すのに役立ちます。
WebアプリとAPIは根本的に異なります。ライドシェアアプリはユーザーにとって「見える」ものですが、アプリがグーグルマップのデータにアクセスするためのAPIは「見えない」ものです。これらの(そして他の)違いを考慮すると、組織はAPIを保護するために、Webアプリのセキュリティだけでなく、専用に構築されたAPIセキュリティが必要です。
例えば、従来のWebアプリケーションファイアウォール(WAF)は、ブロックリストに基づいて、Webアプリケーションとインターネット間のHTTPトラフィックをフィルタリング、監視します。WAFは、既知の攻撃の兆候を探し、それらの攻撃を阻止するために行動を起こします。その他のトラフィックはすべて許可されています。この「ブラックリスト」型のセキュリティモデルは、悪意のあるWebトラフィックを特定してブロックすることが容易なWebアプリのセ キュリティに効果的です。
しかし、APIを悪用から守る(APIセキュリティ)には「ホワイトリスト」型のセキュリティが必要です。「既知の悪い」リクエストを探すのではなく、「既知の良い」リクエストを探し、それだけを通過させ、それ以外はブロックします。(API呼び出しの要求を定義する方法について詳しくはこちらを参照してください)。
その理由
あるオーストラリアの通信プロバイダーが、約1,000万人分の顧客データを流出させる情報漏えいに見舞われた例を考えてみましょう。ハッカーは認証されていないAPI経由で特定の顧客データベースにアクセスしていました。攻撃の全詳細は公開されていませんが、注目すべきは、「ホワイトリスト」型のAPIセキュリティモデルでは、同社のAPI仕様に準拠したAPIトラフィックのみが許可されていたという点です。
言い換えれば、「ホワイトリスト」型のAPIセキュリティに切り替え、認証されたユーザー、認証された企業ネットワーク、許可さ れたアクションからのトラフィックのみを許可します。(必要に応じて、WAFが提供する「ブラックリスト」型のセキュリティとAPIゲートウェイが提供する「ホワイトリスト」によるセキュリティを重ねるなどの組み合わせも可能です)。
結論:APIには、以下の6つのAPI脅威上位を含む、幅広いAPIの脅威から防御するための包括的なアプローチが必要です:
出典:2024年APIセキュリティおよび管理レポート
上のグラフから分かるように、軽減されたAPIの脅威の大部分(60.7%)はHTTP異常でした。ユーザーエージェント(エンドユーザー向けにインターネットコンテンツを取得するソフトウェア)の欠落などのHTTP異常は、悪意のあるリクエストの一般的な兆候です。
「ホワイトリスト」型のセキュリティ(前述)を適用することで、組織はHTTP異常やその他の脅威を特定し、APIサーバーに向かう各APIの「クリーン」なトラフィックのみを通過させることができます。
IT、セキュリティ、アプリ開発者はすべて、何千ものAPIがサポートする資産を持つことに伴う膨大な攻撃対象領域を保護する責任を共有しています。ですが、これらのチームの優先順位はしばしば対立します:
開発者の73%が、そのセキュリティチームが使用を要求する仕事やツールが「生産性とイノベーションに干渉している」と述べています。
CIOの87%が、ソフトウェアエンジニアと開発者が「新製品やサービスを迅速に市場に投入するためにセキュリティポリシーやコントロールを妥協している」と考えています。
CISOのわずか半分しか、開発者が「開発およびワークフローのツールのセキュリティリスクに非常に精通している」と感じていませ ん。
結果として、企業は、イノベーションの迅速化とセキュリティの向上との間で「トレードオフ」を経験することになり、APIが脆弱なまま放置される可能性があります。レポートによると、60%近くの組織がAPIの少なくとも半数に「書き込み」アクセスを許可しています。ですが、「書き込み」権限が間違ったユーザーに与えられていないことを確認する最終的な「責任者」は誰でしょうか?
API経由で新しいサービスを公開し続ける企業にとって、コネクティビティクラウドは、アプリの展開やAPIの徹底的な防御の間の接着剤的な役割を果たすことができます。
コネクティビティクラウドとは、IT環境全体におけるセキュアな「Any-to-Any」接続を簡素化する、クラウドネイティブサービスの統合プラットフォームです。これにより、企業はAPIトラフィックを含む広範なデジタルドメインのコントロール能力と可視性を取り戻すことができます。
コネクティビティクラウドを利用することで、企業は単一のコントロールプレーンを使用して、以下の取り組み(およびそれ以上)に対処することができます:
APIの発見と可視化を自動化し、すべての関係者にAPI資産の明確なインベントリを 提供する
API認証と認可プロセスを最初から近代化する
APIエンドポイントを管理し、APIドメインの遅延、エラー、エラー率、応答サイズなどのメトリクスを監視する
API技術は新しいものではありませんが、APIセキュリティに総合的に取り組むことは、多くのAppSecチームやAppDevチームにとって初めてのことです。ですが、何かを進めるには始めることが必要です。そして、APIセキュリティは段階的に取り組むことができます:
ステージ1 - 可視性:まずは、組織内で使用されているすべてのAPIを特定することから始めます 。API発見ツールの使用、技術文書や契約書の確認、開発者に話を聞く、Webトラフィックの監視、などを実施します。
ステージ 2 - 一般的なWeb攻撃からの保護:WebアプリケーションとAPIは、しばしば協力して動作します(例えば、eコマースのWebサイトが支払いを処理するためにAPIを使用するなど)。DoS攻撃やDDoS攻撃、クレデンシャルスタッフィング、zero-dayの脆弱性、その他の脅威からWebアプリ(そしてある程度はその背後にあるAPI)を保護するために設計されたツールを使用し、組み合わせて使用します。
ステージ3 - 高度なAPI セキュリティの統合:コネクティビティクラウドを活用したCloudflareのWebアプリケーションとAPIの保護(WAAP)ポートフォリオは、生産性を阻害することなく、公開API周りの総合的なセキュリティとパフォーマンスを提供します。Cloudflareは、APIの検出、APIの統合管理・分析、多層防御によって、IT部門とセキュリティ部門がAPIを可視化し制御できるようにします。
この記事は、技術関連の意思決定者に影響を及ぼす最新のトレンドとトピックについてお伝えするシリーズの一環です。
2024年APIセキュリティおよび管理レポートを入手し、最も一般的とされるAPIの脆弱性、業界の予測、APIを保護するための詳細な推奨事項について確認してください。
この記事では、以下のことがわかるようになります。
APIに関する3つの一般的課題
API管理専用ツールで「すべきこと」と「すべきでないこと」
APIセキュリティ成熟度を経時的に上げる方法