API의 확산으로 공격 표면 증가
API의 급속한 성장으로 인해 보안 위험이 발생했습니다
애플리케이션 프로그래밍 인터페이스(API)는 서로 다른 소프트웨어 간의 상호 작용을 정의하고 활성화하는 컴퓨팅 인터페이스입니다. 소셜 플랫폼에서 미디어 공유, 온라인 결제 처리, 웹 사이트 분석 데이터 집계 등 많은 일상적인 작업이 API 덕분에 발생합니다. 기업에서는 클라우드 컴퓨팅을 통해 API의 도움으로 글로벌 인프라를 보다 쉽게 배포할 수 있습니다.
오늘날 대부분의 소프트웨어는 API를 사용하거나 API이며 지난 4~5년 동안 API는 기하급수적으로 증가했습니다.예를 들어, API 개발을 위한 협업 플랫폼인 Postman에서는 API 폴더 수가 2016년 50만 개 미만에서 2021년에는 거의 3,500만 개로 급증했습니다.
API의 인기가 폭증했음에도 불구하고 관련 보안 조치는 지연되었습니다.이제 더 폭넓게 이용되면서 다양한 주요 취약점이 드러났습니다.Gartner에 따르면 폭발적인 성장과 미흡한 보안의 조합을 감안할 때 API는 사상 최대의 보안 취약점 이 될 것으로 예상됩니다.
API 우선 개발의 대두
API 성장의 주요 동인 중 하나는 2013년에 인기를 얻기 시작한 마이크로서비스의 확산이었습니다.마이크로서비스 스타일의 아키텍처는 API를 사용하여 서로 통신하는 작은 개별 애플리케이션을 개발합니다.이렇게 하면 복잡한 작업이 더 작은 부분으로 분할되고 각 부분이 독립적으로 개발되고 유지 관리됩니다.
글로벌 마이크로서비스 아키텍처 시장은 2018년에 2.07조 달러로 평가되었으며 2026년에는 8.07조 달러(2019~2026년 연평균 성장률 18.6%)에 이를 것으 로 예상됩니다. 마이크로서비스는 유연성, 더 빠른 개발 주기, 탁월한 확장성으로 인해 널리 채택되었습니다.
예를 들어, Netflix에서는 수요를 따라잡기 위해 중앙 집중식 모놀리식 데이터 센터에서 클라우드 기반 마이크로서비스 아키텍처로 전환했습니다. 그 결과 개발자는 특정 지역에 맞게 콘텐츠를 맞춤화하는 기능과 같은, 고객 경험을 지속적으로 개선할 수 있는 엄청난 자유를 만끽하게 되었습니다.
이처럼 API에 우선순위를 두는 추세가 이어지면서 취약점을 어디에서 찾을 수 있는지에 대한 힌트도 계속 나오고 있습니다. API는 어디에나 있으며 API는 계속 성장하고 있습니다. 따라서 위험도 증가합니다.
API - 새롭고 거대한 보안 취약점
API와 관련하여 개발 및 활동은 늘어나지만, 보안 애플리케이션 개발로 이어지지는 않습니다. Gartner에 따르면 웹 지원 애플리케이션의 90%는 사용자 인터페이스(UI)가 아닌 노출된 API에서 더 많은 공격 표면 영역을 갖게 됩니다. Gartner는 또한 2022년에 API 남용이 드물게 발생하는 공격 벡터에서 가장 빈번한 공격 벡터로 바뀔 것이라고 예측했습니다.
API 취약점은 엔드포인트(장치, 서버, 가상 환경 등), 데이터 노출, 서비스 거부(DoS), 권한 부여 결함, 보안 시스템 구성 오류 등의 광범위한 영역에서 찾아볼 수 있습니다. 특정 조직에서 발견되는 수천 개의 API 지원 자산과 관련된 대규모 공격면을 고려할 때, API 취약성은 기업에 아주 광범위한 영향을 미칠 수 있습니다.
예를 들어 데이터 파괴, 자금 도난, 생산성 손실, 지적 재산권 도용, 개인 및 금융 데이터 도난, 사기, 비즈니스 운영 중단, 손상된 데이터, 시스템 복원 및/또는 삭제 비용 등이 있습니다. API 위반과 관련된 평판 손상은 또한 심각한 보안 이벤트에서 흔히 발생하는 신뢰 저하로 이어질 수 있습니다.
기업에서 대체로 강력한 보안 조치를 취했음에도 불구하고 API 공격을 받은 여러 사례가 이미 헤드라인을 장식하면서 세간의 이목을 끌었습니다.Facebook의 예를 살펴보면, 사이트의 "다른 이름으로 보기" 기능의 약점이 공격을 받으면서 5천만 개의 계정이 노출되었습니다 .이를 이용하여 Facebook이 API 지원 동영상 업로드 기능을 만든 후 해커가 계정 액세스 토큰을 훔칠 수 있었습니다.
Uber 또한 API 요청에 포함된 사용자의 범용 고유 식별자(UUID)로 인해 API 응답에서 토큰이 유출되어 계정 하이재킹에 악용될 수 있는 위험에 노출되기도 했습니다. 이로 인해 공격자들은 피해자의 위치를 추적하고 승차 기회를 도용할 수도 있었습니다.
페이스북과 우버의 사례에서는 '손상된 사용자 인증' API 공격이라고 알려진 경우를 볼 수 있습 니다. 인증이 잘못 실행되면 인증 토큰 및 기타 취약점이 손상되어 사용자 ID가 도용될 수 있습니다.
코로나19와 관련된 재택 근무 증가로 인해 가정용 IP 주소가 많이 사용됨에 따라 합법적인 API 호출과 악의적 API 호출을 분리 하는 것이 더욱 중요해졌습니다.자격 증명 스터핑 또는 스팸 봇넷 공격에는 해킹된 서버, 워크스테이션, 심지어 IoT 장치까지로 구성된 최대 10,000개의 각기 다른 IP가 사용될 수 있습니다.
API 공격을 차단하려면 올바른 전략 + 올바른 네트워크가 필요합니다
API는 애플리케이션 로직, 개인 식별 정보(PII) 등 중요한 데이터를 노출하므로 조직의 인프라 및 보안 전략에 매우 중요합니다. 그러나 대부분 "네거티브 보안" 모델에 의존하는 기존의 웹 애플리케이션 보안 전략으로는 대부분의 API 위협을 차단하지 못할 수 있습니다.
포지티브 보안을 통한 API 방어
"네거티브 보안" 모델에서는 알려진 위협 또는 의심되는 위협의 차단 목록에 없는 한 모든 요청이 웹 애플리케이션 방화벽(WAF)을 통과할 수 있습니다. 이 모델로는 긍정 오류가 생성되어 합법적인 API 호출이 차 단될 수 있으며, 보다 표적화된 공격 중 일부가 포착되지 못할 수도 있습니다. 그러나 WAF는 API 보안에서 중요한 역할을 합니다. 예를 들어, 스키마 유효성 검사의 몇 단계를 통과하는 인증된 트래픽(예: 엔드포인트, 메서드, 매개 변수)은 여전히 WAF가 포착할 수 있는 SQL 공격을 수행할 수 있습니다. 또한 일부 API는 TLS에 적합하지 않거나 스키마 유효성 검사 문제를 초래합니다. 스키마가 최신 상태가 아니거나 API가 분편화되어 단일 스키마로 통합하기 어려운 경우 WAF가 격차를 메우는 데 도움이 됩니다.
즉, API 보안을 위해 차단 목록 중심의 WAF에만 의존하면 조직이 취약해집니다.API 위협 완화로 API Shield와 같은 "포지티브 보안" 모델을 통해 이러한 위험을 피할 수 있으며, 이 모델을 적용하면 알려진 동작만 허용되고 다른 것은 모두 식별되고 거부됩니다.
포지티브 모델을 향한 한 가지 핵심 단계는 비밀번호의 재사용 또는 공유에 취약하지 않은 강력한 인증 및 권한 부여를 배포하는 것입니다(예: TLS 또는 OAuth). 권한 및 인증서 공유를 관리하는 데 시간이 많이 걸릴 수 있으므로 개발자는 허용 목록 프로세스를 최대한 간소화하는 도구의 우선순위를 지정해야 합니다.
물론 장치에서 인증서를 추출하여 다른 곳에서 재사용하는 것이 불가능하지는 않습니다. 개발자에게는 API 호출의 유효성을 직접 검사하는 방법도 필요합니다. 스키마 유효성 검사로는 API 요청의 내용(POST 본문의 URL 및 내용 뒤에 오는 쿼리 매개 변수)을 예상되는 내용에 대한 규칙이 포함된 계약 또는 "스키마"와 매칭하여 이를 수행할 수 있습니다. 유효성 검사에 실패하면 API 호출이 차단되어 잘못된 요청 또는 악의적인 페이로드로부터 원본을 보호합니다.
API 공격 차단 - 네트워크는 개별 도구를 강화합니다
인증/권한 부여 및 API 호출 유효성 검사를 통한 포지티브 보안도 중요하지만, 추가적인 보안 조치도 필요합니다. 예를 들어 API는 볼류메트릭 공격, 무차별 암호 대입 공격, 자격 증명 스터핑에 여전히 취약합니다. 따라서 DDoS 완화 및 레이트 리미팅은 기업의 전반적인 보안 상태에서 여전히 필요한 도구로 입니다.
DDoS 완화 및 레이트 리미팅과 같은 기존 보안 도구에 새로운 보안 도구를 추가하면 문제가 발생할 수 있습니다. API 호출이 서로 다른 많은 도구를 통과하면 모니터링하고 기록하기가 더 번거로워집니다. 또한 지리적으로 분산된 데이터 센터의 다양한 도구를 통해 트래픽을 유입하면 대기 시간이 추가되고 앱 성능이 저하될 수 있습니다.
이러한 이유로 API 보안은 더 큰 에지 네트워크에 통합된 여러 보안 기능을 통해 가장 잘 제공되며, 다음과 같은 이점이 제공됩니다.
복원력: 여러 에지 네트워크 위치에서 API 보안 도구를 호스팅할 수 있는 경우, 중단이 격리되어 위험이 줄어듭니다.
대기 시간 감소: 여러 API 보안 도구가 동일한 에지 네트워크 위치 내에서 작동하는 경우 트래픽이 서로 다른 위치 간에 반송될 필요가 없습니다.
위협 인텔리전스: 에지 네트워크에 충분한 도달 범위가 있는 경우 많은 수의 API에 대한 공격을 분석하고 이 인텔리전스를 사용하여 나머지를 더 잘 보호할 수 있습니다.
더 쉬운 로깅: 단일 창을 통해 운영되는 단일 네트워크를 사용하면 개발자에게 단일 정보 소스가 제공됩니다.
최신 기업 아키텍처를 위해 구축된 Cloudflare는 강력한 클라이언트 인증서 기반 ID 및 엄격한 스키마 기반 유효성 검사를 이용하여 API를 간단하게 보호 할 수 있도록 합니다.이는 기존 인프라를 변경하지 않고 악의적인 공격으로부터 비즈니스에 중요한 웹 애플리케이션을 보호하는 지능적이고 확장 가능한 솔루션입니다.
이 글은 오늘날의 기술 의사 결정자에 영향을 주는 최신 동향 및 주제에 대한 시리즈 중 일부입니다.
핵심 사항
이 글을 읽고 나면 다음을 이해할 수 있습니다.
API 사용 증가율
API를 사용하면 공격 표면 영역이 확장되는 방법
이 위험을 막기 위한 전략
통합 플랫폼의 이점
관련 자료
이 주제에 관해 자세히 알아보세요.
API 취약점으로부터 보호하는 방법에 대한 자세한 내용은 Gartner Magic Quadrant 웹 애플리케이션 및 API 보호(WAAP) 부문 보고서를 참조하세요.