Segurança do RDS: criptografia e grupos de parâmetros

O RDS é compatível com criptografia em repouso usando o AWS Key Management Service (KMS). Quando você habilita a criptografia durante a criação da instância de banco de dados, todos os dados nos volumes EBS subjacentes, nos backups automatizados, nos instantâneos e nas réplicas de leitura são criptografados usando a chave KMS especificada.

A criptografia deve ser habilitada no momento da criação — não é possível criptografar no local uma instância existente que não esteja criptografada. A solução alternativa é fazer um instantâneo não criptografado, copiá-lo com a criptografia habilitada e restaurá-lo a partir do instantâneo criptografado. A chave KMS pode ser uma chave gerenciada pela AWS ou uma chave gerenciada pelo cliente (CMK), para obter mais controle e auditoria.

Como não é possível ativar a criptografia em uma instância existente, siga este processo de migração:

1. Crie um snapshot manual da instância sem criptografia
2. Copie o snapshot e ative a criptografia durante a cópia, especificando uma chave KMS
3. Restaure uma nova instância de banco de dados a partir do snapshot criptografado
4. Atualize o endpoint da sua aplicação para apontar para a nova instância
5. Exclua a instância antiga sem criptografia

Essa abordagem causa algum tempo de inatividade, a menos que você use DMS para manter a nova instância criptografada sincronizada antes da mudança.

O RDS criptografa os dados em trânsito usando SSL/TLS. Cada mecanismo fornece um certificado de CA que pode ser baixado e que o driver do cliente usa para verificar a identidade do servidor. Para exigir conexões SSL, configure o mecanismo de banco de dados para rejeitar conexões sem criptografia.

Para MySQL, defina o parâmetro require_secure_transport = ON no grupo de parâmetros. Para PostgreSQL, defina ssl = 1 e, opcionalmente, rds.force_ssl = 1 para rejeitar completamente conexões que não usem SSL. Muitos drivers de banco de dados Java e Python também aceitam o parâmetro sslmode=require na string de conexão.

Grupos de parâmetros são coleções nomeadas de configurações do mecanismo que você associa a uma instância RDS. Eles são o equivalente, no RDS, à edição de my.cnf no MySQL ou de postgresql.conf no PostgreSQL, mas são gerenciados pela AWS e têm versões por família de mecanismos.

A AWS fornece um grupo de parâmetros padrão para cada versão do mecanismo, mas suas configurações não podem ser editadas. Para personalizar parâmetros, crie um grupo de parâmetros personalizado, modifique os parâmetros desejados e associe-o à sua instância de banco de dados. Alterações em parâmetros estáticos exigem uma reinicialização; parâmetros dinâmicos entram em vigor imediatamente.

Depois de criar um grupo de parâmetros personalizado, você modifica parâmetros individuais usando o comando modify-db-parameter-group da CLI ou o console. Os parâmetros têm um método de aplicação: immediate (entra em vigor sem reinicialização) ou pending-reboot (só entra em vigor após a próxima reinicialização da instância).

Parâmetros importantes para a prova: max_connections (limita as conexões simultâneas), innodb_buffer_pool_size (tamanho do cache em memória do MySQL), log_bin_trust_function_creators (permite funções armazenadas que gravam no log binário) e rds.force_ssl (força o uso de SSL no PostgreSQL).

Grupos de opções são semelhantes aos grupos de parâmetros, mas controlam recursos adicionais do mecanismo de banco de dados, em vez de ajustar sua configuração. Eles são usados principalmente com Oracle e SQL Server para ativar recursos como Oracle Application Express (APEX), Transparent Data Encryption (TDE) do SQL Server ou autenticação do SQL Server pelo Active Directory.

Cada opção em um grupo de opções pode ter suas próprias configurações. Os grupos de opções têm versões por família de mecanismos e devem ser associados à instância de banco de dados. A maioria dos mecanismos de código aberto (MySQL, PostgreSQL, MariaDB) raramente precisa de grupos de opções personalizados.

O RDS oferece suporte à autenticação de banco de dados pelo IAM para os mecanismos MySQL e PostgreSQL. Em vez de um nome de usuário e uma senha estáticos, sua aplicação assume uma função do IAM e gera um token de autenticação temporário (válido por 15 minutos) usando o comando generate-db-auth-token da AWS CLI ou uma chamada do SDK.

Os benefícios incluem a ausência de senhas de banco de dados de longa duração, a rotação automática das credenciais por meio de políticas do IAM e o controle de acesso centralizado. O recurso exige a ativação de --enable-iam-database-authentication na instância e a criação de um usuário de banco de dados associado a uma função do IAM.

O AWS Secrets Manager pode armazenar e alternar automaticamente a senha principal do RDS e as credenciais da aplicação. Quando a rotação está ativada, o Secrets Manager invoca uma função do Lambda que atualiza a senha do banco de dados e armazena o novo valor no segredo; sua aplicação busca o valor mais recente do segredo por meio da API do Secrets Manager, mantendo sempre credenciais válidas.

Ao criar uma instância RDS no console, você pode optar pelo gerenciamento das credenciais principais pelo Secrets Manager. Isso elimina senhas codificadas diretamente no código ou nas variáveis de ambiente.

As instâncias RDS são executadas dentro de uma VPC e usam grupos de sub-redes de banco de dados para definir em quais sub-redes (em várias AZs) a instância pode ser colocada. A prática recomendada é colocar o RDS em sub-redes privadas, sem acesso direto à Internet.

Grupos de segurança controlam quais endereços IP e outros grupos de segurança podem acessar a porta do banco de dados (por exemplo, TCP 3306 para MySQL). O grupo de segurança da camada da aplicação deve ser a única origem permitida no grupo de segurança do RDS, aplicando o princípio do menor privilégio no nível da rede. Nunca configure 0.0.0.0/0 (todo o tráfego) como regra de entrada em um grupo de segurança do RDS.

O Enhanced Monitoring publica métricas no nível do sistema operacional (CPU, memória, sistema de arquivos, E/S de disco) no CloudWatch Logs a cada 1–60 segundos, oferecendo uma granularidade maior que a das métricas padrão do CloudWatch, de 60 segundos. Ele usa um agente em execução no host do banco de dados e está disponível para todos os mecanismos, exceto no modo de espelhamento do SQL Server.

Os logs de auditoria do banco de dados (log geral de consultas e log de consultas lentas no MySQL; pgaudit no PostgreSQL) podem ser publicados no CloudWatch Logs para análise de conformidade. Ative-os por meio dos grupos de parâmetros e configure as exportações de logs no console do RDS, em Exportações de logs.

Principais práticas recomendadas de segurança do RDS para a prova SAA-C03:

• Ative a criptografia em repouso com uma CMK do KMS ao criar a instância
• Exija SSL/TLS em trânsito por meio das configurações do grupo de parâmetros
• Coloque as instâncias em sub-redes privadas com grupos de segurança restritivos
• Use autenticação de banco de dados pelo IAM ou o Secrets Manager para evitar senhas estáticas
• Ative o CloudTrail para registrar chamadas de API do RDS e o CloudWatch Logs para logs de auditoria do banco de dados
• Use regras do AWS Config (por exemplo, rds-instance-public-access-check) para detectar configurações incorretas

Teste sua compreensão dos conceitos do AWS Solutions Architect (SAA-C03) apresentados nesta lição.

Nesta lição, você aprendeu que: a criptografia em repouso do RDS usa KMS e deve ser ativada durante a criação; os grupos de parâmetros controlam a configuração do mecanismo, incluindo a aplicação de SSL/TLS em trânsito; e a autenticação de banco de dados pelo IAM e o Secrets Manager eliminam senhas estáticas de banco de dados. A seguir, exploraremos tabelas, itens e o design de chaves primárias do DynamoDB.