API 보안이란 무엇인가요?

API 보안은 민감한 데이터를 훔치거나 서비스를 방해하기 위해 악의적으로 API를 사용하거나 악용하려는 공격으로부터 애플리케이션 프로그래밍 인터페이스(API)를 보호하는 관행입니다. API 보안은 전략, 기술 및 솔루션을 사용하여 권한이 부여된 사용자만 API에 액세스하고 사용할 수 있도록 하고 API를 통해 전송되는 데이터가 무단 액세스 또는 조작으로부터 보호되도록 합니다.

API 보안 설명

API는 시스템 및 서비스의 백엔드 프레임워크 역할을 하므로 인증, 권한 부여, 입력 유효성 검사 및 암호화와 같은 액세스 정보를 포함하여 전송하는 민감한 데이터를 보호하기 위해 API를 보호하는 것이 중요합니다. API 보안은 이러한 백엔드 프레임워크를 보호하고 액세스 위반, 봇 공격 및 남용으로부터 공격을 완화하도록 설계된 방법과 도구를 말합니다.

일반적인 API 공격 유형

• Denial-of-Service(DOS) 공격
• 분산 서비스 거부(DDoS) 공격
• 중간자(MITM) 공격
• 취약한 액세스 제어 공격
• 주입

API 공격이 성공하면 대량의 데이터 손실, 개인 정보 또는 개인정보 도난, 서비스 중단이 발생할 수 있습니다.

API의 정의

API는 애플리케이션 프로그래밍 인터페이스의 약자로, 소프트웨어 구성 요소가 통신할 수 있도록 하는 일련의 정의와 프로토콜로 구성되어 있습니다. 소프트웨어 시스템 간의 중개자 역할을 하는 API는 소프트웨어 애플리케이션이나 서비스가 데이터와 기능을 공유할 수 있도록 합니다. 하지만 API는 연결 인프라를 제공하는 것 이상의 역할을 합니다. 또한 소프트웨어 애플리케이션의 통신 및 상호 작용이 허용되는 방식도 관리합니다. API는 프로그램 간에 교환되는 요청 유형, 요청 방법, 허용되는 데이터 형식을 제어합니다.

조직은 API를 통해 고객 및 기타 외부 사용자와 데이터를 공유할 수 있습니다. API 유형에는 결제 처리, 화상 회의, 소셜 미디어, 문자 메시지, 의료 또는 피트니스 모니터링, 스마트 홈에 사용되는 API가 포함됩니다. API는 개방형 또는 폐쇄형, 공개형 또는 비공개형일 수 있으며 일반적으로 REST, SOAP 또는 GraphQL과 같은 아키텍처 표준을 준수합니다.

또한 API는 개발자가 다른 애플리케이션의 기능에 액세스할 수 있도록 하여 새로운 연결 인프라를 반복적으로 구축하거나 기본 코드 또는 아키텍처를 이해할 필요성을 덜어주므로 개발자에게도 도움이 됩니다.

그림 1: 최신 애플리케이션 구조

API 보안이 중요한 이유

앱은 비즈니스와 사회에서 없어서는 안 될 필수 요소입니다. 그리고 거의 모든 앱의 배후에는 API가 있으므로 API 보안은 미션 크리티컬한 수준으로 향상됩니다.

API는 내부, 파트너 대면 및 고객 대면 애플리케이션은 물론 모바일 앱, 웹 애플리케이션, SaaS를 포함한 대부분의 클라우드 네이티브 애플리케이션의 백엔드 프레임워크 역할을 합니다. API 사용 현황을 살펴보면, API 관리 플랫폼인 Postman은 2022년에 11억 3천만 건의 API 호출을 기록했습니다. 물론 API의 부상과 함께 악의적인 공격자들을 유인하는 잠재적으로 수익성이 높은 공격 표면이 등장했습니다.

API는 애플리케이션 로직, 리소스 및 개인 식별 정보(PII)를 포함한 민감한 데이터를 노출하기 때문에 공격자의 표적이 되고 있습니다. 공격자가 보호되지 않은 API에 액세스할 수 있으면 비즈니스를 방해하고, 민감한 데이터에 액세스하거나 파괴하고, 재산을 훔칠 수 있습니다.

그림 2: API를 활용하는 최신 마이크로서비스 애플리케이션

웹 애플리케이션 보안에 대한 기존의 접근 방식

모놀리스 애플리케이션 시대의 웹 애플리케이션 보안은 웹 클라이언트가 전송하는 HTTP 트래픽을 가로채고 검사하기 위해 경계에 웹 애플리케이션 방화벽(WAF) 을 구축하는 것으로 구성되었습니다. WAF는 애플리케이션에 대한 잠재적 위험이 주로 표준 HTTP 웹 양식 제출 또는 브라우저 요청에 포함된 악의적인 사용자 입력과 관련된 경우 효과적인 애플리케이션 보안을 제공했으며, 앞으로도 지속적으로 제공할 것입니다.

그러나 웹 애플리케이션의 특성은 개별 웹 서버에서 호스팅되는 모놀리식 애플리케이션에서 호스트 서버 클러스터에 분산된 컨테이너화된 클라우드 네이티브 애플리케이션으로 바뀌었습니다.

고도로 분산된 클라우드 네이티브 마이크로서비스 아키텍처를 다루는 오늘날의 개발자와 보안 팀은 경계가 없는 네트워크와 싸워야 합니다. 최신 앱은 표준 웹 요청, 모바일 디바이스 API 호출, 클라우드 이벤트, IoT 디바이스 원격 측정 통신, 클라우드 스토리지 등 광범위한 소스로부터 입력을 사용합니다.

클라이언트 인바운드 HTTP 요청(즉, 북-남 트래픽)은 일련의 통신 흐름에서 가장 먼저 발생하는 경우가 많습니다. 많은 경우, 하나의 인바운드 요청이 수십 개의 내부 API 호출(즉, 동서 트래픽)을 생성합니다. 내부 API 호출을 제대로 검사하고 유효성을 검사하지 않으면 API 엔드포인트가 보호되지 않은 채로 남게 됩니다.

경계에서 입력을 검사하는 것만으로는 위험한 페이로드를 잡을 수 없습니다. 내부 API 엔드포인트가 잘못 구성되어 개별 마이크로서비스에 대한 무단 액세스를 허용하여 애플리케이션 로직이 악의적인 동작에 노출될 수 있습니다. 외부 및 내부의 모든 API 엔드포인트를 지속적으로 모니터링하고 보안을 유지하는 것이 중요합니다.

비디오: API 보안 개요 및 API 보안 강화를 위한 팁

API 공격의 해부학

조직이 비즈니스를 추진하기 위해 API에 의존함에 따라 공격자들은 API 결함을 악용할 수 있는 기회를 노리고 있습니다. 모바일 애플리케이션을 프론트엔드로 사용하는 이커머스 애플리케이션을 표적으로 삼은 API 공격의 예는 위협 행위자가 얼마나 쉽게 중요한 데이터에 침입할 수 있는지를 보여줍니다.

그림 3: API 기반 공격의 구조

1단계: 공격자는 모바일 앱을 리버스 엔지니어링하여 백엔드 마이크로서비스에서 데이터를 검색하는 데 사용되는 더 이상 사용되지 않는 API 엔드포인트 URL을 발견합니다.

2단계: 공격자는 이 엔드포인트로 API 호출을 전송하는 데 인증이나 권한 부여가 필요하지 않다는 것을 알 수 있습니다.

3단계: 공격자는 SQLi 취약점을 악용합니다. API 엔드포인트 URL은 숫자 값 형태의 고유한 제품 식별자를 제공하며, 공격자는 일련의 자동화된 검사를 실행하여 입력 필드가 성공적인 SQLi 공격을 수행하는 데 활용될 수 있는지 확인합니다.

4단계: 공격자는 데이터 변조를 위해 이 SQLi 취약점을 악용하는 대신 SQL 데이터베이스를 실행하는 마이크로서비스에서 셸 명령을 실행합니다. 셸 명령은 악성 실행 파일을 다운로드하여 실행합니다. 실행 파일은 비트코인 채굴 소프트웨어입니다.

API 보안 위험

API의 잘못된 구성, 논리 결함 및 취약성으로 인해 애플리케이션과 데이터가 공격자에게 노출될 수 있습니다. API 게이트웨이는 게이트웨이를 통해 라우팅되는 API 트래픽만 볼 수 있고 내부 트래픽에 대한 가시성을 제공하지 않지만, 일부 조직에서는 API 게이트웨이가 완전한 API 보호를 제공한다고 믿고 API 보안을 API 게이트웨이에 맡기기도 합니다.

보안 팀은 API 표면 전체에 대한 가시성이 필요합니다. 보이지 않는 것은 보호할 수 없으며, 보이지 않는 것은 결국 섀도 API를 발견한 악의적인 공격자의 탐지되지 않은 활동이 됩니다.

API 게이트웨이는 API와 API 사용을 효과적으로 모니터링하지만 공격을 탐지하고 차단할 수는 없습니다. API 보안에는 가시성 및 위험 관리 외에도 악의적인 공격에 대한 실시간 보호가 필요합니다.

OWASP 상위 10

오픈 웹 애플리케이션 보안 프로젝트(OWASP)는 최신 웹 애플리케이션에 영향을 미치는 API 보안 위험에 대한 인식을 높이기 위해 2019년에 상위 10가지 API 보안 위험 목록을 발표했습니다. 이 목록에는 웹 API에 대한 가장 일반적인 공격에 대한 개요와 이러한 위협으로부터 API를 보호하기 위한 팁이 포함되어 있습니다.

깨진 개체 수준 권한 부여

객체 식별자를 처리하는 엔드포인트는 API에 의해 자주 노출되기 때문에 공격 표면을 넓히는 수준의 접근 제어 문제가 발생합니다. 예를 들어 적절한 권한 확인이 구현되지 않은 경우 공격자는 API 호출 중에 다른 사용자가 소유한 리소스의 ID를 대체할 수 있습니다. 안전하지 않은 직접 객체 참조(IDOR) 공격으로 알려진 이 공격은 공격자가 액세스 권한이 없는 리소스에 액세스할 수 있게 합니다.

깨진 사용자 인증

API 인증 메커니즘은 모든 사람에게 노출되기 때문에 쉽게 공격 대상이 될 수 있습니다. API 인증 취약점이라고 하는 제대로 구현되지 않은 인증 메커니즘은 구현 결함을 악용하여 권한이 있는 사용자의 신원을 추정할 수 있는 공격자에게 침입의 기회를 제공합니다.

액세스 토큰 유효성 검사를 구현하지 않거나 API 엔드포인트 URL에 자격 증명 및 키를 저장하지 않는 등 업계 모범 사례를 우회할 때 API 인증의 잘못된 구성이 발생할 수 있습니다.

과도한 데이터 노출

노출되는 데이터가 많을수록 위험도 커집니다. API를 구현하는 과정에서 개발자는 항목별 제한 없이 객체 속성을 노출하고 클라이언트에 의존하여 불필요한 데이터를 필터링한 후 UI에 표시하는 경우가 있습니다. 그러나 API 클라이언트가 민감한 데이터를 필터링하더라도 공격자는 초기 API 호출을 악용하여 신용카드 번호, 로그인 인증 정보 및 주민등록번호에 액세스할 수 있습니다.

리소스 부족 및 속도 제한

클라이언트가 호출할 수 있는 리소스 수를 제한하지 않는 API는 트래픽 과부하를 통한 API 악용에 취약합니다. 이러한 유형의 과부하는 API 서버의 성능을 저하시켜 합법적인 사용자를 차단하고 DoS를 유발할 수 있습니다. 또한 API 서버 과부하는 무차별 대입과 같은 인증 결함에 API를 노출시킵니다.

깨진 기능 수준 권한 부여

API 개발자가 직면하는 어려움 중 하나는 다양한 계층의 사용자 그룹과 역할에 대한 접근 제어 정책을 구현하는 것이 복잡하다는 것입니다. 관리 기능과 일반 기능의 구분이 모호하면 공격자가 사용자의 리소스에 액세스하거나 권한이 없는 관리 기능을 수행하는 데 악용할 수 있는 권한 부여 결함이 발생합니다.

대량 할당

대량 할당 취약점은 클라이언트가 제공한 데이터가 화이트리스트에 대해 필터링되지 않고 데이터 모델에 바인딩되어 사용자가 보호된 필드에 데이터를 할당할 수 없을 때 발생합니다. 이 취약점을 통해 공격자는 API 쿼리를 가로채고, 개체 속성을 추측하여 저장된 백엔드 개체의 속성을 변경하고, 문서를 읽고, API 엔드포인트에서 비공개 API의 데이터 속성을 손상시키는 방법에 대한 힌트를 검색하여 민감한 데이터에 액세스할 수 있습니다.

잘못된 보안 구성

보안 구성이 잘못되면 민감한 사용자 정보 및 시스템 세부 정보가 노출되어 서버가 손상될 수 있습니다. 일반적인 원인으로는 허용된 CORS(교차 출처 리소스 공유), 불완전하거나 임시 구성, 잘못된 HTTP 헤더 또는 HTTP 메서드, 안전하지 않은 기본 구성, 불완전하거나 잘못된 구성, 민감한 정보를 노출하는 자세한 오류 메시지 등이 있습니다.

주입

API는 명령이나 쿼리의 일부로 신뢰할 수 없는 데이터가 인터프리터로 전송될 때 발생할 수 있는 SQL 인젝션, NoSQL 인젝션 및 명령 인젝션과 같은 인젝션 취약점의 영향을 받습니다. 공격자는 인터프리터를 속여 위험한 명령을 실행하도록 하여 승인되지 않은 데이터를 노출시켜 조작 및 도용할 수 있습니다.

부적절한 자산 관리

API는 기존 웹 애플리케이션보다 더 많은 엔드포인트를 노출하며, 노출된 민감하거나 취약한 API 엔드포인트의 API 남용을 방지하려면 이러한 엔드포인트를 추적하는 강력한 API 관리가 필수적입니다. 예를 들어 더 이상 사용되지 않는 API 엔드포인트 또는 디버그 엔드포인트는 공격자가 애플리케이션을 손상시키는 데 사용할 수 있습니다.

불충분한 로깅 및 모니터링

부적절한 로깅 및 모니터링은 직접적인 위협은 아니지만 악성 활동의 탐지를 지연시킵니다. 악의적인 공격자들은 어둠 속에서 충분한 시간을 갖고 공격을 진행하고 다른 시스템으로 이동하여 데이터를 변경, 추출 및 파괴합니다. 침해 연구에 따르면 지속적인 위협을 탐지하는 데 200일 이상 걸릴 수 있습니다. 또한 데이터 유출이 발생한 후 적절한 로깅과 모니터링이 없으면 조직은 피해를 평가할 수 있는 포렌식 정보가 부족합니다.

비디오: OWASP, AppSec 및 OWASP 상위 10대 애플리케이션 보안 위험에 대해 알아보기

SOAP, REST 및 GraphQL용 API 보안

SOAP, Rest API 및 GraphQL은 세 가지 일반적인 API 아키텍처 패턴이며, 각 API 아키텍처 스타일은 고유한 보안 고려 사항을 제시합니다.

SOAP API 보안

SOAP(간단한 객체 액세스 프로토콜)는 컴퓨터 네트워크에서 웹 서비스를 구현할 때 구조화된 데이터를 교환하기 위한 프로토콜입니다. SOAP는 XML을 메시지 형식으로 사용하며 HTTP 및 SMTP를 비롯한 다양한 하위 수준 프로토콜을 통해 전달할 수 있습니다. SOAP API는 일반적으로 전송 계층 보안(예: HTTPS)과 메시지 수준 보안(예: XML 디지털 서명 및 암호화)을 조합하여 보안을 유지합니다.

SOAP API 보안에는 보안 문제를 처리하기 위한 프로토콜 확장이 포함됩니다. SOAP는 웹 서비스(WS) 사양을 준수하며, 기본 제공 오류 처리 지원을 확장하는 WS-ReliableMessaging과 같은 기능을 통해 모든 웹 서비스에 대한 엔터프라이즈급 보안을 보장합니다.

Rest API 보안

표현 상태 전송 API 또는 REST API의 아키텍처는 JSON 데이터 전송과 HTTP/S 전송 프로토콜에 의존하며, 두 가지 모두 다른 API 아키텍처에 비해 REST API 개발을 간소화합니다. Rest API는 HTTP 요청을 사용하여 데이터를 POST(생성), PUT(업데이트), GET(읽기), DELETE(삭제)합니다.

기본 제공 보안 프로비저닝이 부족하기 때문에 Rest API 보안은 API 설계에 달려 있습니다. 데이터 전송, 구축 및 클라이언트 상호 작용 서비스는 보안 고려 사항을 통합해야 합니다. 대부분의 Rest API는 전송 계층 보안(예: HTTPS) 및 토큰 기반 인증에 의존합니다.

REST API 보안을 해결하기 위한 일반적인 아키텍처 선택은 API 게이트웨이 뒤에 REST API를 구축한 다음 이 연결 옵션을 클라이언트에 제공하는 것입니다. 하지만 API 게이트웨이는 다양한 보안 위협을 방어할 수 있는 기능을 갖추고 있지 않습니다.

휴식 대 비누

SOAP 및 Restful API는 HTTP 요청 및 응답과 SSL(Secure Sockets Layer)을 지원하지만 공통점은 거기서 끝납니다. 보안 기능이 내장된 SOAP API는 본질적으로 안전합니다. 반면에 Restful API는 구현 및 아키텍처 선택을 통해 보안을 유지해야 합니다.

GraphQL API 보안

GraphQL은 클라이언트가 정보를 요청하는 방법을 설명하는 동시에 기존 데이터로 쿼리를 수행하는 런타임 역할을 하는 오픈 소스 API 언어입니다. GraphQL 구문은 개발자가 단일 또는 여러 소스에서 특정 데이터를 요청하는 데 사용됩니다. GraphQL을 사용하면 클라이언트는 요청에 대한 데이터 구조를 정의할 수 있으며, 서버는 정확한 구조가 반환되도록 보장합니다.

GraphQL API 보안을 적용하면 사용자 지정 가능하고 유연한 요청과 관련된 문제가 발생합니다. 서버가 복잡한 쿼리를 처리하지 못할 수 있으며 이 과정에서 실수로 악성 쿼리를 실행할 수 있습니다.

GraphQL API 보안 위험을 완화하는 방법에는 스로틀링과 최대 쿼리 깊이 설정, 대규모 쿼리를 방어하기 위한 쿼리 타임아웃 등이 있습니다.

API 보안 모범 사례

API가 점점 더 많이 공개됨에 따라 공격 표면을 최소화하고 취약점을 수정하며 거의 실시간으로 악의적인 활동을 포착하는 모범 사례를 구현하여 데이터 노출 위험을 해결하는 것이 중요합니다.

보안 인증 및 권한 부여 방법 사용

권한이 있는 사용자만 OAuth2 또는 JSON 웹 토큰(JWT)과 같은 보안 인증 방법을 사용하여 API에 액세스할 수 있도록 하세요.

구현 속도 제한

API에 속도 제한을 구현하여 무차별 대입 공격 및 기타 악의적인 행동을 방지하세요. 속도 제한은 지정된 기간 내에 API에 요청할 수 있는 횟수를 제한합니다.

HTTPS 사용

API 요청과 응답은 암호화되고 안전한지 확인하기 위해 HTTPS를 사용하여 이루어져야 합니다. 이는 민감한 데이터를 다룰 때 특히 중요합니다.

정기적인 보안 평가 수행

API의 보안을 정기적으로 평가하여 잠재적인 취약점을 파악하세요. API 인벤토리의 변경 사항을 검토하여 민감한 데이터 노출, 인터넷 노출, 워크로드 취약성 및 인증 수준 등 새로 노출된 API와 해당 위험 프로필을 감지하세요.

API 키 사용

API 키는 API를 호출하는 애플리케이션을 식별하고 액세스 권한을 확인하는 데 사용되는 고유 식별자입니다. API 키는 애플리케이션(또는 웹사이트)을 사용하는 사람이 아니라 API 호출을 하는 애플리케이션(또는 웹사이트)을 식별한다는 점에서 인증 토큰과 다릅니다. 두 가지 모두 중요한 보안 조치입니다.

원치 않는 호출, 무단 액세스, 개인정보 손실로 인한 잠재적인 데이터 유출을 방지하려면 API 키 저장 모범 사례를 따르세요.

API 모니터링

API 사양, 문서, 테스트 사례, 트래픽 및 메트릭을 관리하고 모니터링하세요. 악성 API 트래픽 및 악성 봇과 같은 원치 않는 활동을 차단하여 애플리케이션을 보호하고 불필요한 비용을 줄일 수 있습니다.

보안 모범 사례에 대해 팀에 교육하기

CI/CD 파이프라인 초기에 보안을 포함시키고 취약한 인증 및 논리적 취약점과 같은 보안 위험에 대한 개발자의 지식을 향상시키기 위한 교육을 제공하세요. 보안 팀과 개발 팀 간의 협업을 포함한 DevSecOps 원칙을 구현하세요.

취약점 파악

정기적으로 OWASP API 보안 상위 10가지 위험을 찾아 API 라이프사이클의 취약점을 파악하세요. API 스캐닝 도구와 기술을 사용하여 각 API 취약점을 식별하고 즉시 해결하여 악용을 방지하세요.

인증을 위한 보안 토큰 요구 사항

인증을 위해 보안 토큰을 요구하는 것은 첫 번째 방어선입니다. 보안 토큰은 사용자 토큰이 인증에 실패할 경우 API 호출을 거부하여 무단 액세스로부터 API를 보호합니다.

요컨대, 모범 사례는 환경 내의 모든 웹 애플리케이션과 API 엔드포인트를 자동으로 검색할 수 있는 공격 표면의 가시성과 모니터링에서 시작해야 합니다. 방어 계층에는 인터넷에서 발생하든 애플리케이션 내에서 발생하든 악성 위협을 차단하기 위해 남북 및 동서 트래픽에 대한 정책이 포함되어야 합니다.

강력한 인증과 함께 취약성 및 규정 준수 스캔을 한 층 더 추가하면 애플리케이션을 더욱 안전하게 보호할 수 있습니다. 또한 워크로드 또는 애플리케이션 호스팅에 도움이 되는 호스트, VM, 컨테이너 및 서버리스 기능과 같은 인프라 계층을 보호해야 합니다.

Prisma Cloud의 API 보안 솔루션

Prisma Cloud는 포괄적인 클라우드 네이티브 애플리케이션 보호 플랫폼 (CNAPP)의 일부로 모든 API에 대한 완벽한 API 검색, 위험 프로파일링, 실시간 보호 기능을 제공합니다.

API 보안 기능

• API 검색: 사용자 환경의 모든 API를 자동으로 검색하고 섀도 또는 악성 API로 인한 사각지대를 제거하세요.
• API 위험 프로파일링: API 위험 및 위험 요소(잘못된 구성, 민감한 데이터 노출, 액세스 제어 등)를 파악하고 해결 우선순위를 정하세요.
• 실시간 보호: API, 속도 제한 및 악성 봇에 대한 OWASP Top 10 공격에 대한 실시간 보호 기능을 적용하세요.

API 보안 FAQ