출처: http://msdn.microsoft.com/ko-kr/magazine/cc982153.aspx
Windows 파일 및 레지스트리의 사용 권한 이해
John R. Michener
이 기사에서는 다음 내용에 대해 설명합니다.
|
이 기사에서 사용하는 기술: Windows Server 2008 |
목차 시스템에서 어떤 일이 일어나면 매번 주체(사용자나 서비스 대신 작업을 수행하는 프로세스나 스레드)가 개체에 어떤 작업을 수행합니다. 파일, 디렉터리 및 레지스트리 키는 일반적으로 알려진 개체의 예입니다. Windows의 기본 보안 메커니즘에는 작업 진행을 허용하기 전에 신뢰할 수 있는 시스템 구성 요소가 사용 권한과 권한(AccessCheck)을 확인하는 과정이 포함됩니다. 따라서 사용 권한과 권한을 설정하여 시스템 동작을 관리할 수 있습니다. 내부적으로 어떤 일이 일어나는지 이해하지 못하면 사용 권한을 적절하게 설정할 수 없으므로 우선 개체의 보안 설정과 이를 처리하는 방법을 설명한 다음 해당 값을 설정하는 방법을 살펴보겠습니다.
기 술적인 세부 사항으로 들어가기 전에 Windows ACL(액세스 제어 목록) GUI를 사용하여 Windows Server 2008의 시스템 드라이브 루트의 사용 권한을 살펴보겠습니다. Windows 탐색기를 열고 보안 탭을 선택한 다음 로컬 디스크(C:)를 마우스 오른쪽 단추로 클릭하고 속성을 선택하면 관리자가 모든 권한을 가진다는 것을 알 수 있습니다. 그룹이나 사용자 이름에서 SYSTEM을 클릭하면 SYSTEM도 모든 권한을 가진다는 것을 알 수 있습니다. 그룹이나 사용자 이름에서 사용자를 클릭하면 사용 권한 상황이 그리 간단하지 않다는 것을 알 수 있습니다. 그림 1에 있는 시스템의 사용자 그룹은 읽기 및 실행, 목록, 읽기 등의 사용 권한을 가집니다. 고급 단추를 클릭하면 사용자 그룹과 연관된 사용 권한에 대한 더 세부적인 보기가 제공됩니다(그림 2 참조).
그림 1 로컬 디스크 C의 사용자 권한
그림 2 드라이브 C의 사용자 권한에 대한 고급 보기 (더 크게 보려면 이미지를 클릭하십시오.)
여기에서 사용자 그룹의 구성원은 시스템 드라이브의 루트에 폴더를 만들고 파일에 데이터를 추가할 수 있습니다. 편집 단추를 클릭하면 그림 3에 나온 것처럼 하위 폴더에 대한 다른 "특수한" 권한 부여를 볼 수 있습니다. 이 작업에는 관리자 권한이 필요합니다.
그림 3 사용자 특수 권한 편집 보기
따 라서 Windows Server 2008에서는 기본적으로 일반 사용자가 시스템 드라이브의 루트에 하위 폴더를 만들고 이러한 폴더에 콘텐츠를 추가할 수 있습니다. Windows Server 2008에서 사용자 그룹의 구성원에 이 기능이 제공된 이유는 일부 타사 소프트웨어가 이러한 권한을 전제로 동작하기 때문입니다. Microsoft로서는 응용 프로그램 호환성을 깨고 싶지 않았던 것이지요.
이 제 이러한 문제에 대한 기술적인 내용으로 들어가서, 사용자에게 제공되는 GUI 인터페이스의 내부에서 어떤 방식으로 동작하는지 알아보겠습니다. Windows의 모든 명명된 개체에는 보안 설명자가 있습니다. 보안 설명자는 소유자에 대한 정보를 제공하고 지정된 사용 권한이 있는 사용자 및 대상을 나열합니다. 또한 보안 설명자는 어떤 개체에 대한 액세스를 시스템 이벤트 로그에 기록해야 하는지도 지정할 수 있습니다.
대 상(사용자, 프로세스 등)이 개체 또는 리소스에 대해 수행할 수 있는 작업에 대한 정보는 ACL이라는 데이터 구조에 지정됩니다. ACL은 특정 개체에 대해 누가(주체), 어떤 액세스 권한을 가지는지 열거합니다. DACL(임의 ACL)은 개체 소유자가 개체를 변경할 수 있도록 허용하는 ACL 유형입니다. 개체가 액세스될 때마다 요청된 액세스가 허용되는지 확인하기 위해 보안 설명자가 주체의 사용 권한과 비교됩니다.
Windows 는 개체에 대한 SACL(시스템 ACL)도 지원하며, 감사 로그에 어떤 이벤트가 기록되는지 설정하기 위한 용도로 여러 릴리스에 걸쳐 SACL을 사용해왔습니다. Windows Server 2008과 Windows Vista에서는 무결성 수준 정보를 제공하도록 SACL이 확장되었습니다.
이 무결성 레이블은 LowRights Internet Explorer에서 사용되는 Internet Explorer 프로세스를 표시하는 "낮음" 레이블을 설정하는 데 사용됩니다. "시스템"과 "높음" 레이블은 중요한 시스템 리소스를 보호하는 데 사용됩니다. Windows 메시지 펌프는 메시지의 무결성 수준을 바탕으로 메시지를 필터링합니다. 예를 들어 중간 수준 프로세스는 낮은 수준 프로세스에서 보낸 메시지를 받지 않으며, 높은 수준 프로세스는 낮은 또는 중간 수준 프로세스에서 보낸 메시지를 받지 않습니다.
현재로서는 무결성 수준 보호는 보안을 보장할 수 있는 진정한 보안 방어막은 아니며 과속 방지턱에 가깝습니다. 이 방지턱의 높이는 향후 릴리스에서는 더 높아질 예정이며, 그러면 진정한 보안 방어막이 될 수 있을 것입니다.
Windows 는 다른 최신 OS와 마찬가지로 일반적인 액세스 제어 결정을 위해 DACL을 사용합니다. 이번 칼럼에서는 DACL에 초점을 맞추겠습니다. 주체가 개체를 대상으로 작업을 수행하도록 허용되는지 여부를 시스템에서 확인하기 위해서는 몇 가지 항목에 대한 검사가 필요합니다. 주체의 권한, 주체의 토큰, 그리고 개체의 보안 설명자가 이러한 항목에 해당합니다. 개체의 이진 보안 설명자는 주체의 토큰과 함께 AccessCheck 루틴으로 전달됩니다. 요청된 액세스 마스크 비트 벡터가 준비되는데, 이는 액세스 검사에 통과하기 위해 반드시 부여되어야 하는 액세스 권한을 나타냅니다. 이는 주체의 보안 설명자와 함께 AccessCheck 루틴에 전달되며 이 루틴에서는 사용자의 보안 토큰을 검사하고, 주체의 권한(관리자와 같이 일반적으로 역할 또는 멤버 자격에 바탕을 둠)을 요청된 액세스 및 개체의 DACL과 조합하여 고려합니다.
요 청된 액세스가 주체의 권한에 의해 충족되는 경우 액세스가 허용됩니다. 그렇지 않으면 DACL ACE(액세스 제어 항목)가 순서대로 검사됩니다. 요청된 모든 액세스 구성 요소가 허용되는지, 아니면 일부가 거부되는지를 보여줄 수 있게 되는 즉시 보안 시스템은 전자의 경우 성공을 반환하고 후자의 경우 실패를 반환합니다.
따 라서 DACL의 ACE 목록이 올바르게 정렬되어야 합니다. 표준(정식) 정렬은 명시적 거부를 가장 먼저 배치하고 그 다음으로 명시적 허용, 일반(그룹) 거부, 그룹 허용을 차례대로 배치합니다. 정식 정렬을 사용하지 않으면 예상하지 못한 허용이나 거부가 발생할 수 있습니다.
개체 보안 설명자
보 안 설명자는 이진 데이터 구조이지만 사람이 읽을 수 있는 텍스트 형식을 제공하기 위해 보안 설명자 문자열 형식을 사용합니다. 문자열 형식 보안 설명자는 네 가지 기본 구성 요소, 즉 소유자(O:), 주 그룹(G:), DACL(D:) 및 SACL(S:)을 나타내는 토큰이 포함된, null로 끝나는 문자열로 표현됩니다(그림 4 참조).
그림 4 보안 설명자
SID (보안 식별자)는 구문 분석 정보를 제공하도록 구성되며 소유자의 고유 식별자 역할을 하기 위한 임의의 96비트 정보를 포함합니다(32비트의 시퀀스 카운트도 포함할 수 있음). string_ace(문자열 형식으로 표현되는 ACE)는 DACL에서 명시적으로 사용 권한을 부여 또는 거부하고 SACL에서 정책을 설정하는 구조입니다. 각 string_ace는 괄호 안에 포함되며 다음과 같은 구조를 가집니다.
(ace_type;ace_flags;rights;object_guid;inherit_ object_guid;account_sid)
해 당 개체에 대한 올바른 액세스에 필요한 권한 부여만 있어야 합니다. owner_sid와 group_sid는 보안 설명자에서 생략되는 경우가 많습니다. 생성될 때 명시적으로 지정되지 않으면 보안 설명자의 owner 필드는 개체 생성을 호출하는 주체의 SID로 설정됩니다. group 필드는 주체 보안 토큰의 주 그룹으로 설정됩니다. 개체를 감사하거나 무결성 레이블을 설정할 필요가 없는 경우에는 SACL이 제공되지 않습니다.
string_ace 내에는 필요한 필드만 포함됩니다. 최소한의 집합은 ace_type, rights, subject이며 일반적으로 account_sid도 포함됩니다. 일반적으로 object_guid와 inherit_object_guid는 없습니다. 시스템은 액세스가 부여되거나 거부될 때까지 순서대로 ACE를 처음부터 끝까지 구문 분석합니다. 따라서 ACE의 순서가 중요합니다. "사용 권한 거부"가 "사용 권한 허용"보다 앞에 배치되어야 합니다.
내 부에 ACE가 없는 ACL은 빈 DACL입니다. ACE는 지정된 대상에게 개체에 대한 액세스를 부여하므로 빈 DACL로는 아무도 개체에 액세스할 수 없습니다. DACL이 없는 개체를 NULL DACL을 가진 개체라고 합니다. NULL DACL을 가진 개체는 보호되지 않으며 모든 사용자가 이에 대한 모든 권한을 가집니다. 따라서 빈 DACL이나 NULL DACL을 설정하면 안 됩니다.
이 쯤에서 실제 보안 설명자는 어떻게 생겼는지 살펴보는 것이 좋겠습니다. 다음은 Windows Server 2008 시스템 드라이브의 루트에 대한 보안 설명자입니다(cacls는 ACL을 조사하고 설정하기 위한 레거시 명령줄 루틴이며 icacls로 대체됨). 아쉽게도 icacls는 결과를 표준 SDDL(Security Descriptor Definition Language)로 출력하기 위한 명령줄 스위치를 지원하지 않습니다. cacls에는 이 스위치(/S 플래그)가 있습니다.
C:\>cacls c:/ /s c:\"D:PAI(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)(A;OICI;0x1200a9;;;BU)(A;CI;LC;;;BU)(A;CIIO;DC;;;BU)(A;OICIIO;GA;;;CO)"
보 안 설명자에 대해 현재 알고 있는 내용을 바탕으로 앞부분의 "D:"를 통해 소유권이나 그룹 멤버 자격이 선언되지 않았으며 설명자가 DACL임을 알 수 있습니다. DACL은 보호됩니다("P"와 Windows NT 5.0 상속 플래그가 설정됨). 그 다음에는 해석이 필요한 여러 개의 ace_string이 나옵니다.
보안 설명자 string_aces의 이해
앞에서 본 string_aces 형식을 떠올려 보십시오. 허용되는 ace_types는 그림 5에 정의되어 있고 허용되는 ace_flags는 그림 6에 정의되어 있습니다. 상속을 위한 ace_flags는 ACE 상속의 핵심 요인입니다.
그림 5 허용되는 ace_types
그림 6 허용되는 ace_flags
ACE 권한은 ACE에 의해 제어되는 액세스 권한을 표시하는 문자열로 표시됩니다. 이 문자열은 액세스 권한을 나타내는 16진수 문자열이거나(예: "0x7800003F") 권한 문자열을 연결한 형태일 수 있으며(예: "CCLCSWLOCRRC") 잠시 후에 이를 해석해 보겠습니다. 그림 7에는 16진수 표현 및 이와 연결된 비트 값이 나와 있습니다.
그림 7 ACL 액세스 마스크
시 스템은 모든 개체에 대해 ACE 권한의 단일 비트맵 표현을 사용합니다. 다양한 개체에서 모든 비트가 의미가 있는 것은 아닙니다. 개체에 해당되는 권한만 적용됩니다. 표준 권한은 모든 보안 개체에 공통적인 권한입니다. 일반 권한은 다양한 개체에 비슷한 목적의 권한을 지정하는 데 편리합니다. 일반 권한의 사양은 해당되는 구체적인 권한 집합에 매핑됩니다. 무결성 레이블도 SACL을 지정할 때 ACE 권한 필드를 사용하여 인코딩됩니다. 다양한 개체에 사용할 수 있는 권한은 그림 8에 나와 있습니다.
그림 8 일반 권한
거 의 동일한 몇 가지 권한 매핑은 구분 없이 사용됩니다. Full Control(FC)은 Generic_All(GA)과 동일합니다. 파일 시스템에서 적절한 모든 권한 선언은 File All(FA)입니다. Key All(KA)은 레지스트리에 적절한 모든 권한 선언입니다. 일반 선언은 보다 적절한 선언을 대신하여 사용되는 경우가 많지만 해당하는 파일 시스템이나 레지스트리 키 선언으로 적절히 매핑됩니다. SDDL 식에서는 이러한 용어를 혼용하는 경우가 많으므로 의미의 동일성을 알고 있어야 합니다.
표준 권한 및 구체적인 권한
다양한 개체에 권한을 할당할 수 있습니다. 이러한 개체에는 파일과 디렉터리 외에도 레지스트리 키, 프로세스, 바탕 화면 등이 있습니다. 전체 목록은 그림 A - J를 참조하십시오. 여기에서는 파일 시스템과 레지스트리에 대한 사용 권한을 설명하며, 이러한 개체에 대한 구체적인 권한은 9와 10에 나와 있습니다.
그림 9 구체적인 파일 권한
그림 10 구체적인 레지스트리 권한
무결성 레이블과 그 용도
앞 서 언급했듯이 무결성 레이블은(있는 경우) 개체의 SACL에 저장됩니다. 개체는 암시적으로 중간 무결성을 가지므로 무결성 레이블이 없으면 개체는 중간 무결성을 가집니다. 마찬가지로, 무결성 레이블이 없는 보안 토큰 역시 중간 무결성을 가집니다. 낮은 무결성 레이블은 LowRights Internet Explorer 및 이와 연관된 신뢰되지 않은 개체와 같은 낮은 권한의 프로세스에 레이블을 지정하는 데 사용됩니다. "높음" 및 "시스템" 수준은 이러한 개체를 중간/낮은 프로세스 및 개체로부터 격리하는 데 사용됩니다. 무결성 레이블은 그림 11에 나와 있습니다.
그림 11 무결성 레이블
object_guid와 inherit_object_guid
object_guid 와 inherit_object_guid는 Active Directory에서 개체의 보안을 지정하는 데 사용되며 파일 시스템 또는 레지스트리 보안에는 사용되지 않습니다. ACE 문자열에서 ace_type 필드의 "OA"와 "OD"는 각각 object-allow와 object-deny에 해당합니다. 이 경우에 object_guid는 사용 권한이 부여되는 개체의 guid를 포함하며 inherit_object_guid는 사용 권한을 상속하는 개체의 guid를 포함합니다.
ACE 구조의 account_sid 필드는 ACE에 지정된 액세스 권한이 허용 또는 거부되는 보안 주체를 나타냅니다. account_sid 필드는 SID(기본적으로 사람이 이해할 수 없는, 구조화된 긴 식별자) 또는 공용 계정을 위한 단축 "SID 문자열" 표기를 포함합니다. 공용 계정을 위한 SID 문자열 표기는 시스템의 가독성을 더 높이기 위해 가능한 경우 항상 사용됩니다. 그림 J에는 공용 또는 잘 알려진 계정과 이에 해당하는 SID 문자열이 나와 있습니다.
소 유자 권한의 OW 선언은 Windows Server 2008 및 Windows Vista에 새로 추가되었습니다. 이전에는 개체의 CO(Creator/Owner)는 개체에 대해 RC(Read Control) 및 WD(Write_DAC) 표준 권한을 가졌으므로 소유자가 개체의 보안을 설정할 수 있었습니다. 사용자가 그룹의 구성원이고 많은 수의 개체를 만들 경우 이것이 문제가 됩니다. 해당 사용자가 그룹에서 나가더라도 여전히 이러한 개체의 소유자이므로 RC와 Write_DAC 사용 권한이 부여되고, 따라서 계속 개체를 제어할 수 있습니다. OW 소유자 ACE 제한이 있으면 소유자에 대한 암시적인 RC/WD 부여가 차단됩니다(ACL에 있는 다른 관련 ACE의 소유자 ACE에 명시적으로 부여되는 경우 제외). 이렇게 하면 이 보안 문제를 완화할 수 있습니다.
보안 설명자 string_aces의 해석
시스템 드라이브 루트에 대한 cacls 출력은 다음과 같습니다.
"D:PAI(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)(A;OICI;0x1200a9;;;BU)(A;CI;LC;;;BU)(A;CIIO;DC;;;BU)
(A;OICIIO;GA;;;CO)"
이를 구문 분석하여 가독성을 높이면 다음과 같습니다.
"D:PAI (A;OICI;FA;;;SY) (A;OICI;FA;;;BA) (A;OICI;0x1200a9;;;BU)(A;CI;LC;;;BU)(A;CIIO;DC;;;BU) (A;OICIIO;GA;;;CO)"
이 것은 최신 파일 시스템의 auto-inherit 플래그가 설정된 보호되는 DACL입니다. protected 플래그는 상속 가능한 부모의 권한 부여가 상속되지 않음을 의미합니다. 즉, DACL은 개체 부모의 상속으로부터 보호됩니다. 이 경우에는 루트이기 때문에 부모가 없습니다.
기 본 제공 관리자와 시스템에는 파일(개체 상속에 의해)과 디렉터리(컨테이너 상속 또는 CI에 의해)에 대해 모두 상속 가능한 File All이 부여됩니다. 즉, 이 DACL은 루트 아래의 모든 파일과 디렉터리에 재귀적으로 File All을 부여합니다(보호되는 DACL의 권한 부여를 검사해야 할 때 보호되는 DACL에 의해 상속이 중단되는 경우 제외). CO에는 루트 디렉터리 아래의 파일과 디렉터리 모두에 대한 Generic_All이 부여되며(inherit-only 플래그에 의해) 이는 File All로 매핑됩니다.
기 본 제공 사용자에 대한 권한 부여는 훨씬 더 흥미롭습니다. 첫 번째 string_ace는 루트 및 그 아래의 파일과 디렉터리에 모두 적용되며 List, Read, ReadEA, Traverse, Execute, ReadAttr, ReadControl 및 Sync를 허용합니다. 두 번째 string_ace는 루트 및 그 아래에 AddSubDir을 부여하며(IO—inherit-only 플래그에 의해), 세 번째 string_ace는 루트 아래의 디렉터리에 AddFile을 부여합니다. Windows 탐색기의 ACL 그래픽 인터페이스를 사용하여 이러한 사용 권한을 확인해도 동일한 내용을 볼 수 있습니다.
Windows 리소스 보호
Windows Server 2008 및 Windows Vista부터 구성 요소는 필요한 보안 설정을 해당 매니페스트에 선언하며 이는 Microsoft 코드 서명 루트에 의해 서명됩니다. 매니페스트는 파일과 연관된 다른 사용 권한 및 ACL을 지정합니다. 따라서 구성 요소가 설치되면 적절한 보안 설정도 함께 제공됩니다. 또한 OS 파일은 WRP(Windows 리소스 보호)를 통해 시스템 관리자의 의도하지 않은 실수로부터 보호됩니다. WRP는 새로운 시스템 수준 엔터티인 신뢰할 수 있는 설치 관리자를 사용하여 시스템 파일과 폴더를 소유하고 관리합니다.
Windows Vista에는 일반 사용자가 권한이 부여된 구성 요소를 설치할 수 있도록 허용하는 유용한 기능이 추가되었습니다. 따라서 고급 사용자 역할이 더 이상 필요 없으며 고급 사용자 SID를 포함하는 ACE 인스턴스가 제거되었습니다. 고급 사용자 그룹은 여전히 존재하지만 구성 요소 매니페스트를 검색하여 PU에 대해 발견되는 모든 권한 부여 인스턴스를 삭제했습니다.
시스템 디렉터리에서 새로운 사용 권한을 살펴보겠습니다. 다음 역시 SDDL 읽기 연습용으로 좋습니다.
C:\>cacls c:\windows /s C:\Windows "D:PAI(A;;FA;;;S-1-5-80-956008885-3418522649-18310 38044-1853292631-2271478464)(A;CIIO;GA;;;S-1-5-80-956008885-3 418522649-1831038044-1853292631-2271478464)(A;;0x1301bf;;;SY} (A;OICIIO;GA;;;SY)(A;;0x1301bf;;;BA)(A;OICIIO;GA;;;BA)(A;;0x1200a9;;;BU) (A;OICIIO;GXGR;;;BU)(A;OICIIO;GA;;;CO)"
신뢰할 수 있는 설치 관리자의 SID는 S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464입니다. TI를 축약형으로 사용하여 다음과 같은 항목을 얻을 수 있습니다.
C:\Windows "D:PAI (A;;FA;;;TI)(A;CIIO;GA;;;TI) (A;;0x1301bf;;;SY)(A;OICIIO;GA;;;SY) (A;;0x1301bf;;;BA)(A;OICIIO;GA;;;BA) (A;;0x1200a9;;;BU)(A;OICIIO;GXGR;;;BU) (A;OICIIO;GA;;;CO)"
해석하면 Windows NT 5.0 상속 모델을 사용하여 C:\Windows에 적용되는 보호되는 ACE임을 알 수 있습니다.
신뢰할 수 있는 설치 관리자에는 C:\Windows에 대한 모든 권한이 부여되며 C:\Windows 아래의 모든 자식 컨테이너에 대한 Generic_All이 부여됩니다(CI이므로 상속만 해당).
시 스템과 관리자에게는 C:\Windows에 대한 Read, Write, Append, ReadEA, WriteEA, Execute, ReadAttr, WriteAttr, Del, RCtl 및 Sync, = SDGRGWGX가 부여됩니다. 이것은 Generic_All에서 Write_Owner 및 Write_DAC를 제외한 것입니다. 관리자와 시스템에는 소유자 또는 ACL을 변경할 수 있는 능력을 제외한 모든 권한이 부여됩니다. "BA"와 "SY"는 자식 파일과 디렉터리 개체에 대한 Generic_All을 가집니다.
관 리자는 소유 권한을 가지므로 여전히 WriteOwnership을 주장하고 제어 권한을 취할 수 있습니다. 관리자와 시스템은 보안상 동일합니다. 그러나 이 권한이 있는 경우 관리자는 마음만 먹으면 WRP ACL 제어를 속일 수 있습니다.
CO 도 자식 파일과 디렉터리 개체에 대한 Generic_All을 가집니다. 기본 제공 사용자는 C:\Windows에 대한 Read, ReadEA, Execute, ReadAttr, RCtl 및 Sync, = GRGX를 가지며 C:\Windows 아래의 하위 디렉터리와 파일에 대한 GRGX를 가집니다.
모 든 시스템 파일과 폴더는 신뢰할 수 있는 설치 관리자에게 모든 권한을 부여하는 보호되는 ACL을 가집니다. 신뢰할 수 있는 설치 관리자에 의한 파일 제어는 시스템 루트 디렉터리의 선언이 아닌 Windows 구성 요소의 개별 선언에 나타납니다.
안전한 파일 시스템 사용 권한 설정
이 제 파일 시스템 ACL의 작동 방식과 이를 읽는 방법을 어느 정도 살펴보았으므로 다음은 이를 설정하는 방법을 알아보겠습니다. 응용 프로그램을 설치하는 경우 기본 Program Files 위치에 설치해야 합니다. 이 위치에 대한 기본 ACL은 관리자와 로컬 시스템에 모든 권한을 제공하며, 이는 적절합니다.
응 용 프로그램을 다른 위치에 설치하는 경우, 또는 원하는 위치에 응용 프로그램을 설치할 수 있는 권한을 사용자에게 부여하는 경우 문제가 발생합니다. 다른 드라이브에 대한 기본 ACL, 그리고 시스템 드라이브에서 시스템 및 응용 프로그램 영역이 아닌 영역에 대한 기본 ACL은 충분히 안전하지 않습니다. 이러한 경우에는 적절하게 보호되는 DACL로 폴더의 ACL을 명시적으로 지정해야 합니다. 응용 프로그램을 설치하기 위한 가장 간단하고 안전한 선택은 Program Files 폴더의 보안 설정을 복제하는 것입니다. 이 방법을 사용하지 않을 경우 관리자가 아닌 사람은 DACL이나 실행 파일의 소유권을 변경할 수 없도록, 그리고 실행 파일이 포함된 디렉터리에 파일을 작성, 추가 또는 삭제하지 못하도록 DACL을 설정하십시오.
DACL 을 설정할 때 기본적인 규칙은 사용자가 작성한 코드를 관리자 또는 다른 사용자가 실행하지 못하도록 하는 것입니다. 이러한 실행이 특히 문제가 되는 경우는 일반적으로 신뢰할 수 있는 영역(Windows, Program Files 등)에 존재한다는 이유로 해당 폴더가 신뢰할 수 있는 폴더로 간주되는 경우입니다. 이 경우 관리자로의 EoP(권한 상승)가 허용되어 사용자 간 공격의 위험성이 높아집니다. 따라서 사용자가 이러한 폴더에 파일을 쓸 수 있다면 다른 사용자와 관리자가 이를 실행할 수 없도록 해야 합니다.
얼 핏 생각하기에는 사용자에게 Windows, System, Program Files 등의 폴더에 대한 쓰기를 전혀 허용하지 않아야 되는 것 같습니다. 그러나 사용자가 이러한 위치에 쓸 수 있어야 하는 합당한 이유가 있습니다. 가장 일반적인 이유는 오류 로그 데이터 기록입니다. 실행 파일이 사용자의 자격 증명으로 실행되고 오류를 기록해야 하는 경우 이 파일에는 오류 로그/로깅 폴더에 대한 쓰기/추가 액세스가 필요합니다. 다중 사용자 시스템에서 사용자별 위치에 오류를 기록하면 로깅 데이터가 실행 파일과 연결되지 않고 시스템 이곳저곳에 분산됩니다. 응용 프로그램과 서비스는 일반적으로 공유 폴더나 레지스트리 키에 씁니다. 사용자 권한으로 실행되는 프로세스가 지정된 시스템 레지스트리 키에 오류 정보를 저장하는 경우가 많으므로 레지스트리에서도 동일한 문제가 발생합니다.
사 용자가 쓸 수 있는 파일과 실행할 수 있는 파일을 구분해야 합니다. 신뢰되어야 하는 파일(예: 실행 파일)과 신뢰되지 않아야 하는 파일(신뢰되지 않은 사용자가 쓸 수 있는 모든 파일)에 각기 별도의 디렉터리를 사용하십시오. 디렉터리에 적절하게 ACL을 지정하십시오. 실행 파일에 대한 관리자 제어와 사용자 읽기/실행을 포함하고 쓰기는 제외하십시오. 레지스트리 키와 하위 키에도 같은 지침이 적용됩니다.
여 기에서 클라이언트와 서버에는 차이가 있습니다. 서버 관리자는 관리자로 실행하는 사용자에 비해 지식 수준이 훨씬 높은 것으로 간주됩니다. 서버 관리자는 신뢰되지 않는 시스템 영역의 코드를 실행하면 안 된다는 것을 알고 있습니다. 시스템에서 실행 파일로부터 데이터 파일을 격리하는 명명 규칙을 설정하면 관리자에게 실행 파일의 신뢰성에 대한 지침을 제공할 수 있습니다. 로깅 하위 디렉터리는 신뢰할 수 없으므로 사용자가 이러한 하위 디렉터리를 만들거나 수정할 수 없도록 해야 합니다. 그렇지 않으면 사용자가 안전한 명명 규칙을 스푸핑할 수 있기 때문입니다.
클 라이언트 환경에서는 코드를 실행하도록 관리자를 속이기가 훨씬 쉽습니다. 이렇게 속이기 쉬운 관리자 있는 경우 사용자가 실행 파일을 설치한 후 이러한 코드를 실행하도록 관리자를 속여 시스템을 손상시킬 수 없도록 사용자 쓰기가 가능한 디렉터리에 대해 관리자 실행 권한을 허용하지 말아야 합니다. 예를 들어 응용 프로그램이나 서비스에서 사용자 권한으로 작성되는 로그 정보를 저장해야 하는 경우 이 데이터를 저장할 로깅 하위 디렉터리를 만들어야 합니다. 이 하위 디렉터리는 관리자 실행을 허용하지 않아야 합니다. 이렇게 하는 한 가지 방법은 D;OI;WP;;;WD와 같이 모든 사용자에 대해 앞에 명시적인 파일 실행 거부를 추가하는 것입니다. 이렇게 하면 사용자에게 파일 쓰기 또는 수정을 허용하는 디렉터리에서 사용자 간 공격을 방지할 수 있습니다.
사 용자가 데이터를 공유해야 하는 경우가 많이 있습니다(공유 영역에서 코드를 공유하고 실행하는 것은 바람직하지 않지만). 예를 들어 집에서는 사용자(또는 사용자의 사진 보기 응용 프로그램)가 C:\Photos와 같은 폴더를 만드는 경우가 있습니다. 사용자는 여러 사용자에게 이 폴더에 대한 쓰기를 허용하고 여러 사용자가 이 폴더의 다양한 사진을 편집할 수 있도록 허용하기를 원합니다. Windows Vista 시스템 드라이브의 루트에 있는 기본 ACL은 이를 지원합니다. 한 폴더에 데이터를 넣어 두고 다른 사용자가 이를 읽을 수 있도록 하는 것도 흔히 볼 수 있는 공유 상황입니다. 삭제 또는 수정은 해당 데이터를 만든 사람에게만 허용되지만 다른 사용자가 이를 복사하여 복사본을 편집할 수 있습니다. 이는 공유 읽기 시나리오이며 Windows Server 2008 시스템 드라이브의 기본 상태입니다.
시 스템 드라이브를 잠그고, 특히 공유용 ACL 폴더를 잠그는 경우를 고려해 보겠습니다. 이러한 두 가지 일반적인 시나리오에 적합한 ACL을 선택해야 합니다. 관리자는 개체를 관리할 수 있어야 하고, 이러한 폴더에서의 코드 실행과 관련된 보안 문제는 방지해야 합니다(여기에서 ACE는 이러한 폴더에서 소유자조차 코드를 실행하지 못하도록 함).
다음은 공유 읽기 ACE입니다.
D:P(D;OI;WP;;;WD)(A;OICI;FA;;;BA)(A;OICI;FA;;;SY)(A;OICI;FA;;;CO)(A;CI;0x1200af;;;AU)(A;OI;GR;;;AU)
다음은 공동 작업 ACE입니다.
D:P(D;OI;WP;;;WD)(A;OICI;FA;;;BA)(A;OICI;FA;;;SY)(A;OICI;FA;;;CO)(A;OICI;SDGRGW;;;AU)
두 ACL 모두 사용자 시스템 및 사용자 간 공격을 방지하기 위해 모든 사용자에 대한 실행 거부 ACE, 개체 상속(파일에 적용하기 위함)으로 시작합니다. 그런 다음 관리자, 시스템 및 CO에 모든 권한, 즉 File All을 부여합니다(사실 시스템에는 필요 없음).
공 유 읽기 시나리오의 경우 인증된 사용자에게는 CI에 대한, 그리고 디렉터리에 대한 권한 부여의 제한에 의해 List, AddFile, AddSubDir, ReadEA, Traverse, ReadAttr, RCtl 및 Sync가 부여되며, 모든 파일에 대해 Generic Read가 별도로 부여됩니다. 공동 작업 시나리오의 경우 인증된 사용자에게는 파일 및 디렉터리에 대한 Delete, Generic Read, 및 Generic Write가 부여됩니다.
레지스트리 및 해당 사용 권한 관리
Windows는 상태 정보의 대부분을 Windows 레지스트리에 저장합니다. 레지스트리 데이터 저장소는 하이브라고 하며, 하이브에서 데이터는 컨테이너라고 할 수 있는 키 및 하위 키에 저장됩니다(하위 키는 개체로 볼 수 없음).
사 용자별 데이터는 Hive Key Users(HKEY_USERS)의 적절한 사용자 섹션에 저장됩니다. 누구나 예상하듯이 이 데이터의 대부분은 사용자가 쓸 수 있습니다. 모든 세션에서 HKey_Current_User(HKCU)는 적절한 HKEY_USERS 섹션을 가리킵니다.
시 스템과 컴퓨터 정보는 HKEY_LOCAL_MACHINE(HKLM) 하이브에 저장됩니다. HKLM에는 모든 시스템 서비스에 대한 정보가 포함되어 있으며, 현재 이러한 서비스의 대부분은 다양한 로컬 서비스 또는 네트워크 서비스 그룹에서 제한된 사용 권한으로 실행됩니다. 서비스와 응용 프로그램은 해당 레지스트리 키에 상태 정보를 저장할 수 있습니다. 이 정보는 서비스 키 또는 서비스 키 아래의 키로 하위 키에 저장되어야 합니다. 서비스 키에는 서비스가 자체 서비스 키 대신 SetKey를 가지도록 ACL을 지정하면 안 됩니다(또는 이러한 공격을 가능하게 하는 WDac 또는 WOwn). 이렇게 할 경우 서비스가 다른 실행 파일을 가리킬 수 있기 때문입니다. 이러한 오류가 있을 경우 시스템이 로드될 때 서비스 제어 관리자가 이 실행 파일을 로드하게 되므로 서비스 호스트에 대한 잠재적인 EoP가 발생합니다.
HKLM 의 DACL에 대한 일반적인 지침은 이 데이터 또는 관련된 ACL 및 소유권을 사용자가 쓰거나 수정하도록 하면 안 된다는 것입니다. 시스템 영역에서의 파일 시스템 DACL 설정에 대한 지침과 마찬가지로, 사용자 또는 제한된 컨텍스트에서 실행되는 응용 프로그램이나 서비스가 오류 정보를 기록해야 하는 경우 오류 로깅에 대해 예외가 발생합니다. 이러한 경우에 대한 지침은 파일 시스템의 해당 문제에 대한 지침과 비슷합니다. 즉, 이러한 정보를 위한 별도의 키를 만들고 적절하게 ACL을 지정해야 합니다. 따라서 중요한 정보는 신뢰되는 대상(관리자, 시스템 등)에 ACL을 지정하고 로깅 데이터는 필요에 따라 쓰기 가능하도록 지정할 수 있습니다.
사 용자가 사용자 또는 관리자용 도구를 통해 신뢰되는 매개 변수를 수정(예: 바이러스 방지 또는 맬웨어 방지 서비스를 해제)하거나 변조하지 못하도록 해야 합니다. 메모장이 호출되면 C:\windows\notepad.exe가 로드된다고 가정해 보겠습니다. C:\windows에 대한 기본 ACL은 공격자가 이 실행 파일을 수정하도록 허용하지 않습니다. 공격자가 메모장 아이콘에서 해당 실행 파일에 대한 링크를 수정할 수 있다면 이 공격자는 다른 파일(예: C:\tools\load_rootkit.exe)을 로드할 수 있습니다. 이렇게 하면 루트킷을 로드한 다음 메모장을 로드하여 사용자가 침해 사실을 인식하지 못하도록 할 수 있습니다.
공 격자가 레지스트리를 통해 링크를 조작할 수 있다면 파일 시스템에 대한 보호 ACL이 무력화됩니다. 제한된 시스템 서비스의 다른 시스템 서비스에 대한 공격에도 주의해야 합니다. Windows Vista와 Windows Server 2008에서 서비스는 필요한 권한에 따라 별도로 그룹화됩니다. 이 서비스 격리에서 제공하는 심층적인 보호를 위해서는 특히 다른 서비스 그룹 간에 서비스가 다른 서비스를 조작하지 못하도록 서비스 사용 권한을 구성해야 합니다.
사 용자가 악성 실행 파일을 추가하거나 연결하지 못하도록 방지하는 데 주의를 기울이는 것과 마찬가지로 서비스가 자체 사용 권한과 기능을 변경하지 못하도록 방지해야 합니다. 서비스에 대한 ChangeConf 권한은 관리자, 시스템 또는 신뢰할 수 있는 설치 관리자에게만 허용해야 합니다. 이 권한이 있으면 권한 소유자가 서비스에 대한 사용 권한을 변경할 수 있기 때문입니다.
요약
Windows에서 제공하는 풍부한 사용 권한 제어 집합을 사용하면 작업을 허용 및 차단하고 새로운 위협에 대한 심층적인 방어책을 제공할 수 있습니다. 그러나 이러한 풍부한 액세스 제어에는 복잡성이라는 문제가 필연적으로 수반됩니다.
몇 가지 일반적인 지침을 따르면 문제를 방지하는 데 도움이 됩니다. 예를 들어 시스템 기본값은 적절한 타협점이므로 이러한 기본값을 사용해야 합니다. Program Files 폴더 외부에 응용 프로그램을 설치하는 경우 프로그램 파일 ACL을 사용해야 합니다. 드라이브에 대한 기본적인 사용자 권한 부여와 같은 기본값을 조금 더 엄격하게 조정해야 하는 경우도 있지만, 이 경우 잠재적인 응용 프로그램 호환성 문제를 해결해야 한다는 점을 기억하십시오.
가 장 중요한 지침은 관리자 또는 시스템 계정은 사용자가 쓰거나 수정할 수 있는 코드를 실행하거나 이러한 코드로 연결되는 포인터를 따라가면 안 된다는 것입니다. 또한 사용자는 다른 사용자가 쓰거나 수정할 수 있는 코드를 실행하거나 이러한 코드로 연결되는 포인터를 따라가면 안 된다는 점 역시 이에 못지않게 중요합니다. 이러한 지침을 통해 여기에서 설명한 모든 문제를 처리할 수 있습니다. 모든 변경 작업이 이 지침에 부합한다면 가장 심각한 보안 문제를 피해갈 수 있습니다.
액세스 제어 구성 요소에 대한 자세한 내용은 MSDN에서 "액세스 제어 구성 요소"를 참조하십시오. ace_string 액세스 마스크 구성 요소에 대한 내용은 MSDN "ACCESS_MASK" 기사를 참조하십시오. 이 기사에는 파일, 디렉터리, 레지스트리 키 및 공유 섹션의 구체적인 권한에 대한 포인터가 포함되어 있습니다. 제한된 SID에 대한 자세한 내용은 MSDN "제한된 토큰" 기사를 참조하십시오.
전체 권한 목록
그림 A 표준 권한
그림 B 파일 및 디렉터리에 대한 구체적인 권한
그림 C 파일 맵 및 레지스트리에 대한 구체적인 권한
그림 D 서비스 제어 관리자 및 서비스에 대한 구체적인 권한
그림 E 프로세스 및 스레드에 대한 구체적인 권한
그림 F WindowStations 및 바탕 화면에 대한 구체적인 권한
그림 G 기호화된 링크 및 이벤트에 대한 구체적인 권한
그림 H 세마포 및 뮤텍스에 대한 구체적인 권한
그림 I 파이프 및 토큰에 대한 구체적인 권한
그림 J 일반적이거나 잘 알려진 계정 및 해당 SID 설정
John R. Michener는 Microsoft의 선임 보안 프로그램 관리자이며 약 5년 전에 Microsoft Windows Security에 합류했습니다. John은 시스템 보안 분야에 20년 이상의 경력을 보유하고 있으며 3개의 보안 업체를 설립했습니다. 현재 Windows Software Assurance 팀에서 암호화 및 사용 권한 전문가로 일하고 있습니다. 문의 사항이 있으면 jmichene@microsoft.com으로 연락하십시오.
