Suporta sa archive

Pangkalahatang-ideya​

Nag-aalok ang Glasswall Halo ng advanced na proteksyon para sa mga archive file. Ginagamit ng makapangyarihang feature na ito ang makabagong Glasswall Engine upang maprotektahan ang bawat file sa loob ng isang archive. Hindi lamang nito pinoprotektahan ang mga file kundi matalinong nire-recompress din nito ang buong archive sa isang suportadong format. Sa pinahusay na functionality na ito, epektibong nase-secure ang iyong mga archive file at nao-optimize para sa tuloy-tuloy na paggamit.

Mga suportadong input type​

Hindi protektado​

• Zip - (sumusuporta sa compression type na bzip2)
• 7-Zip
• Gzip
• Rar
• Tar

Protektado​

• Zip

Paano ito gumagana​

Sa pagtanggap ng isang archive, nagsasagawa ang Halo ng komprehensibong processing workflow. Una, dini-decompress nito ang archive, at umaabot ito hanggang limang nested na antas ng mga archive. Sa bawat antas, hiwa-hiwalay na pini-process ng platform ang bawat non-archive file na makita.

Ang bawat file ay isinasailalim sa makapangyarihang Glasswall engine para sa pagproseso. Kapag naproseso na ang lahat ng file sa loob ng archive, muling binubuo ng platform ang archive habang pinananatili ang orihinal na istruktura. Ang mga inaasahang resulta ng prosesong ito ay ang mga sumusunod:

1. Proteksyon at sanitisation: tinitiyak ng Glasswall Engine na ang bawat file ay lubusang napoprotektahan at nasi-sanitise, na inaalis ang mga posibleng banta at kahinaan.

2. Pagsunod sa mga policy: sumusunod ang Glasswall Halo sa mga tinukoy na policy, na tinitiyak na ang nagreresultang archive ay nakaayon sa itinalagang mga configuration para sa seguridad at pamamahala ng content.

3. Pagpapanatili ng format: muling kino-compile ang archive sa paraang napapanatili ang orihinal na istruktura, habang pinananatili ang hierarkikal na organisasyon at integridad ng mga file.

Sa pagsunod sa matatag na workflow ng pagproseso na ito, tinitiyak ng Halo ang pinakamataas na antas ng proteksyon ng file, pagsunod sa policy, at pagpapanatili ng integridad para sa mga archive.

Mga inaasahang kinalabasan​

Mga uri ng file​

Bagama't napakahusay ng Glasswall Halo, may mga pagkakataon na hindi masuportahan ang ilang uri ng archive para sa recompression dahil sa mga paghihigpit sa lisensya. Sa ganitong mga kaso, gumagamit ang platform ng alternatibong paraan: nire-recompress nito ang mga hindi suportadong uri ng archive sa pangkalahatang compatible na Zip format. Mahalaga, sa prosesong ito, tinitiyak ng platform na ang lahat ng uri ng file at mga istruktura ng folder sa loob ng magreresultang Zip archive ay mananatiling ganap na hindi nababago.

Sa pagpapatupad ng solusyong ito, ginagarantiyahan ng Glasswall Halo ang tuloy-tuloy na compatibility at pinapanatili ang integridad ng mga orihinal na file at organisasyon ng folder, kahit na humaharap sa mga hindi suportadong uri ng archive. Tinitiyak nito na nananatiling naa-access at hindi nababago ang data, sa kabila ng anumang mga limitasyong dulot ng mga hadlang sa lisensya.

Mga nilalaman ng file​

Sa karamihan ng mga sitwasyon, kapag nagpoproseso ng archive, pinapalitan ng Halo ang isang file sa loob ng archive ng malinis na bersyon bago ito ibalik sa pamamagitan ng API. Gayunpaman, may mga sitwasyon kung saan maaaring makaranas ang platform ng kahirapan sa pagproseso ng isang partikular na file sa loob ng archive. Sa ganitong mga kaso, kung may ilang file na matagumpay na naproseso habang ang iba ay hindi, ang file na hindi maproseso ay papalitan ng isang .txt file. Ang nilalaman ng kapalit na file na ito ay magbibigay ng paliwanag kung bakit hindi maproseso ang file.

Sa paggamit ng paraang ito, tinitiyak ng Halo na ang karamihan ng mga file sa loob ng archive ay epektibong napoproseso at naibabalik sa malinis na kalagayan. Para sa anumang mga file na makakaranas ng mga isyu sa pagproseso, nagbibigay ng malinaw at nagbibigay-kaalamang mga paliwanag, upang maunawaan ng mga user ang mga dahilan sa likod ng mga file na hindi maproseso.

Ang mga sumusunod na sitwasyon ay inaasahang mangyayari:

Muling buuin​

• Ang archive ay muling binubuo at pinapayagan ang entry - ginagamit ang orihinal na file
• Ang archive ay muling binubuo at hindi pinapayagan ang entry - palitan ng text file (kaparehong pangalan) na nagsasabing "file disallowed"
• Ang archive ay muling binubuo at ang entry ay hindi suportadong uri ng file - palitan ng text file (kaparehong pangalan) na nagsasabing "unsupported file type"
• Ang archive ay muling binubuo at nabigo ang Engine habang muling binubuo ang entry - palitan ng text file (kaparehong pangalan) na nagsasabing "unable to rebuild file"
• Ang archive ay muling binubuo at matagumpay na muling nabuo ang entry - gamitin ang muling nabuong file

Pagsusuri​

• Ang archive ay sinusuri at pinapayagan ang entry - palitan ng text file (kaparehong pangalan) na nagsasabing "file allowed by policy, no analyse needed"
• Ang archive ay sinusuri at hindi pinapayagan ang entry - palitan ng text file (kaparehong pangalan) na nagsasabing "file disallowed"
• Ang archive ay sinusuri at ang entry ay hindi suportadong uri ng file - palitan ng text file (kaparehong pangalan) na nagsasabing "unsupported file type"
• Ang archive ay sinusuri at nabigo ang Engine habang sinusuri ang entry - palitan ng text file (kaparehong pangalan) na nagsasabing "unable to analyse file"
• Ang archive ay sinusuri at matagumpay na muling nabuo ang entry - gamitin ang pagsusuri ng file

Sa lahat ng kaso ng mga archive kapag ginagamit ang V3 endpoint, may inilalabas ding manifest.json na nagdedetalye ng resulta ng pagproseso ng lahat ng file sa loob ng archive at maaaring gamitin upang makatulong na maunawaan ang archive nang hindi na kailangang i-unpack ito.

Mga uri ng compression​

Kapag nagpoproseso ng mga file sa pamamagitan ng Halo, itinuturing nito ang mga uri ng compression na Bzip at Gzip bilang mga indibidwal na file. Bilang resulta, walang manifest.json na nabubuo habang nagpoproseso. Gayunpaman, ang pagpoproseso ng mga compressed file na ito ay sumusunod pa rin sa mga tuntunin ng pagpoproseso ng archive. Kung ang isang compressed file ay naglalaman ng archive sa loob nito, isang manifest.json ang nililikha at inilalabas sa pinakamataas na antas ng istruktura ng archive.

Ang file type response header para sa isang compressed file ay nakatakda sa compressed_file, na nagpapahiwatig ng pagiging compressed nito.

Kapag nabuo ang isang analysis report para sa isang compressed file, sumasailalim ito sa proseso ng pagpapalit ng pangalan upang matiyak ang wastong decompression ng panloob na file. Halimbawa, kung ang orihinal na file ay pinangalanang test.pdf.bz2, ang report file ay papalitan ng pangalan bilang test.pdf.report.xml.bz2. Tinitiyak ng kombensyong ito sa pagpapangalan ang malinaw na ugnayan sa pagitan ng report at ng kaukulang compressed file, na nagpapadali sa tamang decompression at kasunod na analysis.

Sa pagpapatupad ng mga hakbang na ito, pinananatili ng Halo ang pare-parehong paghawak sa mga compressed file, gumagawa ng mga tumpak na report, at pinapanatili ang integridad ng mga naprosesong file sa buong analysis workflow.

Config ng policy​

Ang mga endpoint ng Glasswall API ay nagbibigay ng malawak na suporta para sa Content Management Flags, na nagpapahintulot ng detalyadong kontrol sa mga indibidwal na file sa loob ng isang archive. Binibigyan ka ng configuration na ito ng kakayahang magtakda ng mga partikular na aksyon para sa bawat uri ng file sa loob ng archive. Ang default na value para sa bawat uri ng file sa configuration na ito ay nakatakda sa allow - 0. Gayunpaman, mayroon ka ring kakayahang pumili ng iba pang suportadong aksyon, gaya ng sanitise - 1 o disallow - 2.

Gamit ang Content Management Flags, maaari mong eksaktong kontrolin ang paghawak sa iba't ibang uri ng file sa loob ng mga archive, na tinitiyak na ang bawat file ay tumatanggap ng naaangkop na antas ng pamamahala at seguridad batay sa nais mong configuration. Pinahuhusay ng feature na ito ang pangkalahatang kontrol at mga opsyon sa pag-customize na magagamit upang epektibong mapamahalaan ang mga file sa loob ng mga archive sa pamamagitan ng Glasswall Halo API.

Ang mga sumusunod na uri ng file ay sinusuportahan sa ilalim ng configuration ng archive:

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

Paano inilalapat ang policy sa loob ng mga archive​

Ang mga archive na pinoproseso sa pamamagitan ng Glasswall Halo ay sumusunod sa ibinigay na policy sa paraang hierarchical. Ang pangunahing prinsipyong gumagabay sa paglalapat ng mga policy ay ang pagpili ng pinakamahigpit na outcome batay sa ibinigay na configuration habang sinusubukang tuparin ang paunang request. Ibig sabihin nito, sa ilang kaso, ang ContentManagementFlags na tinukoy sa request ang siyang nauuna.

Bukod dito, kapag ang parameter na return-executable-file ay nakatakda sa false, nagsisilbi ito bilang pangkalahatang paghihigpit para sa lahat ng executable sa loob ng mga archive, anuman ang ibinigay na configuration ng archive.

Higit pa rito, isinasaalang-alang din ang seksyong ArchiveConfig, kasama ang mga value sa loob nito. Kung ang mga value sa seksyong ito ang kumakatawan sa pinakamahigpit na outcome, gagamitin ang mga ito upang matukoy ang magiging outcome ng mga archive.

Sa pagsunod sa hierarchical na paraang ito at sa pagsasama ng mga ibinigay na parameter, tinitiyak ng Halo na epektibong naipapatupad ang mga policy, na nagbibigay ng pinakamataas na seguridad at kontrol sa pagpoproseso ng archive.

Matrix ng outcome​

Ang halimbawang ito ay batay sa isang Word document na naglalaman ng internal hyperlink:

CMF = halaga ng WordContentManagement:InternalHyperlinks

AC = halaga ng ArchiveConfig:doc

REF = halaga ng return-executable-file

Mga limitasyon​

Upang matiyak na maayos na gumagana ang system at maiwasan ang sobrang pagkakarga, nagtakda ng mga partikular na limitasyon para sa pagproseso ng mga archive. Ang mga limitasyong ito ay ang mga sumusunod:

• Pinakamataas na bilang ng file na 500. Ibig sabihin nito, ang anumang archive na naglalaman ng higit sa 500 file kapag na-unpack ay hindi mapoproseso.
• Pinakamataas na laki ng file na 500 MB. Ang anumang archive na naglalaman ng higit sa 500 MB ng mga file sa loob ay mabibigong maproseso.
• Pinakamataas na bilang ng archive na 50. Sinusubaybayan nito ang anumang nested archive (mga archive sa loob ng ibang archive). Kung higit sa 50 nested archive ang makita, mabibigo ang kabuuang file.
• Pinakamataas na bilang ng nesting na 5. Tumutukoy ito sa kung ilang layer ng nesting ang maaaring mangyari sa isang file. Hindi nagiging sanhi ang limitasyong ito na mabigo ang pagproseso ng buong file, ngunit ang anumang file na nakabalot sa higit sa 5 layer ng mga archive ay hindi mapoproseso at sa halip ay maglalagay ng placeholder text file sa ika-5 antas. Ang nesting na ito ay tumutukoy lamang sa mga archive sa loob ng mga archive; hindi kasama ang mga folder.

Ang lahat ng limitasyong ito ay nako-configure sa pamamagitan ng service configuration.