Dọn dẹp AWS Access Key khi ứng phó ISMS: Hành trình chuyển sang xác thực dựa trên Role

Đây là bài viết tổng hợp lại trải nghiệm chuyển sang xác thực dựa trên Role sau khi rà soát các Access Key tích tụ trong tài khoản AWS trong quá trình ứng phó với đợt kiểm tra hậu kỳ ISMS.

Bối cảnh áp dụng

• Khi xem IAM console, thấy Access Key đã rải rác ở nhiều nơi (CI/CD, script triển khai, phát triển cục bộ, v.v.) và rất khó lần ra chúng đang được dùng ở đâu, theo cách nào
• Access Key được duy trì mà không có thời hạn hết hạn, và nếu bị đánh cắp thì các quyền đã cấp sẽ bị lộ nguyên vẹn, nên rủi ro khá lớn
• AWS cũng khuyến nghị dùng thông tin xác thực tạm thời (Role/STS) thay vì thông tin xác thực dài hạn (Access Key)

Vấn đề

• Vì key bị sao chép và dùng ở nhiều nơi, rất khó trả lời câu hỏi “nếu key này bị lộ thì sẽ ảnh hưởng đến đâu?”
• Muốn rotation thì phải thay đổi đồng thời các cấu hình đang phân tán, và do nhiều quyền phục vụ nhiều mục đích bị dồn vào một IAM User nên khó áp dụng nguyên tắc đặc quyền tối thiểu
• Khi đó, một IAM User dùng cho CI/CD đang đồng thời nắm các quyền như triển khai ECR/S3/SSM/ECS

Cách chuyển đổi đã áp dụng (tóm tắt)

• Assume Role: cách tạm thời mượn quyền của một Role khác vào đúng thời điểm cần thiết
• OIDC Web Identity: cách cấp Role bằng ID của hệ thống bên ngoài như GitHub Actions/EKS (=IRSA)
• Instance Profile: cách gắn trực tiếp Role vào EC2/Lambda để tự động có quyền

Quá trình chuyển đổi thực tế

• Bước 1: tách quyền của IAM User đang gắn policy phạm vi rộng thành các Role theo từng mục đích (push/pull ECR, triển khai ECS, cache S3, v.v.)
• Bước 2: áp dụng OIDC cho GitHub Actions (đăng ký Identity Provider → giới hạn phạm vi repo bằng điều kiện trong Trust Policy → dùng configure-aws-credentials trong workflow)

Hiệu quả

• Loại bỏ Access Key khỏi code/secret; vì dùng token tạm thời nên ngay cả khi bị lộ, phạm vi thiệt hại cũng bị giới hạn theo thời hạn hết hạn
• Không còn gánh nặng rotation key, và việc theo dõi quyền theo từng workflow/công việc trở nên rõ ràng hơn

Điểm cần lưu ý

• Không đặt điều kiện trong Trust Policy quá rộng; hãy giới hạn ở phạm vi tối thiểu (org/repo, nếu có thể thì cả branch)
• Đừng xóa Access Key hiện có ngay lập tức; sau khi chuyển đổi hãy vô hiệu hóa một thời gian, kiểm chứng ổn định rồi mới xóa