MCP 보안: 95번의 운영 장애를 겪으며 배운 점
보안은 간단하다고 생각했습니다. 의존성을 업데이트하고, HTTPS를 사용하며, 비밀번호를 하드코딩하지 않으면 된다고 말이죠.
제 생각이 틀렸습니다.
95번의 운영 장애와 1,800시간의 개발 끝에, 저는 Model Context Protocol (MCP) 보안은 다르다는 것을 깨달았습니다. 일반적인 REST API 보안과는 다릅니다.
MCP는 클라이언트가 사람이 아닌 LLM이기 때문에 새로운 위험을 초래합니다.
MCP 서버를 안전하게 유지하기 위해 반드시 알아야 할 사항은 다음과 같습니다.
1. MCP 위협 모델
REST에서는 누가 API를 호출하는지 정확히 알 수 있습니다. 하지만 MCP에서는 LLM이 중개자 역할을 합니다. 이는 모든 것을 변화시킵니다:
- LLM은 도구 호출이나 파라미터를 환각(hallucinate)할 수 있습니다.
- 사용자는 도구를 직접 호출하지 않습니다. 사용자는 LLM과 대화하고, LLM이 서버와 대화합니다.
- 악의적인 클라이언트는 탐색(discovery) 과정에서 숨겨진 도구를 찾기 위해 서버를 조사할 수 있습니다.
가장 큰 위협은 단순히 해커만이 아닙니다. 시스템을 중단시킬 수 있는 실수를 저지르는, 선의를 가진 LLM이 될 수도 있습니다.
2. API 키 관리
많은 개발자가 편의를 위해 쿼리 파라미터에 API 키를 전달합니다. 이는 실수입니다. 쿼리 파라미터는 모든 서버 로그와 프록시에 남기 때문입니다.
다음 규칙을 따르세요:
- 헤더 인증(
Authorization: Bearer)을 사용하세요. - JSON 본문에 키를 전달하는 것을 피하세요.
- 클라이언트마다 별도의 API 키를 발급하세요. 이렇게 하면 사용량을 추적하고, 전체 시스템을 망가뜨리지 않고도 액세스 권한을 취소할 수 있습니다.
3. 엄격한 입력 검증
LLM은 잘못된 추측을 할 수 있습니다. 잘못된 타입이나 추가적인 파라미터를 보낼 수도 있습니다. 모든 호출을 반드시 검증해야 합니다:
- 먼저 도구 이름이 목록에 존재하는지 확인하세요.
- 추가 파라미터가 포함된 호출은 거부하세요. 단순히 무시해서는 안 됩니다.
- 파라미터 타입을 정확히 일치시키세요. 데이터 타입을 강제로 변환(coerce)하지 마세요.
- 메모리 충돌을 방지하기 위해 문자열과 배열에 엄격한 크기 제한을 설정하세요.
- 디렉토리 트래버설(directory traversal)을 방지하기 위해 모든 파일 경로를 정화(sanitize)하세요.
4. 계층적 속도 제한 (Rate Limiting)
사용자의 프롬프트 하나가 한 번에 10개의 도구 호출을 트리거할 수 있습니다. 이는 몇 초 만에 커넥션 풀(connection pool)을 고갈시킬 수 있습니다.
세 가지 계층의 방어 체계를 사용하세요:
- 클라이언트 사용량을 제어하기 위한 API 키별 제한.
- 무차별 대입 공격(brute force attacks)을 막기 위한 IP별 제한.
- 요청 급증 상황에서도 서버를 유지하기 위한 동시 연결 제한.
5. 프롬프트 인젝션(Prompt Injection) 위험
사용자가 LLM을 속여 파괴적인 도구를 호출하게 만들 수 있습니다. 사용자가 LLM에게 모든 노트를 삭제하라고 명령하면, LLM은 실제로 그렇게 할 수도 있습니다.
다음과 같이 스스로를 보호하세요:
- 읽기 작업과 쓰기 작업을 분리하세요.
- 삭제 또는 업데이트 작업 시에는 사용자의 수동 확인을 거치도록 하세요.
- 데이터베이스 사용자에게 최소 권한 원칙(principle of least privilege)을 적용하세요.
보안은 지속적인 과정입니다. 더 나은 키 관리와 엄격한 검증부터 시작하세요. 이 단계들만으로도 대부분의 문제를 해결할 수 있습니다.
Optional learning community: https://t.me/GyaanSetuAi