企业安全建设实践之测试环境的安全管理

  • A+
所属分类:安全文章

企业安全建设实践之测试环境的安全管理


1月20日,【金融业企业安全建设实践群】针对测试环境安全管理展开了较为深入的讨论,给出了一些落地的思路和经验。我们将大家的讨论内容整理成此文分享,希望可以帮助到有同样痛点的同行:


Q:对于测试环境的管理,大家有什么好的办法或者有什么可推行的规范吗?测试环境变动比较快,变更不会走变更流程,还经常整个站点都铲了换新的,经常是各种默认页面、管理页面都不删除,安全性上很难保证。特别是对于需要联网的测试环境,风险很高,对于这类问题大家是怎么解决的?


A:1、测试环境当做隔离网管理,隔离网的访问控制很严格;2、需要联网的,限定方位来源 IP +时间。如果可以就从物理层面隔离网络,然后限制访问控制,可以的话在前面加一层http basic authorization 。


Q:可以联网的测试区以及不能联网的测试区有没有做区分呢?目前已经放了很多权限出去了,主要还是被互联网访问的,访问互联网的相对少一些,现在要收回来需要整体再梳理一遍。


Q:我们测试网和生产网是物理隔离的,如果要上监控设备,就得重新买一全套,成本比较高。


A1:一般生产环境配套全,反而风险可控,测试网要么就是规范管理,要么就是加强安全监测,什么都看不到挺吓人的。可以先借厂商设备的试用看看,说不定能看到意想不到的问题。


A2:WEB防火墙还是有必要买的,其他可以接入到现有设备做检测。测试环境和开发环境统一收口通过代理,然后部分应用限定 IP +时间,WAF 这些也是配套的。


A3:分情况的吧,如果必须与第三方联调的可以考虑特定的网络环境,如果只是外部的测试人员,走 VPN 也是不错的方法。内部测试给一个环境随便玩,但是要出入互联网就要过 DMZ ,严格管控和变更,源目限制做监控。外联测试区本来就建议要单独设计。按照生产网来管理应该就可以了吧,包括区域划分、安全设备监控、访问控制细化等等。


A4:被访也要做白名单,测试环境建议严格白名单访问。


Q:因为测试网生产网物理隔离,所以之前对测试环境不够重视。测试环境没有区分 DMZ 和非 DMZ ,防火墙放出去了也没有及时清理,现在问题挺多的。开墙的时候我们会限制不放敏感端口,但是有些员工用端口转发的方式进行规避,这种情况大家有碰到过吗,怎么处理的?


A:这个问题对攻击者来说不是问题,扫描器一扫,哪个端口上跑了哪个协议,不管你改什么都可以利用。能限来源 IP 就限,会少很多事情。亲身感受,还是白名单靠谱。可以定规范,白名单一般不超过几个,时限一般多长,过期要重新申请。


Q:之前没做白名单,看来确实要做一下了。我们还要求开墙的时候限定时间,开发人员为了方便都选的很长。


A:看以上信息,如果是我的话,现在最有效的方式是组织一次内部演练,然后把他们拿下,后面推制度+技术的整改建设一切都顺理成章了。


Q:发现端口转发问题通报了几次。但是对于配置不规范的,没有罚则,大家也不够重视。


A:如果不好推的话,就只能借助演练了。


Q:有做过,发现问题太多。生产环境大家还重视,测试环境重视程度不够。但是真正 HW 的时候扣分都是一样的,不管什么环境。


A1:若近期不能从整体或长远上落地一系列安全管控机制,那就定期做运维安全审计吧。结合运维安全管理基线警告或通报。


A2:对于测试网互联网应用测试管理我们是这样做的:


1、不涉及第三方等外部交互测试的测试应用原则上需通过 VPN 进行测试,不能直接发布在公网上进行测试。


2、涉及第三方合作方联调等外部交互需求的测试应用,按照如下原则处理: 


a) 如可以通过给第三方开通 VPN 进行测试,则原则上通过开通 VPN 进行测试。 

b) 如不能通过给第三方开通 VPN 进行测试,但可以限定访问源 IP 的,应设置白名单访问控制。 

c) 如不能限定访问源 IP 的,原则上应只在有测试需求时间段才放开公网访问,其他时间应关闭公网访问。 

d) 尽量把电商测试应用资源池进行独立。 

e) 对发布在公网的测试应用流量进行安全监测。 


我们测试网还有单独的 DMZ 区,涉及互联网的测试全部走这个 DMZ 区。测试网内部管理主要是要做到与生产环境的隔离,特别需要注意测试网和生产网的例外网络权限管控,再就是测试环境测试数据的管理,不要把生产数据未经脱敏弄到测试环境去了。


Q:“尽量把电商测试应用资源池进行独立”,请问这个是基于什么考虑?


A:电商测试应用比较特殊也比较常见,一般要求互联网权限,比如手机证券,我们考虑就把他独立出来了,方便统一管理。


Q:“再就是测试环境测试数据的管理,不要把生产数据未经脱敏弄到测试环境去了”,这个我们知道风险很大,但是现在没有好的管控手段。


A:测试数据一般是通过生产环境弄过来的,且需要数据库管理员配合,所以一方面是卡住测试网和生产网的网络权限安全审批,另一方面多通报几次违规情况,让数据库管理员绷紧神经,重点加强数据库管理员的安全意识。通报的效果还是不错的,基本数据库管理员不敢不经安全团队确认私自就把数据弄出来了。如果资金较多,可以在生产环境和测试环境间再加一道 DLP 。


Q:我们生产网和测试网是物理隔离的,不能通信。如果是DBA管的数据库,拿数据出来比较严格。比较麻烦的是运维的应用,数据库也是自己管理,不过这部分应用的数据不会涉及交易。


A1:原则上测试人员不能拥有生产环境的访问权限,生产环境的数据库统一由DBA管理,这个问题就解决了。


A2:测试环境划分DMZ缩小威胁面与影响面、严控互联网访问IP白名单,收紧可攻击源,这两个看来是大家实践比较多又见效快的。如果要配套生产环境类似的防护与检测产品,流量类监控比WAF好上一些,WAF的测试环境对每个应用太难维护管理,流量类监控的工作量就少多了。


Q:“c)如不能限定访问源IP的,原则上应只在有测试需求时间段才放开公网访问,其他时间应关闭公网访问”,对外测试需求,时间段的把控有个问题,涉及相当长时间且需求项目的怎么办?


A1:我们目前对这类情况当做是一项正式工作在开展:1.测试系统对公发布之前要求递交申请,安全审核卡点(应用基线核查、产品经理沟通将对公时间最小化、渗透、加安全防护配置、到期审计、提醒运维关闭),有点耗人力。而且测试环境对公网发布之后不能保证不变,没有卡变更流程,做好前期工作后面还是会有问题。


A:2:这里建议当生产环境管理,原则上我们的应用只要挂公网(无论生产还是测试),都要满足安全基线要求。


A3:目前我们测试系统对公发布,最有效的卡点是安全审核。只要渗透发现漏洞,立马驳回。


Q:不是要求修复漏洞吗,是直接驳回?


A:驳回,同时要求修复后再提交。


Q:违规问题是通过什么技术手段发现的?


A:一般是两种情况,一种是我们会要求测试团队维护一份测试环境数据库清单,我们不定期上去检查,二是通过一些安全事件倒查发现违规。


如何进群?

如何下载群周报完整版?

请见下图:


企业安全建设实践之测试环境的安全管理

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: