株式会社renue
renueについて
renueは、AIで業務を実装する会社です
AIコンサルティングから図面AI・広告運用エージェント・コールセンターAIまで、実際に動いているサービスをご覧いただけます。renueが何をしている会社か、まずはサービス一覧からご確認ください。
パスキーとは？パスワードレス認証とFIDO2・WebAuthn
パスキーは、公開鍵暗号を使ってサービスへログインするための認証情報です。サービス側は登録された公開鍵で署名を検証し、利用者は対応する認証器を使います。毎回共通のパスワードを送る方式とは異なり、対象サイトに結び付けて認証できることがフィッシング対策につながります。パスワードを入力しない認証のすべてがパスキーではなく、メールリンクやコード認証などとは仕組みを区別します。
FIDO Allianceのパスキー解説は、同期型と端末固定型、PINや生体による利用者検証を説明しています。FIDO2は、W3CのWebAuthnとFIDOのCTAPを組み合わせた仕様群です。WebAuthnはWebアプリが公開鍵認証を使うためのAPI等を定め、CTAPは外部認証器とのやり取りに関わります。製品名と標準仕様を同じものとして扱わず、対象の環境で対応する機能を確認する必要があります。
- 登録時に、サービスのアカウントと公開鍵等の認証情報を関連付ける。
- ログイン時に、サービスが認証に使うチャレンジを発行する。
- 利用者が認証器を使い、必要なPIN・生体等の検証を行って署名する。
- サービス側で署名、チャレンジ、対象サイト、利用者検証などの条件を確認する。
「署名が正しい」だけでログインを受け入れる実装にはしません。W3C WebAuthn Level 2の検証手順は、チャレンジ、オリジン、RP ID、アカウントと認証情報の対応、必要な利用者検証などを含みます。RPは認証を受け入れるサービス側を指します。導入するライブラリがこれらをどう検証するか、設定したドメインや利用者との対応が正しいかを確認します。
PINや生体の確認は、認証器を使う人の検証です。サイトへ指紋や顔そのものを送ることとは異なります。画面上の操作が少なくても複数要素を使う構成はありますが、パスキーという名称だけで全実装をMFAと決めつけるべきではありません。要素と検証条件の違いは、MFAと二段階認証の解説も参照してください。
同期型・端末固定型と、OS・ブラウザの対応を確認する
同期型は、パスキー提供者の仕組みで複数端末から使える構成です。端末固定型は、特定の認証器に結び付けて使う構成で、端末やセキュリティキーを失った場合に備えた別の認証器や復旧手順が重要になります。どちらを選ぶかは、利便性だけでなく、秘密鍵の保護、同期先の管理、アカウント復旧、必要な保証条件で決めます。
| 確認対象 | 同期型 | 端末固定型 |
|---|---|---|
| 複数端末での利用 | 提供者のアカウント・対応環境と同期条件を確認 | 別認証器の追加登録や、対応する別端末認証を確認 |
| 紛失・故障 | 提供者の復旧と、残った端末で利用できる条件を確認 | 予備認証器とサービス側の復旧を準備 |
| 企業の管理 | 個人用・会社用の同期先、登録の制限、退職時処理を確認 | 配布・保管・返却・交換と登録削除を管理 |
「秘密鍵は必ず一台の端末から出ず、すべての処理が端末内で終わる」と一般化するのは正確ではありません。例えばMicrosoft Password Managerの技術説明には、サービス側の保護された実行環境で認証情報の作成、署名応答や復旧検証を行う構成が示されています。ログイン先へ秘密鍵を渡さないことと、保存・同期を担う提供者の内部構成を区別します。
対応状況はOS名だけで判断しません。ブラウザ、バージョン、保存先、端末管理の設定を組み合わせて確認します。Googleの対応環境説明でも、パスキーの利用、Googleパスワードマネージャーへの保存、別端末を使う認証の条件は分けられています。WindowsのローカルなWindows Helloと、提供者による同期も別の構成です。
同じ提供者の端末間同期、異なる提供者への移行、スマートフォンで別のPCへのログインを承認する機能は、同一ではありません。導入前に実際の組み合わせで登録・ログイン・端末交換を試します。保存先を選ぶ際は、パスワードマネージャーの比較も参考に、業務用の認証情報を個人アカウントへ同期してよいか確認してください。
企業導入の設計｜IdP連携とアプリ側の実装を分ける
企業でパスキーを導入する方法には、IdPで認証して連携アプリへSSOする構成と、自社アプリが直接パスキーを受け入れる構成があります。IdPで有効にしたことだけで、各アプリの直接ログイン、復旧、認証が必要なAPIまで同じ制御になるとは限りません。どこで本人を確認し、各アプリが何を信頼してアクセスを許可するかを図にして整理します。
利用者についても、一般社員、管理者、外部委託先、顧客を分けます。管理者にはどの認証器を認めるか、同期型の保存先をどう扱うか、端末を管理できない利用者に何を用意するかを決めます。Microsoft Entraの同期型パスキー説明には、許可対象とプロファイルの設定、特権利用者で端末固定型を検討する考え方があります。これは同製品の条件であり、全IdPが同じ制御を持つという意味ではありません。
保証レベルへの対応も個別に判断します。NIST SP 800-63B-4のAAL3には、秘密鍵の非エクスポート性などの条件があります。同期型を含むすべてのパスキーが自動的に最も高い保証条件を満たすと考えず、対象の認証器、利用者検証、運用を照合します。米国政府向けガイドの保証レベルと、日本の個別の法令・契約上の要件は区別します。
自社アプリで直接実装する場合は、登録とログインだけでなく、認証情報の一覧、追加、削除、名前の変更、アカウントとの対応を設計します。既存セッションを持つ攻撃者が勝手に認証器を追加できないか、別ユーザーの認証情報を操作できないかも検証します。登録済み認証器を表示し、利用者が身に覚えのないものを確認・報告できる運用も検討します。
費用は、認証基盤のライセンス、認証器、アプリ改修、端末対応、移行、サポートと復旧を含めて比較します。市場規模や他社の成功率から自社の費用対効果を決めず、対象人数、認証回数、問い合わせ、例外対応を実測して判断します。認証後の権限、セッション、端末状態も含めた設計は、ゼロトラストの解説と合わせて確認してください。
導入・復旧・失効を試し、安全性と使いやすさを点検する
展開は、対応環境と利用者を限定した試行から始めます。通常の登録とログインに加えて、端末の交換・紛失、同期先へ入れない場合、ネットワーク制限、予備の認証器を使う場合まで試します。全社展開までの期間を一律に決めず、実際に解消できた条件と残る例外から展開範囲を判断します。試行の利用者が困った操作と、対応した担当者の作業も記録します。
- 対象サービス・利用者・端末と許可する保存先を決める。
- 登録、通常利用、追加認証器、別端末での利用を試す。
- 紛失、同期アカウントの復旧、認証器の失効を試す。
- 旧ログインと復旧経路を残す条件・期限・責任者を決める。
- 適用状況、失敗と問い合わせ、認証情報の追加・削除記録を点検する。
パスワードやコードによる代替ログインを残す場合は、その経路の強さと利用条件も確認します。パスキーで通常ログインを強くしても、弱い復旧手順で容易にアカウントを取り戻せる設計では迂回の余地が残ります。移行中の利用者を締め出さないことと、代替経路を無条件に開放しないことの両方を、具体的な手順で検証する必要があります。
紛失時には、新しい端末で使えることと、失った認証器・セッションを使えなくすることを分けます。提供者の保管庫から削除したことと、ログイン先サービスの登録を削除したことも同じとは限りません。予備認証器や復旧コードを準備し、会社では本人確認、承認、記録を伴って再登録します。日常の保管と復旧先の点検は、パスワード・認証情報の管理手順も参照してください。
フィッシング耐性は、端末の感染やログイン後のセッション窃取まで防ぐ保証ではありません。自社アプリでは、チャレンジ等の検証、認証器の追加と復旧、認証後の権限とセッションを含めて点検します。renueのAI脆弱性診断支援では、コード分析や合意した検証環境で、認証・権限に関わる弱点と改善の優先順位を調べる範囲を相談できます。セキュリティ診断の対象と手順も確認し、診断と改修・運用の担当を明確にして進めます。
