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

このブログは2024年に掲載されたものです。. 

Google、Apple、Facebook、Metaなどの消費者向けサービスのおかげで、パスキーの利用がますます一般的になってきています。パスキーを利用することで、従来のパスワードベースのログインやパスワードレスMFAと比較して、セキュリティが大幅に向上します。.

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

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

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

2013年以来、FIDOは最も人気のあるパスワードレス認証方法の一つとなっています。その主な理由は、その名称を構成する頭字語が示す通り、「オンライン上で迅速な本人確認」を実現している点にあります。FIDOアライアンスは、消費者向け環境に特に重点を置いています。 当然のことながら、同アライアンスの主要メンバーであるApple、Google、PayPal、そしてMicrosoftは、この分野で積極的に活動しています。. RSAもFIDO Allianceのメンバー また、同グループの「エンタープライズ導入ワーキンググループ」の共同議長を務めている。.

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

サービスとFIDO認証情報のこの厳格な紐付けこそが、フィッシング攻撃に対する高い耐性をもたらしています。ユーザーが、本物のサイト用に作成されたパスキーを使って偽のフィッシングサイトにログインしようとしても、指定されたドメイン名が認証情報と一致しないため、ログインは失敗するからです。.

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

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

パスキーのタイプ

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

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

デバイスに紐付けられたパスキーは、通常、特定の「セキュリティキー」デバイス上に格納されます。このタイプのパスキーは、秘密鍵がデバイス外に出ることがないため、抽出や遠隔からの不正アクセスに対して耐性があり、一般的により安全であると考えられています。.

しかし、これは同時に、デバイスを紛失したり破損したりした場合、ユーザーは新しいデバイスに新しいパスキーを登録する必要があることを意味します。デバイスに紐づけられたパスキーは、特に高信頼性が求められる環境や企業での利用事例で好まれており、多くの場合、セキュリティキーやトラステッド・プラットフォーム・モジュール（TPM）などのハードウェアが活用されています。.

また、iOSおよびAndroid向けの「RSA Authenticator」アプリなど、一部のモバイルアプリケーションでも、デバイスに紐付けられたパスキーがサポートされるようになりました。.

パスキーの同期

同期されたパスキーでは、鍵データはいわゆる「リモート同期ファブリック」を介して保存され、その後、同じユーザーが所有する他のどのデバイスでもその鍵データを復元することができます。 現在、主要な同期ファブリックとしては、Microsoft、Google、Appleが挙げられます。つまり、Androidスマートフォンをパスキーとして登録した場合、対応する鍵データはGoogleによって保存されるため、その後まもなく、所有する他のすべてのAndroidデバイスでも利用可能になります。.

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

パスキーは、従来のパスワードを暗号鍵ペアに置き換え、強固でフィッシング攻撃に強い認証を実現します。ユーザーがサービスに登録すると、その端末が一意の秘密鍵・公開鍵ペアを生成します。秘密鍵はユーザーの端末に安全に保管され、公開鍵はサービス側と共有されます。 認証の際、端末はサービスからのチャレンジに署名することで秘密鍵を所有していることを証明し、その署名は保存されている公開鍵を使用して検証されます。共有秘密鍵は送信されず、パスワードも生成・保存されないため、認証情報の盗難やリプレイ攻撃のリスクを劇的に低減します。.

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

パスキーは、パスワードを公開鍵・秘密鍵暗号に置き換えることで、こうしたリスクを排除します。 認証は、鍵そのものを送信することなく、その鍵を所持していることを証明することで行われます。このアプローチにより、フィッシング、認証情報の盗難、パスワードの再利用など、最も一般的な攻撃手法のほとんどが通用しなくなります。組織にとって、パスキーは安全な認証における飛躍的な進歩をもたらすと同時に、パスワードのリセットやサポートチケットの負担を軽減します。.

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

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

• ユーザー体験： たとえば、セキュリティキーをUSBポートに挿入するよう求めるメッセージやPINの入力を求めるメッセージといったパスキーに関するプロンプトは、オペレーティングシステムやブラウザによって表示が異なります。こうしたプロンプトがあると、ユーザーへの指導が難しくなり、サポートへの問い合わせが増える可能性があります。.
• 他の攻撃からの注意散漫： パスキーを使用すれば、ソーシャルエンジニアリング攻撃のような多要素認証（MFA）の迂回攻撃から突然免れることができると考える人は、大きな誤解を犯しています。 パスキーは、ソーシャルエンジニアリング攻撃の一種であるフィッシング対策には役立ちます。しかし残念ながら、他にもさまざまな手口が存在します。ラスベガスのMGMリゾーツやシーザーズ・パレスに対する攻撃には、ソーシャルエンジニアリングの要素が含まれていました。それは、ヘルプデスクを悪用し、攻撃者が自らMFA認証デバイスを登録できるようにするというものでした。.
• 端末の紛失や機種変更に伴う課題： デバイスに紐付けられたパスキーに対応しているデバイスへのアクセス権を失った場合、そのパスキーは復元できません。.
• すべてのサービスにおけるサポートは限定的です： 普及は進んでいるものの、まだすべてのウェブサイトや企業システムがパスキーに対応しているわけではないため、日常的な利便性が制限される可能性があります。.
• ユーザーの混乱や認識不足： パスキーという概念は、多くのユーザーにとってまだ馴染みの薄いものであり、そのために設定や同期、あるいは内部で何が起きているのかについて混乱が生じることがあります。 用語のばらつき（パスキー、セキュリティキー、FIDOキーなど）や業界全体で進化し続ける標準規格により、この混乱はさらに増大し、ユーザーや組織がベストプラクティスを明確に理解し、パスキーを一貫して導入・運用することが困難になる可能性があります。また、これにより設定や使用時のミス、サポートへの問い合わせの増加、さらにはセキュリティ上の潜在的な脆弱性につながる恐れもあります。.
• インフラの準備状況： パスキーの導入には、特に従来の認証方式からの移行を行う場合、組織がID管理プラットフォームやデバイス管理ポリシーを更新し、研修を実施する必要が生じる可能性があります。また、Web限定の認証方式を採用しているため、従来のシステムやオンプレミスリソースがパスキーに対応していない場合もあるでしょう。そのような場合、組織は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日間トライアル.

パスキーの導入を決定するのは簡単なことです。このガイドでは、導入を成功させるための3つの段階――評価、パイロット運用、全社展開――について、実際に導入を完了した組織の実例を交えて解説します。RSAのパスワードレス機能に関する詳細については、以下のページをご覧ください。 RSAのパスワード不要ソリューションのページ.

フェーズ1：評価と計画 （4～8週間）

1. 認証監査を実施する。認証を必要とする、または認証に関与するすべてのアプリケーション、インフラストラクチャ、システムを洗い出し、そのうち「FIDO2」をまだサポートしていないものを特定する。.
2. リスクの高いユーザーグループを特定します。特権管理者、財務担当者、リモートワーカー、共有デバイス利用者など、それぞれ異なる対応が必要です。導入計画を立てる前に、リスクレベルに応じて従業員を分類してください。.
3. パスキーポリシーを定義します。どのユーザー層がデバイス固有のパスキー、同期されたパスキー、あるいはその両方を併用すべきかを決定します。RSAでは、デフォルトとしてデバイス固有のパスキーを推奨しており、同期されたパスキーは、そのトレードオフが正当化される場合にのみ使用することを推奨しています。.
4. USBポート、BLE、またはモバイルデバイスの使用に関する制限など、パスキーの利用に影響を与える可能性のある社内ポリシーを見直します。段階的な導入スケジュールを策定します。マイルストーンを設定し、担当者を割り当て、実施・中止の判断基準を明確にします。早い段階で経営陣の合意を得ておきます。.

フェーズ2：パイロット導入 （6～10週間）

1. パイロットグループは慎重に選定してください。IT部門やセキュリティ担当者は、最初のユーザーとして最適です。また、少人数の経営幹部アシスタントを加えることで、共有パソコンや業務の委任といった、実務上のエッジケースを明らかにしやすくなります。.
2. ユースケースに応じて、お使いの環境で両方のパスキータイプをテストしてください。組織で使用している各種デバイスやオペレーティングシステムにおいて、登録、ログイン、デバイスのスリープ状態からの再認証、およびSSOが正常に機能することを確認してください。.
3. ヘルプデスクの手順を策定し、テストを行います。端末の紛失、PINの忘れ、入社・退社時の対応といったシナリオについて、本番環境で実際に発生する前にシミュレーションを行います。ヘルプデスクのスタッフは、ソーシャルエンジニアリングの被害に遭うことなく、復旧ワークフローを安全に実行できる必要があります。.
4. 成功指標を定義します。スケールアップを行う前に、登録率、認証の成功率・失敗率、およびヘルプデスクへの問い合わせ件数をベースラインとして追跡します。.
5. 体系的なフィードバックを収集する。パイロットユーザーを対象に、2週間後と6週間後にアンケート調査を実施する。得られた知見を活用して、本格的な展開に先立ち、研修資料や設定内容を更新する。.

フェーズ3：企業への展開 （2～6か月）

1. 変更管理プログラムを開始しましょう。長いドキュメントよりも、短い動画による操作ガイドや文書化された作業支援ツールの方が効果的です。ユーザー層に応じてコンテンツを調整しましょう。リモートで働く開発者の体験は、共有ワークステーションのフロアで作業するユーザーとは異なります。.
2. 段階的に展開します。部門、地域、またはリスクレベルごとに導入を進めます。通常、リスクの高いユーザーから優先的に導入し、共有端末を使用するユーザーやレガシーシステムに依存しているユーザーは最後に導入します。.
3. 予備の認証手段を確保しておいてください。従来の多要素認証（MFA）を直ちに廃止しないでください。登録数が目標値（通常、部門ごとに90%+）に達するまでは、OTPプッシュ通知、QRコード、またはハードウェアトークンを予備手段として維持してください。.
4. 導入状況と認証の健全性を監視します。プラットフォームのダッシュボードを使用して、登録完了状況、失敗率、ヘルプデスクの傾向を追跡します。異常を早期に検知できるようアラートを設定します。.
5. セキュリティ対策で一連のプロセスを完結させましょう。導入が完了したら、MFAポリシーの文書を更新し、導入後のレビューを実施してください。パスキーの導入により、認証情報のフィッシング攻撃は排除されますが、ヘルプデスクにおけるソーシャルエンジニアリングによる攻撃は依然として現実的なリスクとして残っています。.

以下は、一般的な導入パターンに基づいた具体例です。.

シナリオ1：金融サービス――地方銀行、従業員5,000人
ある中規模の地方銀行は、以下を通じてデバイスに紐づけられたパスキーを導入した。 RSA ID Plus ～と FIPS 140-3 認定のハードウェアセキュリティキー 特権ユーザーおよび支店スタッフ向け。.

• 主な課題: 従来のテラーアプリケーションにはFIDO2プロキシ層が必要でした。また、ヘルプデスクのスタッフには、導入前にソーシャルエンジニアリング対策の研修が必要でした。.
• パスキーの種類: デバイスに紐づけられたハードウェアセキュリティキー
• 年表: 6ヶ月
• 成果: 43% によるヘルプデスクのチケット件数の削減；導入後はパスワード関連のセキュリティ侵害がゼロ

シナリオ2：政府機関（連邦政府機関）、従業員数12,000人
ある連邦政府の民間機関は、エアギャップ化された機密ネットワークセグメントを含むハイブリッド環境において、大統領令14028号およびOMB M-22-09で定められたフィッシング攻撃に耐性のある多要素認証（MFA）の要件を満たす必要がありました。.

• 主な課題: エアギャップ化されたセグメントでは、インターネットに依存しない認証が必要でした。また、レガシーの案件管理システムにはFIDO2プロキシ層が必要でした。さらに、30か所以上の現地事務所では、リモート登録のサポートが必要でした。.
• パスキーの種類: FIPS 140-3 レベル 3 RSA iShield Key 2 全スタッフ向け；エアギャップ環境のセグメント向けRSA DS100 OTPトークン
• 年表: 10ヶ月
• 成果: 大統領令14028号およびM-22-09への完全な準拠が認定された；認証情報の取得率が18%から1%未満に低下した；ヘルプデスクのチケット数が38%減少した