콘텐츠로 이동

03-실전

모든 MCP 서버는 운영 등록 전에 통과해야 한다.

  • 벤더 공식 / Anthropic Registry / 검증된 커뮤니티 중 하나
  • 라이선스 호환
  • 최근 90일 활동, 보안 공지 채널 존재
  • 노출 도구 전체 목록 캡처
  • 쓰기/삭제/네트워크 호출 도구는 별도 승인
  • read-only 시작 가능 여부
  • 토큰은 환경변수만, 코드/.mcp.json에 없음
  • 최소 스코프 토큰
  • 토큰 만료·로테이션 정책
  • stdio면 OK
  • HTTP면: HTTPS 강제, Origin 검증, 로컬 시 127.0.0.1 바인딩
  • SSRF 가드(IP 차단 목록) 존재
  • 도구 호출이 로깅되는가 (서버 stderr / 사내 SIEM)
  • 호출자 식별 가능 (토큰 audience, user binding)

사용 안 하는 서버는 정기적으로 제거. claude mcp list 결과를 분기마다 리뷰.

3–6개월 주기. 만료 알림 자동화.

  • project 스코프 첫 동의는 개인이 직접 (자동 우회 금지)
  • claude mcp reset-project-choices는 관리자 작업으로 격리
  1. 의심되는 서버를 즉시 비활성: claude mcp remove <name>
  2. 토큰 회수
  3. 감사 로그에서 호출 이력 추적
  4. 영향 범위 평가, 사용자 통보

LLM 에이전트가 권한 너무 큰 DB MCP를 부르고, 사용자 동의 우회 + 쓰기 도구 노출이 결합되어 운영 DB를 삭제 — datatalksclub case. 교훈: 첫 릴리스에 쓰기 도구를 넣지 마라, 별도 권한 계정을 쓰라.

사례 2: 빌링/계정 모델 잘못 가정

섹션 제목: “사례 2: 빌링/계정 모델 잘못 가정”

MCP는 아니지만 유사 교훈: 클라우드 마켓플레이스 결제와 자체 크레딧이 다른 계정 시스템 — leach case. MCP 도입 시에도 벤더의 청구·지원 경계를 미리 확인.

examples/ssrf_guard.py 참고. 도구 안에서 외부 URL을 fetch하기 전 통과시킨다. 라이브러리(smokescreen egress proxy)가 있다면 그쪽이 더 안전.

E. Streamable HTTP 운영 시 추가 체크

섹션 제목: “E. Streamable HTTP 운영 시 추가 체크”

mcp-transports:

  • Origin 헤더 검증 (DNS 리바인딩 방지)
  • 로컬은 127.0.0.1 바인딩
  • 모든 연결에 인증
  • Mcp-Session-Id는 암호학적 UUID, 가시 ASCII만
  • MCP-Protocol-Version 헤더 검증