View a markdown version of this page

Práticas recomendadas ao habilitar a criptografia em trânsito - Amazon ElastiCache
Antes de ativar a criptografia em trânsito: verifique se você tem o tratamento adequado dos registros DNSDurante a criptografia em trânsito: preste atenção quando o processo de migração terminar

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