Práticas recomendadas ao habilitar a criptografia em trânsito - Amazon ElastiCache
Antes de ativar a criptografia em trânsito: verifique se você tem um tratamento adequado DNS dos registrosDurante 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 um tratamento adequado DNS dos registros

nota

Estamos alterando e excluindo endpoints antigos durante esse processo. O uso incorreto dos endpoints pode fazer com que o OSS cliente Valkey ou Redis 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 antigos por nó são mantidos e os novos DNS registros por nó DNS são gerados em um formato diferente. TLSos clusters habilitados usam um formato de DNS registro diferente dos non-TLS-enabled clusters. ElastiCache manterá os dois DNS registros quando um cluster for configurado no modo de criptografia: preferencial para que aplicativos e outros OSS clientes Valkey ou Redis possam alternar entre eles. As seguintes alterações nos DNS registros ocorrem durante o processo TLS de migração:

Descrição das alterações nos DNS registros que ocorrem ao ativar a criptografia em trânsito

Para CME clusters

Quando um cluster é definido como “modo de criptografia em trânsito: preferencial”:

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

  • Novos OSS endpoints TLS Valkey ou Redis serão gerados quando o cluster for definido no modo -preferencial. TLS Esses novos endpoints serão resolvidos da IPs mesma forma que os antigos (não-TLS).

  • O novo endpoint de OSS configuração TLS Valkey ou Redis será exposto no ElastiCache console e na resposta a. describe-replication-group API

Quando um cluster é definido como “modo de criptografia em trânsito: obrigatório”:

  • Os endpoints antigos não TLS habilitados serão excluídos. Não haverá tempo de inatividade dos endpoints do TLS cluster.

  • Você pode recuperar um novo cluster-configuration-endpoint do ElastiCache Console ou do describe-replication-groupAPI.

Para CMD clusters 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 do cluster não TLS habilitado permanecerão ativos.

  • Novos endpoints TLS primários e de leitura serão gerados quando o cluster for configurado para TLS Preferred modo. Esses novos endpoints serão resolvidos para o (s) mesmo (s) IP (s) dos antigos (não-TLS).

  • O novo endpoint primário e o endpoint do leitor serão expostos no ElastiCache console e na resposta ao. describe-replication-group API

Quando o grupo de replicação é definido como “modo de criptografia em trânsito: obrigatório”:

  • Os endpoints antigos não TLS primários e de leitura serão excluídos. Não haverá tempo de inatividade dos endpoints do TLS cluster.

  • Você pode recuperar novos endpoints primários e de leitura do ElastiCache Console ou do. describe-replication-group API

O uso sugerido dos DNS registros

Para CME clusters

  • Use o endpoint de configuração do cluster em vez dos DNS registros por nó no código do seu aplicativo. Não é recomendável usar DNS nomes por nó diretamente, pois eles podem mudar ao adicionar ou remover fragmentos.

  • 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 o describe-replication-group API (conforme demonstrado acima (em negrito)) e use a DNS resposta obtida a partir desse momento.

Para CMD clusters com o failover automático ativado

  • Use o endpoint primário e o endpoint do leitor em vez dos DNS nomes por nó no código do seu aplicativo, pois os DNS nomes antigos por nó são excluídos e os novos são gerados ao migrar o cluster de não para -preferencial. TLS TLS Não é recomendável usar DNS nomes 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 eles podem ser alterados durante o processo de migração. TLS Depois que a alteração da migração para TLS -preferred for concluída, consulte o endpoint primário e o endpoint do leitor com o describe-replication-group API e use a resposta DNS que você obtiver a partir desse momento. Dessa forma, você poderá acompanhar as mudanças nos endpoints de forma dinâmica.

Para CMD cluster com o failover automático desativado

  • Use o endpoint primário e o endpoint do leitor em vez dos DNS nomes 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 DNS nomes antigos por nó são excluídos e novos são gerados ao migrar o cluster de não TLS para TLS -preferencial, não use os nomes por DNS nó diretamente. Isso é obrigatório para que os clientes possam se conectar ao cluster durante a TLS migração. Além disso, você se beneficiará de distribuir uniformemente as leituras entre as réplicas ao usar o endpoint do leitor e acompanhar os 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 TLS processo de migração.

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 TLS -preferred, ele é capaz de aceitar e atender ambas as conexõesTCP. TLS Portanto, você não deve criar clientes que tentarão estabelecer TLS conexões 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):

  • Usando o SNS serviço para receber uma notificação quando a criptografia for concluída

  • Usar o describe-events API 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”)

  • Afirmando que o cluster foi transit_encryption_enabled definido como True consultando o. describe-replication-group API

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 TLS preferencial, seu aplicativo deve abrir TLS conexões 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 TCP conexões mais claras com o OSS mecanismo Valkey ou Redis 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