권한 요청이 쌓이면서 시스템이 망가지는 과정
사내 시스템을 처음 만들 때는 권한 구조가 단순합니다. 관리자·팀장·일반 사용자 정도의 역할 세 개면 충분해 보입니다. 그런데 운영을 3~4년 하다 보면 "영업2팀인데 물류 재고만 조회하게 해 주세요", "이번 달만 정산 화면을 열어 주세요" 같은 요청이 계속 들어옵니다.
역할이 사람 수만큼 늘어나는 역할 폭증
요청마다 역할을 새로 만들면 역할 폭증(Role Explosion)이 생깁니다. 예를 들어 직원 300명 규모의 회사에서 역할이 180개를 넘고, 그중 40% 이상이 사용자 1명짜리 역할이라고 생각해 보십시오. 이 정도가 되면 역할은 사실상 개인별 권한 목록이 되고, 누가 무엇을 할 수 있는지 아무도 설명하지 못합니다.
"일단 관리자 권한"이 만드는 리스크
급한 요청을 처리하려고 관리자 권한을 주는 일도 흔합니다. 문제는 이 권한이 회수되지 않는다는 점입니다. 필요 이상의 권한은 내부자 정보 유출의 통로가 되고, 감사에서는 최소 권한 원칙 위반으로 지적받습니다.
RBAC와 ABAC, 무엇을 언제 쓰나
기능은 역할로, 데이터 범위는 속성으로
RBAC(역할 기반 접근 제어)는 "무엇을 할 수 있는가"를 정하는 데 적합합니다. 수주 등록, 단가 수정, 결재 승인 같은 기능 권한이 여기에 해당합니다. ABAC(속성 기반 접근 제어)는 "어느 데이터까지"를 정하는 데 강합니다. 사용자의 부서·지점·담당 거래처와 데이터의 속성을 비교해 접근 여부를 판단합니다.
현실적인 하이브리드 구조
실무에서는 두 방식을 섞어 씁니다. 예를 들어 '영업담당' 역할이 수주 조회 기능을 주고, `user.branch == order.branch` 정책이 자기 지점 데이터로 범위를 좁힙니다. 이렇게 하면 지점이 10개여도 역할은 1개로 유지됩니다. 역할은 수십 개 이내로 관리하고, 조직 차이는 속성으로 흡수하는 것이 핵심입니다.
현장에서 반드시 나오는 예외 케이스
겸직·파견, 위임, 임시 권한
퇴사·부서 이동은 인사 데이터와 연동
권한 회수를 담당자가 수동으로 처리하면 누락이 생깁니다. 인사 시스템의 퇴직·발령 이벤트를 받아 계정 잠금과 권한 재계산을 자동으로 실행해야 합니다. 개인정보 안전성 확보조치 기준도 퇴직 등 인사이동이 있으면 접근 권한을 지체 없이 변경하거나 말소하도록 정하고 있습니다.
구현 설계 포인트
권한 판단은 서버·API 계층에
화면에서 버튼만 숨기는 방식은 권한 통제가 아닙니다. API를 직접 호출하면 그대로 뚫립니다. 모든 요청은 서버의 공통 인가 모듈을 거쳐야 하고, 기능 권한과 데이터 범위를 한곳에서 판단해야 정책이 흩어지지 않습니다.
목록 조회와 엑셀 다운로드
데이터가 가장 많이 새는 곳은 상세 화면이 아니라 목록 조회와 엑셀 다운로드입니다. 상세 API에만 범위 조건을 넣고 검색·다운로드 쿼리에는 빠뜨리는 경우가 많습니다. 데이터 범위 조건을 쿼리 계층에서 자동으로 붙이고, 대량 다운로드는 사유 입력과 건수 기록을 함께 남기는 것이 좋습니다.
감사와 정기 점검
이력과 접근 로그 보존
권한 부여·변경·말소 이력에는 누가, 언제, 누구에게, 왜 부여했는지를 남겨야 합니다. 개인정보처리시스템의 경우 이 기록은 최소 3년, 접속기록은 최소 1년(5만 명 이상의 정보주체, 고유식별정보·민감정보를 처리하면 2년) 보관해야 합니다.
분기별 권한 재검토
분기마다 부서장에게 소속 인원의 권한 목록을 보내 "유지/회수"를 확인받는 Access Review를 운영하십시오. 90일 이상 사용하지 않은 권한을 자동으로 표시해 주면 검토 시간이 크게 줄어듭니다.
기존 시스템 권한 체계 개편 로드맵
POLYGLOTSOFT는 ERP·MES·WMS 등 사내 시스템을 구축하고 개편하면서 역할 정리, 데이터 범위 정책 설계, 인사 연동 권한 회수까지 여러 차례 수행했습니다. 권한 요청이 쌓여 관리가 어려워졌거나 감사 대응이 부담된다면, 현황 진단부터 단계적 전환까지 함께 설계해 드립니다. 구독형 개발 서비스로 부담 없이 시작해 보십시오.