フィッシングに強い認証へ。パスキー移行を棚卸し・段階展開・復旧で分けて考える

編集部の実務提案

パスキーは「共有秘密を持たない」認証である

パスキーはFIDO標準に基づく認証資格情報であり、公開鍵暗号を使う。端末側に秘密鍵、サービス側に公開鍵を置き、サインインのたびにサービスから送られるチャレンジへ秘密鍵で署名して返す。パスワードのように「利用者とサービスが同じ秘密を共有する」構造ではないため、サービス側の情報漏えいがそのまま認証の突破につながりにくい。

もう一つの要点はオリジンとの結び付きである。Microsoftの説明では、パスキーはオリジンに結び付いた公開鍵暗号を使い、資格情報が悪意ある相手へ再生されたり共有されたりすることを防ぐ。登録した正規のサイトやアプリでしか使えない鍵であるため、そっくりの偽サイトに誘導されても、そこで署名が成立しない。これが「フィッシングに強い」と言われる技術的な理由である。

FIDO Allianceも、パスキーはパスワードと違い、フィッシングに強く、常に強固で、共有秘密が存在しないよう設計されていると説明する。利用者は端末のロック解除と同じ操作、生体認証やPIN、パターンでサインインを承認する。覚える秘密が消えることは、利用者の利便性と安全性を同時に上げる。

従来の多要素認証との違いを整理しておく。SMSコードやメールコード、さらにはアプリのプッシュ承認も、入力や承認の行為そのものは中継され得る。パスキーは「何を知っているか」ではなく「正しい相手に対してだけ署名できる鍵を持っているか」を問う。移行の議論は、要素の数を増やす話から、盗まれない要素へ置き換える話へ変える必要がある。

もちろん、パスキーが万能なわけではない。端末そのものの盗難、端末ロックの弱さ、復旧フローの甘さは残る論点である。だからこそ本稿では、仕組みの理解だけで終わらせず、復旧と運用までを移行設計に含める。強い認証方式ほど、失ったときの手続きが攻撃の入口になりやすい。

運用チームの視点では、この仕組みの違いは障害対応にも現れる。パスワード方式では「漏れたかもしれない」という疑いだけで全員にリセットを強いる場面があるが、パスキーでは漏れる共有秘密自体がないため、対応は端末と鍵の単位に絞れる。インシデント時の影響範囲が小さくなることも、移行を正当化する実務上の理由になる。

なお、パスキーの登録情報は「どの端末・どのプロバイダに鍵があるか」という新しい棚卸し対象を生む。移行後は、利用者ごとの登録済み認証器の一覧を把握できる状態にしておくこと。端末紛失時の影響範囲は、この一覧がなければ即座に答えられない。

出典：[1][2]

編集部の実務提案

最初にやるのは、認証方式の棚卸しである

移行の出発点は、新しい方式の有効化ではなく、現在の認証の棚卸しである。どのシステムに、どの方式で入っているか。パスワードのみ、SMSコード併用、認証アプリ併用、セキュリティキー利用、といった現状をシステム単位で並べる。棚卸しがないままパスキーを有効化しても、弱い経路が残り続ける。

棚卸し表には、対象システム、利用者範囲、現在の認証方式、管理者権限の有無、外部公開の有無、復旧方法を記録する。特に管理者権限を持つアカウントと、外部から到達できるシステムは、リスクの観点で先に色分けしておく。攻撃者が狙うのは全アカウントではなく、権限と到達可能性が重なる一部である。

棚卸しでは「例外」も拾う。工場の共用端末、委託先の作業アカウント、古い業務アプリのために残した互換設定、退職者対応のために残した予備経路。例外は移行計画から漏れやすく、移行完了後もフィッシング可能な入口として残る。例外を禁止するのではなく、棚卸し表に理由と期限付きで明記することが先である。

棚卸しの副産物として、使われていないアカウントや、所有者不明の管理者アカウントが見つかることも多い。認証方式の移行は、アカウント自体の棚卸しとセットで進めると効果が大きい。誰のものか分からないアカウントに強い認証を付けても、運用の穴は塞がらない。

棚卸しの結果は、移行の優先順位付けに直結する。外部公開×管理者権限×現在の方式が弱い、という交点から着手順を決める。全社一斉の移行を目指すより、リスクの高い交点から段階的に潰す方が、小さな運用チームでも完走できる。

棚卸しの進め方として、ID基盤の管理画面で方式別の登録状況を出力し、業務システム側の台帳と突き合わせる方法が確実である。基盤側だけではカバーできない、基盤を経由しない独自ログインを持つシステムが必ず混ざる。その独自ログインの洗い出しこそが棚卸しの本丸であり、発見したものは台帳に「移行対象外の理由」まで含めて記録しておく。

棚卸しの表は、経営層への説明資料としても使える。どの経路がどれだけ弱いかが見える形になっていれば、移行の優先順位と予算の根拠は一目で伝わる。技術的な正しさを、組織の意思決定に使える形へ変換するのも、棚卸しの役割である。

出典：[1]

編集部の実務提案

同期型とデバイス固定型を使い分ける

パスキーには大きく2種類ある。Microsoftの整理では、秘密鍵が単一の物理デバイスに作られ外に出ないデバイス固定型と、暗号化された秘密鍵がクラウドのパスキープロバイダ経由で同期される同期型である。前者の例がFIDO2セキュリティキーや認証アプリ内のパスキー、後者の例がOS標準の資格情報マネージャーに同期されるパスキーである。

使い分けの軸は、利用者の権限と業務の規制水準である。Microsoftは、高度に規制された業界や高い権限を持つ利用者にはFIDO2セキュリティキーを推奨する。一方で、一般の利用者には同期型が利便性と低コストのバランスで現実的な選択肢になると述べている。全員に同じ型を配るのではなく、権限で分けるのが設計の基本である。

構成証明（アテステーション）の扱いも分岐点である。Microsoft Entra IDでは、パスキープロファイル単位で構成証明を強制でき、強制した場合はデバイス固定型のみが許可され、同期型は除外される。どの認証器で作られた鍵かを確認したい管理者向けの領域では、構成証明を有効化する代わりに同期型を諦める、というトレードオフを意識して決める。

同期型の利点は、登録と利用の成功率の高さにも表れる。Microsoftは、消費者向けアカウントでの学習として、同期型パスキーの登録成功率が99%に達し、サインインもパスワードと従来型MFAの組み合わせより速いと紹介している。数値は環境により異なるが、移行の摩擦が小さいことは、展開計画の前提として置ける。

決め方をまとめると、管理者と高権限者はデバイス固定型（できれば予備キーとセット）、一般利用者は同期型を既定とし、共用端末など端末が固定される業務ではデバイス固定型を検討する、という三層が扱いやすい。型の選択はセキュリティの好みではなく、権限・端末・復旧のしやすさから決める。

型の選択では、端末の買い替えサイクルも考慮したい。同期型は新しい端末へ資格情報が引き継がれるため、機種変更の多い現場での摩擦が小さい。逆にデバイス固定型は、端末やキーを替えるたびに再登録の手順が発生する。権限の高い少人数にはその手間を受け入れてもらい、人数の多い一般層には同期型で摩擦を下げる、という配分が現実に合う。

費用の観点も使い分けを後押しする。セキュリティキーは人数分の購入と予備の在庫管理が発生し、同期型は既存の端末とOSのアカウント基盤に乗るため追加費用が小さい。全員を最も強い型に寄せる設計は、費用と運用の両面で破綻しやすい。強さの配分は、リスクの配分と一致させるのが原則である。

出典：[1][2]

編集部の実務提案

段階展開は「管理者→希望者→全員」の順で進める

有効化の操作自体は短いが、展開の順序を誤ると問い合わせが集中し、プロジェクトが止まる。現実的な順序は三段階である。まず情シスと管理者アカウントで先行運用し、次に希望者とITリテラシーの高い部門へ広げ、最後に全員へ展開する。各段階で登録率と失敗理由を集計し、次の段階の案内に反映させる。

先行段階の目的は、技術検証よりも「つまずきポイントの収集」である。対象OSやブラウザの組み合わせ、古い端末での挙動、共用端末での登録可否、ヘルプデスクへの質問の型。ここで得た知見をFAQと案内文に落としてから広げると、全社展開時の問い合わせは大きく減る。

段階ごとに「従来方式をいつ無効化するか」も決めておく。パスキーを追加しただけでは、攻撃者は弱い従来方式を引き続き狙える。登録が行き渡った段階で、SMSコードのような中継可能な方式を段階的に外し、最終的にはフィッシングに強い方式のみを残す。追加と削除は一つの計画として扱う。

展開の進捗は、登録率だけでは測れない。実際にパスキーでサインインしている割合、従来方式でのサインインが残っているアカウント数、失敗してパスワードに戻った回数。これらを段階の出口条件に置くと、「配ったが使われていない」状態を早期に発見できる。

途中で止めない工夫も要る。移行期間が長引くと、先行者の知識が風化し、案内が陳腐化する。段階ごとに期間と出口条件を先に決め、経営層や部門長への進捗報告を挟む。認証の移行はセキュリティ施策であると同時に、全社員の日常操作を変える変更管理である。

段階展開では、案内の出し方も段階に合わせる。先行者には詳細な手順とフィードバック窓口を、一般展開では短い手順とFAQへのリンクを、という具合に情報量を変える。全員に同じ長文を送る案内は読まれず、結果として問い合わせが増える。段階ごとに「前段階で実際に来た質問」を先回りして潰すことが、展開速度を決める。

出典：[1]

編集部の実務提案

復旧フローが移行の成否を決める

パスキー移行で最も設計が要るのは、端末を失くした日の手続きである。スマートフォンの紛失、PCの故障、セキュリティキーの置き忘れ。利用者が正規の手順で素早く復旧できなければ、現場は例外対応で従来方式へ戻し、移行そのものが形骸化する。

復旧の原則は二つある。一つ目は、復旧の本人確認を、通常のサインインより弱くしないこと。電話口頭だけでの即時リセットは、ソーシャルエンジニアリングの入口になる。本人確認の要素、上長の承認、対面確認の要否を、権限の大きさに応じて決めておく。二つ目は、一時的な代替手段に有効期限を付けること。期限のない一時手段は、恒常的な抜け道になる。

予備の鍵も先に配る。特にデバイス固定型を使う管理者には、予備のセキュリティキーを登録させ、保管場所を記録する。Microsoftも、セキュリティキーは紛失時のアカウント復旧に伴うヘルプデスク負荷が増え得る点に触れている。予備の登録を「任意」ではなく展開チェックリストの必須項目にするだけで、紛失時の混乱は大きく減る。

復旧の記録も残す。いつ、誰が、どの確認を経て復旧したか。復旧は攻撃者にとっても魅力的な経路であるため、復旧イベントは監視対象に含め、通常と異なる時間帯や頻度の復旧を検知できるようにする。強い認証と強い復旧はセットで設計する。

利用者への案内では、紛失時に「まず何をするか」を1枚にまとめる。連絡先、業務への影響範囲、代替手段の期限。移行の案内文に復旧の章を最初から含めておくことが、現場の不安を下げ、例外運用の乱発を防ぐ。

復旧手順は、作っただけでは不十分で、机上訓練が要る。情シス担当が「利用者の端末紛失」を演じて復旧を1回通しで実施し、詰まる箇所と本人確認の証跡の残り方を確認する。訓練で見つけた曖昧さは、そのまま本番の混乱になる。移行の各段階の出口条件に、復旧訓練の実施を含めておくとよい。

復旧と並んで重要なのが、登録そのものの保護である。新規端末へのパスキー追加が弱い確認だけで通る設計では、攻撃者はサインインではなく登録を狙う。新しい認証器の登録には既存の強い認証を要求し、登録イベントを利用者本人へ通知する。この「登録の警戒」が、移行後の運用で効いてくる。

出典：[1][2]

編集部の実務提案

残す方式と外す方式を、ポリシーで固定する

移行が進んだら、利用できる認証方式の範囲をポリシーで固定する。誰がどの方式を使えるか、どの方式がどのシステムで必須かを、設定として明示する。案内文だけに頼る運用は、担当者の異動や例外対応の積み重ねで静かに崩れる。

固定の対象は三層ある。利用者層（管理者、一般、委託先）、方式層（パスキー、認証アプリ、SMS、パスワードのみ）、システム層（外部公開、管理画面、基幹システム）。層の掛け算で必須方式を決め、表として公開しておくと、監査や新規システム導入時の判断が速くなる。

例外はポリシーの外ではなく中に入れる。どうしても従来方式が必要な業務があるなら、対象アカウント、理由、期限、代替の監視強化を条件に例外として登録する。期限が来たら自動で見直す。例外を可視化しておくことが、例外の常態化を防ぐ最も実効的な方法である。

委託先や外部協力者のアカウントも同じ表で扱う。自社員より管理が緩くなりがちな領域であり、契約更新のタイミングで方式の要件を確認する。強い認証への移行は、自社の境界の内側だけで完結しない。

ポリシーは作って終わりではなく、プラットフォーム側の進化に合わせて見直す。パスキーの対応範囲や構成証明の扱いは今も広がっている。四半期ごとの見直しで、新しく使えるようになった制御を例外の解消に充てる、という循環を作ると、ポリシーは徐々に締まっていく。

ポリシーの固定では、設定変更の権限も併せて決める。認証方式の緩和は強い権限でしか行えないようにし、変更はチケットとひも付ける。設定の変更履歴が残る状態にしておけば、監査対応だけでなく「いつの間にかSMSが再度有効になっていた」という静かな後戻りにも気付ける。

出典：[1]

編集部の実務提案

移行後は、サインインの内訳を監視する

移行の完了は「全員が登録した日」ではなく、「従来方式でのサインインが想定どおり減った状態が続くこと」で判断する。監視する指標は、方式別のサインイン件数、パスキー登録率と実利用率、失敗率、復旧件数、例外アカウントの利用状況である。

異常の兆候も方式別に見える。特定のアカウントで従来方式のサインインが急増する、復旧申請が特定の時間帯に集中する、登録済みのはずの利用者が失敗を繰り返す。これらは、攻撃の試行か、運用の不整合かのどちらかであり、方式別の内訳がなければ発見できない。

ヘルプデスクの問い合わせも移行の健全性指標である。登録手順の質問が多い段階と、紛失・機種変更の質問が多い段階では、必要な改善が違う。問い合わせを分類して集計し、案内文とFAQを更新する作業を、移行後の定常業務に組み込む。

最後に、移行の効果を言語化しておく。フィッシング耐性のある方式でカバーされるアカウントの割合、パスワードリセット件数の推移、サインイン成功率の変化。効果が見える形で残っていれば、次のセキュリティ投資の判断材料になり、移行を後戻りさせない根拠にもなる。

認証は一度変えれば終わる設定ではない。端末の更新、利用者の入退社、プラットフォームの仕様変更のたびに、棚卸しとポリシーは少しずつずれる。そのずれを監視で拾い続けることが、パスキー移行を一過性のプロジェクトで終わらせない条件である。

監視の定着には、見る場所と頻度を決めることが先である。月次の定例で方式別サインインの内訳を確認し、四半期ごとに棚卸し表と突き合わせる。小さな組織ほど、立派なダッシュボードより「決まった日に誰かが必ず見る」という習慣の方が効く。監視項目は少なく、継続できる形に絞るのがよい。

最後に、移行の記録を残す。棚卸し表、段階ごとの判断、例外の一覧、ポリシーの版数。これらがあれば、担当者が替わっても移行の意図は引き継げる。認証基盤は触る頻度が低い分、意図の記録がないと数年後に「なぜこの設定なのか」が誰にも分からなくなる。運用の文書化は、移行プロジェクトの最後の成果物である。

出典：[1][2]