ToB企服应用市场:ToB评测及商务社交产业平台

标题: 读零信托网络：在不可信网络中构建安全体系15协议和过滤 [打印本页]

---

作者: tsx81428    时间: 2024-8-11 21:31
标题: 读零信托网络：在不可信网络中构建安全体系15协议和过滤

1. 协议

1.1. IKE/IPSec

• 1.1.1. 因特网密钥交换协议（Internet Key Exchange,IKE）用于执行IPSec认证和密钥交换
  
• 1.1.1.1. 通常以配景守护进程的方式实现，使用预共享密钥或X.509证书来认证对端并创建一个安全会话
  
• 1.1.2. IKEv1与IKEv2
  
• 1.1.2.1. IKEv1过于复杂，性能也不太好
  
• 1.1.2.2. 相比于IKEv1, IKEv2更为灵活和可靠
  
• 1.1.2.3. 强烈发起使用IKEv2
  
• 1.1.3. IPSec不是单一的协议，而是一系列协议的集合
  
• 1.1.4. IKE可以被认为是IPSec的控制平面，它处理会话协商和认证，使用协商的效果为端点设置会话密钥和加密算法
  
• 1.1.5. 由于核心的IPSec协议内嵌在IP协议栈中，因此IPSec通常在内核中实现
  
• 1.1.5.1. 密钥交换是一种相对复杂的机制，IKE以用户态的守护进程情势实现
  
• 1.1.5.2. 内核维护的状态定义了IPSec安全关联，流量选择器则定义了对哪些流量应用IPSec策略
  

1.2. 身份认证凭据

• 1.2.1. IKEv2支持预共享密钥和X.509证书
  
• 1.2.2. 还支持可扩展身份验证协议（EAP）​
  
• 1.2.3. 支持EAP意味着IKEv2通过代理可以支持大量其他的身份验证方法（包括多因素认证）
  
• 1.2.4. X.509证书是IKE的首选认证方法
  
• 1.2.4.1. X.509证书不是为人工使用准备的，它们用于设备。证书不光携带信托证实，而且提供了带有署名的元数据，以及一种利用其身份对数据进行强加密的方法
  
• 1.2.5. IKEv2支持预共享密钥，但我们强烈反对使用它们，其带来了大量的密钥生成和分发题目，但最重要的是，必要人为记忆这些预共享密钥
  

1.3. IKE SA_INIT和AUTH

• 1.3.1. 所有的IKEv2密钥交换都从一对名为IKE_SA_INIT的数据包交换开始，这个初始交换决定密码套件的选择（和Diffie-Hellman交换一样）​
  

1.4. 密码套件选择

• 1.4.1. IPSec的密码选择比TLS稍微复杂一些
  
• 1.4.1.1. IPSec是在内核中实现的，相较于以软件包的情势实现，其对密码支持的要求更严苛
  
• 1.4.2. RFC 6379提出了被称为套件B的密码套件，该标准是由美国国家安全局撰写的，它是一个被广泛接受的IPSec密码套件标准
  
• 1.4.3. 不是所有的IPSec实现都支持椭圆曲线算法，而套件B强制要求椭圆曲线加密
  
• 1.4.4. 对于主流椭圆曲线算法的安全性的担心，很多人认为国家政府相关人员的干预大概会影响其安全性
  

1.5. IPSec安全关联

• 1.5.1. 4个不同状态：幼年（larval）、成熟（mature）、弥留（dying）和死亡（dead）​
  

1.6. IPSec隧道模式

• 1.6.1. 隧道模式是目前广泛摆设的模式，当IPSec在隧道模式下运行时，SA包含了远程端点的信息，用于封装IP数据包并且在路由到端点的过程中掩护它
  
• 1.6.2. 经常用于VPN，在必要与远程网络创建安全连接的环境下，管理员能够接纳隧道方式将流向该网络的流量通过安全通道进行传输
  
• 1.6.3. 既然是隧道模式，那就意味着流量在某个时间点会变得不受掩护
  
• 1.6.4. 发送者与中心网络之间传输的安全是可以确保的，但在此之后，将无法保证安全性
  
• 1.6.4.1. 认为隧道模式其实与零信托体系结构相矛盾
  

1.7. IPSec传输模式

• 1.7.1. 传输模式提供了几乎雷同的安全保证，只是减去了隧道的部分
  
• 1.7.2. 它没有封装整个IP数据包，而是封装了IP有效负载，这对于主机到主机的直接IP通信非常有用
  
• 1.7.3. 传输模式并不是与网络中心设备创建一个安全联盟，而是与流量的目的端点直接创建安全联盟，确保端到端应用安全，这个属性使得传输模式能够很好地适用于零信托网络
  
• 1.7.4. 成熟的零信托数据中心架构应该选择IPSec的传输模式
  

1.8. 将IKE/IPSec用于设备认证

• 1.8.1. 由于IPSec直接在IP上实现，因此它可以处理大多数应用程序流量，而不仅仅是TCP和UDP
  

2. 双向认证TLS

2.1. 传输层安全（TLS，通常会相沿其前身SSL的称呼）是用来掩护Web流量的常见协议

• 2.1.1. 它是一种成熟的、易于理解的协议，被广泛地摆设和支持，并且已经获得一些敏感业务的信托
  
• 2.1.2. HTTPS中的S指代的就是TLS（SSL）
  
• 2.1.3. 面向一般公众的服务可以接受客户端身份认证的缺失，但其他任何用例都不可接受这种妥协
  
• 2.1.4. 双向身份认证是遵照零信托模型安全协议的须要条件，TLS也不破例
  

2.2. 在TLS密码套件中有4个主要的组件

• 2.2.1. 密钥交换
  
• 2.2.2. 身份验证
  
• 2.2.3. 块加密
  
• 2.2.4. 消息完备性
  

2.3. 体系的整体安全性取决于较弱的客户端能提供的最强密码套件

• 2.3.1. 在TLS握手中，客户端按优先次序表现其支持的密码套件列表，如果客户端和服务端支持的密码套件有重合，那么服务器会从这个列表中选择一个密码套件，否则会话创建就大概失败
  
• 2.3.2. 发起服务器只支持最合理的密码套件
  

2.4. 协商是一个缺点

• 2.4.1. 码套件协商被认为是现代加密协议中的反模式
  
• 2.4.2. 较新的协议和框架，如Noise，旨在消除协议协商
  

2.5. 密钥交换

• 2.5.1. TLS的密钥交换形貌了在不安全的通道上安全地生成加密密钥的过程
  
• 2.5.2. 它们使用数学函数来协商密钥，而不用明文进行传输（在大多数环境下是如许）​
  
• 2.5.3. TLS支持3个主流的密钥交换/协商协议，按照优先次序排列，它们是ECDHE、DHE和RSA
  
• 2.5.4. ECDHE基于Diffie-Hellman交换，使用椭圆曲线来协商一个密钥
  
• 2.5.4.1. 椭圆曲线密码具备高强度、高服从的特点，它创建在一个难以办理的数学题目的底子之上
  
• 2.5.4.2. 从安全性和性能上考虑，它是理想的选择
  
• 2.5.5. DHE同样基于Diffie-Hellman交换，但它使用模运算而不是椭圆曲线来协商一个密钥
  
• 2.5.6. RSA密钥交换基于非对称运算来验证数字署名的身份（如X.509证书）​，它使用服务器的公钥来加密传输必要的共享密钥
  
• 2.5.7. 当今主流的公钥密码学都基于如许一种假设，即分解较大数字的计算开销非常大
  
• 2.5.7.1. 经典的计算必须依赖于一种被称为普通数域筛选法的技术来推导出大数因子，这是一种相对低效的算法
  
• 2.5.7.2. Shor算法是一种比一般数域筛选更有效的量子算法，只要有足够强大的量子计算机，它就可以被用来快速破解大多数非对称密钥交换协议
  

2.6. 完善的前向保密性

• 2.6.1. PFS（完善的前向安全性）是一种加密属性，基于PFS，私钥的披露不会导致之前协商的会话的走漏
  
• 2.6.2. 可以确保窃听者不能记录会话数据以供之后解密
  
• 2.6.3. RSA密钥交换不支持PFS
  
• 2.6.3.1. 因为我们是直接使用私钥加密和传输会话密钥的
  
• 2.6.4. 必须使用DHE或ECDHE以获得完善的前向安全性
  
• 2.6.5. 经心设计服务器端密码套件，在可用的环境下先选择DHE协商，须要时返回到ECDHE协商
  

2.7. 认证

• 2.7.1. 有3种常见的认证方法：RSA、DSA和ECDSA
  
• 2.7.2. RSA认证是较常见的，它在超过99%的基于Web的TLS资源中使用
  
• 2.7.3. DSA认证已不再保举使用
  
• 2.7.4. EDCSA是DSA的新表兄，它使用椭圆曲线来提供公/私钥对
  

2.8. 职责分离

• 2.8.1. 必要掩护的资源是设备，因此将加密功能独立于工作负载本身非常有意义
  
• 2.8.2. 要确保所有这些应用程序都确实通过正确的方式使用TLS，在已知漏洞上保持最新状态是非常困难的
  
• 2.8.3. 将TLS的设置职责转移到控制平面是非常有用的
  
• 2.8.3.1. 到服务的连接被TLS守护进程代理，然后本地转发给应用程序
  
• 2.8.3.2. TLS守护进程设置了体系证书、信托权限和节点信息
  
• 2.8.3.3. 通过这种方式，可以确保所有的软件都接受设备认证和TLS的安全掩护，而不管软件是否支持TLS库
  
• 2.8.4. 零信托网络对业务流接纳了“白名单”机制，以是可通过限制到已知TLS端点的业务流白名单，确保应用程序业务流量受到掩护
  

2.9. 块加密

• 2.9.1. TLS握手主要有两个目的：认证和会话密钥的创建
  
• 2.9.2. 当无须考虑身份或认证题目时，使用对称加密就可以满意所需的安全强度
  
• 2.9.3. 对称加密使用一个单独的密钥而不是公/私钥对，并且与非对称加密相比其计算本钱要低得多
  
• 2.9.4. 业界一致发起接纳AES
  
• 2.9.4.1. 它设计完善，并且没有专利掩护，可以在硬件中广泛实现，并且已在软件中普遍接纳
  
• 2.9.4.2. 它非常高效，经过严格的检察/检查，并且保持一致性
  

2.10. ⑩消息完备性

• 2.10.1. 消息的完备性纵然不是必需的也是一个重要属性
  
• 2.10.2. 完备性算法的选择仅限于MD5和SHA系列的散列算法
  
• 2.10.2.1. 前者已经被破解
  
• 2.10.2.2. 这使得SHA系列成为TLS确保消息完备性的唯一合理选择
  
• 2.10.2.3. 不断增长的计算本领导致SHA-1脆弱并易受攻击
  
• 2.10.2.4. 发起选择可以合理摆设的最强SHA散列算法
  

2.11. ⑾基于双向TLS进行设备认证

• 2.11.1. TLS是依赖于协议的
  
• 2.11.1.1. 它通常基于TCP协议实现，虽然基于UDP的协议变种DTLS也是可用的
  
• 2.11.2. 只要代理和掩护的上游节点被一个计算机网络分离开，这种运行模式就不适用于零信托网络
  
• 2.11.3. 在零信托网络中，基于TLS协议实现的通信代理必须和应用程序摆设在一个逻辑主机上
  
• 2.11.4. 在用TLS掩护数据中心零信托网络时，应用必要主动化设置以便使用外部的TLS通信，它不像IPSec协议那样是“免费”加密
  
• 2.11.5. TLS仍然是目前掩护面向客户的零信托网络的较好选择，它在软件和传输网络中都得到了广泛的支持，并且其运作模式直接而可信赖
  
• 2.11.6. 大部分Web浏览器本身就支持双向TLS认证，这意味着资源可以直接基于零信托原则进行掩护而不必要专门的客户端软件
  

3. 过滤

3.1. 过滤是数据包被网络上的体系接受或拒绝的过程
3.2. 防火墙确实提供了过滤作用，但它们也可以提供其他服务

• 3.2.1. 网络地址转换（NAT）
  
• 3.2.2. 流量控制
  
• 3.2.3. VPN隧道服务
  

3.3. 传统意义上过滤功能可以由很多体系提供，比如路由器或交换机
3.4. 过滤是一种简单的服务，在网络体系的很多地方都可以应用它
3.5. 很多零信托概念都集中在高级加密和认证体系上，这是因为网络安全的这些方面没有得到应有的设计和考虑

• 3.5.1. 不应该低估网络过滤的重要性，它仍然是零信托架构的关键组成部分
  

4. 主机过滤

4.1. 过滤主机上的流量

• 4.1.1. 主机过滤让网络端点成为其自身安全的积极到场者，其目标是确保每台主机都被设置为过滤自己的网络流量
  

4.2. 防火墙利用专用集成电路（Application-Specific Integrated Circuit, ASIC）来有效地处理流经设备的数据包
4.3. 软件防火墙比硬件防火墙要灵活很多，它们提供了一组丰富的服务

• 4.3.1. 比如根据日期和恣意的数据偏移（字段）来定义策略
  
• 4.3.2. Linux:IPtable
  
• 4.3.3. BSD体系：Berkley包过滤（BPF）
  
• 4.3.4. macOS：应用程序防火墙和基于下令行的主机防火墙
  
• 4.3.5. Windows:Windows防火墙服务
  

4.4. 零信托网络假设网络中始终充满威胁，必要在每个大概的位置过滤网络流量，通常使用主机防火墙实现
4.5. 通过主机防火墙可以过滤不良网络流量来减小主机的攻击面
4.6. 主机过滤非常容易着手实施，设置管理体系很好地支持了主机防火墙的管理
4.7. 在安全设计中隔离的好处，主机过滤可以从中受益
4.8. 关于主机过滤的题目是，其摆设点在网络中的位置太“深”了，会造成大量的额外本钱

• 4.8.1. 增加了拒绝服务（DoS）攻击的大概性，使内部网络充斥大量的无用流量，压垮了相对脆弱的软件防火墙
  

5. 双向过滤

5.1. 同时过滤主机的出入流量

• 5.1.1. 一种在接收和发送数据包时同时应用的过滤策略
  

5.2. 出站（入站的反面）这个术语用来形貌离开主机的网络流，这种类型的过滤通常用于管理从私有网络到公共网络的通信，它很少在私有网络内部使用

• 5.2.1. 入站过滤更容易理解，因为在构建防火墙规则时可以罗列出所有的监听服务，出站过滤则必要更多的记录来得知主机如何进行通信
  
• 5.2.2. 通常认为，入站过滤能够制止网络中的不良通信
  
• 5.2.3. 出站过滤必要相识每一个预期的流量，这在传统网络中不常见
  

5.3. 纵然在体系中出现了关键的错误设置，一个摆设了全面的双向过滤机制的网络也会受到掩护
5.4. 双向过滤不是防备疾病，而是掩护被错误设置的体系能够免受错误设置带来的潜伏影响
5.5. 在体系中构建双向过滤并没有那么困难，可以通过程序化实现对通信业务流的捕获，捕捉这些流的较好方法是定义细粒度的入站规则
5.6. 出站过滤机制最好与运行在体系上的应用程序隔离，发起在虚拟化或容器化环境的外层实现过滤以便拥有结实的过滤机制
5.7. 当网络流数据库与运行体系隔离时，双向过滤是较有效的
5.8. Calico项目是动态调度工作负载的虚拟网络体系
6. 中心过滤

6.1. 通过两个主机间的设备过滤流量

• 6.1.1. 指除了发送方或接收方之外的设备在零信托网络中可以并且应该到场到流量过滤中
  

6.2. 边界过滤在零信托网络中可以发挥作用，并且在网络结构中的中心设备也可以发挥作用
6.3. 高吞吐量的过滤流量通常是来自互联网入口的流量，在理想环境下，我们希望尽快过滤流量，以淘汰耽误过滤的影响和本钱
6.4. UPnP被认为是有害的

• 6.4.1. 从主机策略衍生出的边界策略不应该与UPnP混合使用
  
• 6.4.2. UPnP是一种用于重新设置用户防火墙的技术
  
• 6.4.3. UPnP受到诟病是因为网络上的任何应用程序都可以重新设置边界，在零信托模型中，主机策略和边界创建的破例规则之间应该存在信托链
  

6.5. 零信托网络不会抛弃所有的边界概念，相反，它们鼓励管理员从主机开始向外扩展，边界设备最终会以某种方式发挥作用，而值得关注的是其在缓解拒绝服务攻击上的应用
6.6. 使用主机策略数据库来动态地规划网络结构本身
6.7. 软件定义网络（Software-Defined Network,SDN）

• 6.7.1. 它不会盲目地将数据包路由到目的地址，而是根据预期和允许的流量，积极管理交换和路由策略
  
• 6.7.2. 将潜伏的恶意流量挡在主机之外，淘汰了攻击面
  
• 6.7.3. 主机上基于软件的防火墙在网络中增加了额外的防御层
  
• 6.7.4. 想象一个SDN控制器，它只根据强身份认证和授权过程的效果实现流量传输，希望访问网络资源的客户端可以向控制平面发出信号，提供网络访问请求以及相应的凭据，请求成功授权之后，网络过滤或转发规则就会被下发并且执行，但这些规则仅针对特定的已授权业务流
  

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

---

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)

Powered by Discuz! X3.4