Seguridad de RDS: cifrado y grupos de parámetros

RDS admite el cifrado en reposo mediante AWS Key Management Service (KMS). Cuando habilita el cifrado al crear la instancia de DB, todos los datos de los volúmenes de EBS subyacentes, los backups automatizados, las instantáneas y las réplicas de lectura se cifran mediante la clave de KMS especificada.

El cifrado debe habilitarse durante la creación: no puede cifrar una instancia existente sin cifrar directamente. La solución consiste en tomar una instantánea sin cifrar, copiarla con el cifrado habilitado y restaurarla desde la instantánea cifrada. La clave de KMS puede ser una clave administrada por AWS o una Customer-Managed Key (CMK) para obtener un mayor control y capacidad de auditoría.

Dado que no puede habilitar el cifrado en una instancia existente, siga este proceso de migración:

1. Cree una instantánea manual de la instancia sin cifrar
2. Copie la instantánea y habilite el cifrado durante la copia, especificando una clave de KMS
3. Restaure una instancia de base de datos nueva a partir de la instantánea cifrada
4. Actualice el endpoint de su aplicación para que apunte a la instancia nueva
5. Elimine la instancia antigua sin cifrar

Este enfoque implica cierto tiempo de inactividad, a menos que utilice DMS para mantener sincronizada la instancia nueva y cifrada antes del cambio.

RDS cifra los datos en tránsito mediante SSL/TLS. Cada motor proporciona un certificado de CA descargable que el controlador de su cliente utiliza para verificar la identidad del servidor. Para aplicar las conexiones SSL, configure el motor de base de datos para que rechace las conexiones sin cifrar.

En MySQL, establezca el parámetro require_secure_transport = ON en el grupo de parámetros. En PostgreSQL, establezca ssl = 1 y, opcionalmente, rds.force_ssl = 1 para rechazar por completo las conexiones que no sean SSL. Muchos controladores de bases de datos de Java y Python también aceptan el parámetro sslmode=require en la cadena de conexión.

Los grupos de parámetros son colecciones con nombre de ajustes de configuración del motor que se asocian a una instancia de RDS. Son el equivalente en RDS a editar my.cnf en MySQL o postgresql.conf en PostgreSQL, pero AWS los administra y versiona por familia de motores.

AWS proporciona un grupo de parámetros predeterminado para cada versión del motor, pero sus ajustes no se pueden editar. Para personalizar los parámetros, cree un grupo de parámetros personalizado, modifique los parámetros deseados y asígnelo a su instancia de base de datos. Los cambios en parámetros estáticos requieren un reinicio; los parámetros dinámicos surten efecto de inmediato.

Después de crear un grupo de parámetros personalizado, modifique parámetros individuales mediante el comando de la CLI modify-db-parameter-group o la consola. Los parámetros tienen un método de aplicación: immediate (surte efecto sin reiniciar) o pending-reboot (solo surte efecto después del siguiente reinicio de la instancia).

Parámetros importantes que debe conocer para el examen: max_connections (limita las conexiones simultáneas), innodb_buffer_pool_size (tamaño de la caché en memoria de MySQL), log_bin_trust_function_creators (permite funciones almacenadas que escriben en el registro binario) y rds.force_ssl (fuerza el uso de SSL en PostgreSQL).

Los grupos de opciones son similares a los grupos de parámetros, pero controlan funciones adicionales del motor de base de datos en lugar de ajustar la configuración. Se utilizan principalmente con Oracle y SQL Server para habilitar funciones como Oracle Application Express (APEX), Transparent Data Encryption (TDE) de SQL Server o la autenticación de SQL Server mediante Active Directory.

Cada opción de un grupo de opciones puede tener sus propios ajustes. Los grupos de opciones se versionan por familia de motores y deben asociarse a la instancia de base de datos. La mayoría de los motores de código abierto (MySQL, PostgreSQL, MariaDB) rara vez necesitan grupos de opciones personalizados.

RDS admite la autenticación de bases de datos mediante IAM para los motores MySQL y PostgreSQL. En lugar de utilizar un nombre de usuario y una contraseña estáticos, su aplicación asume un rol de IAM y genera un token de autenticación temporal (válido durante 15 minutos) mediante el comando de la CLI de AWS generate-db-auth-token o una llamada al SDK.

Entre sus ventajas se incluyen la ausencia de contraseñas de base de datos de larga duración, la rotación automática de credenciales mediante políticas de IAM y el control de acceso centralizado. Esta función requiere habilitar --enable-iam-database-authentication en la instancia y crear un usuario de base de datos asignado a un rol de IAM.

AWS Secrets Manager puede almacenar y rotar automáticamente la contraseña maestra de RDS y las credenciales de la aplicación. Cuando la rotación está habilitada, Secrets Manager invoca una función de Lambda que actualiza la contraseña de la base de datos y almacena el nuevo valor en el secreto; su aplicación obtiene el valor más reciente del secreto mediante la API de Secrets Manager, por lo que siempre dispone de credenciales válidas.

Al crear una instancia de RDS en la consola, puede optar por que Secrets Manager administre las credenciales maestras. Esto elimina las contraseñas codificadas directamente en el código o en las variables de entorno.

Las instancias de RDS se ejecutan dentro de una VPC y utilizan grupos de subredes de DB para definir en qué subredes (de varias AZ) se puede colocar la instancia. Una práctica recomendada es colocar RDS en subredes privadas sin acceso directo a Internet.

Los grupos de seguridad controlan qué direcciones IP y qué otros grupos de seguridad pueden acceder al puerto de la base de datos (por ejemplo, TCP 3306 para MySQL). El grupo de seguridad de la capa de aplicación debe ser el único origen permitido en el grupo de seguridad de RDS, aplicando el principio de mínimo privilegio a nivel de red. Nunca configure 0.0.0.0/0 (todo el tráfico) como regla de entrada en un grupo de seguridad de RDS.

Enhanced Monitoring publica métricas a nivel del sistema operativo (CPU, memoria, sistema de archivos, E/S de disco) en CloudWatch Logs cada 1–60 segundos, lo que proporciona una mayor granularidad que las métricas predeterminadas de CloudWatch, que se recopilan cada 60 segundos. Utiliza un agente que se ejecuta en el host de la base de datos y está disponible para todos los motores, excepto para el modo de duplicación de SQL Server.

Los registros de auditoría de la base de datos (registro de consultas generales y registro de consultas lentas de MySQL; pgaudit de PostgreSQL) se pueden publicar en CloudWatch Logs para realizar análisis de cumplimiento. Habilítelos mediante los grupos de parámetros y, a continuación, configure las exportaciones de registros en la consola de RDS, en Log exports.

Prácticas recomendadas clave de seguridad de RDS para el examen SAA-C03:

• Habilite el cifrado en reposo con una CMK de KMS al crear la instancia
• Aplique SSL/TLS en tránsito mediante la configuración de los grupos de parámetros
• Coloque las instancias en subredes privadas con grupos de seguridad restrictivos
• Utilice la autenticación de bases de datos mediante IAM o Secrets Manager para evitar contraseñas estáticas
• Habilite CloudTrail para registrar las llamadas a la API de RDS y CloudWatch Logs para los registros de auditoría de la base de datos
• Utilice reglas de AWS Config (por ejemplo, rds-instance-public-access-check) para detectar configuraciones incorrectas

Compruebe su comprensión de los conceptos de AWS Solutions Architect (SAA-C03) tratados en esta lección.

En esta lección ha aprendido que: el cifrado en reposo de RDS utiliza KMS y debe habilitarse al crear la instancia, los grupos de parámetros controlan la configuración del motor, incluido el uso obligatorio de SSL/TLS en tránsito, y la autenticación de bases de datos mediante IAM y Secrets Manager eliminan las contraseñas estáticas de las bases de datos. A continuación, exploraremos las tablas, los elementos y el diseño de claves principales de DynamoDB.