Microsoft MVP성태의 닷넷 이야기
Windows: 16. 개발자를 위한 UAC 환경 설정 [링크 복사], [링크+제목 복사],
조회: 27834
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 2개 있습니다.)

개발자를 위한 UAC 환경 설정


이미 2차례에 걸쳐서, 다음과 같은 글로 UAC 관련 설명을 했습니다.

보호 모드와 필수 무결성 제어(MIC: Mandatory Integrity Control)
; https://www.sysnet.pe.kr/2/0/433

MIC 환경 구성 - Windows XP와 유사한 보안 설정
; https://www.sysnet.pe.kr/2/0/434

처음, 윈도우즈 비스타를 사용했을 때는, 개발자 환경이 워낙 관리 권한을 많이 건드리기 때문에 당연히 UAC를 해제해야만 한다고 생각했었습니다. 하지만, 조금씩 비스타에 익숙해지면서... UAC 창이 그다지 많이 뜨는 것은 아님을 알게 되었습니다. 여러분들도 한번 잠시 UAC 확인창에 대해서 생각해 보십시오. 정말로 그렇게 자주 뜨던가요?

솔직히, 응용 프로그램보다는 오히려 인터넷 웹 사이트에서 더욱 UAC 확인창을 요구하더군요. 아니 좀 더 정확히 말하면 UAC 확인창을 요구한다기보다는 애당초 관리자 권한으로 인터넷 익스플로러를 실행시켜야 하지요. ^^;

그건 그렇다 치고... 어쨌든 기존 환경에 비하면 단 한 번일지라도 UAC 확인창을 거쳐야 하는 것이 불편하지 않을리 없습니다. 따라서, 어떻게 해서든지 ^^ 조금이라도 편해질 수 있는 환경 설정을 하는 것이 좋을 텐데요.

나름대로 생각해 보면, 자신의 환경에 따라서 다음과 같은 4가지 구성 중에서 선택하는 것이 가능할 것 같습니다.



1. 기본 환경이 관리 모드여야 하는 개발자라면?
간단하지요. ^^; UAC를 해제하면 됩니다. "msconfig.exe"를 실행시키고, "Tools" 탭에 있는 "Disable UAC"를 실행시켜 준 후 재부팅을 하게 되면 UAC가 해제되고 기본적으로 모든 프로세스들의 "integrity SID" 값이 "high"로 설정되어 실행됩니다. 무조건 high 모드에서 개발하는 업종(예를 들면, 커널 개발 같은)이 아니라면 별로 권하고 싶지 않은 설정입니다.

2. 비록 빈번한 관리자 환경이 요구되기는 하지만 전체적인 MIC 환경은 유지하고 싶은 경우라면?
초기에 제가 즐겨 사용했던 구성입니다. 재부팅이 필요하지 않은데다 UAC 확인창이 뜨지 않고도 자동으로 관리 권한 요청이 발생하면 승격이 됩니다. (따라서, 인터넷 익스플로러 같은 경우에 명시적으로 "Run as administrator"로 실행시켜 주지 않으면 포탈 사이트의 ActiveX들이 정상적으로 동작하지 않았습니다.)

이러한 구성은 "로컬 보안 정책(local security policy)"에서 해줄 수 있습니다. "시작 메뉴"의 명령어 입력창(사실, 이제는 "검색"과 관련되어 있지만.)에서 "로컬 보안 정책"이라고 입력해 주시면 됩니다. 그럼, 다음과 같은 로컬 보안 정책 관리자 콘솔이 뜨게 되는데, "보안 설정" / "로컬 정책" / "보안 옵션"으로 이동해서 "사용자 계정 컨트롤: 관리자 계정일 때 관리 승인 모드에서 권한 상승 확인 방법" 값을 "권한 상승 전에 확인 안 함"으로 설정하는 것입니다.

uac_settings_for_dev_1.png

위와 같이 설정하게 된 이후에는, UAC 확인창이 뜨질 않습니다. 왜냐하면 자동으로 "확인"한 것으로 간주하기 때문입니다. 물론 승격 요청 이전에는 각 프로세스들의 "integrity SID" 값도 그대로 유지된 체 시스템이 운영됩니다. 재부팅도 필요하지 않기 때문에 무척 편리한 설정입니다. 사실, "권한 승격 요청"은 악성 코드에 상관없이 모두 할 수 있기 때문에 이 모드가 "안전"하다고 볼 수는 없습니다.

3. 특정 프로그램만이 관리 권한이 요구되는 환경이라면?
예를 들어, VS.NET 2005로 웹 사이트를 IIS와 연동하여 개발하는 경우라면, IIS의 메타베이스 정보를 접근하게 되어 관리자 권한이 필요하게 됩니다. 따라서, 이런 분들은 거의 매일 VS.NET 2005를 관리자 권한으로 실행하게 될 텐데요. 그때마다 매번 "관리자 권한으로 실행(Run as administrator)"으로 실행시키기가 꽤나 번거로울 테니, VS.NET 2005 아이콘을 오른쪽 마우스 버튼으로 눌러서 나오는 속성창에서 "관리자 권한으로 이 프로그램 실행(Run this program as an administrator)"을 설정해 두시는 것이 편리하겠습니다.

uac_settings_for_dev_2.png

즉,,, 이제부터는 UAC는 받아들이되 어떻게해서든지 번거로운 과정을 하나라도 줄이는 노력을 해야 하겠지요. ^^

4. 일반 응용 프로그램 개발자라면?
문제는 ^^ 이런 분들입니다. 방법이 없단 얘기입니다. 그냥 일반 사용자와 동등하게 UAC를 받아들이셔야 합니다. 위의 '3번'에서 살펴본 "관리자 권한으로 실행(Run as administrator)"조차도 이 분들은 대상이 될 수 없습니다. 왜냐고요?

일단, VS.NET 2005 프로세스가 관리 권한으로 승격된 이후에는, 그 자식으로 실행되는 프로세스들 역시 "high" 권한으로 실행되어 집니다. 아래의 화면은 VS.NET 2005에서 "WindowsApplication1" 프로젝트를 만든 후, "Ctrl + F5" 키를 눌러 실행시켰을 때의 프로세스 구조입니다. "WindowsApplication1.vshost.exe"는 물론이고 "WindowsApplication1.exe" 역시 "devenv.exe"의 자식 프로세스로 실행되기 때문에 "high" 권한을 그대로 물려받아 실행되게 됩니다. UAC 환경 테스트가 제대로 될 수 없겠지요!

uac_settings_for_dev_3.png



그럼, 저는 어떻게 해두고 쓰냐는 질문을 하실 분이 계실 텐데요. 저는 위의 "4번" 선택의 변형으로 해두고 있습니다. 기본적으로는 4번 단계인데, 거기에 "로컬 보안 정책"에서 "보안 설정" / "로컬 정책" / "보안 옵션"의 "사용자 계정 컨트롤: 권한 상승시 보안 데스크톱으로 전환" 값을 아래와 같이 "사용 안함"으로 두고 있습니다.

uac_settings_for_dev_4.png

데스크톱 보안을 사용하지 않게 되므로, UAC 확인창을 제어하려고 들면 보안이 뚫리게 되는 단점이 있지만 저처럼 ^^ 컴퓨터를 표준으로 사용하는 사람이라면 별다른 위험이 없을 것으로 "스스로" 판단하고 있기 때문에 이 정도로만 해두고 있습니다. 적어도 UAC 제어를 받는 프로그램의 개발에도 영향을 주지 않고 데스크톱 전환으로 인한 부하가 없기 때문에 개인적으로는 이 정도 선택이 가장 최선인 것 같습니다.

혹시... 여러분들 중에서 "나는 위에서 설명한 방법과는 다르게 구성했다."라는 분들이 계시다면 공개 좀 부탁드리겠습니다. ^^

마지막으로 하고 싶은 말.

"개발자일수록 UAC를 Enable 상태로 둬야 한다"





[이 토픽에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 2/11/2023]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 



2007-01-15 03시01분
[WaterStone] 저는 완전히 UAC 기본 값으로 사용하고 있습니다.
문제가 무엇인가 알아야 대처가 가능하기 땀시...
가끔 WCF 프로그래밍이나 기타 관리자 권한이 필요한 경우에는 VS 2005를 관리자 권한으로 구동시키곤
합니다만...

참... 보안 데스크톱을 사용하지 않을 때의 장점이 있나요?
보안 상승 확인이 좀 더 빨리 뜬다든가 등등...
[guest]
2007-01-15 03시18분
예. 보안 상승 확인창이 빨리 뜹니다. 그나마 ^^; 0.1초의 생산성을 올리기 위해 택할 수 있었던 유일한 방법이었습니다.

보안 데스크톱 전환에 대해 설명한 글을 읽어보면 재미있는 사실을 발견할 수 있는데요. ^^ 원래 데스크톱 단위 사이에서는 화면 공유가 안되잖아요? 그런데, UAC 확인창이 뜰 때 배경에 기존 화면이 남아있을 수 있게 전체 화면을 캡쳐해서 이미지 처리한다고 합니다. 사실 많이 빨라서 덜 느낀다고는 해도,,, 어쨌든, 화면이 깜박이는 것 자체가 별로니까요.

조금은 편리할 수 있다고 해도, 다음의 글에서도 밝히듯이 그다지 권장하지 않는다고 합니다. ^^

User Account Control Prompts on the Secure Desktop
; https://learn.microsoft.com/en-us/archive/blogs/uac/user-account-control-prompts-on-the-secure-desktop
kevin25
2011-05-18 08시32분
[guest] "Computer Configuration" / "Windows Settings" / "Security Settings" / "Local Policies" / "Security Options"
- User Account Control: Switch to the secure desktop when prompting for elevation
[guest]

... 16  17  18  19  20  21  22  23  24  [25]  26  27  28  29  30  ...
NoWriterDateCnt.TitleFile(s)
13191정성태12/11/202210593.NET Framework: 2077. C# - 직접 만들어 보는 SynchronizationContext파일 다운로드1
13190정성태12/9/202211265.NET Framework: 2076. C# - SynchronizationContext 기본 사용법파일 다운로드1
13189정성태12/9/202212009오류 유형: 831. Visual Studio - Windows Forms 디자이너의 도구 상자에 컨트롤이 보이지 않는 문제
13188정성태12/9/202210154.NET Framework: 2075. C# - 직접 만들어 보는 TaskScheduler 실습 (SingleThreadTaskScheduler)파일 다운로드1
13187정성태12/8/202210259개발 환경 구성: 654. openssl - CA로부터 인증받은 새로운 인증서를 생성하는 방법 (2)
13186정성태12/6/20228312오류 유형: 831. The framework 'Microsoft.AspNetCore.App', version '...' was not found.
13185정성태12/6/20229222개발 환경 구성: 653. Windows 환경에서의 Hello World x64 어셈블리 예제 (NASM 버전)
13184정성태12/5/20228539개발 환경 구성: 652. ml64.exe와 link.exe x64 실행 환경 구성 [1]
13183정성태12/4/20228546오류 유형: 830. MASM + CRT 함수를 사용하는 경우 발생하는 컴파일 오류 정리 [1]
13182정성태12/4/202210055Windows: 217. Windows 환경에서의 Hello World x64 어셈블리 예제 (MASM 버전)
13181정성태12/3/20228594Linux: 54. 리눅스/WSL - hello world 어셈블리 코드 x86/x64 (nasm)
13180정성태12/2/20228689.NET Framework: 2074. C# - 스택 메모리에 대한 여유 공간 확인하는 방법파일 다운로드1
13179정성태12/2/20227738Windows: 216. Windows 11 - 22H2 업데이트 이후 Terminal 대신 cmd 창이 뜨는 경우
13178정성태12/1/20228611Windows: 215. Win32 API 금지된 함수 - IsBadXxxPtr 유의 함수들이 안전하지 않은 이유파일 다운로드1
13177정성태11/30/20229238오류 유형: 829. uwsgi 설치 시 fatal error: Python.h: No such file or directory
13176정성태11/29/20227664오류 유형: 828. gunicorn - ModuleNotFoundError: No module named 'flask'
13175정성태11/29/202210637오류 유형: 827. Python - ImportError: cannot import name 'html5lib' from 'pip._vendor'
13174정성태11/28/20228423.NET Framework: 2073. C# - VMMap처럼 스택 메모리의 reserve/guard/commit 상태 출력파일 다운로드1
13173정성태11/27/20229187.NET Framework: 2072. 닷넷 응용 프로그램의 스레드 스택 크기 변경
13172정성태11/25/20228740.NET Framework: 2071. 닷넷에서 ESP/RSP 레지스터 값을 구하는 방법파일 다운로드1
13171정성태11/25/20228347Windows: 214. 윈도우 - 스레드 스택의 "red zone"
13170정성태11/24/20228522Windows: 213. 윈도우 - 싱글 스레드는 컨텍스트 스위칭이 없을까요?
13169정성태11/23/20229359Windows: 212. 윈도우의 Protected Process (Light) 보안 [1]파일 다운로드2
13168정성태11/22/20228644제니퍼 .NET: 31. 제니퍼 닷넷 적용 사례 (9) - DB 서비스에 부하가 걸렸다?!
13167정성태11/21/20228633.NET Framework: 2070. .NET 7 - Console.ReadKey와 리눅스의 터미널 타입
13166정성태11/20/20228526개발 환경 구성: 651. Windows 사용자 경험으로 WSL 환경에 dotnet 런타임/SDK 설치 방법
... 16  17  18  19  20  21  22  23  24  [25]  26  27  28  29  30  ...