アーカイブのサポート
概要
Glasswall Halo は、アーカイブファイルに対して高度な保護を提供します。この強力な機能は、最先端の Glasswall Engine を活用して、アーカイブ内のすべてのファイルを保護します。ファイルを保護するだけでなく、アーカイブ全体を対応形式にインテリジェントに再圧縮します。この強化された機能により、アーカイブファイルは効果的に保護され、シームレスに利用できるよう最適化されます。
対応する入力タイプ
保護なし
- Zip - （bzip2 の圧縮タイプをサポート）
- 7-Zip
- Gzip
- Rar
- Tar
保護あり
- Zip
仕組み
アーカイブを受信すると、Halo は包括的な処理ワークフローを実行します。まずアーカイブを展開し、最大 5 階層までネストされたアーカイブをたどります。各階層で、プラットフォームは検出されたアーカイブ以外の各ファイルを個別に処理します。
各ファイルは、強力な Glasswall engine による処理の対象となります。アーカイブ内のすべてのファイルの処理が完了すると、プラットフォームは元の構造を維持したままアーカイブを再構築します。この処理で期待される結果は次のとおりです。
-
保護とサニタイズ: Glasswall Engine は各ファイルが徹底的に保護およびサニタイズされることを保証し、潜在的な脅威や脆弱性を排除します。
-
policy への準拠: Glasswall Halo は指定された policy に従い、生成されるアーカイブが指定されたセキュリティおよびコンテンツ管理の構成に適合することを保証します。
-
形式の保持: アーカイブは元の構造を保持する方法で再コンパイルされ、ファイルの階層構造と完全性が維持されます。
この堅牢な処理ワークフローに従うことで、Halo はアーカイブに対して最高レベルのファイル保護、policy 準拠、完全性の維持を実現します。
期待される結果
ファイルタイプ
Glasswall Halo は非常に高機能ですが、ライセンス上の制約により、再圧縮に対応できない特定のアーカイブ形式が存在する場合があります。そのような場合、プラットフォームは代替アプローチを適用します。つまり、未対応のアーカイブ形式を汎用互換性のある Zip 形式に再圧縮します。重要なのは、この処理の間も、生成される Zip アーカイブ内のすべてのファイル形式とフォルダー構造が完全に変更されないよう、プラットフォームが保証することです。
このソリューションを実装することで、Glasswall Halo はシームレスな互換性を保証し、未対応のアーカイブ形式に直面した場合でも、元のファイルおよびフォルダー構成の完全性を維持します。これにより、ライセンス上の制約による制限があっても、データはアクセス可能で改変されないまま保たれます。
| 入力ファイル | 入力ファイルの例 | 出力ファイル | 出力ファイルの例 |
|---|---|---|---|
| Zip | file.zip | Zip | file.zip |
| Tar | file.tar | Tar | file.tar |
| GZip | file.gzip | GZip | file.gzip |
| 7Zip | file.7zip | Zip | file.7zip.zip |
| Rar | file.rar | Zip | file.rar.zip |
ファイル内容
ほとんどのシナリオでは、アーカイブを処理する際、Halo は API 経由で返却する前に、アーカイブ内のファイルをクリーンなバージョンに置き換えます。ただし、プラットフォームがアーカイブ内の特定のファイルの処理に困難を伴う場合があります。そのような場合、一部のファイルは正常に処理され、他のファイルは処理されないとき、処理不能なファイルは .txt ファイルに置き換えられます。この置換ファイルの内容には、そのファイルを処理できない理由の説明が記載されます。
このアプローチを採用することで、Halo はアーカイブ内の大部分のファイルが効果的に処理され、クリーンな状態で返却されることを保証します。処理上の問題が発生したファイルについては、明確で有益な説明が提供されるため、ユーザーは処理不能なファイルの理由を理解できます。
以下のシナリオが想定されます:
再構築
- アーカイブを再構築中で、エントリが許可されている場合 - 元のファイルを使用
- アーカイブを再構築中で、エントリが許可されていない場合 - 「file disallowed」と記載したテキストファイル（同じ名前）に置き換える
- アーカイブを再構築中で、エントリが未対応のファイルタイプである場合 - 「unsupported file type」と記載したテキストファイル（同じ名前）に置き換える
- アーカイブを再構築中で、エントリの再構築中に Engine が失敗した場合 - 「unable to rebuild file」と記載したテキストファイル（同じ名前）に置き換える
- アーカイブを再構築中で、エントリの再構築に成功した場合 - 再構築されたファイルを使用
分析
- アーカイブを解析中で、エントリが許可されている場合 - 「file allowed by policy, no analyse needed」と記載したテキストファイル（同じ名前）に置き換える
- アーカイブを解析中で、エントリが許可されていない場合 - 「file disallowed」と記載したテキストファイル（同じ名前）に置き換える
- アーカイブを解析中で、エントリが未対応のファイルタイプである場合 - 「unsupported file type」と記載したテキストファイル（同じ名前）に置き換える
- アーカイブを解析中で、エントリの解析中に Engine が失敗した場合 - 「unable to analyse file」と記載したテキストファイル（同じ名前）に置き換える
- アーカイブを解析中で、エントリの再構築に成功した場合 - ファイルの解析結果を使用
アーカイブに関するすべてのケースにおいて、V3 endpoint を使用すると、アーカイブ内のすべてのファイルの処理結果を詳述した manifest.json も出力され、アーカイブを展開しなくても内容の理解に役立てることができます。
圧縮タイプ
Halo でファイルを処理する際、Bzip および Gzip の圧縮タイプは個別のファイルとして扱われます。その結果、処理中に manifest.json は生成されません。ただし、これらの圧縮ファイルの処理は引き続きアーカイブ処理のルールに従います。圧縮ファイル内にアーカイブが含まれている場合は、manifest.json が作成され、アーカイブ構造の最上位レベルに出力されます。
圧縮ファイルのファイルタイプ応答ヘッダーは、その圧縮ファイルである性質を示すために compressed_file に設定されます。
圧縮ファイルに対して分析レポートが生成される場合、内部ファイルを適切に展開できるようにするため、リネーム処理が行われます。たとえば、元のファイル名が test.pdf.bz2 の場合、レポートファイルは test.pdf.report.xml.bz2 にリネームされます。この命名規則により、レポートと対応する圧縮ファイルとの関連付けが明確になり、正しい展開とその後の分析が容易になります。
これらの対策を実装することで、Halo は圧縮ファイルを一貫して処理し、正確なレポートを生成し、分析ワークフロー全体を通じて処理済みファイルの完全性を維持します。
policy 設定
Glasswall API エンドポイントは Content Management Flags を幅広くサポートしており、アーカイブ内の個々のファイルをきめ細かく制御できます。この設定により、アーカイブ内の各ファイルタイプに対して特定のアクションを定義できます。この設定における各ファイルタイプのデフォルト値は allow - 0 に設定されています。ただし、sanitise - 1 や disallow - 2 など、サポートされている別のアクションを選択することもできます。
Content Management Flags を使用すると、アーカイブ内の異なるファイルタイプの処理を正確に制御でき、目的の設定に基づいて各ファイルに適切なレベルの管理とセキュリティを適用できます。この機能により、Glasswall Halo API を通じたアーカイブ内ファイルの効果的な管理に向けて、全体的な制御性とカスタマイズ性が向上します。
アーカイブ設定では、次のファイルタイプがサポートされています。
"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
}
アーカイブ内で policy はどのように適用されますか
Glasswall Halo を通じて処理されるアーカイブは、提供された policy に階層的に従います。policy の適用を導く基本原則は、初期リクエストを満たそうとしつつ、指定された設定に基づいて最も厳格な結果を選択することです。つまり、場合によってはリクエストで指定された ContentManagementFlags が優先されます。
さらに、return-executable-file パラメーターが false に設定されている場合、提供されたアーカイブ設定に関係なく、アーカイブ内のすべての実行可能ファイルに対する包括的な制限として機能します。
加えて、ArchiveConfig セクションも考慮され、その中の値が評価されます。このセクション内の値が最も厳格な結果を表す場合、それらがアーカイブの最終的な結果を決定するために使用されます。
この階層的なアプローチに従い、提供されたパラメーターを組み込むことで、Halo は policy が効果的に適用されることを保証し、アーカイブ処理に対する最大限のセキュリティと制御を提供します。
結果マトリクス
この例は、内部ハイパーリンクを含む Word ドキュメントに基づいています:
CMF = WordContentManagement:InternalHyperlinks の値
AC = ArchiveConfig:doc の値
| CMF = 0 | CMF = 1 | CMF = 2 | |
|---|---|---|---|
| AC = 0 | ファイルは許可されます | ファイルは許可されます | ファイルは許可されます |
| AC = 1 | ファイルはサニタイズされます | ファイルはサニタイズされます | ファイルは許可されません |
| AC = 2 | ファイルは許可されません | ファイルは許可されません | ファイルは許可されません |
この例は、return-executable-file が設定された pe ファイル向けです: |
REF = return-executable-file の値
| REF = true | REF = false | |
|---|---|---|
| AC = 0 | ファイルは許可されます | ファイルは許可されません |
| AC = 1 | ファイルはサニタイズされます | ファイルは許可されません |
| AC = 2 | ファイルは許可されません | ファイルは許可されません |
制限
システムが円滑に動作し、過負荷を回避できるように、アーカイブの処理には特定の制限が設定されています。制限事項は次のとおりです。
- 最大ファイル数は500です。つまり、展開時に500を超えるファイルを含むアーカイブは処理されません。
- 最大ファイルサイズは500 MBです。内部に合計500 MBを超えるファイルを含むアーカイブは処理に失敗します。
- 最大アーカイブ数は50です。これはネストされたアーカイブ（他のアーカイブ内にあるアーカイブ）を追跡します。50を超えるネストされたアーカイブが見つかった場合、ファイル全体が失敗します。
- 最大ネスト数は5です。これは、ファイル内で何層のネストが発生できるかを指します。この制限によってファイル全体の処理が失敗することはありませんが、5層を超えるアーカイブに包まれたファイルは処理されず、代わりにプレースホルダーのテキストファイルが5層目に配置されます。このネストはアーカイブ内のアーカイブのみを指し、フォルダーはカウントされません。
これらの制限はすべて、サービス構成で設定可能です。