부서를 옮긴 직원에게 새 업무 권한을 추가하면서 이전 부서 권한은 그대로 두는 일이 있다. 평소에는 문제가 드러나지 않지만, 계정이 탈취되거나 자료가 잘못 공유되면 더 넓은 업무 영역까지 영향을 받을 수 있다. 접근권한 관리는 계정을 만드는 절차에서 끝나지 않는다. 지금 하는 일에 맞게 권한을 정하고, 업무가 바뀌면 줄이는 과정까지 포함한다.
1. 최소 권한은 업무 수행에 필요한 범위를 정하는 원칙
최소 권한 원칙은 사용자나 프로그램이 맡은 기능을 수행하는 데 필요한 최소한의 자원과 권한만 갖도록 하는 보안 원칙이다. NIST의 정의도 사람뿐 아니라 사용자를 대신해 동작하는 프로세스를 포함한다.[1] 따라서 직원 계정, 관리자 계정, 시스템 연동용 서비스 계정 모두 적용 대상이다.
여기서 ‘최소’는 권한을 무조건 적게 준다는 뜻이 아니다. 업무에 필요한 범위는 허용하되, 필요성을 설명할 수 없는 접근을 남기지 않는다는 의미다. 고객 문의를 처리하는 담당자에게 담당 고객의 주문 조회는 필요할 수 있지만, 전체 고객 목록 다운로드나 다른 직원의 권한 변경까지 함께 허용할 이유는 별도로 검토해야 한다.
2. 시스템 이름보다 대상·행위·기간을 구체화
‘고객관리 시스템 사용 가능’만으로는 권한의 크기를 알기 어렵다. 누구의 데이터를 대상으로 어떤 행위를 할 수 있는지, 언제까지 허용되는지를 함께 정해야 한다. 다음 표는 권한 신청과 검토에 사용할 수 있는 실무 판단 틀이다.
| 구분 | 확인할 질문 | 설정 예시 |
|---|---|---|
| 대상 | 어느 데이터와 조직 범위가 필요한가 | 담당 고객, 소속 지점, 지정 프로젝트 |
| 행위 | 조회·수정·삭제·반출 중 무엇이 필요한가 | 조회 허용, 대량 다운로드는 별도 승인 |
| 기간 | 언제부터 언제까지 필요한가 | 프로젝트 종료일 또는 계약 종료일 |
| 조건 | 추가로 제한할 접속 조건이 있는가 | 관리 단말 또는 승인된 접속 경로 |
| 관리 기능 | 업무 처리와 권한 관리가 분리되는가 | 일반 사용자는 계정 생성·권한 변경 불가 |
위 항목을 모든 시스템이 같은 수준으로 지원하는 것은 아니다. 조회 권한에 다운로드가 묶여 있다면 두 권한이 분리되었다고 기록해서는 안 된다. 대체 조회 화면, 제한된 데이터 제공, 반출 기록 검토 같은 보완 방법을 검토하고, 남는 위험과 예외 승인자를 명시한다.
3. 역할 기반 권한은 출발점이며 예외는 따로 관리
역할 기반 접근통제(RBAC)는 업무 역할에 권한을 묶고 사용자에게 역할을 부여하는 방식이다. CIS Control 6은 역할에 맞는 접근과 권한 부여·회수 절차를 함께 다룬다.[2] 개인마다 권한을 복제하는 방식보다 기준을 설명하기 쉽지만, 역할 자체에 과도한 권한이 들어 있으면 여러 사용자에게 같은 문제가 확산될 수 있다.
예를 들어 같은 영업 담당자라도 담당 지역이나 프로젝트가 다르면 필요한 데이터 범위도 달라진다. 공통 역할은 기본 업무로 제한하고, 추가 권한에는 사유·대상·승인자·만료일을 남기는 방식이 적합하다. 동일한 예외가 반복되면 역할 설계가 실제 업무와 맞는지 재검토한다.
4. 입사·이동·퇴사에 맞춰 권한 변경
- 신청: 업무 목적, 시스템, 데이터 범위, 허용 행위, 사용 기간을 적는다.
- 승인: 업무 책임자가 필요성을 확인하고, 시스템·데이터 책임자가 요청 범위의 적절성을 검토한다. 구체적인 승인 역할은 조직 규모에 맞춰 정한다.
- 부여·검증: 운영 담당자가 승인된 권한을 설정하고 필요한 기능은 동작하는지, 불필요한 기능은 제한되는지 확인한다.
- 변경·회수: 부서 이동, 계약 종료, 퇴사 등 변경 사건에 맞춰 기존 권한을 검토하고 불필요한 접근을 종료한다.
- 재검토: 권한 목록과 현재 업무, 승인 기록, 사용 흔적을 대조해 유지·축소·회수 결정을 남긴다.
부서 이동에서는 새 권한 추가와 옛 권한 제거를 한 건으로 관리하는 편이 누락을 줄인다. 인수인계로 기존 권한이 잠시 필요하면 종료일과 승인자를 지정한다. 퇴사 시에는 중앙 계정뿐 아니라 별도 SaaS 계정, 공유 폴더, 외부 협업 초대, 개인에게 발급된 API 키와 활성 세션의 처리 여부도 확인한다. 서비스 계정이 퇴사자 소유로 등록되어 있다면 업무 의존성을 확인하고 소유자를 이관해야 한다.
5. 가상 예시: 프로젝트 종료 후 남은 다운로드 권한
다음은 설명을 위한 가상 예시다. 마케팅 담당자가 행사 운영을 위해 특정 참여자 목록을 다운로드할 권한을 받았는데, 행사가 끝난 뒤에도 권한이 유지되었다고 가정하자. 계정이 정상이고 재직 중이라는 사실만 확인하면 이 권한은 계속 남을 수 있다.
이때 검토 기준은 재직 여부와 함께 해당 행사의 후속 업무가 남아 있는지 확인하는 것이다. 후속 업무가 종료되었다면 다운로드 권한을 회수하고 결과를 기록한다. 정산 때문에 일부 정보가 필요하다면 전체 목록 접근을 유지하는 대신 필요한 필드나 집계 자료를 제공할 수 있는지 검토한다. 이미 내려받은 파일의 보관·삭제 문제는 접근권한 회수와 별도로 처리해야 한다.
6. 관리자와 서비스 계정은 별도 기준으로 점검
일반 업무 계정과 관리자 계정을 분리하면 관리자 기능이 필요한 작업과 일상 업무를 구분하기 쉽다. 지원되는 환경에서는 관리자 접근에 MFA를 적용하고, 임시 상승 권한은 사용 목적과 종료 조건을 관리한다. MFA는 로그인 보호 수단이므로, 인증 후 갖는 권한의 범위를 줄이는 작업도 함께 수행해야 한다.
서비스 계정은 담당자, 사용 시스템, 필요한 권한, 자격 증명 관리 방법을 목록으로 남긴다. AWS의 IAM 지침은 임시 자격 증명, 최소 권한, 미사용 사용자·역할·권한·자격 증명의 정기 검토를 권고한다.[3] 구체적인 기능은 환경에 따라 다르므로, 사용 중인 시스템에서 지원하는 방식을 확인해 적용한다.
7. 실무자 관점: 승인 기록과 실제 권한이 일치하는지 확인
권한 신청서가 모두 승인되었어도 시스템에 적용된 결과가 다르면 통제는 제대로 작동하지 않는다. 직접 부여 권한뿐 아니라 그룹 소속, 중첩 그룹, 공유 링크 등으로 얻는 실제 접근 범위도 확인해야 한다. 가능하면 대표 계정으로 필요한 행위의 성공과 불필요한 행위의 거부를 함께 검증한다.
- 권한 목록에 사용자·역할·대상·행위·승인 근거·만료일·책임자를 연결할 수 있는가.
- 부서 이동·퇴사·계약 종료 정보가 권한 운영 담당자에게 전달되고 처리 결과가 남는가.
- 관리자 권한, 대량 다운로드, 외부 공유처럼 영향이 큰 권한부터 재검토하고 있는가.
- 사용하지 않은 권한을 회수하기 전에 연간 결산·비상 복구 등 드문 업무와의 관련성을 확인하는가.
- 회수 완료 기록과 실제 접근 제한 결과가 일치하는가.
검토 주기는 데이터 민감도, 권한의 영향, 조직 변경 빈도에 맞춰 정한다. 정기 검토와 별개로 부서 이동이나 계약 종료가 발생하면 그 시점에 처리한다. ‘최근 사용하지 않았다’는 사실은 검토의 단서이며, 업무 필요성 확인 없이 서비스 권한을 일괄 삭제하는 근거로 삼기에는 부족하다.
결론
최소 권한을 시작하려면 영향이 큰 업무 시스템 하나를 골라 현재 권한과 실제 업무를 대조해 보는 것이 좋다.
조회·수정·다운로드·관리자 기능을 구분하고, 불필요한 권한의 회수와 예외 만료부터 정리할 수 있다. 권한을 줄인 뒤에도 필요한 업무가 정상적으로 수행되는지 확인하고, 그 결과를 다음 역할 설계에 반영한다.