앱 제어 거부 정책 만들기에 대한 지침

아티클
10/01/2024
적용 대상:

✅ Windows 11, ✅ Windows 10

비즈니스용 App Control을 사용하면 특정 드라이버 및 애플리케이션을 명시적으로 거부하는 정책을 만들 수 있습니다. 효과적인 비즈니스용 App Control 거부 정책을 만들려면 활성 정책에 대해 파일을 평가할 때 App Control이 적용되는 규칙 우선 순위의 순서를 이해 해야 합니다.

독립 실행형 거부 정책

거부 규칙으로만 구성된 정책을 만들 때 명시적 거부 규칙 외에도 정책의 커널 및 사용자 모드 섹션에 "모두 허용" 규칙을 포함해야 합니다. "모두 허용" 규칙은 정책에 의해 명시적으로 거부되지 않은 모든 항목을 실행할 수 있도록 합니다. 거부 전용 정책에 "모두 허용" 규칙을 추가하지 못하면 모든 것을 차단할 위험이 있습니다. 이 결과는 일부 코드가 명시적으로 거부되고 다른 모든 코드가 암시적으로 거부되기 때문에 발생합니다. 권한 부여 규칙이 없기 때문입니다. 독립 실행형 거부 정책을 만들 때 AllowAll 정책 템플릿 을 사용하는 것이 좋습니다.

<FileRules>
  <Allow ID="ID_ALLOW_A_1" FriendlyName="Allow Kernel Drivers" FileName="*" />
  <Allow ID="ID_ALLOW_A_2" FriendlyName="Allow User mode components" FileName="*" />
</FileRules>
<SigningScenarios>
    <SigningScenario Value="131" ID="ID_SIGNINGSCENARIO_DRIVERS" FriendlyName="Kernel Mode Signing Scenario">
      <ProductSigners>
        <FileRulesRef>
          <FileRuleRef RuleID="ID_ALLOW_A_1" />
        </FileRulesRef>
      </ProductSigners>
    </SigningScenario>
    <SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_WINDOWS" FriendlyName="User Mode Signing Scenario">
      <ProductSigners>
        <FileRulesRef>
          <FileRuleRef RuleID="ID_ALLOW_A_2" />
        </FileRulesRef>
      </ProductSigners>
    </SigningScenario>
</SigningScenarios>

앞의 "모두 허용" 규칙을 추가해도 명시적 허용 목록을 적용하는 배포한 다른 App Control 정책에는 영향을 주지 않습니다. 설명하려면 다음 예제를 고려하세요.

Policy1은 Windows 및 Microsoft 서명 애플리케이션에 대한 허용 목록입니다.

Policy2는 MaliciousApp.exe 차단하고 Windows 구성 요소 이진 wmic.exe 차단하는 새로운 거부 정책입니다. "모두 허용" 규칙도 포함됩니다.

policy2에 명시적 블록 규칙이 있으므로 MaliciousApp.exe 차단됩니다. 또한 해당 정책의 파일을 다루는 허용 규칙이 없으므로 Policy1에 의해 암시적으로 차단됩니다.
Policy2에 명시적 블록 규칙이 있으므로 Windows 서명 파일 wmic.exe 차단됩니다.
Policy1 및 Policy2에는 파일을 포함하는 명시적 허용 규칙이 있으므로 다른 모든 Windows 및 Microsoft 서명 애플리케이션이 허용됩니다.
다른 모든 애플리케이션은 암시적으로 거부됩니다. 예를 들어 ExampleApp.exe 은 Policy1이 아닌 Policy2에서만 신뢰할 수 있으므로 허용되지 않습니다(모든 규칙 허용).

혼합 허용 및 거부 정책 고려 사항

명시적 허용 규칙을 포함하는 기존 정책에 거부 규칙 집합을 추가하려면 앞의 "모두 허용" 규칙을 포함하지 마세요. 대신 앱 제어 마법사를 통해 또는 다음 PowerShell 명령을 사용하여 거부 규칙을 기존 App Control 정책과 병합해야 합니다.

$DenyPolicy = <path_to_deny_policy>
$ExistingPolicy = <path_to_existing_policy>
Merge-CIPolicy -PolicyPaths $ DenyPolicy, $ExistingPolicy -OutputFilePath $ExistingPolicy

모범 사례

감사 모드에서 먼저 테스트 - 모든 새 정책과 마찬가지로 감사 모드에서 새 거부 정책을 배포하고 3076 감사 블록 이벤트를 모니터링하여 차단하려는 애플리케이션만 차단되도록 하는 것이 좋습니다. 이벤트 뷰어 로그 및 고급 헌팅을 통한 차단 이벤트 모니터링에 대한 자세한 내용: 비즈니스용 App Control 정책 관리 및 문제 해결
권장되는 거부 규칙 유형 - 서명자 및 파일 특성 규칙은 보안, 관리 효율성 및 성능 관점에서 권장됩니다. 해시 규칙은 필요한 경우에만 사용해야 합니다. 파일의 해시는 파일을 변경하면서 변경되므로 공격자가 파일을 간단하게 업데이트할 수 있는 해시 기반 블록 정책을 따라가기 어렵습니다. App Control은 해시 규칙 구문 분석을 최적화하지만 정책에 수만 개 이상의 해시 규칙이 있는 경우 일부 디바이스는 런타임 평가 시 성능에 영향을 줄 수 있습니다.

거부 정책 만들기 자습서

거부 규칙 및 정책은 PowerShell cmdlet 또는 앱 제어 마법사를 사용하여 만들 수 있습니다. 가능한 경우 서명자 규칙(PCACertificate, Publisher 및 FilePublisher)을 만드는 것이 좋습니다. 서명되지 않은 이진 파일의 경우 원래 파일 이름 또는 해시와 같은 파일의 특성에 대한 규칙을 만들어야 합니다.

소프트웨어 게시자 기반 거부 규칙

$DenyRules += New-CIPolicyRule -Level FilePublisher -DriverFilePath <binary_to_block> -Fallback SignedVersion,Publisher,Hash -Deny

소프트웨어 특성 기반 거부 규칙

$DenyRules += New-CIPolicyRule -Level FileName -DriverFilePath <binary_to_block> -Fallback Hash -Deny

해시 기반 거부 규칙

$DenyRules += New-CIPolicyRule -Level Hash -DriverFilePath <binary_to_block> -Deny

AllowAll 템플릿 정책을 사용하여 거부 규칙 병합

거부 규칙을 만든 후 AllowAll 템플릿 정책과 병합할 수 있습니다.

$DenyPolicy = <path_to_deny_policy_destination>
$AllowAllPolicy = $Env:windir + "\schemas\CodeIntegrity\ExamplePolicies\AllowAll.xml"
Merge-CIPolicy -PolicyPaths $AllowAllPolicy -OutputFilePath $DenyPolicy -Rules $DenyRules
Set-CiPolicyIdInfo -FilePath $DenyPolicy -PolicyName "My Deny Policy" -ResetPolicyID

거부 정책 배포

이제 배포할 준비가 된 거부 정책이 있어야 합니다. 관리형 엔드포인트에 정책을 배포하려면 앱 제어 배포 가이드 를 참조하세요.

다음을 통해 공유