Rò rỉ dữ liệu từ S3 public: cách kiểm tra và khóa ngay

Bạn có chắc bucket lưu trữ của công ty mình đang ở chế độ riêng tư? Chỉ một cấu hình sai — một dòng policy thừa, một ACL cũ chưa xóa — là toàn bộ file khách hàng, hợp đồng hay bản sao lưu cơ sở dữ liệu có thể bị phơi bày ra Internet cho bất kỳ ai cũng tải về được. Kịch bản S3 public rò rỉ dữ liệu này đã khiến không ít doanh nghiệp trả giá bằng uy tín, tiền phạt và cả vụ kiện.

Tin tốt là việc kiểm tra và khóa bucket public chỉ mất vài phút nếu bạn biết đúng chỗ cần nhìn. Bài viết hướng dẫn từng bước — phát hiện, khóa khẩn cấp, rà soát triệt để và phòng ngừa — áp dụng cho cả AWS S3 lẫn dịch vụ lưu trữ tương thích S3 (S3-compatible).

S3 public rò rỉ dữ liệu: s3 public là gì và vì sao nó gây rò rỉ dữ liệu?

S3 là dịch vụ lưu trữ đối tượng: bạn tạo các "bucket" và đưa file vào đó. Mặc định mọi bucket mới đều ở chế độ riêng tư (private) — chỉ chủ tài khoản mới đọc được. Bucket trở thành public khi có ai đó vô tình hoặc cố ý bật một trong các cơ chế cho phép truy cập ẩn danh:

• Bucket policy chứa "Principal": "*" cho phép đọc object.
• ACL ở cấp bucket hoặc object đặt thành public-read / public-read-write.
• Static website hosting được bật mà không giới hạn truy cập.
• Pre-signed URL bị chia sẻ ra ngoài (hiệu quả tương tự public trong thời hạn của URL).

Khi bucket public, bất kỳ ai có link đều có thể liệt kê và tải file — kể cả các bot quét Internet chuyên săn bucket mở. Nguy hiểm nhất là file sao lưu database, file cấu hình chứa key/secret và dữ liệu cá nhân khách hàng. Theo hướng dẫn bảo mật S3 của AWS, đừng bao giờ cho phép public trừ khi có lý do chính đáng và được kiểm soát chặt. Lưu ý: dịch vụ S3-compatible trong nước dùng đúng mô hình quyền này nên toàn bộ checklist đều áp dụng được.

S3 public rò rỉ dữ liệu: dấu hiệu cho thấy bucket của bạn đang bị mở public

Rà nhanh các dấu hiệu cảnh báo sau — trúng bất kỳ dấu hiệu nào, hãy coi như tình huống khẩn cấp:

• Mở được link file ở trình duyệt ẩn danh. Copy URL của một object, mở bằng cửa sổ ẩn danh. Tải được mà không hỏi xác thực — bucket đang public.
• Console hiển thị nhãn "Public". Trên S3 console, bucket public có nhãn cảnh báo ở cột "Access".
• Bucket policy có Principal "*". Mở tab Permissions → Bucket policy, nếu thấy "Effect": "Allow", "Principal": "*" kèm "Action": "s3:GetObject" — đó chính là cửa mở.
• ACL có grant cho nhóm "Everyone". Trong Access control list, grantee http://acs.amazonaws.com/groups/global/AllUsers nghĩa là file mở cho cả thế giới.
• Log truy cập bất thường. Server access log hoặc CloudTrail ghi nhận lượt GET từ IP lạ, user-agent của tool quét, hoặc lượng download tăng đột biến vào giờ lạ.

Ngay cả khi bạn "chỉ mở public tạm để test", các bot quét bucket có thể phát hiện trong vài phút. Không có khái niệm "mở tạm an toàn".

S3 public rò rỉ dữ liệu: cách kiểm tra quyền bucket bằng console và AWS CLI

Kiểm tra nhanh trên console: vào S3 console, mở bucket, chọn tab Permissions. Xem mục Block public access: cả 4 ô phải ở trạng thái On. Tiếp theo đọc Bucket policy — chỉ giữ Allow cho principal cụ thể (IAM role, tài khoản, CloudFront OAC...), không bao giờ để "*". Cuối cùng kiểm tra ACL: không có dòng nào grant cho "Everyone" hay "Authenticated users". Với object nhạy cảm, kiểm tra thêm ACL ở cấp object vì nó có thể mở public độc lập với bucket.

Kiểm tra hàng loạt bằng AWS CLI khi có hàng chục, hàng trăm bucket:

# Liệt kê toàn bộ bucket
aws s3api list-buckets --query "Buckets[].Name" --output text

# Kiểm tra Block Public Access của từng bucket
aws s3api get-public-access-block --bucket TEN-BUCKET

# Kiểm tra ACL và bucket policy
aws s3api get-bucket-acl --bucket TEN-BUCKET
aws s3api get-bucket-policy --bucket TEN-BUCKET

Viết vòng lặp shell chạy các lệnh trên cho mọi bucket, xuất CSV để đội bảo mật rà soát. Với S3-compatible trong nước, thêm --endpoint-url của nhà cung cấp. Lên lịch quét mỗi tuần một lần — nhiều vụ rò rỉ xảy ra do ai đó sửa policy lúc xử lý sự cố rồi quên trả lại, chứ không phải cấu hình ban đầu sai.

Khóa public access ngay lập tức với Block Public Access

Phát hiện bucket public, việc đầu tiên là khóa khẩn cấp, rồi mới điều tra nguyên nhân. AWS cung cấp cơ chế Block Public Access — "công tắc tổng" ghi đè mọi policy/ACL cho phép public. Chi tiết kỹ thuật xem tại tài liệu Block Public Access của AWS.

Cách 1 — khóa từng bucket (khẩn cấp): trên console vào S3 → chọn bucket → tab Permissions → Block public access → Edit → bật cả 4 tùy chọn → Save. Bằng CLI:

aws s3api put-public-access-block --bucket TEN-BUCKET \
  --public-access-block-configuration \
  "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"

Cách 2 — bật ở cấp tài khoản (khuyến nghị): áp dụng cho mọi bucket hiện tại và tương lai, kể cả bucket do người khác tạo sau này. Trên console: S3 → Block Public Access settings for this account → Edit → bật cả 4 ô. Đây là lớp phòng thủ rẻ nhất và hiệu quả nhất.

Bốn tùy chọn lần lượt: chặn ACL public mới, vô hiệu hóa ACL public đã tồn tại, chặn policy public mới, và giới hạn policy public cũ chỉ còn tác dụng với principal trong tài khoản.

Sau khi bật, kiểm tra lại bằng trình duyệt ẩn danh — phải nhận lỗi AccessDenied. Nếu website tĩnh đang serve trực tiếp từ S3 public, hãy chuyển sang CDN với quyền truy cập giới hạn thay vì mở lại bucket.

Rà soát ACL và bucket policy còn sót sau khi khóa

Block Public Access là công tắc khẩn cấp, nhưng dọn gốc rễ mới ngăn tái diễn:

1. Xóa grant "Everyone" khỏi ACL. Đặt lại ACL về private ở cả cấp bucket và object. Với hàng loạt object, dùng script duyệt toàn bộ và gán lại --acl private.
2. Sửa bucket policy: thay "Principal": "*" bằng principal cụ thể (ví dụ service của CDN kèm điều kiện AWS:SourceArn). Tham khảo cú pháp chuẩn tại tài liệu bucket policy của AWS.
3. Kiểm tra cross-account access: xác minh từng tài khoản được liệt kê — tài khoản đối tác cũ hay tài khoản test bị bỏ quên đều là rủi ro.
4. Rà soát IAM policy: bucket private nhưng IAM user quyền quá rộng bị lộ access key thì hiệu quả cũng như public. Áp dụng least privilege và bật MFA cho mọi user có quyền S3.
5. Tắt static website hosting nếu không dùng: endpoint website của S3 luôn public.

Ghi lại mọi thay đổi vào ticket nội bộ: ai sửa, sửa gì, khi nào — hồ sơ này quan trọng khi cần chứng minh với khách hàng hoặc cơ quan quản lý.

Thiết lập cảnh báo tự động khi có bucket bị mở public

Con người sẽ quên, automation thì không. Hãy dựng ít nhất một lớp giám sát:

• AWS Config rule s3-bucket-public-read-prohibited và s3-bucket-public-write-prohibited: tự động đánh dấu non-compliant khi có bucket public, có thể cấu hình tự động bật lại Block Public Access.
• CloudTrail + EventBridge: bắt sự kiện PutBucketPolicy, PutBucketAcl, PutPublicAccessBlock — bất kỳ ai chạm vào quyền bucket đều trigger cảnh báo về Slack/email trong vài phút.
• Với S3-compatible trong nước: hỏi nhà cung cấp về audit log và cảnh báo thay đổi policy; phân quyền chặt trên portal quản trị — chỉ 1–2 admin được sửa bucket policy.

Đặt ngưỡng phản ứng rõ ràng: cảnh báo bucket public = sự cố P1, người trực phải khóa trong vòng 30 phút kể cả ngoài giờ hành chính.

Dữ liệu đã bị rò rỉ: quy trình xử lý sự cố

Phát hiện muộn không có nghĩa là hết cách. Khi xác nhận dữ liệu đã bị truy cập trái phép, xử lý theo trình tự:

1. Cô lập: khóa bucket public ngay. Đừng xóa log — log là bằng chứng.
2. Đánh giá phạm vi: từ access log / CloudTrail, xác định những object nào bị tải, thời gian nào, từ IP nào, tổng dung lượng bao nhiêu.
3. Xoay vòng bí mật: nếu file lộ chứa API key, password, connection string — xoay ngay lập tức toàn bộ credential liên quan, kể cả khi "chưa thấy dấu hiệu bị dùng". Kẻ xấu thường thu thập trước, khai thác sau.
4. Thông báo: nếu dữ liệu cá nhân khách hàng bị lộ, bạn có nghĩa vụ thông báo theo Luật Bảo vệ dữ liệu cá nhân và Luật An toàn thông tin mạng.
5. Khắc phục gốc và rút kinh nghiệm: rà soát toàn bộ bucket, dựng cảnh báo tự động, họp post-mortem trong 72 giờ với action item có người chịu trách nhiệm.

Sai lầm phổ biến là chỉ khóa bucket rồi coi như xong. Kẻ tấn công đã tải file về máy chúng thì việc khóa bucket sau đó không còn ý nghĩa với những dữ liệu đó nữa.

Phòng ngừa dài hạn: chính sách mặc định an toàn

• Mặc định deny: mọi bucket mới đều private + Block Public Access bật sẵn ở cấp tài khoản. Muốn public phải qua phê duyệt bằng ticket có lý do và thời hạn.
• Mã hóa mặc định cho bucket để giảm thiệt hại trong các kịch bản rò rỉ khác.
• Versioning cho bucket chứa dữ liệu quan trọng để chống xóa nhầm và mã độc tống tiền.
• Server access logging cho mọi bucket production, lưu sang bucket riêng, đặt lifecycle tự xóa sau 12–24 tháng.
• Phân tách môi trường: bucket dev/test/staging tuyệt đối không chứa dữ liệu production thật.
• Đào tạo định kỳ mỗi quý cho đội dev/ops về quyền S3.

Đưa checklist này vào quy trình onboarding nhân sự kỹ thuật mới và checklist review trước mỗi release có đụng đến hạ tầng lưu trữ.

Lưu trữ S3-compatible an toàn ngay tại Việt Nam

Với dữ liệu khách hàng, hồ sơ pháp lý hay dữ liệu phải tuân thủ quy định lưu trữ trong nước, dịch vụ S3-compatible đặt tại datacenter Việt Nam cho độ trễ thấp hơn và kiểm soát rõ ràng hơn về vị trí dữ liệu.

Khi chọn nhà cung cấp S3 trong nước, hãy hỏi: có hỗ trợ đầy đủ Block Public Access, bucket policy, ACL chuẩn S3 không? Có audit log thay đổi quyền bucket không? Datacenter đạt chuẩn gì (Tier III, ISO 27001)? Có mã hóa mặc định, versioning không? Hỗ trợ có phản ứng 24/7 khi sự cố không?

SunCloud cung cấp dịch vụ lưu trữ đám mây đặt tại datacenter đạt chuẩn Tier III trong nước, hạ tầng colocation đạt ISO 27001:2013, portal quản trị tập trung giúp phân quyền chặt chẽ và hỗ trợ kỹ thuật 24/7/365. Gom các bucket phân tán về một nền tảng quản trị tập trung sẽ giảm đáng kể rủi ro cấu hình sai.

Kết luận

S3 public rò rỉ dữ liệu hầu như không bao giờ do hacker "bẻ khóa" — mà do một cấu hình quyền bị mở ra và không ai để ý. Công thức xử lý gói gọn trong bốn bước: kiểm tra (console + CLI quét toàn bộ bucket), khóa ngay (Block Public Access cấp bucket rồi cấp tài khoản), dọn sạch (xóa ACL/policy public còn sót, xoay credential nếu đã lộ), và phòng ngừa (mặc định deny, cảnh báo tự động, đào tạo định kỳ).

Hãy dành 15 phút ngay hôm nay để thử mở link các bucket quan trọng nhất bằng trình duyệt ẩn danh. Phát hiện sớm một bucket public rẻ hơn rất nhiều so với xử lý một vụ rò rỉ dữ liệu.

Cần rà soát lại hạ tầng lưu trữ và phân quyền? Liên hệ SunCloud qua hotline 083 979 3434 hoặc suncloud.vn để được tư vấn giải pháp lưu trữ S3 an toàn tại datacenter Tier III trong nước.

Câu hỏi thường gặp

Bucket S3 mới tạo có mặc định public không?

Không. Mọi bucket mới đều private, và tài khoản mới còn được bật sẵn Block Public Access ở cấp tài khoản. Bucket chỉ public khi có người hoặc script chủ động tắt các lớp bảo vệ. Vì vậy khi phát hiện bucket public, câu hỏi đầu tiên là "ai đã thay đổi và khi nào" — hãy tra CloudTrail.

Block Public Access có làm sập website đang chạy trên S3 không?

Có thể, nếu website của bạn serve trực tiếp từ S3 public qua static website hosting. Khi bật khóa, người dùng sẽ nhận lỗi AccessDenied. Cách đúng là chuyển sang dùng CDN với quyền truy cập giới hạn (chỉ CDN được đọc bucket), giữ bucket ở chế độ private. Hãy chuẩn bị phương án CDN trước khi bật khóa trên bucket production.

Pre-signed URL có được coi là public không?

Không hẳn, nhưng rủi ro tương đương nếu URL bị lộ: ai có link đều tải được trong thời hạn hiệu lực. Hãy đặt thời gian hết hạn ngắn nhất có thể (vài phút thay vì vài ngày), và không bao giờ đăng pre-signed URL lên nơi công cộng như GitHub hay forum.

Làm sao biết dữ liệu đã bị tải trộm trước khi mình khóa bucket?

Bật server access logging và lọc các request GET thành công từ IP lạ, đặc biệt request liệt kê bucket (ListBucket) — dấu hiệu của tool quét. Nếu chưa từng bật log, bạn không thể biết chắc quá khứ — hãy giả định tình huống xấu nhất và xoay toàn bộ credential liên quan.

S3-compatible của nhà cung cấp Việt Nam có nguy cơ tương tự không?

Có, vì mô hình phân quyền là chuẩn chung của S3 API. Rủi ro nằm ở cách đội ngũ của bạn cấu hình chứ không nằm ở nhà cung cấp. Hãy ưu tiên đơn vị hỗ trợ đầy đủ cơ chế khóa public, có audit log và portal quản trị tập trung.

Nên kiểm tra bucket public với tần suất bao nhiêu?

Tối thiểu mỗi tuần một lần bằng script tự động, cộng cảnh báo real-time mỗi khi có thay đổi quyền. Đưa việc rà soát vào checklist mọi đợt release, audit bảo mật hàng quý và sau mỗi lần xử lý sự cố hạ tầng.