Club Delphi  
    FTP   CCD     Buscar   Trucos   Trabajo   Foros

Retroceder   Foros Club Delphi > Bases de datos > Firebird e Interbase
Registrarse FAQ Miembros Calendario Guía de estilo Buscar Temas de Hoy Marcar Foros Como Leídos

Respuesta
 
Herramientas Buscar en Tema Desplegado
  #1  
Antiguo 24-05-2003
jberaza jberaza is offline
Registrado
 
Registrado: may 2003
Ubicación: MONTEVIDEO - URUGUAY
Posts: 6
Poder: 0
jberaza Va por buen camino
ISC4 y PRIVACIDAD DE ESTRUCTURA

Nuevamente yo, preguntando lo siguiente:

Si yo distribuyo junto a mi software un archivo de interbase llamado DATOS.GDB, es posible que solo mi programa lo pueda acceder y nadie mas pueda conocer la estructura de mis tablas y mis datos????.
Mi pregunta surje por lo siguiente: Si el usuario final usa un nuevo archivo ISC4.GDB con un usuario que pueda hacer todo, vería mi diseño del problema (tablas, campos, tipos de datos, etc.)?????
HAY ALGUNA FORMA DE MANTENER LA PRIVACIDAD EN LA ESTRUCTURA DE DATOS PUES VEO QUE ISC4 ES GLOBAL A TODAS LAS BASES DE DATOS

Saludos y gracias
Responder Con Cita
  #2  
Antiguo 24-05-2003
Avatar de kinobi
kinobi kinobi is offline
Miembro
 
Registrado: may 2003
Posts: 2.621
Poder: 23
kinobi Va por buen camino
Hola,

todo el mecanismo de gestión de usuarios está basado en la base de datos de usuarios (isc4.gdb); por tanto, si alguien consigue llegar a hasta ella, o tiene la contraseña del administrador (SYSDBA) o la del superusuario (root en sistemas Unix y Linux), puede hacer lo que quiera con tu base de datos.

Conclusión: tu base de datos es tan segura como lo sea el sistema operativo sobre el que está corriendo el servidor InterBase.

Nota: existe la posibilidad de eliminar el código fuente de ciertos metadatos (procedimientos almacenados, triggers y vistas), pero nada más. Si te interesa, en otro mensaje te comento cómo hacerlo.

Saludos.
Responder Con Cita
  #3  
Antiguo 26-05-2003
pedrohdez pedrohdez is offline
Miembro
 
Registrado: may 2003
Ubicación: Murcia
Posts: 54
Poder: 21
pedrohdez Va por buen camino
Hola Jberza,

¿que quieres evitar? que un usuarios vea los datos crudos, o que tu cliente acceda a sus datos?

Lo primero me parece legitimo y correcto, un usuario solo debe acceder a la información para la que esta autorizado, pero cortar el acceso del cliente a sus propios datos no me parece legitimo, es aceptable eliminar los fuentes de los store procedures, son tuyos igual que el fuente de la aplicación, sobre todo desde el momento que un cliente no paga el 100% del coste de desarrollo, no solo el tiempo empleado si no tu coste de formación previo, pero lo que no debes negarle es el acceso a su información.

Es solo una opinion personal, y tampoco se cual es el caso tuyo, igual distribuyes una aplicacion de consulta y la GDB se entrega llena de datos, aqui la cosa cambiaria completamente.

pedro.
Responder Con Cita
  #4  
Antiguo 26-05-2003
jberaza jberaza is offline
Registrado
 
Registrado: may 2003
Ubicación: MONTEVIDEO - URUGUAY
Posts: 6
Poder: 0
jberaza Va por buen camino
Estimado Pedro:

Quiero evitar que cualquier persona que tambien realiza software, conozca la forma en que resolvi mi aplicacion conociendo las tabas, el diseño, los campos, etc. No es un problema de datos sino de no mostrar la solucion.

Gracias de todos modos, saludos, JORGE BERAZA
Responder Con Cita
  #5  
Antiguo 26-05-2003
pedrohdez pedrohdez is offline
Miembro
 
Registrado: may 2003
Ubicación: Murcia
Posts: 54
Poder: 21
pedrohdez Va por buen camino
Hola Jorge,

Con IB no puedes eliminar las estructuras, solo al nivel que te ha comentado Kinobi, eliminar el codigo de triggers y SPs pero nada mas, no conozco ninguna BD que permita ocultar estructuras, tampoco es quer lo he investigado mucho, como te comentaba en el correo anterior no me parece correcto impedir al cliente el acceso a sus datos, aunque eso implique dejar a la vista parte de mi trabajo, tampoco borro triggers ni sp, no es una cosa que me preocupe en exceso.

Por si estas interesado en borrar los procediemientos, mira en la tabla rdb$procedures y en rdb$triggers.

Saludos,
Pedro.
Responder Con Cita
  #6  
Antiguo 26-05-2003
Avatar de kinobi
kinobi kinobi is offline
Miembro
 
Registrado: may 2003
Posts: 2.621
Poder: 23
kinobi Va por buen camino
Hola,

es más, las aplicaciones cliente (en el caso de aplicaciones Delphi, los componentes de acceso a datos) deben tener acceso a los metadatos (estructuras de tablas, columnas, claves, índices, ...) de la base de datos para poder funcionar.

En cuanto a ocultar los fuentes de ciertos metadatos (triggers, procedimientos y vistas), he subido a mi página web un documento donde se explica el método; tal como tu comentas es a través de las tablas del sistema rdb$procedures, rdb$triggers y rdb$relations.

Saludos.
Responder Con Cita
  #7  
Antiguo 28-05-2003
lbuelvas lbuelvas is offline
Miembro
 
Registrado: may 2003
Ubicación: Colombia
Posts: 377
Poder: 21
lbuelvas Va por buen camino
Hola muchachos,

Creo que este hilo se esta convirtiendo en un debate (bueno hay un foro que se llama asi).

Infortunadamente para quienes trabajamos con Interbase/Firebird las estructuras de las bases de datos son muy visibles.

Cualquier persona con un programa como IBConsole (o cualquier herramienta para administracion) puede "sacar" la estructura de la Base de Datos y llevarsela en un diskete. Es más, se toma los metadatos y algunas herramientas como ERWin (www.ca.com) pueden generarte por ingeneria en reversa el modelo, si señor el dibujito y todo.

Algunas bases de datos la cosa puede ser un poco mas dificil como en Oracle, pero una persona con algun entrenamiento podria sacarla.

Sin embargo lo comentado por el compañero Pedro Hernandez es muy válido, no podemos "cerrarle" al cliente la posibilidad que pueda acceder a la base de datos.

He observado algunas triquiñuelas de programadores para hacer mas dificil el proceso pero creo que no es muy etico. Una de ellas es oscurecer los nombres de los atributos, por ejemplo al atributo nombre del cliente llamarlo "clnmb", pero al final creo que es mas el enredo para uno de desarrollador.

En lo personal he tomado bases de datos de otros desarrolladores y he visto y "aprendido" formas de hacer algunas mejoras a mis propios productos (tambien se que ellos han hecho lo mismo con mi trabajo).

Pero señores el Bechmarking es una forma de trabajo, observa al mejor, aprende del mejor y supera al mejor.

Creo que debemos enfocarnos en hacer cada vez mejor nuestros productos y no rompernos tanto la cabeza en algo que esta fuera de nuestro control.
__________________
Luis Fernando Buelvas T.
Responder Con Cita
  #8  
Antiguo 10-07-2008
canelita canelita is offline
Miembro
 
Registrado: ago 2007
Ubicación: Cucuta
Posts: 18
Poder: 0
canelita Va por buen camino
Seguridad -->Clave de Acceso a base de datos

Es posible eliminar la clave SYSDBA y masterkey de Interbase para mantener la seguridad en los datos de tal modo que otro ingeniero que programe no puede acceder a la base de datos. Es decir dejar solo las claves que van a manejar los usarios responsables de alimentar la informacion de la base de datos?
Responder Con Cita
  #9  
Antiguo 10-07-2008
Avatar de jhonny
jhonny jhonny is offline
Jhonny Suárez
 
Registrado: may 2003
Ubicación: Colombia
Posts: 7.058
Poder: 29
jhonny Va camino a la famajhonny Va camino a la fama
Cita:
Empezado por canelita Ver Mensaje
Es posible eliminar la clave SYSDBA y masterkey de Interbase para mantener la seguridad en los datos de tal modo que otro ingeniero que programe no puede acceder a la base de datos. Es decir dejar solo las claves que van a manejar los usarios responsables de alimentar la informacion de la base de datos?
Puedes usar el gsec para cambiar el password de cualquier usuario, incluso el del SYSDBA, pero de ahí a eliminar el SYSDBA, pues la verdad es que nunca lo había intentado hasta hoy y ni siquiera se si se puede hacer.

Pero por lo menos si hago lo siguiente:

gsec -user SYSDBA -password masterkey -delete SYSDBA

Pues me devuelve:
"An error occurred while attempting to delete the user record."

Para que veas como utilizar el gsec, puedes ir a la pagina web...
http://www.destructor.de/firebird/gsec.htm
__________________
Lecciones de mi Madre. Tema: modificación del comportamiento, "Pará de actuar como tu padre!"

http://www.purodelphi.com/
http://www.nosolodelphi.com/
Responder Con Cita
  #10  
Antiguo 11-07-2008
pedrohdez pedrohdez is offline
Miembro
 
Registrado: may 2003
Ubicación: Murcia
Posts: 54
Poder: 21
pedrohdez Va por buen camino
Hola,
No te serviria de mucho eliminar SYSDBA, en Firebird la seguridad es del servidor, la forma mas sencilla de saltarte esas restricciones es instalar un firebird en una maquina limpia, copia la GDB y listo, accedes como SYSDBA masterkey sin mayor problema.

O incluso mas sencillo, usa Firebird embebido, ni siquieras tienes que instalar nada.

Te recomiendo que revises las paginas de FirebirdSQL.org esta previsto implementar la seguridad por base de datos para la version 3.0 (lo cuentan aqui: http://www.destructor.de/firebird/3.0/index.htm)

Un saludo,
Pedro
Responder Con Cita
  #11  
Antiguo 12-07-2008
Avatar de AzidRain
[AzidRain] AzidRain is offline
Miembro Premium
 
Registrado: sep 2005
Ubicación: Córdoba, Veracruz, México
Posts: 2.914
Poder: 21
AzidRain Va camino a la fama
Yo creo que estás cayendo en la paranoia del programador bisoño. La estructura de una base de datos mas los SP (o PA) no son sino una parte un sistema completo. Hay más de un ejemplo estructuras de archivos y BD que nacieron con intención de ser "privadas" que no duraron ni la víspera antes de que alguien se metiera a descubrir como le hicieron.

Antes que pensar que tienes el "santo grial" de la programación, es mejor verificar que efectivamente el software que produces resuelve el o los problemas para los cuales fue concebido.
__________________
AKA "El animalito" ||Cordobés a mucha honra||
Responder Con Cita
  #12  
Antiguo 12-07-2008
lbuelvas lbuelvas is offline
Miembro
 
Registrado: may 2003
Ubicación: Colombia
Posts: 377
Poder: 21
lbuelvas Va por buen camino
En Interbase /Firebird no es posible cerrar la base de datos para que nadie tenga acceso al diseño (tablas, llaves, indicces, etc).

Lo unico que se puede hacer como comento kinobi (quien hace años no pasa por aca) y de hecho yo lo hago es eliminar el codigo fuente de los triggers y procedimientos almacenados.

Kinobi elaboro un documento para eso, me tomo el atrevimiento de copiar el codigo sql para eso:

Código SQL [-]
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)));
__________________
Luis Fernando Buelvas T.
Responder Con Cita
  #13  
Antiguo 12-07-2008
lbuelvas lbuelvas is offline
Miembro
 
Registrado: may 2003
Ubicación: Colombia
Posts: 377
Poder: 21
lbuelvas Va por buen camino
Olvidaba darles un consejo, antes de ejecutar las instrucciones anteriores, hagan una copia de seguridad de la base de datos.
__________________
Luis Fernando Buelvas T.
Responder Con Cita
Respuesta


Herramientas Buscar en Tema
Buscar en Tema:

Búsqueda Avanzada
Desplegado

Normas de Publicación
no Puedes crear nuevos temas
no Puedes responder a temas
no Puedes adjuntar archivos
no Puedes editar tus mensajes

El código vB está habilitado
Las caritas están habilitado
Código [IMG] está habilitado
Código HTML está deshabilitado
Saltar a Foro


La franja horaria es GMT +2. Ahora son las 04:04:28.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi
Copyright 1996-2007 Club Delphi