多要素認証は「導入済み」で終わらない――アスクルの事案から考える委託先アカウント管理

「多要素認証は導入しています」

取引先からの質問や社内の点検で、こう回答したことはないでしょうか。

その回答には、外部の保守会社が使うアカウントも含まれていますか。管理者権限を持つアカウントや、通常とは異なる接続方法についても、実際の設定を確認していますか。

今回考えたいのは、多要素認証を初めて設定する方法ではありません。導入した対策の対象から、何が外れているのかを把握し、その例外を管理することです。

アスクルが公表したランサムウェア攻撃の調査報告では、例外的に多要素認証を適用していなかった、業務委託先に付与した管理者アカウントへの不正アクセスが確認されています。会社全体としての対策状況だけでなく、実際に使われるアカウントごとの確認が必要なことを考えさせる事案です。

この記事では、公表資料から確認できることを整理したうえで、中小企業が委託先アカウントの適用漏れを見つけ、例外の解消まで進めるための方法を紹介します。

アスクルの公表資料で確認できること

アスクルでは、2025年10月19日にランサムウェア攻撃が検知され、サービスの停止や情報の流出につながりました。同社は同年12月12日、「ランサムウェア攻撃の影響調査結果および安全性強化に向けた取り組みのご報告」を公表しています。ASKUL

報告書の原因分析では、業務委託先に付与していた管理者アカウントについて、IDとパスワードの漏えい・不正利用が確認されたと説明しています。このアカウントには、例外的に多要素認証が適用されていませんでした。

一方、同社は、ログが失われていたことなどから原因の完全な究明は困難とも説明しています。公表資料からは、認証情報が具体的にどのような方法で漏えいしたのかは分かりません。 フィッシングメールや特定のマルウェアが原因だったと、この記事で断定することはできません。

また、この事案を「多要素認証が突破された事件」と表現するのも適切ではありません。今回の論点となるアカウントについて、公表された問題は、多要素認証が適用されていなかったことです。

ここから自社の点検につなげたいのは、委託先を一律に危険視することではありません。

「多要素認証を使う」という方針と、「現実に使われるすべての対象へ適用されている」という状態を分けて確認することです。

点検の単位を「会社」から「アカウントと接続経路」へ変える

「当社では多要素認証を導入している」という回答だけでは、対象がどこまで含まれているのか分かりません。

従業員のメールだけなのか、クラウドの管理画面も含むのか。外部から社内へ接続する仕組みは対象なのか。保守会社の担当者が使うIDは、従業員と同じ管理の中に入っているのか。

そこで、本記事では、**「誰が、どのアカウントで、どの経路から、何に接続するか」**を一組として確認する方法を提案します。

例えば、販売管理システムの保守を外部へ委託している場合、委託先の会社名だけでなく、実際に作業する担当者、接続用アカウント、利用する遠隔接続の仕組み、接続先のサーバーや管理画面までを整理します。

クラウドの管理を委託している場合も同様です。自社が発行したアカウントだけでなく、外部の担当者を招待して利用させている方法や、委託先に管理権限を委ねている方法がないかを確認してください。

その際、委託先から「当社では多要素認証を使っています」と回答を受けても、確認を終えないようにしましょう。それが委託先の社内メールの話なのか、自社環境への保守接続の話なのかを明確にします。

IPAの「中小企業の情報セキュリティ対策ガイドライン第4.0版」も、自社だけでなく、委託先の情報セキュリティ対策まで考慮することを経営者の原則として示しています。委託先に任せる業務があっても、何を任せ、どの条件で自社の情報へアクセスさせるのかは、委託元として整理する必要があります。

「対応している」「登録した」「必須になっている」を分ける

多要素認証の確認では、「設定済み」という言葉の中身も具体化しましょう。

例えば、サービスに多要素認証の機能があることと、利用者が認証アプリを登録したことは別です。認証アプリを登録したことと、対象の接続で多要素認証が必須になっていることも、分けて確認しなければなりません。

本記事では、管理上の状態を次のように分けることを提案します。製品の管理画面に表示される正式な状態名ではなく、社内で確認結果を整理するための分類です。

管理上の状態	確認できていること	まだ確認が必要なこと
機能対応を確認	利用するサービスに多要素認証の機能がある	自社の契約・設定で使えるか、対象へ適用しているか
認証手段を登録済み	利用者が認証アプリなどを登録した	対象の接続で、その認証が要求されるか
必須化の設定を確認	対象者・接続先に認証ルールを設定した	除外設定や別経路がないか、実際に適用されるか
適用結果まで確認済み	設定と接続記録などを照合した	変更後も同じ状態が維持されているか
未確認	判断に必要な情報がそろっていない	誰が、何を、いつまでに確認するか

この区別が必要な例として、Microsoft Entra IDの「条件付きアクセス」には、ポリシーの影響を調べるためのレポート専用モードがあります。このモードでは、サインイン時に条件を評価して結果を記録しますが、そのポリシーは適用しません。ポリシーを作成しただけで、認証が強制されているとは限らないということです。

逆に、管理画面の一つの表示だけを見て、「無効だから多要素認証が使われていない」と決めつけることも避けてください。Microsoftは、条件付きアクセスで多要素認証を要求しても、ユーザーごとの多要素認証の状態表示は変わらないと説明しています。

確認したいのは設定項目の名前ではなく、そのアカウントの接続に、意図した認証が適用されているかです。

実際の接続で、適用されていることを確かめる

設定の確認が済んだら、業務で使う接続方法と照合します。

本記事では、管理者と委託先で確認日時を調整し、承認されたテスト用アカウントなどを使って、想定どおりに認証とアクセス制御が働くかを確認する方法を提案します。

例えば、通常の接続では必要な認証を経て対象システムへ入れること、許可していない条件では接続できないこと、接続後に業務と無関係な範囲へアクセスできないことを、それぞれ確認します。

ただし、従業員や委託先へパスワードや認証コードを提出させる必要はありません。本人が操作する場面を確認し、設定や記録と照合する形で進めてください。

また、「今回は認証コードを求められなかった」という見た目だけで、適用漏れと断定しないことも重要です。Microsoft Entra IDのサインインログでは、以前の認証に基づく情報によって認証要件が満たされ、利用者に改めて入力を求めない場合についても確認できます。Microsoft Learn

確認結果には、対象アカウント、接続先、接続方法、確認日時、適用された認証ルール、確認者を残します。接続記録の識別番号や設定資料の保管場所が分かるようにしておくと、後から根拠を確認できます。

複数のサービスを利用している場合、一つのサービスで確認できた結果を、そのまま他のサービスへ当てはめないようにしましょう。「この条件で、この接続を確認した」という範囲を明確にすることが必要です。

なお、接続テストで全体の設定を無断変更したり、既存の認証手段を削除したりしてはいけません。管理者自身が接続できなくなる場合に備え、変更の承認、影響範囲、復旧方法を確認してから実施してください。

委託先には「必要な人へ、必要な権限を、必要な期間だけ」

多要素認証の対象を確認するときは、そのアカウントに与えた権限も見直しましょう。

認証は、接続してきた相手を確認する仕組みです。一方、アクセス権限は、認証された相手に何を許可するかを決めるものです。本人の確認を強化しても、業務に不要な権限まで残す理由にはなりません。

IPAのガイドラインでは、ユーザーIDと管理者IDを発行から削除まで管理し、必要最小限の割当てとすること、共有IDはなるべく使わず、やむを得ず使う場合も利用者を特定できる仕組みを整えることが示されています。

委託先の作業についても、「保守を依頼しているから管理者権限」という決め方ではなく、作業内容から必要な権限を整理することを提案します。

例えば、ログを確認して原因を調べる作業と、システム設定を変更する作業では、必要な操作が異なります。閲覧だけで足りる場面に、利用者の追加やデータ削除までできる権限を付ける必要があるかを確認してください。

また、通常の連絡や資料確認に使うアカウントと、管理作業用のアカウントは、可能な範囲で分けることをおすすめします。管理者権限が必要になる作業だけ、所定の承認を経て利用する形にできないか検討しましょう。

利用期間も、保守契約の終了日だけでなく、担当者の交代や担当業務の終了と結び付けます。委託先との取引が続いていても、すべての担当者のアクセスを残し続ける必要があるとは限りません。

「契約中の会社だから利用可」ではなく、「この人が、この仕事のために使う」という状態まで具体化することが大切です。

例外を見つけたら、まず理由を具体化する

多要素認証の適用対象から外れているアカウントが見つかった場合、すぐに「現場がルールを守っていなかった」と結論付けるのではなく、なぜその状態になっているのかを確認しましょう。

例えば、システムが認証機能に対応していないのか、対応しているが設定していないのか、以前のトラブル対応で一時的に除外したのかによって、必要な作業は変わります。

「保守に必要だから」という説明だけでは、判断に必要な情報が足りません。

何の作業を行うために、どの認証設定が問題になるのか。どの条件で試し、何ができなかったのか。製品の仕様として対応できないのか、まだ試していないのか。こうした点を具体化してください。

本記事では、例外の理由を、少なくとも「機能上の制約」「設定・移行作業が未完了」「一時的な障害対応」「利用実態を確認できていない」といった形で分けて整理することを提案します。

特に注意したいのは、分からない状態を、承認済みの例外へ置き換えないことです。「昔からこの設定だった」「前の担当者しか分からない」は、継続利用を認めるための根拠ではなく、調査が必要な状態です。

同時に、確認できないアカウントを無計画に一斉削除することも避けましょう。通常の人による保守作業なのか、自動処理にも使われているのかを確認し、業務への影響を整理したうえで停止・変更します。

プログラムが利用するサービスアカウントが見つかった場合は、人が使うアカウントと管理を分けてください。人向けの認証手順をそのまま適用できないことを理由に、保守担当者まで同じIDを使い続ける運用にはしないようにします。

委託先アカウントと認証例外を、一つの台帳で管理する

点検の結果は、アカウント一覧と例外申請を別々に保管して終わらせず、相互に確認できるようにしましょう。

本記事では、次のような台帳を提案します。新しいシステムを購入することが前提ではありません。既存のアカウント台帳に必要な項目を追加する方法でも構いません。

以下は当事業所による管理項目の提案であり、アスクルが使用していた帳票や、公的機関が指定する様式ではありません。

記録項目	記録する内容
対象システム・接続経路	どのサービス・機器へ、どの方法で接続するか
アカウント	対象を特定できるID、一般利用・管理者利用の区別
利用者	委託先名、実際の担当者、再委託がある場合の所属
業務上の責任者	自社で利用目的と継続の必要性を判断する人
利用目的・権限	依頼した業務、許可する操作、対象となる情報や機器
利用期間	利用開始日、終了日、次回確認日
認証の状況	認証方式、必須化の設定、対象・除外条件
確認の根拠	設定資料、接続確認結果、ログなどの保管場所
例外の内容と理由	何が標準から外れているか、具体的な制約
暫定措置と残るリスク	継続する場合に実施する制限、解消できていない問題
承認と期限	判断した責任者、承認日、例外の有効期限
解消計画	作業内容、担当者、完了予定日、完了条件
停止・変更の記録	実施日時、実施者、利用できなくなったことの確認結果

この台帳で重視したいのは、「多要素認証あり」という一つの欄だけで管理しないことです。

例えば、認証アプリの登録は終わっているが、特定の接続だけ対象から外れている場合は、その接続経路を分けて記録します。同じアカウントでも接続条件が異なるなら、別の行にする方法が考えられます。

例外がないことを確認したものと、例外があるかどうか未確認のものも区別してください。空欄のままでは、点検が終わっているのか判断できません。

また、パスワード、認証アプリの登録用QRコード、秘密鍵、復旧用コードなどを、この台帳へ書き込まないでください。台帳には管理担当者や保管場所を記録し、認証に使う秘密情報は、別に定めた方法で保護します。

例外の解消は、「設定を変えた」ではなく「通常運用へ戻った」で判断する

ここで、架空の事業所の例を考えます。以下は実務を説明するための例であり、アスクルの内部運用を再現したものではありません。

ある会社では、外部の保守担当者が認証端末を交換した際、一時的に多要素認証の対象から外していました。その後、認証端末の準備は終わっていたものの、元の設定へ戻す作業が残っていたとします。

この場合の対応は、除外設定を削除するだけで終わらせない方がよいでしょう。

まず、保守担当者本人の認証手段が正しく登録されていることを確認します。次に、変更する日時を調整し、対象の接続で多要素認証を必要とする設定へ戻します。そのうえで、通常の保守作業ができることと、意図した認証が適用されていることを確認します。

完了記録には、設定変更の日時だけでなく、接続確認の結果と、承認した担当者を残します。使わなくなった古い認証手段や、臨時に発行したアカウントがある場合は、その扱いも確認してください。

例外の解消条件を、

対象の保守接続で多要素認証が適用され、必要な作業を実施できることを確認し、臨時の設定とアカウントを整理する。

と定めれば、作業の終点が明確になります。

一方、システムの機能上の制約がある場合は、認証に対応した接続経路への変更や、システムの更新を検討します。接続元や利用時間の制限だけを追加しても、それで多要素認証と同じ保護が得られるとは扱わないようにしてください。

例外の承認は、問題がなくなったという意味ではありません。残る問題を把握し、解消までの扱いを決めたということです。

委託元と委託先で、設定・承認・確認の担当を分ける

アカウントの設定を保守会社に任せている場合でも、すべての判断まで任せる必要はありません。

本記事では、自社側が利用目的と必要な権限を決め、技術担当者が設定し、その結果を双方で確認する役割分担を基本として提案します。

例えば、自社の業務責任者は「販売管理システムの障害調査に必要な範囲」を決めます。保守会社は、その作業に必要な操作と権限を説明します。設定を行う管理者は、合意した範囲をシステムへ反映します。最後に、自社の担当者が設定・作業記録を確認します。

例外を継続する判断についても、設定を変更できる人が、そのまま単独で承認する運用にしないことをおすすめします。業務への影響と残るリスクを理解した責任者が、期限と解消計画を含めて判断してください。

IPAのガイドラインでは、外部委託に際し、情報セキュリティに関する責任や実施すべき対策を契約書に明記し、合意することが示されています。

具体化する際は、認証方式や利用権限だけでなく、担当者交代時の連絡、再委託先の利用条件、接続記録の提供、事故時の連絡先、緊急停止の方法まで確認しておくと、実際の作業につなげやすくなります。

委託先へ確認を依頼する際は、例えば次のような文章が使えます。

当社環境への保守接続について、利用中のアカウント、実際の利用者、接続経路、付与権限、多要素認証の適用状況をご確認ください。適用対象から外れている接続がある場合は、その理由、現在の保護措置、解消方法と予定日を併せてご提示ください。回答には、設定や接続記録など、確認した根拠を付記してください。パスワードや認証コードの送付は不要です。

これは依頼文の作成例です。実際の契約内容や管理範囲に合わせて調整してください。

「ログインできないので解除してほしい」への対応を決めておく

例外を減らすためには、新たな例外が生まれる場面への備えも必要です。

例えば、保守担当者から「認証用の端末が使えない」「機種変更後にログインできない」と連絡が来たとき、担当者の判断だけで多要素認証を解除する運用になっていないでしょうか。

本記事では、まず依頼者の本人確認と、作業を行う権限の確認をし、そのうえで認証手段の再登録など、定めた復旧手順を利用する方法を提案します。

本人確認には、依頼時に新たに伝えられた連絡先だけでなく、事前に登録した委託先の窓口や担当者情報を使います。「急いでいる」「本日の作業が止まる」という事情と、本人であることの確認は分けて扱ってください。

また、認証手段が一つ使えなくなった場合に備え、利用するサービスで認められる予備の認証手段や復旧方法を、先に整理しておくことをおすすめします。

管理者全員が接続できなくなる事態に備える緊急アクセス用アカウントについても、単に多要素認証を外した予備IDを置く方法とは区別してください。

Microsoftは、Microsoft Entra IDの緊急アクセス用アカウントについて、FIDO2などの認証方法、安全な資格情報の保管、監視、定期的な検証を案内しています。通常の認証やアクセス制御に障害が起きた場合でも使えるよう、独立した設計が必要です。

緊急時に使えることと、普段から無制限に使えることは違います。 利用する条件、承認する人、使用後の確認まで含めて準備しましょう。

接続記録は、「残している」から「確認している」へ進める

アカウント台帳と設定が整っていても、実際にどう使われているかを確認しなければ、運用の変化を把握できません。

IPAのガイドラインでは、通信ログや認証ログを取得・保管し、改ざん防止を行ったうえで、定期的に確認することが示されています。

本記事では、委託先の接続記録を、依頼した作業の記録と照合する方法を提案します。

例えば、作業予定のない日に接続がある、終了した案件のアカウントが使われている、いつもと異なる接続方法が使われた、多要素認証の除外設定が変更されたといった場合に、誰が確認するかを決めます。

ただし、予定外の接続を見つけたことだけで、不正アクセスと断定する必要はありません。緊急対応が追加されていた、予定表が更新されていなかったなどの事情がないか、本人と作業責任者へ確認します。

確認した結果は、「異常なし」で終わらせず、照合した作業番号や確認先を残しておくと、後から経緯を追いやすくなります。

また、記録を残す期間だけでなく、誰が取り出せるか、委託先が不在でも確認できるか、機器の更新や交換時に失われないかを確認してください。ログを取得する設定があっても、必要なときに読めないのであれば、調査の準備として十分とはいえません。

小規模な会社では、最初からすべての記録を詳細に確認しようとするのではなく、管理者権限を使う接続や、例外を認めている接続から、確認対象と担当者を決める方法が考えられます。

契約終了や事故のときは、「IDを止めた」で終わらせない

委託先との契約が終了したときや、担当者が交代したときには、利用を認める状態を見直します。不正利用が疑われた場合も、対象のアクセスを停止する判断と操作が必要になります。

このときに確認したいのは、新しいログインを止めたかだけではなく、すでに接続中の利用も止まるかです。

Microsoftは、アクセスの取消しについて、環境によって実際に利用できなくなるまで時間がかかる場合があることや、アプリケーションが独自に発行するセッションについては、そのアプリケーション側での対応が必要になることを説明しています。

そのため、本記事では、利用しているサービスごとに、アカウントの無効化、接続中セッションの終了、認証情報の変更、残る権限の解除など、どの操作が必要かを事前に確認しておくことを提案します。

担当者が交代する場合は、後任者へ同じIDと認証手段を渡すのではなく、後任者の利用を新たに承認し、前任者の利用を終了する手順を基本にしましょう。共用が避けられない仕組みでは、利用者と認証情報の管理方法を別途定めます。

事故対応では、対象を止めることに加え、停止前後の設定、接続記録、実施した操作を保全します。証拠が必要な段階で、関連するアカウントや記録をまとめて削除する運用にはしないでください。

さらに、委託先自身に障害や事故が起きて連絡が取れない場合でも、自社側で接続を止められるかを確認しておきます。停止する人と停止方法が分からない場合は、平時のうちに整理すべき課題です。

多要素認証の「方式」も、適用範囲とは別に確認する

適用漏れの解消と併せて、採用している認証方式も確認してください。

多要素認証であれば、すべての方式が同じ性質を持つわけではありません。NISTのデジタル認証ガイドラインでは、利用者が手入力するワンタイムパスワードなどは、フィッシング耐性がある方式として扱われていません。偽のサイトが入力された認証情報を中継する攻撃に対し、技術的に防げるかという違いがあります。

ここでいうフィッシング耐性とは、利用者が偽物に気付くことだけに頼らず、認証の仕組みとして偽の相手への認証情報の提供や悪用を防ぐ性質です。

管理者権限を持つアカウントについては、利用するサービスが対応しているかを確認し、FIDO2対応のパスキーなど、フィッシング耐性のある認証方式を検討することをおすすめします。方式の選定だけでなく、登録、端末紛失時の対応、担当者交代時の解除まで含めて設計してください。

ただし、この記事で紹介したアスクルの事案について、ワンタイムパスワードが盗まれたと説明しているわけではありません。公表された適用漏れの問題と、一般的な認証方式の比較は分けて考える必要があります。

また、より強い認証方式の検討が終わるまで、現在の適用漏れを放置する進め方は避けたいところです。まず対象を把握して必要な認証を適用し、その後の改善計画として方式の強化も進めましょう。

最初の点検では、「未確認」と「期限のない例外」を減らす

自社で確認を始めると、すべての情報がすぐにはそろわないかもしれません。その場合は、台帳を完成させるまで何もしないのではなく、確認結果を次の行動へつなげてください。

最初に、外部から管理者権限で接続できるアカウントを確認します。利用者、用途、認証の適用状況が分かるものと、分からないものを分け、未確認のものに担当者と確認期限を付けます。

次に、多要素認証の対象から外れている接続について、設定変更で対応できるのか、システムや業務の変更が必要なのかを整理します。期限のない例外には、責任者の判断と解消計画を求めます。

そのうえで、確認済みのアカウントについても、担当者の変更、認証設定の変更、契約更新などのタイミングで再確認する運用を組み込みます。

経営者への報告は、「ほとんど対応しています」より、次のような形が分かりやすいでしょう。

外部保守用アカウントの一覧化を進めています。現在、認証の適用を確認できたもの、設定変更が必要なもの、利用実態を調査中のものに分けています。未確認事項と例外には担当者・期限を設定し、完了時には接続結果まで確認します。

これは報告文の作成例です。実際の報告では、それぞれの件数、対象、期限、業務への影響を加えてください。

対応済みの割合だけでなく、未確認の管理者アカウントが残っていないか、期限切れの例外が放置されていないかを、判断できる形にすることが大切です。

まとめ――確認すべきなのは、「導入したか」より「誰が対象外なのか」

多要素認証の点検では、会社として導入したという説明だけで終わらせず、実際に使われるアカウントと接続経路まで確認しましょう。

その際に整理したいのは、利用者、接続先、権限、認証の適用状況、例外の理由、解消期限、停止方法です。

委託先のアカウントも、自社の業務を支えるために認めたアクセスです。信頼関係を前提としながら、その信頼を、対象が分かる台帳、必要な権限、確認できる記録、終了できる手順へ落とし込んでください。

例外が見つかったこと自体で、点検が失敗したわけではありません。これまで分からなかった対象が明らかになれば、次の対策を具体化できます。大切なのは、見つかった例外を説明のつかない状態で残さないことです。

「多要素認証は導入済みです」から、「対象と例外を把握し、実際の適用を確認しています」へ。

まずは、自社の環境へ管理者権限で接続できる委託先アカウントを、一つ確認するところから始めてみてください。

ライトハウスコンサルタントでは、個人事業主・中小企業のアカウント管理、クラウド、社内ルールなどの現状を確認し、対策の優先順位を整理する支援を行っています。委託先へ何を確認すればよいか分からない場合や、台帳と実際の設定を照合したい場合は、ご相談ください。