Skanowanie wirusów przy przesyłaniu plików: opcje architektury dla aplikacji

Problem w prostych słowach: niebezpieczne pliki trafiają do Twojej aplikacji

Jeśli Twoja aplikacja pozwala użytkownikom przesyłać dokumenty, przyjmujesz pliki, których nie stworzyłeś. W produktach intensywnie operujących dokumentami (portale klientów, systemy HR, aplikacje roszczeń, onboarding dostawców) przesyłania są częste, a użytkownicy często udostępniają pliki z wątków e-mail, dysków współdzielonych lub od stron trzecich. To czyni takie aplikacje praktycznym celem: jedno udane przesłanie może rozprzestrzenić się na wiele pobrań.

Ryzyka to nie tylko „wirus”. Plik Word lub Excel może zawierać złośliwe makra, PDF może być spreparowany tak, by wykorzystać błędy czytnika, a „faktura” może być dokumentem phishingowym, który nakłoni kogoś do zadzwonienia pod fałszywy numer lub podania danych. Niektóre pliki są „zatrute” w bardziej subtelny sposób, np. ukrywając ładunek w ZIP, używając podwójnych rozszerzeń (report.pdf.exe) lub osadzając zdalne treści, które łączą się z siecią przy otwarciu.

Poleganie na prostym antywirusie zainstalowanym na jednym serwerze to za mało. Przesyłania mogą trafiać do wielu instancji aplikacji, przechodzić między systemami storage lub być serwowane z obiektowego storage lub CDN. Jeśli którakolwiek ścieżka kodu przypadkowo udostępni surowy plik, użytkownicy mogą go pobrać zanim skan się zakończy. Aktualizacje, błędne konfiguracje i tymczasowe dostępy administratorów także mogą z czasem omijać skanowanie.

Jasny cel skanowania wirusów przy przesyłaniu plików jest prosty: żaden nieskanowany plik nie powinien być nigdy możliwy do pobrania lub obejrzenia przez kogokolwiek, kto nie ma wyraźnego uprawnienia do przeglądu zawartości kwarantanny.

Zdefiniuj, co oznacza „bezpieczny” jako regułę biznesową, a nie odczucie. Na przykład:

• Musi przejść skan antywirusowy z aktualnym zestawem sygnatur
• Musi odpowiadać dozwolonym typom plików i limitom rozmiaru
• Musi być przechowywany i udostępniany tylko z zatwierdzonych lokalizacji
• Musi mieć ślad audytowy: kto przesłał, kiedy i jaki był wynik końcowy
• Musi być zablokowany aż do ostatecznej decyzji: zwolnić lub odrzucić

Jeśli budujesz na platformie takiej jak AppMaster, traktuj „status skanowania” jako pole pierwszej klasy w modelu danych i spraw, by każda akcja pobrania go weryfikowała. Ta jedna bramka zapobiega wielu kosztownym błędom.

Co naprawdę oznacza kwarantanna dla przesłanych dokumentów

„Kwarantanna” najlepiej rozumiana jest jako stan w systemie, nie tylko jako folder w storage. Kluczowa idea jest prosta: plik istnieje, ale nikt nie może go otworzyć ani pobrać, dopóki aplikacja nie ma jasnego, zapisanego wyniku skanowania. To sedno skanowania wirusów przy przesyłaniu plików.

Kwarantanna zwykle działa jako niewielki cykl życia ze zrozumiałymi statusami. Jawne przechowywanie stanu utrudnia przypadkowe wycieki niebezpiecznej zawartości przez podgląd, bezpośredni URL czy zadanie eksportu.

Praktyczny zestaw stanów pliku wygląda tak:

• odebrany (upload zakończony, jeszcze nie zeskanowany)
• skanowanie (wybrany przez worker)
• czysty (można zwolnić)
• odrzucony (wykryto malware lub naruszenie polityki)
• niepowodzenie (błąd skanera, timeout lub uszkodzony plik)

Kwarantanna potrzebuje też odpowiednich metadanych, abyś później mógł egzekwować dostęp i audytować zdarzenia. Co najmniej przechowuj: właściciela (użytkownik lub organizacja), status, oryginalną nazwę pliku i typ, checksum (do deduplikacji i kontroli modyfikacji), lokalizację przechowywania oraz znaczniki czasu (przesłano, skan rozpoczęty, skan zakończony). Wiele zespołów dodatkowo zapisuje wersję skanera i szczegóły verdictu.

Retencja to decyzja polityczna, ale powinna być przemyślana. Przechowuj pliki w kwarantannie tylko tak długo, jak potrzebujesz do skanowania i debugowania błędów. Krótsza retencja zmniejsza ryzyko i koszty, ale nadal potrzebujesz czasu na zbadanie incydentów i wsparcie użytkowników, którzy pytają „gdzie jest mój upload?”.

Na koniec zdecyduj, co robić z plikami, które nigdy nie kończą skanowania. Ustaw maksymalny czas skanu i znacznik „wygaśnięcia”. Po przekroczeniu terminu przenieś plik do stanu niepowodzenia, zablokuj dostęp i albo spróbuj ponownie automatycznie ograniczoną liczbę razy, albo usuń go i poproś użytkownika o ponowne przesłanie.

Wzorce tymczasowego przechowywania, które zmniejszają ryzyko

To w tym miejscu pojawiają się największe problemy. Plik jest w Twoim systemie, ale jeszcze nie wiesz, czy jest bezpieczny, więc potrzebujesz miejsca, które łatwo zablokować i trudno przypadkowo ujawnić.

Dysk lokalny może działać na jednym serwerze, ale jest kruchy. Jeśli skalujesz do wielu serwerów aplikacji, musisz współdzielić storage, kopiować pliki i utrzymywać spójne uprawnienia. Object storage (np. bucket w stylu S3 lub kontener chmurowy) jest często bezpieczniejszy dla aplikacji operujących dużą liczbą dokumentów, ponieważ reguły dostępu są scentralizowane, a logi bardziej przejrzyste.

Prosty wzorzec skanowania polega na oddzieleniu „kwarantanny” od „czystego” storage. Możesz to zrobić dwoma bucketami/kontenerami, co zmniejsza ryzyko pomyłek, albo jednym bucketem z wyraźnymi prefiksami, co może być tańsze i łatwiejsze w zarządzaniu.

Jeśli używasz prefiksów, spraw, by były niemożliwe do pomylenia. Preferuj układ jak quarantine/<tenant_id>/<upload_id> i clean/<tenant_id>/<document_id>, a nie nazwy dostarczone przez użytkownika. Nigdy nie używaj tego samego path dla różnych stanów.

Pamiętaj o zasadach:

• Nie pozwalaj na publiczne odczyty w kwarantannie, nawet „tymczasowo”.
• Generuj nazwy obiektów po stronie serwera, nie klienta.
• Dziel według tenantów lub kont, aby zmniejszyć blast radius.
• Przechowuj metadane (właściciel, status, checksum) w bazie danych, nie w nazwie pliku.

Szyfruj dane spoczynku i bądź restrykcyjny co do tego, kto może odszyfrować. API uploadu powinno mieć możliwość zapisu do kwarantanny, skaner powinien mieć prawo odczytu z kwarantanny i zapisu do czystego storage, a część publiczna aplikacji powinna czytać jedynie z czystego storage. Jeśli chmura obsługuje polityki kluczy, powiąż prawa odszyfrowania z najmniejszym możliwym zestawem ról.

Duże pliki wymagają dodatkowej ostrożności. Przy multi-part uploadach nie oznaczaj obiektu jako „gotowego” dopóki ostatnia część nie zostanie zatwierdzona i nie zanotujesz oczekiwanego rozmiaru oraz checksumy. Bezpieczne podejście to przesyłanie części do kwarantanny, a po przejściu skanu kopiowanie lub promowanie obiektu do czystego storage.

Przykład: w portalu klienta zbudowanym na AppMaster każdy upload możesz traktować jako „oczekujący”, zapisać go w bucketcie kwarantanny i pokazywać przycisk pobrania dopiero po zmianie statusu na „czysty”.

Opcje architektury: skanowanie inline kontra w tle

Planując skanowanie wirusów przy przesyłaniu plików, zwykle wybierasz między dwoma przepływami: skan inline (użytkownik czeka) albo skan w tle (aplikacja akceptuje plik, ale blokuje dostęp do czasu potwierdzenia). Wybór zależy raczej od szybkości, niezawodności i częstotliwości przesyłania niż od „poziomu bezpieczeństwa” (oba mogą być bezpieczne).

Opcja 1: Skanowanie inline (użytkownik czeka)

Skan inline oznacza, że żądanie uploadu nie kończy się, dopóki skaner nie zwróci wyniku. Wydaje się proste, bo jest tylko jeden krok: upload, skan, akceptacja lub odrzucenie.

Skan inline jest zwykle akceptowalny, gdy pliki są małe, przesyłania rzadkie i czas oczekiwania przewidywalny. Na przykład narzędzie wewnętrzne, gdzie użytkownicy wrzucają kilka PDF dziennie, może tolerować przerwę 3–10 sekund. Minusem jest to, że wolny skan powoduje wolną aplikację. Timeouty, retry i sieci mobilne mogą pogorszyć doświadczenie.

Opcja 2: Skanowanie w tle (asynchroniczne)

Skan asynchroniczny najpierw zapisuje plik, oznacza go jako „w kwarantannie” i wrzuca zadanie do kolejki skanowania. Użytkownik dostaje szybkie potwierdzenie „upload odebrano”, ale nie może pobrać ani podejrzeć pliku, dopóki nie zostanie on zwolniony.

To podejście lepiej sprawdza się przy dużej liczbie plików, większych rozmiarach i w godzinach szczytu, bo rozkłada pracę i utrzymuje responsywność aplikacji. Pozwala też skalować workerów skanu niezależnie od serwerów web/API.

Praktyczny hybryd to: wykonaj szybkie kontrole inline (allowlist typów plików, limity rozmiaru, podstawowa walidacja formatu), a pełny skan AV rób w tle. To wychwytuje oczywiste problemy bez opóźniania wszystkich użytkowników.

Prosta zasada wyboru:

• Małe pliki, niska liczba przesłań, wymaganie „musimy wiedzieć od razu”: skan inline
• Duże pliki, dużo uploadów lub nieprzewidywalny czas skanowania: skan w tle
• Ścisłe SLA dla responsywności uploadu: skan w tle + jasne UI statusu
• Mieszane obciążenia: hybryda (szybkie kontrole najpierw, pełny skan asynchronicznie)

Jeśli budujesz na AppMaster, wybór ten często mapuje się na synchroniczny endpoint API (inline) lub Business Process, który umieszcza zadanie w kolejce i aktualizuje status pliku po otrzymaniu wyniku.

Krok po kroku: budowa asynchronicznej kolejki skanów

Skan asynchroniczny oznacza, że akceptujesz upload, zabezpieczasz go w kwarantannie i skanujesz w tle. Użytkownicy nie mają dostępu, dopóki skaner nie potwierdzi bezpieczeństwa. To zazwyczaj najbardziej praktyczna architektura skanowania malware dla aplikacji z dużą liczbą dokumentów.

1) Zdefiniuj wiadomość kolejki (trzymaj ją małą)

Traktuj kolejkę jako listę rzeczy do zrobienia. Każdy upload tworzy jedną wiadomość wskazującą plik, nie plik jako taki.

Prosta wiadomość zwykle zawiera:

• ID pliku (lub klucz obiektu) oraz ID tenant lub projektu
• ID użytkownika, który przesłał
• Znacznik czasu przesłania i checksum (opcjonalne, ale pomocne)
• Numer próby (lub oddzielny licznik retry)

Unikaj pakowania surowych bajtów w wiadomości. Duże ładunki mogą przekroczyć limity, kosztować więcej i zwiększać ekspozycję.

2) Zbuduj flow workera (pobierz, zeskanuj, zapisz)

Worker pobiera wiadomość, pobiera plik z storage kwarantanny, skanuje go, a następnie zapisuje decyzję.

Jasny przebieg to:

• Pobierz plik po ID z kwarantanny (prywatny bucket lub prywatny wolumen)
• Uruchom skaner (silnik AV lub usługa skanująca)
• Zapisz wynik w bazie danych: status (czysty, zainfekowany, błąd), nazwa/wersja skanera i znaczniki czasu
• Jeśli czysty: przenieś plik do zatwierdzonego storage albo ustaw flagę dostępu, by stał się możliwy do pobrania
• Jeśli zainfekowany: trzymaj w kwarantannie (lub usuń) i powiadom odpowiednie osoby

3) Zapewnij idempotentność (bezpieczne ponowne przetwarzanie)

Workery będą padać, wiadomości będą dostarczane dwukrotnie, retry będą się zdarzać. Projektuj tak, aby ponowne skanowanie tego samego pliku nie powodowało szkód. Użyj pojedynczego źródła prawdy, np. files.status, i pozwól tylko na prawidłowe przejścia stanów, na przykład: przesłano -> skanowanie -> czysty/zainfekowany/blad. Jeśli worker widzi status czysty, powinien zakończyć pracę i potwierdzić wiadomość.

4) Kontroluj współbieżność (unikaj „skanowych burz”)

Ustaw limity na workera i na tenant. Ogranicz liczbę skanów równocześnie i rozważ oddzielne kolejki dla dużych plików. To zapobiega sytuacji, w której jeden aktywny klient pochłania całą pojemność skanera.

5) Obsługuj błędy retryami i audytem

Używaj retry dla błędów tymczasowych (timeout skanera, problem z siecią) z niewielką maksymalną liczbą prób. Po przekroczeniu limitu wyślij wiadomość do dead-letter queue do ręcznego przeglądu.

Prowadź ślad audytu: kto przesłał dokument, kiedy trafił do kwarantanny, który skaner uruchomiono, jaka była decyzja i kto zatwierdził lub usunął plik. Ten log jest równie ważny jak samo skanowanie, szczególnie w portalach klientów i w kontekście compliance.

Kontrola dostępu: jak uczynić kwarantannę naprawdę prywatną

Kwarantanna to nie tylko status w bazie. To obietnica, że nikt nie otworzy pliku, dopóki nie udowodnimy, że jest bezpieczny. Najbezpieczniejsza zasada jest prosta: nigdy nie serwuj plików z kwarantanny przez publiczne URL, nawet „tymczasowe”.

Dobry flow pobierania jest nudny i restrykcyjny. Aplikacja powinna traktować każde pobranie jak akcję chronioną, a nie jak pobranie obrazka.

Przykładowy, bezpieczny przepływ:

1. Żądanie pobrania
2. Sprawdź uprawnienia użytkownika do tego konkretnego pliku
3. Sprawdź status pliku (kwarantanna, czysty, odrzucony)
4. Dostarcz plik tylko jeśli status to czysty

Jeśli używasz podpisanych URL, zachowaj tę samą ideę: generuj je tylko po weryfikacji uprawnień i statusu, i ustaw krótki czas życia. Krótkie wygaśnięcie zmniejsza szkody, jeśli link wycieknie przez logi, zrzut ekranu lub przekazaną wiadomość.

Dostęp oparty na rolach pomaga unikać „specjalnych przypadków” logiki, które z czasem stają się dziurami. Typowe role w aplikacjach dokumentowych to:

• Wysyłający: widzi swoje przesyłania i ich statusy skanów
• Recenzent: może przeglądać czyste pliki, a czasem podejrzeć pliki w kwarantannie tylko w bezpiecznym narzędziu przeglądowym
• Admin: może badać, ponownie skanować i nadpisywać dostęp w razie potrzeby
• Użytkownik zewnętrzny: ma dostęp tylko do dokumentów, które zostały mu wyraźnie udostępnione

Chroń też przed zgadywaniem ID. Nie wystawiaj inkrementalnych ID jak 12345 dla elementów w kwarantannie — używaj nieprzezroczystych identyfikatorów i zawsze autoryzuj per plik i per użytkownik (nie tylko „każdy zalogowany”). Nawet jeśli bucket jest prywatny, nieuwaga w endpointach API może nadal ujawnić zawartość kwarantanny.

W praktyce to warstwa dostępu jest miejscem, gdzie pojawiają się największe błędy. Na platformie takiej jak AppMaster egzekwujesz te sprawdzenia w endpointach API i logice biznesowej przed wygenerowaniem jakiejkolwiek odpowiedzi pobrania, dzięki czemu kwarantanna jest domyślnie prywatna.

Zwolnienie, odrzucenie i ponowne próby: obsługa wyników skanu

Gdy plik zakończy skanowanie, najważniejsze jest przejście do jednego jasnego stanu i uczynienie następnego kroku przewidywalnym. Traktuj wynik skanu jako bramkę: nic nie staje się możliwe do pobrania, dopóki bramka tego nie pozwoli.

Prosty zestaw wyników obejmuje większość systemów:

• Czysty: zwolnij plik z kwarantanny i pozwól na normalny dostęp.
• Zainfekowany: zablokuj dostęp trwale i uruchom workflow dla zainfekowanych plików.
• Nieobsługiwany: skaner nie może ocenić tego typu (np. archiwum z hasłem). Trzymaj zablokowany.
• Błąd skanu: błąd tymczasowy (timeout, niedostępność usługi). Trzymaj zablokowany.

Komunikaty dla użytkownika powinny być jasne i stonowane. Unikaj przerażających sformułowań typu „Twoje konto jest zagrożone.” Lepiej: „Plik jest sprawdzany. Możesz kontynuować pracę.” Jeśli plik jest zablokowany, powiedz, co użytkownik może zrobić dalej: „Wyślij plik w innym formacie” lub „Spróbuj ponownie później.” Dla plików nieobsługiwanych bądź konkretny (np. „zaszyfrowane archiwa nie podlegają skanowaniu”).

Dla zainfekowanych plików zdecyduj wcześniej, czy je usuwać, czy przechowywać. Usuwanie jest prostsze i zmniejsza ryzyko. Przechowywanie pomaga w audycie, ale tylko jeśli robisz to w izolowanym obszarze z restrykcyjnym dostępem i krótką retencją, i logujesz, kto ma do niego dostęp (najczęściej nikt poza zespołem bezpieczeństwa).

Retry mają sens tylko dla błędów tymczasowych. Ustal małą politykę retry, żeby nie tworzyć nieskończonego backlogu:

• Powtarzaj przy timeoutach i niedostępności skanera.
• Nie retryuj przy „zainfekowany” lub „nieobsługiwany”.
• Ogranicz liczbę prób (np. 3), a potem oznacz jako niepowodzenie.
• Dodaj backoff między próbami, aby nie przeciążyć systemu.

Wreszcie, traktuj powtarzające się niepowodzenia jako problem operacyjny, a nie użytkownika. Jeśli wiele plików trafia do „błąd skanu” w krótkim czasie, zaalarmuj zespół i wstrzymaj nowe zwolnienia. W AppMaster możesz modelować te stany w bazie i kierować powiadomienia przez wbudowane moduły komunikacji, aby odpowiednie osoby szybko o tym wiedziały.

Przykład scenariusza: portal klienta z dużą liczbą dokumentów

Portal klienta pozwala klientom przesyłać faktury i umowy dla każdego projektu. To typowy przypadek, gdzie skanowanie wirusów przy przesyłaniu plików ma znaczenie — użytkownicy przeciągają na stronę wszystko, co mają na pulpicie, włącznie z plikami przekazanymi im przez innych.

Gdy klient przesyła PDF, portal zapisuje go w tymczasowej, prywatnej lokalizacji i tworzy rekord w bazie ze statusem ustawionym na Oczekuje na skan. Plik nie jest jeszcze widoczny jako do pobrania. Worker skanujący pobiera plik z kolejki, uruchamia skan i aktualizuje rekord na Czysty lub Zablokowany.

W UI klient widzi plik od razu, ale z wyraźną odznaką Oczekuje. Widoczna jest nazwa pliku i rozmiar, więc wie, że upload się powiódł, ale przycisk Pobierz jest wyłączony, dopóki skan nie przejdzie pomyślnie. Jeśli skan trwa dłużej niż oczekiwano, portal może pokazać prostą wiadomość: „Sprawdzamy ten plik pod kątem bezpieczeństwa. Spróbuj ponownie za minutę.”

Jeśli skaner oznaczy dokument, klient zobaczy status Zablokowany z krótką, nietechniczną notką: „Ten plik nie przeszedł kontroli bezpieczeństwa.” Support i admini mają osobny widok z powodem skanu i zalecanymi działaniami. Mogą:

• pozostawić zablokowany i poprosić o nowe przesłanie
• usunąć i zanotować powód
• oznaczyć jako fałszywy alarm tylko jeśli polityka na to pozwala

W sporach typu „Wysłałem to wczoraj, a teraz zniknęło”, dobre logi są kluczowe. Przechowuj znaczniki upload received, scan started, scan finished, status changed oraz kto wykonał daną akcję. Zapisz też hash pliku, oryginalną nazwę, konto przesyłające, adres IP i kod wyniku skanera. Jeśli budujesz to w AppMaster, Data Designer i prosty Business Process mogą zarządzać tymi statusami i polami audytu bez wystawiania plików w kwarantannie zwykłym użytkownikom.

Typowe błędy prowadzące do rzeczywistych luk bezpieczeństwa

Większość awarii zabezpieczeń uploadów to nie wymyślne ataki, lecz małe decyzje projektowe, które przypadkowo sprawiają, że niebezpieczny plik zachowuje się jak normalny dokument.

Klasyczny problem to wyścig: aplikacja akceptuje upload, zwraca URL do pobrania, a użytkownik (lub inna usługa) może pobrać plik zanim skan się skończy. Przy skanowaniu wirusów dla przesyłanych plików traktuj „przesłano” i „dostępne” jako dwa różne stany.

Oto błędy pojawiające się najczęściej:

• Mieszanie czystych i kwarantannowych plików w tym samym bucket/folderze i poleganie na regułach nazewnictwa. Jedno złe uprawnienie lub zła ścieżka i kwarantanna traci sens.
• Zaufanie rozszerzeniom plików, MIME type lub kontroli po stronie klienta. Atakujący może zmienić nazwę na .pdf i UI niczego nie zauważy.
• Brak planu na awarie skanera. Jeśli skaner jest wolny lub offline, pliki mogą stać w „oczekuje” wiecznie i zespoły zaczynają stosować niebezpieczne ręczne obejścia.
• Pozwalanie workerom tła na pomijanie tych samych reguł autoryzacji co główne API. Worker, który może czytać „dowolny plik”, to cicha eskalacja uprawnień.
• Publikowanie łatwych do odgadnięcia ID (inkrementalne) dla elementów w kwarantannie, nawet jeśli treść ma być chroniona.

Testowanie to kolejne miejsce błędów. Zespoły testują kilkoma małymi, czystymi plikami i myślą, że to koniec. Trzeba też sprawdzić duże uploady, uszkodzone pliki i zaszyfrowane dokumenty, bo to właśnie tam skanery i parsery zawodzą lub timeoutują.

Prosty przykład: użytkownik portalu przesyła „contract.pdf”, który w rzeczywistości jest przemianowanym plikiem wykonywalnym wewnątrz archiwum. Jeśli portal zwraca go natychmiast lub support ma dostęp do kwarantanny bez właściwych kontroli, stworzyłeś bezpośrednią ścieżkę dostawy zainfekowanego pliku do innych użytkowników.

Szybka lista kontrolna przed wdrożeniem

Zrób ostatnie sprawdzenie miejsc, w których zespoły zwykle myślą „to jest ok”, a potem odkrywają, że nie było. Cel jest prosty: niebezpieczny plik nie powinien stać się czytelny tylko dlatego, że ktoś zgadł URL, powtórzył żądanie lub użył starego linku z cache.

Zacznij od flow użytkownika. Każde pobranie, podgląd lub „otwórz plik” powinno przy żądaniu ponownie weryfikować aktualny status skanowania pliku, nie tylko przy przesłaniu. To chroni przed wyścigami (ktoś klika natychmiast), opóźnionymi wynikami skanów i przypadkami krawędziowymi, gdy plik jest ponownie skanowany.

Użyj tej przed-wdrożeniowej listy jako minimum:

• Storage kwarantanny jest prywatny domyślnie: brak publicznego dostępu do bucketu, brak „każdy z linkiem” i brak bezpośredniego serwowania z surowego obiektowego storage.
• Każdy rekord pliku ma właściciela (użytkownik, zespół lub tenant) oraz klarowny stan cyklu życia jak oczekuje, czysty, zainfekowany lub failed.
• Twoja kolejka skanów i workery mają ograniczone retry, jasne zasady backoff i alerty, gdy elementy stoją lub często zawodzą.
• Istnieją logi audytu dla uploadów, wyników skanów i prób pobrania (w tym zablokowanych prób) z informacją kto, kiedy i dlaczego.
• Ręczne nadpisanie istnieje na rzadkie przypadki, ale jest tylko dla adminów, zapisywane i ograniczone czasowo (brak cichego przycisku „oznacz jako czysty”).

Na koniec upewnij się, że możesz obserwować system end-to-end. Powinieneś móc odpowiedzieć: „Ile plików teraz oczekuje na skan?” i „Którzy tenantci widzą błędy?” Jeśli budujesz na AppMaster, zamodeluj cykl życia pliku w Data Designer i egzekwuj kontrole stanów w Business Process Editor, aby zasady pozostały spójne w web i mobile.

Następne kroki: zamiana projektu w działającą aplikację

Zacznij od spisania dokładnych stanów plików i co każdy stan pozwala robić. Uprość i bądź jawny: „przesłano”, „w kolejce”, „skanowanie”, „czysty”, „zainfekowany”, „scan_failed”. Dodaj reguły dostępu obok każdego stanu: kto może widzieć plik, pobrać go lub usunąć, gdy jest nieufny?

Następnie wybierz podejście odpowiadające Twojemu wolumenowi i oczekiwaniom UX. Skan inline jest łatwiejszy do wytłumaczenia, ale może spowalniać uploady. Skan asynchroniczny lepiej się skaluje w aplikacjach z dużą ilością dokumentów, ale dodaje stany, kolejki i UI „oczekuje”.

Praktyczny sposób przejścia od projektu do budowy to prototypowanie pełnego flow end-to-end z realistycznymi dokumentami (PDF, pliki Office, obrazy, archiwa) i realistycznym zachowaniem użytkowników (wiele uploadów, anulowanie, retry). Nie zatrzymuj się na „skaner działa”. Waliduj, że aplikacja nigdy nie serwuje pliku w kwarantannie, nawet przypadkowo.

Prosty plan budowy na tydzień:

• Zdefiniuj stany plików, przejścia i reguły dostępu na jednej stronie
• Wybierz inline, async lub hybrydowe skanowanie i udokumentuj kompromisy
• Zaimplementuj upload -> storage kwarantanny -> zadanie skanu -> callback z wynikiem, z logami audytu
• Zbuduj UI stanów, które zobaczą użytkownicy (oczekuje, zablokowany, failed, zatwierdzony)
• Dodaj monitoring od pierwszego dnia: wielkość backlogu, wskaźnik błędów i czas do czystości

Jeśli budujesz bez kodu, AppMaster może pomóc zmodelować metadane pliku (status, właściciel, checksum, znaczniki czasu), zbudować ekrany uploadu i przeglądu oraz zorganizować workflow skanowania za pomocą logiki biznesowej i przetwarzania w kolejce. To pozwala przetestować realny przepływ produktu wcześnie, a potem utwardzić krytyczne elementy: uprawnienia, separację storage i niezawodne retry.

Na koniec zdecyduj, jak wyglądają dobre wskaźniki. Ustaw progi alertów przed uruchomieniem, aby zauważyć zablokowane skany i rosnące błędy zanim zrobi to użytkownik.