Bloquear Mi BD en Firebird

[JUGUE]

Hola amigos.

Mi requisición consiste en lo siguiente: Tengo una base de datos de firebird a la cual le he hecho restricciones de acuerdo a las roles y todo eso, lo que quiero saber es como la puedo bloquear de tal forma que no puedan ver su contenido. En el equipo en que esta montada yo cambio la clave de sysdba, pero si se copia la base de datos y se lleva a otro equipo donde se monte firebird de nuevo pueden acceder a sus datos usando el login:
Sysdba-Masterkey.

Entonces como puedo bloquear el acceso a los datos de tal forma que ni haciendo esta operación puedan acceder a la información de la base de datos?

Gracias por la atención y de antemano les agradezco si me pueden ayudar.

[[AzidRain]]

No hay forma. La única alternativa es que solo ciertos usuarios tengan acceso en el servidor a esos archivos, claro si es un servidor Linux esto no tendrá problema.

[Neftali [Germán.Estévez]]

Empezado por JUGUE

...En el equipo en que esta montada yo cambio la clave de sysdba, pero si se copia la base de datos y se lleva a otro equipo donde se monte firebird de nuevo pueden acceder a sus datos usando el login:
Sysdba-Masterkey.

Entonces como puedo bloquear el acceso a los datos de tal forma que ni haciendo esta operación puedan acceder a la información de la base de datos?

No entiendo mucho de IB/FB y hace mucho tiempo que no trabajo con ella.

PREGUNTAS: ¿Se puede crear un usuario con permisos similares o equivalentes a SYSDBA y eliminar posteriormente el SYSDBA? ¿Eso solucionaría el problema de mover la Base de Datos a otro servidor?

[[felipe88]]

Hola,
Yo tengo otra pregunta, quien sea que quiera copiar tu base de datos ¿Como se da cuenta que esta hecha en firebird?, ademas si buscas la forma de proteger tu directorio la bd no seria "profanada"

[[egostar]]

Lo que pasa es que la seguridad no está creada en tu base de datos sino en el archivo security2.fdb que tienes en la carpeta donde instalaste firebird en tu maquina, no estoy seguro que pasa si copias ese archivo en la otra maquina, pero nuestro amigo jhonny te podria dar una mejor explicación al respecto el es el guru de firebird y sus modificaciones.

Por cierto, felicidades amigo jhonny, tu creación (FirebirdConfig) ha sido todo un exito

Salud PS

[xander]

Es fácil lo que quieres hacer si usas los triggers de la base de datos Before/After Connect, pero solo con firebird 2.1 en adelante...

En estos triggers puedes validar que el usuario que pretende conectarse sea válido para ti y si no lo es el lanzamiento de una excepción en los triggers evita que el intruso llegue más allá.

[[AzidRain]]

Lo de los triggers no le va a funcionar porque tendría que "soldar" el usuario dentro del código del trigger por lo que si después lo quiere cambiar será una lata.

Yo insisto que lo mas sencillo es proteger a nivel de Sistema operativo el directorio donde están alojadas los archivos de las bds de esta manera solo el administrador o quien se designe tendría acceso a esos archivos de otra manera sería imposible copiarlas, vamos ni siquiera ver que ahí están.

[juanelo]

Empezado por xander

Es fácil lo que quieres hacer si usas los triggers de la base de datos Before/After Connect, pero solo con firebird 2.1 en adelante...

En estos triggers puedes validar que el usuario que pretende conectarse sea válido para ti y si no lo es el lanzamiento de una excepción en los triggers evita que el intruso llegue más allá.

Esta se me hace una muy buena idea, lastima que estos eventos como mencionas solo vengan apartir de la 2.1.
Saludos

[Gallosuarez]

Srs.

En mi caso, la seguridad de FireBird dejó de ser un problema desde hace ya un tiempo. ¿Como lo solucioné?... Sencillo, utilizo un esquema mixto: servidor de datos dedicado (Linux Ubuntu Server 8.04) y los clientes se conectan en cualesquiera de los sabores de Window conocidos. ¿Precio? Lo mas barato del mercado: $500.00 USD (Principales características: Intel Xeon (2 procesadores, 2.4 GHz), 2 tarjetas de red Gigabit, 2 GB de memoria RAM, 2 discos duros de 100 GB c/u). Como se pueden dar cuenta, está al alcance de cualquier persona y bolsillo. Por mi parte es la solución que estoy utilizand en TODOS mis desarrollos (Cualquier cliente puede adquirir este servidor creanlo, pues resulta mucho mas barato que cualquier máquina ensamblada con Windows, y nunca se va a comparar con los beneficios que Linux otorga). Además el desempeño es barbaro. Todo funciona a la perfección. Estoy seguro que Neftali nunca a utilizado un esquema parecido. Amigo Neftalí, piensalo y aunque sea por curiosidad haz la prueba. Ignoro cual sea la base de datos que tú utilizas pero conozco al menos tres personas que utilizaban MySQL y despues de probar Firebird ya no quisieron saber nada de MySQL. ¿Sera por algo?. Por cierto, no se si sepan que el creador de Interbase (Jim Starkey, ¿asi se escribe?), estuvo trabajando un tiempo en el equipo de desarrollo de MySQL.

Saludos a todos los foristas,
Gerardo Suárez

[Neftali [Germán.Estévez]]

Empezado por Gallosuarez

Estoy seguro que Neftali nunca a utilizado un esquema parecido. Amigo Neftalí, piensalo y aunque sea por curiosidad haz la prueba. Ignoro cual sea la base de datos que tú utilizas pero conozco al menos tres personas que utilizaban MySQL y despues de probar Firebird ya no quisieron saber nada de MySQL. ¿Sera por algo?. Por cierto, no se si sepan que el creador de Interbase (Jim Starkey, ¿asi se escribe?), estuvo trabajando un tiempo en el equipo de desarrollo de MySQL.

Creo que es una muy buena solución y no dudo que solvente tu problema, además se ajusta a tus necesidades, pero sigo pensando que no todo el mundo puede adquirir un servidor dedicado (sea Windows/Linux) para "suplir" las carencias del SGBD en seguridad.

He visto servidores con 15 o 20 máquinas conectadas, que como he dicho estaban "muertas de risa"; La CPU no subía del 5% y el servidor SQL estaba más frío que el congelador de un esquimal. Todo depende del desarrollo; Por eso no es una solución que se pueda considerar genérica. Habrá otros casos que con 5 máquinas el servidor eche humo y sí se justifique tener una máquina dedicada.

Sí he hecho algunas pruebas (en mi empresa anterior) con IB/FB (hablamos de versaiones de hace 4 años), pero la verdad es que no quedamos muy contentos. Había clientes con él funcionando, pero la experiencia nos hizo ver que por encima de 15 máquinas había que "mudar" (en nuestro caso a SQL Server); Problemas de rendimiento y fiabilidad sobre todo.

[Casimiro Notevi]

Empezado por Neftali

[..]
He visto servidores con 15 o 20 máquinas conectadas, que como he dicho estaban "muertas de risa"; La CPU no subía del 5% y el servidor SQL estaba más frío que el congelador de un esquimal. Todo depende del desarrollo; Por eso no es una solución que se pueda considerar genérica. Habrá otros casos que con 5 máquinas el servidor eche humo y sí se justifique tener una máquina dedicada.

Creo que una empresa con 20 máquinas tiene más que justificado tener un servidor dedicado, aunque éste se muera de risa, cuestión de poner uno más humilde.

Empezado por Neftali

Sí he hecho algunas pruebas (en mi empresa anterior) con IB/FB (hablamos de versaiones de hace 4 años), pero la verdad es que no quedamos muy contentos. Había clientes con él funcionando, pero la experiencia nos hizo ver que por encima de 15 máquinas había que "mudar" (en nuestro caso a SQL Server); Problemas de rendimiento y fiabilidad sobre todo.

La mayoría de nuestros clientes tienen más de 15 máquinas, la media puede estar alrededor de 20 a 30 máquinas y algunos sobrepasan las 100, ninguno tiene problemas de rendimiento y mucho menos de fiabilidad
Estoy hablando de bases de datos de más de 10 Gbytes.

[Neftali [Germán.Estévez]]

Empezado por Casimiro Notevi

Creo que una empresa con 20 máquinas tiene más que justificado tener un servidor dedicado, aunque éste se muera de risa, cuestión de poner uno más humilde.

No creo que sea generalizable, Casimiro.
Sigo pensando que depende de la carga de trabajo que tenga el Servidor.

Aunque me da la impresion de que nunca vamos a ponernos de acuerdo.

[Casimiro Notevi]

Empezado por Neftali

[..]
Aunque me da la impresion de que nunca vamos a ponernos de acuerdo.

Puede que en esto no, pero en otras cosas... seguro que sí

[hecospina]

Hola
No recuerdo si fue en este foro donde encontre una solucion que aunque no es la panacea le da trabajo a la persona que ingresa a la base de datos

Lo primero es crear un usuario con los mismos atributos de SYSDBA
Luego eliminas a SYSDBA
posteriormente creas un roll con el nombre SYSDBA, este queda directamente en la base de datos
Como no pueden existir un roll y un nombre de usuario igual no podran accesar la base de datos aunque cambien de PC o restauren la copia

No es infalible, pero... seria una solucion