本期话题抢先看
1. 日常在管理测试环境时有没有好的管理规范和技术措施？
2. 关于测试业务需要互联网访问权限有没有什么好的管理方法？
3. 对于堡垒机方面，除了非堡垒机登录监控，以及高风险命令执行监控，还有什么其他可以监控的点？
A1：
每家公司不一样，管理测试环境是需要付出很大的成本。网络隔离测试环境，特殊业务特批，先限制增量，再治理存量，最后出台政策，在隔离区域内定期评估，最终在测试机上安装入网控制软件，做好终端层面自动化入网与安全评估管理。
A2:
环境隔离：确保测试环境与生产环境严格隔离，以避免测试活动对生产环境造成影响；
访问控制：设置适当的访问控制机制，只允许授权人员访问测试环境，并采取强密码和多因素身份验证等安全措施；
版本控制：使用版本控制系统管理测试环境中的代码、配置文件和文档，以实现更好的跟踪和协作；
配置管理：有效管理测试环境的各种配置，包括操作系统、数据库和网络配置，并采用自动化工具提高配置的标准化和准确性；
日志记录：启用详细的日志记录机制，帮助故障排除、监控环境运行情况和检测潜在的安全问题；
数据备份和恢复：定期备份重要的测试数据，并确保能够快速恢复到先前状态，同时保护敏感信息的安全；
漏洞管理：定期进行漏洞扫描和安全评估，及时修补测试环境中发现的漏洞，减少安全风险；
自动化测试：建立自动化测试框架和流程，提高测试效率和一致性，并生成相关的报告和指标；
变更管理：跟踪和管理对测试环境的变更，确保经过适当的评审、批准和记录；
监控与警报：设置监控系统实时监测测试环境的性能、资源利用率和异常情况，并设置合适的警报机制。
A3：
按需申请，发布配置平台上安全卡点，评估是否需要互联网访问，能否设置 IP 来源白名单。
A4：
互联网专线这个口子把好关，要么正式上线+通过安全验收才能接入互联网，要么紧急测试的话，互联网这边做ACL，但是往往很多企业没有领导支持这个做法。
A5：
域名解析怎么出去的，怎么做白名单？正在推动这个事情，有点麻烦。
A6：
防火墙做ACL，只允许外部精细IP访问这个测试系统，然后Deny all。
A7：
流程管理规范安全合规评估、ACL审计、外网资产梳理清晰、明确问责关系，找个外部团队给他们资产渗透按照成果给钱，后续出事就准备去问责。
A8：
VPN加ACL。
A9：
测试用户是非公司内部人员呢？VPN不太好管理。这类业务也比较头疼。
A10：
业务还能自己变更映射？
A11：
每个部门自己买自己的专线、防火墙，也不排除有这种可能。
A12：
那也得在IT登记吧，按流程的话，变更需要经过渗透，而且要留痕。
A13：
我猜测是把内网IP挪给测试服务器用，我想是不是互联网映射配置没变，内网把IP挪给测试服务器用，如果是前者，那就收回映射的权限。
A14：
我们都有过SSH用80，就为了绕过审查。
A15：
这是不是也绕过了四层的访问控制？
A16：
这就是为什么我想做七层的原因，总是有骚操作绕过去的。
A17：
这种情况测试环境会多点，生产还不会出现。睁只眼闭只眼就过了。
A18：
协议通过指纹、流量分析的办法可以抓到，只不过如果是应用改了的话估计会难发现一些。
A19：
资产指纹识别内容也不少 要是定期和不定期扫描对比注册时的指纹完全可以自动发现自动识别自动Deny掉的。
A20：
1.资产的全生命周期管理应该涵盖所有的在用服务，通过资产收敛和发现去规避这些资源的滥用情况；
2.在网络服务和策略上，隔离测试环境与正式环境的网络访问，一方面可以杜绝内网漫游，同时也可以确保测试环境的误操作；
3.使用统一的对外安全服务入口，无论正式还是测试环境都通过安全网关进行网络扫描。
A1：
你非堡垒机监控怎么实现的？单纯通过堡垒机日志吗？
A2：
非堡垒机，不是堡垒机的IP。
A3：
非堡垒机登录监控，这个主要在主机侧做的监控。
堡垒机的监控点有：高危命令执行监控、黑白命令监控、管理员的审计数据导出、自动改密导出监控、计划任务监控、资产导出监控、异地异常登录监控、主机/密码授权监控。
A4：
嗯，我们也是这样做的，以为还有啥新途径了呢。
A5：
再增加一个，有大佬说针对数据库链接客户端的监控，或者数据库执行相关的监控。
A6：
数据库链接客户端怎么理解？
A7：
就是类似Navicat这种，大佬的意思好像是监控是否直连数据库，具体我也还在想具体场景。
A8：
这个数据库监控是不是要用数据库运维堡垒机？我记得数据库运维堡垒机有客户端监控的选项，会识别来源的客户端，判断客户端合法性、准入性、兼容性。
A9：
好像是，但是不见得每个公司都能单独买个数据库相关的运维堡垒机。
A10：
其实你这个还是结合主机或者数据库层面的日志来的，大了说都是访问控制层面的。我们工具用到的都是个人账号，而且只能通过安全指定的IP连接，其他都会被定义为绕过，数据库层面直接Block。
A11：
阻断。
A12：
如果还不到阻断这个级别的，会怎么处理？
A13：
这个我不太清楚，可能就告警日志吧。
A14：
我们的高危命令有两种，一种是直接Rejection，还有一种就是Approval，资产上级审批就执行。
A15：
不能阻断的监控，监控到的去找执行的人确认，如果是通过堡垒机登录执行的，是会有执行日志的。
A16：
就感觉这个工作量有点大，感觉实践上有点搞不过来。目前我们还是偏事后查问题去处理使用的。
A17：
也不大，前提是业务、运维侧协商一致，一些命令就是禁止不让用的，并且规范里说明。那么其实后期执行中使用到高风险命令的情况会相对少。一旦有告警去确认一下就行，反正有用户名，执行内部的通讯工具确认下即可。
关于管理测试环境时的规范和技术措施，以及测试业务时互联网访问权限管理，可通过按需申请、互联网专线接入管控、防火墙和ACL控制等方式，帮助减少测试环境中的安全漏洞，并降低系统被攻击的风险。同时，建立明确的流程和规范，在变更和访问控制方面加强监管和审查，避免类似业务部门私自变更的情况发生。
在讨论到堡垒机监控中关于非堡垒机登录监控和高风险命令执行监控点外，还可以有高危命令执行监控、黑白命令监控、管理员的审计数据导出、自动改密导出监控、计划任务监控、资产导出监控、异地异常登录监控、主机/密码授权监控以及针对数据库链接客户端的监控等。至于匹配到高危命令的处理方式，可能的处理方式包括阻断命令执行、告警日志记录、进行审批等。具体的处理方式需要根据组织的安全策略和流程来确定，确保及时发现潜在的风险，并采取适当的措施来处理。
A1：
可以做一下免杀样本过一下，主要还是对用户电脑的资源负载考虑，还有在查杀任务时的资源占有。
A2：
更新病毒库方式、对现有网络影响。
A3：
一般这个还好吧，都很成熟了，后台联网更新，不联网，就只能手动推送。
A1：
堡垒机。
A2：
堡垒机直接开到互联网？
A3：
给个VPN。
A4：
还有一种直接打通的，比如向日葵，ToDesk。
A5：
堡垒机放云上，云和内网打通。
A6：
带OTP的VPN或者云桌面登进去，访问堡垒机，外网一定要加OTP，否则HVV会被虐的很惨。
A7：
这两种方式怎么样？
A8：
理论上第二个比第一个要好，重点是要安全，可审计回溯。
A9：
有堡垒机审计回溯没问题。这个入口是个问题。
A10：
但是只考虑安全性，不考虑效率的情况下，可以在VPN后加个云桌面，VPN接入后直接通过云桌面连其他的，这样避免数据落到本地。
A11：
第一种跳板机那个有哪些风险呢？
A12：
容易泄露，谁都可以连，而且没审计记录。
A13：
登到跳板机上再用堡垒机，就有审计记录了，只不过连到跳板机上没有记录。
A14：
我们现在有两种访问方式：
1.内部开发和运维：带OTP的专用vpn+OTP的专用堡垒机；
2.外包开发：带OPT的专用VPN+专用云桌面+OTP的专用堡垒机。
专用的VPN在部署的网络上只允许访问堡垒机和云桌面，云桌面在网络上只能访问有限的资源和端口。
A1：
10分钟-30分钟。
A2：
看试用场景，这个感觉有点苛刻啊。金融的才会30分钟吧。
A3：
大部分30分钟足够了，有多少是连续业务。
A4：
看具体情况定，比如OA的需要移动端和WEB联合办公，30分钟估计业务开骂了。
A5：
你的账号锁屏策略多少时间，Session就是多少时间。
A6：
之前C端是要求2小时比较多，B端还更宽点，当然对于安全来说越短越好，每个操作重新登录最好。
上期话题回顾：
活动回顾：
FreeBuf甲方社群每周开展不同的话题讨论，快来扫码加入我们吧！
【申请流程：扫码申请-后台审核（2-5个工作日）-邮件通知-加入社群】
注：目前1群、2群已满，如有疑问，也可添加Kiki群助手微信：freebuf1024，备注：甲方会员
“FreeBuf甲方群”帮会已建立，该帮会以三大甲方社群为基础，连接1100+甲方，持续不断输出、汇总各行业知识干货，打造网安行业甲方专属资料留存地。现“FreeBuf甲方群”帮会限时开放加入端口，让我们一同加入，共同建设帮会内容体系，丰富学习交流地。
文章引用微信公众号"FreeBuf",如有侵权,请联系管理员删除!
