读零信任网络：在不可信网络中构建安全系统18零信任代理

1. 零信任代理

1.1. 零信任代理是应用级代理服务器，用来保护零信任网络，它是处理认证、授权以及加密的基础设施

1.2. 零信任代理分为反向代理和前向代理两种工作模式

• 1.2.1. 运行时可以同时采用这两种工作模式，也可以只采用其中的一种

• 1.2.2. 在反向代理工作模式下，代理接收来自零信任客户端的连接请求，并接收初始连接，校验此连接是否应该被授权，授权通过后，把客户端请求传递给后端的应用系统处理

• 1.2.3. 在前向代理工作模式下，非零信任感知的组件需要向另一个零信任系统发出网络请求

  • 1.2.3.1. 因为非零信任感知的组件不能和零信任控制平面交互，所以不能正确地初始化该请求，只能通过认证代理完成请求的初始化

1.3. 利用代理构建零信任网络时，代理应该以嵌入式的方式部署在运行工作负载的设备上

• 1.3.1. 以这种方式构建零信任网络，所有工作负载的网络通信流量在进入网络之前都会被强制引流到代理上

1.4. 最好不要把零信任代理部署在一台单独的外部设备上

• 1.4.1. 把零信任职责交由外部设备代理的做法违背了零信任模型声称的保证所有流量安全的目标

• 1.4.2. 这种做法不能保证代理/负载均衡器和后端服务之间的流量安全

1.5. 如果系统管理员对于网络中的设备和服务没有完全的控制权，那么构建零信任网络就会变得非常困难

1.6. 在不可修改的组件和零信任网络之间部署零信任代理，就可以让该组件参与到零信任网络中来，尽管不能保证足够高的安全性

1.7. 将非零信任感知的组件完全隔离非常重要，而且这种隔离必须保证流入和流出该组件的网络流量都只能经过认证代理

• 1.7.1. 如果可能，代理最好采用串联部署而非旁路部署模式

2. 客户端与服务端迁移

2.1. 通常首先是从客户端—服务器之间的交互着手实现零信任模型

• 2.1.1. 客户端一般是指移动设备或者源自非受控网络的访问服务

• 2.1.2. 零信任架构的自动化系统需要兼容多种客户端操作系统

• 2.1.3. 不是每个客户端设备都能安装现有的自动化系统

• 2.1.4. 在客户端—服务器层面构建零信任将会面临很多挑战

2.2. 从服务器—服务器之间的交互着手构建零信任网络相对来说更容易一些

• 2.2.1. 服务器通常都已经安装了自动化工具

• 2.2.2. 服务器供应商的数量相对较少，对系统自动化工具的兼容性要求也更低

• 2.2.3. 从安全角度考虑也应当尽快着手实现服务器之间的零信任

  • 2.2.3.1. 服务器通常是那些保存敏感数据的系统，所以它们也是攻击者的攻击目标

2.3. 网络安全较薄弱的环节恰恰是构建零信任网络的着手点

2.4. 使用威胁建模方法可以预测攻击者会在组织的哪些脆弱点进行攻击、如何攻击，然后依此决定在哪里投入资源和时间研究以实现零信任

3. PagerDuty的云无关网络

3.1. PagerDuty系统的日常运营重度依赖广域网（WAN）通信

• 3.1.1. 互联网的网络环境相对比较恶劣，可能会出现意外的高延迟和数据包丢失等状况

• 3.1.2. 广域网的通信需要采用认证和加密机制以保证数据的隐私和完整性

3.2. 部署无边界的零信任网络成为理想的解决方案，零信任网络集群中的每个节点都仅仅负责它自己的通信，可以实现故障的隔离

3.3. 配置管理系统作为自动化平台

• 3.3.1. Chef系统

  • 3.3.1.1. Chef已经被用来配置系统中的虚拟机，因此它是一个理想的、随时可用的自动化系统，可以利用它来构建零信任网络

• 3.3.2. 好处

  • 3.3.2.1. 网络计算资源能够随着实例数量的增减而自动伸缩，随着网络的扩展，这种伸缩性能够降低购买更大的共享硬件服务器的需求

  • 3.3.2.2. 更好地隔离故障

    3.3.2.2.1. 该方案事实上是采用大量“微型防火墙”代替了传统的完整防火墙

    3.3.2.2.2. 即使微型防火墙失效，也只是影响很小范围的网络流量

• 3.3.3. 贯穿整个网络设计的分布式策略的缺点

  • 3.3.3.1. 需要持续校验预期策略的状态，以确保所有节点正确地执行预期策略

  • 3.3.3.2. 策略变更会逐步作用到整个集群

• 3.3.4. 选择合适的配置管理工具作为着手点，能够快速实现零信任网络的理念落地，但是配置管理工具并不是理想的长期解决方案

• 3.3.5. 随着零信任网络的成熟度不断提高，管理员应该尽快摆脱对Chef系统的依赖，实现自己的自动化平台，以获得最佳性能，为目标进行部署并持续迭代调优

  • 3.3.5.1. 随着网络规模的扩大，系统的配置不再依赖Chef，而是由一个专用服务负责

3.4. 动态配置本地防火墙

• 3.4.1. Chef系统需要基于现有的系统知识生成IPtable配置

• 3.4.2. 每个主机都需要构建IPtable链表，枚举特定角色的服务器的IP地址，然后就可以使用这些链表来定义基于角色的访问控制规则

3.5. 分布式流量加密

• 3.5.1. PagerDuty实现了一个基于IPSec主机—主机模式的网状网络

  • 3.5.1.1. 所有数据包都经过系统中每个节点的加密和认证

  • 3.5.1.2. 因为认证和加密是在系统中分布式部署的，所以这些关键功能会随着主机数量的增加而增长

• 3.5.2. 3个问题

  • 3.5.2.1. 不是每个应用都能正确实施加密规范

  • 3.5.2.2. 缺乏响应安全漏洞的配置控制手段

  • 3.5.2.3. 导致系统性能降低

• 3.5.3. 为了保证安全能力的一致性，系统管理员应当把TLS基础设施从应用系统中剥离出来

• 3.5.4. 随着系统中应用程序的数量不断增加，越来越多的系统倾向于利用过程外（Out-Of-Process）加密机制来保证网络通信安全

• 3.5.5. IPSec通信通常采用ESP数据包传输，但是有些云服务提供商不能路由ESP数据包，所以需要使用UDP数据包封装所有IPSec流量

  • 3.5.5.1. 优点是可以有效处理随着主机数量增加而不断增长的业务吞吐量

  • 3.5.5.2. 缺点：初次上线运行时，IPSec通信双方的状态不一致经常会导致通信的失败，而这类问题对于网络的生产运营至关重要

• 3.5.6. 分布式流量加密也采取了渐进式部署模式

  • 3.5.6.1. 以空操作（No-Op）的方式在系统集群中部署IPSec策略，这些策略用于控制网络流量是否应该使用IPSec通信

  • 3.5.6.2. 不使用（None）​：不使用IPSec通信

  • 3.5.6.3. 使用（Use）​：如果通信双方可以通过协商调整关系参数，那么最好使用IPSec

  • 3.5.6.4. 必须（Required）​：必须使用IPSec通信

  • 3.5.6.5. 在实际应用中，不能直接把整个网络同时配置成“使用”状态，而是先将一小部分网络迁移到“使用”状态，然后再将它们重新配置成“必须使用”状态

3.6. 用户管理的去中心化

• 3.6.1. PagerDuty的用户访问控制也是集中式部署的，但是其用户管理没有依赖中心化的LDAP系统，而是由网络中的每个主机构建本地用户和群组

• 3.6.2. 系统根据LDAP服务器和其他相关数据库中的信息，集中完成用户和群组的定义

3.7. 部署上线

• 3.7.1. 步骤

  • 3.7.1.1. 定义新策略

  • 3.7.1.2. 在不影响生产系统的情况下部署策略，同时收集有用的测量指标和日志

  • 3.7.1.3. 长期收集监测测量指标或日志，确保整个系统运行在期望状态下

  • 3.7.1.4. 策略逐渐覆盖整个系统集群，从只覆盖系统的一部分直到百分之百完全覆盖

3.8. 供应商无关系统的价值

• 3.8.1. 构建与供应商无关的系统需要巨大的工程投入

• 3.8.2. 供应商无关网络将显著减少供应商移除过程所花费的时间，并且降低了风险

• 3.8.3. 调研新供应商

• 3.8.4. 试新供应商的系统

• 3.8.5. 使用Chef自动化系统重新配置

• 3.8.6. 真正对生产系统部署变更的时间只需要1周，并且不会对客户造成任何影响