+86-755-89202795

网络安全认证测试cybersecurity certification

网络安全认证测试(Cybersecurity Certification Testing)是对信息系统、网络、应用程序和设备进行评估和验证,以确保其符合特定的安全标准和法规要求的过程。目的是确认系统具备足够的安全性,能够抵御潜在的网络威胁和攻击,从而保护数据的机密性、完整性和可用性。

测试服务

欧盟PSD2合规方案和强客户认证(SCA)



⼀、法规框架与适⽤范围总览

为构建更安全、开放和统⼀的欧洲⽀付市场,欧盟已建⽴了⼀套完整的⽀付服务监管体系。本章旨在对当前有效的核⼼法规框架及其适⽤范围进⾏总览,为理解后续章节的具体技术要求与合规路径奠定基础。
核⼼法规框架:以PSD2为主体。
欧盟当前的⽀付服务法规核⼼是《第⼆⽀付服务指令》(PSD2),即Directive (EU) 2015/2366。

该指令于2015年通过,并于2018年1⽉⽣效,旨在修订和取代其前⾝PSD1 (Directive 
2007/64/EC),其核⼼⽴法⽬标在于:
1.提升⽀付交易的安全性,特别是通过引⼊强制性的强客⼾认证(SCA)。
2.促进竞争与创新,强制银⾏在客⼾同意下向获得授权的第三⽅提供商开放账⼾访问接⼝
(即“开放银⾏”)。
3.增强消费者保护,并扩展规则适⽤范围,为所有⽀付服务提供商创造⼀个更公平的竞争环境。

PSD2是⼀部框架性指令,其原则性规定由欧盟委员会通过的系列技术性实施条例进⾏细化与补充。

⼆、强客⼾认证(SCA)技术要求与测试标准

承接PSD2确⽴的强制性安全框架,监管技术标准《委托条例 (EU) 2018/389》构成了产品设计与验证必须遵循的“技术法典”。

SCA的基本认证模型与技术要求

SCA的本质是建⽴⼀个基于多重独⽴证据的⾝份验证堡垒。根据SCA-RTS规定,⽀付服务提供商实施SCA时必须严格遵守以下技术要求:
核⼼原则:多要素独⽴认证认证过程必须整合⾄少两个独⽴的认证要素,这些要素必须来⾃以下三类中的不同类别:
1.知识(Knowledge):仅⽤⼾知晓的信息,如密码、PIN码。
2.占有(Possession):仅⽤⼾持有的物品,如智能⼿机、硬件令牌、银⾏卡。
3.固有特征(Inherence):⽤⼾⾃⾝的⽣物特征,如指纹、⾯部识别、声纹。

认证码(Authentication Code)的安全属性认证过程⽣成的“认证码”是交易授权的核⼼,必须满⾜⼀系列密码学安全要求:
  • ⼀次性使⽤:认证码只能被⽀付服务提供商接受⼀次。
  • 防逆向推导:即使认证码泄露,也⽆法从中推导出任何认证要素(如密码、密钥)的信息。
  • 防序列预测:⽆法根据已知的历史认证码⽣成新的有效认证码。
  • 防伪造:认证码本⾝必须具备不可伪造的特性。
认证尝试与静默超时控制

  • 失败认证限制:连续失败的认证尝试次数不得超过5次。超过此阈值后,相关操作应被暂时或永久性阻⽌。
  • 会话超时:⽤⼾通过SCA成功登录在线⽀付账⼾后,若⽆任何操作,会话将在最⻓5分钟后⾃动失效,要求重新认证。
多功能设备上的特别安全考量当使⽤智能⼿机、平板电脑等多功能设备来实现“占有”(如认证APP)或“固有特征”(如指纹识别)要素时,⾯临设备本⾝被恶意软件侵⼊的⻛险。为此,条例要求必须采取额外的技术隔离措施来降低此类⻛险。⼀个典型且关键的实现⽅式是**使⽤独⽴的安全执⾏环境(如Secure Enclave、TrustZone)**来处理敏感的认证数据和密钥运算,使其与设备的主操作系统及应⽤环境隔离。

动态关联(Dynamic Linking):防篡改的核⼼纽带

动态关联是针对远程电⼦⽀付交易的最⾼级别安全要求,旨在从根本上防⽌交易⾦额或收款⼈被中途篡改的“中间⼈攻击”。

四项强制性要求根据SCA-RTS第5条,⽀付服务提供商必须确保:

1.知情确认:在认证过程中,付款⼈必须被清晰告知具体的交易⾦额与收款⼈信息。
2.唯⼀绑定⽣成:⽣成的认证码必须是针对该笔交易中付款⼈同意的特定⾦额和特定收款⼈⽽定制的。
3.⼀致性验证:⽀付服务提供商在验证时,必须确保接收到的认证码与原始的⾦额、收款⼈信息完全匹配。
4.篡改即失效:任何对交易⾦额或收款⼈信息的修改,都将导致先前⽣成的认证码⽴即失效,交易⽆法完成。技术中⽴的实现⽅式条例采取技术中⽴原则,不强制规定具体技术路径。只要满⾜上述安全要求,认证码可以通过多种密码学⽅案实现,包括但不限于:
  • ⽣成和验证⼀次性密码。
  • 使⽤数字签名技术。
  • 利⽤存储在安全元件中的密钥,⽣成基于密码学的有效性声明。
接⼝如何⽀撑强客⼾认证(SCA)

开放接⼝不仅是数据通道,更是SCA安全流程的关键执⾏载体。接⼝设计必须内置⽀持以下SCA相关功能:
  • 动态链接的实现:接⼝必须⽀持将交易⾦额、收款⼈信息与⽣成的认证码进⾏唯⼀、防篡改的绑定。任何通过接⼝发起的⽀付交易,其认证流程都应符合动态链接的四项技术要求。
  • 安全元素隔离:当通过多功能设备(如智能⼿机上的银⾏APP与第三⽅APP交互)完成SCA 时,接⼝通信与认证处理应能利⽤或调⽤设备的安全执⾏环境,以降低设备被⼊侵的⻛险。
  • 凭证安全传输:确保⽤⼾在第三⽅界⾯输⼊的个性化安全凭证,能通过安全通道加密传输⾄ASPSP进⾏验证,且不被第三⽅留存。
测试环境与互操作性测试要求

为确保第三⽅提供商能够在接⼝正式上线前完成集成,PSD2 RTS规定了明确的测试义务。请注意,提供的资料中未包含互操作性测试的具体⽤例或认证标准,但明确了测试的法律基础和核⼼框架要求。

1.测试环境的法律强制要求

  • 提供义务:ASPSP必须提供⼀个功能完整的测试环境。
  • 提供对象:向所有已获得授权或已提交授权申请的PISP、AISP等TPP开放。
  • 时间要求:测试环境必须在相关SCA与CSC标准正式适⽤⽇之前⾄少6个⽉提供。若接⼝在标准⽣效后才推出,则须在接⼝市场发布⽇期前提供。这为TPP提供了法定的、充⾜的开发与集成测试窗⼝期。


2.测试环境的核⼼原则

  • 数据安全:明确禁⽌通过测试设施共享任何真实的敏感⽀付数据或个⼈⾝份信息,必须使⽤模拟数据。
  • 环境真实性:测试环境应尽可能模拟⽣产环境的技术栈与⾏为,以确保测试的有效性。


3.互操作性测试的核⼼⽬标虽然⽆具体测试清单,但根据法规精神,互操作性测试应⾄少验证以下维度的合规性与稳定性:

  • 功能正确性:⽀付发起、账⼾信息查询、资⾦确认等核⼼API调⽤是否按规范响应。
  • SCA流程集成:TPP应⽤是否能正确引导⽤⼾完成符合PSD2要求的强客⼾认证流程。
  • 通信标准符合性:API请求与响应是否严格遵循公开的技术规范与通信标准。
  • 安全性与稳定性:接⼝在⾼并发、异常输⼊、错误处理等⽅⾯的表现是否健壮。
  • 数据完整性:传输的数据是否准确、完整,且未被篡改。

接⼝变更管理与过渡安排

考虑到技术的演进,法规对接⼝变更设置了明确的透明度要求,以保障⽣态系统的稳定。
  • 常规变更通知:除紧急情况外,ASPSP对其接⼝技术规范的任何修改,必须提前通知相关TPP。通知期应尽可能⻓,且不得短于变更实施前3个⽉。
  • 特定豁免相关变更:为遵守《授权条例 (EU) 2022/2360》中关于“90天账⼾访问豁免”等特定条款⽽进⾏的接⼝修改,通知期不得短于2个⽉。
  • 紧急变更:在紧急情况下可⽴即实施变更,但必须详细记录紧急原因,并应主管当局要求提供该记录。
  • 过渡期参考:在PSD2的SCA与CSC要求全⾯强制执⾏前的过渡期,欧洲银⾏管理局发布的


《2014年互联⽹⽀付安全指南》被作为重要的临时参考基准,要求市场实践尽可能与PSD2的最终⽬标保持⼀致。
本路线图勾勒了在PSD2及RTS法律框架下,⼀个⽀付服务产品所必须经历的关键合规“⾥程碑”与控制点。

制造商的PSD2合规是⼀项融合了技术刚性要求与流程柔性管理的系统⼯程。成功的关键在于将法规条款内化为企业制度,将安全设计植⼊产品基因,并通过前置、开放、持续的测试验证与透明的⽣态协作,最终在提升⽀付安全与信⼼的同时,驾驭开放银⾏带来的市场机遇。

欢迎和深光沟通和咨询欧盟PSD2合规事情和强客⼾认证SCA,深光可以协助安卓设备客户同步完成谷歌GMS要求,对欧盟PSD2合规可以给予设备正版认证。


推荐项目