Security WatchACL 관리 도구
Jesper M. Johansson
Windows에서 액세스 제어 목록(ACL)을 사용하면 사용자와 프로세스의 리소스(예: 파일 및 폴더) 사용을 매우 세밀하게 제어할 수 있습니다. ACL 관리는 사용자 시스템의 보안 유지에 있어 다소 복잡한 작업이 될 수 있지만, 다행히 사용 권한 및 ACL 관련 작업을 자동화하고 간소화하는 데 유용한
여러 유틸리티를 활용할 수 있습니다.
대부분의 독자들은 첫 출시 버전부터 Windows NT®의 모든 버전에 포함되어 왔던 cacls.exe 도구에 친숙할 것입니다. Windows Vista™에서 cacls.exe를 실행하면 화면에 다음과 같은 메시지가 나타납니다.
Microsoft Windows [Version 6.0.5744]
Copyright (c) 2006 Microsoft Corporation. All rights reserved.
C:\Windows\system32>cacls
NOTE: Cacls is now deprecated, please use Icacls.
Windows Vista에서 Microsoft는 ACL 업데이트(technetmagazine.com/issues/ 2007/06의 TechNet Magazine 2007년 6월호 참조)는 물론, ACL 관리에 사용하는 일부 도구도 업데이트했습니다. 이러한 업데이트에서 특히 가장 중요한 것은 바로 명령줄 도구 업데이트입니다.
icacls.exe는 Windows Vista에서 새로 등장한 항목으로, Windows Server® 2003 서비스 팩 2에서 하위 수준으로 사용되기도 했습니다. 이 icacls.exe는 결국 cacls.exe를 대체하게 될 것입니다. cacls.exe는 Windows® 2000에서 보다 정밀한 사용 권한을 도입한 이후 지금까지 약 7년 동안 이 기능을 지원하도록 완전히 업데이트되지 않았기 때문입니다.
그런데 놀랍게도 문제의 이 cacls.exe에는 몇 가지 새로운 기능이 추가되었습니다. 첫째, cacls.exe는 이제 연결 지점과 심볼 링크 모두를 인식하여 트래버스할 수 있습니다. 둘째, SDDL(Security Description Definition Language) 문자열을 사용하여 ACL을 인쇄하고 설정할 수도 있습니다.
그러나 cacls.exe의 이러한 업데이트에도 불구하고 icacls.exe가 제공하는 기능은 훨씬 매력적입니다.
ACL 저장 및 복원
지난 10년 동안 필자를 비롯하여 많은 사람들은 나중에 복원할 수 있도록 ACL을 저장하는 기능을 원했습니다. 그러나 이 기능은 ACL에서 수행하기에 가장 복잡한 작업 중 하나로서, 일부 특수한 경우를 제외하면 애초에 ACL을 손상시키지 않고 이전 상태로 정확히 복원하기는 어렵습니다. 그럼에도 불구하고 이 기능은 상당히 유용할 수 있습니다.
ACL을 저장 또는 복원하는 방법을 설명하기 전에, 먼저 이런 작업이 왜 그토록 어려운지 그 이유를 알려드릴까요? 한 대학교의 학생 사용자 데이터가 들어 있는 계층 구조를 예로 들어 봅시다. 2월 1일 ACL을 저장했는데 4월 17일 어떤 이유로 이 ACL이 손상된 것을 발견하여 저장된 사본으로 ACL을 복원해야 합니다. 이 작업에 어떤 복잡한 요소가 있을까요?
우선 새학기는 4월 2일에 시작되었습니다. 그리고 학생의 약 15%가 졸업했으므로 이들의 디렉터리는 이제 존재하지 않습니다. 따라서 백업 파일에 있는 ACL은 유효하지 않습니다. 또 다른 15%의 학생은 새학기에 추가된 신입생들입니다. 따라서 이들에게는 현재 홈 디렉터리가 있지만 백업 파일에는 ACL이 없습니다. 이들의 ACL은 어디에 있을까요? 물론 나머지 70%의 학생은 그대로지만 이들도 새로운 파일과 폴더를 만들고 다른 일부는 삭제하기도 했습니다. 삭제된 파일과 폴더는 무시하면 되겠지만 새로 만든 폴더는 어떻게 구성할까요? 어떤 학생이 3월 4일에 폴더 하나를 친구들과 공유했다면 또 어떻게 될까요? ACL을 복원하면서 이 공유 설정을 해제하시겠습니까?
ACL의 저장과 복원은 이렇게 많은 사람들의 생각과 달리 전혀 단순하지 않으며 매우 신중해야 하는 작업입니다. 결과적으로 정의되지 않은 동작이 초래될 가능성이 높기 때문입니다. 따라서 ACL 복원은 최후의 수단으로 사용해야 합니다. 백업 이후 기간이 길수록 복원할 때 문제가 발생할 가능성이 높습니다.
그래도 이 기능을 사용해야 한다면 /save 스위치와 함께 icacls.exe를 실행하십시오.
icacls <target> /save acls.bin /t
그러면 ACL이 acls.bin이라는 파일에 저장됩니다. 이 파일 안에는 ACL이 있는 각 개체에 대한 줄 다음에 SDDL로 이러한 ACL을 지정하는 줄이 순서대로 들어 있습니다. 이 명령에 사용된 /t 스위치는 사용자가 지정한 개체와 이 개체의 모든 하위 개체 및 컨테이너만을 대상으로 작업하도록 합니다.
도구 키트에 저장 기능이 추가된 것은 반가운 일이지만 여기에도 몇 가지 결함이 있습니다. 예를 들어 이 기능은 DACL(임의 액세스 제어 목록)만 저장하고 SACL(시스템 액세스 제어 목록)은 저장하지 않습니다. SACL이 있어도 이를 나타내는 더미 값만 저장할 뿐 실제로는 SACL의 어떤 부분도 저장하지 않습니다.
ACL이 저장되는 방식에서도 특이한 문제가 발생합니다. 자주 사용하는 텍스트 편집기에서 저장된 ACL을 열기 전에 반드시 다음 사항을 명심하십시오.
저장된 ACL을 절대 편집하지 마십시오!
저장된 ACL이 들어 있는 파일을 텍스트 편집기에서 열면 유니코드(UTF-16) 형식의 텍스트 파일처럼 보입니다. 사실 이것은 틀린 것도 아닙니다. 그래서 사용자는 텍스트 편집기에서 편집하고 저장할 수 있을 것이란 생각이 들 수도 있습니다. 그러나 절대 그렇게 하지 마십시오!
저장된 ACL이 들어 있는 파일을 텍스트 편집기에서 열고 저장하면 이 파일로는 ACL을 복원할 수 없게 됩니다. 이런 파일은 사실상 유니코드 텍스트 파일이 아니기 때문입니다. 유니코드 텍스트 파일은 2바이트 0xfffe로 시작되어야 합니다. 메모장과 같은 텍스트 편집기에서 이런 파일을 저장하면 플래그가 파일의 처음 2바이트에 삽입됩니다. 그러나 icacls.exe 도구는 ACL 데이터가 파일의 바이트 0에서 시작하는 것으로 간주합니다. icacls.exe 도구는 처음 2바이트를 작업 대상 개체를 지정하는 문자열의 일부로 간주하기 때문에 파일에 들어 있는 ACL을 구문 분석할 수 없는 것입니다. 따라서 백업 파일은 사용할 수 없게 됩니다.
Microsoft도 이 문제를 알고 있지만 Windows Vista 베타 버전이 진행되던 중 매우 늦게 보고되었기 때문에 출시 전에 수정하지 못했습니다. 현재로서는 이 문제가 언제 수정될지, 심지어 수정 계획이 있는지도 알 수가 없습니다. 따라서 당분간은 저장된 ACL을 편집하지 않는 것이 최선입니다. 반드시 편집해야 한다면 파일을 .bin 파일로 저장하고 자주 사용하는 개발 도구와 같은 16진 편집기를 사용하십시오.
/save 스위치를 사용해서 ACL을 저장한 다음에는 /restore 스위치와 함께 icacls.exe를 사용하여 이를 복원할 수 있습니다. 가장 단순한 형태의 복원 명령 구문은 다음과 같습니다.
icacls <directory> /restore acls.bin
이 복원 절차는 파일에는 적용되지 않습니다. 이를 확인하려면 그림 1의 명령 시퀀스를 참조하십시오. 여기서 필자는 특정 파일에서 icacls.exe를 선택하여 저장 파일을 만들었습니다. 그런 다음 /save를 /restore로 바꾸어 복원을 시도했습니다. 그러나 restore 명령은 디렉터리에서만 작동하기 때문에 이 시도는 실패했습니다. 이 명령이 수정해야 하는 파일은 acls.bin 파일에 이미 지정되어 있습니다. ACL을 복원하기 위해 필자는 파일 대신 디렉터리를 대상으로 지정했습니다. 마지막 명령에서 "."를 작동 대상 개체로 지정한 것입니다.
Figure 1 ACL 저장 및 복원
C:\Users\Jesper>icacls test.txt /save acls.bin
processed file: test.txt
Successfully processed 1 files; Failed processing 0 files
C:\Users\Jesper>icacls test.txt /restore acls.bin
test.txt\test.txt: The system cannot find the path specified
Successfully processed 0 files; Failed processing 1 files
C:\Users\Jesper>icacls . /restore acls.bin
processed file: .\test.txt
Successfully processed 1 files; Failed processing 0 files
이때 restore 명령은 반드시 상승된 권한으로 실행해야 한다는 점을 주의하십시오! ACL에 대해 읽기 권한만 있으면 하위 수준의 관리자 또는 일반 사용자 계정으로도 명령 프롬프트에서 save 명령을 실행할 수 있습니다. 그러나 ACL을 복원하려면 완전한 관리자 토큰이 필요합니다.
SID 대체
icacls.exe에서 매우 유용한 또 다른 기능은 특정 사용자의 권한을 다른 사용자의 권한으로 대체할 수 있다는 점입니다. 이런 작업은 /substitute 스위치를 사용하여 복원하는 도중 수행됩니다. substitute 스위치에 대한 설명서에서는 SID가 필요한 것으로 나와 있지만 뒷부분에는 일반 사용자 이름을 사용할 수 있다는 설명이 있습니다. 따라서 그림 2의 시퀀스가 제대로 작동하는 것입니다.
Figure 2 복원 중 SID 대체
C:\Users\Jesper>icacls test.txt
test.txt VistaRC2-Test\foo:(R,W)
VistaRC2-Test\Jesper:(I)(F)
NT AUTHORITY\SYSTEM:(I)(F)
BUILTIN\Administrators:(I)(F)
Successfully processed 1 files; Failed processing 0 files
C:\Users\Jesper>icacls test.txt /save acls.bin
processed file: test.txt
Successfully processed 1 files; Failed processing 0 files
C:\Users\Jesper>icacls. /substitute foo bar /restore acls.bin
processed file: .\test.txt
Successfully processed 1 files; Failed processing 0 files
C:\Users\Jesper>icacls test.txt
test.txt VistaRC2-Test\bar:(R,W)
VistaRC2-Test\Jesper:(I)(F)
NT AUTHORITY\SYSTEM:(I)(F)
BUILTIN\Administrators:(I)(F)
Successfully processed 1 files; Failed processing 0 files
여기서 볼 수 있듯이 필자는 결국 이전의 것과 동일한 ACL을 사용하지만, foo에 대한 사용 권한을 지정하는 데 사용된 ACE가 이제는 bar에 대한 사용 권한을 지정하고 있습니다.
소유자 변경
chown 도구는 여러 해 동안 UNIX 시스템에서 중요한 요소였습니다. 원래 Windows는 개체 소유자를 변경할 수 있는 기본 방법이 없었습니다. 그러다가 Resource Kit을 통해 setowner 도구가 등장했고, 이후 Windows NT 4.0에서 takeown.exe 도구가 등장했지만 이 유틸리티에서는 소유권을 뺏는 것이 가능할 뿐 해당 사용자의 암호가 없으면 다른 사용자에게 소유권을 부여할 수 없었습니다. 이제 icacls.exe에서는 개체 소유자를 설정할 수 있는 기능이 기본적으로 제공됩니다. 단, 해당 개체에 소유자를 설정할 수 있는 권한이 있어야 합니다.
C:\>icacls c:\test /setowner foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
안타깝게도 icacls.exe는 개체 소유자를 보여줄 수가 없습니다. 명령줄에서 개체 소유자가 누구인지 실제로 확인할 방법이 없는 것입니다. 게다가 개체의 ACL을 저장할 경우 이 개체의 소유자는 저장되지 않습니다.
또한 icacls.exe에는 소유자 변경을 위한 SeTakeOwnershipPrivilege를 호출하지 않는 버그가 있습니다. 사용자에게 ACL에 따라 개체 소유자를 변경할 권한이 있는 경우 icacls.exe는 정상적으로 작동합니다. 그러나 관리자이지만 개체의 ACL에 따라 소유자를 변경할 권한이 없다면 이 버그 때문에 icacls.exe를 사용하여 소유자를 변경할 수는 없습니다. 이런 경우에는 takeown.exe 도구를 사용해야 합니다. 이 도구는 SeTakeOwnershipPrivilege를 호출하지만 임의의 계정이 아니라 사용자의 계정 또는 Administrators 그룹으로만 소유자를 변경할 수 있습니다.
C:\>takeown /f c:\test
SUCCESS: The file (or folder): “c:\test” now owned by user “JJ-VistaRTMTst\Jesper”.
물론 Microsoft 다운로드 센터에서 다운로드할 수 있는 subinacl 도구 역시 setowner 스위치를 갖고 있습니다. 그러나 subinacl은 여러 면에서 icacls보다 직관적이지만 사용 방법은 훨씬 복잡합니다.
특정 사용자의 파일 찾기
icacls에 포함된 또 다른 유용한 기능은 특정 사용자에 대한 권한이 들어 있는 파일을 찾을 수 있다는 것입니다. 예를 들면 다음과 같습니다.
C:\windows\system32>icacls “c:\program files” /findsid jesper /t
SID Found: c:\program files\Passgen\
passgen.exe.
Successfully processed 1808 files; Failed processing 0 files
이 기능은 특정 사용자가 어떤 파일에 액세스할 수 있는지 알아내려 할 때 유용합니다.
ACL 재설정 및 변경
ACL이 손상되었거나 완전히 파괴된 경우, icacls.exe는 이를 재설정하여 부모로부터 상속받을 수 있습니다. 2006년 가을 제로 데이(zero-day) 보안 문제가 발생했을 때 이 기능이 있었더라면 매우 유용했을 것입니다. Windows 구성 요소에서 이 문제를 완화하는 데 사용했던 방법 중 하나는 개체에 대한 Everyone 액세스를 거부하는 것이었습니다. 이 작업은 간단했지만 문제는 Windows XP와 Windows Server 2003에서 기본 제공하는 도구로는 이 ACE(액세스 제어 항목)를 제거하는 것이 거의 불가능하다는 것이었습니다. 그러나 Windows Vista에서는 다음과 같은 명령만 실행하면 됩니다.
C:\windows\system32>icacls “c:\program files\passgen\passgen.exe” /reset
processed file: c:\program files\passgen\passgen.exe
Successfully processed 1 files; Failed processing 0 files
물론 icacls.exe에는 표준 grant/deny/remove 기능이 모두 포함되어 있습니다. 이 중 실제로 새로운 항목은 remove뿐입니다. 이 스위치를 사용하면 특정 개체 또는 계층 구조에서 특정 사용자의 모든 Allow ACE, 모든 Deny ACE 또는 둘 모두를 제거할 수 있습니다. 그림 3은 여러 grant, remove, deny 기능의 일부 예를 보여줍니다.
Figure 3 작업 허용, 거부 및 제거
C:\>icacls c:\test /grant foo:(F)
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test
c:\test JJ-VistaRTMTst\foo:(F)
BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test /remove:g foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test /deny foo:(F)
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test
c:\test JJ-VistaRTMTst\foo:(N)
BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test /remove:d foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
Successfully processed 1 files; Failed processing 0 files
Deny ACE만 제거하는 기능은 특정 그룹이나 사용자에게 개체에 대한 액세스를 제공할 때 유용합니다.
무결성 수준 설정
icacls.exe는 무결성 수준을 표시하고 설정하는 기능도 갖고 있습니다. Windows Vista는 개체에 무결성 레이블을 지정하는 기능을 지원합니다. icacls.exe는 이런 작업을 수행할 때 사용하는 명령줄 도구입니다.
C:\>icacls c:\test /setintegritylevel high
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
Mandatory Label\High Mandatory Level:(NW)
Successfully processed 1 files; Failed processing 0 files
단, icacls.exe는 무결성 레이블이 개체에 명시적으로 설정된 경우에만 이를 표시합니다. 대부분의 파일에 이런 명시적 설정이 없기 때문에 무결성 레이블이 표시되는 경우는 흔치 않습니다.
마지막으로, icacls.exe는 개체에 정식 ACL이 있는지 확인할 수 있습니다. 앞서 언급했듯이 타사 도구는 ACL에 ACE를 잘못된 순서로 입력하는 것으로 알려져 있습니다. icacls.exe는 아래와 같이 이런 종류의 문제를 확인하고 수정할 수 있습니다.
C:\>icacls c:\test /verify
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
ACL UI
ACL UI, 즉 ACL 사용자 인터페이스는 Windows XP에 있던 UI에서 약간 수정되었습니다. 그림 4와 5는 각각 Windows XP와 Windows Vista의 ACL UI 대화 상자를 보여 줍니다.
그림 4** Windows XP의 ACL UI 대화 상자 **
그림 5** Windows Vista의 ACL UI 대화 상자 **
그림을 보면 몇 가지 변화를 알 수 있습니다. 첫째, 이 대화 상자는 현재 작업 중인 개체를 매우 명확하게 보여 주기 때문에 한 번에 여러 개체를 작업할 때 유용할 수 있습니다. 둘째, 하단에는 일부 도움말에 대한 하이퍼링크가 있습니다. 그러나 가장 주목할 만한 변화는 추가 단추와 제거 단추가 사라지고 대신 Windows Vista에서 UAC(사용자 액세스 제어)를 지원하기 위해 폭넓게 제공되는 편집 단추로 대체되었다는 점입니다. 이 단추의 방패 표시를 보면 알 수 있듯이, 이 대화 상자를 연 사용자는 ACL을 편집할 권한이 없습니다. 따라서 권한을 편집하려면 먼저 권한 상승을 수행해야 합니다. 이때 C: 드라이브의 루트에 폴더를 만들고 해당 속성을 즉시 확인해보면 이것이 기본값이 아니라는 것을 알 수 있습니다. 폴더의 소유자는 ACL을 편집할 수 있는 암시적 권한을 갖고 있으므로 방패 모양이 표시되지 않습니다. 방패 표시는 권한 상승 메시지를 실행 프로세스의 일부로 표시하는 데 사용되는 메커니즘인 COM 모니커를 나타냅니다. 편집 단추를 클릭하면 친숙한 권한 상승 대화 상자가 표시되며, 여기서 계속을 클릭하면 Windows XP에서 추가 단추를 클릭했을 때 표시되는 것과 거의 동일한 대화 상자가 나타납니다. ACL UI는 여러 위치에서 이러한 이중 대화 상자 방식을 따르고 있습니다. 즉, 권한 상승 전까지 하나의 대화 상자가 표시되다가 권한을 상승하면 이전 버전의 Windows로부터 친숙한 이전 대화 상자가 표시되는 것입니다.
고급 단추를 클릭하고 감사 탭을 클릭하면 항상 그림 6과 같은 권한 상승 단추가 나타납니다. 개체 소유자로서 개체에 대해 모든 제어 권한을 갖고 있더라도 권한을 상승하지 않으면 감사를 수정할 수 없습니다. GUI 도구에서 '감사 및 보안 로그 관리'라 부르는 SE_SECURITY_NAME 권한이 개체 SACL 수정 기능을 제어하기 때문입니다. 이러한 권한은 기본적으로 관리자만 가지고 있습니다. 그러나 관리 승인 모드(UAC를 사용하는 경우)에서 이러한 권한은 관리자 계정에서 제거되므로 관리자라 해도 권한 상승이 필요합니다.
그림 6** Windows Vista에서 감사 설정을 수정하려면 항상 권한 상승 필요 **
ACL을 수정할 때 권한 상승에 관해 유의해야 할 마지막 사항은 이러한 모든 설명이 UAC를 해제하지 않은 상태를 전제로 한다는 점입니다. UAC를 해제하면 모양이 다른 대화 상자를 제외하고 모든 동작이 Windows XP에서와 동일한 상태로 돌아갑니다. 그러나 관리자로 로그온한 경우에는 토큰에 항상 Administrators SID가 포함되어 있으므로 권한을 상승할 필요는 없습니다.
기타 도구
icacls.exe는 매우 유용한 도구로서 cacls.exe에 비해 크게 향상되었지만 아직 몇 가지 단점이 남아 있습니다. 가장 두드러진 단점은 아마도 파일과 디렉터리 외에는 다른 개체에 대한 액세스를 관리할 수 없다는 점일 것입니다. Windows Vista는 기타 개체의 ACL에 있어서는 Windows XP에 비해 거의 달라진 점이 없습니다. 그러나 여전히 서비스, 레지스트리 키, 심지어 Active Directory® 개체에 대한 ACL을 관리해야 할 때가 있습니다.
명령줄을 매우 선호하는 사용자라면 이런 작업을 수행하는 데 subinacl.exe가 필요합니다. subinacl.exe는 지원 도구에 포함되어 있으며 다운로드에서도 구할 수 있습니다.
그런데 subinacl.exe는 사용 방법이 그리 간편하지 않습니다. 때때로 기능이 너무 둔할 때도 있습니다. 그래도 subinad.exe는 액세스 제어 관리에 있어 놀랄 만큼 강력한 도구라 할 수 있습니다. 고급 관리자라면 반드시 이 도구가 필요합니다.
레지스트리 ACL
레지스트리 ACL은 파일 시스템 ACL과 똑같은 변화를 거쳤지만 범위 면에서 파일 시스템보다 훨씬 작다고 할 수 있습니다. 이전 버전의 Windows로부터 명확히 달라진 점은 Power Users의 문제점으로 인해 거의 모든 Power User ACE가 없어졌다는 것입니다. 이제 Power Users는 다른 사용자들보다 강력한 것으로 간주되지 않습니다. 그래도 Power Users의 ACE가 모두 제거되지는 않았다는 사실은 ACL이 실제로 얼마나 복잡한 것인지 보여 주는 증거라 할 수 있습니다. 안타깝게도 몇 개는 누락된 것입니다.
레지스트리의 ACL을 살펴보면 몇 군데에서 RESTRICTED라는 SID의 ACE를 볼 수 있습니다. 이 SID는 Windows Vista에서 처음 등장한 것은 아니지만 잘 알려지지는 않은 SID입니다. RESTRICTED SID는 제한 토큰을 표시하는 모든 프로세스를 나타냅니다. 제한 토큰은 CreateRestrictedToken API의 특수한 기능을 통해 생성됩니다. 이러한 토큰은 하나 이상의 제한 SID(별도의 액세스 확인에 사용되는 SID)를 갖고 있습니다. 예를 들어 제한 토큰으로 실행되는 프로세스가 있다고 가정할 경우, 이 프로세스가 RESTRICTED SID에 대한 ACE를 통해 개체 액세스를 시도하면 사실상 Windows가 두 번의 액세스 확인 작업을 수행합니다. 첫 번째는 일반적인 액세스 확인이고, 두 번째는 첫 번째와 똑같은 작업을 토큰의 제한 SID에 대해서만 수행하는 것입니다. 이 두 가지 액세스 확인이 모두 통과해야 합니다.
현재 RESTRICTED SID를 사용하는 몇 가지 ACL(특히 레지스트리에)이 있습니다. 그림 7은 이러한 ACL의 스크린샷입니다.
그림 7** Registry ACL의 몇 군데에 RESTRICTED에 대한 ACE 포함 **
현재는 특히 제한 SID와 관련하여 제한 토큰 기능을 사용하는 프로세스가 거의 없습니다. 제한 토큰 기능을 사용하는 프로세스의 예를 한 가지 들면 Windows 방화벽, 기본 필터링 엔진 및 진단 정책 서비스를 호스팅하는 서비스 프로세스가 있습니다. 이 프로세스는 쓰기 제한 토큰도 사용합니다. 필자가 찾아본 바로는 현재 Windows Vista에서 RESTRICTED 및 쓰기 제한 토큰을 사용하는 서비스는 9개뿐입니다.
비교적 최근에 출시된 기존 버전의 Windows와 마찬가지로 레지스트리 사용 권한과 관련하여 가장 바람직한 방침은 최대한 신중을 기하는 것입니다. 예외적이고 명백한 목적이 있는 상황 외에는 레지스트리의 사용 권한을 수정하지 마십시오. 레지스트리에서 수행되는 민감한 작업과 복잡한 상속 모델을 감안할 때 레지스트리의 ACL을 잘못 수정하면 치명적 오류가 발생할 가능성이 매우 높아집니다.
요약
대부분의 다른 Windows 버전과 마찬가지로 Windows Vista에서도 액세스 제어에 대해 몇 가지 미묘한 변경이 수행되었습니다. 그러나 최근 출시된 일부 다른 버전과 달리 사소한 변경 사항이 많기 때문에 전체적으로는 액세스 제어 동작이 상당히 변화되었다고 할 수 있습니다. 특히 UAC는 무결성 레이블과 ACL UI의 수정 등 몇 가지 변화가 필요했습니다. 또한 최초로 대규모 ACL 정리 작업이 수행되었습니다.
여러 가지 면에서 Windows의 기본 ACL은 Windows Vista에서 많이 단순해졌으며 이는 최초의 시도라 할 수 있습니다. 그러나 이전 버전과 마찬가지로 액세스 제어에 있어서는 철저히 파악하기 전까지 매우 신중한 자세를 유지해야 합니다. 새로운 OS 버전에서는 특히 조심해야 합니다. 이 컬럼에서 소개된 여러 도구가 여러분의 ACL 관련 작업에 큰 도움이 되기를 바랍니다.
Jesper M. Johansson은 소프트웨어 보안 문제 분야의 수석 보안 엔지니어이며 TechNet Magazine의 객원 편집자로서, MIS 박사 학위를 보유하고 있으며 컴퓨터 보안 분야에서 20여 년 활동해왔습니다. 이 칼럼은 Roger Grimes와 Jesper Johansson의 신간 서적 Windows Vista Security: Securing Vista Against Malicious Attacks(Wiley, 2007)에서 일부를 발췌하여 재구성한 것입니다.
© 2008 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..