Los datos son el nuevo oro para las grandes empresas y organizaciones. Se consideran el elemento vital de la mayoría de las empresas modernas y existe una bonanza de oportunidades para vender o comercializar a la gran audiencia de Internet. Para las grandes empresas de comercio electrónico o redes sociales, los datos impulsan su capacidad para generar grandes ingresos y ganancias, para lo cual los datos están fuertemente protegidos y cuentan con una protección sofisticada contra ataques maliciosos e intrusos en línea.
Entonces, datos como el oro, su valioso estado comienza una vez que se procesan. Su valor bruto está lleno de desorden, como si fuera un bocado gigantesco sin clasificar. Una vez que se estructura su esencia, el valor de los datos se multiplica. Imagínese, si tiene un sitio educativo que permite a los usuarios pagar. Una vez que tenga toneladas de conferencias y módulos que su público objetivo pueda aprender, desarrollar y obtener un grado de productividad, habrá captado el sabor de la oportunidad y el éxito, ya que tiene la posibilidad de regular las tarifas antes de que puedan obtener los datos estructurados que desean. . Aunque esto suena como el sueño de éxito de todos, cuando se trata de big data y su esencia subyacente, existen muchas complicaciones para procesarlo y una preocupación importante son las amenazas a su base de datos.
Las amenazas de bases de datos en general tienen numerosos y extensos sectores para mirar y examinar. Aunque, las causas más comunes son el robo de datos y las filtraciones de datos. Otra amenaza común son los privilegios extensos o el acceso a bases de datos incorrectamente asignadas y/o proporcionadas a un usuario. La protección de todo el host del servidor es una preocupación para cualquiera que administre una base de datos. Reforzó su seguridad y se ocupó de todos los tipos de ataques aplicables, como espionaje, alteración, reproducción y denegación de servicio (DDoS), no solo para la base de datos, sino también para toda su pila subyacente que tiene acceso o que interactúa con su almacenamiento de datos.
En este blog, discutiremos el alcance de la necesidad de por qué necesita comprender y tener privilegios de acceso a la base de datos.
Peligros de privilegios de acceso incorrectos
Inevitablemente tenemos que compartir o al menos crear un usuario ya sea a nivel físico como técnico. Mientras que proporcionar acceso a otra persona significa que confías en la persona. Esto también significa que la persona autorizada debe comprender el peligro y el riesgo de compartir el acceso y los datos del mundo exterior.
El punto más importante para asegurar sus privilegios de acceso es el nivel de comprensión de la seguridad entre sus ingenieros, como el administrador de la base de datos, el ingeniero de seguridad o el administrador del servidor. Si la comprensión es deficiente o carece de conocimiento y experiencia, especialmente de las vulnerabilidades y exposiciones más actualizadas, puede ser un problema para la organización o la empresa.
Hay cosas básicas que deben entenderse y tenerse en cuenta para que tenga un mínimo o al menos no pueda ser intruso o expuesto. De lo contrario, esto podría poner en peligro sus datos del mundo exterior o al menos de la persona o personas equivocadas. Posiblemente para robar sus datos y usarlos por su propio bien para obtener ganancias financieras o pueden rescatarlos y pedir dinero a cambio de su mala implementación de seguridad.
En esta sección, veamos algunas causas comunes de estas amenazas de seguridad.
Compartir el privilegio de acceso raíz
Para un entorno local, un caso habitual de violación de la base de datos se basa principalmente en el peligro de dar acceso a la raíz, ya sea en el nivel del sistema operativo o en el nivel del software de la base de datos. Hay casos en los que la contraseña de root se distribuye y se expone a varias personas, lo que debería limitarse solo a los administradores que trabajan únicamente en el sistema. Esto podría ocurrir debido a la falta de una lista de verificación o medidas de seguridad en el protocolo antes de implementar los privilegios de acceso. Tener una lista de verificación de seguridad ayuda a realizar un seguimiento de cualquier acceso y privilegio que pueda exponer el riesgo y el peligro, especialmente cuando un usuario específico del sistema operativo está expuesto a un intruso. La lista de verificación también lo ayuda a discutir o tener una descripción general de las medidas de seguridad implementadas e implementadas como un protocolo para su organización.
Por ejemplo, un usuario que tiene acceso de root puede causar mucho daño, como eliminar todos sus datos de su unidad de almacenamiento físico, restablecer la contraseña de root, crear su propio usuario/contraseña que parece como un usuario legítimo (se puede usar durante mucho tiempo para recopilar datos a menos que se detecte temprano), sudo a un usuario de sistema operativo diferente, como el usuario de postgres, y muchas más cosas aterradoras para que disfrute el intruso.
Si está utilizando MongoDB, un usuario con acceso raíz puede iniciar sesión en su servidor de base de datos. Siempre que el intruso pueda ubicar su /etc/mongod.conf o su archivo de configuración mongodb y ubicar la ruta de su clave, es fácil iniciar sesión. Por ejemplo, usar este comando le permite iniciar sesión,
[[email protected] ~]# mongo -u __system -p "$(tr -d '\011-\015\040' < /etc/mongo-cluster.key)" --authenticationDatabase local --eval "db.adminCommand( { listDatabases: 1, nameOnly:1 } )"
Considere una configuración de instalación normal de MySQL, un acceso de raíz se puede dejar sin una contraseña para el acceso localhost. Es fácil obtener acceso una vez que eres root. El acceso a archivos como $HOME/.my.cnf o ver el contenido de /etc/my.cnf lo llevará a obtener acceso fácilmente.
Se recomienda enfáticamente limitar solo o solo otorgar su acceso raíz a la menor cantidad de personas que trabajan directamente con el servidor para actualizar los paquetes, las actualizaciones de seguridad y aplicar los parches requeridos por el equipo de desarrollo.
Uso correcto de sudoers
El software de base de datos de código abierto convencional como PostgreSQL, MySQL/MariaDB, MongoDB requiere la creación de un usuario de sistema operativo específico. El usuario del sistema operativo requiere un rol específico limitado para permitir la gestión de sus capacidades dentro de la funcionalidad de la base de datos. Es necesario configurar los permisos de lectura y escritura adecuados para la ruta del dispositivo de almacenamiento subyacente. Sin embargo, hay casos en los que algunos que utilizan estos usuarios específicos para el software de la base de datos tienen privilegios sudo que también pueden acceder al usuario designado únicamente para el acceso a la base de datos. Los privilegios de usuario en el sistema operativo deben limitarse y es mejor limitar su acceso según el rol. Por ejemplo, para Percona Server CVE-2016-6664, aunque se ha solucionado, este tipo de vulnerabilidad es un ejemplo de un posible ataque de un usuario específico que tiene acceso a la cuenta de MySQL y obtiene acceso de root. Se debe revisar a los usuarios de Sudo y hacerles comprender que el rol solo se limita a realizar un trabajo específico.
Habilitar el sistema de auditoría de Linux, como auditd, puede ayudar a mejorar la seguridad, ya que aumenta los privilegios de acceso pasados por alto en el nivel del sistema operativo que podrían generar vulnerabilidades de seguridad en su base de datos. SELinux y AppArmor son buenos ejemplos de módulos de seguridad para su entorno Linux que alojan su sistema de base de datos para ayudar a mejorar su seguridad contra intrusos o infracciones que podrían poner en peligro sus datos.
Concesión de privilegios de acceso a la base de datos
Las principales bases de datos de código abierto ofrecen una lista granular de privilegios que se pueden personalizar para asignarse solo a una acción específica para un usuario específico. Esta es una forma amplia de ayudar a los administradores de bases de datos a tener una separación de datos y una acción de destino seguras en función de privilegios específicos.
Privilegios de acceso comunes
Sus privilegios más utilizados se basarán en estas tres categorías:
-
Capaz de leer/buscar como SELECCIONAR, MOSTRAR VISTA, ENCONTRAR
-
Capaz de Insertar/Actualizar/Eliminar como INSERTAR, ACTUALIZAR, ELIMINAR, ELIMINAR
-
Capaz de realizar acciones administrativas como CREAR USUARIO, CREAR ROL, ALTERAR, REPLICAR, ELIMINAR USUARIO/TABLAS/ SCHEMA's, operaciones de eliminación, etc.
Estas categorías se pueden extender a privilegios más refinados según su lista de verificación de seguridad. Es bueno definir un usuario específico que se creará con privilegios específicos para una tarea específica. Por ejemplo, una aplicación puede tener múltiples usuarios con sus propios privilegios designados asignados. Aunque la aplicación puede ser compleja con este tipo de implementación. Hay casos en los que la conectividad por usuario puede consumir muchos recursos, como el uso de ORM como Hibernate, por ejemplo. Por otro lado, depende del diseño arquitectónico de su aplicación. El propósito de una base por usuario en una aplicación puede ayudar a mantener un privilegio de acceso a la base de datos más refinado y evitar dañar sus datos por eliminaciones no deseadas, actualizaciones o una inyección SQL que ataca su base de datos.
En la mayoría de los casos, una aplicación utiliza un usuario para conectarse a la base de datos, que solo se limita a sus acciones específicas para que se ejecute la aplicación. Es mejor que diseñe el privilegio de usuario de su aplicación para que solo tenga acceso de lectura y escritura. Mientras que si se requieren acciones administrativas, un script, demonio o módulo específico en el acceso a su aplicación debe estar separado de los usuarios normales.-.
Se debe evitar el acceso a la base de datos
PostgreSQL y MySQL/MariaDB tienen esta opción para otorgar a un usuario TODOS los privilegios. Para PostgreSQL, también es mejor tener su usuario con NOSUPERUSER. Si es posible, esto debe evitarse a toda costa. Este privilegio puede realizar la mayoría de las acciones que potencialmente pueden destruir o dañar sus datos valiosos. Puede usar TODOS los privilegios para su administrador o acceso de raíz, pero solo está limitado a los usuarios que requieren superprivilegios para realizar tareas administrativas y administrar los datos.
Acceso por tabla o por esquema
Es una buena práctica proporcionar acceso a un usuario solo para las tablas requeridas. . Entonces, incluso si el usuario tiene algunos privilegios administrativos, cualquier daño es solo para un conjunto limitado de tablas. O puede establecer en un esquema de todo; proporcionar acceso a una tabla limitada proporciona un tipo granular de privilegios y lo ayuda a mantener sus datos fuera de peligro.
Acceso limitado solo al host
Conectarse a través de su dirección IP de recursos ayuda a limitar el acceso a sus datos. Evite usar '%' de modo que en MySQL, por ejemplo,
GRANT SELECT, INSERT, DELETE ON mydb TO [email protected]'%' IDENTIFIED BY 'password';El alcance del daño está expuesto a cualquier host al que conectarse y eso no es lo que quería que sucediera. Impone vulnerabilidad y el desafío de entrometerse en su base de datos es muy bajo.
Para PostgreSQL, asegúrese de haber configurado su pg_hba.conf y el usuario en su límite específico de host solamente. Esto también se aplica a MongoDB, para lo cual puede establecerlo en su archivo de configuración de MongoDB o en /etc/mongodb.conf. En MongoDB, puede jugar con las Restricciones de autenticación y configurar el origen del cliente o la dirección del servidor respectivamente, pero solo para lo que requiere que el cliente o usuario se conecte o sea validado.
Control de acceso basado en roles
El control de acceso basado en roles (RBAC) en las bases de datos proporciona una manera conveniente de administrar el usuario o una manera fácil de agrupar a un usuario con su privilegio designado vinculado a una lista de usuarios o grupo de usuarios.
Aunque debe tener en cuenta que los roles se manejan de manera diferente en cualquier base de datos de código abierto. Por ejemplo, MySQL definió los roles de la siguiente manera,
Un rol de MySQL es una colección de privilegios con nombre. Al igual que las cuentas de usuario, los roles pueden tener privilegios concedidos y revocados.
A una cuenta de usuario se le pueden otorgar roles, lo que otorga a la cuenta los privilegios asociados con cada rol. Esto permite la asignación de conjuntos de privilegios a las cuentas y proporciona una alternativa conveniente para otorgar privilegios individuales, tanto para conceptualizar las asignaciones de privilegios deseadas como para implementarlas.
MongoDB define el rol con RBAC como,
MongoDB emplea el control de acceso basado en roles (RBAC) para controlar el acceso a un sistema MongoDB. A un usuario se le otorgan uno o más roles que determinan el acceso del usuario a los recursos y operaciones de la base de datos. Fuera de las asignaciones de roles, el usuario no tiene acceso al sistema.
Mientras que en PostgreSQL,
PostgreSQL administra los permisos de acceso a la base de datos usando el concepto de roles. Una función se puede considerar como un usuario de la base de datos o como un grupo de usuarios de la base de datos, según cómo esté configurada la función. Los roles pueden poseer objetos de base de datos (por ejemplo, tablas y funciones) y pueden asignar privilegios sobre esos objetos a otros roles para controlar quién tiene acceso a qué objetos. Además, es posible otorgar membresía en un rol a otro rol, lo que permite que el rol de miembro use los privilegios asignados a otro rol.
El concepto de roles subsume los conceptos de “usuarios” y “grupos”. En las versiones de PostgreSQL anteriores a la 8.1, los usuarios y los grupos eran distintos tipos de entidades, pero ahora solo hay roles. Cualquier rol puede actuar como un usuario, un grupo o ambos.
Aunque estas bases de datos implementan los roles específicos de su uso, comparten el concepto de asignar roles al usuario para asignar privilegios convenientemente. El uso de roles permite a los administradores de bases de datos gestionar los usuarios necesarios para iniciar sesión o acceder a la base de datos.
Imagínese si tiene una lista de usuarios que tiene que administrar o una lista de usuarios que puede eliminar o revocar cuando ya no los necesite. En algunos casos específicos, si una determinada tarea necesita trabajo, los administradores de la base de datos pueden crear usuarios con funciones ya establecidas. Estos usuarios creados pueden asignarse a un rol específico por un período corto y luego revocarse una vez que no sea necesario.
Las auditorías también ayudan a segregar a los usuarios que tienen sospechas de vulnerabilidades o exposición de datos, por lo que en ese caso, ayuda a administrar a los usuarios con roles muy fácilmente.
Sistema de gestión de usuarios
Si la seguridad de sus datos se maneja e implementa de manera adecuada, le allana el camino hacia el éxito. Aunque no existe una solución perfecta, ya que las vulnerabilidades y las intrusiones también evolucionan siempre. Es como un gusano que intenta acechar todo el tiempo hasta que puede alcanzar su objetivo de violar su seguridad y obtener acceso a sus datos. Sin las herramientas adecuadas, como sistemas de alerta o avisos de inseguridades y vulnerabilidades, sería difícil proteger sus datos.
ClusterControl lo ayuda a administrar sus usuarios y verificar o verificar los privilegios de sus usuarios desde los balanceadores de carga hasta los usuarios de la base de datos principal. También ofrece asesores y alertas para que te avise de posibles vulnerabilidades o intrusiones.
Por ejemplo, el uso de MySQL/MariaDB con un ProxySQL por adelantado incluye funciones de importación y adición de usuarios. Para importar usuarios, recopila la lista de usuarios que están presentes en su clúster MySQL/MariaDB actual y le ofrece revisar sus privilegios actuales. Véase más abajo,
También en este caso, un usuario de ProxySQL puede desactivarse rápidamente si dicha vulnerabilidad ha sido conocido por el usuario específico.
ClusterControl también le ofrece administrar usuarios directamente desde su base de datos, como MySQL/MariaDB o PostgreSQL. Para MySQL/MariaDB, puede ir a
Para PostgreSQL,
Con ClusterControl, puede personalizar sus alertas utilizando los asesores. Los asesores son entidades basadas en secuencias de comandos que se pueden modificar. Por ejemplo, esto está en un clúster de MySQL/MariaDB como se muestra a continuación, al que se puede acceder a través de
Al hacer clic en el botón Editar, puede personalizar cómo reaccionaría ClusterControl en caso de que encuentre usuarios con cualquier host o '%" o un usuario sin contraseña. Vea cómo se muestra el script una vez que presiona el Botón editar.
Una vez que ClusterControl descubra que alguno de estos asesores se activó, se mostrará una alerta y también se enviará al correo electrónico que haya configurado o si se integran notificaciones de terceros, se le notificará allí también.
Conclusión
El privilegio de acceso a la base de datos es uno de los principales objetivos de preocupación por las violaciones e intrusiones de datos. Si el usuario de su base de datos está expuesto o si hubo una amenaza importante para la versión actual de la base de datos que no estaba parcheada, las posibilidades de ser pirateado o ser blanco de ransomware y robo son muy altas. Comprender los privilegios de acceso y establecer los límites correctos lo ayuda a mitigar los peligros de exponer sus datos valiosos.
