फ़ाइल अपलोड के लिए वायरस स्कैनिंग: ऐप्स के वास्तुकला विकल्प

समस्या सरल शब्दों में: आपके ऐप में असुरक्षित फ़ाइलें आना

यदि आपका ऐप लोगों को दस्तावेज़ अपलोड करने देता है, तो आप ऐसी फ़ाइलें स्वीकार कर रहे हैं जिन्हें आपने बनाया नहीं है। दस्तावेज़-भारी प्रोडक्ट्स (कस्टमर पोर्टल, HR सिस्टम, क्लेम ऐप्स, विकेंडर ऑनबोर्डिंग) में अपलोड अक्सर होते हैं और उपयोगकर्ता ईमेल थ्रेड, साझा ड्राइव या थर्ड-पार्टी स्रोतों से फ़ाइलें लाते हैं। यही कारण है कि ये ऐप्स व्यवहार में अच्छे लक्ष्य बनते हैं: एक सफल अपलोड बहुत सरे डाउनलोड्स तक फैल सकता है।

जो जोखिम हैं वे केवल “वायरस” तक सीमित नहीं हैं। Word या Excel फ़ाइलों में मैलिशस मैक्रो हो सकते हैं, PDF रीडर बग्स का एक्सप्लॉइट हो सकता है, और एक “इनवॉइस” फ़िशिंग दस्तावेज़ हो सकता है जो किसी को नकली नंबर पर कॉल करने या क्रेडेंशियल दर्ज करने के लिए धोखा दे। कुछ फ़ाइलें चुपचाप ज़हरीली होती हैं—ZIP में पेलोड छिपा होना, डबल एक्सटेंशन (report.pdf.exe), या रिमोट कंटेंट एम्बेड करना जो खोलते ही फोन्स होम कर देता है।

सिर्फ़ एक सर्वर पर इंस्टॉल किया हुआ बेसिक एंटीवायरस काफी नहीं है। अपलोड कई ऐप इंस्टेंसों को हिट कर सकते हैं, स्टोरेज सिस्टम के बीच मूव कर सकते हैं, या ऑब्जेक्ट स्टोरेज/ CDN से सर्व किए जा सकते हैं। अगर कोई कोड पाथ गलती से रॉ अपलोड एक्सपोज़ कर दे, तो यूज़र स्कैन खत्म होने से पहले ही उसे डाउनलोड कर सकता है। अपडेट, मिसकन्फिगरेशन और अस्थायी एडमिन एक्सेस भी समय के साथ स्कैनिंग को बाईपास कर सकते हैं।

फ़ाइल अपलोड की वायरस स्कैनिंग का स्पष्ट लक्ष्य सरल है: कोई भी अनस्कैन की गई फ़ाइल किसी ऐसे व्यक्ति के लिए डाउनलोडेबल या व्यूएबल नहीं होनी चाहिए जिसे स्पष्ट रूप से क्वारंटाइन की गई सामग्री की समीक्षा करने की अनुमति नहीं है।

“सुरक्षित” का मतलब भावना नहीं बल्कि बिज़नेस नियम के रूप में परिभाषित करें। उदाहरण के लिए:

• ताज़ा सिग्नेचर सेट के साथ मैलवेयर स्कैन पास होना चाहिए
• अनुमत फ़ाइल प्रकार और आकार सीमा से मैच होना चाहिए
• केवल अनुमोदित लोकेशनों से ही स्टोर और सर्व किया जाना चाहिए
• ऑडिट ट्रेल होना चाहिए: किसने अपलोड किया, कब, और अंतिम स्थिति
• अंतिम निर्णय (रिलीज़ या रिजेक्ट) तक ब्लॉक रहना चाहिए

यदि आप AppMaster जैसे प्लेटफ़ॉर्म के साथ बनाते हैं, तो “scan status” को अपने डेटा मॉडल में पहला दर्जा का फ़ील्ड मानें और हर डाउनलोड एक्शन इसे चेक करे। यही एक गेट बहुत सी महँगी गलतियों को रोकता है।

क्वारंटाइन का असल अर्थ क्या है

“क्वारंटाइन” को सिस्टम में एक स्थिति के रूप में सोचें, सिर्फ़ स्टोरेज में एक फ़ोल्डर नहीं। मुख्य विचार सरल है: फ़ाइल मौजूद है, लेकिन तब तक कोई उसे खोल या डाउनलोड न करे जब तक आपके ऐप में स्पष्ट और रिकॉर्ड किया गया स्कैन परिणाम न आ जाए। यही फ़ाइल अपलोड की वायरस स्कैनिंग का दिल है।

क्वारंटाइन आमतौर पर एक छोटा लाइफ़साइकिल स्टेटस होता है। स्थिति को स्पष्ट रखने से एक प्रिव्यू, डायरेक्ट URL या एक्सपोर्ट जॉब के ज़रिए असुरक्षित कंटेंट लीक करना कठिन हो जाता है।

एक व्यावहारिक फ़ाइल स्टेटस सेट इस तरह दिखता है:

• received (अपलोड पूरा हुआ, अभी स्कैन नहीं हुआ)
• scanning (किसी वर्कर ने उठाया)
• clean (रिलीज़ के लिए सुरक्षित)
• rejected (मैलवेयर मिला या नीति उल्लंघन)
• failed (स्कैनर त्रुटि, टाइमआउट, या फ़ाइल करप्ट)

क्वारंटाइन के लिए सही मेटाडेटा भी ज़रूरी है ताकि आप बाद में एक्सेस लागू कर सकें और ऑडिट कर सकें। कम से कम स्टोर करें: owner (यूज़र या ऑर्गेनाइज़ेशन), status, original filename और प्रकार, checksum (डुपे और टैम्पर चेकिन्ग के लिए), storage location, और timestamps (uploaded, scan started, scan finished)। कई टीमें स्कैनर वर्शन और स्कैन वर्डिक्ट विवरण भी रखती हैं।

रिटेंशन एक नीति निर्णय है, पर जानबूझकर होना चाहिए। क्वारंटाइन फ़ाइलें केवल उतने समय रखें जितना स्कैन करने और फेल्यर डिबग करने के लिए ज़रूरी हो। कम रिटेंशन रिस्क और लागत घटाता है, पर आपको इनसिडेंट्स की जाँच करने और यूज़र्स को सपोर्ट देने के लिए पर्याप्त समय चाहिए ताकि वे पूछ सकें “मेरी अपलोड कहाँ गई?”

आख़िर में, उन फ़ाइलों के साथ क्या करना है जो कभी स्कैन पूरा नहीं करतीं—इस पर निर्णय लें। अधिकतम स्कैन समय और एक “समाप्ति” टाइमस्टैम्प सेट करें। जब डेडलाइन बीत जाए, फ़ाइल को failed में ले जाएं, एक्सेस ब्लॉक कर दें, और या तो सीमित संख्या में ऑटोमेटिक रीट्राइ करें या फ़ाइल डिलीट करवा कर यूज़र से फिर से अपलोड करने को कहें।

जोखिम कम करने के लिए अस्थायी स्टोरेज पैटर्न

अस्थायी स्टोरेज वह जगह है जहाँ अधिकांश अपलोड समस्याएँ होती हैं। फ़ाइल आपके सिस्टम में है, पर आपको अभी पता नहीं है कि यह सुरक्षित है या नहीं, इसलिए आपको ऐसी जगह चाहिए जिसे लॉक डाउन करना आसान हो और गलती से एक्सपोज़ करना कठिन हो।

लोकल डिस्क एकल सर्वर के लिए काम कर सकती है, पर यह नाज़ुक है। यदि आप कई ऐप सर्वरों तक स्केल करते हैं, तो अब आपको स्टोरेज शेयर करनी होगी, फ़ाइलें कॉपी करनी होंगी, और परमिशन कंसिस्टेंट रखनी होंगी। ऑब्जेक्ट स्टोरेज (S3-स्टाइल बकेट या क्लाउड कंटेनर) अक्सर दस्तावेज़-भारी ऐप्स के लिए सुरक्षित होता है क्योंकि एक्सेस नियम केंद्रीकृत होते हैं और लॉग्स स्पष्ट होते हैं।

एक सरल पैटर्न यह है कि “क्वारंटाइन” और “क्लीन” स्टोरेज अलग रखें। आप यह दो बकेट/कंटेनरों से कर सकते हैं, जिससे गलतियाँ कम होती हैं, या एक बकेट के भीतर कड़े प्रीफ़िक्स स्ट्रक्चर से, जो सस्ता और प्रबंधनीय हो सकता है।

यदि आप प्रीफ़िक्स उपयोग करते हैं, तो उन्हें कन्फ्यूज़ करना असंभव बनाएं। एक लेआउट पसंद करें जैसे quarantine/<tenant_id>/<upload_id> और clean/<tenant_id>/<document_id>, न कि यूज़र-प्रोवाइड किए गए नाम। कभी भी अलग-अलग स्टेट्स के लिए एक ही पाथ दोबारा उपयोग न करें।

इन नियमों को ध्यान में रखें:

• क्वारंटाइन पर पब्लिक रीड की अनुमति न दें, भले ही अस्थायी हो।
• सर्वर-साइड ऑब्जेक्ट नाम जेनरेट करें, क्लाइंट नाम नहीं।
• ब्लास्ट रेडियस घटाने के लिए टेनेन्ट या अकाउंट के अनुसार पर्टिशन करें।
• मेटाडेटा (owner, status, checksum) अपने डेटाबेस में स्टोर करें, फ़ाइलनाम में नहीं।

डेटा रेस्ट में एन्क्रिप्ट करें, और किसे डिक्रिप्ट करने की अनुमति है, उसके बारे में सख़्ती बरतें। अपलोड API को क्वारंटाइन में लिखने की अनुमति होनी चाहिए, स्कैनर को क्वारंटाइन से पढ़ने और क्लीन में लिखने की अनुमति, और पब्लिक-फेसिंग ऐप केवल क्लीन से पढ़े। यदि आपके क्लाउड में की नीतियाँ हैं, तो डिक्रिप्शन अधिकारों को सबसे छोटे संभव रोल सेट तक सीमित करें।

बड़ी फ़ाइलों को अतिरिक्त ध्यान की ज़रूरत है। मल्टी-पार्ट अपलोड के लिए, ऑब्जेक्ट को “ready” मार्क न करें जब तक फाइनल पार्ट कमिट न हो और आपने अपेक्षित साइज और चेकसम रिकॉर्ड न कर लिया हो। एक सामान्य सुरक्षित तरीका है पार्ट्स को क्वारंटाइन में अपलोड करना और स्कैन पास होने पर ऑब्जेक्ट को क्लीन में कॉपी या प्रमोट करना।

उदाहरण: AppMaster पर बने एक कस्टमर पोर्टल में, आप हर अपलोड को “pending” मान सकते हैं, इसे क्वारंटाइन बकेट में स्टोर कर सकते हैं, और केवल तब डाउनलोड बटन दिखाएँ जब स्कैन रिज़ल्ट status को “clean” पर फ़्लिप कर दे।

वास्तुकला विकल्प: इनलाइन स्कैन बनाम बैकग्राउंड स्कैन

जब आप फ़ाइल अपलोड के लिए वायरस स्कैनिंग जोड़ते हैं, तो आम तौर पर दो फ्लो में से चुनते हैं: इनलाइन स्कैन (यूज़र वेट करता है) या बैकग्राउंड स्कैन (ऐसिंक्रोनस)। सही चुनाव “सिक्योरिटी लेवल” से कम और स्पीड, विश्वसनीयता, और अपलोड की आवृत्ति से ज़्यादा जुड़ा होता है।

विकल्प 1: इनलाइन स्कैन (यूज़र वेट करे)

इनलाइन स्कैन का मतलब है कि अपलोड रिक्वेस्ट तब तक खत्म नहीं होती जब तक स्कैनर रिज़ल्ट न दे दे। यह सरल लगता है क्योंकि केवल एक स्टेप है: अपलोड, स्कैन, स्वीकार या अस्वीकार।

इनलाइन स्कैन आमतौर पर तब स्वीकार्य होता है जब फ़ाइलें छोटी हों, अपलोड कम हों, और आप वेट टाइम प्रिडिक्टेबल रख सकें। उदाहरण के लिए, एक टीम टूल जहाँ यूज़र रोज़ कुछ PDFs अपलोड करते हैं, वहाँ 3–10 सेकंड का इंतज़ार सहन्य हो सकता है। डाउनसाइड यह है कि स्लो स्कैन का मतलब स्लो ऐप है। टाइमआउट, रीट्राइज़ और मोबाइल नेटवर्क एक क्लीन फ़ाइल को भी खराब यूज़र एक्सपीरियंस बना सकते हैं।

विकल्प 2: बैकग्राउंड स्कैन (ऐसिंक्रोनस)

ऐसिंक्रोनस स्कैन फ़ाइल को पहले स्टोर करता है, उसे “quarantined” मार्क करता है, और स्कैनिंग जॉब को एक कतार में डालता है। यूज़र को तेज़ “upload received” रिस्पॉन्स मिलती है, पर तब तक फ़ाइल डाउनलोड या प्रिव्यू के लिए उपलब्ध नहीं होती जब तक वह क्लियर न हो।

यह अप्रोच हाई वॉल्यूम, बड़ी फ़ाइलों और व्यस्त समय के लिए बेहतर है क्योंकि यह काम फैलाता है और आपके ऐप को प्रतिक्रियाशील रखता है। यह स्कैनिंग वर्कर्स को आपके मुख्य वेब/एपीआई सर्वरों से अलग स्केल करने की भी अनुमति देता है।

एक व्यावहारिक हाइब्रिड यह है: इनलाइन त्वरित चेक्स चलाएँ (फ़ाइल प्रकार allowlist, आकार सीमा, बेसिक फॉर्मेट वेलिडेशन), फिर पूरा एंटीवायरस स्कैन बैकग्राउंड में करें। यह स्पष्ट समस्याओं को जल्दी पकड़ता है बिना हर यूज़र को वेट करवाए।

चुनने का सरल तरीका:

• छोटी फ़ाइलें, कम वॉल्यूम, जब “तुरंत जानना ज़रूरी” हो: इनलाइन स्कैन
• बड़ी फ़ाइलें, बहुत सारे अपलोड, या अनप्रिडिक्टेबल स्कैन समय: बैकग्राउंड स्कैन
• अपलोड प्रतिक्रियाशीलता के लिए कड़ी SLA: बैकग्राउंड स्कैन + स्पष्ट स्टेटस UI
• मिश्रित वर्कलोड: हाइब्रिड (पहले त्वरित चेक, पूरा स्कैन ऐसिंक्रोनस)

यदि आप AppMaster के साथ बनाते हैं, तो यह चुनाव अक्सर सिंक्रोनस API एंडपॉइंट (इनलाइन) या एक बिज़नेस प्रोसेस जो स्कैनिंग वर्क को इनक्यू करता है और रिज़ल्ट आने पर फ़ाइल स्टेटस अपडेट करता है, से साफ़ मैप हो जाता है।

स्टेप-बाय-स्टेप: एक ऐसिंक्रोनस स्कैनिंग कतार बनाना

ऐसिंक्रोनस स्कैनिंग का अर्थ है आप अपलोड स्वीकार करते हैं, उसे क्वारंटाइन में लॉक कर देते हैं, और बैकग्राउंड में उसे स्कैन करते हैं। यूज़र्स को तब तक एक्सेस नहीं मिलता जब तक स्कैनर सुरक्षित न कहे। यह आम तौर पर दस्तावेज़-भारी ऐप्स के लिए सबसे व्यावहारिक मैलवेयर स्कैनिंग आर्किटेक्चर है।

1) कतार संदेश परिभाषित करें (इसे छोटा रखें)

कतार को एक टू-डू सूची की तरह मानें। हर अपलोड एक संदेश बनाता है जो फ़ाइल की ओर इशारा करता है, न कि फ़ाइल खुद।

एक सरल संदेश आमतौर पर शामिल करता है:

• File ID (या object key) और tenant या project ID
• Uploaded-by user ID
• Upload timestamp और checksum (वैकल्पिक पर मददगार)
• Attempt number (या एक अलग retry काउंटर)

क्यू में कच्चे बाइट्स न रखें। बड़े पेलोड लिमिट्स तोड़ सकते हैं, महँगे होते हैं, और एक्सपोज़र बढ़ाते हैं।

2) वर्कर फ़्लो बनाएं (fetch, scan, record)

एक वर्कर संदेश खींचता है, क्वारंटाइन स्टोरेज से फ़ाइल लाता है, उसे स्कैन करता है, फिर निर्णय लिखता है।

एक स्पष्ट फ्लो इस तरह है:

• क्वारंटाइन स्टोरेज (प्राइवेट बकेट या प्राइवेट वॉल्यूम) से ID द्वारा फ़ाइल फ़ेच करें
• स्कैनर चलाएँ (AV इंजन या स्कैनिंग सर्विस)
• रिज़ल्ट अपने डेटाबेस में लिखें: status (clean, infected, error), scanner name/version, और timestamps
• यदि clean: फ़ाइल को अप्रूव्ड स्टोरेज में मूव करें या एक एक्सेस फ्लैग फ़्लिप करें ताकि वह डाउनलोडेबल हो जाए
• यदि infected: उसे क्वारंटाइन्ड रखें (या डिलीट करें) और संबंधित लोगों को सूचित करें

3) इसे idempotent बनाएं (दोबारा प्रोसेस करना सुरक्षित हो)

वर्कर्स क्रैश होंगे, संदेश दो बार डिलीवर होंगे, और रीट्राइज़ होंगे। डिज़ाइन ऐसा रखें कि एक ही फ़ाइल को दो बार स्कैन करने से नुकसान न हो। files.status जैसे सिंगल सोर्स ऑफ़ ट्रूथ रिकॉर्ड का उपयोग करें और केवल वैध ट्रांज़िशन की अनुमति दें, उदाहरण: uploaded -> scanning -> clean/infected/error। यदि कोई वर्कर clean देखता है, तो उसे रोक कर संदेश को acknowledge कर देना चाहिए।

4) समवर्तीता नियंत्रित करें (स्कैनिंग स्टॉर्म से बचें)

प्रति वर्कर और प्रति टेनेन्ट सीमा सेट करें। कितने स्कैन एक साथ चल सकते हैं इसे कैप करें, और बड़ी फ़ाइलों के लिए अलग कतारों पर विचार करें। यह रोकता है कि एक व्यस्त कस्टमर सारा स्कैनर कैपेसिटी न ले ले।

5) फेल्यर्स को retries और ऑडिट ट्रेल के साथ हैंडल करें

टेम्परेरी एरर्स (स्कैनर टाइमआउट, नेटवर्क इश्यू) के लिए retries उपयोग करें और एक छोटा मैक्स अटेम्प्ट काउंट रखें। उसके बाद संदेश को dead-letter queue पर भेजें ताकि मैन्युअल रिव्यू हो सके।

ऑडिट ट्रेल रखें: किसने दस्तावेज़ अपलोड किया, कब क्वारंटाइन में गया, किसने किस स्कैनर को चलाया, क्या निर्णय लिया गया, और किसने फ़ाइल अप्रूव या डिलीट की। यह लॉग वायरस स्कैनिंग जितना ही महत्वपूर्ण है, ख़ासकर कस्टमर पोर्टल और अनुपालन के लिए।

एक्सेस नियंत्रण: क्वारंटाइन्ड फ़ाइलों को वास्तव में निजी रखना

क्वारंटाइन केवल डेटाबेस में एक स्थिति नहीं है। यह एक वादा है कि फ़ाइल तब तक नहीं खोली जाएगी जब तक वह सुरक्षित साबित न हो। सबसे सुरक्षित नियम सरल है: क्वारंटाइन्ड फ़ाइलें सार्वजनिक URLs के ज़रिए कभी भी सर्व न करें, भले ही वे “अस्थायी” हों।

एक अच्छा डाउनलोड फ़्लो नीरस और सख़्त होता है। ऐप को हर डाउनलोड को एक संरक्षित क्रिया की तरह ट्रीट करना चाहिए, न कि किसी छवि को फेच करने की तरह।

1. डाउनलोड का अनुरोध
2. उस विशेष फ़ाइल पर उपयोगकर्ता की अनुमति जाँचें
3. फ़ाइल की स्थिति जांचें (quarantined, clean, rejected)
4. केवल तब फ़ाइल डिलीवर करें जब status clean हो

यदि आप signed URLs का प्रयोग करते हैं, तो विचार वही रखें: केवल अनुमति और स्टेटस चेक करने के बाद ही उन्हें जेनरेट करें, और उन्हें कम समय के लिए एक्सपायर होने वाला रखें। कम एक्सपायरी समय लिंक लीक होने पर नुकसान घटाता है।

रोल-आधारित एक्सेस आपको “स्पेशल केस” लॉजिक से बचाता है जो बाद में होल बन सकता है। दस्तावेज़-भारी ऐप्स के लिए सामान्य रोल्स:

• Uploader: अपनी अपलोड और उनके स्कैन स्टेटस देख सकता है
• Reviewer: क्लीन फ़ाइलें देख सकता है, और कभी-कभी सुरक्षित रिव्यू टूल में क्वारंटाइन्ड फ़ाइलें देख सकता है
• Admin: जाँच कर सकता है, री-स्कैन कर सकता है, और जरूरत पड़ने पर ओवरराइड कर सकता है
• External user: केवल उन दस्तावेज़ों तक पहुँच सकता है जो स्पष्ट रूप से उनके साथ शेयर किए गए हों

ID गेसिंग से भी बचाएँ। आसान अनुमान लगाने योग्य फ़ाइल IDs (जैसे क्रमागत 12345) न दिखाएँ।opaque IDs का उपयोग करें, और हमेशा पर-यूज़र और पर-फ़ाइल authorize करें (सिर्फ़ “कोई भी लॉग-इन यूज़र” नहीं)। यहाँ तक कि यदि आपका स्टोरेज बकेट प्राइवेट है, एक लापरवाह API एंडपॉइंट अभी भी क्वारंटाइन्ड कंटेंट लीक कर सकता है।

जब आप फ़ाइल अपलोड की वायरस स्कैनिंग बनाते हैं, एक्सेस लेयर वह जगह है जहाँ वास्तविक दुनिया की अधिकतर विफलताएँ होती हैं। AppMaster जैसे प्लेटफ़ॉर्म में आप इन चेक्स को अपने API एंडपॉइंट्स और बिज़नेस लॉजिक में लागू करेंगे ताकि क्वारंटाइन डिफ़ॉल्ट रूप से निजी रहे।

रिलीज़, रिजेक्ट और रीट्राइ करना: स्कैन रिज़ल्ट हैंडल करना

एक बार फ़ाइल स्कैन पूरा हो जाए, सबसे महत्वपूर्ण बात है कि उसे एक स्पष्ट स्थिति में ले जाया जाए और अगला कदम प्रत्याशित बनाया जाए। यदि आप फ़ाइल अपलोड की वायरस स्कैनिंग बना रहे हैं, तो स्कैन रिज़ल्ट को एक गेट की तरह ट्रीट करें: गेट कहे बिना कुछ भी डाउनलोडेबल न हो।

एक सरल सेट ऑफ़ आउटकम अधिकांश सिस्टम्स को कवर करता है:

• Clean: फ़ाइल को क्वारंटाइन से रिलीज़ करें और सामान्य एक्सेस की अनुमति दें।
• Infected: एक्सेस स्थायी रूप से ब्लॉक करें और इंफेक्टेड-फाइल वर्कफ़्लो ट्रिगर करें।
• Unsupported: स्कैनर इस प्रकार का मूल्यांकन नहीं कर सकता (या यह पासवर्ड-प्रोटेक्टेड है)। इसे ब्लॉक रखें।
• Scan error: अस्थायी विफलता (टाइमआउट, सर्विस अनुपलब्ध)। इसे ब्लॉक रखें।

उपयोगकर्ता संदेश स्पष्ट और शांत रखें। "Your account is compromised" जैसे डरावने शब्दों से बचें। बेहतर होगा: “फ़ाइल की जांच की जा रही है। आप काम जारी रख सकते हैं।” यदि फ़ाइल ब्लॉक हो गई है, तो उपयोगकर्ता को बताएं कि अगला क्या कर सकता है: “एक अलग फ़ाइल प्रकार अपलोड करें” या “कृपया बाद में पुनः प्रयास करें।” Unsupported फ़ाइलों के लिए विशिष्ट बनें (उदाहरण: “Encrypted archives को स्कैन नहीं किया जा सकता”)।

इंफेक्टेड फ़ाइलों के लिए, शुरू में तय करें कि आप डिलीट करेंगे या रखेंगे। डिलीट करना सरल है और रिस्क घटाता है। रखना ऑडिट के लिए मददगार हो सकता है, पर केवल तब जब आप उसे एक अलग, पृथक क्षेत्र में सख़्त एक्सेस के साथ और सीमित रिटेंशन के साथ रखें, और रिकॉर्ड करें कि किसे उसे देखना है (आदर्श रूप से, किसी को नहीं सिवाय सुरक्षा एडमिन्स के)।

रीट्राइज़ उपयोगी हैं, पर केवल उन त्रुटियों के लिए जो अस्थायी लगती हैं। एक छोटा रीट्राइ नीति रखें ताकि अनंत बैकलॉग न बन जाए:

• टाइमआउट और स्कैनर डाउनटाइम पर retry करें।
• “infected” या “unsupported” पर retry न करें।
• retries को कैप करें (उदाहरण: 3) और फिर failed मार्क कर दें।
• अटेम्प्ट्स के बीच बैकऑफ़ रखें ताकि ओवरलोड न हो।

आख़िर में, बार-बार विफलताएँ ऑप्स की समस्या मानें, यूज़र की नहीं। यदि छोटी अवधि में बहुत सी फ़ाइलें “scan error” पर जा रही हैं, तो अपनी टीम को अलर्ट करें और नए रिलीज़ को अस्थायी रूप से रोक दें। AppMaster में आप इन स्टेट्स को डेटाबेस में मॉडल कर सकते हैं और बिल्ट-इन मैसेजिंग मॉड्यूल के ज़रिए नोटिफिकेशन रूट कर सकते हैं ताकि सही लोग जल्दी से सूचित हों।

उदाहरण परिदृश्य: बहुत सारे दस्तावेज़ों वाला कस्टमर पोर्टल

एक कस्टमर पोर्टल क्लाइंट्स को प्रत्येक प्रोजेक्ट के लिए इनवॉइस और कॉन्ट्रैक्ट अपलोड करने देता है। यह एक सामान्य जगह है जहाँ फ़ाइल अपलोड की वायरस स्कैनिंग मायने रखती है, क्योंकि यूज़र्स अपने डेस्कटॉप से जो कुछ भी ड्रैग करते हैं वह अपलोड हो सकता है, उसमे दूसरे लोगों से फॉरवर्ड किए गए फ़ाइल भी शामिल होते हैं।

जब कोई कस्टमर PDF अपलोड करता है, पोर्टल उसे एक अस्थायी, प्राइवेट लोकेशन में सेव करता है और एक डेटाबेस रिकॉर्ड बनाता है जिसका status Pending scan पर सेट होता है। फ़ाइल अभी डाउनलोड करने योग्य नहीं दिखाई देती। एक स्कैनिंग वर्कर कतार से फ़ाइल उठाता है, स्कैन चलाता है, फिर रिकॉर्ड को Clean या Blocked पर अपडेट करता है।

UI में, ग्राहक दस्तावेज़ को तुरंत देखता है, पर उसके साथ एक स्पष्ट Pending बैज होता है। फ़ाइलनाम और आकार दिखाई देते हैं ताकि वे जान लें कि अपलोड सफल रहा, पर Download बटन तब तक डिसेबल रहता है जब तक स्कैन clean न हो। यदि स्कैन अपेक्षा से ज़्यादा समय लेता है, पोर्टल सरल संदेश दिखा सकता है जैसे “हम इस फ़ाइल की सुरक्षा की जांच कर रहे हैं। एक मिनट में पुनः प्रयास करें।”

यदि स्कैनर किसी दस्तावेज़ को फ़्लैग कर देता है, ग्राहक को Blocked के साथ एक संक्षेप, गैर-तकनीकी नोट दिखेगा: “यह फ़ाइल सुरक्षा जांच में असफल हुई।” सपोर्ट और एडमिन्स को एक अलग व्यू मिलता है जिसमें स्कैन कारण और अगले कदम होते हैं। वे कर सकते हैं:

• इसे ब्लॉक रखकर नया अपलोड अनुरोध करें
• इसे डिलीट करें और कारण रिकॉर्ड करें
• नीति अनुमति देने पर ही false positive के रूप में मार्क करें

विवादों के दौरान (“मैंने यह कल अपलोड किया था और आपने खो दिया”) अच्छे लॉग्स मायने रखते हैं। upload received, scan started, scan finished, status changed, और किसने क्या किया—इनके timestamps रखें। साथ ही फ़ाइल हैश, मूल फ़ाइलनाम, uploader account, IP एड्रेस, और स्कैनर रिज़ल्ट कोड स्टोर करें। AppMaster में Data Designer और सरल Business Process फ्लो इन स्टेट्स और ऑडिट फ़ील्ड्स को संभाल सकते हैं बिना क्वारंटाइन्ड फ़ाइलों को सामान्य उपयोगकर्ताओं के सामने एक्सपोज़ किए।

सामान्य गलतियाँ जो असली सिक्योरिटी गैप बनाती हैं

अधिकतर अपलोड सिक्योरिटी विफलताएँ बड़े हैक नहीं होतीं। वे छोटे डिज़ाइन चुनाव होते हैं जो गलती से असुरक्षित फ़ाइल को सामान्य दस्तावेज़ जैसा व्यवहार करने देते हैं।

एक क्लासिक समस्या रेस है: ऐप अपलोड स्वीकार कर लेता है, एक “डाउनलोड” URL वापस दे देता है, और यूज़र (या कोई और सर्विस) स्कैन खत्म होने से पहले फ़ाइल को फ़ेच कर लेता है। यदि आप फ़ाइल अपलोड की वायरस स्कैनिंग करते हैं, तो "uploaded" और "available" को अलग-अलग स्टेट्स मानें।

बार-बार मिलने वाली गलतियाँ:

• क्लीन और क्वारंटाइन्ड फ़ाइलों का एक ही बकेट/फ़ोल्डर में मिश्रण कर देना, फिर नामकरण नियमों पर भरोसा करना। एक गलत अनुमति या पाथ गेस करते ही क्वारंटाइन बेकार हो जाता है।
• फ़ाइल एक्सटेंशन, MIME टाइप या क्लाइंट-साइड चेक्स पर भरोसा करना। अटैकर कोई भी फ़ाइल .pdf कर सकता है और आपका UI अनदेखा कर देगा।
• स्कैनर डाउनटाइम की योजना न बनाना। अगर स्कैनर स्लो या ऑफ़लाइन है, फ़ाइलें हमेशा के लिए “pending” में बैठ सकती हैं और टीमें असुरक्षित मैन्युअल ओवरराइड जोड़ने लगती हैं।
• बैकग्राउंड वर्कर्स को मुख्य API जितने authorization नियम लागू न करना। एक वर्कर जिसे “कोई भी फ़ाइल पढ़ने” की अनुमति है, एक ख़ामोश प्रिविलेज एस्केलेशन है।
• क्वारंटाइन्ड आइटम्स के लिए अनुमान लगाने योग्य IDs प्रकाशित करना (जैसे क्रमागत नम्बर), भले ही आप सोचते हैं कि कंटेंट प्रोटेक्टेड है।

टेस्टिंग भी एक गैप है। टीमें कुछ छोटे, क्लीन फ़ाइलों के साथ टेस्ट कर के काम खत्म मान लेती हैं। आपको बड़ी अपलोड, करप्टेड फ़ाइलें, और पासवर्ड-प्रोटेक्टेड दस्तावेज़ भी आज़माने चाहिए, क्योंकि यही वे मामले हैं जहाँ स्कैनर और पार्सर फेल या टाइमआउट होते हैं।

एक साधारण वास्तविक दुनिया का उदाहरण: एक कस्टमर पोर्टल यूज़र एक “contract.pdf” अपलोड करता है जो असल में एक आर्काइव के अंदर रिनेम किया हुआ एक executable है। यदि आपका पोर्टल उसे तुरंत सर्व कर देता है, या आपका सपोर्ट टीम क्वारंटाइन तक बिना उचित चेक के पहुँच सकता है, तो आपने सीधे तौर पर दूसरों तक डिलीवरी का रास्ता खोल दिया है।

शिप करने से पहले त्वरित चेकलिस्ट

फ़ाइल अपलोड की वायरस स्कैनिंग शिप करने से पहले, उन जगहों पर एक अंतिम पास करें जहाँ टीमें आमतौर पर मान लेती हैं “ठीक है” और बाद में पाती हैं कि ठीक नहीं था। लक्ष्य सरल है: कोई असुरक्षित फ़ाइल तब तक पठनीय न बने सिर्फ़ इसलिए कि किसी ने URL गेस कर लिया, रिक्वेस्ट को रीट्राय किया, या पुरानी कैश्ड लिंक का इस्तेमाल किया।

यूज़र फ्लो से शुरू करें। कोई भी डाउनलोड, प्रिव्यू, या “open file” एक्शन को अनुरोध के समय फ़ाइल के वर्तमान स्कैन स्टेटस पर फिर से चेक करना चाहिए, सिर्फ़ अपलोड के समय नहीं। यह आपको रेस कंडीशंस (कोई तुरंत क्लिक कर दे), देर से आए स्कैन रिज़ल्ट्स, और उन किनारों से बचाता है जहाँ फ़ाइल को फिर से स्कैन किया गया हो।

न्यूनतम बेसलाइन के रूप में यह प्री-शिप चेकलिस्ट उपयोग करें:

• क्वारंटाइन स्टोरेज डिफ़ॉल्ट रूप से प्राइवेट है: कोई पब्लिक बकेट एक्सेस नहीं, कोई “anyone with the link” नहीं, और कच्चे ऑब्जेक्ट स्टोरेज से डायरेक्ट सर्व नहीं।
• हर फ़ाइल रिकॉर्ड का एक owner (यूज़र, टीम, या टेनेन्ट) और एक स्पष्ट लाइफ़साइकिल स्टेट जैसे pending, clean, infected, या failed हो।
• आपकी स्कैनिंग कतार और वर्कर्स के bounded retries, स्पष्ट बैकऑफ नियम, और अलर्ट हों जब आइटम अटके या बार-बार फेल हों।
• अपलोड्स, स्कैन रिज़ल्ट्स, और डाउनलोड प्रयासों (ब्लॉक किए गए प्रयास सहित) के लिए ऑडिट लॉग्स मौजूद हों—किसने, कब, और क्यों।
• दुर्लभ मामलों के लिए मैन्युअल ओवरराइड मौजूद हो, पर वह एडमिन-ओनली हो, रिकॉर्डेड हो, और समय-सीमित हो (कोई चुपचाप “mark clean” बटन न हो)।

अंत में, सुनिश्चित करें कि आप सिस्टम को एंड-टू-एंड ऑब्ज़र्व कर सकते हैं। आपको यह उत्तर देने में सक्षम होना चाहिए: “अभी कितनी फ़ाइलें pending scan में हैं?” और “कौन से टेनेन्ट फेल्यर्स देख रहे हैं?” यदि आप AppMaster पर बना रहे हैं, तो फ़ाइल लाइफ़साइकिल को Data Designer में मॉडल करें और बिज़नेस प्रोसेस एडिटर में स्टेट चेक्स लागू करें ताकि नियम वेब और मोबाइल दोनों पर सुसंगत रहें।

अगले कदम: डिज़ाइन को काम करने वाले ऐप में बदलना

सबसे पहले अपने फ़ाइलों की बिल्कुल वही स्थितियाँ लिख कर रखें जो वे हो सकती हैं, और हर स्थिति में क्या अनुमति है वह तय करें। इसे सरल और स्पष्ट रखें: “uploaded”, “queued”, “scanning”, “clean”, “infected”, “scan_failed”。 फिर हर एक के बगल में एक्सेस नियम जोड़ें। कौन फ़ाइल को देख सकता है, डाउनलोड कर सकता है, या हटाकर सकता है जब वह अभी भी अनट्रस्टेड हो?

अगला, वह तरीका चुनें जो आपके वॉल्यूम और यूज़र एक्सपीरियंस लक्ष्यों से मेल खाता हो। इनलाइन स्कैन समझाने में सरल है, पर यह अपलोड को स्लो बना सकता है। ऐसिंक्रोनस स्कैन दस्तावेज़-भारी ऐप्स के लिए बेहतर पैमाना देता है, पर यह स्टेट्स, कतारें और “pending” UI जोड़ता है।

डिज़ाइन से बिल्ड तक जाने का एक व्यावहारिक तरीका है कि आप प्रोटोटाइप में पूरा फ्लो एंड-टू-एंड रियलिस्टिक दस्तावेज़ों (PDFs, Office फ़ाइलें, इमेजेज़, आर्काइव्स) और वास्तविक उपयोगकर्ता व्यवहार (कई अपलोड, कैंसल करना, रीट्राइज़) के साथ टेस्ट करें। केवल यह न सत्यापित करें कि “स्कैनर काम करता है”। सुनिश्चित करें कि ऐप कभी भी गलती से क्वारंटाइन्ड फ़ाइल सर्व न करे।

यहाँ एक सरल बिल्ड प्लान है जिसे आप एक सप्ताह में कर सकते हैं:

• फ़ाइल स्टेट्स, ट्रांज़िशन और एक्सेस नियम एक पन्ने पर परिभाषित करें
• इनलाइन, ऐसिंक्रोनस, या हाइब्रिड स्कैनिंग चुनें और ट्रैडऑफ़्स दस्तावेज़ करें
• अपलोड -> क्वारंटाइन स्टोरेज -> स्कैन जॉब -> रिज़ल्ट कॉलबैक लागू करें, ऑडिट लॉग्स के साथ
• उपयोगकर्ताओं को दिखने वाले UI स्टेट्स बनाएं (pending, blocked, failed, approved)
• पहले दिन से मॉनिटरिंग जोड़ें: बैकलॉग साइज, फेल्यर रेट, और time-to-clean

यदि आप नो-कोड के बिना बन रहे हैं, तो AppMaster आपकी मदद कर सकता है फ़ाइल मेटाडेटा (status, owner, checksum, timestamps) मॉडल करने में, अपलोड और रिव्यू स्क्रीन बनाने में, और बिज़नेस लॉजिक तथा कतार-स्टाइल प्रोसेसिंग को ऑर्केस्ट्रेट करने में। इससे आप जल्दी वास्तविक प्रोडक्ट फ्लो टेस्ट कर पाएँगे और फिर उन हिस्सों को कड़ा कर सकेंगे जो महत्वपूर्ण हैं: परमिशन्स, स्टोरेज विभाजन, और विश्वसनीय retries।

अंत में, यह तय करें कि संख्याओं में “अच्छा” क्या दिखता है। लॉन्च से पहले अलर्ट थ्रेशोल्ड सेट करें ताकि आप अटक गए स्कैन और बढ़ते फेल्यर्स को यूज़र्स से पहले नोटिस कर सकें।