策略决定什么
安全模式只说要不要签名、要不要加密，具体用什么算法由安全策略决定。因此只选签名并加密却不看策略，可能仍在使用早已不推荐的算法。策略升级的难点在兼容：两端必须同时支持同一个策略才能握手，所以现实做法是分两步走，先让服务器同时开放新旧两个端点，客户端分批迁移，确认全部切换后再关闭旧端点。无安全策略只应出现在离线实验环境，生产网络中它等于把读写能力向任何网络邻居开放。
基本信息
| 决定内容 | 签名算法、加密算法、密钥长度等要求 |
|---|---|
| 匹配要求 | 客户端与服务器必须支持同一策略 |
| 工程基线 | 以基于 SHA-256 与 2048 位 RSA 的策略为最低要求 |
| 强度不足 | 早期以较弱哈希为基础的策略已被规范标记为不推荐 |
| 升级方法 | 双端点共存、分批迁移、最后关闭旧端点 |
| 名称差异 | 不同产品界面上的策略命名可能不同，以规范标识为准 |
典型使用场景
- 新项目定基线：直接只启用满足当前要求的策略，避免后续升级
- 老设备兼容：确认设备支持的最高策略，再决定过渡期长短
- 过渡期管理：同时开放新旧策略，按客户端实际使用情况判断何时收敛
- 安全评审：梳理每个端点暴露的策略列表，剔除无安全与弱算法
- 性能评估：算法强度提升会带来额外开销，需在高频场景实测
- 证书要求核对：策略对密钥长度与算法有要求，证书不合规会握手失败
策略强度梯度
| 类别 | 保护效果 | 使用建议 |
|---|---|---|
| 无安全 | 无签名无加密 | 仅限隔离实验室 |
| 仅签名类 | 可验证来源与完整性，内容仍可读 | 内部网络阶段性使用，需评估窃听风险 |
| 早期哈希策略 | 基于较弱哈希，已不推荐 | 尽快替换，不要用于新部署 |
| SHA-256 基线策略 | 满足当前通用要求 | 生产环境的最低选择 |
| 更强对称算法策略 | 更高的加密强度 | 性能允许时优先，需两端支持 |
过渡期切换步骤
过渡期切换步骤
# 1 清点现有客户端支持的策略集合，找出交集与并集
# 2 服务器同时开放新策略端点与旧策略端点，旧端点仅对过渡期客户端开放来源
# 3 客户端分批切换，记录每批实际协商到的策略
# 4 过渡期结束前复核：是否还有客户端消耗旧端点
# 5 关闭旧策略端点，并纳入配置基线，防止后续被重新打开
# 注意：具体策略名称与算法细节以规范与产品文档为准只签名不加密能保证报文没被篡改，但内容仍可被读取；涉及口令类身份令牌时，必须使用加密端点。
为兼容而长期保留弱策略，等于让整条链路按最弱的一环定强度；过渡期应设定明确的收敛时间点，而不是无限延长。