gyumin.log

LSA·SAM·SRM

🌿 자라는 중

목차

윈도우 인증 구조의 두 축 - 하나는 검문하는 주체 3형제(LSA·SAM·SRM), 하나는 신분증 번호(SID)다. 비유 하나로 다 꿰어진다: 검문소 · 명부 · 집행관, 그리고 주민등록번호.

3형제 한눈에

비유하는 일
LSA (Local Security Authority)검문소모든 계정의 로그인 검증, 자원 접근 권한 검사, 보안·감사 정책 관리, 인증 성공 시 액세스 토큰 발급
SAM (Security Account Manager)명부계정·패스워드를 저장·관리하는 DB - 판단은 안 하고 저장만
SRM (Security Reference Monitor)집행관접근 허가/거부를 실제로 판단·집행하고 감사 로그 생성

전체 흐름: 인증에서 인가까지

윈도우 로그인부터 자원 접근까지 로그인 시도를 LSA가 접수해 SAM 명부와 대조하고 액세스 토큰을 발급하는 인증 단계, 이후 자원 접근마다 SRM이 토큰과 ACL을 비교해 허가/거부하고 감사 로그를 남기는 인가 단계 인증 (Authentication) - 너 누구냐 · LSA + SAM ① 로그인 시도 ID·패스워드 입력 ② LSA - 검문소 접수·검증 총괄 ③ SAM - 명부 저장된 해시와 대조 ④ 액세스 토큰 발급 SID가 담긴 통행증 토큰을 들고 다니며 접근 인가 (Authorization) - 너 이거 해도 되냐 · SRM ⑤ 자원 접근 시도 파일·프린터 열기 ⑥ SRM - 집행관 토큰(SID) vs ACL 비교 ⑦ 허가 or 거부 + 감사 로그 생성 LSA+SAM은 "너 누구냐"(인증), SRM은 "너 이거 해도 되냐"(인가) - HTTP 401 vs 403과 같은 축

로그인 시도 → LSA가 접수 → SAM 명부와 대조해 신원 확인 → 통과하면 LSA가 액세스 토큰 발급 → 이후 파일·프린터에 접근할 때마다 SRM이 토큰 vs ACL을 비교해 허가/거부 + 감사 로그.

여기서 인증(Authentication)과 인가(Authorization)가 갈린다 - LSA+SAM은 인증(너 누구냐), SRM은 인가(너 이거 해도 되냐). HTTP의 401(인증 실패) vs 403(인가 실패)과 정확히 같은 축이다.

SID - 권한의 기준은 이름이 아니라 번호

SID (Security Identifier): 사용자·그룹·컴퓨터 계정을 구분하는 고유 식별 번호. 핵심은 윈도우가 계정 이름이 아니라 SID로 권한을 판단한다는 것.

S-1-5-21-1004336348-1177238915-682003330-500
                                         └─ RID

맨 뒤의 RID (Relative Identifier, 상대 식별자)가 시험 단골:

RID계정
500Administrator (관리자)
501Guest
1000 이상일반 사용자 계정

여기서 함정 두 방향:

  • 이름을 바꿔도 SID는 그대로. 보안 조치로 “Administrator 계정 이름을 바꿔라”라고 하지만, 공격자가 SID를 조회해 RID 500짜리를 찾으면 그게 관리자인 걸 안다. 이름 변경은 초보적 공격만 막는 보조 수단이지 완전한 대책이 아니다.
  • 삭제 후 같은 이름으로 재생성하면 SID는 새로 발급. 그래서 예전 권한·파일 접근권을 물려받지 못한다. “이름이 같으니 권한도 같다”가 아니라 **“SID가 다르면 완전히 다른 사람”**이다.

SAM 파일 - 명부 그 자체를 지켜라

로그인하면 LSA가 입력받은 정보를 SAM에 조회해 대조하고, 일치하면 인증 성공. 시험에 나오는 건 세 가지:

  • 패스워드는 평문이 아니라 해시로 저장된다 (LM 해시 / NTLM 해시)
  • 실제 파일 위치: %SystemRoot%\System32\config\SAM - 경로를 그대로 묻는다
  • 이 파일이 유출되면 해시를 뽑아 오프라인 크래킹(레인보우 테이블, 무차별 대입)을 당한다. 그래서 SAM 파일 보호가 윈도우 보안의 핵심이고, SYSKEY로 한 번 더 암호화하는 기능이 있다

유닉스로 치면 /etc/shadow에 해당한다 - 유닉스 챕터에서 shadow 파일이 나오면 “SAM의 유닉스 버전”으로 연결하면 된다.

SRM = 참조 모니터의 윈도우 구현

이름에서 보이듯 SRM은 참조 모니터(Reference Monitor) 개념을 윈도우가 구현한 것이다. “참조 모니터 = 개념, 보안 커널 = 구현체”라고 할 때의 그 구현체의 윈도우판. 모든 접근이 시스템 콜이라는 “문”을 지나기 때문에, 그 문 앞에서 SRM이 토큰과 ACL을 검사할 수 있다.

시험 포인트

역할 바꿔치기가 단골이다. **“저장은 SAM, 인증은 LSA, 판단·집행은 SRM”**만 잡으면 전부 걸러진다.

  • 함정 1: “SAM이 접근 권한을 판단한다” → ✕. SAM은 저장만, 판단은 SRM.
  • 함정 2: “SRM이 계정 정보를 저장한다” → ✕. 그건 SAM.
  • 함정 3: “SRM이 로그인 인증을 수행한다” → ✕. 그건 LSA.
  • 함정 4: RID 숫자 - 500 = Administrator, 501 = Guest, 1000 이상 = 일반 사용자.
  • 함정 5: Administrator 이름 변경 → SID(RID 500)는 그대로. 같은 이름 재생성 → SID는 새로 발급.
  • 함정 6: SAM 파일 경로 %SystemRoot%\System32\config\SAM, 보호 기능은 SYSKEY.

한 줄: LSA는 인증하고 토큰 발급(검문소), SAM은 해시 명부(config\SAM, shadow 대응), SRM은 토큰 vs ACL로 인가+감사(집행관) - 권한의 기준은 이름이 아니라 SID.

연결되는 것들

  • SRM이 비교하는 그 ACL이 바로 NTFS의 권한 명부다 - 집행관이 읽는 규칙서
  • SRM이 지키는 “문”(시스템 콜)과 커널 모드 이야기 → 사용자 모드와 커널 모드
  • 누가 권한을 정하는가(MAC·DAC·RBAC) → 접근 통제