SaaS 에서 권한 처리

 

SaaS 에서 권한 처리

SaaS  관련하여 공부하며 느낀점과 생각을 정리한 글입니다.

 

 

SaaS(Software as a Service)는 클라우드 기반의 소프트웨어 제공 모델입니다.

재고관리 솔루션, 인사관리 솔루션 등 고객에게 소프트웨어로 서비스를 제공하는 사업 운영 방식을 말합니다.

 

이는 이전에 쓴 멀티테넌시 모델과도 직접적으로 관련이 있는 주제입니다.

 

 

하나의 소프트 웨어를 함께 사용

SaaS 에서는 하나의 기반 소프트웨어를 여러 고객들이 같이 사용합니다.

각 사용자들이 사용할 데이터는 여러가지 방법으로 나누어 관리합니다.

 

특정 사용자 혹은 업체에 관리 소프트웨어를 직접 맞춤형으로 제작 해주는 모습이랑은 조금 다른 모습입니다.

SaaS 에서도 고객 맞춤형으로 서비스를 제공할 수는 있지만 관리가 어려워질 수 있다는 단점이 있습니다.

 

EAV 컨셉 등 실제 사용할 수 있는 방법을 몇가지 찾아내기는 했지만 데이터베이스 쿼리를 날릴 때 복잡해지는 점과 소프트웨어를 업데이트 할 때 이 과정이 다소 복잡할 수 있겠다 라는 생각이 들었습니다.

 

 

권한 관리

커스터마이징 뿐만 아니라 권한 관련해서도 여러가지 고민거리가 많이 생겼습니다.

보통 SaaS 에서는 테넌트 그룹 ( 서비스 사용자 ) 내에서도 여러가지 권한이 나뉠 수 있습니다.

뿐만 아니라 SaaS를 제공하는 서비스 제공자 그룹 ( 개발자, 기업 등 ) 내에서도 권한이 나뉩니다.

 

외주를 받아서 해당 업체에 딱 맞는 형태로만 제작 해준다면 이런 권한 문제는 해당 프로그램에서만 처리하면 되기 때문에 고민 거리가 많이 줄어듭니다. 

 

예를들어 A회사에서 "우리 회사 직원 관리 프로그램을 제작해주세요" 라고 요청했다면 해당 회사내의 직원들의 권한만 처리하면 되기 때문에 고민거리가 많이 줄어듭니다.

 

하지만 SaaS 에서는 A사용자의 권한, B사용자의 권한, C업체의 권한 등 벌써 생각할 거리가 많습니다.

여기서 A사용자 그룹내에 있는 다른 사용자들의 권한 처리 까지 해야합니다.

보통 A사용자 그룹내에 있는 다른 사용자들의 권한은 A사용자 그룹의 최고관리자 등이 처리합니다.

 

A사용자 그룹의 최고관리자인지, 서비스 제공자 그룹 내의 최고관리자 인지 구별도 필요하고 해당 관리자가 어떤 작업이 가능한지도 구별이 필요합니다.

 

---

 

여러가지 권한 처리 방법

1. Role-Based Access Control (RBAC)

역할기반 엑세스 제어 라고 합니다. 그룹내의 사용자가 수행할 수 있는 작업을 제어하는 방법중 하나이며,

각 사용자들에게 하나이상의 "역할"을 할당하고 서로 다른 권한을 부여하여 이를 수행하는 처리 방법입니다.

 

각 역할에는 아래 예시와 같은 내용들을 사전 정의하여 기록합니다.

• 무엇에 접근할 수 있는가
• 무엇을 조회하고 삭제할 수 있는가
• 로그인 세션의 최대 기간이 어느정도인가

 

예를들어 Super Admin, Admin, User 로 나누어 SuperAdmin은 모든 기능, Admin은 일부기능, User는 조회만 가능하도록 처리하는 형태의 방식입니다. 

 

역할은 공통으로 사용하는 형태이고 그룹내 누구 한명에게 특별히 맞춰져 있지 않습니다.

예를들어 A과장, B과장은 Admin권한을 가지고 있고 C대리는 User권한을 가지고 있습니다.

이처럼 사전 정의된 명확한 "역할"들을 여러 사람에게 할당해서 처리하는 방식 입니다.

 

이 방식을 사용하면 손쉽게 그룹 내 사용자의 권한을 바꿀 수 있습니다.

예를들어 C대리가 승진해서 과장이 되었다면 단순히 역할을 Admin으로 바꿔주기만 하면 됩니다.

 

 

2. Attribute-Based Access Control (ABAC)

속성기반 엑세스 제어 라고 합니다. 접근 제어나 작업에 대한 권한을 사용자와, 리소스, 환경에 따라 다르게 처리합니다.

1. 사용자 직급 등
2. 글을 작성한 사람이 누구인지, 문서의 보안등급 등
3. 로그인을 시도하는 물리적인 위치 등

RBAC를 조금 더 유연하게 처리하기 위한 방식이라고 생각된다.

 

위 정의대로 시뮬레이션 해보면 아래와 같이 시뮬레이션 해볼 수 있다.

 

A부장, B대리가 있고, RBAC 방식으로 Admin, User 두가지 Role이 있다고 가정하겠습니다.

이때 A부장이 문제를 일으켜 강등이 되었습니다.

 

그럼 A부장은 User라는 권한을 부여하면 간단하게 해결될 일입니다.

그런데 A부장은 이 회사의 핵심 인물입니다. Admin 레벨의 업무를 담당하고 있었는데 강등이 되어 권한을 많이 잃은 상태입니다.

 

핵심인물이 회사 업무에 여러가지 제약이 걸리면 문제가 많이 발생하기에 if(A부장) a,b,c 권한만 예외적으로 부여한다.

라는 예외를 넣어주는 방식을 취할 수 있습니다.

 

이처럼 RBAC를 베이스로 예외를 몇가지씩 추가해주는 방식입니다.

현재로썬 상당히 좋은 방법 같아보입니다. 그런데 예외가 하나 둘 늘다보면 관리가 힘들 것 같다는 생각이 듭니다.

 

 

 

3. API 수준에서 제어

이 방법은 별개로 사용하기보다는 위 방법들과 함께 사용 하는 것이 맞는 것 같다.

API 레벨에서 먼저 제어하여 불필요한 조회를 줄일 수 있을 것 같다.

 

Spring Security 에서 제공하는 권한 관리를 이용하여 API 수준에서 먼저 제어한 후 이를 충족하면 DB에 기록된 정보를 토대로,어떠한 권한을 가진 사용자 인지 식별하는 방식으로 처리할 수 있을 것 같다.

 

 

 

고민중인 내용 1

Spring Security 단에서 하드코딩 하여 권한을 미리 제어한다면 권한을 변경 할 때 매번 새로 배포를 해야 할 텐데 Spring Security 에서

DB를 조회하는게 맞는건지 고민중입니다.

 

고민중인 내용 2

역할 이란 내용은 Admin, User등으로 표현이 가능하지만 각 역할들이 어떠한 "작업"을 수행할 수 있는지를 관계형 데이터베이스에 어떻게 표현해야 할지 고민중입니다.