等保 2.0 安全计算环境的控制点，在邮件系统上怎么逐条落地？

安全计算环境的第一个控制点是身份鉴别，第三级要求采用两种或两种以上组合的鉴别技术，且其中一种应使用不可伪造的方式实现。邮件系统在这一条上有一个结构性难题：传统邮件协议的认证机制诞生于双因素概念之前。

RFC 4954《SMTP Service Extension for Authentication》 定义的 SMTP AUTH 与 IMAP/POP 的认证，本质上都是「一次性提交一组凭据」的模型，不存在交互式的第二因素环节。这导致一个很常见的合规漏洞：Web 端上了双因素，IMAP/POP/SMTP 客户端却仍在用纯口令，攻击者只要换用客户端协议就绕过了第二因素。测评时这一点会被直接指出。

可行的解法有两条，通常需要并用：

• 用令牌化认证替代口令。RFC 6749《The OAuth 2.0 Authorization Framework》 的授权模型允许把第二因素放在授权环节完成，客户端拿到的是有范围与有效期的令牌而非长期口令。
• 对无法改造的旧客户端，用专用凭据加通道限制。为其签发独立的应用专用凭据，并限制可用来源与可访问范围，同时把这类账号纳入重点审计。

另需注意鉴别信息在传输中的保护——这一点与 RFC 8314《Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access》 的要求一致：凭据不得在未加密通道上传输，允许明文认证的端口应当关闭而非仅仅「不推荐」。

访问控制要求对主体授予最小权限、实现权限分离、由授权主体配置访问规则。邮件系统里最容易失控的不是普通用户权限，而是下面三类：

• 管理员权限。邮件管理员往往具备读取任意邮箱的技术能力。等保要求权限分离——系统管理、安全管理、审计管理三类角色应当分离，且管理员的越权读取行为必须被审计员看到。一个人同时拥有全部权限且自己审计自己，是明确的不符合。
• 邮箱委派与共享。秘书代收领导邮件、多人共用职能邮箱，这类授权一旦建立就极少被回收。委派关系必须可枚举、可定期复核。「查不出当前有哪些委派关系」本身即是失分点。
• 自动转发规则。用户自建的转发规则可以把邮件持续外发，这既是访问控制问题也是数据外泄通道。至少要做到：可全局枚举、外发转发需审批或告警。

取证要点：要能当场导出「谁能访问哪个邮箱」的完整清单，而不是靠管理员口述。

安全审计要求覆盖每个用户、对重要行为与安全事件审计、审计记录包含必要要素、审计记录受到保护不被非预期删改、且审计进程应当受到保护、不能被未授权中断。邮件系统上的具体要求：

• 审计对象必须包含管理员操作。只审计普通用户而不审计管理员，等于没有审计。管理员的邮箱读取、策略变更、账号操作、日志导出都要留痕。
• 记录要素要齐。事件的日期时间、主体标识、客体标识、事件类型、结果，缺一不可。只有「某时刻发生了一次登录」而无源地址与结果，无法支撑追溯。
• 审计记录不可被运维随意删改。常见做法是实时外送到独立的日志系统，使邮件管理员在本机的删除动作不影响已外送的副本。
• 留存期要覆盖典型发现延迟。邮件类事件常在事后较长时间才被发现，日志若已轮转，追溯即失败。

此外要留意一个细节：RFC 5322《Internet Message Format》 定义的 Message-ID 是跨主机串联同一封邮件的唯一可靠桥梁。审计日志若不记录它，多组件之间的时间线就拼不起来。

这两个控制点要求采用密码技术保证重要数据在传输与存储过程中的完整性与保密性。邮件场景必须区分三种性质不同的保护，它们不能互相替代：

1. 传输中保护。由传输层加密提供，保护的是链路。邮件在每一跳解密后重新加密，因此传输加密保护不了中间节点上的数据。
2. 存储中保护。邮箱存储与归档库的落盘加密。要注意实际防护效果取决于密钥管理——密钥与密文存在同一台机器且服务账号可直接读取时，这层保护对在线攻击几乎无效，它主要防的是介质失窃与不当报废。
3. 端到端保护。RFC 8551《Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification》 定义的 S/MIME 在报文层做签名与加密，是唯一能覆盖中间节点的方式。代价是内容检查、反垃圾、归档检索都将无法解析正文，这是一个必须事先做出的取舍，而不是可以两全的选项。

取证时常被追问的一句是：「重要数据」在你们这里具体指哪些？答不上来意味着分类工作没做，后面所有加密措施都失去了针对性。建议事先给出明确清单：账号鉴别信息、邮件正文与附件、归档数据、审计日志、配置与密钥。

数据备份恢复要求提供本地备份与恢复功能、异地实时或定时备份、重要数据处理系统的热冗余。邮件系统的判分点不在「有没有备份」，而在有没有验证过恢复——从未演练过的备份在事件中等同于不存在。建议定期实测一件具体的事：能否在合理时间内恢复出指定时段、指定账号的完整原始报文。

剩余信息保护要求鉴别信息与敏感数据所在存储空间被释放或重新分配前得到完全清除。邮件系统的对应点很具体：

• 用户删除邮件后，回收站、索引、缓存、临时文件中的副本是否同步清理。
• 离职账号注销后，其邮箱数据的处置路径是否明确——是按保留期归档还是清除，由谁批准，有无记录。
• 存储介质更换与报废时的清除流程与记录。

个人信息保护要求仅采集与保存业务必需的个人信息、禁止未授权访问和非法使用。邮件系统天然是个人信息的高密度载体，这一条与个人信息保护法在邮件场景的要求高度重合，实务中建议合并成一套控制来做，避免两张皮：一套分类清单、一套权限模型、一套留存策略，同时满足两边的取证需要。

安全计算环境失分最多的原因往往不是没做，而是做了但拿不出证据。因此在补控制点时，建议直接按「测评时怎么举证」来设计：

1. 能一键导出的清单。账号与权限清单、委派关系清单、转发规则清单、管理员操作记录——这四份能随时导出，计算环境的问询环节就过去大半。
2. 能复现的验证动作。恢复演练、清除验证、双因素绕过测试，各留一份带时间与结论的记录。
3. 能自洽的口径。「重要数据」的定义在分类清单、加密方案、备份策略、留存策略中必须是同一个定义。

选型上，邮件系统的信创版与标准版在这一层的差别主要体现在密码实现与身份体系的适配方式上，但控制点本身没有差别——不能因为选了某一版本就默认某些控制点自动满足。建议把上述四份清单的导出能力作为选型时的硬性验收项，它直接决定了未来每一次测评与自查的成本。

在落地上述技术建议时，可结合 MAEF 盾 等邮件安全防护能力，按邮件系统的信创版与标准版分别适配，将鉴伪、策略执行、日志留存与密钥管理统一收口，形成可举证、可审计的控制闭环。具体能力边界以实际部署版本为准。