等保 2.0 安全区域边界层面的要求，落到邮件系统上具体要做哪些事？

GB/T 22239-2019 的安全通用要求分为技术与管理两大部分。技术部分包含安全物理环境、安全通信网络、安全区域边界、安全计算环境、安全管理中心五个层面；管理部分包含安全管理制度、安全管理机构、安全管理人员、安全建设管理、安全运维管理五个层面。

邮件系统的特殊之处在于，它天然是一个跨越边界的系统：对外要接收来自互联网上任意主机的连接，对内要向全体员工投递。这使它在「安全区域边界」层面承担的要求密度远高于一般的内部业务系统。

更值得注意的是，该标准在安全区域边界层面设有「恶意代码和垃圾邮件防范」这一控制点，垃圾邮件防范被写进了控制点名称本身。这在整部标准里是罕见的——大多数控制点是通用表述，而这一处直接点名了邮件这一具体业务形态。这说明邮件通道被明确视为边界上的独立风险面，不能被「装了防火墙」笼统覆盖过去。

定级方面，GB/T 22240-2020 给出了定级方法。邮件系统通常不单独定级，而是随其所属的信息系统整体定级；但如果邮件系统承载了独立的业务与数据，且其受破坏后的影响范围与所属系统不同，就需要单独考虑。这一步判断必须在设计之前完成，因为级别直接决定了后续要满足的要求条数。

边界防护控制点的核心要求是跨越边界的访问和数据流通过受控接口进行通信，并对非授权设备接入内部网络、内部用户非授权连接外部网络的行为进行检查与限制。访问控制控制点则要求在网络边界或区域之间根据访问控制策略设置访问控制规则，默认情况下除允许通信外受控接口拒绝所有通信，并要求删除多余或无效的访问控制规则、优化访问控制列表、使规则数量最小化。

翻译到邮件系统：

• 入站只留一个门。互联网到内部的 SMTP 连接必须收敛到边界网关，内部投递服务器不得直接暴露在公网。MX 记录只指向网关，且要主动核查是否有历史遗留的 A 记录或备用 MX 泄露了内部主机。
• 出站也要收敛。内网主机不应能够直接向互联网发起对外部 25 端口的连接。这一条常被忽略，但它是遏制内网失陷主机外发垃圾邮件、以及数据经由邮件外泄的关键一环。所有外发必须经由指定的中继。
• 默认拒绝。网关的中继策略必须是白名单式的：只为已认证用户或已授权网段中继。开放中继在任何级别下都是不可接受的，且必须定期用外部视角实测验证，而不是只看配置文件。
• 规则最小化。网关上的放行白名单、免检名单、豁免规则会随时间不断累积。这些恰恰是标准明确要求清理的「多余或无效规则」——一条为三年前某个合作方临时加的免检规则，就是一个永久后门。应建立白名单的有效期与复核机制。
• 提交与投递分离。用户提交走独立端口并强制认证，与承载服务器间中继的通道在配置上彻底分开，避免一条策略同时服务两种语义完全不同的流量。

入侵防范控制点要求在关键网络节点处检测、防止或限制从外部与内部发起的网络攻击行为，并要求对攻击行为进行分析、在发生严重入侵事件时提供报警。恶意代码和垃圾邮件防范控制点则要求在关键网络节点处对恶意代码进行检测和清除，并维护恶意代码防护机制的升级和更新；对垃圾邮件进行检测和防护，并维护垃圾邮件防护机制的升级和更新。

注意两处措辞：一是「检测和清除」，只检测不处置不满足要求；二是「维护升级和更新」，规则库停更的设备在测评中等同于失效。据此的落地要点：

1. 附件与链接的处置策略必须明确。可执行体、脚本、宏文档、密码保护压缩包各自的处置动作（拒收 / 剥离 / 隔离 / 沙箱）要形成书面策略，并与实际配置一致。测评看的是「策略—配置—日志」三者能否对上。
2. 规则与特征库的更新要可举证。保留更新时间、版本号、更新失败告警记录。断网环境下的离线更新流程同样要有记录。
3. 发件人身份认证要真正落地。SPF、DKIM、DMARC（RFC 7489）构成对伪造发件人这一类攻击的检测能力。只发布记录而不对入站结果做判定，等于只做了一半——需要明确 DMARC 校验失败时的动作，并保证判定结果进入日志。
4. 协议层的攻击面要收敛。连接频率与并发限制、单连接收件人数量限制、报文尺寸限制、无效收件人探测的限速与封禁。RFC 5321 为其中若干项提供了协议层依据，这些限制同时服务于反滥用与可用性保障。
5. 告警必须有人接。标准要求「提供报警」，落地时要指定接收人、响应时限与处置记录。告警发到一个没人看的邮箱，在测评中与没有告警等价，何况邮件系统故障时这类告警恰好发不出去——告警通道应当独立于被监控的邮件系统本身。

安全区域边界层面同样设有安全审计控制点，要求在网络边界、重要网络节点进行安全审计，审计覆盖到每个用户，对重要的用户行为和重要安全事件进行审计；审计记录应包括事件的日期和时间、用户、事件类型、事件是否成功及其他与审计相关的信息；并要求对审计记录进行保护、定期备份，避免受到未预期的删除、修改或覆盖等。同时要求能够对远程访问的用户行为、访问互联网的用户行为等单独进行行为审计和数据分析。

「覆盖到每个用户」这一句对邮件系统提出了具体约束：网关日志若只记录了 IP 与信封地址，而无法关联到内部的具体账号，就没有真正做到覆盖到用户。Webmail 与移动端访问尤其需要注意——同一个出口 IP 后面可能是全公司，必须记录到认证主体。

需要落地的记录字段至少包括：会话时间、源地址、认证账号、信封发件人与收件人、报文标识、判定结果与依据、最终动作、以及失败原因。「事件是否成功」这一要求意味着失败记录与成功记录同等重要——被拒绝的投递、认证失败、策略拦截都必须留痕，而这恰恰是很多默认配置下被丢弃的部分。

安全区域边界层面还包含可信验证控制点，要求可基于可信根对边界设备的系统引导程序、系统程序、重要配置参数和边界防护应用程序等进行可信验证，并在检测到其可信性受到破坏后进行报警，且将验证结果形成审计记录送至安全管理中心。随着等级提高，验证的时机要求从启动时扩展到运行过程中的动态验证。

对邮件网关而言，这一条的现实含义是：网关的策略配置文件属于「重要配置参数」，其变更应当被监控与记录。攻击者取得网关权限后的典型动作，就是悄悄加一条免检规则或转发规则，而不是制造明显的服务中断。

建议的推进顺序：

1. 先画准边界。把所有能收发邮件的路径列全，包括业务系统的通知邮件、监控告警邮件、打印机与摄像头等设备的外发、以及历史遗留的直连出口。漏画一条路径，后面所有控制都会从这里绕过去。
2. 再收敛通道。入站收敛到网关，出站收敛到中继，关闭一切旁路。
3. 然后配策略。默认拒绝、白名单可控、白名单有期限。
4. 再补审计。确认日志字段完整、能关联到用户、且集中存储不可篡改。网络安全法要求相关网络日志留存不少于六个月，这是留存期的下限起点。
5. 最后做证据链。把策略文档、配置快照、日志样本、告警处置记录、规则库更新记录整理成一一对应的材料。测评本质上是核对「你说的」与「系统做的」是否一致，两者对不上的地方就是失分点。