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á.
# Proteção de dados no MemoryDB
O modelo de [responsabilidade AWS compartilhada modelo](https://aws.amazon.com/compliance/shared-responsibility-model/) se aplica à proteção de dados em. Conforme descrito neste modelo, AWS é responsável por proteger a infraestrutura global que executa todos os Nuvem AWS. Você é responsável por manter o controle sobre o conteúdo hospedado nessa infraestrutura. Você também é responsável pelas tarefas de configuração e gerenciamento de segurança dos Serviços da AWS que usa. Para saber mais sobre a privacidade de dados, consulte as [Data Privacy FAQ](https://aws.amazon.com/compliance/data-privacy-faq/). Para saber mais sobre a proteção de dados na Europa, consulte a postagem do blog [AWS Shared Responsibility Model and RGPD](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) no *Blog de segurança da AWS *.
Para fins de proteção de dados, recomendamos que você proteja Conta da AWS as credenciais e configure usuários individuais com Centro de Identidade do AWS IAM ou AWS Identity and Access Management (IAM). Dessa maneira, cada usuário receberá apenas as permissões necessárias para cumprir suas obrigações de trabalho. Recomendamos também que você proteja seus dados das seguintes formas:
+ Use uma autenticação multifator (MFA) com cada conta.
+ Use SSL/TLS para se comunicar com AWS os recursos. Exigimos TLS 1.2 e recomendamos TLS 1.3.
+ Configure a API e o registro de atividades do usuário com AWS CloudTrail. Para obter informações sobre o uso de CloudTrail trilhas para capturar AWS atividades, consulte Como [trabalhar com CloudTrail trilhas](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) no *Guia AWS CloudTrail do usuário*.
+ Use soluções de AWS criptografia, juntamente com todos os controles de segurança padrão Serviços da AWS.
+ Use serviços gerenciados de segurança avançada, como o Amazon Macie, que ajuda a localizar e proteger dados sensíveis armazenados no Amazon S3.
+ Se você precisar de módulos criptográficos validados pelo FIPS 140-3 ao acessar AWS por meio de uma interface de linha de comando ou de uma API, use um endpoint FIPS. Para saber mais sobre os endpoints FIPS disponíveis, consulte [Federal Information Processing Standard (FIPS) 140-3](https://aws.amazon.com/compliance/fips/).
É altamente recomendável que nunca sejam colocadas informações confidenciais ou sensíveis, como endereços de e-mail de clientes, em tags ou campos de formato livre, como um campo **Nome**. Isso inclui quando você trabalha com ou Serviços da AWS usa o console, a API ou AWS SDKs. AWS CLI Quaisquer dados inseridos em tags ou em campos de texto de formato livre usados para nomes podem ser usados para logs de faturamento ou de diagnóstico. Se você fornecer um URL para um servidor externo, é fortemente recomendável que não sejam incluídas informações de credenciais no URL para validar a solicitação nesse servidor.
# Segurança de dados no MemoryDB
Para ajudar a manter seus dados seguros, o MemoryDB e o Amazon EC2 fornecem mecanismos de proteção contra o acesso não autorizado aos seus dados no servidor.
O MemoryDB também fornece atributos de criptografia para dados em clusters:
+ 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 cluster e o aplicativo.
+ A criptografia em repouso criptografa o log de transações e os dados no disco durante as operações de snapshot.
É possível usar também o [Autenticando usuários com listas de controle de acesso () ACLs](clusters.acls.md) para controlar o acesso do usuário aos seus clusters.
**Topics**
+ [Segurança de dados no MemoryDB](encryption.md)
+ [Criptografia em repouso no MemoryDB](at-rest-encryption.md)
+ [Criptografia em trânsito (TLS) do MemoryDB](in-transit-encryption.md)
+ [Autenticando usuários com listas de controle de acesso () ACLs](clusters.acls.md)
+ [Autenticação com o IAM](auth-iam.md)
# Criptografia em repouso no MemoryDB
Para ajudar a manter seus dados seguros, o MemoryDB e o Amazon S3 oferecem diferentes maneiras de restringir o acesso aos dados nos clusters. Para obter mais informações, consulte [MemoryDB e Amazon VPC](vpcs.md) e [Gerenciamento de identidade e acesso no MemoryDB](iam.md).
A criptografia em repouso do MemoryDB está sempre ativada para aumentar a segurança dos dados por meio da criptografia de dados persistentes. Ele criptografa os seguintes aspectos:
+ Dados no log de transações
+ Disco durante operações de sincronização, snapshot e swap
+ Snapshots armazenados no Amazon S3
O MemoryDB oferece criptografia padrão (gerenciada pelo serviço) em repouso, bem como a capacidade de usar suas próprias chaves raiz simétricas gerenciadas pelo cliente no [Key Management Service (KMS) da AWS](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html).
Os dados armazenados em Solid-State Drives (SSDs – Unidades de estado sólido) em clusters habilitados para classificação de dados em níveis sempre são criptografados por padrão.
Para obter informações sobre criptografia em trânsito, consulte [Criptografia em trânsito (TLS) do MemoryDB](in-transit-encryption.md)
**Topics**
+ [Uso de chaves gerenciadas pelo cliente do KMS da AWS](#using-customer-managed-keys-for-memorydb-security)
+ [Consulte também](#at-rest-encryption-see-also)
## Uso de chaves gerenciadas pelo cliente do KMS da AWS
O MemoryDB oferece suporte a chaves raiz simétricas gerenciadas pelo cliente (chave KMS) para criptografia em repouso. Chaves KMS gerenciadas pelo cliente são chaves de criptografia que você cria, detém e gerencia na sua conta da AWS. Para obter mais informações, consulte [Chaves raiz do cliente](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 KMS da AWS antes de poderem ser usadas com o MemoryDB.
Para saber como criar chaves de raiz do KMS da AWS, consulte [Criação de chaves](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) no *Guia do desenvolvedor do serviço de gerenciamento de chaves da AWS*.
O MemoryDB 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*. Não é necessária nenhuma ação do cliente para ativar a integração do MemoryDB com o KMS da AWS.
A chave de condição `kms:ViaService` limita o uso de uma chave do KMS AWS para solicitações provenientes de serviços da AWS especificados. Para usar `kms:ViaService` com o MemoryDB, inclua os dois nomes do ViaService no valor da chave de condição: `memorydb.amazon_region.amazonaws.com`. Para obter mais informações, consulte [kms:ViaService](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-via-service).
Você pode usar o [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) para rastrear as solicitações que o MemoryDB envia para o AWS Key Management Service em seu nome. Todas as chamadas de API para o AWS Key Management Service relacionadas a chaves gerenciadas pelo cliente têm logs do CloudTrail correspondentes. Você também pode ver as concessões que o MemoryDB cria fazendo a chamada de API do KMS [ListGrants](https://docs.aws.amazon.com/kms/latest/APIReference/API_ListGrants.html).
Quando um cluster é criptografado usando uma chave gerenciada pelo cliente, todos os snapshots do cluster são criptografados da seguinte forma:
+ Os snapshots diários automáticos são criptografados usando a chave gerenciada pelo cliente associada ao cluster.
+ O snapshot final criado quando o cluster é excluído também é criptografado usando a chave gerenciada pelo cliente associada ao cluster.
+ Os snapshots criados manualmente são criptografados por padrão para usar a chave KMS associada ao cluster. Você pode substituir escolhendo outra chave gerenciada pelo cliente.
+ A cópia de um snapshot tem como padrão o uso da chave gerenciada pelo cliente associada ao snapshot de origem. Você pode substituir escolhendo outra chave gerenciada pelo cliente.
**nota**
As chaves gerenciadas pelo cliente não podem ser usadas ao exportar snapshots para o bucket do Amazon S3 selecionado. No entanto, todos os snapshots exportados para o Amazon S3 são criptografados usando a [criptografia do lado do servidor](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingServerSideEncryption.html). Você pode optar por copiar o arquivo de snapshot para um novo objeto S3 e criptografar usando uma chave KMS gerenciada pelo cliente, copiar o arquivo para outro bucket S3 configurado com criptografia padrão usando uma chave KMS ou alterar uma opção de criptografia no próprio arquivo.
Você também pode usar chaves gerenciadas pelo cliente para criptografar snapshots criados manualmente que não usam chaves gerenciadas pelo cliente para criptografia. Com essa opção, o arquivo de snapshot armazenado no Amazon S3 é criptografado usando uma chave KMS, mesmo que os dados não sejam criptografados no cluster original.
A restauração a partir de um snapshot permite que você escolha entre as opções de criptografia disponíveis, de forma semelhante às opções de criptografia disponíveis ao criar um novo cluster.
+ Se você excluir a chave ou [desativar](https://docs.aws.amazon.com/kms/latest/developerguide/enabling-keys.html) a chave e [revogar as concessões](https://docs.aws.amazon.com/kms/latest/APIReference/API_RevokeGrant.html) para a chave que usou para criptografar um cluster, o cluster se tornará irrecuperável. Em outras palavras, ele não poderá ser modificado nem recuperado depois de uma falha de hardware.AWS O KMS exclui as chaves raiz somente depois de 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 snapshot para fins de arquivamento.
+ A rotação automática de chaves preserva as propriedades das chaves raiz do KMS da AWS, de modo que a rotação não afeta sua capacidade de acessar os dados do MemoryDB. Os clusters criptografados do MemoryDB não são compatíveis com a rotação manual de chaves, o que envolve a criação de uma nova chave raiz e a atualização de todas as referências à chave antiga. Para saber mais, consulte [Rotação das chaves raiz do cliente](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html) no *Guia do desenvolvedor do Key Management Service daAWS*.
+ A criptografia de um cluster do MemoryDB usando a chave KMS requer uma concessão por cluster. Essa concessão é usada durante toda a vida útil do cluster. Além disso, uma concessão por snapshot é usada durante a criação do snapshot. Essa concessão é suspensa quando o snapshot é criado.
+ Para obter mais informações sobre concessões e limites do KMS da AWS, consulte [Cotas](https://docs.aws.amazon.com/kms/latest/developerguide/limits.html) no *Guia do desenvolvedor do Key Management Service da AWS*.
## Consulte também
+ [Criptografia em trânsito (TLS) do MemoryDB](in-transit-encryption.md)
+ [MemoryDB e Amazon VPC](vpcs.md)
+ [Gerenciamento de identidade e acesso no MemoryDB](iam.md)
# Criptografia em trânsito (TLS) do MemoryDB
Para ajudar a manter seus dados seguros, o MemoryDB e o Amazon EC2 fornecem mecanismos de proteção contra o acesso não autorizado aos seus dados no servidor. Ao fornecer a capacidade de criptografia em trânsito, o MemoryDB oferece uma ferramenta que pode ser usada para ajudar a proteger seus dados quando eles estiverem sendo transferidos de um local para outro. Por exemplo, você pode mover dados de um nó primário para um nó de réplica de leitura em um cluster ou entre o cluster e o aplicativo.
**Topics**
+ [Visão geral da criptografia em trânsito](#in-transit-encryption-overview)
+ [Consulte também](#in-transit-encryption-see-also)
## Visão geral da criptografia em trânsito
A criptografia em trânsito do MemoryDB é um recurso que aumenta a segurança dos dados nos pontos mais vulneráveis: quando estão em trânsito de um local para outro.
A criptografia em trânsito do MemoryDB implementa os seguintes atributos:
+ **Conexões criptografadas**: as conexões do servidor e do cliente são criptografadas por Transport Layer Security (TLS).
+ **Replicação criptografada**: os dados em movimento entre um nó primário e nós de réplica são criptografados.
+ **Autenticação do servidor**: os clientes podem autenticar que estão conectados ao servidor certo.
A partir de 20/07/2023, o TLS 1.2 é a versão mínima compatível para clusters novos e existentes. Use este [link](https://aws.amazon.com/blogs/security/tls-1-2-required-for-aws-endpoints/) para saber mais sobre o TLS 1.2 em AWS.
Para obter mais informações sobre como se conectar aos clusters do MemoryDB, consulte [Conectando-se aos nós do MemoryDB usando redis-cli](getting-started.md#connect-tls).
## Consulte também
+ [Criptografia em repouso no MemoryDB](at-rest-encryption.md)
+ [Autenticação de usuários com listas de controle de acesso (ACLs)](https://docs.aws.amazon.com/memorydb/latest/devguide/clusters.acls.html)
+ [MemoryDB e Amazon VPC](vpcs.md)
+ [Gerenciamento de identidade e acesso no MemoryDB](iam.md)
# Autenticando usuários com listas de controle de acesso () ACLs
Você pode autenticar usuários com listas de controle de acesso (ACLs).
ACLs permitem que você controle o acesso ao cluster agrupando usuários. Essas listas de controle de acesso são projetadas como uma maneira de organizar o acesso aos clusters.
Com ACLs, você cria usuários e atribui a eles permissões específicas usando uma string de acesso, conforme descrito na próxima seção. Você atribui os usuários a listas de controle de acesso alinhadas a uma função específica (administradores, recursos humanos) que, em seguida, são implantadas em um ou mais clusters do MemoryDB. Ao fazer isso, você pode estabelecer limites de segurança entre clientes usando o mesmo cluster ou clusters do MemoryDB e impedir que os clientes acessem os dados uns dos outros.
ACLs são projetados para oferecer suporte à introdução da [ACL](https://valkey.io/docs/topics/acl/) no Redis OSS 6. Quando você usa ACLs com seu cluster MemoryDB, há algumas limitações:
+ Não é possível especificar senhas em uma string de acesso. Você define senhas com [CreateUser](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateUser.html)nossas [UpdateUser](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateUser.html)chamadas.
+ Para direitos de usuário, você passa `on` e `off` como parte da string de acesso. Se nenhum deles for especificado na string de acesso, o usuário é atribuído com `off` e não tem direitos de acesso ao cluster.
+ Você não pode usar comandos proibidos. Se você especificar um comando proibido, será emitida uma exceção. Para obter uma lista desses comandos, consulte [Comandos restritos](restrictedcommands.md).
+ Não é possível usar o comando `reset` como parte de uma string de acesso. Você especifica as senhas com parâmetros de API e o MemoryDB gerencia as 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 da ACL aplicadas a cada usuário. O MemoryDB oferece suporte ao comando `ACL LIST`, mas não inclui suporte para hashes de senha como o Redis OSS faz. Com o MemoryDB, você pode usar a [DescribeUsers](https://docs.aws.amazon.com/memorydb/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/memorydb/latest/APIReference/API_DescribeUsers.html)não recupera a senha do usuário.
Outros comandos somente de leitura compatíveis com o MemoryDB incluem [ACL WHOAMI](https://valkey.io/commands/acl-whoami), [ACL USERS](https://valkey.io/commands/acl-users) e [ACL CAT](https://valkey.io/commands/acl-cat). O MemoryDB não oferece suporte a nenhum outro comando ACL baseado em gravação.
O uso ACLs com o MemoryDB é descrito em mais detalhes a seguir.
**Topics**
+ [Especificação de permissões usando uma string de acesso](#access-string)
+ [Recursos de pesquisa vetorial](#access-vss)
+ [Aplicação ACLs a um cluster para MemoryDB](#rbac-using)
## Especificação de permissões usando uma string de acesso
Para especificar permissões para um cluster MemoryDB, você cria uma string de acesso e a atribui a um usuário usando o AWS CLI ou. Console 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. As 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.
+ `&*`: o acesso é dado a todos os canais pubsub.
+ `+@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 listas de controle de acesso com o console e a CLI](#users-management).
Se você estiver migrando uma workload existente para o MemoryDB, poderá recuperar a string de acesso chamando `ACL LIST`, excluindo o usuário e quaisquer hashes de senha.
## Recursos de pesquisa vetorial
Para a [Pesquisa vetorial](vector-search.md), todos os comandos de pesquisa pertencem à categoria `@search`, e as categorias `@read`, `@write`, `@fast` e `@slow` existentes são atualizadas para incluir comandos de pesquisa. Se um usuário não tiver acesso a uma categoria, ele não terá acesso aos comandos dentro dela. Por exemplo, se ele não tiver acesso a `@search`, não poderá executar comandos relacionados a pesquisas.
A tabela a seguir indica o mapeamento de comandos de pesquisa as categorias apropriadas.
| Comandos do VSS | @read | @write | @fast | @slow |
| --- | --- | --- | --- | --- |
| FT.CREATE | | S | S | |
| FT.DROPINDEX | | S | S | |
| FT.LIST | S | | | S |
| FT.INFO | S | | S | |
| FT.SEARCH | S | | | S |
| FT.AGGREGATE | S | | | S |
| FT.PROFILE | S | | | S |
| FT.ALIASADD | | S | S | |
| FT.ALIASDEL | | S | S | |
| FT.ALIASUPDATE | | S | S | |
| FT.\$1ALIASLIST | S | | | S |
| FT.EXPLAIN | S | | S | |
| FT.EXPLAINCLI | S | | S | |
| FT.CONFIG | S | | S | |
## Aplicação ACLs a um cluster para MemoryDB
Para usar o MemoryDB ACLs, siga as seguintes etapas:
1. Crie um ou mais usuários.
1. Crie uma ACL e adicione usuários à lista.
1. Atribua a ACL a um cluster.
Essas etapas estão descritas em detalhes a seguir.
**Topics**
+ [Criação de usuários e listas de controle de acesso com o console e a CLI](#users-management)
+ [Gerenciamento de listas de controle de acesso com o console e a CLI](#user-groups)
+ [Atribuição de listas de controle de acesso a clusters](#users-groups-to-clusterss)
### Criação de usuários e listas de controle de acesso com o console e a CLI
As informações do usuário para ACLs usuários são um 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 nome é exclusivo para o usuário e é passado para o mecanismo.
Verifique se as permissões do usuário fornecidas fazem sentido com a finalidade pretendida da ACL. Por exemplo, se você criar uma ACL chamada `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 uma ACL de `e-commerce`, você pode definir suas strings de acesso para somente leitura.
O MemoryDB configura automaticamente um usuário padrão por conta com um nome de usuário `"default"`. Ele não será associado a nenhum cluster, a menos que seja explicitamente adicionado a uma ACL. 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.
Uma ACL imutável de “acesso aberto” será criada para cada conta que contém o usuário padrão. Essa é a única ACL da qual o usuário padrão pode se tornar membro. Ao criar um cluster, você deve selecionar uma ACL para associar ao cluster. Embora você tenha a opção de aplicar a ACL de “acesso aberto” com o usuário padrão, é altamente recomendável criar uma ACL com usuários que tenham permissões restritas às suas necessidades comerciais.
Os clusters que não têm o TLS ativado devem usar a ACL de “acesso aberto” para fornecer uma autenticação aberta.
ACLs pode ser criado sem usuários. Uma ACL vazia não teria acesso a um cluster e só pode ser associada a clusters habilitados para TLS.
Ao criar um usuário, você pode configurar até duas senhas. Quando você modifica uma senha, todas as conexões existentes para os clusters são mantidas.
Em particular, esteja ciente dessas restrições de senha de usuário ao usar ACLs o MemoryDB:
+ 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
##### Criação de usuários (console)
**Para criar usuários no console**
1. Faça login no Console de gerenciamento da AWS e abra o console do MemoryDB em. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. No painel de navegação à esquerda, escolha **Usuários**.
1. Escolha **Criar usuário**
1. Na página **Criar usuário**, insira um **Nome**.
As restrições de nomenclatura de cluster são as seguintes:
+ Devem conter 1 a 40 caracteres alfanuméricos ou hifens.
+ Deve começar com uma letra.
+ Não podem conter dois hifens consecutivos.
+ Não podem terminar com um hífen.
1. Em **Senhas**, você pode inserir até duas senhas.
1. Em **String de acesso**, insira uma cadeia de caracteres de acesso. A string de acesso define o nível de permissão para quais chaves e comandos o usuário é permitido.
1. Para **tags**, você pode, opcionalmente, aplicar tags para pesquisar e filtrar seus usuários ou monitorar seus AWS custos.
1. Escolha **Criar**.
##### Criando um usuário usando o AWS CLI
**Para criar um usuário usando a CLI**
+ Use o comando [create-user](https://docs.aws.amazon.com/cli/latest/reference/memorydb/create-user.html) para criar um usuário.
Para Linux, macOS ou Unix:
```
aws memorydb create-user \
--user-name user-name-1 \
--access-string "~objects:* ~items:* ~public:*" \
--authentication-mode \
Passwords="abc",Type=password
```
Para Windows:
```
aws memorydb create-user ^
--user-name user-name-1 ^
--access-string "~objects:* ~items:* ~public:*" ^
--authentication-mode \
Passwords="abc",Type=password
```
##### Modificação de um usuário (console)
**Para modificar usuários no console**
1. Faça login no Console de gerenciamento da AWS e abra o console do MemoryDB em. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. No painel de navegação à esquerda, escolha **Usuários**.
1. Escolha o botão de opção ao lado do usuário que você deseja modificar e escolha **Ações**->**Modificar**
1. Se você quiser modificar uma senha, escolha o botão de opção **Modificar senhas**. Observe que, se você tiver duas senhas, deverá inserir as duas ao modificar uma delas.
1. Se você estiver atualizando a string de acesso, insira a nova.
1. Escolha **Modificar**.
##### Modificando um usuário usando AWS CLI
**Para modificar um usuário usando a CLI**
1. Use o comando [update-user](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-user.html) para modificar um usuário.
1. Quando um usuário é modificado, as listas de controle de acesso associadas ao usuário são atualizadas, juntamente com quaisquer clusters associados à ACL. Todas as conexões existentes são mantidas. Veja os exemplos a seguir.
Para Linux, macOS ou Unix:
```
aws memorydb update-user \
--user-name user-name-1 \
--access-string "~objects:* ~items:* ~public:*"
```
Para Windows:
```
aws memorydb update-user ^
--user-name user-name-1 ^
--access-string "~objects:* ~items:* ~public:*"
```
##### Visualizar detalhes do usuário (console)
**Para visualizar os detalhes do usuário no console**
1. Faça login no Console de gerenciamento da AWS e abra o console do MemoryDB em. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. No painel de navegação à esquerda, escolha **Usuários**.
1. Escolha o usuário em **Nome de usuário** ou use a caixa de pesquisa para localizar o usuário.
1. Em **Configurações do usuário**, você pode revisar a string de acesso, a contagem de senhas, o status e o nome do recurso da Amazon (ARN) do usuário.
1. Em **Listas de controle de acesso (ACL)**, você pode revisar a ACL à qual o usuário pertence.
1. Em **Tags**, você pode revisar todas as tags associadas ao usuário.
##### Visualizando detalhes do usuário usando o AWS CLI
Use o comando [describe-users](https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-users.html) para ver os detalhes de um usuário.
```
aws memorydb describe-users \
--user-name my-user-name
```
##### Exclusão de um usuário (Console)
**Para excluir usuários no console**
1. Faça login no Console de gerenciamento da AWS e abra o console do MemoryDB em. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. No painel de navegação à esquerda, escolha **Usuários**.
1. Escolha o botão de opção ao lado do usuário que você deseja modificar e escolha **Ações**->**Excluir**
1. Para confirmar, digite `delete` na caixa de texto de confirmação e, em seguida, selecione **Excluir**.
1. Para cancelar, escolha **Cancelar**.
##### Excluindo um usuário usando o AWS CLI
**Para excluir um usuário usando a CLI**
+ Use o comando [delete-user](https://docs.aws.amazon.com/cli/latest/reference/memorydb/delete-user.html) para excluir um usuário.
A conta é excluída e removida de todas as listas de controle de acesso às quais pertence. Veja um exemplo do a seguir:
Para Linux, macOS ou Unix:
```
aws memorydb delete-user \
--user-name user-name-2
```
Para Windows:
```
aws memorydb delete-user ^
--user-name user-name-2
```
### Gerenciamento de listas de controle de acesso com o console e a CLI
Você pode criar listas de controle de acesso para organizar e controlar o acesso de usuários a um ou mais clusters, conforme mostrado a seguir.
Use o procedimento a seguir para gerenciar as listas de controle de acesso usando o console.
#### Criação de uma lista de controle de acesso (ACL) (console)
**Como criar uma Lista de controle de acesso usando o console**
1. Faça login no Console de gerenciamento da AWS e abra o console do MemoryDB em. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. No painel de navegação à esquerda, escolha **Listas de controle de acesso (ACL)**.
1. Escolha **Criar ACL**.
1. Na página **Criar lista de controle de acesso (ACL)**, insira o nome da ACL.
As restrições de nomenclatura de cluster são as seguintes:
+ Devem conter 1 a 40 caracteres alfanuméricos ou hifens.
+ Deve começar com uma letra.
+ Não podem conter dois hifens consecutivos.
+ Não podem terminar com um hífen.
1. Em **Usuários selecionados**, siga um destes procedimentos:
1. Crie um novo usuário selecionando **Criar usuário**
1. Adicione usuários escolhendo **Gerenciar** e, em seguida, selecionando usuários na caixa de diálogo **Gerenciar usuários**, depois selecione **Escolher**.
1. Para **tags**, você pode, opcionalmente, aplicar tags para pesquisar e filtrar ACLs ou rastrear seus AWS custos.
1. Escolha **Criar**.
#### Criando uma Lista de Controle de Acesso (ACL) usando o AWS CLI
Use os procedimentos a seguir para criar uma lista de controle de acesso usando a CLI.
**Para criar uma nova ACL e adicionar um usuário usando a CLI**
+ Use o comando [create-acl](https://docs.aws.amazon.com/cli/latest/reference/memorydb/create-acl.html) para criar uma ACL.
Para Linux, macOS ou Unix:
```
aws memorydb create-acl \
--acl-name "new-acl-1" \
--user-names "user-name-1" "user-name-2"
```
Para Windows:
```
aws memorydb create-acl ^
--acl-name "new-acl-1" ^
--user-names "user-name-1" "user-name-2"
```
#### Modificação de uma lista de controle de acesso (ACL) (console)
**Para modificar uma lista de controle de acesso usando o console**
1. Faça login no Console de gerenciamento da AWS e abra o console do MemoryDB em. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. No painel de navegação à esquerda, escolha **Listas de controle de acesso (ACL)**.
1. Escolha a ACL que você deseja modificar e escolha **Modificar**
1. Na página **Modificar**, em **Usuários selecionados**, faça o seguinte:
1. Crie um novo usuário escolhendo **Criar usuário** para adicionar à ACL.
1. Adicione ou remova usuários escolhendo **Gerenciar** e, em seguida, selecionando ou desmarcando usuários na caixa de diálogo **Gerenciar usuários** e depois, selecionando **Escolher**.
1. Na página **Criar lista de controle de acesso (ACL)**, insira o nome da ACL.
As restrições de nomenclatura de cluster são as seguintes:
+ Devem conter 1 a 40 caracteres alfanuméricos ou hifens.
+ Deve começar com uma letra.
+ Não podem conter dois hifens consecutivos.
+ Não podem terminar com um hífen.
1. Em **Usuários selecionados**, siga um destes procedimentos:
1. Crie um novo usuário selecionando **Criar usuário**
1. Adicione usuários escolhendo **Gerenciar** e, em seguida, selecionando usuários na caixa de diálogo **Gerenciar usuários**, depois selecione **Escolher**.
1. Escolha **Modificar** para salvar suas alterações ou **Cancelar** para descartá-las.
#### Modificando uma Lista de Controle de Acesso (ACL) usando o AWS CLI
**Para modificar uma ACL adicionando novos usuários ou removendo membros atuais usando a CLI**
+ Use o comando [update-acl](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-acl.html) para modificar uma ACL.
Para Linux, macOS ou Unix:
```
aws memorydb update-acl --acl-name new-acl-1 \
--user-names-to-add user-name-3 \
--user-names-to-remove user-name-2
```
Para Windows:
```
aws memorydb update-acl --acl-name new-acl-1 ^
--user-names-to-add user-name-3 ^
--user-names-to-remove user-name-2
```
**nota**
Quaisquer conexões abertas pertencentes a um usuário removido de uma ACL são encerradas por este comando.
#### Visualização de detalhes da Lista de controle de acesso (ACL) (console)
**Para ver os detalhes da ACL no console**
1. Faça login no Console de gerenciamento da AWS e abra o console do MemoryDB em. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. No painel de navegação à esquerda, escolha **Listas de controle de acesso (ACL)**.
1. Escolha a ACL sob **nome da ACL** ou use a caixa de pesquisa para localizar a ACL.
1. Em **Usuários**, você pode revisar a lista de usuários associados à ACL.
1. Em **Clusters associados**, você pode revisar o cluster ao qual a ACL pertence.
1. Em **Tags**, você pode revisar todas as tags associadas à ACL.
#### Exibindo listas de controle de acesso (ACL) usando o AWS CLI
Use o comando [describe-acls](https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-acls.html) para ver detalhes de uma ACL.
```
aws memorydb describe-acls \
--acl-name test-group
```
#### Excluindo uma Lista de controle de acesso (ACL) (console)
**Para excluir uma lista de controle de acesso usando o console**
1. Faça login no Console de gerenciamento da AWS e abra o console do MemoryDB em. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. No painel de navegação à esquerda, escolha **Listas de controle de acesso (ACL)**.
1. Escolha a ACL que você deseja modificar e, em seguida, escolha **Excluir**
1. Na página **Excluir**, insira `delete` na caixa de confirmação e escolha **Excluir**; ou **Cancelar** para evitar a exclusão da ACL.
A própria ACL, não os usuários pertencentes ao grupo, é excluída.
#### Excluindo uma Lista de Controle de Acesso (ACL) usando o AWS CLI
**Para excluir uma ACL usando a CLI**
+ Use o comando [delete-acl](https://docs.aws.amazon.com/cli/latest/reference/memorydb/delete-acl.html) para excluir uma ACL.
Para Linux, macOS ou Unix:
```
aws memorydb delete-acl /
--acl-name
```
Para Windows:
```
aws memorydb delete-acl ^
--acl-name
```
Os exemplos anteriores retornam a seguinte resposta.
```
aws memorydb delete-acl --acl-name "new-acl-1"
{
"ACLName": "new-acl-1",
"Status": "deleting",
"EngineVersion": "6.2",
"UserNames": [
"user-name-1",
"user-name-3"
],
"clusters": [],
"ARN":"arn:aws:memorydb:us-east-1:493071037918:acl/new-acl-1"
}
```
### Atribuição de listas de controle de acesso a clusters
Depois de criar uma ACL e adicionar usuários, a etapa final da implementação ACLs é atribuir a ACL a um cluster.
#### Atribuindo listas de controle de acesso a clusters usando o console
Para adicionar uma ACL a um cluster usando o Console de gerenciamento da AWS, consulte[Criação de um cluster do MemoryDB](getting-started.md#clusters.create).
#### Atribuindo listas de controle de acesso a clusters usando o AWS CLI
A AWS CLI operação a seguir cria um cluster com a criptografia em trânsito (TLS) ativada e o **acl-name** parâmetro com o valor`my-acl-name`. Substitua o grupo de sub-redes `subnet-group` por um grupo de sub-redes que exista.
**Principais parâmetros**
+ **--engine-version**: deve ser 6.2.
+ **--tls-enabled**: usado para autenticação e para associar uma ACL.
+ **--acl-name**: esse valor fornece listas de controle de acesso compostas por usuários com permissões de acesso especificadas para o cluster.
Para Linux, macOS ou Unix:
```
aws memorydb create-cluster \
--cluster-name "new-cluster" \
--description "new-cluster" \
--engine-version "6.2" \
--node-type db.r6g.large \
--tls-enabled \
--acl-name "new-acl-1" \
--subnet-group-name "subnet-group"
```
Para Windows:
```
aws memorydb create-cluster ^
--cluster-name "new-cluster" ^
--cluster-description "new-cluster" ^
--engine-version "6.2" ^
--node-type db.r6g.large ^
--tls-enabled ^
--acl-name "new-acl-1" ^
--subnet-group-name "subnet-group"
```
A AWS CLI operação a seguir modifica um cluster com a criptografia em trânsito (TLS) ativada e o **acl-name** parâmetro com o valor. `new-acl-2`
Para Linux, macOS ou Unix:
```
aws memorydb update-cluster \
--cluster-name cluster-1 \
--acl-name "new-acl-2"
```
Para Windows:
```
aws memorydb update-cluster ^
--cluster-name cluster-1 ^
--acl-name "new-acl-2"
```
# 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 do IAM, você pode autenticar uma conexão com o MemoryDB usando identidades AWS do IAM, quando seu cluster 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. Com a autenticação do IAM, é possível configurar o controle de acesso refinado para cada cluster e usuário individual do MemoryDB e seguir os princípios de permissões de privilégio mínimo. A autenticação do IAM para MemoryDB fornece um token de autenticação do IAM de curta duração em vez de uma senha de usuário do MemoryDB de longa duração no comando `AUTH` ou `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. Você também pode conceder acesso aos usuários de seus provedores de identidade federados diretamente aos clusters do MemoryDB.
Para usar o AWS IAM com o MemoryDB, primeiro você precisa criar um usuário do MemoryDB com o modo de autenticação definido como IAM e, em seguida, criar ou reutilizar uma identidade do IAM. A identidade do IAM precisa de uma política associada para conceder a ação `memorydb:Connect` ao cluster do MemoryDB e ao usuário do MemoryDB. 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 nó do cluster do MemoryDB. Um cliente com suporte para provedor de credenciais pode gerar automaticamente as credenciais temporárias para cada nova conexão. O MemoryDB executará a autenticação do IAM para solicitações de conexão de usuários do MemoryDB habilitados para o 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 ao usar o mecanismo Valkey ou Redis OSS versão 7.0 ou posterior.
+ O token de autenticação do IAM é válido por 15 minutos. Para conexões de longa duração, recomendamos usar um cliente do Redis OSS que ofereça suporte a uma interface de provedor de credenciais.
+ Uma conexão autenticada pelo IAM com o MemoryDB 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 oferece suporte a todas as chaves de contexto de condição global. 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 cluster
```
aws memorydb create-cluster \
--cluster-name cluster-01 \
--description "MemoryDB IAM auth application"
--node-type db.r6g.large \
--engine-version 7.0 \
--acl-name open-access
```
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" : [
"memorydb:connect"
],
"Resource" : [
"arn:aws:memorydb:us-east-1:123456789012:cluster/cluster-01",
"arn:aws:memorydb:us-east-1:123456789012:user/iam-user-01"
]
}
]
}
```
------
1. Criar um perfil do IAM.
```
aws iam create-role \
--role-name "memorydb-iam-auth-app" \
--assume-role-policy-document file://trust-policy.json
```
1. Crie a política do IAM.
```
aws iam create-policy \
--policy-name "memorydb-allow-all" \
--policy-document file://policy.json
```
1. Anexe a política do IAM à função.
```
aws iam attach-role-policy \
--role-name "memorydb-iam-auth-app" \
--policy-arn "arn:aws:iam::123456789012:policy/memorydb-allow-all"
```
1. Crie um novo usuário habilitado para o IAM.
```
aws memorydb create-user \
--user-name iam-user-01 \
--authentication-mode Type=iam \
--access-string "on ~* +@all"
```
1. Crie uma ACL e inclua o usuário.
```
aws memorydb create-acl \
--acl-name iam-acl-01 \
--user-names iam-user-01
aws memorydb update-cluster \
--cluster-name cluster-01 \
--acl-name iam-acl-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, forneça o token de autenticação do IAM como senha ao se conectar a um cluster do MemoryDB, conforme mostrado no exemplo abaixo.
```
String userName = "insert user name"
String clusterName = "insert cluster name"
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 MemoryDB.
IAMAuthTokenRequest iamAuthTokenRequest = new IAMAuthTokenRequest(userName, clusterName, region);
String iamAuthToken = iamAuthTokenRequest.toSignedRequestUri(awsCredentialsProvider.getCredentials());
// Construct URL with IAM Auth credentials provider
RedisURI redisURI = RedisURI.builder()
.withHost(host)
.withPort(port)
.withSsl(ssl)
.withAuthentication(userName, iamAuthToken)
.build();
// Create a new Lettuce client
RedisClusterClient client = RedisClusterClient.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 ACTION_NAME = "connect";
private static final String SERVICE_NAME = "memorydb";
private static final long TOKEN_EXPIRY_SECONDS = 900;
private final String userName;
private final String clusterName;
private final String region;
public IAMAuthTokenRequest(String userName, String clusterName, String region) {
this.userName = userName;
this.clusterName = clusterName;
this.region = region;
}
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(userName));
return request;
}
private URI getRequestUri() {
return URI.create(String.format("%s%s/", REQUEST_PROTOCOL, clusterName));
}
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 no MemoryDB usando o provedor de credenciais de autenticação do IAM.
```
String userName = "insert user name"
String clusterName = "insert cluster name"
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 MemoryDB.
IAMAuthTokenRequest iamAuthTokenRequest = new IAMAuthTokenRequest(userName, clusterName, region);
// Create a credentials provider using IAM credentials.
RedisCredentialsProvider redisCredentialsProvider = new RedisIAMAuthCredentialsProvider(
userName, iamAuthTokenRequest, awsCredentialsProvider);
// Construct URL with IAM Auth credentials provider
RedisURI redisURI = RedisURI.builder()
.withHost(host)
.withPort(port)
.withSsl(ssl)
.withAuthentication(redisCredentialsProvider)
.build();
// Create a new Lettuce cluster client
RedisClusterClient client = RedisClusterClient.create(redisURI);
client.connect();
```
Abaixo está um exemplo de um cliente de cluster Lettuce que envolve um provedor de credenciais para gerar automaticamente credenciais temporárias quando necessário. IAMAuth TokenRequest
```
public class RedisIAMAuthCredentialsProvider implements RedisCredentialsProvider {
private static final long TOKEN_EXPIRY_SECONDS = 900;
private final AWSCredentialsProvider awsCredentialsProvider;
private final String userName;
private final IAMAuthTokenRequest iamAuthTokenRequest;
private final Supplier iamAuthTokenSupplier;
public RedisIAMAuthCredentialsProvider(String userName,
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(userName, iamAuthTokenSupplier.get()));
}
private String getIamAuthToken() {
return iamAuthTokenRequest.toSignedRequestUri(awsCredentialsProvider.getCredentials());
}
```