15 Prácticas recomendadas de ciberseguridad para base de datos AWS RDS

El servicio de base de datos relacional de Amazon ( AWS RDS ) le permite descargar la responsabilidad de administrar una base de datos, pero también conlleva el riesgo de otra dependencia externa. Afortunadamente AWS proporciona algunas herramientas y configuraciones para ayudar con esto. 

Cuando combine su política de seguridad de datos existente con las herramientas de AWS y los consejos de este artículo, estará bien encaminado para administrar el riesgo de manera más efectiva. Profundicemos con 15 prácticas recomendadas de seguridad de datos de AWS RDS.

Cifrar bases de datos RDS

AWS le permite cifrar bases de datos RDS cuando se crean. Es importante tomar esta decisión en el momento de la creación, ya que cifrar las bases de datos existentes no es un proceso sencillo. Existen soluciones alternativas, pero RDS no le permite activar o desactivar el cifrado para una base de datos existente. Tampoco puede crear copias de seguridad cifradas de bases de datos no cifradas.

El cifrado a nivel de base de datos, o cifrado en reposo, protege los datos confidenciales de fugas e infracciones al garantizar que nadie no autorizado pueda leer los datos.

Monitorear conexiones de bases de datos no seguras

AWS RDS le permite conectarse de forma segura a través de SSL/TSL. Para hacerlo, asegúrese de que sus aplicaciones se conecten con los certificados proporcionados por AWS. Puede encontrar el paquete global o los certificados específicos de la región en la documentación de RDS .

Tenga en cuenta que los diferentes motores de bases de datos requerirán configuraciones diferentes, por lo que si sus aplicaciones utilizan RDS, pero diferentes tipos de bases de datos, deberá configurar el cifrado en tránsito para cada uno. 

Habilitar KMS

Cuando cifra una base de datos RDS, la forma más fácil de hacerlo es utilizando el Servicio de administración de claves integrado de AWS (AWS KMS). KMS se encargará de la generación, el almacenamiento e incluso el ciclo de las claves de cifrado. Estas claves se utilizan no solo para cifrar las propias bases de datos, sino también sus instantáneas y copias de seguridad.

A menos que ya confíe en un sistema de administración de claves dedicado, es mejor quedarse con el integrado en AWS.

Verificar nuevos procesamientos de datos

Incluso después de que se haya asegurado una base de datos, es importante monitorear cualquier nueva adición o cambio en su esquema. Esto se puede hacer en el nivel de la aplicación mediante el escaneo (análisis de código estático) del propio código de la aplicación o el análisis de esquema de los archivos de esquema. También se puede hacer en AWS monitoreando los cambios de la base de datos con AWS CloudTrail .

Derechos de acceso a la base de datos de auditoría

Una configuración de administración de acceso e identidad (IAM) bien administrada es crucial para usar AWS de manera segura. Asegúrese de que solo las aplicaciones y los servicios necesarios tengan acceso a cada base de datos. Evite proporcionar derechos de acceso combinados, como permitir que un solo usuario acceda a todas las bases de datos, a menos que sea necesario. Los controles de IAM granulares y limitados ayudan a evitar la fuga accidental de datos.

En general, comience con derechos de acceso mínimos y agregue permisos adicionales según sea necesario. Los derechos deben reevaluarse una vez que se completa el desarrollo de una función para garantizar que no se hayan transferido accidentalmente cambios “temporales” a la función del usuario final.

Asegúrese de que se utilicen las regiones de AWS adecuadas

Si bien es más un problema de privacidad de datos que específicamente una preocupación de seguridad, asegurarse de que el uso regional de AWS coincida con sus políticas de datos internas evitará cualquier problema normativo en el futuro. Especialmente cuando se trata de GDPR y otras regulaciones que definen estrictamente dónde se pueden almacenar y transmitir los datos.

Esto puede ser más difícil de realizar un seguimiento manual, por lo que es mejor definir cuidadosamente estas políticas al principio al crear funciones, o usar una herramienta automatizada que pueda hacer coincidir las regiones de la base de datos con las aplicaciones que acceden a ellas.

Asegúrese de que existan copias de seguridad periódicas

Habilite copias de seguridad periódicas y/o instantáneas de sus bases de datos. Puede ser valioso cifrar también estas copias de seguridad, incluso si las bases de datos en sí no están cifradas. En algunos escenarios, AWS ahora le permitirá cifrar fácilmente una instantánea de una base de datos no cifrada, así que tenga esto en cuenta al crear nuevos servicios.

Tenga en cuenta sus políticas de retención de datos cuando genere copias de seguridad para asegurarse de no almacenar datos de usuario durante más tiempo del que indican sus políticas.

Asegúrese de que las copias de seguridad y las instantáneas estén cifradas en reposo

Como se mencionó anteriormente, AWS no permite copias de seguridad ni instantáneas cifradas de bases de datos no cifradas, así que asegúrese de que la base de datos esté cifrada para generar copias de seguridad e instantáneas cifradas. Las copias de seguridad son copias completas de los datos, mientras que las instantáneas se pueden considerar como pasos de control de versiones más pequeños.

Considere sus políticas de seguridad de datos y asegúrese de que los datos en las copias de seguridad reciban el mismo nivel de protección que los datos en la base de datos.

Evite las copias de seguridad entre regiones

Al igual que con el almacenamiento de datos en la región correcta de acuerdo con los requisitos reglamentarios y de cumplimiento, asegúrese de que sus copias de seguridad también cumplan con esos requisitos. 

Puede ser común que una organización piense en las copias de seguridad de manera diferente a los datos en sí. Esto genera problemas en los que los datos cruzan fronteras accidentalmente. 

Supervisar el acceso a la base de datos

Una vez que haya configurado los roles de IAM apropiados, mencionados anteriormente en esta lista, es una buena práctica monitorear el acceso a las bases de datos de RDS. Esto se puede hacer con AWS CloudTrail.

Supervisar el acceso le permite confirmar que solo los usuarios y aplicaciones requeridos están interactuando con la base de datos. Es una manera fácil de ver si una cuenta de usuario inesperada está en uso o si se creó una nueva cuenta sin pasar por el proceso de aprobación correcto. Esto puede ser un precursor de una fuga o violación de datos.

Supervisar los cambios de configuración de RDS

Los cambios de configuración son un aspecto que se pasa por alto en la seguridad de la base de datos, ya que los servicios se “establecen y se olvidan” mientras funcionan. CloudTrail se puede configurar para observar eventos de cambio de configuración y otros cambios en sus bases de datos.

Elimina las instancias de RDS no utilizadas

A medida que su aplicación cambia con el tiempo, es posible que termine con instancias de bases de datos RDS sin usar o orientadas al desarrollador. Es bueno verificar regularmente que estos sean necesarios y auditar si cumplen con sus políticas de seguridad de datos actuales.

Evite los grupos de acceso sin restricciones

Anteriormente mencionamos a los usuarios de IAM, pero vale la pena mencionarlos nuevamente. Además de establecer derechos individuales para usuarios y servicios específicos, asegúrese de evitar configurar súper cuentas cuando pueda evitarlo. El acceso sin restricciones a los servicios crea un riesgo enorme, especialmente si ese usuario de IAM administra cualquier cosa mediante programación a través de una aplicación o servicio.

Mejore sus notificaciones con GuardDuty

Hemos mencionado CloudTrails varias veces, pero puede ir un paso más allá combinándolo con GuardDuty. GuardDuty le permite configurar “detectores” para buscar eventos inesperados o sospechosos de una variedad de fuentes de datos. De esta manera, no necesita monitorear directamente CloudTrail u otros registros.

Supervise el cumplimiento de las políticas con regularidad

Todos estos consejos solo le serán útiles si se convierten en una parte regular de su postura de seguridad de datos. Muchas organizaciones aún colocan la seguridad de los datos al final del proceso de desarrollo. En su lugar, desplácelo hacia la izquierda incorporando la seguridad de los datos al flujo de trabajo moderno de DevSecOps. Trabaje con sus desarrolladores, sin interponerse en su camino, para monitorear y mitigar los riesgos directamente en el ciclo de vida del desarrollo de software.