As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Práticas recomendadas ao habilitar a criptografia em trânsito
## Antes de ativar a criptografia em trânsito: verifique se você tem o tratamento adequado dos registros DNS
**nota**
Estamos alterando e excluindo endpoints antigos durante esse processo. O uso incorreto dos endpoints pode fazer com que o cliente Valkey ou Redis OSS use endpoints antigos e excluídos, o que impedirá que ele se conecte ao cluster.
Enquanto o cluster está sendo migrado do No-TLS para TLS-preferred, o antigo registro DNS do endpoint de configuração do cluster é mantido e os novos registros DNS do endpoint de configuração do cluster são gerados em um formato diferente. TLS-enabled os clusters usam um formato de registros DNS diferente dos TLS-disabled clusters. ElastiCache manterá os dois registros DNS quando um cluster for configurado `encryption mode: Preferred` para que os aplicativos e outros clientes Valkey ou Redis OSS possam alternar entre eles. As seguintes alterações nos registros DNS ocorrem durante o TLS-migration processo:
### Descrição das alterações nos registros DNS que ocorrem ao ativar a criptografia em trânsito
**Para clusters CME**
Quando um cluster é definido como “modo de criptografia em trânsito: preferencial”:
+ O endpoint do cluster de configuração original para o cluster não TLS permanecerá ativo. Não haverá tempo de inatividade quando o cluster for reconfigurado do modo de criptografia TLS 'nenhum' para 'preferencial'.
+ Novos endpoints TLS Valkey ou Redis OSS serão gerados quando o cluster estiver configurado para modo. TLS-preferred Esses novos endpoints terão os mesmos IPs dos antigos (não TLS).
+ O novo endpoint de configuração TLS Valkey ou Redis OSS será exposto no ElastiCache console e na resposta à API. `describe-replication-group`
Quando um cluster é definido como “modo de criptografia em trânsito: obrigatório”:
+ Os endpoints habilitados para não TLS antigos serão excluídos. Não haverá tempo de inatividade dos endpoints do cluster TLS.
+ Você pode recuperar um novo `cluster-configuration-endpoint` do ElastiCache Console ou da `describe-replication-group` API.
**Para clusters CMD com Failover automático ativado ou Failover automático desativado**
Quando um grupo de replicação é definido como “modo de criptografia em trânsito: preferencial”:
+ O endpoint primário original e o endpoint do leitor para um cluster habilitado para não TLS permanecerão ativos.
+ Os novos endpoints TLS primários e do leitor serão gerados quando o cluster for definido no modo de TLS `Preferred`. Esses novos endpoints terão os mesmos IPs dos antigos (não TLS).
+ O novo endpoint primário e o endpoint do leitor serão expostos no ElastiCache console e na resposta à `describe-replication-group` API.
Quando o grupo de replicação é definido como “modo de criptografia em trânsito: obrigatório”:
+ Os endpoints primários e de leitura não TLS antigos serão excluídos. Não haverá tempo de inatividade dos endpoints do cluster TLS.
+ Você pode recuperar novos endpoints primários e de leitura do ElastiCache console ou da `describe-replication-group` API.
### Uso sugerido dos registros DNS
**Para clusters CME **
+ Use o endpoint de configuração do cluster em vez dos registros DNS por nó no código do seu aplicativo. Não é recomendável usar nomes DNS por nó diretamente, pois eles mudarão durante a migração e o código do aplicativo interromperá a conexão com o cluster.
+ Não codifique um endpoint de configuração de cluster em seu aplicativo, pois ele mudará durante esse processo.
+ Ter o endpoint de configuração do cluster codificado em seu aplicativo é uma prática ruim, pois ele pode ser alterado durante esse processo. Depois que a criptografia em trânsito for concluída, consulte o endpoint de configuração do cluster com a API `describe-replication-group` [conforme demonstrado acima (em negrito)] e use o DNS que você obtiver em resposta a partir desse momento.
**Para clusters CMD com Failover Automático ativado**
+ Use o endpoint primário e o endpoint do leitor em vez dos nomes DNS por nó no código do seu aplicativo, pois os nomes DNS antigos por nó são excluídos e os novos são gerados ao migrar o cluster de não-TLS para o. TLS-preferred Não é recomendável usar nomes DNS por nó diretamente, pois você pode adicionar réplicas ao seu cluster no futuro. Além disso, quando o failover automático está ativado, as funções do cluster primário e das réplicas são alteradas automaticamente pelo ElastiCache serviço. O uso do endpoint primário e do endpoint do leitor é sugerido para ajudar você a acompanhar essas alterações. Por fim, usar o endpoint do leitor ajudará você a distribuir as leituras das réplicas igualmente entre as réplicas no cluster.
+ Ter o endpoint primário e o endpoint do leitor codificados em seu aplicativo é uma prática ruim, pois isso pode ser alterado durante o processo de migração do TLS. Depois que a mudança de migração para TLS-preferred for concluída, consulte o endpoint primário e o endpoint do leitor com a API describe-replication-group e use o DNS que você obterá como resposta a partir desse momento. Dessa forma, você poderá acompanhar as mudanças nos endpoints de forma dinâmica.
**Para cluster CMD com Failover automático ativado**
+ Use o endpoint primário e o endpoint do leitor em vez dos nomes DNS por nó no código do seu aplicativo. Quando o Failover Automático está desativado, o escalonamento, a correção, o failover e outros procedimentos que são gerenciados automaticamente pelo ElastiCache serviço quando o Failover Automático está ativado são feitos por você. Isso facilita seu acompanhamento manual dos diferentes endpoints. Como os nomes DNS antigos por nó são excluídos e novos são gerados ao migrar o cluster de não-TLS paraTLS-preferred, não use os nomes DNS por nó diretamente. Isso é obrigatório para que os clientes possam se conectar ao cluster durante TLS-migration o. Além disso, você se beneficiará de distribuir uniformemente as leituras entre as réplicas ao usar o endpoint do leitor e acompanhar as leituras DNS-records ao adicionar ou excluir réplicas do cluster.
+ Ter o endpoint de configuração do cluster codificado em seu aplicativo é uma prática ruim, pois ele pode ser alterado durante o processo de migração TLS.
## Durante a criptografia em trânsito: preste atenção quando o processo de migração terminar
A alteração do modo de criptografia em trânsito não é imediata e pode levar algum tempo. Isso é especialmente verdade para clusters grandes. Somente quando o cluster termina a migração para ele TLS-preferred é capaz de aceitar e atender conexões TCP e TLS. Portanto, você não deve criar clientes que tentarão estabelecer conexões TLS com o cluster até que a criptografia em trânsito seja concluída.
Há várias maneiras de ser notificado quando a criptografia em trânsito é concluída com êxito ou falha: (não mostrado no exemplo de código acima):
+ Usar o serviço SNS para receber uma notificação quando a criptografia for concluída
+ Usar a API `describe-events` que emitirá um evento quando a criptografia for concluída
+ Vendo uma mensagem no ElastiCache console informando que a criptografia foi concluída
Você também pode implementar a lógica em seu aplicativo para saber se a criptografia foi concluída. No exemplo acima, vimos várias maneiras de garantir que o cluster conclua a migração:
+ Esperar até o início do processo de migração (o status do cluster muda para “modificando”) e esperar até que a modificação seja concluída (o status do cluster volta para “disponível”)
+ Verificar se `transit_encryption_enabled` do cluster está definido como Verdadeiro consultando a API `describe-replication-group`.
### Depois de ativar a criptografia em trânsito: verifique se os clientes que você usa estão configurados corretamente
Enquanto o cluster estiver no TLS-preferred modo, seu aplicativo deve abrir conexões TLS com o cluster e usar somente essas conexões. Dessa forma, seu aplicativo não sofrerá tempo de inatividade ao ativar a criptografia em trânsito. Você pode garantir que não haja conexões TCP mais claras com o mecanismo Valkey ou Redis OSS usando o comando info na seção SSL.
```
# 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
```