セキュリティ

エンタッチ不正アクセス:医療従事者と面談予約の情報が漏洩、対象範囲と窓口

エンタッチ不正アクセス:医療従事者と面談予約の情報が漏洩、対象範囲と窓口

東邦ホールディングスの非連結子会社で、製薬企業に代わって医療従事者へリモートで情報を届ける事業を行うエンタッチ株式会社は、管理するデータベースが不正アクセスを受け、医療従事者の氏名や所属医療機関、面談の予約情報などが外部に流出したと2026年10月19日に公表しました。原因はランサムウェア攻撃を行う第三者による不正アクセスとされ、件数と範囲は調査中です。本記事の前半は、自分は対象か、何が漏れたのか、どこに問い合わせるか、届いた連絡は本物かという医療従事者とMRの疑問への、公式発表に沿った回答です。後半では、データの改ざんや消去が確認されていないという経過から、開発・運用の担当者がデータベースへの接続元を絞り、外部への持ち出しを検知する手順をコードで示します。

まとめ:エンタッチ不正アクセスで公表された事実と医療従事者・製薬企業の対応

公表されているのは、10月9日に不正アクセスが発生し、13日16時頃にデータの外部漏洩が発覚したという経過です。漏洩が確認されたのは、リモートディテーリングを受けた医療従事者の氏名・所属医療機関・都道府県、プラットフォームを使う管理者や担当者の氏名とメールアドレス、予約時の連絡先、製品名、面談の日時と状況です。説明資料のファイル本体や録画・音声は対象外でした。

医療従事者とMRがまずやることは、エンタッチ・東邦グループ・製薬企業を名乗る心当たりのない連絡のリンクや添付ファイルを開かないことです。問い合わせ先はメールアドレスだけが公表されています。開発者が受け取る教訓は、暗号化されずに盗まれる被害では業務が止まらないため、外へ出ていくデータの量を見ていなければ気づく機会がないという点です。

項目 公表されている内容(2026年10月23日時点)
発生日 10月9日(エンタッチの第一報)
発覚 10月13日16時頃
公表 10月19日(東邦HD・東邦薬品・エンタッチ)
原因 ランサムウェア攻撃を行う第三者の不正アクセス
件数と範囲 調査中
改ざんと消去 確認されていない
問い合わせ先 [email protected]
未公表 侵入経路・使われた脆弱性・攻撃者の名称

問い合わせ先の記載はメールアドレスのみで、電話番号の記載はありません。

医療従事者とMRが最初に確かめること:対象の範囲・漏洩した項目・問い合わせ先

リモートディテーリングを受けた医療従事者とプラットフォーム利用者の2つの対象

エンタッチは、医療機関向けにオンラインで製品情報を届けるリモートディテーリングの予約管理と実施を担う会社です。東邦ホールディングスの10月19日の開示によると、この事業は東邦薬品からの受託で行う場合と、エンタッチが製薬企業から直接受託する場合があります。

対象になり得る人は2つの立場に分かれます。1つは、このサービスで面談の予約を受けた医師や薬剤師などの医療従事者です。もう1つは、プラットフォームにログインして予約を管理する製薬企業側の管理者や、面談を行うMR(開示では「eMR等」)です。面談を受けた記憶があるかどうかが目安になりますが、予約が「キャンセル」の状態でも記録は残るため、実施しなかった面談も対象に含まれ得ます。

漏洩が確認された7種類の項目と、コンテンツ本体・録画が対象外とされた理由

エンタッチの第一報が挙げた項目は次のとおりです。

  • 医療従事者の氏名、所属医療機関、医療機関の所在都道府県
  • プラットフォームにアクセスする管理者とディテーリング担当者の氏名、メールアドレス
  • 予約時に連絡先として入力した電話番号とメールアドレス
  • 予約対象となった製品名とコンテンツ名
  • 予約作成日時
  • 面談日時
  • 面談のステータス(予約中、キャンセル、実施済み)

東邦HDの開示は「製品名・製薬企業名」と書いており、どの製薬企業のどの製品について、どの医師がいつ面談したかという組み合わせが外に出たことになります。説明に使うコンテンツファイルや録画・音声データは、そもそも当該データベースに置かれていなかったため対象外です。データの置き場所を分けていたことが、漏洩の範囲を限りました。

問い合わせ先[email protected]と、電話窓口が公表されていない点

本件の問い合わせ先として公表されているのは、エンタッチの第一報の末尾にあるメールアドレス [email protected] だけです。東邦HDの開示に載っている電話番号は、適時開示の問い合わせ先(経営戦略本部)であり、利用者の相談窓口として案内されたものではありません。

この点は、なりすましの見分けに直結します。「エンタッチ相談窓口」を名乗る電話番号がメールやSMSに書かれていても、10月23日時点で公表された電話窓口は存在しません。対象かどうか、自分の情報が含まれるかを確かめたいときは、エンタッチの公式サイトのニュース欄を自分で開き、そこに載ったアドレスへ送ります。

製薬企業・東邦グループを装う連絡への備え:メール・電話・SMSの見分け方

面談予約の具体的な文脈を知る相手からの連絡が本物らしく見える仕組み

今回漏れた項目には、氏名と連絡先に加えて「どの製品の面談を、いつ予約したか」が含まれます。攻撃者がこれを使えば、「先日ご予約いただいた○○(製品名)の面談について、日程変更のお願いです」という、受け取った医師にとって心当たりのある文面を作れます。一般的なフィッシングと違い、文面の具体性だけでは本物と区別できません。

エンタッチは第一報で、同社、東邦グループ各社、製薬企業などを装った不審なメール、電話、SMSが届く可能性があるとし、心当たりのない連絡に書かれたリンクや添付ファイルを開かず、個人情報やパスワードを入力しないよう求めています。手口と技術的な見分け方の考え方はフィッシング詐欺の仕組みと技術的対策で解説しています。

MR・管理者のパスワードは変更済みでも、別サービスの使い回しは自分で直す

エンタッチは発覚後、プラットフォームの全パスワードを強制的に変更しました。再設定の方法は公表されていないため、プラットフォームへの再ログインの手順は、自社の管理者かエンタッチに確かめます。注意が要るのは、同じパスワードを社内のメールや他の業務サービスで使い回していた場合です。開示はパスワードの漏洩を項目に挙げていませんが、強制変更をした以上、使い回しのあるサービスは自分で変更しておくのが安全です。

製薬企業の担当部門は、自社のMRや管理者のメールアドレスが漏れた前提で、エンタッチや東邦グループを名乗る添付ファイル付きメールへの注意を社内に周知します。医療機関側から「予約変更の連絡が来たが本物か」と問い合わせを受けたときに答える窓口を、社内で1つ決めておくと混乱が減ります。

公式発表で追う経過:10月9日の発生から13日の発覚、19日の公表まで

公式発表で確認する発生から発覚まで4日、発覚から公表まで6日の時系列

  1. 10月9日:不正アクセスが発生(エンタッチの第一報のみに記載)
  2. 10月13日16時頃:データベースからリモートディテーリング事業のデータが外部に漏洩していることが発覚
  3. 発覚後:データベースにアクセスするソフトウェアへのセキュリティパッチ適用、アクセスログの保全、全パスワードの強制変更、警視庁サイバー犯罪対策課への相談
  4. 10月19日:東邦HDが適時開示、東邦薬品もニュースリリースを掲載。エンタッチは同日付の第一報を20日に自社サイトへ掲載

発覚の経緯(攻撃者からの連絡か、外部からの通報か、自社の監視か)は公表されていません。外部のフォレンジック調査会社が原因究明と影響範囲の特定を進めており、判明しだい続報を出すとしています。フォレンジック調査の流れと期間の目安はフォレンジック調査の流れ・費用と依頼先の選び方で整理しています。

東邦HD・東邦薬品・エンタッチの3つの発表で書き方が異なる箇所

3社の発表は大筋で一致しますが、細部の書き方が違います。照らし合わせると、読み違えやすい箇所がわかります。

箇所 東邦HD・東邦薬品 エンタッチ
原因の主体 ランサムウェア攻撃を行う第三者 攻撃グループを名乗る第三者
発生日 記載なし 10月9日
利用者の呼び方 管理者、eMR等 管理者、ディテーリング担当者
予約対象 製品名・製薬企業名 製品名、コンテンツ名
委員会への報告 東邦薬品の委託分は東邦薬品が報告 報告済み

エンタッチが「名乗る」と書いているのは、攻撃者の名乗りを同社がまだ裏付けていない段階だからだと読めます。攻撃者の名称は3社とも公表していません。本記事も、報道やリークサイトの情報で名称を補うことはしません。

暗号化せずに盗む手口への備え:データベースの管理ソフト更新と接続元の制限

改ざん・消去が確認されず業務も止まらなかった被害が示す窃取型の特徴

ランサムウェアというとファイルが暗号化されて業務が止まる被害を思い浮かべますが、今回は東邦HDの開示で、データの改ざんや消去は確認されず、エンタッチの事業継続にも支障は生じていないとされています。警察庁のランサムウェア被害防止対策のページは、データを暗号化せずに窃取して対価を要求する「ノーウェアランサム」という手口と、窃取したデータの公開を材料に対価を求める二重恐喝を挙げています。今回がどの手口にあたるかは公表されていません。

開発者にとっての要点は1つです。業務が止まる被害なら誰でもすぐ気づきますが、盗むだけの侵入は画面上に何の変化も残しません。気づく手段は、データベースに誰が接続したかの記録と、外へ出ていった通信量の記録だけになります。感染が見つかった後の隔離と報告の手順はランサムウェアの初動対応:隔離・証拠保全・報告の手順にまとめています。

データベースにアクセスするソフトウェアへのパッチ適用が最初の対策だった意味

エンタッチが発覚後に最初に挙げた対策は、データベースにアクセスするために使っているソフトウェアへのセキュリティパッチの適用でした。製品名やバージョンは公表されていないため、侵入経路がそのソフトウェアだったと断定はできません。ただ、警察庁のページも、インターネットに露出した機器やソフトウェアの未修正の脆弱性を、主な侵入経路の1つとして挙げています。

Webブラウザから操作するデータベース管理ツールや、データベースに接続する中継ソフトは、運用の便利さからインターネット側に公開されたまま更新が止まりがちです。社内の構成表に「データベースへ接続できるソフトウェア」の一覧があるか、それぞれの更新日がいつかを確かめるだけで、放置された入口が見つかります。APIを経由した不正取得への対策はAPI不正アクセス対策の実装手順で扱っています。

pg_hba.confでデータベースに接続できる送信元とユーザーを絞る設定例

管理ソフトの更新と並んで効くのが、データベースそのものに「どこから、どのユーザーで」接続できるかを絞る設定です。PostgreSQLではpg_hba.confの公式ドキュメントのとおり、ファイルの上から順に照合され、接続の種類・送信元・データベース・ユーザーが最初に一致した行の方式で認証されます。一致した行で拒否されても、下の行に進むことはありません。

# pg_hba.conf:上から順に照合され、最初に一致した行で認証方式が決まる(後ろの行には進まない)
# TYPE   DATABASE   USER        ADDRESS          METHOD
# アプリサーバのサブネットからは、アプリ用ユーザーだけをTLS必須で通す
hostssl  detailing  app_rw      10.0.1.0/24      scram-sha-256
# 管理用ユーザーは運用担当の踏み台サーバ1台からだけ通す
hostssl  detailing  ops_admin   10.0.9.10/32     scram-sha-256
# それ以外の送信元・ユーザーの組み合わせはすべて拒否する
host     all        all         0.0.0.0/0        reject

管理用ユーザーを踏み台サーバ1台に限れば、管理ツールの脆弱性を突かれても、その画面から全件を引き出す経路は残りにくくなります。上の設定は本記事の環境では実行しておらず、構文はPostgreSQLの公式ドキュメントの記述に基づきます。変更後はpg_ctl reloadなどで設定を読み直してから、許可していない送信元から接続できないことを確かめてください。

データベースからの持ち出しを検知する手順:VPCフローログで外部への送信量を集計

VPCフローログの既定形式14項目から送信元・送信先・バイト数を取り出す

盗むだけの侵入に気づくには、データベースや管理ツールを置いたサーバが外部へどれだけ送ったかを見ます。AWSではVPCフローログがネットワークインターフェースごとの通信を記録します。既定形式(version 2)は14項目をスペース区切りで並べ、4番目が送信元アドレス、5番目が送信先アドレス、10番目が転送バイト数、11番目が開始時刻(Unix秒)、13番目が許可(ACCEPT)か拒否(REJECT)かです。

既定形式は項目を変えられないため、決まった位置を読めば集計できます。記録が配信されるまでにCloudWatch Logsでおよそ5分、Amazon S3でおよそ10分かかるとされているので、検知は「発生中」ではなく「数十分以内」が現実的な目標です。

DBサブネットの外部送信を1時間ごとに集計し上限超過の送信先を示すPython

# VPCフローログ(既定形式・version 2)から、DBのあるサブネットが外部へ送ったバイト数を1時間ごとに集計し、閾値超えを指摘する
# 使い方: python egress_check.py flowlog.txt(ファイル名を省くと標準入力から読む)
import fileinput, ipaddress
from collections import defaultdict
from datetime import datetime, timezone

VPC = ipaddress.ip_network("10.0.0.0/16")        # VPC全体(ここ以外への送信を「外部」とみなす)
WATCH = ipaddress.ip_network("10.0.20.0/24")     # DBとDB管理ツールを置いたサブネット
ALLOW = {"52.95.110.1"}                           # 送信先として認めた外部(バックアップ先など)
LIMIT_MB = 50                                     # 1時間・1送信先あたりの上限

sent = defaultdict(int)                           # (時刻, 送信元, 送信先) -> バイト
for line in fileinput.input(encoding="utf-8"):
    f = line.split()
    if len(f) != 14 or f[0] != "2" or f[12] != "ACCEPT":
        continue                                  # 見出し行・NODATA・拒否された通信は数えない
    src, dst = ipaddress.ip_address(f[3]), ipaddress.ip_address(f[4])
    if src in WATCH and dst not in VPC and f[4] not in ALLOW:
        hour = int(f[10]) // 3600 * 3600
        sent[(hour, f[3], f[4])] += int(f[9])

for (hour, src, dst), b in sorted(sent.items()):
    if b > LIMIT_MB * 1e6:
        t = datetime.fromtimestamp(hour, timezone.utc).astimezone()
        print(f"{t:%m-%d %H:00} {src} -> {dst} 送信{b / 1e6:.0f}MB")

外部かどうかは、ipaddressの「プライベートアドレスか」の判定ではなく、自社のVPCの範囲に入るかどうかで決めています。Pythonのis_privateは文書用のアドレス範囲(203.0.113.0/24など)も真を返すため、判定を自分のネットワーク定義に寄せたほうが漏れがありません。

試験用ログで3時間の外部送信だけを検出した結果と、許可リストの運用

DBサーバからアプリサーバへの通常の応答、許可済みのバックアップ先への深夜の送信、拒否された外部からの接続に、DB管理ツールを置いたサーバ(10.0.20.30)が10月9日1時から3時間、外部の1か所へ1分ごとに約1.5MBを送る架空の記録を混ぜた試験用ログ(4,545行)を作り、Python 3.14.7(Windows)で実行した結果です。これはエンタッチの事案の再現ではなく、公表されていない手口を仮定したものでもありません。

10-09 01:00 10.0.20.30 -> 203.0.113.77 送信90MB
10-09 02:00 10.0.20.30 -> 203.0.113.77 送信91MB
10-09 03:00 10.0.20.30 -> 203.0.113.77 送信91MB

バックアップ先への約360MBの送信は許可リストにあるため出ず、拒否された接続も数えられていません。運用で詰まるのは許可リストの側です。バックアップ先や監視サービスを足したときにリストを更新しないと、毎晩の正規の送信が誤検知になり、やがて誰も通知を見なくなります。50MBは目安なので、平常時の1週間分を集計してから決めてください。集計結果を改ざんされない場所に残す設計はFluentdで作る監査ログ基盤で解説しています。

事業者の判断:医療関係者の情報を預かる委託先と委託元が見直す範囲

東邦薬品の委託分は東邦薬品が報告した、委託元と委託先の報告の分担

東邦HDの開示によると、エンタッチは個人情報保護委員会へ報告しましたが、東邦薬品からの業務委託に基づくものについては東邦薬品が報告しています。個人情報保護法第26条第1項のただし書は、委託先が委託元に漏洩を通知した場合、委託先の報告義務を免除する規定です。今回の分担はこの仕組みに沿ったものと読めます。

個人情報保護委員会の案内のとおり、不正の目的によるおそれがある漏洩は件数にかかわらず報告対象で、速報は知ってから3〜5日以内、確報は60日以内です。製薬企業がエンタッチに直接委託していた場合、自社の医師情報がどこまで含まれていたかの確認と、本人への通知の要否の判断は委託元の仕事として残ります。報告の要否を判断する手順は個人情報保護委員会への報告義務の実務で解説しています。

見直しを急ぐべき事業者と、第三者の脆弱性診断に任せる場面の線引き

判断は言い切れます。見直しを急ぐべきなのは、医療従事者や取引先の担当者の情報を預かるプラットフォームを運営しているか、その運営を外部に委託している事業者です。点検は3点に絞れます。データベースへ接続できるソフトウェアの一覧と更新日がわかるか、データベースの管理用ユーザーが特定の送信元からしか入れないか、データベースのあるサーバから外部への送信量を誰かが見ているか、です。3点目が無い構成では、今回のように業務が止まらない侵入を、外部から知らされるまで認知できません。

逆に、予約管理と面談記録を大手のSaaSに任せ、自社でデータベースや管理ツールを持たない製薬企業が、この3点を自前で組む必要はありません。その場合は委託先に上の3点の状況を書面で尋ねるのが現実的です。医師情報を扱う別の事例はエムスリー不正アクセスでMR君から医師情報が漏えいした事例と会員DBの経路分離で扱っています。自社で持つ管理ツールや公開APIが外から突ける状態になっていないかは、運用担当者が自分で確かめられる範囲には限界があるため、第三者による点検も検討の対象です。診断の種類と進め方は脆弱性診断の種類・費用相場と外注の判断基準にまとめています。医療関係者の情報を扱うシステムを外部の目で点検するなら、脆弱性診断・セキュリティ診断で相談できます。

よくある質問

エンタッチの不正アクセスについて、医療従事者・製薬企業の担当者から出やすい質問をまとめました。

エンタッチの不正アクセスで漏洩した情報は何ですか?

10月19日の第一報では、医療従事者の氏名・所属医療機関・所在都道府県、プラットフォームの管理者と担当者の氏名・メールアドレス、予約時の電話番号とメールアドレス、予約対象の製品名とコンテンツ名、予約作成日時、面談日時、面談のステータスが挙げられています。件数と範囲は調査中です。説明に使うコンテンツファイルや録画・音声データは対象外とされています。

自分が対象かどうかはどうすればわかりますか?

10月23日時点で、対象者が自分で照会できる専用ページや個別連絡の予定は公表されていません。リモートディテーリングの面談を予約したことがある医療従事者と、プラットフォームを使う製薬企業の管理者・担当者が対象になり得ます。確かめたい場合は、エンタッチの公式サイトに載ったアドレス([email protected])へ問い合わせます。

エンタッチの問い合わせ窓口に電話番号はありますか?

第一報に記載された問い合わせ先はメールアドレスのみで、電話窓口は公表されていません。東邦ホールディングスの開示に載る電話番号は適時開示の問い合わせ先です。メールやSMSに「相談窓口」として電話番号が書かれていても、公式サイトで確かめられない番号にはかけないでください。

プラットフォームのパスワードは変更する必要がありますか?

エンタッチは発覚後に全パスワードを強制的に変更しています。再設定の手順は公表されていないため、自社のプラットフォーム管理者かエンタッチに確かめてください。同じパスワードを他のサービスで使っていた場合は、そちらも自分で変更しておくと安全です。パスワードの変更をメールのリンクから求められた場合は、リンクを使わず公式サイトから操作します。

東邦薬品の他のシステムや医薬品の取引に影響はありますか?

東邦HDの開示では、本件はエンタッチのシステムにおけるもので、グループの他のシステムとは完全に遮断されているため影響はないとしています。データの改ざんや消去は確認されておらず、エンタッチの事業継続にも支障は生じていないとされています。

関連記事

お気に入りに入れた記事の一覧

この記事は以下の記事からリンクされています

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.07.21 テックブログ Apache Tomcatの脆弱性一覧【2026年10月】最新版11.0.27・10.1.61・9.0.123とCVE-2026-59083ほかの影響確認・対応手順
  2. 2026.10.21 テックブログ NEC委託先の不正アクセスとは|顧客システム暗号化・情報漏えいの経緯と委託元が点検する正規アカウント
  3. 2026.10.21 テックブログ ふるさとチョイス不正アクセスで445万件流出:対象確認・パスワード変更と再開時期
  4. 2026.10.22 テックブログ Tomcatバージョン一覧とサポート期限【2026年10月】9.0系は2027年3月末で終了・9.1系と11.0系への移行判断
  5. 2024.07.05 コラム XAMPPの脆弱性とは?危険性とCVE-2024-4577への対策をわかりやすく解説【2026年10月】

RELATED POSTS 関連記事

目次