새로운 API 위협에 대응하기 위한 3가지 방법
API 중심 세상을 위한 API 중심 보안
API로 연결된 모든 것의 숨은 함정
20여 년 전, Jeff Bezos는 모든 Amazon 팀에게 예외 없이 “서비스 인터페이스를 통해 데이터와 기능을 노출해야 한다”고 선언했습니다. 현재 ‘API 명령’으로 알려진 이 메모는 애플리케이션 프로그래밍 인터페이스(API)가 선택 사항이 아니라는 점을 분명히 했고, 모든 개발자들 사이에서 API를 통해 모든 것을 연결하려는 경쟁을 불러일으켰습니다. 그러나 많은 조직에서 API 배포의 빠른 속도에 비해 API 보안은 뒤처져 있습니다.
최근 발표된 2024 API 보안 및 관리 보고서에 따르면 API 관련 트래픽은 현재 전체 동적 인터넷 트래픽의 대부분(약 57%)을 차지하고 있습니다. 하지만 기업들은 일반적으로 다음과 같은 문제로 인해 어려움을 겪고 있습니다.
보이지 않고 보호되지 않는 공격면: IT 및 보안 팀은 보이지 않는 것을 방어할 수 없으며, 조직에는 IT 또는 보안 팀이 관리하지 않는 API인 ‘섀도우 API’가 있어 데이터 노출, 내부망 이동, 기타 사이버 위험을 초래할 수 있습니다.
과도한 권한 부여: 원래 읽기 전용이어야 하는 API에 ‘쓰기’ 권한이 잘못 부여되면 시스템이 공격에 취약해지고 데이터 손실 가능성이 높아집니다. 약 60%의 조직에서는 최소 절반이 넘는 API에 ‘쓰기’ 접근 권한을 부여합니다.
조직은 API 관련 오류의 원인을 간과하거나 잘못 분류하기 쉬움: 모든 API 오류가 공격으로 인해 발생하는 것은 아니며, API에 대한 모든 공격을 동일한 방식으로 완화할 수 있는 것도 아닙니다. 오류나 취약점을 놓치거나 잘못 진단하면 최종 사용자 경험이 저하되거나 최악의 경우 사이버 공격으로 이어질 수 있습니다.
현재 사용 중인 공개 및 비공개 API는 약 2억 개에 달하며, 그 수는 계속 증가하고 있습니다. 이러한(그리고 향후) API의 기능을 안전하게 활용하기 위해 조직은 다음 3가지 ‘해야 할 일’과 ‘하지 말아야 할 일’을 통합하는 전용 API 관리 접근 방식이 필요합니다.
1) 더욱 효율적인 API 가시성 및 보안 관리를 위해 전용 머신러닝 서비스를 활용하세요.
원활한 모바일 원격 의료부터 AI 지원 기록 처리에 이르기까지 환자와 의료 서비스 공급자가 선호하는 디지털 이니셔티브를 제공하는 Acme 병원이 있다고 가정해 보겠습니다. 어느 날 Acme의 개발자 중 한 명이 적절한 문서화 없이 청구 시스템의 API에 ‘쓰기’ 접근 권한을 부여했습니다. 몇 달 후, 이 벤더는 해킹을 당했고 공격자들은 내부망 이동을 통해 Acme의 공개 API를 악용하여 병원의 환자 기록을 유출할 수 있었습니다.
Acme에 다음과 같은 자동 감지 조치가 마련되어 있었다면 이 시나리오를 더 빨리 감지하고 완화할 수 있었을 것입니다.
모든 공개 API 엔드포인트(승인되지 않은 API 포함) 및 관련 트래픽 확인하기
유효한 API 요청/응답의 사양을 정의하는 메타데이터인 API 스키마 감지하기
API에 대한 공격 변형 감지
시작하기: 머신러닝 모델을 활용하고 IT, 보안, 개발자 간의 수동 ‘특정 시점’ 커뮤니케이션이 필요하지 않은 API 보안 솔루션입니다.
예를 들어, Acme와 같은 조직은 머신 러닝 기반의 API 검색 및 API 스키마 검색을 통해 보다 완벽한 API 인벤토리를 확보할 수 있습니다. 어떤 API가 존재하나요? 어떤 데이터와 시스템에 접근하나요? 접근하는 곳과 시기는 어디인가요? 누가 ‘읽기 전용’ 권한과 ‘쓰기’ 권한을 가지고 있나요?
이러한 유형의 데이터는 섀도우 API의 확산을 방지하는 데 매우 중요합니다. 새로운 고객 기능(주로 인터넷용 API로 처음 노출되는)의 개발 과정에서 API 문서와 보안 ‘모범 사례’는 일반적으로 개발자의 재량에 달려 있습니다. 대부분 보안 팀을 투입할 시간이나 리소스가 부족한 경우가 많습니다.
이는 조직에게 볼 수 없는 것을 보호할 수 없다는 보안 문제를 제기합니다. 실제로 Cloudflare의 머신러닝 모델은 조직이 자체적으로 보고한 것보다 31% 더 많은 API 엔드포인트를 발견했으며, 이는 API의 거의 1/3이 본질적으로 섀도우 API임을 나타냅니다.
코드가 자주 변경되는 동안 해를 끼치지 않고 도입되는 섀도우 API는 본질적으로 악의적이지 않습니다. 하지만 개발자의 86%가 애플리케이션 보안을 우선시하지 않기 때문에 섀도우 API는 가장 큰 위협으로 간주됩니다. 섀도우 API가 악용되면 데이터 노출, 패치되지 않은 취약점, 데이터 규제 준수 위반, 기타 위험을 초래할 수 있습니다. 머신러닝을 통해 이러한 섀도우 API를 어둠 속에서 끌어낼 수 있습니다.
2) API 보안 및 관리를 위해 웹 앱 보안 도구에만 의존하지 마세요.
웹 앱과 API는 근본적으로 다릅니다. 차량 공유 앱은 사용자에게 ‘표시’되지만 앱에 Google 지도 데이터에 대한 접근 권한을 부여하는 API는 ‘표시되지 않습니다.’ 이러한 (그리고 다른) 차이점을 고려할 때, 조직은 API를 보호하기 위해 웹 앱 보안보안과 더불어 특화된 API 보안이 필요합니다.
예를 들어, 기존 웹 애플리케이션 방화벽(WAF)은 차단 목록에 따라 웹 앱과 인터넷 간의 HTTP 트래픽을 필터링하고 모니터링합니다. WAF는 알려진 공격 징후를 감지하고 이를 차단하기 위한 조치를 취합니다. 그 외 다른 트래픽은 허용됩니다. 이는 악성 웹 트래픽을 쉽게 식별하고 차단할 수 있는 웹 앱 보안을 위한 효과적인 ‘소극적’ 보안 모델입니다.
하지만 API를 남용되지 않도록 보호하려면 ‘능동적’ 보안(API 보안)이 필요합니다. ‘나쁜 것으로 알려진’ 요청만 찾는 대신 ‘좋은 것으로 알려진’ 요청을 찾아서 해당 요청만 허용하고 나머지는 전부 차단하세요. 이러한 요청, 즉 API 호출을 정의하는 요소에 대한 자세한 내용은 여기를 참조하세요.
이유는?
1,000만 명에 가까운 고객의 데이터가 유출된 침해 사고를 경험한 호주 통신업체의 사례를 생각해 보세요. 해커는 인증되지 않은 API를 통해 특정 고객 데이터베이스에 접근했습니다. 공격의 구체적인 내용은 알려지지 않았지만, ‘능동적’ API 보안 모델이었다면 해당 회사의 API 사양을 준수하는 API 트래픽만 허용했을 것이라는 점에 주목할 필요가 있습니다.
즉, ‘능동적’ API 보안으로 전환하여 인증된 사용자의 트래픽과 인증된 기업 네트워크 내에서 승인된 작업만 허용하세요. (조직은 WAF의 ‘소극적’ 보안과 API 게이트웨이의 ‘능동적’ 보안을 계층화하여 보안 모델을 결합할 수도 있습니다)
결론: API에는 다음과 같은 6가지 상위 API 위협을 비롯한 다양한 API 위협을 방어하기 위해서 포괄적인 접근 방식이 필요합니다.
출처: 2024년 API 보안 및 관리 보고서
위 차트에서 볼 수 있듯이, 완화된 API 위협의 대부분(60.7%)은 HTTP 이상과 관련이 있습니다. 최종 사용자를 위해 인터넷 콘텐츠를 검색하는 소프트웨어인 사용자 에이전트가 누락되는 등의 HTTP 이상 징후는 악성 요청의 일반적인 지표입니다.
앞서 설명한 대로 ‘능동적’ 보안을 적용하면 조직은 HTTP 이상 징후 및 기타 위협을 식별하고 각 API에 대해 API 서버로 ‘청정’ 트래픽만 허용할 수 있습니다.
3) 앱 개발, 성능, 보안 관리를 통합합니다.
수천 개의 API 지원 자산과 관련된 방대한 공격면을 보호할 책임은 IT, 보안, 앱 개발 팀에 있습니다. 그러나 이러한 팀의 우선 순위는 충돌하는 경우가 많습니다.
개발자의 73%는 보안 팀에서 사용하라고 요구한 작업 또는 도구가 “생산성 및 혁신에 지장을 준다”고 응답했습니다.
CIO의 87%는 “소프트웨어 엔지니어와 개발자가 신제품과 서비스를 더 빨리 시장에 출시하기 위해 보안 정책과 제어 능력을 타협한다”고 생각합니다.
CISO의 절반 가량만이 개발자가 개발 및 워크플로우 도구로 인해 발생하는 보안 위험을 “매우 잘 이해하고 있다”는 인상을 받았습니다.
결과적으로 조직은 더욱 빠른 혁신과 보안 개선 사이에서 ‘성능 저하’를 경험할 수 있으며, 이로 인해 API가 취약해질 수 있습니다. 보고서에 따르면 거의 60%의 조직이 API의 절반 이상에 대해 ‘쓰기’ 접근을 허용하고 있습니다. 그렇다면 권한이 없는 사용자가 ‘쓰기’ 접근 권한을 갖지 못하도록 방지하는 권한을 궁극적으로 ‘소유’하는 주체는 누구일까요?
API를 통해 새로운 서비스를 지속적으로 노출하는 기업의 경우, 클라우드 연결성은 앱 배포와 API 심층 방어 사이의 연결 조직 역할을 할 수 있습니다.
클라우드 연결성은 IT 환경 전반에서 안전한 ‘무제한’ 연결을 간소화하는 클라우드 네이티브 서비스의 통합 플랫폼입니다. 이를 통해 조직에서는 API 트래픽을 포함한 방대한 디지털 도메인에 대한 제어 능력과 가시성을 회복할 수 있습니다.
클라우드 연결성을 통해 조직은 단일 제어판을 사용하여 다음과 같은 작업(과 그 이상)을 처리할 수 있습니다.
API 검색 및 가시성 자동화를 통해 모든 이해관계자에게 API 자산의 명확한 인벤토리 제공
처음부터 API 인증 및 권한 부여 프로세스 최신화
API 엔드포인트 관리로 API 기반 도메인의 대기 시간, 오류 및 오류율, 응답 크기 등의 지표 모니터링
DDoS 공격, 무차별 대입 로그인 시도, 기타 API 악용과 같은 API 애플리케이션 계층(L7) 위협으로부터 보호
시간이 지남에 따라 개선되는 API 보안 성숙도
API 기술이 새로운 것은 아니지만, API 보안을 포괄적으로 다루는 것은 많은 앱 보안 및 앱 개발 팀에게 새로운 과제입니다. 하지만 모든 발전은 어딘가에서 시작되며, 다음과 같은 방법으로 API 보안을 단계적으로 해결할 수 있습니다.
1단계 - 가시성: 먼저 조직에서 사용 중인 API를 모두 파악해 보세요. API 검색 도구를 사용하고, 기술 문서와 계약서를 검토하고, 개발자와 대화하고, 웹 트래픽을 모니터링하세요.
2단계 - 일반 웹 공격 보호: 웹 애플리케이션과 API는 함께 작동하는 경우가 많습니다(예: 결제를 처리하기 위해 API를 사용하는 전자 상거래 웹 사이트). 웹 앱(및 그 배후에 있는 API)을 DoS 및 DDoS 공격, 자격 증명 스터핑, zero-day 취약점, 기타 위협으로부터 보호하려면 직접 설계된 전용 도구를 사용하고 통합하세요.
3단계 - 통합 고급 API 보안: 클라우드 연결성을 기반으로 하는 Cloudflare의 웹 애플리케이션 및 API 보호(WAAP) 포트폴리오는 생산성을 저해하지 않으면서 공개 API에 대한 포괄적인 보안과 성능을 제공합니다. API 검색, 통합 API 관리 및 분석, 계층화된 방어 기능을 통해 Cloudflare는 IT 및 보안 팀이 API에 대한 가시성과 제어를 확보할 수 있도록 지원합니다.
이 글은 오늘날의 기술 의사 결정자에 영향을 주는 최신 동향 및 주제에 대한 시리즈 중 일부입니다.
이 주제에 관해 자세히 알아보세요.
2024 API 보안 및 관리 보고서를 다운로드하고 가장 일반적인 API 취약점, 업계 예측 및 API 보호를 위한 심층적인 권장 사항을 살펴보세요.
핵심 사항
이 글을 읽고 나면 다음을 이해할 수 있습니다.
API와 관련된 3가지 공통적인 문제
전용 API 관리 시 ‘해야 할 일’과 ‘하지 말아야 할 일’
시간의 흐름에 따라 API 보안 성숙도를 개선하는 방법