** NORMAS DEL FORO **
Inicio del foro Inicio del foro > Access y VBA > Access y VBA
  Mensajes nuevos Mensajes nuevos RSS - Proteger Tablas y consultas
  Preguntas frecuentes Preguntas frecuentes  Buscar en el foro   Eventos   Registro Registro  Iniciar sesion Iniciar sesion

Tema cerradoProteger Tablas y consultas

 Responder Responder Página  123>
Autor
Mensaje
rokoko Ver desplegable
Colaborador
Colaborador
Avatar

Unido: 16/Febrero/2008
Localización: Pamplona
Estado: Sin conexión
Puntos: 1107
Enlace directo a este mensaje Tema: Proteger Tablas y consultas
    Enviado: 11/Febrero/2018 a las 20:23
Buenas!!

Estoy tocando la seguridad en acces y lo unico que me queda y no consigo es que no se puedan ver o editar las tablas y consultas.

Bloqueo la tecla shift, pero eso es facilmente vulnerable....
Tablas vinculadas...
Creo MDE, pero tablas y consultas deja editarlas
Oculto tablas y consultas mediante codigo, pero si puedo acceder mediante shift no vale para nada, las desoculto....
Abro el formulario mediante macro Autoexec, pero igual que la anterior, con shift accedo

No se que mas hacer.........he estado buscando, pero basicamente es lo de arriba.

Alguien conoce un metodo totalmente eficaz????

Saludos



Editado por rokoko - 11/Febrero/2018 a las 20:24
Arriba
Mihura Ver desplegable
Administrador
Administrador
Avatar

Unido: 06/Mayo/2005
Localización: España
Estado: Sin conexión
Puntos: 9933
Enlace directo a este mensaje Enviado: 11/Febrero/2018 a las 21:38
Si, trabajar sin tablas adjuntas.

Acceder a los datos a través de un objeto Database, cuyo nombre y password ocultas entre las propiedades de la aplicación. Exige saber MUCHO de programación.


Sin ser esa hay dos opciones:

- es tu empresa y puedes hacerlo, ocultas las tablas y pones el bloqueo del Shiftt y al que pilles tocando le cortas los dedos, lo echas de la empresa, .... etc

- trabajas de informático externo para esa empresa, adviertes al responsable de lo que pasa si alguien toca dónde no debe y cuando alguien la cague pasas la correspondiente factura por el arreglo, al culpable le darán dos 'yoyas' y tú te ganarás el sueldo (ésta es la mejor opción  LOL)



Jesús Mansilla Castells.
Saludos desde Móstoles.

Access Aplicaciones
Tecsys.es
Arriba
mounir Ver desplegable
Colaborador
Colaborador


Unido: 09/Febrero/2009
Localización: Asturias-España
Estado: Sin conexión
Puntos: 4333
Enlace directo a este mensaje Enviado: 11/Febrero/2018 a las 22:39
Hola!

Hace tiempo tengo localizado un ejemplo de un tal "Alan Cossey" que habla de implementar la conexión protegida con contraseña virtual (vPPC).

este es ele ejempo:

http://www.devhut.net/download/3972/
Un Saludo.
Arriba
javier.mil Ver desplegable
Colaborador
Colaborador
Avatar

Unido: 10/Agosto/2005
Localización: España
Estado: Sin conexión
Puntos: 4170
Enlace directo a este mensaje Enviado: 12/Febrero/2018 a las 00:07
Buenas

Cuidado con vPPC security toolkit , hay muchas versiones distintas que corren por ahi... No todas protegen lo mismo ,....... ademas dicho por el propio autor (Alan Cossey) todas sus versiones anteriores a la versión 1.009  (noviembre de 2007) son relativamente vulnerables pero a partir de la versión 1.010 el sistema es algo mas robusto.
Creo que su ultima versión fue la vPPC Security Toolkit version 1.014
Arriba
rokoko Ver desplegable
Colaborador
Colaborador
Avatar

Unido: 16/Febrero/2008
Localización: Pamplona
Estado: Sin conexión
Puntos: 1107
Enlace directo a este mensaje Enviado: 12/Febrero/2018 a las 17:33
Buenas!!!

Pues va a ser mas dificil de lo que pensaba pues......curioso que microsoft no traiga algo de serie, como si trae para formularios y modulos.(mde)
Y como mi nivel de programacion es mas bien bajo la llevo clarinete jajaja

Voy a echarle un ojo a lo de Alan Cossey, a ver de que va.....

Saludos
Arriba
jilo Ver desplegable
Colaborador
Colaborador
Avatar

Unido: 19/Diciembre/2004
Localización: TAFALLA
Estado: Sin conexión
Puntos: 745
Enlace directo a este mensaje Enviado: 12/Febrero/2018 a las 19:12
Publicado originalmente por Mihura Mihura escribió:

Si, trabajar sin tablas adjuntas.

Acceder a los datos a través de un objeto Database, cuyo nombre y password ocultas entre las propiedades de la aplicación


Me apunto a la opción de Mihura, hoy por hoy no se necesitan tener las tablas vinculadas...

Espero te sirva !!!!!!
Arriba
rokoko Ver desplegable
Colaborador
Colaborador
Avatar

Unido: 16/Febrero/2008
Localización: Pamplona
Estado: Sin conexión
Puntos: 1107
Enlace directo a este mensaje Enviado: 12/Febrero/2018 a las 21:16
Publicado originalmente por Mihura Mihura escribió:

Si, trabajar sin tablas adjuntas.

, cuyo nombre y password ocultas entre las propiedades de la aplicación. Exige saber MUCHO de programación.


Las consultas si no quieres que las toquen habria que ponerlas enformularios en SQL, bastante trabajo pero seria la solucion, los informes entiendo que tampoco se pueden editar ni borrar si es un mde.

Quedarian las tablas, alguna pista mas Mihura!!!!

Se me ocurre tambien la posibilidad de crear las vinculaciones de tablas mediante vba en un formulario y al cerrar la base de datos que se eliminen los vinculos.....pero con un poco de perreria tambien podrias saltarte esto...abres las access normalmente y cierras access desde el administrador de tareas, como no as cerrado bien no se a ejecutado el codigo para eliminar los vinculos, ahora la abres con la tecla shift y ya tienes acceso a las tablaas.....
Arriba
Mihura Ver desplegable
Administrador
Administrador
Avatar

Unido: 06/Mayo/2005
Localización: España
Estado: Sin conexión
Puntos: 9933
Enlace directo a este mensaje Enviado: 12/Febrero/2018 a las 22:13
rokoko,

Sin tablas vinculadas, como no hay tablas no pueden verlas.

Un objeto Database, con relación a este abres recordsets usando DAO y estos recordsets son los que asignas al RecordSource (o RowSource) de los formularios, informes, listas ....

Jesús Mansilla Castells.
Saludos desde Móstoles.

Access Aplicaciones
Tecsys.es
Arriba
xavi Ver desplegable
Administrador
Administrador
Avatar
Terrassa-BCN

Unido: 10/Mayo/2005
Localización: Catalunya ||||
Estado: Sin conexión
Puntos: 11508
Enlace directo a este mensaje Enviado: 12/Febrero/2018 a las 23:04
Como dice Jesús, sin tablas vinculadas.

SELECT * FROM UnaTabla In 'RutaAlaBaseDeDatos' WHERE ....

La "RutaALaBase de datos" puedes almacenarla como una propiedad personalizada o como constante dentro del código (si es un mde no podrán ver el código)

En la BackEnd puedes ocultar las tablas mediante código

Para "fastidiar" aun más, el fichero BackEnd, le cambias la extensión a DAT o a lo que te de la gana de manera que, si buscan un accdb, tampoco lo encuentren.

Con todo eso hay que tener muchas ganas de destripar la base de datos... Si se da el caso aplica las opciones que te da Jesús en el primer post: cortar dedos o facturar más.

Un saludo


Xavi, un minyó de Terrassa

Mi web
Arriba
emiliove Ver desplegable
Moderador
Moderador


Unido: 16/Junio/2009
Localización: Mexico
Estado: Sin conexión
Puntos: 4453
Enlace directo a este mensaje Enviado: 12/Febrero/2018 a las 23:11
Pero . . . .  que con eso, que la información (Tablas es del cliente)

Shocked
Arriba
ceac Ver desplegable
Colaborador
Colaborador
Avatar

Unido: 05/Octubre/2007
Localización: Colombia
Estado: Sin conexión
Puntos: 1418
Enlace directo a este mensaje Enviado: 13/Febrero/2018 a las 05:57
Yo use vPPC Security Toolkit como prueba, hace años en Access 2007 y en ese tiempo funcionaba, no recuedo la version. Tendria que mirar mi viejo disco duro.

Pero si creas tablas vinculadas y haces que la aplicación no funcione como accde si no como accdr... en los formularios compruebas que siempre que se ejecute como Runtime:

Public Function Cierre()
 If SysCmd(acSysCmdRuntime) = False Then
        MsgBox "No es Runtime"
        DoCmd.Quit
    Else
       MsgBox "Es Runtime"
    End If
End Function

Y la usas en la mayoría de los formularios, al igual que crear la macro autoexec de donde llamas tambien la funcion. Asi dificilmente pueden ingresar a las tablas vinculadas. Bueno solo es una idea!

 


Editado por ceac - 13/Febrero/2018 a las 05:59
«Todos morimos, pero sólo unos pocos viven de verdad» Mel Gibson - Corazón Valiente

Arriba
01loko Ver desplegable
Habitual
Habitual


Unido: 17/Agosto/2017
Localización: Santander
Estado: en línea
Puntos: 171
Enlace directo a este mensaje Enviado: 13/Febrero/2018 a las 06:05
1º-Entiendo que, el diseño de formularios ,consultas y report aun seguiran accesibles?
Cosa que es  preocupante, ya que pueden borrarte un control y dejar de funcionar. Mi caso los datos me ocupo de que se copien almenos dos veces por dia. me es mas problematico las horas de curro.

2º- Si es asi, ¿de la propiedad de los datos (origen del registro) no puede sacarse la fuente?

3º-¿No es extraño que Microsoft (con lo paranoide que es con la seguridad) no halla pensado en esto?

En cuanto a la factura, no siempre es facil hacer entender a alguien que su cuñada (por decir algo, en una ciudad pequeña los empleados tambien son familia) ha metido la mano donde no debia, con lo que en mas facil que se crea que no funciona bien a que han enrredado.


"El aprender no ocupa lugar, pero si mucho tiempo. Por eso aunque soy viejo sigo intentando aprender cosas nuevas cada dia"
Arriba
Mihura Ver desplegable
Administrador
Administrador
Avatar

Unido: 06/Mayo/2005
Localización: España
Estado: Sin conexión
Puntos: 9933
Enlace directo a este mensaje Enviado: 13/Febrero/2018 a las 08:54
emiliove,

Si, las tablas (es decir los datos) son propiedad del cliente. Hay que explicarle que es lo que pasa y porqué se hace.
Normalmente lo entienden (suelen ser conscientes de que tienen empleados 'enreda') y no insisten.
Y si insisten estamos en el punto dos de mi anterior post (pero con los 'fees' aumentados  LOL)
Cita
- trabajas de informático externo para esa empresa, adviertes al responsable de lo que pasa si alguien toca dónde no debe y cuando alguien la cague pasas la correspondiente factura por el arreglo, al culpable le darán dos 'yoyas' y tú te ganarás el sueldo (ésta es la mejor opción  LOL)




01loko,

1.- En una accde los diseños no son accesibles (y el código menos)
2.- Lo primero es que aplíquese la regla número 1 (no es accesible el diseño) y lo segundo es que el origen de datos se establece por código en el momento de la ejecución
3.- Micro$oft 'pasa' mucho de Access, prefiere otras cosas (por cierto, con este sistema se consigue una seguridad 'casi' tan buena como si estuvieras trabajando con una SQL de Back-End y además si quisieras usar una SQL el cambio es relativamente sencillo)

Y en cuanto al comentario de la 'cuñada', suele pasar, .... pero ese es tú trabajo, hacerle ver que si te ha contratado a ti es porque tú eres solución, no el cuñad@ de turno.





Editado por Mihura - 13/Febrero/2018 a las 08:54
Jesús Mansilla Castells.
Saludos desde Móstoles.

Access Aplicaciones
Tecsys.es
Arriba
01loko Ver desplegable
Habitual
Habitual


Unido: 17/Agosto/2017
Localización: Santander
Estado: en línea
Puntos: 171
Enlace directo a este mensaje Enviado: 13/Febrero/2018 a las 12:27
Algunas veces.... cojeria la escopeta.... me iba al mcdonals de turno y a matar "inocentes"
"El aprender no ocupa lugar, pero si mucho tiempo. Por eso aunque soy viejo sigo intentando aprender cosas nuevas cada dia"
Arriba
01loko Ver desplegable
Habitual
Habitual


Unido: 17/Agosto/2017
Localización: Santander
Estado: en línea
Puntos: 171
Enlace directo a este mensaje Enviado: 13/Febrero/2018 a las 12:34
veamos despacito:
El codigo "SELECT * FROM UnaTabla In 'RutaAlaBaseDeDatos' WHERE ...." tendria que meterlo cada vez que un formulario tenga que realizar una consulta?
en el formulario inicial?




"El aprender no ocupa lugar, pero si mucho tiempo. Por eso aunque soy viejo sigo intentando aprender cosas nuevas cada dia"
Arriba
 Responder Responder Página  123>
  Compartir tema   

Ir al foro Permisos de foro Ver desplegable