Windows 보안- 접근제어 모델

2015.06.12황인균

2황인균

목차

일반 접근제어 개념 접근제어 단계 구성요소 모델 비교

Windows 접근 제어 개요 권한 용어 기본 모델 정리 보호 객체 구성 요소 권한 결정 추가 보안 요구 보안 레벨 도입

Windows 접근 제어 아키텍처 이해 순서 Access Token, 프로세스 Access Token ACL, ACE 객체의 ACL 결정 접근제어 확장 , MIC MIC 레벨 Object IL, User IL Process IL, Process IL 결정 Integrity Policies 접근 권한 결정 Low IL 위치

Windows 접근 제어 구현 UAC > 요구사항 UAC > 2 개의 Access Token UAC > Access Token 구성 UAC > Access Token 선택 UAC > 권한 상승 요청 UAC > Elevation 승인 창 UAC > 승인 창 아이콘 UAC > 코드 사인 UAC Virtualization > Windows 환경 변화 UAC Virtualization > 가상화 활성화 조건 UAC Virtualization > 파일 UAC Virtualization > 레지스트리

레퍼런스 부록

Access Token 생성 프로세스 생성 Impersonation SID 정의 UAC 관련 그룹정책

3황인균

일반 접근제어 개념 > 접근 제어 단계

1 단계 Identification( 식별 ), ID

2 단계 Authentication( 인증 ), PWD

3 단계 Access Control Mechanism( 권한 접근 유무 판별 )

4 단계 Authorization( 접근 권한 부여 / 인가 )

5 단계 Audit( 감사 )

예방 통제

탐지 통제

4황인균

일반 접근 제어 개념 > 구성요소

주체의 비 인가된 동작들의 위협에 대해 자원을 보호하는 기능

구성요소 설명 WINDOWS주체 (SUBJECT) • 객체 접근자 , 즉 보안 객체에 접근을

요청하는 쪽• 자신의 권한 정보 (rights, privileges) 를

소유하고 있다 .

사용자 , 그룹 , 프로세스 등

객체 (OBJECT) • 접근 대상 자원 , 즉 주체의 접근 요청을 허용하는 쪽

• 허용 정보 (permissions) 를 소유하고 있다

파일 , 폴더 , 레지스트리 , 프로세스 , 윈도우 서비스 등

참조 모니터(REFERENCE MONITOR)

• 주체와 객체 사이에서 비 인가된 접속이나 불법적 변조 막기 위한 주체의 접근 권한을 통제하는 장치

SECUTIRY SUBSYSTEM

보안 정책 • 어떻게 적용할 것인가에 대한 정책 또는 설정을 정의한다 .

5황인균

일반 접근 제어 개념 > 구성 요소 ( 계속 )

주체 객체

참조 모니터

권한정보 허용정보

프로세스

보안 정책

6황인균

일반 접근 제어 > 모델 비교

접근제어 모델 설명 WINDOWS임의적 접근 제어(Discretionary Access Control)

• 객체 소유자의 재량 (discretion) 에 의해 객체의 ACL 속성을 변경해서 주체별 접근을 허용(permit) 한다 .

1) 폴더에 대한 접근 계정 추가

강제적 접근 제어(Mandatory Access Control )

• DAC 모델로 제어하기 힘든 제어 시나리오를 보완 .

• 시스템에 의해서 주체의 권한 레벨과 객체의 허용 레벨을 정의

• 권한 레벨이 자신보다 낮은 객체에만 주체의 접근을 허용

Windows Integrity Level

역할 기반 접근 통제(Role Based Access Control)

• 역할을 정의해서 역할별로 객체에 대한 접근 권한(privileges) 을 부여

1) 사용자 계정 및 그룹 계정을 정의해서 권한 부여

2) UAC( User Access Control )

모델 비교 DAC MAC RBAC접근 권한 부여자 객체 소유자 시스템 중앙 관리

접근 여부 결정 기준 ID 보안 라벨 (Security Label) Role정책 유연 경직 유연

장점 유연 , 구현 용이 안전 / 중앙 집중 관리트로이 목마에 안전

관리 용이

단점 트로이 목마에 취약ID 도용시 통제 방법 없음

구현 , 운영이 어려움높은 비용성능 문제

7황인균

Windows 접근제어 개요 > 권한 용어

한글로는 주로 “권한”으로 번역되는 개념은 영어에서는 3 가지로 표현된다 : Rights, Privileges, Permissions.

구분 설명 예

Rights • Account Rights• 누가 (who), 어떻게 (How) 시스템에 로그온 할 수

있는지 여부를 나타내는 권한• SRM 에 할당되지도 않고 , 토큰에 저장되지도 않는다 .

• 예 ) SeRemoteInteractiveLogonRight : Remote Desktop 을 통해서 원격에 로그온할 수 있는

• 로컬 시스템 로그온 여부• 네트워크를 통한 로그온 여부• 터미널 서비스를 통한 로그온 여부• 서비스의 로그온 계정으로 사용가능 여부• 배치 job 의 로그온 계정으로 사용가능 여부• Mark Russinovichi, p.540

Privileges • 주체 (“Subject”) 가 무엇을 할 수 있는지에 대해 정의함• 접근 주체 ( 접근 요청하는 쪽 ) 에 설정• 주체의 Access Token 에 포함됨• 특정 객체와 관련된 것이 아니라 시스템 차원의 능력을

나타낸다 .

• 예 ) SeBackupPrivilege : 객체에 접근 ( 읽기 ) 시 접근 제어를 통과할 수 있는 권한

• 34 user privilegesNotorious Nine privileges + 25 user privileges

• 사용자 계정 토큰은 Notorious Nine privileges 는 갖지 못함 .

• Privilege 표현방법- SesomethingPrivilege

• Mark Minasi, p.68• Mark Minasi, p.540

Permissions • 접근 객체 ( 접근 요청을 받는 쪽 ) 가 가지고 있는 접근 허용 정보

• 접근 객체의 Security Descriptor 에 포함됨• Permissions 을 때로는 access rights 로 표현하기도

한다 .

• allowed, denied, or audited.

Rights, Privileges vs Permissions 개념 -Windows

※ 일반 개념• Rights : 하늘 또는 법 같은 주위의 시스템이 부여하는 권리 . • Privileges : 특정 그룹 , 사람에게만 주어지는 권한 . 특권• http://www.voicesofliberty.com/article/how-to-tell-the-difference-between-a-right-and-a-privilege/

8황인균

Windows 접근 제어 개요 > 기본 모델 정리

UAC UACVirtualizationMIC

DEP UIPI

SmartScreen Filter

Windows Defender

기본 제어

확장 제어

Windows 확장된 보안 제어 기능은 “기본 보안 제어” 기능을 바탕으로 하고 있다 . 확장 보안은 보안 레이어를 중복 , 추가하는 개념 (defense-in-depth ) 이다 .

DAC

IE PM(Protected Mode)IE Enhanced PM

9황인균

Windows 접근 제어 개요 > 보호 객체 보호 객체 (Protected Object )

Windows 에서 보호되는 객체 Windows 객체 관리자가 관리하는 모든 것

약간 익숙한 것 – files, folders, processes, threads, jobs, registry keys, events, access tokens, 기타 – devices, mailslots, pipes(named and anonymous), mutexes, semaphores, shared

memory sections, I/O completion ports, LPC ports, waitable timers, volumes, windows stations, desktops, network shares, services, printers, Active Directory objects and so on.

어플리케이션

( 프로세스 ) 보호 객체

시스템 환경

접근

Windows 접근 제어

접근 권한 정보 접근 허용 정보

접근 가능 판단

Windows 보안 설정

10황인균

Windows 접근 제어 개요 > 구성 요소

Security Subsystem( 보안 참조 모니터 )

프로세스

Access Token

Object Manager

Securable Object

Security Descriptor

③ 접근 권한 문의① 객체 접근 ( 오픈 , 읽기 , 쓰기 등 )사용자

① 객체에 접근 ② 허용 정보 요청

④ 접근

Access Token:• “ 사용자 프로파일 정보” ( 사용자 정보 , 권한 정보 등 ) 포함 .

Security Descriptor• ACL, ACE 포함 - 보안 객체에 설정된 접근 허용 정보 포함 (Permissions)

“ 사용자”가 객체에 접근 권한이 있느냐 ?” = “ 프로세스”가 객체에 접근 권한이 있느냐 ?

SRM(Security Reference Monitor)• SRM 은 접근 제어를 입력받아 최종적으로 접근 허용할지에 대한 Yes , No 를 반환한다 .

11황인균

Windows 접근 제어 구현 > 권한 결정

Security Subsystem( 보안 참조 모니터 )

Thread 의 Security Identity( 주체의 Access Token 정보 )

객체의 접근허용 정보( 객체의 Security Descriptor 정보 )

보안 정책

접근허용Yes 또는 No

Security Subsystem( Security Reference Monitor ) 보안 주체가 가지고 있는 권한 정보와 보안 객체가 가지고 있는 허용 정보를 비교해서 접근 가능 여부를 평가한다 . 접근 가능 여부를 결정할때 , UAC, MIC 두 모델 ( 뒤에서 설명 ) 을 모두 고려한다 .

- 주체가 가지고 있는 Access Token 의 Privilege, - 객체가 가지고 있는 Security Descriptor 의 Permissions 정보 - 양쪽에서 가지고 있는 IL 정보가 사용된다 .

12황인균

Windows 접근 제어 구현 > 추가 보안 요구

인터넷에서 온 파일의 실행 프로세스

사용자Access Token

Securable Object

Security Descriptor

사용자 계정

?

DAC 접근 제어의 부족한 점 실행 파일이 예를 들어 , 인터넷에서 내려온 악성 코드라면 ? 사용자 계정이 권한이 있다고 해서 악성 코드 프로그램을 실행해서는 안된다 . Access Token, ACL, ACE(Security Descriptor 에 포함 ) 기반의 DAC 모델은 이 접근을 제어할

수 없다 .

13황인균

Windows 접근 제어 개요 > 보안 레벨 도입

보안 레벨 개념 도입

Mandatory Integrity Control( Windows 의 MAC 접근제어 ) 프로그램의 프로세스와 객체들 ( 예 , 그 프로그램이 생성한 파일 ) 의 “신뢰도 ( Integrity Level)” 기반으로

Windows 객체를 보호하는 메커니즘 예 ) 실행 파일 ( 악성코드 ) 의 프로세스에 할당된 보안 레벨이 객체의 허용된 보안 레벨보다 낮으면 접근할

수 없다 .

인터넷에서 온 파일의 실행 프로세스

사용자Access Token

Securable Object

Security Descriptor!

보안 레벨허용 보안 레벨

사용자 계정

프로세스의 보안 레벨 > 보안 객체의 허용 레벨 접근 허용

14황인균

Windows 접근 제어 구현 > 아키텍처 이해 순서

Windows 보안 객체 이해

접근 제어 알고리즘 이해

Access Token, Security Descriptor(ACL, ACE ), 보안 레벨 (MIC ) 등

객체 접근 권한 결정 알고리즘

15황인균

Windows 접근 제어 구현 > Access To-ken

Access Token

1) 주체의 SID(*)

2) 소속된 그룹 SID 목록

3) 주체 권한 (Privileges) 목록

contains

4) Integrity Policy

Access Token 정보

보호 객체에 접근하는 주체의 프로파일 정보를 가지고 있다 .

• 누가 ?

• 무엇을 할 수 있는가 ?

• 보안 레벨을 어떻게 적용할 것인가 ?( 뒤에서 설명 )

※ SID(Security Identifier) – 부록 ) 용어 참조

16황인균

Windows 접근 제어 구현 > 프로세스 Access Token

Process Access Token

프로세스

Access Token #1

Securable Object

Security Descriptor

1) 쓰레드

2) 쓰레드 Securable Object

Impersonation Access Token #2

Security Descriptor

※ Access Token #1 Primary Access Token

17황인균

Windows 접근 제어 구현 > ACL, ACE

Security Descriptor

ACE

SID 정보

Permission 정보

ACLcontains

IL 정보

contains

DACL DACE

SACL SACE

( Discretionary Permission 정보 포함 )

(Mandatory label 를 나타내는 특별한 ACE )

contains

Securable Object

ACL

Security Descriptor ACL, ACE

ACE 타입

DACE • access allowed ACE, access denied ACE, allowed ob-ject ACE( AD 용 ), denied object ACE( AD 용 ), allowed callback ACE , denied callback ACE, allowed object callback ACE , denied-object callback ACE, Conditional ACE, claims ACE

SACE • system audit ACE, system audit-object ACEs • 윈도우 탐색기의 GUI 를 통해서 볼 수 없다 .

※ ACL, ACE : 누가 해당 객체에 접근할 수 있는지에 대한 허용 정보 ( access permissions, IL 정보 ) 를 가지고 있다 .

18황인균

Windows 접근 제어 구현 > ACL, ACE( 계속 ) Security Descriptor

Security Descriptor 는 ACL 을 가지고 있다 . ACL 은 ACE 목록을 가지고 있다 . ACL( Access Control List )

ACL 은 zero or more ACE 를 갖는다 . ACL 종류

• DACL( Discretionary Access Control List) – DACE 목록을 포함• SACL( System Access Control List ) – SACE 목록을 포함

ACL - http://clintboessen.blogspot.kr/2011/04/whats-difference-between-acl-ace-dacl.html

ACE(Access Control Entity )• ACE 종류

• DACE – Discretionary permission 정보 포함 . SID, Permissions 정보• SACE – 보안 레벨 (Integrity Level, MIC 에서 설명 ) 정보 포함 . 즉 Mandatory Permission 정보 포함 .

• ACE - https://msdn.microsoft.com/en-us/library/windows/desktop/aa374868(v=vs.85).aspx

파일 객체 Security Descriptor

Allow USER#1Read Data

Allow TEAM#1Read DataWrite Data

Allow Everyone

File Execute

DACL

ACE ACE ACE

19황인균

Windows 접근 제어 구현 > 객체의 ACL 결정

DACL 결정

생성 요청자가 제공한 Security Descriptor

의 ACEs

컨테이너 (Directory) 객체의 Security

Descriptor 의 ACES

Inheritable ACEs

최종 ACEs

컨테이너 (Directory) 객체의 Security

Descriptor 의 ACES

Inheritable ACEs

최종 ACEs

생성 요청자가 제공한 Security Descriptor

의 ACEs

X

컨테이너 (Directory) 객체의 Security

Descriptor 의 ACES

Inheritable ACEs

최종 ACEs

생성 요청자가 제공한 Security Descriptor 의

ACEs

XX

생성 요청자의 디폴트 ACL

1)3)

2)

컨테이너 (Directory) 객체의 Security

Descriptor 의 ACES

Inheritable ACEs

No DACL

생성 요청자가 제공한 Security Descriptor 의

ACEs

XX

생성 요청자의 디폴트 ACL

4)

X

Allow everyone full access to the object SACL 결정

SACL 결정도 위와 거의 유사하다 .Mark Russinovichi p.527

20황인균

Windows 접근 제어 구현 > 접근제어 확장 , MIC

MIC ACL, ACE 와 더불어 객체 접근을 제어하는 확장된 메커니즘 MIC 의 중요 구성 요소 = IL(Integrity Level ) + Integrity Polices

Integrity Level

Integrity Policies

구성요소

Windows 는 보안 레벨 (Integrity Level) 을 정의하고 객체의 “신뢰도”를 나타내는 수단으로 사용• IL 을 이용해서 , “ 신뢰도가 낮은 녀석이 신뢰도가 높은 녀석에게 접근 , 이용할 수 없음”과 같은 정책을 정의할 수 있다 .

Integrity policies 는 객체에 대한 접근을 제어한다 . 그러나 정보의 흐름 ( the flow of information) 을 제한하는데 사용되지는 않는다 . 정보의 흐름을 막는 것은 Windows 의 Integrity 메커니즘의 목표가 아니다 .( 정보의 흐름을 막는 것은 객체에 대한 읽기 , 쓰기 에 대한 allow, deny 를 이용한다 )

IL 을 이용하면 process isolation 에 사용할 수 있다 . • “ 낮은 IL 을 갖는 주체는 높은 IL 을 갖는 프로세스를 접근할 수 없다 .“

프로세스뿐만 아니라 , 사용자 , 보안 객체도 각각의 IL 을 갖는다 . 동일한 사용자가 시작하는 프로세스라 하더라도 인터넷으로부터 와서 IL 이 낮은 프로세스는 IL 이 높은 프로세스나 객체에 접근할

수 없다 .

21황인균

Windows 접근 제어 구현 > MIC 레벨

MIC IL( Integrity Levels) Integrity Level = Mandatory Level ≒ IE 보안 옵션의 “보안 수준 (Security Level)” 과는 다름

Mandatory Label Integrity level, integrity policies 을 가지고 있다 . mandatory label ACE 로 표현된다 . 객체가 생성될때 Windows 는 Mandatory Label 을 생성해서 객체의 Security Descriptor 에 할당한다 .

MIC IL 정의각 보안 레벨은 고유한 SID 를 갖는다 .

이름 ( 보안 레벨 )

SID 용도

Untrusted(0) S-1-16-0 • Anonymous 으로 로그온한 계정에서 갖는 보안 레벨• 이 계정으로 시작된 프로세스• 대부분의 쓰기 접근 차단 .

Low(1) S-1-16-4096 • Protected Mode 의 IE 프로세스 (PMIE) 에서 사용하는 보안 레벨 .• PMIE 에서 Temporary Internet Files 폴더로 자동 다운받는 객체들• 대부분 보안 객체에 쓰기 접근 차단

Medium(2) S-1-16-8192 • UAC on 된 환경에서 로그온한 일반 사용자가 갖는 레벨• Windows 의 시스템 객체들은 대부분 보안 라벨이 없는데 , 이 경우 Medium 으로

간주한다 .notepad.exe 에도 보안 레벨이 없다

High(3) S-1-16-12288 • UAC on 된 환경에서 권상 상승된 계정이 갖는 레벨• 이 계정으로 시작한 프로세스 으로 시작한 프로세스가 갖는 레벨

System(4) S-1-16-16384 • 시스템 서비스• 시스템 프로세스Mark Minasi, P.140, Mark Russinovich, p.680

22황인균

Windows 접근 제어 구현 > Object IL, User IL

Object, Process, User 의 IL 결정 Object 의 IL 을 SACE 에 저장되지만 , Process, User 의 경우의 IL 은 “계산”된다 .

Object 의 IL 저장 구조 SACE(System Access Control Entry) : Mandatory label 를 나타내는 특별한 ACE SACE 는 SACL(System Access Control List) 목록에 있음 ( Minasi, P.141) 일반 사용자가 생성하는 파일은 medium, 권한 상승된 관리자 계정으로 생성하는 파일은 high 레벨을 갖는다 .

사용자의 IL 결정 ( 계산 ) 사용자가 로그온을 할때 Windows 는 해당 사용자의 IL 을 계산해서 access token 에 할당한다 . 소속된 사용자 계정의 그룹은 상관없다 . 중요한 것은 사용자가 갖는 privilege 이다 .• User integrity levels depend on solely on privileges• 사용자 계정이 Notorious Nine privileges 을 가지면 , 로그온 시 high IL 을 갖고 , 그렇지 않으면 medium 을 갖는다 . ( Mi-

nasi, P.152)

Process 의 IL( 계산 ) 다음 슬라이드에서 계속

SID in access token Assigned IL SID in access token Assigned ILLocalSystem System Network Configuration Opera-

torsHigh

LocalService System Cryptographic Operators HighNetworkService System Authenticated Users MediumAdministrators High Everyone (World) LowBackup Operators High Anonymous Untrustedhttps://msdn.microsoft.com/en-us/library/bb625963.aspx

23황인균

Windows 접근 제어 구현 > Process IL 프로세스 IL( Integrity Level )

사용자계정

실행 파일

프로세스

사용자 IL : 프로세스를 시작하는 주체 ( 사용자 등 ) 가 가지고 있는 토큰에는 IL 이 포함되어 있다 . 실행 파일 IL : 실행 파일 (exe) 은 보안 객체로서 IL 을 가지고 있다 .

이런 상황에서 프로세스의 최종 IL 은 어떻게 결정될까 ?

Windows 는 모든 프로세스와 쓰레드에 access token 을 할당한다 . 프로세스의 primary access token 에는 프로세스의 IL 이 포함된다 .

동일한 사용자에 의해서 실행되는 어플리케이션의 프로세스는 사용자와 동일한 Primary Access Token 을 할당받는다 . 그러나 사용자 계정의 IL 을 그대로 프로세스의 IL 로 할당하지 않는다 .Access

Token IL Access

Token

ACL, ACEIL

IL

?

※ 참고 – “사용자가 파일을 생성하다”

그림에서는 “사용자 계정”으로 표현했지만 , 정확히는 “프로세스”이다 . 예를 들어 파일 탐색기에서 “사용자가 파일을 생성”한다는 것은 “ explorer.exe 가 파일을 생성”하는 것이다 . Explorer.exe 에는 로그온시에 생성된 사용자 토큰이 첨부되어 있다 . “ 부록 )Access Token 생성”을 참조하면 한다 .

24황인균

Windows 접근 제어 구현 > Process IL 결정

프로세스 IL 결정 일반 규칙

• 모든 객체는 생성하는 프로세스 ( 또는 쓰레드 ) 가 가지고 있는 mandatory label 을 상속받는다 . 그러나 보안 환경 , 예를 들면 UAC 의 ON/OFF 에 따라서 달라질 수 있다 .

프로세스 IL 변경

특별한 권한이 있는 사용자는 파일 같은 객체의 IL 을 변경할 수 있다 . 프로세스가 자식 프로세스를 생성할 때 , IL 을 지정할 수 있다 .

지정하지 않으면 부모 사용자 토큰에 있는 IL 을 그대로 상속받는다 .( Mark Minasi, 147 )

구분 프로세스 IL 비고

관리자 계정으로 프로세스를 실행하는 경우

• High IL 을 설정한다 . • UAC 를 통해서 사용자 승인을 받은 경우도 High 레벨을

갖는다 .일반 사용자 계정으로 프로세스를 실행하는 경우

• 프로세스의 경우 , 사용자 토큰의 IL(medium) 과 exe 파일의 IL, 둘 중에서 더 낮은 레벨로 설정한다 .

• 사용자 토큰의 IL 보다 낮은 레벨의 프로세스를 생성할 수 있다 . 하지만 높은 레벨의 프로세스는 UAC 의 사용자 승인을 거쳐야 한다 .

일반 사용자 계정으로 생성하는 객체( 파일이나 레지스트리 키 ) 는 기본적으로 medium 레벨이 부여된다 .

Mark Minasi, p.154

25황인균

Windows 접근 제어 구현 > Integrity Policies Integrity Policies

주체의 다른 수준의 IL 을 갖는 객체에 대한 접근 타입 ( 읽기 , 쓰기 , 실행 등 ) 을 결정하는데 사용하는 정책을 정의하고 있다 . 주체의 보안 레벨과 객체의 보안 레벨이 다른 경우 “어떻게 적용할지”에 대한 정책 Mandatory Access Token policies, Mandatory Label policies

Mandatory Access Token Policies

Mandatory Policies 가 어떻게 주체에 적용될지를 결정하는 정책 Access token 에 설정됨

정책 설명

TOKEN_MANDATORY_NO_WRITE_UP • 모든 Access Token 에 적용되는 기본 정책• 보다 높은 IL 의 객체에는 쓰기 접근을 제한한다 .

TOKEN_MANDATORY_NEW_PROCESS_MIN

• 기본 정책으로 활성화• 프로세스의 실행 파일이 갖는 IL 과 프로세스를 시작하는 부모 프로세스의

IL 을 비교해서 더 낮은 IL 을 생성되는 자식 프로세스에 부여한다 .

https://msdn.microsoft.com/en-us/library/bb625963.aspxMark Russinovichi, p.509

26황인균

Windows 접근 제어 구현 > Integrity Policies( 계속 ) Mandatory Label Policies

객체의 mandatory label ACE 에 IL 과 함께 저장됨 Mark Russinovichi, p.505 낮은 IL 을 갖는 주체가 객체에 접근해 올 때 어떻게 접근을 제한할 것인가를 정의하고 있다 .

정책 디폴트 적용 객체 설명

No_Write_Up상위 레벨 쓰기 금지 정책

• 모든 객체에 암묵적으로 존재 • 낮은 IL 프로세스는 자신보다 높은 IL 의 객체에 쓰기 접근을 제한한다 .• 높은 무결성을 가진 데이터의 오염을 방지하기 위함 .

No-Read-Up상위 레벨 읽기 금지 정책

• 프로세스 객체에만 존재 • 낮은 IL 프로세스는 높은 IL 의 객체에 읽기 접근을 제한한다 .• 정보의 기밀성을 보장하고자 하는 정책• 프로세스 객체에서만 사용됨

No_Execute_Up상위 레벨 실행 금지 정책

• COM 클래스를 구현하는 바이너리에만 존재

• 보다 낮은 IL 을 갖는 프로세스의 COM 객체에서 실행 접근을 제한한다 .

27황인균

Windows 접근 제어 구현 > 접근 권한 결정

접근 권한 체크 순서

Mandatory integrity check(IL, Policies 고려 )

Discretionary access check( 객체에 대한 ACE 고려 )

Integrity check 작업 속도 > access check 작업 속도따라서 , 체크 순서는 이렇게 . ( Mark Russinovichi, p.528 )

Integrity check 와 access check 를 모두 통과해야 겍체에 접근할 수 있다 .

28황인균

Windows 접근 제어 구현 > 접근 권한 결정 ( 계속 )접근 권한 결정

High Processes

Medium Processes

Low Processes

High Objects

Medium Objects

Low Object

Processes Objects

Medium IL Processes

Low IL Processes

읽기

쓰기

Mark Russinovich, p.529

구분 설명

정책 • 모든 객체 : TOKEN_MANDATORY_NO-WRITE-UP, TOKEN_MANDATORY_NEW-PROCESS-MIN

• 프로세스 추가 정책 - No_Read_Up객체 쓰기 • DACL 이 허용되면 , 프로세스는 자신보다 낮거나 같은 IL 을 갖는 객체 (Object) 에 쓰기 접근이 허용된다 .

객체 읽기 • DACL 이 허용되면 , 프로세스는 자신보다 높은 IL 을 갖는 객체 (Objects) 에도 읽기 접근이 허용된다 .Windows 는 주체가 어떤 레벨의 데이터도 “읽기”는 가능하도록 하고 있다 . Protected Mode 의 IE 에서 실행되는 악성코드 ( 낮은 IL) 가 외부의 설정이나 파일에 쓸 수는 없지만 , 읽을 수는 있다 .

• Process, Threads 는 기본적으로 “ No-Read-Up” 정책이 포함되어 있어서 보다 높은 레벨의 프로세스에 읽기를 할 수 없다 .

29황인균

Windows 접근 제어 구현 > Low IL 위치 Default Low Integrity Folders

폴더나 레지스트리 키도 Object 로서 보안 레벨을 갖는다 . Protected Mode 의 낮은 IL 의 IE 프로세스에서 접근할 수 있는 파일 시스템이나 레지스트리 위치 (Mark Minasi, p.151 )

\Users\username\AppData\LocalLow\Users\username\AppData\Local\Temp\Low\Users\username\AppData\Local\Microsoft\Temporary Internet Files\Low 하위의 몇 개 경로( 시스템 파일이어서 기본적으로 보여지지 않는다 )

Writeable locations at low integrity ( https://msdn.microsoft.com/en-us/library/bb625957.aspx ) Table 10 shows these writeable locations.

Location Writeable areaRegistry Low-integrity processes can write to and create subkeys under HKEY_CURRENT_USER\Software\App-

DataLowFile system Low-integrity processes can write and create subfolders under %USER PROFILE%\AppData\LocalLow

30황인균

Windows 접근 제어 구현 > UAC > 요구사항

보안 요구사항 최소 권한 정책 : NEED-TO-KNOW 정책에 기반해서 , 주체들에게 필요한 최소한의 권한만 부여 Windows 의 보호된 자원에 영향을 주려는 작업을 하려면 , “ 사용자의 승인＂을 얻어야 한다 . Windows 시스템에서 수행하는 대부분의 작업은 “일반 계정＂으로 할 수 있다 . 필요할 때만 사용자의 승인을 받아서 관리자

권한을 획득하면 된다 . 이런 Warning 시스템은 사용자의 실수를 줄여 “나쁜 프로그램”의 설치나 실행을 막을 수 있는 기회를 준다 .

이슈 사용자 계정에서 관리자 계정으로 smooth 하게 전환하는 방법을 어떻게 구현할 것인가 ?

UAC 등장

31황인균

Windows 접근 제어 구현 > UAC > 2 개의 Access Token

UAC on Two LSA Logon Sessioncreate Standard User Session

Administrator Session

2 개의 토큰

UAC on 된 시스템에 관리자 계정으로 로그온을 하면 두 개의 세션이 생성된다 . 각 세션에는 사용자의 Access Token 이 포함되어 있다 .

Standard User Token( Filtered token)

Administrator Token(Full token)

contains

contains

https://technet.microsoft.com/en-us/library/dd835561(v=ws.10).aspx

32황인균

Windows 접근 제어 구현 > UAC > Access Token 구성

Token 구성요소 설명

일반 사용자용 To-ken

SID • User Token 의 SID 는 Administrator Token 의 SID 와 동일

Privileges • Notorious Nine “scary” 권한은 읽게 된다 . - create a token, act as a part of the OS, take ownership of objects, impersonate a client, modify an object label 등 ( Mark Minasi p.74)

GROUP • Fearsome Four 그룹을 제외한 나머지 모든 권한그룹의 멤버쉽을 유지한다 .BUILTIN\Administrators, BUILTIN\Backup Operators, BUILTIN\Power Users, BUILTIN\Network Configuration Operators정확히 말하면 멤버에서 제거되는 것은 아니다 . Mark Minasi p.74, 76

• Domain Administrators 등 다른 그룹의 멤버쉽은 잃지 않는다 .IL(Integrity Level)

• Medium (S-1-16-8192)

Integrity Policy • TOKEN_MANDATORY_NO_WRITE_UP• TOKEN_MANDATORY_NEW_PROCESS_MIN

관리자용 Token…IL • High ( S-1-16-12288)

Access Token 요소

33황인균

Windows 접근 제어 구현 > UAC > Access Token 선택 Access Token 선택

2 개의 토큰이 생성되면 , 프로세스에 어떤 토큰을 할당할지에 대한 선택의 문제가 있다 .

프로그램 (exe)시작

Standard User Token

Administrator Token

사용자

WindowsWhich to use?

프로세스

Access token 할당

관리자 토큰 선택

기본적으로는 사용자 토큰을 사용한다 . 관리자 권한의 토큰을 사용해야 한다면 “권한 상승 요청”을 해야 한다 .

34황인균

Windows 접근 제어 구현 > UAC > 권한 상승 요청

Access Token 선택 프로그램이 관리자 권한의 토큰을 사용해야 한다면 UAC 는 “권한 승인 요청”을 해야 하고 , 사용자가 승인을

해야 한다 . 그럼 , 권한 상승 요청 방법은 ?

※ 권한 상승 요청 방법 관리자용 토큰 요청 ( 사용자가 직접 ) 관리자용 토큰 요청 ( 어플리케이션 configuration) 관리자용 토큰 필요성 자동 인식

사용자 권한 상승 승인

관리자 토큰 선택

프로세스 토큰 할당

사용자 토큰 사용

프로그램 시작

로그온 ( UAC ON)

권한 상승 요청 ?

사용자 토큰 선택

35황인균

Windows 접근 제어 구현 > UAC > 권한 상승 요청 (II) Elevation Request

Mark Minasi, p. 74~81 UAC 가 관리자용 토큰을 선택하기 위해서는 권한 상승 요청이 있어야 한다 . 권한 상승 요청을 하는 방법에는 아래 3 가지가 있다 .

권한 상승 요청 방법 설명

사용자가 Elevation 요청하는 방법

• exe 오른쪽 클릭해서 “ Run as administrator” 선택 승인창 오픈• exe 를 더블클릭해서 바로 승인창 띄우기

- Exe 오른쪽 클릭 > 속성 선택- 바로가기 오른쪽 클릭 > 속성 선택

어플리케이션 Manifest 이용

• 개발자가 Elevation 요청하는 방법• 어플리케이션의 “ manifest” 파일 이용 ,

- <REQEUSTEDEXECUTIONLEVEL level=“asInvoker” uiAccess=“false” />- level값 : asInvoker, higestAvailable, requireAdministrator- uiAccess : 승인 창 이외의 데스크톱 배경은 선택할 수 없게 한다 ( 기본값 , false). Mark Minasi, p.91, 108

• Manifest 파일을 exe 파일안에 임베딩시킬 수도 있다 . 이 경우

Windows-Heuristics • Windows 가 스스로 Elevation 요청을 인식할 수 있는 방법• 인스톨 파일인 경우

- 프로그램을 실행했을때 다른 프로그램을 설치하는 설치 프로그램이라고 판단되는 경우 Windows 는 elevation 을 요청한다 . - Wyse, Installshield 로 제작한 프로그램- “install”, “setu,”, “update” 등이 파일 이름에 있는 경우 인스톨 파일로 추정 등

• “Program Compatibility Assistant” • “Application Compatibility Database”

Elevation 을 요청하면 “승인 창” ( 또는 경고 창 ) 이 뜬다 .

36황인균

Windows 접근 제어 구현 > UAC > Elevation 승인 창

사용자 계정에 의한 권한 상승 요청을 OTS elevation 요청 ( Over The Shoulder ) 으로 표현하기도 한다 . 관리자 계정에 의한 권한 상승 요청을 AAM elevation 요청 ( Admin Approval Mode ) 이라고 표현하기도 한다 .

주로 관리자 계정으로 로그온을 할 것으로 예상되며 , 따라서 “ Approval 창”을 주로 보게 될 것이다 . 그룹정책을 통해서 , AAA 관리자도 Credentials 입력 창을 보여주는 등 그 거동을 변경할 수 있다 ( “UAC 그룹 정책” 참조 )

Elevation 승인 창

사용자에게 보여지는 Elevation 승인 창은 로그온 한 계정에 따라서 달라질 수 있다 .

UAC on, 사용자 계정으로 로그온 한 경우 Account Credentials 입력 창 출력

UAC on, 관리자 계정으로 로그온 한 경우 Approval 창 출력

37황인균

Windows 접근 제어 구현 > UAC > 승인 창 아이콘승인 창 아이콘

어플리케이션 종류와 코드 사인에 따라서 사용자 승인 창의 아이콘이 달리질 수 있다 .

Windows 7, 권한 상승 창의 색상 및 아이콘 결정

• 빨간색 방패 아이콘과 빨간색 배경: 그룹 정책에 의해 차단되거나 차단된 게시자에 의해 게시된 어플리케이션

• 파란색과 금색 방패 아이콘 및 파란색 배경: 제어판 항목처럼 Windows 7 이 관리하는 어플리케이션

• 파란색 방패 아이콘과 파란색 배경: 어플리케이션이 Authenticode 서명됨 . : 로컬 컴퓨터에 의해 신뢰됨 .

• 노란색 방패 아이콘과 노란색 배경: 서명에 상관없이 로컬 컴퓨터에 의해 신뢰되지 않음 .

https://technet.microsoft.com/ko-kr/library/dd835561(v=ws.10).aspx

38황인균

Windows 접근 제어 구현 > UAC > 코드 사인

어플리케이션 사인 의미

외부에 의한 어플리케이션 코드 수정 여부 확인 승인 창에 게시자 정보 제공

사용자는 게시자 정보를 확인 후 elevation 승인 여부를 결정한다 . 즉 사용자는 게시자의 “평판”을 이용한다 . 참고 ) SmartScreen Filter 의 평판 기반의 보안 기능 참고

사용자에게 게시자의 평판이 좋다고 해서 , Windows 에서 어플리케이션 프로세스에 관리자 권한을 자동으로 부여하지는 않는다 . 인증서 발급업체 Vesisign 는 코드 작성자가 악성코드를 작성하지 않는다는 것까지 보장하지는 않는다 . 사용자 PC 에 신뢰할 수 있는 게시자로 등록되었더라도 그가 제작한 어플리케이션이 권한 상승을 요청하는 경우는 사용자의 승인을 받아야 한다 .

코드 사인 관련 그룹정책 설정

정책 : • “User Account Control: Only execute executables that are signed and validated”

설명 : • Enabled 관리자 권한으로 실행되기 위해서는 사용자 승인 && 코드 (exe) 도 사인되어야 한다 .• UAC on 에서 코드 사인이 된 어플리케이션만 실행될 수 있다 .

즉 사용자 승인 & 코드 사인 필수• “ 사용자 승인”과 “코드 사인 체크”의 순서는 확인해보지 않음 .

(Mark Minasi, p.110 )

39황인균

Windows 접근 제어 구현 > UAC Virtualization > 기본

Windows 환경 변화 UAC 이전 Windows – single-user 기반 환경 , 관리자 권한 (디폴트 ) UAC 이후 Windows – multi-user 기반 환경 , 사용자 권한 (디폴트 )

동시에 여러 사용자가 동일한 Winwos 를 사용할 수 있는 있는 환경이 되면서 사용자별 환경 구분이 필요함 . 또한 사용자별 환경의 보호가 필요 .

파일 / 레지스트리 가상화 과거 환경과의 호환성을 유지하기 위한 기술 보호된 디렉터리 , 레지스트리 (protected folder or registry) 에 사용자 정의 데이터를 저장하려는 어플리케이션의 행동을

실시간으로 Windows 가 판단해서 리다이렉트시켜주는 기능 Procted area 를 사용하고 있는 레거시 어플리케이션을 위한 과도기적 기술 ( Mark Minasi, p.116) 레거시 어플리케이션 – UAC 이전에 개발된 , 권한 상승을 요청할 수 없는 어플리케이션

시스템 전역 공간

UAC 이전 Windows

Protected area

사용자 #1 공간

사용자 #2 공간

UAC 이후 Windows

40황인균

Windows 접근 제어 구현 > UAC Virtualization > 활성화 조건

가상화 발생 조건 “UAC 이후”의 Windows 환경에서 “사용자 계정으로 실행되는 레거시 어플리케이션”이 “보호된 공간”을 접근하다가 “ Access

Denied” 오류가 발생하는 경우 , 가상화 레거시 어플리케이션 + Protected area 접근 + 권한 부족

가상화 발생하지 않는 경우 UAC 권한 상승된 경우

• 권한 상승된 어플리케이션은 가상화를 사용하지 않는다 . • Runs with an administrator-level token• Has a manifest with a level=parameter• 인스톨 파일인 경우

Running in kernel mode The user token is derived via impersonation

직접적으로 logacy 로 분류된 프로세스에서 시작된 오퍼레이션에 대해서만 가상화가 작동한다 . The application is a 64-bit application

가상화는 레거시 어플리케이션을 위한 기술이다 . 64-bit 어플리케이션은 최신 기술로서 일반 사용자 환경에서 실행되는 어플리케이션으로 구현해야 한다 .

관리자 계정이 접근 파일과 레지스트리에 대한 쓰기 권한이 없는 경우 The application seeks to modify a Registry key that has been marked “don’t_virtualize” Windows Service 는 가상화를 지원하지 않는다 . Mark Minasi, p.121, Mark Runssinovich p.567

41황인균

Windows 접근 제어 구현 > UAC Virtualization > 활성화 조건( 계속 )프로세스 Virtualization status

상태 설명

Enabled 가상화가 지원되는 프로세스 . 필요하면 redirect 가 된다 .“Virtualized 프로세스”

Disabled 많은 Windows 시스템 프로세스들은 이미 관리자 계정으로 실행되고 있어서 , 가상화 상태는 disabled 되어 있다 .앞에서 정리된 가상화가 지원되지 않는 경우는 모두 dis-abled 로 된다 .

Not Allowed UAC off 되면 가상화는 지원되지 않는다 .

Mark Russinovich, p.568

42황인균

Windows 접근 제어 구현 > UAC Virtualization > 파일

Virtualized Process

%ProgramFiles%

%ProgramData%

%SystemRoot%

write

%LocalAppData%\VirtualStore

redirect

File Virtualization - WRITE

Protected Area

File Virtualization - READ

가상화 대상 경로 %ProgramFiles%, %ProgramData%,

%SystemRoot% 가상화 예외 경로

일부 하위 디렉토리 제외 실행 파일 확장자 파일 제외 ( .exe, .bat, .scr, .vbs

등 ) UAC File Virtualization 구현

%SystemRoot%System32\Drivers\Luafv.sys

파일 읽기

1) 가상 경로에서 파일 찾기

2) 가상 경로에서 찾지 못하면 , 실제 경로에서 파일을 찾는다 .

파일 생성

1) Protected area 에 생성하려는 파일은 리다이렉트되어 가상 경로에 생성된다 .

Virtualization

Virtualized Process

%ProgramFiles%

%ProgramData%

%SystemRoot%

read

%LocalAppData%\VirtualStore

1) read

Protected AreaVirtualization

2) read

43황인균

Windows 접근 제어 구현 > UAC Virtualization > 레지스트리

Registry Virtualization - READ

Virtualized Process

HKLM\SOFTWARE

Write- HKLM\Software\App

HKCU\Software\Classes\VirtualStore\Machine\Software\App

redirect

Registry Virtualization - WRITE

가상화 대상 경로 HKLM\Software

가상화 예외 경로 HKLM\Software\Microsoft\Windows HKLM\Software\Microsoft\Window NT HKLM\Software\Classes

파일 시스템과 달리 , 레지의 가상화 대상 경로는 고정되지 않음

레지스트리의 가상화 플래그 값에 따라서 결정됨 플래그 - DONT_VIRTUALIZE, DON’T_SILENT_FAIL,

RECURSE_FLAG(Mark Russinovich p.572) 플래그 값 제어 툴 : Reg.exe

레키 키 생성 Protected area 에 생성하려는 레지 키는

리다이렉트되어 가상 경로에 생성된다 . 레지 읽기

1) 가상 경로에서 레지 키 찾기

2) 가상 경로에서 찾지 못하면 , 실제 경로에서 레지 키를 찾는다 .

Virtualization

Virtualized Process

HKLM\SOFTWARE\App

1) read

Virtualization

2) read

Read - HKLM\Software\App

HKCU\Software\Classes\VirtualStore\Machine\Software\App

※ 가상화와 “ Wow6432” 키와 연관시켜서 검토할 것

44황인균

레퍼런스

Main

Windows Internals, 6th edition 저장 : Mark Russinovich 출판사 : Microsoft

Administering Windows Vista Security 저자 : Mark Minasi, Byron Hynes 출판사 : SYBEX

Etc

Windows Sysinternals Adminitrator’s Reference 저자 : Mark Russinovich 출판사 : Microsoft

MSDN What is the Windows Integrity Mechanism?

( https://msdn.microsoft.com/en-us/library/bb625957.aspx ) Windows Integrity Mechanism Design

( https://msdn.microsoft.com/en-us/library/bb625963.aspx )

45황인균

부록 )Access Token 생성

사용자

① 로그온

Userinit 프로세스

Access Token

윈도우 탐색기 프로세스 생성(Explorer.exe)

Access Token

WinlogonSecurity Subsystem( 보안 참조 모니터 )

① 프로세스 생성 요청 ( 예 , exe 더블클릭 )

② 인증 요청

③Access Token 반환

⑤프로세스 첨부

⑦복사

④ 생성

⑥ 생성

로그온 후 최종 생성되는 윈도우 탐색기 프로세스 (explorer.exe) 에는 사용자의 AccessToken 이 attach 된다 .

46황인균

부록 ) 프로세스 생성

④ 생성

Object Manager

① 프로세스 생성 요청 ( 예 , exe 더블클릭 ) 사용자

윈도우 탐색기 프로세스 생성(Explorer.exe)

Access Token

프로세스

Access Token

Security Subsystem( 보안 참조 모니터 )

② 생성 요청

③ 권한 문의

⑥객체 참조 (핸들 ) 반환

⑤ Access Token 복사

프로세스의 Access Token 사용자가 프로그램을 시작하면 윈도우는 사용자의 Access Token 을 프로그램에 복사한다 .

프로그램이 어떤 방법으로 시작되더라도 Access Token 복사가 된다 . • command 창에서 명령을 통해서 실행• 데스크톱에서 아이콘을 더블클릭해서 실행• 시작 메뉴에서 프로그램을 실행 등

일단 프로그램이 시작되면 , 프로그램의 Access Token 을 변경할 수 없다 . Access Token 을 변경하려면 프로세스가 시작되기 전에 해야 한다 . UAC 가 사용자 승인 창을 보여주는 시점과 관련되어 있다 .

47황인균

부록 )Impersonation

프로세스

Access Token #1

Securable Object

Security Descriptor① 객체 접근

( 오픈 , 읽기 , 쓰기 등 )

사용자

1) 쓰레드

2) 쓰레드 Securable Object

Impersonation Access Token #2

Security Descriptor

프로세스가 다른 사용자 계정으로 쓰레드를 생성하는 경우 (impersonation), 그 쓰레드는 다른 사용자 계정의 토큰을 사용하게 된다 .

다른 사용자

48황인균

부록 )SID 정의 SID( Security Identifier)

사용자 , 그룹 , 컴퓨터 , 그리고 보안 레벨 (Integrity Level, MIC 에서 설명 ) 등을 구분하는 고유한 값 . Windows 에서 주체를 구분하는 방법으로 사용 주체의 Access Tokeen, 객체의 Security Descriptor 에 포함됨

SID 예• S-1-5-21-211353117-160xx-83xx - 1 : revision, 5 : authority, 21~83xxx : subauthority values• S-1-1-0 - everyone 그룹 ( 고정된 SID – 모든 Windows 에서 동일한 값을 가짐 )• SID S-1-5-32-544 - Administrators group( 영어 ), Administratoren(독일 ), Järjestelmänvalvojat(핀란드 )

Local SID( Machine SID )• Windows 컴퓨터는 셋업 시점에 고유한 local SID 를 갖게 된다 . Machine SID 라고도 한다 . • 컴퓨터의 로컬 그룹 및 사용자 계정은 machine SID + RID 형식의 고유한 SID 를 갖는다 .

Domain SID• Active Directory domain 도 컴퓨터처럼 자신의 domain SID 를 갖는다 .• 도메인의 그룹 , 사용자 계정 , 멤버 컴퓨터 등의 엔터티도 domain SID + RID 형식의 고유한 SID 를 갖는다 .

Windows 의 Well-known SID• NT AUTHORITY, BUILTIN domains 등• Well-known security identifiers in Windows operating systems

( https://support.microsoft.com/en-us/kb/243330 ) Service SID

• Vista 이후로는 Windows Service 를 구분하기 위한 SID 도 도입되었다 . • SID “SID 이름”을 변환해주는 Sysinternals 툴

• PsGetSid.exe• 명령

psgetsid S-1-5-21-1699876237-…• 출력결과

Account for 로컬컴퓨터명 \S-1-5-21-1699876237-…:User: 도메인명 \dalbong2

각 엔터티의 SID = domain SID + RID(Relative ID)

49황인균

부록 ) UAC 관련 그룹정책

설정 설명 옵션 비고

User Account Control: Use Admin Approval Mode for the built-in Administrator account

This policy setting controls the behavior of Admin Ap-proval Mode for the built-in Administrator account.

• Enabled: The built-in Administrator ac-count uses Admin Approval Mode. By de-fault, any operation that requires elevation of privilege will prompt the user to approve the operation.

• Disabled: (Default) The built-in Adminis-trator account runs all applications with full administrative privilege.

User Account Control: Allow UIAccess applica-tions to prompt for ele-vation without using the secure desktop.

This policy setting controls whether User Interface Ac-cessibility (UIAccess or UIA) programs can automatically disable the secure desktop for elevation prompts used by a standard user.

• Enabled: UIA programs, including Win-dows Remote Assistance, automatically disable the secure desktop for elevation prompts. If you do not disable the "User Account Control: Switch to the secure desktop when prompting for elevation" pol-icy setting, the prompts appear on the in-teractive user's desktop instead of the se-cure desktop.

• Disabled: (Default) The secure desktop can be disabled only by the user of the in-teractive desktop or by disabling the "User Account Control: Switch to the secure desktop when prompting for elevation" pol-icy setting.

Local Group Policy Editor - gpedit.msc Local Computer Policy > Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options 하위에 10 개

50황인균

부록 )UAC 관련 그룹정책설정 설명 옵션 비고

User Account Control: Behavior of the eleva-tion prompt for adminis-trators in Admin Ap-proval Mode

This policy setting controls the behavior of the eleva-tion prompt for administra-tors.

• Elevate without prompting: Allows privileged accounts to perform an operation that requires elevation without re-quiring consent or credentials. Note: Use this option only in the most constrained environments.

• Prompt for credentials on the secure desktop: When an operation requires elevation of privilege, the user is prompted on the secure desktop to enter a privileged user name and password. If the user enters valid credentials, the operation continues with the user's highest available privilege.

• Prompt for consent on the secure desktop: When an op-eration requires elevation of privilege, the user is prompted on the secure desktop to select either Permit or Deny. If the user selects Permit, the operation continues with the user's highest available privilege.

• Prompt for credentials: When an operation requires ele-vation of privilege, the user is prompted to enter an admin-istrative user name and password. If the user enters valid credentials, the operation continues with the applicable privilege.

• Prompt for consent: When an operation requires eleva-tion of privilege, the user is prompted to select either Per-mit or Deny. If the user selects Permit, the operation con-tinues with the user's highest available privilege.

• Prompt for consent for non-Windows binaries: (Default) When an operation for a non-Microsoft application requires elevation of privilege, the user is prompted on the secure desktop to select either Permit or Deny. If the user selects Permit, the operation continues with the user's highest available privilege.

51황인균

부록 ) UAC 관련 그룹정책설정 설명 옵션 비고

User Account Control: Behavior of the eleva-tion prompt for standard users

This policy setting controls the behavior of the eleva-tion prompt for standard users.

• Prompt for credentials: (Default) When an operation requires elevation of privilege, the user is prompted to enter an administrative user name and password. If the user enters valid credentials, the operation con-tinues with the applicable privilege.

• Automatically deny elevation requests: When an op-eration requires elevation of privilege, a configurable access denied error message is displayed. An enter-prise that is running desktops as standard user may choose this setting to reduce help desk calls.

• Prompt for credentials on the secure desktop: When an operation requires elevation of privilege, the user is prompted on the secure desktop to enter a different user name and password. If the user enters valid cre-dentials, the operation continues with the applicable privilege.

User Account Control: Detect application in-stallations and prompt for elevation

This policy setting controls the behavior of application installation detection for the computer.

• Enabled: (Default) When an application installation package is detected that requires elevation of privi-lege, the user is prompted to enter an administrative user name and password. If the user enters valid cre-dentials, the operation continues with the applicable privilege.

• Disabled: Application installation packages are not detected and prompted for elevation. Enterprises that are running standard user desktops and use dele-gated installation technologies such as Group Policy Software Installation or Systems Management Server (SMS) should disable this policy setting. In this case, installer detection is unnecessary.

52황인균

부록 ) UAC 관련 그룹정책

설정 설명 옵션

User Account Control: Only elevate executable files that are signed and validated

This policy setting enforces public key in-frastructure (PKI) signature checks for any interactive applications that request ele-vation of privilege. Enterprise administra-tors can control which applications are al-lowed to run by adding certificates to the Trusted Publishers certificate store on lo-cal computers.

• Enabled: Enforces the PKI certification path validation for a given executable file before it is permitted to run.

• Disabled: (Default) Does not enforce PKI certification path val-idation before a given executable file is permitted to run.

User Account Control: Only elevate UIAccess applications that are in-stalled in secure locations

This policy setting controls whether appli-cations that request to run with a User In-terface Accessibility (UIAccess) integrity level must reside in a secure location in the file system. Secure locations are lim-ited to the following:

- …\Program Files\, including subfolders- …\Windows\system32\- …\Program Files (x86)\, including sub-folders for 64-bit versions of Windows

Note: Windows enforces a public key in-frastructure (PKI) signature check on any interactive application that requests to run with a UIAccess integrity level regard-less of the state of this security setting.

• Enabled: (Default) If an application resides in a secure loca-tion in the file system, it runs only with UIAccess integrity.

• Disabled: An application runs with UIAccess integrity even if it does not reside in a secure location in the file system.

53황인균

부록 ) UAC 관련 그룹정책설정 설명 옵션 비고

User Account Control: Turn on Admin Approval Mode

This policy setting controls the behavior of all User Ac-count Control (UAC) policy settings for the computer. If you change this policy set-ting, you must restart your computer.

• Enabled: (Default) Admin Approval Mode is enabled. This policy must be enabled and related UAC policy set-tings must also be set appropriately to allow the built-in Administrator account and all other users who are mem-bers of the Administrators group to run in Admin Approval Mode.

• Disabled: Admin Approval Mode and all related UAC pol-icy settings are disabled. Note: If this policy setting is dis-abled, the Security Center notifies you that the overall security of the operating system has been reduced.

User Account Control: Switch to the secure desktop when prompt-ing for elevation

This policy setting controls whether the elevation re-quest prompt is displayed on the interactive user's desktop or the secure desk-top.

• Enabled: (Default) All elevation requests go to the se-cure desktop regardless of prompt behavior policy set-tings for administrators and standard users.

• Disabled: All elevation requests go to the interactive user's desktop. Prompt behavior policy settings for admin-istrators and standard users are used.

User Account Control: Virtualize file and reg-istry write failures to per-user locations

This policy setting controls whether application write failures are redirected to defined registry and file sys-tem locations. This policy setting mitigates applica-tions that run as administra-tor and write run-time ap-plication data to %Program-Files%, %Windir%, %Windir%\system32, or HKLM\Soft-ware.

• Enabled: (Default) Application write failures are redi-rected at run time to defined user locations for both the file system and registry.

• Disabled: Applications that write data to protected loca-tions fail.