API セキュリティは一般的なアプリケーション セキュリティとどう違うのですか?

公開: 2023-07-19

同じものとして混同されることがありますが、アプリケーション セキュリティと API セキュリティは 2 つの異なる分野です。 アプリケーション セキュリティはアプリケーション全体のセキュリティを確保することを指しますが、API セキュリティは組織がアプリケーションの接続やデータ交換に使用する API のセキュリティを確保することを指します。 したがって、組織は 2 つの分野に対して異なるアプローチを取る必要があります。

アプリケーションのセキュリティとは何ですか?

アプリケーション セキュリティ (AppSec) は、承認、暗号化、安全なコーディング手法を使用して、データとシステムをサイバー攻撃から保護します。 AppSec を導入している組織は、データ侵害のリスクを軽減し、機密データを保護し、アプリケーションが業界標準に準拠していることを保証します。

ISACA は、AppSec プログラムの 5 つの重要なコンポーネントを次のように定義しています。

  1. 設計によるセキュリティ
  2. 安全なコードのテスト
  3. ソフトウェア部品表
  4. セキュリティのトレーニングと意識向上
  5. WAF と API セキュリティ ゲートウェイとルールの開発

APIセキュリティとは何ですか?

API、またはアプリケーション プログラミング インターフェイスのセキュリティは、API をサイバー攻撃から保護します。 API の使用は近年爆発的に増加しており、アプリケーション間のデータ転送を可能にすることで組織にイノベーションの機会が与えられています。 残念ながら、API の使用が増加するにつれて、API に対する攻撃も増加しています。 Salt Security の調査によると、API に対する攻撃は 2022 年 6 月から 12 月の間に 400% 増加しました。

アプリケーションと API のセキュリティ上の脅威

AppSec と API セキュリティの違いを理解するには、各分野の主な脅威を理解する必要があります。 幸いなことに、ソフトウェア セキュリティの向上を目指す非営利団体である OWASP は、アプリケーション セキュリティと API セキュリティに対する最も重大な脅威の包括的なリストを提供しています。 OWASP トップ 10 として知られるこのリストは、OWASP のグローバル セキュリティ専門家コミュニティからの情報を照合して、アプリケーションと API に対する最も重大な脅威を特定します。

興味深いことに、OWASP は 2003 年に Web アプリケーション セキュリティ リスクのトップ 10 リストを発表しましたが、API セキュリティ リスクのトップ 10 リストを発表したのは 2019 年後半でした。この矛盾は、アプリケーションと API セキュリティのもう 1 つの重要な違いを表しています。アプリケーション セキュリティは十分に確立されており、 API セキュリティは、多くの進化段階を経て広範囲に研究された分野ですが、そうではありません。

詳細な分析をする時間はありませんが、各リストを簡単に見てそれらがどのように異なるかを確認することは価値があり、組織が AppSec と API セキュリティにどのようにアプローチするかを知ることができます。

OWASP アプリケーション セキュリティ リスク トップ 10 (2021)

  1. 壊れたアクセス制御- 権限のないユーザーが制限された情報やシステムにアクセスできる場合
  2. 暗号化の失敗- 暗号化の欠如または欠陥により、サードパーティが特定の意図なしに機密データを公開した場合
  3. インジェクション– 攻撃者がインタープリターに送信されるコマンドの意味を変更する方法でアプリケーションにデータを送信しようとする場合
  4. 安全でない設計– アーキテクチャおよび設計の欠陥に関連するリスク
  5. セキュリティの構成ミス– セキュリティ チームがセキュリティ管理を不正確に構成したり、安全でないままにした場合
  6. 脆弱で古いコンポーネント– 組織がコンポーネントにパッチを適用しないまま放置している場合
  7. 識別および認証の失敗 (認証の失敗が必要) – アプリケーションが認証攻撃に対して脆弱な場合
  8. ソフトウェアとデータの整合性障害– コードとインフラストラクチャが整合性違反から保護できない場合
  9. セキュリティのログと監視の失敗 (不十分なログと監視が必要) – 組織が不適切なログと監視の手順によりデータ侵害を検出できない場合
  10. サーバー側のリクエスト フォージェリ– ファイアウォール、VPN、または別の種類のネットワーク アクセス コントロール リスト (ACL) で保護されている場合でも、攻撃者がアプリケーションをだまして、細工したリクエストを予期しない宛先に送信させる場合

OWASP トップ 10 API セキュリティ リスク (2023)

  1. オブジェクト レベルの認証の破損– API オブジェクト (データベースやファイルなど) に適切な認証制御がなく、未承認のユーザーにアクセスが許可される場合
  2. 認証の失敗– ソフトウェアおよびセキュリティのエンジニアが API 認証の境界とその実装方法を誤解している場合
  3. 壊れたオブジェクト プロパティ レベルの認証– 過度のデータ公開と大量割り当ての組み合わせ。攻撃者がオブジェクト プロパティ レベルでのロックまたは不適切な認証を悪用した場合。
  4. 無制限のリソース消費 – API リクエストを満たすには、ネットワーク帯域幅、CPU、メモリ、ストレージが必要です。 サービスプロバイダーは、電子メール/SMS/電話や生体認証検証などの他のリソースを API 統合を通じて利用可能にし、リクエストごとに料金を支払います。 攻撃が成功すると、サービス妨害や運用コストの増加につながる可能性があります。
  5. 機能レベルの承認が壊れている場合、攻撃者は公開された API エンドポイントに正規の API 呼び出しを送信します。
  6. 機密性の高いビジネス フローへの無制限のアクセス –このリスクに対して脆弱な API は、自動化された方法で過度に使用された場合に機能がビジネスに悪影響を与える可能性があることを補償することなく、チケットの購入やコメントの投稿などのビジネス フローを公開します。 これは必ずしも実装のバグが原因であるとは限りません。
  7. サーバー側のリクエスト フォージェリ – API がユーザー指定の URI を検証せずにリモート リソースを取得する場合。 これにより、ファイアウォールや VPN で保護されている場合でも、攻撃者がアプリケーションに細工したリクエストを予期しない宛先に送信させることができます。
  8. セキュリティの構成ミス– API とそれをサポートするシステムには、通常、よりカスタマイズしやすくするための複雑な構成が含まれています。 ソフトウェアおよび DevOps エンジニアは、これらの構成を見逃したり、構成に関するセキュリティのベスト プラクティスに従っていない可能性があり、さまざまな種類の攻撃の扉を開くことになります。
  9. 不適切な在庫管理– API は従来の Web アプリケーションよりも多くのエンドポイントを公開するため、適切で更新されたドキュメントが重要になります。 ホストとデプロイされた API バージョンの適切なインベントリも、非推奨の API バージョンや公開されたデバッグ エンドポイントなどの問題を軽減するために不可欠です。
  10. API の安全でない使用 –開発者は、ユーザー入力よりもサードパーティ API から受信したデータを信頼し、弱いセキュリティ標準を採用する傾向があります。 API を侵害するために、攻撃者はターゲット API を直接侵害しようとするのではなく、統合されたサードパーティ サービスを狙います。

ご覧のとおり、一部の重複はありますが、アプリケーションと API は主に異なる固有の脅威にさらされるため、組織はそれに応じて対応する必要があります。 2 つのリストの主な違いは、組織は従来の多目的セキュリティ ツールと技術を使用してアプリケーション セキュリティに関連するすべての重大なリスクを軽減できるが、API セキュリティは異なるということです。

API セキュリティは非常に現代的な問題であり、同様に最新のソリューションが必要です。 組織は、アプリケーションやその他の資産を保護するために使用するツールが、API を保護するというタスクを満たすことを期待できません。 API セキュリティには API 固有のセキュリティ ツールが必要です。 API ゲートウェイや Web アプリケーション ファイアウォール (WAF) などの従来の保護方法では十分ではありません。