基于云服务器 EC2 的云上堡垒机的设计和自动化实现

背景

在很多企业的实际应用场景中，特别是金融类的客户，大部分的应用都是部署在私有子网中，如何能够让客户的开发人员和运维人员从本地的数据中心中安全的访问云上资源，堡垒机是一个很好的选择。传统堡垒机的核心实现原理是基于 SSH 协议的安全连接，通常运用 SSH（Secure Shell）协议实现数据的加密通信。SSH 为安全身份验证和数据加密提供了可靠保障，从而确保了连接的安全性。然而，传统的自建堡垒机在其管理和运维方面面临着多种挑战：

1. 部署与维护复杂性：自建堡垒机的部署和配置往往涉及多个复杂步骤和组件，导致管理和维护的工作量显著增加。

2. 安全性风险：自行管理多个密钥和凭证可能会增加安全漏洞的风险。若密钥管理不当，可能导致未经授权的访问。

亚马逊云科技开发者社区为开发者们提供全球的开发技术资源。这里有技术文档、开发案例、技术专栏、培训视频、活动与竞赛等。帮助中国开发者对接世界最前沿技术，观点，和项目，并将中国优秀开发者或技术推荐给全球云社区。如果你还没有关注/收藏，看到这里请一定不要匆匆划过，点这里让它成为你的技术宝库！

3. 可用性问题：自建堡垒机常常无法实现高可用性和弹性，多用户同时访问时可能出现性能问题，影响用户体验。

4. 扩展困难：随着用户数量和需求的增加，自建堡垒机可能难以灵活扩展，导致资源分配不均。

5. 更新和升级：自建堡垒机需要定期进行更新和升级，以保持安全性和性能，然而这可能会导致业务中断或不稳定情况。

6. 外网暴露：传统堡垒机需要在云上环境中部署一个有外网访问的权限的机器，增加了被攻击的风险。

与传统方式不同，基于 Amazon Systems Manager Session Manager 的堡垒机通过建立双向加密通道，连接客户端和远程节点，并采用 TLS 1.2 进行流量加密和 Sigv4 签名请求。这一方式具备显著优势：

1. 一键式部署：该方案极大简化了堡垒机部署流程，从而减少了部署难度和运维成本。

2. 卓越安全性： Session Manager 提供了加密和身份验证功能，保障连接的安全性。

a. 基于 Amazon Web Services Identity and Access Management (IAM) 角色的最小权限原则，管理员能够通过集中的 IAM 策略管理堡垒机的访问授权。
b. 无需管理堡垒机密钥。
c. 支持云上私有子网部署，无需部署在公有子网中，且无需打开入站端口。
复制代码

3. 高可用性： 通过弹性伸缩功能实现了堡垒机的跨可用区高可用性。

**4. 可扩展性： ** 基于 CPU 利用率的弹性伸缩策略能够自动调整容量，以适应不同流量访问的需求。

**5. 简化管理： ** Systems Manager Session Manager 是一项无需用户自行管理实例的托管服务。无需预先启动实例，也无需将实例直接暴露在公网上，从而降低了管理复杂性。

6. 端口转发与跨平台支持：通过 Session Manager，可在本地客户端进行远程节点端口转发，并实现连接。同时，它对 Linux、Windows、Mac 等多种操作系统平台提供了跨平台访问支持。

7. 全面的日志记录与审计：Session Manager 支持多种方式进行日志记录，涵盖登录时间、命令执行等内容，以确保会话连接活动得到完整记录。这些记录可用于审计和故障排除。

8. 提供监控告警功能：针对堡垒机的性能指标进行监控告警，以便在性能异常时及时收到通知。

基于 Session Manager 的堡垒机为访问管理提供了高效、安全、高可用的解决方案，成为提升操作效率和保障安全性的理想选择。堡垒机作为一种安全措施，允许用户通过中间主机来访问位于私有子网中的实例或资源。它作为一座桥梁，帮助用户在安全的环境下连接到内部资源，同时减少对直接连接的需求，从而降低被攻击的风险。对于企业的安全管理员来说，堡垒机可以增强安全性、简化网络配置、降低网络资源暴露风险、提供审计跟踪，对于开发运维人员来说，他们可以在本地环境中使用熟悉的开发、运维工具，如数据库客户端、浏览器、RDP 等去访问云上私有资源，大大提高生产效率。

本文主要阐述的是基于 Amazon Systems Manager 的 Session Manager 特性和 Amazon EC2 堡垒机的设计和实现。主要内容包括堡垒机的架构设计、安全设计、日志监控设计、高可用弹性设计以及自动化部署设计等，同时针对堡垒机在不同场景中的使用方式和脚本进行举例说明。

云上堡垒机设计

2.1 安全设计

在进行云上堡垒机设计时，安全是第一个需要考虑的要求。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 存储桶，以确保会话和日志的安全性。

2.2  高可用和弹性设计

堡垒机的高可用设计可以确保在发生故障或负载增加时，堡垒机仍然能够保持可用，并继续提供安全的访问控制。

• 堡垒机的高可用性

  • 使用 Auto Scaling Group（ASG）： 配置堡垒机所在的 EC2 实例为一个 Auto Scaling Group。当堡垒机实例的负载增加时，ASG 会根据设置的扩展规则自动增加实例数量，保持高可用性。
  • 设置负载均衡： 当多个堡垒机实例同时运行时，可以使用负载均衡器来分发流量，确保各个实例的负载均衡。负载均衡器还可以在某些实例出现故障时自动将流量路由到其他健康的实例，提高了整体的可用性。

• 定时扩展和缩减

  • 通过 Auto Scaling Group 的定时规则，控制堡垒机的启动和关机时间，从而来节约堡垒机的费用。

2.3 监控告警设计

• Amazon CloudWatch 指标监控： CloudWatch 可以监控 EC2 实例和其他亚马逊云资源的性能指标。可监控实例的 CPU 使用率、内存利用率、磁盘等关键指标。并通过 Amazon SNS 服务设置报警，以便在性能异常时及时收到通知。

2.4  自动化部署设计

2.4.1 堡垒机代码设计

考虑到堡垒机的高可用设计，在其中一台机器宕机的情况下，可以自动、快速的拉起一台新的堡垒机以供使用，我们采取 EC2 launch template 的方式进行堡垒机的构建，以下是 IaC 样例代码：

1.通过弹性伸缩启动模版创建堡垒机的 IaC 代码样例，包含启动模版、弹性伸缩组、弹性规则等。

## 创建Bastion的launch template
resource "aws_launch_template" "bastion_template" {
  name = "bastion_template"
  block_device_mappings {
    device_name = "/dev/xvda"
    ebs {
      volume_size = 8
      encrypted   = true
    }
  }

  iam_instance_profile {
    name = aws_iam_instance_profile.bastion_ec2_profile.id
  }

  image_id                             = data.aws_ami.linux_2023_image.id
  instance_initiated_shutdown_behavior = "terminate"
  instance_type                        = var.bastion_instance_type
  
  monitoring {
    enabled = true
  }

  network_interfaces {
    associate_public_ip_address = false
    device_index                = 0
    security_groups             = [aws_security_group.bastion.id]
    subnet_id                   = element(module.vpc.private_subnets, 0)
    delete_on_termination       = true
  }

  user_data = base64encode(
    templatefile(
      "${path.module}/templates/user_data.sh.tftpl",
      {
        ##传入值到user data中所需要的变量中
      }
    )
  )
}

## 创建Bastion的弹性伸缩组
resource "aws_autoscaling_group" "bastion_asg" {
  launch_template {
    id      = aws_launch_template.bastion_template.id
    version = "$Latest"
  }
  availability_zones        = ["${var.region}a","${var.region}b"]
  name                      = "bastion_daily"
  max_size                  = 1
  min_size                  = 1
  health_check_grace_period = 300
  health_check_type         = "EC2"
  force_delete              = true
  termination_policies      = ["OldestInstance"]

  tag {
    key                 = "Name"
    value               = "bastion"
    propagate_at_launch = true
  }
}

## 创建Bastion的弹性伸缩规则-样例中使用定时规则
resource "aws_autoscaling_schedule" "bastion_scale_down" {
  scheduled_action_name  = "bastion_scale_down"
  min_size               = 0
  max_size               = 0
  desired_capacity       = 0
  recurrence             = "0 20 * * *" # 20:00 UTC +8 时间
  time_zone              = "Asia/Chongqing"
  autoscaling_group_name = aws_autoscaling_group.bastion_asg.name
}

resource "aws_autoscaling_schedule" "bastion_scale_up" {
  scheduled_action_name  = "bastion_scale_up"
  min_size               = 1
  max_size               = 1
  desired_capacity       = 1
  recurrence             = "0 8 * * *" # 8:00 UTC +8 时间
  time_zone              = "Asia/Chongqing"
  autoscaling_group_name = aws_autoscaling_group.bastion_asg.name
}

## 或者基于CPU利用率的弹性伸缩规则（样例）
resource "aws_autoscaling_group" "bation_cpu" {
  name                 = "bastion-cpu-asg"
  launch_configuration = aws_launch_configuration.bastion_template.name
  min_size             = 2
  max_size             = 4
  desired_capacity     = 2
  
  metric_trigger {
    metric_name = "CPUUtilization"
    namespace   = "AWS/EC2"
    statistic   = "Average"
    unit        = "Percent"
    threshold   = 70  # CPU利用率超过70%时扩容
    comparison_operator = "GreaterThanOrEqualToThreshold"
    dimensions = {
      AutoScalingGroupName = aws_autoscaling_group.bastion_cpu.name
    }
  }

  scaling_policy {
    name = "scale-up-policy"
    adjustment_type         = "ChangeInCapacity"
    scaling_adjustment      = 1
    cooldown               = 300  # 冷却时间300s
  }
复制代码

2.定义堡垒机的 EC2 用户数据代码样例

在创建堡垒机时，不仅仅是单独的创建一台 EC2 的实例，还需要针对用于该 EC2 的实例进行安全加固、安装相应的工具、设置对于堡垒机的监控等功能，以下是 IaC 代码中，用于 EC2 实例初始化的用户数据（User Data）样例。

## 安全加固
yum -y update --security

## 仅允许ec2-user访问该目录
mkdir /var/log/bastion
chown ec2-user:ec2-user /var/log/bastion
chmod -R 770 /var/log/bastion
setfacl -Rdm other:0 /var/log/bastion

## Make OpenSSH execute a custom script on logins
echo -e "nForceCommand /usr/bin/bastion/shell" >> /etc/ssh/sshd_config
echo "AllowTcpForwarding yes" >> /etc/ssh/sshd_config
awk '!/X11Forwarding/' /etc/ssh/sshd_config > temp && mv temp /etc/ssh/sshd_config
echo "X11Forwarding no" >> /etc/ssh/sshd_config

sed  -i "s/002/022/g" /etc/profile
umask 022

## SSH命令记录脚本
mkdir /usr/bin/bastion
cat > /usr/bin/bastion/shell > /etc/ssh/sshd_config
echo "PermitEmptyPasswords no" >> /etc/ssh/sshd_config
systemctl start sshd

## 安装CloudWatch Agent，进行系统日志收集及性能指标收集
sudo yum -y install amazon-cloudwatch-agent
sudo yum install -y collectd
cat > /opt/aws/amazon-cloudwatch-agent/etc/config.json  /dev/null 2>&1

## Step 3: 发送生成 SSH public key 到堡垒机中，根据实际情况替换掉命令行中的变量
$ echo -ne "Pushing public key to instance.........r"
$ aws ec2-instance-connect send-ssh-public-key --region $AWS_DEFAULT_REGION 
    --instance-id $instanceId --availability-zone  
    --instance-os-user  
    --ssh-public-key file://temp-key.pub > /dev/null 2>&1

## Step 4: 修改 ~/.ssh/config 配置（仅需要一次配置）
Host test-ssh-bastion
     IdentityFile ~/test/temp-key
     StrictHostKeyChecking no
     UserKnownHostsFile /dev/null
     LogLevel QUIET
     User ec2-user
     ProxyCommand sh -c "aws ssm start-session --target $(aws ec2 describe-instances --no-cli-pager 
        --filters 'Name=tag:Name,Values=bastion_linux' 
        --query 'Reservations[0].Instances[0].InstanceId' --output text) 
     --document-name AWS-StartSSHSession --parameters 'portNumber=%p' --region us-east-1"

## Step 5: 修改完成后，通过 ssh 就可以连接到堡垒机中,如下图所示
$ ssh test-ssh-bastion
复制代码

将以上代码中的 Step1 到 Step3 编写成一个脚本，在每次执行 ssh 之前，先运行该脚本，确保新生成的 SSH Key 有效（通过 send-ssh-public-key 上传到 EC2 上的 Key 有效期只有 60s）。

 图 4-11 启动本地 SSH 访问堡垒机

注意： 如果使用动态生成 SSH Key 的方式，需要先创建“EC2 Instance Connect Endpoint”，同时确保本地电脑上使用的 IAM 角色包含有“ec2-instance-connect:SendSSHPublicKey”的权限。另外，亚马逊云科技中国区暂时不支持该 Endpoint 类型的创建。

通过本地 Session Manager 插件 SSH 进入到堡垒机后，所有的操作都会上传到 S3 桶（S3 桶名：bastion-audit-log-bucket-，路径为：logs/）中做持久化存储。

 图 4-12 S3 中存储的在本地通过 SSH 操作堡垒机的审计日志

除通过 SSH 登录到堡垒机外，SSM 还可以支持 SSH Socks Proxy，如下图在浏览器中设置 Proxy（以 Firefox 为例）：

 图 4-13 Socks Proxy 配置

使用以下代码启动 SSH Socks Proxy：

ssh -f -N -p 2200 -i temp -o "IdentitiesOnly=yes" -D 1080 ec2-user@localhost
复制代码

启动后，就可以通过 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 Systems Manager Session Manager 官方文档

• Amazon 官方博客：New – Port Forwarding Using AWS System Manager Session Manager

  文章来源：
  dev.amazoncloud.cn/column/arti…