先定问题
确认要保护的是密钥、链路、存储数据、身份还是操作过程。
零基础模式
START HERE · 先看全局
先别背产品名，先看它在安全体系中的位置
产品目录最容易让人陷入“记名称”的误区。这里先沿着一条真实的责任链阅读：密钥在哪里生成和保存，密码能力如何被调用，数据在传输、存储和访问时分别由谁保护，最后再回到具体产品。
一张图读懂四条产品线
先问保护对象，再看产品落点
四条线只是阅读入口，不是四座孤岛。一个完整项目通常同时需要密码能力、传输保护、数据保护与身份控制；产品的输入、输出和部署边界决定了它能承担哪一段责任。
分层心智模型
从业务往下问五次“靠什么”
1
业务使用层
用户最终要完成什么？
电子签章 · 统一认证 · 零信任 · 堡垒机
2
场景保护层
保护哪类数据或通道？
数据库加密 · VPN · 视频安全 · HTTPS
3
信任服务层
如何证明身份与时间？
CA · 签名验签 · 时间戳 · 协同签名
4
资源管理层
能力如何共享和治理？
密码服务平台 · KMS · 密码监管平台
5
密码硬件层
密钥在哪里安全地存和算？
密码机 · 密码卡 · UKey · 物联网模块
先抓住六个锚点
其他产品都可以和它们比较
新增 · 知识与产品双向照应
不再把“原理课”和“产品手册”分开看
知识专题解释算法、密钥和协议怎样工作，并列出相关产品；产品详情反向显示它依赖哪些知识，以及这些知识在产品里承担什么作用。
再看机制
辨认加密、签名、认证、访问控制、审计各自解决什么，不把它们混成一个“安全能力”。
最后落到产品
用部署位置、输入输出、依赖关系和失效边界判断产品是否适合场景。
目录里的四条“产品线” ≠ 密评标准里的四个“技术层面”
产品资料按密码安全、网络安全、数据安全、身份安全分类；GB/T 39786 则从物理和环境、网络和通信、设备和计算、应用和数据四个技术层面提出要求。一个产品可能支撑多个密评指标，但不能因为采购了产品就默认“通过密评”。