[Redis] 레디스의 보안

레디스의 보안

Redis(레디스)는 기본적으로 빠른 인메모리 데이터 처리에 초점을 맞춘 소프트웨어이임.

최근에는 엔터프라이즈급 사용 사례가 늘어나면서 보안(Security) 요구사항도 크게 중요해졌음.

Redis 자체가 초기 버전에는 간단한 패스워드 인증만 제공했으나, 버전 6.0 이후로는 ACL(Access Control List) 같은 고급 기능을 도입하여 보안 수준을 한층 높임.

그럼에도 불구하고 운영 환경에서 Redis를 안전하게 사용하기 위해서는, Redis 자체 설정뿐만 아니라 네트워크 및 시스템 레벨에서의 여러 보안 전략이 필요함.

 

기본 보안 전제: 레디스는 신뢰할 수 없는 네트워크에 직접 노출하지 않아야 함

Redis 공식 문서에서는 기본적으로 ‘Redis를 퍼블릭 인터넷에 직접 노출하지 말라’고 권장함.

이는 Redis가 태생적으로 고성능, 저지연 응답에 초점을 두고 설계되었고, 과거에는 인증이나 암호화 같은 기능이 상대적으로 단순했기 때문임.

따라서 서버 내부 네트워크(사설망)나 VPN, SSH 터널링 등을 통해 접근할 수 있도록 구성하고, Redis 포트를 직접 외부에 공개하지 않는 것이 1차적인 보안 수단임.

 

인증 및 ACL

1. requirepass (Redis 5.x 이하 및 호환)

Redis 버전 6.0 이전에는 requirepass 설정을 통해 단일 패스워드 기반 인증을 제공했음.

redis.conf 파일 내 requirepass <비밀번호> 지시자를 사용하거나, 동적으로 CONFIG SET requirepass ... 명령을 통해 비밀번호를 설정함.

이 경우 인증에 성공한 후에는 모든 권한이 부여되는 단순 모델임.

단일 패스워드만 유출되어도 Redis 서버 내 모든 명령에 접근할 수 있으므로, 별도의 네트워크 보안 장치(방화벽, 보안 그룹)나 TLS 암호화(아래 참고) 등과 함께 사용해야 함.

 

2. ACL (Redis 6.0 이상)

Redis 6.0에서 도입된 ACL 기능은 보다 세밀한 권한 관리를 지원함.

여러 명의 사용자(user)를 만들고, 각 사용자별로 다른 패스워드, 권한(실행 가능한 명령, 접근 가능한 key 패턴 등)을 할당할 수 있음.

예시는 다음과 같음.

ACL SETUSER alice on >alicepassword ~orders:* +get +set
ACL SETUSER bob on >bobpassword ~inventory:* +get +del

on : 해당 사용자 활성화

>alicepassword : 패스워드 설정

~orders:* : keyspace 패턴 (orders: 접두사가 붙은 키에만 접근)

+get +set : 허용할 명령(ACL Category 혹은 명령어별로 지정 가능)

이렇게 사용자별로 구체적인 정책을 정의함으로써, 애플리케이션별로 최소 권한 원칙(Principle of Least Privilege)을 적용할 수 있음.

 

2.3. 인증 실패 시 지연(acl-pubsub-default, acl-log, …)

Redis 6.2+부터는 ACL 인증 실패, 명령어 제한 위반 등의 이벤트에 대한 로그 기록이 강화되었으며, 일부 환경에서는 문제 발생 시 지연(기본 1초 정도)을 줄 수 있도록 설정 가능함.

이는 무차별 대입(Brute Force) 공격을 어느 정도 방어하는 데 도움이 됨.

 

통신 암호화

1. Redis 6.0 이상에서의 네이티브 TLS 지원

Redis 6.0 이상 버전에서는 네이티브 TLS/SSL 암호화를 지원함.

이전 버전의 경우 stunnel, spiped 등 별도의 터널링 소프트웨어를 통해 SSL/TLS 암호화를 구현해야 했지만, 이제는 Redis 자체적으로 TLS를 활성화할 수 있음.

redis.conf에서 다음과 같은 설정을 통해 TLS 포트(기본 6379 대신 6380 등)를 열고 키/인증서 파일을 지정할 수 있음.

tls-port 6380
tls-cert-file /path/to/redis.crt
tls-key-file /path/to/redis.key
tls-ca-cert-file /path/to/ca.crt

TLS를 통해 클라이언트-서버 간 전송 구간에서 데이터가 암호화되고, 중간자 공격(MITM) 위험을 크게 줄일 수 있음.

 

2. 클라이언트 측 설정

클라이언트 라이브러리(예: redis-py, Jedis, Lettuce, go-redis 등)에서 TLS 옵션을 활성화하고, 필요한 인증서 정보를 지정해야 함.

일반적으로 ‘rediss://’ 스킴을 사용하거나, 별도 TLS/SSL 파라미터를 통해 연결함.

 

네트워크 레벨 보안

1. 바인딩 주소 제한 (bind, protected-mode)

Redis 설정파일에서 bind 127.0.0.1 등을 통해 특정 IP만 수신 대기하도록 제한할 수 있음.

protected-mode yes로 설정하면, Redis가 인터넷에 직접 노출되는 상황을 감지했을 때 연결을 차단하는 보호 모드가 활성화됨.

단, 실제 운영 환경에서는 방화벽으로 막고 별도의 인증을 설정하는 것이 더 안전함.

 

2. 방화벽, 보안 그룹

운영 환경(온프레미스, 클라우드)에서 방화벽 또는 클라우드 보안 그룹(Security Group)을 사용해 Redis 포트(기본 6379/6380 등)를 내부망 주소로만 허용하고, 불필요한 외부 접근을 차단해야 함.

VPC(가상 사설망) 내부에 Redis 인스턴스를 배치하면, 외부에서 직접 접근이 불가능하도록 구성할 수 있어 더욱 안전함.

 

3. SSH 터널링, VPN

만약 개발/운영자가 원격에서 Redis 서버에 직접 접근해야 한다면, SSH 포트 포워딩(터널링) 또는 회사 VPN을 통해 내부망에 접속하는 방식이 권장됨.

이를 통해 Redis가 외부에 열리지 않고, 안전한 채널을 통해서만 접근이 가능해짐.

 

명령어 보호 (CONFIG, SLAVEOF, FLUSHALL 등)

1. rename-command

공격자가 Redis 인증에 성공하거나, 혹은 잘못된 설정으로 인해 인증 없이 접근이 가능해졌다면, 시스템에 치명적인 명령어(예: FLUSHALL, CONFIG, SHUTDOWN, SLAVEOF 등)가 쉽게 실행될 수 있음.

Redis 설정 파일에서 rename-command <원본명령> <새이름> 구문으로 중요 명령어의 이름을 바꿀 수 있음.

rename-command FLUSHALL "NOT_ALLOWED_FLUSHALL"
rename-command CONFIG "HIDDEN_CONFIG"

이렇게 하면 일반적인 해킹 스크립트나 봇이 이러한 명령을 직접 실행하기 어렵게 만들 수 있음.

주의: 명령어를 변경하면 운영·관리 시에도 해당 ‘새 이름’으로 사용해야 하므로 문서화가 필수임.

 

2. ACL을 통한 명령어 차단/허용

Redis 6.0+부터는 ACL에서 특정 명령어를 + 혹은 -로 허용/차단할 수 있음.

예를 들어, 일반 사용자에게는 쓰기 명령(set, del, flushall 등)을 차단하고, 읽기 전용(get, mget)만 허용할 수 있음.

이러한 방식으로 운영 계정과 애플리케이션 계정을 구분하면, 혹시 애플리케이션 계정이 탈취되더라도 Redis 전체를 망가뜨리는 명령 실행이 불가능하게 됨.

 

데이터 영속성 파일 보안

1. RDB 스냅샷, AOF 파일 보호

Redis는 RDB 파일(스냅샷) 혹은 AOF(Append Only File)을 디스크에 저장하는데, 여기에는 실제 키-값 데이터가 그대로(혹은 직렬화 형태로) 기록됨.

따라서 파일 시스템 권한(permissions) 설정을 적절히 적용해, Redis 프로세스 소유자만 접근할 수 있도록 해야 함.

서버가 침해되었을 때 RDB/AOF 파일이 유출되면 데이터가 노출될 수 있으므로 파일 암호화(encryption at rest)도 고려해야 함.

 

2. 노출 금지

운영 상 실수(예: 웹 서버 루트 디렉터리에 RDB/AOF 파일을 저장)가 없도록 주의함.

Redis의 기본 디렉터리는 /var/lib/redis(리눅스 배포판별 상이)에 위치하는 경우가 많으며, 외부에서 쉽게 접근할 수 없는 곳이어야 함.

 

운영 시 보안 모니터링 및 로그 관리

1. SLOWLOG, MONITOR, ACL LOG

Redis에서 제공하는 SLOWLOG, MONITOR 기능을 통해 어떤 명령이 실행되는지, 어느 쿼리가 느린지 등을 파악할 수 있음.

ACL LOG를 통해 인증 실패, 권한 부족 에러 등을 추적하여 공격 시도를 감지할 수 있음.

단, MONITOR는 실시간으로 모든 명령을 스트리밍하므로 운영 환경에서는 과도한 부하와 보안 위험(실제 키/값 노출) 우려가 있어 주의가 필요함.

 

2. 서버 로그인/파일 접근 로그

Redis는 주로 리눅스에서 동작하므로, OS 레벨에서 SSH 접근 로그, 파일 접근 감사(audit) 로그 등을 활용해 침해 시도를 감지할 수 있음.

 

3. 외부 보안 솔루션 연동

Prometheus, Grafana 등 모니터링 툴로 Redis 지표를 수집·시각화하여, 비정상적인 트래픽 패턴이나 연결 시도 급증을 식별할 수 있음.

SIEM(Security Information and Event Management) 시스템과 연동해 이상 징후를 자동으로 알림 받거나 차단할 수도 있음.

 

Sentinel, Cluster 환경에서의 보안

1. Sentinel

Redis Sentinel 구성 시에도 Sentinel 포트(기본 26379)에 대한 인증 설정(>=Redis 5.0.1)과 TLS 적용을 고려해야 함.

Sentinel과 Redis 서버 간, 그리고 Sentinel 클라이언트 간 트래픽도 안전한 네트워크 구간에서 이루어지도록 구성함.

 

2. Redis Cluster

Redis 클러스터 모드(포트 6379와 별개로 클러스터 포트 16379 등)에서도 노드 간 통신을 암호화(TLS)하거나, 내부망에서만 수행되도록 구성해야 함.

노드 간 gossip 통신과 데이터 전송(클러스터 슬롯 이동, 재샤딩 등) 과정에서 민감 정보가 노출되지 않도록 주의함.

 

모범 사례

1. 네트워크 격리

Redis 포트를 외부(공인 IP)에 절대 직접 노출하지 말고, 로컬 네트워크 또는 VPN/SSH 터널 등을 통해 제한적으로 접근.

 

2. 인증 및 ACL

Redis 6.0+ 버전을 사용해 다중 사용자/다중 권한을 적용하고, 최소 권한 원칙 준수.

 

3. TLS 암호화

전송 구간에서 데이터가 평문으로 노출되지 않도록 TLS를 활성화하고, 클라이언트 설정도 함께 구성.

 

4. 중요 명령 보호

rename-command 또는 ACL을 통해 FLUSHALL, CONFIG, SLAVEOF, SHUTDOWN 등 파괴적인 명령어를 감추거나 제한.

 

5. 파일/디렉터리 권한 설정

RDB, AOF 파일이 외부로 유출되지 않도록 OS 레벨 권한을 최소화하고, 필요하다면 암호화.

 

6. 로그 및 모니터링

ACL LOG, SLOWLOG, OS 감사로그, Prometheus 등과 연동해 이상 징후를 즉시 파악.

 

7. 정기 점검 및 업데이트

Redis 자체 보안 취약점 패치, OS/라이브러리 업데이트, 패스워드 변경, 접근 권한 검증 등을 주기적으로 수행.

 

정리

Redis는 고성능 인메모리 스토어로서 현대의 다양한 서비스에서 핵심적인 역할을 하지만, 기본 설정만으로는 보안 면에서 취약할 수 있음.

‘Redis를 외부 인터넷에 직접 노출하지 않는다’는 전제하에, 최근 버전(6.0 이상)에서 제공하는 ACL, TLS 등을 제대로 활용하면 엔터프라이즈 환경에서도 안전하고 효율적으로 운영할 수 있음.

또한, 네트워크 및 시스템 보안(방화벽, VPN, OS 권한 관리, 로그 모니터링)과 결합해 전방위적으로 방어 체계를 구축하는 것이 중요함.

이를 통해 불필요한 데이터 노출을 방지하고, 악의적인 명령 실행이나 무차별 대입 공격 등을 효과적으로 차단할 수 있음.