최신 인터넷의 대부분은 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 Gateway는 일반적인 API 보안 위험으로부터 보호하기 위해 하나의 대시보드에서 여러 API 보안 기능을 사용할 수 있습니다. API Gateway에는 다음이 포함됩니다.
API Gateway 또는 API 보안 솔루션에 대해 자세히 알아보세요.