The Machine SID Duplication Myth

원문 : http://blogs.technet.com/markrussinovich/archive/2009/11/03/3291024.aspx
본 글은 연속성이 결여된 번역 작업과 제 허접한 영어 및 컴퓨팅 시스템에 대한 이해도로 인한 오역이 다소 존재 할 수 있습니다.
본 글의 모든 권리는 원문 저자에 있습니다.

2009년 11월 3일을 마지막으로 시스인터널의 NewSID(Machine Security Indentifire / machine SID 를 변경하는 유틸리티)는 역사의 뒤안길로 사라졌습니다. 전 1997년에 NewSID를 NTSID라는 이름으로 개발했습니다. 그 당시에는 MS의 Sysprep 라는 유일한 SID 변경 툴이 있었지만, 그 마저도 어플리케이션이 설치된 이후에는 쓸 수가 없었습니다. 머신 SID는 Windows 설치 시 생성되는 식별자로써 Windows에서는 관리자가 생성한 로컬 계정과 그룹 SID의 기본값으로 사용하게 됩니다. 사용자가 로그인하게 되면 사용자는 시스템은 사용자 계정의 SID와 그룹 SID를 통해 시스템상의 각종 오브젝트의 접근 권한을 체크합니다. 만약 2개의 머신이 동일한 SID를 가지고 있다면 계정이나 그룹의 SID 역시 동일할것입니다. 이 때문에 동일한 SID를 갖는 다수의 컴퓨터들은 보안상 문제를 야기할 수 있겠죠? 그렇지 않을까요? 이것이 바로 우리가 전부터 알던 지식이였습니다.

사람들은 Windows Vista에서 NewSID를 유용하게 사용한다고 했지만 내 스스로 NewSID를 완벽하게 테스트 하지도 못했고, 종종 NewSID 적용 이후 Windows의 일부 컴포넌트들이 실패를 한다는 애기를 듣고 NewSID를 은퇴시키기로 마음 먹었습니다. 차분하게 않아 레포트를 들어다 보면서 전 모두가 알고있는 “SID가 중복되면 문제가 일어난다” 부터 차분하게 다시 생각하기 시작했습니다. 차분하게 생각하고 생각한 결과 SID 중복은 문제가 아닐 수 있다는 확신을 갖게 되었습니다. 다른 말로 동일한 SID를 갖는 머신들이 있더라도 별 보안상의 문제가 아니라는 것이죠. 전 윈도우 개발팀과 보안팀과 함께 위와 같은 결론을 냈는데, 우리 중 누구도 도메인이나 Workgroup 환경에서 SID 중복이 문제를 일으키는 시나리오에 대한 증명을 하지 못했습니다. 이게 발로 NewSID가 역사의 뒤안길로 사라지게 된 이유입니다.
윈도우즈 NT의 시작부터 이미지 형태의 배포에서 신념처럼 SID를 변경했었는데 이 SID의 중복이 별 문제가 없다는 것은 정말 엄청난 충격으로 다가왔다. 본 포스트는 이 SID의 중복과 관련된 신화의 실체를 폭로할 것이다. 우리는 먼저 머신 SID의 표현 방식에 대해 알아보고 어떻게 윈도우즈에서 SID를 사용하는지 그리고 단하나의 예외 상황까지 모두 보여줄 것이다.
윈도우즈는 절대 자신의 머신 SID를 외부에 노출하지 않는다. 이는 바로 시스템이 중복 SID를 갖더라도 무방하다는 증거가 된다. Sysprep는 머신의 특정한 상태를 리셋한다는 것을 기억하자 물론 이 SID가 중복이 된다면 특정 어플리케이션(Windows 서버 업데이트 서비스와 같은)에서는 문제가 될 수 있다. 그래서 여전히 마이크로소프트는 복제 이미지 기반의 배포등을 이용할때는 Sysprep를 통해 SID를 유니크하게 만들어 줄것을 권고하고 있다.

SIDs
윈도우즈는 단지 머신 뿐만이 아닌 모든 보안 Principle들을 표현하기 위하여 SID를 사용한다. 보안 Principle은 머신과 도메인 환경의 유저와 사용자 그리고 보안 그룹들을 모두 포괄하는 개념이다.
이름이라는 건 단지 SID를 사용자 편의에 맞춰 표현해 놓은 것에 불과하다. 이름을 변경한다고 해도 이미 ACL에서 계정의 변경된 부분을 반영하고 있기 때문에 굳이 ACL을 변경해 줄 필요는 없습니다. (역 주 : 왜냐하면 내부적으로는 SID를 이용하여 ACL을 정의 하기 때문에 이름이 변경되도 이 SID는 변경되지 않습니다.)

SID는 가변길의 숫자 값들로 이루어져 있는데, 이는 스트럭처 리비전 번호와 48비트의 아이텐티파이어 오소리티 값 그리고 가변길이의 32비트 서브오소리티값과 RID로구성되어 있습니다. 이 authority 값을 통해 SID를 발급하는 에이전트를 구분하게 됩니다. 이런 에이전트는 일반적으로 윈도우즈의 로컬 시스템이거나 도메인이 됩니다. (역 주 : SID의 앞단의 indetifier authority를 에이전트라고 부르는데, 이값을 기본으로 SID가 구성되게 되기 때문에 에이전트라 하고 있습니다.) 그리고 subauthority 값을 통해 issuing authoriy 와 연관되어 수탁받은 권한들을 확인하며, RID는 윈도우즈에서 base SID를 통해 유니크한 SID를 만드는 간단한 방법을 제공합니다.

여러분은 Sysinternals 의 PsGetSid 툴을 단순히 실행 하는 것만으로 머신의 SID를 확인 할 수 있습니다.

보시면 리비전 넘버가 1번이고 오소리티는 5번 입니다. 그리고 4개로 이루어진 서브오소리티 값들이 있습니다. 중요한 점은 윈도우즈 엔티가 머신의 SID가 네트워크상의 아이덴티피케이션으로 사용될 수 도 있다는 염두를 해 두고 디자인 됐다는 점입니다. 즉 이 아이텐디티의 유일성을 보장하기 위하여 1개의 (21) 고정된 서브오소리티 값과 3개의 렌덤하게 생성된 값이 만들어지게 됩니다. (S-1-5-21 뒤에 나오는 숫자들)

첫번째 유저를 만들지 않았더라도 윈도우즈는 몇개의 빌트인 유저 및 그룹들을 정의해놓고 있는데 이 속에는 administrator 나 Guest 계정들이 포함되어 있습니다. 윈도우즈는 위와 같은 유저들을 위한 렌덤한 SID 생성 대신에 각 유저마다 RID라 불리는 간단한 유니크한 숫자들을 SID에 추가로 붙여 각 계정의 SID의 유일성을 보장하게 됩니다. 위와 같은 유저들은 RID이 이미 정의 되어 있습니다. 예를 들어 Administrator의 경우 RID는 항상 500이 되게 되죠.

설치가 끝난 후 새로운 계정이나 그룹의 RID는 1000부터 시작하게 됩니다. 여러분은 PsGetSid를 통해 특정 계정의 SID를 확인 할 수 있는데, 아래 그림의 Abby 계정(윈도우즈 설치 과정에서 관리자 권한으로 생성한 계정)의 RID는 1000임을 볼 수 있습니다.

추가적으로 윈도우즈가 먼저 정의해놓은 SID들중 RID를 사용하지 않는 녀석들도 있습니다. 예를 들자면 Everyone 그룹이 이에 해당하는데 이 Everyone은 모든 윈도우즈 시스템에서 S-1-1-0의 SID를 갖습니다.

또다른 예로 로컬 시스템 계정 (System) 역시 마찬가지 입니다. (시스템 프로세인 SMSS.exe 나 Services.exe, Winlogon.exe 를 실행 시키는 계정)

SIDs and Access Control Lists

Local Security Authority Subsystem (LSASS -Lsass.exe) 은 계정이 윈도우에 로그인 할 때 로그온 세션과 토큰을 만듭니다. 이 토큰은 윈도우의 커널 정의한 구조체인데, 이 토큰은 계정과 해당 시점에 인증된 이 계정의 SID 및 해당 시점에 인증된 그룹의 SID 그리고 계정과 그룹 할당된 보안 권한 등을 나타냅니다. 로그온 세션에서 참조하고 있는 마지막 토큰이 삭제되면 LSASS는 로그온 세션을 삭제하고 유저는 로그 오프 한 것으로 추정되게 됩니다. 아래는 시스인터널스의 LogonSession 유틸리티로 본 제 인터렉티브 로그인 세션입니다.

여러분은 아래와 같이 프로세스 익스플로어의 핸들 뷰를 통해 세션을 위해 할당된 토큰을 확인 할 수 있습니다. 계정 명 뒤에 따라오는 번호 (7fdee) 를 기억하시고 이를 LogonSessions의 로그인한 세션의 ID와 맞춰 보시기 바랍니다.

기본적으로 프로세스들은 부모 프로세스의 토큰을 상속 받습니다. 예를 들어 인터렉티브 세션에서 동작하는 모든 프로세스는 Userint.exe 프로세스로(인터렉티브 로그온을 위해서 Winlogon.exe 가 생성한) 부터 상속된 토큰의 카피를 갖게 되는 것이죠. 여러분은 프로세스 익스플러어의 프로세스를 더블 클릭한 화면의 보안 탭을 통해 해당 내용을 확인 할 수 있습니다.

제 프로세스 중 하나가 OS object (파일, 레지스트리키 와 같은) 을 오픈 하면 보안 서브 시스템은 퍼미션 체크를 진행 합니다. 퍼미션 체크란 해당 오브젝트의 엑세스 컨트롤 리스트 (ACL / 프로세스 토큰의 SID를 참조)의 항목들에 대한 내용을 확인 하는 것을 의미합니다.

이와 유사한 확인은 원격 컴퓨터의 공유의 net use 를 통해 생성된 외부 로그온 세션에서도 확인 할 수 있습니다. 공유된 자원을 사용하기 위해서는 해당 외부 시스템이 확인 할 수 있는 계정을 통해 해당 시스템으로 부터 인증을 받아야 합니다. 만약 그 환경이 워크 그룹이라면 여러분은 해당 리모트 (외부) 시스템의 로컬 계정이여야 하고, 만약 도메인 환경이라면 여러분은 해당 리모트 시스템의 로컬 계정이거나 도메인 계정이여야 합니다. 여러분이 공유되어 있는 파일에 접근을 하게 되면 해당 시스템의 파일서버 드라이버는 로그온 세션의 토큰을 이용하여 권한을 확인하게 됩니다. 이런 레버리징 메커니즘을 임퍼스네이션이라고 부릅니다.

SID Duplication

마이크로소프트에서 제공하는 유일한 이미지 기반의 윈도우 배포 방법은 이미지로 윈도우를 배포한 후에 Sysprep 툴을 실행 하는 것입니다.  이를 이미지를 제네럴라이징 한다고 부르는데 그 이유는 여러분이 이 이미지로 만들어진 윈도우를 부팅할 때 Sysprep 이 새로운 SID 생성 및 PnP 하드웨어 디텍션, 제품 엑티베이션 클락 리셋, 컴퓨터 이름과 같은 데이터를 설정 진행하기 때문입니다.

어떤 IT 담당자들은 하나의 시스템에 어플리케이션을 설치하고 설정을 변경한 후 SID를 리셋 없이 이에 대한 카피본을 사용하는 경우가 있습니다.  지금까지 가장 좋은 방법은 NewSID와 같은 툴로 SID를 리셋하는 것이였습니다. 이 유틸리티는 새로운 머신 SID를 생성하고 파일 시스템과 레지스트리등의 ACL을 확인하여 모든 SID를 새로운 머신의 SID로 업데이트하는 역활을 했습니다. 마이크로소프트에서 Sysprep와는 다른 이런 방식의 시스템 변경을 지원하지 않았던 이유는 윈도우즈에서 감추고 있는 모든 머신 SID에 대한 참조를 알 수 없었기 때문입니다. 이러한 이유로 새로운 머신 SID와 이전의 변경되지 않는 SID가 공존하는 환경에 대한 안정성 및 보안은 게런티가 될 수 없는거죠…

자 같은 SID를 갖는 다수의 컴퓨터들은 문제가 될까요?  딱 한가지 윈도우들이 다른 컴퓨터의 머신 SID를 참조한다면 문제가 될 수도 있을 것입니다. 예를 들어 만약 여러분이 리모트 시스템에 접근할때 로컬 머신의 SID가 리모트 머신으로 전달 되고 이를 이용하여 권한을 체크한다면 시스템은 외부의 인바운드 계정과 로컬 머신의 같은 SID를 같는 로컬 계정을 구분할 수 없어 문제가 발생 하게 됩니다. (이 양 계정의 SID는 동일한 머신 SID 를 기반으로 동일한 RID를 갖고 있습니다.) 그러나 검토한 결과로는 윈도우즈는 여러분이 자신의 로컬 컴퓨터 만이 확인 할 수 있는 계정을 가지고 다른 컴퓨터로부터 인증을 받는 것을 허용하지 않습니다. 대신에 여러분은 리모트 시스템의 로컬 계정이나 리모트 컴퓨터가 트러스트한 도메인의 도메인 계정의 크리덴셜을 이용하여야 합니다. 리모트 컴퓨터는 SID를 조회하는데 로컬 계정의 경우 Security Accounts Database (SAM) 부터 조회하고, 도메인 계정인 경우 DC의 Active Directory 데이터 베이스로부터 조회합니다. 리모트 컴퓨터는 절대 연결되는 컴퓨터의 머신 SID를 참조 하지 않습니다.

즉 컴퓨터에 엑세스 하는 궁극의 방법은 SID가 아니라 계정 명과 패스워드입니다.. 간단히 말해서 리모트 시스템 계정의 SID를 알아 봤자 컴퓨터나 해당 머신 상의 어떤 자원에 대한 접근도 할 수 없고,. 좀더 들어가 보자면 SID는 충분한 인증 정보가 아닙니다. 기억하겠지만 Built – in 계정의 경우 모든 컴퓨터에서 동일한 SID 값을 갖기 때문에 만약 이게 가능하다면 이것 보안상의 아주 큰 문제가 되는 것이죠.

이전에 제가 언급했던 딱 하나의 예외는 DC들 자신들에 대한 것입니다. 모든 도메인은 도메인 셋업 시 유니크한 도메인 SID를 생성합니다. 그리고 모든 도메인 DC의 머신 SID는 도메인 SID로 매치 되게 됩니다.  이는 어떤 의미에서는 서로의 머신의 SID를 참조하는 것이죠. 이는 모든 도메인의 멤버 컴퓨터의 머신 SID는 DC의 머신 SID나 도메인의 SID와 절대 동일 할 수 없다는 것을 의미합니다. 그러나 각각의 DC 역시 멤버 컴퓨터들 처럼 도메인 내에서 컴퓨터 계정을 지니고 리모트 시스템에 접근할 경우 인증을 받아야 합니다.

몇몇의 SID 중복에 대한 아티클들을 보면 (KB 314828을 포함하여) 동일한 SID를 갖는 다수의 컴퓨터를 사용할 경우에 대한 우려를 제기하고 있습니다. (NTFS-formatted firewire disk와 같은 이동식 미디어의 경우 로컬 계정을 이용하여 Secure 할 수 없는 등의 / 역 주 왜냐하면 이동식 디스크의 ACL의 SID 값이 일부 계정의 경우 동일 하기 때문에 직접 다른 머신의 로컬로 붙을 경우 로컬 계정에 대한 혼선이 있을 수 있습니다.) 하지만 이는 기우에 불과합니다. 왜냐하면 이동식 미디어들은 보안에 대한 고려 자체가 없기 때문입니다. 왜냐하면 자 NTFS를 지원하지 않는 운영체제에서 해당 데이터에 접근한다고 생각합시다. 그 경우 사용자는 아무런 제약 없이 해당 리소스를 접근할 수 있지 않습니까? 게다가 이동식 미디어의 경우 administrators 그룹과 같이 모든 시스템에서 잘 알려진 SID에 대해서는 기본적인 접근 권한을 할당하고 있습니다. 이는 물리 보안과 윈도우즈 7에서 소계된 Bitlocker-to-go(이동식 스토리지의 데이터를 암호화하는)의 기본 개념입니다.

마지막 케이스로 만약 Distributed application 이 머신 SID을 고유 식별자로 사용한다면 문제가 될 수 도 있습니다. (예를 들어 모든 컴퓨터들이 사용하는 어플리케이션인데 이 어플리케이션들을 식별하기 위하여 머신의 SID를 사용하는 경우) 하지만 어떤 마이크로소프트의 소프트웨어도 이런 방식은 사용하지 않으며 머신 SID 역시 이런 일을 위해서 만들어 진 것이 아닙니다. 그리고 동일한 SID를 같은 DC들의 경우에는 이와 같은 경우 아예 제대로 동작하지 않는다고 봐야 합니다. 고유의 컴퓨터 식별자에 기반을 둔 소프트웨어는 컴퓨터의 이름이나 컴퓨터의 도메인 SID들을 이용하게 됩니다. (도메인 상의 컴퓨터 계정의 SID)

The New Best Practice

SID 중복에 관한 이슈가 꽤 오랫동안 제기 되지 않은 것은 좀 놀랄 만한 사실입니다. 정작 문제는 모든 사람들이 누군가는 정확히 알고 있을 꺼라 생각하고 있었다는 것입니다.. 제가 진짜 억울한 것은 NewSID가 어느짝에도 쓸모가 없었다는 것이고, 그게 바로 NewSID가 역사의 뒤안길을 밟더라도 아쉬워할 일 없다는 것 입니다. 기억하시기 바랍니다. Sysprep는 머신 설정을 재 리셋 해줍니다. (만약 이런 설정들이 중복된다면 WSUS 와 같은 어플리케이션에서는 문제를 일으킬 수 있습니다.)  그래서 마이크로소프트의 지원 정책은 여전히 복제 시스템에서는 Sysprep를 통해 유니크하게 만들어라 입니다.