Quét virus cho tệp tải lên: các phương án kiến trúc cho ứng dụng

Vấn đề nói thẳng: tệp không an toàn lọt vào ứng dụng của bạn

Nếu ứng dụng của bạn cho phép người dùng tải tài liệu lên, bạn đang nhận những tệp mà chính bạn không tạo ra. Trong các sản phẩm nhiều tài liệu (portal khách hàng, hệ thống HR, ứng dụng khiếu nại, onboarding nhà cung cấp), việc tải lên diễn ra thường xuyên, và người dùng thường chia sẻ tệp từ email, ổ đám mây hoặc bên thứ ba. Điều đó biến các ứng dụng này thành mục tiêu thực tế: chỉ cần một lần tải thành công có thể lây lan qua nhiều lượt tải xuống.

Rủi ro không chỉ là "một con virus." Một file Word hay Excel có thể chứa macro độc hại, một PDF có thể được tạo để khai thác lỗi của trình đọc, và một "hóa đơn" có thể là tài liệu lừa đảo khiến người xem gọi số giả hoặc nhập thông tin. Một số tệp bị đầu độc tinh vi hơn, như giấu payload trong ZIP, dùng phần mở rộng kép (report.pdf.exe), hoặc nhúng nội dung từ xa khiến thiết bị gọi về khi mở.

Dựa vào một phần mềm diệt virus đơn giản trên một máy chủ là không đủ. Các upload có thể đến nhiều instance ứng dụng, di chuyển giữa hệ thống lưu trữ, hoặc được phục vụ từ object storage hay CDN. Nếu bất kỳ đường dẫn mã nào vô tình phơi bày tệp thô, người dùng có thể tải xuống trước khi quét xong. Cập nhật, cấu hình sai, và quyền admin tạm thời cũng có thể vô hiệu hóa quét theo thời gian.

Mục tiêu rõ ràng khi quét virus cho tệp tải lên là: không có tệp nào chưa được quét được phép tải xuống hoặc xem bởi bất kỳ ai mà không được phép rõ ràng để xem nội dung cách ly.

Định nghĩa "an toàn" nên là quy tắc kinh doanh, không phải cảm giác. Ví dụ:

• Phải vượt qua quét phần mềm độc hại với bộ chữ ký cập nhật
• Phù hợp với loại tệp và giới hạn kích thước được cho phép
• Chỉ được lưu trữ và phục vụ từ những vị trí được phê duyệt
• Có đường dẫn kiểm toán: ai đã upload, khi nào, và trạng thái cuối
• Bị chặn cho tới khi có quyết định cuối cùng: phát hành hay từ chối

Nếu bạn xây dựng trên nền tảng như AppMaster, hãy coi "scan status" là một trường quan trọng trong mô hình dữ liệu và đảm bảo mọi hành động tải xuống đều kiểm tra nó. Một cổng kiểm tra đơn giản như vậy ngăn ngừa nhiều sai sót đắt giá.

Quarantine thực sự có nghĩa là gì với tài liệu tải lên

"Quarantine" nên được hiểu như một trạng thái trong hệ thống của bạn, không chỉ là một thư mục trong lưu trữ. Ý tưởng chính đơn giản: tệp tồn tại, nhưng không ai có thể mở hoặc tải xuống nó cho tới khi ứng dụng ghi nhận kết quả quét rõ ràng. Đây là cốt lõi của việc quét virus cho tệp tải lên.

Quarantine thường vận hành như một vòng đời nhỏ với các trạng thái rõ ràng. Giữ trạng thái rõ ràng giúp khó vô tình rò rỉ nội dung không an toàn qua preview, URL trực tiếp, hoặc công việc xuất dữ liệu.

Một bộ trạng thái thực tế cho tệp có thể như sau:

• received (upload hoàn tất, chưa quét)
• scanning (được worker lấy để quét)
• clean (an toàn để phát hành)
• rejected (phát hiện mã độc hoặc vi phạm chính sách)
• failed (lỗi scanner, timeout, hoặc tệp bị hỏng)

Quarantine cũng cần metadata phù hợp để bạn có thể thực thi quyền truy cập và kiểm tra sau này. Tối thiểu, lưu: chủ sở hữu (user hoặc tổ chức), trạng thái, tên tệp gốc và loại, checksum (để dedupe và kiểm tra thay đổi), vị trí lưu trữ, và dấu thời gian (uploaded, scan started, scan finished). Nhiều nhóm còn lưu phiên bản scanner và chi tiết phán đoán quét.

Retention là quyết định về chính sách, nhưng nên có chủ ý. Giữ tệp trong quarantine chỉ trong thời gian cần để quét và gỡ lỗi. Giữ ngắn giảm rủi ro và chi phí, nhưng vẫn cần đủ thời gian để điều tra sự cố và hỗ trợ người dùng hỏi "tệp tải lên của tôi đâu rồi?".

Cuối cùng, quyết định xử lý những tệp không bao giờ hoàn thành quét. Đặt thời hạn quét tối đa và timestamp "hết hạn". Khi quá hạn, chuyển tệp sang failed, chặn truy cập, và tự động thử lại một số lần có giới hạn hoặc xóa nó và yêu cầu người dùng tải lại.

Mẫu lưu trữ tạm thời giảm rủi ro

Lưu trữ tạm thời là nơi hầu hết vấn đề upload xảy ra. Tệp đã ở trong hệ thống nhưng bạn chưa biết nó có an toàn hay không, nên cần nơi dễ khóa và khó bị phơi bày vô tình.

Đĩa local có thể dùng cho một máy chủ đơn, nhưng dễ bị lỗi. Khi scale lên nhiều app server, bạn phải chia sẻ lưu trữ, sao chép tệp, và giữ quyền nhất quán. Object storage (như bucket kiểu S3 hoặc container cloud) thường an toàn hơn cho ứng dụng nhiều tài liệu vì quy tắc truy cập tập trung và log rõ ràng.

Mẫu đơn giản cho quét virus của tệp tải lên là tách "quarantine" khỏi "clean" storage. Bạn có thể dùng hai bucket/container, giảm khả năng sai sót, hoặc dùng prefix nghiêm ngặt trong một bucket để tiết kiệm và dễ quản lý.

Nếu dùng prefix, hãy làm cho chúng không thể nhầm lẫn. Ưu tiên layout như quarantine/<tenant_id>/<upload_id> và clean/<tenant_id>/<document_id>, không dùng tên do user cung cấp. Không bao giờ tái dùng cùng một đường dẫn cho các trạng thái khác nhau.

Giữ các quy tắc này trong đầu:

• Không cho phép đọc công khai trên quarantine, kể cả tạm thời.
• Sinh tên đối tượng phía server, không dùng tên client.
• Phân vùng theo tenant hoặc account để giảm ảnh hưởng khi sự cố.
• Lưu metadata (owner, status, checksum) trong cơ sở dữ liệu, không trong tên tệp.

Mã hóa khi nghỉ (encrypt at rest), và nghiêm ngặt về ai có thể giải mã. API upload chỉ có thể ghi vào quarantine, scanner chỉ có thể đọc từ quarantine và ghi vào clean, và ứng dụng phục vụ công khai chỉ đọc từ clean. Nếu cloud hỗ trợ chính sách key, gán quyền giải mã vào tập các role nhỏ nhất có thể.

Các tệp lớn cần chú ý thêm. Với multipart upload, không đánh dấu đối tượng "sẵn sàng" cho tới khi phần cuối cùng được commit và bạn đã ghi kích thước và checksum mong đợi. Cách an toàn thường thấy là upload từng phần vào quarantine, sau khi quét vượt qua thì copy hoặc promote đối tượng sang clean.

Ví dụ: Trong portal khách hàng xây bằng AppMaster, bạn có thể xử lý mọi upload là "pending", lưu vào bucket quarantine, và chỉ hiện nút tải xuống sau khi trạng thái quét chuyển sang "clean".

Tùy chọn kiến trúc: quét ngay (inline) so với quét nền (background)

Khi thêm quét virus cho tệp tải lên, bạn thường chọn giữa hai luồng: quét inline (người dùng chờ) hoặc quét nền (app chấp nhận upload nhưng chặn truy cập cho tới khi cleared). Lựa chọn phù hợp phụ thuộc ít hơn vào "mức độ bảo mật" (cả hai đều có thể an toàn) và nhiều hơn vào tốc độ, độ tin cậy, và tần suất upload.

Phương án 1: Quét inline (người dùng chờ)

Quét inline nghĩa là request upload chưa hoàn tất cho tới khi scanner trả kết quả. Cảm giác đơn giản vì chỉ một bước: upload, quét, chấp nhận hoặc từ chối.

Quét inline thường chấp nhận được khi tệp nhỏ, upload ít, và bạn giữ thời gian chờ dự đoán được. Ví dụ, công cụ nội bộ nơi người dùng upload vài PDF mỗi ngày có thể chịu được pause 3–10 giây. Nhược điểm là quét chậm làm app chậm. Timeout, retry, và mạng di động có thể biến tệp sạch thành trải nghiệm tồi.

Phương án 2: Quét nền (async)

Quét bất đồng bộ lưu tệp trước, đánh dấu là "quarantined", và đẩy một job vào hàng đợi quét. Người dùng nhận phản hồi nhanh "đã nhận upload", nhưng không thể tải xuống hoặc xem trước cho tới khi được phép.

Cách này phù hợp hơn với khối lượng lớn, tệp lớn, và giờ cao điểm vì phân phối công việc và giữ app phản hồi. Nó cũng cho phép bạn scale worker quét riêng khỏi server web/API chính.

Một hybrid thực tế là: chạy kiểm tra nhanh inline (allowlist loại tệp, giới hạn kích thước, xác thực định dạng cơ bản), rồi làm quét antivirus đầy đủ ở nền. Điều này bắt các vấn đề hiển nhiên sớm mà không buộc mọi người phải chờ lâu.

Gợi ý chọn:

• Tệp nhỏ, khối lượng thấp, quy trình cần biết ngay: quét inline
• Tệp lớn, nhiều upload, hoặc thời gian quét không đoán trước: quét nền
• SLA chặt cho độ phản hồi upload: quét nền + UI trạng thái rõ ràng
• Khối lượng hỗn hợp: hybrid (kiểm tra nhanh trước, quét đầy đủ async)

Nếu bạn xây với AppMaster, lựa chọn này thường map rõ ràng tới endpoint đồng bộ (inline) hoặc một Business Process đặt job quét và cập nhật trạng thái khi có kết quả.

Bước từng bước: xây hàng đợi quét bất đồng bộ

Quét async nghĩa là bạn chấp nhận upload, khóa trong quarantine, và quét nền. Người dùng không được truy cập cho tới khi scanner xác nhận an toàn. Đây thường là kiến trúc quét phần mềm độc hại thực tế cho ứng dụng nhiều tài liệu.

1) Định nghĩa message hàng đợi (giữ nhỏ)

Xử hàng đợi như một danh sách việc cần làm. Mỗi upload tạo một message trỏ tới file, không phải chứa file.

Message đơn giản thường gồm:

• File ID (hoặc object key) và tenant hoặc project ID
• Uploaded-by user ID
• Timestamp upload và checksum (tuỳ chọn nhưng hữu ích)
• Số lần thử (attempt number) hoặc counter retry riêng

Tránh đặt raw bytes vào hàng đợi. Payload lớn có thể vượt giới hạn, tốn kém, và tăng mức phơi bày.

2) Xây luồng worker (fetch, scan, record)

Worker kéo message, lấy file từ quarantine storage, quét, rồi ghi lại quyết định.

Luồng rõ ràng:

• Lấy file theo ID từ quarantine storage (bucket private hoặc volume private)
• Chạy scanner (engine AV hoặc dịch vụ quét)
• Ghi kết quả vào database: status (clean, infected, error), tên/phiên bản scanner, và timestamp
• Nếu clean: chuyển file sang approved storage hoặc bật flag truy cập để có thể tải xuống
• Nếu infected: giữ trong quarantine (hoặc xóa) và thông báo cho người phụ trách

3) Làm idempotent (an toàn khi xử lý lại)

Worker sẽ crash, message có thể được gửi hai lần, và retry xảy ra. Thiết kế để quét cùng tệp nhiều lần không gây hại. Dùng nguồn chân lý duy nhất như files.status và chỉ cho phép chuyển trạng thái hợp lệ, ví dụ: uploaded -> scanning -> clean/infected/error. Nếu worker thấy clean, nó nên dừng và acknowledge message.

4) Kiểm soát concurrency (tránh bão quét)

Đặt giới hạn cho worker và per-tenant. Hạn chế số quét cùng lúc, và cân nhắc queue riêng cho tệp lớn. Điều này ngăn một khách hàng bận rộn tiêu thụ hết tài nguyên scanner.

5) Xử lý lỗi với retry và audit trail

Dùng retry cho lỗi tạm thời (timeout scanner, sự cố mạng) với số lần tối đa nhỏ. Sau đó, gửi message vào dead-letter queue để xem xét thủ công.

Giữ audit trail: ai upload, khi nào vào quarantine, scanner nào chạy, quyết định thế nào, và ai phê duyệt hoặc xóa tệp. Log này quan trọng ngang với việc quét virus cho tệp tải lên, đặc biệt với portal khách hàng và tuân thủ.

Kiểm soát truy cập: giữ tệp trong quarantine thật sự riêng tư

Quarantine không chỉ là một trường trong DB. Nó là một cam kết rằng không ai mở tệp cho tới khi chứng minh an toàn. Quy tắc an toàn nhất là: không bao giờ phục vụ tệp đang quarantine qua URL công khai, kể cả tạm thời.

Luồng download tốt là nhàm chán và nghiêm ngặt. Ứng dụng nên xử mỗi download như một hành động được bảo vệ, không phải như lấy một ảnh.

1. Yêu cầu tải xuống
2. Kiểm tra quyền của user với tệp cụ thể
3. Kiểm tra trạng thái tệp (quarantined, clean, rejected)
4. Chỉ cung cấp file nếu trạng thái là clean

Nếu dùng signed URLs, giữ nguyên tắc: tạo chúng chỉ sau khi kiểm tra quyền và trạng thái, và làm cho thời hạn rất ngắn. Thời hạn ngắn giảm thiệt hại nếu link bị lộ qua log, screenshot, hoặc email chuyển tiếp.

Phân quyền theo vai trò giúp tránh logic "trường hợp đặc biệt" thành lỗ hổng. Vai trò phổ biến cho ứng dụng nhiều tài liệu:

• Uploader: xem upload của chính họ và trạng thái quét
• Reviewer: xem file clean, và đôi khi xem file quarantine chỉ trong công cụ review an toàn
• Admin: điều tra, quét lại, và ghi đè truy cập khi cần
• External user: chỉ truy cập tài liệu được chia rõ ràng

Cũng bảo vệ chống đoán ID. Không phơi IDs tăng dần như 12345. Dùng ID mập mờ, và luôn authorize theo user và file (không chỉ "bất cứ user đã đăng nhập"). Ngay cả khi bucket storage private, endpoint API cẩu thả vẫn có thể lộ nội dung cách ly.

Khi xây quét virus cho tệp tải lên, lớp truy cập là nơi hầu hết lỗi thực tế xảy ra. Trên nền tảng như AppMaster, bạn nên áp các kiểm tra này trong endpoint API và logic nghiệp vụ trước khi tạo bất kỳ phản hồi tải xuống nào, để quarantine mặc định là riêng tư.

Phát hành, từ chối và thử lại: xử lý kết quả quét

Khi tệp hoàn tất quét, điều quan trọng nhất là đưa nó vào một trạng thái rõ ràng và làm cho bước tiếp theo dự đoán được. Nếu xây hệ thống quét virus cho tệp tải lên, coi kết quả quét như chiếc cổng: không có gì được tải xuống cho tới khi cổng mở.

Một tập kết quả đơn giản đáp ứng hầu hết:

• Clean: phát hành file từ quarantine và cho phép truy cập bình thường.
• Infected: chặn truy cập vĩnh viễn và kích hoạt quy trình xử lý file nhiễm.
• Unsupported: scanner không đánh giá được loại này (hoặc tệp có mật khẩu). Giữ chặn.
• Scan error: lỗi tạm thời (timeout, service unavailable). Giữ chặn.

Thông điệp tới người dùng nên rõ ràng và bình tĩnh. Tránh câu chữ gây hoảng sợ như "Tài khoản của bạn bị xâm phạm." Cách tốt hơn: "Tệp đang được kiểm tra. Bạn có thể tiếp tục làm việc." Nếu tệp bị chặn, cho biết bước tiếp theo: "Tải tệp khác" hoặc "Thử lại sau." Với tệp không hỗ trợ, cụ thể hóa (ví dụ, "Kho lưu trữ được mã hóa/đặt mật khẩu không thể quét").

Với tệp nhiễm, quyết định sớm là xóa hay giữ. Xóa đơn giản và giảm rủi ro. Giữ lại giúp audit, nhưng chỉ khi lưu ở vùng cách ly hoàn toàn với quyền truy cập nghiêm ngặt và thời gian lưu ngắn, và bạn ghi lại ai có thể xem (lý tưởng là không ai ngoài admin bảo mật).

Retry hữu ích nhưng chỉ cho lỗi có thể tạm thời. Đặt chính sách retry nhỏ để không tích tụ backlog vô tận:

• Retry khi timeout và scanner downtime.
• Không retry khi kết luận là infected hoặc unsupported.
• Giới hạn số retry (ví dụ 3) rồi đánh dấu failed.
• Thêm backoff giữa các lần để tránh quá tải.

Cuối cùng, coi lỗi lặp lại là vấn đề ops, không phải vấn đề người dùng. Nếu nhiều tệp vào "scan error" trong khoảng thời gian ngắn, cảnh báo đội ngũ và tạm dừng phát hành mới. Trên AppMaster bạn có thể mô tả các trạng thái này trong DB và chuyển thông báo qua module messaging để người phụ trách biết sớm.

Kịch bản ví dụ: portal khách hàng với nhiều tài liệu

Portal khách hàng cho phép client upload hóa đơn và hợp đồng cho từng dự án. Đây là nơi quét virus cho tệp tải lên rất quan trọng, vì người dùng sẽ kéo bất cứ thứ gì trên desktop, kể cả tệp nhận từ người khác.

Khi khách hàng upload một PDF, portal lưu nó vào vị trí tạm riêng và tạo bản ghi DB với trạng thái Pending scan. File chưa được hiển thị để tải xuống. Một worker quét kéo file từ hàng đợi, quét, rồi cập nhật bản ghi thành Clean hoặc Blocked.

Trong UI, khách hàng thấy tài liệu xuất hiện ngay, nhưng có badge Pending rõ ràng. Tên tệp và kích thước hiển thị để họ biết upload thành công, nhưng nút Download bị vô hiệu cho tới khi quét clean. Nếu quét lâu, portal có thể hiện thông báo: "Chúng tôi đang kiểm tra tệp này. Thử lại sau 1 phút."

Nếu scanner đánh dấu tài liệu, khách hàng thấy trạng thái Blocked với ghi chú ngắn, không kỹ thuật: "Tệp này không vượt qua kiểm tra bảo mật." Support và admin có view riêng gồm lý do quét và hành động tiếp theo. Họ có thể:

• giữ chặn và yêu cầu upload lại
• xóa và ghi lý do
• đánh dấu là false positive nếu chính sách cho phép

Trong tranh chấp ("Tôi đã upload hôm qua mà các bạn mất"), log tốt quan trọng. Giữ timestamp upload received, scan started, scan finished, status changed, và ai đã thao tác. Lưu cả hash tệp, tên gốc, tài khoản uploader, IP, và mã kết quả scanner. Nếu xây trên AppMaster, Data Designer và Business Process flow có thể quản lý trạng thái và trường audit mà không phơi bày quarantine cho người dùng thường.

Sai lầm phổ biến gây lỗ hổng thực tế

Hầu hết lỗi bảo mật upload không phải là hack cao siêu. Là các lựa chọn thiết kế nhỏ vô tình khiến tệp không an toàn hoạt động như tài liệu bình thường.

Một vấn đề kinh điển là race: app chấp nhận upload, trả URL tải xuống, và user (hoặc dịch vụ khác) tải file trước khi quét xong. Khi quét tệp, coi "uploaded" và "available" là hai trạng thái khác nhau.

Những sai lầm lặp lại:

• Trộn file clean và quarantined trong cùng bucket/folder rồi dựa vào quy ước tên. Một quyền sai hoặc đoán đường dẫn có thể làm vô nghĩa quarantine.
• Tin tưởng phần mở rộng file, MIME type hoặc kiểm tra phía client. Kẻ tấn công có thể đổi tên thành .pdf và UI của bạn vẫn hiển thị bình thường.
• Không lường trước downtime của scanner. Nếu scanner chậm hoặc offline, file có thể nằm mãi ở pending và team bắt đầu dùng thao tác ghi đè không an toàn.
• Cho phép worker nền bỏ qua cùng các quy tắc ủy quyền như API chính. Worker có thể là con đường leo thang quyền thầm lặng.
• Công bố ID dễ đoán (tăng dần) cho mục quarantine, dù bạn nghĩ nội dung được bảo vệ.

Kiểm thử cũng là một lỗ hổng. Nhóm thử với vài file nhỏ sạch và nghĩ xong. Bạn cần thử tệp lớn, bị hỏng, và tài liệu có mật khẩu vì đó là nơi scanner và parser thường fail hoặc timeout.

Ví dụ thực tế: một user upload "contract.pdf" nhưng thực tế là executable đổi tên trong một archive. Nếu portal phục vụ lại ngay lập tức, hoặc support có thể truy cập quarantine mà không kiểm soát, bạn đã tạo đường dẫn giao hàng trực tiếp cho người dùng khác.

Checklist nhanh trước khi phát hành

Trước khi đưa quét virus cho tệp tải lên vào production, rà soát những chỗ mà teams thường nghĩ "ổn rồi" nhưng sau đó phát hiện không ổn. Mục tiêu đơn giản: tệp không an toàn không bao giờ trở nên có thể đọc chỉ vì ai đó đoán URL, thử lại request, hoặc dùng link cũ trong cache.

Bắt đầu từ luồng người dùng. Mọi hành động download, preview, hoặc "mở file" nên kiểm tra lại trạng thái quét hiện tại tại thời điểm yêu cầu, không chỉ khi upload. Điều này bảo vệ khỏi race condition (ai đó bấm ngay), kết quả quét bị chậm, và trường hợp tệp được quét lại.

Dưới đây là checklist tiền phát hành tối thiểu:

• Quarantine storage mặc định private: không có public bucket access, không "bất kỳ ai có link", và không phục vụ trực tiếp từ raw object storage.
• Mỗi bản ghi tệp có owner (user, team, hoặc tenant) cùng lifecycle state rõ ràng như pending, clean, infected, hoặc failed.
• Hàng đợi quét và worker có retry giới hạn, backoff rõ ràng, và cảnh báo khi item bị kẹt hoặc fail lặp lại.
• Log audit cho upload, kết quả quét, và nỗ lực tải xuống (kể cả bị chặn), với ai, khi nào, và lý do.
• Có cơ chế ghi đè thủ công cho trường hợp hiếm, nhưng chỉ admin, được ghi lại và giới hạn thời gian (không có nút "mark clean" lặng lẽ).

Cuối cùng, đảm bảo bạn quan sát được hệ thống end-to-end. Bạn nên trả lời được: "Hiện có bao nhiêu file đang pending scan?" và "Tenant nào đang gặp lỗi?" Nếu xây trên AppMaster, mô hình vòng đời tệp trong Data Designer và thực thi kiểm tra trạng thái trong Business Process Editor giúp duy trì quy tắc nhất quán trên web và mobile.

Bước tiếp theo: biến thiết kế thành ứng dụng hoạt động

Bắt đầu bằng ghi lại các trạng thái tệp chính xác và mỗi trạng thái cho phép gì. Giữ đơn giản và rõ ràng: "uploaded", "queued", "scanning", "clean", "infected", "scan_failed". Sau đó thêm quy tắc truy cập cạnh mỗi trạng thái. Ai có thể xem file, tải xuống, hoặc xóa khi file chưa được tin cậy?

Tiếp theo, chọn phương án phù hợp với khối lượng và mục tiêu trải nghiệm người dùng. Quét inline dễ giải thích nhưng có thể làm upload chậm. Quét async scale tốt hơn cho ứng dụng nhiều tài liệu nhưng cần state, queue, và UI "pending".

Cách thực tế để đi từ thiết kế đến xây dựng là prototype toàn bộ luồng end-to-end bằng tài liệu thực tế (PDF, Office, hình ảnh, archive) và hành vi người dùng thực tế (nhiều upload, huỷ, retry). Đừng dừng lại ở "scanner chạy ok". Xác nhận rằng ứng dụng không bao giờ phục vụ file đang quarantine, ngay cả vô tình.

Kế hoạch xây dựng 1 tuần mẫu:

• Định nghĩa trạng thái tệp, chuyển trạng thái, và quy tắc truy cập trong một trang
• Chọn inline, async, hoặc hybrid và ghi lại đánh đổi
• Triển khai upload -> quarantine storage -> scan job -> callback kết quả, kèm audit log
• Xây UI cho các trạng thái người dùng sẽ thấy (pending, blocked, failed, approved)
• Thêm monitoring từ ngày đầu: kích thước backlog, tỷ lệ lỗi, và thời gian tới khi clean

Nếu bạn xây không code, AppMaster có thể giúp bạn mô hình metadata tệp (status, owner, checksum, timestamps), dựng màn upload và review, và điều phối luồng quét với business logic và xử lý theo kiểu hàng đợi. Điều đó cho phép bạn kiểm thử luồng sản phẩm thực tế sớm, rồi gia cố những phần quan trọng: quyền, tách lưu trữ, và retry đáng tin cậy.

Cuối cùng, xác định con số cho "tốt": đặt ngưỡng cảnh báo trước khi launch để bạn phát hiện scan bị kẹt và lỗi tăng trước người dùng.