等保 2.0 三级要求怎么逐条映射到邮件系统？

映射的第一步不是查配置，而是依据 GB/T 22240-2020《信息安全技术 网络安全等级保护定级指南》 确定定级对象。邮件系统最常见的错误是把定级对象缩得太小——只写「邮件服务器」，把网关、目录服务、归档库、Web 访问端排除在外，导致测评时边界与实际数据流对不上。

判定条件：凡是承载或经手邮件正文、附件、收发件人地址、认证凭据的组件，都应纳入同一定级对象。至少包括：外部接收 MTA、反垃圾/反病毒处理节点、内部投递 MTA、邮箱存储、身份目录、Web/IMAP/POP 访问入口、归档与备份系统。

产出物是一张唯一的数据流边界图，后续定级、设计、整改、测评四个环节共用同一份。

GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》 的第三级安全通用要求分为安全物理环境、安全通信网络、安全区域边界、安全计算环境、安全管理中心五个技术层面。邮件系统的对应落点：

• 安全物理环境：机房与介质管理，邮件系统一般随承载环境一并测评；若使用外部承载资源，需另行说明责任边界。
• 安全通信网络：传输过程的完整性与保密性——对应 SMTP/IMAP/POP/HTTP 各链路的加密。
• 安全区域边界：访问控制、入侵防范、恶意代码与垃圾邮件防范、边界侧审计。
• 安全计算环境：身份鉴别、访问控制、安全审计、数据完整性与保密性、数据备份恢复、剩余信息保护、个人信息保护。
• 安全管理中心：系统管理、审计管理、安全管理三类角色分离，以及集中管控。

高频误解是「内网链路不用加密」。等保对通信传输的完整性与保密性要求并不以内外网划界。网关到内部 MTA、MTA 到存储、应用到数据库、应用到目录服务，这些链路同样在范围内。

协议侧的立场也一致：RFC 8314 Cleartext Considered Obsolete: Use of TLS for Email Submission and Access 明确把明文的邮件提交与访问视为过时做法，应使用 TLS。

可操作配置：客户端接入统一走隐式 TLS 端口（提交 465、IMAP 993、POP 995），保留 587 时必须要求先 STARTTLS 再认证并禁止明文认证；服务器间链路启用 TLS 并配置对端校验；关闭 110/143 的明文可用路径或仅监听回环。

区域边界的必查点：端口最小化开放、管理端口不暴露公网、无开放中继、垃圾邮件检测防护机制存在且能提供规则库更新的时间序列证据、恶意代码防范同样要有升级记录。

计算环境的必查点：身份鉴别应采用两种及以上鉴别技术且其中之一不可被复制（注意 IMAP/POP/SMTP 客户端协议不能成为绕过通道）；审计覆盖每个用户与重要行为；重要数据传输与存储的完整性、保密性有保护措施；备份可恢复并做过恢复演练。

系统管理员、审计管理员、安全管理员三类角色需分离，且审计管理员对系统管理员的操作具备可见性。「三个角色其实是同一个人」在访谈环节极易暴露，属于性质明确的不符合项。

可落地的最小改动：即使不增编制，也应把审计日志的读取与留存权限从系统管理员剥离到另一自然人，并使系统管理员无权删改审计记录（日志实时外送到独立系统即可实现）。

1. 定级对象与边界图是否覆盖全部经手邮件数据的组件，且与资产清单一致。
2. 客户端与服务器间链路是否全部加密，能否用抓包实测证明。
3. 垃圾邮件与恶意代码防范机制是否有可展示的更新历史。
4. 身份鉴别是否存在客户端协议绕过路径。
5. 审计记录五要素（时间、主体、客体、事件类型、结果）是否齐全，留存期是否达标。
6. 三类管理员是否真实分离，审计员能否独立取证。
7. 本域是否已发布发件人鉴伪策略，边界访问控制是否最小化。

标准编号与现行有效状态，请以国家标准全文公开系统检索结果为准。