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 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 habilitados para não TLS. O ElastiCache manterá os dois registros DNS quando um cluster for configurado no modo de criptografia preferencial para que aplicações e outros clientes Valkey ou 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 Valkey ou Redis OSS serão gerados quando o cluster for definido no modo de TLS preferencial. Esses novos endpoints terão os mesmos IPs dos antigos (não TLS).

• O novo endpoint de configuração do TLS Valkey ou Redis OSS será exposto no console do ElastiCache 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 console do ElastiCache ou da API describe-replication-group.

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).

• Os novos endpoints primário e de leitor serão expostos no console do ElastiCache e na resposta à API describe-replication-group.

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 os novos endpoints primário e do leitor no console do ElastiCache ou na API describe-replication-group.

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 serviço ElastiCache. Sugere-se usar o endpoint primário e o endpoint do leitor 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 preferencial 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ê obtiver em 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 ajuste de escala, a aplicação de patches, o failover e outros procedimentos que são gerenciados automaticamente pelo serviço ElastiCache 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

• Mensagem no console do ElastiCache 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 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