API라는 ‘거대 공격 표면’ 이해하기

클라우드 컴퓨팅, 모바일 기기, 마이크로서비스의 세계라 할 만하다. 우리가 상호작용하는 거의 모든 애플리케이션이 여러 API에 의해 구동된다. 첨단 CSP, 모바일 애플리케이션, 마이크로서비스 환경을 다룰 때는 특히 그렇다. 이는 API가 결정적인 공격 표면이라는 의미로 이어진다.
 

아카마이(Akamai)는 대략 83%의 인터넷 트래픽이 API 기반인 것으로 추정한다. 솔트 시큐리티(Salt Security) 등의 연구에 따르면 API 공격은 2021년부터 2022년까지 600% 이상 증가했고, 가트너는 90%의 웹 지원 애플리케이션이 노출된 API로 인해 더 넓은 공격 표면을 가질 것으로 예측한다. 임페르바(Imperva)의 최신 연구는 취약한 API가 연간 400~700억 달러의 비용을 조직들에게 발생시킨다고 주장한다.

API 공격 표면 증가의 주요 배경 중 하나는 쿠버네티스와 마이크로서비스의 도입이다. 한 연구는 최근 38만개 이상의 노출된 쿠버네티스 API 서버를 발견했다. 이는 쿠버네티스 API 서버가 컨테이너 전개의 핵심적인 제어 평면 컴포넌트임을 감안할 때 우려할 만한 일이다. 그러나 API가 현대 디지털 생태계를 묶는 현실에도 불구하고 API 보안에 대한 관심은 그리 높지 않다.

API는 데이터에 접근하고 데이터에 대해 질의할 뿐 아니라 데이터 보강, 데이터 수정 등의 활동을 수행하는 데 사용된다. 이는 API를 통해 흐르는 데이터뿐 아니라 API 자체가 보호되어야 함을 의미한다. 

이러한 현실로 인해 API를 이용함에 있어 애플리케이션 및 데이터 보안 모범 준칙이 절실히 필요하다. 애석하게도 대다수의 조직은 API 목록을 만드는 단순한 작업도 힘들어한다. 어떤 API를 가지고 있고 어떤 API와 상호작용하는지, 그리고 공격 표면과 연관된 API가 무엇인지에 관한 가시성이 대부분 없다는 의미다.

리서피스 랩(Resurface Labs), 트레이서블 AI(Traceable AI) 등의 기업이 이 문제에 주목하기 시작했지만 해야 할 일이 훨씬 더 많다. 여기서는 API 공격 표면과 잠재적 취약점에 대해 설명한다. 

API 공격 표면을 평가하는 법 
API 보안은 조직에게 만만치 않은 작업일 수 있다. 산만한 API 목록을 가진 대기업이라면 특히 그렇다. 거의 다루어지지 않은 이 공격 벡터에 대처하는 데는 견실한 사례와 방법론이 도입될 수 있다. 조직적 위험을 낮출 수 있도록 거버넌스, 인프라 보안, 애플리케이션 수준 모범 관행의 조합이 필요하다. 

API의 목록을 만드는 것과 별개로, 좋은 시작점은 보편적인 API 보안 우려를 파악하고 이해하는 것이다. 다행히도 OWASP 커뮤니티가 API 보안 톱10 리스트를 만들었다. 이는 불안전한 오브젝트 및 사용자 허가/인증(broken object and user authorization/authentication), 과도한 데이터 익스포저(excessive data exposure), 트래픽 제한(rate limiting)의 결여 등의 항목을 포함한다. 

불안전한 객체 수준 허가(Broken object level authorization)는 사용자가 액세스하도록 허가된 객체에만 액세스하도록 보장하는 코드 수준 구조이다. 이는 제로 트러스트의 추구 시 일반화된 최소 수준 액세스 제어(least-privileged access control) 라는 항상 존재하는 개념으로 돌아온다.  

불안전한 사용자 인증(Broken user authentication)은 여러 형태로 구체화된다. 예를 들어 느슨한 인증 메커니즘, URL 내 민감한 인증 정보의 존재, 그리고 악의적인 행위자가 인증 정보를 입수해 인증 인터페이스를 반복적으로 악용하는 크리덴셜 스터핑(credential stuffing)이다. 이러한 취약점에 대처하려면 인증 흐름, 메커니즘을 이해하고 산업 기반 표준을 인증에 이용해야 한다. 

과도한 데이터 익스포저(excessive data exposure)는 매우 흔한 문제다. API에 있어서 이 취약점은 API가 이용자 활동에 응답해 노출되지 않아야 할 민감 정보를 반환할 때 주로 발생한다. API 응답에 포함된 데이터를 검증하고 민감한 데이터가 부주의하게 포함되지 않도록 함으로써 이 취약점에 대처할 수 있다. 또한 응답 검증 메커니즘을 구현해 민감한 데이터가 노출되지 않도록 보장할 수 있다. 

트래픽 제한 제어의 결여(lack of rate limiting controls)는 다른 주요한 취약점에서 언급되는 것처럼 기밀성과 무결성의 훼손이 아니라 시스템의 이용성에 영향을 주는 것과 관련성이 높다. API가 흔히 현대의 마이크로서비스, 클라우드, 모바일 애플리케이션을 묶는 아교로서 기능하고 있음을 고려할 때 (모두가 궁극적으로 고객에게 가치를 전달하고, 매출을 견인하는 데 사용됨) 이용성에 영향을 주는 것은 심각한 문제이다. 비즈니스의 중단은 매출 또는 고객 신뢰 상실을 의미할 수 있다. 공공 분야나 국가 안보의 경우 핵심 민간 서비스와 국가 안보가 영향을 받을 수 있다. 

이러한 문제는 숙련된 보안 전문가에게 선명하게 체감될 것이다. 인증, 허가, DoS 공격은 보편적이기 때문이다. 조직 내의, 그리고 인터넷 상의 API의 만연에 관한 이전에 제공된 지표들, 그리고 악의적 행위자의 API에 대한 급속히 증가하는 공격을 고려할 때 잠재적 위험은 심화된다.  

API는 횡적 이동을 가능하게 한다 
API는 애플리케이션과 디지털 환경으로의 정문 역할을 하곤 한다. 이로 인해 API에 대한 공격은 시스템에 걸친 횡적 이동에 흔히 사용된다. API는 초기 공격 벡터 역할을 할 수 있고 이후 기저의 시스템, 워크로드 및 데이터에 액세스하는 데 쓰일 수 있다. 따라서 이들을 보호하는 것이 지극히 중요하다. API에 대한 1차 공격 벡터는 객체 및 사용자 수준 인증 및 허가를 포함한다. 따라서 악의적 행위자는 API 자체가 아니라 API가 액세스하고 전송하는 데이터와 API 앞에 놓인 기저의 시스템을 노리는 것이다. 

API 보안에 대한 집중 강화 
많은 공격 벡터가 API 고유의 것이 아니라고 판단될 수 있다. 그러나 오늘날 API의 보편성을 감안할 때 API의 공격 벡터는 매우 우려해야할 대상이다. 다행스럽게도 API 보안 스타트업과 제품에 대한 투자 증가, API 보안을 둘러싼 지침 강화, 불안전한 API가 얼마나 문제가 되는가에 대한 업계의 인식 제고 등 몇몇 경향이 나타나고 있다. 

API가 현대 디지털 생태계를 묶는 끈이 되었다면 이 끈은 견실해야 하고 허술하지 않아야 한다. 경계 기반 보안(perimeter-based security)의 구형 모델은 주류에서 밀려났을지 모르지만 API는 여전히 현대 시스템의 핵심적인 진입 및 선회 지점 역할을 한다. 이는 단지 외부와 대면하는 시스템만이 아니라 내부적으로 통신하는 시스템 역시 포함한다. 

또한 소프트웨어 공급망을 보호하는 노력도 나타나고 있다. 이 공급망은 소프트웨어로 구동되는 시스템 사이의 주요 통신 수단인 API를 통해 결합된다. 따라서 API 보안은 보안과 견고함을 보장하는 폭넓은 소프트웨어 공급망 생태계의 핵심 컴포넌트이다. ciokr@idg.co.kr