网站建设资讯

NEWS

网站建设资讯

跟着大公司学安全之BeyondCorp安全架构

 过去这些年,技术发生了很大的革命,云计算改变了业务方式,敏捷改变了开发方式,某宝改变了购物方式。而在内部安全上,零信任则提供了一个新的模式。

为阳谷等地区用户提供了全套网页设计制作服务,及阳谷网站建设行业解决方案。主营业务为网站制作、网站建设、阳谷网站设计,以传统方式定制建设网站,并提供域名空间备案等一条龙服务,秉承以专业、用心的态度为用户提供真诚的服务。我们深信只要达到每一位用户的要求,就会得到认可,从而选择与我们长期合作。这样,我们也可以走得更远!

过去这些年,各种数据泄漏层出不穷,我懒得去找例子,反正比比皆是,从大公司到小公司,从政府到商业机构。这说明什么呢?这说明我们过去的方法出了问题,以前基于边界来划分可信不可信的办法行不通了。

传统的内部安全外围取决于防火墙、VPN来隔离,但随着员工用自己的电脑、用自己的手机、再加上云计算,整个网络边界越来越模糊。零信任安全则直接在概念上颠覆了原有概念,内部用户比外部用户更不可信!看以往的各种案例,太多由于黑客掌握了密码,证书之后得手的攻击。因此,对这些内部用户零信任,可能是未来减少数据泄漏的主要方法。

  一、Google实践

Gartner提出了CARTA方法论,意为持续自适应风险与信任评估,包含了零信任安全的核心元素。当然,更关键的是,Google已经在15年就开始付诸实施,这个项目就是大名鼎鼎的BeyondCorp,开始从本质上改变。BeyondCorp完全不信任网络,而是基于设备、用户、动态访问控制和行为感知策略。零信任需要一个强大的身份服务来确保每个用户的访问,一旦身份验证通过,并能证明自己设备的完整性,则赋予适当权限访问资源。所以这里有四个元素:验证用户、验证设备、权限控制、自学习和自适应。

跟着大公司学安全之BeyondCorp安全架构

  1. 验证用户

验证用户最基本的是用户名和密码,但怎么确保这个密码不是从黑市上买来的?所以就出现了多因素认证来获得额外的保证,国内一般是短信验证码或软硬件token,当然现在也开始逐渐出现人脸、指纹等。用户有很多类型,普通用户、管理员、外包、合作伙伴、客户,多因素认证都可以适用。

  2.验证设备

要实现零信任安全,要把控制扩展到设备级。如果设备未经过验证,设备就不可信。如果用户数用常用、可信设备访问,则有可信度。如果他在网吧用一台电脑来登陆,那这个信任度就低。设备验证还包括了一些安全准入条件,比如是否安装杀毒软件和最新补丁。

 3. 限制访问权限和特权

限制用户最小权限的访问,就可以限制攻击的横向移动。其次是对业务应用的授权,业务层包含大量敏感数据,是攻击的首要目标,因此在应用侧限制权限也同样重要。数据越重要,权限越少,也可以用多因素来进一步验证。

  4.自学习和自适应

收集用户、设备、应用和服务器数据和行为信息,形成日志数据库进行机器学习分析,达到异常识别的目的,比如从异常位置访问资源,则立即触发强认证。

  整个方案有几个好处:

一是重新定义了身份,以前都是根据角色进行的,而零信任模型则更加动态,用时间、属性、状态的组合来实时评估。

二是集中控制,所有的流量都通过中央网关来处理认证和授权,这种网关可以拦截所有到资源之间的通信。但中央网关不是只有一个,而是分布式的,只是逻辑上的集中。BeyondCorp就在每个受保护的资源之前放了一个反向代理服务。

三是主动防范,能够检查日志做审计是一回事,能够实时拦截主动防范则是另一回事了。

Google的方法很好,值得借鉴,但不一定要完全照搬。每个企业有自己的实际情况,要是上来就干,可能会导致更多的问题。根据Google的几篇论文,我试着分析一下实现路径做参考。

  二、信息收集

整个项目上,第一步要实现的就是数据的收集,收集数据的作用是掌握全局,包括账号和应用的流向关系、网络架构、应用协议等。在这个过程中也能清理掉很多没用的系统和账号。而数据的收集分为几种:

  1、设备信息

因为设备验证属于一个重要环节,因此要对设备进行清点。Google要求所有设备都有IT管理,并且保存一个资产库,但这在国内企业中并不现实,例如有的员工自带电脑,自带手机。所以实际上需要在Google的思路上有所拓展,虽然我不知道,但我可以通过设备指纹来建立一个资产库。每个设备都有的独一无二的标识,通过标识,把员工常用设备作为可信设备,从而建立自己的资产库。

  2、梳理访问记录

零信任的目标是完全消除静态密码的使用,转为更加动态的验证,可以对每个单独的访问发布范围、时间的证书。这是这个架构的好处,也是防范内部风险的最佳答案。所以需要掌握公司内部的访问记录,常见是通过SSO访问日志来进行。而且定期review内网访问日志,也应该是一个常态化工作。梳理这个的目的,是了解账户和应用之间的关系。

  3、系统架构图

零信任的目标是抛弃掉网络层的访问控制,但现实是需要在整个过程中逐步改造,因此需要掌握网络拓扑,掌握各访问控制的位置,掌握资源位置。最后才能达到把访问控制放到应用侧来实现。所以这里的着眼思考点是,如果我把这个资源放到互联网上,需要怎么控制。

4、流量日志

流量是基于网络拓扑来的,在应用日志完备的情况下,甚至可以不需要做流量日志。不过考虑到大家的实际情况,还是加上比较好。另外网络内跑的协议也很重要,Google在计划阶段发现网内使用了各种协议,因此在新系统中作了严格的规定,以HTTPS和SSH为主要协议。

  二、访问策略

在Google的论文中,多次提到了他们在形成这个框架时面临的挑战,为了有效推进,这个安全措施必须在全公司强制执行,覆盖广泛且易于管理。这其实在很多公司是个不容易的事情。而且Google也提到,安全架构不应该影响生产力,在国内就是就是安全不应影响业务。因此把敏感应用放到公网上,需要小心谨慎。零信任要求每个请求都完整验证身份,授权和加密,这个信任是基于动态用户和设备决定的,而不再基于网络单一维度进行判断。

数据收集以后,接下来要做的事情就是访问策略框架了。Google整个项目周期是7年(泪奔,7年后我还在不在现在的公司都不好说),提到的建议是情景决策,换成中国话的意思就是业务场景。例如我是一个运营,要去访问运营报表系统,那么我用公司给我的笔记本电脑登录报表系统,然后通过跳板机登陆到Hadoop上去调整源数据。这些业务场景会告诉你一些信息,运营应该授予报表系统、Hadoop权限,而在这里的授权元素包括,设备、角色、被访问资源、时间等。

  1、数据字段

听上去比较别扭,换成中国话的意思,要收集那些数据维度,以用做访问控制要素。常见的比如组织架构、角色。新增的设备与用户配对关系,也包括比如操作系统是否更新,杀毒软件是否安装这些设备状态。同时也可以包括更多的要素:时间、位置、多因素等。这些条件组成了验证规则,但这太容易被猜测出来了,所以在这个基础上,还可以增加一些新的判断字段,比如wifi的mac等信息。

 2、规则

接下来制定规则,规则中除了包括上面所说的字段,还应包括行为信息。例如有一个提出离职的员工,进入文档系统大量下载文档,这就是一个风险。可能需要的规则是,打通PS系统掌握谁提出了离职,然后限制该员工对文档系统的大量下载行为。再细分一点规则,主动离职和被动离职对系统的风险是不同的,下载和查看文档也是不同的。

规则中一个常见错误是设置了太多细致的规则,Google在实践中遇到了这个问题,最终他们在代理服务的粗粒度,和后端资源的细粒度之间找到了平衡点。在论文中他们提到了两个例子:

全局规则:粗粒度,影响所有服务和资源。比如“底层设备不允许提交代码”。特定服务规则:比如G组中的供应商允许访问web应用A。

如果规则太复杂,或者对资源规定太过具体,那对规则的语言是很有挑战性的,所以应该用一套任何人都可以理解的策略规则。Google的做法是从粗规则开始,然后再将RBAC和ABAC引入。

  3、权限

零信任是把信任从外围改变到端点,目标是在不断变化的环境中基于动态用户和设备,做出智能的选择。BeyondCorp是最小权限原则,通过不断地处理用户、设备、行为数据,为这些数据建立信任值,每个资源都有一个信任层,必须满足才能访问。比如你的手机版本过低,系统会给你一个低信任评分。当你访问工资数据的时候,需要你有更高的信任等级。你必须把手机版本升级,否则不能访问资源。这其实和金融里的信用分一个意思,这些元素的组合形成了分数。

但有一点,就是要明确的告诉用户,基于什么原因,你的分数过低,要把补救方法明确的提示出来,不然用户就陷入了迷思,然后会干出一些乱七八糟的事情出来。换句话说,可以把规则形成问题,你的补丁打了吗?杀毒软件更新了吗?然后通过验证这些问题,赋予权限。

 三、访问控制

策略订好了以后就是控制措施,这里也是国内大多数公司和Google做法有分叉的地方,Google当然有能力自己造所有轮子,操作系统都能自己写,但国内公司很少会这么干,同时在内部这些应用里,或多或少都会有外购的应用系统。

  1、微服务

传统系统已经做了很多访问控制手段,有的可能就是一个SSO账号,这种方式是角色、权限是在后面逻辑上处理的,也就是说,你先进入内网门户,然后通过门户进入各个子系统。在进入门户这个环节并不做后面的资源的验证,把验证放在了后端应用上处理。这也就是之前乌云还在的时候,我们看到一旦拿到一个员工账号,就可以在内部各种横向漂移。

而在Google,则使用了微服务,把验证逻辑和资源系统隔离,以实现灵活的验证。加入你们采购了外部的一个财务系统,那么财务系统在这里只看作是一个原始数据的记录系统。通过微服务方式的解耦,服务之间不再需要关心对方的模型,仅通过事先约定好的接口来进行数据流转即可。因此策略层改变起来也很容易,这是其中一个关键。

  2、集中处理

零信任中有一个处理所有流量的ACCESS GATEWAY,这是个反向代理服务,集中了身份验证和授权过程,统一进行处理,也是理想的日志监控点。代理服务支持PKI证书,所有请求都通过HTTPS提供给网关,用户和设备的数据在这时候被提取出来进行验证授权。再接下来则是SSH,RDP或TLS连接,与资源进行安全会话,这就大大限制了攻击面。

跟着大公司学安全之BeyondCorp安全架构

在某个时间点,根据动态数据来配置身份验证,而不是单纯的依靠网络。这就是零信任系统的能力。但在初期的时候,这个动态,是需要经过磨合的。最简单的例子是根据大多数人的共同的行为来调整策略,这里就需要机器学习来辅助,让机器来了解共同行为是什么意思。

  四、资源迁移

最后一步则是资源的迁移。资源迁移有个灰度过程,关键系统往后放,先从简单应用开始,这个应用应该适合粗粒度规则,且数据敏感度比较低,比如内部的wiki这种。为了防止在这个过程中的数据泄漏,Google初期是并联传统系统的,然后逐渐割接。Google非常强调他们把所有资源都放到公网上,消灭了网络分区需求。但实际上,我们大可不必这么冒险,传统基于网络层的控制方法仍然可以使用。

跟着大公司学安全之BeyondCorp安全架构

通过这个逻辑,只需要把流量指向访问结构,就可以保护资源。在所有流量都经过网关的情况下,需要确保和应用的连接是安全的,每个请求必须端到端加密。但只有这么个安全隧道是不够的,还需要确保每个请求都被完全验证授权,方法上可以是对请求证书和关联数据进行签名,再配置应用验证,也可以是对特定IP列入白名单。

  五、总结

Google在基础架构安全上付出了巨大的努力。我在看这些paper的时候就在想,为什么Google公开宣传内部的安全实践呢,我以小人之心揣测,可能与Google云相关,从Google一系列的博客来看,信息保护一直都是重点范围。但对于我们这些安全从业者来说,这5个paper提供了很多安全的先进点,让我们一探顶尖互联网企业的基础安全架构。整个阅读理解过程中,有几句话我觉得是特别值得总结的:

1、“我们不依赖于内部网络分隔或防火墙作为我们的主要安全机制”

我曾在阿里工作过几年,早在14年阿里安全就提出“去防火墙”。但当时的“去防火墙”思想,更多的是摆脱传统盒子硬件防火墙层次,和Google还不一样。零信任的核心主题是,它是一个无周边架构,这和Google的员工分布在全球各地办公有关系。这并不是说防火墙完蛋了,而是说不作为“主要”安全机制。但是在借鉴过程上,去防火墙不是第一步,而应在各种认证、授权等机制建立后的最后一步。

2、“最终用户登陆由中央服务器验证,然后中央服务器向用户端设备发送凭证,例如cookie或OAuh令牌,从客户端设备到Google的每个后续请求都需要该凭据”。

零信任基于用户和设备的状态做出智能决策,凭证是动态的,也就是可撤销、可审计、有较短时间期限。这其中说,每个后续都需要该凭据,这就是零信任的精髓了。

3、“实际上,任何发布的服务都使用GFE作为智能反向代理前端,这个代理提供了DNS,拒绝服务保护,TLS终止和公共IP托管”

把内部应用放到公网,可以实现端到端的前向加密,但却让系统面临攻击,通过反向代理来管理这些流量。现实而言,我们并不需要这么激进,抗ddos保护对于中小企业来说,还是应该依靠外部力量。

4、“在企业局域网上不是我们授予访问权限的主要机制。相反,我们使用应用程序级的访问管理控制,允许我们只在特定用户来自正确管理的设备以及期望的网络和地理位置时才将内部应用程序公开。

身份认证是整个流程中的重要部分,但零信任独特在于:用户、设备组成一个可以实时进行信任决策的配置文件。举例来说,我在北京从我的手机上登陆crm应用,那肯定不会在同一时间允许我在上海的pc上登陆。访问策略上要么允许,要么提示你另一个认证因素。

安全性和可用性一直存在互相矛盾,安全部门要在这里寻找平衡。每个公司也都有自己的风险容忍度,有的公司因为月饼开除员工,有的公司因为云盘上传开除员工。每一个处罚,都会引起内部很多争论,对于零信任来说,决策是动态的,允许更多的自适应,其中机器学习是这里的重要工具。

5、“我们积极地限制和监督已经被授予基础设施管理权限的员工的活动,提供能安全和可控的方式完成相同任务的自动化,不断努力消除特定任务的特权访问需求。

零信任目的在减少内部威胁,整个架构中学习和适应是重要环节。同时也对自动化很敏感,在这么大一个全球企业中,人工是不现实的。另外,整个项目对特权的检查,会比对普通权限的检查要仔细的多。


当前名称:跟着大公司学安全之BeyondCorp安全架构
网页URL:http://cdweb.net/article/gdsepe.html