远程IT支持不失控：香港财富管理公司实例

一句话结论： 远程 IT 支持本身没有问题，问题在于事后没有人说得清那次连接发生过什么——对一家持牌的香港公司来说尤其如此。解法不是"更信任你的供应商"，而是让每一次远程连接都成为一个有记录的事件：连接前经过同意、连接中全程可见、连接后留下日志、并且可以随时撤销。

为什么远程 IT 支持会让香港的金融机构不安？

香港几乎每一家中小型金融机构都在依赖远程 IT 支持，只是很多公司从来没有用这个词称呼过它。行情终端的授权文件失效，交易录不进去；客户会议前一小时，分析师的笔记本电脑打不开共享盘。运营部的同事打给 IT 服务商，对方让他点一下"允许"，十分钟后一切恢复正常。这个循环每周都要发生几次，而且大多数时候确实有效。

在持牌机构里，让人不安的并不是这个循环本身，而是迟早会有人针对它提出的那个问题。精品资产管理公司、家族办公室、持有证监会牌照的顾问业务——在这类机构里，客户身份证明文件、组合持仓、申购赎回指令和银行账户信息，往往由很少的几个人经手。能访问一台工作站，就等于能访问上述全部内容。而在一家三十到六十人的公司里，敏感资料真正存放的位置常常就是这些工作站，而不是某个专门设计过的、加固过的系统。

于是迟早会有一个以提问为职责的人问出来：过去这段时间，究竟是谁在连接我们的电脑？连了多少次？做了什么？根据我们的经验，公司诚实的回答通常是某种版本的"我们的 IT 公司，在我们请他们连的时候"。这句话是真的，但它完全无法被验证——而"无法验证"正是在受监管环境里会出事的那一点。没有人在指控供应商做了什么。真正的问题是，这家公司没有任何办法证明什么都没有发生过；这和"确实什么都没发生"是两件不同的、而且难度差得很远的事。

自 2016 年在香港设立办公室以来，Brocent 一直为本地金融服务业客户提供托管 IT 服务，这个模式在各种规模的机构里都高度一致。公司规模越大，这个问题被提出得越早——但它总会被提出来。提问的通常是合规主管，有时是外部审计师，偶尔是一位准备配置资金、正在做运营尽职调查的机构投资者。

一张被拦下的工单：一个复合情境

下面是一个我们见过很多变体的情境。其中的细节属于示例性质——它是根据这种规模、这种类型的公司真实运作方式拼合出来的复合情境，而不是某一家具名客户。

一家香港财富管理公司，约四十五人，中环有办公室，另有一层小型后台。持牌经营，每年接受审核。这四十五人里有两位是运营团队，其中一位负责大家口中的"IT"——意思是，她是那个打电话给 IT 服务商的人。这家服务商能力不错，已经支持公司六年，对环境很熟。出问题时有人在群里发一句，工程师接手、连上、修好。从来没有出过糟糕的体验。

然后，公司的合规主管在准备年度内部控制检视时，把一张例行工单拦了下来。不是因为他怀疑什么，而是因为检视要求他描述公司对"第三方访问存有客户资料的系统"这件事的控制措施；当他坐下来准备写的时候，他发现自己写不出来。他说不出上一个季度发生过多少次远程连接。他说不出是哪几位工程师连过。他说不出那些连接里有没有哪一次触及过存放客户开户文件的机器。他向服务商索取日志，收到的是一封态度诚恳、也确实出于善意的邮件，大意是：你们叫我们连，我们才连。

那一刻，这家公司不再把远程支持当作一项便利设施，而开始把它当作一项控制措施。这个时刻确实很尴尬，因为供应商什么都没做错。公司并不是在找新的服务商，它是在找证据——而供应商用的工具从设计之初就不是用来产生证据的。

"反正一直都是让他们连进来"到底代价是什么

这些代价都不戏剧化。它们属于慢性的那一类，并且总在不方便的时刻浮出水面。

回溯性的问题没有答案。 "上个季度有没有外部人员访问过存放客户 KYC 文件的那台机器？"这个问题只有两种可以接受的回答：有记录的"没有"，或者有记录、有细节的"有"。"应该没有吧"不在其中。一旦一家公司意识到自己只能给出第三种回答，这个缺口通常会迅速上升到优先处理的位置——因为明年还会被问同样的问题，而到那时它就从新发现变成了重复发现。

这段关系建立在信任而非证据之上，而信任无法转移。 现在的这几位工程师，公司认识，也喜欢。但工程师会跳槽，服务商会招人。上周二连进来的那个人，可能是公司从未见过的人，而且没有任何机制会告诉他们究竟是不是。公司实际上依赖的，是供应商内部的招聘与督导——那对客户来说是不可见的，而且他们从来没有评估过。

年度检视没有任何东西可以指着说。 检视文件里的控制描述需要凭据：一份政策、一份日志、一份报告、一张设置截图。"我们用的是一家有信誉的 IT 服务商"是一句关于意图的陈述。检视者要的是可以附进档案里的东西。

员工开始悄悄回避。 这一点常常出乎意料。在我们服务过的几家公司里，问题的第一个信号并不是合规发现，而是行为上的变化：前台业务部门有人开始拒绝远程协助，宁愿等工程师上门，或者自己绕过问题——因为屏幕上开着客户持仓，他们对"有人在看"这件事感到不适。这种直觉完全合理，但它也很贵：它把一个十分钟能解决的问题变成半天的低效工作，同时意味着公司的 IT 问题不再被如实上报。

离场流程没有定义。 服务协议结束时，那些访问权限怎么办？在临时性的安排里，通常没有任何正式动作：从大家记得的那几台机器上把工具卸载掉，账号继续有效，没有人留下任何书面记录。公司往往是在更换服务商时才发现这一点——他们无法确认上一家已经没有任何路径进来了。

以上没有一项构成安全事件。它们全都是"记录的缺失"——而正是记录的缺失，把一项普通的运营做法变成了一条审核发现。

我们的看法：解法不是"更信任你的供应商"

当客户向我们提起这件事时，第一反应——是他们的，不是我们的——通常是去找一家更值得信任的服务商，或者干脆限制远程支持、要求工程师必须到场。两条路都走不通。只做现场支持既慢又贵，而且它同样不产生记录：一位坐在工位旁边的工程师，并不比一位从观塘连进来的工程师更有日志可查。而"更值得信任"本身不是一个能从外部验证的属性。

有用的重构是这一句：远程访问应该是一个事件，而不是一种状态。 在大多数小型机构里，供应商的访问权限现在是一种状态：它常驻在背景中，并且以不可见的方式被行使。应该取而代之的，是一连串离散的事件——每一个都在事前具名、在进行中可见、在事后被写下来，并且能够被关掉。

这是一个设计问题，不是信任问题，而且用对工具是可以解决的。真正重要的是四个属性。

让远程访问变得可问责的四个属性

经过同意 — 员工设备上的会话不应该悄无声息地开始。坐在键盘前的人应该看到是谁在请求连接、具名到人，并且由他来决定是否允许。
全程可见 — 会话进行期间，这件事应该是显而易见的。不是藏在某个设置面板里，而是就在屏幕上，持续整个会话。
留下日志 — 每一次连接都应该在开始的那一刻写下记录：谁连的、连的是哪台设备、什么时候、以什么模式、对应哪一张支持工单。这份日志应该可以由客户导出，而不只是供应商自己看得到。
可以撤销 — 客户应该能够只凭一句话就终止供应商的访问权限——针对单台设备或整批设备——并且得到"已执行"的确认。当合作关系结束时，离场流程应该自动触发并由人复核，而不是依赖谁还记得这件事。

这也是我们为什么要在"支持代理程序能做的两件事"之间划一条硬线。观察一台机器的安全健康状况，和在一台机器上执行操作，是两种风险特征完全不同的活动，它们不应该共用同一套权限模型。持续监控在构造上就应该是只读的——它只报告它看到的，无法执行任何东西。动手的工作则只能通过上面描述的那条"已同意、可见、有日志"的通道进行。把两者合并成一个随时什么都能做的代理程序，对供应商方便，对客户不利。

在屏幕上，"事前同意、全程可见、随时可撤销"具体长什么样

我们把这些属性做进了 BCS Beam——Brocent 托管 IT 客户所使用的端点客户端。之所以这么做，正是因为另一条路（一个权限面不可见的通用远程控制工具）在客户对话里一次又一次通不过这项检验。具体来说，在一台安装了它的设备上：

屏幕会话开始前，同意提示会具名到工程师。 在启用同意机制的设备上，除非坐在键盘前的人点了同意，否则屏幕会话不会开始，而且提示里会写明是谁在请求。这是最直接回应"会不会有人在看我"这个担忧的控制措施——因为答案变成了：你不点同意，就不会。

屏幕横幅在整个会话期间持续显示。 不是那种五秒钟就消失的通知，而是贯穿整个会话的常驻指示。

托盘图标实时显示会话状态。 Beam 的托盘助手会显示当前有几个远程会话在进行、以及连接的是哪个账号。这把"他们能访问我的电脑"从一个不可见的背景事实，变成了任何用户随时看一眼就能确认的状态，不需要问任何人。

每一次连接在开始的那一刻就被写入审计账本。 谁连的、连到哪台设备、什么时候、什么模式、对应哪一张工单。已经签发但从未被使用的邀请同样会被记录——这一点很重要，因为一个未被使用的邀请仍然是一次已经授出的访问权限。你的客户经理可以应要求把完整历史导出为表格。会话也可能出于质量与审计目的被录制，录像在归档前会先加密。

基础设施是 Brocent 自己的，就在香港。 远程支持服务器、审计平台和会话记录，全部运行在我们位于香港的服务器上。你的设备与我们的工程师之间，没有任何第三方远程控制云平台——这意味着只有一套数据处理政策、一条审计链，而不是一串各有各政策的供应商。

每一家客户的设备彼此隔离。 你的设备群位于独立环境中，拥有自己的注册身份，工程师的访问权限在服务器端强制执行。你要求撤销某一台设备、或者全部设备的访问权限，我们照做。协议结束时，离场流程自动触发，并由工程师确认执行。

安全审计那一半从不动任何东西。 它在设计上就是只读的。它读取设备事实——磁盘加密、防病毒与防火墙状态、系统更新状态、已安装软件的名称与版本——并对照 CIS 基准进行检查；每天将已安装软件与全球 CVE 目录比对，并使用 CVSS、EPSS 和 CISA KEV 清单，按真实世界的被利用风险排定优先级。它会标出未经授权的远程访问工具、文件共享客户端以及已停止支持的软件，并在管理层看得懂的报告里给出每台设备的风险评分。它无法在机器上执行任何东西，也从不采集文件内容、按键记录或屏幕画面。

还有一个细节值得单独点出来，因为它通常要到用得上的时候才会被想起：安装包本身。每一家客户的安装包都是单独构建、经过数字签名的，并且通过受管理的部署通道交付，而不是一条公开的下载链接。代理程序的流量一律通过 TLS 向外发起，因此不需要开放任何入站端口，也不需要向审查你网络配置的人解释任何防火墙例外。

对情境中的那家财富管理公司来说，这把合规主管面对的"一个无法回答的问题"变成了"一次文件调阅"。他要该季度的连接账本。他拿到一份表格，逐条列出每一次会话的工程师、设备、时间戳、模式和工单编号。那份表格就是他的检视所需要的凭据，而产生它只需要发一封邮件。

临时连接、通用远程工具、可审计支持通道：三者的差别

这三样东西经常被当成同一件事。它们不是——而且差别只有在有人要证据的时候才会显现出来。

三种模式的对比

临时性的供应商访问（"打个电话，他们就连进来"） — 建立起来最快，而且在解决问题这件事上确实有效。但它没有同意记录、没有会话日志、无法列举出谁拥有访问权限，也没有定义过的离场流程。公司的控制措施就是供应商的善意。在没有人要证据之前，这没有问题；一旦有人要，你拿不出任何东西。
通用远程支持工具（屏幕共享，消费级或中小企业级） — 好一些：会话通常要求用户报出一个代码，因此至少存在一个"同意的瞬间"。但审计轨迹（如果存在的话）位于供应商的账号里，设计上并不是为了交给客户的。访问权限通常是基于账号而非基于设备群划分的，因此"谁能连到我们的机器"不是客户能够独立回答的问题。会话数据往往会经过一个第三方云平台——这等于在你的数据处理链上多了一个从未出现在你的供应商名册里的参与方。
可审计的支持通道（BCS Beam 的设计目标） — 具名到工程师的同意提示、常驻的屏幕横幅、实时的托盘状态、会话开始即写入的账本记录、客户可导出的历史、按客户隔离的租户、按需撤销、自动触发并经人复核的离场流程，以及一个严格只读、无法执行操作的监控半边。建立起来更慢，因为它需要一次真正的导入流程。而它把证据变成了日常运作的副产品——这正是全部意义所在。

诚实地说，第三种模式的运营成本高于第一种。得有人去构建和运维审计平台、准备经过签名的按客户安装包、并安排人力做离场复核。如果你的公司确实不承担任何"须对第三方访问展示控制措施"的外部义务，那么第一种模式并非不理性。只是大多数香港持牌机构其实是有这项义务的，而他们往往在检视的时候才发现。

这件事在托管 IT 关系里的位置

可审计的远程访问不是一件可以单独买回来的产品，它是"你的 IT 如何被运营"的一项属性。它存在于一份托管 IT 服务之中，与那些让它真正有用的东西并列：有真实响应承诺的服务台、补丁管理、备份，以及只读审计半边所支撑的端点安全工作。单独来看，一本维护良好的连接账本只能告诉你"没出事"。与托管 IT 安全服务结合之后，它才成为一种你可以用一段话向检视者描述、并且附得上凭据的安全态势。

如果你正在评估这件事的规模与成本，我们各市场的服务方案以及每一档包含哪些内容，都列在定价页面上。BCS Beam 包含在 Brocent 的托管 IT 方案之内，而不是单独售卖——因为一份只有部分设备会产生记录的审计轨迹，算不上审计轨迹。

Brocent 自 2007 年起在亚洲运营，2016 年设立香港办公室，2021 年起将总部设于新加坡。金融服务业客户始终是这项工作的核心组成部分之一，这也是为什么"支持既要快、又要可问责"这个特定问题，是我们认真思考过的，而不是最近才发现的。

常见问题

IT 服务商远程连进我们的系统时，究竟能看到什么？

在屏幕会话期间，工程师看到的就是你看到的屏幕——这正是会话必须经过同意并且全程可见的原因。在会话之外，能看到什么完全取决于供应商的代理程序还被允许做什么。就 BCS Beam 而言，答案被刻意限定得很窄：监控那一半只读取设备事实（安全设置、已安装软件的名称与版本、更新状态），从不读取文件内容、按键记录或屏幕画面。如果一家供应商无法干脆利落地回答这个问题，那本身就是答案。

我们要怎么向审计师证明某次远程访问是恰当的？

用账本，不是用政策。政策陈述的是"应该发生什么"，账本呈现的是"实际发生了什么"。检视者通常想要的，是该期间内的会话清单：谁连的、连到哪台设备、什么时候、以及为什么——而"为什么"要能连回一张支持工单，让业务理由可以被追溯。如果你现有的安排产生不了这份清单，那就是需要补上的缺口，无论你用的是哪一家供应商。

远程支持和持续监控有什么区别？

远程支持是间歇性、交互式的：一个人在你同意之后连进来修好某件事，然后断开。持续监控是被动、恒常的：一个代理程序按计划报告设备的安全状态，不执行任何动作。把两者混为一谈很常见，但没有帮助，因为它们需要的控制措施不同。监控应当是只读的，也不需要同意提示，因为它什么都做不了；支持则会改变你的机器，所以每一次都应该要求同意。

如果需要，我们能立刻撤销供应商的访问权限吗？

你应该能，而且应该实测一次，而不是假设。在 BCS Beam 上，撤销访问权限——单台设备或整批设备——是向客户经理提出的一项请求，会被执行并回执确认，同时撤销新设备的注册能力。协议结束时，离场流程自动触发，并由工程师复核执行，而不是靠记忆。不妨问问任何一家候选供应商：撤销是怎么做的、需要多久？回答的质量本身就很有诊断价值。

这会取代我们现有的防病毒或 EDR 吗？

不会——而且对任何声称能取代的产品，你都应该保持怀疑。审计那一半所做的，是核实你的防护是否真的装了、开了、并且健康，盯住那些防护工具覆盖不到的漏洞，并把证据集中到一份报告里。它与你现有的安全体系共存，而不是取而代之。把它想成"告诉你控制措施是否在起作用的那个仪表"，而不是一项替代性的控制措施。

如果我们终止合约，我们的数据会怎样？

有两件独立的事必须发生，而且两件都应该事先定义清楚。一是访问权限终止：注册被撤销、工程师对你环境的访问权限被移除、代理程序像任何标准应用一样干净卸载。二是留存记录：会话日志和任何归档录像，按你服务协议中的留存条款处理。请在签约之前就把这两件事写下来，而不是等到离场之后。

我们是一家小公司，这种程度的控制对我们是不是过头了？

公司的规模并不会改变机器上那些资料的敏感程度。一家四十人的财富管理公司，可能把客户身份证明文件、银行账户信息和组合持仓放在寥寥几台笔记本电脑上——设备数量比银行少，但就单台设备而言并不更不敏感。随规模变化的是"能投入多少资源去管理它"，而这恰恰是一个论据：这项控制应该内建在服务里，而不是由公司自己拼装。如果你的远程支持本来就会产生一份可导出的账本，那么"变得可审计"的边际成本几乎是零。

如果你的公司现在回答不了"上个季度是谁连过我们的机器"，这是一个可以解决的问题，通常也只是一次简短的对话。联系我们，我们会为你梳理现有安排能证明什么、不能证明什么——无论你最终是否选择与我们合作。