상태 구분

아티클
02/28/2022
읽는 데 21분 걸림

상태 분리는 다음과 같은 경우 보다 명확한 보안 경계를 사용 하는 향상 된 서비스 및 보안 모델입니다.

주요 시스템 영역에 대 한 보안 강화 지원
더 빠르고 클리너 업데이트 및 시스템 다시 설정 사용

이 모델은 모든 공장 OS 이미지에 사용 됩니다. 보안 경계는 다음 상태로 분류 됩니다.

주	설명	예
뿐	운영 체제 자체를 제외 하 고는이 영역을 영구적으로 변경할 수 없습니다.	운영 체제 이진 파일 레지스트리 하이브: `HKLM\SYSTEM` 및 `HKLM\SOFTWARE`
변경 가능, 높은 값	시스템이 다시 설정 된 후에는 변경 내용을 적용 하 여 다시 부팅 하거나 업데이트 한 후에도 유지 해야 할 수 있습니다.	시스템 설정 로그 파일 프로그램 데이터. 참고: api 또는와 같은 환경 변수를 사용 하 여 이러한 폴더를 참조 합니다. 코드에와 같은 절대 경로 `C:\Program Data\` 또는 다른 시스템 영역에 대 한 쓰기를 포함 하는 경우 쓰기 작업이 실패 하 고 액세스 위반이 발생할 수 있습니다.
변경 가능, 낮은 값	변경 작업을 수행할 수 있지만 다시 부팅 하거나 시스템을 다시 설정한 후에는 사라집니다.	일부 구성 요소는 및와 같은 레지스트리 하이브에 써야 할 수도 있습니다 `HKLM\SYSTEMHKLM\SOFTWARE` . 이러한 레지스트리 영역은 volatile로 로드 되므로 구성 요소가 특정 런타임에 대 한 쓰기 작업을 계속 수행할 수 있습니다. 다음 재부팅 시 변경 내용이 사라집니다.
사용자 데이터	변경할 수 있습니다. 각 사용자 데이터 프로필은 자체 파티션에서 암호화 되므로 사용자가 로그인 한 경우에만 변경 내용이 적용 됩니다.	NT 사용자 프로필 레지스트리 하이브: `HKCU`

팩터리 테스트의 경우에는 로그 파일 및 기타 테스트 파일을 데이터 파티션 또는에 저장 하는 것이 좋습니다 %PROGRAMDATA% .

상태 구분 위반

상태 분리는 다음과 같은 경우에 발생 합니다.

구성 요소가 MainOS 볼륨의 filesystem에 쓰려고 합니다.
구성 요소가 HKLM\SYSTEM 또는 HKLM\SOFTWARE 레지스트리 하이브에 씁니다.

이러한 규칙을 충족 하는 구성 요소를 개발 하는 데 도움을 주는 Windows 구성 요소가 이러한 위치 중 하나에 쓰려고 할 때마다 기록할 수 있습니다.

Windows에서 쓰기 작업을 추적 한다고 해 서 반드시 문제가 발생 하는 것은 아닙니다. 구성 요소는 때때로 HKLM\SYSTEMHKLM\SOFTWARE 변경 내용이 volatile이 될 것으로 예상 되는 또는 레지스트리 하이브에 의도적으로 쓸 수 있습니다.

계측

레지스트리 및 파일 시스템 작업에 대 한 로그를 수집 하는 몇 가지 방법이 있습니다. 사용할 적절 한 방법을 결정 하는 것은 사용 사례에 따라 다르며 부팅 시퀀스에서 드라이버가 활성화 되는 시점에 따라 결정 됩니다. 다음은 각 방법을 사용 하 여 상태 분리 및 드라이버 격리 위반을 찾는 시기를 요약 한 테이블입니다.

메서드	실행 시기	무엇을 찾을 수 있나요?
초기 부팅 자동로 거	드라이버 검증 도구를 사용 하 여 찾을 수 없는 파일 위반을 찾거나 동일한 추적에서 파일 및 레지스트리 위반을 확인 하려고 합니다.	모든 파일 위반 및 대부분의 레지스트리 위반
주문형로 거	드라이버 검증 도구를 사용 하 여 찾을 수 없는 파일 위반을 찾거나 동일한 추적에서 파일 및 레지스트리 위반을 확인 하려고 합니다.	모든 파일 위반 및 대부분의 레지스트리 위반
부팅 추적	위반에 대 한 자세한 스택 정보를 포함 하려고 합니다.	위반 인지 여부에 관계 없이 모든 파일 및 레지스트리 작업
드라이버 확인 프로그램 드라이버 격리 검사	장치를 가져오는 동안 모든 레지스트리 위반을 찾으려고 하 고, 일반 드라이버 테스트 및/또는 인증 테스트를 수행 하려는 경우	파일 위반 및 모든 레지스트리 위반 없음

위반의 실시간 보기

상태 분리 위반을 추적 하는 가장 쉬운 방법은 Windows 장치 포털을 통해 ETW (Windows 용 이벤트 추적) 실시간을 검토 하는 것입니다.

참고

이 원격 분석을 제공 하는 필터 드라이버는 구성 요소 다음에 로드 될 수 있습니다. 구성 요소가 부팅 프로세스 초기에 실행 되는 경우 다음 섹션을 확인 해야 합니다.

테스트 중인 장치에서 Windows 장치 포털에 로그인 합니다.
왼쪽의 ETW 로깅 탭으로 이동 합니다.
사용자 지정 공급자에서 다음 공급자를 사용 하도록 설정 합니다. d6e1490c-c3a6-4533-8de2-18b16ce47517 .
시나리오를 재현 합니다. 위반은 테이블에 표시 됩니다.
충분 한 데이터를 수집한 경우 파일에 저장 을 클릭 하 여 캡처된 위반을 포함 하는 텍스트 파일 (.csv)을 가져옵니다. 실시간 분석을 수행 하는 것 보다 다운로드 한 데이터를 사용 하는 것이 더 쉬울 수도 있습니다.

초기 부팅 자동 기록기

초기 부팅 자동 기록기를 사용 하 여 부팅 경로 초기에 수행 된 작업에 대 한 ETW 추적을 캡처합니다.

tshell을 사용 하 여 장치에 커넥트합니다.
Tracelog 를 실행 하 여 공급자 GUID: d6e1490c-c3a6-4533-8de2-18b16ce47517를 수신 하도록 자동 기록기를 구성 합니다.

버퍼를 128 kb로 설정 하 고, 최소 12 개의 버퍼와 최대 34 버퍼 (값이 낮을수록 이벤트를 삭제할 수 있음)를 설정 합니다.

세션 guid의 경우를 사용 하 여 guid를 생성 한 다음 앞에 숫자 기호 (#)를 추가 하거나 guid를 포함 하는 파일 이름을 제공할수 있습니다.

사용자 또는 응용 프로그램 데이터 폴더의 위치 (예:)를 사용 하는 것이 좋습니다. 하지만 로그 파일은 어디에 나 저장할 수 있습니다 -f %ProgramData%\Fabrikam\log.etl .
```
Tracelog.exe -addautologger StateSeparationViolationsAutologger -sessionguid #aabbccdd-1234-5678-90ab-a00bb00ccdd -f %ProgramData%\Fabrikam\log.etl -guid #d6e1490c-c3a6-4533-8de2-18b16ce47517 -b 128 -min 12 -max 34
```
자동 기록기 추적 세션을 시작 하려면 장치를 다시 부팅 합니다.
tshell을 사용 하 여 장치에 커넥트합니다.

자동 기록기를 중지 합니다.

Tracelog.exe -stop StateSeparationViolationsAutologger

ETL 파일을 가져오고 데이터를 검토 합니다.

a. 장치의 ProgramData 디렉터리 값 (예:)을 캡처합니다 E:\ProgramData .
```
cmd-device -InformationVariable echoInfo echo %ProgramData% $deviceProgramData = $echoInfo[0]
```
b. 이 값을 사용 하 여 ETL 파일을 장치에서 로컬 PC로 복사 합니다. 예제:
```
PS C:\> getd E:\ProgramData\Fabrikam\log.etl C:\hostdir\log.etl
```
WPA (Windows Performance Analzyer) 또는 기타 도구를 사용 하 여 추적 로깅 작업 데이터를 검토 합니다.

주문형로 거

주문형로 거를 사용 하 여 주문형 ETW 추적을 캡처할 수 있습니다.

공급자 GUID d6e1490c-c3a6-4533-8de2-18b16ce47517를 수신 대기 하도록 로깅 세션을 구성 합니다.

Tracelog.exe -start StateSeparationViolations -f <path to save ETL> -guid #d6e1490c-c3a6-4533-8de2-18b16ce47517

시나리오를 재현 하거나 테스트를 실행 합니다 (장치가 다시 부팅 되지 않는 한).

로깅 세션을 중지 합니다.

Tracelog.exe -stop StateSeparationViolations

장치에서 ETL 파일을 복사 합니다.

PS C:\> getd C:\ProgramData\Fabrikam\log.etl C:\hostdir\log.etl

로그 파일을 열고 Windows Performance Analyzer를 사용 하 여 추적 로깅 작업 데이터를 검토 합니다.

부팅 추적

초기 부팅 ETW 추적이 올바르게 설정 되 면 모든 레지스트리 작업 및/또는 파일 작업을 추적에서 캡처할 수 있으며 해당 레지스트리 작업을 진행 하는 코드 경로를 자세히 설명 하는 각 작업에 대 한 스택을 캡처할 수 있습니다.

TShell을 사용 하 여 장치에 커넥트
부팅 추적 (레지스트리, fileio 또는 둘 다)을 등록 합니다.
```
wpr -boottrace -addboot registry
wpr -boottrace -addboot fileio
```
장치를 다시 부팅 하 여 추적 캡처를 시작 합니다.
TShell을 사용 하 여 장치에 다시 커넥트 합니다.

추적을 중지합니다.

wpr -boottrace -stopboot <path where to write ETL>

디바이스에서 ETL 파일을 복사합니다.

PS C:\> getd C:\<path on device to the>\log.etl C:\hostdir\log.etl

로그 파일을 열고 Windows 성능 분석기 사용하여 추적 로깅 활동 데이터를 엽니다.
WPA에서 조사 중인 이진 파일을 스택 추적에서 확인할 수 있도록 기호를 로드하도록 지시한 다음 레지스트리 요약 테이블을 엽니다.

SYSTEM 및 SOFTWARE 하이브에 대한 작업만 표시하도록 테이블을 필터링하는 것이 좋습니다. 기본 키 트리" 열을 보는 경우 ““ 확장한 다음 머신 을 확장합니다. SYSTEM 및 SOFTWARE를둘 다 다중 선택하고 마우스 오른쪽 단추를 클릭하고 선택 영역으로 필터링을선택합니다.

스택이 조사 중인 이진 파일과 관련된 작업으로만 테이블을 필터링하는 것이 좋습니다. 이 필터링은 위에서 권장하는 SYSTEM 및 SOFTWARE 하이브에 대한 필터링을 기반으로 수행할 수 있습니다. 스택 열을 클릭하고 검색 상자를 엽니다. 조사 중인 이진 파일의 이름을 입력하고 모두 찾기를클릭합니다. 스택에서 이진 이름이 포함된 강조 표시된 줄 중 하나를 마우스 오른쪽 단추로 클릭하고 선택 영역으로 필터링을선택합니다.

드라이버 검증 도구 드라이버 격리 검사

DV(드라이버 검증 도구)는 시스템을 손상할 수 있는 부적절한 함수 호출 또는 작업에 대해 드라이버를 모니터링하는 데 사용되는 Windows 함께 제공됩니다. OS 빌드 19568부터 드라이버 검증 도구에는 드라이버 패키지 격리 요구 사항 위반을 모니터링하여 Windows 드라이버 개발자를 지원하는 새로운 기능이 있습니다. 드라이버 패키지 격리는 상태 분리 요구 사항을 준수하기 위해 팩터리 OS 시스템에서 드라이버가 준수해야 하는 주요 요구 사항입니다.

드라이버 검증 도구는 팩터리 OS 시스템에서 허용되지 않는 부적절한 레지스트리 읽기 및 쓰기를 모니터링합니다. 드라이버 개발 초기에 이 도구를 사용하여 구성 요소가 드라이버 격리 요구 사항을 위반하는 위치를 이해하고 수정할 수 있습니다.

구문:

참고

팩터리 OS 시스템에서 사용하도록 설정하는 경우 SSH를 통해 원격으로 팩터리 OS 시스템에 연결하기 위해 SSH를 사용하는 커넥트 참조하세요.

verifier /rc 33 36 /driver myDriver.sys

이렇게 하면 대상 드라이버(myDriver.sys)에서 드라이버 격리 검사가 활성화됩니다. 목록을 공백으로 구분하여 여러 드라이버를 선택할 수도 있습니다.

verifier /rc 33 36 /driver myDriver1.sys myDriver2.sys

확인 설정을 사용하도록 설정하려면 다시 부팅해야 합니다. 다음을 지정하여 수행할 수 있습니다.

shutdown /r /t 0

예상 동작 - 원격 분석 모드:

드라이버 가져오기의 초기 단계에서 이러한 검사에 권장되는 동작은 원격 분석 모드입니다. 이는 기본 동작이며 개발자가 진행 상황을 방해하는 버그 검사 없이 모든 위반을 볼 수 있는 방법을 제공합니다.

DV 드라이버 격리 검사는 커널 디버거가 연결된 위의 섹션에 지정된 구문을 사용하여 사용하도록 설정하는 것이 좋습니다. 다시 부팅 시 DV 설정을 사용하도록 설정하면 커널 디버거 출력에서 위반을 볼 수 있습니다.

다음은 드라이버 격리 요구 사항을 위반하는 드라이버의 몇 가지 예제 시나리오와 일반적인 출력은 다음과 같습니다.

시나리오:전체 절대 경로를 사용하는 ZwCreateKey:

"DRIVER_ISOLATION_VIOLATION: 드라이버 <> 이름: 레지스트리 작업은 절대 경로를 사용하면 안 됩니다. 단일 컴퓨터 레지스트리 키 '\Registry\Machine\SYSTEM'의 생성이 감지되었습니다."

시나리오: 승인된 API에서 작성되지 않은 핸들에 상대적인 경로를 사용하는 ZwCreateKey:

"DRIVER_ISOLATION_VIOLATION: 드라이버 <> 이름: 레지스트리 작업은 WDF 또는 WDM API에서 반환된 키 핸들만 사용해야 합니다. 단일 컴퓨터 레지스트리 키 '\REGISTRY\MACHINE\SYSTEM\SomeKeyThatShouldNotExist'의 생성이 감지되었습니다."

원격 분석 모드를 활용하여 구성 요소에 대한 모든 위반의 기준을 설정하고, 진행하면서 하나씩 테스트를 통해 수정하기 시작합니다.

예상 동작 - 선택 모드:

또한 드라이버 개발 프로세스에서 위반을 분명하게 만드는 모드에서 드라이버 격리 검사를 사용하도록 설정하는 것이 중요할 수 있습니다. DV는 위반이 발생할 때 induceabugcheck를 유도하도록 구성할 수 있습니다.

그러면 위반이 발생한 위치에 대한 정확한 세부 정보를 제공하는 메모리 덤프가 생성됩니다. 버그 검사 모드에서 DV를 사용하도록 설정하려면 다음 구문을 사용합니다.

verifier /onecheck /rc 33 36 /driver myDriver1.sys

이 모드는 드라이버가 프로덕션 준비에 근접하고 유효성 검사 및 테스트의 최종 단계를 진행하는 경우에 유용합니다.

코드 경로 최대화:

DV 드라이버 격리 규칙은 IHV가 기존 테스트 프레임워크를 실행한 동안 사용하도록 설정할 수 있습니다. 이렇게 하면 테스트 중인 드라이버에서 연습하는 코드 경로를 최대화하는 데 도움이 됩니다.

명령줄을 통한 디바이스 기본 사항 테스트는 드라이버에 대한 일반적인 코드 경로를 실행하기 위한 테스트의 좋은 기준입니다. 개발자는 DV 드라이버 격리 검사를 통해 이러한 테스트를 사용하도록 설정하여 가능한 한 빨리 드라이버 격리 위반을 포착할 가능성을 최대화할 수 있습니다.

개발 모드: 적용 사용 안 함

개발 목적으로 상태 분리 개발 모드에서 를 실행하여 상태 분리 적용을 해제할 수 있습니다. 이렇게 하면 요구 사항을 준수하지 않는 앱 및 드라이버(예: 공장 테스트 앱)를 개발, 테스트 및 실행할 수 있습니다.

개발 모드에서:

MainOS 파티션은 쓰기가 가능합니다.
의 변경 HKLM\SYSTEM 내용 및 는 다시 HKLM\SOFTWARE 부팅할 때 유지됩니다.
Windows 상태 분리 규칙을 위반하는 활동을 계속 모니터링합니다.

기능 를 로 대체하여 이미지 생성 시 개발 모드를구성할 수 STATESEPARATION_DEVMODE 있습니다.

다음 표에서는 각 모드 간의 차이점을 자세히 설명합니다.

상태 분리 모드	변경 불가능한 파일 시스템 액세스	불변 레지스트리 액세스
강제 적용 모드	쓰기가 허용되지 않음	레지스트리 변경 내용이 다시 부팅할 때 유지되지 않음
	ETW 및 디버거 출력의 위반 경고	ETW 및 디버거 출력의 위반 경고
개발 모드	읽기/쓰기 허용	레지스트리 변경 내용이 다시 부팅할 때 유지됩니다.
	ETW 및 디버거 출력의 위반 경고	ETW 및 디버거 출력의 위반 경고