MT5 服务器安全需要回答几个具体问题：谁能进入生产环境，谁能修改交易配置，哪些外部系统持有连接凭据，以及发现异常后由谁切断访问。对 Forex/CFD 经纪商而言，这些问题涉及技术、交易、运营团队，也涉及托管商及软件供应商。
GMO Internet 在 2026 年 10 月 24 日的公告中确认，其 Onamae.com Desktop Cloud 服务环境遭到未经授权访问，客户信息被转移至外部，并收到部分客户关于不明交易的报告。该服务提供托管的 Windows 桌面环境，交易者可在其中运行 MT4、MT5 等交易工具。上述公告不能据此证明 MT5 核心 Trade Server 遭到入侵。
排查安全问题，首先要弄清受影响的对象。客户交易终端、Manager 账号和服务器管理入口，所能触及的权限及需要采取的措施都不相同。
先查清 MT5 环境中有哪些访问入口
从实际部署出发，列出 Trade Server、Access Server、Administrator 管理入口、Manager 与 Dealer 权限、托管控制台、RDP 远程连接，以及 CRM、Bridge、Gateway 和 LP 接口。每项访问都应明确用途、负责人和撤销方式。
| 访问入口 | 主要风险 | 应检查的控制措施 |
|---|---|---|
| 平台管理账号 | 交易配置遭到未授权修改 | 个人独立账号、权限限制、变更审批 |
| 托管控制台及 RDP | 服务器或基础设施被控制 | 访问路径限制、适用的 MFA、登录日志 |
| 客户交易 VPS | 已保存的交易凭据泄露 | 终端防护、可信软件、独立凭据 |
| CRM 与 Manager API | 接口权限过大或凭据外泄 | 独立服务账号、权限范围、凭据存储 |
| LP 与 FIX 连接 | 连接凭据被滥用 | 认可的连接端点、负责人、会话监控 |
| 外部技术支持 | 项目结束后仍保留高权限 | 临时授权、操作记录、及时撤销 |
这张表用于确定检查范围。具体能否设置 MFA、限制来源 IP 或撤销会话，应以相关组件、版本和供应商提供的能力为准。
管理员、Manager 和 Dealer 权限如何划分？
先按工作职责确定权限，再分配账号。技术人员维护服务器，交易人员处理获授权的交易事务，客服查询客户信息，各自需要的权限并不相同。只负责报表的账号，不应同时拥有修改交易条件或账户余额的权限。
不要仅凭账号名称判断权限，应检查它实际能查看哪些账户、执行哪些操作。每位员工使用可追溯的独立账号；涉及 Group、Symbol、路由及财务记录的重要变更，应有审批和操作记录，适用时保留修改前配置。
员工离职、转岗或供应商项目结束时，应同步撤销不再需要的访问。临时提权必须指定负责人和结束时间。可把这些工作纳入既有的 MT5 日常维护检查，避免只在出现事故后清理账号。
交易 VPS 与经纪商服务器需要分别保护
例如，一位客户在第三方 Windows VPS 上长期运行 MT5 和 EA。如果 VPS 被入侵，保存在交易软件或相关文件中的登录信息可能受到威胁。但这个情况本身，并不能证明经纪商的 Trade Server 被攻破。不同 EA 托管产品的访问方式也有差异，应分别检查。
对于经纪商生产环境，不应让管理用 RDP 入口向整个互联网无限制开放。应通过受控网关或 VPN 接入，限制允许连接的人员及来源网络，并检查远程登录记录。网关、VPN 和管理员使用的设备，同样需要更新和维护。
CISA 等机构发布的远程访问安全指南介绍了远程工具及权限管理措施。MFA 应部署在支持它的认证环节；例如，Microsoft 提供了远程桌面服务的 MFA 配置规划说明。这不代表所有 MT5 账号或接口都有同样的功能。
CRM、LP、Bridge 和 API 凭据如何保护？
接口使用的可能是账号密码、令牌、证书或其他认证资料，不能全部当成同一种“API Key”处理。应记录每项凭据由谁负责、连接哪个系统、被哪些程序使用。自动化服务应使用独立服务账号，避免直接借用员工的高权限账号。
按 OWASP 凭据管理指南中的相关原则，将凭据存放在有访问控制的管理系统中，避免写入源代码、共享文档或支持工单。根据实际支持能力，限制账号权限及连接端点。
更换凭据前，需要找全依赖它的程序，并与相关供应商确认更新步骤。替换后验证连接，再停用旧凭据。若已怀疑泄露，应优先控制风险，不能等到下一个例行维护日。IP 白名单只是额外限制，不能代替身份认证。
隔离生产环境，限制供应商访问
生产与测试环境应分别管理，包括账号凭据和管理路径。防火墙只放行必要的组件及业务连接，避免测试服务器能够随意访问生产管理接口。
供应商需要维护时，应写明连接人员、工作范围、可修改项目和访问期限。工作结束后检查变更结果并关闭临时权限。生产凭据不应复用在普通办公电脑或客户交易 VPS 上。这些安排应在规划 MT5 服务器托管时确定，而不是等上线后再补。
怎样发现异常登录、越权修改和可疑交易？
把能够取得的操作系统、远程访问、平台管理及接口日志放在同一时间范围内核对，记录时区和系统时钟差异。重点调查意外的高权限登录、新增账号、未知远程工具，以及无法对应审批记录的权限、Group 或 Symbol 修改。条件允许时，将日志保存在受影响主机之外。
遇到连接或执行异常，可结合 MT5 服务器故障排查定位原因。但异常成交是否属于未授权交易，需要交易及风控团队参与判断，不能仅凭技术报错或某笔交易亏损下结论。
怀疑凭据泄露后，先控制风险并保留证据
应指定一名事件负责人，协调技术处置和业务决策。以下工作可以并行开展，不必机械地等待上一步全部结束。
- 确认影响范围。 列出相关账号、服务器、可能泄露的时间段及连接系统，区分已确认事实与待核实情况。
- 限制访问，同时保留证据。 尽快控制可疑连接，保存日志及相关系统证据。不能为追求完整取证而延误紧急隔离，也不要习惯性地重启服务器或清空日志。
- 从可信设备更换凭据。 按调查范围处理交易账号及有关服务凭据，不要在疑似受侵环境中输入新密码。
- 核查现有连接。 使用系统支持的方式终止或撤销相关会话，并向负责的供应商确认处理结果。
- 升级处理并验证恢复。 按实际情况联系托管商、软件供应商、交易、风控及合规负责人，排查持续访问手段后再恢复受影响服务。
GMO 在 10 月 23 日的公告中特别提醒：视经纪商服务器的具体行为而定，修改密码后，原有连接仍可能暂时保持。因此，更换密码与处理现有会话必须分别核查，不能假定其中一个动作已经完成另一个动作的效果。
恢复登录后，还要核对交易和账户记录
平台重新在线，只能证明部分功能恢复。应按受影响时段检查订单（Orders）、成交（Deals）、持仓（Positions），以及余额和信用额操作。MetaQuotes 官方说明对订单、成交和持仓作了区分，核对时不应将它们混为一类记录。
将账户标识、时间、数量、价格与能够取得的 Bridge、LP 执行记录进行比较。并非每笔客户交易都有一笔对应的外部对冲，应根据经纪商实际执行模式对账。
发现差异时，先保存原始记录并说明差异，再按授权流程处理。涉及交易的决定由交易及风控团队确认。服务器恢复和切换方案，可继续参考 MT5 灾难恢复文章。
经纪商与供应商的安全责任如何划分？
责任应按合同和实际系统控制权确定，不能只写一句“由技术公司负责”。
| 参与方 | 需要写明的职责 |
|---|---|
| 经纪商 | 访问审批、交易决策、客户沟通及适用的报告义务 |
| 托管或维护服务商 | 约定范围内的基础设施控制、维护、日志及技术响应 |
| MetaQuotes | 通过适用支持安排提供平台产品支持及厂商控制的修复 |
| CRM 或 Bridge 供应商 | 其软件、接口行为、凭据控制及可提供的日志 |
| LP | 其连接访问、会话处理及外部执行记录 |
尤其要确认：谁能停用凭据，谁能调取日志，谁能批准限制服务，以及非工作时间如何升级处理。服务器运行监控，不等于已经覆盖所有连接系统的安全调查。
经纪商 MT5 服务器安全检查清单
以下为实操检查表，可用于定期权限复核及重要变更后的检查。每个未完成项目都应记录负责人和跟进日期。
| 检查项目 | 应保留的检查依据 |
|---|---|
| 清理不必要的共享及闲置高权限账号 | 账号与负责人清单 |
| 权限符合技术、交易、客服的实际职责 | 已审批的权限复核记录 |
| 远程入口受限，适用的 MFA 已启用 | 网关及访问配置记录 |
| 接口凭据有存储、轮换及撤销安排 | 不含密钥明文的凭据目录 |
| 供应商访问经过批准且有结束时间 | 访问与变更记录 |
| 生产和测试环境适当隔离 | 已复核的网络规则 |
| 异常登录及敏感配置修改可追溯 | 日志覆盖及告警检查记录 |
| 更新兼容性与备份恢复经过检查 | 更新评估及恢复验证记录 |
| 事故联系人和会话处理方式明确 | 事件响应流程 |
| 能够调查交易及账户记录差异 | 对账流程 |
这份检查表不能替代完整安全审计、渗透测试或监管合规认证。
EBS FinTech 如何协助管理 MT5 环境安全？
EBS FinTech 可在约定范围内，协助经纪商进行服务器访问配置、基础设施监控、平台维护及技术排查，并就连接系统的问题与相关供应商协调。
如需检查现有服务器和访问权限，可通过 MT5 技术维护服务明确需要覆盖的系统、支持时段及各方职责。专项安全测试或 SOC 服务应另行确认安排，不能默认包含在日常维护中。
