读零信托网络：在不可信网络中构建安全体系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层扩展一些须要的服务
  

1. >  5.2.5.1.1. 有状态连接
3. >  5.2.5.1.2. 多路复用
5. >  5.2.5.1.3. 有序发送
7. >  5.2.5.1.4. 流量控制
9. >  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的情况中实现零信托的较实用方法
  

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