API セキュリティとは

API は、アプリケーション・プログラミング・インターフェースの略語です。ソーシャルメディア上のユーザー ID に関連付けられたパスワードなどの基本情報を保護するのと同様に、API キーや API コールなどの識別子が悪用されないように、バックエンドで API アクセスを保護することも重要です。

API がセキュリティリスクを増大させていることは驚くべきことではありません。利用可能な Web アプリケーションや Web サービスは、ほぼ確実に API によってサポートされているからです。モバイルアプリケーションや IoT（モノのインターネット）デバイスから、内部アプリケーションやクラウドベースのカスタマーサービス、マイクロサービスアーキテクチャまで、ビジネスのコミュニケーションとトランザクションを可能にしているのが API です。

そのため、API のライフサイクル全体を通じて、Web API セキュリティと API 管理が IT チームにとって重要な優先事項である必要があります。しかし、クラウドへの移行、最新の DevOps プラクティス、着実に進化する API により、セキュリティ脅威から API を保護することは複雑な課題となります。

API セキュリティとは、ビジネスプロセスに使用する API を保護するための体系的なアプローチです。API には次のようなものがあります。

• 顧客やビジネスパートナーが機能やデータに簡単にアクセスするための API
• ビジネスパートナーが利用する API
• 標準化されたスケーラブルな方法でアプリケーションの機能やデータをさまざまなシステムやユーザーインターフェースを介して利用できるようにする、内部的に実装され使用される API

効果的な API セキュリティ戦略には、以下のための体系的な手法が不可欠です。

• リスクと潜在的な影響の評価
• 適切な緩和策の実施

リスク評価の第一歩は、まず組織が公開し使用している API のうち、許可しているものと許可していないものをすべて目録化することです。この目録に含めるべき属性は次のとおりです。

• 最低限、「機密性がない」、「機密性がある」、「機密性が高い」データを区別したデータ分類
• API の脆弱性や設定ミスなどのリスク指標

リスクの影響を測定し、緩和策の優先順位を決定するためには、これらの属性が不可欠です。

API の可視化とリスク緩和策は、以下に示すように、潜在的な脅威のさまざまな組み合わせを考慮したものでなければなりません。

• 許可されていない「シャドー API」の使用を検知し防止する
• 攻撃者が悪用する可能性がある API の脆弱性や設定ミスを特定し、修正する
• ビジネスロジックの悪用やデータスクレイピングのようなさまざまな API 悪用を防止する

これらやその他の API セキュリティリスクを特定して緩和するためには、この急変する複雑な脅威状況に対処できる高度なセキュリティ制御が必要です。さらに、API のセキュリティ体制に影響を及ぼすセキュリティ以外のワークフロー（ソフトウェア開発や文書化など）にも API セキュリティプラクティスを適用することが重要です。

API（アプリケーション・プログラミング・インターフェース）は現代の Web 開発に欠かせない要素です。その分、大きな責任も伴います。その責任とは、API のセキュリティです。API セキュリティとは、アプリケーション間のインターフェースを保護することです。適切な API セキュリティがなければ、機微な情報が漏えいし、システムが侵害され、サービスが中断する可能性があります。簡単に言えば、API セキュリティのおかげで、攻撃者の侵入を防止しながら、正規ユーザーは業務を遂行できるのです。

API セキュリティの基本は、認証と認可です。認証とは、ユーザー、デバイス、またはシステムのアイデンティティを検証するプロセスです。クラブの入口で身分証明書を確認するようなものです。クラブに入ろうとしている人が、間違いなく本人であることを確認しなければなりません。一方、認可とは、認証を受けたユーザーが何を実行できて、何を実行できないのかを判別することです。クラブに入ることを許されたからといって、カウンターの中に入って勝手に飲み物を作っていいわけではありません。API の場合、認証と認可に API キー、トークン、OAuth などの手法を使用する場合があります。

API セキュリティのもう 1 つの重要な側面は、入力の検証です。入力の検証とは、API に送信されたデータが有効であることを処理前に確認することです。映画館でチケットを確認するようなものです。映画館では、別の映画のチケットを持った客を通すことはありません。同様に、入力の検証では、悪性データが API に侵入して問題を引き起こすのを防止します。

API セキュリティは、セキュリティ関連の責任者にとって急激に優先度が増した事項の 1 つです。しかし同時に、理解度が非常に低い問題でもあります。API は、実装の細かい部分から、イノベーションの戦略的な実現手段へと進化のスピードを速めています。その結果、多くのセキュリティチームは、API セキュリティの戦略や実践をどう高度化すればよいのか混乱状態に陥っています。API は、商取引を可能にする一方、機微な情報も伝送します。

セキュリティ責任者や担当者が API セキュリティに関する基本知識を強化するためのトピックを以下にいくつか紹介します。

Web API とは、あらかじめ決まっている要求-応答型のメッセージシステムと接続する 1 つ以上のエンドポイントで構成されるプログラム上のインターフェースのことです。この接続先のシステムは、通常、JSON 形式または XML 形式であり、公開され、Web 経由でアクセスできます（たいていは HTTP ベースの Web サーバーという形で公開）。

「API」という言葉を聞いて、ほとんどの人が思い浮かべるのは Web API です。実際には API はエンドポイントの集まりです。エンドポイントを構成する要素は、リソースパス、そのリソースに対して実行できる処理、リソースデータの定義（JSON、XML、protobuf などの形式）です。

Web API という用語は、その他の API（同一マシン上で実行しているアプリケーションに、オペレーティングシステムやライブラリを経由してアクセスする API など）と区別できるため便利です。しかし、私たちは皆、エンタープライズ企業のデジタルトランスフォーメーションや API セキュリティについて語るとき、「API」が HTTP ベースの（Web）API を指すものだと考えています。

現在、HTTP ベースの Web API には主に次の 4 種類があります。

• RESTful API Representational State Transfer（RESTful）は、 Roy Fielding 氏が 2000 年の博士論文で発表した最も一般的なタイプの Web API です。通常、データには JSON（JavaScript Object Notation）を使用します。RESTful API は、最近のフロントエンドフレームワーク（React、React Native など）にとって利用しやすく、Web アプリケーション開発やモバイルアプリケーション開発を容易にします。企業間取引に使用されるものも含めて、あらゆる Web API の事実上の標準となっています。
• SOAP API — SOAPは、リモート・プロシジャー・コール（RPC）に冗長性のある eXtensible Markup Language（XML）を使用します。古いタイプの API でまだ使用されています。
• GraphQL API —Facebook が開発した新しい GraphQL 標準です。単一のエンドポイント（通常は /graphql）を通じてデータベースにアクセスできます。単体の UI ページのデータを埋めるために複数回の呼び出しを必要とするという一般的な RESTful API の問題を解決できますが、一方で別の問題も引き起こします。
• gRPC APIHTTP/2.0 を介してアクセスする、Google開発の高性能バイナリープロトコルで、East-West 通信で最もよく使用されています。

企業対消費者（B2C）API とは、Web アプリケーションやモバイルアプリケーションで活用される API です。この API は一般的に、先進的なフロントエンドのクライアントが使用します。その目的は、エンドユーザーが API を介して会社の業務機能にアクセスできるようにすることです。

企業間（B2B）API とは、企業のビジネスパートナー（他の企業）が使用する API です。ビジネスパートナー（エンドカスタマー）にサービスを提供するために使用したり、共通の顧客（B2B2C）に価値を提供するために使用したりします。

B2B API は、エンタープライズ企業のデジタルトランスフォーメーションの基盤となります。この API を使用して、サプライヤー、販売代理店などのパートナーとの連携方法を合理化できるだけでなく、顧客体験を向上させることもできます。

B2B API の応用例を以下に示します。

• オープンバンキング用の API
• サプライチェーン管理用の API
• 取引パートナーとの間の電子的な請求処理、支払い処理

API の利用者は大きく異なるため（B2C API はユーザー向けアプリケーションで利用され、B2B API はパートナーのビジネスアプリケーションで利用される）、これらの API のセキュリティを保護するためのセキュリティ制御も異なります。

業界はごく最近まで B2C のユースケースを重要視してきましたが、そのようなケースでも、B2C API のセキュリティ確保よりも、むしろ Web アプリケーションのセキュリティ確保に力を入れてきました。B2C の Web アプリケーションを保護するためのセキュリティ制御では、B2C API をほとんど保護できないか（WAF／WAAP など）、またはまったく保護できません（大半のボット防御ソリューション）。

B2B API をどう保護するかの問題が深刻化しています。B2B API について言えば、第 1 世代のベンダーが提供するソリューションの中に、（たとえばフィンテック企業と金融機関が合意の上で顧客データを共有するオープンバンキングのようなケースで）共有する顧客データへの大量データアクセスをカバーできる専用の可視化／セキュリティソリューションは存在しません。

「API」という言葉は、1 つの API エンドポイントを指して使われることがよくあります。本来、API（サービスまたは API 製品と呼ばれることもあります）とは、業務上の機能を担うエンドポイントの集まりです。一方、エンドポイントとは、リソース（またはリソースパス、あるいは URI つまり Uniform Resource Identifier と呼ばれることもあります）と、それに対して実行される処理（作成、読み込み、更新、削除、RESTful API の場合の処理は HTTP メソッドの POST、GET、PUT、DELETE に相当）を指します。

North-South API は、外部（主にビジネスパートナー）向けに公開する API のことです。たとえば、オープンバンキングを採用している銀行が API を介して他のフィンテック組織や金融サービス組織に口座情報へのアクセスを提供したり、ヘルスケア関連の組織が API を介して保険会社や医療機関に患者の記録へのアクセスを提供したり、ホスピタリティ組織が API を介して旅行代理店やアグリゲーターに予約システムへのアクセスを提供したりすることが考えられます。API は、組織間をつなぐ接続口なのです。North-South API は、アクセスが許可され認証されているため、ともすれば安全であるとみなされがちです。しかし、一般的に見て、この API は急激に成長し、量も非常に多くなっているため、ほとんどの組織にとって最大のアタックサーフェスになります。

East-West API は、組織内部で使用する API です。社内のアプリケーション間の連携や、事業部門や部署との連携に使用します。外部からアクセスできない API は、East-West API とみなされます。

プライベート API は、内部 API と呼ばれることもあり、企業の開発者や業務委託先が使用することを目的とした API です。サービス指向アーキテクチャ（SOA）の取り組みの一環として使用されることが多く、別々の部署や事業部門が相互にデータに効率的かつ効果的にアクセスできるようにして、内部的な開発を合理化することを目的としています。

一方、パブリック API は、外部 API とも呼ばれ、社外の顧客に公開する API です。これを極端に推し進めたものが、オープン API と呼ばれる、誰でも自由に利用できる API です。しかし、いずれのケースにせよ、社外のエンジニアが使用しても問題がないように、管理を厳重にし、文書化を徹底する必要があります。

注意すべき重要な点は、プライベート API がインターネット経由でアクセスできる以上、厳密な意味でプライベートではないということです。たとえば、ACME の B2C API を使用するアプリが ACME のモバイルアプリ（ACME の社内エンジニアが開発したアプリ）に限定されるとします。この API をプライベート API と呼んでもよいのではないかと思うかもしませんが、この API へのトラフィックは、インターネットを経由します。したがって、表現上はプライベートであっても、実際にはプライベートではありません。ハッカーは、トラフィックを傍受し、モバイルアプリをリバースエンジニアリングして、該当する API を探し出し、このような API を日常的に攻撃しているのです。

API のセキュリティリスクはすでに、エンタープライズ企業のセキュリティチームにとって切迫した最大のリスクの 1 つとなっています。顧客とのやり取りや社内のビジネスプロセスで API の利用が広まるにつれて、その問題は深刻化する一方です。

つまり、API の利用が爆発的に増えており、多くのセキュリティチームが API のセキュリティ戦略をどうにかしようと悪戦苦闘しているということです。

このような理由から、IT 部門やセキュリティ担当の責任者にとって API セキュリティが最優先事項、最大の懸念事項の 1 つとして急浮上しているのです。Gartner 社は「2022 年までに、API を悪用した攻撃は、頻度の低い攻撃ベクトルから最も頻度の高い攻撃ベクトルへと移行し、エンタープライズ Web アプリケーションのデータ漏えいに発展する」と予想しています。

API セキュリティと従来のアプリケーションセキュリティは関連性の高い分野ではありますが、問題の規模と複雑さという 2 つの大きな理由から、両者は明確に異なる問題となっています。

以下に示すように、API の利用が急増した要因は 3 つあります。

1. マイクロサービス（サービス間通信に API 使用を前提としたアーキテクチャ）の利用が拡大しています。
2. ダイレクト・ユーザー・チャネルでは、React、Angular、Vue などの最新のフロントエンド・アプリケーション・フレームワークが API を使用し、API を使用しない傾向がある従来型の Web アプリに取って代わろうとしています。
3. さらに、まったく新しいチャネル（パートナー、モノのインターネット、業務自動化など）の対応にも API が使用されるようになっています。

Web アプリケーションとは異なり、API はさまざまな方法でプログラマティックに使用するように設計されているため、正当な使用と攻撃や悪用を区別するのは極めて困難です。

顧客やパートナーとの間で、ビジネスプロセスやデータを双方向でやり取りするために API を使用する組織が増えています。Web サイトやモバイルアプリのデータでは、企業対消費者（B2C）API が活用されています。この背後では複数の API のネットワークがトリガーされているため、API 間のセキュリティが必要となります。たとえば、財務情報を調べるためにフィンテックアプリにアクセスするとします。その場合、フィンテックアプリが銀行に対して B2B API コールを実行して、ユーザー認証を行います。このように、B2C API コールと B2B API コールが複雑に絡み合っているため、あらゆる API トラフィックを保護するための包括的なアプローチが必要です。それが、API 間セキュリティなのです。

API セキュリティの強化に関心がある場合は、以下の 12 のベストプラクティスから始めることをお勧めします。

• API セキュリティの標準と実践を組織のソフトウェア開発ライフサイクルに組み込みます。
• 継続的インテグレーション／継続的デリバリー（CI／CD）パイプラインに API の文書化と自動化されたセキュリティテストを組み込みます。
• 適切で効果的な認証と認可の制御が API に確実に適用されるようにします。
• API の悪用や過負荷を避けるために、レート制限を導入します。
• 専用のゲートウェイやコンテンツ・デリバリー・ネットワーク（CDN）を導入して、レート制限やアプリケーションレベルの対策を強化することで、分散サービス妨害（DDoS）攻撃のリスクを緩和します。
• アプリケーションテストのプロセスの幅を広げ、API セキュリティテストをその一部として盛り込みます。
• API の探索を継続して行うようにします。
• 一般的な API の脆弱性を特定し、修正するための体系的なアプローチを採用します。例：OWASP API トップ 10
• 既知の API 攻撃に対する基本的なレベルの防御として、シグネチャーベースの脅威検知と防御を使用します。
• 新しい脅威に対する API の脅威検知のスケーラビリティ、正確さ、ビジネスとの関連性、耐障害性を高めるために、シグネチャーベースの検知を AI とふるまい分析で補強します。
• いくつもの API セッションに対して API セキュリティの監視や分析を何週間にもわたって実施できるようにします。
• 脅威ハンター、開発者、DevOps、サポート担当者が使用する API の目録とアクティビティデータにオンデマンドでアクセスできるようにして、API セキュリティの監視とアラートを補強します。

API セキュリティのベストプラクティスに対する最善のアプローチ方法は、以下のようなフレームワークを使用して、組織の成熟度という観点から考えるやり方です。

API の脆弱性は、ソフトウェアのバグやシステムの設定エラーです。攻撃者はこれを悪用して、機密性の高いアプリケーション機能や機微な情報にアクセスしたり、API を悪用したりします。

 OWASP API トップ 10 は、最も広く悪用され、組織が特定し修正する必要のある API 脆弱性の概要を示す有用なリストです。

 OWASP API トップ 10 は、API の安全性とセキュリティ対策の向上を図ろうとしている組織にとって、絶好のスタート地点となります。潜在的な API のリスクを幅広くカバーしています。しかし、OWASP API トップ 10 のカテゴリーは、かなり大まかな内容であるという点に注意する必要があります。つまり、そのカテゴリーを 1 つずつ掘り下げ、その下の領域に焦点を当てることが重要です。

また、API のセキュリティリスクには、ロジック上のバグの悪用など、OWASP API トップ 10 には含まれていないものもあります。API 攻撃者は、認可の問題（OWASP に含まれています）だけでなく、ロジック上のバグ（OWASP には含まれていません）も頻繁に悪用しようとします。

API の攻撃や悪用の方法は多岐にわたり、最も一般的な例としては次のようなものがあります。

• 脆弱性の悪用：基盤インフラに技術的な脆弱性が存在すると、サーバーの侵害につながります。この種の脆弱性の例は、Apache Struts の脆弱性（CVE-2017-9791、CVE-2018-11776 など）から Log4j の脆弱性（CVE-2021-44228 など）まで多岐にわたります。
• ビジネスロジックの悪用：この恐ろしいシナリオでは従来のセキュリティ制御が役に立たないため、CISO が夜通し働かなければなりません。ロジックの悪用とは、攻撃者がアプリケーションの設計上または実装上の欠陥を突いて、想定外のふるまいや許可されていない動きをさせることです。
• 不正なデータアクセス：よくある API 悪用の 1 つとして挙げられるのが、不備のある認可メカニズムを悪用して、アクセスが許されるべきではないデータにアクセスできるようにすることです。このような脆弱性には、オブジェクトレベルの認可の不備（BOLA）、安全でないオブジェクト直接参照（IDOR）、機能レベルの認可の不備（BFLA）といったさまざまな名称が付けられています。脆弱性の最新リストは、OWASP API Security Project の Web サイトで確認できます。
• アカウントの乗っ取り：認証情報の窃盗やクロスサイトスクリプティング（XSS）攻撃の後には、アカウントが乗っ取られる可能性があります。そのようなことが起こると、極めてよく記述され完全にセキュリティが確保された API でさえ悪用される可能性があります。結局のところ、ふるまい分析を実行していないと、認証されたアクティビティはすべて正しく使用されているものとみなされます。
• データスクレイピング：組織がパブリック API を介してデータセットを利用可能にすると、攻撃者はそのリソースを積極的にクエリーして大量の貴重なデータセットを大規模に取得することができます。
• ビジネスサービス妨害（DoS）：API 攻撃者は、バックエンドに重いタスクを実行するようにリクエストすることで、アプリケーションレイヤーで「サービスの崩壊」、つまり完全なサービス妨害を引き起こすことができます（これは GraphQL の非常に一般的な脆弱性ですが、あらゆるリソース集約型 API エンドポイント実装で発生する可能性があります）。

バックエンド API により、開発者はコア・アプリケーション・サービスに繰り返し迅速にアクセスできます。バックエンド API は、さまざまなユーザーインターフェースを通じてデータアクセスを提供している組織にとって特に重要です。バックエンド API のセキュリティを確保するための最重要手順の 1 つは、厳格な認証アクセスモデルを実装することです。ただし、適切に認証されたバックエンド API であっても、悪用の可能性がないとは限りません。

モバイルアプリや Web インタフェースの脆弱性を悪用して、想定外の方法や許可されていない方法を通じてユーザーインターフェースでバックエンド API とやり取りする攻撃事例は数多くあります。このような悪用からバックエンド API を保護する最善の方法は、ふるまい分析を継続的に実行することです。バックエンド API のベースラインとなる利用状況をモデル化することで異常を検知し、開発段階や実装段階では予期できなかった攻撃ベクトルからエンドポイント API を予防的に保護できます。

市場やビジネスのニーズの変化に伴い、API の状況も常に変化しています。新しいビジネスニーズへの対応、バグの修正、技術的な改善のために新しいエンドポイントが実装されると、古いバージョンのエンドポイントは使われなくなります。

しかし、古いエンドポイントの廃止プロセスを管理することは、それほど簡単な話ではありません。廃止されたはずのエンドポイントがいまだに利用可能で、アクセスできるというようなことはよくあります。このようなエンドポイントをゾンビ API と呼びます。

エンタープライズ規模でシャドー API を探索する際の最良の方法は、カバー範囲が最も広いソースから API アクティビティのログデータをインジェストし、分析する方法です。各 API の周囲にアプリ単位のセンサーを展開すれば、API アクティビティに関する詳しい情報を得ることができますが、当然のことながら、把握していない古い API はシャドーの状態のままになっているため、すべてを網羅していない可能性があります。

API アクティビティデータのログソースの例を以下に示します。

• コンテンツ・デリバリー・ネットワーク（CDN）
• API ゲートウェイ
• Web Application Firewall（WAF）
• Kubernetes コンテナオーケストレーション

利用可能なすべてのソースから生データを収集したら、AI 手法を使用して、すべての API、エンドポイント、パラメーターを、人が理解しやすい目録に変換することができます。そこから、さらに分析を行って、これらの要素を分類し、シャドー API のうち排除すべきもの、正式なガバナンスプロセスに組み込むべきものを振り分けることができます。

内部 API に関しては、「内部」の定義によって保護する方法は異なります。インターネット経由で組織の Web アプリケーションやモバイルアプリケーションにアクセスするための公開 API のことを「内部 API」と呼ぶ人も多くいます。会社の従業員や業務委託先しか、このような API のドキュメントを閲覧できませんが、ハッカーにとって、Burp Suite のようなアプリ逆アセンブリのツールキットやプロキシを使用して、アプリを分析し、そのアプリへの API をリバースエンジニアリングすることは、いともたやすいことなのです。

しかし、「内部 API」の定義が East-West API であり、組織外からアクセスできないものであれば、主な脅威はインサイダーの脅威に絞られます。

前者の意味合いの内部 API と企業間（B2B）API はほとんどの API と同様に次のように保護します。まず、セキュアなソフトウェア開発ライフサイクル（SSDLC）を保護することが重要となります。そして、アクセスが必ず認証、認可されたものであること、クォータ、レート制限、Spike Arrest を管理すること、既知のシグネチャーに対して WAF／WAAP で防御することを継続します。

B2B API のトランザクションは機密性が高く、大量に発生することが多いため、できる限り、mTLS のような厳格な認証メカニズムを追加することを検討します。

次に両方の API セキュリティを確保するために、ふるまい分析を採用することをお勧めします。特に、関係するエンティティが多く、正当なふるまいと不当なふるまいを区別しにくい場合にお勧めします。

以下に例を示します。

• 特定のユーザーの API 認証情報が漏えいしたかどうかを確認する場合
• パートナーが請求書 API を悪用し、請求書番号を通じてアカウントデータを盗んでいるかどうかを検知する場合

B2B API と内部 API の保護には、IP アドレスや API トークンなどの技術的要素だけを分析しても得られないビジネスコンテキストが必要です。AI やふるまい分析を使用してビジネス関連のエンティティを可視化する方法が、B2B API と内部 API のリスクを効果的に把握、管理する唯一の手段です。ユーザーやパートナーのような個別のエンティティごと、あるいは場合によってはビジネスプロセスのエンティティ（請求書、支払い書、注文書など）ごとに API が正常に使用されているかどうかをビジネスコンテキストや過去のベンチマークで調べれば、それ以外の方法では検知できないような異常も見つけることができます。

API に対して戦略的なアプローチを採っている組織の多くが、API ゲートウェイを使用しています。具体的には、Apigee、Kong、MuleSoft、Akamai、AWS API Gateway、Azure API Management などです。

ほとんどの API ゲートウェイは、組織が活用すべきセキュリティ機能を豊富に取り揃えています。その機能の中でも筆頭なのが、認証（OpenID Connect を活用できる場合は認可も）です。

しかし、API ゲートウェイで認証、認可、クォータの管理をするだけでは十分ではありません。その理由は次のとおりです。

• API ゲートウェイで探索できないもの：API ゲートウェイは、管理するように設定された API のみを可視化し、制御するため、シャドー API やエンドポイントを効果的に検知することができません。
• API ゲートウェイのセキュリティギャップ：API ゲートウェイは、認証スキームと、ある程度の認可スキームを強制することはできますが、（WAF や WAAP と同様に）ペイロードを検査することも、ふるまいを評価して悪用を検知することもできません。

API の用途は多岐にわたるため、API の設定ミスを挙げようとしたらきりがありませんが、一般的なテーマであれば、以下のようにある程度、絞り込むことができます。

API を介してアクセスできる機微な情報のセキュリティを確保するうえで、認証は不可欠です。最初の一歩は、機微な情報にアクセスする API がすべて、初めから認証されるようにすることです。しかし、総当たり攻撃、Credential Stuffing、レート制限を悪用した認証トークンの窃盗から認証メカニズムを保護することも重要です。

設定に誤りがあると、API 利用者が認証メカニズムを迂回できることもありますが、それは得てしてトークン管理（たとえば、悪名高い JWT の検証の問題、トークンのスコープをチェックしないという問題）上の問題になりがちです。

API の最も一般的な用途の 1 つは、機微な情報を含むデータやコンテンツにアクセスできるようにすることです。認可とは、API 利用者がアクセスしようとしているデータにアクセスする資格があることを、実際に利用する前に検証するプロセスです。このプロセスは、オブジェクトやリソースのレベル（自分の注文書にはアクセスできるが他人の注文書にはアクセスできないなど）で行われることもあれば、職務レベル（管理権限の場合など）で行われることもあります。

エッジのケースと条件は数が非常に多く、また、マイクロサービス間で API コールが取り得るフローは多岐にわたるため、認可を正しく行うことは至難の技です。認可エンジンが一元化されていない場合は、API の実装に、Broken Object-Level Authorization（オブジェクトレベルの認可の不備、BOLA）や Broken Function-Level Authorization（機能レベルの認可の不備、BFLA）のような脆弱性が存在する可能性が高くなります。

前述した認証と認可の問題以外にも、さまざまなタイプのセキュリティ上の設定ミスがあり得ます。たとえば、安全でない通信（脆弱な暗号スイートを使用している場合や、TLS［旧 SSL］を使用していない場合など）、保護されていないクラウドストレージ、過度に制限の緩いオリジン間リソース共有ポリシーなどです。

API を実装するにあたって、API 利用者の呼び出しの回数に制限がない場合、攻撃者は、システムリソースをいくらでも消費できるため、サービスの低下や大規模なサービス妨害（DoS）攻撃が発生する可能性があります。エンドポイントの認証は極めて重要であるため、最低限でも、認証されていないエンドポイントに対するアクセスにはレート制限を適用する必要があります。そうしないと必然的に、総当たり攻撃、 Credential Stuffing、認証情報検証攻撃を受けることになります。

API 攻撃とは、API を悪意のある目的、あるいは許可されていない目的で使用する試みのことです。API 攻撃には、次のようなさまざまな形態があります。

• API 実装における技術的な脆弱性の悪用
• 正当なユーザーになりすますために、盗んだ認証情報やその他のアカウント乗っ取り技術を使用
• 想定外の方法で API を使用することを可能にするビジネスロジックの乱用

Web サイトや SaaS プラットフォームからのユーザー ID とパスワードの流出は、日常茶飯事となっています。たいていの場合、このように流出した大量の認証情報は、オンラインで広く共有されてしまいます。

Credential Stuffing とは、過去に攻撃を受けた Web サイトから流出した認証情報を使用して、自動的に他の Web サイトにログインしようとする攻撃のことです。この手法は、一定の割合のユーザーが複数のサイトで同じ認証情報を使用しているという前提に基づいています。

その標的は、Web アプリケーションやモバイルアプリケーションのようなフロントエンドよりも、むしろ直接的に API に向いているものが徐々に増えています。いずれにしても API は簡単に利用できるようになっているため、攻撃者にとって自動的な攻撃の対象にしやすいのです。

データ窃取は、API 攻撃と悪用が成功した場合に頻繁に発生します。API 攻撃や悪用を通して攻撃者に盗まれた機密性の高い非公開情報を指す場合もあります。しかし、API の悪用は、一般に公開されているデータを積極的にデータスクレイピングして、集合体として価値のある大規模なデータセットを作成するような、それほど深刻ではない場合にも使用されます。

開発プラクティス。セキュリティ関連の責任者が API セキュリティの戦略を立てるうえで考慮すべき主な傾向を以下に示します。

ふるまい分析と異常検知：リスクを緩和するために、発生し得る攻撃を予測しようとしたり、シグネチャーベースの検知やあらかじめ定義されたポリシー（WAF など）だけに頼ったりするのではなく、AI やふるまい分析に徐々に変わっていき、ビジネスコンテキストに従ってさまざまな API の活動を視覚化し、異常を検知できるようにする組織が増えています。

オンプレミスから SaaS への移行：第 1 世代の API セキュリティ製品の多くはオンプレミス環境に展開されてきましたが、SaaS ベースのアプローチは、展開の速さと容易さに加えて、規模に応じて AI や機械学習の能力を利用できるため、徐々に普及しています。

時間枠を広くとった分析：個々の API コールや短期的なセッション活動のみを分析する API セキュリティのアプローチは廃れつつあり、その代わりに、基本的な WAF ポリシー最適化の自動化から、ふるまい分析や異常検知に至るまで、数日、場合によっては数週間にわたって API の動きを分析するプラットフォームが台頭してきています。

DevSecOps — セキュリティ以外のステークホルダーの関与：API のリスクを軽減する最善の方法の 1 つは、API セキュリティの戦略やツールと、API の作成、実装、設定に関与している開発者やシステムとのつながりを強めることです。

API の情報に基づく API セキュリティ：活発な API 攻撃や悪用の事例を検知し緩和することが重要である一方、先進的な組織は、脅威ハンティング、インシデント対応、API を改善するために、API セキュリティに関するデータや知見にオンデマンドでアクセスできるようにしています。

シグネチャーベースの API セキュリティ手法とは、既知の攻撃の特徴やパターンが発生していないかどうかを監視し、それに合致するものがあれば、セキュリティのアラートを発したり、自動的に対応したりする手法です。API 攻撃や悪用手法の多くにはそもそもシグネチャーがないため、（API セキュリティにおいても、一般的な用途においても）シグネチャーベースの検知には限界があります。

シグニチャーベースの検知は、単一のパケットまたはリクエストに攻撃や悪用の兆候が含まれていることを前提としています。シグネチャー一致エンジンが高速で動作できるのは、コンテキスト（ユーザーは誰か？そのユーザーが先月アクセスしたエンドポイントの数は？など）を考慮に入れないためです。そのため、ほとんどの API 攻撃を完全に見逃してしまうことになります。

API セキュリティにはコンテキストが必要です。リクエストを行ったユーザー、そのユーザーが過去に行ったリクエストの内容、および全ユーザーの全体的なリクエストパターンなど、各 API リクエストのコンテキストを把握しなければなりません。そのため、異常な利用を検知するためには、ふるまい分析と機械学習に基づく API セキュリティ手法を使用する必要があります。

API の検知と対応は、過去のデータを深く分析することに焦点を当てた、新しいカテゴリーの API セキュリティです。その目的は以下のとおりです。

• すべての API 利用者のふるまいのベースラインを確立する
• API の悪用や誤用の可能性を示す攻撃や異常を検知する

AI 手法や機械学習手法に使用されるデータセットは巨大であり、リソースを大量に消費するため、規模に応じて効果的に API の検知と対応を行うためには、SaaS モデルを使用する以外に方法がありません。

高度な API 脅威防御とは、ふるまい分析と脅威ハンティングを組み合わせた API セキュリティを SaaS ベースで実装するアプローチのことです。その目的は以下のとおりです。

• 組織で使用されている API（シャドー API やゾンビ API を含む）をすべて探索する
• API がどのように使用されているか、悪用されているかというビジネスコンテキストを加味するために機械学習を応用する
• API と、長い時間をかけて蓄積されてきた API アクティビティデータに対してふるまい分析と脅威ハンティングを実施する

API セキュリティプラットフォームとは、次の目的に特化した SaaS ベースのサービスのことです。

• エンタープライズ規模で使用されているすべての API（認可されているかどうかにかかわらず）を目録化し、継続的に更新する
• AI 手法や機械学習手法を使用して API とその使用状況を分析して、ビジネスコンテキストを探索し、想定されるふるまいのベースラインを確立する
• API の使用状況の中から異常を検知し、必要に応じて、セキュリティ情報およびイベント管理（SIEM）、セキュリティのオーケストレーション、自動化および応答（SOAR）ワークフローにアラートとその裏付けとなるデータを送る
• セキュリティのステークホルダーと、セキュリティ以外のステークホルダーの両方が、API の目録やアクティビティ、脅威に関する情報にオンデマンドでアクセスできるようにする

アプリケーションや機微な情報を悪用などの攻撃から保護するための API セキュリティ手法には、さまざまな種類のものがあります。一般的な API セキュリティを以下に示します。

• 開発中およびテスト中に API コードをスキャンして欠陥や脆弱性を見つける
• API 脅威モデルを開発し、入力の検証などの対策を実装する
• TLS 暗号化や厳格かつスケーラブルな認証／認可モデルなどのベストプラクティスを通じて API を実装する
• Web アプリケーションファイアウォール、ボット緩和プラットフォーム、API ゲートウェイなどの専用ツールを導入して API を保護する
• 脆弱性評価を定期的に実施して、設定ミスやその他の実装上の欠陥を特定する
• API 探索を継続的に実行して、使用中のすべての API が保護されていること、または必要に応じて廃止されていることを確認する
• シグニチャーを用いて、既知の API 攻撃手法を監視する
• ふるまい分析と異常検知を用いて、より巧妙な API 悪用を監視する
• 脅威ハンティングを継続的に実行して、早期にリスクを特定および緩和し、開発チームと運用チームに事前対応型のセキュリティガイダンスを提供する

上記の API セキュリティはいずれも、セキュリティ戦略全体において重要な役割を果たす可能性があります。ただし、組織固有のリスクプロファイルに目を向けながら、一体的に実装することが重要です。

今では IT 担当やセキュリティ担当の責任者が API をより戦略的に使用できるようになり、API 専用のパートナーとの連携が必要になったと言えるでしょう。API 企業のタイプを大別すると以下の 2 つになります。

• API コールを一元的に受け付け、適切なバックエンドリソースやマイクロサービスに振り分けるテクノロジーを保有する API ゲートウェイ企業
• 活発な API に対する認識を企業に与え、攻撃や悪用の事例を検知し、API の使用状況に関する多様なデータを保有している API セキュリティプラットフォーム企業

多くのセキュリティチームは、潜在的な脅威を早期に特定し、しかるべき対策で対応できるようにするために事前対応型の脅威ハンティング活動を行っています。第 1 世代の API セキュリティ製品の多くは、脅威ハンティングチーム以外には価値がありません。その理由は、アラートに重点を置いており、API アクティビティをまったく蓄積しないため、クエリーやハンティングに必要なデータが存在しないからです。より先進性の高い API セキュリティ企業は、状況に関する情報が豊富に揃った大規模な API アクティビティデータセットを蓄積し、そのデータを GUI でも API でも利用できるようにしているため、脅威ハンターもそのデータを活用することができます。

Web アプリケーションと API の保護（WAAP）は、調査会社 Gartner が、新たに出現する Web および API の脅威に関する業界カバレッジに使用している分類です。これは、Web アプリケーションファイアウォール（WAF）市場の以前の業界カバレッジが進化したもので、API セキュリティの戦略的重要性の高まりと、WAF プラットフォームがマネージド型 SaaS としてクラウドに移行していることに対応しています。

RESTful API（最も一般的な Web API）に関する API ドキュメンテーションでよく使われる形式は、OpenAPI 仕様に準拠した Swagger ファイルの集まりです。API の設計時または実装時に開発者が API ドキュメンテーションを作成することが理想です。しかし実際には、API ドキュメンテーションは古くなることが非常に多く、その結果、API の実際の使い方とドキュメンテーションの記載内容が一致しなくなります。この問題に対処するために、一部の API セキュリティプラットフォームは、実際の API アクティビティをもとに Swagger ファイルを生成することができるため、ドキュメンテーションの記載内容と、実際に展開されている API との間の不一致を明確にできます。まさに、あらゆる API リスク評価に不可欠なコンポーネントです。

効果的な API セキュリティには、いくつもの細かいステップと継続的な実践が必要になりますが、以下に示す API チェックリストを使用すれば、セキュリティチームが API セキュリティに対するアプローチの洗練度を向上させようとするうえで良いスタートを切れるでしょう。

• API セキュリティのアプローチに、エンタープライズ規模の API 探索を継続させるための仕組みが盛り込まれているか
• クラウド／SaaS を活用して、AI 手法や機械学習手法を利用し、展開が不必要に複雑にならないようにしているか
• 十分な期間（30 日以上が理想）を取ってデータ分析する API セキュリティアプローチを採用しているか
• 観測している API アクティビティと潜在的なリスクを正しく理解するうえで必要なビジネスコンテキストがチームに伝達されるアプローチになっているか
• API セキュリティプラットフォームとその他の関連ビジネスプロセス（SIEM／SOAR、脅威ハンティング、ドキュメンテーション、DevOps ツールなど）との間で、自動的に双方向でやり取りできる仕組みを導入しているか
• 開発者のようなセキュリティ以外のステークホルダーが API セキュリティのツールやプロセスにスムーズに馴染めるような段取りを組んでいるか

セキュリティの立場から見たときの API の一般的な分類とその説明を以下に示します。

セキュリティチームは、API 実装のさまざまな使用モデルや技術的なアプローチを指す以下の用語に慣れておくとよいでしょう。

API セキュリティソリューションとは、アプリケーション・プログラミング・インターフェース（API）を攻撃やデータ漏えいから保護するための一連のツールと手法です。API は、アプリケーション間の通信、データの共有、その他の機能の実行などを目的として、企業や組織によって広く使用されています。

しかし、API の普及に伴い、API 関連のセキュリティリスクも増大しています。API は、不正アクセス、サービス妨害攻撃、インジェクション攻撃など、さまざまなセキュリティ脅威に対して脆弱となる場合があります。これらのリスクを緩和するためには、堅牢な API セキュリティソリューションを実装する必要があります。

API セキュリティソリューションには次のような機能が含まれています。

• 認証と認可： API セキュリティソリューションでは、許可されたユーザーだけがデータにアクセスして操作できるよう、API にアクセスするユーザーの認証と認可を行います。認証方式には、多要素認証、OAuth、OpenID Connect、API キーなどがあり、認可方式には、ロールベースのアクセス制御と属性ベースのアクセス制御があります。
• API ゲートウェイ： API ゲートウェイは、すべての API リクエストのエントリポイントとして機能する、包括的な API セキュリティソリューションのコンポーネントです。API ゲートウェイは、認証、レート制限、トラフィック管理、キャッシングなど、複数の機能を実行し、分散型サービス妨害（DDoS）などの攻撃を防ぐのに役立ちます。
• 暗号化： API セキュリティソリューションには暗号化機能も含まれているため、API 経由で送信するデータのセキュリティを確保し、攻撃者による傍受を防止できます。SSL、TLS、AES などを使用して、API リクエスト、API 応答、および保存データを暗号化できます。
• レート制限： レート制限は、ユーザーが指定期間内に実行できるリクエストの数を制限することで、サービス妨害攻撃を防止するための API セキュリティソリューション機能です。IP アドレス、ユーザーアカウント、またはその他のパラメーターに基づいてレートを制限することで、大量の API リクエストを送信して過負荷をかける攻撃を防止できます。
• 監査とロギング： API セキュリティソリューションには、監査とロギングのための機能も必要です。この機能により、API アクティビティを可視化して、セキュリティ脅威を検知および緩和できます。監査機能により、API のリクエストと応答を追跡し、ロギング機能により、API のイベントとアクティビティを安全かつ改ざん不能な方法で記録します。
• API テスト： API セキュリティソリューションには、脆弱性と潜在的なセキュリティリスクを特定するための API テスト機能も含まれています。API テストを手動または自動ツールを使用して実行することで、API のセキュリティが確保されていること、そして意図したとおりに機能することを確認できます。
• API の監視とランタイム保護： API セキュリティソリューションを使用して、API のふるまいを監視する必要があります。API を悪性ユーザーから防御するためには、正常なふるまいと異常な悪用の違いを把握することが不可欠です。
• 脆弱性管理： API セキュリティソリューションには、脆弱性管理機能も含まれています。この機能により、API のセキュリティ脆弱性を特定して対処できます。脆弱性管理により、脆弱性のスキャン、パッチ適用、修正などを行い、攻撃者が API の既知の脆弱性を悪用するのを防止できます。

API のセキュリティと整合性を確保するためには、API セキュリティソリューションが不可欠です。認証と認可、API ゲートウェイ、暗号化、レート制限、監査とロギング、API のテスト、監視、ランタイム保護、脆弱性管理などの機能を実装することで、API のセキュリティを確保し、幅広いセキュリティ脅威から防御できます。

API は業務運営に不可欠な存在となっているため、堅牢な API セキュリティソリューションに投資して、機微な情報や知的財産を保護することが重要です。

ふるまい分析とは、機械学習やデータ分析を用いて、ユーザーのふるまいにおける異常やパターンを特定するセキュリティアプローチです。このアプローチにより、インサイダーの脅威、アカウントの乗っ取り、不正行為などのセキュリティ脅威を検知して防止できます。

API の普及に伴い、API がサイバー犯罪の標的になることが増えています。そのため、API セキュリティの分野ではふるまい分析の重要性がますます高まっています。

API は、アプリケーション間の通信、データの共有、その他の機能の実行などを目的として使用されています。しかし、API の普及に伴い、API 関連のセキュリティリスクも増大しています。

API は、不正アクセス、サービス妨害攻撃、インジェクション攻撃など、さまざまなセキュリティ脅威に対して脆弱となる場合があります。ふるまい分析により、ユーザーのふるまいを分析し、攻撃を示唆する可能性のある異常なパターンを特定することで、これらの脅威を検知できます。

ふるまい分析 は、API セキュリティの重要な要素です。API は、機微な情報への不正アクセスや業務の中断を狙うサイバー犯罪者の標的となる可能性があるためです。ふるまい分析により、ユーザーのふるまいを分析し、攻撃を示唆する可能性のある異常なパターンを特定することで、これらの脅威を検知できます。

ふるまい分析機能を備えた API セキュリティソリューションにより、次のような攻撃を特定して防止できます。

アカウントの乗っ取り： アカウントの乗っ取りとは、攻撃者が正規のユーザーアカウントにアクセスし、そのアカウントを使用して機微な情報にアクセスしたり、悪性のアクションを実行したりすることです。ふるまい分析により、ユーザーのふるまいを分析し、攻撃者がユーザーのアカウントにアクセスしたことを示す異常なパターンを特定することで、アカウントが侵害されたかどうかを検知できます。

インサイダーの脅威： インサイダーの脅威とは、API へのアクセス権を持つ正規ユーザーがそのアクセス権を悪用することです。ふるまい分析により、ユーザーのふるまいを分析し、疑わしいふるまいや悪用を示唆する可能性のある異常なパターンを特定することで、インサイダーの脅威を検知できます。

インジェクション攻撃： インジェクション攻撃とは、攻撃者が悪性コードや悪性コマンドを API リクエストに挿入して、脆弱性を悪用し、機微な情報に不正にアクセスすることです。ふるまい分析により、ユーザーのふるまいを分析し、API の脆弱性の悪用を示唆する可能性のある異常なパターンを特定することで、インジェクション攻撃を検知できます。

サービス妨害攻撃： サービス妨害（DoS）攻撃とは、攻撃者が API を過負荷状態にして、業務を中断させることです。ふるまい分析により、ユーザーのふるまいを分析し、API リクエストの大量送信を示唆する可能性のある異常なパターンを特定することで、DoS 攻撃を検知できます。

API の普及に伴い、API を標的とするサイバー犯罪が増えています。そのため、ふるまい分析機能を備えた堅牢な API セキュリティソリューションに投資して、機微な情報や知的財産を保護することが重要です。

マネージド型脅威ハンティングとは、高度なツールと手法を用いて、被害を引き起こす前に潜在的なセキュリティ脅威を特定して緩和するための事前対応型のセキュリティアプローチです。

API セキュリティ企業が提供するサービスの一種であり、このサービスを利用する企業は、サードパーティのプロバイダーに料金を支払うことで、マネージド型脅威ハンティングの管理と実行を代行してもらいます。このサービスにより、社内に脅威ハンティング機能を導入することなく、専門のセキュリティチームの専門知識とリソースを活用できます。

マネージド型脅威ハンティングの「マネージド型」とは、API セキュリティ企業に料金を支払うことで、脅威ハンティングを代わりに実行してもらうことです。API セキュリティ企業は、顧客企業の API インフラの予防的監視、ログやその他のデータソースの分析、機械学習やふるまい分析などの高度な技術の活用などを通じて、潜在的なセキュリティ脅威を特定します。

その後、API セキュリティ企業は顧客企業と協力しながら、特定した脅威を修正し、セキュリティ体制を改善するための提案を行います。

API は、インジェクション攻撃、アカウントの乗っ取り、サービス妨害攻撃など、さまざまなセキュリティ脅威に対して脆弱となる可能性があるため、マネージド型脅威ハンティングは API セキュリティにとって非常に重要です。

マネージド型脅威ハンティングにより、これらの脅威が損害をもたらす前に特定および緩和し、機微な情報や知的財産を保護できます。

マネージド型脅威ハンティングには、次のような主要コンポーネントがあります。

• 予防的な監視と調査： マネージド型脅威ハンティングでは、企業の API を予防的に監視して、潜在的なセキュリティ脅威を特定します。具体的には、すべての API アクティビティデータ（システムログやその他のデータソース）を監視したり、検知したアラートを調査したりします。
• API 履歴データの保存： 調査と脅威ハンティングを実行するためには、すべての API データを保存する必要があります。マネージド型脅威ハンティングでは、データへのアクセスが不可欠です。
• 高度な検知手法： マネージド型脅威ハンティングでは、機械学習やふるまい分析などの高度な手法を用いて、潜在的なセキュリティ脅威を特定します。これらの手法により、従来のシグネチャーベースのアプローチでは検知が困難な脅威を特定できます。
• 脅威ハンティングチーム： マネージド型脅威ハンティングを提供する API セキュリティ企業には通常、API セキュリティ脅威の特定と緩和に関する訓練を受け、経験を積んだ専門家チームが存在します。このセキュリティ専門家チームが潜在的なセキュリティ脅威を特定して緩和します。
• 修正と提案： マネージド型脅威ハンティングでは、API セキュリティ企業が顧客企業と協力しながら、特定した脅威を修正し、セキュリティ体制を改善するための提案を行います。具体的には、脆弱性へのパッチ適用、アクセス制御の改善、他のツール（WAF、CDN など）やプロキシへのセキュリティ制御の実装などです。

マネージド型脅威ハンティングにより、インジェクション攻撃、アカウントの乗っ取り、サービス妨害攻撃など、さまざまな脅威を特定して緩和できます。

マネージド型脅威ハンティングに投資することで、API のセキュリティを確保し、さまざまなセキュリティ脅威から保護できます。