```table-of-contents title: minLevel: 0 maxLevel: 0 includeLinks: true ``` - - [noteで書く](https://note.mu/intent/post?url=https%3A%2F%2Fjapan.zdnet.com%2Farticle%2F35235516%2F&ref=https%3A%2F%2Fjapan.zdnet.com%2Farticle%2F35235516%2F&hashtags=ZDNET) - - 印刷する - - メールで送る - テキスト - HTML - 電子書籍 - PDF - - ダウンロード - テキスト - 電子書籍 - PDF - - クリップした記事をMyページから読むことができます 　これまでのパスキーに関する議論では、Relying Party（依拠当事者）」と呼ばれるウェブサイトやアプリの運営者が、従来のセキュリティが低いユーザー名とパスワードによる認証方式に代わって、パスキーによるサインイン機能を提供しているかどうかを把握することの難しさについて述べてきた。 　Apple、Google、Microsoftといった世界的なテクノロジー企業の一部は、パスワードレス認証の手段としてパスキーをすでにサポートしている。これらの大手企業が連携することで、数十億人規模のグローバルユーザーに対して、フィッシングやスミッシングに強い認証技術を広く普及させられるだろう。しかしながら、現時点では多くのウェブサイトやアプリがこの流れに追随しておらず、パスキーの導入は限定的な状況にとどまっている。果たして、パスキーが広く普及し、ほとんどの依拠当事者がそれをサポートするようになり、さらに重要なこととして、ユーザーの多くがユーザー名やパスワードの代替としてパスキーを主要な認証手段として受け入れるようになるのは、いつになるのだろうか。筆者の見立てでは、そのような状況が実現するまでには、さらに5～10年程度の時間を要する可能性がある。 　パスキーの現状を試してみたいユーザーのために、Shopify.comをユースケースとして取り上げる。Shopifyは、オンラインストアを迅速かつ容易に立ち上げられるEコマースサービスプロバイダーである。ただ、Shopifyのパスキー対応を体験するために、実際にオンラインストアを開設する必要はない。ここでは、Shopifyのウェブサイトを使って、パスキーの登録プロセスを開始する際にユーザーがたどる典型的な流れを紹介する。 　その手順は一般的なものではあるが、パスキーのユーザー体験には、依拠当事者ごとに違いが生じる可能性がある。こうした細かな違いは、たとえわずかなものであっても、ユーザー名とパスワードによる認証という、ほぼ全ての人が慣れ親しんでいる一貫したワークフローに比べて、ユーザーを戸惑わせる要因となり得る。 [前回](https://japan.zdnet.com/article/35235371/) の記事では、筆者がShopifyの「Create a Passkey（パスキーを作成）」ボタンにたどり着いた様子を紹介した（下図参照）。  Shopifyでパスキーを作成するオプションは、Shopifyのアカウント管理画面にある「Security（セキュリティ）」の下で発見できる。（提供：Screenshot by David Berlind/ZDNET） 　これまでのところ、Shopify.comのセキュリティ設定にたどり着くまでに、幾つかのメニューを操作するなど、プロセスは比較的スムーズだった。しかし、依拠当事者が誰であれ、パスキーの作成ボタン（あるいはそれに相当するもの）をクリックしてパスキー登録のセレモニーを開始した瞬間から、試練が始まる。パスキーの登録がうまくいくかどうかは、使用しているブラウザーやOS、オーセンティケーター（認証器）など、さまざまな要因に左右される。 　本シリーズ全6回のうち、パスキー登録セレモニーに関する記述を2回に分けている。本稿は、パスキーに必須となるオーセンティケーターの選択について説明する。次回は、その舞台裏で何が起こるかを解説する。 ## オーセンティケーターとパスワードマネージャーの違い 　パスキーの説明を続ける前に、まずオーセンティケーターとパスワードマネージャの違いを明確にしておく必要がある。 　パスキーの世界において、オーセンティケーターとは、パスキーの公開鍵と秘密鍵という構成要素を生成・保存し、あらゆる認証セレモニーの際にそれらを取得・使用する技術を指す。Googleのパスワードマネージャーのようにウェブブラウザーに組み込まれているものもあれば、「Bitwarden」「Dashlane」「NordPass」といったサードパーティー製のBYO（Bring Your Own）型パスワードマネージャーも含まれる。 　また、デバイスのOSと連携したり、Trusted Platform Module（TPM）や「Secure Enclave」などのローカルセキュリティハードウェア、あるいはYubicoの「YubiKey」のような「FIDO2」準拠のローミングオーセンティケーターといった、パスワードマネージャーではないハードウェアとの組み合わせで構成されたりする場合もある。 　ここで重要なのは、現在のパスワードマネージャーの多くがFIDO2準拠のオーセンティケーターである一方で、全ての認証器がパスワードマネージャーであるとは限らないという点である。例えば、YubiKeyは認証器ではあるが、パスワードマネージャーではない。また、「オーセンティケーター」という言葉の意味は、テクノロジーベンダーやその顧客によって異なる場合があることにも注意が必要だ。 　「Google Authenticator」は、TOTP（時間ベースのワンタイムパスワード）を生成する多要素認証の一形態であり、現時点ではパスキーとは無関係である。「Microsoft Authenticator」は、パスワードマネージャー、TOTPジェネレーター、そして限定的ながらパスキー認証器としての機能を1つにまとめた製品である。Microsoftは、パスキーを推進し、パスワードを不要にするという業界の方向性に沿って、オーセンティケーターにおけるパスワード対応の廃止を進めようとしている。こうした背景もあり、「オーセンティケーター」という用語は、業界内で不必要に混乱を招いているのが現状である。 　FIDO Allianceは、Apple、Google、Microsoftなどが参加するコンソーシアムであり、パスワードへの依存を減らすための認証標準の維持と推進を担っている。Appleが2021年、FIDO2準拠の資格情報を実装する際に、それらを「パスキー」と呼んだことがきっかけとなり、この名称が広く定着するようになった。 　オーセンティケーターにはさまざまな種類と選択肢があり、それぞれのユーザーや組織がパスキー導入を計画する際に、慎重に検討すべき重要な要素となっている。 　また、パスキーの全体的な戦略を考える上で、異なるパスキーに対して異なるオーセンティケーターを使用できることも覚えておきたい。筆者の場合は、ほとんどのウェブサイトではBitwardenをオーセンティケーターとして使用しているが、そのBitwardenアカウント自体のオーセンティケーターにはYubiKeyを設定している。さらに、多くの依拠当事者は、同じアカウントに対して複数のパスキーの登録を許可している。筆者の場合、「Gmail」アカウントには2つのパスキーを設定しており、それぞれ異なるローミングオーセンティケーターを使用している。 ZDNET Japan 記事を毎朝メールでまとめ読み（登録無料） [メールマガジン登録のお申し込み](https://japan.zdnet.com/newsletter/) - - [noteで書く](https://note.mu/intent/post?url=https%3A%2F%2Fjapan.zdnet.com%2Farticle%2F35235516%2F&ref=https%3A%2F%2Fjapan.zdnet.com%2Farticle%2F35235516%2F&hashtags=ZDNET) ## ZDNET Japan クイックポール 所属する組織のデータ活用状況はどの段階にありますか？ ZDNET Japanは、CIOとITマネージャーを対象に、ビジネス課題の解決とITを活用した新たな価値創造を支援します。 ITビジネス全般については、 [CNET Japan](https://japan.cnet.com/) をご覧ください。