전송 중 암호화 활성화 시 모범 사례 - Amazon ElastiCache
전송 중 암호화를 활성화하기 전에: 적절한 DNS 레코드 처리가 있는지 확인합니다.전송 중 데이터 암호화 중: 마이그레이션 프로세스가 언제 완료되는지에 주의 기울이기

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

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

전송 중 암호화를 활성화하기 전에: 적절한 DNS 레코드 처리가 있는지 확인합니다.

참고

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

클러스터를 no-TLS에서 TLS-preferred로 마이그레이션하는 동안 이전 노드별 DNS 레코드가 유지되고 새 노드별 DNS 레코드가 다른 형식으로 생성됩니다. TLS-활성화된 클러스터는 클러스터와 non-TLS-enabled 다른 형식의 DNS 레코드를 사용합니다. 는 클러스터가 암호화 모드로 구성된 경우 두 DNS 레코드를 모두 ElastiCache 유지합니다. 애플리케이션과 다른 Valkey 또는 Redis OSS 클라이언트가 서로 전환할 수 있도록 선호됩니다. TLS마이그레이션 프로세스 중에 DNS 레코드가 다음과 같이 변경됩니다.

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

CME 클러스터의 경우

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

  • 활성화TLS되지 않은 클러스터의 원래 클러스터 엔드포인트는 활성 상태로 유지됩니다. 클러스터가 양식 TLS 암호화 모드 '없음'을 '선호됨'으로 재구성되면 가동 중지가 발생하지 않습니다.

  • 클러스터가 TLS-기본 모드로 설정되면 새 TLS Valkey 또는 Redis OSS 엔드포인트가 생성됩니다. 이러한 새 엔드포인트는 이전 엔드포인트IPs와 동일하게 확인됩니다(비-TLS).

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

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

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

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

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

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

  • 활성화TLS되지 않은 클러스터의 원래 기본 엔드포인트 및 리더 엔드포인트는 활성 상태로 유지됩니다.

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

  • 새 기본 엔드포인트 및 리더 엔드포인트는 ElastiCache 콘솔과 describe-replication-group 에 대한 응답으로 노출됩니다API.

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

  • 이전 비TLS 프라이머리 및 리더 엔드포인트가 삭제됩니다. TLS 클러스터 엔드포인트의 가동 중지 시간은 없습니다.

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

DNS 레코드의 권장 사용량

CME 클러스터의 경우

  • 애플리케이션 코드의 노드별 DNS 레코드 대신 클러스터 구성 엔드포인트를 사용합니다. 노드별 DNS 이름은 샤드를 추가하거나 제거할 때 변경될 수 있으므로 직접 사용하는 것은 권장되지 않습니다.

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

  • 클러스터 구성 엔드포인트는 이 프로세스 중에 변경될 수 있으므로 애플리케이션에서 클러스터 구성 엔드포인트를 하드코딩하는 것은 좋지 않습니다. 전송 중 암호화가 완료되면 describe-replication-group API (위에 표시된 대로(굵은 글씨체)) 로 클러스터 구성 엔드포인트를 쿼리하고 이 시점부터 응답으로 DNS 얻은 를 사용합니다.

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

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

  • 애플리케이션에 프라이머리 엔드포인트와 리더 엔드포인트를 하드코딩하는 것은 TLS 마이그레이션 프로세스 중에 변경할 수 있기 때문에 잘못된 관행입니다. TLS-preferred로 마이그레이션 변경이 완료되면 를 사용하여 describe-replication-group 기본 엔드포인트 및 리더 엔드포인트를 쿼리API하고 이 시점부터 응답으로 DNS 얻은 를 사용합니다. 이렇게 하면 엔드포인트의 변경 사항을 동적으로 추적할 수 있습니다.

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

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

  • 클러스터 구성 엔드포인트를 애플리케이션에 하드코딩하는 것은 TLS 마이그레이션 프로세스 중에 변경할 수 있으므로 잘못된 관행입니다.

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

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

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

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

  • 암호화가 완료될 때 이벤트를 내보내describe-eventsAPI는 사용

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

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

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

  • 를 쿼리하여 클러스터가 True로 transit_encryption_enabled 설정되었다고 주장합니다describe-replication-groupAPI.

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

클러스터가 TLS-선호 모드에 있는 동안 애플리케이션은 클러스터에 대한 TLS 연결을 열고 이러한 연결만 사용해야 합니다. 이렇게 하면 전송 중 데이터 암호화를 활성화할 때 애플리케이션이 가동 중지를 겪지 않습니다. SSL 섹션의 정보 명령을 사용하여 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