La seguridad del servidor depende principalmente de qué tan correctamente puede configurar los permisos de acceso en los objetos. Proporcionar a un usuario permisos excesivos puede causar muchos problemas. No, un usuario no utilizará sus errores. En cambio, cualquier hacker o yo haremos esto. En este caso, puedes olvidarte de tus tablas con datos o de toda la base de datos.
Por alguna razón, la seguridad de la base de datos es la protección del exterior, como un hacker. Sin embargo, esto sucede muy pocas veces. Soy programador en una gran empresa y un administrador ni siquiera piensa en proteger los puertos del servidor, donde todo está abierto. Hay un montón de bases de datos, programas e incluso un servidor FTP en un solo servidor y nunca ha sido pirateado en los últimos 5 años. Afortunadamente, persuadí al administrador para que implementara el servidor WEB en un hardware separado. De lo contrario, si alguien supiera la dirección IP de nuestro servidor principal, cualquier holgazán podría piratearlo. Ni la base de datos ni Windows han sido parcheados durante varios años.
Sin embargo, los problemas internos surgen todos los días debido a una política de seguridad incorrecta. Todos los usuarios inician sesión con derechos de administrador y pueden crear lo que quieran. Este es un verdadero problema porque los permisos excesivos permiten a los holgazanes mostrar su completo analfabetismo. Por lo tanto, consideraremos la seguridad independientemente de dónde provenga la amenaza:de un hacker o de un usuario.
En este artículo, vamos a considerar todos los conceptos básicos necesarios de protección de seguridad tanto de piratas informáticos como de usuarios. Elegí MS SQL Server como ejemplo porque contiene todo lo disponible en otras bases de datos (Oracle, MySQL, etc.) y tiene capacidades adicionales de administración de seguridad. Alguien podría pensar que esto hace que la EM sea más pronunciada. Sin embargo, a veces, las funciones adicionales pueden ser excesivas y causar problemas.
Funciones de servidor
En Windows y otros sistemas operativos, existen grupos y usuarios para administrar los permisos. Podemos combinar usuarios en un grupo y otorgarles derechos a todos a la vez, lo cual es mucho más fácil que asignar derechos a cada usuario individualmente. A estos efectos, en las bases de datos, existe el concepto “rol”.
Suponga que 100 usuarios deben tener permisos para leer datos de una tabla específica. Proporcionar a cada usuario este permiso es una molestia. Es mucho más sencillo crear un rol al que se le permita leer y luego agregarle todos los usuarios necesarios. El resultado es similar a la agrupación.
En SQL Server, hay dos tipos de roles:servidor y base de datos. Los roles del servidor están predefinidos y no se pueden cambiar.
Abra la rama de roles de seguridad/servidor en Enterprise Manager para que pueda ver una lista de los roles disponibles en la parte derecha de la ventana. La descripción define lo que el usuario puede hacer con el rol correspondiente.
Roles de servidor en MS SQL Server y la ventana del administrador de roles
Para agregar un usuario existente a un rol, haga doble clic en la fila del rol. En la ventana que aparece, puede agregar usuarios al rol o eliminarlos. La pestaña Permiso describe en detalle lo que cada usuario puede hacer.
Usuarios
Para administrar usuarios, abra la rama Seguridad/Inicios de sesión en Enterprise Manager. En la parte derecha, verá una lista de todos los usuarios del servidor. De forma predeterminada, el acceso se concede a los administradores de dominio y a las cuentas de inicio de sesión integradas, como sa.
Para agregar un nuevo usuario, haga clic derecho en cualquier parte de la parte derecha vacía de la ventana y seleccione Nuevo inicio de sesión en el menú que aparece. En la parte superior de la ventana, seleccione un nombre de usuario. Si necesita elegir un dominio existente o un usuario de computadora, haga clic en el botón (...) a la derecha del campo de entrada y verá el cuadro de búsqueda de usuario en el dominio.
Agregar un nuevo usuario
A continuación, puede seleccionar el tipo de autenticación:Windows o SQL Server. Si selecciona Windows, no necesita especificar una contraseña porque el servidor la obtendrá del sistema. Sin embargo, puede alternar Otorgar acceso (permitir acceso) o Denegar acceso (prohibir). En este último caso, el usuario quedará registrado en la base de datos, pero no podrá conectarse – está prohibido.
Si selecciona la autenticación de SQL Server, deberá establecer una contraseña porque, en este caso, se almacenará en las tablas del sistema del servidor de la base de datos. Tenga en cuenta que incluso si solo se especifica la autenticación de Windows en la configuración del servidor, puede crear registros del servidor SQL, pero no podrá iniciar sesión en el sistema con estos registros.
En la pestaña Funciones del servidor, puede especificar qué función del servidor se otorgará a un usuario. Por lo tanto, incluso en la etapa de creación, puede agregar usuarios a los roles necesarios.
Acceso de usuarios a bases de datos
En la pestaña Acceso a la base de datos, especifique las bases de datos con las que puede trabajar el usuario. Aquí, la ventana se divide en dos partes:en la mitad superior, puede seleccionar la base de datos a la que se permite el acceso, y en la lista inferior, puede seleccionar el rol de la base de datos. Este rol en la base de datos definirá los permisos de usuario. Se pueden otorgar varios roles a un usuario.
Cree una cuenta qq, que tendrá acceso a la base de datos Northwind. Esta es una base de datos de prueba estándar creada al implementar el servidor.
Guarde los cambios.
Ahora, abra la rama Bases de datos/Northwind/Usuarios y vea la lista de usuarios que tienen permiso para acceder a la base de datos seleccionada. Tenga en cuenta que aquí está la cuenta qq. No existe cuenta en otras bases de datos porque está prohibido el acceso a ellas para nuestro nuevo usuario.
Roles de la base de datos
Cada base de datos puede tener sus propios roles, que definen los permisos de acceso a los objetos. A muchos administradores no les gusta molestarse con estos permisos. Por lo tanto, instalan el público predeterminado incorporado, que permite casi todo. Si faltan permisos para la función pública, simplemente agregue un usuario a la función del servidor Administrador del sistema. En este caso, la base de datos se vuelve vulnerable.
Cada usuario debe contar con sus propios y necesarios permisos. Lo que no está permitido debe estar prohibido. Los roles que ya existen en el servidor no deben usarse porque sus permisos están abiertos a todos. Se recomienda incluso eliminarlos todos, especialmente el público.
Crear un rol
Para crear una nueva función de base de datos, haga clic con el botón derecho en la rama Bases de datos/Nombre de base de datos/Funciones. En el menú que aparece, seleccione Nuevo rol de base de datos. Se abre la ventana Propiedades de la función de la base de datos:nueva función. En la parte superior de la ventana, escriba el nombre del rol.
Por ejemplo, queremos crear un rol para contadores. Para ello, escriba Buh en el campo Nombre.
Crear un rol de base de datos
A continuación, seleccione un tipo de rol, por ejemplo, uno predeterminado estándar. En el centro de la ventana, hay una lista de usuarios que se agregarán al rol. Hasta ahora, la lista está vacía. Sin embargo, si hacemos clic en Agregar, agregaremos usuarios, por ejemplo, a la cuenta qq creada anteriormente. No hay nada más que hacer en la etapa de creación de un rol. Guarde los cambios haciendo clic en Aceptar.
Permisos de acceso
Ahora, vamos a ver cómo podemos establecer permisos. Haga doble clic en el rol Buh creado para abrir la ventana de edición. Tenga en cuenta que el botón Permiso ya está disponible. Solo cuando el rol está registrado en la base de datos, podemos cambiar sus derechos. Haga clic en este botón para abrir la ventana Propiedades del rol de la base de datos.
Configuración de permisos de acceso para roles
En la parte superior de la ventana, hay una lista de roles de base de datos para que pueda cambiar rápidamente entre ellos. Ahora, el rol Buh está seleccionado. En el centro de la ventana, hay una gran cuadrícula con las siguientes columnas:
- Objeto:nombres de objetos;
- Propietario:propietario de un objeto;
- SELECT:permiso para ver datos o ejecutar la instrucción SELECT. Está disponible solo para tablas y vistas;
- INSERT:permiso para agregar datos o ejecutar la declaración INSERT. Está disponible solo para tablas y vistas;
- ACTUALIZAR:permiso para modificar datos o ejecutar la instrucción ACTUALIZAR. Está disponible solo para tablas y vistas;
- Permiso DELETE para eliminar datos o ejecutar la instrucción DELETE. Está disponible solo para tablas y vistas;
- EXEC:permiso para ejecutar funciones y procedimientos almacenados. Está disponible solo para funciones y procedimientos almacenados;
- DRI (integridad referencial declarativa). Solo está disponible para tablas, vistas y funciones.
No hay permisos para el nuevo rol. Para poder ver una tabla, por ejemplo, Categorías, marque la casilla en la intersección de la fila Categorías y la columna SELECCIONAR. Verá una marca verde en la casilla, lo que significa un permiso. El segundo clic cambia la marca a la cruz roja y significa prohibición. Esto puede ser necesario si otorga un permiso al usuario y lo agrega a otro rol, donde se permite el acceso a la acción seleccionada. El tercer clic elimina cualquier permiso sobre la acción y deja el cuadro vacío. Esto significa que no hay acceso; sin embargo, se puede delegar si el usuario se agrega a otra función con los permisos en el objeto o si los permisos se especifican explícitamente.
Si selecciona una fila con el objeto de la tabla o vista, el botón Columnas estará disponible en la parte inferior de la ventana. Suponga que seleccionó la tabla y hizo clic en este botón. Se abre la ventana, en la que puede establecer permisos para columnas de tabla individuales.
Configurar permisos de columna
De hecho, esta es una gran posibilidad porque los usuarios o piratas informáticos no deben cambiar algunas columnas responsables de la integridad de la base de datos. Es mejor prohibir las operaciones UPDATE o SELECT (si es posible) para estas columnas.
Individualismo
Los roles son convenientes de usar cuando es necesario combinar usuarios similares. Por ejemplo, numerosos contadores necesitan tener acceso a las tablas financieras. Otorgar permisos a cada contador lleva mucho tiempo. Es mucho más fácil crear un rol para el contador, otorgarle permisos y luego agregar todas las cuentas contables a este rol.
Sin embargo, hay casos en los que los permisos deben ser únicos para un usuario, o además de los permisos otorgados por el rol, es necesario otorgar permisos adicionales. Por ejemplo, uno de los contadores necesita tener acceso a las tablas del departamento de recursos humanos. En este caso, es mejor agregar permisos directamente al contador en lugar de crear un nuevo rol.
Primero exploramos los roles para acostumbrarnos a ellos. En la mayoría de los casos, hay una cuenta separada para contadores, una cuenta separada para economistas, etc. En este caso, la mayoría de las personas se conectan al servidor usando una sola cuenta. Así, controlar quién hace qué es imposible. Es mejor usar permisos individuales cuando sea necesario, mientras que cada usuario debe tener su propia cuenta.
Permisos en tablas
Veamos cómo podemos otorgar permisos sobre objetos particulares, por ejemplo, sobre tablas.
Seleccione la rama Bases de datos/Northwind/Tablas en el árbol de objetos. En la parte derecha, se abre una lista de todas las tablas. Haga clic con el botón derecho en cualquier tabla y seleccione Todas las tareas/Administrar permisos. Se abre la ventana Propiedades del permiso, que es similar a la ventana Propiedades del rol de la base de datos con la lista de usuarios en lugar de la lista de objetos. El objeto es una tabla en la que hicimos clic y su nombre aparecerá en el menú desplegable de la ventana. Ahora, necesitamos establecer permisos en este objeto para diferentes usuarios.
Establecer permisos en una tabla
La lista de permisos es la siguiente:ver, actualizar, agregar, eliminar, ejecutar y administrar. Si hace clic en el botón Columnas, se abre la ventana para establecer permisos en el objeto a nivel de campos de tabla para un usuario en particular.
Visualizaciones
Tenemos dos mesas. Uno de ellos almacena la lista de empleados, mientras que otra tabla contiene información sobre la cantidad de horas trabajadas por mes y los salarios recibidos (salarios oficiales y ocultos).
Suponga que un funcionario de impuestos se le acerca y le pide que muestre los salarios de los trabajadores. Además, te preguntan si has pagado todos los impuestos. ¿Qué acciones necesitas realizar por tu parte?
La primera propuesta provino de la tercera fila:crear un nuevo usuario al que se le permita leer tablas que incluyan una lista de empleados y salarios. Además, no debe olvidar cerrar la columna con el salario oculto. En realidad, la solución es correcta pero absolutamente ineficaz.
La mejor opción es crear una vista, una consulta SQL que seleccione datos. En la base de datos, parece una tabla. Puede seleccionar datos SQL mediante consultas y conceder permisos. Resulta que la consulta se ejecutará contra la consulta.
Para crear una vista, ejecute la siguiente consulta:
CREATE VIEW salary AS SELECT fields for a tax official FROM Employees, Wages WHERE joins
Ahora, hay un nuevo objeto Salario en la rama Bases de datos/Northwind/Vistas. Si hace clic con el botón derecho y selecciona Todas las tareas/Administrar permisos, se abrirá la ventana para otorgar permisos. Establezca un permiso para el funcionario de impuestos y guárdelo. Para revisar el contenido de la vista, ejecute la consulta:
SELECT * FROM salary
Como puede ver, hay un acceso como a una tabla simple. El funcionario fiscal también pensará que ve datos reales. Sin embargo, de hecho, esta consulta contendrá solo los datos que necesitamos.
En la vida real, el funcionario fiscal no puede ser engañado tan fácilmente porque no son tontos. Sin embargo, este ejemplo muestra que la vista puede ser un método de seguridad perfecto. Podemos mostrar los datos que los usuarios necesitan y nada más. Al mismo tiempo, tenemos todas las herramientas para administrar los permisos en la vista sin afectar los permisos de acceso en las tablas.
Por lo tanto, diferentes vistas de las mismas tablas pueden mostrar datos diferentes. Si desea mostrar una columna adicional, agregue las vistas a la consulta. En este caso, no es necesario cambiar los permisos.
Vistas del sistema
En cada base de datos, puede haber vistas del sistema creadas por el servidor automáticamente. No recomiendo otorgarles un permiso porque pueden mostrar información adicional, lo que puede ayudar a un pirata informático a establecer permisos o simplemente destruir datos. Las vistas del sistema comienzan con el prefijo sys y el sistema se especifica en la columna Tipo de la lista.
Procedimientos y funciones
Los servidores de bases de datos modernos admiten funciones y procedimientos almacenados. Este es un código PL/SQL o Transact-SQL según la base de datos que se ejecuta en el servidor de la base de datos. Usando estos procedimientos, podemos realizar cualquier operación en el servidor o simplemente seleccionar datos, como en la vista. Podemos establecer permisos en cada procedimiento.
Al revisar los roles, ya hemos visto los procedimientos en la lista de objetos en los que puede establecer permisos y solo la columna EXEC está disponible en estas filas porque los procedimientos solo se pueden ejecutar.
Los procedimientos y funciones almacenados se almacenan en una base de datos particular. Para ver los procedimientos de la base de datos Northwind, seleccione la rama Bases de datos/Northwind/Procedimientos almacenados. Hay muchos procedimientos del sistema, cuyos nombres comienzan con el prefijo dt_ y el sistema se especifica en la columna Tipo. Se recomienda no dar acceso a estos trámites, si es posible. Puede ver las funciones en la rama de funciones definidas por el usuario/Northwind/Bases de datos.
Para cambiar los permisos sobre procedimientos y funciones, haga clic derecho en su nombre y seleccione Todas las tareas/Administrar permisos en el menú. En la ventana que aparece, puede cambiar solo la columna EXEC para procedimientos y las columnas EXEC y DRI para funciones.
Política de permisos
Algunos administradores establecen permisos en función del rol existente, por ejemplo, público. Esto no es cierto porque, en este rol, puede haber permisos que los usuarios no necesitan. Por lo tanto, intente establecer un nuevo permiso.
En cuanto a mí, siempre creo un nuevo rol y otorgo un conjunto mínimo de permisos. Si los usuarios piden más permisos y realmente son necesarios, agrego más permisos. Si permite todo de forma predeterminada, no hay garantía de que en el futuro se eliminen derechos innecesarios y peligrosos.
Otro problema para establecer menos permisos es un hábito. Los usuarios pueden acostumbrarse al hecho de que se les otorgan muchos permisos y luego la prohibición causará un grave escándalo. A nadie le gusta que se infrinjan sus derechos.
Tablas/Bases de datos
Las bases de datos almacenan sus configuraciones y propiedades ocultas en tablas y bases de datos del sistema. No se diferencian de otros objetos de la base de datos y se pueden establecer permisos en ellos. En ningún caso, no permita que los usuarios accedan a estas tablas sin una necesidad especial.
En SQL Server, los datos importantes del sistema se almacenan en las bases de datos maestra y msdb. Por lo tanto, estas bases de datos deben protegerse. En Oracle, cada base de datos existe como un objeto separado y las tablas del sistema se almacenan junto con las de los usuarios.
Casi todos los servidores de bases de datos ofrecen instalar bases de datos de prueba que se pueden usar para aprender o probar el sistema. Si los tiene, elimínelos, porque se establece un acceso público a estas bases de datos. Si un pirata informático conoce los nombres o las propiedades de cualquier objeto existente en el sistema, simplificará enormemente su tarea.
Al conectarse a una base de datos de prueba, puede ejecutar algunos comandos en el servidor y dañar el sistema operativo o una base de datos en funcionamiento. No debe haber cosas adicionales en el sistema. Además, tales tablas/bases de datos tienen permisos bastante altos incluso para un invitado.
Resumen
A pesar de que usamos MS SQL Server como ejemplo, los conceptos de permisos, roles y autenticación existen en todas las bases de datos.
Conociendo todas las reglas que consideramos, lo único que necesita es explorar la peculiaridad de su uso en su base de datos.
