如何应对堡垒机安全风险

堡垒机作为服务器和网络安全控制的系统，包含了用户管理、资源管理、策略、审核等功能，为企业安全提供了有力保障。但越是复杂的系统，可能遭遇的漏洞与威胁也越大，因此，堡垒机安全的重要性自然不言而喻。本期话题，我们就聚焦于堡垒机本身，看看大家在遇到有关安全风险时如何“排忧解难”。

单点故障和绕过访问是堡垒机比较容易遇到的安全风险，对此大家的解决办法是什么？除此以外还遇到过哪些其他安全威胁？都是如何解决的？

A1：单点故障（可用性）的话通过HA或集群部署，然后异地多站点的方式应对；绕过访问涉及到安全有效性的问题，有两种发现渠道，一是需要对网络安全策略进行一些监测与验证，通过部署在不同网段的节点做一些连通性测试，二是通过操作机器上的软审计功能，结合风险规则进行发现。还遇到过Log4j漏洞，通过升级版本打补丁解决。

A2:堡垒机支持双机双活，最好选择密码备份有逃生机制的方案，比如密码保险箱，防止绕过访问，必须网络明确管理来源的一致性。作为资产的集中管理和权限管理审计工具，首当其冲应对各种攻击，选择成熟服务商和产品很关键。

A3：堡垒机账号管理混乱，密码长期不换，这是个风险，还是得定期换密码。

A4：有很多堡垒机绑定域，拿下域=拿下堡垒机。

A5：单点故障是可用性的问题，架构层面HA或者集群都是可行性方案，通过部署不同物理机器或者分散机房的方式，也是解耦的一种实现；绕过访问，不同网段的问题基本可以通过网络ACL解决，同网段的访问容易绕过堡垒机，可以通过收集登录日志分析SIP是否是堡垒机白名单解决。感觉HIDS也可以解决这个问题。其他的风险诸如0Day、账号共享、高危命令操作等。账号共享问题，主要通过提升共享的难度和成本来规避。前端通过MFA等方式，后端可通过定期改密等方式。高危命令操作问题，事前将命令收敛，事中增加审批节点复核的方式。

A6：绕过这个风险，如果说的是不通过堡垒机访问目标服务器这种情况，我们是通过在接入交换机实施网络策略做限制的，仅允许堡垒机可访问SSH端口。

Q：攻防演练期间遇到堡垒机 0Day爆出，大家是如何进行处置的？

A1:不管什么时期，遇到0Day，首先确认堡垒机不对互联网开放，在攻击路径上设置多卡点管控，第一时间检查产品服务授权是否在维保期内，然后要求供应商尽快修复。

A2：堡垒机+零信任组合使用。

A3：初期主要是限制访问，严格访问策略，把访问频度低的需求暂时砍掉，访问频度高的流量丢到威胁感知里去。中后期厂商出具了相关补丁与缓解措施，及时升级维护。

A4：1.补丁发布之前，无POC细节，通过提升攻击难度，如继续收敛操作员登录SIP、管理员登录SIP；2.补丁发布之前，无POC细节，通过全流量设备，监控有无此类的攻击告警，重点关注；3.补丁发布，有测试环境的先测试，无测试环境的，待稳定版本发布后，通知升级。期间做好持续监测。

A5：堡垒机在HVV中经常会成为靶子，为了防止服务器撸了攻击堡垒机，我们是对堡垒机实施了最小化的网络访问权限：如仅允许VPN网段可访问堡垒机，堡垒机可访问目标服务器SSH端口，实施粒度是到端口、协议级。

Q：除上述外，还遇到过哪些堡垒机的自身BUG？最后都是怎么解决的？

A1:堡垒机自身BUG无穷多，喊上代理商/供应商上门即可。

A2：堡垒机的客户端稳定性欠佳，甚至没一些开源的VNC好用。

A3：估计也不算BUG，就是不够智能，在用户无操作但画面如果有一些动态的元素（如闪动条、动态桌面等），缺乏智能判断，审计数据大，结合部分会话控制策略有效性遇到问题，导致疫情影响下的远程办公场景审计数据过大，通过转发审计数据方式解决。

A4：目前遇到最大的问题，是图形化工具量一上来，就触发当前的BUG，无法使用。短期通过引流其他节点，重启BUG应用发布机器；长期通过升级。

A5：防火墙要放到堡垒机管理，堡垒机前面有防火墙，防火墙有问题导致堡垒机连不上怎么办？

A6：架构师设计问题，没有设置带外管理网。

Q：现在不少人吐槽一些厂商的堡垒机价格昂贵，会选择更换堡垒机，那在更换不同厂商堡垒机时需要注意些什么？除此以外还可以有哪些安全的低成本方案？

A1：堡垒机已经是市场化比较成熟的产品，价格昂贵情况实属未明确需求，只需要采购满足需求的功能模块即可。迁移堡垒机，需要注重资产导入、密码复原、灾备方案，全面规划方案，重点逐步推进替换。低成本的开源方案不失为好的选择。

A2：低成本的就是JumpServer 开源堡垒机挺好用的。

A3：可以通过一些可扩展的安全代理软件来做反向代理或者跳板代理，通过某一台特定的跳板机访问特定目标主机，如V2ray trojan 。

A4：如果更换堡垒机是慢慢换，还是直接一次性换完呢？

A5：慢慢替换，一下子替换，有难度。

A6：一般都是建议慢慢换，尤其涉及到使用习惯的问题，需要慢慢培养。

A7：需求层面：合规方面的需求，使用部门的需求，安全其他方面的考虑，建议分批次上线，直接切换影响用户体验，还可能会出现很多意想不到的事情。

阶段1，并行运行期间，邀请个别用户部门体验，提问题优化；

阶段2，陆续邀请其他部门，直至所有用户；

阶段3，明确切换时间，提醒用户尽早切换；

阶段4，切换后，保留历史堡垒机，规避用户访问；新堡垒机运行一段时间后，历史设备下线。

话题二：大家对象存储都全部要求私有吗？业务想拿桶来放允许公开的数据，是否允许呢？

A1：要依据数据安全管理制度，尽然已经定级为公开数据，那就随意。当然也不排除定级标准不规范。

A2：标准规范了，也不排除业务可能不知道，还有可能误操作。

A3：在这个时候可以提一些基线要求，满足了这108项，可以上。

A4：还是得看最佳实践吧，可是最佳实践不会那么细，就像基线要求，是否包含敏感数据，是否为测试数据等等。

A5：每家数据的战略定位都不一样，何况国内的实践不一定是最佳的。数据安全是独立的体系，是在基础安全之上的。

A6：多少安全基线都不合格的已经在上DLP 加密。喊着做数据安全了。

A7：我想着基础的也只能判断业务是否允许公开读、禁止公开读写这样了。

A8：业务定义的可公开，大概率只是他们认为不重要，不会考虑安全性。比如，我这边业务团队认为身份证号、银行卡号这些不算敏感信息。

A9：这个有明确制度规范要求，还好，我也管不过来了，再管下去，大头都要管不住了，只能给些基础的要求了。