Protección de base de datos,

En mi caso, es un pedido del cliente. En la empresa del cliente nadie debe
poder acceder a los datos de la aplicación navegando las tablas.

No entiendo bien los puntos 1 y 3.
¿Podrías explicarme más detenidamente qué ventajas obtengo con el trigger
"with encryption" (nunca lo hice)?.



"Luis Enrique García A." escribió:

Es un punto complicado, puedes esconder el pass de "sa" pero no mas, lo que
se utiliza normalmente para incrementar la seguridad de tus sistemas y mas
si es en via de que no modifiquen la base de datos para realizar reportes o
cambios a tu informacion, estriba en:

1. No manejar integridad referencial del tipo PRIMARY KEY / FOREIGN KEY sino
manejar toda esa parte por trigger "WITH ENCRYPTION"

2. Nombres de objetos no genericos, es decir, tu catalogo de productos no se
llamara "Productos" o algo similar, sino que todas tus objetos tendran un
nombre del tipo "XXb125" o la semantica que tu decidas

3. Manejar vistas con triggers "INSTEAD OF" tambien "WITH ENCRYPTION"

4. Todos tus SP recompilarlos con "WITH ENCRYPTION"

5. Dependiendo de tu front end, verifica la posibilidad de almacenar tu info
encriptada (Esto siempre ralentiza los procesos)

6. El DBO de tu base de datos debe de ser el de tu aplicacion y sera el
unico con acceso a ella


Esto, no es garantia de que no entren a tu base de datos, pero al menos les
complicaras la vida.


Adicionalmente, si tu SW es de pago, no olvides agregar en la licencia la
estructura de la base de datos.

Y dentro de la garantia, la perdida de la misma si se realizan actividades
en la base de datos que no sean ejecutadas desde tu aplicacion.


En fin, solo son algunos puntos, la pregunta es ¿¿¿Vale la pena invertir
tiempo en todo esto??? tal vez te sea suficiente con el registro de licencia
de tu producto para evitar todo eso.


Luis E.



"José Miguel Torres" <jtorres_diaz~~ARROBA~~terra.es> escribió en el mensaje
news:
> Buenas señores:
>
> Tengo un problema. Tengo que distribuir una aplicación a unos 20
usuarios
> con MSDE o SQL Server. La base de datos también entra en la distribución.
Mi
> pregunta es, ¿cual es la mejor manera de asegurarme que nadie entrará en
la
> base de datos para modificarla? he estudiado varias alternativas, (
capturar
> el sa, auditar conexión,) espero me echen una mano, muchas gracias
desde
> ya!
>
>
> José Miguel Torres
> jtorres_diaz~~ARROBA~~terra.es
> http://jmtorres.blogspot.com
>
>
>

Bueno, si yo puedo conectarme a la base de datos fuera de tu aplicacion, y
genero un diagrama de la misma, podria ver cual es tu estructura, y si me
quiero asignar un bono, solo tendria que seguir el hilo de relaciones para
terminar teniendo un aumento de sueldo.

Sin embargo, si veo que tus tablas no tienen relaciones, y trato de ver los
triggers que tienes, me quedo con un palmo de narices, ya que no podria ver
nada.

Yo tenia un sistema de este tipo hace algunos ayeres, y manejabamos varias
tablas para complementar los movimientos todas con relaciones por codigo
(aplicacion o trigger), y con una sola en que no este, CAPUT, encontraste un
movimiento que no se genero desde tu sistema.

Nuestra semantica para nombres de tablas era:

2 caracteres para ver si era local o remota
3 caracteres para ubicar la tabla dentro de una entidad
1 caracter "1"
2 caracteres para indicar si era tabla primaria o foranea
2 caracteres para indicar el # de tabla dentro de la entidad (Usabamos
99, 98, 97...00)
4 caracteres para notas, tambien cada una con su clave (podian ser del
tipo, TR00 <-- Tabla para transmisiones, GOAL < TABLA SIN COMENTARIOS)

Tabla:
LOGIR10199GOAL

Campos:
np0000001
nf0000002
s_0000003

donde la primera letra era para indicar el tipo del campo y la segunda para
ver si era PK o FK

La captura de movimientos implicaba 5 tablas + 2 de verificacion y algunas
se llenaban desde el codigo de la aplicacion y otras por los triggers.

En 2 años que estuve con ese sistema, (Instalado en 600 puntos con DB local
y sincronizacion a una sola DB central ) solo una vez intentaron meter datos
por fueray al momento de realizar la sincronizacion boto, por lo que no paso
a mayores, salvo k descubrieron un empleado corrupto JA JA JA.

Aclaro que era una aplicacion para transferencias de $$$$$

Por ese motivo es k teniamos tan escondida toda la informacion, todo
encriptado, vistas, tirggers, sp, un solo usuario de base de datos para la
aplicacion con permisos definidos por tabla.

Aunque el diseño ya contemplaba estos puntos, no fue una adaptacion de una
aplicacion terminada.

Espero que te sirva de algo.


Luis E.



"Asterion" escribió en el mensaje
news:

En mi caso, es un pedido del cliente. En la empresa del cliente nadie debe
poder acceder a los datos de la aplicación navegando las tablas.

No entiendo bien los puntos 1 y 3.
¿Podrías explicarme más detenidamente qué ventajas obtengo con el trigger
"with encryption" (nunca lo hice)?.



"Luis Enrique García A." escribió:

> Es un punto complicado, puedes esconder el pass de "sa" pero no mas, lo

que

> se utiliza normalmente para incrementar la seguridad de tus sistemas y

mas

> si es en via de que no modifiquen la base de datos para realizar

reportes o

> cambios a tu informacion, estriba en:
>
> 1. No manejar integridad referencial del tipo PRIMARY KEY / FOREIGN KEY

sino

> manejar toda esa parte por trigger "WITH ENCRYPTION"
>
> 2. Nombres de objetos no genericos, es decir, tu catalogo de productos

no se

> llamara "Productos" o algo similar, sino que todas tus objetos tendran

un

> nombre del tipo "XXb125" o la semantica que tu decidas
>
> 3. Manejar vistas con triggers "INSTEAD OF" tambien "WITH ENCRYPTION"
>
> 4. Todos tus SP recompilarlos con "WITH ENCRYPTION"
>
> 5. Dependiendo de tu front end, verifica la posibilidad de almacenar tu

info

> encriptada (Esto siempre ralentiza los procesos)
>
> 6. El DBO de tu base de datos debe de ser el de tu aplicacion y sera el
> unico con acceso a ella
>
>
> Esto, no es garantia de que no entren a tu base de datos, pero al menos

les

> complicaras la vida.
>
>
> Adicionalmente, si tu SW es de pago, no olvides agregar en la licencia

la

> estructura de la base de datos.
>
> Y dentro de la garantia, la perdida de la misma si se realizan

actividades

> en la base de datos que no sean ejecutadas desde tu aplicacion.
>
>
> En fin, solo son algunos puntos, la pregunta es ¿¿¿Vale la pena invertir
> tiempo en todo esto??? tal vez te sea suficiente con el registro de

licencia

> de tu producto para evitar todo eso.
>
>
> Luis E.
>
>
>
> "José Miguel Torres" <jtorres_diaz~~ARROBA~~terra.es> escribió en el

mensaje

> news:
> > Buenas señores:
> >
> > Tengo un problema. Tengo que distribuir una aplicación a unos 20
> usuarios
> > con MSDE o SQL Server. La base de datos también entra en la

distribución.

> Mi
> > pregunta es, ¿cual es la mejor manera de asegurarme que nadie entrará

en

> la
> > base de datos para modificarla? he estudiado varias alternativas, (
> capturar
> > el sa, auditar conexión,) espero me echen una mano, muchas gracias
> desde
> > ya!
> >
> >
> > José Miguel Torres
> > jtorres_diaz~~ARROBA~~terra.es
> > http://jmtorres.blogspot.com
> >
> >
> >
>
>
>

Hola, yo en lugar de complicarla tanto (ya que el costo de mantenimiento de
esa aplicacion podria ser muy grande, y la curva de aprendizaje enorme :( )
usaria encriptacion de datos. Si usas Sp's y pasas a los param del SP's los
datos encriptados tenes todo el problema resuelto. Nadie por mas que pueda
entrar (estamos hablando de personal de sistemas porque un usuario no
deberia tener permisos sobre los objetos y mucho menos sobre operaciones de
BDD) podra tocar algo porque esta encriptado.

Esto no pone lento al servidor si la encriptacion se envia y el que
desencripta es el cliente. Tambien hay productos de terceros que encriptan
muy bien sobre la BDD, pero estos generalmente la hacen poner muy lenta con
lo cual se corren algunos riesgos de implementacion.

Un abrazo


Salu2
Maxi


"Luis Enrique García A." escribió en el mensaje
news:

Bueno, si yo puedo conectarme a la base de datos fuera de tu aplicacion, y
genero un diagrama de la misma, podria ver cual es tu estructura, y si me
quiero asignar un bono, solo tendria que seguir el hilo de relaciones para
terminar teniendo un aumento de sueldo.

Sin embargo, si veo que tus tablas no tienen relaciones, y trato de ver
los
triggers que tienes, me quedo con un palmo de narices, ya que no podria
ver
nada.

Yo tenia un sistema de este tipo hace algunos ayeres, y manejabamos varias
tablas para complementar los movimientos todas con relaciones por codigo
(aplicacion o trigger), y con una sola en que no este, CAPUT, encontraste
un
movimiento que no se genero desde tu sistema.

Nuestra semantica para nombres de tablas era:

2 caracteres para ver si era local o remota
3 caracteres para ubicar la tabla dentro de una entidad
1 caracter "1"
2 caracteres para indicar si era tabla primaria o foranea
2 caracteres para indicar el # de tabla dentro de la entidad (Usabamos
99, 98, 97...00)
4 caracteres para notas, tambien cada una con su clave (podian ser del
tipo, TR00 <-- Tabla para transmisiones, GOAL < TABLA SIN COMENTARIOS)

Tabla:
LOGIR10199GOAL

Campos:
np0000001
nf0000002
s_0000003

donde la primera letra era para indicar el tipo del campo y la segunda
para
ver si era PK o FK

La captura de movimientos implicaba 5 tablas + 2 de verificacion y algunas
se llenaban desde el codigo de la aplicacion y otras por los triggers.

En 2 años que estuve con ese sistema, (Instalado en 600 puntos con DB
local
y sincronizacion a una sola DB central ) solo una vez intentaron meter
datos
por fueray al momento de realizar la sincronizacion boto, por lo que no
paso
a mayores, salvo k descubrieron un empleado corrupto JA JA JA.

Aclaro que era una aplicacion para transferencias de $$$$$

Por ese motivo es k teniamos tan escondida toda la informacion, todo
encriptado, vistas, tirggers, sp, un solo usuario de base de datos para la
aplicacion con permisos definidos por tabla.

Aunque el diseño ya contemplaba estos puntos, no fue una adaptacion de una
aplicacion terminada.

Espero que te sirva de algo.


Luis E.



"Asterion" escribió en el mensaje
news:

En mi caso, es un pedido del cliente. En la empresa del cliente nadie
debe
poder acceder a los datos de la aplicación navegando las tablas.

No entiendo bien los puntos 1 y 3.
¿Podrías explicarme más detenidamente qué ventajas obtengo con el trigger
"with encryption" (nunca lo hice)?.



"Luis Enrique García A." escribió:

> Es un punto complicado, puedes esconder el pass de "sa" pero no mas, lo

que

> se utiliza normalmente para incrementar la seguridad de tus sistemas y

mas

> si es en via de que no modifiquen la base de datos para realizar

reportes o

> cambios a tu informacion, estriba en:
>
> 1. No manejar integridad referencial del tipo PRIMARY KEY / FOREIGN KEY

sino

> manejar toda esa parte por trigger "WITH ENCRYPTION"
>
> 2. Nombres de objetos no genericos, es decir, tu catalogo de productos

no se

> llamara "Productos" o algo similar, sino que todas tus objetos tendran

un

> nombre del tipo "XXb125" o la semantica que tu decidas
>
> 3. Manejar vistas con triggers "INSTEAD OF" tambien "WITH ENCRYPTION"
>
> 4. Todos tus SP recompilarlos con "WITH ENCRYPTION"
>
> 5. Dependiendo de tu front end, verifica la posibilidad de almacenar tu

info

> encriptada (Esto siempre ralentiza los procesos)
>
> 6. El DBO de tu base de datos debe de ser el de tu aplicacion y sera el
> unico con acceso a ella
>
>
> Esto, no es garantia de que no entren a tu base de datos, pero al menos

les

> complicaras la vida.
>
>
> Adicionalmente, si tu SW es de pago, no olvides agregar en la licencia

la

> estructura de la base de datos.
>
> Y dentro de la garantia, la perdida de la misma si se realizan

actividades

> en la base de datos que no sean ejecutadas desde tu aplicacion.
>
>
> En fin, solo son algunos puntos, la pregunta es ¿¿¿Vale la pena
> invertir
> tiempo en todo esto??? tal vez te sea suficiente con el registro de

licencia

> de tu producto para evitar todo eso.
>
>
> Luis E.
>
>
>
> "José Miguel Torres" <jtorres_diaz~~ARROBA~~terra.es> escribió en el

mensaje

> news:
> > Buenas señores:
> >
> > Tengo un problema. Tengo que distribuir una aplicación a unos 20
> usuarios
> > con MSDE o SQL Server. La base de datos también entra en la

distribución.

> Mi
> > pregunta es, ¿cual es la mejor manera de asegurarme que nadie entrará

en

> la
> > base de datos para modificarla? he estudiado varias alternativas, (
> capturar
> > el sa, auditar conexión,) espero me echen una mano, muchas
> > gracias
> desde
> > ya!
> >
> >
> > José Miguel Torres
> > jtorres_diaz~~ARROBA~~terra.es
> > http://jmtorres.blogspot.com
> >
> >
> >
>
>
>

Vaya si me sirve!!!.
La aplicación de la que hablo también es con dinero.

Muchísimas gracias por tus sugerencias.



"Luis Enrique García A." escribió:

Bueno, si yo puedo conectarme a la base de datos fuera de tu aplicacion, y
genero un diagrama de la misma, podria ver cual es tu estructura, y si me
quiero asignar un bono, solo tendria que seguir el hilo de relaciones para
terminar teniendo un aumento de sueldo.

Sin embargo, si veo que tus tablas no tienen relaciones, y trato de ver los
triggers que tienes, me quedo con un palmo de narices, ya que no podria ver
nada.

Yo tenia un sistema de este tipo hace algunos ayeres, y manejabamos varias
tablas para complementar los movimientos todas con relaciones por codigo
(aplicacion o trigger), y con una sola en que no este, CAPUT, encontraste un
movimiento que no se genero desde tu sistema.

Nuestra semantica para nombres de tablas era:

2 caracteres para ver si era local o remota
3 caracteres para ubicar la tabla dentro de una entidad
1 caracter "1"
2 caracteres para indicar si era tabla primaria o foranea
2 caracteres para indicar el # de tabla dentro de la entidad (Usabamos
99, 98, 97...00)
4 caracteres para notas, tambien cada una con su clave (podian ser del
tipo, TR00 <-- Tabla para transmisiones, GOAL < TABLA SIN COMENTARIOS)

Tabla:
LOGIR10199GOAL

Campos:
np0000001
nf0000002
s_0000003

donde la primera letra era para indicar el tipo del campo y la segunda para
ver si era PK o FK

La captura de movimientos implicaba 5 tablas + 2 de verificacion y algunas
se llenaban desde el codigo de la aplicacion y otras por los triggers.

En 2 años que estuve con ese sistema, (Instalado en 600 puntos con DB local
y sincronizacion a una sola DB central ) solo una vez intentaron meter datos
por fueray al momento de realizar la sincronizacion boto, por lo que no paso
a mayores, salvo k descubrieron un empleado corrupto JA JA JA.

Aclaro que era una aplicacion para transferencias de $$$$$

Por ese motivo es k teniamos tan escondida toda la informacion, todo
encriptado, vistas, tirggers, sp, un solo usuario de base de datos para la
aplicacion con permisos definidos por tabla.

Aunque el diseño ya contemplaba estos puntos, no fue una adaptacion de una
aplicacion terminada.

Espero que te sirva de algo.


Luis E.



"Asterion" escribió en el mensaje
news:
> En mi caso, es un pedido del cliente. En la empresa del cliente nadie debe
> poder acceder a los datos de la aplicación navegando las tablas.
>
> No entiendo bien los puntos 1 y 3.
> ¿Podrías explicarme más detenidamente qué ventajas obtengo con el trigger
> "with encryption" (nunca lo hice)?.
>
>
>
> "Luis Enrique García A." escribió:
>
> > Es un punto complicado, puedes esconder el pass de "sa" pero no mas, lo
que
> > se utiliza normalmente para incrementar la seguridad de tus sistemas y
mas
> > si es en via de que no modifiquen la base de datos para realizar
reportes o
> > cambios a tu informacion, estriba en:
> >
> > 1. No manejar integridad referencial del tipo PRIMARY KEY / FOREIGN KEY
sino
> > manejar toda esa parte por trigger "WITH ENCRYPTION"
> >
> > 2. Nombres de objetos no genericos, es decir, tu catalogo de productos
no se
> > llamara "Productos" o algo similar, sino que todas tus objetos tendran
un
> > nombre del tipo "XXb125" o la semantica que tu decidas
> >
> > 3. Manejar vistas con triggers "INSTEAD OF" tambien "WITH ENCRYPTION"
> >
> > 4. Todos tus SP recompilarlos con "WITH ENCRYPTION"
> >
> > 5. Dependiendo de tu front end, verifica la posibilidad de almacenar tu
info
> > encriptada (Esto siempre ralentiza los procesos)
> >
> > 6. El DBO de tu base de datos debe de ser el de tu aplicacion y sera el
> > unico con acceso a ella
> >
> >
> > Esto, no es garantia de que no entren a tu base de datos, pero al menos
les
> > complicaras la vida.
> >
> >
> > Adicionalmente, si tu SW es de pago, no olvides agregar en la licencia
la
> > estructura de la base de datos.
> >
> > Y dentro de la garantia, la perdida de la misma si se realizan
actividades
> > en la base de datos que no sean ejecutadas desde tu aplicacion.
> >
> >
> > En fin, solo son algunos puntos, la pregunta es ¿¿¿Vale la pena invertir
> > tiempo en todo esto??? tal vez te sea suficiente con el registro de
licencia
> > de tu producto para evitar todo eso.
> >
> >
> > Luis E.
> >
> >
> >
> > "José Miguel Torres" <jtorres_diaz~~ARROBA~~terra.es> escribió en el
mensaje
> > news:
> > > Buenas señores:
> > >
> > > Tengo un problema. Tengo que distribuir una aplicación a unos 20
> > usuarios
> > > con MSDE o SQL Server. La base de datos también entra en la
distribución.
> > Mi
> > > pregunta es, ¿cual es la mejor manera de asegurarme que nadie entrará
en
> > la
> > > base de datos para modificarla? he estudiado varias alternativas, (
> > capturar
> > > el sa, auditar conexión,) espero me echen una mano, muchas gracias
> > desde
> > > ya!
> > >
> > >
> > > José Miguel Torres
> > > jtorres_diaz~~ARROBA~~terra.es
> > > http://jmtorres.blogspot.com
> > >
> > >
> > >
> >
> >
> >

Hola:

Creo que en ese caso lo ideal sería no dar acceso a ningún usuario, y
hacerlo mediante funciones (roles) de aplicación.
Ya que si utilizas otra forma un usuario puede acceder desde una herramienta
cliente a los procedimientos almacenados a los que tenga acceso y llamarlos
con los parámetros que desee. Ten en cuenta que si hay administradores del
sistema, puede utilizar Profiler y extraer bastante información.
También ten en cuenta que si pueden hacer copias de seguridad, pueden
restaurar éstas sobre otro SQL Server y allí si que podrán tener acceso
total.

En fin, creo que a la hora de tener un administrador del sistema, gerencia
debe confiar en él, ya que prácticamente toda la información que haya en el
sistema, si se lo propone podrá consultarla.

Un saludo
Salvador Ramos
Murcia - España
[Microsoft MVP SQL Server]
www.helpdna.net (información sobre SQL server, Windows DNA y .NET)

"Asterion" escribió en el mensaje
news:

Si Maxi, esta sugerencia es buena. La cuenta de mi empresa sería sa.

Ahora, ¿cómo hago para darle acceso a los usuarios desde la aplicación?.
¿Debo usar exclusivamente sp?.
¿Debo compilar los sp "with encryption" tal cual lo sugiere el amigo
García?.