2021.05.26

API 공격의 메커니즘과 이를 확인, 예방하는 방법

Maria Korolov | CSO
5월 초, 피트니스 기업 펠로톤(Peloton)은 인터넷에 고객 계정 데이터가 노출되었다고 발표했다. 사용자가 계정 프로필을 비공개로 설정했더라도 누구든 펠로톤 서버에 있는 사용자의 계정 데이터에 접근할 수 있었다. 원인은 무단 요청을 허용하는 결함이 있는 API(Application Programming Interface)였다.
 
ⓒ Getty Images Bank

손쉬운 사물통신(machine-to-machine)을 가능하게 하는 API 사용량이 최근 폭발적으로 증가했다. 아카마이(Akamai)에 따르면, API 통신은 현재 전체 인터넷 트래픽의 83% 이상을 차지한다.

또한 많은 보안 문제의 원인이기도 하다. 펠로톤 외에도 최근 API 관련 사이버보안 문제로 뉴스에 나왔던 기업은 에퀴팩스(Equifax), 인스타그램(Instagram), 페이스북(Facebook), 아마존(Amazon), 페이팔(Paypal) 등이 있다.


API 사용 증가와 비례하는 공격 

솔트 시큐리티(Salt Security)가 2월에 공개한 보고서에 따르면, 기업 가운데 91%가 지난해 API와 관련된 보안 문제를 겪은 것으로 나타났다. 가장 보편적인 것은 취약점이었으며, 응답자 가운데 54%를 차지했고 46%는 인증 문제, 20%는 봇 문제, 19%는 DoS(Denial of Service) 문제를 겪었다.

80%의 기업이 보안 도구로 API 공격을 효과적으로 방지할 수 없다고 생각한다. 솔트 시큐리티의 조사에 따르면, 기업 가운데 2/3가 API 보안 관련 우려 때문에 새로운 애플리케이션의 생산 속도를 늦췄다고 한다. WAF(Web Application Firewall)과 API 게이트웨이를 갖춘 솔트의 고객은 모두 매월 다수의 API 공격을 경험하고 있으며, 이는 API 공격이 이런 보안 도구를 통과했다는 것을 의미한다. 솔트에 따르면, WAF와 API 게이트웨이는 OWASP API 보안 10대 위협 가운데 90%를 놓친다.

하지만 1/4 이상의 기업이 보안 전략 없이 중요한 API 기반 애플리케이션을 운용하고 있다. SCRC(Synopsys Cybersecurity Research Center)의 수석 보안 전략가 팀 맥키는 "펠로톤은 본래 인증 없이 API를 통해 누구에게든 장소에 상관없이 사용자 데이터 접근을 제공했다"라고 말했다. 맥키는 “API 보안을 위해 펠로톤이 취한 첫번째 조치는 가입자에 접근을 제한하는 것이었지만, 모든 사용자가 여전히 개인정보 보호 설정에 상관없이 다른 사용자의 데이터에 접근할 수 있었다. 사용자의 연령과 성별, 프로필 이미지 등의 데이터와 일부 활동 데이터에 접근할 수 있었다”라고 설명했다.

API 유출은 드물지 않다. 솔트 시큐리티의 보고서에 따르면, 기업 가운데 82%는 API에 사유 네트워크 정보, 보호되는 건강 정보, 카드 소유자 데이터 등의 PII(Personally Identifiable Information)가 포함되어 있는지 여부 등의 API 세부사항을 잘 모르고 있었으며, 22%의 기업은 어떤 API가 민감한 데이터를 노출시키는지 알 수 없다고 밝혔다.

트레이서블(Traceable)의 보안 연구 엔지니어 로샨 피유시는 "펠로톤의 실수는 망가진 객체 레벨 인증에 취약한 미인증 API를 사용한 것이었다"라고 말했다. 피유시는 이런 문제에 직면한 기업으로는 파네라(Panera), 피서브(Fiserv), 라이프록(LifeLock), 케이 주얼스(Kay Jewelers) 등이 있었다고. 피유시는 “그 외에도 많다. 일반적으로 개발 프로세스 중 API에 대한 인증과 승인 보호를 간과하면서 발생하는 것이 원인이다”라고 지적했다.


한 은행의 API 성장 스토리

중형 금융업체의 사이버보안 기술 관리자 제프 세로타는 자사의 API 사용량이 지난 몇 개월 동안 극적으로 증가했다고 말했다. 현재, API는 약 3,000개의 엔드포인트를 연결하며, 여기에는 내부 애플리케이션과 비즈니스 파트너의 애플리케이션뿐 아니라 고객용 웹 사이트와 모바일 기기까지 포함된다.

세로타는 "이것은 시작에 불과하다. 5년이 소요될 것으로 예상되는 프로세스를 2년 동안 진행했으며, 남은 3년은 속도가 빨라질 것이다. 약 16개월 전에 새로운 CIO를 영입했고, 그는 API 개발 출신이었기 때문에 그 속도를 높이는 데 확실히 기여했다"라고 밝혔다.

현재까지 이 금융업체는 대부분 기초 작업을 수행했다. 세로타는 "우리는 실제로 모든 온프레미스 데이터센터를 없애고 모든 것을 웹서비스와 API로 전환하는 계획을 진행 중이다"라고 설명했다. 

세로타는 "API 호출은 다양한 파라미터를 포함해 다양한 서비스를 사용해 4개의 메인 URL을 통해 이뤄진다. 이 접근 방식으로 보호 계층이 만들어진다. API의 위험성 때문에 우리는 횡적 이동 또는 발견을 어렵게 하기 위해 API 엔드포인트 이름 중 일부를 헷갈리게 만들었다"라고 말했다. 이 금융업체는 지난 6개월 동안 다수의 API 게이트웨이를 하나의 주된 게이트웨이로 통합했다. 

API 게이트웨이의 경우, 이 금융업체는 2016년에 구글이 인수한 API 보안 제공업체인 아피지(Apigee)를 이용한다. 일부 기업은 모든 개발자가 하나의 게이트웨이를 이용하도록 하는 데 어려움을 겪거나 잠재적인 병목, 단일 장애 지점, DDOS 공격 등에 대해 우려했다. 세로타는 "우리는 그렇지 않다. 우리의 개발자는 실제로 API 게이트웨이 방식을 선호한다. SaaS 기반의 다지역성을 가졌으며 실제로 더 나은 가용성과 낮은 지연 속도를 제공한다. 그들은 자동 확장이 지원된다는 것을 알고 있기 때문에 전통적인 API 게이트웨이 같은 게이트웨이 제약이 없다”라고 밝혔다.

예를 들어, 이 금융업체는 하나의 API는 월간 1,000만 건의 트랜잭션을 기록할 것으로 예상됐지만 출시 후 첫 2주 동안 2억 건을 기록했다. 세로타는 “지연 속도나 성능 저하를 전혀 느끼지 못했다"라고 말했다. 현재, 해당 생산 환경에서는 2년 전의 약 8억 건보다 많은 월 약 20억 건의 API 호출이 이뤄지고 있다.

인증의 경우, 이 금융업체의 모바일 및 웹 기반 앱은 오래된 자바(Java) 기술을 사용한다. 세로타는 "하지만 우리는 이것을 소프트웨어 개발 키트를 사용해 모두 API 기반 인증으로 이전하고 있다. 현재 이전의 주요한 부분이며 여러 부서들의 대대적인 협업이 필요했다"라고 설명했다. 

이 새로운 접근방식은 기관이 자격 증명 기반 공격을 찾는 방식을 완전히 바꾸어 놓았다. 외부 파트너에 대해 이 금융업체는 자사의 API 호출을 위해 제로 트러스트(Zero Trust) 모델을 추진하고 있다. 그는 “우리는 속도를 높이겠지만 아직 준비가 되지 않은 파트너들이 있다”라고. 

자체 웹 또는 모바일 앱을 통해 업체에 접근하는 소비자들의 경우, 퍼시스턴스(Pesistence)가 있다. 즉, 소비자들이 인증 프로세스를 여러 번 거칠 필요가 없다. 세로타는 “제로 트러스트 모델이 있으면 모든 세션 퍼시스턴스와 쿠키(Cookie) 사용을 허용하지 않는다. 매번 다시 인증해야 한다. 안전하거나 편리하거나 빠른 것을 원할 때 2가지를 선택할 수는 있지만 전부를 선택할 수는 없다”라고 말했다.

하지만 회사의 보안 경계 내에 있는 API의 경우 또 다른 접근방식이 있다. 세로타는 “내부에 있으면 제로 트러스트 외에 더 가벼운 다른 방법을 사용한다. 우리는 목적지, 인증 서비스 계정, 액티브 디렉터리 기반으로 수행하는 일 등에 따라 IP 보안을 사용하고 있다”라고 밝혔다.

이 금융업체는 외부 및 내부 트래픽의 의심스러운 행동을 탐지하기 위해 행동 분석도 마련되어 있으며, 확실히 잘못된 메시지는 자동으로 필터링한다. 세로타는 “현관에서 밀에서 왕겨를 분리할 수 있기 때문에 예상되는 정상 호출을 더욱 집중적으로 살펴볼 수 있다. 행동 분석은 실제 트랜잭션 자체에 대해서도 실시한다. 우리는 IP 명성부터 행동 분석과 사용자 및 계정 패턴 분석까지 모든 것을 사용한다. 격주로 금요일마다 200달러의 예금을 받고 이제 수요일마다 800달러짜리 수표를 예금하기 시작하는 경우, 우리는 그것을 살펴보기 시작한다. 단순히 우리의 자산을 보호하는 것이 아니라 돈세탁 또는 인신매매일 수 있는 것을 선제적으로 보고할 수 있도록 하는 것이 목적이다”라고 설명했다.

자동화를 통해 이 업체는 네트워크 운영 센터와 사이버보안 사건 대응팀에 도달하는 문제의 수를 35%나 줄일 수 있었으며, 도달하는 긍정 오류가 줄어들었다.

이를 위해 약 1년 전에 NOC와 CSIRT팀은 아피지 API 게이트웨이와의 공유 흐름에서 사용하는 솔트 시큐리티를 배치했다. 세로타는 “우리의 상위 API로 유입되는 모든 트래픽을 감시한 후 학습해 확률이 높은 공격자와 코드를 개선하는 방법에 관한 추천사항을 알려준다”라고 말했다.

사기 탐지팀, 개발팀, 보안 아키텍처팀 등 다른 팀도 이 플랫폼을 도입했다. 이를 통해 이 업체는 API 마이그레이션 타임라인을 가속화할 수 있었다.


API에 대한 봇(Bot) 공격

API 트래픽이 증가하고 있지만 악성 API 트래픽이 더 빠르게 증가하고 있다. 솔트 시큐리티의 고객들의 월 API 호출량은 51% 증가했지만 악성 트래픽은 211%나 증가했다.

금융서비스, 소매, 미디어, 엔터테인먼트 산업의 100개 기업 고객의 월 API 데이터 가치에 대한 아카마이의 분석에서 7,440억 회의 API 호출이 발견됐으며, 이 가운데 12%는 알려진 악의적인 활동가로부터 발생했고 25%는 웹 브라우저나 모바일 기기 또는 애플리케이션이 아닌 엔드포인트 클라이언트에서 발생했다. 즉, 정상적인 사용자가 아니라 악의적인 활동가에 의해 발생했을 수도 있다.

언스트앤영(Ernst & Young)의 상무이사 리시 판데는 웹 사이트와 모바일 앱 등 전통적인 프론트 엔드 애플리케이션은 공격자에 대한 방어책이 마련되어 있다고 말했다. 여기에는 DDoS, 크리덴셜 스터핑(Credential Stuffing), 기타 자동화된 공격에 대한 방어가 포함된다. 판데는 “프론트 엔드가 보호될 수 있지만 API 게이트웨이가 보호되지 않으면 쉽게 넘쳐 흐를 수 있다”라고 말했다. 이 공간은 빠르게 발전하고 있고, 일부 고객은 기술이 보호를 제공한다고 가정하지만 도구 자체는 아직 준비가 제대로 되어 있지 않다. 크리덴셜 스터핑 문제는 API로 해결되지 않는다. 판데는 “사람들은 아직 크리덴셜 스터핑 문제를 해결하지 않았다”라고 지적했다. 

시퀀스 시큐리티(Cequence Security)의 전속 해커인 제이슨 켄트는 "사실, API 계층에 대한 공격은 해커 사이에서 인기를 얻고 있으며, 그 이유는 익명성이 더 크며, API가 일반적으로 웹 사이트와 모바일 앱만큼 보호되지 않기 때문"이라고 말했다. 켄트는 차고 도어 업체의 API로 설계 문제를 이용해 차고 도어를 여는 방법을 알아냈다.

켄트는 “일반적인 웹 사이트 보안에는 클라이언트 측에서 확인할 수 있는 모든 추가적인 코드가 있기 때문에 공격자인지 아니면 진짜 사람인지 알 수 있다. API에서는 이 모든 것들을 없애 버렸다. 우리는 실제로 공격이 원하는 빈도로 빠르게 발생하도록 도왔다”라고 밝혔다.

켄트는 현재 API 보안은 2009년의 애플리케이션 보안과 비슷하다고 말했다. 그가 차고 도어 API를 해킹했던 방법은 모바일 애플리케이션을 살펴보는 것이었다. 그는 “앱 스토어에서 다운로드하는 앱에는 여러 개의 압축된 폴더와 파일이 있다. 통신하는 모든 API 종점의 목록이 포함되어 있다”라고 말했다. 켄트는 OWASP를 위해 수행하는 방법을 가르치고 있다.

공격자가 모바일 앱을 분석해 통신 방법을 알아내면 같은 API 채널을 사용해 요청을 전송할 수 있다. 봇에서 오는 API 요청은 정상적인 앱을 사용하는 실제 사람의 그것과 다르기 때문에 AI와 머신러닝은 이를 방어하는 데 도움이 된다.


방향을 바꾸어야 할 때

1만 3,500명 이상의 개발자를 조사한 포스트맨(Postman)의 2020년 API 실태 보고서에 따르면, 기업 가운데 36%만이 API의 보안 테스트를 진행하고 있는 것으로 나타났다. 반면에 70%는 기능 테스트를 하고 67%는 통합 테스트를 진행했다. 스마트베어의 2020년 API 실태 보고서에 따르면, API와 관련해 가용성이 개발자들의 가장 큰 우려사항이었으며, 기능이 그 뒤를 이었고 보안은 세 번째였다.

개발팀이 보안팀과 분리되어 있고 네트워킹 및 인프라 팀과도 분리되어 있는 것도 문제였다. 캡제미니 북아메리카의 수석 사이버보안 관리자 앨버트 웨일은 “사일로의 해결책은 데브섹옵스(DevSecOps)이다. 이제 우리는 테스트를 통합하고 테스트 통제권을 애플리케이션 개발자에게 제공할 수 있다. 우리는 모두를 보안팀에 소속시킨다”라고 말했다.

처음부터 더욱 안전한 애플리케이션을 개발하는 것이 API 게이트웨이 같은 기술을 사용해서 마지막에 보호하려고 하는 것보다 더 중요하다. 웨일은 “API 게이트웨이는 단일 장애점이라고 생각한다. 모든 정보를 수집하고 다시 내보내야 하기 때문에 애플리케이션의 속도를 저하시킬 것이다. 그렇다고 끔찍할 정도는 아니며 웹 애플리케이션 방화벽과 마찬가지로 용도에 적합하지만 이를 활용하고 확장할 필요가 있을 때가 있다”라고 설명했다.

대신, 기업은 더 나은 아키텍처, 더 나은 보안, 더 나은 API 호출에 집중해야 한다. 웨일은 “더 긴 시간이 소요되지만 더 나은 보호를 위해서는 코드가 개선된 애플리케이션이 필요하다. 애플리케이션이 공격에 저항할 만큼 탄탄하게 만들 수 있다면 추가적인 보안을 제공하기 위한 다른 요소가 필요 없다"라고 덧붙였다.

개발자들은 보안을 더욱 의식하기 시작했다고 사이버보안 조사 기업 시큐로시스(Securosis)의 분석가이자 사장 마이크 로스만이 말했다. 로스만은 "데브섹(DevSec)이 사람들의 협업을 이끌어내고 있다. 항상 이런 일이 발생할까? 항상 그렇지는 않지만 우리는 많은 사일로와 벽을 무너뜨리고 팀들이 협력할 수 있도록 하기 위해 노력하고 있다”라고 말했다.

API 보안의 경우 다양한 취약점 영역이 존재하는 데, 비즈니스 로직으로부터 시작된다. 로스만은 “우리가 지금까지 제대로 하지 못한 애플리케이션 보안의 주요 측면 가운데 하나"라고. 하나의 애플리케이션이 API들로 연결된 작은 서비스로 분리되면서 로직 오류를 찾아 완화하는 문제가 증폭되었다. 애플리케이션은 설계된 대로 정확히 작동할 수 있으며, 인증 메커니즘이 완벽하게 보호할 수 있고 취약점이 전혀 없을 수 있지만 코딩에 문제가 있으면 여전히 해킹이 발생할 수 있다.

그리고 주의해야 하는 일반적인 일련의 취약점이 있다. 2019년에 공개된 10대 OWASP API는 지난 2년 동안 바뀌지 않았다. 로스만은 “우리는 계속해서 같은 문제를 겪고 있다. 그리고 우리는 전통적인 네트워크 기술, 전통적인 애플리케이션 보안 기술 등 다양한 수준에서 환경을 방어해야 한다”라고 지적했다.

마지막으로, 조직은 API 보안을 수동으로 모니터링할 사람들이 충분하지 않기 때문에 도구, 자동화, 스캔 기술, 원격 측정 모니터링을 살펴봐야 한다. 로스만은 "우리는 사람 외의 것들을 활용해야 한다. 모니터링을 통해 API가 호출되는 방식을 판단하고 악성 오용을 나타낼 수 있는 비정상적인 행동을 찾아야 한다”라고 주장했다. 


API 보안 가시성을 확보하는 창고 기업

개발자들이 웹 서비스를 만들어 API를 설정하기가 쉬워졌다. 새로운 기술이 늘 그렇듯이, 보안이 뒤쳐질 때가 많다. 

개발자들이 모두 새로운 보안 제어에 참여하더라도 여전히 구식 시스템이 존재할 수 있다. 이런 오래된 좀비 API는 짧은 기간 동안 사용할 것으로 예상했지만 계속 사용하고 있다면 큰 위험이 된다.

물류기업 프롤로지스(Prologis)의 보안 책임자 타일러 워렌은 “잘 모르는 것을 보호할 수는 없다. API 보안 솔루션을 보면서 이를 보호할 수 있는 방법이 뭐가 있는지 알아야 한다. 모르고 있다면 애시당초 가능성이 없는 것이다. 우리에게 무엇이 있는지 파악하는 것이 첫 번째 우선순위다”라고 말했다.

프롤로지스의 API 보안 프로그램을 담당하고 있는 워렌은 4년 전 우선적으로 프롤로지스의 고객용 시스템을 개발하기 시작했다. 워렌은 “19개 국가에 10억 제곱피트에 달하는 약 5,000개의 창고를 소유하고 있다. 사람들이 물류 기업이라고 하면 ‘첨단 기술로 무엇을 하냐?’고 말한다. 하지만 경영진은 기술이 비용 센터가 아니라 비즈니스의 촉매라고 판단했다"라고 설명했다.

그래서 프롤로지스가 바뀌었다. 프롤로지스는 현재 클라우드 기반 프롤로지스 에션셜스(Prologis Essentials) 플랫폼이 있어, 고객들이 서비스 티켓을 제출하거나 청구서 상태를 확인할 수 있으면서, 누군가 새로운 창고로 이동할 때 필요한 방역, 지게차, 조명, 기타 제품 및 서비스를 제공하는 현지 공급업체와 연결할 수 있다.

새로운 시스템이었고 이에 대응하는 구식 시스템이 없었기 때문에 프롤로지스는 처음부터 클라우드 기반 서버리스 아키텍처로 시작했다. 워렌은 “우리는 심지어 컨테이너를 건너뛰었다. 우리는 거의 100% 서버리스이다. 우리는 기본적으로 아마존과 람다(lambda) 기능이다”라고 말했다.

프롤로지스 에센셜스는 AWS API 게이트웨이를 사용하며 약 15개의 API가 500개의 엔드포인트에 서비스를 제공하고 여기에는 내부 연결뿐 아니라 외부 비즈니스 파트너와의 통합도 포함되어 있다고 워렌이 말했다. 지난 달, 이 시스템은 52만 9,000개의 API 요청을 처리했다.

워렌은 AWS가 API에 관해 많은 정보를 제공하지 않는다는 사실을 발견했다. 워렌은 “AWS 자체는 그 정보를 제공하지 않는다. 우리는 일부 구형 방식을 시도해 보았는데, 아무것도 없는 경우 약간의 보호를 제공하기는 하지만 웹 애플리케이션 방화벽이 작동하지 않았다”라고 말했다.

워렌은 배치가 쉽고 개발팀에 방해가 되지 않는 기술을 찾았다. 그는 “그 관계가 엉망이 되면 문제가 된다. 보안 직원이 ‘안돼’ 라고 이야기하면 그들은 우회하기 시작한다. 그래서 솔루션이 워크플로우에 적합하고 추가적인 업무를 발생시켜야 한다”라고 토로했다. 

프롤로지스는 솔트 시큐리티를 선택했다. 원래는 2021년에 롤아웃을 계획했지만, 2020년에 하기로 결정했다. 워렌은 “API 공격 표면이 더 큰 관심을 끌고 있다. 악당들은 공격 표면이 많다는 것을 알아차렸다”라고 말했다.

에센셜스 시스템을 위해 솔트 시큐리티를 배치하기까지 약 1개월이 소요되었다. 프롤로지스는 많은 테스트를 진행했고 개발자에게 문제가 없으며 성능이 영향이 없도록 많은 노력을 기울였다.

이 도구는 AWS 환경에 있으며 API 게이트웨이에서 트래픽을 감시하고 로그와 메타데이터를 확보하며 알림 및 보고를 위해 보고서를 솔트의 SaaS 대시보드로 보낸다. 

워렌은 “처음에는 100개의 API 엔드포인트가 있다고 추정했다. 결국 500개가 있었다. 일반적으로 나는 네트워크에 관해 꽤 잘 파악하고 있는 편이지만, 나의 예상은 크게 빗나갔다. 이 문제는 이 업계에서 보편적이며, 사람들은 보유하고 있는 것을 과소평가하는 경우가 많다”라고 설명했다.

지난해 가을, 시스템이 가동을 시작했다. 결국, WAF에 연결하고 동작을 자동으로 실행하게 되었다. 현재, 보안 직원들이 수동으로 확인할 수 있는 보고서를 전송한다. 워렌은 “마지막으로 내가 하고 싶은 것은 정상적인 트래픽을 차단하는 것이다”라고 피력했다.

또한 이 시스템은 잠재적인 API 유출을 감시한다. 예를 들어, AWS 프라이빗 키가 유출되었을 수 있다는 알림을 받았지만 긍정 오류로 밝혀졌다. 워렌은 “AWS 키처럼 보이는 계좌 번호가 있었는데, 그것은 우연이었다”라고 말했다.

또한 이 시스템은 API가 엄격하게 필요한 것보다 많은 정보를 제공하는 사례도 일부 발견했다. 워렌은 “그렇게 민감하지는 않지만 이메일 주소와 계좌 번호의 조합이 있었다. 하지만 나는 '절대적으로 필요하지 않으면 하지 말라'는 주의다”라고 설명했다. 많은 기업이 API에 대해 이 조언을 따라야 한다. editor@itworld.co.kr 


2021.05.26

API 공격의 메커니즘과 이를 확인, 예방하는 방법

Maria Korolov | CSO
5월 초, 피트니스 기업 펠로톤(Peloton)은 인터넷에 고객 계정 데이터가 노출되었다고 발표했다. 사용자가 계정 프로필을 비공개로 설정했더라도 누구든 펠로톤 서버에 있는 사용자의 계정 데이터에 접근할 수 있었다. 원인은 무단 요청을 허용하는 결함이 있는 API(Application Programming Interface)였다.
 
ⓒ Getty Images Bank

손쉬운 사물통신(machine-to-machine)을 가능하게 하는 API 사용량이 최근 폭발적으로 증가했다. 아카마이(Akamai)에 따르면, API 통신은 현재 전체 인터넷 트래픽의 83% 이상을 차지한다.

또한 많은 보안 문제의 원인이기도 하다. 펠로톤 외에도 최근 API 관련 사이버보안 문제로 뉴스에 나왔던 기업은 에퀴팩스(Equifax), 인스타그램(Instagram), 페이스북(Facebook), 아마존(Amazon), 페이팔(Paypal) 등이 있다.


API 사용 증가와 비례하는 공격 

솔트 시큐리티(Salt Security)가 2월에 공개한 보고서에 따르면, 기업 가운데 91%가 지난해 API와 관련된 보안 문제를 겪은 것으로 나타났다. 가장 보편적인 것은 취약점이었으며, 응답자 가운데 54%를 차지했고 46%는 인증 문제, 20%는 봇 문제, 19%는 DoS(Denial of Service) 문제를 겪었다.

80%의 기업이 보안 도구로 API 공격을 효과적으로 방지할 수 없다고 생각한다. 솔트 시큐리티의 조사에 따르면, 기업 가운데 2/3가 API 보안 관련 우려 때문에 새로운 애플리케이션의 생산 속도를 늦췄다고 한다. WAF(Web Application Firewall)과 API 게이트웨이를 갖춘 솔트의 고객은 모두 매월 다수의 API 공격을 경험하고 있으며, 이는 API 공격이 이런 보안 도구를 통과했다는 것을 의미한다. 솔트에 따르면, WAF와 API 게이트웨이는 OWASP API 보안 10대 위협 가운데 90%를 놓친다.

하지만 1/4 이상의 기업이 보안 전략 없이 중요한 API 기반 애플리케이션을 운용하고 있다. SCRC(Synopsys Cybersecurity Research Center)의 수석 보안 전략가 팀 맥키는 "펠로톤은 본래 인증 없이 API를 통해 누구에게든 장소에 상관없이 사용자 데이터 접근을 제공했다"라고 말했다. 맥키는 “API 보안을 위해 펠로톤이 취한 첫번째 조치는 가입자에 접근을 제한하는 것이었지만, 모든 사용자가 여전히 개인정보 보호 설정에 상관없이 다른 사용자의 데이터에 접근할 수 있었다. 사용자의 연령과 성별, 프로필 이미지 등의 데이터와 일부 활동 데이터에 접근할 수 있었다”라고 설명했다.

API 유출은 드물지 않다. 솔트 시큐리티의 보고서에 따르면, 기업 가운데 82%는 API에 사유 네트워크 정보, 보호되는 건강 정보, 카드 소유자 데이터 등의 PII(Personally Identifiable Information)가 포함되어 있는지 여부 등의 API 세부사항을 잘 모르고 있었으며, 22%의 기업은 어떤 API가 민감한 데이터를 노출시키는지 알 수 없다고 밝혔다.

트레이서블(Traceable)의 보안 연구 엔지니어 로샨 피유시는 "펠로톤의 실수는 망가진 객체 레벨 인증에 취약한 미인증 API를 사용한 것이었다"라고 말했다. 피유시는 이런 문제에 직면한 기업으로는 파네라(Panera), 피서브(Fiserv), 라이프록(LifeLock), 케이 주얼스(Kay Jewelers) 등이 있었다고. 피유시는 “그 외에도 많다. 일반적으로 개발 프로세스 중 API에 대한 인증과 승인 보호를 간과하면서 발생하는 것이 원인이다”라고 지적했다.


한 은행의 API 성장 스토리

중형 금융업체의 사이버보안 기술 관리자 제프 세로타는 자사의 API 사용량이 지난 몇 개월 동안 극적으로 증가했다고 말했다. 현재, API는 약 3,000개의 엔드포인트를 연결하며, 여기에는 내부 애플리케이션과 비즈니스 파트너의 애플리케이션뿐 아니라 고객용 웹 사이트와 모바일 기기까지 포함된다.

세로타는 "이것은 시작에 불과하다. 5년이 소요될 것으로 예상되는 프로세스를 2년 동안 진행했으며, 남은 3년은 속도가 빨라질 것이다. 약 16개월 전에 새로운 CIO를 영입했고, 그는 API 개발 출신이었기 때문에 그 속도를 높이는 데 확실히 기여했다"라고 밝혔다.

현재까지 이 금융업체는 대부분 기초 작업을 수행했다. 세로타는 "우리는 실제로 모든 온프레미스 데이터센터를 없애고 모든 것을 웹서비스와 API로 전환하는 계획을 진행 중이다"라고 설명했다. 

세로타는 "API 호출은 다양한 파라미터를 포함해 다양한 서비스를 사용해 4개의 메인 URL을 통해 이뤄진다. 이 접근 방식으로 보호 계층이 만들어진다. API의 위험성 때문에 우리는 횡적 이동 또는 발견을 어렵게 하기 위해 API 엔드포인트 이름 중 일부를 헷갈리게 만들었다"라고 말했다. 이 금융업체는 지난 6개월 동안 다수의 API 게이트웨이를 하나의 주된 게이트웨이로 통합했다. 

API 게이트웨이의 경우, 이 금융업체는 2016년에 구글이 인수한 API 보안 제공업체인 아피지(Apigee)를 이용한다. 일부 기업은 모든 개발자가 하나의 게이트웨이를 이용하도록 하는 데 어려움을 겪거나 잠재적인 병목, 단일 장애 지점, DDOS 공격 등에 대해 우려했다. 세로타는 "우리는 그렇지 않다. 우리의 개발자는 실제로 API 게이트웨이 방식을 선호한다. SaaS 기반의 다지역성을 가졌으며 실제로 더 나은 가용성과 낮은 지연 속도를 제공한다. 그들은 자동 확장이 지원된다는 것을 알고 있기 때문에 전통적인 API 게이트웨이 같은 게이트웨이 제약이 없다”라고 밝혔다.

예를 들어, 이 금융업체는 하나의 API는 월간 1,000만 건의 트랜잭션을 기록할 것으로 예상됐지만 출시 후 첫 2주 동안 2억 건을 기록했다. 세로타는 “지연 속도나 성능 저하를 전혀 느끼지 못했다"라고 말했다. 현재, 해당 생산 환경에서는 2년 전의 약 8억 건보다 많은 월 약 20억 건의 API 호출이 이뤄지고 있다.

인증의 경우, 이 금융업체의 모바일 및 웹 기반 앱은 오래된 자바(Java) 기술을 사용한다. 세로타는 "하지만 우리는 이것을 소프트웨어 개발 키트를 사용해 모두 API 기반 인증으로 이전하고 있다. 현재 이전의 주요한 부분이며 여러 부서들의 대대적인 협업이 필요했다"라고 설명했다. 

이 새로운 접근방식은 기관이 자격 증명 기반 공격을 찾는 방식을 완전히 바꾸어 놓았다. 외부 파트너에 대해 이 금융업체는 자사의 API 호출을 위해 제로 트러스트(Zero Trust) 모델을 추진하고 있다. 그는 “우리는 속도를 높이겠지만 아직 준비가 되지 않은 파트너들이 있다”라고. 

자체 웹 또는 모바일 앱을 통해 업체에 접근하는 소비자들의 경우, 퍼시스턴스(Pesistence)가 있다. 즉, 소비자들이 인증 프로세스를 여러 번 거칠 필요가 없다. 세로타는 “제로 트러스트 모델이 있으면 모든 세션 퍼시스턴스와 쿠키(Cookie) 사용을 허용하지 않는다. 매번 다시 인증해야 한다. 안전하거나 편리하거나 빠른 것을 원할 때 2가지를 선택할 수는 있지만 전부를 선택할 수는 없다”라고 말했다.

하지만 회사의 보안 경계 내에 있는 API의 경우 또 다른 접근방식이 있다. 세로타는 “내부에 있으면 제로 트러스트 외에 더 가벼운 다른 방법을 사용한다. 우리는 목적지, 인증 서비스 계정, 액티브 디렉터리 기반으로 수행하는 일 등에 따라 IP 보안을 사용하고 있다”라고 밝혔다.

이 금융업체는 외부 및 내부 트래픽의 의심스러운 행동을 탐지하기 위해 행동 분석도 마련되어 있으며, 확실히 잘못된 메시지는 자동으로 필터링한다. 세로타는 “현관에서 밀에서 왕겨를 분리할 수 있기 때문에 예상되는 정상 호출을 더욱 집중적으로 살펴볼 수 있다. 행동 분석은 실제 트랜잭션 자체에 대해서도 실시한다. 우리는 IP 명성부터 행동 분석과 사용자 및 계정 패턴 분석까지 모든 것을 사용한다. 격주로 금요일마다 200달러의 예금을 받고 이제 수요일마다 800달러짜리 수표를 예금하기 시작하는 경우, 우리는 그것을 살펴보기 시작한다. 단순히 우리의 자산을 보호하는 것이 아니라 돈세탁 또는 인신매매일 수 있는 것을 선제적으로 보고할 수 있도록 하는 것이 목적이다”라고 설명했다.

자동화를 통해 이 업체는 네트워크 운영 센터와 사이버보안 사건 대응팀에 도달하는 문제의 수를 35%나 줄일 수 있었으며, 도달하는 긍정 오류가 줄어들었다.

이를 위해 약 1년 전에 NOC와 CSIRT팀은 아피지 API 게이트웨이와의 공유 흐름에서 사용하는 솔트 시큐리티를 배치했다. 세로타는 “우리의 상위 API로 유입되는 모든 트래픽을 감시한 후 학습해 확률이 높은 공격자와 코드를 개선하는 방법에 관한 추천사항을 알려준다”라고 말했다.

사기 탐지팀, 개발팀, 보안 아키텍처팀 등 다른 팀도 이 플랫폼을 도입했다. 이를 통해 이 업체는 API 마이그레이션 타임라인을 가속화할 수 있었다.


API에 대한 봇(Bot) 공격

API 트래픽이 증가하고 있지만 악성 API 트래픽이 더 빠르게 증가하고 있다. 솔트 시큐리티의 고객들의 월 API 호출량은 51% 증가했지만 악성 트래픽은 211%나 증가했다.

금융서비스, 소매, 미디어, 엔터테인먼트 산업의 100개 기업 고객의 월 API 데이터 가치에 대한 아카마이의 분석에서 7,440억 회의 API 호출이 발견됐으며, 이 가운데 12%는 알려진 악의적인 활동가로부터 발생했고 25%는 웹 브라우저나 모바일 기기 또는 애플리케이션이 아닌 엔드포인트 클라이언트에서 발생했다. 즉, 정상적인 사용자가 아니라 악의적인 활동가에 의해 발생했을 수도 있다.

언스트앤영(Ernst & Young)의 상무이사 리시 판데는 웹 사이트와 모바일 앱 등 전통적인 프론트 엔드 애플리케이션은 공격자에 대한 방어책이 마련되어 있다고 말했다. 여기에는 DDoS, 크리덴셜 스터핑(Credential Stuffing), 기타 자동화된 공격에 대한 방어가 포함된다. 판데는 “프론트 엔드가 보호될 수 있지만 API 게이트웨이가 보호되지 않으면 쉽게 넘쳐 흐를 수 있다”라고 말했다. 이 공간은 빠르게 발전하고 있고, 일부 고객은 기술이 보호를 제공한다고 가정하지만 도구 자체는 아직 준비가 제대로 되어 있지 않다. 크리덴셜 스터핑 문제는 API로 해결되지 않는다. 판데는 “사람들은 아직 크리덴셜 스터핑 문제를 해결하지 않았다”라고 지적했다. 

시퀀스 시큐리티(Cequence Security)의 전속 해커인 제이슨 켄트는 "사실, API 계층에 대한 공격은 해커 사이에서 인기를 얻고 있으며, 그 이유는 익명성이 더 크며, API가 일반적으로 웹 사이트와 모바일 앱만큼 보호되지 않기 때문"이라고 말했다. 켄트는 차고 도어 업체의 API로 설계 문제를 이용해 차고 도어를 여는 방법을 알아냈다.

켄트는 “일반적인 웹 사이트 보안에는 클라이언트 측에서 확인할 수 있는 모든 추가적인 코드가 있기 때문에 공격자인지 아니면 진짜 사람인지 알 수 있다. API에서는 이 모든 것들을 없애 버렸다. 우리는 실제로 공격이 원하는 빈도로 빠르게 발생하도록 도왔다”라고 밝혔다.

켄트는 현재 API 보안은 2009년의 애플리케이션 보안과 비슷하다고 말했다. 그가 차고 도어 API를 해킹했던 방법은 모바일 애플리케이션을 살펴보는 것이었다. 그는 “앱 스토어에서 다운로드하는 앱에는 여러 개의 압축된 폴더와 파일이 있다. 통신하는 모든 API 종점의 목록이 포함되어 있다”라고 말했다. 켄트는 OWASP를 위해 수행하는 방법을 가르치고 있다.

공격자가 모바일 앱을 분석해 통신 방법을 알아내면 같은 API 채널을 사용해 요청을 전송할 수 있다. 봇에서 오는 API 요청은 정상적인 앱을 사용하는 실제 사람의 그것과 다르기 때문에 AI와 머신러닝은 이를 방어하는 데 도움이 된다.


방향을 바꾸어야 할 때

1만 3,500명 이상의 개발자를 조사한 포스트맨(Postman)의 2020년 API 실태 보고서에 따르면, 기업 가운데 36%만이 API의 보안 테스트를 진행하고 있는 것으로 나타났다. 반면에 70%는 기능 테스트를 하고 67%는 통합 테스트를 진행했다. 스마트베어의 2020년 API 실태 보고서에 따르면, API와 관련해 가용성이 개발자들의 가장 큰 우려사항이었으며, 기능이 그 뒤를 이었고 보안은 세 번째였다.

개발팀이 보안팀과 분리되어 있고 네트워킹 및 인프라 팀과도 분리되어 있는 것도 문제였다. 캡제미니 북아메리카의 수석 사이버보안 관리자 앨버트 웨일은 “사일로의 해결책은 데브섹옵스(DevSecOps)이다. 이제 우리는 테스트를 통합하고 테스트 통제권을 애플리케이션 개발자에게 제공할 수 있다. 우리는 모두를 보안팀에 소속시킨다”라고 말했다.

처음부터 더욱 안전한 애플리케이션을 개발하는 것이 API 게이트웨이 같은 기술을 사용해서 마지막에 보호하려고 하는 것보다 더 중요하다. 웨일은 “API 게이트웨이는 단일 장애점이라고 생각한다. 모든 정보를 수집하고 다시 내보내야 하기 때문에 애플리케이션의 속도를 저하시킬 것이다. 그렇다고 끔찍할 정도는 아니며 웹 애플리케이션 방화벽과 마찬가지로 용도에 적합하지만 이를 활용하고 확장할 필요가 있을 때가 있다”라고 설명했다.

대신, 기업은 더 나은 아키텍처, 더 나은 보안, 더 나은 API 호출에 집중해야 한다. 웨일은 “더 긴 시간이 소요되지만 더 나은 보호를 위해서는 코드가 개선된 애플리케이션이 필요하다. 애플리케이션이 공격에 저항할 만큼 탄탄하게 만들 수 있다면 추가적인 보안을 제공하기 위한 다른 요소가 필요 없다"라고 덧붙였다.

개발자들은 보안을 더욱 의식하기 시작했다고 사이버보안 조사 기업 시큐로시스(Securosis)의 분석가이자 사장 마이크 로스만이 말했다. 로스만은 "데브섹(DevSec)이 사람들의 협업을 이끌어내고 있다. 항상 이런 일이 발생할까? 항상 그렇지는 않지만 우리는 많은 사일로와 벽을 무너뜨리고 팀들이 협력할 수 있도록 하기 위해 노력하고 있다”라고 말했다.

API 보안의 경우 다양한 취약점 영역이 존재하는 데, 비즈니스 로직으로부터 시작된다. 로스만은 “우리가 지금까지 제대로 하지 못한 애플리케이션 보안의 주요 측면 가운데 하나"라고. 하나의 애플리케이션이 API들로 연결된 작은 서비스로 분리되면서 로직 오류를 찾아 완화하는 문제가 증폭되었다. 애플리케이션은 설계된 대로 정확히 작동할 수 있으며, 인증 메커니즘이 완벽하게 보호할 수 있고 취약점이 전혀 없을 수 있지만 코딩에 문제가 있으면 여전히 해킹이 발생할 수 있다.

그리고 주의해야 하는 일반적인 일련의 취약점이 있다. 2019년에 공개된 10대 OWASP API는 지난 2년 동안 바뀌지 않았다. 로스만은 “우리는 계속해서 같은 문제를 겪고 있다. 그리고 우리는 전통적인 네트워크 기술, 전통적인 애플리케이션 보안 기술 등 다양한 수준에서 환경을 방어해야 한다”라고 지적했다.

마지막으로, 조직은 API 보안을 수동으로 모니터링할 사람들이 충분하지 않기 때문에 도구, 자동화, 스캔 기술, 원격 측정 모니터링을 살펴봐야 한다. 로스만은 "우리는 사람 외의 것들을 활용해야 한다. 모니터링을 통해 API가 호출되는 방식을 판단하고 악성 오용을 나타낼 수 있는 비정상적인 행동을 찾아야 한다”라고 주장했다. 


API 보안 가시성을 확보하는 창고 기업

개발자들이 웹 서비스를 만들어 API를 설정하기가 쉬워졌다. 새로운 기술이 늘 그렇듯이, 보안이 뒤쳐질 때가 많다. 

개발자들이 모두 새로운 보안 제어에 참여하더라도 여전히 구식 시스템이 존재할 수 있다. 이런 오래된 좀비 API는 짧은 기간 동안 사용할 것으로 예상했지만 계속 사용하고 있다면 큰 위험이 된다.

물류기업 프롤로지스(Prologis)의 보안 책임자 타일러 워렌은 “잘 모르는 것을 보호할 수는 없다. API 보안 솔루션을 보면서 이를 보호할 수 있는 방법이 뭐가 있는지 알아야 한다. 모르고 있다면 애시당초 가능성이 없는 것이다. 우리에게 무엇이 있는지 파악하는 것이 첫 번째 우선순위다”라고 말했다.

프롤로지스의 API 보안 프로그램을 담당하고 있는 워렌은 4년 전 우선적으로 프롤로지스의 고객용 시스템을 개발하기 시작했다. 워렌은 “19개 국가에 10억 제곱피트에 달하는 약 5,000개의 창고를 소유하고 있다. 사람들이 물류 기업이라고 하면 ‘첨단 기술로 무엇을 하냐?’고 말한다. 하지만 경영진은 기술이 비용 센터가 아니라 비즈니스의 촉매라고 판단했다"라고 설명했다.

그래서 프롤로지스가 바뀌었다. 프롤로지스는 현재 클라우드 기반 프롤로지스 에션셜스(Prologis Essentials) 플랫폼이 있어, 고객들이 서비스 티켓을 제출하거나 청구서 상태를 확인할 수 있으면서, 누군가 새로운 창고로 이동할 때 필요한 방역, 지게차, 조명, 기타 제품 및 서비스를 제공하는 현지 공급업체와 연결할 수 있다.

새로운 시스템이었고 이에 대응하는 구식 시스템이 없었기 때문에 프롤로지스는 처음부터 클라우드 기반 서버리스 아키텍처로 시작했다. 워렌은 “우리는 심지어 컨테이너를 건너뛰었다. 우리는 거의 100% 서버리스이다. 우리는 기본적으로 아마존과 람다(lambda) 기능이다”라고 말했다.

프롤로지스 에센셜스는 AWS API 게이트웨이를 사용하며 약 15개의 API가 500개의 엔드포인트에 서비스를 제공하고 여기에는 내부 연결뿐 아니라 외부 비즈니스 파트너와의 통합도 포함되어 있다고 워렌이 말했다. 지난 달, 이 시스템은 52만 9,000개의 API 요청을 처리했다.

워렌은 AWS가 API에 관해 많은 정보를 제공하지 않는다는 사실을 발견했다. 워렌은 “AWS 자체는 그 정보를 제공하지 않는다. 우리는 일부 구형 방식을 시도해 보았는데, 아무것도 없는 경우 약간의 보호를 제공하기는 하지만 웹 애플리케이션 방화벽이 작동하지 않았다”라고 말했다.

워렌은 배치가 쉽고 개발팀에 방해가 되지 않는 기술을 찾았다. 그는 “그 관계가 엉망이 되면 문제가 된다. 보안 직원이 ‘안돼’ 라고 이야기하면 그들은 우회하기 시작한다. 그래서 솔루션이 워크플로우에 적합하고 추가적인 업무를 발생시켜야 한다”라고 토로했다. 

프롤로지스는 솔트 시큐리티를 선택했다. 원래는 2021년에 롤아웃을 계획했지만, 2020년에 하기로 결정했다. 워렌은 “API 공격 표면이 더 큰 관심을 끌고 있다. 악당들은 공격 표면이 많다는 것을 알아차렸다”라고 말했다.

에센셜스 시스템을 위해 솔트 시큐리티를 배치하기까지 약 1개월이 소요되었다. 프롤로지스는 많은 테스트를 진행했고 개발자에게 문제가 없으며 성능이 영향이 없도록 많은 노력을 기울였다.

이 도구는 AWS 환경에 있으며 API 게이트웨이에서 트래픽을 감시하고 로그와 메타데이터를 확보하며 알림 및 보고를 위해 보고서를 솔트의 SaaS 대시보드로 보낸다. 

워렌은 “처음에는 100개의 API 엔드포인트가 있다고 추정했다. 결국 500개가 있었다. 일반적으로 나는 네트워크에 관해 꽤 잘 파악하고 있는 편이지만, 나의 예상은 크게 빗나갔다. 이 문제는 이 업계에서 보편적이며, 사람들은 보유하고 있는 것을 과소평가하는 경우가 많다”라고 설명했다.

지난해 가을, 시스템이 가동을 시작했다. 결국, WAF에 연결하고 동작을 자동으로 실행하게 되었다. 현재, 보안 직원들이 수동으로 확인할 수 있는 보고서를 전송한다. 워렌은 “마지막으로 내가 하고 싶은 것은 정상적인 트래픽을 차단하는 것이다”라고 피력했다.

또한 이 시스템은 잠재적인 API 유출을 감시한다. 예를 들어, AWS 프라이빗 키가 유출되었을 수 있다는 알림을 받았지만 긍정 오류로 밝혀졌다. 워렌은 “AWS 키처럼 보이는 계좌 번호가 있었는데, 그것은 우연이었다”라고 말했다.

또한 이 시스템은 API가 엄격하게 필요한 것보다 많은 정보를 제공하는 사례도 일부 발견했다. 워렌은 “그렇게 민감하지는 않지만 이메일 주소와 계좌 번호의 조합이 있었다. 하지만 나는 '절대적으로 필요하지 않으면 하지 말라'는 주의다”라고 설명했다. 많은 기업이 API에 대해 이 조언을 따라야 한다. editor@itworld.co.kr 


X