왜 복잡한 인가 시스템이 필요한가?
대규모 금융 거래를 처리하는 글로벌 플랫폼에서는 '누가', '무엇을', '어떤 조건에서' 할 수 있는지를 아주 세밀하게 통제해야 합니다. 단순한 역할 기반 접근 제어(RBAC)로는 사용자 역할, 거래 금액, 지리적 위치, 조직 계층 구조, 테넌트 소속 등 다양한 속성(Context)을 동적으로 평가하는 정책을 구현하기 어렵습니다. Convera는 자체 솔루션 개발 대신 Amazon Verified Permissions를 선택해 이러한 복잡성을 해결했습니다. 이 결정의 배경에는 정책 관리, 실시간 인가 평가, 로깅 및 감사를 일관되게 구축하고 유지하는 데 드는 엔지니어링 부담을 줄이고 핵심 비즈니스에 집중하려는 전략이 있었습니다.
한국 개발 생태계에서의 맥락: 국내의 많은 기업, 특히 규제가 엄격한 금융권이나 대규모 B2B SaaS를 운영하는 곳에서도 비슷한 고민을 합니다. 모놀리식 인가 로직을 서비스 코드 내에 하드코딩하다 보면 유지보수가 어려워지고, 보안 검수와 규정 준수 대응이 복잡해지는 경우가 많습니다. Verified Permissions와 같은 전용 서비스를 도입하면 인가 정책을 선언적으로 분리하고 중앙에서 관리할 수 있어, 보안 팀과 개발 팀의 협업 구조를 개선하는 데도 도움이 됩니다.
핵심 아키텍처 패턴: 사용자 접근 제어
Convera가 구축한 아키텍처의 핵심은 API Gateway, Lambda Authorizer, Verified Permissions의 조합입니다. 사용자 인증은 Amazon Cognito가 담당하고, 인가는 Verified Permissions가 Cedar 정책을 평가하여 결정합니다.
주요 데이터 흐름:
- 사용자가 클라이언트 앱으로 로그인하면 Cognito가 인증을 처리합니다.
- Cognito의 'Pre Token Generation' Lambda 훅이 RDS 등에서 사용자 역할/속성을 조회해 JWT 토큰에 주입합니다.
- 클라이언트가 이 토큰을 담아 API를 호출하면 API Gateway가 요청을 가로챕니다.
- Lambda Authorizer가 토큰을 검증하고, 사용자 정보와 요청 컨텍스트를 Verified Permissions에 전달합니다.
- Verified Permissions는 해당 정책 저장소(Policy Store)의 Cedar 정책을 평가해
Allow또는Deny결정을 내립니다. - 이 결정은 IAM 정책 형태로 API Gateway에 반환되며, 허용된 요청만 백엔드 서비스로 전달됩니다.
성능 최적화 전략: Convera는 밀리초 미만의 지연 시간을 보장하기 위해 2단계 캐싱을 적용했습니다. 첫째, API Gateway 자체의 인가 결과 캐싱. 둘째, 애플리케이션 레벨의 Cognito 토큰 캐싱입니다. 이를 통해 초당 수천 건의 인가 요청을 처리하면서도 운영 비용을 절감할 수 있었습니다.
심화 적용: 서비스 간 통신과 멀티테넌시
서비스 간(M2M) 통신 보안
동일한 인가 아키텍처를 서비스 간 통신에도 확장 적용했습니다. 각 마이크로서비스는 Cognito의 기계 간(M2M) 사용자 풀에 클라이언트로 등록되고, 서비스 식별자, 허용 작업, 속도 제한 등이 정의된 정책을 가집니다. 서비스는 사용자 자격증명 대신 클라이언트 자격증명으로 토큰을 발급받아 API를 호출합니다. Lambda Authorizer는 토큰에서 서비스 컨텍스트를 추출해 Verified Permissions에 전달하고, '서비스 A가 리소스 R에 대한 작업 X를 수행할 수 있는가?'를 평가받습니다.
멀티테넌시 접근 제어
SaaS 형태로 서비스를 제공할 때 가장 까다로운 요구사항 중 하나가 테넌트 간 데이터 격리입니다. Convera는 테넌트별 정책 저장소(Per-tenant Policy Store) 방식을 채택했습니다.
| 방식 | 장점 | Convera 적용 이유 |
|---|---|---|
| 테넌트별 정책 저장소 | 정책 격리 용이, 테넌트별 스키마/템플릿 커스터마이징 가능, 테넌트 온보딩/오프보딩 관리 간편 | 각 테넌트의 정책을 완전히 분리해 보안 요구사항을 충족하고, 테넌트별 리소스 할당량 관리 가능 |
| 단일 저장소 내 정책 구분 | 관리 포인트 단일화, 초기 구성 간편 | 초기 복잡도는 낮지만, 대규모 테넌트에서 정책 관리와 성능 최적화가 어려워질 수 있음 |
구현 흐름은 사용자 토큰에 tenant_id 속성을 주입하고, Lambda Authorizer가 이 tenant_id로 해당 테넌트의 정책 저장소 ID를 조회한 후 Verified Permissions 평가를 요청합니다. 백엔드 서비스는 요청 헤더의 tenant_id를 검증하여 제로 트러스트 원칙을 적용하고, 데이터베이스 쿼리 시 이 컨텍스트를 필터로 사용합니다.
이 기술의 한계 또는 주의사항:
- 비용: 테넌트별 정책 저장소를 사용하면 테넌트 수에 비례해 관리 비용이 증가할 수 있습니다. 소규모 테넌트나 초기 단계에서는 단일 저장소 내에서 정책을 구분하는 방식도 고려해볼 만합니다.
- 벤더 종속: AWS 생태계에 깊이 의존하는 아키텍처입니다. 타 클라우드로의 이전이나 하이브리드 환경 구성 시 추가 작업이 필요합니다.
- 학습 곡선: Cedar 정책 언어와 Verified Permissions의 개념에 익숙해지는 시간이 필요합니다.
결론 및 다음 학습 방향
Convera 사례는 복잡한 엔터프라이즈 환경에서 인가를 애플리케이션 로직에서 분리하고, 선언적 정책과 중앙화된 평가 엔진을 통해 보안성, 유지보수성, 확장성을 동시에 확보한 훌륭한 사례입니다. Verified Permissions와 Cedar는 단순한 허용/거부를 넘어 속성 기반 접근 제어(ABAC)의 강력함을 보여줍니다.
실무 적용 조언:
- 점진적 도입: 기존 시스템을 한 번에 전환하기보다, 새로운 마이크로서비스나 중요도가 낮은 API부터 도입해 경험을 쌓는 것이 좋습니다.
- 정책 버전 관리 및 테스트: Cedar 정책도 코드입니다. Git을 통한 버전 관리와 단위 테스트(Verified Permissions는 정책 시뮬레이션 테스트 기능 제공)를 도입해야 합니다.
- 감사 로그 활용: Verified Permissions의 모든 결정은 CloudTrail에 로깅됩니다. 이를 활용해 보안 감사와 문제 분석을 체계적으로 수행할 수 있습니다.
다음 단계 학습 방향:
- 공식 문서: Amazon Verified Permissions 사용 설명서를 통해 Cedar 정책 언어 문법과 고급 패턴을 학습하세요.
- 핸즈온 워크샵: AWS가 제공하는 Verified Permissions 워크샵을 통해 직접 구축해보는 것이 개념 이해에 가장 도움이 됩니다.
- 관련 서비스 탐구: Amazon Cognito의 세부 기능(Pre/Post Token Generation 훅)과 API Gateway의 Lambda Authorizer 최적화 방법을 함께 공부하면 더욱 견고한 아키텍처를 설계할 수 있습니다.
이 글에서 분석한 아키텍처에 대한 자세한 근거자료는 AWS Architecture Blog의 Convera 사례 연구에서 확인할 수 있습니다.