redis-guard-mcp

read-only가 라벨이 아니라 도구 표면 그 자체인 Redis MCP 서버입니다. 모든 도구는 redis-py의 타입(typed) API를 통해 정확히 하나의 안전하고 읽기 전용인 Redis 명령과 매핑됩니다. 잘못 라벨이 붙을 수 있는 "명령 문자열 실행" 도구는 존재하지 않습니다.

왜 존재하는가

Redis는 프로덕션 백엔드(캐시, 세션 저장소, 큐, 레이트 리미터, pub/sub)에서 가장 널리 배포된 인프라 중 하나이며, 그 명령 표면에는 널리 쓰이는 데이터 스토어 중에서도 가장 위험한 단일 명령들이 포함되어 있습니다:

• EVAL/EVALSHA/FCALL — Redis 프로세스 안에서 임의의 Lua 코드를 실행합니다.

• CONFIG SET dir + CONFIG SET dbfilename + SAVE — Redis만으로 임의의 파일(예: 웹 루트의 웹 셸, 크론 작업)을 디스크에 쓰는, 표준적이고 널리 문서화된 기법입니다.

• MODULE LOAD — Redis 프로세스에 임의의 공유 라이브러리를 로드합니다. 공격자가 .so/.dll을 디스크에 올릴 수 있다면 바로 RCE입니다.

• FLUSHALL/FLUSHDB — 확인 절차 없이 데이터베이스의 모든 키를 즉시 삭제합니다.

• SHUTDOWN, DEBUG, SLAVEOF/REPLICAOF, ACL, CLIENT KILL — 서버 크래시, 복제 하이재킹, 권한 재작성, 세션 종료를 일으키는 관리 명령 표면입니다.

발표된 MCP 서버 감사에서 명령 실행 도구의 메타데이터에 readonly: true라고 표시되어 있었지만 EVAL과 FLUSHALL을 그대로 받아 실행한 사례가 발견되었습니다. 메타데이터는 장식일 뿐, 실제로 강제되지는 않았습니다. 공식 redis/mcp-redis 서버와 직접 대조해 보면, 해당 서버 문서에서도 위의 모든 위험에 대한 유일한 완화책은 Redis ACL을 직접 구성하는 것이라고 밝니다. 그 서버에는 EVAL, FULLALL, CONFIG, MODULE, DEBUG에 대한 내장 차단이 없고, 자체 read-only 모드도 없습니다. 즉, 기본 설이 그대로의 상태에서 안전은 전량 운영자의 책임입니다.

redis-guard-mcp는 어떻게 다른가

1. 허용 목록(allow list)은 필터가 아니라 도구 표면 자체입니다. 이 서버의 어디에도 임의의 명령 문자열을 받아들일 수 있는 대상은 존재하지 않습니다. 모든 도구는 하나의 특정 redis-py 메서드(r.get(key), r.hget(key, field), ...)을 호출하는 특정 파이썬 함수입니다. EVAL, CONFIG, MODULE, FLUSHALL 또는 해당 자체로 명로로 구현되지 않은 명령이 전달될 수 있는 코드 경로는 존재하지 않습니다. 검사하여 거부되서가 아니라, 그러한 명령을 보내는 클라인트 코도 자체가 이곳에 없기 때문입니다.

2. 앱 수준의 제한만이 아니라 실제 권한의 강화도 있습니다. 권장되는(그리고 시작 시 검사되는) 설정은 Redis ACL 사용자를 +@read -@write -@admin -@dangerous로 만들어 연결하는 것입니다. 설사 이 서버 자체 코도에서 버그가 있더라도, 올바르게 구성된 연결을 상대로 쓰기 명령이나 관리 명령을 실행하는 것은 불가능합니다. Redis가 프로토콜 수준에서 자체로 거부하기 때문입니다. 그러므로 규칙 순서가 중요합니다. — CLIENT KILL/PAUSE/LIST/UNBLOCK는 @admin과 @connection 양쪽 모에 속하므로, ... -@admin +@connection(잘못된 순서) 이면 이 네 개 명령을 조용이 허용하게 됩니다. 이것은 가상 시나리오가 않습니다. 이 프로젝트의 초기 설기 스크립트에서도 정확히 그런 순서였고, 보안 검토에서 배포된 "올바로 구성된" 사용자로 실제로 CLIENT PAUSE을 실했고 성공했습니다. 프로젝트 문서에서 "할 수 없다"고 단언했던 사용자로부터 나온 서버 전체 DoS 프리미입니다. +@connection을 앞에 배치해서 수정하습니다. scripts/setup_dev_redis.sh에서 올바른 순서와 왜 되돌일 수 없는지도록 설명를 주석을 확인하세요.

3. 모든 컬력션 조회는 단발이 아닌 커서 기반입습니다. KEYS는 Redis 자체의 내장 @dangerous 카테고리에 속합니다. 단가 호출이 대규모 키스페이스를 직렬화하면 서버 전체가 블로킥 수 있기 때문입니다. 큰 해시의 HETALL, 큰 집하의 SMEMBERS는 널리 알려지지 않은 것뿐 마찬가지입니다. 이 서버의 "컬렉션을 달자" 도구는 모듈 커서 기반(redis_ind(scan/redis_hscan/redis_sscan)이거나, 호출당 최대 1000개로 상한이 걸리고 truncated 플래그가 붙는(redis_lrange/rdis_zrange) 방식입니다. — 서버가 아무리 큰 컬렉션을 한 번에 실체화하게 만듬는 호출은 존재하지 않습니다.

4. Redis 자체의 규칙을 다시 구현하지 않고 Redis에 권한을 직접 묻습니다. redis_check_permission()는 신중하게 고른 위험 명령 목록에 대해 ACL DRYRUN — "이 명령이 이 사용자에게 실제로 성공할 것인가"라는 Redis 자체의 답 — 을 사용합니다. ACL 규칙의 목록을 파싱해 ESPig`` is exactly the bug title" rule list라는 카테고리 목록을 단독으로 읽으면 @admin과 @connection이 겹치는지 발견하지 못합니다). would_succeed는 항상 비어 있어야 합니다.

도구

설정

pip install redis-guard-mcp
export REDIS_GUARD_URL="redis://readonly_user:password@localhost:6379/0"
redis-guard-mcp

REDIS_GUARD_URL은 필수입니다. — 기본값은 없습니다. MCP 클라인트가 env 구서이 설정되어 있는 redis-guard-mcp 명령을 가르키게 하세요. 제한된 ACU 사용자를 관리하는, 작동하는, 올바르게 순서가 짜인 예시 scripts/setup_dev_redis.sh을 참조하세요. (+@connection +@read -@write -@admin -@dangeruos — 그리고 redis_check_permissions() 자체가 필요로 하는 세 개의 총총한 예외인 ACL WHOAMI/ACL GETUSER/ACL DRYRUN도 추가하세요. 이것들이 개별적으로는 @read에 포함되지 않지만 부ẳ해도 안전한 이유는 a.py을 참조하세요).

테스트

pip install -e ".[dev]"
scripts/setup_dev_redis.sh   # starts a Redis container + provisions the ACL user + seeds data
pytest tests/ -v

34 0개의 테스트는 거의 대부분이 실제 로컬 컨테이너를 대상으로 합니다(순수한 설정 검증 전용 몇 개는 Redis가 필요 없어 독립적으로 스킵됩니다); 컨테이너에 접속할 수 없으면 자동으로 스킵됩니다. 위에 언급한 CLIENT PAUSE 규칙 순서 버그에 대한 회귀 테스트와, commands.py가 호출하는 redis-py 메서드의 정확한 집합을 검증하는 AST 기반 구조 테스트가 포함되어 있어, 나중에 새 도구가 리뷰를 조용히 통과하기 전에 여기서 발견됩니다.

상태

v0.1.0. 첫 커밋 전에 적대적 보안 검토를 거쳤으며 이 문제에서 발견하고 수정된 것은: 위의 ACL 규칙 순서 순서 (배포된 사용자야 실제로 CS에 대해 CLIENT PAUSE를 실행해 확인), 원래 카테고리 기반 권한 인증의 두 시각지대(ACL DRYRUN으로 대체), 공유 Redis 인스턴스한테의 무제한 컬렉션 읽기 (이제 상한/페이지 처리), 비멱등적인 dev seed 스크립트, MCP 도구 층의 lazy-singleton에 대한 thread-safety 경합입니다.

라이선스

MIT