▲

마이크로서비스 아키텍처에서 인증(Authentication)과 인가(Authorization)

 (microservices.io)
10P by baeba 2일전 | ★ favorite | 댓글과 토론

이 시리즈는 마이크로서비스 아키텍처에서 인증(Authentication)과 인가(Authorization)를 구현하는 방법을 다룬다.
이번 글은 전체 개요와 함께 단일 애플리케이션(모놀리식)과의 차이를 설명한다.

예시 애플리케이션: RealGuard.io

RealGuard.io는 상업용 보안 시스템 플랫폼으로, 보안 장비의 제어 및 알람을 관리한다.
사용자는 판매사, 고객사, 모니터링 제공업체 소속이며 각기 다른 접근 권한을 가진다.

모놀리식 아키텍처에서의 인증과 인가

모놀리식 구조는 하나의 애플리케이션과 데이터베이스로 구성되며, 인증은 세션 토큰으로 구현된다.
인가는 다음과 같은 구조로 수행된다:

isAllowed(user, operation, resource)

예시:

isAllowed(user, "disarm", SecuritySystem(ID))

인가 모델 4가지

  1. RBAC: 역할 기반 접근 제어 – 사용자에게 부여된 역할로 권한 결정
  2. ReBAC: 관계 기반 접근 제어 – 사용자와 자원의 관계로 접근 결정
  3. ABAC: 속성 기반 접근 제어 – 사용자, 자원, 환경의 속성으로 결정
  4. 혼합 모델: 위 3가지를 조합하여 복합적인 정책 구현 가능

인가 예시와 역할별 권한

Operation Required Role
getAlarmSystem() SecuritySystemViewer
armSystem() SecuritySystemArmer
disarmSystem() SecuritySystemDisarmer
cancelSystem() SecuritySystemAlarmCanceller

특정 역할 외에도 근무 시간 제약(ABAC)이나 알림 목록 포함 여부 등 추가 조건이 적용될 수 있다.

인가 검증 위치

  1. 네트워크 인프라: 서비스 메시, ingress controller 등에서 간단한 권한 체크 가능
  2. REST API 핸들러: 요청 수준 coarse-grained 인가 처리
  3. 도메인 로직: 복잡한 조건 기반의 인가 처리
  4. DB 접근 계층: SQL 내부에서 인가 필터링 (대용량 처리에 효과적)

UI에서의 인가

UI는 인가를 강제할 수는 없지만, 사용자 권한에 따라 버튼/기능을 표시하거나 비활성화하는 방식으로 UX를 최적화할 수 있다.

마이크로서비스 아키텍처에서의 인증

BFF(Backend For Frontend)가 로그인 및 세션 관리 담당.
각 마이크로서비스는 독립 실행되므로 사용자 정보를 세션에서 직접 접근할 수 없고, JWT 등 토큰으로 사용자 정보를 전달해야 한다.

마이크로서비스 아키텍처에서의 인가

BFF → SecurityService 순으로 요청이 전달되며, 다음 세 가지 위치에서 인가 검증이 가능하다:

  1. BFF: 세션 정보 기반으로 경로 및 메서드에 따른 요청 수준 인가 가능
  2. Inter-service Network: 서비스 메시가 JWT 기반의 인가 일부 수행
  3. 각 서비스 내부: 도메인 로직과 DB 접근 계층에서 인가 수행

분산 인가의 어려움

각 서비스가 필요한 정보를 자체 DB에 가지지 않기 때문에, 인가를 위해 타 서비스 API 호출이 필요할 수 있다.
이를 JWT로 해결하려는 방식도 있지만, 토큰 크기와 검증 비용이 문제가 된다.

정리

  • 인증은 사용자 신원 확인, 인가는 권한 판단
  • isAllowed(user, operation, resource) 패턴이 인가 핵심
  • RBAC, ReBAC, ABAC 세 가지 인가 모델을 조합하여 구현
  • 모놀리식에서는 단일 DB 접근으로 인가가 쉬우나
  • 마이크로서비스에서는 인가를 위한 데이터가 흩어져 있어 구현이 더 복잡함