读零信任网络：在不可信网络中构建安全系统14流量信任

1. 流量信任

1.1. 网络流的验证和授权是零信任网络至关重要的机制

1.2. 零信任并非完全偏离已知的安全机制，传统的网络过滤机制在零信任网络中仍然扮演着重要的角色

2. 加密和认证

2.1. 加密和认证通常是紧密相关的，尽管其目的截然不同

• 2.1.1. 加密提供机密性，用于确保只有接收者才能读取发送的数据

• 2.1.2. 认证则用于确保接收者可以验证消息确实是由所声称的对象发送的

2.2. 认证还有另外一个有趣的特性，为了确保消息是可信的，必须能够验证发送者以及发送的消息未被篡改，这是消息认证的基本属性，它被称为完整性

2.3. 加密也可以不与认证同时使用，但一般认为这是一种非常糟糕的安全实践

• 2.3.1. 由于身份认证的缺失引发了更多的攻击向量，因此业界对此的看法高度一致，强烈建议同时使用加密和认证

2.4. 消息的真实性是零信任网络的一个必选需求，没有它就无法构建零信任网络

2.5. 加密能够保证机密性，但偶尔也会带来麻烦

• 2.5.1. 只有经过复杂的解密过程才可以读取捕获的数据包内容，这会导致故障排除变得更加困难

• 2.5.2. 如果不能检查网络流量，那么入侵检测就很难甚至不可能实现

• 2.5.3. 如果想放弃加密机制，那么一定要确保数据机密性对系统而言并不重要

• 2.5.4. 通过各种理由来拒绝对业务流量进行加密是完全站不住脚的

• 2.5.5. 在真实场景中，真正不需要机密性的系统是非常少见的

2.6. 认证仍然是必需的

• 2.6.1. 很少有网络协议提供强认证机制但不提供加密

3. 首包认证

3.1. 网络流中的首个数据包职责重大，根据连接的类型或者设备生命周期的时间点，首个数据包所蕴含的信任度极其有限

3.2. 在数据中心内部对各类数据流的预期是比较清楚的

3.3. 在面向客户的系统中，谁都无法预测，因为这类系统一般是广泛可达的，这大大增加了风险

3.4. 所谓的首包信任问题，通常采用预认证的方式来解决

• 3.4.1. 预认证操作模式也称为单包授权（Single Packet Authorization, SPA）

• 3.4.2. 通过为认证请求设定预期，预认证可以被认为是对认证请求的授权，它往往通过为一小段数据加密和/或签名，并使用UDP协议将数据包发送至资源方来完成

• 3.4.3. 使用UDP进行预认证非常重要，因为UDP传输是无连接的，默认无须响应，这个特性允许信息接收方“隐藏”自己，只有其接收到采用正确密钥加密的数据包时才会做出响应暴露自己

• 3.4.4. 被动接收一个经过正确加密的预认证数据包后，就可以让信息发送方启动身份认证流程了，可以对防火墙过滤规则进行细粒度控制，仅仅为此发送方打一个“洞”​，让此发送方与系统的TLS服务器通信

3.5. 将SPA作为设备认证协议并不完全合适，它仅仅有助于解决首包信任问

3.6. 虽然SPA机制对于预认证来说极其重要，但不能用SPA代替更为稳定的双向认证协议，比如TLS或者IK

4. fwknop

4.1. 一个流行的SPA开源实现，它支持多种操作系统，并且与主机防火墙集成以便创建具有严格范围的短时例外

4.2. 短时例外

• 4.2.1. fwknop创建的防火墙规则是严格限定范围的，它只允许发送方的IP地址和发送方请求的目的端口号通过，并且可以通过策略限制不同用户的可请求目标端口范围

• 4.2.2. 发送方还可以指定一个源端口号，进一步限制防火墙规则的范围

4.3. 单包授权载荷

• 4.3.1. fwknop SPA实现的有效载荷中包含7个必选字段和3个可选字段，其中包括用户名、访问请求自身的一些信息（端口号等）、时间戳和一个校验和

• 4.3.2. 一旦客户端生成了有效载荷，就可以对其进行加密，添加一个可选的HMAC, SPA数据包就成功生成并可以传输了

4.4. 载荷加密

• 4.4.1. AES

  • 4.4.1.1. 个人应用程序或小型部署场景更倾向于AES

  • 4.4.1.2. 不要求任何GnuPG工具，并且AES在数据量和计算开销方面性能更优

  • 4.4.1.3. 对称加密的密钥分配问题很难解决，而且在一定程度上，其带来的挑战变得难以应对

• 4.4.2. GnuPG

  • 4.4.2.1. GnuPG加密模式解决了大部分对称加密的问题，它是推荐的操作模式

  • 4.4.2.2. 在性能方面，GnuPG肯定不如AES

4.5. HMAC

• 4.5.1. fwknop可以在其有效载荷的最后添加HMAC，散列消息验证码（Hashed Message Authentication Code, HMAC）可以保证消息的真实可靠性，以防止篡改

• 4.5.2. 包括一个消息摘要字段，它是与明文一起计算并存储的

  • 4.5.2.1. 这个消息摘要有助于减少密文被篡改的威胁，但不够理想，因为这种方法（被称为“验证并加密”或AtE）容易受到一些特定类别的攻击

  • 4.5.2.2. 在加密的有效载荷后追加HMAC可以防止这些攻击生效

• 4.5.3. 解密程序通常比HMAC程序要复杂得多，这意味着它们更易遭受攻击

• 4.5.4. 通过为密文添加HMAC，使得接收者能够进行轻量级的完整性检查，这样接受者只需发送验证通过的可信数据到解密程序即可

• 4.5.5. 强烈建议在fwknop中启用HMAC

5. 网络模型

5.1. 每一层都负责网络传输数据的一部分工作

• 5.1.1. 分层定义的机制还有利于描述新技术在网络栈中运行的位置

• 5.1.2. 4层负载均衡器不用考虑7层的数据，因此它仅仅能够基于简单的网络连接信息（如源IP和端口号）来转发和路由流量

5.2. OSI网络模型

• 5.2.1. 1984年发布

  • 5.2.1.1. 国际标准化组织ISO发布了ISO 749

  • 5.2.1.2. 国际电信联盟电信标准化局（ITU-T）发布了X.200

• 5.2.2. 第1层——物理层

  • 5.2.2.1. 被定义为网络设备和承载网络传输的物理介质之间的接口，其中包括引脚布局、线路阻抗、电压和频率

• 5.2.3. 第2层——数据链路层

  • 5.2.3.1. 负责在物理层上传输数据。数据链路层仅考虑直连节点间的数据传输，并不考虑在互联的网络之间如何进行数据传输

• 5.2.4. 第3层——网络层

  • 5.2.4.1. 负责在两个相互连接的节点之间传输数据包

• 5.2.5. 第4层——传输层

  • 5.2.5.1. 建立在第3层的简单数据包传输能力之上，它通常作为控制协议来为第3层扩展一些必要的服务

    5.2.5.1.1. 有状态连接

    5.2.5.1.2. 多路复用

    5.2.5.1.3. 有序发送

    5.2.5.1.4. 流量控制

    5.2.5.1.5. 重传

  • 5.2.5.2. TCP就是第4层协议，不过和网络层的IP协议类似

• 5.2.6. 第5层——会话层

  • 5.2.6.1. 为连接提供了额外的状态层，并允许恢复通信

  • 5.2.6.2. 多个VPN（PPTP、L2TP）和代理协议（SOCKS）都工作在这一层

• 5.2.7. 第6层——表示层

  • 5.2.7.1. 与应用程序开发人员频繁发生交互的一层，这一层负责处理应用程序数据（通常是结构数据）和可传输的数据流之间的转换

  • 5.2.7.2. 通常还负责加密和压缩之类的工作

  • 5.2.7.3. TLS是工作在表示层的协议，尽管只在会话建立后它才开始在第6层上运行

• 5.2.8. 第7层——应用层

  • 5.2.8.1. OSI模型的最高层，它提供了应用程序在网络上通信的高级通信协议

  • 5.2.8.2. 常见协议有DNS、HTTP和SSH协议

5.3. TCP/IP网络模型

• 5.3.1. TCP/IP模型没有试图通过明确的边界来定义严格的层

• 5.3.2. RFC 3439记录了针对互联网架构师的“哲学指导方针”​，其中有一节名为“深思熟虑，认为分层是有害的”​

• 5.3.3. 链路层

• 5.3.4. 互联网层

  • 5.3.4.1. 一般与第3层相关联

• 5.3.5. 传输层

  • 5.3.5.1. 大致可以映射到第4层

  • 5.3.5.2. 通过引入端口的概念它具备了一些第5层的特性

• 5.3.6. 应用层

  • 5.3.6.1. 大致覆盖了OSI模型中的第5～7层

6. 零信任在网络模型中的位置

6.1. TLS

• 6.1.1. TLS（传输层安全，其前身是SSL）相对较为常见，许多应用层协议支持通过TLS来保护流量

• 6.1.2. TLS并不工作在TCP/IP模型的传输层，而是工作在应用层（在OSI模型的第5层和第6层之间）​

• 6.1.3. 基于边界的网络经常将TLS从应用程序中抽象出来，将其职责从应用程序转移到基础设施

6.2. IPSec

• 6.2.1. IPSec是一种替代协议，通常用于VPN场景

• 6.2.2. IPSec通常被认为是TCP/IP模型中互联网层的一部分（OSI模型中的第3层或者第4层，这取决于不同的理解）

• 6.2.3. IPSec本身是为IPv6规范开发的，它最初是IPv6的一个需求，但最终被降级为推荐项

  • 6.2.3.1. 因为IPv6标准包含IPSec，所以希望随着IPV6的逐步采用，IPSec能够成为网络环境下的可行解决方案

• 6.2.4. 使用IPSec可以明确保护主机之间的通信

  • 6.2.4.1. 由于IPSec被深度集成到网络栈中，因此可以将其配置为仅允许在建立了安全通道之后再进行数据包传输

  • 6.2.4.2. 接收方可以配置为只处理通过安全通道发来的数据包

  • 6.2.4.3. 只有安全的流量才能通过

  • 6.2.4.4. 它可以一次性为一个应用程序增加安全通信

6.3. 零信任的目标是保证所有流量的安全通信，实现这一目标的较好方式是构建默认安全通信的系统，作为一种底层服务，IPSec能够很好地提供这种默认服务

6.4. 仅保护两个设备之间的通信是不够的，还需要确保每个单独的网络流都是经过授权的

• 6.4.1. IPSec可以为每个应用程序配置使用唯一的安全关联（SA）

  • 6.4.1.1. 只有经过授权的流量才允许构造这些安全策略

• 6.4.2. 过滤系统（软件防火墙）可以叠加在IPSec之上

• 6.4.3. 应通过应用程序级授权来确保通信得到授权，可以使用标准的授权技术（如访问令牌或X.509证书）​，同时将强大的加密和认证职责委派给IPSec栈

• 6.4.4. 对于一个真正具备双重保障的系统，双向TLS认证可以被叠加在现有的IPSec层之上

  • 6.4.4.1. 这种纵深防御的方法提供了两层加密（MTLS和IPSec）​，确保即使其中一层被攻破，通信仍能得到保护

  • 6.4.4.2. 这是以复杂性和额外的开销为代价的

6.5. 网络支持问题

• 6.5.1. 网络支持问题会阻碍IPSec的大规模应用，IPSec引入多个新协议，其中有两个（ESP和AH）IP协议

• 6.5.2. 大型公有云提供商Amazon的Web服务不允许在其网络上传输ESP或AH流量

• 6.5.3. IPSec支持在UDP报文中封装流量

  • 6.5.3.1. 这种封装允许不友好的网络进行流量传输，但它在一定程度上增加了系统的复杂性

6.6. 设备支持问题

• 6.6.1. IPSec标准是复杂的，它包括许多配置选项和密码套件

• 6.6.2. 在IPSec系统中还没有一个非常强大的密码套件

• 6.6.3. IPSec同样需要主动配置相关的设备，在设备能力不同的客户端/服务器系统中，配置客户端设备可能相当具有挑战性

• 6.6.4. 桌面操作系统通常可以支持不那么主流的协议，然而，移动操作系统的局限性更大，它难以通过符合零信任模式的方式完全支持IPSec

6.7. 应用支持问题

• 6.7.1. 和基于TLS的方案相比，IPSec对系统配置的要求更高

• 6.7.2. 使用IPSec的系统需要配置IPSec策略，为所需的密码套件启用内核支持，并运行IKE守护进程来实现IPSec安全关联的协商

• 6.7.3. Web浏览器通常是访问一个组织各类系统的公共接入点，它支持现代TLS（假设组织保证使用浏览器的最新版本）​

• 6.7.4. 在服务器端，许多组织正在向一种新模式转变，这种模式通过本地的守护进程集中保护网络通信，它将配置集中在单个应用程序中，并且允许系统管理员提供基本的网络安全层，在某种程度上，它看起来类似于IPSec模型，但是其实现基于TLS

6.8. 实用解决方案

• 6.8.1. 对于客户端/服务器的交互，使用双向认证的TLS协议似乎是一种合理的网络安全方案

  • 6.8.1.1. 这会限制零信任仅支持基于浏览器的Web应用

• 6.8.2. 对于服务器/服务器的交互，IPSec似乎更实用，服务器机群（Fleet）的配置通常更可控，并且网络环境更明确

• 6.8.3. 对于不支持IPSec的网络，UDP封装可以用来解决网络传输问题

6.9. 微软服务器隔离

• 6.9.1. 对于完全使用带有AD域的Microsoft Windows环境来说，一种被称为服务器隔离的特性尤其具有吸引力

• 6.9.2. 服务器隔离可以与AD域的安全组绑定，提供细粒度的访问控制，强大的IPSec认证为这种模式提供支持

• 6.9.3. 服务器隔离可能是在基于Windows的环境中实现零信任的较实用方法