1.1. 将设备身份和用户身份混为一谈会导致一些显而易见的问题

1.1.1. 特别是当用户拥有多台设备时，而这种情况很普遍

1.1.2. 应该针对不同类型的设备提供相匹配的凭证

1.1.3. 在存在共用终端设备的情况下，所有的这些问题将更加凸显

1.2. 需要将用户的识别和信任严格地区分于设备

1.2.1. 二者是完全不同的两个凭证

1.2.2. 用户信任在多人参与的情况下会有所不同

2.1. 每个人都有身份，它是现实社会中个体的象征，是个体进行社会活动的基础

2.2. 在网络系统中，身份就是社会人/用户所对应的数字个体的标识，是用户在网络系统中活动的基础

2.3. 非正式身份

2.3.1. 是组织内部的自定义身份

2.3.2. 常用于计算机系统

2.3.2.1. 昵称/花名常见于在线通信，是一种不与现实世界中真实姓名相关联的账户

2.3.3. 常用于小团体中，个体之间的信任程度相对较高，风险较低

2.3.4. 缺点

2.3.4.1. 用户可以创建虚假身份

2.3.4.2. 用户可以假冒他人身份

2.3.4.3. 单个用户可以创建多个身份

2.3.4.4. 多个用户可以共享同一身份

2.4. 权威身份

2.4.1. 在现实世界中，个人往往使用政府颁发的ID（如驾照）作为他们的身份凭证

2.4.2. 在安全性较高、风险较低的场景下，单独使用这些ID就可以证明某人的身份

2.4.3. 在风险较高的场景下，需要根据政府数据库交叉核验身份凭证，进一步增强安全保障

2.4.4. 计算机系统也需要一个权威中心负责用户身份管理，同现实世界一样，授予用户不同强度的凭证，并据此在计算机系统中标识他们

2.4.5. 依据风险等级的不同，可能还需要根据中央数据库交叉核验用户凭证

2.5. 凭证可能丢失或者被盗，因此身份管理的权威机构需要制定一种机制来处理用户身份遗失问题，使用户重新获得身份凭证

2.5.1. 验证方式和验证材料的选取不当可能会诱发安全隐患

3.1. 数字化身份的产生以及身份与人的初始关联都是非常敏感的操作

3.1.1. 对实体人的验证机制必须足够强，以防攻击者伪装成新员工获取系统身份

3.1.2. 当用户无法提供当前的身份凭证时，账号恢复程序同样需要足够强的认证控制来确保实体人身份的合法性

3.2. 政府颁发的身份

3.2.1. 应该首选政府颁发的身份对物理世界中的实体人进行认证

3.2.2. 这些身份设计之初的首要目的就是认证实体人

3.2.3. 相关安全人员要想验证这些ID必须经过专业培训，以免某些安全机制被攻击者轻易绕过

3.3. 人工认证的力量

3.3.1. 人工认证机制的安全性却依然更强

3.3.2. 人工当面授予实体人新的数字身份一直是很好的方式

3.3.3. 非常不推荐通过邮件或其他“盲引”机制进行认证

3.3.4. 信任的建立是基于一个已知的可信人员对待开通身份的人员的信息了解，这种间接的信任关系是后续人工认证和身份创建的基础

3.3.5. 虽然人工认证的可信度很高，但这不应该是唯一的认证机制，就像零信任网络中的其他组件一样

3.4. 预期信息的确认

3.4.1. 在创建数字身份之前，有许多信息可以获取，应使用尽可能多的信息全面构建用户画像，确保用户画像符合相关数字身份创建的预期要求

3.4.2. 可以将这些预期信息看作是实体身份通向数字身份的关键要素，主要依赖人为收集和确认

3.4.2.1. 用户使用的语言

3.4.2.2. 用户个人ID上的家庭住址

3.4.2.3. 其他更有意思的信息

3.4.3. 在现实生活中，人们常常使用类似的机制进行认证（偶尔或正式），所以这种机制相当成熟可

4.1. 通常需要永久保存

4.2. 用户目录

4.2.1. 为了构建用户信任，系统一般需要一个目录集中记录用户相关信息

4.2.2. 由于用户在该目录的存在性是后续所有认证的前提，因此集中存储这些高度敏感的数据是一个无法逃避的安全挑战

4.2.3. 用户目录会存储一些基本信息，还有一些扩展信息

4.2.3.1. 零信任网络可以基于丰富的用户信息做出更好的认证判定

4.2.4. 用户信息极其敏感，最好不要将所有信息都存储在一个数据库中

4.2.4.1. 最好用几个相互隔离的数据库代替单一数据库来存储所有用户信息

4.2.4.2. 这些数据库仅仅可以通过受限的API接口进行访问，这样最大程度地限制了信息的暴露面

4.2.4.3. 永远不要直接暴露原始数据

4.2.4.4. 通过有权访问这些数据的应用程序开放访问接口

4.2.4.5. 过这些接口对一个用户的信息进行断言式查询

4.2.5. 系统可以考虑询问用户一些关于已知“事实”的知识/信息来进一步验证用户身份

4.3. 目录的维护

4.3.1. 保证用户目录的准确性对于零信任网络的安全性至关重要

4.3.2. 身份源系统和人力资源系统这两个数据源应该尽量保持同步

4.3.3. 必须有一个系统作为身份的原始记录系统

4.3.3.1. 如何选择是根据组织需要决定的

4.3.4. 选择哪个系统并不重要，重要的是只有一个权威身份源系统记录身份，其他身份源系统都得从该系统导出它们所需的数据

4.4. 最小化存储数据是有益的

4.4.1. 维护基础身份记录的系统并不需要存储所有身份信息

4.4.2. 最好明确地分开存储不同的用户数据

4.4.3. 记录系统只需要存储可以识别个人身份的关键性信息

4.4.4. 衍生系统可以使用此记录系统中的权威ID来存储额外的用户信息

5.1. 传统模式总是力求划分出一个高度敏感的数据区域或操作，并对其进行极尽可能的强认证，即便用户之前已经做过一定的认证并且累积了足够的信任度

5.1.1. 信任评分驱动的认证机制摒弃绝对的一次性的认证需求，取而代之的是一种自适应的按需认证和授权机制

5.2. 认证对于零信任网络至关重要，它是强制行为，但应该在显著增强安全性的同时保证用户体验最优，最大程度地使用户方便

5.3. 务必牢记用户体验是设计零信任网络的一个重要的参考因素

5.3.1. 往往容易只关注认证的安全性而忽略其便捷

5.3.2. 若一个安全技术提供的用户体验相当糟糕且注定会失效，那么用户很可能会想办法削弱甚至破坏安全机制

5.3.3. 糟糕的用户体验会极大地影响用户的使用意愿，并且往往会使用户最终找到一些捷径绕过这些安全强制要求

5.4. 通过认证机制获取信任

5.4.1. 认证用户实际上就是系统验证用户是否是他声称的那个人

5.4.2. 不同的认证操作赋予不同的信任等级，根据情况灵活选择认证方式

5.4.3. 登录音乐订阅服务仅需要密码

5.4.4. 登录投资账户不仅需要密码，还需要额外的验证码

5.4.5. 用户可以通过额外的认证方式提高其信任等级

5.4.6. 如果一个用户的信任评分低于当前访问请求要求的最低信任评分，就需要进行额外的认证

5.4.7. 若通过该认证，那么用户的信任等级将提升至该请求要求的水平

5.4.8. 通过二次认证提高信任等级这种机制并不陌生，如今它已经被广泛应用

5.4.9. 仅通过认证机制获取的信任等级始终是有限的，如果没有这一原则，设备安全性和其他一些危险信号可能导致的潜在安全问题就可能被忽略

5.5. 通过信任驱动认证机制

5.5.1. 认证的目的是获取信任

5.5.1.1. 切记不要毫无目的地让用户通过各种认证挑战

5.5.1.2. 应该根据期望的信任等级设定认证需求的机制

5.5.1.3. 当用户的信任评分足够高时，则不需要对他进行进一步认证

5.5.1.4. 当用户的的信任评分太低时，则要求进一步认证

5.5.2. 系统不需要对特定操作设置额外的认证要求，而是设置一个信任评分阈值来驱动认证流程和需求

5.5.3. 系统可以选取任意的认证方式进行组合来满足信任评分要求，掌握每种认证方式的可信度及可访问信息的敏感度，有助于设计对攻击更免疫的系统

5.6. 通道安全

5.6.1. 通信信道本身就有不同的信任等级

5.6.2. 各种信道的认证强度也不相同

5.6.3. 使用多通道模式时，理解通道本身的信任度非常重要，这决定了在不同场景下对通道的选择

5.6.4. 硬件动态令牌的安全性和其分发系统的安全性一致

5.6.4.1. 如果令牌是通过当面领取的方式分发的，则其安全性取决于领取令牌时，管理员对领取人的身份确认是否足够可靠

5.6.5. 企业聊天系统的推送通知功能，其安全性和登录该聊天系统时所使用的凭证安全性相

5.7. 使用多通道通信

5.7.1. 在对请求进行认证和授权时，使用多通道通信是非常高效的

5.7.2. 可以选择多种通道，并将其有机整合，形成完整的数字认证方案

5.7.3. 当用户请求某些高风险操作时，可以通过某种通道提示用户进行二次确认

5.7.4. 当决定什么时候、在哪里应用多通道通信时，必须将用户体验作为重要的因素考虑在内

5.7.5. 第二通道应该与认证/授权的第一通道不同

5.7.6. 破坏一个通道可能很容易，可是同时破坏多个通道的难度将大大增加，这就是多通道带来安全性提升的根本原因

5.8. 缓存身份及其信任等级

5.8.1. 会话缓存技术已经相当成熟

5.8.2. 对授权进行频繁验证有非常重要的意义，这是当信任等级发生变化时，控制平面对数据平面应用程序进行有效干预的唯一机制

5.8.3. 一般认为授权验证的频率越高越好

5.8.3.1. 在某些实现方案中，每个请求的授权都会通过控制平面实时处理

5.8.4. 许多应用只会在会话初始阶段验证SSO令牌，验证通过后，会给此会话设定一个和应用绑定的令牌

5.8.5. 对请求进行授权时若采用控制平面令牌代替应用令牌，那么当信任等级波动时，可以更方便高效地更改授权判定，及时撤销授权