RBI 规则要求您评估移动银行应用，并在每次发布前后进行测试。

1. 01

   RBI (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, 第 149 至 161 段

   按固定间隔测试关键互联网应用

   文本的内容

   对所有关键和面向互联网的系统定期开展 VA 与 PT，并对关键、面向互联网的 Web 和移动应用，在其整个生命周期（包括实施前、实施后和变更后）定期开展 VA 与 PT。对关键信息系统以及有客户界面的 DMZ 系统，至少每半年进行一次 VA，每 12 个月至少进行一次 PT；其他系统采用基于风险的方法。实施后测试在生产环境进行，或在接近生产的测试环境进行，任何偏差均须记录并获批。对发现的漏洞限期修复，并至少每季度向 IT 战略委员会和信息安全委员会报告关闭情况。

   来源：RBI (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, 第 149 至 161 段

   对您的移动应用意味着什么

   移动应用是有客户界面的关键互联网应用，需要每半年一次的 VA、每年一次的 PT，以及每次变更后的测试，而不只是上线时测一次。

   Ostorlab 如何提供帮助

   Mobile SAST 分析包括内嵌 SDK 在内的二进制文件，Mobile DAST 测试运行中的应用，两者都在 CI/CD 中运行。AI 智能体渗透测试在登录后测试应用及其 API，并为每个 AI 智能体发现提供可重放的有效漏洞利用。

   仍由您负责的部分

   为服务器和网络组件设定范围与频率、委任 VA 与 PT 审计方，以及向委员会报告关闭情况。

2. 02

   RBI (Commercial Banks – Digital Payment Security Controls) Directions, 2026, 第 68 段；Master Direction on Digital Payment Security Controls, 2021 年 2 月 18 日, 第 IV 章（早期表述）

   落实移动支付应用控制措施

   文本的内容

   移动支付应用控制措施要求银行能够在启用交易前验证应用版本，并根据风险评估执行设备策略，包括检查存在漏洞的操作系统、存在漏洞或恶意的应用以及不安全的 Wi-Fi 配置；应用沙箱或容器化与加密；最小化数据收集与权限；识别远程访问应用并禁止从其登录；以及代码混淆。旧版本应用须分阶段、限期停用，不超过新版本发布后六个月。银行须在公共平台公布当前有效版本的校验和，实施设备绑定，在闲置一段时间后及每次启动时要求重新认证，并识别来自不安全网络的连接。银行还可以验证设备、操作系统和应用的安全性与兼容性，并可在安装前检查设备是否已 Root 或越狱，若已 Root 或越狱则阻止应用安装或运行。

   来源：RBI (Commercial Banks – Digital Payment Security Controls) Directions, 2026, 第 68 段；Master Direction on Digital Payment Security Controls, 2021 年 2 月 18 日, 第 IV 章（早期表述）

   对您的移动应用意味着什么

   这些控制措施您的应用要么有、要么没有，而且每一项都能在客户下载的版本上测试：Root 与越狱检测、远程访问检测、混淆、版本校验和设备绑定。

   Ostorlab 如何提供帮助

   Mobile Shielding Scan 在运行时测试 Root 和越狱检测、防篡改和证书固定，展示哪些防护有效、哪些被绕过。Ostorlab 还会报告其观察到的应用版本、权限和网络连接。

   仍由您负责的部分

   编写设备策略、托管校验和、维护设备绑定记录，以及就新设备注册通知客户。

3. 03

   RBI (Commercial Banks – Digital Payment Security Controls) Directions, 2026, 第 27 至 39 段；Cybersecurity Directions, 2026, 第 83 至 87 段

   将安全内置，并在发布前后测试

   文本的内容

   采用安全设计方法，将安全贯穿应用生命周期：在需求、设计、开发、测试、实施和退役各阶段明确安全目标；威胁建模；安全编码实践；以及与全球标准（包括 OWASP 和 OWASP MASVS）一致的安全测试。对数字支付应用开展包括源代码审查、VA 和 PT 在内的安全测试：VA 至少每半年一次，PT 至少每年一次，并在引入新应用或基础设施或进行重大变更时开展。源代码不归银行所有时，须取得开发方出具的证明，确认应用不含已知漏洞、恶意软件和隐蔽通道。将结果与早前扫描对比以确认没有复发，并限期修复已发现的漏洞。网络安全指引还要求对 Web 和移动应用在其整个生命周期内、在接近生产的环境中进行应用安全测试。

   来源：RBI (Commercial Banks – Digital Payment Security Controls) Directions, 2026, 第 27 至 39 段；Cybersecurity Directions, 2026, 第 83 至 87 段

   对您的移动应用意味着什么

   每次发布都是对面向互联网渠道的一次变更。流水线中的自动化测试覆盖发布前，商店版本的扫描覆盖发布后。

   Ostorlab 如何提供帮助

   Ostorlab 从您的 CI/CD 流水线在每次构建时运行自动化扫描，无需手动触发即可监控商店发布版本。Mobile SAST 可直接分析 APK、AAB 或 IPA，无需源代码。

   仍由您负责的部分

   安全需求、威胁模型、安全编码标准、源代码审查和发布批准。

4. 04

   RBI (Authentication mechanisms for digital payment transactions) Directions, 2025, 第 6、8 和 9 段

   双因素认证，其中至少一个为动态

   文本的内容

   除豁免情形外，所有数字支付交易必须使用至少两种不同的认证因素进行认证；对于非卡类在场交易，至少一个因素必须动态生成或证明，即随交易发送的证明为该交易独有。因素必须稳健：一个因素被攻破不得影响另一个因素的可靠性。发行方可提供多种因素选择，可基于行为和上下文（如位置、设备属性）增加基于风险的检查，但必须在部署前确保机制的稳健性和完整性。若因不符合规定的交易造成损失，发行方须无条件全额赔偿客户。合规期限为 2026 年 4 月 1 日。

   来源：RBI (Authentication mechanisms for digital payment transactions) Directions, 2025, 第 6、8 和 9 段

   对您的移动应用意味着什么

   第二个因素必须由服务端在每笔支付上强制执行，而且必须是动态的。短信 OTP 是一种选择，但指引明确允许设备绑定、生物识别或 PKI 等替代方案。

   Ostorlab 如何提供帮助

   认证测试使用您的测试账户完成短信、邮件或 TOTP 一次性验证码，并测试 MFA 执行、增强验证流程以及支付背后的 API 调用。

   仍由您负责的部分

   选择认证因素、豁免分析、客户沟通和赔偿流程。

5. 05

   RBI (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, 第 107、110 和 115 段；Digital Payment Security Controls Directions, 2026, 第 46 段

   认证客户和特权用户

   文本的内容

   银行必须实施认证框架，确保通过所有渠道访问其服务的客户得到身份确认，并使用安全认证技术，作为客户访问合作方系统的身份提供方。基于风险评估，实施双因素或多因素认证，包括对关键信息系统的特权用户和关键活动强制实施 MFA，并保护登录用户名、认证信息和令牌等用户凭据免遭泄露和攻击。数字支付安全指引还要求对所有支付交易（包括借记和贷记）、新增账户关联、账户信息变更和转账限额调整实施 MFA 和提醒。

   来源：RBI (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, 第 107、110 和 115 段；Digital Payment Security Controls Directions, 2026, 第 46 段

   对您的移动应用意味着什么

   登录、取款、变更收款人和限额，都是后端必须要求正确因素的时刻。设备上的令牌处理属于同一项控制。

   Ostorlab 如何提供帮助

   Ostorlab 在应用包中发现 API 密钥、令牌和凭据并验证其是否有效，并测试 API 的授权缺陷（BOLA、BFLA、IDOR）以及令牌和会话的滥用。

   仍由您负责的部分

   身份核验、特权访问管理、访问审查和认证技术选型。

6. 06

   RBI (Commercial Banks – Digital Payment Security Controls) Directions, 2026, 第 48 至 51 段

   会话、失败尝试和提醒

   文本的内容

   已认证的会话及其加密协议必须在整个交互过程中保持完整；如果发生干扰或客户关闭应用，会话必须终止，受影响的交易必须解决或冲正，并及时通知客户。银行必须规定登录或认证失败的最大次数，超过后封锁访问，建立安全的重新开通流程，并将失败尝试通知客户。还必须针对中间人、浏览器中间人和应用中间人攻击采取措施，确保传输中的数据安全，并且只有真实来源或流程发起的交易才能通过认证。

   来源：RBI (Commercial Banks – Digital Payment Security Controls) Directions, 2026, 第 48 至 51 段

   对您的移动应用意味着什么

   会话处理是可测试的行为：超时、令牌刷新、注销或关闭应用时的失效、失败尝试后的锁定，以及它们背后的 API 调用。

   Ostorlab 如何提供帮助

   认证测试覆盖登录和注销、令牌刷新、超时、会话失效和锁定，以及它们背后的 API 调用，并为每个发现提供复现步骤。

   仍由您负责的部分

   提醒渠道、重新开通流程，以及消费这些提醒的反欺诈监控规则。

7. 07

   RBI (Commercial Banks – Digital Payment Security Controls) Directions, 2026, 第 22、24 和 68(10) 至 68(13) 段；Digital Lending Directions, 2025, 第 12 和 13 段

   保护设备上和传输中的数据

   文本的内容

   Web 应用不得在 HTML 隐藏字段、Cookie 或其他客户端存储中保存敏感信息。加密控制必须使用未过时、未被证明不安全的强密钥长度、算法、密码套件和协议。移动应用不得在设备上存储或保留用户 ID、密码、密钥、哈希或硬编码引用等敏感个人或认证信息，并须在客户退出时从内存中安全清除敏感客户信息。须限制写入临时文件的敏感信息并加以保护，避免原始 SQL 查询和 SQL 注入，在检测到 SSL/TLS 协商错误时不得加载 Web 内容。写入应用数据库的敏感信息必须加密。对于借贷应用，Digital Lending Directions 禁止访问文件与媒体、联系人、通话记录和电话功能等手机资源，并要求数字借贷数据存储在印度境内的服务器上。

   来源：RBI (Commercial Banks – Digital Payment Security Controls) Directions, 2026, 第 22、24 和 68(10) 至 68(13) 段；Digital Lending Directions, 2025, 第 12 和 13 段

   对您的移动应用意味着什么

   密码、令牌和个人数据绝不能以明文留在手机上、临时文件、日志或截图中，也绝不能无保护地传输到后端。

   Ostorlab 如何提供帮助

   Ostorlab 在本地存储、缓存、日志、临时文件和截图中查找会话令牌和个人数据，检查削弱传输和会话保护的配置错误，并采集文件系统证据，显示写入了什么、在哪里、何时写入。

   仍由您负责的部分

   数据分类、密钥管理、备份、隐私告知和防数据泄露。

8. 08

   RBI (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, 第 47 和 126 至 135 段；Digital Payment Security Controls Directions, 2026, 第 32 段

   了解组件和第三方

   文本的内容

   维护信息资产的最新清单，包括业务应用、支撑 IT 基础设施、硬件、软件和服务，并标明其业务重要性。数字支付安全指引要求，在代码发生重大变更时，取得应用开发方或供应商出具的证明或书面确认，说明应用不含已知漏洞、恶意软件和隐蔽通道；对第三方许可的应用，须安排源代码托管或其他措施。第三方安排需要与风险和重要性相称的供应商风险评估、尽职调查与监督、包含审计权的协议，并关注基础设施的地理位置和跨境数据传输。

   来源：RBI (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, 第 47 和 126 至 135 段；Digital Payment Security Controls Directions, 2026, 第 32 段

   对您的移动应用意味着什么

   移动银行应用捆绑了与各自后端通信的第三方 SDK，它们应纳入您的资产清单、SBOM 和第三方风险视图。

   Ostorlab 如何提供帮助

   Ostorlab 列出每个版本中的 SDK 和原生库及其版本和在应用包中的位置，逐版本映射到已知漏洞，并展示应用及其 SDK 通过网络与后端交换的内容。

   仍由您负责的部分

   资产台账、供应商尽职调查、供应商证明、托管安排和合同。

9. 09

   RBI (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, 第 37、98 至 103 和 153 段

   限期管理漏洞和补丁

   文本的内容

   建立书面的变更与补丁管理政策，评估补丁的业务影响，在获得必要批准后安全、及时地应用，并提供部署失败后的恢复手段。采用书面的、基于风险的策略，维护需要打补丁的组件清单，识别适用的补丁并及时应用，以尽量减少存在漏洞的系统和暴露时长。监控软件停止支持日期，避免使用过时或不再受支持的软件。对发现的漏洞限期修复，并检查 CVE 数据库等已知漏洞不再复发。

   来源：RBI (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, 第 37、98 至 103 和 153 段

   对您的移动应用意味着什么

   应用中的库和 SDK 是您交付的软件。每一个都需要已知版本、出现漏洞时的严重级别，以及可以证明的修复期限。

   Ostorlab 如何提供帮助

   SCA 识别静态编译的库并逐版本映射到已知漏洞。发现按严重、高、中、低评级，在平台或 Jira、ServiceNow 中作为工单跟踪，并在修复发布后重新测试。

   仍由您负责的部分

   服务器和基础设施补丁、供应商维护合同和风险接受决策。

10. 10

    RBI (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, 第 182 段；CERT-In 指示 No. 20(3)/2022-CERT-In, 2022 年 4 月 28 日；Digital Personal Data Protection Rules, 2025, 第 6 和 7 条

    报告事件和泄露，将日志保存在印度

    文本的内容

    网络事件必须在发现后六小时内报告到 RBI 的高级监管监控系统 DAKSH 平台，同时通知 CERT-In。根据 2022 年 CERT-In 指示，指定事件必须在察觉后六小时内报告 CERT-In，ICT 日志必须在印度司法管辖范围内安全保存 180 天（滚动），系统时钟必须与 NIC 或 NPL 时间同步。根据 2025 年 DPDP 规则，个人数据泄露必须立即通知受影响的数据主体，并立即通报数据保护委员会，72 小时内提供详细信息，安全日志须保存一年。

    来源：RBI (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, 第 182 段；CERT-In 指示 No. 20(3)/2022-CERT-In, 2022 年 4 月 28 日；Digital Personal Data Protection Rules, 2025, 第 6 和 7 条

    对您的移动应用意味着什么

    通过应用或 API 发现的泄露会启动计时。六小时和 72 小时的窗口从发现时开始，证据必须随时可用。

    Ostorlab 如何提供帮助

    Ostorlab 不向 RBI、CERT-In 或数据保护委员会报告事件。它为您的事件和法律团队提供报告所需的技术证据：可重放的漏洞利用、请求与响应日志和文件系统证据，并跟踪发现直至关闭，以便您说明修复了什么、何时修复。

    仍由您负责的部分

    检测与监控、DAKSH 和 CERT-In 报告、泄露通知和法律评估。

对 RBI、MeitY 和 CERT-In 公开文本的摘要，核对日期为 2026 年 9 月 27 日。2026 年 7 月指引适用于商业银行；RBI 针对其他受监管机构发布了类似的分类指引，本页引用的 2021 年和 2023 年文本已于 2026 年 7 月 31 日对商业银行废止。本页不构成法律意见。