微隔离入门（2）

从彻底映射数据流和架构开始   说起成功微隔离部署中的最大拦路虎，安全专家首推可见性问题。分隔粒度越细，IT 部门越需要了解数据流，需要理解系统、应用和服务之间到底是怎样相互沟通的。   Entrust Datacard 董事兼首席信息安全架构师 Jarrod Stenberg 表示，你不仅需要知道有哪些数据流流经你的路由网关，还需要具体追溯到单个主机，无论是实体主机还是虚拟主机。你必须拥有可供获取此信息的基础设施和工具，否则你的部署实现很可能失败。   这就是为什么任何成功的微隔离都需要从彻底的发现和映射过程开始的原因。Stenberg 解释道，作为该过程的一部分，公司企业应挖掘或编制自身应用的完备文档，文档可以支持未来所有微隔离决策，确保应用按既定方式运转。   NCC Group 安全咨询总监 Damon Small 表示，这种细致程度可能需要与供应商紧密合作，或者执行详细分析，确定哪里应该部署微隔离，以及如何在不引发生产中断的情况下部署。   使用威胁建模来定义用例   一旦公司建立起机制获取数据流可见性，这种理解就会开始带来风险评估和威胁建模。然后评估和建模再反过来帮助公司确定微隔离的位置和粒度。   vArmour 产品及策略高级副总裁 Keith Stewart 称：“有了这种理解，你就会开始认清自身环境中的风险，或者说你的‘爆炸半径’。攻击者侵入网络后能深入到哪里？用户数据库之类关键资产在不在该爆炸半径内呢？只要你能标出高风险区域，你就可以开始布置微隔离控制，解决这些风险。   思科 Duo Security 全球咨询 CISO Dave Lewis 表示，在没制定出详细的行动计划前，不要着手布置微隔离。因为微隔离以细粒度访问控制实现，要求大量的尽职调查与对细节的关注。   “必须十分重视微隔离前的恰当规划。要知道自己到底需要分隔什么。   WatchGuard Technologies 高级安全分析师 Marc Laliberte 表示，需要注意的一点是，微隔离可以多种不同技术方法实现，复杂程度也各不相同。   “一开始的计划应包含界定威胁模型，确定适合自己的微隔离形式。安全投资应基于公司及其应用面临的风险，还有成功攻击可能导致的破坏。   以业务需求进行平衡控制   威胁建模过程中，推进微隔离的策略师在设计微隔离时需时刻考虑到商业利益。   SAP NS2 CISO Ted Wagner 称表示，全面铺开的时候，分隔方案既要符合安全需求，也要提供必要的访问权，让应用和过程能无缝衔接，平滑工作。方案不能孤立设计或实现，得经过很多利益相关方的审查。   微隔离的成功需要安全部门与来自业务和 IT 的利益相关者协作，从一开始就深入了解所有这些流动中的应用和业务过程是怎么协同工作的。   Palo Alto Networks 全球系统工程高级副总裁 Scott Stevens 表示，有必要组建一支由企业主、网络架构师、IT 安全人员和应用架构师组成的多样化团队来实现该过程。   打造一支全方位团队还有助企业预先设立期望值，避开可能腰斩项目的那类政治问题。   思科的 Lewis 称，实现微隔离的主要障碍存在于和业务部门之间的沟通。以前就常在出问题时听人抱怨 “这肯定是防火墙弄的”。现在，微隔离成了内部业务部门刻薄批评的对象。

微隔离入门（3）

采用阶段式方法   专家建议，开始微隔离的公司企业理性对待微隔离项目推进速度。   Stevens 支招，从专注实用方法开始，而不是一来就搞大翻修。熟悉该过程的基本步骤：识别信息在公司中的流动方式，基于该信息流建立分隔的网络，创建更新的安全策略，纳入必需的安全功能，然后准备持续监视和更新该网络。   Entrust Datacard 的 Stenberg 建议采用一次处理一个应用的阶段式方法。   “这可以使你专注高优先级目标，完全锁定它们，同时又保留网络上其他东西的分隔控制。为控制粒度，应基于所处理和存储的数据的敏感度，根据需访问的用户来分组资产。   Ericom Software CTO Nick Kael 表示，微隔离项目不仅应该分解成可管理的部分分阶段实施，其部署过程也应设置能反映阶段性进展的里程碑和度量指标。这些项目可能复杂且耗时，所以在过程中显示进展很重要。   建立微隔离可持续性   随着公司不断往微隔离中引入更多资产，负责团队需考虑长远发展。正如 Woods 解释的，微隔离不是“设置了就可以丢开不管”的策略。   这意味着，企业需设立长期机制以维持数据流的可见性，设置技术功能以灵活维护策略改变与实施要求。还意味着需清晰描述微隔离配置管理中各人都负责做些什么。   SAP NS2 的 Wagner 表示，微隔离管理的角色和责任同样很重要。微隔离规则的改变应经过审查，类似配置控制委员会这种运营和安全团队可验证变更适当性的地方。   同时，企业不想受人工审批和修改过程的掣肘。所以，应尝试尽可能往维护过程中引入自动化。   Edgewise Networks 创始人兼 CEO Peter Smith 称：   “微隔离要求的很多费时费力工作如今都可以用机器学习加以自动化，包括查清应用相互通信的方式，确定能以最少数量提供最大覆盖面的规则集，以及持续跟进变更，尤其是在云环境中。   在策略方面，人类操作员将是最终决策者，但自动化应能帮助缩短审查所有东西的过程。   长远看，实行微隔离的所有努力都能帮助企业大幅降低不可避免的安全入侵风险。微隔离在增加安全控制的同时，还保留了发挥现代工作流和混合基础设施优势所必需的灵活性，而最终，无论你将其视为遵从最小权限原则还是实行零信任，微隔离都可帮助安全团队以细粒度维持 IT 资产的保密性、完整性和可用性。

负载均衡基础知识（1）

一、什么是负载均衡？ 　互联网早期，业务流量比较小并且业务逻辑比较简单，单台服务器便可以满足基本的需求；但随着互联网的发展，业务流量越来越大并且业务逻辑也越来越复杂，单台机器的性能问题以及单点问题凸显了出来，因此需要多台机器来进行性能的水平扩展以及避免单点故障。但是要如何将不同的用户的流量分发到不同的服务器上面呢？     　早期的方法是使用DNS做负载，通过给客户端解析不同的IP地址，让客户端的流量直接到达各个服务器。但是这种方法有一个很大的缺点就是延时性问题，在做出调度策略改变以后，由于DNS各级节点的缓存并不会及时的在客户端生效，而且DNS负载的调度策略比较简单，无法满足业务需求，因此就出现了负载均衡。     　客户端的流量首先会到达负载均衡服务器，由负载均衡服务器通过一定的调度算法将流量分发到不同的应用服务器上面，同时负载均衡服务器也会对应用服务器做周期性的健康检查，当发现故障节点时便动态的将节点从应用服务器集群中剔除，以此来保证应用的高可用。     　负载均衡又分为四层负载均衡和七层负载均衡。四层负载均衡工作在OSI模型的传输层，主要工作是转发，它在接收到客户端的流量以后通过修改数据包的地址信息将流量转发到应用服务器。   　七层负载均衡工作在OSI模型的应用层，因为它需要解析应用层流量，所以七层负载均衡在接到客户端的流量以后，还需要一个完整的TCP/IP协议栈。七层负载均衡会与客户端建立一条完整的连接并将应用层的请求流量解析出来，再按照调度算法选择一个应用服务器，并与应用服务器建立另外一条连接将请求发送过去，因此七层负载均衡的主要工作就是代理。

负载均衡基础知识（2）

二、四层和七层负载均衡的区别？ 2.1 - 技术原理上的区别。 　所谓四层负载均衡，也就是主要通过报文中的目标地址和端口，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。   　以常见的TCP为例，负载均衡设备在接收到第一个来自客户端的SYN 请求时，即通过上述方式选择一个最佳的服务器，并对报文中目标IP地址进行修改(改为后端服务器IP），直接转发给该服务器。TCP的连接建立，即三次握手是客户端和服务器直接建立的，负载均衡设备只是起到一个类似路由器的转发动作。在某些部署情况下，为保证服务器回包可以正确返回给负载均衡设备，在转发报文的同时可能还会对报文原来的源地址进行修改。       　所谓七层负载均衡，也称为“内容交换”，也就是主要通过报文中的真正有意义的应用层内容，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。   　以常见的TCP为例，负载均衡设备如果要根据真正的应用层内容再选择服务器，只能先代理最终的服务器和客户端建立连接(三次握手)后，才可能接受到客户端发送的真正应用层内容的报文，然后再根据该报文中的特定字段，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。   　负载均衡设备在这种情况下，更类似于一个代理服务器。负载均衡和前端的客户端以及后端的服务器会分别建立TCP连接。所以从这个技术原理上来看，七层负载均衡明显的对负载均衡设备的要求更高，处理七层的能力也必然会低于四层模式的部署方式。那么，为什么还需要七层负载均衡呢？

负载均衡基础知识（3）

负载均衡设备 2.2 - 应用场景的需求。 　七层应用负载的好处，是使得整个网络更"智能化", 参考我们之前的另外一篇专门针对HTTP应用的优化的介绍，就可以基本上了解这种方式的优势所在。例如访问一个网站的用户流量，可以通过七层的方式，将对图片类的请求转发到特定的图片服务器并可以使用缓存技术；将对文字类的请求可以转发到特定的文字服务器并可以使用压缩技术。   　当然这只是七层应用的一个小案例，从技术原理上，这种方式可以对客户端的请求和服务器的响应进行任意意义上的修改，极大的提升了应用系统在网络层的灵活性。很多在后台，(例如Nginx或者Apache)上部署的功能可以前移到负载均衡设备上，例如客户请求中的Header重写，服务器响应中的关键字过滤或者内容插入等功能。   　另外一个常常被提到功能就是安全性。网络中最常见的SYN Flood攻击，即黑客控制众多源客户端，使用虚假IP地址对同一目标发送SYN攻击，通常这种攻击会大量发送SYN报文，耗尽服务器上的相关资源，以达到Denial of Service(DoS)的目的。   　从技术原理上也可以看出，四层模式下这些SYN攻击都会被转发到后端的服务器上；而七层模式下这些SYN攻击自然在负载均衡设备上就截止，不会影响后台服务器的正常运营。另外负载均衡设备可以在七层层面设定多种策略，过滤特定报文，例如SQL Injection等应用层面的特定攻击手段，从应用层面进一步提高系统整体安全。   　现在的7层负载均衡，主要还是着重于应用广泛的HTTP协议，所以其应用范围主要是众多的网站或者内部信息平台等基于B/S开发的系统。 4层负载均衡则对应其他TCP应用，例如基于C/S开发的ERP等系统。   2.3 - 七层应用需要考虑的问题。 是否真的必要，七层应用的确可以提高流量智能化，同时必不可免的带来设备配置复杂，负载均衡压力增高以及故障排查上的复杂性等问题。在设计系统时需要考虑四层七层同时应用的混杂情况。   是否真的可以提高安全性。例如SYN Flood攻击，七层模式的确将这些流量从服务器屏蔽，但负载均衡设备本身要有强大的抗DDoS能力，否则即使服务器正常而作为中枢调度的负载均衡设备故障也会导致整个应用的崩溃。   是否有足够的灵活度。七层应用的优势是可以让整个应用的流量智能化，但是负载均衡设备需要提供完善的七层功能，满足客户根据不同情况的基于应用的调度。最简单的一个考核就是能否取代后台Nginx或者Apache等服务器上的调度功能。能够提供一个七层应用开发接口的负载均衡设备，可以让客户根据需求任意设定功能，才真正有可能提供强大的灵活性和智能性。

虚拟化安全威胁

虚拟化安全威胁 随着大数据、云平台的热潮席卷全球，大多数企业正在实施或者已经完成虚拟化，将传统硬件服务器系统迁移到虚拟化平台中，逐步向虚拟化方向迈进。 任何新业务的部署都会引入新的风险，因此，对于当前虚拟化大集中平台，安全风险不仅包含传统硬件架构中的风险，还会有因虚拟化引入的新的安全风险。本文主要讲解虚拟化后带来的新的安全风险。 Hypervisor安全威胁 在CVE的数据库中，虚拟化软件的漏洞累计超过超过700条，其中主要是vmware系统的。作为虚拟机的底层系统，一旦存在漏洞，将危及运行其上的所有虚拟机。 网络虚拟化安全威胁 虚拟化后，同一物理服务器上的不同虚拟机间可能通过硬件背板而不是网络进行通讯，因此这些通讯流量对标准的网络安全控制来说是不可见的，无法对它们进行监控或内嵌封堵。内嵌虚拟设备可以解决这个问题;另一个解决途径是硬件辅助虚拟化(Hardware AssistedVirtualization)，它需要与Hypervisor和虚拟化管理框架进行API级别的整合。 当一个可疑的虚拟机迁移进信任区域，在传统以网络为基础的安全控制措施下，将无法检测到它的不当行为。在每个虚拟机上安装全套的安全工具，是添加保护层的另一途径。 存储虚拟化安全威胁 虚拟化后，多租户对同一存储区域都有访问权。 租户数据迁移后，原磁盘释放给其他租户使用，原有数据未被彻底清除的话，也可能被新租户获取。 虚拟机镜像文件在休眠时是数据文件形式存数的，有被修改的风险。 对内存/存储清零或者对全部数据加密是此问题的解决方案。加密密钥应当存储在虚拟环境以外的一个基于策略的密钥服务器上。此外，如果没有使用加密或恰当的数据擦洗，虚拟机在运行的状态下迁移，自身可能面临风险。 网络边界模糊安全威胁 虚拟化后，一个物理接口上配置的不同网络的虚拟接口，逻辑网络间无明显边界，同一个租户可以运行在同一个物理机上，传统架构中的网络物理边界消失，只能通过逻辑域划分界定边界，虚拟化环境中，防火墙做逻辑隔离，内部通过虚拟交换机和VlAN标记等方式来界定防火墙保护特定的区域，以弥补防火墙在物理位置上不能清楚的体现的缺陷。 特权用户安全威胁 虚拟化环境下，除了租户可以访问自己的数据外，管理员由于需要对资源进行管理，因此也可以接触数据，SaaS提供商可能会利用其它PaaS、IaaS的服务，因此也可能会有特权用户，从而可能造成数据泄露、损坏或被修改。因此必须控制好权限分配，以防止操作不当或恶意删除等安全威胁。 总之，同其它任何新技术一样，虚拟化安全有自己的安全挑战。既不能认为虚拟化后的安全同传统架构的安全大同小异，也不能认为虚拟化后的安全不能保证，只有采取适当的安全解决方案后，虚拟化网络的安全仍然是可以保证的。