Astrana Healthの公表事例から考える、「社内からの電話」に見えるソーシャルエンジニアリング
※本稿はAstrana Healthが米国証券取引委員会（SEC）へ提出したForm 8-Kなどの公開情報をもとに、医療機関・医療関連事業者に共通するサイバーセキュリティ上の確認点を考えるものです。公表されていない攻撃手法や原因を推測するものではありません。
「表示されている電話番号」は本人確認になるでしょうか
サイバー攻撃というと、フィッシングメールや不審な添付ファイルを思い浮かべることが多いかもしれません。しかし、相手が電話で「社内の担当者です」と名乗り、画面に表示された番号も会社の代表番号だった場合はどうでしょうか。
2026年9月23日、米国のヘルスケア企業Astrana Healthは、子会社Astrana Health Managementで発生したサイバーセキュリティインシデントについてSECへForm 8-Kを提出しました。同社の公表によると、攻撃者は会社の担当者になりすまし、さらに同社の代表電話番号を偽装して従業員へ接触する、一連のソーシャルエンジニアリングを行っていました。SEC Form 8-K
ここで大切なのは、「電話だから安全」「社内の番号が表示されているから本人だ」とは限らない、ということです。
公表されている事実
Astrana Healthは、子会社の環境で異常な活動を検知したとしています。同社のSEC開示では、攻撃者が会社関係者を装い、会社の代表電話番号を偽装して従業員へ接触し、システムへの不正アクセスを試みたことが説明されています。
その後の調査で、同社サーバー上の一部の秘密情報または機密情報が、権限なくアクセスまたは取得されたと同社は判断しています。
一方、患者、従業員、医療従事者、事業情報、財務情報、知的財産などのうち、実際に何がどの範囲まで影響したのかについては、記事作成時点でも調査中です。影響人数も公表されていません。SEC Form 8-K
Astrana Healthが公表している対応
同社はインシデントへの対応として、外部のサイバーセキュリティ・デジタルフォレンジック専門家を起用し、法執行機関や規制当局等への連絡を進めています。
技術面では、影響した認証情報のリセット、リモートアクセスツールの制限、一部システムのclean backupからの復元、監視・ログ・検知能力の強化を実施したとしています。SEC Form 8-K
ただし、公表資料からは、どの認証情報がどのように取得されたのか、リモートアクセスツールが実際の侵入経路だったのか、MFAが設定されていたのか、あるいは回避されたのかまでは確認できません。確認できていないことを補って物語を作らないことも、インシデントを学ぶうえでは重要です。
この事例から確認したい5つのこと
1. 電話番号だけで相手を本人と判断していないか
発信者番号表示は便利ですが、それだけを本人確認には使えません。
パスワード変更、MFAの再設定、リモート接続の許可、管理者権限の付与など重要な依頼では、登録済みの連絡先へ折り返す、社内ディレクトリや別の承認経路で確認するなど、「相手が示した情報とは別の経路」で本人確認できるようにします。
2. パスワードやMFAを変更する手順が決まっているか
「急いでいる」「端末を交換した」「ログインできない」といった依頼は、日常のITサポートでも起こります。だからこそ、担当者個人の勘ではなく、本人確認、承認、記録まで含めた標準手順が必要です。
3. リモートアクセスを誰が使えるか把握しているか
遠隔保守やリモートサポートは、医療機関や医療機器メーカーでも日常的に使われます。利用しているツール、利用者、接続可能時間、権限、MFA、接続ログを棚卸しし、不要な接続経路を残さないことが重要です。
4. 「いつもと違う操作」を後から追えるか
認証情報の変更、リモートアクセス、新しい端末からの接続、管理者権限の変更などを記録し、異常時に追跡できるようにします。ログを保存するだけでなく、「誰が確認するのか」まで決めておく必要があります。
5. システムを安全な状態へ戻せるか
Astrana Healthは、一部システムをclean backupから復元したと公表しています。
バックアップは「存在する」だけでは十分ではありません。復元できること、復元後のシステムが安全かを確認できること、復旧手順を担当者が実行できることまで確認します。
医療機関ではどう考えるか
例えば、電子カルテ、PACS、予約システム、VPN、医療機器の遠隔保守について、電話で「メーカーです」「院内のIT担当です」と言われたときに、どのように本人確認するかを決めておく必要があります。
特に、パスワードやMFAの変更、遠隔接続の開始、管理者権限の付与は、一本の電話だけで完結させない運用が重要です。
医療機器メーカーではどう考えるか
製品そのものだけでなく、保守用アカウント、VPN、クラウド管理画面、顧客サポート環境なども攻撃対象になり得ます。「製品に脆弱性がない」ことと、「製品を支える運用環境が安全である」ことは別です。
設計・試験とあわせて、遠隔保守の接続手順、サポート担当者の本人確認、権限管理、ログ、インシデント発生時の復旧手順を確認する必要があります。
AIGISの見解
今回の公表事例から読み取れるのは、サイバーセキュリティが技術だけの問題ではないということです。高度な攻撃ツールがなくても、「社内の人に見える」「いつもの電話番号に見える」「急いで対応してほしい」といった状況が、人の判断を揺らすことがあります。
そのため対策も、「社員に気をつけてもらう」だけでは不十分です。
本人確認の方法を決める。
リモートアクセスを制限する。
重要操作を記録する。
異常時には認証情報を止める。
安全なバックアップから復旧できるようにする。
人が迷ったときでも安全側へ進める仕組みを作ることが、実務上のサイバーセキュリティ対策になります。
AIGISでは、医療機関・医療機器メーカーのIT環境や遠隔接続、認証、バックアップ、インシデント対応の現在地を整理する支援を行っています。
関連記事
参考資料
- Astrana Health, Inc., Form 8-K, Item 1.05 Material Cybersecurity Incident, filed September 23, 2026.
- HHS Cyber Gateway, Social Engineering.
情報確認日：2026年10月2日。公表内容は今後更新される可能性があります。