APIセキュリティとは？主な種類と使用例

API（アプリケーションプログラミングインターフェース）は、現代のアプリケーション開発において欠かせない基本要素です。Web APIは、アプリケーションが他のアプリケーション、サービス、またはプラットフォームと通信し、データを交換する能力を提供します。これにより、企業は外部のプラットフォームやサードパーティのサービスと簡単に統合し、さまざまなコンポーネントを接続して包括的なソリューションを構築することができます。

開発者は、既存のサービスや機能を活用することで、コードの再利用を促進し、開発サイクルを加速させ、生産性を向上させることができます。さらに、APIはビジネスロジックを切り離し、分散化する能力を持つため、最新のアプリケーションの基盤となります。従来のアプリケーションをAPIベースのアーキテクチャに進化させるための重要なメカニズムでもあります。

APIセキュリティの重要性も高まっており、個人情報保護やデータの安全性を確保するための仕組みが必要です。 APIセキュリティの問題を把握し、適切な対策を行うことが、スマートフォンやwebサイトなど多くのケースで不可欠となっています。APIセキュリティの普及が進む中、企業はこの重要な領域を無視することはできないでしょう。

コンピューティングの他のあらゆる側面と同様に、APIテクノロジーも、開発者がパフォーマンスと信頼性を向上させる方法を模索する中で、過去25年の間に変化してきた。APIの設計思想とデータ表現の両方が進化し、それと共にデータとトラフィックを保護する方法も進化してきた。一般的なAPIアーキテクチャのタイムラインは、おおよそ以下のように見ることができる：

• SOAP APIs (1998年-2010年). SOAP（Simple Objects Access Protocol）APIは、XMLフォーマットデータのデジタル署名と暗号化を使用して、メッセージレベルでセキュリティを適用する。メッセージ・レベルのセキュリティは、一般的にREST APIアーキテクチャ・スタイル（下記）のセキュリティよりも包括的である。しかし、その移植性は高く評価されているものの、メッセージ・レベルのセキュリティは現在ではレガシーなウェブ・サービスでしか見られない。
• REST APIs (2010年-今). 過去10年間で、表現的状態遷移（REST）はAPIの最も一般的なアーキテクチャ・スタイルとなった。今日、ほとんどのウェブAPIはREST APIである。RESTでは、リソースは固有のHTTP URIで識別され、アクセス制御ルールはHTTP動詞とHTTP URIの組み合わせに基づいている。
• GraphQL APIs (2020年-未来) GraphQLはAPI用の新しいクエリ言語だ。アプリケーションに最適な方法でAPIクエリをカスタマイズできるようにすることで、フロントエンド開発者をコントロールできるようにする。すべてのリソースは単一のURIを通してアクセスされます。この柔軟性と制御性により、GraphQLはますます人気が高まっています。

APIは、そのアクセシビリティ、使用方法、対象者によっていくつかのタイプに分類することができる。

• プライベートAPIは内部APIとも呼ばれ、組織が内部で使用するために開発・保守するもので、組織のインフラストラクチャ内の異なるコンポーネントやサービス間の通信を可能にするために使用される。プライベートAPIは、外部の開発者が使用することを意図していません。
• パブリックAPIは、サービス、プラットフォーム、またはアプリケーションの特定の機能やデータへのアクセスを提供するように設計されており、外部の開発者、サードパーティのソフトウェアアプリケーション、および一般の人々が利用できるようになっています。公開APIは、製品やサービスの機能を拡張し、サードパーティの開発者がアプリケーションや統合機能を構築することを促進するために使用されることがよくあります。
• パートナーAPIは、パブリックAPIのサブセットであり、組織の特定のパートナー、関連会社、顧客、またはB2B（企業間）協力者の使用に制限され、特定の機能やデータへの制御されたアクセスを提供する。これらのAPIへのアクセスは、通常、認証と認可のメカニズムを通じて許可される。
• サードパーティAPIは、外部の組織や個人によって開発され、他のアプリケーションに統合できる機能を提供する。これらのAPIを利用することで、開発者は外部のサービスやライブラリ、データソースにアクセスして自身のアプリケーションを拡張することができ、既存のサービスや機能を活用することで時間と労力を節約するソフトウェア開発に広く利用されている。サードパーティAPIの例としては、カスタムマップを表示するマッピングAPIや、旅行や観光のウェブページに地域の予報を表示する天気APIなどがある。

APIはまた、リスクサーフェスを拡大し、特にマルチクラウドアーキテクチャにまたがる相互依存の性質により、予期せぬリスクをもたらす。これはAPIスプロールと呼ばれ、APIエコシステムのセキュリティに極度の脅威をもたらす可能性がある。ウェブアプリと同様に、APIは脆弱性の悪用、自動化された脅威による悪用、サービス拒否、設定ミス、認証と認可のコントロールをバイパスする攻撃の影響を受けやすい。

最新のマイクロサービス・アーキテクチャの採用が進むと、APIのスポールが悪化する可能性がある。なぜなら、そのようなアーキテクチャでは、インターフェースへの通信（南北トラフィック）とマイクロサービス間の通信（東西トラフィック）の両方に大量のAPIが使用されるからだ。

APIスプロールに対抗するための戦術には以下のようなものがある：

• APIガバナンス戦略の導入
• APIディスカバリーのための真実の単一ソースを作成する
• 適切なバージョン管理とドキュメンテーションの確保
• APIトラフィックのメトリクスと可視性を提供する
• APIセキュリティを大規模に適用する

これらの戦術とその実行方法については、APIスプロールと戦うための5つの方法（そして、なぜあなたは気にする必要があるのか）をお読みください。

APIはその性質上、ユーザーデータ、認証情報、金融取引などの重要なビジネスロジックや機密情報を公開するものであり、特にログイン、アカウント作成、カートへの追加、送金機能など、ますます攻撃者の標的となっています。APIは、脆弱性や弱点を悪用しようとする攻撃者や、基盤となるインフラやリソースを公開しようとする攻撃者の入口となる可能性があります。

認証と認可はAPIセキュリティの基本要素である。認証は、APIにアクセスしようとするユーザーやシステムの身元を確認することで、リクエストを行うエンティティが本人であることを保証する。一般的な認証方法には、ユーザー名／パスワード、APIキー、トークン、生体認証などがある。認証は、認証されたユーザーまたはシステムがAPI内でどのようなアクションを実行することを許可されるかを決定する。これには、アクセス制御ルール、ロール、パーミッションの定義が含まれる。役割ベースのアクセス制御（RBAC）と属性ベースのアクセス制御（ABAC）は、一般的に使用される認可モデルである。適切な権限チェックを実施することで、組織は認証されたクライアントが特定のリソースへのアクセスや特定のアクションを実行するために必要な権限を持っていることを保証できる。きめ細かなアクセス制御によって、機密性の高いAPIエンドポイントやデータ、関連するオブジェクトや機能へのアクセスを制限することができる。

オープン・オーソライゼーション（OAuth）プロトコルは、強力な認証と認可のプラクティスの重要なコンポーネントです。OAuthは、ユーザーがユーザー名とパスワードをサードパーティのアプリケーションと直接共有する必要性を排除します。その代わりに、OAuth は限定的でスコープされたパーミッションを表すアクセストークンを付与し、クレデンシャルの盗難や悪用のリスクを低減します。これにより、APIプロバイダはスコープとパーミッションを通じてきめ細かなアクセス制御を定義できるようになり、サードパーティアプリケーションはユーザーによって許可された特定のリソースとアクションにのみアクセスできるようになり、不正アクセスのリスクが低減します。

認証認可メカニズムの不適切な実装は、API セキュリティに以下のような複数の脅威をもたらす可能性がある: 

オブジェクトレベルの認証が壊れている. このセキュリティ脆弱性は、アプリケーションがオブジェクトやデータレベルでのアクセス制御を適切に実施しない場合に発生し、攻撃者が認証チェックを操作したり迂回したりして、アプリケーション内の特定のオブジェクトやデータへの不正なアクセスを許可することを可能にします。オブジェクトの ID を受け取り、そのオブジェクトに対して何らかのアクションを実行する全ての API エンドポイントは、ログインしているユーザが要求されたオブジェクトに対して要求されたアクションを実行する権限を持っていることを検証するために、オブジェクトレベルの認可チェックを実装すべきである。

壊れた認証. APIにおける認証メカニズムはしばしば不正に実装され、攻撃者がユーザーアカウントや機密データに不正にアクセスしたり、不正なアクションを実行したりすることを許してしまう。

オブジェクトプロパティレベルの認可が壊れている。この脅威は、APIがオブジェクト・プロパティ・レベルでのアクセス制御と認可チェックを適切に実施しない場合に発生する。APIエンドポイントは、センシティブでユーザが読むべきではないとされるオブジェクトのプロパティを公開する場合、これらの攻撃に対して脆弱である、過剰なデータ露出と呼ばれることもある。APIエンドポイントが、ユーザーにセンシティブなオブジェクトのプロパティの値を変更、追加、または削除させる場合、これらの攻撃に対する脆弱性もある、大量割り当てと呼ばれることもある。 

• ファンクションレベルの認証が壊れている。この脅威は、APIが関数や操作レベルでの認可チェックを適切に実施せず、攻撃者が認可されていない機能へのアクセスを許してしまうことで発生する。最近のアプリケーションは多くのタイプの機能的な役割とグループを定義し、攻撃者が操作できる複雑なユーザ階層を含むので、適切な認可チェックを実装することは混乱する可能性があります。 
• 機密性の高いビジネスフローへの無制限のアクセス。この攻撃は、APIに適切なアクセス制御や権限チェックが欠けている場合に発生し、攻撃者はAPIによって保護された機密性の高いビジネスフローへのアクセスを自動化することができる。攻撃者は洗練された自動化ツールキットを使用して攻撃を再編成することが多く、ターゲットのウェブアプリが自動化対策によって適切に保護されている場合、APIの背後にあるビジネスロジックをターゲットにする可能性があります。

JSON Webトークン（JWT）は、コンパクトで自己完結的、かつ安全な方法で2者間でデータを転送するオープンスタンダードの手法です。JWTはトークンベースの認証と認可に広く使用されています。JWTを使用することで、ユーザーやクライアントは、リクエストごとに認証情報（例えば、ユーザー名とパスワード）を繰り返し送信する必要なく、APIサーバーに対して自分の身元と承認を証明することができます。このトークン・ベースのアプローチは、セッション・ハイジャックのような潜在的な攻撃にさらされるウィンドウを最小限に抑えることで、セキュリティを強化する。JWTは失効させることができ、有効期限を設定することができます。これは、トークンが無期限に有効であるリスクを軽減する。

JWTの発見と検証は、不正アクセスや改ざんを防ぐためにJWTの正当性を検証するための重要なメカニズムである。JWTの発見には、JWTの検証に使用されるJSONエンコードされた公開鍵または証明書を発見し確認することが含まれ、JWTの検証には、JWTの発行者がAPIに期待される発行者と一致することを確認することが含まれる。これは、トークンが信頼できるソースから来たことを確認するのに役立つ。

API は様々な暗号化技術を使用してクライアントとサーバ間で伝送されるデータを保護し、伝送中に交換される情報の機密性と完全性を確保する。これは HTTP over Secure Sockets Layer (SSL)/Transport Layer Security (TLS)であり、クライアントとサーバ間の転送中のデータを暗号化し、悪意のある第三者からの盗聴や改ざんを防ぎます。SSL/TLSは非対称暗号と対称暗号の両方を使い、転送中のデータの機密性と完全性を保護します。非対称暗号化はクライアントとサーバー間で安全なセッションを確立するために使われ、対称暗号化は安全なセッション内でデータを交換するために使われる。これにより、攻撃者が2つのノード間（この場合はクライアントとAPIサーバー間）でやり取りされるデータを閲覧したり、改ざんしたりすることを防ぐことができる。

しかし、「East-West」トラフィック（ネットワーク内、または組織のインフラ内の異なるサービスやコンポーネント間のマシン間APIコールを指す）にエンドツーエンドの暗号化を提供することは、複数の暗号化キーの生成、配布、管理を必要とするため、困難な場合がある。通信するすべてのコンポーネントが適切なタイミングで適切な鍵を利用できるようにすることは、特に大規模環境では複雑であり、待ち時間を発生させ、エンドツーエンドの暗号化実装のスケーラビリティを制限する可能性がある。

入力検証とサニタイズは、ユーザー入力やAPIなどの外部ソースから受け取ったデータが安全で信頼性が高く、悪意のあるコンテンツがないことを保証し、インジェクション攻撃やその他の悪用を防ぐのに役立ちます。バリデーション・ルールは、何が有効なデータとみなされるかを定義する。これらのルールには、データ型のチェック（例えば、数値、アルファベット、電子メール形式）、長さの制約、フォーマットの要件、およびカスタムのビジネスロジックを含めることができます。入力の妥当性確認が失敗した場合（つまり、データが定義された基準を満たさない場合）、アプリケーションは入力を拒否し、それ以上処理されないようにします。

入力サニタイゼーションとは、潜在的に有害または悪意のあるコンテンツを除去または中和するために、データをクリーニングまたはフィルタリングするプロセスである。入力検証とサニタイズは、さまざまな攻撃、特にインジェクション攻撃からシステムを保護するのに役立つ。インジェクション攻撃は、攻撃者が信頼できないデータや敵対的なデータをコマンドやクエリ言語に挿入したり、ユーザーから提供されたデータがアプリケーションによって検証、フィルタリング、またはサニタイズされない場合に発生し、悪意のあるコマンドの実行につながります。インジェクション攻撃には、NoSQL、OS コマンド、LDAP、SQLインジェクション攻撃の他、攻撃者が JavaScript などの悪意のあるクライアント側スクリプトを他のユーザが閲覧するウェブページに注入するクロスサイトスクリプティング（XSS）があります。

これらのメカニズムは、クライアントがAPIにリクエストできるレートを制御し、APIの乱用や使いすぎを防ぎ、リソースの過剰消費を防ぎ、潜在的なサービス拒否（DoS）攻撃からAPIを保護する。

監査証跡とログは、誰がリクエストを開始したか、どのエンドポイントにアクセスしたか、いつリクエストが発生したかなど、APIリクエストとレスポンスに関する詳細な情報を取得することで、APIアクティビティを可視化する。ログを分析することで、セキュリティチームは、ログイン試行の失敗の繰り返し、予期しないデータアクセス、異常なトラフィックの急増など、API アクティビティの異常または疑わしいパターンを検出することができる。これらの異常は、ハッキングの試みやデータ侵害のようなセキュリティインシデントを示す可能性がある。セキュリティ侵害や不審なアクティビティが発生した場合、監査証跡とログはフォレンジックデータの貴重なソースとしても機能する。

安全なAPIを設計するには、APIと相互作用するユーザーとシステムの身元を確認する強力な認証メカニズムの実装を含む、強固なセキュリティ制御が必要である。認可制御を使用してアクセス権を定義・実施し、認可されたエンティティのみが特定のアクションを実行できるようにする。最小特権の原則に従い、ユーザーとシステムにはタスクの実行に必要な最小限の権限を付与する。APIの誤用や悪用につながる可能性があるため、過剰な権限は避ける。SSL/TLSなどの強力な暗号化を使用して、ネットワーク経由で送信されるデータを保護する。インジェクション攻撃などの一般的なセキュリティ脆弱性を防ぐために、クライアントやその他のソースから受け取ったすべての入力を検証し、サニタイズする。

さらに、脆弱性攻撃からAPIを保護することも重要である。これには、すべてのAPIの依存関係、ライブラリ、フレームワークを最新の状態に保ち、既知のセキュリティ上の弱点に対処するための定期的なパッチ管理が含まれる。DDoS攻撃のリスクを軽減するためには、レート制限とスロットリング機構を実装し、指定された時間枠内で実行できるリクエスト数を制限することが重要だ。ビジネスロジックの悪用もAPIセキュリティの重要な脆弱性である。これらの攻撃は、悪意ある目的を達成するために、アプリケーションの基本的なロジックとプロセスを利用します。例えば、攻撃者は API のビジネスロジックを操作して、特定の機能やリソースに不正にアクセスしたり、機密データを流出させたりする。強力なアクセス制御と認可メカニズムは、認可されたユーザのみが特定のAPIビジネスロジック機能にアクセスできることを保証するのに役立ちます。

一般的に、「最小驚嘆の原則」に従うこと。つまり、API を設計するときに、ユーザや開発者が最も驚かない、あるいは驚かないようなメソッドや規約を選択することである。APIの利用者は、セキュリティ機能がどのように機能し、何が期待されているかを明確に理解する必要があります。ユーザは、セキュリティ機能がユーザの期待や確立された業界の慣行と一致していれば、間違いを犯したり、誤解したりする可能性は低くなります。

ランタイム検知システムは、機械学習と行動分析を採用し、正常なAPI動作のベースラインを確立し、システムがこのベースラインからの逸脱を検知するとアラートを提供する。これらの異常には、APIリクエストの異常なパターン、予期しないデータフロー、不正アクセスの試行などが含まれる。実行時検知の目的は、開発中や配備中に適用される静的なセキュリティ対策に依存するのではなく、セキュリティ上の脅威や脆弱性がリアルタイムで発生したときに、それを特定し対応することである。

APIゲートウェイは、APIトラフィックの集中制御、セキュリティ、管理のポイントを提供することで、APIエコシステムの保護層として機能する。API ゲートウェイは、認証と認可ポリシーの実施、API の悪用を防ぐためのトラフィックフィルタリング、レート制限、スロットリングなど、多くの一般的な脅威や運用上の課題から基礎となる API インフラストラクチャを保護するセキュリティと管理のレイヤーとして機能する。APIゲートウェイはAPIトラフィックとアクティビティの詳細なログを取得するため、監査やインシデントの調査に不可欠なリアルタイムのロギングとモニタリング機能も提供する。

CORSは、JavaScriptのようなクライアントサイド技術を使用するウェブアプリケーションによるクロスオリジン（異なるドメインまたはオリジン間）リクエストを制御および管理するために、ウェブブラウザによって実装されるセキュリティポリシーのセットです。CORSは、Webサーバーがクロスオリジンリクエストにどのように応答すべきかを管理する一連のHTTPヘッダーを強制することで機能します。CORSは、ウェブページがAPI、ウェブサービス、または他のドメインでホストされているアセットからのリソースを要求し、やり取りできるようにする一方で、ウェブのセキュリティを確保するために不可欠です。

インターネット上に公開するAPIを保護する場合、CORSポリシーを使用してAPIへのアクセスを許可するドメインを制御し、信頼できるドメインのみが保護されたリソースにアクセスできるようにする。クロスサイトリクエストフォージェリ（CSRF）攻撃やその他のセキュリティリスクにAPIをさらすような、過度に寛容な設定は避ける。

定期的なテスト、モニタリング、ソフトウエアのパッチ適用は、プロアクティブなAPIセキュリティ戦略の不可欠な要素である。継続的なモニタリングの重点分野には、API の弱点、脆弱性、及び設定ミスを特定するのに役立つ、定期的な脆弱性スキャン及び侵入テストを含めるべきである。一方、静的コード解析及び動的アプリケーションセキュリティテスト（DAST）は、API のコードベース及び実行時の動作にセキュリティ上の弱点がないか評価する。オペレーティングシステム、ウェブサーバ、ライブラリ、フレームワークなど、API スタックで使用されるソフトウエアコンポーネントを定期的に更新し、既知の脆弱性に対処する。

Eコマース企業や決済ゲートウェイプラットフォームは、機密データや金融取引を大量に処理するため、堅牢なAPIセキュリティが不可欠です。Eコマース企業は、ログイン、商品検索と表示、ショッピングカート、配送料金の見積もり、支払い処理など、ほとんどの顧客接点でAPIを採用しています。さらに、APIは、過去の顧客に対する新規購入の推奨、レビューや評価の追跡、チャットボットとの対話など、顧客体験を強化するためのビジネスも支援している。

APIはモバイルアプリと様々なサービス、データソース、サードパーティプラットフォームとの橋渡しの役割を果たすため、APIセキュリティはモバイルアプリの統合にとって決定的に重要です。モバイルアプリは多くの場合、APIを介してバックエンドサーバや外部サービスとデータを交換する必要があり、APIはアプリがデータを要求・受信するための構造化された方法を提供します。モバイルアプリとAPIとの安全な相互作用を確保することは、セキュリティ侵害を防止し、認証とアクセス制御を保護し、アプリと接続されたシステムの両方の全体的なセキュリティ体制を維持するために不可欠です。

医療データには通常、医療記録、診断、治療計画、請求詳細などの機密性の高い患者情報が含まれ、APIは医療提供者、支払者、その他の利害関係者間での機密性の高い患者情報の共有を促進します。これらのAPIのセキュリティを確保することは、患者のプライバシーを保護し、ヘルスケア規制（米国のHIPAAなど）を遵守し、ヘルスケアデータの完全性を維持するために極めて重要です。

堅牢なAPIセキュリティは、金融サービスデータの機密性、完全性、可用性を確保し、オープンバンキングソリューションを運用するための基本要件です。APIセキュリティは、さまざまな金融機関、決済プロバイダー、フィンテック企業間の金融データの安全な交換を可能にする上で中心的な役割を果たすだけでなく、EUのPayment Services Directive 2や米国のPCI DSSなどの規制で義務付けられているデータ暗号化やアクセス制御の要件への準拠を確保する上でも役立ちます。さらに、APIセキュリティは、不正行為の防止や、オープンバンキングのイニシアチブを支えるサードパーティの統合を保護する上でも重要な役割を果たします。

APIセキュリティはIoTの重要な要素であり、IoTデバイス、アプリケーション、サービスが安全に通信し、データを保護し、エコシステム全体の整合性を維持できるようにする。IoTデバイスは、APIを通じて相互、エッジゲートウェイ、クラウドプラットフォームと通信します。APIセキュリティは、デバイスと他のエコシステムコンポーネント間で交換されるデータが機密性を保ち、認証され、不正アクセスから保護されることを保証します。また、IoTネットワークには固有のIDを持つ多数のデバイスが含まれることが多く、APIセキュリティはデバイスID管理を提供してデバイスIDの完全性を維持し、なりすましや不正アクセスを防止することができる。IoT エコシステムには、デバイスのオンボーディング、プロビジョニング、アップデート、セキュアなデコミッショニングを管理する能力も必要であり、API セキュリティは、セキュアなファームウェア・アップデートを含むデバイス・ライフサイクル全体の管理をサポートするのに役立つ。

AIとMLの膨大な処理能力は、APIセキュリティを根本的に変革する態勢を整えている。機械学習モデルは、通常のAPI使用パターンのベースラインを作成することができ、これらのベースラインからの逸脱やその他の異常は、潜在的なセキュリティ侵害を防止するために、アラートや自動応答をトリガーすることができます。AIはまた、従来のルールベースのシステムでは見逃してしまうような複雑な攻撃パターンやゼロデイ脆弱性を特定することもできる。AIシステムはますます賢くなり、変化する脅威に対応して適応・進化するため、新しい高度な攻撃への対策がより効果的になり、過去のデータや新たなトレンドに基づいて潜在的なセキュリティ脅威を予測できる可能性がある。このプロアクティブなアプローチにより、セキュリティチームは脆弱性が悪用される前に対処できるようになる。

ゼロトラストモデルは「決して信用せず、常に検証する」という原則を提唱しており、APIセキュリティに適用する場合、APIエンドポイントとサービスをリクエストごとに認証と認可を必要とする別個のエンティティとして扱うことを意味する。ゼロトラストは、ネットワークの内外を問わず、いかなるエンティティもデフォルトで信頼されるべきではなく、リソースへのアクセスは知る必要があるベースで許可されるべきであると仮定する。これには、特定のタスクや役割に必要な権限のみを付与する最小権限の原則をAPIアクセスに導入し、変化する要件に基づいてアクセス権限を定期的に見直して更新することが含まれる。ゼロトラストは、最初のアクセスが許可された後も、デバイス、ユーザー、アプリケーションの継続的な検証を実施し、行動とデバイスのコンプライアンスに基づいて信頼レベルを再評価する。

ブロックチェーンの核となる機能は、一度ブロックチェーンに追加されたデータの不変性である。これにより、APIを通じてアクセスされるデータは改ざんされないため、悪意のある行為者が発見されずにデータを改ざんすることは事実上不可能となる。ブロックチェーンはまた、資産、アクセス権、またはクレデンシャルをトークン化し、APIへのアクセスを管理・制御するために使用することができ、アクセス制御管理を簡素化することができる。APIはスマートコントラクトを使用してアクセス制御ポリシーを実施し、許可されたユーザーまたはアプリケーションのみが特定のAPIリソースとやり取りできるようにすることができる。データとトランザクションを分散化することで、ブロックチェーンは中央集中型のサーバーやデータベースといった単一障害点への依存を減らす。これにより、攻撃者がAPIのセキュリティを侵害することがより困難になる。