MCP 시스템 보안 강화: 흔히 발생하는 11가지 위험과 대응 방법

MCP 위험은 크게 LLM 조작, 데이터 및 액세스 보안, 인프라 취약점의 세 가지 범주로 나뉩니다.

MCP 서버는 광범위한 내부 시스템에 대한 액세스를 제공하는 경우가 많기 때문에 잠재적인 보안 위험이 큽니다. 하지만 실제 발생 가능성은 설정 방식에 따라 크게 달라집니다.

개인과 기업이 시스템을 보호하기 위해 취할 수 있는 조치는 많으며, 보안 프로토콜은 항상 연결된 MCP 서버가 노출할 수 있는 기능과 데이터에 비례해야 합니다.

MCP와 MCP 보안이란 무엇인가요?

Model Context Protocol(MCP)은 Anthropic이 LLM 기반 앱(또는 호스트)을 외부 시스템에 연결하기 위해 만든 개방형 표준입니다.

MCP 시스템에는 호스트, 클라이언트, 서버라는 세 가지 핵심 구성 요소가 있습니다. 호스트는 주로 AI 어시스턴트이며, 클라이언트를 통해 외부 MCP 서버에 연결됩니다. 이후 호스트는 외부 기능(도구)을 실행하거나, 데이터(리소스) 또는 프롬프트를 가져와 LLM의 컨텍스트 창에 추가하도록 요청을 보낼 수 있습니다.

확대

MCP 보안은 MCP 시스템의 연결과 구성 요소를 보호하는 프로토콜을 말합니다. MCP에는 고유한 몇 가지 주요 과제가 있는데, AI 앱이 에이전트 기능을 갖춘 경우가 많고 메시지에 악성 지시가 포함될 수 있다는 점 등이 그 예입니다.

프롬프트 인젝션, 취약한 인증, 안전하지 않은 서드파티 통합처럼 MCP에만 국한되지 않는 기존 문제도 위험 요인이 됩니다. 다른 컴퓨터 시스템과 마찬가지로 MCP도 신뢰할 수 있는 서버만 사용하는 것과 같은 절차적 프로토콜과 API 게이트웨이 같은 기술적 통제를 함께 활용해 보호합니다.

MCP 위협은 얼마나 심각할까요?

MCP는 빠르게 인기 있는 LLM 기술로 자리 잡았으며, 많은 조직과 소비자용 앱에서 사용하고 있습니다. MCP 서버는 코드로 작성된 프로그램이기 때문에 다른 애플리케이션과 마찬가지로 취약점이 있습니다.

하지만 조직이 통제된 환경에 MCP를 배포해 사용한다면 일반적으로 안전합니다. 신뢰할 수 있는 서버와 검증된 권한으로 시스템을 구축하는 것과, 검증되지 않은 서버 10여 개에 자율 에이전트를 연결하는 것 사이에는 큰 차이가 있습니다.

위협 #1: 간접 프롬프트 인젝션

공격자는 MCP 서버가 반환하는 문서, 웹페이지 또는 도구 출력 안에 LLM을 겨냥한 지시를 심어 둘 수 있습니다. 호스트가 이 내용을 컨텍스트 창에 추가하면 LLM이 이를 실제 지시로 오인할 가능성이 있습니다.

게다가 이러한 지시는 겉보기에는 적절해 보일 수 있습니다. 예를 들어, 가져온 지원 티켓에 답변을 생성하기 전에 민감한 고객 기록을 내보내라는 지시가 담겨 있을 수 있습니다.

간접 프롬프트 인젝션을 방지하는 방법

프롬프트 인젝션은 일반적으로 호스트 수준에서 대응해야 합니다. 외부 콘텐츠는 신뢰할 수 없는 것으로 표시하고, 민감한 정보 요청은 검토 과정에 참여하는 사람(휴먼 인 더 루프)이 내용을 충분히 이해한 상태에서 승인하도록 해야 합니다. 악성 문서나 데이터를 호출해 호스트와 LLM이 어떻게 반응하는지 확인하는 보안 테스트도 도움이 될 수 있습니다.

위협 #2: 도구 포이즈닝과 러그 풀

도구 포이즈닝 공격에서는 MCP 도구의 설명이나 스키마에 악성 코드가 추가됩니다. 이는 MCP가 사용 가능한 도구를 처음 노출하는 탐색 단계에서 LLM에 영향을 미칠 수 있습니다.

확대

러그 풀은 승인된 메타데이터가 변경되는 특수한 유형의 도구 포이즈닝입니다. 이러한 형태의 도구 포이즈닝은 악성 도구를 직접 호출하기보다는 모델이 신뢰할 수 있는 도구를 사용하는 방식을 바꿀 수 있습니다.

도구 포이즈닝과 러그 풀을 방지하는 방법

호스트는 각 도구를 사용하기 전에 전체 정의를 검사하고 승인된 신뢰할 수 있는 도구 목록과 비교하여 변경 사항을 감지해야 합니다. 매개변수 검사는 위험한 기능이 있을 가능성을 파악하고 이를 표시하는 데 도움이 될 수 있습니다.

위협 #3: 과도한 권한

사용자가 MCP 서버와 (호스트를 통해) 연결된 LLM에 작업에 필요한 것보다 더 많은 권한을 부여하는 경우는 흔합니다. 예를 들어 읽기 전용으로 충분한데도 쓰기 권한을 부여하거나, 내부 파일 시스템(예: Google Drive)에 대한 전체 액세스 권한을 부여하는 경우가 있습니다.

이처럼 권한이 광범위하게 늘어나면 악성 도구 호출 같은 다른 취약점의 피해 범위가 커질 수 있습니다. 기업 환경에서 사용자가 AI 도구를 활용한 일상 업무 중에 권한을 계속 부여하다 보면 권한이 “누적”되는 경우가 흔합니다(권한 누적).

과도한 권한을 방지하는 방법

이 문제를 방지하는 가장 직접적인 방법은 권한과 OAuth 범위(읽기, 쓰기, 전체 액세스 등)를 제한하는 것입니다. 특히 민감한 작업에 대한 사용자 승인이 중요한 부분이지만, 권한은 시스템 수준(운영 체제, MCP 호스트, 서버)에서도 통제해야 합니다.

위협 #4: 취약한 인증 및 권한 부여

인증은 MCP 서버에 연결하는 사용자나 애플리케이션의 신원을 확인합니다. 권한 부여는 이들이 액세스할 수 있는 도구와 리소스를 규정합니다.

잘못 구성된 MCP 서버는 사용자를 올바르게 인증하거나 액세스 제한을 적용하지 않은 채 요청이나 토큰을 수락할 수 있습니다. 또한 검증이 취약하면 악의적인 행위자가 탈취한 자격 증명으로 액세스 권한을 얻을 수 있습니다.

취약한 인증 및 권한 부여를 방지하는 방법

원격 MCP 서버를 위한 OAuth 기반 인증, 수명이 짧은 토큰, 역할 기반 액세스 제어(RBAS)는 모두 취약한 권한 부여 문제를 완화하는 데 도움이 되는 조치입니다. 역할 기반 액세스는 서버 자체에 액세스 권한이 있더라도 사용자가 자신의 권한을 넘어서는 데이터와 도구에 액세스하지 못하도록 막아 주므로 유용합니다.

위협 #5: 자격 증명 유출 및 오용

MCP 서버는 외부 서비스에 연결하기 위해 API 키나 OAuth 액세스 토큰 같은 자격 증명을 일상적으로 사용합니다. 이러한 자격 증명이 노출되거나 오용되면 공격자가 민감한 데이터와 기능에 액세스할 수 있습니다.

한 가지 예는 토큰 패스스루로, MCP 서버가 액세스 토큰이 실제로 수신 서비스용으로 발급된 것인지 확인하지 않고 다른 서비스로 전달하는 경우입니다. 이 경우 수신 서비스의 보호 조치가 불충분하면 유출로 이어질 수 있습니다.

자격 증명 유출 및 오용을 방지하는 방법

수명이 짧고 범위가 좁은 토큰과 자격 증명 순환은 유출된 데이터가 악의적인 행위자에게 악용되는 범위를 제한하는 데 효과적입니다. API 키와 자격 증명은 항상 시크릿 관리자를 사용해 안전하게 저장해야 합니다.

위협 #6: 혼동된 대리인 공격

혼동된 대리인 공격은 공격자가 신뢰할 수 있는 애플리케이션을 속여, 정당한 사용자가 승인하지 않은 작업을 해당 애플리케이션의 권한으로 수행하게 만들 때 발생합니다. 이 경우에는 MCP 서버가 대리인입니다.

확대

공격자는 MCP 서버의 취약점(예: 취약한 OAuth 검증)을 악용해 도구 호출이나 데이터 검색 같은 악성 프로세스를 실행합니다.

혼동된 대리인 공격을 방지하는 방법

모든 도구 호출이 특정 사용자에게 속한 것인지 확인하는 권한 부여 검증은 혼동된 대리인 공격을 제한하는 데 도움이 됩니다. 또한 데이터 내보내기 같은 민감한 작업에는 명시적인 권한 부여가 필요하도록 해야 합니다.

위협 #7: 악성 서버 및 손상된 종속성

MCP 서버는 악성 코드를 포함하고 있거나(본질적으로 외부 프로그램이기 때문입니다) 서드파티 라이브러리 같은 손상된 종속성에 의존할 수 있습니다. 이는 MCP 고유의 문제라기보다는 소프트웨어 공급망 문제입니다.

이런 일이 일어나는 간단한 경우 중 하나는 공격자가 정상적인 것처럼 보이는 통합을 배포하는 것입니다. 이 통합은 일단 설정되면 자격 증명을 탈취해 재사용하고, 민감한 데이터에 액세스하며, 승인되지 않은 작업을 실행할 수 있습니다.

악성 서버 및 손상된 종속성을 방지하는 방법

MCP 서버는 신뢰할 수 있고 검증된 출처에서만 설치하세요. 가능하면 코드를 검토하고, 외부 종속성은 항상 확인하세요. 서버를 정기적으로 업데이트하고 패치하세요.

위협 #8: 서버 측 요청 위조(SSRF)

서버 측 요청 위조(SSRF)는 공격자가 MCP 서버를 속여 사용자가 액세스하려고 의도하지 않은 내부 주소로 네트워크 요청을 보내게 만드는 공격입니다.

이는 MCP 서버가 URL에서 정보를 가져오는 도구를 노출할 때 발생할 수 있습니다. 공격자가 URL 매개변수에 영향을 줄 수 있다면 이를 내부 API나 클라우드 서비스 같은 원하는 네트워크 주소로 바꿀 수 있습니다. 그 결과 민감한 데이터가 검색되고 외부에서 액세스할 수 있게 될 수 있습니다

서버 측 요청 위조(SSRF)를 방지하는 방법

MCP 서버는 항상 URL을 검증하고, 제한된 내부 네트워크 주소에 대한 액세스를 차단하며, 아웃바운드 네트워크 액세스를 막아야 합니다. 리디렉션에도 이 프로토콜을 적용해야 합니다.

위협 #9: 세션 하이재킹

세션 하이재킹은 공격자가 MCP 클라이언트와 서버 간의 활성 연결을 장악하는 것을 말합니다.

예를 들어 공격자는 보안이 취약한 MCP 애플리케이션(예: 호스트 또는 서버)에서 세션 식별자를 탈취할 수 있습니다. MCP 서버가 이 식별자를 수락하면 공격자는 사용자의 정당한 권한으로 도구를 호출할 수 있게 됩니다.

방지하는 방법

MCP 시스템의 모든 애플리케이션에서 엄격한 신원 확인을 적용하면 세션 하이재킹 위험을 줄일 수 있습니다. 또한 세션 식별자가 노출되지 않도록 MCP 클라이언트와 원격 서버 간의 암호화도 필수적입니다.

위협 #10: 믹스업 공격

믹스업 공격에서 공격자는 MCP 클라이언트를 속여, 클라이언트와 MCP 서버 사이에 있는 악성 권한 부여 서버로 권한 부여 코드를 보내게 만듭니다. 권한 부여 서버는 요청된 액세스가 승인되었는지 확인한 후 OAuth 액세스 토큰을 발급하는 애플리케이션입니다.

확대

MCP 호스트가 각각 다른 권한 부여 서버를 사용하는 여러 서비스에 연결되어 있다면, 공격자는 (예를 들어 악성 서비스를 등록하는 방식으로) 그중 하나를 장악하고, 클라이언트가 정상 서버에서 발급한 권한 부여 코드를 악성 서버로 보내도록 만들 수 있습니다. 공격자는 이러한 혼동을 이용해 권한을 부여받은 애플리케이션으로 위장하고 보호된 서비스에 액세스할 수 있습니다.

믹스업 공격을 방지하는 방법

MCP 클라이언트는 OAuth 프로세스 전반에 걸쳐 권한 부여 서버의 신원을 확인해야 합니다. 구체적으로는 서버의 발급자 식별자(iss)를 예상되는 신원과 대조하고, 일치하지 않으면 거부해야 합니다.

위협 #11: 로컬 MCP 서버 침해

많은 MCP 서버가 사용자의 로컬 머신에서 실행됩니다. 사용자는 서드파티로부터 서버를 설치하거나 직접 구축할 수 있습니다. 공격자가 이 로컬 MCP 서버를 침해하면 로컬 시스템의 상당 부분에 액세스할 수 있게 됩니다.

공격자가 액세스 권한을 얻는 방법은 다양합니다. 정상적인 통합으로 위장한 악성 서버를 배포하거나, MCP 호스트의 구성을 수정해 악성 명령을 내리게 하거나, 보안 통제가 불충분한 환경에서 실행되는 MCP 서버에 액세스할 수 있습니다. 예를 들어 DNS 리바인딩은 브라우저를 속여 localhost 서비스로 요청을 보내게 만드는 방식입니다.

로컬 MCP 서버 침해를 방지하는 방법

로컬 MCP 서버를 사용할 때는 샌드박스 적용과 엄격한 동의 프로토콜이 중요합니다. MCP 서버는 반드시 신뢰할 수 있는 제공업체로부터만 설치해야 하며, 운영 체제 권한을 통해 서버가 액세스할 수 있는 디렉터리를 제한해야 합니다.

MCP 취약점은 대부분 겉모습만 바뀐 기존 위협입니다

MCP 취약점은 기존의 위험과 공격 기법이 새롭게 적용되면서 발생하는 경우가 많습니다. MCP는 LLM, MCP 서버, 외부 서비스 간의 상호작용을 통해 공격자가 이러한 취약점을 악용할 수 있는 새로운 경로를 만듭니다.

물론 MCP 고유의 위협도 존재합니다. 하지만 엄격한 권한 부여 적용, 신뢰할 수 있는 제공업체 이용, 프롬프트 인젝션 방어와 같은 표준 보안 프로토콜만으로도 모든 MCP 구현을 보호하는 데 큰 도움이 된다는 점을 기억해 두는 것이 좋습니다.