배경
사내 서버를 만들기 위해 기존 시스템을 분석해보니 다음과 같은 문제가 있었다.
- 기존 사이트가 10개 이상이고, 각 사이트마다 URL이 다르다.
- 사이트들이 하나의 인프라 위에 구축되어 있지 않고, 서로 다른 인프라 위에 구축되어 있다. (AWS EC2 외에 Azure, FireBase 등 사용처가 여러가지였다.)
- 각 사이트마다 인증/인가 방식이 다르다. 예를 들어, 사이트 A는 OAuth를 지원하고 사이트 B는 Id + password 방식만 지원하는 식이다. 그리고 똑같은 역할로 보여도, 사이트마다 사용할 수 있는 기능이 달랐다. 그리고 사이트마다 회원 가입을 다시 해야했다.
해결하기
MSA 적용하기
MSA를 아무 생각없이 적용하는 것은 별로다. 배보다 배꼽이 더 클 수가 있다. 하지만 다음 이유들 때문에 MSA가 적합하다고 여겼다.
- 이미 각 사이트가 하나의 도메인이며 하나의 마이크로 서비스다. 왜냐하면 시스템 간의 연결성 (gRPC나 kafka를 쓴다던가 일절 없었음)이 없기 때문이다. 이미 시스템마다 독립적으로 운영 및 배포가 되어있었다.
- 문제인 것은 인프라 집중화와 인증 집중화다. 인프라 집중화는 내 일이 아니었고, 인증을 어떻게 집중화하느냐가 문제였다. 왜냐하면 같은 회사의 서비스임에도 불구하고, 사용자는 서비스마다 회원 가입해야 하는 문제를 겪었기 때문이다.
즉, 사실상 Auth 서버가 없는 MSA나 마찬가지였던 상황이었다.
인증 / 인가가 문제다.
천차만별로 난립되어있는 인증/인가를 어떻게 하면 확장성있게 만들 수 있냐가 문제였다. 그리고 기존 시스템과 호환될 수 있으면서 사용자들의 불편함을 해소해야 했다.
그래서 관련 개념을 공부했다.
RBAC와 ABAC란
사용자의 권한을 관리하는 인가는 여러 방식이 있었다. 그 중 대표적인 것은 RBAC와 ABAC였다.
RBAC는 사용자에게 역할을 할당하고, 그 역할에 따라 접근 권한을 제어한다. 가장 널리 쓰인다고 한다. 예를 들어 CUSTOMER, ADMIN 이런 식으로 퉁치는 것이다. 매우 직관적이고 간단하다.
ABAC는 사용자, 리소스, 환경에 대한 속성을 기준으로 세밀하고 동적인 접근 제어를 해준다. 예를 들면, comment:edit과 같은 식이다.
RBAC 만으론 부족하다.
RBAC만으론 현재 요구 사항을 만족시킬 수 없었다.
사이트 A의 CUSTOMER는 매달 경품을 응모할 수 있고, 사이트 B의 CUSTOMER는 매주마다 포인트를 적립할 수 있다고 해보자. 같은 고객이라는 Role이어도 사이트마다 권한이 다르다.
그러면 사이트 A에 가입한 고객에 대해 B에 대한 Role을 부여해야 하나? 그것도 이상하다. 왜 가입한 적도 없는 사이트에 가입을 해야 하는지 납득이 어렵다.
ABAC는 어떤가
ABAC는 위 RBAC 문제를 잘 해결해준다.
예를 들어 경품:응모:매 달, 포인트:적립:매 주라는 것으로 주면 세밀하게 제어가 가능하기 때문이다.
하지만 문제가 있다. 이러한 정보는 백엔드가 가지고 있어야 할 정보들이다. 프론트엔드는 이 정보들이 알 바가 아니다. 사용자들도 세밀하게 알고 싶어하지도 않는다.
즉, 추상화할 필요가 있다.
하이브리드로 하자!
그래서 두 가지 방식을 혼합했다. Role과 Permission이라는 개념으로 분리하였다.
Role은 기존 RBAC처럼 역할을 제공한다. 이렇게 하면, 사용자와 프론트엔드는 추상화된 정보를 가질 수 있게 된다.
그리고 Permission에는 Resource, Action 등의 개념을 조합해서 인가를 세밀하게 조정할 수 있을 뿐만 아니라, 확장성있게 추가할 수 있게 했다.
예를 들어, 사이트 A의 고객이 처음에 회원가입할 경우, 사이트 A에 대한 Permission 집합의 권한을 얻게 된다. 그리고나서 사이트 B를 가입한다고 해보자. 이 때, MSA 내 중앙집중식 Auth 서버이기 때문에 또다시 가입하게 할 필요가 없다. 단순히 사이트 B의 Permission 집합을 추가해주기만 하면 된다.
참고 자료
