使用Amazon EC2 Systems Manager取代堡垒机
通常情况下,堡垒机(也称为“跳转机”)是在系统中访问私有主机的一个最佳实践。例如,您的系统可能包含一个不希望被公开访问的应用服务器,当需要在这台服务器上进行产品的更新或系统补丁程序的管理时,您通常会登录到堡垒机,然后从那里访问(即“跳转到”)应用服务器。
本文将向您介绍使用Amazon EC2 Systems Manager替换您的堡垒机,实现在服务器上运行命令的同时缩小系统攻击平面并获取更好的可见性。
堡垒机方案
堡垒机最好仅向特定的IP地址范围开放,这个地址范围通常可设定为您单位的企业网络。使用堡垒机的好处是,任何对内部服务器的访问都被限定到一种方式:通过单个或一组堡垒机。为了获取进一步的隔离,堡垒机通常被安放在单独的VPC中。
这种设计方案如下图所示:
应用服务器运行在与管理VPC对等相连的一个VPC的私有子网中。 应用服务器设定了一个安全组规则,其仅允许来自管理VPC中堡垒机所在安全组的22端口访问(本文的示例仅针对端口22和SSH访问。Windows用户可将其相应的替换为端口3389和RDP访问)。同样,堡垒机也设定了一个安全组规则,其仅允许来自公司网络IP地址空间的22端口访问。
由于应用服务器运行在私有子网中,所以它只能通过VPC公共子网中的NAT网关来建立出站公网连接。
假设您希望查看应用程序服务器的网络接口,您需要执行以下步骤:
- 将应用服务器的私钥安装在堡垒机上。
- 从可信网络(如公司网络)发起,在堡垒机上建立SSH会话。
- 从堡垒机发起,建立SSH会话到应用服务器。
- 运行“ifconfig”命令。
- 如需保存命令的结果,您可以复制和粘贴命令的输出,或者将输出重定向到文件。
这个方案中的安全措施限制了对应用服务器和堡垒机的访问,但堡垒机模式存在一些缺点:
- 像任何基础设施服务器一样,堡垒机必须进行管理和维护。
- 运行时会产生成本。
- 允许堡垒机访问的每个安全组都需要设置一个安全组入口规则,即SSH(用于Linux)的22端口或RDP的3389端口(用于Windows服务器)。
- 堡垒机和应用服务器的RSA密钥需要进行管理、保护和轮换。
- SSH操作无缺省日志记录。
替代方案
Systems Manager允许您在被管理的服务器上远程执行命令,而不使用堡垒机(此功能称为EC2 Run Command)。安装于服务器上的代理程序会自动轮询Systems Manager以确定是否有命令在等待执行。
此方案具备以下优点:
- 使用AWS托管服务,这意味着Systems Manager组件具备高可用性。
- Systems Manager通过IAM策略设定是否允许用户或角色远程执行命令。
- Systems Manager代理程序需要IAM角色和策略才能允许它们调用Systems Manager服务。
- Systems Manager不可更改的记录每个执行的命令,从而提供了可审计的命令历史,包括:
o 执行命令的内容
o 执行命令的主体
o 执行命令的时间
o 命令的输出摘要
- 当AWS CloudTrail在当前区域中启用时,CloudTrail会记录每个事件,并写入Amazon CloudWatch Logs。
- 使用CloudTrail和CloudWatch规则,您可以将Systems Manager事件用作自动响应的触发器,例如Amazon SNS通知或AWS Lambda函数调用。
- Systems Manager可以选择将命令历史记录和每个命令的全部输出存储在Amazon S3中。
- Systems Manager可以选择发布消息到SNS主题,从而在命令开始执行时和完成时通知订阅者。
- Systems Manager是基于代理程序的,这意味着它不限于管理Amazon EC2实例。它还可以管理运行在自有数据中心或者另一个云服务提供商的非AWS服务器上。
- 无需管理SSH密钥。
Systems Manager本身没有成本,但是您需要支付Systems Manager所管理的资源(如EC2实例、SNS消息和S3存储等)的成本。
Systems Manager代理程序
Systems Manager代理是运行在被管理的服务器上的开源可执行程序,支持Linux和Windows操作系统(请参见支持的详细操作系统版本列表)。
Systems Manager代理通过IAM角色与Systems Manager进行通信。这个角色必须具有足够权限与Systems Manager及其辅助服务进行交互。IAM已经提供了一个名为AmazonEC2RoleforSSM的托管策略,为您预先定义了这些权限:允许代理程序获取并回复Systems Manager消息、发布CloudWatch指标、并将日志文件写入S3。
Systems Manager代理通过HTTPS协议与Systems Manager通信,这意味着服务器和Systems Manager服务之间的通信是被加密的,而且安全组也不需要特殊的出口规则。
理想情况下,您可以在实例引导时安装代理程序。您可以将其安装在已经运行的EC2实例或非AWS的服务器上。例如,您可以通过EC2实例的user data在系统引导时使用yum安装Systems Manager代理:
#!/bin/bash
cd /tmp
curl https://amazon-ssm-region.s3.amazonaws.com/latest/linux_amd64/amazon-ssm-agent.rpm -o amazon-ssm-agent.rpm
yum install -y amazon-ssm-agent.rpm
关于安装Systems Manager代理的更多信息,请参考以下链接:Installing SSM Agent.
优化后的系统架构
现在您已了解了Systems Manager的众多优点,下面我们看一下如何据此优化您的系统架构。
如下图所示,Systems Manager消除了系统对堡垒机的需求,从而简化了系统架构。 用户不再直接与应用服务器进行交互,Systems Manager成为了执行命令的代理。
在此设计中,Systems Manager代理程序驻留在应用服务器上,使其成为 “受管实例”——这意味着它可以从Systems Manager接收命令。 要执行一个命令,只需在Systems Manager中创建一个命令请求,并派发到该实例或一组实例上运行。
创建命令请求时,您可以选择一个用于存储命令执行结果的S3存储桶,和用于发送执行通知的SNS主题。 您还可以创建通过Systems Manager事件触发的CloudWatch事件。
操作演示
您可以使用下面的【Launch Stack】链接来启动一个AWS CloudFormation栈,后者将创建上述架构,然后运行命令并在Systems Manager控制台中查看结果。最后,您可以销毁整个CloudFormation栈。
注:该链接会在北弗吉尼亚州区域启动相关资源,并产生相应的成本。SSM 只在如下区域可应用。
1.选择Launch Stack打开CloudFormation控制台(请确保您已经使用您的AWS账户登录)并启动CloudFormation模板。选择Next。
2.对于Stack name,请使用缺省的ssm-demo或输入自定义名称。 对于通知电子邮件,请输入您的电子邮件地址,以在Systems Manager执行操作时通知您。CloudFormation模板启动后,您将收到一个订阅确认邮件,您必须确认才能收到后续的通知。选择Next 。
3.在Review 屏幕上,确认允许CloudFormation创建IAM角色。选择Create。
4.要查看栈的创建进度,请选择Refresh,然后选择ssm-demo栈以查看启动过程。
5.当栈成功启动时,状态会从CREATE_IN_PROGRESS更改为CREATE_COMPLETE 。 要查看本文后面需要使用的输出值,请选择Outputs.
这个CloudFormation模板创建的资源将在本文的后面中使用。您应该看到下表中列出的值。
Output名称 | 示例值 | 用途 |
S3Bucket | S3Bucket ssm-output-history -account-id – 区域 | S3桶用于存储命令的输出 |
ApplicationHostInstance | id-instance-id | 用于执行命令的EC2实例 |
SnsTopicArn | arn:aws:sns: region : account-id :SsmNotificationTopic | 用于发送命令执行通知的SNS主题 |
RoleArn | arn:aws:iam :: account-id :role / SsmNotificationRole- region | 用于向SNS发送通知的角色 |
Systems Manager演示
在本节中,您将使用Systems Manager发出与上文堡垒机方案中相同的“ifconfig”命令来查看应用服务器的网络接口配置。
首先,您需要指定要在其上执行命令的实例。在Systems Manager执行命令之后,它会报告执行状态,显示输出,并将输出的历史存储在S3桶中,并向您发送一封电子邮件通知。
Systems Manager代理以root权限运行,管理员在授予用户执行Systems Manager命令的权限时应注意这一点。
要使用Systems Manager,请按照下列步骤操作:
1.登录到您的AWS帐户并跳转到EC2控制台
2.在左侧导航窗格的SYSTEMS MANAGER 下 ,选择Managed Instances
注意:如果您看到“欢迎使用EC2系统管理器 ”的界面,而非受管实例列表,请确保您的系统已满足以下条件:
- 您正在查看的EC2控制台与您启动CloudFormation模板的区域相同
- 至少有一个实例正在运行Systems Manager代理
- 运行Systems Manager代理的实例具有关联的实例角色,并具有允许Systems Manager操作的策略
- 实例已完成初始化(通常只有几分钟)
3.选择本文前面CloudFormation模板创建的实例,然后选择 Run a command.4.在Run a command屏幕上,向下滚动命令文档列表并选择AWS-RunShellScript,平台类型是Linux。如果您使用Windows服务器,请选择AWS-RunPowerShellScript。本文不会涉及命令文档列表中的其他命令,但您可以在工作中根据实际用途选择使用其他命令文档。
5.确保选择了前文CloudFormation模板创建的EC2实例。
6.在Commands输入框中输入以下命令:Bashifconfig
这会发出一个命令来查看主机的网络接口配置。 您可以在这里输入任何有效的bash命令(对于Linux),例如:安装补丁程序,执行应用程序,或更新配置文件等。
7.输入以下值,然后选择Run:
- 对于S3存储桶,请输入上文CloudFormation模板创建的存储桶名称(将S3前缀值留空)。
- 对于角色ARN,输入从CloudFormation模板创建的ARN。
- 对于SNS主题ARN,输入从CloudFormation模板创建的ARN。
- 对于Notify me on,选择全部。
- 对于Notify me for,选择命令。
- 所有其他字段采用默认值。
8.在你启动这个要求之后, 选择 View Managed Instances.
9.如需查看命令历史,在 SYSTEMS MANAGER SERVICES,选择 Run Command.
10.要在Systems Manager控制台上查看命令的简要输出,请选择 Output, 然后再选择View Output.
对于较长的输出,您可以在先前指定的S3存储桶中查看完整的命令输出。此外,您应该在几分钟内收到一封电子邮件,通知您Systems Manager的命令已执行完成。
注意:如果您没有收到电子邮件通知,请确保您在启动CloudFormation栈时收到的SNS主题确认邮件中,点击链接确认接收SNS通知。
截至目前,您已经在应用服务器上成功执行了一个命令,而没有使用堡垒机或直接访问服务器。您可以审核命令的执行,并使用现有的IAM框架来控制对服务器的访问,而无需管理专用的RSA密钥。有关使用IAM框架控制Systems Manager的权限的详细信息,请参阅Configuring Access to Systems Manager。
要清理CloudFormation模板创建的资源,请确保删除CloudFormation栈。如果您使用Systems Manager时将执行日志存储在存储桶中,您在删除栈之前必须手动删除存储桶及其内容。
下一步
大多数AWS服务都包含强大的API让您实现服务交互的自动化。使用控制台是学习和理解远程命令执行过程的好方法,但自动化这一能力提供了一种可靠和规范的方式来管理用户对此功能的使用。
例如,许多组织都依靠人员的轮值来支持生产环境。由于Systems Manager支持IAM集成,您可以根据人员上岗的特定时间段来自动授予或撤消Systems Manager调用权限。
在上文的示例中,您在控制台中执行了一个随意的命令。实际工作中,您将执行存储在具备访问控制的源代码库中的脚本,并可将此功能集成到现有的运维工作流程中,实现请求的跟踪、审批或拒绝。另外,使用AWS CLI、AWS API和AWS SDK,您还可以实现Systems Manager的全程自动化。
更多Systems Manager的特性
远程命令执行只是Systems Manager的一个功能。 其他功能包括:自动补丁管理,服务器软件清单,AMI自动化和参数库等。更多详细信息,请参阅Amazon EC2 Systems Manager产品详细信息页面。
总结
本文介绍了如何在EC2实例上远程执行命令,同时减少系统的攻击平面并简化系统的架构。您还可以使用AWS的IAM、日志和警报等服务帮助您获取服务器上所执行命令的详细信息。
您可能会遇到此解决方案无法满足的SSH或RDP的用例,例如SSH隧道或依赖于SSH的专有软件。希望这篇文章为您提供了关于如何访问和管理服务器的新思路。