API セキュリティとは何ですか? 主なタイプと使用例

API (アプリケーション プログラミング インターフェイス) は、アプリケーションが他のアプリケーション、サービス、またはプラットフォームと通信してデータを交換する機能を容易にするため、最新のアプリケーションの開発に不可欠です。 企業は外部プラットフォームやサードパーティのサービスと簡単に統合し、さまざまなコンポーネントを接続することで包括的なソリューションを構築できます。 これにより、アプリ開発に対するモジュール式のアプローチが促進され、開発者は既存のサービスと機能を活用し、コードの再利用を促進し、開発サイクルを加速し、生産性を向上させることができます。 API は、ビジネス ロジックを分離および分散化する機能を備えているため、最新のアプリの基礎となり、従来のアプリケーションを API ベースのアーキテクチャに進化させるために使用されるメカニズムです。 

コンピューティングのほぼすべての側面と同様に、開発者がパフォーマンスと信頼性を向上させる方法を模索する中で、API テクノロジーは過去 25 年間にわたって変化してきました。 API の設計哲学とデータ表現は進化しており、それに伴いデータとトラフィックを保護する方法も進化しています。 一般的な API アーキテクチャのタイムラインは、おおよそ次のようになります。

• SOAP API (1998-2010)。 Simple Objects Access Protocol (SOAP) API は、デジタル署名と XML 形式のデータの暗号化を使用して、メッセージ レベルでセキュリティを適用します。 メッセージ レベルのセキュリティは、通常、REST API アーキテクチャ スタイル (以下) のセキュリティよりも包括的です。 しかし、移植性が高く評価されている一方で、メッセージ レベルのセキュリティは現在、レガシー Web サービスでのみ使用されています。
• REST API (2010 年現在)。 過去 10 年間で、Representational State Transfer ( REST ) が API の最も人気のあるアーキテクチャ スタイルになりました。 現在、ほとんどの Web API は REST API です。 REST では、リソースは一意の HTTP URI によって識別され、アクセス制御ルールは HTTP 動詞と HTTP URI の組み合わせに基づいて決定されます。
• GraphQL API (2020 年以降) GraphQL は、API 用の新しいクエリ言語です。 これにより、フロントエンド開発者は、アプリケーションに最適な方法で API クエリをカスタマイズして制御できるようになります。 すべてのリソースは単一の URI を通じてアクセスされます。この柔軟性と制御性により、GraphQL はますます人気が高まっています。

API は、アクセス可能性、使用方法、対象ユーザーに基づいていくつかのタイプに分類できます。

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

また、API はリスクの対象範囲を拡大し、マルチクラウド アーキテクチャ全体にわたる相互依存性の性質により、予期しないリスクをもたらします。 これはAPI スプロールと呼ばれ、API エコシステムのセキュリティに極めて大きな脅威をもたらす可能性があります。 Web アプリと同様に、API は脆弱性の悪用、自動化された脅威による悪用、サービス拒否、構成ミス、認証および承認制御を回避する攻撃の影響を受けやすくなります。

最新のマイクロサービス アーキテクチャの採用が増えると、API スパーリングが悪化する可能性があります。これは、このようなアーキテクチャでは、インターフェイス (南北トラフィック) とマイクロサービス間 (東西トラフィック) の両方の通信に多数の API が使用されるためです。

API の拡散に対抗するための戦術には次のものがあります。

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

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

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

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

Open Authorization (OAuth) プロトコルは、強力な認証および承認プラクティスの重要なコンポーネントです。 OAuth を使用すると、ユーザーがユーザー名とパスワードをサードパーティのアプリケーションと直接共有する必要がなくなります。 代わりに、OAuth は限定された範囲の権限を表すアクセス トークンを付与し、資格情報の盗難や悪用のリスクを軽減します。 これにより、API プロバイダーはスコープと権限を通じてきめ細かいアクセス制御を定義できるようになり、サードパーティのアプリケーションがユーザーによって承認された特定のリソースとアクションにのみアクセスできるようにして、不正アクセスのリスクを軽減できます。

認証および承認メカニズムの不適切な実装は、API セキュリティに対する次のような複数の脅威につながる可能性があります。 

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

認証が壊れています。 API の認証メカニズムは不適切に実装されることが多く、攻撃者がユーザー アカウントや機密データに不正にアクセスしたり、不正なアクションを実行したりできるようになります。 

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

• 機能レベルの認証が壊れています。 この脅威は、API が機能レベルまたは操作レベルで承認チェックを適切に実施できず、攻撃者が許可されていない機能にアクセスできる場合に発生します。 最近のアプリケーションでは、多くの種類の機能ロールとグループが定義され、攻撃者が操作できる複雑なユーザー階層が含まれるため、適切な承認チェックを実装するのは混乱を招く可能性があります。 
• 機密性の高いビジネス フローへの無制限のアクセス。 この攻撃は、API に適切なアクセス制御や承認チェックがない場合に発生し、攻撃者は API を基盤とする機密性の高いビジネス フローへのアクセスを自動化できます。攻撃者は高度な自動化ツールキットを使用して攻撃を改良することが多く、ターゲットの Web アプリが自動化対策によって適切に保護されている場合は、API の背後にあるビジネス ロジックをターゲットにする可能性があります。  

JSON Web Token (JWT) は、コンパクトで自己完結型かつ安全な方法で 2 者間でデータを転送するオープン スタンダード方式です。 JWT はトークンベースの認証と承認に広く使用されています。 JWT を使用すると、ユーザーまたはクライアントは、リクエストごとに資格情報 (ユーザー名やパスワードなど) を繰り返し送信する必要なく、API サーバーに対して ID と承認を証明できるため、ネットワーク上で機密情報が公開されることを回避できます。 このトークンベースのアプローチは、セッションハイジャックなどの潜在的な攻撃の露出時間を最小限に抑えることでセキュリティを強化します。 JWT は取り消すことができ、有効期限が設定されており、有効期限を過ぎると無効になります。 これにより、トークンが無期限に有効になるリスクが軽減されます。 

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

API はさまざまな暗号化技術を使用して、クライアントとサーバー間で送信されるデータを保護し、送信中に交換される情報の機密性と整合性を保証します。 API リクエストとレスポンスを保護するために使用される主な暗号化プロトコルは HTTPS です。これは、Secure Sockets Layer (SSL)/Transport Layer Security (TLS) を介した HTTP であり、クライアントとサーバー間の転送中のデータを暗号化して、悪意のある第三者による盗聴や改ざんを防止します。 SSL/TLS は、非対称暗号化と対称暗号化の両方を使用して、転送中のデータの機密性と整合性を保護します。 非対称暗号化は、クライアントとサーバー間の安全なセッションを確立するために使用され、対称暗号化は、安全なセッション内でデータを交換するために使用されます。 これにより、攻撃者が 2 つのノード間 (この場合はクライアントと API サーバー間) で交換されるデータを表示したり改ざんしたりすることを防ぎます。 

ただし、ネットワーク内または組織のインフラストラクチャ内の異なるサービスやコンポーネント間のマシン間 API 呼び出しを指す「East-West」トラフィックにエンドツーエンドの暗号化を提供することは、複数の暗号化キーの生成、配布、管理が必要になるため、困難な場合があります。 すべての通信コンポーネントに対して適切なキーが適切なタイミングで利用可能であることを保証することは、特に大規模な環境では複雑であり、遅延を引き起こし、エンドツーエンドの暗号化実装のスケーラビリティを制限する可能性があります。 

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

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

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

監査証跡とログは、リクエストを開始したユーザー、アクセスされたエンドポイント、リクエストが発生した日時など、API リクエストと応答に関する詳細な情報をキャプチャすることで、API アクティビティの可視性を提供します。 ログを分析することで、セキュリティ チームは、ログイン試行の繰り返しの失敗、予期しないデータ アクセス、異常なトラフィックの急増など、API アクティビティの異常なパターンや疑わしいパターンを検出できます。 これらの異常は、ハッキングの試みやデータ侵害などのセキュリティ インシデントを示している可能性があります。 セキュリティ侵害や疑わしいアクティビティが発生した場合、監査証跡とログは法医学的データの貴重なソースとしても機能します。 

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

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

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

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

API ゲートウェイは、API トラフィックの制御、セキュリティ、管理の集中ポイントを提供することで、API エコシステムの保護レイヤーとして機能します。 これらは、認証および承認ポリシーの適用、トラフィックのフィルタリング、レート制限、API の不正使用を防ぐためのスロットリングなど、多くの一般的な脅威や運用上の課題から基盤となる API インフラストラクチャを保護するセキュリティおよび管理レイヤーとして機能します。 API ゲートウェイは API トラフィックとアクティビティの詳細なログをキャプチャするため、監査やインシデントの調査に不可欠なリアルタイムのログ記録と監視機能も提供します。 

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

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

定期的なテスト、監視、ソフトウェアのパッチ適用は、プロアクティブな API セキュリティ戦略に不可欠な要素です。 継続的な監視の重点分野には、API の弱点、脆弱性、および誤った構成を特定するために、スケジュールされた脆弱性スキャンと侵入テストを含める必要があります。また、静的コード分析と動的アプリケーション セキュリティ テスト (DAST) では、セキュリティ上の弱点について API コードベースとランタイム動作を評価します。 パッチが適用されていないソフトウェアは攻撃者の主な標的となる可能性があるため、既知の脆弱性に対処するために、オペレーティング システム、Web サーバー、ライブラリ、フレームワークなど、API スタックで使用されるソフトウェア コンポーネントを定期的に更新します。

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

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

ヘルスケア データには通常、医療記録、診断、治療計画、請求の詳細などの患者の機密情報が含まれており、API により、医療提供者、支払者、その他の関係者間での患者の機密情報の共有が容易になります。 これらの API のセキュリティを確保することは、患者のプライバシーを保護し、医療規制 (米国の HIPAA など) を遵守し、医療データの整合性を維持するために不可欠です。

堅牢な API セキュリティは、金融サービス データの機密性、整合性、可用性、およびオープン バンキング ソリューションの運用を確保するための基本的な要件です。 APIセキュリティは、さまざまな金融機関、決済プロバイダー、フィンテック企業間での金融データの安全な交換を可能にする上で中心的な役割を果たすだけでなく、EUの決済サービス指令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 セキュリティを侵害することがより困難になります。