Dosya yüklemeleri için virüs taraması: uygulamalar için mimari seçenekler

Sorunu sade bir dille açıklamak: güvensiz dosyaların uygulamanıza girmesi

Uygulamanız insanların belge yüklemesine izin veriyorsa, sizin oluşturmadığınız dosyaları kabul ediyorsunuz demektir. Müşteri portalları, İK sistemleri, hasar talepleri uygulamaları veya tedarikçi kayıtları gibi belge ağırlıklı ürünlerde yüklemeler sık olur ve kullanıcılar genellikle e-posta eklerinden, paylaşılan sürücülerden veya üçüncü taraflardan aldıkları dosyaları paylaşır. Bu durum uygulamaları pratik bir hedef haline getirir: tek bir başarılı yükleme birçok indirmeye yayılabilir.

Risk sadece “bir virüs” değildir. Bir Word veya Excel dosyası kötü amaçlı makrolar taşıyabilir, PDF okuyucu hatalarını suistimal edecek şekilde hazırlanabilir ve bir “fatura” sahte bir numarayı aramanızı veya kimlik bilgisi girmenizi sağlayacak bir oltalama belgesi olabilir. Bazı dosyalar daha sessiz yöntemlerle zehirlenir: bir ZIP içinde yük taşıyıcısı saklamak, çift uzantı kullanmak (report.pdf.exe) veya açıldığında dışa bağlantı kuran gömülü uzaktan içerik barındırmak gibi.

Tek bir sunucuda kurulu basit bir antivirüse güvenmek yeterli değildir. Yüklemeler birden fazla uygulama örneğine çarpabilir, depolama sistemleri arasında taşınabilir veya nesne depolama ya da CDN üzerinden servis edilebilir. Hangi kod yolu ham yüklemeyi yanlışlıkla açığa çıkarırsa kullanıcılar tarama bitmeden önce indirebilir. Güncellemeler, yanlış yapılandırmalar ve “geçici” yönetici erişimleri de zamanla taramayı atlayabilir.

Dosya yüklemeleri için virüs taramasının açık hedefi basittir: hiçbir taranmamış dosya, karantinadaki içeriği açıkça incelemeye izin verilmiş olmayan biri tarafından indirilebilir veya görüntülenebilir olmamalıdır.

"Güvenli"nin ne anlama geldiğini his ile değil iş kuralı olarak tanımlayın. Örneğin:

• Güncel imza setiyle zararlı yazılım taramasından geçmeli
• İzin verilen dosya türleri ve boyut limitleriyle eşleşmeli
• Sadece onaylı konumlardan depolanıp servis edilmeli
• Kim yükledi, ne zaman ve nihai durum gibi bir denetim izi olmalı
• Nihai karar verilene kadar engellenmeli: yayınla veya reddet

AppMaster gibi bir platformla inşa ediyorsanız, “tarama durumu”nu veri modelinizde birinci sınıf bir alan olarak ele alın ve her indirme eyleminin bunu kontrol etmesini sağlayın. Bu tek kapı birçok pahalı hatayı engeller.

Yüklenen belgeler için karantinanın gerçek anlamı

"Karantina"yı sisteme ait bir durum olarak düşünmek en iyisidir, sadece depolamada bir klasör değil. Temel fikir basittir: dosya mevcut ama uygulamanızda net, kaydedilmiş bir tarama sonucu olmadan kimse açamaz veya indiremez. Bu, dosya yüklemeleri için virüs taramasının kalbidir.

Karantina genellikle net durumlarla küçük bir yaşam döngüsü olarak çalışır. Durumu açık tutmak, önizleme, doğrudan URL veya bir dışa aktarma işi yoluyla güvensiz içeriğin istemeden sızmasını zorlaştırır.

Pratik bir dosya durumu seti şu şekilde olabilir:

• received (yükleme tamamlandı, henüz taranmadı)
• scanning (bir işçi almış)
• clean (yayınlanmaya uygun)
• rejected (zararlı bulundu veya politika ihlali)
• failed (tarayıcı hatası, zaman aşımı veya bozuk dosya)

Karantina ayrıca daha sonra erişimi uygulamak ve ne olduğunu denetlemek için doğru meta veriye ihtiyaç duyar. En azından şu bilgileri saklayın: sahibi (kullanıcı veya kuruluş), durum, orijinal dosya adı ve türü, özet (dublike ve tahrifat kontrolleri için), depolama konumu ve zaman damgaları (yükleme, tarama başlama, tarama bitiş). Birçok ekip ayrıca tarayıcı sürümünü ve tarama kararı ayrıntılarını da saklar.

Saklama politikası kasıtlı olmalıdır. Karantinadaki dosyaları yalnızca taramak ve hataları ayıklamak için gerektiği kadar saklayın. Kısa saklama riski ve maliyeti azaltır, ancak olayları araştırmak ve “yüklemem nerede kaldı?” diye soran kullanıcılara destek vermek için yeterli süreyi bırakmak istersiniz.

Son olarak, asla tarama bitmeyen dosyalarla ne yapacağınızı kararlaştırın. Maksimum tarama süresi ve bir "son kullanma" zaman damgası belirleyin. Süre dolduğunda dosyayı failed durumuna taşıyın, erişimi engelleyin ve ya sınırlı sayıda otomatik yeniden deneme başlatın ya da dosyayı silip kullanıcının yeniden yüklemesini isteyin.

Riski azaltan geçici depolama desenleri

Geçici depolama, çoğu yükleme probleminin olduğu yerdir. Dosya sisteminizde var ama henüz güvenli olup olmadığını bilmiyorsunuz, bu yüzden kapatması kolay ve yanlışlıkla açığa çıkarması zor bir yere ihtiyacınız var.

Yerel disk tek sunucu için çalışabilir, ancak kırılgandır. Çoklu uygulama sunucularına ölçeklendiğinizde depolamayı paylaşmanız, dosya kopyalamanız ve izinleri tutarlı tutmanız gerekir. Nesne depolama (S3-style bucket veya bulut konteyneri gibi) belge ağırlıklı uygulamalar için genellikle daha güvenlidir çünkü erişim kuralları merkezidir ve günlükler daha nettir.

Dosya yüklemeleri için virüs taramasında basit bir desen, "karantina"yı "temiz" depolamadan ayırmaktır. Bunu iki bucket/kap ile yapabilirsiniz; bu hataları daha az olası kılar veya tek bir bucket içinde sıkı bir prefix yapısıyla daha ucuz ve yönetimi kolay olabilir.

Prefix kullanıyorsanız, kafa karışıklığını imkansız kılın. quarantine/<tenant_id>/<upload_id> ve clean/<tenant_id>/<document_id> gibi bir düzen tercih edin; kullanıcı tarafından sağlanan adları kullanmayın. Farklı durumlar için aynı yolu asla tekrar kullanmayın.

Aşağıdaki kuralları aklınızda tutun:

• Karantinada genel okumalara izin vermeyin, hatta "geçici" olsa bile.
• Sunucu tarafı nesne adları oluşturun, istemci adları değil.
• Etki alanını azaltmak için tenant veya hesap bazlı bölümleme yapın.
• Meta veriyi (sahip, durum, özet) dosya adında değil veritabanınızda saklayın.

İstirahatte şifreleyin ve kimin çözebileceği konusunda katı olun. Yükleme API'sı karantinaya yazabilmeli, tarayıcı karantinadan okuyup temiz'e yazabilmeli ve halka açık uygulama yalnızca temiz'den okuyabilmelidir. Bulut anahtar politikaları destekliyorsa, şifre çözme haklarını mümkün olan en küçük rol kümesine bağlayın.

Büyük dosyalar ekstra dikkat gerektirir. Çok parçalı yüklemeler için son parça onaylanıp beklenen boyut ve özet kaydedilene kadar nesneyi "hazır" olarak işaretlemeyin. Güvenli bir yaklaşım, parçaları karantinaya yüklemek ve tarama geçtikten sonra nesneyi temiz alana kopyalamak veya terfi ettirmektir.

Örnek: AppMaster ile yapılmış bir müşteri portalında her yüklemeyi "beklemede" olarak ele alabilir, karantina bucket'ına kaydedebilir ve yalnızca tarama sonucu durum "clean" olduğunda bir indirme düğmesi gösterirsiniz.

Mimari seçenekler: inline tarama vs arka plan taraması

Dosya yüklemeleri için virüs taraması eklerken genelde iki akış arasında seçim yaparsınız: inline tarama (kullanıcı bekler) veya arka plan tarama (uygulama yüklemeyi kabul eder ama temizlenene kadar erişimi engeller). Doğru seçim genelde "güvenlik seviyesi"nden daha çok hız, güvenilirlik ve kullanıcıların ne sıklıkta yükleme yaptığına bağlıdır.

Seçenek 1: Inline tarama (kullanıcı bekler)

Inline tarama, tarayıcı sonuç verene kadar yükleme isteğinin tamamlanmaması anlamına gelir. Tek adım varmış gibi hissettirir: yükle, tara, kabul et veya reddet.

Küçük dosyalar, nadir yüklemeler ve bekleme süresinin tahmin edilebilir olmasının kabul edilebilir olduğu durumlarda inline tarama genellikle uygundur. Örneğin, kullanıcıların günde birkaç PDF yüklediği bir ekip aracı 3–10 saniyelik bir duraksamayı tolere edebilir. Dezavantajı, yavaş bir taramanın uygulamayı yavaşlatmasıdır. Zaman aşımı, yeniden denemeler ve mobil ağlar temiz bir dosyayı kötü bir kullanıcı deneyimine çevirebilir.

Seçenek 2: Arka plan taraması (asenkron)

Asenkron tarama önce dosyayı depolar, onu "karantinada" işaretler ve bir tarama kuyruğuna bir iş gönderir. Kullanıcı hızlı bir "yükleme alındı" yanıtı alır, ancak dosya temizlenene kadar indirme veya önizleme yapamaz.

Bu yaklaşım yüksek hacim, büyük dosyalar ve yoğun saatler için daha iyidir çünkü işi yayar ve uygulamanızın yanıtlı kalmasını sağlar. Ayrıca tarama işçilerini ana web veya API sunucularından ayrı ölçeklendirmenize olanak verir.

Pratik bir hibrit, hızlı kontrolleri inline çalıştırmak (dosya türü beyaz listesi, boyut limitleri, temel format doğrulama) ve tam antivirüs taramasını arka planda yapmaktır. Bu, bariz sorunları erken yakalar ve her kullanıcıyı bekletmez.

Seçim için basit bir kılavuz:

• Küçük dosyalar, düşük hacim, "hemen bilmek" gereken iş akışları: inline tarama
• Büyük dosyalar, çok sayıda yükleme veya tahmin edilemeyen tarama süreleri: arka plan taraması
• Yükleme yanıt hızı için sıkı SLA'lar: arka plan taraması ve net durum UI'sı
• Karışık iş yükleri: hibrit (önce hızlı kontroller, tam tarama asenkron)

AppMaster ile inşa ediyorsanız, bu seçim genelde bir eşzamanlı API uç noktasına (inline) veya tarama işini kuyruğa alan ve sonuç geldiğinde dosya durumunu güncelleyen bir Business Process'e (arka plan) temiz şekilde eşlenir.

Adım adım: asenkron tarama kuyruğu oluşturma

Asenkron tarama, yüklemeyi kabul edip karantinaya kilitler ve arka planda tarar; kullanıcılar tarayıcı "tamam" demeden erişemez. Bu genellikle belge ağırlıklı uygulamalar için en pratik zararlı yazılım tarama mimarisidir.

1) Kuyruk mesajını tanımlayın (küçük tutun)

Kuyruğu bir yapılacaklar listesi gibi düşünün. Her yükleme, dosyaya işaret eden bir mesaj oluşturur; dosyanın kendisini koymayın.

Basit bir mesaj genellikle şunları içerir:

• Dosya ID'si (veya nesne anahtarı) ve tenant veya proje ID'si
• Yükleyen kullanıcı ID'si
• Yükleme zaman damgası ve bir özet (isteğe bağlı ama faydalı)
• Deneme sayısı (veya ayrı bir yeniden deneme sayacı)

Ham baytları kuyruğa koymaktan kaçının. Büyük yükler sınırları aşabilir, daha pahalı olur ve maruz kalmayı artırır.

2) İşçi akışını oluşturun (al, tara, kaydet)

Bir işçi bir mesaj çeker, karantinadan dosyayı alır, tarar ve sonra bir karar yazar.

Açık bir akış şöyledir:

• Karantinadaki depolamadan dosyayı ID ile alın (özel bucket veya özel hacim)
• Tarayıcıyı çalıştırın (AV motoru veya tarama servisi)
• Sonucu veritabanına yazın: durum (clean, infected, error), tarayıcı adı/sürümü ve zaman damgaları
• Clean ise: dosyayı onaylı depolamaya taşıyın veya erişim bayrağını çevirin ki indirilebilsin
• Infected ise: karantinada tutun (veya silin) ve ilgili kişilere bildirim gönderin

3) İdempotent yapın (tekrar işlenmeye dayanıklı)

İşçiler çökecek, mesajlar iki kez teslim edilecek ve yeniden denemeler olacaktır. Aynı dosyayı iki kez taramanın zarar vermeyecek şekilde tasarlayın. Tek bir gerçek kaynak kayıt kullanın, örneğin files.status ve yalnızca geçerli geçişlere izin verin; örneğin: uploaded -> scanning -> clean/infected/error. Bir işçi clean görürse durmalı ve mesajı onaylamalıdır.

4) Eşzamanlılığı kontrol edin (tarama selini önleyin)

İşçi başına ve tenant başına limitler koyun. Aynı anda kaç taramanın yapılabileceğini sınırlayın ve büyük dosyalar için ayrı kuyruklar düşünün. Bu, tek bir yoğun müşterinin tüm tarayıcı kapasitesini tüketmesini engeller.

5) Hataları yeniden deneme ve denetim izi ile yönetin

Geçici hatalar (tarayıcı zaman aşımı, ağ sorunu) için yeniden denemeler kullanın ve düşük bir maksimum deneme sayısı belirleyin. Ondan sonra mesajı manuel inceleme için dead-letter kuyruğuna gönderin.

Kim yükledi, karantinaya ne zaman girdi, hangi tarayıcı çalıştı, ne karar verdi ve dosyayı kim onayladı veya sildi gibi bilgileri denetim izine kaydedin. Bu günlükler, müşteri portalları ve uyumluluk için virüs taraması kadar önemlidir.

Erişim kontrolü: karantinadaki dosyaları gerçekten özel tutmak

Karantina veritabanınızdaki bir durumdan daha fazlasıdır; kimsenin dosyayı güvenli olduğu onaylanana kadar açamayacağının bir taahhüdüdür. En güvenli kural basittir: karantinadaki dosyaları halka açık URL'lerle asla servis etmeyin, hatta "geçici" olsa bile.

İyi bir indirme akışı sıkıcı ve katıdır. Uygulama her indirmeyi bir resim almak gibi değil korumalı bir eylemmiş gibi ele almalıdır.

İyi bir indirme akışı şöyle olmalıdır:

1. İndirme isteği
2. Bu belirli dosyaya kullanıcının izinini kontrol et
3. Dosyanın durumunu kontrol et (quarantined, clean, rejected)
4. Durum clean ise dosyayı teslim et

İmzalı URL'ler kullanıyorsanız aynı fikri uygulayın: izin ve durum kontrollerinden sonra üretin ve kısa ömürlü yapın. Kısa süreli geçerlilik, bağlantı günlükler, ekran görüntüleri veya iletilmiş e-postalar yoluyla sızarsa zararı azaltır.

Rol tabanlı erişim, zamanla deliğe dönüşen "özel durum" mantığını önlemenize yardımcı olur. Belge ağırlıklı uygulamalar için tipik roller:

• Yükleyen: kendi yüklemelerini ve tarama durumunu görebilir
• İnceleyen: temiz dosyaları görüntüleyebilir, bazen özel güvenli inceleme aracında karantinadakileri görebilir
• Yönetici: inceleyebilir, yeniden tarayabilir ve gerektiğinde erişimi geçersiz kılabilir
• Harici kullanıcı: yalnızca kendisiyle açıkça paylaşılan belgeleri erişebilir

Ayrıca ID tahmini saldırılarına karşı koruyun. 12345 gibi artan dosya ID'lerini açığa çıkarmayın. Opak ID'ler kullanın ve her zaman kullanıcı ve dosya bazında yetkilendirme yapın (sadece "oturum açmış herhangi bir kullanıcı" değil). Depolama bucket'ınız özel olsa bile, dikkatsiz bir API uç noktası karantinadaki içeriği yine de sızdırabilir.

Dosya yüklemeleri için virüs taraması kurarken, erişim katmanı gerçek dünyadaki hataların çoğunun olduğu yerdir. AppMaster gibi bir platformda, bu kontrolleri herhangi bir indirme yanıtı üretmeden önce API uç noktalarınızda ve iş mantığınızda uygularsınız, böylece karantina varsayılan olarak özel kalır.

Yayınlama, reddetme ve yeniden deneme: tarama sonuçlarını yönetme

Bir dosya taramayı tamamladığında, en önemli şey onu tek ve net bir duruma taşımak ve sonraki adımı öngörülebilir kılmaktır. Dosya yüklemeleri için virüs taraması kuruyorsanız, tarama sonucunu bir kapı gibi ele alın: kapı "olumlu" demedikçe hiçbir şey indirilebilir hale gelmemelidir.

Çoğu sistem için basit bir sonuç seti yeterlidir:

• Clean: dosyayı karantinadan serbest bırakın ve normal erişime izin verin.
• Infected: erişimi kalıcı olarak engelleyin ve enfekte dosya iş akışınızı tetikleyin.
• Unsupported: tarayıcı bu türü değerlendiremiyor (veya şifreli). Engelleyin.
• Scan error: geçici hata (zaman aşımı, servis kullanılamıyor). Engelleyin.

Kullanıcı mesajları net ve sakin olmalı. "Hesabınız tehlikede" gibi korkutucu ifadelerden kaçının. Daha iyi bir yaklaşım: "Dosya kontrol ediliyor. Çalışmaya devam edebilirsiniz." Dosya engellendiyse kullanıcıya ne yapabileceğini söyleyin: "Farklı bir dosya türü yükleyin" veya "Daha sonra tekrar deneyin." Desteklenmeyen dosyalar için spesifik olun (örneğin, "Şifreli arşivler taranamaz").

Enfekte dosyalar için silme mi saklama mı yapacağınıza erken karar verin. Silmek daha basittir ve riski azaltır. Saklamak denetimler için yardımcı olabilir, ancak sadece izole bir alanda sıkı erişimle ve kısa bir saklama süresiyle saklanmalı ve kimlerin görebileceğini kaydetmelisiniz (ideal olarak, kimse yönetici güvenlik personeli dışında).

Yeniden denemeler yararlı olabilir, ancak yalnızca geçici olduğu muhtemel hatalar için. Sonsuz bir birikim oluşturmayacak küçük bir yeniden deneme politikası belirleyin:

• Zaman aşımı ve tarayıcı kesintilerinde yeniden dene.
• "Infected" veya "Unsupported" durumlarında yeniden deneme yapmayın.
• Yeniden denemeleri sınırlayın (örneğin 3) ve sonra failed olarak işaretleyin.
• Denemeler arasında aşamalı bekleme (backoff) ekleyin.

Son olarak, tekrarlayan hataları kullanıcı sorunu değil operasyon sorunu olarak ele alın. Kısa sürede birçok dosya "scan error" oluyorsa ekibinizi uyarın ve yeni yayınları duraklatın. AppMaster'da bu durumları veritabanında modelleyebilir ve bildirimleri yerleşik mesajlaşma modülleriyle yönlendirerek doğru kişilerin hatalardan çabuk haberdar olmasını sağlayabilirsiniz.

Örnek senaryo: çok sayıda belgesi olan bir müşteri portalı

Bir müşteri portalı müşterilerin her proje için fatura ve sözleşme yüklemesine izin verir. Bu tür portallar dosya yüklemeleri için virüs taraması açısından önemlidir çünkü kullanıcılar masaüstlerinde ne varsa sürükleyip bırakır; bunlar genellikle başkalarından iletilmiş dosyalardır.

Müşteri bir PDF yüklediğinde, portal dosyayı geçici, özel bir konuma kaydeder ve durum Pending scan olarak ayarlanmış bir veritabanı kaydı oluşturur. Dosya henüz indirilebilir gösterilmez. Bir tarama işçisi kuyruğundan dosyayı çeker, taramayı çalıştırır ve kaydı Clean veya Blocked olarak günceller.

UI'da müşteri dosyanın hemen görünmesini görür, ancak üzerinde açık bir Pending rozeti vardır. Dosya adı ve boyutu görünür, böylece yüklemenin başarılı olduğunu bilirler, ama indirme düğmesi tarama clean olana kadar devre dışıdır. Tarama beklenenden uzun sürerse portal basit bir mesaj gösterebilir: "Bu dosyanın güvenliği kontrol ediliyor. Bir dakika sonra tekrar deneyin."

Tarayıcı bir belgeyi işaretlerse müşteri Blocked ve kısa, teknik olmayan bir not görür: "Bu dosya bir güvenlik kontrolünden geçemedi." Destek ve yöneticiler tarama nedeni ve sonraki adımları içeren ayrı bir görünüm alır. Yapabilecekleri:

• engeli korumak ve yeni bir yükleme talep etmek
• silmek ve nedenini kaydetmek
• politika izin veriyorsa yanlış pozitif ise sadece o zaman işaretlemek

Uyuşmazlıklarda ("Dün yükledim ve kaybettiniz") iyi günlükler önemlidir. Yükleme alındı, tarama başladı, tarama bitti, durum değişti ve kimin ne yaptığına dair zaman damgalarını saklayın. Ayrıca dosya hash'i, orijinal dosya adı, yükleyen hesap, IP adresi ve tarayıcı sonuç kodunu kaydedin. AppMaster ile inşa ediyorsanız, Data Designer ve basit bir Business Process akışı bu durumları ve denetim alanlarını düzenleyerek karantinadaki dosyaları normal kullanıcılara açmadan yönetebilir.

Gerçek güvenlik boşluklarına neden olan yaygın hatalar

Çoğu yükleme güvenliği hatası gösterişli hack'ler değildir. Güvensiz bir dosyanın normal bir belge gibi davranmasına neden olan küçük tasarım seçimleridir.

Klasik bir sorun yarış durumudur: uygulama bir yüklemeyi kabul eder, bir "indir" URL'si döner ve kullanıcı (veya başka bir servis) tarama bitmeden dosyayı alabilir. Dosya yüklemeleri için virüs taraması yapıyorsanız, "uploaded" ve "available" durumlarını farklı ele alın.

Tekrar eden hatalar şunlardır:

• Temiz ve karantina dosyalarını aynı bucket/klasörde karıştırmak ve sonra adlandırma kurallarına güvenmek. Bir yanlış izin veya yol tahmini ile karantina anlamsız olur.
• Dosya uzantısına, MIME türüne veya istemci tarafı kontrollere güvenmek. Saldırganlar her şeyi .pdf yapabilir ve UI buna aldanır.
• Tarayıcı kesintileri için plan yapmamak. Tarayıcı yavaş veya çevrimdışıyken dosyalar "pending" olarak kalabilir ve ekipler güvensiz manuel geçersiz kılmalar eklemeye başlar.
• Arka plan işçilerinin ana API ile aynı yetkilendirme kurallarını atlamasına izin vermek. "Herhangi bir dosyayı okuyabilen" bir işçi sessiz bir yetki yükseltme yolu olur.
• Karantinadaki öğeler için tahmin edilebilir ID'ler yayınlamak (arttırılmış numaralar gibi), içerik korunuyor sanılsa bile.

Test etmek de sık karşılaşılan bir açık. Ekipler birkaç küçük, temiz dosya ile test edip işi bitmiş sayar. Büyük yüklemeler, bozuk dosyalar ve parola korumalı belgelerle de denemelisiniz; çünkü bunlar tarayıcıların ve ayrıştırıcıların hata verdiği veya zaman aşımına uğradığı yerlerdir.

Gerçek bir örnek: bir müşteri portalı kullanıcısı "contract.pdf" adlı bir dosya yükler ama aslında bir arşiv içinde yeniden adlandırılmış bir yürütülebilir dosyadır. Portal bunu hemen geri sunuyorsa veya destek ekibi karantinaya düzgün kontroller olmadan erişebiliyorsa, diğer kullanıcılara doğrudan teslimat yolu açmış olursunuz.

Yayınlamadan önce hızlı kontrol listesi

Dosya yüklemeleri için virüs taramasını yayına almadan önce, ekiplerin genelde "tamam" varsaydığı ve sonra yanlış çıkan yerlerde son bir kontrol yapın. Hedef basit: kimse tahmin ederek, isteği yeniden deneyerek veya eski bir önbellek bağlantısıyla güvensiz bir dosyayı okunur hale getirmemeli.

Kullanıcı akışıyla başlayın. Herhangi bir indirme, önizleme veya "dosyayı aç" eylemi, sadece yükleme zamanında değil istek anında dosyanın mevcut tarama durumunu tekrar kontrol etmelidir. Bu, biri hemen tıklarsa ortaya çıkan yarış durumlarına, gecikmiş tarama sonuçlarına ve yeniden tarama durumlarına karşı koruma sağlar.

Yayın öncesi kontrol listesi (asgari):

• Karantina depolama varsayılan olarak özel: halka açık bucket erişimi yok, "bağlantıya sahip herkes" yok ve ham nesne depolamadan doğrudan servis yok.
• Her dosya kaydının bir sahibi (kullanıcı, ekip veya tenant) ve pending, clean, infected veya failed gibi net bir yaşam döngüsü durumu var.
• Tarama kuyruğunuz ve işçileriniz sınırlı yeniden denemelere, net backoff kurallarına ve öğeler takıldığında uyarılara sahip.
• Yüklemeler, tarama sonuçları ve indirme denemeleri (engellenen denemeler dahil) için denetim günlükleri mevcut; kim, ne zaman ve neden bilgisiyle.
• Nadir durumlar için yöneticiye özel, kaydedilen ve süreli bir manuel geçersiz kılma yolu var (gizli "temiz yap" butonu yok).

Son olarak, sistemi uçtan uca gözlemleyebildiğinizden emin olun. Şu sorulara cevap verebilmelisiniz: "Şu anda kaç dosya tarama bekliyor?" ve "Hangi tenant'lar başarısızlık görüyor?" AppMaster üzerinde inşa ediyorsanız, dosya yaşam döngüsünü Data Designer'da modelleyin ve iş mantığında durum kontrollerini Business Process Editor ile zorunlu kılın ki kurallar web ve mobil arasında tutarlı kalsın.

Sonraki adımlar: tasarımı çalışan bir uygulamaya dönüştürmek

Öncelikle dosyalarınızın hangi durumlarda olabileceğini ve her durumun neye izin verdiğini yazın. Basit ve açık tutun: "uploaded", "queued", "scanning", "clean", "infected", "scan_failed". Ardından her birinin yanında erişim kurallarını ekleyin. Dosya güvensizken kim görebilir, kim indirebilir veya kim silebilir?

Sonra hacminize ve kullanıcı deneyimi hedeflerinize uyan yaklaşımı seçin. Inline tarama açıklaması daha kolaydır ama yüklemeleri yavaşlatabilir. Asenkron tarama belge ağırlıklı uygulamalar için daha iyi ölçeklenir ama durum, kuyruklar ve "pending" UI ekler.

Tasarımı uygulamaya geçirmek için pratik bir yol, gerçekçi belgelerle uçtan uca bir prototip yapmaktır (PDF'ler, Office dosyaları, resimler, arşivler) ve gerçekçi kullanıcı davranışlarını test edin (birden çok yükleme, iptal etme, yeniden deneme). Sadece "tarayıcı çalışıyor" demekle yetinmeyin. Uygulama hiçbir şekilde karantinadaki bir dosyayı yanlışlıkla sunmamalıdır.

Bir haftada uygulayabileceğiniz basit bir inşa planı:

• Dosya durumlarını, geçişleri ve erişim kurallarını bir sayfada tanımlayın
• Inline, async veya hibrit tarama yaklaşımlarından birini seçin ve takasları dokümante edin
• Yükleme -> karantina depolama -> tarama işi -> sonuç geri çağrısı akışını uygulayın, denetim günlükleri ile
• Kullanıcıların göreceği UI durumlarını oluşturun (pending, blocked, failed, approved)
• İlk günden itibaren izleme ekleyin: bekleyen kuyruk boyutu, hata oranı ve temizlenme süresi

No-code ile inşa ediyorsanız, AppMaster dosya meta verilerini (durum, sahip, özet, zaman damgaları) modellemenize, yükleme ve inceleme ekranları oluşturmanıza ve tarama iş akışını iş mantığı ve kuyruk benzeri işlemlerle düzenlemenize yardımcı olabilir. Bu, gerçek ürün akışını erken test etmenizi, sonra izinler, depolama ayrımı ve güvenilir yeniden denemeler gibi önemli parçaları sertleştirmenizi sağlar.

Son olarak, "iyi"nin sayısal karşılıklarını belirleyin. Yayın öncesi uyarı eşiklerini ayarlayın ki takılmış taramalar ve yükselen hataları kullanıcılar görmeden önce fark edesiniz.