Tải tệp an toàn ở quy mô lớn: URL được ký và xác thực

Điều gì làm cho upload tệp trở nên khó ở quy mô lớn

Upload tệp trông có vẻ đơn giản cho tới khi người dùng thực sự xuất hiện. Một người tải ảnh hồ sơ. Rồi mười nghìn người cùng tải PDF, video và bảng tính cùng một lúc. Đột nhiên app chậm, chi phí lưu trữ tăng cao và ticket hỗ trợ chất đống.

Các lỗi phổ biến thì dễ dự đoán. Trang upload treo hoặc timeout khi server cố xử lý toàn bộ byte thay vì để object storage làm phần nặng. Quyền truy cập trôi dạt, ai đó đoán được URL của đối tượng và thấy thứ họ không nên thấy. Tệp “vô hại” đến kèm malware, hoặc có định dạng rắc rối làm hỏng công cụ phía sau. Và log không đầy đủ, nên bạn không thể trả lời các câu hỏi cơ bản như ai đã tải gì và khi nào.

Những gì bạn muốn thay vào đó là nhàm chán nhưng đáng tin cậy: upload nhanh, quy tắc rõ ràng (loại và kích thước cho phép), và một dấu vết kiểm toán giúp điều tra sự cố dễ dàng.

Thương lượng khó nhất là tốc độ vs an toàn. Nếu bạn chạy mọi kiểm tra trước khi người dùng hoàn tất, họ sẽ chờ và retry, làm tăng tải. Nếu bạn hoãn kiểm tra quá lâu, tệp không an toàn hoặc không đúng quyền có thể lan trước khi bị phát hiện. Cách thực dụng là tách việc upload khỏi các kiểm tra, và giữ mỗi bước nhanh và đo lường được.

Cũng hãy cụ thể về “quy mô”. Ghi rõ con số của bạn: tệp mỗi ngày, peak upload mỗi phút, kích thước tệp tối đa, và nơi người dùng ở. Vùng địa lý ảnh hưởng tới độ trễ và quy tắc bảo mật dữ liệu.

Nếu bạn xây dựng app trên nền tảng như Koder.ai, tốt hơn là quyết các giới hạn này sớm, vì chúng ảnh hưởng tới cách thiết kế quyền, lưu trữ và workflow quét nền.

Mô hình mối đe dọa đơn giản cho upload

Trước khi chọn công cụ, hãy rõ những gì có thể sai. Một mô hình mối đe dọa không cần là tài liệu dài. Nó là hiểu biết ngắn gọn chung về những gì bạn phải ngăn chặn, những gì có thể phát hiện sau, và những đánh đổi bạn chấp nhận.

Kẻ tấn công thường cố len lỏi ở vài điểm dễ đoán: client (thay metadata hoặc giả MIME type), rìa mạng (replay và lạm dụng giới hạn tần suất), storage (đoán tên đối tượng, ghi đè), và khi tải/xem trước (kích hoạt rendering rủi ro hoặc đánh cắp tệp qua truy cập chia sẻ).

Từ đó, map mối đe dọa tới các kiểm soát đơn giản:

Tệp quá lớn là lạm dụng dễ nhất. Chúng có thể làm tăng chi phí và làm chậm người dùng thật. Chặn sớm bằng giới hạn byte cứng và trả về lỗi nhanh.

Tệp giả loại là vấn đề tiếp theo. Một tệp tên invoice.pdf có thể là thứ khác. Đừng tin extension hay kiểm tra UI. Xác minh dựa trên byte thực sau khi upload.

Malware thì khác. Thường bạn không thể quét mọi thứ trước khi upload hoàn tất mà không làm trải nghiệm đau đớn. Mẫu thông thường là phát hiện bất đồng bộ, cách ly mục nghi ngờ, và chặn truy cập cho tới khi quét sạch.

Truy cập trái phép thường gây tổn thất lớn nhất. Xử lý mỗi upload và mỗi download như một quyết định quyền. Người dùng chỉ nên upload vào vị trí họ sở hữu (hoặc được phép ghi), và chỉ tải về tệp họ được phép xem.

Với nhiều app, chính sách v1 chắc chắn là:

• Áp giới hạn kích thước tối đa và danh mục cho phép (ảnh, PDF, v.v.)
• Xác minh loại tệp thực tế phía server sau khi upload
• Quét bất đồng bộ và cách ly cho tới khi sạch
• Yêu cầu ủy quyền rõ ràng cho upload và download
• Ghi log và cảnh báo khi lỗi lặp lại (kích thước, loại, auth)

Kiến trúc upload thực tế mà vẫn nhanh

Cách nhanh nhất để xử lý upload là tránh để app server dính vào “vấn đề byte”. Thay vì gửi mọi tệp qua backend, để client tải trực tiếp lên object storage bằng signed URL ngắn hạn. Backend của bạn tập trung vào quyết định và ghi chép, không phải truyền gigabyte.

Phân tách đơn giản: backend trả lời “ai có thể upload gì, và ở đâu”, còn storage nhận dữ liệu tệp. Điều này loại bỏ cổ chai phổ biến: app server vừa auth vừa proxy file và bị hết CPU, bộ nhớ hoặc mạng khi tải cao.

Các thành phần tối thiểu cần có

Giữ một bản ghi upload nhỏ trong DB (ví dụ PostgreSQL) để mỗi tệp có chủ sở hữu rõ ràng và vòng đời xác định. Tạo bản ghi này trước khi upload bắt đầu, rồi cập nhật khi các sự kiện xảy ra.

Các trường thường hữu ích gồm owner và tenant/workspace, key của đối tượng trên storage, status, kích thước và MIME type được khai nhận, và checksum bạn có thể xác minh.

Lên kế hoạch trạng thái upload trước

Xử lý upload như một state machine để kiểm tra quyền vẫn đúng ngay cả khi retry xảy ra.

Một tập trạng thái thực dụng là:

• requested
• uploaded
• scanned
• approved
• rejected

Chỉ cho client dùng signed URL sau khi backend tạo bản ghi requested. Sau khi storage xác nhận upload, chuyển sang uploaded, khởi chạy quét malware nền, và chỉ mở file khi nó approved.

Bước theo bước: signed URL uploads không gây tắc nghẽn

Bắt đầu khi người dùng bấm Upload. App gọi backend để bắt đầu upload với thông tin cơ bản như tên file, kích thước dự kiến, và mục đích (avatar, hóa đơn, đính kèm). Backend kiểm tra quyền cho mục tiêu đó, tạo bản ghi upload và trả về signed URL ngắn hạn.

Signed URL nên được phân quyền hẹp. Tốt nhất chỉ cho phép một lần upload tới một object key chính xác, có thời hạn ngắn và điều kiện rõ ràng (giới hạn kích thước, loại nội dung cho phép, checksum tùy chọn).

Trình duyệt tải trực tiếp lên storage bằng URL đó. Khi hoàn tất, trình duyệt gọi backend để finalize. Khi finalize, kiểm tra lại quyền (người dùng có thể mất quyền), và xác minh thứ thực sự nằm trên storage: kích thước, loại nội dung được phát hiện, và checksum nếu dùng. Làm finalize idempotent để retry không tạo bản ghi trùng lặp.

Sau đó đánh dấu bản ghi là uploaded và kích hoạt quét nền (queue/job). UI có thể hiển thị “Đang xử lý” trong khi quét chạy.

Xác thực loại và kích thước bạn có thể tin tưởng

Cần kiểm tra gì, và ở đâu

Tin vào extension là lý do invoice.pdf.exe xuất hiện trong bucket. Xem xác thực là một tập kiểm tra lặp lại diễn ra ở hơn một nơi.

Bắt đầu với giới hạn kích thước. Đặt kích thước tối đa vào chính sách signed URL (hoặc điều kiện pre-signed POST) để storage từ chối upload quá kích thước ngay từ đầu. Áp cùng giới hạn lại khi backend ghi metadata, vì client vẫn có thể cố né UI.

Kiểm tra loại nên dựa trên nội dung, không phải tên tệp. Kiểm tra các byte đầu của tệp (magic bytes) để xác nhận khớp mong đợi. Một PDF thực sự bắt đầu bằng %PDF, và PNG có chữ ký cố định. Nếu nội dung không khớp allowlist, từ chối ngay cả khi extension trông hợp lệ.

Giữ allowlist riêng cho từng tính năng. Upload avatar có thể chỉ cho phép JPEG và PNG. Tính năng tài liệu có thể cho phép PDF và DOCX. Điều này giảm rủi ro và làm quy tắc dễ giải thích hơn.

Checksum và tên tệp

Không bao giờ tin filename gốc làm storage key. Chuẩn hóa nó cho hiển thị (loại bỏ ký tự lạ, cắt độ dài), nhưng lưu key an toàn của bạn, ví dụ UUID cộng với extension bạn gán sau khi phát hiện loại.

Lưu checksum (ví dụ SHA-256) trong DB và so sánh sau này trong xử lý hoặc quét. Điều này giúp phát hiện hỏng, upload một phần, hoặc giả mạo, đặc biệt khi upload retry dưới tải cao.

Quét malware mà không làm người dùng chờ

Quét malware quan trọng, nhưng không nên là đường dẫn chết. Chấp nhận upload nhanh, rồi xử lý file như bị chặn cho tới khi quét sạch.

Mẫu bất đồng bộ

Tạo bản ghi upload với status như pending_scan. UI có thể hiển thị file, nhưng không nên cho dùng ngay.

Quét thường được kích hoạt bởi event của storage khi đối tượng được tạo, bằng cách publish job vào queue ngay sau khi upload hoàn thành, hoặc cả hai (queue + storage event như biện pháp dự phòng).

Worker quét tải xuống hoặc stream đối tượng, chạy scanner, rồi ghi kết quả lại vào DB. Giữ những thứ thiết yếu: trạng thái quét, phiên bản scanner, dấu thời gian, và ai đã yêu cầu upload. Dấu vết kiểm toán này giúp support dễ trả lời khi ai đó hỏi “Tại sao tệp của tôi bị chặn?”

Điều gì xảy ra khi tệp bị lỗi

Đừng để tệp lỗi lẫn với tệp sạch. Chọn chính sách và áp dụng nhất quán: cách ly và thu hồi truy cập, hoặc xóa nếu bạn không cần để điều tra.

Dù chọn gì, thông báo cho người dùng bình tĩnh và cụ thể. Nói cho họ biết đã xảy ra gì và cần làm gì tiếp theo (tải lại, liên hệ support). Cảnh báo đội khi nhiều lỗi xảy ra trong thời gian ngắn.

Quan trọng nhất, đặt quy tắc cứng cho download và preview: chỉ phục vụ các tệp được đánh dấu approved. Các trạng thái khác trả về phản hồi an toàn như “Tệp đang được kiểm tra.”

Kiểm tra quyền giữ đúng dưới tải cao

Upload nhanh thì tốt, nhưng nếu người sai có thể đính tệp vào workspace sai, bạn có vấn đề lớn hơn chậm trễ. Quy tắc đơn giản nhất cũng mạnh nhất: mỗi bản ghi tệp thuộc về đúng một tenant (workspace/org/project) và có chủ sở hữu rõ ràng.

Kiểm tra quyền hai lần: khi cấp signed upload URL, và một lần nữa khi ai đó cố tải về hoặc xem tệp. Kiểm tra đầu ngăn upload trái phép. Kiểm tra thứ hai bảo vệ bạn nếu quyền bị thu hồi, URL rò rỉ, hoặc vai trò người dùng thay đổi sau upload.

Nguyên tắc ít quyền nhất (least privilege) giữ bảo mật và hiệu năng ổn định. Thay vì một permission rộng “files”, tách thành các vai trò như “có thể upload”, “có thể xem”, và “có thể quản lý (xóa/chia sẻ).” Nhiều yêu cầu sau đó chỉ là tra cứu nhanh (user, tenant, action) thay vì logic tùy biến tốn kém.

Để tránh đoán ID, tránh ID tệp tăng dần trong URL và API. Dùng identifier mờ (opaque) và giữ storage key không đoán được. Signed URL là kênh truyền, không phải hệ thống quyền của bạn.

Chia sẻ file thường là nơi hệ thống chậm và rối. Xử lý chia sẻ như dữ liệu rõ ràng, không phải quyền ngầm. Cách đơn giản là một bản ghi sharing riêng cấp quyền cho user hoặc group với một file, có thể có expiry.

Giữ upload nhanh khi lưu lượng và kích thước tăng

Khi nói về scale upload an toàn, người ta hay tập trung vào kiểm tra bảo mật và quên những điều cơ bản: di chuyển byte mới là phần chậm. Mục tiêu là giữ traffic tệp lớn khỏi app server, kiểm soát retry, và tránh biến kiểm tra an toàn thành một hàng đợi không giới hạn.

Làm cho tệp lớn trở nên dự đoán được

Với tệp lớn, dùng multipart hoặc chunked uploads để kết nối yếu không buộc người dùng bắt đầu lại từ đầu. Các chunk cũng giúp bạn áp giới hạn rõ ràng: tổng kích thước tối đa, kích thước chunk tối đa, và thời gian upload tối đa.

Đặt timeout và retry cho client có chủ đích. Một vài retry cứu người dùng thật; retry vô hạn có thể làm tăng chi phí, nhất là trên mạng di động. Nhắm vào timeout ngắn cho mỗi chunk, số lần retry nhỏ, và deadline cứng cho toàn bộ upload.

Kiểm soát bước “tạo upload”

Signed URL giữ đường dữ liệu nặng nhanh, nhưng request tạo chúng vẫn là điểm nóng. Bảo vệ nó để giữ phản hồi nhanh:

• Rate-limit “create upload” theo user và theo IP
• Áp giới hạn kích thước trước khi cấp signed URL
• Giữ TTL ngắn để URL không dùng được nếu bỏ không
• Theo dõi upload đang tiến hành để một user không bắt đầu hàng trăm cùng lúc
• Dùng idempotency keys để refresh không tạo upload trùng lặp

Độ trễ cũng phụ thuộc địa lý. Giữ app, storage và worker quét cùng region khi có thể. Nếu cần hosting theo từng quốc gia vì tuân thủ, lên kế hoạch routing sớm để upload không phải đi vòng qua lục địa. Các nền tảng chạy trên AWS toàn cầu (như Koder.ai) có thể đặt workload gần người dùng khi cần lưu trú dữ liệu.

Cuối cùng, lên kế hoạch cho download, không chỉ upload. Phục vụ tệp bằng signed download URL và đặt quy tắc cache theo loại tệp và mức riêng tư. Asset công khai có thể cache lâu hơn; biên lai riêng tư nên có thời hạn ngắn và luôn kiểm tra quyền.

Ví dụ: hóa đơn và biên lai trong app nhiều người dùng

Hình dung một app doanh nghiệp nhỏ nơi nhân viên upload hóa đơn và ảnh biên lai, và quản lý phê duyệt để hoàn tiền. Đây là khi thiết kế upload trở nên thực tế: nhiều người dùng, ảnh lớn và tiền thật liên quan.

Luồng tốt dùng trạng thái rõ ràng để mọi người biết chuyện gì đang diễn ra và bạn có thể tự động hóa phần nhàm chán: tệp xuống storage và bạn lưu bản ghi gắn với user/workspace/expense; job nền quét tệp và trích metadata cơ bản (như MIME type thực); rồi mục được phê duyệt và dùng trong báo cáo, hoặc bị từ chối và chặn.

Người dùng cần phản hồi nhanh, cụ thể. Nếu tệp quá lớn, hiển thị giới hạn và kích thước hiện tại (ví dụ: “Tệp 18 MB. Giới hạn 10 MB.”). Nếu loại sai, nói rõ cho phép gì (“Tải PDF, JPG hoặc PNG”). Nếu quét thất bại, giữ thông báo bình tĩnh và hành động được (“Tệp này có thể không an toàn. Vui lòng tải bản sao khác.”).

Nhóm hỗ trợ cần dấu vết giúp gỡ lỗi mà không mở file: upload ID, user ID, workspace ID, timestamps cho created/uploaded/scan started/scan finished, mã kết quả (quá lớn, sai loại, quét thất bại, permission denied), cùng storage key và checksum.

Tải lại và thay thế thường xảy ra. Xử lý chúng như upload mới, gắn vào cùng expense như phiên bản mới, giữ lịch sử (ai thay thế và khi nào), và chỉ đánh dấu phiên bản mới nhất là active. Nếu bạn xây dựng app trên Koder.ai, điều này khớp rõ ràng với bảng uploads cộng bảng expense_attachments có trường version.

Sai lầm phổ biến và các sửa chữa dễ làm

Hầu hết bug upload không phải hack cầu kỳ. Chúng là các lối tắt nhỏ dần dần trở thành rủi ro khi traffic tăng.

Năm sai lầm hay gặp

• Tin vào kiểm tra phía client duy nhất. Sửa: validate lại phía server bằng byte thực (magic bytes) và áp giới hạn kích thước dựa trên metadata storage, không chỉ báo trình duyệt.
• Để signed URL tồn tại lâu. Sửa: giữ ngắn (vài phút), một mục đích, và scoped cho một object key. Rotate credentials và log mỗi lần cấp.
• Cho phép file tải về trước khi quét xong. Sửa: upload vào khu cách ly, quét bất đồng bộ, rồi chỉ promote hoặc serve sau khi sạch.
• Dùng tên hoặc đường dẫn do user cung cấp làm storage key. Sửa: sinh object key của bạn (UUID) và lưu filename gốc chỉ như metadata hiển thị.
• Bỏ qua kiểm tra quyền khi download. Sửa: coi download như quyết định riêng và kiểm tra lại ownership, membership workspace, và rules chia sẻ mỗi lần cấp download URL.

Sửa dễ giúp tránh tắc nghẽn

Nhiều kiểm tra hơn không nhất thiết làm uploads chậm. Tách đường nhanh và đường nặng.

Thực hiện kiểm tra nhanh đồng bộ (auth, kích thước, loại cho phép, rate limits), rồi giao quét và kiểm tra sâu cho worker nền. Người dùng có thể tiếp tục làm việc trong khi tệp từ “uploaded” chuyển sang “ready.” Nếu bạn xây dựng với builder dựa trên chat như Koder.ai, giữ tư duy giống nhau: endpoint upload nhỏ và chặt, và đẩy quét cùng xử lý hậu kỳ vào job.

Checklist nhanh và bước tiếp theo

Trước khi phát hành upload, định nghĩa “v1 đủ an toàn” là gì. Nhóm thường gặp rắc rối khi trộn quy tắc quá chặt (chặn người dùng thật) với thiếu quy tắc (mời gọi lạm dụng). Bắt đầu nhỏ, nhưng đảm bảo mỗi upload có đường đi rõ ràng từ “received” tới “được phép download.”

Checklist trước khi ra mắt:

• Áp giới hạn kích thước cứng sớm (trước khi chi phí storage phình ra)
• Dùng allowlist loại tệp, kiểm tra bằng nội dung (magic bytes), không chỉ tên tệp
• Khóa truy cập cho tới khi quét: đừng phục vụ tệp cho người khác trước khi quét xong
• Yêu cầu kiểm tra ủy quyền mỗi lần download
• Giữ log audit cho upload, kết quả quét và cố gắng download

Nếu cần chính sách tối thiểu, giữ đơn giản: giới hạn kích thước, allowlist loại hẹp, upload bằng signed URL, và “quarantine cho tới khi quét sạch.” Thêm tính năng đẹp sau (preview, nhiều loại hơn, reprocessing nền) khi đường chính ổn định.

Giám sát là thứ giữ cho “nhanh” không biến thành “bất ngờ chậm” khi bạn mở rộng. Theo dõi tỉ lệ lỗi upload (client vs server/storage), tỉ lệ lỗi quét và độ trễ quét, thời gian upload trung bình theo nhóm kích thước, từ chối ủy quyền khi download, và mẫu egress storage.

Chạy một bài test tải nhỏ với kích thước tệp thực tế và mạng thực tế (mạng di động khác Wi‑Fi văn phòng). Sửa timeout và retry trước khi ra mắt.

Nếu bạn triển khai trên Koder.ai (koder.ai), Planning Mode là nơi thực tế để map trạng thái upload và endpoint trước, rồi sinh backend và UI xung quanh luồng đó. Snapshot và rollback cũng hữu ích khi bạn tinh chỉnh giới hạn hoặc điều chỉnh quy tắc quét.