Get your free and exclusive 80-page Banking Passkey Report
Blog-Post-Header-Image

PCI DSS 4.0の認証:パスキー

パスキー認証がPCI DSS 4.0のMFA要件をどのように満たし、セキュリティを強化し、カード会員データを取り扱う事業者にとってコンプライアンスを簡素化するかを解説します。

Vincent Delitz

Vincent

Created: July 15, 2025

Updated: July 16, 2025


See the original blog version in English here.

WhitepaperEnterprise Icon

60-page Enterprise Passkey Whitepaper:
Learn how leaders get +80% passkey adoption. Trusted by Rakuten, Klarna & Oracle

Get free Whitepaper

1. はじめに#

デジタル環境は絶えず進化しており、それに伴いサイバー脅威の巧妙さと頻度も増し続けています。決済カードデータは依然として悪意ある攻撃者の主要な標的であり、それを取り扱うすべての組織にとって堅牢なセキュリティ基準が不可欠です。決済カード業界データセキュリティ基準(PCI DSS)は、長年にわたりカード会員データを保護するためのベンチマークとして機能してきました。その最新版であるPCI DSS 4.0は、大幅な前進を意味し、特に認証要件を大幅に強化することで、現代の脅威に直接対処しています。

組織がこれらの新しい要求に取り組む中で、新しいテクノロジーが有望な解決策を提供しています。FIDO(Fast Identity Online)アライアンスの標準とWebAuthnプロトコルに基づいて構築されたパスキーは、この新しい認証の波の最前線にあります。パスキーはパスワードレスでフィッシング耐性のあるアプローチを提供し、機密データへのアクセスを保護する方法を改善します。本記事では、PCI DSS 4.0がもたらした重要な変更点、特にセキュアな認証に関する点を分析し、パスキー認証の能力を探り、このテクノロジーを活用してコンプライアンスを達成・維持するためのロードマップを提供します。

この探求は、この新しいフロンティアを航海する組織にとって、2つの重要な問いを投げかけます。

  1. 認証PCI DSS 4.0が認証の基準を引き上げる中、組織はユーザーやセキュリティチームに過度な負担をかけることなく、これらの厳格な新要件をどのように効果的に満たすことができるのでしょうか?
  2. パスキーとPCIコンプライアンスパスキーのような新しいテクノロジーは、PCI DSS 4.0の認証コントロールを満たし、セキュリティを強化し、運用効率を向上させることができるのでしょうか?

本記事はこれらの問いに答え、技術専門家をより安全でコンプライアンスに準拠した未来へと導くことを目指します。

2. PCI DSSとバージョン4.0への変更点の理解#

現在のコンプライアンス環境におけるパスキーの役割を理解するためには、PCI DSSのフレームワークとバージョン4.0によって示された重要な進化を理解することが不可欠です。

2.1 PCI DSS(Payment Card Industry Data Security Standard)とは?#

PCIデータセキュリティ基準は、決済データを保護するために設計された世界的な情報セキュリティ基準です。これは、カード会員データを保存、処理、または送信するすべての事業体(加盟店、プロセッサー、アクワイアラーイシュアー、サービスプロバイダーを含む)に適用されます。この基準は、主要な決済カードブランドによって策定され(American Express、Discover Financial Services、JCB International、MasterCardVisa)、2006年9月7日にPCIセキュリティ基準審議会(PCI SSC)を設立し、その継続的な進化を管理しています。PCI DSSは、決済データのライフサイクル全体にわたる保護のベースラインを形成する、技術的および運用上の要件の包括的なセットで構成されています。

2.2 PCIセキュリティ基準審議会(PCI SSC)とその使命#

PCI SSCは、決済業界のステークホルダーを結集し、世界中の安全な決済のためのデータセキュリティ基準とリソースを開発・推進する世界的なフォーラムとして運営されています。PCI DSS以外にも、同審議会は決済セキュリティのさまざまな側面に対応する一連の基準を管理しています。その使命は、ステークホルダーによる教育、意識向上、効果的な実装を推進する基準とサポートサービスを開発することにより、グローバルな決済アカウントデータのセキュリティを強化することです。

2.3 PCI DSS 4.0への進化:主な推進要因と目的#

PCI DSS 4.0基準は2022年3月に正式にリリースされ、その後ステークホルダーからのフィードバックに対応するためのマイナーリビジョン(v4.0.1)が行われました。これは、近年で最も重要な基準の更新となります。この進化の主な推進要因は、ますます巧妙化するサイバー脅威の状況と、決済業界内の変化する技術環境に対応する必要性でした。

PCI DSS 4.0の主な目的は以下の通りです。

  • 決済業界の進化するセキュリティニーズへの対応: AIベースのフィッシングなど、現在および新たな脅威に対して基準が有効であり続けることを保証する。
  • 継続的なプロセスとしてのセキュリティの推進: 特定時点でのコンプライアンスから、継続的なセキュリティ規律へと焦点を移行する。
  • 検証方法と手順の強化: コンプライアンス評価の厳格さと一貫性を向上させる。
  • 柔軟性の追加と追加的な方法論のサポート: 組織がセキュリティ目標と成果を達成する方法について、より多くの裁量を与える。

2.4 4.0における中核的な変更点:セキュリティ成果、継続的セキュリティ、カスタマイズされた実装、および移行スケジュールへの焦点#

PCI DSS 4.0は、組織がコンプライアンスに取り組む方法に影響を与えるいくつかの根本的な変更を導入しています。

規範的なコントロールからセキュリティ成果への焦点の移行

極めて重要な変更は、主に規範的なコントロールからセキュリティ成果の重視への移行です。基準自体がこの柔軟性について詳しく説明しています。

第8章:PCI DSSの実装と検証のためのアプローチ

セキュリティ目標を達成する方法の柔軟性をサポートするために、PCI DSSを実装し検証するための2つのアプローチがあります。

カスタマイズされたアプローチは、各PCI DSS要件の目的に焦点を当て、事業体が定義された要件に厳密に従わない方法で、要件に記載された目的を満たすためのコントロールを実装することを可能にします。

この移行は、PCI DSS 3.2.1が「何を」すべきかについて詳細な指示を提供していたのに対し、バージョン4.0では組織が要件を「どのように」満たすかについてより多くの柔軟性を許容することを意味します。企業は、自社の環境に最も適したコントロールを実装できますが、それらのコントロールが規定のセキュリティ目標を達成することを証明できる必要があります。これは、パスキーのような革新的な技術を採用する際に特に重要で、古い、より厳格なコントロールの記述にはうまく適合しなかったかもしれません。しかし、この柔軟性には、組織が徹底的なリスク評価を行い、選択したコントロール方法論を明確に正当化するという期待が伴います。

継続的セキュリティ(通常業務)

PCI DSS 4.0のもう一つの重要な原則は、セキュリティを継続的な通常業務(BAU)プロセスとして推進することです。基準はこれを第5章で詳述しています。

第5章:PCI DSSを通常業務プロセスに実装するためのベストプラクティス

通常業務プロセスを実装する事業体は、セキュリティコントロールが...通常業務の一環として正しく実装され、適切に機能し続けることを保証するための措置を講じています。

一部のPCI DSS要件は、セキュリティコントロールを監視してその有効性を継続的に保証することにより、BAUプロセスとして機能することを意図しています。

この「通常業務」(BAU)プロセスの重視は、組織がセキュリティを日常活動に組み込む必要があることを意味します。これは、セキュリティを後回しにしたり、年に一度の大騒ぎにしたりするのではなく、運用の不可欠な部分としてセキュリティ文化を育むことです。これにより、継続的な監視、定期的な評価、適応的なセキュリティ体制が確保され、カード会員データの持続的な保護が保証されます。パスキーの実装においては、これはその有効性、ユーザーの採用パターン、および新たな脅威を継続的に監視し、セキュリティを特定時点でのコンプライアンス活動ではなく、持続的な取り組みにすることを意味します。

カスタマイズされた実装と対象リスク分析

PCI DSS 4.0の重要な新機能は、厳格なリスク評価と本質的に関連付けられた、カスタマイズされた実装の正式なオプションです。基準は、要件12.3.2でこの関連性を義務付けています。

要件12.3.2:組織のポリシーとプログラムによる情報セキュリティのサポート

事業体がカスタマイズされたアプローチで満たす各PCI DSS要件について、対象リスク分析が実施される。これには...文書化された証拠...上級管理職による承認、および少なくとも12ヶ月に一度の対象リスク分析の実施が含まれる。

この正式化されたオプションにより、組織は厳格な規範的手法に固執するのではなく、独自の環境に合わせた新しい技術や革新的なコントロールを使用してセキュリティ目標を達成できます。しかし、引用が強調するように、この柔軟性は、カスタマイズされた各コントロールに対して対象リスク分析を実行することに基づいています。この分析は文書化され、上級管理職によって承認され、毎年レビューされる必要があります。その後、第三者の評価者(認定セキュリティ評価機関またはQSA)が、リスク分析を含む組織の文書化されたアプローチをレビューし、特定のテスト手順を開発することによって、これらのカスタマイズされたコントロールを検証します。この経路は、パスキーのようなソリューションの重要な実現要因であり、組織がリスク評価を通じて自社のアプローチがセキュリティ目標を満たすことを証明できれば、その高度なセキュリティ機能を効果的に活用できます。堅牢なリスク分析に裏打ちされた実装のカスタマイズ能力は、脅威と防御技術の両方の急速な進化が、厳格で規範的なコントロールを時間とともに適応しにくくするという理解を反映しています。

移行スケジュール

PCI DSS 3.2.1は、2024年3月31日までv4.0と並行して有効でしたが、その後廃止されました。PCI DSS 4.0で導入された新しい要件は、2025年3月31日までベストプラクティスと見なされていました。この日以降、これらの新しい要件はすべての評価で必須となります。この段階的なアプローチは、組織が変更を理解し、計画し、実装するための期間を提供しました。

これらの変更は、総じて、決済カードセキュリティに対するより成熟し、適応性があり、リスクに焦点を当てたアプローチを示しており、より強力で現代的な認証メカニズムの採用の舞台を整えています。

3. 賭け金は高い:PCI DSS非準拠の影響#

PCI DSS要件を遵守しないことは単なる見落としではありません。それは、組織の財務安定性、法的地位、評判に深刻な影響を与える可能性のある、重大かつ多面的な結果を伴います。

3.1 金銭的ペナルティ#

非準拠の最も直接的な結果は、金銭的ペナルティの賦課です。これらの罰金は通常、PCI SSCから直接ではなく、アクワイアリングバンクや決済代行業者によって課されます。ペナルティは、処理する取引量(これにより、年間600万件以上の取引を行うレベル1から、2万件未満のeコマース取引を行うレベル4までの加盟店レベルが決定される)および非準拠の期間と重大度に応じて、月額5,000ドルから100,000ドルと高額になる可能性があります。例えば、数ヶ月間非準拠であったレベル1の加盟店は、この範囲の上限に近いペナルティに直面する可能性が高く、小規模なレベル4の事業者は月額5,000ドルに近い罰金を科される可能性があります。

これらの罰金が毎月繰り返される負担になり得ることを理解することが重要です。この持続的な財務的圧力は、決済代行業者が非準拠の事業者に課す可能性のある取引手数料の増加によってさらに悪化する可能性があり、_非準拠_の累積コストが_コンプライアンスを達成・維持_するために必要な投資をはるかに上回ることを意味します。これにより、コンプライアンスは単なるコストセンターではなく、重要なリスク軽減投資として再定義されます。パスキーのような強力な認証を含む堅牢なセキュリティ対策への投資は、これらのより大きく、しばしば予測不可能で、潜在的に壊滅的なコストを回避するための財政的に賢明な決定となります。

3.2 法的および規制上の影響#

直接的な罰金に加えて、非準拠は、特にデータ侵害につながった場合、深刻な法的問題を引き起こす可能性があります。データが漏洩した顧客は訴訟を起こす可能性があり、カードブランドも法的措置を取る可能性があります。非準拠の状態にあると、原告が組織側の過失を証明することがかなり容易になり、高額な和解金や判決につながる可能性があります。

3.3 評判の毀損と顧客信頼の喪失#

おそらく最も損害が大きいのは、定量化は難しいものの、組織の評判への害です。一度のコンプライアンス違反、特にデータ侵害につながるものは、顧客の信頼を著しく損なう可能性があります。一度失われた信頼を取り戻すのは難しく、しばしば顧客離れ、競合他社へのビジネスの喪失、ブランドイメージへの長期的な損害につながります。繰り返される、または重大な違反は、カードブランドやアクワイアリングバンクによる組織の決済処理権限の取り消しにつながることさえあり、事実上、カード決済を受け入れる能力を断ち切られます。これは、コンプライアンスを単なる技術的要件としてではなく、ブランドの信頼と事業継続性の基本的な構成要素として見ることの重要性を強調しています。

3.4 データ侵害の補償費用#

非準拠がデータ侵害の一因となった場合、組織は罰金や訴訟費用に加えて、多額の補償費用を負担する可能性が高くなります。これらの費用には、影響を受けた顧客への無料の信用監視、個人情報盗難保険、不正請求やサービス手数料の払い戻しなどのサービスの提供が含まれる場合があります。さらに、漏洩した決済カードの再発行費用は、1枚あたり3ドルから5ドルと見積もられており、多数のカード会員に影響を与える侵害の場合、すぐに数百万ドルに達する可能性があります。逆に、組織が完全にPCI DSSに準拠している状態で侵害を受けた場合、関連する罰金は減額されたり、免除されたりすることさえあります。なぜなら、コンプライアンスは過失ではなく、セキュリティへのデューデリジェンスとコミットメントを示すからです。

潜在的なマイナスの結果の数々は、PCI DSSコンプライアンスが、決済カードエコシステムに関与するあらゆる事業体にとって、現代の事業運営に不可欠な側面であることを浮き彫りにしています。

4. PCI DSS 4.0の強化された認証コントロール:要件8の詳細#

PCI DSSの要件8は、常にこの基準の礎石でした。バージョン4.0では、その規定が大幅に強化され、機密性の高いカード会員データおよびそれを処理するシステムへの不正アクセスを防ぐ上での堅牢な認証の重要な役割を反映しています。

4.1 要件8の概要:システムコンポーネントへのアクセスを識別し認証する#

要件8の主な目的は、カード会員データ環境(CDE)内またはそれに接続されたシステムコンポーネントにアクセスするすべての個人が一意に識別され、堅牢に認証されることを保証することです。これは、不正アクセスを防ぎ、すべての操作が特定の既知のユーザーに追跡できるようにすることで、カード会員データの完全性とセキュリティを維持するために重要であり、それによって個人の説明責任を確立します。

4.2 強化された多要素認証(MFA)の義務化#

PCI DSS 4.0における大きな進化は、多要素認証(MFA)要件の拡大と強化です。

  • CDEアクセスに対する普遍的なMFA: PCI DSS 3.2.1が主に管理者アクセスとCDEへのすべてのリモートアクセスにMFAを義務付けていたのに対し、バージョン4.0ではCDEへの_すべて_のアクセスにMFAを要求します。これには、アクセスがネットワーク内からか外からかにかかわらず、管理者、一般ユーザー、およびサードパーティベンダーによるアクセスが含まれます。この大幅な拡大は、PCI SSCがMFAを基本的なセキュリティコントロールとして認識していることを示しています。
    基準はこれらの要件を次のように規定しています。

    要件8の抜粋

    「8.4.1 管理者権限を持つ担当者によるCDEへのすべての非コンソールアクセスに対してMFAが実装されている。」 

    「8.4.3 事業体のネットワーク外から発信され、CDEにアクセスまたは影響を与える可能性のあるすべてのリモートアクセスに対してMFAが実装されている。」 

  • 要素の要件: MFAの実装は、認識されている3つの認証要素タイプのうち少なくとも2つを使用する必要があります。

    • 知識要素(例:パスワード、PIN)
    • 所有要素(例:トークンデバイス、スマートカード、またはパスキーを保持するデバイス)
    • 生体要素(例:指紋や顔認識などの生体データ)。重要なのは、これらの要素は独立している必要があり、つまり1つの要素が侵害されても他の要素が侵害されないことです。
  • MFAシステムの完全性: MFAシステムは、リプレイ攻撃(攻撃者が認証データを傍受して再利用する攻撃)に耐えるように設計され、必要なすべての認証要素が正常に検証された後にのみアクセスを許可する必要があります。

  • 不正なバイパスの禁止: MFAは、管理者を含むいかなるユーザーによってもバイパスされてはならず、特定の文書化された例外が管理によってインスタンスごとに限られた期間許可される場合を除きます。

  • フィッシング耐性認証を例外として: PCI DSS 4.0は、フィッシング耐性のある認証要素に関する追加のガイダンスも導入しており、これは場合によってはMFAの意図を満たすことができます。

    要件8の抜粋

    「この要件は...フィッシング耐性のある認証要素のみで認証されるユーザーアカウントには適用されない。」 — 8.4.2への適用性に関する注記 

    「フィッシング耐性認証...フィッシング耐性認証の例にはFIDO2が含まれる。」 — 付録G、フィッシング耐性認証の用語集定義 

    これらの抜粋で強調されているように、フィッシング耐性認証の意味合いについては、次のセクション(4.3)でさらに詳しく説明します。

4.3 フィッシング耐性認証の重視#

PCI DSS 4.0は、フィッシング耐性のある認証方法の使用を特に重視しています。これは、従来の認証情報を侵害するフィッシング攻撃の蔓延と成功への直接的な対応です。

  • MFAの代替/補完としてのフィッシング耐性認証:

    • 要件8.4.2の下での重要な進展は、フィッシング耐性認証方法が、事業体のネットワーク内から発信されるCDEへのすべての非管理者アクセスに対して、従来のMFAの_代わり_に使用できることです。これは、本質的にフィッシング耐性のあるパスキーのような技術にとって重要な規定です。これは、PCI SSCがこれらの高度な方法が、この特定のユースケースにおいて、一部の従来のMFAの組み合わせと同等かそれ以上の保証レベルを提供すると見なしていることを示しています。
  • **しかし、CDEへの管理者アクセス(要件8.4.1)および事業体のネットワーク外からCDEへのすべてのリモートアクセス(要件8.4.3)については、フィッシング耐性認証が強く推奨される一方で、MFA要件を満たすためには少なくとも他の1つの認証要素と組み合わせる必要があります。**この区別は、パスキーの実装に微妙なアプローチを必要とし、一般の内部ユーザーにはパスキー単独で十分であるが、よりリスクの高いアクセスシナリオではパスキーと別の要素を組み合わせるという階層的な戦略が必要になる可能性があります。

  • FIDOの認識と専門家の洞察: 基準は、特にFIDOベースの認証(パスキーの基盤)を、その堅牢なフィッシング耐性特性のためにMFAを達成するための好ましい方法として言及しています。このトピックに関するさらなる洞察は、PCI SSCのポッドキャスト「Coffee with the Council」のエピソード「Passwords Versus Passkeys: A Discussion with the FIDO Alliance」で共有されました(https://blog.pcisecuritystandards.org/coffee-with-the-council-podcast-passwords-versus-passkeys-a-discussion-with-the-fido-alliance)。

    ポッドキャストで、PCI SSCのVP Distinguished Standards ArchitectであるAndrew Jamieson氏は、これらの技術の価値を強調しました。

    「フィッシング耐性認証は素晴らしい技術だと改めて強調したいです。これは、私たちがパスワードで抱えている問題の多くを解決できるものです。そして、人々が認証にどの技術を導入するかを検討する際には、フィッシング耐性認証とその可能性を検討することを強くお勧めします。しかし、それが人々が慣れ親しんだものとは少し異なること、そしてそれを自社の認証アーキテクチャ全体に正しく、安全に統合する方法を検討する必要があることも理解しておく必要があります。」

    FIDO AllianceのChief Marketing OfficerであるMegan Shamas氏(FIDO Leadership参照)は、これらの技術が表す根本的な変化と、ポリシーが適応する必要性を強調しました。

    「これは、私たちが慣れ親しんでいる『パスワード+要素、要素、要素』とは根本的に異なります。私たちは技術を進化させてきました。そして今、人々もそれに合わせて要件やポリシーを進化させる必要があります。それが、組織がフィッシング可能な認証を排除するための正しい道を歩む助けとなるでしょう。」

    この共同の見解は、業界がより安全で現代的な認証方法へと移行していることを示しています。

4.4 新しいパスワードとパスフレーズの要件(使用する場合)#

PCI DSS 4.0はMFAとフィッシング耐性のある方法を強く推進していますが、パスワードやパスフレーズがまだ使用されている場合の要件も強化しています。

  • 長さと複雑性の増加: 最小パスワード長はv3.2.1の7文字からv4.0では12文字に増加しました(システムが12文字をサポートしていない場合は少なくとも8文字)。パスワードには数字とアルファベットの両方を含める必要があります。
  • パスワード変更頻度: パスワードが認証に使用される_唯一_の要素である場合(つまり、そのアカウントのそのアクセスにMFAが適用されていない場合)、少なくとも90日ごとに変更する必要があります。この要件は、アクセスにMFAが実装されている場合、または組織がリアルタイムでアクセスを動的に評価する継続的なリスクベースの認証を採用している場合には免除されます。

パスワード規則の大幅な強化、拡大されたMFAの義務化、そしてフィッシング耐性アプローチの明確な支持は、PCI SSCからの戦略的な方向性を示しています。それは、主要または唯一の認証メカニズムとしてのパスワードへの依存を体系的に減らすことです。パスワードは長い間セキュリティの弱点として認識されており、PCI DSS 4.0は、そのスタンドアロンでの使用をより厳格で魅力の少ないものにし、同時により強力で現代的な代替手段を推進することで、その固有のリスクを積極的に軽減しようとしています。

これらの変化を明確に示すために、次の表はPCI DSS 3.2.1と4.0の間の主要な認証の側面を比較しています。

表1:認証における主な違い:PCI DSS 3.2.1 vs. 4.0

特徴PCI DSS 3.2.1PCI DSS 4.0
CDEアクセスに対するMFA非コンソール管理者アクセスおよびCDEへのすべてのリモートアクセスに義務付け。CDEへのすべてのアクセス(管理者、非管理者、内部、リモート)に義務付け。
パスワード長(最小)7文字(数字とアルファベット)。12文字(数字とアルファベット)。システムが12文字をサポートしない場合は8文字。
パスワード変更頻度90日ごと。パスワードが唯一の要素である場合は90日ごと。MFAまたはリスクベース認証が使用されている場合はより長くてもよい。
フィッシング耐性の重視限定的で、主に一般的なセキュリティ意識向上を通じて対処。強い重視。フィッシング耐性認証は特定の内部CDEアクセスに対してMFAを代替できる(要件8.4.2)。FIDOが明示的に言及されている。
パスキー/FIDOの使用主要な方法として明示的に対処されていない。FIDOベースの認証が好ましいMFA方法として引用されている。フィッシング耐性のある方法(パスキーなど)がMFA要件を満たす上で特定の役割を与えられている。

PCI DSS 4.0におけるこの認証への heightened focus は、組織が現在の戦略を再評価し、パスキーのようなより回復力のあるソリューションを探求するための明確な方向性を示しています。

なぜパスキーはエンタープライズにとって重要なのか?

エンタープライズ向けパスキー

世界中のエンタープライズは、脆弱なパスワードとフィッシングにより深刻なリスクに直面しています。パスキーは、エンタープライズのセキュリティとUXのニーズを満たす唯一のMFA手法です。私たちのホワイトペーパーでは、パスキーを効率的に実装する方法と、そのビジネスインパクトについて解説しています。

エンタープライズ向けパスキー

Download free whitepaper

5. パスキー:フィッシング耐性認証の未来#

FIDOアライアンスの標準に基づいたパスキーは、従来のパスワードや一部のレガシーなMFA形式よりも、根本的により安全でユーザーフレンドリーな代替手段を提供します。

5.1 パスキーとは?(FIDO標準、WebAuthn)#

パスキーは、ユーザーがパスワードを入力することなくウェブサイトやアプリケーションにサインインできるデジタル認証情報です。これらは、FIDOアライアンスによって開発されたオープンな仕様セットであるFIDO2標準に基づいて構築されています。WebAuthnは、ブラウザやウェブアプリケーションが暗号鍵ペアを使用して強力でフィッシング耐性のある認証を実行できるようにするWorld Wide Web Consortium(W3C)の標準です。本質的に、パスキーはこれらのFIDO2標準の実装であり、ウェブ環境での対話にはWebAuthnを活用します。これらは、従来のパスワードを、スマートフォン、コンピュータ、またはハードウェアセキュリティキーなどのユーザーのデバイスに安全に保存された一意の暗号鍵に置き換えます。

5.2 パスキーの仕組み:暗号技術、デバイスバインディング、生体認証/PIN#

パスキーのセキュリティは、公開鍵暗号方式に根ざしています。ユーザーがサービス(「リライングパーティ」またはRP)にパスキーを登録すると、一意の暗号鍵ペアが生成されます。

  • 秘密鍵:ユーザーのデバイスに安全に保存されます。この鍵は、ハードウェアセキュリティモジュール(例:TPMやSecure Enclave)内に存在する場合があります。秘密鍵はこの安全なストレージから決して離れません(後述する同期パスキーの場合を除く)。
  • 公開鍵リライングパーティ(ウェブサイトまたはアプリケーションサービス)に送信されて保存され、ユーザーのアカウントに関連付けられます。

認証中のプロセスは次のとおりです。

  1. リライングパーティは、一意の「チャレンジ」(ランダムなデータ)をユーザーのデバイスに送信します。
  2. 秘密鍵をアンロックして使用するために、ユーザーはデバイス上でローカル検証を実行します。これには通常、生体認証識別子(指紋や顔スキャンなど)の使用、デバイスPINの入力、またはパターンの描画が含まれます。重要なのは、この生体データやPINはユーザーのデバイスから決して離れず、リライングパーティに送信されないことです。
  3. アンロックされると、デバイス上の秘密鍵がリライングパーティから受け取ったチャレンジに署名します。
  4. この署名されたチャレンジ(「アサーション」)がリライングパーティに返送されます。
  5. リライングパーティは、そのユーザーに対応する保存された公開鍵を使用して、アサーションの署名を検証します。署名が有効であれば、認証は成功します。

パスキーには主に2つのタイプがあります。

  • 同期パスキー これらのパスキーは、AppleのiCloudキーチェーンやGoogleパスワードマネージャーなどのクラウドベースの認証情報マネージャーを使用して、ユーザーの信頼できるデバイス間で同期できます。これにより利便性が提供され、あるデバイスで作成されたパスキーを、同じエコシステム内で同じユーザーが所有する別のデバイスで使用できます。
  • デバイス固定パスキー これらのパスキーは、USBハードウェアセキュリティキー(例:YubiKey)や特定の電話のアプリケーションなど、特定の物理的な認証器に結び付けられています。パスキーはこの特定のデバイスから離れません。

この暗号基盤とローカルのユーザー検証プロセスは、多くの一般的な攻撃ベクトルに直接対処する本質的なセキュリティ上の利点を提供します。

5.3 本質的なセキュリティ上の利点:フィッシング耐性、共有秘密の不在、クレデンシャルスタッフィングおよびアカウント乗っ取り(ATO)からの保護#

パスキーの設計は、従来の認証方法に比べていくつかのセキュリティ上の利点を提供します。

  • フィッシング耐性: これは基盤となる利点です。パスキーは、作成された特定のウェブサイトのオリジンリライングパーティIDまたはRP ID)に暗号的にバインドされています。ユーザーが騙されて正規のサイトを模倣した偽のフィッシングサイトにアクセスした場合、ブラウザまたはオペレーティングシステムは現在のドメインがパスキーに関連付けられたRP IDと一致しないことを認識します。その結果、パスキーは単に機能せず、認証は失敗します。これにより、フィッシングの試みを識別する負担が、しばしば間違いを犯しやすい人間のユーザーから、テクノロジー自体の堅牢なセキュリティプロトコルへと移ります。
  • 共有秘密の不在 パスキーでは、ユーザーとサーバーの両方が知っていて盗まれる可能性のあるパスワードのような「共有秘密」は存在しません。認証に不可欠なコンポーネントである秘密鍵は、ユーザーの安全なデバイスから決して離れません。サーバーによって保存される公開鍵は、秘密鍵と数学的に関連付けられていますが、秘密鍵を導き出したり、ユーザーになりすましたりするために使用することはできません。これは、リライングパーティのサーバーが侵害され、公開鍵が盗まれたとしても、対応する秘密鍵がなければ攻撃者にとって無用であることを意味します。
  • クレデンシャルスタッフィングおよびリプレイ攻撃からの保護: 攻撃者が盗んだユーザー名とパスワードのリストを使用してさまざまなアカウントへのアクセスを試みるクレデンシャルスタッフィング攻撃は、盗んで再利用するパスワードがないため効果がありません。さらに、各パスキー認証には一意のチャレンジレスポンスメカニズムが含まれます。秘密鍵によって生成される署名は、その特定のログインセッションで受信したチャレンジに固有のものであり、攻撃者が認証アサーションを傍受して後で再生して不正アクセスを得ることを不可能にします。
  • アカウント乗っ取り(ATO)リスクの大幅な削減: フィッシングを効果的に無力化し、共有秘密を排除し、クレデンシャルスタッフィングやリプレイ攻撃を防ぐことにより、パスキーはアカウント乗っ取りに使用される主要な攻撃ベクトルを劇的に削減します。攻撃者はユーザーの認証情報を簡単に入手したり悪用したりできないため、ATOが成功する可能性は急落します。

この知識ベースの認証(ユーザーが知っていること、パスワードなど)から、所有ベース(ユーザーが持っているもの – 安全な鍵を持つデバイス)と生体ベースまたはローカル知識ベース(生体認証によるユーザー自身、またはデバイスPINによるローカルで知っていること)の組み合わせへの根本的な移行は、リモートで使用可能な共有秘密を侵害することに依存する攻撃チェーンを根本的に断ち切ります。摩擦を加える多くのセキュリティ対策とは異なり、パスキーは複雑なパスワードを覚える必要なく、より速く、より簡単なログインを提供することでユーザーエクスペリエンスを向上させることが多く、これは採用を促進し、全体的なセキュリティ体制を強化できる二重の利点です。

Igor Gjorgjioski Testimonial

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

Corbado proved to be a trusted partner. Their hands-on, 24/7 support and on-site assistance enabled a seamless integration into VicRoads' complex systems, offering passkeys to 5 million users.

エンタープライズはCorbadoを信頼し、パスキーでユーザーを保護し、ログインをよりシームレスにしています。今すぐ無料のパスキー相談をお申し込みください。

無料相談を申し込む

6. ギャップを埋める:パスキーがPCI DSS 4.0の認証コントロールを満たす方法#

パスキーに固有の強力なセキュリティ機能は、PCI DSS 4.0で義務付けられている強化された認証コントロール、特に要件8で概説されているものと非常によく一致しています。パスキーはこれらの要件を満たすだけでなく、多くの場合、従来の方法が提供するセキュリティを上回ります。

6.1 要件8のMFAおよびフィッシング耐性基準への直接的な対応#

パスキーは、PCI DSS 4.0で定義されている多要素認証の基本原則を本質的に満たしています。

  • 多要素性: パスキー認証イベントは通常、「所有要素」(秘密鍵を含む物理デバイス、スマートフォンやハードウェアセキュリティキーなど)と、「生体要素」(デバイス上のパスキーをアンロックするために使用される指紋や顔スキャンなどの生体認証)または「知識要素」(デバイスのPINやパターン)を組み合わせます。これらの要素は独立しています。例えば、デバイスのPINが侵害されても、デバイス自体が安全であれば、暗号鍵が本質的に侵害されることはありません。
  • フィッシング耐性: 広範に議論されているように、パスキーは暗号的な性質とオリジンバインディングにより、設計上フィッシング耐性があります。秘密鍵はリライングパーティに公開されたり、ネットワーク経由で送信されたりすることはなく、パスキーは登録された正規のドメインでのみ動作します。これは、PCI DSS 4.0がフィッシング脅威の軽減を強く重視していることと直接一致します。
  • リプレイ耐性: 各パスキー認証には、サーバーからのユニークな暗号チャレンジが含まれ、それは秘密鍵によって署名されます。結果として得られる署名は、その特定のチャレンジとセッションに対してのみ有効であり、リプレイ攻撃に耐性があります。これは、MFAシステムがそのような攻撃を防ぐことを義務付けている要件8.5を満たします。

6.2 従来のパスワードベースのセキュリティを超える#

従来のパスワードと比較して、パスキーははるかに優れたセキュリティモデルを提供します。パスワードは、フィッシング、ソーシャルエンジニアリング、パスワードの再利用によるクレデンシャルスタッフィング、ブルートフォース攻撃、侵害されたデータベースからの盗難など、多数の攻撃に対して脆弱です。パスキーは、共有秘密(パスワード)を方程式から完全に取り除くことで、これらの脆弱性を排除します。認証は、簡単に盗まれたり推測されたりする可能性のある秘密ではなく、ローカルのデバイスセキュリティによって保護されている秘密鍵の所持を暗号的に証明することに依存します。

6.3 パスキーに関するPCI SSCの見解#

PCIセキュリティ基準審議会は、パスキー技術の可能性を認識しています。FIDOアライアンスとの議論を特集したPCI SSCの「Coffee with the Council」ポッドキャストからの洞察は、彼らのスタンスを明確にしています。

  • 事業体のネットワーク_内_からのカード会員データ環境(CDE)への非管理者アクセス(要件8.4.2)については、PCI SSCは、パスキーのようなフィッシング耐性認証方法が従来のMFAの_代わり_に使用できることを示しています。これは、パスキーの強さを大きく認めるものです。
  • CDEへの管理者アクセス(要件8.4.1)およびネットワークへのすべてのリモートアクセス(要件8.4.3)については、パスキー(フィッシング耐性認証として)が推奨される一方で、MFA要件を満たすためには_別の認証要素と組み合わせて使用する必要があります_。これは、より高い権限やよりリスクの高いアクセスシナリオでは追加のレイヤーが必要であるというリスクベースのアプローチを示唆しています。
  • PCI SSCは、組織がパスキーを準拠した方法で実装する方法を理解するのを助けるために、FAQなどのガイダンスを積極的に開発しており、パスキーが従来のパスワードベースの考え方からの根本的な転換を表していることを認識しています。
  • さらに、PCI DSS 4.0の文書は、FIDOベースの認証を、義務付けられてはいないものの、MFAを実装するための好ましい方法として明示的に言及しており、基準の目的との整合性を強調しています。

この立場により、組織は戦略的にパスキーを展開できます。内部でCDEにアクセスする広範な非管理者ユーザーベースに対しては、シームレスなパスキーログインがコンプライアンス要件を満たすことができます。管理者およびリモートユーザーに対しては、パスキーはMFAソリューションのための強力でフィッシング耐性のある基盤を提供します。

6.4 パスキーの種類、要素の独立性、アテステーション:要件8に対するQSAの期待に応える#

パスキーは大幅なセキュリティ向上を提供しますが、PCI DSS認定セキュリティ評価機関(QSA)は、特にCDEへの管理者アクセス(要件8.4.1)のような高リスクのアクセスシナリオにおいて、真の多要素認証の原則が満たされていることを確認するために、その実装を精査します。主な考慮事項には、パスキーの種類、認証要素の独立性、およびアテステーションの使用が含まれます。

6.4.1 同期パスキー vs. デバイス固定パスキー:#

すでに説明したように、パスキーには主に2つの形式があります。

  • 同期パスキー: これらは、Apple iCloudキーチェーンやGoogleパスワードマネージャーなどのクラウドサービスを介して、ユーザーの信頼できるデバイス間で同期されます。これらは、あるデバイスで作成されたパスキーを別のデバイスで使用できるという利便性を提供します。
  • デバイス固定パスキー: これらは、USBハードウェアセキュリティキー(例:YubiKey)や特定の電話のセキュアハードウェアなど、特定の物理的な認証器に結び付けられています。秘密鍵はこの特定のデバイスから離れません。

6.4.2 要素の独立性とQSAによる精査#

PCI DSSは、MFA要素が独立していること、つまり1つの要素の侵害が他の要素を侵害しないことを義務付けています。パスキーは通常、「所有要素」(秘密鍵を持つデバイス)と「知識/生体要素」(鍵をアンロックするためのローカルデバイスPINまたは生体認証)を組み合わせます。

同期パスキーは多くの攻撃に対して非常に安全ですが、一部のQSAは管理者アクセス(要件8.4.1)に対する「所有」要素の絶対的な独立性について疑問を呈する可能性があります。懸念されるのは、パスキーを同期するユーザーのクラウドアカウント(例:Apple ID、Googleアカウント)が侵害された場合、秘密鍵が攻撃者の制御するデバイスに複製される可能性があることです。これにより、一部の評価者は、高リスクのコンテキストにおいて、同期メカニズム自体が強力なMFAで堅牢に保護されていない場合、同期パスキーが2つの完全に独立した要素という厳格な解釈を満たしていない可能性があると見なす可能性があります。NISTのガイドラインでは、例えば、同期パスキーをAAL2準拠として認識していますが、デバイス固定パスキーは、しばしばエクスポート不可能な鍵を含むAAL3を満たすことができます。

  • WebAuthn認証器フラグの理解: WebAuthnセレモニー(パスキーの基盤)中、認証器は特定のフラグを報告します。重要な2つは次のとおりです。
    • uv=1 (User Verified): このフラグは、ユーザーがローカルで認証器に対して自身の存在を正常に検証したことを示します。通常はデバイスPINまたは生体認証を使用します。この検証は認証要素の1つとして機能します – 「知識要素」(PIN)または「生体要素」(生体認証)。
    • up=1 (User Present): このフラグは、ユーザーが存在し、セレモニー中に認証器と対話したこと(例:セキュリティキーに触れる)を確認します。ユーザープレゼンスは、ユーザーの意図を証明し、特定のリモート攻撃を防ぐために重要ですが、それ自体は通常、MFAの多要素要件を満たすための独立した別の認証要素とは見なされません。これは重要なセキュリティ機能ですが、通常は2番目の_要素_としてはカウントされません。
  • デバイス固定パスキーとハードウェアセキュリティキーの役割:
    管理者アクセス(要件8.4.1)やその他の高保証シナリオでは、ハードウェアセキュリティキーに保存されたデバイス固定パスキーが、要素の独立性についてより強力な論拠を提供します。秘密鍵はハードウェアトークンから決して離れないように設計されているため、「所有要素」はソフトウェアベースの攻撃やクラウドアカウントの侵害による複製に対してより堅牢に保護されます。これにより、これらは管理用MFAに対する厳格なQSAの期待を満たそうとする多くの組織にとって好ましい選択肢となります。

6.4.3 認証器検証のためのアテステーション#

アテステーションは、パスキー登録プロセス中に、認証器が自身に関する検証可能な情報(例:メーカー、モデル、認証ステータス、ハードウェアバックアップされているかどうか)をリライングパーティ(あなたのFIDOサーバー)に提供するWebAuthnの機能です。

  • PCI DSSにとってなぜ重要か: アテステーションは、使用されている認証器が組織のセキュリティポリシーを満たし、本当に主張どおりのものであること(例:認定されたハードウェアセキュリティキー)をQSAに証明するための重要な証拠を提供できます。これは、認証要素の強度と独立性を実証する際に特に重要になる可能性があります。
  • 推奨事項: 管理者によるCDEアクセスのような高セキュリティアクセスには、堅牢なアテステーションをサポートするハードウェアセキュリティキー上のパスキーを使用することを強くお勧めします。これにより、組織は許容される認証器の種類に関するポリシーを強制し、コンプライアンスのより強力な証拠を提供できます。

実際には、要件8.4.1の監査での摩擦を避けるため、多くの企業は、鍵の保護と潜在的なアテステーションの強力な保証を提供するハードウェアセキュリティキー上でデバイス固定パスキーを発行することを選択します。

6.5 パスキーと要件8のサブ条項のマッピング#

パスキーがどのようにギャップを埋め、要件8で詳述されているコントロールを満たすかを明確に示すために、次の表は、特定のパスキー機能と特性を関連するサブ条項にマッピングし、さまざまなシナリオへの適合性を示しています。

要件8サブ条項パスキーの機能パスキーがどのように満たすか/超えるか同期OK?デバイス固定OK?
8.2 (User ID)パスキーによる一意のUser ID各パスキーはユーザーのサービスへの登録に固有です。秘密鍵は共有されません。個人の説明責任を可能にします。
8.3.x (パスワード)パスワードの置き換えパスキーがアクセスパスのパスワードを完全に置き換える場合、パスワード固有のコントロール(長さ、複雑さ、ローテーション、履歴)はそのパスに対してN/Aとなり、それらのコントロールのコンプライアンスを簡素化します。
8.4.1 (管理者MFA)フィッシング耐性要素(デバイス+ローカル)パスキーは強力なフィッシング耐性のある1つの要素として機能します。(同期パスキーの要素の独立性についてはQSAによる精査あり)。⚠️
8.4.2 (非コンソールMFA)フィッシング耐性認証(デバイス+ローカル)フィッシング耐性認証(パスキーなど)は、このシナリオでは従来のMFAの_代わり_に使用できます。
8.4.3 (リモートMFA)フィッシング耐性要素(デバイス+ローカル)パスキーはネットワークへの強力なフィッシング耐性のある1つの要素として機能します。(同期パスキーの要素の独立性についてはQSAによる精査あり)。⚠️
8.5.1 (リプレイ耐性)ユニークなチャレンジ/レスポンス各ログインはサーバーのチャレンジに結びついたユニークな署名を生成し、傍受された認証データの再利用を防ぎます。
8.5.x (要素の独立性)明確なローカル要素(デバイス+ローカル)デバイス上の暗号鍵とローカルの生体認証/PINは独立しています。暗号操作はローカルでのユーザー検証が成功した後にのみ実行されます。(同期キーの要素の独立性は、高リスクシナリオではQSAによって疑問視される可能性があります)。⚠️
フィッシング耐性(一般)コアセキュリティ(オリジンバインディング、秘密なし、PK暗号)パスキーが正規のサイトでのみ機能し、盗まれる可能性のある秘密が送信されないことを保証することで、フィッシング攻撃に抵抗するように根本的に設計されています。

このマッピングは、パスキーが単なる理論的な適合ではなく、PCI DSS 4.0の高度な認証要求を満たすための実用的で堅牢なソリューションであることを示しています。

7. 結論:強力な認証のためのパスキーの採用#

決済セキュリティの状況は複雑で進化しています。PCI DSS 4.0はこの現実を反映しており、特に認証の領域でセキュリティコントロールの基準を引き上げています。組織がこれらの新しく、より厳格な要求を満たすために努力する中で、FIDO/WebAuthn標準に基づいて構築されたパスキーは、単なる準拠ソリューションとしてではなく、セキュアなアクセスを再定義する準備が整った変革的なテクノロジーとして浮上しています。

この分析を通じて、2つの中心的な問いが私たちの探求を導いてきました。

  1. PCI DSS 4.0が認証の基準を引き上げる中、組織はユーザーやセキュリティチームに過度な負担をかけることなく、これらの厳格な新要件をどのように効果的に満たすことができるのでしょうか? 証拠は、組織がパスキーのようなフィッシング耐性のある多要素認証(MFA)ソリューションを戦略的に採用することで、PCI DSS 4.0の認証要件を効果的に満たすことができることを強く示唆しています。これらのテクノロジーは、堅牢で暗号的に検証されたセキュリティと、大幅に改善された、しばしばより高速なユーザーエクスペリエンスを本質的に両立させます。さらに、PCI DSS 4.0が「カスタマイズされた実装」を許容することで、組織はこのような高度なソリューションを特定の環境やリスクプロファイルに合わせて調整し、画一的なアプローチを超えることができます。PCI SSC自身のガイダンスはこれをさらに促進し、大多数のユーザーに対しては合理化されたコンプライアンスを可能にし、よりリスクの高い管理者およびリモートアクセスにはより階層的なアプローチを留保します。
  2. パスキーのような新しいテクノロジーは、PCI DSS 4.0の堅牢な認証コントロールを満たすだけでなく、単なるコンプライアンスを超えた、セキュリティ強化や運用効率の向上といった具体的な利点を提供できるのでしょうか? 答えは明確な「はい」です。パスキーは、MFA、フィッシング耐性、リプレイ耐性の基準を含む、PCI DSS 4.0の要件8内のコア認証コントロールを満足させることが実証されています。しかし、その価値は単なるコンプライアンスを超えて広がります。パスキーの固有の設計—共有秘密を排除し、認証を特定のオリジンにバインドすること—は、成功するフィッシング攻撃やアカウント乗っ取りのリスクを劇的に削減し、詐欺関連の損失の具体的な削減につながります。運用面では、パスワードからの移行は、パスワード関連のヘルプデスクチケットの減少につながり、コストを節約し、ITリソースを解放します。ユーザーは、よりシンプルで、より速く、よりストレスの少ないログイン体験から恩恵を受け、これにより生産性と顧客満足度が向上する可能性があります。さらに、特定のアクセスパスでパスワードがパスキーに完全に置き換えられた場合、パスワード固有のコントロールに対する監査負担が排除され、それらの領域でのコンプライアンス活動が合理化される可能性があります。

真に安全な決済エコシステムへの道のりは継続的です。PCI DSS 4.0は新たなマイルストーンを設定し、パスキー認証はそれらに到達するための強力な手段を提供します。カード会員データを処理、保存、または送信する組織は、パスキーの採用を評価し、計画を開始することを強くお勧めします。これは、単に基準の最新版に従うことだけではありません。それは、デジタルアイデンティティの未来と一致する、より安全で、効率的で、ユーザー中心の認証アプローチを受け入れることです。パスキーを戦略的に実装することで、企業は進化する脅威に対する防御を強化し、貴重な決済データを保護し、ますますデジタル化する世界で顧客とのより大きな信頼を築くことができます。

Schedule a call to get your free enterprise passkey assessment.

Talk to a Passkey Expert

Share this article


LinkedInTwitterFacebook

Enjoyed this read?

🤝 Join our Passkeys Community

Share passkeys implementation tips and get support to free the world from passwords.

🚀 Subscribe to Substack

Get the latest news, strategies, and insights about passkeys sent straight to your inbox.

Related Articles

Table of Contents