# AWS Session Manager: vào máy chủ của khách hàng mà không mở cổng 22

> Không mở cổng 22, không dựng bastion, quyền vào máy nằm trọn trong IAM policy, nhưng tunnel SSH qua Session Manager không ghi lại nội dung phiên, và khách cần biết điều đó trước khi ký duyệt.

Bản gốc: https://fdetimes.net/vi/cong-cu/aws-systems-manager-session-manager-vao-may-khach-khong-ssh/

Tuần đầu ở một khách hàng mới, rất hay có một cuộc họp kiểu này. Bạn cần vào máy chủ để đọc log và sửa một service đang lỗi. Đội bảo mật trả lời rằng cổng 22 sẽ không mở, và cũng không ai dựng bastion riêng cho bạn.

Gặp tình huống đó, nhiều kỹ sư chọn ngồi chờ ticket hoặc nhờ người của khách gõ hộ từng lệnh. Nếu hạ tầng nằm trên AWS, bạn còn một lựa chọn tốt hơn. Session Manager, một công cụ thuộc AWS Systems Manager, cho bạn vào máy mà cổng inbound vẫn đóng, không có bastion và không ai phải giữ SSH key.

Với một FDE, công cụ này giải quyết hai việc. Bạn vào được hệ thống thật nhanh hơn. Đội bảo mật cũng có một mô hình truy cập để kiểm tra. Nhưng nó có một giới hạn về audit, và bạn phải biết giới hạn đó trước khi hứa hẹn bất cứ điều gì với khách.

## Vì sao đội bảo mật dễ đồng ý hơn?

Tài liệu của AWS nêu lý do khá thẳng: cổng SSH và remote PowerShell để ngỏ trên máy khiến rủi ro bị chạy lệnh trái phép tăng lên rất nhiều. Session Manager cho phép đóng hẳn các cổng đó. AWS đã nhấn mạnh điểm này ngay khi ra mắt công cụ vào ngày 11/9/2018.

Điều thường thuyết phục được đội bảo mật là IAM: quyền truy cập chỉ do IAM policy quyết định. Admin của khách chọn được người hay nhóm nào dùng Session Manager và họ vào được những máy nào.

Họ cũng có thể cấp quyền có thời hạn, chẳng hạn cho kỹ sư trực on-call. Như vậy, cho bạn vào máy không còn là việc tạo tài khoản Linux hay phát key. Đó là một policy họ tự viết, tự đọc lại và tự thu hồi được.

Về đường truyền, traffic giữa client và máy được mã hóa bằng TLS 1.2. Yêu cầu tạo kết nối được ký bằng SigV4, và có thể thêm một lớp mã hóa nữa bằng KMS key. Nếu khách lo về phần mềm cài trên laptop của bạn, Session Manager plugin là mã nguồn mở trên GitHub theo giấy phép Apache 2.0, nên họ có thể tự đọc mã.

## Một policy đủ hẹp để khách ký duyệt

Thay vì xin "quyền vào AWS", hãy mang tới cuộc họp một bản nháp policy cụ thể. Phác thảo dưới đây chỉ cho phép mở phiên SSH qua Session Manager tới đúng một máy; các giá trị trong ngoặc nhọn là chỗ bạn điền.

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ssm:StartSession",
      "Resource": [
        "arn:aws:ec2:<region>:<account-id>:instance/<instance-id>",
        "arn:aws:ssm:<region>::document/AWS-StartSSHSession"
      ]
    }
  ]
}
```

Đây là điểm khởi đầu để thảo luận, không phải bản cuối. Khi dùng thật, nên xem thêm quyền `ssm:TerminateSession` và `ssm:ResumeSession` trên chính các phiên của người dùng, để phiên đầu tiên không bị kẹt khi cần đóng hay nối lại; hãy đối chiếu với tài liệu IAM của Systems Manager.

Giá trị của bản nháp là đội bảo mật nhìn vào là thấy ngay bạn chạm được tới đâu.

## Một ví dụ nhỏ: giữ nguyên thói quen SSH

Thử hình dung bạn cần chép một file cấu hình lên máy `i-0abc...` rồi xem log của service. Việc đầu tiên là cài AWS CLI và Session Manager plugin trên laptop. Plugin có bản cho Windows, macOS và Linux.

Nếu chỉ cần một shell, `aws ssm start-session --target ` là đủ. Nhưng phần lớn kỹ sư đã quen dùng `ssh`, `scp` và các công cụ đi kèm. Session Manager cho phép tunnel SSH và SCP; tài liệu AWS làm việc này bằng một dòng ProxyCommand gọi `aws ssm start-session` với document `AWS-StartSSHSession`.

Một cách viết tương đương, dễ đọc hơn, là tách lệnh ra một script nhỏ, chẳng hạn `~/bin/ssm-proxy.sh`:

```sh
#!/bin/sh
# $1 = ID của máy, $2 = cổng SSH
exec aws ssm start-session \
  --target "$1" \
  --document-name AWS-StartSSHSession \
  --parameters "portNumber=$2"
```

Rồi trong `~/.ssh/config`:

```
Host i-* mi-*
    ProxyCommand ~/bin/ssm-proxy.sh %h %p
```

Ở đây, `%h` là ID của máy: tiền tố `i-` cho EC2, `mi-` cho máy ngoài EC2. `%p` là cổng. Từ lúc đó, `ssh` và `scp` tới `i-0abc...` đều đi qua Session Manager, còn security group của máy không cần mở thêm cổng nào.

Port forwarding cũng theo cách này: một cổng bên trong máy được đưa về một cổng trên laptop của bạn. Đây là cách hợp lý để xem một database hay một web UI nội bộ của khách mà không phải mở chúng ra ngoài.

Session Manager cũng chạy được với máy không có IP public và với môi trường hybrid. Khi dùng VPC endpoint qua AWS PrivateLink, toàn bộ traffic giữa máy, Systems Manager và EC2 nằm trong mạng của Amazon.

## Giới hạn dễ bỏ sót: tunnel không đồng nghĩa với audit

Đây là chỗ FDE dễ nói quá lời nhất. Tài liệu của AWS ghi rõ: phiên đi qua port forwarding hoặc SSH không được ghi log. Trong hai trường hợp đó, Session Manager không ghi lại những gì bạn gõ bên trong phiên.

Thứ vẫn được ghi lại là các lệnh gọi API. CloudTrail ghi những lệnh tạo phiên đi từ console, AWS CLI và SDK. EventBridge có thể gửi cảnh báo khi có StartSession, ResumeSession hay TerminateSession. Với shell tương tác của Session Manager, log của phiên có thể đẩy sang S3 hoặc CloudWatch Logs.

**Điểm mấu chốt:** Mở được tunnel an toàn không có nghĩa là có audit trail; nói rõ điều đó với khách ngay từ đầu.

Vì vậy, nếu khách yêu cầu biết đúng từng lệnh đã chạy trên máy production, hãy dùng shell tương tác và bật log lên S3 hoặc CloudWatch Logs. Đừng dùng tunnel SSH trong trường hợp này.

Nếu tunnel SSH là lựa chọn duy nhất, hãy nói rõ rằng CloudTrail chỉ cho biết ai đã mở phiên tới máy nào và lúc nào, chứ không cho biết bên trong phiên đã làm gì.

## Hai lỗi hay gặp khi mới dùng

Lỗi phổ biến nhất là hứa "mọi thứ đều có log" rồi lại làm việc qua tunnel SSH. Như phần trên đã nói, hai thứ đó không đi cùng nhau, và khách sẽ phát hiện ra vào đúng lúc tệ nhất: khi cần điều tra một sự cố.

Lỗi còn lại là cài AWS CLI rồi tưởng đã xong. Muốn mở phiên từ dòng lệnh, laptop của bạn còn cần Session Manager plugin riêng. Hãy kiểm tra điều này trước buổi làm việc đầu tiên, đừng để cả phòng ngồi chờ bạn cài đặt.

## Nên học gì trước?

Thứ cần học trước là IAM, chưa phải Session Manager. Hãy tập viết một policy như bản phác thảo ở trên, mở một phiên, rồi đọc sự kiện CloudTrail của chính phiên đó. Sau đó mới tới cấu hình SSH và port forwarding.

Khi viết CV, đừng chỉ ghi "dùng AWS". Hãy viết cụ thể, ví dụ: thiết kế cách vào máy production của khách không cần cổng inbound, dựa trên IAM, kèm cảnh báo khi phiên được mở. Một dòng như vậy cho người tuyển dụng thấy bạn hiểu được mối lo của đội bảo mật.

Trong cuộc họp đầu tiên với khách, câu nên hỏi là "anh chị cần audit tới mức nào?". Câu trả lời sẽ quyết định bạn dùng shell tương tác hay tunnel SSH.

**Thử ngay tuần này:**

- Cài AWS CLI và Session Manager plugin trên laptop, rồi mở thử một phiên bằng aws ssm start-session --target tới một instance trong tài khoản sandbox
- Thêm khối ProxyCommand cho i-* và mi-* vào ~/.ssh/config, sau đó chép một file bằng scp mà không mở cổng 22
- Viết một IAM policy chỉ cho phép mở phiên tới đúng một máy, rồi kiểm tra sự kiện StartSession trong CloudTrail

## Nguồn

- [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html)

- [Introducing AWS Systems Manager Session Manager](https://aws.amazon.com/about-aws/whats-new/2018/09/introducing-aws-systems-manager-session-manager/)

- [Install the Session Manager plugin for the AWS CLI](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-install-plugin.html)

- [aws/session-manager-plugin (GitHub)](https://github.com/aws/session-manager-plugin)

- [Step 8: (Optional) Allow and control permissions for SSH connections through Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started-enable-ssh-connections.html)

- [Logging session activity](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-auditing.html)