可借鉴的一些安全管理检测

1、接口服务层部署要求

检测目的：验证应用方是否遵循 JR/T 0185—2020 中商业银行应用程序接口网络部署逻辑结构示意图，进行商业银行应用程序接口的安全部署。

检测方法：

1) 检查应用方是否在互联网边界部署了具备访问控制、入侵防范相关安全防护能力的网络安全防护措施，如：防火墙、IDS/IPS、DDoS 防护等，同时检查安全防护措施是否配置了有效的防护规则；

2) 检查应用方通过互联网、移动互联网网络访问商业银行应用程序接口相关应用服务的服务器，是否部署在应用方互联网接入安全防护设备之后的逻辑隔离区域；

3) 检查应用方部署商业银行应用程序接口有关安全控制措施，是否符合国家网络安全等级保护有关标准二级及以上安全要求。

通过标准：

1) 应用方在互联网边界部署了具备访问控制、入侵防范相关安全防护能力的网络安全防护措施，并配置了有效的防护规则；

2) 应用方通过互联网、移动互联网网络访问商业银行应用程序接口相关应用服务的服务器，部署在应用方互联网接入安全防护设备之后的逻辑隔离区域；

3) 应用方部署商业银行应用程序接口的有关安全控制措施，符合国家网络安全等级保护有关标准二级及以上安全要求。

1、应用方身份核验

检测目的：验证应用方在接入注册与审批阶段是否按商业银行要求提供身份核验资料。

检测方法： 访谈相关人员，并检查相关材料，确认应用方是否按照商业银行的要求，在注册与审批阶段向商业银行提交了运营资质、法人信息材料、主要应用开发人员的个人信息身份材料等必要的身份核验材料。

通过标准： 在应用方接入注册与审批阶段，应用方按照商业银行要求，提交必要的身份核验资料，包括但不限于运营资质、法人信息材料、主要应用开发人员的个人信息身份材料等。

2、安全传输

检测目的：验证商业银行与应用方之间的网络安全传输是否符合安全要求。

检测方法：

1) 检查对于 A1 类，是否采用 MAC 校验等手段保证商业银行与应用方之间数据传输的完整性；

2) 检查对于 A2 类，是否采用数字签名等手段保证商业银行与应用方之间数据传输的完整性与不可抵赖性；

3) 检查商业银行与应用方之间数据传输是否采用 SSL/TLS 等安全通道连接进行通信及使用的 SSL/TLS 版本。

通过标准：

1) 对于A1 类，应采用MAC 校验等手段，保证商业银行与应用方之间数据传输的完整性，必要时可采用数字签名技术；

2) 对于 A2 类，应采用数字签名等手段，保证商业银行与应用方之间数据传输的完整性与不可抵赖性；

3) 应采用 SSL/TLS 等安全通道连接进行安全通信，宜使用 TLS1.2 及以上版本。

3、用户身份认证

检测目的：验证应用方在用户身份认证方面是否满足安全要求。

检测方法：检查若用户个人金融信息或支付敏感信息确需在应用方输入，应用方是否在本地留存相关信息。

通过标准： 若用户个人金融信息或支付敏感信息确需在应用方输入，应用方不应以任何方式在本地留存相关信息。

4、权限控制

检测目的：验证应用方调用敏感接口时是否满足安全要求。

检测方法： 检查对于获取、使用、变更用户信息、账户、资金等接口，应用方调用接口时，是否首先取得用户明示同意，其内容是否包含授权有效期。

通过标准：对于获取、使用、变更用户信息、账户、资金等接口，应用方调用接口时，首先应取得用户明示同意，其内容应包含授权有效期。

5、数据安全

检测目的：验证应用方在数据安全保护方面是否满足安全要求。

检测方法：

数据完整性保护：检查应用方是否对数据完整性进行校验，并在检测到完整性错误时是否采取必要的恢复措施。

数据机密性保护：

a) 检查应用方是否采集、存储用户个人金融信息或支付敏感信息；

b) 检查对于需要用户输入支付敏感信息或身份鉴别信息的场景，应用方是否仅作为信息的采集与传输通道，是否部署商业银行 SDK、釆取报文加密等措施，保证采集与传输信息的机密性与完整性，支付敏感信息与身份鉴别信息是否在应用方进行留存；

c) 数据抗抵赖性保护：检查应用方是否使用数字签名等技术确保 A2 类数据的不可抵赖性；

d) 数据删除与销毁：检查应用方是否承诺在合作终止后，将依据与商业银行约定的方式删除（或销毁）通过商业银行应用程序接口获取的商业银行及其用户的相关数据；

e) 检查针对接口处理的数据，应用方是否建立数据备份管理机制和应急灾备机制，并纳入机构灾备体系。检查应用方是否承诺在合作终止后，依据行业主管部门有关要求，履行反洗钱、反欺诈等义务。

通过标准：

1) 数据完整性保护：应对数据完整性进行校验，并在检测到完整性错误时采取必要的恢复措施（或停止执行请求）。

2) 数据机密性保护：

a) 不应采集、存储用户个人金融信息或支付敏感信息；

b) 对于需要用户输入支付敏感信息或身份鉴别信息的场景，应用方仅可作为信息的采集与传输通道，应部署商业银行 SDK、釆取报文加密等措施，保证采集与传输信息的机密性与完整性，支付敏感信息与身份鉴别信息不应在应用方留存；

c) 数据抗抵赖性保护：应使用数字签名等技术确保 A2 类数据的不可抵赖性；

d) 数据删除与销毁：应用方通过签署相关协议等有效方式承诺在合作终止后，依据与商业银行约定的方式删除（或销毁）通过商业银行应用程序接口获取的商业银行及其用户的相关数据；

e) 针对接口处理的数据，应建立数据备份管理机制和应急灾备机制，并纳入机构灾备体系。检查应用方通过签署相关协议等有效方式承诺在合作终止后，依据行业主管部门有关要求，履行反洗钱、反欺诈等义务。

检测目的：验证应用方安全防护是否满足安全要求。

检测方法：

1) 查看应用方安全建设方案、验收报告、最近的等保测评报告等材料，确认其是否按照国家网络安全等级保护相应要求，进行了安全设计、安全建设和安全保护；

2) 查看应用方源代码，确认应用方是否遵循商业银行的安全设计要求，使用了商业银行提供的安全接口，依据用户手册和安全规范进行了集成；

3) 查看应用登录相关设备，检查应用方是否存留了与商业银行应用程序接口集成相关的应用系统、网络设备、主机设备、安全产品日志，确认存留的日志是否不少于 6 个月；

4) 通过访谈、文档审查、配置检查、查看源代码等方式确认应用方是否通过有效的技术手段和管理措施等防止接口滥用。

通过标准：

1) 应用方应按照国家网络安全等级保护相应要求，进行安全设计、安全建设和安全保护；

2) 应用方应遵循商业银行的安全设计要求，使用了商业银行提供的安全接口，并依据用户手册和安全规范进行了集成；

3) 应用方应存留与商业银行应用程序接口集成相关的应用系统、网络设备、主机设备、安全产品日志，日志存留不少于 6 个月；

1. 应通过有效的技术手段和管理措施防止接口滥用。

检测目的：验证应用方接口集成是否满足安全要求。

检测方法：

1) 查看应用方接口集成程序源代码，确认其是否按照商业银行提供的用户手册以及授权其使用的服务类型要求，正确合理的使用 API；

2) 查看应用方接口集成程序源代码，确认应用方是否对密钥加密存储，密钥加密使用的密码算法是否符合法律法规的规定和密码相关国家标准、行业标准的有关要求，相关密钥、数字证书的使用和保管是否符合商业银行提供的用户手册要求；

3) 如商业银行提供封装了商业银行应用程序接口调用的 SDK，审查应用方接口集成程序源代码，分析应用方是否使用商业银行提供的 SDK 进行 API 调用，是否对商业银行提供的 SDK 进行了篡改或二次封装，应用方是否承诺不会对商业银行提供的 SDK 进行反编译；

4) 访谈应用方相关人员，了解应用方是否承诺若发现商业银行应用程序接口存在安全缺陷，将采取合理的补救措施并及时通知商业银行；了解应用方是否承诺未经商业银行许可，不会将发现的缺陷细节透露给任何其他第三方；

5) 查看相关资料，确认应用方是否承诺不会利用商业银行应用程序接口漏洞，进行网络攻击、信息窃取或交易欺诈等非法操作。

通过标准：

1) 应用方 API 使用正确合理，符合商业银行提供的用户手册和授权其使用的服务类型要求；

2) 应用方对密钥加密存储，相关密钥、数字证书的使用和保管符合商业银行提供的用户手册要求；

3) 如商业银行提供封装了商业银行应用程序接口调用的 SDK，应用方需使用商业银行提供的 SDK 进行 API 调用，不得对商业银行提供的 SDK 进行篡改或二次封装；应用方通过签署相关协议等有效方式承诺承诺不会对商业银行提供的 SDK 进行反编译；

4) 若应用方发现商业银行应用程序接口存在安全缺陷，应采取合理的补救措施并及时通知商业银行。应用方通过签署协议等有效方式承诺未经商业银行许可，不得将缺陷细节透露给任何其他第三方；

5) 应用方应承诺不会利用商业银行应用程序接口漏洞，进行网络攻击、信息窃取或交易欺诈等非法操作

1、异常监测

检测目的：验证应用方是否具有故障识别与隔离能力。

检测方法：

1. 检查应用方是否具有故障识别与隔离能力，查看应用故障识别与隔离能力情况；

2) 检查应用方是否具有熔断机制，查看熔断规则和熔断措施是否包括失败笔数阈值、商业银行应用程序接口调用失败阈值、拒绝交易和暂停服务调用等；

3) 检查是否建立异常告警处理机制。

通过标准：

1) 应用方具备故障识别与隔离能力，发生异常情况应用方具备合理的处理措施及能力；

2) 应用方具有熔断机制，并依据制度执行，查看熔断规则和熔断措施是否包括失败笔数阈

值、商业银行应用程序接口调用失败阈值、拒绝交易和暂停服务调用等内容，相关要求配置合理；

3) 建立了相关异常告警处理机制，明确了异常告警时，对应处理措施，发生问题时以某种方式主动通知相关人员及时处置。

2、交易流程控制

检测目的：验证应用方是否建立交易流程控制体系。

检测方法：

1) 访谈相关人员，确认是否建立有效的交易流程控制体系，查看交易流程控制体系是否符合要求；

2) 检查身份认证服务等授权类服务以何种方式识别是否经过用户本人授权；

3) 检查账户查询、资金交易、金融产品及服务申请类交易以何种方式识别是否经过用户本人发起（或本人授权发起），核实用户本人意愿；

4) 验证发生资金类等高风险金融服务时，是否向用户提示相关安全风险。

通过标准：

1) 应用方建立了有效的交易流程控制体系，交易流程控制体系符合要求，并依据该体系运行实施；

2) 发生身份认证服务类等授权服务操作时，系统应能够充分识别经过用户本人授权发起；

3) 发生账户查询、资金交易、金融产品及服务申请类交易操作时，系统应能够充分识别经过用户本人发起（或本人授权发起），并能够核实用户本人意愿；

3、变更控制

检测目的：验证应用方是否采取有效的变更控制措施。

检测方法：

1) 检查应用方是否具备有效的变更方案和应急预案；

2) 检查是否具备应用方对商业银行应用程序接口的使用发生重大变更时，如其交易量预期发生变化、对商业银行应用程序接口集成方案进行修改等可能对商业银行系统安全性、业务连续性等造成重大影响的有关事项相关的变更方案和应急预案。

通过标准：

1) 应用方具备变更方案和应急预案相应控制措施，明确了当应用程序接口的使用发生变更时应及时对变更结果进行评估并告知商业银行，同时充分履行用户告知义务，具备完整的变更过程文档和记录；

2) 具备发生重大变更时对应的变更方案和应急预案，明确了相关处理流程且具备完整的变更过程记录。

4、运维巡检

检测目的：验证应用方是否定期对商业银行应用程序接口进行安全巡检。

检测方法：

1) 检查应用方是否定期对商业银行应用程序接口进行安全巡检，包括：定期对其调用商业银行应用程序接口的应用系统进行安全评估，及时处理安全漏洞，确保调用的真实有效。

通过标准：

1) 应用方采用了恰当的方法定期对商业银行应用程序接口进行安全巡检，巡检内容包括定期对其调用商业银行应用程序接口的应用系统进行安全评估，并及时处理了安全漏洞，具备相关记录

检测目的：验证应用方是否具备安全审计能力。

检测方法：

1) 检查应用方是否完整记录商业银行应用程序接口访问日志，日志记录中应以部分屏蔽的方式记录支付账号（或其等效信息），除此之外的个人金融信息不应在应用方接口日志中进行记录。

2) 检查应用方是否对日志记录进行完整性保护，确保日志不被篡改、删除、覆盖。

3) 检查应用方是否提供查询应用方用户商业银行应用程序接口历史操作日志功能，日志内容是否包含登录、授权、交易等。

通过标准：

1) 应用方记录了完整的商业银行应用程序接口访问日志，日志记录中以部分屏蔽的方式记录支付账号（或其等效信息），除此之外的个人金融信息未在应用方接口日志中进行记录；

2) 应用方对日志记录有完整性保护措施，能够确保日志不被篡改、删除、覆盖；

3) 应用方提供了查询应用方用户商业银行应用程序接口历史操作日志功能，日志内容包含登录、授权、交易等。