[기고] API와 취약점의 시대: 제로 트러스트 넘어서는 보안 운영①

1일 전
4분 분량

취약점 존재 자체가 공격 가능성...취약점 제거 속도 '관건' 제로 트러스트 구현해도 취약점 해결 못해...실시간 취약점 탐지와 제거 방안 시급

[데이터넷] 사이버 보안 패러다임 전환을 이끌어온 ‘제로 트러스트’는 이제 그 이후를 고민해야 할 시기를 맞았다. 그동안 제로 트러스트 전략은 ‘접근 전 인증’에 초점을 맞춰왔으나, ‘접근’이라는 요소를 제외한 다른 부분은 제대로 다뤄지지 않았다. 특히 제로 트러스트의 전제조건인 ‘자산 파악과 무결성 검증’은 거의 고려되지 않았다. 본고에서는 자산과 취약점 관리에 초점을 맞춰 제로 트러스트 이후 보안운영 방안에 대해 알아본다.<편집자>

<연재순서>

1. 제로 트러스트 이후의 보안: 우리는 이미 내부에 있다(이번 호)

2. 보이지 않는 공격 표면: API와 섀도우 API의 시대

3. 취약점은 예측하고 제거해야 한다: 상시 취약점 관리와 새로운 보안 모델

사이버 보안 패러다임은 지난 10여 년간 ‘경계를 어떻게 지킬 것인가’에서 ‘신뢰를 어떻게 검증할 것인가’로 이동해왔다. 그 중심에 제로 트러스트가 있다. ‘아무도 신뢰하지 말고, 항상 검증하라(Never trust, always verify)’는 이 원칙은 기존의 경계 기반 보안이 무너진 환경에서 필연적으로 등장한 대응 전략이었다. 클라우드 전환, 원격 근무, API 기반 시스템 확산은 네트워크 경계를 사실상 무의미하게 만들었다. 제로 트러스트는 이러한 환경에서 접근 통제와 인증을 강화하는 핵심 프레임워크로 자리 잡았다.

그러나 지금 시점에서 우리는 보다 근본적인 질문을 던져야 한다. 과연 제로 트러스트는 충분한가? 더 정확히 말하면, 제로 트러스트는 현재의 공격 환경을 설명하고 방어하는 데 있어 ‘필요조건’은 되지만 ‘충분조건’은 되는가?

이 질문에 대한 답은 점점 명확해지고 있다. 공격자는 더 이상 ‘신뢰를 우회’하려 하지 않으며, ‘취약점으로 직행’한다. 즉 보안의 중심축이 인증 이전(Pre-authentication)에서 인증 이후(Post-authentication)로 이동하고 있다.

현재 구현된 ZTA의 한계

이 논의에서 중요한 전제를 먼저 명확히 해야 한다. NIST SP 800-207로 대표되는 최신 제로 트러스트 아키텍처(ZTA) 사양은 마이크로세그멘테이션, 지속적 신뢰 평가, 런타임 행위 분석까지 포함하는 포괄적인 프레임워크다. 이론적으로는 인증 이후의 이상 행위도 탐지 범위에 포함된다.

문제는 실제 현장에서 구현되는 ZTA가 이 이론적 완성도에 훨씬 못 미친다는 점이다. 대부분의 조직이 도입한 제로 트러스트는 사실상 다단계 인증(MFA) 강화, ID 기반 접근 통제, 최소 권한 원칙의 조합으로 요약된다. 이는 ‘누가 접근할 수 있는가’를 통제하는 데 초점이 맞춰져 있으며, ‘접근 이후 무엇이 가능한가’, 특히 ‘취약점을 통해 무엇이 가능한가’에 대해서는 제한적인 가시성과 통제만을 제공한다.

현대 공격은 바로 이 간극을 파고든다. 공격자는 유효한 인증 정보를 탈취하거나, 합법적인 API 호출 경로를 활용하거나, 혹은 내부 서비스 간 통신을 악용해 시스템 내부로 자연스럽게 진입한다. 그리고 그 이후에는 취약점을 기반으로 권한 상승, 데이터 탈취, 서비스 장악을 수행한다. 이 과정에서 제로 트러스트는 더 이상 ‘장벽’이 아니라 ‘통과한 이후의 환경’이 된다.

인증이 존재했음에도 공격 발생

이 패턴은 이론이 아니라 반복적으로 검증된 현실이다. 2021년 12월 공개된 로그포셸(Log4Shell, CVE-2021-44228)이 그 극단적인 사례다. 아파치 Log4j 라이브러리의 원격 코드 실행 취약점으로, 이를 악용한 스캐닝과 익스플로잇이 취약점 공개 후 수 시간 내에 전 세계적으로 시작되었다. 해당 취약점은 인증 체계를 우회한 것이 아니라, 인증과 무관하게 동작하는 로깅 파이프라인 자체를 통해 진입했다. 아무리 정교한 접근 제어가 구축되어 있어도, Log4j를 사용하는 환경이라면 동일한 위험에 노출될 수밖에 없었다.

2023년 발생한 무브잇 취약점(CVE-2023-34362)도 마찬가지다. 이는 프로그레스 소프트웨어의 파일 전송 솔루션 무브잇(MOVEit)에서 발견된 SQL 인젝션 취약점으로, 클롭(Cl0p) 랜섬웨어 그룹이 이용해 수백 개 조직의 데이터를 탈취했다.

피해 조직 상당수는 MFA와 접근 제어 정책을 운영하고 있었다. 그러나 인증을 통과한 이후의 서비스 레이어에 존재하는 취약점은 그 정책들이 막을 수 있는 영역 밖에 있었다. 이처럼 ‘인증된 공격(Authenticated Attack)’, 또는 인증과 무관한 서비스 취약점을 통한 직접 침투는 이제 표준적인 공격 형태로 자리 잡고 있다.

AI가 바꾸는 취약점의 시간적 가치

최근 AI 기술 발전은 상황을 한층 더 복잡하게 만든다. 과거에는 취약점 탐색과 익스플로잇 개발은 높은 수준의 전문성과 시간을 요구했다. 이제는 대형 언어모델(LLM)과 자동화 도구를 통해 취약점 분석, PoC 생성, 공격 경로 설계가 빠르게 자동화되고 있다.

공격자는 특정 시스템의 API 구조를 추론하고, 입력 패턴을 분석하며, 잠재적인 취약점을 탐색하는 과정을 거의 자동으로 수행할 수 있다. 나아가 여러 취약점을 연결한 공격 체인까지 구성할 수 있다. 이러한 변화는 취약점의 ‘시간적 가치’를 근본적으로 바꾸고 있다. 로그포셸 당시 공개 후 수 시간 내 익스플로잇이 확산되었고, 무브잇의 경우 패치 공개 직후에도 공격이 멈추지 않았다.

미국 사이버보안 및 인프라 보안국(CISA)의 KEV(Known Exploited Vulnerabilities) 카탈로그가 보여주는 패턴은 일관적이다. 상당수의 취약점이 공개 후 수일 이내에 실제 공격에 활용된다. 과거에는 패치 배포에서 실제 공격 확산까지 몇 주 또는 몇 달의 여유가 있었다면, 지금은 그 창이 극단적으로 좁아지고 있다.

이는 ‘취약점은 존재하는 순간 이미 공격 가능한 상태’라는 사실을 분명히 보여준다. 그리고 이 상태는 제로 트러스트 여부와 무관하게 유지된다. 인증이 강화되더라도, 정책이 정교해지더라도, 취약점이 남아 있는 한 공격 가능성은 사라지지 않는다.

이 지점에서 현장에서 구현된 ZTA의 근본적인 한계가 드러난다. 제로 트러스트는 ‘누가 들어오는가’를 통제하지만, ‘무엇이 뚫려 있는가’를 해결하지는 않는다. 다시 말해, 제로 트러스트는 공격 표면을 줄이는 데 기여할 수는 있지만, 취약점 자체를 제거하지는 않는다.

또 다른 중요한 문제는 현대 시스템이 가지는 구조적 복잡성이다. 마이크로서비스, 컨테이너, 서버리스, 그리고 다양한 외부 API 의존성은 시스템을 수백, 수천 개의 상호 연결된 컴포넌트로 분해한다. 이 구조에서 하나의 취약점은 단일 지점 문제가 아니라, 전체 그래프를 통해 확산될 수 있는 잠재적 위험 요소가 된다. 특히 동일한 벤더, 동일한 라이브러리, 동일한 구성 패턴에서 반복적으로 나타나는 취약점은 구조적으로 증폭된다.

이러한 환경에서는 개별 취약점을 단순히 나열하고 우선순위를 매기는 방식으로는 충분하지 않다. 취약점이 어떤 구조 속에 위치하는지, 어떤 경로를 통해 공격 체인으로 연결될 수 있는지, 그리고 어떤 조건에서 실제 공격으로 전환되는지를 함께 고려해야 한다. 보안은 더 이상 정적인 점검의 문제가 아니라, 동적인 시스템 분석의 문제가 된다.

제로 트러스트 환경에서의 '보안' 문제 해결해야

이미 ‘제로 트러스트 이후’의 보안 환경이 상당 부분 구축되었다. 그 환경에서의 핵심 질문은 더 이상 ‘누구를 믿을 것인가’가 아니라 ‘어떤 취약점이 언제 공격으로 전환되는가’에 주목해야 한다. 이 변화는 단순한 기술적 변화가 아니라 운영 패러다임의 전환을 요구한다.

주기적인 취약점 점검, 형식적인 컴플라이언스 체크, CVSS 점수 기반의 정적 우선순위 설정은 더 이상 충분하지 않다. 대신 우리는 취약점을 실시간으로 관측하고, 그 위험도를 동적으로 평가하며, 공격으로 전환되기 전에 제거하는 체계를 필요로 한다. 결국 보안의 본질은 ‘침입을 막는 것’에서 ‘취약점을 제거하는 속도 경쟁’으로 이동하고 있다. 그리고 이 경쟁에서 뒤처지는 순간, 공격자는 이미 내부에 존재하게 된다.

다음 글에서는 이러한 변화의 핵심 원인인 ‘API 중심 공격 표면’과 ‘섀도우 API’ 문제를 다룬다. 왜 우리가 관리하지 못하는 API가 가장 위험한 자산이 되었는지, 그리고 AI가 어떻게 이 보이지 않는 공격 표면을 폭발적으로 확장시키고 있는지 분석할 예정이다.

원문 보기

데이터넷