아카이브 지원
개요
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 | 파일이 Sanitised됨 | 파일이 Sanitised됨 | 파일이 허용되지 않음 |
| AC = 2 | 파일이 허용되지 않음 | 파일이 허용되지 않음 | 파일이 허용되지 않음 |
이 예시는 return-executable-file이 설정된 pe 파일에 대한 것입니다: |
REF = return-executable-file 값
| REF = true | REF = false | |
|---|---|---|
| AC = 0 | 파일 허용 | 파일이 허용되지 않음 |
| AC = 1 | 파일이 Sanitised됨 | 파일이 허용되지 않음 |
| AC = 2 | 파일이 허용되지 않음 | 파일이 허용되지 않음 |
제한 사항
시스템이 원활하게 작동하고 과부하를 방지할 수 있도록 아카이브 처리에 대한 특정 제한이 설정되어 있습니다. 이러한 제한은 다음과 같습니다:
- 최대 파일 수는 500개입니다. 즉, 압축 해제 시 500개를 초과하는 파일이 포함된 아카이브는 처리되지 않습니다.
- 최대 파일 크기는 500 MB입니다. 내부 파일 총량이 500 MB를 초과하는 아카이브는 처리에 실패합니다.
- 최대 아카이브 수는 50개입니다. 이는 중첩된 아카이브(다른 아카이브 내부의 아카이브)를 추적합니다. 중첩 아카이브가 50개를 초과하여 발견되면 전체 파일 처리가 실패합니다.
- 최대 중첩 수는 5입니다. 이는 파일에서 허용되는 중첩 계층 수를 의미합니다. 이 제한으로 인해 전체 파일 처리가 실패하지는 않지만, 5개 계층을 초과하는 아카이브로 감싸진 파일은 처리되지 않으며 대신 5번째 수준에 자리 표시자 텍스트 파일이 배치됩니다. 여기서 중첩은 아카이브 내부의 아카이브만을 의미하며, 폴더는 포함되지 않습니다.
이러한 제한은 모두 서비스 구성에서 설정할 수 있습니다.