Admin 을 개발하다보면 권한 관리를 계층적으로 할 필요를 느낀다. 처음 개발할 때에는 딱히 요구 사항이 없다가 계속 시스템을 유지보수 하게 되면 필연적으로 계정의 권한과 그룹이 필요해진다. 그리고 Admin 사이트(일반 Manager 들을 관리 할 수 있다.)/ Manage 사이트/일반 고객(유저) 사이트 씩으로 사이트를 3벌 개발할 필요까지도 생기게 된다. 이 구조는 처음부터 설계하지 않고 나중에 적용하려고 하면 모든 API 마다 권한 체크 로직이 없게 되면서 생각하지 못한 버그가 생기게 된다. 이런 버그는 보안과 직결되기 때문에 좀 critical 한 편이다.
그래서 무엇을 만들던 계정과 계정 그룹(또는 계정 종류) 그리고 권한은 미리 설계하는게 좋다.
내 경험상 계정관리와 권한에 대해서 가장 잘 된 것은 리눅스 파일 시스템이라고 생각된다. 그래서 이와 유사하게 구현된 보안체계를 많이 보았다. 기본적으로 User 자체의 권한, Group의 권한, Other 의 권한으로 나누어져 있다. 이와 유사하게 User 는 Group 이 없거나 복수의 Group 을 가질 수 있어야 한다. 그리고 Other 는 로그인 한 사용자로 생각해야 한다.
그 다음으로는 RDBMS 에서 account 들이 잘되어 있다. RDBMS 에서는 Table 별로 권한을 가질 수도 있고, 경우에 따라서는 column 별로도 가능하다. 그리고 각 데이터(테이블이나 column)에 대한 access 를 select, insert, delete 등으로 구별할 수 있다. 이 두 보안체계를 고려해서 권한을 만들어 보면 아래와 같다.
데이터는 table 과 column 단위로 권한을 지정할 수 있고, action 은 admin 에 맞게 create, modify, list, detail, delete, search, autofill 이 필요할 것 같다. 그리고 User 는 하나 이상의 Group 을 가질 수 있다. 만일 유저가 2개 이상의 Group 을 가지고 있다면 둘 중 하나의 Group 에서 특정 action 과 해당 데이터에 대해 permission 이 허용된다면 해당 동작은 가능하다. (쉽게 설명해서 permission 의 User 가 포함된 Group 들의 Permission 의 합집합이다.)
그리고 모든 model(table)의 레코드(row) 에는 owner user 와 owner group 이 있어야 한다. User 의 경우 group 이 여러개 있더라도 데이터를 생성하면 바로 적용할 수 있는 default group 이 지정되어 있어야 한다. 이 owner user 와 owner group 을 바탕으로 User, Group, Other 를 적용해서 접근 사용자나 그룹을 적용할 수 있다.