スカラコミュニケーションズの不正アクセスと最大71万件：管理サイトから他社へ広げない設計

スカラコミュニケーションズ（以下SC社）は2026年10月6日、FAQシステム「i-ask」の管理サイトに第三者が不正ログインし、同じサーバーで動いていた利用企業最大5社の問い合わせ情報、延べ最大713,126件が漏えいした可能性があると公表しました。10月7日までに大和証券、シチズン時計、損保ジャパン、東武鉄道が利用企業として名乗り出ています。本記事では5つの公表文を突き合わせて範囲を整理し、1回の不正ログインが複数社へ届いた構造を、SaaSを提供する側の実装に落とす内容です。アップロード先でスクリプトを動かさないnginx設定、実行可能なファイルを洗い出すPython、利用企業ごとのデータベース分離、委託先としての通知の順番までを扱います。

まとめ：スカラコミュニケーションズの不正アクセスで確定した事実とSaaS事業者の対策

確定しているのは、10月2日20時30分頃から3日8時頃にかけて、i-askの管理サイトへの不正ログインを起点にサーバー上へ不正なプログラムが置かれ、同一サーバー上の利用企業の環境からデータベースの問い合わせ情報が取得された可能性がある、という点です。発覚の契機はデータベースの監視アラートでした。不正ログインに使われた認証情報の入手経路は、10月9日時点で公表されていません。

SaaS事業者が自社の基盤で先に確かめるのは4点です。管理サイトがパスワードだけで入れる状態になっていないか。アップロードしたファイルがサーバー上でプログラムとして動かないか。ある利用企業の環境で動いたプログラムから、他社のデータベースに届かないか。そして侵害時に、利用企業ごとの影響を当日中に言えるか。SC社が再発防止策に挙げた多要素認証、環境間の分離、監視の強化は、この4点にそのまま対応しています。

SC社と利用企業4社の公表文を時系列で並べる｜10月2日の不正ログインから7日まで

SC社の10月6日付お知らせで確定した管理サイト経由の侵入と延べ713,126件

SC社の2026年10月6日付のお知らせによると、第三者がi-askの管理サイトに不正にログインし、不正なプログラムを設置したうえで、同一サーバー上の利用企業のシステム環境のデータベースから問い合わせ情報を取得した可能性があります。SC社は10月3日朝、データベースの監視アラートを契機に調査を始め、同日8時頃に遮断し、該当する利用企業には同日中に報告しました。

件数の713,126件は問い合わせ単位の延べ件数で、同じ顧客の複数回の問い合わせを重ねて数えています。実際の人数は名寄せ中です。対象の項目は氏名、メールアドレス、問い合わせ内容などで、利用企業によって異なるとされています。SC社は不正ログインに使われたアカウントと全環境の管理者のパスワードを変え、攻撃元IPアドレスを遮断し、アップロードされたファイルをプログラムとして実行できない設定に変えました。

大和証券・シチズン時計・損保ジャパン・東武鉄道の公表で分かれた影響の範囲

利用企業側の公表は10月5日の大和証券から始まり、7日の2社で4社になりました。同じ侵害でも、預けていた項目と影響の有無は社ごとに違います。

大和証券の公表文は口座番号を含むとし、シチズン時計のお知らせは本文に口座やカード情報を書いた場合はそれも対象としています。損保ジャパンの公表文によれば、事業者向けドライブレコーダー「SMILING ROAD」の問い合わせで、ドライバーID、運転アラートの種別と発生日時、機器のシリアル番号までが対象に含まれるとの説明です。一方で東武鉄道の公表文は、現時点の調査で同社に関する情報の閲覧と取得の形跡は確認されていない、とのSC社の報告を載せています。

10月9日時点で未公表のまま残る認証情報の入手経路と5社目の利用企業

管理サイトのログインに使われた認証情報を、攻撃者がどう手に入れたかは書かれていません。脆弱性の悪用か、パスワードの流出か、推測による突破かで、効く対策は変わります。本記事では手口を特定せず、どの経路で入られても被害を広げない設計の側を扱います。

SC社は対象を「最大5社」としており、4社以外の利用企業はまだ名乗り出ていません。SC社は外部の専門機関とフォレンジック調査を進めているため、経路と5社目は調査結果の公表を待つことになります。委託元の担当者が自社側で確かめられるログの範囲は不正アクセスのログ確認・解析方法で整理しています。

1回の不正ログインが最大5社に届いた構造｜同一サーバーと管理サイトの権限

管理サイトへのファイル配置がサーバー上のプログラム実行につながる型

SC社は不正なプログラムの設置方法を明かしていません。ただ、緊急対応にアップロードされたファイルを実行させない設定変更を入れたことは、管理サイトのファイル機能が対策の対象になったことを示しています。

FAQシステムの管理サイトには、回答に添える画像やマニュアルを上げる機能がよくあります。上げたファイルがWebサーバーの公開ディレクトリに置かれ、拡張子が.phpなどならサーバーはそれをプログラムとして実行します。これが一般にWebシェルと呼ばれる型です。OWASPのFile Upload Cheat Sheetは、許可する拡張子を絞ること、保存先をWebルートの外に置くこと、ファイル名をサーバー側で付け直すことを挙げています。管理者が使う機能だからと検査を省くと、管理者の認証が破られた時点でサーバー上の任意の処理に直結します。

同一サーバーに同居した利用企業の環境とデータベースが一度に読まれる理由

SC社の説明では、利用企業ごとに「システム環境」と「データベース」は分かれていました。それでも最大5社に届いたのは、同じサーバーの上で動いていたからです。i-askの内部構成は公表されていないため、ここでは一般的なWebアプリケーションの構造で説明します。

サーバーに置かれたプログラムは、Webサーバーやアプリケーションと同じOSユーザーの権限で動きます。そのユーザーが各社の環境の設定ファイルを読めるなら、ファイルに書かれたデータベースの接続情報も読めます。データベースが社ごとに分かれていても、接続に必要な情報が1つのOSユーザーから全部見えていれば、分離は不正プログラムに対して働きません。分離の効き目は、データベースの単位ではなく、プログラムが動く権限の単位で決まります。

東武鉄道だけが閲覧・取得の形跡なしと報告を受けられた利用企業別ログの粒度

同じ侵害の報告を受けた利用企業のうち、東武鉄道は閲覧と取得の形跡が確認されていないと伝えられました。利用企業ごとにこう言い切るには、どの環境のデータベースに、いつ、どの接続から読み出しがあったかを社ごとに区別できる記録が要ります。

記録がサーバー全体で1本しかなければ、事業者は最大の範囲を全社に伝えるしかありません。データベースの監査ログやクエリの記録を利用企業の単位で分けて保存しておくと、影響の無い利用企業を早く外せます。委託元にとっては、顧客への通知や報告の要否がこの1行で変わります。

アップロード領域でプログラムを動かさない｜nginx設定とPythonによる検出

nginxのlocationでアップロード先のスクリプト実行を403にする設定例

PHPで動く管理サイトをnginxで配信している場合の例です。nginxのlocationの仕様では、最も長く一致した前方一致のlocationに^~が付いていると、正規表現のlocationは検査されません。これを使うと、アップロード先のURLはPHPの処理に回らなくなります。

# アップロード先（例: /uploads/）はPHPの処理に回さず、スクリプトの拡張子は403で返す
location ^~ /uploads/ {
    location ~* \.(php|phtml|phar|jsp|aspx|cgi|pl|sh)$ {
        return 403;
    }
}

外側の^~だけで、サーバー直下にある\.php$の処理用locationには届かなくなります。内側の403は、静的ファイルとしてソースを返してしまうことも防ぐ二重の止めです。反映前にnginx -tで構文を確かめ、PHPのテスト用ファイルを置いて403が返ることを確認してください。根本は保存先をWebルートの外に移すことで、この設定は移すまでの間の手当てと位置付けます。

利用企業ごとのアップロード領域から実行可能なファイルを洗い出すPython

設定を変えても、すでに置かれたファイルは残ります。次の例は、利用企業ごとのディレクトリを順に見て、実行されうる拡張子のファイルと、先頭がスクリプトになっているファイルを洗い出すためのコードです。標準ライブラリのpathlibだけで動きます。

# アップロード領域に置かれた「実行されうるファイル」を利用企業ごとに洗い出す（Python 3.9以上）
import sys
import time
from pathlib import Path

EXEC_EXT = {".php", ".phtml", ".phar", ".jsp", ".jspx", ".asp", ".aspx", ".cgi", ".pl", ".sh"}
SIGNATURES = (b"<?php", b"<?=", b"<%@", b"<%", b"#!/")

def suspicious(path: Path) -> list[str]:
    reasons = []
    suffixes = [s.lower() for s in path.suffixes]
    if any(s in EXEC_EXT for s in suffixes):
        reasons.append("拡張子 " + "".join(suffixes))
    try:
        with path.open("rb") as f:
            head = f.read(4096)
    except OSError:
        return reasons + ["読み取り不可（ウイルス対策による隔離の可能性）"]
    if any(head.lstrip().startswith(sig) for sig in SIGNATURES) or b"<?php" in head:
        reasons.append("先頭がスクリプト")
    return reasons

def scan(root: Path, hours: float) -> int:
    since = time.time() - hours * 3600
    hits = 0
    for tenant in sorted(p for p in root.iterdir() if p.is_dir()):
        for path in tenant.rglob("*"):
            if not path.is_file():
                continue
            reasons = suspicious(path)
            if reasons:
                hits += 1
                new = "新規" if path.stat().st_mtime >= since else "既存"
                print(f"[{tenant.name}] {new} {path.relative_to(root)}: {'／'.join(reasons)}")
    return hits

if __name__ == "__main__":
    root = Path(sys.argv[1])
    hours = float(sys.argv[2]) if len(sys.argv) > 2 else 24
    sys.exit(1 if scan(root, hours) else 0)

3社分の模擬ディレクトリに6ファイルを置いてpython upload_scan.py 対象ディレクトリ 24で実行すると、banner.php.jpgの二重拡張子、中身が<?phpで始まるnote.png、info.phtmlの3件が利用企業名付きで出力され、PNG画像・PDF・テキストは通過しました。検出があると終了コードが1になるため、cronや監視の仕組みから定期実行して通知に回せます。

拡張子を.pngに偽装したファイルを中身の先頭で拾う点が、拡張子だけの検査との差です。ウイルス対策ソフトが先に隔離したファイルは読み取りに失敗するため、その場合も「読み取り不可」として一覧に残します。24時間以内に作られたものは「新規」と付くので、侵害が疑われる時間帯と突き合わせる材料になります。

管理サイトの認証を一段上げる｜多要素認証と接続元制限を事業者側で掛ける

事業者の管理サイトに多要素認証を必須化しパスワードだけで入れなくする

SC社が再発防止策の先頭に挙げたのは、多要素認証の導入などによる管理者認証の強化です。OWASPのMultifactor Authentication Cheat Sheetは、管理者など高い権限を持つアカウントで多要素認証を必須にするよう求めています。入手経路が流出でも推測でも、パスワード1つでは入れない状態にすれば、今回の起点そのものが成立しにくくなります。

SaaSでは、利用企業の担当者が使う画面と、事業者の社員が全社の環境をまたいで操作する管理サイトが別にあることが多いです。後者は1つのアカウントで全利用企業に届くため、利用企業向けの画面より先に、認証を強める順番にします。方式ごとの強さと実装は多要素認証（MFA）の3要素と実装方式で比べています。

管理サイトのURLを接続元IPで絞るnginxのallow・denyの書き方

事業者の社員しか使わない管理サイトは、インターネットの全体に開いておく理由がありません。nginxのaccessモジュールのallowとdenyで、社内やVPNの出口アドレスだけに絞れます。

# 管理サイト（例: /admin/）は許可した接続元だけに絞る（アドレスは文書用の例示範囲）
location ^~ /admin/ {
    allow 203.0.113.10;
    allow 198.51.100.0/24;
    deny  all;

    location ~ \.php$ {
        include       fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_pass  unix:/run/php/php-fpm.sock;
    }
}

ここで^~を外すと失敗します。location /admin/だけで書くと、/admin/login.phpのようなPHPの要求はサーバー直下の正規表現locationが受け持ち、allowとdenyが掛かりません。PHPの処理を内側に入れ子で書き直し、許可していない回線から403が返ることを確かめてから反映します。fastcgi_passのソケットの場所は環境に合わせてください。

利用企業ごとに環境を切り分ける｜DBロールからサーバー分離までの5段階

PostgreSQLで利用企業ごとに接続ロールを分けるREVOKEの書き方

PostgreSQLのドキュメントによると、データベースを作るとPUBLIC（全ロール）にCONNECTとTEMPORARYの権限が既定で付きます。社ごとにデータベースを分けても、この既定のままでは、ある社の接続ロールで別の社のデータベースへ接続できます。

-- 利用企業ごとにデータベースと接続ロールを1対1で作る（tenant_aの例）
CREATE ROLE app_tenant_a LOGIN PASSWORD '利用企業ごとに別の値';
CREATE DATABASE faq_tenant_a OWNER app_tenant_a;
REVOKE CONNECT, TEMPORARY ON DATABASE faq_tenant_a FROM PUBLIC;

-- 他社のロールから接続できないことを確かめる（false が返れば分離できている）
SELECT has_database_privilege('app_tenant_b', 'faq_tenant_a', 'CONNECT');

権限の付け外しの書式はGRANTのリファレンスにまとまっています。ただし前の章のとおり、各社のパスワードを1つのOSユーザーが全部読めるなら、この分離は不正プログラムには効きません。接続ロールの分離は、次に挙げる上の段とセットで初めて意味を持ちます。

分離の単位ごとに不正プログラムが届く範囲を比べた5段階の比較表

マルチテナントの分離は、どこで切るかで不正プログラムが届く範囲が変わります。下の段ほど費用が上がり、届く範囲は狭くなります。

今回の公表文から読み取れるのは、少なくともサーバーは共有だったという点までです。設計の考え方と比較の全体はシングルテナントとマルチテナントの違いとテナント分離の実装で整理しています。管理基盤そのものが破られた別の事例として、さくらインターネットの不正アクセスと管理基盤経由の侵害も参考になります。

自由記述の個人情報を預かるSaaSが共有サーバーをやめるべき条件

判断は言い切れます。利用企業の顧客が自由記述で書き込む問い合わせ本文を保存するSaaSで、利用企業に金融・保険・決済の事業者が含まれるなら、少なくともコンテナかVMの単位まで分けます。本文に口座番号やカード番号が書き込まれることは、今回の大和証券とシチズン時計の公表文が示したとおりです。1社の侵入が全社の通知と報告に広がる費用は、分離の費用を上回ります。

反対に、公開済みのFAQを表示するだけで顧客の入力を保存しない構成なら、共有サーバーと接続ロールの分離で足ります。守る対象が公開情報だけだからです。迷うのは中間の、メールアドレスと氏名だけを預かる構成でしょう。この場合はOSユーザーを社別にし、管理サイトの多要素認証と接続元制限を先に終えます。分離の状態は、利用企業から求められるSOC2の報告書や監査の証跡にもそのまま載ります。

利用企業への通知と報告の順番｜委託先としての法26条ただし書と速報期限

SaaS事業者が委託元へ通知すれば委員会報告を免れる個人情報保護法の規定

個人情報保護法26条1項は、漏えい等が起きたとき個人情報保護委員会への報告を義務付けています。ただし書は、個人データの取り扱いの委託を受けた事業者が、委託元にその事態を通知したときは、この報告義務を負わないと定めています。報告と本人への通知の主体は、原則として利用企業の側です。

SC社は利用企業へ同日中に報告したうえで、自らも委員会へ報告しています。個人情報保護委員会の案内では、速報は発覚日から3〜5日以内、確報は30日以内、不正の目的によるおそれがある場合は60日以内です。委託元の4社は10月5日から7日にかけて公表しており、事業者からの通知が早いほど、この期限に余裕が生まれます。報告書式の段取りは個人情報保護委員会への報告義務の実務で解説しています。

利用企業が自社の顧客へ説明できる情報を事業者が当日中にそろえる手順

今回、各社の公表文には同じ時間帯（20時33分頃〜8時1分頃）が書かれ、件数の数え方も「延べ」でそろっていました。事業者が利用企業に渡す情報の型が決まっていると、各社の公表がぶれません。当日中に渡すものは次の順です。

1. 不正アクセスの開始・遮断の時刻（分単位）
2. その利用企業の環境への読み出しの有無
3. 対象の件数と数え方（延べか人数か）
4. 対象の項目（利用企業が設定した入力欄ごと）
5. 実施済みの遮断と次の報告予定日

2番目を社別に言えるかどうかは、前述の利用企業別ログで決まります。4番目は、損保ジャパンのドライバーIDのように利用企業が独自に足した項目を事業者が把握していないと出せません。委託先を起点にした攻撃の型の全体はサプライチェーン攻撃とはで整理しています。管理サイトの認証、アップロード処理、利用企業ごとの分離が設計どおりに働いているかを第三者の目で確かめるなら、脆弱性診断・セキュリティ診断で管理画面とサーバー上の権限まで含めて点検できます。

よくある質問

スカラコミュニケーションズの不正アクセスについて、利用者とSaaSの開発者から出やすい質問をまとめました。

スカラコミュニケーションズの不正アクセスでどの企業が影響を受けましたか？

SC社は同一サーバー上の利用企業最大5社が対象としています。10月7日までに大和証券（約11万名・約22万件）、シチズン時計（約10万名）、損保ジャパン（延べ約6万件）、東武鉄道が公表しました。東武鉄道は、同社に関する情報の閲覧と取得の形跡は現時点で確認されていないとの報告を受けています。残る1社は10月9日時点で公表されていません。

i-askとはどのようなサービスですか？

SC社が提供するFAQシステムです。利用企業は、よくある質問の掲載と問い合わせの受け付けに使っていました。損保ジャパンはドライブレコーダー「SMILING ROAD」のよくある質問と問い合わせに、東武鉄道はお客さまセンターの問い合わせフォームに使っていたと公表しています。今回不正ログインされたのは、事業者側の管理サイトです。

延べ713,126件は何人分の情報ですか？

人数ではありません。問い合わせ単位の延べ件数で、同じ顧客が複数回問い合わせた分を重ねて数えています。SC社の説明では、実際の人数は現在名寄せ中です。利用企業側の公表でも、大和証券は約11万名で約22万件、損保ジャパンは延べ約6万件というように、人数と件数の扱いが社ごとに異なります。

自分の情報が含まれているか確かめる方法はありますか？

問い合わせをした企業の公表文に記載された専用窓口へ確認します。対象者には各社が個別に連絡するとしています。SC社や利用企業を装ったメールや電話が届いても、記載されたURLや電話番号は使わず、自分で開いた公式サイトから窓口をたどってください。SC社自身も特設窓口を設けています。

自社で提供するSaaSが同じ構造か確かめるには何を見ればよいですか？

3点を順に見ます。事業者側の管理サイトに多要素認証と接続元の制限が掛かっているか。アップロードしたファイルが公開ディレクトリで実行されないか。1つの環境で動いたプログラムから、他の利用企業のデータベースの接続情報が読めないか。3点目はOSユーザーやコンテナの単位で確かめる必要があり、データベースが社別というだけでは判断できません。

関連記事

• 大和証券の不正アクセスと約11万人分の口座番号：問い合わせ管理の委託先に残さない設計：同じ侵害を委託元の側から見て、口座番号を送る前に伏せる実装
• シチズン時計の不正アクセスと約10万人分の問い合わせ情報：自由記述欄にカード番号を残さない設計：本文に書かれたカード番号を保存前に止める実装
• SaaSセキュリティ対策の実装手順｜設定診断・OAuth棚卸し・ログ監視を解説：SaaSを使う側の設定とログの点検
• さくらインターネットの不正アクセスと最大136万件｜管理基盤経由の侵害と利用者の点検手順：事業者の管理基盤が破られた別の事例