内网去死,基于IP认证的去死,VPN去死。

我原先对BeyondCorp有疑问。因为没去研究,偶尔看了几篇报道,我以为不用VPN,不用防火墙,不要内网,那就是所有服务器直接对外,是谁敢盲目自信到这个程度。然而当我终于抽空来仔细阅读了Google的6篇论文后,我发现我错了。

我开始以为是所有应用直接对外,后来才发现实际上是有一个网关在前端拦截,应用还是对内的,所有的访问都过网关,再通过网关判断是否给你转发到后端真实服务器。

这样子我们就可以隐藏后端真实服务器了,这样子是可以接受的。我认为BeyondCorp才是今后企业或组织网络安全架构的最高形态

BeyondCorp、零信任安全、零信任架构、零信任网络

对于BeyondCorp和相关的术语,可参考 https://www.beyondcorp.com 上面的5篇论文和360身份安全实验室的6篇翻译。我认为任何人都应当仔细阅读这些论文,即使你不是做安全的,里面有一些做事情的方法也是值得认真学习的。比如没有调查就没有发言权,通过完善的网络分析识别迁移过程,对用户发送邮件告知关闭VPN账户;用户自测试界面和管理员自发布,将工作量分散;逐步上线,允许多个形态并存,先富和后富;完善的用户手册等等。

360身份安全实验室在互联网安全内参公众号上的:

  • Google BeyondCorp系列论文(一):一种新的企业安全方法
  • Google BeyondCorp系列论文(二):BeyondCorp从设计到部署
  • Google BeyondCorp系列论文(三):BeyondCorp访问代理
  • Google BeyondCorp系列论文(四):迁移到BeyondCorp
  • Google BeyondCorp系列论文(五):用户体验
  • Google BeyondCorp系列论文(六):构建健康的机群

论文详细披露了实现的细节和实施过程中遇到的坑。

关于BeyondCorp的细节我这边不再细说了,我所要探讨的是,我们没有Google那样的研发能力,我们在其他地方还有很多薄弱的地方,我不知道厂商是否已有相应稳定成熟的产品形态,如何在高校内建立一个低配版的BeyondCampus?

高校内的现状:基于边界或者说基于IP的防护

对于内网,WannaCry大家都知道了,进入了内网可以为所欲为,这实际上是管理的懒惰造成的。认为内网内是安全的其实只是因为管理人员没法做内网大量的服务器的安全防护。于是划分了一个安全域,在边界做些简单的防护,就给了自己一个借口:内网是安全的。而这个也会养出用户的惰性,我们有遇到厂商部署完系统没开防火墙第二天就被黑了,厂商的理由是,他们的系统在其他地方都部署在内网,不开防火墙都没事。

在BeyondCorp,内网也不会死,会有更多精细化的安全措施来保障,比如虚拟机微分段、东西向防火墙,纵深领域上的所有防火墙等安全策略还是必须存在。唯一变化的是后端服务器不信任任何的访问,只信任来自访问代理AP Access Proxy网关的访问。

高校内的内网IP是比较复杂的,比如有多个运营商,学生宿舍使用运营商IP又要认定是校内,校外机构在校内办公分配IP段后又要剔除,还有访客的IP。于是在校内IP认定上策略是非常复杂。

为什么很多人喜欢NAT,实际上NAT是一个非常高内聚、低耦合的架构,使得对多出口运营商低耦合(好像还有BGP等解决方法),内部又有非常大量的IP地址可供调配。

高校内的现状:VPN

VPN的配置和协议的支持有用过的都知道,PPTP、IKEv2、L2TP、SSL(这里我也不懂),多个不同的客户端,不同的安全级别,连接的稳定性,自检测机制的缺失都是一件非常麻烦的事情。然而VPN不能在应用BeyondCampus后取消。只是旧的VPN采购比重应当下降,VPN在进化过程中还是不可替代的,应当作为用户的多种入口补充或者非HTTP协议或者管理员入口等在小批量内使用。

我惊讶地发现有些学校只给老师提供VPN不给学生提供VPN,他们担心学生使用VPN会带来一些麻烦。我想说的是,VPN其实他不是一个福利,是你为了安全将网站关在校内的一个让步,你应当是求着学生在校外来用VPN访问被你关在校内的信息系统。

由于高校师生还需要访问互联网数据库,数据库对用户的认定目前还是以IP为主的(未来可能会慢慢过渡到用户的认证)。有些形态的产品提供了在浏览器内访问远程正向代理通过认证后以中间人的模式去访问数据库,同时可以兼顾访问频率控制和访问数据分析决策,也是当前一个很好的解决方法。

高校内的现状:对外开放的业务

一般学校会对对外开放的业务进行一系列的上线前安全检查,并使用防火墙、WAF、IPS做一些防护。有些是为了提供业务不得不让业务带着漏洞上线的,但是,一旦对外开放了,安全就是很不可控的。这里有什么风险不细说了。

BeyondCorp解决什么问题

在不需要VPN的情况下,在标准浏览器内可以直接对业务进行访问,但是又阻止了业务真实服务器对外的直接开放

说起来有点拗口,举个例子:以邮件系统为例,在重保期间,邮件系统是一直对外开放的,一般邮件系统也不会需要拨VPN,因为拨VPN确实很烦,而且邮件系统作为定制较少的标准化产品,安全性确实稍微高一点,邮件系统的安全更多要面对的是登录用户伪造和登录后的用户如何预防XSS、钓鱼邮件、垃圾邮件等等。

如果应用了BeyondCorp会如何?邮件的SMTP需要长期对互联网开放这个可以忽略,我们关注的是Web、SMTP、POP、IMAP。原先邮件的Web在登录之前就需要对所有人开放,然而Web上有操作系统漏洞、Web服务器漏洞、程序方面的漏洞,0day漏洞,应用了BeyondCorp,也就是,可以将对邮件系统的攻击者缩小到只有有权限应该可以登录邮件的少量范围内。不考虑账户泄露(加入双因素认证和登录行为分析),这将攻击者从几十亿级缩小到几万以内

所以说零信任这个体现在哪?体现在真实服务器不信任任何流量,只信任访问代理过来的流量(信任通过IP认证,标准版BeyondCorp实现了一个加密的隧道),体现在访问代理不信任来自物理位置IP等的认证,只信任基于设备和身份结合的认证。

BeyondCorp不能解决什么问题

除了上面解决的问题,其他一概解决不了。当然,由于部署了统一的网关,可以在一个地方更加方便对安全规则进行应用。

原先业务系统有代码漏洞,该存在的还是存在,原先管理员拿着盗版PL/SQL进入数据库导致被勒索还是存在。

高校内建立一个低配版的BeyondCampus

高校的管理比较松散,学校不会给每个学生老师发一个受控的设备并进行客户端服务器双向认证,还跟踪你的硬盘网卡是否近期更换,我们从最头疼的业务系统服务器入手。

在当前环境下,我认为做好带认证的反向代理、堡垒机就差不多了。同时你可以扯着说你是在做小BeyondCorp的事。

将所有的业务系统对接到反向代理,对业务系统的管理全部走堡垒机,对业务系统的服务器开放的端口进行探测,只允许反向代理和堡垒机访问,否则报警整改,就够了。

对于身份认证使用目前已有的统一身份认证即可,最多区分教工、学生、校友,不去考虑在反向代理上管理很重的用户和业务系统访问的权限。对于准入,运维管理员识别等,由于准入通常是网络厂商解决的,统一身份认证是信息化公司处理的,业务系统是各种不同的第三方软件公司开发的,关系非常复杂,协调改造成本非常高。

其他的都保留现状,该内网还是内网,自己组网基于IP做防火墙,有能力释放公网IP迁移内网就迁移。漏扫,应用上线前检查,但是安全应该已经提高很大一个级别了。

反向代理直接用来做堡垒机?我建议不要。因为涉及到安全等级不同、稳定性要求不同、专业性功能不同、流量不同、带外管理、只做一件事情等等问题,应当分开。

其他非反向代理和堡垒机覆盖的流量,怎么样还是怎么样。

BeyondCampus带来的问题

如果使用了全网准入,每个人需要先认证进入网络,再认证进入反代,再认证进入各个业务系统,如何打通这些认证环节?认证进入网络可以通过记忆密码或者801.1x来完成无感知,同时可以在有限范围内向后端传递认证信息。认证进入反代和认证进入各个业务系统可以整合SSO来完成,这要求SSO需要对校外暴露,还要考虑SSO的范围。或者通过校内IP直接认证进入反代来解决。

迁移过程的工作量非常巨大,需要所有业务系统都进入反代,需要完善的迁移辅导。业务上线流程变长,管理复杂。而反向代理、堡垒机的健壮性和安全性会是一个非常大的考验,造成全校业务停摆和被入侵的安全风险也会很高。这需要更多的责任担当、更多的分离、更多的整合、更多的集群、更多的经常性安全检查来完成。

先写这一篇,抛砖引玉,有些错误,有些没想到,我将在接受到更多反馈后继续。