香港支付公司的HKMA渗透测试要求

摘要： 一家持牌香港支付公司收到一次常规监管审查请求，其中一项要求是提供渗透测试的证据——公司精简的IT团队这才意识到，"证据"不只是两年前某次扫描留下的一份PDF。这是一个复合的示例情境，并非指代某一家真实客户。本文讨论测试从一次性事件变成持续节奏之后会发生什么变化，以及IT合作伙伴的运营角色止步于何处、企业自身的合规与法律判断从何处开始。

持牌机构，以及一个不会在发牌后就消失的监管者

香港拥有为数不少的持牌支付与货币服务企业——储值支付工具（SVF）营运商、货币服务营运商，以及以资金转移或支付处理为核心业务的公司。拿到牌照是一个里程碑，但牌照之后发生的事情，从外部往往不那么容易看见：香港金融管理局及其管理的相关框架，对持牌机构如何管理技术风险持续保持关注——这不是发牌时勾选一次就结束的事项，而是一段持续的监管关系。

这种关注对不同机构呈现出不同形式——定期申报、临时的资料索取、现场或非现场审查，以及由行业内其他地方发生的事件所触发的问询。就HKMA与技术风险相关指引通常被公开描述的方式而言，业界普遍理解持牌机构被期望能够证明自己理解并主动管理自身的技术风险，包括其应用系统与基础设施可能存在可被利用弱点的风险。某一次具体审查究竟会索取什么、按什么节奏、依据什么具体标准，这是HKMA与机构自身合规职能之间的判断，而不是技术服务商能够代为预测或承诺的事情。以下内容描述这类问题在实践中常见的样貌，以及Brocent对其中运营层面工作的自身理解，这些理解都根植于Brocent在香港金融服务行业的实际工作经验。

持有这类牌照的公司往往比在HKMA相关监管话题中更常被提及的银行和保险公司要小得多。一家员工不足百人的支付或货币服务营运商，很少配备银行那种规模的专职合规部门，甚至常常根本没有专职的安全岗位——负责回答监管审查中技术问题的人，往往同时也是管理服务台工单和云主机账单的那个人。这不是对这类企业运营方式的批评，而是精简型支付企业面对的真实运营现实——也正是在这种现实下，临时性的测试做法最容易生根，因为没有人有余力在其他一切事务之外再去持续拥有一套标准化的测试项目。

为什么这类客群与银行、保险公司不同

公开讨论较多的香港金融IT话题，往往集中在对冲基金、家族办公室和保险经纪这类合规人手较为充足、测试项目（若已存在）通常也相对成熟的细分领域。持牌支付或货币服务企业是一个明显不同的客群：通常规模更精简、业务历史更短，而且往往是在平台已经明显超出最初设计范围之后，才第一次面对针对自身技术态势的正式监管审查。本文所描述的差距，对这一细分领域而言并非一种假设性的边缘情形，而更接近默认的起点——这正是为什么运营层面的补救措施在这里比一句笼统的"多做测试"建议更有实际意义。

一次审查请求，对不上公司手头的证据

设想一家员工约50至90人的香港持牌支付公司。它稳步成长——新增的商户对接、持续增长的交易量、多年来陆续叠加在原有平台上的几条新产品线。它的IT职能规模不大：几个人维持平台运行、开发功能、处理日常支持。安全测试并非从未发生过，只是发生的方式和许多同等规模的公司一样——被动响应式的。某家意向合作的银行在开立结算账户前要求提供一份渗透测试报告，于是公司委托做了一次。一年后，某个大商户自己的供应商安全问卷问了同样的问题，公司又跑了一次扫描。没有人负责一套持续性的测试项目；测试始终是对"最近是谁在问"的回应，而不是任何人日历上的固定事项。

随后，一次常规的监管审查到来——是一次周期性的检查，并非由某个事件触发，是持牌机构理应预期时不时会面对的那种审查。其中一个问题公司此前非正式地回答过，但从未真正好好地整理成文档：你们的渗透测试项目是什么，能否提供相关证据。公司翻出手头能找到的材料：大约两年前做的一次测试留下的PDF，那次测试是为了配合银行开户流程而委托的，并非出于自身风险管理的主动安排。此后再无任何记录。对于当时具体测试了什么，也说不清楚——是面向公众的支付API、商户门户，还是内部网络，抑或三者都有？当时决定测试范围的人，如今已经没人还在公司里。

正是在这一刻，差距变得显而易见。这不是因为公司管理松懈——平台整体运行得还算稳健，原来那次测试也不是伪造或敷衍的——而是因为测试从未被当作一套项目来搭建，它只是对最近谁在追问而做出的一系列一次性回应。

"我们做过一次扫描"实际上暴露了什么

一旦公司真的要向审查方拿出自己的测试历史，而不只是口头断言"我们做过测试"，通常会浮现三个问题：

没有带日期的证据链条。 两年前的一份单一报告，只能回答"你们是否测试过"，回答不了"你们目前是否维持着经过测试、状态更新的安全态势"。审查方看到一套明显已发生变化的技术栈——新的对接、新的产品线，也许还有新的基础设施——却无从判断这些变化是否曾被测试过。
测试范围不清晰。 即便报告确实存在，公司也未必能确切说清它覆盖了什么。是只测了外部网络，还是也包括了Web应用层？上次测试之后新增的API端点有没有被纳入？一份没有清楚保留范围说明的报告，很难被当作对任何具体事项的现行证据来使用。
在截止日期前仓促补测。 一旦差距暴露，本能反应是立刻预约一次测试——但合格的测试团队往往需要提前数周预约，而在截止日期压力下仓促安排的测试，其起点其实比按计划安排的测试更糟。仅仅为了回答某一次审查而委托的测试，而不是作为持续项目的第一个周期，往往会重复公司本想摆脱的那种一次性模式。

这三个问题其实都与任何单次测试本身的质量无关，而是关乎围绕单次测试的项目结构是否存在——正是这套项目结构，才能把"我们做过一次测试"变成"我们持续维持一个经过测试、状态更新的环境，并且能准确展示给你看"。

Brocent的角色从哪里开始、又止步于何处

在这类情境中，清楚说明一家IT与安全合作伙伴能做什么、不能做什么，是很有必要的——因为正是在这种情况下，如果服务商夸大自己的角色，对持牌机构没有任何好处。

Brocent在这类情境中扮演的角色是运营性的，而非监管性的。具体而言：通过针对公司实际环境定制范围的渗透测试项目来执行实际测试——使用持证测试人员，并提供带有概念验证证据、按CVSS评分的发现结果——按公司自行设定并坚持执行的节奏进行；维护文档记录和带日期的报告，使其随时间积累成一条证据链条；帮助公司的合规团队以清晰的运营语言理解测试了什么、何时测试的、发现了什么以及如何修复的。Brocent不做、也不应该被期待去做的事情是：告诉持牌机构其监管方会认为什么才算充分，认定某一套测试节奏满足了HKMA的某项具体要求，或者替代公司自身的合规与法律顾问去解读某次审查究竟要求什么。这些判断属于公司自身的合规职能，以及在适当情况下的外部法律顾问——而不属于任何技术服务商，无论其经验多么丰富。任何声称能替代这些判断的合作伙伴，都是在承诺自己实际上无法兑现的东西。

这种分工值得直白地再说一遍，因为对于一支被拉得很紧的五人IT团队来说，很容易希望事情比实际更简单：任何服务商，无论资质多高，都无法给持牌机构一张写着"合规"的证书。Brocent能够给到公司的，是一份证据——带日期、有范围、已修复、保持更新——公司自身的合规职能可以据此向自己的监管方阐述立场。证据是Brocent的工作。这份证据对某次审查而言是否足够，这个判断是公司自己的工作，需要通过其合规与法律顾问来行使。把这两件事混为一谈，正是公司容易出问题的地方——要么是因为服务商暗示"合规的事我们已经搞定"而投入不足，要么是过度依赖某一次早已过时的测试结果。

持续测试节奏在实践中的样子

从临时性测试到持续性项目，两种状态之间的实际差别，归结起来是几个具体习惯，而不是理念上的转变：

固定循环的节奏，而不是一次性预约。 不再只是有外部方问起才委托测试，而是按公司自己选定并能够说明理由的固定周期运行——常见做法是至少每年一次，对于直接处理支付数据的系统，有时会更频繁。Brocent自己的渗透测试项目正是按这种节奏设计的，年度测试套餐中包含修复后的复测，而不是一份单一时间点的报告。
保留带日期的报告，形成持续更新的证据链条，而不是需要时才临时找出的单一文件。每个周期的报告、范围说明和修复记录不断累积，形成一段历史，合规负责人可以直接交给审查方，而不必在时间压力下临时重新拼凑。
每个周期都重新审视测试范围，而不是默认范围一成不变。 如果公司自上次测试以来新增了面向商户的API、将部分基础设施迁移到新的云环境，或推出了新产品线，实际上就等于新增了未经测试的攻击面。在每个周期开始时重新审视范围——而不是默认沿用上一次的测试计划——正是让证据链条真正贴合当前环境（包括云端托管的部分）的关键。
清楚区分扫描与测试，各自按其适当的节奏独立运行，而不是混为一谈。漏洞扫描是自动化的、覆盖面广的，适合更频繁的节奏；渗透测试是人工的、更深入的，适合频率较低但更彻底的节奏。如果一家公司只做其中一项，无论缺的是哪一项，都是一个实实在在的缺口。

这一切并不需要多么特殊的工具，也不需要庞大的内部安全团队。它需要的是把测试关系构建成一套有明确责任人的持续项目，而不是每次外部有人提问才发生的一笔交易。

香港支付公司应对渗透测试的三种方式

没有正式项目。 只有当客户、银行合作方或商户直接索要证据时才做测试。没有固定周期，测试范围也不一致——正如上文情境所示，一旦审查方问出一个公司此前从未以书面形式回答过的问题，风险敞口就会立刻暴露。
归档保留的一次性测试。 比什么都没有要好：至少存在一份带日期的报告。但面对一个持续变化的平台，单次测试很快就会过时，它回答的是"是否测试过一次"，而不是"目前是否在测试目前实际运行的系统"。
具备持续证据链条的固定测试节奏（Brocent模式）。 测试按照公司自己拥有并能够说明的周期运行，每个周期都对照当前环境重新审视范围，报告与修复记录不断积累成一段站得住脚的历史，公司的合规团队可以随时拿出这段历史——而关于什么才算"充分"的监管判断，则始终留在它本应归属的地方：公司自身及其顾问手中。

常见问题

漏洞扫描能满足渗透测试方面的要求吗？

通常不能单独满足——这是两种不同的活动。漏洞扫描使用自动化工具，在较大的覆盖面内识别已知弱点；渗透测试则由持证测试人员主动尝试利用这些弱点、将它们串联起来，并展示真实世界中的影响。如果审查方明确询问的是渗透测试，通常不太可能接受一份扫描报告作为等同的证据，不过这两者是互补的，成熟的项目通常会按各自适当的节奏同时开展两者。某个具体监管方或某次具体审查是否接受以其中一种替代另一种，这属于公司自身合规判断的范畴，而不是服务商应代为断言的事情。

持牌机构应该多久测试一次？

没有一个适用于所有公司的统一数字，Brocent也不会将某个具体频率断言为监管要求。实践中，处理支付数据的公司常见的做法是至少每年一个周期，若发生重大变化——新的面向外部的系统、重大的基础设施迁移、涉及客户资金的新产品线——则会触发额外测试。对某家具体公司而言合适的节奏，是一个需要公司自身合规与风险职能参与、并基于其实际风险状况来判断的决定。

一份测试证据链条应当包含什么？

至少应包括：每个测试周期对应的带日期报告、清楚说明具体测试了什么（系统、环境、测试类型）的范围说明、附带严重程度评级的发现结果，以及显示修复了什么、何时修复的修复记录——理想情况下还应有确认修复到位的复测。目标是让合规负责人能够向审查方呈现一幅清晰、按时间顺序排列的图景，而不必从散落的文件中临时拼凑历史。

谁来判断我们的测试项目是否充分？

由公司自身，连同其自身的合规职能，以及在需要时的外部法律或合规顾问来判断——并以适用于其牌照与业务的具体监管期望为依据。IT或安全服务商，包括Brocent在内，可以描述自身测试项目做了什么，并提供公司所需的证据，但不能、也不应该告诉公司某套项目满足了某项具体的监管标准。这个判断属于公司自身，并且这与执行测试本身的运营工作，本质上是两种不同性质的判断。

同一家服务商能否同时负责扫描和测试？

可以——这是相当常见的做法，因为同一家服务商对同一环境在两项活动中都有可见性，往往能够维持更一致的文档记录。但这并非必须；有些公司会刻意为测试和更广泛的托管IT关系分别选用不同的服务商。对证据链条而言，真正重要的是无论由哪家服务商执行测试，都按照一致的节奏进行，并留存带日期的记录——而不是具体采用哪一种服务商组合方式。

如果审查发现此前没有测试记录，会发生什么？

这属于公司与其监管方之间的事情，Brocent不会对具体的监管后果进行推测。IT合作伙伴能够掌控的，是帮助公司从那一刻起迅速而有说服力地做出回应——及时确定范围并开展测试，更重要的是，从此建立起持续性的项目，避免同样的差距在下一次审查中再次出现。公司对某项发现的应对方式，以及这种应对如何被看待，通常在很大程度上取决于事后发生的改变，而不仅仅是最初的那个差距本身。

云端托管的基础设施会改变需要测试的内容吗？

它改变的是需要纳入范围的内容，而不是是否需要测试这件事本身。一个部分或全部运行在云端的支付平台，依然存在攻击面——API、Web应用层、身份与访问配置，以及根据云服务商的责任共担模式，公司自身直接负有测试责任的某些基础设施层面。前文所述的"每个周期重新审视范围"，正是为了捕捉这类变化——自上次测试以来的一次云迁移，恰恰是应当触发重新审视测试范围的那类变化。

把测试节奏纳入托管IT方案，而不是一次次单独预约

这个情境中的公司，其实并不是孤立地存在一个"测试问题"——它存在的是一个"项目问题"，而测试只是恰好最先让它显现出来的地方。只要仔细看，同样的差距往往也会出现在其他地方：补丁节奏、备份验证、访问权限审查——所有这些持续性的运营纪律，对一支同时还要交付产品的五人IT团队来说，做一次容易，持续做则很难。

这正是为什么Brocent把持续的测试节奏定位为托管IT方案本身的一部分，而不是每次审查方提问时才单独商定的一次次预约。该页面上的按用户计费托管IT方案，正是围绕这种持续性运营纪律构建的——安全测试、补丁管理、监控与文档记录按固定节奏运行，作为这段合作关系中一项常态化的内容，而不是每次需要时才在截止日期压力下从零拼凑。对一家持牌支付公司而言，这种持续性才是真正的产品：不是某一次通过的测试，而是无论下一次何时被问起"给我们看看你们的测试项目"，都能给出一份站得住脚、状态更新的答案。渗透测试——以及对于环境需要更深入测试层级的公司而言，更高阶的Red Team高级渗透测试选项——都作为该方案内的附加项存在，而不是终点本身；真正让节奏在各次测试之间持续运转的，是这套方案。

如果贵公司正面对一次审查请求，而对自己现有的测试历史并不满意，务实的下一步是先展开一次对话，而不是仓促预约一次测试。欢迎查看托管IT方案的定价，或与我们联系，一起探讨适合贵公司具体环境的持续测试节奏应该是什么样子——以及在监管这一侧，Brocent的运营角色如何与贵公司自身的合规与法律判断相互配合。