【はじめに】

前提としてパスキーの種類で"同期パスキー(Synced passkeys)"と"デバイス固定パスキー(Device-bound passkey)"があるのはご存知でしょうか

パスキーを導入したから大丈夫という事ではなく各々の違いを理解し利便性やセキュリティとしてどこを大事にするかで選定する必要があります。

【本文】

■Beyond Identityのパスキーの種類

では、早速Beyond Identityはどれに属するのでしょうか結論から言うと大まかにはデバイス固定パスキーに属し他端末への拡張も可能という回答になります。

端末内のパスキーの管理は"Beyond Identity Authenticator"というソフトウェアで行い、端末内のセキュリティチップ(TPMなど)に秘密鍵は格納され外部露出しない仕組みです。

また、他端末へのパスキーの拡張が端末同士で行える点、GUI上でパスキーの発行及び無効化が可能な点が最大の特徴です。※あくまで同期ではなく拡張

ただし、これまでの事をまとめるとそんな"同期パスキー"と"デバイス固定パスキー"の良いとこ取りは可能なのか？パスキー拡張時にクラウドと通信しているならダメなんじゃない？という意見が出てくるでしょう

その点をBeyond Identity独自の"Secure Credential Extension"という仕組みでできるだけセキュアに実装しているという訳です。

ではこれからSecure Credential Extensionとは何なのか、パスキーの拡張はどのように行うのかについてまとめていきます。

■Secure Credential Extensionと、パスキーの拡張方法

既存でパスキーが登録されている端末（以下、端末①）とパスキーを拡張する端末（以下、端末②）間にて厳格にポリシーを効かせることができるフローの事です。

端末が物理的に手元にあるか、拡張元の端末は健全か、端末①、端末②がポリシーに準拠しているかと様々な観点でセキュリティを担保しています。

下記に実際の拡張方法と合わせセキュリティ観点をまとめていきます。

1.パスキーを拡張する端末(端末②)でワンタイムのQRコードまたは9桁のコードを生成します

これにより、新しいデバイスが物理的に手元にあり、ユーザーが操作できる環境であることを証明します。

2.ユーザーは、生成されたコードを既存のデバイス(端末①)に入力します

既存でパスキーが登録されている端末(端末①)、パスキーを一方的にプッシュするのではなく、端末②からの明示的なリクエストにのみ応答します。

3.両方のデバイスがセキュリティ準拠(設定してあるポリシー)かどうか評価されます

どちらか一方でもポリシーを満たしていない場合、パスキーは拡張されません。

4.端末①がリクエストを検証し、ポリシー評価に成功すると新しいパスキーが作成されます

【さいごに】

Beyond Identityでは通信に関してセキュリティの担保を最大限行いつつユーザビリティも損なわないように開発しています。

セキュリティーキーやスマートカードの方が通信的には間違いはないのかもしれませんが物品管理が必要になってきます。

クラウドに秘密鍵をどうしても置きたくないという要望がない限りはBeyond Identityという製品も一度検討していただけますと幸いです。

----------------------------------------------------

執筆者：星野 幸哉

三井情報株式会社

ソリューション技術グループ ソリューション第二技術本部　インフラ第一技術部第二技術室