Segurança com o Amazon Aurora PostgreSQL - Amazon Aurora
Como proteger dados do Aurora PostgreSQL com SSL/TLS

Segurança com o Amazon Aurora PostgreSQL

Para obter uma visão geral da segurança do Aurora, consulte Segurança no Amazon Aurora. É possível gerenciar a segurança do Amazon Aurora PostgreSQL em alguns níveis diferentes:

  • Para controlar quem pode realizar ações de gerenciamento do Amazon RDS em clusters de banco de dados e instâncias de banco de dados Aurora PostgreSQL, use o AWS Identity and Access Management (IAM). O IAM processa a autenticação da identidade do usuário antes que o usuário possa acessar o serviço. Ele também processa a autorização, ou seja, se o usuário tem permissão para fazer o que está tentando fazer. A autenticação de banco de dados do IAM é um método de autenticação adicional que pode ser escolhido ao criar o cluster de banco de dados do Aurora PostgreSQL. Para ter mais informações, consulte Gerenciamento de identidade e acesso no Amazon Aurora.

    Ao usar o IAM com o cluster de banco de dados do Aurora PostgreSQL, primeiro faça login no AWS Management Console com suas credenciais do IAM, antes de abrir o console do Amazon RDS em https://console.aws.amazon.com/rds/.

  • Crie clusters de banco de dados do Aurora em uma nuvem privada virtual (VPC) com base no serviço Amazon VPC. Para controlar quais dispositivos e instâncias do Amazon EC2 podem abrir conexões para o endpoint e a porta da instância de banco de dados dos clusters de banco de dados Aurora em uma VPC, use um grupo de segurança da VPC. Você pode fazer essas conexões de endpoint e de porta usando o Secure Sockets Layer (SSL). Além disso, as regras de firewall em sua empresa podem controlar se dispositivos sendo executados nela podem abrir conexões em uma instância de banco de dados. Para ter mais informações sobre VPCs, consulte VPCs da Amazon VPC e Amazon Aurora.

    A locação da VPC compatível depende da classe de instância de banco de dados usada pelos seus clusters de bancos de dados Aurora PostgreSQL. Com a locação de VPC default, o cluster de banco de dados é executado em hardware compartilhado. Com a locação de VPC dedicated, o cluster de banco de dados é executado em uma instância de hardware dedicado. As classes de instâncias de banco de dados com performance intermitente apenas oferecem suporte para locação de VPC padrão. As classes de instância de banco de dados de performance intermitente incluem db.t3 e db.t4g. Todas as outras classes de instâncias de banco de dados Aurora PostgreSQL oferecem suporte a locações de VPC padrão e dedicada.

    Para ter mais informações sobre as classes da instância, consulte Classes de instância de banco de dados Aurora. Para ter mais informações sobre a locação de VPC default e dedicated, consulte Instâncias dedicadas no Guia do usuário do Amazon Elastic Compute Cloud.

  • Para conceder permissões aos bancos de dados do PostgreSQL em execução no cluster de banco de dados do Amazon Aurora, é possível usar a mesma abordagem geral usada em instâncias autônomas do PostgreSQL. Comandos, como CREATE ROLE, ALTER ROLE, GRANT e REVOKE, funcionam exatamente como em bancos de dados on-premises, assim como a modificação direta de bancos de dados, esquemas e tabelas.

    O PostgreSQL gerencia privilégios usando perfis. O perfil rds_superuser é o mais privilegiado em um cluster de banco de dados do Aurora PostgreSQL. Esse perfil é criado automaticamente e concedido ao usuário que cria o cluster de banco de dados (a conta de usuário mestre, postgres por padrão). Para saber mais, consulte Noções básicas de perfis e permissões do PostgreSQL.

Todas as versões disponíveis do Aurora PostgreSQL, incluindo as versões 10, 11, 12, 13, 14 e posteriores, são compatíveis com o SCRAM (Salted Challenge Response Authentication Mechanism) para senhas como uma alternativa ao resumo de mensagens (MD5). Recomendamos que você use o SCRAM porque ele é mais seguro que o MD5. Para ter mais informações, inclusive como migrar senhas de usuários do banco de dados do MD5 para o SCRAM, consulte Usar criptografia de senha SCRAM para PostgreSQL.

Como proteger dados do Aurora PostgreSQL com SSL/TLS

O Amazon RDS oferece suporte à criptografia de Secure Socket Layer (SSL) e Transport Layer Security (TLS) para clusters de bancos de dados Aurora PostgreSQL. Usando o SSL/TLS, você pode criptografar uma conexão entre as suas aplicações e clusters de banco de dados do PostgreSQL do Aurora. Você também pode forçar todas as conexões do seu cluster de bancos de dados Aurora PostgreSQL a usar SSL/TLS. O Amazon Aurora PostgreSQL oferece suporte ao Transport Layer Security (TLS) versões 1.1 e 1.2. Recomendamos usar o TLS 1.2 para conexões criptografadas. Adicionamos suporte ao TLSv1.3 nas seguintes versões do Aurora PostgreSQL:

  • 15.3 e todas as versões posteriores

  • 14.8 e versões 14 posteriores

  • 13.11 e versões 13 posteriores

  • 12.15 e versões 12 posteriores

  • 11.20 e versões 11 posteriores

Para obter informações gerais sobre o suporte para SSL/TLS e bancos de dados do PostgreSQL, consulte Suporte para SSL na documentação do PostgreSQL. Para obter informações sobre como usar uma conexão SSL/TLS via JDBC, consulte Como configurar o cliente na documentação do PostgreSQL.

O suporte a SSL/TLS está disponível em todas as regiões da AWS para o Aurora PostgreSQL. O Amazon RDS criará um certificado SSL/TLS para o seu cluster de bancos de dados Aurora PostgreSQL quando o cluster de banco de dados for criado. Se você habilitar a verificação de certificado SSL/TLS, o certificado SSL/TLS incluirá o endpoint do cluster de banco de dados como o nome comum (CN) do certificado SSL/TLS para se proteger contra ataques de falsificação.

Para se conectar a um cluster de bancos de dados Aurora PostgreSQL via SSL/TLS

  1. Baixe o certificado.

    Para obter informações sobre como baixar certificados, consulte Usar SSL/TLS para criptografar uma conexão com um cluster de banco de dados.

  2. Importe o certificado no sistema operacional.

  3. Conecte-se ao seu cluster de bancos de dados Aurora PostgreSQL via SSL/TLS.

    Quando você se conectar usando o SSL/TLS, seu cliente poderá optar por verificar ou não a cadeia de certificados. Se os seus parâmetros de conexão especificarem sslmode=verify-ca ou sslmode=verify-full, seu cliente exigirá que os certificados de CA do RDS estejam no armazenamento confiável ou sejam referenciados no URL da conexão. Esse requisito tem o objetivo de verificar a cadeia de certificados que assina o seu certificado de banco de dados.

    Quando um cliente, como psql ou JDBC, for configurado com o suporte para SSL/TLS, primeiro ele tentará se conectar ao banco de dados via SSL/TLS por padrão. Se esse cliente não puder se conectar via SSL/TLS, ele retomará a conexão sem SSL/TLS. Por padrão, a opção sslmode para clientes baseados em JDBC e libpq é definida como prefer.

    Use o parâmetro sslrootcert para fazer referência ao certificado, por exemplo sslrootcert=rds-ssl-ca-cert.pem.

Veja a seguir um exemplo de como usar psql para se conectar a um cluster de banco de dados PostgreSQL do Aurora.

$ psql -h testpg.cdhmuqifdpib.us-east-1.rds.amazonaws.com -p 5432 \
    "dbname=testpg user=testuser sslrootcert=rds-ca-2015-root.pem sslmode=verify-full"

Como exigir uma conexão SSL/TLS de um cluster de bancos de dados Aurora PostgreSQL

Você pode exigir que conexões estabelecidas do seu cluster de bancos de dados Aurora PostgreSQL usem SSL/TLS por meio do parâmetro rds.force_ssl. Por padrão, o parâmetro rds.force_ssl é definido como 0 (desativado). Você pode definir o parâmetro rds.force_ssl como 1 (ativado) para exigir SSL/TLS para conexões com o seu cluster de banco de dados. Atualizar o parâmetro rds.force_ssl também define o parâmetro ssl do PostgreSQL para 1 (ativado) e modifica o arquivo pg_hba.conf do seu cluster de banco de dados para oferecer suporte à nova configuração de SSL/TLS.

Você pode definir o valor do parâmetro rds.force_ssl atualizando o grupo de parâmetros do seu cluster de banco de dados. Se o grupo de parâmetros do cluster de banco de dados não for o padrão, e o parâmetro ssl já estiver definido como 1 quando você definir o parâmetro rds.force_ssl como 1, não será necessário reiniciar seu cluster de banco de dados. Caso contrário, você deverá reiniciar seu cluster de banco de dados para que a alteração entre em vigor. Para ter mais informações sobre grupos de parâmetros, consulte Trabalhar com grupos de parâmetros.

Quando o parâmetro rds.force_ssl for definido como 1 para um cluster de banco de dados, você verá um resultado semelhante ao seguinte ao se conectar, indicando a exigência do SSL/TLS:


$ psql postgres -h SOMEHOST.amazonaws.com -p 8192 -U someuser
psql (9.3.12, server 9.4.4)
WARNING: psql major version 9.3, server major version 9.4.
Some psql features might not work.
SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256)
Type "help" for help.

postgres=>

Como determinar o status de conexão SSL/TLS

O status criptografado da conexão é mostrado no banner de login quando você se conecta ao cluster de banco de dados:

Password for user master: 
psql (9.3.12) 
SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256) 
Type "help" for help.   

postgres=>

Você também pode carregar a extensão sslinfo e, então, chamar a função ssl_is_used() para determinar se o SSL/TLS está em uso. A função retornará t se a conexão estiver usando o SSL/TLS; caso contrário, retornará f.


postgres=> create extension sslinfo;
CREATE EXTENSION

postgres=> select ssl_is_used();
 ssl_is_used
---------
t
(1 row)

Você pode usar o comando select ssl_cipher() para determinar a criptografia de SSL/TLS:


postgres=> select ssl_cipher();
ssl_cipher
--------------------
DHE-RSA-AES256-SHA
(1 row)

Se você habilitar set rds.force_ssl e reiniciar seu cluster de banco de dados, as conexões sem SSL serão recusadas com a seguinte mensagem:


$ export PGSSLMODE=disable
$ psql postgres -h SOMEHOST.amazonaws.com -p 8192 -U someuser
psql: FATAL: no pg_hba.conf entry for host "host.ip", user "someuser", database "postgres", SSL off
$

Para obter informações sobre a opção sslmode, consulte Funções de controle de conexão com o banco de dados na documentação do PostgreSQL.

Configurar conjuntos de cifras para conexões a clusters de banco de dados PostgreSQL do Aurora

Usando conjuntos de cifras configuráveis, você pode ter mais controle sobre a segurança de suas conexões de banco de dados. Você pode especificar uma lista de conjuntos de cifras que deseja permitir para proteger conexões SSL/TLS do cliente com seu banco de dados. Com conjuntos de cifras configuráveis, você pode controlar a criptografia de conexão aceita pelo servidor de banco de dados. Fazer isso ajuda a evitar o uso de cifras inseguras ou obsoletas.

Os conjuntos de cifras configuráveis são compatíveis com as versões 11.8 e posteriores do Aurora PostgreSQL.

Para especificar a lista de cifras permitidas para criptografia de conexões, modifique o parâmetro de cluster ssl_ciphers. Defina o parâmetro ssl_ciphers como uma string de valores de criptografia separados por vírgulas em um grupo de parâmetros do cluster usando o AWS Management Console, a AWS CLI ou a API do RDS. Para definir parâmetros de cluster, consulte Modificar parâmetros em um grupo de parâmetros de cluster de banco de dados.

A tabela a seguir mostra as criptografias compatíveis para as versões do mecanismo do Aurora PostgreSQL

Versões de mecanismo do Aurora PostgreSQL Criptografias compatíveis

9.6, 10.20 e anteriores, 11.15 e anterior, 12.10 e anterior, 13.6 e anterior

  • DHE-RSA-AES128-SHA

  • DHE-RSA-AES128-SHA256

  • DHE-RSA-AES128-GCM-SHA256

  • DHE-RSA-AES256-SHA

  • DHE-RSA-AES256-SHA256

  • DHE-RSA-AES256-GCM-SHA384

  • ECDHE-ECDSA-AES256-SHA

  • ECDHE-ECDSA-AES256-GCM-SHA384

  • ECDHE-RSA-AES256-SHA384

  • ECDHE-RSA-AES128-SHA

  • ECDHE-RSA-AES128-SHA256

  • ECDHE-RSA-AES128-GCM-SHA256

  • ECDHE-RSA-AES256-SHA

  • ECDHE-RSA-AES256-GCM-SHA384

10.21, 11.16, 12.11, 13.7, 14.3 e 14.4

  • DHE-RSA-AES128-SHA

  • DHE-RSA-AES128-SHA256

  • DHE-RSA-AES128-GCM-SHA256

  • DHE-RSA-AES256-SHA

  • DHE-RSA-AES256-SHA256

  • DHE-RSA-AES256-GCM-SHA384

  • ECDHE-ECDSA-AES256-SHA

  • ECDHE-ECDSA-AES256-GCM-SHA384

  • ECDHE-RSA-AES256-SHA384

  • ECDHE-RSA-AES128-SHA

  • ECDHE-RSA-AES128-GCM-SHA256

  • ECDHE-RSA-AES256-SHA

  • ECDHE-RSA-AES256-GCM-SHA384

  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

  • TLS_RSA_WITH_AES_256_GCM_SHA384

  • TLS_RSA_WITH_AES_256_CBC_SHA

  • TLS_RSA_WITH_AES_128_GCM_SHA256

  • TLS_RSA_WITH_AES_128_CBC_SHA

  • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

10.22 e posterior, 11.17 e posterior, 12.12 e posterior, 13.8 e posterior, 14.5 e posterior e 15.2 e posterior

  • DHE-RSA-AES128-SHA

  • DHE-RSA-AES128-SHA256

  • DHE-RSA-AES128-GCM-SHA256

  • DHE-RSA-AES256-SHA

  • DHE-RSA-AES256-SHA256

  • DHE-RSA-AES256-GCM-SHA384

  • ECDHE-ECDSA-AES256-SHA

  • ECDHE-ECDSA-AES256-GCM-SHA384

  • ECDHE-RSA-AES256-SHA384

  • ECDHE-RSA-AES128-SHA

  • ECDHE-RSA-AES128-SHA256

  • ECDHE-RSA-AES128-GCM-SHA256

  • ECDHE-RSA-AES256-SHA

  • ECDHE-RSA-AES256-GCM-SHA384

  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

  • TLS_RSA_WITH_AES_256_GCM_SHA384

  • TLS_RSA_WITH_AES_256_CBC_SHA

  • TLS_RSA_WITH_AES_128_GCM_SHA256

  • TLS_RSA_WITH_AES_128_CBC_SHA256

  • TLS_RSA_WITH_AES_128_CBC_SHA

  • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

15.3, 14.8, 13.11, 12.15 e 11.20

  • DHE-RSA-AES128-SHA

  • DHE-RSA-AES128-SHA256

  • DHE-RSA-AES128-GCM-SHA256

  • DHE-RSA-AES256-SHA

  • DHE-RSA-AES256-SHA256

  • DHE-RSA-AES256-GCM-SHA384

  • ECDHE-ECDSA-AES256-SHA

  • ECDHE-ECDSA-AES256-GCM-SHA384

  • ECDHE-RSA-AES256-SHA384

  • ECDHE-RSA-AES128-SHA

  • ECDHE-RSA-AES128-SHA256

  • ECDHE-RSA-AES128-GCM-SHA256

  • ECDHE-RSA-AES256-SHA

  • ECDHE-RSA-AES256-GCM-SHA384

  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

  • TLS_RSA_WITH_AES_256_GCM_SHA384

  • TLS_RSA_WITH_AES_256_CBC_SHA

  • TLS_RSA_WITH_AES_128_GCM_SHA256

  • TLS_RSA_WITH_AES_128_CBC_SHA256

  • TLS_RSA_WITH_AES_128_CBC_SHA

  • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

  • TLS_AES_128_GCM_SHA256

  • TLS_AES_256_GCM_SHA384

Você também pode usar o comando da CLI describe-engine-default-cluster-parameters para determinar quais conjuntos de cifras são atualmente compatíveis com uma família de grupos de parâmetros específica. O exemplo a seguir mostra como obter os valores permitidos para o parâmetro de cluster ssl_cipher para o Aurora PostgreSQL 11.

aws rds describe-engine-default-cluster-parameters --db-parameter-group-family aurora-postgresql11
                
    ...some output truncated...
	{
		"ParameterName": "ssl_ciphers",
		"Description": "Sets the list of allowed TLS ciphers to be used on secure connections.",
		"Source": "engine-default",
		"ApplyType": "dynamic",
		"DataType": "list",
		"AllowedValues": "DHE-RSA-AES128-SHA,DHE-RSA-AES128-SHA256,DHE-RSA-AES128-GCM-SHA256,DHE-RSA-AES256-SHA,DHE-RSA-AES256-SHA256,DHE-RSA-AES256-GCM-SHA384,
		ECDHE-RSA-AES128-SHA,ECDHE-RSA-AES128-SHA256,ECDHE-RSA-AES128-GCM-SHA256,ECDHE-RSA-AES256-SHA,ECDHE-RSA-AES256-SHA384,ECDHE-RSA-AES256-GCM-SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,
		TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256,
		TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA",
		"IsModifiable": true,
		"MinimumEngineVersion": "11.8",
		"SupportedEngineModes": [
			"provisioned"
		]
	},
    ...some output truncated...

O parâmetro ssl_ciphers é o padrão para todos os conjuntos de criptografia permitidos. Para ter mais informações sobre cifras, consulte a variável ssl_ciphers na documentação do PostgreSQL.