IT 살이/03. 관리 - 보안 관리 썸네일형 리스트형 비스타 첫 체험기. 비스타 니가 뭔데. 쫌~ 비스타 니가 뭔데. 쫌~. 비스타로 하도 떠들썩하길래, 지금 프로젝트가 끝나기 전에 미리 함 체험해 볼 생각으로 설치해보기로 했다. 진행중인 프로젝트의 개발때문에, Windows 2003 서버도 필요했다. 자금 문제 때문에 노트북을 하나 더 구매할 수는 없고, 해서 하나의 노트북에 Virutal PC 2007을 이용해서 같이 설치하기로 했다. 처음에는 노트북의 메인 OS로 비스타를 설치했다. 처음 생각과는 달리 Visual Studio를 비스타에 설치해 보기로 했다. 그래서 왠만하면 지금 프로젝트 솔루션을 비스타에서 구성해서 계속 개발을 해 보기로 했다. 그리고 Virtual PC에는 Windows 2003을 설치해서 아직 비스타에서 실행되지 않는 프로그램들도 있다고 하니 그런 것들은 2003에 설치할려.. 더보기 [연재] 8. 보안 요청 8. 보안 요청 보호된 리소스를 직접 액세스하는 코드를 작성하거나 이러한 액세스가 호출자에게 노출되는 경우, 호출하는 코드(어셈블리)에 권한이 있는지를 확인하는 요청을 작성할 수 있다. 호출자에 의한 호출이 실제로 수행되기 전에 이런 요청에 대한 권한 체크를 먼저 통과해야 한다. 이런 권한 요청은 어트리뷰트를 사용한 선언적인 방법을 사용할 수도 있고 또는 메소드를 통해서 프로그램적 요청을 사용할 수 있다. 대부분의 .NET Framework 클래스에는 자신과 연결된 요청이 이미 있으므로 보호된 리소스에 액세스하는 클래스를 사용할 때마다 요청을 추가할 필요가 없다. 예를 들어, StreamWriter 클래스는 열릴 때마다 자동으로 FileIOPermission에 대한 보안 요청을 한다. StreamWrit.. 더보기 [연재] 7. 보안 정책 배포 7. 보안 정책 배포 지금까지의 과정, 권한 그룹 생성, 코드 그룹 생성 및 세부 사항 편집은 모두 프로그램적으로도 가능하다. 따라서 클라이언트 보안을 설정하는 exe 프로그램을 제작해서 사용자들에게 배포하면 된다. 그러자면 CAS와 관련한 API를 숙지하고 있어야 할 것이다. 그러나 관리 툴은 그보다 간단한 배포 방법을 제공해주고 있다. 이 방법을 사용하면 보안 편집 툴로 편집한 내용을 .msi 파일로 자동 생성해준다. 이 .msi 파일을 사용자들에게 배포만 하면 된다. 관리 툴을 이용한 보안 정책 배포 #1 런타임 보안 정책(오른쪽 클릭)->배포 패키지 만들기…를 선택한다. 관리 툴을 이용한 보안 정책 배포 #2 이 화면에서 배포할 보안 정책 수준을 선택할 수 있다. 그리고 .msi 파일명을 입력하고.. 더보기 [연재] 6. 보안 정책 설정 예 6. 보안 정책 설정 예다음은 관리툴을 사용해서 보안 정책을 배포하는 예제를 보겠다. 이 보안 정책에서는 부모와 자식, 2 계층 구조의 코드 그룹을 생성해서 권한 집합을 확대하는 방법을 보이겠다. 그리고 앞에서 생략한 사용자가 직접 권한 집합을 만드는 예도 더불어 본다. ■ 권한 집합 생성먼저 코드그룹에서 사용할 권한 집합을 "SCPermissionSet'이라는 이름으로 미리 하나 만들어두자. 집합을 새로 생성하려면 권한에 대한 자세한 내용을 알고 있어야 한다. 그러나 현실적으로 엔터프라이즈 애플리케이션을 개발하는 개발자들이 권한 집합을 생성하거나 편집하면서 개발할 시간은 거의 없다. 따라서 개발자시에는 주로 이미 만들어진 FullTrust 권한 집합을 사용하는 것이 보통이다. 권한 집합 생성 #1 생성.. 더보기 [연재] 5. 보안 설정 편집 5. 보안 설정 편집 이제 개념적인 내용을 알았으니 PC의 보안 설정을 편집하는 방법을 알아보자.이곳에서는 어셈블리가 실행될 컴퓨터에 코드 그룹을 생성하고 그룹에 권한을 매핑하는 작업을 권한 관리 툴을 이용하는 방법을 보여준다. 툴을 사용해서 편집한 보안 내용은 .config 파일에 저장될 것이고 어셈블리가 로딩될 때 정책 평가기에 의해서 해석되어서 어셈블리에 설정된 권한을 부여할 것이다. 앞에서 이미 개념은 알았으니 툴의 사용 화면 캡쳐와 간단한 설명으로 쉽게 넘어갈 수 있으리라 본다. 엔터프라이즈, 컴퓨터, 사용자, 응용 프로그램 레벨별로 보안 설정이 가능하나 여기서는 주로 사용되는 컴퓨터 레벨의 보안 정책을 구성해보겠다. 다른 레벨의 정책도 동일하게 방법으로 구성될 수 있다. 순서는 간단하다. 다음.. 더보기 [연재] 4. 보안 정책(Security Policies) 4. 보안 정책(security policies) 증거들은 그 자체만으로는 의미가 없고 PC에 설정된 보안 정책을 평가해서 그 증거들에 어떤 권한을 부여되는가 즉 어셈블리에 어떤 권한이 부여되는가에 따라서 어셈블리가 로딩도 될 수 있고 코드를 정상적으로 실행할 수 있는 가도 결정된다. 각 PC의 보안 정책은 .config 파일에 저장된다. 이 파일에는 어셈블리의 증거별 권한 집합이 정의되어 있다. 각 PC의 보안정책에는 “이 PC에서는 어떤 증거에 대해서는 어떤 권한을 부여하겠다”는 정책이 표현되어 있는 것이다. 보안 정책 파일은 사용자(관리자, 개발자)가 편집해서 적절한 보안 정책을 PC에 적용할 수 있다. .NET의 SDK와 함께 제공되는 구성 편집 툴이 있는데, 이것을 사용하면 쉽게 보안 정책을 편.. 더보기 [연재] 3. 증거(evidence) 3. 증거(evidence) 권한 풀이기(permission resolver)는 어셈블리를 로딩하면서 그것에 대한 증거를 수집하게 된다. 이런 증거들은 .config 파일에 있을 수 있고(CODEBASE) 또는 어셈블리가 가지고 있는 메너페스트 등에도 있을 수 있다. 다음 그림은 .NET에서 사용하는 증거들을 “어디서 왔는가”에 사용되는 증거들, “누가 만들었는가”에 사용되는 증거들 그리고 기타 증거들로 분류해 놓고 있다. .NET의 7가지 증거(v2.0 기준) .NET에서는 그림에 나타난 것처럼 기본적으로 8가지 증거를 확인한다. 어디서 왔는가? 누가 만들었는가?를 판단하는데 사용되는 증거들을 구분해서 보여주고 있다. 기타에 있는 해시값은 관리자가 어셈블리 파일을 배포한 이후 임의의 코드 변경(해킹)이.. 더보기 [연재] 2. 보안 정책 평가( 권한 풀이)프로세스 2. 정책 평가 / 권한 부여 프로세스 어셈블리가 어디서 왔고, 누가 만들었는지에 대한 정보를 어셈블리의 증거(evidences)라고 한다. 이런 어셈블리가 제시하는 증거들을 근거로 해서 어셈블리가 부여받을 수 있는 권한 집합(permission set)을 결정하게 되는데, 이런 과정을 정책 평가(policy evaluation)라고 한다. 대신에 달봉이는 권한 풀이(permission resolving)라는 말로도 표현한다. 증거들을 근거로 해서 어셈블리의 권한을 결정할 수 있으려면, 증거별 권한(permission)을 평가, 부여할 수 있는 정책이 PC에 정의되어 있어야 할 것이다. 이런 정의를 보안 정책(security policy)라고 하며 보안 정책에 대한 내용은 .config 파일에 XML 포.. 더보기 [연재] 1. CAS(Code Access Security)란? 1. CAS(Code Access Security)란? 스마트클라이언트 애플리케이션에서는 배포와 함께 가장 이슈로 떠오르는 문제가 바로 보안의 문제이다. 어셈블리가 외부로부터 다운되기 때문에 어떻게 외부 코드로부터 로컬 PC의 자원을 보호하느냐가 문제가 되는 것이다. 기존의 사용자 중심의 보안체계로는 이 경우를 대처할 수 없게 된다. 사용자 중심의 보안 체계라는 것은 사용자별로 계정이 있고 그 계정에 권한을 부여하는 방식이었다. 따라서 윈도우상에서 보안을 판단할때는 이 사용자(즉 이 계정)를 기반으로해서 현재의 프로세스를 실행시킬 수 있느냐 없느냐를 체크했다. 사용자 계정 중심의 보안 체계에서는 인터넷에서 프로그램을 다운, 설치를 사용자가 한번만 승인하게 되면 이 코드는 현재 로그인된 사용자의 계정 권한.. 더보기 AllowPartiallyTrustedCallers 어트리뷰트 로컬 PC 외부에서 들어오는 어셈블리는 로컬 PC의 어셈블리들과는 달리 권한에 있어서 제한을 받는다. 이렇게 완전한 권한을 부여받지 못한 어셈블리를 이름하여 부분적으로 신뢰를 받는 어셈블리(partially trusted assembly)라고 한다. FullTrust 권한을 부여받지 못했다면 Everything 권한 집합을 부여받은 어셈블리할지라도 부분적으로 신뢰를 받는 어셈블리에 속하게 된다. .NET CLR은 기본적으로 강력한 이름의 어셈블리(strong named assembly)는 완전한 권한을 갖는 어셈블리만이 호출할 수 있도록 하고 있다. 그러나 강력한 이름의 어셈블리가 AllowPartiallyTrustedCallersAttribute(APTC) 어셈블리 어트리뷰트를 사용하게 되면 부분 신뢰.. 더보기 Introduction to Code Signing ClickOnce의 배포를 이야기하면서 Authenticode에 대한 이야기가 나와서 그 원리를 함 알아보려고 했다. 달봉이도 Authenticode에 대해서는 잘 모른다. 혹시라도 잘못된 곳이 있으면 사정없는 댓글에 대한 희망을 전한다. Introduction to Code Signing 요약 ■ 코드 사인(code singing) 소개 인터넷으로 파일 다운로드하는 경우, 두 종류의 보안 이슈가 발생한다. 1. 게시자의 신뢰성 확인(Ensuring authenticity) - 누가 게시했나? 즉 게시한 사람은 믿을 수 있나? 2. 코드의 무결성 확인(Ensuring integrity) - 게시 이후 코드(소프트웨어)는 변경되지 않았나? Authenticode는 이런 이슈를 해결하기 위한 Microsof.. 더보기 GAC에 있는 어셈블리는 FullTrust권한을 부여하나? v2.0의 CodeGroup의 멤버 조건을 보면 "GAC"이라는 것이 하나 더 추가되었다. 이것과 관련해서 잠시 정리해 두려 한다. Q : GAC에 등록된 어셈블리는 항상 FullTrust 권한을 부여받을까? A : 상황에 따라 다르다. v1.X에서는 GAC에 등록된 어셈블리도 MyComputer 영역의 어셈블리도 간주해서 MyComputer 영역의 권한셋인 FullTrust 를 부여받았다. 그래서 MyComputer 코드 그룹의 권한을 변경하면 GAC에 등록된 어셈블리의 권한도 함께 변하게 되었다. 그러나 v2.0에서는 GacMembershipCondition을 추가하고 있다. 추가된 멤버 조건 : GAC 이 조건을 사용하면 GAC에 등록된 어셈블리는 MyComputer 영역의 권한셋과는 별도의 권한을.. 더보기 구성 섹션 암/복호화 구성파일 (web.config) 암/복호화에 대한 포스트가 있어서 소개합니다. ensimple.net http://www.ensimple.net/enSimple/show.aspx?cnum=87&b_id=study_csharp&page=1 msdn http://msdn2.microsoft.com/ko-kr/library/53tyfkaw.aspx http://msdn2.microsoft.com/ko-kr/library/zhhddkxy.aspx 더보기 이전 1 2 3 다음
