等保 2.0 里邮件系统怎么定级？定级对象的边界到底划到哪一层？

等级保护的第一步是确定「定级对象」，而邮件场景里绝大多数返工都发生在这一步。GB/T 22240-2020《信息安全技术 网络安全等级保护定级指南》 给出的判据是三条基本特征：具有确定的主要安全责任主体、承载相对独立的业务应用、包含相互关联的多个资源。三条要同时满足。

用这三条去卡邮件系统，会得到一个和直觉不同的结论：邮件系统通常应当作为一个独立的定级对象，而不是挂在「综合办公系统」下面的一个功能模块。理由很直接——它有独立的责任主体（邮件运维团队）、承载相对独立的业务（收发、存储、归档），并且包含相互关联的多个资源（MTA、存储、认证、网关、Web 端）。

反过来的错误同样常见：把邮件网关、反垃圾、邮件归档各自单独定级。这三者不满足「相对独立的业务应用」——它们是同一业务链条上的组件，拆开定级会导致边界处的安全责任出现真空，且在测评时无法解释数据流。

定级结论由两个维度交叉得出：受侵害的客体（公民、法人和其他组织的合法权益 / 社会秩序与公共利益 / 国家安全）与侵害程度（一般损害 / 严重损害 / 特别严重损害）。

邮件系统在这个矩阵里有一个容易被低估的特点：它的实际影响面往往高于它的「系统重要性」直觉。原因有三：

• 邮箱是身份找回的枢纽。大量业务系统把密码重置寄托于邮箱，邮箱失守等于这些系统一并失守。定级时如果只看「邮件本身承载什么」，会系统性低估。
• 邮件天然沉淀历史数据。邮箱里累积的往来记录、附件、合同草稿，其敏感度通常高于任何单一业务库的当期数据。
• 域名信誉具有对外溢出性。本域被用于外发滥用时，受损的不只是本单位，还包括所有接收方——这直接关联到「社会秩序与公共利益」这一客体。

因此对承载正式公文、客户往来或涉及大量个人信息的单位，邮件系统按第三级定级是常见且通常站得住的判断；把它按第二级处理，往往在测评的数据保密性与集中管控环节上难以自圆其说。

定级对象确定后要划边界，正确的方法是沿着邮件的数据流走一遍，凡是原始报文经过、落地或可被读取的地方，都在边界内。按这个原则，边界内至少包含：

• 接收与投递链路：对外的 MTA（RFC 5321 定义的 SMTP 传输）、对内的提交入口（RFC 6409 定义的 Submission，通常在 587 端口）。
• 过滤与策略执行点：反垃圾、反病毒、内容检查与策略路由环节。
• 存储与检索：邮箱存储、索引、归档库，以及归档的备份介质。
• 访问端：Web 邮件界面、IMAP/POP 服务、移动端接入通道。
• 认证与目录：邮件系统所依赖的账号目录与认证服务（若为共用组件，需明确接口边界与责任划分）。

常被漏掉、而测评时必被问到的两处：一是邮件网关到内部 MTA 之间那一段「内网所以不加密」的链路；二是归档系统的检索导出通道——它能一次性取出大量历史原始报文，权限却常常只有一层口令。

错误一：把云上的邮件网关排除在边界外。理由通常是「那是服务商的」。但原始报文确实经过它，它就是数据流的一环。正确做法是把它纳入边界并明确责任划分：哪些控制项由服务商承担、以何种方式提供证据，这在测评时需要能拿出书面依据。

错误二：只算生产不算灾备。灾备端持有的是同一份数据的完整副本，其防护水平不能低于生产端。灾备常年无人访问，反而更容易出现补丁滞后与账号失管。

错误三：把移动端接入当成「客户端问题」。移动端接入通道是系统对外暴露的一个真实入口，其认证强度、传输加密与会话管理都在定级对象范围内。

错误四：把测试环境排除，但测试库里是生产数据的拷贝。这是最危险的一种——边界外的系统持有边界内等级的数据。要么把测试环境纳入同等防护，要么严格做数据脱敏，二者必居其一。

定级不是终点，它决定了后续两份文件的坐标系：GB/T 25070-2019《信息安全技术 网络安全等级保护安全设计技术要求》 是「按这个级别应当怎么设计」，GB/T 28448-2019《信息安全技术 网络安全等级保护测评要求》 是「按这个级别怎么验」。三者必须共用同一个定级对象定义与同一张边界图。

实务中一个高频返工点是：定级报告里的系统边界图、安全建设方案里的网络拓扑、测评时提供的资产清单，三份图不一致。测评机构一旦发现三者对不上，会先要求统一，整个进度就此停摆。

务实的做法是：把边界图做成唯一的一份，定级、设计、整改、测评全部引用它；每次架构变更（新增一个中继节点、换一个网关、加一套归档）都回改这张图，并记录变更时间与原因。这张图本身就是测评时最有说服力的证据之一。

在补任何技术控制之前，先把下面四件事落成文档，它们的性价比远高于急着上设备：

1. 一张数据流图：从外部发送方到最终存储，标出每一跳的组件、协议、是否加密、日志落在哪。
2. 一份组件责任表：每个组件的责任主体（自建 / 外包 / 云服务），以及各自负责哪些控制项。
3. 一份数据类型清单：邮件系统中实际存在哪些类别的数据（往来正文、附件、账号信息、日志、归档），分别存放在哪、保留多久。
4. 一份接口清单：所有对外与对内的接入点，含协议、端口、认证方式、开放范围。

技术选型上，无论采用邮件系统的信创版还是标准版，都建议把「对外收发」与「内部投递」在架构上分层：对外一层集中做鉴伪、策略执行与日志留存，内部一层专注投递与存储。这种分层不是为了合规好看，而是因为它让边界清晰可述——边界能一句话讲清楚的系统，测评过程通常会顺利得多。

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