Tự động hóa bảo mật AWS: Giảm thiểu rủi ro lộ lọt khóa truy cập IAM
Amazon Web Services (AWS) đã phát triển khả năng phản ứng nhanh chóng, chuyển từ giai đoạn phát hiện sang kiểm soát trong vòng vài giây khi một khóa truy cập Identity and Access Management (IAM) bị lộ trên kho lưu trữ mã nguồn công khai GitHub. Khả năng này giúp giảm thiểu đáng kể cửa sổ cơ hội cho các hành vi lạm dụng.
Trong một bài thử nghiệm được Unit 42 thực hiện, AWS đã gắn chính sách quản lý AWSCompromisedKeyQuarantineV3 cho người dùng IAM bị ảnh hưởng chỉ 10 giây sau khi các nhà nghiên cứu công bố thông tin đăng nhập bị lộ. Điều này cho thấy sự hiệu quả của hệ thống tự động hóa trong việc bảo vệ tài khoản.
Lỗ hổng CVE và các mối đe dọa từ khóa truy cập IAM
Các khóa truy cập IAM tồn tại lâu dài luôn là một trong những vector truy cập ban đầu hấp dẫn nhất. Chúng cung cấp quyền truy cập theo chương trình mà không yêu cầu xác thực tương tác. Lỗi này xảy ra khi các nhà phát triển vô tình đưa các khóa này vào mã nguồn, tệp cấu hình hoặc các tệp môi trường có thể truy cập công khai.
GitHub secret scanning, một tính năng tìm kiếm các kho lưu trữ công khai và các bề mặt công khai khác cho các mẫu thông tin đăng nhập đã nhận dạng, đóng vai trò quan trọng. Thông qua tích hợp đối tác, GitHub báo cáo các bí mật AWS bị phát hiện trực tiếp cho AWS, cho phép nhà cung cấp nền tảng phản ứng kịp thời.
Diễn biến của một vụ lộ lọt thông tin
Theo nghiên cứu được công bố bởi Unit 42, bài thử nghiệm vào ngày 19 tháng 12 năm 2025 đã cung cấp cái nhìn chi tiết về quy trình tự động hóa này. Các nhà nghiên cứu đã đẩy một khóa truy cập và một khóa bí mật lên một kho lưu trữ công khai lúc 18:50:05 UTC, ngay cả sau khi tính năng bảo vệ của GitHub đã cảnh báo về cả hai giá trị này.
Vào lúc 18:50:15, CloudTrail đã ghi lại một sự kiện AttachUserPolicy, cho thấy AWSCompromisedKeyQuarantineV3 đã được đính kèm vào người dùng có tên TestUser. Một giây sau, GitHub đã gửi một cảnh báo qua email. Lúc 18:50:17, AWS Health hiển thị thông báo “Risk IAM quarantine”. AWS gửi email lúc 18:50:26 và một trường hợp hỗ trợ (Support case) xuất hiện vào lúc 18:50:59.
Những điểm cần lưu ý trong quá trình ghi log
Một chi tiết trong quá trình ghi log có thể làm phức tạp quá trình phân loại sự cố. Trường userIdentity của CloudTrail đã chỉ định TestUser là tác nhân đứng sau việc đính kèm chính sách, mặc dù người dùng này không thực hiện hành động đó. Bản ghi không xác định rõ ràng quá trình tự động hóa của AWS.
Thông báo trên AWS Health và việc tạo trường hợp hỗ trợ cũng không tạo ra bất kỳ sự kiện CloudTrail nào trong quá trình thử nghiệm. Điều này làm cho bản ghi AttachUserPolicy trở thành tín hiệu có thể đọc bằng máy đáng tin cậy nhất.
Lịch sử phát triển và mục đích của các chính sách kiểm dịch AWS
AWS đã giới thiệu chính sách AWSCompromisedKeyQuarantine ban đầu vào tháng 8 năm 2020, theo sau là phiên bản V2 vào tháng 4 năm 2021 và V3 vào tháng 8 năm 2024. Phiên bản đầu tiên đã rõ ràng từ chối 28 hành động trên các dịch vụ IAM, EC2, Organizations, Lambda và Lightsail.
Phiên bản V2 đã mở rộng các hạn chế sang S3 và cuối cùng tích lũy thêm 61 quyền bị từ chối trên 17 dịch vụ. Các phiên bản sau đó đã giải quyết các hành vi lạm dụng liên quan đến ECS, ECR, Bedrock, SageMaker, STS và các dịch vụ khác.
Sự phát triển này phản ánh những thay đổi trong các cuộc tấn công trên đám mây. Các hạn chế đối với việc tạo vai trò và Lambda có thể cản trở sự tồn tại của các hoạt động đào tiền ảo. Các biện pháp kiểm soát xóa S3 có thể làm gián đoạn các nỗ lực tống tiền dữ liệu, và việc từ chối các hành động liên quan đến Bedrock nhằm giải quyết việc tiêu thụ AI tạo sinh trái phép.
Do một quy tắc Deny rõ ràng được ưu tiên hơn Allow trong quá trình đánh giá chính sách IAM, cơ chế kiểm dịch có thể chặn các hành động rủi ro cao đã liệt kê mà không cần viết lại các quyền hiện có của người dùng.
Giới hạn của cơ chế kiểm dịch
Cơ chế kiểm dịch, tuy nhiên, không phải là thu hồi. AWS cố tình chặn các hoạt động được chọn thay vì vô hiệu hóa khóa hoặc áp dụng AWSDenyAll, làm giảm thiểu khả năng gián đoạn đối với các quy trình công việc hợp pháp.
Do đó, kẻ tấn công vẫn có thể thực hiện các hành động không có trong danh sách từ chối. Quản trị viên nên xem việc đính kèm chính sách này như một sự cố lộ lọt thông tin đăng nhập đã được xác nhận, tuân theo trường hợp hỗ trợ của AWS, xoay vòng hoặc vô hiệu hóa khóa, và xem xét lại các hoạt động xung quanh vụ việc.
Các biện pháp giám sát và phòng ngừa
Các nhóm bảo mật nên thiết lập cảnh báo cho các sự kiện IAM AttachUserPolicy nơi requestParameters.policyArn chứa AWSCompromisedKeyQuarantine, AWSCompromisedKeyQuarantineV2, hoặc AWSCompromisedKeyQuarantineV3.
Họ nên liên kết người dùng bị ảnh hưởng với các hoạt động CloudTrail trước đó và sau đó, bao gồm các yêu cầu GetCallerIdentity mang tác nhân người dùng xác thực tự động của GitHub. Ngoài ra, cần tập trung hóa các trường hợp hỗ trợ thông qua AWS Systems Manager Explorer để ngăn chặn các thông báo bị phân mảnh trong các nhóm kỹ thuật đám mây.
Palo Alto Networks cho biết Cortex Cloud có thể bổ sung ngữ cảnh hành vi cho các mối đe dọa đám mây dựa trên định danh, trong khi Idira PAM hỗ trợ quản lý bí mật tập trung, truy cập theo yêu cầu và quyền truy cập không có sẵn (zero standing privileges). Các tổ chức cũng có thể sử dụng Unit 42 Cloud Security Assessment để xác định các cấu hình sai và lỗ hổng bảo mật trên đám mây. Họ nên khẩn trương báo cáo các vụ xâm nhập nghi ngờ cho đội ngũ Ứng phó Sự cố Unit 42, đặc biệt là trong các môi trường đám mây đa tài khoản phức tạp.
Tích hợp tra cứu threat intelligence vào Trung tâm Điều hành An ninh (SOC) của bạn có thể giúp cắt giảm thời gian điều tra cảnh báo tới 21 phút, cung cấp ngữ cảnh IOC tức thời cho phản ứng nhanh.
Để tìm hiểu thêm về các lỗ hổng bảo mật và các biện pháp phòng ngừa, bạn có thể tham khảo thông tin từ CISA hoặc NVD.
