Como este es un tema largo no lo podremos tratar en un solo artículo de este blog, por eso habrá otros artículos relacionados.
Crear usuarios para las bases de datos y determinar lo que esos usuarios pueden hacer y no pueden hacer, es una tarea básica de administración.
Hasta Firebird 2.5.9 la tarea de administración de usuarios estaba centralizada.
¿Qué significa eso?
Que los datos de los usuarios (sus nombres y los hash de sus contraseñas) se guardan en una «Base de Datos de seguridad», utilizada sólo para eso, y allí se buscan cuando alguien quiere conectarse a una Base de Datos normal.
El nombre de esa «Base de Datos de seguridad», en Firebird 2.x es: security2.fdb
¿Y qué significa que se guarda el hash de la contraseña?
Que en la Base de Datos security2.fdb nunca se guarda la contraseña del usuario sino un número que se obtiene al realizar algunas operaciones con esa contraseña.
Veamos un ejemplo muy simple para entender esto. Supongamos que la contraseña de un usuario es «SUPERMAN», y que el algoritmo para obtener el hash consiste en multiplicar el código ASCII de un carácter por la posición que ocupa dentro de la contraseña, empezando por 1, y sumando todos esos resultados parciales.
S = 83 resultado1 = 83 * 1 = 83
U = 85 resultado2 = 85 * 2 = 170
P = 80 resultado3 = 80 * 3 = 240
E = 69 resultado4 = 69 * 4 = 276
R = 82 resultado5 = 82 * 5 = 410
M = 77 resultado6 = 77 * 6 = 462
A = 65 resultado7 = 65 * 7 = 455
N = 78 resultado8 = 78 * 8 = 624
El hash de SUPERMAN, usando ese algoritmo será: 83 + 170 + 240 + 276 + 410 + 462 + 455 + 624 = 2720
Y en la Base de Datos llamada security2.fdb se guarda el número 2720, no la palabra SUPERMAN. Entonces, cuando el usuario quiere conectarse a una Base de Datos normal introduce su contraseña y el Servidor del Firebird calcula el hash de lo que escribió y lo compara con el hash guardado en security2.fdb. Si es 2720 entonces se le permite la conexión a la Base de Datos. Si el resultado es cualquier otro número, se lo rechaza.
Desde luego que el algoritmo usado por Firebird no es el mostrado arriba, es un algoritmo mucho más complicado. Lo de arriba fue un ejemplo muy sencillo para ilustrar la idea.
La gran ventaja de usar un hash es que la palabra SUPERMAN no la encontrarás jamás dentro de security2.fdb por la sencilla razón de que esa palabra jamás se guardó ahí, lo que sí se guardó fue su hash.
¿Te has dado cuenta que cuando escribes una contraseña/password debes escribir exactamente las mayúsculas y las minúsculas?
Eso es debido a que el código ASCII de una letra mayúscula es diferente al código de esa misma letra en minúscula. Por ejemplo, el código ASCII de la letra «A» es 65 pero el código ASCII de la letra «a» es 97. Al ser números diferentes los hash que se obtengan también serán diferentes, por supuesto.
¿Qué significa que la administración de usuarios está centralizada?
Que los nombres de todos los usuarios y los hash de todos los usuarios (hay un hash para cada usuario, nunca más y nunca menos) se encuentran siempre, sí o sí, en la Base de Datos de nombre security2.fdb
La ventaja de la administración de usuarios centralizada
Cada usuario (y su hash, claro) se crea una sola vez aunque haya muchas bases de datos en el Servidor. Escribiendo su nombre y su contraseña/password podría conectarse a cualquier Base de Datos. Aunque en cada Base de Datos se le podrían restringir los accesos/permisos/derechos, pero no se le podría impedir la conexión.
Y si está conectado a una Base de Datos entonces podría crear objetos dentro de esa Base de Datos, por ejemplo escribiendo:
CREATE TABLE PRUEBA1 (MiColumna1 INTEGER);
Listo, ya creó una tabla llamada PRUEBA1
También podría crear vistas, stored procedures, triggers, etc.
Te guste o no te guste…así funciona.
La desventaja de la administración de usuarios centralizada
Si un usuario conoce el nombre de una Base de Datos y su ubicación, entonces podrá conectarse a ella. Por ejemplo, si la Base de Datos es:
D:\CONTABILIDAD\DATABASES\MARCELA.FDB
con solamente conocer eso ya podrá realizar una conexión exitosa.
Lo mismo si no conoce la ruta y el nombre de la Base de Datos pero sí conoce el alias que se le asignó en el archivo ALIASES.CONF, podrá conectarse con éxito.
Y como ya sabes, si se conectó a una Base de Datos entonces podrá crear objetos dentro de esa Base de Datos.
Resumiendo:
La administración de usuarios centralizada tiene la ventaja de que se escribe poco porque el nombre de cada usuario y su contraseña se determinan una sola vez y pueden ser usados en múltiples bases de datos.
La desventaja es que cualquier usuario podría conectarse a cualquier Base de Datos si conoce el nombre y la ubicación (o el alias) de esa Base de Datos. Y aunque con los comandos GRANT y REVOKE se podría limitar las operaciones que puede realizar, que tenga esa posibilidad de poder conectarse a la Base de Datos que se le antoje, es un riesgo a la seguridad.
Otro riesgo a la seguridad, aún mucho más grave, es que si consigue copiar la Base de Datos (en un pen-drive, por ejemplo) y luego la lleva a una computadora donde conoce la contraseña del usuario SYSDBA entonces podrá ver todo lo que se le ocurra ver. O agregar. O borrar. O modificar.
En muchas empresas, sobre todo las pequeñas y medianas, es imposible evitar que algún empleado copie en un pen-drive una Base de Datos. Y algo así, podría ser muy grave.
Afortunadamente, con Firebird 3 se aumentó mucho la seguridad, como veremos en los siguientes artículos de esa serie.
Artículos relacionados:
Usuarios y seguridad en Firebird 3 (2)
Usuarios y seguridad en Firebird 3 (3)
Usuarios y seguridad en Firebird 3 (4)
Usuarios y seguridad en Firebird 3 (5)
Firebird SQL 
Comentarios recientes