최신 인터넷의 대부분은 API에 의존하여 작동합니다. API 보안은 공격과 데이터 유출로부터 API를 보호하는 프로세스입니다.
이 글을 읽은 후에 다음을 할 수 있습니다:
관련 콘텐츠
인터넷에서 가장 인기 있는 인사이트를 한 달에 한 번 정리하는 Cloudflare의 월간 요약본 theNET를 구독하세요!
글 링크 복사
애플리케이션 프로그래밍 인터페이스(API)는 한 소프트웨어가 다른 소프트웨어와 상호 작용하는 방법입니다. 프로그램이나 애플리케이션에 API가 있는 경우 외부 클라이언트가 해당 프로그램이나 애플리케이션에 서비스를 요청할 수 있습니다.
API 보안은 API를 공격으로부터 보호하는 프로세스입니다. 애플리케이션, 네트워크, 서버가 공격 대상이 될 수 있는 것처럼, API 역시 다양한 위협의 희생양이 될 수 있습니다.
API 보안은 웹 애플리케이션 보안의 핵심 구성 요소입니다. 대부분의 최신 웹 애플리케이션은 API에 의존하여 작동하며, API는 외부 사용자가 애플리케이션에 액세스할 수 있도록 허용함으로써 애플리케이션에 추가적인 위험을 초래합니다. 사무실을 일반인에게 개방하는 기업의 경우에 비유해볼 수 있습니다. 기업 직원에게 잘 알려지지 않은 사람이 더 많이 구내에 들어오게 되면 더 큰 위험이 초래될 수 있습니다. 마찬가지로 API를 사용하면 외부인이 프로그램을 사용할 수 있으므로 API 서비스 인프라에 더 많은 위험이 발생할 수 있습니다.
API 보안 전략은 이러한 위험과 기타 위험을 완화하는 데 도움이 될 수 있습니다.
강력한 인증 및 권한 부여 조치를 사용하면 데이터 유출이 방지되고 권한이 있는 클라이언트만 API 요청을 할 수 있도록 하는 데 도움이 됩니다. DDoS 보호 및 레이트 리미팅을 통해 DDoS 공격을 차단할 수 있습니다. 스키마 유효성 검사 및 웹 애플리케이션 방화벽(WAF)을 사용하면 취약점 익스플로잇을 차단할 수 있습니다.
레이트 리미팅은 특정 시간 내에 특정 작업을 반복할 수 있는 횟수에 제한을 두는 기능입니다.API 클라이언트가 허용된 요청 수를 초과하는 경우, 레이트 리미팅은 일정 기간 동안 해당 클라이언트의 추가 요청을 삭제하거나 차단합니다.
DDoS 완화는 DoS 및 DDoS 공격을 차단하는 데 도움이 됩니다.DDoS 공격에서 공격자는 짧은 시간 내에 많은 요청으로 API를 압도하려고 시도합니다.이러한 요청은 여러 출처에서 오는 경우가 많습니다.
레이트 리미팅 및 DDoS 완화는 몇 가지 이유로 API에 매우 중요합니다.
취약점 익스플로잇이 작동하려면 취약점 익스플로잇 때문에 설계자가 의도하지 않은 방식으로 API가 응답하게 만드는 방식으로 악의적인 API 요청이 구조화되어야 합니다. API 개발자가 이러한 악의적인 요청을 차단할 수 있는 방법은 여러 가지가 있습니다. 알아야 할 가장 중요한 두 가지 사항은 다음과 같습니다.
API의 스키마는 API의 예상 동작, 즉 API가 받아야 하는 요청의 종류와 제공해야 하는 응답의 종류를 설명합니다. 이 스키마를 준수하지 않는 잘못된 요청으로 인해 API가 예기치 않은 방식으로 작동하면 잠재적으로 데이터 유출이 발생할 수 있습니다. 스키마 유효성 검사는 잘못된 요청과 응답을 식별합니다. API 개발자는 유효하지 않은 응답을 차단함으로써 일부 유형의 공격을 피하고 데이터 유출을 방지할 수 있습니다.
WAF는 일부 네트워크 요청과 응답을 차단하고 다른 요청과 응답은 허용한다는 점에서 기존의 방화벽과 유사하게 작동합니다. 요청이나 응답이 규칙을 위반하거나 규칙에 부합하지 않는 경우 차단되는 일련의 규칙을 기반으로 합니다. WAF는 API 또는 웹 애플리케이션 앞에 배포되며 HTTP 트래픽을 모니터링합니다.
취약점을 대상으로 하는 요청 및 응답 패턴을 차단하는 WAF 규칙을 설정할 수 있습니다.또한 WAF 규칙은 특정 IP 주소로부터의 요청을 차단하여 봇 공격 및 기타 공격자를 차단하도록 지원할 수 있습니다.
인증은 API 요청이 합법적인 출처에서 온 것임을 보장합니다. 권한 부여는 요청하는 클라이언트가 요청된 데이터를 획득할 권한이 있는지 API 서버에 알려줍니다.
Alice가 API를 구축하고 Bob이 Alice의 API를 사용하는 웹 애플리케이션을 구축한다고 가정해 보겠습니다. Bob의 애플리케이션에서 Alice의 API에 API 요청을 보낼 때, Bob은 요청에 "Bob이 보낸 요청임" 이라는 레이블을 첨부합니다. 이에 따라 Bob의 요청이 인증되어 Alice의 API 서버에서 요청이 합법적인 것으로 처리됩니다.
Alice의 API 서버에서는 또한 Bob이 어떤 권한을 가지고 있는지 확인합니다. Bob의 요청이 Alice의 API에서 "Bob이 이 데이터를 볼 수 있음"라는 레이블이 첨부된 데이터에 대한 요청이라면 서버에서 요청을 처리합니다. 그러나 Alice의 API에는 "Bob을 위한 것이 아님"이라는 레이블이 지정된 데이터 섹션이 있을 수 있으며, Bob이 요청자인 경우 서버에서는 해당 데이터에 대한 요청을 처리해서는 안 됩니다. 이것이 인증이 중요한 이유입니다.
(실제로는 Bob은 API 요청에 "Bob이 보낸 것임."이라는 레이블이 아니라 키나 다른 형태의 인증을 첨부합니다.)
API에는 여러 가지 인증 방법이 있습니다. 가장 일반적인 방법은 다음과 같습니다.
클라이언트에게는 자신과 API 서비스만 알고 있는 고유한 문자열인 키가 할당됩니다. 그 키는 각 API 요청에 첨부됩니다. API 서버에서는 API 요청을 받을 때 키를 확인하여 인증된 클라이언트로부터 온 요청인지 확인합니다.
이 인증 방법의 단점은 키를 도난당하면 공격자가 이 키를 사용하여 합법적인 클라이언트로 가장한 후 다양한 공격을 수행할 수 있다는 점입니다. 전송 계층 보안(TLS)과 같은 암호화 프로토콜을 사용하여 API와의 요청 및 응답을 암호화하는 것이 중요합니다. 이렇게 하면 키가 인터넷을 통과할 때 일반 텍스트로 노출되지 않습니다.
API 요청은 HTTP 인증이라는 방법을 통해 일반적인 사용자 이름과 비밀번호 자격 증명을 인증에 사용할 수 있습니다. HTTP 인증에서는 사용자 이름과 비밀번호가 인코딩되어 모든 API 요청에 대한 HTTP 헤더에 추가됩니다. 서버에서는 이러한 자격 증명을 허용된 클라이언트의 자격 증명과 대조하여 요청을 인증할 수 있습니다.
이러한 접근 방식에는 비밀번호 분실, 유출, 도난, 추측, 신뢰할 수 없는 상대방과의 공유 등 일반적으로 비밀번호와 관련된 모든 문제가 수반됩니다. 또한 비밀번호는 자격 증명 스터핑 및 무차별 대입 공격 등에 노출될 수 있습니다.
API 서버는 클라이언트로부터 직접 인증을 요청하는 대신 OAuth 프로토콜을 사용하여 신뢰할 수 있는 인증 서버로부터 인증 토큰을 받을 수 있습니다. 사용자는 API를 사용하기 위해 API에 직접 로그인하는 대신 타사 서비스에 로그인합니다. 사용자 이름 및 비밀번호 방식과 마찬가지로 이 인증 방식도 자격 증명 스터핑 및 기타 공격에 취약합니다.
TLS는 웹 페이지를 로드할 때 클라이언트와 서버 간에 암호화된 인증 연결을 생성하는 암호화 프로토콜입니다. 또한 TLS는 API 연결의 양쪽 끝을 모두 확인하고 인증할 수 있습니다.
상호 TLS(mTLS)에서 클라이언트와 서버는 모두 TLS 인증서를 가지고 있습니다.이 인증서를 사용하여 서로를 인증하므로 비밀번호나 기타 인증 방법에 의존할 필요 없이 양측 모두 당사자가 맞는지 확인할 수 있습니다.
하지만 mTLS는 구현하기가 어려울 수 있습니다. 모든 API 엔드포인트와 클라이언트에는 합법적인 TLS 인증서가 필요하며, 이는 시행 및 유지 관리가 어려울 수 있습니다.
Cloudflare API Shield는 일반적인 API 보안 위험으로부터 보호하기 위해 하나의 대시보드에서 여러 API 보안 기능을 사용할 수 있습니다. API Shield에는 다음이 포함됩니다.
API Shield 또는 API 보안 솔루션에 대해 자세히 알아보세요.
API 보안은 공격과 데이터 유출로부터 API를 보호하는 프로세스입니다. 이를 통해 의도된 사용자만 API를 통해 특정 서비스와 데이터에 액세스할 수 있으며, API를 압도하거나 오프라인 상태로 만들려는 공격에도 불구하고 API가 계속 작동하도록 합니다. 레이트 리미팅, DDoS 완화, WAF 규칙, 스키마 유효성 검사, 강력한 인증 관행은 모두 API를 보호하는 데 도움이 될 수 있습니다.
인증은 API 사용자의 신원을 확인하고, 권한 부여는 사용자가 액세스할 수 있는 데이터나 서비스를 결정합니다. 이들은 함께 사용되어 무단 데이터 액세스를 방지하는 데 기여합니다.
일반적인 API 보안 위험에는 합법적인 사용자에 대한 API 서비스를 방해할 수 있는 취약점 익스플로잇, 인증 기반 공격, 권한 부여 오류, 서비스 거부(DoS/DDoS) 공격이 있습니다.
레이트 리미팅은 정해진 기간 동안 API 사용 횟수를 제한하고, DDoS 완화는 대량의 악의적인 요청을 흡수하거나 차단하는 데 기여합니다. 이들은 모두 인증된 사용자가 API를 계속 사용할 수 있도록 지원합니다.
스키마 유효성 검사는 API의 예상 형식과 일치하지 않는 요청을 차단합니다. 이렇게 하면 API가 사용자 요청에 대한 응답으로 예상치 못한 방식으로 작동할 가능성이 줄어듭니다. WAF는 규칙을 사용하여 악의적이거나 의심스러운 API 호출이 API에 도달하기 전에 차단합니다.
API는 API 키, 사용자 이름/비밀번호 조합, OAuth 토큰, mutual TLS(mTLS)를 사용하여 사용자를 확인합니다.
OWASP API 보안 상위 10대 목록은 보안 가이드라인과 일반적인 API 취약점 목록을 제공하므로 API 개발자가 가장 중요한 보안 위험을 이해하고 해결하는 데 도움이 됩니다.
Transport Layer Security(TLS)와 같은 암호화 프로토콜은 전송 중인 API 데이터를 보호하여 공격자가 자격 증명이나 중요한 정보를 탈취하는 것을 방지합니다. API가 인증을 위해 API 키를 발급하는 경우, 이는 특히 중요합니다. API 키가 전송 중에 암호화되지 않으면, 공격자가 이를 복사하여 기밀 데이터에 접근할 수 있습니다. 또한 공격자가 합법적인 사용자를 가장하는 것을 방지하기 위해 인증에 mutual TLS(mTLS)가 사용되는 경우도 있습니다.
zero-day 위협은 이전에 알려지지 않았던 API의 취약점을 악용하는 공격입니다. zero-day 위협은 특히 감지하고 차단하기가 어렵습니다.