La nube híbrida puede ser una excelente manera de agregar flexibilidad a sus implementaciones locales existentes. Como discutimos en varios blogs, la nube pública puede ser una gran adición a su propio centro de datos, asegurando que pueda escalar fácilmente para manejar la carga, reducir su gasto de capital y usarse para implementar procedimientos de recuperación ante desastres. La seguridad es otro aspecto en el que debe pensar cuando planea construir dichos sistemas. En esta publicación de blog, hablaremos sobre algunas de las consideraciones de seguridad para las implementaciones de MariaDB en la nube híbrida.
Conectividad
VPN
La parte principal de toda infraestructura híbrida es la red. Al fin y al cabo, estamos hablando de dos entornos, local, on-premise y nube pública, que tienen que estar conectados y formar una sola entidad. La conexión tiene que estar encriptada. Cómo abordarlo, hay numerosas formas de hacerlo.
Uno de ellos sería utilizar una solución proporcionada por el proveedor de la nube; la mayoría de ellos tienen algún tipo de opción de conectividad disponible. Puede ser AWS Direct Connect si se integra con Amazon Web Services. Si planea usar Google Cloud, las soluciones se analizan en el siguiente sitio web:https://cloud.google.com/hybrid-connectivity. En resumen, hay una cantidad significativa de opciones diferentes que varían desde la integración de VPN de hardware hasta la configuración de intercambio de tráfico BGP.
En el otro lado del espectro, tenemos soluciones VPN de software. Se puede usar OpenVPN o un tipo de software similar para configurar una conexión de red cifrada y segura entre su propio centro de datos y la nube pública. En tal caso, necesitará una instancia separada que se ejecute en la nube pública que se utilizará para el servidor VPN. El uso de VPN de software le permite elegir la solución que mejor se adapte a sus requisitos y se adapte mejor a su entorno.
Cortafuegos
Las bases de datos nunca deben ser accesibles desde redes externas. Es primordial construir su entorno de manera que el nivel de la base de datos sea accesible solo desde el conjunto limitado de hosts. Exactamente lo que se requiere y cómo hacerlo, depende de usted decidir. Una configuración típica consistiría en un nivel de base de datos seguro al que solo se puede acceder desde el nivel de proxy y, si es necesario, se debe implementar algún tipo de host de salto si es necesario para las tareas de automatización y administración.
Los servidores de aplicaciones no deben tener acceso directo a la base de datos; no es necesario. Todo lo que debe hacer la aplicación es conectarse al balanceador de carga. Los balanceadores de carga deberían poder conectarse a la base de datos. Un equilibrador de carga como ProxySQL es perfectamente capaz de realizar la división de lectura/escritura y enviar las lecturas y escrituras a los nodos de base de datos correctos. La aplicación debería poder conectarse a ProxySQL y el proxy manejará el resto:autenticación de la base de datos, configuración del tráfico, distribución del tráfico entre numerosas réplicas que pueda tener. Todo acceso innecesario debe ser restringido. Grupos de seguridad, cortafuegos:estas son las herramientas que desea utilizar para proteger su entorno.
En resumen, el acceso a los hosts de la base de datos debe permitirse solo en los puertos requeridos. Para MariaDB será, obviamente, un puerto utilizado para la base de datos pero también otros puertos si es necesario; es posible que tenga algún tipo de exportadores o agentes instalados. Para Galera, necesitaría abrir puertos para la comunicación dentro del clúster. También es posible que desee tener un puerto abierto para conexiones SSH. Idealmente, limite el acceso por host; solo un conjunto limitado de hosts puede acceder a un puerto determinado. Por ejemplo, se puede acceder al puerto de la base de datos desde los otros nodos de la base de datos, el host local y la capa de proxy. No es necesario mantenerlo abierto para otros nodos. Los nodos de su base de datos pueden incluso estar ubicados en una subred separada, lo que garantiza que la seguridad sea aún más estricta.
En cuanto a los puertos, las mejores prácticas serían cambiarlos de la configuración predeterminada a otra cosa. Idealmente, algo aleatorio. Cambiar el puerto SSH del 22 al 2222 o el puerto MariaDB del 3306 al 33306 puede ayudar a evitar algunos de los ataques automáticos, pero aún se puede averiguar si alguien está buscando activamente ingresar a su red. Si desea una mayor seguridad, puede seguir adelante con algunos valores aleatorios. Establezca SSH en 5762 y MariaDB en 24359. Es muy probable que nadie pueda adivinarlos. Configure sus tiempos de espera de TCP para que los escaneos de puertos sean muy largos y costosos y esto seguramente aumentará sus posibilidades.
SSL
Además de la VPN y el cortafuegos, debe asegurarse de que el tráfico de su base de datos esté encriptado mediante SSL.
Idealmente, protegerá las conexiones frontales (de los balanceadores de carga) y la comunicación entre los nodos de su base de datos (ya sea la replicación o la transferencia dentro del clúster en los clústeres de Galera). ClusterControl puede ayudarlo a habilitar esas opciones con solo unos pocos clics.
Todo lo que necesita hacer es permitir que ClusterControl cree nuevos certificados o use uno de los existentes; puede importar su propio certificado si lo desea. Tener SSL habilitado garantiza que el tráfico de la base de datos no podrá ser leído ni siquiera por alguien que obtuvo acceso a su red.
Seguridad de la base de datos
Por supuesto, la red no es el único aspecto importante de la seguridad. Sí, es crítico, especialmente en el entorno de la nube híbrida, pero también hay otros aspectos muy importantes. Uno de ellos es el control de acceso integrado en MariaDB.
Control de acceso basado en roles para MariaDB
MariaDB viene con un conjunto de instrumentos para garantizar que el acceso a la base de datos se administre y restrinja adecuadamente donde sea necesario. La primera línea de autenticación son los usuarios. Todos y todo lo que tiene permitido acceder a MariaDB debe usar un usuario asignado para conectarse a la base de datos. Dichos usuarios tendrán una contraseña adecuada; puede habilitar la validación de contraseña en MariaDB para asegurarse de que las contraseñas sean lo suficientemente seguras. Idealmente, limitaría el host de acceso del usuario solo a nombres de host o IP de balanceadores de carga; esta debería ser siempre la forma en que los usuarios se conectan a la base de datos. Para algunos usuarios administrativos, es posible que desee mantener el acceso localhost si es necesario. Además de hacer cumplir la seguridad de la contraseña adecuada, puede configurar la contraseña para que caduque dentro de un período de tiempo o forzar la rotación de la contraseña en los usuarios. Como puede imaginar, querrá implementar una política de rotación de contraseñas adecuada.
Cada usuario en MariaDB puede tener múltiples privilegios asignados. Los privilegios se pueden asignar en varios niveles:nivel global, nivel de base de datos, nivel de tabla o incluso nivel de columna. La mejor práctica es otorgar un conjunto limitado de privilegios a los usuarios como sea posible. Si el usuario solo requiere acceso a una tabla en particular, concédelo. No es necesario que ese usuario acceda a otras tablas sin mencionar otros esquemas. Puede definir derechos de acceso bastante detallados utilizando un gran conjunto de privilegios que puede otorgar a los usuarios. Va desde los derechos para leer, actualizar o eliminar datos a través de los privilegios de administración de la base de datos hasta el privilegio "súper" que permite al usuario realizar acciones como administrar los subprocesos de replicación y omitir la configuración de solo lectura.
Además de eso, MariaDB viene con roles:para facilitar la administración de usuarios, es posible definir roles con un conjunto dado de privilegios otorgados y luego asignar esos roles a los usuarios. Dichos usuarios heredarán concesiones relacionadas con la función que se les ha asignado, lo que facilita mucho la gestión de concesiones a gran escala:en lugar de cambiar las concesiones para varios usuarios, puede asignarlas a una función específica y luego administrar todos sus privilegios mediante alterando los privilegios otorgados al rol al que han sido asignados.
También debe asegurarse de no tener ningún usuario preexistente sin una contraseña asignada o con un conjunto demasiado grande de privilegios. Dicha auditoría de seguridad debe realizarse de vez en cuando, asegurándose de que esté al tanto de los posibles riesgos de seguridad y pueda planificar cómo actuar en consecuencia.
Registro de auditoría
Si su base de datos viene con un registro de auditoría, tal como lo hace MariaDB, debería considerar usarlo para rastrear las acciones que están ocurriendo en la base de datos. El registro de auditoría le ayudará a lograrlo. Con él habilitado, podrá rastrear incluso los detalles, como qué usuario ejecutó qué consulta. Si usa ClusterControl, puede habilitar el registro de auditoría con solo un par de clics:
Para resumir este blog, hay un par de cosas que debe considerar al diseñar una implementación de MariaDB en el entorno de nube híbrida. Algunos de ellos están estrictamente relacionados con la forma en que se diseña el entorno, otros están bastante relacionados con el tipo de base de datos que usa y el hecho de que use la nube híbrida realmente no cambia mucho. Lo que es realmente importante es asegurarse de que su base de datos esté debidamente protegida:ese es el objetivo final, sin importar cuál sea el entorno.
