读零信任网络：在不可信网络中构建安全系统08设备清单管理

1. 设备清单管理

1.1. 设备的认证和完整性检查是零信任安全至关重要的第一大步，但是仅仅验证设备是否属于企业是不够的

1.2. 设备清单管理涉及对设备及其属性进行编目管理

• 1.2.1. 将配置管理作为设备清单数据库

• 1.2.2. 维护/管理这些记录对客户端和服务器设备同样重要

• 1.2.3. 建议将这些设备当作网络实体而不是物理设备，虽然大多数情况下它们是物理设备，但是在零信任网络中，它们也可能是网络上的逻辑实体

• 1.2.4. 事实上，同时部署多个清单管理系统也是很常见的

1.3. 零信任网络模型主张跟踪工作负载流量以便进行细粒度的网络策略

• 1.3.1. 工作负载调度服务是可以作为设备清单管理的一个组件进行工作的

1.4. 梳理系统预期

• 1.4.1. 零信任网络的强大之处在于系统预期的明确，什么应该发生和什么不应该发生是很清晰的

• 1.4.2. 默认情况下禁止任何等级的访问，只允许预期的操作和请求

• 1.4.3. 设备清单数据库是实现这种可预期的访问控制能力的关键组件

  • 1.4.3.1. 通过各类设备属性可以推导出大量的有用信息

  • 1.4.3.2. 基于这些信息推导出系统的预期行为

  • 1.4.3.3. 预期行为可能包括哪些用户或应用应该在哪些设备运行、设备应该被部署的位置，甚至设备上应该运行什么操作系统等

  • 1.4.3.4. 属性信息越丰富、越准确，这种细粒度的行为预期和访问控制规则就越完善

    1.4.3.4.1. 可以默认只放行期望的流量

• 1.4.4. 在数据中心内的服务器行为相对静态和可预期，它们往往采用长连接的方式与特定的预设主机/服务通信

• 1.4.5. 客户端系统则常常使用短连接与各种不同的服务进行通信，通信的时间、频率和模式都会持续有机变化

• 1.4.6. 一种可行的方案是允许各类全局访问

  • 1.4.6.1. 确保所有的通信都使用双向认证的TLS连接进行保护

  • 1.4.6.2. 强制客户端提供设备证书，否则双向认证的TLS连接将无法建立

  • 1.4.6.3. 通过设备证书，可以在设备清单数据库中进行设备检索，从而判断是否授权此连接请求

• 1.4.7. 这种方案的优势在于，很多系统现在都支持双向TLS连接，并且不会过度限定必须使用某种客户端软件，因此，可以在获得较高安全性的同时保持不错的可用性和易用性

• 1.4.8. 不足也非常明显，服务是全局可访问的

  • 1.4.8.1. 通过双向TLS验证客户端证书可以缓解这种安全性的不足

  • 1.4.8.2. 由于心脏滴血（HeartBleed）之类漏洞的存在，TLS服务器仍然暴露了相当大的攻击面

1.5. 安全介绍

• 1.5.1. Secure Introduct​ion, SI

• 1.5.2. 新设备发出的第一个连接或数据包具有极高的不确定性（甚至威胁性）​

  • 1.5.2.1. 因为系统为了提供服务，必须允许和接受这个请求，如果没有很好的机制对这个初始包进行认证，则风险就始终存在

• 1.5.3. 通过安全介绍，一个新实体在将自己介绍给一个现有系统的同时可以传递足够的信任信息

• 1.5.4. 安全介绍机制的核心在于必须设置一个预期

  • 1.5.4.1. 安全介绍在实践中必须依赖一个可信的第三方

  • 1.5.4.2. 这个可信第三方是一个已经被信任的系统，并且它具备介绍其他更多新系统加入的能力

• 1.5.5. 优秀的安全介绍系统的构成要素

  • 1.5.5.1. 单次使用

    1.5.5.1.1. 安全介绍所使用的凭证或权限信息只能单次使用，防止攻击者通过重用密钥进行攻击或重放攻击

  • 1.5.5.2. 瞬时性安全介绍所使用的凭证或权限信息应该具备时效性，防止有效但尚未使用的密钥形成堆积

  • 1.5.5.3. 第三方参与

    1.5.5.3.1. 通过第三方系统进行安全介绍有利于职责分离，这可以避免引入一些不良的安全举措，并且有效地缓解一些运维麻烦

• 1.5.6. Chef系统提供唯一的秘密信息（视作“验证证书”​）​，只要拥有这个证书，主机就可以作为一个新节点加入系统

• 1.5.7. 新版的Chef采用了新方案，它不再提供静态的验证证书，而是供应系统（通过Chef客户端工具“Kni​fe”​）与Chef服务器通信，创建一个客户端和相关联的客户端证书，然后进一步创建一个新主机并传递客户端证书，通过这种方法，新客户端就建立了足够的预期

2. 设备信任续租

2.1. 没有完美的安全，也没有永远的安全。这是一个必须面对和遵循的事实，没有例外

• 2.1.1. 只有意识到这一“残酷”现实，才能妥善地寻求缓解措施来应对各种可能的安全问题和潜在影响

  • 2.1.1.1. 所有解决方案都依赖于具体的场景

• 2.1.2. 随着时间的推移，信任度会流失，因此，需要考虑信任的续租

  • 2.1.2.1. 设备从可信状态开始，逐步退化到不可信状态

2.2. 设备运行的时间越长，其被攻破的可能性就越高，因此，设备“年龄”应该作为一个信任信号进行度量

• 2.2.1. 一台全新镜像的设备的可信度显然高于一台运行了多年的设备

2.3. 设备轮换（Rotat​ion）

• 2.3.1. 云主机实例，在这种场景下实现“轮换”就相对简单：只需要销毁现有实例，重新构建一个新实例就完成了（使用配置管理系统，这个过程很简单）​

• 2.3.2. 物理硬件的场景，设备轮换就不那么简单了

• 2.3.3. 大家都认可客户端设备也需要周期性的轮换或重镜像，但是这个频率需要根据情况具体分析

• 2.3.4. 设备轮换或重镜像的周期越长，终端系统的安全越是难以控制

2.4. 本地度量

• 2.4.1. 基于硬件的度量

  • 2.4.1.1. 更加安全可靠，但是受限于硬件的能力

  • 2.4.1.2. 利用TPM实现远程证明

    2.4.1.2.1. 这个响应信息非常可靠并且难以复制

    2.4.1.2.2. TPM的远程证明只能覆盖比较低级的系统信息和特定的软件信息，如果攻击者通过提权在系统的用户空间运行了一些未授权应用，那么TPM的远程认证机制就无能为力了，因此其能力是受限的

• 2.4.2. 基于软件的度量

  • 2.4.2.1. 安全性和可靠性稍弱，但是在实践中，其度量能力会更加强大

  • 2.4.2.2. 代理程序可以持续报告系统的健康度和状态评估

    2.4.2.2.1. 缺乏硬件层面的保护，所以只要攻击者具备足够的权限就很容易对其进行攻击（甚至篡改）​，整个度量机制也会随之失效

2.5. 远程度量

• 2.5.1. 其受益于职责分离

• 2.5.2. 一个被攻破的系统可能上报任意经过篡改的内容，这些内容和信息能轻而易举地掩盖攻击者的行为

  • 2.5.2.1. 这种情况在远程度量或被动度量的场景下不会发生

  • 2.5.2.2. 因为这些度量是完全独立的外部系统，它从外部对目标设备进行健康度分析和度量

• 2.5.3. 在传统方案中，远程度量通过简单的漏洞扫描实现，周期性地对目标系统进行扫描、探测，并观察和分析其响应结果

  • 2.5.3.1. 这种探测和扫描可以获取不少的有用信息，包括设备上运行的是什么操作系统、设备开启了哪些服务，甚至于可以探测这些服务的版本是多少

  • 2.5.3.2. 非常成熟的漏洞扫描软件

    2.5.3.2.1. OpenVAS

    2.5.3.2.2. Nessus

    2.5.3.2.3. Metasploi​t

  • 2.5.3.3. 本地度量是询问某人是否抢劫了银行，而漏洞扫描系统则稍微高明一点，它通过观察判断某人是否抢劫了银行

3. 软件配置管理

3.1. 配置管理是严格控制和记录所有软件变更的过程

• 3.1.1. 所需的配置被定义为代码或数据

• 3.1.2. 这些信息通常被提交到版本控制系统进行管理，以便进行变更审计、回滚之类的操作

3.2. 配置管理软件在数据中心和客户端部署场景中同样适用，特别是当系统规模超出一定范围后尤其必需

• 3.2.1. 数据中心托管系统虽然具备一定的动态性，但某种程度上却明显比客户端系统更加静态和可预测

3.3. 基于配置管理的设备清单库

• 3.3.1. 一种免费馈赠

• 3.3.2. 配置管理系统本身还有很多其他好处可大量使用，将其作为设备清单数据库往往是出于方便

• 3.3.3. 配置管理系统不是为设备清单管理系统而设计的，它们是作为配置管理系统使用的，其功能存在明确的边界，当然，最终可以逐步将其完善

3.4. 可搜索的设备清单库

• 3.4.1. 一些配置管理系统集中存储通过其代理收集的数据，并且支持对这些数据进行搜索，基于这样的系统构建零信任网络，具备了更多的可能性和想象空间

• 3.4.2. 设备清单库的可搜索特性在审计和报表生成方面也大有可为

  • 3.4.2.1. 这种特性不仅仅适用于数据中心，还适用于客户端系统

• 3.4.3. 只需要简单地搜索目标系统，并变更配置管理的代码，有漏洞的软件包就全部精准更新了

3.5. 软件

• 3.5.1. Chef

• 3.5.2. Puppet

• 3.5.3. Ansible

• 3.5.4. CFEngine

4. 确保数据的真实性

4.1. 信任的基础是设备部署者，或者是人工操作员，又或者是某个自治系统

4.2. 评估设备的关键属性或行为等各个方面

• 4.2.1. 设备类型

• 4.2.2. 角色

• 4.2.3. IP地址（针对数据中心而言）

• 4.2.4. 公钥

4.3. 限制对这些属性的变更至关重要

• 4.3.1. 这些自汇报的设备属性仍然可以用于授权判定

• 4.3.2. 在任何情况下都不能把这些属性当作既成事实，而应仅仅将其作为一个提示性的属性

5. 用户授权

5.1. 零信任网络模型强制对设备、用户甚至应用程序进行认证和授权

5.2. 设备认证一般在用户认证之前完成，因此设备认证不应该依赖用户认证阶段获取的任何信息，用户认证则与之相反

• 5.2.1. 当进行用户认证时，设备认证也已完成，网络已经知悉了设备的身份并生成了大量有用的场景信息

• 5.2.2. 可以据此信息构建比以往更强大的用户认证手段

• 5.2.3. 可以根据这些信息判断用户是否应该在某个类型的设备或者某个位置登录

5.3. 另外一种不错的威胁信号是用户认证频率

• 5.3.1. 事无绝对，这种情况也有可能是合法的，因此，对这种情况的处理可以灰度化，降低用户的信任评分以表明当前会话值得怀疑

5.4. 对零信任网络架构而言，能进行场景感知的动态授权判定是非常关键的，这也说明了强大的设备清单数据库的重要性

• 5.4.1. 设备清单管理虽然是为了进行严格的设备认证而引入的，但其在用户认证方面的贡献更是极具价值

6. 信任信号

6.1. 上次镜像时间

• 6.1.1. 随着时间的推移，设备被攻破的几率将大幅上升

6.2. 历史访问

• 6.2.1. 设备认证模式和用户认证模式比较类似，能较好地体现设备的风险，并且可以对设备的行为进行建模和过滤

• 6.2.2. 访问频率也可以用于分析某个资源是否被可疑地滥用

6.3. 位置

• 6.3.1. 虽然在零信任网络模型中，网络位置不再是授权判定的依赖因素，但是仍然可以将其作为一种信任信号进行分析

• 6.3.2. 零信任的目标就是不以网络位置作为信任的基础，因此，基于网络位置来判定访问权限确实看起来有少许矛盾

6.4. 网络通信模式

• 6.4.1. 如果设备访问的网络是可控的，那就有机会度量网络通信模式，并形成一种流量范式，范式的突然变化是可疑的，这将直接影响系统对设备的信任度

• 6.4.2. 网络监测和流量采集设备通过流量分析可以快速检测出可能的入侵，将这种检测结果作为授权判定的输入因子，可以产生强大的联动效果