标签: 密评

  • 云计算服务安全评估2026全解:适用对象、评估维度与准备要点

    【摘要】

    云计算已成为党政机关与关键行业信息系统的主要承载方式,云平台的安全性直接关系到其上运行的业务与数据。《云计算服务安全评估办法》由多部门联合发布,旨在对党政机关、关键信息基础设施运营者采购使用的云计算服务开展安全评估,从云服务商背景、供应链安全、系统保护、应急响应与退出机制等维度提出要求。对湖南地区的云服务商、拟采购政务云或行业云的甲方单位以及系统集成商而言,理解评估的适用对象、关注维度与准备要点,是参与政务与关键行业项目的前提。本文梳理评估制度、审查维度、与等级保护及商用密码评估的关系,并给出准备建议。

    一、制度框架与适用对象

    (一)制度背景

    云计算服务的安全风险与传统的自建信息系统不同:多租户共享资源、数据存储位置不确定、供应链环节多、服务可迁移性差异大。为应对这些风险,《云计算服务安全评估办法》建立了面向特定用户的云计算服务安全评估制度。

    (二)适用对象

    评估主要面向两类采购主体:

    1. 党政机关:采购云计算服务用于政务信息系统的;
    2. 关键信息基础设施运营者:采购云计算服务承载关键业务的。

    对上述主体而言,采购的云计算服务应通过安全评估(或符合相应要求)。这也是招标文件中的常见资格条件。

    (三)评估的基本逻辑

    评估关注的不是”云服务商的技术参数有多强”,而是”能否保障采购方的数据与业务安全”。核心问题包括:云服务商能否被有效监管、供应链是否可控、数据能否被保护与迁移、服务终止时能否安全退出。

    二、评估关注的维度

    维度 核心关注 常见材料
    云服务商基本情况 背景、治理、监管可控性 股权结构、资质文件
    供应链安全 关键组件来源、供应链风险 组件清单、风险评估
    系统开发与维护 开发安全、变更管理 流程文件、记录
    系统与通信保护 网络与边界防护 安全方案、配置说明
    访问控制 身份与权限管理 权限模型、审计记录
    应急响应与灾备 预案、备份、演练 预案、演练报告
    审计与监控 日志与审计能力 日志方案、留存策略
    数据安全 加密、隔离、迁移、销毁 数据安全方案
    持续监控 风险监测与报告 监控机制

    (一)数据安全是核心

    数据安全是评估的重中之重,具体包括:数据存储位置是否明确、是否可被非授权访问、租户之间是否有效隔离、数据能否按要求迁移、服务终止后数据能否安全销毁。对采购方而言,”上得去、下得来”是可迁移性的通俗表达。

    (二)供应链安全

    云服务依赖大量软硬件组件,供应链风险可能来自组件漏洞、来源不可控、维护中断等。评估要求云服务商对关键组件进行梳理与风险评估,做到”说得清、管得住”。

    (三)退出机制

    服务终止时的退出安排常被忽视,但恰恰是评估关注的重点:数据如何提取、格式是否通用、过渡期如何安排、是否有锁定风险。甲方在合同中应明确约定退出条款。

    三、与等级保护、密码评估的关系

    (一)三类工作的定位

    工作 依据 侧重点
    网络安全等级保护 网络安全法及等保标准 系统的整体安全保护
    商用密码应用安全性评估 密码法及相关标准 密码技术应用与密钥管理
    云计算服务安全评估 云计算服务安全评估办法 云服务商与云平台的安全能力

    (二)不能相互替代

    三者侧重不同,不能相互替代。实际项目中,政务云平台通常需要同时满足等级保护要求、开展商用密码应用安全性评估,并在采购环节符合云计算服务安全评估的相关要求。

    (三)统筹实施建议

    建议在项目立项阶段就梳理清楚需要开展的安全评估事项与时间节点,统筹安排测评与整改,避免因某一项评估未完成而影响整体交付。

    四、云服务商与集成商的准备要点

    (一)把材料做在前面

    评估申报需要大量证明材料:安全管理制度、技术方案、测试报告、应急预案与演练记录等。建议建立常备资料包,按周期更新,避免临时拼凑。

    (二)把能力做实

    评估本质上是能力核验。云服务商应持续完善安全运营能力,包括漏洞管理、变更管理、事件响应与日志审计,而不是在评估前”突击改进”。

    (三)把合同条款设计好

    与甲方签订合同时,应明确:数据权属与使用边界、安全责任划分、服务可用性承诺、退出与数据迁移安排、安全事件通报机制。清晰的条款既保护甲方,也保护乙方。

    (四)把合规作为竞争力

    通过安全评估的云服务商,在政务与关键行业项目中具有明显优势。把合规能力转化为市场准入能力,是云服务商的长期策略。

    五、采购方的操作建议

    (一)明确需求与责任边界

    采购前明确需要承载的业务系统、数据敏感级别与安全要求,据此选择相应的云服务模式(公有云、私有云、混合云)。

    (二)核查合规资质

    在招标或采购环节核查云服务商是否具备相应安全评估结果,以及等级保护、密码应用等合规情况,避免”先采购后补合规”。

    (三)约定退出与迁移

    在合同中明确数据导出格式、迁移协助义务、过渡期安排与费用承担,降低锁定风险。

    (四)持续监督

    采购不是终点。应建立服务质量的持续监督机制,定期评估服务可用性、安全事件处置情况与合规状态变化。

    六、评估申报的实操流程

    (一)准备阶段

    梳理云平台的架构、组件、安全措施与运营流程,形成完整的技术与管理文档。这一阶段工作量最大,也是决定评估效率的关键。

    (二)申报与受理

    按要求提交评估申报材料,由评估机构受理并组织评估。材料应真实、完整,避免报一套、做一套。

    (三)评估与整改

    评估过程中可能提出整改要求。应建立整改台账,逐项落实并反馈。整改的彻底性直接影响评估结论。

    (四)持续符合

    通过评估不是终点。云平台的架构、组件或运营模式发生重大变化的,应重新评估合规状态。

    阶段 主要工作 建议安排
    准备 梳理与文档化 视平台复杂度确定
    申报 提交材料 预留受理周期
    评估 配合评估与整改 预留整改时间
    维护 持续符合性管理 常态化开展

    常见误区

    (一)把评估当成一次性认证

    评估反映的是特定时点的能力状态,平台架构、组件或运营模式变化后需要重新评估,不能一劳永逸。

    (二)只看技术不看管理

    安全能力既包括技术措施,也包括管理制度与运营流程。只堆设备、不建制度,很难通过评估。

    (三)忽视合同中的合规条款

    采购方若不在合同中明确合规要求与责任划分,后续出现问题时容易陷入被动。

    (四)低估退出成本

    数据迁移与系统切换的成本常被低估,应在采购阶段就把退出安排写清楚。

    给甲方单位的操作提示

    (一)明确系统分级

    按业务重要性与数据敏感度对系统分类,差异化选择云服务模式与安全要求,避免一刀切。

    (二)把要求写实

    在采购文件与合同中把安全要求、可用性指标、事件通报时限、数据归属与退出安排写成可考核的条款。

    (三)建立监督机制

    通过定期评估、事件复盘与合规状态跟踪,实现对云服务的持续监督,而不是签订合同就放手。

    结语

    云安全既是技术问题,也是治理问题。对甲方而言,把要求写进合同、把监督做成常态,是保障业务与数据安全最有效的方式;对云服务商而言,把合规能力做成产品能力,才能在政务与关键行业市场站稳脚跟。

    迁移与上云的安全衔接

    需要强调的是,上云过程中的安全风险往往高于稳定运行期。建议在迁移前完成数据分类、权限梳理与备份验证;迁移中做好访问控制与加密传输;迁移后开展安全验证与回归测试。对核心系统,建议采用分批迁移与灰度切换的方式,并保留回退方案,避免一次性切换带来的业务中断风险。

    同时,迁移期间应明确责任分工,形成书面的迁移方案与应急预案,确保出现问题能够快速响应。

    最后提示一点:安全评估的准备工作应当日常化。建议建立合规台账,把制度文件、测试报告与演练记录按周期更新归档,评估时即可从容应对、逐项举证,而不是临时突击整理材料。

    七、常见问题与应对

    (一)文档与实际不一致

    这是评估中最常见的失分点。建议建立文档、配置、运行三者的一致性核验机制。

    (二)多租户隔离说明不清

    需要清晰的隔离机制说明与验证材料,包括网络隔离、数据隔离与权限隔离,不能只停留在文字表述。

    (三)退出机制准备不足

    应提前设计并文档化数据导出格式、迁移路径与过渡期安排,避免服务变更时陷入被动。

    八、给政务云项目的建议

    (一)把合规要求写进采购文件

    在采购文件中明确云服务商应具备的合规条件,把安全评估、等级保护、密码评估等要求前置,避免先采购后补合规。

    (二)分期实施

    上云项目可分阶段推进,先迁移非核心系统,积累经验后再迁移核心业务,降低整体风险。

    (三)建立安全运营机制

    上云后应建立持续的安全运营机制,包括漏洞管理、日志审计、事件响应与定期演练,把安全能力常态化。

    常见问题

    问题1:哪些单位采购云计算服务需要关注安全评估?

    党政机关采购云计算服务用于政务信息系统、关键信息基础设施运营者采购云计算服务承载关键业务的,应关注云计算服务安全评估的相关要求。这也是相关项目招标中的常见资格条件。

    问题2:云计算服务安全评估与等级保护有什么区别?

    等级保护关注信息系统的整体安全保护水平,依据网络安全法与等保标准;云计算服务安全评估关注云服务商与云平台的安全能力,依据云计算服务安全评估办法。两者侧重点不同,不能相互替代,政务云项目通常需要同时满足。

    问题3:云服务合同要注意哪些条款?

    建议重点约定:数据权属与使用边界、数据存储位置、租户隔离要求、安全事件通报机制、服务可用性承诺、数据迁移与退出安排、费用与责任划分。其中退出与数据迁移条款最容易被忽视,却对长期风险影响最大。

    行动建议

    云计算服务安全评估的关键是”材料常备、能力做实、条款清晰”。建议云服务商建立常备的合规资料包并持续更新,把安全运营能力做成日常;建议采购方在立项阶段就梳理需开展的各类安全评估,把合规要求写进采购文件与合同,特别要把数据迁移与退出安排约定清楚,避免长期锁定。

    延伸阅读

  • 商用密码应用与安全性评估2026全解:密码分类、产品合规与密评实务

    【摘要】

    密码是网络安全的基石。《密码法》自2020年1月1日起施行,把密码分为核心密码、普通密码与商用密码三类,确立了分类管理的制度框架。2023年修订的《商用密码管理条例》(国务院令第760号)进一步细化了商用密码的检测认证、应用与监督管理要求。对湖南地区的信息系统建设与运营单位、密码产品与服务提供者而言,理解”哪些系统必须做密评””商用密码产品如何合规使用””密评怎么做”三件事,既是合规底线,也是项目验收与招投标的常见门槛。本文系统梳理密码分类、商用密码管理制度、商用密码应用安全性评估(密评)的流程与要点。

    一、密码的分类与法律框架

    (一)三类密码的定位

    类型 保护对象 管理部门
    核心密码 国家秘密信息 国家密码管理部门
    普通密码 国家秘密信息 国家密码管理部门
    商用密码 不属于国家秘密的信息 国家密码管理部门(市场化应用)

    核心密码与普通密码用于保护国家秘密,由密码管理部门严格管理;商用密码则面向社会,用于保护不属于国家秘密的信息,是企业和机构日常最常接触的一类。

    (二)法律与规章体系

    • 《密码法》:2020年1月1日施行,确立分类管理、商用密码市场化、关键信息基础设施密评等基本制度;
    • 《商用密码管理条例》(国务院令第760号,2023年修订施行):细化商用密码科研、生产、销售、服务、检测认证、应用与监督管理;
    • 配套标准:GB/T 39786《信息安全技术 信息系统密码应用基本要求》等,是密评的技术依据。

    (三)监管的核心逻辑

    商用密码监管遵循”放管服”与”安全底线”并重的思路:一方面取消商用密码产品生产单位审批、销售许可等事前许可,改为检测认证与事中事后监管;另一方面对关键信息基础设施提出强制性密评要求,把安全责任压到运营者身上。

    二、商用密码产品的合规使用

    (一)检测认证制度

    商用密码产品需通过具备资质的机构检测认证,列入商用密码产品认证目录的产品应取得认证证书。采购方在选择密码产品时,应核实产品的认证状态、适用范围与执行标准,避免使用来源不明、未认证的产品。

    (二)密码服务的合规

    提供商用密码服务(如电子认证、密码应用集成)的机构,需符合相应要求。使用密码服务时,应关注服务提供者的资质、密钥管理能力与责任约定。

    (三)电子认证服务与密码的关系

    电子认证服务依赖密码技术实现签名与验证。提供电子认证服务需取得许可,其使用的密码技术应合规。企业在选择电子签名、电子印章服务时,应确认服务方的合规资质与签名的法律效力依据。

    三、商用密码应用安全性评估(密评)

    (一)哪些系统要做密评

    关键信息基础设施应当使用商用密码进行保护,并开展商用密码应用安全性评估。此外,法律法规或主管部门要求开展密评的政务信息系统、重要行业信息系统,也应纳入评估范围。实践中,密评已成为不少政府项目、国企项目的验收前置条件。

    (二)密评的四个技术维度

    维度 核心要求 常见问题
    密码技术应用 使用合规的密码算法与产品 使用自研或未认证算法
    密钥管理 密钥全生命周期安全管理 密钥硬编码、明文存储
    密码服务 通过合规服务实现密码功能 以普通软件模拟密码功能
    安全管理 制度、人员、培训、应急 制度缺失、责任不清

    (具体要求以 GB/T 39786 等标准为准。)

    (三)密评的三个阶段

    密评不是一次性动作,而是贯穿信息系统生命周期的过程:

    1. 规划阶段:在系统设计初期就明确密码应用方案,编制密码应用方案并评估其合理性;
    2. 建设阶段:按方案实施密码应用,开展建设阶段密评;
    3. 运行阶段:系统上线运行后定期开展密评,形成常态化的评估与整改机制。

    未通过密评的系统,应限期整改;关键信息基础设施未按要求开展密评的,可能面临主管部门的通报与处罚。

    四、落地实施的关键动作

    (一)先做资产与系统梳理

    实施密码应用改造前,应梳理信息系统清单、数据分类分级情况与关键业务链路,明确哪些系统需要改造、需要保护哪些数据、涉及哪些环节。

    (二)再看方案与产品

    密码应用方案应由具备能力的单位编制,明确选用的算法、产品、密钥管理策略与部署方式。产品选择应遵循合规、适配、可持续维护三原则,避免为一次性验收而”买而不用”。

    (三)最后建制度与留痕

    密码应用不仅是技术问题,也是管理问题。应建立密码设备管理、密钥管理、人员权限、应急处置等制度,并保留密评报告、整改记录与运行日志,以备监督检查。

    五、给企业与机构的建议

    1. 把密评纳入项目计划:涉及政务、国企、关键行业的项目,应在立项阶段预留密评时间与预算,避免验收时被动;
    2. 区分强制与自愿:关键信息基础设施与法定要求的信息系统必须做,其他系统可根据风险与业务需要自愿开展;
    3. 不要”重产品轻管理”:大量问题出在密钥管理与制度落实上,技术采购解决不了管理缺失;
    4. 关注服务方资质:密码服务、密评服务的提供方应具备相应能力,合同中应明确交付物与责任。

    密码应用改造的实施路径

    (一)第一步:确定范围

    不是所有系统都需要做密评。建议先按”数据敏感度、业务重要性、合规强制要求”三个维度排序:处理重要数据、涉及大量个人信息的系统优先级最高;被主管部门明确要求开展密评的系统必须纳入;其他系统可结合风险自愿开展。范围确定后,应形成清单并明确责任部门。

    (二)第二步:梳理密码应用需求

    密码应用需求来自三个方面:一是法律法规与标准的要求;二是业务系统自身的防护需求,如身份鉴别、访问控制、数据完整性与保密性;三是风险管理要求,即针对已识别的风险点确定密码保护措施。把需求写成清单,避免为了用密码而用密码。

    (三)第三步:编制密码应用方案

    方案应包括系统概况与边界、安全需求分析、密码技术应用设计、密钥管理设计、产品选型与部署、改造实施计划、投资估算与验收方式。方案的质量直接决定后续改造的成败。

    (四)第四步:实施与密评

    按方案实施改造后进行建设阶段密评,评估通过后组织上线;上线运行后按周期开展运行阶段密评。

    阶段 主要工作 关键交付物
    规划 需求分析与方案编制 密码应用方案
    建设 设备部署与系统集成 实施方案、测试报告
    评估 建设阶段密评 密评报告
    运行 运行阶段密评与整改 年度评估报告

    (五)三个常见误解

    一是认为用了 HTTPS 就等于密码应用合规——传输加密只是其中一个维度,身份鉴别、密钥管理、数据完整性同样需要评估;二是认为买了密码产品就通过了——产品只是工具,方案合理性与管理落实才是关键;三是认为密评只是运维部门的事——密评涉及规划、建设、运行全流程,需要业务、技术、管理多方协同。

    总结与建议

    商用密码合规不是一次性的技术采购,而是一项持续的安全工程。建议企业与机构建立清单化、台账化、周期化的管理方式:清单化明确哪些系统需要保护,台账化记录密码产品与密钥使用情况,周期化开展密评与整改,把安全能力沉淀为组织能力。

    密评与信息系统的生命周期

    需要强调的是,密评不是项目验收的最后一道手续,而是贯穿系统生命周期的常态化工作。系统上线后,业务变化、技术演进与外部威胁都会带来新的风险,运行阶段的定期评估必不可少。建议把密评纳入年度安全工作计划,与等级保护测评、风险评估等工作统筹安排,避免重复投入、分散精力。

    此外,密评报告中的整改建议应转化为可执行的任务清单,明确责任人与完成时限,并在下一次评估时复核整改效果,形成评估、整改、复核的闭环。

    最后一点体会:密评的价值不在于报告本身,而在于它迫使组织系统地梳理信息安全短板。把每一次评估都当成一次体检,把整改建议转化为长期机制,安全水位才能持续提升。对中小企业而言,如果暂时不具备全面改造的条件,也应从最关键的系统和最敏感的数据入手,分步推进,而不是一拖了之。

    密评常见问题与整改要点

    (一)方案层面的问题

    常见问题包括方案未覆盖全部技术要求、密钥管理设计缺失、产品选型与方案不匹配。整改应从方案入手,避免打补丁式的局部修改,否则容易出现改了这处、漏了那处的情况。

    (二)实施层面的问题

    如密码设备未按要求配置、系统调用方式不合规、日志记录不完整。建议在建设阶段先开展自测,提前发现问题,避免正式评估时集中暴露。

    (三)管理层面的问题

    如制度缺失、密钥管理无台账、人员培训无记录。管理类问题整改成本低,但最容易被忽视。建议优先补齐,因为管理缺失往往导致技术措施难以持续有效。

    (四)整改的组织方式

    建议组建跨部门整改小组,明确责任人与时限,形成整改台账并逐项验收。整改完成后应重新评估,确保问题闭环,并保留完整的过程记录。

    给决策者的三点提示

    一是密评不是技术部门的独角戏,需要业务与管理部门共同参与,否则容易出现技术与业务两张皮。二是应预留足够的时间与预算,避免临近项目验收时仓促整改。三是把密评成果沉淀为制度与流程,而不是一次性应付,让安全能力真正留在组织内部。

    常见问题

    问题1:所有信息系统都必须做商用密码应用安全性评估吗?

    不是。法律法规明确要求开展密评的主要是关键信息基础设施,以及主管部门另有规定的信息系统。其他系统可结合自身风险与业务需要自愿开展。但若项目招标文件或验收标准提出密评要求,则应按规定执行。

    问题2:商用密码产品还有生产许可和销售许可吗?

    在”放管服”改革后,商用密码产品的生产单位审批与销售许可已取消,改为检测认证与事中事后监管。采购方应关注产品是否通过合规检测认证,而不是只看是否”有许可”。

    问题3:密评不通过会有什么后果?

    关键信息基础设施未通过密评且未按期整改的,主管部门可依法采取通报、约谈、限期整改等措施;对政府投资或国企项目,密评结果往往与项目验收、资金拨付挂钩。因此建议在项目计划阶段就预留整改时间。

    行动建议

    商用密码合规的关键是”合规产品+合规方案+合规管理”三条腿走路。建议企业从系统梳理入手,识别需要保护的数据与系统,编制密码应用方案,选用通过认证的产品,并按规划、建设、运行三个阶段落实密评。对涉及政务与关键行业的项目,把密评纳入合同与验收条件,是最稳妥的做法。

    延伸阅读