很多企业第一次接触 EAL4+ 测评认证 ，往往不是从标准开始，而是从客户准入、项目招投标、信创采购或行业测评要求中看到一句话："产品需通过 EAL4+ 认证"。
在国内下，企业常说的 EAL4+ 测评认证 ，通常指向 CCRC IT 产品信息安全认证中的评估保障级 EAL4 增强级认证。CCRC 官网已将"评估保障级（EAL）认证"作为 IT 产品信息安全认证业务之一，并发布相应实施规则、申请书和产品依据标准列表等文件。
一、什么是国内 EAL4+ 测评认证？
EAL 是 Evaluation Assurance Level 的缩写，通常译为评估保障级。它不是直接描述产品"有多少安全功能"，而是描述这些安全功能经过了多大程度的设计、开发、测试、审查和验证。
国内 EAL 认证主要依据 GB/T 18336《网络安全技术 信息技术安全评估准则》体系开展。国家标准公开系统显示，GB/T 18336.3-2024 为《网络安全技术 信息技术安全评估准则 第3部分：安全保障组件》，已于 2024 年 4 月 25 日发布，并于 2024 年 11 月 1 日实施。
简单来说，EAL4+ 测评认证关注的是：企业声称产品具备哪些安全能力，这些能力有没有被清晰定义、正确实现、充分测试，并且是否具备相应的开发和交付过程证据。
这里的 "+" 一般表示在 EAL4 基础上增加了增强保障组件，例如更高要求的漏洞分析、生命周期支持或其他特定产品技术要求。不同产品类别对应的增强项可能不同，不能简单理解为所有产品的 EAL4+ 都完全一样。
二、哪些产品常见需要做 EAL4+？
国内 EAL4+ 常见于政企采购、行业准入、信创项目、关键行业客户要求以及部分招投标场景。常见产品包括：
| 产品类型 | 常见场景 |
|---|---|
| 操作系统 | 信创、政企采购、行业信息化平台 |
| 数据库 | 金融、政务、能源、运营商等项目 |
| 中间件 | 应用支撑平台、业务系统底座 |
| 云平台组件 | 虚拟化、容器、云管平台、核心组件 |
| 网络安全产品 | 防火墙、网关、安全管理类产品 |
| 芯片及安全芯片 | 高安全终端、密码相关产品 |
| 智能终端系统 | 终端操作系统、嵌入式系统 |
| Hypervisor / 虚拟化产品 | 云计算、车载、边缘计算等场景 |
需要注意的是，不是所有产品都天然适合直接申请 EAL4+。是否适合申请，取决于产品类别、适用技术要求、客户要求、产品成熟度、文档基础以及企业能否支撑对应等级的证据要求。
三、国内 EAL4+ 测评认证的基本流程
1. 前期判断：确认客户到底要什么证书
企业拿到客户要求后，第一步不是立刻准备材料，而是先确认：
客户要求的是不是 国内 CCRC EAL4+ ？
是否限定产品类别？
是否指定依据标准或技术要求？
是否接受同类产品证书？
证书主体、产品名称、版本号是否有要求？
2. 产品范围梳理：确定 TOE 边界
EAL 项目中有一个核心概念叫 TOE，即 Target of Evaluation，评价对象。
通俗理解，TOE 就是本次被评价的产品范围。它需要明确：
哪些模块属于本次认证范围？
哪些模块只是运行环境或外部依赖？
产品部署形态是什么？
管理端、客户端、服务端是否都纳入？
第三方组件是否纳入？
哪些接口、协议、配置属于安全边界？
很多项目卡住，不是因为产品没有安全功能，而是因为TOE 边界一开始没有定义清楚。边界过大，证据难以闭合；边界过小，又可能无法满足客户要求。
3. 编写 ST：形成安全目标文件
ST，即 Security Target，通常译为安全目标。它是 EAL 测评中的核心文件之一。
ST 需要说明：
产品是什么；
评价范围是什么；
产品运行环境是什么；
产品面临哪些威胁；
需要满足哪些安全目标；
产品具备哪些安全功能；
对应哪些安全功能要求和安全保障要求。
可以把 ST 理解为整个认证项目的"总纲"。后续设计文档、测试证据、漏洞分析和实验室评价，都会围绕 ST 展开。
如果 ST 写得过宽，产品需要证明的内容会变多；如果写得过窄，又可能无法覆盖客户关注点。因此，ST 不是简单套模板，而是需要结合产品实际功能、目标等级和适用技术要求进行设计。
4. 资料准备：补齐设计、开发、测试和交付证据
EAL4+ 的重点不只是"产品有没有安全功能"，还包括这些功能是否有充分证据支撑。
企业通常需要准备以下材料：
| 材料类别 | 主要内容 |
|---|---|
| 产品基础材料 | 产品说明、版本信息、部署架构、运行环境 |
| TOE 范围材料 | 产品边界、组件清单、接口说明、外部依赖 |
| ST 安全目标 | 威胁、安全目标、安全功能要求、保障要求 |
| 功能规格文档 | 安全功能说明、接口行为、用户角色、权限逻辑 |
| 设计文档 | 总体设计、模块设计、子系统设计、数据流说明 |
| 测试材料 | 安全功能测试、测试用例、测试结果、缺陷记录 |
| 配置管理材料 | 版本管理、代码管理、构建记录、变更记录 |
| 交付运行材料 | 安装手册、运维手册、安全配置指南 |
| 漏洞分析材料 | 已知漏洞排查、脆弱性分析、整改说明 |
| 开发过程材料 | 开发规范、缺陷管理、发布流程、生命周期证据 |
企业常见的问题是：产品已经开发多年，但相关过程文档没有按认证要求沉淀。此时就需要围绕 TOE 和 ST 重新梳理证据，而不是简单把已有研发文档打包提交。
5. 送测与实验室评价
材料初步完成后，产品进入测评环节。实验室会围绕 ST、设计文档、测试材料和实际产品进行审查与验证。
通常会关注：
ST 是否合理；
安全功能是否与产品实现一致；
设计文档是否能支撑安全功能；
测试用例是否覆盖安全功能；
配置管理和交付文档是否完整；
产品是否存在可被利用的安全缺陷；
漏洞分析是否充分。
EAL4+ 项目中的测评沟通往往是多轮的。实验室提出问题后，企业需要补充说明、修改文档、调整配置或进行产品整改。
6. 整改与闭环
整改阶段通常包括两类工作：
一类是文档整改，例如 ST 表述不准确、设计文档不完整、测试证据缺失、术语不统一。
另一类是产品整改，例如安全功能实现与文档描述不一致、默认配置不安全、日志记录不足、权限控制逻辑存在问题、接口暴露不合理等。
认证项目能否顺利推进，很大程度上取决于企业能否快速完成问题闭环。
7. 认证审核与取证
测评完成后，相关评价结果进入认证审核流程。通过后，企业可获得对应产品、版本和等级的认证证书。
需要注意的是，证书通常会明确产品名称、型号/版本、申请组织、依据标准和技术要求等信息。后续如果产品发生重大版本变化、架构变化或安全功能变化，可能需要重新评估是否影响证书有效性。
四、企业做 EAL4+ 前应重点准备哪些材料？
1. 产品说明类材料
包括产品简介、功能清单、部署架构、运行环境、版本说明、典型应用场景等。
这类材料用于帮助评估人员理解产品是什么、怎么部署、谁来使用、承担什么安全功能。
2. 安全功能说明材料
这部分是 EAL 项目的重点。企业需要说明产品具备哪些安全功能，例如：
身份鉴别；
访问控制；
安全审计；
用户权限管理；
数据保护；
通信保护；
配置管理；
安全告警；
日志留存；
接口访问控制；
升级与完整性保护。
不要只写"支持安全审计""支持权限管理"，而要说明具体机制、角色、规则、触发条件、配置方式和验证方法。
3. TOE 边界材料
TOE 边界材料需要回答一个问题：
本次认证到底评价产品的哪一部分？
例如一个数据库产品，是否包含管理工具？是否包含客户端？是否包含插件？是否包含底层操作系统？是否包含第三方组件？这些都需要明确。
TOE 边界越清晰，后续 ST、设计文档和测试工作越容易闭合。
4. 设计与开发材料
EAL4+ 对设计文档的要求明显高于普通测试项目。企业需要提供能够支撑安全功能实现逻辑的设计证据。
例如：
安全架构设计；
模块划分；
接口说明；
权限模型；
审计机制；
数据流向；
安全功能调用关系；
关键安全机制实现说明。
这部分最容易暴露企业研发文档不规范的问题。
5. 测试与漏洞分析材料
企业不仅要准备已有测试报告，还要能说明测试如何覆盖 ST 中声明的安全功能。
常见材料包括：
测试计划；
测试用例；
测试环境；
测试数据；
测试结果；
缺陷记录；
漏洞扫描记录；
漏洞分析说明；
整改闭环记录。
EAL4+ 不只是看有没有测试，而是看测试是否与安全功能要求对应、结果是否可复现、缺陷是否闭环。
6. 交付与运维材料
认证项目也会关注产品交付后的安全使用方式。
例如：
安装手册；
管理员指南；
安全配置指南；
运维手册；
升级说明；
默认账号和口令策略；
安全加固建议；
日志查看和备份方式。
如果产品本身具备安全功能，但交付文档没有说明如何正确启用和配置，也可能影响评价结果。
五、国内 EAL4+ 常见问题
问题一：EAL4+ 是不是等级越高越好？
不一定。
EAL 等级越高，通常意味着评价深度、证据要求和项目成本更高。但企业是否需要 EAL4+，要看客户要求、产品类型、行业场景和项目预算。
对于很多企业来说，关键不是盲目追求高等级，而是选择与产品定位和客户准入要求匹配的认证路径。
问题二：EAL4+ 是不是等于渗透测试？
不是。
渗透测试主要关注产品是否存在可利用漏洞，而 EAL4+ 是一套系统性安全评价。它不仅关注漏洞，还关注安全功能定义、设计实现、测试覆盖、配置管理、交付过程和开发证据。
可以理解为：渗透测试只是安全验证的一部分，EAL4+ 要证明的是产品安全能力的完整性和可信度。
问题三：产品已经上线多年，还能做 EAL4+ 吗？
可以，但要看产品文档和研发过程是否能支撑。
很多成熟产品功能没有问题，但缺少认证所需的设计文档、测试证据、配置管理记录和安全功能说明。这种情况下，通常需要先进行材料补齐和证据重构。
问题四：EAL4+ 认证周期一般多久？
周期取决于产品复杂度、资料基础、产品整改量、实验室排期和认证审核进度。
如果企业产品边界清晰、文档基础较好、安全功能稳定，周期会更可控；如果一边开发一边补材料，或者 TOE 范围反复调整，周期就容易被拉长。
问题五：ST 文件可以直接套模板吗？
不建议。
ST 是整个 EAL 项目的核心文件，必须与产品实际安全功能、运行环境、客户要求和适用技术要求对应。模板只能作为结构参考，不能代替产品分析。
很多项目后期返工，就是因为 ST 前期写得过宽、过虚或与产品实现不一致。
问题六：产品版本变化会不会影响证书？
可能会。
如果只是小版本修复，影响相对有限；如果涉及安全功能、系统架构、认证边界、核心模块或运行环境变化，就需要评估是否影响原证书范围。
因此，企业在认证前要谨慎确定产品版本，避免认证过程中频繁变更。
六、企业启动 EAL4+ 前的建议
企业在正式申请 EAL4+ 之前，建议先完成三件事：
第一，确认认证路径 。
明确客户要求的是国内 CCRC EAL4+，还是国际 CC EAL4+，避免方向错误。
第二，梳理 TOE 边界 。
不要一上来就把整个系统都纳入认证范围，而要结合客户要求、产品架构和证据能力确定合理边界。
第三，评估资料成熟度 。
提前检查 ST、设计文档、测试材料、配置管理、交付文档和漏洞分析材料是否具备基础。
EAL4+ 测评认证的难点不只是"测"，更在于把产品安全能力用标准化语言表达出来，并用完整证据证明出来。
七、结语
国内 EAL4+ 测评认证，本质上是一项产品安全能力的系统化证明工作。它要求企业不仅要有安全功能，还要能够说明安全功能的边界、设计依据、实现方式、测试结果和交付保障。
对于已经遇到客户准入、招投标或行业采购要求的企业来说，越早启动认证路径判断、TOE 边界梳理和材料准备，后续项目推进就越可控。
浙江望安科技有限公司长期围绕 CC/EAL、国内 CCRC EAL、EUCC、CRA 合规与形式化验证开展项目服务，可协助企业完成产品认证路径判断、TOE 边界规划、ST 安全目标梳理、材料体系搭建以及测评沟通支持，帮助企业把复杂的 EAL4+ 要求转化为可推进、可验证、可落地的认证工作。