CBK 网络安全指引:在每次发布前后测试您的移动银行应用及其背后的 API。
肯尼亚中央银行(CBK)2017 年的《网络安全指引》要求银行至少每年开展一次独立的网络威胁测试,并将威胁和漏洞评估以及全面的渗透测试纳入内部和外部审计范围。其 2019 年面向支付服务提供商的指南规定了季度漏洞扫描和年度渗透测试。2019 年《数据保护法》要求在设计和默认层面落实保护措施。Ostorlab 在每次发布时测试您的应用及其背后的 API,覆盖登录后的流程。
- 基于客户实际下载的版本,测试移动应用及其调用的 API
- 使用您的测试账户测试登录、一次性验证码、增强验证和会话处理
- 列出每个版本中的 SDK 和原生库,并将其与已知漏洞对应
- 每项发现都以可重放的漏洞利用或请求和响应证据作为证明
- 适用对象
- 根据《Banking Act》获得许可的银行,以及根据 2011 年《National Payment System Act》获得授权的支付服务提供商
- 关键日期
- 《网络安全指引》发布于 2017 年 8 月;支付服务提供商指南发布于 2019 年 7 月;CBK 正在更新 2017 年指引
- 重点
- 独立网络威胁测试、漏洞评估和渗透测试、第三方风险以及数据保护
- 主要参考
- CBK《Guidance Note on Cybersecurity for the Banking Sector》,2017 年 8 月
移动渠道背后的 CBK 文本
2017 年的银行指引、支付服务提供商指南和《National Payment System》规则与《数据保护法》并行。以下日期对应本页引用的文本和进展。
- 2011 年和 2014 年
National Payment System Act 与 Regulations
《National Payment System Act》(2011 年第 39 号法律)赋予 CBK 对支付系统的监管权以及发布指令和指南的权力。2014 年条例为支付服务提供商增加了运营、审计轨迹、报告和年度系统安全审计义务。
- 2013 年 1 月
Risk Management Guidelines
CBK 发布风险管理指南。第 7 章涉及 ICT 风险,包括将漏洞扫描器和渗透测试作为识别漏洞的工具,以及信息安全计划。
- 2017 年 8 月
Guidance Note on Cybersecurity
CBK 依据《Banking Act》第 33(4) 条发布《Guidance Note on Cybersecurity for the Banking Sector》。该指引要求至少每年开展一次独立的网络威胁测试,将威胁和漏洞评估以及全面渗透测试纳入审计范围,并要求重大事件在 24 小时内报告 CBK。
- 2019 年 7 月
支付服务提供商指南
CBK 发布《Guideline on Cybersecurity for Payment Service Providers》。该指南规定对关键网络资产进行季度漏洞扫描、年度渗透测试和半年度漏洞评估,并给予 90 天的合规期。
- 2025 年 3 月
采用情况调查
CBK 调查银行对 2017 年《网络安全指引》的采用情况。所有受访银行都表示以年度、季度或月度为周期开展漏洞评估和渗透测试,92% 的银行在内部审计团队中配备 IT 审计人员。报告于 2025 年 6 月发布。
- 2025 年 9 月 22 日
银行业 SOC
CBK 宣布设立 Banking Sector Cyber Security Operations Centre,隶属其 Cyber Fusion Unit,并开始将 2017 年和 2019 年的网络安全指引与 2024 年关键信息基础设施相关条例对齐。各机构必须继续同时遵守两套要求,并向该中心报告事件。
- 2026 年 9 月 22 日
指引正在修订
《2025 年银行监管年度报告》指出,CBK 已着手更新 2017 年《网络安全指引》。受访银行要求将 API 安全、人工智能、云计算和移动支付欺诈检测纳入指引。
- 2026 年 9 月
征求意见的草案
CBK 于 2026 年 9 月 10 日发布修订后的《Prudential Guidelines》《Risk Management Guidelines》和《Guidance Notes》草案征求意见;国家财政部与 CBK 于 2026 年 9 月 21 日发布《National Payment System Policy and Bill 2026》草案。这些均为草案,尚未生效。
将 CBK 文本应用于您的移动应用
每条规则都说明:文本的内容、它对移动银行应用意味着什么、Ostorlab 如何提供帮助,以及哪些工作仍由您的团队负责。
- 《Guidance Note on Cybersecurity for the Banking Sector》,2017 年 8 月,第 3.2 节
至少每年开展一次独立的网络威胁测试
文本的内容
各机构应聘请具备足够网络安全专业能力的外部顾问,协助了解自身的网络威胁态势,并至少每年开展一次独立的网络威胁测试。外部审计师应将独立的威胁和漏洞评估以及全面的渗透测试纳入 IT 审计范围,并每年向董事会和肯尼亚中央银行报告结果。
来源:《Guidance Note on Cybersecurity for the Banking Sector》,2017 年 8 月,第 3.2 节
对您的移动应用意味着什么
年度测试是下限而非上限。应用及其调用的 API 属于范围内的系统,每次商店发布都是对它们的变更。
Ostorlab 如何提供帮助
AI 智能体渗透测试覆盖登录后的应用及其 API,针对您发布的版本,AI 智能体的每个发现都附有可重放的有效漏洞利用。它可以在每次发布时运行,位于年度测试之间。
仍由您负责的部分
选择外部顾问、确定审计范围,以及向董事会和 CBK 提交年度报告。
- 《Guidance Note on Cybersecurity for the Banking Sector》,第 3.2 节(内部审计与风险管理职能)
将威胁和漏洞测试保留在审计范围内
文本的内容
内部审计应包括合格的 ICT 审计人员,可来自内部或外包。其范围包括持续审查并报告 ICT 系统和相关第三方连接的网络风险与控制、评估网络安全框架的设计和有效性、定期开展独立的威胁和漏洞评估、开展全面的渗透测试,并向董事会报告结果。风险管理应维护网络风险登记册和按业务重要性分类的完整 IT 资产清单,并开展红队演练。
来源:《Guidance Note on Cybersecurity for the Banking Sector》,第 3.2 节(内部审计与风险管理职能)
对您的移动应用意味着什么
审计范围明确提到第三方连接。对移动银行应用而言,这意味着应用、其中的 SDK 及其调用的 API,而不仅是核心银行系统。
Ostorlab 如何提供帮助
Mobile DAST 运行应用及其流程,并返回附有反编译代码上下文、流量、堆栈跟踪和截图的发现,让审计团队获得可用的证据。
仍由您负责的部分
审计计划、红队演练,以及向董事会报告的发现。
- 《Guideline on Cybersecurity for Payment Service Providers》,2019 年 7 月,第 3.2.5 节和第 4.0 节
满足支付服务提供商的测试频率
文本的内容
2019 年《Guideline on Cybersecurity for Payment Service Providers》要求建立包含持续监控以及定期渗透测试和漏洞评估的网络安全计划。在缺乏有效持续监控的情况下,支付服务提供商应对所有关键网络资产进行季度漏洞扫描,开展年度渗透测试并至少覆盖当年根据风险评估确定的关键网络资产,以及进行半年度漏洞评估。提供商自指南生效之日起有 90 天的合规期。
来源:《Guideline on Cybersecurity for Payment Service Providers》,2019 年 7 月,第 3.2.5 节和第 4.0 节
对您的移动应用意味着什么
如果您的机构或集团运营支付服务,频率就是季度扫描、年度渗透测试和半年度评估。移动渠道及其背后的 API 属于关键网络资产。
Ostorlab 如何提供帮助
Ostorlab 可从您的 CI/CD 流水线对每个构建运行扫描,并在无需手动触发的情况下扫描商店版本,因此季度或更高频率是计划安排,而不是一次性项目。
仍由您负责的部分
界定何为关键网络资产、持续监控,以及决定年度范围的风险评估。
- 《National Payment System Regulations》,2014 年,第 27 条和第 29 条
保障支付服务安全并保留审计轨迹
文本的内容
支付服务提供商必须为其服务建立充分的运营安排,包括确保服务安全、可靠运行的措施和应急安排。提供商必须使用能够提供从交易发起到最终完成、准确且完全可访问的审计轨迹的系统,将每笔电子转账的记录保存至少七年,每月向肯尼亚中央银行报告欺诈事件以及重大服务中断或重大安全漏洞,并每年提交由信誉良好的独立审计机构出具的系统安全审计报告。
来源:《National Payment System Regulations》,2014 年,第 27 条和第 29 条
对您的移动应用意味着什么
审计轨迹、七年记录保存和月度报告是提供商的义务。应用及其 API 是交易的起点,因此其行为也是证据的一部分。
Ostorlab 如何提供帮助
Ostorlab 测试应用及其 API,并为每项发现保留请求和响应证据,可直接附入年度系统安全审计和整改记录。
仍由您负责的部分
记录保存、向 CBK 的月度报告,以及聘请独立审计机构。
- 《Guidance Note on Cybersecurity for the Banking Sector》,第 2.4 节和第 3.1 节
为客户数据和交易部署强认证
文本的内容
高级管理层应监督部署强认证措施,以保护客户数据、交易和系统。《网络安全指引》将薄弱的认证控制列为网络风险的来源之一,并要求 CISO 确保机构维护覆盖全企业的用户、设备和应用程序知识库,包括软件和硬件资产清单以及网络图。
来源:《Guidance Note on Cybersecurity for the Banking Sector》,第 2.4 节和第 3.1 节
对您的移动应用意味着什么
第二因素必须由服务器在关键操作中强制执行,而不仅是应用展示。一次性验证码、超时和增强验证都是可以测试的行为。
Ostorlab 如何提供帮助
认证测试使用您的测试账户,覆盖登录和注销、令牌刷新、超时、会话失效和 MFA 强制执行,包括增强验证流程。
仍由您负责的部分
选择认证方式、发送一次性验证码,以及为被锁定的客户提供支持。
- 《Guidance Note on Cybersecurity》第 3.3 节;《Prudential Guidelines》CBK/PG/16(外包),第 4.1.4 节和第 4.5 节
管理第三方和外包
文本的内容
各机构应确保其第三方遵守法律法规框架和国际最佳实践。机构应为外包协议建立充分的治理,包括对潜在服务提供商的尽职调查、书面协议和对服务交付的充分监控;基于合规和风险评估选择供应商;要求服务提供商遵守适用的法律法规框架;监控其业务和网络安全态势的变化;并签订在安全、可用性、绩效指标和处罚方面有强有力条款的服务水平协议。根据《Prudential Guideline CBK/PG/16》,重大外包需要获得肯尼亚中央银行的批准,其中明确将提供移动金融服务渠道或技术列为重大活动的示例。
来源:《Guidance Note on Cybersecurity》第 3.3 节;《Prudential Guidelines》CBK/PG/16(外包),第 4.1.4 节和第 4.5 节
对您的移动应用意味着什么
应用中的 SDK 及其调用的后端都属于第三方。它们的安全态势应纳入您的尽职调查和监控,部分外包在开始前需要 CBK 批准。
Ostorlab 如何提供帮助
SCA 和 SBOM 列出每个版本中的 SDK 和原生库及其版本,网络分析则显示应用及其 SDK 与哪些后端通信。
仍由您负责的部分
尽职调查、合同、CBK 批准以及退出计划。
- 《Risk Management Guidelines》,2013 年 1 月,第 7.3.4、7.4 和 7.5 节
建立 ICT 风险框架并用合适的工具测试
文本的内容
《Risk Management Guidelines》要求建立 ICT 风险管理框架,包括董事会监督、ICT 风险政策,以及促进安全意识并向董事会报告信息安全评估的信息安全计划。在识别漏洞方面,指南提到漏洞扫描器(将系统或其响应与漏洞特征库进行比对)和渗透测试(由人类安全分析师对系统施加威胁的尝试,包括社会工程等运营漏洞)。风险应被评估、衡量、缓解并记录。
来源:《Risk Management Guidelines》,2013 年 1 月,第 7.3.4、7.4 和 7.5 节
对您的移动应用意味着什么
扫描器和渗透测试是文本明确提到的两种漏洞发现工具。移动应用两者都需要:对构建的分析以及对运行中应用及其 API 的动态测试。
Ostorlab 如何提供帮助
Mobile SAST 对 APK、AAB 或 IPA 进行分析,并对应用及其嵌入的 SDK 进行污点分析;Mobile DAST 则运行应用。两者都在 CI/CD 中随每个构建运行。
仍由您负责的部分
ICT 风险政策、向董事会的报告,以及更广泛的信息安全计划。
- 《Data Protection Act》,2019 年,第 41 条和第 42 条;《Data Protection (General) Regulations》,2021 年,第 32 条
在设计和默认层面保护个人数据
文本的内容
2019 年《数据保护法》要求每个数据控制者或处理者实施适当的技术和组织措施,以有效落实数据保护原则并将必要的保护措施融入处理过程,既适用于确定处理方式之时,也适用于处理之时。默认情况下,只应处理每个特定目的所必需的个人数据。应考虑的措施包括识别个人数据面临的内部和外部风险、维持针对这些风险的保护措施、假名化和加密、在事件后恢复可用性、验证保护措施有效,以及针对新风险或缺陷进行更新。当处理涉及通过网络传输时,控制者必须考虑技术水平、措施成本、特殊风险和数据性质。一般条例列出了完整性、机密性和可用性原则的要素,包括评估个人数据安全面临的风险、审计轨迹和事件监控,以及定期审查和测试软件以发现支撑处理的系统的漏洞。
来源:《Data Protection Act》,2019 年,第 41 条和第 42 条;《Data Protection (General) Regulations》,2021 年,第 32 条
对您的移动应用意味着什么
应用是收集、存储和发送个人数据的地方。缓存什么、如何加密以及记录什么等设计选择,都是法律所要求的措施的一部分。
Ostorlab 如何提供帮助
Ostorlab 在本地存储、缓存、日志和截图中查找会话令牌和个人数据,检查传输保护,并在应用包中查找 API 密钥、令牌和凭据,验证它们是否可用。
仍由您负责的部分
数据保护影响评估、同意、保留规则以及泄露处理。
- 《Guidance Note on Cybersecurity》第四部分;《Data Protection Act 2019》第 43 条;《National Payment System Regulations》,2014 年,第 29(2) 条
报告事件并保留记录
文本的内容
《网络安全指引》要求各机构在 24 小时内通知肯尼亚中央银行任何可能对机构向客户提供充分服务的能力、声誉或财务状况造成重大不利影响的网络安全事件,并提交关于事件及其处理情况的季度报告。《数据保护法》要求数据控制者在知悉个人数据被未经授权访问或获取且对数据主体存在实际伤害风险时,毫不迟延并在 72 小时内通知数据保护专员,并以书面形式告知数据主体;处理者必须毫不迟延地通知控制者,在合理可行的情况下在 48 小时内通知。支付服务提供商还须每月向 CBK 报告重大服务中断和重大安全漏洞。
对您的移动应用意味着什么
事件报告由您负责,但计时从发现事件时开始。测试帮助您在问题成为需要报告的事件之前发现并修复它们。
Ostorlab 如何提供帮助
Ostorlab 为每项发现提供技术证据和复现步骤,并在修复后复测,让您在报告时记录完整。
仍由您负责的部分
检测、24 小时、72 小时和月度报告,以及与客户的沟通。
本页概述了 CBK 和 ODPC 的公开文本,核对日期为2026年9月27日。征求意见中的草案文本在本页不作为要求处理。本页不构成法律意见。
逐项梳理 CBK 规则中的控制措施
CBK 和 ODPC 文本所指向的控制措施、Ostorlab 如何在您的应用及其 API 中测试这些控制,以及您可以留存的证据。
| 控制措施 | Ostorlab 如何提供帮助 | 您留存的证据 |
|---|---|---|
| 至少每年一次的独立网络威胁测试Guidance Note 3.2 | 在登录后,针对您发布的版本,由 AI 智能体对应用及其 API 进行渗透测试。 详情 | AI 智能体的每个发现都附有可重放的有效漏洞利用,另有覆盖率热力图 |
| 威胁和漏洞评估以及全面的渗透测试Guidance Note 3.2 | Mobile DAST 运行构建及其流程,并将发现与反编译上下文、流量、堆栈跟踪和截图相对应。 详情 | 附有反编译代码上下文、流量、堆栈跟踪和截图的发现 |
| 支付服务提供商的季度扫描、年度渗透测试和半年度评估PSP 指南 3.2.5 | 即使启用 TLS 证书固定也能拦截流量,并测试授权、令牌滥用以及枚举和重放等滥用行为。 详情 | 每项 API 发现的请求和响应证据,以及每个周期的扫描结果 |
| 支付服务的安全和可靠运行NPS Regulations 第 27 条 | 测试构成客户服务的应用和 API 流程,包括故障和错误处理。 | 可附入年度系统安全审计报告的测试证据 |
| 审计轨迹、记录和报告NPS Regulations 第 29 条 | 将发现归入平台中或 Jira 和 ServiceNow 中的工单,并在修复后复测。 | 每项发现的工单历史和复测结果 |
| 客户数据和交易的强认证Guidance Note 3.1(b)(v) | 使用一次性验证码登录,测试 MFA 强制执行和增强验证流程,以及其背后的 API 调用。 详情 | 有关登录和增强验证流程的发现,附复现步骤 |
| 第三方和外包风险Guidance Note 3.3;CBK/PG/16 | 列出每个版本中的 SDK 和原生库及其版本,并显示应用及其 SDK 与哪些后端通信。 详情 | 每个版本的组件标识、版本和在应用包中的位置 |
| ICT 风险框架和漏洞识别Risk Management Guidelines 7.3.4 | Mobile SAST 对二进制文件进行分析,并对应用及其嵌入的 SDK 进行污点分析。 详情 | 每个构建的发现,附反编译代码上下文 |
| 设备上和传输中的个人数据Data Protection Act 第 41 条 | 在存储、缓存、日志和截图中查找令牌和个人数据,并检查传输保护。 详情 | 文件系统证据,显示写入了什么、写入位置和时间 |
| 定期审查和测试软件以发现漏洞DP General Regulations 32(k) | 在 CI/CD 中对每个构建进行基于二进制文件的 APK、AAB 和 IPA 静态分析。 详情 | 每个构建的扫描结果,附反编译代码上下文 |
Ostorlab 测试应用及其 API 中的控制措施。SOC 监控、事件检测以及向 CBK、数据保护专员或 BS-SOC 的报告、业务连续性和恢复、年度系统安全审计意见、治理以及物理安全仍由您的团队负责。
需要在移动应用中测试的 CBK 控制措施
面向安全和审计团队的实用清单,依据 2017 年《网络安全指引》、支付服务提供商指南和 2019 年《数据保护法》编制。
年度独立测试
将移动应用及其调用的 API 纳入年度独立网络威胁测试的范围,并在审计间隔期于每次发布时测试。
审计与风险范围
将应用及其第三方连接纳入内部审计范围:威胁和漏洞评估、全面的渗透测试,以及面向董事会的证据。
支付服务频率
如果您的集团运营支付服务,应为关键网络资产规划季度漏洞扫描、年度渗透测试和半年度漏洞评估。
认证与会话
测试登录、一次性验证码、增强验证、超时和会话失效,并确认检查在服务器端强制执行。
第三方与 SDK
为每个版本中的 SDK 和后端保留带版本信息的清单,并确认外包安排在开始前是否需要 CBK 批准。
设备上的数据
在存储、缓存、日志和截图中,以及应用包本身中查找令牌和个人数据。
数据保护设计
针对应用梳理第 41 条和第 42 条:收集什么、缓存什么、如何加密,以及如何验证保护措施。
报告与复测
了解向 CBK 的 24 小时和向数据保护专员的 72 小时时限,保留技术证据,并在修复后复测。
此清单仅为建议,并非 CBK 模板,也不构成法律意见。
本页涉及的能力
每项能力都有详细介绍页面。
- Mobile Agentic Deep ScanAI 智能体在每次发布时对商店版本进行渗透测试,AI 智能体的每个发现都附有可重放的有效漏洞利用。了解更多
- 认证测试使用测试账户测试登录、一次性验证码和增强验证流程。了解更多
- API 与后端测试即使启用 TLS 证书固定也能拦截应用流量,并测试账户和支付背后的 API 与后端。了解更多
- Mobile SAST基于二进制文件对 APK、AAB 和 IPA 进行静态分析,并对应用及其嵌入的 SDK 进行污点分析。了解更多
- SCA 与 SBOM发现存在漏洞的依赖项,包括静态编译的原生库,并逐个版本跟踪其关闭情况。了解更多
- Mobile Shielding Scan在运行时测试 Root 和越狱检测、防篡改以及证书固定,查看哪些防护有效、哪些被绕过。了解更多
- 自带 AI 密钥使用您自己的 AI 服务商密钥运行 AI 智能体扫描,并设置单次扫描支出上限,符合内部政策。了解更多
- 本地部署扫描在您自己控制的基础设施上,扫描防火墙或 VPN 后的预发布应用、API 和代码仓库。了解更多
受到银行和金融科技企业的信赖,包括
来源
本页所依据的官方文本,核对日期为2026年9月27日。
- National Payment System Act, No. 39 of 2011, and National Payment System Regulations, 2014该法赋予肯尼亚中央银行对国家支付系统的监管权以及发布指令和指南的权力。2014 年条例要求支付服务提供商保持服务安全、可靠运行(第 27 条),维护审计轨迹并将记录保存至少七年(第 29(1) 条),每月报告重大服务中断和重大安全漏洞(第 29(2)(c) 条),并提交由信誉良好的独立审计机构出具的年度系统安全审计报告(第 29(3)(c) 条)
- Risk Management Guidelines,2013 年 1 月Central Bank of Kenya。第 7 章涉及 ICT 风险:董事会和高级管理层职责、ICT 风险管理框架、通过漏洞扫描器和渗透测试识别漏洞(7.3.4)、风险评估和缓解(7.4),以及信息安全计划(7.5)
- Prudential Guidelines,2013 年,包括外包指南 CBK/PG/16Central Bank of Kenya。CBK/PG/16 要求重大外包获得 CBK 批准,将提供移动金融服务渠道或技术列为重大活动的示例(4.1.4),并规定了尽职调查、监控和合同方面的期望。机构对已外包的活动仍负有责任(4.2)
- Guidance Note on Cybersecurity for the Banking Sector,2017 年 8 月Central Bank of Kenya,依据《Banking Act》第 33(4) 条发布,适用于该法下获得许可的所有机构。涵盖治理、至少每年一次的独立网络威胁测试、包括全面渗透测试的内部和外部审计、外包,以及 24 小时内的事件报告(第 3.1 至 3.4 节和第四部分)
- Guideline on Cybersecurity for Payment Service Providers,2019 年 7 月Central Bank of Kenya,依据 2011 年《National Payment System Act》第 31(2)(b) 条发布,适用于该法下获得授权的支付服务提供商。季度漏洞扫描、年度渗透测试和半年度漏洞评估(3.2.5)、提前 30 天通知外包(3.4.2),以及 90 天过渡期(4.0)
- Data Protection Act,2019 年肯尼亚共和国 2019 年第 24 号法律,由 Office of the Data Protection Commissioner 发布。数据保护设计和默认保护及其要求的措施(第 41 和 42 条)、72 小时内通知泄露(第 43 条),以及向肯尼亚境外传输个人数据的条件(第 48 至 50 条)
- Data Protection (General) Regulations,2021 年Office of the Data Protection Commissioner。数据保护设计和默认保护的要素,包括评估个人数据安全面临的风险、审计轨迹和事件监控,以及定期审查和测试软件以发现支撑处理的系统的漏洞(第 32 条)
- 新闻稿:Establishment of the Banking Sector Cyber Security Operations Centre (BS-SOC)Central Bank of Kenya,2025 年 9 月 22 日。CBK 表示已开始将 2017 年和 2019 年的网络安全指引与 2024 年关键信息基础设施相关条例对齐,各机构必须继续同时遵守两套要求,并须按该条例规定的时限向 BS-SOC 报告网络安全事件




