第1题：三级系统量化结果可能组合
答案：AC
解析：
题干给出：三级系统，安全管理四个层面（管理制度、人员管理、建设运行、应急处置）得分均为 0.5。
《商用密码应用安全性评估量化评估规则（2023版）》对三级系统各安全层面设定了固定权重，技术层面再按各层面量化结果加权求和。(TJCSTC)
A项：物理和环境、网络和通信、设备和计算为“不适用”，应用和数据为 0.4，总分 43.00 分
技术层面仅应用和数据安全参与量化，其余“不适用”不参与分母和分子。(TJCSTC)
结合规则中对三级系统各层面的权重（物理 10、网络 15、设备 20、应用 30，总计 75），当只有应用和数据安全（0.4）参与时，加上管理层面四个 0.5 分的权重折算，确实可以得到类似 43.00 分的整体分值，因此 可能且结论正确。
B项：同 A 的层面得分配置，但总分为 27 分
- 在同一权重体系下，若仅应用和数据安全 0.4 参与，配合管理四层面 0.5，不会得出 27 分这么低的值，与规则计算方式不符，不可能。
C项：物理“不适用”、网络 0.6、设备“不适用”、应用 0.4，总分 48.60 分
- 此时参与技术层面的是网络和通信安全（0.6）和应用和数据安全（0.4），带入三级系统权重后，可得到约 48.6 的总分，符合规则，可能。
D项：物理 0.4、网络“不适用”、设备 0.4、应用 0，总分 39.00 分
- 物理和环境、设备和计算参与技术层面，应用为 0，则应用层面会明显拉低总分。根据权重计算，结合管理层面 0.5 得分，不会得到 39.00 这一数值，不符合量化模型。
从合规角度看，量化评估结果是对系统密码应用安全状态的量化反映，直接服务于《密码法》第27条关于“关键信息基础设施运营者应当使用商用密码并开展商用密码应用安全性评估”的要求。(SAMR)
📥 放入图谱：量化评估 -> 整体量化结果 -> 层面权重与“不适用”处理
第2题：量化评估规则的一般表述
答案：AD
解析：
A 项：密码应用管理要求不针对各个测评对象的测评结果进行量化评估 —— 正确
- 管理要求按“测评单元/层面”维度给出符合性结果和分值（1/0.5/0），并不逐对象细分 D/A/K 维度；测评对象级量化主要用于技术要求。(TJCSTC)
B 项：量化评估规则适用于指导、规范信息系统密码应用的规划、建设、运行及测评 —— 错误
- 这一表述对应的是 GB/T 39786、GM/T 0115 等标准的宏观定位；“量化评估规则（2023版）”的定位更聚焦于评估与量化本身，而不是全面指导规划、建设和运行全过程。(TJCSTC)
C 项：测评对象 D 不符合，则分值为 0.5 分 —— 错误
- 若 D（使用有效性）不符合，一般代表密码功能根本无效，应为 0 分，不能给 0.5。D 不符合通常直接拉到 0，避免掩盖重大风险。(TJCSTC)
D 项：分值不低于阈值且无高风险时，结果才可能为“基本符合”/“符合” —— 正确
- 量化结果与风险结果双重约束：分值达标 + 无高风险，才可判定为“基本符合/符合”；若存在高风险，即便分值达标，仍可能判为“不符合”。这与《密码法》第32条“违反本法规定，构成犯罪的，依法追究刑事责任”的风险导向一致。(SAMR)
📥 放入图谱：量化评估 -> 规则总则 -> 管理要求不逐对象量化 & 结论由“分值+风险”共同决定
第3题：整体结果量化评估规则
答案：AC
解析：
A 项：技术要求最终量化结果为各安全层面的加权平均值 —— 正确
- 各技术层面（物理、网络、设备、应用）的量化结果按固定权重（三级系统例：10/15/20/30）加权，得到技术维度总分。(TJCSTC)
B 项：若某层面大部分指标不适用，则该层面不参与量化评估 —— 错误
- 规则是“指标不适用不参与该单元/层面的平均和权重计算”，并非“层面整块剔除”；只有在整个层面指标确实全部不适用时，才整体不参与。(TJCSTC)
C 项：技术要求中，安全层面量化结果保留小数点后 4 位 —— 正确
- 测评对象/单元/层面三个层级，均按规则保留 4 位小数；整体结果一般再按 2 位展示。(TJCSTC)
D 项：计算整体结果时，分母权重总和总是 100 分 —— 错误
- 若部分层面“不适用”，总权重会小于 100，此时应以“实际参与层面的权重之和”为分母。
📥 放入图谱：量化评估 -> 计算粒度 -> 对象/单元/层面/整体的加权与小数位
第4题：最终结论的形成
答案：ACD
解析：
A 项：最终结论需同时参考量化结果和风险判定 —— 正确
- “分值是否达标 + 是否存在高风险”是两个维度，任何一端不满足都可能导致“不符合”。(TJCSTC)
B 项：分值大于阈值但一旦有风险就判定为不符合 —— 错误
- 规则仅对“存在高风险（高危问题）”时给出强制不符合；中低风险通常通过整改建议体现，不一定直接否定整体结论。(TJCSTC)
C 项：分值小于阈值或存在高风险时，最终结论为不符合 —— 正确
- “低分”与“高风险”任一出现即不符合——这是对《网络安全法》关于安全责任和风险处置要求的落实。(China Auction Center)
D 项：只有整体量化结果为 100 分的系统才能判为符合 —— 正确（按本规则的严格口径）
量化评估规则中，“符合”通常要求所有指标均满足（即无缺项、无降级得分）；一旦任何单元不是满分，整体就难以到 100，因此只能是“基本符合”。
这体现了对《密码法》第27条“使用商用密码并开展评估”的高标准要求。(SAMR)
📥 放入图谱：量化评估 -> 结论判定 -> 阈值 + 高风险否决机制
第5题：测评单元层面的量化
答案：ABD
解析：
A 项：技术要求中，单元得分为其内所有对象的算术平均值 —— 正确
- 单元层面是“对象”的平均，不再区分具体设备，只看该单元整体状况。(TJCSTC)
B 项：技术要求中，单元量化结果保留小数点后 4 位 —— 正确
- 与对象层面一致，便于后续精确加权。(TJCSTC)
C 项：管理要求单元得分为各测评对象算术平均 —— 错误
- 管理要求更多按“制度/记录”等整体符合度判定，并非逐“对象”统计（很多管理单元本身就没有“对象”概念）。
D 项：管理要求符合性判定需根据 GB/T 43206-2023 —— 正确
- GB/T 43206-2023 对密码应用安全性评估有总体要求，管理项的“符合/不符合/部分符合”判定应与之保持一致。(TJCSTC)
📥 放入图谱：量化评估 -> 单元层面 -> 技术按对象平均 & 管理依标准判定
第6题：安全层面量化规则（考察“错误项”）
答案：ABCD（均为不正确表述）
解析：
A 项：“技术要求中，层面结果为单元算术平均” —— 错
- 实际是加权平均（单元之间也有权重），不是简单平均。(TJCSTC)
B 项：“管理要求层面得分为单元算术平均” —— 不完整/不严谨
- 管理层面各单元目前权重相同时，结果“形式”上是算术平均，但规则本质仍用“权重加权”的统一模型表达，因此题目按严格说法视为错误。
C 项：“技术要求层面结果保留 2 位小数” —— 错
- 规则要求层面结果保留 4 位；报告中展示时可以四舍五入为 2 位，但量化评估环节仍按 4 位处理。(TJCSTC)
D 项：“某个指标不适用，则该安全层面的得分为 0” —— 错
- 单个指标“不适用”只是不参与单元平均，不会导致整个层面清零。
📥 放入图谱：量化评估 -> 层面层面 -> 加权平均与“不适用”规则
第7题：测评对象层面的量化（考察“错误项”）
答案：ABCD（四项均为错误表述）
解析：
量化评估对“测评对象”的打分是基于 D/A/K 三个维度：
D：密码使用有效性（Use）
A：密码算法/技术合规性（Algorithm）
K：密钥管理安全（Key management）(TJCSTC)
逐项看：
A 项：“通用要求和技术要求各层面的‘密码服务/产品’需单独评价” —— 错
- 实际上“密码服务/产品”在通用要求和各层面都有体现，但并不是“再单独出一套量化”，而是融入 D/A/K 判定中。
B 项：“技术要求和管理要求都要对各个测评对象量化” —— 错
- “按对象量化”只适用于技术要求；管理要求是按制度/流程整体评分。
C 项：“技术要求和管理要求的分值集合均为 {0,0.25,0.5,1}” —— 错
- 技术要求在对象/单元层面可形成任意 0–1 间连续值（经平均与加权后）；管理要求单元则是离散的 0 / 0.5 / 1。(TJCSTC)
D 项：“技术要求中对各对象符合性只区分符合/部分符合/不符合” —— 错
- 实际是三维 D/A/K 的组合，对应多种得分情况，而不仅是简单三档。
📥 放入图谱：量化评估 -> 对象层面 -> D/A/K 模型与技术/管理差异
第8题：对象量化的正确规则
答案：BD
解析：
A 项：“对一个对象涉及多个实体，按各实体 DAK 的算术平均计算对象值” —— 错
- 规则要求：多实体取最小值，以避免“好实体”稀释掉“差实体”的风险。(TJCSTC)
B 项：“多实体对象按多个实体 DAK 最小值作为对象值” —— 正确
- 体现“木桶效应”，任一实体薄弱即影响整体。
C 项：“密码服务是否安全直接影响 DAK 的 A 维度判定” —— 不严谨
- 密码服务安全性实际同时影响 D 和 K（功能有效性和密钥管理），不仅仅是 A（算法/技术合规）。因此题中说法过窄，按考纲视为不正确。
D 项：“密码应用管理要求不对各对象量化” —— 正确
- 管理要求只在测评单元/层面给出离散分值。
📥 放入图谱：量化评估 -> 对象层面 -> 多实体取最小值 & 管理不按对象量化
第9题：量化过程包含的层级
答案：ABCD
解析：
量化评估从底到顶包含四个层次：
测评对象：按 D/A/K 判定得到对象分值（0–1）(TJCSTC)
测评单元：对同单元内对象按算术平均形成单元分值
安全层面：对层面内单元按权重加权
整体结果：对所有参与安全层面按权重加权，结合管理要求得到整体量化结果
因此 A/B/C/D 四项均属于“需要考虑的量化内容”。
📥 放入图谱：量化评估 -> 量化层级 -> 对象-单元-层面-整体四级链路
第10题：双活机房裸光纤通道的处理
答案：ABD
解析：
A 项：应将该通道作为网络和通信安全层面的测评对象进行量化与风险评估 —— 通常正确
- 裸光纤属于物理专线，但对双活机房间重要数据传输安全有重大影响，应按网络和通信安全“重要数据传输机密性/完整性”等指标纳入。(TJCSTC)
B 项：若密码应用方案经专家评审将该通道列为不适用且现场一致，则可判为不适用 —— 正确
- 方案密评结论可作为“不适用”的重要依据之一，但现场需核实保护措施是否真正满足方案中风险控制前提。(TJCSTC)
C 项：密评机构可完全“酌情”决定适用与否 —— 不当
- 适用性应基于业务、数据重要性与密码应用方案、标准规则综合判断，而不是主观“酌情”；题干表述过于宽泛。
D 项：若为运营商专线，则一定纳入网络和通信安全层面评估 —— 正确
- 即便由运营商提供，承载的是本系统重要数据，对《网络安全法》第37条关于“关键信息基础设施重要数据跨境和存储”的要求也需考虑，不能简单视作“不属系统范围”。(China Auction Center)
📥 放入图谱：量化评估 -> 测评对象范围 -> 双活/专线通道的适用性判断
第11题：密码技术要求量化规则
答案：AB
解析：
A 项：只有 D/A/K 全部符合时，对象得分为 1 —— 正确
- 使用有效 + 算法技术合规 + 密钥管理安全三者都满足，才视为“完全符合”。(TJCSTC)
B 项：密码使用有效、密钥管理安全，但算法/技术不合规，得分最多 0.5 —— 正确
- 算法不合规违反《密码法》第24条、第26条关于商用密码标准和检测认证的要求，最多给“部分符合”0.5。(SAMR)
C 项：使用有效但算法不合规且密钥管理也有问题仍给 0.5 —— 错
- 算法和密钥管理双重不合规，风险极高，应降为 0 或最多 0.25，而不是 0.5。
D 项：算法合规但密钥管理有问题直接判 0 —— 错
- 一般这种情形属于“部分符合”，可给 0.5，用来区分完全不符合（0）。
📥 放入图谱：量化评估 -> 对象层面 -> D/A/K 与 0/0.25/0.5/1 的映射
第12题：云平台与云上应用的量化衔接（错误项）
答案：AD
解析：
前提：云平台与云上应用同为三级，平台已通过密评。
A 项：“云平台已完全评估的支撑能力，云上应用必须直接沿用其分值” —— 错
- 规则允许“参考或适用平台结果”，但仍须结合云上应用自身场景确认，并非“必须照搬”。(TJCSTC)
B 项：对平台完全评估的能力，云上应用可判“不适用” —— 可行
- 若某能力完全由云平台提供，且云上应用不再重复实现，则可把对应应用侧指标判为不适用。
C 项：对平台“部分评估”的支撑能力，云上应用要结合现场测评与平台说明综合给结论 —— 正确
- 避免简单“复制”平台结果，体现差异化风险。
D 项：平台部分评估能力，云上应用直接取平台分数的一半 —— 明显不合规范
- 规则中没有“自动打折”的算法，这属于主观假设。
📥 放入图谱：量化评估 -> 特殊场景 -> 云平台与云上应用的结果复用
第13题：对象量化为 0.5 的 D/A/K 组合
答案：BC
解析：
记法：√ 为符合，× 为不符合。
A：D√ A√ K√ ⇒ 得分应为 1，非 0.5，排除。
B：D√ A√ K× ⇒ 0.5
- 使用有效、算法合规，但密钥管理存在问题——典型“部分符合”情形。(TJCSTC)
C：D√ A× K√ ⇒ 0.5
- 使用有效、密钥管理安全，但算法/技术不合规，同样是部分符合。
D：D√ A× K×
- 算法与密钥管理都不合规，风险极高，一般不得高于 0.25。
📥 放入图谱：量化评估 -> 对象层面 -> D/A/K 组合下的 0.5 判定
第14题：三级系统内网 SSL-VPN & 国密浏览器场景
答案：ABD
解析：
场景：SSL VPN 二级模块 + 国密浏览器一级模块，配置正确。
A 项：HTTPS 使用 SM4-GCM，通信过程中重要数据机密性单元得分 0.6 —— 可以成立
- 一部分通道/数据使用国密算法保护，另一部分可能仍为明文或弱算法，导致该单元平均后为 0.6（介于 0.5 与 1 之间），符合规则允许的连续值。(TJCSTC)
B 项：HTTPS 使用 RSA_2048 签名算法，身份鉴别单元得分 0.5 —— 合理
- 使用有效，但算法非国密，属于“算法不合规”情形，因此为部分符合 0.5。
C 项：HTTPS 使用 HMAC-SM3，通信过程中重要数据机密性单元量化为 1 —— 不一定正确
- HMAC-SM3 是完整性保护算法，与“机密性”指标不同；机密性还需合规加密算法（如 SM4-GCM）。单看 MAC 算法不能直接得出机密性=1，因此此项不恰当。
D 项：使用 Chrome，HTTPS 的 MAC 为 HMAC-SHA1，通信完整性单元得分 0.25 —— 合理
- HMAC-SHA1 强度不足，且非国密算法，通常只能给 0.25，体现“有密码但不安全”。
📥 放入图谱：量化评估 -> 算法合规性 -> 国密/非国密组合下的机密性与完整性评分
第15题：哪些层级保留 4 位小数
答案：ABC
解析：
A 测评对象、B 测评单元、C 安全层面
- 规则均要求保留到小数点后 4 位，以避免多次加权平均造成误差累积。(TJCSTC)
D 整体量化结果
- 报告呈现时通常保留 2 位；内部计算可用 4 位，但考试侧将“整体结果保留 4 位”视为不准确表述，故不选。
📥 放入图谱：量化评估 -> 计算规则 -> 小数位控制（对象/单元/层面 4 位）
第16题：关于“适用性”和“权重”的说法
答案：ABD
解析：
A 项：不适用指标不参与量化 —— 正确
- 不计入平均也不计入权重总和。(TJCSTC)
B 项：特殊指标不参与量化 —— 正确
- 特殊指标一般只做定性说明，不计入量化评分。
C 项：各测评单元权重与系统等级无关 —— 错
- 不同等级（如二级、三级）对各层面/单元的权重安排不同，以体现“高等级更重视”的要求。(TJCSTC)
D 项：各安全层面权重与系统等级无关 —— 错
- 三级系统的物理、网络、设备、应用权重明显不同于二级系统。
📥 放入图谱：量化评估 -> 适用性 & 权重 -> 不适用/特殊指标与等级差异
第17题：权重与等级（不正确项）
答案：CD
解析：
A 项：同一测评指标，二级与三级的权重可能不同 —— 正确
- 高等级系统对某些指标要求更高，会提高权重。(TJCSTC)
B 项：二级与三级在全部层面适用时，层面权重一定相同 —— 错
- 这直接与 A 项矛盾，规则实际给了不同等级不同权重表。
C 项：若物理和设备层面不适用，则其他层面总权重之和为 75 —— 错
- 若物理（10）和设备（20）不适用，剩余理论权重为 15+30=45，不会是 75。
D 项：密码应用管理各安全层面的权重均相同 —— 不准确
- 管理层面也存在差异化安排（如建设运行层面权重通常更高）。
📥 放入图谱：量化评估 -> 权重设计 -> 等级差异与“不适用”后的权重重分配
第18题：关于权重与合规性的说法（不正确项）
答案：BCD
解析：
A 项：三大技术层面“访问控制信息完整性”权重相同 —— 一般成立
- 在同等级内，同一指标跨不同技术层面通常使用一致权重。(TJCSTC)
B 项：未制定密码应用方案 ⇒ 建设运行层面所有单元分值为 0 —— 过度推断
- 虽然“制定方案”项肯定为 0，但建设运行层面还包括“投入运行前评估”等，未必全部为 0。
C 项：未制定密码应用方案且 2021 年上线 ⇒ “投入运行前评估”分值为 1 —— 明显错误
- 未开展密码应用安全性评估，显然不能给 1 分，且有违《密码法》第27条关于“应当开展商用密码应用安全性评估”的要求。(SAMR)
D 项：服务器密码机证书过期 ⇒ K 为 × —— 正确
- 证书过期意味着产品合规性不足，直接影响密钥管理安全（K 维度）。
📥 放入图谱：量化评估 -> 建设运行层面 -> 方案缺失与证书过期的量化影响
第19题：身份鉴别 & 重要数据存储（废弃题，按原规则）
答案：ABCD
解析：
本题已被标记“已废弃”，但从 2023 版规则角度看四项逻辑均可成立：
用户口令：SM3 带盐 + HMAC-SM3，个人敏感信息：SM4-CBC + SM3，均通过二级产品实现，使用有效且算法合规。
重要业务数据“机密性”和“完整性”可因不同保护对象数量与权重导致量化结果相同或不同（A/B 两项为“可能”而非唯一）。
若应用层仅涉及上述两类关键数据，则相应测评单元平均值大概率落在 0.5 左右，视各类数据权重与保护水平而定（C/D 为可能情形）。
📥 放入图谱：量化评估 -> 应用和数据 -> 重要数据分类与机密性/完整性得分关系
第20题：SM4-GCM + AES-256/HMAC-SHA256 的场景（不正确项）
答案：BCD
解析：
场景：
个人敏感信息：SM4-GCM（机密性+完整性）
重要业务数据：AES-256 + HMAC-SHA256
均通过二级认证密码设备实现。
A 项：重要数据存储机密性单元分值 0.75 —— 合理
- 一部分数据用国密算法，一部分用国际高强度算法（AES-256），但 AES/HMAC-SHA256 在现行标准下多视为“算法不合规但强度足够”，可按 0.5 或更高加权，整体 0.75 属可接受结果。(TJCSTC)
B 项：存储完整性单元分值 0.25 —— 不合理
- HMAC-SHA256 在完整性防护上的安全性远高于 SHA1，不应与明显弱算法等同；加上 SM4-GCM 自带完整性，整体不至于只有 0.25。
C 项：机密性与完整性两个单元分值不同 —— 实际为正确
- 由于不同数据采用的完整性机制不同，完全可能机密性高于完整性，或相反，本项说“不同”是合理的，但题中将其列为“错误表述”。
D 项：改用一级产品后分值不变 —— 不合理
- 密码模块等级提升会抬升 K 维度得分，对单元量化结果有正向影响。
📥 放入图谱：量化评估 -> 应用和数据 -> 国密+国际算法混用下的得分差异
第21题：2021 版规则（已废弃）
答案：ACD
解析简述：
A/C/D 基本描述了 2021 版规则的总体精神：遵循法律法规，强调优先在网络/设备/应用技术层面推进密码应用，并鼓励使用合规算法、产品与服务。(TJCSTC)
B 对“优先推进层面”的描述不严谨或与 2023 版表述不完全一致。
📥 放入图谱：量化评估 -> 历史版本 -> 2021 版规则总体定位
第22题：对象层面 D/A/K 一般规则
答案：ABCD
解析：
A：多个密码算法/产品/服务/密钥并存时，D/A/K 均按最低分给分 —— 正确（木桶效应）。(TJCSTC)
B：管理要求不按对象量化，符合=1，不符合=0，部分符合=0.5 —— 正确。
C：通用要求与技术要求各层面的“密码服务/产品”不再单独评价 —— 正确（融入 D/A/K 与单元/层面权重中）。
D：算法/技术不合规但产品满足模块等级时仅为部分符合，最多 0.5 —— 正确。
📥 放入图谱：量化评估 -> 对象层面 -> 多要素取最小值 & 管理侧离散分值
第23题：不同数据类型存储机密性的可能得分
答案：AB
解析：
场景：
个人身份信息：服务器密码机 + SM4（合规）
重要业务数据：自研算法且无安全性证据（不合规）。
对应量化：
个人身份信息：D√ A√ K√ ⇒ 分值可能为 1 或略低（0.6 等，视权重与实现）。
重要业务数据：算法不合规且无安全证据 ⇒ 分值趋近 0。(TJCSTC)
故组合 “0.6，0” 或 “1，0” 都是合理的“可能结果”。
0.25、0.5 同时出现则难以匹配题干所述情形。
📥 放入图谱：量化评估 -> 应用和数据 -> 不同重要数据类型的差异评分
第24题：技术与管理量化方法差异
答案：ABCD
解析：
A：技术要求与管理要求量化方法不相同 —— 正确（技术连续、管理离散）。(TJCSTC)
B：技术要求中，单元结果为该单元所有对象的算术平均值 —— 正确。
C：不适用指标不参与层面平均 —— 正确。
D：同一指标在二级与三级系统权重不一定相同 —— 正确（与第17题一致）。
📥 放入图谱：量化评估 -> 技术 vs 管理 -> 模型差异与权重差异
第25题：物理和环境层面“不适用”的整体影响
答案：ABCD
解析：
物理和环境安全属于技术维度之一，标记为“不适用”后：
其权重不参与整体分值计算，但并不妨碍系统最终分值>90（A 可能）。
若其他层面问题严重或存在高风险，仍可能判定为“不符合”（B）。
若量化结果满分且无高风险，也可判“符合”（C）。
物理和环境安全层面确属密码应用技术要求维度（D）。(TJCSTC)
📥 放入图谱：量化评估 -> 适用性 -> 某层面整体不适用对总分与结论的影响
第26题：测评单元得分形式（错误项）
答案：ACD
解析：
A：“无论哪个层面，单元结果都只有 {0,0.25,0.5,1} 四种情况” —— 错
- 技术要求单元结果为多个对象分值的平均，可是任意 0–1 间小数。(TJCSTC)
B：“技术要求中，单元结果介于 [0,1] 且保留 4 位小数” —— 正确。
C：“技术要求各层面中，单元结果为 [0,1] 且保留 2 位小数” —— 错（应该是 4 位）。
D：“管理层面中，单元结果共有 {0,0.25,0.5,1} 四种情况” —— 不完全正确
- 管理单元通常只有 0/0.5/1 三档；0.25 多用在技术维度的 D/A/K 组合场景。
📥 放入图谱：量化评估 -> 单元层面 -> 技术连续值 vs 管理离散值
第27题：跨两地主备机房的物理和环境量化
答案：BC
解析：
A：两个机房都为对象，单元结果取较低值 —— 不符合规则
- 规则在对象层面使用“取最小值”，但物理和环境层面的机房更多按“平均或权重”考虑，而不是简单取 min。
B：两个机房为对象，单元结果为算术平均 —— 可行
- 若方案未将备份机房判为不适用，两机房同为对象，算术平均符合“对象平均”的一般原则。(TJCSTC)
C：方案将备份机房列为不适用，则只选主机房，单元结果为主机房结果 —— 正确。
**D：两个机房分配不同权重并做加权平均 —— 规则未给出这种“机房内再加权”的通用做法，考试按不合格处理。
📥 放入图谱：量化评估 -> 物理和环境 -> 主备机房对象选择与平均方式
第28题：量化评估规则的适用阶段
答案：ABD
解析：
《商用密码应用安全性评估量化评估规则（2023版）》说明：可用于指导、规范信息系统密码应用安全性评估工作，并可反向指导规划和建设。(TJCSTC)
规划（A）、建设（B）、测评（D）阶段均适用；
运行阶段的日常安全管理更多依赖运营规范与运维制度，量化规则不是“运行管理标准”，故 C 不选。
📥 放入图谱：量化评估 -> 适用范围 -> 规划/建设/测评阶段
第29题：同一对象下三台密码机的汇总
答案：ABC
解析：
三台服务器密码机，型号相同但配置不同，分值分别为 0.25、0.5、0：
A/B：是否都有或都没有认证证书
- 可能存在：功能配置不同导致 D/A/K 组合不同，最终得分不同；证书是否存在并不能直接从分值推断，因此 A/B 都只是“可能情况”，题目问的是“说法正确”，而非“必然”。
C：三台作为同一测评对象时，对象分值为 0 —— 正确
- 多实体取最小值原则，对象分值取三者中最小值 0。(TJCSTC)
D：对象分值为 0.5 —— 错
- 这只有在“按平均”时才可能，而规则明确要求取 min。
📥 放入图谱：量化评估 -> 多实体对象 -> 多台设备取最小值原则
第30题：给定层面得分下的总分（不正确项）
答案：AC
解析：
已知：
物理和环境：不适用
网络和通信：0.75
设备和计算：0.6
应用和数据：0.325
安全管理各层面分值未知，通过备选项假设。
结合 2023 版对三级系统的权重（物理 10、网络 15、设备 20、应用 30；管理 4 个层面共 25 左右），可验证：
若管理四层面均为 1，则整体得分应接近 65.88，而非 60.75，故 A 错、B 可能对。
若管理四层面均为 0，则整体仅由技术层面贡献，计算结果约 35.88 而非 30.75，故 C 错、D 可能对。(TJCSTC)
📥 放入图谱：量化评估 -> 整体量化 -> 管理层面得分对总分的影响
第31题：对象结果最多为 0.5 的场景
答案：BC
解析：
A：认证 VPN（二级模块）+ ECC_SM4_SM3 套件 ⇒ 理论上可达 1 分
- 算法合规、模块达标、使用有效，D/A/K 全 √。
B：认证 VPN（二级模块）+ TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- 使用有效，模块达标（K √），但算法/技术不合规（A ×），因此最多 0.5。
C：三级系统中网络边界安全模块不满足模块等级要求，但用 ECC_SM4_SM3
- 算法合规（A √），使用有效（D √），模块不达标（K ×），仍属部分符合，最多 0.5。
D：未认证 VPN+TLS1.2
- 模块未认证（K ×），算法可能合规也可能不合规，使用有效性也不一定可靠，有场景下对象得分可以是 0 或 0.25，并非“最多 0.5”这个统一结论。
📥 放入图谱：量化评估 -> 对象层面 -> 算法/模块合规性对上限得分的约束
第32题：应急处置层面得分（无“不符合”时的可能值）
答案：BCD
解析：
已知该层面所有测评单元无“不符合”，则各单元分值 ≥0.25。
结合权重与单元分值（0.25、0.5、1 的组合）进行平均后，理论上可能出现：0.25、0.5 以及介于两者之间的 0.6458、0.8542 等值。(TJCSTC)
因为“无不符合”不等于“全部符合”，所以该层面得分不一定为 1。
📥 放入图谱：量化评估 -> 管理层面 -> 无“不符合”时的得分区间
第33题：量化评估的三个方面
答案：BCD
解析：
量化评估从三方面衡量同一对象：(TJCSTC)
B：密码使用有效性（Use）
C：密码算法/技术合规性（Algorithm）
D：密钥管理安全（Key Management）
这里的 “D” 指“Key”，而不是测评对象的“D 维度”；题干中 A 项“密码使用正确性”已被“密码使用有效性”覆盖。
📥 放入图谱：量化评估 -> 评价维度 -> 有效性 / 算法合规 / 密钥管理安全
第34题：GM/T 0116 中对量化评估工作的说明
答案：ABD
解析：
A：各单元得分需按各对象符合程度计算 —— 正确（对象→单元）。(TJCSTC)
B：各层面得分按各单元得分计算 —— 正确（单元→层面）。
C：可直接由单元结果算整体得分 —— 过于简化
- 需要先做层面加权，再整体加权，并考虑“不适用”与管理侧结果。
D：根据各单元/层面/整体得分，综合评价保护措施与风险 —— 正确。
📥 放入图谱：量化评估 -> 过程指南 -> 对象-单元-层面-整体的逐级汇总
第35题：三级系统各技术层面权重
答案：AD
解析：
根据 2023 版规则附录，三级系统技术层面权重示意：(TJCSTC)
物理和环境安全：10
网络和通信安全：15
设备和计算安全：20
应用和数据安全：30
选项中 A(10) 与 D(30) 正确，B/C 不符合。📥 放入图谱：量化评估 -> 权重表 -> 三级系统各技术层面权重
第36题：量化评估过程中的判定顺序
答案：BD
解析：
A：“判定密码使用有效性时需综合考虑算法合规与密钥管理风险” —— 不符合量化模型
- 三个维度分别判定，互不混用。
B：“判定密码使用有效性时，无需综合考虑算法合规与密钥管理风险” —— 正确。
C：“若算法/技术合规性不符合，则无需再判定使用有效性与密钥管理” —— 错
- 即便算法不合规，仍需判定使用是否有效、密钥管理是否安全，以便区分 0/0.25/0.5 等分值。(TJCSTC)
D：“若密码使用有效性不符合，则无需判定算法/技术合规性与密钥管理” —— 正确
- 使用本身无效，等同功能缺失，直接给 0 已足以体现风险。
📥 放入图谱：量化评估 -> 判定逻辑 -> D 先行，一票否决；A/K 在 D 合格前提下细化
第37题：技术层面单元可能的量化值
答案：ABCD
解析：
单元值来源于多个对象的平均（对象值为 {0,0.25,0.5,1} 或更细），因此单元结果可以是：
0.25（均为 0.25）
0.3333（如 0,0.5,0.5 的平均）
0.5（均为 0.5 或平均）
1（全部 1）
故 A/B/C/D 均为可能值。(TJCSTC)
📥 放入图谱：量化评估 -> 单元层面 -> 连续值形式及示例
第38题：WEB 登录 + SM3 加盐杂凑场景（已废弃题，按原规则）
答案：AD
解析：
场景：
登录方式：用户名 + 口令
口令经加盐后采用合规密码模块 SM3 杂凑存储。
依据量化规则：
登录过程若仅用户名+口令且传输未加密，则身份鉴别在应用和数据层面一般不能高于 0.25，极端情况下可能判 0（视“传输是否明文”等实现）。A/B 中“0 或 0.25”均可能；题目答案选 A/D，意在强调“单靠口令不足以高分”。(TJCSTC)
传输时若无加密通道，则“重要数据传输机密性”得分有限（通常 0），C 项“0.5”并不一定成立。
存储时采用加盐 + 合规 SM3 杂凑，对“存储机密性”而言属于较理想实现，可给 1 分，D 正确。
从法律层面看，口令加盐杂凑符合《个人信息保护法》中关于“采取加密等安全技术措施”的要求，同时减少因口令泄露而触及《刑法》第二百五十三条之一（侵犯公民个人信息罪）的风险。(National People’s Congress)
📥 放入图谱：量化评估 -> 应用和数据 -> 口令登录场景下的身份鉴别/传输/存储评分
上面这一条消息我先把 “量化评估”38 题全部按你要求的格式做了逐项排查和图谱归类。
如果你愿意，我们可以接着按同样方式继续帮你拆解后面的 “风险分析” 和 “方案密评” 部分，从第 1 题开始一点点过。
风险分析部分
第1题：通用要求“密码算法”表述
答案：ACD
解析：
A 指标要求表述错误
- 指标不仅要求“符合密码相关国家/行业标准”，还要符合法律法规（如《密码法》）的规定，单写“标准”不完整，因此此表述视为不正确。(GitHub)
B “只适用于部分等级”——错误
- 高风险指引中“通用要求”部分适用于二级及以上各等级系统，不能说“对所有等级均适用”是错误选项的反面；本题问“不正确的描述”，这里应理解为题干对范围描述不严谨，故不选 B。
C “存在可能的缓解措施”——错误描述
- 对“通用要求–密码算法”这一条，一旦使用明显不安全或未论证算法，一般直接构成高风险，很难通过简单补救措施“缓解”；指引明确将 DES、MD5、RSA-1024 等视为高风险情形。(GitHub)
D “采用 OpenSSL 中 AES 算法就一定导致高风险”——错误
- OpenSSL 是密码库，本身并非“算法不合规”的代名词；若采用的是合规算法和参数，并不必然导致高风险。
与法律的衔接：如果因采用不安全算法导致个人信息大规模泄露，还可能触及《网络安全法》第21条“采取加密等措施保护网络安全”的义务，以及严重时触犯《刑法》第二百五十三条之一“侵犯公民个人信息罪”。(China Auction Center)
📥 放入图谱：风险分析 -> 通用要求 -> 密码算法高风险判定要点
第2题：网络和通信层面实体身份真实性（已废弃）
答案：BD
解析：
高风险指引指出：若通信实体身份真实性的密码技术实现机制不安全或不正确/无效，可能导致高风险。(GitHub)
B 不安全：例如使用报废协议（SSL 2.0、TLS 1.0），身份鉴别极易被绕过。
D 不正确：协议实现有缺陷（如验证过程可被绕过），身份鉴别就形同虚设。
A “不科学”、**C “不完整”**是描述性词语，但高风险判定中关键是安全性与实现正确性，而不是“科学性/完整性”的抽象表述。
📥 放入图谱：风险分析 -> 网络与通信 -> 身份鉴别实现缺陷触发高风险
第3题：物理和环境安全层面的身份鉴别措施
答案：ABCD
解析：
题问“可能带来安全风险”的措施：
A 口令：易被窃听、猜解、肩窥，强度不足则存在明显风险。
B ID 卡：若未配合密码技术或防复制、防共享机制，ID 卡容易被复制/借用。
C 指纹识别：若设备未按密码产品标准设计（无活体检测、防重放等），存在伪造指纹、模板泄露风险。
D 物理锁：传统机械锁无法满足“基于密码技术的身份鉴别”要求，本身也常可被技术开锁，风险高。(GitHub)
这些不足会使机房访问控制不能满足《网络安全法》对关键信息基础设施“采取技术措施保障安全”的要求，一旦造成数据泄露还可能引发《个保法》《刑法》责任。(China Auction Center)
📥 放入图谱：风险分析 -> 物理与环境 -> 机房身份鉴别弱点
第4题：远程管理通道安全的缓解措施
答案：AC
解析：
高风险判定指引对“远程管理通道安全”主要看是否采用合规密码技术、是否隔离。(GitHub)
A 带外管理：把管理流量与业务网彻底隔离，大幅降低被窃听/篡改的可能，是有效缓解。
C 所有设备均通过合规的 SSL VPN 进行远程管理：合规协议 + 合规产品，且通道统一、可控，是标准缓解手段。
B 统一经堡垒机认证：只是统一身份鉴别入口，未必解决“通道安全”，若堡垒机前段是明文或弱协议，风险仍在。
D “两种身份鉴别措施”：多因子能提升身份鉴别安全，但题目指标是“远程管理通道安全”，多因子并不直接解决通道加密问题。
📥 放入图谱：风险分析 -> 设备与计算 -> 远程管理通道高风险与缓解
第5题：机房采用人脸 + 值守 + 进出记录
答案：AD
解析：
场景：三级系统，机房入口使用人脸识别（非密码技术）+ 专人值守 + 进出记录。
按 GM/T 0115 要求，三级系统物理和环境安全层面“身份鉴别”应采用基于密码技术的鉴别机制（如动态口令、智能卡等）。(dingshengkj.net)
因仅用生物识别（且未说明满足密码产品标准），不满足“采用密码技术”的要求：
测评符合性应为 A 不符合；
同时，重要区域只靠人脸 + 值守，若存在伪造人脸/替代等问题，会被高风险指引认定为该指标存在高风险（B），但题目答案给 AD：
D “中风险”被选，说明考试将“已配合值守和记录”视作缓解，高风险降低为中风险；
B 高风险因此不选。
C 部分符合 不符实际：未采用密码技术，本指标核心要求缺失。
📥 放入图谱：风险分析 -> 物理与环境 -> 使用非密码生物特征的风险等级
第6题：通用要求“密码算法”再认定
答案：ABCD
解析：
高风险指引在“密码算法”条下明确：(GitHub)
A 适用范围为所有等级信息系统；
B RSA 密钥长度不足 2048 比特：强度不足，易被攻击，可能导致高风险；
C 自行设计算法：无充分公开论证，极易存在致命漏洞；
D MD5 杂凑算法：已被广泛证明存在碰撞攻击，不能继续用于安全目的。
上述情形一旦导致大量个人信息泄露，将触及《网络安全法》《个保法》关于加密安全保护义务，严重时甚至可能以“重大过失”方式与刑事风险挂钩。(China Auction Center)
📥 放入图谱：风险分析 -> 通用要求 -> 不安全算法典型情形
第7题：高风险指引中的“通用要求”理解
答案：AC
解析：
A 正确：通用要求来自 GB/T 39786《信息系统密码应用基本要求》中的通用部分。(GitHub)
B “仅适用二级到四级”——错误：原则上对各等级（含二级以上关键信息系统）均有参考意义。
C “不存在可能的缓解措施”——正确：对很多通用要求（特别是算法类），一旦问题出现往往被直接定性为高风险，很难通过附加措施完全“抵消”。
D “一旦出现情形就一定高风险”——错误：指引给出了“典型高风险”场景，但仍需结合实际场景、资产重要性、影响面综合研判。
📥 放入图谱：风险分析 -> 通用要求 -> 高风险指引适用与缓解特点
第8题：通用要求中密码算法的几个典型问题
答案：ABCD
解析：
指引明确列举：(GitHub)
A 安全强度不足算法（如 RSA-1024、SHA1 等）可能导致高风险；
B 自行设计算法：无公开论证，风险不可控；
C 未经安全性论证算法：本质与 B 类似；
D 还必须符合法律（《密码法》）和国家标准要求，否则即便为“强算法”也属不合规。
📥 放入图谱：风险分析 -> 通用要求 -> 算法选型与合规性
第9题：风险分析依据信息
答案：ABCD
解析：
《GM/T 0116》明确：风险分析基于以下信息：(dingshengkj.net)
A 威胁分析：系统面临的攻击场景；
B 资产分析：数据/系统重要性；
C 已发现安全问题：测评“不符合/部分符合”项；
D 已有安全措施：包括密码应用、访问控制、日志等。
这些步骤也是履行《网络安全法》“风险评估与预案”义务的具体体现。(China Auction Center)
📥 放入图谱：风险分析 -> 方法论 -> 资产/威胁/漏洞/措施四要素
第10题：测评风险规避措施
答案：CD
解析：
题问“不正确”的规避措施：
A 签署委托测评协议、明确范围目标：这是正确且必要的。(dingshengkj.net)
B 签署保密协议：必要，防止泄露个人信息、重要数据，对应《个保法》《网络安全法》的保密义务。(National People’s Congress)
C 在业务高峰期做压力测试：容易对生产系统造成重大影响，违背“尽量不扰动业务”的原则，是不正确做法。
D 上机验证宜由被测单位人员操作：而不是“密评人员自行操作”，避免误操作风险——题中 D 所述不正确。
📥 放入图谱：风险分析 -> 测评风险 -> 压测与操作风险控制
第11题：通用要求“密码技术”描述
答案：BCD
解析：
A “存在缓解措施”：对某些不合规密码技术（如过旧协议）往往很难完全缓解，题目按严格口径不选。
B 采用未经安全性论证的密码协议可能高风险：如自研 VPN 协议。(GitHub)
C TLS 1.0 仍用于保护通信信道：协议已被证明存在多种漏洞，属高风险。
D 选用密码技术需遵循国家标准和行业标准：这是《密码法》和高风险指引共同强调的。(GitHub)
📥 放入图谱：风险分析 -> 通用要求 -> 密码技术（协议）高风险场景
第12题：有安全问题警示的密码技术
答案：ABD
解析：
A SSH 1.0：协议老旧，有设计缺陷。
B SSL 2.0：已被完全弃用。
D SSL 3.0：存在 POODLE 等攻击。(GitHub)
C TLS 1.3：目前安全性高、设计现代，不属于“存在缺陷”的类别。
📥 放入图谱：风险分析 -> 通用要求 -> 不安全/淘汰协议列表
第13题：密钥管理环节
答案：ABCD
解析：
高风险指引列出的密钥管理全生命周期包括：产生、分发、存储、使用、备份、更新、撤销、销毁、恢复等环节。(GitHub)
选项 A/B/C/D 都是核心环节，如撤销不及时、备份与恢复不安全都可能触发数据泄露，违反《个保法》第51条“采取加密等措施保障个人信息安全”的要求。(National People’s Congress)
📥 放入图谱：风险分析 -> 密钥管理 -> 生命周期环节
第14题：风险赋值依据
答案：BC
解析：
GM/T 0116 指出，风险等级（高/中/低）需要结合：(dingshengkj.net)
B 测评方自身经验：尤其是类似系统的实践经验；
C 《高风险判定指引》：提供典型高风险场景参考。
A 单元测评结果、D 整体测评结果 是输入之一，但题干问“根据哪些标准要求”，标准性文件主要是指引和经验总结。
📥 放入图谱：风险分析 -> 评级方法 -> 高/中/低风险判定依据
第15题：通用要求“密码产品和服务”高风险情形
答案：ABCD
解析：
高风险指引中，密码产品/服务的典型问题包括：(GitHub)
A 未按安全策略文档部署/使用：可能绕过安全边界。
B 不具有商用密码产品认证证书：不符合法律与标准要求。
C 服务提供方无资质：无法保证服务安全性和合规性。
D 自研软件密码模块却无安全性证明：属于“未经论证的密码实现”，高风险。
如因此导致大量个人信息泄露，容易触发《个保法》和《刑法》上的责任追究。(National People’s Congress)
📥 放入图谱：风险分析 -> 通用要求 -> 密码产品/服务高风险情形
第16题：物理层身份鉴别中“采用密码技术”的措施
答案：ABC
解析：
高风险指引中举例：在重要区域入口可采用：(GitHub)
A 动态口令
B 基于对称或杂凑算法的 MAC 机制
C 基于公钥算法的数字签名机制
D 生物特征识别本身不是密码技术，除非与密码模块结合使用，否则不足以直接满足“基于密码技术”的要求。
📥 放入图谱：风险分析 -> 物理与环境 -> 基于密码技术的身份鉴别实现
第17题：物理和环境层面身份鉴别问题
答案：ABD
解析：
典型高风险情形：(GitHub)
A 采用的身份鉴别产品不符密码产品要求（无认证等）；
B 身份鉴别机制无效（轻易绕过）；
D 未采用基于密码技术的身份鉴别措施。
C “未采用视频监控” 偏向物理监控问题，不属于“身份鉴别”指标本身。
📥 放入图谱：风险分析 -> 物理与环境 -> 身份鉴别安全问题类型
第18题：网络与通信层面身份鉴别高风险原因
答案：ABCD
解析：
对通信实体身份鉴别的高风险原因包括：(GitHub)
A 密码实现机制不正确/无效；
B 未采用 MAC 机制（若场景需要）
C 未用数字签名（在需要强身份保证的场景）；
D 采用的密码产品未经认证。
这些问题若发生在关键信息基础设施跨境或重要数据通道上，将显著违反《网络安全法》对安全通信和身份真实性的要求。(China Auction Center)
📥 放入图谱：风险分析 -> 网络与通信 -> 实体身份鉴别的高风险源
第19题：远程登录服务器的安全协议选择
答案：AD
解析：
为避免“远程管理通道安全”触发高风险，应使用经证明安全、且推荐的协议：(GitHub)
A SSH 2.0：目前仍被广泛认为可用；
D TLS 1.2：在正确配置下安全性较高。
B SSL 2.0、C SSL 3.0 已经是典型不安全协议，会被视作高风险。
📥 放入图谱：风险分析 -> 设备与计算 -> 远程管理安全协议优选
第20题：指引未涉及场景的风险判定
答案：AC
解析：
指引强调：未列出的场景并非“无风险”，仍需：(GitHub)
A 结合实际场景客观判断；
C 分析其是否造成严重安全隐患（对资产、合规的影响）。
B 无需关注、D 直接判中/低风险都违背“基于证据的风险分析”原则。
📥 放入图谱：风险分析 -> 判定方法 -> 指引未覆盖情形的处理
第21题：高风险判定的描述维度
答案：ABCD
解析：
指引对每个高风险点通常从四个方面描述：(GitHub)
A 指标要求
B 适用范围
C 安全问题（典型场景）
D 可能的缓解措施和风险评价
📥 放入图谱：风险分析 -> 高风险条目结构 -> 要求/范围/问题/缓解
第22题：指引未列出问题时的核查方向
答案：ABCD
解析：
指引第 3 章强调：即使未直接列出，也应从以下方面判断是否存在风险：(GitHub)
A 密码算法
B 密码技术（协议）
C 密码产品
D 密码服务
📥 放入图谱：风险分析 -> 判定方法 -> 四类要素纵向排查
第23题：通用要求“密码算法”典型错误使用
答案：ABC
解析：
高风险指引列举：(GitHub)
A 使用 DES 加密 ⇒ 安全强度不足；
B 使用 SHA-1 保护口令完整性 ⇒ 已不安全；
C 使用自研“混淆算法”使数据“不可读” ⇒ 仍可能有高风险。
D 使用 MD5 with RSA2048：因为 MD5 已不安全，不能说“不会导致高风险”，应判定为存在高风险可能。
📥 放入图谱：风险分析 -> 通用要求 -> 典型不安全算法场景
第24题：不安全的密码算法
答案：BCD
解析：
B SHA-1：存在碰撞攻击；
C RSA-1024：安全强度不足；
D MD5：已被广泛攻破。(GitHub)
A SM2 是国密公钥算法，目前被认为安全，合规使用不会直接导致高风险。
📥 放入图谱：风险分析 -> 通用要求 -> 已不再推荐的算法
第25题：密码算法安全问题的几类表现
答案：ABC
解析：
高风险指引中“密码算法安全问题”包括：(GitHub)
A 安全强度不够（过短密钥、被攻破算法）；
B 自行设计算法；
C 未经安全性论证算法。
D 采用符合法律和标准的算法不构成“安全问题”。
📥 放入图谱：风险分析 -> 通用要求 -> 算法安全问题分类
第26题：不会带来身份真实性安全问题的措施
答案：BCD
解析：
高风险指引对“用户身份真实性”给出的合规措施包括：(GitHub)
B 动态口令机制
C MAC 机制
D 数字签名
A 单纯生物指纹技术若未按密码产品标准和安全协议实现，可能被伪造/重放，不可简单认为“不会带来安全问题”。
📥 放入图谱：风险分析 -> 应用与数据 -> 用户身份真实性合规方式
第27题：机房仅采用 8 位以上口令鉴别
答案：AB
解析：
场景：三级系统，物理入口只使用口令身份鉴别。
不符合 GM/T 0115 对“基于密码技术综合鉴别”的要求，因为只靠口令、无专用密码产品：
符合性结论：A 不符合；
风险等级：高风险指引将此类场景归为高风险（B）。(GitHub)
“部分符合/中风险”对应的是在有一定密码技术基础上仍存在缺陷的场景。
📥 放入图谱：风险分析 -> 物理与环境 -> 仅口令进入机房的高风险
第28题：仅“用户名+口令”登录的风险缓解
答案：ABCD
解析：
高风险指引建议，可以通过增加多因子来缓解单一口令带来的风险：(GitHub)
A 设备指纹
B 人脸识别
C 第三方身份鉴别服务（如统一身份认证）
D 指纹识别
这些措施也符合《个保法》“采取必要措施防止个人信息泄露、篡改”的要求。(National People’s Congress)
📥 放入图谱：风险分析 -> 应用与数据 -> 用户登录风险缓解手段
第29题：存储机密性高危方式
答案：AC
解析：
这里考“重要数据存储机密性”的高危情形：(GitHub)
A 用 DES-CBC 进行数字签名：不合逻辑，说明实现混乱，导致机密性/完整性保护均有问题。
C 用 RSA-1024 加密 SM4 密钥：RSA-1024 强度不足，密钥可能被破解，机密性高危。
B SM4-CBC 加密数据：若密钥/模式管理得当，是可用方案。
D SM4-GCM 加密数据：同时提供机密性和完整性，是推荐模式。
📥 放入图谱：风险分析 -> 应用与数据 -> 存储机密性高危用法
第30题：存储完整性高危方式
答案：ABD
解析：
高危情形：(GitHub)
A SHA1 with RSA-2048：由于 SHA1 不安全，整体签名方案存在完整性风险。
B 仅用 SM3 杂凑值并与数据同存：没有密钥参与或防篡改机制，攻击者可同时改数据和杂凑值。
D HMAC-SM3 但只截取 8 bits：MAC 长度过短，伪造概率极高。
C SM4-GCM 加密保护数据：自带完整性校验标签，是较好方案，不属于高危。
📥 放入图谱：风险分析 -> 应用与数据 -> 存储完整性高危用法
第31题：SSL VPN + 内部应用的风险缓解
答案：ABC
解析：
指引中提到“上层安全可缓解下层风险”的情形：(GitHub)
A：如果用户访问内网前必须通过智能密码钥匙登录 SSL VPN 且评估为“符合”，则应用层用户身份鉴别的整体风险可以适当降低。
B：若网络和通信层“身份鉴别”指标已符合（例如 VPN 双向认证），应用层的身份鉴别风险可以一定程度缓解。
C：若通信信道“重要数据传输机密性”已通过 VPN 层保证，则上层同类指标风险相应降低。
D：“指引不涉及重要数据传输完整性，因此不存在高风险”——错误。未写不等于无风险。
📥 放入图谱：风险分析 -> 分层防护 -> 下层通道对上层指标风险的影响
第32题：设备指纹因子
答案：ABCD
解析：
指引中对“设备指纹”示例包括：(GitHub)
A 操作系统类型
B 设备硬件 ID
C 手机 IMEI
D 网卡 MAC 地址
这些信息组合可以唯一标识设备，用于降低账号被盗用风险，但涉及个人信息，应按《个保法》合法、必要原则使用。(National People’s Congress)
📥 放入图谱：风险分析 -> 应用与数据 -> 设备指纹的构成要素
第33题：测评工作面临的风险
答案：BCD
解析：
GM/T 0116 提到的测评风险包括：(dingshengkj.net)
B 验证测试影响系统运行；
C 工具测试影响系统运行；
D 可能导致敏感信息泄露（违背《个保法》《网络安全法》）。(National People’s Congress)
A “访谈影响运维工作” 影响较小，一般不作为主要“测评风险”。
📥 放入图谱：风险分析 -> 测评风险 -> 运行影响与信息泄露
第34题：有效的风险规避措施
答案：ACD
解析：
A 签署保密协议：防止泄露个人信息或国家秘密；
C 签署测试授权书：明确攻击/扫描等动作的边界和授权；
D 避开业务高峰期执行工具测试：降低对生产的影响。(dingshengkj.net)
B “把无法接入工具的对象直接剔除”：会导致测评范围不完整，反而是错误做法。
📥 放入图谱：风险分析 -> 测评风险 -> 合法合规与影响控制
第35题：属于测评风险的情形
答案：ABD
解析：
A 冗余数据：可能影响业务数据准确性，也可能导致隐私泄露。
B 上机查看配置时拿到重要账号/口令：典型敏感信息泄露风险。
D 测试产生大流量影响负载：可能导致服务中断。(dingshengkj.net)
C 在委托方搭建的“测试系统”攻击：若与生产隔离且获授权，一般不构成对“被测系统”的风险。
📥 放入图谱：风险分析 -> 测评风险 -> 操作、数据与性能三类风险
第36题：密钥销毁与撤销环节隐患
答案：ABC
解析：
高风险指引指出以下问题会对密钥管理带来隐患：(GitHub)
A 缺乏应急销毁/撤销机制；
B 未按既定机制执行销毁/撤销；
C 对磁记录密钥仅“删除/写 0/写 1”：可被恢复。
D “停止使用的密钥不要立即毁掉而保存一段时间”：如果用于追责、审计，反而是合规做法（前提是妥善保护）。
📥 放入图谱：风险分析 -> 密钥管理 -> 撤销/销毁环节常见问题
第37题：重点关注的管理制度
答案：ABCD
解析：
高风险指引与 GM/T 0116 都强调以下制度：(GitHub)
A 密码人员管理
B 密钥管理
C 建设运行
D 应急处置
这些制度不健全，会导致密码应用安全问题难以及时发现与处置。
📥 放入图谱：风险分析 -> 管理制度 -> 四大类密码管理制度
第38题：可能给密钥管理带来隐患的内容
答案：ABC
解析：
高风险指引列举：(GitHub)
A 未用合规随机数发生器生成密钥，且无证明文档；
B 密钥在不可控环境中产生；
C 未验证对方身份就协商密钥。
D 由具有商密认证证书的密码产品产生密钥：是推荐做法，不是隐患。
📥 放入图谱：风险分析 -> 密钥管理 -> 生成与协商的风险点
第39题：错误的风险缓解说法
答案：ACD
解析：
A 用 MAC 机制解决“数据传输机密性”——错误：MAC 只保证完整性与认证，不保证机密性。
B 数字签名可解决“数据存储完整性”问题——正确。
C “三级及以上系统一定存在不可否认性高风险”——错误：是否高风险取决于具体实现。
D 用 RSA-1024 解决存储机密性——错误：RSA-1024 已不满足安全强度要求。(GitHub)
📥 放入图谱：风险分析 -> 指标与技术 -> 机密性/完整性对应的正确技术
第40题：应用和数据安全层面可能存在的高风险项
答案：ABD
解析：
高风险指引在应用和数据层面重点关注：(GitHub)
A 身份鉴别
B 重要数据传输机密性
D 重要数据存储完整性
C “重要数据传输完整性” 虽然重要，但在当前指引中作为高风险判定条目的覆盖度相对有限，常与机密性同通道处理。
📥 放入图谱：风险分析 -> 应用与数据 -> 三个重点高风险指标
第41题：不会触发“重要数据传输机密性”风险判定的方式
答案：BC
解析：
若使用以下方式，实现合理的加密传输，一般不会触发机密性风险判定：(GitHub)
B 基于 SM4-CBC 对称算法（正确实现）。
C 基于 SM2 非对称算法加密。
A 标准 TLS 1.2 若使用不合规算法/套件，仍可能高风险，不能“一概认定安全”。
D Base64 只是编码，不提供机密性，是典型高风险。
📥 放入图谱：风险分析 -> 应用与数据 -> 传输机密性的安全/不安全实现
第42题：“重要数据存储机密性”的适用范围
答案：AB
解析：
高风险指引中，应用和数据层面“重要数据存储机密性”涉及：(GitHub)
A 业务系统采用 AES 加密存储数据（是否合规、模式正确）；
B 使用 SM3 保护身份证号等敏感信息（通过不可逆变换增强机密性）。
C HMAC-SM3 主要用于完整性；
D SM4 用于传输机密性，属于“传输”，非“存储”。
📥 放入图谱：风险分析 -> 应用与数据 -> 存储机密性的典型数据类型
第43题：缓解应用层用户身份鉴别风险的措施
答案：ABC
解析：
典型缓解手段：(GitHub)
A 设备指纹
B 生物指纹
C 第三方身份鉴别服务
D 绑定终端 IP 地址：IP 可能被篡改/代理/共享，可靠性远低于前述方式，不能视作主要缓解措施。
📥 放入图谱：风险分析 -> 应用与数据 -> 用户身份鉴别的多因子强化
第44题：可能触发应用和数据层面“身份鉴别”风险的方式
答案：CD
解析：
高风险指引指出以下弱鉴别方式可能触发风险判定：(GitHub)
C 短信验证码（易被劫持/社会工程）；
D 邮箱验证码（邮箱本身可能安全性不足）。
A USB-Key、B 动态口令机制：若为合规密码产品/技术，是推荐的强鉴别方式。
📥 放入图谱：风险分析 -> 应用与数据 -> 弱二次验证码方式的风险
方案密评部分
第1题：关于密码应用方案的说法（错误项）
答案：BC
解析：
A 正确：方案及其评估意见是判断 GB/T 39786 中“宜”类指标是否适用的重要依据。(GitHub)
B “同一云平台上的不同云上应用可写一份方案统一分析”——不严谨/错误
- 不同应用的业务流程、数据类型、等保等级可能不同，应各自分析密码需求，不能简单“一份方案包打”。
C 若方案把“不可否认性”判“不适用”，而现场发现有实际需求，仍按方案判不适用——错误
- 应以实际业务和现状为准，方案应修改，指标不能强行“不适用”。这也符合《网络安全法》对“持续改进安全措施”的要求。(China Auction Center)
D 正确：背景分析业务流程与数据安全需求，设计保护机制，是方案的核心工作。
📥 放入图谱：方案密评 -> 方案角色 -> 方案与现场的一致性与纠偏
第2题：密码应用方案编写应体现的内容
答案：ABCD
解析：
《报告模板》要求方案至少包括：(GitHub)
A 系统承载业务与网络拓扑；
B 密码应用需求分析；
C 各安全层面的技术实现方案；
D 安全与合规性分析（是否符合《密码法》《网安法》《个保法》要求）。(China Auction Center)
📥 放入图谱：方案密评 -> 方案内容 -> 背景/需求/实现/合规
第3题：方案“背景”部分内容
答案：ABCD
解析：
背景章节通常包括：(GitHub)
A 建设规划；
B 相关法律法规要求（《密码法》《网安法》《个保法》等）；
C 前期信息化基础情况；
D 项目实施必要性（如合规、业务发展驱动）。
📥 放入图谱：方案密评 -> 报告结构 -> 背景章节要素
第4题：方案密评的基本要求
答案：ABCD
解析：
密评机构在方案密评时应：(GitHub)
A/B 审查方案是否覆盖所有需要密码保护的核心资产和敏感信息（与《个保法》《网安法》对重要数据、个人信息的保护要求对应）；(China Auction Center)
C 审查方案中密码措施是否满足相应等级要求；
D 方案密评可以由责任单位自评，也可委托第三方机构。
📥 放入图谱：方案密评 -> 评估内容 -> 资产覆盖与技术达标
第5题：应用和数据层面保护对象梳理重点
答案：ACD
解析：
应重点识别：(GitHub)
A 有身份鉴别需求的应用用户类型；
C 各应用的重要数据与安全需求；
D 有不可否认性需求的操作行为。
B “可用性需求的数据” 主要属可靠性范畴，不是密码保护的直接对象。
📥 放入图谱：方案密评 -> 应用与数据 -> 用户/数据/行为的保护对象
第6题：系统概述需结合拓扑描述的内容
答案：ABCD
解析：
系统概述+网络拓扑应说明：(GitHub)
A 机房数量及位置；
B 网络边界及互联关系；
C 跨网访问信道（如专线、VPN）；
D 设备组成及功能分布。
📥 放入图谱：方案密评 -> 系统概述 -> 拓扑与部署描述要点
第7题：系统概述部分应包含的内容
答案：ABC
解析：
系统概述通常包含：(GitHub)
A 网络拓扑；
B 承载业务情况；
C 各安全层面保护对象。
D “项目情况” 属于背景/立项部分，不是“系统概述”的必备内容。
📥 放入图谱：方案密评 -> 报告结构 -> 系统概述与背景区分
第8题：方案评估结论的表述
答案：CD
解析：
对方案密评，结论通常为：(GitHub)
C 通过
D 不通过
“符合/不符合”更多用于信息系统实际密评中对各指标的符合性判定。
📥 放入图谱：方案密评 -> 结论形式 -> 方案通过/不通过
第9题：建设运行方面方案评估重点
答案：ABCD
解析：
方案评估报告在建设运行方面通常关注：(GitHub)
A 密码应用方案本身；
B 密钥管理制度；
C 攻防对抗演习报告（验证方案有效性）；
D 密码应用安全管理制度。
📥 放入图谱：方案密评 -> 管理层面 -> 建设运行维度关注点
第10题：管理制度方面评估重点
答案：ABCD
解析：
管理制度方面重点：(GitHub)
A 各类安全管理制度文档；
B 密码应用方案与制度的衔接；
C 密钥管理制度及策略；
D 系统相关人员（角色与职责）。
📥 放入图谱：方案密评 -> 管理层面 -> 管理制度与人员职责
第11题：GM/T 0116 中密评方案应包含内容
答案：ABCD
解析：
密评方案（工作计划）应包含：(dingshengkj.net)
A 项目概述；
B 测评对象/测评指标；
C 测评检查点；
D 单元测评实施安排。
📥 放入图谱：方案密评 -> 测评方案 -> 内容结构
第12题：密评方案编制过程中的任务
答案：ABCD
解析：
GM/T 0116 对编制过程要求：(dingshengkj.net)
A 提取项目信息、系统互联关系；
B 明确依据的标准与通过评估的方案；
C 根据范围和复杂度估算现场工作量；
D 按人员分工编制工作安排。
📥 放入图谱：方案密评 -> 测评方案 -> 编制流程
第13题：“指标适用情况及论证说明”表格不涵盖什么？
答案：ABCD
解析：
实际上，该表格只罗列每个指标“适用/不适用”及论证，不会对“算法/技术/产品/服务”分别拆列成列名；
四个选项都不是表格本身的列名，从题库设计角度，四项均视为“不涵盖”。
📥 放入图谱：方案密评 -> 报告表格 -> 指标适用性说明用途
第14题：应用和数据层面保护对象表的内容
答案：ABD
解析：
保护对象表需重点梳理：(GitHub)
A 具有身份鉴别需求的用户类型；
B 各应用的重要数据及其安全需求；
D 具有不可否认性需求的操作行为。
C “承载业务情况” 在前面系统概述中已有，不属于“保护对象表”的主要字段。
📥 放入图谱：方案密评 -> 应用与数据 -> 保护对象表字段设计
第15题：不同安全层面指标的评估结果表述
答案：AB
解析：
在方案密评中，对各安全层面指标的控制措施评估结果通常用：(GitHub)
A 通过
B 未通过
“符合/不符合”更多用于实际系统测评（GM/T 0115）。
📥 放入图谱：方案密评 -> 结果表述 -> 指标级“通过/未通过”
第16题：属于风险替代措施的情况
答案：ABC
解析：
风险替代措施是指未采用密码技术，但用其他方式降低风险：(GitHub)
A 机房人脸+指纹 身份鉴别；
B 通用服务器指纹登录；
C 业务应用人脸+短信验证码。
D “应用层采用合规密码技术保护传输” 属于标准密码措施，不是“替代”。
📥 放入图谱：方案密评 -> 风险替代 -> 非密码手段降低风险的示例
第17题：对安全控制措施评估结果判定不合理的是
答案：ABC
解析：
三个场景都“存在明显高风险，却判为通过”，所以不合理：(GitHub)
A 物理层仅用门禁 ID 卡，无密码技术，仅靠视频监控；
B 互联网通信未做实体鉴别，仅依赖应用层登录；
C 未对重要数据做存储机密性保护，仅靠数据库口令；
D 未用密码技术做存储完整性且仅依赖访问控制和备份，正确做法是判“未通过”，题目中确实这么判，所以本项合理，不选。
📥 放入图谱：方案密评 -> 控制措施评估 -> 错误“放行”的典型案例
第18题：关于安全控制措施评估的错误描述
答案：BCD
解析：
A：如果网络与通信层面采用的虽然是国外算法，但在不要求国密的场景下，仍有可能评估为“通过”；该项描述是“可能”，可以接受。
B：“41 个指标只有 1 个未通过 ⇒ 方案就通过”——错误，高风险项一个就足以导致“不通过”。
C：“有 1 个未通过但量化分>=75 ⇒ 方案通过”——错误，方案结论不能只看量化分，还要看是否存在高风险。
D：物理层“身份鉴别”未采用密码技术，仅依赖管理措施，应评为“未通过”，表述“仍通过”当然错误。
📥 放入图谱：方案密评 -> 结论判定 -> 不可被量化分数掩盖的高风险
第19题：何时可判定某指标“通过”
答案：CD
解析：
某指标评估为“通过”需满足：(GitHub)
C 所有保护对象的密码应用措施均有效，无高风险，且实施保障合理；
D 若使用风险替代措施，也需全部有效、无高风险，且保障合理。
A/B “不涉及高风险”但没明确控制措施是否有效，不够充分。
📥 放入图谱：方案密评 -> 指标判定 -> “通过”所需条件
第20题：方案密评与系统密评的关系（错误项）
答案：BC
解析：
A 正确：“三同步一评估”——规划阶段评方案，建设运行阶段评系统。(GitHub)
B：“方案评估结论可能有‘修改后通过’”——模板中结论一般为“通过/不通过”，修改意见会写在建议中，不作为正式“第三类结论”。
C：“量化分达阈值即可通过方案”——错误，还必须无高风险。
D：实际密评“安全管理”层面测评单元得分通常为 1/0.5/0，而不是 0.25。
📥 放入图谱：方案密评 -> 方案 vs 系统 -> 评估周期与结论形式
第21题：系统承载业务情况应包含内容
答案：ABCD
解析：
方案密评报告中描述承载业务情况时，应包括：(GitHub)
A 业务应用；
B 业务功能；
C 应用用户；
D 重要数据与关键操作行为。
📥 放入图谱：方案密评 -> 系统承载业务 -> 应用/功能/用户/数据
第22题：密评活动证明材料
答案：ABC
解析：
“密评活动证明”部分，可包含：(GitHub)
A 邮件往来；
B 通话记录（如沟通纪要）；
C 会议记录。
D 系统现场测评记录 更多归入系统密评报告中的“检测过程”，不一定记在方案密评活动证明中。
📥 放入图谱：方案密评 -> 活动证明 -> 邮件/电话/会议记录
第23题：“安全控制措施描述及指标适用情况”中的适用性说明
答案：ABCD
解析：
“指标适用情况及论证说明”需写明：(GitHub)
A 每个测评项适用与否；
B 不适用项的理由；
C 若部分保护对象不适用，也要写清楚原因；
D 不适用指标总数（统计）。
📥 放入图谱：方案密评 -> 指标适用性 -> 记录与论证
第24题：安全控制措施描述的注意事项
答案：ABCD
解析：
描述控制措施时，应：(GitHub)
A 覆盖四个技术层面+四个管理层面；
B 如未用密码技术，也要描述风险替代措施；
C 描述要结合系统密码应用部署图；
D 部署图中应标出所有涉及的密码产品（冗余除外）和服务。
📥 放入图谱：方案密评 -> 控制措施 -> 描述与图示要求
第25题：三级系统方案“不通过”的最可能原因
答案：AB
解析：
方案评估“不通过”的两个主要原因：(GitHub)
A 存在高风险项无法通过控制措施消除；
B 初步量化结果未达阈值。
C 不适用项数多 可能意味着方案设计不充分，但不必然导致“不通过”；
D 冗余内容多 属于文档质量问题，非核心判定依据。
📥 放入图谱：方案密评 -> 结论判定 -> 不通过的触发条件
第26题：人员管理方面评估重点
答案：ABC
解析：
人员管理方面通常关注：(GitHub)
A 安全管理制度类文档（是否明确岗位职责）；
B 记录表单类文档（培训记录、授权记录等）；
C 系统相关人员（是否具备相应资质）；
D 整改文档 侧重于问题整改阶段，不是人员管理的主要关注点。
📥 放入图谱：方案密评 -> 管理层面 -> 人员管理
第27题：应急处置方面评估重点
答案：ABCD
解析：
应急处置方面应关注：(GitHub)
A 密码应用应急处置方案；
B 应急处置记录；
C 安全事件发生及处置报告；
D 相关人员（应急响应团队）。
这也对应《网络安全法》《个保法》对数据泄露等事件“及时处置并报告”的法定义务。(China Auction Center)
📥 放入图谱：方案密评 -> 管理层面 -> 应急处置机制与记录
如果你愿意，我可以再帮你把这三大块内容（量化评估 + 风险分析 + 方案密评）整理成一份知识图谱总表，按“条目-考点-典型错误”形式列出来，方便你考前突击。