APIセキュリティとは？主な種類とユースケース

APIは最新のアプリケーションアーキテクチャで重要な役割を果たす一方、攻撃者の標的となるケースが増えています。APIセキュリティに共通する弱点を理解し、攻撃や侵害からAPIをプロアクティブに保護するための戦略をご確認ください。

APIセキュリティの理解

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は、サービス、プラットフォーム、またはアプリケーションの特定の機能やデータへのアクセスを提供するよう設計されており、外部の開発者、サードパーティ製ソフトウェアアプリケーション、一般ユーザーに公開されています。パブリックAPIは、製品やサービスの機能を拡張し、サードパーティの開発者によるアプリケーションや統合機能の構築を促進するためによく使用されます。
• パートナーAPIはパブリックAPIの一種で、特定の機能やデータへのアクセスを制御するため、組織が指定したパートナー、関連会社、顧客、またはB2B（企業間取引）の協業先のみが利用できます。通常、これらのAPIへのアクセスは、認証および認可の仕組みを通じて付与されます。
• サードパーティAPIは、他のアプリケーションに統合できる機能を提供するために、外部の組織や個人によって開発されます。これらのAPIを使用すると、開発者は外部のサービス、ライブラリ、データソースにアクセスして、自身のアプリケーションを強化できます。既存のサービスや機能を活用することで時間と労力を削減できるため、ソフトウェア開発で広く利用されています。サードパーティAPIの例としては、カスタムマップを表示する地図APIや、旅行・観光関連のWebページに地域の天気予報を表示する気象APIなどがあります。

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

また、APIはリスク領域を拡大します。特に、マルチクラウドアーキテクチャ全体にわたる相互依存関係の性質上、予期しないリスクが生じます。これは「APIスプロール」と呼ばれ、APIエコシステムのセキュリティに極めて深刻な脅威をもたらす可能性があります。Webアプリと同様に、APIも脆弱性の悪用、自動化された脅威による不正利用、サービス拒否、設定ミス、認証および認可の制御を回避する攻撃の影響を受ける可能性があります。

最新のマイクロサービスアーキテクチャの採用が進むと、APIスプロールが深刻化する可能性があります。これは、このようなアーキテクチャでは、インターフェースとの通信（南北トラフィック）とマイクロサービス間の通信（東西トラフィック）の両方に多数のAPIが使用されるためです。

APIスプロールへの対策には、次のようなものがあります。

• APIガバナンス戦略の導入
• APIディスカバリのための信頼できる唯一の情報源を構築
• 適切なバージョン管理とドキュメント整備の徹底
• APIトラフィックに関するメトリクスと可視性の提供
• APIセキュリティを大規模に適用

これらの戦術と実装方法について詳しくは、「APIの無秩序な拡大に対処する5つの方法（対策が必要な理由）」をご覧ください。

不十分なAPIセキュリティがもたらすリスク

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

APIセキュリティの主な種類

堅牢なAPIセキュリティ対策が必要です。これは、不正なアクセス、改ざん、漏えいからデータを保護してプライバシーを確保し、ユーザーやステークホルダーからの信頼を維持するとともに、APIの機密性、完全性、可用性を確保するためです。

ただし、APIとアプリは同じ脅威の多くから標的とされるため、セキュリティチームはアプリケーションとAPIを統合したセキュリティ戦略を検討する必要があります。OWASPの「2023 API Security Top 10」によると、セキュリティソリューションを実装する際に考慮すべき、アプリとAPIに共通するセキュリティリスクがあります。たとえば、次のようなものです。

• 脆弱な認証／認可制御
• 設定ミス
• ビジネスロジックの悪用（クレデンシャルスタッフィング、アカウント乗っ取り）
• サーバーサイドリクエストフォージェリ（SSRF）

その結果、アプリとAPIの両方で共通機能を共有する、アプリケーションとAPIを統合したセキュリティ戦略が実現します。同じ脅威やリスクに対処するために2倍の数のサービスを運用することは非効率であり、不必要な複雑さを招きます。アプリケーションとAPIを統合したセキュリティ戦略は、運用面、財務面、アーキテクチャ面でより合理的です。

APIセキュリティの主なユースケースは次のとおりです。

認証と認可

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

Open Authorization（OAuth）プロトコルは、強固な認証と認可を実践するうえで重要な要素です。OAuthを使用すると、ユーザーがユーザー名とパスワードをサードパーティ製アプリケーションに直接共有する必要がなくなります。代わりに、OAuthは限定されたスコープの権限を表すアクセストークンを付与し、認証情報の窃取や不正使用のリスクを軽減します。また、APIプロバイダーはスコープと権限を通じてきめ細かなアクセス制御を定義できます。これにより、サードパーティ製アプリケーションは、ユーザーが許可した特定のリソースと操作にのみアクセスできるため、不正アクセスのリスクが軽減されます。

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

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

認証の不備。APIの認証メカニズムは不適切に実装されることが多く、攻撃者がユーザーアカウントや機密データに不正アクセスしたり、不正な操作を実行したりする可能性があります。

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

• 機能レベルの認可不備。この脅威は、APIが機能または操作レベルで認可チェックを適切に実施できず、攻撃者が認可されていない機能にアクセスできる場合に発生します。最新のアプリケーションでは、さまざまな種類の機能ロールやグループを定義できるほか、攻撃者に悪用される可能性のある複雑なユーザー階層が存在するため、適切な認可チェックの実装は複雑になることがあります。
• 機密性の高いビジネスフローへの無制限のアクセス。 この攻撃は、APIに適切なアクセス制御や認可チェックがなく、攻撃者がAPIを基盤とする機密性の高いビジネスフローへのアクセスを自動化できる場合に発生します。攻撃者は高度な自動化ツールキットを使用して攻撃手法を組み替えることが多く、標的のWebアプリが自動化対策によって十分に保護されている場合は、APIの背後にあるビジネスロジックへと標的を移す可能性があります。

JSON Web Token（JWT）

JSON Web Token（JWT）は、2者間でデータをコンパクトかつ自己完結型の安全な形式で転送するためのオープン標準方式です。JWTは、トークンベースの認証と認可に広く使用されています。JWTを使用すると、ユーザーまたはクライアントは、リクエストのたびに認証情報（ユーザー名やパスワードなど）を送信することなく、APIサーバーに対して自身のIDと権限を証明できます。これにより、機密情報がネットワーク上に露出することを回避できます。このトークンベースの方式では、セッションハイジャックなどの潜在的な攻撃にさらされる時間を最小限に抑えることで、セキュリティを強化します。JWTは失効させることができ、有効期限も設定されます。有効期限を過ぎると無効になるため、トークンが無期限に有効であり続けるリスクを軽減できます。

JWTの検出と検証は、JWTの正当性を確認し、不正アクセスや改ざんを防止するための重要な仕組みです。JWTの検出では、JWTの検証に使用するJSON形式でエンコードされた公開鍵または証明書を特定して確認します。一方、JWTの検証では、JWTの発行者がAPIで想定されている発行者と一致することを確認します。これにより、トークンが信頼できるソースから発行されたことを確認できます。

データ暗号化

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

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

入力の検証とサニタイズ

入力の検証とサニタイズは、ユーザー入力やAPIなどの外部ソースから受信したデータの安全性と信頼性を確保し、悪意のあるコンテンツを排除することで、インジェクション攻撃やその他のエクスプロイトの防止に役立ちます。検証ルールでは、有効と見なすデータを定義します。これらのルールには、データ型のチェック（数値、英字、メールアドレス形式など）、長さの制約、形式要件、カスタムビジネスロジックを含めることができます。入力の検証に失敗した場合（データが定義済みの基準を満たしていない場合）、アプリケーションは入力を拒否し、それ以降の処理を行いません。

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

レート制限とスロットリング

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

監査証跡とログ記録

監査証跡とログは、リクエストの実行者、アクセスされたエンドポイント、リクエストの発生日時など、APIのリクエストとレスポンスに関する詳細情報を記録することで、APIアクティビティを可視化します。セキュリティチームはログを分析することで、ログインの失敗が繰り返される、予期しないデータアクセスが発生する、トラフィックが異常に急増するといった、通常とは異なる、または不審なAPIアクティビティのパターンを検出できます。こうした異常は、ハッキングの試みやデータ侵害などのセキュリティインシデントを示している可能性があります。セキュリティ侵害や不審なアクティビティが発生した場合、監査証跡とログはフォレンジックデータの貴重な情報源としても役立ちます。

APIセキュリティのベストプラクティス

APIのライフサイクルでは、設計から開発、デプロイに至るすべてのフェーズにセキュリティを組み込む必要があります。トップダウン型のセキュリティアプローチで使用される検出ツールは不可欠な要素ですが、適切なAPIセキュリティは、APIを構築してデプロイするチームから始まります。このアプリとAPIのセキュリティアプローチは「シフトレフト」と呼ばれ、ソフトウェア開発ライフサイクル（SDLC）の早い段階でセキュリティ制御を適用し、CI/CDパイプラインで自動化できます。

以下の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）

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

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

定期的なテスト、監視、更新

定期的なテスト、監視、ソフトウェアへのパッチ適用は、プロアクティブなAPIセキュリティ戦略に不可欠な要素です。継続的な監視では、APIの弱点、脆弱性、設定ミスの特定に役立つよう、計画的な脆弱性スキャンとペネトレーションテストを重点項目に含める必要があります。また、静的コード解析と動的アプリケーションセキュリティテスト（DAST）を実施し、APIのコードベースと実行時の動作にセキュリティ上の弱点がないか評価します。パッチが適用されていないソフトウェアは攻撃者の主要な標的となる可能性があるため、既知の脆弱性に対処するには、オペレーティングシステム、Webサーバー、ライブラリ、フレームワークなど、APIスタックで使用するソフトウェアコンポーネントを定期的に更新してください。

API保護のユースケース

Eコマースと決済ゲートウェイ

Eコマース企業や決済ゲートウェイプラットフォームは、大量の機密データや金融取引を処理するため、堅牢なAPIセキュリティが不可欠です。Eコマース企業は、ログイン、商品の検索と表示、ショッピングカート、配送料の見積もり、決済処理など、顧客との接点の大半でAPIを利用しています。さらにAPIは、既存顧客への新たな購入商品の提案、レビューや評価の追跡、チャットボットとの対話などを通じて、顧客体験の向上にも役立ちます。

モバイルアプリ連携

APIは、モバイルアプリと各種サービス、データソース、サードパーティプラットフォームをつなぐ役割を果たすため、モバイルアプリの統合においてAPIセキュリティは極めて重要です。モバイルアプリでは、多くの場合、APIを介してバックエンドサーバーや外部サービスとデータを交換する必要があります。APIは、アプリが構造化された方法でデータを要求し、受信できるようにします。モバイルアプリとAPI間の安全な連携を確保することは、セキュリティ侵害の防止、認証とアクセス制御の保護、ならびにアプリと接続先システム双方の全体的なセキュリティ態勢の維持に不可欠です。

医療データ交換

医療データには通常、医療記録、診断、治療計画、請求情報など、機密性の高い患者情報が含まれます。APIは、医療提供者、保険者、その他の関係者間で、こうした患者情報を共有するために利用されます。患者のプライバシーを保護し、米国のHIPAAなどの医療関連規制に準拠し、医療データの完全性を維持するには、これらのAPIのセキュリティを確保することが極めて重要です。

金融サービスとオープンバンキング

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

IoT（モノのインターネット）エコシステム

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

APIセキュリティの未来

APIセキュリティは、変化するテクノロジー環境や、ますます増加・高度化するサイバー脅威に対応して進化し続けるため、常に変動する課題です。以下では、APIセキュリティの将来を形作る可能性のある主なトレンドを紹介します。

APIセキュリティにおけるAIと機械学習

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

API向けゼロトラストアーキテクチャ

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

ブロックチェーンと分散型API

ブロックチェーンの中核的な特長は、一度追加されたデータが改変できないことです。これにより、APIを介してアクセスするデータの改ざんを防止し、悪意のある攻撃者が検知されずにデータを変更することは事実上不可能になります。また、ブロックチェーンでは資産、アクセス権、認証情報をトークン化できます。これらのトークンを使用してAPIへのアクセスを管理・制御することで、アクセス制御の管理を簡素化できます。APIでは、スマートコントラクトを使用してアクセス制御ポリシーを適用し、許可されたユーザーまたはアプリケーションのみが特定のAPIリソースを操作できるようにすることも可能です。ブロックチェーンはデータとトランザクションを分散化することで、集中型サーバーやデータベースなどの単一障害点への依存を軽減します。その結果、攻撃者がAPIのセキュリティを侵害することがより困難になります。

F5が支援できること

APIは、システムと外部プラットフォームやサードパーティサービスとの容易な統合を可能にし、複数のコンポーネントを接続して包括的なソリューションを構築できるため、最新のアプリ開発の基盤となっています。一方で、APIはアプリの攻撃対象領域を拡大します。特に、マルチクラウドアーキテクチャ全体にわたる相互依存関係の性質上、予期しないリスクをもたらします。APIを攻撃や侵害から保護するには、堅牢なAPIセキュリティ対策が必要です。

F5は、APIの管理を容易にし、セキュリティを強化するソリューションを提供します。F5 Web Application and API Protection (WAAP) solutionsは、WAF、L3～L7 DDoS緩和、ボット対策を含む包括的な保護により、最新アプリの攻撃対象領域全体を防御し、自動化された脅威や不正行為から保護します。分散型プラットフォームにより、ホスティング先を問わず、アプリとAPIの環境全体に一貫したポリシーを容易に導入し、セキュリティを拡張できます。

F5 Distributed Cloud API Securityは、アプリケーションにマッピングされたすべてのAPIエンドポイント（攻撃者に狙われることの多いシャドーAPIを含む）を自動的に特定してAPIを保護し、APIセキュリティポリシーの設定と導入にかかる時間を短縮します。このソリューションはAIとMLを活用して異常なアクティビティや挙動を監視し、不審なリクエストやエンドポイントをリアルタイムでブロックします。Distributed Cloud API SecurityのSaaSベースのポータルにより、管理と可視化が容易になります。ユーザーは、最新のアプリケーションを保護するAPI防御について、監視に加え、脅威分析、フォレンジック、トラブルシューティングを詳細に行えます。

F5 NGINXは、APIのセキュリティを確保し、継続的に保護するための複数のソリューションを提供しています。その1つが、包括的な保護によってセキュリティ侵害を減らし、悪意のあるユーザーにさらされるリスクを抑えるF5 NGINX App and API Security Solutionsです。主なメリットには、レイヤー7攻撃からの保護、エンドツーエンド暗号化、シングルサインオン（SSO）、楕円曲線暗号、API認証、DDoS緩和が含まれます。

Kubernetesアプリ向けF5 NGINXゼロトラストセキュリティソリューションは、複雑さやオーバーヘッドを増やすことなく、エッジからクラウドまでKubernetesアプリとAPIを保護します。また、F5 NGINX PlusはエンタープライズグレードのAPIゲートウェイとして導入でき、F5 NGINX App ProtectはWAFおよびDoS攻撃に対する保護を提供します。