01-개념
01 — 위협 모델
섹션 제목: “01 — 위협 모델””MCP면 안전하다”는 착각
섹션 제목: “”MCP면 안전하다”는 착각”MCP의 보안 모델은 두 가지 사실 위에 서 있다:
- 호스트가 보안 경계를 강제한다. 서버는 격리되고, 다른 서버나 대화 전체를 못 본다 — mcp-architecture.
- 그러나 모든 보안 제어는 직접 구현해야 한다. MCP 사양은 원칙을 정의하고, 구체 방어는 서버/호스트 구현자의 몫이다 — mcp-security-best-practices.
의역: “이 문서는 MCP 구현에 특화된 보안 위험·공격 벡터·모범 사례를 정의한다.” — mcp-security-best-practices
즉 MCP를 도입했다고 OAuth, SSRF 방지, 세션 관리가 자동으로 되는 게 아니다.
위협 6종 (사양 명시)
섹션 제목: “위협 6종 (사양 명시)”공식 보안 베스트 프랙티스 문서가 정의한 6가지 — 다음 챕터에서 하나씩 다룬다.
| # | 위협 | 한 줄 |
|---|---|---|
| 1 | Confused Deputy | 정적 client_id + 동적 등록 + 동의 쿠키 조합으로 사용자 동의 없이 OAuth 코드 탈취 |
| 2 | Token Passthrough | MCP 서버가 발급되지 않은 토큰을 다운스트림에 그대로 전달 |
| 3 | SSRF | 메타데이터 URL이 내부 IP/클라우드 메타데이터 엔드포인트를 가리키게 |
| 4 | Session Hijacking | 예측 가능한 세션 ID를 훔쳐 클라이언트 행세 |
| 5 | Local Server Compromise | 로컬 MCP 바이너리에 악성 startup 명령 삽입 |
| 6 | Scope 과대(Over-privileged Scope) | 와일드카드/omnibus 스코프로 토큰 침해 영향 확대 |
두 가지 메타 원칙
섹션 제목: “두 가지 메타 원칙”최소 권한
섹션 제목: “최소 권한”- 토큰 스코프는 해야 할 일만큼만
- 도구는 필요할 때만 노출
- read-only로 시작, 쓰기는 별도 검토
명시적 동의
섹션 제목: “명시적 동의”- 호스트가 도구 호출 전 사용자 동의를 묻는 것은 기능이다
- 자동 승인 hook 만들지 마라
- project 스코프 첫 사용 시 동의는 우회 금지 — mcp.md
”어디까지가 내 책임인가” 매트릭스
섹션 제목: “”어디까지가 내 책임인가” 매트릭스”| 요소 | 책임 |
|---|---|
| 프로토콜 정확성 | SDK |
| 호스트 동의 UI | 호스트(Claude Code/Desktop 등) |
| 서버 ↔ 다운스트림 인증 | 서버 구현자 |
| 토큰 검증 | 서버 구현자 |
| SSRF 차단 | 서버 구현자 |
| 세션 ID 안전성 | 서버 구현자 |
| 사내 권한·감사 | 운영팀 |
호스트는 거들 뿐, 구현자가 거의 모든 것을 책임진다.
- 02-구조 — 6가지 위협 상세