MCP 보안 체크리스트: 안전한 MCP 서버 배포를 위한 OWASP 최소 기준
OWASP GenAI 보안 프로젝트는 안전한 MCP 서버 배포를 위한 5개 카테고리의 최소 기준을 정의합니다. 이 체크리스트를 사용하여 프로덕션 배포 전에 식별, 격리, 도구, 검증 및 배포 전반에 걸친 현재 보안 상태를 평가하세요....
9 분 읽기
MCP Security
Security Checklist
+3
인증은 MCP 서버의 강력한 기능이 정당한 사용자에게 제공될지 공격자에게 제공될지를 결정하는 게이트키퍼입니다. 잘못 설정하면 다른 모든 보안 제어가 무의미해집니다 - 이메일, 파일 및 데이터베이스에 접근할 수 있는 인증되지 않았거나 제대로 인증되지 않은 MCP 서버는 다른 모든 것을 얼마나 잘 강화했는지와 관계없이 심각한 취약점입니다.
OWASP GenAI 보안 프로젝트 가이드는 인증 및 권한 부여를 MCP 서버의 8가지 핵심 보안 도메인 중 하나로 식별하며, 대부분의 개발자가 기본적으로 구현하는 것을 넘어서는 특정 요구사항을 제시합니다. 이 글은 이러한 요구사항이 존재하는 이유와 올바르게 구현하는 방법을 설명합니다.
MCP의 인증 과제
MCP 서버는 여러 주체 간을 중재하기 때문에 기존 서비스보다 더 복잡한 인증 환경에 직면합니다:
- AI 어시스턴트를 구동하는 지시사항을 제공하는 사용자
- 지시사항을 해석하고 도구를 호출하는 AI 모델
- AI를 호스팅하는 애플리케이션인 MCP 클라이언트
- 도구 호출을 실행하는 MCP 서버
- MCP 서버가 사용자를 대신하여 호출하는 다운스트림 서비스
이러한 각 관계에는 자체 인증 및 권한 부여 제어가 필요합니다. 어떤 링크의 약점이라도 다른 것들을 우회하는 데 악용될 수 있습니다.
필수: 원격 서버를 위한 OAuth 2.1 및 OIDC
원격 MCP 서버 - 로컬 STDIO나 Unix 소켓이 아닌 네트워크를 통해 접근되는 서버 - 에 대해 OWASP GenAI 가이드는 명확합니다: OAuth 2.1과 OIDC는 필수이며, 선택 사항이 아닙니다.
이 요구사항이 존재하는 이유는 다음과 같습니다:
OAuth 2.1은 명시적인 범위 제어를 제공합니다. 모든 액세스 토큰은 정확히 어떤 리소스와 작업을 승인하는지 선언합니다. MCP 서버는 도구 호출 시점에 제시된 토큰이 해당 작업에 필요한 특정 범위를 가지고 있는지 확인할 수 있습니다 - 단지 사용자가 인증되었다는 것뿐만 아니라 이 특정 작업에 대해 권한이 부여되었는지도 확인합니다.
OIDC는 암호화된 신원을 제공합니다. OpenID Connect는 MCP 서버가 신원 제공자에게 왕복하지 않고도 검증할 수 있는 신원 주장(ID 토큰)을 추가합니다. 서버는 모든 요청에서 iss(발급자), aud(대상), exp(만료) 및 서명을 검증합니다.
OAuth 2.1 토큰은 설계상 짧은 수명을 가집니다. 최신 OAuth 사양(OAuth 2.0 모범 사례를 통합하고 대체함)은 정기적으로 갱신되어야 하는 짧은 수명의 액세스 토큰을 강조합니다. 이는 토큰이 손상된 경우 피해 기간을 제한합니다.
모든 요청에서 검증해야 할 사항
세션 설정 시에만 토큰을 검증하지 마세요. 모든 도구 호출마다 검증하세요:
def validate_token(token: str, required_scope: str) -> TokenClaims:
claims = jwt.decode(
token,
key=get_public_key(claims_preview['kid']),
algorithms=["RS256", "ES256"]
)
assert claims['iss'] == EXPECTED_ISSUER
assert EXPECTED_AUDIENCE in claims['aud']
assert claims['exp'] > time.time()
assert required_scope in claims['scope'].split()
return claims
요청 간에 검증 결과를 캐시하지 마세요. 세션 시작 시 유효했던 토큰이 세션 중간에 취소될 수 있습니다.
동적 클라이언트 환경
MCP 클라이언트가 자주 변경되는 환경(예: 동일한 서버에 연결되는 다른 AI 어시스턴트)에서는 정적 API 키나 사전 공유 비밀이 충분하지 않습니다. OAuth 2.1 또는 OIDC를 사용한 동적 클라이언트 등록을 사용하여 연결 시점에 클라이언트 신원을 확인하세요. 허용 목록, 하드코딩된 연결 정책 또는 상호 TLS(mTLS)는 특정 클라이언트와 서버 간의 알려진 정적 관계에 적합합니다.
혼란스러운 대리인 문제
공격 이해하기
혼란스러운 대리인은 MCP 아키텍처에서 특히 위험한 형태로 나타나는 고전적인 권한 부여 취약점입니다. 이 공격은 MCP 서버가 누구의 권한으로 작동하는지의 모호성을 악용합니다.
다음 시나리오를 고려하세요:
- 사용자 Alice는 제한된 권한으로 MCP 서버에 인증됩니다 - 자신의 파일은 읽을 수 있지만 다른 사람의 파일은 읽을 수 없습니다
- MCP 서버는 조직의 모든 파일을 읽을 수 있는 광범위한 서비스 계정 권한을 가지고 있습니다
- MCP 서버는 토큰 패스스루를 사용합니다: Alice의 토큰을 다운스트림 서비스로 전달합니다
Alice가 AI 어시스턴트에게 “내 프로젝트 폴더를 요약해줘"라고 요청하면, 서버는 Alice의 토큰을 사용하여 그녀의 파일에 접근합니다 - 올바른 동작입니다. 그러나 공격자가 서버를 속여 자체 서비스 자격 증명을 사용하여 요청하도록 만들면(도구 중독 공격이나 간접 프롬프트 주입을 통해), 서버의 상승된 권한이 Alice가 볼 권한이 없는 파일에 접근하는 데 사용됩니다.
서버는 “혼란스러운 대리인"입니다 - 해당 권한이 없는 사람을 대신하여 자신의 권한을 사용하도록 속아서 권한 상승의 대리인 역할을 합니다.
토큰 패스스루가 이 취약점을 만드는 이유
많은 MCP 구현은 단순성을 위해 클라이언트의 토큰을 다운스트림 API로 전달합니다. 이것은 직관적으로 보입니다 - 사용자의 토큰은 사용자의 권한을 나타내므로, 모든 다운스트림 호출에 사용하면 올바른 접근 제어가 유지됩니다.
문제는: MCP 서버를 신뢰할 수 있는 중개자로 인식하는 다운스트림 API가 전달된 사용자 토큰의 수준이 아닌 서버의 신원 수준을 사용하여 요청을 승인할 수 있다는 것입니다. 그리고 MCP 서버가 자체적으로 행동하는 경우 - 사용자가 명시적으로 요청하지 않은 AI 의사 결정을 통해 - 사용자의 토큰 대신 자체 자격 증명을 사용할 수 있습니다.
사용자 토큰을 전달하면 다음과 같은 문제도 발생합니다:
- 감사 추적을 중단시킵니다(다운스트림 로그는 서버 신원이 아닌 사용자 신원을 표시하여 MCP 계층을 모호하게 만듭니다)
- MCP 서버를 손상시킨 공격자에게 전달된 모든 사용자 토큰에 대한 접근 권한을 부여합니다
- 다른 사용자의 토큰이 혼동되거나 재생될 수 있는 경우 규정 준수 문제를 야기합니다
해결 방법: On-Behalf-Of 흐름을 통한 명시적 토큰 위임
클라이언트 토큰을 전달하는 대신, MCP 서버는 OAuth의 On-Behalf-Of (OBO) 흐름을 사용하여 다운스트림 서비스 접근을 위한 자체 토큰을 얻어야 합니다:
사용자가 MCP 클라이언트에 인증 → 클라이언트가 사용자 액세스 토큰을 받음
MCP 클라이언트가 MCP 서버에 사용자 토큰을 제시
MCP 서버가 OBO 흐름을 통해 사용자 토큰을 서버 토큰으로 교환:
POST /token
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
assertion=<user_access_token>
scope=<minimum_required_scope>
MCP 서버가 다운스트림 호출에 자체 OBO 토큰을 사용
OBO 토큰은:
- 특정 도구 호출에 필요한 최소 권한으로 명시적으로 범위가 지정됩니다
- MCP 서버를 호출 당사자로 식별합니다(사용자가 주체로)
- 사용자의 인증 이벤트에 연결됩니다(사용자의 세션이 종료되면 취소될 수 있음)
- 사용자의 전체 토큰을 다운스트림 서비스에 노출하지 않습니다
짧은 수명, 범위가 지정된 토큰
OWASP GenAI 가이드는 구체적인 권장 사항을 제시합니다: 시간이 아닌 분 단위로 측정되는 수명을 가진 액세스 토큰을 발급하세요. 이는 MCP 서버가 클라이언트로부터 받는 토큰과 다운스트림 서비스 접근을 위해 얻는 토큰 모두에 적용됩니다.
짧은 수명이 중요한 이유
도난당한 액세스 토큰은 정당한 사용자가 로그아웃했거나, 비밀번호를 변경했거나, 세션을 취소했는지 여부와 관계없이 전체 수명 동안 유효합니다. 세션 시작 시 도난당한 24시간 토큰은 공격자에게 24시간의 지속적인 접근 권한을 제공합니다. 세션 중간에 도난당한 5분 토큰은 최대 5분을 제공합니다.
짧은 수명의 토큰은 또한 정기적인 재인증 이벤트를 강제하여 다음을 수행할 기회를 제공합니다:
- 사용자의 계정이 정지되었거나 권한이 변경되었는지 재확인
- 비정상적인 인증 패턴(비정상적인 시간, 위치 또는 빈도) 감지
- 민감한 작업에 대한 단계적 인증 적용
토큰 범위 최소화
각 토큰은 수행 중인 특정 작업에 필요한 범위만 포함해야 합니다. 현재 도구 호출이 read:files만 필요할 때 read:files write:files delete:files 범위를 가진 토큰을 발급하지 마세요. 이는 토큰이 가로채지거나 모델이 예상치 못한 도구 호출로 조작되는 경우 피해를 제한합니다.
def get_tool_token(user_id: str, tool_name: str) -> str:
# 도구를 최소 필요 범위에 매핑
required_scopes = TOOL_SCOPE_MAP[tool_name]
return oauth_client.get_token(
subject=user_id,
scopes=required_scopes,
lifetime_seconds=300 # 5분 수명
)
뉴스레터 가입
최신 팁, 트렌드 및 특가 정보를 무료로 받아보세요.
세션을 신원이 아닌 상태로 취급하기
일반적인 실수는 세션 ID를 권한 부여 프록시로 사용하는 것입니다: 요청이 유효한 세션 ID를 전달하면 서버는 권한이 부여되었다고 가정합니다. 이는 상태 관리와 신원 확인을 혼동합니다.
올바른 모델: 세션 ID는 대화 상태를 관리합니다. 권한 부여는 OAuth 토큰의 클레임을 검증하여 모든 요청에서 독립적으로 확인됩니다. 유효한 세션 ID를 전달하는 요청이라도 도구 호출이 허용되기 전에 유효하고 만료되지 않은 적절한 범위의 OAuth 토큰을 제시해야 합니다.
이것이 중요한 이유는 세션 ID가 도난당하거나, 추측되거나, 재생될 수 있는 방식으로 OAuth 토큰 - 암호화 무결성 보장을 포함 - 은 그럴 수 없기 때문입니다.
중앙 집중식 정책 시행
개별 도구 핸들러에 분산된 권한 부여 검사를 구현하는 대신, OWASP GenAI 가이드는 다음을 수행하는 중앙 집중식 정책 게이트웨이를 권장합니다:
- 모든 도구 호출 요청을 도구별 코드에 도달하기 전에 가로챕니다
- 인증을 검증합니다(토큰 서명, 발급자, 대상, 만료)
- 권한 부여를 시행합니다(이 특정 도구에 필요한 범위)
- 동의 확인을 적용합니다(사용자가 이러한 유형의 작업을 명시적으로 승인했는가?)
- 도구 필터링을 구현합니다(이 도구가 이 배포 컨텍스트에서 허용되는가?)
- 감사를 위해 전체 컨텍스트로 모든 결정을 기록합니다
중앙 집중화는 정책이 모든 도구와 에이전트에 일관되게 적용되도록 보장합니다. 도구별 권한 부여 검사는 개발 중에 잊혀지거나 우회될 수 있지만 게이트웨이 검사는 그럴 수 없습니다.
요약: 인증 체크리스트
원격 MCP 서버의 경우 최소 인증 보안 기준은 다음과 같습니다:
- 모든 연결에 OAuth 2.1 / OIDC 시행
- 모든 도구 호출마다 토큰 서명, 발급자, 대상 및 만료 검증
- 다운스트림 API에 토큰 패스스루 금지 - OBO 또는 서버 발급 토큰 사용
- 도구당 최소 필요 권한으로 범위가 지정된 액세스 토큰
- 필수 갱신을 통해 분 단위로 측정되는 토큰 수명
- 세션 ID를 권한 부여 프록시로 사용하지 않음
- 중앙 집중식 정책 시행 게이트웨이 구축
- 모든 인증 이벤트 및 권한 부여 결정을 불변적으로 기록
