堡垒主机为何会增加风险

为了管理私有网络中的服务器，团队过去通常使用堡垒主机（也称为跳板机）：这是一台经过强化、面向互联网的实例，您先通过 SSH 连接到它，再跳转到内部计算机。虽然这种模式很常见，但它会通过多种方式扩大攻击面，而 SCS-C02 考试要求您能够识别并消除这些风险。

堡垒主机位于公有子网中，并向互联网或企业 IP 地址范围开放某个端口（通常 SSH 使用 22，RDP 使用 3389）。管理员先连接到它，再访问私有实例。它是进入整个环境的唯一受保护入口，因此既至关重要，又是攻击者的首要目标。

最大的风险是开放的入站端口。任何可从互联网访问的 SSH 或 RDP 端口都会持续遭到攻击者扫描和暴力破解。即使使用基于密钥的身份验证，暴露的端口也会招来攻击；而堡垒主机上的一次配置错误或未修补漏洞，就可能让攻击者进入整个网络。

堡垒主机访问通常依赖分发给管理员的长期有效 SSH 密钥对。这些密钥可能被复制、丢失，或留在前员工的笔记本电脑上。在整个服务器群中轮换密钥十分麻烦，而且通常很难准确记录哪个密钥开启了哪个会话，从而削弱了责任追踪能力。

通过堡垒主机追踪谁做了什么十分困难。原生 SSH 很难集中记录在下游主机上执行的命令。调查事件时，您必须拼接各台主机的日志；如果堡垒主机遭到入侵，攻击者还可能删除自己的痕迹，这正是审计人员会指出的可见性缺口。

堡垒主机本身也是一个必须持续修补和强化的实例。如果更新滞后，它就会成为最薄弱的环节。维护一台高可用且始终安全的跳板机会持续增加运维负担，在没有带来业务价值的情况下增加成本和风险。

由于所有管理流量都要经过堡垒主机，它既是单点故障，也是高价值目标。如果它停止运行，管理员就会失去访问权限；如果它被攻破，攻击者就获得了发起进一步攻击的平台。将风险集中在一台暴露的主机上，是考试希望您避免的架构。

AWS Systems Manager (SSM) Session Manager 完全消除了对堡垒主机的需求。它通过 SSM 服务为实例提供 Shell 访问，无需开放入站端口、无需公有 IP，也无需 SSH 密钥。访问权限由 IAM 控制，且每个会话都会被记录，一次性解决堡垒主机模式的所有弱点。

SSM 之所以能够工作，是因为实例运行着 SSM Agent，并由它向 SSM 服务建立出站连接；系统不会开放任何入站连接。安全组可以拒绝所有入站流量，同时管理功能仍然正常。这种从入站改为出站的反转，是使堡垒主机过时的关键理念。

在考试中，任何描述开放 SSH/RDP 端口、分发密钥对或使用跳板机的场景，几乎总有更好的答案：使用 Session Manager 替代堡垒主机。这样可以缩小攻击面，将访问控制集中到 IAM 中，并生成完整的审计记录，这正是 AWS 推荐的安全、最小权限设计。

堡垒主机暴露入站端口，依赖长期有效的 SSH 密钥，审计能力较弱，还必须持续修补，因此会成为集中且极具吸引力的目标。推荐的替代方案是 SSM Session Manager，它通过 IAM 控制、完整记录的 Shell 访问来授予权限，完全不需要开放端口、公有 IP 或密钥。

测试您对堡垒主机风险的理解。

堡垒主机会开放入站 SSH/RDP 端口，依赖长期有效的 SSH 密钥，审计能力较弱，并且需要持续修补，从而将风险集中在一个暴露的目标上。SSM Session Manager通过出站 Agent 连接替代堡垒主机，提供由 IAM 控制且完整记录的访问，无需开放端口、公有 IP 或密钥。