读零信任网络：在不可信网络中构建安全系统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. 更好地隔离故障
  

1. >  3.3.2.2.1. 该方案事实上是采用大量“微型防火墙”代替了传统的完整防火墙
3. >  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周，并且不会对客户造成任何影响
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。