网络支付系统安全要求.docx

网络支付系统安全要求.docx

《网络支付系统安全要求.docx》由会员分享，可在线阅读，更多相关《网络支付系统安全要求.docx（13页珍藏版）》请在冰点文库上搜索。

网络支付系统安全要求

第1章安全性需求

第2章

2.1说明

2.2

本需求主要根据中国人民银行《非金融机构支付服务业务系统检测规范》的安全性检测编制，内容包括卡系统和网络支付要求的安全性规范。

本需求只针对应用程序的开发和操作部署，不含网络和运维安全需求，同时参考各银行的网银、支付宝等支付系统的成功经验作为补充制定此文档。

应用安全

2.3

身份鉴别

2.3.1

密码管理

2.3.1.1

1.密码强度：

系统默认生成密码后，客户修改密码应具有一定的复杂度检查，如长度不少于8位，必须字母数字结合，开始3个字符不能完全一致。

系统默认生成的密码也许满足要求

2.登录密码有效期：

密码必须有一定的有效期,可设置，一般为半年，过期登录后必须修改密码

3.支付密码：

为客户设置独立的支付密码

登录处理

2.3.1.2

1.黑名单：

对非法来源的ip、用户id等登录实行黑名单管理，加入黑名单的客户拒绝登录和交易，统计出黑名单后可直接在防火墙处理

2.失败次数处理：

登录失败超过指定次数（3次），冻结此账户1天，并记录失败日志，供统计分析

3.单点登录：

每个账号同时只能在一个地方登录，系统中同时只能有一个session

多种认证方式

2.3.1.3

除密码外，为增加安全性，在关键业务（支付或重要信息修改）或登录时采用多重认证方式，以完善整个安全体系。

1.动态口令卡：

生成二位矩阵的数字电子卡片，每次使用一组密码，客户下载口令卡到电脑或手机，使用时随机输入提示的一组密码与服务器认证，口令卡有一定的使用次数限制

2.随机码短信确认：

由服务器发送一个随机验证码的短信到客户手机，客户在网页输入此验证码和服务器确认，保证此业务为客户本人提交的

3.数字证书签名：

发送关键业务都必须签名后发送服务器，防止传输过程中的篡改，以及检查发送方不可抵赖

4.u-key：

同数字证书签名，并更安全，由于发放不方便，可受理用户范围有限

客户连接管理

2.3.1.4

1.最大连接数：

为防止服务器负载过大实行最大连接数管理，可配置客户连接数

2.连接有效时间：

根据设置的客户会话有效时间，对超过有效时间的客户自动退出，并清理相关连接资源

说明

2.3.1.5

1.为保证登录安全性，最好使用密码+多种认证方式中的至少一种，即双重认证。

2.支付业务必须执行数字签名

程序安全保护

2.3.2

Web页面

2.3.2.1

1.图片验证码：

登录和支付等关键业务使用图片验证码，以防止被程序重复攻击，图片生成的随机验证码必须有高强度的干扰，以防ocr识别

2.正确网页域名提示：

topframe中显示本网站正确的域名，以及工商局ICP备案标示，加大宣传力度，减少客户被钓鱼网站干扰

3.密码安全控件：

开发密码安全控件，防止在输入账号和密码时使用默认的表单控件时被记录键盘事件以及通过消息机制获取密码。

除能通过ocx安装包自动安装外，还需要提供直接exe的下载安装包

4.数字签名控件：

执行数字签名的ocx，也需提供下载安装包

密码保护

2.3.2.2

1.密码问题保护：

注册时输入三个问题以及答案，修改时必须正确回答此三个随机书序的问题

2.短信确认：

发送验证码短信，手工录入到网页

3.密码重置：

业务人员在收到客户申请并获得授权后重置密码，并通知客户新密码并登录修改

4.加密保存：

所有密码不能明文保存

私钥证书保护

2.3.2.3

不同用途的服务器私钥证书加密保护，防止被盗后非法使用。

交易时验证对方证书的有效性，包括有效期、挂失列表等。

安全软件

2.3.2.4

防钓鱼防欺诈：

类似网盾之类的独立安装软件运行于客户电脑中，监控并阻止客户被登录钓鱼网站

安全检测

2.3.2.5

对系统程序进行各种安全性技术检测，主要为以下方面：

1.网站页面SQL注入防范

2.网站页面跨站脚本攻击（xss）

3.网站页面是否存在源代码暴露

4.网站页面是否存在黑客挂马

5.网站页面是否采用防篡改措施

6.网站页面是否提供防钓鱼网站的防伪信息验证

数据加密

2.3.3

应用部署

2.3.3.1

程序根据安全性要求分为3个区域部署：

如下图：

Internet

防火墙

DMZ

防火墙

应用区

防火墙

核心区

DMZ：

部署web程序，只提供internet接入，不提供到数据库的连接，与应用通过网络tcp/ip连接

应用区：

部署电子支付平台的业务应用系统和DB

核心区：

部署电子支付平台的支付业务系统和DB

网页连接

2.3.3.2

配置web服务器ssl，客户登录强制使用https登录

加解密和签名

2.3.3.3

1.平台内各应用节点间传输数据和报文必须加密，节点包括客户端、web服务器、业务平台、支付平台等

2.与外部系统连接，报文必须加密并数字签名，以防抵赖和篡改

3.对关键数据的加解密只是使用端到端加密，如交易密码只能在客户输入点加密和在认证服务器能验证，中间传输节点都是密文传输不能解密和查看。

配置数据

2.3.3.4

各应用服务器上部署的程序，应对如数据库密码、ftp密码等关键数据，在配置文件或数据库表中加密保存

密钥强度

2.3.3.5

对称加密使用128位以上长度密钥

非对称加密1024位以上长度密钥

认可的算法

2.3.3.6

分为对称加密算法、非对称加密算法、哈希算法三类，请参考PBOC2.0标准中对此三类算法的要求

访问控制

2.3.4

参照人行支付系统检测标准

访问权限设置

2.3.4.1

应提供访问控制功能，依据安全策略控制用户对文件、数据库表等客体的访问。

应由授权主体配置访问控制策略，并严格限制默认帐户的访问权限。

应授予不同帐户为完成各自承担任务所需的最小权限，并在它们之间形成互相制约的关系。

自主访问控制范围

2.3.4.2

访问控制的覆盖范围应包括与资源访问相关的主体、客体及它们之间的操作。

业务操作日志

2.3.4.3

应具有所有业务操作日志。

关键数据存放

2.3.4.4

应具有对重要信息资源设置敏感标记的功能。

应依据安全策略严格控制用户对有敏感标记重要信息资源的操作。

异常中断防护

2.3.4.5

用户访问异常中断后，应具有防护手段，保证数据不丢失。

数据库安全配置

2.3.4.6

应具有数据库安全配置手册，并对数据库进行安全配置

应用容错

2.3.5

参照人行支付系统检测标准

数据有效性校验

2.3.5.1

应提供数据有效性检验功能，保证通过人机接口输入或通过通信接口输入的数据格式或长度符合系统设定要求。

边界容错

2.3.5.2

提供可靠的边界检查控制，保证不存在超过边界限制的逻辑数据在交易中出现，并对重要的边界检查失败交易写入日志系统，提供告警信息，便于监控人员分析是否是恶意攻击等

容错机制

2.3.5.3

应提供自动保护功能，当故障发生时自动保护当前所有状态，保证系统能够进行恢复。

故障机制

2.3.5.4

发生故障后，系统应能够及时恢复。

回退机制

2.3.5.5

应提供回退功能，当故障发生后，能够及时回退到故障发生前的状态。

代码安全

2.3.6

源代码审查

2.3.6.1

应对源代码进行安全性审查

插件安全性审查

2.3.6.2

应对插件进行安全性审查

编码规范约束

2.3.6.3

应按照编码规范进行编码，具有编码规范约束制度。

版本管理

2.3.6.4

代码版本管理工具，配置不同文档和代码操作权限

建议

2.3.6.5

部署程序加密

第三方认证

2.3.7

为了使客户对使用的网站信任，需要网站的服务器根证书必须经过权威的第三方认证，才能获得客户信任。

认证机构

2.3.7.1

1.CFCA：

较便宜，几百元一年，但是浏览器没有默认安装，缺少知名度

2.VeriSign：

贵，几千元一年，最权威的认证机构，客户体验好

3.签发主题：

本网站的域名

使用模块

2.3.7.2

1.网站ssl配置：

IE7以后的浏览器如果服务器的ssl证书没有经过权威认证，默认会被拦截，因此ssl配置需要认证过的根证书

2.签名/密码控件：

浏览器默认安装ocx时，签名未认证的控件不能安装，需要用第三方认证过的可信根证书签名发布的所有ocx控件

3.发布的客户证书：

本网站发布的客户和商户证书，需要用第三方认证过可信根证书签发所属客户和商户的所有证书

安全审计

2.3.8

资源报告分析

2.3.8.1

1.统计分析每日、各时间段内，一定客户连接数对应的各种资源的利用率（cpu、内存、网络带宽等），根据报告决定是否需要增加更多机器或带宽

2.根据区域和运营商分析接入客户的分布情况，提供增加对应资源的依据

失败登录分析

2.3.8.2

统计各种登录失败的原因，使操作员根据不同的原因作对应的处理。

如：

重复并多日从同一ip密码登录失败，则联系此客户，如果不是客户本人操作则为恶意登录，把此ip加入黑名单。

事件报告

2.3.8.3

对影响系统稳定的重要事件，写入事件日志，并提供事件报告供监控人员使用和处理：

1.网络不稳定，常断开的线路连接写入事件日志

2.一定时间内大量失败的交易

3.对系统服务水平降低到预先规定的最小值进行检查和报警

日志分析

2.3.8.4

根据记录的详细日志，提供日志分类查询和统计功能

其他补充

2.3.9

防止人为篡改数据

2.3.9.1

为防止黑客通过数据库或内部人员修改数据，应有以下系统的防范或检查措施，保证或发现系统业务安全运行的逻辑安全体系设计：

防止黑客攻击或内部人员人为通过直接修改数据库中资金余额、交易金额等关键数据，而不被发觉并能正常交易和资金转移。

防止彩票业务数据在提交交易到兑奖后的整个时间段，交易数据没有被人为修改而不能被发觉。

通知提醒

2.3.9.2

通知方式主要有短信，邮件，站内页面通知，客户人工等方式。

所有关键业务执行成功后，都应该通过各种通知方式提醒客户，使客户对可疑交易确认和相应处理。

可根据通知方式所需的成本，对不同重要性的业务执行不同的通知。

如支付和修改密码等必须短信和邮件通知，其他修改和普通业务开通只需邮件通知即可。

对于监控到的可疑交易，或者需要尽快确认的问题，业务人员直接电话沟通，同时电话需要录音。

数据安全

2.4

数据保存

2.4.1

客户身份信息

2.4.1.1

应按规定妥善保管客户身份基本信息，支付机构对客户身份信息的保管期限自业务关系结束当年起至少保存5年

支付业务信息

2.4.1.2

应按规定妥善保管支付业务信息，支付机构对支付业务信息的保管期限自业务关系结束当年起至少保存5年

会计档案信息

2.4.1.3

应按规定妥善保管会计档案，支付机构对会计档案的保管期限适用《会计档案管理办法》（财会字〔1998〕32号文印发）相关规定

数据安全性

2.4.2

物理存储

2.4.2.1

具备高可用性的数据物理存储环境，

实时在线的存储备份设施，

提供异地数据备份功能，利用通信网络将关键数据定时批量传送至备用场地

客户身份认证信息存储安全

2.4.2.2

不允许保存支付服务业务系统非必须的客户身份认证信息（如银行卡交易密码、指纹、银行卡磁道信息、CVN、CVN等）

终端信息采集设备硬加密措施或其它防伪手段

2.4.2.3

如果使用终端信息采集设备则应采取硬加密措施，否则要使用其它手段达到防伪目的

数据访问控制

2.4.2.4

1.服务器数据的权限访问控制，分级访问主机和文件目录

2.敏感业务数据（卡号、余额等）的权限访问控制，主要是程序控制和目录权限控制，如果能加密存储最好。

3.日志系统的权限访问控制，多不等级的操作员看到不同的内容，并且所有日志不允许删除，只能查询和统计

关键链路冗余设计

2.4.2.5

应采用冗余技术设计网络拓扑结构，避免关键节点存在单点故障；应提供主要网络设备、通信线路和数据处理系统的硬件冗余，保证系统的高可用性。

加密存储和传输

2.4.2.6

1.传输：

应采用加密或其他有效措施实现系统管理数据、鉴别信息和重要业务数据传输保密性。

2.存储：

应采用加密或其他保护措施实现系统管理数据、鉴别信息和重要业务数据存储保密性