Redis 미드레벨 보안 면접

세션 ID는 암호학적으로 안전한 난수 생성기(CSPRNG)를 사용하여 충분한 엔트로피(최소 128비트)를 가지도록 생성해야 합니다. 세션 ID는 HTTPS를 통해서만 전송하고 HttpOnly, Secure, SameSite 쿠키 속성을 설정하여 XSS와 CSRF 공격을 방어합니다. 로그인 성공 시 기존 세션 ID를 폐기하고 새로운 세션 ID를 발급하여 세션 고정 공격을 방지해야 합니다. Redis 측면에서는 requirepass로 인증을 설정하고, bind 옵션으로 접근 IP를 제한하며, rename-command로 위험한 명령어를 비활성화해야 합니다. 세션 데이터에는 IP 주소, User-Agent 등의 컨텍스트 정보를 함께 저장하여 세션 탈취를 감지하고, 적절한 TTL을 설정하여 유휴 세션을 자동으로 만료시켜야 합니다.

Application-level 암호화는 데이터를 Redis에 저장하기 전에 애플리케이션에서 AES-256 같은 강력한 대칭키 암호화를 수행하여, Redis 서버가 침해되더라도 데이터가 보호되도록 합니다. Redis TLS/SSL은 클라이언트와 서버 간 전송 구간을 암호화하여 네트워크 스니핑 공격을 방어하며, 6.0 이상에서 지원됩니다. 디스크 암호화(LUKS, dm-crypt)는 RDB/AOF 파일이 저장되는 파일시스템 레벨에서 암호화하여 물리적 접근으로부터 보호합니다. 세 가지 암호화는 각각 다른 위협 모델을 대응하므로 모두 적용하는 다층 방어 전략이 권장됩니다. 암호화 키는 AWS KMS, HashiCorp Vault 같은 전용 키 관리 시스템에 저장하고, 키 로테이션 정책을 수립하며, 애플리케이션 코드나 환경변수에 하드코딩하지 않아야 합니다.

사용자 입력을 검증 없이 Redis 키나 명령어에 사용하면 공격자가 의도하지 않은 키에 접근하거나 다른 명령어를 실행할 수 있는 Redis Injection 공격이 가능합니다. 예를 들어 키 이름에 공백이나 특수문자를 삽입하여 FLUSHDB, CONFIG 같은 위험한 명령어를 실행하거나, 다른 사용자의 데이터에 접근할 수 있습니다. EVAL 명령어로 Lua 스크립트를 실행할 때 사용자 입력을 스크립트 문자열에 직접 삽입하면 Lua Injection이 발생하므로, 반드시 KEYS와 ARGV 배열을 통해 파라미터화해야 합니다. 방어 방법으로는 사용자 입력에 대한 엄격한 화이트리스트 검증(영문, 숫자, 하이픈만 허용), 키 네이밍에 고정 접두사 사용, 그리고 rename-command로 위험한 명령어 비활성화가 필요합니다. 또한 Redis ACL(6.0+)을 사용하여 애플리케이션 계정에 최소 권한만 부여하고, 관리 명령어 접근을 차단해야 합니다.

Redis ACL은 사용자별로 실행 가능한 명령어와 접근 가능한 키 패턴을 세밀하게 제어할 수 있는 기능으로, requirepass의 단일 비밀번호 방식보다 훨씬 강력한 보안을 제공합니다. ACL USER 명령어로 사용자를 생성하고, on/off로 활성화 상태, 비밀번호는 >password 형식으로, 명령어는 +@category 또는 +command 형식으로, 키는 ~pattern 형식으로 설정합니다. 예를 들어 읽기 전용 사용자는 '+@read ~*', 특정 서비스용 사용자는 '+@all ~service:order:*' 같은 방식으로 권한을 제한합니다. 마이크로서비스 환경에서는 각 서비스마다 전용 Redis 사용자를 생성하고, 해당 서비스의 키 접두사 패턴에만 접근하도록 제한하여 서비스 간 데이터 격리를 보장합니다. ACL 설정은 redis.conf의 aclfile 옵션으로 외부 파일에 저장하고, ACL SAVE로 영구 저장하며, ACL LOG로 권한 위반 시도를 모니터링해야 합니다.

사용자 데이터 삭제를 위해서는 먼저 모든 Redis 키에 일관된 네이밍 규칙을 적용해야 하며, 사용자 ID를 포함하는 패턴(예: user:{userId}:*, session:{userId}, cache:profile:{userId})을 정의합니다. 데이터 인벤토리를 문서화하여 사용자 데이터가 저장되는 모든 키 패턴과 용도를 추적하고, 삭제 요청 시 이를 기반으로 체크리스트를 만듭니다. SCAN 명령어를 사용하여 user:{userId}:* 패턴의 모든 키를 찾고, DEL이나 UNLINK로 삭제하되, 프로덕션 환경에서는 KEYS 명령어 대신 반드시 SCAN을 사용해야 합니다. Redis Cluster 환경에서는 모든 노드에서 삭제를 수행해야 하며, Replica에도 복제되었는지 확인합니다. 삭제 후에는 SCAN으로 재검색하여 남은 키가 없는지 검증하고, 삭제 로그를 남겨 감사 추적을 가능하게 합니다. AOF/RDB 백업 파일에도 데이터가 남아있을 수 있으므로, 백업 보관 정책과 암호화를 함께 고려해야 합니다.

Redis 보안의 첫 번째 방어선은 bind 옵션으로 127.0.0.1이나 내부 네트워크 IP만 바인딩하여 외부 인터넷에서의 직접 접근을 차단하는 것입니다. protected-mode를 활성화하면 bind 설정이 없거나 비밀번호가 없을 때 외부 연결을 자동으로 거부합니다. 방화벽(iptables, AWS Security Group)에서 Redis 포트(6379)는 애플리케이션 서버의 IP나 서브넷에서만 접근 가능하도록 화이트리스트를 설정합니다. 클라우드 환경에서는 Redis를 private 서브넷에 배치하고, 퍼블릭 IP를 할당하지 않으며, VPC 피어링이나 PrivateLink를 통해서만 접근하도록 격리합니다. 추가로 requirepass나 ACL로 인증을 설정하고, rename-command로 위험한 명령어를 비활성화하며, TLS를 활성화하여 전송 구간을 암호화하는 다층 방어 전략을 적용해야 합니다. 정기적으로 포트 스캔과 취약점 점검을 수행하여 노출 여부를 모니터링합니다.

slowlog는 설정된 임계값(slowlog-log-slower-than)보다 느린 명령어를 기록하여 비정상적으로 무거운 쿼리나 공격 시도를 탐지할 수 있으며, 메모리에만 저장되므로 성능 영향이 적습니다. ACL LOG는 Redis 6.0+에서 권한 위반 시도를 기록하여 무단 접근이나 권한 상승 시도를 추적할 수 있으며, ACL LOG RESET으로 주기적으로 초기화해야 합니다. MONITOR 명령어는 모든 명령어를 실시간으로 출력하여 디버깅에 유용하지만, 프로덕션 환경에서는 성능에 심각한 영향을 주므로 짧은 시간만 사용하거나 피해야 합니다. 실무에서는 Redis Exporter와 Prometheus를 연동하여 메트릭을 수집하고, Grafana로 시각화하며, 비정상적인 연결 수 증가, 명령어 실패율 상승, 메모리 급증 등의 패턴을 AlertManager로 감지하여 Slack이나 PagerDuty로 알림을 보냅니다. 또한 애플리케이션 레벨에서 Redis 명령어 실행 로그를 중앙 로깅 시스템(ELK, Splunk)에 전송하여 장기 보관하고, 정기적인 보안 감사와 이상 탐지 분석을 수행해야 합니다.