업데이트됨 1개월 전
Redis는 어디에나 있습니다. 지난 10년간 웹 애플리케이션을 사용해 본 적이 있다면, 여러분의 경험 중 어느 부분—세션, 캐시된 쿼리, 실시간 알림—은 아마 Redis를 거쳤을 것입니다. 모든 것을 메모리에 보관하기 때문에 빠릅니다. 그냥 동작하길 원하는 개발자들을 위해 설계되었기 때문에 단순합니다.
Redis는 포트 6379에서 수신 대기합니다. 그리고 수년간, 이 포트는 서버에 침입하는 가장 쉬운 방법 중 하나였습니다.
신뢰라는 전제
Redis는 이제 더 이상 존재하지 않는 세계를 위해 설계되었습니다. "방화벽 안쪽"이 곧 "안전한 구역"을 의미하던 그 세계 말입니다.
원래의 철학은 충분히 합리적이었습니다. Redis는 내부 서버에서 실행되고, 여러분이 제어하는 애플리케이션 코드에서만 접근할 것입니다. 모든 연결이 자체 인프라에서 오는데 굳이 인증의 부담을 얹을 이유가 있을까요? 사용자가 자체 서비스뿐인데 왜 명령어를 제한해야 할까요?
그래서 Redis는 비밀번호 없이 출시되었습니다. 모든 IP 주소로부터의 연결을 수락했습니다. 모든 클라이언트에게 전체 관리자 권한을 부여했습니다.
이 방식은 사람들이 공용 IP를 가진 클라우드 서버에 Redis를 배포하거나, 방화벽을 잘못 구성하거나, VPC가 실제보다 훨씬 격리되어 있다고 착각하기 전까지는 잘 작동했습니다. 어느 순간, 신뢰할 수 있는 환경을 위해 설계된 데이터베이스가 인터넷 전체에 노출되기 시작했습니다.
노출된 Redis에 무슨 일이 일어나는가
공격자들의 전술은 그 단순함에서 거의 우아함마저 느껴집니다.
1단계: 포트 6379를 찾아 인터넷을 스캔합니다. 2단계: 연결을 시도합니다. 3단계: 성공하면, 데이터베이스를 통째로 장악한 것입니다.
가장 흔한 공격 방식은 이렇습니다. 보호되지 않은 Redis 인스턴스에 연결하고, FLUSHALL을 실행해 모든 데이터를 삭제한 뒤, 단 하나의 키만 남겨둡니다—데이터 "복구"를 위해 비트코인을 요구하는 협박 메시지입니다. 잔인한 진실은 복구할 것이 없다는 점입니다. Redis는 데이터를 메모리에 보관합니다. 한번 플러시되면 영원히 사라집니다. 몸값은 순수한 이익입니다—공격자는 처음부터 여러분의 데이터를 가진 적이 없으니까요.
더 정교한 공격자들은 Redis를 발판 삼아 서버 자체에 지속적인 접근 권한을 확보합니다. Redis는 파일을 디스크에 쓸 수 있습니다—영속성이 작동하는 방식이 바로 그것입니다. 공격자들은 이를 악용해 악성 SSH 키나 크론 작업을 심어두고, 데이터베이스 설정 하나가 잘못된 것에서 서버 전체 장악으로 이어지게 만듭니다. 암호화폐 채굴기가 뒤따릅니다. CPU 비용이 폭증합니다. 몇 주가 지나서야 알게 됩니다.
보안 연구자들은 수천 개의 노출된 Redis 인스턴스를 꾸준히 발견합니다. 그 안에는 세션 토큰, API 키, 캐시된 개인 정보, 결제 정보가 담겨 있습니다. 연결하는 데 몇 초, 추출하는 데 몇 초.
Redis가 실제로 하는 일
Redis(Remote Dictionary Server)는 메모리 내 키-값 저장소입니다. 키를 주면 값을 돌려줍니다—밀리초가 아닌 마이크로초 단위로.
그 속도는 모든 것을 RAM에 유지하는 데서 옵니다. 전통적인 데이터베이스는 먼저 디스크에 쓰고 응답합니다. Redis는 메모리에서 곧바로 응답하고, 선택적으로 백그라운드에서 디스크에 영속화합니다. 이 덕분에 빠른 속도가 필요하고 일부 데이터 손실을 허용할 수 있는 용도에 이상적입니다.
캐싱: 데이터베이스 쿼리 결과를 저장해 반복 조회를 피합니다. API 응답을 저장합니다. 연산 비용이 높은 결과라면 무엇이든 저장합니다.
세션: 모든 웹 서버가 접근할 수 있는 중앙 저장소에 사용자 로그인 상태를 유지합니다. 사용자가 한 번 로그인하면, 다음 요청을 어느 서버가 처리하든 로그인 상태가 유지됩니다.
실시간 기능: 채팅, 알림, 실시간 업데이트를 위한 Pub/Sub 메시징. 리더보드와 순위를 위한 정렬 집합. 속도 제한과 분석을 위한 카운터.
Redis는 문자열, 해시, 리스트, 집합, 정렬 집합, 스트림 등을 지원합니다. 단순한 캐시가 아닙니다—데이터 구조 서버입니다. 하지만 이 다재다능함에는 대가가 따릅니다. 강력한 명령어들이 함께 존재하는데, 잘못된 손에 들어가면 위험해집니다.
공개 노출이 절대 허용되지 않는 이유
Redis를 인터넷에 노출하는 것은 계산된 위험이 아닙니다. 사고가 되기를 기다리는 잘못된 구성입니다.
비밀번호가 있더라도, 공개된 Redis 인스턴스는 무차별 대입 공격에 직면합니다. Redis에는 속도 제한도, 계정 잠금도, 비밀번호 추측을 막는 보호 기능도 없습니다. 강력한 비밀번호가 도움이 되지만, 그것이 유일한 방어선입니다.
INFO 명령어는 공격자에게 Redis 버전, 메모리 사용량, 구성 정보를 넘겨줍니다—어떤 취약점 공격이 통할지 가늠하는 데 필요한 모든 것입니다. KEYS * 명령어는 수백만 개의 키를 순회하는 동안 서버를 몇 초씩 먹통으로 만들 수 있습니다—사소하지만 효과적인 서비스 거부 공격입니다.
그리고 Redis 취약점이 발견될 때(어떤 소프트웨어에나 존재합니다), 인터넷에 노출된 인스턴스는 보안 권고문을 읽기도 전에 이미 공격받을 수 있습니다.
답은 간단합니다: Redis는 방화벽 뒤에 있어야 합니다. localhost 또는 사설 IP에 바인딩합니다. 여러분이 제어하는 애플리케이션 서버에서만 연결을 수락합니다. 원격 접근이 필요하면 VPN 또는 SSH 터널을 사용합니다. Redis가 불특정 인터넷 주소에서 오는 연결을 수락해야 하는 상황은 없습니다.
실제로 작동하는 인증
최신 Redis(6.0+)에는 제대로 된 접근 제어 기능이 있습니다.
예전 방식은 모두를 위한 단일 비밀번호였습니다. 구성에서 requirepass를 설정하면, 클라이언트는 명령을 실행하기 전에 AUTH <password>를 전송합니다. 없는 것보다는 낫지만 조잡합니다—비밀번호 하나, 인증 후 전체 접근.
접근 제어 목록(ACL)이 이를 바꿨습니다. 서로 다른 비밀번호와 권한을 가진 여러 사용자를 만들 수 있습니다:
읽기 전용 사용자는 cache:로 시작하는 키에 대해 GET과 TTL만 실행할 수 있습니다. 앱 서버는 전체 접근 권한을 가집니다. 모니터는 Redis가 살아있는지 확인하는 것만 가능합니다. 자격 증명이 유출되더라도 피해 범위는 제한됩니다.
이것이 데이터베이스에 적용된 최소 권한 원칙입니다. 모니터링 시스템에는 FLUSHALL이 필요하지 않습니다. 캐시 계층에는 CONFIG가 필요하지 않습니다. 필요 없는 권한은 주지 마세요.
전송 중 암호화
Redis 6.0은 기본 TLS 지원도 추가했습니다.
그 전에는 Redis 트래픽이 평문이었습니다. 모든 명령, 모든 응답, 캐시된 모든 데이터—네트워크를 스니핑할 수 있는 누구라도 읽을 수 있었습니다. Redis 트래픽을 보호하려면 stunnel 같은 TLS 프록시를 통해 우회해야 했습니다.
이제는 인증서 파일로 Redis를 구성하면 클라이언트가 TLS로 직접 연결합니다. 세션 토큰이 네트워크를 통해 평문으로 오가지 않습니다. 중간자 공격이 현실적으로 어려워집니다. 클라이언트 인증서를 추가하면 또 하나의 인증 요소가 생깁니다.
약간의 성능 비용이 있습니다. TLS 핸드셰이크에는 시간이 걸립니다. 암호화는 CPU를 씁니다. 하지만 네트워크 경계를 넘는 데이터—특히 가용 영역이나 데이터 센터 간—에는 그 보호가 충분히 가치 있습니다.
다층 방어
Redis 보안은 한 가지 조치로 끝나지 않습니다. 여러 겹의 방어층으로 구성됩니다.
네트워크: 0.0.0.0이 아닌 127.0.0.1 또는 사설 인터페이스에 바인딩합니다. 알려진 애플리케이션 서버만 허용하는 방화벽 규칙. 이상적으로는 Redis가 전용 네트워크 세그먼트에 위치합니다.
인증: 개발 환경에서도 항상 요구합니다. ACL로 사용자별 권한을 제한합니다. 자격 증명은 구성 파일이 아닌 시크릿 관리 시스템에 보관합니다.
위험한 명령어: FLUSHALL, FLUSHDB, CONFIG, DEBUG, SHUTDOWN을 이름을 바꾸거나 비활성화합니다. 애플리케이션에 필요하지 않다면, 존재하지 않는 것이 낫습니다.
암호화: 로컬 머신을 벗어나는 모든 트래픽에 TLS를 적용합니다.
최소 권한: Redis를 권한이 없는 일반 사용자로 실행합니다. 공격이 성공하더라도 공격자가 갖는 권한은 제한됩니다.
업데이트: Redis 보안 공지를 구독합니다. 신속하게 패치합니다. 체계적인 프로세스를 갖춥니다.
모니터링: slowlog는 비용이 큰 연산을 추적합니다. 비정상적인 패턴—예상치 못한 명령, 낯선 IP에서의 연결—은 정찰의 신호일 수 있습니다.
영속성 파일: RDB 스냅샷과 AOF 로그는 전체 데이터셋을 평문으로 담고 있습니다. 데이터베이스 자체를 보호하듯 철저히 관리합니다.
Redis가 우리에게 가르쳐 주는 것
포트 6379의 Redis는 전제에 대한 교훈입니다.
설계자들은 신뢰할 수 있는 네트워크를 전제했습니다. 그 전제는 수년간 유효했고, 그러다 더 이상 유효하지 않게 되었습니다. 클라우드 인프라로의 전환, 기본값이 공용 IP인 환경, 개발자가 완전히 이해하지 못하는 복잡한 VPC 구성—이 모든 것이 "방화벽 안쪽"을 위험한 전제로 만들었습니다.
Redis는 변화에 적응했습니다. 버전 3.2는 인증을 명시적으로 구성하지 않으면 외부 연결을 거부하는 보호 모드를 추가했습니다. 버전 6.0은 ACL과 TLS를 추가했습니다. 기본값이 더 안전해졌습니다.
하지만 이미 배포된 수많은 인스턴스는 스스로 업데이트되지 않습니다. 오래된 튜토리얼은 여전히 비밀번호 없는 Redis를 보여줍니다. 개발자들은 이해하지 못한 채 구성을 복붙합니다. 그리고 인터넷은 포트 6379를 계속 스캔하며, 방화벽이 자신들을 지켜줄 것이라고 믿는 데이터베이스를 찾습니다.
해결책은 복잡하지 않습니다: Redis를 인터넷에 노출하지 마세요. 인증을 요구합니다. 명령어를 제한합니다. 트래픽을 암호화합니다. 권한 없는 사용자로 실행합니다. 최신 상태를 유지합니다.
Redis는 탁월한 도구입니다—빠르고, 다재다능하며, 오랜 실전에서 검증된. 올바르게 구성된다면 보안도 이제 충분히 견고합니다. 위험은 Redis 자체가 아니라, 내부 서비스를 공개 노출에도 버틸 수 있는 것처럼 다루는 태도에서 비롯됩니다.
버틸 수 없습니다. 신뢰를 위해 설계된 것은 인터넷이 품고 있는 상시적 위협 앞에서 살아남지 못합니다. Redis가 무엇인지 이해하고, 그에 맞게 보호하세요. 그러면 Redis는 여러분에게 충실히 제 역할을 다할 것입니다.
Redis 보안에 관한 자주 묻는 질문
포트 6379는 왜 공격자들의 특별한 표적이 되나요?
포트 6379는 Redis의 기본 포트이므로 스캔하기가 매우 쉽습니다. 역사적으로 기본 인증이 없었던 것과 강력한 관리 명령어의 조합 덕분에, 노출된 인스턴스는 찾기도 쉽고 공격하기도 쉬웠습니다. 자동화된 스캐너들이 이 포트를 대상으로 인터넷 전체를 끊임없이 스캔합니다.
강력한 비밀번호만으로 Redis를 보호할 수 있나요?
강력한 비밀번호는 도움이 되지만 그 자체로는 충분하지 않습니다. 네트워크 격리(Redis는 절대 인터넷에 노출되어서는 안 됩니다), 명령어 제한(FLUSHALL, CONFIG 등 비활성화), 그리고 가능하면 TLS 암호화까지 필요합니다. Redis에는 속도 제한이 없기 때문에 비밀번호만으로는 무차별 대입 공격에 취약합니다.
Redis AUTH와 ACL의 차이점은 무엇인가요?
AUTH는 단일 공유 비밀번호를 사용합니다—알고 있는 모든 사람이 전체 접근 권한을 얻습니다. ACL(Redis 6.0+)을 사용하면 서로 다른 비밀번호와 세밀한 권한을 가진 여러 사용자를 만들 수 있습니다. 특정 키만 읽을 수 있는 사용자, 전체 접근 권한을 가진 사용자, 모니터링 명령만 실행할 수 있는 사용자를 각각 설정할 수 있습니다. ACL은 최소 권한 원칙을 구현하지만, AUTH는 그렇지 않습니다.
프로덕션에서 Redis를 안전하게 사용할 수 있나요?
네, 올바르게 구성한다면 가능합니다. 최신 Redis는 강력한 보안 기능을 갖추고 있습니다. 위험은 Redis 자체가 아니라—잘못된 구성에서, 특히 신뢰할 수 없는 네트워크에 노출했을 때 옵니다. 방화벽 뒤에 유지하고, 인증을 요구하고, 위험한 명령어를 제한하고, 최신 상태로 유지하세요.
Redis 인스턴스가 외부에 노출되어 있는지 어떻게 확인하나요?
네트워크 외부에서 redis-cli -h <your-public-ip> -p 6379 ping을 실행해 보세요. 인증 없이 "PONG"으로 응답한다면 문제가 있는 것입니다. 또한 클라우드 제공업체의 보안 그룹과 방화벽 규칙도 확인하세요. 더 나아가, Shodan 같은 도구를 사용하면 인터넷에서 여러분의 인프라가 어떻게 보이는지 직접 확인할 수 있습니다.
이 페이지가 도움이 되었나요?