[기고] 보이지 않는 공격 표면: API와 섀도우 API의 시대
- 1일 전
- 5분 분량
API, 보안의 출발점···지속적 가시성·평가·모니터링 필요 AI 사용 증가하며 섀도우 API 더 늘어 API 그래프 기반 공격경로 파악·대응해야
[데이터넷] 사이버 보안 패러다임 전환을 이끌어온 ‘제로 트러스트’는 이제 그 이후를 고민해야 할 시기를 맞았다. 그동안 제로 트러스트 전략은 ‘접근 전 인증’에 초점을 맞춰왔으나, ‘접근’이라는 요소를 제외한 다른 부분은 제대로 다뤄지지 않았다. 특히 제로 트러스트의 전제조건인 ‘자산 파악과 무결성 검증’은 거의 고려되지 않았다. 본고에서는 자산과 취약점 관리에 초점을 맞춰 제로 트러스트 이후 보안운영 방안에 대해 알아본다.<편집자>
<연재순서>
1. 제로 트러스트 이후의 보안: 우리는 이미 내부에 있다
2. 보이지 않는 공격 표면: API와 섀도우 API의 시대(이번 호)
3. 취약점은 예측하고 제거해야 한다: 상시 취약점 관리와 새로운 보안 모델
앞선 글에서 제로 트러스트가 충분조건이 될 수 없는 이유를 살펴봤다. 이제 공격은 ‘신뢰를 우회’하는 방식이 아니라, 취약점을 통해 직접 내부로 진입하는 방식으로 진화하고 있다. 그렇다면 다음 질문은 자연스럽게 이어진다. 공격자는 어디를 통해 들어오는가? 그리고 우리는 그 진입 지점을 제대로 인지하고 있는가? 이 질문에 대한 가장 중요한 답은 ‘API’다.
현대 디지털 시스템은 더 이상 단일 애플리케이션이나 서버로 구성되지 않는다. 대부분의 서비스는 수십에서 수백 개의 마이크로 서비스로 분해되어 있으며, 이들은 API를 통해 서로 통신한다. 외부 사용자 역시 웹이나 모바일 인터페이스를 통해 직접 시스템에 접근하는 것이 아니라, API를 호출하는 형태로 상호작용한다.
오늘날 시스템에서 API는 단순한 인터페이스가 아니라, 기능 그 자체이며 동시에 공격 표면이다. 문제는 이 공격 표면이 빠르게 증가하고 있으며, 그 증가 속도가 조직의 관리 능력을 압도하고 있다는 점이다.
특히 데브옵스와 CI/CD 환경에서는 코드가 배포되는 속도만큼 API도 생성된다. 새로운 기능이 추가될 때마다 새로운 엔드포인트가 생성되고, 테스트 과정에서 임시 API가 만들어지며, 내부 시스템 간 통신을 위해 비공식적인 인터페이스가 추가된다.
이 과정에서 모든 API가 중앙에서 관리되거나 문서화되는 것은 아니다. 이렇게 관리되지 않는 API를 우리는 ‘섀도우 API’라고 부른다. 이는 기존에 논의되던 섀도우 IT의 연장선에 있지만, 그 위험성은 훨씬 더 직접적이다. 섀도우 IT가 관리되지 않는 시스템이라면, 섀도우 API는 외부에서 호출 가능한 ‘열린 문’이기 때문이다.
실제 사고가 증명하는 섀도우 API의 위험성
섀도우 API로 인해 발생한 공격은 수 없이 많다. 2021년 페이스북은 106개국 5억3300만 명 사용자 전화번호와 개인정보가 외부에 노출된 사고를 겪었다. 비공식적으로 운영되던 내부 API가 충분한 접근 통제 없이 대규모 데이터 조회를 허용하는 구조였고, 이를 통해 사용자 식별 정보와 전화번호 매핑 데이터가 유출되었다. 공식 인터페이스에는 존재하지 않는 기능이 비공식 경로를 통해 외부에 노출된 전형적인 섀도우 API 문제였다.
2023년 인도 정부의 CoWIN 예방접종 플랫폼에서 수억 명의 개인정보가 유출되는 사고가 발생했다. 과도한 권한이 부여된 채 외부에 노출된 API 엔드포인트가 사고의 주요 원인 중 하나였다. 공식 사용자 인터페이스를 통해 접근할 수 없는 데이터가, API를 직접 호출하는 방식으로 대량 수집되었다.
같은 해 대규모 피해를 낳은 파일 전송 시스템 무브잇(MOVEit) 취약점 공격도 이 맥락에서 재해석할 수 있다. 피해 조직 중 상당수는 무브잇을 내부 파일 전송 용도로만 사용한다고 인식했지만, 실제로는 외부 접근이 가능한 API 엔드포인트가 노출되어 있었다. 이 보이지 않는 노출면이 공격자가 진입하는 경로가 되었다.
이 사례 모두 공격의 진입점이 공식적으로 관리되던 시스템이 아니라, 조직이 충분히 인지하지 못했거나 관리 체계에서 누락된 API였다.
섀도우 API의 위험성은 크게 세 가지 측면에서 나타난다.
첫째, 가시성의 부재다. 조직은 자신이 보유한 서버나 네트워크 장비에 대해서는 비교적 정확한 인벤토리를 유지한다. 그러나 API에 대해서는 그렇지 못한 경우가 많다. 특히 오래된 서비스, 테스트 환경, 외주 개발 산출물, 혹은 비공식적으로 생성된 내부 API는 관리 목록에서 누락되기 쉽다. 이 경우 해당 API는 보안 점검 대상에서도 제외되며, 취약점이 존재하더라도 장기간 방치될 가능성이 높다.
둘째, 보안 통제의 불균형이다. 공식적으로 운영되는 API는 인증, 인가, 속도 제한(rate limiting), 입력 검증 등의 보안 통제를 적용받는다. 반면 섀도우 API는 이러한 보호 장치가 적용되지 않거나, 최소한으로만 적용되는 경우가 많다. 특히 내부 API라는 이유로 인증이 생략되거나, 과도한 권한이 부여되는 사례는 실제 공격에서 자주 활용되는 패턴이다. 이러한 패턴이 실제 사고로 이어진 사례는 이미 여러 차례 확인된다.
셋째, 구조적 연결성이다. API는 독립적으로 존재하지 않는다. 하나의 API 호출은 다른 API 호출로 이어지고, 데이터 흐름과 권한 흐름이 복잡하게 얽혀 있다. 이때 하나의 취약한 API는 단순한 단일 지점 문제가 아니라, 전체 시스템으로 확산될 수 있는 출발점이 된다. 공격자는 이러한 연결 구조를 이용해 단계적으로 권한을 상승시키고, 최종적으로 핵심 자산에 도달한다.
이런 이유로 현대 보안에서는 개별 API나 개별 취약점을 따로 보지 않고, 여러 취약점과 자산이 연결된 공격 그래프를 구성해 전체 구조를 한 번에 바라보려는 시도가 늘고 있다. 이 그래프는 각 자산, 취약점을 노드, 그 사이의 접근, 의존 관계를 엣지로 표현한 것이다.
그래프 신경망(GNN)은 공격 그래프 위에서, 실제 침투로 이어지기 쉬운 경로와 거점 노드를 추정, 예측하는 역할을 한다. 이때 모델은 단일 취약점의 심각도만이 아니라, 해당 취약점이 어떤 다른 노드들과 어떻게 연결돼 있는지를 함께 고려해 ‘어디를 지나가면 내부로 들어갈 수 있는지’ 학습한다. 이렇게 도출된 고위험 경로와 노드 정보는 3부에서 다룰 상시 취약점 관리 모델, 그리고 제로 트러스트, SDN 기반의 자동 대응 체계와 결합될 때 비로소 실질적인 방어 전략으로 완성된다.
최근에는 생성형 AI와 보안 특화 모델이 기존에 탐지되지 않았던 API 취약점까지 드러내고, Nuclei나 OpenVAS 같은 스캐너는 공개된 API와 섀도우 API를 대상으로 자동 탐색을 수행하면서 이러한 공격 표면과 공격 그래프를 더욱 명확히 드러내고 있다.
AI가 공격 표면을 어떻게 확장하는가
이러한 문제는 AI 기술의 확산으로 더욱 심화되고 있다. 생성형 AI와 에이전트 기반 시스템은 내부적으로 수많은 API 호출을 생성한다. 예를 들어, 하나의 사용자 요청을 처리하기 위해 여러 개의 내부 서비스와 외부 API가 연쇄적으로 호출될 수 있으며, 이 과정에서 새로운 API 엔드포인트가 동적으로 생성되거나 노출될 수 있다. 또한 개발자들이 LLM을 활용해 빠르게 서비스를 구현하면서, 보안 검증이 충분히 이루어지지 않은 API를 그대로 배포하는 사례도 증가하고 있다.
더 중요한 변화는 공격 측면에서 나타난다. 과거에는 공격자가 시스템의 구조를 이해하기 위해 상당한 시간과 노력이 필요했다. 그러나 이제는 AI를 활용해 API 구조를 추론하고, 엔드포인트를 탐색하며, 입력 패턴을 자동으로 분석할 수 있다. 공개된 API 일부만으로도 전체 서비스 구조를 유추하거나, 응답 패턴을 기반으로 숨겨진 파라미터를 찾아내는 것이 가능해지고 있다. 공격자는 더 이상 개별 취약점을 찾는 것이 아니라, API 그래프 전체를 분석하고 최적의 공격 경로를 계산하는 방향으로 진화하고 있다.
자산 정의의 전환
여기서 중요한 개념 전환이 필요하다. 우리는 오랫동안 자산(Asset)을 서버, 데이터베이스, 네트워크 장비와 같은 물리적 또는 논리적 인프라로 정의해왔다. 그러나 오늘날의 환경에서 자산의 실질적인 단위는 API다. 데이터는 API를 통해 노출되고, 기능은 API를 통해 실행되며, 권한은 API 호출을 통해 행사된다.
페이스북과 CoWIN의 사례가 보여주듯, 실제로 침해되는 것은 서버가 아니라 API다. 따라서 API를 관리하지 않는다는 것은, 실제 자산을 관리하지 않는 것과 동일하다. 이 관점에서 보면, 기존의 취약점 관리 체계가 왜 한계를 가지는지도 명확해진다. 전통적인 취약점 관리는 자산 인벤토리를 기반으로 한다. 관리 대상 시스템을 식별하고, 해당 시스템에 대한 취약점을 주기적으로 점검하며, 발견된 취약점을 패치하는 방식이다.
그러나 이 모델은 ‘자산이 고정되어 있다’는 가정을 전제로 한다. API가 지속적으로 생성되고 사라지는 환경에서는 이 가정이 성립하지 않는다. 또한 주기적 점검 방식은 시간적 공백을 필연적으로 발생시킨다. 점검과 점검 사이의 기간 동안 새롭게 생성된 API나, 새롭게 발생한 취약점은 그대로 노출된다. AI 기반 공격 환경에서는 이 공백이 곧 공격 기회로 직결된다. 결국 주기적 점검은 구조적으로 ‘뒤늦은 대응’일 수밖에 없다.
현대 보안의 핵심 문제는 ‘취약점이 존재하는가’가 아니라 ‘취약점이 존재하는 API를 알고 있는가’이다. 그리고 이 질문에 확신 있게 답할 수 있는 조직은 많지 않다. 따라서 보안 전략은 두 가지 방향으로 동시에 전환되어야 한다.
첫째, 모든 API를 실시간으로 식별하고 추적할 수 있는 가시성 확보가 필요하다. 이는 단순한 문서화가 아니라, 네트워크 트래픽과 서비스 호출을 기반으로 실제 존재하는 API를 자동으로 탐지하는 수준까지 포함해야 한다. 둘째, 각 API에 대해 취약점 노출 상태를 지속적으로 평가하고, 위험도를 동적으로 갱신하는 체계가 필요하다.
결국 API는 더 이상 개발의 산출물이 아니라, 보안의 출발점이다. 그리고 섀도우 API는 더 이상 예외적인 문제가 아니라, 기본적으로 존재한다고 가정해야 하는 현실이다.
다음 글에서는 이러한 환경에서 어떻게 취약점을 우선순위화하고, 실제 공격으로 이어질 가능성을 예측하며, 상시적으로 제거할 수 있는지를 다룬다. 특히 단순한 점수 기반 평가를 넘어, 무기화 가능성과 구조적 특성을 결합한 새로운 접근 방식이 왜 필요한지를 구체적으로 살펴볼 것이다.
데이터넷
댓글