SFC对虚拟资产交易平台运营者的网络安全要求分析
文件来源
本文档基于香港证券及期货事务监察委员会(SFC/证监会)于2023年6月发布的《适用于虚拟资产交易平台营运者的指引》(Guidelines for Virtual Asset Trading Platform Operators)第XII章”网络保安”及相关章节整理而成。
一、网络安全管治架构(第12.1-12.7段)
1.1 总体要求
- 平台(包括交易系统及保管基础设施)的设计须适当,所有支持平台运营的系统及程序须稳健且获妥善维护
- 须尽量减少及适当管理以下风险:盗窃、欺诈、专业失当、错误及遗漏、服务中断、运作或监控缺失
- 须设有稳健的管治安排,备有充足的人力、技术及财政资源
1.2 负责人员职责
至少有一名负责人员(Responsible Officer)负责平台的整体管理及监督,并设定网络保安管理框架。其责任包括:
- 审视及批准与平台设计、开发、应用、运作、改动及网络保安风险管理有关的政策及程序
- 审视及批准与平台和网络保安风险管理资源有关的预算及开支
- 安排定期进行技术稽查(至少每年一次)及独立的网络保安评估
- 审视平台相关的紧急情况、中断事故和网络保安事故引致的重大事件
- 审视内部和外部稽查及网络保安检视所识别出的重大发现,批准补救行动并监察至完成
- 监察及评估网络保安威胁及攻击,包括掌握网络威胁形势、新漏洞、缺陷和攻击媒介的最新知识,收集网络威胁情报,运用自动化工具定期进行漏洞扫描
- 审视及批准应变计划
- 审视及批准与第三方服务提供者相关的尽职审查及服务协议
1.3 关键人员管理
- 须识别关键人员(如平台创办人或首席开发员),并制定计划减低关键人员风险
- 关键人员须具备必要的专业资格、管理和技术经验
1.4 管治程序
- 须在交易、风险及合规部门共同提供意见下订有正式的管治程序
- 须设有清楚界定的汇报途径
- 须订有管理监控措施及监督管制措施
1.5 定期检视
须定期检视内部政策及程序,确保能配合不断变化的市况、网络威胁形势及监管发展,并从速纠正任何已识别的不足之处。
1.6 技术稽查
- 须安排具备合适资格的独立专业人士至少每年进行一次技术稽查
- 须以适当的技能、审慎和勤勉尽责的态度挑选独立专业人士
- 须考虑他们在检视虚拟资产相关技术方面的经验和往绩记录
1.7 第三方服务管理
- 须对第三方服务提供者作出适当的尽职审查、持续监察及适当安排
- 须与服务提供者订立正式的服务协议,定明服务条款及提供者的责任
- 服务协议须定期审视并适时修改
二、平台可靠性(第12.8-12.11段)
- 须就系统升级及维护订有书面标准运作程序(SOP)
- 平台及所有改动在应用前须经过测试,并定期检视
- 应用前至少须进行:高级管理层检视及签署确认测试结果、系统及数据完整备份、制订回退应变计划
- 须就所有改动备存清晰的审计线索
- 如计划中断平台进行升级和测试,须尽早通知客户
三、平台安全性(第12.12段)— 核心网络安全要求
3.1 访问控制与身份验证
| 要求 | 具体内容 |
|---|---|
| 授权访问 | 确保只有获授权人士在有需要情况下方可进入平台 |
| 职员数据访问 | 仅准许职员在有需要情况下取阅交易指示及已执行交易的买卖资料 |
| 访问记录 | 高级管理层须时刻知悉每名有权访问职员的身份、可取阅的资料、需要取阅的理由、变动及原因 |
| 用户认证 | 采纳适当的用户认证方法,精准识别使用者身份 |
| 定期审视 | 至少每年审视使用者有权接达的平台及数据库列表 |
| 权限撤销 | 及时撤销不必要的使用者接达权和特权(如离职员工) |
| 访问日志 | 备存充足的取阅纪录,并设有保护措施防止纪录被篡改或删除 |
| 防范措施 | 设有足够政策、系统和监控措施,防范和侦测未经授权的数据加插、更改或删除 |
3.2 客户帐户安全
- 双重认证(2FA):须对客户帐户登入实施双重认证(使用客户所知的、客户所有的、客户是谁中的任何两项)
- 密码安全:
- 密码须在安全环境下产生及发送
- 系统随机产生密码,透过不受人为干预的途径发送
- 如非系统随机产生,须实施额外保安措施(如强制首次登入更改密码)
- 密码策略:
- 最短密码长度
- 向长期未更改密码的客户发出定期提示
- 最低密码复杂程度(字母与数字混合),重用限制
- 避免使用已广为使用、预期之内或已遭破解的密码
- 针对无效登入尝试的适当监控措施
- 网页闲置超时设定
3.3 客户活动通知
帐户出现以下活动后须立即通知客户:
- 登入系统
- 重设密码
- 执行交易
- 更改客户和帐户相关资料
通知途径须与登入系统所使用者不同。
3.4 基础设施安全
| 要求 | 具体措施 |
|---|---|
| 网络隔离 | 透过妥善的网络隔离措施(设有多重防火墙的DMZ)保护关键系统及客户数据 |
| 内部网络访问 | 只容许有需要的人士接达内部网络,并实施保安监控措施 |
| 补丁管理 | 及时监察和评估安全修补程式,评估影响后尽快测试,测试完成后一个月内执行 |
| 防病毒/反恶意软件 | 及时执行和更新防毒及抗恶意软件解决方案及EDR(端点侦测与回应)技术 |
| 入侵防御/侦测 | 实施IPS、IDS及SIEM解决方案,即时侦测入侵或未经授权接达,并产生警示 |
| SOC | 建立保安运作中心(SOC)或同等职能,负责所有保安监察及事故侦测和处理 |
| 硬件/软件管控 | 防止未经授权安装硬件及软件,仅可使用获授权的储存媒体和装置 |
| 实体安全 | 保护关键平台组件(HSM、存储媒体、伺服器、网络装置)的实体安全,采纳职责划分或特权分隔 |
3.5 数据加密
须采用依照业界最佳作业手法及国际标准的最新数据加密及安全传输技术:
- 敏感资料(用户名、密码、交易数据)在内部网络与客户装置之间传递时加密
- 保护储存于平台的客户登入密码
- 保护在系统基础设施组件之间转移的关键数据
- 保护平台关键数据的备份副本
3.6 安全监控与防御
- 采用最新保安工具侦测、预防及阻止未经授权入侵、违反保安规定及网络攻击
- 实施有效监察及监督机制侦测未经授权接达客户帐户或平台帐户的情况
3.7 安全培训
- 至少每年为平台运营者职员提供网络保安培训
- 向客户提供定期的警示及教材
- 提高对网络保安重要性及严格遵循保安规定的意识
四、网络保安评估(第12.13段)
推出平台或作出改动前,须进行严格及独立的网络保安评估,范围至少涵盖:
- 用户应用程式保安:桌面/网络/流动应用程式
- 钱包保安
- 实地保安
- 网络及系统保安:包括穿透测试(渗透测试)、保管系统及相关系统的源代码审查、漏洞扫描
须备存足够文件,包括测试范围和方法以及评估结果。
五、网络保安事故处理(第12.14段)
须订立书面政策及程序,订明怀疑或确实的网络保安事故应以何种方式向内和向外上报:
- 内部上报
- 向客户通知
- 向证监会及其他监管机构报告(如适用)
六、平台容量管理(第12.15段)
- 定期监察平台容量使用情况,订有适当的容量规划
- 定期进行压力测试,确定不同模拟市况下的系统表现
- 确保容量足以处理可预见的增长
- 设有应变安排处理容量超限情况
七、系统及数据备份(第12.16段)
- 至少每天将业务纪录、客户及交易数据库、伺服器及证明文件在离线媒体进行备份
- 办公室以外地方的储存须设有妥善的保安措施
- 须实施适当措施确保备份副本完整及可供取阅
八、应变措施(第12.17-12.20段)
8.1 应变计划内容
- 可能出现的中断情景,包括网络攻击情境(如DDoS攻击、数据因网络攻击而完全损毁)
- 适当的后备设施
- 有经过培训的员工处理客户及监管当局查询
8.2 测试与更新
- 后备设施及应变计划至少每年进行一次可行性及充足性方面的检讨、更新及测试
8.3 事故响应
出现重大延误或故障时,须及时:
- 纠正有关情况
- 尽快通知客户有关情况及处理方案
九、稽查纪录与事故报告(附表3)
9.1 稽查纪录须包含
- 交易指示的发出/取消/修订/执行资料(加时间戳及独有参考编号)
- 系统登入纪录(使用者身份、登入日期和时间)
- 交易限额/持仓限额/现金限额的例外情况
- 合规验证异常情况
- 用户使用权等级分配
- 关键性系统指标及主档案的更改详情
- 输入错误交易指示
9.2 事故报告须包含
- 对问题的清楚解释,包括根本原因分析(RCA)
- 出现中断或延误的时间
- 中断或延误历时多久
- 受影响的平台或系统
- 问题以前曾否发生
- 受影响客户的数目及影响
- 糾正步骤
- 防止重演的步骤
9.3 纪录保存期限
- 稽查纪录及事故报告:不少于两年
- 平台或系统设计、开发、应用及运营文件:平台或系统停止运作后不少于两年
- 风险管理监控措施文件:平台或系统停止运作后不少于两年
十、持续汇报责任(第XVI章相关)
网络安全相关的通知义务:
- 对可能影响平台运作的硬件、软件及系统技术改动,须在实施前向证监会解释原因
- 应变及业务恢复计划的变更须通知证监会
- 重大服务中断或其他重大问题须通知证监会,包括原因分析、影响分析及恢复措施
- 交易、保管、会计、结算及交收系统在运作上出现重大缺失、错误或缺陷须通知证监会
- 以上事项须向证监会提交事故报告,不得有不当延误
十一、对网络安全工程师的实操建议
11.1 优先建立的安全能力
| 优先级 | 能力领域 | 建议行动 |
|---|---|---|
| P0 | 访问控制 | 建立完善的IAM系统,实施最小权限原则,建立定期访问审查流程 |
| P0 | 双重认证 | 确保客户端和内部系统全面实施2FA |
| P0 | 加密体系 | 部署TLS/mTLS、HSM管理密钥、数据库加密存储 |
| P0 | SOC/SIEM | 建立或接入安全运营中心,部署SIEM进行实时监控和告警 |
| P1 | 网络隔离 | 设计多层DMZ架构、微分段、零信任网络 |
| P1 | 入侵检测 | 部署IDS/IPS,配置规则并持续更新 |
| P1 | EDR | 在所有关键服务器和工作站部署EDR方案 |
| P1 | 漏洞管理 | 建立自动化漏洞扫描流程,补丁管理SLA(测试完成后一个月内执行) |
| P2 | 渗透测试 | 安排年度独立渗透测试和源代码审查 |
| P2 | 应急响应 | 制定IR计划,覆盖DDoS、数据泄露、系统入侵等场景 |
| P2 | 备份与恢复 | 每日离线备份、异地存储、定期恢复测试 |
| P3 | 安全培训 | 建立年度员工安全培训计划和客户安全教育 |
| P3 | 第三方管理 | 建立供应商安全评估和持续监控框架 |
11.2 合规落地建议
文档体系:建立完整的网络安全政策和程序文档,涵盖SFC指引提到的每一项要求。这些文档需要定期审视和更新。
治理结构:确保公司有指定的负责人员(RO)对网络安全负最终责任,并建立清晰的汇报线(从SOC到RO)。
技术稽查准备:SFC要求每年至少一次独立技术稽查。日常工作中就要保持合规状态,而不是稽查前突击整改。
事故响应流程:
- 建立清晰的事故分级标准
- 明确内部上报路径和时间要求
- 准备好向SFC通报的模板和流程
- 注意SFC要求”不得有不当延误”——建议设定24小时内初步通报的内部标准
审计线索:确保所有操作都有完整的审计日志,并且日志防篡改、保存不少于两年。这对网络安全工程师来说意味着:
- 日志集中收集和存储
- 日志完整性保护(如WORM存储)
- 日志保留策略符合监管要求
关注Web3特有风险:
- 钱包安全(冷/热钱包管理、多签)
- 智能合约安全
- 链上交易监控
- 私钥管理(HSM必须使用)
11.3 需要特别注意的合规红线
- 网络保安评估须由独立第三方在平台推出前完成
- 漏洞扫描须自动化定期执行(注意:这不等同于渗透测试)
- 安全补丁须在测试完成后一个月内执行
- 稽查纪录须保存不少于两年
- 应变计划须至少每年测试一次
- 任何重大系统改动须事先通知证监会
11.4 推荐的安全框架参考
SFC指引虽未指定具体框架,但从要求来看,建议参考:
- NIST Cybersecurity Framework:与SFC的治理、识别、保护、检测、响应、恢复要求高度吻合
- ISO 27001/27002:信息安全管理体系,适用于建立文档体系和内部审计
- CIS Controls:提供具体的技术控制基准
- OWASP:Web应用和智能合约安全开发参考
十二、总结
SFC对持牌虚拟资产交易平台的网络安全要求覆盖面广、标准高。作为网络安全工程师,核心工作可以概括为:
- 建设:搭建符合监管要求的安全技术栈(SOC、SIEM、IDS/IPS、EDR、加密、2FA等)
- 运营:持续的漏洞管理、补丁管理、访问审查、日志分析、威胁情报
- 响应:建立并演练事故响应流程,确保能快速检测、遏制、恢复并上报
- 合规:维护完整的安全文档、审计线索和事故报告,配合年度技术稽查和网络保安评估
- 汇报:按SFC要求及时通报重大事件和系统变更
关键心态:SFC采取的是持续监管模式,不是一次性检查通过就结束。所有安全措施都需要是”活的”——持续运行、持续改进、持续记录。