Windows Vista에서 무결성 메커니즘을 구현하는 방법

  • 아티클

Windows 무결성 메커니즘은 Windows Vista에서 여러 가지 방법으로 사용됩니다. 기본 목적은 덜 신뢰할 수 있는 동일한 사용자 계정으로 실행되는 애플리케이션의 액세스 권한을 제한하는 것입니다. 이 메커니즘은 덜 신뢰할 수 있는 코드가 더 높은 수준에서 개체를 수정하는 것을 방지합니다. 관리자 그룹 또는 시스템의 제어 하에 있는 대부분의 개체에는 일반적으로 관리자 및 시스템에 대한 모든 권한 권한을 부여하고 인증된 사용자에게 읽기 및 실행 권한을 부여하는 DACL(임의 액세스 제어 목록)이 있습니다. Administrators 그룹 및 시스템을 제어하는 리소스의 예로는 애플리케이션용 프로그램 파일 디렉터리 또는 레지스트리의 HKEY_LOCAL_MACHINE 하이브가 있습니다. 무결성 메커니즘은 다른 사용자 계정 또는 그룹의 액세스를 제한하도록 이미 제대로 구성된 개체의 보안을 향상시키지 않습니다. 무결성 메커니즘의 주요 목적은 프로그램이 동일한 사용자 보안 주체의 모든 권한으로 리소스에 액세스할 수 있는 다양한 권한을 처리하는 것입니다.

추가 보호가 필요한 동일한 사용자 보안 주체가 제어하는 리소스는 주로 사용자의 프로필(C:\Users\<username> 디렉터리 및 레지스트리의 HKEY_CURRENT_USER hive) 및 해당 사용자를 대신하여 현재 실행 중인 애플리케이션 프로그램에 있습니다. Windows Vista는 다음과 같은 방법으로 무결성 메커니즘을 사용합니다.

  • UAC에서는 표준 사용자 권한으로 실행되는 프로세스와 관리 승인 모드에서 전체 관리 권한으로 실행되는 관리자 권한으로 실행되는 관리자 권한 프로세스 간의 액세스를 제한합니다.
  • COM 보안은 무결성 수준을 인식하며 낮은 무결성 클라이언트가 더 높은 무결성 수준에서 실행되는 클래스 인스턴스에 바인딩하는 것을 허용하지 않습니다.
  • 기본 보안 설정에서는 시스템 볼륨의 루트 폴더에 대한 액세스를 제한합니다.
  • 보호 모드 인터넷 Explorer 인터넷 브라우저에서 실행되는 코드의 기능을 제한하여 사용자 데이터 또는 사용자 프로필 설정을 수정합니다.
  • 낮은 무결성으로 실행되는 애플리케이션이 쓰기 가능한 파일 위치를 가질 수 있도록 하려면 사용자 프로필의 특정 폴더에 낮은 무결성 수준을 할당합니다.

무결성 메커니즘은 Windows Vista 보안 아키텍처의 일부입니다. 시간이 지남에 따라 신뢰할 수 없는 입력(주로 인터넷 연결)을 처리하는 특정 애플리케이션이 낮은 무결성 수준에서 실행되는 기능을 활용하도록 업데이트됩니다. 개인 생산성 애플리케이션은 사용자가 입력 데이터의 원본을 알고 있는 한 중간 무결성 수준에서 잘 실행됩니다. 대부분의 애플리케이션에서 무결성 메커니즘은 완전히 투명하며 애플리케이션 기능을 방해하지 않습니다. 애플리케이션 서비스를 업데이트하여 다양한 무결성 수준에서 클라이언트 프로세스에 대한 서버 리소스를 더 잘 격리할 수 있습니다.

무결성 수준 및 UAC

Windows Vista의 UAC는 관리 승인 모드를 사용할 때 동일한 데스크톱에서 서로 다른 액세스 수준에서 여러 프로그램을 실행합니다. 프로그램은 프로세스를 만들 때 프로세스에 할당된 보안 액세스 토큰에 따라 서로 다른 권한을 가집니다. 표준 사용자인 계정이 있는 사용자에게는 로그온하는 동안 생성된 보안 액세스 토큰이 하나만 있습니다. 표준 사용자 액세스 토큰에는 중간 무결성 수준이 할당됩니다. 중간 무결성 표준 사용자 액세스 토큰은 사용자가 실행하는 거의 모든 애플리케이션 프로세스에 할당됩니다. 보호 모드 인터넷 Explorer 같은 특정 애플리케이션은 아래에 자세히 설명된 예외입니다.

Administrators 그룹의 구성원인 계정이 있는 사용자에게는 로그온 시 생성된 두 개의 보안 액세스 토큰이 함께 연결되어 있습니다. 하나의 액세스 토큰은 중간 무결성 수준이 할당된 표준 사용자 액세스 토큰으로, 액세스 거부 검사에만 사용되는 관리자 그룹이 있고 특정 관리 권한이 제거됩니다. 두 번째 액세스 토큰은 관리자 그룹 및 관리 권한이 액세스 토큰에 있으므로 높은 무결성 수준이 할당된 전체 권한의 관리자 액세스 토큰입니다. 액세스 토큰은 해당 사용자 계정에 대해 동일한 대화형 로그온과 관련이 있기 때문에 연결됩니다. 두 액세스 토큰 모두 Active Directory에서 동일한 사용자 SID와 동일한 전역 그룹을 갖습니다(도메인 및 엔터프라이즈 관리 필터링된 그룹을 제외).

Windows Explorer(셸이라고도 함) 및 관리자가 아닌 모든 작업에는 표준 사용자, 중간 무결성 액세스 토큰이 할당됩니다. Administrators 그룹의 구성원인 사용자 계정의 경우 거의 모든 애플리케이션이 중간 무결성 액세스 토큰으로 실행됩니다. NO_WRITE_UP 무결성 정책은 중간 수준 프로세스의 액세스 권한이 암시적 중간 개체 필수 레이블이 있는 개체에 액세스하도록 제한하지 않습니다. 무결성 메커니즘은 더 높은 권한 수준에서 실행될 수 있는 다른 프로세스를 제어하도록 설계되지 않은 한 중간 무결성 수준에서 애플리케이션에 투명합니다. Windows UI 자동화는 다른 프로세스를 제어하도록 설계된 애플리케이션의 예입니다.

UAC 관리 승인 모드를 사용하면 사용자가 모든 권한의 상승된 액세스 토큰에 동의한 후 관리 작업 및 애플리케이션을 시작할 수 있습니다. 운영 체제는 동일한 사용자 SID에서 실행되는 더 높은 권한(관리자) 프로세스를 직접 변조하는 낮은 권한(표준 사용자) 프로세스의 기능을 제한해야 합니다. Windows 무결성 메커니즘은 중간 무결성 프로세스가 높은 무결성 프로세스에 대해 가질 수 있는 액세스 권한을 제한합니다. 프로세스 관리자(Windows 커널의 일부)는 NO_READ_UP 및 NO_WRITE_UP 필수 정책 옵션을 할당하여 낮은 무결성 프로세스가 읽기 또는 쓰기 액세스에 대해 더 높은 무결성 프로세스를 열지 못하도록 제한합니다.

낮은 무결성 프로세스에는 일반 실행 액세스만 있습니다. 일반 실행 액세스에는 다음이 포함됩니다.

  • SYNCHRONIZE, PROCESS_QUERY_LIMITED_INFORMATION
  • PROCESS_TERMINATE

더 높은 무결성 프로세스(프로세스의 가상 메모리에 대한 액세스 PROCESS_VM_READ 및 PROCESS_QUERY_INFORMATION)에 대한 일반 읽기 액세스는 암호 데이터 또는 인증에 사용되는 기타 키 자료를 포함할 수 있는 메모리에 대한 읽기 권한을 얻는 낮은 권한 프로세스의 기능을 차단하도록 제한됩니다. 더 높은 무결성 프로세스에 대한 일반 쓰기 액세스는 NO_WRITE_UP 정책에 의해 차단됩니다. 일반적인 쓰기 프로세스 액세스 권한은 다음과 같습니다.

  • PROCESS_CREATE_THREAD
  • PROCESS_VM_OPERATION
  • PROCESS_VM_WRITE
  • PROCESS_DUP_HANDLE
  • PROCESS_SET_QUOTA
  • PROCESS_SET_INFORMATION
  • PROCESS_SET_PORT

현재 사용자 레지스트리 하이브

사용자 프로필에 있는 대부분의 개체에는 명시적 필수 레이블이 할당되지 않으므로 암시적 기본 무결성 수준이 중간입니다. 이는 레지스트리의 HKEY_CURRENT_USER(HKCU) 하이브에 적용됩니다. HKCU에서 만든 키에는 암시적 중간 무결성 수준이 있습니다. 즉, Administrators 그룹의 구성원인 사용자의 경우 중간 무결성 표준 사용자 액세스 토큰 또는 높은 무결성 전체 관리자 액세스 토큰을 사용하여 실행되는 애플리케이션에서 HKCU 하이브를 쓸 수 있습니다. 애플리케이션 호환성을 위해 이 경우여야 합니다. HKEY_LOCAL_MACHINE(HKLM) 하이브에는 관리자 및 시스템에 모든 권한을 부여하고 사용자가 읽기 및 실행 권한을 부여하는 기본 보안 정책이 있습니다. HKLM 하이브는 전체 관리자 액세스 토큰이 할당된 관리자 권한 프로세스에서만 수정할 수 있습니다. HKLM 하이브는 높은 필수 레이블로 보호되지 않습니다.

명시적 필수 레이블이 없는 개체의 기본 무결성 수준은 보통이므로 관리자 그룹의 구성원인 사용자는 HKCU 및 사용자 프로필 데이터를 공유하는 다양한 권한 수준(중간 및 높음)에서 프로그램을 실행할 수 있습니다. Windows Vista는 중간 무결성과 높은 무결성 프로세스 간에 엄격한 경계를 적용하지 않습니다. 높은 무결성 프로세스는 "읽기"할 수 있습니다. 전체 권한의 높은 무결성 액세스 토큰을 사용하여 실행되는 애플리케이션은 일반적으로 HKCU에서 구성 정보를 읽거나 고 무결성 프로세스의 동작에 영향을 주는 입력 파일을 수락합니다. 전체 권한으로 실행되는 애플리케이션은 HKLM을 사용하여 관리자만 수정할 수 있는 구성 정보를 저장해야 합니다. 또한 전체 권한 애플리케이션은 사용자 수정 가능한 파일을 처리하기 전에 사용자 입력 데이터가 올바른 형식인지 확인해야 합니다.

COM은 무결성을 인식합니다.

COM은 애플리케이션 구성 요소 및 개체 서비스를 빌드하기 위한 프레임워크입니다. COM 인프라는 CoCreateInstance를 호출하는 클라이언트의 무결성 수준과 클래스 instance 실행하는 서버 프로세스를 인식합니다. 무결성 수준이 동작에 영향을 미치는 COM 기능 영역은 다음과 같습니다.

  • COM 권한 상승 모니커를 사용하면 관리자가 동의를 제공하거나 표준 사용자가 명시적 관리자 자격 증명을 제공한 후 클라이언트가 높은 무결성 수준에서 상승된 서비스를 시작할 수 있습니다.
  • 중간 무결성 수준 이상으로 관리자 권한으로 실행되는 서버 클래스에는 HKLM 레지스트리 하이브에 정의된 CLSID가 있어야 합니다.
  • COM은 서버가 낮은 클라이언트에서 프로그래밍 방식으로 액세스를 허용하지 않는 한 낮은 무결성 수준의 클라이언트가 더 높은 무결성 수준에서 서버의 실행 중인 인스턴스에 바인딩하지 못하도록 합니다.

COM 권한 상승 모니커를 사용하면 낮은 또는 중간 무결성 수준의 애플리케이션이 높은 무결성에서 상승된 권한으로 실행되는 프로세스에서 COM 서비스를 시작할 수 있습니다. 권한 상승 모니커를 사용하면 관리자 권한으로 실행되도록 설계되고 완전한 애플리케이션 호환성을 위한 것이 아닌 특정 작업을 수행할 수 있습니다. COM 권한 상승은 UAC 권한 상승과 통합됩니다. 관리자 권한 COM 서버 프로세스에는 높은 무결성을 가진 모든 권한의 관리자 권한 액세스 토큰이 할당됩니다. COM에서는 낮은 수준의 클라이언트가 더 높은 무결성 수준에서 서버의 실행 중인 instance 바인딩할 수 없습니다.

COM 서버가 낮은 무결성 클라이언트의 연결을 지원하도록 설계된 경우 서버는 낮은 무결성 클라이언트에서 바인딩을 허용하도록 CLSID에 대한 레지스트리의 시작/활성화 권한을 프로그래밍 방식으로 수정할 수 있습니다. COM은 필수 레이블 ACE의 NO_EXECUTE_UP 필수 정책을 사용하여 클라이언트가 더 높은 무결성 수준에서 서버 instance 바인딩할 수 있는지 여부를 제어합니다. COM 시작/활성화 액세스 권한은 정품 인증을 확인하기 위해 COM에서 사용하는 GENERIC_MAPPING 일반 실행 액세스 권한에 매핑됩니다. 개체와 연결된 필수 레이블의 무결성 수준은 서버에 바인딩할 수 있는 클라이언트의 가장 낮은 무결성 수준을 식별합니다. 파일 시스템 액세스와 마찬가지로 기본 암시적 필수 정책을 사용하면 중간 무결성 클라이언트가 서버에 바인딩할 수 있습니다.

낮은 무결성 클라이언트가 서버의 instance 바인딩할 수 있도록 설계된 COM 서버의 경우 COM 활성화 권한은 서버 코드에 의해 설정됩니다.

낮은 무결성 클라이언트가 서버에 바인딩되도록 허용하려면

  1. 낮은 무결성 수준에 대한 NX(NO_EXECUTE_UP) 정책을 사용하여 필수 레이블을 정의합니다. 낮은 무결성에 대한 필수 레이블 정책을 사용하는 개체 보안 설명자에 대한 SDDL은 다음과 같습니다.

    O:BAG:BAD:(A;;0xb;;;WD)S:(ML;;NX;;;LW)

  2. 문자열 보안 설명자를 이진 보안 설명자로 변환합니다.

  3. 이진 보안 설명자를 사용하여 서버 CLSID에 대한 CLSID 시작 권한을 설정합니다.

dcomcfg.exe COM 보안 UI는 무결성 수준을 지원하지 않습니다.

COM 시작 권한 필수 정책을 설정하는 방법에 대한 코드 예제는 WINDOWS 무결성 메커니즘 리소스 에서 COM 및 무결성 수준 지원에 대한 자세한 내용을 확인할 수 있습니다.

서비스에 시스템 무결성 수준이 할당됩니다.

SCM(서비스 제어 관리자)은 특수 서비스 계정 또는 사용자 이름 및 암호를 사용하여 서비스 프로세스를 시작합니다. 특수 서비스 계정은 LocalSystem, LocalService 및 NetworkService입니다. 이러한 서비스 계정 중 하나에서 실행되는 서비스에는 다른 사용자를 가장하는 동안 서비스가 작업을 수행할 수 있는 SE_IMPERSONATE_NAME 권한과 같은 특별한 권한이 있습니다. Windows Vista는 특수 서비스 계정 중 하나에서 실행되는 서비스의 프로세스 개체에 시스템 무결성 수준을 할당합니다. 프로세스 Explorer 다음 이미지는 특수 서비스 계정에 대한 액세스 토큰에 할당된 시스템 무결성 수준을 보여 줍니다.

그림 6 서비스에 대한 시스템 무결성 수준

서비스 프로세스에는 시스템 무결성 수준이 있지만 이러한 주체에서 만든 보안 개체에는 시스템 필수 레이블이 할당되지 않습니다. 서비스에서 만든 개체(자식 프로세스, 스레드, 액세스 토큰 및 작업 제외)에는 암시적 중간 무결성 수준이 있습니다.

Windows Vista의 서비스 변경 내용은 보안, 안정성 및 관리 효율성 향상을 위한 서비스 변경 내용을 설명합니다. 서비스의 변경 내용은 세션 0에서 서비스를 격리하고 서비스가 서비스 SID를 사용하여 액세스할 수 있는 리소스를 격리하여 시스템 보안을 향상시킵니다. 특수 서비스 계정에 대한 시스템 무결성 수준은 서비스 격리 목표와 일치합니다. 시스템 무결성 수준에서 실행되는 서비스 프로세스는 낮은 무결성 프로세스에 의해 에 액세스하지 못하도록 보호됩니다. 낮은 무결성 프로세스에서 서비스 프로세스를 여는 데 사용할 수 있는 프로세스 액세스 권한은 다음으로 제한됩니다.

  • SYNCHRONIZE
  • PROCESS_QUERY_LIMITED_INFORMATION
  • PROCESS_TERMINATE

일부 애플리케이션은 하나 이상의 서비스 계정에서 실행될 수 있는 여러 협력 프로세스를 사용하여 설계되었습니다. 프로세스와 서비스(예: RPC) 간의 대부분의 IPC(Interprocess Communication) 메커니즘은 무결성 수준에 의해 제한되지 않습니다. 서비스는 특히 낮은 무결성 클라이언트의 입력 유효성을 검사하는 데 주의해야 합니다.

서비스 간 중복 핸들

여러 프로세스를 사용하는 서비스 애플리케이션은 서버 프로세스 간에 파일과 같은 개체에 대한 핸들을 복제하도록 디자인되기도 합니다. 모든 프로세스가 동일한 특수 서비스 계정으로 실행되는 경우 서비스 프로세스에 대한 기본 보안에 제한이 적용되지 않습니다. 특수 서비스 계정으로 실행되는 서비스 프로세스의 기본 DACL은 duplicateHandle 호출에 필요한 PROCESS_DUP_HANDLE 액세스 권한을 부여하지 않습니다. 애플리케이션 서비스 디자이너는 서로 다른 사용자 계정으로 실행되는 애플리케이션 프로세스 간에 핸들을 공유하기 위해 공동 프로세스에서 사용하는 다른 사용자 계정에 서비스 프로세스 개체에 대한 PROCESS_DUP_HANDLE 액세스 권한을 부여하는 기능을 구현해야 합니다. 그러나 핸들을 복제하려는 서비스가 시스템 무결성 수준에서 실행되는 특수 서비스 계정인 경우 필수 레이블 정책으로 인해 높거나 중간 무결성 수준에서 실행되는 공동 프로세스는 PROCESS_DUP_HANDLE 얻을 수 없습니다. DACL이 PROCESS_DUP_HANDLE 액세스 권한을 부여하더라도 필수 레이블 정책은 액세스하는 낮은 무결성 호출자를 허용하지 않습니다. 이 상황이 서비스 애플리케이션 디자인에 영향을 주는 경우 DuplicateHandle을 시작하는 프로세스가 핸들의 원본인 프로세스의 무결성 수준보다 높은 무결성 수준에 있도록 애플리케이션 서비스 코드를 변경해야 합니다. 즉, 무결성이 높은 서비스는 핸들 원본으로 낮은 무결성 프로세스에서 대상으로 핸들을 자체 프로세스에 복제할 수 있습니다.

가장 정책

SE_IMPERSONATE_NAME 권한을 사용하면 서버 프로세스가 클라이언트 프로세스의 보안 컨텍스트를 가장할 수 있습니다. 가장 권한은 강력한 권한입니다. 무결성 메커니즘은 가장 권한을 높은 또는 시스템 무결성 수준이 있는 액세스 토큰과 연결합니다. 무결성 메커니즘은 주체가 가장 권한이 있는 경우에만 더 높은 무결성 수준에서 클라이언트를 가장할 수 있는 정책을 적용합니다.

이 정책 제한이 적용되는 시나리오는 낮은 무결성 프로세스가 관리자 자격 증명을 입력하도록 관리자 사용자를 설득하기 위해 UI를 스푸핑하는 경우입니다. 악성 코드는 자격 증명을 사용하여 LsaLogonUser 및 ImpersonateLoggedOnUser를 호출하여 더 높은 권한 수준에서 프로세스를 시작하려고 시도합니다. 가장 액세스 토큰에 대한 무결성 메커니즘 정책은 LsaLogonUser에서 반환하는 액세스 토큰의 무결성 수준이 호출 프로세스의 무결성 수준보다 높지 않아야 한다는 것입니다.

높은 무결성 수준의 루트 폴더

시스템 파티션의 루트 폴더(일반적으로 C:\ )는 지금까지 프로그램 또는 임시 파일을 저장하는 편리한 장소로 사용되었지만 권장되지는 않습니다. 관리자 권한이 필요한 설치 프로그램은 시작되기 전에 루트 폴더에 복사되는 경우가 많습니다. 루트 폴더에 대한 기본 보안 정책은 인증된 사용자가 루트 폴더 아래에 하위 폴더를 만들 수 있도록 하지만 관리자만 루트 폴더에 파일을 만들 수 있도록 설계되었습니다. 또한 이상적으로 이 정책은 관리자가 아닌 사용자가 관리자가 만든 폴더의 파일을 수정하는 것을 허용하지 않습니다. 이 정책은 루트 폴더에 ACL만 사용하여 정의하기 어렵습니다.

자식 개체에 적용되지만 자식 컨테이너에는 적용되지 않는 높은 무결성 수준으로 필수 레이블을 설정하면 루트 폴더에 대한 기본 보안이 이 정책을 충족합니다. 중간 무결성 수준에서 프로그램을 실행하는 표준 사용자는 ACL이 사용자에게 액세스 수정 권한을 부여하더라도 루트 폴더의 관리자가 만든 파일을 수정할 수 없습니다. 루트 폴더에는 개체가 상속되고 하위 폴더로 전파되지 않는 높은 무결성의 상속 가능한 필수 레이블이 있습니다.

다음 이미지는 C:\의 기본 보안 설정을 보여줍니다. 루트 폴더(개체 포함)는 높은 무결성에서 필수 레이블을 상속합니다. 표 9에는 이미지의 약어에 대한 정의가 표시됩니다.

표 9 이미지 약어

약어 정의

(OI)

개체 상속

(NP)

전파 없음

(IO)

상속만

(NW)

쓰기 없음

그림 7 루트 폴더의 필수 레이블

낮은 무결성의 보호 모드 인터넷 Explorer

인터넷 Explorer 인터넷에서 임의의 데이터와 확장 가능한 코드를 허용하도록 설계된 애플리케이션의 예입니다. 인터넷 콘텐츠의 원본은 거의 인증되지 않으므로(서명됨) 인터넷의 모든 입력이 신뢰할 수 없다고 가정해야 합니다. 인터넷 Explorer 또는 다른 인터넷 브라우저에 대한 공격은 인터넷에서 사용할 수 있는 동적 콘텐츠 및 데이터의 신뢰할 수 없는 특성을 보여 줍니다. 보안 관점에서 인터넷 Explorer 프로세스 자체가 손상되고 신뢰할 수 없는 것으로 가정하고 브라우저에 대한 공격으로 인한 잠재적 손상을 제한하는 솔루션을 찾습니다. 브라우저 기반 공격에 대한 몇 가지 제안된 솔루션은 웹 브라우저를 다른 애플리케이션 및 데이터와 완전히 격리하려고 합니다. 아쉽게도 브라우저의 완전한 격리는 .pdf 파일과 같은 다양한 파일 형식을 읽는 프로그램을 자동으로 시작하는 기능과 같이 사용자의 검색 환경에 큰 영향을 미칩니다. 완전한 격리는 브라우저에 사용자 데이터 파일에 대한 읽기 권한이 없는 경우 웹 사이트에 사진을 업로드하는 것과 같은 일반적인 사용자 환경을 방해합니다.

보호 모드 인터넷 Explorer 목표는 원치 않는 시작 파일을 만들거나, 사용자 데이터 파일을 수정하거나, 브라우저 구성 설정을 성가신 변경하거나, 데스크톱에서 실행되는 다른 프로그램의 동작을 유도하기 위해 브라우저에서 실행되는 악용의 기능을 제한하기 위해 프로세스에 사용할 수 있는 액세스 권한을 줄이는 것입니다. 낮은 무결성 프로세스에서 보호 모드 인터넷 Explorer 실행되는 모든 코드는 신뢰할 수 없는 것으로 간주됩니다. 개체의 기본 중간 무결성 수준은 낮은 무결성으로 명시적으로 레이블이 지정된 키를 제외하고 브라우저가 쓰기 액세스를 위해 디렉터리, 파일 또는 레지스트리 키를 열지 못하도록 합니다. UIPI는 낮은 무결성 브라우저 코드가 잠재적으로 손상될 수 있는 창 메시지를 데스크톱에서 실행 중인 다른 애플리케이션으로 보내지 못하도록 방지합니다.

낮은 무결성으로 실행되는 브라우저에는 사용자 데이터 파일에 대한 읽기 권한이 있습니다. Windows 무결성 메커니즘은 기밀성을 적용하지 않으므로 정보 흐름을 제한하지 않습니다. 이 프로세스는 기본 자격 증명을 사용하여 네트워크 프록시 서버(인터넷에 연결하는 데 인증이 필요한 경우 필요) 또는 웹 페이지를 인쇄하기 위해 네트워크 프린터 디바이스와 같은 네트워크 연결을 시작할 수도 있습니다. 무결성이 낮은 프로세스는 다른 네트워크 서비스에 대한 인증된 연결을 시작하여 해당 서버에 현재 사용자로 인증할 수도 있습니다.

인터넷 Explorer 애플리케이션 디자인에는 낮은 무결성 수준에서 보호 모드에서 실행하기 위해 일부 재구성이 필요했습니다. 주요 변경 내용은 특정 프로그램 작업이 중간 무결성 수준에서 실행되는 broker 프로세스라고 하는 별도의 프로세스로 이동되었다는 것입니다. 브로커 프로세스는 사용자가 인터넷 Explorer 아이콘 또는 URL 링크를 클릭할 때 중간 무결성 수준에서 시작됩니다. 브로커는 URL 및 영역 정책을 확인하고 낮은 무결성 수준에서 iexplore.exe 자식 프로세스를 시작하여 인터넷에 연결하고 웹 페이지를 렌더링합니다. 프로세스 Explorer 다음 이미지는 ieuser.exe, 중간 무결성 수준의 broker 프로세스 및 낮은 무결성 수준의 iexplore.exe 프로세스를 보여줍니다.

그림 8 보호 모드 인터넷 Explorer 프로세스

인터넷 Explorer 웹 브라우저에서 사용자가 경험하는 모든 작업은 낮은 무결성 프로세스 내에서 수행됩니다. 인터넷 옵션 설정 변경 또는 파일로 저장 대화 상자와 같은 몇 가지 특정 작업은 broker 프로세스에서 처리됩니다. URL이 기본 영역 정책 설정에 따라 신뢰할 수 있는 사이트인 경우 broker 프로세스는 중간 무결성 프로세스에서 다른 iexplore.exe instance 시작합니다. 모든 브라우저 확장 및 ActiveX 컨트롤은 낮은 무결성 프로세스 내에서 실행됩니다. 이는 브라우저 확장에 대한 잠재적인 악용이 낮은 무결성에서도 실행되고 있다는 이점이 있습니다.

인터넷 Explorer Microsoft에서 개발하지 않은 브라우저 확장 및 ActiveX 컨트롤을 호스트하고, 다른 파일 확장명의 mime 형식을 기반으로 다른 애플리케이션을 시작하고, 단일 부모 창 프레임 내에서 다른 애플리케이션의 클라이언트 창을 통합하기 때문에 다른 애플리케이션보다 다소 복잡합니다. 또한 사용자는 브라우저를 통해 인터넷에서 소프트웨어를 다운로드하고 애플리케이션 패키지 또는 애플리케이션 설치 관리자를 즉시 시작합니다. 이러한 작업의 대부분은 작업을 확인하기 위해 사용자를 통해 중재하기 위해 더 높은 무결성 수준에서 broker 프로세스의 도움이 필요합니다. 그렇지 않으면 브라우저에서 실행되는 코드가 시스템에 악성 소프트웨어를 설치하고 사용자의 데이터를 수정하거나 삭제하려고 할 수 있습니다. ActiveX 컨트롤 설치는 관리자 권한이 필요한 UAC에서 시작한 관리자 권한 작업을 사용하여 수행됩니다.

인터넷 Explorer 브라우저와 다른 로컬 애플리케이션 간의 광범위한 사용자 상호 작용을 지원하므로(복사 및 붙여넣기는 한 가지 명백한 예임) 개체에 대한 쓰기 액세스를 제한하는 무결성 메커니즘은 완전한 격리 메커니즘이 아닙니다. 보호 모드 인터넷 Explorer 디자인은 다양한 상호 작용을 살펴보고 특히 브로커의 동작과 낮은 권한 iexplore.exe 프로세스의 동작을 조정하여 최소 권한 기능을 유지하면서 풍부하고 협업적인 사용자 환경을 제공합니다.

보호 모드 인터넷 Explorer 대한 자세한 내용은 보호 모드 인터넷 Explorer 이해 및 작업(https://go.microsoft.com/fwlink/?LinkId=90931)을 참조하세요.