1. 设备信任
1.1. 在零信任网络中建立设备信任至关重要，这也是非常困难的一个环节
1.2. 建立设备信任是基石，直接影响零信任网络架构的成败
1.3. 大多数网络安全事件都和攻击者获得信任设备的控制权相关，这种情况一旦发生，信任就将被彻底瓦解，无法通过设备来确保安全信任链的建立
2. 初始信任
2.1. 对于新采购的设备，其信任程度取决于采购者对生产厂商和供应商的信任程度
2.1.1. 一般认为其信任度较高
2.1.2. 这种继承自供应商的信任度是一种社会化信任
2.1.3. 需要将这种现实社会的真实信任度"注入"设备本身，形成初始的数字信任度
2.2. 黄金镜像
2.2.1. 无论以何种方式收到设备，都需要加载一个明确的"好"镜像，这个镜像就是"黄金镜像"
2.2.2. 一次性地通过彻底的审核确定软件镜像的可信，并将其作为"黄金镜像"进行分发
2.2.3. 将一个干净的"黄金镜像"加载到设备能极大地确保设备的信任度
2.2.3.1. 通过这种方式，有足够的理由确信设备运行的软件经过了审核并且是安全的
2.2.3.2. 记录设备上次重新加载镜像的时间可以在一定程度上决定设备的可信程度
2.3. 安全启动
2.3.1. 通过一些非常底层的技术将非法代码植入到设备中是完全有可能的
2.3.1.1. 即便重新为设备加载镜像也无法擦除
2.3.2. 安全启动是防护此类攻击的方法之一，通过在设备固件内嵌入的公钥对驱动程序和操作系统引导程序进行签名验证，可以确保这类非法植入物无所遁形
2.3.3. 安全启动比较有效，但是其受限于操作系统和设备的内在机制的支持
2.3.4. 有效验证设备上运行的软件只是第一步，还需要提供一种技术手段，让设备可以向待访问的资源标识自己的身份
2.3.4.1. 典型做法是通过私有CA为每台设备签发单独的设备证书，进行网络通信时，设备必须提交此证书
2.4. 设备证书
2.4.1. 设备证书不仅仅能证明设备是已知在册的，还能证明设备的唯一身份
2.4.2. 设备证书的私钥一旦被窃取，攻击者就可以假冒信任设备，这种情况会直接影响设备认证方案的有效性
2.4.2.1. 必须考虑设备证书私钥的安全存储问题
2.4.3. 方案1：配置对私钥的访问权限，只允许具有超级权限的用户（如root或administrator）访问
2.4.3.1. 攻击者一旦提权就可以轻易获取私钥
2.4.4. 方案2：对私钥进行加密
2.4.4.1. 比简单的权限控制方案好一些
2.4.4.2. 可能存在一些易用性问题
2.4.4.2.1. 必须提供口令或其他凭证才能解密和使用私钥
2.4.4.2.2. 对于服务器认证的场景它就很不适用了
2.4.4.2.2.1. 无法做到每次软件重启时都要求人工交互
2.4.5. 方案3：迄今为止存储设备密钥的一种极好的方法是使用安全的加密处理器
2.4.5.1. 这些设备[通常被称为硬件安全模块（HSM）或可信平台模块（TPM）]提供可以执行加密操作的安全区域
2.4.5.2. 加密处理器暴露为数不多的应用程序编程接口（API）用于生成非对称加密密钥，确保私钥永远不会离开安全模块
2.4.5.3. 操作系统也不能直接访问安全模块存储的私钥，因此它很难被窃取
2.4.6. 设备证书代表了设备的身份和初始信任度，其私钥用于对其他系统证明本设备是被认证的、可信的
2.4.6.1. 既然对身份标识的本地安全存储都需要谨慎防护以免被窃取，证书的生成和签发就更不应掉以轻心
2.4.6.2. 如果从企业的安全需求来看，设备的初始证书签发和安装极其敏感，那就必须在证书签署流程中引入人工干预环节，杜绝流程上的隐患
2.5. 身份标识安全
2.5.1. 在相对静态的系统中配置新主机时，通常由安全操作员进行人工的设备身份标识部署
2.5.1.1. 一般认为安全操作员是可信任的
2.5.1.2. 这一人工操作确保初始身份标识可信
2.5.2. 在动态系统中，配置和签名过程都是自动化的，是否需要人工干预？
2.5.2.1. 完全取决于系统的安全等级
2.5.3. 所有应用和系统组件都应该身份化，这一原则是不变的，这同时适用于主机中心化和容器中心化的环境
2.6. 审批和安全授权
2.6.1. 为避免人为犯错，建议每个人只负责对他们自己发起的请求进行审批确认
2.6.2. 通过使用一次性动态口令（TOTP）可以在单个步骤中完成部署和签名授权
2.6.2.1. 一个TOTP口令只能使用一次，所以TOTP验证失败是一个重要的安全事件，可以杜绝安全隐患
2.6.3. 信任只能来源/派生于某个已有的信任源
2.6.3.1. 人工干预
2.6.3.1.1. 在相对静态的基础设施或终端用户设备的场景中，人工干预是一种简单安全的方案
2.6.3.1.2. 对于自动化的基础设施场景而言，人工干预不是一个好的选择
2.6.3.2. 资源管理器
2.6.3.2.1. 在某种程度上属于特权系统，其具备对基础设施的系统进行扩大或缩减的能力，并且整个基础设施的可用性也极大地依赖这类资源管理系统
2.6.3.2.2. 通过资源管理器可以直接或间接地对新证书的签发进行授权
2.6.3.2.3. 在容器化环境中，这类职责可能由资源调度器承担
2.6.3.3. 镜像或设备
2.6.3.3.1. 可考虑将身份凭证直接"烧制"到设备镜像中
2.6.3.3.2. 不建议将这种方案作为首选，因为这种方案过度依赖镜像库，并且保护和周期性地刷新镜像将变得复杂且具有风险
2.6.3.3.3. 可以利用HSM或TPM来提供与硬件关联的设备证书，这种方案比直接将凭证"烧制"到设备镜像中稍好
2.6.3.3.4. 但过度依赖TPM来实现设备证书的签发仍然不是最理想的方案
2.6.3.3.5. 特别是需要兼顾云端系统的部署时，其局限性就很明显了
2.6.4. 授权因子
2.6.4.1. 镜像中的密钥（或TPM中注册的密钥）
2.6.4.2. 正确的IP地址
2.6.4.3. 合法的TOTP（通过资源管理器生成）
2.6.4.4. 匹配的证书属性（如匹配的证书CN）
2.6.5. 一种较好的方式是综合利用资源管理器和可信安全镜像，将通用的认证凭证"烧制"到设备镜像中（或注册TPM密钥），并将其用于终端和签名服务之间的安全通信传输
2.6.5.1. 攻击者无法访问待部署的主机，顶多对可用性进行一些攻击
2.6.5.2. 即便设备镜像被盗用也无法完成证书请求，因为资源管理器会进一步验证镜像部署的主机以及签名请求的其他属性
3. X.509
3.1. X.509是当之无愧的设备身份和认证方面的重要标准
3.1.1. 它定义了公钥证书、吊销列表的证书格式和验证证书链的方法
3.1.2. X.509证书的首要作用是证明身份
3.2. X.509的强大之处在于，其使用的公私钥对除了用于设备身份认证，还提供了一种用于设备初始安全通信的可靠机制
3.2.1. 这也是X.509对互联网安全非常有价值的众多原因之一
3.3. 证书链及证书认证机构
3.3.1. 要使证书具备足够的意义，对其建立信任是至关重要的
3.3.2. 任何人都可以签发证书，只是拥有一个匹配的CN名称证书并不意味着什么，证书必须经由可信机构进行数字签名才能具备有效性，才是可信的
3.3.3. 没有"真实"签名的证书被称为自签名证书，通常用于测试
3.3.4. 证书注册机构（一般可由证书签发机构充当或委派）负责对证书的详细信息进行确认，只有确认过的证书信息才能被签名
3.3.5. 如果签发的证书具备一定的属性，还可以用于签发下一级证书，从而形成信任链，显而易见，这个信任链的根就是证书认证机构
3.3.6. 通过信任CA，我们间接信任了其签发的所有证书的有效性
3.3.7. 通过实现分发少量公钥（CA公钥），所有从这个CA签发的证书都包含了到上级签发证书的链接，从而可验证其有效性和合法性
3.4. 公钥加密或非对称加密
3.4.1. 非对称加密运算代价极大，不适合用于大块数据加密
3.4.2. 通过使用公钥和私钥两个密钥可以完成身份证明/认证
3.4.3. 公钥是可公开分发的，而私钥由证书的所有者安全持有
3.4.4. 使用私钥加密一小段数据，则这段数据只能通过对应的公钥进行解密，从而证明证书所有者确实持有证书私钥
3.4.5. 在大多数场景下，这个密钥对采用RSA密钥对
3.5. 设备身份
3.5.1. 主体（Subject），这个字段用于描述证书的所有者，在设备认证的场景下，这个所有者就是设备（或主机）
3.5.2. 通常情况下，组织（Organization, O）和组织机构（Organizational Unit, OU）字段的含义与字面意思一致
3.5.2.1. O字段用于表示环境
3.5.2.2. OU字段用于表示主机的角色
3.5.3. 证书是经过签名的，可被信任，所以这些信息可以安全地用于授权判定
3.5.4. 作为授权客体的服务器明确地知道其应该被授权给哪些主体
3.6. 私钥存储
3.6.1. 如果私钥被攻破，那么设备的身份和隐私也会受到威胁
3.6.1.1. 私钥被攻破的情况是一种糟糕的场景，应该不惜一切代价进行规避
3.6.2. 可以在存储私钥时对其进行加密，使用私钥的时候需要提供加密口令进行解密
3.6.2.1. 使用口令对私钥进行加密仅适用于面向用户的设备
3.6.2.2. 在数据中心场景，这种方案并不奏效，因为解密私钥需要口令并考虑其安全存储，或通过某种安全机制传输密钥口令到服务器，这样一来，保证口令的安全变得和保护私钥一样重要
3.6.3. 硬件安全模块（HSM）
3.6.3.1. 可以通过硬件生成密钥对并且将私钥保存在安全存储区内，安全存储区的私钥是禁止直接读取的，只能通过HSM提供的接口请求其使用私钥来进行指定的运算
3.6.3.2. 这种基于硬件安全存储的私钥保护机制非常安全，不易被盗
3.7. 设备认证
3.7.1. 在零信任网络中，将X.509证书用于设备认证至关重要，它是证明设备身份的基石，其在建立端到端加密的过程中也不可或缺
3.7.2. 零信任网络的每个设备都应该拥有X.509证书
3.7.2.1. 这个方案的核心是私钥，私钥是基于软件的，如果被盗，那么整个设备认证体系将成为无本之木
3.7.3. 设备证书通常用于真正的设备认证的代理
3.7.3.1. 密钥如此之长，不可能将其写下来或记住
3.7.3.2. 密钥可以被下载和安装，因此，一般不由用户随身携带，在设备认证的场景中，密钥应该始终和设备在一起
3.7.4. 通过使用TPM可以将私钥和硬件进行绑定并安全存储，从而有望彻底地解决私钥的安全问题
4. TPM
4.1. 可信平台模块（TPM）是一种嵌入到计算设备中的特殊芯片
4.1.1. 这种芯片一般称为加密处理器，用于以可信和安全的方式进行密码运算
4.1.2. 一般包含自己的固件，可以将其视作一种特殊的单片机
4.1.3. 有助于实现一种小巧而精简的硬件API，并且可轻松审核和分析潜在的系统漏洞
4.1.3.1. 可以避免暴露过多接口以及直接对私钥的读取
4.1.3.2. 即便是操作系统，也无从获取安全密钥
4.1.4. 安全密钥和硬件紧密绑定
4.1.4.1. 在零信任安全中，通过TPM实现设备认证是一个极佳的实践
4.2. 使用TPM加密数据
4.2.1. TPM生成并存储所谓的存储根密钥（Storage Root Key, SRK），这个密钥对代表了TPM设备的信任根
4.2.2. 为了有效利用TPM进行批量数据加密，必须设法减少SRK直接保护的数据量
4.2.3. 方案是生成一个随机加密密钥，将其用作对称加密算法（如AES）的加密密钥，并采用这类高性能算法对块数据进行加密，这个随机加密密钥可以使用SRK进行加密保护
4.3. 中间密钥和密码短语
4.3.1. 很多TPM库（如TrouSerS）在加密数据时会使用中间密钥
4.3.1.1. 要求TPM创建一个全新的非对称密钥对，使用公钥对AES密钥进行加密，然后使用SRK对私钥进行加密
4.3.1.2. 解密数据时，首先通过TPM解密中间密钥的私钥，并用它解密AES密钥，然后再使用AES密钥解密原始数据
4.3.2. 增加一级额外的中间密钥有利于加密数据的灵活分发
4.3.2.1. 如果仅仅为了满足"密钥只能通过相应的设备进行解密"这一目标，则并不需要采用中间密钥方案
4.3.3. SRK和中间密钥都支持加密短语，因此中间密钥可以允许使用额外的加密短语
4.4. 基于TPM的安全存储机制的一个作用在于保护设备X.509证书的私钥
4.4.1. 安全密钥是设备身份证明的权威信任根，如果其被盗用，那么设备身份事实上也被盗用了
4.4.2. 使用TPM对私钥进行加密，意味着虽然仍有可能从磁盘获取私钥，但是一旦离开当前设备，这个私钥就不能解密和恢复使用
4.4.3. 密钥盗用仍然存在可能性
4.4.3.1. 方案只能防止攻击者直接从磁盘读取密钥
4.4.3.2. 无法避免攻击者提权后直接从内存读取解密后的密钥
4.4.3.3. 攻击者甚至可能调用TPM的接口直接进行加解密操作
4.5. 平台配置寄存器
4.5.1. Platform Configuration Register, PCR
4.5.2. 是TPM的重要特性之一
4.5.3. 提供多个存储插槽，可以用于存放运行软件的散列值
4.5.4. PCR最开始存放的是BIOS的散列值，紧随其后的是引导记录，然后是对应的配置信息，诸如此类
4.5.4.1. 这些散列值序列可以用于证明系统的配置或状态是合法的
4.5.5. 数据"封印"
4.5.5.1. 可以确保只允许经过授权的软件配置解密数据，这可以通过在使用TPM加密数据时，传递一组已知的PCR数据值作为参数来实现
4.5.5.2. 被"封印"的数据只能通过封印它的TPM进行解密，并且解密时PCR的取值必须匹配
4.5.5.3. 由于PCR的取值无法修改或回滚，因此可以使用TPM"封印"技术确保加密数据不仅仅绑定到当前设备，还能绑定到特定的软件配置和版本
4.5.5.4. 可以有效地防止攻击者通过设备访问权限来获取私钥，因为只有未被修改的软件才能解锁这些数据
4.6. 远程认证
4.6.1. 数据一旦离开物理TPM的安全存储区域，其安全性将无法保证，仍然可能被盗用
4.6.2. 一旦通过TPM对加密数据进行解锁/解密，原本在TPM中安全存放的私钥就被暴露了
4.6.3. TPM还提供了另外一种唯一标识其身份的方法，就是被称为背书密钥（Endorsement Key,EK）的密钥对
4.6.3.1. 每个TPM都有唯一的密钥对
4.6.3.2. EK的私钥仅存在于TPM内，因此即便是操作系统也无法对其进行访问
4.6.4. 远程认证时，TPM生成一个称为"引用"，然后将其安全地传输至远端系统
4.6.4.1. 这个"引用"包含了当前的PCR取值列表，并且使用EK进行签名
4.6.4.2. 远端系统可以通过这些信息对主机身份（因为EK对于每个TPM都是唯一的）和对应的软件状态/配置（因为PCR的取值不能被修改）进行确证