# Segurança no Amazon Aurora
A segurança na nuvem na AWS é a nossa maior prioridade. Como cliente da AWS, você se beneficiará de um data center e de uma arquitetura de rede criados para atender aos requisitos das empresas com as maiores exigências de segurança.
A segurança é uma responsabilidade compartilhada entre a AWS e você. O [modelo de responsabilidade compartilhada](https://aws.amazon.com/compliance/shared-responsibility-model/) descreve isto como segurança *da* nuvem e segurança *na* nuvem:
+ **Segurança da nuvem:** a AWS é responsável pela proteção da infraestrutura que executa produtos da AWS na Nuvem AWS. A AWS também fornece serviços que podem ser usados com segurança. Auditores de terceiros testam e verificam regularmente a eficácia da nossa segurança como parte dos [programas de conformidade da AWS](https://aws.amazon.com/compliance/programs/). Para saber mais sobre os programas de compatibilidade que se aplicam ao Amazon Aurora (Aurora), consulte [Serviços da AWS no escopo pelo programa de conformidade](https://aws.amazon.com/compliance/services-in-scope/).
+ **Segurança na nuvem**: sua responsabilidade é determinada pelo serviço da AWS que você usa. Você também é responsável por outros fatores, inclusive a confidencialidade dos dados, os requisitos da organização, as leis e as regulamentações vigentes.
Essa documentação ajuda a entender como aplicar o Modelo de Responsabilidade Compartilhada ao usar o Amazon Aurora. Os tópicos a seguir mostram como configurar o Amazon Aurora para atender aos seus objetivos de segurança e conformidade. Saiba também como usar outros serviços da AWS que ajudam a monitorar e proteger os recursos do Amazon Aurora.
Você pode gerenciar o acesso a seus recursos do Amazon Aurora e a seus bancos de dados em um cluster de banco de dados. O método usado para gerenciar o acesso depende do tipo de tarefa que o usuário precisa realizar com o Amazon Aurora:
+ Execute o cluster de banco de dados em uma nuvem privada virtual (VPC) baseada no serviço da Amazon VPC para obter o maior controle possível de acesso à rede. Para ter mais informações sobre como criar um cluster de banco de dados em uma VPC, consulte [Amazon VPC e Amazon Aurora](USER_VPC.md).
+ Use políticas do AWS Identity and Access Management (IAM) para atribuir permissões que determinam quem tem permissão para gerenciar os recursos do Amazon Aurora. Por exemplo, você pode usar o IAM para determinar quem tem permissão para criar, descrever, modificar e excluir clusters de banco de dados, marcar recursos ou modificar grupos de segurança.
Para examinar exemplos de política do IAM, consulte [Exemplos de políticas baseadas em identidade do Amazon Aurora](security_iam_id-based-policy-examples.md).
+ Use grupos de segurança para controlar quais endereços IP ou instâncias do Amazon EC2 podem se conectar aos seus bancos de dados em um cluster de banco de dados. Quando você cria um cluster de banco de dados, seu firewall impede qualquer acesso ao banco de dados, exceto por meio de regras especificadas por um grupo de segurança associado.
+ Use conexões Secure Socket Layer (SSL) ou Transport Layer Security (TLS) com clusters de banco de dados que executam o Aurora MySQL ou o Aurora PostgreSQL. Para ter mais informações sobre como usar o SSL/TLS com um cluster de banco de dados, consulte [Usar SSL/TLS para criptografar uma conexão com um cluster de banco de dados](UsingWithRDS.SSL.md).
+ Use a criptografia do Amazon Aurora para proteger seus clusters de banco de dados e snapshots em repouso. A criptografia do Amazon Aurora usa o algoritmo de criptografia AES-256 padrão do setor para criptografar seus dados no servidor que hospeda o cluster de banco de dados. Para ter mais informações, consulte [Criptografar recursos do Amazon Aurora](Overview.Encryption.md) .
+ Use os recursos de segurança do seu mecanismo de banco de dados para controlar quem pode fazer login nos bancos de dados em um cluster de banco de dados. Esses recursos funcionam como se o banco de dados estivesse em sua rede local.
Para ter informações sobre segurança com o Aurora MySQL, consulte [Segurança com o Amazon Aurora MySQL](AuroraMySQL.Security.md). Para ter informações sobre segurança com o Aurora PostgreSQL, consulte [Segurança com o Amazon Aurora PostgreSQL](AuroraPostgreSQL.Security.md).
O Aurora faz parte do serviço de banco de dados gerenciado Amazon Relational Database Service (Amazon RDS). O Amazon RDS é um serviço da Web que facilita a configuração, operação e escala de um banco de dados relacional na nuvem. Se você não estiver familiarizado com o Amazon RDS, consulte o [https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html).
O Aurora inclui um subsistema de armazenamento de alta performance. Seus mecanismos de banco de dados compatíveis com o MySQL e o PostgreSQL são personalizados para tirar proveito do rápido armazenamento distribuído. O Aurora também automatiza e padroniza a clusterização e a replicação de bancos de dados que, normalmente, são os aspectos mais desafiantes da configuração e da administração de bancos de dados.
Tanto no Amazon RDS como no Aurora, você pode acessar a API do RDS programaticamente, além de usar a AWS CLI para acessar interativamente a API do RDS. Algumas operações da API do RDS e comandos da AWS CLI se aplicam tanto ao Amazon RDS como ao Aurora, enquanto outras se aplicam ao Amazon RDS ou ao Aurora. Para obter informações sobre as operações da API do RDS, consulte [Referência de API do Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/Welcome.html). Para obter mais informações sobre a AWS CLI, consulte a [Referência da AWS Command Line Interface para o Amazon RDS](https://docs.aws.amazon.com/cli/latest/reference/rds/index.html).
**nota**
Basta configurar a segurança para os casos de uso. Não é necessário configurar o acesso de segurança para os processos que o Amazon Aurora gerencia. Isso inclui a criação de backups, o failover automático e outros processos.
Para ter mais informações sobre como gerenciar o acesso a recursos do Amazon Aurora e os bancos de dados de um cluster de banco de dados, consulte os tópicos a seguir.
**Topics**
+ [Autenticação de banco de dados com o Amazon Aurora](database-authentication.md)
+ [Gerenciamento de senhas com Amazon Aurora e AWS Secrets Manager](rds-secrets-manager.md)
+ [Proteção de dados no Amazon RDS](DataDurability.md)
+ [Gerenciamento de identidade e acesso no Amazon Aurora](UsingWithRDS.IAM.md)
+ [Registrar em log e monitorar no Amazon Aurora](Overview.LoggingAndMonitoring.md)
+ [Validação de conformidade do Amazon Aurora](RDS-compliance.md)
+ [Resiliência no Amazon Aurora](disaster-recovery-resiliency.md)
+ [Segurança da infraestrutura no Amazon Aurora](infrastructure-security.md)
+ [API do Amazon RDS e endpoints da VPC de interface (AWS PrivateLink)](vpc-interface-endpoints.md)
+ [Práticas recomendadas de segurança do Amazon Aurora](CHAP_BestPractices.Security.md)
+ [Controlar acesso com grupos de segurança](Overview.RDSSecurityGroups.md)
+ [Privilégios da conta de usuário mestre](UsingWithRDS.MasterAccounts.md)
+ [Usar funções vinculadas ao serviço do Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md)
+ [Amazon VPC e Amazon Aurora](USER_VPC.md)
# Autenticação de banco de dados com o Amazon Aurora
O Amazon Aurora permite autenticar usuários do banco de dados de várias maneiras.
A autenticação por senha está disponível por padrão para todos os clusters de banco de dados. No Aurora MySQL e no Aurora PostgreSQL, você também pode adicionar a autenticação de banco de dados do IAM e a autenticação Kerberos (uma ou ambas) para o mesmo cluster de banco de dados.
As autenticações de banco de dados do IAM, do Kerberos e por senha usam diferentes métodos de autenticação no banco de dados. Portanto, um usuário específico pode fazer login em um banco de dados usando apenas um método de autenticação.
No PostgreSQL, use apenas uma das seguintes configurações de função para um usuário de um banco de dados específico:
+ Para usar a autenticação de banco de dados do IAM, atribua a função `rds_iam` ao usuário.
+ Para usar a autenticação do Kerberos, atribua a função `rds_ad` ao usuário.
+ Para usar a autenticação por senha, não atribua as funções `rds_iam` ou `rds_ad` ao usuário.
Não atribua ambas as funções `rds_iam` e `rds_ad` a um usuário de um banco de dados PostgreSQL direta ou indiretamente por acesso de concessão aninhado. Se a função `rds_iam` for adicionada ao usuário mestre, a autenticação do IAM terá precedência sobre a autenticação por senha, então o usuário mestre terá que fazer login como um usuário do IAM.
**Importante**
É altamente recomendável não usar o usuário mestre diretamente nas aplicações. Em vez disso, siga as práticas recomendadas de usar um usuário do banco de dados criado com os privilégios mínimos obrigatórios para a aplicação.
**Topics**
+ [Autenticação com senha](#password-authentication)
+ [Autenticação do banco de dados do IAM](#iam-database-authentication)
+ [Autenticação de Kerberos](#kerberos-authentication)
## Autenticação com senha
Com a *autenticação com senha,* seu banco de dados executa toda a administração de contas de usuário. Crie usuários com instruções SQL, como `CREATE USER`, usando a cláusula apropriada exigida pelo mecanismo de banco de dados para especificar senhas. Por exemplo, no MySQL, a instrução é `CREATE USER` *name* `IDENTIFIED BY` *password*, enquanto, no PostgreSQL, ela é `CREATE USER` *name* `WITH PASSWORD` *password*.
Com a autenticação com senha, seu banco de dados controla e autentica contas de usuário. Se um mecanismo de banco de dados tiver recursos de gerenciamento de senhas fortes, ele poderá aumentar a segurança. A autenticação de banco de dados pode ser mais fácil de administrar usando autenticação com senha quando você tem pequenas comunidades de usuários. Como as senhas de texto não criptografado são geradas nesse caso, a integração com o AWS Secrets Manager pode aumentar a segurança.
Para ter informações sobre como usar o Secrets Manager com o Amazon Aurora, consulte [Creating a basic secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_create-basic-secret.html) e [Rotating secrets for supported Amazon RDS databases](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets-rds.html) no *Guia do usuário do AWS Secrets Manager*. Para obter informações sobre como recuperar os segredos de forma programática nas aplicações personalizadas, consulte [Recuperar o valor do segredo](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_retrieve-secret.html) no *Guia do usuário do AWS Secrets Manager*.
## Autenticação do banco de dados do IAM
Você pode se autenticar no cluster de banco de dados usando a autenticação de banco de dados do AWS Identity and Access Management (IAM). Com esse método de autenticação, você não precisa usar uma senha ao conectar-se a um cluster de banco de dados. Em vez disso, você usa um token de autenticação.
Para ter mais informações sobre autenticação de banco de dados do IAM, incluindo informações sobre disponibilidade de mecanismos de banco de dados específicos, consulte [Autenticação do banco de dados do IAM](UsingWithRDS.IAMDBAuth.md).
## Autenticação de Kerberos
O Amazon Aurora oferece suporte à autenticação externa de usuários de banco de dados usando o Kerberos e o Microsoft Active Directory. O Kerberos é um protocolo de autenticação de rede que usa tíquetes e criptografia de chave simétrica para eliminar a necessidade de transmitir senhas pela rede. O Kerberos foi integrado ao Active Directory e foi projetado para autenticar usuários em recursos de rede, como bancos de dados.
O suporte do Amazon Aurora ao Kerberos e ao Active Directory oferece os benefícios de autenticação única e autenticação centralizada dos usuários do banco de dados. Você pode manter suas credenciais de usuário no Active Directory. O Active Directory oferece um lugar centralizado para armazenar e gerenciar credenciais para vários clusters de banco de dados.
Para usar as credenciais do Active Directory autogerenciado, é necessário configurar uma relação de confiança com o Directory Service para Microsoft Active Directory ao qual o cluster de banco de dados está associado.
O Aurora PostgreSQL e o Aurora MySQL comportam relacionamentos de confiança florestal unidirecionais e bidirecionais com autenticação em toda a floresta ou autenticação seletiva.
Em alguns casos, é possível configurar a autenticação Kerberos em uma relação de confiança externa. Isso exige que o Active Directory autogerenciado tenha configurações adicionais. Isso inclui, entre outros, o [Kerberos Forest Search Order](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/kfso-not-work-in-external-trust-event-is-17).
O Aurora é compatível com a autenticação Kerberos para clusters de banco de dados do Aurora MySQL e do Aurora PostgreSQL. Para obter mais informações, consulte [Usar a autenticação Kerberos para Aurora MySQL](aurora-mysql-kerberos.md) e [Usar a autenticação Kerberos com o Aurora PostgreSQL](postgresql-kerberos.md) .
# Gerenciamento de senhas com Amazon Aurora e AWS Secrets Manager
O Amazon Aurora integra-se ao Secrets Manager para gerenciar senhas do usuário principal para suas .
**Topics**
+ [Disponibilidade de regiões e versões](#rds-secrets-manager-availability)
+ [Limitações da integração do Secrets Manager com o Amazon Aurora](#rds-secrets-manager-limitations)
+ [Visão geral do gerenciamento de senhas do usuário principal com AWS Secrets Manager](#rds-secrets-manager-overview)
+ [Benefícios do gerenciamento de senhas do usuário principal com o Secrets Manager](#rds-secrets-manager-benefits)
+ [Permissões necessárias para a integração do Secrets Manager](#rds-secrets-manager-permissions)
+ [Impor o gerenciamento da senha do usuário principal pelo Aurora no AWS Secrets Manager](#rds-secrets-manager-auth)
+ [Gerenciar a senha do usuário principal para um cluster de banco de dados com o Secrets Manager](#rds-secrets-manager-db-cluster)
+ [Alternar o segredo da senha do usuário principal para um cluster de banco de dados](#rds-secrets-manager-rotate-db-cluster)
+ [Visualizar os detalhes sobre um segredo para um cluster de banco de dados](#rds-secrets-manager-view-db-cluster)
## Disponibilidade de regiões e versões
A disponibilidade e a compatibilidade de recursos variam entre versões específicas de cada mecanismo de banco de dados e entre Regiões da AWS. Para ter mais informações sobre a disponibilidade de versões e regiões com a integração do Secrets Manager com o Amazon Aurora, consulte [Regiões e mecanismos de banco de dados do Aurora compatíveis com a integração com o Secrets Manager](Concepts.Aurora_Fea_Regions_DB-eng.Feature.SecretsManager.md).
## Limitações da integração do Secrets Manager com o Amazon Aurora
O gerenciamento de senhas do usuário principal com o Secrets Manager não é compatível com os seguintes recursos:
+ Implantações azul/verde do Amazon RDS
+ Clusters de banco de dados que fazem parte de um banco de dados global do Aurora.
+ Aurora Serverless v1Clusters de banco de dados do
+ Réplicas de leitura entre regiões
+ Replicação externa de logs binários
## Visão geral do gerenciamento de senhas do usuário principal com AWS Secrets Manager
Com o AWS Secrets Manager, é possível substituir credenciais codificadas em seu código, inclusive senhas de banco de dados, por uma chamada de API ao Secrets Manager para recuperar o segredo de forma programática. Para ter mais informações sobre o Secrets Manager, consulte o [Guia do usuário do AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/).
Quando você armazena segredos de banco de dados no Secrets Manager, sua Conta da AWS incorre em cobranças. Para obter mais informações sobre definição de preços, consulte [Definição de preço do AWS Secrets Manager](https://aws.amazon.com/secrets-manager/pricing).
Você pode especificar que o Aurora gerencie a senha de usuário principal no Secrets Manager para um cluster de banco de dados do Amazon Aurora ao realizar uma das seguintes operações:
+ Criar um cluster de banco de dados
+ Modificar um cluster de banco de dados
+ Restaurar um cluster de banco de dados do Amazon S3 (somente Aurora MySQL)
Quando você especifica que o Aurora gerencie a senha do usuário principal no Secrets Manager, o Aurora gera a senha e a armazena no Secrets Manager. Você pode interagir diretamente com o segredo para recuperar as credenciais do usuário principal. Você também pode especificar uma chave gerenciada pelo cliente para criptografar o segredo ou usar a chave do KMS fornecida pelo Secrets Manager.
O Aurora gerencia as configurações do segredo e o alterna a cada sete dias por padrão. Você pode modificar algumas configurações, como o cronograma de alternância. Se você excluir um cluster de banco de dados que gerencie um segredo no Secrets Manager, o segredo e seus metadados associados também serão excluídos.
Para conectar-se a uma com as credenciais em um segredo, você pode recuperar o segredo do Secrets Manager. Para ter mais informações, consulte [ Recuperar segredos do AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets.html) e [Conecte-se a um banco de dados SQL com credenciais em um segredo do AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets_jdbc.html) no *Guia do usuário do AWS Secrets Manager*.
## Benefícios do gerenciamento de senhas do usuário principal com o Secrets Manager
O gerenciamento de senhas do usuário principal pelo Aurora com o Secrets Manager oferece os seguintes benefícios:
+ O Aurora gera automaticamente credenciais de banco de dados.
+ O Aurora armazena e gerencia automaticamente as credenciais do banco de dados no AWS Secrets Manager.
+ O Aurora alterna as credenciais do banco de dados regularmente, sem exigir alterações na aplicação.
+ O Secrets Manager protege as credenciais do banco de dados do acesso humano e da visualização de texto sem formatação.
+ O Secrets Manager permite a recuperação de credenciais do banco de dados em segredos para conexões de banco de dados.
+ O Secrets Manager permite um controle refinado do acesso às credenciais do banco de dados em segredos com o uso do IAM.
+ Você também pode separar a criptografia do banco de dados da criptografia de credenciais com chaves do KMS diferentes.
+ É possível eliminar o gerenciamento e a alternância manuais das credenciais do banco de dados.
+ Você pode monitorar facilmente as credenciais do banco de dados com o AWS CloudTrail e o Amazon CloudWatch.
Para obter mais informações sobre os benefícios do Secrets Manager, consulte o [Guia do usuário do AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/).
## Permissões necessárias para a integração do Secrets Manager
Os usuários devem ter as permissões necessárias para realizar operações relacionadas à integração do Secrets Manager. É possível criar políticas do IAM que concedam permissões para realizar operações de API específicas nos recursos especificados necessários. Depois, você pode anexar essas políticas aos conjuntos de permissões do IAM ou às funções que exigem essas permissões. Para ter mais informações, consulte [Gerenciamento de identidade e acesso no Amazon Aurora](UsingWithRDS.IAM.md).
Para operações de criação, modificação ou restauração, o usuário que especifica que o Aurora gerencie a senha do usuário principal no Secrets Manager deve ter permissões para realizar as seguintes operações:
+ `kms:DescribeKey`
+ `secretsmanager:CreateSecret`
+ `secretsmanager:TagResource`
A permissão `kms:DescribeKey` é necessária para acessar sua chave gerenciada pelo cliente para o `MasterUserSecretKmsKeyId` e para descrever `aws/secretsmanager`.
Para operações de criação, modificação ou restauração, o usuário que especifica a senha do usuário principal para criptografar o segredo no Secrets Manager deve ter permissões para realizar as seguintes operações:
+ `kms:Decrypt`
+ `kms:GenerateDataKey`
+ `kms:CreateGrant`
Para operações de modificação, o usuário que alterna a senha de usuário principal no Secrets Manager deve ter permissões para realizar a seguinte operação:
+ `secretsmanager:RotateSecret`
## Impor o gerenciamento da senha do usuário principal pelo Aurora no AWS Secrets Manager
Você pode usar as chaves de condição do IAM para impor o gerenciamento pelo Aurora da senha do usuário principal no AWS Secrets Manager. A política a seguir não permite que os usuários criem nem restaurem instâncias de banco de dados ou clusters de banco de dados ou a menos que a senha do usuário principal seja gerenciada pelo Aurora no Secrets Manager.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": ["rds:CreateDBInstance", "rds:CreateDBCluster", "rds:RestoreDBInstanceFromS3", "rds:RestoreDBClusterFromS3"],
"Resource": "*",
"Condition": {
"Bool": {
"rds:ManageMasterUserPassword": false
}
}
}
]
}
```
------
**nota**
Esta política impõe o gerenciamento de senhas no AWS Secrets Manager no momento da criação. No entanto, você ainda pode desativar a integração do Secrets Manager e definir manualmente uma senha principal modificando o cluster.
Para evitar isso, inclua `rds:ModifyDBInstance` e `rds:ModifyDBCluster` no bloco “Ação” da política. Esteja ciente de que isso impede que o usuário aplique quaisquer modificações adicionais aos clusters existentes que não têm a integração com o Secrets Manager habilitada.
Para ter mais informações sobre como usar as chaves de condição em políticas do IAM, consulte [Chaves de condição de políticas do Aurora](security_iam_service-with-iam.md#UsingWithRDS.IAM.Conditions) e [Políticas de exemplo: usar chaves de condição](UsingWithRDS.IAM.Conditions.Examples.md).
## Gerenciar a senha do usuário principal para um cluster de banco de dados com o Secrets Manager
Você pode configurar o gerenciamento pelo Aurora da senha do usuário principal no Secrets Manager ao realizar as seguintes ações:
+ [Criar um cluster de bancos de dados do Amazon Aurora](Aurora.CreateInstance.md)
+ [Modificar um cluster de bancos de dados Amazon Aurora](Aurora.Modifying.md)
+ [Migrar dados de um banco de dados MySQL externo para um cluster de banco de dados do Amazon Aurora MySQL](AuroraMySQL.Migrating.ExtMySQL.md)
Você pode usar o console do RDS, a AWS CLI ou a API do RDS para realizar essas ações.
### Console
Siga as instruções para criar ou modificar um cluster de banco de dados com o console do RDS:
+ [Criar um cluster de banco de dados](Aurora.CreateInstance.md#Aurora.CreateInstance.Creating)
+ [Modificar uma instância de banco de dados em um cluster de banco de dados](Aurora.Modifying.md#Aurora.Modifying.Instance)
No console do RDS, você pode modificar qualquer instância de banco de dados para especificar as configurações de gerenciamento de senha do usuário principal para todo o cluster de banco de dados.
+ [Restaurar um cluster de banco de dados do Amazon Aurora MySQL de um bucket do Amazon S3](AuroraMySQL.Migrating.ExtMySQL.S3.md#AuroraMySQL.Migrating.ExtMySQL.S3.Restore)
Ao usar o console do RDS para realizar uma dessas operações, você pode especificar que a senha do usuário principal seja gerenciada pelo Aurora no Secrets Manager. Para fazer isso ao criar ou restaurar um cluster de banco de dados, selecione **Gerenciar credenciais principais no AWS Secrets Manager** em **Configurações de credenciais**. Quando estiver modificando um cluster de banco de dados, selecione **Gerenciar credenciais principais no AWS Secrets Manager** em **Configurações**.
A imagem a seguir é um exemplo da configuração **Gerenciar credenciais principais no AWS Secrets Manager** quando você está criando ou restaurando um cluster de banco de dados.
![\[Gerenciar credenciais principais no AWS Secrets Manager\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/secrets-manager-credential-settings.png)
Quando você seleciona essa opção, o Aurora gera a senha do usuário principal e a gerencia durante todo o ciclo de vida no Secrets Manager.
![\[Gerenciar credenciais principais no AWS Secrets Manager selecionado\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/secrets-manager-integration-create.png)
Você pode optar por criptografar o segredo com uma chave do KMS fornecida pelo Secrets Manager ou com uma chave gerenciada pelo cliente criada por você. Depois que o Aurora estiver gerenciando as credenciais de banco de dados de um cluster de banco de dados, não será possível alterar a chave do KMS usada para criptografar o segredo.
Você pode escolher outras configurações para atender às suas necessidades.
Para ter mais informações sobre as configurações disponíveis ao criar um cluster de banco de dados, consulte [Configurações de clusters de bancos de dados do Aurora](Aurora.CreateInstance.md#Aurora.CreateInstance.Settings). Para ter mais informações sobre as configurações disponíveis ao modificar um cluster de banco de dados, consulte [Configurações do Amazon Aurora](Aurora.Modifying.md#Aurora.Modifying.Settings).
### AWS CLI
Para especificar que o Aurora gerencie a senha do usuário principal no Secrets Manager, especifique a opção `--manage-master-user-password` em um dos seguintes comandos:
+ [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html)
+ [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)
+ [restore-db-cluster-from-s3](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-from-s3.html)
Quando você especifica a opção `--manage-master-user-password` nesses comandos, o Aurora gera a senha do usuário principal e a gerencia durante todo o ciclo de vida no Secrets Manager.
Para criptografar o segredo, você pode especificar uma chave gerenciada pelo cliente ou usar a chave do KMS fornecida pelo Secrets Manager. Use a opção `--master-user-secret-kms-key-id` para especificar uma chave gerenciada pelo cliente. O identificador de chave do AWS KMS é o ARN da chave, o ID da chave, o ARN do alias ou o nome do alias da chave do KMS. Para usar uma chave do KMS em outra Conta da AWS, é necessário usar o ARN da chave ou o ARN do alias. Depois que o Aurora estiver gerenciando as credenciais de banco de dados de um cluster de banco de dados, não será possível alterar a chave do KMS usada para criptografar o segredo.
Você pode escolher outras configurações para atender às suas necessidades.
Para ter mais informações sobre as configurações disponíveis ao criar um cluster de banco de dados, consulte [Configurações de clusters de bancos de dados do Aurora](Aurora.CreateInstance.md#Aurora.CreateInstance.Settings). Para ter mais informações sobre as configurações disponíveis ao modificar um cluster de banco de dados, consulte [Configurações do Amazon Aurora](Aurora.Modifying.md#Aurora.Modifying.Settings).
Este exemplo cria um cluster de banco de dados e especifica que o Aurora gerencie a senha no Secrets Manager. O segredo é criptografado usando a chave do KMS fornecida pelo Secrets Manager.
**Example**
Para Linux, macOS ou Unix:
```
1. aws rds create-db-cluster \
2. --db-cluster-identifier sample-cluster \
3. --engine aurora-mysql \
4. --engine-version 8.0 \
5. --master-username admin \
6. --manage-master-user-password
```
Para Windows:
```
1. aws rds create-db-cluster ^
2. --db-cluster-identifier sample-cluster ^
3. --engine aurora-mysql ^
4. --engine-version 8.0 ^
5. --master-username admin ^
6. --manage-master-user-password
```
### API do RDS
Para especificar que o Aurora gerencie a senha do usuário principal no Secrets Manager, defina o parâmetro `ManageMasterUserPassword` como `true` em uma das seguintes operações:
+ [CreateDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html)
+ [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html)
+ [RestoreDBClusterFromS3](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterFromS3.html)
Quando você define o parâmetro `ManageMasterUserPassword` como `true` em uma dessas operações, o Aurora gera a senha do usuário principal e a gerencia durante todo o ciclo de vida no Secrets Manager.
Para criptografar o segredo, você pode especificar uma chave gerenciada pelo cliente ou usar a chave do KMS fornecida pelo Secrets Manager. Use o parâmetro `MasterUserSecretKmsKeyId` para especificar uma chave gerenciada pelo cliente. O identificador de chave do AWS KMS é o ARN da chave, o ID da chave, o ARN do alias ou o nome do alias da chave do KMS. Para usar uma chave do KMS em outra Conta da AWS, é necessário usar o ARN da chave ou o ARN do alias. Depois que o Aurora estiver gerenciando as credenciais de banco de dados de um cluster de banco de dados, não será possível alterar a chave do KMS usada para criptografar o segredo.
## Alternar o segredo da senha do usuário principal para um cluster de banco de dados
Quando o Aurora alterna um segredo de senha do usuário principal, o Secrets Manager gera uma nova versão para o segredo existente. A nova versão do segredo contém a nova senha do usuário principal. O Aurora altera a senha do usuário principal do cluster de banco de dados para corresponder à nova versão do segredo.
Você pode alternar um segredo imediatamente em vez de esperar por uma alternância programada. Para alternar o segredo de uma senha do usuário principal no Secrets Manager, modifique o cluster de banco de dados . Para obter informações sobre como modificar um cluster de banco de dados, consulte [Modificar um cluster de bancos de dados Amazon Aurora](Aurora.Modifying.md).
Você pode alternar o segredo de uma senha do usuário principal imediatamente com o console do RDS, a AWS CLI ou a API do RDS. A nova senha tem sempre 28 caracteres e contém pelo menos um caractere maiúsculo e um minúsculo, um número e um sinal de pontuação.
### Console
Para alternar o segredo de uma senha do usuário principal usando o console do RDS, modifique o cluster de banco de dados e selecione **Rotate secret immediately** (Alternar segredo imediatamente) em **Settings** (Configurações).
![\[Alternar o segredo da senha do usuário principal imediatamente\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/secrets-manager-integration-rotate-aurora.png)
Siga as instruções para modificar um cluster de banco de dados com o console do RDS em [Modificar o cluster de banco de dados usando o console, a CLI e a API](Aurora.Modifying.md#Aurora.Modifying.Cluster). Você deve escolher **Apply immediately** (Aplicar imediatamente) na página de confirmação.
### AWS CLI
Para alternar o segredo de uma senha do usuário principal usando a AWS CLI, utilize o comando [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) e especifique a opção `--rotate-master-user-password`. Você deve especificar a opção `--apply-immediately` ao alternar a senha principal.
Este exemplo alterna o segredo de uma senha do usuário principal.
**Example**
Para Linux, macOS ou Unix:
```
1. aws rds modify-db-cluster \
2. --db-cluster-identifier mydbcluster \
3. --rotate-master-user-password \
4. --apply-immediately
```
Para Windows:
```
1. aws rds modify-db-cluster ^
2. --db-cluster-identifier mydbcluster ^
3. --rotate-master-user-password ^
4. --apply-immediately
```
### API do RDS
Você pode alternar o segredo de uma senha do usuário principal usando a operação [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) e definindo o parâmetro `RotateMasterUserPassword` como `true`. Você deve definir o parâmetro `ApplyImmediately` como `true` ao alternar a senha principal.
## Visualizar os detalhes sobre um segredo para um cluster de banco de dados
É possível recuperar seus segredos usando o console ([https://console.aws.amazon.com/secretsmanager/](https://console.aws.amazon.com/secretsmanager/)) ou a AWS CLI (comando [get-secret-value](https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/get-secret-value.html) do Secrets Manager).
Você pode encontrar o nome do recurso da Amazon (ARN) de um segredo gerenciado pelo Aurora no Secrets Manager com o console do RDS, a AWS CLI o ou a API do RDS.
### Console
**Como visualizar os detalhes sobre um segredo gerenciado pelo Aurora no Secrets Manager**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. No painel de navegação, escolha **Bancos de dados**.
1. Selecione o nome do cluster de banco de dados para mostrar os detalhes.
1. Escolha a guia **Configuração**.
Em **Master Credentials ARN** (ARN das credenciais principais), você pode ver o ARN do segredo.
![\[Ver os detalhes sobre um segredo gerenciado pelo Aurora no Secrets Manager\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/secrets-manager-integration-view-cluster.png)
Você pode seguir o link **Manage in Secrets Manager** (Gerenciar no Secrets Manager) para visualizar e gerenciar o segredo no console do Secrets Manager.
### AWS CLI
Você pode usar o comando [describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html) da AWS CLI do RDS para encontrar as seguintes informações sobre um segredo gerenciado pelo Aurora no Secrets Manager:
+ `SecretArn`: o ARN do segredo
+ `SecretStatus`: o status do segredo
Os valores de status possíveis são os seguintes:
+ `creating`: o segredo está sendo criado.
+ `active`: o segredo está disponível para uso e alternância normais.
+ `rotating`: o segredo está sendo alternado.
+ `impaired`: o segredo pode ser usado para acessar as credenciais do banco de dados, mas não pode ser alternado. Um segredo pode ter esse status se, por exemplo, as permissões forem alteradas para que o RDS não possa mais acessar o segredo nem a chave do KMS do segredo.
Quando um segredo tem esse status, você pode corrigir a condição que o causou. Se você corrigir a condição que causou o status, ele permanecerá `impaired` até a próxima alternância. Como alternativa, você pode modificar o cluster de banco de dados para desativar o gerenciamento automático das credenciais do banco de dados e, depois, modificar o cluster de banco de dados novamente para ativar o gerenciamento automático das credenciais do banco de dados. Para modificar o cluster de banco de dados, use a opção `--manage-master-user-password` no comando [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html).
+ `KmsKeyId`: o ARN da chave do KMS usada para criptografar o segredo
Especifique a opção `--db-cluster-identifier` para mostrar a saída de um cluster de banco de dados específico. Este exemplo mostra a saída de um segredo usado por um cluster de banco de dados.
**Example**
```
1. aws rds describe-db-clusters --db-cluster-identifier mydbcluster
```
O exemplo a seguir mostra a saída de um segredo:
```
"MasterUserSecret": {
"SecretArn": "arn:aws:secretsmanager:eu-west-1:123456789012:secret:rds!cluster-033d7456-2c96-450d-9d48-f5de3025e51c-xmJRDx",
"SecretStatus": "active",
"KmsKeyId": "arn:aws:kms:eu-west-1:123456789012:key/0987dcba-09fe-87dc-65ba-ab0987654321"
}
```
Quando você tiver o ARN do segredo, poderá visualizar detalhes sobre o segredo usando o comando da CLI [get-secret-value](https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/get-secret-value.html) do Secrets Manager.
Este exemplo mostra os detalhes do segredo na saída de exemplo anterior.
**Example**
Para Linux, macOS ou Unix:
```
aws secretsmanager get-secret-value \
--secret-id 'arn:aws:secretsmanager:eu-west-1:123456789012:secret:rds!cluster-033d7456-2c96-450d-9d48-f5de3025e51c-xmJRDx'
```
Para Windows:
```
aws secretsmanager get-secret-value ^
--secret-id 'arn:aws:secretsmanager:eu-west-1:123456789012:secret:rds!cluster-033d7456-2c96-450d-9d48-f5de3025e51c-xmJRDx'
```
### API do RDS
Você pode visualizar o ARN, o status e a chave do KMS de um segredo gerenciado pelo Aurora no Secrets Manager usando a operação [DescribeDBClusters](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusters.html) do RDS e definindo o parâmetro `DBClusterIdentifier` como um identificador de cluster de banco de dados. Detalhes sobre o segredo estão incluídos na saída.
Quando você tiver o ARN do segredo, poderá visualizar detalhes sobre o segredo usando o comando da CLI [GetSecretValue](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html) do Secrets Manager.
# Proteção de dados no Amazon RDS
O [modelo de responsabilidade compartilhada](https://aws.amazon.com/compliance/shared-responsibility-model/) da AWS aplica-se à proteção de dados no Amazon Relational Database Service. Conforme descrito nesse modelo, a AWS é responsável por proteger a infraestrutura global que executa toda a 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 obter mais informações sobre a privacidade de dados, consulte as [Data Privacy FAQ](https://aws.amazon.com/compliance/data-privacy-faq/). Para obter mais informações 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 as credenciais da Conta da AWS e configure as contas de usuário 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 os recursos da AWS. Exigimos TLS 1.2 e recomendamos TLS 1.3.
+ Configure os logs de API e atividade do usuário com AWS CloudTrail. Para obter informações sobre como usar as trilhas do CloudTrail para capturar atividades da AWS, consulte [Working with CloudTrail trails](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) no *Guia do usuário do AWS CloudTrail*.
+ Use as soluções de criptografia AWS, juntamente com todos os controles de segurança padrão em Serviços da AWS.
+ Use serviços gerenciados de segurança avançada, como o Amazon Macie, que ajuda a localizar e proteger dados sigilosos armazenados no Amazon S3.
+ Se você precisar de módulos criptográficos validados pelo FIPS 140-3 ao acessar a AWS por meio de uma interface de linha de comandos ou de uma API, use um endpoint do FIPS. Para obter mais informações 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 sigilosas, como endereços de e-mail de clientes, em tags ou campos de formato livre, como um campo **Nome**. Isso também vale para o uso do Amazon RDS ou de outros Serviços da AWS com o console, a API, a AWS CLI ou os AWS SDKs. 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.
**Topics**
+ [Proteção de dados usando criptografia](Encryption.md)
+ [Privacidade do tráfego entre redes](inter-network-traffic-privacy.md)
# Proteção de dados usando criptografia
O Amazon Aurora criptografa os recursos do banco de dados na camada de armazenamento. Também é possível criptografar conexões com clusters de banco de dados.
**Topics**
+ [Criptografar recursos do Amazon Aurora](Overview.Encryption.md)
+ [AWS KMS keyGerenciamento de](Overview.Encryption.Keys.md)
+ [Usar SSL/TLS para criptografar uma conexão com um cluster de banco de dados](UsingWithRDS.SSL.md)
+ [Alternar o certificado SSL/TLS](UsingWithRDS.SSL-certificate-rotation.md)
# Criptografar recursos do Amazon Aurora
O Amazon Aurora protege os dados em repouso e em trânsito, seja quando eles são movidos entre clientes on-premises e o Amazon Aurora ou entre o Amazon Aurora e outros recursos da AWS. O Amazon Aurora criptografa todos os dados do usuário em seus clusters de banco de dados do Amazon Aurora, inclusive logs, backups automatizados e snapshots.
Após a criptografia dos dados, o Amazon Aurora lida com a autenticação do acesso e a decodificação dos dados de forma transparente com um impacto mínimo sobre o desempenho. Você não precisa modificar suas aplicações cliente de banco de dados para usar a criptografia.
**nota**
Para clusters, os dados em trânsito entre a origem e as réplicas de leitura são criptografados, até mesmo quando a replicação ocorre entre regiões da AWS.
**Topics**
+ [Visão geral sobre criptografia em recursos do Amazon Aurora](#Overview.Encryption.Overview)
+ [Criptografar um cluster de banco de dados do Amazon Aurora](#Overview.Encryption.Enabling)
+ [Verificar se a criptografia está habilitada para um cluster de banco de dados](#Overview.Encryption.Determining)
+ [Disponibilidade da criptografia do Amazon Aurora](#Overview.Encryption.Availability)
+ [Criptografia em trânsito](#Overview.Encryption.InTransit)
+ [Limitações dos clusters de banco de dados criptografados do Amazon Aurora](#Overview.Encryption.Limitations)
## Visão geral sobre criptografia em recursos do Amazon Aurora
Os clusters de banco de dados criptografados do Amazon Aurora fornecem uma camada adicional de proteção de dados, protegendo seus dados contra o acesso não autorizado ao armazenamento subjacente. Todos os novos clusters de banco de dados criados em ou após 18 de fevereiro de 2026 e no Amazon Aurora são criptografados em repouso usando a criptografia AES-256 padrão do setor. Essa criptografia é realizada automaticamente em segundo plano, protegendo os dados sem exigir nenhuma ação de sua parte. Isso também ajuda a reduzir a carga e complexidade operacionais necessárias para proteger dados sensíveis. Com a criptografia de dados em repouso, é possível proteger aplicações que exigem conformidade e alto nível de segurança contra ameaças acidentais e mal-intencionadas, bem como atender a requisitos regulamentares.
O Amazon Aurora usa uma chave do AWS Key Management Service para criptografar esses recursos. O AWS KMS combina hardware e software seguros e altamente disponíveis para fornecer um sistema de gerenciamento de chaves escalado para a nuvem. Ao criar um cluster de banco de dados, o Amazon Aurora usa criptografia do lado do servidor (SSE) com uma chave de [propriedade da AWS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-key) por padrão. No entanto, é possível escolher entre três tipos de criptografia com base em suas necessidades de segurança e conformidade:
+ **Chave de propriedade da AWS (SSE-RDS)**: uma chave de criptografia totalmente controlada pela AWS que é usada automaticamente pelo Aurora para criptografia padrão e não pode ser visualizada nem gerenciada pelo usuário.
+ **Chave gerenciada pela AWS (AMK)**: essa chave, criada e gerenciada pela AWS, é visível em sua conta, mas não pode ser personalizada. Não há taxa mensal, mas cobranças de API do AWS KMS serão aplicadas.
+ **Chave gerenciada pelo cliente (CMK)**: a chave é armazenada na sua conta e é você que a cria, detém e gerencia. Você tem controle total sobre a chave do KMS (cobranças do AWS KMS são aplicáveis).
As chaves gerenciadas pela AWS são uma opção de criptografia legada que permanece disponível para oferecer compatibilidade com versões anteriores. Por padrão, o Amazon Aurora usa chaves de propriedade da AWS para criptografar os dados, o que oferece uma sólida proteção à segurança sem cobranças adicionais nem custos indiretos de gerenciamento. Para a maioria dos casos de uso, recomendamos usar a chave de propriedade da AWS padrão para simplificar e economizar ou uma chave gerenciada pelo cliente (CMK) se você precisar de controle total sobre suas chaves de criptografia. Para saber mais sobre tipos de chave, consulte as informações sobre [chaves gerenciadas pelo cliente e chaves gerenciadas pela AWS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#key-mgmt).
**nota**
**Importante:** para instâncias ou clusters de banco de dados de origem ou clusters criados antes de 18 de fevereiro de 2026 e em , nos quais você não optou por criptografia, snapshots, clones e réplicas do Amazon Aurora (instância de leitura) criadas com base nessas fontes, permanecerão sem criptografia. No entanto, as operações de restauração e a replicação lógica fora do cluster do Amazon Aurora produzirão instâncias criptografadas.
Em um cluster de banco de dados criptografado do Amazon Aurora, todas as instâncias de banco de dados, logs, backups e snapshots são criptografados. Consulte mais informações sobre a disponibilidade e as limitações da criptografia em [Disponibilidade da criptografia do Amazon Aurora](#Overview.Encryption.Availability) e [Limitações dos clusters de banco de dados criptografados do Amazon Aurora](#Overview.Encryption.Limitations).
Ao criar um cluster de banco de dados criptografado, é possível escolher uma chave gerenciada pelo cliente ou a Chave gerenciada pela AWS para que o Amazon Aurora criptografe o cluster de banco de dados. Se você não especificar o identificador de chave para uma chave gerenciada pelo cliente, o Amazon Aurora usará a Chave gerenciada pela AWS para seu novo cluster de banco de dados. O Amazon Aurora cria uma Chave gerenciada pela AWS para o Amazon Aurora para a sua conta da AWS. A sua conta da AWS tem uma Chave gerenciada pela AWS diferente para o Amazon Aurora para cada região da AWS.
Para gerenciar as chaves gerenciadas pelo cliente usadas para criptografia e descriptografia de recursos do Amazon Aurora, use o [AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/).
Com o AWS KMS, é possível criar chaves gerenciadas pelo cliente e definir as políticas para controlar o uso dessas chaves. O AWS KMS é compatível com o CloudTrail, o que permite auditar o uso da chave do KMS para verificar se as chaves gerenciadas pelo cliente estão sendo usadas adequadamente. Você pode usar as chaves gerenciadas com o Amazon Aurora e serviços compatíveis da AWS, como o Amazon S3, Amazon EBS e Amazon Redshift. Para obter uma lista de serviços integrados ao AWS KMS, consulte [Integração de serviços da AWS](https://aws.amazon.com/kms/features/#AWS_Service_Integration). Algumas considerações sobre o uso de chaves do KMS:
+ Assim que uma instância de banco de dados criptografada é criada, não é possível alterar a chave do KMS usada por essa instância de banco de dados. Determine os requisitos da chave do KMS antes de criar a instância de banco de dados criptografada. Se você precisar alterar a chave de criptografia do cluster de banco de dados, siga estas etapas:
+ Crie um snapshot manual do cluster.
+ Restaure o snapshot e habilite a criptografia com a chave do KMS desejada durante a operação de restauração.
+ Se você restaurar um snapshot não criptografado e optar por não criptografar, o cluster de banco de dados criado será criptografado usando a criptografia padrão em repouso (chave de propriedade da AWS).
+ Não é possível compartilhar um snapshot que foi criptografado usando a Chave gerenciada pela AWS da conta da AWS que o compartilhou.
+ Cada instância de banco de dados no cluster de banco de dados tem em comum o mesmo armazenamento criptografado com a mesma chave do KMS.
**Importante**
O Amazon Aurora pode perder o acesso à chave do KMS para um cluster de banco de dados quando você desabilita a chave do KMS. Nesses casos, o cluster de banco de dados criptografada entra no estado `inaccessible-encryption-credentials-recoverable`. O cluster de banco de dados permanece nesse estado por sete dias, durante os quais a instância é interrompida. As chamadas de API feitas ao cluster de banco de dados durante esse período podem não ser bem-sucedidas. Para recuperar o cluster de banco de dados, habilite a chave do KMS e reinicie esse cluster. É possível habilitar a chave do KMS no Console de gerenciamento da AWS, na AWS CLI ou na API do RDS. Reinicie o cluster de banco de dados utilizando o comando [start-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/start-db-cluster.html) da AWS CLI ou o Console de gerenciamento da AWS.
O estado `inaccessible-encryption-credentials-recoverable` só se aplica a clusters de banco de dados que podem ser interrompidos. Esse estado recuperável não se aplica a instâncias que não podem ser interrompidas, como cluster com réplicas de leitura entre regiões. Para obter mais informações, consulte [Limitações para interromper e iniciar clusters de banco de dados do Aurora](aurora-cluster-stop-start.md#aurora-cluster-stop-limitations).
Se o cluster de banco de dados não for recuperado em até sete dias, ele entrará no estado `inaccessible-encryption-credentials` do terminal. Nesse estado, o cluster de banco de dados não pode mais ser usado e só é possível restaurá-lo por um backup. É recomendável sempre habilitar backups para evitar a perda de dados em seus bancos de dados.
Durante a criação de um cluster de banco de dados, o Aurora verifica se a entidade principal da chamada tem acesso à chave do KMS e gera uma concessão da chave do KMS, que é usada durante toda a vida útil do cluster de banco de dados. A revogação do acesso da entidade principal da chamada à chave do KMS não afeta um banco de dados em execução. Ao usar chaves do KMS em cenários entre contas, como copiar um snapshot para outra conta, a chave do KMS precisa ser compartilhada com a outra conta. Se você criar um cluster de banco de dados com base no snapshot sem especificar uma chave do KMS diferente, o novo cluster usará a chave do KMS da conta de origem. A revogação do acesso à chave após a criação do cluster de banco de dados não afeta o cluster. No entanto, a desabilitação da chave afeta todos os clusters de banco de dados criptografados com essa chave. Para evitar isso, especifique uma chave diferente durante a operação de cópia do snapshot.
Para ter mais informações sobre chaves do KMS, consulte [AWS KMS keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#kms_keys) no *Guia do desenvolvedor do AWS Key Management Service* e [AWS KMS keyGerenciamento de](Overview.Encryption.Keys.md).
## Criptografar um cluster de banco de dados do Amazon Aurora
Todos os novos clusters de banco de dados criados em ou após 18 de fevereiro de 2026 são criptografados por padrão com uma chave de propriedade da AWS.
Para criptografar um novo cluster de banco de dados usando uma Chave gerenciada pela AWS ou uma chave gerenciada pelo cliente, escolha a opção no console. Para obter informações sobre como criar com um cluster de banco de dados, consulte [Criar um cluster de bancos de dados do Amazon Aurora](Aurora.CreateInstance.md).
Se você usar o comando [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) da AWS CLI para criar um cluster de banco de dados criptografado, defina o parâmetro `--storage-encrypted`. Se você usar a operação da API [CreateDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html), defina o parâmetro `StorageEncrypted` como true.
Depois de criar um cluster de banco de dados criptografado, não será possível alterar a chave do KMS usada por esse cluster de banco de dados. Portanto, certifique-se de determinar os requisitos da chave do KMS antes de criar o seu cluster de banco de dados criptografado.
Se você usar o comando AWS CLI da `create-db-cluster` para criar um cluster de banco de dados criptografado com uma chave gerenciada pelo cliente, defina o parâmetro `--kms-key-id` para qualquer identificador da chave do KMS. Se você usar a operação `CreateDBInstance` da API do Amazon RDS, defina o parâmetro `KmsKeyId` para qualquer identificador de chave do KMS. Para usar uma chave gerenciada pelo cliente em outra conta da AWS, especifique o ARN da chave ou o ARN do alias.
## Verificar se a criptografia está habilitada para um cluster de banco de dados
É possível utilizar o Console de gerenciamento da AWS, a AWS CLI ou a API do RDS para verificar se a criptografia em repouso está habilitada para um cluster de banco de dados.
### Console
**Para verificar se a criptografia em repouso está habilitada para um cluster de banco de dados**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. No painel de navegação, escolha **Bancos de dados**.
1. Escolha no nome do cluster de banco de dados que você deseja verificar para mostrar os detalhes.
1. Escolha a guia **Configuration** (Configuração) e verifique o valor **Encryption** (Criptografia).
![\[Verificar a criptografia em repouso de um cluster de banco de dados\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/encryption-aurora-instance.png)
### AWS CLI
Para verificar se a criptografia em repouso está habilitada para um cluster de banco de dados usando a AWS CLI, chame o comando [describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html) comando com a seguinte opção:
+ `--db-cluster-identifier`: o nome do cluster de banco de dados.
O exemplo a seguir utiliza uma consulta para retornar `TRUE` ou `FALSE` referente à criptografia em repouso para o cluster de banco de dados `mydb`.
**Example**
```
1. aws rds describe-db-clusters --db-cluster-identifier mydb --query "*[].{StorageEncrypted:StorageEncrypted}" --output text
```
### API do RDS
Para verificar se a criptografia em repouso está habilitada para um cluster de banco de dados usando a API do Amazon RDS, chame a operação [DescribeDBClusters](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusters.html) com este parâmetro:
+ `DBClusterIdentifier`: o nome do cluster de banco de dados.
## Disponibilidade da criptografia do Amazon Aurora
No momento, a criptografia do Amazon Aurora está disponível para todos os mecanismos de banco de dados e tipos de armazenamento.
**nota**
A criptografia do Amazon Aurora não está disponível para a classe de instância de banco de dados db.t2.micro.
## Criptografia em trânsito
**Criptografia na camada física**
Todos os dados que fluem pelas Regiões da AWS por meio da rede global da AWS são automaticamente criptografados na camada física antes de saírem das instalações seguras da AWS. Todo o tráfego entre AZs é criptografado. Camadas adicionais de criptografia, inclusive as listadas nesta seção, podem oferecer mais proteções.
**Criptografia fornecida pelo emparelhamento da Amazon VPC e do Transit Gateway entre regiões**
Todo o tráfego entre regiões que usa o emparelhamento da Amazon VPC e do Transit Gateway é automaticamente criptografado em massa ao sair de uma região. Uma camada adicional de criptografia é fornecida automaticamente à camada física para todo tráfego antes que ele saia das instalações seguras da AWS.
**Criptografia entre instâncias**
A AWS fornece conectividade privada e segura entre instâncias de banco de dados de todos os tipos. Além disso, alguns tipos de instância usam os recursos de descarregamento do hardware subjacente Nitro System para criptografar automaticamente o tráfego em trânsito entre instâncias. Essa criptografia usa algoritmos de criptografia autenticada com dados associados (AEAD) com criptografia de 256 bits. Não há impacto na performance da rede. Para oferecer suporte a essa criptografia adicional de tráfego em trânsito entre instâncias, os seguintes requisitos devem ser atendidos:
+ As instâncias usam os seguintes tipos de instância:
+ **Uso geral**: M6i, M6id, M6in, M6idn, M7g
+ **Otimizadas para memória**: R6i, R6id, R6in, R6idn, R7g, X2idn, X2iedn, X2iezn
+ As instâncias estão na mesma Região da AWS.
+ As instâncias estão na mesma VPC ou VPCs emparelhadas, e o tráfego não passa por um dispositivo ou serviço de rede virtual, como um balanceador de carga ou um gateway de trânsito.
## Limitações dos clusters de banco de dados criptografados do Amazon Aurora
As seguintes limitações existem para clusters criptografados de banco de dados do Amazon Aurora:
+ Não é possível desativar a criptografia em um cluster de banco de dados criptografado.
+ Se você tiver um cluster não criptografado, todos os snapshots criados com base nesse cluster também não serão criptografados. Para criar um snapshot criptografado com base em um cluster não criptografado, é necessário copiar o snapshot e especificar uma chave gerenciada pelo cliente durante a operação de cópia. Não é possível criar um snapshot criptografado com base em um snapshot não criptografado sem especificar uma chave gerenciada pelo cliente.
+ Também não é possível criar um snapshot criptografado de uma de banco de dados não criptografada.
+ Um snapshot de uma instância de banco de dados criptografo deve ser criptografado usando a mesma chave do KMS que a instância de banco de dados.
+ Não é possível converter um cluster de banco de dados não criptografado em um criptografado. Entretanto, é possível restaurar um snapshot não criptografado em um cluster de banco de dados criptografado do Aurora. Para fazê-lo, especifique uma chave do KMS ao fazer uma restauração no snapshot não criptografado.
+ Se você tiver um cluster não criptografado, qualquer réplica do Amazon Aurora (instância de leitura) criada com base nesse cluster também não será criptografada. Para criar um cluster criptografado em um cluster não criptografado, é necessário restaurar o cluster de banco de dados. O cluster restaurado será criptografado por padrão após a operação de restauração.
+ Para copiar um snapshot criptografado de uma região da AWS para outra, é necessário especificar a chave do KMS na região da AWS de destino. Isso ocorre porque as chaves do KMS são específicas da região da AWS em que são criadas.
O snapshot de origem permanece criptografado ao longo do processo de cópia. O Amazon Aurora usa criptografia de envelope para proteger os dados durante o processo de cópia. Para ter mais informações sobre a criptografia de envelope, consulte [Criptografia de envelope](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping) no *Guia do desenvolvedor do AWS Key Management Service*.
+ Não é possível descriptografar um cluster de banco de dados criptografado. No entanto, é possível exportar dados de um cluster de banco de dados criptografado e importar os dados para um cluster de banco de dados não criptografado.
# AWS KMS keyGerenciamento de
O Amazon Aurora integra-se automaticamente ao [AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/) para gerenciar chaves. O Amazon Aurora usa criptografia envelopada. Para ter mais informações sobre a criptografia de envelope, consulte [Criptografia de envelope](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping) no *Guia do desenvolvedor do AWS Key Management Service*.
Você pode usar dois tipos de chave do AWS KMS para criptografar clusters de banco de dados.
+ Se você quiser o controle total de uma chave do KMS, precisará criar uma *chave gerenciada pelo cliente*. Para obter mais informações sobre chaves gerenciadas pelo cliente, consulte [Chaves gerenciadas pelo cliente](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) no *Guia do desenvolvedor do AWS Key Management Service*.
+ *Chaves gerenciadas pela AWS* são chaves do KMS em sua conta que são criadas, gerenciadas e usadas em seu nome por um produto da AWS integrado ao AWS KMS. Por padrão, a Chave gerenciada pela AWS do RDS (`aws/rds`) é usada para criptografia. Você não pode gerenciar, nem rotacionar, nem excluir a Chave gerenciada pela AWS do RDS. Para obter mais informações sobre as Chaves gerenciadas pela AWS, consulte [Chaves gerenciadas pela AWS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk) no *Guia do desenvolvedor do AWS Key Management Service*.
Para gerenciar as chaves do KMS usadas para clusters de banco de dados criptografados do Amazon Aurora, use o [AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/) no console do [AWS KMS](https://console.aws.amazon.com/kms), a AWS CLI ou a API do AWS KMS. Para visualizar logs de auditoria de cada ação realizada com uma chave gerenciada pela AWS ou pelo cliente, use o [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/). Para obter mais informações sobre a alternância de chaves, consulte [Alternância de chaves do AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html).
## Como autorizar o uso de uma chave gerenciada pelo cliente
Quando o Aurora utiliza uma chave gerenciada pelo cliente em operações criptográficas, ele atua em nome do usuário que está criando ou alterando o recurso do Aurora.
Para criar um recurso do Aurora usando uma chave gerenciada pelo cliente, um usuário deve ter permissões para acionar as seguintes operações na chave gerenciada pelo cliente:
+ `kms:CreateGrant`
+ `kms:DescribeKey`
Você pode especificar essas permissões em uma política de chaves ou em uma política do IAM, se a política de chaves permitir.
**Importante**
Ao usar instruções de negação explícitas para todos os recursos (\$1) nas políticas de chave do AWS KMS com serviços gerenciados como o Amazon RDS, você deve especificar uma condição para dar permissão à conta proprietária do recurso. As operações podem falhar sem essa condição, mesmo que a regra de negação inclua exceções para seu usuário do IAM.
**dica**
Para seguir o princípio de menor privilégio, não permita acesso total a `kms:CreateGrant`. Em vez disso, use a [chave de condição kms:ViaService](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-via-service) para permitir que o usuário crie concessões na chave do KMS somente quando a concessão for criada em nome do usuário por um serviço da AWS.
É possível tornar a política do IAM mais rígida de várias maneiras. Por exemplo, se você quiser permitir que a chave gerenciada pelo cliente seja usada somente para solicitações provenientes do Aurora, poderá utilizar a chave de condição kms:ViaService com o valor `rds..amazonaws.com`. Também é possível usar as chaves ou valores em [Contexto de criptografia do Amazon RDS](#Overview.Encryption.Keys.encryptioncontext) como uma condição para usar a chave gerenciada pelo cliente para criptografia.
Para obter mais informações, consulte [Permitir que usuários de outras contas usem uma chave do KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html) no *Guia do desenvolvedor do AWS Key Management Service* e em [Políticas de chave no AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies).
## Contexto de criptografia do Amazon RDS
Quando o Aurora usa sua chave do KMS ou quando o Amazon EBS usa a chave do KMS em nome do Aurora, o serviço especifica um [contexto de criptografia](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#encrypt_context). O contexto de criptografia é [dados autenticados adicionados](https://docs.aws.amazon.com/crypto/latest/userguide/cryptography-concepts.html#term-aad) (AAD) que o AWS KMS usa para garantir a integridade dos dados. Quando um contexto de criptografia é especificado para uma operação de criptografia, o serviço deve especificar esse mesmo contexto para a operação de descriptografia. Caso contrário, ocorrerá uma falha na descriptografia. O contexto de criptografia é também gravado nos logs do [AWS CloudTrail](https://aws.amazon.com/cloudtrail/) para ajudar você a compreender por que uma determinada chave do KMS foi usada. Os logs do CloudTrail podem conter muitas entradas que descrevem o uso de uma chave do KMS, mas o contexto de criptografia em cada entrada de log pode ajudar a determinar o motivo desse uso específico.
No mínimo, o Aurora sempre usa o ID do cluster de banco de dados para o contexto de criptografia, como no seguinte exemplo em formato JSON:
```
{ "aws:rds:dbc-id": "cluster-CQYSMDPBRZ7BPMH7Y3RTDG5QY" }
```
Esse contexto de criptografia pode ajudar a identificar para qual cluster de banco de dados a chave do KMS foi usada.
Quando a chave do KMS é usada em determinado cluster de banco de dados e em um volume do Amazon EBS específico, o ID do cluster de banco de dados e o ID do volume do Amazon EBS são usados no contexto de criptografia, como no seguinte exemplo em formato JSON:
```
{
"aws:rds:dbc-id": "cluster-BRG7VYS3SVIFQW7234EJQOM5RQ",
"aws:ebs:id": "vol-ad8c6542"
}
```
# Usar SSL/TLS para criptografar uma conexão com um cluster de banco de dados
É possível usar o Security Socket Layer (SSL) ou o Transport Layer Security (TLS) na aplicação para criptografar uma conexão com um cluster de banco de dados que executa o Aurora MySQL ou o Aurora PostgreSQL.
As conexões SSL/TLS oferecem uma camada de segurança criptografando dados que se movem entre o cliente e o cluster de banco de dados. Opcionalmente, sua conexão SSL/TLS pode realizar a verificação da identidade do servidor validando o certificado do servidor instalado no banco de dados. Para exigir a verificação da identidade do servidor, siga este processo geral:
1. Escolha a **Autoridade de certificação (CA)** que assina o**certificado de servidor de banco de dados** para seu banco de dados. Para ter mais informações sobre autoridades de certificação, consulte [Autoridades certificadoras](#UsingWithRDS.SSL.RegionCertificateAuthorities).
1. Baixe um pacote de certificados para usar quando você estiver se conectando com o banco de dados. Para baixar um pacote de certificados, consulte [Pacote de certificados por Região da AWS](#UsingWithRDS.SSL.CertificatesAllRegions).
**nota**
Todos os certificados somente estão disponíveis para download usando conexões SSL/TLS.
1. Conecte-se ao banco de dados usando o processo do mecanismo de banco de dados para implementar conexões SSL/TLS. Cada mecanismo de banco de dados tem seu próprio processo de implementação do SSL/TLS. Para saber como implementar o SSL/TLS para o banco de dados, siga o link correspondente ao seu mecanismo de banco de dados:
+ [Segurança com o Amazon Aurora MySQL](AuroraMySQL.Security.md)
+ [Segurança com o Amazon Aurora PostgreSQL](AuroraPostgreSQL.Security.md)
## Autoridades certificadoras
A **autoridade de certificação (CA**) é o certificado que identifica a CA raiz no início da cadeia de certificados. A CA assina o **certificado do servidor de banco de dados**, que é instalado em cada instância de banco de dados. O certificado do servidor de banco de dados identifica a instância de banco de dados como um servidor confiável.
![\[Visão geral sobre autoridade de certificação\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/certificate-authority-overview.png)
O Amazon RDS fornece as CAs a seguir para assinar o certificado do servidor de banco de dados para um banco de dados.
****
| Autoridade certificadora (CA) | Descrição | Nome comum (CN) |
| --- | --- | --- |
| rds-ca-rsa2048-g1 | Utiliza uma autoridade de certificação com algoritmo de chave privada RSA 2048 e algoritmo de assinatura SHA256 na maioria das Regiões da AWS. Nas AWS GovCloud (US) Regions, essa CA utiliza uma autoridade de certificação com algoritmo de chave privada RSA 2048 e algoritmo de assinatura SHA384. Essa CA é compatível com a alternância automática de certificados do servidor. | Amazon RDS region-identifier Root CA RSA2048 G1 |
| rds-ca-rsa4096-g1 | Utiliza uma autoridade de certificação com algoritmo de chave privada RSA 4096 e algoritmo de assinatura SHA384. Essa CA é compatível com a alternância automática de certificados do servidor. | Amazon RDS region-identifier Root CA RSA4096 G1 |
| rds-ca-ecc384-g1 | Utiliza uma autoridade de certificação com algoritmo de chave privada ECC 384 e algoritmo de assinatura SHA384. Essa CA é compatível com a alternância automática de certificados do servidor. | Amazon RDS region-identifier Root CA ECC384 G1 |
**nota**
Se você estiver usando a AWS CLI, poderá ver as validades das autoridades de certificação listadas acima usando [describe-certificates](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-certificates.html).
Esses certificados CA estão incluídos no pacote de certificados regionais e globais. Quando você usa a CA rds-ca-rsa2048-g1, rds-ca-rsa4096-g1 ou rds-ca-ecc384-g1 com um banco de dados, o RDS gerencia o certificado do servidor no banco de dados. O RDS alterna automaticamente o certificado do servidor de banco de dados antes que ele expire.
### Configurar a CA do banco de dados
Você pode definir a CA para um banco de dados ao realizar as seguintes tarefas:
+ Crie um cluster de banco de dados do Aurora: você pode definir a CA para uma instância de banco de dados em um cluster do Aurora ao criar a primeira instância de banco de dados no cluster de banco de dados usando a AWS CLI ou a API do RDS. Atualmente, você não pode definir a CA para as instâncias de banco de dados em um cluster de banco de dados ao criar o cluster de banco de dados com o uso do console do RDS. Para instruções, consulte [Criar um cluster de bancos de dados do Amazon Aurora](Aurora.CreateInstance.md) .
+ Modificar uma instância de banco de dados: você pode definir a CA para uma instância de banco de dados em um cluster de banco de dados modificando-a. Para instruções, consulte [Modificar uma instância de banco de dados em um cluster de banco de dados](Aurora.Modifying.md#Aurora.Modifying.Instance) .
**nota**
A CA padrão é definida como rds-ca-rsa2048-g1. Você pode substituir a CA padrão para sua Conta da AWS usando o comando [modify-certificates](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-certificates.html).
As CAs disponíveis dependem do mecanismo de banco de dados e da versão do mecanismo de banco de dados. Ao usar o Console de gerenciamento da AWS, você pode selecionar a CA usando a configuração **Certificate authority** (Autoridade de certificação), conforme mostrado na imagem a seguir.
![\[Opção de autoridade certificadora\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/certificate-authority.png)
O console mostra apenas as CAs que estão disponíveis para o mecanismo de banco de dados e a versão do mecanismo de banco de dados. Se estiver usando a AWS CLI, você poderá definir a CA para uma instância de banco de dados usando o comando [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) ou [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html).
Se estiver usando a AWS CLI, você poderá ver as CAs disponíveis para sua conta usando o comando [describe-certificates](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-certificates.html). Esse comando também mostra a data de expiração de cada CA em `ValidTill` na saída. Você pode encontrar as CAs que estão disponíveis para uma versão específica do mecanismo de banco de dados e do mecanismo de banco de dados usando o comando [describe-db-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html).
O exemplo a seguir mostra as CAs disponíveis para a versão padrão do mecanismo de banco de dados do RDS para PostgreSQL.
```
aws rds describe-db-engine-versions --default-only --engine postgres
```
A saída é semelhante à seguinte. As CAs disponíveis estão listadas em `SupportedCACertificateIdentifiers`. A saída também mostra se a versão do mecanismo de banco de dados é compatível com a alternância do certificado sem reiniciar em `SupportsCertificateRotationWithoutRestart`.
```
{
"DBEngineVersions": [
{
"Engine": "postgres",
"MajorEngineVersion": "13",
"EngineVersion": "13.4",
"DBParameterGroupFamily": "postgres13",
"DBEngineDescription": "PostgreSQL",
"DBEngineVersionDescription": "PostgreSQL 13.4-R1",
"ValidUpgradeTarget": [],
"SupportsLogExportsToCloudwatchLogs": false,
"SupportsReadReplica": true,
"SupportedFeatureNames": [
"Lambda"
],
"Status": "available",
"SupportsParallelQuery": false,
"SupportsGlobalDatabases": false,
"SupportsBabelfish": false,
"SupportsCertificateRotationWithoutRestart": true,
"SupportedCACertificateIdentifiers": [
"rds-ca-rsa2048-g1",
"rds-ca-ecc384-g1",
"rds-ca-rsa4096-g1"
]
}
]
}
```
### Validades do certificado do servidor de banco de dados
A validade do certificado do servidor de banco de dados depende do mecanismo de banco de dados e da versão do respectivo mecanismo. Se a versão do mecanismo comportar a alternância de certificado sem reinicialização, a validade do certificado do mecanismo será de um ano. Caso contrário, será de três anos.
Para obter mais informações sobre alternância de certificados de servidor de banco de dados, consulte [Alternância automática de certificados do servidor](UsingWithRDS.SSL-certificate-rotation.md#UsingWithRDS.SSL-certificate-rotation-server-cert-rotation).
### Visualizar a CA da instância de banco de dados
É possível visualizar os detalhes sobre a CA para um banco de dados na guia **Conectividade e segurança** no console, como na imagem a seguir.
![\[Detalhes da autoridade certificadora\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/certificate-authority-details.png)
Se estiver usando a AWS CLI, você poderá visualizar os detalhes da CA de uma instância de banco de dados usando o comando [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html).
## Baixar pacotes de certificados para o Aurora
Quando você se conecta ao banco de dados com SSL ou TLS, a instância do banco de dados exige um certificado de confiança do Amazon RDS. Selecione o link apropriado na tabela a seguir para baixar o pacote que corresponde à Região da AWS onde você hospeda o banco de dados.
### Pacote de certificados por Região da AWS
Os pacotes de certificados para todas as Regiões da AWS e as regiões GovCloud (EUA) contêm os seguintes certificados de CA raiz:
+ `rds-ca-rsa2048-g1`
+ `rds-ca-rsa4096-g1`
+ `rds-ca-ecc384-g1`
Os certificados `rds-ca-rsa4096-g1` e `rds-ca-ecc384-g1` não estão disponíveis nas seguintes regiões:
+ Ásia-Pacífico (Mumbai)
+ Ásia-Pacífico (Melbourne)
+ Oeste do Canadá (Calgary)
+ Europa (Zurique)
+ Europa (Espanha)
+ Israel (Tel Aviv)
O armazenamento confiável da aplicação só precisa registrar o certificado CA raiz. Não registre os certificados CA intermediários em seu armazenamento confiável, pois isso poderá causar problemas de conexão quando o RDS alternar automaticamente o certificado do servidor de banco de dados.
**nota**
O Amazon RDS Proxy e Aurora Serverless v1 usam certificados do AWS Certificate Manager (ACM). Se você estiver usando o RDS Proxy, não será necessário baixar os certificados do Amazon RDS nem atualizar as aplicações que usam conexões do RDS Proxy. Para ter mais informações, consulte [Usar TLS/SSL com o RDS Proxy](rds-proxy.howitworks.md#rds-proxy-security.tls) .
Se você estiver usando o Aurora Serverless v1, não será necessário baixar certificados do Amazon RDS. Para ter mais informações, consulte [Usar TLS/SSL com o Aurora Serverless v1](aurora-serverless.md#aurora-serverless.tls) .
Para baixar um pacote de certificados para uma Região da AWS, selecione o link da Região da AWS que hospeda o banco de dados na tabela a seguir.
| **AWS Região da** | **Pacote de certificados (PEM)** | **Pacote de certificados (PKCS7)** |
| --- | --- | --- |
| Qualquer Região da AWS comercial. | [global-bundle.pem](https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem) | [global-bundle.p7b](https://truststore.pki.rds.amazonaws.com/global/global-bundle.p7b) |
| Leste dos EUA (Norte da Virgínia) | [us-east-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/us-east-1/us-east-1-bundle.pem) | [us-east-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/us-east-1/us-east-1-bundle.p7b) |
| Leste dos EUA (Ohio) | [us-east-2-bundle.pem](https://truststore.pki.rds.amazonaws.com/us-east-2/us-east-2-bundle.pem) | [us-east-2-bundle.p7b](https://truststore.pki.rds.amazonaws.com/us-east-2/us-east-2-bundle.p7b) |
| Oeste dos EUA (N. da Califórnia) | [us-west-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/us-west-1/us-west-1-bundle.pem) | [us-west-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/us-west-1/us-west-1-bundle.p7b) |
| Oeste dos EUA (Oregon) | [us-west-2-bundle.pem](https://truststore.pki.rds.amazonaws.com/us-west-2/us-west-2-bundle.pem) | [us-west-2-bundle.p7b](https://truststore.pki.rds.amazonaws.com/us-west-2/us-west-2-bundle.p7b) |
| África (Cidade do Cabo) | [af-south-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/af-south-1/af-south-1-bundle.pem) | [af-south-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/af-south-1/af-south-1-bundle.p7b) |
| Ásia-Pacífico (Hong Kong) | [ap-east-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-east-1/ap-east-1-bundle.pem) | [ap-east-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-east-1/ap-east-1-bundle.p7b) |
| Ásia-Pacífico (Hyderabad) | [ap-south-2-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-south-2/ap-south-2-bundle.pem) | [ap-south-2-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-south-2/ap-south-2-bundle.p7b) |
| Ásia-Pacífico (Jacarta) | [ap-southeast-3-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-southeast-3/ap-southeast-3-bundle.pem) | [ap-southeast-3-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-southeast-3/ap-southeast-3-bundle.p7b) |
| Ásia-Pacífico (Malásia) | [ap-southeast-5-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-southeast-5/ap-southeast-5-bundle.pem) | [ap-southeast-5-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-southeast-5/ap-southeast-5-bundle.p7b) |
| Ásia-Pacífico (Melbourne) | [ap-southeast-4-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-southeast-4/ap-southeast-4-bundle.pem) | [ap-southeast-4-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-southeast-4/ap-southeast-4-bundle.p7b) |
| Ásia-Pacífico (Mumbai) | [ap-south-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-south-1/ap-south-1-bundle.pem) | [ap-south-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-south-1/ap-south-1-bundle.p7b) |
| Asia Pacific (Osaka) | [ap-northeast-3-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-northeast-3/ap-northeast-3-bundle.pem) | [ap-northeast-3-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-northeast-3/ap-northeast-3-bundle.p7b) |
| Ásia-Pacífico (Tailândia) | [ap-southeast-7-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-southeast-7/ap-southeast-7-bundle.pem) | [ap-southeast-7-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-southeast-7/ap-southeast-7-bundle.p7b) |
| Ásia-Pacífico (Tóquio) | [ap-northeast-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-northeast-1/ap-northeast-1-bundle.pem) | [ap-northeast-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-northeast-1/ap-northeast-1-bundle.p7b) |
| Ásia-Pacífico (Seul) | [ap-northeast-2-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-northeast-2/ap-northeast-2-bundle.pem) | [ap-northeast-2-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-northeast-2/ap-northeast-2-bundle.p7b) |
| Ásia-Pacífico (Singapura) | [ap-southeast-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-southeast-1/ap-southeast-1-bundle.pem) | [ap-southeast-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-southeast-1/ap-southeast-1-bundle.p7b) |
| Ásia-Pacífico (Sydney) | [ap-southeast-2-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-southeast-2/ap-southeast-2-bundle.pem) | [ap-southeast-2-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-southeast-2/ap-southeast-2-bundle.p7b) |
| Canadá (Central) | [ca-central-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/ca-central-1/ca-central-1-bundle.pem) | [ca-central-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ca-central-1/ca-central-1-bundle.p7b) |
| Oeste do Canadá (Calgary) | [ca-west-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/ca-west-1/ca-west-1-bundle.pem) | [ca-west-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ca-west-1/ca-west-1-bundle.p7b) |
| Europa (Frankfurt) | [eu-central-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/eu-central-1/eu-central-1-bundle.pem) | [eu-central-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/eu-central-1/eu-central-1-bundle.p7b) |
| Europa (Irlanda) | [eu-west-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/eu-west-1/eu-west-1-bundle.pem) | [eu-west-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/eu-west-1/eu-west-1-bundle.p7b) |
| Europa (Londres) | [eu-west-2-bundle.pem](https://truststore.pki.rds.amazonaws.com/eu-west-2/eu-west-2-bundle.pem) | [eu-west-2-bundle.p7b](https://truststore.pki.rds.amazonaws.com/eu-west-2/eu-west-2-bundle.p7b) |
| Europa (Milão) | [eu-south-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/eu-south-1/eu-south-1-bundle.pem) | [eu-south-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/eu-south-1/eu-south-1-bundle.p7b) |
| Europa (Paris) | [eu-west-3-bundle.pem](https://truststore.pki.rds.amazonaws.com/eu-west-3/eu-west-3-bundle.pem) | [eu-west-3-bundle.p7b](https://truststore.pki.rds.amazonaws.com/eu-west-3/eu-west-3-bundle.p7b) |
| Europa (Espanha) | [eu-south-2-bundle.pem](https://truststore.pki.rds.amazonaws.com/eu-south-2/eu-south-2-bundle.pem) | [eu-south-2-bundle.p7b](https://truststore.pki.rds.amazonaws.com/eu-south-2/eu-south-2-bundle.p7b) |
| Europa (Estocolmo) | [eu-north-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/eu-north-1/eu-north-1-bundle.pem) | [eu-north-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/eu-north-1/eu-north-1-bundle.p7b) |
| Europa (Zurique) | [eu-central-2-bundle.pem](https://truststore.pki.rds.amazonaws.com/eu-central-2/eu-central-2-bundle.pem) | [eu-central-2-bundle.p7b](https://truststore.pki.rds.amazonaws.com/eu-central-2/eu-central-2-bundle.p7b) |
| Israel (Tel Aviv) | [il-central-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/il-central-1/il-central-1-bundle.pem) | [il-central-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/il-central-1/il-central-1-bundle.p7b) |
| México (Centro) | [mx-central-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/mx-central-1/mx-central-1-bundle.pem) | [mx-central-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/mx-central-1/mx-central-1-bundle.p7b) |
| Oriente Médio (Bahrein) | [me-south-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/me-south-1/me-south-1-bundle.pem) | [me-south-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/me-south-1/me-south-1-bundle.p7b) |
| Oriente Médio (Emirados Árabes Unidos) | [me-central-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/me-central-1/me-central-1-bundle.pem) | [me-central-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/me-central-1/me-central-1-bundle.p7b) |
| América do Sul (São Paulo) | [sa-east-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/sa-east-1/sa-east-1-bundle.pem) | [sa-east-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/sa-east-1/sa-east-1-bundle.p7b) |
| Quaisquer AWS GovCloud (US) Regions. | [global-bundle.pem](https://truststore.pki.us-gov-west-1.rds.amazonaws.com/global/global-bundle.pem) | [global-bundle.p7b](https://truststore.pki.us-gov-west-1.rds.amazonaws.com/global/global-bundle.p7b) |
| AWS GovCloud (Leste dos EUA) | [us-gov-east-1-bundle.pem](https://truststore.pki.us-gov-west-1.rds.amazonaws.com/us-gov-east-1/us-gov-east-1-bundle.pem) | [us-gov-east-1-bundle.p7b](https://truststore.pki.us-gov-west-1.rds.amazonaws.com/us-gov-east-1/us-gov-east-1-bundle.p7b) |
| AWS GovCloud (Oeste dos EUA) | [us-gov-west-1-bundle.pem](https://truststore.pki.us-gov-west-1.rds.amazonaws.com/us-gov-west-1/us-gov-west-1-bundle.pem) | [us-gov-west-1-bundle.p7b](https://truststore.pki.us-gov-west-1.rds.amazonaws.com/us-gov-west-1/us-gov-west-1-bundle.p7b) |
### Visualizar o conteúdo do certificado CA
Para verificar o conteúdo do pacote de certificados da CA, use o seguinte comando:
```
keytool -printcert -v -file global-bundle.pem
```
# Alternar o certificado SSL/TLS
Os certificados rds-ca-2019 da autoridade de certificação do Amazon RDS expiraram em agosto de 2024. Se você usa ou planeja usar Secure Sockets Layer (SSL) ou Transport Layer Security (TLS) com verificação de certificado para se conectar às instâncias de banco de dados do RDS ,considere usar um dos novos certificados CA rds-ca-rsa2048-g1, rds-ca-rsa4096-g1 ou rds-ca-ecc384-g1. Se você não usa SSL/TLS com verificação de certificado no momento, é possível que ainda tenha algum certificado de CA expirado e precise atualizá-lo para um novo certificado de CA se planeja usar SSL/TLS com verificação de certificado para se conectar aos bancos de dados do RDS.
O Amazon RDS fornece novos certificados CA como uma prática recomendada de segurança da AWS. Para ter informações sobre os novos certificados e as regiões da AWS compatíveis, consulte [Usar SSL/TLS para criptografar uma conexão com um cluster de banco de dados](UsingWithRDS.SSL.md).
Para atualizar o certificado CA do seu banco de dados, use os seguintes métodos:
+ [Atualizar o certificado CA modificando a instância de banco de dados](#UsingWithRDS.SSL-certificate-rotation-updating)
+ [Atualizar seu certificado CA aplicando manutenção](#UsingWithRDS.SSL-certificate-rotation-maintenance-update)
Antes de atualizar as instâncias de banco de dados para usar o novo certificado CA, atualize os clientes ou as aplicações que se conectam aos bancos de dados do RDS.
## Considerações sobre a troca de certificados
Pense nas seguintes situações antes de trocar seu certificado:
+ O Amazon RDS Proxy e Aurora Serverless v1 usam certificados do AWS Certificate Manager (ACM). Se estiver usando o RDS Proxy, ao trocar o certificado SSL/TLS, não será necessário atualizar as aplicações que usam conexões do RDS Proxy. Para ter mais informações, consulte [Usar TLS/SSL com o RDS Proxy](rds-proxy.howitworks.md#rds-proxy-security.tls) .
+ Se você estiver usando o Aurora Serverless v1, não será necessário baixar certificados do Amazon RDS. Para ter mais informações, consulte [Usar TLS/SSL com o Aurora Serverless v1](aurora-serverless.md#aurora-serverless.tls) .
+ Se estiver usando uma aplicação Go versão 1.15 com uma instância de banco de dados criada ou atualizada para o certificado rds-ca-2019 antes de 28 de julho de 2020, você deverá atualizar o certificado novamente. Atualize o certificado para rds-ca-rsa2048-g1, rds-ca-rsa4096-g1 ou rds-ca-ecc384-g1, dependendo do seu mecanismo .
Use o comando `modify-db-instance` usando o novo identificador de certificado CA. Você pode encontrar as CAs que estão disponíveis para uma versão específica do mecanismo de banco de dados e do mecanismo de banco de dados usando o comando `describe-db-engine-versions`.
Caso você tenha criado a instância de banco de dados ou atualizado o certificado dela após 28 de julho de 2020, nenhuma ação será necessária. Para obter mais informações, consulte [Go GitHub issue \$139568](https://github.com/golang/go/issues/39568).
## Atualizar o certificado CA modificando a instância de banco de dados
O exemplo a seguir atualiza o certificado de CA de *rds-ca-2019* para *rds-ca-rsa2048-g1*. Você pode escolher um certificado diferente. Para ter mais informações, consulte [Autoridades certificadoras](UsingWithRDS.SSL.md#UsingWithRDS.SSL.RegionCertificateAuthorities)..
Atualize seu repositório confiável de aplicações para reduzir o tempo de inatividade associado à atualização do certificado de CA. Consulte mais informações sobre reinicializações associadas à alternância de certificados de CA em [Alternância automática de certificados do servidor](#UsingWithRDS.SSL-certificate-rotation-server-cert-rotation).
**Como atualizar o certificado CA modificando a instância de banco de dados**
1. Baixe o novo certificado SSL/TLS conforme descrito em [Usar SSL/TLS para criptografar uma conexão com um cluster de banco de dados](UsingWithRDS.SSL.md).
1. Atualize as aplicações para usarem o novo certificado SSL/TLS.
Os métodos para atualizar aplicações para novos certificados SSL/TLS dependem de suas aplicações específicas. Trabalhe com os desenvolvedores de aplicações para atualizar os certificados SSL/TLS para suas aplicações.
Para obter informações sobre como verificar conexões SSL/TLS e atualizar aplicações para cada mecanismo de banco de dados, consulte os seguintes tópicos:
+ [Atualizar aplicações para conexão com clusters de banco de dados do Aurora MySQL usando novos certificados TLS](ssl-certificate-rotation-aurora-mysql.md)
+ [Atualizar aplicações para conexão com clusters de banco de dados PostgreSQL do Aurora usando novos certificados SSL/TLS](ssl-certificate-rotation-aurora-postgresql.md)
Para conhecer um script de exemplo que atualiza um armazenamento confiável para um sistema operacional Linux, consulte [Script de exemplo para importar certificados para o seu armazenamento confiável](#UsingWithRDS.SSL-certificate-rotation-sample-script).
**nota**
O pacote de certificados contém certificados tanto para a CA antiga como para a nova, portanto, é possível atualizar a aplicação de maneira segura e manter a conectividade durante o período de transição. Se você estiver usando o AWS Database Migration Service a fim de migrar um banco de dados para um cluster de banco de dados, recomendamos o uso do pacote de certificados para garantir a conectividade durante a migração.
1. Modifique a instância de banco de dados para alterar a CA de **rds-ca-2019** para **rds-ca-rsa2048-g1**. Para verificar se o banco de dados requer reinicialização para atualizar os certificados de CA, use o comando [descrebe-db-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) e verifique o sinalizador `SupportsCertificateRotationWithoutRestart`.
**nota**
Reinicialize o cluster do Babelfish depois de modificar para atualizar o certificado CA.
**Importante**
Se você estiver enfrentando problemas de conectividade após a expiração do certificado, especifique a opção **Apply immediately (Aplicar imediatamente)** no console ou a opção `--apply-immediately` usando a AWS CLI. Por padrão, essa operação é programada para ser executada durante a próxima janela de manutenção.
Para definir uma substituição de CA do clusterda instância que é diferente da CA padrão do RDS, use o comando [modify-certificates](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-certificates.html) da CLI.
É possível usa o Console de gerenciamento da AWS ou a AWS CLI para alterar o certificado CA de **rds-ca-2019** para **rds-ca-rsa2048-g1** para uma instância de banco de dados .
------
#### [ Console ]
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. No painel de navegação, escolha **Bancos de dados** e selecione a instância de banco de dados que você deseja modificar.
1. Escolha **Modificar**.
![\[Modificar instância de banco de dados\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/ssl-rotate-cert-modify-aurora.png)
1. Na seção **Conectividade**, escolha **rds-ca-rsa2048-g1**.
![\[Escolher certificado CA\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/ssl-rotate-cert-ca-rsa2048-g1.png)
1. Escolha **Continue (Continuar)** e verifique o resumo de modificações.
1. Para aplicar as alterações imediatamente, escolha **Apply immediately**.
1. Na página de confirmação, revise suas alterações. Se estiverem corretas, escolha **Modificar instância de banco de dados** para salvar as alterações.
**Importante**
Ao programar essa operação, certifique-se de ter atualizado o armazenamento de confiança do lado do cliente com antecedência.
Ou escolha **Back (Voltar)** para editar as alterações ou **Cancel (Cancelar)** para cancelar as alterações.
------
#### [ AWS CLI ]
Para usar a AWS CLI a fim de alterar a CA de **rds-ca-2019** para **rds-ca-rsa2048-g1** para uma instância de banco de dados , chame o comando [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) ou [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html). Especifique o identificador da instância de banco de dados e a opção `--ca-certificate-identifier`.
Use o parâmetro `--apply-immediately` para aplicar a atualização imediatamente. Por padrão, essa operação é programada para ser executada durante a próxima janela de manutenção.
**Importante**
Ao programar essa operação, certifique-se de ter atualizado o armazenamento de confiança do lado do cliente com antecedência.
**Example**
O exemplo a seguir modifica `mydbinstance` definindo o certificado CA como `rds-ca-rsa2048-g1`.
Para Linux, macOS ou Unix:
```
aws rds modify-db-instance \
--db-instance-identifier mydbinstance \
--ca-certificate-identifier rds-ca-rsa2048-g1
```
Para Windows:
```
aws rds modify-db-instance ^
--db-instance-identifier mydbinstance ^
--ca-certificate-identifier rds-ca-rsa2048-g1
```
Se a instância exigir reinicialização, você poderá usar o comando [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) da CLI e especificar a opção `--no-certificate-rotation-restart`.
------
## Atualizar seu certificado CA aplicando manutenção
Siga as etapas a seguir para atualizar o certificado CA aplicando a manutenção.
------
#### [ Console ]
**Como atualizar o certificado CA aplicando a manutenção**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. No painel de navegação, selecione **Atualização de certificado**.
![\[Opção do painel de navegação de rotação do certificado\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/ssl-rotate-cert-certupdate.png)
A página **Bancos de dados que precisam de atualização de certificado** é exibida.
![\[Atualizar certificado CA do banco de dados\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/ssl-rotate-cert-update-multiple.png)
**nota**
Essa página mostra apenas as instâncias de banco de dados na Região da AWS atual. Se você tiver bancos de dados em mais de uma Região da AWS, confira essa página em cada Região da AWS para ver todas as instâncias de banco de dados com certificados SSL/TLS antigos.
1. Escolha a instância de banco de dados que você deseja atualizar.
Você pode programar a alternância de certificado para sua próxima janela de manutenção escolhendo **Programar**. Aplique a mudança imediatamente escolhendo **Aplicar agora**.
**Importante**
Se você tiver problemas de conectividade após a expiração do certificado, use a opção **Aplicar agora**.
1.
1. Se você escolher **Programar**, precisará confirmar a alternância do certificado de CA. Essa solicitação de confirmação também indica a janela agendada para sua atualização.
![\[Confirmar rotação de certificado\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/ssl-rotate-cert-confirm-schedule.png)
1. Se você escolher **Aplicar agora**, precisará confirmar a alternância do certificado de CA.
![\[Confirmar rotação de certificado\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/ssl-rotate-cert-confirm-now.png)
**Importante**
Antes de programar a rotação do certificado CA no banco de dados, atualize todas as aplicações cliente que usam SSL/TLS e o certificado do servidor para se conectar. Essas atualizações são específicas ao seu mecanismo de banco de dados. Depois de atualizar essas aplicações cliente, você pode confirmar a rotação do certificado CA.
Para continuar, escolha a caixa de seleção e escolha **Confirm (Confirmar)**.
1. Repita as etapas 3 e 4 para cada instância de banco de dados instância que você deseja atualizar.
------
## Alternância automática de certificados do servidor
Se a CA raiz comportar a troca automática de certificados de servidor, o RDS gerenciará automaticamente a troca do certificado do servidor de banco de dados. Como o RDS usa a mesma CA raiz para essa alternância automática, então você não precisa baixar um novo pacote de CA. Consulte [Autoridades certificadoras](UsingWithRDS.SSL.md#UsingWithRDS.SSL.RegionCertificateAuthorities).
A alternância e a validade do certificado do servidor de banco de dados dependem do mecanismo de banco de dados:
+ Se o mecanismo de banco de dados comportar a alternância sem reinicialização, o RDS alternará automaticamente o certificado do servidor de banco de dados sem exigir nenhuma ação de sua parte. O RDS tenta alternar o certificado do servidor de banco de dados em sua janela de manutenção preferida na meia-vida do respectivo certificado. O novo certificado do servidor de banco de dados é válido por 12 meses.
+ Se seu mecanismo de banco de dados não aceitar alternância sem reinicialização, o Amazon RDS tornará visível uma ação de manutenção pendente `server-certificate-rotation` por meio da API Describe-pending-maintenance-actions, na meia-vida do certificado ou pelo menos 3 meses antes da expiração. É possível aplicar a alternância usando a API apply-pending-maintenance-action. O novo certificado do servidor de banco de dados é válido por 12 meses.
Use o comando [describe-db-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) e inspecione o sinalizador `SupportsCertificateRotationWithoutRestart` para identificar se a versão do mecanismo de banco de dados é compatível com a alternância de certificado sem reinicialização. Para ter mais informações, consulte [Configurar a CA do banco de dados](UsingWithRDS.SSL.md#UsingWithRDS.SSL.RegionCertificateAuthorities.Selection) .
## Script de exemplo para importar certificados para o seu armazenamento confiável
Veja os exemplos de scripts do shell que importam o pacote de certificados para um armazenamento de confiança.
Cada script de shell de amostra usa o keytool, que faz parte do Java Development Kit (JDK). Para obter mais informações sobre como instalar o JDK, consulte o [Guia de instalação do JDK](https://docs.oracle.com/en/java/javase/17/install/overview-jdk-installation.html).
------
#### [ Linux ]
Veja a seguir um exemplo de script shell que importa o pacote de certificados para um armazenamento confiável em um sistema operacional Linux.
```
mydir=tmp/certs
if [ ! -e "${mydir}" ]
then
mkdir -p "${mydir}"
fi truststore=${mydir}/rds-truststore.jks storepassword=changeit
curl -sS "https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem"> ${mydir}/global-bundle.pem
awk 'split_after == 1 {n++;split_after=0} /-----END CERTIFICATE-----/ {split_after=1}{print > "rds-ca-" n+1 ".pem"}' < ${mydir}/global-bundle.pem
for CERT in rds-ca-*; do alias=$(openssl x509 -noout -text -in $CERT | perl -ne 'next unless /Subject:/; s/.*(CN=|CN = )//; print')
echo "Importing $alias"
keytool -import -file ${CERT} -alias "${alias}" -storepass ${storepassword} -keystore ${truststore} -noprompt
rm $CERT
done
rm ${mydir}/global-bundle.pem
echo "Trust store content is: "
keytool -list -v -keystore "$truststore" -storepass ${storepassword} | grep Alias | cut -d " " -f3- | while read alias
do expiry=`keytool -list -v -keystore "$truststore" -storepass ${storepassword} -alias "${alias}" | grep Valid | perl -ne 'if(/until: (.*?)\n/) { print "$1\n"; }'`
echo " Certificate ${alias} expires in '$expiry'"
done
```
------
#### [ macOS ]
Veja a seguir um exemplo de script do shell que importa o pacote de certificados em um armazenamento de confiança no macOS.
```
mydir=tmp/certs
if [ ! -e "${mydir}" ]
then
mkdir -p "${mydir}"
fi truststore=${mydir}/rds-truststore.jks storepassword=changeit
curl -sS "https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem"> ${mydir}/global-bundle.pem
split -p "-----BEGIN CERTIFICATE-----" ${mydir}/global-bundle.pem rds-ca-
for CERT in rds-ca-*; do alias=$(openssl x509 -noout -text -in $CERT | perl -ne 'next unless /Subject:/; s/.*(CN=|CN = )//; print')
echo "Importing $alias"
keytool -import -file ${CERT} -alias "${alias}" -storepass ${storepassword} -keystore ${truststore} -noprompt
rm $CERT
done
rm ${mydir}/global-bundle.pem
echo "Trust store content is: "
keytool -list -v -keystore "$truststore" -storepass ${storepassword} | grep Alias | cut -d " " -f3- | while read alias
do expiry=`keytool -list -v -keystore "$truststore" -storepass ${storepassword} -alias "${alias}" | grep Valid | perl -ne 'if(/until: (.*?)\n/) { print "$1\n"; }'`
echo " Certificate ${alias} expires in '$expiry'"
done
```
------
Para saber mais sobre as práticas recomendadas sobre o uso de SSL com o Amazon RDS, consulte [ Best practices for successful SSL connections to Amazon RDS for Oracle ](https://aws.amazon.com/blogs/database/best-practices-for-successful-ssl-connections-to-amazon-rds-for-oracle/).
# Privacidade do tráfego entre redes
As conexões são protegidas entre o Amazon Aurora e as aplicações on-premises e entre o Amazon Aurora e outros recursos da AWS na mesma região da AWS.
## Tráfego entre clientes de serviço e on-premises e as aplicações
Você tem duas opções de conectividade entre sua rede privada e a AWS:
+ Uma conexão AWS Site-to-Site VPN. Para ter mais informações, consulte [O que é o AWS Site-to-Site VPN?](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html)
+ Uma conexão Direct Connect. Para ter mais informações, consulte [O que é o Direct Connect?](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html)
Você obtém acesso ao Amazon Aurora pela rede usando operações de API publicadas pela AWS. Os clientes devem oferecer compatibilidade com:
+ Transport Layer Security (TLS). Exigimos TLS 1.2 e recomendamos TLS 1.3.
+ Conjuntos de criptografia com perfect forward secrecy (PFS) como DHE (Ephemeral Diffie-Hellman) ou ECDHE (Ephemeral Elliptic Curve Diffie-Hellman). A maioria dos sistemas modernos, como Java 7 e versões posteriores, comporta esses modos.
Além disso, as solicitações devem ser assinadas usando um ID da chave de acesso e uma chave de acesso secreta associada a uma entidade principal do IAM. Ou você pode usar o [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html) (AWS STS) para gerar credenciais de segurança temporárias para assinar solicitações.
# Gerenciamento de identidade e acesso no Amazon Aurora
O AWS Identity and Access Management (IAM) é um serviço da AWS service (Serviço da AWS) que ajuda um administrador a controlar com segurança o acesso aos recursos da AWS. Os administradores do IAM controlam quem pode ser *autenticado* (conectado) e *autorizado* (ter permissões) para utilizar os recursos do Amazon RDS. O IAM é um AWS service (Serviço da AWS) que pode ser usado sem custo adicional.
**Topics**
+ [Público](#security_iam_audience)
+ [Autenticar com identidades](#security_iam_authentication)
+ [Gerenciamento do acesso usando políticas](#security_iam_access-manage)
+ [Como o Amazon Aurora funciona com o IAM](security_iam_service-with-iam.md)
+ [Exemplos de políticas baseadas em identidade do Amazon Aurora](security_iam_id-based-policy-examples.md)
+ [AWSPolíticas gerenciadas pela para o Amazon RDS](rds-security-iam-awsmanpol.md)
+ [Atualizações do Amazon RDS para políticas gerenciadas pela AWS](rds-manpol-updates.md)
+ [Prevenção do problema do substituto confuso entre serviços](cross-service-confused-deputy-prevention.md)
+ [Autenticação do banco de dados do IAM](UsingWithRDS.IAMDBAuth.md)
+ [Solução de problemas de identidade e acesso do Amazon Aurora](security_iam_troubleshoot.md)
## Público
A forma de usar o AWS Identity and Access Management (IAM) varia em função do trabalho realizado no Amazon Aurora.
**Usuário do serviço**: se você usar o serviço Aurora para fazer sua tarefa, o administrador fornecerá as credenciais e as permissões de que você precisa. À medida que usar mais recursos do Aurora para fazer seu trabalho, você poderá precisar de permissões adicionais. Entender como o acesso é gerenciado pode ajudar você a solicitar as permissões corretas ao seu administrador. Se não for possível acessar um recurso no Aurora, consulte [Solução de problemas de identidade e acesso do Amazon Aurora](security_iam_troubleshoot.md).
**Administrador do serviço**: se você for o responsável pelos recursos do Aurora em sua empresa, você provavelmente terá acesso total ao Aurora. Seu trabalho é determinar quais recursos do Aurora seus funcionários devem acessar. Assim, é necessário enviar solicitações ao administrador do para alterar as permissões dos usuários de seu serviço. Revise as informações nesta página para compreender os conceitos básicos do IAM. Para saber mais sobre como sua empresa pode usar o IAM com o Aurora, consulte [Como o Amazon Aurora funciona com o IAM](security_iam_service-with-iam.md).
**Administrador**: se você é um administrador, talvez queira saber detalhes sobre como pode escrever políticas para gerenciar o acesso ao Aurora. Para visualizar exemplos de políticas baseadas em identidade do Aurora que podem ser usadas no IAM, consulte [Exemplos de políticas baseadas em identidade do Amazon Aurora](security_iam_id-based-policy-examples.md).
## Autenticar com identidades
A autenticação é a forma como fazer login na AWS usando suas credenciais de identidade. Você precisa se autenticar como o Usuário raiz da conta da AWS, como um usuário do IAM ou assumindo um perfil do IAM.
É possível fazer login como uma identidade federada usando credenciais de uma fonte de identidade, como o Centro de Identidade do AWS IAM (Centro de Identidade do IAM), autenticação única ou credenciais do Google/Facebook. Para ter mais informações sobre como fazer login, consulte [How to sign in to your Conta da AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) no *Guia do usuário do Início de Sessão da AWS*.
Para acesso programático, a AWS oferece um SDK e uma CLI para assinar solicitações criptograficamente. Para ter mais informações, consulte [AWS AWS Signature Version 4 para solicitações de API](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) no *Guia do usuário do IAM*.
### Usuário raiz de conta da AWS
Ao criar uma Conta da AWS, você começa com uma única identidade de login chamada *usuário-raiz* da Conta da AWS, que tem acesso total a todos os recursos e Serviços da AWS. É altamente recomendável não usar o usuário-raiz para tarefas diárias. Para ver as tarefas que exigem credenciais de usuário-raiz, consulte [Tarefas que exigem credenciais de usuário-raiz](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) no *Guia do usuário do IAM*.
### Identidade federada
Como prática recomendada, exija que os usuários humanos usem a federação com um provedor de identidades para acessar a Serviços da AWS usando credenciais temporárias.
*Identidade federada* é um usuário do seu diretório empresarial, de um provedor de identidades da web ou do Directory Service que acessa Serviços da AWS usando credenciais de uma fonte de identidade. As identidades federadas assumem perfis que oferecem credenciais temporárias.
Para o gerenciamento de acesso centralizado, é recomendável usar o Centro de Identidade do AWS IAM. Para obter mais informações, consulte [O que é o IAM Identity Center?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) no *Guia do usuário do Centro de Identidade do AWS IAM*.
### Usuários e grupos do IAM
*[Usuário do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)* é uma identidade com permissões específicas a uma única pessoa ou aplicação. Recomendamos usar credenciais temporárias, em vez de usuários do IAM com credenciais de longo prazo. Para obter mais informações, consulte [Exigir que os usuários humanos usem a federação com um provedor de identidade para acessar a AWS usando credenciais temporárias](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) no *Guia do usuário do IAM*.
Um [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) especifica um conjunto de usuários do IAM e facilita o gerenciamento de permissões para grandes conjuntos de usuários. Para ter mais informações, consulte [Casos de uso de usuários do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) no *Guia do usuário do IAM*.
Você pode se autenticar no cluster de banco de dados usando a autenticação de banco de dados do IAM.
A autenticação do banco de dados do IAM funciona com o Aurora. Para obter mais informações sobre a autenticação no cluster usando o IAM, consulte [Autenticação do banco de dados do IAM](UsingWithRDS.IAMDBAuth.md).
### Perfis do IAM
Um *[perfil do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* é uma identidade na Conta da AWS que tem permissões específicas. Ela é semelhante a um usuário, mas não está associada a uma pessoa específica. É possível presumir temporariamente um perfil do IAM no Console de gerenciamento da AWS [alternando perfis](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html). É possível presumir um perfil chamando uma operação de API da AWS CLI ou da AWS, ou usando um URL personalizado. Para obter mais informações sobre métodos para o uso de perfis, consulte [Utilizar perfis do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html) no *Guia do usuário do IAM*.
Funções do IAM com credenciais temporárias são úteis nas seguintes situações:
+ **Permissões temporárias para usuários**: um usuário pode assumir um perfil do IAM para obter temporariamente permissões diferentes para uma tarefa específica.
+ **Acesso de usuário federado**: para atribuir permissões a identidades federadas, é possível criar um perfil e definir permissões para ele. Quando uma identidade federada é autenticada, essa identidade é associada ao perfil e recebe as permissões definidas por ele. Para ter mais informações sobre perfis para federação, consulte [Criar um perfil para um provedor de identidade de terceiros (federação)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp.html) no *Guia do usuário do IAM*. Se usar o Centro de Identidade do IAM, configure um conjunto de permissões. Para controlar o que suas identidades podem acessar após a autenticação, o Centro de Identidade do IAM correlaciona o conjunto de permissões a um perfil no IAM. Para obter informações sobre conjuntos de permissões, consulte [Conjuntos de Permissões](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html) no *Guia do Usuário do Centro de Identidade do AWS IAM*.
+ **Acesso entre contas**: é possível usar um perfil do IAM para permitir que alguém (uma entidade principal confiável) em outra conta acesse recursos em sua conta. Os perfis são a principal forma de conceder acesso entre contas. No entanto, alguns Serviços da AWS permitem que você anexe uma política diretamente a um recurso (em vez de usar um perfil como proxy). Para saber a diferença entre perfis e políticas baseadas em recurso para acesso entre contas, consulte [Como os perfis do IAM diferem das políticas baseadas em recurso](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html) no *Guia do usuário do IAM*.
+ **Acesso entre serviços**: alguns Serviços da AWS usam atributos em outros Serviços da AWS. Por exemplo, quando você faz uma chamada em um serviço, é comum que esse serviço execute aplicações no Amazon EC2 ou armazene objetos no Amazon S3. Um serviço pode fazer isso usando as permissões da entidade principal da chamada, usando um perfil de serviço ou um perfil vinculado ao serviço.
+ **Sessões de acesso direto**: as sessões de acesso direto (FAS) usam as permissões da entidade principal chamando um AWS service (Serviço da AWS), além de solicitar que o AWS service (Serviço da AWS) faça solicitações a serviços de downstream. Para obter detalhes da política ao fazer solicitações de FAS, consulte [Sessões de acesso direto](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html).
+ **Perfil de serviço**: um perfil de serviço é um [perfil do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) que um serviço assume para executar ações em seu nome. Um administrador do IAM pode criar, modificar e excluir um perfil de serviço do IAM. Para obter mais informações, consulte [Criar um perfil para delegar permissões a um AWS service (Serviço da AWS)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) no *Guia do Usuário do IAM*.
+ **Perfil vinculado a serviço**: um perfil vinculado a serviço é um tipo de perfil de serviço vinculado a um AWS service (Serviço da AWS). O serviço pode presumir o perfil para executar uma ação em seu nome. Perfis vinculadas ao serviço aparecem em sua Conta da AWS e são de propriedade do serviço. Um administrador do IAM pode visualizar, mas não editar as permissões para perfis vinculados a serviço.
+ **Aplicações em execução no Amazon EC2**: é possível usar um perfil do IAM para gerenciar credenciais temporárias para aplicações em execução em uma instância do EC2 e fazer solicitações da AWS CLI ou da API da AWS. É preferível fazer isso a armazenar chaves de acesso na instância do EC2. Para atribuir um perfil da AWS a uma instância do EC2 e disponibilizá-la para todas as suas aplicações, crie um perfil de instância que esteja anexado a ela. Um perfil de instância contém o perfil e permite que os programas em execução na instância do EC2 obtenham credenciais temporárias. Para mais informações, consulte [Utilizar um perfil do IAM para conceder permissões a aplicações em execução nas instâncias do Amazon EC2](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html) no *Guia do usuário do IAM*.
Para saber se você deve usar perfis do IAM, consulte [Quando criar um perfil do IAM (em vez de um usuário)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose_role) no *Guia do usuário do IAM*.
## Gerenciamento do acesso usando políticas
Você controla o acesso na AWS criando e anexando políticas às identidades do IAM ou aos recursos da AWS. Uma política é um objeto na AWS que, quando associada a uma identidade ou a um recurso, define suas permissões. A AWS avalia essas políticas quando uma entidade (usuário raiz, usuário ou perfil do IAM) faz uma solicitação. As permissões nas políticas determinam se a solicitação será permitida ou negada. A maioria das políticas é armazenada na AWS como documentos JSON. Para obter mais informações sobre a estrutura e o conteúdo de documentos de políticas JSON, consulte [Visão geral das políticas JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) no *Guia do usuário do IAM*.
Um administrador pode usar políticas para especificar quem tem acesso aos recursos da AWS e quais ações essas pessoas podem executar nesses recursos. Cada entidade do IAM (conjunto de permissões ou perfil) começa sem permissões. Em outras palavras, por padrão, os usuários não podem fazer nada, nem mesmo alterar sua própria senha. Para dar permissão a um usuário para fazer algo, um administrador deve anexar uma política de permissões ao usuário. Ou o administrador pode adicionar o usuário a um grupo que tenha as permissões pretendidas. Quando um administrador concede permissões a um grupo, todos os usuários desse grupo recebem essas permissões.
As políticas do IAM definem permissões para uma ação, independentemente do método usado para executar a operação. Por exemplo, suponha que você tenha uma política que permite a ação `iam:GetRole`. Um usuário com essa política pode obter informações de perfis do Console de gerenciamento da AWS, da AWS CLI ou da API AWS.
### Políticas baseadas em identidade
As políticas baseadas em identidade são documentos JSON de políticas de permissões que você pode anexar a uma identidade, como um conjunto de permissões ou um perfil. Essas políticas controlam quais ações cada identidade pode realizar, em quais recursos e em que condições. Para saber como criar uma política baseada em identidade, consulte [Criar políticas do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) no *Guia do usuário do IAM*.
As políticas baseadas em identidade podem ser categorizadas ainda adicionalmente como *políticas em linha* ou *políticas gerenciadas*. As políticas em linha são anexadas diretamente a um único conjunto de permissões ou perfil. As políticas gerenciadas são políticas independentes que podem ser anexadas a vários conjuntos de permissões e perfis em sua conta da AWS. As políticas gerenciadas incluem políticas gerenciadas pela AWS e políticas gerenciadas pelo cliente. Para saber como escolher entre uma política gerenciada ou uma política em linha, consulte [Escolher entre políticas gerenciadas e políticas em linha](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#choosing-managed-or-inline) no *Guia do Usuário do IAM*.
Para obter informações sobre políticas gerenciadas pela AWS específicas do Amazon Aurora, consulte [AWSPolíticas gerenciadas pela para o Amazon RDS](rds-security-iam-awsmanpol.md).
### Outros tipos de política
A AWS oferece compatibilidade com tipos de política menos comuns. Esses tipos de política podem definir o máximo de permissões concedidas a você pelos tipos de política mais comuns.
+ **Limites de permissões**: um limite de permissões é um recurso avançado no qual você define o máximo de permissões que uma política baseada em identidade pode conceder a uma entidade do IAM (conjunto de permissões ou perfil). É possível definir um limite de permissões para uma entidade. As permissões resultantes são a interseção das políticas baseadas em identidade da entidade e seus limites de permissões. As políticas baseadas em recurso que especificam o conjunto de permissões ou o perfil no campo `Principal` não são limitadas pelo limite de permissões. Uma negação explícita em qualquer uma dessas políticas substitui a permissão. Para obter mais informações sobre limites de permissões, consulte [Limites de permissões para identidades do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) no *Guia do usuário do IAM*.
+ **Políticas de controle de serviço (SCPs)**: SCPs são políticas JSON que especificam as permissões máximas para uma organização ou unidade organizacional (UO) no AWS Organizations. O AWS Organizations é um serviço para agrupar e gerenciar centralmente várias contas da AWS pertencentes à sua empresa. Se você habilitar todos os recursos em uma organização, poderá aplicar políticas de controle de serviço (SCPs) a qualquer uma ou a todas as contas. O SCP limita as permissões para entidades em contas membro, o que inclui cada Usuário raiz da conta da AWS. Para obter mais informações sobre o Organizações e SCPs, consulte [Como os SCPs Funcionam](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_about-scps.html) no *Manual do Usuário do AWS Organizations*.
+ **Políticas de sessão**: são políticas avançadas que você transmite como um parâmetro quando cria de forma programática uma sessão temporária para um perfil ou um usuário federado. As permissões da sessão resultante são a interseção entre as políticas baseadas em identidade dos conjuntos de permissões ou do perfil e as políticas de sessão. As permissões também podem ser provenientes de uma política baseada em recursos. Uma negação explícita em qualquer uma dessas políticas substitui a permissão. Para obter mais informações, consulte [Políticas de sessão](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) no *Guia do usuário do IAM*.
### Vários tipos de política
Quando vários tipos de política são aplicáveis a uma solicitação, é mais complicado compreender as permissões resultantes. Para saber como a AWS determina se deve permitir ou não uma solicitação quando há vários tipos de política envolvidos, consulte [Lógica da avaliação de políticas](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) no *Guia do usuário do IAM*.
# Como o Amazon Aurora funciona com o IAM
Antes de usar o IAM para gerenciar o acesso ao Amazon Aurora, você precisa entender quais recursos do IAM estão disponíveis para uso com o Aurora.
A tabela a seguir lista os recursos do IAM que você pode usar com o Amazon Aurora:
| Recurso do IAM | Compatibilidade do Amazon Aurora |
| --- | --- |
| [Políticas baseadas em identidade](#security_iam_service-with-iam-id-based-policies) | Sim |
| [Políticas baseadas em recurso](#security_iam_service-with-iam-resource-based-policies) | Não |
| [Ações de políticas](#security_iam_service-with-iam-id-based-policies-actions) | Sim |
| [Recursos de políticas](#security_iam_service-with-iam-id-based-policies-resources) | Sim |
| [Chaves de condição de política (específicas do serviço)](#UsingWithRDS.IAM.Conditions) | Sim |
| [ACLs](#security_iam_service-with-iam-acls) | Não |
| [Controle de acesso baseado em atributos (ABAC) (tags em políticas)](#security_iam_service-with-iam-tags) | Sim |
| [Credenciais temporárias](#security_iam_service-with-iam-roles-tempcreds) | Sim |
| [Sessões de acesso direto](#security_iam_service-with-iam-principal-permissions) | Sim |
| [Perfis de serviço](#security_iam_service-with-iam-roles-service) | Sim |
| [Perfis vinculados a serviço](#security_iam_service-with-iam-roles-service-linked) | Sim |
Para obter uma visão de alto nível de como o Amazon Aurora e outros serviços da AWS funcionam com o IAM, consulte [Serviços da AWS compatíveis com o IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) no *Guia do usuário do IAM*.
**Topics**
+ [Políticas baseadas em identidade do Aurora](#security_iam_service-with-iam-id-based-policies)
+ [Políticas baseadas em recursos do Aurora](#security_iam_service-with-iam-resource-based-policies)
+ [Ações de políticas para o Aurora](#security_iam_service-with-iam-id-based-policies-actions)
+ [Recursos de políticas do Aurora](#security_iam_service-with-iam-id-based-policies-resources)
+ [Chaves de condição de políticas do Aurora](#UsingWithRDS.IAM.Conditions)
+ [Listas de controle de acesso (ACLs) no Aurora](#security_iam_service-with-iam-acls)
+ [Controle de acesso baseado em atributos (ABAC) em políticas com tags do Aurora](#security_iam_service-with-iam-tags)
+ [Usar credenciais temporárias com o Aurora](#security_iam_service-with-iam-roles-tempcreds)
+ [Sessões de acesso direto para o Aurora](#security_iam_service-with-iam-principal-permissions)
+ [Perfis de serviço do Aurora](#security_iam_service-with-iam-roles-service)
+ [Funções vinculadas a serviço do Aurora](#security_iam_service-with-iam-roles-service-linked)
## Políticas baseadas em identidade do Aurora
**Compatível com políticas baseadas em identidade:** sim.
As políticas baseadas em identidade são documentos de políticas de permissões JSON que podem ser anexados a uma identidade, como usuário do IAM, grupo de usuários ou perfil. Essas políticas controlam quais ações os usuários e perfis podem realizar, em quais recursos e em que condições. Para saber como criar uma política baseada em identidade, consulte [Definir permissões personalizadas do IAM com as políticas gerenciadas pelo cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) no *Guia do Usuário do IAM*.
Com as políticas baseadas em identidade do IAM, é possível especificar ações e recursos permitidos ou negados, assim como as condições sob as quais as ações são permitidas ou negadas. Para saber mais sobre todos os elementos que podem ser usados em uma política JSON, consulte [Referência de elemento de política JSON do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) no *Guia do usuário do IAM*.
### Exemplos de políticas baseadas em identidade do Aurora
Para visualizar exemplos de políticas baseadas em identidade do Aurora, consulte [Exemplos de políticas baseadas em identidade do Amazon Aurora](security_iam_id-based-policy-examples.md).
## Políticas baseadas em recursos do Aurora
**Compatível com políticas baseadas em recursos:** não.
Políticas baseadas em recursos são documentos de políticas JSON que você anexa a um recurso. São exemplos de políticas baseadas em recursos as *políticas de confiança de perfil* do IAM e as *políticas de bucket* do Amazon S3. Em serviços compatíveis com políticas baseadas em recursos, os administradores de serviço podem usá-las para controlar o acesso a um recurso específico. Para o atributo ao qual a política está anexada, a política define quais ações uma entidade principal especificado pode executar nesse atributo e em que condições. É necessário [especificar uma entidade principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) em uma política baseada em recursos. As entidades principais podem incluir contas, usuários, perfis, usuários federados ou Serviços da AWS.
Para permitir o acesso entre contas, é possível especificar uma conta inteira ou as entidades do IAM em outra conta como a entidade principal em uma política baseada em recursos. Consulte mais informações em [Acesso a recursos entre contas no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) no *Guia do usuário do IAM*.
## Ações de políticas para o Aurora
**Compatível com ações de políticas:** sim.
Os administradores podem usar as políticas JSON da AWS para especificar quem tem acesso a quê. Ou seja, qual **entidade principal** pode executar **ações** em quais **recursos** e em que **condições**.
O elemento `Action` de uma política JSON descreve as ações que podem ser usadas para permitir ou negar acesso em uma política. Incluem ações em uma política para conceder permissões para executar a operação associada.
As ações de políticas no Aurora usam o seguinte prefixo antes da ação: `rds:`. Por exemplo, para conceder a alguém permissão para descrever instâncias de banco de dados com a operação da API `DescribeDBInstances` do Amazon RDS, inclua a ação `rds:DescribeDBInstances` na política. As instruções de política devem incluir um elemento `Action` ou `NotAction`. O Aurora define seu próprio conjunto de ações que descrevem as tarefas que você pode executar com esse serviço.
Para especificar várias ações em uma única declaração, separe-as com vírgulas, conforme a seguir.
```
"Action": [
"rds:action1",
"rds:action2"
```
Você também pode especificar várias ações utilizando caracteres curinga (\$1). Por exemplo, para especificar todas as ações que começam com a palavra `Describe`, inclua a ação a seguir:
```
"Action": "rds:Describe*"
```
Para obter uma lista de ações do Aurora, consulte [Ações definidas pelo Amazon RDS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-actions-as-permissions)* na *Referência de autorização do serviço.
## Recursos de políticas do Aurora
**Compatível com recursos de políticas:** sim.
Os administradores podem usar as políticas JSON da AWS para especificar quem tem acesso a quê. Ou seja, qual **entidade principal** pode executar **ações** em quais **recursos** e em que **condições**.
O elemento de política JSON `Resource` especifica o objeto ou os objetos aos quais a ação se aplica. Como prática recomendada, especifique um recurso usando seu [nome do recurso da Amazon (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). Para ações que não oferecem compatibilidade com permissões em nível de recurso, use um curinga (\$1) para indicar que a instrução se aplica a todos os recursos.
```
"Resource": "*"
```
O recurso de instância de banco de dados tem o nome do recurso da Amazon (ARN) a seguir.
```
arn:${Partition}:rds:${Region}:${Account}:{ResourceType}/${Resource}
```
Para obter mais informações sobre o formato de ARNs, consulte [Nomes de recursos da Amazon (ARNs) e namespaces de serviços da AWS](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html).
Por exemplo, para especificar a instância de banco de dados `dbtest` em sua instrução, use o ARN a seguir.
```
"Resource": "arn:aws:rds:us-west-2:123456789012:db:dbtest"
```
Para especificar todas as instâncias de banco de dados que pertencem a uma conta específica, use o caractere curinga (\$1).
```
"Resource": "arn:aws:rds:us-east-1:123456789012:db:*"
```
Algumas operações da API do RDS, como as operações para a criação de recursos, não podem ser executadas em um recurso específico. Nesses casos, use o caractere curinga (\$1).
```
"Resource": "*"
```
Muitas operações da API do Amazon RDS envolvem vários recursos. Por exemplo, o `CreateDBInstance` cria uma instância de banco de dados. Você pode especificar que um usuário do deve usar um grupo de segurança e um grupo de parâmetros específicos ao criar uma instância de banco de dados. Para especificar vários recursos em uma única declaração, separe os ARNs com vírgulas.
```
"Resource": [
"resource1",
"resource2"
```
Para ver uma lista dos tipos de recursos do Aurora e seus ARNs, consulte [Tipos de recursos definidos pelo Amazon RDS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-resources-for-iam-policies) na *Referência de autorização do serviço*. Para saber com quais ações você pode especificar o ARN de cada recurso, consulte [Ações definidas pelo Amazon RDS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-actions-as-permissions).
## Chaves de condição de políticas do Aurora
**Compatível com chaves de condição de política específicas de serviço:** sim.
Os administradores podem usar as políticas JSON da AWS para especificar quem tem acesso a quê. Ou seja, qual **entidade principal** pode executar **ações** em quais **recursos** e em que **condições**.
O elemento `Condition` especifica quando as instruções são executadas com base em critérios definidos. É possível criar expressões condicionais que usem [agentes de condição](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), como “igual a” ou “menor que”, para fazer a condição da política corresponder aos valores na solicitação. Para ver todas as chaves de condição globais da AWS, consulte [Chaves de contexto de condição globais da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) no *Guia do usuário do IAM*.
O Aurora define seu próprio conjunto de chaves de condição e também é compatível com o uso de algumas chaves de condição globais. Para ver todas as chaves de condição globais da AWS, consulte [Chaves de contexto de condição globais da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) no *Guia do usuário do IAM*.
Todas as operações da API do RDS oferecem suporte à chave de condição `aws:RequestedRegion`.
Para ver uma lista das chaves de condição do Aurora, consulte [Chaves de condição do Amazon RDS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-policy-keys) na *Referência de autorização do serviço*. Para saber com quais ações e recursos você pode usar a chave de condição, consulte [Ações definidas pelo Amazon RDS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-actions-as-permissions).
## Listas de controle de acesso (ACLs) no Aurora
**Compatível com listas de controle de acesso (ACLs):** não.
As listas de controle de acesso (ACLs) controlam quais entidades principais (membros, usuários ou perfis da conta) têm permissões para acessar um recurso. As ACLs são semelhantes às políticas baseadas em recursos, embora não usem o formato de documento de política JSON.
## Controle de acesso baseado em atributos (ABAC) em políticas com tags do Aurora
**Compatível com tags de controle de acesso baseado em atributos (ABAC) em políticas:** sim.
O controle de acesso por atributo (ABAC) é uma estratégia de autorização que define permissões com base em atributos chamados de tags. Você pode anexar tags a entidades do IAM e recursos da AWS e, em seguida, projetar políticas de ABAC para permitir operações quando a tag da entidade principal corresponder à tag no recurso.
Para controlar o acesso baseado em tags, forneça informações sobre as tags no [elemento de condição](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) de uma política usando as `aws:ResourceTag/key-name`, `aws:RequestTag/key-name` ou chaves de condição `aws:TagKeys`.
Se um serviço for compatível com as três chaves de condição para cada tipo de recurso, o valor será **Sim** para o serviço. Se um serviço for compatível com as três chaves de condição somente para alguns tipos de recursos, o valor será **Parcial**
Para saber mais sobre o ABAC, consulte [Definir permissões com autorização do ABAC](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) no *Guia do usuário do IAM*. Para visualizar um tutorial com etapas para configurar o ABAC, consulte [Usar controle de acesso por atributo (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) no *Guia do usuário do IAM*.
Para obter mais informações sobre recursos de marcação do Aurora, consulte [Especificar condições: usar tags personalizadas](UsingWithRDS.IAM.SpecifyingCustomTags.md). Para visualizar um exemplo de política baseada em identidade para limitar o acesso a um recurso baseado em tags desse recurso, consulte [Conceder permissão para ações em um recurso com uma tag específica com dois valores diferentes](security_iam_id-based-policy-examples-create-and-modify-examples.md#security_iam_id-based-policy-examples-grant-permissions-tags).
## Usar credenciais temporárias com o Aurora
**Compatível com credenciais temporárias:** sim.
As credenciais temporárias dão acesso de curto prazo aos recursos da AWS e são criadas automaticamente quando você usa a federação ou alterna os perfis. A AWS recomenda a você gerar credenciais temporárias dinamicamente, em vez de usar chaves de acesso de longo prazo. Para ter mais informações, consulte [Credenciais de segurança temporárias no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) e [Serviços da Serviços da AWS que funcionam com o IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) no *Guia do usuário do IAM*.
## Sessões de acesso direto para o Aurora
**Compatível com sessões de acesso direto:** sim.
As sessões de acesso direto (FAS) usam as permissões da entidade principal chamando um AWS service (Serviço da AWS), bem como o AWS service (Serviço da AWS) solicitante, para fazer solicitações a serviços subsequentes. Para obter detalhes da política ao fazer solicitações de FAS, consulte [Sessões de acesso direto](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html).
## Perfis de serviço do Aurora
**Compatível com perfis de serviço:** sim.
O perfil de serviço é um [perfil do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) que um serviço assume para executar ações em seu nome. Um administrador do IAM pode criar, modificar e excluir um perfil de serviço do IAM. Para saber mais, consulte [Criar um perfil para delegar permissões a um AWS service (Serviço da AWS)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) no *Guia do Usuário do IAM*.
**Atenção**
A alteração das permissões de uma função de serviço pode interromper a funcionalidade do Aurora. Edite perfis de serviço somente quando o Aurora fornecer orientação para isso.
## Funções vinculadas a serviço do Aurora
**Compatível com perfis vinculados a serviços:** sim.
Um perfil vinculado a serviço é um tipo de perfil de serviço vinculado a um AWS service (Serviço da AWS). O serviço pode presumir o perfil de executar uma ação em seu nome. Perfis vinculados ao serviço aparecem em sua Conta da AWS e são de propriedade do serviço. Um administrador do IAM pode visualizar, mas não editar as permissões para perfis vinculados ao serviço.
Para obter detalhes sobre como usar funções vinculadas o serviço do Aurora, consulte [Usar funções vinculadas ao serviço do Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md).
# Exemplos de políticas baseadas em identidade do Amazon Aurora
Por padrão, os conjuntos de permissões e perfis não têm permissão para criar nem modificar recursos do Aurora. Eles também não podem executar tarefas usando o Console de gerenciamento da AWS, a AWS CLI ou uma API da AWS. Um administrador deve criar políticas do IAM que concedam aos conjuntos de permissões e perfis permissão para executar operações de API específicas nos recursos especificados de que precisam. Depois, o administrador deve anexar essas políticas aos conjuntos de permissões e perfis que exigem essas permissões.
Para saber como criar uma política baseada em identidade do IAM utilizando esses exemplos de documentos de política JSON, consulte [Criar políticas na guia JSON ](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor) no *Guia do usuário do IAM*.
**Topics**
+ [Práticas recomendadas de política](#security_iam_service-with-iam-policy-best-practices)
+ [Usar o console do Aurora](#security_iam_id-based-policy-examples-console)
+ [Permissões necessárias para usar o console](#UsingWithRDS.IAM.RequiredPermissions.Console)
+ [Permitir que os usuários visualizem suas próprias permissões](#security_iam_id-based-policy-examples-view-own-permissions)
+ [Políticas de permissão para criar, modificar e excluir recursos no Aurora](security_iam_id-based-policy-examples-create-and-modify-examples.md)
+ [Políticas de exemplo: usar chaves de condição](UsingWithRDS.IAM.Conditions.Examples.md)
+ [Especificar condições: usar tags personalizadas](UsingWithRDS.IAM.SpecifyingCustomTags.md)
+ [Conceder permissão para marcar recursos do Aurora durante a criação](security_iam_id-based-policy-examples-grant-permissions-tags-on-create.md)
## Práticas recomendadas de política
As políticas baseadas em identidade determinam se alguém pode criar, acessar ou excluir recursos do Amazon RDS em sua conta. Essas ações podem incorrer em custos para sua Conta da AWS. Ao criar ou editar políticas baseadas em identidade, siga estas diretrizes e recomendações:
+ **Comece com as políticas gerenciadas pela AWS e avance para as permissões de privilégio mínimo**: para começar a conceder permissões a seus usuários e workloads, use as *políticas gerenciadas pela AWS*, que concedem permissões para muitos casos de uso comuns. Elas estão disponíveis em seus Conta da AWS. Recomendamos que você reduza ainda mais as permissões definindo políticas gerenciadas pelo cliente da AWS que são específicas para seus casos de uso. Para saber mais, consulte [Políticas gerenciadas pela AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) ou [Políticas gerenciadas pela AWS para funções de trabalho](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) no *Guia do usuário do IAM*.
+ **Aplique permissões de privilégio mínimo**: ao definir permissões com as políticas do IAM, conceda apenas as permissões necessárias para executar uma tarefa. Você faz isso definindo as ações que podem ser executadas em recursos específicos sob condições específicas, também conhecidas como *permissões de privilégio mínimo*. Para saber mais sobre como usar o IAM para aplicar permissões, consulte [Políticas e permissões no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) no *Guia do usuário do IAM*.
+ **Use condições nas políticas do IAM para restringir ainda mais o acesso**: é possível adicionar uma condição às políticas para limitar o acesso a ações e recursos. Por exemplo, é possível escrever uma condição de política para especificar que todas as solicitações devem ser enviadas usando SSL. Também pode usar condições para conceder acesso a ações de serviço, se elas forem usadas por meio de um AWS service (Serviço da AWS) específico, como o CloudFormation. Para saber mais, consulte [Elementos da política JSON do IAM: condição](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) no *Guia do usuário do IAM*.
+ **Use o IAM Access Analyzer para validar suas políticas do IAM a fim de garantir permissões seguras e funcionais**: o IAM Access Analyzer valida as políticas novas e existentes para que elas sigam a linguagem de política do IAM (JSON) e as práticas recomendadas do IAM. O IAM Access Analyzer oferece mais de cem verificações de política e recomendações práticas para ajudar a criar políticas seguras e funcionais. Para saber mais, consulte [Validação de políticas do IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) no *Guia do Usuário do IAM*.
+ **Exigir autenticação multifator (MFA)**: se houver um cenário que exija usuários do IAM ou um usuário raiz em sua Conta da AWS, ative a MFA para obter segurança adicional. Para exigir MFA quando as operações de API forem chamadas, adicione condições de MFA às suas políticas. Para saber mais, consulte [Configuração de acesso à API protegido por MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) no *Guia do Usuário do IAM*.
Para saber mais sobre as práticas recomendadas do IAM, consulte [Práticas recomendadas de segurança no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) no *Guia do usuário do IAM*.
## Usar o console do Aurora
Para acessar o console do Amazon Aurora, você deve ter um conjunto mínimo de permissões. Essas permissões devem permitir que você liste e visualize detalhes sobre os recursos do Amazon Aurora em sua Conta da AWS. Caso crie uma política baseada em identidade mais restritiva que as permissões mínimas necessárias, o console não funcionará como pretendido para entidades (usuários ou perfis) com essa política.
Não é necessário conceder permissões mínimas do console para usuários que fazem chamadas somente à AWS CLI ou à API do AWS. Em vez disso, permita o acesso somente às ações que corresponderem a operação da API que você estiver tentando executar.
Para garantir que essas entidades ainda possam usar o console do Aurora, anexe também a seguinte política gerenciada pela AWS às entidades.
```
AmazonRDSReadOnlyAccess
```
Para obter mais informações, consulte [Adicionar permissões a um usuário](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) no *Guia do usuário do IAM*.
## Permissões necessárias para usar o console
Para um usuário trabalhar com o console, esse usuário deve ter um conjunto de permissões mínimo. Essas permissões permitem que o usuário descreva os recursos do Amazon Aurora para a conta da AWS e forneça outras informações relacionadas, inclusive informações de segurança e rede do Amazon EC2.
Se você criar uma política do IAM que seja mais restritiva que as permissões mínimas necessárias, o console não funcionará como pretendido para os usuários com essa política do IAM. Para garantir que esses usuários ainda consigam usar o console, associe também a política gerenciada `AmazonRDSReadOnlyAccess` ao usuário, conforme descrito em [Gerenciamento do acesso usando políticas](UsingWithRDS.IAM.md#security_iam_access-manage).
Não é necessário conceder permissões mínimas do console para usuários que fazem chamadas somente à AWS CLI ou à API do Amazon RDS.
A seguinte política concede acesso completo a todos os recursos do Amazon Aurora para a conta raiz da AWS:
```
AmazonRDSFullAccess
```
## Permitir que os usuários visualizem suas próprias permissões
Este exemplo mostra como criar uma política que permita que os usuários do IAM visualizem as políticas gerenciadas e em linha anexadas a sua identidade de usuário. Essa política inclui permissões para concluir essa ação no console ou de forma programática usando a AWS CLI ou a API da AWS.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
# Políticas de permissão para criar, modificar e excluir recursos no Aurora
As seções a seguir apresentam exemplos de políticas de permissão que concedem e restringem o acesso aos recursos:
## Permitir que um usuário crie instâncias de Bancos de Dados em uma conta da AWS
Veja a seguir um exemplo de política que permite à conta com o ID `123456789012` criar instâncias de banco de dados para a sua conta da AWS. A política exige que o nome da nova instância de banco de dados comece com `test`. A nova instância de banco de dados também deve usar o mecanismo de banco de dados MySQL e a classe de instância de banco de dados `db.t2.micro`. Além disso, a nova instância de banco de dados deve usar um grupo de opções e um grupo de parâmetros de banco de dados que começa com `default` e deve usar o grupo de sub-redes `default`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowCreateDBInstanceOnly",
"Effect": "Allow",
"Action": [
"rds:CreateDBInstance"
],
"Resource": [
"arn:aws:rds:*:123456789012:db:test*",
"arn:aws:rds:*:123456789012:og:default*",
"arn:aws:rds:*:123456789012:pg:default*",
"arn:aws:rds:*:123456789012:subgrp:default"
],
"Condition": {
"StringEquals": {
"rds:DatabaseEngine": "mysql",
"rds:DatabaseClass": "db.t2.micro"
}
}
}
]
}
```
------
A política inclui uma única instrução que especifica as seguintes permissões para o usuário do :
+ A política permite que a conta crie uma instância de banco de dados usando a operação de API [CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) (isso também se aplica ao comando [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) da AWS CLI e ao Console de gerenciamento da AWS).
+ O elemento `Resource` especifica que o usuário pode realizar ações em ou com recursos. Você especifica recursos usando um nome de recurso da Amazon (ARN). O ARN inclui o nome do serviço ao qual o recurso pertence (`rds`), a região da AWS (`*` indica qualquer região neste exemplo), o número de conta da AWS (`123456789012` é o número de conta neste exemplo) e o tipo de recurso. Para obter mais informações sobre como criar ARNs, consulte [Nomes de recurso da Amazon (ARNs) no Amazon RDS](USER_Tagging.ARN.md).
O elemento `Resource` neste exemplo especifica as restrições da política a seguir em recursos para o usuário:
+ O identificador de instância de banco de dados para a nova instância de banco de dados deve começar com `test` (por exemplo, `testCustomerData1`, `test-region2-data`).
+ O grupo de opções para a nova instância de banco de dados deve começar com `default`.
+ O grupo de parâmetros de banco de dados para a nova instância de banco de dados deve começar com `default`.
+ O grupo de sub-redes para a nova instância de banco de dados deve ser o grupo de sub-redes `default`.
+ O elemento `Condition` especifica que o mecanismo de banco de dados deve ser MySQL e a classe da instância de banco de dados deve ser `db.t2.micro`. O elemento `Condition` especifica as condições quando uma política deve entrar em vigor. Você pode adicionar permissões ou restrições usando o elemento `Condition`. Para obter mais informações sobre como especificar condições, consulte [Chaves de condição de políticas do Aurora](security_iam_service-with-iam.md#UsingWithRDS.IAM.Conditions). Este exemplo especifica condições `rds:DatabaseEngine` e `rds:DatabaseClass`. Para obter informações sobre valores de condição válidos para o `rds:DatabaseEngine`, consulte a lista no parâmetro `Engine` em [CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html). Para obter informações sobre os valores de condição válidos para `rds:DatabaseClass`, consulte [Mecanismos de banco de dados compatíveis para classes de instância de banco de dados](Concepts.DBInstanceClass.SupportAurora.md).
A política não especifica o elemento `Principal` porque, em uma política baseada em identidade, não se especifica o principal que obtém as permissões. Quando você anexar uma política um usuário, o usuário será a entidade principal implícita. Quando você anexa uma política de permissão a um perfil do IAM, o principal identificado na política de confiança do perfil obtém as permissões.
Para obter uma lista de ações do Aurora, consulte [Ações definidas pelo Amazon RDS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-actions-as-permissions)* na *Referência de autorização do serviço.
## Permitir que um usuário execute qualquer ação de descrição em qualquer recurso do RDS
A seguinte política de permissões concede permissões a um usuário para executar todas as ações que começam com `Describe`. Essas ações mostram informações sobre um recurso do RDS, como uma instância de banco de dados. O caractere curinga (\$1) no elemento `Resource` indica que as ações são permitidas para todos os recursos do Amazon Aurora que pertencem à conta.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowRDSDescribe",
"Effect": "Allow",
"Action": "rds:Describe*",
"Resource": "*"
}
]
}
```
------
## Permitir que um usuário crie uma instância de banco de dados que usa o grupo de parâmetros de banco de dados e o grupo de sub-redes especificados.
A seguinte política de permissões concede permissões para permitir que um usuário crie apenas uma instância de banco de dados que deve usar o grupo de parâmetros de banco de dados `mydbpg` e o grupo de sub-rede de banco de dados `mydbsubnetgroup`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "rds:CreateDBInstance",
"Resource": [
"arn:aws:rds:*:*:pg:mydbpg",
"arn:aws:rds:*:*:subgrp:mydbsubnetgroup"
]
}
]
}
```
------
## Conceder permissão para ações em um recurso com uma tag específica com dois valores diferentes
Você pode usar condições em sua política baseada em identidade para controlar o acesso aos recursos do Aurora com base em tags. A política a seguir concede permissão para realizar a operação de API `CreateDBSnapshot` em instâncias de banco de dados com a etiqueta `stage` definida como `development` ou `test`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AllowAnySnapshotName",
"Effect":"Allow",
"Action":[
"rds:CreateDBSnapshot"
],
"Resource":"arn:aws:rds:*:123456789012:snapshot:*"
},
{
"Sid":"AllowDevTestToCreateSnapshot",
"Effect":"Allow",
"Action":[
"rds:CreateDBSnapshot"
],
"Resource":"arn:aws:rds:*:123456789012:db:*",
"Condition":{
"StringEquals":{
"rds:db-tag/stage":[
"development",
"test"
]
}
}
}
]
}
```
------
A política a seguir concede permissão para realizar a operação de API `ModifyDBInstance` em instâncias de banco de dados com a etiqueta `stage` definida como `development` ou `test`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AllowChangingParameterOptionSecurityGroups",
"Effect":"Allow",
"Action":[
"rds:ModifyDBInstance"
],
"Resource": [
"arn:aws:rds:*:123456789012:pg:*",
"arn:aws:rds:*:123456789012:secgrp:*",
"arn:aws:rds:*:123456789012:og:*"
]
},
{
"Sid":"AllowDevTestToModifyInstance",
"Effect":"Allow",
"Action":[
"rds:ModifyDBInstance"
],
"Resource":"arn:aws:rds:*:123456789012:db:*",
"Condition":{
"StringEquals":{
"rds:db-tag/stage":[
"development",
"test"
]
}
}
}
]
}
```
------
## Impedir que um usuário exclua uma instância de banco de dados
A seguinte política de permissões concede permissões para impedir que um usuário exclua uma instância de banco de dados específica. Por exemplo, você pode querer negar a capacidade de excluir suas instâncias de banco de dados de produção para qualquer usuário que não seja um administrador.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyDelete1",
"Effect": "Deny",
"Action": "rds:DeleteDBInstance",
"Resource": "arn:aws:rds:us-west-2:123456789012:db:my-mysql-instance"
}
]
}
```
------
## Negar todo o acesso a um recurso
É possível negar acesso explicitamente a um recurso. As políticas de negação têm precedência sobre as políticas de permissão. A política a seguir nega explicitamente a um usuário a capacidade de gerenciar um recurso:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "rds:*",
"Resource": "arn:aws:rds:us-east-1:123456789012:db:mydb"
}
]
}
```
------
# Políticas de exemplo: usar chaves de condição
Os seguintes exemplos mostram como você pode usar chaves de condição em políticas de permissões do IAM do Amazon Aurora.
## Exemplo 1: conceder permissão para criar uma instância de banco de dados que usa um mecanismo de banco de dados específico e não é MultiAZ
A seguinte política usa uma chave de condição do RDS e permite que um usuário crie apenas instâncias de banco de dados que usam o mecanismo de banco de dados MySQL e não use o MultiAZ. O elemento `Condition` indica a exigência de que o mecanismo de banco de dados seja MySQL.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowMySQLCreate",
"Effect": "Allow",
"Action": "rds:CreateDBInstance",
"Resource": "*",
"Condition": {
"StringEquals": {
"rds:DatabaseEngine": "mysql"
},
"Bool": {
"rds:MultiAz": false
}
}
}
]
}
```
------
## Exemplo 2: negar explicitamente a permissão para criar instâncias de bancos de dados para determinadas classes de instância de banco de dados e criar instâncias de bancos de dados que usam IOPS provisionadas
A seguinte política nega explicitamente a permissão para criar instâncias de bancos de dados que usam as classes de instância de banco de dados `r3.8xlarge` e `m4.10xlarge`, que são as classes de instância de banco de dados maiores e mais caras. Essa política também impede que os usuários criem instâncias de banco de dados que usam IOPS provisionadas, que resultam em custos adicionais.
A negação explícita da permissão substitui quaisquer outras permissões concedidas. Isso garante que as identidades não obtenham acidentalmente permissão que você nunca deseja conceder.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyLargeCreate",
"Effect": "Deny",
"Action": "rds:CreateDBInstance",
"Resource": "*",
"Condition": {
"StringEquals": {
"rds:DatabaseClass": [
"db.r3.8xlarge",
"db.m4.10xlarge"
]
}
}
},
{
"Sid": "DenyPIOPSCreate",
"Effect": "Deny",
"Action": "rds:CreateDBInstance",
"Resource": "*",
"Condition": {
"NumericNotEquals": {
"rds:Piops": "0"
}
}
}
]
}
```
------
## Exemplo 3: limitar o conjunto de chaves de tag e valores que podem ser usados para identificar um recurso
A política a seguir usa uma chave de condição do RDS e permite a adição de uma tag com a chave `stage` a ser adicionada a um recurso com os valores `test`, `qa` e `production`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowTagEdits",
"Effect": "Allow",
"Action": [
"rds:AddTagsToResource",
"rds:RemoveTagsFromResource"
],
"Resource": "arn:aws:rds:us-east-1:123456789012:db:db-123456",
"Condition": {
"StringEquals": {
"rds:req-tag/stage": [
"test",
"qa",
"production"
]
}
}
}
]
}
```
------
# Especificar condições: usar tags personalizadas
O Amazon Aurora oferece suporte para especificar condições em uma política do IAM usando tags personalizadas.
Por exemplo, suponha que você adicione uma tag chamada `environment` às suas instâncias de banco de dados com valores como `beta`, `staging`, `production` e assim por diante. Se fizer isso, você poderá criar uma política que restrinja determinados usuários a instâncias de banco de dados com base no valor da tag `environment`.
**nota**
Os identificadores de tags personalizados diferenciam maiúsculas de minúsculas.
A tabela a seguir lista os identificadores de tags do RDS que você pode usar em um elemento `Condition`.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAM.SpecifyingCustomTags.html)
A sintaxe de uma condição de tag personalizada é a seguinte:
`"Condition":{"StringEquals":{"rds:rds-tag-identifier/tag-name": ["value"]} }`
Por exemplo, o seguinte elemento `Condition` se aplica a instâncias de banco de dados com uma tag `environment` e um valor de tag de `production`.
` "Condition":{"StringEquals":{"rds:db-tag/environment": ["production"]} } `
Para obter informações sobre como criar tags, consulte [Marcar recursos do Amazon Aurora e do Amazon RDS](USER_Tagging.md).
**Importante**
Se você gerenciar o acesso aos recursos do RDS usando tags, recomendamos proteger o acesso às tags para os seus recursos do RDS. Você pode gerenciar o acesso a tags, criando políticas para as ações `AddTagsToResource` e `RemoveTagsFromResource`. Por exemplo, a seguinte política nega aos usuários a capacidade de adicionar ou remover tags para todos os recursos. Você pode então criar políticas para permitir que usuários específicos adicionem ou removam tags.
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"DenyTagUpdates",
"Effect":"Deny",
"Action":[
"rds:AddTagsToResource",
"rds:RemoveTagsFromResource"
],
"Resource":"*"
}
]
}
```
Para obter uma lista de ações do Aurora, consulte [Ações definidas pelo Amazon RDS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-actions-as-permissions)* na *Referência de autorização do serviço.
## Políticas de exemplo: usar tags personalizadas
Os seguintes exemplos mostram como você pode usar tags personalizadas em políticas de permissões do IAM do Amazon Aurora. Para obter mais informações sobre como adicionar tags a um recurso do Amazon Aurora, consulte [Nomes de recurso da Amazon (ARNs) no Amazon RDS](USER_Tagging.ARN.md).
**nota**
Todos os exemplos usam a região us-west-2 e contêm IDs de conta fictícios.
### Exemplo 1: conceder permissão para ações em um recurso com uma tag específica com dois valores diferentes
A política a seguir concede permissão para realizar a operação de API `CreateDBSnapshot` em instâncias de banco de dados com a etiqueta `stage` definida como `development` ou `test`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AllowAnySnapshotName",
"Effect":"Allow",
"Action":[
"rds:CreateDBSnapshot"
],
"Resource":"arn:aws:rds:*:123456789012:snapshot:*"
},
{
"Sid":"AllowDevTestToCreateSnapshot",
"Effect":"Allow",
"Action":[
"rds:CreateDBSnapshot"
],
"Resource":"arn:aws:rds:*:123456789012:db:*",
"Condition":{
"StringEquals":{
"rds:db-tag/stage":[
"development",
"test"
]
}
}
}
]
}
```
------
A política a seguir concede permissão para realizar a operação de API `ModifyDBInstance` em instâncias de banco de dados com a etiqueta `stage` definida como `development` ou `test`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AllowChangingParameterOptionSecurityGroups",
"Effect":"Allow",
"Action":[
"rds:ModifyDBInstance"
],
"Resource": [
"arn:aws:rds:*:123456789012:pg:*",
"arn:aws:rds:*:123456789012:secgrp:*",
"arn:aws:rds:*:123456789012:og:*"
]
},
{
"Sid":"AllowDevTestToModifyInstance",
"Effect":"Allow",
"Action":[
"rds:ModifyDBInstance"
],
"Resource":"arn:aws:rds:*:123456789012:db:*",
"Condition":{
"StringEquals":{
"rds:db-tag/stage":[
"development",
"test"
]
}
}
}
]
}
```
------
### Exemplo 2: negar explicitamente a permissão para criar uma instância de banco de dados que usa grupos de parâmetros de banco de dados especificados
A seguinte política nega explicitamente a permissão para criar uma instância de banco de dados que usa grupos de parâmetros de banco de dados com valores de tag específicos. Você poderá aplicar essa política se precisar que um grupo de parâmetros de banco de dados específico criado pelo cliente sempre seja usado ao criar instâncias de bancos de dados. As políticas que utilizam `Deny` são mais frequentemente usadas para restringir o acesso que foi concedido por uma política mais ampla.
A negação explícita da permissão substitui quaisquer outras permissões concedidas. Isso garante que as identidades não obtenham acidentalmente permissão que você nunca deseja conceder.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"DenyProductionCreate",
"Effect":"Deny",
"Action":"rds:CreateDBInstance",
"Resource":"arn:aws:rds:*:123456789012:pg:*",
"Condition":{
"StringEquals":{
"rds:pg-tag/usage":"prod"
}
}
}
]
}
```
------
### Exemplo 3: conceder permissão para executar ações em uma instância de banco de dados com um nome de instância prefixado com um nome de usuário
A seguinte política permite chamar qualquer API (exceto para `AddTagsToResource` ou `RemoveTagsFromResource`) em uma instância de banco de dados que tem um nome prefixado com o nome do usuário e que tem uma tag `stage` igual a `devo` ou sem tag `stage`.
A linha `Resource` na política identifica um recurso pelo seu Nome de Recurso Amazon (ARN). Para obter mais informações sobre como usar ARNs com recursos do Amazon Aurora, consulte [Nomes de recurso da Amazon (ARNs) no Amazon RDS](USER_Tagging.ARN.md).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AllowFullDevAccessNoTags",
"Effect":"Allow",
"NotAction":[
"rds:AddTagsToResource",
"rds:RemoveTagsFromResource"
],
"Resource":"arn:aws:rds:*:123456789012:db:${aws:username}*",
"Condition":{
"StringEqualsIfExists":{
"rds:db-tag/stage":"devo"
}
}
}
]
}
```
------
# Conceder permissão para marcar recursos do Aurora durante a criação
Algumas operações de API do RDS permitem atribuir tags ao criar recursos. É possível usar tags de recursos para implementar o controle baseado em atributo (ABAC). Para ter mais informações, consulte [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) e [Controlar o acesso a recursos da AWS usando tags](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html).
Para permitir que os usuários marquem recursos na criação, eles devem ter permissões para usar a ação que cria o recurso, como `rds:CreateDBCluster`. Se as tags forem especificadas no ato da criação, o RDS concederá uma autorização adicional na ação `rds:AddTagsToResource` para verificar se os usuários têm permissões para criar tags. Portanto, os usuários também precisam ter permissões para usar a ação `rds:AddTagsToResource`.
Na definição de política do IAM para a ação `rds:AddTagsToResource`, você pode usar a chave de condição `aws:RequestTag` para exigir tags em uma solicitação para marcar um recurso.
Por exemplo, a seguinte política permite que os usuários criem instâncias de banco de dados e apliquem tags durante a criação, mas somente com chaves de tag específicas (`environment` ou `project`):
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds:CreateDBInstance"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"rds:AddTagsToResource"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/environment": ["production", "development"],
"aws:RequestTag/project": ["dataanalytics", "webapp"]
},
"ForAllValues:StringEquals": {
"aws:TagKeys": ["environment", "project"]
}
}
}
]
}
```
------
Essa política nega qualquer solicitação de criação de instância de banco de dados que inclua tags diferentes das tags `environment` ou `project` ou que não especifique nenhuma dessas tags. Além disso, os usuários devem especificar valores para as tags que correspondam aos valores permitidos na política.
A seguinte política permite que os usuários criem clusters de banco de dados e apliquem qualquer tag durante a criação, exceto a tag `environment=prod`:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds:CreateDBCluster"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"rds:AddTagsToResource"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestTag/environment": "prod"
}
}
}
]
}
```
------
## Ações de API do RDS que permitem atribuir tags durante a criação
As ações de API do RDS a seguir permitem atribuir tags durante a criação de um recurso. Para estas ações, você pode atribuir tags ao criar o recurso:
+ `CreateBlueGreenDeployment`
+ `CreateCustomDBEngineVersion`
+ `CreateDBCluster`
+ `CreateDBClusterEndpoint`
+ `CreateDBClusterParameterGroup`
+ `CreateDBClusterSnapshot`
+ `CreateDBInstance`
+ `CreateDBInstanceReadReplica`
+ `CreateDBParameterGroup`
+ `CreateDBProxy`
+ `CreateDBProxyEndpoint`
+ `CreateDBSecurityGroup`
+ `CreateDBShardGroup`
+ `CreateDBSnapshot`
+ `CreateDBSubnetGroup`
+ `CreateEventSubscription`
+ `CreateGlobalCluster`
+ `CreateIntegration`
+ `CreateOptionGroup`
+ `CreateTenantDatabase`
+ `CopyDBClusterParameterGroup`
+ `CopyDBClusterSnapshot`
+ `CopyDBParameterGroup`
+ `CopyDBSnapshot`
+ `CopyOptionGroup`
+ `RestoreDBClusterFromS3`
+ `RestoreDBClusterFromSnapshot`
+ `RestoreDBClusterToPointInTime`
+ `RestoreDBInstanceFromDBSnapshot`
+ `RestoreDBInstanceFromS3`
+ `RestoreDBInstanceToPointInTime`
+ `PurchaseReservedDBInstancesOffering`
Se você usar a AWS CLI ou a API para criar um recurso com tags, o parâmetro `Tags` será usado para aplicar tags aos recursos durante a criação.
Para essas ações de API, se a atribuição de tags falhar, o recurso não será criado e a solicitação falhará e apresentará um erro. Isso garante que os recursos sejam criados com tags ou não sejam criados, o que evita a criação de recursos sem as tags pretendidas.
# AWSPolíticas gerenciadas pela para o Amazon RDS
Para adicionar permissões a conjuntos de permissões e perfis, é mais fácil usar políticas gerenciadas pela AWS do que elaborar políticas por conta própria. É necessário tempo e experiência para [criar políticas gerenciadas pelo cliente do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) que fornecem à sua equipe apenas as permissões de que precisam. Para começar rapidamente, você pode usar nossas políticas gerenciadas pela AWS. Essas políticas abrangem casos de uso comuns e estão disponíveis na sua Conta da AWS. Para ter mais informações sobre as políticas gerenciadas da AWS, consulte [Políticas gerenciadas da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) no *Guia do usuário do IAM*.
Os Serviços da AWS mantêm e atualizam políticas gerenciadas pela AWS. Não é possível alterar as permissões em políticas gerenciadas pela AWS. Os serviços ocasionalmente acrescentam permissões adicionais a uma política gerenciada pela AWS para oferecer compatibilidade com novos atributos. Esse tipo de atualização afeta todas as identidades (conjuntos de permissões e perfis) às quais a política está anexada. É mais provável que os serviços atualizem uma política gerenciada pela AWS quando um novo atributo for iniciado ou novas operações se tornarem disponíveis. Os serviços não removem permissões de uma política gerenciada pela AWS. Portanto, as atualizações de políticas não suspendem suas permissões atuais.
Além disso, a AWS oferece suporte a políticas gerenciadas para funções de trabalho que abrangem vários serviços. Por exemplo, a política `ReadOnlyAccess` gerenciada pela AWS concede acesso somente leitura a todos os recursos e Serviços da AWS. Quando um serviço executa um novo recurso, a AWS adiciona permissões somente leitura para novas operações e recursos. Para obter uma lista e descrições das políticas de perfis de trabalho, consulte [Políticas gerenciadas pela AWS para perfis de trabalho](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) no *Guia do usuário do IAM*.
**Topics**
+ [AWSPolítica gerenciada pela : AmazonRDSReadOnlyAccess](#rds-security-iam-awsmanpol-AmazonRDSReadOnlyAccess)
+ [AWSPolítica gerenciada pela : AmazonRDSFullAccess](#rds-security-iam-awsmanpol-AmazonRDSFullAccess)
+ [AWSPolítica gerenciada pela : AmazonRDSDataFullAccess](#rds-security-iam-awsmanpol-AmazonRDSDataFullAccess)
+ [AWSPolítica gerenciada pela : AmazonRDSEnhancedMonitoringRole](#rds-security-iam-awsmanpol-AmazonRDSEnhancedMonitoringRole)
+ [AWSPolítica gerenciada pela : AmazonRDSPerformanceInsightsReadOnly](#rds-security-iam-awsmanpol-AmazonRDSPerformanceInsightsReadOnly)
+ [Política gerenciada pela AWS: AmazonRDSPerformanceInsightsFullAccess](#rds-security-iam-awsmanpol-AmazonRDSPerformanceInsightsFullAccess)
+ [AWSPolítica gerenciada pela : AmazonRDSDirectoryServiceAccess](#rds-security-iam-awsmanpol-AmazonRDSDirectoryServiceAccess)
+ [AWSPolítica gerenciada pela : AmazonRDSServiceRolePolicy](#rds-security-iam-awsmanpol-AmazonRDSServiceRolePolicy)
+ [Política gerenciada da AWS: AmazonRDSPreviewServiceRolePolicy](#rds-security-iam-awsmanpol-AmazonRDSPreviewServiceRolePolicy)
+ [Política gerenciada da AWS: AmazonRDSBetaServiceRolePolicy](#rds-security-iam-awsmanpol-AmazonRDSBetaServiceRolePolicy)
## AWSPolítica gerenciada pela : AmazonRDSReadOnlyAccess
Essa política permite o acesso somente leitura ao Amazon RDS por meio do Console de gerenciamento da AWS.
**Detalhes de permissões**
Esta política inclui as seguintes permissões:
+ `rds`: permite que as entidades principais descrevam os recursos do Amazon RDS e listem as etiquetas dos respectivos recursos.
+ `cloudwatch`: permite que as entidades principais obtenham estatísticas de métricas do Amazon CloudWatch.
+ `ec2`: permite que as entidades principais descrevam zonas de disponibilidade e recursos de rede.
+ `logs`: permite que as entidades principais descrevam fluxos de log do CloudWatch Logs de grupos de logs e obtenham eventos de log do CloudWatch Logs.
+ `devops-guru`: permite que as entidades principais descrevam os recursos que têm cobertura do Amazon DevOps Guru, que é especificada pelos nomes das pilhas ou pelas tags de recursos do CloudFormation.
Para ter mais informações sobre essa política, incluindo o documento de política JSON, consulte [AmazonRDSReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSReadOnlyAccess.html) no *Guia de referência de políticas gerenciadas pela AWS*.
## AWSPolítica gerenciada pela : AmazonRDSFullAccess
Essa política concede acesso total ao Amazon RDS por meio do Console de gerenciamento da AWS.
**Detalhes de permissões**
Esta política inclui as seguintes permissões:
+ `rds`: concede às entidades principais acesso total ao Amazon RDS.
+ `application-autoscaling`: permite que as entidades principais descrevam e gerenciem destinos e políticas de escalabilidade do Application Auto Scaling.
+ `cloudwatch`: permite que as entidades principais obtenham estáticas de métricas do CloudWatch e gerenciem os respectivos alarmes.
+ `ec2`: permite que as entidades principais descrevam zonas de disponibilidade e recursos de rede.
+ `logs`: permite que as entidades principais descrevam fluxos de log do CloudWatch Logs de grupos de logs e obtenham eventos de log do CloudWatch Logs.
+ `outposts`: permite que as entidades principais obtenham tipos de instância AWS Outposts.
+ `pi`: permite que as entidades principais obtenham métricas do Performance Insights.
+ `sns`: permite que as entidades principais acessem assinaturas e tópicos do Amazon Simple Notification Service (Amazon SNS) e publiquem mensagens do Amazon SNS.
+ `devops-guru`: permite que as entidades principais descrevam os recursos que têm cobertura do Amazon DevOps Guru, que é especificada pelos nomes das pilhas ou pelas tags de recursos do CloudFormation.
Para ter mais informações sobre essa política, incluindo o documento de política JSON, consulte [AmazonRDSFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSFullAccess.html) no *Guia de referência de políticas gerenciadas pela AWS*.
## AWSPolítica gerenciada pela : AmazonRDSDataFullAccess
Essa política permite acesso total ao uso da API DATA e ao editor de consultas em clusters do Aurora Serverless em uma Conta da AWS específica. Essa política permite que a Conta da AWS obtenha o valor de um segredo do AWS Secrets Manager.
É possível anexar a política `AmazonRDSDataFullAccess` às suas identidades do IAM.
**Detalhes de permissões**
Esta política inclui as seguintes permissões:
+ `dbqms`: permite que as entidades principais acessem, criem, excluam, descrevam e atualizem consultas. O Database Query Metadata Service (`dbqms`) é um serviço somente interno. Ele fornece suas consultas recentes e salvas para o editor de consultas no Console de gerenciamento da AWS para vários Serviços da AWS, inclusive o Amazon RDS.
+ `rds-data`: permite que as entidades principais executem instruções SQL em bancos de dados do Aurora Serverless.
+ `secretsmanager` – permite que as entidades principais obtenham o valor de um segredo do AWS Secrets Manager.
Para ter mais informações sobre essa política, incluindo o documento de política JSON, consulte [AmazonRDSDataFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSDataFullAccess.html) no *Guia de referência de políticas gerenciadas pela AWS*.
## AWSPolítica gerenciada pela : AmazonRDSEnhancedMonitoringRole
Essa política fornece acesso ao Amazon CloudWatch Logs for Amazon RDS Enhanced Monitoring.
**Detalhes de permissões**
Esta política inclui as seguintes permissões:
+ `logs`: permite que as entidades principais criem grupos de logs e políticas de retenção do CloudWatch Logs, bem como criem e descrevam fluxos de log do CloudWatch Logs de grupos de logs. Ela também permite que as entidades principais insiram e obtenham eventos de log do CloudWatch Logs.
Para ter mais informações sobre essa política, incluindo o documento de política JSON, consulte [AmazonRDSEnhancedMonitoringRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSEnhancedMonitoringRole.html) no *Guia de referência de políticas gerenciadas pela AWS*.
## AWSPolítica gerenciada pela : AmazonRDSPerformanceInsightsReadOnly
Essa política fornece acesso somente leitura ao Insights de Performance do Amazon RDS para instâncias de banco de dados do Amazon RDS e de clusters de banco de dados do Amazon Aurora.
Essa política agora inclui `Sid` (ID da instrução) como identificador para a declaração de política.
**Detalhes de permissões**
Esta política inclui as seguintes permissões:
+ `rds`: permite que as entidades principais descrevam instâncias de banco de dados do Amazon RDS e de clusters de banco de dados Amazon Aurora
+ `pi`: permite que as entidades principais façam chamadas para a API do Insights de Performance do Amazon RDS e acessem as métricas do Insights de Performance.
Para ter mais informações sobre essa política, incluindo o documento de política JSON, consulte [AmazonRDSPerformanceInsightsReadOnly](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSPerformanceInsightsReadOnly.html) no *Guia de referência de políticas gerenciadas pela AWS*.
## Política gerenciada pela AWS: AmazonRDSPerformanceInsightsFullAccess
Essa política fornece acesso total ao Insights de Performance do Amazon RDS para instâncias de banco de dados do Amazon RDS e clusters de banco de dados do Amazon Aurora.
Essa política agora inclui `Sid` (ID da instrução) como identificador para a declaração de política.
**Detalhes de permissões**
Esta política inclui as seguintes permissões:
+ `rds`: permite que as entidades principais descrevam instâncias de banco de dados do Amazon RDS e de clusters de banco de dados Amazon Aurora
+ `pi`: permite que as entidades principais façam chamadas para a API do Insights de Performance do Amazon RDS e criem, visualizem e excluam relatórios de análise de performance.
+ `cloudwatch`: permite que as entidades principais listem métricas do Amazon CloudWatch e obtenham dados de métricas e estatística.
Para receber mais informações sobre essa política, incluindo o documento de política JSON, consulte [AmazonRDSPerformanceInsightsFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSPerformanceInsightsFullAccess.html) no *Guia de referência de políticas gerenciadas pela AWS*.
## AWSPolítica gerenciada pela : AmazonRDSDirectoryServiceAccess
Essa política permite que o Amazon RDS faça chamadas ao Directory Service.
**Detalhes relacionados às permissões**
Esta política inclui a seguinte permissão:
+ `ds`: permite que as entidades principais descrevam diretórios do Directory Service e controlem a autorização para diretórios do Directory Service.
Para ter mais informações sobre essa política, incluindo o documento de política JSON, consulte [AmazonRDSDirectoryServiceAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSDirectoryServiceAccess.html) no *Guia de referência de políticas gerenciadas pela AWS*.
## AWSPolítica gerenciada pela : AmazonRDSServiceRolePolicy
Não é possível anexar a política `AmazonRDSServiceRolePolicy` às suas entidades do IAM. Essa política é anexada a uma função vinculada ao serviço que permite ao Amazon RDS realizar ações em seu nome. Para ter mais informações, consulte [Permissões de função vinculada ao serviço do Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions).
## Política gerenciada da AWS: AmazonRDSPreviewServiceRolePolicy
Não é possível anexar `AmazonRDSPreviewServiceRolePolicy` às suas entidades do IAM. Essa política é anexada a um perfil vinculado ao serviço que permite ao Amazon RDS chamar serviços da AWS em nome de seus recursos de banco de dados do RDS. Para obter mais informações, consulte [Perfil vinculado ao serviço da Pré-visualização do Amazon RDS](UsingWithRDS.IAM.ServiceLinkedRoles.md#slr-permissions-rdspreview).
**Detalhes de permissões**
Esta política inclui as seguintes permissões:
+ `ec2`: permite que as entidades principais descrevam Zonas de Disponibilidade e recursos de rede.
+ `secretsmanager` – permite que as entidades principais obtenham o valor de um segredo do AWS Secrets Manager.
+ `cloudwatch`, `logs`: permite que o Amazon RDS faça upload de métricas e logs da instância de banco de dados no CloudWatch por meio do agente do CloudWatch.
Para ter mais informações sobre essa política, bem como o documento de política JSON, consulte [AmazonRDSPreviewServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSPreviewServiceRolePolicy.html) no *Guia de referência de políticas gerenciadas da AWS*.
## Política gerenciada da AWS: AmazonRDSBetaServiceRolePolicy
Não é possível anexar `AmazonRDSBetaServiceRolePolicy` às suas entidades do IAM. Essa política é anexada a um perfil vinculado ao serviço que permite ao Amazon RDS chamar serviços da AWS em nome de seus recursos de banco de dados do RDS. Para obter mais informações, consulte [Permissões de perfis vinculados ao serviço para o Amazon RDS Beta](UsingWithRDS.IAM.ServiceLinkedRoles.md#slr-permissions-rdsbeta).
**Detalhes de permissões**
Esta política inclui as seguintes permissões:
+ `ec2`: permite que o Amazon RDS execute operações de backup na instância de banco de dados que fornece recursos de restauração para um ponto no tempo.
+ `secretsmanager`: permite ao Amazon RDS gerenciar segredos específicos da instância de banco de dados criados pelo Amazon RDS.
+ `cloudwatch`, `logs`: permite que o Amazon RDS faça upload de métricas e logs da instância de banco de dados no CloudWatch por meio do agente do CloudWatch.
Para ter mais informações sobre essa política, incluindo o documento de política JSON, consulte [AmazonRDSBetaServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSBetaServiceRolePolicy.html) no *Guia de referência de políticas gerenciadas da AWS*.
# Atualizações do Amazon RDS para políticas gerenciadas pela AWS
Visualize detalhes sobre atualizações em políticas gerenciadas pela AWS para o Amazon RDS desde que esse serviço começou a monitorar essas alterações. Para receber alertas automáticos sobre mudanças nesta página, assine o feed RSS na página [Histórico de documentos](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/WhatsNew.html) do Amazon RDS.
| Alteração | Descrição | Data |
| --- | --- | --- |
| [Política gerenciada da AWS: AmazonRDSPreviewServiceRolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSPreviewServiceRolePolicy): atualizar para uma política existente. | O Amazon RDS removeu a permissão `sns:Publish` da `AmazonRDSPreviewServiceRolePolicy` do perfil vinculado ao serviço `AWSServiceRoleForRDSPreview`. Para ter mais informações, consulte [Política gerenciada da AWS: AmazonRDSPreviewServiceRolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSPreviewServiceRolePolicy). | 7 de agosto de 2024 |
| [Política gerenciada da AWS: AmazonRDSBetaServiceRolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSBetaServiceRolePolicy): atualizar para uma política existente. | O Amazon RDS removeu a permissão `sns:Publish` da `AmazonRDSBetaServiceRolePolicy` do perfil vinculado ao serviço `AWSServiceRoleForRDSBeta`. Para ter mais informações, consulte [Política gerenciada da AWS: AmazonRDSBetaServiceRolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSBetaServiceRolePolicy). | 7 de agosto de 2024 |
| [AWSPolítica gerenciada pela : AmazonRDSServiceRolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSServiceRolePolicy): atualizar para uma política existente. | O Amazon RDS removeu a permissão `sns:Publish` da `AmazonRDSServiceRolePolicy` do perfil vinculado ao serviço ` AWSServiceRoleForRDS`. Para ter mais informações, consulte [AWSPolítica gerenciada pela : AmazonRDSServiceRolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSServiceRolePolicy). | 2 de julho de 2024 |
| [AWSPolíticas gerenciadas pela para o Amazon RDS](rds-security-iam-awsmanpol.md): atualizar para uma política existente. | O Amazon RDS adicionou uma nova permissão ao `AmazonRDSCustomServiceRolePolicy` do perfil vinculado ao serviço `AWSServiceRoleForRDSCustom` para permitir que o RDS Custom para SQL Server modifique o tipo de instância de host do banco de dados subjacente. O RDS também adicionou a permissão `ec2:DescribeInstanceTypes` para receber informações sobre o tipo de instância para o host do banco de dados. Para ter mais informações, consulte [AWSPolíticas gerenciadas pela para o Amazon RDS](rds-security-iam-awsmanpol.md). | 8 de abril de 2024 |
| [AWSPolíticas gerenciadas pela para o Amazon RDS](rds-security-iam-awsmanpol.md) – Nova política | O Amazon RDS adicionou uma nova política gerenciada chamada AmazonRDSCustomInstanceProfileRolePolicy para permitir que o RDS Custom execute ações de automação e tarefas de gerenciamento de banco de dados por meio de um perfil de instância do EC2. Para ter mais informações, consulte [AWSPolíticas gerenciadas pela para o Amazon RDS](rds-security-iam-awsmanpol.md). | 27 de fevereiro de 2024 |
| [Permissões de função vinculada ao serviço do Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions): atualizar para uma política existente | O Amazon RDS adicionou novos IDs de declarações à `AmazonRDSServiceRolePolicy` do perfil vinculado ao serviço `AWSServiceRoleForRDS`. Para ter mais informações, consulte [Permissões de função vinculada ao serviço do Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions). | 19 de janeiro de 2024 |
| [AWSPolíticas gerenciadas pela para o Amazon RDS](rds-security-iam-awsmanpol.md): atualizações em políticas existentes. | As políticas `AmazonRDSPerformanceInsightsFullAccess` gerenciadas `AmazonRDSPerformanceInsightsReadOnly` e as políticas agora incluem `Sid` (ID da instrução) como identificador na declaração de política. Para obter mais informações, consulte [AWSPolítica gerenciada pela : AmazonRDSPerformanceInsightsReadOnly](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSPerformanceInsightsReadOnly) e [Política gerenciada pela AWS: AmazonRDSPerformanceInsightsFullAccess](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSPerformanceInsightsFullAccess). | 23 de outubro de 2023 |
| [AWSPolíticas gerenciadas pela para o Amazon RDS](rds-security-iam-awsmanpol.md): atualizar para uma política existente. | O Amazon RDS adicionou novas permissões à política gerenciada `AmazonRDSFullAccess`. As permissões autorizam que você gere, visualize e exclua o relatório de análise de performance por um período. Para receber mais informações sobre como configurar políticas de acesso para o Insights de Performance, consulte [Configurar políticas de acesso para o Performance Insights](USER_PerfInsights.access-control.md). | 17 de agosto de 2023 |
| [AWSPolíticas gerenciadas pela para o Amazon RDS](rds-security-iam-awsmanpol.md): nova política e atualização da política existente. | O Amazon RDS adicionou novas permissões à política gerenciada `AmazonRDSPerformanceInsightsReadOnly` e uma nova política gerenciada chamada `AmazonRDSPerformanceInsightsFullAccess`. Essas permissões autorizam que você analise o Insights de Performance por um período, visualize os resultados da análise com as recomendações e exclua os relatórios. Para receber mais informações sobre como configurar políticas de acesso para o Insights de Performance, consulte [Configurar políticas de acesso para o Performance Insights](USER_PerfInsights.access-control.md). | 16 de agosto de 2023 |
| [AWSPolíticas gerenciadas pela para o Amazon RDS](rds-security-iam-awsmanpol.md): atualizar para uma política existente | O Amazon RDS adicionou um novo namespace do Amazon CloudWatch `ListMetrics` a `AmazonRDSFullAccess` e a `AmazonRDSReadOnlyAccess`. Esse namespace é necessário para que o Amazon RDS liste métricas específicas de uso de recursos. Para ter mais informações, consulte [Visão geral do gerenciamento de permissões de acesso aos recursos do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/iam-access-control-overview-cw.html) no *Guia do usuário do Amazon CloudWatch*. | 4 de abril de 2023 |
| [Permissões de função vinculada ao serviço do Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions): atualizar para uma política existente | O Amazon RDS adicionou novas permissões à `AmazonRDSServiceRolePolicy` da função vinculada ao serviço `AWSServiceRoleForRDS` para integração com o AWS Secrets Manager. O RDS requer integração com o Secrets Manager para gerenciar senhas do usuário principal no Secrets Manager. O segredo usa uma convenção de nomenclatura reservada e restringe as atualizações do cliente. Para ter mais informações, consulte [Gerenciamento de senhas com Amazon Aurora e AWS Secrets Manager](rds-secrets-manager.md). | 22 de dezembro de 2022 |
| [AWSPolíticas gerenciadas pela para o Amazon RDS](rds-security-iam-awsmanpol.md): atualizações em políticas existentes. | O Amazon RDS adicionou uma nova permissão a `AmazonRDSFullAccess` e às políticas gerenciadas `AmazonRDSReadOnlyAccess` para possibilitar que você ative o Amazon DevOps Guru no console do RDS. Essa permissão é necessária para conferir se o DevOps Guru está ativado. Para ter mais informações, consulte [Configurar políticas de acesso do IAM para DevOps Guru para RDS](devops-guru-for-rds.md#devops-guru-for-rds.configuring.access). | 19 de dezembro de 2022 |
| [Permissões de função vinculada ao serviço do Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions): atualizar para uma política existente | O Amazon RDS adicionou um novo namespace do Amazon CloudWatch ao `AmazonRDSPreviewServiceRolePolicy` para `PutMetricData`. Esse namespace é necessário para que o Amazon RDS publique métricas de uso de recursos. Para ter mais informações, consulte [Usar chaves de condição para limitar o acesso a namespaces do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/iam-cw-condition-keys-namespace.html) no *Guia do usuário do Amazon CloudWatch*. | 7 de junho de 2022 |
| [Permissões de função vinculada ao serviço do Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions): atualizar para uma política existente | O Amazon RDS adicionou um novo namespace do Amazon CloudWatch ao `AmazonRDSBetaServiceRolePolicy` para `PutMetricData`. Esse namespace é necessário para que o Amazon RDS publique métricas de uso de recursos. Para ter mais informações, consulte [Usar chaves de condição para limitar o acesso a namespaces do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/iam-cw-condition-keys-namespace.html) no *Guia do usuário do Amazon CloudWatch*. | 7 de junho de 2022 |
| [Permissões de função vinculada ao serviço do Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions): atualizar para uma política existente | O Amazon RDS adicionou um novo namespace do Amazon CloudWatch ao `AWSServiceRoleForRDS` para `PutMetricData`. Esse namespace é necessário para que o Amazon RDS publique métricas de uso de recursos. Para ter mais informações, consulte [Usar chaves de condição para limitar o acesso a namespaces do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/iam-cw-condition-keys-namespace.html) no *Guia do usuário do Amazon CloudWatch*. | 22 de abril de 2022 |
| [AWSPolíticas gerenciadas pela para o Amazon RDS](rds-security-iam-awsmanpol.md) – Nova política | O Amazon RDS adicionou uma nova política gerenciada denominada `AmazonRDSPerformanceInsightsReadOnly`, para permitir que o Amazon RDS chame serviços da AWS em nome de suas instâncias de banco de dados. Para receber mais informações sobre como configurar políticas de acesso para o Insights de Performance, consulte [Configurar políticas de acesso para o Performance Insights](USER_PerfInsights.access-control.md). | 10 de março de 2022 |
| [Permissões de função vinculada ao serviço do Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions): atualizar para uma política existente | O Amazon RDS adicionou novos namespaces do Amazon CloudWatch ao `AWSServiceRoleForRDS` para `PutMetricData`. Esses namespaces são necessários para que o Amazon DocumentDB (compatível com MongoDB) e o Amazon Neptune publiquem métricas do CloudWatch. Para ter mais informações, consulte [Usar chaves de condição para limitar o acesso a namespaces do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/iam-cw-condition-keys-namespace.html) no *Guia do usuário do Amazon CloudWatch*. | 4 de março de 2022 |
| O Amazon RDS passou a monitorar alterações | O Amazon RDS passou a monitorar alterações nas políticas gerenciadas pela AWS. | 26 de outubro de 2021 |
# Prevenção do problema do substituto confuso entre serviços
O *problema “confused deputy”* é um problema de segurança em que uma entidade que não tem permissão para executar uma ação pode coagir uma entidade mais privilegiada a executá-la. Na AWS, a personificação entre serviços pode resultar no problema do ‘confused deputy’.
A personificação entre serviços pode ocorrer quando um serviço (o *serviço de chamada*) chama outro serviço (o *serviço chamado*). O serviço de chamada pode ser manipulado de modo a usar suas permissões para atuar nos recursos de outro cliente de uma forma na qual ele não deveria ter permissão para acessar. Para evitar isso, a AWS fornece ferramentas que ajudam você a proteger seus dados para todos os serviços com entidades principais de serviço que receberam acesso aos recursos em sua conta. Para obter mais informações, consulte [O problema confused deputy](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html) no *Guia do usuário IAM*.
Recomendamos o uso das chaves de contexto de condição global [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) e [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) em políticas de recursos para limitar as permissões que o Amazon RDS concede a outro serviço para um recurso específico.
Em alguns casos, o valor `aws:SourceArn` não contém o ID da conta, por exemplo, quando você usa o nome do recurso da Amazon (ARN) para um bucket do Simple Storage Service (Amazon S3). Nesses casos, certifique-se de usar as duas chaves de contexto de condição global para limitar as permissões. Em alguns casos, você usa chaves de contexto de condição global e o valor `aws:SourceArn` contém o ID da conta. Nesses casos, verifique se o valor `aws:SourceAccount` e a conta no `aws:SourceArn` usa o mesmo ID de conta quando eles são usados na mesma instrução de política. Use se quiser que apenas um recurso seja associado ao acesso entre serviços `aws:SourceArn`. Use `aws:SourceAccount` se você quiser permitir que qualquer recurso nessa conta da AWS específica seja associado ao uso entre serviços.
Verifique se o valor de `aws:SourceArn` é um ARN para um tipo de recurso do Amazon RDS. Para obter mais informações, consulte [Nomes de recurso da Amazon (ARNs) no Amazon RDS](USER_Tagging.ARN.md).
A maneira mais eficaz de se proteger contra o problema do substituto confuso é usar a chave de contexto de condição global `aws:SourceArn` com o ARN completo do recurso. Em alguns casos, talvez você não saiba o ARN completo do recurso ou pode estar especificando vários recursos. Nesses casos, use a chave de condição de contexto global com curingas `aws:SourceArn` (`*`) para as partes desconhecidas do ARN. Um exemplo é `arn:aws:rds:*:123456789012:*`.
O exemplo a seguir mostra como é possível usar as chaves de contexto de condição global `aws:SourceArn` e `aws:SourceAccount` no Amazon RDS, a fim de evitar o problema do substituto confuso.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Sid": "ConfusedDeputyPreventionExamplePolicy",
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:rds:us-east-1:123456789012:db:mydbinstance"
},
"StringEquals": {
"aws:SourceAccount": "123456789012"
}
}
}
}
```
------
Para obter mais exemplos de políticas que usam as chaves de contexto de condição global `aws:SourceArn` e `aws:SourceAccount`, consulte as seguintes seções:
+ [Conceder permissões para publicar notificações em um tópico do Amazon SNS](USER_Events.GrantingPermissions.md)
+ [Configurar o acesso a um bucket do Amazon S3](USER_PostgreSQL.S3Import.AccessPermission.md) (Importação do PostgreSQL)
+ [Configurar o acesso a um bucket do Amazon S3](postgresql-s3-export-access-bucket.md) (Exportação do PostgreSQL)
# Autenticação do banco de dados do IAM
Você pode se autenticar o cluster de banco de dados usando a autenticação de banco de dados do AWS Identity and Access Management (IAM). A autenticação do banco de dados do IAM funciona com o Aurora MySQL e o Aurora PostgreSQL. Com esse método de autenticação, você não precisa usar uma senha ao conectar-se a um de instância de banco de dados. Em vez disso, você usa um token de autenticação.
Um *token de autenticação* é uma string exclusiva de caracteres que o Amazon Aurora gera mediante solicitação. Os tokens de autenticação são gerados usando o Signature da AWS versão 4. Cada token tem uma vida útil de 15 minutos. Você não precisa armazenar as credenciais de usuário no banco de dados, porque a autenticação é gerenciada externamente usando o IAM. Você também pode usar a autenticação de banco de dados padrão. O token é usado apenas para autenticação e não afetará a sessão depois que ela for estabelecida.
A autenticação do banco de dados do IAM oferece os seguintes benefícios:
+ O tráfego de rede de e para o banco de dados é criptografado usando Secure Socket Layer (SSL) ou Transport Layer Security (TLS). Para obter mais informações sobre como usar SSL/TLS com o Amazon Aurora, consulte [Usar SSL/TLS para criptografar uma conexão com um cluster de banco de dados](UsingWithRDS.SSL.md).
+ Você pode usar o IAM para gerenciar centralmente o acesso aos recursos de banco de dados, em vez de gerenciar o acesso individualmente em cada cluster de banco de dados.
+ Para aplicações em execução no Amazon EC2, você pode usar as credenciais específicas da instância do EC2 para acessar o banco de dados em vez de uma senha para maior segurança.
Em geral, considere usar a autenticação de banco de dados do IAM quando suas aplicações criam menos de 200 conexões por segundo e você não deseja gerenciar nomes de usuário e senhas diretamente no código da aplicação.
O driver JDBC da Amazon Web Services (AWS) comporta a autenticação do banco de dados do IAM. Para ter mais informações, consulte [AWS IAM Authentication Plugin](https://github.com/aws/aws-advanced-jdbc-wrapper/blob/main/docs/using-the-jdbc-driver/using-plugins/UsingTheIamAuthenticationPlugin.md) no [Amazon Web Services (AWS) JDBC Driver GitHub repository](https://github.com/aws/aws-advanced-jdbc-wrapper).
O driver Python da Amazon Web Services (AWS) comporta a autenticação do banco de dados do IAM. Para ter mais informações, consulte [AWS IAM Authentication Plugin](https://github.com/aws/aws-advanced-python-wrapper/blob/main/docs/using-the-python-driver/using-plugins/UsingTheIamAuthenticationPlugin.md) no [Amazon Web Services (AWS) Python Driver GitHub repository](https://github.com/aws/aws-advanced-python-wrapper).
Navegue pelos tópicos a seguir para aprender o processo de configuração do IAM para autenticação de banco de dados:
+ [Habilitar e desabilitar a autenticação de banco de dados do IAM](UsingWithRDS.IAMDBAuth.Enabling.md)
+ [Criar e usar uma política do IAM para acesso do banco de dados do IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md)
+ [Criar uma conta de banco de dados usando autenticação do IAM](UsingWithRDS.IAMDBAuth.DBAccounts.md)
+ [Conectar-se ao cluster de banco de dados usando a autenticação do IAM](UsingWithRDS.IAMDBAuth.Connecting.md)
## Disponibilidade de regiões e versões
A disponibilidade e a compatibilidade de recursos variam entre versões específicas de cada mecanismo de banco de dados do Aurora e entre Regiões da AWS. Para obter mais informações sobre a disponibilidade de versões e regiões com Aurora e autenticação de banco de dados do IAM, consulte [Regiões e mecanismos de banco de dados do Aurora compatíveis com a autenticação de banco de dados do IAM](Concepts.Aurora_Fea_Regions_DB-eng.Feature.IAMdbauth.md).
Para o Aurora MySQL, todas as classes de instância de banco de dados compatíveis oferecem suporte à autenticação de banco de dados do IAM, exceto db.t2.small e db.t3.small. Para obter informações sobre as classes de instância de banco de dados compatíveis, consulte [Mecanismos de banco de dados compatíveis para classes de instância de banco de dados](Concepts.DBInstanceClass.SupportAurora.md).
## Suporte para CLI e SDK
A autenticação de banco de dados do IAM está disponível para a [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/rds/generate-db-auth-token.html) e para os seguintes AWS SDKs específicos à linguagem:
+ [AWS SDK para .NET](https://docs.aws.amazon.com/sdkfornet/v3/apidocs/items/RDS/TRDSAuthTokenGenerator.html)
+ [AWS SDK para C\$1\$1](https://docs.aws.amazon.com/sdk-for-cpp/latest/api/class_aws_1_1_r_d_s_1_1_r_d_s_client.html#ae134ffffed5d7672f6156d324e7bd392)
+ [AWS SDK para Go](https://docs.aws.amazon.com/sdk-for-go/api/service/rds/#pkg-overview)
+ [AWS SDK para Java](https://docs.aws.amazon.com/sdk-for-java/latest/reference/software/amazon/awssdk/services/rds/RdsUtilities.html)
+ [AWS SDK para JavaScript](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/modules/_aws_sdk_rds_signer.html)
+ [AWS SDK para PHP](https://docs.aws.amazon.com/aws-sdk-php/v3/api/class-Aws.Rds.AuthTokenGenerator.html)
+ [AWS SDK para Python (Boto3)](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/rds.html#RDS.Client.generate_db_auth_token)
+ [AWS SDK para Ruby](https://docs.aws.amazon.com/sdk-for-ruby/v3/api/Aws/RDS/AuthTokenGenerator.html)
## Limitações para a autenticação de banco de dados do IAM
Ao usar a autenticação do banco de dados do IAM, as seguintes limitações se aplicam:
+ Atualmente, a autenticação do banco de dados 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 AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) no *Guia do usuário do IAM*.
+ No PostgreSQL, se o perfil do IAM (`rds_iam`) for adicionado a um usuário (por exemplo, o usuário principal do RDS), a autenticação do IAM terá precedência sobre a autenticação por senha, então o usuário precisará fazer login como um usuário do IAM.
+ Não é possível usar um registro DNS personalizado do Route 53 em vez do endpoint do cluster de banco de dados para gerar o token de autenticação.
+ O CloudWatch e o CloudTrail não registram em log a autenticação do IAM. Esses serviços não rastreiam chamadas de API `generate-db-auth-token` que autorizam o perfil do IAM a habilitar a conexão com o banco de dados.
+ A autenticação de banco de dados do IAM requer recursos de computação no cluster de banco de dados. É necessário ter entre 300 MiB e 1.000 MiB extras de memória no banco de dados para ter uma conectividade confiável. Para ver a memória necessária para a workload, compare a coluna RES para processos do RDS na lista de processos do monitoramento avançado antes e depois de habilitar a autenticação de banco de dados do IAM. Consulte [Como visualizar métricas do SO no console do RDS](USER_Monitoring.OS.Viewing.md).
Se você estiver usando uma instância de classe com capacidade de expansão, evite ficar sem memória reduzindo a memória usada por outros parâmetros, como buffers e cache, na mesma quantidade.
+ Em relação ao Aurora MySQL, não é possível usar autenticação baseada em senha para um usuário do banco de dados configurado com a autenticação do IAM.
+ Não é possível usar a autenticação de banco de dados do IAM com o RDS no Outposts em nenhum mecanismo.
## Recomendações para autenticação de banco de dados do IAM
Recomendamos o seguinte durante o uso da autenticação do banco de dados do IAM:
+ Use a autenticação de banco de dados do IAM quando sua aplicação exigir menos de 200 novas conexões de autenticação de banco de dados do IAM por segundo.
Os mecanismos de banco de dados que funcionam com o Amazon Aurora não impõem quaisquer limites para as tentativas de autenticação por segundo. No entanto, quando você usa a autenticação de banco de dados do IAM, sua aplicação deve gerar um token de autenticação. Sua aplicação então usa esse token para se conectar ao cluster de banco de dados. Se você exceder o limite de novas conexões máximas por segundo, a sobrecarga extra da autenticação de banco de dados IAM poderá causar a limitação da conexão.
Considere usar o agrupamento de conexões em suas aplicações para mitigar a criação constante de conexões. Isso pode reduzir a sobrecarga da autenticação de banco de dados do IAM e permitir que as aplicações reutilizem as conexões existentes. Como alternativa, considere usar o RDS Proxy para esses casos. O RDS Proxy tem custos adicionais. Consulte [Preços do RDS Proxy](https://aws.amazon.com/rds/proxy/pricing/).
+ O tamanho de um token de autenticação de banco de dados do IAM depende de muitas coisas, incluindo o número de etiquetas do IAM, políticas de serviço do IAM, comprimentos de ARN, bem como outras propriedades do IAM e do banco de dados. O tamanho mínimo desse token geralmente é de cerca de 1 KB, mas pode ser maior. Como esse token é usado como senha na string de conexão com o banco de dados por meio da autenticação do IAM, você deve garantir que o driver de banco de dados (por exemplo, ODBC) e/ou quaisquer ferramentas não limitem nem trunquem esse token devido ao respectivo tamanho. Um token truncado fará com que a validação da autenticação feita pelo banco de dados e pelo IAM falhe.
+ Se você estiver usando credenciais temporárias ao criar um token de autenticação do banco de dados do IAM, as credenciais temporárias ainda deverão ser válidas ao usar o token de autenticação do banco de dados do IAM para fazer uma solicitação de conexão.
## Chaves de contexto de condição globais da AWS incompatíveis
A autenticação do banco de dados do IAM não é compatível com o seguinte subconjunto de chaves de contexto de condição global da AWS.
+ `aws:Referer`
+ `aws:SourceIp`
+ `aws:SourceVpc`
+ `aws:SourceVpce`
+ `aws:UserAgent`
+ `aws:VpcSourceIp`
Para obter mais informações, 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*.
# Habilitar e desabilitar a autenticação de banco de dados do IAM
Por padrão, a autenticação de banco de dados do IAM está desabilitada nos clusters de banco de dados. É possível habilitar ou desabilitar a autenticação de banco de dados do IAM usando o Console de gerenciamento da AWS, a AWS CLI ou a API.
É possível habilitar a autenticação de banco de dados do IAM ao executar uma das seguintes ações:
+ Para criar um novo cluster de banco de dados com autenticação de banco de dados do IAM habilitada, consulte [Criar um cluster de bancos de dados do Amazon Aurora](Aurora.CreateInstance.md).
+ Para modificar um cluster de banco de dados para habilitar a autenticação de banco de dados do IAM, consulte [Modificar um cluster de bancos de dados Amazon Aurora](Aurora.Modifying.md).
+ Para restaurar um cluster de banco de dados de um snapshot com a autenticação de banco de dados do IAM habilitada, consulte [Restauração de um snapshot de um cluster de banco de dados](aurora-restore-snapshot.md).
+ Para restaurar um cluster de banco de dados em um momento específico com a autenticação de banco de dados do IAM habilitada, consulte [Restaurar um cluster de banco de dados para um horário especificado](aurora-pitr.md).
## Console
Cada fluxo de trabalho de criação ou modificação tem uma seção **Database authentication (Autenticação de banco de dados)**, onde é possível habilitar ou desabilitar a autenticação de banco de dados do IAM. Nessa seção, escolha **Password and IAM database authentication (Senha e autenticação do banco de dados do IAM)** para habilitar a autenticação do banco de dados do IAM.
**Para habilitar ou desabilitar a autenticação do banco de dados do IAM para um cluster de banco de dados existente**
1. Abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. No painel de navegação, escolha **Databases (Bancos de dados)**.
1. Escolha o cluster de banco de dados que você deseja modificar.
**nota**
Só será possível habilitar a autenticação do IAM se todas as instâncias de banco de dados no cluster de banco de dados forem compatíveis com o IAM. Verifique os requisitos de compatibilidade em [Disponibilidade de regiões e versões](UsingWithRDS.IAMDBAuth.md#UsingWithRDS.IAMDBAuth.Availability).
1. Selecione **Modify**.
1. Na seção **Autenticação do banco de dados**, escolha **Autenticação do banco de dados do IAM** para habilitar a autenticação do banco de dados do IAM. Escolha **Autenticação de senha** ou **Senha e autenticação Kerberos** para desabilitar a autenticação do IAM.
1. Você também pode optar por habilitar a publicação de logs de autenticação de banco de dados do IAM no CloudWatch Logs. Em **Exportações de log**, escolha a opção **Log iam-db-auth-error**. A publicação de logs no CloudWatch Logs consome armazenamento e gera cobranças por esse armazenamento. Se não precisar mais de algum log do CloudWatch, lembre-se de excluí-lo.
1. Escolha **Continue**.
1. Para aplicar as alterações imediatamente, escolha **Immediately (Imediatamente)** na seção **Scheduling of modifications (Programação de modificações)**.
1. Escolha **Modify cluster (Modificar cluster)** para salvar suas alterações.
## AWS CLI
Para criar um novo cluster de banco de dados com a autenticação do IAM usando a AWS CLI, use o comando [https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html). Especifique a opção `--enable-iam-database-authentication`.
Para atualizar um cluster de banco de dados existente a fim de ter ou não autenticação do IAM, use o comando da AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html). Especifique a opção `--enable-iam-database-authentication` ou `--no-enable-iam-database-authentication`, conforme apropriado.
**nota**
Só será possível habilitar a autenticação do IAM se todas as instâncias de banco de dados no cluster de banco de dados forem compatíveis com o IAM. Verifique os requisitos de compatibilidade em [Disponibilidade de regiões e versões](UsingWithRDS.IAMDBAuth.md#UsingWithRDS.IAMDBAuth.Availability).
Por padrão, o Aurora modifica a instância de banco de dados durante a próxima janela de manutenção. Se você quiser habilitar a autenticação de banco de dados do IAM o mais rápido possível, use o parâmetro `--apply-immediately`.
Se você está restaurando um cluster de banco de dados, use um dos comandos da AWS CLI a seguir:
+ `[restore-db-cluster-to-point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-to-point-in-time.html)`
+ `[restore-db-cluster-from-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html)`
A autenticação de banco de dados do IAM assumirá como padrão aquela do snapshot de origem. Para alterar essa configuração, defina a opção `--enable-iam-database-authentication` ou `--no-enable-iam-database-authentication`, conforme apropriado.
## API do RDS
Para criar uma nova instância de banco de dados com a autenticação do IAM usando a API, use a operação da API [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html). Defina o parâmetro `EnableIAMDatabaseAuthentication` como `true`.
Para atualizar um cluster de banco de dados existente a fim de ter ou não autenticação do IAM, use a operação da API [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html). Defina o parâmetro `EnableIAMDatabaseAuthentication` como `true` para habilitar a autenticação do IAM, ou `false` para desabilitá-la.
**nota**
Só será possível habilitar a autenticação do IAM se todas as instâncias de banco de dados no cluster de banco de dados forem compatíveis com o IAM. Verifique os requisitos de compatibilidade em [Disponibilidade de regiões e versões](UsingWithRDS.IAMDBAuth.md#UsingWithRDS.IAMDBAuth.Availability).
Se você está restaurando um de instância de banco de dados, use uma das operações da API a seguir:
+ [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterFromSnapshot.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterFromSnapshot.html)
+ [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterToPointInTime.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterToPointInTime.html)
A autenticação de banco de dados do IAM assumirá como padrão aquela do snapshot de origem. Para alterar essa configuração, defina o parâmetro `EnableIAMDatabaseAuthentication` como `true` para habilitar a autenticação do IAM, ou `false` para desabilitá-la.
# Criar e usar uma política do IAM para acesso do banco de dados do IAM
Para permitir que um usuário ou um perfil se conecte ao cluster de banco de dados, você deve criar uma política do IAM. Depois disso, associe a política a um conjunto de permissões ou a um perfil.
**nota**
Para saber mais sobre as políticas do IAM, consulte [Gerenciamento de identidade e acesso no Amazon Aurora](UsingWithRDS.IAM.md).
O exemplo de política a seguir permite que um usuário se conecte a um cluster de banco de dados usando a autenticação de banco de dados do IAM.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds-db:connect"
],
"Resource": [
"arn:aws:rds-db:us-east-2:111122223333:dbuser:cluster-ABCDEFGHIJKL01234/db_user"
]
}
]
}
```
------
**Importante**
Um usuário com permissões de administrador pode acessar clusters de banco de dados sem permissões explícitas em uma política do IAM. Se você quiser restringir o acesso do administrador a clusters de banco de dados, é possível criar um perfil do IAM com as permissões adequadas e menos privilegiadas e atribuí-lo ao administrador.
**nota**
Não confunda o prefixo `rds-db:` com outros prefixos de operações da API do RDS que começam com `rds:`. Você usa o prefixo `rds-db:` e a ação `rds-db:connect` somente para a autenticação de banco de dados do IAM. Eles não são válidos em nenhum outro contexto.
Os exemplos de política incluem uma única instrução com os seguintes elementos:
+ `Effect`: especifica `Allow` para conceder acesso ao cluster de banco de dados. Se você não permitir explicitamente o acesso, o acesso será negado por padrão.
+ `Action`: especifica `rds-db:connect` para permitir conexões com o cluster de banco de dados.
+ `Resource`: especifica um nome do recurso da Amazon (ARN) que descreva uma conta de banco de dados em um cluster. de banco de dados. O formato do ARN é o seguinte.
```
arn:aws:rds-db:region:account-id:dbuser:DbClusterResourceId/db-user-name
```
Neste formato, substitua o seguinte:
+ `region` é a região da AWS para a de Bancos de Dados cluster. No exemplo de política, a região da AWS é `us-east-2`.
+ `account-id` é o número da conta da AWS para de Bancos de Dadoscluster. No exemplo de política, o número da conta é `1234567890`. O usuário deve estar na mesma conta que a conta do cluster de banco de dados.
Para realizar o acesso entre contas, crie um perfil do IAM com a política mostrada acima na conta do cluster de banco de dados e permita que sua outra conta assuma o perfil.
+ `DbClusterResourceId` é o identificador do cluster de banco de dados. Esse identificador é exclusivo para uma região da AWS e nunca muda. Na exemplo de política, o identificador é `cluster-ABCDEFGHIJKL01234`.
Para encontrar um ID de recurso de cluster de banco de dados no Console de gerenciamento da AWS do Amazon Aurora, escolha o cluster de banco de dados para ver os respectivos detalhes. Em seguida, escolha a guia **Configuration (Configuração)**. O **Resource ID (ID de recurso)** é exibido na seção **Configuration (Configuração)**.
Como alternativa, use o comando da AWS CLI para listar os identificadores e os IDs de recurso de de Bancos de Dados cluster na região atual da AWS, conforme mostrado a seguir.
```
aws rds describe-db-clusters --query "DBClusters[*].[DBClusterIdentifier,DbClusterResourceId]"
```
**nota**
Se você estiver se conectando a um banco de dados por meio do RDS Proxy, especifique o ID do recurso de proxy, como `prx-ABCDEFGHIJKL01234`. Para obter informações sobre como usar a autenticação de banco de dados do IAM com RDS Proxy, consulte [Conectar-se a um banco de dados usando autenticação do IAM](rds-proxy-connecting.md#rds-proxy-connecting-iam).
+ `db-user-name` é o nome da conta de banco de dados para associar à autenticação do IAM. No exemplo de política, a conta de banco de dados é `db_user`.
Você pode criar outros ARNs que sejam compatíveis com vários padrões de acesso. A política a seguir permite o acesso a duas contas de banco de dados diferentes em um cluster de banco de dados.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds-db:connect"
],
"Resource": [
"arn:aws:rds-db:us-east-2:123456789012:dbuser:cluster-ABCDEFGHIJKL01234/jane_doe",
"arn:aws:rds-db:us-east-2:123456789012:dbuser:cluster-ABCDEFGHIJKL01234/mary_roe"
]
}
]
}
```
------
A política a seguir usa o caractere "\$1" para comparar de Bancos de Dados clusters e todas as contas de banco de dados para uma conta daAWS e uma região específicas da AWS.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds-db:connect"
],
"Resource": [
"arn:aws:rds-db:us-east-2:111122223333:dbuser:*/*"
]
}
]
}
```
------
A política a seguir compara de Bancos de Dados clusters de uma conta da AWS e uma região da AWS específicas. Contudo, a política concede acesso somente aos clusters de banco de dados que têm uma conta de banco de dados `jane_doe`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds-db:connect"
],
"Resource": [
"arn:aws:rds-db:us-east-2:123456789012:dbuser:*/jane_doe"
]
}
]
}
```
------
O usuário ou perfil tem acesso apenas aos bancos de dados que o usuário do banco de dados tem. Por exemplo, suponha que seu cluster de banco de dados tenha um banco de dados chamado *dev* e outro chamado *test*. Se a usuária do banco de dados `jane_doe` tiver acesso apenas a *dev*, os usuários ou perfis que acessarem esse cluster de banco de dados com a usuária `jane_doe` também terão acesso apenas a *dev*. Essa restrição de acesso também é válida para outros objetos de banco de dados, como tabelas, visualizações e assim por diante.
Um administrador deve criar políticas do IAM que concedam às entidades permissões para executar operações de API específicas nos recursos especificados de que precisam. Depois, o administrador deve anexar essas políticas aos conjuntos de permissões e perfis que exigem essas permissões. Para obter exemplos de políticas, consulte [Exemplos de políticas baseadas em identidade do Amazon Aurora](security_iam_id-based-policy-examples.md).
## Anexar uma política do IAM a um conjunto de permissões ou perfil
Depois de criar uma política do IAM para permitir a autenticação de banco de dados, você precisa anexar a política a um conjunto de permissões ou a um perfil. Para obter um tutorial sobre esse tópico, consulte [ Criar e anexar sua primeira política gerenciada pelo cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_managed-policies.html) no *Guia do usuário do IAM*.
À medida que avança pelo tutorial, você pode usar um dos exemplos de política mostrados nessa seção como um ponto de partida e adequá-lo às suas necessidades. No fim do tutorial, você terá um conjunto de permissões com uma política anexada que pode usar a ação `rds-db:connect`.
**nota**
Você pode mapear vários conjuntos de permissões ou perfis para a mesma conta de usuário do banco de dados. Por exemplo, suponha que a sua política do IAM especificou o seguinte recurso do ARN.
```
arn:aws:rds-db:us-east-2:123456789012:dbuser:cluster-12ABC34DEFG5HIJ6KLMNOP78QR/jane_doe
```
Se você anexar a política a *Jane*, *Bob* e *Diego*, todos eles poderão se conectar ao cluster de banco de dados em questão usando a conta de banco de dados `jane_doe`.
# Criar uma conta de banco de dados usando autenticação do IAM
Com a autenticação de banco de dados do IAM, você não precisa atribuir senhas de banco de dados à conta de usuário que você criar. Se você remover um usuário que está mapeado a uma conta de banco de dados, também deverá remover a conta de banco de dados com a instrução `DROP USER`.
**nota**
O nome de usuário usado para autenticação do IAM deve corresponder ao caso do nome de usuário no banco de dados.
**Topics**
+ [Usar autenticação do IAM com o Aurora MySQL](#UsingWithRDS.IAMDBAuth.DBAccounts.MySQL)
+ [Usar a autenticação do IAM com o AuroraPostgreSQL](#UsingWithRDS.IAMDBAuth.DBAccounts.PostgreSQL)
## Usar autenticação do IAM com o Aurora MySQL
Com o Aurora MySQL, a autenticação é processada por `AWSAuthenticationPlugin`: um plug-in fornecido pela AWS que funciona perfeitamente com o IAM para autenticar seus usuários. Conecte-se ao cluster de banco de dados como usuário principal ou um usuário diferente que possa criar usuários e conceder privilégios. Depois de se conectar, emita a instrução `CREATE USER` conforme mostrado no exemplo a seguir.
```
CREATE USER 'jane_doe' IDENTIFIED WITH AWSAuthenticationPlugin AS 'RDS';
```
A cláusula `IDENTIFIED WITH` permite que o Aurora MySQL usem o `AWSAuthenticationPlugin` para autenticar a conta de banco de dados (`jane_doe`). A `AS 'RDS'` cláusula refere-se ao método de autenticação. Verifique se o nome do usuário do banco de dados especificado é o mesmo que um recurso na política do IAM para acesso ao banco de dados do IAM. Para obter mais informações, consulte [Criar e usar uma política do IAM para acesso do banco de dados do IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md).
**nota**
Se você ver a mensagem a seguir, significa que o plugin fornecido pela AWS não está disponível para de Bancos de Dados atual cluster.
`ERROR 1524 (HY000): Plugin 'AWSAuthenticationPlugin' is not loaded`
Para solucionar esse erro, verifique se você está usando uma configuração compatível e se habilitou a autenticação de banco de dados do IAM em seu cluster de banco de dados. Para obter mais informações, consulte [Disponibilidade de regiões e versões](UsingWithRDS.IAMDBAuth.md#UsingWithRDS.IAMDBAuth.Availability) e [Habilitar e desabilitar a autenticação de banco de dados do IAM](UsingWithRDS.IAMDBAuth.Enabling.md).
Apos criar uma conta usando `AWSAuthenticationPlugin`, você a gerencia do mesmo modo que as outras contas de banco de dados. Por exemplo, você pode modificar os privilégios da conta com os atributos `GRANT` e `REVOKE`, ou modificar os vários atributos da conta com a instrução `ALTER USER`.
O tráfego de rede do banco de dados é criptografado utilizando SSL/TLS ao usar o IAM. Para permitir conexões SSL, modifique a conta do usuário com o comando a seguir.
```
ALTER USER 'jane_doe'@'%' REQUIRE SSL;
```
## Usar a autenticação do IAM com o AuroraPostgreSQL
Para usar a autenticação do IAM com o Aurora PostgreSQL, conecte-se ao cluster de banco de dados como usuário principal ou um usuário diferente que possa criar usuários e conceder privilégios. Depois de conectar-se, crie usuários de banco de dados e, depois, conceda a eles a função `rds_iam` conforme mostrado no exemplo a seguir.
```
CREATE USER db_userx;
GRANT rds_iam TO db_userx;
```
Verifique se o nome do usuário do banco de dados especificado é o mesmo que um recurso na política do IAM para acesso ao banco de dados do IAM. Para obter mais informações, consulte [Criar e usar uma política do IAM para acesso do banco de dados do IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md). Você deve conceder o perfil `rds_iam` para usar a autenticação do IAM. Também é possível usar associações aninhadas ou concessões indiretas do perfil.
Observe que um usuário de banco de dados PostgreSQL pode usar a autenticação do IAM ou Kerberos, mas não ambas, portanto esse usuário também não pode ter a função `rds_ad`. Isso também se aplica a assinaturas aninhadas. Para obter mais informações, consulte [Etapa 7: Criar usuários do PostgreSQL para suas entidades principais do Kerberos](postgresql-kerberos-setting-up.md#postgresql-kerberos-setting-up.create-logins).
# Conectar-se ao cluster de banco de dados usando a autenticação do IAM
Com a autenticação de banco de dados do IAM, você usa um token de autenticação ao se conectar ao cluster de banco de dados. Um *token de autenticação* é uma string de caracteres que você usa em vez de uma senha. Depois que você gerar um token de autenticação, ele será válido por 15 minutos antes de expirar. Se você tentar se conectar usando um token expirado, a solicitação de conexão será negada.
Todo token de autenticação deve ser acompanhado por uma assinatura válida, usando o Signature da AWS versão 4. (Para ter mais informações, consulte [Processo de assinatura do Signature versão 4](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html) na * Referência geral da AWS.*) A AWS CLI e um SDK da AWS, como AWS SDK para Java ou AWS SDK para Python (Boto3), podem assinar automaticamente cada token que você criar.
Você pode usar um token de autenticação quando se conectar ao Amazon Aurora de outro serviço da AWS, como o AWS Lambda. Ao usar um token, você não precisa inserir uma senha no seu código. Como alternativa, você pode usar o SDK da AWS para criar e assinar programaticamente um token de autenticação.
Depois que tiver um token de autenticação do IAM assinado, você poderá se conectar a um cluster de bancos de dados Aurora. Veja a seguir como fazer isso usando uma ferramenta de linha de comando ou um SDK da AWS, como o AWS SDK para Java ou AWS SDK para Python (Boto3).
Para ter mais informações, consulte as seguintes postagens no blog:
+ [Use IAM authentication to connect with SQL Workbench/J to Aurora MySQL or Amazon RDS para MySQL](https://aws.amazon.com/blogs/database/use-iam-authentication-to-connect-with-sql-workbenchj-to-amazon-aurora-mysql-or-amazon-rds-for-mysql/)
+ [Using IAM authentication to connect with pgAdmin Amazon Aurora PostgreSQL or Amazon RDS para PostgreSQL](https://aws.amazon.com/blogs/database/using-iam-authentication-to-connect-with-pgadmin-amazon-aurora-postgresql-or-amazon-rds-for-postgresql/)
**Pré-requisitos**
Veja a seguir os pré-requisitos para se conectar ao cluster de banco de dados usando a autenticação do IAM:
+ [Habilitar e desabilitar a autenticação de banco de dados do IAM](UsingWithRDS.IAMDBAuth.Enabling.md)
+ [Criar e usar uma política do IAM para acesso do banco de dados do IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md)
+ [Criar uma conta de banco de dados usando autenticação do IAM](UsingWithRDS.IAMDBAuth.DBAccounts.md)
**Topics**
+ [Conectar-se ao cluster de banco de dados usando a autenticação do IAM com os drivers da AWS.](IAMDBAuth.Connecting.Drivers.md)
+ [Conectando-se ao seu cluster de banco de dados usando a autenticação do IAM na linha de comando: AWS CLI e cliente mysql](UsingWithRDS.IAMDBAuth.Connecting.AWSCLI.md)
+ [Conectar o cluster de banco de dados usando a autenticação do IAM na linha de comando: AWS CLI e cliente psql](UsingWithRDS.IAMDBAuth.Connecting.AWSCLI.PostgreSQL.md)
+ [Conectar-se ao cluster de banco de dados usando a autenticação do IAM e o AWS SDK para .NET](UsingWithRDS.IAMDBAuth.Connecting.NET.md)
+ [Conectar-se ao cluster de banco de dados usando a autenticação do IAM e o AWS SDK para Go](UsingWithRDS.IAMDBAuth.Connecting.Go.md)
+ [Conectar-se ao cluster de banco de dados usando a autenticação do IAM e o AWS SDK para Java](UsingWithRDS.IAMDBAuth.Connecting.Java.md)
+ [Conectar-se ao cluster de banco de dados usando a autenticação do IAM e o AWS SDK para Python (Boto3)](UsingWithRDS.IAMDBAuth.Connecting.Python.md)
# Conectar-se ao cluster de banco de dados usando a autenticação do IAM com os drivers da AWS.
O pacote de drivers da AWS foram projetados para comportar tempos mais rápidos de transição e de failover, além de autenticação com o AWS Secrets Manager, o AWS Identity and Access Management (IAM) e identidades federadas. Os drivers da AWS dependem do monitoramento do status do cluster de banco de dados e do conhecimento da topologia do cluster para determinar o novo gravador. Essa abordagem reduz os tempos de transição e de failover para segundos de um dígito, em comparação com dezenas de segundos para drivers de código aberto.
Para ter mais informações sobre os drivers da AWS, consulte o driver de linguagem correspondente para o cluster de banco de dados do [Aurora MySQL](Aurora.Connecting.md#Aurora.Connecting.JDBCDriverMySQL) ou do [Aurora PostgreSQL](Aurora.Connecting.md#Aurora.Connecting.AuroraPostgreSQL.Utilities).
# Conectando-se ao seu cluster de banco de dados usando a autenticação do IAM na linha de comando: AWS CLI e cliente mysql
Você pode se conectar de uma linha de comando a um cluster de bancos de dados Aurora com a AWS CLI e a ferramenta da linha de comando `mysql`, conforme descrito a seguir.
**Pré-requisitos**
Veja a seguir os pré-requisitos para se conectar ao cluster de banco de dados usando a autenticação do IAM:
+ [Habilitar e desabilitar a autenticação de banco de dados do IAM](UsingWithRDS.IAMDBAuth.Enabling.md)
+ [Criar e usar uma política do IAM para acesso do banco de dados do IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md)
+ [Criar uma conta de banco de dados usando autenticação do IAM](UsingWithRDS.IAMDBAuth.DBAccounts.md)
**nota**
Para obter informações sobre como se conectar ao banco de dados usando o SQL Workbench/J com autenticação do IAM, consulte a publicação do blog [Use IAM authentication to connect with SQL Workbench/J to Aurora MySQL or Amazon RDS para MySQL](https://aws.amazon.com/blogs/database/use-iam-authentication-to-connect-with-sql-workbenchj-to-amazon-aurora-mysql-or-amazon-rds-for-mysql/).
**Topics**
+ [Gerar um token de autenticação do IAM](#UsingWithRDS.IAMDBAuth.Connecting.AWSCLI.AuthToken)
+ [Conexão ao cluster de banco de dados](#UsingWithRDS.IAMDBAuth.Connecting.AWSCLI.Connect)
## Gerar um token de autenticação do IAM
O exemplo a seguir mostra como obter um token de autenticação assinado usando a AWS CLI.
```
aws rds generate-db-auth-token \
--hostname rdsmysql.123456789012.us-west-2.rds.amazonaws.com \
--port 3306 \
--region us-west-2 \
--username jane_doe
```
No exemplo, os parâmetros são os seguintes:
+ `--hostname`: o nome do host do cluster de banco de dados que você deseja acessar
+ `--port`: o número da porta usada para se conectar ao cluster de banco de dados
+ `--region`: a região da AWS na qual o cluster do banco de dados está em execução.
+ `--username`: a conta de banco de dados que você deseja acessar
Os primeiros caracteres do token são parecidos com os seguintes.
```
rdsmysql.123456789012.us-west-2.rds.amazonaws.com:3306/?Action=connect&DBUser=jane_doe&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Expires=900...
```
**nota**
Não é possível usar um registro DNS personalizado do Route 53 em vez do endpoint do cluster de banco de dados para gerar o token de autenticação.
## Conexão ao cluster de banco de dados
O formato geral para se conectar é mostrado a seguir.
```
mysql --host=hostName --port=portNumber --ssl-ca=full_path_to_ssl_certificate --enable-cleartext-plugin --user=userName --password=authToken
```
Os parâmetros são os seguintes:
+ `--host`: o nome do host do cluster de banco de dados que você deseja acessar
+ `--port`: o número da porta usada para se conectar ao cluster de banco de dados
+ `--ssl-ca`: o caminho completo para o arquivo de certificado SSL que contém a chave pública
Para ter mais informações, consulte [Conexões do TLS com clusters de banco de dados do Aurora MySQL](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL).
Para baixar um certificado SSL, consulte [Usar SSL/TLS para criptografar uma conexão com um cluster de banco de dados](UsingWithRDS.SSL.md).
+ `--enable-cleartext-plugin`: um valor que especifica que o `AWSAuthenticationPlugin` deve ser usado para essa conexão
Se você estiver usando um cliente MariaDB, a opção`--enable-cleartext-plugin` não será necessária.
+ `--user`: a conta de banco de dados que você deseja acessar
+ `--password`: um token de autenticação do IAM assinado
Um token de autenticação é composto de várias centenas de caracteres. Ele pode ser incômodo para a linha de comando. Um modo de contornar isso é salvar o token em uma variável de ambiente, e usar essa variável quando você se conectar. O exemplo a seguir mostra um modo de executar essa solução alternativa. No exemplo, */sample\$1dir/* corresponde ao caminho completo do arquivo de certificado SSL contendo a chave pública.
```
RDSHOST="mysqlcluster.cluster-123456789012.us-east-1.rds.amazonaws.com"
TOKEN="$(aws rds generate-db-auth-token --hostname $RDSHOST --port 3306 --region us-west-2 --username jane_doe )"
mysql --host=$RDSHOST --port=3306 --ssl-ca=/sample_dir/global-bundle.pem --enable-cleartext-plugin --user=jane_doe --password=$TOKEN
```
Quando você se conecta usando o `AWSAuthenticationPlugin`, a conexão é protegida usando SSL. Para verificar isso, digite o seguinte no prompt de comando `mysql>`.
```
show status like 'Ssl%';
```
As seguintes linhas na saída mostram mais detalhes.
```
+---------------+-------------+
| Variable_name | Value |
+---------------+-------------+
| ... | ...
| Ssl_cipher | AES256-SHA |
| ... | ...
| Ssl_version | TLSv1.1 |
| ... | ...
+-----------------------------+
```
Se você quiser se conectar a um cluster de banco de dados por meio de um proxy, consulte [Conectar-se a um banco de dados usando autenticação do IAM](rds-proxy-connecting.md#rds-proxy-connecting-iam).
# Conectar o cluster de banco de dados usando a autenticação do IAM na linha de comando: AWS CLI e cliente psql
Conecte-se pela linha de comando a um cluster de bancos de dados Aurora PostgreSQL com a AWS CLI e a ferramenta da linha de comando psql conforme descrito a seguir.
**Pré-requisitos**
Veja a seguir os pré-requisitos para se conectar ao cluster de banco de dados usando a autenticação do IAM:
+ [Habilitar e desabilitar a autenticação de banco de dados do IAM](UsingWithRDS.IAMDBAuth.Enabling.md)
+ [Criar e usar uma política do IAM para acesso do banco de dados do IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md)
+ [Criar uma conta de banco de dados usando autenticação do IAM](UsingWithRDS.IAMDBAuth.DBAccounts.md)
**nota**
Para obter informações sobre como se conectar ao seu banco de dados usando pgAdmin com autenticação do IAM, consulte a publicação do blog [Using IAM authentication to connect with pgAdmin Amazon Aurora PostgreSQL or Amazon RDS para PostgreSQL](https://aws.amazon.com/blogs/database/using-iam-authentication-to-connect-with-pgadmin-amazon-aurora-postgresql-or-amazon-rds-for-postgresql/).
**Topics**
+ [Gerar um token de autenticação do IAM](#UsingWithRDS.IAMDBAuth.Connecting.AWSCLI.AuthToken.PostgreSQL)
+ [Conectar-se a um cluster do Aurora PostgreSQL](#UsingWithRDS.IAMDBAuth.Connecting.AWSCLI.Connect.PostgreSQL)
## Gerar um token de autenticação do IAM
Um token de autenticação é composto de várias centenas de caracteres. Dessa maneira, ele pode ficar estranho na linha de comando. Um modo de contornar isso é salvar o token em uma variável de ambiente, e usar essa variável quando você se conectar. O exemplo a seguir mostra como usar a AWS CLI para obter um token de autenticação assinado usando o comando `generate-db-auth-token` e armazená-lo em uma variável de ambiente `PGPASSWORD`.
```
export RDSHOST="mypostgres-cluster.cluster-123456789012.us-west-2.rds.amazonaws.com"
export PGPASSWORD="$(aws rds generate-db-auth-token --hostname $RDSHOST --port 5432 --region us-west-2 --username jane_doe )"
```
No exemplo, os parâmetros para o comando `generate-db-auth-token` são os seguintes:
+ `--hostname`: o nome do host do cluster (endpoint do cluster) de banco de dados que você deseja acessar
+ `--port`: o número da porta usada para se conectar ao cluster de banco de dados
+ `--region`: a região da AWS na qual o cluster do banco de dados está em execução.
+ `--username`: a conta de banco de dados que você deseja acessar
Os primeiros caracteres do token gerado são parecidos com os seguintes.
```
mypostgres-cluster.cluster-123456789012.us-west-2.rds.amazonaws.com:5432/?Action=connect&DBUser=jane_doe&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Expires=900...
```
**nota**
Não é possível usar um registro DNS personalizado do Route 53 em vez do endpoint do cluster de banco de dados para gerar o token de autenticação.
## Conectar-se a um cluster do Aurora PostgreSQL
O formato geral para usar psql na conexão é mostrado a seguir.
```
psql "host=hostName port=portNumber sslmode=verify-full sslrootcert=full_path_to_ssl_certificate dbname=DBName user=userName password=authToken"
```
Os parâmetros são os seguintes:
+ `host`: o nome do host do cluster (endpoint do cluster) de banco de dados que você deseja acessar
+ `port`: o número da porta usada para se conectar ao cluster de banco de dados
+ `sslmode`: o modo SSL a ser usado
Quando você usa `sslmode=verify-full`, a conexão SSL verifica o endpoint do cluster de banco de dados em relação ao endpoint no certificado SSL.
+ `sslrootcert`: o caminho completo para o arquivo de certificado SSL que contém a chave pública
Para ter mais informações, consulte [Como proteger dados do Aurora PostgreSQL com SSL/TLS](AuroraPostgreSQL.Security.md#AuroraPostgreSQL.Security.SSL).
Para baixar um certificado SSL, consulte [Usar SSL/TLS para criptografar uma conexão com um cluster de banco de dados](UsingWithRDS.SSL.md).
+ `dbname`: o banco de dados que você deseja acessar
+ `user`: a conta de banco de dados que você deseja acessar
+ `password`: um token de autenticação do IAM assinado
**nota**
Não é possível usar um registro DNS personalizado do Route 53 em vez do endpoint do cluster de banco de dados para gerar o token de autenticação.
O exemplo a seguir mostra o uso do psql para conexão. No exemplo, psql usa a variável de ambiente `RDSHOST` para o host e a variável de ambiente `PGPASSWORD` para o token gerado. Além disso, */sample\$1dir/* corresponde ao caminho completo do arquivo de certificado SSL contendo a chave pública.
```
export RDSHOST="mypostgres-cluster.cluster-123456789012.us-west-2.rds.amazonaws.com"
export PGPASSWORD="$(aws rds generate-db-auth-token --hostname $RDSHOST --port 5432 --region us-west-2 --username jane_doe )"
psql "host=$RDSHOST port=5432 sslmode=verify-full sslrootcert=/sample_dir/global-bundle.pem dbname=DBName user=jane_doe password=$PGPASSWORD"
```
Se você quiser se conectar a um cluster de banco de dados por meio de um proxy, consulte [Conectar-se a um banco de dados usando autenticação do IAM](rds-proxy-connecting.md#rds-proxy-connecting-iam).
# Conectar-se ao cluster de banco de dados usando a autenticação do IAM e o AWS SDK para .NET
Você pode se conectar a um cluster de banco de dados Aurora MySQL ou Aurora PostgreSQL com a AWS SDK para .NET, conforme descrito a seguir.
**Pré-requisitos**
Veja a seguir os pré-requisitos para se conectar ao cluster de banco de dados usando a autenticação do IAM:
+ [Habilitar e desabilitar a autenticação de banco de dados do IAM](UsingWithRDS.IAMDBAuth.Enabling.md)
+ [Criar e usar uma política do IAM para acesso do banco de dados do IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md)
+ [Criar uma conta de banco de dados usando autenticação do IAM](UsingWithRDS.IAMDBAuth.DBAccounts.md)
**Exemplos**
O exemplo de código a seguir mostra como gerar um token de autenticação e usá-lo para se conectar a um cluster de banco de dados.
Para executar esse exemplo de código, você precisa do [AWS SDK para .NET](https://aws.amazon.com/sdk-for-net/), encontrado no site AWS. Os pacotes `AWSSDK.CORE` e `AWSSDK.RDS` são necessários. Para se conectar a um cluster de banco de dados, use o conector de banco de dados .NET para o mecanismo de banco de dados, como MySqlConnector para MariaDB ou MySQL ou Npgsql para PostgreSQL.
Esse código se conecta a um cluster de banco de dados Aurora MySQL. Modifique os valores das seguintes variáveis, conforme necessário:
+ `server`: o endpoint do cluster de banco de dados que você deseja acessar
+ `user`: a conta de banco de dados que você deseja acessar
+ `database`: o banco de dados que você deseja acessar
+ `port`: o número da porta usada para se conectar ao cluster de banco de dados
+ `SslMode`: o modo SSL a ser usado
Quando você usa `SslMode=Required`, a conexão SSL verifica o endpoint do cluster de banco de dados em relação ao endpoint no certificado SSL.
+ `SslCa`: o caminho completo para o certificado SSL do Amazon Aurora
Para baixar um certificado, consulte [Usar SSL/TLS para criptografar uma conexão com um cluster de banco de dados](UsingWithRDS.SSL.md).
**nota**
Não é possível usar um registro DNS personalizado do Route 53 em vez do endpoint do cluster de banco de dados para gerar o token de autenticação.
```
using System;
using System.Data;
using MySql.Data;
using MySql.Data.MySqlClient;
using Amazon;
namespace ubuntu
{
class Program
{
static void Main(string[] args)
{
var pwd = Amazon.RDS.Util.RDSAuthTokenGenerator.GenerateAuthToken(RegionEndpoint.USEast1, "mysqlcluster.cluster-123456789012.us-east-1.rds.amazonaws.com", 3306, "jane_doe");
// for debug only Console.Write("{0}\n", pwd); //this verifies the token is generated
MySqlConnection conn = new MySqlConnection($"server=mysqlcluster.cluster-123456789012.us-east-1.rds.amazonaws.com;user=jane_doe;database=mydB;port=3306;password={pwd};SslMode=Required;SslCa=full_path_to_ssl_certificate");
conn.Open();
// Define a query
MySqlCommand sampleCommand = new MySqlCommand("SHOW DATABASES;", conn);
// Execute a query
MySqlDataReader mysqlDataRdr = sampleCommand.ExecuteReader();
// Read all rows and output the first column in each row
while (mysqlDataRdr.Read())
Console.WriteLine(mysqlDataRdr[0]);
mysqlDataRdr.Close();
// Close connection
conn.Close();
}
}
}
```
Esse código se conecta a um cluster de banco de dados Aurora PostgreSQL.
Modifique os valores das seguintes variáveis, conforme necessário:
+ `Server`: o endpoint do cluster de banco de dados que você deseja acessar
+ `User ID`: a conta de banco de dados que você deseja acessar
+ `Database`: o banco de dados que você deseja acessar
+ `Port`: o número da porta usada para se conectar ao cluster de banco de dados
+ `SSL Mode`: o modo SSL a ser usado
Quando você usa `SSL Mode=Required`, a conexão SSL verifica o endpoint do cluster de banco de dados em relação ao endpoint no certificado SSL.
+ `Root Certificate`: o caminho completo para o certificado SSL do Amazon Aurora
Para baixar um certificado, consulte [Usar SSL/TLS para criptografar uma conexão com um cluster de banco de dados](UsingWithRDS.SSL.md).
**nota**
Não é possível usar um registro DNS personalizado do Route 53 em vez do endpoint do cluster de banco de dados para gerar o token de autenticação.
```
using System;
using Npgsql;
using Amazon.RDS.Util;
namespace ConsoleApp1
{
class Program
{
static void Main(string[] args)
{
var pwd = RDSAuthTokenGenerator.GenerateAuthToken("postgresmycluster.cluster-123456789012.us-east-1.rds.amazonaws.com", 5432, "jane_doe");
// for debug only Console.Write("{0}\n", pwd); //this verifies the token is generated
NpgsqlConnection conn = new NpgsqlConnection($"Server=postgresmycluster.cluster-123456789012.us-east-1.rds.amazonaws.com;User Id=jane_doe;Password={pwd};Database=mydb;SSL Mode=Require;Root Certificate=full_path_to_ssl_certificate");
conn.Open();
// Define a query
NpgsqlCommand cmd = new NpgsqlCommand("select count(*) FROM pg_user", conn);
// Execute a query
NpgsqlDataReader dr = cmd.ExecuteReader();
// Read all rows and output the first column in each row
while (dr.Read())
Console.Write("{0}\n", dr[0]);
// Close connection
conn.Close();
}
}
}
```
Se você quiser se conectar a um cluster de banco de dados por meio de um proxy, consulte [Conectar-se a um banco de dados usando autenticação do IAM](rds-proxy-connecting.md#rds-proxy-connecting-iam).
# Conectar-se ao cluster de banco de dados usando a autenticação do IAM e o AWS SDK para Go
Você pode se conectar a um cluster de banco de dados Aurora MySQL ou Aurora PostgreSQL com a AWS SDK para Go, conforme descrito a seguir.
**Pré-requisitos**
Veja a seguir os pré-requisitos para se conectar ao cluster de banco de dados usando a autenticação do IAM:
+ [Habilitar e desabilitar a autenticação de banco de dados do IAM](UsingWithRDS.IAMDBAuth.Enabling.md)
+ [Criar e usar uma política do IAM para acesso do banco de dados do IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md)
+ [Criar uma conta de banco de dados usando autenticação do IAM](UsingWithRDS.IAMDBAuth.DBAccounts.md)
**Exemplos**
Para executar esses exemplos de código, você precisa do [AWS SDK para Go](https://aws.amazon.com/sdk-for-go/), encontrado no site AWS.
Modifique os valores das seguintes variáveis, conforme necessário:
+ `dbName`: o banco de dados que você deseja acessar
+ `dbUser`: a conta de banco de dados que você deseja acessar
+ `dbHost`: o endpoint do cluster de banco de dados que você deseja acessar
**nota**
Não é possível usar um registro DNS personalizado do Route 53 em vez do endpoint do cluster de banco de dados para gerar o token de autenticação.
+ `dbPort`: o número da porta usada para se conectar ao cluster de banco de dados
+ `region`: a região da AWS na qual o cluster do banco de dados está em execução.
Além disso, verifique se as bibliotecas importadas no código de exemplo existem no sistema.
**Importante**
Os exemplos nesta seção usam o seguinte código para fornecer credenciais que acessam um banco de dados a partir de um ambiente local:
`creds := credentials.NewEnvCredentials()`
Se estiver acessando um banco de dados de um serviço da AWS, como o Amazon EC2 ou Amazon ECS, você poderá substituir o código pelo seguinte código:
`sess := session.Must(session.NewSession())`
`creds := sess.Config.Credentials`
Se você fizer essa alteração, certifique-se de adicionar a seguinte importação:
`"github.com/aws/aws-sdk-go/aws/session"`
**Topics**
+ [Conectar-se usando a autenticação do IAM e o AWS SDK para Go V2](#UsingWithRDS.IAMDBAuth.Connecting.GoV2)
+ [Conectar-se usando a autenticação do IAM e o AWS SDK para Go V1.](#UsingWithRDS.IAMDBAuth.Connecting.GoV1)
## Conectar-se usando a autenticação do IAM e o AWS SDK para Go V2
Conecte-se a um cluster de banco de dados usando a autenticação do IAM e o AWS SDK para Go V2.
O exemplo de código a seguir mostra como gerar um token de autenticação e usá-lo para se conectar a um cluster de banco de dados.
Esse código se conecta a um cluster de banco de dados Aurora MySQL.
```
package main
import (
"context"
"database/sql"
"fmt"
"github.com/aws/aws-sdk-go-v2/config"
"github.com/aws/aws-sdk-go-v2/feature/rds/auth"
_ "github.com/go-sql-driver/mysql"
)
func main() {
var dbName string = "DatabaseName"
var dbUser string = "DatabaseUser"
var dbHost string = "mysqlcluster.cluster-123456789012.us-east-1.rds.amazonaws.com"
var dbPort int = 3306
var dbEndpoint string = fmt.Sprintf("%s:%d", dbHost, dbPort)
var region string = "us-east-1"
cfg, err := config.LoadDefaultConfig(context.TODO())
if err != nil {
panic("configuration error: " + err.Error())
}
authenticationToken, err := auth.BuildAuthToken(
context.TODO(), dbEndpoint, region, dbUser, cfg.Credentials)
if err != nil {
panic("failed to create authentication token: " + err.Error())
}
dsn := fmt.Sprintf("%s:%s@tcp(%s)/%s?tls=true&allowCleartextPasswords=true",
dbUser, authenticationToken, dbEndpoint, dbName,
)
db, err := sql.Open("mysql", dsn)
if err != nil {
panic(err)
}
err = db.Ping()
if err != nil {
panic(err)
}
}
```
Esse código se conecta a um cluster de banco de dados Aurora PostgreSQL.
```
package main
import (
"context"
"database/sql"
"fmt"
"github.com/aws/aws-sdk-go-v2/config"
"github.com/aws/aws-sdk-go-v2/feature/rds/auth"
_ "github.com/lib/pq"
)
func main() {
var dbName string = "DatabaseName"
var dbUser string = "DatabaseUser"
var dbHost string = "postgresmycluster.cluster-123456789012.us-east-1.rds.amazonaws.com"
var dbPort int = 5432
var dbEndpoint string = fmt.Sprintf("%s:%d", dbHost, dbPort)
var region string = "us-east-1"
cfg, err := config.LoadDefaultConfig(context.TODO())
if err != nil {
panic("configuration error: " + err.Error())
}
authenticationToken, err := auth.BuildAuthToken(
context.TODO(), dbEndpoint, region, dbUser, cfg.Credentials)
if err != nil {
panic("failed to create authentication token: " + err.Error())
}
dsn := fmt.Sprintf("host=%s port=%d user=%s password=%s dbname=%s",
dbHost, dbPort, dbUser, authenticationToken, dbName,
)
db, err := sql.Open("postgres", dsn)
if err != nil {
panic(err)
}
err = db.Ping()
if err != nil {
panic(err)
}
}
```
Se você quiser se conectar a um cluster de banco de dados por meio de um proxy, consulte [Conectar-se a um banco de dados usando autenticação do IAM](rds-proxy-connecting.md#rds-proxy-connecting-iam).
## Conectar-se usando a autenticação do IAM e o AWS SDK para Go V1.
Conecte-se a uma instância de banco de dados usando a autenticação do IAM e o AWS SDK para Go V1
O exemplo de código a seguir mostra como gerar um token de autenticação e usá-lo para se conectar a um cluster de banco de dados.
Esse código se conecta a um cluster de banco de dados Aurora MySQL.
```
package main
import (
"database/sql"
"fmt"
"log"
"github.com/aws/aws-sdk-go/aws/credentials"
"github.com/aws/aws-sdk-go/service/rds/rdsutils"
_ "github.com/go-sql-driver/mysql"
)
func main() {
dbName := "app"
dbUser := "jane_doe"
dbHost := "mysqlcluster.cluster-123456789012.us-east-1.rds.amazonaws.com"
dbPort := 3306
dbEndpoint := fmt.Sprintf("%s:%d", dbHost, dbPort)
region := "us-east-1"
creds := credentials.NewEnvCredentials()
authToken, err := rdsutils.BuildAuthToken(dbEndpoint, region, dbUser, creds)
if err != nil {
panic(err)
}
dsn := fmt.Sprintf("%s:%s@tcp(%s)/%s?tls=true&allowCleartextPasswords=true",
dbUser, authToken, dbEndpoint, dbName,
)
db, err := sql.Open("mysql", dsn)
if err != nil {
panic(err)
}
err = db.Ping()
if err != nil {
panic(err)
}
}
```
Esse código se conecta a um cluster de banco de dados Aurora PostgreSQL.
```
package main
import (
"database/sql"
"fmt"
"github.com/aws/aws-sdk-go/aws/credentials"
"github.com/aws/aws-sdk-go/service/rds/rdsutils"
_ "github.com/lib/pq"
)
func main() {
dbName := "app"
dbUser := "jane_doe"
dbHost := "postgresmycluster.cluster-123456789012.us-east-1.rds.amazonaws.com"
dbPort := 5432
dbEndpoint := fmt.Sprintf("%s:%d", dbHost, dbPort)
region := "us-east-1"
creds := credentials.NewEnvCredentials()
authToken, err := rdsutils.BuildAuthToken(dbEndpoint, region, dbUser, creds)
if err != nil {
panic(err)
}
dsn := fmt.Sprintf("host=%s port=%d user=%s password=%s dbname=%s",
dbHost, dbPort, dbUser, authToken, dbName,
)
db, err := sql.Open("postgres", dsn)
if err != nil {
panic(err)
}
err = db.Ping()
if err != nil {
panic(err)
}
}
```
Se você quiser se conectar a um cluster de banco de dados por meio de um proxy, consulte [Conectar-se a um banco de dados usando autenticação do IAM](rds-proxy-connecting.md#rds-proxy-connecting-iam).
# Conectar-se ao cluster de banco de dados usando a autenticação do IAM e o AWS SDK para Java
Você pode se conectar a um cluster de banco de dados Aurora MySQL ou Aurora PostgreSQL com a AWS SDK para Java, conforme descrito a seguir.
**Pré-requisitos**
Veja a seguir os pré-requisitos para se conectar ao cluster de banco de dados usando a autenticação do IAM:
+ [Habilitar e desabilitar a autenticação de banco de dados do IAM](UsingWithRDS.IAMDBAuth.Enabling.md)
+ [Criar e usar uma política do IAM para acesso do banco de dados do IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md)
+ [Criar uma conta de banco de dados usando autenticação do IAM](UsingWithRDS.IAMDBAuth.DBAccounts.md)
+ [Configurar o AWS SDK for Java](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/setup-install.html)
Consulte exemplos de como usar o SDK para Java 2.x em [Amazon RDS examples using SDK for Java 2.x](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/java_rds_code_examples.html). Você também pode usar o AWS Advanced JDBC Wrapper. Para isso, consulte a documentação do [AWS Advanced JDBC Wrapper](https://github.com/aws/aws-advanced-jdbc-wrapper/blob/main/docs/Documentation.md).
**Topics**
+ [Gerar um token de autenticação do IAM](#UsingWithRDS.IAMDBAuth.Connecting.Java.AuthToken)
+ [Criar manualmente um token de autenticação do IAM](#UsingWithRDS.IAMDBAuth.Connecting.Java.AuthToken2)
+ [Conexão ao cluster de banco de dados](#UsingWithRDS.IAMDBAuth.Connecting.Java.AuthToken.Connect)
## Gerar um token de autenticação do IAM
Se estiver escrevendo programas usando o AWS SDK para Java, você pode obter um token de autenticação assinado usando a classe `RdsIamAuthTokenGenerator`. O uso dessa classe exige que você forneça as credenciais da AWS. Para fazer isso, crie uma instância da classe `DefaultAWSCredentialsProviderChain`. `DefaultAWSCredentialsProviderChain` usa a primeira chave de acesso da AWS e a chave secreta encontradas na [cadeia de fornecedores de credencial padrão](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/credentials.html#credentials-default). Para ter mais informações sobre chaves de acesso da AWS, consulte [Gerenciar chaves de acesso para usuários](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html).
**nota**
Não é possível usar um registro DNS personalizado do Route 53 em vez do endpoint do cluster de banco de dados para gerar o token de autenticação.
Após criar uma instância de `RdsIamAuthTokenGenerator`, você pode chamar o método `getAuthToken` para obter um token assinado. Forneça a região da AWS, o nome do host, o número da porta e o nome do usuário. O exemplo de código a seguir ilustra como fazer isso.
```
package com.amazonaws.codesamples;
import com.amazonaws.auth.DefaultAWSCredentialsProviderChain;
import com.amazonaws.services.rds.auth.GetIamAuthTokenRequest;
import com.amazonaws.services.rds.auth.RdsIamAuthTokenGenerator;
public class GenerateRDSAuthToken {
public static void main(String[] args) {
String region = "us-west-2";
String hostname = "rdsmysql.123456789012.us-west-2.rds.amazonaws.com";
String port = "3306";
String username = "jane_doe";
System.out.println(generateAuthToken(region, hostname, port, username));
}
static String generateAuthToken(String region, String hostName, String port, String username) {
RdsIamAuthTokenGenerator generator = RdsIamAuthTokenGenerator.builder()
.credentials(new DefaultAWSCredentialsProviderChain())
.region(region)
.build();
String authToken = generator.getAuthToken(
GetIamAuthTokenRequest.builder()
.hostname(hostName)
.port(Integer.parseInt(port))
.userName(username)
.build());
return authToken;
}
}
```
## Criar manualmente um token de autenticação do IAM
No Java, o modo mais fácil de gerar um token de autenticação é usar o `RdsIamAuthTokenGenerator`. Essa classe cria um token de autenticação para você e assina-o usando o Signature da AWS versão 4. Para ter mais informações, consulte [Processo de assinatura do Signature versão 4](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html) na *Referência geral da AWS*.
No entanto, você também pode construir e assinar um token de autenticação manualmente, conforme mostrado no exemplo de código a seguir.
```
package com.amazonaws.codesamples;
import com.amazonaws.SdkClientException;
import com.amazonaws.auth.DefaultAWSCredentialsProviderChain;
import com.amazonaws.auth.SigningAlgorithm;
import com.amazonaws.util.BinaryUtils;
import org.apache.commons.lang3.StringUtils;
import javax.crypto.Mac;
import javax.crypto.spec.SecretKeySpec;
import java.nio.charset.Charset;
import java.security.MessageDigest;
import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.SortedMap;
import java.util.TreeMap;
import static com.amazonaws.auth.internal.SignerConstants.AWS4_TERMINATOR;
import static com.amazonaws.util.StringUtils.UTF8;
public class CreateRDSAuthTokenManually {
public static String httpMethod = "GET";
public static String action = "connect";
public static String canonicalURIParameter = "/";
public static SortedMap canonicalQueryParameters = new TreeMap();
public static String payload = StringUtils.EMPTY;
public static String signedHeader = "host";
public static String algorithm = "AWS4-HMAC-SHA256";
public static String serviceName = "rds-db";
public static String requestWithoutSignature;
public static void main(String[] args) throws Exception {
String region = "us-west-2";
String instanceName = "rdsmysql.123456789012.us-west-2.rds.amazonaws.com";
String port = "3306";
String username = "jane_doe";
Date now = new Date();
String date = new SimpleDateFormat("yyyyMMdd").format(now);
String dateTimeStamp = new SimpleDateFormat("yyyyMMdd'T'HHmmss'Z'").format(now);
DefaultAWSCredentialsProviderChain creds = new DefaultAWSCredentialsProviderChain();
String awsAccessKey = creds.getCredentials().getAWSAccessKeyId();
String awsSecretKey = creds.getCredentials().getAWSSecretKey();
String expiryMinutes = "900";
System.out.println("Step 1: Create a canonical request:");
String canonicalString = createCanonicalString(username, awsAccessKey, date, dateTimeStamp, region, expiryMinutes, instanceName, port);
System.out.println(canonicalString);
System.out.println();
System.out.println("Step 2: Create a string to sign:");
String stringToSign = createStringToSign(dateTimeStamp, canonicalString, awsAccessKey, date, region);
System.out.println(stringToSign);
System.out.println();
System.out.println("Step 3: Calculate the signature:");
String signature = BinaryUtils.toHex(calculateSignature(stringToSign, newSigningKey(awsSecretKey, date, region, serviceName)));
System.out.println(signature);
System.out.println();
System.out.println("Step 4: Add the signing info to the request");
System.out.println(appendSignature(signature));
System.out.println();
}
//Step 1: Create a canonical request date should be in format YYYYMMDD and dateTime should be in format YYYYMMDDTHHMMSSZ
public static String createCanonicalString(String user, String accessKey, String date, String dateTime, String region, String expiryPeriod, String hostName, String port) throws Exception {
canonicalQueryParameters.put("Action", action);
canonicalQueryParameters.put("DBUser", user);
canonicalQueryParameters.put("X-Amz-Algorithm", "AWS4-HMAC-SHA256");
canonicalQueryParameters.put("X-Amz-Credential", accessKey + "%2F" + date + "%2F" + region + "%2F" + serviceName + "%2Faws4_request");
canonicalQueryParameters.put("X-Amz-Date", dateTime);
canonicalQueryParameters.put("X-Amz-Expires", expiryPeriod);
canonicalQueryParameters.put("X-Amz-SignedHeaders", signedHeader);
String canonicalQueryString = "";
while(!canonicalQueryParameters.isEmpty()) {
String currentQueryParameter = canonicalQueryParameters.firstKey();
String currentQueryParameterValue = canonicalQueryParameters.remove(currentQueryParameter);
canonicalQueryString = canonicalQueryString + currentQueryParameter + "=" + currentQueryParameterValue;
if (!currentQueryParameter.equals("X-Amz-SignedHeaders")) {
canonicalQueryString += "&";
}
}
String canonicalHeaders = "host:" + hostName + ":" + port + '\n';
requestWithoutSignature = hostName + ":" + port + "/?" + canonicalQueryString;
String hashedPayload = BinaryUtils.toHex(hash(payload));
return httpMethod + '\n' + canonicalURIParameter + '\n' + canonicalQueryString + '\n' + canonicalHeaders + '\n' + signedHeader + '\n' + hashedPayload;
}
//Step 2: Create a string to sign using sig v4
public static String createStringToSign(String dateTime, String canonicalRequest, String accessKey, String date, String region) throws Exception {
String credentialScope = date + "/" + region + "/" + serviceName + "/aws4_request";
return algorithm + '\n' + dateTime + '\n' + credentialScope + '\n' + BinaryUtils.toHex(hash(canonicalRequest));
}
//Step 3: Calculate signature
/**
* Step 3 of the &AWS; Signature version 4 calculation. It involves deriving
* the signing key and computing the signature. Refer to
* http://docs.aws.amazon
* .com/general/latest/gr/sigv4-calculate-signature.html
*/
public static byte[] calculateSignature(String stringToSign,
byte[] signingKey) {
return sign(stringToSign.getBytes(Charset.forName("UTF-8")), signingKey,
SigningAlgorithm.HmacSHA256);
}
public static byte[] sign(byte[] data, byte[] key,
SigningAlgorithm algorithm) throws SdkClientException {
try {
Mac mac = algorithm.getMac();
mac.init(new SecretKeySpec(key, algorithm.toString()));
return mac.doFinal(data);
} catch (Exception e) {
throw new SdkClientException(
"Unable to calculate a request signature: "
+ e.getMessage(), e);
}
}
public static byte[] newSigningKey(String secretKey,
String dateStamp, String regionName, String serviceName) {
byte[] kSecret = ("AWS4" + secretKey).getBytes(Charset.forName("UTF-8"));
byte[] kDate = sign(dateStamp, kSecret, SigningAlgorithm.HmacSHA256);
byte[] kRegion = sign(regionName, kDate, SigningAlgorithm.HmacSHA256);
byte[] kService = sign(serviceName, kRegion,
SigningAlgorithm.HmacSHA256);
return sign(AWS4_TERMINATOR, kService, SigningAlgorithm.HmacSHA256);
}
public static byte[] sign(String stringData, byte[] key,
SigningAlgorithm algorithm) throws SdkClientException {
try {
byte[] data = stringData.getBytes(UTF8);
return sign(data, key, algorithm);
} catch (Exception e) {
throw new SdkClientException(
"Unable to calculate a request signature: "
+ e.getMessage(), e);
}
}
//Step 4: append the signature
public static String appendSignature(String signature) {
return requestWithoutSignature + "&X-Amz-Signature=" + signature;
}
public static byte[] hash(String s) throws Exception {
try {
MessageDigest md = MessageDigest.getInstance("SHA-256");
md.update(s.getBytes(UTF8));
return md.digest();
} catch (Exception e) {
throw new SdkClientException(
"Unable to compute hash while signing request: "
+ e.getMessage(), e);
}
}
}
```
## Conexão ao cluster de banco de dados
O exemplo de código a seguir mostra como gerar um token de autenticação e usá-lo para se conectar a um cluster que esteja executando o Aurora MySQL.
Para executar esse exemplo de código, você precisa do [AWS SDK para Java](https://aws.amazon.com/sdk-for-java/), encontrado no site AWS. Além disso, você precisa do seguinte:
+ MySQL Connector/J. Este exemplo de código foi testado com `mysql-connector-java-5.1.33-bin.jar`.
+ Um certificado intermediário do Amazon Aurora específico de uma região da AWS. (Para ter mais informações, consulte [Usar SSL/TLS para criptografar uma conexão com um cluster de banco de dados](UsingWithRDS.SSL.md).) No tempo de execução, o carregador de classe procura o certificado no mesmo diretório do exemplo de código Java para que possa encontrá-lo.
+ Modifique os valores das seguintes variáveis, conforme necessário:
+ `RDS_INSTANCE_HOSTNAME`: o nome do host do cluster de banco de dados que você deseja acessar.
+ `RDS_INSTANCE_PORT`: o número da porta usado na conexão com o cluster de banco de dados PostgreSQL.
+ `REGION_NAME`: a região da AWS na qual o cluster do banco de dados está em execução.
+ `DB_USER`: a conta de banco de dados que você deseja acessar.
+ `SSL_CERTIFICATE`: um certificado SSL para o Amazon Aurora que é específico de uma região da AWS.
Para baixar o certificado para a sua região da AWS, consulte [Usar SSL/TLS para criptografar uma conexão com um cluster de banco de dados](UsingWithRDS.SSL.md). Coloque o certificado do SSL no mesmo diretório que esse arquivo do programa Java para que o carregador de classe possa encontrar o certificado no tempo de execução.
Esse exemplo de código obtém as credenciais da AWS a partir da[cadeia de fornecedores de credencial padrão](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/credentials.html#credentials-default).
**nota**
Especifique uma senha para `DEFAULT_KEY_STORE_PASSWORD` diferente do prompt mostrado aqui como prática recomendada de segurança.
```
package com.amazonaws.samples;
import com.amazonaws.services.rds.auth.RdsIamAuthTokenGenerator;
import com.amazonaws.services.rds.auth.GetIamAuthTokenRequest;
import com.amazonaws.auth.BasicAWSCredentials;
import com.amazonaws.auth.DefaultAWSCredentialsProviderChain;
import com.amazonaws.auth.AWSStaticCredentialsProvider;
import java.io.File;
import java.io.FileOutputStream;
import java.io.InputStream;
import java.security.KeyStore;
import java.security.cert.CertificateFactory;
import java.security.cert.X509Certificate;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.Statement;
import java.util.Properties;
import java.net.URL;
public class IAMDatabaseAuthenticationTester {
//&AWS; Credentials of the IAM user with policy enabling IAM Database Authenticated access to the db by the db user.
private static final DefaultAWSCredentialsProviderChain creds = new DefaultAWSCredentialsProviderChain();
private static final String AWS_ACCESS_KEY = creds.getCredentials().getAWSAccessKeyId();
private static final String AWS_SECRET_KEY = creds.getCredentials().getAWSSecretKey();
//Configuration parameters for the generation of the IAM Database Authentication token
private static final String RDS_INSTANCE_HOSTNAME = "rdsmysql.123456789012.us-west-2.rds.amazonaws.com";
private static final int RDS_INSTANCE_PORT = 3306;
private static final String REGION_NAME = "us-west-2";
private static final String DB_USER = "jane_doe";
private static final String JDBC_URL = "jdbc:mysql://" + RDS_INSTANCE_HOSTNAME + ":" + RDS_INSTANCE_PORT;
private static final String SSL_CERTIFICATE = "rds-ca-2019-us-west-2.pem";
private static final String KEY_STORE_TYPE = "JKS";
private static final String KEY_STORE_PROVIDER = "SUN";
private static final String KEY_STORE_FILE_PREFIX = "sys-connect-via-ssl-test-cacerts";
private static final String KEY_STORE_FILE_SUFFIX = ".jks";
private static final String DEFAULT_KEY_STORE_PASSWORD = "changeit";
public static void main(String[] args) throws Exception {
//get the connection
Connection connection = getDBConnectionUsingIam();
//verify the connection is successful
Statement stmt= connection.createStatement();
ResultSet rs=stmt.executeQuery("SELECT 'Success!' FROM DUAL;");
while (rs.next()) {
String id = rs.getString(1);
System.out.println(id); //Should print "Success!"
}
//close the connection
stmt.close();
connection.close();
clearSslProperties();
}
/**
* This method returns a connection to the db instance authenticated using IAM Database Authentication
* @return
* @throws Exception
*/
private static Connection getDBConnectionUsingIam() throws Exception {
setSslProperties();
return DriverManager.getConnection(JDBC_URL, setMySqlConnectionProperties());
}
/**
* This method sets the mysql connection properties which includes the IAM Database Authentication token
* as the password. It also specifies that SSL verification is required.
* @return
*/
private static Properties setMySqlConnectionProperties() {
Properties mysqlConnectionProperties = new Properties();
mysqlConnectionProperties.setProperty("verifyServerCertificate","true");
mysqlConnectionProperties.setProperty("useSSL", "true");
mysqlConnectionProperties.setProperty("user",DB_USER);
mysqlConnectionProperties.setProperty("password",generateAuthToken());
return mysqlConnectionProperties;
}
/**
* This method generates the IAM Auth Token.
* An example IAM Auth Token would look like follows:
* btusi123---cmz7kenwo2ye---rds---cn-north-1.amazonaws.com.rproxy.goskope.com.cn:3306/?Action=connect&DBUser=iamtestuser&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20171003T010726Z&X-Amz-SignedHeaders=host&X-Amz-Expires=899&X-Amz-Credential=AKIAPFXHGVDI5RNFO4AQ%2F20171003%2Fcn-north-1%2Frds-db%2Faws4_request&X-Amz-Signature=f9f45ef96c1f770cdad11a53e33ffa4c3730bc03fdee820cfdf1322eed15483b
* @return
*/
private static String generateAuthToken() {
BasicAWSCredentials awsCredentials = new BasicAWSCredentials(AWS_ACCESS_KEY, AWS_SECRET_KEY);
RdsIamAuthTokenGenerator generator = RdsIamAuthTokenGenerator.builder()
.credentials(new AWSStaticCredentialsProvider(awsCredentials)).region(REGION_NAME).build();
return generator.getAuthToken(GetIamAuthTokenRequest.builder()
.hostname(RDS_INSTANCE_HOSTNAME).port(RDS_INSTANCE_PORT).userName(DB_USER).build());
}
/**
* This method sets the SSL properties which specify the key store file, its type and password:
* @throws Exception
*/
private static void setSslProperties() throws Exception {
System.setProperty("javax.net.ssl.trustStore", createKeyStoreFile());
System.setProperty("javax.net.ssl.trustStoreType", KEY_STORE_TYPE);
System.setProperty("javax.net.ssl.trustStorePassword", DEFAULT_KEY_STORE_PASSWORD);
}
/**
* This method returns the path of the Key Store File needed for the SSL verification during the IAM Database Authentication to
* the db instance.
* @return
* @throws Exception
*/
private static String createKeyStoreFile() throws Exception {
return createKeyStoreFile(createCertificate()).getPath();
}
/**
* This method generates the SSL certificate
* @return
* @throws Exception
*/
private static X509Certificate createCertificate() throws Exception {
CertificateFactory certFactory = CertificateFactory.getInstance("X.509");
URL url = new File(SSL_CERTIFICATE).toURI().toURL();
if (url == null) {
throw new Exception();
}
try (InputStream certInputStream = url.openStream()) {
return (X509Certificate) certFactory.generateCertificate(certInputStream);
}
}
/**
* This method creates the Key Store File
* @param rootX509Certificate - the SSL certificate to be stored in the KeyStore
* @return
* @throws Exception
*/
private static File createKeyStoreFile(X509Certificate rootX509Certificate) throws Exception {
File keyStoreFile = File.createTempFile(KEY_STORE_FILE_PREFIX, KEY_STORE_FILE_SUFFIX);
try (FileOutputStream fos = new FileOutputStream(keyStoreFile.getPath())) {
KeyStore ks = KeyStore.getInstance(KEY_STORE_TYPE, KEY_STORE_PROVIDER);
ks.load(null);
ks.setCertificateEntry("rootCaCertificate", rootX509Certificate);
ks.store(fos, DEFAULT_KEY_STORE_PASSWORD.toCharArray());
}
return keyStoreFile;
}
/**
* This method clears the SSL properties.
* @throws Exception
*/
private static void clearSslProperties() throws Exception {
System.clearProperty("javax.net.ssl.trustStore");
System.clearProperty("javax.net.ssl.trustStoreType");
System.clearProperty("javax.net.ssl.trustStorePassword");
}
}
```
Se você quiser se conectar a um cluster de banco de dados por meio de um proxy, consulte [Conectar-se a um banco de dados usando autenticação do IAM](rds-proxy-connecting.md#rds-proxy-connecting-iam).
# Conectar-se ao cluster de banco de dados usando a autenticação do IAM e o AWS SDK para Python (Boto3)
Você pode se conectar a um cluster de banco de dados Aurora MySQL ou Aurora PostgreSQL com a AWS SDK para Python (Boto3), conforme descrito a seguir.
**Pré-requisitos**
Veja a seguir os pré-requisitos para se conectar ao cluster de banco de dados usando a autenticação do IAM:
+ [Habilitar e desabilitar a autenticação de banco de dados do IAM](UsingWithRDS.IAMDBAuth.Enabling.md)
+ [Criar e usar uma política do IAM para acesso do banco de dados do IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md)
+ [Criar uma conta de banco de dados usando autenticação do IAM](UsingWithRDS.IAMDBAuth.DBAccounts.md)
Além disso, verifique se as bibliotecas importadas no código de exemplo existem no sistema.
**Exemplos**
Os exemplos de código usam perfis para credenciais compartilhadas. Para obter informações sobre a especificação de credenciais, consulte [Credenciais](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/credentials.html) na documentação AWS SDK para Python (Boto3).
O exemplo de código a seguir mostra como gerar um token de autenticação e usá-lo para se conectar a um cluster de banco de dados.
Para executar esse exemplo de código, você precisa do [AWS SDK para Python (Boto3)](https://aws.amazon.com/sdk-for-python/), encontrado no site AWS.
Modifique os valores das seguintes variáveis, conforme necessário:
+ `ENDPOINT`: o endpoint do cluster de banco de dados que você deseja acessar
+ `PORT`: o número da porta usada para se conectar ao cluster de banco de dados
+ `USER`: a conta de banco de dados que você deseja acessar
+ `REGION`: a região da AWS na qual o cluster do banco de dados está em execução.
+ `DBNAME`: o banco de dados que você deseja acessar
+ `SSLCERTIFICATE`: o caminho completo para o certificado SSL do Amazon Aurora
Para `ssl_ca`, defina um certificado SSL. Para baixar um certificado SSL, consulte [Usar SSL/TLS para criptografar uma conexão com um cluster de banco de dados](UsingWithRDS.SSL.md).
**nota**
Não é possível usar um registro DNS personalizado do Route 53 em vez do endpoint do cluster de banco de dados para gerar o token de autenticação.
Esse código se conecta a um cluster de banco de dados Aurora MySQL.
Antes de executar esse código, instale o driver PyMySQL seguindo as instruções no [Python Package Index](https://pypi.org/project/PyMySQL/).
```
import pymysql
import sys
import boto3
import os
ENDPOINT="mysqlcluster.cluster-123456789012.us-east-1.rds.amazonaws.com"
PORT="3306"
USER="jane_doe"
REGION="us-east-1"
DBNAME="mydb"
os.environ['LIBMYSQL_ENABLE_CLEARTEXT_PLUGIN'] = '1'
#gets the credentials from .aws/credentials
session = boto3.Session(profile_name='default')
client = session.client('rds')
token = client.generate_db_auth_token(DBHostname=ENDPOINT, Port=PORT, DBUsername=USER, Region=REGION)
try:
conn = pymysql.connect(auth_plugin_map={'mysql_clear_password':None},host=ENDPOINT, user=USER, password=token, port=PORT, database=DBNAME, ssl_ca='SSLCERTIFICATE', ssl_verify_identity=True, ssl_verify_cert=True)
cur = conn.cursor()
cur.execute("""SELECT now()""")
query_results = cur.fetchall()
print(query_results)
except Exception as e:
print("Database connection failed due to {}".format(e))
```
Esse código se conecta a um cluster de banco de dados Aurora PostgreSQL.
Antes de executar esse código, instale `psycopg2`, seguindo as instruções na [documentação de Psycopg](https://pypi.org/project/psycopg2/).
```
import psycopg2
import sys
import boto3
import os
ENDPOINT="postgresmycluster.cluster-123456789012.us-east-1.rds.amazonaws.com"
PORT="5432"
USER="jane_doe"
REGION="us-east-1"
DBNAME="mydb"
#gets the credentials from .aws/credentials
session = boto3.Session(profile_name='RDSCreds')
client = session.client('rds')
token = client.generate_db_auth_token(DBHostname=ENDPOINT, Port=PORT, DBUsername=USER, Region=REGION)
try:
conn = psycopg2.connect(host=ENDPOINT, port=PORT, database=DBNAME, user=USER, password=token, sslrootcert="SSLCERTIFICATE")
cur = conn.cursor()
cur.execute("""SELECT now()""")
query_results = cur.fetchall()
print(query_results)
except Exception as e:
print("Database connection failed due to {}".format(e))
```
Se você quiser se conectar a um cluster de banco de dados por meio de um proxy, consulte [Conectar-se a um banco de dados usando autenticação do IAM](rds-proxy-connecting.md#rds-proxy-connecting-iam).
# Solucionar problemas referentes à autenticação de banco de dados do IAM
A seguir, é possível encontrar ideias de solução de problemas para alguns problemas comuns de autenticação de banco de dados do IAM e informações sobre logs e métricas do CloudWatch para autenticação de banco de dados do IAM.
## Exportar logs de erros de autenticação de banco de dados do IAM para o CloudWatch Logs
Os logs de erros de autenticação de banco de dados do IAM são armazenados no host do banco de dados e podem ser exportados para sua conta do CloudWatch Logs. Use os logs e os métodos de correção nesta página para solucionar problemas de autenticação de banco de dados do IAM.
Você pode habilitar as exportações de log para o CloudWatch Logs por meio do console, da AWS CLI e da API do RDS. Para obter instruções sobre o console, consulte [Publicação de logs de banco de dados no Amazon CloudWatch Logs](USER_LogAccess.Procedural.UploadtoCloudWatch.md).
Para exportar logs de erros de autenticação de banco de dados do IAM para o CloudWatch Logs ao criar um cluster de banco de dados por meio da AWS CLI, use o seguinte comando:
```
aws rds create-db-cluster --db-cluster-identifier mydbinstance \
--region us-east-1 \
--engine postgres \
--engine-version 16 \
--master-username master \
--master-user-password password \
--publicly-accessible \
--enable-iam-database-authentication \
--enable-cloudwatch-logs-exports=iam-db-auth-error
```
Para exportar logs de erros de autenticação de banco de dados do IAM para o CloudWatch Logs ao modificar um cluster de banco de dados por meio da AWS CLI, use o seguinte comando:
```
aws rds modify-db-cluster --db-instance-identifier mydbcluster \
--region us-east-1 \
--cloudwatch-logs-export-configuration '{"EnableLogTypes":["iam-db-auth-error"]}'
```
Para verificar se o cluster de banco de dados está exportando logs de autenticação de banco de dados do IAM para o CloudWatch Logs, confira se o parâmetro `EnabledCloudwatchLogsExports` está definido como `iam-db-auth-error` na saída do comando `describe-db-instances`.
```
aws rds describe-db-cluster --region us-east-1 --db-cluster-identifier mydbcluster
...
"EnabledCloudwatchLogsExports": [
"iam-db-auth-error"
],
...
```
## Métricas do CloudWatch de autenticação de banco de dados do IAM
O Amazon Aurora fornece métricas quase em tempo real sobre a autenticação de banco de dados do IAM para sua conta do Amazon CloudWatch. A seguinte tabela lista as métricas de autenticação de banco de dados do IAM disponíveis usando o CloudWatch:
| Métrica | Descrição |
| --- | --- |
| `IamDbAuthConnectionRequests` | Número total de solicitações de conexão feitas com a autenticação de banco de dados do IAM. |
| `IamDbAuthConnectionSuccess` | Número total de solicitações de autenticação de banco de dados do IAM bem-sucedidas. |
| `IamDbAuthConnectionFailure` | Número total de solicitações de autenticação de banco de dados do IAM malsucedidas. |
| `IamDbAuthConnectionFailureInvalidToken` | Número total de solicitações de autenticação de banco de dados do IAM malsucedidas devido a token inválido. |
| `IamDbAuthConnectionFailureInsufficientPermissions` | Número total de solicitações de autenticação de banco de dados do IAM malsucedidas devido a políticas ou permissões incorretas. |
| `IamDbAuthConnectionFailureThrottling` | Número total de solicitações de autenticação de banco de dados do IAM malsucedidas devido ao controle de utilização da autenticação de banco de dados do IAM. |
| `IamDbAuthConnectionFailureServerError` | Número total de solicitações de autenticação de banco de dados do IAM malsucedidas devido a um erro interno do servidor no recurso de autenticação de banco de dados do IAM. |
## Problemas e soluções comuns de
Você pode encontrar os problemas a seguir ao usar a autenticação de banco de dados do IAM. Use as etapas de correção na tabela para resolver os problemas:
| Erro | Métrica(s) | Causa | Solução |
| --- | --- | --- | --- |
| `[ERROR] Failed to authenticate the connection request for user db_user because the provided token is malformed or otherwise invalid. (Status Code: 400, Error Code: InvalidToken)` | `IamDbAuthConnectionFailure` `IamDbAuthConnectionFailureInvalidToken` | O token de autenticação de banco de dados do IAM na solicitação de conexão não é um token SigV4a válido ou não está formatado corretamente. | Verifique a estratégia de geração de tokens em sua aplicação. Em alguns casos, observe se você está passando o token com uma formatação válida. Truncar o token (ou formatar incorretamente a string) tornará o token inválido. |
| `[ERROR] Failed to authenticate the connection request for user db_user because the token age is longer than 15 minutes. (Status Code: 400, Error Code:ExpiredToken)` | `IamDbAuthConnectionFailure` `IamDbAuthConnectionFailureInvalidToken` | O token de autenticação de banco de dados do IAM expirou. Os tokens são válidos somente por 15 minutos. | Verifique a lógica de armazenamento em cache e/ou a reutilização de tokens em sua aplicação. Você não deve reutilizar tokens com mais de 15 minutos. |
| `[ERROR] Failed to authorize the connection request for user db_user because the IAM policy assumed by the caller 'arn:aws:sts::123456789012:assumed-role/ / ' is not authorized to perform `rds-db:connect` on the DB instance. (Status Code: 403, Error Code:NotAuthorized)` | `IamDbAuthConnectionFailure` `IamDbAuthConnectionFailureInsufficientPermissions` | Esse erro pode ocorrer devido aos seguintes motivos: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAMDBAuth.Troubleshooting.html) | Verifique o perfil e/ou a política do IAM que você está assumindo em sua aplicação. Você deve assumir a mesma política para gerar o token e para se conectar ao banco de dados. |
| `[ERROR] Failed to authorize the connection request for user db_user due to IAM DB authentication throttling. (Status Code: 429, Error Code: ThrottlingException)` | `IamDbAuthConnectionFailure` `IamDbAuthConnectionFailureThrottling` | Você está fazendo muitas solicitações de conexão ao banco de dados em um curto espaço de tempo. O limite de controle de utilização da autenticação de banco de dados do IAM é duzentas conexões por segundo. | Reduza a taxa de estabelecimento de novas conexões por meio da autenticação do IAM. Considere implementar o agrupamento de conexões usando o RDS Proxy para reutilizar as conexões estabelecidas em sua aplicação. |
| `[ERROR] Failed to authorize the connection request for user db_user due to an internal IAM DB authentication error. (Status Code: 500, Error Code: InternalError)` | `IamDbAuthConnectionFailure` `IamDbAuthConnectionFailureThrottling` | Houve um erro interno ao autorizar a conexão do banco de dados com a autenticação de banco de dados do IAM. | Entre em contato com https://aws.amazon.com/premiumsupport/ para investigar o problema. |
# Solução de problemas de identidade e acesso do Amazon Aurora
Use as seguintes informações para ajudar a diagnosticar e corrigir problemas comuns que podem ser encontrados ao trabalhar com o Aurora e o IAM.
**Topics**
+ [Não estou autorizado a realizar uma ação no Aurora](#security_iam_troubleshoot-no-permissions)
+ [Não estou autorizado a executar iam:PassRole](#security_iam_troubleshoot-passrole)
+ [Quero permitir que pessoas fora de minha conta da AWS acessem meus recursos do Aurora](#security_iam_troubleshoot-cross-account-access)
## Não estou autorizado a realizar uma ação no Aurora
Se o Console de gerenciamento da AWS informar que você não está autorizado a executar uma ação, será necessário entrar em contato com o administrador para obter assistência. Seu administrador é a pessoa que forneceu a você suas credenciais de início de sessão.
O exemplo de erro a seguir ocorre quando o usuário `mateojackson` tenta usar o console para visualizar detalhes sobre um *widget*, mas não tem as permissões `rds:GetWidget`.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: rds:GetWidget on resource: my-example-widget
```
Neste caso, Mateo pede ao administrador para atualizar suas políticas para permitir a ele o acesso ao recurso `my-example-widget` usando a ação `rds:GetWidget`.
## Não estou autorizado a executar iam:PassRole
Se você receber uma mensagem de erro informando que você não está autorizado a executar a ação `iam:PassRole`, entre em contato com o administrador para obter assistência. Caso seu administrador seja a pessoa que forneceu suas credenciais de início de sessão. Peça a essa pessoa para atualizar suas políticas para permitir que você passe uma função para o Aurora.
Alguns serviços da AWS permitem que você passe uma função existente para o serviço, em vez de criar um novo perfil de serviço ou perfil vinculado ao serviço. Para fazer isso, um usuário deve ter permissões para passar a função para o serviço.
O erro de exemplo a seguir ocorre quando uma usuária chamada `marymajor` tenta usar o console para executar uma ação no Aurora. No entanto, a ação exige que o serviço tenha permissões concedidas por um perfil de serviço. Mary não tem permissões para passar a função para o serviço.
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
Neste caso, Mary pede ao administrador para atualizar suas políticas para permitir que ela execute a ação `iam:PassRole`.
## Quero permitir que pessoas fora de minha conta da AWS acessem meus recursos do Aurora
É possível criar um perfil que os usuários de outras contas ou pessoas fora da organização podem usar para acessar seus recursos. É possível especificar quem é confiável para assumir o perfil. Para serviços que oferecem compatibilidade com políticas baseadas em recursos ou listas de controle de acesso (ACLs), é possível usar essas políticas para conceder às pessoas acesso aos seus recursos.
Para saber mais, consulte o seguinte:
+ Para saber se o Aurora oferece suporte a esses recursos, consulte [Como o Amazon Aurora funciona com o IAM](security_iam_service-with-iam.md).
+ Para saber como conceder acesso a seus recursos em todas as contas da AWS pertencentes a você, consulte [Fornecer acesso a um usuário do IAM em outra conta da AWS pertencente a você](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) no *Guia de usuário do IAM*.
+ Para saber como conceder acesso aos recursos para contas da AWS de terceiros, consulte [Fornecer acesso a contas da AWS pertencentes a terceiros](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) no *Guia do usuário do IAM*.
+ Para saber como conceder acesso por meio da federação de identidades, consulte [Conceder acesso a usuários autenticados externamente (federação de identidades)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) no *Guia do usuário do IAM*.
+ Para saber a diferença entre usar perfis e políticas baseadas em recursos para acesso entre contas, consulte [Como os perfis do IAM diferem de políticas baseadas em recursos](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html) no *Guia do usuário do IAM*.
# Registrar em log e monitorar no Amazon Aurora
O monitoramento é uma parte importante da manutenção da confiabilidade, da disponibilidade e da performance do Amazon Aurora e de suas soluções da AWS. É necessário coletar dados de monitoramento de todas as partes de sua solução da AWS para depurar uma falha de vários pontos com maior facilidade, caso ocorra. A AWS oferece várias ferramentas para monitorar seus recursos do Amazon Aurora e responder a possíveis incidentes:
**Alarmes do Amazon CloudWatch**
Com o uso de alarmes do Amazon CloudWatch, você observa uma única métrica durante um período especificado. Se a métrica ultrapassar um limite especificado, uma notificação será enviada para um tópico do Amazon SNS ou para uma política do AWS Auto Scaling. Os alarmes do CloudWatch não invocam ações só porque estão em um determinado estado. O estado deve ter sido alterado e mantido por uma quantidade especificada de períodos.
**AWS CloudTrailLogs do **
O CloudTrail fornece um registro de ações executadas por um usuário, perfil ou serviço da AWS no Amazon Aurora. O CloudTrail captura todas as chamadas de API para o Amazon Aurora como eventos, inclusive as chamadas do console e de chamadas do código para operações de API do Amazon RDS. Usando as informações coletadas pelo CloudTrail, é possível determinar a solicitação que foi feita ao Amazon Aurora, o endereço IP da solicitação, quem fez a solicitação, quando ela foi feita e outros detalhes. Para ter mais informações, consulte [Monitorar chamadas de API do Amazon Aurorano AWS CloudTrail](logging-using-cloudtrail.md) .
**Monitoramento avançado**
O Amazon Aurora fornece métricas em tempo real para o sistema operacional (SO) no qual o cluster de banco de dados é executado. Você pode visualizar as métricas do cluster de banco de dados usando o console ou consumir o resultado do JSON de monitoramento avançado do Amazon CloudWatch Logs em um sistema de monitoramento de sua escolha. Para ter mais informações, consulte [Monitorar métricas do SO com o monitoramento avançado](USER_Monitoring.OS.md) .
**Amazon RDS Performance Insights**
O Insights de Performance expande os recursos de monitoramento existentes do Amazon Aurora para ilustrar a performance do banco de dados e ajudar a analisar todos os problemas que o afetam. Com o painel do Performance Insights, você pode visualizar a carga do banco de dados e filtrá-la por esperas, instruções SQL, hosts ou usuários. Para ter mais informações, consulte [Monitorar a carga de banco de dados com o Performance Insights no Amazon Aurora](USER_PerfInsights.md) .
**Logs de banco de dados**
Você pode visualizar, baixar e observar os logs de banco de dados usando o Console de gerenciamento da AWS, a AWS CLI ou a API do RDS. Para ter mais informações, consulte [Monitorar arquivos de log do Amazon Aurora](USER_LogAccess.md) .
** Recomendações do Amazon Aurora**
O Amazon Aurora oferece recomendações automatizadas para recursos de banco de dados. Essas recomendações fornecem orientações de práticas recomendadas analisando a configuração, o uso e os dados de performance do cluster de banco de dados. Para ter mais informações, consulte [Recomendações do Amazon Aurora](monitoring-recommendations.md) .
** Notificação de eventos do Amazon Aurora**
OAmazon Aurora usa o Amazon Simple Notification Service (Amazon SNS) para fornecer uma notificação quando um evento do Amazon Aurora ocorre. Essas notificações podem estar em qualquer formato de notificação compatível com o Amazon SNS para uma região da AWS, como um e-mail, uma mensagem de texto ou uma chamada para um endpoint HTTP. Para ter mais informações, consulte [Trabalhar com a notificação de eventos do Amazon RDS](USER_Events.md) .
**AWS Trusted Advisor**
O Trusted Advisor conta com as práticas recomendadas aprendidas com o atendimento a centenas de milhões de clientes da AWS. O Trusted Advisor inspeciona seu ambiente da AWS e faz recomendações quando há oportunidades para economizar dinheiro, melhorar a performance e a disponibilidade do sistema e ajuda a corrigir falhas de segurança. Todos os clientes da AWS têm acesso a cinco verificações do Trusted Advisor. Os clientes com um plano de suporte Business ou Enterprise podem ver todas as verificações do Trusted Advisor.
O Trusted Advisor tem as seguintes verificações relacionadas ao Amazon Aurora:
+ Instâncias ociosas de banco de dados do Amazon Aurora
+ Risco de acesso de grupo de segurança do Amazon Aurora
+ Backups do Amazon Aurora
+ Multi-az do Amazon Aurora
+ Acessibilidade da instância de bancos de dados Aurora
Para obter mais informações sobre essas verificações, consulte [Práticas recomendadas do Trusted Advisor (verificações)](https://aws.amazon.com/premiumsupport/trustedadvisor/best-practices/).
**Streams de atividades do banco de dados**
Os fluxos de atividades de banco de dados protegem os bancos de dados de ameaças internas controlando o acesso de DBA aos fluxos de atividades de banco de dados. Assim, a coleta, transmissão, armazenamento e subsequente processamento do fluxo de atividade de banco de dados está além do acesso dos administradores de banco de dados que gerenciam o banco de dados. Os fluxos de atividades de banco de dados podem ajudar a fornecer proteções para o banco de dados e atender aos requisitos regulatórios e de conformidade. Para obter mais informações, consulte[Monitorar o Amazon Aurora com o recurso Database Activity Streams](DBActivityStreams.md) .
Para ter mais informações sobre monitoramento do Aurora, consulte [Monitorar métricas em um cluster do Amazon Aurora](MonitoringAurora.md).
# Validação de conformidade do Amazon Aurora
Auditores de terceiros avaliam a segurança e a compatibilidade do Amazon Aurora como parte de vários programas de conformidade da AWS. Isso inclui SOC, PCI, FedRAMP, HIPAA e outros.
Para obter uma lista dos serviços da AWS no escopo de programas de conformidade específicos, consulte [Serviços da AWS no escopo por programa de conformidade](https://aws.amazon.com/compliance/services-in-scope/). Para obter informações gerais, consulte [Programas de conformidade da AWS](https://aws.amazon.com/compliance/programs/).
Você pode baixar relatórios de auditoria de terceiros usando o AWS Artifact. Para obter mais informações, consulte [Baixar os relatórios no AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html).
Sua responsabilidade com relação à conformidade ao usar o Amazon Aurora é determinada pela confidencialidade dos dados, pelos objetivos de compatibilidade da organização e pelos regulamentos e leis aplicáveis. A AWS fornece os seguintes recursos para ajudar com a compatibilidade:
+ [Guias de início rápido de segurança e conformidade](https://aws.amazon.com/quickstart/?awsf.quickstart-homepage-filter=categories%23security-identity-compliance): esses guias de implantação abordam as considerações de arquitetura e fornecem etapas para a implantação de ambientes de linha de base concentrados em conformidade e segurança na AWS.
+ [Architecting for HIPAA Security and Compliance on Amazon Web Services](https://docs.aws.amazon.com/pdfs/whitepapers/latest/architecting-hipaa-security-and-compliance-on-aws/architecting-hipaa-security-and-compliance-on-aws.pdf) (Arquitetura para segurança e conformidade com HIPAA na Amazon Web Services): esse artigo técnico descreve como as empresas podem usar a AWS para criar aplicações em conformidade com os padrões HIPAA.
+ [Recursos de conformidade da AWS](https://aws.amazon.com/compliance/resources/): esta coleção de manuais e guias pode ser aplicada ao seu setor e local.
+ [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html): este produto da AWS avalia até que ponto suas configurações de recursos atendem adequadamente às práticas internas e às diretrizes e regulamentações do setor.
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html): este AWS service (Serviço da AWS) fornece uma visão abrangente do seu estado de segurança na AWS. O Security Hub CSPM usa controles de segurança para avaliar os recursos da AWS e conferir a conformidade com os padrões e as práticas recomendadas do setor de segurança. Para acessar uma lista dos serviços e controles aceitos, consulte a [Referência de controles do Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-controls-reference.html).
# Resiliência no Amazon Aurora
A infraestrutura global da AWS é criada com base em regiões da AWSe zonas de disponibilidade da AWS. As regiões fornecem várias zonas de disponibilidade separadas e isoladas fisicamente, as quais são conectadas com baixa latência, alto throughput e redes altamente redundantes. Com as zonas de disponibilidade, você pode projetar e operar aplicações e bancos de dados que executam o failover automaticamente entre as zonas de disponibilidade sem interrupção. As zonas de disponibilidade são mais altamente disponíveis, tolerantes a falhas e escaláveis que uma ou várias infraestruturas de data center tradicionais.
Para obter mais informações sobre regiões e zonas de disponibilidade da AWS, consulte [Infraestrutura global da AWS](https://aws.amazon.com/about-aws/global-infrastructure/).
Além da infraestrutura global da AWS, o Auroraoferece recursos para ajudar a oferecer suporte às suas necessidades de resiliência e backup de dados.
## Backup e restauração
O Aurora faz backup do volume de cluster automaticamente e mantém dados de restauração pela duração do *período de retenção de backup*. Os backups do Aurora são contínuos e incrementais para que você possa restaurar rapidamente em qualquer ponto do período de retenção de backup. Quando os dados do backup estão sendo gravados, não há nenhum impacto sobre a performance ou interrupção de serviço do banco de dados. Você pode especificar um período de retenção de backup, de 1 a 35 dias, ao criar ou modificar um cluster de banco de dados.
Se você quiser manter um backup além do período de retenção do backup, também será possível fazer um snapshot dos dados no seu volume de cluster. O Aurora retém dados de restauração incrementais durante todo o período de retenção de backup. Assim, você precisa criar um snapshot apenas para os dados que deseja reter além do período de retenção do backup. Crie um novo cluster de banco de dados a partir do snapshot.
Você pode recuperar seus dados criando um novo cluster de bancos de dados Aurora a partir dos dados de backup retidos pelo Aurora ou a partir de um snapshot de cluster de banco de dados que você salvou. É possível criar rapidamente uma nova cópia de um cluster de banco de dados a partir dos dados de backup a qualquer momento no período de retenção do backup. Devido à natureza contínua e incremental dos backups do Aurora durante o período de retenção do backup, você não precisa fazer snapshots frequentes de seus dados para melhorar os tempos de restauração.
Para obter mais informações, consulte [Como fazer o backup e a restauração de um cluster de banco de dados do Amazon Aurora](BackupRestoreAurora.md).
## Replicação
As réplicas do Aurora são endpoints independentes em um cluster de banco de dados Aurora, cuja melhor utilidade é escalar operações de leitura e aumentar a disponibilidade. Até 15 réplicas do Aurora podem ser distribuídas entre as zonas de disponibilidade abrangidas por um cluster de banco de dados em uma região da AWS. O volume do cluster de banco de dados é composto por várias cópias dos dados do cluster de banco de dados. Contudo, os dados no volume do cluster são representados como um volume lógico, único, para a instância do banco de dados primário e para réplicas do Aurora no cluster de banco de dados. Se a instância do banco de dados primário falhar, uma réplica do Aurora é promovida para ser a instância primária do banco de dados.
O Aurora também oferece suporte a opções de replicação específicas do Aurora MySQL e do Aurora PostgreSQL.
Para obter mais informações, consulte [Replicação com o Amazon Aurora](Aurora.Replication.md).
## Failover
O Aurora armazena cópias dos dados em um cluster de banco de dados em várias zonas de disponibilidade em uma única região da AWS. Esse armazenamento ocorre independentemente de as instâncias de banco de dados no cluster de banco de dados abrangerem várias zonas de disponibilidade. Quando você cria réplicas do Aurora nas zonas de disponibilidade, o Aurora as provisiona e as mantém automaticamente, de maneira síncrona. A instância do banco de dados primário é replicada de maneira síncrona em zonas de disponibilidade para réplicas do Aurora a fim de fornecer a redundância de dados, eliminar os congelamentos de E/S e minimizar os picos de latência durante backups do sistema. Executar um cluster de banco de dados com alta disponibilidade pode aumentar a disponibilidade durante a manutenção planejada do sistema e ajudar a proteger os bancos de dados contra falhas e interrupções da zona de disponibilidade.
Para mais informações, consulte [Alta disponibilidade do Amazon Aurora](Concepts.AuroraHighAvailability.md).
# Segurança da infraestrutura no Amazon Aurora
Como um serviço gerenciado, o Amazon Relational Database Service é protegido pela segurança de rede global da AWS. Para obter informações sobre serviços de segurança da AWS e como a AWS protege a infraestrutura, consulte [Segurança na Nuvem AWS](https://aws.amazon.com/security/). Para projetar seu ambiente da AWS usando as práticas recomendadas de segurança da infraestrutura, consulte [Proteção de Infraestrutura](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) em *Pilar de Segurança: AWS Estrutura bem arquitetada*.
Você usa chamadas de API publicadas da AWS para acessar o Amazon RDS por meio da rede. Os clientes devem oferecer compatibilidade com:
+ Transport Layer Security (TLS). Exigimos TLS 1.2 e recomendamos TLS 1.3.
+ Conjuntos de criptografia com perfect forward secrecy (PFS) como DHE (Ephemeral Diffie-Hellman) ou ECDHE (Ephemeral Elliptic Curve Diffie-Hellman). A maioria dos sistemas modernos, como Java 7 e versões posteriores, comporta esses modos.
Além disso, o Aurora oferece recursos para ajudar a oferecer suporte à segurança da infraestrutura.
## Grupos de segurança
Os grupos de segurança controlam o acesso que o tráfego tem dentro e fora de um cluster de banco de dados. Por padrão, o acesso à rede é desativado para um cluster de banco de dados. É possível especificar regras em um grupo de segurança que permitem o acesso de um intervalo de endereço IP, de uma porta ou de grupo de segurança. Depois que as regras de entrada são configuradas, as mesmas regras se aplicam a todos os clusters de banco de dados associados a esse grupo de segurança.
Para obter mais informações, consulte [Controlar acesso com grupos de segurança](Overview.RDSSecurityGroups.md).
## Public accessibility
Quando você inicia uma instância de banco de dados dentro de uma nuvem privada virtual (VPC) com base no serviço da Amazon VPC, pode ativar ou desativar a acessibilidade pública para essa instância de banco de dados. Para designar se a instância de banco de dados que você cria tem um nome DNS que é determinado como um endereço IP público, use o parâmetro *Public accessibility*. Usando esse parâmetro, você pode designar se há acesso público à instância do banco de dados. Você pode modificar uma instância de banco de dados para ativar ou desativar a acessibilidade pública modificando o parâmetro *Public accessibility (Acessibilidade pública)*.
Para obter mais informações, consulte [Ocultar um cluster de banco de dados em uma VPC da Internet](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.Hiding).
**nota**
Se sua instância de banco de dados estiver em uma VPC, mas não estiver acessível publicamente, também será possível usar uma conexão AWS Site-to-Site VPN ou uma conexão do Direct Connect para acessá-la de uma rede privada. Para obter mais informações, consulte [Privacidade do tráfego entre redes](inter-network-traffic-privacy.md).
# API do Amazon RDS e endpoints da VPC de interface (AWS PrivateLink)
É possível estabelecer uma conexão privada entre a VPC e os endpoints da API do Amazon RDS criando um *VPC endpoint de interface*. Os endpoints de interface são desenvolvidos pelo [AWS PrivateLink](https://aws.amazon.com/privatelink).
O AWS PrivateLink permite que você acesse as operações de API do Amazon RDS sem um gateway da Internet, um dispositivo NAT, uma conexão VPN ou uma conexão do Direct Connect. As instâncias de banco de dados na VPC não precisam de endereços IP públicos para se comunicarem com endpoints de API do Amazon RDS para executar, modificar ou encerrar instâncias e clusters de banco de dados. As instâncias de banco de dados também não precisam de endereços IP públicos para usar qualquer uma das operações de API do RDS disponíveis. O tráfego entre seu VPC e Amazon RDS não deixa a rede da Amazon.
Cada endpoint de interface é representado por uma ou mais interfaces de rede elástica nas sub-redes. Para obter mais informações sobre interfaces de rede elástica, consulte [Interfaces de rede elástica](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) no *Guia do usuário do Amazon EC2.*
Para obter mais informações sobre limites de VPC , consulte [VPC endpoints de interface (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html) no *Guia do usuário da Amazon VPC*. Para obter informações sobre as operações da API do RDS, consulte [Referência da API do Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/).
Você não precisa de um endpoint da VPC de interface para se conectar a um cluster de banco de dados. Para obter mais informações, consulte [Cenários para acessar um cluster de banco de dados em uma VPC](USER_VPC.Scenarios.md).
## Considerações sobre VPC endpoints
Antes de configurar um VPC endpoint de interface para endpoints da API do Amazon RDS, revise [Propriedades e limitações do endpoint de interface](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#vpce-interface-limitations) no *Guia do usuário da Amazon VPC*.
Todas as operações de API do RDS relevantes para o gerenciamento de recursos do Amazon Aurora estão disponíveis na VPC usando o AWS PrivateLink.
As políticas de endpoint da VPC têm suporte para endpoints da API do RDS. Por padrão, o acesso total às operações de API do RDS é permitido através do endpoint. Para obter mais informações, consulte [Controlar o acesso a serviços com VPC endpoints](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-access.html) no *Guia do usuário da Amazon VPC*.
## Disponibilidade
No momento, a API do Amazon RDS é compatível com os limites da VPC nas seguintes regiões da AWS:
+ Leste dos EUA (Ohio)
+ Leste dos EUA (Norte da Virgínia)
+ Oeste dos EUA (N. da Califórnia)
+ Oeste dos EUA (Oregon)
+ África (Cidade do Cabo)
+ Ásia-Pacífico (Hong Kong)
+ Asia Pacific (Mumbai)
+ Ásia-Pacífico (Nova Zelândia)
+ Ásia-Pacífico (Osaka)
+ Ásia-Pacífico (Seul)
+ Ásia-Pacífico (Singapura)
+ Ásia-Pacífico (Sydney)
+ Ásia-Pacífico (Taipei)
+ Ásia-Pacífico (Tailândia)
+ Ásia-Pacífico (Tóquio)
+ Canadá (Central)
+ Oeste do Canadá (Calgary)
+ China (Pequim)
+ China (Ningxia)
+ Europa (Frankfurt)
+ Europa (Zurique)
+ Europa (Irlanda)
+ Europa (Londres)
+ Europa (Paris)
+ Europa (Estocolmo)
+ Europa (Milão)
+ Israel (Tel Aviv)
+ México (Centro)
+ Middle East (Bahrain)
+ South America (São Paulo)
+ AWS GovCloud (Leste dos EUA)
+ AWS GovCloud (Oeste dos EUA)
## Criar um VPC endpoint de interface para a API Amazon RDS
Você pode criar um endpoint da VPC para o serviço de APIs do Amazon RDS usando o console da Amazon VPC ou a AWS Command Line Interface (AWS CLI). Para obter mais informações, consulte [Criar um endpoint de interface](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#create-interface-endpoint) no *Guia do usuário da Amazon VPC*.
Crie um VPC endpoint para a API Amazon RDS usando o nome de serviço `com.amazonaws.region.rds`.
Ao excluir regiões da AWS na China, se você habilitar o DNS privado para o endpoint, poderá fazer solicitações de API ao Amazon RDS com o endpoint da VPC usando seu nome DNS padrão para a região da AWS, por exemplo, `rds.us-east-1.amazonaws.com`. Para as regiões China (Pequim) e China (Ningxia) da AWS, é possível fazer solicitações de API com o endpoint da VPC usando `rds-api---cn-north-1.amazonaws.com.rproxy.goskope.com.cn` e `rds-api---cn-northwest-1.amazonaws.com.rproxy.goskope.com.cn`, respectivamente.
Para obter mais informações, consulte [Acessar um serviço por um endpoint de interface](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#access-service-though-endpoint) no *Guia do usuário da Amazon VPC*.
## Criar uma política de VPC endpoint para a API Amazon RDS
É possível anexar uma política de endpoint ao VPC endpoint que controla o acesso à API Amazon RDS Essa política especifica as seguintes informações:
+ A entidade principal que pode executar ações.
+ As ações que podem ser executadas.
+ Os recursos sobre os quais as ações podem ser realizadas.
Para obter mais informações, consulte [Controlar o acesso a serviços com VPC endpoints](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-access.html) no *Guia do usuário da Amazon VPC*.
**Exemplo: política de VPC endpoint para ações da API Amazon RDS**
Veja a seguir um exemplo de uma política de endpoint da API Amazon RDS. Quando anexada a um endpoint, essa política concede acesso às ações indicadas da API Amazon RDS para todos os principais em todos os recursos.
```
{
"Statement":[
{
"Principal":"*",
"Effect":"Allow",
"Action":[
"rds:CreateDBInstance",
"rds:ModifyDBInstance",
"rds:CreateDBSnapshot"
],
"Resource":"*"
}
]
}
```
**Exemplo: política de endpoint da VPC que nega todo o acesso de uma conta da AWS especificada**
A política de endpoint da VPC a seguir nega à conta da AWS `123456789012` todo o acesso aos recursos que usam o limite. A política permite todas as ações de outras contas.
```
{
"Statement": [
{
"Action": "*",
"Effect": "Allow",
"Resource": "*",
"Principal": "*"
},
{
"Action": "*",
"Effect": "Deny",
"Resource": "*",
"Principal": { "AWS": [ "123456789012" ] }
}
]
}
```
# Práticas recomendadas de segurança do Amazon Aurora
Use contas do AWS Identity and Access Management (IAM) para controlar o acesso a operações da API do Amazon RDS, especialmente operações que criam, modificam ou excluem recursos do Amazon Aurora. Esses recursos incluem clusters de banco de dados, grupos de segurança e grupos de parâmetros. Além disso, use o IAM para controlar ações que executam ações administrativas comuns, como fazer backup e restaurar clusters de banco de dados.
+ Crie um usuário individual para cada pessoa que gerencia recursos do Amazon Aurora, incluindo você. Não use as credenciais-raiz da AWS para gerenciar recursos do Amazon Aurora.
+ Conceda a cada usuário o conjunto mínimo de permissões necessárias para realizar suas funções.
+ Use grupos do IAM para gerenciar efetivamente permissões para vários usuários.
+ Mude suas credenciais do IAM regularmente.
+ Configure o AWS Secrets Manager para alternar automaticamente os segredos para o Amazon Aurora. Para ter mais informações, consulte [Alternar os segredos do AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html) no *Guia do usuário do AWS Secrets Manager*. Também é possível recuperar a credencial do AWS Secrets Manager forma programática. Para ter mais informações, consulte [Recuperar o valor do segredo](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_retrieve-secret.html) no *Guia do usuário do AWS Secrets Manager*.
Para ter mais informações sobre a segurança do Amazon Aurora, consulte [Segurança no Amazon Aurora](UsingWithRDS.md). Para ter mais informações sobre o IAM, consulte [AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/Welcome.html). Para obter informações sobre as práticas recomendadas do IAM, acesse [Melhores práticas do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/IAMBestPractices.html).
O AWS Security Hub CSPM utiliza controles de segurança para avaliar configurações de recursos e padrões de segurança que ajudam você a cumprir várias frameworks de conformidade. Para ter mais informações sobre como usar o Security Hub CSPM para avaliar os recursos do RDS, consulte [Controles do Amazon Relational Database Service](https://docs.aws.amazon.com/securityhub/latest/userguide/rds-controls.html) no Guia do usuário do AWS Security Hub.
É possível monitorar o uso do RDS em relação às práticas recomendadas de segurança com o Security Hub CSPM. Para ter mais informações, consulte [O que é o AWS Security Hub CSPM?](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html).
Use o Console de gerenciamento da AWS, a AWS CLI ou a API do RDS para alterar a senha do usuário mestre. Se você usar outra ferramenta, como um cliente SQL, para alterar a senha do usuário mestre, isso poderá resultar na revogação de privilégios ao usuário involuntariamente.
O Amazon GuardDuty é um serviço contínuo de monitoramento de segurança que analisa e processa uma série de fontes de dados, incluindo a atividade de login do Amazon RDS. Ele usa feeds de inteligência sobre ameaças e machine learning para identificar atividades inesperadas e possivelmente não autorizadas e mal-intencionadas no ambiente da AWS.
Quando a Proteção RDS do Amazon GuardDuty detecta uma ameaça em potencial ou uma tentativa de login anômala que indica uma ameaça ao banco de dados, o GuardDuty gera uma nova descoberta com detalhes sobre o banco de dados possivelmente comprometido. Para ter mais informações, consulte [Monitorar ameaças com o Amazon GuardDuty RDS Protection para Amazon Aurora](guard-duty-rds-protection.md) .
# Controlar acesso com grupos de segurança
Os grupos de segurança de VPC controlam o acesso que o tráfego tem dentro e fora de um cluster de banco de dados. Por padrão, o acesso à rede é desativado para um cluster de banco de dados. É possível especificar regras em um grupo de segurança que permitem o acesso de um intervalo de endereço IP, de uma porta ou de grupo de segurança. Depois que as regras de entrada são configuradas, as mesmas regras se aplicam a todos os clusters de banco de dados associados a esse grupo de segurança. Você pode especificar até 20 regras no grupo de segurança.
## Visão geral dos grupos de segurança de VPC
Cada regra de grupo de segurança de VPC possibilita que uma origem específica acesse um cluster de banco de dados em uma VPC que esteja associada a esse grupo de segurança de VPC. A origem pode ser uma gama de endereços (por exemplo, 203.0.113.0/24) ou outro grupo de segurança da VPC. Ao especificar um grupo de segurança de VPC como origem, você permite o tráfego recebido de todas as instâncias (geralmente servidores de aplicações) que usam o grupo de segurança de VPC de origem. Os grupos de segurança de VPC podem ter regras que controlam o tráfego de entrada e saída. No entanto, as regras de tráfego de saída normalmente não se aplicam a clusters de banco de dados. As regras de tráfego de saída se aplicarão apenas se o cluster de banco de dados atuar como um cliente. É necessário usar a [API do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Welcome.html) ou a opção **Security Group** (Grupo de segurança) no console da VPC para criar grupos de segurança de VPC.
Quando você cria regras para o grupo de segurança de VPC que permitem acessar os clusters na sua VPC, você deve especificar uma porta para cada intervalo de endereços ao qual a regra permite o acesso. Por exemplo, se quiser ativar o acesso via Secure Shell (SSH) para instâncias na VPC, crie uma regra que permitirá o acesso à porta TCP 22 para o intervalo de endereços especificado.
É possível configurar vários grupos de segurança de VPC que permitem o acesso a diferentes portas para diferentes instâncias na sua VPC. Por exemplo, você pode criar um grupo de segurança da VPC que permite acessar a porta TCP 80 para servidores web na VPC. Você pode criar outro grupo de segurança de VPC que permita acessar a porta TCP 3306 para instâncias de bancos de dados do Aurora MySQL na VPC.
**nota**
Em um cluster de bancos de dados Aurora, o grupo de segurança da VPC associado a esse cluster também é associado a todas as instâncias de banco de dados que ele contém. Se você alterar o grupo de segurança da VPC do cluster de banco de dados ou de uma instância de banco de dados, a alteração será aplicada automaticamente a todas as instâncias de banco de dados nesse cluster.
Para ter mais informações sobre grupos de segurança da VPC, consulte [Grupos de segurança](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) no *Guia do usuário da Amazon Virtual Private Cloud*.
**nota**
Se o cluster de banco de dados estiver em uma VPC, mas não acessível publicamente, também será possível usar um Site-to-Site VPN ou uma conexão do Direct Connect para acessá-la de uma rede privada. Para ter mais informações, consulte [Privacidade do tráfego entre redes](inter-network-traffic-privacy.md) .
## Cenário de grupos de segurança
Um uso comum de um cluster de banco de dados em uma VPC é compartilhar dados com um servidor de aplicações executado em uma instância do Amazon EC2 na mesma VPC, acessado por uma aplicação cliente fora da VPC. Para este cenário, use as páginas do RDS e da VPC no Console de gerenciamento da AWS ou nas operações de API do RDS e do EC2 para criar as instâncias e os grupos de segurança necessários:
1. Crie um grupo de segurança de VPC (por exemplo, `sg-0123ec2example`) e defina as regras de entrada que utilizam os endereços IP da aplicação cliente como a origem. Esse grupo de segurança permite que sua aplicação cliente se conecte a instâncias do EC2 em uma VPC que usa esse grupo de segurança.
1. Crie uma instância do EC2 para a aplicação e adicione a instância do EC2 ao grupo de segurança de VPC (`sg-0123ec2example`) que você criou na etapa anterior.
1. Crie um segundo grupo de segurança de VPC (por exemplo, `sg-6789rdsexample`) e crie uma nova regra especificando o grupo de segurança de VPC que você criou na etapa 1 (`sg-0123ec2example`) como origem.
1. Crie um cluster de banco de dados e adicione a o cluster de banco de dados ao grupo de segurança de VPC (`sg-6789rdsexample`) que você criou na etapa anterior. Quando você criar o cluster de banco de dados, use o mesmo número de porta especificado para a regra do grupo de segurança de VPC (`sg-6789rdsexample`) que você criou na etapa 3.
O diagrama a seguir mostra esse cenário.
![\[Cluster de banco de dados e instância do EC2 em uma VPC\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/con-VPC-sec-grp-aurora.png)
Para obter instruções detalhadas sobre como configurar uma VPC para esse cenário, consulte [Tutorial: Criar uma VPC para usar com um cluster de banco de dados (somente IPv4)](CHAP_Tutorials.WebServerDB.CreateVPC.md). Para ter mais informações sobre como usar uma VPC, consulte [Amazon VPC e Amazon Aurora](USER_VPC.md).
## Criar um grupo de segurança de VPC
Você pode criar um grupo de segurança de VPC para uma instância de banco de dados usando o console da VPC. Para obter informações sobre como criar um grupo de segurança, consulte [Fornecer acesso ao cluster de banco de dados na VPC criando um grupo de segurança](CHAP_SettingUp_Aurora.md#CHAP_SettingUp_Aurora.SecurityGroup) e [Grupos de segurança](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) no *Guia do usuário da Amazon Virtual Private Cloud*.
## Associação de um grupo de segurança a um cluster de banco de dados
Você pode associar um grupo de segurança a um cluster de banco de dados usando **Modify cluster** (Modificar cluster) no console do RDS, a API `ModifyDBCluster` do Amazon RDS ou o comando `modify-db-cluster` da AWS CLI.
O exemplo da CLI a seguir associa um grupo de VPC específico e remove grupos de segurança de banco de dados do cluster de banco de dados.
```
aws rds modify-db-cluster --db-cluster-identifier dbName --vpc-security-group-ids sg-ID
```
Para ter informações sobre como modificar um cluster de banco de dados, consulte [Modificar um cluster de bancos de dados Amazon Aurora](Aurora.Modifying.md).
# Privilégios da conta de usuário mestre
Ao criar um cluster de banco de dados, o usuário principal padrão usado obtém determinados privilégios para esse cluster de banco de dados. Não é possível alterar o nome de usuário principal depois que o cluster de banco de dados é criado.
**Importante**
É altamente recomendável não usar o usuário mestre diretamente nas aplicações. Em vez disso, siga as práticas recomendadas de usar um usuário do banco de dados criado com os privilégios mínimos obrigatórios para a aplicação.
**nota**
Se você excluir acidentalmente as permissões do usuário principal, poderá restaurá-las modificando o cluster de banco de dados e definindo uma nova senha de usuário principal. Para ter mais informações sobre como modificar um cluster de banco de dados, consulte [Modificar um cluster de bancos de dados Amazon Aurora](Aurora.Modifying.md).
A tabela a seguir mostra os privilégios e as funções de banco de dados que o usuário mestre obtém para cada um dos mecanismos do banco de dados.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.MasterAccounts.html)
# Usar funções vinculadas ao serviço do Amazon Aurora
O Amazon Aurora usa [funções vinculadas ao serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) do AWS Identity and Access Management (IAM). O perfil vinculado ao serviço é um tipo exclusivo de perfil do IAM vinculado diretamente ao Amazon Aurora. Os perfis vinculados a serviços são predefinidos pelo Amazon Aurora e incluem todas as permissões que o serviço requer para chamar outros serviços da AWS em seu nome.
Uma função vinculada ao serviço facilita o uso do Amazon Aurora porque você não precisa adicionar as permissões necessárias manualmente. O Amazon Aurora define as permissões das funções vinculadas ao serviço e, exceto se definido de outra forma, somente o Amazon Aurora pode assumir suas funções. As permissões definidas incluem a política de confiança e a política de permissões, e essa política não pode ser anexada a nenhuma outra entidade do IAM.
Você pode excluir as funções somente depois de primeiro excluir seus recursos relacionados. Isso protege seus recursos do Amazon Aurora, pois você não pode remover por engano as permissões para acessar os recursos.
Para ter informações sobre outros serviços compatíveis com perfis vinculados ao serviço, consulte [Serviços da AWS compatíveis com o IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) e procure serviços que tenham **Sim** na coluna **Perfis vinculados ao serviço**. Escolha um **Sim** com um link para visualizar a documentação da função vinculada a serviço desse serviço.
## Permissões de função vinculada ao serviço do Amazon Aurora
O Amazon Aurora utiliza a função vinculada a serviço chamada AWSServiceRoleForRDS para permitir que o Amazon RDS chame serviços da AWS em nome dos seus clusters de banco de dados.
A função vinculada ao serviço AWSServiceRoleForRDS confia nos seguintes serviços para assumir a função:
+ `rds.amazonaws.com`
Essa função vinculada a serviços tem uma política de permissões anexada a ela, chamada `AmazonRDSServiceRolePolicy`, que concede permissões para operar na conta.
Para ter mais informações sobre essa política, incluindo o documento de política JSON, consulte [AmazonRDSServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSServiceRolePolicy.html) no *Guia de referência de políticas gerenciadas pela AWS*.
**nota**
É necessário configurar permissões para que uma entidade do IAM (por exemplo, um usuário, grupo ou função) crie, edite ou exclua uma função vinculada ao serviço. Se encontrar a seguinte mensagem de erro:
**Impossível criar o recurso. Você se você tem permissão para criar o perfil vinculado ao serviço. Caso contrário, aguarde e tente novamente mais tarde.**
Certifique-se de que você tem as seguintes permissões ativadas:
```
{
"Action": "iam:CreateServiceLinkedRole",
"Effect": "Allow",
"Resource": "arn:aws:iam::*:role/aws-service-role/rds.amazonaws.com/AWSServiceRoleForRDS",
"Condition": {
"StringLike": {
"iam:AWSServiceName":"rds.amazonaws.com"
}
}
}
```
Para ter mais informações, consulte [Service-linked role permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) (Permissões de nível vinculado a serviços) no *Guia do usuário do IAM*.
### Criar uma função vinculada ao serviço para o Amazon Aurora
Você não precisa criar manualmente uma função vinculada a serviço. Ao criar um cluster de banco de dados, o Amazon Aurora cria o perfil vinculado ao serviço para você novamente.
**Importante**
Se você já usava o serviço Amazon Aurora antes de 1.º de dezembro de 2017, quando ele começou a comportar perfis vinculados ao serviço, o Amazon Aurora já criou o perfil AWSServiceRoleForRDS em sua conta. Para saber mais, consulte [Uma nova função apareceu na minha conta da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared).
Se você excluir essa função vinculada ao serviço e precisar criá-la novamente, poderá usar esse mesmo processo para recriar a função em sua conta. Ao criar um cluster de banco de dados, o Amazon Aurora cria o perfil vinculado ao serviço para você novamente.
### Editar uma função vinculada ao serviço para o Amazon Aurora
O Amazon Aurora não permite que você edite a função vinculada ao serviço AWSServiceRoleForRDS. Depois que criar uma função vinculada ao serviço, você não poderá alterar o nome da função, pois várias entidades podem fazer referência a ela. No entanto, será possível editar a descrição do perfil usando o IAM. Para ter mais informações, consulte [Editar uma função vinculada a serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) no *Guia do usuário do IAM*.
### Excluir uma função vinculada ao serviço para o Amazon Aurora
Se você não precisar mais usar um recurso ou serviço que requer uma função vinculada a serviço, é recomendável excluí-la. Dessa forma, você não tem uma entidade não utilizada que não seja monitorada ativamente ou mantida. Contudo, você deve excluir todos os seus clusters de banco de dados antes de poder excluir a função vinculada ao serviço.
#### Limpar uma função vinculada ao serviço
Antes de você poder usar o IAM para excluir uma função vinculada ao serviço, você deve primeiro confirmar que a função não tem sessões ativas e remover quaisquer recursos usados pela função.
**Para verificar se a função vinculada ao serviço tem uma sessão ativa no console do IAM**
1. Faça login no Console de gerenciamento da AWS e abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. No painel de navegação do console do IAM, escolha **Roles (Perfis)**. A seguir, escolha o nome (não a caixa de seleção) da função AWSServiceRoleForRDS.
1. Na página **Resumo** do perfil escolhido, selecione a guia **Último acesso**.
1. Na guia **Último acesso**, analise a atividade recente para o perfil vinculado ao serviço.
**nota**
Se não tiver certeza se o Amazon Aurora está usando a função AWSServiceRoleForRDS, você pode tentar excluir a função. Se o serviço estiver usando a função, a exclusão falhará e você poderá visualizar as regiões da AWS em que a função está sendo usada. Se a função está sendo usada, você deve aguardar a sessão final antes de excluir a função. Você não pode revogar a sessão para uma função vinculada a serviço.
Para remover a função AWSServiceRoleForRDS, primeiro é necessário excluir *todas* os clusters de banco de dados.
##### Exclusão de todos os clusters
Siga um destes procedimentos para excluir um cluster. Repita o procedimento para cada um dos clusters.
**Para excluir um cluster (console)**
1. Abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Na lista **Databases (Bancos de dados)**, escolha o cluster que você deseja excluir.
1. Em **Cluster Actions (Ações de cluster)**, escolha **Delete (Excluir)**.
1. Escolha **Delete (Excluir)**.
**Para excluir um cluster (CLI)**
Consulte `[delete-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-db-cluster.html)` no *AWS CLI Command Reference*.
**Para excluir um cluster (API)**
Consulte `[DeleteDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteDBCluster.html)` no *Amazon RDS API Reference*.
Também é possível usar o console do IAM, a CLI do IAM ou a API do IAM para excluir a função AWSServiceRoleForRDS vinculada a serviço. Para ter mais informações, consulte [Excluir uma função vinculada ao serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) no *Guia do usuário do IAM*.
## Permissões de perfis vinculados ao serviço para o Amazon RDS Beta
O Amazon Aurora usa o perfil vinculado ao serviço chamado `AWSServiceRoleForRDSBeta` para permitir que o Amazon Aurora chame serviços da AWS em nome dos recursos de banco de dados do RDS.
O perfil vinculado ao serviço AWSServiceRoleForRDSBeta confia nos seguintes serviços para assumir o perfil:
+ `rds.amazonaws.com`
Essa função vinculada a serviços tem uma política de permissões anexada a ela, chamada `AmazonRDSBetaServiceRolePolicy`, que concede permissões para operar na conta. Para obter mais informações, consulte [Política gerenciada da AWS: AmazonRDSBetaServiceRolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSBetaServiceRolePolicy).
**nota**
É necessário configurar permissões para que uma entidade do IAM (por exemplo, um usuário, grupo ou função) crie, edite ou exclua uma função vinculada ao serviço. Se encontrar a seguinte mensagem de erro:
**Impossível criar o recurso. Você se você tem permissão para criar o perfil vinculado ao serviço. Caso contrário, aguarde e tente novamente mais tarde.**
Certifique-se de que você tem as seguintes permissões ativadas:
```
{
"Action": "iam:CreateServiceLinkedRole",
"Effect": "Allow",
"Resource": "arn:aws:iam::*:role/aws-service-role/custom.rds.amazonaws.com/AmazonRDSBetaServiceRolePolicy",
"Condition": {
"StringLike": {
"iam:AWSServiceName":"custom.rds.amazonaws.com"
}
}
}
```
Para ter mais informações, consulte [Service-linked role permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) (Permissões de nível vinculado a serviços) no *Guia do usuário do IAM*.
## Perfil vinculado ao serviço da Pré-visualização do Amazon RDS
O Amazon Aurora usa o perfil vinculado ao serviço chamado `AWSServiceRoleForRDSPreview` para permitir que o Amazon Aurora chame serviços da AWS em nome dos recursos de banco de dados do RDS.
O perfil vinculado ao serviço AWSServiceRoleForRDSPreview confia nos seguintes serviços para assumir o perfil:
+ `rds.amazonaws.com`
Essa função vinculada a serviços tem uma política de permissões anexada a ela, chamada `AmazonRDSPreviewServiceRolePolicy`, que concede permissões para operar na conta. Para obter mais informações, consulte [Política gerenciada da AWS: AmazonRDSPreviewServiceRolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSPreviewServiceRolePolicy).
**nota**
É necessário configurar permissões para que uma entidade do IAM (por exemplo, um usuário, grupo ou função) crie, edite ou exclua uma função vinculada ao serviço. Se encontrar a seguinte mensagem de erro:
**Impossível criar o recurso. Você se você tem permissão para criar o perfil vinculado ao serviço. Caso contrário, aguarde e tente novamente mais tarde.**
Certifique-se de que você tem as seguintes permissões ativadas:
```
{
"Action": "iam:CreateServiceLinkedRole",
"Effect": "Allow",
"Resource": "arn:aws:iam::*:role/aws-service-role/custom.rds.amazonaws.com/AmazonRDSPreviewServiceRolePolicy",
"Condition": {
"StringLike": {
"iam:AWSServiceName":"custom.rds.amazonaws.com"
}
}
}
```
Para ter mais informações, consulte [Service-linked role permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) (Permissões de nível vinculado a serviços) no *Guia do usuário do IAM*.
# Amazon VPC e Amazon Aurora
A Amazon Virtual Private Cloud (Amazon VPC) possibilita a execução de recursos da AWS, como clusters de bancos de dados do Aurora, em uma nuvem privada virtual (VPC).
Ao usar uma VPC, você tem controle sobre o ambiente de rede virtual. É possível escolher seu próprio intervalo de endereços IP, criar sub-redes e configurar o roteamento e listas de controle de acesso. Não há custos adicionais para executar o cluster de banco de dados em uma VPC.
As contas têm uma VPC padrão. Todos os novos clusters de banco de dados são criados na VPC padrão, a menos que você especifique o contrário.
**Topics**
+ [Trabalhar com um cluster de banco de dados em uma VPC](USER_VPC.WorkingWithRDSInstanceinaVPC.md)
+ [Cenários para acessar um cluster de banco de dados em uma VPC](USER_VPC.Scenarios.md)
+ [Tutorial: Criar uma VPC para usar com um cluster de banco de dados (somente IPv4)](CHAP_Tutorials.WebServerDB.CreateVPC.md)
+ [Tutorial: Criar uma VPC para uso com um cluster de banco de dados (modo de pilha dupla)](CHAP_Tutorials.CreateVPCDualStack.md)
Veja a seguir uma discussão sobre a funcionalidade da VPC relevante para clusters de banco de dados do Amazon Aurora. Para obter mais informações sobre uma Amazon VPC, consulte o [Guia de conceitos básicos da Amazon VPC](https://docs.aws.amazon.com/AmazonVPC/latest/GettingStartedGuide/) e [Guia do usuário da Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/).
# Trabalhar com um cluster de banco de dados em uma VPC
Seu cluster deve estar em uma nuvem privada virtual (VPC). Uma VPC é uma rede virtual logicamente isolada de outras redes virtuais na Nuvem AWS. A Amazon VPC permite que você execute recursos da AWS, como um cluster de banco de dados do Amazon Aurora ou instância do Amazon EC2, em uma VPC. A VPC pode ser uma VPC padrão que vem com sua conta ou aquele que você criou. Todas as VPCs estão associadas à sua conta da AWS.
Sua VPC padrão possui três sub-redes que você pode usar para isolar recursos dentro da VPC. A VPC padrão também possui um gateway da Internet que pode ser usado para fornecer acesso a recursos na VPC de fora da VPC.
Para obter uma lista de cenários envolvendo clusters de banco de dados do Amazon Aurora em uma VPC , consulte [Cenários para acessar um cluster de banco de dados em uma VPC](USER_VPC.Scenarios.md).
**Topics**
+ [Trabalhar com um cluster de banco de dados em uma VPC](#Overview.RDSVPC.Create)
+ [Controle de criptografia da VPC](#USER_VPC.EncryptionControl)
+ [Trabalhar com grupos de sub-redes de banco de dados](#USER_VPC.Subnets)
+ [Sub-redes compartilhadas](#USER_VPC.Shared_subnets)
+ [Endereçamento IP do Amazon Aurora](#USER_VPC.IP_addressing)
+ [Ocultar um cluster de banco de dados em uma VPC da Internet](#USER_VPC.Hiding)
+ [Criar um cluster de banco de dados em uma VPC](#USER_VPC.InstanceInVPC)
Nos tutoriais a seguir, você pode aprender a criar uma VPC a ser usar para um cenário comum do Amazon Aurora:
+ [Tutorial: Criar uma VPC para usar com um cluster de banco de dados (somente IPv4)](CHAP_Tutorials.WebServerDB.CreateVPC.md)
+ [Tutorial: Criar uma VPC para uso com um cluster de banco de dados (modo de pilha dupla)](CHAP_Tutorials.CreateVPCDualStack.md)
## Trabalhar com um cluster de banco de dados em uma VPC
Veja a seguir algumas dicas sobre como trabalhar com um cluster de banco de dados em uma VPC:
+ A VPC deve ter pelo menos duas sub-redes. Essas sub-redes devem estar em duas zonas de disponibilidade diferentes na Região da AWS onde você deseja implantar o cluster de banco de dados. Uma *sub-rede* é um segmento do intervalo de endereços IP de uma VPC que você pode especificar e que permite agrupar clusters com base nas suas necessidades operacionais e de segurança.
+ Se quiser que seu cluster de banco de dados na VPC seja publicamente acessível, você deverá habilitar os atributos *DNS hostnames* (Nomes de host de DNS) e *DNS resolution* (Resolução de DNS).
+ Sua VPC deve ter um grupo de sub-redes de banco de dados que você criou. Crie um grupo de sub-redes de banco de dados especificando as sub-redes criadas. O Amazon Aurora escolhe uma sub-rede e um endereço IP dentro dessa sub-rede para associar à instância de banco de dados primária no cluster de banco de dados. A instância de banco de dados primária usa a zona de disponibilidade que contém a sub-rede.
+ Sua VPC deve ter um grupo de segurança de VPC que permita o acesso ao cluster de banco de dados.
Para ter mais informações, consulte [Cenários para acessar um cluster de banco de dados em uma VPC](USER_VPC.Scenarios.md).
+ Os blocos CIDR em cada uma das suas sub-redes devem ser suficientemente grandes para acomodar endereços IP sobressalentes para o Amazon Aurora usar durante atividades de manutenção, incluindo failover e escalabilidade de computação. Por exemplo, um intervalo como 10.0.0.0/24 e 10.0.1.0/24 normalmente é grande o suficiente.
+ Uma VPC pode ter um atributo *instance tenancy* (locação de instâncias) com o valor *default* (padrão) ou *dedicated* (dedicado). Todas as VPC padrão têm o atributo de locação de instâncias definido como padrão, e uma VPC padrão pode oferecer suporte a qualquer classe de instância de banco de dados.
Se você optar por ter seu cluster de banco de dados em uma VPC dedicada em que o atributo de locação de instâncias esteja definido como dedicado, a classe de seu cluster de banco de dados deverá ser um dos tipos aprovados de instância dedicada do Amazon EC2. Por exemplo, a instância dedicada r5.large do EC2 corresponde à classe de instância de banco de dados db.r5.large. Para obter informações sobre a locação de instâncias em uma VPC, consulte [Instâncias dedicadas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/dedicated-instance.html) no *Guia do usuário do Amazon Elastic Compute Cloud*.
Consulte mais informações sobre os tipos de instância que podem estar em uma instância dedicada em [Instâncias dedicadas do Amazon EC2](https://aws.amazon.com/ec2/purchasing-options/dedicated-instances/), na página de preços do Amazon EC2.
**nota**
Quando você define o atributo de locação de instâncias como dedicado para um cluster de banco de dados, ele não garante que esse cluster terá execução em um host dedicado.
## Controle de criptografia da VPC
Os controles de criptografia da VPC permitem que você aplique a criptografia em trânsito para todo o tráfego de rede em suas VPCs. Use o controle de criptografia para atender aos requisitos de conformidade regulatória, garantindo que somente hardware baseado em Nitro habilitado para criptografia possa ser provisionado em VPCs designadas. O controle de criptografia também detecta problemas de compatibilidade no momento da solicitação da API, e não durante o provisionamento. Suas workloads existentes continuam funcionando e somente novas solicitações incompatíveis são bloqueadas.
Defina seus controles de criptografia de VPC definindo o modo de controle de VPC como:
+ *desabilitado* (padrão)
+ *monitorar o*
+ *imposta*
Para conferir o modo de controle atual da sua VPC, use o comando Console de gerenciamento da AWS da CLI ou da API [DescribeVpcs](https://docs.aws.amazon.com//AWSEC2/latest/APIReference/API_DescribeVpcs.html).
Se sua VPC impõe criptografia, você só pode provisionar clusters de banco de dados com base em Nitro que aceitem criptografia em trânsito nessa VPC. Para obter mais informações, consulte, [Tipos de classe de instância de banco de dados](Concepts.DBInstanceClass.Types.md). Para acessar informações sobre instâncias Nitro, consulte [Instâncias baseadas no AWS Sistema Nitro](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-nitro-instances.html) no *Guia do usuário do Amazon EC2*.
**nota**
Se você tentar provisionar clusters de banco de dados incompatíveis em uma VPC com criptografia imposta, o Aurora exibirá uma exceção `VpcEncryptionControlViolationException`.
Para Aurora Serverless para MySQL e PostreSQL, o controle de criptografia requer a versão da plataforma 3 ou posterior.
## Trabalhar com grupos de sub-redes de banco de dados
*Sub-redes* são segmentos do intervalo de endereços IP de uma VPC que você designa para agrupar seus recursos com base em necessidades operacionais e de segurança. Um *grupo de sub-redes de banco de dados* é uma coleção de sub-redes (geralmente privadas) que você cria em uma VPC e designa para seus clusters de banco de dados. Ao usar um grupo de sub-redes de banco de dados, você pode especificar uma VPC específica ao criar clusters de banco de dados usando a AWS CLI ou a API. Se você usar o console, poderá escolher somente a VPC e os grupos de sub-redes que deseja usar.
Cada grupo de sub-redes de banco de dados deve ter sub-redes em pelo menos duas zonas de disponibilidade em determinada Região da AWS. Ao criar um cluster de banco de dados em uma VPC, escolha um grupo de sub-redes de banco de dados. Do grupo de sub-rede de banco de dados, o Amazon Aurora escolhe uma sub-rede e um endereço IP dentro dessa sub-rede para associar à instância de banco de dados primáriaà instância de banco de dados no cluster de banco de dados. O banco de dados usa a zona de disponibilidade que contém a sub-rede. O Aurora sempre atribui um endereço IP de uma sub-rede que tem espaço de endereço IP livre.
As sub-redes em um grupo de sub-redes de banco de dados são públicas ou privadas. As sub-redes são públicas ou privadas, dependendo da configuração definida para as listas de controle de acesso à rede (ACLs de rede) e tabelas de roteamento. Para que um cluster de banco de dados seja acessível ao público, todas as sub-redes em seu grupo de sub-redes de banco de dados devem ser públicas. Se uma sub-rede associada a um cluster de banco de dados acessível ao público mudar de pública para privada, ela poderá afetar a disponibilidade do cluster de banco de dados.
Para criar um grupo de sub-redes de banco de dados que seja compatível com o modo de pilha dupla, verifique se cada sub-rede adicionada ao grupo de sub-redes de banco de dados tem um bloco CIDR do Internet Protocol versão 6 (IPv6) associado a ele. Para ter mais informações, consulte [Endereçamento IP do Amazon Aurora](#USER_VPC.IP_addressing) e [Migrar para IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) no *Guia do usuário da Amazon VPC.*
Quando o Amazon Aurora cria um cluster de banco de dados em uma VPC, ele atribui uma interface de rede ao seu cluster de banco de dados usando um endereço IP do seu grupo de sub-redes de banco de dados. No entanto, é altamente recomendável que você use o Sistema de Nomes de Domínio (DNS) para se conectar ao seu cluster de banco de dados. Recomendamos isso porque o endereço IP subjacente muda durante o failover.
**nota**
Para cada cluster de banco de dados executado em uma VPC, é necessário reservar pelo menos um endereço em cada sub-rede no grupo de sub-redes de banco de dados para uso pelo Amazon Aurora para ações de recuperação.
## Sub-redes compartilhadas
Você pode criar um cluster de banco de dados em uma VPC compartilhada.
Algumas considerações que você deve ter em mente ao usar VPCs compartilhadas:
+ Você pode mover um cluster de banco de dados de uma sub-rede de VPC compartilhada para uma sub-rede de VPC não compartilhada e vice-versa.
+ Os participantes de uma VPC compartilhada devem criar um grupo de segurança na VPC para permitir que criem um cluster de banco de dados.
+ Proprietários e participantes de uma VPC compartilhada podem acessar o banco de dados usando consultas SQL. No entanto, somente o criador de um recurso pode fazer chamadas de API no recurso.
## Endereçamento IP do Amazon Aurora
Os endereços IP habilitam recursos na sua VPC para se comunicar com outros e com recursos na Internet. O Amazon Aurora comporta protocolos de endereçamento IPv4 e IPv6. Por padrão, o Amazon Aurora e a Amazon VPC usam o protocolo de endereçamento IPv4. Você não pode desativar esse comportamento. Ao criar uma VPC, especifique um bloco CIDR IPv4 (um intervalo de endereços IPv4 privados). Você também pode atribuir um bloco CIDR IPv6 à VPC e às sub-redes, bem como endereços IPv6 desse bloco a clusters de banco de dados em sua sub-rede.
A compatibilidade com o protocolo IPv6 expande o número de endereços IP compatíveis. Ao usar o protocolo IPv6, você tem a garantia de que terá endereços disponíveis suficientes para o crescimento futuro da Internet. Os recursos do RDS novos e existentes podem usar endereços IPv4 e IPv6 na VPC. Configurar, proteger e converter o tráfego de rede entre os dois protocolos usados em diferentes partes de uma aplicação pode causar sobrecarga operacional. Você pode padronizar o protocolo IPv6 para recursos do Amazon RDS a fim de simplificar sua configuração de rede.
**Topics**
+ [Endereços IPv4](#USER_VPC.IP_addressing.IPv4)
+ [Endereços IPv6](#USER_VPC.IP_addressing.IPv6)
+ [Modo de pilha dupla](#USER_VPC.IP_addressing.dual-stack-mode)
### Endereços IPv4
Quando você cria uma VPC, é necessário especificar um intervalo de endereços IPv4 para a VPC em forma de um bloco CIDR, como `10.0.0.0/16`. m *grupo de sub-redes de banco de dados* define o intervalo de endereços IP nesse bloco CIDR que um cluster de banco de dados pode usar. Esses endereços IP podem ser públicos ou privados.
Um endereço IPv4 privado é um endereço IP que não é acessível pela Internet. Você pode usar endereços IPv4 privados para comunicação entre o cluster de banco de dados e outros recursos, como instâncias do Amazon EC2, na mesma VPC. Cada cluster de banco de dados tem um endereço IP privado para comunicação na VPC.
Um endereço IP público é um endereço IPv4 acessível pela Internet. Você pode usar endereços públicos para comunicação entre o cluster de banco de dados e os recursos na Internet, como um cliente SQL. Você controla se o cluster de banco de dados recebe um endereço IP público.
O Amazon RDS usa endereços IPv4 elásticos públicos do grupo de endereços IPv4 públicos do EC2 para instâncias de banco de dados acessíveis ao público. Esses endereços IP são visíveis em sua conta da AWS ao usar a `describe-addresses` CLI e a API ou ao visualizar a seção IPs elásticos (EIPs) no Console de gerenciamento da AWS. Cada endereço IP gerenciado pelo RDS é marcado com um atributo `service_managed` definido como `"rds"`.
Embora esses IPs estejam visíveis em sua conta, eles continuam sendo totalmente gerenciados pelo Amazon RDS e não podem ser modificados ou liberados. O Amazon RDS libera IPs de volta ao grupo de endereços IPv4 públicos quando eles não estão mais em uso.
O CloudTrail registra em log chamadas de API relacionadas a EIPs do RDS, como `AllocateAddress`. Essas chamadas de API são invocadas pela entidade principal de serviço `rds.amazonaws.com`.
**nota**
Os IPs alocados pelo Amazon RDS não são contabilizados nos limites de EIPs da sua conta.
Para ver um tutorial que mostra como criar uma VPC somente com endereços IPv4 privados que você pode usar para um cenário comum do Amazon Aurora, consulte [Tutorial: Criar uma VPC para usar com um cluster de banco de dados (somente IPv4)](CHAP_Tutorials.WebServerDB.CreateVPC.md).
### Endereços IPv6
Como opção, você pode associar um bloco CIDR IPv6 a sua VPC e sub-redes e atribuir endereços IPv6 desse bloco a recursos em sua VPC. Todo endereço IPv6 é globalmente exclusivo.
O bloco CIDR IPv6 da VPC é automaticamente atribuído do grupo de endereços IPv6 da Amazon. Você não pode escolher o intervalo.
Ao se conectar a um endereço IPv6, verifique se as seguintes condições são atendidas:
+ O cliente está configurado para que o tráfego do cliente para o banco de dados via IPv6 seja permitido.
+ Os grupos de segurança do RDS usados pela instância de banco de dados estão configurados corretamente para que o tráfego do cliente para o banco de dados via IPv6 seja permitido.
+ A pilha do sistema operacional do cliente permite tráfego no endereço IPv6, e os drivers e bibliotecas do sistema operacional estão configurados para escolher o endpoint de instância de banco de dados padrão correto (IPv4 ou IPv6).
Para ter mais informações sobre IPv6, consulte [Endereçamento IP](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html) no *Guia do usuário da Amazon VPC*.
### Modo de pilha dupla
Um cluster de banco de dados é executado no modo de pilha dupla quando consegue se comunicar pelos protocolos de endereçamento IPv4 e IPv6. Os recursos podem então se comunicar com o cluster de banco de dados usando IPv4, IPv6 ou ambos os protocolos. As instâncias de banco de dados privadas do modo de pilha dupla têm endpoints IPv6 aos quais o RDS concede somente acesso à VPC, garantindo que seus endpoints IPv6 permaneçam privados. As instâncias de banco de dados no modo de pilha dupla pública oferecem endpoints IPv4 e IPv6 endpoints que podem ser acessados pela internet.
**Topics**
+ [Modo de pilha dupla e grupos de sub-redes de banco de dados](#USER_VPC.IP_addressing.dual-stack-db-subnet-groups)
+ [Trabalhar com instâncias de banco de dados de modo de pilha de dupla](#USER_VPC.IP_addressing.dual-stack-working-with)
+ [Modificar clusters de banco de dados somente IPv4 para usar o modo de pilha dupla](#USER_VPC.IP_addressing.dual-stack-modifying-ipv4)
+ [Disponibilidade de clusters de banco de dados de rede de pilha dupla](#USER_VPC.IP_addressing.dual-stack-availability)
+ [Limitações para clusters de banco de dados de rede de pilha dupla](#USER_VPC.IP_addressing.dual-stack-limitations)
Para ver um tutorial que mostra como criar uma VPC com endereços IPv4 e IPv6 que você pode usar para um cenário comum do Amazon Aurora, consulte [Tutorial: Criar uma VPC para uso com um cluster de banco de dados (modo de pilha dupla)](CHAP_Tutorials.CreateVPCDualStack.md).
#### Modo de pilha dupla e grupos de sub-redes de banco de dados
Para usar o modo de pilha dupla, verifique se cada sub-rede no grupo de sub-redes de banco de dados que você associa ao cluster de banco de dados tem um bloco CIDR IPv6 associado a ela. Você pode criar um grupo de sub-redes de banco de dados ou modificar um existente para atender a esse requisito. Depois que um cluster de banco de dados entra no modo de pilha dupla, os clientes podem se conectar normalmente. Os firewalls de segurança do cliente e os grupos de segurança de instâncias de banco de dados do RDS devem ser configurados com precisão para permitir tráfego por IPv6. Para se conectar, os clientes usam o endpoint da instância primária do cluster de banco de dados. As aplicações cliente podem especificar qual protocolo é o preferencial ao se conectar a um banco de dados. No modo de pilha dupla, o cluster de banco de dados detecta o protocolo de rede de preferência do cliente, IPv4 ou IPv6, e o usa para a conexão.
Se um grupo de sub-redes de banco de dados deixar de ser compatível com o modo de pilha dupla devido à exclusão de sub-rede ou desassociação do CIDR, existe o risco de um estado de rede incompatível para instâncias de banco de dados associadas ao grupo de sub-redes de banco de dados. Além disso, não é possível usar o grupo de sub-redes de banco de dados ao criar um novo cluster de banco de dados do modo de pilha dupla.
Para determinar se um grupo de sub-redes de banco de dados é compatível com o modo de pilha dupla usando o Console de gerenciamento da AWS, visualize o **Network type** (Tipo de rede) na página de detalhes do grupo de sub-redes de banco de dados. Para determinar se um grupo de sub-redes de banco de dados comporta o modo de pilha dupla usando a AWS CLI, execute o comando [describe-db-subnet-groups](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-subnet-groups.html) e visualize `SupportedNetworkTypes` na saída.
As réplicas de leitura são tratadas como instâncias de banco de dados independentes e podem ter um tipo de rede diferente da instância de banco de dados primária. Se você alterar o tipo de rede da instância de banco de dados primária de uma réplica de leitura, esta não será afetada. Você pode restaurar uma instância de banco de dados para qualquer tipo de rede compatível.
#### Trabalhar com instâncias de banco de dados de modo de pilha de dupla
Ao criar ou modificar um cluster de banco de dados, você pode especificar o modo de pilha dupla para permitir que os recursos se comuniquem com o cluster de banco de dados por IPv4, IPv6 ou ambos.
Ao usar o Console de gerenciamento da AWS para criar ou modificar uma instância de banco de dados, você pode especificar o modo de pilha dupla na seção **Network type** (Tipo de rede). A imagem a seguir mostra a seção **Network type** (Tipo de rede) no console.
![\[Seção Tipo de rede no console com o Modo de pilha dupla selecionado.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/dual-stack-mode.png)
Ao usar a AWS CLI para criar ou modificar um cluster de banco de dados, defina a opção `--network-type` como `DUAL` para usar o modo de pilha dupla. Ao usar a API do RDS para criar ou modificar um cluster de banco de dados, defina o parâmetro `NetworkType` como `DUAL` para usar o modo de pilha dupla. Quando você estiver modificando o tipo de rede de uma instância de banco de dados, é possível que ocorra tempo de inatividade. Se o modo de pilha dupla não for compatível com a versão do mecanismo de banco de dados especificado nem com o grupo de sub-redes de banco de dados, o erro `NetworkTypeNotSupported` será retornado.
Para ter mais informações sobre como criar um cluster de banco de dados, consulte [Criar um cluster de bancos de dados do Amazon Aurora](Aurora.CreateInstance.md). Para ter mais informações sobre como modificar um cluster de banco de dados, consulte [Modificar um cluster de bancos de dados Amazon Aurora](Aurora.Modifying.md).
Para determinar se um cluster de banco de dados está no modo de pilha dupla usando o console, visualize o **Network type** (Tipo de rede) na guia **Connectivity & security** (Conectividade e segurança) para o cluster de banco de dados.
#### Modificar clusters de banco de dados somente IPv4 para usar o modo de pilha dupla
Você pode modificar clusters de banco de dados somente IPv4 para usar o modo de pilha dupla. Para isso, altere o tipo de rede do cluster de banco de dados. A modificação pode ocasionar tempo de inatividade.
É recomendável que você altere o tipo de rede dos clusters do Amazon Aurora durante uma janela de manutenção. No momento, não é possível definir o tipo de rede de novas instâncias para o modo de pilha dupla. É possível definir o tipo de rede manualmente usando o comando `modify-db-cluster`.
Antes de modificar um cluster de banco de dados para usar o modo de pilha dupla, verifique se seu grupo de sub-redes de banco de dados é compatível com o modo de pilha dupla. Se o grupo de sub-redes de banco de dados associado ao cluster de banco de dados não for compatível com o modo de pilha dupla, ao modificar o cluster de banco de dados especifique um grupo de sub-redes de banco de dados diferente que seja compatível. Modificar o grupo de sub-redes de banco de dados de um cluster de banco de dados pode ocasionar tempo de inatividade.
Se você modificar o grupo de sub-redes de banco de dados de um cluster de banco de dados antes de alterar o cluster de banco de dados para usar o modo de pilha dupla, verifique se o grupo de sub-redes de banco de dados é válido para o cluster de banco de dados antes e depois da alteração.
Recomendamos que você execute a API [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) apenas com o parâmetro `--network-type` com valor `DUAL` para alterar a rede de um cluster do Amazon Aurora para o modo de pilha dupla. Adicionar outros parâmetros com o parâmetro `--network-type` na mesma chamada de API pode ocasionar tempo de inatividade.
Se você não conseguir se conectar ao cluster de banco de dados após a alteração, verifique se os firewalls de segurança do cliente e do banco de dados e as tabelas de rotas estão configurados com precisão para permitir tráfego para o banco de dados na rede selecionada (IPv4 ou IPv6). Você também pode precisar modificar parâmetros, bibliotecas ou drivers do sistema operacional para se conectar por meio de um endereço IPv6.
**Como modificar clusters de banco de dados somente IPv4 para usar o modo de pilha dupla**
1. Modifique um grupo de sub-redes de banco de dados para ser compatível com o modo de pilha dupla ou crie um grupo de sub-redes de banco de dados que seja compatível com esse modo:
1. Associe um bloco CIDR IPv6 à VPC.
Para obter instruções, consulte [Adicionar um bloco CIDR IPv6 a sua VPC](https://docs.aws.amazon.com/vpc/latest/userguide/modify-vpcs.html#vpc-associate-ipv6-cidr) no *Manual do usuário do Amazon VPC*.
1. Anexe o bloco CIDR IPv6 a todas as sub-redes do grupo de sub-redes do banco de dados.
Para obter instruções, consulte [Adicionar um bloco CIDR IPv6 a sua sub-rede](https://docs.aws.amazon.com/vpc/latest/userguide/modify-subnets.html#subnet-associate-ipv6-cidr) no *Manual do usuário do Amazon VPC*.
1. Verifique se o grupo de sub-redes de banco de dados é compatível com o modo de pilha dupla.
Se você estiver usando o Console de gerenciamento da AWS, selecione o grupo de sub-redes de banco de dados e verifique se o valor **Supported network types** (Tipos de rede compatíveis) é **Dual, IPv4** (Duplo, IPv4).
Se estiver usando a AWS CLI, execute o comando [describe-db-subnet-groups](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-subnet-groups.html) e verifique se o valor `SupportedNetworkType` para a instância de banco de dados é `Dual, IPv4`.
1. Modifique o grupo de segurança associado ao cluster de banco de dados para permitir conexões IPv6 com o banco de dados ou crie um grupo de segurança que permita conexões IPv6.
Para obter instruções, consulte [Regras do grupo de segurança](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html) no *Guia do usuário da Amazon VPC*.
1. Modifique o cluster de banco de dados para oferecer suporte ao modo de pilha dupla. Para fazer isso, defina a opção **Network type** (Tipo de rede) como **Dual-stack mode** (Modo de pilha dupla).
Se você estiver usando o console, verifique se as seguintes configurações estão corretas:
+ **Network type** (Tipo de rede): **Dual-stack mode** (Modo de pilha dupla).
![\[Seção Tipo de rede no console com o Modo de pilha dupla selecionado.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/dual-stack-mode.png)
+ **DB subnet group** (Grupo de sub-redes do banco de dados): o grupo de sub-redes de banco de dados que você configurou em uma etapa anterior
+ **Security group** (Grupo de segurança): o grupo de segurança que você configurou em uma etapa anterior.
Se você estiver usando a AWS CLI, verifique se as seguintes configurações estão corretas:
+ `--network-type` – `dual`
+ `--db-subnet-group-name`: o grupo de sub-redes de banco de dados que você configurou em uma etapa anterior
+ `--vpc-security-group-ids`: o grupo de segurança da VPC que você configurou em uma etapa anterior.
Por exemplo:
```
aws rds modify-db-cluster --db-cluster-identifier my-cluster --network-type "DUAL"
```
1. Verifique se o cluster de banco de dados é compatível com o modo de pilha dupla.
Se estiver usando o console, selecione a guia **Configuration** (Configuração) para o cluster de banco de dados. Nessa guia, verifique se o valor de **Network type** (Tipo de rede) é **Dual-stack mode** (Modo de pilha dupla).
Se estiver usando a AWS CLI, execute o comando [describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html) e verifique se o valor `NetworkType` para o cluster de banco de dados é `dual`.
Execute o comando `dig` no endpoint da instância de banco de dados gravadora para identificar o endereço IPv6 associado a ele.
```
dig db-instance-endpoint AAAA
```
Use o endpoint da instância de banco de dados de gravador, não o endereço IPv6, para se conectar ao cluster de banco de dados.
#### Disponibilidade de clusters de banco de dados de rede de pilha dupla
Os clusters de banco de dados de rede de pilha dupla estão disponíveis em todas as Regiões da AWS, exceto nas seguintes:
+ Ásia-Pacífico (Hyderabad)
+ Ásia-Pacífico (Malásia)
+ Ásia-Pacífico (Melbourne)
+ Ásia-Pacífico (Tailândia)
+ Oeste do Canadá (Calgary)
+ Europa (Espanha)
+ Europa (Zurique)
+ Israel (Tel Aviv)
+ México (Centro)
+ Oriente Médio (Emirados Árabes Unidos)
As seguintes versões do mecanismo de banco de dados são compatíveis com clusters de banco de dados de rede de pilha dupla:
+ Versões do Aurora MySQL:
+ Versão 3.02 e versões 3 posteriores
+ Versão 2.09.1 e versões 2 posteriores
Para ter mais informações sobre as versões do Aurora MySQL, consulte as [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/Welcome.html](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/Welcome.html) (Notas de lançamento do Aurora MySQL).
+ Versões do Aurora PostgreSQL:
+ 15.2 e todas as versões posteriores
+ Versão 14.3 e versões 14 posteriores
+ Versão 13.7 e versões 13 posteriores
Para ter mais informações sobre as versões do Aurora PostgreSQL, consulte as [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/Welcome.html](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/Welcome.html) (Notas de lançamento do Aurora PostgreSQL).
#### Limitações para clusters de banco de dados de rede de pilha dupla
As seguintes limitações se aplicam aos clusters de banco de dados de rede de pilha dupla:
+ Clusters de banco de dados não podem usar o protocolo IPv6 exclusivamente. É possível usar IPv4 exclusivamente ou o protocolo IPv4 e IPv6 (modo de pilha dupla).
+ O Amazon RDS não é compatível com sub-redes IPv6 nativas.
+ Você não pode usar o RDS Proxy com clusters de banco de dados do modo de pilha dupla.
## Ocultar um cluster de banco de dados em uma VPC da Internet
Um cenário comum do Amazon Aurora é ter uma VPC na qual exista uma instância do Amazon EC2 com uma aplicação web voltada para o público e um cluster de banco de dados com um banco de dados não acessível ao público. Por exemplo, você pode criar uma VPC que tenha uma sub-rede pública e uma sub-rede privada. As instâncias do EC2 que funcionam como servidores Web podem ser implantadas na sub-rede pública. os clusters de banco de dados são implantados na sub-rede privada. Nessa implantação, apenas os servidores Web têm acesso aos clusters de banco de dados. Para obter uma ilustração desse cenário, consulte [Um cluster de banco de dados em uma VPC acessada por uma instância do Amazon EC2 na mesma VPC.](USER_VPC.Scenarios.md#USER_VPC.Scenario1).
Quando você inicia um cluster de banco de dados dentro de uma VPC, o cluster de banco de dados tem um endereço IP privado para tráfego dentro da VPC. Esse endereço IP privado não é acessível ao público geral. Você pode usar a opção **Public access** (Acesso público) para designar se o cluster de banco de dados também deve ter um endereço IP público além do endereço IP privado. Se o cluster de banco de dados for acessível ao público, seu endpoint DNS resolverá para o endereço IP privado de dentro da VPC. Ele é resolvido para o endereço IP público de fora da VPC. O acesso ao cluster de banco de dados é controlado em última análise pelo grupo de segurança usado. Esse acesso público não será permitido se o grupo de segurança atribuído ao cluster de banco de dados não incluir regras de entrada que permitam isso. Além disso, para que um cluster de banco de dados seja acessível publicamente, as sub-redes no grupo de sub-redes de banco de dados devem ter um gateway da Internet. Para ter mais informações, consulte [Não é possível conectar-se à instância de banco de dados do Amazon RDS](CHAP_Troubleshooting.md#CHAP_Troubleshooting.Connecting).
Você pode modificar um cluster de banco de dados para ativar ou desativar a acessibilidade ao público geral modificando a opção **Public access** (Acesso público). A ilustração a seguir mostra a opção **Public access (Acesso público)** na seção **Additional connectivity configuration (Configuração de conectividade adicional)**. Para definir a opção, abra a seção **Additional connectivity configuration (Configuração de conectividade adicional)** na seção **Connectivity (Conectividade)**.
![\[Defina a opção Acesso público do banco de dados na seção Configuração de conectividade adicional como Não.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/VPC-example4.png)
Para obter informações sobre como modificar uma instância de banco de dados para definir a opção de **Public access (Acesso público)**, consulte [Modificar uma instância de banco de dados em um cluster de banco de dados](Aurora.Modifying.md#Aurora.Modifying.Instance).
## Criar um cluster de banco de dados em uma VPC
Os procedimentos a seguir ajudam você a criar um cluster de banco de dados em uma VPC. Para usar a VPC padrão, você pode começar na etapa 2 e usar a VPC e o grupo de sub-redes de banco de dados que já foram criados para você. Se quiser criar uma VPC adicional, você poderá criar uma nova VPC.
**nota**
Se você deseja que seu cluster de banco de dados na VPC seja acessível ao público geral, atualize as informações de DNS da VPC, habilitando os atributos *DNS hostnames* (Nomes de host de DNS) e *DNS resolution* (Resolução de DNS). Para obter informações sobre como atualizar as informações de DNS para uma instância de VPC, consulte [Atualização do suporte a DNS para sua VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html).
Siga estas etapas para criar uma instância de banco de dados em uma VPC:
+ [Etapa 1: Criar uma VPC](#USER_VPC.CreatingVPC)
+ [Etapa 2: Criar um grupo de sub-redes de banco de dados](#USER_VPC.CreateDBSubnetGroup)
+ [Etapa 3: Criar um grupo de segurança da VPC](#USER_VPC.CreateVPCSecurityGroup)
+ [Etapa 4: Criar uma instância de banco de dados na VPC](#USER_VPC.CreateDBInstanceInVPC)
### Etapa 1: Criar uma VPC
Crie uma VPC com duas sub-redes em pelo menos duas zonas de disponibilidade. Você usará essas sub-redes ao criar um grupo de sub-redes de banco de dados. Se você tiver uma VPC padrão, uma sub-rede será criada automaticamente para você em cada zona de disponibilidade na Região da AWS.
Para ter mais informações, consulte [Criar uma VPC com sub-redes públicas e privadas](CHAP_Tutorials.WebServerDB.CreateVPC.md#CHAP_Tutorials.WebServerDB.CreateVPC.VPCAndSubnets) ou [Criar uma VPC](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#Create-VPC) no *Guia do usuário da Amazon VPC*.
### Etapa 2: Criar um grupo de sub-redes de banco de dados
Um grupo de sub-redes de banco de dados é uma coleção de sub-redes (geralmente privadas) que você cria para uma VPC e designa aos seus clusters de banco de dados. Um grupo de sub-redes de banco de dados permite que você especifique uma VPC particular ao criar clusters de banco de dados usando a AWS CLI ou a API do RDS. Se você usar o console, poderá escolher somente a VPC e as sub-redes que deseja usar. Cada grupo de sub-redes de banco de dados deve ter pelo menos uma sub-rede em pelo menos duas zonas de disponibilidade na Região da AWS. Como prática recomendada, cada grupo de sub-redes de banco de dados deve ter no mínimo uma sub-rede para cada zona de disponibilidade na Região da AWS.
Para que um cluster de banco de dados seja acessível publicamente, as sub-redes no grupo de sub-redes de banco de dados devem ter um gateway da Internet. Para ter mais informações sobre gateways da Internet para sub-redes, consulte [“Estabelecer conexão com a Internet usando um gateway da Internet](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html) no *Manual do usuário da Amazon VPC*.
Ao criar um cluster de banco de dados em uma VPC, você pode escolher um grupo de sub-redes de banco de dados. O Amazon Aurora escolhe uma sub-rede e um endereço IP dentro dessa sub-rede para associar ao cluster de banco de dados. Se não houver nenhum grupo de sub-redes de banco de dados, o Amazon Aurora criará um grupo de sub-redes padrão quando você criar um cluster de banco de dados. O Amazon Aurora cria e associa uma interface de rede elástica ao seu cluster de banco de dados com esse endereço IP. O cluster de banco de dados usa a zona de disponibilidade que contém a sub-rede.
Nesta etapa, você criará um grupo de sub-redes de banco de dados e adicionará as sub-redes criadas à sua VPC.
**Como criar um grupo de sub-redes de banco de dados**
1. Abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. No painel de navegação, escolha **Subnet groups (Grupos de sub-redes)**.
1. Escolha **Create DB Subnet Group** (Criar grupo de sub-redes de banco de dados).
1. Em **Name (Nome)**, digite o nome do grupo de sub-redes de banco de dados.
1. Em **Description (Descrição)**, digite uma descrição para o grupo de sub-redes de banco de dados.
1. Para **VPC**, escolha a VPC padrão ou a VPC criada por você.
1. Na seção **Adicionar sub-redes**, escolha as zonas de disponibilidade que incluem as sub-redes de **Zonas de disponibilidade** e escolha as sub-redes de **Sub-redes**.
![\[Criar um grupo de sub-redes de banco de dados.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/RDSVPC101.png)
1. Escolha **Create** (Criar).
Seu novo grupo aparece na lista de grupos de sub-redes de banco de dados no console do RDS. Você pode selecionar o grupo de sub-redes de banco de dados para obter detalhes, incluindo todas as sub-redes associadas a esse grupo, no painel de detalhes, na parte inferior da janela.
### Etapa 3: Criar um grupo de segurança da VPC
Antes de criar um cluster de banco de dados, você pode criar um grupo de segurança da VPC para associar a esse cluster. Se você não criar um grupo de segurança da VPC, poderá usar o grupo de segurança padrão ao criar um cluster de banco de dados. Para obter instruções sobre como criar um grupo de segurança para o cluster de banco de dados, consulte [Criar um grupo de segurança da VPC para um cluster de banco de dados privada](CHAP_Tutorials.WebServerDB.CreateVPC.md#CHAP_Tutorials.WebServerDB.CreateVPC.SecurityGroupDB) ou [Controle o tráfego para recursos usando grupos de segurança](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) no *Guia do usuário da Amazon VPC*.
### Etapa 4: Criar uma instância de banco de dados na VPC
Nessa etapa, você cria um cluster de banco de dados e usa o nome da VPC, o grupo de sub-redes de banco de dados e o grupo de segurança de VPC que você criou nas etapas anteriores.
**nota**
Se quiser que seu cluster de banco de dados na VPC seja acessível ao público geral, você deverá habilitar os atributos *DNS hostnames* (Nomes de host de DNS) e *DNS resolution* (Resolução de DNS). Para ter mais informações, consulte [Atributos de DNS para sua VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html) no *Guia do usuário da Amazon VPC*.
Para obter detalhes sobre como criar um cluster de banco de dados, consulte [Criar um cluster de bancos de dados do Amazon Aurora](Aurora.CreateInstance.md).
Quando solicitado na seção **Connectivity** (Conectividade), insira o nome da VPC, o grupo de sub-redes de banco de dados e o grupo de segurança da VPC.
**nota**
A atualização de VPCs não é compatível com clusters do Aurora no momento.
# Cenários para acessar um cluster de banco de dados em uma VPC
O Amazon Aurora é compatível com os seguintes cenários de acesso a um cluster de banco de dados em uma VPC:
+ [Uma instância do Amazon EC2 na mesma VPC](#USER_VPC.Scenario1)
+ [Uma instância do EC2 em uma VPC diferente](#USER_VPC.Scenario3)
+ [Uma aplicação cliente pela Internet](#USER_VPC.Scenario4)
+ [Uma rede privada](#USER_VPC.NotPublic)
## Um cluster de banco de dados em uma VPC acessada por uma instância do Amazon EC2 na mesma VPC.
Um uso comum de um cluster de banco de dados em uma VPC é compartilhar dados com um servidor de aplicações que está sendo executado em uma instância do Amazon EC2 na mesma VPC.
O diagrama a seguir mostra esse cenário.
![\[Cenário de VPC com um servidor Web público e um banco de dados privado.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/con-VPC-sec-grp-aurora.png)
A maneira mais simples de gerenciar o acesso entre instâncias do EC2 e clusters de banco de dados na mesma VPC é fazer o seguinte:
+ Crie um grupo de segurança de VPC no qual os seus clusters de banco de dados estarão. Esse grupo de segurança pode ser usado para restringir o acesso aos clusters de banco de dados. Por exemplo, você pode criar uma regra personalizada para esse grupo de segurança. Isso pode permitir o acesso TCP usando a porta que você atribuiu ao cluster de banco de dados quando a criou e um endereço IP para acessar o cluster de banco de dados para desenvolvimento ou outros fins.
+ Crie um grupo de segurança da VPC em que as suas instâncias do EC2 (servidores Web e clientes) estarão. Esse grupo de segurança pode, se necessário, permitir o acesso à instância do EC2 pela Internet usando a tabela de roteamento da VPC. Por exemplo, você pode definir regras nesse grupo de segurança para permitir o acesso TCP à instância do EC2 pela porta 22.
+ Crie regras personalizadas no grupo de segurança para seus clusters de banco de dados que permitam conexões do grupo de segurança que você criou para suas instâncias do EC2. Essas regras podem permitir que qualquer membro do grupo de segurança acesse os clusters de banco de dados.
Há uma sub-rede pública e privada adicional em uma zona de disponibilidade separada. Um grupo de sub-redes do banco de dados RDS exige uma sub-rede em, pelo menos, duas zonas de disponibilidade. A sub-rede adicional facilita a migração para uma implantação de instância de banco de dados multi-AZ no futuro.
Para um tutorial que mostra como criar uma VPC com sub-redes públicas e privadas para esse cenário, consulte [Tutorial: Criar uma VPC para usar com um cluster de banco de dados (somente IPv4)](CHAP_Tutorials.WebServerDB.CreateVPC.md).
**dica**
Você pode configurar a conectividade de rede entre uma instância do Amazon EC2 e um cluster de banco de dados automaticamente ao criar o cluster de banco de dados. Para obter mais informações, consulte [Configurar a conectividade automática de rede com uma instância do EC2](Aurora.CreateInstance.md#Aurora.CreateInstance.Prerequisites.VPC.Automatic) .
**Para criar uma regra em um grupo de segurança de VPC que permita conexões de outro grupo de segurança, faça o seguinte:**
1. Faça login no Console de gerenciamento da AWS e abra o console da Amazon VPC em [https://console.aws.amazon.com/vpc](https://console.aws.amazon.com/vpc).
1. No painel de navegação, selecione **Grupos de segurança**.
1. Escolha ou crie um grupo de segurança ao qual você deseja conceder acesso para membros de outro grupo de segurança. No cenário anterior, esse é o grupo de segurança usado para seus clusters de banco de dados. Vá para a guia **Inbound Rules** (Regras de entrada) e escolha **Edit rules** (Editar regras).
1. Na página **Edit inbound rules** (Editar regras de entrada), escolha **Add Rule** (Adicionar regra).
1. Em **Type** (Tipo), escolha a entrada que corresponde à porta usada ao criar seu cluster de banco de dados, como **MYSQL/Aurora**.
1. Na caixa **Origem**, comece a digitar o ID do grupo de segurança para listar os grupos de segurança correspondentes. Escolha o grupo de segurança com membros que você deseja que tenham acesso aos recursos protegidos por esse grupo de segurança. Esse é o grupo de segurança usado para sua instância do EC2 no cenário anterior.
1. Se necessário, repita as etapas para o protocolo TCP, criando uma regra com **Todos os TCP** como **Tipo** e seu grupo de segurança na caixa **Origem**. Se você pretende usar o protocolo UDP, crie uma regra com **All UDP** (Todos os UDP) como **Type** (Tipo) e seu grupo de segurança em **Source** (Origem).
1. Selecione **Salvar regras**.
A tela a seguir mostra uma regra de entrada com um grupo de segurança como origem.
![\[Adição de um grupo de segurança às regras de outro grupo de segurança.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/con-vpc-add-sg-rule.png)
Para ter mais informações sobre como se conectar ao cluster de banco de dados por meio da instância do EC2, consulte [Como conectar-se a um cluster de bancos de dados Amazon Aurora](Aurora.Connecting.md).
## Um cluster de banco de dados em uma VPC acessada por uma instância do EC2 em uma VPC diferente
Quando seu cluster de banco de dados está em uma VPC diferente da instância do EC2 que você está usando para acessá-la, você pode usar emparelhamento de VPC para acessar o cluster de banco de dados.
O diagrama a seguir mostra esse cenário.
![\[Uma instância de banco de dados em uma VPC acessada por uma instância do Amazon EC2 em uma VPC diferente.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/RDSVPC2EC2VPC-aurora.png)
Uma conexão de emparelhamento da VPC é uma conexão de redes entre duas VPCs que permite direcionar o tráfego entre elas usando endereços IP privados. Recursos em qualquer VPC podem se comunicar uns com os outros como se estivessem na mesma rede. É possível criar uma conexão de emparelhamento da VPC entre suas próprias VPCs, com uma VPC em outra conta da AWS ou com uma VPC em uma Região da AWS diferente. Para saber mais sobre o emparelhamento de VPCs, consulte [Emparelhamento de VPCs](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html), no *Guia do usuário do Amazon Virtual Private Cloud*.
## Um cluster de banco de dados em uma VPC acessada por uma aplicação cliente pela internet
Para acessar um cluster de banco de dados em uma VPC de uma aplicação cliente via Internet, configure uma VPC com uma sub-rede pública única e um gateway da Internet para permitir a comunicação pela Internet.
O diagrama a seguir mostra esse cenário.
![\[Um cluster de banco de dados em uma VPC acessada por uma aplicação cliente pela internet.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/GS-VPC-network-aurora.png)
Recomendamos a seguinte configuração:
+ Uma VPC de tamanho /16 (por exemplo, CIDR: 10.0.0.0/16). Esse tamanho fornece 65.536 endereços IP privados.
+ Uma sub-rede de tamanho /24 (por exemplo CIDR: 10.0.0.0/24). Esse tamanho fornece 256 endereços IP privados.
+ Um cluster associado do Amazon Aurora à VPC e à sub-rede. O Amazon RDS atribui um endereço IP da sub-rede ao seu cluster de banco de dados.
+ Um gateway da Internet que conecta a VPC à Internet e a outros produtos da AWS.
+ Um grupo de segurança associado com o cluster de banco de dados. As regras de entrada de grupo de segurança permitem que sua aplicação cliente acesse o seu cluster de banco de dados.
Para ter mais informações sobre como criar um cluster de banco de dados em uma VPC, consulte [Criar um cluster de banco de dados em uma VPC](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.InstanceInVPC).
## Um cluster de banco de dados em uma VPC acessado por uma rede privada
Se seu cluster de banco de dados não estiver acessível publicamente, você terá as seguintes opções para acessá-la a partir de uma rede privada:
+ Uma conexão AWS Site-to-Site VPN. Para ter mais informações, consulte [O que é o AWS Site-to-Site VPN?](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html)
+ Uma conexão Direct Connect. Para obter mais informações, consulte [O que é o Direct Connect?](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html)
+ Uma conexão AWS Client VPN. Para ter mais informações, consulte [O que é o AWS Client VPN?](https://docs.aws.amazon.com//vpn/latest/clientvpn-admin/what-is.html)
O diagrama a seguir mostra um cenário com uma conexão AWS Site-to-Site VPN.
![\[Clusters de banco de dados em uma VPC acessada por uma rede privada.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/site-to-site-vpn-connection-aurora.png)
Para obter mais informações, consulte [Privacidade do tráfego entre redes](inter-network-traffic-privacy.md).
# Tutorial: Criar uma VPC para usar com um cluster de banco de dados (somente IPv4)
Um cenário comum inclui um cluster de banco de dados em uma nuvem privada virtual (VPC) com base no serviço Amazon VPC. Essa VPC compartilha dados com um servidor Web em execução na mesma VPC. Neste tutorial, você cria a VPC para esse cenário.
O diagrama a seguir mostra esse cenário. Para obter informações sobre outros cenários, consulte [Cenários para acessar um cluster de banco de dados em uma VPC](USER_VPC.Scenarios.md).
![\[Cenário de VPC única\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/con-VPC-sec-grp-aurora.png)
Seu cluster de banco de dados só precisa estar disponível para seu servidor Web e não para a Internet pública. Assim, você cria uma VPC com sub-redes públicas e privadas. O servidor Web está hospedado na sub-rede pública, para que ele possa chegar à Internet pública. O cluster de banco de dados está hospedado em uma sub-rede privada. O servidor Web pode se conectar ao cluster de banco de dados porque ela está hospedado na mesma VPC. Mas o cluster de banco de dados não está disponível para a Internet pública, o que oferece maior segurança.
Esse tutorial configura uma sub-rede pública e privada adicional em uma zona de disponibilidade separada. Essas sub-redes não são usadas no tutorial. Um grupo de sub-redes do banco de dados RDS exige uma sub-rede em, pelo menos, duas zonas de disponibilidade. A sub-rede adicional facilita a configuração de mais de uma instância de banco de dados Aurora.
Este tutorial descreve como configurar uma VPC para clusters de bancos de dados Amazon Aurora. Para obter um tutorial que mostra como criar um servidor Web para esse cenário de VPC, consulte [Tutorial: crie um servidor Web e um cluster de banco de dados do Amazon Aurora](TUT_WebAppWithRDS.md). Para obter mais informações sobre uma Amazon VPC, consulte o [Guia de conceitos básicos da Amazon VPC](https://docs.aws.amazon.com/AmazonVPC/latest/GettingStartedGuide/) e [Guia do usuário da Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/).
**dica**
Você pode configurar a conectividade de rede entre uma instância do Amazon EC2 e um cluster de banco de dados automaticamente ao criar o cluster de banco de dados. A configuração da rede é semelhante à descrita neste tutorial. Para obter mais informações, consulte [Configurar a conectividade automática de rede com uma instância do EC2](Aurora.CreateInstance.md#Aurora.CreateInstance.Prerequisites.VPC.Automatic).
## Criar uma VPC com sub-redes públicas e privadas
Use o seguinte procedimento para criar uma VPC com sub-redes públicas e privadas.
**Para criar uma VPC e sub-redes**
1. Abra o console da Amazon VPC, em [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. No canto superior direito do Console de gerenciamento da AWS, escolha a região na qual deseja criar sua VPC. Este exemplo usa a região Oeste dos EUA (Oregon).
1. No canto superior esquerdo, escolha **VPC dashboard** (Painel da VPC). Para começar a criar uma VPC, escolha **Create VPC** (Criar VPC).
1. Para **Resources to create** (Recursos a serem criados) em **VPC settings** (Configurações da VPC), escolha **VPC and more** (VPC e mais).
1. Para **VPC settings** (Configurações da VPC), defina os seguintes valores:
+ **Name tag auto-generation** (Geração automática da etiqueta de nome): **tutorial**
+ **IPv4 CIDR block** (Bloco CIDR IPv4): **10.0.0.0/16**
+ **IPv6 CIDR block** (Bloco CIDR IPv6): **No IPv6 CIDR Block** (Nenhum bloco CIDR IPv6)
+ **Tenancy** (Locação): **Default** (Padrão)
+ **Number of Availability Zones (AZs)** [Número de zonas de disponibilidade (AZs)]: **2**
+ **Customize AZs** (Personalizar AZs): mantenha os valores padrão.
+ **Number of public subnet** (Número de sub-redes públicas):**2**
+ **Number of private subnets** (Número de sub-redes privadas): **2**
+ **Customize subnets CIDR blocks** (Personalizar blocos CIDR de sub-redes): mantenha os valores padrão.
+ **NAT gateways (\$1)** (Gateways NAT (\$1)): **None** (Nenhum)
+ **VPC endpoints** (Endpoints da VPC): **None** (Nenhum)
+ **DNS options** (Opções de DNS): mantenha os valores padrão.
1. Escolha **Criar VPC**.
## Criar um grupo de segurança de VPC para um servidor Web público
Em seguida, você criará um grupo de segurança para acesso público. Para se conectar a instâncias públicas do EC2 em sua VPC, adicione regras de entrada ao seu grupo de segurança de VPC. Isso permite que o tráfego se conecte pela Internet.
**Para criar um grupo de segurança de VPC**
1. Abra o console da Amazon VPC em [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Escolha **VPC Dashboard (Painel da VPC)**, **Security Groups (Grupos de segurança)** e depois **Create grupo de segurança (Criar grupo de segurança)**.
1. Na página **Create grupo de segurança (Criar grupo de segurança)**, defina esses valores:
+ **Security group name (Nome do grupo de segurança:** **tutorial-securitygroup**
+ **Descrição:** **Tutorial Security Group**
+ **VPC:** escolha a VPC criada na etapa anterior; por exemplo, **vpc-*identifier* (tutorial-vpc)**
1. Adicione regras de entrada ao grupo de segurança.
1. Determine o endereço IP a ser usado para se conectar a instâncias do EC2 em sua VPC usando Secure Shell (SSH). Para determinar seu endereço IP público, em uma janela ou guia diferente do navegador, é possível usar o serviço em [https://checkip.amazonaws.com](https://checkip.amazonaws.com). Um exemplo de endereço IP: `203.0.113.25/32`.
Em muitos casos, você pode se conectar por meio de um provedor de serviços de Internet (ISP) ou atrás de um firewall sem um endereço IP estático. Se sim, especifique o intervalo de endereços IP utilizado por computadores cliente.
**Atenção**
Se usar `0.0.0.0/0` para acesso do SSH, você possibilitará que todos os endereços IP acessem suas instâncias públicas usando SSH. Essa abordagem é aceitável por um período curto em um ambiente de teste, mas não é seguro em ambientes de produção. Em produção, autorize somente um endereço IP específico ou um intervalo de endereços para acessar suas instâncias usando SSH.
1. Na seção **Regras de entrada**, escolha **Adicionar regra**.
1. Defina os valores a seguir para a sua nova regra de entrada, para possibilitar o acesso do SSH à sua instância do Amazon EC2. Se você fizer isso, poderá se conectar à sua instância do Amazon EC2 para instalar o servidor Web e outros utilitários. Você também se conecta à sua instância do EC2 para fazer upload de conteúdo para seu servidor Web.
+ **Digite:** **SSH**
+ **Origem:** o endereço IP ou o intervalo da etapa A, por exemplo: **203.0.113.25/32**.
1. Escolha **Add rule (Adicionar regra)**.
1. Defina os seguintes valores para a sua nova regra de entrada a fim de permitir o acesso HTTP ao servidor Web.
+ **Tipo:** **HTTP**
+ **Source (Origem:** **0.0.0.0/0**
1. Escolha **Create grupo de segurança** (Criar grupo de segurança) para criar o grupo de segurança.
Anote o ID do grupo de segurança porque você precisa dele posteriormente neste tutorial.
## Criar um grupo de segurança da VPC para um cluster de banco de dados privada
Para manter seu cluster de banco de dados particular, crie um segundo grupo de segurança para acesso privado. Para se conectar a clusters privados de banco de dados na VPC, você adiciona regras de entrada ao grupo de segurança da VPC que permitem o tráfego somente pelo seu servidor web.
**Para criar um grupo de segurança de VPC**
1. Abra o console da Amazon VPC em [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Escolha **VPC Dashboard (Painel da VPC)**, **Security Groups (Grupos de segurança)** e depois **Create grupo de segurança (Criar grupo de segurança)**.
1. Na página **Create grupo de segurança (Criar grupo de segurança)**, defina esses valores:
+ **Security group name (Nome do grupo de segurança:** **tutorial-db-securitygroup**
+ **Descrição:** **Tutorial DB Instance Security Group**
+ **VPC:** escolha a VPC criada na etapa anterior; por exemplo, **vpc-*identifier* (tutorial-vpc)**
1. Adicione regras de entrada ao grupo de segurança.
1. Na seção **Regras de entrada**, escolha **Adicionar regra**.
1. Defina os valores a seguir para a sua nova regra de entrada, para permitir o tráfego MySQL na porta 3306 de sua instância do Amazon EC2. Se fizer isso, você poderá se conectar de seu servidor Web ao seu cluster de banco de dados. Ao fazer isso, você poderá armazenar e recuperar dados de sua aplicação Web para seu banco de dados.
+ **Tipo:** **MySQL/Aurora**
+ **Source** (Origem): o identificador do grupo de segurança **tutorial-securitygroup** criado anteriormente neste tutorial; por exemplo, **sg-9edd5cfb**.
1. Escolha **Create grupo de segurança** (Criar grupo de segurança) para criar o grupo de segurança.
## Criar um grupo de sub-redes de banco de dados
Um *grupo de sub-redes de banco de dados* é uma coleção de sub-redes que você cria em uma VPC e depois designa para seus clusters de bancos de dados. Um grupo de sub-redes de banco de dados permite que você especifique uma VPC ao criar clusters de banco de dados.
**Como criar um grupo de sub-redes de banco de dados**
1. Identifique as sub-redes privadas do seu banco de dados na VPC.
1. Abra o console da Amazon VPC, em [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Escolha **VPC Dashboard** (Painel da VPC), depois selecione **Subnets** (Sub-redes).
1. Anote os IDs das sub-redes chamadas **tutorial-subnet-private1-us-west-2a** e **tutorial-subnet-private2-us-west-2b**.
Você precisará dos IDs de sub-rede ao criar seu grupo de sub-redes de banco de dados.
1. Abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
Conecte-se ao console do Amazon RDS, não ao console da Amazon VPC.
1. No painel de navegação, escolha **Subnet groups (Grupos de sub-redes)**.
1. Escolha **Create DB Subnet Group** (Criar grupo de sub-redes de banco de dados).
1. Na página **Create DB subnet group (Criar grupo de sub-redes de banco de dados)**, defina esses valores em **Subnet group details (Detalhes do grupo de sub-redes)**:
+ **Nome:** **tutorial-db-subnet-group**
+ **Descrição:** **Tutorial DB Subnet Group**
+ **VPC:** **tutorial-vpc (vpc-*identifier*)**
1. Na seção **Adicionar sub-redes**, escolha **Zonas de disponibilidade** e **Sub-redes**.
Para este tutorial, escolha **us-west-2a** e **us-west-2b** para as **Availability Zones** (Zonas de disponibilidade). Para **Subnets** (Sub-redes), escolha as sub-redes privadas que você identificou na etapa anterior.
1. Escolha **Criar**.
Seu novo grupo aparece na lista de grupos de sub-redes de banco de dados no console do RDS. Você pode selecionar o grupo de sub-redes de banco de dados para visualizar detalhes no painel de detalhes na parte inferior da janela. Esses detalhes incluem todas as sub-redes associadas ao grupo.
**nota**
Se você criou essa VPC para concluir [Tutorial: crie um servidor Web e um cluster de banco de dados do Amazon Aurora](TUT_WebAppWithRDS.md), crie de cluster de banco de dados seguindo as instruções em [Criar um cluster de banco de dados do Amazon Aurora](CHAP_Tutorials.WebServerDB.CreateDBCluster.md).
## Como excluir a VPC
Depois de criar a VPC e outros recursos para este tutorial, você poderá excluí-los se deixarem de ser necessários.
**nota**
Se você incluiu recursos na VPC que criou para este tutorial, talvez seja necessário excluí-los para poder excluir a VPC. Por exemplo, esses recursos podem incluir instâncias do Amazon EC2 ou clusters de banco de dados do Amazon RDS. Para obter mais informações, consulte [Como excluir a sua VPC](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#VPC_Deleting) no *Guia do usuário da Amazon VPC*.
**Para excluir uma VPC e recursos relacionados**
1. Exclua o grupo de sub-redes de banco de dados.
1. Abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. No painel de navegação, escolha **Subnet groups (Grupos de sub-redes)**.
1. Selecione o grupo de sub-rede de banco de dados que deseja excluir, como, por exemplo, **tutorial-db-subnet-group**.
1. Escolha **Delete** (Excluir) e, em seguida, **Delete** (Excluir) na janela de confirmação.
1. Anote o ID da VPC.
1. Abra o console da Amazon VPC, em [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Escolha **VPC Dashboard** (Painel da VPC) e, em seguida, **VPCs**.
1. Na lista, identifique a VPC que criou, como **tutorial-vpc**.
1. Anote o **VPC ID** (ID da VPC) da VPC que você criou. Você precisará do ID da VPC nas etapas posteriores.
1. Exclua os grupos de segurança.
1. Abra o console da Amazon VPC, em [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Escolha **VPC Dashboard** (Painel da VPC) e, em seguida, **Security Groups** (Grupos de segurança).
1. Selecione o grupo de segurança para a instância de banco de dados do Amazon RDS, como, por exemplo, **tutorial-db-securitygroup**.
1. Em **Actions** (Ações), escolha **Delete grupo de seguranças** (Excluir grupos de segurança) e, depois, **Delete** (Excluir) na página de confirmação.
1. Na página **Security Groups** (Grupos de segurança), selecione o grupo de segurança para a instância do Amazon EC2, como, por exemplo, **tutorial-securitygroup**.
1. Em **Actions** (Ações), escolha **Delete grupo de seguranças** (Excluir grupos de segurança) e, depois, **Delete** (Excluir) na página de confirmação.
1. Exclua a VPC.
1. Abra o console da Amazon VPC, em [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Escolha **VPC Dashboard** (Painel da VPC) e, em seguida, **VPCs**.
1. Selecione a VPC que deseja excluir, como, por exemplo, **tutorial-vpc**.
1. Em **Actions (Ações)**, escolha **Delete VPC (Excluir a VPC)**.
A página de confirmação mostra outros recursos associados à VPC que também serão excluídos, incluindo as sub-redes associadas a ela.
1. Na página de confirmação, insira **delete** e, em seguida, escolha **Delete** (Excluir).
# Tutorial: Criar uma VPC para uso com um cluster de banco de dados (modo de pilha dupla)
Um cenário comum inclui um cluster de banco de dados em uma nuvem privada virtual (VPC) com base no serviço Amazon VPC. Essa VPC compartilha dados com uma instância pública do Amazon EC2 que está sendo executada na mesma VPC.
Neste tutorial, você criará a VPC para esse cenário que funciona com um banco de dados em execução no modo de pilha dupla. Modo de pilha dupla para permitir a conexão pelo protocolo de endereçamento IPv6. Para obter mais informações sobre endereçamento IP, consulte [Endereçamento IP do Amazon Aurora](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.IP_addressing).
Os clusters de rede de pilha dupla são compatíveis na maioria das regiões. Para obter mais informações, consulte [Disponibilidade de clusters de banco de dados de rede de pilha dupla](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.IP_addressing.dual-stack-availability). Para ver as limitações do modo de pilha dupla, consulte [Limitações para clusters de banco de dados de rede de pilha dupla](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.IP_addressing.dual-stack-limitations).
O diagrama a seguir mostra esse cenário.
![\[Cenário da VPC para o modo de pilha dupla\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/con-VPC-sec-grp-dual-stack-aurora.png)
Para obter informações sobre outros cenários, consulte [Cenários para acessar um cluster de banco de dados em uma VPC](USER_VPC.Scenarios.md).
Seu cluster de banco de dados só precisa estar disponível para sua instância do Amazon EC2 e não para a Internet pública. Assim, você cria uma VPC com sub-redes públicas e privadas. A instância do Amazon EC2 é hospedada na sub-rede pública, para que ela possa acessar a Internet pública. O cluster de banco de dados está hospedado em uma sub-rede privada. A instância do Amazon EC2 pode se conectar ao cluster de banco de dados porque ela está hospedada na mesma VPC. No entanto, o cluster de banco de dados não está disponível para a Internet pública, o que oferece maior segurança.
Esse tutorial configura uma sub-rede pública e privada adicional em uma zona de disponibilidade separada. Essas sub-redes não são usadas no tutorial. Um grupo de sub-redes do banco de dados RDS exige uma sub-rede em, pelo menos, duas zonas de disponibilidade. A sub-rede adicional facilita a configuração de mais de uma instância de banco de dados Aurora.
Para criar um cluster de banco de dados que use o modo de pilha dupla, especifique **Dual-stack mode** (Modo de pilha dupla) para a configuração **Network type** (Tipo de rede). Você também pode modificar um cluster de banco de dados com a mesma configuração. Para ter mais informações sobre como criar um cluster de banco de dados, consulte [Criar um cluster de bancos de dados do Amazon Aurora](Aurora.CreateInstance.md). Para ter mais informações sobre como modificar um cluster de banco de dados, consulte [Modificar um cluster de bancos de dados Amazon Aurora](Aurora.Modifying.md).
Este tutorial descreve como configurar uma VPC para clusters de bancos de dados Amazon Aurora. Para obter mais informações sobre o Amazon VPC, consulte o [Manual do usuário do Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/).
## Criar uma VPC com sub-redes públicas e privadas
Use o seguinte procedimento para criar uma VPC com sub-redes públicas e privadas.
**Para criar uma VPC e sub-redes**
1. Abra o console da Amazon VPC, em [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. No canto superior direito do Console de gerenciamento da AWS, escolha a região na qual deseja criar sua VPC. Este exemplo usa a região Leste dos EUA (Ohio).
1. No canto superior esquerdo, escolha **VPC dashboard** (Painel da VPC). Para começar a criar uma VPC, escolha **Create VPC** (Criar VPC).
1. Para **Resources to create** (Recursos a serem criados) em **VPC settings** (Configurações da VPC), escolha **VPC and more** (VPC e mais).
1. Para o restante de **VPC settings** (Configurações da VPC), defina os seguintes valores:
+ **Name tag auto-generation (Geração automática da etiqueta de nome** – **tutorial-dual-stack**
+ **IPv4 CIDR block (Bloco CIDR IPv** – **10.0.0.0/16**
+ **IPv6 CIDR block** (Bloco CIDR IPv6): **Amazon-provided IPv6 CIDR block** (Bloco CIDR IPv6 fornecido pela Amazon)
+ **Tenancy** (Locação): **Default** (Padrão)
+ **Number of Availability Zones (AZs) [Número de zonas de disponibilidade (AZs)** – **2**
+ **Customize AZs** (Personalizar AZs): mantenha os valores padrão.
+ **Number of public subnet (Número de sub-redes públicas** – **2**
+ **Number of private subnets (Número de sub-redes privadas** – **2**
+ **Customize subnets CIDR blocks** (Personalizar blocos CIDR de sub-redes): mantenha os valores padrão.
+ **NAT gateways (\$1)** (Gateways NAT (\$1)): **None** (Nenhum)
+ **Egress only internet gateway** (Gateway da Internet somente de saída): **No** (Não)
+ **VPC endpoints** (Endpoints da VPC): **None** (Nenhum)
+ **DNS options** (Opções de DNS): mantenha os valores padrão.
**nota**
O Amazon RDS exige pelo menos duas sub-redes em duas zonas de disponibilidade diferentes para oferecer suporte a implantações de instâncias de banco de dados multi-AZ. Este tutorial cria uma implantação single-AZ, mas o requisito facilita a conversão para uma implantação de instância de banco de dados multi-AZ no futuro.
1. Escolha **Criar VPC**.
## Criar um grupo de segurança da VPC para uma instância pública do Amazon EC2
Em seguida, você criará um grupo de segurança para acesso público. Para se conectar a instâncias públicas do EC2 na sua VPC, adicione regras de entrada ao grupo de segurança de sua VPC que permitam que o tráfego se conecte da Internet.
**Para criar um grupo de segurança de VPC**
1. Abra o console da Amazon VPC em [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Escolha **VPC Dashboard (Painel da VPC)**, **Security Groups (Grupos de segurança)** e depois **Create grupo de segurança (Criar grupo de segurança)**.
1. Na página **Create grupo de segurança (Criar grupo de segurança)**, defina esses valores:
+ **Security group name (Nome do grupo de segurança:** **tutorial-dual-stack-securitygroup**
+ **Descrição:** **Tutorial Dual-Stack Security Group**
+ **VPC:** escolha a VPC criada na etapa anterior, por exemplo **vpc-*identifier*(tutorial-dual-stack-vpc)**
1. Adicione regras de entrada ao grupo de segurança.
1. Determine o endereço IP a ser usado para se conectar a instâncias do EC2 em sua VPC usando Secure Shell (SSH).
Um exemplo de endereço IPv4 (Internet Protocol versão 4) é `203.0.113.25/32`. Um exemplo de intervalo de endereços de Protocolo de Internet versão 6 (IPv6) é `2001:db8:1234:1a00::/64`.
Em muitos casos, você pode se conectar por meio de um provedor de serviços de Internet (ISP) ou atrás de um firewall sem um endereço IP estático. Se sim, especifique o intervalo de endereços IP utilizado por computadores cliente.
**Atenção**
Se usar `0.0.0.0/0` para IPv4 ou `::0` para IPv6, você possibilitará que todos os endereços IP acessem suas instâncias públicas usando SSH. Essa abordagem é aceitável por um período curto em um ambiente de teste, mas não é seguro em ambientes de produção. No ambiente de produção, autorize apenas um endereço IP específico ou um intervalo de endereços a acessar as instâncias.
1. Na seção **Regras de entrada**, escolha **Adicionar regra**.
1. Defina os valores a seguir para a sua nova regra de entrada, para permitir o acesso Secure Shell (SSH) à sua instância do Amazon EC2. Se você fizer isso, poderá se conectar à instância do EC2 para instalar clientes SQL e outras aplicações. Especifique um endereço IP para que você possa acessar sua instância do EC2:
+ **Tipo:** **SSH**
+ **Source** (Fonte): o endereço IP ou o intervalo da etapa a. Um exemplo de endereço IP IPv4 é **203.0.113.25/32**. Um exemplo de endereço IP IPv6 é **2001:DB8::/32**.
1. Escolha **Create grupo de segurança** (Criar grupo de segurança) para criar o grupo de segurança.
Anote o ID do grupo de segurança porque você precisa dele posteriormente neste tutorial.
## Criar um grupo de segurança da VPC para um cluster de banco de dados privada
Para manter seu cluster de banco de dados particular, crie um segundo grupo de segurança para acesso privado. Para se conectar a clusters de banco de dados privados em sua VPC, adicione regras de entrada ao seu grupo de segurança de VPC. Eles permitem o tráfego somente de sua instância do Amazon EC2.
**Para criar um grupo de segurança de VPC**
1. Abra o console da Amazon VPC em [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Escolha **VPC Dashboard (Painel da VPC)**, **Security Groups (Grupos de segurança)** e depois **Create grupo de segurança (Criar grupo de segurança)**.
1. Na página **Create grupo de segurança (Criar grupo de segurança)**, defina esses valores:
+ **Security group name (Nome do grupo de segurança:** **tutorial-dual-stack-db-securitygroup**
+ **Descrição:** **Tutorial Dual-Stack DB Instance Security Group**
+ **VPC:** escolha a VPC criada na etapa anterior, por exemplo **vpc-*identifier*(tutorial-dual-stack-vpc)**
1. Adicione regras de entrada ao grupo de segurança:
1. Na seção **Regras de entrada**, escolha **Adicionar regra**.
1. Defina os valores a seguir para a sua nova regra de entrada, para permitir o tráfego MySQL na porta 3306 de sua instância do Amazon EC2. Se fizer isso, você poderá se conectar de sua instância do EC2 ao seu cluster de banco de dados. Ao fazer isso, você poderá enviar dados da instância do EC2 para o banco de dados.
+ **Digite:** **MySQL/Aurora**
+ **Source** (Origem): o identificador do grupo de segurança **tutorial-dual-stack-securitygroup** criado anteriormente neste tutorial; por exemplo, **sg-9edd5cfb**.
1. Para criar o grupo de segurança, escolha **Criar grupo de segurança**.
## Criar um grupo de sub-redes de banco de dados
Um *grupo de sub-redes de banco de dados* é uma coleção de sub-redes que você cria em uma VPC e depois designa para seus clusters de bancos de dados. Ao usar um grupo de sub-redes de banco de dados, você pode especificar uma VPC específica ao criar clusters de banco de dados. Para criar um grupo de sub-redes de banco de dados que seja compatível com `DUAL`, todas as sub-redes devem ser compatíveis com `DUAL`. Para ser compatível com `DUAL`, uma sub-rede deve ter um CIDR IPv6 associado a ela.
**Como criar um grupo de sub-redes de banco de dados**
1. Identifique as sub-redes privadas do seu banco de dados na VPC.
1. Abra o console da Amazon VPC, em [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Escolha **VPC Dashboard** (Painel da VPC), depois selecione **Subnets** (Sub-redes).
1. Anote os IDs das sub-redes chamadas **tutorial-dual-stack-subnet-private1-us-west-2a** e **tutorial-dual-stack-subnet-private2-us-west-2b**.
Você precisará dos IDs de sub-rede ao criar seu grupo de sub-redes de banco de dados.
1. Abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
Conecte-se ao console do Amazon RDS, não ao console da Amazon VPC.
1. No painel de navegação, escolha **Subnet groups (Grupos de sub-redes)**.
1. Escolha **Create DB Subnet Group** (Criar grupo de sub-redes de banco de dados).
1. Na página **Create DB subnet group (Criar grupo de sub-redes de banco de dados)**, defina esses valores em **Subnet group details (Detalhes do grupo de sub-redes)**:
+ **Nome:** **tutorial-dual-stack-db-subnet-group**
+ **Descrição:** **Tutorial Dual-Stack DB Subnet Group**
+ **VPC:** **tutorial-dual-stack-vpc (vpc-*identifier*)**
1. Na seção **Add subnets** (Adicionar sub-redes), escolha as opções **Availability Zones** (Zonas de disponibilidade) e **Subnets** (Sub-redes).
Para este tutorial, escolha **us-east-2a** e **us-east-2b** para as **Availability Zones** (Zonas de disponibilidade). Para **Subnets** (Sub-redes), escolha as sub-redes privadas que você identificou na etapa anterior.
1. Escolha **Criar**.
Seu novo grupo aparece na lista de grupos de sub-redes de banco de dados no console do RDS. Você pode escolher o grupo de sub-redes de banco de dados para ver os detalhes. Isso inclui os protocolos de endereçamento compatíveis e todas as sub-redes associadas ao grupo e o tipo de rede compatível com o grupo de sub-redes de banco de dados.
## Criar uma instância do Amazon EC2 no modo de pilha dupla
Para criar uma instância do Amazon EC2, siga as instruções em [Iniciar uma instância usando o novo assistente de inicialização de instância, versão beta](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-instance-wizard.html) no *Guia do usuário do Amazon EC2*.
Na página **Configure Instance Details** (Configurar os detalhes da instância), defina esses valores e mantenha os outros valores como padrão:
+ **Rede**: escolha uma VPC existente com sub-redes públicas e privadas, como **tutorial-dual-stack-vpc** (vpc-*identifier*), criada em [Criar uma VPC com sub-redes públicas e privadas](#CHAP_Tutorials.CreateVPCDualStack.VPCAndSubnets).
+ **Subnet** (Sub-rede): escolha uma sub-rede pública existente, como **subnet-*identifier* \$1 tutorial-dual-stack-subnet-public1-us-east-2a \$1 us-east-2a** criada em [Criar um grupo de segurança da VPC para uma instância pública do Amazon EC2](#CHAP_Tutorials.CreateVPCDualStack.SecurityGroupEC2).
+ **Auto-assign Public IP** (Atribuir automaticamente IP público): escolha **Enable** (Habilitar).
+ **Auto-assign IPv6 IP** (Atribuir automaticamente IPv6): escolha **Enable** (Habilitar).
+ **Firewall (security groups)** (Firewall (grupos de segurança)): escolha **Select an existing security group** (Selecionar um grupo de segurança existente).
+ **Common security groups** (Grupos de segurança comuns): selecione um grupo de segurança existente, como o `tutorial-securitygroup` criado em [Criar um grupo de segurança da VPC para uma instância pública do Amazon EC2](#CHAP_Tutorials.CreateVPCDualStack.SecurityGroupEC2). Verifique se o grupo de segurança escolhido inclui regras de entrada para Secure Shell (SSH) e acesso HTTP.
## Criar um cluster de banco de dados no modo de pilha dupla
Nesta etapa, crie um cluster de banco de dados do Amazon RDS para execução no modo de pilha dupla.
**Como criar uma instância de banco de dados**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. No canto superior direito do console, escolha a Região da AWS na qual você quer criar o cluster de banco de dados. Este exemplo usa a região Leste dos EUA (Ohio).
1. No painel de navegação, escolha **Databases** (Bancos de dados).
1. Selecione **Criar banco de dados**.
1. Na página **Create database** (Criar banco de dados), verifique se a opção **Standard create** (Criação padrão) está selecionada e escolha o tipo de mecanismo de banco de dados Aurora MySQL.
1. Na seção **Conectividade**, defina estes valores:
+ **Network type** (Tipo de rede): escolha **Dual-stack mode** (Modo de pilha dupla).
![\[Seção Network type (Tipo de rede) no console com o Dual-stack mode (Modo de pilha dupla) selecionado\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/dual-stack-mode.png)
+ **Virtual private cloud (VPC)** (Nuvem privada virtual (VPC): escolha uma VPC existente com sub-redes públicas e privadas, como a **tutorial-dual-stack-vpc** (vpc-*identifier*) criada em [Criar uma VPC com sub-redes públicas e privadas](#CHAP_Tutorials.CreateVPCDualStack.VPCAndSubnets).
A VPC deve ter sub-redes em zonas de disponibilidade diferentes.
+ **DB subnet group** (Grupo de sub-redes de banco de dados): escolha um grupo de sub-redes de banco de dados para a VPC, como **tutorial-dual-stack-db-subnet-group** criado em [Criar um grupo de sub-redes de banco de dados](#CHAP_Tutorials.CreateVPCDualStack.DBSubnetGroup).
+ **Public access** (Acesso público): escolha **No** (Não).
+ **VPC security group (firewall)** (Grupo de segurança da VPC (firewall)): selecione **Choose existing** (Escolher existente).
+ **Existing VPC grupo de seguranças** (Grupos de segurança da VPC existentes): escolha um grupo de segurança da VPC existente configurado para acesso privado, como **tutorial-dual-stack-db-securitygroup** criado em [Criar um grupo de segurança da VPC para um cluster de banco de dados privada](#CHAP_Tutorials.CreateVPCDualStack.SecurityGroupDB).
Remova outros grupos de segurança, como o grupo de segurança padrão, escolhendo o **X** associado.
+ **Availability Zone** (Zona de disponibilidade): escolha **us-west-2a**.
Para evitar o tráfego entre zonas, certifique-se de que a instância de banco de dados e a instância do EC2 estejam na mesma zona de disponibilidade.
1. Nas seções restantes, especifique suas configurações de cluster de banco de dados. Para obter informações sobre cada configuração, consulte [Configurações de clusters de bancos de dados do Aurora](Aurora.CreateInstance.md#Aurora.CreateInstance.Settings).
## Conectar-se à sua instância do Amazon EC2 e ao cluster de banco de dados
Depois de criar a instância do Amazon EC2 e o cluster de banco de dados no modo de pilha dupla, você poderá se conectar a cada uma usando o protocolo IPv6. Para se conectar a uma instância do Amazon EC2 usando o protocolo IPv6, siga as instruções em [Conecte-se à sua instância do Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstances.html) no *Guia do usuário do Amazon EC2*.
Para se conectar à instância de banco de dados do Aurora MySQL por meio da instância do Amazon EC2, siga as instruções em [Conectar-se a um cluster de banco de dados do Aurora MySQL](CHAP_GettingStartedAurora.CreatingConnecting.Aurora.md#CHAP_GettingStartedAurora.Aurora.Connect).
## Como excluir a VPC
Depois de criar a VPC e outros recursos para este tutorial, você poderá excluí-los se deixarem de ser necessários.
Se você incluiu recursos na VPC que criou para este tutorial, talvez seja necessário excluí-los para poder excluir a VPC. Exemplos de recursos são instâncias do Amazon EC2 ou clusters de banco de dados. Para obter mais informações, consulte [Como excluir a sua VPC](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#VPC_Deleting) no *Guia do usuário da Amazon VPC*.
**Para excluir uma VPC e recursos relacionados**
1. Exclua o grupo de sub-redes de banco de dados:
1. Abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. No painel de navegação, escolha **Subnet groups (Grupos de sub-redes)**.
1. Selecione o grupo de sub-redes de banco de dados a ser excluído, por exemplo, **tutorial-db-subnet-group**.
1. Escolha **Delete** (Excluir) e, em seguida, **Delete** (Excluir) na janela de confirmação.
1. Anote o ID da VPC:
1. Abra o console da Amazon VPC, em [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Escolha **VPC Dashboard** (Painel da VPC) e, em seguida, **VPCs**.
1. Na lista, identifique a VPC que você criou, como **tutorial-dual-stack-vpc**.
1. Anote o valor **VPC ID** (ID da VPC) da VPC que você criou. Você precisará do ID da VPC nas etapas subsequentes.
1. Exclua os grupos de segurança:
1. Abra o console da Amazon VPC, em [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Escolha **VPC Dashboard** (Painel da VPC) e, em seguida, **Security Groups** (Grupos de segurança).
1. Selecione o grupo de segurança para a instância de banco de dados do Amazon RDS, como **tutorial-dual-stack-db-securitygroup**.
1. Em **Actions** (Ações), escolha **Delete grupo de seguranças** (Excluir grupos de segurança) e, depois, **Delete** (Excluir) na página de confirmação.
1. Na página **Security Groups** (Grupos de segurança), selecione o grupo de segurança para a instância do Amazon EC2, como **tutorial-dual-stack-securitygroup**.
1. Em **Actions** (Ações), escolha **Delete grupo de seguranças** (Excluir grupos de segurança) e, depois, **Delete** (Excluir) na página de confirmação.
1. Exclua o gateway NAT:
1. Abra o console da Amazon VPC, em [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Escolha **VPC Dashboard** (Painel da VPC) e, em seguida, **NAT Gateways** (Gateways NAT).
1. Selecione o gateway NAT da VPC que você criou. Use o ID da VPC para identificar o gateway NAT correto.
1. Em **Actions** (Ações), escolha **Delete NAT gateway** (Excluir gateway NAT).
1. Na página de confirmação, insira **delete** e, em seguida, escolha **Delete** (Excluir).
1. Exclua a VPC:
1. Abra o console da Amazon VPC, em [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Escolha **VPC Dashboard** (Painel da VPC) e, em seguida, **VPCs**.
1. Selecione a VPC que deseja excluir, como a **tutorial-dual-stack-vpc**.
1. Em **Actions (Ações)**, escolha **Delete VPC (Excluir a VPC)**.
A página de confirmação mostra outros recursos associados à VPC que também serão excluídos, incluindo as sub-redes associadas a ela.
1. Na página de confirmação, insira **delete** e, em seguida, escolha **Delete** (Excluir).
1. Libere os endereços de IP elásticos:
1. Abra o console do Amazon EC2 em [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Escolha **Painel do EC2** e, em seguida, **IPs elásticos**.
1. Selecione o endereço de IP elástico que deseja liberar.
1. Em **Actions** (Ações), escolha **Release Elastic IP addresses** (Liberar endereços de IP elásticos).
1. Na página de confirmação, escolha **Release** (Liberar).