접근 권한은 늘어나기만 합니다. 부서를 옮겨도 예전 권한이 남고, 프로젝트가 끝나도 시스템 계정은 살아 있고, 급하게 받은 관리자 권한은 돌려주는 사람이 없습니다. 그래서 주기적으로 "이 권한이 아직 필요한가"를 묻는 절차가 필요하고, 이것이 접근 권한 검토입니다. 인증 통제 항목이기도 하지만, 실제 사고(퇴직자 계정·과다 권한)를 줄이는 효과가 가장 분명한 운영 활동이기도 합니다.
1. 무엇을 검토하나 — 계정 × 권한 목록
시스템마다 '누가 어떤 권한을 가졌는가'를 표로 뽑습니다. 사람 계정만이 아니라 서비스 계정·공용 계정·외주 계정도 포함합니다. 처음에는 핵심 시스템(인사·재무·고객정보·운영 서버·클라우드 콘솔)부터 시작하고, 범위를 분기마다 넓히는 편이 현실적입니다.
2. 누가 검토하나 — 권한을 쓰는 쪽의 책임자
보안팀이 전체 명단을 보고 서명하는 방식은 형식에 그칩니다. 보안팀은 그 사람이 지금 무슨 일을 하는지 모르기 때문입니다. 명단을 부서장·시스템 소유자에게 쪼개 보내고, 각자 자기 사람의 권한만 판단하게 합니다. 보안팀의 역할은 절차를 돌리고, 결과를 모으고, 반영을 확인하는 것입니다.
3. 응답 — 유지 / 회수 / 변경, 그리고 미응답은 회수
응답은 세 가지뿐입니다. 유지, 회수, 축소(읽기만 남김 등). 기한(2주)이 지나도 응답이 없으면 회수가 기본값이어야 검토에 힘이 생깁니다. 처음 시행할 때는 미응답 회수를 예고만 하고 한 분기 유예를 두는 것도 방법입니다.
4. 관리자·특권 계정은 따로, 더 자주
root·관리자·DBA·클라우드 Owner 같은 특권 계정은 명단이 짧고 위험이 크므로 일반 권한과 섞지 않습니다. 월 1회, '왜 이 권한이 필요한가' 한 줄 사유와 함께 재승인받습니다. 가능하면 상시 권한 대신 필요할 때만 받는 방식(임시 승격)으로 옮깁니다.
5. 반영과 증적
회수 결정은 티켓으로 남기고 실제 반영된 것을 시스템 로그나 캡처로 확인합니다. 심사에서 보는 것은 '검토했다'는 서명이 아니라 검토 → 결정 → 반영이 이어진 기록입니다. 분기마다 한 폴더에 명단·응답·반영 증적을 모아 두면 됩니다.
자주 생기는 문제와 대응
- 명단이 너무 길어 아무도 안 본다 — 시스템별로 나누고, 지난 분기와 달라진 항목(신규·변경)을 위에 표시합니다.
- 부서장이 '다 유지'로 답한다 — 최근 90일 미사용 계정을 표시해 주면 판단이 쉬워집니다.
- 퇴직자가 명단에 남아 있다 — 분기 검토와 별개로 퇴직·이동은 인사 연동으로 즉시 처리하는 것이 원칙입니다. 검토에서 발견됐다면 그 자체가 개선 과제입니다.
권한 검토의 목표는 서명이 아니라 줄어든 권한 목록입니다. 분기마다 몇 개를 회수했는지가 이 절차의 성적표입니다.
댓글