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á. # Segurança de dados no Amazon ElastiCache Para ajudar a manter seus dados seguros, o Amazon ElastiCache e o Amazon EC2 fornecem mecanismos para proteger contra o acesso não autorizado aos seus dados no servidor. O Amazon ElastiCache para Memcached oferece atributos de criptografia para dados em caches que estiverem executando as versões 1.6.12 ou posterior do Memcached. O Amazon ElastiCache com Valkey e Redis OSS oferece atributos de criptografia para dados em caches que estiverem executando o Valkey 7.2 ou posterior e as versões 3.2.6 do Redis OSS (programadas para EOL, consulte [Cronograma de fim de vida útil das versões do Redis OSS](engine-versions.md#deprecated-engine-versions)), 4.0.10 ou posteriores. O Amazon ElastiCache dá suporte à autenticação de usuários com o IAM ou o AUTH do Valkey e Redis OSS, além da autorização das operações de usuários usando o controle de acesso baseado em função (RBAC). + A criptografia em trânsito criptografa seus dados sempre que eles estão se movendo de um lugar para outro, como entre os nós no seu cluster ou entre seu cache e o aplicativo. + A criptografa em repouso criptografa dados no disco durante as operações de sincronização e backup. O ElastiCache oferece suporte à autenticação de usuários usando o IAM e o comando AUTH do Valkey e Redis OSS, além de autorizar operações de usuários usando o controle de acesso baseado em função (RBAC). ![\[Imagem: diagrama de segurança do ElastiCache para Valkey e Redis OSS\]](http://docs.aws.amazon.com/pt_br/AmazonElastiCache/latest/dg/images/ElastiCache-Redis-Secure-Compliant.png) *Diagrama de segurança do ElastiCache para Valkey e Redis OSS* **Topics** + [ElastiCache criptografia em trânsito (TLS)](in-transit-encryption.md) + [Criptografia em repouso em ElastiCache](at-rest-encryption.md) + [Autenticação e autorização](auth-redis.md) # ElastiCache criptografia em trânsito (TLS) Para ajudar a manter seus dados seguros, a Amazon ElastiCache e a Amazon EC2 fornecem mecanismos de proteção contra o acesso não autorizado aos seus dados no servidor. Ao fornecer o recurso de criptografia em trânsito, ElastiCache oferece uma ferramenta que você pode usar para ajudar a proteger seus dados quando eles são movidos de um local para outro. Todos os caches de tecnologia sem servidor do Valkey ou Redis OSS têm criptografia em trânsito habilitada. Para clusters baseados em nós, você pode habilitar a criptografia em trânsito em um grupo de replicação configurando o parâmetro `TransitEncryptionEnabled` como `true` (CLI: `--transit-encryption-enabled`) ao criar o grupo de replicação. Você pode fazer isso se estiver criando o grupo de replicação usando a Console de gerenciamento da AWSAWS CLI, a ou a ElastiCache API. Todos os caches sem servidor têm criptografia em trânsito habilitada. Para clusters baseados em nós, você pode habilitar a criptografia em trânsito em um cluster definindo o parâmetro como `TransitEncryptionEnabled` (`true`CLI: `--transit-encryption-enabled`) ao criar o cluster usando a operação `CreateCacheCluster` (CLI: `create-cache-cluster`). **Topics** + [Visão geral da criptografia em trânsito](#in-transit-encryption-overview) + [Condições de criptografia em trânsito (Valkey e Redis OSS)](#in-transit-encryption-constraints) + [Condições de criptografia em trânsito (Memcached)](#in-transit-encryption-constraints) + [Práticas recomendadas de criptografia em trânsito](#in-transit-encryption-best-practices) + [Outras opções para Valkey e Redis OSS](#in-transit-encryption-see-also) + [Habilitação da criptografia em trânsito para o Memcached](#in-transit-encryption-enable-existing-mc) + [Habilitação da criptografia em trânsito](in-transit-encryption-enable.md) + [Conexão ao ElastiCache (Valkey) ou ao Amazon ElastiCache para Redis OSS com criptografia em trânsito usando o valkey-cli](connect-tls.md) + [Ativar criptografia em trânsito em um cluster Redis OSS baseado em nós usando Python](in-transit-encryption-enable-python.md) + [Práticas recomendadas ao habilitar a criptografia em trânsito](enable-python-best-practices.md) + [Conectar-se a nós habilitados com criptografia em trânsito usando o Openssl (Memcached)](#in-transit-encryption-connect-mc) + [Criação de um cliente TLS Memcached usando Java](#in-transit-encryption-connect-java) + [Criação de um cliente TLS Memcached usando PHP](#in-transit-encryption-connect-php-mc) ## Visão geral da criptografia em trânsito A criptografia ElastiCache em trânsito da Amazon é um recurso que permite aumentar a segurança de seus dados nos pontos mais vulneráveis, quando estão em trânsito de um local para outro. Como a criptografia e descriptografia dos dados requerem processamento nos endpoints, a ativação da criptografia em trânsito pode ter impacto no desempenho. Compare seus dados com e sem criptografia em trânsito para determinar o impacto no desempenho para seus casos de uso. ElastiCache a criptografia em trânsito implementa os seguintes recursos: + **Conexões de cliente criptografadas**: as conexões do cliente com os nós de cache são criptografadas por TLS. + **Conexões de servidor criptografadas**: os dados que se movem entre os nós em um cluster são criptografados. + **Autenticação do servidor**: os clientes podem autenticar que estão conectados ao servidor certo. + **Autenticação do cliente**: usando o atributo AUTH do Valkey ou do Redis OSS, o servidor pode autenticar os clientes. ## Condições de criptografia em trânsito (Valkey e Redis OSS) As seguintes restrições na criptografia ElastiCache em trânsito da Amazon devem ser lembradas ao planejar sua implementação de cluster baseado em nós: + A criptografia em trânsito é aceita em grupos de replicação que executam o Valkey 7.2 e posteriores, e o Redis OSS versões 3.2.6, 4.0.10 e posteriores. + A modificação da configuração de criptografia em trânsito para um cluster existente é aceita em grupos de replicação que executam o Valkey 7.2 e posterior, e o Redis OSS versão 7 e posterior. + A criptografia em trânsito tem suporte somente em grupos de replicação em execução em uma Amazon VPC. + A criptografia em trânsito não é aceita para grupos de replicação que executam os seguintes tipos de nó: M1, M2. Para obter mais informações, consulte [Tipos de nó compatíveis](CacheNodes.SupportedTypes.md). + A criptografia em trânsito é ativada configurando explicitamente o parâmetro `TransitEncryptionEnabled` como `true`. + Verifique se o cliente de armazenamento em cache dá suporte à conectividade TLS e se você a habilitou na configuração do cliente. + A partir de 26 de janeiro de 2026,AWS atualizaremos a versão mínima suportada do TLS para 1.2 no ElastiCache Valkey versão 7.2 e superior e no Redis OSS versão 6 e ElastiCache superior. Os clientes devem atualizar o software-cliente antes dessa data. Essa atualização ajuda você a atender às necessidades regulatórias, de conformidade e de segurança. ## Condições de criptografia em trânsito (Memcached) As seguintes restrições na criptografia ElastiCache em trânsito da Amazon devem ser lembradas ao planejar sua implementação de cluster baseado em nós: + A criptografia em trânsito é compatível com clusters executando as versões 1.6.12 e posteriores do Memcached. + A criptografia em trânsito é compatível com as versões 1.2 e 1.3 do Transport Layer Security (TLS). + A criptografia em trânsito é compatível somente em clusters em execução em uma Amazon VPC. + A criptografia em trânsito não é aceita para grupos de replicação que executam os seguintes tipos de nó: M1, M2, M3, R3, T2. Para obter mais informações, consulte [Tipos de nó compatíveis](CacheNodes.SupportedTypes.md). + A criptografia em trânsito é ativada configurando explicitamente o parâmetro `TransitEncryptionEnabled` como `true`. + Só é possível ativar a criptografia em trânsito em um cluster ao criá-lo. Não é possível ativar e desativar a criptografia em trânsito modificando um cluster. + Verifique se o cliente de armazenamento em cache dá suporte à conectividade TLS e se você a habilitou na configuração do cliente. ## Práticas recomendadas de criptografia em trânsito + Como a criptografia e descriptografia dos dados requerem processamento nos endpoints, a implementação da criptografia em trânsito pode reduzir o desempenho. Compare seus dados com criptografia em trânsito e sem criptografia para determinar o impacto no desempenho da sua implementação. + Como criar novas conexões pode ser caro, é possível reduzir o impacto na performance da criptografia em trânsito persistindo suas conexões TLS. ## Outras opções para Valkey e Redis OSS Para obter mais informações sobre as opções disponíveis para Valkey e Redis OSS, consulte os links a seguir. + [Criptografia em repouso em ElastiCache](at-rest-encryption.md) + [Autenticar com o comando AUTH do Valkey e Redis OSS](auth.md) + [Regras de controle de acesso com base em função (RBAC)](Clusters.RBAC.md) + [Amazon VPCs e ElastiCache segurança](VPCs.md) + [Identity and Access Management para Amazon ElastiCache](IAM.md) ## Habilitação da criptografia em trânsito para o Memcached Para ativar a criptografia em trânsito ao criar um cluster Memcached usando o AWS Management Console, escolha as seguintes opções: + Escolha o Memcached como seu mecanismo. + Escolha a versão 1.6.12 ou posterior do mecanismo. + Em **Encryption in transit** (Criptografia em trânsito), escolha **Enable** (Habilitar). Para o step-by-step processo, consulte[Criação de um cluster do Valkey ou Redis OSS](Clusters.Create.md). # Habilitação da criptografia em trânsito Todos os caches sem servidor têm criptografia em trânsito habilitada. Em um cluster baseado em nós, você pode ativar a criptografia em trânsito usando a,Console de gerenciamento da AWS a AWS CLI ou a API. ElastiCache ## Habilitando a criptografia em trânsito usando o Console de gerenciamento da AWS ### Habilitando a criptografia em trânsito para um novo cluster baseado em nós usando o Console de gerenciamento da AWS Ao projetar o próprio cluster, as configurações “Dev/Teste” e “Produção” com o método “Criação fácil” têm a criptografia em trânsito habilitada. Ao escolher a configuração por conta própria, faça as seguintes seleções: + Escolha a versão 3.2.6, 4.0.10 ou posterior do mecanismo. + Clique na caixa de seleção ao lado de **Habilitar** para a opção **Criptografia em trânsito**. Para o step-by-step processo, consulte o seguinte: + [Criação de um cluster do Valkey (modo cluster desabilitado) (console)](SubnetGroups.designing-cluster-pre.valkey.md#Clusters.Create.CON.valkey-gs) + [Criação de um cluster do Valkey ou Redis OSS (modo cluster habilitado) (console)](Clusters.Create.md#Clusters.Create.CON.RedisCluster) ### Habilitando a criptografia em trânsito para um cluster existente baseado em nós usando o Console de gerenciamento da AWS Habilitar a criptografia em trânsito é um processo de duas etapas para o qual você deve primeiro definir o modo de criptografia de em trânsito como `preferred`. Esse modo permite que seus clientes Valkey ou Redis OSS se conectem usando conexões criptografadas e não criptografadas. Depois de migrar todos os seus clientes Valkey ou Redis OSS para usar conexões criptografadas, você pode modificar a configuração do cluster para definir o modo de criptografia em trânsito como `required`. Se o modo de criptografia em trânsito for definido como `required`, todas as conexões não criptografadas serão eliminadas e somente conexões criptografadas serão permitidas. **Defina seu **modo de criptografia em trânsito** como **Preferencial**** 1. Faça login no Console de gerenciamento da AWS e abra o ElastiCache console da Amazon em [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/). 1. Escolha **caches Valkey** ou **caches Redis OSS nos ElastiCache** **Recursos** listados no painel de navegação, presentes à esquerda. 1. Escolha o cache que você deseja atualizar. 1. Escolha o menu suspenso **Actions** (Ações) e escolha **Modify** (Modificar). 1. Escolha **Enable** (Habilitar) em **Encryption in transit** (Criptografia em trânsito) na seção **Security** (Segurança). 1. Escolha **Preferred** (Preferencial) como **Transit encryption mode** (Modo de criptografia em trânsito). 1. Escolha **Preview changes** (Visualizar alterações) e salve suas alterações. Depois de migrar todos os seus clientes Valkey ou Redis OSS para usar conexões criptografadas: **Defina seu **Modo de criptografia em trânsito** como **Obrigatório**** 1. Faça login no Console de gerenciamento da AWS e abra o ElastiCache console da Amazon em [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/). 1. Escolha **caches Valkey** ou **caches Redis OSS nos ElastiCache** **Recursos** listados no painel de navegação, presentes à esquerda. 1. Escolha o cache que você deseja atualizar. 1. Escolha o menu suspenso **Actions** (Ações) e escolha **Modify** (Modificar). 1. Escolha **Required** (Obrigatório) como **Transit encryption mode** (Modo de criptografia em trânsito), na seção **Security** (Segurança). 1. Escolha **Preview changes** (Visualizar alterações) e salve suas alterações. ## Habilitando a criptografia em trânsito usando o AWS CLI Para habilitar a criptografia em trânsito ao criar um grupo de replicação do Valkey ou do Redis OSS usando a AWS CLI, use o parâmetro `transit-encryption-enabled`. ### Habilitação da criptografia em trânsito em um cluster baseado em nós para Valkey ou Redis OSS (modo cluster desabilitado) (CLI) Use a AWS CLI operação `create-replication-group` e os parâmetros a seguir para criar um grupo de replicação Valkey ou Redis OSS com réplicas que tenham a criptografia em trânsito ativada: **Principais parâmetros:** + **--engine**: precisa ser `valkey` ou `redis`. + **--engine-version**: se o mecanismo for Redis OSS, é preciso que seja 3.2.6, 4.0.10 ou posterior. + **--transit-encryption-enabled**—Obrigatório. Se você habilitar a criptografia em trânsito, também deverá fornecer um valor para o parâmetro `--cache-subnet-group`. + **--num-cache-clusters**: deve ser pelo menos 1. O valor máximo para esse parâmetro é de seis. Para saber mais, consulte: + [Criação de um grupo de replicação do Valkey ou Redis OSS (modo cluster desabilitado) do início (AWS CLI)](Replication.CreatingReplGroup.NoExistingCluster.Classic.md#Replication.CreatingReplGroup.NoExistingCluster.Classic.CLI) + [create-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-replication-group.html) ### Habilitação da criptografia em trânsito em um cluster baseado em nós para Valkey ou Redis OSS (modo cluster habilitado) (CLI) Use a AWS CLI operação `create-replication-group` e os parâmetros a seguir para criar um grupo de replicação Valkey ou Redis OSS (modo de cluster ativado) que tenha a criptografia em trânsito ativada: **Principais parâmetros:** + **--engine**: precisa ser `valkey` ou `redis`. + **--engine-version**: se o mecanismo for Redis OSS, é preciso que seja 3.2.6, 4.0.10 ou posterior. + **--transit-encryption-enabled**: obrigatório. Se você habilitar a criptografia em trânsito, também deverá fornecer um valor para o parâmetro `--cache-subnet-group`. + Use um dos seguintes conjuntos de parâmetros para especificar a configuração dos grupos de nó do grupo de replicação: + **--num-node-groups**: especifica o número de grupos de fragmentos (grupos de nós) deste grupo de replicação. O valor máximo desse parâmetro é de 500. **--replicas-per-node-group**: especifica o número de nós de réplica em cada grupo de nós. O valor especificado aqui é aplicado a todos os fragmentos neste grupo de replicação. O valor máximo desse parâmetro é de 5. + **--node-group-configuration**: especifica a configuração de cada fragmento de forma independente. Para saber mais, consulte: + [Criação de um grupo de replicação do Valkey ou Redis OSS (modo cluster habilitado) do início (AWS CLI)](Replication.CreatingReplGroup.NoExistingCluster.Cluster.md#Replication.CreatingReplGroup.NoExistingCluster.Cluster.CLI) + [create-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-replication-group.html) ### Habilitação da criptografia em trânsito em um cluster existente usando o AWS CLI Habilitar a criptografia em trânsito é um processo de duas etapas para o qual você deve primeiro definir o modo de criptografia de em trânsito como `preferred`. Esse modo permite que seus clientes Valkey ou Redis OSS se conectem usando conexões criptografadas e não criptografadas. Depois de migrar todos os seus clientes Valkey ou Redis OSS para usar conexões criptografadas, você pode modificar a configuração do cluster para definir o modo de criptografia em trânsito como `required`. Se o modo de criptografia em trânsito for definido como `required`, todas as conexões não criptografadas serão eliminadas e somente conexões criptografadas serão permitidas. Use a AWS CLI operação `modify-replication-group` e os parâmetros a seguir para atualizar um grupo de replicação Valkey ou Redis OSS (modo de cluster ativado) que tenha a criptografia em trânsito desativada. **Como habilitar a criptografia em trânsito** 1. transit-encryption-modeDefina como`preferred`, usando os seguintes parâmetros + **--transit-encryption-enabled**—Obrigatório. + **--transit-encryption-mode**: deve ser definido como `preferred`. 1. transit-encryption-modeDefina como`required`, usando os seguintes parâmetros: + **--transit-encryption-enabled**—Obrigatório. + **--transit-encryption-mode**: deve ser definido como `required`. # Conexão ao ElastiCache (Valkey) ou ao Amazon ElastiCache para Redis OSS com criptografia em trânsito usando o valkey-cli Para acessar dados de caches do ElastiCache para Redis OSS habilitados com criptografia em trânsito, você usa clientes que trabalhem com Secure Socket Layer (SSL). Você também pode usar o valkey-cli com TLS/SSL no Amazon Linux e no Amazon Linux 2. Se o cliente não oferecer suporte ao TLS, você poderá usar o comando `stunnel` no host do cliente a fim de criar um túnel SSL para os nós do Redis OSS. ## Conexão criptografada com Linux Para usar o valkey-cli para se conectar a um cluster do Valkey ou Redis OSS habilitado com criptografia em trânsito no Amazon Linux 2 ou Amazon Linux, siga estas etapas. 1. Baixe e compile o utilitário valkey-cli. Esse utilitário está incluído na distribuição do software Valkey. 1. No prompt de comando da sua instância do EC2, digite os comandos apropriados para a versão do Linux que você está usando. **Amazon Linux 2** Se estiver usando o Amazon Linux 2, digite o seguinte: ``` sudo yum -y install openssl-devel gcc wget https://github.com/valkey-io/valkey/archive/refs/tags/7.2.6.tar.gz tar xvzf valkey-7.2.6.tar.gz cd valkey-7.2.6 make distclean make valkey-cli BUILD_TLS=yes sudo install -m 755 src/valkey-cli /usr/local/bin/ ``` **Amazon Linux** Se estiver usando o Amazon Linux, digite o seguinte: ``` sudo yum install gcc jemalloc-devel openssl-devel tcl tcl-devel clang wget wget https://github.com/valkey-io/valkey/archive/refs/tags/8.0.0.tar.gz tar xvzf valkey-8.0.0.tar.gz cd valkey-8.0.0 make valkey-cli CC=clang BUILD_TLS=yes sudo install -m 755 src/valkey-cli /usr/local/bin/ ``` No Amazon Linux, também pode ser necessário executar as seguintes etapas adicionais: ``` sudo yum install clang CC=clang make sudo make install ``` 1. Depois de baixar e instalar o utilitário valkey-cli, recomendamos executar o comando opcional `make-test`. 1. Para se conectar a um cluster com criptografia e autenticação habilitadas, digite este comando: ``` valkey-cli -h Primary or Configuration Endpoint --tls -a 'your-password' -p 6379 ``` **nota** Se você instalar o redis6 no Amazon Linux 2023, agora poderá usar o comando `redis6-cli` em vez de `valkey-cli`: ``` redis6-cli -h Primary or Configuration Endpoint --tls -p 6379 ``` ## Conexão criptografada com stunnel Para usar o valkey-cli para se conectar a um cluster do Redis OSS habilitado com criptografia em trânsito usando túnel, siga as etapas a seguir. 1. Use o SSH para se conectar ao seu cliente e instalar o `stunnel`. ``` sudo yum install stunnel ``` 1. Execute o seguinte comando para criar e editar o arquivo `'/etc/stunnel/valkey-cli.conf'` simultaneamente para adicionar um endpoint de cluster do ElastiCache para Redis OSS a um ou mais parâmetros de conexão, usando a saída fornecida abaixo como modelo. ``` vi /etc/stunnel/valkey-cli.conf fips = no setuid = root setgid = root pid = /var/run/stunnel.pid debug = 7 delay = yes options = NO_SSLv2 options = NO_SSLv3 [valkey-cli] client = yes accept = 127.0.0.1:6379 connect = primary.ssltest.wif01h.use1.cache.amazonaws.com:6379 [valkey-cli-replica] client = yes accept = 127.0.0.1:6380 connect = ssltest-02.ssltest.wif01h.use1.cache.amazonaws.com:6379 ``` Neste exemplo, o arquivo de configuração tem duas conexões, `valkey-cli` e `valkey-cli-replica`. Os parâmetros são definidos como a seguir: + **client** (cliente) é definido com sim para especificar que essa instância de stunnel é um cliente. + **accept** (aceitar) é definido com o IP do cliente. Neste exemplo, o primário é definido com o Redis OSS padrão 127.0.0.1 na porta 6379. A réplica deve chamar uma porta diferente e ser definida como 6380. Você pode usar portas efêmeras 1024-65535. Para obter mais informações, consulte [Portas efêmeras](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_ACLs.html#VPC_ACLs_Ephemeral_Ports) no *Guia do usuário da Amazon VPC.* + **connect** é definido como o endpoint do servidor Redis OSS. Para obter mais informações, consulte [Encontrar endpoints de conexão no ElastiCache](Endpoints.md). 1. Início `stunnel`. ``` sudo stunnel /etc/stunnel/valkey-cli.conf ``` Use o comando `netstat` para confirmar que os túneis começaram a funcionar. ``` sudo netstat -tulnp | grep -i stunnel tcp 0 0 127.0.0.1:6379 0.0.0.0:* LISTEN 3189/stunnel tcp 0 0 127.0.0.1:6380 0.0.0.0:* LISTEN 3189/stunnel ``` 1. Conecte-se ao nó criptografado do Redis OSS usando o endpoint local do túnel. + Se nenhuma senha AUTH foi usada durante a criação do cluster do ElastiCache para Redis OSS, este exemplo usa o valkey-cli para se conectar ao servidor ElastiCache para Redis OSS usando o caminho completo para o valkey-cli, no Amazon Linux: ``` /home/ec2-user/redis-7.2.5/src/valkey-cli -h localhost -p 6379 ``` Se a senha AUTH foi usada durante a criação do cluster do Redis OSS, este exemplo usa o valkey-cli para se conectar ao servidor Redis OSS usando o caminho completo para o valkey-cli, no Amazon Linux: ``` /home/ec2-user/redis-7.2.5/src/valkey-cli -h localhost -p 6379 -a my-secret-password ``` OU + Altere o diretório para redis-7.2.5 e faça o seguinte: Se nenhuma senha AUTH foi usada durante a criação do cluster do ElastiCache para Redis OSS, este exemplo usa o valkey-cli para se conectar ao servidor ElastiCache para Redis OSS usando o caminho completo para o valkey-cli, no Amazon Linux: ``` src/valkey-cli -h localhost -p 6379 ``` Se a senha AUTH foi usada durante a criação do cluster do Redis OSS, este exemplo usa o valkey-cli para se conectar ao servidor Valkey ou Redis OSS usando o caminho completo para o valkey-cli, no Amazon Linux: ``` src/valkey-cli -h localhost -p 6379 -a my-secret-password ``` Este exemplo usa o Telnet para se conectar ao servidor Valkey ou Redis OSS. ``` telnet localhost 6379 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. auth MySecretPassword +OK get foo $3 bar ``` 1. Para encerrar e fechar os túneis SSL, `pkill` o processo de stunnel. ``` sudo pkill stunnel ``` # Ativar criptografia em trânsito em um cluster Redis OSS baseado em nós usando Python O guia a seguir demonstrará como ativar a criptografia em trânsito em um cluster do Redis OSS 7.0 que foi originalmente criado com a criptografia em trânsito desativada. Os clientes TCP e TLS continuarão se comunicando com o cluster durante esse processo sem tempo de inatividade. O Boto3 obterá as credenciais necessárias (`aws_access_key_id`, `aws_secret_access_key` e `aws_session_token`) das variáveis de ambiente. Essas credenciais serão coladas com antecedência no mesmo terminal bash em que executaremos o `python3` para processar o código Python mostrado nesse guia. O código no exemplo abaixo foi processado a partir de uma EC2 instância que foi executada na mesma VPC que será usada para criar o ElastiCache Redis OSS Cluster nela. **nota** Os exemplos a seguir usam o SDK boto3 para operações de ElastiCache gerenciamento (criação de cluster ou usuário) e redis-py-cluster redis-py/ para tratamento de dados. Você deve usar pelo menos a versão boto3 (=\$1) 1.26.39 para usar a migração TLS on-line com a API de modificação de cluster. ElastiCache oferece suporte à migração de TLS on-line somente para clusters com Valkey versão 7.2 e superior ou Redis OSS versão 7.0 ou superior. Portanto, se você tiver um cluster executando uma versão do Redis OSS anterior à 7.0, será preciso atualizar a versão do Redis OSS do seu cluster. Para obter mais informações sobre as diferenças entre as versões, consulte [Principais diferenças de comportamento e compatibilidade do mecanismo da versão com o Redis OSS](VersionManagementConsiderations.md). **Topics** + [Defina as constantes de string que iniciarão o ElastiCache Valkey ou o Redis OSS Cluster](#enable-python-define-constants) + [Defina as classes para a configuração do cluster](#enable-python-define-classes) + [Defina uma classe que representará o próprio cluster](#enable-python-define-classes-cluster) + [(Opcional) Crie uma classe wrapper para demonstrar a conexão do cliente com o cluster do Valkey ou Redis OSS](#enable-python-create-wrapper) + [Crie a função principal que demonstra o processo de alteração da configuração de criptografia em trânsito](#enable-python-main-function) ## Defina as constantes de string que iniciarão o ElastiCache Valkey ou o Redis OSS Cluster Primeiro, vamos definir algumas constantes de string simples do Python que conterão os nomes das AWS entidades necessárias para criar o ElastiCache cluster`security-group`, como`Cache Subnet group`, e a. `default parameter group` Todas essas AWS entidades devem ser criadas com antecedência em sua AWS conta na região que você deseja usar. ``` #Constants definitions SECURITY_GROUP = "sg-0492aa0a29c558427" CLUSTER_DESCRIPTION = "This cluster has been launched as part of the online TLS migration user guide" EC_SUBNET_GROUP = "client-testing" DEFAULT_PARAMETER_GROUP_REDIS_7_CLUSTER_MODE_ENABLED = "default.redis7.cluster.on" ``` ## Defina as classes para a configuração do cluster Agora, vamos definir algumas classes simples de Python que representarão a configuração de um cluster, que conterá metadados sobre o cluster, como a versão do Valkey ou do Redis OSS, o tipo de instância e se a criptografia em trânsito (TLS) está habilitada ou desabilitada. ``` #Class definitions class Config: def __init__( self, instance_type: str = "cache.t4g.small", version: str = "7.0", multi_az: bool = True, TLS: bool = True, name: str = None, ): self.instance_type = instance_type self.version = version self.multi_az = multi_az self.TLS = TLS self.name = name or f"tls-test" def create_base_launch_request(self): return { "ReplicationGroupId": self.name, "TransitEncryptionEnabled": self.TLS, "MultiAZEnabled": self.multi_az, "CacheNodeType": self.instance_type, "Engine": "redis", "EngineVersion": self.version, "CacheSubnetGroupName": EC_SUBNET_GROUP , "CacheParameterGroupName": DEFAULT_PARAMETER_GROUP_REDIS_7_CLUSTER_MODE_ENABLED , "ReplicationGroupDescription": CLUSTER_DESCRIPTION, "SecurityGroupIds": [SECURITY_GROUP], } class ConfigCME(Config): def __init__( self, instance_type: str = "cache.t4g.small", version: str = "7.0", multi_az: bool = True, TLS: bool = True, name: str = None, num_shards: int = 2, num_replicas_per_shard: int = 1, ): super().__init__(instance_type, version, multi_az, TLS, name) self.num_shards = num_shards self.num_replicas_per_shard = num_replicas_per_shard def create_launch_request(self) -> dict: launch_request = self.create_base_launch_request() launch_request["NumNodeGroups"] = self.num_shards launch_request["ReplicasPerNodeGroup"] = self.num_replicas_per_shard return launch_request ``` ## Defina uma classe que representará o próprio cluster Agora, vamos definir algumas classes simples de Python que representarão o próprio ElastiCache Valkey ou Redis OSS Cluster. Essa classe terá um campo de cliente que conterá um cliente boto3 para operações ElastiCache de gerenciamento, como criar o cluster e consultar a API. ElastiCache ``` import botocore.config import boto3 # Create boto3 client def init_client(region: str = "us-east-1"): config = botocore.config.Config(retries={"max_attempts": 10, "mode": "standard"}) init_request = dict() init_request["config"] = config init_request["service_name"] = "elasticache" init_request["region_name"] = region return boto3.client(**init_request) class ElastiCacheClusterBase: def __init__(self, name: str): self.name = name self.elasticache_client = init_client() def get_first_replication_group(self): return self.elasticache_client.describe_replication_groups( ReplicationGroupId=self.name )["ReplicationGroups"][0] def get_status(self) -> str: return self.get_first_replication_group()["Status"] def get_transit_encryption_enabled(self) -> bool: return self.get_first_replication_group()["TransitEncryptionEnabled"] def is_available(self) -> bool: return self.get_status() == "available" def is_modifying(self) -> bool: return self.get_status() == "modifying" def wait_for_available(self): while True: if self.is_available(): break else: time.sleep(5) def wait_for_modifying(self): while True: if self.is_modifying(): break else: time.sleep(5) def delete_cluster(self) -> bool: self.elasticache_client.delete_replication_group( ReplicationGroupId=self.name, RetainPrimaryCluster=False ) def modify_transit_encryption_mode(self, new_transit_encryption_mode: str): # generate api call to migrate the cluster to TLS preffered or to TLS required self.elasticache_client.modify_replication_group( ReplicationGroupId=self.name, TransitEncryptionMode=new_transit_encryption_mode, TransitEncryptionEnabled=True, ApplyImmediately=True, ) self.wait_for_modifying() class ElastiCacheClusterCME(ElastiCacheClusterBase): def __init__(self, name: str): super().__init__(name) @classmethod def launch(cls, config: ConfigCME = None) -> ElastiCacheClusterCME: config = config or ConfigCME() print(config) new_cluster = ElastiCacheClusterCME(config.name) launch_request = config.create_launch_request() new_cluster.elasticache_client.create_replication_group(**launch_request) new_cluster.wait_for_available() return new_cluster def get_configuration_endpoint(self) -> str: return self.get_first_replication_group()["ConfigurationEndpoint"]["Address"] #Since the code can throw exceptions, we define this class to make the code more readable and #so we won't forget to delete the cluster class ElastiCacheCMEManager: def __init__(self, config: ConfigCME = None): self.config = config or ConfigCME() def __enter__(self) -> ElastiCacheClusterCME: self.cluster = ElastiCacheClusterCME.launch(self.config) return self.cluster def __exit__(self, exc_type, exc_val, exc_tb): self.cluster.delete_cluster() ``` ## (Opcional) Crie uma classe wrapper para demonstrar a conexão do cliente com o cluster do Valkey ou Redis OSS Agora, vamos criar uma classe de wrapper para o cliente `redis-py-cluster`. Essa classe de wrapper será compatível com o pré-preenchimento do cluster com algumas chaves e, em seguida, com a execução de comandos `get` aleatórios repetidos. **nota** Essa é uma etapa opcional, mas simplifica o código da função principal que vem em uma etapa posterior. ``` import redis improt random from time import perf_counter_ns, time class DowntimeTestClient: def __init__(self, client): self.client = client # num of keys prefilled self.prefilled = 0 # percent of get above prefilled self.percent_get_above_prefilled = 10 # nil result expected when get hit above prefilled # total downtime in nano seconds self.downtime_ns = 0 # num of success and fail operations self.success_ops = 0 self.fail_ops = 0 self.connection_errors = 0 self.timeout_errors = 0 def replace_client(self, client): self.client = client def prefill_data(self, timelimit_sec=60): end_time = time() + timelimit_sec while time() < end_time: self.client.set(self.prefilled, self.prefilled) self.prefilled += 1 # unsuccesful operations throw exceptions def _exec(self, func): try: start_ns = perf_counter_ns() func() self.success_ops += 1 elapsed_ms = (perf_counter_ns() - start_ns) // 10 ** 6 # upon succesful execution of func # reset random_key to None so that the next command # will use a new random key self.random_key = None except Exception as e: elapsed_ns = perf_counter_ns() - start_ns self.downtime_ns += elapsed_ns # in case of failure- increment the relevant counters so that we will keep track # of how many connection issues we had while trying to communicate with # the cluster. self.fail_ops += 1 if e.__class__ is redis.exceptions.ConnectionError: self.connection_errors += 1 if e.__class__ is redis.exceptions.TimeoutError: self.timeout_errors += 1 def _repeat_exec(self, func, seconds): end_time = time() + seconds while time() < end_time: self._exec(func) def _new_random_key_if_needed(self, percent_above_prefilled): if self.random_key is None: max = int((self.prefilled * (100 + percent_above_prefilled)) / 100) return random.randint(0, max) return self.random_key def _random_get(self): key = self._new_random_key_if_needed(self.percent_get_above_prefilled) result = self.client.get(key) # we know the key was set for sure only in the case key < self.prefilled if key < self.prefilled: assert result.decode("UTF-8") == str(key) def repeat_get(self, seconds=60): self._repeat_exec(self._random_get, seconds) def get_downtime_ms(self) -> int: return self.downtime_ns // 10 ** 6 def do_get_until(self, cond_check): while not cond_check(): self.repeat_get() # do one more get cycle once condition is met self.repeat_get() ``` ## Crie a função principal que demonstra o processo de alteração da configuração de criptografia em trânsito Agora, vamos definir a função principal, que fará o seguinte: 1. Crie o cluster usando o cliente boto3 ElastiCache . 1. Inicialize o cliente `redis-py-cluster` que se conectará ao cluster com uma conexão TCP clara sem TLS. 1. O cliente `redis-py-cluster` preenche o cluster com alguns dados. 1. O cliente boto3 acionará a migração de TLS de não TLS para TLS preferencial. 1. Enquanto o cluster estiver sendo migrado para o TLS `Preferred`, o cliente TCP `redis-py-cluster` enviará operações `get` repetidas para o cluster até que a migração seja concluída. 1. Após a conclusão da migração para o TLS `Preferred`, afirmaremos que o cluster é compatível com a criptografia em trânsito. Depois, criaremos um cliente `redis-py-cluster` que se conectará ao cluster com TLS. 1. Enviaremos alguns comandos `get` usando o novo cliente TLS e o antigo cliente TCP. 1. O cliente boto3 acionará a migração de TLS de TLS `Preferred` para TLS obrigatório. 1. Enquanto o cluster estiver sendo migrado para o TLS obrigatório, o cliente redis-py-cluster TLS enviará `get` operações repetidas para o cluster até que a migração seja concluída. ``` import redis def init_cluster_client( cluster: ElastiCacheClusterCME, prefill_data: bool, TLS: bool = True) -> DowntimeTestClient: # we must use for the host name the cluster configuration endpoint. redis_client = redis.RedisCluster( host=cluster.get_configuration_endpoint(), ssl=TLS, socket_timeout=0.25, socket_connect_timeout=0.1 ) test_client = DowntimeTestClient(redis_client) if prefill_data: test_client.prefill_data() return test_client if __name__ == '__main__': config = ConfigCME(TLS=False, instance_type="cache.m5.large") with ElastiCacheCMEManager(config) as cluster: # create a client that will connect to the cluster with clear tcp connection test_client_tcp = init_cluster_client(cluster, prefill_data=True, TLS=False) # migrate the cluster to TLS Preferred cluster.modify_transit_encryption_mode(new_transit_encryption_mode="preferred") # do repeated get commands until the cluster finishes the migration to TLS Preferred test_client_tcp.do_get_until(cluster.is_available) # verify that in transit encryption is enabled so that clients will be able to connect to the cluster with TLS assert cluster.get_transit_encryption_enabled() == True # create a client that will connect to the cluster with TLS connection. # we must first make sure that the cluster indeed supports TLS test_client_tls = init_cluster_client(cluster, prefill_data=True, TLS=True) # by doing get commands with the tcp client for 60 more seconds # we can verify that the existing tcp connection to the cluster still works test_client_tcp.repeat_get(seconds=60) # do get commands with the new TLS client for 60 more seconds test_client_tcp.repeat_get(seconds=60) # migrate the cluster to TLS required cluster.modify_transit_encryption_mode(new_transit_encryption_mode="required") # from this point the tcp clients will be disconnected and we must not use them anymore. # do get commands with the TLS client until the cluster finishes migartion to TLS required mode. test_client_tls.do_get_until(cluster.is_available) ``` # 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, o registro DNS do endpoint de configuração de cluster antigo é mantido e os novos registros DNS do endpoint de configuração de cluster são gerados em um formato diferente. Os clusters habilitados para TLS usam um formato de registros DNS diferente dos clusters desabilitados para TLS. O ElastiCache manterá os dois registros DNS quando um cluster for configurado no `encryption mode: Preferred` 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”: + 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 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 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 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 ``` ## Conectar-se a nós habilitados com criptografia em trânsito usando o Openssl (Memcached) Para acessar dados de quatro nós do ElastiCache Memcached habilitados com criptografia em trânsito, você precisa usar clientes que funcionem com Secure Socket Layer (SSL). Também é possível usar a Openssl s\$1client no Amazon Linux e no Amazon Linux 2. Para usar a Openssl s\$1client para se conectar a um cluster Memcached habilitado com criptografia em trânsito no Amazon Linux 2 ou no Amazon Linux: ``` /usr/bin/openssl s_client -connect memcached-node-endpoint:memcached-port ``` ## Criação de um cliente TLS Memcached usando Java Para criar um cliente no modo TLS, faça o seguinte para inicializar o cliente com o apropriado: SSLContext ``` import java.security.KeyStore; import javax.net.ssl.SSLContext; import javax.net.ssl.TrustManagerFactory; import net.spy.memcached.AddrUtil; import net.spy.memcached.ConnectionFactoryBuilder; import net.spy.memcached.MemcachedClient; public class TLSDemo { public static void main(String[] args) throws Exception { ConnectionFactoryBuilder connectionFactoryBuilder = new ConnectionFactoryBuilder(); // Build SSLContext TrustManagerFactory tmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm()); tmf.init((KeyStore) null); SSLContext sslContext = SSLContext.getInstance("TLS"); sslContext.init(null, tmf.getTrustManagers(), null); // Create the client in TLS mode connectionFactoryBuilder.setSSLContext(sslContext); MemcachedClient client = new MemcachedClient(connectionFactoryBuilder.build(), AddrUtil.getAddresses("mycluster.fnjyzo.cfg.use1.cache.amazonaws.com:11211")); // Store a data item for an hour. client.set("theKey", 3600, "This is the data value"); } } ``` ## Criação de um cliente TLS Memcached usando PHP Para criar um cliente no modo TLS, faça o seguinte para inicializar o cliente com o apropriado: SSLContext ``` setOption(Memcached::OPT_CLIENT_MODE, Memcached::DYNAMIC_CLIENT_MODE); /* Add the memcached's cluster server/s */ $tls_client->addServer($server_endpoint, $server_port); /* Configure the client to use TLS */ if(!$tls_client->setOption(Memcached::OPT_USE_TLS, 1)) { echo $tls_client->getLastErrorMessage(), "\n"; exit(1); } /* Set your TLS context configurations values. * See MemcachedTLSContextConfig in memcached-api.php for all configurations */ $tls_config = new MemcachedTLSContextConfig(); $tls_config->hostname = '*.mycluster.fnjyzo.use1.cache.amazonaws.com'; $tls_config->skip_cert_verify = false; $tls_config->skip_hostname_verify = false; /* Use the created TLS context configuration object to create OpenSSL's SSL_CTX and set it to your client. * Note: These TLS context configurations will be applied to all the servers connected to this client. */ $tls_client->createAndSetTLSContext((array)$tls_config); /* test the TLS connection with set-get scenario: */ /* store the data for 60 seconds in the cluster. * The client will decide which cache host will store this item. */ if($tls_client->set('key', 'value', 60)) { print "Successfully stored key\n"; } else { echo "Failed to set key: ", $tls_client->getLastErrorMessage(), "\n"; exit(1); } /* retrieve the key */ if ($tls_client->get('key') === 'value') { print "Successfully retrieved key\n"; } else { echo "Failed to get key: ", $tls_client->getLastErrorMessage(), "\n"; exit(1); } ``` Para obter mais informações sobre como usar o cliente PHP, consulte [Instalação do cliente de cluster do ElastiCache para PHP](Appendix.PHPAutoDiscoverySetup.md). # Criptografia em repouso em ElastiCache Para ajudar a manter seus dados seguros, a Amazon ElastiCache e o Amazon S3 oferecem maneiras diferentes de restringir o acesso aos dados em seu cache. Para obter mais informações, consulte [Amazon VPCs e ElastiCache segurança](VPCs.md) e [Identity and Access Management para Amazon ElastiCache](IAM.md). ElastiCache a criptografia em repouso é um recurso para aumentar a segurança dos dados criptografando dados em disco. Ela está sempre habilitada em um cache sem servidor. Quando habilitada, ela criptografa os seguintes aspectos: + Disco durante as operações de sincronização, backup e swap + Backups armazenados no Amazon S3 Os dados armazenados em SSDs (unidades de estado sólido) em clusters habilitados para armazenamento de dados em camadas são sempre criptografados. ElastiCache oferece criptografia padrão (gerenciada pelo serviço) em repouso, bem como a capacidade de usar suas próprias chaves AWS KMS simétricas gerenciadas pelo cliente no [AWS Key Management Service (KMS](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html)). Quando o backup do cache for feito, em opções de criptografia, escolha se você deseja usar a chave de criptografia padrão ou uma chave gerenciada pelo cliente. Para obter mais informações, consulte [Ativar criptografia em repouso](#at-rest-encryption-enable). **Importante** A habilitação da criptografia em repouso em um cluster do Valkey ou Redis OSS baseado em nós existente envolve a exclusão do grupo de replicação existente **após** a execução do backup e a restauração no grupo de replicação. A criptografia em repouso só pode ser habilitada em um cache quando é criada. Como a criptografia e a descriptografia dos dados requerem processamento, a ativação da criptografia em repouso pode afetar o desempenho durante essas operações. Compare seus dados com e sem criptografia em repouso para determinar o impacto no desempenho para seus casos de uso. **Topics** + [Condições da criptografia em repouso](#at-rest-encryption-constraints) + [Usando chaves gerenciadas pelo cliente do AWS KMS](#using-customer-managed-keys-for-elasticache-security) + [Ativar criptografia em repouso](#at-rest-encryption-enable) + [Consulte também](#at-rest-encryption-see-also) ## Condições da criptografia em repouso As seguintes restrições sobre a criptografia em ElastiCache repouso devem ser lembradas ao planejar sua implementação da ElastiCache criptografia em repouso: + A criptografia em repouso é compatível em grupos de replicação que estejam executando as versões do Valkey 7.2 ou posteriores e do Redis OSS (3.2.6 programadas para EOL, consulte [Cronograma de fim de vida útil das versões do Redis OSS](engine-versions.md#deprecated-engine-versions)) 4.0.10 ou posteriores. + A criptografia em repouso tem suporte somente em grupos de replicação em execução em uma Amazon VPC. + A criptografia em repouso é compatível somente com grupos de replicação que estejam executando os tipos de nó a seguir. + R7g, R6gd, R6g, R5, R4, R3 + M7g, M6g, M5, M4, M3 + T4g, T3, T2 + C7gn Para obter mais informações, consulte [Tipos de nó compatíveis](CacheNodes.SupportedTypes.md). + A criptografia em repouso é ativada por meio da configuração explícita do parâmetro `AtRestEncryptionEnabled` como `true`. + Somente é possível habilitar a criptografia em repouso em um grupo de replicação ao criá-lo. Não é possível ativar e desativar a criptografia em repouso modificando um grupo de replicação. Para obter informações sobre a implementação de criptografia em repouso em um grupo de replicação, consulte [Ativar criptografia em repouso](#at-rest-encryption-enable). + Se um cluster estiver usando um tipo de nó da família r6gd, os dados armazenados em SSD serão criptografados independentemente de a criptografia em repouso estar ativada ou não. + A opção de usar a chave gerenciada pelo cliente para criptografia em repouso não está disponível nas regiões AWS GovCloud (us-gov-east us-gov-west-1 e -1). + Se um cluster estiver usando um tipo de nó da família r6gd, os dados armazenados no SSD serão criptografados com a chave AWS KMS gerenciada pelo cliente escolhida (ou criptografia gerenciada pelo serviço nas regiões).AWS GovCloud + Com o Memcached, a criptografia em repouso só é compatível em caches de tecnologia sem servidor. + Ao usar o Memcached, a opção de usar a chave gerenciada pelo cliente para criptografia em repouso não está disponível nas regiões AWS GovCloud (us-gov-east-1 e us-gov-west -1). A implementação de criptografia em repouso pode reduzir o desempenho durante as operações de backup e sincronização de nós. Compare seus dados com criptografia em repouso e sem criptografia para determinar o impacto no desempenho da sua implementação. ## Usando chaves gerenciadas pelo cliente do AWS KMS ElastiCache suporta chaves AWS KMS simétricas gerenciadas pelo cliente (chave KMS) para criptografia em repouso. As chaves KMS gerenciadas pelo cliente são chaves de criptografia que você cria, possui e gerencia em sua conta.AWS Para obter mais informações, consulte [Chaves KMS da AWS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#root_keys) no *Guia do desenvolvedor do serviço de gerenciamento de chaves da AWS*. As chaves devem ser criadas no AWS KMS antes de poderem ser usadas com ElastiCache. Para saber como criar chaves raiz do AWS KMS, consulte [Criação de chaves](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) no *Guia do desenvolvedor do AWS Key Management Service*. ElastiCache permite a integração com o AWS KMS. Para obter mais informações, consulte [Uso de concessões](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html) no *Guia do desenvolvedor do serviço de gerenciamento de chaves da AWS*. Nenhuma ação do cliente é necessária para permitir a ElastiCache integração da Amazon com o AWS KMS. A chave de `kms:ViaService` condição limita o uso de uma chave AWS KMS (chave KMS) às solicitações de serviços especificados AWS. Para usar `kms:ViaService` com ElastiCache, inclua os dois ViaService nomes no valor da chave de condição: `elasticache.AWS_region.amazonaws.com` `dax.AWS_region.amazonaws.com` e. Para maiores informações, veja [kms: ViaService](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-via-service). Você pode usar [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)para rastrear as solicitações que a Amazon ElastiCache envia AWS Key Management Service em seu nome. Todas as chamadas de API AWS Key Management Service relacionadas às chaves gerenciadas pelo cliente têm CloudTrail registros correspondentes. Você também pode ver as concessões ElastiCache criadas ao chamar a chamada da API [ListGrants](https://docs.aws.amazon.com/kms/latest/APIReference/API_ListGrants.html)KMS. Assim que um grupo de replicação é criptografado usando a chave gerenciada pelo cliente, todos os backups do grupo de replicação são criptografados da seguinte maneira: + Os backups diários automáticos são criptografados usando a chave gerenciada pelo cliente associada ao cluster. + O backup final criado quando o grupo de replicação é excluído também é criptografado usando a chave gerenciada pelo cliente associada ao grupo de replicação. + Os backups criados manualmente são criptografados por padrão para usar a chave do KMS associada ao grupo de replicação. Você pode substituir escolhendo outra chave gerenciada pelo cliente. + Por padrão, a cópia de um backup equivale a usar uma chave gerenciada pelo cliente associada ao backup de origem. Você pode substituir escolhendo outra chave gerenciada pelo cliente. **nota** As chaves gerenciadas pelo cliente não podem ser usadas ao exportar backups para o bucket do Amazon S3 selecionado. No entanto, todos os backups exportados para o Amazon S3 são criptografados usando [Criptografia do lado do servidor](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingServerSideEncryption.html). Você pode optar pro copiar o arquivo de backup para um novo objeto do S3 e criptografar usando uma chave do KMS gerenciada pelo cliente, copiar o arquivo para outro bucket do S3 configurado com a criptografia padrão usando uma chave do KMS ou alterar uma opção de criptografia no próprio arquivo. Você também pode usar chaves gerenciadas pelo cliente para criptografar backups criados manualmente para grupos de replicação que não usem chaves gerenciadas pelo cliente para criptografia. Com essa opção, o arquivo de backup armazenado no Amazon S3 é criptografado usando uma chave do KMS, embora os dados não sejam criptografados no grupo de replicação original. A restauração de um backup permite escolher entre as opções de criptografia disponíveis, semelhantes às opções de criptografia disponíveis ao criar um novo grupo de replicação. + Se você excluir a chave ou [desabilitá-la](https://docs.aws.amazon.com/kms/latest/developerguide/enabling-keys.html) e [revogar as concessões](https://docs.aws.amazon.com/kms/latest/APIReference/API_RevokeGrant.html) da chave que usou para criptografar um cache, o cache ficará irrecuperável. Em outras palavras, ele não pode ser modificado ou recuperado após uma falha de hardware.AWS O KMS exclui as chaves raiz somente após um período de espera de pelo menos sete dias. Depois que a chave for excluída, você poderá usar uma chave gerenciada pelo cliente diferente para criar um backup para fins de arquivamento. + A rotação automática de chaves preserva as propriedades das chaves raiz do AWS KMS, portanto, a rotação não afeta sua capacidade de acessar seus ElastiCache dados. Os ElastiCache caches criptografados da Amazon não oferecem suporte à rotação manual de chaves, o que envolve a criação de uma nova chave raiz e a atualização de qualquer referência à chave antiga. Para saber mais, consulte [Chaves rotativas do AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html) no Guia do *desenvolvedor do AWS Key Management Service*. + Criptografar um ElastiCache cache usando a chave KMS requer uma concessão por cache. Essa concessão é usada durante toda a vida útil do cache. Além disso, uma concessão por backup é usada durante a criação do backup. Essa concessão é retirada assim que o backup é criado. + Para obter mais informações sobre concessões e limites do AWS KMS, consulte [Limites](https://docs.aws.amazon.com/kms/latest/developerguide/limits.html) no *Guia do desenvolvedor do AWS Key Management Service*. ## Ativar criptografia em repouso Todos os caches sem servidor têm criptografia em repouso habilitada. Ao criar um cluster baseado em nós, você pode habilitar a criptografia em repouso definindo o parâmetro `AtRestEncryptionEnabled` como `true`. Não é possível ativar a criptografia em repouso em grupos de replicação existentes. Você pode ativar a criptografia em repouso ao criar um ElastiCache cache. Você pode fazer isso usando a Console de gerenciamento da AWSAWS CLI, a ou a ElastiCache API. Ao criar um cache, você pode escolher uma das seguintes opções: + **Default (Padrão)** – Esta opção usa a criptografia gerenciada pelo serviço em repouso. + **Chave gerenciada pelo cliente** — Essa opção permite que você forneça a chave ID/ARN do AWS KMS para criptografia em repouso. Para saber como criar chaves raiz do AWS KMS, consulte [Criar chaves](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) no Guia do *desenvolvedor do AWS Key Management Service* **Contents** + [Habilitando a criptografia em repouso usando o Console de gerenciamento da AWS](#at-rest-encryption-enable-con) + [Habilitando a criptografia em repouso usando o AWS CLI](#at-rest-encryption-enable-cli) ### Habilitação da criptografia em repouso em um cluster do Valkey ou Redis OSS baseado em nós existente Só é possível ativar a criptografia em repouso ao criar um grupo de replicação do Valkey ou Redis OSS. Se você tem um grupo de replicação no qual deseja ativar a criptografia em repouso, siga as etapas a seguir. **Para ativar a criptografia em repouso em um grupo de replicação existente** 1. Crie um backup manual do seu grupo de replicação existente. Para obter mais informações, consulte [Realização de backups manuais](backups-manual.md). 1. Crie um novo grupo de replicação com base em um backup. No novo grupo de replicação, ative a criptografia em repouso. Para obter mais informações, consulte [Restauração de um backup para um novo cache](backups-restoring.md). 1. Atualize os endpoints no seu aplicativo para apontarem para o novo grupo de replicação. 1. Exclua o grupo de replicação antigo. Para acessar mais informações, consulte [Excluindo um cluster no ElastiCache](Clusters.Delete.md) ou [Exclusão de um grupo de replicação](Replication.DeletingRepGroup.md). ### Habilitando a criptografia em repouso usando o Console de gerenciamento da AWS #### Habilitação da criptografia em repouso em um cache sem servidor (console) Todos os caches sem servidor têm criptografia em repouso habilitada. Por padrão, uma chave KMS AWS de propriedade própria é usada para criptografar dados. Para escolher sua própria AWS KMS chave, faça as seguintes seleções: + Expanda a seção **Visualizar configurações padrão**. + Escolha **Personalizar configurações padrão** na seção **Visualizar configurações padrão**. + Escolha **Personalize suas configurações de segurança** na seção **Segurança**. + Escolha **CMK gerenciada pelo cliente** na configuração **Chave de criptografia**. + Selecione uma chave na configuração **Chave AWS KMS**. #### Habilitação da criptografia em repouso em um cluster baseado em nós existente (console) Ao projetar o próprio cache, as configurações “Dev/Teste” e “Produção” com o método “Criação fácil” têm a criptografia em repouso habilitada usando a chave **Padrão**. Ao escolher a configuração por conta própria, faça as seguintes seleções: + Escolha a versão 3.2.6, 4.0.10 ou posterior como a versão do mecanismo. + Clique na caixa de seleção ao lado de **Habilitar** para a opção **Criptografia em repouso**. + Escolha uma **Chave padrão** ou uma **CMK gerenciada pelo cliente**. Para o step-by-step procedimento, consulte o seguinte: + [Criação de um cluster do Valkey (modo cluster desabilitado) (console)](SubnetGroups.designing-cluster-pre.valkey.md#Clusters.Create.CON.valkey-gs) + [Criação de um cluster do Valkey ou Redis OSS (modo cluster habilitado) (console)](Clusters.Create.md#Clusters.Create.CON.RedisCluster) ### Habilitando a criptografia em repouso usando o AWS CLI Para habilitar a criptografia em repouso ao criar um cluster OSS Valkey ou Redis usando o AWS CLI, use o at-rest-encryption-enabled parâmetro *--* ao criar um grupo de replicação. #### Habilitação da criptografia em repouso em um cluster do Valkey ou Redis OSS (modo cluster desabilitado) (CLI) A operação a seguir cria o grupo de replicação Valkey ou Redis OSS (modo de cluster desativado) `my-classic-rg` com três nós (*-- num-cache-clusters*), uma réplica primária e duas réplicas de leitura. A criptografia em repouso está habilitada para esse grupo de replicação (*-- at-rest-encryption-enabled*). Os seguintes parâmetros e seus valores são necessários para ativar a criptografia neste grupo de replicação: **Principais parâmetros** + **--engine**: precisa ser `valkey` ou `redis`. + **--engine-version**: se o mecanismo for Redis OSS, é preciso que seja 3.2.6, 4.0.10 ou posterior. + **--at-rest-encryption-enabled**: obrigatório para habilitar a criptografia em repouso. **Example 1: cluster do Valkey ou Redis OSS (modo cluster desabilitado) com réplicas** Para Linux, macOS ou Unix: ``` aws elasticache create-replication-group \ --replication-group-id my-classic-rg \ --replication-group-description "3 node replication group" \ --cache-node-type cache.m4.large \ --engine redis \ --at-rest-encryption-enabled \ --num-cache-clusters 3 ``` Para Windows: ``` aws elasticache create-replication-group ^ --replication-group-id my-classic-rg ^ --replication-group-description "3 node replication group" ^ --cache-node-type cache.m4.large ^ --engine redis ^ --at-rest-encryption-enabled ^ --num-cache-clusters 3 ^ ``` Para obter informações adicionais, consulte: + [Criação de um grupo de replicação do Valkey ou Redis OSS (modo cluster desabilitado) do início (AWS CLI)](Replication.CreatingReplGroup.NoExistingCluster.Classic.md#Replication.CreatingReplGroup.NoExistingCluster.Classic.CLI) + [create-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-replication-group.html)   #### Habilitação da criptografia em repouso em um cluster do Valkey ou Redis OSS (modo cluster habilitado) (CLI) *A operação a seguir cria o grupo de replicação Valkey ou Redis OSS (modo de cluster ativado) `my-clustered-rg` com três grupos de nós ou fragmentos (--). num-node-groups* Cada um tem três nós, uma réplica primária e duas réplicas de leitura (*-- replicas-per-node-group*). A criptografia em repouso está habilitada para esse grupo de replicação (*-- at-rest-encryption-enabled*). Os seguintes parâmetros e seus valores são necessários para ativar a criptografia neste grupo de replicação: **Principais parâmetros** + **--engine**: precisa ser `valkey` ou `redis`. + **--engine-version**: se o mecanismo for Redis OSS, é preciso que seja 4.0.10 ou posterior. + **--at-rest-encryption-enabled**: obrigatório para habilitar a criptografia em repouso. + **--cache-parameter-group**: deve ser `default-redis4.0.cluster.on` ou um derivado dele para torná-lo um grupo de replicação para o modo cluster habilitado. **Example 2: um cluster do Valkey ou Redis OSS (modo cluster habilitado)** Para Linux, macOS ou Unix: ``` aws elasticache create-replication-group \ --replication-group-id my-clustered-rg \ --replication-group-description "redis clustered cluster" \ --cache-node-type cache.m3.large \ --num-node-groups 3 \ --replicas-per-node-group 2 \ --engine redis \ --engine-version 6.2 \ --at-rest-encryption-enabled \ --cache-parameter-group default.redis6.x.cluster.on ``` Para Windows: ``` aws elasticache create-replication-group ^ --replication-group-id my-clustered-rg ^ --replication-group-description "redis clustered cluster" ^ --cache-node-type cache.m3.large ^ --num-node-groups 3 ^ --replicas-per-node-group 2 ^ --engine redis ^ --engine-version 6.2 ^ --at-rest-encryption-enabled ^ --cache-parameter-group default.redis6.x.cluster.on ``` Para obter informações adicionais, consulte: + [Criação de um grupo de replicação do Valkey ou Redis OSS (modo cluster habilitado) do início (AWS CLI)](Replication.CreatingReplGroup.NoExistingCluster.Cluster.md#Replication.CreatingReplGroup.NoExistingCluster.Cluster.CLI) + [create-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-replication-group.html) ## Consulte também + [Amazon VPCs e ElastiCache segurança](VPCs.md) + [Identity and Access Management para Amazon ElastiCache](IAM.md) # Autenticação e autorização AWS O Identity and Access Management (IAM) é um serviço da web que ajuda controlar o acesso aos recursos da AWS com segurança. O ElastiCache oferece suporte à autenticação de usuários usando o IAM e o comando AUTH do Valkey e Redis OSS, além de autorizar operações de usuários usando o controle de acesso baseado em função (RBAC). **Topics** + [Regras de controle de acesso com base em função (RBAC)](Clusters.RBAC.md) + [Autenticar com o comando AUTH do Valkey e Redis OSS](auth.md) + [Desabilitar o controle de acesso em um cache do ElastiCache Valkey ou Redis OSS](in-transit-encryption-disable.md) # Regras de controle de acesso com base em função (RBAC) Com o comando AUTH do Valkey e Redis OSS, conforme descrito em [Autenticar com o comando AUTH do Valkey e Redis OSS](auth.md), você pode usar o controle de acesso baseado em funções (RBAC). O RBAC também é a única maneira de controlar o acesso a caches sem servidor. Isso está disponível para o Valkey 7.2 e posterior e o Redis OSS 6.0 a 7.2 e posterior. O RBAC permite que você: + Controle o acesso ao cache por meio de grupos de usuários. Esses grupos de usuários foram projetados como uma maneira de organizar o acesso a caches. + Com o *authN*, tenha senhas por usuário em vez de tokens de autenticação por cluster. + Com o *authZ*, tenha permissões de usuário refinadas. + Baseie seu acesso ao cluster em ACLs. Diferentemente do AUTH do Valkey e do Redis OSS, no qual todos os clientes autenticados têm acesso total ao cache em caso de autenticação do token, o RBAC permite atribuir usuários a sets dependendo das funções desejadas dos usuários. Esses sets foram projetados como uma maneira de organizar o acesso a caches. Com o RBAC, você cria usuários e atribui a eles permissões específicas usando uma cadeia de acesso, conforme descrito a seguir. Você atribui os usuários a conjuntos alinhados com uma função específica (administradores, recursos humanos) que são então implantados em um ou mais caches. ElastiCache Fazendo isso, você pode estabelecer limites de segurança entre clientes usando o mesmo cache ou caches do Valkey ou Redis OSS e impedir que os clientes acessem os dados uns dos outros. O RBAC foi projetado para oferecer suporte à introdução da [ACL](https://valkey.io/topics/acl/) no Redis OSS 6. Quando você usa o RBAC com seu cache OSS ElastiCache Valkey ou Redis, há algumas limitações: + Um grupo de usuários configurado para o mecanismo “VALKEY” só pode conter usuários que estejam usando um mecanismo de autenticação (senha ou IAM). Isso significa que todos os usuários com o mecanismo “VALKEY” e quaisquer outros usuários com o mecanismo “Redis” que tenham sua configuração definida para autenticação com senha ou IAM podem estar nesse grupo de usuários. + Ao usar o RBAC com clusters Valkey, os dois grupos de usuários com o mecanismo “VALKEY” e com o mecanismo “REDIS” podem ser usados. + Ao usar o RBAC com clusters Redis OSS, você poderá usar somente grupos de usuários com o mecanismo “REDIS”. + Não é possível especificar senhas em uma string de acesso. Você define senhas com [CreateUser](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateUser.html)nossas [ModifyUser](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyUser.html)chamadas. + Para direitos de usuário, você habilita ou desabilita usuários com `on` e `off` como parte da string de acesso. Se nenhum deles for especificado na string de acesso, o usuário receberá `off` e não terá direitos de acesso ao cache. + Não é possível usar comandos proibidos e renomeados como parte da string de acesso. Se você especificar um comando proibido ou renomeado, será emitida uma exceção. Se você quiser usar listas de controle de acesso (ACLs) para um comando renomeado, especifique o nome original do comando, em outras palavras, o nome do comando antes de ser renomeado. + Não é possível usar o comando `reset` como parte de uma string de acesso. Você especifica senhas com parâmetros de API e, ElastiCache para Valkey e Redis, o OSS gerencia senhas. Assim, você não pode usar `reset` porque ele removeria todas as senhas de um usuário. + O Redis OSS 6 apresenta o comando [ACL LIST](https://valkey.io/commands/acl-list). Esse comando retorna uma lista de usuários junto com as regras de ACL aplicadas a cada usuário. ElastiCache suporta o `ACL LIST` comando, mas não inclui suporte para hashes de senha, como faz o Redis OSS. Com ElastiCache, você pode usar a [DescribeUsers](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeUsers.html)operação para obter informações semelhantes, incluindo as regras contidas na string de acesso. No entanto, [DescribeUsers](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeUsers.html)não recupera a senha do usuário. + [https://valkey.io/commands/acl-users](https://valkey.io/commands/acl-users) ElastiCache para Valkey e Redis, o OSS não oferece suporte a nenhum outro comando ACL baseado em gravação. + Os limites a seguir se aplicam ao seguinte: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonElastiCache/latest/dg/Clusters.RBAC.html) **RBAC com Valkey** Ao usar o Controle de Acesso Baseado em Função com o Valkey, os usuários e grupos de usuários são criados com o tipo de mecanismo “VALKEY”. Isso é recomendado, pois, por padrão, o Valkey com RBAC oferece maior segurança em comparação com o Redis OSS. Os clusters Valkey provisionados e com tecnologia sem servidor oferecem suporte a associações de usuários e grupos de usuários do VALKEY. Os principais atributos do Valkey Access Control incluem: + Os usuários do Valkey estão restritos somente às associações de grupos de usuários do Valkey. + Os grupos de usuários do Valkey podem conter usuários do Valkey e usuários do Redis OSS protegidos por senha ou habilitados para autenticação do IAM. + Os usuários do Valkey devem usar proteção por senha ou autenticação do IAM. + Os grupos de usuários do VALKEY só podem ser associados aos clusters do VALKEY + Não há nenhum requisito de usuário padrão. Quando o grupo de usuários do Valkey é anexado aos clusters, o requisito de usuário padrão é automaticamente desativado. Os clientes verão que o usuário padrão está desativado ao usar o comando ACL LIST. Veja a seguir mais informações sobre como usar o RBAC com o ElastiCache Valkey e o Redis OSS. **Topics** + [Especificação de permissões usando uma string de acesso](#Access-string) + [Aplicando o RBAC a um cache ElastiCache para Valkey ou Redis OSS](#rbac-using) + [Migração do AUTH para o RBAC](#Migrate-From-RBAC-to-Auth) + [Migração do RBAC para o AUTH](#Migrate-From-RBAC-to-AUTH-1) + [Alternância automática de senhas para os usuários](User-Secrets-Manager.md) + [Autenticação com o IAM](auth-iam.md) ## Especificação de permissões usando uma string de acesso Para especificar permissões para um cache OSS ElastiCache Valkey ou Redis, você cria uma string de acesso e a atribui a um usuário por meio do ou.AWS CLIConsole de gerenciamento da AWS As cadeias de caracteres de acesso são definidas como uma lista de regras delimitadas por espaço que são aplicadas ao usuário. Eles definem quais comandos um usuário pode executar e em quais chaves um usuário pode operar. Para executar um comando, um usuário deve ter acesso ao comando que está sendo executado e todas as chaves que estão sendo acessadas pelo comando. Regras são aplicadas da esquerda para a direita cumulativamente, e uma string mais simples pode ser usada em vez da fornecida se houver redundâncias na string fornecida. Para obter informações sobre a sintaxe das regras ACL, consulte [ACL](https://valkey.io/topics/acl/). No exemplo a seguir, a string de acesso representa um usuário ativo com acesso a todas as chaves e comandos disponíveis. `on ~* +@all` A sintaxe da cadeia de acesso é dividida da seguinte forma: + `on`: o usuário é um usuário ativo. + `~*`: o acesso é dado a todas as chaves disponíveis. + `+@all`: o acesso é dado a todos os comandos disponíveis. As configurações anteriores são as menos restritivas. Você pode modificar essas configurações para torná-las mais seguras. No exemplo a seguir, a string de acesso representa um usuário com acesso restrito ao acesso de leitura em chaves que começam com o keyspace "app::" `on ~app::* -@all +@read` Você pode refinar mais essas permissões listando comandos aos quais o usuário tem acesso: `+command1`: o acesso do usuário aos comandos é limitado a *`command1`*. `+@category`: o acesso do usuário é limitado a uma categoria de comandos. Para obter informações sobre como atribuir uma string de acesso a um usuário, consulte [Criação de usuários e grupos de usuários com o console e a CLI](#Users-management). Se você estiver migrando uma carga de trabalho existente para ElastiCache, poderá recuperar a string de acesso chamando`ACL LIST`, excluindo o usuário e quaisquer hashes de senha. Para o Redis OSS versão 6.2 e posteriores, a seguinte sintaxe de string de acesso também tem suporte: + `&*`: o acesso é dado a todos os canais disponíveis. Para o Redis OSS versão 7.0 e posteriores, a seguinte sintaxe de string de acesso também tem suporte: + `|`: ´pode ser usado para bloquear subcomandos (por exemplo, "-config\$1set"). + `%R~`: adicione o padrão de chave de leitura especificado. Comporta-se de forma semelhante ao padrão de chave normal, mas só concede permissão para ler chaves que correspondam ao padrão fornecido. Para obter mais informações, consulte [permissões de chave](https://valkey.io/topics/acl/). + `%W~`: adicione o padrão de chave de gravação especificado. Comporta-se de forma semelhante ao padrão de chave normal, mas só concede permissão para gravar em chaves que correspondam ao padrão fornecido. Para obter mais informações, consulte [Permissões de chave de ACL](https://valkey.io/topics/acl/). + `%RW~`: alias para `~`. + `()`: crie um novo seletor para combinar as regras. Os seletores são avaliados após as permissões do usuário e são avaliados de acordo com a ordem em que são definidos. Se um comando corresponder às permissões do usuário ou a qualquer seletor, ele será permitido. Para obter mais informações, consulte [Seletores de ACL](https://valkey.io/topics/acl/). + `clearselectors`: exclua todos os seletores associados ao usuário. ## Aplicando o RBAC a um cache ElastiCache para Valkey ou Redis OSS ElastiCache Para usar o Valkey ou o Redis OSS RBAC, siga as seguintes etapas: 1. Crie um ou mais usuários. 1. Crie um grupo de usuários e adicione usuários ao grupo. 1. Atribua o grupo de usuários a um cache que tenha criptografia em trânsito habilitada. Essas etapas estão descritas em detalhes a seguir. **Topics** + [Criação de usuários e grupos de usuários com o console e a CLI](#Users-management) + [Gerenciamento de grupos de usuários com o console e a CLI](#User-Groups) + [Atribuição de grupos de usuários a caches sem servidor](#Users-groups-to-serverless-caches) + [Atribuição de grupos de usuários a grupos de replicação](#Users-groups-to-RGs) ### Criação de usuários e grupos de usuários com o console e a CLI As informações de usuário para usuários do RBAC são um ID de usuário, nome de usuário e, opcionalmente, uma senha e uma string de acesso. A string de acesso fornece o nível de permissão em chaves e comandos. O ID de usuário é exclusivo para o usuário e o nome de usuário é o que é passado para o mecanismo. Certifique-se de que as permissões do usuário fornecidas fazem sentido com a finalidade pretendida do grupo de utilizadores. Por exemplo, se você criar um grupo de usuários chamado `Administrators`, qualquer usuário que você adicionar a esse grupo deve ter sua string de acesso definida para acesso total a chaves e comandos. Para usuários em um grupo de usuários `e-commerce`, você pode definir suas cadeias de acesso para acesso somente leitura. ElastiCache configura automaticamente um usuário padrão com ID de usuário e nome de usuário `"default"` e o adiciona a todos os grupos de usuários. Você não pode excluir ou modificar esse usuário. Esse usuário destina-se à compatibilidade com o comportamento padrão das versões anteriores do Redis OSS e tem uma string de acesso que permite chamar todos os comandos e acessar todas as chaves. Para adicionar um controle de acesso indicado a um cache, substitua esse usuário padrão por um novo que não esteja habilitado ou use uma senha forte. Para alterar o usuário padrão, crie um novo usuário com o nome de usuário definido como `default`. Em seguida, você pode trocá-lo pelo usuário padrão original. Os seguintes procedimentos mostram como trocar o usuário `default` original por outro usuário `default` que tem uma string de acesso modificada. **Para modificar o usuário padrão no console** 1. Faça login no Console de gerenciamento da AWS e abra o ElastiCache console da Amazon em [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/). 1. Escolha **Gerenciamento de grupos de usuários** no painel de navegação. 1. Em **ID do grupo de usuários**, escolha o ID que você deseja modificar. Verifique se você escolheu o link e não a caixa de seleção. 1. Escolha **Modificar**. 1. Na janela **Modificar**, escolha **Gerenciar**. Para “selecionar o usuário que você deseja”, selecione o usuário com o **nome de usuário** como padrão. 1. Selecione **Choose (Escolher)**. 1. Escolha **Modificar**. Quando você fizer isso, todas as conexões existentes com um cache que o usuário padrão original tiver serão encerradas. **Para modificar o usuário padrão com o AWS CLI** 1. Criar um novo usuário com o nome de usuário `default` usando os seguintes comandos. Para Linux, macOS ou Unix: ``` aws elasticache create-user \ --user-id "new-default-user" \ --user-name "default" \ --engine "VALKEY" \ --passwords "a-str0ng-pa))word" \ --access-string "off +get ~keys*" ``` Para Windows: ``` aws elasticache create-user ^ --user-id "new-default-user" ^ --user-name "default" ^ --engine "VALKEY" ^ --passwords "a-str0ng-pa))word" ^ --access-string "off +get ~keys*" ``` 1. Crie um grupo de usuários e adicione o usuário que você criou anteriormente. Para Linux, macOS ou Unix: ``` aws elasticache create-user-group \ --user-group-id "new-group-2" \ --engine "VALKEY" \ --user-ids "new-default-user" ``` Para Windows: ``` aws elasticache create-user-group ^ --user-group-id "new-group-2" ^ --engine "VALKEY" ^ --user-ids "new-default-user" ``` Ao criar um usuário, você pode configurar até duas senhas. Quando você modifica uma senha, todas as conexões existentes com os caches são mantidas. Em particular, esteja ciente dessas restrições de senha de usuário ao usar o RBAC ElastiCache para Valkey e Redis OSS: + As senhas devem ter de 16 a 128 caracteres imprimíveis. + Os seguintes caracteres não alfanuméricos não são permitidos: `,` `""` `/` `@`. #### Gerenciamento de usuários com o console e a CLI Use o procedimento a seguir para gerenciar usuários no console. **Para gerenciar usuários no console** 1. Faça login no Console de gerenciamento da AWS e abra o ElastiCache console da Amazon em [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/). 1. No ElastiCache painel da Amazon, escolha **Gerenciamento de usuários**. As seguintes opções estão disponíveis: + **Criar usuário**: ao criar um usuário, você insere um ID de usuário, um nome de usuário, um modo de autenticação e uma string de acesso. A string de acesso define o nível de permissão para quais chaves e comandos o usuário é permitido. Ao criar um usuário, você pode configurar até duas senhas. Quando você modifica uma senha, todas as conexões existentes com os caches são mantidas. + **Modificar usuário**: permite a você atualizar as configurações de um usuário ou alterar a string de acesso. + **Excluir usuário**: a conta de usuário será removida de todos os grupos de usuários aos quais ela pertence. Use o procedimento a seguir para gerenciar usuários na AWS CLI. **Para modificar um usuário usando a CLI** + Use o comando `modify-user` para atualizar a senha ou senhas de um usuário ou alterar as permissões de acesso de um usuário. Quando um usuário é modificado, os grupos de usuários associados ao usuário são atualizados com todos os caches associados ao grupo de usuários. Todas as conexões existentes são mantidas. Veja os exemplos a seguir. Para Linux, macOS ou Unix: ``` aws elasticache modify-user \ --user-id user-id-1 \ --access-string "~objects:* ~items:* ~public:*" \ --authentication-mode Type=iam ``` Para Windows: ``` aws elasticache modify-user ^ --user-id user-id-1 ^ --access-string "~objects:* ~items:* ~public:*" ^ --authentication-mode Type=iam ``` **nota** Não recomendamos usar a opção `nopass`. Se o fizer, recomendamos definir as permissões do usuário como somente de leitura, com acesso a um conjunto limitado de chaves. **Para excluir um usuário usando a CLI** + Use o comando `delete-user` para excluir um usuário. A conta é excluída e removida de todos os grupos de usuários aos quais pertence. Veja um exemplo do a seguir: Para Linux, macOS ou Unix: ``` aws elasticache delete-user \ --user-id user-id-2 ``` Para Windows: ``` aws elasticache delete-user ^ --user-id user-id-2 ``` Para ver uma lista de usuários, execute a operação [describe-users](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-users.html). ``` aws elasticache describe-users ``` ### Gerenciamento de grupos de usuários com o console e a CLI É possível criar grupos de usuários para organizar e controlar o acesso de usuários a um ou mais caches, conforme mostrado a seguir. Use o procedimento a seguir para gerenciar grupos de usuários no console. **Como gerenciar grupos de usuários usando o console** 1. Faça login no Console de gerenciamento da AWS e abra o ElastiCache console da Amazon em [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/). 1. No ElastiCache painel da Amazon, escolha **Gerenciamento de grupos de usuários**. As operações a seguir estão disponíveis para criar novos grupos de usuários: + **Criar**: ao criar um grupo de usuários, você adiciona usuários e, em seguida, atribui os grupos de usuários a caches. Por exemplo, é possível criar um grupo de usuários `Admin` para usuários que tenham funções administrativas em um cache. **Importante** Se você não estiver usando um grupo de usuários Valkey ou Redis OSS, inclua um usuário padrão ao criar um grupo de usuários. + **Add Users** (Adicionar usuários): adiciona usuários ao grupo de usuários. + **Remove Users** (Remover usuários): remove usuários do grupo de usuários. Quando os usuários são removidos de um grupo de usuários, todas as conexões existentes que eles têm com um cache são encerradas. + **Delete** (Excluir): use para excluir um grupo de usuários. Observe que o próprio grupo de usuários, e não os usuários pertencentes ao grupo, serão excluídos. Para grupos de usuários existentes, você pode fazer o seguinte: + **Add Users** (Adicionar usuários): adiciona usuários existentes ao grupo de usuários. + **Delete Users** (Excluir usuários): remove usuários existentes do grupo de usuários. **nota** Os usuários são removidos do grupo de usuários, mas não excluídos do sistema. Use os procedimentos a seguir para gerenciar grupos de usuários na CLI. **Para criar um novo grupo de usuários e adicionar um usuário usando a CLI** + Use o comando `create-user-group`, conforme mostrado a seguir. Para Linux, macOS ou Unix: ``` aws elasticache create-user-group \ --user-group-id "new-group-1" \ --engine "VALKEY" \ --user-ids user-id-1, user-id-2 ``` Para Windows: ``` aws elasticache create-user-group ^ --user-group-id "new-group-1" ^ --engine "VALKEY" ^ --user-ids user-id-1, user-id-2 ``` **Para modificar um grupo de usuários adicionando novos usuários ou removendo membros atuais usando a CLI** + Use o comando `modify-user-group`, conforme mostrado a seguir. Para Linux, macOS ou Unix: ``` aws elasticache modify-user-group --user-group-id new-group-1 \ --user-ids-to-add user-id-3 \ --user-ids-to-remove user-id-2 ``` Para Windows: ``` aws elasticache modify-user-group --user-group-id new-group-1 ^ --user-ids-to-add user-id-3 ^ --user-ids-to-removere user-id-2 ``` **nota** Quaisquer conexões abertas pertencentes a um usuário removido de um grupo de usuários são encerradas por este comando. **Para excluir um grupo de usuários usando a CLI** + Use o comando `delete-user-group`, conforme mostrado a seguir. O grupo de usuários em si, não os usuários pertencentes ao grupo, é excluído. Para Linux, macOS ou Unix: ``` aws elasticache delete-user-group / --user-group-id ``` Para Windows: ``` aws elasticache delete-user-group ^ --user-group-id ``` Para ver uma lista de grupos de usuários, você pode chamar a [describe-user-groups](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-user-groups.html)operação. ``` aws elasticache describe-user-groups \ --user-group-id test-group ``` ### Atribuição de grupos de usuários a caches sem servidor Depois que você tiver criado um grupo de usuários e adicionado usuários, a etapa final na implementação do RBAC será atribuir o grupo de usuários a um cache sem servidor. #### Atribuição de grupos de usuários a caches sem servidor usando o console Para adicionar um grupo de usuários a um cache sem servidor usando o Console de gerenciamento da AWS, faça o seguinte: + Para o modo cluster desabilitado, consulte [Criação de um cluster do Valkey (modo cluster desabilitado) (console)](SubnetGroups.designing-cluster-pre.valkey.md#Clusters.Create.CON.valkey-gs) + Para o modo cluster habilitado, consulte [Criação de um cluster do Valkey ou Redis OSS (modo cluster habilitado) (console)](Clusters.Create.md#Clusters.Create.CON.RedisCluster) #### Atribuindo grupos de usuários a caches sem servidor usando o AWS CLI A AWS CLI operação a seguir cria um cache sem servidor usando o **user-group-id** parâmetro com o valor. `my-user-group-id` Substitua o grupo de sub-redes `sng-test` por um grupo de sub-redes que exista. **Principais parâmetros** + **--engine**: precisa ser `VALKEY` ou `REDIS`. + **--user-group-id**: este valor fornece o ID do grupo de usuários, composto de usuários com permissões de acesso especificadas para o cache. Para Linux, macOS ou Unix: ``` aws elasticache create-serverless-cache \ --serverless-cache-name "new-serverless-cache" \ --description "new-serverless-cache" \ --engine "VALKEY" \ --user-group-id "new-group-1" ``` Para Windows: ``` aws elasticache create-serverless-cache ^ --serverless-cache-name "new-serverless-cache" ^ --description "new-serverless-cache" ^ --engine "VALKEY" ^ --user-group-id "new-group-1" ``` A AWS CLI operação a seguir modifica um cache sem servidor com o **user-group-id** parâmetro com o valor. `my-user-group-id` Para Linux, macOS ou Unix: ``` aws elasticache modify-serverless-cache \ --serverless-cache-name serverless-cache-1 \ --user-group-id "new-group-2" ``` Para Windows: ``` aws elasticache modify-serverless-cache ^ --serverless-cache-name serverless-cache-1 ^ --user-group-id "new-group-2" ``` Eventuais modificações feitas em um cache são atualizadas de maneira assíncrona. Você pode monitorar este progresso visualizando os eventos. Para obter mais informações, consulte [Visualizando ElastiCache eventos](ECEvents.Viewing.md). ### Atribuição de grupos de usuários a grupos de replicação Depois de criar um grupo de usuários e adicionar usuários, a etapa final na implementação do RBAC é atribuir o grupo de usuários a um grupo de replicação. #### Atribuição de grupos de usuários a grupos de replicação usando o console Para adicionar um grupo de usuários a uma replicação usando o Console de gerenciamento da AWS, faça o seguinte: + Para o modo cluster desabilitado, consulte [Criação de um cluster do Valkey (modo cluster desabilitado) (console)](SubnetGroups.designing-cluster-pre.valkey.md#Clusters.Create.CON.valkey-gs) + Para o modo cluster habilitado, consulte [Criação de um cluster do Valkey ou Redis OSS (modo cluster habilitado) (console)](Clusters.Create.md#Clusters.Create.CON.RedisCluster) #### Atribuindo grupos de usuários a grupos de replicação usando o AWS CLI A AWS CLI operação a seguir cria um grupo de replicação com a criptografia em trânsito (TLS) ativada e o **user-group-ids** parâmetro com o valor. `my-user-group-id` Substitua o grupo de sub-redes `sng-test` por um grupo de sub-redes que exista. **Principais parâmetros** + **--engine**: precisa ser `valkey` ou `redis`. + **--engine-version**: deve ser 6.0 ou posterior. + **--transit-encryption-enabled**: necessário para autenticação e para associar um grupo de usuários. + **--user-group-ids**: este valor fornece o ID do grupo de usuários, composto de usuários com permissões de acesso especificadas para o cache. + **--cache-subnet-group**: necessário para associar um grupo de usuários. Para Linux, macOS ou Unix: ``` aws elasticache create-replication-group \ --replication-group-id "new-replication-group" \ --replication-group-description "new-replication-group" \ --engine "VALKEY" \ --cache-node-type cache.m5.large \ --transit-encryption-enabled \ --user-group-ids "new-group-1" \ --cache-subnet-group "cache-subnet-group" ``` Para Windows: ``` aws elasticache create-replication-group ^ --replication-group-id "new-replication-group" ^ --replication-group-description "new-replication-group" ^ --engine "VALKEY" ^ --cache-node-type cache.m5.large ^ --transit-encryption-enabled ^ --user-group-ids "new-group-1" ^ --cache-subnet-group "cache-subnet-group" ``` A AWS CLI operação a seguir modifica um grupo de replicação com a criptografia em trânsito (TLS) ativada e o **user-group-ids** parâmetro com o valor. `my-user-group-id` Para Linux, macOS ou Unix: ``` aws elasticache modify-replication-group \ --replication-group-id replication-group-1 \ --user-group-ids-to-remove "new-group-1" \ --user-group-ids-to-add "new-group-2" ``` Para Windows: ``` aws elasticache modify-replication-group ^ --replication-group-id replication-group-1 ^ --user-group-ids-to-remove "new-group-1" ^ --user-group-ids-to-add "new-group-2" ``` Observe o `PendingChanges` na resposta. Eventuais modificações feitas em um cache são atualizadas de maneira assíncrona. Você pode monitorar este progresso visualizando os eventos. Para obter mais informações, consulte [Visualizando ElastiCache eventos](ECEvents.Viewing.md). ## Migração do AUTH para o RBAC Se você estiver usando o AUTH conforme descrito em [Autenticar com o comando AUTH do Valkey e Redis OSS](auth.md) e deseja migrar para usar o RBAC, use os seguintes procedimentos. Use o procedimento a seguir para migrar do AUTH para o RBAC usando o console. **Para migrar do AUTH do Valkey ou Redis OSS para o RBAC usando o console** 1. Faça login no Console de gerenciamento da AWS e abra o ElastiCache console em [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/). 1. Na lista no canto superior direito, escolha a AWS região em que o cache que você deseja modificar está localizado. 1. No painel de navegação, escolha o mecanismo em execução no cache que você deseja modificar. Uma lista dos caches do mecanismo escolhido é exibida. 1. Na lista de caches, para o cache que você deseja modificar, escolha o nome. 1. Para **Actions (Ações)**, escolha **Modify (Modificar)**. A janela **Modificar** é exibida. 1. Para **Controle de acesso**, escolha **Lista de controle de acesso do grupo de usuários**. 1. Em **Lista de controle de acesso do grupo de usuários**, escolha um grupo de usuários. 1. Escolha **Previsualizar alterações** e, na próxima tela, **Modificar**. Use o procedimento a seguir para migrar do AUTH do Valkey ou Redis OSS para o RBAC usando a CLI. **Para migrar do AUTH para o RBAC usando a CLI** + Use o comando `modify-replication-group`, conforme mostrado a seguir. Para Linux, macOS ou Unix: ``` aws elasticache modify-replication-group --replication-group-id test \ --auth-token-update-strategy DELETE \ --user-group-ids-to-add user-group-1 ``` Para Windows: ``` aws elasticache modify-replication-group --replication-group-id test ^ --auth-token-update-strategy DELETE ^ --user-group-ids-to-add user-group-1 ``` ## Migração do RBAC para o AUTH Se você estiver usando o RBAC e desejar migrar para o AUTH do Redis OSS, consulte [Migração do RBAC para o AUTH](auth.md#Migrate-From-RBAC-to-AUTH). **nota** Se precisar desativar o controle de acesso em um ElastiCache cache, você precisará fazer isso por meio do AWS CLI. Para obter mais informações, consulte [Desabilitar o controle de acesso em um cache do ElastiCache Valkey ou Redis OSS](in-transit-encryption-disable.md). # Alternância automática de senhas para os usuários Com AWS Secrets Manager, você pode substituir as credenciais codificadas em seu código (incluindo senhas) por uma chamada de API para o Secrets Manager para recuperar o segredo programaticamente. Isso ajuda a garantir que o segredo não será comprometido por alguém que esteja examinando seu código, pois o segredo simplesmente não está ali. Além disso, configure o Secrets Manager para alterar automaticamente o segredo para você de acordo com a programação que você especificar. Isso permite substituir segredos de longo prazo por outros de curto prazo, ajudando a reduzir de maneira significativa o risco de comprometimento. Usando o Secrets Manager, você pode alternar automaticamente suas ElastiCache senhas do OSS do Redis (ou seja, segredos) usando uma AWS Lambda função fornecida pelo Secrets Manager. Para obter mais informações sobre AWS Secrets Manager, consulte [O que éAWS Secrets Manager?](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) ## Como ElastiCache usa segredos O Valkey 7.2 e superiores têm um conjunto de atributos equivalente ao Redis OSS 7.0. No Redis OSS 6, ElastiCache introduzido [Regras de controle de acesso com base em função (RBAC)](Clusters.RBAC.md) para proteger o cluster Valkey ou Redis OSS. Esse recurso permite que certas conexões sejam limitadas em termos dos comandos que podem ser executados e das chaves que podem ser acessadas. Com o RBAC, enquanto o cliente cria um usuário com senhas, os valores da senha precisam ser inseridos manualmente em texto sem formatação e ficam visíveis para o operador. Com o Secrets Manager, as aplicações buscam a senha do Secrets Manager em vez de inseri-la manualmente e armazená-la na configuração da aplicação. Para obter informações sobre como fazer isso, consulte [Como ElastiCache os usuários são associados ao segredo](#How-User-Secrets-Manager-Associate). O uso de segredos tem um custo. Para obter informações sobre preços, consulte [Preços do AWS](https://aws.amazon.com/secrets-manager/pricing/). ## Como ElastiCache os usuários são associados ao segredo O Secrets Manager manterá uma referência para o usuário associado no campo `SecretString` do segredo. Não haverá nenhuma referência ao segredo do ElastiCache lado de fora. ``` { "password": "strongpassword", "username": "user1", "user_arn": "arn:aws:elasticache:us-east-1:xxxxxxxxxx918:user:user1" //this is the bond between the secret and the user } ``` ## Função de alternância do Lambda Para habilitar a alternância automática de senhas do Secrets Manager, você criará uma função do Lambda que interagirá com a API [modify-user](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-user.html) para atualizar as senhas do usuário. Para obter informações sobre como isso funciona, consulte [Como funciona a alternância](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html#rotate-secrets_how). **nota** Para alguns AWS serviços, para evitar o cenário confuso de substituto,AWS recomenda que você use as chaves de condição `aws:SourceArn` e as chaves de condição `aws:SourceAccount` globais. No entanto, se você incluir a condição `aws:SourceArn` em sua política de função de alternância, a função de alternância só poderá ser usada para alternar o segredo especificado por esse ARN. Recomendamos que inclua apenas a chave de contexto `aws:SourceAccount`, de modo que possa usar a função de alternância para vários segredos. Para quaisquer problemas que você possa encontrar, consulte [Solucionar problemas de rotação do AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/troubleshoot_rotation.html). ## Como criar um ElastiCache usuário e associá-lo ao Secrets Manager As seguintes etapas ilustram como criar um usuário e associá-lo ao Secrets Manager: 1. **Criar um usuário inativo** Para Linux, macOS ou Unix: ``` aws elasticache create-user \ --user-id user1 \ --user-name user1 \ --engine "REDIS" \ --no-password \ // no authentication is required --access-string "*off* +get ~keys*" // this disables the user ``` Para Windows: ``` aws elasticache create-user ^ --user-id user1 ^ --user-name user1 ^ --engine "REDIS" ^ --no-password ^ // no authentication is required --access-string "*off* +get ~keys*" // this disables the user ``` Você verá uma resposta semelhante ao seguinte: ``` { "UserId": "user1", "UserName": "user1", "Status": "active", "Engine": "redis", "AccessString": "off ~keys* -@all +get", "UserGroupIds": [], "Authentication": { "Type": "no_password" }, "ARN": "arn:aws:elasticache:us-east-1:xxxxxxxxxx918:user:user1" } ``` 1. **Criar um segredo** Para Linux, macOS ou Unix: ``` aws secretsmanager create-secret \ --name production/ec/user1 \ --secret-string \ '{ "user_arn": "arn:aws:elasticache:us-east-1:123456xxxx:user:user1", "username":"user1" }' ``` Para Windows: ``` aws secretsmanager create-secret ^ --name production/ec/user1 ^ --secret-string ^ '{ "user_arn": "arn:aws:elasticache:us-east-1:123456xxxx:user:user1", "username":"user1" }' ``` Você verá uma resposta semelhante ao seguinte: ``` { "ARN": "arn:aws:secretsmanager:us-east-1:123456xxxx:secret:production/ec/user1-eaFois", "Name": "production/ec/user1", "VersionId": "aae5b963-1e6b-4250-91c6-ebd6c47d0d95" } ``` 1. **Configurar uma função do Lambda para alternar sua senha** 1. Faça login no Console de gerenciamento da AWS e abra o console Lambda em [https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/elasticache/) 1. No painel de navegação, escolha **Functions** (Funções) e escolha a função que você criou. Escolha o nome da função, não a caixa de seleção à esquerda. 1. Escolha a guia **Configuration** (Configuração). 1. Em **General configuration** (Configuração geral), escolha **Edit** (Editar) e defina **Timeout** (Tempo limite) para pelo menos 12 minutos. 1. Escolha **Salvar**. 1. Escolha **Environment variables** (Variáveis de ambiente) e defina o seguinte: 1. SECRETS\$1MANAGER\$1ENDPOINT – https://secretsmanager. **REGION**.amazonaws.com 1. SECRET\$1ARN – O nome de recurso da Amazon (ARN) do segredo que você criou na etapa 2. 1. USER\$1NAME — Nome de usuário do ElastiCache usuário, 1. Escolha **Salvar**. 1. Escolha **Permissions** (Permissões) 1. Em **Execution role** (Função de execução), escolha o nome da função do Lambda para exibição no console do IAM. 1. A função do Lambda precisará da seguinte permissão para modificar os usuários e definir a senha: ElastiCache ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "elasticache:DescribeUsers", "elasticache:ModifyUser" ], "Resource": "arn:aws:elasticache:us-east-1:123456789012:user:user1" } ] } ``` ------ Secrets Manager  ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret", "secretsmanager:PutSecretValue", "secretsmanager:UpdateSecretVersionStage" ], "Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:XXXX" }, { "Effect": "Allow", "Action": "secretsmanager:GetRandomPassword", "Resource": "*" } ] } ``` ------ 1. Configurar a alternância de segredos do Secrets Manager 1. **Usando o Console de gerenciamento da AWS, consulte [Configurar a rotação automática para AWS segredos do Secrets Manager usando o console](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotate-secrets_turn-on-for-other.html)** Para obter mais informações sobre como configurar uma programação de alternância, consulte [Programe expressões nas alternâncias do Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotate-secrets_schedule.html). 1. **Usando o AWS CLI, consulte [Configurar a rotação automática para AWS Secrets Manager usar o AWS Command Line Interface](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotate-secrets-cli.html)** # Autenticação com o IAM **Topics** + [Visão geral do](#auth-iam-overview) + [Limitações](#auth-iam-limits) + [Configuração](#auth-iam-setup) + [Conexão](#auth-iam-Connecting) ## Visão geral do Com a autenticação IAM, você pode autenticar uma conexão ElastiCache para Valkey ou Redis OSS usando identidades AWS IAM, quando seu cache está configurado para usar Valkey ou Redis OSS versão 7 ou superior. Isso possibilita que você fortaleça seu modelo de segurança e simplifique várias tarefas administrativas de segurança. Você também pode usar a autenticação do IAM para configurar um controle de acesso refinado para cada ElastiCache cache e ElastiCache usuário individual, seguindo os princípios de permissões de privilégio mínimo. O IAM Authentication for ElastiCache funciona fornecendo um token de autenticação IAM de curta duração em vez de uma senha de ElastiCache usuário de longa duração no OSS ou comando Valkey ou Redis. `AUTH` `HELLO` Para obter mais informações sobre o token de autenticação do IAM, consulte o [processo de assinatura do Signature versão 4](https://docs.aws.amazon.com//general/latest/gr/signature-version-4.html) no Guia de referência AWS geral e no exemplo de código abaixo. Você pode usar as identidades do IAM e suas políticas associadas para restringir ainda mais o acesso ao Valkey ou Redis OSS. Também é possível conceder acesso a usuários dos provedores de identidade federados diretamente para caches do Valkey ou Redis OSS. Para usar o AWS IAM com ElastiCache, primeiro você precisa criar um ElastiCache usuário com o modo de autenticação definido como IAM. Em seguida, você pode criar ou reutilizar uma identidade do IAM. A identidade do IAM precisa de uma política associada para conceder a `elasticache:Connect` ação ao ElastiCache cache e ao ElastiCache usuário. Depois de configurado, você pode criar um token de autenticação do IAM usando AWS as credenciais do usuário ou da função do IAM. Por fim, você precisa fornecer o token de autenticação do IAM de curta duração como uma senha no cliente do Valkey ou Redis OSS ao se conectar ao cache. Um cliente Valkey ou Redis OSS com suporte para provedor de credenciais pode gerar automaticamente as credenciais temporárias automaticamente para cada nova conexão. ElastiCache realizará a autenticação do IAM para solicitações de conexão de ElastiCache usuários habilitados para IAM e validará as solicitações de conexão com o IAM. ## Limitações Ao usar a autenticação do IAM, as seguintes limitações se aplicam: + A autenticação do IAM está disponível quando usada ElastiCache para Valkey 7.2 e superior ou Redis OSS versão 7.0 e superior. + Para ElastiCache usuários habilitados para IAM, as propriedades de nome de usuário e ID de usuário devem ser idênticas. + O token de autenticação do IAM é válido por 15 minutos. Para conexões de longa duração, recomendamos usar um cliente do Valkey ou Redis OSS que suporte uma interface de provedor de credenciais. + Uma conexão autenticada pelo IAM ElastiCache para Valkey ou Redis OSS será automaticamente desconectada após 12 horas. A conexão pode ser prolongada por 12 horas enviando um comando `AUTH` ou `HELLO` com um novo token de autenticação do IAM. + A autenticação do IAM não tem suporte em comandos `MULTI EXEC`. + Atualmente, a autenticação do IAM não dá suporte às seguintes chaves de contexto de condição global: + Durante o uso da autenticação do IAM com caches sem servidor, `aws:VpcSourceIp`, `aws:SourceVpc`, `aws:SourceVpce`, `aws:CurrentTime`, `aws:EpochTime` e `aws:ResourceTag/%s` (de caches sem servidor associados e usuários) são compatíveis. + Durante o uso da autenticação do IAM com grupos de replicação, `aws:SourceIp` e `aws:ResourceTag/%s` (de grupos de replicação associados e usuários) são compatíveis. Para obter mais informações sobre chaves de contexto de condição global, consulte [Chaves de contexto de condição global da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) no Guia do usuário do IAM. ## Configuração Como configurar a autenticação do IAM 1. Criar um cache ``` aws elasticache create-serverless-cache \ --serverless-cache-name cache-01 \ --description "ElastiCache IAM auth application" \ --engine redis ``` 1. Crie um documento de política de confiança do IAM, conforme mostrado abaixo, para o perfil que permita que sua conta assuma o novo perfil. Salve a política em um arquivo chamado *trust-policy.json*. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:root" }, "Action": "sts:AssumeRole" } } ``` ------ 1. Crie um documento de política do IAM, conforme mostrado abaixo. Salve a política em um arquivo chamado *policy.json*. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect" : "Allow", "Action" : [ "elasticache:Connect" ], "Resource" : [ "arn:aws:elasticache:us-east-1:123456789012:serverlesscache:cache-01", "arn:aws:elasticache:us-east-1:123456789012:user:iam-user-01" ] } ] } ``` ------ 1. Criar um perfil do IAM. ``` aws iam create-role \ --role-name "elasticache-iam-auth-app" \ --assume-role-policy-document file://trust-policy.json ``` 1. Crie a política do IAM. ``` aws iam create-policy \ --policy-name "elasticache-allow-all" \ --policy-document file://policy.json ``` 1. Anexe a política do IAM à função. ``` aws iam attach-role-policy \ --role-name "elasticache-iam-auth-app" \ --policy-arn "arn:aws:iam::123456789012:policy/elasticache-allow-all" ``` 1. Crie um novo usuário habilitado para o IAM. ``` aws elasticache create-user \ --user-name iam-user-01 \ --user-id iam-user-01 \ --authentication-mode Type=iam \ --engine redis \ --access-string "on ~* +@all" ``` 1. Crie um grupo de usuários e anexe o usuário. ``` aws elasticache create-user-group \ --user-group-id iam-user-group-01 \ --engine redis \ --user-ids default iam-user-01 aws elasticache modify-serverless-cache \ --serverless-cache-name cache-01 \ --user-group-id iam-user-group-01 ``` ## Conexão **Conectar com token como senha** Primeiro, é necessário gerar o token de autenticação do IAM de curta duração usando uma [solicitação pré-assinada do AWS SigV4](https://docs.aws.amazon.com//general/latest/gr/sigv4-signed-request-examples.html). Depois disso, você fornecerá o token de autenticação do IAM como senha ao se conectar a um cache do Valkey ou Redis OSS, conforme mostrado no exemplo abaixo. ``` String userId = "insert user id"; String cacheName = "insert cache name"; boolean isServerless = true; String region = "insert region"; // Create a default AWS Credentials provider. // This will look for AWS credentials defined in environment variables or system properties. AWSCredentialsProvider awsCredentialsProvider = new DefaultAWSCredentialsProviderChain(); // Create an IAM authentication token request and signed it using the AWS credentials. // The pre-signed request URL is used as an IAM authentication token for ElastiCache with Redis OSS. IAMAuthTokenRequest iamAuthTokenRequest = new IAMAuthTokenRequest(userId, cacheName, region, isServerless); String iamAuthToken = iamAuthTokenRequest.toSignedRequestUri(awsCredentialsProvider.getCredentials()); // Construct Redis OSS URL with IAM Auth credentials provider RedisURI redisURI = RedisURI.builder() .withHost(host) .withPort(port) .withSsl(ssl) .withAuthentication(userId, iamAuthToken) .build(); // Create a new Lettuce Redis OSS client RedisClient client = RedisClient.create(redisURI); client.connect(); ``` Veja abaixo a definição de `IAMAuthTokenRequest`. ``` public class IAMAuthTokenRequest { private static final HttpMethodName REQUEST_METHOD = HttpMethodName.GET; private static final String REQUEST_PROTOCOL = "http://"; private static final String PARAM_ACTION = "Action"; private static final String PARAM_USER = "User"; private static final String PARAM_RESOURCE_TYPE = "ResourceType"; private static final String RESOURCE_TYPE_SERVERLESS_CACHE = "ServerlessCache"; private static final String ACTION_NAME = "connect"; private static final String SERVICE_NAME = "elasticache"; private static final long TOKEN_EXPIRY_SECONDS = 900; private final String userId; private final String cacheName; private final String region; private final boolean isServerless; public IAMAuthTokenRequest(String userId, String cacheName, String region, boolean isServerless) { this.userId = userId; this.cacheName = cacheName; this.region = region; this.isServerless = isServerless; } public String toSignedRequestUri(AWSCredentials credentials) throws URISyntaxException { Request request = getSignableRequest(); sign(request, credentials); return new URIBuilder(request.getEndpoint()) .addParameters(toNamedValuePair(request.getParameters())) .build() .toString() .replace(REQUEST_PROTOCOL, ""); } private Request getSignableRequest() { Request request = new DefaultRequest<>(SERVICE_NAME); request.setHttpMethod(REQUEST_METHOD); request.setEndpoint(getRequestUri()); request.addParameters(PARAM_ACTION, Collections.singletonList(ACTION_NAME)); request.addParameters(PARAM_USER, Collections.singletonList(userId)); if (isServerless) { request.addParameters(PARAM_RESOURCE_TYPE, Collections.singletonList(RESOURCE_TYPE_SERVERLESS_CACHE)); } return request; } private URI getRequestUri() { return URI.create(String.format("%s%s/", REQUEST_PROTOCOL, cacheName)); } private void sign(SignableRequest request, AWSCredentials credentials) { AWS4Signer signer = new AWS4Signer(); signer.setRegionName(region); signer.setServiceName(SERVICE_NAME); DateTime dateTime = DateTime.now(); dateTime = dateTime.plus(Duration.standardSeconds(TOKEN_EXPIRY_SECONDS)); signer.presignRequest(request, credentials, dateTime.toDate()); } private static List toNamedValuePair(Map> in) { return in.entrySet().stream() .map(e -> new BasicNameValuePair(e.getKey(), e.getValue().get(0))) .collect(Collectors.toList()); } } ``` **Conectar com o provedor de credenciais** O código abaixo mostra como se autenticar ElastiCache usando o provedor de credenciais de autenticação do IAM. ``` String userId = "insert user id"; String cacheName = "insert cache name"; boolean isServerless = true; String region = "insert region"; // Create a default AWS Credentials provider. // This will look for AWS credentials defined in environment variables or system properties. AWSCredentialsProvider awsCredentialsProvider = new DefaultAWSCredentialsProviderChain(); // Create an IAM authentication token request. Once this request is signed it can be used as an // IAM authentication token for ElastiCache with Redis OSS. IAMAuthTokenRequest iamAuthTokenRequest = new IAMAuthTokenRequest(userId, cacheName, region, isServerless); // Create a Redis OSS credentials provider using IAM credentials. RedisCredentialsProvider redisCredentialsProvider = new RedisIAMAuthCredentialsProvider( userId, iamAuthTokenRequest, awsCredentialsProvider); // Construct Redis OSS URL with IAM Auth credentials provider RedisURI redisURI = RedisURI.builder() .withHost(host) .withPort(port) .withSsl(ssl) .withAuthentication(redisCredentialsProvider) .build(); // Create a new Lettuce Redis OSS client RedisClient client = RedisClient.create(redisURI); client.connect(); ``` Abaixo está um exemplo de um cliente Lettuce Redis OSS que envolve um provedor de credenciais para gerar IAMAuth TokenRequest automaticamente credenciais temporárias quando necessário. ``` public class RedisIAMAuthCredentialsProvider implements RedisCredentialsProvider { private static final long TOKEN_EXPIRY_SECONDS = 900; private final AWSCredentialsProvider awsCredentialsProvider; private final String userId; private final IAMAuthTokenRequest iamAuthTokenRequest; private final Supplier iamAuthTokenSupplier; public RedisIAMAuthCredentialsProvider(String userId, IAMAuthTokenRequest iamAuthTokenRequest, AWSCredentialsProvider awsCredentialsProvider) { this.userName = userName; this.awsCredentialsProvider = awsCredentialsProvider; this.iamAuthTokenRequest = iamAuthTokenRequest; this.iamAuthTokenSupplier = Suppliers.memoizeWithExpiration(this::getIamAuthToken, TOKEN_EXPIRY_SECONDS, TimeUnit.SECONDS); } @Override public Mono resolveCredentials() { return Mono.just(RedisCredentials.just(userId, iamAuthTokenSupplier.get())); } private String getIamAuthToken() { return iamAuthTokenRequest.toSignedRequestUri(awsCredentialsProvider.getCredentials()); } } ``` # Autenticar com o comando AUTH do Valkey e Redis OSS **nota** O **AUTH** foi substituído por [Regras de controle de acesso com base em função (RBAC)](Clusters.RBAC.md). Todos os caches sem servidor devem usar o RBAC na autenticação. As senhas ou tokens de autenticação do Valkey e Redis OSS habilitam o Valkey e Redis OSS a exigir uma senha antes de permitir que os clientes executem comandos, melhorando assim a segurança dos dados. O **AUTH** está disponível somente para clusters baseados em nós. **Topics** + [Visão geral do AUTH no ElastiCache Valkey e no Redis OSS](#auth-overview) + [Aplicando autenticação a um cluster OSS ElastiCache para Valkey e Redis](#auth-using) + [Modificação do token AUTH em um cluster existente](#auth-modifyng-token) + [Migração do RBAC para o AUTH](#Migrate-From-RBAC-to-AUTH) ## Visão geral do AUTH no ElastiCache Valkey e no Redis OSS Quando você usa o **AUTH** com seu cluster OSS ElastiCache para Valkey e Redis, há alguns refinamentos. Em particular, esteja ciente destas restrições de token ou senha AUTH ao usar AUTH: + Tokens, ou senhas, devem ter de 16 a 128 caracteres imprimíveis. + Caracteres não alfanuméricos são restritos a (\$1 , &, \$1, \$1, ^, <, >, -). + O AUTH só pode ser habilitado para criptografia em trânsito para clusters do Valkey ou Redis OSS. Para configurar um token forte, recomendamos que você siga uma política de senha estrita, tal como exigir o seguinte: + Tokens ou senhas devem incluir pelo menos três dos seguintes tipos de caractere: + Caracteres maiúsculos + Caracteres minúsculos + Dígitos + Caracteres não alfanuméricos (`!`, `&`, `#`, `$`, `^`, `<`, `>`, `-`) + Tokens ou senhas não devem conter uma palavra de dicionário ou uma palavra de dicionário minimamente alterada. + Tokens ou senhas não devem ser iguais ou similares a um token usado recentemente. ## Aplicando autenticação a um cluster OSS ElastiCache para Valkey e Redis Você pode exigir que os usuários insiram um token (senha) em um servidor Valkey ou Redis OSS protegido por tokens. Para fazer isso, inclua o parâmetro `--auth-token` (API: `AuthToken`) com o token correto quando você criar seu grupo de replicação ou cluster. Inclua-o também em todos os comandos subsequentes para o grupo de replicação ou cluster. A AWS CLI operação a seguir cria um grupo de replicação com a criptografia em trânsito (TLS) ativada e o **AUTH** token. `This-is-a-sample-token` Substitua o grupo de sub-redes `sng-test` por um grupo de sub-redes que exista. **Principais parâmetros** + **--engine**: precisa ser `valkey` ou `redis`. + **--engine-version**: se o mecanismo for Redis OSS, é preciso que seja 3.2.6, 4.0.10 ou posterior. + **--transit-encryption-enabled**: obrigatório para autenticação e qualificação para HIPAA. + **--auth-token**: obrigatório para qualificação para HIPAA. Esse valor deve ser o token correto para esse servidor Valkey ou Redis OSS protegido por tokens. + **--cache-subnet-group**: obrigatório para qualificação para HIPAA. Para Linux, macOS ou Unix: ``` aws elasticache create-replication-group \ --replication-group-id authtestgroup \ --replication-group-description authtest \ --engine redis \ --cache-node-type cache.m4.large \ --num-node-groups 1 \ --replicas-per-node-group 2 \ --transit-encryption-enabled \ --auth-token This-is-a-sample-token \ --cache-subnet-group sng-test ``` Para Windows: ``` aws elasticache create-replication-group ^ --replication-group-id authtestgroup ^ --replication-group-description authtest ^ --engine redis ^ --cache-node-type cache.m4.large ^ --num-node-groups 1 ^ --replicas-per-node-group 2 ^ --transit-encryption-enabled ^ --auth-token This-is-a-sample-token ^ --cache-subnet-group sng-test ``` ## Modificação do token AUTH em um cluster existente Para facilitar a atualização da autenticação, você pode modificar o token **AUTH** usado em um cluster. Você pode fazer essa modificação se a versão do mecanismo for Valkey 7.2 ou superior ou Redis 5.0.6 ou superior. ElastiCache também deve ter a criptografia em trânsito ativada. A modificação do token de autenticação oferece suporte a duas estratégias: ROTATE (ALTERNAR) e SET (DEFINIR). A estratégia ROTATE (ALTERNAR) acrescenta um token AUTH adicional para o servidor enquanto retém o token anterior. A estratégia SET (DEFINIR) atualiza o servidor para aceitar apenas um único token AUTH. Faça essas chamadas de modificação com o parâmetro `--apply-immediately` para aplicar as alterações imediatamente. ### Alternância do token AUTH Para atualizar um servidor Valkey ou Redis OSS com um novo **token AUTH**, chame a API `ModifyReplicationGroup` com o parâmetro `--auth-token` como o novo token **AUTH** e o `--auth-token-update-strategy` com o valor ROTATE (ALTERNAR). Depois que a modificação ROTATE (ALTERNAR) for concluída, o cluster oferecerá suporte ao token AUTH anterior além do especificado no parâmetro `auth-token`. Se nenhum token AUTH tiver sido configurado no grupo de replicação antes da rotação do token AUTH, o cluster oferecerá suporte ao token AUTH especificado no parâmetro `--auth-token`, além do suporte a conexões sem autenticação. Consulte [Definição do token AUTH](#auth-modifying-set) para atualizar o token AUTH a ser necessário usando a estratégia de atualização SET (DEFINIR). **nota** Se você não configurar o token AUTH antes, depois que a modificação for concluída, o cluster não oferecerá suporte a nenhum token AUTH além do especificado no parâmetro auth-token. Se essa modificação for executada em um servidor que já ofereça suporte a dois tokens AUTH, o token AUTH mais antigo também será removido durante esta operação. Isso permite que um servidor ofereça suporte a até dois tokens AUTH mais recentes em um determinado momento. Neste ponto, você pode continuar atualizando o cliente para usar o token AUTH mais recente. Depois que os clientes forem atualizados, você poderá usar a estratégia SET (DEFINIR) para alternância de token **AUTH** (explicada na seção a seguir) para começar exclusivamente a usar o novo token. A AWS CLI operação a seguir modifica um grupo de replicação para girar o token. **AUTH** `This-is-the-rotated-token` Para Linux, macOS ou Unix: ``` aws elasticache modify-replication-group \ --replication-group-id authtestgroup \ --auth-token This-is-the-rotated-token \ --auth-token-update-strategy ROTATE \ --apply-immediately ``` Para Windows: ``` aws elasticache modify-replication-group ^ --replication-group-id authtestgroup ^ --auth-token This-is-the-rotated-token ^ --auth-token-update-strategy ROTATE ^ --apply-immediately ``` ### Definição do token AUTH Para atualizar um servidor Valkey ou Redis OSS para oferecer suporte a um único token **AUTH** necessário, chame a operação `ModifyReplicationGroup` da API com o parâmetro `--auth-token` com o mesmo valor do último token AUTH e o parâmetro `--auth-token-update-strategy` com o valor `SET`. A estratégia SET (DEFINIR) só pode ser usada com um cluster que tenha 2 tokens AUTH ou 1 token AUTH opcional do uso anterior da estratégia ROTATE (ALTERNAR). Após a conclusão da modificação, o servidor oferecerá suporte apenas para o token AUTH especificado no parâmetro auth-token. A AWS CLI operação a seguir modifica um grupo de replicação para definir o token AUTH. `This-is-the-set-token` Para Linux, macOS ou Unix: ``` aws elasticache modify-replication-group \ --replication-group-id authtestgroup \ --auth-token This-is-the-set-token \ --auth-token-update-strategy SET \ --apply-immediately ``` Para Windows: ``` aws elasticache modify-replication-group ^ --replication-group-id authtestgroup ^ --auth-token This-is-the-set-token ^ --auth-token-update-strategy SET ^ --apply-immediately ``` ### Habilitação de autenticação em um cluster existente Para habilitar a autenticação em um servidor Valkey ou Redis OSS existente, chame a operação `ModifyReplicationGroup` da API. Execute `ModifyReplicationGroup` com o parâmetro `--auth-token` como o novo token e o parâmetro `--auth-token-update-strategy` com o valor ROTATE (ALTERNAR). Depois que a modificação ROTATE (ALTERNAR) for concluída, o cluster oferecerá suporte ao token **AUTH** especificado no parâmetro `--auth-token`, além do suporte a conexões sem autenticação. Depois que todos os aplicativos cliente forem atualizados para se autenticar no Valkey ou no Redis OSS com o token AUTH, use a estratégia SET (DEFINIR) para marcar o token AUTH conforme necessário. A habilitação da autenticação só é aceita em servidores Valkey e Redis OSS com criptografia em trânsito (TLS) habilitada. ## Migração do RBAC para o AUTH Se você estiver autenticando usuários com o controle de acesso baseado em função (RBAC) do Valkey ou Redis OSS, conforme descrito em [Regras de controle de acesso com base em função (RBAC)](Clusters.RBAC.md), e desejar migrar para o AUTH, use os seguintes procedimentos. Você pode migrar usando o console ou a CLI. **Para migrar do RBAC para o AUTH usando o console** 1. Faça login no Console de gerenciamento da AWS e abra o ElastiCache console em [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/). 1. Na lista no canto superior direito, escolha a AWS região em que o cluster que você deseja modificar está localizado. 1. No painel de navegação, escolha o mecanismo em execução no cluster que deseja modificar. É exibida uma lista dos clusters do mecanismo escolhido. 1. Na lista de clusters, no cluster que você deseja modificar, escolha seu nome. 1. Para **Actions (Ações)**, escolha **Modify (Modificar)**. A janela **Modificar** é exibida. 1. Em **Controle de acesso**, escolha **Acesso do usuário padrão AUTH do Valkey** ou **Acesso do usuário padrão AUTH do Redis OSS**. 1. Em **Token AUTH do Valkey** ou **Token AUTH do Redis OSS**, defina um novo token. 1. Escolha **Previsualizar alterações** e, na próxima tela, **Modificar**. **Para migrar do RBAC para o AUTH usando o AWS CLI** Use um dos comandos a seguir para configurar um novo token **AUTH** opcional para seu grupo de replicação do Valkey ou Redis OSS. Observe que um token Auth opcional permitirá acesso não autenticado ao grupo de replicação até que o token Auth seja marcado como obrigatório, usando a estratégia de atualização `SET` na etapa a seguir. Para Linux, macOS ou Unix: ``` aws elasticache modify-replication-group \ --replication-group-id test \ --remove-user-groups \ --auth-token This-is-a-sample-token \ --auth-token-update-strategy ROTATE \ --apply-immediately ``` Para Windows: ``` aws elasticache modify-replication-group ^ --replication-group-id test ^ --remove-user-groups ^ --auth-token This-is-a-sample-token ^ --auth-token-update-strategy ROTATE ^ --apply-immediately ``` Depois de executar o comando acima, você pode atualizar seus aplicativos Valkey ou Redis OSS para se autenticar no grupo de ElastiCache replicação usando o token AUTH opcional recém-configurado. Para concluir a rotação do token Auth, use a estratégia de atualização `SET` no comando subsequente abaixo. Isso marcará o token AUTH opcional conforme necessário. Quando a atualização do token Auth for concluída, o status do grupo de replicação será exibido como `ACTIVE` e todas as conexões com esse grupo de replicação exigirão autenticação. Para Linux, macOS ou Unix: ``` aws elasticache modify-replication-group \ --replication-group-id test \ --auth-token This-is-a-sample-token \ --auth-token-update-strategy SET \ --apply-immediately ``` Para Windows: ``` aws elasticache modify-replication-group ^ --replication-group-id test ^ --remove-user-groups ^ --auth-token This-is-a-sample-token ^ --auth-token-update-strategy SET ^ --apply-immediately ``` Para obter mais informações, consulte [Autenticar com o comando AUTH do Valkey e Redis OSS](#auth). **nota** Se você precisar desativar o controle de acesso em um ElastiCache cluster, consulte[Desabilitar o controle de acesso em um cache do ElastiCache Valkey ou Redis OSS](in-transit-encryption-disable.md). # Desabilitar o controle de acesso em um cache do ElastiCache Valkey ou Redis OSS Siga as instruções abaixo para desabilitar o controle de acesso em um cache do Valkey ou Redis OSS habilitado para TLS. Seu cache terá um dos dois tipos diferentes de configurações: acesso de usuário padrão AUTH ou lista de controle de acesso de grupo de usuários (RBAC). Se o cache tiver sido criado com a configuração AUTH, você precisará alterá-lo para a configuração RBAC antes de poder desabilitar o cache por meio da remoção dos grupos de usuários. Se o cache tiver sido criado com a configuração RBAC, você poderá desabilitá-lo diretamente. **Como desabilitar um cache de tecnologia sem servidor do Valkey ou Redis OSS configurado com RBAC** 1. Remova os grupos de usuários para desabilitar o controle de acesso. ``` aws elasticache modify-serverless-cache --serverless-cache-name --remove-user-group ``` 1. (Opcional) Verifique se nenhum grupo de usuários está associado ao cache sem servidor. ``` aws elasticache describe-serverless-caches --serverless-cache-name { "..." "UserGroupId": "" "..." } ``` **Como desabilitar um cache do Valkey ou Redis OSS configurado com um token AUTH** 1. Altere o token AUTH para RBAC e especifique um grupo de usuários a ser adicionado. ``` aws elasticache modify-replication-group --replication-group-id --auth-token-update-strategy DELETE --user-group-ids-to-add ``` 1. Verifique se o token AUTH foi desabilitado e se um grupo de usuários foi adicionado. ``` aws elasticache describe-replication-groups --replication-group-id { "..." "AuthTokenEnabled": false, "UserGroupIds": [ "" ] "..." } ``` 1. Remova os grupos de usuários para desabilitar o controle de acesso. ``` aws elasticache modify-replication-group --replication-group-id --user-group-ids-to-remove { "..." "PendingModifiedValues": { "UserGroups": { "UserGroupIdsToAdd": [], "UserGroupIdsToRemove": [ "" ] } "..." } ``` 1. (Opcional) Verifique se nenhum grupo de usuários está associado ao cluster. O campo `AuthTokenEnabled` também deve ser falso. ``` aws elasticache describe-replication-groups --replication-group-id "AuthTokenEnabled": false ``` **Como desabilitar um cluster do Valkey ou Redis OSS configurado com RBAC** 1. Remova os grupos de usuários para desabilitar o controle de acesso. ``` aws elasticache modify-replication-group --replication-group-id --user-group-ids-to-remove { "..." "PendingModifiedValues": { "UserGroups": { "UserGroupIdsToAdd": [], "UserGroupIdsToRemove": [ "" ] } "..." } ``` 1. (Opcional) Verifique se nenhum grupo de usuários está associado ao cluster. O campo `AuthTokenEnabled` também deve ser falso. ``` aws elasticache describe-replication-groups --replication-group-id "AuthTokenEnabled": false ```