パスキーはエンタープライズで使えるのか？

こんにちは、富士榮です。

先日、IDProで紹介されていた記事を見つつ以下のポストをしました。

• パスキーはパスすべきなのか？
• 結局パスキーはパスすべきなのか？

記事の中では同期ファブリックの安全性や互換性に関する課題が指摘され、デバイス紐付けパスキーという選択肢やUniversal Credential Exchangeによる相互運用性の実現に向けた取り組みの紹介をしました。

結果、エンタープライズでの利用の場合は同期パスキーよりもデバイス紐付けと管理などが現実的なのかな？？などのコメントを各所で頂いたりしました。

そんな中、RSAが最近こんなブログを公開しました。

Are FIDO Passkeys Ready for Enterprise Use?

https://www.rsa.com/ja/resources/blog/passwordless/are-fido-passkeys-ready-for-enterprise-use/

RSA社のブログ

ベンダのブログなので若干バイアスがかかる可能性は否定しませんが、まさにエンタープライズでパスキーを使えるのかどうか気になっている人は必見だと思います。

ということで簡単に見ていきましょう。

Device-Bound Passkeys vs. Synced Passkeys

まずはデバイス紐付きのパスキーと同期パスキーについて解説されています。この辺りはご存知の方が殆どだと思いますがおさらいしておきましょう。

Device-bound passkeys are generally hosted on specific ‘security key’ devices. On a device-bound passkey, key pairs are generated and stored on a single device; moreover, the key material itself never leaves that device.

With synced passkeys, the key material is saved via a so-called remote sync fabric, and the key material can then be restored on any other devices owned by the same user. The current major sync fabrics are Microsoft, Google and Apple. This means that if you were to register your Android phone as a passkey, then the corresponding key material would be available on all your other Android devices shortly after.

Synced passkeys are—in addition to the support of widely used services such as WhatsApp or Facebook—a main reason for the sharp increase in the general use of passkeys. It’s easy to see why: one user with a lot of accounts and a lot of devices can use the same synced passkey between all of them.

デバイスに紐づけられたパスキーは、通常、特定の「セキュリティキー」デバイスにホストされています。デバイスに紐づけられたパスキーでは、キーペアが生成され、単一のデバイスに保存されます。さらに、キー素材自体はデバイスから決して離れることはありません。

同期パスキーでは、鍵情報はリモート同期ファブリックと呼ばれる仕組みを介して保存され、同じユーザーが所有する他のデバイスにも復元することができます。現在、主な同期ファブリックとしては、Microsoft、Google、Appleが挙げられます。つまり、Androidフォンをパスキーとして登録すると、その後すぐに、他のすべてのAndroidデバイスでも対応する鍵情報を利用できるようになるということです。

同期されたパスキーは、WhatsAppやFacebookなどの広く使用されているサービスのサポートに加えて、パスキーの一般的な使用が急激に増加している主な理由です。その理由は簡単です。多くのアカウントとデバイスを持つユーザーは、それらすべてに同じ同期されたパスキーを使用することができます。

 

ユーザが直接サインアップして使うコンシューマ向けサービスではユーザビリティの向上を目標として同期パスキーが使われることで急激にパスキー自体の普及率が上がっている、ということですね。

The Benefits of Passkeys

パスキーの利点についてもおさらいされています。

Passkeys are an excellent MFA method: safe, fast, convenient, and users are already familiar with them. But the passkey benefit that’s beginning to get a lot of attention is that they’re phishing-resistant.

Passkeys can help organizations stop traditional phishing in its tracks: if there’s no password being used, then there’s no password to steal. And while that’s true for other passwordless MFA methods, passkeys have an added level of security provided by that synched key/service domain match.

In the U.S., phishing resistance is a major driver for government agencies. Executive Order 14028 requires phishing-resistant, passwordless authentication to secure critical infrastructure.

パスキーは優れた多要素認証の方法です。安全で、高速で、便利であり、ユーザーもすでに慣れ親しんでいます。しかし、現在注目を集め始めているパスキーの利点は、フィッシング対策に有効であるという点です。

パスキーは、従来のフィッシングを阻止するのに役立ちます。パスワードが使用されていなければ、盗むべきパスワードも存在しないからです。これはパスワード不要の他の多要素認証方法にも当てはまりますが、パスキーには、同期されたキー/サービスドメインの一致による追加のセキュリティレベルが備わっています。

米国では、フィッシング対策は政府機関にとって重要な推進要因となっています。大統領令14028では、重要なインフラストラクチャを保護するために、フィッシング対策のパスワード不要の認証が義務付けられています。

パスキーの一番の利点としてフィッシング耐性があることに触れられています。米国では大統領令でもフィッシングについての記載があるんですね。

The Challenges with Passkeys

ここからパスキーの課題について触れられています。

While passkeys provide significant advantages, they also come with a few significant challenges and problems.

For a solution that has grown up in the consumer environment, user guidance and the user experience can sometimes be a challenge.

Dialogs that ask the user to insert the passkey into the USB port or enter the PIN, for example, look different depending on the operating system and browser. Those prompts will likely make it more difficult to train users and minimize support calls.

Why not just change the prompts you ask? Because third-party service providers like RSA can’t: those prompts are set by the browser or OS vendor themselves in their own vendor (for instance, Apple sets their prompt for iOS, Google for Chrome, etc). There’s some good reason for this:  if vendors could change the prompt, then so could attackers, using an updated form to spy on users. Keeping those log-in prompts locked is an important security measure, but it can make for a one-size-fits-all approach.

The high level of phishing resistance is a clear advantage, but it can also be a distraction. Anyone who thinks that the use of passkeys suddenly makes them immune to social engineering attacks is very much mistaken. Passkeys help against one type of social engineering attack: phishing. Unfortunately, there are other variants. The attacks on MGM Resorts or Caesars Palace in Las Vegas had a social engineering component: exploiting the help desk to allow the attacker to register an MFA authenticator himself.

Attackers adapt as a matter of course. The proliferation of MFA has made phishing much less attractive, so it’s only natural that vulnerabilities around the MFA system are exploited. Such as the way users register. Anyone who thinks passkeys solve these problems is very wrong.

パスキーには大きな利点がある一方で、いくつかの重大な課題や問題も伴います。

消費者環境で成長してきたソリューションでは、ユーザーへのガイダンスやユーザーエクスペリエンスが課題となることがあります。

たとえば、パスキーをUSBポートに挿入するようユーザーに求めるダイアログやPINの入力などは、オペレーティングシステムやブラウザによって表示が異なります。このようなプロンプトは、ユーザーのトレーニングを難しくし、サポートコールを最小限に抑えることが難しくなるでしょう。

では、求めるプロンプトを変更すればよいのでしょうか?RSAのようなサードパーティのサービスプロバイダーにはできないからです。これらのプロンプトは、ブラウザやOSのベンダー自身が、それぞれのベンダーで設定しています(例えば、AppleはiOS、GoogleはChromeなど)。これにはいくつかの理由があります。もしベンダーがプロンプトを変更できるのであれば、攻撃者も同様に変更でき、最新のフォームを使用してユーザーをスパイすることが可能になります。ログインプロンプトをロックすることは重要なセキュリティ対策ですが、画一的なアプローチになりかねません。

フィッシングに対する高い耐性は明らかな利点ですが、かえって邪魔になることもあります。パスキーの使用によって、ソーシャルエンジニアリング攻撃に対する耐性が突然得られると考える人は、大きな誤解をしています。パスキーは、ソーシャルエンジニアリング攻撃の一種であるフィッシングに対する防御策となります。残念ながら、それ以外にもさまざまな種類があります。ラスベガスのMGMリゾートやシーザーズパレスに対する攻撃にはソーシャルエンジニアリングの要素がありました。ヘルプデスクを悪用して、攻撃者が多要素認証の認証装置を自分で登録できるようにしたのです。

攻撃者は当然のように適応していきます。多要素認証の普及により、フィッシングはあまり魅力的ではなくなりました。そのため、多要素認証システム周辺の脆弱性が悪用されるのは当然です。例えば、ユーザーによる登録方法などです。パスキーがこれらの問題を解決すると考える人は、大きな誤りを犯しています。

1つはUI（プロンプト）がプラットフォームによって異なる（かつサードパーティのソフトウェアでは変更ができない）ことが挙げられています。OSベンダがプロンプトを変更させないのはセキュリティの観点から見ると合理的ではありますが、OSごとにプロンプトが異なるのはユーザから見ると混乱を招く一因となっていると思います。

また、フィッシング耐性がある、というキーワードがかえって誤解を与えてしまう懸念についても記載されています。そもそもフィッシングはソーシャルエンジニアリングの一部であることを理解しないと、ソーシャルエンジニアリング全般に対する対策となっている、という誤解を招く、と指摘されています。

同じく、システムへの多要素認証手段の登録機能自体がパスキーでセキュアになる、という誤解もあるようですね。

Sync Fabrics and Cybersecurity Vulnerabilities

これも以前紹介した記事にも記載があった、同期ファブリックのセキュリティの話です。

They say that when you have a hammer, everything can look like a nail. Turing a solution—even a great solution—that was originally intended for consumer use into an enterprise application can introduce significant risk.

While reading this article, you may have had a queasy feeling at the mention of ‘sync fabric’. Your gut was right.

The fact that passkeys appear as if by magic on all devices on which the user is logged in via Apple or Google is a major red flag in the corporate environment and should raise some significant questions:

Should users be allowed to use several (possibly also privately used) devices for authentication at all? If so… How many?

Synced passkeys make restoring a “lost” passkey possible with the account recovery processes of e.g. Google or Apple. That’s great… but are these processes secure enough for you?

The Apple feature that allows users to share Passkey with friends or family is quite nice… but does this also apply to Passkeys that are used to log in to enterprise applications?

When using synced passkeys, the security of your company suddenly depends largely on the technical and organizational security of Apple and Google. Sure, there is a certain dependency anyway due to the use of iOS and Android—but synced passkeys increase this dependency considerably.

This isn’t a theoretical vulnerability, either. Last year Retool discussed how threat actors had used it to gain access to its systems: Retool wrote that the functionality means that “if your Google account is compromised, so now are your MFA codes.”

ハンマーを持っていれば、すべてが釘に見えるという。もともとコンシューマー向けに意図されたソリューション、たとえそれが優れたソリューションであったとしても、それをエンタープライズアプリケーションに転用することは、重大なリスクを伴う可能性がある。

この記事をお読みになっている方の中には、「同期ファブリック」という言葉に不安を覚えた方もいらっしゃるかもしれません。その直感は正しいです。

パスキーが、Apple や Google 経由でログインしたすべてのデバイス上に魔法のように現れるという事実は、企業環境においては重大な問題であり、次のような重要な疑問が生じます。

ユーザーは、認証のために複数の(場合によっては個人用も含む)デバイスを使用することが許されるべきでしょうか? もし許されるのであれば、何台まででしょうか?

同期されたパスキーは、Google や Apple のアカウント復旧プロセスによって「紛失した」パスキーの復元を可能にします。素晴らしいことですが、これらのプロセスは十分に安全でしょうか?

友人や家族とパスキーを共有できるAppleの機能は素晴らしいですが、これは企業アプリケーションへのログインに使用するパスキーにも適用されるのでしょうか?

同期されたパスキーを使用する場合、企業のセキュリティは突如としてAppleとGoogleの技術的および組織的なセキュリティに大きく依存することになります。もちろん、iOSやAndroidを使用しているため、ある程度の依存関係は存在しますが、同期されたパスキーは、この依存関係を大幅に高めます。

これは理論上の脆弱性でもありません。昨年、Retoolは、脅威の主体がこの機能を利用してシステムにアクセスした方法について論じています。Retoolは、この機能により「Googleアカウントが侵害された場合、MFAコードも侵害される」と書いています。

想像通り、ですがAppleやGoogleがホストする同期ファブリックを介して個人の所有物を含むデバイス間でクレデンシャルが同期されていたり、家族とクレデンシャルが共有されている環境下で企業アプリケーションを利用するのは管理者から見ると悪夢となりそうです。簡単に言うとコントロールをAppleやGoogleに握られている状態（依存している状態）は企業にとって必ずしも良い状態ではない、ということですね。

Are Passkeys Ready for Enterprise Use or Not?

結局パスキーはエンタープライズで使える状態なのか？という話です。

Whether Passkeys should be used in the company cannot be answered in a general way. Every organization is different and must balance its unique security and operational priorities.

Moreover, whether to use passkeys shouldn’t be a yes/no question. The introduction of passkeys or passwordless login in general should be used to fundamentally review an organization’s entire MFA processes. What has been good for hardware OTP tokens for 15 years is probably no longer entirely true for passkeys or other MFA methods today.

RSA believes that passkeys can be deployed for enterprise use if they align with organizational strategy and if organizations think through their answers to the following questions. We’ve seen organizations use passkeys successfully using RSA® ID Plus, our comprehensive identity and access management (IAM) platform that provides a range of passwordless options.

Because we’re a security-first organization and use Secure by Design / Secure by Default principles, we prevent using synced passkeys by default. Only device-bound passkeys are available by default in RSA environments to provide the maximum level of security out-out-the-box, and without any extra work required by admins.

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

さらに、パスキーを使用すべきかどうかは、イエス・ノーで答えられる質問ではありません。 パスキーやパスワード不要のログインを導入することは、組織のMFAプロセス全体を根本的に見直すために使用すべきです。15年間ハードウェアOTPトークンにとって有効であったことが、パスキーやその他の多要素認証方法ではもはや完全に当てはまらない可能性が高いのです。

RSAは、パスキーを企業で使用するには、組織の戦略と一致し、組織が以下の質問に対する答えを十分に検討することが必要だと考えています。RSAは、パスワード不要のさまざまなオプションを提供する包括的なアイデンティティおよびアクセス管理(IAM)プラットフォームであるRSA® ID Plusを使用して、パスキーを成功裏に使用している組織をいくつも見てきました。

当社はセキュリティを最優先する企業であり、「Secure by Design / Secure by Default」の原則を採用しているため、同期型パスキーのデフォルトでの使用は防止しています。RSA環境では、デフォルトではデバイスに紐づいたパスキーのみが利用可能であり、管理者による追加作業を必要とせずに、最大限のセキュリティをすぐに利用できます。

 まぁ、この辺りはポジショントークが入ってきていますが、Yes/No問題ではない、という点は真理だと思います。結局のところパスキーの登場をきっかけに企業における認証戦略を見直すことが重要ってことです。

Questions Organizations Must Ask Before Using Passkeys

まぁ、最後は当然のことながら自社サービスへの誘導ですね。とは言え、企業が自問すべきことについて触れられているのでここはみなさんちゃんと考えてみましょう。

When assessing whether to introduce passkeys, organizations should ask: How are our authenticators registered? Are there processes that safely handle the ‘I lost my authenticator’ scenario? What about the classification of users, applications and data?

Passkeys are one MFA method among many.  Yes, their phishing resistance is fantastic, but can users log in with it on their remote desktops?

For these reasons and many others, it’s important that your MFA system isn’t just technically up to date, but that it also supports a wide variety of MFA methods, such as QR codes, biometrics, OTP, push messages and FIDO passkeys.

It is also important that the processes around MFA are adapted to new threats. This goes far beyond the actual MFA system: Is your help desk also safe from social engineering attacks?

If passkeys make sense to you, then we want to help. Contact us to learn more or start a free, 45-day trial of ID Plus.

 パスキーを導入すべきかどうかを評価する際、組織は次のような質問を自問すべきです。「当社の認証情報はどのように登録されているか?」「認証情報を紛失した」というシナリオを安全に処理するプロセスはあるか?」「ユーザー、アプリケーション、データの分類についてはどうなっているか?」

パスキーは、数ある多要素認証(MFA)の方法のひとつです。 確かにフィッシング対策としては素晴らしいですが、ユーザーはリモートデスクトップ上でこれを使ってログインできるのでしょうか?

こうした理由やその他の理由から、MFAシステムは単に技術的に最新であるだけでなく、QRコード、生体認証、OTP、プッシュ通知、FIDOパスキーなど、多様なMFA方式をサポートしていることが重要です。

また、MFAに関連するプロセスが新たな脅威に対応していることも重要です。これは実際のMFAシステムをはるかに超えるものです。ヘルプデスクもソーシャルエンジニアリング攻撃から安全であるか?

パスキーが適切だとお考えであれば、ぜひご相談ください。詳細についてはお問い合わせいただくか、ID Plusの45日間無料トライアルをお試しください。

確かにパスキーは多要素認証の方法の一つ、として捉えて認証戦略について考えることは大切ですね。

ということでベンダのブログではありますが、結構書いてあることは重要だと思います。

日本企業・組織においてもパスキーを前向きに捉えて導入するためにもしっかりとシナリオを設計して導入を進めてほしいところです。