PDF de programación - Firebird: Administración y seguridad

FIREBIRD:

ADMINISTRACIÓN

Y SEGURIDAD










Firebird: Administración y seguridad Tema 5

FIREBIRD: ADMINISTRACIÓN Y SEGURIDAD

1.- SEGURIDAD.....................................................................................................................................1
2.- TABLAS Y VISTAS DE SISTEMA.................................................................................................5
3.- MONITORIZACIÓN.........................................................................................................................6
4.- CONFIGURACIÓN...........................................................................................................................8
5.- HERRAMIENTAS.............................................................................................................................9
5.1.- ISQL............................................................................................................................................9
5.2.- GBAK y.....................................................................................................................................10
5.3.- GFIX .........................................................................................................................................10
5.4.- GSTAT......................................................................................................................................10
5.5.- GSEC.........................................................................................................................................11



Vicente Tejero Trueba Pag i IES Pedro Espinosa

Firebird: Administración y seguridad Tema 5



1.- SEGURIDAD
Firebird no viene con ninguna utilidad para encriptar y desencriptar datos (salvo para las
contraseñas de usuario) por lo que esta operación la tiene que hacer el cliente. Así no se tienen
mecanismos de seguridad sobre los ficheros salvo los establecidos por el propio sistema operativo en
el que se encuentra instalado el servidor.
Es por ello, que se aconseja instalar el servidor en máquinas dedicadas en las que se pueda
establecer un buen nivel de seguridad: sistema operativo seguro (mejor linux que windows), sistema
de ficheros apropiado (ext o ntfs), establecer limitaciones de acceso por parte de usuarios a los ficheros
(definición de permisos de acceso a las carpetas y/o ficheros, no compartir las carpetas en red),
configuración de un cortafuegos (habilitar sólo lo mas imprescindible como el acceso al servidor a
través del puerto 3050), trabajo sobre líneas seguras y aplicar configuraciones de seguridad a Firebird
(directorios en los que pueden estar los ficheros de bases de datos, etc).

La instalación de servidor de Firebird incluye una base de datos de autentificación de usuario
(fichero security.fdb) para almacenar las definiciones de todos los usuarios que tienen acceso al
servidor. Para cada usuario se establece un nombre y una contraseña sensible al contexto.

Esta seguridad se aplica cuando se conecta un usuario al servidor mediante conexión TCP/IP o
local, siendo necesario identificarse con un usuario y contraseña. Este mecanismo adolece de un
problema básico: si copian un fichero de base de datos y lo llevan a otro sistema, pueden acceder al
mismo con los datos de seguridad de éste último (usuario y contraseñas), por lo que es fundamental
hacer segura la máquina servidor.

Por defecto, Firebird viene con un usuario administrador SYSDBA con contraseña
MASTERKEY, aconsejándose como primera operación cambiar la contraseña. Este usuario tiene
permiso para hacer cualquier operación sobre cualquier objeto de la base de datos. Por ello, siempre se
debe definir otro usuario con el que trabajar cuando, por ejemplo, accedemos desde un cliente. Si
capturan el nombre de usuario y/o contraseña, podrán hacer menos cosas sobre la base de datos.

Un usuario se crea mediante la sentencia CREATE USER, se modifica mediante ALTER
USER y se borra mediante DROP USER


CREATE USER <nombre usuario> {PASSWORD 'contraseña'}
[FIRSTNAME 'nombre']
[MIDDLENAME 'primer apellido']
[LASTNAME 'segundo apellido'];



CREATE USER <nombre usuario>
[PASSWORD 'contraseña']
[FIRSTNAME 'nombre']
[MIDDLENAME 'primer apellido']
[LASTNAME 'segundo apellido'];

DROP USET <nombre usuario>





Un usuario con permisos SYSDBA puede crear, modificar y borrar usuarios. Un usuario puede
modificar su contraseña.

En Firebird, se trabaja con el concepto de role. Un role es creado en una base de datos estanado
sólo disponible en la misma. No es más que un contenedor de privilegios asignados. Una vez que se
rellena algún privilegio, estos pasarán a estar disponibles para algunos usuarios.

Vicente Tejero Trueba Pag 1 IES Pedro Espinosa

Firebird: Administración y seguridad Tema 5

Un role se usa para controlar permisos asignados a conjuntos de usuarios, por ejemplo, se
consideran usuarios de perfil administrativos, otros cajeros, etc. Así se asignan los permisos a role y se
incluyen los usuarios en el role. Cualquier cambio se realiza sobre el role y no sobre los usuarios
individuales.

Un usuario de Firebird se puede asignar a mas de un role, aunque sólo se le aplicará los
permisos para el role con el que se conectó.

Además de los roles Firebird soporta los grupos UNIX y recientemente los WINDOWS.

Firebird trae por defecto un role para administración RDB$ADMIN. Este role se utiliza para
dar permisos de SYSDBA a un usuario. Para ello será necesario asignarlo previamente al usuario.

A nivel de un objeto de base de datos se trabaja con los privilegios. Un privilegio representa un
permiso para realizar una operación de DML. Se tienen los siguientes privilegios:

INSERT: Crear nuevas filas.

- SELECT: Leer datos.
-
- UPDATE: Modificar datos existentes.
- DELETE: Borrar filas.
- REFERENCES: Referirse a una clave primaria desde una clave foránea. Siempre se tiene

que acompañar de los privilegios sobre las tablas que contienen la tabla foránea.

- ALL: Todos los privilegios anteriores.
- EXECUTE: Ejecución un procedimiento almacenado o llamarlo desde una sentencia

SELECT. Nunca se asigna cuando se indica ALL.

- ROLE: Se adquieren todos los privilegios asignados al role. Nunca se asigna cuando se

indica ALL.


Cada objeto defininido en la base de datos (tabla, vista, procedimiento almacenado y role) tiene
definido una serie de privilegios que se pueden asignar sobre él. Así un UPDATE no es aplicable a un
procedimiento almacenado mientras que un EXECUTE no es aplicable a una tabla o vista. De esta
forma tenemos que:

- SELECT, INSERT, UPDATE y DELETE sólo se pueden aplicar a tablas y vistas.
- REFERENCES solo se aplica a tablas, en principio solo a aquellas que son referenciadas

por claves foráneas.

- En las vistas, el usario además de tener permiso sobre la misma debe tener permisos sobre
las tablas usadas para generar la misma. Estos permisos puede tenerlos el propietario de la
vista, la vista en sí misma o el usuario de la vista.

- La vistas actualizables tienen que tener los permisos SELECT, INSERT, UPDATE y

DELETE sobre las tabla base.

- EXECUTE solo se puede puede aplicar a procedimientos almacenados.,


Los privilegios se asignan a los usuarios. Un usuario será un usuario definido en la base de
datos de seguridad, una cuenta o un grupo UNIX/WINDOWS, un usuario especial o un objeto de base
de datos.

La asignación de los permisos a un objeto sólo la puede realizar el usuario SYSDBA o el
propietario del mismo. Si alguno de ellos quiere permitir que otro usuario distinto pueda asignar
permisos se utiliza la cláusula WITH GRANT OPTION. A partir de ese momento el usuario puede
asignar los permisos que le han dado a otro usuario. Esto mismo se puede aplicar para administrar el
objeto con la cláusula WITH ADMIN OPTION.


Vicente Tejero Trueba Pag 2 IES Pedro Espinosa

Firebird: Administración y seguridad Tema 5
Existe un usuario especial PUBLIC que representa cualquier usuario en la base de datos y que
se puede utilizar para asignar permisos a todos en un solo paso.

Los privilegios se pueden asignar tanto a objetos enteros como a columnas dentro de una tabla
o vista. Para asignarlos se tiene la siguiente sintaxis:


GRANT <privilegios>
{ON {{[TABLE] <tabla>}
| <vista>
| {PROCEDURE procedimiento}
}
}| <role con privilegios>
TO <usuario generico>
[{WITH GRANT OPTION} | {WITH ADMIN OPTION}]

<privilegios> = <privilegio> [, <privilegio> ...] | <role> | ALL
<privilegio> = INSERT | DELETE | UPDATE [(columna [, columna ....])]
| REFERENCES [(columna [, columna ....])]
| EXECUTE

<usuario generico> = <usuario>[, usuario …] | PUBLIC








| <usuario LINUX> | <usuario WINDOWS>
| GROUP <grupo LINUX o WINDOWS>
| <role>
| {TRIGGER triger}
| {PROCEDURE procedimiento}
| {VIEW vista}


Por ejemplo podríamos tener

GRANT SELECT, UPDATE, INSERT, DELETE ON USUARIOS TO profesor; -- da los privilegios

indicados a la tabla usuarios para el usuario profesor.

GRANT UPDATE (CODIGO) ON USUARIOS TO PUBLIC -- da permiso para actualizar la columna

codigo de la tabla usuarios a PUBLIC


GRANT REFERENCES (codigo) ON USUARIOS TO oficina; -- da el permiso para referenciar la

columna codigo de la tabla usuarios al usuario oficina.


GRANT EXECUTE ON PROCEDURE procedimiento
TO profesor,
PROCEDURE otro_proc; -- da el privilegio de ejecución sobre procedimiento al usuario

profesor y al procedimiento otro_proc;


GRANT ALL ON USUARIOS TO profesor; -- da todos los privilegios sobre la tabla usuarios al usuario

profesor.



Para trabajar con los roles se tiene una serie de sentencias. Por ejemplo podríamos tener:


CREATE ROLE papel; -- crea el role papel
l
GRANT ALL ON USUARIOS TO papel; --asigna todos los privilegios al rol