情報漏洩対策は「兆候」を見張ることから——2026年11月の情報漏洩事件から考える、不正アクセス対策と、Zabbixで当社が監視していること

名古屋でAIシステムの開発をしている小嶋です。

11月に入って、情報漏洩の発表が続いています。今日だけでも、無印良品のクレジットカード番号、大阪市の行政オンラインシステムのメールアドレス108万件、大阪公立大学の学生と教職員の約17万人分と、大きな発表が重なりました。

当社でもまとめ記事を書きながら、自分たちのサーバーはどうなっているのかが気になりました。社内のサーバーは Zabbix という監視の仕組みで見ています。調べてみると、障害は見張れていても、不正アクセスやデータの持ち出しの兆候は、ほとんど見ていませんでした。

今日、その監視を足しました。事件から考えたことと、当社が実際にやったことをまとめます。

先にまとめます。

• 最近の事件の共通点：攻撃は数日にわたって続いていた。漏れたのは、委託先や、使い終わったのに残っていたデータからだった
• 気づくのが早ければ、被害は小さくできた：持ち出しが続いている間に気づければ、止められる量が増えます
• Zabbix でできること：ログイン失敗の急増、社外からのログイン成功、重要なファイルの書き換え、送信量の急増といった「兆候」を見張ること
• Zabbix でできないこと：通信の中身を調べて攻撃を見抜くこと、複数のサーバーのログを突き合わせること、データの持ち出しを中身で止めること
• 当社の見直し：4台のサーバーとも、標準の監視のまま。改ざんの監視は /etc/passwd の1つだけで、ログイン失敗は見ていませんでした。今日、4種類の監視を足しました
• 監視だけでなく、守りも固めた：インターネットに面しているサーバーで、止まっていた自動遮断（fail2ban）を動かし、ログインをパスワードから鍵だけに切り替えました

最近の情報漏洩事件に共通すること

詳しくは、それぞれのまとめ記事に書いています。

• 無印良品の不正アクセス・情報漏洩——MUJI Cardのクレジットカード番号16桁は、なぜ5年間も残っていたのか
• 大阪市 行政オンラインシステムのメールアドレス流出108万件——原因はメール配信サービス「アララ メッセージ」への不正アクセス

3つの事件に共通することは、大きく3つあります。

1. 攻撃は数日にわたって続いていた

アララ メッセージでは、公開されている経緯によると、データの持ち出しは10月28日から31日まで、サービスを止めるまで続いていました。大阪公立大学でも、攻撃の入口になった委託先の端末への侵入は9月下旬で、大学のシステムが止まったのは10月に入ってからです。

攻撃を受けた瞬間に防ぐのは難しくても、続いている間に気づければ、被害を小さくできます。

2. 委託先や、その先から漏れていた

大阪市は、自分のシステムは破られていません。大阪公立大学も、入口は運営委託先のさらに再委託先でした。自分のシステムだけを守っていても、情報は漏れます。

3. 使い終わったデータが残っていた

無印良品のカード番号も、大阪公立大学のパスポートの画像などの多くも、使い終わったあとに消されずに残っていたものでした。持っていないデータは漏れようがありません。

当社のサーバーの監視を見直した

当社では、社内の4台のサーバー（AIの推論や画像生成、社内システムを動かしているもの）を、オープンソースの監視の仕組み Zabbix で見ています。障害が起きると、ローカルのAI（gemma4）が原因を調べてレポートを書き、メールで知らせる仕組みにしています。

今日、監視の項目を全部書き出してみました。

• 4台とも、Linux の標準のテンプレートのままでした
• 改ざんの監視は、ユーザーの一覧のファイル（/etc/passwd）の1つだけ
• SSH のログイン失敗は、どのサーバーでも見ていませんでした
• 送信量の監視は、回線の速さの90%を超えたら知らせるものだけ。普段と比べて急に増えた、という見方はしていませんでした

調べている途中で、インターネットに面している1台では、6日間で約2万件のログインの失敗（存在しないユーザー名や、誤った認証）が記録されていることも分かりました。いずれも失敗で、この方法でログインに成功したものはありませんでした。ただ、これだけの試みが毎日来ていることに、監視は何も言っていませんでした。

今日足した監視

いくつか工夫したところがあります。

• ログは監視の仕組みに直接読ませない：ログイン記録（auth.log）や公開鍵のファイルは、Zabbix のエージェントからは読めない権限になっています。権限を広げる代わりに、もともと1分ごとに動いている証拠集めのプログラムに数えさせ、数と結果だけを Zabbix に渡すようにしました。鍵やログの中身そのものは外に出しません
• サーバーごとにしきい値を変える：インターネットに面している1台は、ふだんから5分に数十件の失敗があります。ほかの3台と同じしきい値にすると、知らせが鳴りっぱなしになります。それでは誰も見なくなるので、普段の量から決めました
• 監視が止まったことも知らせる：証拠集めのプログラムが止まると、不正アクセスの監視も止まります。10分間更新がなければ知らせるようにしました

足した監視は、知らせが鳴ると、障害のときと同じように AI が前後の記録を集めて調べ、メールで届きます。

Zabbix でできないこと

Zabbix は、障害の監視の仕組みです。今日足したのは「兆候」を見張ることで、次のことはできません。

• 通信の中身を調べて、攻撃を見抜くこと：侵入検知（IDS）の役割で、Suricata などのオープンソースがあります
• 複数のサーバーのログを突き合わせて、攻撃の流れを見つけること：SIEM の役割で、Wazuh などのオープンソースがあります。Wazuh は Zabbix と組み合わせて使われることも多いです
• 個人情報を含むデータの持ち出しを、中身で止めること：DLP（情報漏洩防止）の役割です
• 攻撃してくる相手を自動で遮断すること：fail2ban や CrowdSec などの役割です

当社では、次にこれらを組み合わせることを検討しています。

追記：監視を足したあと、守りも固めた

監視を足すために中を見ていく途中で、インターネットに面している1台について、次のことが分かりました。

• パスワードでのログインが有効なままだった：担当者が、ターミナルのソフト（Tera Term）からパスワードでログインしていたためです。約2万件の試みは、このパスワードを当てようとするものでした
• 自動遮断の仕組み（fail2ban）は、入っているのに止まっていた：入れただけで、一度も動いていませんでした

監視は「気づく」ための仕組みで、攻撃そのものは止めません。そこで、同じ日のうちに次の3つを行いました。

1. 自動遮断を動かした（fail2ban）

社内のネットワークは遮断の対象から外しています。外さないと、社内の作業で入力を間違えただけで、自分たちが締め出されることがあるためです。動かした直後から、総当たりをしていた相手の遮断が始まりました。

注意したのは、fail2ban の標準の設定は、SSH の標準の番号の入口しか見張らないことです。入口の番号を変えているサーバーでは、その番号を設定しないと、遮断したつもりで何も止まっていない、ということが起きます。

2. ログインを「鍵」に切り替えた

パスワードは、総当たりで当てられるおそれがあります。鍵での認証は、手元のパソコンにある秘密鍵を持っていないと入れません。

Tera Term での手順は、次のとおりです。

1. メニューの「設定」→「SSH鍵生成」で、種類に「ED25519」を選んで鍵を作り、公開鍵と秘密鍵を保存する（秘密鍵には、使うときのパスフレーズを付ける）
2. いつもどおりパスワードでログインし、公開鍵をサーバーの ~/.ssh/authorized_keys に登録する
3. いまの接続を切らずに、新しく接続し直す。ログインの画面（SSH認証）の「認証方式」で「RSA/DSA/ECDSA/ED25519鍵を使う」を選び、秘密鍵のファイルとパスフレーズを入れる
4. 鍵で入れたことを確かめてから、サーバーのパスワードでのログインを止める

順番が大切です。鍵で入れることを確かめる前にパスワードを止めると、自分が入れなくなります。 当社でも、担当者がパスワードで入っていることを、止める直前に知りました。

3. 止めたことを、外から確かめた

設定を変えたあと、鍵での接続がつながること、パスワードでの接続が拒否されることを、それぞれ実際に試して確かめました。担当者が鍵を登録したときには、今日足した監視が「鍵の一覧（authorized_keys）が変わった」と知らせを出し、社外からのログインも記録しました。もし覚えのない鍵が足されたら、同じように知らせが届きます。

いまの守りは、鍵がなければ入れない、何度も試す相手は自動で遮断する、それでも起きた変化は監視が知らせる、の3段です。

会社として、まず確かめたいこと

大きな仕組みを入れる前に、どの会社でもすぐに確かめられることがあります。

• サーバーの監視が、障害だけになっていないか：ログイン失敗、社外からのログイン、送信量の急増を見ているか
• 委託先や、使っている外部のサービスを一覧にしているか：メール配信、決済、問い合わせフォームなど。その先で何が使われているかまで
• 使い終わったデータを消しているか：移行のときに作ったコピー、終わった連携のデータ、解約した人のデータ
• Webサイトの、外から見える守りを点検しているか：古いソフトのままになっていないか、設定に穴がないか

Webサイトについては、URLを入れるだけで、外部から確認できる守りを点検できるシステムを開発しています。

• Webサイトの脆弱性診断を、URLを入れるだけで（Kurage Security Check）
• PHPの脆弱性でWebサイトに不正アクセスされても、社内の情報漏えいは起きないのか

調べ方

• 事件の経緯は、各社の発表を伝えた報道と、セキュリティの研究者がまとめている公開情報（piyolog）によります
• 当社の監視の見直しは、Zabbix 7.0 の API で、4台のサーバーの監視項目とトリガーを書き出して確かめました
• 当社のサーバーの構成や、どのサーバーがインターネットに面しているかなど、守りに関わる細かいことは書いていません

よくある質問

情報漏洩対策として、まず何をすればよいですか？

使い終わったデータを消すこと、委託先や外部のサービスを一覧にすること、サーバーで不正アクセスの兆候を見張ることです。最近の事件では、漏れたのは使い終わったのに残っていたデータや、委託先のシステムからでした。

不正アクセスに早く気づくには、何を監視すればよいですか？

ログインの失敗の急増、社内のネットワーク以外からのログイン成功、重要なファイルの書き換え、送信量の急増です。攻撃は数日にわたって続くことが多く、その間に気づければ被害を小さくできます。

Zabbix で不正アクセスを監視できますか？

兆候を見張ることはできます。ログの監視、ファイルのハッシュの監視、送信量の監視を組み合わせれば、ログイン失敗の急増、社外からのログイン、改ざん、データの持ち出しの兆候に気づけます。通信の中身を調べて攻撃を見抜くことはできないので、侵入検知や SIEM の仕組みと組み合わせます。

Zabbix と Wazuh は何が違いますか？

Zabbix はサーバーやネットワークの障害の監視の仕組みで、Wazuh はセキュリティの監視（ログの突き合わせ、改ざんの検知、脆弱性の検出）の仕組みです。どちらもオープンソースで、組み合わせて使うこともできます。

委託先から情報が漏れないようにするには、どうすればよいですか？

委託先とその先で使われているサービスを一覧にし、渡すデータを必要なものだけにすることです。メールを送るだけのサービスに、氏名や住所まで渡す必要はありません。委託先のアカウントの権限も、作業に必要な範囲に絞ります。