← 목록

ElastiCache 접속 보안 구조: AUTH Token + TLS 이중 보안

ElastiCache Valkey의 인증 토큰과 전송 암호화가 각각 무엇을 막는지, 토큰 로테이션이 왜 두 단계인지 정리

2026-04-23AWSElastiCacheValkeySecurityTLS

들어가며

캐시 서버에 보안 설정이 두 개 걸려 있다는 건 알고 있었다. 그런데 "그 둘이 각각 무엇을 막느냐"는 질문을 받고 나서 설명이 매끄럽게 나오지 않았다. 둘 다 보안이라는 것 말고는, 왜 하나로는 부족한지를 말하지 못했다.

계기는 장애였다. AUTH Token 로테이션을 절차 중간까지만 진행한 상태가 한 달 가까이 유지되다가, Task가 재시작되는 순간 서비스가 crash loop에 빠졌다(AUTH TOKEN 로테이션 미완료 장애 분석). 설정 자체는 문서대로였는데도 문제가 생겼다는 점이 걸렸다. 그래서 구조를 처음부터 다시 정리했다.

두 계층이 각각 막는 것

인증 토큰은 "누가 들어오는가"를 막는다

캐시 서버에 접속할 때 사전에 설정된 인증 토큰을 제출해야 한다. 토큰이 없거나 틀리면 접속 자체가 거부된다. 이 토큰은 Secrets Manager에 저장되어 있고, 애플리케이션이 시작될 때 주입받는다.

토큰이 없다면 방어선은 네트워크 하나뿐이다. 보안 그룹과 서브넷으로 VPC 안에서만 접근할 수 있게 막아두는 방식인데, 이건 "우리 네트워크 안은 안전하다"는 전제 위에 서 있다. 보안 그룹 규칙 하나가 잘못 열리거나, 같은 VPC의 다른 인스턴스가 침해되면 그 전제가 바로 무너진다. 캐시에는 권한 정보 같은 것들이 들어 있어서, 읽히는 것만으로도 문제가 된다.

TLS는 "무엇이 오가는가"를 가린다

애플리케이션과 캐시 서버 사이의 모든 통신이 TLS로 암호화된다. HTTPS와 같은 방식이다.

TLS가 없으면 데이터만 노출되는 게 아니다. 인증 토큰 자체가 평문으로 흘러간다. 접속할 때마다 토큰을 그대로 실어 보내기 때문에, 패킷을 한 번 잡는 것만으로 토큰이 넘어간다. 토큰을 아무리 길고 복잡하게 만들어도 소용이 없어진다.

보안 계층막는 것없을 때 벌어지는 일
인증 토큰접속 권한네트워크 경계만 뚫리면 누구나 데이터 접근
TLS 암호화통신 내용데이터와 토큰이 함께 평문 노출

둘은 서로를 대신하지 못한다. 토큰만 있으면 그 토큰이 새고, TLS만 있으면 암호화된 채널로 아무나 들어온다.

접속 보안 흐름

[ECS Task]
  │
  │ 1. Secrets Manager에서 AUTH Token 주입 (환경변수)
  │ 2. rediss:// (TLS) 프로토콜로 접속 시도
  │
  ▼
[ElastiCache Valkey]
  │
  │ 3. TLS 핸드셰이크 → 암호화 채널 수립
  │ 4. AUTH Token 검증 → 접속 허용/거부
  │
  ▼
[정상 접속, 암호화된 채널에서 데이터 송수신]

순서가 중요하다. TLS 채널이 먼저 서고, 그 안에서 토큰이 오간다. 그래서 rediss://가 아니라 redis://로 접속하도록 설정 하나만 잘못 두면, 인증은 정상 동작하는 것처럼 보이면서 토큰만 노출되는 상태가 된다. 동작하니까 아무도 모른다.

왜 로테이션이 두 단계인가

토큰을 바꾸는 일이 한 번에 끝나지 않는 이유가 이 구조의 핵심이다. 캐시 서버와 애플리케이션은 서로 다른 시점에 새 토큰을 알게 되기 때문에, 그 사이를 이어주는 구간이 필요하다.

AUTH Token 로테이션 구간

즉 ROTATE는 문을 하나 더 다는 작업이고, SET은 옛 문을 떼는 작업이다. 그 사이에 사람이 해야 하는 일(갱신과 재배포)이 들어 있어서, 중간에 멈추면 멈춘 채로 유지된다.

중간에서 멈추면 생기는 상태

어디까지 했나겉보기실제 상태
ROTATE만 실행정상 동작옛 토큰으로 계속 접속 중, 새 토큰은 아무도 안 씀
ROTATE + Secrets Manager 갱신, 재배포 누락정상 동작실행 중인 Task는 여전히 옛 토큰, 새로 뜨는 Task만 새 토큰
SET을 먼저 실행즉시 장애옛 토큰을 쓰던 모든 연결이 한 번에 거부

첫 번째와 두 번째가 위험한 이유는 즉시 아무 일도 일어나지 않기 때문이다. 이미 맺어진 연결은 계속 살아 있어서 며칠이든 몇 주든 정상으로 보인다. 그러다 배포나 스케일 아웃, 플랫폼 패치 같은 이유로 Task가 새로 뜨는 순간 인증이 실패한다. 원인을 만든 시점과 증상이 드러나는 시점이 멀리 떨어져 있어서 추적이 어렵다.

ECS Task는 시작할 때 한 번만 받아온다

이 잠복을 만드는 조건이 하나 더 있다. ECS Task는 Secrets Manager의 값을 시작 시점에 환경변수로 주입받고, 실행 중에는 다시 읽지 않는다.

Secrets Manager 값 변경
        │
        │  (실행 중인 Task는 영향 없음)
        ▼
Task 재시작 / 새 배포
        │
        ▼
변경된 값으로 접속 시도  ← 여기서 처음 검증된다

그래서 "비밀값을 바꿨다"와 "애플리케이션이 그 값을 쓴다" 사이에는 반드시 재배포가 들어간다. 토큰 변경 절차를 ROTATE, Secrets Manager 갱신, 재배포, SET 네 단계로 적어두는 이유다.

점검할 때 보는 것

정상으로 보이는 상태와 실제로 끝난 상태를 구분하려면 아래를 확인한다.

핵심 정리

배운 점

인증과 암호화는 비슷해 보여도 막는 것이 다르다. AUTH Token은 누가 들어올 수 있는지를 정하고, TLS는 오가는 내용을 감춘다. 이걸 구분하고 나니 보안 설정을 볼 때 "무엇을 켰는가"가 아니라 "어떤 공격 경로를 닫았는가"로 묻게 됐다.

위험한 건 설정이 아니라 변경 절차였다. 이 구조에서 실제로 사고가 난 지점은 토큰의 길이나 TLS 설정이 아니라, 두 단계로 나뉜 절차의 중간이었다. 여러 단계로 이뤄진 작업은 중간에서 멈출 수 있고, 멈춘 상태가 정상처럼 보이면 아무도 알아채지 못한다. 그래서 절차를 적을 때 마지막 항목은 "끝났는지 확인하는 방법"이어야 한다는 결론에 도달했다.

같은 성격의 문제를 다른 곳에서도 본다. Access Key에서 IAM Role 기반 인증으로 전환에서 남겨둔 장기키의 로테이션도, SES CloudTrail 데이터 이벤트 활성화에서 CLI로만 적용하고 Terraform에 반영하지 못한 구간도, 모두 "중간 상태"가 문제였다.

이어 읽기