banner
ホームページ / ブログ / API セキュリティが誰にとっても重要な理由
ブログ

API セキュリティが誰にとっても重要な理由

Aug 20, 2023Aug 20, 2023

地球上には、コンピューターが情報を交換するために使用するメカニズムであり、すべてのソフトウェアの構成要素である API が溢れています。 企業は、内部で使用するため、または顧客が自社のシステムと対話できるようにするために、独自の API を構築します。 API を使用して、エクストラネット内やクラウド全体でパートナーと通信します。 たとえば、Google マップを表示したり、フォームで郵便番号検索テーブルを使用したりするために、サードパーティ API を使用して既製の機能にアクセスします。

モバイル、Web、クラウド アプリケーションの急増に伴い、API の数は急激に増加しています。 いくつかの業界統計:

当然のことながら、API は重要かつ急速に成長している攻撃ベクトルでもあります。 Gartner によると、「API の爆発的な増加により、組織の攻撃対象領域が拡大し、悪意のある攻撃者に新たな侵害やデータ漏洩の機会が与えられています。」

視点によっては、使用されている API の約 50% が管理されていないことは、非常に驚​​くべきことであるか、それほど驚くべきことではないことになります。

それらは明らかに増大するリスクをもたらしているので、驚くべきことです。 API の使用の爆発的な増加は、リスクに対する認識の欠如によってさらに悪化しており、また API の管理が難しいため、これは驚くべきことではありません。 開発者は、以前の API をわざわざ削除せずに、新しい API や新しいバージョンを頻繁に公開します。 サイバースペースにはゾンビ API が散乱しており、バックエンド システムとデータが公開されていますが、監視されておらず、ビジネス価値は提供されていません。

拡大を続ける攻撃対象領域、パトロールが不十分な状況。これはハッカーの夢の実現です。

Gartner の警告は、API セキュリティの明白なリスクの 1 つを強調しています。つまり、API は多くの機密トラフィックの交差点です。 銀行アプリや e コマース アプリでは、顧客の口座詳細やクレジット カード番号が含まれる場合があります。 しかし、API は企業 (およびその顧客) のデータだけでなく、サービスの背後にあるビジネス ロジックも公開します。 ビジネス ロジックの弱点により、重大な損失が発生する前に検出されない可能性が高い攻撃を開始する新しい方法がハッカーに提供されます。

たとえば、私たちは為替取引で非常に少額を切り上げるルーチンを使用している銀行でいくつかの作業を行いました。 このアルゴリズムは、わずか 1 セントの差を意味するため、通常の取引では重要ではありませんでした。 しかし、このシステムは 1 人の顧客が 1 日に実行できるトランザクションの数に制限を設けておらず、フロントエンド制御をバイパスしてビジネス ロジックを直接攻撃することで、攻撃者が許可するような小規模なトランザクションを多数実行することができました。四捨五入機能を使用して自分の口座にお金を印刷します。 仮想通貨業界の顧客についても同様の結果が得られており、API ビジネス ロジックを悪用することで仮想通貨を盗むこともできました。

もちろん、銀行には最終的にこの問題を警告する管理機能があったが、危険信号が出る前に数百万ドル相当の異常な取引が行われていた可能性があることは認めた。 この例は、API セキュリティのいくつかの重要な原則を示しています。 最も有用な API は公開されています。 それらは使用されることを目的としています。 彼らの仕事を妨げずに、それらを非表示にしたり、アクセスを困難にしたりすることはできません。

侵入テストなどの技術は役に立ちますが、侵入テストですらその時点での演習にすぎず、テスターは提供された範囲を評価するだけです。 API の盲点がある企業は、API のスコープを設定する方法がわかりません。また、ほとんどのペネトレーション テスターはビジネス ロジックのテストを求められないか、有能な API 攻撃者がアクセスで何を行うかを評価するための API 固有のスキル セットを欠いています。 。

2 番目の教訓は、API ライフサイクルの一部だけに焦点を当てるのは意味がないということです。 シフトレフトの原則は、設計とコーディングの時点でセキュリティを組み込むことに重点を置いているのは当然ですが、コードの運用ライフサイクルも同様に重要です。 状況は変わります。 元のコードは別の開発者によって微調整されています。 ドキュメントが貧弱であるか、存在しません。 ビジネスはプレッシャーにさらされています。 アップデートは完全にテストされていない可能性があります。 たとえ開発とテストが完璧で、改訂が細心の注意を払っていたとしても、元の設計に欠けていた何かが戻ってきて悩まされる可能性があります。 左にシフトするのはそうだが、自分の危険を直視するのはやめよう。