フィッシング対策と利便性を両立する「パスキー」とは。企業がパスワードレス認証へ移行すべき理由

デジタルトランスフォーメーション（DX）の進展に伴い、企業が守るべき情報資産の境界線は広がり続けています。その一方で、サイバー攻撃の手口は高度化し、特にフィッシング詐欺においては、従来のパスワード運用や従業員のセキュリティ意識だけに頼った対策では防御しきれないのが実情です。

本記事では、セキュリティとユーザビリティという、これまでトレードオフの関係にあった二つの課題を解決する次世代の認証技術「パスキー（Passkeys）」について解説します。仕組みや導入のメリット、運用上の課題への対処法を含め、企業が検討すべき認証基盤のあり方を考える一助になれば幸いです。

長年にわたり、企業セキュリティの基本は「IDとパスワード」でした。しかし、クラウドサービスの普及やリモートワークの常態化により、その限界が顕在化しています。

パスワード認証の根本的な課題は、「秘密の情報（パスワード）をサーバーとユーザーの間で共有し、都度入力する必要がある」という点です。攻撃者はこの「入力する瞬間」を狙います。近年増加している「AiTM（Adversary-in-the-Middle：中間者攻撃）」と呼ばれる手口では、正規のサイトとユーザーの間に攻撃者が介在し、入力されたパスワードと多要素認証（MFA）のワンタイムコードをリアルタイムで窃取します。

このように、正規の認証プロセス自体を巧みに悪用する攻撃に対しては、パスワードの複雑化や定期変更といった従来の対策は効果を発揮しづらくなっています。

また、パスワード管理は生産性の観点でも課題となります。複雑なパスワードの設定を強制すれば、従業員はログインに時間を取られ、忘れた際にはヘルプデスクへのリセット依頼が発生します。これらは、本来の業務に充てるべき時間を奪う「見えないコスト」となって組織の負担を増大させています。

これらの課題を解決するのが、「パスキー」です。従来の「記憶（パスワード）」に頼る認証から、「所持（デバイス）」と「生体（指紋・顔）」または「記憶（PINコード※など）」を組み合わせた認証への転換を意味します。

※PINコードはデバイス内での本人確認（ロック解除）に用いられるもので、サーバーには送信されません（従来のパスワードとは異なります）。

パスキーは、「公開鍵暗号方式」を認証に応用した技術です。ユーザーの手元にあるデバイス（スマートフォンやPC）内に「秘密鍵」を生成・保管し、サービスのサーバー側には「公開鍵」のみを登録します。認証時には、サーバーから送られてくる課題（チャレンジ）に対し、デバイス内の秘密鍵を用いて署名を作成し、送り返します。この際、ユーザーの本人確認として、デバイスのロック解除（生体認証やPINコード）が求められます。

重要なのは、「秘密鍵そのものは通信経路に流れず、サーバーにも保存されない」という点です。これにより、サーバー攻撃によるパスワード漏洩のリスクを構造的に排除できます。

パスキーがフィッシングに強い最大の理由は、「オリジンバインディング（ドメインとの紐付け）」という機能にあります。パスキーは作成時に登録されたWebサイトのドメイン（URL）と厳密に紐付けられます。そのため、ユーザーが本物そっくりの偽サイト（フィッシングサイト）に誘導されたとしても、ブラウザやOSがドメインの不一致を検知し、認証プロセスを停止します。

「人が偽サイトを見抜く」のではなく、「システムが不一致を判断して認証させない」仕組みであるため、人的ミスによる事故を未然に防ぐことが可能です。

パスキーの導入は、セキュリティ強化だけでなく、業務環境の改善にも寄与します。

1. フィッシングおよび認証情報窃取リスクの低減

前述の通り、パスキーはフィッシングサイトでは動作しません。また、認証情報（秘密鍵）がネットワーク上を流れないため、通信経路での窃取も困難です。これにより、アカウント乗っ取りのリスクを大幅に低減し、インシデント対応コストを削減できます。

2. ログイン時間の短縮とUX向上

生体認証等を用いたスムーズなログインが可能になるため、従業員はパスワード入力の手間から解放されます。1日に何度も行うログイン作業が数秒で完了することで、業務の開始がスムーズになり、従業員体験（EX）の向上につながります。

3. パスワード管理負担の解消

「パスワードを覚える」「定期的に変更する」「安全に管理する」といった従業員の負担がなくなります。これにより、パスワードの使い回しや、付箋へのメモといったシャドーIT（不適切な管理）のリスクも自然と解消されます。

4. IT部門のヘルプデスク負荷軽減

パスワードレス化が進めば、「パスワードを忘れた」「ロックされた」といった問い合わせ対応が不要になります。ヘルプデスク業務の工数を削減し、IT部門のリソースをより戦略的なプロジェクトへ配分することが可能になります。

企業導入を検討する際、パスキーには大きく分けて2つの運用形態があることを理解しておく必要があります。

上記の特性を踏まえ、BtoB環境での具体的な運用課題への対処法を解説します。

1. 「同期パスキー」運用時のセキュリティ要件

Apple（iCloudキーチェーン）やGoogle（Googleパスワードマネージャー）が提供する「同期パスキー」は、デバイスを紛失・買い替えた際でもクラウド経由で復旧できるため、管理コスト削減に寄与します。

しかし、その安全性は「同期を行う元のアカウント（Apple IDやGoogleアカウント）」の堅牢性に依存します。もし攻撃者が元のアカウントを乗っ取ってしまえば、攻撃者のデバイスにパスキーが同期され、不正利用されるリスクがあります。

そのため、同期パスキーを社用で認める場合は、プラットフォーム側のアカウント（Apple ID/Googleアカウント）自体に多要素認証（MFA）を設定し、決してパスワードのみの運用にしないというポリシーの徹底が不可欠です。

2. 共有端末やスマホ持ち込み禁止エリアでの対応

コールセンター、工場、金融機関の営業店など、以下のような環境ではスマートフォンの利用が難しい場合があります。

• ・1台のPCを複数人で共有している（個人の秘密鍵をPCに残したくない）
• ・セキュリティエリアでスマートフォンの持ち込みが禁止されている

こうした環境では、YubiKeyなどに代表される「物理セキュリティキー（デバイス固定パスキー）」の配布が最適解です。

物理キーであれば、鍵はハードウェアの中に隔離されており、USBポートに挿してタッチするだけで認証が完了します。PC本体に情報は残らず、個人がキーを持ち歩くことで「どの端末でも、自分だけの鍵で安全にログイン」が可能になります。

3. 既存システムとの共存（ハイブリッド運用）

全ての社内システムが即座にパスキーに対応するわけではありません。

現実的な導入ステップとしては、まずIdP（IDプロバイダー：SeciossLink, Microsoft Entra IDなど）でSSO（シングルサインオン）基盤でパスキー対応を行い、社内システムへの入り口をパスワードレス化する方法がスムーズです。

[SeciossLinkの製品資料をダウンロードする]

パスキーは、Google、Apple、Microsoftなどのプラットフォーマーが標準化を進める、確かな技術トレンドです。企業での導入にあたっては、利便性を重視して「スマートフォンの同期パスキー」を採用するのか、あるいはセキュリティと共有利用を重視して「物理セキュリティキー」を採用するのか、あるいは部署によって使い分けるのか。「同期型」と「固定型」の特性を理解し、自社のポリシーに合わせた選択を行うことが成功の鍵となります。まずは情報システム部門内での試験導入から始め、パスワード依存からの脱却に向けた一歩を踏み出してみてはいかがでしょうか。

[SeciossLinkのFIDO認証を知る]