donghyeon.kang/llm-wiki

Fork 0

Files

T

DongHyeonka 58515ab0f3 feat: 공식 문서 근거자료, 브랜치 기능 문서 작성

2026-07-29 18:05:17 +09:00

11 KiB

Raw Blame History

title, source_type, url, archive_url, related_branches, related_projects, tags, created

title

source_type

url

archive_url

related_branches

related_projects

official-doc / Redis — TLS (Encryption in Transit)

Layer: raw/ — 외부 자료(공식 문서 / 대기업 기술 블로그)의 원문 발췌·출처 기록. 본 템플릿은 raw/official-docs/ 와 raw/company-tech-blogs/ 두 폴더가 공유. 검증된 요약은 /ingest 후 wiki/concepts/에 source-summary-template 형식으로 별도 작성. 원본은 raw에 영구 보관.

source_type 허용값

official-doc — Redis 공식 레퍼런스 (redis.io/docs, oss_and_stack).

Parent / 활용 branch

Branch	이 자료가 정당화하는 결정
raw/branch-notes/feature-redis-runtime-role-isolation-contract	production 에서 role 별 Redis 연결에 TLS(mutual TLS 포함) + 명시적 trust bundle(CA cert)을 요구하고, `port 0` + `tls-port` 로 plaintext downgrade 를 startup 에서 원천 차단하며, replication/cluster bus 채널도 별도 TLS 플래그(`tls-replication`/`tls-cluster`)로 각각 켜야 한다는 결정의 근거

출처

원본 URL: https://redis.io/docs/latest/operate/oss_and_stack/management/security/encryption/
아카이브 URL: (미등록)
저자 / 조직: Redis (공식 문서, redis.io)
발행일: (페이지에 명시 없음 — redis.io docs 는 버전별 업데이트, 게시일 미표기)
마지막 확인일: 2026-07-28

왜 저장했는지

Redis 서버 자체가 TLS 를 컴파일 타임 옵션으로 지원하며 기본적으로 켜져 있지 않다는 것, port 0/tls-port 조합으로 plaintext 를 완전히 차단하는 방법, mutual TLS 가 (TLS 활성화 시) 기본 동작이라는 것, 그리고 replication/cluster 채널은 client-facing tls-port 와 별개로 각각 켜야 한다는 것을 검증하기 위해 보관. feature-redis-runtime-role-isolation-contract 의 role 별 TLS 강제 결정의 1차 근거.

핵심 인용

[§Getting Started] "SSL/TLS is supported by Redis starting with version 6 as an optional feature" [...] "that needs to be enabled at compile time."

[§TLS listening port] "You may specify port 0 to disable the non-TLS port completely."

[§Client certificate authentication] "By default, Redis uses mutual TLS and requires clients to authenticate with a" [...] "valid certificate (authenticated against trusted root CAs specified by" [...] "ca-cert-file or ca-cert-dir)." [...] "You may use tls-auth-clients no to disable client authentication."

[§Replication] "On the replica server side, it is necessary to specify tls-replication yes to" [...] "use TLS for outgoing connections to the master."

[§Cluster] "When Redis Cluster is used, use tls-cluster yes in order to enable TLS for the" [...] "cluster bus and cross-node connections."

[§Performance considerations] "TLS adds a layer to the communication stack with overheads due to writing/reading to/from an SSL connection, encryption/decryption and integrity checks." [...] "using TLS results in a decrease of the achievable throughput per Redis instance"

Claims Extracted

Claim ID	Claim (이 자료가 직접 말하는 것)	Evidence quote	Strength	Applies to	Does not prove
REDIS-TLS-C1	Redis 의 SSL/TLS 지원은 버전 6부터 시작된 컴파일 타임(`BUILD_TLS=yes`) 옵션 기능이며 기본 활성 상태가 아니다	[§Getting Started] "SSL/TLS is supported by Redis starting with version 6 as an optional feature that needs to be enabled at compile time."	`official-vendor-doc`	Redis OSS/Stack 서버 바이너리가 TLS 를 지원하려면 별도 빌드 플래그가 필요하다는 사실	특정 배포판(managed Redis, Docker 공식 이미지 등)이 기본적으로 TLS 지원 빌드인지 여부는 증명하지 않음 — 배포 환경별 확인 필요
REDIS-TLS-C2	`port 0` 로 non-TLS 포트를 완전히 끄고 `tls-port` 만 열어 plaintext 연결을 원천 차단할 수 있다	[§TLS listening port] "You may specify `port 0` to disable the non-TLS port completely."	`official-vendor-doc`	production 에서 plaintext downgrade 를 startup 설정으로 차단하는 방법의 근거	`tls-port` 만으로 인증서 검증 강도(hostname verification 등)까지 보장한다는 뜻은 아님 — 이 문서는 hostname verification 을 언급하지 않음
REDIS-TLS-C3	TLS 활성화 시 Redis 는 기본적으로 mutual TLS 를 사용하며 신뢰 루트 CA 로 검증된 유효 클라이언트 인증서를 요구하고, 이 요구는 `tls-auth-clients no` 로 명시적으로 꺼야만 해제된다	[§Client certificate authentication] "By default, Redis uses mutual TLS and requires clients to authenticate with a valid certificate (authenticated against trusted root CAs specified by `ca-cert-file` or `ca-cert-dir`)." + "You may use `tls-auth-clients no` to disable client authentication."	`official-vendor-doc`	서버가 클라이언트 인증서를 요구하는 기본값(opt-in 아니라 opt-out)이라는 것, trust-all 이 기본이 아니라는 것	hostname verification(서버 인증서의 CN/SAN이 접속 hostname과 일치하는지 검증)은 이 문서에 전혀 언급되지 않음 — mutual TLS(클라이언트 인증) 과 hostname verification(서버 인증 강화) 은 별개 개념이며, 후자는 클라이언트 라이브러리(Lettuce/Jedis 등) 설정에서 별도로 검증 필요. `UNSUPPORTED_DECISION` — 이 문서만으로 hostname verification 요구를 정당화할 수 없음
REDIS-TLS-C4	replication 링크는 client-facing `tls-port`/`tls-auth-clients` 설정을 그대로 상속하지만, replica 가 master 로의 outbound 연결에 TLS 를 쓰려면 replica 측에서 별도로 `tls-replication yes` 를 명시해야 한다	[§Replication] "On the replica server side, it is necessary to specify `tls-replication yes` to use TLS for outgoing connections to the master."	`official-vendor-doc`	replication 채널이 client 채널과 별개의 명시적 opt-in 플래그를 요구한다는 근거	이 프로젝트의 role(cache/coordination/session)별 replication 토폴로지가 실제로 존재하는지, Spring Data Redis 클라이언트 설정에서 이 서버 플래그가 어떻게 매핑되는지는 증명하지 않음
REDIS-TLS-C5	Redis Cluster 사용 시 `tls-cluster yes` 를 명시해야 cluster bus 와 cross-node 연결에 TLS 가 적용된다	[§Cluster] "When Redis Cluster is used, use `tls-cluster yes` in order to enable TLS for the cluster bus and cross-node connections."	`official-vendor-doc`	cluster bus 채널이 client-facing TLS 설정과 별개의 명시적 opt-in 플래그를 요구한다는 근거	이 프로젝트가 Redis Cluster 토폴로지를 실제로 쓰는지(vs standalone/Sentinel) 는 증명하지 않음 — 이 branch 의 role 분리 결정과 무관하게 배포 토폴로지 별개 확인 필요
REDIS-TLS-C6	TLS 는 SSL 연결에 대한 write/read, 암복호화, 무결성 검사 오버헤드로 인해 Redis 인스턴스의 처리 가능 처리량(throughput)을 감소시킨다	[§Performance considerations] "TLS adds a layer to the communication stack with overheads due to writing/reading to/from an SSL connection, encryption/decryption and integrity checks. Consequently, using TLS results in a decrease of the achievable throughput per Redis instance"	`official-vendor-doc`	production 에서 TLS 적용이 성능 trade-off 를 수반한다는 사실 인정의 근거	구체적 처리량 감소 수치(%, latency 등)는 이 페이지에 없음 — 문서는 GitHub 논의(#7595) 로 위임, 수치는 별도 벤치마크 필요

Usage Boundaries

적용 가능: production Redis 연결에 대해 (1) port 0 + tls-port 로 plaintext 리스너를 완전히 제거하고, (2) TLS 활성화 시 mutual TLS(클라이언트 인증서)가 기본이며 tls-auth-clients no 로만 해제 가능하다는 사실, (3) replication(tls-replication yes)과 cluster bus(tls-cluster yes)는 client-facing TLS 와 독립적으로 각각 켜야 한다는 사실, (4) TLS 가 처리량 저하 비용을 수반한다는 사실 — 이 4가지는 이 문서만으로 정당화 가능.
적용 불가 / UNSUPPORTED_DECISION: "hostname verification"을 요구한다는 branch 결정은 이 문서만으로 정당화되지 않는다. 이 페이지는 mutual TLS(클라이언트→서버 인증서 인증)와 CA trust bundle(tls-ca-cert-file)만 다루며, "서버 인증서의 hostname/SNI/CN 매칭"에 대한 서술이 전혀 없다(§본문 self-grep 결과 hostname, verify 키워드 0건). hostname verification 은 통상 클라이언트 라이브러리(Lettuce SslOptions.verifyPeer 등) 레벨 설정이므로, branch 가 이 요구를 유지하려면 별도의 클라이언트 라이브러리 공식 문서를 추가 근거로 확보해야 한다.
trust-all 거절: tls-auth-clients 는 서버가 클라이언트를 신뢰할지에 대한 스위치일 뿐, 클라이언트가 서버를 무조건 신뢰(trust-all)하지 않도록 막는 것은 클라이언트 측 설정 영역이라 이 문서 범위 밖.
이 프로젝트에 적용하려면 추가 확인 필요: Spring Data Redis / Lettuce 클라이언트가 이 서버 플래그들(tls-port, tls-auth-clients, tls-replication, tls-cluster)에 대응하는 자체 설정(RedisStandaloneConfiguration, SslOptions, hostname verification mode 등)이 실제로 무엇인지는 별도 official-doc(Spring Data Redis / Lettuce) 확보 필요.

메모

이 문서는 Redis 서버(redis-server) 측 TLS 설정만 다룬다. 클라이언트(애플리케이션) 측 hostname verification·trust store 구성은 다른 공식 문서(Lettuce/Jedis)로 별도 보강 필요 — branch 결정의 "hostname verification" 부분은 현재 UNSUPPORTED_DECISION 상태.
tls-replication/tls-cluster 는 client 채널(tls-port)과 독립적인 opt-in 이므로, role 별(cache/coordination/session) 배포에서 replication 이나 cluster 를 쓰는 role 이 있다면 각각 별도로 켜야 한다는 점을 구현 가이드에 명시할 근거로 쓸 수 있음.
추가로 봐야 할 동일 출처 페이지: Redis ACL 공식 문서(role 별 ACL 격리 근거), Lettuce/Jedis SSL 옵션 공식 문서(hostname verification 근거).

11 KiB Raw Blame History