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

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

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

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

참고

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

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

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

CME 클러스터의 경우

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

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

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

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

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

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

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

자동 장애 조치가 활성화되었거나 자동 장애 조치가 비활성화된 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-referred로의 마이그레이션 변경이 완료되면 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 섹션 아래의 Redis OSS info 명령을 사용하여 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