모든 감사인을 만족시키는 사용자 접근 검토
접근 검토는 감사에서 가장 자주 불합격하는 통제 중 하나이며, 검토를 아무도 하지 않아서보다는 제대로 수행되었음을 아무도 입증하지 못해서 실패하는 경우가 대부분이다.
이 글은 작성 당시 ControlMapping이 매핑한 11개 프레임워크를 다룹니다. 그 이후 DORA, CPS 234, Cyber Essentials이(가) 2026-10-27에 추가되었으며, 해당 페이지와 커버리지 매트릭스에도 포함되어 있습니다.
사용자 접근 검토만큼 보편적이면서도 자주 불합격하는 통제는 드물다. 모든 프레임워크는 각 구성원이 여전히 자신이 가진 접근 권한을 필요로 하는지 누군가 주기적으로 확인하기를 요구한다. 대부분의 조직은 검토를 수행한다. 그러나 검토가 빠짐없이 이루어졌고, 독립적으로 수행되었으며, 결과에 따라 조치되었음을 감사인에게 보여줄 수 있는 조직은 훨씬 적다.
프레임워크의 요구사항
| 프레임워크 | 접근 통제 | 링크 |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01PR.AA-05 | 주제 정의 |
| ISO 27001 | A.5.15A.5.16A.5.18A.8.3 | 대응표 |
| CIS v8.1 | CIS 5.1CIS 6.1CIS 6.2CIS 6.7CIS 6.8CIS 3.3CIS 5.2CIS 5.3CIS 5.5CIS 5.6CIS 6.6CIS 12.5 | 대응표 |
| SOC 2 | CC6.1CC6.2CC6.3 | 편집 콘텐츠 |
| PCI DSS | 7.2.17.2.27.2.48.2.1 | 대응표 |
| CMMC | AC.L2-3.1.1AC.L2-3.1.2 | 대응표 |
| 800-53 | AC-2AC-3 | 대응표 |
| HIPAA | §164.308(a)(4)§164.312(a)§164.312(a)(2)(i)§164.312(d) | 대응표 |
| GDPR | Art.25(2)Art.32(1)(b) | 편집 콘텐츠 |
| NIS2 | 11.111.211.5 | 대응표 |
| Essential Eight | — | 보유 데이터에 매핑 없음 |
모든 연결의 상세 내용과 근거: 프레임워크별 접근 통제 →
PCI DSS는 고정된 주기를 명시한 유일한 프레임워크다. 모든 사용자 계정과 권한은 최소 6개월마다 검토되어야 하며(7.2.4), 애플리케이션 및 시스템 계정도 마찬가지다(7.2.5.1). SOC 2 감사인은 접근 권한이 적절히 승인되고, 변경되며, 제거되는지 테스트하고(CC6.2, CC6.3), 증적으로서 주기적 검토가 이루어졌는지 확인한다. ISO 27001은 접근 권한을 정해진 간격으로 검토할 것을 요구한다(A.5.18). HIPAA는 정보 접근 관리와 활동 검토를 요구한다(§164.308(a)(4)). CMMC는 접근을 승인된 사용자와 기능으로 제한하고 최소 권한 원칙을 따를 것을 기대한다(AC.L2-3.1.1, 3.1.2).
통과하는 접근 검토의 조건
- 전체 대상 목록. 시스템에서 사용자 목록을 직접 추출하라(누군가 관리하는 스프레드시트가 아니라 내보내기 결과여야 한다). 서비스 계정과 공유 계정도 포함하라.
- 적절한 검토자. 접근을 부여한 관리자가 아니라 시스템 또는 데이터 소유자, 또는 각 사용자의 관리자여야 한다.
- 충분한 맥락. 검토자에게 각 사용자의 역할과 접근 수준을 보여주어, '승인'이 근거에 기반한 결정이 되도록 하라.
- 계정별 결정. 유지, 변경 또는 제거 중 하나를 검토자의 이름과 날짜와 함께 기록하라.
- 실제로 이루어진 변경. 제거 건은 티켓으로 등록하고, 완료되었음을 증명하는 자료를 보관하라.
- 증적 보관. 내보내기 결과, 결정 사항, 티켓, 서명을 함께 보관하라.
검토 주기
모든 적용 범위 내 시스템의 기준으로 PCI DSS의 6개월 주기를 사용하고, 특권 접근은 분기별로 검토하라. SOC 2 Type II 보고서를 보유하고 있다면, 관찰 기간마다 최소 한 번(가능하면 두 번) 검토가 포함되도록 하라.
감사인이 발견하는 문제
- 형식적 승인: 판단할 근거가 없는 사람이 몇 분 만에 모든 계정을 승인하는 경우.
- 불완전한 대상 목록: 검토가 애플리케이션만 다루고 데이터베이스는 제외했거나, 사람 계정만 다루고 서비스 계정은 제외한 경우.
- 자가 검토: 관리자가 자신의 접근 권한을 스스로 승인하는 경우.
- 미완료된 제거: 검토에서 제거하도록 했지만 몇 달이 지나도 계정이 남아 있는 경우.
- 검토에서 드러난 퇴사자: 오프보딩 프로세스가 실패하고 있다는 신호이며, 감사인은 이를 별도로 테스트할 것이다.
핵심 요약
- 접근 검토가 감사에서 실패하는 이유는 노력이 아니라 증적 때문이다: 불완전한 대상 목록, 자가 검토, 완료되지 않은 제거.
- 시스템 내보내기, 적절한 검토자, 계정별 결정, 변경 증명을 사용하라.
- 6개월 주기 검토(PCI DSS 기준)와 특권 접근의 분기별 검토는 모든 프레임워크를 충족한다.
- 범위는 중요한 시스템으로 한정하고, 실무 절차는 자동화하라.
지속 가능하게 운영하기
내보내기와 알림을 자동화하고, 사용자 단위가 아닌 시스템 단위로 검토하며, 범위를 운영 환경, 고객 데이터, 특권 도구, 프레임워크 적용 범위에 속한 모든 항목 등 중요한 시스템으로 한정하라. 항상 지연되는 방대한 검토보다 규모는 작지만 증적이 잘 갖춰진 검토가 낫다.
모든 요구사항과 출처를 확인하려면 접근 통제 및 특권 접근 주제 페이지를 참고하고, SOC 2, ISO 27001, PCI DSS 간 증적 재사용에 관한 블로그 글도 확인하라.
질문
사용자 접근 권한은 얼마나 자주 검토해야 합니까?
PCI DSS는 사용자 계정과 접근 권한을 최소 6개월마다 검토할 것을 요구한다(7.2.4). 대부분의 다른 프레임워크는 정의한 주기에 따른 주기적 검토를 요구하며, 특권 접근은 분기별로, 그 밖의 접근은 6개월마다 검토하는 것이 일반적인 기준이다.
누가 접근 검토를 수행해야 합니까?
시스템 또는 데이터의 소유자, 또는 사용자의 관리자이며, 접근을 부여한 관리자는 제외된다. 감사인은 독립성과 근거를 갖춘 검토자인지를 본다.
서비스 계정도 접근 검토가 필요합니까?
예. 감사인은 서비스, 공유 및 API 계정을 검토 대상에 포함하는 경우가 점점 늘고 있으며, PCI DSS는 애플리케이션 및 시스템 계정에 대한 주기적 검토를 명시적으로 요구한다(7.2.5.1).
2026-10-27 기준 데이터: 본 게시물의 수치는 현재 대응표에서 계산되며, 대응표가 변경되면 함께 업데이트됩니다. 대응표 공개된 크로스워크(NIST, ENISA, CIS, PCI SSC)가 연결을 뒷받침합니다 · 편집 콘텐츠 대응 크로스워크가 없는 경우 ControlMapping의 판단이며, 그 사유가 표시됩니다. · CSF 2.0 성과 하나만 공유함: 검토할 가치는 있으나 매핑은 아님 · 보유 데이터에 매핑 없음 당사 데이터에 매핑된 항목이 없음. 대개 신규 작업이지만 적용 범위 안내를 확인하세요. 컴플라이언스 자문 아님.
관련 게시물
분석 · 2026-10-27APRA CPS 234와 ISO 27001: ISMS 적용 범위와 APRA 추가 요건ISO 27001 ISMS는 APRA의 CPS 234 거의 모든 항목을 다루지만, APRA는 이사회 책임, 제3자 보증, 엄격한 통보 기한을 추가로 요구합니다.
분석 · 2026-10-1311개 보안 프레임워크의 MFA 요구사항 비교어떤 프레임워크가 MFA를 요구하는지, 대상과 강도는 어떠한지 확인하세요. PCI DSS, CMMC, NIS2, Essential Eight, ISO 27001, SOC 2, HIPAA를 한눈에 비교합니다.
분석 · 2026-09-29NIST CSF 2.0 관점에서 본 HIPAA 보안 규칙NIST CSF 2.0 프로그램은 HIPAA 보안 규칙의 요구사항 거의 전부와 대응됩니다. 그대로 이어지는 부분, 대응되지 않는 두 가지, 그리고 CSF가 HIPAA를 넘어 추가로 다루는 내용을 정리했습니다.