邮件系统等保2.0与密评合规全景指南

摘要

本文以 GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》（等保2.0）和 GB/T 39786-2021《信息安全技术 信息系统密码应用基本要求》（密评）为核心依据，系统梳理邮件系统在安全通信网络、安全计算环境、安全管理中心三个层面的合规要求，以及密码应用在物理和环境安全、网络和通信安全、设备和计算安全、应用和数据安全四个技术层面及四个管理层面的具体条款。文章同时覆盖政务、金融等特定行业的邮件合规增强要求，为邮件系统的等保定级、密评准备、安全建设和迎检整改提供可操作的检查清单与实施指引。

1. 背景：等保2.0与密评的关系框架

1.1 等保2.0的核心变化

等保2.0（GB/T 22239-2019）相较于等保1.0（GB/T 22239-2008），在保护对象范围、安全要求维度和测评力度上均有显著扩展[1]：

• 保护对象扩展：从传统信息系统扩展至云计算、移动互联、物联网、工业控制系统和新型应用系统，邮件系统作为关键信息基础设施的核心组件，其保护需求被纳入更广泛的网络安全框架。
• 安全要求重构：将原"技术要求"和"管理要求"两大分类重构为"安全物理环境、安全通信网络、安全区域边界、安全计算环境、安全管理中心"五个技术层面和"安全管理制度、安全管理机构、安全管理人员、安全建设管理、安全运维管理"五个管理层面，形成"一个中心、三重防护"的纵深防御体系。
• 密码技术核心化：等保2.0在三级及以上要求中明确引入密码技术，用于保障通信数据的完整性和保密性、身份鉴别的高强度要求以及数据的存储加密。

1.2 密评的制度定位

GB/T 39786-2021《信息系统密码应用基本要求》是我国商用密码应用安全性评估（简称"密评"）的核心依据[2]。密评从以下八个层面对信息系统提出密码应用要求：物理和环境安全、网络和通信安全、设备和计算安全、应用和数据安全四个技术层面，以及管理制度、人员管理、建设运行、应急处置四个管理层面。

密评等级与等保等级形成严格对应关系：等保一级对应密评一级，等保二级对应密评二级，等保三级对应密评三级，等保四级对应密评四级。对于关键信息基础设施（关基）和等保三级及以上系统，密评为强制性要求。中国密码学会密评联委会在《商用密码应用安全性评估FAQ（第三版）》（2023年10月）中明确指出：缺少密码应用方案或密评未通过，将被判定为高风险项[4]。

1.3 邮件系统为什么需要双合规

邮件系统承载组织内外的核心通信，是数据流转的关键节点。邮件内容涉及商业秘密、个人信息和业务指令，其传输和存储安全直接关系到组织的法律合规风险。在等保2.0和密评的交叉要求下，邮件系统至少需要在以下方面实现双覆盖：

• 网络传输加密（TLS + 国密TLS双栈）
• 邮件存储加密（国密SM4全盘/细粒度加密）
• 用户身份鉴别（国密SM2数字证书+双因素认证）
• 安全审计日志的完整性与不可否认性（SM3哈希链）
• 密码产品和服务的合规选用（GM/T 0028-2014 安全二级及以上模块）

2. 等保2.0对邮件系统的核心要求

2.1 安全通信网络

GB/T 22239-2019 在安全通信网络层面，对邮件系统提出的关键控制点包括[1]：

2.1.1 通信传输加密与完整性保护

等保三级明确要求"应采用密码技术保证通信过程中数据的完整性"和"应采用密码技术保证通信过程中数据的保密性"。对邮件系统而言，这意味着：

• SMTP传输加密：发信MTA至收信MTA之间的SMTP会话必须启用STARTTLS（RFC 3207）或隐式TLS（端口465），强制TLS 1.2及以上版本，禁用SSLv3/TLS 1.0/1.1。对于密评场景，需同时支持基于SM2/SM3/SM4的国密TLS密码套件。
• IMAP/POP3加密：客户端访问邮件时，必须通过IMAPS（端口993）或POP3S（端口995）进行，禁止明文传输认证凭据和邮件内容。RFC 8314（2018年1月）已明确建议废弃所有明文邮件协议。
• WebMail HTTPS：WebMail前端必须强制HTTPS，启用HSTS（HTTP Strict Transport Security），证书选用国密SM2证书或国际RSA/ECC证书，视合规场景而定。
• 管理信道加密：邮件系统的管理后台、API接口、日志传输通道均须使用加密信道，防止管理凭据和审计数据被截获。

2.1.2 网络架构安全

邮件系统应部署于独立的网络安全域，与办公网络、业务系统网络进行逻辑隔离。邮件安全网关应部署于DMZ区域，作为内外网邮件流量的统一出入口，过滤恶意邮件和敏感数据外泄，不得将邮件服务器直接暴露于公网。

2.2 安全计算环境

2.2.1 身份鉴别

等保2.0对身份鉴别提出以下关键技术要求[1]：

• 身份标识与鉴别：用户登录邮件系统时，身份标识必须唯一，鉴别信息复杂度策略（密码长度≥8位，含大小写字母、数字、特殊字符至少三类）须强制执行。系统应支持鉴别信息定期更换策略（建议90天），初次登录强制修改默认口令。
• 两种以上组合鉴别技术：等保三级及以上系统必须采用两种或两种以上组合的鉴别技术。邮件系统常见的实现方案为"静态口令 + 动态验证码（短信/邮件OTP）"或"静态口令 + 数字证书（SM2 USBKey/移动端软证书）"。仅使用用户名+口令的单因素认证不满足三级要求。
• 登录失败处理：同一账户连续登录失败达到阈值（建议5次）后，应自动锁定账户（建议30分钟）或触发告警，并记录安全审计日志。
• 远程管理安全：通过SSH等协议远程管理邮件服务器时，须采用密钥认证替代口令认证，禁止root直接远程登录。

2.2.2 访问控制

• 最小权限原则：邮件系统管理员、域管理员、普通用户三类角色应严格分离权限。邮件系统应提供基于角色的访问控制（RBAC），管理员不应默认拥有读取所有用户邮件的权限。审计管理员与系统管理员须为不同账户，实现三权分立（系统管理、安全审计、安全保密）。
• 细粒度授权：对邮件附件下载、邮件转发、自动转发规则、API调用等敏感操作应支持按用户/组级别的授权控制。政务邮件系统特别要求禁止自动转发邮件至外部域（见第4.1节）。
• 默认拒绝策略：新建账户的默认权限集应为最小集合，未经明确授权不具备任何超出基本收发邮件之外的操作能力。

2.2.3 安全审计

• 审计内容全覆盖：邮件系统须对以下事件生成审计记录：用户登录/登出、邮件发送/接收/删除/转发、管理员操作（配置变更、账户增删改、权限修改）、安全策略变更、系统启动/停止。每条记录须包含事件时间、用户标识、事件类型、事件结果、来源IP等信息。
• 审计记录保护：审计日志存储时间不少于6个月（GB/T 22239-2019 三级要求），且须受到严格保护，防止非授权访问、修改和删除。应采用SM3等密码哈希算法对审计日志进行完整性保护，实现不可否认性。
• 审计集中管控：邮件系统的审计数据应统一汇聚至安全管理中心（SOC/SIEM），实现集中审计与分析（见第2.3节）。

2.2.4 数据完整性与保密性

等保三级在数据安全方面对邮件系统提出核心要求[1]：

• 传输完整性：采用校验码或密码技术保证数据在传输过程中的完整性。邮件系统应在SMTP/IMAP协议层面实施TLS加密，同时支持SM2/SM3签名以提供传输过程中的防篡改保护。
• 存储完整性：采用校验码或密码技术保证数据在存储过程中的完整性。邮件系统中的邮件正文、附件、审计日志、配置数据均应通过完整性校验机制（如SM3哈希）进行保护。
• 传输保密性：采用密码技术保证数据在传输过程中的保密性。通信加密方案见第2.1.1节。
• 存储保密性：采用密码技术保证数据在存储过程中的保密性。邮件存储服务器应支持全盘加密（LUKS）或文件级加密（SM4/AES），确保物理介质丢失后数据不可恢复。邮件附件应独立加密存储，加密密钥与存储数据分离。
• 数据备份与恢复：邮件系统须提供本地和异地数据备份能力，备份数据同样须加密保护。备份恢复演练应至少每半年执行一次。

2.3 安全管理中心

等保三级要求系统具备安全管理中心功能，实现集中管控[1]：

• 集中审计：邮件系统的全部安全审计数据应上报至安全管理中心，支持查询、统计、关联分析和报表生成。安全管理中心应能对邮件系统的审计数据进行跨设备关联分析，检测异常登录、大量邮件外发、权限异常变更等安全事件。
• 集中监控：对邮件系统的运行状态（CPU、内存、磁盘、邮件队列、网络流量）、安全事件（暴力破解、异常登录、病毒邮件拦截）进行实时监控和告警。
• 集中策略管理：安全策略（密码复杂度、登录锁定、访问控制规则）应通过安全管理中心统一下发和执行，避免各组件策略不一致产生的安全盲区。
• 安全事件响应：安全管理中心应能够识别和预警安全事件，并触发应急响应流程（通知管理员、自动阻断、证据保全）。

2.4 等保定级建议

邮件系统的等保定级建议如下：

3. 密评对邮件系统的专项要求

3.1 密评概述

GB/T 39786-2021 将密码应用要求划分为八个层面，其中四个技术层面对邮件系统具有直接约束力[2]：

• 物理和环境安全：机房电子门禁系统应采用SM2/SM3/SM4进行身份鉴别与门禁记录保护。视频监控数据须通过国密算法进行完整性保护，防止监控记录被篡改。
• 网络和通信安全：通信双方的身份须通过基于SM2的数字证书进行鉴别，通信过程须采用国密TLS密码套件保障数据的机密性和完整性，通信过程中的重要安全参数（如随机数、会话密钥）的生成须使用符合GM/T 0005要求的随机数生成器。
• 设备和计算安全：服务器操作系统和数据库管理系统登录用户的身份鉴别信息须通过SM3等密码算法进行完整性保护，防止鉴别信息被篡改。系统资源访问控制信息（权限配置、ACL）的完整性须通过密码技术保护。日志记录的完整性须通过SM3或HMAC-SM3进行保护。重要可执行程序（邮件系统的可执行文件、脚本、配置文件）的完整性须在加载时进行校验。
• 应用和数据安全：这是对邮件系统最直接、最详细的要求层面。见第3.2节至第3.7节的逐项解析。

3.2 身份鉴别层面的密评要求

邮件系统须对登录用户进行身份鉴别，并采用密码技术保证鉴别信息在传输和存储过程中的机密性与完整性[2]：

• 鉴别信息传输保护：用户登录口令在传输过程中不得以明文或可逆编码（Base64）形式出现，必须通过加密信道（TLS/国密TLS）保护。SMTP AUTH PLAIN/LOGIN机制必须在STARTTLS或隐式TLS通道内执行。
• 鉴别信息存储保护：用户口令在服务器端存储时不得为明文，须使用加盐哈希算法（如SHA-512 crypt、bcrypt、arg2id）或符合GM/T的密码杂凑算法（SM3）进行单向哈希存储。不得使用MD5或未加盐SHA-1。
• 动态令牌验证：若采用双因素认证（2FA），动态令牌的种子密钥存储须使用密码技术保护。基于SM2数字证书的身份鉴别方案优于基于静态密钥分发的OTP方案，因其不依赖共享秘密信道。

3.3 访问控制信息完整性

邮件系统的访问控制列表（ACL）、角色权限配置、授权策略等访问控制信息的完整性须通过SM3或HMAC-SM3进行保护[2]，防止攻击者通过篡改ACL数据库获取非授权访问能力。实现方式包括：

• 数据库层面的字段级SM3哈希签名
• 配置文件的整体HMAC-SM3签名，启动时校验
• API层面的请求签名验证，防止权限配置接口被中间人篡改

3.4 数据传输加密

邮件在传输过程中的机密性和完整性保护是密评的重点检查项[2]：

• 传输机密性：邮件正文、附件、邮件头信息在网络传输中须使用密码技术加密。加密通道的密钥协商应基于SM2或ECDHE等具有前向安全性（PFS）的密钥交换算法，确保即使服务器长期私钥泄露，历史会话密钥仍不可恢复。
• 传输完整性：传输加密通道应使用AEAD（认证加密）模式（如SM4-GCM、AES-256-GCM），在加密的同时提供数据完整性校验，防止密文被篡改。
• 国密TLS双栈：对密评三级系统，邮件系统应支持国密TLS密码套件（基于SM2密钥交换+SM4加密+SM3 HMAC），与国际标准TLS（基于ECDHE+AES-256-GCM+SHA-384）组成双栈。客户端连接时应进行密码套件协商，优先选择符合合规要求的套件。

3.5 数据存储加密

邮件数据在存储介质上的加密保护是密评的核心要求之一[2]：

• 全盘加密：邮件存储服务器的磁盘应采用LUKS2（Linux Unified Key Setup）等全盘加密方案，加密算法选用SM4（GM/T 0002-2012）或AES-256，密钥长度不低于128位（SM4）或256位（AES）。加密密钥须通过密码模块（如HSM或符合GM/T 0028-2014安全二级及以上的软件密码模块[3]）进行管理和保护。
• 应用层加密：对于涉密或高敏邮件，邮件系统应提供应用层加密能力——基于SM2数字信封实现端到端加密（E2EE），发件人使用收件人的SM2公钥加密会话密钥，收件人使用自己的SM2私钥解密，确保即使邮件服务器管理员也无法读取邮件内容。
• 密钥生命周期管理：存储加密密钥须遵循完整的生命周期管理：安全生成（符合GM/T 0005的随机数）、安全分发（离线或加密信道分发）、安全存储（密码模块内存储，不可明文导出）、定期更换（建议每年轮换）、安全销毁（物理覆盖或密码擦除）。
• 附件独立加密：邮件附件应独立于邮件正文进行加密存储，每条附件的加密密钥应唯一生成，不可全系统共享同一密钥。

3.6 日志完整性与不可否认性

邮件的发送、接收、删除等操作记录以及系统审计日志须通过密码技术实现不可否认性保障[2]：

• 审计日志签名：每条审计日志在生成时，应使用系统的SM2私钥进行数字签名，签名值与日志记录一同存储。审计查询时验证签名有效性，任何已篡改的日志记录均可被检测。
• 哈希链防篡改：审计日志应构建SM3哈希链——每条日志记录包含前一条日志的SM3哈希值，形成前后关联的哈希链。攻击者若试图删除/插入/修改中间一条记录，会导致后续所有记录的哈希链断裂，使得篡改行为可被溯源定位。
• 日志完整性定期校验：邮件系统应支持对审计日志进行定期（建议每日）完整性校验，自动检测并告警哈希链断裂或签名验证失败的日志记录。

3.7 密码模块合规

GM/T 0028-2014《密码模块安全技术要求》将密码模块安全等级分为4级[3]，邮件系统应根据自身安全等级选择对应级别的密码模块：

邮件系统在密评三级场景中，通常使用通过国家密码管理局认证的软件密码模块（如GM/T 0028-2014安全二级软件模块）或硬件密码模块（如PCIe插卡式密码卡、USB密码钥匙），实现密钥生成、存储、使用的全流程安全管控。

4. 行业专项合规要求

4.1 政务邮件系统

政务邮件系统在等保和密评的基础上，还需满足政务信息系统的特有合规要求：

• 禁止自动转发：政务邮件系统不得提供将政务邮箱邮件自动转发至互联网邮箱的功能。这一要求源自《党政机关电子政务安全规范》中对政务信息流向的严格控制——政务信息禁止从政务网向互联网方向主动传出。
• 涉密邮件隔离：政务邮件系统中的非密邮件与涉密邮件须物理隔离或采用经过国家保密部门认证的逻辑隔离方案。涉密邮件不得流经非密邮件服务器，不得在非密网络中传输，不得存储在非密存储介质中。
• 公文流转合规：政务邮件系统承载的公文（如通知、批复、函件）须满足《党政机关公文处理工作条例》对公文的格式、加密、归档要求。邮件的SM2数字签名应等同于公文中的电子签章法律效力。
• 安全审计升级：政务邮件系统的审计日志中须包含政务邮件的密级标识（非密/秘密/机密/绝密）和处理状态（已阅/已办/已转发），审计日志须支持按密级进行检索和统计。

4.2 金融行业邮件系统

金融行业邮件系统面临银保监会、证监会的专项安全监管要求：

• 交易记录完整留存：涉及金融交易的邮件（如交易确认、对账单、合同）须完整留存，留存期限不低于监管要求的年限（通常为5-15年，依据具体业务类型而定）。留存邮件须具备完整的时间戳和数字签名，确保其法律证据效力。
• 防邮件诈骗增强：金融邮件系统须防范BEC（商业电子邮件欺诈）和CEO Fraud攻击，对来自声称"管理层"的转账指令邮件实施强化的发件人身份验证（基于DMARC reject策略 + BIMI品牌标识）和异常行为检测（如发件时间异常、转账金额超过阈值、收款账户首次出现等）。
• 监管报送接口：邮件系统应预留与监管报送系统的数据接口，支持将涉及金融合规检查的邮件数据按监管要求的格式和频次进行报送。
• 个人信息保护：邮件中涉及的个人金融信息（如身份证号、银行卡号、账户余额）须按照《个人信息保护法》和金融行业标准进行加密存储和脱敏处理，未经脱敏的原始数据不得通过邮件外发。

4.3 关基设施邮箱

关键信息基础设施运营者（CIIO）的邮件系统须满足《关键信息基础设施安全保护条例》的增强要求，密评为强制性义务。等保三级及以上关基系统必须通过密评，未通过密评将被判定为重大合规缺陷[4]。此外，关基邮件系统的供应链安全也须纳入合规评估：邮件系统及安全网关的供应商须通过安全审查，系统组件须具备自主可控能力。

5. 邮件系统合规建设检查清单

以下检查清单覆盖等保三级和密评三级对邮件系统的核心要求，可用于合规自查与整改验收。

5.1 安全通信网络检查项

5.2 身份鉴别检查项

5.3 安全审计检查项

5.4 数据安全与密码应用检查项

5.5 行业专项检查项

6. 合规建设实施路径

6.1 第一阶段：差距分析（第1-2周）

依据本文第5节的检查清单，开展邮件系统合规差距分析：逐项对照检查，标记"已满足""部分满足""不满足"三项。重点识别以下高风险项[4]：是否存在密码应用方案（无方案即为高风险）、国密算法支持情况（仅使用国际算法不满足密评要求）、密码产品合规性（使用未经认证的密码模块即为高风险）。

6.2 第二阶段：方案设计（第2-4周）

根据差距分析结果，设计邮件系统合规建设方案，形成密码应用方案文档。方案应明确：采用的密码算法和密码产品型号、密码模块安全等级、密钥管理体系架构（含密钥生成、分发、存储、更新、销毁全生命周期）、加密部署拓扑（全盘加密/应用层加密/传输加密各层的部署位置和范围）。

6.3 第三阶段：建设实施（第4-12周）

依据方案进行技术实施，核心工作包括：部署国密TLS（在Nginx或邮件网关侧启用基于SM2/SM3/SM4的国密TLS套件）、实施存储加密（Linux LUKS2 SM4全盘加密 + 应用层邮件附件独立加密）、部署双因素认证（SM2 USBKey或TOTP动态令牌）、建设日志签名体系（SM2签名 + SM3哈希链）、对接安全管理中心（审计日志上报、策略统一下发、告警联动）。

6.4 第四阶段：测评验证（第12-16周）

委托具有资质的测评机构进行等保测评和密评。测评前完成内部预评估，确保首次正式测评通过率。重点准备以下材料：密码应用方案、密码产品认证证书（国家密码管理局颁发的型号证书）、密钥管理相关文档（密钥生成记录、分发记录、销毁记录）、审计日志样本（含SM2签名和SM3哈希链）、加密部署证明材料（磁盘加密状态截图、TLS配置审计输出）。

6.5 第五阶段：持续运营

合规建设非一次性项目，需建立持续运营机制：密码证书定期更新（SM2证书有效期建议1-3年）、加密密钥年度轮换、每半年安全审计自查、每年至少一次等保和密评复评、跟踪国家密码管理局和中国密码学会密评联委会发布的最新FAQ和判定指南。