多要素認証とは

多要素認証とは

多要素認証（Multi-Factor Authentication、MFA）は、本人の確認に性質の異なる2つ以上の要素を併用する仕組みです。例えばメールへのログインでパスワードを入力した後、利用者が所持するスマートフォンの認証アプリに表示されるコードを入力します。認証アプリは、ログイン時に入力する認証用のコードを表示するアプリです。パスワードだけが漏えいしても、それだけではログインしにくくなります。銀行のキャッシュカードと暗証番号のように、所持と知識という異なる要素を併用する考え方です。

多要素認証と混同されやすい、ログインの仕組みにシングルサインオンがあります。シングルサインオンは一度のログインで複数のサービスを利用しやすくする仕組みです。本人を確認する要素の組み合わせを指す多要素認証とは異なります。両者は併用でき、シングルサインオンのログイン時に多要素認証を求める構成もあります。

異なる要素の組合せ

多要素認証の要素は利用者の知識、所持するもの、本人の身体的な特徴に分類されます。異なる分類の要素を併用したときに、多要素認証になります。

要素	例
知識	パスワード、暗証番号
所持	登録したスマートフォンの認証アプリ、セキュリティキー
生体	指紋、顔

パスワードと別のパスワードを入力するだけでは、どちらも知識の要素です。確認画面が2つあっても、多要素認証にはなりません。一方、端末内の鍵を利用するために端末の暗証番号や指紋を求める方式は、鍵の所持と知識または生体を併用します。

指紋や顔などの生体情報を利用する場合にも条件があります。生体情報は単独で認証に利用せず、所持する認証器と併用します。

パスキーはワンタイムコードの手入力より偽サイト経由の不正ログインへの耐性が高い

パスワードを入力する代わりに、端末などに保存した本人用の認証データでログインする方式をパスキーと呼びます。パスキーはサービスごとに作成されて、登録先のサービスへのログインにだけ使用できます。

偽のログイン画面へ誘導して認証情報を入力させる攻撃をフィッシングと呼びます。誘導されても、攻撃者に本物のサービスへログインさせない性質が、フィッシングへの耐性です。

認証アプリが生成するコードやSMS（Short Message Service）で受信するコードには、一度だけ利用できるワンタイムコードがあります。ワンタイムコードをパスワードと併用すると、パスワードだけの場合より不正なログインを防止しやすくなります。

ただし、認証アプリが生成したワンタイムコードやSMSで受信したものを手入力する方式は、フィッシング耐性のある方式には該当しません。偽のログイン画面に入力したパスワードとコードは攻撃者が取得します。攻撃者はそれらをコードが有効なうちに正規サービスへ入力し、ログインする場合があります。

SMSには、さらに電話番号の移転やSIMの変更を悪用されるリスクもあります。電話番号を不正に移転されると、SMSのコードが攻撃者の端末で受信される場合があります。認証アプリのコードは電話番号を経由しないため、このSMS固有のリスクはありません。

SMSにはこの固有のリスクがあるため、パスキーを利用できないサービスでは認証アプリのコードを優先して選択します。サービスが認証アプリに対応していない場合は、SMSのコードを利用します。

方式を選択した後は、その運用も確認します。認証アプリなら、コードを表示する端末を誰が管理し、紛失時にどう再登録するかを確認します。SMSなら、コードを受信する電話番号を誰が管理し、番号の変更時にどう更新するかを確認します。

パスキーでは、ブラウザやOSが登録先のサイトやアプリとの対応を確認するため、登録先と対応しないドメインを使用する偽サイトでは正規サービス用のパスキーを利用できません。

パスキーの利用時に端末の暗証番号や指紋などの確認が必要な構成なら、パスキーを保存した端末の所持と、知識または生体の組み合わせになります。実際に確認が求められるかは、サービスと端末の設定で確認します。

パスキーを登録しても、パスワードだけでログインできる方法が存在すれば、攻撃者はその方法を攻撃の対象にできます。復旧などパスキーで保護されていない方法も含めて設定を確認します。

パスキーを利用できない場合も、まず利用可能な多要素認証を有効にし、フィッシングへの耐性がある方式へ段階的に移行します。米国の政府機関CISA（Cybersecurity and Infrastructure Security Agency）も、フィッシングへの耐性がある方式を目標にしつつ、どの多要素認証も未設定より安全だとしています。

フィッシングへの耐性がある方式でログインしても、ログインした後のリスクは存在します。ログインに成功するとサービスが発行し、以後の操作のたびに提示することでログイン済みであることを示す文字列を、トークンと呼びます。サービスはトークンを保有する相手をログイン済みとみなすため、トークンが不正に取得されると、攻撃者が追加の認証なしに操作できる場合があります。

攻撃者のアプリにメールやファイルへのアクセスを許可させる、不正なアプリへの権限許可も、ログイン後のリスクです。

多要素認証をどのアカウントから設定するか

一度にすべてへ設定できない場合は、シングルサインオンのアカウント、メール、管理者、決済用アカウント、機密情報にアクセスするアカウントから優先します。いずれも侵害されたときの影響が重大なアカウントです。

シングルサインオンでは、事業者のクラウド上のソフトウェアをネットワーク経由で利用するSaaS（Software as a Service）の複数へ、同じ認証情報でログインします。この認証情報が窃取されると、攻撃者も同じSaaSへログインできる可能性があります。

パスワードの再設定にメールを利用するサービスは、登録されたメールアドレスへ再設定用のリンクやコードを送信し、それを受信した人を本人とみなします。メールアカウントへ不正にログインした攻撃者がそのサービスで再設定を申請すると、リンクやコードはそのメールアカウントに送信されます。攻撃者はそれを閲覧して再設定画面で使用し、そのサービスで多要素認証を設定していなければ、本人とみなされてパスワードを変更できる場合があります。

管理者アカウントは利用者の設定や権限を変更できるので、侵害の影響が利用者全体に及ぶ可能性があります。決済用アカウントの侵害は不正な支払いに、機密情報にアクセスするアカウントの侵害は情報の流出を招く可能性があります。

シングルサインオンによる共通ログインでは、多要素認証を任意ではなく必須の設定にします。

SaaSによっては、共通ログインとは別に、そのSaaS専用のIDとパスワードでログインする個別ログインも利用できます。個別ログインが存在する場合は、業務で使用しない個別ログインを停止し、必要な個別ログインにも多要素認証を設定します。

管理者は、多要素認証を設定できないサービスを例外として一覧で管理します。多要素認証をまだ登録していない利用者のアカウントや、アカウントの復旧手段から、必須にした多要素認証を迂回してログインできないかも確認します。残りのアカウントにも権限や取扱対象の情報に応じて順次設定します。

端末を紛失したときのアカウント復旧と本人確認

端末の紛失や機種変更に備え、予備の認証手段と復旧手順を先に準備します。例えばGoogle Workspaceは管理者用の予備のセキュリティキーやバックアップコードを案内しています。登録できる予備手段やコードの発行権限はサービスごとに確認し、予備手段は普段使う端末とは別の安全な場所に保管します。

復旧を依頼された担当者は、申告された連絡先だけを信用せず、登録済みの連絡先へ改めて連絡するなど、本人確認をしてから再登録を支援します。連絡先が紛失した端末や侵害されたメールに依存していないかも確認し、必要に応じて別の手段や複数の確認方法を併用します。

本人確認の後は、紛失した認証手段の無効化と、新規の認証手段の登録も確認します。本人確認を省略して多要素認証を解除できると、通常のログインが強固でも復旧手続きが弱点になります。

組織で導入するときは、多要素認証に対応するサービスプランの費用と、対応する端末や認証用機器の購入費用を見積もります。利用者への登録案内、機種変更時の再登録、問合せや復旧への対応について、担当者の工数も見積もります。