第三方支付机构对外部用户提供的终端形式，主要有自家的移动钱包应用和外部应用接入的支付SDK。
（1）移动钱包应用是一款基于手机的应用，常见的GoogleWallet（谷歌钱包）、支付宝钱包、华为钱包的主要功能是让移动设备（手机、平板电脑等）变成移动钱包，将之前现金钱包、硬币、银行卡存储为手机或云端上的资金数据。该移动钱包应用不仅包含数字货币，还变身为卡券中心和私人小助手，例如各种优惠打折券、购物卡和礼品卡，以及电子驾照、社会保险卡、医疗保险卡、身份证等个人证件类的电子助手。
（2）支付SDK主要是把第三方支付机构的支付功能、产品和能力打包成SDK形式提供给其他应用和商业产品接入。
处于交易终端的移动钱包应用和支付SDK是用户使用支付系统交易的过程中的第一道关卡，也是最为重要和复杂的一道关卡，安全性至关重要。
终端在交易过程中涉汲支付系统的数据有用户的个人信息数据、账户数据、订单数据、系统配置数据、日志数据、交易记录数据等，其中涉及个人隐私、商户利益及商业机密，如果无法安全地保存和传输好这些数据，则会涉及户的资金安全和个人隐私泄露问题，这样一来，第三方支付机构的企业信誉也无法得到有效保证，随时可能将企业陷入信任危机中。
对于从事支付行业的第三仿支付机构来说，终端数据的安全防护无疑是支付业务发展的重要保证之一，是安全防护长城的第一关。支付系统一般会采用以下方法来保障终端数据的安全。
1、安全加密
在存储、使用数据的过程中一般要对数据进行安全加密，该过程可分为加密（见图1）和解密（见图2）。
图1
图2
在图2中，加密和解密都使用了同一把密钥，这种加密方法叫作对称加密（也叫作单密钥加解密）。同时，可以采用非对称加解密，例如：使用RSA算法来加解密时，一般都需要先产性公钥和私钥，可以使用OpenSSL工具进行公私钥生成，也可以使用代码生成。当明文数据采用公钥加密时，需要使用私钥对密文进行解密；当明文数据使用私钥加密时，需要 使用公钥对密文进行解密。
采用安全加密方式和算法时一般依据自身数据的安全要求级别进行界定，比如：在使用场景中是否需要高安全级别、非常快的加解密速度和进行高性能处理。
（1）个人信息数据。安全级别较高，属于用户的个人隐私数据。随着互联网的高速发展，我们已经进入全新的数据化时期，随着几次个人隐私泄露安全大事件的爆发（例如国外某大型社交网站上的联系人数据泄露事件、某大型技术论坛的明文密码泄露事件等），用户对个人信息数据的安全意识也开始觉醒，对个人隐私数据的保护需求也越来越强，毕竟，每个人都有自己的隐私权，都不愿意自己的身份信息和联系数据被泄露。
这种个人信息数据支付系统一般由机构自己研发加解密引擎来支持并且采用云端存储方案，其他不具备加解密引擎研发能力的机构通常也会使用国际流行的高强度加密算法（例如AES加解密算法），或者对存储数据文件进行驱动层级别的加解密操作。
（2）账户数据。安全级别较高，属于第三方支付机构或商户的商业机密数据。这部分数据一般不被存储在终端或客户端，在客户端一般仅存储账户的唯一标识、账号编码或其他信息，在需要时再从账户服务端将数据安全传输到本地进行展示。对于用户输入的登录账户信息，则在本地将其处理成对应的验签数据，再通过安全传输通道（TLS或SSL）上传到服务端，然后对原来在数据库里面预设的账户信息进行比对，如果数据相等，则表示账号登录成功，否则业务系统将提示账号登录失败。
（3）订单数据。安全级别较高，属于商户的商业机密数据和用户交易数据。这部分数据由客户端生成并传递给商户服务端，再传递给第三方支付机构的支付服务器，如果在该过程中被窥探、泄露或篡改，则将对商户产生影响，严重时会造成商户资产的流失。
之前有一起安全事件，某企业的电子商务应用出现了一个实际价值为999元的商品，被攻击者伪装的用户以0.1元买走。经技术分析，其原因是架构师和工程师在设计之初出于对网络整体性能的考虑，支付链路采用了HTTP，而攻击者探测、劫持、篡改了订单数据的支付金额数据包，在付款时也没有验证订单字段的环节，所以导致了以上安全事件的发生。应对方法是让商户对原订单进行RSA数据签名，支付系统对商户传入的订单数据进行验签，保证数据在传输过程中不被篡改，同时对全站启用HTTPS访问。
（4）系统配置文件。安全级别低，属于支付系统正常运行的配置参数数据，被定义为系统加载所需环境的设置和文件的集合，如果对其进行修改，则会造成支付业务运行不正常。例如：在现有大部分软件中配置文件的参数大多可以被随意修改，但支付软件会较其他软件级别高，所以对配置文件的参数进行修改时，会造成软件不能正常运行，不能正常付款。在对配置文件进行安全改造时通常会采用安全性较高、性能较好、速度较快的对称加密算法来加密，例如AES算法，防止配置文件被窥探和篡改。
（5）日志数据。安全级别中等，属于支付系统运行过程中的日志数据，这部分数据对于第三方支付机构的技术人员分析和定位支付业务中的问题至关重要。并且，不同于其他普通软件系统，支付系统是安全性要求较高的系统。例如：黑客可以通过分析支付系统的日志数据来掌握支付业务流程和关键数据，通过这些信息可以确定发起攻击的位置，所以日志数据或文件的安全性也是重中之重。日志数据还有一个特点：数据量较交易数据量多，通常是交易数据量的数十倍。
所以针对日志数据，我们首先要对数据中的敏感字段与关键信息做清洗、脱敏和加密处理，期加密算法可以采用AES算法或Log4J日志组件自带的SM4算法。
（6）交易记录数据。安全级别较高，属于商户的商业机密数据、交易记录和用户交易数据，通常被存储在本地数据库中用于用户查看自己的支付交易记录。一般会采用本地数据库自带的加密算法来加密，例如：Android系统里面sQLite数据库自带的加密算法SQLCipher。同时可以针对数据库中的数据进行加密，或者针对终端的本地数据库文件进行次整体文件加密。
2、访问授权
支付系统中的各个子系统都有不同等级的数据安全级别的访问控制，如果没有合法的子系统使用身份、网络、本地访问授权及正确的安全访问通道，则所有数据都将以密文状态保存、传输，通过其他非法手段无法访问、窃取或篡改。
访问授权其实就是一个获得授权、申请访问（操作）资源、审查授权、授权及备案的过程，如图3所示。
图3
访问授权可以分为以下几个级别。
（1）操作系统级别。访问授权粒度较粗，操作系统级别的访问授权主要基于操作系统的用户角色和账号来划分，主要限制访问驱动器、文件系统、硬件资源等。例如：文件访问限制的开放可能会导致数据和系统文件被破坏或未经核准的用户修改文件，操作系统必须控制用户对文件的存储、读取等权限，即对目标文件的读、写、执行的许可问题。客通常会通过操作系统的漏洞获取操作系统的最高权限（例如Windows 0 day漏洞），然后对目标计算机上的任意文件进行访问和篡改。该级别的防护主要关注漏洞发布网站，例如乌云、FreeBuf及操作系统官方网站，通过打补J来及时升级和修复操作系统漏洞。
（2）网络访问级别。访问授权粒度较粗，可以在计算机之间构建基于信任关系的网络访问域，域外计算机不能访问域内机器。这种域内访问控制方案最早来自Windows NT，网络域可以采用软件级隔离和物理级隔离。其中，央行的某些处理机密信息的终端规定采用物理级隔离，除电线外不能接入任何电缆或互联网络。这里讨论的主要是软件级别的隔离和访问控制，物理级别隔离主 要体现在硬件终端和网络通信设备上面，例如：从加固网络节点控制器（也叫域控制器）的角度出发，形成一个内部网络，提供独立于应用和用户的安全解决方案，构造安全可控的网络环境。最成熟的方案就是Windows的域控制器解决方案。
（3）文件系统访问级别。访问授权粒度较细，在互联网时期所有数据都被存储在分布式文件系统中，最为经典的是Hadoop的分布式文件系统（HDFS）或者亚马逊AWS的S3对象存储系统。基于这些分布式文件系统，就可以在这个文件访问层面进行权限的相关控制，例如使用HDFS的文件、目录权限控制模型。如果是AWS系统，则可以使用IAM实体（用户、操作组、角色）的权限粒度进行控制，这是一种粒度更小、更灵活的权限控制方案。每一个AWS服务的操作都可以分成4个访问级别：列表、读取、写入和权限管理，AWS的操作便利性在于提取预设置的权限方案和自定义的权限方案。
（4）数据库级别。访问授权粒度较细，支付系统的子系统数据一般被存储在数据库中，几乎市面上的所有关系或非关系数据库都有自己的访问授权和权限控制功能，例如： MySQL、MongoDB、Oracle，其权限控制方案（授权）也有很多，基本是可以控制列表（字段级别）级别的权限，通过数据库的自身权限可以细分到对某个表、某个字段是否有CRUD权限。
（5）应用级别。访问授权粒度细，在支付系统中有很多应用级别的访问授权和权限控制。这里的应用级别指在数据库层面之上构建的软件应用系统，例如支付系统的经营分析子系统中的分析报表模块，我们在应用级别可以通过技术研发来控制数据访问，更精细化地进行权限控制，例如：对不同的角色加工和显示不同的数据内容，这其中从字段的源数据到显示数据已经有非常大的变化了。还有对数据查询范围字段的控制，一般都可以采用基于角色的访问控制模型（RBAC模型）来完成应用级别细粒度的权限控制和访问授权控制，如图4所示。
图4
3、传输安全
数据在支付系统中并不是孤岛，要在一定范围内的计算机节点之间进行传输和使用，在传输过程中就会涉及信息是否被劫持、篡改及伪造等风险。同样，依据不同的信息安全保护级别，传输安全可以分成以下几个层次。
（1）专用网络。这种网络与Internet互联网、办公网等是互相隔离的，通常基于专用的传输协议和网络通信交换机设备，为各个金融机构提供数据报文制定、数据传输、交换等基础功能，在此基础之上还可以运作相关的金融信息服务和增值服务。在我国，中国国家金融数据通信网（CNFN）就是这么一个专用网络，由中国人民银行负责建设，网络层则基于X.25分组交换技术及帧中继技术。
与传统的计算机网络不一样，在该网络的基础之上中国人民银行建设了小额支付系统（BEPS）、大额支付系统（HVPS）、清算账户处理系统（SAPS）、银行卡电子授权系统、银行卡授权系统及通用信息服务系统等，为全国各商业银行和第三方支付机构提供跨行支付的清算和结算服务。
目前CNFN网络节点设立在全国各地400个城市的中国人民银行分行处理中心（CCPC）内部，每个CCPC不仅为本区域各商业银行分行的处理中心，还提供跨行、跨区域支付的交易处理业务。
SWIFT（全球同业金融通信系统）则提供全双工专用的国际化金融通信服务，负责制定通信节点之间电文格式的标准化、传输的安全性，同时在全球范围内提供三个中心操作节点（美国、比利时、荷兰）及每个国家的区域处理中心，在该网络之上运行着纽约清算所银行同业支付系统（CHIPS）、联邦储备通信系统（Fedwire系统）、伦敦自动清算支付系统（CHAPS）等。
如图5所示是一个SWIFT网络汇款电文的传输流程示意图。
图5
（2）安全协议。在一个开放的网络访问环境中（例如互联网、办公网或城域网），拥有安全协议是传输安全至关重要的一个节点，这些协议涉及HTTPS（超文本安全传输协议）、SSLTLS（安全套接层协议）、3-DSecure和安全电子邮件（PEM、S/MIME协议）等协议。
在互联网中，支付系统（例如移动收银台、支付网关等）传输数据的常见做法是采用HTTPS。HTTPS 是一种以安全为目标的HTTP通道，基于HTTP进行身份认证和传输加密保证了传输过程中的安全性。
如图6所示，最里层为TCP（同样都基于IP协议）。TCP通过三次握手建立了客户端和服务器之间的连接，HTTPS除了实现了基于TCP的HTTP（超文本传输协议），还需要加上安全传输和加密的SSL或TLS协议。
图6
HTTPS较HTTP“重”，具体表现在服务端与客户端之间通信次数较多： HTTPS不仅包括TCP的3次握手，还包括SSL的4次握手。
HTTP和HTTPS，在具体业务中选择其中哪种协议通信呢?可以参考如图7所示的流程进行选型。
图7
当接收和发送的数据为敏感数据时，我们需要采用HTTPS通信，因为通道中的数据采用了SSLTLS进行加密传输。对于数据不敏感并且性能要求较高的数据，则可以采用HTTP进行传输，例如：用户的登录信息、会话数据等都采用了HTTPS，而官方网站的信息数据和公共下载文件可以采用HTTP进行传输。
（3）专用协议。部分支付系统采用专用的电子支付协议来保障数据的安全，这种协议是一种专门针对支付业务定制的协议。
SET（Secure Electronic Transaction，安全电子交易）就是这么一种专用的支持即时电子支付的安全协议，是由Master card、Visa、Microsoft Netscape 等公司共同设计并在1997年推出的。
SET协议的核心技术有公开密钥加密、数据签名及验证、数据信封及电子安全证书等，早期是基于信用卡的支付模式而设计的，保证了开放网络上交易的安全性。SET主要是为了支持用户、商家、银行之间通过信用卡交易而设计的，具有保证交易过程和数据的完整性、一致性和安全性、商户及持卡人的合法身份验证，以及交易的不可抵赖性等优点，因此成为目前公认的网上交易的国际标准的信用卡协议。
SET采用以下方案来保证安全性。
（1）SET协议采用了先进的密码系统及数字签名、数字证书等技术。
（2）持卡人能够确认收款商家是否有权采用SET协议的安全方式接收信用卡。
（3）采用SET协议的商家能够确认交易中正在使用的信用卡。
（4）SET协议保证支付信息只能被指定的接收方获取和读取，只能被采用SET协议的商家与金融机构破译，同时，商家只能看到订单数据信息而看不到持卡人账号。
根据SET协议设计的网上安全支付应用软件，必须经过SET协议和机构验证才能被批准使用，SET协议利用发放给用户、商户、商业银行及信用卡公司的数字证书进行系列的认证与安全性检验，提高了数据在交易过程中的防伪性与安全性。
基于SET协议的支付系统一般由移动（电子）钱包应用、商户商业产品服务端、支付网关及认证机构软件等组成。
