Longhorn의 보안: 최소 권한에 집중

키스 브라운
DevelopMentor

2004년 4월

적용 대상:
   2003 PDC(Professional Developers Conference) "Longhorn" 미리 보기 빌드

요약: Longhorn은 최소 권한 애플리케이션을 위한 훌륭한 플랫폼이 될 것을 약속합니다. 먼저 관리 코드를 작성하여 오늘 시작합니다. 데스크톱 애플리케이션을 빌드할 때 LUA 규격으로 만들고 Windows 애플리케이션 검증 도구 를 사용하여 작업을 검사. (11페이지 인쇄)

콘텐츠

문제
애플리케이션 및 배포 매니페스트
LUA: 최소 권한 사용자 계정
(사용되지 않음) 전원 사용자 그룹
AIM: 애플리케이션 영향 관리
PA: 보호된 관리자
Longhorn의 관리되는 애플리케이션
"위험 없음" 권한 집합
도구
요약

저는 오랫동안 최소한의 권한으로 달리기를 옹호해 왔습니다. 저를 아는 많은 사람들은 개발자가 코드를 개발하는 동안 관리자 권한으로 실행을 중단해야 한다는 제 폭언을 들었습니다. 그래서 2003 년 Microsoft PDC (전문 개발자 컨퍼런스)에서 다음 버전의 Windows® 운영 체제의 기본 목표 중 하나 인 코드 이름 "Longhorn"이 사용자가 최소 권한으로 쉽게 실행할 수 있다는 것을 듣고 매우 기뻤습니다.

문제

로컬 소프트웨어 상점에서 Microsoft Windows XP® Professional 복사본을 구입하여 PC에 설치하면 설치 마법사는 사용자와 컴퓨터를 사용할 다른 모든 사용자를 위한 계정을 만듭니다. Windows XP가 부팅되면 각 사용자의 이름을 표시하고 로그인할 수 있는 매우 환영 화면이 표시됩니다. 이러한 각 사용자는 기본적으로 컴퓨터의 관리자입니다. 그 이유는 사용자 환경이 이렇게 되지 않으면 좋지 않기 때문입니다.

사용자는 컴퓨터에 소프트웨어를 설치할 수 있을 것으로 예상하지만 관리자가 아닌 한 현재 소프트웨어의 90%를 설치할 수 없습니다. 사용자는 소프트웨어가 충돌하지 않고 실행될 것으로 예상하지만, 사용자가 관리자가 아닌 한 소프트웨어의 70%가 제대로 실행되지 않으며 이는 낙관적인 수치입니다. 안타깝게도 많은 수의 애플리케이션이 비관리 환경에서 실패하는 이유는 애플리케이션 상태를 저장할 위치를 잘못 선택하기 때문입니다. Program Files 디렉터리가 상태를 저장하기 위한 장소가 아닙니다. 프로그램(실행 파일)을 저장하기 위한 장소입니다. 애플리케이션 상태를 저장할 위치를 사용자 프로필이라고 하며 공유 사용자 상태를 저장하기 위해 "모든 사용자" 프로필로 충분합니다. Windows 로고 프로그램 지침에서는 이를 설명하지만, 오늘날 대부분의 Windows 소프트웨어는 Windows 로고 지침을 고려하지 않고 개발되었습니다.

그러나 사용자가 관리자가 아닌 사용자, 특히 홈 사용자로 실행해야 하는 이유는 무엇인가요? 글쎄, 실제로 쉽게 할 수 있다면, 홈 사용자는 혜택의 부하를 얻을 것이다. 맬웨어(바이러스, 웜 또는 기타 악성 코드)는 관리 권한을 보유하는 것을 좋아합니다. 웹 서핑 또는 관리자로 전자 메일을 읽는 것은 요즘 그냥 평범한 위험. 당신의 아이들은 어떻습니까? 실수로 무언가를 중단하거나, 스파이웨어를 설치하거나, 부과한 콘텐츠 등급 제한을 제거하지 않는다는 것을 알고 홈 컴퓨터에 게임을 설치하고 플레이할 수 있도록 허용하는 것이 좋지 않을까요? 관리자 권한으로 실행하면 Windows에서 제공하는 대부분의 보안 보호가 효과적으로 해제됩니다. 가정 및 회사 사용자 모두 이러한 보호를 해제해서는 안됩니다. 특히 인터넷에 연결되어 있어 다소 위험한 지역이 되었습니다.

최소 권한 환경에서 실행 중인 사용자와 프로그램을 행복하게 라이브로 전환하면 Windows 플랫폼의 보안이 크게 향상됩니다.

애플리케이션 및 배포 매니페스트

Longhorn이 소개하는 중요한 기능 중 하나는 애플리케이션 및 배포 매니페스트의 개념입니다. 전자를 사용하면 애플리케이션 개발자가 애플리케이션이 제대로 작동하는 데 필요한 사용 권한을 나타낼 수 있으며, 후자는 관리자가 애플리케이션에 얼마나 많은 신뢰를 두는지 지정할 수 있도록 합니다. 이러한 매니페스트에는 이보다 훨씬 더 많은 것이 있지만 관리되는 애플리케이션과 관리되지 않는 애플리케이션 모두에서 사용할 수 있다는 점을 지적하고 싶습니다. 이러한 매니페스트가 존재하는 가장 큰 이유는 사용자가 최소한의 권한으로 애플리케이션을 실행할 수 있도록 돕는 것입니다.

이러한 매니페스트에 대해 자세히 알아보려면 브렌트 렉터의 저서 '개발자를 위한 롱혼'의 1장을 참조하세요.

LUA: 사용자 계정 Least-Privilege

LUA 또는 최소 권한 사용자 계정은 이제부터 Microsoft 프레젠테이션에서 반복해서 볼 수 있는 약어입니다. PDC 2003 발표자는 종종 약어를 "루아"로 발음했습니다. 그것은 아무것도 공상, 심지어 아무것도 정말 새로운. LUA는 대화형 사용자와 서비스 모두에 대해 권한이 없는 사용자 계정을 사용하는 방법을 나타냅니다.

Longhorn 팀은 보안을 단순화하려고 합니다. 그들은 시스템에 대한 액세스의 두 가지 수준이 있어야한다고 생각: 최소 권한, 관리. 심지어 Longhorn에서 Power Users 그룹(일부 원에서는 "admin-lite"이라고 함)을 더 이상 사용하지 않습니다.

Power Users 그룹이 사라지면 애플리케이션 개발자는 실제로 선택해야 합니다. 그들은 Longhorn에 애플리케이션에 필요한 두 가지 수준의 권한(LUA 또는 관리) 중 어느 것을 결정해야 합니다. 애플리케이션에 관리 권한이 필요하지 않은 경우 최소 권한 계정으로 작동하도록 신중하게 작성해야 합니다. 즉, 일반 사용자 계정을 사용하여 테스트(그리고 하나의 희망, 심지어 코드 작성)를 의미합니다. 예를 들어 LUA 애플리케이션은 프로그램 파일 디렉터리 트리가 아닌 사용자 프로필과 같은 안전한 위치에 데이터 파일을 작성해야 합니다. 그러나 Longhorn용으로 다시 작성되지 않은 애플리케이션은 어떻게 되나요? 이러한 애플리케이션이 Windows XP에서도 최소 권한 계정에서 잘 실행되지 않는 경우 어떻게 해야 하나요? AIM(Application Impact Management)이라는 Longhorn 기능은 곧 볼 수 있듯이 이러한 앱이 LUA에서 실행되는 데 도움이 될 수 있습니다.

(사용되지 않음) 전원 사용자 그룹

"높은" 액세스 권한이 있는 관리 계정과 "낮은" 액세스 권한이 있는 일반 사용자 계정을 생각하면 Power User 계정에 "보통" 액세스 권한이 있다고 할 수 있습니다. Power Users 그룹은 일반적으로 최소 권한 계정(즉, 관리자 또는 Power Users와 같은 권한 있는 그룹의 멤버 자격을 보유하지 않는 일반 사용자 계정)으로 제한되는 파일 시스템 및 레지스트리의 일부를 읽고 쓸 수 있습니다. 일반 사용자로 실행하려고 시도한 많은 사람들이 너무 많은 소프트웨어가 실패하여 Power Users 그룹에 계정을 추가하기로 결정하여 거의 모든 문제를 해결했음을 발견했습니다. 그러나 그들은 더 이상 최소한의 권한으로 진정으로 실행되지 않았습니다. 예를 들어 Windows XP에서 이 "중간" 수준의 권한으로 실행되는 모든 맬웨어는 Program Files 디렉터리에 저장된 다른 애플리케이션을 손상시키고 신뢰할 수 있는 COM 구성 요소를 트로이 목마로 바꿀 수 있습니다. 다음에 사용자가 이러한 손상된 컴퓨터에서 관리 계정으로 실행될 때 이전에 설치된 트로이 목마를 통해 맬웨어가 실행되도록 할 수 있습니다. 따라서 Power User로 실행되는 실제 보호를 받지 않습니다.

AIM: 애플리케이션 영향 관리

Longhorn 팀은 최소한의 권한으로 실행하는 것이 중요하다고 믿습니다. 이러한 시작 화면에는 주로 최소 권한 계정으로 구성된 사용자 계정 목록이 포함되기를 원합니다. 그러나 그들은 또한 그들의 발이 현실에 접지되어 있습니다. 오늘날 많은 주요 소프트웨어가 Windows 로고 프로그램을 완전히 무시하는 것처럼 Longhorn 기간의 많은 주요 소프트웨어도 LUA 이니셔티브를 무시할 수 있습니다. 정보 없는 애플리케이션 개발자는 Program Files 디렉터리 트리에서 데이터 파일을 읽고 쓰는 소프트웨어를 계속 작성합니다. 또한 HKEY_CURRENT_USER 대신 HKEY_LOCAL_MACHINE 레지스트리 데이터를 계속 작성합니다. 전자는 일반 사용자에 의해 쓰기에 대 한 제한을 해제, 그래서 후자는 애플리케이션 설정을 저장 하는 것이 좋습니다., 레지스트리를 전혀 사용 해야 하는 경우.

Windows XP에서 애플리케이션에 더 많은 권한이 필요하다는 것을 감지할 수 있는 경우(드문 경우지만 설치 프로그램에서 가끔 발생함) 애플리케이션을 실행하려면 관리자 권한이 없는 사용자에게 관리 권한이 필요하고 관리자 계정의 사용자 이름과 암호를 수집하는 대화 상자를 편리하게 표시합니다. 그러면 프로그램이 지정된 계정으로 실행됩니다. 그러나 많은 애플리케이션이 한 계정에 설치되고 다른 계정으로 사용되지 않기 때문에 항상 작동하지는 않습니다.

롱혼은 완전히 다른 접근 방식을 취합니다. 애플리케이션이 제대로 작동할 수 있도록 사용자가 권한을 높이도록 장려하는 대신 Longhorn은 LUA에서 애플리케이션을 실행하는 것을 선호합니다. 그러나 애플리케이션이 HKEY_LOCAL_MACHINE 또는 Program Files 디렉터리 트리에 쓰려고 하면 어떻게 되나요? Longhorn은 쓰기 시 복사 전략을 사용하여 애플리케이션에 변경하려는 리소스에 대한 자체 가상화된 보기를 제공합니다. 애플리케이션이 프로그램 파일 디렉터리의 파일에 쓰려고 하면 Longhorn은 애플리케이션에 파일의 프라이빗 복사본을 제공하고 파티할 수 있습니다. 이러한 방식으로 AIM 시나리오에서 느슨해지는 모든 맬웨어는 프로그램 파일 디렉터리 트리에서 일반적으로 사용되는 실행 파일을 덮어쓰려고 시도할 수 WINWORD.EXE. 그러나 덮어쓰게 될 것은 맬웨어만 볼 수 있는 프라이빗 복사본입니다. 사용자에게 표시되는 WINWORD.EXE 버전은 여전히 원래의 오염되지 않은 버전입니다.

AIM에 의존하여 저장하지 마세요. 첫날부터 LUA에서 실행할 애플리케이션을 작성합니다.

PA: 보호된 관리자

LUA에서 실행하기 위해 Longhorn 기간에 모든 애플리케이션을 수정해야 하더라도 실제로 관리 권한이 필요한 애플리케이션이 계속 존재합니다. 여기에는 백업 소프트웨어, 하드 드라이브 조각 모음 및 재분할 소프트웨어, 엔터프라이즈 관리 소프트웨어와 같은 유틸리티가 포함되며 목록은 계속됩니다. 따라서 어떤 시점에서 사용자는 특정 작업을 완료하기 위해 관리 계정을 사용해야 합니다. 그리고 그것을 직면하자, 많은 사람들이 LUA 계정을 만들고 단순히 관리자로 모든 시간을 실행하는 조언을 무시합니다.

Longhorn 팀은 관리 계정으로 실행할 때 사용자를 보호하기 위해 깔끔한 계획을 고안했습니다. 이 기능은 보호된 관리자라는 기능이며, 이 기능이 켜져 있으면 항상 관리 계정으로 실행하고 합리적으로 안전하다고 느낄 수 있습니다. 실행하는 대부분의 애플리케이션은 LUA 시나리오에 있는 것과 유사한 토큰인 특수 제한된 토큰으로 실행되기 때문입니다. "축복"을 받은 애플리케이션 또는 회사에서 신뢰할 수 있는 것으로 배포하고 지정한 애플리케이션만 전체 관리 토큰으로 실행됩니다. 애플리케이션을 신뢰할 수 있는 것으로 지정하는 한 가지 방법은 배포 매니페스트에 서명하는 것입니다. 이 정보가 왜 중요할까요? 예를 들어 보겠습니다.

일반적으로 관리자로 실행되는 사용자는 Longhorn 전자 메일 클라이언트를 열고 전자 메일 검색을 시작합니다. 그녀는 자신이 아는 누군가로부터 온 메일을 우연히 접하고 첨부 파일을 엽니다. 그녀는 그녀의 친구가 최근에 전자 메일 웜에 감염되었다는 것을 거의 알지 못하며,이 메시지에는 맬웨어가 포함되어 있습니다. 맬웨어가 실행되면 시스템에 대한 권한이 거의 없다는 것을 알게 됩니다. Program Files 디렉터리 트리에서는 아무것도 수정할 수 없습니다. HKEY_LOCAL_MACHINE COM 개체 등록은 변경할 수 없습니다. 이것은 나쁜 아무것도 할 수 없다고 말하는 것이 아니라 맬웨어가 관리 권한으로 실행되는 경우보다 훨씬 더 나은 상황입니다.

하지만 전자 메일 애플리케이션을 실행할 때 사용자가 관리자 권한으로 실행 중이라고 말하지 않나요? 예, 그건 사실 사실이었다. 그러나 전자 메일 애플리케이션은 "축복받은" 관리 앱으로 지정되지 않았습니다. 실제로 LUA 애플리케이션으로 작성되었습니다. 따라서 제한된 토큰을 받았고 결과적으로 맬웨어도 수신되었습니다. 이것은 최소한의 권한의 전체 지점입니다. 시스템을 제어하지 못하는 경우(실수로 일부 악한 소프트웨어를 실행했거나 잘못된 메뉴 항목을 클릭했기 때문일 수 있음) 손상이 제한되거나 완전히 방지됩니다.

일부 보안에 민감한 관리자는 이미 현재 이 정책을 구현하고 있습니다. 나는 그들 중 하나입니다. 나는 두 개의 계정을 가지고, 정상적인 하나와 관리 하나. 컴퓨터에서 가상 디렉터리를 추가하고, Microsoft SQL™ Server에서 데이터베이스를 만드는 instance 위해 어떤 식으로든 시스템을 관리해야 할 때 일반 사용자로 로그인하고 가끔 관리 계정으로 전환합니다. (당신이 궁금해하는 경우, 나는 소프트웨어를 개발할 때에도, 일반 사용자로 실행 내 시간의 약 95 %를 지출 결국.) Longhorn 팀은 보호된 관리자(PA) 기능에서 종종 "적절한 시기에 적절한 권한"이라는 아이디어인 이 접근 방식을 공식화했습니다. 즉, 항상 관리자로 실행할 수 있지만 여전히 최소 권한으로 실행될 수 있습니다. 더 이상 앞뒤로 전환하지 않고 두 개의 사용자 프로필을 저글링하는 등의 작업을 할 수 없습니다.

이 방법이 깔끔한 아이디어처럼 들리고 사람들이 이 기능을 실제로 사용할 수 있도록 하려는 경우 최소 권한으로 실행되는 애플리케이션을 작성하는 데 진지해야 합니다. 이 기능을 사용하도록 설정하면 관리자가 실행하는 경우에도 실제로 필요한 것보다 더 많은 권한이 필요한 애플리케이션이 신뢰할 수 있는 관리 애플리케이션으로 지정되지 않는 한 불필요하게 중단됩니다. 물론 AIM은 복구에 올 수 있지만, Microsoft는 애플리케이션의 20%가 AIM을 통해 LUA를 호환할 수 없을 것으로 예상하기 때문에 이를 의존해서는 안 됩니다. 이 20%에 속하는 경우 애플리케이션이 실행되지 않습니다. 이 경우 아무도 보호된 관리 기능을 사용하지 않으며 이는 매우 슬픈 일입니다.

최소 권한으로 실행되는 더 많은 애플리케이션이 작성됨에 따라 다른 이점이 나타날 것입니다. 예를 들어 기업은 마침내 워크스테이션을 잠글 수 있으므로 직원이 최소 권한 계정으로 실행할 수 있습니다. 이렇게 하면 관리가 크게 간소화되고 비용이 절감됩니다. 이제 그 어느 때보다 최소한의 권한으로 실행되는 애플리케이션을 작성하는 것이 중요합니다. 이 플랫폼에서 차이를 만들 수 있습니다.

Longhorn의 관리되는 애플리케이션

PDC 2003의 메시지 중 하나는 관리되는 애플리케이션이 미래라는 것이었습니다. 관리 코드를 작성하면 Windows 플랫폼에서 보안의 최신 혁명인 코드 ID를 통한 보안을 활용할 수 있습니다. CLR(공용 언어 런타임)에서 제공하고 CAS 또는 "코드 액세스" 보안이라고도 하는 증거 기반 보안 시스템을 사용하면 CLR이 어디에서 왔는지, 누가 서명했는지 등에 따라 코드에 추가 제한을 적용할 수 있습니다. 이렇게 보안 차원이 추가되면 소프트웨어 배포를 위한 새로운 방법이 열립니다. 이제 클라이언트는 보안 샌드박스에서 코드를 실행하여 중앙 서버에서 다운로드한 코드를 자신 있게 실행하여 "터치 없음" 및 "한 번 클릭" 배포와 같은 기능을 구현하여 관리 비용을 더욱 줄일 수 있습니다. 그리고 배포 및 보안 위험이 비슷한 경우 컴퓨터에서 실행되는 실제 Windows 애플리케이션을 브라우저 기반 애플리케이션에 선호하지 않는 사람은 누구일까요?

Longhorn에서 관리되는 각 애플리케이션은 애플리케이션 매니페스트를 통해 작동하기 위해 필요한 특정 권한을 나타낼 수 있습니다. 코드 목록 1은 마법사에서 생성된 기본 "Longhorn 애플리케이션" 프로젝트를 빌드할 때 생성된 예제 매니페스트를 보여 줍니다. TrustInfo 섹션 및 해당 섹션에 표현된 사용 권한 집합을 확인합니다. 애플리케이션이 실행해야 하는 권한입니다.

코드 목록 1. 애플리케이션 매니페스트

<?xml version="1.0" encoding="utf-8"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" 
manifestVersion="1.0" xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="urn:schemas-microsoft-com:asm.v1 
assembly.adaptive.xsd">
  <assemblyIdentity name="MyLonghornApp" version="1.0.0.0" 
processorArchitecture="x86" asmv2:culture="en-us" 
publicKeyToken="0000000000000000" />
  <entryPoint name="main" xmlns="urn:schemas-microsoft-com:asm.v2" 
dependencyName="MyLonhornApp">
    <commandLine file="MyLonghornApp.exe" parameters="" />
  </entryPoint>
  <description asmv2:iconFile="App.ico" />
  <TrustInfo xmlns="urn:schemas-microsoft-com:asm.v2" 
xmlns:temp="temporary">
    <Security>
      <ApplicationRequestMinimum>
        <PermissionSet class="System.Security.PermissionSet" 
version="1" ID="SeeDefinition">
          <IPermission 
class="System.Security.Permissions.FileDialogPermission" version="1" 
Unrestricted="true" />
          <IPermission class="System.Security.Permissions.IsolatedStorageFilePermission" 
version="1" Allowed="DomainIsolationByUser" UserQuota="5242880" />
          <IPermission 
class="System.Security.Permissions.SecurityPermission" version="1" 
Flags="Execution" />
          <IPermission class="System.Security.Permissions.UIPermission" 
version="1" Window="SafeTopLevelWindows" Clipboard="OwnClipboard" />
          <IPermission 
class="System.Drawing.Printing.PrintingPermission, System.Drawing, 
Version=1.2.3400.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" 
version="1" Level="SafePrinting" />
          <IPermission class="MSAvalon.Windows.AVTempUIPermission, 
PresentationFramework, Version=6.0.4030.0, Culture=neutral, 
PublicKeyToken=a29c01bbd4e39ac5" version="1" 
NewWindow="LaunchNewWindows" FullScreen="SafeFullScreen" />
        </PermissionSet>
        <DefaultAssemblyRequest PermissionSetReference="SeeDefinition" 
/>
      </ApplicationRequestMinimum>
    </Security>
  </TrustInfo>
  <dependency asmv2:name="MyLonghornApp">
    <dependentAssembly>
      <assemblyIdentity name="MyLonghornApp" version="0.0.0.0" 
processorArchitecture="x86" />
    </dependentAssembly>
    <asmv2:installFrom codebase="MyLonghornApp.exe" 
hash="28c18a303c7fb7e9fe43a32b456f0932f52125a9" hashalg="SHA1" 
size="110592" />
  </dependency>
</assembly>

LUA 규격 관리 애플리케이션에는 항상 이와 같은 섹션이 포함되며 Longhorn의 신뢰 관리자는 이 정보를 사용하여 애플리케이션을 컴퓨터에 설치할 수 있는지 여부를 결정합니다. 애플리케이션이 신중하게 코딩된 경우 신뢰 관리자가 "위험 없음" 점수를 할당할 수 있는 낮은 권한으로 실행할 수 있으며, 애플리케이션을 즉시 설치하고 사용자 개입 없이 실행할 수 있습니다. 그러나 애플리케이션이 요청하는 권한에 따라 더 위험한 위험 등급의 점수를 지정하면 사용자에게 애플리케이션이 제기하는 잠재적 위험을 설명하는 대화 상자가 표시됩니다. 그런 다음 사용자는 애플리케이션을 설치하고 실행할 수 있도록 허용할지 여부를 선택할 수 있습니다.

매니페스트에서 의도를 미리 알리는 것은 좋은 생각입니다. 그렇지 않은 경우 신뢰 관리자는 애플리케이션에 대해 최악의 경우만 가정할 수 있으며 사용자에게 표현된 위험 등급은 더욱 사악해 보일 수 있기 때문입니다. 따라서 매니페스트에 필요한 권한을 표현하는 것이 좋습니다. 이 단계를 건너뛰지 마세요.

PDC 2003에서 언급한 연구에서 Microsoft는 ActiveX 컨트롤 다운로드 경고와 같은 보안 대화 상자가 표시될 때 사용자의 40%가 항상 "아니요"를 클릭하는 것으로 나타났습니다. 인터넷을 통해 사용자에게 소프트웨어를 배포하려는 경우 Longhorn의 신뢰 관리자로부터 "위험 없음"의 위험 등급을 기대하므로 애플리케이션을 설치하고 실행하기 전에 사용자에게 메시지가 표시되지 않습니다. 따라서 항상 "위험 없음"으로 채점되는 문서화된 권한 집합이 있는지 궁금할 수 있습니다. 이러한 정의가 있으며 이를 SEE 권한 집합이라고 합니다.

"위험 없음" 권한 집합

PDC 2003에서 SEE (보안 실행 환경)라고 하는 것을 들었을 수도 있지만 대부분의 사람들은 해당 용어가 다소 혼란스럽기 때문에 위험하지 않은 권한 집합이라고 부르기만 하면 됩니다. Longhorn은 항상 Longhorn의 기본 신뢰 관리자와 함께 "위험 없음"의 점수를 매기는 특수 권한 집합과 함께 제공됩니다. 사용 권한 요구 사항이 위험 없음 권한 집합에 완전히 속하는 애플리케이션을 작성하는 경우 트러스트 경고를 전혀 표시하지 않고 설치하고 실행할 수 있습니다. 이 집합 내에서만 권한이 부여된 코드(적어도 Microsoft가 처음에 정의한 대로)는 의도적으로 또는 실수로 컴퓨터에 해를 끼칠 수 없습니다.

따라서 사용자에게 무서운 대화 상자가 표시되지 않고 애플리케이션을 설치하고 실행하려면 이 권한 집합에서 허용하는 활동으로 자신을 제한해야 합니다. Longhorn 팀이 관리자가 이 권한 집합을 구성할 수 있도록 하는 것을 고려하고 있으므로 한 사이트에서 "위험 없음"으로 간주되는 것은 다른 사이트에서 다를 수 있습니다. 그러나 대부분의 Longhorn 설치의 경우 위험 없음 권한 집합은 운영 체제와 함께 제공되는 기본 사용 권한 집합이 됩니다.

어떻게 표시되나요? 코드 목록 1에서 매니페스트를 다시 살펴보세요. TrustInfo 섹션 "SeeDefinition"에 정의된 PermissionSet 에 지정된 ID를 확인합니다.

다음은 PDC 2003 미리 보기 빌드에 대한 위험 없음 권한 집합의 모양입니다. 무제한 FileDialogPermission 을 사용하면 표준 OpenFileDialog 및 SaveFileDialog 클래스를 통해 사용자가 선택한 파일을 읽거나 쓸 수 있지만 사용자가 선택한 파일의 이름을 포함하여 사용자 파일 시스템의 구조에 대해 자세히 알아볼 수는 없습니다. IsolatedStoragePermission을 사용하면 어셈블리가 파일 대화 상자로 메시지를 표시하지 않고도 사용자의 하드 드라이브에서 최대 5MB의 사용자별 상태를 읽고 쓸 수 있습니다. SecurityPermission을 사용하면 코드를 처음부터 실행할 수 있습니다. UIPermission을 사용하면 화면에 그릴 수 있지만 사용자 고유의 창에서만 그릴 수 있으며 클립보드에 대한 제한된 액세스 권한을 부여합니다(프로그래밍 방식으로 내용을 읽을 수는 없지만 사용자가 클립보드에서 컨트롤에 붙여넣을 수 있음). PrintingPermission 을 사용하면 인쇄 대화 상자를 통해 인쇄할 때만 인쇄할 수 있습니다. 사용자가 작업을 수행하고 있다는 사실을 모르면 코드에서 자동으로 인쇄 작업을 시작할 수 없습니다. "Avalon" 관련 권한을 사용하면 코드가 운영 체제에서 제어하는 테두리가 있는 한 전체 화면 창을 만들 수 있습니다(예: 로그인 화면을 스푸핑할 수 없음).

이 정의는 시간이 지남에 따라 거의 확실하게 변경됩니다. 롱혼 베타가 출시되기 전에 변경될 수도 있습니다. 그래서 소금 알갱이로 여기에 내 설명을 가져 가라. 이 문서에서는 위험 없음 권한 집합의 최종 정의에서 신뢰 대화 상자를 피하기 위해 이러한 기능을 사용해야 할 가능성이 매우 높기 때문에 격리된 스토리지 및 일반 대화 상자와 같은 .NET Framework 최소 권한 기능 중 일부를 살펴보도록 동기를 부여하는 데 도움이 될 것입니다.

위험 없음 권한 집합을 정의하는 것은 간단한 작업이 아닙니다. Longhorn 팀은 정의가 너무 제한적이면 애플리케이션이 충분하지 않다는 것을 알고 있습니다. 그러나 너무 관대하면 맬웨어가 확실히 오용됩니다. 하나는 팀이 달콤한 자리를 찾을 수 있기를 바랍니다. 그림 1은 축복받은 관리 애플리케이션부터 SEE 권한 집합으로 실행되도록 설계된 애플리케이션에 이르기까지 Longhorn 애플리케이션에 대한 권한 범위를 보여 주는 다이어그램입니다.

그림 1. 애플리케이션 유형

도구

최소 권한 애플리케이션을 빌드하는 것은 결코 간단하지 않습니다. 도움이 되는 지침과 도구가 있어야 합니다. PDC 2003에서 이러한 도구의 몇 가지 예를 살펴보었는데, 그 중 첫 번째는 Visual Studio® 2005(PDC 2003 기간의 코드 이름 "Whidbey")입니다.

이 새로운 개발 환경은 최소 권한 환경을 더 쉽게 대상으로 지정할 수 있는 다양한 기능을 제공합니다. 예를 들어 애플리케이션을 디버그할 때 적용하려는 권한 집합을 선택할 수 있습니다. Longhorn 애플리케이션을 시작하기에 좋은 곳은 SEE 권한 집합입니다. 기존 애플리케이션의 경우 현재 SEE가 정의되는 방식과 매우 가까운 인터넷 권한 집합을 대상으로 하는 것이 가장 좋습니다.

권한 감소로 디버깅을 시작하면 예기치 않은 SecurityExceptions가 발생할 수 있습니다. 그림 2는 개발자가 파일 대화 상자를 사용하여 사용자에게 파일 이름을 묻는 메시지를 표시한 다음 지정된 파일 이름을 읽으려고 하는 클래식 예제를 보여줍니다. SEE 권한 집합에 있는 것처럼 FileDialogPermission 이 부여되면 사용자에게 파일을 묻는 메시지를 표시할 수 있지만 사용자가 선택한 파일 이름을 볼 수 없습니다. 대신 메서드(OpenFile)를 호출하여 파일에서 읽는 데 사용할 수 있는 스트림을 열어야 합니다. Visual Studio 2005는 개발자가 보안 예외를 방지하기 위해 OpenFileDialog 클래스를 사용하는 올바른 방법을 찾는 데 도움이 되는 조언을 제공합니다.

그림 2. 더 나은 도구 지원

PDC 2003에서 발표된 또 다른 유용한 도구를 PermCalc라고 합니다. 어셈블리를 평가하고 추론을 통해 실행해야 하는 권한을 결정하는 명령줄 도구입니다. 이 기능은 Visual Studio 2005에도 포함할 계획입니다. 이는 최소 권한 환경을 대상으로 하는 좋은 방법입니다. 현재 존재하는 유사한 도구를 Windows 애플리케이션 호환성 도구 키트의 일부인 Windows 애플리케이션 검증 도구라고 합니다. 이 도구는 애플리케이션이 파일 시스템 또는 레지스트리의 보호된 부분에 쓰는 것과 같은 규칙을 위반하는 경우를 감지하는 데 도움이 될 수 있습니다.

요약

Longhorn은 최소 권한 애플리케이션을 위한 훌륭한 플랫폼이 될 것을 약속합니다. 먼저 관리 코드를 작성하여 오늘 시작하세요. 데스크톱 애플리케이션을 빌드할 때 LUA 규격으로 만들고 Windows 애플리케이션 검증 도구를 사용하여 작업을 검사. 가능하면 지금은 인터넷 사용 권한 집합을 대상으로 지정하고 Longhorn이 배송될 때 SEE에 바로 맞을 수 있습니다.

참조 항목

브렌트 렉터의 책, 개발자를위한 "롱 혼"소개를 읽습니다.

작성자 정보

Keith Brown은 애플리케이션 보안을 전문으로 하는 독립 컨설턴트입니다. 그는 프로그래밍 Windows 보안(Addison-Wesley, 2000)라는 책을 저술했으며 .NET 프로그래머를 위한 새로운 보안 책을 쓰고 있습니다. 에서 온라인으로 새 책을 읽어보기 http://www.develop.com/kbrown