Q> MSA와 같은 분산환경에서 고려할 수 있는 인증기술에 대한 문의
회사에서 정보보안 업무를 담당하고 있습니다. 회사에서 추진하는 정보시스템 개발사업에서 정보보안 업무를 담당하게 되었습니다.
MSA와 같은 분산환경에서 고려할 수 있는 인증기술에는 어떤 것들이 있으며 어떻게 활용되는지 알고 싶어서 도움을 요청합니다.
A>
MSA와 같은 분산환경에서 사용되는 인증기술 종류
- Microservice Architecture와 같은 분산환경의 서비스 개발시 사용자 인증 및 권한구현과 관련된 대표적인 기술로는 OAuth 2.0, JWT, OpenID Connect, SAML, API Key, CI/DI, 생채인증을 고려할 수 있다.
- 인증 및 권한부여 기술은 크게 중앙집중 방식의 인증과 분산형 방식으로 나눌수 있으며, 어떤 인증기술을 선택할 것인지는 인증기술의 특징과 서비스 운영환경, 장애대응력, 관리 편의성, 확장성, 보안성 등을 고려해서 선택해야 한다.
- 또한, 하나의 서비스를 처리하는 전체 흐름의(Front부터 Backend) 관점에서 보면, 각 기술의 특징을 고려하여 복합적으로 사용되는 것이 일반적이다.
- 각 인증기술의 특징, 인증처리 흐름, 주요 보안요구사항 등을 정리하면 아래와 같다.
1. OAuth 2.0
1) 특징
- 중앙집중 방식으로써, 사용자가 이미 보유하고 있는 타사(Google, Facebook, Kakao 등)인증정보를 이용하여 구현하는 위임 인증방식 기술이다.
- 사용자 로그인시 타사의 인증정보를 제공받아서 Access Token을 발급하고, 이 Access Token에 접근권한 정보를 포함하여 사용자에게 인증과 권한을 제공한다.
- 보안을 위해 Access Token에 유효기간을 설정하고, 만료되면 Refresh Token을 사용하여 인증의 편리성을 강화할 수 있다.
- OAuth 2.0을 구현하는 방식은, 가장 일반적인 Authorization Code Grant(타사 인증정보→ 인증코드→ Access Token 발급), 보안성이 낮아서 주로 내부 서비스용으로 사용하는 Implicit Grant(인증정보와 Access Token을 한전에 제공), 클라이언트가 인증서버에게 직접 Access Token을 발급받는 Client Credentials Grant, 보안성이 낮아 주로 내부용으로 사용하는 Resource Owner Password Cridentials Grant(사용자의 비밀번호를 사용하여 인증처리)로 나눠진다.
- 처리흐름을 요약하면, a)OAuth 2.0 Provider등록 → b)리소스 소유자의 인가요청 → c)사용자 인증 및 동의 → d)Access Token발급 → e)리소스접근으로 이뤄진다.
- 이 기술이 가장 보편적으로 사용되는 이유는 중앙집중식으로 인증을 통합관리할 수 있으며, 한번의 인증으로 여러 서비스에 적용할 수 있고, 사용자 인증정보가 아니라 Access Token을 사용하기 때문에 인증정보 노출의 위험성이 낮아 보안성을 높일수 있기 때문이다.
2) 보안요구사항
- 별도 게시물 참조요망(https://wiki.wikisecurity.net/faq:oauth_security)
2. OpenID Connect(OIDC)
1) 특징
- OAuth2.0은 실제 권한부여를 위한 표준 프레임워크이며 사용자 자체 인증처리를 제공하지 않는 표준이기 때문에, 사용자 인증처리를 위한 별도 메커니즘을 구현하거나 독립적인 인증 서비스를 구축하여 OAuth2.0과 통합해야 한다.
- OpenID Connect(OIDC)는 OAuth2.0를 기반으로 인증과 권한관리를 제공하는 표준 프레임워크로써 중앙집중 방식의 인증기술이다.
- OIDC는 OAuth2.0과 다르게 Access Token이외에 ID Token을 발급 및 제공하여 사용자 정보(사용자의 이름, 이메일주소, 프로필사진 등)을 포함시켜 인증과 권한관리 서비스에 활용할 수 있다.
- 처리흐름을 요약하면, a)OIDC 등록 → b)사용자 인증 요청 → c)사용자 인증 및 동의 → d)인가코드 또는 ID Token발급 → e)Token교환 및 Access Token요청 → f)리소스접근으로 이뤄진다.
- OAuth 2.0 기술은 타사(Google, Facebook, Kakao 등)인증정보를 가져오기 위한 기술표준이기 때문에 OIDC는 일반적인 서비스에서OAuth2.0 프레임워크를 함께 사용하여 사용자를 인증하고 사용자 프로필 정보를 관리하는데 사용된다.
2) 보안요구사항
- OIDC를 구현할때 SSL/TLS사용, 필수적인 최소권한 및 범위부여, ID토큰 및 Access Token검증 및 보호, 악의적 리디렉션 및 CSRF대응, 세션관리, 로그인시도제한 등 다양한 보안고려사항이 존재하므로 별도 게시물로 다룰 예정이다.
3. SAML(Security Assertion Markup Language)
1) 특징
- 일반적인 SSO(Single Sign-On) 구현은 쿠키를 사용하여 한번의 로그인으로 여러 서비스의 인증과 접근을 처리하지만 MSA기반 서비스 또는 다중 도메인간의 SSO가 필요한 경우에는 SAML을 이용하여 SSO를 구현하는 경우가 일반적이다.
- SAML은 SSO를 구현하기 위한 XML기반의 표준 프로토콜로써, 기본 구성원인 사용자(Subject), ID제공자(IdP), 서비스제공자(SP)가 SAML Token생성, 교환, 검증 등을 통해 보안성 높은 SSO 기능을 제공한다.
- 처리흐름을 요약하면, a)SP등록(SAML지원을 위해 idP와 연결 설정, 메타데이터 교환) → b) 사용자가 SP에 인증요청 → c) 인증요청을 idP에 리다이렉션 → d) idP에 자격증명 제공, 로그인 → e) idP가 SAML 토큰생성 → f) idP가 생성한 SAML을 SP에게 전달 → g) SP는 SAML토큰을 검증, 무결성 확인 → h) SP는 사용자 인증 및 접속허용으로 이뤄진다.
- SAML은 기존의 인증시스템을 통합하기 위해 LDAP 또는 Active Directory와 연동하여 사용자ID, 비밀번호를 관리하고 SSO서비스를 제공하기도하며, 계열사간 또는 비즈니스파트너간의 SSO를 구현하는데 사용된다.
2) 보안요구사항
- SAML을 구현할때는 메타데이터 교환, 서명 및 암호화, 사용자 세션관리, IdP와 SP간의 연결보안 등 다양한 보안고려사항이 존재하므로 별도 게시물로 다룰 예정이다.
4 JWT(JSON Web Token)
1) 특징
- JWT(JSON Web Token)는 인증정보를 담고 있는 JSON형태의 Token으로써 인증서버에서 발급하여 각 서비스와 클라이언트에 공유하는 분산형 방식이다.
- 인증서버가 발급한 JWT는 클라이언트에 저장되고 서버에 가지고 있지 않음으로써 MSA와 같은 분산환경에서 빠른 인증처리를 제공하는 특징이 있다.
- JWT에 필요한 정보를 추가하여 다양한 목적으로 사용할 수 있으며, 인증서버는 자신의 Private Key로 서명된 JWT의 무결성을 검증함으로써 인증정보를 보호할 수 있다.
- 처리흐름을 요약하면, a)사용자인증(ID, PWD등) → b)인증서버가 JWT발급 → c)클라이언트는 JWT저장 및 전송 → d)클라이언트가 접근 리소스 요청 → e)리소스서버 또는 바이크로서비스가 JWT유효성 검사 → f)리소스서버 또는 바이크로서비스가 인증 및 권한확인 → g)리소스 제공으로 이뤄진다.
2) 보안요구사항
- 별도 게시물 참조요망(https://wiki.wikisecurity.net/faq:jwt-1)
5. API Key
1) 특징
- API Key방식은 사용자 인증이 아니라 클라이언트 자체에 부여되기 때문에 사용자 인증을 위해서는 별도의 인증 기능을 구현해야 한다.
- API Key는 인크립션된 단순한 문자열 또는 토큰형식으로 표현되며 구현이 비교적 간단하지만, 다른 인증방식보다는 보안성이 낮으므로 신뢰관계가 형성 있는 서비스간의 인증에 유용하다.
- API Key는 서비스 제공자가 발급하는 고유한 식별자이며, 클라이언트는 API Key를 HTTP header나 쿼리 파라미터에 포함하여 API를 호출하고 서비스 제공자는 API Key를 확인하여 클라이언트를 인증하는 방식으로 처리된다.
- 처리흐름을 요약하면, a)API Key생성 → b)클라이언트에게 API Key 제공 → c) 클라이언트는 API Key를 요청헤더에 추가하여 서비스 요청 → d)서비스 또는 API G/W에서 API Key를 검증(유효성, 만료여부, 제한된 권한 등) → e) 인증 및 권한 확인 → f) 요청처리 및 리소스 제공 → g) 로깅 및 감사추적 확보
2) 보안요구사항
- 금융분야의 마이데이터 서비스 확산에 따라 금융권 Open API 서비스가 활성화되고 있으며, 대형그룹의 경우 계열사간의 서비스 연동을 위해 자체 Open API서비스를 개발 및 운영하는 기업이 늘어나고 있다.
- 금융감독원은 금융권 Open API 서비스의 보안성 확보를 위하여 API서비스 운영기관을 위한 보안점검 가이드, 이용기관을 위한 보안점검 가이드를 제공하고 있으므로 보안성 확보를 위해 도움이 될 것이다.
6. CI(Connecting Information)
1) 특징
- CI는 다양한 사회적 문제를 야기하는 주민등록번호의 대체수단으로 개발되어 우리나라에서만 사용되는 유일한 본인식별 정보이므로 주민번호 또는 외국인등록번호가 없는 외국인에게는 적용할 수 없는 단점이 있다.
- CI는 마이데이터 서비스개시와 더불어 대부분의 금융회사들이 주민번호를 사용하지 않고 본인을 식별할 수 있는 개인 고유번호이며, 일방향 암호화가 이뤄지므로 원본으로 복원이 불가능하다.
- CI값은 주민번호와 공유비밀번호를 함수로 해쉬 암호화로 생성하는 88byte 문자열이다(DI(Duplication Information)는 동일한 목적으로 주민번호, 사업자별 고유번호, 공유비밀번호를 함수로 해쉬함호화로 생성하는 66byte문자열임)
- 주민번호 수집이 금지 또는 제한되어 있는 온라인 서비스 제공자는 휴대폰인증, 공인인증, 신용카드인증, 네이버 인증 등을 통해 CI를 제공받을수 있으며, 주민번호 대신에 CI를 이용하여 개인을 식별하는데 사용할수 있다.
- CI는 단지 개인을 식별하는 정보에 불과하므로, 사용자 인증이 완료된 이후에 인증된 사용자 식별자를 이용하여 다른 서비스 또는 계열사 서비스간 연동 등과 같은 Backend 서비스 처리에서 일반적으로 사용된다.
2) 보안요구사항
- CI는 다른 정보와 결합하여 특정 개인을 식별할 수 있는 정보이므로 개인정보에 속하며 대부분의 금융회사는 이를 개인정보로 정의하고 해당 보호대책을 적용하고 있다.
- 따라서, CI는 개인정보보호 정책 및 관리방침을 준수한다.
(*) A금융회사의 경우, 지금까지 언급된 모든 인증기술이 복합적으로 사용되고 있다.
Session과 같은 전통적인 인증기술, 사용자 편의를 위한 OAuth2.0, OpenID Connect인증, 본인확인 결과인 CI값, 계열사간 인증정보 활용을 위한 SAML, 계열사간 서비스 연동을 위한 API Key인증, Microservice간 인증을 위한 JWT 인증기술 등이 서비스 구간의 특징과 요구사항에 따라 복합적으로 적용되고 있다.
