APIセキュリティとは?

APIセキュリティが重要な理由

アプリはあらゆる場所に存在し、ビジネスや社会に不可欠な一部となっています。そして、ほぼすべてのアプリの背後にはAPIがあり、APIのセキュリティをミッション クリティカルなレベルに高めています。

APIは、モバイル アプリ、Webアプリケーション、SaaSに加えて、社内向け、パートナー向け、顧客向けのアプリケーションなど、ほとんどのクラウドネイティブ アプリケーションのバックエンド フレームワークの役割を果たしています。API利用を大局的に見てみると、API管理プラットフォームのPostmanでは、2022年に 11億3千万件のAPI呼び出し がありました。APIの増加により、攻撃者がアタックサーフェスから金銭を得る可能性を求めてやって来ているのです。

APIはアプリケーション ロジック、リソース、および個人識別情報(PII)などの機密データを露出するため、攻撃者はそれらを標的にします。攻撃者は未保護のAPIにアクセスできれば、事業活動の中断、機密データへのアクセスと破壊、資産の窃取を行うことが可能です。

Webアプリケーション セキュリティへの従来のアプローチ

モノリス アプリケーション時代のWebアプリケーション セキュリティは、Webクライアントが送信するHTTPを傍受し阻止する Webアプリケーション ファイアウォール(WAF) を境界上に導入することで成り立っていました。WAFは、アプリケーションに対する潜在的リスクが、標準的なHTTP Webフォーム送信やブラウザ要求に埋め込まれた悪意のあるユーザー入力に主に含まれていた場合に、効果的なアプリケーション セキュリティをこれまで提供してきました。

しかし、Webアプリケーションの特質は、個別のWebサーバでホストされるモノリス アプリケーションから、クラスタやホスト サーバに分散し、コンテナ化されたクラウドネイティブ アプリケーションへと変化しました。

現在、開発者やセキュリティ チームは、高度に分散化したクラウドネイティブ マイクロサービス アーキテクチャを扱い、境界のないネットワークに対処しなければなりません。現代のアプリは、標準的なWeb要求、モバイル デバイスのAPI呼び出し、クラウド イベント、IoTデバイスのテレメトリ通信、クラウド ストレージなど、広範なソースから入力を取り込みます。

クライアントのインバウンドHTTP要求(つまりNorth-Southトラフィック)は、一連の通信フローで最初になることがよくあります。多くの場合、1つのインバウンド要求が数十の内部API呼び出し(つまりEast-Westトラフィック)を生成します。それらの内部API呼び出しが適切に検査および検証されない場合、APIエンドポイントは保護されないままです。

境界で入力を検査するだけでは有害なペイロードの捕捉には不十分です。内部のAPIエンドポイントが、設定ミスにより個々のマイクロサービスへの不正アクセスを許可して、アプリケーション ロジックを悪意のある行為にさらしてしまうことがあります。外部および内部のすべてのAPIエンドポイントを、継続的に監視および保護することが重要です。

API攻撃の分析

組織がAPIに依拠してビジネスを推進すると、攻撃者はAPIの欠陥を悪用しようとうろつき回ります。以下の例では、フロントエンドとしてモバイル アプリケーションを使用するeコマース アプリケーションを標的とするAPI攻撃で、脅威アクターが貴重なデータを侵害する手段を見つけることがいかに容易であるかを示したものです。

ステップ1: 攻撃者はモバイル アプリをリバース エンジニアリングすることで、バックエンドのマイクロサービスからのデータの取得に使われる、非推奨のAPIエンドポイントURLを発見します。

ステップ2: 攻撃者は、このエンドポイントへのAPI呼び出しの送信には、認証も承認も不要であることに気づきます。

ステップ3: 攻撃者はSQLiの脆弱性を悪用します。このAPIエンドポイントURLは一意の製品IDを数値の形式で提供し、攻撃者は一連の自動チェックを実行して、入力フィールド<product_id>を利用して、SQLi攻撃をうまく実行できることを発見します。

ステップ4: 攻撃者は、このSQLiを悪用してデータを改ざんするよりも、SQLiの脆弱性を悪用して、SQLデータベースで実行しているマイクロサービスのシェル コマンドを実行することを選択します。このシェル コマンドは、悪意のある実行可能ファイルをダウンロードして実行します。この実行可能ファイルは、ビットコインのマイニング ソフトウェアです。

APIセキュリティ リスク

APIの設定ミス、論理の誤り、脆弱性は、アプリケーションやデータを攻撃者に露出します。APIゲートウェイでは、ゲートウェイ経由でルーティングされるAPIトラフィックのみが可視化され、内部トラフィックの可視性は提供しないにもかかわらず、一部の組織では、APIゲートウェイがAPIを完全に保護すると信じて、自社のAPIセキュリティをAPIゲートウェイに頼っています。

セキュリティ チームには、APIサーフェス全体の可視性が必要です。見えないものを守ることはできません。可視性がなければ最終的には、シャドーAPIを発見した攻撃者の活動が検出されないことにつながります。

APIゲートウェイは、APIとAPIの利用状況を効果的に監視できますが、攻撃を検出してブロックすることはできません。APIセキュリティには可視性やリスク管理だけでなく、悪意ある攻撃に対するリアルタイム保護が必要です。

OWASPトップ10

OWASP (Open Web Application Security Project)は2019年にAPIセキュリティ リスクトップ10を発表して、現代のWebアプリケーションに影響を与えるAPIセキュリティ リスクについての認識をもたらしました。このリストは、Web APIに対して最も頻繁に見られる攻撃の概要と、それらの脅威からAPIを保護するヒントを示しています。

オブジェクト レベルの承認の不備

オブジェクトIDを扱うエンドポイントは多くの場合、APIによって公開され、その結果、アタックサーフェスを拡大するアクセス制御の問題につながります。適切な承認チェックが実装されない場合は、例えば、攻撃者がAPI呼び出しの際に、別のユーザーに属するリソースのIDを置き換えることが可能です。これは安全でない直接オブジェクト参照(IDOR)攻撃として知られており、攻撃者がアクセスを認められていないリソースにアクセスすることを可能にします。

ユーザー認証の不備

APIの認証メカニズムは、誰にでも公開されているため、容易に標的にされます。認証メカニズムの実装が不十分なことは、API認証不備の脆弱性と呼ばれ、実装の欠陥を悪用して正規ユーザーのIDを推測できる攻撃者がそこから侵入します。

API認証の設定ミスは、アクセス トークンの検証の未実装や、APIエンドポイントURLでの認証情報とキーの保存など、業界のベストプラクティスが回避された場合に発生する可能性があります。

データの過剰公開

公開されるデータが多いほど、リスクも高まります。APIの実装の際、開発者は制限事項の詳細を定めずにオブジェクト プロパティを公開し、それがUIに表示される前に、クライアントが不要データをフィルタリングして除外することを当てにする場合があります。しかし、APIクライアントが機密データをフィルタリングして除外した場合でも、攻撃者は最初のAPI呼び出しを悪用することができ、クレジット カード番号、ログイン認証情報、社会保障番号へのアクセスを取得する可能性があります。

リソース不足とレート制限

クライアントが呼び出せるリソース数を制限しないAPIは、トラフィック オーバーロードによるAPIの悪用に対して脆弱です。この種類のオーバーロードはAPIサーバのパフォーマンスを低下させ、正規ユーザーを締め出し、DoSにつながる可能性があります。さらに、APIサーバのオーバーロードによりAPIが公開され、ブルート フォースなど、認証の不備にもつながります。

機能レベルの承認の不備

API開発者が直面する課題の1つに、多様な階層のユーザー グループやロールにアクセス制御ポリシーを実装する複雑さがあります。管理と通常機能の区別が不明確なことで承認の不備が生じ、それを攻撃者が悪用して、ユーザーのリソースへのアクセスを取得したり、未承認の管理機能を実行したりするのです。

マス アサインメント

マス アサインメント脆弱性は、クライアント供給データが、ユーザーが保護対象フィールドにデータを割り当てないように、ホワイトリストに照らしてフィルタリングを行うことがないデータ モデルに結びついている場合に発生します。この脆弱性により、攻撃者はAPIクエリを傍受して、オブジェクト プロパティを推測することで保存済みのバックエンド オブジェクトのプロパティの変更を行い、機密データへのアクセスを取得できます。攻撃者はプライベートAPIのデータ属性の侵害手口に関する手がかりを得るうえで、ドキュメントを読み、APIエンドポイントを徹底的に調べます。

セキュリティの設定ミス

セキュリティの設定ミスにより、機密ユーザー情報やシステムの詳細が公開されることがあり、サーバの侵害につながる可能性があります。よくある原因には、寛容なオリジン間リソース共有(CORS)、不完全またはその場しのぎの設定、HTTPヘッダーやHTTPメソッドの誤り、安全でないデフォルト設定、不完全または誤った設定、機密情報を露出する冗長なエラー メッセージなどがあります。

インジェクション

APIは、信頼されていないデータがコマンドやクエリの一部としてインタープリタに送信される際に発生することがある、インジェクションの脆弱性(SQLインジェクション、NoSQLインジェクション、コマンド インジェクション)にさらされています。攻撃者はインタープリタをだまして、危険なコマンドを実行させ、操作や窃取のために未承認のデータを公開させることができます。

不適切な資産管理

APIは、従来のWebアプリケーションよりも多くのエンドポイントを公開するため、これらのエンドポイントを追跡する強力なAPI管理は、公開された機密や脆弱なAPIエンドポイントの悪用を防止する上で欠かせません。例えば、非推奨のAPIエンドポイントやデバッグ エンドポイントは、攻撃者によるアプリケーションの侵害に使われる可能性があります。

不十分なログ記録とモニタリング

不適切なログ記録とモニタリングは、直接的な脅威ではありませんが、悪意のある活動の検出を遅らせます。攻撃者は闇に隠れて、たっぷり時間をかけて攻撃を進展させ、別のシステムに進んでデータの改変、抽出、破壊を行います。侵害の調査によると、持続型脅威の検出には200日以上かかることもあります。また、データの侵害後、適切なログ記録とモニタリングを行わない場合、組織では損害を評価するためのフォレンジック情報が不足します。

SOAP、REST、GraphQLのAPIセキュリティ

SOAP、REST、GraphQLは、一般的な3つのAPIアーキテクチャ パターンです。各APIアーキテクチャ スタイルに、明確なセキュリティ考慮事項が存在します。

SOAP APIセキュリティ

SOAP (シンプル オブジェクト アクセス プロトコル)は、コンピューター ネットワークでのWebサービスの実装において構造化データの交換を行うためのプロトコルです。SOAPではXMLをメッセージ形式として使用し、HTTPやSMTPなど、多様な比較的低次のプロトコルで使用できます。SOAP APIは通常、トランスポート レイヤー セキュリティ(HTTPSなど)とメッセージレベルのセキュリティ(XMLデジタル署名や暗号化など)を組み合わせて保護されます。

SOAP APIのセキュリティには、セキュリティの問題に対処するためのプロトコル拡張を伴います。SOAPはWebサービス(WS)の仕様を順守します。それにより、組み込みのエラー処理のサポートを拡張するWS-ReliableMessagingなどの機能を通じて、すべてのWebサービスをエンタープライズレベルのセキュリティで確実に保護します。

REST APIセキュリティ

REST API (representational state transfer API)のアーキテクチャは、JSONデータ転送およびHTTP/S転送プロトコルを利用します。これら2つにより、REST APIの開発は他のAPIアーキテクチャに比べて簡素化されています。RESTful APIは、HTTP要求を使用してデータのPOST (作成)、PUT (更新)、GET (読取り)、DELETE (削除)を行います。

組み込みのセキュリティが用意されていないため、REST APIのセキュリティはAPIの設計で決まります。データの転送、導入、およびクライアント インタラクション サービスには、セキュリティ考慮事項を組み込む必要があります。大多数のRESTful APIは、トランスポート レイヤー セキュリティ(HTTPSなど)とトークンベースの認証を使用します。

REST APIのセキュリティへの対処で最もよく選ばれるアーキテクチャは、REST APIをAPIゲートウェイの背後に導入して、その接続性オプションをクライアントに提供する方法です。しかし、APIゲートウェイは配備されず、セキュリティ脅威から全面的に防御されません。

RESTとSOAPの比較

SOAPとRESTful APIはHTTPの要求と応答だけでなく、SSL (Secure Sockets Layer)もサポートしますが、共通性はそれだけです。SOAP APIにはセキュリティ機能が組み込まれ、本質的に安全です。一方、RESTful APIは、実装やアーキテクチャの選択を通じて安全にする必要があります。

GraphQL APIセキュリティ

GraphQL APIセキュリティを適用すると、カスタマイズ可能で柔軟な要求に関する課題が生じます。サーバは複雑なクエリを処理できない可能性があり、そのプロセスで悪意のあるクエリを意図せず実行してしまうことがあります。

GraphQL APIセキュリティ リスクの緩和方法には、最大クエリ深度の絞り込みや設定だけでなく、大規模クエリから防御するためのクエリ タイムアウトも含まれます。

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

APIがますます公に入手可能になり、アタックサーフェスの最小化、脆弱性の修復、ほぼリアルタイムでの悪意のある活動の把握を行うベストプラクティスを実装することで、データ公開のリスクに対処することが重要です。

安全な認証および承認方法の使用

正規ユーザーのみが、OAuth2やJSON Webトークン(JWT)などの安全な認証方法を使用して、APIにアクセスできるようにします。

レート制限の実装

ブルートフォース攻撃やその他の悪意のある動作を防ぐために、APIでレート制限を実装します。レート制限では、指定された期間内にAPIに対して実行できる要求の数を制限します。

HTTPSの使用

APIの要求と応答は、HTTPSを使用して、確実に暗号化と保護を実施して行う必要があります。これは特に、機密データを扱う際に重要です。

定期的なセキュリティ評価の実施

APIのセキュリティを定期的に評価して、脆弱性の可能性を特定します。APIインベントリの変更のレビューを行って、新しく公開されたAPIとそのリスク プロファイル(機密データの公開、インターネットへの公開、ワークロードの脆弱性 、認証レベルなど)を検出します。

APIキーの使用

APIキーは、APIを呼び出すアプリケーションを特定し、アクセスの承認を検証するために使用する、一意の識別子です。APIキーは、アプリケーション(またはWebサイト)を使用する人物ではなく、API呼び出しを行うアプリケーション(またはWebサイト)を特定する点で、認証トークンとは異なります。どちらも重要なセキュリティ対策です。

望ましくない呼び出し、不正アクセス、個人情報の損失によるデータ侵害の可能性を避けるため、APIキー ストレージのベストプラクティスに従います。

APIの監視

APIの仕様、ドキュメント、テスト ケース、トラフィック、メトリックを管理および監視します。悪意のあるAPIトラフィックや不正なボットなど、望ましくない活動をブロックして、アプリケーションの保護や不要なコストの削減に役立てます。

セキュリティ ベストプラクティスについてのチームへの教育

CI/CDパイプライン の初期にセキュリティを組み込み、脆弱な認証や論理的脆弱性などのセキュリティ リスクについて、開発者の知識を向上させるトレーニングを提供します。セキュリティ チームと開発チームのコラボレーションなど、 DevSecOps 原則を実装します。

脆弱性の把握

OWASP APIセキュリティ トップ10のリスクを日常的に探すことで、APIライフサイクルの弱点を特定します。APIスキャン ツールや手法を使用して、APIの各脆弱性を特定し、直ちに解決して悪用を防ぎます。

認証用のセキュリティ トークンの要求

認証用のセキュリティ トークンの要求は、防御の第一線です。セキュリティ トークンは、ユーザーのトークンが検証にパスしなかった場合にAPI呼び出しを拒否することで、APIを不正アクセスから保護します。

つまり、ベストプラクティスはまず、環境内のすべてのWebアプリケーションとAPIエンドポイントを自動的に検出できる、アタックサーフェスの可視性とモニタリングから始める必要があります。防御層には、North-SouthおよびEast-Westトラフィックで、インターネット由来のものでも、アプリケーション内のものでも、悪意のある脅威をブロックするポリシーが含まれます。

強力な認証に加えて、脆弱性とコンプライアンスのスキャン機能を追加することで、アプリケーションの保護がさらに強化されます。また、ホスト、VM、コンテナ、アプリケーションのホストに役立つサーバレス機能など、ワークロードやインフラストラクチャの層を保護する必要もあります。

Prisma CloudのAPIセキュリティ ソリューション

Prisma Cloud はクラウドネイティブ アプリケーション保護プラットフォーム (CNAPP)の一部として、すべてのAPIを対象とした検出、リスク プロファイリング、リアルタイム保護機能を完備します。.

APIセキュリティ機能

• API検出: 環境上の全APIを自動検出し、シャドーAPIや野良APIが原因の死角を解消します。
• APIリスク プロファイリング: APIのリスクやリスク要素(設定ミス、機密データの公開やアクセス制御)を特定し、修復の優先順位付けを行います。
• リアルタイム保護: OWASP Top 10 (API編)でリストアップされた攻撃に対するリアルタイム保護の適用、レート制限の実施、悪意あるボットの阻止を行います。

APIセキュリティについてのよくある質問