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的取值不能被修改）进行确证
4.7. 用于认证的密钥仅可以或许签订源自于TPM的数据，这种局限显然无法支持类似TLS之类的传输加密协议
4.7.1. 流行的IKE守护进程strongSwan使得TPM不仅仅可以用于认证IPSec连接，还能通过对PCR数据的利用实现授权，确保发起连接的主机所运行的软件是准确且未被篡改过的
4.8. 对于一个成熟的零信任网络，利用TPM进行强设备认证是抱负选择，它完善地实现了软件身份和物理硬件之间的联结
4.8.1. 如今TPM虚拟化技术已有可用的实现（如用于Xen系统的vTPM），但信任仍然必须植根于硬件TPM
4.8.2. 设计一套可热迁移的基于TPM的安全系统具有极大的挑衅性
4.8.3. 虽然在成熟的零信任网络中建议采用TPM作为设备认证的手段，但不应该将其视为强制需求， TPM的大幅采用并不轻易，在零信任架构的采用和迁移方面可以思量一些其他的折中方案
5. 基于硬件的零信任附件
5.1. 在零信任网络中，支持传统设备的常用方案是采用认证代理
5.2. 认证代理终止与零信任相干的逻辑和操作，并将连接转发至传统主机
5.3. 可以通过一些专用硬件来实现类似功能，这些专用硬件设备作为零信任附件设备，携带一枚TPM芯片，可以直接插入传统设备的以太网端口
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
