[데이터넷] 국내에서 금융 마이데이터 서비스가 전면 시행됐다. 금융권에서는 개인정보와 관련해 페이징되는 모든 데이터를 가져와 고객 계정 정보 유출 위험이 높고 과도 한 개인정보를 수집할 수 있는 스크래핑 방식의 사용이 금지되고, 필요한 정보에 대해서만 요청하고 접근이 허용된 정보만을 제공받는 API 방식을 통해 서비스를 개발하고 제공해야 한다.

그렇다면 안정성과 보안을 중시하는 금융시장에서 인정받은 API(Application Programming Interface)는 얼마나 신뢰할 수 있으며, 보안 이슈 없이 안전할까?

API 사용량 비례해 위협 증가

API는 1970년대 운영체제(OS)를 제어하기 위해 프로그램 방식으로 시작해 웹 2.0 개념이 확산된 2000년 초부터는 웹 기반으로 사용됐다. 이후 오픈소스 생태계가 조성되고 정보 공유 기술에 대한 관심이 증가하면서 오픈 API라는 개념이 등장했다.

근래에는 마이크로서비스 아키텍처(MSA) 기반의 클라우드 서비스로 제공돼 모 던 앱이라는 혁신적인 개념을 창출하는 등 생각보다 오랜 기간 검증된 기술이다. 그렇기 때문에 단순히 혁신성을 인정받아 단기간에 각광받는 다른 기술들에 비하면 신뢰도나 안정성이 높다고 할 수 있다.

하지만 API 역시 증가한 사용량만큼 위협도 함께 증가하고 있다. 대표적인 예로 CVE 취약점 리스트에서 API와 관련된 항목을 검색해보면 1999년부터 2021년까지 총 2942건의 API 관련 취약점이 검색되는데, 그중 64%에 달하는 1880건이 API의 사용량이 급증하기 시작한 2017년부터 2021년까지 최근 5년 동안에 신규 등록된 취약점이다.

이와 같이 API 관련 취약점 증가 추세를 통해 알 수 있는 것은, 스크래핑에서 API 방식으로 전환하는 것만으로는 애플리케이션 간의 데이터 제공에 대한 보안 대책이 적절하다고 하기는 힘들고, API와 관련한 근본적인 취약점 이슈에 대해서 적극적 인 이해와 보안 대책이 필요하다는 것이다.

그렇다면 API 보안은 어떻게 접근해야 할까? 기존 웹 애플리케이션과 보안 접근 측면과는 달리 생각하면 안 된다.

이미 여러 글로벌 기관과 기업에서 API 보안에 대한 개념과 대응 방안을 소개하는 자료를 많이 발표했고, 이런 자료들만 보더라도 왜 API 보안이 웹 애플리케이션 보안과 다르지 않다고 했는지 쉽게 이해할 수 있다.

3~4년 주기로 웹 애플리케이션 취약점인 OWASP 톱 10을 발표하는 국제 웹 보안 표준 기구(OWASP)는 2019년에 ‘OWASP API 보안 톱 10:2019’라는 별도의 API 10대 취약점을 발표했다.

API에 대한 별도의 취약점을 발표했다는 것은 최근의 애플 리케이션 환경에서 API의 사용성과 중요성이 그만큼 커졌다는 것을 의미하는 가장 명확한 지표라 할 수 있다. 또한 서비스를 설 계 및 운용하는 입장에서도 설계 단계부터 API에 대한 보안대 책을 고려한 설계가 필요하다고 할 수 있다.

다만 OWASP API 보안 톱 10의 취약점 내용을 분석해 보 면 기존 OWASP 톱 10과 크게 다르지 않음을 알 수 있다. 특 히 2021년 발표된 OWASP 톱 10:2021은 애플리케이션의 개발 트렌드가 클라우드로 옮겨가면서 OWASP API 보안 톱 10:2019를 포괄하는 개념의 취약점들이 선정돼 순위에 이름을 올렸다.

API취약성, 애플리케이션 취약성과 유사

OWASP 톱 10:2021과 OWASP API 보안 톱 10:2019를 공격 개념과 공격에 대한 대응기술을 고려해 유사한 항목 간 매치시킨 <그림 1>은 OWASP API 보안 톱 10:2019의 A06 항목을 제외한 모든 취약점이 OWASP 톱 10:2021과 매치된다.

매치라는 표현을 사용했지만 실질적으로는 OWASP 톱 10:2021의 각 항목들이 매치된 OWASP API 보안 톱 10:2019 항목들을 포괄한다고 보는 것이 보다 정확한 표현일 것이다.

이는 기본적으로 API의 동작 환경이나 서비스 환경이 웹이 라는 카테고리 내에 존재하기 때문에 어떻게 보면 당연하다고 할 수 있다.

추가적으로 API 중 가장 활발히 사용되고 있는 REST API는 HTTP 프로토콜 기반 위에서 동작되며, 데이터 전송 형태도 흔 히 웹 애플리케이션에서 사용하고 있는 JSON이나 XML을 사용한다.

이는 결국 웹 애플리케이션에서 가지고 있는 취약점이 그대 로 API에 대한 취약점으로 나타날 수 있다는 것이다. 한마디로 웹 애플리케이션과 API에 대한 취약점은 큰 차이가 있지 않기에 보안에 대한 고려 사항에 대해서는 웹 애플리케이션의 취약 점의 연장선에서 고민하는 게 바람직하다.

WAF·API 보호 통합 WAAP 등장

OWASP뿐 아니라 IT시장조사기관인 가트너 역시 2019년에 API 보안에 중요성을 강조하며 WAAP(Web Application and API Protection)라는 개념을 제시했다. WAAP는 애플리케이션 보호, DDoS 방어, 봇 관리, API 보호와 같이 웹방화벽(WAF)의 4가지 핵심 기능을 확장한 진화된 모델이다. WAF가 집중적으 로 담당하고 있던 애플리케이션 보호, DDoS 방어, 봇 탐지 및 관리 기능에 API 보호가 추가된 셈이다.

가트너는 WAAP 개념을 소개한 2년 뒤인 2021년에 WAAP 시장을 전망하며 ‘WAAP 분야 매직 쿼드런트 2021’ 보고서를 발표했다. 이 보고서에서는 WAAP 개념과 시장분석 및 전망, 대표기업들에 대해 설명하고 있는데, 흥미로운 것은 WAAP 시 장을 이끄는 대부분의 기업이 글로벌 WAF 기업들로 소개됐다.

이는 앞서 말한 것과 같이 WAAP 개념 자체가 WAF에서 파생 됐고, OWASP에서 발표한 내용처럼 API 보안은 웹 애플리케이 션 보안의 확장된 개념으로, 이미 WAF가 담당하는 보안 영역 내에 있는 개념이기 때문에 어찌 보면 당연하다. 물론 API 보안 이 중시되면서 API 전용 보안장비도 등장했지만 이미 많은 노 하우를 축적하고 대응법을 잘 알고 있는 글로벌 WAF 기업들이 WAAP 시장을 주도하고 있는 것이다.

WAF, API 보안 기능 수행

WAF가 어떻게 API 보안을 수행하는지 최근 이슈가 되고 있는 금융 마이데이터와 애플리케이션 보안의 가장 기본인 OWASP 취약점을 통해 살펴보자.

금융 마이데이터의 시행으로 금융권에서 제공되는 개인정보 와 관련된 서비스는 모두 API를 사용하게 됐다. 따라서 금융 마이데이터 서비스를 제공하는 대부분의 기업들은 안전하고 편리한 개인신용정보 전송 및 마이데이터 서비스 제공을 위해 금융보안 원에서 발행한 ‘금융분야 마이데이터 기술 가이드 라인’에 따라 기술적 조치를 취하고 있다.

가이드라인에서 소개하는 조치 가운데 보안 담당자들이 가장 신경을 많이 쓰고 있는 조치가 ‘양 방향 TLS(mTLS)’일 것이다. mTLS는 클라이언트가 서버에 대해 신뢰할 수 있는 서버 인지만을 확 인하는 기존의 TLS 개념과 달리 클라이언트가 신뢰할 수 있는 서버인지 확인하는 것은 물론 서버 역시 신뢰할 수 있는 클라이언트인지를 확인하는 개념이다.

mTLS가 API 보안과 무슨 관련이 있는지 의문도 있겠지만 마이데이터 사업에서 API로 제공되는 정보는 대부분 개인정보를 포함한 민감한 정보로 서로 신뢰할 수 있는 사이에서만 서비스를 제공하기 위한 보안 기능이라고 할 수 있다.

이러한 개념만 본다면 간단해 보일 수 있지만 기존의 TLS 개 념만을 놓고 개발된 애플리케이션들은 자체적인 mTLS 기능 구현을 위해 전체 구조를 변경해야 하는 엄청난 작업을 필요로 할지도 모른다.

그렇다면 어떻게 mTLS 기능을 지원하도록 구현할 수 있을까? 그 해결책은 WAF에서 mTLS 기능을 지원해 준다면 간단히 해결된다.

기존 TLS와 마찬가지로 서버 앞에서 프록시 서버 역할을 하 는 WAF가 클라이언트와 서버의 인증서를 가지고 클라이언트 와 통신 시에는 서버로, 서버와 통신 시에는 클라이언트로서 인증을 실시해 mTLS 기능을 구현할 수 있기 때문이다.

WAF, WAAP로 자연스럽게 확장

OWASP API 보안 톱 10 역시 WAF의 다양한 탐지 기술들을 이용해 대응이 가능하다. WAF하면 바로 떠올릴 수 있는 버퍼 오버플로우, 인젝션 등 웹 애플리케이션에 대한 공격 대응, 민감 정보 유출 방지, 허용 리스트, 차단 리스트, 접근 로그 관리, 크리덴셜 스터핑 차단 등의 기능들과 더불어 과도한 정보가 노출돼 비정상적인 접근 시도가 발생하는 것을 방지할 수 있도록 URL 내의 GUID 등 사용자가 원하는 식별 정보를 숨겨주는 기능 등이 있다.

또한 인증된 사용자인지를 검증하기 위한 JWT의 무결성 검사 기능, API별 임계치 및 허용 메소드 설정을 통한 과도한 요청이나 허용되지 않은 메소드에 의한 시스템의 정상적인 동작을 방해하는 공격에 대해 대응, JSON에 대한 필터링 기능이 지원된다면 OWASP API 보안 톱 10:2019에서 말하는 취약점 들 은 충분히 대응이 가능하다.

물론 현재 국내의 모든 WAF가 앞서 언급한 기능들을 모두 지원한다고 할 수는 없지만, 파이오링크의 ‘웹프론트-K(WEBFRONT-K)’처럼 이미 API 보안에 대해 그 기능을 구현해 놓은 국산 WAF도 있다. 국내 WAF 시장도 글로벌 트렌 드에 발맞춰 WAAP로 자연스럽게 확장되고 있고, 금융 마이데 이터라는 정책적인 배경까지 동반돼 WAAP 시장이 자리 잡고 성장하기 좋은 시기가 도래하게 됐다.

지금까지 API 보안 대응 방안을 살펴봤다. 정리하면 API 역시 웹이라는 카테고리 내에서 웹 애플리케이션을 구성하는 기 능으로 그 보안의 개념은 웹 애플리케이션 보안의 연장선이라 고 볼 수 있고, 이미 WAF에서 고도화된 기능을 통해 API 보안 기능을 구현 중이다.

얼핏 보면 막막해 보일 수 있는 API 보안은 그동안 관심을 갖지 않고 무심히 지나친 부분일 뿐이지 이미 가장 잘 대응하고 있던 웹 애플리케이션 보안 영역의 한 부분인 것이다.

이처럼 API 보안 역시 OWASP API 보안 톱 10:2019를 기본으로 하나하나 대응해 나간다면 큰 문제없이 안전하게 API를 사용할 수 있을 것이다. 더욱이 금융 마이데이터 시행으로 API 보안에 대한 관심과 수요가 증가한 만큼 API 보안을 고민해 볼 수 있는 최적의 시기다.