9.300 khóa AWS bị lộ vẫn hoạt động sau nhiều năm

Thông tin xác thực AWS bị công khai không phải lúc nào cũng chỉ là sự cố tồn tại trong thời gian ngắn. Cuộc điều tra kéo dài từ tháng 8/2022 đến tháng 8/2026 của Truffle Security cho thấy nhiều khóa vẫn hợp lệ trong nhiều năm, thậm chí có khóa sở hữu đủ quyền để kiểm soát toàn bộ tài khoản AWS doanh nghiệp.

Hơn 9.300 khóa bị lộ vẫn xác thực được

Truffle Security đã thu thập 431.875 lần xuất hiện của bí mật AWS từ các kho mã công khai, lịch sử Git, bộ dữ liệu, ảnh Docker, registry container và nhật ký tích hợp liên tục (CI). Sau khi loại bỏ bản trùng lặp, dữ liệu còn 64.024 khóa truy cập AWS duy nhất, liên quan đến 50.654 tài khoản AWS.

Các nhà nghiên cứu xác minh được 10.616 cặp khóa hoàn chỉnh. Khi kiểm tra lại vào ngày 10/8, 88% vẫn xác thực thành công—tương đương hơn 9.300 khóa AWS từng bị công khai vẫn có thể sử dụng.

Một thông tin xác thực xuất hiện trong kho mã công khai chưa chắc còn gây nguy hiểm nếu nó đã bị thu hồi hoặc không còn quyền truy cập. Rủi ro trở nên nghiêm trọng khi khóa vẫn chưa bị vô hiệu hóa, vẫn xác thực được và còn giữ quyền hạn đáng kể. Cuộc điều tra cho thấy ba điều kiện này thường cùng tồn tại.

768 khóa có thể kiểm soát toàn bộ tài khoản doanh nghiệp

Trong số các khóa còn hoạt động được liên kết với tài khoản doanh nghiệp, 817 khóa được quy cho các công ty. Nhóm này bao gồm:

• 526 khóa của tài khoản root AWS;
• 242 khóa của người dùng IAM gắn với chính sách AdministratorAccess;
• 768 khóa tổng cộng có quyền quản trị toàn bộ tài khoản AWS của một công ty.

Thông tin xác thực root là cấp quyền cao nhất đối với khách hàng AWS. Trong khi đó, danh tính IAM có AdministratorAccess cũng có thể thực hiện các thao tác trên nhiều dịch vụ AWS với phạm vi quyền rất rộng.

Nếu còn hiệu lực, khóa ở một trong hai cấp này có thể mở đường cho việc chiếm quyền tài khoản, tạo tài nguyên trái phép, truy cập dữ liệu hoặc lạm dụng hóa đơn đám mây.

Vì vậy, vấn đề không chỉ nằm ở việc giữ mã nguồn sạch sẽ mà còn ở quản lý quyền và vòng đời thông tin xác thực. Xóa khóa khỏi một tệp công khai không bảo vệ được tài khoản nếu ai đó đã sao chép khóa; tổ chức phải thu hồi hoặc thay mới khóa đó.

Hugging Face là nguồn lộ khóa lớn nhất

Hugging Face là nguồn đơn lẻ lớn nhất được xác định, với 8.482 lần lộ thông tin xác thực AWS. Truffle Security cho biết 17,9% số thông tin xác thực AWS này là thông tin xác thực root.

Kết quả này nằm trong một cuộc quét rộng hơn đối với dữ liệu công khai trên Hugging Face. Truffle Security cho biết họ đã kiểm tra 7,6 petabyte bộ dữ liệu công khai và phát hiện thông tin xác thực còn hoạt động trong hàng nghìn bộ dữ liệu. Phát hiện cho thấy bí mật có thể tồn tại bên ngoài các kho phần mềm truyền thống và tiếp tục lan truyền qua những bộ dữ liệu được công khai.

Với các đội ngũ bảo mật, chỉ quét những kho mã hiện tại là chưa đủ. Lịch sử Git, sản phẩm build, ảnh container, registry, bộ dữ liệu đã xuất bản và nhật ký CI đều có thể lưu lại khóa ngay cả khi nhà phát triển nghĩ rằng mình đã xóa chúng.

Nhiều khóa đã tồn tại khoảng 5 năm và hiếm khi được thay mới

Tuổi trung vị của các thông tin xác thực được báo cáo là khoảng 1.831 ngày, tương đương gần 5 năm. Khóa lâu đời nhất đã tồn tại 17,4 năm. Chỉ 13,7% mục dữ liệu có một khóa mới hơn gắn với cùng người dùng, cho thấy phần lớn khóa chưa được thay theo quy trình luân chuyển thông thường.

Khóa truy cập tồn tại lâu làm tăng khoảng thời gian có thể bị sử dụng trái phép và khiến việc xác định chủ sở hữu trở nên khó khăn hơn. Chúng cũng có thể tiếp tục tồn tại sau khi nhân sự thay đổi, ứng dụng được chuyển đổi, kho mã được dọn dẹp hoặc trách nhiệm vận hành được bàn giao.

Do đó, tuổi của khóa nên được xem là một tín hiệu rủi ro. Một khóa đã bị công khai từ nhiều năm trước không nên mặc định là đã hết giá trị; tổ chức cần kiểm tra, thu hồi và điều tra, trừ khi có thể chứng minh khóa không còn hiệu lực.

Chỉ một phần nhỏ tài khoản bật cảnh báo ngân sách

Truffle Security có thể đọc thông tin tài khoản của 2.754 tài khoản, nhưng chỉ 262 tài khoản đã bật cảnh báo ngân sách AWS.

Cảnh báo ngân sách không thể thay thế việc thu hồi khóa hay phát hiện xâm nhập. Tuy nhiên, đây có thể là tín hiệu sớm khi thông tin xác thực bị lộ được dùng để tạo tài nguyên tốn kém, chẳng hạn hoạt động đào tiền số hoặc các hình thức lạm dụng đám mây khác.

Nếu thông báo không đến được người có khả năng xử lý, chi phí bất thường có thể tiếp tục phát sinh ngay cả sau khi tài khoản đã bị xâm phạm.

Thông báo của AWS giải quyết được gì?

Theo các báo cáo, cơ chế bảo vệ của AWS có thể phát hiện khóa truy cập bị lộ, thông báo cho khách hàng bị ảnh hưởng và áp dụng các biện pháp hạn chế hoặc cách ly. Tuy nhiên, việc nhiều khóa vẫn xác thực được cho thấy cảnh báo hoặc phát hiện chưa phải lúc nào cũng dẫn đến hành động thu hồi và thay mới kịp thời từ phía khách hàng.

Phát hiện chỉ là bước đầu trong quy trình xử lý sự cố thông tin xác thực. Một quy trình đầy đủ cần xác định chủ sở hữu, đánh giá khóa có thể truy cập những gì, kiểm tra dấu hiệu lạm dụng và vô hiệu hóa khóa.

Truffle Security mô tả hoạt động xác minh của mình là chỉ đọc: nhóm này kiểm tra khả năng xác thực và siêu dữ liệu về quyền hoặc tài khoản, thay vì chỉnh sửa tài nguyên của khách hàng. Chi tiết về phương pháp này được nêu theo mô tả của Truffle Security và chưa được mọi nguồn trong tài liệu cung cấp xác minh độc lập.

Doanh nghiệp nên làm gì khi khóa AWS bị lộ?

1. Thu hồi hoặc thay khóa ngay lập tức

Xóa hoặc vô hiệu hóa mọi thông tin xác thực đã bị công khai, sau đó chỉ cấp khóa thay thế nếu quyền truy cập vẫn thực sự cần thiết. Xóa bí mật khỏi kho mã, xóa tệp hoặc viết lại lịch sử Git không làm vô hiệu hóa những bản sao đã có thể bị người khác lưu lại.

2. Loại bỏ khóa truy cập root

Không nên dùng khóa truy cập của người dùng root AWS cho hoạt động truy cập lập trình thường ngày. Hãy xóa các khóa root và chuyển workload sang những danh tính được kiểm soát với quyền hạn giới hạn rõ ràng.

3. Kiểm tra quyền và chủ sở hữu

Xác định khóa thuộc tài khoản, người dùng, dịch vụ và tài nguyên nào. Ưu tiên xử lý các khóa có quyền root, AdministratorAccess, quyền truy cập dữ liệu rộng hoặc khả năng tạo hạ tầng.

4. Điều tra cả trước và sau khi thu hồi

Rà soát hoạt động xác thực, nhật ký CloudTrail, thay đổi IAM, tài nguyên mới được tạo và hóa đơn để tìm dấu hiệu đáng ngờ. Thu hồi khóa chỉ ngăn việc tiếp tục sử dụng khóa bị lộ; hành động này không cho biết khóa đã từng bị lợi dụng hay chưa.

5. Thay khóa dài hạn bằng danh tính ngắn hạn

Khi có thể, hãy dùng IAM role ngắn hạn và danh tính dành cho workload thay cho khóa truy cập vĩnh viễn. Áp dụng nguyên tắc quyền tối thiểu sẽ giảm mức độ thiệt hại nếu thông tin xác thực bị lộ.

6. Bật cảnh báo ngân sách và thiết lập đầu mối phản ứng

Cấu hình cảnh báo AWS Budgets và tính năng theo dõi bất thường về chi phí, đồng thời chuyển thông báo đến những người có thể hành động nhanh. Giám sát tài chính chỉ là lớp bảo vệ bổ sung, không thể thay thế quét bí mật, luân chuyển khóa và rà soát quyền truy cập.

Bài học lớn hơn về bảo mật đám mây

Điểm đáng lo nhất không chỉ là số lượng bí mật được phát hiện, mà là sự kết hợp của bị công khai, vẫn còn hiệu lực, có quyền cao, tồn tại quá lâu và thiếu giám sát. Dữ liệu công khai có thể lưu giữ thông tin xác thực rất lâu sau khi tổ chức quên mất chúng từng được dùng ở đâu, còn một khóa đã bị sao chép có thể tiếp tục hoạt động cho đến khi bị thu hồi rõ ràng.

Giả định an toàn hơn cho các đội ngũ sử dụng đám mây rất đơn giản: hãy coi mọi thông tin xác thực AWS bị lộ là đã bị xâm phạm, xác minh phạm vi truy cập, lập tức thay mới hoặc thu hồi, rồi chuyển từ khóa dài hạn sang các danh tính ngắn hạn với quyền tối thiểu.