SONAE KNOWLEDGE / 会社の備え
多要素認証、どのアカウントから設定する？小さな会社の導入手順
AI技術確認日：2026-10-23／編集確認は未了
AIを用いて初稿を作成し、技術確認もCodex（AI）が実施しています。一次資料との対応、記述とひな型の整合性を確認しました。専門家による監修ではありません。運営者の判断で先行公開しています。本人による編集確認は未了です。確認範囲は運営と編集のページをご覧ください。
公開：
メール、管理者、経理。まず守る入口を決め、ログインできなくなったときの備えまで整える。
多要素認証は、異なる種類の要素を組み合わせる仕組み
多要素認証（MFA）は、知っている情報、持っているもの、身体の特徴など、異なる種類の要素を組み合わせて本人を確かめる方法です。NISTは小規模事業者向け資料で、パスワードが漏れた場合に追加の壁となることと、認証方法によってフィッシングへの強さが異なることを説明しています。SMSや一度だけ使うコードも、偽サイトへ入力すれば悪用されるおそれがあります。FIDOのセキュリティキーなど、フィッシングに強い方式が利用できるか確認しましょう。MFAの導入だけで、端末の侵害やすべての不正利用を防げるわけではありません。
SONAE KNOWLEDGE / 図解 01
一つのIDから、どこまで届く？
アカウントが侵害されたときの影響は、割り当てた権限と連携先にも左右される。
図の内容を文章で読む
侵害されたID：第三者が不正利用 / 認証・認可：本人確認と権限の評価 / メール：与えた権限の範囲 / 共有資料：与えた権限の範囲 / 業務サービス：与えた権限の範囲。関係：侵害されたID → 認証・認可（アクセスを試す） / 認証・認可 → メール（） / 認証・認可 → 共有資料（） / 認証・認可 → 業務サービス（）
最初は、乗っ取られたときに困る入口から
ここからはSONAEの導入計画例です。会社のメール、管理者用のアカウント、振込や会計に関わるサービスを最初の候補にします。メールは他のサービスのパスワード再設定にも使うため、単なる連絡手段として扱わず、どこにつながるかを書き出します。次に顧客情報や重要な共有ファイルを扱うサービスを確認します。「対象外」にしたアカウントも、理由と見直し日を残してください。最終的にはMFAを使える業務アカウント全体へ広げる計画を立てます。
SONAE KNOWLEDGE / 図解 02
パスワードが漏れた。その先で、何が違う？
同じ場面を比較：第三者がパスワードを知っているが、本人の認証キーは持っていない。
パスワードのみ
パスワード ＋ 認証キー
MFAの一例パスワードが知られても、
別の本人確認が、次の壁になる。
一人で試してから、部署へ広げる
利用中の契約で選べる方式、対応端末、管理者が必須化できるかを公式手順で確認します。まず少人数で、通常のログインと端末を替えた場合の手順を確かめます。方式名が同じでも設定や回復手順は製品ごとに異なります。いきなり全社員へ必須化せず、案内する担当、質問の窓口、実施時期を決めましょう。日常作業と管理作業でアカウントを分けている場合は、それぞれの登録状況も確認します。
端末を失くしたときの手順もセットにする
認証に使うスマートフォンやキーの紛失、故障、担当者の退職を想定します。製品が対応する予備の認証手段や回復コードの保管方法を選び、閲覧できる人を限定します。回復コードをアカウント台帳や全員が見る共有フォルダーに貼らないでください。再登録を認める前に誰が本人確認し、誰が承認するかも決めます。緊急用アカウントを設ける場合は、製品の推奨手順に従い、利用の記録と定期確認を含めて管理します。
「設定済み」を確認できる台帳にする
架空の例では、総務担当が対象者への案内を行い、IT担当が登録状況を確認し、管理部門が未登録者の対応期限を決めます。台帳にはサービス、役割、方式、適用範囲、確認日、未完了の理由を記録します。パスワードや秘密の回復情報そのものは記録しません。完了の目安は、対象者の登録と必須化の状態を確かめ、紛失時の連絡先まで共有できたことです。未対応や例外を別の担当者が見直せる形にすると、導入後も運用を続けやすくなります。
「登録した」と「利用時に要求される」を分ける
架空の会社では、メール管理者、経理担当、一般社員の三つの役割を並べます。管理者は広い権限があるため先に確認し、次に重要な業務へ進む計画にします。台帳ではMFAが使えるか、本人が登録したか、組織が要求する設定か、その対象へ期待どおり適用されるかを別の欄にします。毎回画面が出ないことだけで無効とは判断せず、製品のポリシーやセッションの条件を管理者が確認します。登録人数だけを導入完了の証拠にしないための区分です。
少人数の試行で、通常時と紛失時を読み合わせる
会社が選べる方式と対応端末を先に確認し、許可した試行用の対象で通常のサインイン、端末変更、担当不在の連絡経路を確認する計画にします。いきなり本番アカウントの認証手段を外して紛失を再現する必要はありません。回復を依頼する人の本人確認、承認、再登録の担当を決め、コードや秘密鍵そのものを台帳へ貼らず、管理された保管場所と閲覧できる役割だけを記録します。未登録者や例外には理由と次の確認日を付け、部署展開の前に残課題を責任者へ渡します。
CASES / 2026年10月23日確認
実際の事例から、備えを考える。
以下は公表資料をもとにした要約です。SONAEの診断実績ではありません。自社への適用は、下の問いと分けて考えます。
事業者の脅威調査
IT担当を装って認証情報を求める電話
- 公表・更新
- 2026年1月31日（今回確認した公式ページの表示）
- 発生・観測
- 報告対象の一部：2026年1月上旬〜中旬。
Googleは、IT担当を装う電話で偽の認証画面へ誘導し、SSO情報やMFAコードを取得した活動を報告しています。
確認範囲：「MFAがあればすべて防げる」と示す事例ではありません。声がAI生成だったとする断定もしていません。
認証コードの提供や再登録を求められたとき、既知の社内窓口に確認する手順がありますか。
被害企業の調査結果
アサヒグループ：侵入・暗号化と業務影響
- 公表・更新
- 2026年2月18日
- 発生・観測
- 障害・暗号化の発生：2025年9月29日。侵入はその約10日前と推定。
アサヒグループは、ネットワーク機器経由の侵入、管理者権限の奪取、複数システムの暗号化などの調査結果を公表しました。
確認範囲：発生年は2025年です。公表されていない機器の詳細やAI利用、MFAの状態を推測していません。
侵入後の影響範囲、管理者権限、業務を戻す順番と判断する担当を把握していますか。
WORKSHEET / 04
MFA導入・回復の確認台帳
まずは記入例を読み、自社で決める欄を確認してください。以下はSONAEの運用提案・架空例で、技術確認はAIが実施しています。専門家による監修ではありません。
UTF-8テキスト。メモ帳や文書アプリで編集できます。保存したファイルへの記入内容をサイトへ送る機能はありません。
記入済みの架空例を見る
- 対象・役割・優先の理由
- 架空メールサービス／管理者／権限が広く再設定にも関わる
- 方式と対応条件
- フィッシングに強い方式を候補にし、プラン・端末・公式手順を確認
- 登録の状態
- 試行対象1名は登録を確認／部署全体は未確認
- 必須化と適用範囲
- 管理者に要求する設定と、対象・例外を管理者が確認
- 確認の根拠・時点
- 確認画面や設定記録の参照先／確認日と担当を記録
- 予備手段の管理
- 利用可能な予備手段の管理場所と閲覧役割のみ／秘密は記入しない
- 紛失時の本人確認・承認
- 本人確認は担当A、承認は責任者B、再登録は管理者C
- 試行・展開の計画
- 少人数の確認後に案内／展開日は残課題の判断後に合意
- 例外と次の確認
- 未対応端末は責任者判断待ち／期限と代替策を別記
- 完了を確認する人
- 登録・適用・回復窓口・例外を別担当が確認する
このひな型の受入チェック
- 利用可能・登録・必須化・適用を混同していない
- 回復手段の秘密を台帳へ書かず、担当と承認経路を共有した
- 未対応と例外を含め、次の担当が残課題を追える
公式資料の対応：NIST Small Business Fact Sheetの1ページ目で認証要素、2ページ目でフィッシングに強い方式と導入時の問いを確認。優先する役割、試行と回復台帳の書式はSONAEの提案で、全製品共通の設定手順ではありません。
相談前の確認表
- メール・管理者・経理などの重要アカウントを挙げた
- フィッシングに強い方式の対応状況を確認した
- 紛失時の回復手順と本人確認の担当を決めた
- 登録・必須化・未対応の状態を記録できる
参考資料（確認日：2026年10月23日）：NIST：Multi-Factor Authentication — Small Business Fact Sheet ↗
一般的な説明とSONAEの運用提案です。製品の公式条件と自社の管理責任者の判断を確認してください。
認証と権限の点検内容を見る →