총체적인 API 보안 전략의 6가지 원칙

요약

UX가 애플리케이션의 얼굴이라면, API는 조직의 중추입니다. 많은 기업이 흔히 저지르는 실수는 API를 단순히 애플리케이션 위에 놓인 인터페이스 계층으로만 여기는 것입니다. 하지만 실제로 API는 애플리케이션과 서드 파티 생태계를 연결하는 조직과도 같으며, 이러한 환경은 점점 더 하이브리드 및 멀티 클라우드 아키텍처 전반에 분산되고 있습니다. API는 웹 애플리케이션과 마찬가지로 취약점 악용, 비즈니스 로직 오용, 잘못된 구성 등의 위험에 노출되지만, 그 밖에도 중대한 위험이 존재합니다. 여기에는 취약한 인증 및 권한 부여 제어를 우회하는 공격, 부적절한 인벤토리 관리, 서드 파티 API의 안전하지 않은 사용 등이 포함됩니다. 복잡한 소프트웨어 공급망과 자동화된 CI/CD 파이프라인을 통해 디지털 비즈니스가 빠르게 전개되면서 위험은 더욱 커집니다. 이로 인해 파악되지 않고 모니터링되지 않으며 보안이 확보되지 않은 API가 생길 수 있습니다. 특히 보안 팀이 존재를 알지 못하거나 개발 팀이 유지 관리하지 않는 섀도 API와 좀비 API가 이에 해당합니다. 이 글에서는 API 보안을 총체적이고 균형 있게 구현하기 위한 6가지 원칙을 살펴보겠습니다.

1. API와 엔드포인트 이해하기

지금 당장 환경 내의 모든 API 엔드포인트를 파악하려 해도 모두 찾아내지 못할 가능성이 매우 높습니다. 안타깝게도 악의적인 공격자도 그러리라고 장담할 수는 없습니다. 엔드포인트가 존재한다면 시스템 침투 경로나 핵심 비즈니스 기능을 방해하는 수단으로 악용될 수 있습니다.

또한 API를 공개하면 수많은 고객, 파트너 및 앱으로부터 요청을 받게 됩니다. 이러한 공개는 조직을 침해 위험에도 노출하므로 API를 정확히 파악하고 모니터링하는 것이 매우 중요합니다. 침해 사고와 서비스 중단으로 이어질 수 있는 API의 취약점과 잠재적 위협으로부터 조직을 보호하려면 다양한 위험 통제 방안을 고려해야 합니다.

모든 보안 담당자에게 API 검색은 API 보안을 위한 가장 중요한 첫 단계입니다. 당연한 말일 수 있지만, “보이지 않는 것은 보호할 수 없다”는 말만큼 정확한 표현도 없습니다. 완전한 API 인벤토리는 API 보안 태세를 수립하거나 개선하기 위한 출발점으로서, 전체 API 공격 표면을 파악하고 정량화하는 데 도움이 됩니다. 이는 다음을 위한 기준선이 됩니다:

  • 가시성: 사용 가능한 모든 API를 목록화하면 취약점, 민감한 데이터 노출, 승인되지 않았거나 잊힌 엔드포인트 등 API 위협 환경을 더욱 명확하게 파악할 수 있습니다.
  • 버전 관리: 인벤토리를 구축하면 버전 관리에 도움이 됩니다. API의 변경 이력과 다양한 버전을 파악하면 오래되었거나 취약한 버전을 폐기하거나 적절하게 보호할 수 있습니다.
  • 모니터링: 중앙 집중식의 완전한 API 인벤토리를 구축하면 API 사용 현황을 더욱 효과적으로 모니터링하고 기록할 수 있어 의심스러운 활동(이상 징후)과 잠재적인 보안 이벤트를 더 쉽게 탐지하고 대응할 수 있습니다. 또한 사고 발생 시 명확한 인벤토리가 대응에 도움이 될 수 있습니다.
  • 일관된 보안 제어 및 정책: 전체 API 인벤토리를 포함한 이러한 가시성을 확보하면 전체 API 위협 표면에 제어 및 정책을 효과적으로 적용할 수 있습니다.

2. 혁신과 보안 간의 균형 찾기

이는 늘 반복되는 고전적인 딜레마입니다. 한편으로는 과감하게 한계를 뛰어넘고 경쟁사가 할 수 없는 일을 해내려는 의지가 모든 성공적인 비즈니스의 초석입니다. 하지만 다른 한편으로는 보안을 유지하는 것이 최신 혁신과 항상 잘 맞는 것은 아닙니다.

균형을 맞추기 위한 핵심은 세 가지입니다:

  • 각 API 유형에 적합한 보안 통제를 설정할 수 있도록 API 거버넌스 전략을 수립하세요.
  • API가 배포되는 모든 환경에서 일관되게 적용할 수 있는 API 보안 정책을 구현합니다.
  • AI를 활용해 API를 악용하거나 남용하려는 새로운 위협, 비정상적인 행동 및 악의적인 사용자에 대응하여 보안 팀의 부담을 줄입니다.

업종에 따라 준수해야 할 규정은 달라지며, 일부 업종에는 다른 업종보다 더 엄격한 보안이 요구됩니다. 어떤 경우든 수많은 위협 벡터에 대응할 수 있을 만큼 강력한 API 보안 태세를 갖추는 것이 중요합니다.

“외부 클라이언트부터 내부 백엔드 인프라에 이르기까지 아키텍처의 모든 부분에는 각각의 보호 조치가 마련되어야 합니다.”

3. 개발 수명 주기 전반에 걸쳐 위험 관리

API 보안 테스트는 한 번으로 끝나는 작업이 아닙니다. 배포 전과 배포 중, 배포 후에 모두 테스트하는 것이 중요합니다. 개발의 모든 단계에 테스트를 포함하면 보안 침해가 발생하기 전에 약점과 취약점을 발견할 기회가 훨씬 많아집니다. 보안 전용 테스트 도구도 유용하지만, 보안 사용 사례 모델링도 잊지 마세요.

보안은 애플리케이션 자체와 동일한 지속적 수명 주기에서 운영되어야 합니다. 즉, CI/CD 파이프라인, 서비스 프로비저닝 및 이벤트 모니터링 에코시스템과 긴밀하게 통합되어야 합니다.

4. 백엔드부터 최종 고객까지 계층별 보호 적용

외부 클라이언트부터 내부 백엔드 인프라에 이르기까지 아키텍처의 모든 부분에는 각각의 보호 조치가 마련되어야 합니다.

또한 기본 거부 아키텍처, 강력한 암호화, 최소 권한 액세스와 같이 오랜 기간 검증된 보안 관행은 여전히 유효합니다.

API 계층에서의 보호를 고려할 때는 먼저 API를 내부용과 외부용이라는 두 가지 범주로 구분하는 것이 좋습니다. 내부 API는 API 제공업체가 앱 팀과 보안 조치를 조율할 수 있으므로 비교적 쉽게 보호할 수 있습니다. 반면 외부 API는 위험을 평가하는 방식이 다릅니다. 다음 세 가지 역할을 하는 API 수준의 보호 조치를 구현할 수 있으며, 반드시 구현해야 합니다:

  • 실시간 위협 인텔리전스와 보안이 강화된 세션 토큰 등의 액세스 제어 메커니즘을 활용하여 보안 침해 가능성을 줄입니다.
  • 정상 및 비정상 트래픽 패턴의 기준선을 설정합니다.
  • API 사용을 제한하고 승인된 애그리게이터 및 타사 통합을 세부적으로 제어합니다.

프로덕션 환경에서는 API의 무분별한 확산으로 발생하는 방대한 트래픽 때문에 비정상적인 동작과 악의적인 사용자를 탐지하는 데 AI를 활용해야 합니다.

5. 적절한 전략과 도구를 갖추세요

한 가지 음식만으로 필요한 영양소를 모두 섭취할 수 없듯이, 단일 보안 제어만으로 API를 완벽하게 보호할 수는 없습니다. 대신 앱 및 API 보안 아키텍처를 전체적인 관점에서 설계하고, 균형 잡힌 도구 생태계를 활용하는 전략을 수립해야 합니다. 여기에는 API 동작을 제어하고, 원치 않거나 악의적인 활동을 제한하며, 민감한 데이터의 노출을 차단할 수 있도록 탐지 및 인라인 적용 기능이 포함되어야 합니다.

여기에는 다음과 같은 기능과 도구의 조합이 포함될 수 있습니다:

  • API 게이트웨이
  • 애플리케이션 보안 테스트(SAST 및 DAST)
  • 웹 애플리케이션 방화벽(WAF)
  • 데이터 손실 방지(DLP)
  • 봇 관리
  • DDoS 완화

API 게이트웨이는 강력한 인벤토리 및 관리 기능을 제공하지만, 정교한 공격자를 막기에는 역부족인 속도 제한과 같은 기본적인 보안 기능만 제공합니다. 또한 API가 급증하면서 API 게이트웨이를 비롯한 도구가 난립하고 있습니다.

애플리케이션 보안 테스트는 항상 중요하지만, 개발 단계에서 강력한 애플리케이션 보안을 구현하기 위한 시프트 레프트 방법론은 프로덕션 환경의 API 엔드포인트를 보호하는 실드 라이트 방식으로 보완해야 합니다.

웹 애플리케이션 방화벽은 시그니처를 기반으로 애플리케이션 취약점 악용을 완화하는 데 중요한 임시 방어 수단을 제공합니다. API도 API가 지원하는 애플리케이션과 마찬가지로 의도하지 않은 명령을 실행하거나 데이터에 액세스하려는 인젝션 공격에 취약합니다. 하지만 WAF에는 일반적으로 알려지지 않은 API(섀도 API 또는 좀비 API)를 지속적으로 탐지하고, API의 비정상적인 동작과 비즈니스 로직의 잠재적 악용을 비롯한 문제를 찾아내는 데 필요한 동적 검색 기능이 부족합니다.

민감한 데이터 탐지 및 데이터 손실 방지 기능은 개인 식별 정보(PII)와 금융 정보를 비롯한 민감한 핵심 데이터를 탐지하고 마스킹하여 API와 API가 액세스하고 전송하는 데이터를 보호하는 데 도움이 됩니다. 이를 통해 조직은 데이터 전송을 제한하거나 마스킹하고 API 엔드포인트의 데이터 노출을 완전히 차단하는 데이터 보호 규칙을 생성하여 API를 통한 데이터 유출을 방지할 수 있습니다.

봇 관리 API의 경우 트래픽이 일반적으로 시스템 간에 전송되고 API 기반 시스템의 사용자 인터페이스를 제외하면 사람이 직접 개입하지 않으므로, 다단계 인증(MFA) 및 CAPTCHA와 같이 일반적으로 사용되는 보안 제어에 의존할 수 없습니다.

기존의 DDoS 완화는 네트워크 및 대규모 트래픽 공격에 중점을 두는 반면, API는 핵심 비즈니스 로직을 악용하는 표적형 레이어 7 공격의 대상이 될 수 있습니다. 결과는 동일합니다. 성능이 저하되고 잠재적으로 서비스가 중단될 수 있습니다.

동적 API 검색, 스키마 적용(포지티브 보안), 액세스 제어, 그리고 머신 러닝 기반의 자동화된 이상 탐지 및 보호 기능은 API 방어를 위한 핵심 생태계 역량으로 부상했습니다. API 프로토콜을 잘 이해하고 올바른 API 동작을 적용하며 API 보호 규칙을 생성할 수 있는 하나 이상의 도구를 갖추는 것이 중요합니다. 조직은 API와 API 동작을 구체적으로 제어하는 사용자 지정 규칙을 만들 수 있어야 합니다. 여기에는 허용 및 차단 목록 제어, 속도 제한, Geo-IP 필터링뿐만 아니라 민감한 데이터 마스킹, 특정 API 엔드포인트 또는 그룹에 대한 일치 조건 및 요청 제약 조건 등 API 요청에 대응하기 위한 사용자 지정 규칙 생성이 포함됩니다.

6. 하이브리드 및 멀티 클라우드 보안

API의 급증으로 인해 하이브리드 및 멀티 클라우드 환경 전반에서 감당하기 어려운 아키텍처 확산이 발생하고 있습니다. 또한 많은 보안 도구가 데이터 센터, 프라이빗/퍼블릭 클라우드, 엣지 등 여러 아키텍처에 걸쳐 일관된 보안을 제공하지 못하면서 API의 확산은 API 게이트웨이의 난립으로 이어졌습니다. 디지털 생태계 전체의 API 트래픽에 대한 가시성과 제어 능력을 확보하는 것은 차세대 주요 취약점을 완화하고, 엔드포인트가 서로 다른 클라우드 제공업체에 분산될 때 발생할 수 있는 구성 오류를 방지하는 데 필수적입니다.

어디에 있든 API를 안전하게 보호

API는 데이터 센터, 여러 클라우드, 엣지 등 어디에나 존재하며 웹 앱, 모바일 앱 및 관련 서드 파티 통합 환경의 이면에서 서로 연결되어 있습니다. API가 어디에 있든 보호해야 하며, 보안에는 한순간의 빈틈도 없어야 합니다. 따라서 API 이면의 핵심 비즈니스 로직을 지속적으로 방어하고 API로 연결된 디지털 패브릭을 일관되게 보호하는 솔루션을 전략에 포함하세요. 이를 통해 운영을 간소화하고 안심하고 혁신할 수 있습니다.

리소스

추천
API 보안 구성 요소

API 보안의 8가지 구성 요소

이 글에서 다룬 주제를 더 심층적으로 분석한 Forrester의 최신 보고서를 확인해 보세요.

보고서 받기