APIセキュリティ

APIセキュリティとは

APIセキュリティとは、アプリケーションが最も機密性の高いデータをやり取りするAPIレイヤーにおいて、脅威を防ぎ、軽減するための取り組みです。APIがデジタル体験や社内システムの中核を担う今、わずかな脆弱性でも重大な情報漏洩やサービスの中断を引き起こすリスクがあります。

効果的なAPIセキュリティ戦略では、利用者が操作するエンドポイントだけでなく、APIが接続するバックエンドサービスや環境、データストアもあわせて保護する必要があります。こうした理由から、多くの先進的な組織ではセキュリティをライフサイクルの初期段階から組み込む「シフトレフト」の考え方を取り入れています。

ここでは、APIファーストを採用するチームが、なぜ開発の初期段階からセキュリティを重視するのかを掘り下げるとともに、よくある脆弱性を紹介し、PostmanのAPIセキュリティルールやBYOK暗号化などの機能が、スケールに応じてAPIとデータをどのように保護するかを見ていきます。

APIセキュリティの「シフトレフト」アプローチは、APIファースト開発をどう支えるか？

APIは現代のソフトウェアにおける構成要素であり、多くの組織が新機能の実現やビジネス目標の達成を目的にAPIへの注力を強めています。この傾向は、Postmanの「2022年版State of the API report」にも表れており、回答者の89％が今後1年間でAPIへの投資が「増加」または「現状維持」と回答しています。また、APIセキュリティの重要性に対する認識も高まっており、50％の回答者が「APIセキュリティは4大優先事項のひとつ」と回答し、70％以上が「サードパーティAPIと統合する際、セキュリティが意思決定に大きな影響を与える」と答えています。

こうした中で、一部の組織はAPIライフサイクルのごく初期段階からセキュリティを優先するアプローチを採用し、セキュリティ上の懸念に対応しています。この戦略では、APIの設計段階から潜在的なセキュリティリスクを想定し、開発およびデプロイの過程で継続的なセキュリティチェックを実施することが求められます。このような「シフトレフト」型のセキュリティアプローチは、APIファースト企業に広く見られる特徴です。APIファースト企業では、アプリケーションや統合機能の構築に先立ってAPIを設計・実装します。こうした計画的な姿勢により、チームは反復開発を迅速に進め、問題を早期に発見・修正し、生産性の向上を実現できるのです。

代表的なAPIセキュリティの脅威と脆弱性とは？

APIは現代のビジネスにおいて欠かせない存在となっており、その重要性の高まりとともに、攻撃者からの標的にもなりつつあります。Open Web Application Security Project（OWASP）は、すでにWebアプリケーションに対する一般的なセキュリティ脅威のトップ10リストを公開していますが、APIを取り巻くリスクの増加を受けて、APIセキュリティに特化した「トップ10リスク」を追跡・更新する専用プロジェクトも新たに立ち上げました。これら2つのリストは幅広い脆弱性をカバーしており、大まかに次のようなカテゴリに分類できます。

セキュリティ衛生の不備

これは最も基本的でありながら、同時に最も重要な脆弱性カテゴリのひとつです。セキュリティ衛生が保たれていないと、本来は容易に防げたはずの重大な情報漏洩につながる可能性があります。たとえば、トークンやAPIキーを、APIクライアントライブラリのソースコードやGitの履歴、ドキュメントなどにハードコーディングしたり、含めたりしてはいけません。また、APIがHTTPベースのREST APIであれ、ProtobufベースのgRPC APIであれ、すべての通信にはTransport Layer Security（TLS）による暗号化を施すことが重要です。

認証と認可の脆弱性

APIでは、利用者の役割に応じて異なる権限が与えられるのが一般的です。そのため、認証や認可に関する不備は、許可されていない操作やデータへのアクセスを可能にし、深刻なセキュリティリスクを引き起こす可能性があります。

こうした問題がAPIに持ち込まれる経路はさまざまです。たとえば、あるリソースが利用者の認可範囲内であることを確認するメソッドレベルの認可チェックが省略されていると、意図しない読み書きが行われるリスクがあります。また、APIエンドポイント単位で認可を設定していても、個々のオブジェクトにより細かなアクセス制御が設けられている場合、十分な確認が行われなければアクセス違反につながるおそれがあります（これは次に述べる「読み取りと書き込みの粒度の欠如」にも関係しています）。さらに、認証フローにおいて公開鍵暗号のような暗号技術を使用していない場合、なりすましのリスクが生じる可能性もあります。

読み取りと書き込みの粒度の欠如

データオブジェクトにはさまざまなプロパティがあり、機密性の高いものとそうでないものが混在しています。たとえば、Userオブジェクトには、非機密の「username」プロパティと、機密情報である「password」プロパティが設定されていることがあります。開発者がこれらの機密プロパティをサーバー側で適切に保護せず、クライアント側にフィルタリングを任せていると、悪意のある第三者に情報を取得されるおそれがあります。このような脆弱性は「過剰なデータ露出（excessive data exposure）」と呼ばれます。

同様に、user.idのような内部プロパティや、user.is_adminのような権限に関わるプロパティは、ユーザーによって更新できるべきではありません。しかし、クライアントから受け取ったすべてのデータを一括で割り当てる「大量割り当て（mass assignment）」を実装してしまうと、これらのプロパティが不正に書き換えられるリスクが生じます。このリスクを避けるためには、各プロパティを検証し、ユーザーが更新できる項目にのみ値を代入するロジックを実装することが重要です。

クォータやスロットリングの未実装

クォータやスロットリングは、計算リソースの消費を抑え、高可用性を維持するために、サービスへのリクエスト数を制限するための仕組みです。こうした制限を実装していないAPIは、パスワードを総当たりで推測する「ブルートフォース攻撃」や、大量のトラフィックを送信してリソースを消耗させる「サービス拒否（DoS：Denial of Service）攻撃」に対して脆弱になります。これらの攻撃は、ダウンストリームのサービスを過負荷にし、最終的にサービス停止を引き起こす可能性があります。

HTTPヘッダーの設定ミスや欠落

WebクライアントがAPIに初回リクエストを送信する際、レスポンスには適切なHTTPヘッダー（特にセキュリティヘッダー）を含める必要があります。これらのヘッダーは、ブラウザに対して安全な方法でAPIと通信するための指示を提供します。たとえば、HTTP Strict Transport Security（HSTS）ヘッダーを使えば、有効な証明書とTLS通信の使用を強制できます。また、Access-ControlヘッダーやCross-Origin Resource Policy（CORP）ヘッダーは、正規のクライアントが悪意のある第三者のためにAPIリクエストを代理送信してしまうことを防ぎます。

さらに、Cache-ControlやVaryヘッダーが正しく設定されていない場合、プロキシやロードバランサーを経由して、プライベートデータが他のAPIクライアントに漏えいするリスクも生じます。

メソッドレベルでの入力検証、サニタイズ、エンコーディングの未実施

APIインジェクションは、攻撃者がリクエストのパラメータやボディに悪意のあるコードを含めて送信することで発生します。このようなコードは、たとえばSQLクエリやデータの逆シリアル化処理の中で、サーバー側で実行されることがあります。あるいは、適切なエスケープ処理が行われていない場合には、HTMLコンテンツに埋め込まれた形でクライアント側で実行されてしまう可能性もあります。これにより、本来保護されているはずの権限やデータベースのレコードが改変される、あるいは任意のリモートコード実行（RCE）が引き起こされるリスクがあります。こうした脅威を防ぐためには、Webアプリケーションファイアウォール（WAF）の活用に加えて、メソッドレベルでの入力検証・サニタイズ・エンコーディングを確実に実装することが重要です。これにより、不正な形式や危険なデータがワークフローに入り込むのを防げます。さらに、OWASPのESAPIライブラリなどのツールを活用することで、こうした脆弱性の発生リスクを効果的に低減できます。

API資産の管理不備とドキュメントの不整合

チームは、エンドポイント、バージョン、サードパーティ製サービスなど、さまざまなAPI成果物を管理する責任を担っています。しかし、こうした資産が増えていくと、正確なドキュメントを維持しながら、それらを安全に管理するのが次第に難しくなります。たとえば、古いAPIバージョンの廃止を忘れてしまうと、すでに修正されたはずの脆弱性を攻撃者に悪用されるリスクがあります。このような「不適切な資産管理（Improper Assets Management）」の問題は、ドキュメントが古かったり、各APIアセットの役割が正しく記載されていなかったりすると、さらに深刻化します。

ロギングと監視体制の不備

ログは、システム上のすべてのアクティビティを記録するため、APIを含むあらゆるサービスやインフラストラクチャコンポーネントでロギングを有効にしておくことが重要です。ただし、小規模なシステムであっても、1日に数百万件のログが生成されることがあり、異常な動作をリアルタイムで検出するのは容易ではありません。さらに、ログには機密データが含まれることもあるため、セキュリティとコンプライアンスの両面から適切に取り扱う必要があります。そのため、チームは堅牢な監視戦略をロギング体制と組み合わせることで、ログストリーム内に現れるセキュリティ侵害や機密情報の漏洩を、即座に検出できるよう備えておくことが求められます。

REST以外のAPIアーキテクチャに特有のセキュリティ脆弱性とは？

RESTは依然として最も広く使われているAPIアーキテクチャですが、ユースケースによっては、SOAP、GraphQL、WebSocket、gRPCなどを採用する開発者も増えています。これらのアーキテクチャにはそれぞれ特有のセキュリティリスクが存在しており、ここでは、それぞれの特徴と注意点について詳しく見ていきます。

• SOAP：SOAPは、XMLベースのメッセージングプロトコルです。しかし、XML処理モジュールは、悪意のある形式で構築されたデータに対して脆弱な可能性があるため、APIとそのダウンストリームサービスを安全に保つには、常に最新のライブラリを使用することが推奨されます。また、SOAP APIでは、リモートプロシージャコール（RPC）においてシリアル化が使われることがあり、それによって攻撃者がリクエスト内に悪意あるコードを潜ませる余地が生まれる可能性もあります。
• GraphQL：GraphQLは、複数のデータソースを1つのAPIエンドポイント経由で統合的に操作できるクエリ言語です。この特性により、一見単純なリクエストであっても、大規模なダウンストリーム処理が発生したり、読み書きの影響範囲が広がった結果、アクセス権限を逸脱するおそれがあります。そのため、GraphQLベースのアーキテクチャでは、クォータやスロットリングの導入に加え、アクセス権限の粒度設定も不可欠です。
• WebSocket：WebSocketは、クライアントとサーバー間で1つのTCP接続を介して継続的な双方向通信を実現するための技術です。ただし、WebSocket自体には認証や暗号化の仕組みが備わっていないため、開発者が明示的にTLSを導入し、認可のチェックを適切に実装する必要があります。さらに、WebSocketには同一オリジンポリシーが適用されないという特性があります。この制約により、かつてOWASPが2013年に追跡していた「クロスサイトリクエストフォージェリ（CSRF）」攻撃の変種が、「クロスサイトWebSocketハイジャック」として再び問題視されるようになりました。また、WebSocketベースのアプリケーションは、他のWebアプリケーションやAPIと同様に、一般的な脆弱性の影響を受けやすいという点にも注意が必要です。レート制限やCSRF対策に加え、入力および出力データの検証・サニタイズ処理を行い、Originヘッダーと許可リストを照合してアクセス制御を強化するなど、他の環境でも有効なセキュリティ対策を同様に適用することが求められます。
• gRPC：gRPCは、HTTP/2上で動作するリモートプロシージャコール（RPC）フレームワークであり、ポリグロットなサービスとクライアント間の低レイテンシ通信を、大規模な環境でも効率的に実現します。SOAPと同様に、gRPCもシリアル化によってデータを転送しますが、内部的にはProtocol Buffers（プロトコルバッファ）をシリアル化メカニズムとして採用しています。安全性を確保するには、Googleが提供する標準のProtocol Buffersライブラリを使用することが推奨されます。一方、非標準の実装には独自のセキュリティ上の懸念がある場合があり、使用には注意が必要です。

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

APIはそれぞれ異なり、個別のセキュリティ要件を持っています。とはいえ、APIの種類やユースケースにかかわらず、以下に示すベストプラクティスは、上記で紹介したようなセキュリティ脆弱性の回避に有効です。

• HTTPSを使用する：HTTPSは、SSL/TLSを用いてインターネット上で送受信されるデータを暗号化します。これは、ログイン認証情報や金融情報などの機密データを保護するうえで不可欠であり、多くの規制基準への準拠にも必要とされます。
• レート制限とスロットリングを実装する：レート制限は、一定期間内にクライアントがAPIに対して送信できるリクエスト数を制限する仕組みです。DoS（サービス拒否）攻撃からAPIを保護するための対策として用いられています。このレート制限は、スロットリングと組み合わせて使われることが多く、スロットリングはリクエスト処理の速度を制御することで、APIの計算リソース消費を抑える効果があります。
• すべての入力パラメータ、ヘッダー、ペイロードを検証し、サニタイズする：入力検証とは、APIに送信されるデータが、想定された形式や制約に従っているかを確認するプロセスです。サニタイズは、入力データに有害な文字や構文が含まれていないことを保証し、不正なデータの混入を防ぐために行います。これらの対策により、SQLインジェクション、クロスサイトスクリプティング（XSS）、コマンドインジェクションといった攻撃からAPIを効果的に保護できます。
• 不審なアクティビティを検知するためにAPIを監視する：セキュリティ監視とは、APIから取得されるテレメトリデータを継続的にモニタリングし、脅威や侵害が発生した際にすばやく検知するためのプロセスです。中でもログ監視は特に重要です。ログには、システム内で行われたすべての操作が記録されており、その中には悪意のある行為者による操作も含まれている可能性があります。
• ロールベースのアクセス制御を実装する：ロールベースのアクセス制御（RBAC）は、認証されたユーザーの役割に基づいて、APIのリソースへのアクセス権限を制御する仕組みです。たとえば、「admin」ロールのユーザーにはすべてのリソースへのアクセスを許可し、「guest」ロールのユーザーには読み取り専用リソースのみアクセスさせる、といった制御が可能です。このような方式を採用することで、APIのリソースやデータを不正アクセスから体系的に保護できます。

よくあるAPIセキュリティ侵害の例とは

APIセキュリティの侵害は、共通した攻撃パターンに基づいて発生することが多く、企業にとって深刻な被害をもたらす可能性があります。以下に、よく見られるセキュリティ侵害の具体例を紹介します。

• ブルートフォース攻撃：ブルートフォース攻撃では、攻撃者がパスワードや暗号鍵、その他の認証情報を自動化された処理で総当たり的に推測し、APIへの不正アクセスを試みます。このような攻撃を防ぐには、強固なパスワードポリシーの導入、多要素認証（MFA）の活用、そして失敗したログイン試行の継続的な監視が効果的です。
• サービス拒否攻撃：サービス拒否（DoS：Denial-of-Service）攻撃とは、攻撃者がAPIに対して大量のリクエストを短時間に集中して送信し、正規の利用者がサービスを利用できない状態を引き起こす攻撃手法です。こうした攻撃は、クォータやスロットリングといったリクエスト制御が適切に実装されていない環境で発生しやすく、被害を受けた組織には金銭的損失や評判の低下といった深刻な影響をもたらすおそれがあります。
• インジェクション攻撃：インジェクション攻撃は、APIが入力パラメーターやペイロードに対して適切なサニタイズ処理を行っていない場合に発生します。このような状況では、攻撃者が悪意のあるコードをシステム内に注入することができてしまいます。注入されたコードが実行されると、データベースのレコードが改ざんされたり、ユーザーのセッショントークンが盗まれたりするなど、深刻な被害につながるおそれがあります。
• 中間者攻撃：中間者攻撃では、攻撃者がAPIクライアントとサーバー間の通信に介入し、データを改ざんしたり、新たなデータを挿入したりすることが可能になります。こうした攻撃は、APIが機密データを暗号化せずに送受信・保存していたり、認証メカニズムが不十分だったりする場合に発生します。その結果として、ユーザーのIDが盗まれたり、金融詐欺に悪用されたりするなど、重大な被害につながるおそれがあります。

APIセキュリティにPostmanを選ぶ理由

Postmanは、API、データ、ワークフローを設計段階から提供・運用に至るまで一貫して保護できる、統合型のエンタープライズグレードプラットフォームです。

• API定義とリクエストにセキュリティルールを適用する：Postman APIセキュリティは、OWASPの「トップ10」に基づいた既定のセキュリティルールを提供しており、APIの定義やリクエストに潜む一般的な脆弱性やセキュリティ要件の逸脱を自動的に検出できます。
• セキュリティルールをニーズに合わせてカスタマイズする：セキュリティ要件は組織ごとに異なるため、Postman APIセキュリティでは、Spectralのガイドラインに従って独自のカスタムルールを定義・インポートすることができます。
• CI/CDパイプラインにAPIセキュリティチェックを統合する：セキュリティの問題は、できる限り早期に発見することが重要です。PostmanのAPIセキュリティルールは、CI/CDパイプラインのビルド段階において、API定義に対して自動的に実行できます。
• APIパフォーマンスとレスポンスタイムを監視する：APIセキュリティは、APIのパフォーマンスに直接的な影響を及ぼす可能性があります。Postman Monitorsを使えば、APIのパフォーマンスやレスポンスタイムを継続的に監視できるため、問題の兆候をいち早く発見し、迅速に対応することが可能になります。
• セキュリティテストを自動化して回帰を防ぐ：Postmanでは、セキュリティテストを自動化するためのテストスクリプトを作成できます。たとえば、認可に関するテストは、Postmanのスクリプト機能を使って簡単に自動化できます。また、モニターを設定してテスト結果を継続的に監視することで、回帰を未然に防ぐことができます。
• バージョン管理を実装する：Postmanのコラボレーション機能には、APIのバージョン履歴を管理できるバージョン管理機能が含まれています。これにより、チームは過去の変更を追跡しながら、現在のバージョンの安全性を常に確保することができます。
• ドキュメントを最新の状態に保つ：Postmanは、任意のコレクションやOpenAPI 3.0定義のドキュメントを自動で生成します。これらのドキュメントは、変更を加えるたびに自動的に更新されるため、チームは担当するAPIアセットの内容を常に正確に把握・共有することができます。