No es ningún secreto que la información hace que el mundo gire actualmente. Si una empresa cuida su propiedad intelectual y cada empleado puede obtener fácilmente la información necesaria, la empresa puede esperar el crecimiento. Si hay caos en los datos, la empresa fracasará a pesar del espíritu de equipo.
En este artículo, vamos a explorar los conceptos básicos de seguridad de la base de datos y ejemplos de protección de la información en Oracle. De hecho, los fundamentos teóricos para proteger la información en la base de datos, que vamos a considerar en este artículo, también serán útiles para las personas que trabajan con otras bases de datos.
Permisos de acceso
En la mayoría de las empresas para las que trabajé, todos los administradores y desarrolladores tenían acceso completo a las bases de datos, y un empleado del departamento de TI era un dios y podía hacer lo que quisiera. ¿Por que sucede? Hay dos razones para esto:
- Mientras trabajan en un departamento, los empleados pueden reunirse durante 8 horas todos los días y hacerse amigos. ¿Cómo no pueden dar acceso? La amistad es una cosa, pero los negocios son los negocios.
- Otorgar algunos derechos de acceso o modificar alguna configuración puede requerir algunos privilegios. A veces, los administradores piensan que los programadores configuran mejor las configuraciones. Por lo tanto, proporcionan a los programadores derechos de acceso innecesarios. En cambio, los programadores no deben estar involucrados en la administración y no deben tener ningún derecho para esto.
En mi experiencia, el segundo problema es muy común, por lo que lo analizaremos en detalle.
Al desarrollar programas para bases de datos, los programadores conocen una contraseña de superusuario o simplemente tienen derechos de administrador de base de datos. Esto es innecesario y absolutamente inseguro. Solo el administrador de la base de datos debe tener todos los derechos. Incluso el jefe de departamento, el director y los mejores amigos pueden tener menos privilegios.
Por ejemplo, al desarrollar programas, basta con tener los derechos de propietario del esquema en la base de datos Oracle que almacena las tablas de trabajo. Estos derechos son suficientes para crear nuevas tablas, paquetes, índices y otros objetos, así como para otorgar derechos de acceso a los objetos del esquema a otros usuarios. No necesita los derechos del sistema para trabajar a tiempo completo.
Si no hay un administrador de base de datos a tiempo completo, es muy malo. Es mejor cuando hay alguien responsable del rendimiento, la optimización y la seguridad de la base de datos. Al menos, debe designar a un programador que será responsable de esto y tendrá derechos exclusivos.
Según las estadísticas, los empleados de la empresa causan la pérdida de datos con mayor frecuencia. Aún así, a pesar de este hecho, la mayoría de las empresas siguen ignorando este hilo y hasta en el metro se venden diferentes bases de datos almacenadas en discos de libre acceso.
Usuarios y roles
Hay dos tipos de objetos para otorgar derechos de acceso en las bases de datos:usuarios y roles. Los roles son algunos grupos que combinan usuarios que deben tener derechos similares. Por ejemplo, todos los contadores pueden requerir acceso a documentos financieros. Para evitar que otorgue derechos a cada contador, podemos combinarlos en un rol con el acceso necesario.
Como puede ver, el principio de los roles es similar al de los grupos en el sistema operativo Windows. Aún así, tiene algunas diferencias. No sin razón, los tres tipos de objetos, como usuarios, grupos y roles, se pueden implementar en la base de datos. Sin embargo, en la mayoría de las bases de datos solo se implementan usuarios y roles. Es necesario administrar y monitorear todos estos objetos para que cada usuario que obtenga los derechos otorgados por los roles pueda tener acceso a los datos que realmente se requieren para resolver las tareas. Es necesario utilizar los derechos de acceso como reglas para un cortafuegos. Con estos derechos, puede resolver el mismo problema:permitir que un usuario realice solo ciertas tareas y evitar posibles pérdidas o daños.
Con la ayuda de roles, es muy conveniente controlar el acceso, otorgar permisos o bloquear a todo el grupo de usuarios. Un rol se puede incluir en el otro, heredando así sus derechos de acceso. Por lo tanto, podemos crear una estructura jerárquica de derechos.
Todos los empleados con derechos de acceso a una base de datos corporativa pueden incluirse en un solo rol con los derechos mínimos. Ahora, si necesita privilegios adicionales, acceso a tablas particulares, deberá agregar un usuario a otros roles (si un grupo requiere el mismo acceso) o proporcionar una cuenta particular con los derechos.
En el programa, para controlar el acceso a las tablas, es posible verificar el resultado en busca de errores después de cada intento de abrir el conjunto de datos. Si se produce un error de acceso, el acceso a la tabla especificada se bloquea para un usuario. Por lo tanto, no hay necesidad de implementar los derechos de acceso a la aplicación cliente. Sin embargo, si desea implementar esto, no habrá ningún daño. Al menos, no veo nada de crítico en esto; parece tener el efecto contrario.
Auditoría de seguridad
Si cada usuario está trabajando con su propia cuenta en su base de datos, puede llamar a la variable de usuario para determinar el usuario actual, por ejemplo:
SELECT user from dual
Esta consulta devolverá un nombre de usuario, bajo el cual se abre la conexión con el servidor. Si varias personas pueden iniciar sesión con un nombre, esta consulta devolverá el mismo nombre para ambos y sería inútil para la auditoría. Especialmente, si el control de bloqueo se produce a nivel de servidor.
Si varios usuarios pueden iniciar sesión con el mismo nombre de usuario, es complicado, pero aún posible, identificar quién inició sesión en la cuenta. La siguiente consulta permite obtener la información detallada de la sesión:
select s.user#, s.username, s.osuser, s.terminal, s.program from sys.v_$session s WHERE username=user
Como puede ver, la consulta devolvió el nombre de usuario, conectado a la base de datos, un nombre en el sistema operativo, un nombre de usuario de terminal y un programa.
Aquí puede acceder a la vista v_$session desde el esquema del sistema sys. Esta vista devuelve información sobre las conexiones al servidor. En la cláusula WHERE, limitamos la salida solo al usuario actual. Como resultado, la consulta devuelve el ID de usuario, el nombre, el nombre en el sistema operativo, la terminal y el programa desde el que se estableció la conexión.
Cuando conoce un nombre de usuario y un nombre de terminal, puede identificar a un usuario con seguridad. Para saber a qué roles se agregó el usuario actual, puede ejecutar la siguiente consulta:
SELECT GRANTED_ROLE FROM dba_role_privs WHERE grantee=user
Seguridad de la cuenta
No diremos que no debería haber contraseñas predeterminadas. Algunas bases de datos, por ejemplo MySQL, se equivocan cuando crean una contraseña de sistema simple y conocida después de la instalación. Tampoco diremos que la contraseña debe ser complicada. Esta regla se aplica a todas las áreas de TI y debe ser conocida incluso por un usuario novato. Vamos a hablar de problemas con la base de datos.
En mi experiencia, al desarrollar programas corporativos, los desarrolladores usan la misma cuenta para acceder a una base de datos. Los parámetros de esta cuenta se registran directamente en el programa, mientras que el acceso a módulos particulares, incluidos contabilidad, almacén, departamento de personal, etc., se implementa de manera programática. Por un lado, este método es conveniente, porque el programa puede conectarse a la base de datos con derechos de administrador y no tendrá que ocuparse de los roles y derechos de acceso a las tablas. Por otro lado, este método está lejos de ser seguro. El nivel de usuarios está creciendo y los amigos de los empleados de su empresa pueden educarse en el campo de la seguridad y la piratería. Después de conocer el nombre y la contraseña, bajo los cuales el programa se conecta a la base de datos, un usuario común puede obtener más oportunidades de las que deseaba.
El lenguaje SQL no es un lenguaje secreto y complicado. Hay muchos programas con los que puede ver fácilmente cualquier dato en la base de datos. Con el nombre de usuario y la contraseña, cualquiera puede robar todos tus datos. Así, se venderá en cualquier puesto que venda discos.
Un nombre de usuario y una contraseña nunca deben almacenarse en el programa. El acceso al programa también debe ser limitado e imposible para terceros. Es bastante lógico combinar ambos inicios de sesión en uno. Es necesario crear una cuenta separada en el servidor de la base de datos con los derechos mínimos necesarios para cada usuario de la organización. Estos nombres y contraseñas deben usarse al iniciar sesión en el programa. Puede usar una lógica común y muy efectiva:si puede iniciar sesión en la base de datos con los datos ingresados, el acceso está permitido; si no, debe abortar el programa. Este proceso es simple y efectivo porque utilizamos la autorización de la base de datos.
Para verificar que los usuarios no trabajen simultáneamente desde dos computadoras diferentes bajo el mismo nombre, puede ejecutar la siguiente consulta:
select s.username, s.terminal, count(*) from sys.v_$session s WHERE username=user HAVING count(*)>1 GROUP BY s.username, s.terminal
De hecho, no debe devolver ningún registro.
Visualizaciones
Las vistas son una forma muy conveniente de desconectarse de la estructura de datos y crear un nivel adicional de protección al mismo tiempo. Es cierto que las vistas tienen un impacto negativo en la productividad, sin embargo, tienen un impacto positivo en la seguridad. Podemos otorgar sus propios derechos de acceso, mientras que las tablas de las que se recuperan los datos pueden permanecer inaccesibles para esta cuenta.
¿Cuándo es mejor usar vistas? Primero, definamos cuáles son sus desventajas. Una vista es una instrucción SELECT para recuperar datos. Puede acceder tanto a una como a varias mesas. Si solo selecciona los datos de la vista, no habrá pérdida de rendimiento. Sin embargo, podemos usar vistas en otras consultas para seleccionar datos y referirnos a ellos como a las tablas. Por ejemplo:
SELECT list of fields FROM view, table_1, table_2 WHERE some parameters
En este caso, la consulta obtiene datos de la vista y de dos tablas. Además, podemos ver una relación entre todos los objetos y se puede establecer una condición adicional.
Ahora, veamos la consulta como la ve el optimizador de base de datos:
SELECT list of fields FROM (SELECT ...), table1, table2 WHERE some parameters
En este caso, reemplacé la vista con una instrucción SELECT abstracta entre paréntesis de la que consta la vista. Resulta que el servidor ve una consulta con una subconsulta. Si la subconsulta devuelve datos dinámicos, en lugar de un valor estático, esta selección de datos funcionará más lentamente que si escribimos la misma consulta sin la subconsulta.
Seguridad de datos
Nunca debe otorgar acceso completo a los objetos sin una necesidad especial. Siempre empiezo a proporcionar derechos solo para permitir la selección de datos con la instrucción SELECT. Si el usuario realmente necesita insertar nuevos registros y no puede realizar las tareas que se le han asignado, en este caso, agregue el permiso en la instrucción INSERT de la tabla especificada.
Las operaciones más peligrosas para los datos son la modificación y la eliminación, es decir, ACTUALIZAR y ELIMINAR, respectivamente. Debe otorgar estos derechos con cuidado. Asegúrese de que los datos se puedan modificar o eliminar. Solo en este caso, seleccione los derechos apropiados. Algunas tablas se amplían solo por naturaleza.
Es necesario estar seguro de que los datos se verán afectados con frecuencia. Por ejemplo, la tabla de empleados se puede ampliar y modificar, pero nunca se debe eliminar un solo registro. La eliminación puede influir en los antecedentes del trabajo, los informes y la integridad de los datos de los empleados. El caso en que un oficial de recursos humanos agrega accidentalmente un registro adicional y quiere eliminarlo todavía es posible. Sin embargo, estos casos son raros y el administrador de la base de datos puede corregir el error. Entendemos que nadie quiere sobrecargarse de trabajo y es más fácil otorgar un permiso, sin embargo, la seguridad es más valiosa.
La concesión de derechos se realiza mediante el operador GRANT. En general, se ve así:
OTORGAR qué otorgar derechos a ON objetos A usuarios o roles
Por ejemplo, la siguiente consulta otorga el derecho de insertar y ver la tabla TestTable al Usuario1:
GRANT Select, Insert ON TestTable TO User1
Claves foráneas
Muchos usuarios tienen miedo de las claves externas porque, por lo general, no permiten eliminar datos cuando hay una combinación externa. El problema se puede resolver fácilmente si se establece una eliminación en cascada. Sin embargo, a la mayoría de los especialistas no les gusta esta posibilidad. Una acción ridícula puede corromper datos muy importantes sin ninguna solicitud de confirmación. Los datos vinculados deben eliminarse explícitamente y solo si el usuario ha confirmado conscientemente que los datos pueden eliminarse.
No tengas miedo de las claves foráneas. Nos brindan una forma conveniente de controlar la integridad de los datos desde el servidor de la base de datos, por lo tanto, esta es una seguridad que nunca está de más. El hecho de que pueda haber problemas con la eliminación es solo un beneficio. Es mejor no borrar los datos que perderlos para siempre. La clave externa junto con el índice no reduce el rendimiento. Esto es solo una pequeña verificación al eliminar los datos o modificar el campo clave al que se conectan los datos en diferentes tablas.
Copia de seguridad
La copia de seguridad también es uno de los factores de seguridad que ignoramos ante la primera pérdida de datos. Sin embargo, personalmente, lo habría incluido entre los principales. La pérdida de datos puede ser causada no solo por piratas informáticos y usuarios incapaces, sino también por fallas en el funcionamiento del equipo. Las fallas en el equipo pueden provocar la pérdida de la base de datos, cuya restauración puede demorar horas o incluso días.
Es necesario desarrollar de antemano la política de copias de seguridad más eficaz. ¿Qué se quiere decir con ello? El tiempo de inactividad causado por la pérdida de datos y hasta el momento de la restauración de la capacidad de trabajo debe ser mínimo. La pérdida de datos también debe ser mínima y la copia de seguridad no debe afectar el trabajo del usuario. Si hay dinero y oportunidades, es mejor usar sistemas como RAID, clúster o incluso replicación de datos.
La copia de seguridad y la recuperación son un tema aparte e interesante. No pudimos tocarlo aquí, pero no lo consideraremos en detalle.
Resumen
Hemos considerado los conceptos básicos de seguridad, en particular para Oracle. No olvide que la protección que brinda la base de datos es de un solo nivel, mientras que la protección debe ser multinivel. Para dormir un poco con la mente despejada, es necesario implementar todas las funciones de seguridad en la red, servidores y todas las computadoras, incluidos antivirus, anti-spyware, VPN, IDS, etc. Cuantos más niveles de protección hay, más difícil será superarlos.
Debe existir una política y un control de seguridad claros. Si un empleado se va, su cuenta se elimina. Si tiene usuarios que trabajan con la misma contraseña o que usan una contraseña de grupo para realizar alguna tarea, todas estas contraseñas deben cambiarse. Por ejemplo, si un administrador se va y todos los administradores usan la misma cuenta, debe cambiar la contraseña.
La seguridad es necesaria. Debe protegerse no solo de los piratas informáticos sino también de los usuarios "novatos", que pueden corromper los datos por su inexperiencia. Una buena política de seguridad ayuda a prevenir tales casos y esta posibilidad no se puede descartar. Es mejor brindar la capacidad de proteger los datos de la inexperiencia por adelantado que perder mucho tiempo para restaurar los datos y obtener un tiempo de inactividad innecesario.
Leer también:
Configuración de permisos de acceso a la base de datos
