MCP 서버를 HTTP로 외부 노출했더니 인증이 0이네요, 어떻게 잠가야 하나요?

답변 3개

• 채택된 답변에디터 검증

  stdio에서 원격 transport로 넘어가는 순간 보안 모델이 통째로 바뀝니다. stdio는 같은 머신·같은 사용자 프로세스라는 신뢰가 깔려 있는데, 원격 HTTP는 인터넷에 도구 실행 엔드포인트를 그냥 열어둔 거예요. 지금 상태는 인증 없는 RCE에 가깝습니다. 다른 거 손대기 전에 노출부터 끄세요. 진심입니다.

  끄고 나서 제대로 설계하면:

  인증 — MCP 원격 transport는 표준적으로 OAuth 2.1 기반 인가 흐름을 따르게 정의돼 있습니다. 클라이언트가 액세스 토큰을 받아 매 요청 Authorization 헤더에 싣고, MCP 서버는 그 토큰을 검증. IdP 직접 굴리기 부담되면 사내 SSO를 인가 서버로 두고 MCP 서버는 리소스 서버 역할만 하게 하는 게 깔끔합니다. 검증할 때 audience(이 토큰이 진짜 이 MCP 서버용인지)까지 확인해야 다른 데서 발급된 토큰 갖다 쓰는 오용을 막습니다. 이거 빼먹는 사람 많아요.

  인가(도구 단위) — 가능합니다. 토큰의 스코프/역할 클레임을 읽어서 도구 핸들러 진입부에서 게이팅하세요. db_query는 허용, internal_api_call은 거부 식으로. 모델이 도구를 호출했다는 게 곧 권한이 아니라서, 호출 주체(토큰)의 권한을 서버가 다시 검증해야 합니다.

  그 위에 추가로:

  • DB 쿼리 도구는 임의 SQL 받지 말고 파라미터화된 정해진 쿼리만 노출. 임의 SQL 실행 도구는 그 존재 자체가 사고.
  • 파일 읽기 도구는 경로 화이트리스트 + os.path.realpath로 정규화해서 ../ 디렉터리 트래버설 차단.
  • 1차 방어는 그냥 VPN/사내망 뒤로 두는 거. 공개 인터넷에 직접 노출 안 하면 위험 대부분 사라집니다.
  • 도구 호출 전부 감사 로그.

  그리고 한 가지 더 — "내부 도구라 안전"은 환상입니다. 도구가 외부에서 가져온 데이터(이슈 본문, 웹페이지 등)를 결과로 모델에 돌려주는 순간 그게 프롬프트 인젝션 벡터가 됩니다. 노출 끄는 게 1번인 이유가 이것까지 겹쳐서예요.

  2025년 3월 12일도움돼요 11

  신고
• 위 답변이 정석이고, 운영하다 데인 거 하나만 보탤게요.

  원격 MCP에서 제일 무서운 게 confused deputy입니다. MCP 서버가 사내 API를 호출할 때 서버 자신의 강한 권한(서비스 계정)으로 호출하면, 권한 낮은 사용자가 MCP를 경유해서 자기 권한 이상의 일을 하게 돼요. 위에서 도구 단위 인가를 잘 걸어놔도, 정작 다운스트림 호출이 만능 계정이면 그 인가가 통째로 무의미해집니다.

  그래서 사용자 토큰을 다운스트림까지 전파해야 하는데, 단순 token passthrough 말고 적절한 토큰 교환(on-behalf-of)으로 가야 사내 API가 "진짜 호출 주체"의 권한으로 동작합니다. 이거 설계 안 하면 결국 우회됩니다. 처음 만들 때 귀찮아서 서비스 계정으로 다 처리해놓고 나중에 갈아엎는 게 제일 흔한 루트라 미리 잡고 가세요.

  2024년 12월 19일도움돼요 10

  신고
• 급하게 막아야 하면 순서가 전부입니다. 인증부터 붙이려다 그거 설계하는 며칠 동안 노출은 계속되거든요. 우선순위는 이렇게:

  1. 지금 당장: 공개 노출 차단, 사내망/VPN 뒤로. 이거 하나로 위험 90% 사라짐. 인증 설계는 그 뒤에 천천히.
  2. 그다음: 위험한 도구(임의 SQL, 임의 파일 읽기, 임의 API 호출)부터 제거하거나 화이트리스트로 좁히기. 인증 붙이는 것보다 표면적 줄이는 게 빠르고 효과 큼.
  3. 그 후에 OAuth 인가 제대로 설계.

  노출 차단 → 표면적 축소 → 인증. 이 순서 지키세요.

  2026년 3월 5일도움돼요 9

  신고