用Systems Manager替代堡垒机

[blog] https://aws.amazon.com/blogs/mt/replacing-a-bastion-host-with-amazon-ec2-systems-manager/

原堡垒机方案

堡垒机，也称为“跳板机”，通常被用作访问私有环境主机的最佳做法。比如，你有一个不允许公网访问的应用程序主机，要访问它做产品更新或补丁管理，你通常需要登录到一个堡垒机，然后访问这台应用程序主机。

对堡垒机的访问最好限制在一个特定的IP范围内，通常来自你公司的网络。为了进一步隔离，堡垒机通常驻留在一个单独的VPC中。下图是一个网络架构设计方案：

应用主机放在Application VPC中，堡垒机放在Management VPC中，两个VPC通过VPC对等连接。应用主机的安全组的规则仅允许来自堡垒机安全组的22端口访问。（SSH访问是22端口，Windows用户可以用3389端口替代SSH的22端口）。堡垒机的安全组设置只有22端口允许0.0.0.0/0访问。

由于应用主机在私有子网中，它只能通过同一个VPC的公有子网中的NAT网关来访问公网（但是无法被公网直接访问）。如果仅使用IPv6地址则需要使用egress-only internet gateway。你可以遵循以下步骤完成：

在堡垒机上安装应用主机的私钥；
在堡垒主机上建立一个SSH（安全外壳）会话。这通常是从一个受信任的网络中进行，如你的公司网络。
建立一个从堡垒机到应用主机的SSH。
运行 "ifconfig "命令确认是否连接成功。
如果要保存结果，你可以复制和粘贴输出，保存成一个文件。

Systems Manager替代堡垒机

安装堡垒机需要购买额外的第三方产品或者安装开源软件，需要经常修复堡垒机的漏洞。也可以尝试使用替代的方案，也就是AWS Systems Manager：

Systems Manager允许你在管理的主机上远程执行命令，而无需使用堡垒机（也就是EC2 Run Command，EC2运行命令）。通过一个主机代理轮询Systems Manager，以确定一个命令是否等待执行。

这里有一些好处：

这种方法使用AWS托管的服务，这意味着Systems Manager组件是可靠和高度可用的。
Systems Manager需要一个IAM策略，允许用户或角色远程执行命令。
Systems Manager代理需要一个IAM角色和策略，允许他们调用Systems Manager服务。
Systems Manager不可改变地记录了每一个执行的命令，这提供了一个可审计的命令历史，包括：
- 被执行的命令；
- 执行该命令的负责人；
- 执行命令的时间；
- 命令的简略输出；
当启用 AWS CloudTrail 以记录和记录运行 Systems Manager 的区域内的事件时，每个事件都会被 CloudTrail 记录下来，并记录在 Amazon CloudWatch 日志中。
使用CloudTrail和CloudWatch规则使你能够使用Systems Manager事件作为自动响应的触发器，如Amazon SNS通知或AWS Lambda函数调用。
Systems Manager 可以选择性地在Amazon S3中存储命令历史和每个命令的整个输出。
Systems Manager可以选择向SNS主题发布消息，在命令执行和完成时通知订阅的个人。
Systems Manager是基于代理的，这意味着它不仅限制可以用于Amazon EC2实例。它也可以在非AWS主机上使用，这些主机位于你的场所，在你的数据中心，在另一个云服务提供商，或其他地方。
你不需要管理SSH密钥。

你需要在主机上安装Systems Manager代理，Installing SSM Agent。

通过使用Systems Manager替换后，网络架构如下：

关于如何配置Systems Manager 与VPC建立连接，可以查看： Configuring Access to Systems Manager.

上一页通过Amazon Inspector保护主机和容器下一页模拟攻击测试防护效果

最后更新于1年前

原堡垒机方案

在堡垒机上安装应用主机的私钥；

在堡垒主机上建立一个SSH（安全外壳）会话。这通常是从一个受信任的网络中进行，如你的公司网络。

建立一个从堡垒机到应用主机的SSH。

运行 "ifconfig "命令确认是否连接成功。

如果要保存结果，你可以复制和粘贴输出，保存成一个文件。

Systems Manager替代堡垒机

安装堡垒机需要购买额外的第三方产品或者安装开源软件，需要经常修复堡垒机的漏洞。也可以尝试使用替代的方案，也就是AWS Systems Manager：

这里有一些好处：

这种方法使用AWS托管的服务，这意味着Systems Manager组件是可靠和高度可用的。

Systems Manager需要一个IAM策略，允许用户或角色远程执行命令。

Systems Manager代理需要一个IAM角色和策略，允许他们调用Systems Manager服务。

Systems Manager不可改变地记录了每一个执行的命令，这提供了一个可审计的命令历史，包括：

被执行的命令；
执行该命令的负责人；
执行命令的时间；
命令的简略输出；

当启用 AWS CloudTrail 以记录和记录运行 Systems Manager 的区域内的事件时，每个事件都会被 CloudTrail 记录下来，并记录在 Amazon CloudWatch 日志中。

使用CloudTrail和CloudWatch规则使你能够使用Systems Manager事件作为自动响应的触发器，如Amazon SNS通知或AWS Lambda函数调用。

Systems Manager 可以选择性地在Amazon S3中存储命令历史和每个命令的整个输出。

Systems Manager可以选择向SNS主题发布消息，在命令执行和完成时通知订阅的个人。

Systems Manager是基于代理的，这意味着它不仅限制可以用于Amazon EC2实例。它也可以在非AWS主机上使用，这些主机位于你的场所，在你的数据中心，在另一个云服务提供商，或其他地方。

你不需要管理SSH密钥。

你需要在主机上安装Systems Manager代理，Installing SSM Agent。

通过使用Systems Manager替换后，网络架构如下：

关于如何配置Systems Manager 与VPC建立连接，可以查看： Configuring Access to Systems Manager.