MSA 환경에서 ABAC 기반의 권한시스템을 어떻게 구현하는게 좋을까요?

Question

안녕하세요 현재 진행중인 프로젝트에 MSA를 적용하여 구현하고 있는 백엔드 꿈나무입니다. 빈번하게 일어나는 권한 검증을 효율적이고 높은 가용성을 확보할 수 있도록 하기 위해서 여러 방법을 모색하던 중, 다른 분들의 의견이 어떨지 하여 QnA를 올려보게 되었습니다.

우선 저희 프로젝트는 User, Device, Organization, Team, License 이렇게 5가지 개념이 있습니다.
사용자가 장비에 접근할 때에는 본인이 소속된 Org에 해당 장비가 존재하는지, 접근하는 동작에 대해서 해당 org가 License를 보유하고 있는지, 소속된 팀 또는 본인에게 해당 장비에 해당 동작을 승인받았는지 등 수많은 조건들에 의해 ABAC가 계산되게 됩니다. 하지만 MSA 환경으로 인해 테이블을 쉽게 join하지 못할 뿐더러, 가능하더라도 상당한 고부하 작업이 될 것이라고 생각합니다.

그래서 CQRS 패턴을 이용해서 license가 만료되거나 팀의 권한이 수정되는 등, 사용자와 장비간의 권한이 수정이 되는 command가 수신되면, 그것을 권한 담당 서비스에 비동기로 전달하여 특정 사용자가 특정 장비에 어떤 동작에 대한 제어가 가능한지를 저장(캐싱)하고 있다가 권한을 검사해야되면 간단하게 query하는 형태로 구현하는 것이 적합할 것이라고 판단했습니다. 이 패턴을 구현하기 위한 두가지 방법을 고안해보았습니다.

[Permission Service]
별도의 permission 서비스를 만들고 캐시용도로 redis를 연결해두고, 권한 검사 요청이 들어왔을 때 Cache Miss가 된다면 Api Gateway 패턴과 유사하게 여러 서비스에 각각 정보를 요청하여 최종적인 권한 정보를 Aggregate 하여 전달하고, 캐시에 보관하는 방식입니다

[권한 관리 Infra Service]
Google의 Zanzibar와 같이 권한을 관리하고 복잡한 쿼리를 처리해주는 서비스를 이용하는 방식입니다. 오픈소스로 구현된 SpiceDB를 고려하고 있습니다.

Permission Service를 만드는 경우, 본인이 보유한 정보가 부족할 경우 능동적으로 정보를 Pull하여 권한 정보를 가져오는 반면, 양측에 별도 인터페이스를 구현해야되는 단점이 있고,
이미 있는 서비스를 사용하면 구현이 쉬워지는 반면, 해당 서비스에서 능동적인 Pull이 불가능하고, 권한 Query 정보가 최신인지 판단하고 업데이트하는 것을 각 서비스에서 각각 담당해야되기 때문에 별도 서비스를 분리하는 것에 비해 Responsibility Segregation이 부족하다고도 느꼈습니다. 무엇보다 관리해야될 인프라 요소가 늘어난 것은 덤이구요.

규모에 비해서 과한 고민을 하고 있는것이 아닌가 하는 생각도 들고, 그래도 더 나은 방법으로 서비스를 만들어가고 싶기도 합니다. ABAC를 적용하는 대부분의 서비스에서 이러한 고민을 적절히 잘 해결하여 서비스가 되고 있을텐데, 정답은 없겠지만 선배님들의 조언을 듣고 싶습니다!