로그인 기능을 만들면 사용자를 구분할 수는 있습니다. 하지만 “누가 무엇을 할 수 있는가”는 별도의 설계가 필요합니다. 관리자와 일반 사용자를 나누는 것만으로는 부족합니다. 같은 관리자라도 조회만 할 사람, 수정할 사람, 승인할 사람의 범위는 다를 수 있기 때문입니다.
권한은 역할·리소스·행동으로 나눈다
권한을 정할 때는 사람 이름에서 출발하지 않는 편이 좋습니다. 먼저 서비스 안의 리소스(주문, 고객 정보, 정산 등)와 행동(조회, 생성, 수정, 삭제, 승인)을 정리합니다. 그다음 반복되는 업무 묶음을 역할로 만들고, 역할에 필요한 행동만 연결합니다.
처음부터 지켜야 할 세 가지
- 기본 권한은 거부로 둡니다. 새 기능이나 새 역할에 자동으로 넓은 권한을 주지 않습니다.
- 화면과 API를 함께 검사합니다. 버튼을 숨겨도 API가 열려 있으면 권한 우회가 가능합니다.
- 권한 변경 기록을 남깁니다. 누가 언제 어떤 권한을 부여하거나 회수했는지 추적할 수 있어야 합니다.
운영 중에는 권한의 수명을 관리한다
프로젝트가 진행될수록 임시 권한은 늘어납니다. 퇴사자 계정, 대체 업무, 긴급 지원을 위해 준 권한이 남아 있으면 사고 가능성도 커집니다. 정기적으로 역할별 사용자 목록을 검토하고, 만료 시각이 있는 임시 권한을 사용하세요.
좋은 권한 설계는 사용자를 불편하게 만드는 장치가 아닙니다. 필요한 사람이 필요한 업무를 안전하게 끝낼 수 있도록 서비스의 경계를 명확히 하는 일입니다.
#권한설계 #RBAC #접근제어 #최소권한 #웹보안 #API보안 #사용자권한 #정보보안 #FastAPI #RESTAPI
