WebAuthnとは何ですか？
パスワードは破られます。フィッシングされ、スタッフィングされ、スプレーされ、流出します。Verizonの2026 Data Breach Investigations Report（DBIR）では、全侵害の39%のどこかで認証情報の悪用が確認されており、これは同レポートのデータセットで最も広範に見られる単一の手法でした。そのため、防御側はログイン経路からパスワードを排除するコントロールを優先しています。WebAuthnは、まさにそれを実現するために構築されたWorld Wide Web Consortium（W3C）の標準です。
Web Authenticationの略であるWebAuthnは、ユーザーをWebアプリケーションに認証するために、強力な公開鍵ベースの認証情報を作成および使用するためのブラウザAPIを定義するW3CのWeb標準です。パスワードのような共有シークレットをやり取りする代わりに、WebAuthnは非対称暗号を使用します。つまり、認証器がサイトごとに一意の鍵ペアを生成し、秘密鍵を安全なハードウェア内に保持し、公開鍵のみをサーバーと共有します。
W3C仕様では、これを正式に「ユーザーを強力に認証する目的で、Webアプリケーションによる強力で、証明付きで、スコープ化された、公開鍵ベースの認証情報の作成と使用を可能にするAPI」と定義しています。実際には、これは指紋スキャン、顔認証解除、または物理的なセキュリティキーを使用してWebアプリケーションにログインでき、サーバーは攻撃者が再利用できるものを一切受け取らないことを意味します。
WebAuthnは、Fast Identity Online (FIDO) Allianceと連携して開発されたFIDO2プロジェクトの中核コンポーネントです。FIDO2は、WebAuthn（ブラウザAPIレイヤー）とCTAP（Client to Authenticator Protocol）を組み合わせたもので、CTAPはUSB、近距離無線通信（NFC）、またはBluetooth Low Energy（BLE）を介して認証器デバイスとブラウザ間の通信を処理します。これらを組み合わせることで、Webにおけるパスワードレスかつフィッシング耐性のある認証の基盤が形成されます。
2つのインシデントは、パスワードモデルが大規模環境でどのような代償を伴うかを示しています。2021年、攻撃者は使用される想定ではなかったレガシーな仮想プライベートネットワーク（VPN）プロファイルを通じてColonial Pipelineに侵入したと、同社CEOが米国上院に証言しました。Colonialは攻撃を封じ込めるためにパイプラインを停止し、CISA advisoryで取り上げられたランサムウェア運用DarkSideのアフィリエイトに440万ドルの身代金を支払いました。その後、Department of Justiceはそのうち230万ドルを押収しました。2023年には、MGM Resortsが、2023年10月の8-Kによると、IDワークフローに対するソーシャルエンジニアリングから始まったサイバーインシデントにより、推定1億ドルの財務上のマイナス影響を報告しました。どちらのインシデントも、再利用可能なシークレットが起点でした。WebAuthnはそれをログイン経路から排除します。
WebAuthnと従来の認証の比較
従来の認証は共有シークレットに依存しています。パスワード、ワンタイムコード、プッシュ承認はいずれも、攻撃者が傍受、リプレイ、またはリアルタイムでフィッシングできるデータを送信します。WebAuthnは、共有シークレットを公開鍵暗号に置き換えることでこのモデルを変えます。秘密鍵は認証器ハードウェアから決して出ることがなく、再利用可能なものは何もネットワークを通過しません。
違いが最も重要になるのは、従来の方法が破綻するポイントです。
- フィッシング耐性。 パスワードベースおよびOTPベースの認証は、リアルタイムのフィッシングプロキシによって取得される可能性があります。WebAuthn認証情報はオリジンドメインに暗号学的にバインドされるため、login.example.comで登録された認証情報はlogin-example.comやその他の類似ドメインに対して認証されません。ブラウザはこれを、ユーザーの判断とは無関係に、プロトコルレベルで強制します。
- サーバー側の露出。 従来のシステムは、データベース侵害時に高価値ターゲットとなるパスワードハッシュや共有シークレットを保存します。WebAuthnが保存するのは公開鍵のみです。サーバーが完全に侵害されても、攻撃者がユーザーになりすますために使えるものは何も得られません。
- 認証情報の再利用。 ユーザーはサービス間でパスワードを再利用するため、 credential stuffingが大規模に有効になります。WebAuthnはrelying partyごとに一意の鍵ペアを生成するため、あるサービスで侵害された認証情報は別のサービスではまったく価値がありません。
- ユーザーの負担とセキュリティのトレードオフ。長いパスワードや頻繁なローテーションは理論上セキュリティを向上させますが、使い勝手を損ないます。WebAuthnはこのトレードオフを排除します。指紋スキャンや顔認証解除は、どのようなパスワードポリシーよりも強い認証保証を、より少ないユーザー負担で提供します。
結果として、WebAuthnは認証情報ベースの侵害の大半を引き起こす3つのベクトル、すなわちフィッシング、サーバー側の窃取、クロスサイトでの再利用を排除します。これらの違いを理解することが、プロトコルのコンポーネントがどのようにそれらの特性を強制するかを理解する基盤になります。
WebAuthnの主要コンポーネント
WebAuthnは、 W3C仕様で定義された3者アーキテクチャで動作します。
Authenticator: これは鍵ペアを生成し、認証アサーションに署名する暗号エンティティです。認証器は2つのカテゴリに分類されます。
- Platform authenticators はデバイスのオペレーティングシステムに組み込まれています。Windows Hello、Touch ID、Face IDなどです。ほぼ摩擦なく登録できますが、デバイスを失うと失われます。
- Roaming (cross-platform) authenticators は、YubiKeysやFIDOセキュリティキーのような持ち運び可能なハードウェアデバイスです。複数のデバイスで利用できますが、物理的な配布と在庫管理が必要です。
どのタイプを選んでも、セキュリティモデルは同じです。認証器はrelying partyごとに一意の鍵ペアを作成し、秘密鍵は認証器の安全な境界から決して出ません。
Relying Party (RP): これはWebアプリケーションです。WebAuthn APIを呼び出すクライアント側JavaScriptと、認証情報の保存および検証を処理するサーバー側コンポーネントで構成されます。RPが保存するのは公開鍵のみです。通常はドメイン名であるRP IDが、オリジンバインディングの暗号学的アンカーとして機能します。
User Agent (Browser): ブラウザは、認証器とrelying partyの間のすべてのやり取りを仲介します。オリジンポリシーを強制し、ドメイン間での認証情報の誤用を防ぎ、ユーザープライバシーを保護します。あるオリジンで登録された認証情報は別のオリジンでは使用できず、これがプロトコルレベルでフィッシングを防ぐ仕組みです。
WebAuthnはまた、登録時に認証器がその真正性を暗号学的に証明できるattestation frameworkも定義しています。これにより、企業は認証情報が未知またはコンシューマー向けデバイスではなく、信頼されたIT承認済みの認証器モデルから来ていることを検証できます。 FIDO Metadata Serviceは、認証器モデルに対するライブの失効およびアドバイザリの仕組みを提供します。
関係者と信頼境界を把握すれば、2つのセレモニーを対応付けて、どこで検証が失敗し得るかを正確に確認できます。
WebAuthnの仕組み
WebAuthnは、登録（認証情報の作成）と認証（アサーションの検証）という2つの暗号セレモニーを定義しています。どちらもチャレンジレスポンスプロトコルに従います。
- 登録（認証情報の作成）: サーバーは暗号学的にランダムなチャレンジを生成し、relying party情報、ユーザーアカウント詳細、許容される暗号アルゴリズムとともにクライアントへ送信します。クライアントは
navigator.credentials.create()を呼び出します。認証器は明示的なユーザー同意を要求し、新しい非対称鍵ペアを生成し、公開鍵、署名済みチャレンジ、credential ID、および（任意で）attestation証明書チェーンを含むattestationオブジェクトを返します。サーバーはattestationを検証し、署名を検証し、公開鍵が要求されたアルゴリズムと一致することを確認し、認証情報の公開鍵、credential ID、署名カウンターを保存します。重要なガードレール: 同一のパラメータであっても、navigator.credentials.create()は呼び出しごとに新しい認証情報を生成します。重複登録を防ぐには、 excludeCredentials parameterを使用する必要があります。 - 認証（アサーションの検証）: サーバーは新しいチャレンジを生成し、許可されたcredential IDのリストとともにクライアントへ送信します。クライアントは
navigator.credentials.get()を呼び出します。認証器はユーザーの存在または本人確認（ポリシーに応じて）を検証し、その後、保存された秘密鍵でチャレンジに署名します。サーバーは保存済みの公開鍵を取得し、アサーション署名を検証し、チャレンジ一致を検証し、ユーザー存在/本人確認フラグを確認し、オリジンとRP IDの一致を確認し、署名カウンターが増加していることを検証します。
署名カウンターの検証は、複製された認証器に対する防御です。カウンターが期待どおりに増加しない場合、認証情報の複製を示す証拠になります。
AAL2準拠のためには、User Presence（UP）だけでなくUser Verification（UV）を強制する必要があります。 syncable authenticators guidanceによると、検証者はUVが推奨されることを示し、応答を確認してUVフラグが設定されていることを確認しなければなりません。
組織によるWebAuthnの導入方法
WebAuthnが本番環境でどこで動作しているかを見ることで、評価者の多くが実際に問う「これは大規模環境で実証されているのか？」という疑問に答えられます。
- Google Accounts は最も明確なベンチマークです。Googleは2023年5月にパスキーの展開を開始し、2023年10月には個人アカウント向けに デフォルト化しました。開始から1年以内に、パスキーは4億超のアカウント全体で 10億回以上使用され、Googleは、日次ベースでパスキーがSMS OTPと認証アプリを合わせたものよりもすでに多く認証に使われていると報告しました。
- GitHub cited WebAuthn は、 2023年に2FAを義務化した際、利用可能な最も強力な2FAオプションとしてWebAuthnを挙げ、物理セキュリティキーやWindows Hello、Face IDのようなplatform authenticatorsを、フィッシングに対して最も脆弱性が低い方法と位置付けました。
- 商用プラットフォームも追随しています: Amazon、PayPal、Shopify、DocuSign、そして平均サインアップおよびサインイン時間を50%短縮したKayakは、いずれもWebAuthn対応のサインインを提供しています。これらの導入は、WebAuthnがコンシューマー規模で機能し、リカバリーワークフローを処理し、標準的なIDプロバイダーアーキテクチャと統合できることを示しています。
セレモニーと実環境での導入事例を理解したら、次の判断は、どの種類の認証器が自社環境に適しているかです。
WebAuthn認証器の種類
認証器の選択は、WebAuthn導入におけるセキュリティ保証レベル、ユーザー体験、運用オーバーヘッドを左右します。各タイプには、エンタープライズ計画において重要となる明確なトレードオフがあります。
- Platform authenticators はデバイスのオペレーティングシステムとハードウェアに組み込まれています。Windows HelloはTrusted Platform Module（TPM）に支えられたPIN、顔認識、または指紋を使用します。AppleデバイスはSecure Enclaveに支えられたTouch IDまたはFace IDを使用します。AndroidデバイスはGoogle Play Servicesを通じて指紋または顔認証解除を使用します。Platform authenticators 1carry the lowest enrollment friction because users already have the hardware, and biometric verification satisfies user verification (UV) requirements for AAL2 compliance without extra steps. 制約は、認証情報がデバイスに紐づくことです。ユーザーがノートPCやスマートフォンを失うと、同期されたパスキーを使用していない限り、それらの認証情報は失われます。
- Roaming (cross-platform) authenticators は、YubiKeys、Feitian BioPass keys、その他のFIDO2セキュリティキーなどの持ち運び可能なハードウェアトークンで、USB、NFC、またはBLEで接続します。複数のデバイスやオペレーティングシステムで利用できるため、特権アクセス、共有ワークステーション環境、高保証のユースケースにおける標準的な選択肢となっています。トレードオフは配布ロジスティクスです。物理デバイスの調達、発送、在庫管理、運用管理が必要であり、ユーザーはそれを携帯する必要があります。
- Synced passkeys は新しいカテゴリで、WebAuthn認証情報がプラットフォームのパスワードマネージャー（iCloud Keychain、Google Password Manager、または1Passwordのようなサードパーティーマネージャー）を通じて同期されます。同期されたpasskeysは、同じアカウントに接続された任意のデバイスで認証情報が存続するため、デバイス紛失時のリカバリー問題を軽減します。多くのエンタープライズユーザーにとって、これはWebAuthn導入における最大の摩擦点を取り除きます。トレードオフは、認証セキュリティが部分的に同期認証情報をホストするプラットフォームアカウントのセキュリティに依存することです。高保証環境では、IT管理のバックアップキーを備えたデバイスバインド型認証情報の方が依然として強力な選択です。
多くのエンタープライズ導入では組み合わせが使われます。日常利用にはplatform authenticators、登録済みバックアップとしてroaming key、そしてリスクプロファイルが許容する場合にはsynced passkeysです。適切な組み合わせの選択は、保証要件、ユーザー層、そして吸収可能な運用オーバーヘッドによって決まります。
認証器の選択は、得られるセキュリティ特性に直接影響します。次のセクションではそれを扱います。
WebAuthnのセキュリティ上の利点
WebAuthnは、フィッシング耐性、サーバー側の露出、規制準拠、クロスサイト攻撃防止にわたって具体的なセキュリティ上の利点を提供します。
- プロトコルレベルでのフィッシング耐性。 WebAuthnは認証情報をオリジンに暗号学的にバインドします。 FIDO Alliance NIST commentでは、攻撃者がフィッシング耐性のないAAL2認証器に追いついていると警告しています。WebAuthnはそのギャップを埋めます。
- サーバー上に共有シークレットが存在しない。FIDO2の公開鍵暗号モデルは、IDプロバイダーと認証器の間でシークレットを共有する必要をなくします。これはNIST SP 800-63B-4がverifier compromise resistanceと呼ぶものです。データベースが完全に侵害されても、攻撃者がリプレイできるものは何も得られません。
- 規制との整合性。 WebAuthnはNIST SP 800-63B-4 AAL2のフィッシング耐性要件を満たします。米国政府のOffice of Management and Budget（OMB）Memorandum M-22-09では、連邦機関向けのフィッシング耐性アプローチとしてW3C Web Authentication標準を直接挙げています。規制対象組織は、明確で監査可能な準拠経路を得られます。
- 人的要素の攻撃の排除。 2026 Verizon DBIR では、侵害の62%に人的要素が関与していました。WebAuthnは、2つの重要な人的攻撃面、すなわち弱いパスワードの選択とフィッシングへの脆弱性を排除します。パスワードが存在しなければ、ユーザーは悪いパスワードを選ぶこともできません。
- クロスサイトのcredential stuffing防止。各認証情報は特定のドメインに暗号学的にスコープされるため、サービス間での credential stuffingの有効性は大幅に低下します。
これらのセキュリティ特性は理論上のものではありません。WebAuthnを大規模に導入した組織は、すでに本番環境でそれらを検証しており、ユースケースはほぼすべての業界にまたがっています。
一般的なWebAuthnのユースケース
WebAuthnの導入は、認証情報ベースの攻撃が最も大きなビジネス影響をもたらすシナリオに集中しています。これらは、本番環境で最も頻繁に見られる導入パターンです。
- 特権アクセスと管理コンソール。VPNポータル、クラウド管理コンソール、インフラ管理パネルは、credential theftにとって最も価値の高い標的です。これらのアクセスポイントに対して、必須の第2要素として、または主要なパスワードレス方式としてWebAuthnを導入することで、フィッシングキットや認証情報ダンプが最も積極的に悪用する攻撃面を排除できます。通常、これはエンタープライズ展開の最初のフェーズです。
- 金融サービスおよび医療向けの顧客向けログイン。 認証情報侵害が侵害通知、規制上の罰則、直接的な金銭的損失を引き起こす規制業界では、顧客認証にパスキーを採用しています。銀行アプリケーション、患者ポータル、保険プラットフォームは、コンプライアンス要件（PCI DSS、HIPAAアクセス制御）とアカウント乗っ取り詐欺の削減という運用目標の両方を満たすためにWebAuthnを使用しています。
- 共有ワークステーションおよびキオスク環境。 病院、製造現場、小売業務では共有端末が使われており、パスワードベースのログインは遅く、ショルダーサーフィンに弱い傾向があります。Roaming authenticators（NFC対応セキュリティキーやバッジタップソリューション）は、共有デバイスに認証情報を入力することなく、数秒でユーザーを認証します。
- 従業員向けシングルサインオン（SSO）。 Okta、Azure AD、Ping Identityのようなプラットフォームを通じて、identity provider (IdP)レベルでWebAuthnを導入すると、フェデレーション環境内のすべての下流アプリケーションを単一の登録で保護できます。これは広範なカバレッジを得る最も効率的な方法です。IdPで一度WebAuthnを導入すれば、すべてのSecurity Assertion Markup Language（SAML）またはOpenID Connect（OIDC）relying partyがそのフィッシング耐性認証を継承するためです。
これらの各ユースケースは同じ原則を強化します。認証フローから再利用可能なシークレットを排除することに近づくほど、認証情報ベースの攻撃経路は少なくなります。とはいえ、WebAuthnを大規模に導入すると、チームが計画すべき運用上の複雑さが生じます。
WebAuthnの課題と制限
WebAuthnのセキュリティモデルは堅牢ですが、エンタープライズ導入では、チームが一貫して過小評価する運用上の複雑さが表面化します。
- 認証情報ライフサイクル管理。 エンタープライズWebAuthn導入における主な失敗モードは、暗号ではなく運用です。認証器の配布、デバイス紛失時の認証情報失効、更新ポリシー、認証失敗時のユーザーサポートについて、文書化されたプロセスが必要です。 FIDO lifecycle guidanceでは、登録、リカバリー、失効の各フェーズを詳細に扱っています。
- 認証器タイプの選択。 Platform authenticators（配布コストゼロ、ただしデバイスとともに失われる）、roaming authenticators（持ち運び可能だが物理配布が必要）、およびハイブリッドアプローチの間で戦略的な判断が必要です。それぞれで保証レベル、リカバリー要件、運用オーバーヘッドが異なります。
- レガシーアプリケーション統合。 環境内のすべてのアプリケーションがWebAuthnをネイティブにサポートしているわけではありません。SAML、OAuth、OpenID Connectのようなフェデレーションプロトコルとの統合に対応する必要があります。これは、複雑なIDフェデレーショントポロジーを持つ組織にとって大きな課題です。
- FIDOサーバーアーキテクチャの判断。 既存のIDプロバイダーにFIDOサーバーを統合するか、スタンドアロンのFIDOサーバーを導入するか、またはFIDO-server-as-a-serviceモデルを使用するかを選択する必要があります。これらはそれぞれ、認証情報保存アーキテクチャ、災害復旧手順、展開範囲に影響します。 FIDO server deployment guideでは、そのトレードオフを詳細に扱っています。
- 同期認証情報のトレードオフ。 主要プラットフォームのパスワードマネージャーを通じたパスキー同期は、ユーザーの負担を大幅に軽減しますが、認証セキュリティの一部をプラットフォームアカウントのセキュリティに移します。保証要件が最も高い場合、IT管理のバックアップキーを備えたデバイスバインド型認証情報の方が依然として強力な選択です。
運用上の複雑さに加えて、特定の実装判断はより長期的な露出を生みます。
- すべてのMFAをフィッシング耐性ありと見なすこと。 これは最も影響の大きい誤りです。TOTP、SMS OTP、または push notification MFAを導入してフィッシング耐性準拠を主張しても、露出は残ります。リアルタイムのフィッシングプロキシは、これらの方式では両方の要素を取得してリプレイできます。真のフィッシング耐性を実現するのは、verifier name bindingまたはchannel bindingを備えたWebAuthnのみです。
- 未認証の認証情報登録を許可すること。 CVE-2021-3632はKeycloakでこれを実証しました。ユーザーアカウントにデバイスが存在しない場合、誰でも新しいセキュリティデバイスを登録できました。登録は、すでに認証済みのセッション内、または検証済みの帯域外プロセスを通じて行われなければなりません。
- 不十分な登録フロー設計。使いにくい登録はユーザーの抵抗を生み、サポートチケット件数を増やします。登録ポータルは、認証済みセッション内でユーザーを登録へ案内し、許可される認証器について明確な指示を提供し、特定のデバイスが拒否された理由を説明する必要があります。
- フォールバックおよびリカバリーメカニズムの欠如。デバイス紛失、ハードウェア障害、または生体認証の問題に対する文書化されたフォールバック手順なしにWebAuthnを導入すると、ロックアウトシナリオが発生します。事前登録済みのバックアップ認証器、IT管理者の緊急アクセスコード、対面確認プロセスが必要です。
- セキュリティスタックから切り離してWebAuthnを導入すること。 WebAuthnは単独の解決策ではありません。NIST SP 1800-35によると、継続的な認証評価、デバイス健全性検証、コンテキスト認識型アクセスポリシー、およびエンドポイントセキュリティ基盤と統合されるべきです。 zero trust architectureでは、WebAuthnはアクセス判断に投入できる最も強力なシグナルの1つになります。
これらの課題は、適切な計画によって解決可能です。以下のプラクティスは、概念実証と本番対応の導入を分ける重要な判断をカバーしています。
WebAuthn実装のベストプラクティス
以下のプラクティスは、概念実証と本番対応のWebAuthn導入を分ける重要な判断をカバーしています。
AAL2のためにユーザー検証を強制する。 登録と認証の両方のセレモニーでuserVerification: "required"を設定し、サーバー側でUVフラグを検証します。準拠対象の導入では"preferred"に依存しないでください。
認証器ポリシーの強制にattestationを使用する。登録時にattestationを確認し、セキュリティ要件（たとえばFIDO L1+認証）を満たす認証器のみを許可します。AAGUID（認証器モデル識別子）ベースの許可リストを使用し、ライブの認証器ステータス確認のためにFIDO Metadata Serviceと統合します。
段階的に導入する。 FIDO phased rolloutの推奨は、段階的アプローチです。
- 高リスクアプリケーション（VPN、特権アクセス、管理コンソール）向けの第2要素WebAuthn
- 運用サポートを構築しながらのプラットフォーム全体への第2要素展開
- 成熟したユーザー層向けのdiscoverable credentialsとパスワードレスフロー
- 登録済みユーザー向けにレガシー認証を廃止した完全なパスワードレス化
このアプローチにより、WebAuthnをデフォルトにする前に、ポリシー、サポート、リカバリーワークフローを検証できます。
複数認証器によるリカバリー戦略を実装する。ユーザーごとに少なくとも2つの認証器を登録します。主認証器（たとえば日常利用のplatform authenticator）とバックアップ（たとえば安全に保管されたセキュリティキー）です。登録済みのリカバリー認証情報をユーザーアカウント設定に明確に表示してください。
署名カウンターを検証する。 すべての認証で署名カウンターが単調増加していることを確認します。増加しないカウンターは、認証器が複製されている可能性を示します。
想定内エラーと想定外エラーを分離する。WebAuthnエラーを明示的に追跡します。NotAllowedError, AbortErrorおよびCredential Managerのパスキーエラーを別個のシグナルとして分類し、ユーザーの負担とセキュリティ異常を区別できるようにします。
これらのプラクティスに従うことで、WebAuthn導入を本番対応の状態にできます。しかし、正しく構成されたWebAuthn展開であっても、完全なID防御にはなりません。WebAuthnを完全に回避する攻撃には、ログインセレモニーの外側で機能するコントロールが必要です。セッションハイジャック、認証後のラテラルムーブメント、そしてヘルプデスクへのsocial engineeringです。
SentinelOneがIDセキュリティを強化する方法
WebAuthnは認証情報のリプレイを減らしますが、本番環境で見られるすべてのID経路攻撃を止めるわけではありません。依然として、セッショントークンの窃取、デバイス侵害、ヘルプデスクへのソーシャルエンジニアリング、認証後のラテラルムーブメントに対処する必要があります。
Singularity™ Platformは、IDとエンドポイントのコンテキストを相関させることでそのギャップを埋めます。
- Singularity Identity は、不審なID挙動を検出し、攻撃者がディレクトリサービスやSSOワークフローを標的にした際に対応します。これは、WebAuthnがまったく触れないID基盤をカバーします。
- Singularity Endpoint は、デバイス上で振る舞いベースおよび静的AIモデルを実行し、認証情報窃取マルウェアや、ログインコントロールを完全に回避するhands-on-keyboard活動を阻止します。攻撃者がパスワードではなくセッションを狙う場合に重要となる、悪意あるパターンを人手を介さずリアルタイムで検出します。
- Purple AI™ は、セキュリティデータ全体を横断して推論し、調査を導き、次の対応を推奨します。2025 IDC Snapshotでは、顧客が脅威を63%速く特定していることが示されており、失敗したWebAuthnログインがユーザーの負担なのか、進行中のフィッシングキャンペーンなのかを判断する必要がある場合に重要です。
これらを組み合わせることで、ログインの前後両面でID攻撃経路を抑えます。
WebAuthnを、より広範な phishing defense programおよびインシデント対応ワークフローの中の1つの強力なシグナルとして扱えば、アカウント乗っ取りリスクと、何が起きたかを証明するために費やす時間の両方を減らせます。
デモをリクエストして、SentinelOneが認証と完全なID防御の間のギャップをどのように埋めるかをご確認ください。
ハイブリッド環境全体でリアルタイムのアイデンティティ保護とエンドツーエンドの可視性を実現し、露出の検出、認証情報の悪用防止、アイデンティティリスクの低減を行います。
主なポイント
WebAuthnは、公開鍵暗号を使用したパスワードレスかつフィッシング耐性のあるWeb認証のためのW3C標準です。認証情報を特定のドメインに暗号学的にバインドするため、認証情報のリプレイはアーキテクチャ上不可能になります。
エンタープライズでの導入を成功させるには、段階的な展開、attestationベースの認証器ポリシー、マルチデバイスのリカバリー戦略、およびより広範なセキュリティスタックとの統合が必要です。
よくある質問
Web Authenticationの略であるWebAuthnは、ユーザーをWebアプリケーションに認証するための強力な公開鍵ベースの認証情報を作成および使用するためのブラウザーAPIを定義するW3CのWeb標準です。
パスワードの代わりに、非対称暗号を使用します。認証器はサイトごとに一意の鍵ペアを生成し、秘密鍵を安全なハードウェア内に保持し、公開鍵のみをサーバーと共有します。これにより、認証情報の窃取やフィッシング攻撃の実行ははるかに困難になります。
WebAuthnの主要なセキュリティ特性は、暗号学的なドメインバインディングによるフィッシング耐性です。認証情報を登録すると、それはリライングパーティの正確なオリジンにバインドされます。認証時には、ブラウザがそのオリジンを署名付きレスポンスに暗号学的に含めるため、類似ドメイン上の攻撃者は認証情報をリプレイできません。
フィッシング以外にも、WebAuthnは公開鍵のみが保存されるためサーバー側での認証情報の窃取を排除し、各認証情報が単一のドメインに限定されるため、 credential stuffingも防止します。
WebAuthn と FIDO2 は関連していますが、同一ではありません。FIDO2 はより広範なプロジェクトであり、 FIDO Alliance が W3C と連携して策定したもので、2 つの仕様を組み合わせています。すなわち、WebAuthn（公開鍵認証情報を作成および検証するためのブラウザ API）と CTAP（Client to Authenticator Protocol。USB、NFC、または BLE を介した認証器とブラウザ間の通信を処理します）です。
WebAuthn は FIDO2 の Web 向けの半分です。アプリケーションには WebAuthn を実装します。CTAP は認証器ハードウェアとブラウザの間で動作します。
WebAuthn は、 ゼロトラスト アーキテクチャにおいて最も強力な認証シグナルの 1 つを提供します。 NIST SP 1800-35 によれば、継続的な認証評価、デバイスの健全性検証、コンテキスト認識型のアクセス ポリシーと統合されます。WebAuthn 認証情報はフィッシング耐性があり、ドメインにバインドされているため、より広範なアクセス判断に反映される高保証の本人確認ステップとして機能します。
実運用では、WebAuthn をエンドポイント テレメトリおよび行動分析と組み合わせることで、ポリシー エンジンに対して、パスワードや従来の MFA 手法よりも信頼性の高い認証シグナルを提供できます。
Can I Useによると、WebAuthn は世界のブラウザの約95%で利用可能です。すべての主要なデスクトップブラウザがこれをサポートしています: Chrome (v67+)、Firefox (v60+)、Safari (v14+)、および Edge (v18+)。モバイルでは、Android 向け Chrome、iOS 上の Safari、Samsung Internet がいずれも WebAuthn をサポートしています。
プラットフォーム認証器については、Windows 10+ には Windows Hello（顔認識、指紋認証、TPM 経由の PIN）が搭載されており、macOS/iOS 16+ は Touch ID と Face ID をサポートし、パスキー向けに iCloud Keychain 同期を提供します。また、Android 9+ は Google Play Services を介して指紋認証と顔認証によるロック解除を提供します。古い OS バージョンや、一部の制限されたエンタープライズブラウザ構成では、依然としてギャップが残っています。
WebAuthnは、公開鍵認証情報の作成と認証のためにブラウザーが実装するW3C API仕様です。パスキーはWebAuthn認証情報を指すユーザー向けの用語であり、多くの場合、プラットフォームプロバイダーを通じてデバイス間で同期される同期済み（クラウドバックアップ型）認証情報を特に指します。
すべてのパスキーは内部的にWebAuthnを使用していますが、すべてのWebAuthn認証情報が同期されるパスキーであるとは限りません。デバイスにバインドされたWebAuthn認証情報は、特定のハードウェアに紐付いたままです。
WebAuthn は、構成に応じて、単一要素（認証器の所持）、二要素（所持に加えて生体認証または PIN）、または多要素認証として機能します。
AAL2 準拠のためには、ユーザー検証（生体認証または PIN）を強制し、サーバー側で UV フラグを検証する必要があります。WebAuthn は、TOTP や SMS OTP などの従来の MFA 手法に代わるものであり、それらのいずれよりも強力なフィッシング耐性を提供します。
復旧計画がなければ、ユーザーはロックアウトされます。ベストプラクティスは、ユーザーごとに少なくとも2つの認証器を登録することです。日常利用のためのプライマリデバイスと、安全に保管されたバックアップです。
アカウント復旧プロセスには、IT管理者用の緊急アクセスコードと、バックアップ認証器が利用できない高保証環境向けの対面確認手順も含める必要があります。
はい。ただし、統合には計画が必要です。WebAuthnは、SAML、OAuth、またはOpenID Connectを使用するフェデレーテッド環境において、IDプロバイダー（IdP）レベルで動作します。IdPがWebAuthnの認証フローを処理し、その後、下流のアプリケーションにフェデレーショントークンを発行します。
これは、個々のアプリケーションごとではなくIdPでWebAuthnを導入することを意味し、フェデレーテッドサービス全体での展開を簡素化します。
ブラウザーは、認証のたびに認証器によって署名されるデータにオリジン（ドメイン）を暗号学的に含めます。中間者攻撃者は、認証アサーションを別のドメインに中継できません。なぜなら、認証情報が登録されたオリジン以外では署名が検証されないためです。
この保護は、TLSやユーザーの認識とは独立して、プロトコルレベルで機能します。
