APIキーは必ず狙われる　生成AI時代のAPIセキュリティの新常識をPreferred NetworksのCISOが解説：@IT NETWORK Live Week 2026 Winter（2/2 ページ）

» 2026年03月26日 05時00分公開

脆弱性を悪用されることによる影響

　開発の視点では、脆弱性の発生源を特定し、検知と緩和のサイクルを高速化することが求められる。開発者はこれらを公開前に修正するか、影響を受けないような緩和策を講じる必要がある。

　APIを提供する側が考慮すべき脆弱性は、大きく2つのカテゴリに分類できる。1つ目は、SQLインジェクションに代表される「インジェクション系」。これらは攻撃パターンが定型化されているため、コードの自動診断やWAF（Web Application Firewall）による攻撃の検知・防御が比較的容易だ。

　2つ目は「権限管理・アクセス制御系」。特にBOLA（Broken Object Level Authorization：認可の不備）が現代のAPIにおいて最も警戒すべき対象となる。BOLAは「プロフィールは見えてもよいが、個人の設定ページは見えてはいけない」といったシステムの文脈や常識に依存するため、従来の機械的な自動診断では発見が極めて難しい上に、通常のアクセスでも発生し得る通信であるため、攻撃の発生を検知しづらい。

　また、OSS（オープンソースソフトウェア）やライブラリの脆弱性リスクに対しては、SBOM（ソフトウェア部品表）を活用した依存ソフトウェアの可視化が不可欠だ。「React2Shell」と呼ばれる脆弱性や、Apache Struts2のような著名なライブラリの脆弱性は、攻撃者が特定の標的を定めず、インターネット全体に対して無差別に攻撃を仕掛ける爆撃の対象となる。

　これらの点については、「脆弱性診断をするのが一番根本的な対策だ」と汐田氏は述べる。PFNでは新規のプログラムや重要な新機能、大きな変更を施すときは、脆弱性診断を行うように促しているという。自動化に関しても生成AIの力が有効になりつつあるが、「基本的に手動でやる」とした。加えて依存ソフトウェアの可視化として、SBOMが取れるCSPM（Cloud Security Posture Management）、CNAPP（Cloud-native Application Protection Platform）を活用し、脆弱性のニュースに即時対応できるようにしている。WAFおよび自動診断は補助的な利用となっているという。

自動診断に向いているエリア、手動診断に向いているエリアの考え方

システム管理者の想定リスク　「許可」を出す側の論理

　「システム管理者」の視点では、ガバナンスと認可範囲の適切性が問われる。現場からのAPI連携需要に対し、管理者は単なる「連携先の信頼性」だけでなく、付与する権限の「強さ」と「範囲」を精査しなければならない。

　サードパーティー連携における最大のリスクは、自社のコントロールが及ばない領域でインシデントが発生することにある。2025年の大手ソフトウェア関連インシデントにおいても、連携先のサードパーティー製ボットサービスが踏み台となり、API経由で機密データが盗み出されるなど、連鎖的な攻撃が常態化している。

2025年に発生した大手CRMの事例では、連携したサードパーティーが不正アクセスを受け、APIが悪用された

　ここで汐田氏は「判断主体の適切性」を指摘する。「プロジェクト単位の認可」で済む範囲を超え、全社のデータにアクセス可能な「全社権限の認可」を求める連携であれば、現場のプロジェクトマネージャーではなく、経営層や全社管理部門がリスクを判断すべきだと述べる。

使いたい人がリスク判断できるのか、どうしても広く権限を与えざるを得ない時は会社としての判断を仰ぐ

開発者、利用者、システム管理者それぞれが取り組むべきこと

　汐田氏は「認可する範囲に対して、リスク判断する人が適切かどうか」を軸に、権限のスコープと判断主体の不一致を防ぐ重要性を強調する。また、技術的な理想形として、固定のAPIキーを排除し、「Workload Identity Federation」のような短命トークン交換方式をサポートすることを開発側に推奨する。これにより、クレデンシャル管理という属人的なリスクを排除し、システム的に安全な認可プロセスを確立できる。さらに、独自仕様の認証シーケンスを避け、OAuth 2.0やOIDC（OpenID Connect）といった標準規格を採用することで、第三者によるレビューや監査を容易にすることも、管理・ガバナンスの観点から極めて重要である。