銀行の課題が増える：PSD2は新しいデータ共有ルールを意味します

多くの皆さんは、間違いなく、PSD2（決済サービス指令の略）と呼ばれる欧州連合の欧州銀行監督局（またはEBA）指令について聞いたことがあるでしょう。 これらのガイドラインは、もともと2015年末に公開されました。2018年1月までに、すべての加盟国が規制を実施する必要がありました。

銀行業界は、非常にデジタルな未来についてまだ考えていない場合、多くの課題に直面しています。

EUのPSD2に対する強力な顧客認証を理解する

PSD2の主な目的は次のとおりです。

1. すべての主要な利害関係者の競争の場を平準化しながら、オンライン商人などのさまざまなプレーヤーに新しい市場機会を開く
2. 消費者の透明性と消費者の選択を提供する
3. オンライン決済のための新しくより堅牢なセキュリティ慣行の紹介

PSD2には一般的にいくつかのガイドラインがあります。 ただし、より優れたPSD2ガイドラインの1つは、MEF（Mobile Ecosystem Forum）からダウンロードできます。

強力な顧客認証

PSD2規制の重要な要素の1つは、強力な顧客認証（またはSCA）の概念です。 EBAは次のように述べています。「PSD2のおかげで、消費者は電子決済や取引（オンラインバンキングの使用やオンラインでの購入など）を行う際の保護が強化されます。

規制技術基準（RTS）は、強力な顧客認証（SCA）を、自分の支払いアカウントにアクセスするため、およびオンラインで支払いを行うための基礎にします。」 つまり、SCAは、少なくとも2要素認証（2FA）を要求します。

二要素認証とは、ユーザーが次の3つの要素のうちの2つの要素によって自分のIDを「証明」する必要があることを意味します。

1. 彼らが知っていること（PINコードまたはパスワード）
2. 彼らが持っているもの（モバイルデバイス、カード）
3. それらが何か（指紋、フェイススキャン：バイオメトリクスなど）

EBAは、SCAはEU全体で一般的に使用されていると述べています。 ただし、これはクレジットカード決済や銀行振込などのオンライン決済取引には必ずしも当てはまりません。 SCAは、ベルギー、オランダ、スウェーデンのEU諸国で適用されます。 ただし、他のEU諸国では、欧州委員会からの優れたプレスリリースによると、SCAは自主的にのみ適用されます。

EU加盟国は2018年1月までにPSD2を実装する予定でしたが、SCAは、RTSの発効日（今年後半になると予想されます）後のEBA規制技術基準（RTS）の18か月後に義務化されます。 。 したがって、本質的には、2019年半ばから後半に注目しています（2019年9月は、一部のドキュメントで引用されているそのような日付の1つでした）。 これにより、すべての利害関係者は、SCAおよびその他のセキュリティ要件をシステムとワークフローに組み込むのに十分な時間を確保できます。

SCAの2FA

SCAのタイムラインを考えると、2018年は、必要なセキュリティの強化に対応するために、企業が2FAソリューションの実装を開始する絶好の機会です。

国際法律事務所のテイラー・ウェッシングは、論文の中で、 PSD2に基づく強力な顧客認証について、次のように述べています。 、アクセス可能で革新的な支払い手段であるため、認証要素をさらに定義するべきではありません。」 これは、EBAが2FAの実装方法を指定していないことを意味します。 SMSやプッシュ通知などのモバイルチャネルや従来の電子メールチャネルを介したトークン配信や、TOTPソフトトークンソリューションなど、さまざまなスキームがあります。

このすべてに注意してください。他の優れた2FA実装スキームと同様に、いくつかの制限と特定の規制があり、これらを慎重に検討する必要があります。

認証コード

RTSは、認証コードの生成が次の条件を満たすことに注意しています。

1. 認証コードの開示から、知識、所持、継承に関する情報を引き出すことはできません。
2. 以前に生成された他の認証コードの知識に基づいて新しい認証コードを生成することはできません
3. 認証コードを偽造することはできません

さらに、RTSは、コードの有効期間内に5回以下の認証試行の失敗を試行する必要があり、オンラインで支払いアカウントにアクセスするために認証された後、支払人またはユーザーによるアクティビティがない最大時間は5分を超えてはならないと述べています。 。

トランザクションのダイナミックリンク

RTSは、電子リモートトランザクション（基本的にインターネット経由で行われる支払い（ラップトップやモバイルデバイスなどのデスクトップデバイス）には、「トランザクションを特定の金額および特定の受取人に動的にリンクする」要素を含める必要があることを示しています。 RTSは、これをSCAの追加形式と見なします。

このSCA要件の場合、2FAトランザクションの時点で、支払いトランザクションの金額と、受取人（またはマーチャント）をユーザーに提供する必要があります。 金額または受取人に変更があった場合は、別の認証コードを生成する必要があります（たとえば、そのコードを新しい受取人および/または支払い金額に「動的にリンク」する）。 必要なすべての情報を含むSMSメッセージは、右の画像のようになります。10分間のセキュリティコード、販売者（または受取人）の名前、および取引金額。

興味深いことに、Google AuthenticatorなどのサードパーティのTOTP準拠アプリによって生成された認証コードは、支払い/販売者情報とは完全に別個に生成されるため、動的にリンクすることはできません。

チャネルの独立性

この要件は少し注意が必要です。 RTSは、「決済サービスプロバイダーは、強力な顧客認証の要素または認証コード自体が多目的デバイスを介して使用されるセキュリティ対策を採用して、その多目的デバイスから生じるリスクを軽減する必要がある」と述べています。危険にさらされています。」 多目的デバイスは、モバイルデバイスやタブレット、さらにはラップトップでもかまいません。

ユーザーがラップトップを使用していて支払いを要求された場合、そのマーチャントは、認証とともに、受取人（マーチャントなど）と支払う金額をユーザーのモバイルデバイスにSMSで送信できます。 SMSの本文のコード。

別の例では、ユーザーがモバイルデバイスを使用してマーチャントと対話し、支払いを開始する場合、このチャネルの独立性は、SMSまたはモバイル固有の配信チャネルを明確に禁止しません。 ここでは、細い線です。 多くの場合、ユーザーが持っているデバイスは、携帯電話などの多目的デバイスだけです。 ただし、チャネルの独立性とは、同じデバイス上の独立したチャネルであり、認証コードを含むSMSは、モバイルとは異なるチャネルです（実際には、携帯電話番号を介して到達する帯域外チャネルです）。ユーザーが販売者と関わっているアプリまたはウェブブラウザ。 同じチャネルの独立性は、モバイルアプリを使用してTOTP準拠のコード（Google認証システムなど）を生成する場合にも適用されますが、前述のように、TOTP準拠のコードはトランザクションの動的リンクに失敗します。

逆に、ユーザーがモバイルアプリを使用して販売者にアクセスしている場合、同じチャネルであるため、同じアプリへのプッシュ通知（認証コードを使用）はできません。

SMSを介した2FAは非常に安全ではなく、場合によってはそれが真実である可能性があると言う人もいます。 はい、攻撃者が1人のオペレーターでSS7を介して2FASMSメッセージにアクセスすることに成功したいくつかの孤立したインスタンスがありました。 ただし、これらの脆弱性の多くはクローズされています。 さらに、認証コードがどのように生成されてユーザーに提供されるか、およびメッセージングサービスプロバイダーがそのようなコードをどのように配信するかは非常に重要です。

多目的デバイスが普及している状況では（そして今日、これらは最も普及しているデバイスであり、今後も続くでしょう）、携帯電話事業者が提供するメッセージングチャネルは、2FAトークンの実行可能な帯域外チャネルであり続ける必要があります。

より詳細な分析については、Frederik Mennesによる有益なブログ投稿を見つけました。これは、どのタイプのシナリオ（特に多目的デバイスの場合）がPSD2SCAに準拠する必要があるかについての詳細を提供します。

PSD2 SCAは軽視すべきではありませんが、すでに実装されている2FAソリューションの多くは機能するはずです。 ただし、多くのオンラインマーチャントは、PSD2SCAに準拠したソリューションをまだ提供していないこともわかっています。 この記事の執筆時点では、SCAを支払いワークフローに組み込むための十分な時間がまだあります。

SAP Authentication 365は、企業がPSD2準拠のSCAを実装できるようにするAPIベースのクラウドソリューションを提供するソリューションです。 SAP Authentication 365モバイルサービスは、デジタルビジネスに合わせた認証を使用して、マルチチャネル2要素認証（2FA）サービスを迅速かつ安全に実装できるようにするエンドツーエンドのサービスです。

SMS、電子メール、プッシュ通知、またはTOTPソフトトークンによる認証を有効にすることで、企業顧客のIDとデータを保護するのに役立ちます。 SAPのRESTAPIは、検証コードまたは認証コードの生成と認証を簡素化し、PSD2準拠のSCA戦略の実装を可能にする柔軟性と機能を提供します。