Sokongan arkib

Gambaran keseluruhan​

Glasswall Halo menawarkan perlindungan lanjutan untuk fail arkib. Ciri berkuasa ini menggunakan Glasswall Engine yang canggih untuk melindungi setiap fail dalam arkib. Ia bukan sahaja melindungi fail, malah turut memampatkan semula keseluruhan arkib secara pintar ke dalam format yang disokong. Dengan fungsi yang dipertingkatkan ini, fail arkib anda dilindungi dengan berkesan dan dioptimumkan untuk penggunaan yang lancar.

Jenis input yang disokong​

Tidak dilindungi​

• Zip - (menyokong jenis pemampatan bzip2)
• 7-Zip
• Gzip
• Rar
• Tar

Dilindungi​

• Zip

Bagaimanakah ia berfungsi​

Apabila menerima arkib, Halo melaksanakan aliran kerja pemprosesan yang menyeluruh. Pertama, ia menyahmampatkan arkib, dengan menelusuri sehingga lima tahap arkib bersarang. Pada setiap tahap, platform memproses setiap fail bukan arkib yang ditemui secara berasingan.

Setiap fail diproses menggunakan Glasswall engine yang berkuasa. Setelah semua fail dalam arkib diproses, platform menyusun semula arkib sambil mengekalkan struktur asal. Hasil yang dijangkakan daripada proses ini adalah seperti berikut:

1. Perlindungan dan sanitasi: Glasswall Engine memastikan setiap fail dilindungi dan disanitasi secara menyeluruh, sekali gus menghapuskan potensi ancaman dan kelemahan.

2. Pematuhan terhadap policy: Glasswall Halo mematuhi policy yang ditetapkan, memastikan arkib yang terhasil sejajar dengan konfigurasi keselamatan dan pengurusan kandungan yang ditetapkan.

3. Pengekalan format: arkib dikompil semula dengan cara yang mengekalkan struktur asal, sambil mengekalkan organisasi hierarki dan integriti fail.

Dengan mengikuti aliran kerja pemprosesan yang teguh ini, Halo memastikan tahap perlindungan fail, pematuhan policy dan pengekalan integriti yang tertinggi untuk arkib.

Hasil yang dijangkakan​

Jenis fail​

Walaupun Glasswall Halo sangat berkeupayaan, terdapat keadaan di mana jenis arkib tertentu tidak dapat disokong untuk pemampatan semula disebabkan sekatan pelesenan. Dalam kes sedemikian, platform menggunakan pendekatan alternatif: ia memampatkan semula jenis arkib yang tidak disokong ke dalam format Zip yang serasi secara universal. Yang penting, semasa proses ini, platform memastikan bahawa semua jenis fail dan struktur folder dalam arkib Zip yang terhasil kekal tidak berubah sepenuhnya.

Dengan melaksanakan penyelesaian ini, Glasswall Halo menjamin keserasian yang lancar dan mengekalkan integriti fail asal serta organisasi folder, walaupun apabila berdepan dengan jenis arkib yang tidak disokong. Ini memastikan data kekal boleh diakses dan tidak diubah, walaupun terdapat sebarang batasan yang disebabkan oleh kekangan pelesenan.

Kandungan fail​

Dalam kebanyakan senario, apabila memproses arkib, Halo menggantikan fail dalam arkib dengan versi yang bersih sebelum mengembalikannya melalui API. Walau bagaimanapun, terdapat situasi di mana platform mungkin menghadapi kesukaran untuk memproses fail tertentu dalam arkib. Dalam kes sedemikian, jika sesetengah fail berjaya diproses manakala yang lain tidak, fail yang tidak boleh diproses akan digantikan dengan fail .txt. Kandungan fail pengganti ini akan memberikan penjelasan tentang sebab fail tersebut tidak dapat diproses.

Dengan menggunakan pendekatan ini, Halo memastikan bahawa majoriti fail dalam arkib diproses dengan berkesan dan dikembalikan dalam keadaan bersih. Bagi mana-mana fail yang menghadapi isu pemprosesan, penjelasan yang jelas dan bermaklumat disediakan, membolehkan pengguna memahami sebab di sebalik fail yang tidak boleh diproses.

Senario berikut adalah dijangka:

Bina semula​

• Arkib sedang dibina semula dan entri dibenarkan - menggunakan fail asal
• Arkib sedang dibina semula dan entri tidak dibenarkan - gantikan dengan fail teks (nama yang sama) yang menyatakan "file disallowed"
• Arkib sedang dibina semula dan entri ialah jenis fail yang tidak disokong - gantikan dengan fail teks (nama yang sama) yang menyatakan "unsupported file type"
• Arkib sedang dibina semula dan Engine gagal semasa membina semula entri - gantikan dengan fail teks (nama yang sama) yang menyatakan "unable to rebuild file"
• Arkib sedang dibina semula dan entri berjaya dibina semula - gunakan fail yang dibina semula

Analisis​

• Arkib sedang dianalisis dan entri dibenarkan - gantikan dengan fail teks (nama yang sama) yang menyatakan "file allowed by policy, no analyse needed"
• Arkib sedang dianalisis dan entri tidak dibenarkan - gantikan dengan fail teks (nama yang sama) yang menyatakan "file disallowed"
• Arkib sedang dianalisis dan entri ialah jenis fail yang tidak disokong - gantikan dengan fail teks (nama yang sama) yang menyatakan "unsupported file type"
• Arkib sedang dianalisis dan Engine gagal semasa menganalisis entri - gantikan dengan fail teks (nama yang sama) yang menyatakan "unable to analyse file"
• Arkib sedang dianalisis dan entri berjaya dibina semula - gunakan analisis fail

Dalam semua kes arkib apabila menggunakan endpoint V3, manifest.json juga dihasilkan yang memperincikan hasil pemprosesan semua fail di dalam arkib dan boleh digunakan untuk membantu memahami arkib tanpa perlu menyahpekannya.

Jenis pemampatan​

Apabila memproses fail melalui Halo, ia menganggap jenis pemampatan Bzip dan Gzip sebagai fail individu. Oleh itu, tiada manifest.json dijana semasa pemprosesan. Walau bagaimanapun, pemprosesan fail termampat ini masih mengikut peraturan pemprosesan arkib. Jika fail termampat mengandungi arkib di dalamnya, manifest.json akan dicipta dan dikeluarkan pada tahap tertinggi struktur arkib.

Pengepala respons jenis fail untuk fail termampat ditetapkan kepada compressed_file, yang menunjukkan sifatnya sebagai fail termampat.

Apabila laporan analisis dijana untuk fail termampat, ia melalui proses penamaan semula untuk memastikan penyahmampatan fail dalaman yang betul. Sebagai contoh, jika fail asal dinamakan test.pdf.bz2, fail laporan dinamakan semula sebagai test.pdf.report.xml.bz2. Konvensyen penamaan ini memastikan kaitan yang jelas antara laporan dengan fail termampat yang sepadan, sekali gus memudahkan penyahmampatan yang betul dan analisis seterusnya.

Dengan melaksanakan langkah-langkah ini, Halo mengekalkan pengendalian fail termampat yang konsisten, menghasilkan laporan yang tepat, dan memelihara integriti fail yang diproses sepanjang aliran kerja analisis.

Konfigurasi policy​

Endpoint API Glasswall menyediakan sokongan yang meluas untuk Content Management Flags, membolehkan kawalan terperinci ke atas fail individu dalam arkib. Konfigurasi ini membolehkan anda mentakrifkan tindakan khusus bagi setiap jenis fail dalam arkib. Nilai lalai bagi setiap jenis fail dalam konfigurasi ini ditetapkan kepada allow - 0. Walau bagaimanapun, anda juga mempunyai fleksibiliti untuk memilih tindakan sokongan alternatif, seperti sanitise - 1 atau disallow - 2.

Dengan menggunakan Content Management Flags, anda boleh mengawal dengan tepat cara pengendalian jenis fail yang berbeza dalam arkib, memastikan setiap fail menerima tahap pengurusan dan keselamatan yang sesuai berdasarkan konfigurasi yang anda kehendaki. Ciri ini meningkatkan kawalan keseluruhan dan pilihan penyesuaian yang tersedia untuk mengurus fail dalam arkib dengan berkesan melalui Glasswall Halo API.

Jenis fail berikut disokong di bawah konfigurasi arkib:

"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
}

Bagaimanakah policy digunakan dalam arkib​

Arkib yang diproses melalui Glasswall Halo mematuhi policy yang diberikan secara hierarki. Prinsip asas yang membimbing penggunaan policy ialah memilih hasil yang paling ketat berdasarkan konfigurasi yang diberikan sambil cuba memenuhi permintaan awal. Ini bermakna dalam sesetengah kes, ContentManagementFlags yang dinyatakan dalam permintaan diberi keutamaan.

Selain itu, apabila parameter return-executable-file ditetapkan kepada false, ia berfungsi sebagai sekatan menyeluruh untuk semua fail boleh laku dalam arkib, tanpa mengira konfigurasi arkib yang dibekalkan.

Tambahan pula, bahagian ArchiveConfig juga diambil kira, dengan mempertimbangkan nilai di dalamnya. Jika nilai dalam bahagian ini mewakili hasil yang paling ketat, nilai tersebut akan digunakan untuk menentukan hasil akhir arkib.

Dengan mengikuti pendekatan hierarki ini dan menggabungkan parameter yang diberikan, Halo memastikan bahawa policy dikuatkuasakan dengan berkesan, memberikan keselamatan maksimum dan kawalan ke atas pemprosesan arkib.

Matriks hasil​

Contoh ini berdasarkan dokumen Word yang mengandungi hiperpautan dalaman:

CMF = nilai WordContentManagement:InternalHyperlinks

AC = nilai ArchiveConfig:doc

REF = nilai return-executable-file

Had​

Untuk memastikan sistem beroperasi dengan lancar dan mengelakkan beban berlebihan, had tertentu telah ditetapkan untuk memproses arkib. Had ini adalah seperti berikut:

• Bilangan fail maksimum ialah 500. Ini bermaksud mana-mana arkib yang mengandungi lebih daripada 500 fail apabila dinyahpek tidak akan diproses.
• Saiz fail maksimum ialah 500 MB. Mana-mana arkib yang mengandungi lebih daripada 500 MB fail di dalamnya akan gagal diproses.
• Bilangan arkib maksimum ialah 50. Ini menjejak sebarang arkib bersarang (arkib di dalam arkib lain). Jika lebih daripada 50 arkib bersarang ditemui, keseluruhan fail akan gagal.
• Bilangan sarangan maksimum ialah 5. Ini merujuk kepada berapa banyak lapisan sarangan yang boleh berlaku dalam sesuatu fail. Had ini tidak menyebabkan keseluruhan fail gagal diproses tetapi mana-mana fail yang dibungkus dalam lebih daripada 5 lapisan arkib tidak akan diproses dan sebaliknya fail teks pemegang tempat akan diletakkan pada tahap ke-5. Sarangan ini hanya merujuk kepada arkib di dalam arkib, folder tidak dikira.

Semua had ini boleh dikonfigurasikan melalui konfigurasi perkhidmatan.