마이크로서비스에서의 인증(Authentication) 심층 분석

인증 서비스란 무엇인가

인증은 사용자의 신원을 확인하여 시스템 사용을 위한 접근 권한과 필요한 권한을 부여하는 과정입니다. 이 기능을 제공하는 서비스가 바로 인증 서비스입니다. 전통적인 모놀리식 소프트웨어 애플리케이션에서는 모든 것이 동일한 애플리케이션 내에서 이루어지지만, 마이크로서비스 아키텍처에서는 시스템이 여러 서비스로 구성됩니다. 각 마이크로서비스는 이러한 아키텍처에서 각자의 작업을 수행하므로, 각 마이크로서비스에 대해 별도로 인증 및 권한 부여 프로세스를 구현하는 것은 완전히 효과적이지 않습니다.

이 글에서는 전통적인 인증과 마이크로서비스 인증을 비교하고, 아키텍처 변화에 따른 인증 방식의 변화를 설명합니다. 마지막으로, 마이크로서비스 아키텍처에서의 다양한 인증 서비스와 그 구현의 장단점을 분석합니다.

전통적 아키텍처에서의 인증 서비스

초기에는 기업이 서비스를 개발할 때 모든 기능이 동일한 애플리케이션 내에서 구현되었습니다. 이 모델을 현재 더 주류인 "마이크로서비스" 아키텍처와 구분하기 위해 "모놀리식"이라고 부릅니다.

모놀리식 애플리케이션은 단일 불가분의 단위로 구성됩니다. 일반적으로 별도의 비즈니스 라인에 의해 독립적으로 개발되고, 배포 시 동일한 환경에 통합됩니다. 이 모든 것이 긴밀하게 통합되어 하나의 단위로 모든 기능을 제공합니다. 이 단위는 필요한 모든 리소스를 가지고 있습니다. 모놀리식 애플리케이션의 장점은 배포와 반복이 쉽다는 점입니다. 비즈니스 라인이 적은 독립적인 회사에 적합합니다.

기업이 개발하는 비즈니스가 점점 복잡해짐에 따라, 단일 서비스는 더 이상 현실에서의 빠른 반복 요구를 충족시킬 수 없게 됩니다. 우리는 이 거대한 시스템을 분할하고, 기존 기능 간의 호출이 정상적으로 이루어질 수 있도록 해야 합니다. 이 문제를 해결하기 위해 **ESB(Enterprise Service Bus)**가 등장했습니다.

"엔터프라이즈 서비스 버스"는 다양한 엔터프라이즈 서비스를 연결하는 파이프라인입니다. ESB의 존재 목적은 다양한 프로토콜을 사용하는 서비스를 통합하는 것입니다. ESB는 클라이언트 요청의 번역과 라우팅과 같은 서비스를 제공하여, 서로 다른 서비스가 쉽게 상호 연결될 수 있도록 합니다. 이름에서 알 수 있듯이, 그 개념은 컴퓨터 구성 원리의 통신 모델인 버스에서 차용되었습니다. 외부 시스템과 통신이 필요한 모든 시스템은 ESB에 연결됩니다. 이를 통해 기존 시스템을 사용하여 느슨하게 결합된 이기종 분산 시스템을 구축할 수 있습니다.

ESB는 요청을 번역하고 라우팅하여 서로 다른 서비스가 통신할 수 있도록 합니다. 전통적인 ESB 서비스 호출 방식은 호출자가 매번 중앙 ESB를 통해 서비스로 라우팅되어야 한다는 것입니다.

모놀리식 아키텍처

사용자 인증과 세션 관리는 상대적으로 간단합니다: 인증과 권한 부여가 동일한 애플리케이션 내에서 이루어지며, 일반적으로 세션 기반 인증 방식을 사용합니다. 일단 인증되면 세션이 생성되어 서버에 저장됩니다. 모든 구성 요소는 이를 접근하고 사용하여 후속 요청을 알리고 권한을 부여할 수 있습니다. 세션 ID는 클라이언트로 전송되며, 모든 후속 요청을 현재 세션과 연결하는 데 사용됩니다.

ESB 아키텍처

ESB 아키텍처 하에서는 모든 서비스 간의 프로세스가 ESB 버스를 통해 처리됩니다. ESB 아키텍처는 모놀리식 아키텍처에서 파생되었기 때문에, 인증 방식은 모놀리식 아키텍처와 비교하여 크게 변경되지 않았습니다.

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

모놀리식 아키텍처에서 마이크로서비스 아키텍처로 전환하는 것은 많은 장점이 있습니다. 그러나 분산 아키텍처인 마이크로서비스 아키텍처는 더 큰 공격 표면을 가지고 있어 사용자 컨텍스트를 공유하기가 더 어렵습니다. 따라서 마이크로서비스 아키텍처 하에서는 더 큰 보안 도전에 대응하기 위해 다양한 인증 서비스가 필요합니다.

마이크로서비스 아키텍처 하에서의 인증 서비스는 다음과 같이 세 가지로 나눌 수 있습니다:

1. 각 마이크로서비스에서 인증 구현
2. 인증 서비스를 통해 인증 구현
3. API 게이트웨이를 통해 인증 구현

각 접근 방식은 각각의 특정한 장단점을 가지고 있습니다.

각 마이크로서비스에서 인증 구현

각 마이크로서비스가 모놀리식 아키텍처에서 분할되었기 때문에, 자연스럽게 각 마이크로서비스가 자체적으로 인증을 구현하는 방식으로 전환할 수 있습니다.

각 마이크로서비스는 각 진입점에서 강제되는 독립적인 보안 보장을 구현해야 합니다. 이 접근 방식은 마이크로서비스 팀이 자율적으로 보안 솔루션을 구현할 수 있도록 합니다. 그러나 이 방식에는 몇 가지 단점이 있습니다:

• 각 마이크로서비스에서 보안 로직을 반복적으로 구현해야 합니다. 이는 서비스 간의 코드 중복을 초래합니다.
• 개발 팀이 주요 서비스에 집중하는 데 방해가 됩니다.
• 각 마이크로서비스는 소유하지 않은 사용자 인증 데이터에 의존합니다.
• 유지보수와 모니터링이 어렵습니다.

이 솔루션을 개선하기 위한 한 가지 옵션은 각 마이크로서비스에 로드된 공유 인증 라이브러리를 사용하는 것입니다. 이는 코드 중복을 방지하고, 개발 팀이 비즈니스 도메인에만 집중할 수 있도록 합니다. 그러나 이 개선으로도 해결할 수 없는 단점이 여전히 있습니다. 공유 인증 라이브러리는 여전히 해당 사용자 신원 데이터를 가지고 있어야 하며, 각 마이크로서비스가 동일한 버전의 인증 라이브러리를 사용하도록 해야 합니다. 공유 인증 라이브러리는 서비스 분할이 잘못된 결과물과 유사합니다.

장점: 빠른 구현, 강한 독립성

단점: 서비스 간 코드 중복; 단일 책임 원칙 위반; 유지보수 어려움

인증 서비스를 통해 인증 구현

각 마이크로서비스가 자체적으로 인증을 구현하기 어렵고, 공유 인증 라이브러리를 사용하는 것이 마이크로서비스 분할의 원래 의도에 위배되므로, 공유 인증 라이브러리를 전용 인증 서비스로 업그레이드할 수 있을까요?

이 경우, 모든 접근은 동일한 서비스에 의해 제어되며, 모놀리식 애플리케이션의 인증 기능과 유사합니다. 각 비즈니스 서비스는 작업을 수행할 때 접근 제어 모듈에 별도의 권한 요청을 보내야 합니다.

그러나 이 접근 방식은 서비스를 느리게 하고 서비스 간의 상호 연결을 증가시킵니다. 그리고 각 마이크로서비스는 이 "단일" 인증 서비스에 의존하게 됩니다. 이는 단일 장애점과 연쇄 반응으로 인한 추가적인 손상을 초래할 수 있습니다.

장점: 각 마이크로서비스가 단일 책임을 가지며, 인증이 중앙 집중화됨

단점: 단일 장애점; 요청 지연 증가

API 게이트웨이를 통해 인증 구현

마이크로서비스 아키텍처로 전환할 때, 마이크로서비스 간의 통신이 어떻게 이루어질지에 대한 질문에 답해야 합니다. 위에서 언급한 ESB는 한 가지 접근 방식이지만, 더 일반적으로는 API 게이트웨이가 사용됩니다. API 게이트웨이는 모든 요청에 대한 단일 진입점입니다. 이는 이러한 마이크로서비스를 소비하기 위한 중앙 인터페이스 역할을 하여 유연성을 제공합니다. 다른 마이크로서비스에 접근해야 하는 마이크로서비스(이제부터는 이를 "클라이언트"라고 부르며, 접근하는 마이크로서비스와 구분하기 위함)는 서비스에 직접 접근하지 않고, 요청을 API 게이트웨이로 보내며, API 게이트웨이는 클라이언트를 업스트림 서비스로 라우팅합니다.

모든 요청은 먼저 API 게이트웨이를 통과해야 하므로, 인증 문제를 강제하기에 적합한 후보입니다. 이는 지연 시간(인증 서비스에 대한 호출)을 줄이고, 애플리케이션 전반에 걸쳐 인증 프로세스가 일관되도록 합니다.

예를 들어, APISIX의 jwt-auth 플러그인을 사용하여 게이트웨이에서 인증을 구현할 수 있습니다.

1. APISIX에 여러 사용자 신원 정보(이름, 키 등)를 구성해야 합니다.
2. 주어진 사용자의 키에 따라 APISIX에 서명 요청을 시작하여 사용자의 JWT 토큰을 얻습니다.
3. 그런 다음, 클라이언트가 업스트림 서비스에 접근해야 할 때 JWT 토큰을 가지고 있으며, APISIX는 API 게이트웨이로 이 접근을 프록시합니다.
4. 마지막으로, APISIX는 JWT 토큰을 사용하여 인증 작업을 완료합니다.

물론, 모든 것에는 장단점이 있으며, 완벽한 기술은 없습니다. API 게이트웨이를 사용하여 인증을 완료하는 것도 여전히 몇 가지 문제가 있습니다. 게이트웨이에서 이 문제를 해결하는 것은 각 마이크로서비스 내에서 인증을 완료하는 것보다 덜 안전합니다. 예를 들어, API 게이트웨이가 손상되면 그 뒤에 있는 모든 마이크로서비스가 노출됩니다. 그러나 위험은 상대적입니다. 단일 인증 서비스와 비교할 때, API 게이트웨이를 사용하는 문제는 상대적으로 경미합니다.

장점: 백엔드 마이크로서비스를 효과적으로 보호; 마이크로서비스가 인증 로직을 처리할 필요 없음

단점: 단일 장애점

요약

다른 시나리오에서는 다른 인증 방