2.5.6 접근권한 검토

1. ISMS 원본

인증기준

정보시스템과 개인정보 및 중요정보에 접근하는 사용자 계정의 등록·이용·삭제 및 접근권한의 부여·변경·삭제 이력을 남기고 주기적으로 검토하여 적정성 여부를 점검하여야 한다.

주요 확인사항 (KISA 안내서)

사용자 계정 및 접근권한 생성·등록·부여·이용·변경·말소 등의 이력을 남기고 있는가?
적정성 검토 기준, 검토주체, 검토방법, 주기 등을 수립하여 정기적 검토를 이행하고 있는가?
검토 결과 과다 부여, 절차 미준수, 오·남용 등 문제 발견 시 조치 절차를 수립·이행하고 있는가?

계정·접근권한 이력 항목 (KISA 안내서, 책임추적성 확보)

구분	기록 항목
신청정보	신청자/대리신청자, 신청일시, 신청목적, 사용기간
승인정보	승인자, 승인 또는 거부 여부, 사유 및 일시
등록정보	등록자, 등록일, 등록방법 (결재시스템 연동·수작업 등록 등)
권한정보	대상 시스템명, 권한명, 권한 내역

보관 기간

개인정보처리자: 접근권한 기록 최소 3년 보관 (안전성 확보조치 기준)
점검: 안전성 확보조치 기준 제8조 = 접속기록 월 1회 이상 점검 의무. SIEM·rsyslog 같은 자동화 의무 X. 수기 점검 (체크리스트 + 월별 보고서)도 가능

검토 주기 (KISA 안내서)

KISA 안내서 명시: "최소 분기 1회 이상 권고"
권고 표현 (강제 X). 회사 위험평가 결과로 자율 조정 가능
회계법인 ITGC 실무 감각 (공식 표준 자료 X. 회사·업종별 변동): 분기 1회 = 대부분 회사 디폴트 / 반기 1회 = 일부 비금융 / 월 1회 = 금융권 일부

적정성 검토 항목 (KISA 안내서)

공식적인 절차에 따른 접근권한 부여 여부
접근권한 분류체계의 업무목적·보안정책 부합 여부
접근권한 승인자의 적절성
직무변경 시 기존 권한 회수 + 신규 업무 권한 적절 부여 여부
업무 목적 외 과도한 접근권한 부여 여부
특수권한 부여·변경·발급 현황·적정성 (2.5.5와 연결)
협력업체 등 외부자 계정·권한 적정성
접근권한 신청·승인 내역과 실제 권한 부여 일치 여부
장기 미접속자 계정 현황 + 삭제·잠금 여부
휴직·퇴직 시 지체 없이 계정·권한 회수 여부 (2.5.1과 연결)

조치 절차 (KISA 안내서)

소명요청·원인분석·보완대책·보고체계
변경 적용된 권한에 대해 사용자·관련자 통지
반복 시 근본 원인 분석·재발방지 대책

결함사례 (KISA 안내서)

사례 1: 검토 방법·점검주기·보고체계·오남용 기준 등이 지침에 구체적으로 정의 X → 정기 검토 미수행
사례 2: 장기 미사용자 계정 잠금·삭제 정책 있으나 6개월 이상 미접속 계정이 활성 (검토 충실 X)
사례 3: 검토 시 권한 과다 부여·오남용 의심 발견됐으나 상세조사·내부보고 등 후속조치 X

2. ITGC 매핑

항목	값
분류	직접 (1-direct)
ITGC 영역	APD (Access to Programs and Data)
부영역	—
보조 영역	ELC/policy (검토 정책 수립 — entity-level)

3. IT감사에서는 이렇게

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

권한 부여(2.5.1·2.5.5) → 사용 → 검토가 통제 사이클의 마지막 단계. ITGC 실무는 검토 정책 + 취합 보고서 + 모집단 walkthrough + 후속조치 양식·기재 건 확인 + 이력 보관 5개. 검토 모집단 IPE 100% 검증·세부 권한 적정성 판단(현업 영역)까지는 파지 않는다.

2.5.6 = ISMS-P와 한국 실무의 격차가 가장 큰 영역. ISMS-P는 분기 1회 검토 + 적정성 검증 항목 10개를 권고하지만, 한국 비금융에서 검토 사이클을 굴리는 회사 자체가 적고, 굴리더라도 형식적인 경우가 대부분. 다만 외부감사 ITGC가 의무화된 이상 검토 사이클 부재·형식 운영은 결국 결함으로 도출됨 — 사전 정비가 사후 결함 대응보다 비용이 낮다. ITGC 검증 시 "취합 보고서 존재 = OK" 박스 체크에 그치지 말고 검토 결과란이 실제로 채워졌는지·서명자가 본인 부서 적정성을 판단할 수 있는 위치인지까지 봐야 결함 발견 가능.

ISMS 요구	ITGC 테스트 절차	모집단	샘플
1. 검토 정책 수립	검토 기준·주체·방법·주기·보고체계 정의된 정책 문서 (entity-level)	정책 1건	1건 walkthrough
2. 검토 취합 보고서	부서별 검토 → 취합 보고서 샘플 (검토자 서명·검토 결과 기재 확인)	1년 검토 사이클	분기 사이클 2건 / 반기 사이클 1~2건 (PCAOB AS 2315 빈도 통제 차용 — 한국 KSA 530도 동일 원리)
3. 검토 모집단 신뢰성 (walkthrough)	검토 시 사용된 list가 시스템 추출본인지 1건 walkthrough. 100% rule-based IPE 검증은 X (외부감사 IPE 영역)	검토 list 1건	1건 walkthrough
4. 검토 결과 발견 건 후속조치	취합 보고서에 발견 건 기재 칸·후속조치 칸 존재 여부 + 기재된 발견 건 있으면 후속조치 확인. 발견 건 미기재로 1년 내내 "이상 없음" 패턴 = 형식 검토 결함 신호	기재된 발견 건 (보통 작음)	전수 가능
5. 이력 보관	부여·변경·삭제 이력 = 감사대상기간(통상 1회계년도) 보유면 ITGC 충족 (법적 보관 의무는 영역별 별도 — 접속기록 1년+은 2.9.4)	감사대상기간 이력	샘플 + 기간 검증

휴직·퇴직자 권한 회수, 장기 미접속자 처리, 외부자 계정·권한 회수 = 2.5.1 사용자 계정 관리 영역. 2.5.6은 검토 사이클 자체에 한정.

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

ISMS 요구	절차	어디 영역
검토 모집단 IPE 100% 검증	검토 list와 시스템 실제 추출 100% rule-based 대조	외부감사 IPE 영역 (비금융 ITGC는 walkthrough 수준만 — §3-A 행 3)
검토 결과 사용자 통지	권한 변경 시 본인 통지 절차	ISMS-P 인증심사
권한 분류체계의 업무목적 부합	분류체계 자체 적정성 검증	ISMS-P 인증심사
권한 오·남용 패턴 분석	UEBA·이상 사용 분석	보안 영역 (SIEM·SOC)

4. Q&A

Q1. 검토 주기 — KISA 분기 1회 권고가 강제인가?

A. 권고 표현. 강제 X. 다만 분기 1회가 사실상 표준. 회사 위험평가로 자율 조정 가능.

KISA 안내서 원문: "검토 절차 수립 (최소 분기 1회 이상 권고)"
"권고"이지 "강제" X. 회사 위험평가 결과로 반기·연 1회로 조정 가능 (단 충분한 보완 근거 필요)
회계법인 ITGC 실무 감각 (공식 표준 자료 X. 회사·업종별 변동):
- 분기 1회 = 대부분 회사 디폴트
- 반기 1회 = 일부 비금융 (위험 낮은 시스템)
- 월 1회 = 금융권 특수권한·고위험 시스템
결함 판단:
- 검토 사이클 자체 X → 결함 (KISA 결함사례 1번)
- 회사 정책 = 분기인데 실제 = 검토 X → 결함
- 회사 정책 = 반기 + 위험평가 근거 + 일관 적용 → OK
- 정책 + 사이클 + 결과 보고서까지 갖춘 게 통제 본질

Q2. 검토 주체 — IT팀? 보안팀? 현업 부서장?

A. 현업 부서장이 1순위. IT팀·보안팀은 검토 지원·결과 취합 역할. 현업이 권한 적정성 판단 가능한 유일한 주체.

현업 부서장 검토 (표준):
- 본인 부서원의 권한이 업무에 필요한지 판단 가능 = 현업뿐
- IT팀·보안팀은 "권한 분포 현황"만 보지 "이 사람이 이 권한 필요한지"는 모름
- 회사가 IT팀 단독 검토만 하면 = 형식적 검토 = 결함 위험
IT팀·보안팀 역할:
- 검토 대상 list 추출·제공
- 검토 결과 취합·보고
- 시정 조치 시스템 반영
검증 절차:
- 검토 회의록·서명자 확인 (현업 부서장 서명이 있는지)
- 검토 대상 list가 현업이 판단 가능한 형태로 제공됐는지 (시스템명·권한명·내역 포함)
결함 판단:
- IT팀 단독 검토 + 현업 부서장 서명 X → 결함 (형식적 검토)
- 검토 list가 너무 기술적 (예: SQL role 이름만)이라 현업이 판단 불가 → 결함
- 현업 부서장 서명 + 시정 조치까지 → OK

Q3. 회사가 검토에서 발견한 건 100% 후속조치 추적이 ITGC 표준?

A. 단정 X. 한국 비금융 실무는 발견 건이 보고서에 별도 기재되는 경우 자체가 드뭄. ITGC가 보는 건 후속조치 칸 존재 여부 + 기재된 발견 건 있으면 확인 정도.

한국 비금융 현실:
- 회사 취합 보고서에 발견 건이 명시 집계되는 경우 = 드뭄
- 보통 "검토 결과 이상 없음" 한 줄로 종결
- 발견 건이 보고서에 안 나오면 ITGC 발견 건 추적 단계 자체가 N/A
그럼 ITGC가 뭘 보나:
- 취합 보고서 양식에 발견 건 기재 칸·후속조치 칸 존재 여부 (정책 적정성)
- 기재된 발견 건이 있다면 → 후속조치 확인 (모집단 작아서 전수 가능)
- 발견 건 0건으로 1년 내내 보고되는 패턴 = 형식 검토 결함 신호 (진짜 issue)
표준 절차 (회사 측):
- 검토 결과 권한 과다 발견 → 소명 요청 → 입증 시 유지 + 사유 기록 / 입증 X면 회수
- 회수 시 사용자·관련자 통지
현실 함정:
- "지금 다 쓰는 권한"이라 회수 못 함 → 검토가 형식적 (KISA 결함사례 3번)
- 회수 시 업무 영향 큼 → 단계적 회수 (모니터링 강화 → 일부 회수 → 전면 회수)
결함 판단:
- 후속조치 칸 양식 자체 X → 결함 (정책 미흡)
- 발견 건 1년 내내 0건 + 검토 결과란 모두 "이상 없음" → 형식 검토 결함 (KISA 결함사례 3번 본질)
- 발견 건 기재됐는데 후속조치 X → 결함
빅4 KAM 통제 한정 깊이: 발견 건이 명시 집계되는 회사라면 빅4가 100% 추적까지 가는 경우 있음. 일반 비금융 ITGC 표준 X

Q4. 장기 미접속자·휴직·퇴직자·외부자 회수는 2.5.6에서 안 봐?

A. 안 본다. 2.5.1 사용자 계정 관리 영역. 2.5.6은 검토 사이클 자체에 한정.

KISA 안내서가 2.5.6 적정성 검토 항목에 "장기 미접속자·휴직 퇴직자·외부자" 다 나열했지만 = 검토 대상 항목일 뿐
ITGC 시각으로는 검증 위치가 다름:
- 휴직·퇴직자 권한 회수 = 2.5.1 (HR 변동 vs 시스템 계정 rule-based 대조)
- 장기 미접속자 처리 = 2.5.1 (회사 정책 기준 query + 잠금·삭제 이력)
- 외부자 계정·권한 회수 = 2.5.5 (외부자 list + 종료 후 회수)
2.5.6에서 보는 건: 위 항목들이 검토 사이클(취합 보고서)에 포함됐는지 = 검토 정책 적정성 검증
결함 위치: 휴직자 권한 미회수 발견 시 결함은 2.5.1에 기재. 2.5.6에는 "검토 사이클이 그걸 못 잡았는지"만 평가

Q5. 한국 비금융 ITGC 실무, 2.5.6 어디까지 봐야 함?

A. §3-A 5개. 정책 + 취합 보고서 + 모집단 walkthrough + 발견 건 후속조치 100% + 이력 보관. 그 이상 (모집단 IPE 100% 검증)은 외부감사 IPE 영역.

ITGC가 보는 깊이 (5개):
- 검토 정책 존재 (1건 walkthrough)
- 취합 보고서가 정책대로 작성됐는지 + 검토 결과란 실제 채워졌는지 (분기 사이클 2건 등)
- 검토 시 사용된 list가 시스템 추출본인지 (1건 walkthrough)
- 후속조치 칸 양식 존재 + 기재된 발견 건 있으면 후속조치 확인 (발견 건 미기재 1년 = 형식 검토 결함 신호)
- 부여·변경·삭제 이력이 감사대상기간 보존됐는지
ITGC가 안 보는 깊이:
- 검토 모집단 IPE 100% 검증 (= 검토 list가 시스템 추출과 100% 일치) → 외부감사 IPE 영역. 비금융 ITGC 일반 X (walkthrough 수준만)
- "이 사람이 이 권한 필요한가" 세부 권한 적정성 판단 → 현업만 가능
- 회사 검토가 못 잡은 권한 과다를 ITGC가 자체 발굴 → 외부감사 별도 영역
2.5.6에서 빠진 항목 (다른 인증기준에서 봄):
- 휴직·퇴직자 권한 회수 → 2.5.1
- 장기 미접속자 처리 → 2.5.1
- 외부자 계정·권한 회수 → 2.5.1·2.5.5
빈출 결함 패턴 (양획 본업 시각):
- 검토 정책은 있는데 사이클 X (KISA 결함사례 1번)
- 취합 보고서에 검토 결과 기재 X 또는 후속조치 칸 공란 (KISA 결함사례 3번)
- IT팀 단독 검토 + 현업 서명 X (형식적 검토)

Q6. 2.5.6 검토 결함 발견 시 다른 통제까지 도미노로 무너지나?

A. 자동 cascade X. 영향 평가 후 의심 영역만 추가 검증. KISA는 cascade 평가 자체를 안 한다 (ISMS-P와 ITGC의 본질 차이).

KISA 시각 (ISMS-P 인증):
- 인증 심사 결과 = 적합 / 결함 / 권고 / 인증 보류·취소
- 2.5.6 단독 결함 = 시정조치 요구 → 시정 후 인증
- 단독으로 인증 취소 사유 X (운영 통제 단일). 다만 2.5.1·2.5.5와 결합 결함이면 APD 영역 통째 결함 → 인증 보류 가능
- "다른 통제 의존성 영향" 평가 자체가 ISMS-P 안내서에 X. 인증기준별 단독 평가
ITGC 시각 (PCAOB AS 2201 결함 분류):
- Deficiency / Significant deficiency / Material weakness 3단계
- 2.5.6 단독 결함 = 통상 deficiency ~ significant
- Material weakness는 다른 영역 결함과 결합 시
다른 통제 영향:
- 부여 통제 (2.5.1·2.5.5): 검토 = 사후 검출 통제. 사후 검출 통제 없어도 부여 통제 자체가 strong이면 결함 단독 가능. 부여 walkthrough 결과 재확인 필요
- SoD 의존 ITAC: 검토 결함 단독으로 ITAC 신뢰성 무효화 X (비약). ITAC는 시스템에 박힌 자동 로직이라 권한 분리와 별개로 작동. ITAC 의존성 평가 = ITAC 자체 walkthrough + ITGC 기반 종합
- 재무제표 leverage: 검토 + 부여 + 특수권한 결함 결합 시 → APD 영역 통째 신뢰 X → 회계감사기준서 240 부정 위험 평가 상향
비금융 소규모 현실:
- ITAC 의존 자체가 드뭄. 빅4 대형 클라이언트는 ITAC 의존 = substantive testing 비용 절감이지만 비금융 중소형은 substantive testing이 더 효율적
- 외부감사가 ITAC 의존 안 하면 ITGC 결함 영향 = 부정 위험 평가 + 부여 통제 추가 검증 정도로 한정
결함 처리 흐름:
- 검토 결함 발견 → 부여 통제 (2.5.1) walkthrough 결과 재확인 → 부여 = strong이면 검토 결함 단독으로 분류
- 부여 + 검토 둘 다 약함 → 결합 결함 → APD 영역 통째 신뢰 X → substantive testing 확대

Q7. 결함 발견 시 재수행이 추출부터? 시간 큰데 다른 통제도 새로 해야 하나?

A. 재수행은 핵심 통제 일부만. ITGC test는 inspection 위주. 결함 발견 시에도 자동 cascade 재수행 X — 영향 평가 후 의심 영역만 추가 검증.

회계감사 4절차 (회계감사기준서 500) ITGC 적용 비중:
- Inspection (검사) = 70~80%. 회사 산출물 (취합 보고서·승인 log·신청서) 검사. 빠름·표준
- Inquiry (질문) = 모든 walkthrough 시작. 단독 증거력 약해서 inspection과 결합
- Observation (관찰) = 실시간 수행 관찰. 권한 신청·승인 단계 정도
- Reperformance (재수행) = 핵심 통제 일부만. 시간·비용 큼
2.5.6 검토 통제 = 보통 inspection 위주:
- Inspection: 취합 보고서 + 검토자 서명 + 후속조치 칸 확인
- Reperformance까지 가면: 감사인이 직접 권한 list 추출 → 회사 검토 list와 대조. 시간 큼
- 외부감사가 재수행까지 가는 경우 = 회사 산출물 의심 + KAM 통제 한정
결함 발견 시 다른 통제 새로? = 자동 cascade X:
- 검토 결함 발견 → 부여 통제 (2.5.1) walkthrough 결과 재확인 (재수행 X, inspection 재검토)
- 부여 = strong이면 검토 결함 단독
- 부여 walkthrough도 이상 → 두 통제 결합 결함 → 추가 substantive 또는 부여 통제 재수행
- 즉 의심 → 영향 평가 → 선택적 추가 검증 흐름. 모든 통제 자동 재수행 X
시간 비용 현실:
- ITGC 단일 통제 walkthrough = 통상 수 시간 (inspection 위주)
- Reperformance까지 가면 = 며칠 단위로 늘어남 (list 추출·대조 비용)
- 모든 통제 재수행하면 ITGC 검증 일정 자체가 비현실
- 외부감사 = inspection 위주 + 핵심 통제 일부만 재수행. 결함 발견 시도 의심 영역만 한정