APIセキュリティチュートリアル

APIセキュリティとは？

APIの安全を守ることは、現代のデジタル環境を守るうえで非常に重要です。多くのシステム間の通信にアプリのAPIが利用されるため、円滑な連携を実現しますが、その反面、大きなセキュリティリスクも伴います。最近の調査では、2023年に91%の企業がAPIに関連したセキュリティインシデントに見舞われたことが示され、安全な運用が求められていることが分かっています。

‍

基本的に、APIセキュリティはAPIの完全性、機密性、利用可能性を守ることに注力します。認証、認可、暗号化、監視などさまざまな手法により、正当に許可されたユーザーやアプリだけがAPIにアクセスできる仕組みを作ります。

‍

2025年までには、企業のAPI管理率が50%を下回る。急増するAPIの数は、API管理ツールの能力を超えているためである。

- Gartner Insights

‍

APIセキュリティは複数の層からなる広範な分野です。各層はそれぞれのセキュリティ課題に対応し、固い守りを実現することを目的としています。

‍

APIセキュリティ vs アプリセキュリティ

セキュリティチームは、かつてないほどのリソースが必要とされるにもかかわらず、常に不足しています。企業は高価なAPIセキュリティソリューションに投資しながら、至らぬ部分には応急措置を施し、回避策を講じていますが、それでもAPI攻撃の頻度や被害は増大する一方です。そのため、アプリセキュリティとAPIセキュリティを統合する動きが強まっています。

一方、従来のWAFベンダーからは、この統合の動きが発せられています。有力な企業が近年、APIセキュリティベンダーを買収し、WAFとAPIを同じアプリセキュリティの側面として位置づけ始めました。しかし、APIセキュリティ分野のスタートアップは、製品にWAFを組み入れる動きはあまり見られず、別個の扱いを維持する利害関係が働いていると考えられます。

また、GartnerもWAFとAPIセキュリティの統合を支持しています。従来はWAFベンダー専用のマジッククアドラントが存在しましたが、数年前にWebアプリとAPIの保護（WAAP）を包括する形に更新されました。

Gartnerほど技術全体を把握している組織は少なく、ウェブアプリとAPIセキュリティの明確な連携は、これらのツールが協調して機能し、今後統合される方向へ進むことを示唆しています。

‍

‍

APIディスカバリー

APIディスカバリーは、組織内外のすべてのAPIを特定し、カタログ化し、文書化するプロセスです。安全で効率的なAPI環境を維持するために不可欠な作業であり、自動化されたAPI管理プラットフォームが、継続的なスキャンとマッピングによって、すべてのAPIを把握し適切に管理するのに役立ちます。

‍

"…デジタルトランスフォーメーションを進める上で、60%の企業がAPIディスカバリー機能の不足により遅れを取るだろう…"

- Gartner

‍

大規模な組織では、すべてのAPIとその提供するデータを常に把握するのは困難です。結果として、ITやDevSecOpsチームに管理されず、組織内に存在するシャドウAPIが問題となることも少なくありません。さらに、2025年までに管理されるAPIが半数以下になるとの予測を踏まえると、API一覧の維持管理は一層困難となります。

最後に、APIはライフサイクルを経ます。進化に伴い新バージョンが登場したり、非推奨となりつつも互換性維持のため一時的に稼働し、その後利用が極端に少なくなるケースもあります。

APIディスカバリーは、API提供者と攻撃者との競争でもあります。攻撃者はAPIを見つければ容易に悪用するため、攻撃者に先んじてAPIを特定するには、異なるソースからのトラフィック解析が必要です。APIゲートウェイ、ロードバランサ、Linuxカーネル（eBPF）、またはネットワークトラフィックからデータを収集し、専用エンジンで全APIのリストを作成します。

そのリストは、API管理レイヤーで提供されるカタログと照合できます。

‍

即時API防御

‍即時の防御対策が不十分なため、75%の企業がAPIに関連するセキュリティインシデントを経験している。

- Outshift by Cisco

‍

即時API防御は、急速に変化するサイバー脅威からAPIを守るために不可欠です。常時監視、脅威の特定、そして脆弱性への迅速な対応を通じて、機械学習や行動分析などの先端技術を活用し、異常や潜在的な脅威を即座に検出します。

APIのトラフィックとパターンを継続的に解析することで、不正アクセス、データ漏洩、DoS攻撃などの問題をすばやく把握・対策することが可能となります。

‍

AI対応API防御

ChatGPT、Gemini、Dall-EなどのジェネレーティブAIツールの登場により、グローバルなAPIエコシステムはAI時代に適応せざるを得なくなりました。AIシステムは、AIモデルと必要なデータストリーミングプラットフォームやサービスを連携させるため、幅広いプロセスでAPIを利用します。

効率の高いAI・機械学習・LLMモデルとデータストリーミングを統合したエコシステムの構築により、システムとサービスが拡大し、生活環境やビジネス成果の向上に貢献しています。

従来の手法（ユーザー認証の欠陥、フィッシング、DDoS、SQLインジェクションなど）が依然として主要な脅威である一方、企業はクロスサイトスクリプティング（XSS）やクレデンシャルスタッフィングなどのブルートフォース攻撃にも備える必要があります。さらに、近年ではAI、機械学習、LLMツールがサイバー攻撃に利用され、企業へのAPI攻撃の頻度は大幅に増加しています。

‍

“…2024年初頭に、4社に1社がサイバー攻撃に遭った…”

- Check Point Research

AIを活用したパターン認識システムは、API全体の異常を検知し、データ分析は長期的なパターンを解析して、後に悪用される可能性のある脆弱性（CVE）を特定する能力を有しています。

‍

脅威の検出

データ収集から異常検知まで、AIアルゴリズムはパターンやユーザーの行動を綿密に解析し、APIの標準的な基準を設定します。常時APIトラフィックを監視することで、情報セキュリティチームは基準からの逸脱を迅速に特定し、効果的な対策を講じることが可能です。

‍

予測分析

AIは、過去のデータとパターン認識を活用することで、潜在的な脆弱性を予測し、差し迫ったセキュリティ脅威に先手を打つ力を企業に与えます。これにより、サイバー攻撃が発生する前にリスクを軽減することが可能です。

‍

即時対応と修復

APIの脅威を検知した際、AIは疑わしいトラフィックの遮断、セキュリティチームへの通知、またはアクセスの一時制限などの措置を迅速に実行し、さらなる被害を防ぎます。この即時対応は、脅威の軽減と被害の抑止に極めて重要です。

行動バイオメトリクス

AIは、タイピング速度、マウスの動き、ナビゲーションの傾向など、ユーザー固有の行動特性を解析する行動バイオメトリクスを統合することで、APIセキュリティをさらに向上させます。これらのパターンを継続的に監視することで、アカウントの侵害や不正利用の兆候を迅速に検知できます。

APIセキュリティにおけるAIの競争優位性は比類なく、業界の最前線へとAPIセキュリティを押し上げています。

‍

‍

APIセキュリティのベストプラクティス－トップ15基準:

多くのプロダクトセキュリティ専門家に、APIセキュリティプログラムの開始点について意見を伺いました。以下はその内容です。

1. すべてのAPIを把握する

セキュリティおよびエンジニアリングのリーダーは、使用中のAPIの数や、どこで機微なデータがやり取りされているか、といった基本的な疑問に容易に答えられるべきですが、実際には99%が把握できていません。最新のAPI一覧と、PIIやPHIデータを扱うAPIを特定することが重要です。専門製品もありますが、APIClarityのようなオープンソースソリューションもディスカバリーに役立ちます。

2. 非推奨（ゾンビ）や未文書化（シャドウ）のAPIを検出する

ゾンビ、シャドウ、オーファンAPIは大きなリスクを孕んでいます（2023 State of the API Report参照）。適切なAPIガバナンスには、開発時の仕様作成・管理や、仕様に沿わない状態を特定するプロセスが含まれ、OSSツールのAPIClaryもここで役立ちます。

3. APIゲートウェイを導入する

APIゲートウェイを活用して、APIトラフィックの管理、監視、セキュリティ強化を図ります（実際、多くのAPIは未管理です）。これにより、レート制限、キャッシュ、認証、アクセス制御、CORSなどの重要なセキュリティ層を追加できます。Kong API GatewayやTykなど、強力なオープンソースゲートウェイも存在します。

4. APIセキュリティテストを自動化する

本番環境よりも、開発環境で重大なセキュリティ設定ミスなどを発見する方が望ましいです。ZAP、openapi-fuzzer、RESTlerといったオープンソースツールは十分な価値を提供します。最適な手法は一つではなく、多くの企業はDAST、SAST、IASTや開発ツール（例：IDE用プラグイン）を組み合わせて安全なコード開発を支援しています。

5. APIの情報漏洩を事前に検出する

APIのシークレット流出は深刻な事故を引き起こす可能性があります。GitHubリポジトリ、Postmanコレクションなどで、APIキーを含む露出した認証情報を定期的にスキャンし、不正アクセスを防止してください。コードリポジトリは、エンジニアが誤ってAPIキーを流出させる場面が多いです。TruffleHogなどのツールで流出情報を特定しましょう。

6. リスクスコアでAPIを評価し、対策の優先順位を決める

守るべきAPIの数に圧倒されないよう、APIを特定した後は、データの機微度（例：個人情報を扱うエンドポイント）、公開レベル（外部または内部API）、パラメータ数など、固有のリスク要因に基づきテストや監査の優先順位を決めます。

7. 既存ツールがAPIに対応しているか監査する

長年信頼してきたスキャナーやWAFなどのセキュリティツールは、新たなAPI脅威から貴社のアプリを十分に守れない場合があります。特に、GraphQLやgRPCなどのトラフィック解析が行われていないケースも見受けられます。GoTestWAF（ガイド参照）などのオープンソースプロジェクトでツールのプロトコル対応をテストするか、Wallarmが提供するオンラインのAPIセキュリティテストプラットフォームをご利用ください。

8. OWASP APIセキュリティトップ10の勧告に準拠する

APIの脅威を理解するには、OWASP API Security Top-10やWallarmが作成したまとめ（該当セクション参照）を読むのが最適です。このリストは、セキュリティやエンジニアリングチームにとって必読であり、主要なAPI脆弱性とその対策について詳しく解説しています。

9. OWASPの枠を超える

Wallarmは、既知のすべてのCVEと数十億の攻撃データを分析し、四半期・年間のAPI ThreatStatsレポートを発行しています。これは、最新の情報としてOWASP API Security Top-10を補完するものです。

10. 認証と認可は業界標準の方法のみを使用する

AuthN/AuthZの方式を独自に構築せず、OAuth 2.0、JWT、OpenID Connect、Bearerトークンなどの業界標準に依存し、各APIエンドポイントで厳格な認可チェックを実施してください。認可の些細なミスが、過去数年間で壊滅的なデータ漏洩を引き起こした例もあります。

11. 悪用されやすいAPIを特定し、対策を講じる

APIはソフトウェア用に設計されているため、悪用されるリスクが内在しています。どのAPIが悪用されやすいかを見極め、対応策の計画を立ててください。レート制限とスロットリングは有効ですが、高度な攻撃には不十分な場合があるため、アプリレベルの保護や専門製品の導入が必要です。

12. 外部・内部のマイクロサービス間は暗号化を利用する

ゼロトラスト環境では、マイクロサービス間でmTLSを利用することが最善策です。

13. トラフィックに対してAPIポリシーを積極的に適用する

SQLインジェクション、SSRF、その他の攻撃を防ぐため、すべてのユーザー入力を徹底的に検証・サニタイズしてください。全API呼び出しを仕様に基づいて検証し、有害なリクエストを排除する方法が実績としてあります。オープンソースのAPIファイアウォールは、リバースプロキシとしてOpenAPIやGraphQLスキーマに基づきリクエストおよびレスポンスを検証する効果的なツールです。

14. APIログを実装する

APIログを保持し、即時監視を実施してセッションレベルも含む異常な動作を検知・対応します。これにより、進行中のインシデントを迅速に隔離できるようになります。

15. LowCode・NoCodeツールにも注意を払う

特に直接データにアクセスするLowCode・NoCodeツールのセキュリティ面は見落とされがちです。これらの多くは連携にAPIを利用しているため、そのリスクに注意してください。

‍‍

APIセキュリティ漏洩

API漏洩とは、APIを通じて機微なデータが誤ってまたは意図的に公開されることを指します。十分なセキュリティ対策がなされていないと、個人情報、財務情報、その他の機密情報が意図しない相手に渡る可能性があります。設定ミス、コードの脆弱性、セキュリティ対策の不備などにより、深刻なデータ漏洩、本人確認の不正、経済的損失といった結果をもたらす恐れがあります。

いくつかのAPI漏洩には以下の種類があります:

1. データ漏洩: 個人情報、パスワード、財務データなどの機微な情報がAPI経由で公開される最も一般的な漏洩です。
2. アクセス漏洩: 許可されていないユーザーに限定APIへのアクセス権が与えられ、本来アクセスすべきでない機微なデータに触れさせてしまう漏洩です。
3. 統合漏洩: 適切なセキュリティ対策が施されないまま他のアプリとAPIが連携する際に発生する漏洩です。
4. サプライチェーン漏洩: 脆弱性を持つサードパーティAPIがサプライチェーンに組み込まれることで、攻撃者がその弱点を突く手段となる漏洩です。
5. 設定漏洩: APIの設定が十分なセキュリティ水準に達しておらず、データが攻撃に晒される漏洩です。

‍

APIセキュリティにおけるOWASP TOP 10脆弱性

• API1:2023 (オブジェクトレベル認可の欠陥): BOLA対策として、開発環境と本番環境の両方で脆弱性を検出し、即時のコード修正が難しい場合はインラインのAPIセキュリティツールを用いて攻撃を遮断することを検討する。リスク評価: 6.0

• API2:2023 (認証の欠陥): 攻撃を検知・遮断する対策を講じ、APIの脆弱性を評価し、高リスクのものを優先して修正に取り組む。アプリ管理外の場合は、ベンダーと協力して証拠と優先順位に基づいて対応する。リスク評価: 8.0

• API3:2023 (オブジェクトプロパティレベル認可の欠陥): 脆弱なAPIエンドポイントを特定し、開発者に修正を指示、またはサードパーティの脆弱性を報告する。迅速な修正が困難な場合はインラインのAPIセキュリティツールを活用する。リスク評価: 5.3

• API4:2023 (リソース消費の無制限): リソース消費に関する脅威モデルを構築し、外部の制限を設定、アプリのコードに直接手を加えられなくてもリスク軽減の判断を行う。リスク評価: 8.0

• API5:2023 (関数レベル認可の欠陥): コード内の機能アクセスを制限し、適切なAPI運用を維持するとともに、監視・遮断ツールの使用を検討する。リスク評価: 8.0

• API6:2023 (機微な業務フローへの無制限アクセス): 業務フローを把握し、自動ツールの使用は控え、強制的な対策を講じ、適切なAPIガバナンスを維持する。リスク評価: 5.3

• API7:2023 (サーバサイドリクエストフォージェリ): 可能であれば、リソース取得の段階で制限を設け、難しい場合はネットワークまたはアプリ層で制御、もしくは専用ツールでSSRF攻撃を遮断する。リスク評価: 5.3

• API8:2023 (セキュリティ設定ミス): 適切なセキュリティガバナンスを実施し、API仕様を策定、ミス設定解消のためのリソース配分を優先する。リスク評価: 9.0

• API9:2023 (在庫管理の不備): APIディスカバリーから始め、文書化を徹底するとともに、開発プロセスにAPI仕様の導入や、ベンダーへの要求を行い在庫管理を強化する。リスク評価: 5.3

• API10:2023 (APIの安全でない利用): 自社管理のAPIについては、ベストプラクティスを実施し、チェックリストで評価する。サードパーティのAPIは、チェックリストに基づく準拠を確認し、非準拠の場合の対策を整備する。リスク評価: 7.0

• インジェクション（旧API8:2019）: インジェクション攻撃はAPIにとって最も危険な脅威です。そのリスクを十分に認識し、予防策を講じることが重要です。リスク評価: 9.0

API認証方法

ユーザーの身元確認は、APIの不正利用を防ぎ、正当な利用者にのみ情報へのアクセスを許可するために不可欠です。アクセスを試みる者の身元を確認し、認証済みのユーザーのみがAPI資源に触れられるようにします。

1. ホストベース認証

ホストベース認証は、IoTデバイスやネットワーク認証で広く用いられています。ウェブ技術には、なりすましにより回避される恐れがあるため推奨されません。この方式は、ホストやサーバーを確認することで、認証済みのユーザーのみがサーバー上の資源にアクセスできるようにします。プロセス開始のために鍵などは不要ですが、DNSスプーフィング、ルーティングスプーフィング、IPスプーフィングを防ぐため、サーバーは事前にログインキーを検証できる必要があります。

この方式はRSAに非常に似ています。

判断は「はい」か「いいえ」で行われ、デフォルトは「いいえ」に設定されます。ホストベースのユーザー確認は、管理者がローカルホスト用の秘密鍵を作成するか、ローカルホストで使用する公開鍵を抽出することで実施されます。

2. ベーシック認証

最も簡単なAPIの本人確認方式のひとつで、HTTPプロトコルを利用し、クライアントがあらかじめ用意されたヘッダー付きのHTTPリクエストを送信し、ユーザー名やパスワードなどの認証情報を要求します。この基本的な確認は、ブラウザ上で行われます。

すべてのブラウザとサーバーでサポートされているため、最も一般的な方式ですが、認証情報は平文（またはbase64エンコードされた状態）で送信されるため、中間者攻撃のリスクがあります。認証情報はRSAやSHA-256など、より安全なアルゴリズムで暗号化するのが望ましいです。

プロキシサーバーでも動作し、IIS以外の資源へのアクセスも可能ですが、暗号化が行われないため安全性は低く、リプレイ攻撃にも弱いです。

3. OAuth

OAuthはオープンな本人確認方式です。ユーザー認証と認可基準の設定を包括し、例えばGoogleなどのOAuthサーバーから発行されるトークンを用いてユーザーを認証します。

システムにログインを試みる際、トークンを要求し、そのトークンで利用者の身元を確認・承認します。リクエスト作成者は、資源へのアクセス要求を認証サーバーに送信し、確認結果に基づいてリクエストが承認または拒否されます。

OAuthは他の方式に比べ安全性が高く、多くのケースで第一選択となっています。OAuthの三要素は、OAuthプロバイダー（GoogleやFacebookなど）、OAuthクライアント（情報を保持するサイトやページ）、およびアクセスリクエストを行うユーザーです。

4. OAuth 2.0

広く利用されるAPIアクセス管理プロトコルであるOAuth 2.0は、OAuthの改良版です。HTTPサービス（例：GitHubやFacebook）を用いてクライアントのアクセスを制限し、認証コードを利用して本人確認を行い、ユーザーの認証情報は要求しません。

OAuth 2.0における三要素は、データを保有するユーザー、アプリケーション、そしてAPIです。

この方式を利用することで、さまざまなリソースからユーザーデータを容易に扱うことができ、ウェブ、モバイル、デスクトップのアプリやデバイスの認証・承認に利用できます。 

5. SAML

SAMLはSecurity Assertion Markup Languageの略で、シングルサインオン技術を用いた標準的なAPI認証方式です。提供された情報に基づきユーザーを確認し、認証が完了すれば各種アプリや資源へのアクセスが許可されます。現在はSAML 2.0が主流で、IDシステムに類似しており、主にユーザーの身元確認に用いられます。

‍

APIセキュリティとは何か 

自社が管理するアプリに関連するAPIのみが制御可能です。そのため、APIセキュリティはユーザーに直接または間接に公開されるAPIを守ることに注力します。他社提供のAPIは、送信トラフィックの詳細な解析で有益な情報が得られるため、Web APIセキュリティの主要な対象ではありません。

また、APIセキュリティの実践には複数のチームやシステムが関与し、スロットリング、レート制限などのネットワークセキュリティや、アイデンティティベースのセキュリティ、分析といったデータ保護策が含まれます。

‍

‍

APIプロトコル

要求に応じて、APIはさまざまな形態・スタイルで利用されます。採用するAPIスタイル（REST, SOAP, GraphQL, gRPC, Websocket または Webhooks）により、APIセキュリティの適用方法が左右されます。gRPCやGraphQLなど、各プロトコルは固有のセキュリティ脅威や攻撃手法を持ち、例えばGraphQLは柔軟なクエリ機能の反面、適切な検証やレート制限がなければリソース枯渇攻撃に晒される恐れがあります。各プロトコルはその構造や運用上の違いから、専用のセキュリティ対策が必要です。

APIプロトコルの比較

APIとクラウドネイティブアプリの守り方

Wallarmを利用してください。Wallarmは、ウェブサイト、マイクロサービス、APIを、OWASP API Top 10、ボット、不正なアプリの利用などあらゆる脅威から守る信頼性の高い完全なAPIセキュリティツールです。

特筆すべきは、Wallarmが手動ルールの設定不要で、誤検知が極めて少ない点です。信頼性のある即時のAPIセキュリティ解析と実用的な解決策が提供され、無料体験やデモも利用可能です。REST、SOAPなど、あらゆる種類のAPIを守ることができます。

経験豊富なWallarmのAPIセキュリティチームは、あらゆる環境におけるAPIの守り方に精通しています。AWS、GCP、Azure、IBM Cloudの各エコシステムで、どの展開形態でもAPIセキュリティの技術と知見を習得しています。