版权所有 © 2019 深圳市安盟信息科技有限公司 All Rights Reserved
手机官网二维码
分享给好友
联系我们
0755-86375372
深圳市南山区科研路9号比克科技大厦24楼2401-I单元
微信公众号
社交平台
新闻中心
祝贺安盟信息荣获“2022 财年 SonicWall 亚太地区合作伙伴奖"
详细内容
Sonicwall SMA 远程办公
详细内容
数据脱敏方法选择框架
详细内容
数据脱敏的最大难点在于平衡隐私保护和数据挖掘需求，从某种意义上，运营商必须要致力保护的隐私内容（具体某个用户的具体位置、社会关系、访问内容等）可能也正是外部第三方希望通过挖掘得到的内容。基于上述对运营商大数据应用特点的分析，结合具体应用场景，在选择脱敏方法时应该考虑以下6个因素：
（1）应用对数据可用性的要求，即脱敏后的数据满足分析应用需要的程度。如果脱敏后的数据完全无法用于目标分析，其也不具备使用价值。在特定的应用场景中，可能需要残留部分非关键信息（如手机号码部分字段、手机位置等）才能满足分析需求。
（2）应用对数据真实性的要求。这里的真实性是指脱敏后的数据对原有数据逻辑特征、统计分布特征的保留程度。绝大部分应用，特别是数据服务类应用对数据统计分布特征都有明确要求；同时对于复杂业务，其相关信息可能跨表跨库，数据间的逻辑特征也必须予以保留。
（3）应用对数据时效性的要求，即脱敏后数据需要在哪个时段内提供才有进一步分析挖掘的意义。
（4）应用对数据可重现性的要求，即相同参数配置下，相同源数据脱敏后的数据是否必须一致。
（5）脱敏方法资源占用。需要结合源数据量、源数据间行内同步、表内同步、跨表同步、跨库同步要求，考虑不同脱敏方法对计算资源、存储资源的需求。资源占用对数据时效性也会有潜在影响。
（6）脱敏方法可配置性。是否可以结合需求，通过对脱敏方法的配置生成个性化的脱敏后数据。
上述几个要素中，脱敏方法资源占用主要需考虑企业内部的资源约束，除此以外都和具体应用相关。
数据脱敏仅仅是运营商企业内部信息安全管理的一个环节，现有的脱敏方法既要服务于企业业务发展，也要遵从整体的IT安全治理要求，脱敏方案的制定和方法的选择需要业务需求单位（包括第三方）、IT安全监管单位和数据实际管控单位协同才能取得预期的成果。
常用数据脱敏架构和方法
详细内容
所谓数据脱敏（ D a t a M a s k i n g ） 是对个人身份识别数据（personal identifiable data）、个人敏感数据（personal sensitive data）和商业敏感数据（commercially sensitive data）进行伪装，以便用于生产系统以外的地方[3]。数据脱敏不是新的技术，当前也有很多成熟的商用解决方案可以选择，如Oracle的Data Masking组件[4]、IBM的InfoSphere OptimData Privacy产品[5]、Informatica的Informatica DataMasking产品[6]等，其中Informatica的产品可以实现对异构数据的脱敏处理。针对特定的生产环境（如异构系统），也可以自己创建脱敏平台或系统进行脱敏处理。脱敏后数据的服务对象，可以是企业内部统计分析、企业生产系统的开放、测试环境，也可以是外部第三方。当然，面向不同的服务对象，针对其服务要求，脱敏的级别和方法也有不同。
从架构的角度看，数据脱敏有2种常用架构：
（1）动态（On the Fly/Dynamic）数据脱敏架构。指数据脱敏规则应用于在将数据从源数据库（生产库）导出到目标数据库（脱敏后数据库）的过程中进行脱敏处理，或者在生产系统产生实际数据的同时，也同步产生用于其他环境的脱敏数据。这种架构有2个好处：脱敏目标库可以获得实时性很高的数据；
在生产系统外不存在非脱敏数据，减少安全风险。这种架构产生的问题是，脱敏处理会对生产系统产生一定的压力；脱敏策略可定制性不强，一旦投入持续生产就不能调整，否则会影响现有业务；脱敏应用会对源数据库到目标数据库链路安全和稳定性有较高要求；该架构一般都要求脱敏工具和生产库管理软件紧密耦合，限制可用工具的选择范围。
（2）静态（Static）数据脱敏架构。通过对源数据库的克隆来进行脱敏操作，形成目标数据库。脱敏规则可以在第三方实体上执行，也可以在目标数据库上执行。因为面对的是生产数据的镜像，这种架构可以根据需要调整脱敏规则，灵活性更高；脱敏工具的选择范围也更大；相对动态架构，静态架构对生产系统的压力更小。这种架构的风险是，因为涉及到第三方平台或目标数据库存储源数据，安全风险会增加；此架构获取的脱敏数据实时性相对动态架构偏低。
具体的数据脱敏方法，主要有以下6种：
（1）替代。指用伪装数据完全替换源数据中的敏感数据，一般替换用的数据都有不可逆性，以保证安全。替代是最常用的数据脱敏方法，具体操作上有常数替代（所有敏感数据都替换为唯一的常数值）、查表替代（从中间表中随机或按照特定算法选择数据进行替代）、参数化替代（以敏感数据作为输入，通过特定函数形成新的替代数据）等。具体选择的替代算法取决于效率、业务需求等因素间的平衡。替代方法能够彻底的脱敏单类数据，但往往也会使相关字段失去业务含义，对于查表替代而言，中间表的设计非常关键。
（2）混洗。主要通过对敏感数据进行跨行随机互换来打破其与本行其他数据的关联关系，从而实现脱敏。混洗可以在相当大范围内保证部分业务数据信息（如有效数据范围、数据统计特征等），使脱敏后数据看起来跟源数据更一致，与此同时也牺牲了一定的安全性。一般混洗方法用于大数据集合、且需要保留待脱敏数据特定特征的场景；对于小数据集，混洗形成的目标数据有可能通过其他信息被还原，在使用的时候需要特别慎重。
（3）数值变换。指对数值和日期类型的源数据，通过随机函数进行可控的调整（例如对于数值类型数据随机增减20%；对于日期数据，随机增减200天），以便在保持原始数据相关统计特征的同时，完成对具体数值的伪装。数值变化通过调整变动幅度可以有效控制目标数据的统计特征和真实度，是常用的脱敏方法。
（4）加密。指对待脱敏数据进行加密处理，使外部用户只看到无意义的加密后数据，同时在特定场景下，可以提供解密能力，使具有密钥的相关方可以获得原数据。加密的方法存在一定的安全风险（密钥泄露或加密强度不够）；加密本身需要一定的计算能力，对于大数据集来源会产生很大资源开销；一般加密后数据与原始数据格式差异较大，“真实性”较差。一般情况下，加密的数据脱敏方式应用不多。
（5）遮挡（Mask Out）。指对敏感数据的部分内容用掩饰符号（如“X、*”）进行统一替换，从而使得敏感数据保持部分内容公开。这种方法可以在很大程度上脱敏的同时，保持原有数据感观，也是一种广泛使用的方法。
（6）空值插入/删除。指直接删除敏感数据或将其置为NULL值。在条件允许的情况下，这种方法最直接。
总体而言，数据脱敏的方法有以上6个类别。在具体应用时，可以根据业务需求，结合可用计算资源情况，进行灵活选择。
SD-WAN行业理解（2）
详细内容
之前提到，SD-WAN作为一种生产方式的变迁，会有自己的演化趋势，甚至很难预测。所以，通过行业动态，来揣测一下趋势，可能会有更多人关心。
1 生态加速整合
1.1 通过并购整合
Cisco收Meraki、Viptela，因为Cisco原本就有自己的iWAN产品，有自己的安全产品，所以可以整合的内容就比较多了，包括SD-Branch产品，SASE产品，这里就说一下更加宏观层面的整合：Cisco把自己的网络功能软件化，推出了“数字网络架构（DNA，Digital Network Architecture）”的概念，把自己的网络功能整合成了DNA for Wireless，DNA for Switch，DNA for SD-WAN三大类，进而进一步构建自己的“基于意图网络（Intend Based Network，IBN）”。
Vmware收Velocloud，可以看做计算虚拟化和SD-WAN结合，在虚拟化层面推云网融合。Dell EMC有一个和Vmware合作的边缘网关系列，也可以侧面说明这种整合的价值。
Oracle收Talari，可以看做是一个小型IaaS，中型SaaS厂商跟SD-WAN结合，在云服务层面推云网融合。
HPE收Silver Peak，可以看做SD-LAN（HPE的Aruba）跟SD-WAN结合，整合SD-Branch产品。之前提到，Branch里的设备实在太多了，SD-Branch可以成为一个可以想象的未来。
PAN收CloudGenix，可以看做云安全厂商跟SD-WAN结合，整合SASE产品。
Juniper收128 Technology，可以看做AI产品（Mist AI）跟SD-WAN结合，整合AI Driven Enterprise产品。
4.1.2 通过合作整合
云厂商的生态位最好，几乎所有人都想着跟云厂商合作，尤其是和SaaS厂商合作，近期比较典型的是Aryaka相继和微软、阿里达成战略合作，这样Aryaka也补齐了四大IaaS厂商的全部合作。
运营商和设备商也在加速合作，最为典型的是北美的前两大运营商和前两大SD-WAN厂商宣布达成战略合作：Verizon和Cisco；AT&T和Vmware。
2 面向未来布局
2.1 孵化未来应用
既然SD-WAN是一种服务应用的广域网，那么就需要开始面向未来的应用布局，未来有哪些可以预见的应用：5G、IoT、边缘计算。
Verizon和Cisco、AT&T和Vmware之间的战略合作，就是在孵化IoT应用。SD-WAN和IoT的契合点：
敏捷：IoT感知层的本质作用是将现实世界数字化，这些数字化大多发生在边缘，而边缘如果需要形成智能的决策，需要将边缘形成的大量数据，连接到近端（边缘计算）或远端（云计算）进行处理，所以IoT的业务类型，天然决定了它需要非常灵活的部署方式。
安全：IoT设备自身的性能较弱，外加数量庞大，需要网络层面支持灵活的基于身份的安全性。
性能：不同IoT业务的性能要求不同，会有做应用分流、应用调度、应用保障的需要。
可视化：IoT存在海量的设备需要管理和维护，统一的可视化平台，是一个必不可少的手段。
云厂商也在为未来应用布局，AWS推出Wavelength Zone，直接进运营商机房，孵化5G MEC应用。SD-WAN和边缘计算的契合点：
敏捷：大体与IoT类似。
安全：边缘计算的场景相对会更加复杂，不但需要连接到现场，还需要与其它边缘节点协同，边云协同，即所谓的ECI（Edge Computing Interconnect）网络，这部分也是需要适配不同业务，在公共基础设施之上，形成非常敏捷的动态连接，也对安全性有很强的需求。
性能：大体与IoT类似。
统一架构：边缘计算相比云计算，一个很大的优势是在数据发生地，或者事件发生地就近处理，这种业务天然就需要比较扁平的计算架构，这种扁平的计算架构和SD-WAN这种较为扁平的网络架构，可以统一考虑。
2.2 边缘下沉
AWS Wavelength Zone进运营商机房，属于5G中的MEC（Multi-access Edge Computing）场景，属于边缘计算中的云边缘形态（云延伸）。当然，运营商也有可能在合作过程中探索发展自己的边缘云形态（节点云化）。顺便说明一下，部分人员可能会觉得为什么把这归属到SD-WAN分析中？AWS没说Wavelength在做SD-WAN。这是因为这属于边缘计算互联网络（Edge Computing Interconnect，ECI）领域，其中的热点之一就是如何用SD-WAN和SRv6等解决其中面临的挑战。
除了云厂商在设法下沉之外，设备商也在设法下沉，一般是边缘网关形态（设备云化）。例如：Cisco收Meraki，HPE收Silver Peak，都是在推SD-Branch，将入口下沉到LAN；之前提到，Dell EMC也有一个和Vmware合作的边缘网关系列。
SD-WAN行业理解（1）
详细内容
随着云计算的普及，越来越多的企业将计算、存储、服务等上云，那么对于云上这部分基础设施，就自然获得了云的客户价值：敏捷、弹性、按量付费。但是企业总有线下部分，比如线下的办公场所，自有的数据中心（混合云架构）。企业网必须是一张线上线下统一的网，并且随着时间推移，越来越以云为中心。然而传统的企业网，高端的像MPLS，草根的像IPSec，越来越难以保障企业上云的价值：
敏捷：这要求企业网可以允许用户不用关心底层的基础设施，可以在分钟级别内完成全球部署。
弹性：这要求企业网可以允许用户可以不用预留容量，可以在需要的时候随时进行伸缩。
按量付费：这要求企业网可以允许用户可以将CAPEX转成OPEX，甚至可以在不使用的时候不付费。
传统的企业网成为了企业云网融合的瓶颈，SD-WAN就在这样的背景下应运而生。由此可以推出：
第一、虽然SD-WAN的主语是WAN是网，但它的本质是云，是广域网的云化，它的灵魂是应用，是场景。这也可以和当前国内的市场情况相印证：很多号称在做SD-WAN的厂家，宣传得比较光鲜，但是市场做得并不怎么样，反倒是那些没说自己在做SD-WAN，一门心思在解决一个具体场景化问题的企业，市场反而做得不错，两个例子：Panabit，专注于应用识别，通过应用分流，帮助某运营商撬开另一运营商统治的网吧市场，发现自己做的竟然是SD-WAN；Agora，专注于音视频优化，通过把音视频编码SDK和实时调度的全球骨干网结合起来，推出了SD-RTN（Software Defined Real-time Network），至今也没说自己在做SD-WAN。
第二、SD-WAN不是一个产品，因为你没法通过SD-WAN这个产品名，定位这个产品要解决一个什么样的问题；它也不是一种技术，因为你没法确切的说它是一种什么样的技术，也没法有确切的技术标准，这个说法可能会有争议，因为近年来国外像MEF，国内像信通院，一直在做各种标准测试和认证，但这这种标准认证，感觉更像是一种行业最佳实践（对促进行业成熟和健康发展很有必要）；它更像是一种生产方式的变迁，一种由广域网云化导致的生产方式变迁。既然是一种生产方式的变迁，那就可以进一步推导出：
SD-WAN在单点技术上可能不是革命性的创新，但它改造的对象是广域网，后者已经是一项渗透到现代社会的方方面面的基础设施（Internet就是最大的广域网），这种连接型创新会对整个行业造成非常深远的影响。这种影响，可以拿集装箱的发明做类比：集装箱如果作为一项单点技术非常简单，但它推动了货运方式的变迁，把全球90%以上的海运、陆运、码头，甚至造船业都卷进来做了深入变革，甚至重塑了全球制造业的新格局。
生产方式的变迁，不是一家企业就能独立完成的，它会有自己的生态，会有自己的趋势，这种趋势甚至没法在一开始准确预测。这里特别愿意引用《罗辑思维》第84期《改变世界的箱子》中，对集装箱发明之后带来的影响描述：
“基于底层逻辑的连接型创新一旦展开之后，你没法控制和预测它未来的发展情况”。
“集装箱诞生之后产生的第二个后果，是整个产业生态里面人的命运被改变了，而且改变的方向，当时身处其间的人是没法想象和预测的”。
第三、这也可以进一步解答一个令人困惑的问题：为什么这个名义市场并不大的行业会持续火热？说它名义市场并不大，是因为根据Gartner、IDC等调研机构预测，整个行业规模在2023年大致在40-60亿美金之间；说行业持续火热，是因为一方面巨头死死咬住这个行业不放，另一方面创业公司持续涌入，近两年的SD-WAN的行业会议，都被戏称“厨师数量超过食客数量”了。这是因为虽然企业网在快速外化（即内网内容越来越少，外网内容越来越多——符合企业云化的趋势），但是企业网不会消失，只是演变成了另外一种形态，一种云的形态。SD-WAN的本质就是广域网的云化，所以对巨头而言，这不仅仅是当前收入问题，而是要么现在就入场参与演化，要么就会被彻底排除在未来的企业云网市场之外。
虚拟化安全威胁
详细内容
随着大数据、云平台的热潮席卷全球，大多数企业正在实施或者已经完成虚拟化，将传统硬件服务器系统迁移到虚拟化平台中，逐步向虚拟化方向迈进。
任何新业务的部署都会引入新的风险，因此，对于当前虚拟化大集中平台，安全风险不仅包含传统硬件架构中的风险，还会有因虚拟化引入的新的安全风险。本文主要讲解虚拟化后带来的新的安全风险。
Hypervisor安全威胁
在CVE的数据库中，虚拟化软件的漏洞累计超过超过700条，其中主要是vmware系统的。作为虚拟机的底层系统，一旦存在漏洞，将危及运行其上的所有虚拟机。
网络虚拟化安全威胁
虚拟化后，同一物理服务器上的不同虚拟机间可能通过硬件背板而不是网络进行通讯，因此这些通讯流量对标准的网络安全控制来说是不可见的，无法对它们进行监控或内嵌封堵。内嵌虚拟设备可以解决这个问题;另一个解决途径是硬件辅助虚拟化(Hardware AssistedVirtualization)，它需要与Hypervisor和虚拟化管理框架进行API级别的整合。
当一个可疑的虚拟机迁移进信任区域，在传统以网络为基础的安全控制措施下，将无法检测到它的不当行为。在每个虚拟机上安装全套的安全工具，是添加保护层的另一途径。
存储虚拟化安全威胁
虚拟化后，多租户对同一存储区域都有访问权。
租户数据迁移后，原磁盘释放给其他租户使用，原有数据未被彻底清除的话，也可能被新租户获取。
虚拟机镜像文件在休眠时是数据文件形式存数的，有被修改的风险。
对内存/存储清零或者对全部数据加密是此问题的解决方案。加密密钥应当存储在虚拟环境以外的一个基于策略的密钥服务器上。此外，如果没有使用加密或恰当的数据擦洗，虚拟机在运行的状态下迁移，自身可能面临风险。
网络边界模糊安全威胁
虚拟化后，一个物理接口上配置的不同网络的虚拟接口，逻辑网络间无明显边界，同一个租户可以运行在同一个物理机上，传统架构中的网络物理边界消失，只能通过逻辑域划分界定边界，虚拟化环境中，防火墙做逻辑隔离，内部通过虚拟交换机和VlAN标记等方式来界定防火墙保护特定的区域，以弥补防火墙在物理位置上不能清楚的体现的缺陷。
特权用户安全威胁
虚拟化环境下，除了租户可以访问自己的数据外，管理员由于需要对资源进行管理，因此也可以接触数据，SaaS提供商可能会利用其它PaaS、IaaS的服务，因此也可能会有特权用户，从而可能造成数据泄露、损坏或被修改。因此必须控制好权限分配，以防止操作不当或恶意删除等安全威胁。
总之，同其它任何新技术一样，虚拟化安全有自己的安全挑战。既不能认为虚拟化后的安全同传统架构的安全大同小异，也不能认为虚拟化后的安全不能保证，只有采取适当的安全解决方案后，虚拟化网络的安全仍然是可以保证的。
负载均衡基础知识（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等服务器上的调度功能。能够提供一个七层应用开发接口的负载均衡设备，可以让客户根据需求任意设定功能，才真正有可能提供强大的灵活性和智能性。
负载均衡基础知识（2）
详细内容
2.1 - 技术原理上的区别。
所谓四层负载均衡，也就是主要通过报文中的目标地址和端口，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。
以常见的TCP为例，负载均衡设备在接收到第一个来自客户端的SYN 请求时，即通过上述方式选择一个最佳的服务器，并对报文中目标IP地址进行修改(改为后端服务器IP），直接转发给该服务器。TCP的连接建立，即三次握手是客户端和服务器直接建立的，负载均衡设备只是起到一个类似路由器的转发动作。在某些部署情况下，为保证服务器回包可以正确返回给负载均衡设备，在转发报文的同时可能还会对报文原来的源地址进行修改。
所谓七层负载均衡，也称为“内容交换”，也就是主要通过报文中的真正有意义的应用层内容，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。
以常见的TCP为例，负载均衡设备如果要根据真正的应用层内容再选择服务器，只能先代理最终的服务器和客户端建立连接(三次握手)后，才可能接受到客户端发送的真正应用层内容的报文，然后再根据该报文中的特定字段，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。
负载均衡设备在这种情况下，更类似于一个代理服务器。负载均衡和前端的客户端以及后端的服务器会分别建立TCP连接。所以从这个技术原理上来看，七层负载均衡明显的对负载均衡设备的要求更高，处理七层的能力也必然会低于四层模式的部署方式。那么，为什么还需要七层负载均衡呢？
负载均衡基础知识（1）
详细内容
互联网早期，业务流量比较小并且业务逻辑比较简单，单台服务器便可以满足基本的需求；但随着互联网的发展，业务流量越来越大并且业务逻辑也越来越复杂，单台机器的性能问题以及单点问题凸显了出来，因此需要多台机器来进行性能的水平扩展以及避免单点故障。但是要如何将不同的用户的流量分发到不同的服务器上面呢？
早期的方法是使用DNS做负载，通过给客户端解析不同的IP地址，让客户端的流量直接到达各个服务器。但是这种方法有一个很大的缺点就是延时性问题，在做出调度策略改变以后，由于DNS各级节点的缓存并不会及时的在客户端生效，而且DNS负载的调度策略比较简单，无法满足业务需求，因此就出现了负载均衡。
客户端的流量首先会到达负载均衡服务器，由负载均衡服务器通过一定的调度算法将流量分发到不同的应用服务器上面，同时负载均衡服务器也会对应用服务器做周期性的健康检查，当发现故障节点时便动态的将节点从应用服务器集群中剔除，以此来保证应用的高可用。
负载均衡又分为四层负载均衡和七层负载均衡。四层负载均衡工作在OSI模型的传输层，主要工作是转发，它在接收到客户端的流量以后通过修改数据包的地址信息将流量转发到应用服务器。
七层负载均衡工作在OSI模型的应用层，因为它需要解析应用层流量，所以七层负载均衡在接到客户端的流量以后，还需要一个完整的TCP/IP协议栈。七层负载均衡会与客户端建立一条完整的连接并将应用层的请求流量解析出来，再按照调度算法选择一个应用服务器，并与应用服务器建立另外一条连接将请求发送过去，因此七层负载均衡的主要工作就是代理。
微隔离入门（3）
详细内容
专家建议，开始微隔离的公司企业理性对待微隔离项目推进速度。
Stevens 支招，从专注实用方法开始，而不是一来就搞大翻修。熟悉该过程的基本步骤：识别信息在公司中的流动方式，基于该信息流建立分隔的网络，创建更新的安全策略，纳入必需的安全功能，然后准备持续监视和更新该网络。
Entrust Datacard 的 Stenberg 建议采用一次处理一个应用的阶段式方法。
“这可以使你专注高优先级目标，完全锁定它们，同时又保留网络上其他东西的分隔控制。为控制粒度，应基于所处理和存储的数据的敏感度，根据需访问的用户来分组资产。
Ericom Software CTO Nick Kael 表示，微隔离项目不仅应该分解成可管理的部分分阶段实施，其部署过程也应设置能反映阶段性进展的里程碑和度量指标。这些项目可能复杂且耗时，所以在过程中显示进展很重要。
建立微隔离可持续性
随着公司不断往微隔离中引入更多资产，负责团队需考虑长远发展。正如 Woods 解释的，微隔离不是“设置了就可以丢开不管”的策略。
这意味着，企业需设立长期机制以维持数据流的可见性，设置技术功能以灵活维护策略改变与实施要求。还意味着需清晰描述微隔离配置管理中各人都负责做些什么。
SAP NS2 的 Wagner 表示，微隔离管理的角色和责任同样很重要。微隔离规则的改变应经过审查，类似配置控制委员会这种运营和安全团队可验证变更适当性的地方。
同时，企业不想受人工审批和修改过程的掣肘。所以，应尝试尽可能往维护过程中引入自动化。
Edgewise Networks 创始人兼 CEO Peter Smith 称：
“微隔离要求的很多费时费力工作如今都可以用机器学习加以自动化，包括查清应用相互通信的方式，确定能以最少数量提供最大覆盖面的规则集，以及持续跟进变更，尤其是在云环境中。
在策略方面，人类操作员将是最终决策者，但自动化应能帮助缩短审查所有东西的过程。
长远看，实行微隔离的所有努力都能帮助企业大幅降低不可避免的安全入侵风险。微隔离在增加安全控制的同时，还保留了发挥现代工作流和混合基础设施优势所必需的灵活性，而最终，无论你将其视为遵从最小权限原则还是实行零信任，微隔离都可帮助安全团队以细粒度维持 IT 资产的保密性、完整性和可用性。
微隔离入门（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 称，实现微隔离的主要障碍存在于和业务部门之间的沟通。以前就常在出问题时听人抱怨 “这肯定是防火墙弄的”。现在，微隔离成了内部业务部门刻薄批评的对象。
上一页
1
2
下一页