Bỏ qua điều hướng
Blog

S3 Block Public Access: đọc bốn cờ trước khi sửa quyền

S3 Block Public Access có bốn cờ khác nhau. Đọc ACL, policy và cấp account/bucket, đối chiếu origin với CDN bằng ma trận chẩn đoán có nguồn.

Chia sẻFacebookLinkedInZalo
Hai nhóm ACL và policy, mỗi nhóm hai cờ trong S3 Block Public Access, cùng Bee Onter
Nội dung bài viết

Console cho thấy một cờ đã bật nhưng URL vẫn có hành vi ngoài dự kiến. Trước khi đổi quyền, cần biết đang nhìn cờ nào và ở cấp nào. S3 Block Public Access gồm bốn thiết lập có tác dụng khác nhau; một cờ chặn ACL mới không tự đồng nghĩa mọi đường đọc hiện tại đã bị chặn.

Bài này dành cho người vận hành AWS S3 cần lập hồ sơ chẩn đoán quyền hiệu lực. Quyết định tài liệu nên công khai hay cấp quyền đã có hướng dẫn riêng. Ở đây, đầu ra là sổ cờ, cấp áp dụng và bằng chứng theo đường truy cập, không phải phân loại nội dung website thêm lần nữa.

Bốn cờ S3 Block Public Access không phải bốn tên của một chức năng

AWS mô tả bốn thiết lập với hai nhóm ACL và policy:

Cờ Điểm cần phân biệt
BlockPublicAcls Từ chối thao tác đặt ACL công khai thuộc phạm vi kiểm tra; không sửa ACL cũ.
IgnorePublicAcls Không dùng quyền cấp công khai từ ACL để cho truy cập; không xóa ACL.
BlockPublicPolicy Chặn việc đặt policy công khai thuộc phạm vi kiểm tra; không sửa policy đã có.
RestrictPublicBuckets Hạn chế truy cập khi bucket có policy công khai; cần xét loại principal và điều kiện AWS nêu.
Bốn cờ S3 Block Public Access chia nhóm ACL và policy, phân biệt chặn thao tác mới với quyền hiệu lực
Bốn cờ BPA được nhóm theo tác động ACL và policy; sơ đồ Onter biên soạn từ tài liệu AWS, không phải cấu hình đã triển khai.

Bảng không đủ để quyết định một request cụ thể được phép hay không. Cần xem action, resource, principal và các chính sách liên quan. Không suy từ tên một cờ ra một quyền tổng quát, cũng không coi thay cờ là đã dọn xong nguồn cấp quyền cũ.

Đọc cờ theo cấp áp dụng, không chỉ một bucket

Thiết lập có thể liên quan account, bucket và access point; chính sách organization cũng có thể ảnh hưởng account. AWS áp tổ hợp hạn chế chặt nhất ở các cấp liên quan. Vì vậy, nhìn bucket tắt một cờ chưa chứng minh cờ hiệu lực đã tắt.

Trong sổ chẩn đoán, ghi đủ bốn cờ ở từng cấp có liên quan, đường truy cập đang dùng và thời điểm quan sát. Nếu không có quyền đọc cấu hình account hoặc organization, ghi chưa đủ bằng chứng. Đừng tự tạo quyền rộng hơn để xem cho đủ một bảng.

Ma trận giả định để kiểm tra cách đọc

Ba ca sau chỉ giải thích một lớp kiểm; giả định các điều kiện khác của request được giữ nguyên. Chúng không đại diện chính sách AWS account thực tế hoặc công thức kết luận mọi quyền:

Ca giả định Quan sát cần phân biệt
Account bật BlockPublicAcls, bucket tắt Cấp bucket không bỏ được hạn chế account cho thao tác ACL thuộc phạm vi.
Chỉ bật IgnorePublicAcls, có ACL công khai cũ Quyền công khai từ ACL bị bỏ qua; không suy ACL đã bị xóa.
Bật BlockPublicPolicy sau khi policy đã tồn tại Không suy policy cũ đã được sửa; kiểm quyền hiệu lực và các cờ khác.
Ba ca giả định phân biệt hạn chế account, ACL bị bỏ qua và policy cũ chưa được sửa
Ba ca giả định về hạn chế account, ACL bị bỏ qua và policy cũ; ma trận Onter biên soạn, không phải kết quả thử AWS thực tế.

Với RestrictPublicBuckets, không rút gọn thành “chặn mọi người ngoài” trong mọi tình huống. Phạm vi liên quan bucket có policy công khai và các ngoại lệ principal AWS mô tả. Nếu request khác action hoặc đi qua access point khác, phải đối chiếu lại.

ACL, Object Ownership và policy phải được đọc cùng nhau

Tài liệu ACL của S3 nêu chế độ Bucket owner enforced vô hiệu hóa ACL. Với môi trường như vậy, việc điều tra một ACL grant không nên bỏ qua Object Ownership hoặc tiếp tục giả định ACL đang cấp quyền như ở cấu hình cũ.

Sổ cần chỉ ra nguồn cấp quyền được cho là nguyên nhân, không chỉ chụp một biểu tượng xanh. Giữ nhãn resource và principal đã ẩn danh khi chia sẻ. Policy, danh sách object hoặc URL có dữ liệu khách vẫn nằm ở nơi được phân quyền; không đưa nguyên cấu hình nhạy cảm vào bài tư vấn.

Origin S3 và đường CloudFront là hai phép quan sát

Một URL CloudFront trả nội dung không tự chứng minh S3 origin mở công khai. AWS hướng dẫn hạn chế truy cập S3 origin qua CloudFront theo cấu hình phù hợp. Quyền CloudFront đến origin và quyền người xem đến CloudFront là hai ranh giới cần ghi riêng.

Ngược lại, origin từ chối vô danh chưa chứng minh CDN từ chối người không được xem. Dùng object thử do mình sở hữu, ghi đường gọi, tài khoản thử, HTTP status, mốc thời gian và cache liên quan. Không mở quyền production để chứng minh download chạy. Link có thời hạn cũng không thay việc đối chiếu chính sách tại từng đường.

Đầu ra trước khi sửa phải đủ để kiểm lại

Một hồ sơ nhỏ gồm nguồn cấu hình, bốn cờ theo cấp, Object Ownership, policy/ACL liên quan và hai đường quan sát sẽ cụ thể hơn kết luận “S3 lỗi quyền”. Phân biệt giả thuyết với lần đọc hoặc thử đã được cấp quyền. Sau thay đổi có phạm vi, kiểm lại đúng object và ngữ cảnh, không thay cả bài toán rồi báo đã sửa.

Khi trao đổi phạm vi tích hợp phần mềm với Onter, chuẩn bị sổ cấu hình đã che dữ liệu và hành vi mong muốn. Quyền thay AWS, canary và rollback cần owner xác nhận; bài này không công bố Onter đã kiểm hoặc sửa account nào, không đưa lệnh mở bucket cho mọi trường hợp.

Tài khoản Onter

Đăng nhập rồi tiếp tục việc đang làm.

Mở trang đăng nhập riêng nếu trình duyệt chưa hiển thị biểu mẫu.

Contact Me on Zalo