——面向策略开发、上线、运维、更新全流程的数据安全工程体系（适配中小量化私募）

第一章问题的本质：量化公司在防什么

1.1 资产画像决定架构

安全架构的第一性原则：威胁模型决定防御架构，而不是最佳实践决定防御架构。照搬互联网公司的安全体系，对量化公司而言是投入错配。

量化公司的核心资产画像：

与一般软件公司的四点本质差异，直接决定本方案的架构取向：

• 价值密度极高、载体极小：攻击者不需要拖走数据库，一次 git clone、一封邮件附件、一张手机屏幕照片即可完成不可逆的资产转移。防御重心不在"守住服务器"，而在"守住数据从内网到外界的每一条通道"；
• 内部人即主要威胁：有合法访问权的研究员、开发、运维人员，其恶意行为（私卖、离职带走）发生的概率与外部定向攻击同量级，但检测难度大得多——传统的"边界防御+账号权限"模型对此近乎无效；
• 生产环境直连资金：策略运维的误操作不是"服务宕机"而是"资金损失"，安全平台必须与交易风控体系在上线环节握手，而不是各管一段；
• 合规刚性约束：投资决策与交易记录自基金清算终止之日起留存不少于 10 年（《私募投资基金监督管理暂行办法》），个人信息受《个保法》保护，等保0 为基线要求——合规不是可选项，而是生存前提。

1.2 威胁建模

按攻击者能力与路径建立威胁模型，作为后续每一项设计的依据：

防护边界声明：本方案对 T1/T2/T4/T5/T6/T7/T10 提供工程化防御，对 T3 显著提高攻击成本（不承诺完全防御国家级力量），对 T8/T9 通过架构与流程设计将暴露面收敛到可审计的最小集合。

1.3 防泄露的"通道物理学"

一个关键的分析框架——数据离开公司边界的物理通道是有限的、可枚举的。安全平台的本质就是把这张表逐项关闭或监控：

每一条通道都必须有对应的控制项，缺一条就是整个体系的漏洞——这是本方案"全面性"的检验标准，第四章起的每一项设计都能回溯到这张表。

第二章总体架构设计

2.1 设计哲学：三个降维

• 降维一：把信任问题降维成工程问题。"该不该信任某个员工"是无解的管理问题；"任何单人可组合的破坏能力是否有上界"是可解的工程问题。本方案不依赖对人的信任，而是通过架构设计保证：单一角色无法集齐"完整策略逻辑+关键参数+生产执行通道"三要素（详见§1最小知识架构）。
• 降维二：把人的自觉降维成系统强制。所有安全要求尽量在系统层强制（网络ACL、流水线门禁、自动备份），把"遵守制度"从员工的义务变成系统的默认行为。人的自觉只用于系统无法覆盖的例外场景，且每个例外都留痕。
• 降维三：把事后追责降维成事前阻断+事中检测。对无权者的越界，事前阻断（网络层、权限层）；对有权者的异常行为，事中检测（行为审计+实时告警）+事后威慑（水印溯源、蜜罐取证）。两类威胁需要完全不同的技术手段——这是多数安全方案混淆而导致失效的根因。

2.2 安全域划分与网络架构

网络是所有上层控制的物理载体。将整体环境划分为七个安全域，域间以防火墙白名单策略互联，默认拒绝：

• 管理端口收口铁律：全部服务器 SSH/RDP/数据库管理端口/vCenter 端口的源 IP 仅允许堡垒机。没有网络层收口的堡垒机只是录像机，收口之后它才是控制点。防火墙 deny 日志本身作为"绕行尝试"的检测数据源接入告警；
• 办公终端→研发协作域：仅开放 HTTPS 业务端口，管理端口不可达；
• 任意域→策略生产域：默认拒绝，仅接受 CI/CD 部署通道与堡垒机管理连接；
• 备份域单向：仅接受备份代理推送，禁止任何域主动访问备份域——备份数据若可被业务域访问，等于给攻击者留了"偷一份全部"的快捷方式；
• 出口统一：全公司互联网出口收敛，办公终端上网经出口代理（可审计可过滤），堡垒机与云管理走 SD-WAN 固定 IP（供券商与云厂商白名单使用）；
• IP与域名锚定：服务器全部静态 IP（或 MAC 绑定 DHCP 保留），内部 DNS 统一解析，每台服务器"IP-域名-资产-责任人-安全域"五元组登记于资产台账——IP 确定性是防火墙策略、审计日志、白名单三者的共同前提；
• 云侧镜像：云上生产环境（如有）安全组策略与本地防火墙矩阵保持同一语义，云账号根凭证密封管理，日常使用 IAM 角色+MFA。

2.3 数据分级体系

全部数据资产分为四级，分级决定后续所有管控强度：

分级的工程意义：S1 是本方案一切强化措施的锚点——终端 DLP 的识别规则围绕 S1 内容指纹构建、GitLab 审计告警围绕 S1 仓库配置、水印与蜜罐只部署在 S1 范围。分级不清则全面设防，全面设防则处处薄弱。

个人信息独立分级（PIPL/数安法合规要求）：量化公司持有的员工简历、客户开户信息、交易对手联络方式等个人信息，按 P1-P3 独立分级保护：P1 敏感个人信息（身份证号、银行卡号）加密存储+访问授权+删除权响应；P2 一般个人信息（姓名、电话）常规授权管理；P3 公开信息（公司官网信息）常规管理。

2.4 权限的三维定级

一次操作的实际管控级别 = max(操作风险等级, 目标环境等级, 涉及资产等级)，三维各自独立定级：

• 操作维度：一级（核心数据直接增删改）→ 四级（提示级）；
• 环境维度：特级（机房物理设备）→ 四级（个人测试机）；
• 资产维度：S1 → S4。

三维取最大值的意义：在中风险环境读取 S1 资产的操作，将按 S1 的要求执行一级管控（审批+告警+留档），而不是按环境的中风险放行——资产敏感性必须独立于其所在环境被评估。

第三章身份与信任基石

3.1 统一身份认证中心（Keycloak）

选型论证：自建身份中心必须满足 OIDC 标准、支持 SSO/MFA/RBAC 映射、开源可自主掌控。Keycloak 是当前最成熟的开源选项之一（替代品如 Authentik、Ory Hydra 亦可，但生态与文档成熟度逊于 Keycloak）。建议保留迁移至其他 OIDC Provider 的抽象层（如标准 JWT 解析，不绑定 Keycloak 特有 API）。

架构设计：

• 双环境：测试环境（供应用对接调试）+生产环境严格分离；
• 生产集群化：双节点+Nginx 负载均衡+独立 PostgreSQL 存储——身份中心宕机等于全公司无法登录任何系统，必须消除单点；
• 部署位置：研发协作域，但按最高管控标准管理（仅堡垒机可达管理端口）。

身份生命周期与安全策略：

• 入职即建档：工号即账号，入职流程触发创建；
• 组即权限：所有应用授权绑定组（quant-researcher / quant-developer / ops / security / risk-audit），岗位变动=换组，从机制上防止个人权限长期累积膨胀——权限漂移是内部威胁的头号温床；
• 用户属性携带密级：用户对象标注可访问数据级别（S1/S2/S3），下游应用据此做数据过滤；
• MFA 分级强制：全员 TOTP；特权账号（堡垒机管理员、GitLab Owner、vCenter 管理员、数据库 root、云账号）强制 FIDO2 硬件密钥——特权账号是 T8 威胁的唯一入口，必须最高强度；
• 离职即失效：离职流程与账号联动，当日冻结、全域 SSO 同时失效、活动会话吊销——一处冻结、处处失效，这是统一身份中心相对各系统独立账号的最大安全红利；
• 暴力破解防护与会话策略：失败锁定（渐进加长）、SSO 会话空闲超时 8 小时、刷新令牌 30 天上限、全链路 HTTPS 强制、禁用 TLS 1.1 及以下；
• 客户端接入规范：每个应用注册独立 OIDC 客户端，redirect URI 精确到路径，机密客户端用私钥 JWT 而非明文 secret。

3.2 账号治理总则

• 一人事一号，杜绝共享账号——每步操作必须可回溯到自然人；
• 服务账号清单化：CI 账号、备份账号、监控采集账号等非人类账号登记造册，owner、用途、密钥轮换周期三项齐全，季度复核；
• 特权账号最小化：每个系统的管理员账号数量控制在一掌之数，其余一律降权；
• 应急账号：各系统保留一个密封应急账号（密码纸质密封于保险柜），启用即触发告警，事后 48 小时内审计。

第四章平台核心组件设计

本章给出九大组件的技术选型、部署架构与加固要点。选型总原则：优先开源自主可控，安全关键能力不足时采购商业版，总预算控制在中小量化团队可承受范围。

4.1 物理与虚拟化底座

物理层是全部上层控制的信任根基——所有数字世界的权限管理，在"有人能物理接触硬盘"面前都不堪一击。

• 机房门禁：联网电子门禁（动态密码+远程授权开锁+断电自动上锁告警）；极少数人常驻授权，其余一律临时授权（精确到小时、自动失效）；门磁防尾随（开门超时告警）；
• 监控联动：门禁开启即触发录像+推送告警（授权进入同样留痕）；录像保存一年，独立存储；
• 环境保障：UPS 覆盖核心设备（满载≥30分钟）、温湿度与烟感告警、核心设备双电源分路；
• 物理机加固：BIOS

本文为 独立观点，未经授权禁止转载。
如需授权、对文章有疑问或需删除稿件，请联系 FreeBuf 客服小蜜蜂（微信：freebee1024）