• 아티클

Security

보안을 강화하는 Windows Vista의 새로운 ACL

Jesper Johansson

 

한 눈에 보기:

  • ACL의 새로운 기능
  • 관리자에 대한 보다 강력한 제어
  • 신뢰할 수 있는 설치 관리자 권한
  • 수정된 사용자 및 그룹

Windows Vista에서 ACL(액세스 제어 목록)의 기본 구조는 크게 변경되지 않았습니다. 하지만 반드시 알고 있어야 할 작지만 중요한 많은 변경이 이루어졌습니다. Windows® XP에서 발생하는 몇 가지

문제는 ACL과 관련이 있었으므로 몇몇 변경은 필수 불가결한 것이었습니다. 첫 번째 문제는 대부분의 Windows XP 사용자가 관리자로 시스템을 실행한다는 것입니다. 즉, 대부분의 Windows XP 사용자는 기본 제공 Administrators 그룹의 구성원인 계정을 사용합니다. 가정에서 Windows XP를 사용하는 사용자의 경우 설치 중 추가되는 모든 계정이 관리자가 되므로 대부분 이러한 문제가 발생합니다. 따라서 이러한 사용자가 실행하는 프로그램도 운영 체제에 대한 무제한 액세스를 제공하는 관리자 권한으로 실행됩니다. 특히 이러한 프로그램이 유해한 종류의 프로그램일 경우에 문제가 될 수 있습니다.

두 번째 문제는 이전 버전 Windows의 기본 ACL의 경우 Everyone, Power Users 등에 대한 ACE(ACL 항목)를 포함하므로 대부분의 사용자들이 꺼려한다는 점입니다. 예를 들어 Windows XP의 부팅 볼륨 루트(일반적으로 C:\)에 대한 기본 ACL은 Everyone에는 읽기 권한을 부여하고 Users 그룹 구성원에게는 폴더를 만들 수 있는 권한을 부여했습니다. 마지막 문제는 Windows XP에서는 ACL로 수행할 수 있는 작업이 제한된다는 것입니다. 예를 들어 Windows XP에는 개체의 현재 소유자에게 권한을 할당할 수 있는 방법이 없었습니다. 소유자에게 권한을 부여할 수는 있었지만 소유자가 변경되는 경우 해당 권한이 새 소유자에게 상속되지 않았습니다. 마찬가지로 소유자는 개체에 대해 어떤 권한을 할당받았는지에 관계없이 항상 개체에 대한 암시적 권한을 가지고 있었습니다.

Windows Vista™를 개발하면서 Microsoft는 이러한 문제의 대부분을 해결하는 동시에 UAC(사용자 계정 컨트롤) 같은 다른 기능을 지원하기 위한 프로젝트에 착수했습니다. 이 기사에서는 Windows Vista의 액세스 제어와 관련된 주요 변경 사항에 중점을 두고 설명하며 다음 달에 제공할 기사에서 계속해서 액세스 제어를 관리하는 데 사용할 수 있는 도구에 대해 살펴보도록 하겠습니다.

새롭게 수정된 사용자 및 그룹

Windows Vista에서는 몇 가지 사용자와 그룹이 새로 도입되었으며 Windows XP에 있었던 몇 가지 이전 사용자와 그룹은 제거되었습니다. 일부 사용자와 그룹의 작동 방식도 수정되었습니다. 이러한 변경은 액세스 제어를 관리하는 방법에 영향을 줍니다.

Administrator - 기본적으로 사용되지 않음 RID(관련 식별자)가 500인 기본 제공 Administrator 계정은 이제 대부분의 경우 기본적으로 사용되지 않습니다. Administrator 계정은 원래는 다른 모든 계정이 실패한 경우 컴퓨터를 복구하는 데 사용하기 위한 비상용 계정으로 만들어졌습니다. 하지만 이 계정은 이러한 원래 용도에서 벗어나 표준 관리 계정으로 사용됨에 따라 몇 가지 보안 원칙을 위배하기에 이르렀습니다. 이 중 가장 주목할 만한 것은 책임에 관한 부분으로 시스템에서 변경 작업을 수행하는 사용자를 추적할 수 없다는 점입니다. 이에 따라 이 계정은 부분적으로 사용되지 않게 되었습니다. 그 결과 Microsoft는 이 계정을 완전히 사용하지 않으려고 했지만 결국에는 기본적으로 사용하지 않는 쪽으로 방향을 바꿨습니다. Administrators 그룹에 다른 로컬 계정이 없는 경우에는 복구 콘솔과 안전 모드에서 RID 500을 여전히 사용할 수 있습니다. 하지만 그 외의 경우에는 RID 500을 사용할 수 없으며 사용해서도 안 됩니다.

기본 제공 Administrator 계정과 Administrators 그룹에 포함된 다른 계정은 서로 다릅니다. RID가 500인 계정을 가리킬 때는 "Administrator"로 첫 글자를 대문자로 표기함으로써 이 계정을 기본 제공 Administrators 그룹의 구성원으로 포함되어 있는 다른 계정인 "관리자"와 구별합니다. 그룹 이름도 이와 비슷하게 첫 글자를 대문자로 표기합니다.

Windows XP의 기본 제공 Administrator 계정은 다른 관리자가 가지고 있지 않은 많은 특수한 권한을 가졌습니다. Windows Vista에서는 두 가지 예외적인 경우를 제외하고는 이러한 대부분의 권한이 제거되었습니다. 첫째, 다른 로컬 관리자가 없는 경우에 한해 사용하지 않도록 설정된 Administrator 계정을 복구 콘솔에서 사용할 수 있습니다. 둘째, Administrator 계정은 UAC의 영향을 받지 않으며 항상 모든 관리 액세스 토큰을 가집니다. Domain Administrator(도메인에서 RID가 500인 계정)에도 동일한 사항이 적용됩니다.

Power Users 권한 제거 이전의 Power Users 그룹은 완전히 실용적인 목적으로 제거되었습니다. 그룹 자체는 남아 있지만 그룹에 부여되었던 대부분의 권한이 제거되었습니다. Power Users 그룹의 구성원인 사용자는 자신을 관리자로 설정하지 않았을 뿐이지 사실상 관리자였다는 것은 모두 다 아는 사실입니다. 예전에 Windows XP 서비스 팩 2(SP2)를 실행하는 완벽하게 패치된 시스템을 인수받은 적이 있었는데 자신에게 관리자 권한을 부여하여 인수 작업을 수행한 결과 작업을 마치는 데 45분도 걸리지 않았습니다. 이는 조사, C++를 사용한 간단한 프로그램 작성, 인수를 완료하기 위해 로그오프 후 다시 로그온하는 작업 등에 소요된 시간이 모두 포함된 것이며 이 모든 작업은 Power Users 그룹의 구성원이었기 때문에 가능했습니다.

대부분의 조직에서 Power Users 그룹에 고급 권한을 부여한 다음 조직의 사용자를 이 그룹의 구성원으로 추가하므로 Windows Vista에서 이 그룹을 제거한다는 것은 현실적으로 가능하지 않았습니다. 하지만 Microsoft는 다음 버전 Windows에서는 Power Users 그룹을 완전히 제거하려고 계획하고 있습니다. 따라서 현재 Power Users 그룹을 사용하고 있다면 서서히 마이그레이션에 대한 계획을 세우는 것이 좋습니다.

신뢰할 수 있는 설치 관리자 신뢰할 수 있는 설치 관리자는 실제로는 서비스이며 사용자가 아닙니다. 신뢰할 수 있는 설치 관리자에 부여된 권한을 파일 시스템 전체에서 볼 수 있더라도 혼동하지 마십시오. 이제 서비스 강화를 통해 각 서비스를 다른 사용자와 마찬가지로 권한을 할당할 수 있는 완전한 보안 사용자로 취급할 수 있게 되었습니다. 이 기능에 대한 개요는 TechNet Magazine2007년 1월호를 참조하십시오. Windows Vista Security(Grimes와 Johansson 공동 집필, Wiley Press, 2007)에서는 방화벽 및 IPsec과 같은 다른 기능을 활용하여 서비스를 강화하는 방법에 대해 자세히 다룹니다.

서비스 SID는 이제 예전과는 달리 NT AUTHORITY나 도메인과 같은 권한에서 발급되지 않습니다. TrustedInstaller 가상 계정의 전체 이름은 NT SERVICE\TrustedInstaller이고 SID는 다음과 같습니다.

S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464

그림 1과 같이 sc showsid 명령을 실행하면 존재하지 않는 서비스의 SID까지 포함하여 모든 서비스의 SID를 볼 수 있습니다.

그림 1 sc showsid로 존재하지 않는 서비스의 SID를 포함한 모든 서비스의 SID 표시

그림 1** sc showsid로 존재하지 않는 서비스의 SID를 포함한 모든 서비스의 SID 표시 **(더 크게 보려면 이미지를 클릭하십시오.)

이 SID는 S-1-5-80으로 시작합니다. 여기서 첫 번째 하위 권한은 SECURITY_SERVICE_ID_BASE_RID를 나타내는 80으로, 이는 이 SID가 NT SERVICE 하위 권한에 의해 서비스에 발급되었음을 의미합니다. 이는 어느 서비스에나 동일하게 적용됩니다. 나머지 하위 권한과 RID는 서비스 이름 자체를 기준으로 만들어집니다. 이름이 미리 결정되어 있으며 컴퓨터마다 다르지 않으므로 개발자는 서비스를 실제로 빌드 및 설치하지 않고도 자신의 서비스에 권한을 부여할 수 있습니다.

서비스 관리자에서 TrustedInstaller 서비스를 찾을 수 없는 경우 표시 이름이 "Windows 모듈 설치 관리자"인 서비스를 찾으십시오.

도움말 및 지원 계정 제거 Windows Vista를 새로 설치하는 경우에는 Support_xxxxxx 및 HelpAssistant 계정이 모두 제거되어 없으며 이전 버전 Windows에서 업그레이드하는 경우에는 그대로 남아 있습니다. Support_xxxxxx 계정은 지원 센터에서 스크립트를 실행하는 데 사용되었습니다. 자체 도움말 콘텐츠를 제공하는 일부 OEM에서도 고유의 지원 계정을 제공했을 수 있습니다. 이러한 OEM 계정이 어떻게 될지는 확실하지 않지만 OEM에서 이러한 계정을 더 이상 만들지 않는다는 것은 확실합니다. 엄밀하게 말하면 이러한 계정은 더 이상 필요하지 않습니다. 사실 보안 측면에서는 사용자가 또 다른 사용자로 도움말 센터에서 스크립트를 실행하도록 허용하는 것이 적절한 방법이 아니므로 이러한 계정은 제거하는 것이 바람직합니다. Windows Vista에는 이 작업을 수행하기 위한 새로운 메커니즘이 도입되었습니다.

HelpAssistant 계정은 원격 지원 중에 사용되었습니다. 도움말 센터와 마찬가지로 원격 지원 기능도 HelpAssistant 계정이 필요하지 않도록 다시 설계되었으며 이에 따라 HelpAssistant 계정도 제거되었습니다.

새로운 네트워크 위치 SID Windows NT® 기반 운영 체제에는 사용자가 네트워크에서 대화식으로 로그온함을 나타내는 NETWORK, INTERACTIVE 등의 몇몇 네트워크 위치 기반 SID가 있습니다. 터미널 서비스를 통해 로그온하는 사용자에게 할당되는 REMOTE INTERACTIVE LOGON SID도 있습니다. 터미널 서비스 사용자의 토큰에는 REMOTE INTERACTIVE LOGON과 INTERACTIVE LOGON이라는 SID가 모두 있습니다. Windows Vista에서는 DIALUP과 INTERNET이라는 두 개의 SID가 추가되었습니다. 전화 접속 연결을 통한 로그온을 나타내는 계정이 추가된 이유는 다소 불분명합니다. 특히 전화선이 사용 가능한 유일한 네트워크라면 아예 온라인을 포기하려는 사용자가 대부분일 것이므로 이러한 계정이 왜 필요한지 다소 모호하지만 Windows Vista에는 어쨌든 이 계정이 있습니다. INTERNET은 LAN 외부에서 사용자가 로그온함을 나타내기 위한 SID입니다. 하지만 NETWORK는 인터넷을 비롯하여 네트워크에서 로그온하는 모든 사용자를 나타냅니다.

OWNER RIGHTS 및 소유자 권한 Windows Vista에는 파일 액세스 시 파일을 소유하게 된 모든 사용자에게 적용되는 OWNER RIGHTS에 대한 SID가 추가되었습니다. 이 SID는 주로 소유자가 파일에 수행할 수 있는 작업을 제한하는 데 사용됩니다. Windows XP에 비해 Windows Vista의 소유자 권한 작동 방식은 두 가지 측면에서 크게 변경되었습니다. 첫째, 개체의 소유자이지만 개체에 대한 ACE가 소유자에게 적용되는 경우 ACE의 권한이 개체의 소유자라는 사실보다 우선합니다. 개체 소유자는 개체에 대한 암시적 권한을 가진다는 사실에 익숙해진 사용자에게 이는 시스템 관리의 일부 측면에 많은 영향을 주는 중대한 변경입니다. 둘째, 소유자가 개체에 수행할 수 있는 작업을 추가로 제한하는 데 OWNER RIGHTS SID를 사용할 수 있습니다.

그림 2와 같이 Jesper라는 사용자가 소유자이며 ACL이 있는 폴더가 있다고 가정해 봅니다. Jesper는 폴더의 소유자이지만 폴더에 대한 읽기 권한만 가지고 있습니다. Jesper에게는 폴더에 쓸 수 있는 권한이 없으므로 폴더에 파일을 복사하려고 하면 복사 작업이 실패합니다. 하지만 오류 메시지만 보고는 이유를 정확하게 알 수 없습니다. Windows 탐색기®에서 소유하고 있지만 쓰기 권한은 없는 폴더에 파일을 복사하려고 하는 경우 먼저 탐색기에서 파일을 복사하려면 권한을 높여야 한다는 메시지를 표시하고 권한을 높일 것을 요청합니다. 하지만 이 폴더에 복사할 수 있는 권한이 없으므로 파일 복사 작업이 실패합니다. "이 작업을 수행하기 위한 권한이 필요합니다."라는 오류 메시지와 함께 "다시 시도"(도움이 되는 것처럼 보임) 및 "취소" 단추가 표시됩니다. 이 동작은 사용자가 폴더의 소유자라는 점을 무시하고 수행됩니다.

그림 2 로컬 시스템과 한 명의 다른 사용자만 이 폴더에 액세스할 수 있음

그림 2** 로컬 시스템과 한 명의 다른 사용자만 이 폴더에 액세스할 수 있음 **(더 크게 보려면 이미지를 클릭하십시오.)

Jesper가 파일에 대한 ACL을 변경하려고 하면 해당 작업을 수행하기 위해 토큰을 승격하라는 메시지가 표시됩니다. Jesper는 파일 소유자이므로 토큰을 승격할 수 있습니다. 달리 명시된 OWNER RIGHTS에 대한 ACE가 있지 않는 한 소유자는 ACL을 읽고 변경할 수 있는 암시적 권한(READ_CONTROL 및 WRITE_DAC)을 가집니다.

OWNER RIGHTS SID가 어떤 효과를 주는지 이해하려면 위의 ACL에 이 SID를 추가해 보십시오. 이제 그림 3에 나와 있는 권한을 가집니다.

그림 3 폴더에 대한 OWNER RIGHTS 권한을 추가하여 Jesper의 권한 변경

그림 3** 폴더에 대한 OWNER RIGHTS 권한을 추가하여 Jesper의 권한 변경 **(더 크게 보려면 이미지를 클릭하십시오.)

이제 Jesper가 폴더 소유자이자 적절한 권한을 가지므로 Jesper 계정으로 이 폴더에 항목을 복사하려고 시도하면 복사 작업이 즉시 성공합니다. 하지만 Jesper가 개체에 대한 ACL을 변경하려고 하면 작업이 실패합니다. OWNER RIGHTS에 대한 ACE는 소유자에게 수정 권한만 허용할 뿐 DACL(임의 액세스 제어 목록)을 수정할 수 있는 권한은 부여하지 않습니다. 따라서 OWNER RIGHTS는 보안 설명자를 수정할 수 있는 권한인 WRITE_DAC를 소유자에게서 제거하는 데 주로 사용됩니다.

관리자가 개체 소유자를 변경하는 경우 OWNER RIGHTS 권한이 새 소유자에게 자동으로 상속되지 않습니다. 이 경우 OWNER RIGHTS ACE는 상속 전용이나 컨테이너, 개체 등 어떤 항목에도 적용되지 않음으로 표시하여 사용하지 않도록 설정됩니다. 이는 개체가 완전히 잠겨 관리자가 이를 사용할 수 없는 상황을 방지하기 위해서입니다. OWNER RIGHTS ACE를 다시 적용하려면 Administrator가 직접 ACE를 다시 설정하는 작업을 수행해야 합니다. 이를 위해서는 필요에 따라 이 ACE를 해당 폴더, 해당 폴더의 하위 폴더 및 폴더 내의 파일에 적용되는 것으로 표시해야 합니다.

사용자가 파일 서버에 파일과 폴더를 만드는 것은 허용하되 해당 폴더에 대한 ACL을 변경하는 것은 허용하지 않으려는 경우와 같이 관리자가 OWNER RIGHTS SID를 유용하게 사용할 수 있는 몇몇 흥미로운 시나리오가 있습니다. 사용자가 과거에 한 그룹의 구성원으로서 몇몇 개체를 만들었는데 나중에 비즈니스상의 이유로 그룹에서 제거된 경우를 예로 들 수 있습니다. 그룹에서 제거된 후에는 자신이 만든 개체에 대한 설정을 수정할 수 없습니다.

OWNER RIGHTS는 서비스 강화 영역에서 매우 광범위하게 사용됩니다. 서비스가 런타임에 임시 개체를 생성하는 경우 해당 개체를 만든 이는 서비스 자체의 SID가 아니라 서비스 프로세스의 기본 SID로 일반적으로 LocalSystem, NetworkService 또는 LocalService입니다. 이는 같은 프로세스 컨텍스트에서 실행 중인 다른 서비스가 개체를 수정할 수 있다는 것을 의미하며 결코 바람직한 동작이 아닙니다. 이러한 개체에 대해 OWNER RIGHTS SID를 설정하면 다른 서비스가 개체에 액세스하는 것을 방지할 수 있습니다.

기본 ACL

Windows XP의 기본 ACL도 사용하는 데 문제가 없었습니다. 사용자가 부팅 볼륨의 루트에 파일을 저장하는 것을 허용하는 것과 같은 몇몇 사소한 문제를 제외하고는 전반적으로 괜찮았습니다. 하지만 일부 OEM은 적절한 보안을 위해 좋은 것이 무엇인지는 자신들이 더 잘 안다고 생각했습니다. 그림 4의 화면은 주요 OEM에서 구성한 Windows XP Media Center Edition 컴퓨터의 Windows 디렉터리에 대한 ACL을 보여 줍니다. 이 OEM은 파일 시스템 보안을 기본적으로 사용하지 않았습니다.

그림 4 OEM에서 구성한 ACL

그림 4** OEM에서 구성한 ACL **

Microsoft는 Windows Vista에서 ACL을 약간 수정했습니다. Windows XP에 친숙한 사용자라면 무엇보다도 모든 OS 파일을 Administrators 그룹이 소유하며 관리자는 OS 파일에 대한 모든 권한을 가진다는 사실을 잘 알고 있을 것입니다. Administrators 그룹의 구성원은 OS 파일에 무제한으로 액세스할 수 있었습니다. 하지만 Windows Vista에서는 그렇지 않습니다.

신뢰할 수 있는 설치 관리자 Windows Vista에서는 대부분의 OS 파일을 TrustedInstaller SID가 소유하며 이 SID만 OS 파일에 대한 모든 권한을 가집니다. 이는 Windows Vista에 포함된 시스템 무결성 작업의 일부이며, 특히 관리자나 로컬 시스템으로 실행되는 프로세스에서 자동으로 파일을 바꾸는 것을 방지합니다. 따라서 운영 체제 파일을 삭제하려면 운영 체제 파일에 대한 소유권을 확보한 다음 이를 해당 파일에 대해 삭제를 허용하는 ACE에 추가해야 합니다. 신뢰할 수 있는 설치 관리자는 LocalSystem으로 실행되며 시스템 무결성 레이블이 지정된 프로세스를 어느 정도 보호합니다. 이보다 낮은 무결성을 가진 프로세스는 소유권을 변경하기 위해 자신의 권한을 높일 수 없습니다. 예를 들어 일부 서비스는 로컬 시스템으로 실행되기는 하지만 무결성 수준이 보통일 수 있습니다. 이러한 서비스는 시스템 파일을 바꿀 수 없습니다. 따라서 이전과는 달리 이러한 서비스 중 하나를 악용하여 운영 체제 파일을 바꿀 수 없으므로 시스템에 루트킷이나 다른 맬웨어를 설치하는 것이 더 어려워졌습니다. 몇몇 시스템 바이너리가 있는 것만으로도 번거로워하는 시스템 관리자가 있는데 이제 이러한 시스템 관리자가 시스템 바이너리를 제거하는 것도 더 어려워졌습니다.

Deny ACE 파일 시스템에 있는 대부분의 개체의 경우 Everyone에 대해 Deny ACE가 설정되어 있는데 대부분의 관리자는 이러한 사실에 매우 놀라워합니다. "숨김 파일 및 폴더 표시" 옵션을 설정하면 친숙한 Documents and Settings 디렉터리가 표시됩니다. 하지만 이 디렉터리를 클릭하면 액세스 거부 오류 메시지가 나타납니다. Documents and Settings에서 어떤 작업이 수행되는지 알아보려면 그림 5의 디렉터리 목록을 살펴보십시오.

그림 5 디렉터리가 아니라 연결 지점인 Documents and Settings

그림 5** 디렉터리가 아니라 연결 지점인 Documents and Settings **(더 크게 보려면 이미지를 클릭하십시오.)

Documents and Settings는 실제로는 디렉터리가 아니라 연결 지점입니다. 연결 지점은 액세스를 다른 위치로 리디렉션하는 심볼 링크와 비슷합니다. 여기서는 C:\Users라는 디렉터리로 이동됩니다. Microsoft는 Windows Vista의 파일 시스템 네임스페이스를 대폭 수정했으며 그 결과 사용자 데이터가 C:\Users로 이동되었습니다. 이전의 "C:\Documents and Settings\<Username>" 네임스페이스 아래에 있던 다른 요소들도 이동되었습니다. 예를 들어 "C:\Documents and Settings\<Username>\Application Data"는 C:\Users\<username>\appdata\roaming으로 이동되었습니다. 그림 5와 같이 명령줄을 표시한 다음 dir /a 명령을 사용하면 이러한 변경 사항을 분명하게 확인할 수 있습니다. 네임스페이스가 이토록 대폭 수정된 이유는 사용자에게 디렉터리를 보다 알아보기 쉽게 표시하고 문서와 데이터를 보다 명확하게 구분하기 위해서입니다. 이제 개발자는 모든 데이터 파일을 My Documents 폴더에 저장하는 대신 사용자 프로필 아래에 고유의 폴더를 만들어 저장할 수 있으며 사용자는 여기에서 파일을 확인할 수 있습니다. 모든 사용자의 응용 프로그램 데이터는 이제 Documents and Settings\All Users\Application Data 대신 %systemroot%\ProgramData라는 숨겨진 폴더로 이동되었습니다.

Microsoft는 "C:\Documents and Settings" 네임스페이스를 제거하지 않았는데 이는 이전 응용 프로그램이 %USERPROFILE%과 같은 기본 환경 변수가 아니라 해당 이름을 사용하도록 하드 코드되어 있을 수도 있기 때문입니다. 이러한 응용 프로그램은 "C:\Documents and Settings"가 없으면 작동하지 않습니다. 이제 이러한 폴더는 이전 버전과의 호환성을 위해 연결 지점이나 심볼 링크로 표시됩니다. 이러한 경로를 하드 코드하는 응용 프로그램은 응용 프로그램에서 경로의 데이터에 액세스하는 방식에 따라 여전히 작동하지 않을 수 있습니다. 하지만 이러한 응용 프로그램은 영어가 아닌 다른 언어의 Windows 버전에서 이미 작동하지 않았습니다. 이게 바로 핵심입니다. Windows XP SP2, Windows Vista 등의 Windows 업데이트로 인해 타사 프로그램이 작동하지 않는 경우 그 원인은 대부분 해당 프로그램의 개발자가 올바르지 않은 가정을 하거나 바람직하지 않은 방식으로 Windows를 사용하는 데 있었습니다.

예를 들어 "C:\Documents and Settings\<Username>\My Documents\foo.txt"를 입력하여 파일을 여는 경우 해당 위치에 foo.txt라는 파일이 있으면 파일이 올바르게 열립니다. 하지만 "C:\Documents and Settings\<Username>\My Documents"로 이동하려고 하면 "액세스 거부" 오류 메시지가 표시됩니다. 그림 6의 ACL을 보면 그 이유를 알 수 있습니다.

그림 6 Documents and Settings에 설정된 Deny ACE

그림 6** Documents and Settings에 설정된 Deny ACE **(더 크게 보려면 이미지를 클릭하십시오.)

목록의 첫 번째 ACE를 살펴보십시오. 이 ACE는 폴더 내용을 나열할 수 없도록 Everyone에 대해 설정된 Deny ACE입니다. Everyone은 트래버스 검사 무시 권한(SeChangeNotifyPrivilege)을 가지고 있으므로 프로그램은 연결 지점을 무시하고 절대 경로를 사용하여 문서를 열 수 있습니다. 하지만 사용자나 프로세스에서 연결 지점이 나타내는 디렉터리를 나열하려고 시도하는 경우에는 Deny ACE로 인해 실패하게 됩니다. 바로 이 때문에 사용자는 C:\Documents and Settings 내의 내용을 볼 수 없으며 "디렉터리"를 삭제할 수도 없습니다. Deny ACE를 설정하는 주요 이유는 사용자가 연결 지점을 삭제하여 이전 응용 프로그램이 작동되지 않게 되는 상황을 방지하는 데 있습니다. Deny ACE는 개발자에게 이전 네임스페이스를 사용하여 응용 프로그램을 코딩하는 대신 앞으로는 환경 변수나 레지스트리 문자열을 사용함으로써 향후의 변경 및 여러 언어를 사용함으로써 발생하는 문제로부터 응용 프로그램을 보호하도록 상기시키는 역할도 합니다.

모든 연결 지점은 기본적으로 숨겨져 있으므로 대부분의 사용자에게는 연결 지점이 표시되지 않습니다. Microsoft는 사용자가 연결 지점을 삭제할 수 없도록 "폴더 목록"에 대해 Deny ACE를 설정했습니다.

트래버스 검사 무시 사용자가 권한이 없는 폴더(또는 연결 지점) 내에 있는 파일에 대한 권한을 가진 경우 해당 파일에 액세스할 수 있는 이유는 모든 사람에게 트래버스 검사 무시 권한이 있기 때문입니다. 트래버스 검사 무시(SeChangeNotifyPrivilege)는 사실상 Windows의 가장 기본적인 권한으로, 프로세스에서 이 권한도 제거하도록 특별히 요청한 경우가 아니면 프로세스에 다른 모든 권한이 제거된 경우에도 이 권한은 부여됩니다. 이 동작은 Windows Vista에서 runas /trustlevel:0x10000 < 줄을 사용하여 프로세스를 실행하는 경우 수행됩니다. 즉, <command>에 지정된 프로그램이 제한된 토큰으로 실행되고 SeChangeNotifyPrivilege를 제외한 모든 권한이 프로세스 토큰에서 제거됩니다.

여기서 흥미로운 사실을 설명하자면 trustlevel 0x20000은 일반적인 SID 집합은 포함되어 있지만 권한은 제거된 토큰을 제공하며 0x40000은 완전히 일반적인 토큰을 제공합니다.

기본 사용 권한

Windows Vista의 파일 시스템에 대한 기본 사용 권한은 Windows XP와는 약간 다르게 변경되었습니다. Windows XP나 Windows Server® 2003에서 %systemdrive%(일반적으로 C: 드라이브인 부팅 볼륨)에 대한 ACL을 보면 기본 사용 권한을 확인할 수 있으며 Windows XP 초기 버전에서도 이와 비슷한 기본 사용 권한을 볼 수 있습니다.

D:AR
(A;OICI;FA;;;BA)
(A;OICIIO;FA;;;CO)
(A;;0x1200a9;;;WD)
(A;OICI;FA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;CI;0x100004;;;BU)
(A;CIIO;0x100002;;;BU)

다음은 Windows Vista의 동일한 디렉터리에 대한 동일한 ACL입니다.

D:PAI
(A;;FA;;;BA)
(A;OICIIO;GA;;;BA)
(A;;FA;;;SY)
(A;OICIIO;GA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;OICIIO;SDGXGWGR;;;AU)
(A;;LC;;;AU)

여기에는 눈여겨볼 만한 많은 차이점이 있습니다. 첫째, BA(BUILTIN\Administrators)에 대한 ACE가 이제 한 개가 아니라 두 개입니다. 하지만 최종 결과는 같습니다. Windows Vista에서는 둘 중 한 ACE는 상속되지 않으며 루트에 대한 모든 권한을 부여합니다. 다른 한 ACE는 IO(상속 전용) ACE로, 컨테이너와 개체에 상속되며 GA(일반 전체 또는 모든 권한)를 부여합니다. SY(LocalSystem)에 대한 한 ACE를 Windows Vista의 두 ACE로 대체하는 경우에도 결과가 동일합니다. Windows XP에서는 단일 ACE가 모든 권한을 부여했으며 개체와 컨테이너에 상속되었습니다. 다시 말해 결과만 보면 변경된 것이 없습니다. ACL이 변경된 주된 이유는 ACL을 보다 쉽게 관리하고 더 나아가 복원할 수 있도록 권한을 명료하게 분류하는 데 있습니다.

이보다 흥미로운 사실은 CO(Creator/Owner)에 대한 ACE가 사라졌다는 것입니다. 즉, 사용자가 파일 시스템 루트에 개체를 만드는 경우 더 이상 만든 이에게 특별한 권한이 부여되지 않습니다.

WD(Everyone)에 대한 ACE가 제거되었다는 사실도 알 수 있습니다. 보안에 관심이 있는 대부분의 사용자는 이 ACE가 수행하는 작업의 의미를 완벽하게 이해하지도 못하면서 이에 대해 지나치게 걱정하는 경향이 있었습니다. Microsoft는 Everyone이 기능적으로는 기본 제공되는 Users와 동일하다는 점을 설명하기 위해 수년 동안 노력했지만 허사였습니다. 결국 이 ACE를 포기하고 완전히 제거했습니다. BU(BUILTIN\Users)에 대해서도 동일한 ACE가 있으며 이 ACE도 컨테이너와 개체에 상속되므로 결과만 놓고 보면 변경된 것이 없습니다.

뿐만 아니라 BU(기본 제공 Users)에 대한 ACE 중 두 개가 AU(Authenticated Users)에 대한 ACE로 대체되었습니다. 그 이유는 INTERACTIVE가 기본 제공 Users의 구성원이라는 이유로 Guest 계정이 기본 제공 Users의 구성원이 되기 때문입니다. 하지만 Guest가 Authenticated Users의 구성원은 아닙니다. Guest 계정이 파일을 읽고 실행할 수 있도록 0x1200a9(읽기 및 실행) ACE는 BU에 계속 부여됩니다. 하지만 파일과 폴더를 만들 수 있는 권한을 부여하는 ACE는 대신 Authenticated Users에 부여되었습니다. 이는 Windows XP로부터 변경된 것입니다. Windows XP에서는 Guest가 루트에 파일을 만들 수 있었습니다. Windows Vista에서는 Guest가 이런 식으로 파일을 만들 수 없습니다. 하지만 Guest 계정이 설정되어 있는 경우 게스트가 부팅 볼륨의 루트에 액세스할 수 있는 방법이 없다면 이는 문제가 될 수 있습니다. 기본적으로 Guest 계정은 사용하지 않도록 설정됩니다.

위의 두 목록에는 매우 흥미로우면서도 문제의 소지가 있는 두 개의 ACE가 있습니다. Windows XP에서는 기본 제공 Users에 대해 0x100004를 지정하여 컨테이너에 ACE가 상속되도록 했습니다. 이 ACE는 컨테이너에 상속되므로 Users에 하위 폴더, 하위 폴더의 하위 폴더 등을 만들 수 있는 권한을 부여합니다. 하위 폴더에 상속되는 0x100002에 대한 상속 전용 ACE도 있습니다. 이 ACE는 루트 아래에 만든 폴더에 파일과 하위 폴더를 만들 수 있는 권한을 사용자에게 부여합니다. 다시 말해 이 두 ACE는 Guest 등의 사용자가 루트 아래에 파일과 폴더를 만들 수 있도록 허용합니다.

Windows Vista에서는 이 ACE가 컨테이너와 파일 모두에 상속되고 SD(보안 설명자 읽기)와 함께 GR(일반 읽기), GX(일반 실행) 및 GW(일반 쓰기)를 부여하는 상속 전용 ACE와 루트 자체에만 적용되며 LC 권한을 부여하는 ACE의 두 ACE로 바뀌었습니다. LC는 Active Directory®의 ACE의 간략한 용어입니다. Active Directory에서 LC는 사용자가 자식 개체를 나열할 수 있음을 의미합니다. 하지만 LC의 16진수 값은 0x4입니다. 디렉터리의 경우 0x4는 0x100004와 기능적으로 동일한 FILE_ ADD_SUBDIRECTORY를 의미합니다. 이는 0x100000(동기화를 위해 개체를 사용할 수 있는 권한)은 0x1200a9 ACE를 통해 이미 가지고 있기 때문입니다. 다시 말해 LC는 Windows XP에서와 정확하게 동일한 결과를 줍니다. 즉, 사용자가 루트 아래에 하위 디렉터리를 만들 수 있습니다.

이 16진수 값은 어디에서 온 것이며 무엇을 의미할까요? 지금쯤이면 이미 아셨겠지만 액세스 제어는 0x1200a9와 같이 모두 16진수(base16) 숫자로 구성됩니다. 이러한 값은 실제로는 "on"으로 설정된 액세스 마스크의 비트에 대한 비트 마스크 표현이며 값이 특정 ACE에서 사용된다는 것을 나타냅니다. icacls, sc 또는 secedit 같은 도구를 사용하여 ACL을 나열하면 이러한 비트 마스크가 각각 일치하는 텍스트 문자열이 있는 경우 훨씬 친숙한 텍스트 문자열로 표시됩니다.

따라서 LC가 무엇을 의미하는지 알아보려면 MSDN® 웹 사이트로 이동하고 문자열 LC를 찾은 다음 해당 Access right value(액세스 권한 값) 열에서 ADS_RIGHT_ACTRL_DS_LIST를 봅니다. 그런 다음 Iads.h 헤더 파일을 열어 해당 문자열을 찾으면 LC가 0x4에 해당한다는 것을 알 수 있습니다. 앞에 "ADS_RIGHT"가 없는 비 Active Directory 문자열의 경우 AccCtrl.h에서 16진수 값을 찾습니다. 16진수 값만 알면 WinNt.h 또는 AccCtrl.h의 액세스 마스크에서 이 값을 찾아 그 의미를 쉽게 확인할 수 있습니다.

이에 대한 자세한 설명이 필요하면 Protect Your Windows Network(Jesper Johansson과 Steve Riley 공동 집필, Addison-Wesley, 2005)를 구해서 읽어 보십시오. 이 책의 17장에는 SDDL(Security Description Definition Language) 문자열과 ACE를 분석하는 방법에 대한 자세한 설명이 나와 있습니다.

Windows Vista에서는 이러한 하위 디렉터리에 부여된 권한이 전적으로 (A;OICIIO;SDGXGWGR;;;AU) ACE에 의해 관리되는데 바로 이점이 Windows Vista와 Windows XP의 가장 큰 차이점입니다. Windows XP와는 달리 Windows Vista에서는 하위 디렉터리를 만든 사람에게 모든 권한을 부여하지 않고 대신 인증된 사용자에게 수정 권한을 부여합니다.

이 새로운 ACL이 가져다 주는 궁극적인 결과는 이제 개체를 만든 사람이 더 이상 특별한 권한을 가지지 않으며 권한 관련 작업이 좀 더 명료하게 수행된다는 것입니다. 가장 크게 변경된 사항이라 할 수 있는 것은 Authenticated Users가 관리자가 만든 하위 폴더에 대해서도 수정 권한을 가진다는 것이며 이는 Windows XP와 크게 다른 점입니다. Windows XP의 Users와 Authenticated Users에게는 관리자가 루트 아래에 만든 개체에 대한 아무런 권한도 없었습니다. Windows Vista의 변경된 ACE는 다소 혼란스러울 수도 있지만 궁극적으로는 Windows XP의 ACE에서 개선되었습니다.

요약하자면 Windows Vista에서는 Guest 사용자를 비롯한 모든 사람이 루트에서 파일을 읽고 실행할 수 있습니다. 파일과 폴더를 만드는 작업은 인증된 사용자만 수행할 수 있으며 이 경우 인증된 사용자에게 해당 파일과 폴더에 대한 수정 권한이 부여됩니다. 다시 말해 Windows Vista에서는 Guest 계정을 기본적으로 사용하지 않지만 Windows XP보다 사용 권한이 보다 강력하게 관리된다고 할 수 있습니다.

토큰 변경

Windows XP에서는 Administrators 그룹의 구성원인 사용자가 로그온하는 경우 사용자 토큰에 Administrators 그룹 SID가 포함되어 있으므로 사용자가 Administrators 그룹이 수행할 수 있는 모든 작업을 수행할 수 있습니다. 하지만 Windows Vista에서는 사용자 계정 컨트롤로 인해 이러한 일이 더 이상 가능하지 않습니다. 토큰에 Administrators SID는 여전히 포함되어 있지만 그림 7의 Process Explorer 스크린샷에서 볼 수 있듯이 이 SID만 Deny(거부)로 설정되어 있습니다.

그림 7 권한을 높이지 않은 한 UAC에서 액세스 거부용으로만 사용되는 Administrators SID

그림 7** 권한을 높이지 않은 한 UAC에서 액세스 거부용으로만 사용되는 Administrators SID **(더 크게 보려면 이미지를 클릭하십시오.)

액세스 제어를 수행할 때 이러한 토큰 내의 항목은 액세스를 거부하는 데에만, 즉 Deny ACE와 비교하는 데에만 사용됩니다. 해당 SID에 대한 Allow ACE는 모두 무시됩니다. 이는 사용자가 시스템에 관리자로 로그온한 경우를 비롯하여 항상 관리자가 아님을 의미합니다.

무결성 수준

이제 Windows에서는 무결성 수준으로 프로세스와 개체에 레이블을 지정할 수 있습니다. 이러한 무결성 수준은 실제로는 ACE로도 표시되지만 DACL에는 표시되지 않습니다. 대신 몇 가지 특수 플래그가 지정되어 SACL(시스템 액세스 제어 목록)에 포함됩니다. 예를 들어 NW 플래그는 낮은 무결성 수준의 프로세스가 높은 무결성 수준의 개체에 쓰지 못하도록 차단되었음을 나타내는 데 사용됩니다(SDDL_NO_WRITE_UP). Mark Russinovich는 TechNet Magazine 이번 호에서 제공하는 "Windows Vista 사용자 계정 컨트롤 들여다보기" 기사에서 이에 대해 자세히 다룹니다.

결론

Windows 2000과는 달리 Windows Vista의 액세스 제어는 눈에 띄게 수정된 것은 없지만 사소한 부분에서 많은 변경이 이루어졌습니다. 이러한 변경을 하나씩 놓고 보면 별 의미가 없어 보입니다. 하지만 이들을 전체적으로 보면 시스템 관리 시 수행해야 할 작업에 대해 재고할 점이 많다는 것을 알 수 있습니다. 더 나아가 이러한 변경은 UAC 및 서비스 강화와 같은 다른 많은 이니셔티브를 지원합니다. Windows Vista를 처음 사용하는 경우 불편함을 느낄 관리자도 있을 수 있습니다. 필자는 Windows Vista가 이런 저런 이유로 원치 않는 운영 체제 일부를 삭제할 수 있는 기능을 제한하는 "독재적인 운영 체제"라는 비판을 이미 들은 바 있습니다. 하지만 이러한 변경이 이루어진 데에는 그만한 이유가 있습니다. 시간을 들여 어떤 변경들이 이루어졌는지 꼼꼼히 분석해 보면 변경이 이루어진 이유를 이해할 수 있을 것입니다.

Jesper Johansson은 대규모 전자 상거래 회사의 보안 설계자로, 속성 및 서비스 범위와 관련된 응용 프로그램 보안 전략을 수립하는 업무를 담당하고 있습니다. 보안 분야에서 20년 동안이나 근무했으며 보안과 관련된 두 권의 책과 많은 기사를 집필했습니다. 정보 보안 관련 업무를 하지 않을 때는 스쿠버 다이빙을 가르칩니다.

© 2008 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..