「1カ月、その後3カ月」という数字はどこから来たのか

「工場は個人情報をほとんど持っていないから、今回の注意喚起は関係ない」という声は、製造業の情報システム部門では珍しくありません。今回の一連の注意喚起は金融機関や通信事業者の漏えいを受けたもので、確かに読み始めは工場の話に見えません。ただ、IPAが示した点検の中身を順に読むと、MESの周りにある仕組みがほぼそのまま対象に入ってきます。

IPAは2026年10月9日、「不正アクセスによる漏えい等の事案を踏まえ、速やかに実施すべき対策等について」を公開しました。背景として挙げているのは、大量の個人情報を扱うオンラインサービスなどへの侵入と、データの窃取が続いていることです。特定の製品の脆弱性を狙った攻撃とは断定しておらず、公表事例からは、外部に公開しているアプリケーションやサービス、またはアカウントの侵害が起点と推測しています。

求めている点検は3つに分かれます。独自に構築・運用している外部公開アプリケーションの精査、利用している外部サービス(クラウドやVPNなど)の洗い出し、保有データの再点検です。このうちログについて、IPAは確認する範囲を「直近1ヵ月、その後3ヵ月」と段階的に広げるよう書いています。異常なログや身に覚えのないアカウントが見つかれば、その時点でセキュリティインシデントと判定し、専門のセキュリティベンダーへ詳細調査を依頼することを強く推奨しています。

前日の10月8日にはJPCERT/CCが注意喚起(JPCERT-AT-2026-0030)を出し、9日に追記しました。被害が相次いだのは2026年9月前後で、一般向けのアプリだけでなく、BIツールや従業員向けの管理システムのように不特定多数の利用を想定していない仕組みも侵入され、内部の情報が漏れたとしています。確認された手口には、既知の脆弱性の探索、管理用APIへの不正なリクエスト、BIツールMetabaseのSQLインジェクション脆弱性(CVE-2026-72898)の悪用、アプリケーションサーバーへのWARファイル設置によるWebシェル(外部からコマンドを実行させる不正プログラム)が並びます。内閣官房国家サイバー統括室も同じ9日、ウェブシステムの脆弱性管理、委託先を含むサプライチェーン対策、データ管理の3点で対策の徹底を求めました。

工場との接点はここにあります。MESのデータを本社や取引先に見せるためのダッシュボード、ERPとつなぐAPI、ベンダーが保守に使うVPNは、どれも「不特定多数の利用を想定していない」仕組みです。そしてMESの作業者マスタには、氏名、社員番号、資格や教育の記録といった個人情報が入っています。

想定の部品工場で、MESにつながる外部接点を数える

ここからは、従業員300人ほどの部品メーカーの1工場を想定して換算します。工場と仕組みの構成は当サイトが置いた想定で、実在の企業ではありません。MESはオンプレミスで、品質データの一部をクラウドのサービスに置き、取引先には検査成績書をポータルで公開している、という国内ではよく見かける形にしました。

MESに直接または間接につながる外部接点を数えると、次の6つになります。

左端の社外(インターネット)から右端のMESサーバ・DBへ、2本の経路がつながる路線図。上の経路は社外から直接つながる経路で、駅は保守VPN(ログ保持90日)、設備リモート監視(保持期間不明、3カ月分なし)、クラウド品質SaaS(30日、3カ月分なし)。下の経路は自社が公開・連携している経路で、駅は取引先ポータル(180日)、本社向けBI(14日、3カ月分なし)、ERP連携API(60日、3カ月分なし)。3カ月分のログが自社で揃うのは保守VPNと取引先ポータルの2つ。 上の経路:社外から直接つながる 下の経路:自社が公開・連携している 社外 インターネット MES MESサーバ・DB ① 保守VPN ログ保持 90日 ② 設備リモート監視 ログ保持 不明 3カ月分なし ③ クラウド品質SaaS ログ保持 30日 3カ月分なし ④ 取引先ポータル ログ保持 180日 ⑤ 本社向けBI ログ保持 14日 3カ月分なし ⑥ ERP連携API ログ保持 60日 3カ月分なし
想定の部品工場で、MESサーバ・DBへつながる外部接点6つ(構成とログ保持期間は当サイトの想定)

上の経路は、社外の誰かが工場の内側へ入ってくる接点です。MESベンダーが障害対応やバージョンアップに使う保守VPN、設備メーカーが稼働状況を見るためのリモート監視、品質記録の一部を置いているクラウドのサービスがここに入ります。IPAの分類では「利用している外部サービス」にあたり、提供者と利用者で見られるログの範囲が違う可能性がある、とわざわざ断っている部分です。

下の経路は、自社がMESのデータを外へ出している接点です。検査成績書を取引先がダウンロードするポータル、本社の経営会議向けに生産実績を出すBIダッシュボード、受注と実績をやり取りするERP連携のAPIがあります。JPCERT/CCの注意喚起に出てくるBIツール、管理用API、アプリケーションサーバーは、この3つにそのまま重なります。工場のポータルやMESの画面はJavaのアプリケーションサーバー上で動いていることも多く、WARファイルによるWebシェルの手口も他人事ではありません。

1カ月分と3カ月分を人日に換算する

6つの接点それぞれについて、IPAの手順どおりに「アカウントの棚卸し」「直近1カ月のログ確認」「3カ月への拡大」を行うと、どのくらいの作業になるかを試算しました。工数とログの保持期間は、当社がMES導入や保守で見てきた範囲から置いた想定値で、実測値ではありません。担当者がその仕組みの管理画面に慣れていること、ログの形式を読める人が社内か委託先にいることを前提にしています。

外部接点(想定)ログの持ち主ログ保持(想定)棚卸し+1カ月分3カ月への拡大3カ月分は揃うか
① 保守VPN自社(VPN装置)90日1.5人日1.5人日揃う
② 設備リモート監視設備メーカー不明1.0人日0.5人日(照会のみ)不明
③ クラウド品質SaaSサービス提供者30日1.5人日0.5人日(提供者へ依頼)揃わない
④ 取引先ポータル自社(アプリサーバ)180日2.0人日2.0人日揃う
⑤ 本社向けBI生産技術部門14日1.0人日なし揃わない
⑥ ERP連携APIERP・MES両ベンダー60日1.5人日1.0人日揃わない
合計8.5人日5.5人日6つ中2つ

合計は約14人日です。1人が専任で動けば3週間弱、兼務なら1カ月半ほどかかる計算になります。重いことは重いのですが、工場の情報システム部門が手をつけられない量ではありません。

この表で目を引くのは工数ではなく右端の列です。3カ月分のログが自社の手元で揃うのは、保守VPNと取引先ポータルの2つしかありません。BIダッシュボードは導入時の初期設定のまま、ログを2週間で上書きしている想定です。クラウドのサービスは管理画面から見られる範囲が30日で、それより前は提供者に依頼しないと出てきません。ERP連携のAPIは、エラーのログは残っていても、どのアカウントが何件のデータを取ったかという記録をそもそも取っていないことがあります。

JPCERT/CCが観測したとしている不審な送信元の一部は、8月28日ごろや8月上旬から9月上旬の時期のものです。10月半ばの時点で3カ月を遡れば7月半ばまで届くので、この期間はちょうど点検範囲に入ります。逆に言えば、保持が14日や30日の接点では、問題の時期のログはすでに消えています。

3カ月分が残っていない接点は、何で埋めるか

ログの無い期間は、あとから取り戻せません。残っていない接点については、ログの代わりになる材料を集めることと、次に同じことが起きたときに遡れるよう設定を変えることの2つを同時に進めます。

代わりになる材料は、接点によって違います。BIダッシュボードなら、ダッシュボードの閲覧ログが無くても、接続先であるMESのデータベース側に、BI用アカウントの接続記録やクエリの記録が残っていることがあります。クラウドのサービスは、管理画面の30日より長い期間のログを提供者が保持している場合があるので、契約上どこまで出してもらえるかを確認します。IPAが「提供者と利用者で確認できる範囲が異なる可能性がある」と書いているのは、この点です。設備メーカーのリモート監視は、自社では接続の有無すら把握していないことが多く、まず接続経路とアカウントの一覧を出してもらうところから始まります。

アカウントの棚卸しは、ログの有無にかかわらず全接点で実行できます。MESまわりで残りやすいのは、導入プロジェクトのときにベンダーの担当者へ発行した保守用アカウント、BIの接続に使っている共用のデータベースアカウント、異動した生産技術担当者が作ったAPIキーです。国家サイバー統括室の文書が退職者・異動者の不要なアカウントの無効化を、JPCERT/CCがAPIトークンの有効期限設定と、漏えいが疑われるトークンを速やかに無効化できる体制を挙げているのは、こうした残り方を想定したものと読めます。

この試算の前提は、接点が6つで、どれも管理者がはっきりしている工場です。実際には、部署単位で契約したクラウドのサービスや、試験導入のまま動き続けている仕組みが見つかり、接点の数そのものが増えることのほうが多いはずです(推測)。IPAが外部サービスについて「組織全体や部署単位で利用しているもの」をできる限り網羅的に把握するよう求めているのも、こうした見落としが起きやすいことを踏まえたものと読めます。数え直した結果、表の行が増えるのであれば、それが今回の点検で得られる最初の成果になります。

MES全体のセキュリティの考え方はMES/OTセキュリティの基礎に、ゾーンとコンジットによる分け方はIEC 62443の解説に、ベンダーから出る脆弱性情報の受け止め方はCRA報告義務とAI脆弱性探索の記事にまとめています。

個人情報をほとんど扱わない工場も、今回の点検の対象になりますか?

IPAが名指ししている対象は、大量の情報資産や機微な情報を扱う事業者の経営者です。ただし、JPCERT/CCはBIツールや従業員向けの管理システムなど管理・運用側の仕組みも被害に遭ったとしており、MESの作業者マスタにも氏名や社員番号は入っています。取引先の図面や品質データも含めれば、点検しておく理由は十分にあります。

14人日という工数は、どの工場にも当てはまりますか?

当てはまりません。外部接点6つ、管理者が明確、ログ形式を読める担当者がいる、という当サイトの想定で置いた試算です。接点の数とログの保持期間を自社の値に置き換えて計算し直してください。

ログが残っていない期間に侵入されていたかどうかは、もう分かりませんか?

ログ以外の痕跡で分かる場合があります。接続先のデータベース側の記録、サーバー上に置かれた見覚えのないファイル(JPCERT/CCはWARファイルによるWebシェルの事例を挙げています)、作成した覚えのないアカウントなどです。自社で判断がつかない場合は、専門のセキュリティベンダーに調査を依頼してください。

この記事に出てくる用語

MES用語集(日・英・中)をすべて見る

この記事を書いた人

株式会社サオス

株式会社サオス MESソリューション部

DELMIA Apriso を中核とした MES / 製造DX の導入・運用・人材育成を手がけるITコンサルティング企業。ISO 9001:2015 / ISO 27001:2022 認証取得。 日本・中国・米国で製造業のMES導入を手がけた実務者が、欧米・中国の一次情報にあたって書いています。