Redis Enterprise 6.2.4에는 노드 간 암호화가 도입되었습니다. Redis Enterprise의 노드 간 암호화 범위는 다음을 포함하여 노드 간의 모든 내부 Redis 클러스터 연결에 대해 TLS 암호화를 달성하는 것입니다.
- CCS(클러스터 구성 저장소) 복제를 암호화하기 위해 제어 평면 연결을 향상합니다.
- 복제 노드에서 기본 노드 CCS로의 모든 연결
- 노드 간 샤드 복제를 암호화하기 위한 데이터 플레인 연결.
- 노드 간의 샤드 연결에 대한 모든 프록시
Redis Enterprise:설계 고려 사항
Redis Enterprise는 여러 기술을 사용하여 성능과 가용성을 최적화합니다. Redis 클러스터는 비공유 아키텍처를 사용하여 안정성과 가용성을 높이고 노드를 쉽게 추가 및 제거할 수 있습니다. 모든 노드 간 연결을 암호화해야 한다는 요구 사항에 접근할 때 팀은 가용성과 운영 단순성에 중점을 두었습니다.
Redis Enterprise와 같은 분산형 상시 가동 시스템은 많은 미션 크리티컬 애플리케이션을 지원합니다. 최고 수준의 운영 가용성을 충족해야 합니다. Redis Enterprise로 구동되는 Redis Cloud는 99.999%의 가용성을 제공하므로 일년에 몇 분 동안만 다운될 수 있습니다. 노드 간 클러스터 통신은 쿼럼(제어 경로 작업)을 유지하고 Redis 복제(데이터 경로 작업)를 활성화하는 데 중요합니다. 따라서 노드간 통신의 신뢰성을 항상 유지하기 위해서는 고가용성이 필수적입니다.
사설 인증 기관(CA)이란 무엇입니까?:
사설 인증 기관(CA) 공개적으로 신뢰할 수 있는 CA처럼 작동하는 클러스터별 인증 기관입니다. Redis 클러스터는 각 노드에 대해 다른 사설 인증서를 발급할 수 있는 자체 사설 루트 인증서를 생성합니다. 사설 CA에서 발급한 사설 인증서는 공개적으로 신뢰할 수 없습니다. 사설 CA는 클러스터 외부에 노출되지 않습니다. 사설 CA는 Redis 클러스터 간에 또는 외부 클라이언트나 서비스와 공유되지 않습니다. 사설 CA에서 서명한 인증서(최종 엔티티 인증서)는 발급된 노드에만 적용됩니다.
Redis Enterprise에서 활용되는 사설 CA는 원활한 내부 자체 회전 메커니즘을 제공합니다. 인증서 교체는 만료되기 전에 자동으로 수행됩니다. 인증서 교체는 REST API를 통해 요청 시 수행할 수도 있습니다. 애플리케이션, 데이터베이스 및 보안 팀의 모니터링을 위해 경고도 제공됩니다. 사설 CA는 인증서 교체를 위해 외부 CA 가용성에 대한 종속성을 제거하여 잠재적인 실패 지점을 제거하고 클러스터의 전체 가용성을 향상시킵니다.
Redis Enterprise는 노드 간 암호화에 필요한 인증서를 관리하기 위해 사설 인증 기관(CA)을 사용하여 이를 달성합니다. 고객은 일반적으로 사설 CA 사용과 관련하여 다음과 같은 주요 우려 사항을 가지고 있습니다.
고객 우려 사항:
- 자체 서명된 인증서나 사설 CA는 우리 환경에서 허용되지 않습니다.
- 사설 CA는 공개적으로 신뢰할 수 없으므로 외부 통신에 대한 신뢰를 설정할 수 없습니다.
- 사설 CA는 종종 침해로부터 적절히 보호되지 않습니다.
첫 번째 문제는 보안 문제가 아닙니다. 이것은 준수 요구 사항입니다. 많은 조직에서 자체 서명된 인증서가 최선의 선택인 유효한 사용 사례를 고려하지 않고 자체 서명된 인증서를 완전히 허용하지 않는 포괄적인 정책을 작성했습니다. 이 요구 사항은 많은 경우에 의미가 있지만 전부는 아니며 동일한 조직에서 포괄적인 정책이 적합하지 않은 경우에 대해 제외를 허용하는 심층 프로세스를 요구하게 되었습니다. 한 가지 예는 Redis Enterprise 노드 간 암호화입니다. 이 특정 예에서 사설 CA는 특정 용도로 사용됩니다.
먼저 자체 서명된 인증서를 정의하겠습니다. . 자체 서명된 인증서는 공개적으로 신뢰할 수 있는 타사 CA에서 서명하지 않은 인증서입니다. 이 유형의 인증서는 인증서가 발급된 웹 사이트 또는 애플리케이션을 담당하는 조직에서 생성, 발급 및 서명합니다. 이러한 인증서는 신뢰할 수 있는 타사 CA에서 발급한 인증서와 동일한 암호를 자유롭게 발급하고 사용할 수 있습니다.
다음과 같이 자문할 수 있습니다. "조직에서 자체 서명된 인증서의 사용을 허용하지 않는 경우 대안은 무엇입니까?" 일반적인 대안은 신뢰할 수 있는 타사 CA에서 발급한 인증서를 사용하는 것입니다. 조직은 신뢰할 수 있는 여러 타사에서 이러한 인증서를 구입한 다음 해당 웹 사이트 또는 응용 프로그램에 인증서를 발급할 수 있습니다. 신뢰할 수 있는 타사 CA에서 발급한 인증서는 보안에 관한 한 자체 서명된 인증서와 동일합니다.
다음 질문은 다음과 같습니다. 자체 서명된 인증서와 신뢰할 수 있는 타사 CA에서 발급한 인증서 사이에 차이점이 있다면 무엇입니까? 각 인증서는 동일한 암호를 지원합니다. 각각은 루트, 중간 및 리프 인증서로 구성됩니다. 각각은 필요에 따라 만료되거나 취소될 수도 있습니다. 유일한 차이점은 자체 서명된 인증서와 신뢰할 수 있는 타사 CA에서 발급한 인증서 간의 기능적 차이점입니다. 그 기능은 신뢰입니다. 신뢰할 수 있는 타사 CA는 관련 없는 두 엔터티 간에 신뢰를 설정하는 데 사용할 수 있는 인증서를 발급할 수 있습니다.
신뢰는 언제 필요한가? 두 개의 관련 없는 엔터티가 통신할 때 신뢰는 솔루션의 필수 부분입니다. 이에 대한 좋은 예는 웹 브라우저와 웹 애플리케이션 간의 통신입니다. 신뢰할 수 있는 타사 CA 발급 인증서를 사용하면 암호화된 통신이 가능하지만 웹 브라우저가 웹 응용 프로그램이 실제로 누구인지 알 수 있습니다. 결과적으로 브라우저는 사용자가 웹 응용 프로그램을 신뢰하고 통신을 계속할 것인지 묻는 메시지를 표시합니다.
신뢰가 필요하지 않은 경우는? 두 개의 관련 엔터티가 통신할 때 신뢰는 솔루션의 필수 부분이 아닙니다. Redis Enterprise의 노드 간 암호화는 이러한 유형의 통신에 대한 좋은 예입니다. Redis Enterprise는 하나의 클러스터로 구성되며 단일 클러스터에는 여러 노드가 포함될 수 있습니다. 또한 노드에는 단일 또는 다중 데이터베이스가 있을 수 있습니다. 각 노드가 동일한 클러스터에 속하기 때문에 신뢰를 구축하기 위해 제3자가 필요하지 않습니다. 각 노드는 동일한 클러스터에 속해 있기 때문에 이미 다른 모든 노드를 신뢰합니다.
Redis 엔터프라이즈 솔루션:
Redis Enterprise는 사설 CA 생성 인증서가 클러스터 내에서만 사용되기 때문에 이러한 규정 준수 및 보안 문제를 완화합니다. 각 노드는 동일한 클러스터 내의 다른 모든 노드에 의해 알려져 있고 신뢰되기 때문에 타사의 신뢰할 수 있는 CA는 Redis 클러스터 내에서 신뢰를 설정하는 데 아무 것도 추가하지 않으며 필요하지 않습니다.