La seguridad es fundamental hoy en día en toda la TI. De vez en cuando escuchamos sobre ataques de ransomware o fugas de datos que tienen su origen en bases de datos o infraestructura de TI no protegidas. Quizás se pregunte:¿cuáles son las mejores prácticas en la arquitectura del entorno MySQL para que pueda sentirse seguro con sus datos? Si es así, este blog es para ti. Tenga en cuenta que no cubriremos el tema en su totalidad; esto encajaría más en un documento técnico que en un blog. Haremos todo lo posible para mencionar los aspectos más importantes de la seguridad de su base de datos MySQL. La idea detrás de este blog es que el lector sepa lo que no sabe y ayude a identificar los temas y las palabras clave para futuras investigaciones. Lo ilustraremos con capturas de pantalla de nuestro producto, ClusterControl, que viene con un amplio conjunto de funciones, incluidas algunas relacionadas con la seguridad de la base de datos.
Red
Primero que nada, tenemos que implementar MySQL en alguna parte. Ya sea una instancia independiente, principal:replicación asíncrona de réplica o una de las topologías de replicación síncrona más avanzadas, como Galera o InnoDB Cluster. No importa lo que sea, tiene que estar protegido a nivel de red. La base de datos contiene los datos que, con bastante frecuencia, son el activo más valioso de toda una organización.
Asegurando el acceso
Las instancias de bases de datos nunca deben ubicarse en la red pública. Los segmentos de red en los que se configuran las bases de datos deben ser accesibles solo desde un número limitado de otras redes. La regla general es:¿debería un nodo determinado poder acceder a la red de la base de datos? Si la respuesta es no, las redes deben separarse.
Por supuesto, todo depende de la configuración exacta, pero en los casos más comunes, donde tiene capas de aplicación, proxy, caché y base de datos, la configuración más típica sería que solo el proxy debería poder para acceder a la base de datos. Todas las demás entidades deben configurarse de manera que accedan a la base de datos solo a través de la capa de proxy. Este diseño es bueno en muchos sentidos. Además de la mayor seguridad, también ayuda a ocultar la complejidad del nivel de la base de datos de la aplicación.
La capa de proxy debe seguir la topología de la base de datos y debe manejar las fallas del nodo de la base de datos y los cambios de topología. La aplicación, que se conecta a la capa de proxy, siempre debe poder comunicarse con un nodo de base de datos en funcionamiento relevante para el tipo de solicitud. Lo mismo ocurre con la capa de caché. Se puede implementar en la capa de proxy; algunos proxies, como ProxySQL, permiten solicitudes de caché dentro del proxy, pero si se trata de una capa independiente creada, por ejemplo, Memcache o Redis, siempre debe llegar a la base de datos a través de la capa de proxy.
El otro tipo de nodos que puede necesitar tener acceso directo a la capa de la base de datos son los nodos de administración, los que utilizan los equipos operativos para administrar las bases de datos. La razón es simple:algunas de las tareas de mantenimiento pueden requerir acceso directo a las bases de datos. Podrían ser scripts de automatización de tareas, libros de jugadas de Ansible en toda la flota de bases de datos u otras tareas. En ese caso, obviamente, se deben implementar medidas de seguridad para garantizar que solo las personas que tienen acceso puedan iniciar sesión en dicho nodo de administración.
Otro posible tipo de nodos (aunque los nodos de administración también se pueden usar para eso) que pueden requerir acceso a la base de datos son los nodos involucrados en recopilar métricas y presentarlas a los usuarios; aquí estamos hablando de monitoreo. y actividades de alerta.
VPN
Para cualquier tipo de nivel de base de datos que abarque varios centros de datos, debe considerar usar VPN para conectarlos. Las conexiones abiertas y sin cifrar a través de la red WAN es algo que nunca debería suceder. Incluso configurar el cifrado SSL no es la mejor opción, ya que requeriría abrir el acceso entre el nivel de la base de datos y la WAN:las conexiones SSL entre los nodos de la base de datos requieren que puedan conectarse directamente. VPN resuelve este problema al agregar un intermediario que crea una forma segura de conectar segmentos de la red de nivel de base de datos.
La VPN también debería ser obligatoria para cualquier tipo de acceso de usuario a la red de la organización, ya que implementa una conectividad segura entre una estación de trabajo y la red de producción.
Cortafuegos
Por supuesto, mientras protegemos la red debemos considerar usar el firewall. En términos generales, cada nodo de la base de datos solo debe recibir conexiones de un conjunto definido de fuentes:nombres de host y puertos. Incluso los segmentos de red "requeridos" no deberían tener acceso completo a la red de la base de datos, sino solo a los puertos requeridos. Si el proxy solo necesita conectarse al puerto de la base de datos, entonces no hay motivo para que pueda acceder a ningún otro puerto en los nodos de la base de datos. Tenga en cuenta también que no debe utilizar los puertos predeterminados. Es, obviamente, seguridad por oscuridad:después de todo, el puerto está abierto en alguna parte, pero ayuda a lidiar con al menos algunas de las intrusiones de seguridad que usan scripts automatizados. No evitará que alguien que está decidido a obtener el acceso, pero puede ralentizarlo (cuando se combina con la detección de escaneo de puertos y medidas anti-escaneo) mientras evita que los ataques automáticos tengan éxito.
Seguridad de la base de datos
La red es la primera línea de defensa, existen otras medidas de seguridad y buenas prácticas que puede utilizar para mejorar aún más su seguridad. Algunos de ellos se pueden implementar en la propia base de datos.
Usuarios y anfitriones
Las propias bases de datos se pueden utilizar para implementar restricciones y control de acceso. Para empezar, puede implementar un control de acceso basado en host, evitando que los hosts que no sean la lista corta de nodos inicien sesión en la base de datos. Por supuesto, si usó un firewall para limitar el acceso, esto puede sonar como un duplicado, pero aún así es una buena idea limitar el acceso a la base de datos en sí; nunca se sabe cuándo, por accidente, se desactivará un firewall. En tal caso, todavía tiene una segunda capa de protección.
Lo que desea implementar aquí es una lista de usuarios de base de datos y hosts que pueden acceder a la base de datos. Lo más probable es que termine teniendo uno o más usuarios con acceso otorgado desde hosts ubicados en la capa de proxy. El control de acceso detallado que pueda tener depende del sistema de base de datos que tenga. MySQL, por ejemplo, no permite un control detallado sobre las máscaras de red, solo usa /32, /24, /16 o /8. En PostgreSQL, por otro lado, puede usar cualquier tipo de máscara de red.
Subvenciones
Si esto es lo que permite su base de datos, cada uno de los usuarios debe tener un conjunto definido de concesiones, lo que garantiza que los privilegios que se les asignan son los mínimos necesarios para que el usuario realice las acciones que debe realizar. . Los sistemas de bases de datos pueden tener diferentes conjuntos de privilegios y diferentes niveles de ellos. Por lo general, tenemos varios niveles de privilegios:global, que afecta a todo el servidor de la base de datos, nivel de esquema, un usuario dado puede tener diferentes privilegios asignados a diferentes esquemas. Puede tener privilegios en una tabla o incluso a nivel de columna. Como mencionamos antes, el objetivo es crear el conjunto mínimo de privilegios para cada usuario. Probablemente querrá tener al menos un usuario con privilegios altos; se usaría para administrar la base de datos. Dicho usuario debe estar estrictamente limitado en lo que respecta a la conectividad. No debería permitirse (y de hecho ninguno de los usuarios debería) conectarse desde ninguna ubicación; debería ser un host local o algún nodo de administración en particular, dedicado a realizar operaciones en la base de datos.
Administración de contraseñas
Cada usuario en la base de datos debe tener una contraseña definida. Esto es obvio. La contraseña debe almacenarse en forma de hash. Debe asegurarse de que para almacenar las contraseñas está utilizando el algoritmo hash más seguro que su base de datos tiene para ofrecer. Las contraseñas no deberían ser fáciles de adivinar ni deberían ser vulnerables al ataque del diccionario. Algunos sistemas de bases de datos, como MySQL, le permiten definir con precisión los requisitos que deben cumplir sus contraseñas para poder utilizarlas. Letras minúsculas y mayúsculas, números, caracteres especiales, longitud de la contraseña:todo es importante y si puede aplicar algunas políticas sobre la seguridad de la contraseña, debe hacerlo. Otro bit importante es la rotación de contraseñas. Las contraseñas no deben crearse de una vez por toda la vida útil de la base de datos, debe tener una política de rotación de contraseñas. Nuevamente, algunos de los sistemas de bases de datos pueden hacer cumplir esto por usted. El usuario administrativo puede crear nuevas cuentas de usuario con la rotación de contraseñas obligatoria. También puede hacer cumplir la rotación de contraseñas para un usuario determinado.
Registros de auditoría
Algunos de los sistemas de bases de datos ofrecen registros de auditoría; la idea es recopilar tanta información sobre la actividad en la base de datos como sea posible. ¿Quién y cuándo hizo qué? ¿Qué consulta ha sido ejecutada, por quién? ¿Quién intentó iniciar sesión pero falló? ¿De qué anfitrión? Idealmente, los registros que contienen dicha información se almacenarían fuera de los nodos de la base de datos. Puede transmitirlos a su servidor de registro central para su custodia, procesamiento posterior y mejores capacidades de búsqueda.
Seguridad SQL
Mencionamos usuarios y hosts, pero el ataque también puede ocurrir desde una fuente diferente. Si su aplicación no está protegida correctamente y la entrada no se valida correctamente, es posible que se enfrente a ataques que se originan en su sitio web. Estamos hablando aquí de inyección SQL. En tal caso, los firewalls no son realmente útiles dado que la consulta se originó en una fuente válida (su servidor web y luego el nodo proxy). Asignar concesiones en realidad puede ayudar a prevenir este tipo de ataque, pero no es una solución ideal; después de todo, su aplicación, en la mayoría de los casos, necesitará un usuario que pueda eliminar o modificar el contenido de la base de datos. Dicho usuario, cuando es explotado, puede usarse para hacer daño. Hay varias formas en las que puedes intentar contrarrestar la golosina.
Cortafuegos SQL
La forma más sencilla de hacerlo es implementando el firewall SQL. Se puede lograr en diferentes niveles y en diferentes lugares. Una de las opciones es usar balanceadores de carga para eso. Algunos de ellos vienen con esta funcionalidad al menos fácilmente alcanzable si aún no está implementada. La idea detrás de esto es crear una lista de consultas que ejecuta su aplicación y luego configurar su proxy para pasar solo este tipo de tráfico. No es ideal ya que tendrás que mantenerlo en el tiempo, agregando nuevas consultas y eliminando las antiguas que ya no se usan. Por otro lado, dicho conjunto de reglas evitará que cualquier consulta no autorizada llegue a la base de datos.
Detección de inyección SQL
Otra opción posible sería implementar la detección de inyección SQL en la capa de proxy. Hay un par de soluciones, ProxySQL entre otras, que se pueden configurar para intentar detectar la inyección de SQL en el tráfico que pasa a través de ellas. Por supuesto, todo se basa en heurística, por lo que puede generar falsos positivos, pero puede ser una buena adición al firewall de SQL.
En el pasado, analizamos cómo puede implementar el firewall de SQL y la detección de inyección de SQL mediante ProxySQL, un equilibrador de carga que se puede implementar desde ClusterControl:
https://severalnines.com/database-blog/how-protect-your-mysql-or-mariadb-database-sql-injection-part-one
https://severalnines.com/database-blog/how-protect-your-mysql-or-mariadb-database-sql-injection-part-two
Seguridad de datos
Finalmente, seguridad de datos. Hemos discutido hasta ahora cómo se puede fortalecer la base de datos, cómo limitar el acceso a ella y cómo prevenir diferentes tipos de ataques provenientes de la propia aplicación. Todavía deberíamos considerar la protección de los datos en sí. Esto puede tener varias capas. Seguridad física:si es el propietario del centro de datos, asegúrese de que esté correctamente bloqueado. Si utiliza proveedores de nube o ISP externos, asegúrese de que tengan los protocolos de seguridad adecuados cuando se trata de acceder al hardware. Entonces tenemos un servidor, VM o lo que sea que esté usando. Los datos se encuentran en el disco, almacenados localmente en el servidor. Los datos se transfieren entre la aplicación, el proxy y la base de datos. Los datos se transfieren entre los nodos de la base de datos por medio de la replicación. Los datos se almacenan fuera del sitio como copias de seguridad. Estos datos deben estar protegidos.
Copias de seguridad
Las copias de seguridad siempre deben cifrarse. La clave de cifrado debe mantenerse cuidadosamente y rotarse periódicamente.
Datos en tránsito
Los datos que se transfieren deben estar encriptados. Asegúrese de haber configurado su aplicación, capa de proxy y base de datos para usar SSL o TSL. Todos los medios de transferencia de datos entre los nodos de la base de datos también deben estar protegidos y cifrados. El objetivo es hacer que cualquier tipo de rastreo de red no tenga sentido.
Datos en reposo
Finalmente, los datos en sí, almacenados en el nodo de la base de datos. También debe estar encriptado. Hay un par de métodos que puede utilizar al abordar este tema. Primero, encriptación a nivel de host. El volumen en el que la base de datos tiene su directorio de datos se puede cifrar (y descifrar en el arranque). Las bases de datos también tienden a venir con capacidades de encriptación. Lo que se puede cifrar depende de la solución exacta y del tipo y versión de la base de datos, pero en algunos casos las opciones son bastante amplias. Cifrado de tablespace, cifrado de registros, a veces incluso cifrado de las estructuras en memoria. Si lo hace correctamente, acceder al nodo de la base de datos no será suficiente para acceder a los datos.
Conclusión
Como mencionamos antes, este blog no pretende ser una guía práctica para la seguridad de la base de datos, pero hemos abordado la mayoría de los aspectos que debe considerar al diseñar su entorno de base de datos y esperamos esta guía le resultará útil.
