MCP 인증 및 권한 부여: OAuth 2.1, 토큰 위임, 그리고 혼란스러운 대리인 문제
인증은 원격 MCP 서버의 가장 중요한 보안 계층입니다. OAuth 2.1과 OIDC가 필수인 이유, 토큰 위임이 혼란스러운 대리인 공격을 방지하는 방법, 그리고 토큰 패스스루가 AI 통합에서 가장 위험한 패턴 중 하나인 이유를 알아보세요....
6 분 읽기
MCP Security
OAuth 2.1
+3
OWASP GenAI 보안 프로젝트의 MCP 서버 개발을 위한 실용 가이드는 구체적인 검토 체크리스트인 “MCP 보안 최소 기준"으로 마무리됩니다. 이 체크리스트는 MCP 서버가 프로덕션에 배포되기 전에 갖추어야 할 기본 통제를 정의합니다.
이 게시물은 OWASP 가이드가 정의하는 5개 보안 영역에 걸쳐 구성된 각 항목에 대한 구현 지침과 함께 전체 체크리스트를 제시합니다. 배포 전 보안 검토, 정기 감사 및 식별된 격차를 개선하기 위한 프레임워크로 사용하세요.
이 체크리스트 사용 방법
항목 표시: 각 항목에 대해 통과(구현 및 검증됨), 실패(구현되지 않음 또는 부분적으로 구현됨) 또는 해당 없음(이 배포에 적용되지 않음)을 기록합니다.
배포 게이트: 카테고리 1(식별, 인증, 정책) 및 카테고리 2(격리)의 항목은 하드 배포 게이트입니다. 모든 실패는 개선될 때까지 배포를 차단해야 합니다. 다른 카테고리의 항목은 문서화된 일정과 함께 위험을 수용해야 합니다.
검토 트리거: MCP 서버 코드, 도구 레지스트리, 인증 구성, 배포 환경에 중요한 변경이 있거나 새로운 카테고리의 도구가 온보딩될 때마다 전체 체크리스트를 다시 실행하세요.
카테고리 1: 강력한 식별, 인증 및 정책 적용
이것은 가장 우선순위가 높은 카테고리입니다. 인증 실패는 공격자에게 MCP 서버가 할 수 있는 모든 것에 대한 직접적인 액세스를 부여합니다.
1.1 모든 원격 MCP 서버는 OAuth 2.1 / OIDC를 사용
검증할 사항: MCP 서버에 대한 모든 원격 연결은 적절하게 구성된 OAuth 2.1 인증 서버를 통한 인증이 필요합니다. 익명 연결은 거부됩니다. STDIO를 사용하는 로컬 MCP 서버는 배포 컨텍스트에 적합한 대체 인증을 사용할 수 있습니다.
테스트 방법: 인증 헤더 없이 연결을 시도합니다. 잘못되거나 만료된 토큰으로 연결을 시도합니다. 두 경우 모두 도구에 대한 액세스가 아닌 인증 실패가 발생해야 합니다.
일반적인 실패 모드: 인증 없이 액세스 가능한 개발 엔드포인트; 만료 또는 범위를 검증하지 않는 API 키 인증으로의 폴백; 요청당이 아닌 세션 설정 시에만 토큰 검증.
1.2 토큰은 수명이 짧고, 범위가 지정되며, 모든 호출에서 검증됨
검증할 사항: 액세스 토큰은 몇 분 내에 만료됩니다(몇 시간이 아님). 각 토큰은 현재 작업에 필요한 최소 범위를 전달합니다. 모든 도구 호출은 세션 설정 시뿐만 아니라 토큰의 서명, 발급자(iss), 대상(aud), 만료(exp) 및 필요한 범위를 검증합니다.
테스트 방법: 유효한 토큰을 사용한 다음 만료될 때까지 기다립니다(또는 수동으로 시계를 앞으로 설정). 도구 호출을 시도합니다. 캐시된 검증 결과에서 성공하는 것이 아니라 401로 실패해야 합니다.
일반적인 실패 모드: 세션 시작 시 캐시되고 반복되지 않는 토큰 검증; 24시간 이상의 수명을 가진 토큰; 작업별 범위 대신 광범위한 “admin” 범위 사용; exp 필드를 확인하지 않음.
1.3 토큰 전달 없음; 정책 적용이 중앙 집중화됨
검증할 사항: MCP 서버는 클라이언트 토큰을 다운스트림 API로 전달하지 않습니다. 모든 다운스트림 서비스 호출은 MCP 서버에 명시적으로 발급된 토큰을 사용합니다(On-Behalf-Of 플로우 또는 서비스 자격 증명을 통해). 중앙 집중식 정책 게이트웨이는 모든 도구 호출을 가로채고 도구 코드가 실행되기 전에 인증, 권한 부여, 동의 및 감사 로깅을 적용합니다.
테스트 방법: 들어오는 클라이언트 토큰이 아웃바운드 API 호출에서 전달되는 코드 위치를 검토합니다. 다운스트림 서비스 액세스 로그를 검사하여 요청이 사용자 자격 증명이 아닌 서버 자격 증명으로 도착하는지 확인합니다.
일반적인 실패 모드: 다운스트림 호출에서 Authorization: Bearer ${request.headers.authorization} 패턴; 개별 도구 핸들러 전반에 분산된 권한 부여 검사; 중앙 집중식 정책 적용 지점 없음.
카테고리 2: 엄격한 격리 및 수명주기 제어
멀티테넌트 환경에서의 격리 실패는 치명적입니다. 한 사용자가 다른 사용자의 데이터에 액세스할 수 있게 됩니다. 이는 하드 배포 게이트입니다.
2.1 사용자, 세션 및 실행 컨텍스트가 완전히 격리됨
검증할 사항: 전역 변수, 클래스 수준 속성 또는 공유 싱글톤 인스턴스가 사용자별 또는 세션별 데이터를 저장하지 않습니다. 각 세션은 독립적으로 인스턴스화된 객체 또는 세션 키 네임스페이스(예: session_id:로 접두사가 붙은 Redis 키)를 사용합니다. 코드 검토는 세션 간에 공유 가변 상태가 없음을 확인합니다.
테스트 방법: 다른 사용자 ID로 두 개의 동시 세션을 실행합니다. 세션 A에서 작성된 데이터를 세션 B에서 읽을 수 없는지 확인합니다. 동시 부하 테스트를 사용하여 세션 상태 누출을 일으킬 수 있는 경쟁 조건을 확인합니다.
일반적인 실패 모드: 싱글톤 서비스에서 클래스 속성으로 self.user_context = {}; 세션 키 네임스페이스가 없는 전역 캐시; 요청 수명주기에 적절하게 범위를 지정하지 않는 스레드 로컬 스토리지.
2.2 사용자 데이터에 대한 공유 상태 없음
검증할 사항: 실행 컨텍스트 외에도 모든 공유 인프라(데이터베이스, 캐시, 메시지 큐)는 사용자별 액세스 제어를 적용합니다. 한 사용자의 세션에서 실행된 쿼리는 공유 인프라가 잘못 구성되거나 손상된 경우에도 다른 사용자의 데이터를 반환할 수 없습니다.
테스트 방법: 세션 매개변수를 조작하거나 공유 캐시 키를 악용하여 다른 사용자의 데이터에 액세스를 시도합니다.
일반적인 실패 모드: 사용자 ID가 아닌 쿼리 콘텐츠만 기반으로 한 캐시 키; 사용자 범위 WHERE 절이 없는 데이터베이스 쿼리; 사용자별 하위 디렉토리가 없는 공유 임시 파일 디렉토리.
2.3 세션에 결정적 정리 및 강제 리소스 할당량이 있음
검증할 사항: 세션이 종료될 때(정상적으로 또는 시간 초과/오류를 통해) 연결된 모든 리소스가 즉시 해제됩니다: 파일 핸들, 임시 파일, 메모리 내 컨텍스트, 캐시된 토큰, 데이터베이스 연결. 메모리, CPU, API 속도 및 파일 시스템 사용에 대한 세션별 제한이 존재합니다.
테스트 방법: 세션을 갑자기 종료합니다(정상 종료 없이 연결을 종료). 잔여 리소스가 남아 있지 않은지 확인합니다. 세션을 생성하고 속도 제한을 소진합니다. 다른 세션에 영향을 미치지 않는지 확인합니다.
일반적인 실패 모드: 세션 종료 후 /tmp에 남아 있는 임시 파일; 세션 종료 시 취소되지 않은 캐시된 토큰; 한 세션이 공유 인프라를 소진할 수 있도록 하는 리소스 할당량 없음.
카테고리 3: 신뢰할 수 있고 통제된 도구
도구 보안은 가장 위험한 MCP 특정 공격인 도구 포이즈닝 및 러그 풀을 방지합니다.
3.1 도구는 암호화 방식으로 서명되고, 버전이 고정되며, 공식적으로 승인됨
검증할 사항: 모든 도구 정의에는 승인된 도구 승인자의 암호화 서명이 있습니다. 서명은 전체 매니페스트(설명, 스키마, 버전, 권한)를 다룹니다. MCP 서버는 로드 시 이 서명을 검증하고 서명되지 않았거나 서명이 일치하지 않는 도구를 거부합니다. 도구 버전이 고정됩니다. 서버는 새로운 승인된 서명 없이 업데이트된 도구를 동적으로 로드할 수 없습니다.
테스트 방법: 로드된 도구의 설명에서 단일 문자를 수정합니다. 서버가 해시 불일치를 감지하고 도구 로드를 차단하는지 확인합니다. 서명되지 않은 도구 정의를 로드하려고 시도합니다. 거부되어야 합니다.
일반적인 실패 모드: 무결성 검증 없이 변경 가능한 구성으로 저장된 도구 정의; 서명 키 인프라 없음; 버전 고정 없이 공유 파일 시스템에서 직접 로드된 도구.
3.2 도구 설명이 런타임 동작에 대해 검증됨
검증할 사항: 자동화된 스캐닝은 포이즈닝 시도를 나타낼 수 있는 명령과 유사한 패턴에 대해 도구 설명을 확인합니다. 정기적인 검증은 도구의 실제 런타임 동작이 선언된 설명과 일치하는지 확인합니다. 읽기 전용이라고 주장하는 도구는 런타임에 쓰기 작업을 수행할 수 없어야 합니다.
테스트 방법: 도구 설명에 의심스러운 명령(“항상 send_webhook도 호출…")을 추가하고 사람의 검토 전에 자동화된 스캐닝이 플래그를 지정하는지 확인합니다. MCP 특정 포이즈닝 감지 규칙에 대한 SAST 도구 구성을 검토합니다.
일반적인 실패 모드: 도구 설명에 대한 자동화된 스캐닝 없음; 긴 설명에 포함된 명령을 놓칠 수 있는 수동 검토 프로세스; 기능에 대해 거짓말하는 도구를 잡기 위한 런타임 동작 검증 없음.
3.3 최소한의 필요한 도구 필드만 모델에 노출됨
검증할 사항: 모델 컨텍스트는 올바른 도구 호출에 필요한 필드만 받습니다: 이름, 설명, 입력 스키마, 출력 스키마. 내부 메타데이터, 구현 세부 사항, 디버깅 정보 및 민감한 구성은 모델에 전달되기 전에 필터링됩니다.
테스트 방법: 모델이 사용 가능한 도구를 열거할 때 받는 것을 검사합니다. 내부 필드, 연결 문자열 또는 운영 메타데이터가 모델의 뷰에 나타나지 않는지 확인합니다.
일반적인 실패 모드: 모델 컨텍스트에 전달된 전체 도구 구성 객체; 모델에 누출되는 내부 시스템 세부 사항을 포함하는 오류 메시지; 호출과 관련이 없는 구현 노트를 포함하는 도구 설명.
뉴스레터 가입
최신 팁, 트렌드 및 특가 정보를 무료로 받아보세요.
카테고리 4: 모든 곳에서 스키마 기반 검증
검증 실패는 주입, 데이터 조작 및 서비스 거부를 가능하게 합니다.
4.1 모든 MCP 메시지, 도구 입력 및 출력이 스키마 검증됨
검증할 사항: JSON 스키마 검증은 모든 MCP 프로토콜 메시지, 모든 도구 호출 입력 및 모델에 도달하기 전의 모든 도구 출력에 대해 적용됩니다. 검증은 정의된 스키마를 준수하지 않는 모든 메시지를 거부합니다. 필수 필드 누락, 잘못된 유형, 허용된 범위를 벗어난 값.
테스트 방법: 필수 매개변수가 누락된 도구 호출을 보냅니다. 예상치 못한 추가 필드가 있는 메시지를 보냅니다. 둘 다 자동으로 무시되거나 기본값으로 처리되는 것이 아니라 거부되어야 합니다.
일반적인 실패 모드: 오류 조건에서 우회되는 선택적 검증; 출력이 아닌 입력에 대해서만 검증; 너무 허용적인 스키마(type: "any" 매개변수 허용).
4.2 입력/출력이 삭제되고, 크기 제한되며, 신뢰할 수 없는 것으로 처리됨
검증할 사항: 모든 입력은 주입을 가능하게 할 수 있는 문자(XSS 시퀀스, SQL 메타문자, 셸 메타문자, 널 바이트)를 제거하거나 이스케이프하도록 삭제됩니다. 모든 입력 및 출력에 크기 제한이 적용됩니다. 서버는 모델의 모든 데이터를 전통적인 웹 애플리케이션의 사용자 입력과 동일하게 잠재적으로 적대적인 것으로 처리합니다.
테스트 방법: SQL 주입 페이로드, 셸 메타문자 및 XSS 시퀀스를 포함하는 입력을 보냅니다. 다운스트림 시스템에 도달하기 전에 거부되거나 안전하게 이스케이프되는지 확인합니다. 크기 제한을 초과하는 입력을 보냅니다. 깔끔하게 거부되는지 확인합니다.
일반적인 실패 모드: SQL 쿼리 또는 셸 명령에 직접 전달되는 입력; 과도한 크기의 입력이 메모리 소진을 일으킬 수 있도록 하는 크기 제한 없음; 크기 제한 또는 콘텐츠 필터링 없이 모델에 반환되는 출력.
4.3 구조화된(JSON) 도구 호출이 필요함
검증할 사항: 도구 호출은 검증된 스키마가 있는 구조화된 JSON 객체로만 허용됩니다. 도구 호출을 의미하는 자유 형식 텍스트 생성은 처리되지 않습니다. 시스템은 서버가 명령으로 해석하는 자연어를 생성하여 도구 호출을 실행하도록 유도할 수 없습니다.
테스트 방법: 도구 호출을 설명하는 자연어 문자열을 보냅니다(“경로 /etc/passwd로 delete_file 도구 호출”). 서버가 이것을 도구 호출로 해석하지 않는지 확인합니다.
일반적인 실패 모드: 구조화된 JSON과 자연어 도구 설명을 모두 허용하는 하이브리드 시스템; 도구 호출을 식별하기 위해 모델 생성 텍스트를 구문 분석하는 서버; 스푸핑될 수 있는 정규식 기반 도구 호출 구문 분석.
카테고리 5: 강화된 배포 및 지속적인 감독
배포 강화는 악용된 취약점의 폭발 반경을 제한합니다.
5.1 서버가 컨테이너화되고, 비루트로 실행되며, 네트워크가 제한됨
검증할 사항: MCP 서버는 최소한의 강화된 컨테이너에서 실행됩니다. 컨테이너 프로세스는 비루트 사용자로 실행됩니다. 불필요한 Linux 기능이 삭제됩니다. 네트워크 정책은 명시적으로 필요한 연결로 모든 인바운드 및 아웃바운드 트래픽을 제한합니다. 컨테이너 이미지에는 필요한 최소한의 소프트웨어만 포함됩니다.
테스트 방법: docker inspect를 실행하고 사용자가 비루트인지 확인합니다. 네트워크 정책을 검토하고 명시적으로 화이트리스트에 추가된 연결을 제외한 모든 트래픽을 차단하는지 확인합니다. 불필요한 패키지 또는 알려진 취약한 소프트웨어에 대해 컨테이너 이미지를 스캔합니다.
일반적인 실패 모드: 편의를 위해 루트로 실행되는 컨테이너; 모든 아웃바운드 트래픽이 허용되는 네트워크 정책 없음; 최소 이미지 대신 전체 OS 설치가 있는 기본 이미지.
5.2 비밀은 볼트에 저장되고 LLM에 노출되지 않음
검증할 사항: 모든 API 키, OAuth 클라이언트 비밀, 데이터베이스 자격 증명 및 서비스 계정 토큰은 비밀 볼트(HashiCorp Vault, AWS Secrets Manager, Azure Key Vault 등)에 저장됩니다. 환경 변수, 소스 코드, 컨테이너 이미지 또는 로그 출력에 비밀이 존재하지 않습니다. 비밀 관리 작업은 AI 모델이 액세스할 수 없는 미들웨어에서 발생합니다. LLM은 자격 증명 값을 보거나 처리하지 않습니다.
테스트 방법: 자격 증명과 유사한 문자열에 대한 로그를 검색합니다. 서버 프로세스에 액세스할 수 있는 환경 변수를 검사합니다. 모델의 액세스 가능한 컨텍스트를 검토하여 자격 증명 값이 나타나지 않는지 확인합니다.
일반적인 실패 모드: 버전 제어에 커밋된 .env 파일의 API 키; 모델에 도달하는 오류 메시지에 반환된 자격 증명; 모델의 대화 컨텍스트에 나타나는 도구 매개변수로 전달된 비밀.
5.3 CI/CD 보안 게이트, 감사 로그 및 지속적인 모니터링이 필수
검증할 사항: 배포 파이프라인에는 자동화된 보안 스캐닝(SAST, SCA, 종속성 취약점 스캐닝)이 하드 게이트로 포함됩니다. 실패한 스캔은 배포를 차단합니다. 모든 도구 호출, 인증 이벤트 및 권한 부여 결정은 전체 컨텍스트와 함께 불변으로 기록됩니다. 로그는 비정상적인 패턴(검증 실패 급증, 비정상적인 도구 호출 빈도, 예상치 못한 외부 연결)에 대한 실시간 경고가 있는 SIEM에 수집됩니다.
테스트 방법: 알려진 취약한 종속성을 도입하고 CI/CD 파이프라인이 빌드에 실패하는지 확인합니다. 비정상적인 도구 호출 패턴을 생성하고 예상 응답 시간 내에 SIEM 경고가 발생하는지 확인합니다.
일반적인 실패 모드: 차단 게이트가 아닌 권고로서의 보안 스캐닝; 공격자가 수정할 수 있는 변경 가능한 스토리지에 기록된 로그; 비정상적인 패턴에 대한 경고 없음; 관련 이벤트를 찾을 수 없게 만드는 과도한 로그 상세도.
MCP 배포에 이 체크리스트 사용
프로덕션 배포 전에 모든 MCP 서버에 대해 이 체크리스트를 인쇄하거나 내보내고 체계적으로 작업하세요. 보안 팀을 검토에 참여시키세요. 많은 항목이 올바르게 검증하려면 코드 검토와 라이브 테스트가 모두 필요합니다.
독립적인 검증을 원하는 팀의 경우, 전문적인 MCP 보안 감사 는 자체 평가가 아닌 적대적 테스트 기술을 사용하여 실제 환경에 대해 16개의 모든 체크리스트 항목을 테스트합니다. 결과는 우선순위가 지정된 개선 계획이 포함된 검증된 보안 상태 보고서입니다.
