T-Mobile の侵害から学んだ教訓 (これまでのところ)

T-Mobile による最近のデータ侵害の開示は、アプリケーション セキュリティの急成長する「無法地帯」である API の課題を浮き彫りにしています。 ある個人（またはグループ）が、API の使用（または悪用）を通じて 3,000 万人を超える顧客の個人データを収集し、発覚するまでに 1 か月以上にわたって毎日情報を抜き出していました。

本稿執筆時点では、今回のケースで API がなぜ、どのように悪用されたのか (機能の悪用、オブジェクト レベルの認証の破損、過剰なデータ漏洩など)、また侵害が最終的にどのように認識されたかについては、具体的なことはあまりわかっていません。 数字だけを調べてみると、レート制限しきい値や時系列の動作異常などをトリガーすることなく、平均して 1 日あたり 902,000 人の顧客データがこの API 経由で削除されました。 あるいは、そうであったとしても、迅速に特定して運用チームが緩和措置を講じるには適切な脅威レベルではなかった、つまり、低速でゆっくりとした攻撃の特徴を備えているのかもしれません。

このような侵害は、API がいかに普及しているか、今日の組織にとっていかに重要であるか、そして、あらゆるアプリケーション、ひいては組織全体のセキュリティ (または非セキュリティ) において API が果たす独自の役割について考える機会を与えてくれます。 F5 Labs は近年の侵害の分析で、API に関連するインシデントのほとんどのシナリオにおいて、侵害の方法が技術的に非常に単純であり、公開されているセキュリティが不十分な API エンドポイントに影響を与えることに気づきました。

API に関して言えば、セキュリティは言うほど簡単ではありません (少なくとも適切に行うのは困難です)。 最近では、ほとんどの組織で監視されているアプリケーションやエンドポイントの数が増え、アプリケーション セキュリティ イベント データが大量に生成されるようになり、すべてを把握するのは不可能な作業のように思われます。

ただし、この攻撃によって特に浮き彫りになった API セキュリティに関する 3 つの中核的な要素は、組織がテクノロジーとサービスの優先順位付けを行う際に参考にできるものです。

API の可視性と検出。 この場合、この特定の API が既知であったか、または積極的に監視されていたかどうかは明らかではありません。 スキーマ強制機能を備えた、安全に開発され、十分に文書化された API に依存するポジティブ セキュリティは重要ですが、方程式の半分にすぎません。 ほとんどの組織では、環境内で実行されているすべての API を把握していない可能性が高いため、アプリケーションのすべての通信パスにわたってまだ文書化されていない API を継続的に学習してマッピングできることが最も重要です。 検出テクノロジーにより、組織は API ランドスケープ全体をマッピングし、不明/シャドー API、ブロック/削除する放棄された API またはゾンビ API、ガバナンスのために検討する必要がある未知の「適切な」 API を公開して、より包括的な監視を行うことができます。

API が存在することを知ることとアクセス制御機能を持つことは、API セキュリティ パズルの 2 つの重要な要素です。 2022 年のアプリケーション戦略の現状レポートでは、回答者の 68% が認証と認可を API セキュリティの最も重要なコンポーネントとしてランク付けしました。それに続いて、API を監視して異常な動作や潜在的な不正使用を特定して警告する動作分析と異常検出がランク付けされています。これは、悪意のあるユーザーが認証と認可を簡単に回避する方法が多数あるためです。 このシナリオでは、API とクライアント間で渡されるデータに何か異常があったに違いありません。 運用開始後に API の動作を経時的に追跡できるようにするには、通常、API リクエスト分析と時系列異常検出が含まれ、リクエスト レート、エラー、レイテンシ、スループットなどの異常を識別するために使用されるベースライン動作属性を構築します。 この機能では、予期しない急増や急減が発生したり、固有のトラフィック パターンが存在したり、異常な API 要求が検出されたりした場合に問題を通知するためのアラート要素が重要になります。

最新の API セキュリティ スタックを完成させるには、インライン アプリケーションと API セキュリティ強制エンジンが必要です。これには、レート制限、IP レピュテーション、許可/拒否リスト機能を備えたきめ細かい L7 ポリシー強制、悪意のあるエンドポイント、ユーザー、その他のアクティビティをさらに調査して対処する機能を備えた L7 DoS など、複数層のアプリケーション セキュリティ機能を備えた WAF が含まれる可能性が最も高くなります。 これにより、運用チームは異常が検出されると、API の不正使用の疑いを迅速かつ簡単に特定し、その不正使用を阻止するポリシーを作成できるため、時間の経過とともに API とアプリのエンドポイントが進化し、動作が変化するにつれて、より適切に保護できるようになります。

時間が経つにつれて、この特定の侵害で実際に何が起こったのかが明らかになり、さらに多くのことが明らかになるでしょう。しかし、組織がこれら 3 つの要素を活用して、アプリと API エンドポイントをこのような不正使用から保護するための計画を評価し、より適切に策定することが重要です。