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

UX가 애플리케이션의 얼굴이라면, APLS는 조직의 중추입니다. 많은 기업이 저지르는 일반적인 실수는 API를 단순히 애플리케이션 위의 인터페이스 계층으로 생각하는 것입니다. 현실적으로 APls는 하이브리드 및 멀티 클라우드 아키텍처에서 점점 더 분산되고 있는 애플리케이션과 타사 생태계를 연결하는 조직 역할을 합니다. APl도 웹 애플리케이션과 동일한 위험(취약성 악용, 비즈니스 로직 남용, 구성 오류 등)에 노출되지만, 그 외에도 다른 심각한 위험도 있습니다. 여기에는 취약한 인증 및 권한 부여 제어를 우회하는 공격, 부적절한 인벤토리, 타사 AP의 안전하지 않은 사용 등이 포함됩니다. 복잡한 소프트웨어 공급망과 자동화된 Cl/CD 파이프라인을 통해 사용되는 디지털 비즈니스의 속도로 인해 위험이 더욱 커질 수 있으며, 이로 인해 알려지지 않고 모니터링되지 않으며 안전하지 않은 API가 생성될 수 있습니다. 구체적으로 여기에는 보안 팀에 알려지지 않았거나 개발 팀에서 유지 관리하지 않는 섀도우 및 좀비 APl이 포함됩니다. 이 글에서는 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를 사용하여 AP를 악용하거나 남용하려는 악의적인 사용자, 비정상적인 행동, 새로운 위협에 적응합니다.

업계에 따라 규정 준수 기준이 다르며, 일부 업계는 다른 업계보다 더 엄격한 보안을 요구합니다. 그럼에도 불구하고, 귀하의 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는 지원하는 애플리케이션과 동일한 유형의 주입 공격, 즉 의도치 않은 명령을 실행하거나 데이터에 액세스하려는 공격을 받을 수 있습니다. 그러나 WAF는 일반적으로 알려지지 않은(섀도 또는 좀비) API와 API의 동작 이상, 비즈니스 로직의 잠재적 악용을 포함한 문제를 지속적으로 감지하는 데 필요한 동적 검색 기능이 부족합니다.

민감한 데이터 탐지 및 데이터 손실 방지 기능은 개인 식별 정보(PII) 및 금융 정보를 비롯한 민감한 중요 데이터를 탐지하고 마스킹하여 API와 API가 액세스하고 전송하는 데이터를 보호하는 데 도움이 됩니다. 이를 통해 조직에서는 데이터 보호 규칙을 만들어 데이터 전송을 제한하거나 가리고 API 엔드포인트가 데이터를 전혀 노출하지 못하도록 차단할 수 있습니다. 즉, API를 통한 데이터 유출을 방지하는 데 도움이 됩니다.

API에 대한 봇 관리에서는 다중 인증(MFA)이나 CAPTCHA와 같은 일반적으로 사용되는 보안 제어 기능에 의존할 수 없습니다. API 트래픽은 일반적으로 머신 대 머신이며 API 기반 시스템의 사용자 인터페이스를 제외하고는 직접적인 인간 상호 작용이 없기 때문입니다. 

기존 DDoS 완화책은 네트워크 및 볼륨별 공격에 초점을 맞추는 반면, API는 중요한 비즈니스 로직을 악용하는 타겟팅된 7계층 공격을 받을 수 있습니다. 최종 결과는 동일합니다. 성능이 저하되고 잠재적으로 가동 중지 시간이 발생합니다.

동적 API 검색, 스키마 적용(긍정적 보안), 액세스 제어, 그리고 머신 러닝을 기반으로 한 자동화된 이상 탐지 및 보호가 API를 방어하는 데 중요한 생태계 역량으로 부상했습니다. API 프로토콜에 능통하고 적절한 API 동작과 API 보호 규칙 생성을 시행할 수 있는 도구 하나 이상을 갖는 것이 중요합니다. 조직에서는 API와 API 동작을 구체적으로 제어하는 사용자 지정 규칙을 만들 수 있어야 합니다. 여기에는 허용 및 거부 목록 제어, 속도 제한, 지리적 IP 필터링, API 요청에 따라 민감한 데이터를 마스킹하고 특정 API 엔드포인트나 그룹에 대한 일치 및 요청 제약 조건을 처리하는 사용자 정의 규칙 생성이 포함됩니다.

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

API의 확산으로 인해 하이브리드 및 멀티 클라우드 환경에서 구조적 확산이 견딜 수 없을 정도로 심화되고 있습니다. 다시 말해, API 확산은 API 게이트웨이 확산으로 이어졌습니다. 많은 보안 도구가 데이터 센터, 프라이빗/퍼블릭 클라우드, 엣지 등 여러 아키텍처에서 일관된 보안을 제공할 수 없기 때문입니다. 디지털 생태계 전반의 API 트래픽에 대한 가시성과 제어는 다음의 심각한 취약성을 완화하고 엔드포인트가 여러 클라우드 공급자에 분산되어 있을 때 발생할 수 있는 잘못된 구성을 방지하는 데 필수적입니다.

어디에 있든 보안 API

API는 데이터 센터, 클라우드, 에지 등 모든 곳에 존재하며 웹 앱, 모바일 앱 및 관련 타사 통합을 통해 상호 연결됩니다. API는 어디에 있든 보호되어야 하며 보안은 결코 저하되지 않아야 합니다. 대신, API 뒤에 있는 중요한 비즈니스 로직을 지속적으로 방어하고 API에 연결된 디지털 패브릭을 일관되게 보호하는 솔루션이 전략에 포함되어 있는지 확인하세요. 이렇게 하면 운영을 간소화하고 자신 있게 혁신할 수 있습니다.

자원

추천

항공 교통 관제사의 간단한 그래픽 일러스트레이션

이 기사에서 다룬 주제에 대해 더 자세히 설명하는 새로운 Forrester 보고서를 확인해 보세요.