02. 사용자 권한 및 메뉴 관리 모델링

[스프링 부트 개발 설정]을 하면서 Spring Security를 사용할 수 있도록 했다. 그렇다는 것은 로그인을 할 수 있도록 사용자 정보가 있어야 하며, 사용자에게 부여된 권한과 권한에 부여된 메뉴가 있어야 한다는 말이다. 우리는 DB를 이용하여 로그인을 하고, 사용자에 부여된 권한을 인가하고, 사용자가 사용할 수 있는 메뉴를 보일 것이다.



Spring Security에 대한 개발을 하기 전에 사용자/권한/메뉴에 대한 일반적인 모델링을 해야 한다. 모델링된 테이블은 JPA로 관리할  것이다. 아래의 ERD는 가장 일반적인 모습의 사용자/권한그룹/메뉴에 대한 모델링이다.




1. 사용자 관리

일반적인 형태의 사용자 관리 테이블이다. 이메일과 전화번호를 이용해서 메일과 SMS와 같은 것을 이용할 수 있으며, 계정의 상태와 계정 만료일, 로그인 실패 수 등의 항목이 있다. 계정 상태와 만료일, 로그인 실패 수는 Spring Security에서 사용하는 UserDetails 인터페이스와 관련이 있다. UserDetails를 implement하면 isAccountNonExpired(), isAccountNonLocked(), isCredentialsNonExpired(), isEnabled() 등을 구현해야 하는데, isAccountNonExpired()는 계전 만료일을, isAccountNonLocked()는 로그인 연속 실패 수로 조절할 수 있으며, isCredentialsNonExpired()은 패스워드의 만료일, isEnabled() 계정의 상태 등을 감시하고 이에 대한 처리를 할 수 있다.


사용자 패스워드는 일정기간마다 변경해야 하고, 같은 패스워드는 일정 회차가 지나기 전에는 사용 할 수 없는 규칙을 정하는 경우도 많다. 따라서 패스워드의 이력을 관리해야 한다. 보안 강화의 한 방법으로 특정 IP에서만 로그인 할 수 있도록 사용자 별 IP를 맵핑하기도 한다. 



2. 권한 그룹 관리


사용자에게 부여되는 권한 그룹은 하나일 필요는 없다. 특정 사용자에게는 관리자 권한과 회계 권한을 부여할 수도 있고, 어떤 사용자에게는 회계 권한과 정산 권한, 영업직원 권한 같은 것을 부여할 수도 있으며, 어떤 사용자는 단 하나의 권한만을 사용할 수도 있다. 그러나 권한 부여 받지 못한 사용자는 서비스를 제공받을 수 없어야 한다.


이런 접근 제어 방식은 일반 기업에서 가장 많이 사용하는 역할기반 접근 제어 방식(RBAC : Role Based Access Control)이다. Spring Security에서도 이러한 접근 제어 방식을 사용하도록 되어 있다. 



3. 메뉴 관리

메뉴는 메뉴로서의 기능과 카테고리로서의 기능 두가지 소화한다. 메뉴가 자식 메뉴를 가지게되면 최종 서비스를 담당하는 메뉴가 아니라, 카테고리 같은 역할을 한다는 의미이며, 자식이 없는 메뉴만이 URL를 부여 받고 서비스를 수행할 수있다. 메뉴는 하나 이상의 권한 그룹에 소속 될 수 있으며, 권한 그룹 또한 하나 이상의 메뉴를 소유할 수 있다. 


최종적으로 보면 한 사용자는 복수의 권한 그룹에 소속될 수 있고, 권한 그룹들은 같은 메뉴를 각각 보유할 수 있다. 결국 한 사용자가 하나 이상의 같은 메뉴를 소유할 수도 있다. 이런 문제는 쿼리나 프로그램으로 처리할 수 밖에 없다.



4. 물리 모델링

물리 모델링은 논리 모델링과 유사하며, 왜래키(Foreign Key)에는 각각 이름을 주었다. 문제가 생겼을 때 발견하기 쉽게 하기 위해서이다. 또한 각 왜래키에는 Index가 주어지며, 특별히 사용자 관리 테이블의 로그인 아이디(LOGIN_ID)에는 유니크 인덱스를 추가하여 로그인 아이디의 유일성도 확보할 것이다. 

그러나, 우리는 JPA를 사용하고, 지금은 개발 초기 단계이므로 ERD에서 테이블 생성하기 보다는 JPA의 Entity 오브젝트를 만드는 것으로 생성을 완료할 것이다.




아래의 예제 파일은 ER-WIN 7.3 버전에서 생성한 것이다.


example.erwin

example.nsm