APIセキュリティとは？

概要

アプリケーションプログラミングインターフェース（API）は、ソフトウェアアプリケーション同士が通信できるようにする上で重要な役割を果たします。しかし、攻撃のベクトルとなる可能性もあります。APIに効果的なアクセス制御や入力検証などのセキュリティ対策が欠けている場合、脅威アクターはAPIを悪用して、アプリケーションから機密データを流出させたり、アプリケーションの動作を操作したり、重要なサービスを妨害したりする可能性があります。

APIセキュリティは、こうしたリスクを軽減します。設計段階でAPIにセキュリティ制御を組み込み、テスト中にAPIのセキュリティリスクを慎重に評価し、本番環境でAPI攻撃を監視するなど、APIライフサイクルのすべての段階でAPIセキュリティの原則に従うことで、組織はAPIがセキュリティ態勢における最も弱い部分となる可能性を最小限に抑えられます。

APIセキュリティとは？

APIセキュリティとは、アプリケーションプログラミングインターフェース（API）に関連するセキュリティリスクを最小限に抑えるための取り組みのことです。

APIセキュリティの定義を十分に理解するには、APIの動作を理解すると役立ちます。繰り返しになりますが、APIとは、2つ以上のアプリケーションがデータを交換できるようにする仕組みです。APIは、一方のアプリケーションがデータをどのようにフォーマットし、別のアプリケーションに送信するかを定める一連のルールを定義することで機能します。また、受信側のアプリケーションが元のアプリケーションに応答を返す方法も定義します。

APIは、アプリケーション同士が容易に通信できるようにするという正当かつ重要な役割を果たしますが、攻撃経路となる可能性もあります。例えば、攻撃者はAPIを利用してアプリケーションに悪意のあるリクエストを送信する可能性があります。別の方法として、認証制御のないAPIを利用して、本来公開されるべきではないデータを要求することも考えられます。あるいは、APIに大量のリクエストを送りつけ、APIをホストするアプリケーションやサーバーに過負荷をかける手段としてAPIを悪用する可能性もあります。これはサービス拒否（DoS）攻撃の一例です。

APIセキュリティは、こうしたリスクから保護します。APIに対するセキュリティ脅威を理解し、それらを軽減するための対策を講じることで、開発者は悪用や攻撃に強いAPIを設計、実装、デプロイできます。

APIライフサイクル全体にわたるAPIの保護

APIを保護するには、開発者はAPIライフサイクルの重要なすべての段階でセキュリティを統合する必要があります。

• 設計：APIの動作を設計する際、開発者は、適切なアクセス制御やレート制限機能を備えていることなどを考慮する必要があります。
• 実装：APIを実装するコードを記述する際には、意図されたセキュリティ機能の一部が適切に動作しなくなる原因となるミスを避けることが重要です。
• テスト：開発者は通常、APIを実運用に導入する前にテストします。テストでは、APIがセキュリティ攻撃に対する耐性を備えているかを評価するとともに、パフォーマンスも評価する必要があります。
• 消費：APIが消費されている場合、つまり本番アプリケーションで使用可能な状態にある場合、チームは信頼できないソースから発生する大量の異常なAPIリクエストなど、攻撃の兆候を監視し、対応する必要があります。

APIセキュリティの主な脅威

APIセキュリティの脅威に関する最も代表的な参考資料は、OWASPのAPIセキュリティリスクのトップ10です。OWASPが特定した主な脅威には以下が含まれます。

• オブジェクトレベル認可の不備：APIがオブジェクトへのアクセスを許可する前にユーザーまたはリクエストを検証しない場合に、このリスクが生じます（オブジェクトとは、APIが提供できるデータの種類などのリソースを意味します）。この欠陥を悪用すると、攻撃者は本来アクセスできないデータやその他のオブジェクトにアクセスできるようになります。
• 認証の不備：リクエストを適切に認証しない（または認証の仕組み自体がない）APIは、認証の不備の影響を受けます。これにより、攻撃者はAPIの正規ユーザーを装って、本来利用できないはずのリクエストを送信できます。
• サーバーサイドリクエストフォージェリ：APIが、要求された宛先が正当かどうかを確認せずにリクエストに応答すると、SSRFが発生します。攻撃者はこの脆弱性を悪用して、任意の宛先にリクエストを送信し、機密データを漏えいさせる可能性があります。
• アクセス制限なし：アクセス制限のないAPIは悪用され、アプリケーションやサービスの可用性を損なう可能性があります。例えば、アプリケーションが1分あたりに処理を試みるAPIリクエスト数に上限がない場合、攻撃者が大量のリクエストを送信し、アプリケーションをクラッシュさせる可能性があります。
• 機能レベルの認可の不備：このタイプのAPI脆弱性は、API機能に対するリクエストを適切に検証しないAPIに影響します。例えば、認証されていないユーザーが、開発者が認証済みユーザーのみ利用できるように意図したアクションをアプリケーションに実行させるリクエストを送信できるAPIもあります。

OWASPのリストに詳述されていない、その他の一般的なAPIセキュリティリスクには、以下のようなものがあります。

• インジェクション：APIインジェクション攻撃は、APIが入力を適切に検証せずに受け入れることで発生し、攻撃者がアプリケーションに悪意のあるリクエストを挿入できるようになります。
• 過剰なデータ：APIは、リクエストを満たすために必要な最小限のデータのみを公開する必要があります。より多くのデータを提供するAPIは、過剰なデータに伴うリスクにさらされ、機密情報の漏えいにつながる可能性があります。
• 「シャドー」API： シャドーAPIとは、公開されているものの、適切に保護、管理、または監視されていないAPIのことです。シャドーAPIは多くの場合、組織内の一部の開発者が他の関係者に知らせることなく、あるいはAPIの設計やセキュリティに関する社内ルールに従わずにAPIを実装することによって発生します。セキュリティ基準や監視の欠如によって攻撃を受けやすくなる可能性があるため、これらはリスクとなります。

API保護のベストプラクティス

APIを取り巻くセキュリティや利用コンテキストはさまざまであるため、開発者がAPIのセキュリティを最大限に高めるために従うべき決まった一連の手順というものは存在しません。さらに、APIのユースケースが異なれば、適用されるセキュリティ基準も異なります。例えば、パブリックAPIを設計する場合、認証を要求することは必ずしも意味がないかもしれません。なぜなら、ほとんどのパブリックAPIの目的は、アプリケーションが他のアプリケーションやサービスからデータを受信できるようにすることだからです。しかし、プライベートAPIは信頼できるアプリケーションやサービスへの接続のみを許可するものであるため、ほとんどの場合、認証を必須とする必要があります。

とはいえ、すべてのユースケースにおいて、事実上あらゆる種類のAPIに対するセキュリティ脅威を緩和するのに役立つ一般的なセキュリティのベストプラクティスやAPI保護機能が存在します。

• 常にデータを暗号化する： APIを介してやり取りされるデータは暗号化する必要があります。暗号化により、APIトランザクション中に第三者が機密データを傍受して読み取るリスクを最小限に抑えられます。
• 強固な認証を必須にする：非認証リクエストをサポートする必要のないAPIでは、開発者はOAuthやJWTなどの方式で強固な認証を実装する必要があります。
• APIのセキュリティ上の欠陥をテストする：開発者が見落とした可能性のあるAPIのセキュリティ上の脅威を検出するには、APIに対する悪意のある行為をシミュレーションし、その応答を評価するテストを実行することが推奨されます。
• APIリクエストを制限する：APIの不正利用のリスクを軽減するため、組織はAPIが受け付けるリクエスト数を制限できます。制限はAPI自体に実装することも、APIゲートウェイなどのツールを使用して適用することもできます（APIゲートウェイは、アプリケーション間のAPIリクエストを傍受し、悪意のあるリクエストをブロックできる仲介ツールです）。
• APIを監視する：実行時（APIが実際の利用に供されている期間）にAPIを監視すると、一連の異常なリクエストなど、攻撃や不正利用の試みを検知できる場合があります。こうしたリクエストは、脅威アクターがAPIの認証または認可の仕組みに存在するセキュリティ上の欠陥を発見し、悪用しようとしていることを示している可能性があります。

APIセキュリティと一般的なアプリケーションセキュリティの比較

APIセキュリティは、アプリケーションセキュリティといくつかの概念やプラクティスを共有しています。例えば、どちらの状況においても、製品を本番環境にリリースする前に、強力な認証制御を実装し、適切なセキュリティテストを実施することが重要です。

ただし、APIはアプリケーションと同じものではなく、APIセキュリティは重要な点でアプリケーションセキュリティとは異なります：

• 攻撃の種類：アプリケーションは、コードインジェクションのリスクから、サプライチェーン攻撃、脆弱性の悪用などに至るまで、より広範な潜在的攻撃の対象となります。これに対し、APIに対する攻撃の多くは、脆弱な、あるいは欠落している認証、認可、レート制限コントロールを悪用します。
• コードベースの悪用：アプリケーションセキュリティにおいて、ソースコードの欠陥（入力検証の欠如など）は、セキュリティリスクの一般的な原因です。APIもコードに依存しますが、コードの範囲は比較的小さく、セキュリティ問題の原因となることはほとんどありません。その代わり、APIのセキュリティ上の欠陥は、認証を必須にしないなど、設計上の誤りに起因する傾向があります。
• セキュリティツール：アプリケーションを保護するために利用できるツールは、APIを保護するために使用されるツールとは異なります。例えば、CVEに関連付けられたソフトウェアコンポーネントをチェックする脆弱性スキャナーは、重要なアプリケーションセキュリティツールですが、APIの保護には役立ちません。その代わり、APIをスキャンするには通常、悪意のあるリクエストをシミュレートするタイプのスキャナーを使用します（DASTスキャナーも同様の方法でアプリケーションのセキュリティリスクをチェックしますが、アプリケーションセキュリティスキャナーの一種にすぎません）。

JFrogとAPIセキュリティ

JFrogソフトウェアサプライチェーンプラットフォームは、アプリケーションスキャン、シークレットスキャン、サプライチェーンセキュリティ、セキュアなアーティファクト管理などのさまざまな保護機能を提供し、どこで発生したリスクであってもアプリケーションを安全に維持し、リスクを軽減できるように支援します。