본문 바로가기

프로그래밍/Spring Security

권한에 대한 설계 및 사상

지난글 까지 꽤 오랜 시간동안 Spring Security의 인증(로그인)에 대한 내용을 다루었다. 최대한 쉽게 설명할려고 장황하게 썼지만 아는 사람 입장에선 오히려 장황했을수도 있다. 그러나 아는 사람이라 해도 본인이 몰랐던 시절을 생각해보라..그 시절 이렇게 친절(?)하게 콕콕 집어 준 사람이 있어서 자신이 알은게 아니었다면 정말 깜깜함 그 자체였을 것이다. 그런 시절을 생각하면서 이해하고 넘어가주길 바란다.

 

이번글부터는 Spring Security의 권한에 대한 내용으로 다루도록 하겠다. 예전에 인증과 권한에 대한 설명을 언급했을때 권한은 사이트를 이용하는 사람이 화면을 이용할 자격이 있는지 확인하는 과정..이라 설명한 적이 있다. 그러나 이것은 기능을 화면에만 맞춰서 설명한 것이라 정확한 표현은 아니다. Spring Security에서 다루는 권한..이라는 것을 설명하기 위해 이제는 권한을 화면에 맞추어 설명하진 않도록 하겠다.

 

화면으로 기준을 잡았을때는 눈에 보이기 쉬운 것이 화면이라 그리 설명했지만 실제로는 기능에 초점이 맞춰져 있다. 화면에 따른 권한 이라는 것은 1차적인 뜻에서 보자면 화면을 볼 수 있는 권한이다. 화면을 본다 라는 기능에 맞춰져 있다. 그러면 기능에 따른 권한이란 어떤 개념일까? 흔히 개발할때 많이 표현하는 CRUD 작업별 권한이라 볼수 있다. 즉 만드는(등록하는) 권한, 조회 권한, 수정 권한, 삭제 권한..크게는 이런 기능 권한을 둘 수 있다. 그럼 좀더 디테일하게 보자.

 

게시판을 예를 들어보자. 게시판의 기능은 이런 기능들이 있을 것이다.

 

(1) 글의 목록을 조회하는 기능

(2) 글을 검색할 수 있는 기능

(3) 특정 글의 상세 내용을 볼 수 있는 기능

(4) 글을 등록할 수 있는 기능

(5) 글을 수정할 수 있는 기능

(6) 글을 삭제할 수 있는 기능

 

이 기능 별로 권한이 생기는 것이다. 즉..

 

(1) 글의 목록을 조회하는 권한

(2) 글을 검색할 수 있는 권한

(3) 특정 글의 상세 내용을 볼 수 있는 권한

(4) 글을 등록할 수 있는 권한

(5) 글을 수정할 수 있는 권한

(6) 글을 삭제할 수 있는 권한

 

그러면 이러한 게시판이 3가지가 있다고 가정해보자. 즉 준회원 게시판, 정회원 게시판, 회원 목록 게시판 이렇게 3가지가 있다고 가정해 보자. 3가지 게시판을 놓고 회원 등급을 유추해본다면 회원 등급으로는 준회원, 정회원, 관리자 이렇게 있을 것이라고 생각해볼 수 있겠다. 그러면 지금부터 준회원 권한에 대해 설계해보자. 준회원 권한이란 무엇인가? 준회원 게시판에 대해 위에서 언급했던 6가지의 권한을 가진 것을 준회원 권한이라고 말할 수 있을 것이다. 즉 준회원 권한은 준회원 게시판에 대한 6가지의 권한을 그룹화 한 권한이라 볼 수 있다. 정회원 권한 또한 정회원 게시판에 대한 6가지의 권한을 그룹화 한 권한이라 볼 수 있다. 관리자 권한 또한 회원 목록 게시판에 대한 6가지의 권한을 그룹화 한 권한이라 볼 수 있다. 여기에서 권한을 그룹화 한 그룹 권한이란 개념을 하나 알게 된다.

 

그런데 권한은 방금 말한 그룹 개념 뿐만 아니라 상/하위 개념도 존재한다. 기능에 따른 상하위 개념은 없다. 억지로 갖다가 붙이면 글을 등록, 수정, 삭제하는 기능에 대한 권한이 있으면 글을 조회할 수 있는 권한이 있는거 아니냐 라고 반문할수도 있다. 물론 논리적으로는 틀린 말이 아니다. 그러나 반드시 옳다고 말할수는 없다. 예를 들어서 외부 조직에서 데이터를 보내줘서 내부 조직에서 그 내용을 본다고 가정해보자. 업무적인 설계에서 외부 조직에서 데이터를 보내줬다고 외부 조직이 내부 조직에서 운영하는 조회 기능을 가질 수 있는 것은 아니다. 즉 작업의 주체가 단일화된 주체냐 아니면 나뉘어 있냐에 따라 이런 상황이 발생하는 것이다. 그래서 기능만 가지고는 상하위 개념을 엮을수는 없는 것이다. 그럼 어느 시점에서 상/하위가 존재하느냐? 권한을 그룹화 한 시점에서 상하위가 존재하게 된다. 기능별 권한을 묶어서 그룹화 된 권한을 만들때는 기능적이라기 보단 조직적인 차원에서 만들게 된다. 관리자 권한이라는 관리자 게시판 권한을 묶은 그룹 권한을 예를 들어보자. 관리자 게시판을 사용하는 기능별 권한을 관리자 권한이라 했다. 관리자..란 무엇인가? 어떤 조직의 관리책임을 맡은 하위 조직이다. 준회원과 정회원도 결국 조직으로 접근할 수 있다. 조직에 대한 하위 조직이 모두 동등하게 설정될 수도 있지만 그런 조직은 거의 드물다. 비회원 < 준회원 < 정회원 < 관리자 이렇게 조직별 서열이 정해진다. 조직별 서열이 정해지면 하위 조직에 대한 권한도 자동으로 승계가 되는 것이 일반적이다. 관리자가 준회원, 정회원 게시판에 대한 권한이 없다고 가정해보자. 준회원이나 정회원이 게시판에 온통 광고글로 도배를 해도 관리자는 준회원,정회원 게시판 삭제 권한이 없기 때문에 어쩌지도 못하는 상황이 발생하게 된다. 즉 그룹화 된 권한을 만드는 시점에서는 권한별 상하관계가 존재하게 되는 것이다.

 

내용이 장황했는데 권한에 대한 설계시 다음의 기준으로 설계를 한다(이 기준은 절대적인 기준은 아니다. 글쓴이의 기준임을 밝혀둔다)

 

● 기능에 대한 권한을 먼저 설계한다. 자잘자잘한 기능이래도 그 기능에 따른 권한을 다 설계한다

● 조직에 따른 권한을 설계한다. 그리고 조직에 따른 권한이 가질 기능적 권한을 매핑시켜준다(권한 그룹)

 

그럼 이렇게 권한에 대해 설계 했으면 이 권한을 자원과 엮어주어야 한다. 자원이란 무엇인가? 웹사이트에서 제공하는 서비스가 자원이다. 서비스는 눈에 보이는 화면이 될 수도 있고 웹서비스 같이 눈에 보이지 않는 것일수도 있다. 이미지도 웹사이트가 제공되는 서비스이기도 하다. 즉 이러한 자원과 권한을 엮어주어야 한다. 

 

Spring Security도 이런 개념에 맞춰 권한 그룹과 권한의 상/하위 개념을 주어 권한에 대한 관리, 그리고 자원별 권한을 엮어주는 그런 기능을 가지고 있다. 이제껏 했던 내용에서 항상 이런 설정 내용을 봤을 것이다.

 

<intercept-url pattern="/admin/**" access="hasRole('ROLE_ADMIN')" />
<intercept-url pattern="/login.do" access="isAnonymous()" />
<intercept-url pattern="/main.do" access="permitAll" />
<intercept-url pattern="/**" access="permitAll"/>

 

지금까지는 아무 생각없이 썼지만 위에서 했던 내용과 맞추어 보자. URL 패턴이 /admin으로 시작하는 모든 자원은 ROLE_ADMIN 권한을 가진 사람만 이용할 수 있도록 엮어준 것이다. URL이 login.do인 화면(자원)은 ANONYMOUS 권한을 가진 사람만 이용할 수 있도록 엮어준 것이다. URL이 /main.do인 화면(자원)은 권한이 있든 없든 모든 사람이 이용할 수 있도록 엮어준 것이다. 방금 언급한  3가지를 제외한 나머지 자원은 모두 이용할 수 있도록 엮어준 것이다. 이런식으로 우리는 자원에 따른 권한을 엮어주었다. 디테일하게 하거나 또는 러프하게..

 

지금까지 설명한 내용은 앞으로 설명할 Spring Security의 권한 관리에 대한 설명을 좀더 쉽게 하기 위해 권한의 그룹화와 상/하위 개념을 설명한 것이다. 그러나 반드시 이런 마인드로 설계를 하라는 것은 아니다. 자기가 수행하는 플젝에 따라 이런 상황은 충분이 바뀔수 있다. 다만 기능에 따른 권한과 이를 그룹화한 조직적 권한 개념으로 설계하면 차후 권한에 대한 세부 설정이 용이하기 때문에 이런 컨셉으로 설명한 것이다. 다음 글에서는 Spring Security에서의 권한 설정 부분에 대해 설명하도록 하겠다