我了解到，使 EC2 实例可通过 Internet 访问的最佳安全做法是将它们放在私有 VPC 子网中，在公共 VPC 子网中创建堡垒主机，并使用安全组仅允许来自堡垒的连接托管，然后进行密钥转发以登录私有实例。
但是，AWS 似乎提供了各种配置，这些配置似乎提供了与实际 Bastion 主机相似的功能。例如，在公共子网上使用安全组似乎相当不错，如果有人可以访问您的堡垒，那么他们似乎离您的私钥不远。无论如何，我是否可以在任何地方找到有关此主题的更多信息？
【问题讨论】：
标签： amazon-web-services security amazon-ec2 cloud
您可以在此处找到使用 Bastion Host 的最佳实践：https://docs.aws.amazon.com/quickstart/latest/linux-bastion/architecture.html
对堡垒主机的访问被锁定在已知 CIDR 范围内 入口。这是通过将堡垒实例与 安全组。快速入门创建 BastionSecurityGroup 用于此目的的资源。
端口被限制为只允许对堡垒进行必要的访问 主机。对于 Linux 堡垒主机，用于 SSH 连接的 TCP 端口 22 是 通常是唯一允许的端口。
请注意，创建 SSH 隧道以通过您的堡垒主机连接到给定资源是很常见的：https://myopswork.com/transparent-ssh-tunnel-through-a-bastion-host-d1d864ddb9ae
希望对你有帮助！
【讨论】：
这是一个最小化攻击面的问题。
对于堡垒主机，您唯一暴露于开放互联网（例如任何负载平衡器）是端口 22，该端口由 relatively trustworthy 软件支持。
这也是单点管理：您定义一个安全组来识别允许联系堡垒的 IP 地址，并创建一个包含授权用户的公钥的 authorized_keys 文件。当用户离开时，您会从每个用户中删除一行。
相比之下，如果您仅依靠安全组来保护可公开访问的主机，则需要在每个组上复制相同的设置（并根据需要删除/更新它们）。如果您允许 SSH 访问这些主机，则必须在每次更改后分发 authorized_keys 文件。
虽然我不建议这样做，但至少在堡垒主机上打开端口 22 以访问世界是合理的。如果您有很多用户，或者这些用户通过系留手机连接，这甚至可能是合理的。对于任意服务，这是您永远不会想要做的事情。
【讨论】：