デジタルトランスフォーメーション（DX）の進展に伴い、企業が守るべき情報資産の境界線は広がり続けています。その一方で、サイバー攻撃の手口は高度化し、特にフィッシング詐欺においては、従来のパスワード運用や従業員のセキュリティ意識だけに頼った対策では防御しきれないのが実情です。
本記事では、セキュリティとユーザビリティという、これまでトレードオフの関係にあった二つの課題を解決する次世代の認証技術「パスキー（Passkeys）」について解説します。仕組みや導入のメリット、運用上の課題への対処法を含め、企業が検討すべき認証基盤のあり方を考える一助になれば幸いです。
長年にわたり、企業セキュリティの基本は「IDとパスワード」でした。しかし、クラウドサービスの普及やリモートワークの常態化により、その限界が顕在化しています。
パスワード認証の根本的な課題は、「秘密の情報（パスワード）をサーバーとユーザーの間で共有し、都度入力する必要がある」という点です。攻撃者はこの「入力する瞬間」を狙います。近年増加しているAiTM（Adversary-in-the-Middle：中間者攻撃）では、正規のサイトとユーザーの間に攻撃者が介在し、入力されたパスワードと多要素認証（MFA）のワンタイムコードをリアルタイムで窃取します。
このように、正規の認証プロセス自体を巧みに悪用する攻撃に対しては、パスワードの複雑化や定期変更といった従来の対策は効果を発揮しづらくなっています。
また、パスワード管理は生産性の観点でも課題となります。複雑なパスワードの設定を強制すれば、従業員はログインに時間を取られ、忘れた際にはヘルプデスクへのリセット依頼が発生します。これらは、本来の業務に充てるべき時間を奪う「見えないコスト」となって組織の負担を増大させています。
これらの課題を解決するのが、「パスキー」です。従来の「記憶（パスワード）」に頼る認証から、「所持（デバイス）」と「生体（指紋・顔）」または「記憶（PINコードなど）」を組み合わせた認証への転換を意味します。
PINコードはデバイス内での本人確認（ロック解除）に用いられるもので、サーバーには送信されません（従来のパスワードとは異なります）。
パスキーは、「公開鍵暗号方式」を認証に応用した技術です。ユーザー側のデバイスやパスキープロバイダーで「秘密鍵」を安全に管理し、サービスのサーバー側には「公開鍵」のみを登録します。認証時には、サーバーから送られてくる課題（チャレンジ）に対し、秘密鍵を用いて署名を作成し、送り返します。この際、ユーザーの本人確認として、デバイスのロック解除（生体認証やPINコード）が求められます。
重要なのは、認証時に秘密鍵そのものを認証先サービスへ送信する必要がなく、サービス側には公開鍵が保存されるという点です。これにより、サービス側の認証情報データベースが侵害された場合でも、攻撃者がそのままログインに再利用できるパスワード相当の秘密情報が漏洩するリスクを大幅に低減できます。
パスキーがフィッシングに強い最大の理由は、「オリジンバインディング（ドメインとの紐付け）」という機能にあります。パスキーは作成時に登録されたWebサイトのドメイン（URL）と厳密に紐付けられます。そのため、ユーザーが本物そっくりの偽サイト（フィッシングサイト）に誘導されたとしても、ブラウザやOSがドメインの不一致を検知し、認証プロセスを停止します。
「人が偽サイトを見抜く」のではなく、「システムが不一致を判断して認証させない」仕組みであるため、人的ミスによる事故を未然に防ぐことが可能です。
パスキーの導入は、セキュリティ強化だけでなく、業務環境の改善にも寄与します。
前述の通り、パスキーはフィッシングサイトでは動作しません。また、認証情報（秘密鍵）がネットワーク上を流れないため、通信経路での窃取も困難です。これにより、アカウント乗っ取りのリスクを大幅に低減し、インシデント対応コストを削減できます。
生体認証等を用いたスムーズなログインが可能になるため、従業員はパスワード入力の手間から解放されます。1日に何度も行うログイン作業が数秒で完了することで、業務の開始がスムーズになり、従業員体験（EX）の向上につながります。
「パスワードを覚える」「定期的に変更する」「安全に管理する」といった従業員の負担がなくなります。これにより、パスワードの使い回しや、付箋へのメモといったシャドーIT（不適切な管理）のリスクも自然と解消されます。
パスワードレス化が進めば、「パスワードを忘れた」「ロックされた」といった問い合わせ対応が不要になります。ヘルプデスク業務の工数を削減し、IT部門のリソースをより戦略的なプロジェクトへ配分することが可能になります。
パスワードレス化を進めることで、「パスワードを忘れた」「パスワードがロックされた」といった従来型の問い合わせを減らせる可能性があります。ヘルプデスク業務の工数削減につながる一方、デバイス紛失や端末交換、パスキーの再登録などに備えたリカバリー手順の整備は必要です。
企業導入を検討する際、パスキーには大きく分けて2つの運用形態があることを理解しておく必要があります。
|
特徴 |
同期パスキー (Synced Passkeys) |
デバイス固定パスキー (Device-Bound Passkeys) |
|
概要 |
クラウド経由でデバイス間で同期される鍵 |
特定のハードウェアに固定され、コピー不可の鍵 |
|
主な媒体 |
・iPhone (iCloud) ・Android (Google PW Manager) |
・YubiKey等のセキュリティキー ・Windows Hello(一部) |
|
メリット |
機種変更時の移行が容易で、利便性が高い |
秘密鍵の複製が物理的に不可能なため、高強度の保護 |
|
適した用途（例） |
一般従業員の業務用スマホ・PC |
特権ID管理者、スマホ持ち込み不可エリア、共有PC |
上記の特性を踏まえ、BtoB環境での具体的な運用課題への対処法を解説します。
Apple（iCloudキーチェーン）やGoogle（Googleパスワードマネージャー）が提供する「同期パスキー」は、デバイスを紛失・買い替えた際でもクラウド経由で復旧できるため、管理コスト削減に寄与します。
一方で、同期パスキーではPasskey Providerのアカウントや同期・アカウント回復の仕組みもセキュリティ上重要になります。これらのアカウントや回復プロセスが侵害された場合、同期されたパスキーが不正利用されるリスクがあります。そのため、同期パスキーを社用で認める場合は、Passkey Provider側の多要素認証（MFA）だけでなく、端末保護、同期時の暗号化、アカウント回復方法なども確認し、自社のセキュリティポリシーに適したプロバイダーや運用方法を選択することが重要です。
コールセンター、工場、金融機関の営業店など、以下のような環境ではスマートフォンの利用が難しい場合があります。
こうした環境では、YubiKeyなどに代表される物理セキュリティキー（デバイス固定パスキー）が有力な選択肢になります。
物理キーであれば、認証に使用する秘密鍵をPC本体に保存する必要がありません。ユーザーが自身のセキュリティキーを持ち運び、USBやNFCなどで対応端末へ接続し、タッチやPIN入力などによって認証できます。これにより、共有端末などでもユーザーごとの認証情報をセキュリティキー側で管理しながら、安全なログイン環境を構築できます。
全ての社内システムが即座にパスキーに対応するわけではありません。
現実的な導入ステップとしては、まずIdP（IDプロバイダー：SeciossLink, Microsoft Entra IDなど）でSSO（シングルサインオン）基盤でパスキー対応を行い、社内システムへの入り口をパスワードレス化する方法がスムーズです。
パスキーは、FIDO AllianceやW3Cの標準技術を基盤とし、Apple、Google、Microsoftをはじめとする主要プラットフォーマーが対応・普及を進めている認証技術です。
企業での導入にあたっては、利便性を重視して「スマートフォンの同期パスキー」を採用するのか、あるいはセキュリティと共有利用を重視して「物理セキュリティキー」を採用するのか、あるいは部署によって使い分けるのか。「同期型」と「固定型」の特性を理解し、自社のポリシーに合わせた選択を行うことが成功の鍵となります。まずは情報システム部門内での試験導入から始め、パスワード依存からの脱却に向けた一歩を踏み出してみてはいかがでしょうか。