※本文内容基于我司内部讨论、经验以及一般安全原则整理而成。不代表特定企业、组织的官方立场，也不涉及特定供应商的内部实现。

✅ 免责声明 #

• 本文内容旨在介绍信息系统设计和运维的一般性思路，不保证对所有组织的安全性和适用性。

• 实际部署时，请根据本公司规模、行业特点、风险承受能力、法规要求、合同义务等因素，征求专家意见并进行内部审查。

• 对于基于本文内容进行的运维、配置、组织调整等行为所产生的任何损失，作者及所属组织概不负责。

前言:一人”全知全能”的状态既强大又危险 #

在基础设施、云和安全领域，
“无所不能、无所不知的’神级工程师'”往往备受推崇。

但同时,这种情况也存在以下风险:

• 该人员离职后运维工作无法正常进行(Bus Factor 为 1)

• 权限过度集中,误操作、突发事件造成的影响可能是致命的

• 从安全角度看,”内部作恶风险”较高的结构

在大规模云、金融机构、SWIFT 等领域,
为了规避这一问题,“任何人都无法完全掌控全局的架构”正在成为常识。

不过,如果中小规模组织照搬同样的做法,
管理成本会激增,实际操作中往往难以承受……这也是现实。

因此,本文整理了一套适合中小至中型组织引入的”轻量零信任分割模型”。

模型目标 #

该模型旨在实现以下状态。

• ✅ 消除一人”全知全能、全权操作”的状态

• ✅ 日常运维不会变得过于复杂

• ✅ 紧急情况下能够正常响应(考虑应急处置)

“零信任”听起来可能有些夸张,
但在这里可以简单理解为“人员和系统只能访问必要的资源”即可。

步骤1:将角色分为 3 类(域分割) #

首先从最简单的方式入手,
将系统分为 3 个域来思考。

A. 基础设施负责人 #

• 虚拟化平台(VMware / Proxmox / Hyper-V 等)

• 操作系统(Linux / Windows)

• 存储

• 基础网络

• 备份基础平台

B. 应用负责人 #

• Web / API 服务器

• 中间件（nginx / Apache / Redis / MQ 等）

• 数据库

• CI/CD 流水线

• 应用程序配置・部署

C. 安全・认证负责人 #

• IAM / 账户管理

• VPN / SSO / AD / LDAP

• 权限设计

• 证书・密钥管理

• 日志・审计基础设施

要点：

避免同一人拥有 A + B + C 全部的完全权限。

即使是小型组织，

• 主要负责人 + 辅助负责人

• 或者”可以操作到这里，但再往下需要请其他人处理”

只要明文规定这样的界限，风险就会大幅降低。

步骤2：权限级别仅设”3个层级” #

提到零信任，容易联想到细致的 RBAC 或角色设计，
但在小规模现场做得过于复杂反而会导致失败。

因此特意仅设3个层级。

D1. 操作员（运维操作） #

• 监控和日志查看

• 服务重启

• 简单的配置变更

• 按照操作手册进行操作

D2. 维护管理员（基础设施／应用管理） #

• 虚拟机创建・删除

• 存储卷添加

• 网络设置变更

• 中间件更新・配置变更

D3. 安全管理员（IAM / 认证） #

• 账户创建・删除

• 角色・组的定义变更

• 密码策略变更

• VPN / 密钥 / 证书的生命周期管理

绝对规则：

D2(运维管理员)和 D3(安全管理员)
不由同一人”长期”兼任。

也就是说,不要让”VM 也能管、IAM 也能管、什么都能管的超级管理员”成为常态。

如果因为人员有限确实需要兼任,

• 平时只启用其中一个权限

• 另一个作为紧急用途,通过权限提升流程+日志记录进行临时使用

这种方式比较推荐。

步骤3:仅仅”好好记录”操作日志就已经很强了 #

即使无法做到完美的权限设计,
只要能追踪”谁在什么时候做了什么”,威慑力和安心感就会有天壤之别。

示例 #

• 虚拟化平台:审计日志(Proxmox / vCenter 的 Audit Log 等)

• 操作系统:journalctl / auditd

• 网络设备:syslog 集中管理

• IaC / Git:提交日志·Pull Request

最低要求:

1. 重要组件全部以某种形式启用日志输出

2. 日志最好集中到一处(syslog 服务器或日志平台)

3. 确保能够了解”谁·何时·用哪个账户·做了什么”

仅仅记录日志,
就能自然形成”难以随意操作的环境”。

步骤4:通过自动化·IaC 将”人脑中的知识”系统化 #

人员依赖的主要原因是,

“配置和架构只存在于某个人的脑子里”

这一点。

打破这种局面的最快方法就是**自动化和 IaC(Infrastructure as Code)**。

示例 #

• 用 Terraform 管理云/虚拟化平台的配置

• 用 Ansible 统一 OS / 中间件配置

• 用 GitHub Actions / GitLab CI 标准化部署流程

• 即使是 Shell 脚本也可以,将手动操作脚本化

关键在于,

“减少人员直接操作控制台的次数”

这个方向性。

步骤5:将机密信息托管给”系统”而非”人” #

SSH 秘密鍵、API 密钥、密码、证明书——
重要的是不要将这些信息放在个人本地电脑或由个人管理。

典型方法 #

• 密码管理器（1Password、Bitwarden、KeePass 等）

• 密钥管理服务（Vault、AWS Secrets Manager 等）

• 不要以明文形式放在 Git 中（进行加密或引用 ID 化）

通过在系统层面的权限控制”谁可以访问哪些密钥”，
目标是建立密钥不与个人绑定的架构。

步骤6：设计文档也要”分割” #

如果文档也做成一体式的，
就只有完全理解它的人才会变得强大。

因此，设计文档也应按角色进行分割。

• 网络设计文档（由基础设施负责人 A 管理）

• 服务器配置·角色清单（基础设施/应用共通）

• 应用程序配置文档（由应用负责人 B 管理）

• 认证·IAM 设计文档（由安全负责人 C 管理）

• 日志·审计设计文档（安全负责人 C）

比起”一个人编写、只有一个人理解的设计文档”，
“多人编写、按角色分工的设计文档”更为健康。

步骤7：决定应急时的”两阶段模式” #

小型组织更需要
避免”紧急时谁都无法操作而陷入困境”的情况。

因此，将规则分为平时和紧急时。

平时 #

• 权限按 D1 / D2 / D3 分离运维

• 危险操作原则上仅限 D3

紧急时 #

• 例如决定”服务全面停止”、”重大事故”等条件

• 负责人 + 安全负责人等2名以上同意后临时提升权限

• 恢复后取消提升，确认和审查操作日志

这样一来，

“平时保持分离”
“真正需要时，留下适当痕迹后临时解禁’神模式'”

可以取得这样的平衡。

总结：”不需要神级工程师”不是理想论，而是设计问题 #

本文介绍的轻量级模型总结如下。

1. 将角色分为基础设施 / 应用 / 安全 3 个领域

2. 将权限分为 3 级（操作/管理/安全），杜绝”随时可以做任何事的人”

3. 妥善保留操作日志，确保”谁做了什么”可追溯

4. 将基础设施和配置自动化/IaC 化，把”人脑中的知识”转化为代码

5. 将机密信息交给系统而非个人保管

6. 设计文档也按角色分割管理

7. 制定规则，仅在紧急情况下”经双人批准解锁神模式”

这些是借鉴大型云服务商、金融机构、SWIFT 等采用的理念，
简化后使中小规模企业也能轻松应用的模型。

结语 #

“一个人掌握全部”的状态，
短期内确实非常便利，
但从长远来看，在业务连续性、安全性、组织健康度方面会带来巨大风险。

反过来说，
只要逐步推进”分割””分离””自动化”，
就能摆脱”依赖神级工程师的组织”。

本文内容仅作为参考框架，
希望各公司能根据自身情况灵活调整。