보안
소프트웨어 제한 정책을 사용하여 응용 프로그램 잠금
Chris Corio and Durga Prasad Sayana
한 눈에 보기:
- 소프트웨어 제한 정책의 작동 방식
- 사용자 환경의 응용 프로그램 인벤토리
- 정책 만들기 및 적용
IT 전문가들은 데스크톱 시스템의 총 소유 비용(TCO)을 줄여야 할 때 흔히 두 가지 핵심 전략을 생각합니다. 첫 번째 전략은
Administrators 그룹에서 데스크톱 사용자의 계정을 가져오는 것이고, 두 번째 전략은 사용자가 실행할 수 있는 응용 프로그램을 제한하는 것입니다. 엔터프라이즈 환경에서 이러한 문제를 해결하기는 대단히 어려울 수 있으나, Windows Vista®에는 이 목표를 달성하는 데 도움이 되는 몇 가지 기능이 있습니다.
Windows Vista 및 UAC(사용자 계정 컨트롤) 기능이 비약적으로 발전한 결과, IT 전문가들은 엔터프라이즈 사용자를 Users 그룹(표준 사용자)의 구성원으로 실행할 수 있게 되었습니다. UAC 기능으로 인해 모든 응용 프로그램의 기본 보안 컨텍스트가 Administrator 그룹이 아닌 User 그룹으로 바뀌었습니다. Users 그룹으로 마이그레이션하는 것은 만만찮은 작업이지만 시간이 지나고 업계가 이 새로운 패러다임에 적응해 갈수록 점점 더 쉬워질 것입니다.
대부분의 관리자는 사용자를 Users 그룹으로 이동하는 문제를 분석하는 도중이나 분석을 마친 후에 사용자에게 필요한 응용 프로그램의 카탈로그를 작성하고 그러한 응용 프로그램만 허용할 방법이 무엇인지 고민합니다. 소프트웨어 제한 정책 기능은 IT 전문가들의 이러한 고민을 해결하기 위해 설계되었습니다.
즉, 실행을 허용할 응용 프로그램을 지정한 다음 그 정책을 그룹 정책으로 배포하기만 하면 됩니다. 이러한 정책을 전사적으로 적용하면 TCO를 줄일 수 있을 뿐 아니라 이 잠금으로 인해 지원되지 않는 응용 프로그램 관련 문제도 제한됩니다. 추가 기사 "핵심 소프트웨어 제한 정책"에서 다룬 것처럼 매우 특이하고 흥미로운 방식으로 소프트웨어 제한 정책을 사용할 수도 있습니다.
소프트웨어 제한 정책의 작동 방식
소프트웨어 제한 정책의 목적은 Windows Vista 시스템에서 사용자가 실행할 수 있는 코드를 정확히 제어하는 데 있습니다. 관리자는 해당 환경에서 실행 가능한 작업과 불가능한 작업을 정의하는 정책을 작성합니다. 그런 다음 코드를 실행할 가능성이 있는 모든 시기와 위치를 감안하여 이 정책을 평가합니다. 여기에는 프로세스를 생성할 때, ShellExecute를 호출할 때, 스크립트를 실행할 때 등이 모두 포함됩니다. 더 자세한 내용은 조금 뒤에 설명하겠습니다.
실행이 허용된 응용 프로그램은 그대로 시작되지만, 실행을 허용하지 않기로 결정된 응용 프로그램은 차단하고 사용자에게 그 사실을 알립니다. 예를 들어, "시작" 메뉴에서 "카드놀이"를 실행하려고 하는데 이 프로그램의 실행이 허용되지 않았다면 그림 1과 비슷한 대화 상자가 표시됩니다.
그림 1** 차단된 응용 프로그램에 나타나는 대화 상자 **(더 크게 보려면 이미지를 클릭하십시오.)
소프트웨어 제한 정책을 정의하기 위한 UI는 GPOE(그룹 정책 개체 편집기)에 있으며, 여기서 잠금 정책을 작성합니다. 실행 가능한 코드와 실행 불가능한 코드를 정의하는 방법은 다양합니다. 정책을 작성하고 테스트를 마친 뒤 해당 정책을 배포할 수 있습니다.
소프트웨어 제한 정책 정의
가장 먼저 내려야 할 주요 결정은 기본 규칙 유형을 선택하는 것이며, 이 결정은 해당 환경에서 소프트웨어 제한 정책의 작동 방식을 크게 좌우합니다. 소프트웨어 제한 정책은 "허용 목록" 또는 "거부 목록" 모드로 배포할 수 있습니다. 기본적으로, 사용자 환경에서 실행을 허용할 모든 응용 프로그램을 설명하는 정책을 만들지 아니면 실행할 수 없는 모든 응용 프로그램을 정의하는 정책을 만들지 선택하는 것입니다.
"허용 목록" 모드에서 정책의 기본 규칙은 "제한됨"이며 명시적으로 실행을 허용하지 않은 모든 응용 프로그램은 차단됩니다. "거부 목록" 모드의 기본 규칙은 "제한 없음"이고 명시적으로 나열된 응용 프로그램만 제한합니다.
짐작하시다시피, 응용 프로그램 잠금을 통해 대폭적인 TCO 절감과 보안상의 이점을 추구하려는 경우 "거부 목록" 모드는 비현실적인 방법입니다. 모든 맬웨어와 문제가 있는 기타 응용 프로그램을 차단하는 대규모 목록을 작성하여 유지하는 것은 거의 불가능하므로, 기본 규칙이 "제한됨"인 "허용 목록" 모드로 소프트웨어 제한 정책을 구현하는 것이 좋습니다.
사용자 환경의 응용 프로그램 인벤토리
실행 가능한 응용 프로그램을 지정하는 정책을 설계하려면 사용자에게 필요한 응용 프로그램이 무엇인지 정확히 파악해야 합니다. 소프트웨어 제한 정책은 매우 간단한 정책으로 사용자 환경에서 실행 중인 응용 프로그램을 정확하게 이해하기 위한 고급 로깅 기능을 제공합니다.
사용자 환경의 샘플 시스템에서 기본 규칙이 "제한 없음"으로 설정된 소프트웨어 제한 정책을 배포하고 그 밖의 추가 규칙은 모두 제거합니다. 이 계획에서는 소프트웨어 제한 정책을 사용하기는 하지만 응용 프로그램을 제한하는 대신 실행 중인 응용 프로그램을 모니터할 뿐입니다.
그런 다음 아래와 같은 레지스트리 값을 만들어 고급 로깅 기능을 지정하고 로그 파일을 기록할 경로를 설정합니다.
"HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\
CodeIdentifiers"
String Value: LogFileName, <path to a log file>
이제 응용 프로그램을 실행하여 소프트웨어 제한 정책이 평가되면(모두 실행 허용하는 정책도 평가됨) 로그 파일에 항목이 기록됩니다.
각 로그 항목에는 소프트웨어 제한 정책의 호출자, 호출 프로세스의 프로세스 ID(PID), 평가 대상, 적용된 소프트웨어 제한 정책의 유형, 규칙 식별자 등이 포함됩니다. 다음은 사용자가 notepad.exe를 두 번 클릭할 때 기록된 샘플 항목입니다.
explorer.exe (PID = 3268) identified
C:\Windows\system32\notepad.exe as Unrestricted using
path rule, Guid =
{191cd7fa-f240-4a17-8986-94d480a6c8ca}
이 로그 파일에는 응용 프로그램을 차단하도록 설정하여 사용 중인 소프트웨어 제한 정책이 검사할 실행 파일의 코드 부분이 모두 표시됩니다. 즉, 로그 파일의 각 항목에 대해 "허용 목록"에 포함할지 여부를 결정해야 합니다. 시스템을 작동하는 데 필요한 Windows®의 일부 이진 코드가 검사됩니다.
여기서 설명하는 로깅 기법은 해당 환경에서 소프트웨어 제한 정책이 적용될 응용 프로그램을 정확하게 파악할 수 있는 방법이지만 이 작업을 수행하는 유일한 방법은 아닙니다.
Microsoft® 응용 프로그램 호환성 도구 키트 5.0에 포함된 Inventory Collector를 사용하여 해당 환경에서 사용 중인 응용 프로그램의 인벤토리를 작성할 수 있습니다. 이 도구를 여러 가지 방법으로 사용하여 사용자 환경에 설치된 응용 프로그램을 검색하고 그 결과를 중앙 데이터베이스에 통합할 수 있습니다.
추가 규칙 작성
이제 해당 환경에서 실행을 허용할 응용 프로그램 목록을 작성했으므로 이러한 응용 프로그램을 실행하도록 허용하는 실제 규칙을 만들 준비가 되었습니다. 소프트웨어 제한 정책 기능에서는 두 가지 방법으로 정책을 식별합니다. 즉, 응용 프로그램의 암호화 속성을 기반으로 하는 방법(예: 해시)과 신뢰할 수 있는 응용 프로그램이 있는 신뢰할 수 있는 경로 또는 폴더를 정의하는 방법이 있습니다.
그림 2는 GPOE(gpedit.msc)의 소프트웨어 제한 정책 노드에서 응용 프로그램을 실행하도록 허용하는 규칙을 추가할 위치를 보여 줍니다. 사용자 환경에서 응용 프로그램을 정의하는 가장 쉬운 방법은 로깅 단계에서 발생하는 모든 이진 코드에 대해 하나의 해시 규칙을 만드는 것입니다.
그림 2** gpedit.msc를 사용하여 소프트웨어 제한 정책 작성 **(더 크게 보려면 이미지를 클릭하십시오.)
해시는 특정 비트 집합에 대해 반환되는 고유한 값이기 때문에 정책의 각 이진은 서로 다른 해시를 갖게 됩니다. 이 방법은 정책 내의 특정 이진만 실행을 허용하므로 매우 안전합니다.
물론 이 방법의 단점도 몇 가지 있습니다. 예를 들어, 사용자 환경에는 수천 개의 이진이 있을 수 있습니다. 소프트웨어 제한 정책 UI로 이러한 규칙을 모두 작성하는 것은 어려울 뿐만 아니라 규칙 수가 늘어나면 성능에 영향을 미칠 수 있습니다. 또한 사용자 환경에서 응용 프로그램이 업데이트될 때마다 하나 이상의 새 해시 규칙을 배포해야 합니다. 응용 프로그램이 업데이트될 때 이 대형 정책을 함께 업데이트하는 것은 엄청난 부담이 될 수 있습니다.
다행히 사용자 환경에서 소프트웨어 제한 정책을 사용하기 쉽도록 하는 규칙 식별 방법이 두 가지 더 있으므로 이러한 부담을 피할 수 있습니다. 암호화 보안 경로를 준수하여 특정 인증서로 서명된 모든 이진의 실행을 허용하는 규칙을 만들 수 있습니다.
응용 프로그램을 업데이트할 때 새 이진도 대개 이전과 동일한 인증서로 서명되기 때문에 이런 방법으로 정책 목록을 손쉽게 유지 관리할 수 있습니다. 그러나 이전 버전의 이진을 사용자 환경에서 실행하지 않으려는 경우에는 "제한됨" 해시 규칙을 추가하여 해당 파일의 실행 허용을 차단해야 합니다.
기본적으로 소프트웨어 제한 정책에 대해서는 인증서 규칙 평가를 사용하지 않습니다. 그렇게 해야 하는 두 가지 이유가 있습니다.
첫째, 소프트웨어 제한 정책의 인증서 규칙은 해당 시스템의 "신뢰할 수 있는 게시자" 저장소에 있는 항목에 따라 정의됩니다. "신뢰할 수 있는 게시자" 저장소는 소프트웨어 제한 정책의 규칙 외에 다른 용도로도 사용되기 때문에, 소프트웨어 제한 정책 기능에 이 저장소를 사용하는 것은 시간을 두고 더 고려해야 합니다.
둘째, 파일의 서명이 유효한지 여부를 결정하기 위해서는 해당 파일의 해시를 가져와서 서명 정보와 비교해야 합니다. 디스크에서 전체 파일을 읽어온 다음 처리하여 해시를 계산해야 하는 파일 해싱은 많은 비용이 소요되는 작업입니다.
인증서 규칙을 사용하려면 "소프트웨어 제한 정책" 노드로 이동하여 결과 창에서 "적용 개체"를 선택합니다. 그런 다음 해당 속성 대화 상자를 두 번 클릭하여 열고 "인증서 규칙 적용" 라디오 옵션을 선택합니다.
코드 식별에 흔히 사용되는 다른 방법으로는 로컬 시스템의 코드 경로를 사용하는 방법이 있습니다. 이것은 효율적이고 효과적인 기법이지만 한 가지 단점이 있습니다. 즉, 해당 폴더의 보안 설정이 제대로 설정되어 있는지 주의해서 확인해야 합니다.
사용자의 파일 기록을 허용하는 특정한 경로 규칙(예: 바탕 화면)을 추가하면 사용자들이 원하는 실행 파일을 해당 폴더에 넣고 무엇이든 실행할 수 있게 됩니다. 그러나 Administrators 그룹에 속하지 않는 사용자는 Program Files 또는 Windows 디렉터리의 항목을 수정할 수 없습니다. 즉, 모든 응용 프로그램이 Program Files 디렉터리에 있고 사용자가 Administrators 그룹에 속하지 않는 경우에는 매우 간단하고 효과적인 정책을 적용하기 위한 경로 규칙이 필요합니다.
경로 규칙은 몇 가지 기능으로 인해 일부 환경에 더 적합합니다. 와일드카드가 허용되며, 환경 변수를 사용하여 해당 환경 내에서 변경 가능한 규칙을 손쉽게 정의할 수 있습니다. 즉, 사용자에 따라 %systemdrive%가 c:\가 아닐 수도 있습니다.
성능과 유지 관리를 고려할 때 이것은 가장 문제가 적은 코드 식별 방법입니다. 경로 규칙은 분명 고려해야 할 방법이지만, 그에 따르는 보안 문제도 생각해야 합니다.
네트워크 영역 규칙
소프트웨어 제한 정책에는 현재 사용되지 않는 네트워크 영역 규칙이라는 규칙 유형도 있습니다. 이 규칙은 원래 식별 및 신뢰할 수 있는 소스의 실행 파일 코드는 실행을 허용한다는 생각으로 만들어졌습니다. 그러나 그렇게 하기는 매우 어려웠으며, 따라서 잘 되지도 않았습니다. 현재 소프트웨어 제한 정책의 진입점에 해당하는 대부분의 위치에서는 이 규칙 유형을 적용하지 않습니다.
대부분의 응용 프로그램이 %Program Files% 디렉터리에 설치되어 있고 특정 인증서로 서명된 나머지 실행 파일은 다른 곳에 설치되어 있다면 서로 다른 유형의 규칙을 사용할 수 있습니다. 해시 규칙 몇 개와 경로 규칙 두어 가지로 적당한 정책을 만들 수 있을 것입니다.
그림 3과 같이 규칙은 순서에 따라 처리된다는 것을 명심하십시오. 인증서 규칙이 가장 구체적이고, 그 다음에는 해시 규칙, 경로 규칙, 와일드카드가 있는 경로 규칙의 순서입니다. 따라서 해시 규칙 및 경로 규칙으로 식별되는 코드의 경우 해시 규칙의 보안 수준이 우선 적용됩니다.
그림 3** 규칙 처리 순서 **(더 크게 보려면 이미지를 클릭하십시오.)
정책 적용
소프트웨어 제한 정책 기능은 보안되는 시스템에서 폭넓게 활용됩니다. 코드 실행이 가능한 모든 위치에 소프트웨어 제한 정책을 적용하고 이 정책을 검사하여 실행 파일 코드의 실행이 허용되었는지 확인하는 것입니다.
여러 곳에서 소프트웨어 제한 정책을 검사할 수 있지만 가장 쉬운 진입점은 CreateProcess입니다. CreateProcess 도중에 정책을 검사하여 해당 응용 프로그램의 이진 실행을 허용할지 여부를 결정합니다. 정책 검사는 SaferIdentifyLevel API에서 수행하고 그 내용을 공개적으로 기록합니다. 일반적인 프로세스는 그림 4에 나와 있습니다. SaferIdentifyLevel에 대해 좀 더 자세히 살펴보겠습니다.
그림 4** SaferIdentifyLevel을 사용하여 이진 실행 여부 결정 **(더 크게 보려면 이미지를 클릭하십시오.)
소프트웨어 제한 정책이 적용되는 API 중 CreateProcess 다음으로 많이 사용되는 것은 ShellExecute입니다. ShellExecute는 사용자가 시작 메뉴에서 응용 프로그램을 클릭하거나 바탕 화면에서 두 번 클릭할 때 호출되는 API입니다.
다양한 파일 형식에서 ShellExecute를 호출할 수 있습니다. .txt 파일의 경우 파일에서 ShellExecute를 호출해도 기술적으로 해당 파일이 열리기는 하지만 실제로 실행되지는 않습니다. 그러므로 ShellExecute가 호출될 때 검사할 파일 형식을 제어할 수 있도록 소프트웨어 제한 정책에 실행 파일 형식 목록이 포함됩니다. 소프트웨어 제한 정책 UI에서 이 실행 파일 형식 목록을 사용자 지정할 수 있습니다.
CreateProcess 및 ShellExecute 외에 LoadLibrary와 스크립트 호스트도 중요한 통합 지점입니다. LoadLibrary가 실행 파일 코드를 검사하기에 중요한 위치인 것은 분명하지만 불행히도 몇 가지 특수한 제약 조건이 있습니다.
대부분의 응용 프로그램은 실행 파일 하나와 DLL 여러 개를 로드합니다. 그리고 보통 시스템에서는 많은 응용 프로그램을 실행합니다. 즉, LoadLibrary는 많은 정책을 검사해야 합니다. 코드 식별 정책에 따라서는 적용에 상당한 비용이 드는 진입점이 될 수 있습니다. 예를 들어, 시스템에 로드된 모든 DLL의 해시를 검사하려면 해당 이진을 해싱한 다음 이를 수천 개의 해시와 비교해야 합니다.
이 기능은 기본적으로 사용하지 않지만 수동으로 설정할 수도 있습니다. gpedit.msc에서 소프트웨어 제한 정책 노드로 이동하여 "적용"을 두 번 클릭한 다음 "모든 소프트웨어 파일" 라디오 단추를 선택하면 됩니다.
설명한 것처럼 소프트웨어 제한 정책은 시스템에 있는 대부분의 스크립트 호스트와 통합됩니다. 여기에는 cmd, VBScript, Cscript, JScript® 등이 포함됩니다. 다른 진입점과 마찬가지로 이러한 진입점에서도 소프트웨어 제한 정책 적용 API로 SaferIdentifyLevel을 주로 사용합니다.
SaferIdentifyLevel API는 해당하는 소프트웨어 제한 정책의 식별 정보를 조사하여 지정된 실행 파일의 실행을 허용할지 여부를 결정합니다. 이 API는 문서로 공개된 API입니다. 타사 스크립트 호스트 및 실행 파일 환경에서는 실행 파일 코드의 실행 허용 여부를 결정하는 소프트웨어 제한 정책을 통합할 때 이 API를 사용할 수 있고 또 사용해야 합니다.
표준 사용자로 실행
소프트웨어 제한 정책의 잘 알려지지 않은 기능으로, 특정 응용 프로그램을 시작할 때 그 권한을 필터링하는 기능이 있습니다. 이 기능은 Windows XP에서 도입되었으나 소프트웨어 제한 정책 UI에 사용하기 시작한 것은 Windows Vista부터입니다.
이 방법을 사용하면 Administrators 그룹의 구성원인 사용자도 표준 사용자로서 응용 프로그램을 실행할 수 있으므로 Windows Vista UAC의 전신인 셈입니다. 규칙을 만들고 "추가 규칙" UI에서 "보안 수준"을 "일반 사용자"로 설정한 경우에 이러한 상황이 벌어집니다.
UAC의 토큰 필터링 기능과 소프트웨어 제한 정책의 "일반 사용자" 규칙은 모두 CreateRestrictedToken API와 동일하게 동작하는 기본 API를 활용합니다. 그러나 두 기술의 전체 아키텍처에는 큰 차이가 있으며, UAC는 몇 가지 중요한 부분에서 소프트웨어 제한 정책과 다릅니다.
첫째, UAC를 사용하는 Windows Vista에서 모든 응용 프로그램은 Administrator 그룹에 속하는 사용자의 경우에도 기본적으로 Users 그룹의 구성원과 비슷한 보안 토큰으로 시작됩니다. 소프트웨어 제한 정책으로도 이러한 결과를 얻을 수 있지만, 응용 프로그램을 설치하는 등의 작업을 해야 하는 사용자는 자신의 실제 토큰인 Administrator 토큰으로 응용 프로그램을 시작할 수 없습니다. 기본 보안 컨텍스트의 변화와 더불어 사용자의 전체 관리자 토큰에 대한 액세스가 쉽다는 것이 UAC의 주된 장점입니다.
두 번째 차이점은 실행 파일의 경우 코드 작동에 필요한 권한 수준이 코드 자체에 표시된다는 점입니다. ISV(독립 소프트웨어 공급업체)와 개발자들은 자신의 코드에 필요한 사항을 알고 있으므로 이것은 중요한 차이점입니다. 예를 들어, 관리자 권한이 필요한 항목을 편집해야 하는 제어판 응용 프로그램이라면 매니페스트에 그러한 요구 사항을 지정할 수 있습니다. 따라서 ISV는 특정한 권한 수준을 부과하는 대신 그 수준을 변경할 수 있는 수단 없이도 해당 응용 프로그램에 필요한 권한을 지정할 수 있습니다.
"일반 사용자" 규칙을 완전히 이해할 때까지 당분간 이 규칙은 사용하지 마십시오. UAC는 Administrators 그룹의 데스크톱 사용자를 줄이는 데 유용한 기능이므로 엔터프라이즈 환경에서 UAC를 그대로 사용하는 것을 신중하게 고려하십시오.
현재 사용되는 소프트웨어 제한 정책
소프트웨어 제한 정책을 사용할 때는 여러 가지 유동적인 부분을 고려해야 합니다. 사실 생각과 달리 모르는 사이에 소프트웨어 제한 정책을 사용하고 있는 경우도 있습니다. 예를 들어, Windows Vista 시스템에서 자녀 보호 기능을 실행한다면 응용 프로그램 실행을 제한하는 소프트웨어 제한 정책을 사용하고 있는 것입니다.
Windows XP에 소프트웨어 제한 정책을 처음 도입했을 때 이것은 중요한 기술적 발전이었습니다. 그러나 현재 IT 전문가들이 주목하는 것은 응용 프로그램 잠금입니다.
Windows Vista의 소프트웨어 제한 정책 기능에는 아직 다듬어져야 할 몇 가지 단점이 있지만, 관리자들이 자신의 환경에서 실행 중인 프로그램을 제어할 수 있는 이 향상된 기능을 원하는 것은 분명합니다. 다행히 이 기술은 앞으로도 계속 발전할 것이며 IT 전문가들은 손쉽게 시스템을 관리하고 Microsoft Windows 환경의 운영 비용을 절감하게 될 것입니다.
핵심 소프트웨어 제한 정책
Windows를 키오스크 모드로 잠그는 정책을 만드는 것도 소프트웨어 제한 정책을 적용하는 한 가지 방법입니다. 사실 Microsoft에서는 이러한 키오스크를 만들 수 있도록 SteadyState™라는 도구 키트를 제작했습니다. 그러나 실행 가능한 응용 프로그램을 잠그는 기능만 필요하다면 이보다 간단한 방법이 있습니다.
Windows Vista에 로그온하는 데 필요한 응용 프로그램을 최소한으로 허용하려면 %windir%\system32에서 logonui.exe 및 userinit.exe를 실행하도록 허용하는 정책을 만듭니다. 또한 대부분의 사용자에게 다음과 같은 응용 프로그램의 실행을 허용해야 합니다.
dllhost.exe, rundll32.exe, control.exe (also under %windir%\system32)....
기본 Windows 셸을 원한다면 %windir%\explorer.exe를 추가할 수도 있습니다.
또는 Internet Explorer®와 같은 응용 프로그램으로 곧장 부팅되도록 할 수 있습니다. 이 경우 explorer.exe 대신 iexplore.exe를 지정해야 합니다.
이 핵심 정책의 또다른 특징은 사용자가 Administrators 그룹의 구성원이 아니어야 한다는 것입니다. 사용자가 정책을 우회하지 못하도록 하려면 이 점이 중요합니다. 그러나 사용자들은 매우 기본적인 응용 프로그램만 실행할 수 있고 Administrator 권한이 없기 때문에 응용 프로그램을 설치하거나 시스템을 유지 관리할 수는 없습니다.
따라서 해당하는 시스템에 대해 그러한 작업을 수행하기 위한 다른 방법이 필요합니다. Administrator 계정으로 로컬에서 로그온하여 이러한 시스템을 업데이트하고 유지 관리하려면 로컬 관리자를 제외한 모든 사용자에게 소프트웨어 제한 정책을 적용하는 라디오 단추를 선택해야 합니다. 또한 consent.exe 및 cmd.exe가 이 정책에 포함되어야 합니다. 그러면 Administrator가 Administrator 명령 프롬프트에서 모든 관리 옵션을 시작할 수 있게 됩니다.
UAC는 기본적으로 사용자의 보안 토큰 권한을 제한하여 해당 토큰이 Administrators 그룹에 속하지 않는 것처럼 보이게 합니다. Administrators에게 정책을 적용하지 않도록 위의 설정을 지정하더라도 사용자에게는 정책이 적용됩니다. Administrator가 실제로 완전한 관리자 권한을 가지도록 하고 소프트웨어 제한 정책이 적용되지 않게 하려면 UAC 권한 상승 과정을 마쳐야 합니다.
Chris CorioChris Corio는 Microsoft의 Windows 보안 팀에서 5년 이상 근무하면서 Windows 보안을 위한 응용 프로그램 보안 기술 및 관리 기술을 주로 담당해 왔습니다. 문의 사항이 있으면 winsecurity@chriscorio.com으로 연락하십시오.
Durga Prasad SayanaDurga Prasad Sayana는 Windows 핵심 보안 팀에서 소프트웨어 설계 엔지니어 겸 테스트를 담당하고 있습니다. 주로 보안 기술 및 소프트웨어 테스트 업무를 처리합니다. 문의 사항이 있으면 durgas@microsoft.com으로 연락하십시오.
© 2008 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..