02. 관리 - 보안 관리 검색 결과

해당 글 56건

[연재 06] 레거시 프로그램과의 호환성 지원

Vista는 보안을 위해서 새로운 보안 모델을 내놨고 따라서 이전 Windows에서는 관리자 계정으로 로그온만 하면 잘 실행되던 프로그램이 이제는 관리자로 로그온하더라도 권한 부족으로 실행에 실패할 상황에 처하게 되었다. 따라서 Vista는 실행 권한이라는 측면에서 이전 프로그램과의 호환성을 해결할 필요가 있게 되었다. 앞 포스트에서는 개발자가 UAC의 토큰 판단에 영향을 미칠 수 있는 방법에 대해서 알아봤다. 개발자에게는 그것이 중요한 내용이라 본다. 이제 이 포스트에서는 UAC가 권한 상승을 스스로 판단하는 기능 그리고 어떻게 레거시 프로그램들과의 호환성을 지원하고 있는지에 대해서 알아보겠다. 여기서 다룰 것은 다음 3가지를 포함한다. ▶Vista의 인스톨러를 자동 인식하는 기능 ▶PCA(Progra..
02. 관리 - 보안 관리 2009.04.23 15:08

[연재 05] Vista가 자동으로 관리자 토큰을 사용하도록 하는 방법

프로그램이 실행되는 도중에 권한 부족으로 프로그램이 중단되었다는 메세지는 신뢰도에 치명적이지 않을 수 없을 것이다. 그렇다면 프로그램이 시작되기 전에 관리자 권한이 필요하다는 것을 어떻게 UAC에게 알릴 것인가에 대한 것이 달봉이가 이전 포스트에서부터 기록하고 싶은 주제중의 하나이다. 그렇다고 동의 확인 창 또는 관리자 계정 요청 창이 뜨게 하지 않을 수는 없다. 관리자 권한이 필요하다면 사용자로부터의 확인을 요하는 창은 뜨게 되어 있다. 결국 개발자는 어떻게 하면 이 확인창을 뜨게 할 것인가를 고민해야 하는 것이 이 포스트들의 주요 내용이라고 할 수 있다. 앞 포스트에서는 사용자가 직접 Vista(UAC)에게 관리자 토큰을 사용하도록 하는 하는 방법에 대해서 알아봤다. 이번 포스트에서는 프로그램을 실행..
02. 관리 - 보안 관리 2009.04.23 15:07

[연재 04] 관리자 토큰을 사용하도록 사용자가 직접 Vista에 일러주는 방법

Administrator Approval Mode의 관리자는 로그온을 하게 되면 일반 사용자 계정의 토큰을 사용하게 된다는 것은 이제 이해했다. UAC의 사정이 이러하므로 관리자 권한이 필요한 어플리케이션을 시작할때는 반드시 Windows에 관리자 토큰을 사용하도록 말해 줄 필요가 있다. 그렇지 않으면 Windows는 아무 생각없이 일반 사용자 토큰으로 프로그램을 시작할 것이고 그러다가 관리자 권한이 필요한 부분에서는 권한 부족으로 프로그램이 작동하지 않게 될 것이다. 이 포스트에서는 Windows에 관리자 토큰을 사용하도록 일러주는 방법으로서 사용자가 직접 조치를 취하는 방법을 알아본다. 그리고 다음 포스트에서는 사용자가 직접 일러주지 않더라도 Windows가 자동으로 인식해서 관리자 토큰을 사용할 수..
02. 관리 - 보안 관리 2009.04.23 15:07

[연재 03] Deeper into the UAC

앞의 포스트를 요약해보면 다음과 같다. "관리자 권한이 필요한 프로그램이 권한 관련해서 에러없이 실행되도록 하려면, 1) 사용자가 관리자 계정으로 프로그램을 실행시키든지 2) 프로그램 자체가 관리자 계정으로 실행되어야 한다는 것을 Windows에게 알려줄 수 있어야 한다. 여기까지는 나름대로 깔끔한 정리이다. 그러나 구체적으로, 언제 UAC에게 언제 어떻게 관리자 토큰을 사용하라고 일러줄 수 있는지에 대한 질문들이 남아있다. 그 질문에 대한 답을 바로 들어가기 전에 이 포스트에서는 토큰(token)의 구조를 좀 더 깊게 알아보자. 어떻게 보면 프로그래밍과는 직접적인 관계는 없으나 보안과 관련된 지식으로써 알아두면 나중에라도 도움이 될 것이다. 토큰(Token)의 구조 토큰은 사용자가 로그온을 하게 되면 ..
02. 관리 - 보안 관리 2009.04.23 15:06

[연재 02] 분리된 토큰 모델(Split token)

달봉이는 Wndows의 보안에 대해서는 잘 모른다. 그러나 UAC를 이해하기 위해서는 기본적인 내용은 알고 있어야 할 것 같아서 이전 Windows의 보안에 대해서 간단히 정리하고 Vista의 UAC 얘기를 계속하겠다. ■ 이전 Windows의 Security Basics 이전 Windows의 보안 모델을 간단히 풀이하면 다음과 같은 그림으로 정리될 수 있을 것 같다(그림이 잘 되었는지는 누구의 검증도 안받았다 -_-;;) [그림] Windows Security Basics 사용자가 로그온을 하면 "토큰(token)"이라는 것이 메모리에 생성된다(1). 토큰에는 사용자가 누구이며 어떤 권한을 갖는가를 정의하는 데이터 구조이며 유일한 값을 갖는다. 사용자가 로그온 후 "diary.doc"라는 워드 문서를 ..
02. 관리 - 보안 관리 2009.04.23 15:06

[연재 01] An Overview Of UAC

UAC는 다시 한번 더 체계적으로 정리할 필요가 있을 것 같다. 뭐든지 튼튼한 기본이 중요한 법인데, UAC는 프로그래밍시 기본적으로 이해하고 있어야 하는 새로운 컨셉일 것이라는 생각에서이다. 해서 체험기부터 해서 다시 나름대로 신경써서 함 정리해보려 한다. UAC라는 것은 머신을 제외한 모든 사람들은 싫어할 것 같은 특징중의 하나인 것 같다. 사용자도 그렇고 개발자도 그렇고 그리고 관리자도 그렇게 좋아할 것 같지는 않다. 처음에 달봉이도 상당히 당혹스러웠다. 그러나 한편으로는 개발자로서의 호기심이 발동하기도 했다. 이번 연재에서는 체험기에서부터 다시 시작해서 나름대로 UAC에 대한 필요성을 알아보고 그리고 구체적으로 개발시 어떻게 해결해야 하는지를 알아보겠다. ■ UAC 시작하기 Vista를 설치하는 ..
02. 관리 - 보안 관리 2009.04.23 15:06

Documents and Settings 이 보이지 않는다.

사용자 프로파일별 폴더와 데이터가 저장되던 "Documents and Settings"라는 폴더의 이름이 달봉이에게는 이상하게 보였는데, 이것이 없어질 모양이다. 이 폴더 역할을 하는 새로운 폴더가 Vista에서는 "사용자"라는 좀 더 그럴싸한 이름으로 생기게 되었다. 그러나 "Documents and Settings" 폴더도 완전히 없어진 것은 아니다. 내부적으로 숨겨져 있고 NTFS 퍼미션을 설정해서 "Everyone 그룹"이 "Documents and Settings"에 접근해서 읽을 수 없도록 했다. 결국 직접 "Document and Settings"폴더에 직접 접근해서 데이터를 쓰려고 하면 실패하게 될 것이다. 그럼, 이전에 "Documents and Settings"라는 폴더에 데이터를 쓰던..
02. 관리 - 보안 관리 2009.04.19 21:12

Vista의 가상화(Virtualization)

Vista에서는 일반 사용자(Administrators 그룹에 속한 사용자 포함)는 시스템에서 보호되는 디렉토리 또는 레지스트리에 직접 쓰지 못하도록 하고 있다. 보호받는 디렉토리와 레지스트리 경로는 다음과 같다. (%SYSTEMROOT%, %PROGRAMDATA%, %PROGRAMFILES%\(서브디렉토리) HKEY_LOCAL_MACHINE\SOFTWARE 그럼, 기존에 이런 곳에 접근해서 데이터를 저장하고 있는 어플리케이션은 모두 사용할 수 없게 되는 것인가. Vista에서는 "임시"로 이런 어플리케이션의 호환성을 위하여 가상화 기술을 도입하고 있다. 어플리케이션에서 보호받는 디렉토리와 레지스트리에 데이터를 쓰려고 하면 Vista에서는 런타임시 그 경로를 사용자별 경로로 자동으로 변경시켜 준다. %S..
02. 관리 - 보안 관리 2009.04.19 20:16

내 PC의 UAC정책 설정 내용을 보자.

그룹 정책 편집기를 실행시켜 보면 현재 내 PC에 설정된 정책 내용을 볼 수 있는데, 이곳에서 UAC 정책 설정 내용도 볼 수 있다. "시작->검색 시작->gpedit.msc" "로컬 컴퓨터 정책->컴퓨터 구성->Windows 설정->보안설정->로컬 정책->보안 옵션"을 선택하면 그림과 같은 내용의 UAC 설정을 볼 수 있다. [그림] 내 PC의 UAC 정책 설정 이 설정 내용을 보면 UAC에 의해서 어떤 일들이 일어나는지를 알 수 있고 그래서 UAC 개념에 대한 이해에도 도움이 될 것이다. 다음은 각 정책을 더블 클릭했을 때 나오는 설명들로서, 몇가지 확인해봐야 하는 내용도 있지만 그대로 복사해 놓고 있다. 1. 각 사용자 위치에 파일이나 레지스트리를 쓰기 오류 발생할 때 가상화 : 사용 사용자 계정 ..
02. 관리 - 보안 관리 2009.04.19 19:17

기본 제공 관리자(built-in Adminitrator) 계정을 보여줘

Administrators 그룹에 속한 관리자와 기본 제공 관리자(Built-in Administrator)는 구분된다. 기본 제공 관리자는 UAC의 적용을 받지 않는다(Administrator 여부를 체크하지 않는다기 보다는). 따라서 높은 권한을 필요로 하는 프로세스를 실행시키더라도 보안창을 띄우지 않는다. 그러나 기본 제공 관리자 계정으로 로그온하는 것은 Vista에서는 비추천이다. 하여튼, 처음 Vista를 설치해서 로그인을 하려고 하면 Administrator 계정이 보이지 않는다. 달봉이는 약간 당황했다. [그림] 로그온 계정 Vista에서는 기본적으로 이 관리자 계정은 사용하지 못하도록 설정되어 있다. 이 계정이 나타나도록 하려면 설정을 하나 변경해야 한다. 시작->실행-> gpedit.ms..
02. 관리 - 보안 관리 2009.04.19 18:18

UAC( User Account Control)

Windows Vista를 공부하기 시작한지는 얼마되지 않았지만 지금까지 훑어본 바로는 개발자에게 제일 먼저 영향을 끼칠만한 것이 바로 새롭게 등장한 UAC 보안 모델일 것으로 보인다. 이것때문에 개발 패턴이 변경될 것으로 보이고 나아가서는 분명 프로그램 사용에 있어서 지금까지와는 다른 사용자 경험을 제공하게 될 것이다. 해서 이번 포스트에서는 UAC를 알아보고 결국 이녀석으로 인해 개발과 배포에 변화가 생기게 될텐데, 아직 직접 테스트는 해 보지 못한 상태이지만 그래도 컨셉적으로나마 그 가이드를 정리해 보고자 한다. ■ UAC가 뭣이여 이것은 무슨 컨트롤이여. 윈도우 컨트롤이여, 웹 컨트롤이여. 아니란다. 윈도우, 웹 컨트롤의 컨트롤은 이름씨(명사)인 반면 UAC의 컨트롤은 움직씨(동사)이다. 얼른 떠..
02. 관리 - 보안 관리 2009.04.19 17:21

비스타 첫 체험기. 비스타 니가 뭔데. 쫌~

비스타 니가 뭔데. 쫌~. 비스타로 하도 떠들썩하길래, 지금 프로젝트가 끝나기 전에 미리 함 체험해 볼 생각으로 설치해보기로 했다. 진행중인 프로젝트의 개발때문에, Windows 2003 서버도 필요했다. 자금 문제 때문에 노트북을 하나 더 구매할 수는 없고, 해서 하나의 노트북에 Virutal PC 2007을 이용해서 같이 설치하기로 했다. 처음에는 노트북의 메인 OS로 비스타를 설치했다. 처음 생각과는 달리 Visual Studio를 비스타에 설치해 보기로 했다. 그래서 왠만하면 지금 프로젝트 솔루션을 비스타에서 구성해서 계속 개발을 해 보기로 했다. 그리고 Virtual PC에는 Windows 2003을 설치해서 아직 비스타에서 실행되지 않는 프로그램들도 있다고 하니 그런 것들은 2003에 설치할려..
02. 관리 - 보안 관리 2009.04.19 16:22

[연재] 8. 보안 요청

8. 보안 요청 보호된 리소스를 직접 액세스하는 코드를 작성하거나 이러한 액세스가 호출자에게 노출되는 경우, 호출하는 코드(어셈블리)에 권한이 있는지를 확인하는 요청을 작성할 수 있다. 호출자에 의한 호출이 실제로 수행되기 전에 이런 요청에 대한 권한 체크를 먼저 통과해야 한다. 이런 권한 요청은 어트리뷰트를 사용한 선언적인 방법을 사용할 수도 있고 또는 메소드를 통해서 프로그램적 요청을 사용할 수 있다. 대부분의 .NET Framework 클래스에는 자신과 연결된 요청이 이미 있으므로 보호된 리소스에 액세스하는 클래스를 사용할 때마다 요청을 추가할 필요가 없다. 예를 들어, StreamWriter 클래스는 열릴 때마다 자동으로 FileIOPermission에 대한 보안 요청을 한다. StreamWrit..
02. 관리 - 보안 관리 2006.04.23 21:43

[연재] 7. 보안 정책 배포

7. 보안 정책 배포 지금까지의 과정, 권한 그룹 생성, 코드 그룹 생성 및 세부 사항 편집은 모두 프로그램적으로도 가능하다. 따라서 클라이언트 보안을 설정하는 exe 프로그램을 제작해서 사용자들에게 배포하면 된다. 그러자면 CAS와 관련한 API를 숙지하고 있어야 할 것이다. 그러나 관리 툴은 그보다 간단한 배포 방법을 제공해주고 있다. 이 방법을 사용하면 보안 편집 툴로 편집한 내용을 .msi 파일로 자동 생성해준다. 이 .msi 파일을 사용자들에게 배포만 하면 된다. 관리 툴을 이용한 보안 정책 배포 #1 런타임 보안 정책(오른쪽 클릭)->배포 패키지 만들기…를 선택한다. 관리 툴을 이용한 보안 정책 배포 #2 이 화면에서 배포할 보안 정책 수준을 선택할 수 있다. 그리고 .msi 파일명을 입력하고..
02. 관리 - 보안 관리 2006.04.23 21:43

[연재] 6. 보안 정책 설정 예

6. 보안 정책 설정 예다음은 관리툴을 사용해서 보안 정책을 배포하는 예제를 보겠다. 이 보안 정책에서는 부모와 자식, 2 계층 구조의 코드 그룹을 생성해서 권한 집합을 확대하는 방법을 보이겠다. 그리고 앞에서 생략한 사용자가 직접 권한 집합을 만드는 예도 더불어 본다. ■ 권한 집합 생성먼저 코드그룹에서 사용할 권한 집합을 "SCPermissionSet'이라는 이름으로 미리 하나 만들어두자. 집합을 새로 생성하려면 권한에 대한 자세한 내용을 알고 있어야 한다. 그러나 현실적으로 엔터프라이즈 애플리케이션을 개발하는 개발자들이 권한 집합을 생성하거나 편집하면서 개발할 시간은 거의 없다. 따라서 개발자시에는 주로 이미 만들어진 FullTrust 권한 집합을 사용하는 것이 보통이다. 권한 집합 생성 #1 생성..
02. 관리 - 보안 관리 2006.04.23 21:43

[연재] 5. 보안 설정 편집

5. 보안 설정 편집 이제 개념적인 내용을 알았으니 PC의 보안 설정을 편집하는 방법을 알아보자.이곳에서는 어셈블리가 실행될 컴퓨터에 코드 그룹을 생성하고 그룹에 권한을 매핑하는 작업을 권한 관리 툴을 이용하는 방법을 보여준다. 툴을 사용해서 편집한 보안 내용은 .config 파일에 저장될 것이고 어셈블리가 로딩될 때 정책 평가기에 의해서 해석되어서 어셈블리에 설정된 권한을 부여할 것이다. 앞에서 이미 개념은 알았으니 툴의 사용 화면 캡쳐와 간단한 설명으로 쉽게 넘어갈 수 있으리라 본다. 엔터프라이즈, 컴퓨터, 사용자, 응용 프로그램 레벨별로 보안 설정이 가능하나 여기서는 주로 사용되는 컴퓨터 레벨의 보안 정책을 구성해보겠다. 다른 레벨의 정책도 동일하게 방법으로 구성될 수 있다. 순서는 간단하다. 다음..
02. 관리 - 보안 관리 2006.04.23 21:42

[연재] 4. 보안 정책(Security Policies)

4. 보안 정책(security policies) 증거들은 그 자체만으로는 의미가 없고 PC에 설정된 보안 정책을 평가해서 그 증거들에 어떤 권한을 부여되는가 즉 어셈블리에 어떤 권한이 부여되는가에 따라서 어셈블리가 로딩도 될 수 있고 코드를 정상적으로 실행할 수 있는 가도 결정된다. 각 PC의 보안 정책은 .config 파일에 저장된다. 이 파일에는 어셈블리의 증거별 권한 집합이 정의되어 있다. 각 PC의 보안정책에는 “이 PC에서는 어떤 증거에 대해서는 어떤 권한을 부여하겠다”는 정책이 표현되어 있는 것이다. 보안 정책 파일은 사용자(관리자, 개발자)가 편집해서 적절한 보안 정책을 PC에 적용할 수 있다. .NET의 SDK와 함께 제공되는 구성 편집 툴이 있는데, 이것을 사용하면 쉽게 보안 정책을 편..
02. 관리 - 보안 관리 2006.04.23 21:42

[연재] 3. 증거(evidence)

3. 증거(evidence) 권한 풀이기(permission resolver)는 어셈블리를 로딩하면서 그것에 대한 증거를 수집하게 된다. 이런 증거들은 .config 파일에 있을 수 있고(CODEBASE) 또는 어셈블리가 가지고 있는 메너페스트 등에도 있을 수 있다. 다음 그림은 .NET에서 사용하는 증거들을 “어디서 왔는가”에 사용되는 증거들, “누가 만들었는가”에 사용되는 증거들 그리고 기타 증거들로 분류해 놓고 있다. .NET의 7가지 증거(v2.0 기준) .NET에서는 그림에 나타난 것처럼 기본적으로 8가지 증거를 확인한다. 어디서 왔는가? 누가 만들었는가?를 판단하는데 사용되는 증거들을 구분해서 보여주고 있다. 기타에 있는 해시값은 관리자가 어셈블리 파일을 배포한 이후 임의의 코드 변경(해킹)이..
02. 관리 - 보안 관리 2006.04.23 21:41

[연재] 2. 보안 정책 평가( 권한 풀이)프로세스

2. 정책 평가 / 권한 부여 프로세스 어셈블리가 어디서 왔고, 누가 만들었는지에 대한 정보를 어셈블리의 증거(evidences)라고 한다. 이런 어셈블리가 제시하는 증거들을 근거로 해서 어셈블리가 부여받을 수 있는 권한 집합(permission set)을 결정하게 되는데, 이런 과정을 정책 평가(policy evaluation)라고 한다. 대신에 달봉이는 권한 풀이(permission resolving)라는 말로도 표현한다. 증거들을 근거로 해서 어셈블리의 권한을 결정할 수 있으려면, 증거별 권한(permission)을 평가, 부여할 수 있는 정책이 PC에 정의되어 있어야 할 것이다. 이런 정의를 보안 정책(security policy)라고 하며 보안 정책에 대한 내용은 .config 파일에 XML 포..
02. 관리 - 보안 관리 2006.04.23 21:41

[연재] 1. CAS(Code Access Security)란?

1. CAS(Code Access Security)란? 스마트클라이언트 애플리케이션에서는 배포와 함께 가장 이슈로 떠오르는 문제가 바로 보안의 문제이다. 어셈블리가 외부로부터 다운되기 때문에 어떻게 외부 코드로부터 로컬 PC의 자원을 보호하느냐가 문제가 되는 것이다. 기존의 사용자 중심의 보안체계로는 이 경우를 대처할 수 없게 된다. 사용자 중심의 보안 체계라는 것은 사용자별로 계정이 있고 그 계정에 권한을 부여하는 방식이었다. 따라서 윈도우상에서 보안을 판단할때는 이 사용자(즉 이 계정)를 기반으로해서 현재의 프로세스를 실행시킬 수 있느냐 없느냐를 체크했다. 사용자 계정 중심의 보안 체계에서는 인터넷에서 프로그램을 다운, 설치를 사용자가 한번만 승인하게 되면 이 코드는 현재 로그인된 사용자의 계정 권한..
02. 관리 - 보안 관리 2006.04.23 21:41

AllowPartiallyTrustedCallers 어트리뷰트

로컬 PC 외부에서 들어오는 어셈블리는 로컬 PC의 어셈블리들과는 달리 권한에 있어서 제한을 받는다. 이렇게 완전한 권한을 부여받지 못한 어셈블리를 이름하여 부분적으로 신뢰를 받는 어셈블리(partially trusted assembly)라고 한다. FullTrust 권한을 부여받지 못했다면 Everything 권한 집합을 부여받은 어셈블리할지라도 부분적으로 신뢰를 받는 어셈블리에 속하게 된다. .NET CLR은 기본적으로 강력한 이름의 어셈블리(strong named assembly)는 완전한 권한을 갖는 어셈블리만이 호출할 수 있도록 하고 있다. 그러나 강력한 이름의 어셈블리가 AllowPartiallyTrustedCallersAttribute(APTC) 어셈블리 어트리뷰트를 사용하게 되면 부분 신뢰..
02. 관리 - 보안 관리 2006.04.23 21:24

Introduction to Code Signing

ClickOnce의 배포를 이야기하면서 Authenticode에 대한 이야기가 나와서 그 원리를 함 알아보려고 했다. 달봉이도 Authenticode에 대해서는 잘 모른다. 혹시라도 잘못된 곳이 있으면 사정없는 댓글에 대한 희망을 전한다. Introduction to Code Signing 요약 ■ 코드 사인(code singing) 소개 인터넷으로 파일 다운로드하는 경우, 두 종류의 보안 이슈가 발생한다. 1. 게시자의 신뢰성 확인(Ensuring authenticity) - 누가 게시했나? 즉 게시한 사람은 믿을 수 있나? 2. 코드의 무결성 확인(Ensuring integrity) - 게시 이후 코드(소프트웨어)는 변경되지 않았나? Authenticode는 이런 이슈를 해결하기 위한 Microsof..
02. 관리 - 보안 관리 2006.04.23 21:23

GAC에 있는 어셈블리는 FullTrust권한을 부여하나?

v2.0의 CodeGroup의 멤버 조건을 보면 "GAC"이라는 것이 하나 더 추가되었다. 이것과 관련해서 잠시 정리해 두려 한다. Q : GAC에 등록된 어셈블리는 항상 FullTrust 권한을 부여받을까? A : 상황에 따라 다르다. v1.X에서는 GAC에 등록된 어셈블리도 MyComputer 영역의 어셈블리도 간주해서 MyComputer 영역의 권한셋인 FullTrust 를 부여받았다. 그래서 MyComputer 코드 그룹의 권한을 변경하면 GAC에 등록된 어셈블리의 권한도 함께 변하게 되었다. 그러나 v2.0에서는 GacMembershipCondition을 추가하고 있다. 추가된 멤버 조건 : GAC 이 조건을 사용하면 GAC에 등록된 어셈블리는 MyComputer 영역의 권한셋과는 별도의 권한을..
02. 관리 - 보안 관리 2006.04.23 21:18