デジタルアーツは2026年10月21日、同社クラウドサービスの運用に使う認証情報が第三者に取得され、運用環境へ侵入されていたと公表しました。痕跡には2025年7月頃までさかのぼるものが含まれているとのことです。この記事では、i-FILTER@Cloudやm-FILTER@Cloudを使う企業・自治体・学校の担当者に向けて、自社が対象かの確かめ方、管理者用と利用者用のパスワードを変える順番、手元のログでどこまで遡れるかを整理します。後半では、同じ構造の事故を自社のSaaSで起こさないための運用鍵の棚卸しを、実行できるコードで示します。
まとめ：デジタルアーツ不正アクセスで利用企業が今週中に終える作業の結論
対象は、i-FILTER@Cloud、m-FILTER@Cloud（Modern Edition）、m-FILTER MailAdviser Microsoft 365 対応版、FINAL CODE@Cloud、z-FILTER、Deskの6サービスです。自社のネットワーク内に導入したソフトウェア版は対象外と明記されています。
6サービスのどれかを契約しているなら、管理者用と利用者用のパスワードを全員分変えてください。公式発表が求めているのはこの1点で、追加の対応が要る顧客にはデジタルアーツから個別に連絡が来ます。変えたパスワードと同じものを別のサービスでも使っていた場合は、そちらも変更の対象です。
ログ調査は、遡れる範囲を先に確かめてから始めます。侵入の痕跡は約15か月前からあるのに対し、IdPやSaaSの既定のログ保持は7日〜30日程度のことが多く、多くの組織では2025年7月までは届きません。届かない前提で、パスワード変更と今後の監視に工数を寄せる判断が現実的です。
デジタルアーツ不正アクセスで公表された事実と、まだ公表されていない点
10月21日公表の内容：運用用の認証情報の窃取と約15か月にわたる痕跡
デジタルアーツの公式発表によると、発端は2026年10月9日に同社がAIを使って行ったシステム・製品・社内環境の総点検です。従来の点検では見つからなかった不正アクセスの痕跡が、クラウドサービスの運用環境と社内環境の両方で見つかりました。
侵入の経路は「クラウドサービスの運用に用いる認証情報」が第三者に不正に取得されたことで、これを使って運用環境に入られています。その結果、対象サービスを使う一部の顧客の情報が閲覧された可能性があるとされました。10月21日正午時点で、顧客情報の外部への持ち出しは確認されておらず、悪用や二次被害の報告も受けていないという記載です。
同社は発覚後に、使われた認証情報の無効化、運用に使う認証情報の交換、不審なプログラムの停止、サーバー認証鍵の交換を実施しました。同日のIR版の開示資料には、業績への影響は精査中で、開示が必要になれば速やかに知らせるとの一文が加わっています。
公表されていない点：件数・閲覧された情報の種類・侵入経路の詳細
10月23日時点の公式発表には、閲覧された可能性のある顧客の件数がありません。どの種類の情報（契約者名、管理者アカウント、ポリシー設定、通信ログなど）が見られうる状態だったのかも書かれていません。
運用用の認証情報がどこから、どのように盗まれたのかも未公表です。報道の中には原因を推測で補う記事もありますが、利用企業の判断材料としては公式発表と個別連絡だけを使ってください。推測で「自社は関係ない」と決めると、個別連絡の対象だった場合に動き出しが遅れます。
10月22日のPHP脆弱性告知は別事象：混同せずに切り分ける理由
翌10月22日、デジタルアーツはPHPの脆弱性への対応状況も告知しました。2026年10月21日に公表されたPHPの脆弱性（CVE-2026-109618、CVE-2026-109619）の影響調査で、告知の中に「不正アクセスとは別の事象」と明記されています。
こちらはオンプレミス製品のFINAL CODE Ver.6 VAとD-SPAが対応中の対象で、利用者には10月23日までに暫定対策を個別に案内するとしています。不正アクセスの件はクラウド6サービス、PHPの件はオンプレミス2製品と、対象も必要な作業も別々です。社内に周知するときは2件を1通にまとめず、別々に出すほうが誤読を防げます。
自社の利用サービスが対象かを確かめる：6サービスとソフトウェア版の線引き
対象6サービスの一覧と、対象外になるオンプレミスのソフトウェア版
製品名が似ているため、クラウド版とソフトウェア版を取り違えやすい点に注意します。公式発表の対象は「@Cloud」などのクラウド提供形態で、自社環境に導入したソフトウェア版は対象外です。表ではm-FILTER@Cloud（Modern Edition）をm-FILTER@Cloud、m-FILTER MailAdviser Microsoft 365 対応版をMailAdviser M365 対応版と略記します。
| 対象のクラウドサービス | 対象外になる形態 |
|---|---|
| i-FILTER@Cloud | 自社導入のi-FILTER |
| m-FILTER@Cloud | 自社導入のm-FILTER |
| MailAdviser M365 対応版 | 自社導入の版 |
| FINAL CODE@Cloud | 自社導入のFINAL CODE |
| z-FILTER | 同名の自社導入版の記載なし |
| Desk | 同名の自社導入版の記載なし |
表の右列は、公式発表の「お客様ご自身の環境に導入いただいているソフトウェア版は対象外」という一文を製品ごとに当てはめたものです。判定の根拠は、製品名ではなく「デジタルアーツのクラウド上で動いているか」です。
契約書・請求書・管理画面のURLで自社の利用形態を突き合わせる手順
情シスが製品名だけを覚えていて、提供形態まで把握していない組織は珍しくありません。次の順で確かめると、半日以内に判定できます。
- 販売代理店からの請求書と契約書で、品名に「@Cloud」「Microsoft 365 対応版」などクラウドを示す表記があるか確認する
- 管理画面を開くときのURLが、自社ネットワーク内のサーバーか、デジタルアーツが運営するドメインかを見る
- 社内にi-FILTERやm-FILTERのサーバー機やアプライアンスがあるか、資産台帳と突き合わせる
- 学校や自治体では、教育委員会や上位組織が一括契約していないかを確認する
4番目は見落としやすい項目です。教育委員会が一括で契約している場合、学校側には契約書も管理画面の権限もないことがあります。判断できない場合は、公式発表の問い合わせ先（お客様専用サポート窓口）か販売代理店に、契約IDを添えて問い合わせてください。
管理者と利用者のパスワードを変える：変更範囲と順番、使い回しの洗い出し
管理者用を先に、利用者用を後に変える理由と社内の全員変更の進め方
変更は管理者用から始めます。管理者アカウントはフィルタリングのポリシーや除外設定を書き換えられるため、ここを押さえられたままだと、利用者のパスワードを変えても通信制御を外される余地が残ります。
利用者用は人数が多いので、期限を決めて一斉に変更を求めます。NIST SP 800-63B-4の3.1.1.2は、定期的なパスワード変更を求めてはならないとする一方で、認証情報が侵害された証拠がある場合は変更を強制しなければならないと定めています。今回は後者に当たるので、任意の呼びかけではなく強制として扱うのが筋です。
変更を終えた人と終えていない人を一覧で追える状態にしてください。管理画面で最終変更日時を出せるなら、その一覧を期限の翌日に確認します。
同じパスワードを別サービスで使い回していた場合に広げる変更範囲
管理者が同じパスワードを、ほかの管理画面やVPN、社内のIdPでも使っていた場合は、そちらも変更の対象に入れます。閲覧された情報に認証情報が含まれていたかは公表されていませんが、含まれていた場合に最初に試されるのは、別サービスへの同じ組み合わせでのログインです。
使い回しを根絶する手段は、パスワードの強化より多要素認証の有効化のほうが確実です。管理者アカウントだけでも先に有効化しておくと、パスワードが漏れていた場合の被害を止められます。方式の選び方は多要素認証の3要素と耐フィッシングMFAの実装方式で整理しています。
SSO連携や連携用アカウントがある場合にサポート窓口へ確認する項目
SAMLなどでIdPと連携し、サービス側にパスワードを置かずに使っている利用者もいます。この場合、公式発表の「利用者用のパスワード変更」が誰の何を指すのかは、契約ごとの設定によって変わります。自己判断で済ませず、次の点を窓口に確認してください。
- SSO連携している利用者に、サービス側で変更すべきパスワードがあるか
- IdPとの連携で登録した証明書やメタデータを入れ替える必要があるか
- ディレクトリ連携やメール連携のために登録した連携用アカウントの認証情報を交換すべきか
連携用アカウントは人が普段ログインしないため、交換の対象から漏れがちです。SSOそのものの仕組みはシングルサインオンの4つの実現方式とIDトークン検証で確認できます。
監査ログで侵入の痕跡を探す：2025年7月まで遡れるかとPythonでの抽出
約15か月の潜伏に対し、IdPの既定ログ保持は7日〜30日という差
最初に確かめるのは、自社の手元にどこまで古いログが残っているかです。Microsoft Entraのデータ保持の説明では、サインインログと監査ログの既定の保持期間はEntra ID無料版で7日、P1とP2で30日です。保持期間の変更はさかのぼって効かず、期限切れのデータは事前にアーカイブしていない限り戻らないとも書かれています。
2025年7月から2026年10月9日の発見までは、およそ15か月あります。既定設定のままなら、その大半は手元に残っていません。
ここで判断を言い切ります。ログをストレージやSIEMに送っていない組織は、2025年7月まで遡る調査に工数をかけないでください。残っている30日分で直近の不審な動きだけを確認し、残りの工数はパスワード変更、多要素認証の有効化、今後のログ保存の設定に回します。逆に、長期保存の仕組みがある組織は、15か月分を下のコードで絞り込む価値があります。
管理者ログイン履歴から許可外IPと業務時間外を抜き出すPythonコード
管理画面やIdPからエクスポートしたログイン履歴のCSVを読み、2025年7月1日以降で「許可外のIPから」「業務時間外に」「失敗した」ログインを抜き出します。標準ライブラリだけで動き、列名はtimestamp、user、source_ip、resultを想定しています。実際のエクスポートの列名に合わせて読み替えてください。CSVの読み方はPythonのcsvモジュールの公式ドキュメントのとおりです。
import csv
import ipaddress
import sys
from datetime import datetime
# 自社の固定IP（拠点・VPN出口）をCIDRで列挙する
ALLOWED = [ipaddress.ip_network(c) for c in ("203.0.113.0/24", "198.51.100.10/32")]
SINCE = datetime.fromisoformat("2025-07-01T00:00:00+09:00")
BUSINESS_HOURS = range(8, 21) # 8時台〜20時台を業務時間とみなす
def suspicious(row):
ts = datetime.fromisoformat(row["timestamp"])
if ts < SINCE:
return None
ip = ipaddress.ip_address(row["source_ip"])
reasons = []
if not any(ip in net for net in ALLOWED):
reasons.append("許可外IP")
if ts.hour not in BUSINESS_HOURS:
reasons.append("業務時間外")
if row["result"] == "failure":
reasons.append("失敗")
return reasons or None
with open(sys.argv[1], newline="", encoding="utf-8") as f:
for row in csv.DictReader(f):
r = suspicious(row)
if r:
print(row["timestamp"], row["user"], row["source_ip"], ",".join(r))2026年10月23日にPython 3.14.7で、架空の5行のCSVに対して実行しました。2025年6月の行は期間外として除かれ、次の3行が出力されます。
2025-07-14T02:41:00+09:00 admin02 192.0.2.44 許可外IP,業務時間外
2026-03-02T13:05:00+09:00 admin01 198.51.100.10 失敗
2026-10-08T23:30:00+09:00 ops-svc 192.0.2.77 許可外IP,業務時間外抽出結果の読み方：ヒットしても侵入とは限らない正規操作による誤検知の典型
抽出された行は、侵入の証拠ではなく確認の候補です。在宅勤務の担当者が自宅回線から夜にログインした、出張先のホテルから設定を変えた、といった正規の操作が「許可外IP」「業務時間外」で必ず混ざります。
候補は、本人へのヒアリングで説明がつくものから順に消していきます。説明がつかない行が残ったら、その時刻の前後で設定変更の操作ログがないかを見ます。フィルタリングの除外設定やポリシーの変更が見つかった場合は、自社だけで判断せず、契約ID・時刻・接続元IPを添えてデジタルアーツの窓口に連絡してください。
SaaSを運営する側の教訓：運用用の認証情報を長く生かさない設計
運用者の鍵が1本盗まれると全顧客に届く構造と、運用権限の分け方
今回の侵入口は、個々の顧客のアカウントではなく「サービスの運用に用いる認証情報」でした。マルチテナントのSaaSでは、運用者の鍵は全顧客のデータに届く設計になりやすく、1本の窃取が全顧客への影響に直結します。取引先経由で被害が広がる構図はサプライチェーン攻撃の起点別3類型のうち、委託先・サービス提供者を起点とする型に当たります。
自社でSaaSや業務システムを運営しているなら、次の順で見直します。優先度が最も高いのは1番目です。
- 人が使う運用アカウントと、バッチやデプロイが使う機械用の鍵を分ける
- 機械用の鍵は有効期限の短い一時認証情報に置き換え、長期のアクセスキーを減らす
- 顧客データに届く操作は、通常の運用権限とは別の権限に切り出し、使うたびに承認と記録を残す
APIの認可やトークン失効の設計はAPI不正アクセス対策の実装手順で扱っています。
AWSの認証情報レポートで90日以上交換していないアクセスキーを洗い出す
AWSで運用しているなら、まず長期間交換していないアクセスキーを一覧にします。AWSの認証情報レポートは、アカウント内の全IAMユーザーについてアクセスキーの最終交換日時と最終使用日時を返す形式はCSVです。レポートは4時間に1回まで生成でき、ユーザーごとに最初の2本のアクセスキーまでが載ります。
aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 -d > report.csv
python stale_keys.py report.csv3行目で呼ぶstale_keys.pyは、有効なキーのうち最終交換から90日を超えたものを出力します。
import csv
import sys
from datetime import datetime, timezone, timedelta
LIMIT = timedelta(days=90)
now = datetime.now(timezone.utc)
with open(sys.argv[1], newline="", encoding="utf-8") as f:
for row in csv.DictReader(f):
for n in ("1", "2"):
if row[f"access_key_{n}_active"] != "true":
continue
rotated = datetime.fromisoformat(row[f"access_key_{n}_last_rotated"])
used = row[f"access_key_{n}_last_used_date"]
if now - rotated > LIMIT:
print(f"{row['user']} key{n} 未交換{(now - rotated).days}日 最終使用={used}")列名はレポートの仕様に合わせています。2026年10月23日に、最終交換日が2025年4月2日のキーを含む架空の2行で実行し、「ops-deploy key1 未交換568日」の1行だけが出ることを確かめました。最終使用日が直近なのに長期間交換していないキーが、最初に一時認証情報へ移すべき候補です。キーを交換したあとの監査ログの見方はTiDB Cloud不正アクセスでのAPIキー交換と監査ログ確認も参考になります。
定期点検で見つからなかった痕跡に備え、ログの保存期間を侵入期間より長くする
デジタルアーツの痕跡は、従来の点検では見つからず、AIを使った総点検で初めて見つかりました。点検の手法を変えたときに過去を調べ直せるかどうかは、ログが残っているかで決まります。
運営側の目安は、想定する潜伏期間より長い保存です。今回の約15か月を基準にするなら、認証・管理操作・運用環境へのアクセスのログは少なくとも18か月を、改ざんできない保存先に送っておきます。転送と保管の設計はFluentdで監査ログ基盤を作る手順で、欠損させない設定と合わせて解説しています。
個人データが含まれていた場合の報告判断：委託先の事故で利用企業が負う義務
個別連絡で確認する項目と、個人情報保護委員会への速報・確報の期限
クラウドサービスに預けていた情報に、従業員や児童生徒、取引先の個人データが含まれていた場合、利用企業は委託元として報告の主体になりえます。デジタルアーツから個別連絡が来たら、閲覧された可能性のある情報の種類、対象の人数、期間を書面で受け取ってください。
個人情報保護委員会の漏えい等の対応ページでは、速報は発覚日から3〜5日以内、確報は30日以内、不正の目的で行われたおそれがある場合は60日以内とされています。第三者による不正アクセスは「不正の目的」に当たりうるので、60日の枠を前提に準備を進めてください。報告の対象になる4類型と書式の実務は個人情報保護委員会への報告義務の解説にまとめています。
自社で点検できない範囲を外部に頼む判断：脆弱性診断とフォレンジック
外部に頼む範囲は、目的で分けます。侵入されたかどうかを過去にさかのぼって調べたいなら、フォレンジック調査の領域です。ログが残っていないと調べられる範囲は狭くなるので、依頼の前に保持期間を確かめておきます。
一方、自社のWebシステムやSaaSに、運用用の認証情報の置き方やアクセス制御の穴が残っていないかを点検したいなら、脆弱性診断が向いています。一創では、運用用の鍵の保管先、管理画面の認証、ログの保存までを対象に脆弱性診断・セキュリティ診断を受け付けています。今回の事案を受けて、自社のサービスに同じ構造がないかを確かめたい場合に相談してください。
よくある質問
デジタルアーツの不正アクセスについて、利用企業の担当者から出やすい質問に、10月23日時点の公式発表に沿って答えます。
i-FILTERをオンプレミスで使っている場合も対応が必要ですか？
公式発表では、顧客自身の環境に導入したソフトウェア版は対象外とされています。自社のサーバーやアプライアンスで動かしているi-FILTERやm-FILTERであれば、今回の不正アクセスについてパスワード変更の依頼は出ていません。ただし、同じ管理者パスワードをクラウド版や別のサービスでも使っていた場合は、そちらの変更は必要です。10月22日のPHP脆弱性の告知はオンプレミスのFINAL CODE Ver.6 VAとD-SPAが対象なので、該当製品の有無も確認してください。
何件の情報が漏れたのですか？
10月23日時点で、件数は公表されていません。公式発表は「一部のお客様の情報が第三者に閲覧された可能性」とし、10月21日正午時点で外部への持ち出しは確認されていないと記載しています。どの種類の情報が対象かも未公表です。追加の対応が必要な顧客には個別に連絡するとしているので、自社が対象かどうかは個別連絡と窓口への問い合わせで確かめるのが確実です。
パスワードはいつまでに変えればよいですか？
公式発表に期限の記載はありません。ただし、運用用の認証情報が窃取されて運用環境に入られた事案で、痕跡は2025年7月頃までさかのぼります。管理者用は当日中、利用者用は数日以内を目安に、社内で期限を決めて進めるのが妥当です。NIST SP 800-63B-4も、侵害の証拠がある場合は変更を強制するよう定めています。
SSOで連携している場合もパスワード変更は必要ですか？
SAMLなどでIdPに認証を任せている利用者は、サービス側に変更すべきパスワードを持っていないことがあります。一方で、管理者がサービス側のアカウントで直接ログインできる設定や、連携用の証明書・アカウントが残っている場合もあります。設定は契約ごとに違うため、自社の構成を伝えたうえで、何を変更・交換すべきかを窓口に確認してください。
自社のログで侵入の有無を確かめられますか？
侵入されたのはデジタルアーツの運用環境なので、利用企業の手元のログに痕跡が残るとは限りません。手元で確かめられるのは、管理画面やIdPに不審なログインや設定変更がないかです。保持期間が30日程度の環境では、2025年7月までは遡れません。残っている範囲を記事中のPythonコードで絞り込み、説明のつかない操作が見つかった場合に窓口へ連絡してください。
関連記事
- ユニリタの不正アクセスと情報漏えい【第3報】漏れた顧客の認証情報と取引先が回す手順：SaaS提供者側の事故で利用企業が認証情報を交換する手順
- SaaSセキュリティ対策の実装手順｜設定診断・OAuth棚卸し・ログ監視を解説：利用中のSaaSを平時から点検する方法
- TiDB Cloud不正アクセスの範囲と対応：APIキー交換と監査ログ確認の手順：クラウド事業者の事故後に鍵を交換する実例
- サプライチェーン攻撃とは？起点別3類型と最新事例・対策の優先順位：委託先・提供者を起点とする攻撃の全体像
- 情報漏洩対策とは：原因別4類型の防ぎ方と発生時の報告義務【2026年10月版】：情報漏洩を原因別に防ぐ全体像
