MCP 위협 모델 개관 — 무엇이, 왜 위험한가

MCP의 신뢰 모델이 깨지기 쉬운 이유

기존의 소프트웨어는 "사용자 입력은 신뢰하지 않는다"라는 전제하에 입력 검증을 쌓아왔습니다. 하지만 MCP에서는 AI 모델에 전달되는 "도구의 설명문·파라미터 정의·도구의 출력" 자체가 거의 검증되지 않은 상태이자 출처(provenance)가 없는 상태로 모델의 컨텍스트(context)에 들어갑니다.

게다가 도구는 많은 경우 강력한 권한(파일/셸/API/토큰)을 가지고 동작합니다. 즉, "신뢰할 수 없는 문자열"이 "강력한 권한"과 바로 연결되어 있다는 것—이것이 MCP의 구조적인 약점입니다.

공격 표면(Attack Surface) 지도

MCP의 등장인물별로 공격 표면을 나누면 정리하기 쉽습니다.

등장인물	주요 공격 표면
MCP 서버	도구 정의 오염, 과도한 권한, 기밀 정보 삽입
...

OWASP MCP Top 10을 "공격자의 움직임"으로 읽기

OWASP의 10개 카테고리(MCP01~10:2025)는 공격자의 침입부터 목적 달성까지의 흐름으로 재배열하면 이해하기 쉽습니다.

입구: 인증 인가 미비(MCP07) / 섀도우 MCP 서버(MCP09) -
준비: 도구 포이즈닝(Tool Poisoning, MCP03) / 공급망 오염(Supply Chain Contamination, MCP04) -
실행: 커맨드 인젝션(Command Injection, MCP05) / 의도 흐름 파괴(MCP06) -
확산: 스코프 비대로 인한 권한 상승(MCP02) / 토큰 악용(MCP01) -
유출: 컨텍스트 주입·과도한 공유(MCP10) -
그리고 알아차리지 못함: 감사 로그 결여(MCP08) ← SOC 관점에서 최악

SOC의 관점: "막지 못했을 때 알아차릴 수 있는가"

구현만으로 모든 것을 막는 것은 불가능합니다. 그렇기에 SOC는 항상 "침입당한 후에, 어떤 로그를 통해 얼마나 빨리 알아차릴 수 있는가"를 고민합니다.

MCP에서 이를 질문하면, 대부분의 자체 제작 서버는 MCP08(감사 로그 결여) 에서 막히게 됩니다. 애초에 "누가·어떤 도구를·어떤 인수로 호출했는지"가 남아있지 않기 때문입니다.

다음 장 이후의 유료 파트에서는 각 리스크에 대해 "안전한 구현"뿐만 아니라, 최소한 이것만은 남겨두어야 할 감사 로그 항목과 이를 자택 랩(Proxmox 등)에서 격리하여 재현·검증하는 절차를 구체적으로 보여드리겠습니다.

출처: OWASP MCP Top 10(CC BY-NC-SA 4.0)을 참조하여 독자적으로 정리함.

Discussion