들어가며

ISMS-P 심사에서 권한관리와 특권계정이 자주 지적되는 이유는 단순합니다. 통제를 했는지 자체보다, 통제한 사실을 운영 증적으로 입증할 수 있는지가 합불을 좌우하기 때문입니다. 특히 ISMS-P 2.5(인증 및 권한관리) 영역은 계정과 권한의 신청, 승인, 부여, 변경, 회수, 그리고 정기 검토까지 책임추적성으로 보여줘야 합니다.

이 글은 권한관리 준비를 문서 작업으로 끝내지 않고, 심사 대응에 실제로 제출할 수 있는 운영 증적으로 바꾸는 방법을 정리합니다. 마지막에는 Unified-IAM을 기준으로 어떤 증적이 운영 과정에서 자연스럽게 쌓이고, 어떤 영역은 다른 보안 체계와 결합하면 더 강해지는지도 함께 안내합니다.

ISMS-P에서 권한관리로 지적되는 전형적 패턴

1) 권한 부여/변경/회수 승인 근거가 남지 않는 경우

Q1. ISMS-P에서 ‘승인 근거’가 왜 그렇게 중요하죠?
A. ISMS-P 2.5.1(사용자 계정 관리)는 사용자 등록·해지와 접근권한 부여·변경·말소 절차를 수립하고 이행하라고 요구합니다. 심사에서는 결국 누가 언제 어떤 사유로 어떤 권한을 받았고, 누가 승인했는지까지 확인합니다. 승인 근거가 남지 않으면 통제 자체가 없었던 것으로 해석될 위험이 커집니다.

Q2. 실무에서 어떤 형태가 가장 많이 지적되나요?
A. 대표적으로 아래 패턴이 심사에서 약점이 됩니다, 즉 운영 증적 공백이 생기는 구간입니다.

• 구두/메신저로 요청하고 운영자가 수동 부여, 요청·승인·사유 기록이 남지 않음
• 만료일, 사용기간 없는 권한 부여로 퇴사/부서이동 후에도 권한이 남음
• 회수, 말소 처리가 늦어 정상 사용자라도 과다권한 상태가 지속

이 부분은 ISMS-P 2.5.6(접근권한 검토)에서 특히 자주 지적됩니다. 한 번 승인했다고 끝나는 구조가 아니라, 권한 부여 이후에도 적정성을 주기적으로 검토하고 조치 결과까지 남겨야 하기 때문입니다. 단발성 승인만으로는 심사 질문을 통과하기 어려워집니다.

2) 특권계정/고위 권한 관리 부족

Q3. root, administrator와 같은 특수 계정이 왜 위험하고, ISMS-P에선 어떻게 보나요?
A. ISMS-P 2.5.5(특수 계정 및 권한관리)는 특수 목적 계정과 권한을 최소화하고, 별도 식별하여 통제하라고 요구합니다. 특권계정은 사고가 나면 영향 범위가 크기 때문에, 존재 여부가 아니라 운영 방식이 핵심입니다. 누가 사용 가능한지, 어떤 기준으로 부여되는지, 어떤 절차로 승인되는지, 그리고 그 결과가 어떻게 기록으로 남는지가 심사 포인트가 됩니다.

Q4. 예외적으로 고위 권한을 부여해야 하는 경우가 있다면요?
A. 예외는 가능하지만, 통제된 예외여야 합니다. ISMS-P 2.5.5 관점에서 최소 인원 부여와 승인 강화, 그리고 사유와 기간을 포함한 기록 관리가 필요합니다. 실무적으로는 아래 항목이 갖춰지면 방어력이 크게 올라갑니다.

• 예외 처리 사유의 타당성
• 책임자 승인 및 사용기간 제한
• 특권계정 사용 이력과 권한 부여·변경·회수 이력의 연결, 책임추적성 확보
• 예외 목록, 별도 리스트 관리와 정기 재평가, 2.5.6 접근권한 검토와 연동

특권계정에서 중요한 것은 단순히 로그가 남는지 여부가 아니라, 승인과 권한 부여 이력, 그리고 사용 이력이 일관되게 맞물려 운영 증적으로 제출 가능한 형태로 정리되는지입니다.

3) 협력사·외주 인력 접근 통제 미흡 

Q5. 협력사 계정이 왜 자주 지적되나요?
A. 협력사/외주 인력은 인사변동과 투입기간 변화가 잦아 권한 회수 지연, 계정 공유, 업무범위 밖 접근이 발생하기 쉽습니다. ISMS-P 관점에서는 정상 사용자라도 과다권한이면 통제 실패로 해석될 수 있습니다. 특히 권한이 남아 있는 상태 자체가 운영 결함으로 판단되는 경우가 많아, 계정과 권한의 라이프사이클 관리가 중요해집니다.

Q6. 최소 요건(심사에서 방어되는 수준)은 뭔가요?
A. 아래 4가지를 문서와 시스템 기록으로 만들면 권한관리 리스크가 크게 줄어듭니다.

• 계약/투입기간 기반 만료일 적용과 회수 프로세스, 가능하면 자동화
• 업무 범위, 역할 기반 최소권한 원칙 적용
• 원격/외부접속 시 인증 강화 적용 (ISMS-P 2.5.3 사용자 인증 관점)
• 외주 작업은 승인된 접근 절차로만 수행되도록 통제하고, 접속기록과 관련 이력이 남도록 로그 체계와 연계 (ISMS-P 2.9.4 로그 및 접속기록 관리 관점)

심사관이 실제로 보고 싶어하는 ‘증적’ 목록

1) 권한 요청/승인/회수 이력

Q7. 심사관이 “이력”에서 확인하는 핵심은 뭐죠?

A. ISMS-P 2.5.1은 계정·권한의 부여/변경/말소 절차를 요구하고, ISMS-P 2.5.6은 접근권한의 적정성을 주기적으로 검토하고 조치하라고 요구합니다. 그래서 심사에서 강하게 보는 것은 이력 자체와 함께, 이력이 누락 없이 쌓이고 검토·조치로 이어지는 운영 구조입니다.

최소 운영 증적(권한관리 증적) 체크 항목 예시:

• 요청자/대상자/시스템/권한명/사유/사용기간
• 승인자/승인일시/승인·반려 사유
• 부여자/부여일시/부여 방식(수동/연동)
• 회수자/회수일시/회수 사유(퇴사/전보/만료 등)

2) 권한 검토(정기 재승인) 결과 리포트

Q8. ‘정기 재승인’은 왜 필요하죠?
A. ISMS-P 2.5.6(접근권한 검토)는 접근권한을 부여한 뒤에도 적정성을 주기적으로 확인하고 필요한 조치를 수행하라고 요구합니다. 즉, 한 번 승인하고 끝나는 구조는 심사 질문에서 쉽게 흔들립니다. 정기 검토가 실제로 운영되고 있다는 리포트가 있어야 심사 대응이 안정적입니다.

Q9. 리포트에는 무엇이 들어가야 설득력이 있나요?
A. 아래 항목이 포함되면 권한관리 운영 증적으로 설득력이 올라갑니다.

• 검토 기준/주체/주기, 정책과 운영 주기를 함께 제시
• 검토 대상 목록, 부서/역할/시스템별 기준으로 정리
• 변경·회수 조치 결과, 과다권한 정리와 미승인 권한 회수 등
• 예외 승인 목록, 사유/기간/보완통제 포함

3) 특권 작업 승인·세션 기록·작업 로그

Q10. 특권 작업 증적은 권한 이력만으로 부족한가요?
A. 심사에서는 권한관리 증적을 기본으로 보되, 상황에 따라 그 권한이 실제로 어떻게 사용됐는지까지 질문이 이어질 수 있습니다. 이때 ISMS-P 2.9.4(로그 및 접속기록 관리)는 사용자 접속기록, 시스템로그 등 로그의 보존과 보호를 요구하므로, 특권계정과 관련된 접속기록이 준비돼 있으면 소명이 훨씬 쉬워집니다. 다만 세션 기록이나 명령 단위 기록은 조직의 로그 체계 구성에 따라 범위와 형태가 달라질 수 있으므로, 우리 환경에서 제출 가능한 수준으로 현실적인 기준을 정하는 것이 중요합니다.

Q11. 심사에서 먹히는 특권작업 증적 구성은요?
A. 실무적으로는 아래 구성이 가장 설명이 깔끔합니다.

• 작업 전 승인, 변경요청/점검요청 티켓, 승인자, 기간
• 특권 접속 이력, 누가 어디에 언제 접속했는지 (ISMS-P 2.9.4 로그 및 접속기록 관리 관점)
• 작업 결과에 대한 추적 자료, 변경 이력이나 조치 결과 등, 환경에 따라 제출 가능한 범위로 구성

실무 체크: 최소 운영 체계 (표준 프로세스 6단계)

신청 → 승인 → 부여 → 만료/회수 → 정기검토 → 예외관리 

Q12. 최소 운영 체계를 6단계로 단순화하면?
A. 아래 6단계를 문서화하고, 시스템 기록으로 남기면 권한관리 운영 증적의 골격이 생깁니다.

• 신청: 표준 신청서, 사유/기간/역할/시스템
• 승인: 권한 등급별 승인자, 팀장/보안책임자 등
• 부여: 자동/수동 부여의 기준 + 부여 기록
• 만료/회수: 만료일 기반 회수, 퇴사/부서 이동 트리거
• 정기검토: 분기/반기 재승인 리포트
• 예외관리: 공용·긴급·특수권한 예외의 별도 통제

긴급권한 운영 원칙

Q13. 긴급권한은 ISMS-P에서 금지인가요?
A. 금지라기보다 통제된 예외여야 합니다. 긴급권한은 ISMS-P 2.5.5 관점에서 최소시간/최소범위, 사후 승인, 그리고 관련 기록이 핵심입니다.

권장 운영 원칙(요약):

• 긴급권한 전용 계정/역할 분리, 기본은 비활성
• 사용 시 자동 알림 + 사후 승인, 근거 문서 필수
• 접속기록과 조치 결과 이력 확보, 사용 후 즉시 회수

계정/권한 변경 시 연동(인사/조직)

Q14. 인사 연동이 왜 심사에서 중요한가요?
A. 권한관리의 결함은 대부분 사람이 놓치는 순간에 발생합니다. 부서 이동이나 퇴사 이후 권한이 남아 있으면 ISMS-P 2.5.1(사용자 계정 관리) 취지에 어긋납니다. 그래서 인사/조직 이벤트를 계정 잠금, 권한 회수와 연결하는 것이 운영 증적 품질을 올리는 가장 빠른 방법입니다. 회수 누락이 줄어들고, 회수 근거와 시점이 이력으로 남아 심사 대응이 쉬워집니다.

솔루션 도입 제안

Unified-IAM이 담당할 수 있는 영역(라이프사이클/특권/감사)

Q15. Unified-IAM을 ISMS-P 권한관리 관점에서 한 문장으로 말하면?
A. Unified-IAM은 권한을 통제하는 것을 넘어서, ISMS-P 2.5 영역에서 요구하는 절차 이행과 이력 관리가 운영 과정에서 자연스럽게 쌓이도록 돕는 구성으로 이해하는 것이 좋습니다. 권한관리의 뼈대는 2.5.1(사용자 계정 관리), 2.5.5(특수 계정 및 권한관리), 2.5.6(접근권한 검토)에서 만들어지고, 로그와 접속기록은 2.9.4(로그 및 접속기록 관리) 체계와 함께 제출 패키지로 완성되는 경우가 많습니다.

Unified-IAM은 이를 실무에서 다음처럼 정리합니다.

1. 권한 라이프사이클(2.5.1 / 2.5.6)
   • 무엇을 해주나 : 권한 신청 → 승인 → 부여 → 만료/회수 흐름이 표준 절차로 운영되도록 구성하고, 승인권자와 필수 입력 항목, 사유·기간·대상 시스템, 이 누락되지 않게 관리합니다.
   • 무슨 증적이 생기나 : 요청서/승인결재/부여이력/회수이력이 일관된 형식으로 남아, 심사에서 바로 제출 가능한 권한관리 운영 증적이 됩니다.
2. 특권계정/특수권한 통제(2.5.5)
   • 무엇을 해주나 : 특권계정과 특수권한을 별도 식별하고, 최소 인원 부여와 승인 강화가 적용되도록 운영 기준을 세웁니다. 특수 계정에 대해서는 결재 승인 프로세스를 통해 근거와 기간을 남기는 방식으로 통제를 강화할 수 있습니다.
   • 무슨 증적이 생기나 : 특권 계정 및 권한 목록, 승인 이력, 사용기간 제한과 회수 이력, 긴급권한 사용과 사후 승인 이력이 정리돼 특권계정 운영 증적으로 제출 가능합니다.
3. 접근권한 검토(2.5.6)
   • 무엇을 해주나 : 정기 검토가 실제 운영되도록 검토 대상과 주기, 승인 주체를 고정하고, 검토 결과가 조치로 이어지도록 관리합니다.
   • 무슨 증적이 생기나 : 검토 대상, 검토 결과, 변경·회수 조치 결과, 예외 승인 목록이 정리된 접근권한 검토 리포트가 운영 증적으로 남습니다.
4. 감사 추적성과 로그 연계(2.9.4)
   • 무엇을 해주나 : 권한 변경과 승인 이력을 감사 관점에서 추적 가능하게 남기고, 필요 시 로그 및 접속기록 관리 체계와 연결해 책임추적성을 강화합니다. 다만 접속기록의 장기 보관, 위변조 방지, 점검 리포트 등은 조직의 로그 체계 구성에 따라 역할 분담이 필요합니다.
   • 무슨 증적이 생기나 : 권한 변경 감사로그와 관련 이력 자료가 남아, 정책 문서 + 이력 + 리포트 + 로그로 제출 패키지를 구성하기 쉬워집니다.

체크리스트

권한관리 증적 체크리스트 

Q16. 지금 당장 내부 점검에 쓸 수 있는 체크리스트가 있나요?
A. 아래 항목이 권한관리 운영 증적의 최소 체크 항목입니다.

• 권한 요청/승인/부여/회수 이력이 시스템으로 남는가? (2.5.1)
• 접근권한 정기검토(재승인) 기준·주체·주기가 문서화되어 있고, 결과 리포트가 남는가? (2.5.6)
• 특수권한(관리자 등) 계정/권한이 별도 식별·목록화되어 있고, 승인 강화가 적용되는가? (2.5.5)
• 접속기록/시스템로그/권한부여 내역 로그의 보존·보호가 정의되어 있는가? (2.9.4) 

특권계정 운영 정책 샘플 목차

Q17. 정책 문서를 새로 만들 때, 목차만이라도 표준이 있으면 좋겠어요.
A. 아래 목차는 특권계정 + 운영 증적 중심으로 바로 쓸 수 있는 형태입니다.

1. 목적/적용범위(특권계정, 공용계정, 협력사 계정 정의 포함)
2. 역할과 책임(R&R: 요청자/승인자/운영자/감사자)
3. 특권권한 부여 기준(최소화, 등급, 승인권자) (2.5.5)
4. 신청·승인·부여·회수 절차(서식/필수항목/보존) (2.5.1)
5. 정기 검토(재승인) 운영(주기/리포트/조치) (2.5.6)
6. 세션 통제/작업 기록/로그 보존(티켓 연계, 위변조 방지) (2.9.4)
7. 긴급권한 부여 정책(사후 승인, 자동 회수, 로그 의무)
8. 예외관리 및 위반 시 조치(교육/감사/징계/개선)

마무리

ISMS-P 권한관리에서 중요한 건 권한을 통제한다가 아니라, 권한관리·특권계정 통제가 실제로 운영되고 있다는 운영 증적을 꾸준히 남기는 것입니다. 즉 ISMS-P 2.5(인증 및 권한관리)가 요구하는 신청–승인–부여–회수–정기검토 흐름을 흔들리지 않게 고정하고, 특권계정은 2.5.5(특수 계정 및 권한관리) 취지에 맞게 별도 식별, 승인 강화, 기록 관리로 책임추적성을 확보해야 합니다. 여기에 2.9.4(로그 및 접속기록 관리)까지 제출 패키지 관점에서 연결해 정책 문서 + 이력 + 리포트 + 로그가 한 묶음으로 준비되면, ISMS-P 심사에서 방어력이 높은 형태로 정리할 수 있습니다.

다음 2편에서는 ISMS-P 2.7(암호화 적용)을 중심으로 암호화 도입 여부가 아니라 암호화 적용 범위(저장/전송/백업/연계)와 키 관리 운영을 어떻게 정리해야 심사에서 흔들리지 않는지 다룹니다. 특히 2.7.1(암호정책 적용), 2.7.2(암호키 관리) 관점에서 무엇을 암호화해야 하고, 키는 누가 어떻게 통제하며, 어떤 운영 증적을 남겨야 하는지를 Q&A로 풀어 DATACRYPTO로 연결되는 실무 프레임을 제시하겠습니다.