不正アクセスに関する注意喚起を受け、自社で利用している製品を確認するだけでは、点検すべき範囲を見落とす可能性があります。Webサービスの裏側で動くAPIや、限られた従業員だけが使う業務システムまで含め、公開範囲と操作権限を確認することが重要です。
JPCERT/CCは2026年10月8日、国内組織で相次ぐ不正アクセスについて注意喚起を公表し、翌9日に情報を追加しました*1。本記事では、注意喚起のうちAPIや業務システムに関する内容を中心に、OWASPの技術資料も踏まえながら、企業が実施すべき点検方法を解説します。
今回の注意喚起で確認されていること
JPCERT/CCが取り上げているのは、2026年9月前後に国内組織で相次いだ、個人情報等の漏えいにつながる不正アクセスです。既知の脆弱性の探索・悪用やAPI経由の不正操作、BIツール「Metabase」の脆弱性を悪用した攻撃などが報告されています。また、一般利用者向けのサービスだけでなく、BIツールや従業員向け管理システムも被害対象となっています。10月9日の更新では、公開Webサーバーからアクセス可能なアプリケーションサーバーにWebシェルが設置された事案が追加されました。
ただし、公表された事案を一つの原因で説明することはできませんJPCERT/CCは、攻撃に関する技術的な情報の共有が十分でない状況を説明し、把握している情報について「限定的かつ断片的」としています。*2
こうした状況を踏まえ、以降はAPIや業務システムのセキュリティ対策について、企業が確認すべきポイントを解説します。
画面に表示されないAPIも点検が必要
APIは、アプリケーション同士がデータや機能をやり取りするための仕組みです。スマートフォンアプリやWeb画面でボタンを押すと、その裏側でAPIに要求が送られ、サーバーが処理する構成があります。画面の表示と、サーバーが要求を受け付ける条件は、それぞれ確認する必要があります。例えば、一般利用者には管理ボタンを表示しない設計でも、それだけで管理用APIへの要求を防げるわけではありません。要求を受けたサーバーが利用者の権限を確認しなければ、本来許可されていない機能を実行されるおそれがあります。OWASPは、こうした問題を機能レベルの認可の不備として整理しています*3。
認証は利用者が誰かを確認すること、認可はその利用者が何をしてよいかを判断することです。ログイン済みであっても、すべての顧客情報を閲覧してよいとは限りません。同じ閲覧機能でも、自分の契約に属するデータだけを扱えるよう、対象データごとに権限を確認する必要があります。
図：画面の表示制御とAPIの権限確認
管理用や内部利用を想定したAPIであっても、適切なアクセス制御は欠かせません。OWASPの「REST Security Cheat Sheet」では、非公開のRESTサービスについても、各APIエンドポイントでアクセス制御を実施することを求めています。APIのURLが一般に知られていないことだけを安全性の根拠とせず、アクセス元の制限や利用者の認証・認可を適切に設定する必要があります。
自社で確認すべき6つの点検項目
公開中のシステムとAPIを把握しているか
まず、運用担当者や開発委託先に、現在動いているシステムとAPIの一覧を確認します。サービス名だけでなく、利用目的、管理担当者、接続先、扱うデータ、利用を許可する相手まで整理すると、見直すべき範囲がはっきりします。仕様書と実際の稼働環境に差がないかも確認したいところです。特に確認したいのは、更新前のAPI、試験用の環境、保守用の機能です。OWASPは、管理から漏れた古いAPIや不要な公開環境をリスクとして挙げています*4。本番のAPIを修正しても、同じデータに接続する旧版が動き続けていれば、点検は完了していません。廃止の判断には利用状況を確認し、停止する担当者と日程まで決めておきます。
また、公開Webサーバーから内部のアプリケーションサーバーや管理システムへ、どのような通信が許可されているかも確認します。外部公開していないシステムであっても、公開サーバーを経由して到達できる場合があります。業務上必要な通信に限定されているか、不要な接続経路が残っていないかを点検することが重要です。
利用者ごとの操作権限は適切か
権限の確認では、誰に、どの機能を、どのデータに対して許可するのかを明文化します。例えば「担当者は自分の担当顧客を閲覧できるが、他部署の顧客情報の出力はできない」といった業務上の条件です。一般利用者と管理者の区別に加えて、所属部署や契約先などの境界も整理します。そのうえで、許可された操作が成功することと、許可されていない操作が拒否されることの両方を確認します。機能単位の権限と、データ単位の権限は別々の観点です。実機での確認は、システム所有者と対象範囲を合意し、検証用アカウントやテストデータを用意して進めます。
APIキーやトークンを失効できるか
APIキーやアクセストークンの管理では、発行済みのものを把握できるかに加え、漏えいが疑われた際に失効させられるかを確認します。どのシステムが使い、どこまでの操作を許可し、誰が更新するのかが分からなければ、緊急時の判断が遅れます。OWASPも、秘密情報への最小限の権限付与と、更新・失効・有効期限を含む管理を示しています*5。実務では、鍵の値そのものを点検表に転記せず、識別子と用途、管理先を記録すると扱いやすくなります。更新後に古い認証情報が使えなくなるか、連携先の設定変更が必要かも確かめます。APIキーの所持だけを機密性の高い処理の許可条件とせず、システムの用途や扱う情報に応じて、適切な認証・認可の仕組みを組み合わせることが重要です。
APIの大量実行を制限できるか
操作権限の確認とあわせて、短時間に繰り返される要求への制限も確認します。検索やパスワード再設定など、機能ごとに通常の利用量を把握し、実行回数や一度に返すデータ件数に適切な上限を設けます。OWASPも、業務に応じたレート制限や応答件数の制限を推奨しています*6。ただし、回数を制限しても、権限のない操作が一度でも通る問題は解消しません。認可の点検と並行して進めます。
脆弱性の修正と暫定措置を管理できるか
既知の脆弱性への対応は、利用製品や部品のバージョンを把握することから始まります。開発委託先に確認する場合も、「対応済み」という回答だけで終えず、修正した対象と反映日、残っている課題を共有してもらいます。更新による業務影響が心配な場合は、検証環境で機能を確認したうえで反映します。すぐに更新できなければ、提供元の回避策や機能制限などの適用可否を検討します。OWASPも、修正版の検証と、修正できない場合の暫定的な緩和策を分けて扱っています*7。暫定措置には担当者と見直し期限を設定し、恒久対応まで追跡することを勧めます。
不審な操作をログで追跡できるか
ログの点検では、記録の有無に加えて、利用者と操作内容を結び付けて調べられるかを確認します。認証や権限確認の失敗、権限変更、アカウント作成、データ出力といった操作は、調査に役立つ手掛かりになります。OWASPのログ管理資料でも、これらの記録が取り上げられています*8。例えば、通常と異なる時間帯に大量の出力が行われた場合、操作した主体、対象データ、実行結果を追えるでしょうか。担当者が一件の操作を実際にたどってみると、記録項目や保存先の不足を見つけやすくなります。一方、パスワードやアクセストークンをそのままログに残すと、記録自体が漏えいの原因になり得ます。必要な情報を選び、秘密情報は記録から除外・マスキングする設計が必要です。
点検結果を改善と初動対応につなげる
点検で見つかった問題は、対応する人と完了を確かめる方法まで決めて初めて管理できます。本記事では、点検結果に「対象」「確認できた事実」「業務への影響」「対応担当者」「期限」「再確認の方法」を残す運用を勧めます。判断材料が不足する項目は、問題なしとして閉じず、未確認の内容を明らかにして担当者へ引き継ぎます。例えば、使われていない公開APIが見つかったなら、利用状況を確認して公開を止め、実際に外部から利用できなくなったかを確認します。権限の不備を修正したなら、許可されない操作が拒否されることと、正規の業務が継続できることを再度確かめます。修正作業の完了と、安全性の確認を対応記録の中で結び付けることが大切です。
不正アクセスが疑われる場合の対応
すでに不審な操作が確認されている場合は、予防目的の点検だけでなく、インシデント対応の担当者へ速やかに連絡します。原因調査に必要なログや設定情報などを保全し、証拠を失わないよう注意しながら、被害の拡大を抑える措置を検討します。平時から、夜間や休日の連絡先と、システムの利用停止を判断する責任者を決めておくことも重要です。
脆弱性診断を相談する前に整理しておきたい情報
専門家に相談する際には、対象URLの一覧に加え、API仕様書、利用者の権限区分、重要な業務機能、扱う情報を整理しておくと、確認したい範囲が伝わりやすくなります。顧客向けの画面だけを対象にするのか、管理機能やAPIも含めるのかを、依頼段階で明確にしておきましょう。自社のAPIや管理機能について、どこまでを診断対象に含めるべきか判断が難しい場合は、システムの構成や業務上の権限を共有したうえでご相談ください。運用中のシステムを定期的に点検する機会としては、脆弱性診断を活用できます。
Webアプリケーションの脆弱性を把握し、適切な対策につなげる
ブロードバンドセキュリティ（BBSec）の「Webアプリケーション脆弱性診断」では、Webアプリケーションの脆弱性を診断し、リスクの深刻度と推奨対策をご報告します。管理機能やAPIを含む診断範囲についても、お気軽にご相談ください。
【関連記事】
APIの脅威と対策について知りたい方は、「OWASP API Security Top 10とは？APIの脅威と対策を知ろう」もあわせてご覧ください。
公開範囲と権限を確かめることから始める
今回の注意喚起を自社の対策につなげるには、現在公開しているシステムを把握し、誰がどの情報を扱えるのかを確かめることが出発点になります。まずは主要な業務システムを一つ選び、APIの一覧、権限の設計、操作ログを担当者と確認してみてください。確認できない部分が見つかれば、そこから次の調査や改善につなげられます。
【参考情報】
- JPCERT/CC「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」（2026年10月8日公開、10月9日更新）（https://www.jpcert.or.jp/at/2026/at260030.html）
- OWASP API Security Project「API5:2023 Broken Function Level Authorization」
https://api-security.owasp.org/editions/2023/en/0xa5-broken-function-level-authorization/ - OWASP API Security Project「API1:2023 Broken Object Level Authorization」
https://api-security.owasp.org/editions/2023/en/0xa1-broken-object-level-authorization/ - OWASP API Security Project「API9:2023 Improper Inventory Management」
https://api-security.owasp.org/editions/2023/en/0xa9-improper-inventory-management/ - OWASP Cheat Sheet Series「Secrets Management Cheat Sheet」
https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html - OWASP API Security Project「API4:2023 Unrestricted Resource Consumption」
https://api-security.owasp.org/editions/2023/en/0xa4-unrestricted-resource-consumption/ - OWASP Cheat Sheet Series「Vulnerable Dependency Management Cheat Sheet」
https://cheatsheetseries.owasp.org/cheatsheets/Vulnerable_Dependency_Management_Cheat_Sheet.html
編集責任：木下
ウェビナー開催のお知らせ
最新情報はこちら