贝壳零信任网络建设技术总结（下篇）

见贤思齐

贝壳零信任网络建设技术总结（下篇） 贝壳零信任网络建设技术总结（下篇） 贝壳安全 贝壳产品技术 贝壳产品技术 “贝壳产品技术公众号”作为贝壳官方产品技术号，致力打造贝壳产品、技术干货分享平台，面向互联网/O2O开发/产品从业者，每周推送优质产品技术文章、技术沙龙活动及招聘信息等。欢迎大家关注我们。 242篇内容 2021年06月18日 20:37 概 要接上篇，本文将较深入的介绍每个零信任组件的建设细节。我们会将“什么是权限”、“权限是如何起作用的”、“权限在哪里起作用的”等疑问一一解开，让零信任不再神秘。零信任管理平台在构建零信任策略配置管理平台之前，先需要确定策略模型与管理方式。我们在策略模型的建立上，采用了语言中“主语”+“谓语”+“宾语”+“修饰语”的方式，引入了4个单位：Subject、Action、Resource、Environment，因此简称之为SARE模型。1）授权原则：S CAN DO A ON R IF E2）主体对象（认证）：可以包括用户/组，IP，设备，服务等。3）资源对象：服务，API等。此处设计，为保证兼容4/7层流量授权。4）执行动作：接入，Method，CMD等。同样，为兼容4/7层流量授权。5）条件环境：网段，时间，地理位置，设备信息/健康状态等，条件信息可多样化，可定制。如下图中实例：根据图中信息，得到策略描述：LiLei、HanMeimei以及三年二班全体同学，都可以在每天的早7点到晚18点之间。在学校计算机室中（网段10.10.0.0/16），访问http://r.zerotrust.com/student_info，但仅限于通过Get请求或Post请求。在管理方式上，则引入Realm概念，用以标识唯一管理单元。从我们的建设经验来看，该单元可以包括域名以及IP。在Realm之下，我们使用Service来标识该管理单元下服务。一个域名或IP下，可以通过不同的端口，对外开放出不同的服务，如HTTP服务、SSH服务等。但在此处注意的是，端口（Port）的重要性，要高于服务协议（Protocol），因为端口决定了流量的走向。策略Policy则归属于各个Service，且每个Service中可以存在多条Policy，Policy之间相对独立，但存在先后顺序关系。策略中会包含我们上述所说的SARE模型，同样的，我们也允许每条策略中包含多个Subject、Resource以及Environment。最后，为了方便管理，我们引入了Realms的概念，类似于文件夹的使用方式，用以对Realm进行归类，方便查看管理，但此概念非必须。最终，我们形成的管理方式如下图：零信任决策中心零信任决策中心的建设，分为“认证”、“授权”以及“风险评估”三部分的建设。关于认证，我们在建立策略模型的时候提到过，认证的主体，包括但不限于“用户”、“服务”、“设备”甚至“IP”等。对用户认证的场景在聊及用户认证时，我们常会想到1993年，漫画家 Peter Steiner的一幅画：On the Internet, nobody knows you're a dog。因此，单纯的账号认证，没有任何意义，因为账号（凭证）≠身份。当该账号背后有确切对应的身份，且可以确定当前账号的使用者可以与之关联时，认证才有意义。在建设零信任决策中心的认证部分是，我们强烈建议其与企业现有的SSO系统相结合，原因如下：可以复用当前完善的账号体系。可以复用SSO已经实现了的多因子认证能力，甚至借其实现梯度认证能力。可以复用SSO提供的登录态，当业务也接入SSO的时候，避免因此而产生的多次登录。对服务认证的场景对服务认证的场景，普遍存在于生产网络内部，服务与服务之间的调用与信息互换。此处有两种实现方式：原始流量中携带服务签名，由此可得服务唯一ID，在网关或服务侧以此为依据进行服务认证。使用“客户端”方式，对服务进行可信代理，封装认证凭证，通过4层流量网关实现认证。如果企业当前的基础架构已经实现容器化，则基于容器化的隔离与认证方案将更有利于服务间的认证与授权。对设备认证的场景例如打印机入网、可视化大屏入网以及其他哑终端类设备入网。此类认证方式，可结合Radius实现，也可以通过设备证书方式实现。前者实现起来更加快捷，适用性也较强，后者安全性更高，但相对实现成本也很高。对IP认证的场景对IP而言，不应称之为“认证”，因为不存在任何认证过程，也不存在可信身份。但此场景最终被实现的原因是：我们终归有一些或暂时、或永久不能解决的场景，无法对明确的主体进行授权，而为保证这部分流量或业务不会因为零信任网络建设而受到影响，我们对之进行了妥协。但无论如何，对IP授权不应广泛地被使用，因为IP授权无法得到有效的权限收敛，也很难进行风险持续评估与审计。关于授权，我们试图用两条“链”来阐述我们所实现的授权过程策略链假设场景如下：访问主体LiLei，为三年级一班的同学，自寝室IP 10.33.27.135访问http://r.zerotrust.com/english获取学习材料（此处假设Environment都满足的情况下，关于Environment链，将单独描述。同时为了简化场景，此处Action也暂不予以考虑）对HTTP Service r.zerotrust.com存在以下6条策略：LiLei同学此次访问的授权过程，可如下图所示：策略链中，存在可以满足授权（不论Access或者Denied）的情况时，授权且退出链。环境链当引入环境条件时，授权将变得更复杂起来。但我们认为环境条件的存在是有必要的，通过环境条件的配置，可以实现授权条件的更细粒度约束，也让整个授权配置变得更加灵活。假设一条访问策略中存在4个环境条件可以看到，环境条件中，引入“属性”概念。属性被我们赋予Requisite或Sufficient，分别表示“必要不充分条件”及“充分不必要条件”。4条环境策略所形成的环境链，可以表示成下图：关于授权时的风险评估，虽然是零信任思想中较重要的一部分，但如果缺失这部分能力，网络也可以正常工作，它是提高网络安全性锦上添花的功能组件。授权时的风险评估，区别于“持续的信任评估”，是一项实时的工作，因此，可以评估的信息，均为静态的、实时的信息，如访问源设备操作系统版本、补丁安装情况、最近一次病毒查杀结果、是否安装EDR软件等。此部分工作，很大程度上依赖于安全客户端的信息采集。当风险评估结果显示，访问源安全性不足，此次授权结果将被更改，甚至直接被拒绝访问。但同时，应当给予用户充分的反馈以帮助用户改善环境安全，提升风险评估等级。零信任L7网关依托于企业成熟的代理网关（Nginx），可以实现L7网关的快速搭建。当前公司的网络结构为例：LVS（Linux Virtual Server）作为负载均衡器，将流量负载至第一层代理服务器（Nginx）中。第一层代理服务器（Nginx）实现SSL卸载、日志记录以及定制化需求配置（如HTTP至HTTPS跳转等）。第二层代理服务器（Nginx）则作为WEB服务网关，将流量代理至真正上游应用中。在更精细化场景中，这一层也可以用作API网关，因此选型也相对多样化，如OpenResty、Tengine、Kong等。我们所要实现的零信任7层流量网关，在此结构下，则可以与第二层代理服务器相结合。复用第二层代理服务器的优点如下：成熟且稳定的网络结构。无需在网络中增加一层，降低链路中的损耗。专业的SRE、网络、运维、故障处理团队守护。我们在这里，使用Lua完成了网关策略执行点（PEP）的快速开发。同时，插件的方式集成到代理服务器中，保证了开发与部署的独立性。为了保证访问性能，降低网络损耗，在网关中我们使用了授权信息缓存的方式，即将个人认证信息以JWT形式存储至用户cookie中，将授权信息短时保存在网关的缓存中。这种方式一定程度上牺牲了安全性，但安全与性能之间，总需要保持一定的平衡，进行一定程度的取舍。另外，在零信任思想中，所有网络传输均需要被加密，包括零信任网关至上游服务之间的通信。Google通过内部开发的高性能认证和加密框架LOAS（Low Overhead Authentication System，低开销认证系统）实现零信任网关至上游服务之间的双向认证和加密。但我们评估了开发成本与安全性，决定采用一种较为取巧的方式来保证上游服务器的安全，即通过防火墙策略保证上游服务只信任来自零信任网关的流量。最后补充一个细节，不建议零信任网关拦截非授权原因造成的403返回码，也不建议零信任网关拦截非网关配置所造成的502返回码，因为这两部分返回码的拦截，将会给零信任网关的运维造成非常多不必要的工作量。零信任安全客户端零信任安全客户端的建设，一方面为了满足4层流量的身份凭证传输以及可信的隧道传输能力，另一方面，为了实现访问源环境信息的采集。认证及隧道传输部分，我们建议在能力允许的范围内，尽量以研发的方式实现，因为这部分将与4层流量网关产生联动，而4层流量网关又需要与企业先前建设的管理平台及决策中心进行联动，因此定制化较强。最基础的安全客户端应该具备以下能力：身份认证：将身份信息提供至服务端，由服务端联动SSO或LDAP，完成身份认证。此处可引入多因子认证来保证认证身份的可靠性。身份认证后，客户端将保存服务端下发的身份凭证，并在请求流量中，携带身份凭证，以便网关根据身份完成合理授权。流量代理：客户端通过创建虚拟网卡，代理指定网段流量（这里我们假定10.0.0.0/8网段），并将报文进行封装，以携带身份认证信息。加密隧道：通过与网关的协商/交换密钥，建立TLS1.2通信隧道，保证通道的安全性与可靠性。进而将虚拟网卡封装好的报文传输至网关侧。客户端与网关及服务端联动时序如下图：在基础功能完备情况下，则需要考虑客户端实现信息收集及其他附加功能，如配置下发、病毒查杀等。最为简单快捷的方案，是通过商业产品采购，如DLP、UEM、杀软等进行能力补足。通过唯一设备标识，与商业产品形成联动，访问商业产品服务端接口，获取对应的客户端详细信息。而不论以何种方式获取设备信息，至少应该包括： 设备的唯一标识 设备登记/初次入网时间 设备MAC与IP地址信息 设备硬件信息 设备操作系统类型及其精确的版本号 设备关键安全配置情况（如是否配置密码、锁屏等） 设备最后一次可靠杀毒时间及结果对应的，服务端在收集到这些信息后，应当以唯一标识为索引，建立起设备全生命周期状况跟踪，包括重要硬件替换等，直至设备被标识销毁。零信任L4网关零信任四层流量网关的建设，完全依赖于安全客户端的建设进度。没有4层流量网关的安全客户端，尚能完成用户环境信息收集，但没有安全客户端的网关，则无法完成任何工作。零信任4层流量网关应具备能力如下：流量还原：自TLS隧道中获取报文，将外层封装部分（Private DataLen与Private Data）摘除后，还原用户请求报文。授权请求：自Private Data中获取用户身份凭证、设备唯一标识等信息，并以此向零信任决策中心请求此次访问授权结果。会话管理：依照授权中心判定结果，决定流量转发/拦截。相对于7层流量网关，可以与现有网络组件相结合，4层流量网关则需要完全从头搭建，因此需要综合考虑性能及吞吐量问题。合理计算并部署集群资源，正确的负载均衡实现，充分可靠的监控及报警设施都是保障服务稳定的必要措施。另外，需要值得注意的是，4层流量网关目前不具有降级功能，降级意味着企业服务对外完全敞开。因此，当紧急事件发生时，需要考虑其替代方案，如VPN等。最坏情况，也需要保证“逃生门”可用。零信任风险识别零信任风险识别，旨在通过持续的信息收集及分析，完成信任的持续评估。而在系列文章开篇时曾经提到，企业引入零信任思想及网络架构，以解决传统安全架构中无法解决的问题，但我们不否认传统安全手段在某些领域的有效性。因而，零信任网络的出现，并非替代传统安全设施，而是期待与传统安全措施相结合，以产生更为快捷、有效的防御机制。综合来看，我们建议使用与SIEM（安全信息和事件管理工具）相结合的方式来实现信息的收集与分析，最终达成信任持续评估的目的。SIEM作为企业网络防御的核心部分，可以与零信任网络形成更为有效的闭环： 零信任网络向SIEM输入更为有价值的分析数据。 SIEM作为事件分析与处置决策发起者。 零信任网络作为最终事件处置执行点存在。下表列举了零信任与SIEM联动后，对于各类安全攻击的防御措施及处置方式。除此之外，零信任平台中，需提供了人工风控入口，弥补自动识别缺陷，可实施登录态踢出、黑名单添加等动作，作为应急处置的手段存在。其他零信任组件相对于上述组件的建设，零信任关于网络隔离部分，在符合安全管理要求的情况下进行，因此本文不再深入介绍。PKI/CA设施建设，归属于另外一个企业安全基础设施建设的领域，也不在此赘述。关于哑终端覆盖部分，我们也正在积极探索，但尚未完成相关部分的建设，因此待方案成熟后再进行补充。写在最后零信任网络建设，是一项艰难且长期的工作，建设过程中涉及许多同SRE团队、网络团队甚至业务团队协作完成的工作，但其可见的效果值得企业投入并持续迭代。本文仅作为我们实践过程中的一些经验的记录，抛砖引玉，后续也将有更多的建设细节呈现出来，希望同大家分享，并共同探讨零信任网络建设方法，共同解决建设过程中遇到的困难。 预览时标签不可点 安全4工程实践6安全 · 目录#安全上一篇贝壳零信任网络建设技术总结（上篇）下一篇房地产互联网领域黑产常见攻击手法初探关闭更多小程序广告搜索「undefined」网络结果