API 보안이란 무엇일까요?

API는 애플리케이션 프로그래밍 인터페이스의 약어입니다. 소셜 미디어에서 사용자 ID에 연결된 암호와 같은 기본 정보를 보호하는 것과 마찬가지로 API 키 및 API 콜과 같은 식별자가 오용되지 않도록 백엔드에서 API 접속을 보호하는 것도 중요합니다.

사용 가능한 웹 애플리케이션 또는 웹 서비스는 어떤 방식으로든 API를 통해 지원되기 때문에 API가 보안 리스크 증가를 의미하는 것은 놀랍지 않습니다. 모바일 애플리케이션 및 사물 인터넷(IoT) 디바이스부터 내부 애플리케이션, 클라우드 기반 고객 서비스, 마이크로서비스 아키텍처에 이르기까지, API는 비즈니스 통신과 트랜잭션을 가능하게 합니다.

따라서 웹 API 보안 및 API 관리는 API 수명 주기 전반에 걸쳐 IT 팀에 중요한 우선순위가 되어야 합니다. 하지만 클라우드 전환, 최신 DevOps 사례, 지속적으로 진화하는 API 등으로 보안 위협으로부터 API를 보호하는 것은 복잡한 문제가 될 수 있습니다.

API 보안은 기업이 비즈니스 프로세스를 지원하는 데 사용하는 API를 보호하기 위한 체계적인 접근 방식입니다. 여기에는 다음이 포함될 수 있습니다.

• 고객이나 비즈니스 파트너가 기능 및 데이터에 쉽게 접속할 수 있도록 구축된 API
• 비즈니스 파트너가 사용하는 API
• 애플리케이션 기능과 데이터를 다양한 시스템과 사용자 인터페이스에서 표준화되고 확장 가능한 방식으로 사용할 수 있도록 내부적으로 구축하고 사용하는 API

효과적인 API 보안 전략에는 다음과 같은 체계적인 기술이 포함되어야 합니다.

• 리스크 및 잠재적 영향 평가
• 적절한 방어 조치 실행

리스크 평가의 첫 번째 단계는 기업에서 게시하고 사용하는 모든 승인 및 비승인 API의 인벤토리를 구축하는 것입니다. 이 인벤토리에는 다음과 같은 속성이 포함되어야 합니다.

• 데이터를 최소한 ‘민감하지 않음’, ‘민감함’, ‘매우 민감함’으로 분류
• API 취약점 및 잘못된 설정과 같은 리스크 지표

이러한 속성은 영향을 측정하고 방어 활동의 우선순위를 정하기 위한 필수 구성요소입니다.

API 가시성 및 리스크 방어 조치는 다음과 같은 다양한 잠재적 위협을 고려해야 합니다.

• 승인되지 않은 ‘섀도 API’ 사용을 탐지 및 방지
• 악성 공격자가 잠재적으로 악용할 수 있는 API 취약점 및 잘못된 설정의 식별 및 수정
• 비즈니스 로직 악용과 데이터 스크레이핑 같은 API 오용 사례 방지

이러한 API 보안 리스크를 식별하고 방어하려면 복잡하고 빠르게 진화하는 위협 환경에 대응할 수 있을 만큼 정교한 보안 제어 기능이 필요합니다. 그러나 이에 못지않게 API 보안 관행을 소프트웨어 개발 및 문서화 등 API 보안 체계에 영향을 미치는 비보안 워크플로우로 확장하는 방법을 찾는 것도 중요합니다.

API, 즉 애플리케이션 프로그래밍 인터페이스는 최신 웹 개발의 핵심 요소입니다. 하지만 영향력이 클수록 막중한 책임이 따르며, API에 있어 책임은 바로 보안입니다. API 보안은 애플리케이션 간의 인터페이스를 보호하는 것입니다. 적절한 API 보안이 없으면 민감한 데이터가 노출되고, 시스템이 감염되고, 서비스가 중단될 수 있습니다. 기본적으로 API 보안은 악성 공격은 차단하되, 선의의 작업은 허용합니다.

API 보안의 두 가지 기본 측면은 인증과 권한 부여입니다. 인증은 사용자, 디바이스 또는 시스템의 ID를 확인하는 프로세스입니다. 클럽에 입장하려면 클럽 입구에서 신분증을 확인해 본인 확인을 거치는 것과 마찬가지입니다. 반면에 권한 부여는 인증된 사용자가 할 수 있는 일과 할 수 없는 일을 결정하는 것입니다. 클럽에 들어갈 수 있다고 해서 바에 들어가 술을 따라 마실 수 있지는 않습니다. API 세계에서 인증 및 권한 부여에는 API 키, 토큰 또는 OAuth와 같은 기술이 사용될 수 있습니다.

API 보안의 또 다른 중요한 측면은 입력 검증입니다. 여기에는 API로 전송된 데이터가 처리되기 전에 유효한지 확인하는 작업이 포함됩니다. 영화관에서 다른 영화 티켓 소지자가 상영관에 입장할 수 없도록 티켓을 확인하는 것과 마찬가지입니다. 입력 검증은 이렇듯 악성 데이터가 API에 침투해 문제를 일으키지 못하도록 방지하는 데 도움이 됩니다.

API 보안은 보안 담당 임원들이 최근에 가장 중요시하고 있는 분야 중 하나입니다. 하지만 가장 이해도가 낮은 분야 중 하나이기도 합니다. API는 구축 세부 사항에서 전략적 혁신의 원동력으로 빠르게 진화해 왔습니다. 따라서 많은 보안팀이 API 보안 전략과 관행을 더욱 정교하게 발전시키기 위해 노력하고 있습니다. API는 상거래를 가능하게 하는 존재이지만, 동시에 민감한 데이터를 전달하기도 합니다.

아래에서 보안 리더와 실무자가 API 보안에 대한 기초 지식을 높이는 데 활용할 수 있는 다양한 주제를 살펴보세요.

웹 API는 정의된 요청-응답 메시지 시스템에 공개적으로 노출된 하나 이상의 엔드포인트로 이루어진 프로그래밍 인터페이스로, 보통 웹을 통해 노출되는 JSON 또는 XML로 표현되며 HTTP 기반 웹 서버를 가장 흔히 활용합니다.

‘API’라고 하면 대부분은 웹 API를 떠올립니다. 웹 API는 엔드포인트의 집합입니다. 엔드포인트는 리소스 경로, 이러한 리소스에서 수행할 수 있는 작업, 리소스 데이터의 정의(JSON, XML, 프로토버프 또는 기타 형식)로 구성됩니다.

이 용어는 운영 체제나 라이브러리가 동일한 머신에서 실행되는 애플리케이션에 노출하는 웹 API를 다른 API와 구분하는데 유용하게 사용됩니다. 그러나 기업 디지털 전환과 API 보안에 대해 이야기할 때는 다들 ‘API’를 HTTP 기반(웹) API를 의미하는 것으로 이해합니다.

오늘날 HTTP 기반으로 정의되는 네 가지 주요 웹 API 종류는 다음과 같습니다.

• RESTful API - 2000년 로이 필딩(Roy Fielding)의 박사 학위 논문에서 처음 등장한 표현형 상태 전송은 가장 흔히 사용되는 웹 API 종류로, 보통 데이터에 JSON(자바스크립트 오브젝트 표기법)을 사용합니다. RESTful API는 최신 프런트엔드 프레임워크(예: React 및 React Native)에서 쉽게 사용할 수 있으며 웹 및 모바일 애플리케이션 개발을 용이하게 합니다. 그리고 B2B에 사용되는 API를 포함한 모든 웹 API의 사실상 표준이 되었습니다. 
• SOAP API - SOAP는 RPC(Remote Procedure Call)에 자세한 XML(eXtensible Markup Language)를 사용합니다. 레거시 API에서 여전히 볼 수 있습니다.
• GraphQL API - Facebook에서 개발한 새로운 GraphQL 표준으로, 단일 POST 엔드포인트(대개 /graphql)를 통해 데이터베이스 접속을 제공합니다. 이 표준은 단일 UI 페이지를 채우기 위해 여러 번 호출해야 하는 일반적인 RESTful API 문제를 해결하는 동시에 다른 추가적인 문제를 야기합니다.
• gRPC API - 주로 동서 통신에 사용되는 HTTP/2.0을 통해 Google에서 개발한 새로운 고성능 바이너리 프로토콜입니다.

B2C(Business-to-Consumer) API는 웹 및 모바일 애플리케이션을 구동하는 API입니다. 일반적으로 최신 프런트엔드 클라이언트에서 최종 사용자가 이러한 API를 통해 노출된 회사의 비즈니스 기능에 접속할 수 있도록 하는 데 사용됩니다.

B2B API는 회사의 비즈니스 파트너(다른 기업)가 사용하는 API로, 때로는 파트너에게 서비스를 제공하기 위해(최종 고객은 기업), 때로는 공동 고객(B2B2C)에게 가치를 제공하기 위해 사용됩니다.

B2B API는 공급업체, 리셀러 및 기타 파트너와의 업무 방식을 간소화하고 고객에게 더 나은 경험을 제공할 수 있도록 지원하므로 기업 디지털 전환의 토대가 됩니다.

B2B API의 사례는 다음과 같습니다.

• 오픈 뱅킹 API
• 공급망 관리 API
• 거래 파트너 간 전자 인보이스 발행 및 결제

API의 소비자가 상당히 다르기 때문에(B2C API를 사용하는 사용자 대상 앱과 B2B API를 사용하는 파트너 비즈니스 앱), 이러한 API를 보호하는 데 사용할 수 있는 보안 제어 기능도 다양합니다.

보안과 관련해 업계는 최근까지 B2C 사용 사례에 집중해 왔는데, 이 경우에도 B2C API 보안보다는 웹 애플리케이션 보안에 중점을 두었습니다. B2C 웹 애플리케이션 보안에 사용되는 보안 제어 기능은 B2C API 보안에 제대로 적용되지 않거나(예: WAF/WAAP), 전혀 적용되지 않습니다(예: 대부분의  봇 보호 솔루션).

B2B API 보안 문제는 점점 심각해지고 있습니다. B2B API의 경우, 1세대 벤더사 중 공유 사용자를 대신해 대량 데이터 접속을 처리하는 전용 가시성 및 보안 솔루션은 존재하지 않습니다(예: 핀테크 기업과 금융 기관이 고객 데이터를 합의 하에 공유하는 오픈 뱅킹의 경우). 

단일 API 엔드포인트를 생각하면서 ‘API’라는 단어를 사용하는 경우가 많습니다. 서비스 또는 API 제품이라고도 하는 API는 비즈니스 기능을 제공하는 엔드포인트의 모음입니다. 반면에 엔드포인트는 리소스(또는 리소스 경로, Uniform Resource Identifier(URI)라고도 함)와 이 리소스에서 수행되는 작업(생성, 읽기, 업데이트 또는 삭제 - RESTful API에서 일반적으로 HTTP 방법인 POST, GET, PUT, DELETE에 매핑되는 작업)입니다.

기업이 외부 세계, 주로 비즈니스 파트너에 노출하는 API입니다. 예를 들어 오픈 뱅킹을 도입한 은행은 API를 통해 다른 핀테크 또는 금융 서비스 기업에 계좌를 노출할 수 있습니다. 헬스케어 기업은 API를 통해 보험사와 다른 의료 기관에 환자 기록을 노출할 수 있습니다. 호텔 기업은 API를 통해 여행사나 애그리게이터에게 예약 시스템을 노출할 수 있습니다. API는 기업을 연결하는 결합 조직입니다. 남북 API는 접속 권한이 부여되고 인증되므로 안전하다고 간주되는 경우가 많으며, 일반적으로 가장 빠르게 성장하고 규모가 가장 큰 API이기 때문에 대부분의 기업에서 가장 큰 공격표면이 됩니다.

기업이 내부적으로 사용하는 API입니다. 이러한 API는 내부 애플리케이션이나 사업부 또는 부서를 연결합니다. 기업 외부에서 접속할 수 없는 API는 동서 API로 간주됩니다.

내부 API라고도 하는 프라이빗 API는 회사의 개발자와 계약업체가 사용하도록 만들어진 것입니다. Service-Oriented Architecture(SOA) 이니셔티브의 일부인 프라이빗 API는 여러 부서나 사업부가 서로의 데이터에 효율적이고 효과적으로 접속할 수 있도록 함으로써 내부 개발을 간소화합니다.

이와 달리 외부 API라고도 하는 퍼블릭 API는 회사 외부의 소비자에게 노출됩니다. 극단적으로 표현하자면 오픈 API인 퍼블릭 API는 누구나 자유롭게 사용할 수 있습니다. 그러나 어떤 경우든 회사 외부의 엔지니어가 사용할 수 있도록 더욱 엄격한 관리와 정확한 문서화를 요구합니다.

인터넷을 통해 접속할 수 있는 프라이빗 API는 엄밀한 의미에서 실제로는 비공개가 아니라는 점에 유의해야 합니다. 예를 들어 ACME 모바일 앱(ACME 엔지니어가 자체 개발)에서만 사용하는 ACME의 B2C API를 생각해 보세요. 프라이빗 API라고 생각할 수도 있지만, API에 대한 트래픽이 인터넷(‘회사 외부’)에서 발생하기 때문에 사실 비공개라기보다는 단순히 문서화되지 않은 API라고 할 수 있습니다. 해커는 트래픽을 가로채고 모바일 앱을 리버스 엔지니어링해 어떤 API와 상호 작용하는지 확인하는 방식으로 매일 이러한 API를 공격합니다.

API 보안 리스크는 이미 기업 보안팀이 직면한 가장 시급한 리스크 중 하나이며, API를 사용하는 고객 인터렉션과 내부 비즈니스 프로세스가 증가하면서 문제는 더 심각해지고 있습니다.

다시 말해 API 사용은 폭발적으로 증가하고 있으며 많은 보안팀이 API 보안 전략을 추진하고 있습니다.

이러한 이유로 API 보안은 IT 및 보안 담당 임원의 최우선 순위이자 관심 분야 중 하나로 빠르게 부상하고 있습니다. 실제로 Gartner 리서치에서는 2022년까지 API 남용은 드물게 발생하는 공격 벡터에서 가장 빈번하게 발생하는 공격 기법으로 바뀌어 기업 웹 애플리케이션의 데이터 유출을 초래할 것이라 내다봤습니다.

API 보안과 기존  애플리케이션 보안은 서로 연관된 분야이지만, 문제의 규모와 복잡성이라는 두 가지 주된 이유로 인해 API 보안은 별도의 문제가 되었습니다.

3가지 요인으로 인해 API 사용이 급증하고 있습니다.

1. 서비스 간 통신을 위해 API를 사용해야 하는 아키텍처인 마이크로서비스의 사용이 증가하고 있습니다.
2. 직접 사용자 채널에서 React, Angular, Vue 같은 최신 프런트엔드 애플리케이션 프레임워크는 API를 사용하며, API를 사용하지 않는 레거시 웹 애플리케이션을 대체하고 있습니다.
3. 나아가 파트너, IoT 및 비즈니스 자동화를 위한 완전히 새로운 채널(본질적으로 다른 채널)을 처리하기 위해 API가 추가되었습니다.

웹 애플리케이션과 달리 API는 프로그래밍에 사용할 수 있도록 다양한 방식으로 설계되어 정상적인 사용과 공격, 악용을 구분하기가 매우 어렵습니다.

점점 더 많은 기업이 API를 사용해 고객 및 파트너와 양방향으로 비즈니스 프로세스와 데이터를 사용할 수 있도록 지원하고 있습니다. B2C라고도 하는 기업과 소비자 간 API가 웹사이트나 모바일 앱의 데이터를 강화한다는 사실은 대부분 알고 있습니다. 하지만 백그라운드에서 트리거되는 API 네트워크에도 API 간 보안이 필요합니다. 금융 정보를 조회하기 위해 접속하는 핀테크 앱이 사용자를 인증하기 위해 해당 앱에서 은행으로 기업 간, 즉 B2B API 호출을 생성한다고 생각해 보세요. B2C-B2B API 호출 네트워크를 통해 모든 API 트래픽을 보호하기 위한 종합적 접근 방식이 필요함을 알 수 있습니다. B2C 및 B2B API 호출이 복잡하게 얽혀 있다는 것은 기업이 API 간 보안까지 고려해야 한다는 의미입니다.

API 보안 강화에 관심이 있는 기업은 다음 12개 모범 사례부터 시작하는 것이 좋습니다.

• 기업의 소프트웨어 개발 라이프사이클에 API 보안 표준 및 관행을 통합하는 방법을 찾습니다.
• API 문서와 자동화 보안 테스트를 Continuous Integration/Continuous Delivery(CI/CD) 파이프라인에 통합합니다.
• 적절하고 효과적인 인증 및 권한 제어가 API에 적용되었는지 확인합니다.
• API가 악용되거나 과부하되는 것을 방지하기 위해 전송률 제한 조치를 구축합니다.
• 특수 게이트웨이 또는 콘텐츠 전송 네트워크를 통해 전송률 제한 및 기타 애플리케이션 수준 조치를 강화해 Distributed Denial-of-Service(DDoS) 공격의 리스크를 방어합니다.
• API 보안 테스트를 보다 광범위한 애플리케이션 테스트 프로세스의 필수적인 부분으로 만듭니다.
• API를 지속적으로 발견합니다.
• 일반적인 API 취약점을 탐지하고 해결하기 위한 체계적인 접근 방식을 구축합니다 (OWASP API 상위 10대 취약점 포함).
• 시그니처 기반의 위협 탐지 및 방지를 알려진 API 공격에 대한 기본 보안 수준으로 사용합니다.
• AI와 행동 애널리틱스로 시그니처 기반 탐지를 강화해 API 위협 탐지의 확장성, 정확성, 비즈니스 관련성, 새로운 위협에 대한 복원력을 개선합니다.
• API 보안 모니터링과 분석을 몇 주 동안 API 세션에 걸쳐 확장합니다.
• 위협 탐색자, 개발자, DevOps, 지원 담당자가 사용할 수 있도록 API 보안 모니터링과 알림을 API 인벤토리 및 활동 데이터에 대한 온디맨드 접속으로 보완합니다.

API 보안 모범 사례에 접근하는 가장 좋은 방법은 아래와 같은 프레임워크를 활용해 기업의 성숙도 측면에서 생각하는 것입니다.

API 취약점은 공격자가 민감한 애플리케이션 기능이나 데이터에 접속하거나 API를 오용하기 위해 악용할 수 있는 소프트웨어 버그 또는 시스템 설정 오류입니다.

 OWASP API 상위 10대 취약점은 기업이 식별하고 해결해야 하며 가장 널리 악용되는 API 취약점 중 몇 가지를 간략히 설명합니다.

 OWASP API 상위 10대 취약점은 API 안전 및 보안 체계를 개선하고자 하는 기업에 훌륭한 출발점이 될 수 있습니다. OWASP API 상위 10대 취약점 카테고리는 발생 가능한 다양한 API 리스크를 아우릅니다. 그러나 여기에 포함되는 카테고리가 상당히 광범위하다는 점에 유의해야 합니다. 따라서 각 카테고리의 하위 분야를 분석해 집중적으로 살펴봐야 합니다.

로직 버그 악용과 같이 OWASP API 상위 10대 취약점에 완전히 포함되지 않는 API 안전 리스크도 있습니다. 예를 들어, API 공격자는 권한 부여 문제(OWASP에서 광범위하게 다룸)를 이용하고 로직 버그(OWASP에서 전혀 다루지 않음)를 악용하는 경우가 많습니다.

API는 여러 방법으로 공격받고 악용될 수 있지만, 가장 일반적인 사례는 다음과 같습니다.

• 취약점 악용: 기반 인프라의 기술적 취약점은 서버 감염을 초래할 수 있습니다. 이러한 종류의 취약점은 Apache Struts 취약점(CVE-2017-9791, CVE-2018-11776 및 기타)부터 Log4j 취약점(CVE-2021-44228 및 기타)까지 다양합니다.
• 비즈니스 로직 악용: CISO의 밤잠을 설치게 하는 무서운 시나리오인데 기존의 보안 제어 기능으로는 이러한 위협에 대응할 수 없기 때문입니다. 로직 악용은 공격자가 애플리케이션 설계 또는 구축 결함을 악용해 예상치 못한 승인되지 않은 행동을 유도하는 것을 말합니다.
• 무단 데이터 접속: API 악용의 또 다른 일반적인 형태는 취약한 권한 메커니즘을 악용해 접속이 허용되지 않아야 하는 데이터에 접속하는 것입니다. 이러한 취약점에는 BOLA(Broken Object-Level Authorization), IDOR(Insecure Direct Object Reference), BFLA(Broken Function-Level Authorization) 같은 여러 종류가 있습니다. 최신 취약점 목록은 OWASP API 보안 프로젝트 웹사이트에서 확인할 수 있습니다.
• 계정 탈취: 인증정보 도난 또는 크로스 사이트 스크립팅(XSS) 공격이 발생한 후에는 계정이 탈취될 수 있습니다. 이렇게 되면 아무리 잘 작성되고 완벽하게 보호된 API라도 악용될 수 있습니다. 결국 행동 분석을 수행하지 않으면 인증된 모든 활동이 정상적인 사용으로 간주됩니다.
• 데이터 스크레이핑: 기업이 퍼블릭 API를 통해 데이터 세트를 제공함에 따라 공격자는 이러한 리소스를 공격적으로 쿼리해 중요한 대규모 데이터 세트를 일괄적으로 캡처할 수 있습니다.
• 비즈니스 DoS(Denial of Service): API 공격자는 백엔드에 과중한 작업을 수행하도록 요청해 애플리케이션 레이어에서 ‘서비스 침식’이나 완전한 서비스 거부를 일으킬 수 있습니다. 이는 GraphQL에서 매우 일반적인 취약점이지만, 리소스 집약적인 API 엔드포인트 구축에서도 발생할 수 있는 문제입니다.

백엔드 API는 개발자가 핵심 애플리케이션 서비스에 빠르고 반복 가능한 방식으로 접속할 수 있게 해줍니다. 이는 다양한 사용자 인터페이스를 통해 데이터를 제공하는 기업에 특히 중요합니다. 백엔드 API를 보호하기 위해 취해야 할 가장 중요한 단계 중 하나는 올바른 인증 및 접속 모델을 구축하는 것입니다. 동시에 아무리 잘 인증된 백엔드 API도 악용될 수 있다는 사실을 인정하는 것도 중요합니다.

공격자가 모바일 앱이나 웹 인터페이스의 취약점을 악용해 사용자 인터페이스가 예상치 못한 무허가 방식으로 백엔드 API와 상호 작용하도록 한 수많은 사례가 있었습니다. 이러한 공격 및 기타 종류의 악용으로부터 백엔드 API를 보호하는 가장 좋은 방법은 행동 애널리틱스를 지속적으로 사용하는 것입니다. 백엔드 API의 기본 사용량 모델을 만들면 비정상을 탐지하고 초기 개발 및 구축 과정에서 예상하지 못했던 공격 기법으로부터 백엔드 API를 보호하기 위한 선제적 조치를 취할 수 있습니다.

API는 시장과 비즈니스 요구사항의 변화에 따라 끊임없이 달라지고 있습니다. 새로운 비즈니스 요구사항을 충족하고, 버그를 수정하고, 기술적 개선을 도입하기 위해 새로운 엔드포인트 구축이 릴리스되면 이러한 엔드포인트의 이전 버전은 지원이 종료됩니다.

기존 엔드포인트의 폐기 프로세스 관리는 결코 간단하지 않습니다. 사용이 중단되어야 하는 엔드포인트 구축이 여전히 살아 있고 접속할 수 있는 경우가 종종 있는데, 이를 좀비 API라고 합니다.

전사적으로 섀도 API를 검색하는 가장 좋은 방법은 가장 광범위한 범위를 제공하는 소스에서 API 활동 로그 데이터를 수집하고 분석하는 것입니다. 모든 API에 앱별 센서를 배포하면 API 활동에 대한 풍부한 정보를 제공할 수 있지만, 레거시 API나 사용자가 모르는 API가 섀도에 남아 있기 때문에 광범위한 커버리지를 제공할 수는 없습니다.

API 활동 데이터 로그 소스의 예는 다음과 같습니다.

• 콘텐츠 전송 네트워크(CDN)
• API 게이트웨이
• 웹 애플리케이션 방화벽(WAF)
• 쿠버네티스 컨테이너 오케스트레이션

사용 가능한 모든 소스의 원시 데이터를 수집한 후에는 AI 기술을 사용해 모든 API, 엔드포인트, 매개변수로 이루어진 사람이 이해할 수 있는 인벤토리로 변환할 수 있습니다. 여기에서 추가 분석을 통해 이러한 요소를 분류하고, 제거하거나 공식 거버넌스 프로세스로 가져와야 하는 섀도 API를 식별할 수 있습니다.

내부 API의 경우, ‘내부’의 의미가 무엇인지에 따라 달라집니다. 인터넷을 통해 기업의 웹 및 모바일 애플리케이션에 노출된 API를 ‘내부 API’라고 부르는 경우도 많습니다. 이런 API에 대한 문서는 실제로 회사 직원과 계약자만 접속할 수 있지만, 해커들은 앱 디스어셈블리 툴킷과 Burp Suite 같은 프록시를 통해 앱을 분석하고 앱을 제공하는 API를 매우 능숙하게 리버스 엔지니어링합니다.

그러나 ‘내부 API’가 기업 외부에서 접속할 수 없는 동서 API라면 주요 위협은 내부자 위협으로 축소됩니다.

대부분의 API와 마찬가지로 내부 API(전자의 의미)와 B2B API를 보호해야 합니다. Secure Software Development Lifecycle(SSDLC)을 보호하는 것부터 시작해 인증되고 권한이 부여된 접속을 보장하고, 할당량/전송률 제한/스파이크 차단을 관리하고, WAF/WAAP를 통해 알려진 시그니처를 방지하세요.

B2B API의 경우, 트랜잭션이 민감하고 대량으로 이루어지는 경우가 많기 때문에 가능하면 mTLS와 같은 엄격한 인증 메커니즘을 추가하는 것이 좋습니다.

둘 모두에, 특히 많은 주체가 관련되어 있어 정상적인 행동과 비정상적인 행동을 구분하는 과정이 어려울 경우에는 행동 애널리틱스를 사용하기를 권장합니다.

예:

• 특정 사용자의 API 인증정보가 감염되었는지 어떻게 확인하나요?
• 파트너가 계정 데이터를 훔치기 위해 인보이스 번호를 열거하는 방식으로 인보이스 발행 API가 악용되고 있는지 어떻게 확인하나요?

B2B API와 내부 API를 보호하려면 IP 주소나 API 토큰 같은 기술적 요소만 분석해서는 얻을 수 없는 비즈니스 맥락이 필요합니다. AI와 행동 애널리틱스를 사용해 비즈니스 관련 주체에 대한 가시성을 확보하는 것이 B2B API 및 내부 API 리스크를 효과적으로 이해하고 관리할 수 있는 유일한 방법입니다. 사용자나 파트너, 심지어 비즈니스 프로세스 주체(인보이스, 결제, 주문 등)와 같은 특정 주체의 정상적인 API 사용에 대한 비즈니스 맥락과 과거 벤치마크를 통해 다른 방법으로는 탐지되지 않는 비정상을 파악할 수 있습니다.

API에 대한 전략적 접근 방식을 취하는 많은 기업이 API Gateway를 사용합니다. Apigee, Kong, MuleSoft, Akamai, AWS API Gateway, Azure API Management 등이 그 예입니다.

대부분의 API Gateway에는 기업이 활용해야 할 풍부한 통합 보안 기능이 있으며, 그중 첫 번째는 인증(OpenID Connect를 활용할 수 있는 경우 권한 부여도 포함)입니다.

하지만 다음과 같은 여러 이유로, API Gateway에서 인증, 권한 부여, 할당량 관리만 수행하는 것만으로는 충분하지 않습니다.

• API Gateway의 검색 격차: API Gateway는 관리하도록 설정된 API에 대한 가시성과 제어 기능만 가지고 있기 때문에 섀도 API와 엔드포인트를 탐지하는 데 효과적이지 않습니다.
• API Gateway의 보안 격차: API Gateway는 인증 및 권한 부여 체계를 어느 정도 적용할 수 있지만, WAF와 WAAP처럼 페이로드를 검사하거나 악용을 탐지하기 위해 행동을 프로파일링하지 않습니다.

API가 사용되는 다양한 방법을 고려하면 발생할 수 있는 API 설정 오류의 수는 거의 무한합니다. 다음은 몇 가지 일반적인 사례입니다.

인증은 API를 통해 제공되는 민감한 데이터를 보호하기 위한 기본적인 요소입니다. 첫 번째 단계는 민감한 데이터를 전달하는 모든 API에 처음부터 인증을 적용하는 것입니다. 하지만 전송률 제한을 통해 무차별 대입 공격, 크리덴셜 스터핑, 도난당한 인증 토큰의 사용으로부터 인증 메커니즘을 보호하는 것도 중요합니다.

API 소비자가 인증 메커니즘을 우회할 수 있는 설정 오류는 때때로 토큰 관리와 관련해 발생할 수 있습니다(예: 일부 악명 높은 JWT 유효성 검사 문제 또는 토큰 범위를 확인하지 않는 경우).

API의 가장 일반적인 용도 중 하나는 민감한 정보를 포함한 데이터나 콘텐츠에 대한 접속을 제공하는 것입니다. 권한 부여는 API 소비자에게 데이터를 제공하기 전에 API 소비자가 접속하려는 데이터에 접속할 수 있는 자격이 있는지 확인하는 프로세스입니다. 이는 오브젝트나 리소스 수준(예: 내 주문에는 접속할 수 있지만, 다른 사람의 주문에는 접속할 수 없음)에서 수행하거나 기능 수준(관리 기능의 경우처럼)에서 수행할 수 있습니다.

엣지 케이스와 조건의 수가 많고 마이크로서비스 간에 API 호출이 발생할 수 있는 흐름이 다양하기 때문에 권한을 올바르게 확보하기는 쉽지 않습니다. 중앙 집중식 권한 부여 엔진이 없는 경우, API 구축에 Broken Object-Level Authorization(BOLA) 및 Broken Function-Level Authorization(BFLA)과 같은 취약점 중 일부가 포함되어 있을 가능성이 높습니다.

위에서 언급한 인증 및 권한 부여 문제 외에도 안전하지 않은 통신(예: SSL/TLS를 사용하지 않거나 취약한 암호 모음 사용), 보호되지 않는 클라우드 스토리지, 지나치게 관대한 교차 오리진 리소스 공유 정책 등 다양한 종류의 보안 설정이 잘못되어 있을 수 있습니다.

API 소비자가 호출할 수 있는 횟수에 제한 없이 API를 구축하면 공격자가 시스템 리소스를 과부하시켜 서비스 성능 저하나 전면적인 Denial of Service(DoS)를 일으킬 수 있습니다. 최소한 인증되지 않은 엔드포인트 접속에 대해서는 전송률 제한을 적용해야 합니다. 그렇지 않으면 인증 엔드포인트가 매우 중요한 경우 무차별 대입 공격, 크리덴셜 스터핑, 인증정보 확인 공격이 발생할 수밖에 없습니다.

API 공격은 악의적이거나 승인되지 않은 목적으로 API를 사용하려는 시도를 말합니다. API 공격은 다음과 같이 다양한 형태를 취합니다.

• API 구축의 기술적 취약점 악용
• 도난당한 인증정보 및 기타 계정 탈취 기술을 이용해 합법적인 사용자로 가장
• 예상치 못한 방식으로 API를 사용하기 위한 비즈니스 로직 악용

웹사이트와 SaaS 플랫폼에서 사용자 ID와 암호 정보가 유출되는 사고가 빈번하게 발생하고 있습니다. 이러한 인시던트로 인해 대량의 인증정보 세트가 온라인에서 널리 공유되는 경우가 많습니다.

크리덴셜 스터핑은 이전에 침해된 웹사이트에서 유출된 인증정보를 사용해 다른 웹사이트에 자동 로그인을 시도하는 행위입니다. 이 방법은 일정 비율의 사용자가 여러 사이트에서 동일한 인증정보를 사용한다는 전제를 바탕으로 합니다.

이 수법은 점점 더 웹 또는 모바일 애플리케이션과 같은 프런트엔드를 거치지 않고 API에 직접 적용되고 있습니다. 결국 API는 사용하기 쉽도록 만들어졌기 때문에 공격자가 공격을 더 쉽게 자동화할 수 있습니다.

데이터 유출은 성공적인 API 공격 및 악용의 결과로 발생하는 경우가 많습니다. 경우에 따라서는 공격자가 API 공격 및 악용을 통해 훔친 매우 민감한 비공개 정보를 의미하기도 합니다. 그러나 집계적인 형태로 가치 있는 대규모 데이터 세트를 모으기 위해 공개적으로 사용 가능한 데이터를 공격적으로 스크레이핑하는 등 덜 심각한 종류의 API 악용에도 적용될 수 있습니다.

개발 관행: 다음은 보안 담당 임원이 API 안전 및 보안 전략을 개발할 때 고려해야 할 주요 트렌드입니다.

행동 애널리틱스 및 비정상 탐지: 기업은 가능한 공격을 예측하고 시그니처 기반 탐지 및 사전 정의된 정책(예: WAF)에 의존해 리스크를 방어하는 것 외에도, 비즈니스 맥락에서 API 활동을 확인하고 비정상을 탐지하기 위해 AI 및 행동 애널리틱스에 점점 더 많은 노력을 기울이고 있습니다.

온프레미스에서 SaaS로 전환: 많은 1세대 API 보안 제품이 온프레미스에 배포되었으나 속도와 배포 용이성, 대규모로 AI와 머신 러닝의 힘을 활용할 수 있는 능력으로 인해 SaaS(Software as a Service) 기반 접근 방식이 널리 활용되고 있습니다.

장기간에 걸친 분석: 개별 API 호출이나 단기 세션 활동만 분석하는 API 보안 접근 방식은 기본적인 자동화된 WAF 정책 최적화 완료부터 행동 애널리틱스 수행과 비정상 탐지에 이르기까지 며칠, 때로는 몇 주에 걸쳐 API 활동을 분석하는 플랫폼으로 대체되고 있습니다.

DevSecOps - 비보안 이해관계자 포용: API 리스크를 줄이는 가장 좋은 방법 중 하나는 API 보안 전략 및 툴과 API의 생성, 구축, 설정에 관여하는 개발자와 시스템 간의 연계성을 높이는 것입니다.

API 기반 API 보안: 현재 진행 중인 API 공격과 악용 사례를 탐지하고 방어하는 것이 중요하지만, 미래 지향적인 기업은 API 보안 데이터와 인사이트에 대한 온디맨드 접속을 사용해 위협 탐색, 인시던트 대응, API를 개선하는 방법을 찾고 있습니다.

시그니처 기반의 API 보안 기술은 알려진 공격 특성과 패턴을 모니터링하고, 일치하는 것이 관찰되면 보안 알림과 기타 자동화된 대응을 생성합니다. 많은 API 공격 및 악용 기법에는 시그니처가 없기 때문에, API 보안은 물론 일반적인 경우에 시그니처 기반 탐지가 줄 수 있는 가치는 제한적입니다.

시그니처 기반 탐지는 단일 패킷 또는 요청에 어떤 징후가 존재한다는 전제로 이루어집니다. 이 사용자는 누구인지, 지난달에 몇 개의 엔드포인트에 접속했는지 등 맥락에 대해 걱정할 필요가 없기 때문에 시그니처 매칭 엔진은 매우 빠른 속도로 작동할 수 있습니다. 하지만 이 때문에 대부분의 API 공격을 완전히 놓칠 수도 있습니다.

API 보안에는 맥락이 필요합니다. 각 API 요청을 수행하는 사용자, 이전 요청, 모든 사용자의 전반적인 요청 패턴 맥락을 이해해야 합니다. 따라서 비정상적인 사용을 탐지하려면 행동 애널리틱스와 머신 러닝에 기반한 API 보안 기법을 사용해야 합니다.

API 탐지 및 대응은 기록 데이터에 대한 심층 분석에 초점을 맞춘 새로운 API 보안 카테고리이며 다음을 지원합니다.

• 모든 API 소비자의 행동에 대한 기준 설정
• API 악용과 오용 가능성을 나타내는 공격 및 비정상 탐지

대규모의 효과적인 API 탐지 및 대응은 리소스 집약적인 AI 및 머신 러닝 기술이 필요한 대규모 데이터 세트와 관련이 있기 때문에 Software as a Service(SaaS) 모델에서만 제공할 수 있습니다.

고급 API 위협 방어는 행동 애널리틱스와 위협 탐색을 결합한 SaaS 기반의 API 보안 접근 방식이며 다음을 지원합니다.

• 섀도 또는 좀비 API를 비롯한 기업에서 사용 중인 모든 API 검색
• 머신 러닝을 적용해 API 사용 및 악용 실태에 대한 비즈니스 맥락을 오버레이
• 장기간에 걸쳐 저장된 API 및 API 활동 데이터에 대한 행동 애널리틱스 및 위협 탐색 수행

API 보안 플랫폼은 특별히 다음과 같은 용도로 설계된 SaaS 기반 제품입니다.

• 기업 차원에서 사용 중인 모든 API의 지속적으로 업데이트된(제재 여부와 관계없이) 인벤토리 생성
• AI 및 머신 러닝 기술로 API와 그 사용 현황을 분석해 비즈니스 맥락을 파악하고 예상되는 행동의 기준 결정
• API 사용의 비정상을 탐지하고, 필요한 경우 Security Information And Event Management(SIEM) 및 Security Orchestration, Automation and Response(SOAR) 워크플로우에 알림과 지원 데이터 제공
• 보안 및 비보안 이해관계자 모두에게 API 인벤토리, 활동, 위협 정보에 대한 온디맨드 접속 제공

기업은 다양한 종류의 API 보안 기술을 사용해 애플리케이션과 민감한 데이터를 오남용 및 여러 종류의 공격으로부터 보호합니다. 일반적인 API 보안 종류는 다음과 같습니다.

• 개발 및 테스트 중에 API 코드에서 결함 및 취약점 스캔
• API 위협 모델 개발 및 입력 검증과 같은 대응책 구축
• TLS 암호화와 같은 모범 사례, 견고하고 확장 가능한 인증 및 권한 부여 모델을 통해 API 구축
• 웹 애플리케이션 방화벽, 봇 방어 플랫폼, API Gateway와 같은 전문 툴을 API 앞에 배포
• 정기적인 취약점 평가를 수행해 구성 오류나 기타 구축 결함 식별
• 지속적인 API 검색을 수행해 사용 중인 모든 API가 보호되고 있는지 또는 필요한 경우 폐기되었는지 확인
• 시그니처를 사용해 알려진 API 공격 기법 모니터링
• 행동 애널리틱스 및 비정상 탐지를 통해 보다 정교한 형태의 API 악용 모니터링
• 지속적인 위협 탐색 활동을 수행해 리스크를 조기에 식별 및 방어하고 개발 및 운영팀에 선제적으로 보안 가이드 제공

이러한 모든 종류의 API 보안은 잠재적으로 전반적인 보안 전략에서 중요한 역할을 할 수 있지만, 기업의 특정 리스크 프로필에 중점을 두고 통합된 방식으로 구축해야 합니다.

IT 및 보안 리더는 API를 보다 전략적으로 사용하므로 전문 API 파트너와 협력해야 할 수도 있습니다. API 회사의 가장 일반적인 두 가지 종류는 다음과 같습니다.

• 중앙에서 API 호출을 수락하고 적절한 백엔드 리소스와 마이크로서비스로 라우팅하는 기술을 제공하는 API Gateway 회사
• 기업이 모든 활성 API를 인식하고, 공격 및 악용 사례를 탐지하며, API가 어떻게 사용되고 있는지에 대한 풍부한 데이터를 제공하는 API 보안 플랫폼 회사

많은 보안팀은 잠재적 위협을 조기에 식별하고 대응책을 마련하기 위해 선제적인 위협 탐색 활동을 수행합니다. 1세대 API 보안 제품은 알림에 초점을 맞추고 API 활동을 전혀 저장하지 않아 쿼리하고 탐색할 데이터가 없기 때문에 위협 탐색팀에게 제한적인 가치를 제공하는 경우가 많습니다. 고급 API 보안 회사는 맥락이 풍부한 대규모의 API 활동 데이터 세트를 저장하고 이 정보를 GUI와 API를 통해 제공하므로 위협 탐색자들이 데이터를 활용할 수 있습니다.

웹 애플리케이션 및 API 보안(WAAP)은 리서치 기관인 Gartner가 새로운 웹 및 API 위협에 대한 업계 적용 범위를 분류하는 데 사용됩니다. 이는 API 보안의 전략적 중요성이 커지고 웹 애플리케이션 방화벽(WAF) 플랫폼이 매니지드 SaaS로 클라우드로 이동함에 따라 WAF 시장에 대한 업계의 초기 적용 범위에서 발전한 것입니다.

웹 API의 가장 일반적인 종류인 RESTful API에 대한 가장 일반적인 형태의 API 문서는 OpenAPI 사양에 기반한 Swagger 파일 모음입니다. API 문서는 API를 설계하거나 구축할 때 개발자가 작성하는 것이 이상적입니다. 그러나 현실에서는 API 문서가 오래된 경우가 많아 실제 API 사용과 문서가 일치하지 않는 경우가 많습니다. 이 문제를 해결하기 위해 일부 API 보안 플랫폼은 실제 API 활동에서 Swagger 파일을 생성해 문서화된 내용과 실제 배포된 내용 사이의 차이를 강조할 수 있으며, 이는 모든 API 리스크 평가에서 필수적인 구성요소입니다.

효과적인 API 보안을 위해서는 여러 세부 단계와 지속적인 관행이 필요합니다. 보안팀은 다음과 같은 API 체크리스트를 보다 정교한 API 보안 접근 방식을 향해 나아가기 위한 출발점으로 삼을 수 있습니다.

• API 보안 접근 방식에 전사적으로 지속적인 API 검색을 위한 메커니즘이 포함되어 있나요?
• 클라우드 및 SaaS를 활용해 AI 및 머신 러닝 기술에 접속하며 불필요한 배포의 복잡성을 피하고 있나요?
• API 보안 접근 방식이 충분히 긴 기간(이상적으로는 30일 이상)에 걸쳐 데이터를 분석하고 있나요?
• 이러한 접근 방식이 팀에게 관찰되는 API 활동과 발생 가능한 리스크를 제대로 이해하는 데 필요한 비즈니스 맥락을 제공하나요?
• API 보안 플랫폼과 SIEM/SOAR, 위협 탐색, 문서화, DevOps 툴 등과 같은 기타 관련 비즈니스 프로세스 간의 양방향 자동화를 위한 전략이 있나요?
• 개발자 같은 비보안 이해관계자를 API 보안 툴과 프로세스에 참여시키기 위한 조치를 취하고 있나요?

다음은 보안 맥락에서 발생할 수 있는 API의 일반적인 분류와 설명입니다.

보안팀은 API 구축을 위한 다양한 사용 모델과 기술 접근 방식을 나타내는 다음 용어를 숙지하는 것이 좋습니다.

API 보안 솔루션은 악성 공격과 데이터 유출로부터 애플리케이션 프로그래밍 인터페이스(API)의 보안을 보장하는 데 사용되는 일련의 툴과 관행을 말합니다. API는 기업과 조직에서 애플리케이션이 서로 통신하고, 데이터를 공유하고, 다양한 기능을 수행할 수 있도록 하는 데 널리 사용됩니다. 

하지만 API의 사용 범위가 넓어지면서 관련된 보안 리스크도 늘어나고 있습니다. API는 무단 접속, 서비스 거부 공격, 인젝션 공격 등 다양한 보안 위협에 취약할 수 있습니다. 이러한 리스크를 방어하려면 기업은 강력한 API 보안 솔루션을 구축해야 합니다.

API 보안 솔루션에는 다음이 포함됩니다.

• 인증 및 권한: API 보안 솔루션은 API에 접속하는 사용자를 인증하고 권한을 부여해 승인된 사용자만 데이터에 접속하고 이를 조작할 수 있도록 합니다. 인증 방법에는 멀티팩터 인증, OAuth, OpenID Connect, API 키 등이 있으며, 권한 부여 방법에는 역할 기반 접속 제어와 속성 기반 접속 제어가 있습니다.
• API Gateway: API Gateway는 포괄적인 API 보안 솔루션의 구성요소로, 모든 API 요청의 진입점 역할을 합니다. 게이트웨이는 인증, 전송률 제한, 트래픽 관리, 캐싱 등 여러 기능을 수행할 수 있으며, Distributed Denial of Service(DDoS)와 같은 공격을 방지하는 데 도움이 될 수 있습니다.
• 암호화: API 보안 솔루션에는 암호화가 포함되어 있어 API를 통해 전송되는 데이터를 안전하게 보호하고 공격자가 가로챌 수 없도록 보장합니다. 암호화 기술에는 API 요청, 응답 및 미사용 데이터를 암호화하는 데 사용할 수 있는 SSL, TLS 및 AES 암호화가 포함됩니다.
• 전송률 제한: 전송률 제한은 사용자가 지정된 시간 내에 수행할 수 있는 요청의 수를 제한해 서비스 거부 공격을 방지하는 데 도움이 되는 API 보안 솔루션의 기능입니다. 전송률 제한은 IP 주소, 사용자 계정 또는 기타 매개변수를 기반으로 할 수 있으며, 공격자가 요청으로 API를 압도하지 못하도록 하는 데 도움이 될 수 있습니다.
• 감사 및 로깅: API 보안 솔루션에는 API 활동에 대한 가시성을 제공해 보안 위협을 탐지하고 방어하는 데 도움이 되는 감사 및 로깅 기능도 포함되어야 합니다. 감사에는 API 요청과 응답을 추적하는 작업이 포함되며, 로깅에는 안전하고 변조되지 않는 방식으로 API 이벤트와 활동을 기록하는 작업이 포함됩니다.
• API 테스트: API 보안 솔루션에는 취약점과 잠재적인 보안 리스크를 식별하기 위한 API 테스트도 포함됩니다. API 테스트는 수동 또는 자동화된 툴을 사용해 수행할 수 있으며, API가 안전하고 의도한 대로 작동하는지 확인하는 데 도움이 될 수 있습니다.
• API 모니터링 및 런타임 보호: API 행동은 API 보안 솔루션에서 모니터링해야 합니다. 정상적인 행동과 비정상적인 악용을 이해해야 악성 사용자로부터 API를 보호할 수 있습니다.
• 취약점 관리: API 보안 솔루션에는 API의 보안 취약점을 식별하고 해결하는 취약점 관리 기능도 포함됩니다. 취약점 관리에는 취약점 스캔, 패치 적용, 수정이 포함될 수 있으며, 이를 통해 공격자가 API의 알려진 취약점을 악용하는 것을 방지할 수 있습니다.

API 보안 솔루션은 API의 보안과 무결성을 보장하는 데 매우 중요합니다. 기업은 인증 및 권한 부여, API Gateway, 암호화, 전송률 제한, 감사 및 로깅, API 테스트, 모니터링, 런타임 보호, 취약점 관리 등을 구축해 다양한 보안 위협으로부터 API를 안전하게 지킬 수 있습니다. 

API가 비즈니스 운영에 필수적인 요소로 자리 잡은 오늘날, 기업은 민감한 데이터와 지적 재산을 보호하려면 강력한 API 보안 솔루션에 투자해야 합니다.

행동 애널리틱스는 머신 러닝과 데이터 분석을 통해 사용자 행동의 비정상과 패턴을 식별하는 보안 접근 방식입니다. 이 접근 방식은 내부자 위협, 계정 탈취, 사기 등의 보안 위협을 탐지하고 예방하는 데 사용됩니다. 

API가 점점 더 널리 사용되고 사이버 범죄자의 표적이 되고 있기에, 행동 애널리틱스는 API 보안 분야에서 나날이 중요해지고 있습니다.

기업에서는 애플리케이션이 서로 통신하고 데이터를 공유하며 다양한 기능을 수행할 수 있도록 하기 위해 API를 사용합니다. 하지만 API의 사용 범위가 넓어지면서 관련된 보안 리스크도 늘어나고 있습니다. 

API는 무단 접속, 서비스 거부 공격, 인젝션 공격 등 다양한 보안 위협에 취약할 수 있습니다. 행동 애널리틱스는 사용자 행동을 분석하고 공격을 나타낼 수 있는 비정상적인 패턴을 식별해 이러한 위협을 탐지하는 데 도움이 될 수 있습니다.

행동 애널리틱스 는 API가 민감한 데이터에 무단으로 접속하거나 비즈니스 운영을 방해하려는 사이버 범죄자의 표적이 될 수 있기 때문에 API 보안에서 빼놓을 수 없는 구성요소입니다. 행동 애널리틱스는 사용자 행동을 분석하고 공격을 나타낼 수 있는 비정상적인 패턴을 식별해 이러한 위협을 탐지하는 데 도움이 될 수 있습니다.

행동 애널리틱스를 통합하는 API 보안 솔루션은 다음과 같은 공격을 식별하고 방지하는 데 도움이 될 수 있습니다.

계정 탈취: 계정 탈취는 공격자가 정상적인 사용자의 계정에 접속해 민감한 데이터에 접속하거나 악성 작업을 수행할 때 발생합니다. 행동 애널리틱스는 사용자 행동을 분석하고 공격자가 사용자 계정에 접속했음을 나타내는 비정상적인 패턴을 식별해 계정의 감염 여부를 탐지하는 데 도움이 될 수 있습니다.

내부자 위협: 내부자 위협은 API에 대한 접속 권한이 있는 신뢰할 수 있는 사용자가 악의적인 목적으로 접속 권한을 사용할 때 발생합니다. 행동 애널리틱스는 사용자 행동을 분석하고 사용자가 의심스럽거나 악의적인 행동을 하고 있음을 나타낼 수 있는 비정상적인 패턴을 식별해 내부자 위협을 탐지하는 데 도움이 될 수 있습니다.

인젝션 공격: 인젝션 공격은 공격자가 취약점을 악용하고 민감한 데이터에 무단으로 접속하기 위해 악성 코드나 명령을 API 요청에 심을 때 발생합니다. 행동 애널리틱스는 사용자 행동을 분석하고 API 취약점을 악용하려는 공격자의 의도를 나타낼 수 있는 비정상적인 패턴을 식별해 인젝션 공격을 탐지하는 데 도움이 될 수 있습니다.

DoS 공격: Denial-of-Service(DoS) 공격은 공격자가 비즈니스 운영을 방해하기 위해 요청으로 API를 과부하시킬 때 발생합니다. 행동 애널리틱스는 사용자 행동을 분석하고 API에 요청을 폭증시키려는 공격자의 의도를 나타낼 수 있는 비정상적인 패턴을 식별해 DoS 공격을 탐지하는 데 도움이 될 수 있습니다.

API가 점점 더 널리 사용되고 사이버 범죄자의 표적이 되고 있기 때문에, 기업은 행동 애널리틱스를 통합하는 강력한 API 보안 솔루션에 투자해 민감한 데이터와 지적 재산을 보호해야 합니다.

매니지드 위협 탐지는 고급 툴과 기술을 사용해 잠재적인 보안 위협이 피해를 입히기 전에 이를 식별하고 방어하는 선제적인 보안 접근 방식입니다. 

매니지드 위협 탐지는 몇몇 API 보안 회사에서 제공하는 서비스의 한 종류로, 써드파티 공급업체가 기업으로부터 비용을 받고 위협 탐지를 대신 관리 및 수행하는 서비스입니다. 이 서비스를 통해 기업은 자체 내부 위협 탐지 기능에 투자할 필요 없이 전문 보안팀의 전문 지식과 리소스를 활용할 수 있습니다.

매니지드 위협 탐지의 매니지드 구성요소는 기업으로부터 비용을 받은 API 보안 회사가 위협을 탐지하는 것입니다. 여기에는 API 보안 회사가 기업의 API 인프라에 대한 사전 모니터링을 수행하고, 로그 및 기타 데이터 소스를 분석하고, 머신 러닝 및 행동 애널리틱스와 같은 고급 기술을 사용해 잠재적인 보안 위협을 식별하는 작업이 포함됩니다. 

그런 다음 API 보안 회사는 기업과 협력해 식별된 위협을 해결하고 보안 체계를 개선하기 위한 권장 사항을 제시합니다.

API는 인젝션 공격, 계정 탈취, DoS 공격 등 다양한 보안 위협에 취약할 수 있기 때문에 매니지드 위협 탐지는 API 보안의 맥락에서 특히 중요합니다. 

매니지드 위협 탐지는 이러한 위협이 피해를 주기 전에 식별하고 방어해 기업이 민감한 데이터와 지적 재산을 보호할 수 있도록 도와줍니다.

매니지드 위협 탐지의 주요 구성요소는 다음과 같습니다.

• 선제적인 모니터링 및 조사: 매니지드 위협 탐지는 잠재적인 보안 위협을 식별하기 위해 기업의 API를 선제적으로 모니터링하는 작업을 포함합니다. 여기에는 시스템 로그 및 기타 데이터 소스를 포함한 모든 API 활동 데이터의 모니터링 또는 탐지된 알림의 조사가 포함될 수 있습니다.
• 과거 API 데이터 저장: 조사 및 위협 탐지를 수행할 수 있도록 모든 API 데이터를 저장해야 합니다. 데이터에 접속할 수 있어야 매니지드 위협 탐지를 수행할 수 있습니다.
• 고급 탐지 기법: 매니지드 위협 탐지는 머신 러닝 및 행동 애널리틱스와 같은 기술을 활용한 고급 기법을 바탕으로 잠재적인 보안 위협을 식별합니다. 이러한 기법은 기존의 시그니처 기반 접근 방식으로는 탐지할 수 없는 위협을 식별하는 데 도움이 될 수 있습니다.
• 위협 탐지팀: 매니지드 위협 탐지에는 잠재적 보안 위협을 식별하고 방어하는 데 숙련되고 경험이 풍부한 보안 전문가로 구성된 전담 팀이 참여합니다. 서비스를 제공하는 API 보안 회사는 일반적으로 API 보안 위협에 대한 전문 지식을 갖춘 전문가 팀을 보유하고 있습니다.
• 해결 및 권장 사항: 매니지드 위협 탐지는 식별된 위협을 해결하고 보안 체계를 개선하기 위한 권장 사항을 제시하고자 기업과 협력하는 작업을 포함합니다. 여기에는 취약점 패치, 접속 제어 개선, 기타 보안 제어를 WAF, CDN 또는 기타 프록시와 같은 다른 툴에 구축하는 작업이 포함될 수 있습니다.

API 보안의 맥락에서 매니지드 위협 탐지는 인젝션 공격, 계정 탈취, DoS 공격 등 다양한 위협을 식별하고 방어하는 데 도움이 될 수 있습니다. 

기업은 매니지드 위협 탐지에 투자해 다양한 보안 위협으로부터 API를 안전하게 보호할 수 있습니다.