谷歌BeyondCorp系列论文（四）：迁移到BeyondCorp-提高安全性的同时保持生产力

前言

       随着企业大规模的采用移动互联网和云计算技术，传统的采用防火墙建立的“城堡”安全模式，变得越来越不安全。2014年12月起，Google先后发表6篇BeyondCorp相关论文，论文提供了一种新的安全模式，设备和用户只能获得经过验证的资源，构建软件定义安全的雏形。另外，论文也介绍了BeyondCorp的架构和实施情况，为传统网络架构迁移至BeyondCorp架构提供依据参考。

       为推动国内安全技术和理论与国际同步，在国内传播国际优秀实践，中国云安全联盟秘书处组织专家翻译BeyondCorp相关论文，供大家学习参考。

       本文档一共由BeyondCorp的六篇论文组合而成：

       [1] BeyondCorp：一种新的企业安全方案

       [2] 谷歌BeyondCorp：从设计到部署

       [3] BeyondCorp：访问代理

       [4] 迁移到BeyondCorp：提高安全性的同时保持生产力

       [5] BeyondCorp ：用户体验

       [6] BeyondCorp：构建健康机群

       该系列论文将定期向大家推送，敬请关注“云安全联盟CSA”公众号。

【第四篇】迁移到BeyondCorp： 提高安全性的同时保持生产力

       如果你熟悉过去两年发表在《;login:》[1-3]上的谷歌BeyondCorp网络安全模型文章，可能会想：“这一切听起来不错，但我的组织如何从现有模式转变到BeyondCorp类似模式？需要做些什么？这种转变对公司和员工会有什么影响？”本文讨论了从现有网络迁移到BeyondCorp模型所采用的方法，探讨如何实现在根本上改变网络访问模式的同时，却不影响公司生产力。

       向BeyondCorp及其类似模型迁移面临诸多挑战，其中有几个尤其值得注意:

• 这个过程会影响整个公司。要让每个人都参与进来并保持一致和确保知情，就需要得到各级管理层的承诺和支持，这就需要与各方广泛沟通，从拥有个性化服务的团队，到管理层，再到支持团队，最后到用户。

• 迁移不可能一蹴而就。这个过程是多层次和渐进式的，包含信息收集、实验部署、流程和技术修正等各阶段，以及必要地点与时间的例外和补救。

• 这个过程涉及到在业务/技术栈中的多层、甚至所有层上进行更改：网络、安全网关、客户端平台和后端服务。为了保证不同层面工作进展相互独立，需要各层分治，确保多线程并行且易于管理和实现。

       下面将讨论我们如何将BeyondCorp迁移工作进行分解，介绍各个层面平滑、一致的迁移所需的技术和工具，当然，必须确保整个过程对用户导致的负面影响最小化。

先决条件：认同和沟通

       着手迁移到一个类似BeyondCorp的模型之前，需要来自公司高层及其他干系人的支持。第一步是理解和沟通迁移的动机：减少成功网络攻击所造成的威胁，同时保持生产力。需要将迁移背后的基本原理、威胁模型以及维持“业务照常运行”所需的成本形成文档。然后，准备好向每一个业务部门解释迁移过程的价值和必要性。与所有的安全项目一样，部署新模型需要付出代价：新工具、额外流程和使用习惯的改变。高层管理者需要积极支持这种改变，并将这种改变的动机和认同理念在所有干系人中推广。

       有了管理者的准许和认同，接下来确定并争取到关键领域负责人的支持：安全、身份、网络、访问控制、客户端和服务器平台软件、关键业务应用程序服务，以及任何第三方合作伙伴或IT外包。负责人应该梳理和确定各领域专家，获得其承诺，并确保他们投入时间和精力。谷歌BeyondCorp团队是一个分布到全球各地的虚拟团队，有负责决策的总监，有项目技术经理负责协调落地执行。随着时间的推移，团队参与成员虽然会有所变化，但是高层领导、团队负责人和其他参与者会通过在线文档、邮件组和定期会议（面对面的和远程的）联系，始终保持对当前进展和项目状态的了解。

       随着迁移工作的推进，通用的变更管理规则同样适用，因为每个工作组都有自己的关注点和优先级。要倾听反馈，调整兼顾每个参与者或受影响群体的特殊情况和要求。及时公开计划和资讯很有必要，但仅仅这样还不够，还需要互动沟通（最好是当面沟通，至少也要通过视频或音频会议进行）才能加深团队间的协同、更易获取帮助和得到认可。

分步推进

       BeyondCorp的总体目标是，从允许客户端直接访问服务器的网络，过渡到无特权网络：取消客户端直接访问后端服务器的特权。详情请参见BeyondCorp系列文章的第一篇《BeyondCorp，一种新的企业安全方案》[1]。为此，谷歌曾考虑依次阻断每个应用或服务器，以便逐步移除遗留VLAN的访问特权。但这一策略并不理想，有两个原因：一是在网络层部署和协调很困难；二是在应用层增加了影响生产力的风险。因此，决定在最终的BeyondCorp配置中部署一个新的VLAN。这个VLAN只允许通过访问控制网关访问服务器网络，确保所有流量都经过身份认证、授权和加密。这一策略不是逐步限制遗留VLAN的特权，而是逐步将设备最终都转移到这个新的VLAN上。

       VLAN迁移项目实现了一个复杂但至关重要的目标，迁移遗留“特权”网络的用户设备，并将它们分配给新的受控无特权客户端（Managed Non-Privileged Client, MNP）VLAN。这次迁移有一关键约束：对于运行在新VLAN工作站上的任何遗留应用，无论是预期还是必需，直接访问服务器网络都将失败。因此，近期目标是在不破坏业务关键操作的情况下实现迁移工作。为此，采用了三管齐下的策略来实现这一目标：

       1、 广泛分析网络流量日志

       2、 识别和修复不符合迁移要求的应用程序

       3、 在确定设备可以在新网络上成功运行之后，迁移设备

       这种策略允许网络层面相对稳定地应用新的配置，且能够独立于BeyondCorp的其他部分进行。BeyondCorp的设计包括基于802.1x认证进行网络准入以及VLAN分配，这种方式能够将网络层与迁移策略的细节隔离开。更高层的软件和数据分析决定了设备的VLAN分配，并由RADIUS服务器将其返回给网络层。

       实现这一系列目标任务艰巨，需要对技术/业务栈的每一层进行修改。但迁移团队并没有试图在一次过渡中修改所有层（毫无疑问这会引起灾难性的崩溃），而是分步实现：

• 解耦网络层：新的VLAN、802.1x、RADIUS策略服务器

• 解耦客户端平台升级：证书生成和安装，用户认证工具

• 完成不符合迁移要求的服务和工作流的修复，逐步地迁移设备

• 持续修正流程和程序

第一步：802.1x网络

       在BeyondCorp的第一阶段，为每个用户设备安装证书并基于802.1x认证实现所有的网络访问准入。这个看似简单的步骤暗含了几个新的开发项目：证书颁发机构(CA)，为公司受控设备（针对所有操作系统）安装证书的工具，在网络交换机上启用802.1x，集成一个策略驱动的RADIUS服务。以上开发项目并行开展。

       安全团队设计了一个新的证书颁发机构，通过提供API接口的方式，使每个操作系统平台管理团队能够在对应的平台上获取并安装证书。每个平台团队独立部署软件、工具和监测系统，执行和监测每个设备的证书安装。在与接入交换机集成的同时，我们还创建了批量分发和维护证书的流程。

       同步开展的还有对接入交换机的重新配置工作，为接入交换机配置新的VLAN定义，开启802.1x认证，支持基于RADIUS的VLAN分配。自动脚本通过审计交换机的升级，来识别尚未配置新VLAN的交换机。这样，RADIUS服务器就不会为这些交换机分配其尚未开通的VLAN。

       采用802.1x认证，就可以将VLAN分配的控制权从网络层转移到VLAN策略服务器。为了减少新RADIUS服务器可能引发的故障，初始策略仅匹配现有VLAN分配（包括复杂的黑名单和白名单）。一开始，配置策略服务器在审计模式工作，比对新的VLAN分配与既有的VLAN分配。当两者差异足够小，就启用新策略。此后，就可以使用软件和数据驱动的策略，接近实时地管理设备的VLAN分配。这个简单初始策略的使用，使得最终状态（和过渡）策略仍在开发中时，在网络层面率先启用动态VLAN分配。

以成功为导向的迁移

       全面部署802.1x认证花费了数年时间，随后又花了更长的时间来实现基于清单、按信任等级动态分配VLAN，并将其作为RADIUS策略服务器的输入[2]。在这些开发工作进行时，需要识别出两类主要用户群和应用服务：那些准备好采用BeyondCorp的，和那些需要升级网络和安全能力才能兼容BeyondCorp的。首先，捕获和分析网络路由器的流量。通过日记记录和分析经过公司路由器的全部流量的部分采样，发现使用模式不兼容的情况。此外，这种分析还可以协助发现网络上的异常、意外和未经授权的流量。识别出这些不兼容BeyondCorp的应用，就可以尽早对这些应用进行兼容性改造，并避免对这些应用的使用者造成干扰。

       有些网络用例，比如使用NFS/CIFS文件服务器的工作站，显然是不兼容BeyondCorp的。虽然NFS / CIFS文件服务器是实现文档共享和协同的最简单方法，但其底层协议不支持我们所需的安全属性（强加密和身份认证）。为了消除对NFS / CIFS的依赖，我们很早就启动了一个项目，来实现两个目标：一是将NFS主目录移动到本地磁盘，并通过自动备份同步至安全的云存储；二是使用Google Drive或其他安全的文件共享技术取代其它NFS的使用。即便如此，还是有些应用程序非常依赖NFS，如CAD（计算机辅助设计）编辑器，对于这种情况，我们在将其用户和工作站移动到受限的MNP VLAN之前，就需要定制解决方案。在下文的“修复困难用例”一节中将讨论如何处理这些特殊需求的框架细节。

       还有些不兼容的工作流不那么容易判断出来，但一旦受到MNP网络的ACL限制时，这些业务就会运行失败。让其失败是必要的，因为我们无法假设NFS、RDP、SQL等具有足够的身份认证、授权和加密能力。当不得不在网络层面进行修复时，检测出这些工作流后通过改变设备的网络分配来恢复其生产力，费时费力。为了避免这种情况对生产力产生巨大影响（更不用提影响用户的情绪），需要一个分析驱动的策略，在将用户分配到MNP VLAN之前，预先检测并修正可能失败的工作流。

       为了方便在无特权网络上进行简单的分析和用户工作流测试，我们创建了一个基于C/S架构的网络ACL仿真器，仿真器能识别被MNP ACL阻塞的网络数据包。底层技术采用Capirca（参见源代码[4]），并依据真实的MNP ACL，创建本地iptable规则或其他的包过滤规则。在分析和迁移阶段，用户设备继续在特权网络上运行，而MNP仿真器监视网络流量，并将所有非MNP兼容的流量的源和目的地址记录到中心数据库。IP源地址标识潜在故障用户，IP目的地址标识潜在故障服务。通过分析日志（必须考虑适当的隐私限制），可以识别出已经兼容MNP的设备，从而将它们分配到MNP VLAN。同样，可以识别出暂不兼容流量的设备、用户和服务，并启动项目将这些服务转移到为其需求其他解决方案。随着时间的推移，更多的设备变为兼容设备并被自动分配到MNP VLAN。

       在第二种模式下，MNP仿真器实际上也可以阻止/丢弃非MNP流量，从而在不依赖MNP VLAN和802.1x管道网络层部署的情况下强制执行MNP ACL。尽管ACL的最终执行是在网络设备中完成，设备中将ACL与用户（或黑客）的滥用隔离，但在试用和过渡阶段，在客户端工作站上启用和禁用这种“强制”模式要更容易、更迅速。客户端强制执行模式既是迁移过程中的重要步骤，也是用于测试验证的自助服务工具。如果当初没有这种工具，BeyondCorp迁移团队恐怕难以实现最终快速、成功的设备迁移工作。

图1 将谷歌电脑迁移到受控的无特权（MNP）网络的管道

使用访问代理处理简单用例

       谷歌的基本安全策略要求所有从工作站流向服务器的业务流量都需要：

• 已认证（识别发出请求的设备和用户）

• 已授权（验证用户和设备是否被允许访问后端资源）

• 已加密（防止窃听）

• 单独记录日志（为了协助取证分析）

       对于HTTP/S流量和HTTP封装的SSH流量，访问代理[3]可以满足以上所有要求。

       幸运的是，在谷歌内大多数高频使用的应用程序都是基于B/S架构的Web应用。这种“幸运”并非巧合，因为谷歌有一独特的核心理念在业界“闻名”：尽可能的使用基于B/S架构的应用。谷歌为每个Web应用提供者准备了工具和文档，让每个应用提供者都可以配置自己的应用运行在访问代理之后。

       当一个应用运行在访问代理后端时，企业和公共DNS包含一个可以解析到访问代理的CNAME，这样此类应用的URL在企业和公共网络中都具有同样的易用性和安全性。能从公共网络访问企业应用就意味着，经过身份认证的远程用户可以直接访问企业Web应用，而不需要再拨通VPN进行访问。因此，使用和支持VPN连接用于远程办公所需的费用会立即大幅减少。据粗略估算，由此产生的生产力提升轻松超过了BeyondCorp的实施成本。

       一旦基于B/S架构的应用在访问代理后受到安全保护，我们就可以大刀阔斧地推进了。通过启动一个自动化流程，分析、验证并将设备迁移到无特权网络;在不到一年的时间里，超过50%的设备迁移到无特权网络访问模式。

修复疑难用例

       虽然可以通过访问代理来处理大多数的应用，但还有些应用难以通过此方法处理。整个迁移的时间安排还必须考虑到非Web案例的长尾问题，因为这些问题用例需要更多的时间和资源。为保证这些用例能够兼容BeyondCorp，需要新工具、新技术和工作流改造。

       特别是，一些工作小组使用基于非HTTP协议的第三方桌面或“胖客户端”应用程序，这就涉及到一系列特殊的问题。例如：

• 有些工具原本就是依赖网络文件共享。

• Java应用程序可能使用远程方法调用（Remote Method Invocation，RMI）或其他直接套接字连接。

• 许多工具可能需要使用非HTTP套接字和协议连接许可服务器。

       即使是基于HTTP的应用程序，也可能遇到一些莫名奇妙的、出乎意料的问题。例如，有些应用无法支持客户端证书或适当的用户凭证，而有些应用则内置了一些负载均衡逻辑，导致不易和访问代理整合。对于其中一些案例，通过调整访问代理，允许来自MNP VLAN的流量在没有证书的情况下通过。这种临时策略效果还不错，因为设备必须出示证书才能访问MNP。每个有问题的案例都需要一个诊断和补救项目。

       为了解决这类疑难杂症，开发了一个解决方案，使用多端口加密通道来传输客户端和服务器之间的流量：

• 当客户端向服务器发起连接时，访问代理使用常规的用户和设备身份认证及授权。

• 客户端上的路由表将数据包发送到TUN设备，该设备可以捕获和加密到特定后端服务器的流量。

• 加密后的数据包采用基于UDP的封装协议直接在客户端和加密服务器之间传输。

• 加密服务器只允许应用程序必须的服务和端口流量通过。

表1：解决问题工作流的方法

       这种方法可以让第三方传统应用更安全地从任何网络连接到它们的服务器，同时也满足了BeyondCorp要求的身份认证、授权和加密。

       表1描述了解决问题工作流的常规方法。详细论述请查阅《BeyondCorp，访问代理》^[3]。在有些场景下，表1中的解决方案还要求用户通过运行脚本或在访问后端资源之前提供必要的身份认证来修正工作流。

       有些基本框架服务也不具备兼容性。当然，这些关键服务的兼容问题并未阻止迁移的整体推进，而是通过开通从MNP到特定端口或服务器的临时访问权限进行解决。为了防止这些临时例外变成常态甚至颠覆BeyondCorp的基本目标，只有服务所有者给出实现和部署兼容解决方案的明确计划时，我们才允许进行临时的例外放行。

       随着一个一个的应用或用例完成整改或调整，借助自动化的分析、验证和迁移工具，越来越多的用户和设备转移到无特权VLAN上。随着工作推进，网络日志记录和分析可以用于度量已成功迁移到MNP的用户和设备数量。

逐步上线并不断完善迁移方法

       MNP仿真器，分析管道，以及将设备自动分配到MNP VLAN，组成了一个重要的软件开发和流程再造项目。所以整个项目的开发和部署也是逐步完成的：首先在针对各个阶段进行小规模测试，持续修复软件，合适的用户调整通告，培训技术支持团队，然后逐步推进到全面部署。

       当识别出那些不兼容工作流的用户，仿真和预分析的方法有助于规避对这些用户的负面影响。然而，这种方法将所有新配置的、尚未分析的设备分配给特权网络，并且没有阻止未迁移的用户使用或创建新的不兼容应用，因此它不能作为长期策略。通过纠正大量用例来减少异常案例后，实施方法变为“默认采用MNP”策略。随着工作逐项推进，全部设备被默认分配到MNP，同时对那些由于工作职责需要使用未修复应用的用户设备，予以例外处理。这个基于策略的分配完成了从“证明用户会成功，然后迁移设备”到“假设用户会成功，直接迁移设备”的演变。

扩大支持，尽量减少对员工的影响

       使用上述工具和流程，能够自动识别、联系和迁移整组用户。但无论是在迁移开始前，还是出现问题时，都需要一些办法来帮助用户，与用户沟通。技术支持的专业培训和增加与用户的沟通和互动，这两点对将工作流迁移到新模型至关重要。

技术支持赋能

       在支持团队中培训一批技术人员，将他们培养成为BeyondCorp模型的专家和本地的主要接口人。项目上线的初期，这些技术人员帮助受影响用户能够在不影响迁移策略的情况下迅速恢复工作，还能有效地将问题准确地反馈给实施和策略专家。一开始，这些受过专业训练的技术人员比其他部门同事获得了更高的访问修复系统的权限。作为BeyondCorp上线的第一批“观察员”，他们可以提前参与思考，接下来的技术支持会需要哪些方式、工具和流程。此外，他们还通过全球科技论坛、讨论列表、午餐时间和办公时间来给其他支持团队做培训。随着信息的不断传播，将系统访问权限赋予全部支持团队人员。

       成立本地专家组，使BeyondCorp团队能够直接与工作流不兼容的部门进行沟通。在本地专家组中确定一个资深对接人，问题部门就可以与BeyondCorp团队项目经理直接沟通，一起找到解决方案。与此同时，允许并鼓励技术人员，让他们在发现问题后立即在内部文档中添加新的临时变通办法或修复手段，以便将解决问题的能力尽可能遍布全网，更有效地实现信息共享并获得规模化支持。

自助服务

       为了避免出现海量问询，需要尽量减少员工疑问，并在无需技术人员人工干预的情况下能够对常见问题进行回答。当用户被选中进行迁移时，系统会自动给他们发送一封启动邮件，内含明确时间安排、迁移将如何影响他们的工作、以及项目信息链接、常见问题答疑链接、自助链接和加急服务点。

       此外，还提供一个自助服务门户网站，允许受业务关键时间节点约束的用户延迟迁移。为了回答问题，并进一步扩大信息传播范围，创建了一个内部讨论列表，征集员工答案。通过对常见问题的分析，能够快速迭代启动邮件内容和项目文档。

       在整个上线过程中，通过专门的Web应用，我们还能快速迭代并改进故障处理指南。这个Web应用清楚地识别了常见问题（例如，解释为什么用户被拒绝访问某个资源），提供了解决问题的步骤，并链接到知识库文章。用户可以解决诸如组成员关系和证书问题等常见问题，从而减少对技术支持的请求。Web应用还通过将来自许多不同层面和系统的信息合并成一系列操作，来帮助技术人员解决错误。

内部宣传活动

       团队还组织内部宣传活动来提高大家对BeyondCorp的认识，比如推出了电脑贴纸、标识和口号，还在办公室张贴随处可见的文章。这些材料都标明了自助服务和办公时间，任何人有任何问题都可以寻求帮助。BeyondCorp团队坚持宣传、指导、提供帮助，这使其直接与用户建立信任、取得信誉、得到用户的理解支持。在整个过程中，企业内沟通和技术专家参与是至关重要的，尤其是在早期阶段，那时亟需为项目的愿景和潜在影响给定一个清晰的蓝图。

分阶段上线

       BeyondCorp最初是一个小规模试点，试点位置与项目团队很近。随着时间的推移，逐步延伸至具有本地技术专家的试点位置，最终扩展到风险高的工作流和距离项目团队远的地点。直到有了成功经验，用户支持，以及对策略的信心，我们才开始实现关键业务流的迁移。在此过程中，即便上线规模和受影响工作流在增加，但技术支持负载却在减少。分阶段上线实施是迁移能成功的关键。

最终结果

       通过持续分析和改进上面提到的所有方法，BeyondCorp团队还建立了一个系统，确保BeyondCorp能够在全球范围内扩展，而不会对业务、支持或用户体验造成负面影响。并不是简单地通过人海战术，而是通过构建系统和流程来有效地处理问题、进行升级和培训。此外，基于良好的沟通、开放和高度一致的目标，我们确信用户会帮助迁移团队一起实现变革。

       随着公司越来越多的人采用BeyondCorp模式，我们也仔细追踪了由于BeyondCorp上线所产生的支持案例。近几个月来，BeyondCorp相关问题只占技术支持团队全部处理问题的0.3%。一开始这个百分比有0.8%，但随着文档、培训、消息传播和上线方法的不断完善，升级问题已经稳步减少。与谷歌内部其他大规模IT变革相比，BeyondCorp的支持问题少了30%。

结论

       在提高安全的急迫性与改变终端用户的使用习惯之间总是存在矛盾。当基础设施和工作流的改变威胁到生产力的时候，这种矛盾只会升级。在发展和稳定之间取得平衡，与其说是科学，不如说是艺术。BeyondCorp能够取得成功、为员工所接受的关键原因是分析、可行的规划和主动沟通。

       通过将BeyondCorp迁移工作划分为独立任务，可以确保各项任务并行向前推进，确保每个阶段的用户影响最低。尽管部署BeyondCorp到各个层级花费了数年时间，但每一个里程碑都实至名归。这个过程逐渐使远程访问变得更容易，更快捷，网络管理变得更简单，安全性得以增强。

       开发出能实现BeyondCorp安全模型的技术很具挑战性。上线规划和管理用户迁移同样具有挑战性。注意一定要确保每次迁移对用户的影响最小，并且不会中断正在开展的业务。每一次成功迁移都带来了对这个项目价值的全新认识，并为用户和管理人员带来了持续的热情和对项目目标的接纳。通过赋能一个跨职能团队，其中包括每个技术和实施团队的代表、安全策略的责任人还有终端用户支持和通信方面的专家，BeyondCorp项目最终取得成功。

       在谷歌内部，已经能够将在BeyondCorp工作中所学到的东西应用到其他项目和服务中。其中最显著的就是最近为谷歌云平台(Google Cloud Platform,即GCP)增加的新服务（比如基于身份识别的访问代理IAP）。BeyondCorp所获得的最大经验教训之一，就是当遇到其它用例时，一定要分步完成项目，并持续完善优化策略。尽管这篇文章关注的是谷歌自己的经验，但它所分享的经验可以在任何组织中采用，无论规模大小，当然，获得相关干系人的坚定支持至关重要。

致谢

       感谢以下的人员，有了他们的帮助才完成这篇文章：希瑟•阿德金斯（Heather Adkins）、杰夫•贝尔德（Jeff Baird）、达伦•比比（Darren Bilby）、约翰·布莱迪（John Brady），维克多·埃斯科贝多（Victor Escobedo），辛西娅·霍伊奇（Cynthia Horiguchi），迈克尔·简诺斯科（Michael Janosko），罗伯·皮斯古德（Rob Peasegood），丹·波尔斯比（Dan Polsby），瓦尔·斯蒂里斯（Val Stiris）和罗里·沃德（Rory Ward）。

参考文献：

[1] R. Ward and B. Beyer, “BeyondCorp, A New Approach to Enterprise Security,” ;login:, vol. 39, no. 6 (December 2014), pp. 6–11: https://www.usenix.org/system/files/login/articles/login_dec14_02_ward.pdf.

[2] B. Osborn, J. McWilliams, B. Beyer, and M. Saltonstall, “BeyondCorp: Design to Deployment at Google,” ;login:, vol.41, no. 1 (Spring 2016), pp.28–35:https://www.usenix.org/publications/login/spring2016/Osborn.

[3] L. Cittadini, B. Spear, B. Beyer, and M. Saltonstall,“ BeyondCorp Part III: The Access Proxy,” ;login:, vol. 41,no. 4 (Winter 2016), pp.28–33: https://www.usenix.org/publications/login/winter2016/cittadini.

[4] Capirca is a tool designed to utilize common definitions of networks, services, and high-level policy files to facilitate the development and manipulation of network access control lists: github.com/google/capirca.

转自于微信公众号-云安全联盟CSA

云深互联

       云深互联， 取名自古诗：“只在此山中，云深不知处”，旨在通过新一代SDP（软件定义边界）网络隐身技术，使应用程序“隐身”于互联网之中，只对授权用户可见，让黑客无从发起攻击，从而有效保护企业数据资产，让每一家企业数据安全上云，实现高效地互联互通。云深互联成立于2012年，已经成功服务不同行业的500强企业及政府单位，覆盖金融 、能源 、交通 、制造 、地产 、教育、零售等领域。成功获得晨兴资本、IDG资本、达晨创投等一系列知名投资机构数亿元融资。