Astemo約350名分の情報漏えい、漏れた氏名・メールアドレス・電話番号で何をされるのかまとめました

2026年10月16日、Astemo株式会社は、同社が利用するデータ共有クラウド環境に第三者による不正アクセスがあり、同社が保有するデータの一部が外部に流出したことを確認したと公表しました[1]。流出したデータには、同社の従業員、仕入先関係者、外部協力会社関係者などの個人情報約350名分が含まれ、氏名・メールアドレス・電話番号・所属などの業務上の連絡先情報が含まれるとしています。一方で、同社の顧客関係者や、その先の消費者の個人情報は含まれていなかったことも確認したとしていますが、それで安心とは言い切れません。

「自分の連絡先で、これから何をされるのか」。「会社として、どこから手を打てばよいのか」。この記事では、その2つに答えるために、流出した情報が悪用されうる場面と、今回の事故で狙われた「社員や委託先のログイン」のどこを見直すとよいかを、公開情報から整理しました。事故の経緯は報道でも扱われているため、短くとどめます。

この記事の要点

• 流出したのは仕事の連絡先です。Astemoや取引先の名前を正しく書いた、本物らしいメール・電話・SMSが届く可能性があります。
• 心当たりのない連絡で、ログインやファイルの取得を求められたら、いつもの連絡経路で相手に確かめるのが安全です。
• 会社側がまず見直したいのは、委託先の社員が使うアカウントの確認方法と、「本人が操作していない多要素認証の通知」を見逃さない仕組みです。

なお、本記事は公表文など公開情報だけをもとにしています。同社のシステムを実際に試すような調査はしていません。確認できなかった点は「確認できず」と書いています。

何が起きたか（要約）

公表文[1]によると、概要は次のとおりです。

対象人数・情報の種類・影響範囲は引き続き精査中、顧客・取引先や製品・開発関連の情報への影響も確認中としています。二次被害の報告は受けていないとしています[1]。

漏れた情報で、何ができてしまうか

今回の情報は「誰が、どの会社で、どの立場で、Astemoと仕事をしているか」がわかる一覧です。個人の買い物の記録とは違い、仕事のやり取りに入り込むための材料になります。

大事なのは、連絡先は「知られた後に変えにくい」情報だという点です。パスワードのように一斉に取り替えることができません。だからこそ、届いた連絡が本物かどうかを、連絡先以外の手がかりで確かめる仕組みが要ります。

この事故で認証が使われる場所

今回は一般の消費者向けの会員サービスで起きた事故ではありません。公表文から読み取れる「ログイン」が関わる場所を並べました。

※「狙われやすさ」は、公開情報をもとにした当社の見立てです。実際のしくみを確かめたものではありません。

会社がまず見直すとよい所（優先順）

公表文の今後の対応には、アカウントとアクセス権限の管理、異常なアクセスの監視、業務委託先を含む情報管理体制の見直しが挙げられています[1]。一方で、多要素認証の方式そのものを変えるといった記載はありませんでした。認証の観点からは、次の順で見直すことが考えられます。

1. 「本人が操作していない通知」を、その場で止める。今回、通知は9月2日頃に出ていましたが、外部から連絡が来るのは9月17日です[1]。身に覚えのない通知を社員が報告でき、すぐにアカウントを止める流れがあれば、その間の時間を縮められた可能性があります。
2. 「承認ボタンを押すだけ」の確認に頼りきらない。米国CISAは、スマートフォンへの承認通知を大量に送り、利用者がうっかり、または根負けして承認するのを待つ「MFA疲れ（プッシュ爆撃）」という手口を挙げ、フィッシングに耐性のある多要素認証への移行を強く勧めています[2]。今回の通知がこの手口だったかは公表文からはわかりませんが、通知の方式は点検しておきたい所です。
3. 委託先のアカウントを、社員と同じ基準で確かめる。今回の入口は委託会社の社員アカウントでした[1]。自社のデータに入れる人は、所属がどこであっても、同じ強さの確認を通るようにすることが考えられます。

認証の観点から：「通知が届く」と「その本人が操作した」は違う

多要素認証を入れていても、「通知が届いた端末で、誰かが承認した」ことしか確かめていなければ、本人が操作したかどうかまではわかりません。今回の公表文にある「本人の操作によらない多要素認証通知」[1]は、その隙間を示しています。

SMSで届くワンタイムパスワードも、「持っているか」を確かめる方式の一つです。ただし米国NISTのガイドラインは、SMSなど電話網を使う確認方法を「制限付き（restricted）」の手段と位置づけています[4]。禁止ではありませんが、端末の入れ替えやSIMの変更、電話番号の乗り換え（ポーティング）といったリスクを踏まえ、それだけに頼りきらない設計が求められています。

当社Infront Securityの電話番号認証は、利用者がワンタップで指定の番号に発信し、その発信者番号と端末の情報をサーバー側で照合して本人を確かめます。電話番号を知っていても、その回線から発信できなければ認証は通りません。偽サイトは利用者の電話回線を持っていないため、フィッシングに耐性のある方式です。

社員や委託先のログインに「その本人の回線からの操作か」という確認を足す方法については、お気軽にご相談ください。

お問い合わせはこちら