Foros Club Delphi - Comentarios varios sobre seguridad

Foros Club Delphi (https://www.clubdelphi.com/foros/index.php)

- Firebird e Interbase (https://www.clubdelphi.com/foros/forumdisplay.php?f=19)

- - Comentarios varios sobre seguridad (https://www.clubdelphi.com/foros/showthread.php?t=22642)

Comentarios varios sobre seguridad

Hola Foro

Utilizo FB 1.52 en linux y en windows e IBExpert personal como administrador.
Hace algunos dias en otro foro se planteaba el problema de lo vulnerable que se convierte la seguridad de los datos (y los metadatos) cuando se distribuyen aplicaciones que utilizan FB/IB como base de datos. Cualquiera con acceso al archivo podría copiar la base de datos y utilizando otro servidor e ingresando con el usuario SYSDBA tendría acceso irrestricto a toda la base de datos. Algunos miembros del foro indicábamos que FB/IB es un gestor de bases de datos cliente/servidor y como tal, debe protegerse el acceso al archivo de la base de datos en el servidor. Por tanto, esto no debiera representar un problema de seguridad en una típica instalación cliente/servidor. Además sugerí la lectura de un artículo que aparece en este sitio sobre como borrar el código fuente de procedimientos, triggers y vistas para proteger nuestro desarrollo. Básicamente ejecutando las siguientes instrucciones se cumplirá nuestro objetivo:

Código:

UPDATE rdb$procedures

SET rdb$procedure_source = NULL

WHERE (rdb$system_flag = 0);



UPDATE rdb$triggers

SET rdb$trigger_source = NULL

WHERE ((rdb$system_flag = 0) OR (rdb$system_flag IS NULL))

AND (rdb$trigger_name NOT IN (SELECT rdb$trigger_name FROM rdb$check_constraints));



UPDATE rdb$relations

SET rdb$view_source = NULL

WHERE (rdb$system_flag = 0);

A partir de esto empiezo a hacerme algunas preguntas:

* Qué sucede si entramos con un usuario normal (no sysdba, no propietario), desde IBExpert u otro gestor, que además no tenga ningún tipo de permisos sobre cierta base de datos, pero sí está registrado en el servidor?
- Para mi fue una sorpresa. Acceso a la estructura de todas las tabla, al código de procedimientos, triggers y vistas, índices, dominios, restricciones, etc. Como era de esperar no pude ver los datos almacenados. Luego de aplicar las instrucciones SQL anteriores yo no pudieron verse los códigos de procedimientos triggers y vistas.

* Qué pasará si intento extraer los metadatos (característica disponible en IBExpert y otros gestores)?
- Aún habiendo eliminado los códigos con las instrucciones SQL, pude extraer los metadatos completos de mi base de datos. Siempre accediendo como un usuario normal y sin ningún tipo de permisos sobre la base. También utilice una herramienta que permite generar documentación HTML consiguiendo el mismo resultado.

Ahora ya cambió la cuestión, ya no se trata de que alguien acceda y copie la base a otro servidor, sino que cualquier usuario registrado en el servidor tiene acceso completo a los metadatos, aunque sea a modo de lectura.

Si bien actualmente hay una tendencia hacia el código abierto, no me parece que dejar expuestas las reglas de negocio sea una decisión acertada. En mi caso absolutamente todo lo hago a través de procedimientos y triggers.

Ahora bien, hay algún método realmente efectivo para proteger la base de datos?.

Hola,

Cita:

Empezado por TJose

Ahora ya cambió la cuestión, ya no se trata de que alguien acceda y copie la base a otro servidor, sino que cualquier usuario registrado en el servidor tiene acceso completo a los metadatos, aunque sea a modo de lectura.

El restringir el acceso a los metadatos complicaría seguramente muchas operaciones desde las aplicaciones clientes. No se me ocurre cómo realizar desde Delphi una conexión (independientemente del tipo de usuario que sea) desde la que se lanzara una consulta SQL (con un TQuery por ejemplo) del tipo: SELECT * FROM MiTabla, para después acceder a columnas concretas del conjunto resultado devuelto por el servidor a través de métodos como FieldByName('Columna'), sin tener acceso a los metadatos. El DataSet (TQuery en este caso) debe acceder a los metadatos en tiempo de ejecución para construir un conjunto de datos que coincida (estoy hablando de los dominios de las columnas) con los metadatos almacenados. Por no hablar de la creación de campos persistentes desde los DataSets en tiempo de diseño en modulos de datos y formularios, o el acceso a la definición de índices para ser fijados en tiempo de diseño y ejecución en un DataSet, o...

Es posible que se pudiese restringir parte del acceso a los metadatos, pero no completamente, ya que gran parte de los metadatos deben ser accesibles si no se quiere que la construcción de aplicaciones clientes que hagan uso de esa base de datos sea un infierno.

Cita:

Empezado por TJose

Ahora bien, hay algún método realmente efectivo para proteger la base de datos?.

Probablemente no, no al menos al nivel de que la base de datos se comporte como una caja negra al exterior, sin ofrecer ningún detalle de su implantación. Incluso el borrado del código fuente de triggers y procedimientos almacenados, al que haces referencia anteriormente, tiene puntos débiles, como que nada impide el acceso al código (semi)compilado (BLR) de los mismos y, a través de ingeniería inversa, poder reconstruir un código fuente bastante parecido al original.

Saludos.