Windows 구조와 계정·인증 | 정보보안기사 필기

1. Windows는 사용자 모드와 커널 모드를 분리한다

Windows에서 실행되는 코드는 크게 사용자 모드(User Mode) 와 커널 모드(Kernel Mode) 로 나누어 이해할 수 있다.

사용자 모드

일반 응용 프로그램과 많은 사용자 영역 서비스는 사용자 모드에서 실행된다. 사용자 모드 프로세스는 각자 독립된 가상 주소 공간을 가지며, 다른 프로세스나 운영체제의 핵심 메모리에 임의로 접근할 수 없도록 제한된다.

이 분리는 보안상 중요하다. 일반 프로그램 하나가 오류를 일으켰다고 해서 곧바로 커널 메모리나 다른 프로세스의 데이터를 자유롭게 변경할 수 있어서는 안 되기 때문이다.

커널 모드

커널, 핵심 메모리 관리·스케줄링 기능, 많은 장치 드라이버 등은 더 높은 권한의 커널 모드에서 동작한다. 커널 모드 코드는 시스템 전체에 큰 영향을 줄 수 있으므로, 이 영역의 결함이나 악성 코드는 사용자 모드 프로그램보다 훨씬 큰 피해를 만들 수 있다.

따라서 다음 관계를 기억한다.

사용자 모드: 일반 프로그램을 제한된 실행 영역에서 격리
커널 모드: 운영체제 핵심 기능과 높은 권한이 필요한 코드가 동작
보안 목적: 일반 프로세스가 운영체제 핵심 자원에 직접 접근하지 못하도록 경계를 형성

2. 로컬 계정과 도메인 계정은 ‘누가 계정을 발급하고 검증하는가’가 다르다

Windows 계정을 이해할 때 가장 먼저 구분해야 할 것은 로컬 계정(Local Account) 과 도메인 계정(Domain Account) 이다.

구분	로컬 계정	도메인 계정
계정의 기준 범위	한 Windows 장치	Active Directory 도메인
계정 정보의 주 저장 위치	로컬 SAM 데이터베이스	도메인 컨트롤러의 Active Directory
인증을 최종적으로 판단하는 주체	해당 로컬 컴퓨터	도메인 컨트롤러
대표 표기	`PC01\\kim` 또는 `.\\kim`	`CORP\\kim`
주 용도	해당 장치의 로컬 자원 사용	여러 도메인 자원에서 중앙 신원 사용

같은 kim이라는 표시 이름을 사용하더라도 PC01\kim과 CORP\kim은 서로 다른 보안 주체가 될 수 있다. 두 계정은 서로 다른 보안 기관이 발급하며 SID도 다르다.

SAM은 로컬 계정 데이터베이스다

SAM(Security Accounts Manager) 은 Windows의 로컬 사용자와 로컬 그룹 정보를 관리하는 데이터베이스다. 워크스테이션이나 멤버 서버의 로컬 계정은 SAM에 저장된다.

여기서 다음을 구분한다.

SAM: 로컬 계정·그룹을 위한 데이터베이스
Active Directory Domain Services(AD DS): 도메인 계정·컴퓨터·그룹 등 도메인 디렉터리 정보를 관리

즉 “Windows 계정은 모두 SAM에 저장된다”는 설명은 틀리다. 도메인 계정은 도메인 컨트롤러의 Active Directory가 관리한다.

SAM은 ‘평문 비밀번호 파일’이 아니다

로컬 계정의 인증 정보는 SAM 데이터베이스와 Windows 보안 메커니즘에 의해 보호된다. 비밀번호를 그대로 읽을 수 있는 평문 문자열 목록으로 저장한다고 이해하면 안 된다. 시험에서는 SAM을 로컬 계정·인증 정보와 연결된 보호 대상으로 이해하는 것이 중요하다.

SAM은 레지스트리 하이브의 일부이며 디스크에서는 일반적으로 %SystemRoot%\System32\Config\SAM과 연결된다. 이 경로를 아는 것보다 더 중요한 것은 일반 사용자가 임의로 읽고 수정하지 못하도록 보호해야 하는 중요한 인증정보 저장소라는 점이다.

3. SID는 Windows가 보안 주체를 식별하는 고유 식별자다

SID(Security Identifier, 보안 식별자) 는 사용자·그룹 같은 보안 주체를 고유하게 식별하는 값이다.

Windows는 화면에 표시되는 계정 이름이 바뀌어도 보안 판정에서는 SID를 기준으로 주체를 식별한다. 이 때문에 계정 이름과 SID를 같은 것으로 생각하면 안 된다.

예를 들어 다음과 같은 SID를 생각해 보자.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.

S-1-5-21-111111111-222222222-333333333-1001

이 문자열을 시험 수준에서 지나치게 세부적으로 분해할 필요는 없지만, 다음 정도는 이해해야 한다.

S: SID임을 나타냄
앞부분: SID 버전과 식별 기관(Authority) 관련 정보
21-...: 로컬 컴퓨터 또는 도메인과 연결되는 식별 영역
마지막 값: 해당 영역 안에서 계정을 구분하는 RID(Relative Identifier) 로 사용될 수 있음

기본 Administrator의 RID는 500, Guest의 RID는 501이다. 계정 이름을 바꿔도 SID는 유지되지만, 계정을 삭제하고 같은 이름으로 새로 만들면 새로운 SID가 부여된다.

중요한 판단은 다음과 같다.

Windows 접근통제에서 계정 이름은 사람이 보기 위한 이름이고, 실제 보안 객체와 ACL은 SID를 기준으로 주체를 식별하는 경우가 핵심이다.

4. 인증은 LSA/LSASS를 중심으로 계정의 신원을 검증한다

Windows 로그온에서 핵심 역할을 하는 구성요소가 LSA(Local Security Authority, 로컬 보안 기관) 이다. 실제 Windows 시스템에서는 LSASS(Local Security Authority Subsystem Service) 프로세스가 LSA 보안 기능을 호스팅하며 로컬 보안 정책, 로그온 세션, 인증 관련 처리를 담당한다.

로그온 흐름을 단순화하면 다음과 같다.

사용자가 사용자 이름, 비밀번호, PIN, 인증서, 생체정보 등 사용 가능한 자격 증명을 제시한다.
Windows의 로그온 구성요소가 이 정보를 인증 시스템에 전달한다.
LSA/LSASS가 적절한 인증 패키지와 계정 기관을 이용해 신원을 검증한다.
로컬 계정이면 로컬 SAM 정보가 사용된다.
도메인 계정이면 도메인 컨트롤러와 Active Directory가 신원 확인에 참여한다. 이 흐름은 온라인 도메인 인증을 단순화한 것이며, 캐시된 로그온 정보로 오프라인 로그온하는 경우도 있다.
인증에 성공하면 해당 사용자의 보안 컨텍스트와 접근 토큰이 만들어진다.
이후 프로세스는 이 토큰을 바탕으로 자원 접근 권한을 판정받는다.

5. Kerberos와 NTLM은 ‘Windows 인증 구조 전체’가 아니라 인증 프로토콜이다

Windows 도메인 환경에서 자주 등장하는 인증 방식으로 Kerberos와 NTLM이 있다.

Kerberos: Active Directory 도메인 환경에서 널리 사용되는 티켓 기반 네트워크 인증 프로토콜
NTLM: 이전 버전과의 호환, Kerberos를 사용할 수 없는 일부 상황 등에서 사용될 수 있는 챌린지-응답 기반 인증 프로토콜

이 둘을 LSA나 SAM과 같은 종류로 보면 안 된다.

개념	역할
LSA/LSASS	Windows의 로컬 보안·로그온·인증 처리 중심 구성요소
SAM	로컬 계정·그룹 데이터베이스
Active Directory	도메인 계정과 디렉터리 정보 관리
Kerberos / NTLM	인증 과정에서 사용될 수 있는 챌린지-응답 기반 인증 프로토콜·패키지 계열

따라서 “LSA가 NTLM이다” 또는 “SAM이 Kerberos를 저장하는 파일이다” 같은 표현은 잘못된 연결이다.

6. 인증 성공의 결과는 ‘접근 토큰’으로 이어진다

사용자 인증이 성공하면 Windows는 해당 로그온 세션의 보안 컨텍스트를 나타내는 접근 토큰(Access Token) 을 만든다.

접근 토큰에는 대표적으로 다음 정보가 포함된다.

사용자의 SID
사용자가 속한 그룹의 SID
사용자에게 부여된 권한(Privileges)
접근검사에 필요한 기타 보안 속성

Windows 프로세스는 이 접근 토큰을 자신의 보안 컨텍스트로 사용한다. 따라서 어떤 프로그램이 파일을 열려고 할 때 Windows는 단순히 “이 프로그램 이름이 무엇인가”를 보는 것이 아니라, 그 프로세스가 어떤 사용자·그룹·권한을 가진 토큰으로 실행되고 있는가를 확인한다.

인증과 인가를 구분한다

인증(Authentication): “너는 누구인가?”를 확인
인가/권한 판정(Authorization): “확인된 네가 이 자원에서 이 작업을 해도 되는가?”를 판단

예를 들어 kim 사용자가 비밀번호를 올바르게 입력해 로그온에 성공했다면 인증은 성공한 것이다. 그러나 C:\Finance\salary.xlsx 파일의 ACL이 Finance 그룹만 읽을 수 있도록 되어 있고 kim이 그 그룹에 속하지 않는다면 파일 읽기는 거부될 수 있다.

즉 인증 성공 ≠ 모든 접근 허용이다.

7. 관리자 계정으로 로그인해도 모든 프로그램이 항상 최고 권한으로 실행되는 것은 아니다

Windows의 UAC(User Account Control, 사용자 계정 컨트롤) 때문에 관리자 그룹에 속한 사용자라고 해서 모든 일반 프로그램이 항상 전체 관리자 권한으로 실행되는 것은 아니다.

일반적인 관리자 승인 모드에서는 관리자가 로그인할 때 표준 사용자 수준으로 사용하는 토큰과 관리자 작업에 사용할 수 있는 높은 권한의 토큰이 분리되어 관리된다. 평소 프로그램은 제한된 토큰으로 실행되고, 관리자 권한이 필요한 작업에서는 사용자에게 승인 또는 자격 증명을 요구해 권한 상승(Elevation) 을 수행할 수 있다.

따라서 다음 문장은 구분해야 한다.

“이 사용자는 Administrators 그룹 구성원이다.”
“현재 이 프로세스가 관리자 권한으로 상승되어 실행 중이다.”

두 문장은 같은 뜻이 아니다.

권한 상속을 단순화해서 외우지 않는다

자식 프로세스는 일반적으로 부모 프로세스의 보안 컨텍스트를 이어받을 수 있지만, UAC의 권한 상승처럼 별도의 보안 절차를 거쳐 다른 수준의 토큰으로 프로세스를 시작할 수도 있다. 따라서 “상위 권한 프로세스의 자식은 무조건 같은 권한”처럼 절대적인 규칙으로 외우면 안 된다.

8. 작은 사례로 전체 흐름 연결하기

회사 PC PC01이 Active Directory 도메인 CORP에 가입되어 있다고 가정한다. 이 장치에는 로컬 계정 PC01\kim도 있고 도메인 계정 CORP\kim도 존재할 수 있다.

상황 A - 로컬 계정으로 로그온

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.

로그온 이름: PC01\kim
계정 기관: PC01
인증 정보: 로컬 SAM
결과: PC01에서 유효한 로컬 보안 주체의 접근 토큰 생성

이 계정은 해당 장치의 로컬 권한에 따라 자원을 사용할 수 있다. 같은 이름의 도메인 계정과는 다른 SID를 가진 별개의 주체다.

상황 B - 도메인 계정으로 로그온

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.

로그온 이름: CORP\kim
계정 기관: CORP 도메인
인증: 도메인 컨트롤러가 참여
결과: 도메인 사용자 SID와 그룹 정보가 반영된 보안 컨텍스트 생성

이 계정은 도메인에서 부여된 그룹과 권한을 이용해 파일 서버·업무 시스템 같은 네트워크 자원에 접근할 수 있다.

상황 C - 로그온은 성공했지만 파일 접근은 실패

CORP\kim의 인증은 성공했지만 대상 파일의 ACL이 CORP\Finance 그룹에만 읽기를 허용한다고 하자. kim이 Finance 그룹 구성원이 아니라면 인증은 성공했어도 파일 접근은 거부될 수 있다.

이 사례가 Windows 보안에서 가장 중요한 연결이다.

계정 → 인증 → SID·그룹 → 접근 토큰 → ACL/정책 → 허용·거부