비즈니스용 앱 제어 정책 규칙 및 파일 규칙 이해
참고
비즈니스용 App Control의 일부 기능은 특정 Windows 버전에서만 사용할 수 있습니다. App Control 기능 가용성에 대해 자세히 알아보세요.
비즈니스용 앱 제어는 드라이버 또는 애플리케이션을 신뢰할 수 있는지 여부를 지정하는 정책을 설정하여 Windows 디바이스에서 실행되는 작업을 제어할 수 있습니다. 정책에는 감사 모드와 같은 옵션을 제어하는 정책 규칙과 organization 트러스트의 애플리케이션을 식별하는 방법을 지정하는 파일 규칙(또는 파일 규칙 수준)이 포함됩니다.
비즈니스용 앱 제어 정책 규칙
기존 App Control 정책 XML의 정책 규칙 옵션을 수정하려면 앱 제어 정책 마법사 또는 Set-RuleOption PowerShell cmdlet을 사용합니다.
App Control 정책 내에서 여러 규칙 옵션을 설정할 수 있습니다. 표 1에서는 각 규칙 옵션과 추가 정책이 이를 설정할 수 있는지 여부를 설명합니다. 일부 규칙 옵션은 향후 작업을 위해 예약되거나 지원되지 않습니다.
참고
새 앱 제어 정책을 적용하기 전에 테스트할 수 있으므로 처음에는 Enabled:Audit Mode 를 사용하는 것이 좋습니다. 감사 모드를 사용하면 애플리케이션이 정상적으로 실행되지만 App Control은 정책에서 허용되지 않는 파일이 실행될 때마다 이벤트를 기록합니다. 이러한 파일을 허용하려면 이벤트 로그에서 정책 정보를 캡처한 다음 해당 정보를 기존 정책에 병합할 수 있습니다. Enabled:Audit 모드가 삭제되면 정책이 강제 모드로 실행됩니다.
일부 앱은 정책이 감사 모드인 경우에도 다르게 동작할 수 있습니다. 옵션이 감사 모드에서 동작을 변경할 수 있는 경우 표 1에 나와 있습니다. 앱 제어 정책에 중요한 업데이트를 배포할 때는 항상 앱을 철저히 테스트해야 합니다.
표 1. 비즈니스용 앱 제어 정책 - 정책 규칙 옵션
| 규칙 옵션 | 설명 | 유효한 추가 옵션 |
|---|---|---|
| 0 사용:UMCI | 앱 제어 정책은 커널 모드와 사용자 모드 이진 파일을 모두 제한합니다. 기본적으로 커널 모드 이진 파일만 제한됩니다. 이 규칙 옵션을 사용하도록 설정하면 사용자 모드 실행 파일 및 스크립트의 유효성이 검사됩니다. | 아니오 |
| 1 사용:부팅 메뉴 보호 | 이 옵션은 현재 지원되지 않습니다. | 아니오 |
| 2 필수:WHQL | 기본적으로 WHQL(Windows Hardware Quality Labs)에 서명되지 않은 커널 드라이버는 실행할 수 있습니다. 이 규칙을 사용하도록 설정하려면 모든 드라이버가 WHQL 서명되고 레거시 드라이버 지원을 제거해야 합니다. Windows 10 위해 빌드된 커널 드라이버는 WHQL 인증을 받아야 합니다. | 아니오 |
| 3 사용:감사 모드(기본값) | 정책이 적용된 경우 차단되었을 애플리케이션, 이진 파일 및 스크립트에 대한 정보를 기록하도록 App Control에 지시합니다. 이 옵션을 사용하여 App Control 정책의 잠재적 영향을 식별하고 감사 이벤트를 사용하여 적용하기 전에 정책을 구체화할 수 있습니다. App Control 정책을 적용하려면 이 옵션을 삭제합니다. | 아니오 |
| 4 사용 안 함:플라이트 서명 | 사용하도록 설정하면 Windows 참가자 빌드의 이진 파일을 신뢰할 수 없습니다. 이 옵션은 Windows 빌드 시험판이 아닌 릴리스된 이진 파일만 실행하려는 조직에 유용합니다. | 아니오 |
| 5 사용: 내재된 기본 정책 | 이 옵션은 나중에 사용하도록 예약되어 있으며 현재는 효과가 없습니다. | 예 |
| 6 사용:서명되지 않은 시스템 무결성 정책(기본값) | 정책이 서명되지 않은 상태로 유지될 수 있습니다. 이 옵션을 제거하면 정책에 서명해야 하며 추가 정책도 서명해야 합니다. 향후 정책 업데이트에 대해 신뢰할 수 있는 인증서는 UpdatePolicySigners 섹션에서 식별해야 합니다. 추가 정책에 대해 신뢰할 수 있는 인증서는 SupplementalPolicySigners 섹션에서 식별해야 합니다. | 예 |
| 7 허용:증강된 디버그 정책 | 이 옵션은 현재 지원되지 않습니다. | 예 |
| 8 필수:EV 서명자 | 이 옵션은 현재 지원되지 않습니다. | 아니오 |
| 9 사용:고급 부팅 옵션 메뉴 | F8 프리부트 메뉴는 모든 App Control 정책에 대해 기본적으로 사용하지 않도록 설정됩니다. 이 규칙 옵션을 설정하면 F8 메뉴가 물리적으로 현재 사용자에게 나타납니다. | 아니오 |
| 10 사용:실패 시 부팅 감사 | 앱 제어 정책이 적용 모드에 있을 때 사용됩니다. 시작 중에 부팅에 중요한 드라이버가 실패하면 Windows가 로드되도록 App Control 정책이 감사 모드에 배치됩니다. 관리자는 CodeIntegrity 이벤트 로그에서 실패 원인을 확인할 수 있습니다. | 아니오 |
| 11 사용 안 함: 스크립트 집행 | 이 옵션은 PowerShell, Windows 기반 스크립트 호스트(wscript.exe), Windows 콘솔 기반 스크립트 호스트(cscript.exe), Microsoft HTML 애플리케이션 호스트(mshta.exe) 및 MSXML에서 실행되는 HTA 파일을 포함하는 스크립트 적용 옵션을 사용하지 않도록 설정합니다. 일부 스크립트 호스트는 정책이 감사 모드인 경우에도 다르게 동작할 수 있습니다. 스크립트 적용에 대한 자세한 내용은 App Control을 사용하여 스크립트 적용을 참조하세요. 참고: 이 옵션은 Windows Server 2016 또는 Windows 10 1607 LTSB에서 지원되지 않으며 해당 운영 체제에서 사용하면 안 됩니다. |
아니오 |
| 12 필수: Store 응용 프로그램 적용 | 이 규칙 옵션을 사용하도록 설정하면 App Control 정책이 유니버설 Windows 애플리케이션에도 적용됩니다. | 아니오 |
| 13 사용: 관리형 설치 관리자 | 관리되는 설치 관리자가 설치한 애플리케이션을 자동으로 허용하려면 이 옵션을 사용합니다. 자세한 내용은 App Control 관리형 설치 관리자를 사용하여 배포된 앱 권한 부여를 참조하세요. | 예 |
| 14 사용: 인텔리전트 보안 그래프 인증 | 이 옵션을 사용하여 Microsoft의 ISG(Intelligent Security Graph)에 정의된 "알려진 양호한" 평판을 가진 애플리케이션을 자동으로 허용합니다. | 예 |
| 15 사용: 재부팅 시 EA 무효화 | Intelligent Security Graph 옵션(14)을 사용하는 경우 App Control은 파일을 실행할 권한이 있음을 나타내는 확장된 파일 특성을 설정합니다. 이 옵션을 사용하면 App Control에서 이전에 ISG에서 승인한 파일의 평판을 주기적으로 다시 확인합니다. | 아니오 |
| 16 사용: 업데이트 정책 재부팅 없음 | 이 옵션을 사용하여 시스템을 다시 부팅하지 않고도 향후 App Control 정책 업데이트가 적용되도록 할 수 있습니다. 참고: 이 옵션은 Windows 10, 버전 1709 이상 또는 Windows Server 2019 이상에서만 지원됩니다. |
아니오 |
| 17 사용:추가 정책 허용 | 기본 정책에서 이 옵션을 사용하여 추가 정책을 확장할 수 있습니다. 참고: 이 옵션은 Windows 10 버전 1903 이상 또는 Windows Server 2022 이상에서만 지원됩니다. |
아니오 |
| 18 사용 안 함:런타임 FilePath 규칙 보호 | 이 옵션은 관리자만 쓸 수 있는 경로에 대한 FilePath 규칙만 허용하는 기본 런타임 검사 사용하지 않도록 설정합니다. 참고: 이 옵션은 Windows 10 버전 1903 이상 또는 Windows Server 2022 이상에서만 지원됩니다. |
예 |
| 19 사용:동적 코드 보안 | .NET 애플리케이션 및 동적으로 로드된 라이브러리에 대한 정책 적용을 사용하도록 설정합니다. 참고: 이 옵션은 Windows 10, 버전 1803 이상 또는 Windows Server 2019 이상에서만 지원됩니다. 참고: 이 옵션은 App Control UMCI 정책이 사용하도록 설정하는 경우 항상 적용됩니다. .NET 동적 코드 보안 강화에 대한 감사 모드는 없습니다. |
아니오 |
| 20 Enabled:Revoked Expired as unsigned | 이 옵션을 사용하여 엔터프라이즈 서명 시나리오에서 해지된 인증서로 서명된 이진 파일 또는 서명의 수명 서명 EKU가 있는 만료된 인증서를 사용자 모드 프로세스/구성 요소의 경우 "서명되지 않은 이진 파일"로 처리합니다. | 아니오 |
| Enabled:Developer Mode Dynamic Code Trust | 개발자 모드가 시스템에서 사용하도록 설정된 경우 Visual Studio에서 디버그 되거나 디바이스 포털을 통해 배포되는 UWP 앱을 신뢰하려면 이 옵션을 사용합니다. | 아니오 |
비즈니스용 앱 제어 파일 규칙 수준
관리자는 파일 규칙 수준을 통해 해당 응용 프로그램을 신뢰하려는 수준을 지정할 수 있습니다. 이 신뢰 수준은 각 이진의 해시만큼 세분화되거나 CA 인증서와 같이 일반적일 수 있습니다. 앱 제어 마법사 또는 App Control PowerShell cmdlet을 사용하여 정책을 만들고 수정할 때 파일 규칙 수준을 지정합니다.
각 파일 규칙 수준에는 장점과 단점이 있습니다. 표 2를 사용하여 사용 가능한 관리 리소스 및 App Control 배포 시나리오에 대한 적절한 보호 수준을 선택합니다.
참고
App Control 서명자 기반 규칙은 최대 키 길이가 4096비트인 RSA 암호화에서만 작동합니다. ECDSA와 같은 ECC 알고리즘은 지원되지 않습니다. ECC 서명을 기반으로 서명별로 파일을 허용하려고 하면 해당 3089 서명 정보 이벤트에 VerificationError = 23이 표시됩니다. 파일이 RSA를 사용하여 서명으로 서명된 경우 해시 또는 파일 특성 규칙 또는 다른 서명자 규칙을 사용하여 파일을 대신 허용할 수 있습니다.
표 2. 비즈니스용 앱 제어 정책 - 파일 규칙 수준
| 규칙 수준 | 설명 |
|---|---|
| Hash | 검색된 각 이진 파일에 대한 개별 Authenticode/PE 이미지 해시 값을 지정합니다. 이 수준은 가장 구체적인 수준이며 현재 제품 버전의 해시 값을 유지하기 위해 더 많은 노력이 필요합니다. 이진 파일이 업데이트될 때마다 해시 값이 변경되므로 정책 업데이트가 필요합니다. |
| FileName | 각 이진 파일에 대한 원래 파일 이름을 지정합니다. 응용 프로그램에 대한 해시 값은 업데이트 시 수정되지만 파일 이름은 일반적으로 수정되지 않습니다. 이 수준은 해시 수준보다 덜 구체적인 보안을 제공하지만 일반적으로 이진 파일이 수정되면 정책 업데이트가 필요하지 않습니다. 기본적으로 이 수준은 파일의 리소스 헤더의 OriginalFileName 특성을 사용합니다. -SpecificFileNameLevel을 사용하여 ProductName과 같은 대체 특성을 선택합니다. |
| FilePath | Windows 10 버전 1903부터 이 수준을 사용하면 이진 파일을 특정 파일 경로 위치에서 실행할 수 있습니다. FilePath 규칙은 사용자 모드 이진 파일에만 적용되며 커널 모드 드라이버를 허용하는 데 사용할 수 없습니다. FilePath 수준 규칙에 대한 자세한 내용은 이 문서의 뒷부분에서 확인할 수 있습니다. |
| SignedVersion | 이 수준은 게시자 규칙을 버전 번호와 결합합니다. 지정된 버전 번호 이상의 버전을 사용하여 지정된 게시자에서 모든 항목을 실행할 수 있습니다. |
| 게시자 | 이 수준은 PcaCertificate 수준(일반적으로 루트 아래의 인증서 하나)과 리프 인증서의 CN(일반 이름)을 결합합니다. 이 규칙 수준을 사용하여 특정 CA에서 발급하고 신뢰할 수 있는 특정 회사(예: 디바이스 드라이버의 경우 Intel)에 발급된 인증서를 신뢰할 수 있습니다. |
| FilePublisher | 이 수준은 서명된 파일의 "FileName" 특성과 "Publisher"(리프의 CN을 사용하는 PCA 인증서)와 최소 버전 번호를 결합합니다. 이 옵션은 지정된 버전 번호 이상으로 버전이 지정된 특정 게시자의 특정 파일을 신뢰합니다. 기본적으로 이 수준은 파일의 리소스 헤더의 OriginalFileName 특성을 사용합니다. -SpecificFileNameLevel을 사용하여 ProductName과 같은 대체 특성을 선택합니다. |
| LeafCertificate | 개별 서명 인증서 수준에서 신뢰할 수 있는 서명자를 추가합니다. 이 수준과 개별 해시 수준을 사용할 경우의 이점은 새 버전의 제품에는 해시 값이 다르지만 일반적으로 서명 인증서가 동일하다는 것입니다. 이 수준을 사용하면 새 버전의 애플리케이션을 실행하는 데 정책 업데이트가 필요하지 않습니다. 그러나 리프 인증서는 일반적으로 다른 인증서 수준보다 유효 기간이 짧으므로 이러한 인증서가 변경될 때마다 App Control 정책을 업데이트해야 합니다. |
| PcaCertificate | 제공된 인증서 체인에서 사용 가능한 인증서 중 가장 높은 인증서를 서명자에 추가합니다. 검사에서 로컬 루트 저장소 또는 온라인 검사 통해 전체 인증서 체인을 resolve 않기 때문에 이 수준은 일반적으로 루트 아래의 인증서 중 하나입니다. |
| RootCertificate | 지원되지 않음. |
| WHQL | Microsoft에 제출되고 WHQL(Windows Hardware Qualification Lab)에서 서명한 이진 파일만 신뢰합니다. 이 수준은 주로 커널 이진 파일에 대한 것입니다. |
| WHQLPublisher | 이 수준은 리프 인증서의 WHQL 수준과 CN을 결합하며 주로 커널 이진 파일용입니다. |
| WHQLFilePublisher | 이 수준은 서명된 파일의 "FileName" 특성과 "WHQLPublisher"와 최소 버전 번호를 결합합니다. 이 수준은 주로 커널 이진 파일에 대한 것입니다. 기본적으로 이 수준은 파일의 리소스 헤더의 OriginalFileName 특성을 사용합니다. -SpecificFileNameLevel을 사용하여 ProductName과 같은 대체 특성을 선택합니다. |
참고
New-CIPolicy를 사용하여 App Control 정책을 만들 때 -Level 매개 변수를 포함하여 기본 파일 규칙 수준을 지정할 수 있습니다. 기본 파일 규칙 조건에 따라 신뢰할 수 없는 검색된 이진 파일의 경우 -Fallback 매개 변수를 사용합니다. 예를 들어 기본 파일 규칙 수준이 PCACertificate이지만 서명되지 않은 애플리케이션도 신뢰하려는 경우 해시 규칙 수준을 대체로 사용하면 서명 인증서가 없는 이진 파일의 해시 값이 추가됩니다.
참고
해당하는 경우 파일 규칙의 최소 및 최대 버전 번호는 정책 XML에서 각각 MinimumFileVersion 및 MaximumFileVersion으로 참조됩니다.
- MinimumFileVersion 및 MaximumFileVersion 모두 지정됨: 허용 규칙의 경우 버전이 MinimumFileVersion 보다 크거나 같 고 MaximumFileVersion 보다 작거나 같은 파일이 허용됩니다. 거부 규칙의 경우 버전이 MinimumFileVersion 보다 크거나 같 고 MaximumFileVersion 보다 작거나 같은 파일이 거부됩니다.
- MaximumFileVersion 없이 지정된 MinimumFileVersion: 허용 규칙의 경우 버전이 지정된 버전 보다 크거나 같은 파일을 실행할 수 있습니다. 거부 규칙의 경우 버전이 지정된 버전 보다 작거나 같은 파일이 차단됩니다.
- MinimumFileVersion 없이 지정된 MaximumFileVersion: 허용 규칙의 경우 버전이 지정된 버전 보다 작거나 같은 파일을 실행할 수 있습니다. 거부 규칙의 경우 버전이 지정된 버전 보다 크거나 같은 파일이 차단됩니다.
사용 중인 파일 규칙 수준의 예
예를 들어 많은 서버를 실행하는 부서에서 IT 전문가를 고려합니다. 하드웨어, 운영 체제, 바이러스 백신 및 기타 중요한 소프트웨어를 제공하는 회사에서 서명한 소프트웨어만 실행하려고 합니다. 또한 이 부서의 서버에서는 서명되지 않았지만 거의 업데이트되지 않는 내부에서 작성된 응용 프로그램만 실행 중입니다. 이 응용 프로그램도 실행할 수 있어야 합니다.
App Control 정책을 만들려면 표준 하드웨어에 참조 서버를 빌드하고 해당 서버가 실행되는 것으로 알려진 모든 소프트웨어를 설치합니다. 그런 다음 -Level Publisher(소프트웨어 공급자, 즉 "게시자"의 소프트웨어 허용) 및 -Fallback Hash(서명되지 않은 내부 응용 프로그램 허용)를 사용하여 New-CIPolicy를 실행합니다. 정책을 감사 모드로 배포하여 정책 적용으로 인한 잠재적 영향을 확인합니다. 감사 데이터의 도움으로 실행하려는 다른 소프트웨어를 포함하도록 앱 제어 정책을 업데이트합니다. 그런 다음, 서버에 대해 적용 모드에서 App Control 정책을 사용하도록 설정합니다.
정상적인 작업의 일환으로 결국 소프트웨어 업데이트를 설치하거나 동일한 소프트웨어 공급자의 소프트웨어를 추가할 수 있습니다. "게시자"는 해당 업데이트 및 소프트웨어에서 동일하게 유지되므로 앱 제어 정책을 업데이트할 필요가 없습니다. 서명되지 않은 내부 애플리케이션이 업데이트되는 경우 새 버전을 허용하도록 App Control 정책도 업데이트해야 합니다.
파일 규칙 우선 순위
App Control에는 우선 순위로 변환되는 기본 제공 파일 규칙 충돌 논리가 있습니다. 먼저 찾은 모든 명시적 거부 규칙을 처리합니다. 그런 다음 명시적 허용 규칙을 처리합니다. 거부 또는 허용 규칙이 없는 경우 App Control은 정책에서 허용되는 경우 관리되는 설치 관리자 클레임 을 확인합니다. 마지막으로 앱 제어는 정책에서 허용하는 경우 ISG 로 돌아갑니다.
참고
App Control 정책을 더 쉽게 추론할 수 있도록 여러 App Control 정책을 지원하는 Windows 버전에서 별도의 ALLOW 및 DENY 정책을 유지하는 것이 좋습니다.
FileName, FilePublisher 또는 WHQLFilePublisher 수준 규칙과 함께 -SpecificFileNameLevel 사용
기본적으로 FileName, FilePublisher 및 WHQLFilePublisher 규칙 수준은 파일의 리소스 헤더에서 OriginalFileName 특성을 사용합니다. -SpecificFileNameLevel을 설정하여 규칙에 대체 리소스 헤더 특성을 사용할 수 있습니다. instance 소프트웨어 개발자는 앱의 일부인 모든 이진 파일에 동일한 ProductName을 사용할 수 있습니다. -SpecificFileNameLevel을 사용하여 모든 파일에 대한 개별 규칙이 아닌 정책의 모든 이진 파일을 포함하는 단일 규칙을 만들 수 있습니다.
표 3에서는 -SpecificFileNameLevel을 사용하여 설정할 수 있는 사용 가능한 리소스 헤더 특성 옵션에 대해 설명합니다.
표 3. -SpecificFileNameLevel 옵션
| SpecificFileNameLevel 값 | 설명 |
|---|---|
| FileDescription | 이진 파일 개발자가 제공하는 파일 설명을 지정합니다. |
| InternalName | 이진 파일의 내부 이름을 지정합니다. |
| OriginalFileName | 이진 파일의 원래 파일 이름 또는 파일이 처음 만들어진 이름을 지정합니다. |
| PackageFamilyName | 이진 파일의 패키지 패밀리 이름을 지정합니다. 패키지 패밀리 이름은 파일 이름과 게시자 ID의 두 부분으로 구성됩니다. |
| ProductName | 이진 파일이 제공되는 제품의 이름을 지정합니다. |
| 파일 경로 | 이진 파일 경로를 지정합니다. |
파일 경로 규칙에 대한 자세한 정보
파일 경로 규칙은 변경 가능한 액세스 권한을 기반으로 하기 때문에 명시적 서명자 규칙이 수행하는 것과 동일한 보안 보장을 제공하지 않습니다. 파일 경로 규칙은 대부분의 사용자가 관리자가 아닌 표준으로 실행되는 환경에 가장 적합합니다. 경로 규칙은 관리자가 쓸 수 있는 상태로만 유지되어야 하는 경로를 허용하는 데 가장 적합합니다. 표준 사용자가 폴더에서 ACL을 수정할 수 있는 디렉터리에 대한 경로 규칙을 방지할 수 있습니다.
사용자 쓰기 가능한 파일 경로
기본적으로 App Control은 런타임에 사용자 쓰기 가능성 검사 수행하여 지정된 파일 경로에 대한 현재 권한에서 관리자 사용자에 대한 쓰기 액세스만 허용하도록 합니다.
App Control에서 관리자로 인식하는 정의된 SID 목록이 있습니다. filepath에서 이 목록에 없는 SID에 대한 쓰기 권한을 허용하는 경우 SID가 사용자 지정 관리자 사용자에 연결되어 있더라도 파일 경로는 사용자 쓰기가 가능한 것으로 간주됩니다. 이러한 특수한 경우를 처리하려면 앞에서 설명한 Disabled:Runtime FilePath 규칙 보호 옵션을 사용하여 App Control의 런타임 관리자 쓰기 가능 검사 재정의할 수 있습니다.
App Control의 잘 알려진 관리자 SID 목록은 다음과 같습니다.
S-1-3-0; S-1-5-18; S-1-5-19; S-1-5-20; S-1-5-32-544; S-1-5-32-549; S-1-5-32-550; S-1-5-32-551; S-1-5-32-577; S-1-5-32-559; S-1-5-32-568; S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394; S-1-15-2-95739096-486727260-2033287795-3853587803-1685597119-444378811-2746676523.
New-CIPolicy를 사용하여 파일 경로 규칙이 생성되면 검색된 경로에서 검색된 모든 파일에 대해 고유하고 정규화된 경로 규칙이 생성됩니다. 지정된 폴더 경로 아래의 모든 파일을 허용하는 규칙을 만들려면 New-CIPolicyRule 을 사용하여 -FilePathRules 스위치를 사용하여 와일드카드를 포함하는 규칙을 정의합니다.
App Control 파일 경로 규칙에서 와일드카드 사용
App Control 파일 경로 규칙에서 다음 와일드카드를 사용할 수 있습니다.
| 와일드카드 문자 | 의미 | 지원되는 운영 체제 |
|---|---|---|
* |
0개 이상의 문자와 일치합니다. | Windows 11, Windows 10 및 Windows Server 2022 |
? |
단일 문자와 일치합니다. | Windows 11 전용 |
정확한 볼륨이 다를 %OSDRIVE%수 있는 경우 , , %WINDIR%%SYSTEM32%매크로를 사용할 수도 있습니다. 이러한 매크로는 위의 와일드카드와 함께 사용할 수 있습니다.
참고
Windows 11 파일 경로 규칙 내에서 하나 이상의 와일드카드를 사용할 수 있습니다.
다른 모든 Windows 및 Windows Server 버전에서는 경로 규칙당 하나의 와일드카드만 허용 되며 경로 규칙의 시작 또는 끝에 있어야 합니다.
와일드카드가 있는 파일 경로 규칙 예제
| 예 | 설명 | 지원되는 운영 체제 |
|---|---|---|
|
C:\Windows\* D:\EnterpriseApps\MyApp\* %OSDRIVE%\Windows\* |
경로 끝에 배치된 와일드카드는 즉시 경로의 모든 파일과 해당 하위 디렉터리에 재귀적으로 권한을 부여합니다. | Windows 11, Windows 10 및 Windows Server 2022 |
| *\bar.exe | 경로의 시작 부분에 배치된 와일드카드는 모든 위치에서 정확히 지정된 파일 이름을 허용합니다. | Windows 11, Windows 10 및 Windows Server 2022 |
|
C:\*\CCMCACHE\*\7z???? -x64.exe %OSDRIVE%\*\CCMCACHE\*\7z???? -x64.exe |
경로 중간에 사용되는 와일드카드는 해당 패턴과 일치하는 모든 파일을 허용합니다. 특히 정책에서 Disabled:Runtime FilePath 규칙 보호 옵션을 사용하여 관리자가 쓸 수 있는 검사 사용하지 않도록 설정하는 경우 가능한 모든 일치 항목을 신중하게 고려합니다. 이 예제에서는 두 가상 경로가 모두 일치합니다.C:\WINDOWS\CCMCACHE\12345\7zabcd-x64.exe C:\USERS\AppControlUSER\Downloads\Malware\CCMCACHE\Pwned\7zhaha-x64.exe |
Windows 11 전용 |
와일드카드가 없으면 filepath 규칙은 특정 파일(예: C:\foo\bar.exe)만 허용합니다.
참고
Configuration Manager 사용하여 App Control 정책을 작성할 때 지정된 파일 및 폴더에 대한 규칙을 만드는 옵션이 있습니다. 이러한 규칙은 App Control 파일 경로 규칙이 아닙니다 . 대신 Configuration Manager 지정된 파일 및 폴더의 일회성 검사를 수행하고 해당 검사 시 해당 위치에 있는 모든 이진 파일에 대한 규칙을 빌드합니다. Configuration Manager 정책을 다시 적용하지 않는 한 해당 검사 후 지정된 파일 및 폴더에 대한 파일 변경은 허용되지 않습니다.
해시에 대한 자세한 정보
App Control은 파일의 해시를 계산할 때 Authenticode/PE 이미지 해시 알고리즘 을 사용합니다. 일반적으로 알려진 플랫 파일 해시와 달리 Authenticode 해시 계산은 파일의 체크섬, 인증서 테이블 및 특성 인증서 테이블을 생략합니다. 따라서 파일의 서명 및 타임스탬프가 변경되거나 파일에서 디지털 서명이 제거될 때 파일의 Authenticode 해시는 변경되지 않습니다. Authenticode 해시의 도움으로 App Control은 추가 보안 및 관리 오버헤드를 줄여 고객이 파일의 디지털 서명을 업데이트할 때 정책 해시 규칙을 수정할 필요가 없도록 합니다.
Authenticode/PE 이미지 해시는 디지털 서명 및 서명되지 않은 파일에 대해 계산할 수 있습니다.
검사에서 XML 파일당 4개의 해시 규칙을 만드는 이유는 무엇인가요?
PowerShell cmdlet은 Authenticode Sha1 해시, Sha256 해시, Sha1 페이지 해시, Sha256 페이지 해시를 생성합니다. 유효성 검사 중에 App Control은 파일 서명 방법 및 파일이 사용되는 시나리오에 따라 계산되는 해시를 선택합니다. 예를 들어 파일이 페이지 해시 서명인 경우 App Control은 파일의 각 페이지의 유효성을 검사하고 전체 sha256 authenticode 해시를 계산하기 위해 메모리에 전체 파일을 로드하지 않습니다.
cmdlet에서는 사용할 해시를 예측하는 대신 4개의 해시(sha1/sha2 authenticode 및 첫 번째 페이지의 sha1/sha2)를 미리 계산하고 사용합니다. 또한 이 메서드는 App Control 정책에 이미 파일에 사용할 수 있는 해시가 두 개 이상 있기 때문에 파일이 서명되는 방식의 변경에 복원력이 있습니다.
스캔이 특정 파일에 대한 8개의 해시 규칙을 만드는 이유는 무엇인가요?
UMCI 및 KMCI에 대해 별도의 규칙이 만들어집니다. cmdlet에서 파일이 사용자 모드 또는 커널에서만 실행되는지 확인할 수 없는 경우 두 서명 시나리오 모두에 대한 규칙이 매우 신중하게 만들어집니다. 특정 파일이 사용자 모드 또는 커널에서만 로드된다는 것을 알고 있는 경우 추가 규칙을 안전하게 제거할 수 있습니다.
App Control은 플랫 파일 해시 값을 언제 사용하나요?
파일 형식이 Authenticode 사양을 준수하지 않아 App Control이 플랫 파일 해시를 사용하기 위해 다시 떨어지는 경우가 있습니다. 이 동작은 런타임에 파일의 메모리 내 버전을 변경하는 경우와 같은 여러 가지 이유로 발생할 수 있습니다. 이러한 경우 상관 관계가 있는 3089 서명 정보 이벤트에 표시된 해시가 3076/3077 블록 이벤트의 플랫 파일 해시와 일치하는 것을 볼 수 있습니다. 잘못된 형식의 파일에 대한 규칙을 만들려면 앱 제어 마법사를 사용하거나 정책 XML을 직접 편집하여 플랫 파일 해시에 대한 정책에 해시 규칙을 추가할 수 있습니다.