블로그 | NGINX

API 보안을 위한 필수 도구와 모범 사례를 통해 API 공격 방지

NGINX-F5-수평-검정-유형-RGB의 일부
앤드류 스티펠 썸네일
앤드류 스티펠
2023년 7월 18일 게시

최근 몇 년 동안 API의 확산으로 인해 기업의 운영 방식이 크게 바뀌었습니다. API를 사용하면 서로 다른 애플리케이션이 서로 통신하고 데이터를 교환할 수 있으며, 이를 통해 보다 효율적이고 효과적인 비즈니스 프로세스와 소프트웨어 개발이 가능합니다.

그러나 API 사용 증가에 따라 API 확산 이라는 위험이 발생합니다. API가 여러 분산된 팀과 아키텍처에 생성되고 배포되는 경우 적절한 감독 및 관리가 이루어지지 않는 경우가 많습니다. 각 API는 공격자가 중요한 데이터와 시스템에 무단으로 액세스할 수 있는 잠재적인 진입점이기 때문에, 이는 기업에 새로운 보안 위험을 초래할 수 있습니다.

API 우선 소프트웨어 개발의 부상

API 확산의 주요 원인 중 하나는 마이크로서비스의 확산입니다. 마이크로서비스 아키텍처는 더 큰 애플리케이션을 API를 통해 서로 통신하는 더 작고 개별적인 애플리케이션으로 나눕니다. 이는 복잡한 애플리케이션을 개별 팀이 관리하고 트래픽 수요를 충족하기 위해 서로 독립적으로 확장할 수 있는 개별적인 부분으로 나눕니다.

마이크로서비스는 개발자에게 많은 이점을 제공하는데, 그중에는 유연성과 확장성이 향상되는 것도 포함됩니다. 그러나 이러한 이점에는 추가적인 복잡성을 포함한 단점이 있습니다. 결과적으로 많은 기업이 마이크로서비스를 구축하는 데 API 우선 접근 방식을 채택합니다. 이 전략에서 애플리케이션과 서비스를 설계하는 과정은 API 계약부터 시작합니다. API 계약은 API의 작동 방식을 설명하며, 요청 및 응답 형식까지 포괄합니다.

API 라이프사이클 전반에 걸쳐 보안 통합

API가 급증함에 따라 공격 표면이 커짐

API 우선 소프트웨어 개발의 이점은 API 보안을 심각하게 받아들이지 않으면 쉽게 훼손될 수 있습니다. 특히 설계 및 배포 단계에서 보안이 취약해질 수 있습니다. 가장 기본적인 수준에서, API가 많아질수록 공격 표면도 늘어납니다. API는 현대 소프트웨어 개발에 중요한 역할을 하지만, 동시에 악용이 쉬워지고 있습니다.

2018년에 가트너는 API가 2022년까지 애플리케이션에 대한 가장 흔한 공격 벡터가 될 것이라고 예측했습니다 . 사실, 그들이 그렇게 많은 지연을 예측한 것은 지나치게 낙관적이었습니다. 수백만 명의 사용자에게 영향을 미치는 주요 회사의 주요 API 침해는 이미 발생하고 있었으며 점점 더 흔해지고 있습니다.

이러한 공격의 폭과 종류는 보안 및 엔지니어링 분야의 리더들이 직면한 과제를 보여줍니다. 일부 공격은 인터넷에 잘못 노출된 API를 악용합니다. 코드 저장소에 잘못 노출된 API 키나 기타 인증 방법을 사용하는 사람들도 있습니다. 또는 공격자는 VPN을 악용하여 내부 환경에 접근하고 내부 API를 사용하여 데이터를 빼냅니다.

API 공격을 막으려면 올바른 전략과 도구가 필요합니다.

API 위협으로부터 보호하는 가장 일반적인 방법은 기존 웹 애플리케이션 보안 전략과 최신 API 보안 기술을 결합하는 것입니다. 오늘날 다양한 API 위협에 직면해서는 기존의 전략은 종종 부족합니다. 자동화된 API 검색 및 API 대조 테스트와 같은 최신 기술은 이러한 격차를 해소하려고 시도됩니다.

기업에서는 올바른 방향으로 보호 (배포된 앱과 API를 보호하기 위해 글로벌 제어 및 보안 정책을 구현)하고, 왼쪽으로 이동 (앱과 API를 프로덕션에 투입하기 전에 취약점을 제거하기 위해 코드에 보안을 구축)하는 것이 중요합니다. 어느 전략도 단독으로 포괄적인 API 보안을 제공할 수 없으므로 침해를 방지하는 핵심은 API 보안 관행의 세 가지 범주를 포괄하는 전체적인 접근 방식입니다.

  • API 보안 포스처 관리 – 노출된 데이터 유형과 요청 방법을 포함하여 API 컬렉션의 보안 상태에 대한 가시성을 제공합니다.
  • API 보안 테스트 – API 수명 주기의 주요 지점에서 API의 보안을 평가하여 잠재적 취약성을 식별합니다.
  • API 런타임 보호 – 운영 중 악성 요청이 API에 도달하는 것을 감지하고 방지합니다.

엔드 투 엔드 API 보안

올바른 전략과 올바른 도구를 결합함으로써 조직은 API를 공격으로부터 더 잘 보호하고 소프트웨어 시스템의 보안을 보장할 수 있습니다. 플랫폼 엔지니어링 리더가 API를 수명 주기 전반에 걸쳐 보호하기 위해 구현해야 하는 중요한 기능과 도구를 살펴보겠습니다.

API 보안 태세 관리란 무엇인가요?

API 보안 포스처 관리를 통해 API에서 노출되는 개수, 유형, 위치 및 데이터에 대한 가시성을 확보할 수 있습니다. 이 정보는 각 API와 관련된 위험을 이해하는 데 도움이 되므로 API를 보호하기 위한 적절한 조치를 취할 수 있습니다.

주요 기능:

  • 자동화된 API 검색 – 환경에 배포된 API에 대한 포괄적인 가시성을 위한 자동적이고 지속적인 API 검색
  • API 특성화 – 프로토콜 또는 아키텍처(REST, GraphQL, SOAP 등)에 따라 API를 식별하고 분류하고 민감한 데이터 흐름을 매핑하여 위험 노출을 파악합니다.
  • API 카탈로그화 – 소프트웨어 팀이 기존 API를 재사용하도록 장려하고 SecOps 팀이 보안 태세에 대한 완전한 뷰를 구축할 수 있도록 API의 전체 목록을 유지 관리합니다.

대표 기술 :

  • 웹 애플리케이션 및 API 보호(WAAP) – API 인프라에서 특권적인 글로벌 위치를 활용하여 환경에 들어오고 나가는 트래픽을 분석하고 API를 식별하며 위험 노출에 대한 뷰를 구축합니다.
  • 인라인 또는 에이전트 기반 검색 – API 트래픽을 미러링하고 분석하기 위해 기존 API 게이트웨이, 로드 밸런서 또는 Kubernetes Ingress 컨트롤러에 에이전트를 연결합니다.
  • 대역 외 또는 에이전트 없는 검색 – 트래픽 미러링 또는 내보낸 로그 및 메트릭을 사용하여 API 트래픽을 분석합니다. 일반적으로 다른 기술보다 API 및 위협에 대한 가시성이 낮습니다.
  • 도메인 크롤러 - API 보안 제공자는 보안 정책을 적용할 수 있는 API 게이트웨이 및 로드 밸런서를 우회하는 트래픽을 허용하는 노출된 API 엔드포인트에 대해 도메인을 조사하는 크롤러를 제공할 수 있습니다.

어떠한 기술도 아키텍처의 모든 API를 안정적으로 찾을 수는 없다는 점을 명심하는 것이 중요합니다. 대부분의 검색 기술은 기존 로드 밸런서, API 게이트웨이, Ingress 컨트롤러가 제공하는 가시성에 의존하며, 이러한 아키텍처 구성 요소를 우회하는 잘못된 구성을 포착할 가능성이 낮습니다.

궁극적으로, 코드 검토와 API 우선 모범 사례를 따르는 것이 더 효과적인 장기적 예방책이 됩니다. 그러나 자동화된 API 검색 도구는 여전히 보안 태세를 빠르게 구축하고 관리되지 않고 보안이 취약할 수 있는 API를 포착하는 데 유용합니다.

API 보안 테스트란 무엇인가요?

API 보안 포스처 관리가 기업 전체의 보안과 관련된 반면, API 보안 테스트는 개별 API에 대한 것입니다. 가장 기본적인 API 보안 테스트는 API 런타임(API 뒤에서 실행되는 애플리케이션)을 테스트하여 취약성과 관련 위험을 식별하고 방지하는 데 도움이 됩니다. 인증, 권한 부여, 속도 제한 및 암호화 조건을 포함하여 기본 보안 요구 사항이 충족되었는지 확인하는 데 도움이 됩니다.

주요 기능:

  • API 계약 테스트 – API의 OpenAPI 사양을 사용하여 클라이언트 요청과 서버 응답을 비교하여 API가 설계대로 수행되는지 확인합니다. API가 배포되기 전에 취약한지 여부를 발견하기 위해 "내부에서 외부로" 접근 방식을 사용합니다.
  • 동적 애플리케이션 보안 테스트(DAST) – API 런타임에 대한 공격을 시뮬레이션하여 취약점을 찾고 악의적인 사용자처럼 "외부에서 내부로" API를 평가합니다.

대표 기술 :

  • API 계약 테스트 소프트웨어 - 클라이언트와 서버 동작이 API 계약을 준수하는지 확인하기 위해 API 요청과 응답을 분할하는 테스트를 실행하기 위한 특수 도구
  • 애플리케이션 보안 테스트(AST) 소프트웨어 - 공격을 시뮬레이션하여 API를 포함한 애플리케이션을 분석하고 테스트하는 도구

전담 API 보안 공급업체가 제공하는 오픈소스 계약 테스트 도구와 상용 제품이 모두 있습니다. 애플리케이션 보안 테스트(AST) 시장은 수십 년 동안 존재해 왔으며, 점점 더 많은 공급업체가 API에 대한 전용 스캐닝 및 테스트 도구를 제공하고 있습니다.

API 런타임 보호란 무엇인가요?

API 런타임 보호는 API가 작동하고 요청을 관리할 때 API를 보호하는 것을 말합니다. API 자체의 코드뿐 아니라 플랫폼 인프라에도 보안을 구축하는 것을 우선시합니다. 목표는 배포 후 나타나는 악성 API 요청을 식별하고 방지하는 것입니다.
주요 기능:

  • 액세스 제어 – 인증(authN) 및 권한 부여(authZ) 정책 시행
  • 네트워크 보안 – 네트워크 전반의 통신을 암호화하고 보호합니다.
  • 애플리케이션 보호 – API 런타임을 악성 API 요청 및 공격으로부터 보호합니다.
  • 실시간 모니터링 – API 인프라 전반에서 공격을 시각화, 추적 및 완화

대표 기술 :

  • API 게이트웨이 - 인증, 권한 부여, 속도 제한, 액세스 제어 목록 및 암호화를 포함한 보안 정책을 적용하고 시행합니다.
  • 웹 애플리케이션 방화벽 (WAF) – 공격 시그니처를 기반으로 트래픽을 적극적으로 모니터링하고 필터링하여 정교한 레이어 7 공격으로부터 API 및 애플리케이션을 보호합니다.
  • ID 공급자 (IdP) – 사용자 ID를 저장하고 검증하는 서비스로 일반적으로 SSO(Single Sign On) 공급자와 협력하여 사용자를 인증합니다.

모든 API 게이트웨이와 WAF/WAAP가 동일하게 만들어진 것은 아닙니다. 일부 서비스, 특히 클라우드와 다른 플랫폼에서 제공되는 기본 솔루션의 경우 멀티 클라우드와 하이브리드 아키텍처에 필요한 글로벌 가시성과 표준화가 부족합니다.

API 보안 모범 사례

API 보안의 중요성을 감안할 때, 체계적인 방식으로 API 보안에 접근하는 것이 필수적입니다. 플랫폼 엔지니어링 및 보안 리더는 API 라이프사이클 전체에 걸쳐 보안 요구 사항을 해결하기 위해 협력해야 합니다. 앞서 살펴보았듯이 이는 대략 세 가지 주요 실무 영역과 일치합니다. API 보안 상태 관리, API 보안 테스트, API 런타임 보호. 즉, API가 몇 개인지, 오류를 테스트하는 방법, 코드에 보안을 구축하는 방법을 아는 데 중점을 두어야 합니다.

API 보안 모범 사례 목록

결론

모든 사이버 보안과 마찬가지로 API 보안은 네트워크 엔지니어, 보안 운영 리더, 플랫폼 엔지니어링 리더, 소프트웨어 개발 엔지니어를 포함한 많은 이해 관계자와의 협력이 필요한 지속적인 프로세스입니다. 좋은 소식은 API를 보호하는 방법이 큰 수수께끼가 아니라는 것입니다.

대부분의 조직에서는 이미 API를 표적으로 삼을 수 있는 크로스 사이트 스크립팅, 주입, 분산 서비스 거부 공격 등 잘 알려진 공격을 막기 위한 대책을 마련해 놓았습니다. 위에서 설명한 모범 사례 중 대부분은 노련한 보안 전문가에게는 매우 익숙할 것입니다. 귀하의 조직에서 아무리 많은 API를 운영하더라도 목표는 견고한 API 보안 정책을 수립하고 이를 시간이 지남에 따라 적극적으로 관리하는 것입니다.

F5 NGINX Management Suite API Connectivity Manager를 포함하여 API를 관리, 통제, 보호하는 NGINX API Connectivity Stack, API 게이트웨이로 사용되는 F5 NGINX Plus, 고급 API 보안을 위한 F5 NGINX App Protect WAF 및 DoS가 포함된 NGINX API Connectivity Stack의 30일 무료 평가판을 시작하세요.

추가 자료

F5 NGINX에 대한 더 많은 블로그 게시물 읽기 ›

"이 블로그 게시물에는 더 이상 사용할 수 없거나 더 이상 지원되지 않는 제품이 참조될 수 있습니다. 사용 가능한 F5 NGINX 제품과 솔루션에 대한 최신 정보를 보려면 NGINX 제품군을 살펴보세요. NGINX는 이제 F5의 일부가 되었습니다. 이전의 모든 NGINX.com 링크는 F5.com의 유사한 NGINX 콘텐츠로 리디렉션됩니다."