在云环境中，长期以来用于连接EC2实例的方式是堡垒机（Bastion Host）。
管理员首先通过SSH连接到堡垒机，然后再连接到内部私有子网中的服务器。这种结构虽然简单且熟悉，但随着运营规模的扩大，管理负担和安全风险也随之增加。
最近，在AWS环境中，堡垒机的使用正在减少或被淘汰，取而代之的是广泛使用AWS Systems Manager的Session Manager来连接EC2实例。
堡垒机方式的局限性
堡垒机充当从外部进入内部服务器的网关。然而，这种结构存在几个问题。
首先，堡垒机本身成为攻击面。
为了外部连接，需要开放SSH 22端口或RDP 3389端口，如果该服务器被入侵，内部网络的访问路径可能会暴露。
其次，需要进行SSH Key管理。
持续产生诸如为每个用户颁发、回收、应对丢失以及删除离职人员密钥等管理任务。
第三，连接历史追踪困难。
虽然可以部分确认谁在何时连接了哪个服务器，但要一致地保留命令级别的审计日志，需要单独配置。
第四，产生运营成本和管理负担。
堡垒机最终也是EC2实例，因此需要进行补丁更新、安全配置、监控和故障响应。
什么是Session Manager？
AWS Systems Manager Session Manager是一种托管式连接功能，允许您无需SSH Key即可连接到EC2实例。
用户通过AWS控制台、AWS CLI或SDK启动Session Manager会话。实例必须安装SSM Agent，并且能够与AWS Systems Manager端点通信。
连接流程如下：
사용자
↓
AWS IAM / AWS SSO 인증
↓
AWS Systems Manager Session Manager
↓
SSM Agent
↓
Private EC2 Instance核心是用户不直接通过SSH连接到EC2。
这意味着EC2安全组中无需开放22端口。
Session Manager替代堡垒机的原因
使用Session Manager，即使没有堡垒机，也可以连接到私有子网中的EC2实例。
传统的堡垒机结构如下：
관리자 PC
↓ SSH
Bastion Host - Public Subnet
↓ SSH
Private EC2 - Private SubnetSession Manager结构如下：
관리자 PC
↓ AWS 인증
Session Manager
↓ SSM Agent
Private EC2 - Private Subnet通过这种方式，无需在公共子网中放置堡垒机。
私有EC2实例无需分配公共IP，也无需开放SSH 22端口。
最终，连接安全的重心从基于网络的访问控制转向基于IAM的访问控制。
安全方面的优点
1. 可以关闭入站端口
使用Session Manager，您无需在EC2实例上开放SSH 22端口或RDP 3389端口。
安全组示例可以简化如下：
Inbound:
없음
Outbound:
HTTPS 443 허용当然，如果是应用服务器，则需要单独允许ALB、NLB、内部服务通信等所需的端口。
但是，用于操作员连接的SSH端口可以移除。
2. 减少SSH Key管理
Session Manager的默认连接不使用SSH Key。
连接权限由IAM策略控制。
例如，可以设置运营团队A只能连接开发服务器，而安全团队只能以只读目的连接运营服务器。
权限回收也可以通过移除IAM权限来处理，而不是删除SSH Key。
3. 支持基于CloudTrail的审计
Session Manager连接会记录为AWS API调用。
您可以在CloudTrail中查看谁在何时启动了哪个实例的会话。
此外，根据配置，会话日志可以保存到S3或CloudWatch Logs。
在运营环境中，建议配置如下审计体系：
Session Manager 접속
→ CloudTrail 기록
→ CloudWatch Logs 또는 S3 저장
→ EventBridge로 접속 이벤트 탐지
→ SNS 또는 Slack 알림4. 适用于以私有子网为中心的架构
Session Manager也适用于私有子网中的EC2实例。
实例无需直接访问互联网，通过配置VPC Endpoint，可以通过AWS PrivateLink与Systems Manager通信。
要在私有子网中稳定使用Session Manager，通常需要配置以下VPC Endpoint：
com.amazonaws.<region>.ssm
com.amazonaws.<region>.ssmmessages
com.amazonaws.<region>.ec2messages如果将会话日志保存到CloudWatch Logs或S3，则还需要考虑相关的Endpoint。
配置所需要素
要使用Session Manager，主要需要四个要素。
1. EC2 IAM角色
EC2实例需要一个能够与Systems Manager通信的IAM角色。
通常，会附加AWS托管策略`AmazonSSMManagedInstanceCore`。
策略附加示例结构如下：
EC2 Instance
→ IAM Role
→ AmazonSSMManagedInstanceCore2. SSM Agent
EC2内部必须安装SSM Agent。
Amazon Linux 2、Amazon Linux 2023、部分Ubuntu AMI和Windows Server AMI通常默认安装。
但在运营环境中，建议保持SSM Agent版本最新。
检查命令如下：
sudo systemctl status amazon-ssm-agent如果未运行，可以按如下方式启动：
sudo systemctl enable amazon-ssm-agent
sudo systemctl start amazon-ssm-agent3. 网络路径
实例必须能够通过HTTPS 443与Systems Manager端点通信。
如果存在互联网路径，可以通过NAT Gateway进行通信。
如果想移除互联网路径，则配置VPC Endpoint。
在安全性重要的运营环境中，基于VPC Endpoint的配置比NAT Gateway更简洁。
4. 用户IAM权限
用户必须拥有启动Session Manager会话的权限。
权限示例如下：
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession",
"ssm:TerminateSession",
"ssm:ResumeSession"
],
"Resource": [
"arn:aws:ec2:ap-northeast-2:123456789012:instance/i-xxxxxxxxxxxxxxxxx",
"arn:aws:ssm:ap-northeast-2:123456789012:document/SSM-SessionManagerRunShell"
]
}
]
}在运营环境中，建议基于实例标签进行控制。
例如，可以只允许开发人员连接`Environment=Dev`的实例，或者只允许运营组连接`Environment=Prod`的实例。
连接方法
从AWS CLI连接Session Manager的基本命令如下：
aws ssm start-session
--target i-xxxxxxxxxxxxxxxxx连接后，可以像普通Shell一样执行命令。
whoami
hostname
ip addr在EC2控制台中，也可以选择实例，然后从“连接”菜单中选择Session Manager进行连接。
何时需要像SSH一样使用
Session Manager默认是不使用SSH进行连接的方式。
但是，现有工具可能基于SSH运行。
例如，SCP、rsync、Ansible、IDE Remote SSH等工具可能需要SSH协议。
在这种情况下，Session Manager可以作为SSH隧道使用。
本地SSH配置示例如下：
Host i-* mi-*
ProxyCommand sh -c "aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"之后可以按如下方式连接：
ssh ec2-user@i-xxxxxxxxxxxxxxxxx但是，由于这种方式是Session Manager隧道SSH流量的结构，因此在命令级别的会话日志记录方面存在限制。
在审计日志重要的运营环境中，建议优先考虑默认的Session Manager Shell连接和日志配置。
端口转发的利用
Session Manager也支持端口转发。
例如，可以将私有子网中EC2的8080端口连接到本地PC的8080端口。
aws ssm start-session
--target i-xxxxxxxxxxxxxxxxx
--document-name AWS-StartPortForwardingSession
--parameters '{"portNumber":["8080"],"localPortNumber":["8080"]}'之后，可以通过本地浏览器访问以下地址：
http://localhost:8080这种方式对于内部管理页面、临时调试、访问私有RDS、内部API检查等非常有用。
堡垒机与Session Manager比较
| 类别 | 堡垒机 | Session Manager |
| 连接方式 | SSH/RDP 直接连接 | 基于AWS API的会话 |
| 公共IP | 通常需要 | 不需要 |
| 入站端口 | 需要22/3389 | 不需要 |
| SSH Key管理 | 需要 | 默认连接不需要 |
| 访问控制 | 安全组、密钥、操作系统账户 | IAM策略 |
| 审计日志 | 需要单独配置 | CloudTrail、S3、CloudWatch Logs集成 |
| 运营负担 | 需要EC2补丁/运营 | 以托管服务为中心 |
| 私有子网访问 | 通过堡垒机 | 可直接访问 |
| 成本 | 产生堡垒机EC2成本 | 基本使用成本较低，日志/VPC Endpoint成本需另行考虑 |
运营环境推荐配置
在运营环境中，推荐以下配置：
1. EC2는 Private Subnet에 배치
2. EC2에는 Public IP 미부여
3. 보안 그룹에서 SSH/RDP Inbound 제거
4. EC2 IAM Role에 AmazonSSMManagedInstanceCore 연결
5. SSM Agent 최신 버전 유지
6. VPC Endpoint 구성
- ssm
- ssmmessages
- ec2messages
7. Session Manager 로그를 CloudWatch Logs 또는 S3에 저장
8. CloudTrail로 StartSession, TerminateSession 이벤트 추적
9. IAM Identity Center 또는 IAM Role 기반으로 사용자 접근 제어
10. 운영 서버 접속은 태그 기반 IAM 정책으로 제한注意事项
虽然Session Manager在很多情况下可以完全替代堡垒机，但这并不意味着在所有情况下都不需要堡垒机。
例如，对于非常特殊的网络设备访问、基于传统SSH的自动化、以及具有严格网络隔离策略的环境，可能需要单独的连接结构。
此外，即使引入Session Manager，如果IAM权限设置过宽，仍然存在风险。
应避免以下策略：
{
"Effect": "Allow",
"Action": "ssm:StartSession",
"Resource": "*"
}在运营环境中，应遵循最小权限原则，限制只允许访问特定实例、特定标签或特定SSM文档。
结论
AWS Systems Manager Session Manager是替代堡垒机非常合适的功能。
最大的优点是，为了操作员连接，无需在EC2上开放SSH端口。
它还减少了SSH Key的管理负担，并可以通过IAM集中控制访问权限。
如果说传统的堡垒机方式是“在网络上打开一扇门并进行管理的方式”，那么Session Manager更接近于“通过AWS认证和权限，在需要时才打开会话的方式”。
因此，在AWS运营环境中，对于新系统，建议优先考虑基于Session Manager的连接结构，而不是默认使用堡垒机。
发表回复