FDE PulseViệc làm FDE đang mở 642Mới trong 7 ngày 46Công ty đang tuyển 98Nhận làm từ xa 24%Lương trung vị (Mỹ) $204kTuyển nhiều nhất Databricks 122
EN

Tờ báo của nghề Forward Deployed Engineer

Công cụ

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.

Ảnh phòng máy chủ hoặc kỹ sư làm việc với laptop hiển thị mã, gợi việc truy cập hạ tầng từ xa một cách an toàn.
Ảnh: Tyler / Unsplash
Chia sẻLinkedInFacebookX

Tóm tắt nhanh

  • Session Manager cho phép đóng cổng SSH và PowerShell inbound, bỏ bastion và SSH key; quyền truy cập do IAM policy quyết định.
  • SSH, SCP và port forwarding chạy được qua tunnel, nhưng Session Manager không ghi log nội dung của các phiên này.
  • CloudTrail vẫn ghi các lệnh gọi API của phiên; shell tương tác thì có thể đẩy log sang S3 hoặc CloudWatch Logs.
Bảng so sánh ba cách vào máy qua AWS Session Manager: shell tương tác, tunnel SSH/SCP và port forwarding. Cả ba đều giữ cổng 22 đóng và đều được CloudTrail ghi lại việc mở phiên. Chỉ shell tương tác ghi được các lệnh bên trong phiên; tunnel SSH và port forwarding thì không.
Cả ba cách đều không cần mở cổng inbound, nhưng CloudTrail chỉ cho biết ai mở phiên tới máy nào và lúc nào. Nếu khách cần biết từng lệnh đã chạy, hãy dùng shell tương tác và bật log. Nguồn: tài liệu AWS Systems Manager.

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.

{
  "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 <instance-id> 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:

#!/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.

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.

Bài này có hữu ích không?

Dùng cùng trợ lý AIHỏi Claude ↗Hỏi ChatGPT ↗
6 nguồn
Đọc tiếp trên lộ trình · Chặng 5: Triển khaiMicrosoft Presidio: che PII trước khi gọi LLM, và vì sao chính tài liệu của nó không hứa bắt hếtThư viện mã nguồn mở này cho bạn một lớp lọc dữ liệu cá nhân đặt trước model, nhưng mặc định nó chỉ có mô hình tiếng Anh và tự nhận không bắt được hết.