Redis Enterprise 6.2.4는 노드 간 암호화(internode encryption) 기능을 새롭게 도입했습니다. Redis Enterprise에서 노드 간 암호화의 목표는 클러스터 내 모든 내부 연결에 TLS 암호화를 적용하는 것이며, 그 범위는 다음과 같습니다.
- 제어 평면(control plane) 연결 강화 – CCS(클러스터 구성 저장소) 복제 암호화
- 복제본 노드에서 프라이머리 노드의 CCS로 향하는 모든 연결
- 데이터 평면(data plane) 연결 – 노드 간 샤드(shard) 복제 암호화
- 노드 간 모든 프록시–샤드(proxy-to-shard) 연결
Redis Enterprise의 설계 고려 사항
Redis Enterprise는 성능과 가용성을 최적화하기 위해 다양한 기술을 활용합니다. Redis 클러스터는 shared-nothing 아키텍처를 채택하여 신뢰성과 가용성을 높이고, 노드 추가·제거를 손쉽게 수행할 수 있습니다. 모든 노드 간 연결을 암호화해야 한다는 요구 사항에 직면했을 때, 개발팀은 가용성과 운영 편의성에 초점을 맞추었습니다.
Redis Enterprise와 같은 분산형 상시 가동(always-on) 시스템은 수많은 미션 크리티컬 애플리케이션을 지원하므로, 최고 수준의 운영 가용성을 충족해야 합니다. Redis Enterprise 기반의 Redis Cloud는 99.999% 가용성을 제공하며, 이는 연간 다운타임이 몇 분에 불과하다는 의미입니다. 노드 간 클러스터 통신은 쿼럼(quorum) 유지(제어 경로 작업)와 Redis 복제(데이터 경로 작업)에 필수적입니다. 따라서 언제나 노드 간 통신의 신뢰성을 유지할 수 있는 높은 가용성 확보가 반드시 필요합니다.
프라이빗 CA(Private Certificate Authority)란?
프라이빗 CA(Private Certificate Authority)는 공인 CA처럼 작동하는 클러스터 전용 인증 기관입니다. Redis 클러스터는 자체 프라이빗 루트 인증서를 생성하며, 이를 통해 각 노드에 대한 다른 프라이빗 인증서를 발급할 수 있습니다. 프라이빗 CA가 발급한 인증서는 공개적으로 신뢰받지 않으며, 프라이빗 CA는 클러스터 외부에 노출되지 않습니다. 또한 Redis 클러스터 간에 공유되거나 외부 클라이언트·서비스와 공유되지 않습니다. 프라이빗 CA가 서명한 인증서(엔드 엔터티 인증서)는 해당 인증서가 발급된 노드에만 사용됩니다.
Redis Enterprise에서 활용되는 프라이빗 CA는 원활한 내부 자체 갱신(self-rotation) 메커니즘을 제공합니다. 인증서 갱신은 만료 전에 자동으로 수행되며, REST API를 통해 요청 시에도 수행할 수 있습니다. 아울러 애플리케이션, 데이터베이스, 보안 팀의 모니터링을 위한 알림 기능도 함께 제공됩니다. 프라이빗 CA는 인증서 갱신 시 외부 CA의 가용성에 대한 의존성을 제거하여 잠재적인 장애 지점을 없애고, 클러스터 전체 가용성을 한층 향상시킵니다.
Redis Enterprise는 프라이빗 CA를 활용해 노드 간 암호화에 필요한 인증서를 관리함으로써 이러한 목표를 달성합니다. 다만 고객들은 일반적으로 프라이빗 CA 사용과 관련해 다음과 같은 주요 우려 사항을 가지고 있습니다.
고객의 주요 우려 사항
- 당사 환경에서는 자체 서명 인증서나 프라이빗 CA를 허용하지 않습니다.
- 프라이빗 CA는 공개적으로 신뢰받지 못하므로 외부 통신에 대한 신뢰를 구축할 수 없습니다.
- 프라이빗 CA는 침해(컴프로마이즈)에 대한 보호가 충분하지 않은 경우가 많습니다.
첫 번째 우려 사항은 사실 보안 문제가 아니라 규정 준수(compliance) 요건입니다. 많은 조직이 자체 서명 인증서가 최선의 선택일 수 있는 타당한 사용 사례를 고려하지 않은 채, 이를 일괄적으로 금지하는 포괄적인 정책을 수립합니다. 이러한 요구 사항은 많은 경우 타당하지만 모든 경우에 적합한 것은 아니며, 그 결과 동일한 조직들이 포괄적 정책이 맞지 않는 사례에 대해 예외를 승인하기 위한 별도의 심층 절차를 운영하게 됩니다. 그 대표적인 예가 바로 Redis Enterprise의 노드 간 암호화입니다. 이 특정 사례에서 프라이빗 CA는 명확하고 특수한 목적을 수행합니다.
먼저 자체 서명 인증서(self-signed certificate)를 정의해 보겠습니다. 자체 서명 인증서란 공인된 제3자 CA가 서명하지 않은 인증서를 말합니다. 이러한 인증서는 해당 인증서가 발급되는 웹사이트나 애플리케이션을 담당하는 조직이 직접 생성·발급·서명합니다. 자체 서명 인증서는 무료로 발급할 수 있으며, 신뢰할 수 있는 제3자 CA가 발급한 인증서와 동일한 암호화 알고리즘(cipher)을 사용합니다.
"조직이 자체 서명 인증서 사용을 허용하지 않는다면 어떤 대안이 있을까?"라고 스스로에게 물어볼 수 있습니다. 일반적인 대안은 신뢰할 수 있는 제3자 CA가 발급한 인증서를 사용하는 것입니다. 조직은 다양한 신뢰할 수 있는 제3자 CA로부터 인증서를 구매한 후 자신의 웹사이트나 애플리케이션에 적용할 수 있습니다. 신뢰할 수 있는 제3자 CA가 발급한 인증서는 보안 측면에서 자체 서명 인증서와 동일합니다.
다음으로 던져야 할 질문은 "자체 서명 인증서와 신뢰할 수 있는 제3자 CA가 발급한 인증서 사이에 과연 어떤 차이가 있는가?"입니다. 두 인증서 모두 동일한 암호화 알고리즘을 지원하며, 루트(root)·중간(intermediate)·리프(leaf) 인증서 체계로 구성됩니다. 또한 필요에 따라 만료되거나 폐기(revoke)될 수도 있습니다. 유일한 차이점은 기능적 차이이며, 그 기능이 바로 '신뢰(trust)'입니다. 신뢰할 수 있는 제3자 CA는 서로 관련 없는 두 개체 간에 신뢰를 구축하는 데 사용할 수 있는 인증서를 발급할 수 있습니다.
신뢰가 필요한 경우와 필요하지 않은 경우
서로 관련 없는 두 개체가 통신할 때 신뢰는 솔루션의 필수 요소입니다. 좋은 예가 웹 브라우저와 웹 애플리케이션 간의 통신입니다. 제3자 신뢰 CA가 발급한 인증서를 사용하면 암호화된 통신이 가능할 뿐만 아니라, 웹 브라우저가 해당 웹 애플리케이션이 실제로 자신이 주장하는 주체인지 확인할 수 있습니다. 그 결과 브라우저는 사용자에게 해당 웹 애플리케이션을 신뢰하며 통신을 계속할 것인지 묻는 안내를 표시하게 됩니다.
그렇다면 신뢰가 필요하지 않은 경우는 언제일까요? 서로 관련 있는 두 개체가 통신할 때에는 신뢰가 필수 요소가 아닙니다. Redis Enterprise의 노드 간 암호화가 바로 이러한 통신 유형의 대표적인 예입니다. Redis Enterprise는 하나의 클러스터로 구성되며, 단일 클러스터는 여러 노드를 포함할 수 있습니다. 하나의 노드에 단일 또는 여러 데이터베이스가 존재할 수도 있습니다. 각 노드는 동일한 클러스터에 속해 있으므로 신뢰를 구축하기 위해 제3자가 필요하지 않습니다. 각 노드는 같은 클러스터에 속해 있다는 이유만으로 이미 다른 모든 노드를 신뢰합니다.
Redis Enterprise의 해결 방안
Redis Enterprise는 프라이빗 CA가 생성한 인증서가 오직 클러스터 내부에서만 사용되기 때문에, 앞서 언급한 규정 준수 및 보안 우려를 효과적으로 해소합니다. 각 노드는 동일한 클러스터 내의 다른 모든 노드에 의해 식별되고 신뢰받으므로, Redis 클러스터 내부에서 신뢰를 구축하는 데 제3자 신뢰 CA는 아무런 역할도 하지 않으며 굳이 필요하지 않습니다.