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

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：一般是两种情况，一种是我们会要求测试团队维护一份测试环境数据库清单，我们不定期上去检查，二是通过一些安全事件倒查发现违规。

如何进群？

如何下载群周报完整版？

请见下图：