마이크로서비스 보안

날아올라돼지야·2024년 8월 30일

스프링부트 뱅킹 시스템 MSA 구축

목록 보기

92/151

보안은 웹 애플리케이션, 모바일 애플리케이션, 그리고 마이크로서비스를 구축할 때 가장 중요한 요소 중 하나입니다. 아무리 좋은 애플리케이션이라도 보안이 없다면 사용자의 민감한 데이터가 노출될 수 있으며, 이는 어떤 조직에게도 큰 문제가 될 수 있습니다.

따라서, 이번 섹션에서는 다음과 같은 질문들에 대해 깊이 있게 다룰 것입니다:

1. 마이크로서비스를 어떻게 보호할 것인가?

현재 우리의 마이크로서비스는 누구나 접근할 수 있습니다. 이를 통해 누구든지 특정 사용자의 계좌 정보를 모바일 번호만으로 조회할 수 있습니다. 이런 상황이 적절할까요? 당연히 아닙니다. 우리는 모든 사용자와 서비스가 인증되지 않은 상태에서 데이터를 조회할 수 없도록 해야 합니다.

2. 인증(Authentication)과 인가(Authorization)를 어떻게 강제할 것인가?

인증은 특정 사용자나 애플리케이션이 누구인지 식별하는 과정입니다.
인가는 인증 이후에, 권한이 있는 사용자나 애플리케이션만이 특정 리소스나 서비스를 이용할 수 있도록 하는 메커니즘입니다.
이 두 가지를 마이크로서비스에 효과적으로 구현해야 합니다.

3. 중앙 집중식 신원 및 접근 관리(IAM)를 어떻게 구현할 것인가?

각 마이크로서비스에 보안 로직을 개별적으로 구현하는 것은 바람직하지 않습니다. 마이크로서비스가 수백 개에 달할 경우, 보안 요구사항이 변경될 때마다 모든 서비스에서 일일이 수정해야 하기 때문입니다. 따라서, 사용자 자격 증명 관리와 인증 및 인가를 처리할 별도의 컴포넌트를 갖추는 것이 필요합니다.

해결 방안: Oauth2, OpenID Connect, Keycloak, Spring Security

이러한 보안 문제를 해결하기 위해, 우리는 Oauth2 및 OpenID Connect와 같은 보안 표준을 활용할 것입니다. 또한 Keycloak이라는 IAM 제품과 Spring Security라는 스프링 제공 보안 프레임워크를 사용하여 마이크로서비스 보안을 구현할 것입니다.

OAuth2를 활용한 마이크로서비스 보안

이제 OAuth2가 무엇인지, 그리고 OAuth2가 해결하려는 문제점들에 대해 설명드리겠습니다.

OAuth2란 무엇인가?

OAuth2는 웹 애플리케이션, 모바일 애플리케이션 또는 마이크로서비스를 안전하게 보호하기 위한 보안 표준 또는 보안 명세입니다. 이 명세는 애플리케이션의 종류에 관계없이 모든 조직에서 사용할 수 있으며, 조직이 개발한 애플리케이션을 안전하게 보호하는 데 사용할 수 있습니다.

OAuth2가 해결하려는 문제들

OAuth2가 등장하기 전에는 대부분의 웹 애플리케이션이 기본 인증(Basic Authentication)을 사용했습니다. 기본 인증이란 무엇이며, 그 한계점은 무엇일까요?

1. 기본 인증(Basic Authentication)의 문제점

기본 인증에서는 사용자가 자신의 자격 증명을 입력하면, 이 정보가 백엔드 서버로 전송됩니다. 백엔드 서버는 이 정보를 기반으로 인증을 수행하며, 성공적으로 인증되면 세션 값이 생성되고 브라우저의 쿠키에 저장됩니다. 이 세션이 유효한 동안 사용자는 보호된 리소스와 URL에 접근할 수 있습니다.

기본 인증의 문제점:

비즈니스 로직과 인증 로직의 결합: 백엔드 서버에 비즈니스 로직과 인증 로직이 밀접하게 결합되어 있어, 인증 로직에 변경이 있을 경우 비즈니스 로직에 영향을 미칠 수 있습니다.
모바일 및 REST API에 친화적이지 않음: 기본 인증은 모바일 애플리케이션이나 REST API 환경에서 적합하지 않습니다.
제3자 접근 권한 관리의 부족: 기본 인증은 제3자 애플리케이션에 임시 접근 권한을 부여하는 데 적합하지 않습니다. 예를 들어, 구글 포토에 저장된 사진을 다른 웹사이트에서 편집하려면, 해당 웹사이트에 구글 계정을 공유해야 하는데, 이는 보안상 위험이 있습니다.

2. OAuth2가 해결하는 문제

OAuth2는 다음과 같은 문제를 해결합니다:

인증 및 인가 로직의 분리:
- OAuth2 명세에 따라 모든 인증 및 인가 로직을 별도의 인증 서버(Authorization Server)로 분리합니다. 이를 통해 조직 내의 모든 애플리케이션과 마이크로서비스가 동일한 인증 서버를 사용하게 되어, 보안 관련 로직이 중앙에서 관리되고 변경될 수 있습니다.
- 예를 들어, 구글의 다양한 제품(Gmail, YouTube, Google Maps 등)은 모두 같은 계정 정보를 사용하여 로그인할 수 있습니다. 이는 구글이 OAuth2 명세에 따라 인증 및 인가 로직을 중앙에서 관리하기 때문입니다.
제3자 애플리케이션과의 안전한 통합:
- OAuth2를 사용하면 사용자는 자신의 자격 증명을 제3자 애플리케이션과 공유하지 않고도, 임시 접근 권한을 부여할 수 있습니다.
- 예를 들어, 사용자가 StackOverflow에서 GitHub 계정을 통해 회원가입을 할 때, 사용자는 자신의 GitHub 자격 증명을 StackOverflow에 직접 제공하지 않습니다. 대신, GitHub 웹사이트에서 자격 증명을 입력하고, GitHub은 StackOverflow에 제한된 접근 권한을 부여합니다.