パスキー：企業での利用に適しているか？

パスキーは、Google、Apple、Facebook、Meta などの消費者向けサービスによってますます一般的になってきています。パスキーを使用すると、従来のパスワードを利用したログインと比べてセキュリティが大幅に向上します。

消費者向けのソリューションがプロフェッショナルな用途に流用されるのはよくあることです。例えば、絵文字リアクションをメールに送ることができるようになったのもその一例です。しかし、Instagramでパスキーを使ってログインできるからといって、ビジネスで使用すべきだというわけではありません。

簡潔に言うと、FIDOパスキーは企業での使用に適しているのでしょうか？

アメリカの FIDOアライアンス （ファイドアライアンス）は、2013年に設立された組織で、パスワードに代わる強力な認証方法を開発しています。FIDOはその名が示す通り、「Fast Identity Online」を提供し、パスワードレスでの認証を実現しています。

FIDOはその後、急速に広まり、多くの大手企業が支持する認証方法となっています。特にApple、Google、PayPal、Microsoftなどが積極的に利用していますRSAもFIDO Allianceのメンバー で、Enterprise Deployment Working Groupの共同議長を務めています）。

FIDO認証は非対称鍵ペアを使用してサービスにログインします。FIDO認証情報がサービスに登録されると、新しい鍵ペアがFIDO認証器で生成され、その鍵ペアだけがサービスに信頼されます。この鍵ペアはサービスの正確なドメイン名に結びつけられます。

サービスとFIDO認証情報との厳密なペアリングにより、高度なフィッシング耐性が実現されています。例えば、ユーザーが実際のサイトとは異なるフィッシングサイトでログインしようとしても、ドメイン名が一致しないためログインに失敗します。

2022年にはApple、Google、Microsoftが 「パスキー」という新しいタイプのFIDO認証をサポートすることを発表しました。2023年にはFIDO Allianceが「パスキー」という用語をすべてのFIDO認証情報を指す言葉として採用しましたが、これにより「パスキー」が指す意味が曖昧と感じる時もあるかもしれません。

この曖昧さはFIDO Allianceによって対処されていますが、組織内での理解が統一されていない場合もあります。この曖昧さを解消することは重要です。なぜなら、すべてのパスキーが同じではなく、企業利用に適しているわけではないからです。

パスキーのタイプ

FIDOアライアンスによって定義されたパスキーには、現在2種類あります: デバイスに結び付けられたもの（デバイスバウンド）と同期されたもの（シンクド）です。

デバイスバウンドパスキーとシンクドパスキーの違い

デバイスバウンドパスキーは、一般的に特定の「セキュリティキー」デバイス上にホストされます。デバイスバウンドパスキーでは、鍵のペアが単一のデバイス上で生成・保存され、鍵の情報自体はそのデバイスから一切外部に出ることがありません。このタイプのパスキーは、秘密鍵がデバイスから外部に出ないため、抽出やリモートからの侵害に対して耐性があり、より安全と一般的に見なされています。 ただし、この方式には欠点もあり、デバイスが紛失または破損した場合には、パスキーを再取得してデバイスに再登録する必要があります。また、新しいデバイスに追加する必要が生じることもあります。 デバイスバウンドパスキーは、特に高い保証レベルが求められる環境や企業用途において好まれており、セキュリティキーやTPM（Trusted Platform Module）などのハードウェアを活用することが一般的です。

パスキーの同期

シンクドパスキーでは、鍵の情報がいわゆるリモート同期プラットフォームを通じて保存され、その後、同じユーザが所有する他のデバイスに復元することができます。現在の主要な同期されるプラットフォームには、Microsoft、Google、Appleがあります。つまり、例えばAndroidスマートフォンをパスキーとして登録した場合、対応する鍵情報は間もなく他のすべてのAndroidデバイスでも利用可能になります。

シンクドパスキーは、WhatsAppやFacebookといった広く使用されているサービスに対応していることに加え、パスキーの一般的な利用が急増している主な理由の1つです。その理由は明白です。多数のアカウントとデバイスを持つ1人のユーザが、すべてのデバイス間で同じシンクドパスキーを使用できるからです。

パスキーは、従来のパスワードに代わって暗号鍵ペアを使用することで、強力でフィッシング耐性のある認証を実現します。ユーザがサービスに登録する際、デバイス上で一意の秘密鍵と公開鍵のペアが生成されます。秘密鍵はユーザーのデバイスに安全に保存され、公開鍵はサービス側と共有されます。 ログイン時には、デバイスがサービスから送られたチャレンジに対して秘密鍵で署名することで、その鍵を所持していることを証明します。サービス側は保存されている公開鍵を使って署名を検証します。 このプロセスでは共有された秘密情報が送信されることも、パスワードが生成・保存されることもなく、資格情報の盗難やリプレイ攻撃のリスクを大幅に低減します。

従来のパスワードは、推測されたり、盗まれたり、フィッシングされたりする可能性のある「共有された秘密」に依存しているため、攻撃者にとって一般的な侵入経路となります。これらはしばしば複数のアカウントで使い回され、不適切に保存されることが多く、ブルートフォース攻撃やクレデンシャル・スタッフィング攻撃に対して脆弱です。

パスキーは、パスワードを公開鍵・秘密鍵暗号に置き換えることで、これらのリスクを排除します。秘密鍵はユーザのデバイスから決して外に出ることはなく、認証はその鍵を所持していることを証明することで行われます――鍵自体を送信する必要はありません。この仕組みにより、フィッシング、資格情報の盗難、パスワードの使い回しといった一般的な攻撃手法の多くが無効化されます。 企業にとって、パスキーはセキュアな認証を大きく前進させる手段であり、同時にパスワードのリセットやサポート対応の負担を軽減する効果も期待できます。

• フィッシング耐性：パスキーは、従来のフィッシング攻撃を防ぐように設計されています。パスワードが存在しないため、盗まれたり使い回されたりする情報がありません。
• 高速かつ便利：パスキーによるログインは、多くの場合、顔認証や指紋認証などの生体認証を使うだけで済むため、ユーザにとってよりスムーズな体験となります。
• 使いやすいユーザ・エクスペリエンス：パスキーによるログインは、一般的なモバイル認証のパターンに似ているため、ほとんど学習コストがかかりません。
• ドメインマッチングによるセキュリティ：パスキーは、鍵の情報が元のサービスのドメインでのみ機能することを保証することで、追加の保護層を提供します。これはすべての多要素認証（MFA）方式には備わっていない利点です。
• 政府承認済み：アメリカ合衆国では、フィッシング耐性が連邦規制の重要な要素となっています。 エグゼクティブオーダー14028 では、重要なインフラを保護するためにフィッシング耐性のあるパスワードレス認証が求められています。

パスキーは大きな利点を提供しますが、いくつかの重要な課題や問題も伴います。

• ユーザエクスペリエンス：例えば、セキュリティキーをUSBポートに挿入するよう求められたり、PINを入力するよう促されたりするパスキープロンプトは、使用するOSやブラウザによって見た目が異なります。これにより、ユーザ教育が難しくなり、サポートへの問い合わせが増える可能性があります。
• 他の攻撃からの注意散漫：パスキーを使えば突然、多要素認証（MFA）バイパスやソーシャルエンジニアリング攻撃に対して無敵になると考えるのは大きな誤りです。パスキーは、ソーシャルエンジニアリング攻撃のうちフィッシングに対しては有効ですが、残念ながら他にも様々な手口があります。例えば、ラスベガスのMGMリゾーツやシーザーズパレスへの攻撃では、ヘルプデスクを悪用して攻撃者自身がMFA認証機器を登録できるようにするというソーシャルエンジニアリングの要素が含まれていました。
• デバイスの紛失やアップグレード時の課題：ユーザがデバイスへのアクセスを失い（同期やバックアップを有効にしていない場合）、特にデバイスバウンドパスキーの場合、パスキーの復旧に困難を伴うことがあります。
• 対応サービスの制限：普及は進んでいるものの、すべてのウェブサイトや企業システムがまだパスキーに対応しているわけではなく、日常的な利用に制限が生じることがあります。
• ユーザの混乱や認知不足：パスキーの概念はまだ多くのユーザにとって新しいため、設定や同期、内部で何が起きているのかについて混乱が生じることがあります。用語の違い（パスキー、セキュリティキー、FIDOキー）や業界全体で変化し続ける標準も、この混乱を助長し、ユーザや組織がベストプラクティスを明確に理解し、一貫してパスキーを導入・運用することを難しくしています。これにより、設定や利用時のミス、サポートへの問い合わせ増加、そしてセキュリティ上の穴が生じる可能性もあります。
• インフラの準備状況：パスキーを導入するには、組織がアイデンティティプラットフォームの更新やデバイス管理ポリシーの見直し、さらには従業員向けのトレーニングを実施する必要がある場合があります。特にレガシー認証から移行する際には注意が必要です。レガシーシステムやオンプレミス環境は、ウェブ認証に限定されるパスキーと互換性がない場合もあります。そのような場合は、環境全体に対応でき、かつレガシーインフラを維持できるパスワードレス認証機能を備えた多要素認証（MFA）をモダナイズすることが推奨されます。

今日のパスキーが、様々なブラウザ、デバイス、オペレーティング・システムで統一されたワークフローを提供するという課題を抱えていることを考えると、真にシームレスでクロスプラットフォームなエクスペリエンスを保証するために、業界には何ができるのだろうか？ユーザーを混乱させ、普及を妨げる可能性のある矛盾を解決するための最善の道をどのように判断すればよいのでしょうか？

RSAでは、UXリーダーシップがFIDOアライアンスの作業部会に積極的に参加し、一貫したユーザー・エクスペリエンスを提唱しています。私たちの洞察力を提供することで、エンド・ユーザーにとって混乱が少なく、摩擦が少なく、統一性のある標準の策定を支援することを目指しています。.

モビリティも、さまざまな環境でシームレスなパスキー体験を実現するための重要な要素です。従業員はますますモバイルファーストのワークフローの利便性を求めています。スマートフォンで企業リソースにアクセスする際に、そのデバイスのロック解除と同じくらい直感的に操作できれば、パスキーのような新しい認証方法の導入が格段に容易になります。ストレスのないモバイル体験はユーザの抵抗感を軽減し、学習コストを最小化してパスワードからの移行をスムーズにします。利用者のデバイスやプラットフォームに関わらず、親しみやすく、権限に関して透明性があり、一貫したインターフェースを提供することで、組織は混乱を減らし信頼性を高めることができます。RSAのモバイルFIDOソリューションは、デバイスに依存しない形でパスキーを実装する一例として挙げられます。

モバイル認証が許可されていない安全な施設や高保証環境においては、 RSA iShield Key 2 シリーズ フィッシング対策機能を備えたクロスプラットフォーム対応のパスワードレスセキュリティを実現する、FIPS 140-3 レベル3、FIDO2認証取得のハードウェア認証器を提供します。.

「ハンマーを持っていると、すべてが釘に見える」と言われます。消費者向けに元々設計された優れたソリューションであっても、それを企業向けアプリケーションに転用することは、重大なリスクを引き起こす可能性があります。

この記事を読んでいるとき、「同期基盤」という言葉に不安を感じたかもしれません。あなたの直感は正しいと思います。

パスキーがAppleやGoogleを通じてユーザがログインしているすべてのデバイスにまるで魔法のように現れるという事実は、企業環境では大きな警告となり、いくつかの重要な疑問を引き起こすはずです：

• ユーザは認証に複数のデバイス（おそらく個人的に使用するデバイスも含む）を使用することを許可すべきでしょうか？ もし許可するのであれば… 何台まで許可すべきでしょうか？
• シンクドパスキーは、例えばGoogleやAppleのアカウント復旧プロセスを使って「失われた」パスキーを復元することを可能にします。それは素晴らしいことですが、これらのプロセスはあなたにとって十分に安全なのでしょうか？
• ユーザがパスキーを友人や家族と共有できるAppleの機能は非常に便利ですが、これは企業向けアプリケーションにログインするために使用されるパスキーにも適用されるのでしょうか？

シンクドパスキーを使用する場合、企業のセキュリティは突然、AppleやGoogleの技術的および組織的なセキュリティに大きく依存することになります。確かに、 iOS や Androidの利用によって一定の依存はもともとありますが、シンクドパスキーはその依存度を大幅に高めます。

これは理論的な脆弱性でもない。. リツール この機能は、「あなたのグーグルアカウントが侵害された場合、あなたのMFAコードも侵害される」ことを意味する。“

パスキーを企業で使用すべきかどうかは、一般的に答えることはできません。各組織は異なり、独自のセキュリティと運用の優先事項をバランスさせる必要があります。

さらに、パスキーを使用するかどうかは、単なる「はい/いいえ」の問題ではありません。パスキーやパスワードレスログインの導入は、組織全体のMFAプロセスを根本的に見直すために活用されるべきです。15年間にわたりハードウェアOTPトークンに適していたことが、今日のパスキーやその他のMFAにはもはや完全には当てはまらないかもしれません。

RSAは、パスキーが組織の戦略に合致し、以下の質問に対する答えを慎重に考慮すれば、企業での使用に導入できると考えています。私たちは、組織がパスキーを成功裏に使用しているのを見てきました。 RSA^® ID Plus, を使用して、パスキーを活用して導入している組織も見られます。これは、さまざまなパスワードレスオプションを提供する包括的なアイデンティティおよびアクセス管理（IAM）プラットフォームです。

私たちはセキュリティを最優先する組織であり、Secure by Design / Secure by Defaultの原則を採用しているため、デフォルトでシンクドパスキーの使用を禁止しています。RSAの環境では、デフォルトでデバイスバウンドパスキーのみが利用可能で、これにより管理者の追加作業なしで最大レベルのセキュリティを提供しています。

パスキーの導入を検討する際、組織は次の点を問いかけるべきです：認証機器はどのように登録されているか？「認証機器を紛失した場合」の対応は安全に行われているか？ユーザ、アプリケーション、データの分類はどうなっているか？

パスキーは 多要素認証（MFA）の方法 数ある中で。確かにフィッシング対策は素晴らしいが、ユーザーはリモートデスクトップでこれを使ってログインできるのか？

これらの理由をはじめ多くの点から、MFAシステムは単に技術的に最新であるだけでなく、QRコード、生体認証、OTP、プッシュメッセージ、パスキーなど、さまざまなMFA方式をサポートしていることが重要です。

MFAに関するプロセスが新しい脅威に適応していることも重要です。これは実際のMFAシステムだけにとどまらず、ヘルプデスクもソーシャルエンジニアリング攻撃から安全であるかどうかということにも関わります。

パスキーの導入が理にかなっていると思われる場合は、お手伝いします。詳細については お問い合わせ にご連絡いただくか、 ID Plusの無料45日間トライアル.