3274
背景
在很多企业的实际应用场景中，特别是金融类的客户，大部分的应用都是部署在私有子网中，如何能够让客户的开发人员和运维人员从本地的数据中心中安全的访问云上资源，堡垒机是一个很好的选择。传统堡垒机的核心实现原理是基于SSH协议的安全连接，通常运用SSH（Secure Shell）协议实现数据的加密通信。SSH为安全身份验证和数据加密提供了可靠保障，从而确保了连接的安全性。然而，传统的自建堡垒机在其管理和运维方面面临着多种挑战：
- 部署与维护复杂性：自建堡垒机的部署和配置往往涉及多个复杂步骤和组件，导致管理和维护的工作量显著增加。
- 安全性风险：自行管理多个密钥和凭证可能会增加安全漏洞的风险。若密钥管理不当，可能导致未经授权的访问。
- 可用性问题：自建堡垒机常常无法实现高可用性和弹性，多用户同时访问时可能出现性能问题，影响用户体验。
- 扩展困难：随着用户数量和需求的增加，自建堡垒机可能难以灵活扩展，导致资源分配不均。
- 更新和升级：自建堡垒机需要定期进行更新和升级，以保持安全性和性能，然而这可能会导致业务中断或不稳定情况。
- 外网暴露：传统堡垒机需要在云上环境中部署一个有外网访问的权限的机器，增加了被攻击的风险。
与传统方式不同，基于Amazon Systems Manager Session Manager的堡垒机通过建立双向加密通道，连接客户端和远程节点，并采用TLS 1.2进行流量加密和Sigv4签名请求。这一方式具备显著优势：
- 一键式部署：该方案极大简化了堡垒机部署流程，从而减少了部署难度和运维成本。
- 卓越安全性：Session Manager提供了加密和身份验证功能，保障连接的安全性。
a. 基于AWS Identity and Access Management（IAM）角色的最小权限原则，管理员能够通过集中的IAM策略管理堡垒机的访问授权。
b. 无需管理堡垒机密钥。
c. 支持云上私有子网部署，无需部署在公有子网中，且无需打开入站端口。
- 高可用性：通过弹性伸缩功能实现了堡垒机的跨可用区高可用性。
- 可扩展性：基于CPU利用率的弹性伸缩策略能够自动调整容量，以适应不同流量访问的需求。
- 简化管理：Systems Manager Session Manager是一项无需用户自行管理实例的托管服务。无需预先启动实例，也无需将实例直接暴露在公网上，从而降低了管理复杂性。
- 端口转发与跨平台支持：通过Session Manager，可在本地客户端进行远程节点端口转发，并实现连接。同时，它对Linux、Windows、Mac等多种操作系统平台提供了跨平台访问支持。
- 全面的日志记录与审计：Session Manager支持多种方式进行日志记录，涵盖登录时间、命令执行等内容，以确保会话连接活动得到完整记录。这些记录可用于审计和故障排除。
- 提供监控告警功能：针对堡垒机的性能指标进行监控告警，以便在性能异常时及时收到通知。
基于Session Manager的堡垒机为访问管理提供了高效、安全、高可用的解决方案，成为提升操作效率和保障安全性的理想选择。堡垒机作为一种安全措施，允许用户通过中间主机来访问位于私有子网中的实例或资源。它作为一座桥梁，帮助用户在安全的环境下连接到内部资源，同时减少对直接连接的需求，从而降低被攻击的风险。对于企业的安全管理员来说，堡垒机可以增强安全性、简化网络配置、降低网络资源暴露风险、提供审计跟踪，对于开发运维人员来说，他们可以在本地环境中使用熟悉的开发、运维工具，如数据库客户端、浏览器、RDP等去访问云上私有资源，大大提高生产效率。
本文主要阐述的是基于Amazon Systems Manager的Session Manager特性和Amazon EC2堡垒机的设计和实现。主要内容包括堡垒机的架构设计、安全设计、日志监控设计、高可用弹性设计以及自动化部署设计等，同时针对堡垒机在不同场景中的使用方式和脚本进行举例说明。
云上堡垒机设计
安全设计
在进行云上堡垒机设计时，安全是第一个需要考虑的要求。Session Manager是一种无需通过公网IP或SSH密钥来连接到EC2实例的服务，它通过Systems Manager的控制台或CLI来创建和管理安全的交互式会话。其安全设计主要考虑以下四点：
- IAM权限和访问控制：
Session Manager权限：确保只有授权的用户或角色拥有使用Session Manager的权限。为用户或角色分配适当的IAM策略，限制其对Session Manager的访问，一般情况下，通过与客户已有的AD进行集成，通过分组来控制启动Session Manager的权限。
多因素认证（MFA）：强制启用多因素认证，增加用户身份验证的安全性。
- VPC和子网安全性：
控制对Session Manager的网络访问：设置VPC Endpoints的安全组仅允许来自堡垒机及私有子网中主机的访问，并且设置VPC Endpoints的策略，以限制特定受信任实体才能访问。
- 日志和审计：
监控Session Manager会话：启用CloudTrail以记录Session Manager的API调用活动，以便审计和监控用户对会话的操作；配置Session Manager参数，发送会话日志到Amazon CloudWatch日志组和S3存储桶，确保用户在会话中的所有操作均被记录，CloudWatch日志组中的数据将保存3个月，S3桶中的会话日志将持久存储以满足安全监管和审计需求。同时，通过脚本来实现对本地Session Manager插件SSH登录上的操作进行详细记录，并存储在指定的存储桶中。
- 安全加密：
加密各类堡垒机相关资源：使用Amazon Key Management Service（KMS）对Session Manager的会话进行加密，加密Amazon CloudWatch日志组及S3存储桶，以确保会话和日志的安全性。
高可用和弹性设计
堡垒机的高可用设计可以确保在发生故障或负载增加时，堡垒机仍然能够保持可用，并继续提供安全的访问控制。
- 堡垒机的高可用性
使用Auto Scaling Group（ASG）：配置堡垒机所在的EC2实例为一个Auto Scaling Group。当堡垒机实例的负载增加时，ASG会根据设置的扩展规则自动增加实例数量，保持高可用性。
设置负载均衡：当多个堡垒机实例同时运行时，可以使用负载均衡器来分发流量，确保各个实例的负载均衡。负载均衡器还可以在某些实例出现故障时自动将流量路由到其他健康的实例，提高了整体的可用性。
- 定时扩展和缩减
通过Auto Scaling Group的定时规则，控制堡垒机的启动和关机时间，从而来节约堡垒机的费用。
监控告警设计
Amazon CloudWatch指标监控：CloudWatch可以监控EC2实例和其他亚马逊云资源的性能指标。可监控实例的CPU使用率、内存利用率、磁盘等关键指标。并通过Amazon SNS服务设置报警，以便在性能异常时及时收到通知。
自动化部署设计
堡垒机代码设计
考虑到堡垒机的高可用设计，在其中一台机器宕机的情况下，可以自动、快速的拉起一台新的堡垒机以供使用，我们采取EC2 launch template的方式进行堡垒机的构建，以下是IaC样例代码：
- 通过弹性伸缩启动模版创建堡垒机的IaC代码样例，包含启动模版、弹性伸缩组、弹性规则等。
2.定义堡垒机的EC2用户数据代码样例
在创建堡垒机时，不仅仅是单独的创建一台EC2的实例，还需要针对用于该EC2的实例进行安全加固、安装相应的工具、设置对于堡垒机的监控等功能，以下是IaC代码中，用于EC2实例初始化的用户数据（User Data）样例。
3.设计和创建堡垒机安全组
根据Session Manager安全组的最佳实践，本方案中堡垒机的安全组设计如下：
IaC代码设计样例如下：
Session Manager配置设计
在启用Session Manager时，需要对Session Manager进行相关的配置，如是否开启Session加密，是否将日志存储到CloudWatch Logs或者S3上，是否对日志进行加密，最大的Session时长等。我们通过创建SSM Documents的方式来进行配置，如以下IaC样例代码所示：
堡垒机IAM角色设计
在本设计中，堡垒机的IAM角色主要包含以下权限：
- AmazonSSMManagedInstanceCore
- CloudWatchAgentServerPolicy
- Logs部分权限
- SSM Messages部分权限
- S3部分权限
- KMS部分权限
如需自定义更多Session Manager IAM角色的详细可访问：自定义Session Manager IAM角色
以下是IaC代码样例：
部署堡垒机
本章将介绍如何通过基础设施即代码（Infrastructure as code）的方式一键式构建云上堡垒机，通过Terraform进行相应的IaC代码开发。
堡垒机部署架构图
根据云上堡垒机的设计，我们在堡垒机的部署中，将使用到亚马逊云上的多种服务：如Amazon CloudWatch、Key Management Service（KMS）、Identity and Access Management（IAM）、Systems Manager、Amazon Simply Notification Service（SNS）、Amazon Simple Storage Service（S3）、Amazon PrivateLink、Amazon EC2以及Amazon EC2 Auto Scaling等，以下为部署架构图：
以下对部署中所使用到的主要亚马逊云相关服务的用途进行简单介绍：
- Amazon EC2/Amazon EC2 Auto Scaling：在EC2上进行堡垒机的部署，并通过AutoScaling确保堡垒机的高可用；
- Amazon Simple Storage Service（S3）：用于存放通过Session Manager和SSH登录到堡垒机上所产生的操作日志信息；
- Amazon VPC endpoints：用于堡垒机在没有外网访问的条件下，进行安全的访问如Amazon CloudWatch（Logs/Monitoring）、Amazon S3、Systems Manager、Amazon KMS等服务；
- Amazon CloudWatch：用于存放通过控制台的Session Manager功能访问堡垒机的操作日志存储；
- Amazon KMS：用于加密堡垒机部署过程中的相关服务，如Session加密、CloudWatch logs加密、S3桶加密等；
- Amazon Simply Notification Service：用于接受Bastion Host在CPU/Memory/磁盘超过阈值的时候的告警信息。
需要创建的Endpoints列表：
堡垒机自动化部署
当IaC代码开发完成后，可以将该代码集成在其他资源的CICD pipeline中，也可以通过Terraform命令，直接进行部署。
等到命令执行完成后，登录到亚马逊云科技管理控制台检查相应资源是否按照预期部署完成。
堡垒机使用场景
堡垒机使用前置条件
如果要在本地机器上使用堡垒机，需要满足以下条件：
- 确保亚马逊云上堡垒机已经部署完成，并且处于running状态；
- 确保网络联通性，确认堡垒机能访问私网环境中的RDS数据库、WebServer EC2等；
- 确保你本地使用的IAM角色至少具有以下权限：
- ec2:DescribeInstances
- ssm:StartSession
- ec2-instance-connect:SendSSHPublicKey
- 确保本地环境中正确安装了亚马逊云命令行工具（CLI V2）和Session Manager插件
堡垒机使用场景实操
假设客户在亚马逊云上的私有子网中，部署了一个Web应用，包含Web前端和服务后端以及RDS数据库（以SQL Server为例）。该客户对于安全性的要求非常高，云上VPC环境中没有Internet访问，也没有在本地网络与云上环境之间搭建专线直连（Direct Connect）和VPN。但客户的开发人员和运维人员，要求提供一个安全、高效、可靠的方式从本地的客户端、应用程序、浏览器去访问云上资源，以提高开发、运维效率。下图为堡垒机实操环境的部署示意图：
场景一：通过亚马逊云科技管理控制台/命令行登录堡垒机
在这个场景中，开发人员或者运维人员通过公司AD集成的账号拿到了相应的角色权限，直接登录到亚马逊云的管理控制台，然后通过Session Manager直接连接到堡垒机上进行操作。操作步骤如下：
方式一：直接进入到EC2控制台，选择堡垒机，然后点击“Connect”进行连接
方式二：进入到Systems Manager→Session Manager→Start Session，然后选择堡垒机进行连接
两种方式登录后，进入的界面如下图所示：
或者在本地启动SSM Session Manager的插件，从本地电脑中，直接访问堡垒机：
通过控制台或者本地CLI进入到堡垒机后，所有的操作都会被记录到Amazon CloudWatch Log Group“/aws/sessionmanager”，日志保留时间为3个月，并且还会上传到S3桶（S3桶名：bastion-audit-log-bucket-，路径为：ssm/）中做持久化存储。
场景二：通过堡垒机实现远程主机端口转发
在该场景中，开发人员或者运维人员通过公司AD集成的账号拿到了相应的角色权限，然后在本地启动Session Manager插件来进行远程主机的端口转发，通过这种方式，开发人员或运维人员可以方便的使用本地客户端进行操作云上资源，如访问云上数据库和访问WebServer等。以下命令是启动如何在本地机器上实现远程主机端口转发：
(1)远端数据库端口转发
以在本地访问云上SQLServer数据库为例子，端口号为1433，本地端口号为12345，远程主机DNS为：“bastion-test-db.xxxxx..rds.amazonaws.com”，启动后，如下图所示：
打开本地SQLServer客户端，输入RDS Server端地址和端口：“127.0.0.1,12345”，并输入登录数据库的账号和密码，如下图所示：
点击“Connect”，即可访问云上RDS数据库并进行操作：
(2)远端服务器端口转发
以本地通过浏览器访问Web Server为例，端口号为80，本地端口号为8080，远程主机IP为：“10.99.3.132”，启动后，如下图所示：
通过本地浏览器访问127.0.0.1:8080，可看到能够成功访问到位于私有网络中的WebServer：
场景三：通过本地SSH连接到堡垒机
在开发人员或者运维人员在实际工作中，偶尔会需要通过SSH连接到堡垒机或者远端的主机上进行调试或者运维，并上传相应的文件到堡垒机上。一般情况下，运维人员需要拿到EC2的密钥并确保安全组中包含有22端口及客户端的IP地址的入站规则，然后才能连接到云上服务器上，这种情况不仅增加了密钥管理的难度，同时对于只存在私有网络中的服务器且本地数据中心和云上环境没有互联的场景是一个很大的挑战。通过ec2-instance-connect服务特性并结合Session Manager可以方便的满足客户通过SSH访问云上EC2的情景。
将以上代码中的Step1到Step3编写成一个脚本，在每次执行ssh之前，先运行该脚本，确保新生成的SSH Key有效（通过send-ssh-public-key上传到EC2上的Key有效期只有60s）。
注意：如果使用动态生成SSH Key的方式，需要先创建“EC2 Instance Connect Endpoint”，同时确保本地电脑上使用的IAM角色包含有“ec2-instance-connect:SendSSHPublicKey”的权限。另外，亚马逊云科技中国区暂时不支持该Endpoint类型的创建。
通过本地Session Manager插件SSH进入到堡垒机后，所有的操作都会上传到S3桶（S3桶名：bastion-audit-log-bucket-，路径为：logs/）中做持久化存储。
除通过SSH登录到堡垒机外，SSM还可以支持SSH Socks Proxy，如下图在浏览器中设置Proxy（以Firefox为例）：
使用以下代码启动 SSH Socks Proxy：
启动后，就可以通过Socks Proxy访问内网的WebServer。
未来架构演进
本方案中堡垒机是根据最常用的功能，如端口转发、SSH访问来设计的，但在一些特定的场景中，还需要设计更多复杂的堡垒机方案，如：Windows类型的堡垒机支持、如何使用IAM角色对堡垒机权限进行更精细化的管理等，这些都是未来本方案演进和增强的一个方向。目前我们方案中，创建的堡垒机类型只有一种，任何拥有启动Session Manager的IAM用户/角色都可以去访问它并进行操作，但在一些场景下，客户需要对于不同的角色使用不同的堡垒机：如角色A仅可以访问堡垒机A，并通过该堡垒机上赋予的IAM权限进行相应的操作；角色B仅可以访问堡垒机B，通过该堡垒机上赋予的IAM权限进行相应的操作。不同的用户角色和客户自有的AD域控进行集成，可以灵活的进行更精细化的权限控制。
总结
本文主要介绍了基于Amazon Systems Manager Session Manager的堡垒机的设计和实现，并通过IaC自动化方式构建和部署云上堡垒机，同时基于堡垒机的使用场景进行了举例，介绍了不同场景下堡垒机的使用方法和步骤。该堡垒机方案已经集成到Cloud Foundations快速启动包服务中，为企业用户提供更便捷的部署方式。
在安全方面做的同样出色的亚马逊云科技Amazon Lightsail和亚马逊云科技Amazon CodeWhisperer也非常实用。
亚马逊云科技Amazon Lightsail可以在Amazon EC2上拓展和迁移，其安全性背靠亚马逊云科技。亚马逊云科技Amazon CodeWhisperer可以对现有的代码进行实时的检测，给予一定的建议，所以构建应用程序时更加的安全。对于企业或开发者，亚马逊云科技Amazon Lightsail和亚马逊云科技Amazon CodeWhisperer的安全性对工作构建、架构设计等全套工作流都非常重要。
下载ECAD模型
