आर्काइव समर्थन

अवलोकन​

Glasswall Halo आर्काइव फ़ाइलों के लिए उन्नत सुरक्षा प्रदान करता है। यह शक्तिशाली सुविधा प्रत्येक आर्काइव के भीतर मौजूद हर एक फ़ाइल की सुरक्षा के लिए अत्याधुनिक Glasswall Engine का उपयोग करती है। यह न केवल फ़ाइलों को सुरक्षित रखती है, बल्कि पूरे आर्काइव को समर्थित फ़ॉर्मेट में बुद्धिमानी से पुनः संपीड़ित भी करती है। इस उन्नत कार्यक्षमता के साथ, आपकी आर्काइव फ़ाइलें प्रभावी रूप से सुरक्षित और निर्बाध उपयोग के लिए अनुकूलित हो जाती हैं।

समर्थित इनपुट प्रकार​

असुरक्षित​

• Zip - (bzip2 प्रकार के compression का समर्थन करता है)
• 7-Zip
• Gzip
• Rar
• Tar

सुरक्षित​

• Zip

यह कैसे काम करता है​

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

प्रत्येक फ़ाइल को प्रोसेसिंग के लिए शक्तिशाली Glasswall engine के अधीन किया जाता है। आर्काइव के भीतर की सभी फ़ाइलों के प्रोसेस हो जाने के बाद, प्लेटफ़ॉर्म मूल संरचना को बनाए रखते हुए आर्काइव को फिर से संकलित करता है। इस प्रक्रिया के अपेक्षित परिणाम निम्नलिखित हैं:

1. सुरक्षा और sanitisation: Glasswall Engine सुनिश्चित करता है कि प्रत्येक फ़ाइल पूरी तरह सुरक्षित और sanitised हो, जिससे संभावित खतरों और कमजोरियों को समाप्त किया जा सके।

2. policies के अनुपालन: Glasswall Halo निर्दिष्ट policies का पालन करता है, जिससे यह सुनिश्चित होता है कि परिणामी आर्काइव निर्धारित सुरक्षा और कंटेंट प्रबंधन कॉन्फ़िगरेशन के अनुरूप हो।

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

इस मज़बूत प्रोसेसिंग वर्कफ़्लो का पालन करके, Halo आर्काइव्स के लिए फ़ाइल सुरक्षा, policy अनुपालन और अखंडता संरक्षण का सर्वोच्च स्तर सुनिश्चित करता है।

अपेक्षित परिणाम​

फ़ाइल प्रकार​

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

इस समाधान को लागू करके, Glasswall Halo निर्बाध संगतता की गारंटी देता है और मूल फ़ाइलों तथा फ़ोल्डर संगठन की अखंडता को सुरक्षित रखता है, यहाँ तक कि असमर्थित आर्काइव प्रकारों का सामना होने पर भी। इससे यह सुनिश्चित होता है that डेटा सुलभ और अपरिवर्तित बना रहे, भले ही लाइसेंसिंग सीमाओं के कारण कोई प्रतिबंध हों।

फ़ाइल सामग्री​

अधिकांश परिस्थितियों में, किसी archive को process करते समय, Halo archive के भीतर किसी फ़ाइल को API के माध्यम से वापस करने से पहले उसके clean version से बदल देता है। हालांकि, कुछ स्थितियों में platform को archive के भीतर किसी विशेष फ़ाइल को process करने में कठिनाई हो सकती है। ऐसे मामलों में, यदि कुछ फ़ाइलें सफलतापूर्वक process हो जाती हैं जबकि अन्य नहीं, तो unprocessable फ़ाइल को .txt फ़ाइल से प्रतिस्थापित किया जाएगा। इस replacement फ़ाइल की सामग्री यह बताएगी कि फ़ाइल को process क्यों नहीं किया जा सकता।

इस approach का उपयोग करके, Halo यह सुनिश्चित करता है कि archive के भीतर अधिकांश फ़ाइलें प्रभावी रूप से process हों और clean स्थिति में वापस की जाएँ। जिन फ़ाइलों में processing issues आते हैं, उनके लिए स्पष्ट और जानकारीपूर्ण स्पष्टीकरण दिए जाते हैं, जिससे users un-processable फ़ाइलों के पीछे के कारण समझ सकें।

निम्नलिखित परिस्थितियाँ अपेक्षित हैं:

रीबिल्ड​

• Archive का rebuild किया जा रहा है और entry की अनुमति है - original फ़ाइल का उपयोग करता है
• Archive का rebuild किया जा रहा है और entry की अनुमति नहीं है - एक text फ़ाइल (उसी नाम से) से बदलें जिसमें लिखा हो "file disallowed"
• Archive का rebuild किया जा रहा है और entry unsupported file type है - एक text फ़ाइल (उसी नाम से) से बदलें जिसमें लिखा हो "unsupported file type"
• Archive का rebuild किया जा रहा है और entry को rebuild करते समय Engine विफल हो जाता है - एक text फ़ाइल (उसी नाम से) से बदलें जिसमें लिखा हो "unable to rebuild file"
• Archive का rebuild किया जा रहा है और entry सफलतापूर्वक rebuild हो जाती है - rebuilt फ़ाइल का उपयोग करें

विश्लेषण​

• Archive का analyse किया जा रहा है और entry की अनुमति है - एक text फ़ाइल (उसी नाम से) से बदलें जिसमें लिखा हो "file allowed by policy, no analyse needed"
• Archive का analyse किया जा रहा है और entry की अनुमति नहीं है - एक text फ़ाइल (उसी नाम से) से बदलें जिसमें लिखा हो "file disallowed"
• Archive का analyse किया जा रहा है और entry unsupported file type है - एक text फ़ाइल (उसी नाम से) से बदलें जिसमें लिखा हो "unsupported file type"
• Archive का analyse किया जा रहा है और entry का analyse करते समय Engine विफल हो जाता है - एक text फ़ाइल (उसी नाम से) से बदलें जिसमें लिखा हो "unable to analyse file"
• Archive का analyse किया जा रहा है और entry सफलतापूर्वक rebuild हो जाती है - फ़ाइल के analysis का उपयोग करें

V3 endpoint का उपयोग करते समय archives के सभी मामलों में एक manifest.json भी output किया जाता है, जो archive के भीतर सभी फ़ाइलों के processing result का विवरण देता है और archive को unpack किए बिना उसे समझने में मदद के लिए उपयोग किया जा सकता है।

संपीड़न प्रकार​

जब फ़ाइलों को Halo के माध्यम से प्रोसेस किया जाता है, तो यह Bzip और Gzip संपीड़न प्रकारों को अलग-अलग फ़ाइलों के रूप में मानता है। परिणामस्वरूप, प्रोसेसिंग के दौरान कोई manifest.json जनरेट नहीं होता। हालांकि, इन संपीड़ित फ़ाइलों की प्रोसेसिंग फिर भी archive processing के नियमों का पालन करती है। यदि किसी संपीड़ित फ़ाइल के भीतर कोई archive मौजूद है, तो manifest.json बनाया जाता है और archive संरचना के सबसे ऊपरी स्तर पर आउटपुट किया जाता है।

किसी संपीड़ित फ़ाइल के लिए file type response header को compressed_file पर सेट किया जाता है, जो उसके संपीड़ित स्वरूप को दर्शाता है।

जब किसी संपीड़ित फ़ाइल के लिए analysis report जनरेट की जाती है, तो भीतर की फ़ाइल के सही decompression को सुनिश्चित करने के लिए उसका नाम बदला जाता है। उदाहरण के लिए, यदि मूल फ़ाइल का नाम test.pdf.bz2 है, तो report फ़ाइल का नाम बदलकर test.pdf.report.xml.bz2 कर दिया जाता है। यह naming convention report और संबंधित संपीड़ित फ़ाइल के बीच स्पष्ट संबंध सुनिश्चित करता है, जिससे सही decompression और उसके बाद analysis में सुविधा होती है।

इन उपायों को लागू करके, Halo संपीड़ित फ़ाइलों के लिए एकसमान handling बनाए रखता है, सटीक reports तैयार करता है, और analysis workflow के दौरान प्रोसेस की गई फ़ाइलों की अखंडता को सुरक्षित रखता है।

policy config​

Glasswall API endpoints Content Management Flags के लिए व्यापक समर्थन प्रदान करते हैं, जिससे archive के भीतर अलग-अलग फ़ाइलों पर सूक्ष्म नियंत्रण संभव होता है। यह configuration आपको archive के भीतर प्रत्येक file type के लिए विशिष्ट actions परिभाषित करने में सक्षम बनाती है। इस configuration में प्रत्येक file type के लिए default value allow - 0 पर सेट होती है। हालांकि, आपके पास अन्य समर्थित actions चुनने की भी सुविधा है, जैसे sanitise - 1 या disallow - 2।

Content Management Flags का उपयोग करके, आप archives के भीतर विभिन्न file types के प्रबंधन को सटीक रूप से नियंत्रित कर सकते हैं, जिससे यह सुनिश्चित होता है कि प्रत्येक file को आपकी इच्छित configuration के आधार पर उपयुक्त स्तर का management और security मिले। यह सुविधा Glasswall Halo API के माध्यम से archives के भीतर files को प्रभावी ढंग से प्रबंधित करने के लिए उपलब्ध समग्र control और customization विकल्पों को बेहतर बनाती है।

निम्नलिखित file types archive configuration के अंतर्गत समर्थित हैं:

"ArchiveConfig": {
    "bmp": 1,
    "doc": 1,
    "docx": 1,
    "emf": 1,
    "gif": 1,
    "jpg": 1,
    "wav": 1,
    "elf": 1,
    "pe": 1,
    "mp4": 1,
    "mpg": 1,
    "pdf": 1,
    "png": 1,
    "ppt": 1,
    "pptx": 1,
    "tif": 1,
    "wmf": 1,
    "xls": 1,
    "xlsx": 1,
    "mp3": 1,
    "rtf": 1,
    "coff": 1,
    "macho": 1,
    "unknown": 1
}

archives के भीतर policy कैसे लागू की जाती है​

Glasswall Halo के माध्यम से processed archives, प्रदान की गई policy का पदानुक्रमित तरीके से पालन करते हैं। policies के अनुप्रयोग का मार्गदर्शन करने वाला मूल सिद्धांत यह है कि प्रारंभिक request को पूरा करने का प्रयास करते हुए, दी गई configuration के आधार पर सबसे कठोर outcome का चयन किया जाए। इसका अर्थ है कि कुछ मामलों में request में निर्दिष्ट ContentManagementFlags को प्राथमिकता मिलती है।

इसके अतिरिक्त, जब return-executable-file parameter को false पर सेट किया जाता है, तो यह supplied archive configuration की परवाह किए बिना archives के भीतर सभी executables पर एक समग्र प्रतिबंध के रूप में कार्य करता है।

इसके अलावा, ArchiveConfig section पर भी विचार किया जाता है, और उसके भीतर के values को ध्यान में रखा जाता है। यदि इस section के values सबसे कठोर outcome का प्रतिनिधित्व करते हैं, तो archives के परिणामी outcome को निर्धारित करने के लिए उनका उपयोग किया जाएगा।

इस पदानुक्रमित दृष्टिकोण का पालन करके और प्रदान किए गए parameters को शामिल करके, Halo सुनिश्चित करता है कि policies प्रभावी रूप से लागू हों, जिससे archive processing पर अधिकतम security और control प्रदान किया जा सके।

Outcome matrix​

यह उदाहरण एक Word दस्तावेज़ पर आधारित है जिसमें एक आंतरिक हाइपरलिंक शामिल है:

CMF = WordContentManagement:InternalHyperlinks मान

AC = ArchiveConfig:doc मान

REF = return-executable-file मान

सीमाएँ​

यह सुनिश्चित करने के लिए कि सिस्टम सुचारू रूप से काम करे और ओवरलोडिंग से बचे, archives को process करने के लिए कुछ विशिष्ट सीमाएँ निर्धारित की गई हैं। ये सीमाएँ इस प्रकार हैं:

• अधिकतम file count 500। इसका मतलब है कि unpack करने पर जिन archives में 500 से अधिक files होंगी, वे process नहीं होंगी।
• अधिकतम file size 500 MB। जिन archives के अंदर 500 MB से अधिक files होंगी, वे process होने में विफल होंगी।
• अधिकतम archive count 50। यह किसी भी nested archives (अन्य archives के अंदर मौजूद archives) को ट्रैक करता है। यदि 50 से अधिक nested archives मिलती हैं, तो पूरी file विफल हो जाएगी।
• अधिकतम nesting count 5। यह दर्शाता है कि किसी file में nesting की कितनी layers हो सकती हैं। यह सीमा पूरी file के process होने को विफल नहीं करती, लेकिन 5 से अधिक archive layers में wrapped किसी भी file को process नहीं किया जाएगा और इसके बजाय 5वें स्तर पर एक placeholder text file रखी जाएगी। यह nesting केवल archives के अंदर archives पर लागू होती है, folders की गिनती नहीं होती।

ये सभी सीमाएँ service configuration के माध्यम से configurable हैं।