厚生労働省の院内感染対策サーベイランス（JANIS）で使われている「薬剤耐性菌発生動向調査システム」が、第三者のサイバー攻撃を受けました。Webサーバー上に情報を抜き取るプログラムを置かれ、実行された可能性があります。漏えいのおそれがあるのは最大11,652名分の医療機関の責任者・担当者の情報と、病院名や登録された耐性菌情報です。前半は2026年11月6日の公表で分かる経緯と項目、医療機関に届くメールを確かめるPythonの例です。後半は、Webサーバーに置かれたプログラムの実行と外向きの通信を捉えるauditdとnftablesの設定を載せます。
まとめ：JANISの不正アクセスで分かっていることと、医療機関・運営側が今やること
厚生労働省の薬剤耐性（AMR）対策のページによると、システムの運営を委託している国立健康危機管理研究機構（JIHS）から10月27日に報告があり、同じ日からシステムを止めています。
| 項目 | 公表文の記載（11月6日時点） |
|---|---|
| 報告 | 10月27日・運営委託先のJIHSから |
| 手口 | Webサーバー上に情報を抜き取るプログラム |
| 人数 | 最大11,652名分の利用者情報 |
| 病院の情報 | 病院名・病床数・住所・耐性菌情報など |
| システム | 10月27日から停止中・再開時期は未定 |
| 二次被害 | 悪用や二次被害は確認されていない |
JANISに参加する医療機関の担当者がやることは1つです。厚生労働省やJIHS、JANISを名乗るメールは、送信元と認証結果を確かめるまで添付もリンクも開かない。同じ形の委託システムを運営する側は、Webサーバーの実行ユーザーが何を起動し、どこへ通信しているかを記録できているかを今週中に確かめてください。
公表文で分かる範囲：10月27日のJIHSからの報告と11月6日の公表まで
委託先のJIHSからの異常報告と10月27日からのシステム停止
発端は、運営を委託されているJIHSからの報告でした。システムが第三者のサイバー攻撃を受け、Webサーバー上に情報を抜き取るプログラムが配置され、そのプログラムが実行された可能性がある、という内容です。厚生労働省は10月27日にこの報告を受け、被害の拡大を防ぐためにその日からシステムを止めました。
同じ10月27日には、JANISのサイトに「システムの安全性を確保するため、当面の間停止」というお知らせが出ています。この時点では理由は書かれていませんでした。漏えいの可能性が公表されたのは11月6日で、停止から10日後です。再開時期は「決まり次第お知らせ」とされたままです。
院内感染対策サーベイランスとシステムの関係、参加医療機関のデータ
公表文の注記によると、このシステムは院内感染対策サーベイランス事業のために、全国の参加医療機関から院内感染の発生状況や薬剤耐性菌の検出状況のデータを集め、集計結果を公表する情報システムです。各医療機関はここで自院のデータを登録し、院内感染対策の参考になる集計を受け取ってきました。
つまり利用者は一般の患者ではなく、医療機関で感染対策を担う医師・看護師・臨床検査技師などの担当者です。停止が続く間、参加医療機関はデータの登録も集計の受け取りもできません。
漏えいのおそれがある情報：最大11,652名の担当者情報と病院・耐性菌情報
責任者・担当者の氏名・職名・連絡先と、病院名・病床数・耐性菌情報
公表文が挙げる情報は次の2つです。2つ目が「など」で終わっているので、これで全部とは限りません。
- 最大11,652名分の利用者情報。システムに登録された医療機関の責任者・担当者の氏名・職名、電話番号、メールアドレス
- システムに登録された病院名、病床数、病院の郵便番号・住所、登録された耐性菌情報など
患者の氏名や生年月日は、項目に挙がっていません。目立つのは組み合わせです。担当者の氏名・職名・メールアドレスと、勤務先の病院名・住所・病床数がそろうと、「誰が、どの病院の感染対策を担っているか」が分かります。そこに耐性菌の登録状況が加われば、その病院の実情に触れた、もっともらしい文面を作れてしまう状況です。厚生労働省は、漏えいの可能性がある人へ個別に連絡するとしています。
厚労省・JIHSを名乗るメールの送信元を、受信サーバーの認証結果で確かめる
公表文は、不審なメールの添付を開かず、URLを押さず、メールごと削除するよう求めています。迷ったときの手がかりが、受信側のメールサーバーが付けるAuthentication-Resultsヘッダーです。RFC 8601は、このヘッダーの先頭に結果を付けたサーバーの識別子（authserv-id）を書くと定めています。自院のサーバーの識別子が付いた行だけを読めば、送信側が自分で書き込んだ「pass」にはだまされません。次のコードは、Pythonのemail.parserでメールを読み、Fromのドメインとdmarcの結果を判定します。
# 届いたメールの送信元ドメインと、自組織のメールサーバーが付けた認証結果を確かめる
# Python 3.10以上・標準ライブラリのみ
import re
import sys
from email import policy
from email.parser import BytesParser
from pathlib import Path
TRUSTED = {"mhlw.go.jp", "jihs.go.jp"} # 公式サイトで確かめた送信元ドメインだけを入れる
AUTHSERV = "mx.hospital.example" # 自組織の受信サーバーが名乗る識別子
def from_domain(msg) -> str:
header = msg["From"]
addrs = header.addresses if header else ()
return addrs[0].domain.lower() if addrs else ""
def auth_results(msg) -> dict:
found = {}
for value in msg.get_all("Authentication-Results", []):
text = str(value)
authserv = text.split(";", 1)[0].split()[0].lower()
if authserv != AUTHSERV:
continue # 途中や送信側で付いたヘッダーは数えない
for method in ("spf", "dkim", "dmarc"):
m = re.search(rf"\b{method}=(\w+)", text)
if m:
found[method] = m.group(1).lower()
return found
def judge(path: Path) -> str:
with path.open("rb") as f:
msg = BytesParser(policy=policy.default).parse(f)
dom = from_domain(msg)
res = auth_results(msg)
if not any(dom == d or dom.endswith("." + d) for d in TRUSTED):
return f"要注意 From={dom} は許可リスト外"
if res.get("dmarc") != "pass":
return f"要注意 From={dom} dmarc={res.get('dmarc', 'なし')}"
return f"確認可 From={dom} spf={res.get('spf')} dkim={res.get('dkim')} dmarc=pass"
if __name__ == "__main__":
for p in sys.argv[1:]:
print(Path(p).name.ljust(16), judge(Path(p)))
Python 3.14.10で、標準ライブラリで作った無害な模擬メール4通に対して2026年11月11日に実行した結果です（リンク・添付なし）。
$ python check_sender.py in/official.eml in/lookalike.eml in/spoofed.eml in/selfstamp.eml
official.eml 確認可 From=mhlw.go.jp spf=pass dkim=pass dmarc=pass
lookalike.eml 要注意 From=mhlw-go.jp.example は許可リスト外
spoofed.eml 要注意 From=mhlw.go.jp dmarc=fail
selfstamp.eml 要注意 From=mhlw.go.jp dmarc=なし
lookalike.emlは表示名を「厚生労働省」にして、似せたドメインから送ったものです。selfstamp.emlは、送信側の中継サーバーが自分で「dmarc=pass」と書き込んだ行しか持たないため、なしと判定されます。許可リストのドメインは例なので、実際に連絡に使われるドメインは公式サイトの記載で確かめてから入れてください。「確認可」は送信元の偽装がないことを示すだけで、本文の依頼が正当かは別の話です。添付やリンクを開く前に、公式サイトの問い合わせ先へ自分から確かめる手順は変わりません。標的型の文面の典型は標的型攻撃メールの見分け方にまとめています。
情報を抜き取るプログラムの手口：Webサーバー上で動き外へ出す流れ
Webサーバーに置かれたプログラムがデータベースの情報を外へ出す流れ
Webサーバー上に置かれ、外から操作されて動くプログラムは、一般にWebシェルと呼ばれます。どこから置かれたのかは、今回の公表文には書かれていません。置かれた後の動きは、どの事案でもおおむね似ています。サイトのプログラムと同じ権限で動き、設定ファイルからデータベースの接続情報を読み、テーブルの中身を取り出して外へ送ります。仕組みと検知・除去のコマンドはWebシェルの仕組みと検知・除去の手順で扱いました。
持ち出しの経路は2つに分かれます。攻撃者のHTTPリクエストへの応答にデータを載せて返す型と、サーバーの側から外部へ接続して送り出す型です。前者はアクセスログの応答サイズに、後者はサーバーからの外向き通信に痕跡が残ります。
改ざん検知だけでは見えない「実行」と「外向き通信」の調査記録
ファイルが置かれたこと自体は、公開ディレクトリのハッシュ値を定期的に比べれば分かります。その実装は日商簿記ネット試験の事案で載せたSHA-256の差分検知にあります。ただ、差分検知が見るのは「置かれたか」までです。置かれたものが何を起動し、どこへ通信したかは分かりません。
本件の公表文も「実行された可能性」と書いています。実行の有無を後から言い切るには、Webサーバーの実行ユーザーが起動したプロセスと、そのユーザーが張った外向きの接続の記録が必要です。この2つを残していないと、調査は「可能性」のまま長引きます。
Webサーバーの実行ユーザーを見張る：auditdとnftablesの設定例
実行ユーザーwww-dataが起動したコマンドをauditdで記録するルール
auditctlのルールで、Webサーバーの実行ユーザーがexecveを呼んだときに記録を残します。-F uidには数値のほかアカウント名も指定可能です。マニュアルは32ビットと64ビットの両方の呼び出しを拾うため、archを分けて2本書くよう勧めています。
# /etc/audit/rules.d/50-web-exec.rules
# Webサーバーの実行ユーザーがプログラムを起動したら記録する
-a always,exit -F arch=b64 -S execve -F uid=www-data -k web_exec
-a always,exit -F arch=b32 -S execve -F uid=www-data -k web_exec
# 読み込みと確認（rootで実行）
# auditctl -R /etc/audit/rules.d/50-web-exec.rules
# auditctl -l -k web_exec
# 今日の記録をユーザー名つきで見る
# ausearch -k web_exec -i -ts today
-Rで読むファイルは、rootが所有し他のユーザーが読めない状態でないと拒否されます。検索はausearchの-kでキーを指定し、-iでUIDを名前に直す指定です。PHPのmail()がsendmailを起動するといった正規の呼び出しは、最初の数日の記録で洗い出して除外します。それ以外にcurlやpython、idが出たら、まず置かれたファイルを疑う合図です。
限界もあります。置かれたプログラムがPHPのファイルのままPHP-FPMの中で動くだけなら、execveは呼ばれず、このルールには出ません。この設定はWindowsの手元環境では起動確認しておらず、公式マニュアルの仕様に沿って書いたものです。検証環境でwww-dataからidを起動し、記録が出ることを確かめてから本番へ入れてください。
nftablesで実行ユーザーからの外向き通信を許可先だけに絞る設定
execveに出ない持ち出しは、出口で止める方針です。nftablesのmeta skuidは、パケットを出したソケットのUIDで一致を取ります。nftablesのWikiの例はoutputチェーンに書かれています。Webサーバーの実行ユーザーが本来つなぐ先は、データベースと名前解決くらいのはずです。
# /etc/nftables.d/web-egress.nft
# www-data が外へ張る接続を、DBと名前解決だけに絞る
table inet web_egress {
chain output {
type filter hook output priority 0; policy accept;
meta skuid "www-data" ip daddr 192.0.2.10 tcp dport 5432 accept
meta skuid "www-data" ip daddr 192.0.2.53 udp dport 53 accept
meta skuid "www-data" counter log prefix "web-egress-deny " drop
}
}
アドレスは例示用の範囲です。最後の行は、最初はdropを外してcounterとlogだけで1〜2週間動かし、正規の通信先（外部APIやメール送信）を洗い出してから止めるほうが安全です。この設定も手元では起動確認していないので、nft -c -fで構文を確かめ、検証環境でwww-dataから外部への接続が拒否されることを見てください。応答に載せて持ち出す型はここでは止まらないため、アクセスログで同じURLへの大きな応答が続いていないかも併せて見ます。
委託先が運営する医療・公的システムで、発注側が確かめる監視範囲
安全管理ガイドライン第7.0版と、委託先から報告を受けるまでの時間
本件は、システムの所管が厚生労働省、運営がJIHSという委託の形でした。厚生労働省へ報告を上げたのは、運営を担う委託先の側でした。医療機関や団体が自前のシステムを外部に任せる場合も構図は同じで、委託先の監視が弱ければ発注側は気付けません。医療機関向けには医療情報システムの安全管理に関するガイドライン第7.0版（令和8年6月）が出ており、編ごとの担当の分け方は第7.0版の読み方で整理しています。
契約で先に決めておくのは、次の3点です。重い順に並べています。
- Webサーバーの実行ユーザーの起動記録と外向き通信の記録を残しているか。何日分か
- 不審な動きを見つけてから、何時間以内に誰へ連絡するか
- 連絡を受けた発注側が、システムを止める判断をどの権限で下せるか
委託先の監督の進め方は委託先管理の実務に、民間の事業者が同種の事案を起こしたときの報告の流れは個人情報保護委員会への報告義務の実務にまとめています。
判断：参加機関からデータを集めるシステムで外部診断に出す条件
外部の参加機関がログインしてデータを登録するシステムは、担当者の連絡先が一か所にまとまります。漏れれば、今回のように全国の担当者へ届く偽のメールの材料になります。参加機関の担当者情報とデータ登録の画面を、同じWebサーバーと同じ実行ユーザーで動かしているなら、起動記録と外向き通信の制限が無い状態のまま運用を続けないと決めてかまいません。
逆に、集計結果を公開するだけの静的なページで、利用者の登録情報を持たないなら、ここまでの設定は過剰です。登録画面とデータベースを持つ場合は、ファイルアップロード、設定ファイルの置き場所、データベース接続の権限、実行ユーザーの出口をまとめて第三者に見てもらうのが近道です。ログイン画面やAPIの入口の固め方はAPI不正アクセス対策の実装手順を参照してください。委託先任せのシステムを外から確かめたい場合は、一創の脆弱性診断・セキュリティ診断で、こうした構成を含めた診断を受け付けています。
よくある質問
JANISの不正アクセスについて、参加医療機関の担当者と運営側から出やすい質問に、11月6日の公表文の範囲で答えます。
JANISに参加しています。自分の情報は対象ですか？
漏えいの可能性があるのは、システムに登録された医療機関の責任者・担当者の氏名・職名、電話番号、メールアドレスで、最大11,652名分です。厚生労働省は、漏えいの可能性がある人へ個別に連絡するとしています。個別の連絡が届いたら、本文の依頼に応じる前に、厚生労働省の薬剤耐性（AMR）対策のページの記載と照らし合わせてください。
JANISはいつ再開しますか？
2026年11月11日時点で、再開時期は公表されていません。JANISのサイトと厚生労働省のページは、10月27日から当面の間停止しているとし、再開は決まり次第知らせるとしています。原因と漏えいした可能性がある情報の調査を進め、その結果を踏まえて再発防止策を講じるとしているため、再開はその後になると読めます。
患者の個人情報は漏れていませんか？
公表文が挙げる項目に、患者の氏名や生年月日はありません。対象は医療機関の担当者の情報と、病院名・病床数・住所・登録された耐性菌情報などです。ただし項目の最後が「など」で終わっており、調査も続いています。続報で項目が変わる可能性はあります。
厚生労働省を名乗るメールが届きました。どう確かめればよいですか？
公表文は、不審なメールの添付を開かず、本文のURLを押さず、メールごと削除するよう求めています。判断に迷う場合は、メールのヘッダーにある自院の受信サーバーの認証結果で、送信元ドメインとdmarcの結果を見ます。それでも依頼が正当かは分からないので、公式サイトに載っている連絡先へ自分から確かめてください。
同じような委託システムを運営しています。まず何を見ればよいですか？
Webサーバーの実行ユーザーが何を起動し、どこへ通信しているかを、今の設定で後から追えるかを確かめます。起動の記録はauditdのexecveのルール、外向き通信はnftablesのmeta skuidで残せます。公開ディレクトリにファイルが増えていないかの差分検知と、委託先から異常の連絡を受けるまでの時間の取り決めも、同じ週に見直してください。
関連記事
- Webシェルとは？仕組み・代表例と検知・除去の手順をTomcat・PHP・IISのコマンド例で解説：Webサーバーに置かれたプログラムを見つけて取り除く手順
- 日商簿記ネット試験の情報漏洩：最大約98万人の対象確認と不審連絡への備え、改ざん検知の実装：置かれたファイルを差分で見つける実装
- 医療情報システムの安全管理に関するガイドライン第7.0版の読み方｜5編の担当と規程・技術対策の対応表：医療機関がシステムを任せるときの基準
- API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効とアプリ解析・SSRF対策：参加機関が使う入口を固める実装
- 個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務：漏えいのおそれがあるときの報告の流れ
