读零信托网络：在不可信网络中构建安全体系14流量信托
https://i-blog.csdnimg.cn/direct/fc56284aca6342eebd786405b9858971.jpeg1. 流量信托
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的环境中实现零信托的较实用方法
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]