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