Haru Utils

데이터베이스 · 설치·설정 레시피

Redis 로컬 우선 보안 설치

Ubuntu 기본 보안 업데이트가 적용되는 Redis를 설치하고, 루프백 바인딩·보호 모드·ACL·방화벽을 순서대로 확인합니다. 인터넷에 6379 포트를 직접 노출하지 않는 구성이 기준입니다.
Redis 설치Redis 보안6379 포트Redis ACLUbuntu Redis
지원 환경Ubuntu Server 24.04 LTS (amd64·arm64)
예상 시간약 25분
난이도중급
검토일2026-08-28

BEFORE YOU START

시작 전에 준비하세요

01

sudo 권한과 끊기지 않는 SSH 세션

02

Redis를 호출할 애플리케이션의 실행 위치와 신뢰할 수 있는 사설망 대역

03

기존 Redis 데이터가 있다면 검증된 RDB/AOF 백업과 복구 절차

04

원격 접속이 필요하다면 인터넷 공개가 아닌 VPN·사설망 또는 TLS 설계

권장 대상 애플리케이션 캐시나 세션 저장소를 직접 운영하는 개발자·운영자

FOLLOW THE RECIPE

8단계 구성·점검 레시피

1
확인시스템을 변경하지 않는 점검 단계

환경과 패키지 지원 범위 확인

운영체제·아키텍처·초기화 시스템을 먼저 확인합니다. 이 레시피는 Ubuntu의 redis-server 패키지와 systemd를 기준으로 합니다.

운영체제 확인
cat /etc/os-release
CPU 아키텍처 확인
dpkg --print-architecture
초기화 시스템 확인
ps -p 1 -o comm=
후보 패키지 확인
apt-cache policy redis-server
  • Ubuntu LTS와 지원 중인 보안 저장소가 설정되어 있다.
  • PID 1이 systemd이다.
  • 설치하려는 Redis 주 버전을 애플리케이션 클라이언트가 지원한다.
결과 읽기

후보 버전이 없으면 Universe 저장소와 apt 인덱스를 먼저 점검합니다. 기존에 외부 Redis 저장소를 사용 중이면 저장소를 섞지 않습니다.

다음 판단

기존 설치·포트·데이터 경로를 조사합니다.

2
확인시스템을 변경하지 않는 점검 단계

기존 설치와 6379 포트 사전 점검

이미 실행 중인 인스턴스나 데이터가 있는지 확인합니다. 기존 서버를 새 설치로 덮어쓰지 않도록 서비스·포트·용량을 함께 봅니다.

설치 패키지 확인
dpkg -l redis-server redis-tools
서비스 상태 확인
systemctl status redis-server --no-pager
기본 포트 점유 확인
sudo ss -ltnp | grep ':6379 '
데이터 경로 용량 확인
df -h /var/lib/redis
기존 설정의 핵심 항목 확인
sudo grep -E '^(bind|protected-mode|aclfile|requirepass|port|dir|appendonly)' /etc/redis/redis.conf
  • 기존 Redis의 소유 팀과 사용 애플리케이션을 확인했다.
  • 6379 포트를 다른 프로세스가 사용하지 않는다.
  • 기존 데이터가 있다면 RDB/AOF 파일과 복원 시험 결과가 있다.
결과 읽기

서비스가 이미 active라면 신규 설치가 아니라 변경 작업입니다. 설정 파일과 데이터 백업을 확보한 뒤 유지보수 시간에 진행합니다.

다음 판단

충돌이 없을 때 Ubuntu 패키지로 설치합니다.

3
변경패키지·설정·서비스 상태가 달라지는 단계

Ubuntu 보안 저장소에서 Redis 설치

Ubuntu LTS 저장소의 redis-server와 redis-tools를 설치합니다. 설치 전 패키지 후보와 변경 목록을 검토하면 예상하지 못한 교체를 줄일 수 있습니다.

변경 단계입니다. 대상 서버, 백업 파일, 서비스 중단 영향과 바로 이전 상태로 돌아가는 방법을 다시 확인하세요.
패키지 인덱스 갱신
sudo apt update
설치 변경사항 미리 보기
apt-get --simulate install redis-server redis-tools
Redis 설치
sudo apt-get install -y redis-server redis-tools
설치 버전 확인
redis-server --version
  • APT 출력에 의도하지 않은 패키지 제거가 없다.
  • redis-server와 redis-cli 버전이 확인된다.
  • 보안 업데이트 자동 적용 정책에 Redis 패키지가 포함된다.
결과 읽기

최신 Redis 기능이 꼭 필요해 공식 Redis 저장소를 선택한다면 Ubuntu 패키지와 혼용하지 말고 별도 변경 계획으로 관리합니다.

다음 판단

기본 설정을 백업하고 네트워크·ACL 정책을 적용합니다.

4
주의권한·연결·중단 영향을 확인할 단계

설정 백업 후 로컬 바인딩과 ACL 준비

설정을 수정하기 전에 작업마다 고유한 <BACKUP_SUFFIX>를 정해 원본을 보존합니다. 단일 서버 애플리케이션이면 루프백만 허용하고, 별도 호스트에서 접근할 때도 사설 IP와 최소 권한 ACL을 사용합니다.

고유 백업 접미사 생성
date -u +%Y%m%dT%H%M%SZ
출력값을 이번 작업의 <BACKUP_SUFFIX>로 사용하고 변경 기록에 남깁니다. 이후 명령의 자리표시자를 반드시 같은 값으로 교체합니다.
기본 설정 백업
sudo cp --preserve=all --no-clobber /etc/redis/redis.conf /etc/redis/redis.conf.<BACKUP_SUFFIX>.bak
<BACKUP_SUFFIX>를 방금 생성한 고유 값으로 교체합니다. 파일이 이미 있으면 덮어쓰지 말고 새 접미사를 만듭니다.
기본 설정 편집
sudoedit /etc/redis/redis.conf
아래 예시 항목을 기존 파일에서 찾아 수정하고 중복 지시문이 생기지 않게 합니다.
기존 ACL 파일 백업
sudo cp --preserve=all --no-clobber /etc/redis/users.acl /etc/redis/users.acl.<BACKUP_SUFFIX>.bak
users.acl이 이미 있을 때만 실행하고 기본 설정과 같은 <BACKUP_SUFFIX>를 사용합니다.
ACL 파일 안전하게 준비
sudo touch /etc/redis/users.acl
touch는 기존 내용을 지우지 않습니다.
ACL 파일 소유권 지정
sudo chown redis:redis /etc/redis/users.acl
ACL 파일 권한 제한
sudo chmod 600 /etc/redis/users.acl
ACL 파일 편집
sudoedit /etc/redis/users.acl
아래의 두 비밀번호 자리표시자를 서로 다른 긴 난수로 교체한 뒤 저장합니다.
Redis 메모리 검사
redis-server --test-memory 2
Redis 실행 계정 확인
getent passwd redis
설정 예시 · /etc/redis/redis.conf
같은 서버에서만 사용할 때의 네트워크 기준
bind 127.0.0.1 ::1
protected-mode yes
port 6379
aclfile /etc/redis/users.acl
원격 연결이 필요해도 모든 인터페이스에 열지 말고 Redis 서버의 사설 IP만 추가하며, 방화벽·ACL·필요 시 TLS를 함께 구성합니다.
설정 예시 · /etc/redis/users.acl
애플리케이션용 최소 권한 ACL 예시
user default off
user app on >REPLACE_WITH_LONG_RANDOM_APP_SECRET ~app:* +@read +@write +@connection -@dangerous
user redis-admin on >REPLACE_WITH_LONG_RANDOM_ADMIN_SECRET ~* +@all
두 REPLACE_WITH 값은 서로 다른 긴 난수로 교체합니다. redis-admin은 로컬 운영 점검에만 사용하고 애플리케이션에 전달하지 않습니다. 실제 app 명령·키 범위는 테스트 후 더 좁히며, Pub/Sub이 필요하면 설치된 Redis 버전에 맞춰 별도 채널 권한을 설계합니다.
  • redis.conf 원본 백업이 고유한 <BACKUP_SUFFIX>로 남아 있고 변경 기록에 접미사를 적었다.
  • protected-mode를 끄지 않았다.
  • 기본 사용자는 비활성화하고 애플리케이션 전용 ACL 사용자를 설계했다.
  • ACL 비밀번호를 코드·Git·명령 기록에 남기지 않는다.
결과 읽기

ACL을 잘못 좁히면 애플리케이션 일부 명령만 실패할 수 있습니다. 운영 적용 전 테스트 인스턴스에서 ACL LOG와 실제 기능을 확인합니다.

다음 판단

설정 파일 권한을 확인한 뒤 서비스를 시작합니다.

5
변경패키지·설정·서비스 상태가 달라지는 단계

서비스 시작과 부팅 자동 시작

설정 파일 권한을 제한하고 서비스를 시작합니다. 실패하면 반복 재시작보다 즉시 로그를 확인합니다.

변경 단계입니다. 대상 서버, 백업 파일, 서비스 중단 영향과 바로 이전 상태로 돌아가는 방법을 다시 확인하세요.
ACL 파일 소유권 지정
sudo chown redis:redis /etc/redis/users.acl
ACL 파일 권한 제한
sudo chmod 600 /etc/redis/users.acl
서비스 활성화 및 시작
sudo systemctl enable --now redis-server
서비스 상태 확인
systemctl status redis-server --no-pager
최근 로그 확인
sudo journalctl -u redis-server -n 80 --no-pager
  • 서비스가 active (running) 상태다.
  • 로그에 ACL 또는 설정 파싱 오류가 없다.
  • 부팅 자동 시작이 enabled 상태다.
결과 읽기

ACL 파일이 없거나 권한·문법이 틀리면 Redis가 시작하지 않습니다. 로그의 첫 설정 오류부터 고친 뒤 재시작합니다.

다음 판단

인증 전후 동작과 재부팅 지속성을 검증합니다.

6
확인시스템을 변경하지 않는 점검 단계

인증·포트·재부팅 후 동작 검증

무인증 요청이 거부되고, 지정한 ACL 사용자만 PING에 성공하는지 확인합니다. 비밀번호는 명령 인자가 아니라 프롬프트 또는 안전한 클라이언트 설정으로 전달합니다.

리스닝 주소 확인
sudo ss -ltnp | grep ':6379 '
무인증 요청 거부 확인
redis-cli -h 127.0.0.1 PING
NOAUTH 오류가 기대 결과입니다.
ACL 사용자 인증 확인
redis-cli --user app --askpass -h 127.0.0.1 PING
비밀번호 프롬프트에 입력하고 PONG을 확인합니다.
부팅 자동 시작 확인
systemctl is-enabled redis-server
서비스 활성 상태 확인
systemctl is-active redis-server
  • 6379가 127.0.0.1 또는 승인한 사설 IP에만 바인딩되어 있다.
  • 무인증 요청은 실패하고 app 사용자의 인증 요청은 성공한다.
  • 유지보수 재부팅 후에도 같은 결과를 다시 확인했다.
결과 읽기

redis-cli의 -a 옵션은 셸 기록이나 프로세스 목록에 비밀번호가 남을 수 있어 사용하지 않습니다. 인증 성공만으로 네트워크 공개가 안전해지는 것은 아닙니다.

다음 판단

방화벽과 최소 권한을 최종 점검합니다.

7
주의권한·연결·중단 영향을 확인할 단계

방화벽·ACL·데이터 보호 최종 점검

Redis는 신뢰할 수 있는 클라이언트가 있는 내부 환경을 전제로 합니다. 포트 차단을 1차 방어선으로 두고 ACL을 추가 방어선으로 사용합니다.

방화벽 상태 확인
sudo ufw status numbered
활성 ACL 확인
redis-cli --user redis-admin --askpass ACL LIST
ACL 오류 이력 확인
redis-cli --user redis-admin --askpass ACL LOG 10
외부 리스닝 재확인
sudo ss -ltnp | grep ':6379 '
  • 6379는 인터넷에서 접근할 수 없고 필요한 사설망 클라이언트만 허용한다.
  • protected-mode yes를 유지한다.
  • 애플리케이션 계정에서 @dangerous와 불필요한 키 패턴을 허용하지 않는다.
  • ACL 파일·RDB·AOF·백업의 파일 권한과 보관 위치를 제한한다.
  • 신뢰할 수 없는 네트워크를 통과하면 Redis TLS 또는 별도 암호화 터널을 사용한다.
결과 읽기

외부 스캐너에서 6379가 보인다면 ACL이 있어도 배포를 완료한 것으로 보지 않습니다. 먼저 네트워크 경계를 닫습니다.

다음 판단

변경 기록과 복구 명령을 운영 문서에 남깁니다.

8
주의권한·연결·중단 영향을 확인할 단계

설정 복원 또는 패키지 제거

백업 목록에서 이번 변경과 일치하는 <BACKUP_SUFFIX>를 명시적으로 선택한 뒤 redis.conf를 복원합니다. users.acl은 같은 접미사의 기존 파일 백업을 복원하거나, 이번에 새로 만든 파일을 삭제하지 않고 고유한 .disabled 파일로 이동합니다. 두 분기 모두 aclfile 참조와 실제 파일 상태가 일치해야 재시작할 수 있습니다.

서비스 중지
sudo systemctl stop redis-server
redis.conf 백업 후보 목록 확인
sudo find /etc/redis -maxdepth 1 -type f -name 'redis.conf.*.bak' -printf '%TY-%Tm-%Td %TH:%TM:%TS %p\n' | sort
변경 기록·파일 시각·내용을 대조해 복원할 한 개의 <BACKUP_SUFFIX>를 고릅니다. 최신 파일을 자동 선택하지 않습니다.
선택한 redis.conf 백업 확인
sudo test -f /etc/redis/redis.conf.<BACKUP_SUFFIX>.bak
<BACKUP_SUFFIX>는 목록에서 명시적으로 고른 값입니다. 성공하지 않으면 복원을 진행하지 않습니다.
redis.conf 백업 복원
sudo cp --preserve=all /etc/redis/redis.conf.<BACKUP_SUFFIX>.bak /etc/redis/redis.conf
선택한 백업의 내용을 먼저 검토한 뒤 실행합니다.
ACL 백업 후보 목록 확인
sudo find /etc/redis -maxdepth 1 -type f -name 'users.acl.*.bak' -printf '%TY-%Tm-%Td %TH:%TM:%TS %p\n' | sort
기존 ACL이 있던 작업은 redis.conf와 같은 <BACKUP_SUFFIX>의 ACL 백업이 있어야 합니다.
기존 ACL 백업 분기 확인
sudo test -f /etc/redis/users.acl.<BACKUP_SUFFIX>.bak
성공하면 기존 ACL 복원 분기를 실행합니다. 실패했다는 이유만으로 신규 분기로 넘어가지 말고, 변경 기록에서 이번 작업 전에 ACL이 없었음을 확인합니다.
기존 ACL 파일 복원
sudo cp --preserve=all /etc/redis/users.acl.<BACKUP_SUFFIX>.bak /etc/redis/users.acl
기존 ACL 백업 확인이 성공한 경우에만 실행합니다.
복원 ACL 소유권 재확립
sudo chown redis:redis /etc/redis/users.acl
기존 ACL 복원 분기에서만 실행합니다.
복원 ACL 권한 재확립
sudo chmod 600 /etc/redis/users.acl
기존 ACL 복원 분기에서만 실행합니다.
신규 ACL 분기 확인
sudo test ! -f /etc/redis/users.acl.<BACKUP_SUFFIX>.bak
성공하고 변경 기록상 users.acl이 이번 작업에서 새로 생성된 파일임을 확인한 경우에만 다음 명령을 실행합니다.
신규 ACL을 복구 가능하게 비활성화
sudo mv --no-clobber /etc/redis/users.acl /etc/redis/users.acl.disabled.<BACKUP_SUFFIX>
신규 ACL 분기에서만 실행하며 파일을 삭제하지 않습니다. 대상이 이미 있으면 새 고유 접미사를 정하고 절대 덮어쓰지 않습니다.
복원 설정의 ACL 참조 확인
sudo grep -E '^(aclfile|user|requirepass|bind|protected-mode)' /etc/redis/redis.conf
기존 ACL 복원 분기라면 aclfile 경로에 복원된 파일이 실제로 존재해야 합니다. 신규 ACL 비활성화 분기라면 /etc/redis/users.acl을 참조하는 aclfile 지시문이 없어야 합니다. 불일치하면 시작하지 말고 redis.conf를 다시 검토합니다.
기존 ACL 참조와 파일 일치 확인
sudo awk '$1 == "aclfile" && $2 == "/etc/redis/users.acl" { found=1 } END { exit !found }' /etc/redis/redis.conf
기존 ACL 복원 분기에서 실행하고, 이어서 /etc/redis/users.acl이 실제로 존재하며 redis 사용자가 읽을 수 있는지 확인합니다. 다른 ACL 경로를 사용하던 구성은 그 실제 경로로 교체합니다.
복원 ACL 읽기 가능 확인
sudo -u redis test -r /etc/redis/users.acl
기존 ACL 복원 분기에서만 실행하며 두 확인이 모두 성공해야 합니다.
신규 ACL 참조 제거 확인
sudo awk '$1 == "aclfile" && $2 == "/etc/redis/users.acl" { found=1 } END { exit found }' /etc/redis/redis.conf
신규 ACL 비활성화 분기에서 실행하며 종료 코드 0이어야 합니다. 실패하면 Redis를 시작하지 않습니다.
복원 후 시작
sudo systemctl start redis-server
선택한 ACL 분기의 참조·파일 확인이 모두 성공한 뒤에만 실행합니다.
신규 설치 패키지만 제거
sudo apt-get remove redis-server redis-tools
RDB/AOF와 /var/lib/redis 삭제 여부를 별도로 확인하고 purge는 사용하지 않습니다.
  • 롤백 전 현재 설정과 데이터도 별도로 보존했다.
  • 백업 목록과 변경 기록을 대조해 복원할 <BACKUP_SUFFIX>를 명시적으로 선택했다.
  • 기존 users.acl은 같은 접미사의 백업 복원·권한 재확립을 완료했다.
  • 신규 users.acl은 삭제하지 않고 고유한 .disabled 파일로 이동했으며 복원된 redis.conf가 이를 참조하지 않는다.
  • redis.conf의 aclfile 참조와 실제 ACL 파일 상태가 일치하는 것을 확인한 뒤에만 재시작했다.
  • 복원 후 PING과 애플리케이션 핵심 기능을 다시 확인했다.
  • 패키지 제거가 필요한 경우 데이터 보존·복원 책임자를 확인했다.
결과 읽기

설정 복원으로 정상화되면 변경점과 실패 원인을 비교합니다. 데이터 손상이 의심되면 자동 재시작을 반복하지 말고 백업 복원 절차로 전환합니다.

다음 판단

장애가 계속되면 포트·서비스·디스크 장애 대응 가이드로 이어갑니다.

SECURITY CHECK

운영 전 마지막 보안 점검

  • 6379를 공인 IP에 직접 공개하지 않는다.
  • 루프백 또는 승인한 사설 IP만 bind하고 protected mode를 유지한다.
  • 기본 사용자를 끄고 애플리케이션별 최소 권한 ACL을 사용한다.
  • 비밀번호는 명령 인자·Git·로그에 남기지 않고 충분히 긴 난수를 사용한다.
  • 신뢰할 수 없는 네트워크에서는 TLS나 암호화 터널을 추가한다.

COMMON ERRORS

자주 막히는 지점

서비스가 설정 오류로 시작하지 않음

증상
redis-server가 failed 상태이고 로그에 설정 행 번호가 표시됩니다.
가능한 원인
redis.conf 또는 users.acl의 문법·경로·파일 권한이 잘못된 경우가 많습니다.
확인 순서
journalctl의 첫 오류를 확인하고 백업과 비교한 뒤, ACL 파일 소유권과 권한을 다시 확인합니다.
트러블슈팅으로 이어보기

애플리케이션만 NOPERM 오류 발생

증상
PING은 성공하지만 특정 Redis 명령 또는 키 접근이 거부됩니다.
가능한 원인
ACL의 명령 카테고리나 키 패턴이 실제 사용 범위보다 좁습니다.
확인 순서
ACL LOG에서 거부된 명령을 확인하고 필요한 범위만 추가한 뒤 회귀 테스트합니다.

원격 연결 시간 초과

증상
로컬 접속은 되지만 사설망 애플리케이션 서버에서 6379 연결이 시간 초과됩니다.
가능한 원인
bind 주소, 서버 방화벽, 클라우드 보안 그룹 또는 라우팅 중 하나가 요청을 막습니다.
확인 순서
인터넷 공개로 우회하지 말고 리스닝 주소부터 사설망 경로 순서로 확인합니다.
트러블슈팅으로 이어보기

PRIMARY REFERENCES

공식 문서

설치 저장소와 지원 버전은 바뀔 수 있습니다. 검토일 이후에는 링크된 공식 문서와 현재 서버의 패키지 후보 버전을 함께 확인하세요.

TROUBLESHOOT NEXT

설치 후 문제라면 여기서 이어가세요

트러블슈팅 · SYSTEMD서비스가 시작되지 않거나 failed일 때진단 순서 보기 →트러블슈팅 · PORT CHECK특정 포트를 누가 사용 중인지 찾을 때진단 순서 보기 →트러블슈팅 · MEMORY메모리 부족과 OOM 종료를 확인할 때진단 순서 보기 →트러블슈팅 · STORAGE FIRST AIDLinux 서버 디스크가 가득 찼을 때진단 순서 보기 →

NEXT RECIPE

함께 볼 구성 레시피

MESSAGE BROKERRabbitMQ 설치·vhost·Management UI8단계로 보기 →DATABASE · 설치·설정 레시피MongoDB 설치·인증·제한된 외부 접속8단계로 보기 →데이터베이스 · 설치·설정 레시피PostgreSQL 설치와 제한된 원격 연결8단계로 보기 →

도구 빠른 검색

최근 사용한 도구를 다시 열거나, 이름과 기능으로 검색하세요.

검색어와 도구의 입력·결과는 저장하지 않습니다.

↑↓ 이동 · Enter 열기 · Esc 닫기