전송 중 암호화 활성화 시 모범 사례 - Amazon ElastiCache
전송 중 데이터 암호화를 활성화하기 전: DNS 레코드를 올바르게 처리했는지 확인하세요.전송 중 데이터 암호화 중: 마이그레이션 프로세스가 언제 완료되는지에 주의 기울이기

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

전송 중 암호화 활성화 시 모범 사례

전송 중 데이터 암호화를 활성화하기 전: DNS 레코드를 올바르게 처리했는지 확인하세요.

참고

이 프로세스에서 기존 엔드포인트를 변경 및 삭제합니다. 엔드포인트를 잘못 사용하면 Valkey 또는 Redis OSS 클라이언트가 이전 엔드포인트 및 삭제된 엔드포인트를 사용하여 클러스터에 연결하지 못하게 될 수 있습니다.

클러스터가 no-TLS에서 TLS 선호로 마이그레이션되는 동안 이전 클러스터 구성 엔드포인트 DNS 레코드가 유지되고 새 클러스터 구성 엔드포인트 DNS 레코드가 다른 형식으로 생성됩니다. TLS 지원 클러스터는 TLS 비활성화 클러스터와 다른 형식의 DNS 레코드를 사용합니다. ElastiCache는 클러스터가에 구성된 경우 두 DNS 레코드를 모두 유지encryption mode: Preferred하므로 애플리케이션과 다른 Valkey 또는 Redis OSS 클라이언트가 서로 전환할 수 있습니다. DNS 레코드의 다음 변경 사항은 TLS 마이그레이션 프로세스 중에 발생합니다.

전송 중 데이터 암호화를 활성화할 때 발생하는 DNS 레코드의 변경 사항에 대한 설명

CME 클러스터의 경우

클러스터가 '전송 암호화 모드: 선호'로 설정된 경우:

  • 비 TLS 클러스터의 원래 클러스터 구성 엔드포인트는 활성 상태로 유지됩니다. 클러스터를 TLS 암호화 모드 '없음'에서 '선호'로 재구성해도 가동 중지가 발생하지 않습니다.

  • 클러스터를 TLS 선호 모드로 설정하면 새 TLS Valkey 또는 Redis OSS 엔드포인트가 생성됩니다. 이러한 새 엔드포인트는 이전 엔드포인트와 동일한 IP(비 TLS)로 변환됩니다.

  • 새로운 TLS Valkey 또는 Redis OSS 구성 엔드포인트는 ElastiCache 콘솔에서 및 describe-replication-group API에 대한 응답으로 노출됩니다.

클러스터가 '전송 암호화 모드: 필수'로 설정된 경우:

  • TLS가 지원되지 않는 이전 엔드포인트는 삭제됩니다. TLS 클러스터 엔드포인트의 가동 중지는 없습니다.

  • ElastiCache 콘솔 또는 describe-replication-group API에서 새 cluster-configuration-endpoint를 검색할 수 있습니다.

자동 장애 조치가 활성화되었거나 자동 장애 조치가 비활성화된 CMD 클러스터의 경우

복제 그룹이 '전송 암호화 모드: 선호'로 설정된 경우:

  • TLS가 지원되지 않는 클러스터의 원래 프라이머리 엔드포인트 및 리더 엔드포인트는 활성 상태로 유지됩니다.

  • 클러스터를 TLS Preferred 모드로 설정하면 새 TLS 프라이머리 및 리더 엔드포인트가 생성됩니다. 이 새 엔드포인트는 이전 엔드포인트와 동일한 IP(TLS 없음)로 변환됩니다.

  • 새로운 프라이머리 엔드포인트 및 리더 엔드포인트는 ElastiCache 콘솔에서 및 describe-replication-group API에 대한 응답으로 노출됩니다.

복제 그룹이 '전송 암호화 모드: 필수'로 설정된 경우:

  • 기존의 비 TLS 프라이머리 엔드포인트와 리더 엔드포인트는 삭제됩니다. TLS 클러스터 엔드포인트의 가동 중지는 없습니다.

  • ElastiCache 콘솔 또는 describe-replication-group API에서 새 프라이머리 엔드포인트 및 리더 엔드포인트를 검색할 수 있습니다.

DNS 레코드의 권장 사용

CME 클러스터의 경우

  • 애플리케이션 코드에서 노드별 DNS 레코드 대신 클러스터 구성 엔드포인트를 사용하세요. 노드별 DNS 이름을 직접 사용하는 것은 권장되지 않습니다. 마이그레이션 중에 DNS 이름이 변경되고 애플리케이션 코드가 클러스터에 대한 연결을 끊기 때문입니다.

  • 이 프로세스 중에 변경되므로 애플리케이션에서 클러스터 구성 엔드포인트를 하드코딩하지 마십시오.

  • 이 프로세스 중에 클러스터 구성 엔드포인트를 변경할 수 있으므로 애플리케이션에서 클러스터 구성 엔드포인트를 하드코딩하는 것은 잘못된 방법입니다. 전송 중 데이터 암호화가 완료되면 describe-replication-group API를 사용하여 클러스터 구성 엔드포인트를 쿼리하고(위에서 설명한 대로(굵게)) 해당 시점부터 응답으로 얻은 DNS를 사용합니다.

자동 장애 조치가 활성화된 CMD 클러스터의 경우

  • 비 TLS에서 TLS 선호로 클러스터를 마이그레이션할 때 이전 노드별 DNS 이름이 삭제되고 새 이름이 생성되므로 애플리케이션 코드에서 노드별 DNS 이름 대신 프라이머리 엔드포인트와 리더 엔드포인트를 사용하세요. 향후 클러스터에 복제본을 추가할 수 있으므로 노드별 DNS 이름을 직접 사용하는 것은 권장되지 않습니다. 또한 자동 장애 조치가 활성화되면 프라이머리 클러스터 및 복제본의 역할이 ElastiCache 서비스에 의해 자동으로 변경됩니다. 이러한 변경 사항을 추적하는 데 도움이 되도록 프라이머리 엔드포인트와 리더 엔드포인트를 사용하는 것이 좋습니다. 마지막으로 리더 엔드포인트를 사용하면 복제본의 읽기를 클러스터의 복제본 간에 균등하게 분산하는 데 도움이 됩니다.

  • TLS 마이그레이션 프로세스 중에 변경될 수 있으므로 애플리케이션에서 프라이머리 엔드포인트와 리더 엔드포인트를 하드코딩하는 것은 좋지 않습니다. TLS 선호로의 마이그레이션 변경이 완료되면 describe-replication-group API를 사용하여 프라이머리 엔드포인트 및 리더 엔드포인트를 쿼리하고 이 시점부터 응답으로 받은 DNS를 사용하세요. 이렇게 하면 엔드포인트의 변경 사항을 동적으로 추적할 수 있습니다.

자동 장애 조치가 비활성화된 CMD 클러스터의 경우

  • 애플리케이션 코드에서 노드별 DNS 이름 대신 프라이머리 엔드포인트와 리더 엔드포인트를 사용하세요. 자동 장애 조치가 비활성화되면 자동 장애 조치가 활성화되었을 때 ElastiCache 서비스에서 자동으로 관리되는 크기 조정, 패치, 장애 조치 및 기타 절차를 사용자가 대신 수행합니다. 이렇게 하면 여러 엔드포인트를 쉽게 수동으로 추적할 수 있습니다. 비 TLS에서 TLS 선호로 클러스터를 마이그레이션할 때 이전 노드별 DNS 이름이 삭제되고 새 이름이 생성되므로 노드별 DNS 이름을 직접 사용하지 마세요. 이는 TLS 마이그레이션 중에 클라이언트가 클러스터에 연결할 수 있도록 하기 위한 필수 사항입니다. 또한 리더 엔드포인트를 사용할 때 복제본 간에 읽기를 균등하게 분산하고 클러스터에서 복제본을 추가하거나 삭제할 때 DNS 레코드를 추적할 수 있다는 이점이 있습니다.

  • 클러스터 구성 엔드포인트는 TLS 마이그레이션 프로세스 중에 변경될 수 있으므로 애플리케이션에서 클러스터 구성 엔드포인트를 하드코딩하는 것은 좋지 않습니다.

전송 중 데이터 암호화 중: 마이그레이션 프로세스가 언제 완료되는지에 주의 기울이기

전송 중 데이터 암호화 모드 변경은 즉시 이루어지지 않으며 시간이 좀 걸릴 수 있습니다. 대규모 클러스터의 경우 특히 그렇습니다. 클러스터가 TLS 선호로 마이그레이션을 완료한 후에만 TCP 연결과 TLS 연결을 모두 수락하고 제공할 수 있습니다. 따라서 전송 중 데이터 암호화가 완료될 때까지 클러스터에 TLS 연결을 설정하려고 시도하는 클라이언트를 생성해서는 안 됩니다.

전송 중 데이터 암호화가 성공적으로 완료되거나 실패했을 때 알림을 받는 방법에는 다음과 같은 여러 가지가 있습니다(위 코드 예에는 표시되지 않음).

  • SNS 서비스를 사용하여 암호화 완료 시 알림 받기

  • 암호화가 완료될 때 이벤트를 발생시키는 describe-events API 사용

  • ElastiCache 콘솔에서 암호화가 완료되었다는 메시지 확인

또한 애플리케이션에 로직을 구현하여 암호화가 완료되었는지 확인할 수 있습니다. 위의 예에서는 클러스터가 마이그레이션을 완료하도록 하는 몇 가지 방법을 살펴보았습니다.

  • 마이그레이션 프로세스가 시작될 때까지 대기(클러스터 상태가 ‘수정 중’으로 변경됨) 및 수정이 완료될 때까지 대기(클러스터 상태가 다시 ‘사용 가능’으로 변경됨)

  • describe-replication-group API를 쿼리하여 클러스터의 transit_encryption_enabled가 True로 설정되었는지 확인.

전송 중 데이터 암호화를 활성화한 후: 사용하는 클라이언트가 올바르게 구성되었는지 확인

클러스터가 TLS 선호 모드에 있는 동안 애플리케이션은 클러스터에 대한 TLS 연결을 열고 해당 연결만 사용해야 합니다. 이렇게 하면 전송 중 데이터 암호화를 활성화할 때 애플리케이션이 가동 중지를 겪지 않습니다. SSL 섹션 아래의 info 명령을 사용하여 Valkey 또는 Redis OSS 엔진에 대한 보다 명확한 TCP 연결이 없는지 확인할 수 있습니다.

# SSL
ssl_enabled:yes
ssl_current_certificate_not_before_date:Mar 20 23:27:07 2017 GMT
ssl_current_certificate_not_after_date:Feb 24 23:27:07 2117 GMT
ssl_current_certificate_serial:D8C7DEA91E684163
tls_mode_connected_tcp_clients:0   (should be zero)
tls_mode_connected_tls_clients:100