MENU

問い合わせ


    JPCERT/CCが「相次ぐ不正アクセス」で注意喚起|スマホアプリのAPI・BIツール・管理画面を持つ発注者が開発会社に確認する6つのこと

    JPCERT/CCは2026年10月8日、国内組織で不正アクセスによる個人情報の漏えいが相次いでいるとして注意喚起を出し、翌9日に内容を更新しました。今回の特徴は、お客様向けのアプリだけでなく、BIツールや従業員向けの管理システムのように「社外の人は使わないはず」のシステムも被害に遭っている点です。

    「うちのスマホアプリや社内の管理画面は大丈夫なのか、開発会社に何を聞けばいいのか分からない…」

    先に結論をお伝えします。発注者が自分で攻撃の手口を理解する必要はありません。ただ、今回の注意喚起で挙がっている対策は「API(アプリとサーバーのやり取りの窓口)の制限」「公開しなくてよい管理機能の非公開化」「古いデータを残さない」など、開発会社と運用担当者が相談して決めることばかりです。この記事では、発注者が開発会社に確認しておきたい6つのことを、そのまま使える質問例とあわせて整理します(情報は2026年10月10日時点)。

    目次

    JPCERT/CCの注意喚起で何が言われているか

    まず事実関係を整理します。JPCERT/CCの注意喚起(JPCERT-AT-2026-0030)では、2026年9月前後から国内組織で不正アクセスによる個人情報等の漏えい被害が相次いでいるとされています。

    📰 出典:JPCERT/CC「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」(2026-10-08公開・10-09更新)

    JPCERT/CCは、複数の製品・サービスで被害が出ている一方で技術的な情報の共有が不足しており、把握している情報は限定的・断片的だと述べています。そのうえで、確認されている攻撃手法を次の4つのケースに整理しています。

    ケース概要(JPCERT/CCの整理)発注者の目線での言い換え
    Aさまざまなソフトウェアの既知の脆弱性を探して攻撃を試みる。設定ファイルやバックアップファイルの窃取を試みる例もある「修正済みの弱点を放置していないか」「見えてはいけないファイルが公開されていないか」
    Bアプリの管理用APIへの不正なリクエスト。公開されているスマホアプリを解析してAPIの接続先やキーを特定する手口などが報告されている「画面からは操作できないはずの窓口を、直接たたかれても大丈夫か」
    CBIツール「Metabase」のSQLインジェクションの脆弱性(CVE-2026-72898)の悪用。8月14日に別途注意喚起が出ている「データを見るための社内ツールが、外から狙われていないか」
    D公開Webサーバーからアクセスできるアプリケーションサーバーに、不正なWebシェル(遠隔操作用の小さなプログラム)を設置(10月9日追記)「1台が破られたとき、奥のサーバーまで広がらないか」

    また注意喚起は、これが普段から起きているランサムウェア等とは別に、大量の個人情報の漏えいにつながり、特に増えている恐れのある攻撃類型を取り上げたものだと位置づけています。

    発注者にとって何が変わるか/変わらないか

    ここからは筆者の見解です。

    変わらないこと:セキュリティ対策は、開発会社と運用担当者が技術的に行う仕事で、発注者がすべてを理解する必要はないという点です。

    変わることは、次の2点だと考えます。

    1. 「社内向けだから後回し」が通りにくくなった。注意喚起は、BIツールや従業員向け管理システムのように、不特定多数の利用者を想定していないシステムも点検の対象だと明記しています。
    2. 「作って納品して終わり」の対象が広がった。公開済みのスマホアプリの裏側にあるAPIや、過去に作った管理画面も、今の目で見直す対象になります。

    なお、この注意喚起は特定の製品や企業が悪いと言っているものではありません。標的ごとに既知の脆弱性や管理の不備を探すタイプの攻撃もあり、どの会社のシステムにも起こり得る話として受け止めるのが現実的です。

    発注者が開発会社に確認したい6つのこと

    注意喚起の「対策」の項目を、発注者が確認しやすい形に直したものです。確認する相手は、システムを作った会社、運用している会社、クラウドの管理担当などです。

    1. 公開している窓口(API・管理画面)の一覧があるか

    何を守るかは、まず「インターネットから届く窓口」を把握するところから始まります。注意喚起は、業務上必要のないサービスや管理機能がインターネットに公開されている場合は公開を停止することを推奨しています。

    • スマホアプリが使うAPI、管理画面、BIツール、検証用の環境など、外から届くものの一覧があるか
    • そのうち、本当に外から使う必要があるものはどれか

    2. APIに「回数制限」と「権限の確認」が入っているか

    注意喚起では、APIへのアクセスに単位時間あたりの回数制限を設けること、ログインやパスワードリセット、SMS送信、検索など悪用されやすい機能には個別の制限をかけることが挙げられています。また、非公開のAPIも含めて、許可された利用者・操作だけを受け付けるアクセス制御を行うことも求められています。

    • 画面のボタンを押せない人が、APIを直接呼んだら操作できてしまわないか
    • 一般ユーザーが、他人の情報を見たり、自分の権限を書き換えたりできないか

    3. APIキー・トークンの管理(有効期限と無効化)

    注意喚起は、APIトークンに有効期限を設けること、不要になったものや漏えいが疑われるものをすぐ無効化できるようにすることを挙げています。ケースBでは、公開されているスマホアプリを解析してAPIの接続先やキーを探す手口が報告されています。

    • 「アプリの中にキーを埋め込んでいるから、誰でも取り出せる前提」で設計されているか
    • 漏えいが疑われたとき、何時間で無効にできるか(誰が操作するか)

    4. 社内ツール・BIツール・管理画面の更新状況

    ケースCのMetabaseのように、データを集めて見せるツールは、大量の情報が一か所に集まっていることが多い点が重要です。

    • 使っているツールと、そのバージョンの一覧があるか
    • 修正版が出たときに、誰がいつまでに更新するか決まっているか
    • 管理画面は、社外からそのまま見える状態になっていないか(接続元の制限や追加の認証があるか)

    5. 1台破られても、奥まで広がらない作りか

    ケースDのように、公開しているWebサーバーから奥のサーバーにたどり着かれる事例が報告されています。注意喚起も、Webサーバー等が侵害された後の横展開(ほかのサーバーへの広がり)対策の見直しを挙げています。

    • 公開サーバーと、データのあるサーバーはネットワーク上で分けられているか
    • データベースに、必要以上の権限でつながっていないか

    6. 不審なアクセスに「気づく」仕組みと、気づいた後の動き

    被害の公表は、本人が気づくのではなく外部からの連絡で発覚する例も少なくありません。注意喚起は、不正アクセス検知体制の点検と、検知時の初動対応の見直しを挙げています。

    • アクセスの記録(ログ)は何か月分残っているか。誰が見られるか
    • 異常を検知したときの連絡先と、最初の1時間にやることが決まっているか
    • 注意喚起に載っている不審な接続元(IPアドレス)が過去の記録にないか、確認を依頼できるか

    また、不要になったデータを残さないことも対策の一つとされています。法令や契約で定められた保存期間を過ぎたデータや、利用目的を終えたデータが残っていないか、あわせて確認しておきましょう。

    今やるべきこと・様子見でいいこと

    区分内容
    今すぐ公開している窓口の一覧を、開発会社・運用会社から出してもらう
    今すぐ注意喚起の内容を自社システムの担当者に共有し、点検を依頼する(今週中に「いつまでに返答をもらうか」を決める)
    今月中上の6項目への回答を文書でもらい、不足があれば対応の費用と時期を相談する
    様子見でよいJPCERT/CCは新しい情報が分かれば同ページを更新するとしています。追加の接続元情報などは、開発会社が確認するので、発注者が毎回追う必要はありません

    費用については、点検や対策が既存の保守契約に含まれるかどうかで扱いが変わります。契約書の範囲を確認し、含まれない場合は見積もりを分けて出してもらうと比較しやすくなります。

    開発会社への質問例(そのまま使えます)

    > 「JPCERT/CCが10月8日に公表した『直近で相次いでいる国内組織における不正アクセスに関する注意喚起』を確認しました。弊社のシステムについて、次の点を教えてください。 > > 1. インターネットから届くAPI・管理画面・BIツールなどの一覧と、外部公開の必要性 > 2. APIの回数制限とアクセス制御(権限確認)の有無 > 3. APIキー・トークンの有効期限と、漏えい時の無効化手順 > 4. 使用中のツール・ライブラリのバージョンと、更新の担当・期限 > 5. 公開サーバーと、データのあるサーバーの分離状況 > 6. ログの保存期間と、異常検知時の連絡・初動の流れ > > 点検が保守契約の範囲に含まれるか、含まれない場合の見積もりもあわせてお願いします。」

    発注者チェックリスト

    • ☐ 公開している窓口(API・管理画面・社内ツール)の一覧を受け取った
    • ☐ 外から使う必要のない窓口は、公開を止める方針を決めた
    • ☐ APIの回数制限・権限確認について、回答をもらった
    • ☐ APIキーが漏れた場合の無効化の手順と所要時間を確認した
    • ☐ BIツール・管理画面のバージョンと更新担当を確認した
    • ☐ ログの保存期間と、異常を見つけた時の連絡先を確認した
    • ☐ 不要になった個人情報のデータが残っていないか確認を依頼した

    まとめ

    JPCERT/CCの注意喚起は、お客様向けのアプリだけでなく、BIツールや従業員向け管理システムも点検対象に含めるよう求めています。発注者がやることは、手口を詳しく学ぶことではなく、「窓口の一覧」「API制限」「キー管理」「更新」「分離」「検知」の6点を、開発会社に聞いて文書で受け取ることです。

    事業者として備えておきたいことの全体像は、過去の記事相次ぐサイバー攻撃と情報漏えい、事業者が今すぐ確認すべきことも参考にしてください。

    あわせて読みたい関連記事

    システム制作・運用・保守のお問い合わせはこちら


      よかったらシェアしてね!
      • URLをコピーしました!
      • URLをコピーしました!

      この記事を書いた人

      株式会社THIRD HERO代表取締役 朝野貴朗
      Webシステム開発を中心に、toC向けサービスサイトの運営、ツール開発などを行ってまいりました。

      目次