2.5.1 사용자 계정 관리

1. ISMS 원본

인증기준

정보시스템 사용자 계정의 등록·변경·삭제·잠금 절차를 수립·운영하고, 신규/직무변경/퇴직 시점에 적시 반영한다.

개요·사례

적용 범위: ERP·HR·DB·OS·네트워크 장비 등 모든 정보시스템 사용자 계정
대표 통제 활동: 신청서 → 승인 결재 → 시스템 발급 → 적시 회수 → 휴면계정 정리 → 직무분리
빈출 결함 패턴:
- 퇴직자 계정 미회수 (가장 빈번)
- 신청서·승인 결재 없이 발급
- 신청자=승인자=처리자 (직무분리 위반)
- 공용 계정 무분별 사용 (관리자 1명이 admin 비번 공유)

2. ITGC 매핑

항목	값
분류	직접 (1-direct)
ITGC 영역	APD (Access to Programs and Data)
부영역	—
보조 영역	ELC/personnel (퇴직자 회수는 인사-IT 인계 entity-level 결함과 연결)

3. IT감사에서는 이렇게

3-A. 한국 비금융 ITGC 실무 표준 (실제 검증 범위)

2.5.1 = 회계감사 ITGC APD 영역의 핵심. 권한 부여 → 사용 → 회수 사이클 전반. 외부감사인이 결함 가장 자주 발견하는 영역 중 하나.

ISMS 요구	ITGC 테스트 절차	모집단	샘플
1. 등록·변경·삭제·잠금 절차 문서화	정책·절차 매뉴얼 입수 → walkthrough (entity-level)	정책 1건	1건 walkthrough
2. 신청 → 승인 → 처리 분리 (SoD)	권한 매트릭스 → 신청·승인·처리 동시 보유자 식별	전 권한 보유자	100% (rule-based)
3. 신규 발급 적시성	신청서·승인 결재·시스템 발급 일자 정합	감사기간 신규 발급 계정	샘플링
4. 퇴직자 회수 적시성	HR 퇴직자 명단 vs 시스템 사용자 마스터 대조, 회수 일자 ≤ 퇴직 일자 + N일	감사기간 퇴직자 전체	100% (rule-based)
5. 휴면계정 점검	휴면계정 잠금 절차 증빙 + 최근 로그인 일자 추출	전 사용자	샘플링 (또는 N개월 미접속자 rule-based 추출)
6. 공용 계정 통제	공용 계정 list + 사용자 식별 가능성(개별 비번·로그) 검증	공용 계정 전체	100%

3-B. ISMS-P가 추가로 요구하지만 ITGC 실무 범위 밖

ISMS 요구	절차	어디 영역
권한 변경 시 사용자 통지	변경 결재 → 본인 통지 절차	ISMS-P 인증심사
직무변경 시 신규 권한 적정성 판단	신규 업무 권한 적합 여부	현업 책임 영역 (2.5.6 검토 사이클에서 catch)
보안 서약·인식 교육과 연계	비밀번호 공유 금지 등	ELC/personnel (2.2.3·2.2.4)
외부자 계정 회수 검증	계약 종료 시 적시 회수	2.5.5 영역과 묶음

4. Q&A

Q1. 휴면계정 N개월 기준이 회사마다 다른데, 무엇을 기준으로?

A. ISMS는 "주기적 점검·잠금" 요구만. 구체 N 명시 X. 회사 내부 정책 문서화 + 일관 적용 입증이 ITGC 검증 포인트. 회계법인 ITGC 실무 감각 (공식 표준 자료 X. 회사·업종별 변동): 약 90일(금융권 강함) ~ 약 180일(비금융 일반). ITGC 결함 판단 = 정책과의 불일치이지 N 자체 절대값 X.

Q2. 공용 계정은 무조건 결함인가?

A. 무조건 X. 부득이한 사유 + 사용자 추적 가능 + 비밀번호 별도 관리가 충족되면 OK. 결함 판정 = 추적 불가능한 공용계정 (예: admin 1개로 5명 공용, 비번 공유, 로그상 누가 썼는지 모름).

불가피한 공용계정 보완통제 예시: 클라우드/DBA root 같이 기술적으로 공용이 불가피한 경우 → jump server(점프서버), sudo 로그, 세션 녹화 등으로 추적성 확보
ITGC·ISMS-P 검증 깊이: 정책·절차 + 로그 존재·점검까지가 표준. 점프서버 우회 경로 직접 검증(침투 테스트)은 ITGC·ISMS-P 모두 표준 절차 X (보안 진단 영역). 즉 회사가 "점프서버 도입했음 + 우회 차단 정책 있음 + 로그 점검함" 입증하면 ITGC·ISMS-P 통과

Q3. 메모리 덤프 막아야 하나? ITGC에서 어디까지 봐?

A. ITGC·ISMS-P 인증 모두 일반적으로 그 단위까지 안 봄. 보안조직(SOC)·침투 테스트 영역.

현실 (한국 시장):
- 일반 비금융 ITGC = OS/DB 슈퍼유저(root/Administrator/sa) 보유자 list + 회수 절차 + 사용 로그 정도까지. SeDebugPrivilege 같은 세분 권한 검토 X
- 금융권 ITGC도 동일. 전자금융감독규정상 슈퍼유저 통제 의무지만 메모리 덤프 명시 X
- ISMS-P 인증심사원도 2.5.5 특수권한 = root/admin/sa 일반 슈퍼유저 단위로 봄. 메모리 덤프 권한 세분 검토 X. KISA 안내서·결함사례에도 명시 X
- 메모리 덤프(Mimikatz 등)는 보안조직(SOC) 운영·침투 테스트 영역이지 ITGC·ISMS-P 인증 심사 영역 아님
만약 클라이언트가 의뢰한다면:
- 별도 정보보호 컨설팅·보안 진단 계약으로 분리
- ITGC·ISMS-P 표준 절차로는 ROI X
예외적으로 보는 경우:
- SOX 대상 미국 클라이언트 (일부 빅4 방법론에 SeDebugPrivilege 명시)
- 강화된 보안 진단 의뢰가 별도로 들어왔을 때
- 한국 ITGC는 거의 X
결론: 본 질문은 ITGC·ISMS-P 영역 회색지대 질문이지만 답은 "안 본다"가 정직. ITGC에서 보는 것 = 슈퍼유저 보유자 list + 회수 + 사용 로그까지. 그 위는 보안 영역

Q4. SSO·IDM 도입 클라이언트는 테스트 어떻게?

A. 자동통제 1건 샘플 + ITGC 일반통제 의존이 국룰. IDM 없음 ≠ 결함.

자동통제(Automated Control) 테스트 원리:
- 시스템 설정대로 모든 케이스 동일 처리 → 1건 샘플로 동작 검증
- ITGC 일반통제 가 effective여야 자동통제 신뢰성 보장:
  - PC = IDM 설정 변경 통제
  - APD = IDM admin 권한 통제
- ITGC 일반통제 OK + 자동통제 1건 OK = 모든 케이스 동일 작동 추론
IDM 도입 환경 표준 테스트:
- 모집단: 감사기간 HR 퇴직자 1건 샘플
- Test step:
  1. HR 퇴직 결재 시점 확인
  2. IDM 자동 회수 워크플로우 실행 로그
  3. 시스템 사용자 마스터에서 회수 결과
  4. 회수 일자 ≤ 퇴직 일자 + N일
- ITGC 일반통제 별도 검증: IDM 설정 변경 통제, IDM admin 권한
IDM 없는 환경 (수기 통제):
- 모집단: 감사기간 HR 퇴직자 전체
- 샘플링 또는 100% rule-based 대조 (HR list vs 시스템 사용자 마스터)
- IDM 없음 ≠ 결함. 수기로 적시 회수 입증되면 OK
결함 판단:
- 자동통제 1건 샘플 결함 → 즉시 결함 + 100% 모집단 확대
- ITGC 일반통제 결함 (IDM 설정 무통제, IDM admin 무관리) → 자동통제 신뢰성 X → 100% 확대
- 수기 통제에서 회수 지연·누락 → 결함
- ITGC 일반통제 OK + 자동통제 1건 OK → OK
HR 퇴직자 모집단 대조는 ISMS-P 명시 X:
- ISMS-P 2.5.1 본문은 "절차 수립·운영, 적시 반영" 요구만. 구체 모집단·테스트 절차 명시 X
- "HR 퇴직자 vs 시스템 마스터 100% 대조"는 회계감사 ITGC 표준 절차이지 ISMS-P 지침 X
- ISMS-P 인증심사원도 절차 문서 + 적용 사례 인터뷰 위주. 모집단 100% 대조는 안 함
- 즉 양 자료의 검증 깊이가 다름. 같은 인증기준이어도 절차는 회계감사 ITGC 쪽이 정량적

Q5. 신청서 부재 = 무조건 결함?

A. 원칙적으로 결함. 다만 시스템상 권한 변경 이력(audit log) + 승인 결재 증빙이 신청서 역할 대체하면 보완 인정 가능. 단, 회사 정책상 신청서 의무 명시되어 있는데 없으면 결함 (정책 위반).

Q6. 퇴직자 적시 회수 — '적시'의 기준은? 적시 회수 안 된 게 자동 결함?

A. N 절대값 명시 X (KISA·ITGC 모두 회사 정책 우선) + 결함 판단은 영향 평가 거쳐야 함.

6-1. '적시' 회계법인 ITGC 실무 감각 (공식 표준 자료 X. 회사·업종별 변동)

산업·계정 유형	회계법인 ITGC 실무 감각
금융권·핀테크 일반 사용자	약 24시간 이내
금융권·핀테크 특수권한자 (admin/root)	즉시 (퇴직 결재 시점)
비금융 대기업 일반 사용자	약 1~3 영업일
비금융 중소 일반 사용자	약 7~14 영업일
외부자·계약직 (전 산업)	계약 종료 즉시
임원·주요직무자	일반보다 빨라야 (위험 가중)

6-2. KISA 안내서·결함사례 표현

KISA는 절대 N 명시 X. 다음 표현 사용:

본문: "지체 없이" 계정 삭제·정지 (즉시 또는 합리적 단기간)
빈출 결함사례: "매월 초 일괄 회수 → 최대 29일까지 권한 회수 안 됨" 형태로 batch 회수 패턴 지적
인사시스템 연계 자동 회수 권장 (의무 X)

→ 월 단위 batch 회수는 KISA 결함사례 빈출 패턴. "지체 없이" 위반 해석

6-3. 결함 판단 ≠ 자동. 영향 평가 거침

회계감사 ITGC 결함 등급:

통제 결함 (Control Deficiency) — 통제가 설계·운영대로 작동 안 함 (1차)
유의적 결함 (Significant Deficiency) — 재무제표 신뢰성에 합리적 영향 (2차) — 한국 KSA 265 정의 영역
중요한 취약점 (Material Weakness) — 재무제표 중요한 왜곡 가능성 (3차) — PCAOB AS 2201 분류 차용. 한국 KSA 265 본문에 명시 X. 빅4 방법론·SOX 대응에서 통용

영향 평가 요소:

회수 지연 케이스 비율 (1/30 vs 10/30)
퇴직자 권한 수준 (일반 vs ERP 마스터 수정 vs DB admin)
시스템 위험도 (재무제표 핵심 영향 시스템 vs 비핵심)
지연 기간 (1일 vs 1개월+)
퇴직 후 실제 활동 발생 여부 (로그상 미접속 vs 활동 O)
보완통제 작동 (모니터링·이상행위 탐지·MFA 잠금)

예시:

퇴직자 1명, 7일 지연, 일반 사용자, 퇴직 후 로그인 X → 통제 결함 (보고하되 영향 작음)
퇴직자 10명 중 3명, 30일+ 지연, ERP 권한, 퇴직 후 로그인 발견 → 유의적 결함 또는 중요한 취약점
외부자 1명, 1주일 지연, ERP 마스터 권한, 활동 X → 위험 가중 (외부자) → 유의적 결함 가능

6-4. ISMS-P 인증심사 시각

회계감사보다 결함 미세화 X. 통상:

결함 발견 시 보완 권고 또는 재심사
영향 큰 결함 (대량·핵심 시스템·외부자) = 인증 거부 또는 중대 결함
단일 1명 단기 지연 = 일반적으로 보완 권고 수준