Práticas recomendadas ao habilitar a criptografia em trânsito - Amazon ElastiCache (RedisOSS)
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 Redis OSS use endpoints antigos e excluídos, o que impedirá que ele se conecte ao cluster.

Enquanto o cluster está sendo migrado de não TLS para TLS preferencial, os registros DNS por nó antigos são mantidos e os novos registros DNS por nó são gerados em um formato diferente. Os clusters habilitados para TLS usam um formato de registros DNS diferente dos clusters não habilitados para TLS. ElastiCache manterá os dois registros DNS quando um cluster for configurado no modo de criptografia: preferencial para que os aplicativos e outros clientes do Redis OSS possam alternar entre eles. As seguintes alterações nos registros DNS ocorrem durante o processo de migração do TLS:

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”:

  • Os endpoints do cluster original para o cluster habilitados para não TLS permanecerão ativos. Não haverá tempo de inatividade quando o cluster for reconfigurado do modo de criptografia TLS 'nenhum' para 'preferencial'.

  • Novos endpoints TLS Redis OSS serão gerados quando o cluster for definido para o modo preferencial TLS. Esses novos endpoints terão os mesmos IPs dos antigos (não TLS).

  • O novo endpoint de configuração do TLS 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 podem mudar quando fragmentos forem adicionados ou removidos.

  • Não codifique o 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 por nó antigos são excluídos e os novos são gerados ao migrar o cluster do não TLS para o TLS preferencial. 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 alteração da migração para o TLS-Preferred for concluída, consulte o endpoint primário e o endpoint do leitor com a describe-replication-group API 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 por nó antigos são excluídos e os novos são gerados ao migrar o cluster de não TLS para TLS preferencial, não use os nomes DNS por nó diretamente. Isso é obrigatório para que os clientes possam se conectar ao cluster durante a migração para TLS. Além disso, você se beneficiará de distribuir uniformemente as leituras entre as réplicas ao usar o endpoint do leitor e acompanhar os registros de DNS 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 conclui a migração para o TLS preferencial é que ele pode aceitar e servir 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 modo de TLS preferencial, 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 Redis OSS usando o comando Redis OSS 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