Medidas básicas de seguridad para aplicaciones Access – Dividir el proyecto

La seguridad en entornos multiusuario para aplicaciones Access no viene configurada por defecto. Hasta la versión 2007 el propio Access traía integrado un sistema de permisos y de cifrado de los datos que se podía romper fácilmente. A partir de esa versión, Microsoft decidió eliminar  el sistema de permisos y cambiar el cifrado de datos unificando lo que antes era “Proteger la base de datos con contraseña” y “Cifrar la base de datos”.

Este paso mejora bastante la seguridad, ya que el cifrado se realiza directamente al proteger con contraseña la base de datos utilizando un algoritmo basado en la propia contraseña. No hay mucha información sobre el método de cifrado,  pero se supone que puedes elegir algoritmos de hasta 128 bits, lo que supone igualarse a plataformas en principio mucho más potentes (Edito: Después de buscar bastante, parece claro que Access 2007 utiliza RC4 de 40 bits modificable y Access 2010 utiliza AES de 128 bits por defecto).

En cuanto al sistema de permisos, deja al desarrollador vía libre para diseñar uno propio, que por muy malo que sea, difícilmente será peor que el que traía por defecto en versiones anteriores. Partiendo de la base de que cuanto más personal y poco standard sea un sistema de seguridad, más seguro será este, voy a intentar explicar unos pasos básicos para hacer las aplicaciones Access más seguras, dejando los sistemas de seguridad finales a los propios desarrolladores.

En esta serie de artículos sobre seguridad en Access trataré de ir desarrollando mediante ejemplos los pasos a seguir para hacer una aplicación Access conectada a una base de datos Access tanto o más segura que una aplicación orientada a entornos en principio más seguros. No hay duda de que si disponemos de medios para funcionar con Oracle, o incluso con Visual Basic contra SQL-Server, no tiene sentido no hacerlo, pero hay casos en los que esto no es posible y para esos casos (muy habituales tanto en PYMES como en aplicaciones departamentales de grandes empresas) están pensados estos artículos.

Voy a empezar con algo que aunque en principio parece sencillo y básico, hacerlo realmente seguro es algo más complicado. Dividir la base de datos en lo que llamaremos Front-End (FE) o aplicación y Back-End (BE) o datos.

Como todo usuario medio/alto de Access sabe, para entornos multiusuario hay que dividir el proyecto en un archivo para datos (que estará en el servidor) y la aplicación en si misma (que estará en cada equipo cliente). El procedimiento es sencillo, hay un apartado en “Herramientas de la base de datos” que realiza todo el proceso.

Imagen 1 – Dividir Base de datos

Una vez dividida la base de datos, tendremos 2 archivos, en nuestro caso Prueba_Seguridad (FE) y Prueba_Seguridad_be (BE). Con esto podríamos empezar a funcionar instalando el FE en cada uno de los equipos cliente pero nuestros datos estarían sin cifrar y sin proteger, se podría acceder directamente al BE.

Como he comentado al principio del artículo, a partir de Access 2007, podemos proteger el BE con contraseña a la vez que ciframos los datos simplemente abriendo la base de datos en modo exclusivo y utilizando la funcionalidad “Cifrar con contraseña” del menú archivo. Sobra decir que intentaremos utilizar contraseñas fuertes (letras mayúsculas, minúsculas, cifras, alfanuméricos…), ya que por muy fuerte que sea el sistema de seguridad, si lo protegemos con contraseñas débiles, nos puede traer problemas (aunque en artículos posteriores veremos que se pueden crear sistemas de control de acceso de varios niveles).

Imagen 2 – Cifrar base de datos

Una vez protegidos los datos con cifrado y contraseña, observamos que ahora no podemos abrir las tablas vinculadas desde nuestro FE. La solución que se tiende a utilizar es volver a vincular las tablas. Con esto, Access nos vuelve a pedir la contraseña y la guarda en la propiedad Connect del objeto TableDef, que un posible atacante podría utilizar para romper nuestra seguridad (esto puede parecer complicadísimo, pero simplemente cambiando la vista de Access para que muestre las tablas de sistema podremos ver la contraseña en la columna Connect de la tabla MSysObjects).

Para evitar esto, utilizaremos un método sencillo y eficaz para conectar nuestro FE con el BE sin necesidad de almacenar la contraseña de nuestra base de datos. Vincularemos las tablas antes de proteger el BE con contraseña (que en principio produciría un error al intentar manejarlas) pero al inicio de nuestra aplicación abriremos un recordset mediante código que permanecerá abierto durante la ejecución de la aplicación, dejando así abierta la conexión al BE, lo que nos permitirá no introducir la contraseña desde el FE.

Una posible implementación (no la más eficaz, pero eso lo dejo para cada desarrollador) podría ser la siguiente:

• -Vincular las tablas antes de proteger el BE con contraseña.
• -Proteger y cifrar el BE
• -Crear una tabla sin datos en el BE (la llamaremos FALSA) y dejarla sin vincular.
• -Abrirla por código al inicio de la aplicación cargando un formulario.
• -Cargar en el recordset del formulario los datos.
• -Ocultar el formulario e iniciar la aplicación.

El código que tendría el formulario al cargarse sería el siguiente:

Private Sub Form_Load()
Dim MiBD As DAO.Database
Dim rs_seguridad As DAO.Recordset

Set MiBD = CurrentDb
Set rs_seguridad = MiBD.OpenRecordset("SELECT * from FALSA IN '' [MS Access;PWD=Contraseña;DATABASE=RUTA SERVIDOR\Prueba_Seguridad_be]”, dbOpenDynaset)

Set Me.Recordset = rs_seguridad

End Sub

Donde Contraseña será la contraseña de nuestro BE (edito:Ahora que sabemos como encriptar contraseñas con Sha-2, podemos encontrar una solución mejor para no tener que escribir la contraseña en el código de nuestro proyecto. Una posible implementación sería pasar la contraseña ya encriptada a una función que la desencripte con un algoritmo simétrico aplicando varias capas, por ejemplo con hashes) y RUTA SERVIDOR será la ruta en la que tengamos nuestro BE.

Al ocultar el formulario y dejarlo abierto durante la ejecución de la aplicación, Access nos permite abrir las tablas vinculadas sin necesidad de introducir la contraseña y sin que quede guardada en ningún sitio. Hay otras muchas opciones para realizar esta operación, por ejemplo aprovechar el formulario de login, que más tarde explicaré, pero como decía antes, cuanto más personalizada sea la seguridad de la aplicación, más difícil de romper resultará.

En estos momentos ya disponemos de un proyecto mucho más seguro. El BE está cifrado y protegido con contraseña, podemos acceder desde nuestro FE a las tablas directamente y la contraseña no se guarda. Falta mucho, pero es un buen inicio.

The following two tabs change content below.

• Bio
• Latest Posts

Arkaitz Arteaga

Administrador at Programador de Palo

Llevo más de 10 años programando, sobre todo en Visual Basic y con bases de datos Access. Para mí, VBA y Access siguen siendo herramientas muy potentes. He desarrollado varios proyectos con PHP y MySql. Si sumo las webs que he tenido, probablemente pasaría de 100. Ahora prefiero dedicar todo mi esfuerzo a este blog (aunque sigo manteniendo unas cuantas...). Trabajo en la administración pública (si, soy funcionario), pero he trabajado en pequeñas empresas e incluso en una "grande" de las telecomunicaciones. Ultimamente estoy bastante metido en abrirme nuevos horizontes con C# y .NET. Renovarse o morir!

Latest posts by Arkaitz Arteaga (see all)

• Access: Encriptar contraseñas con SHA-256 utilizando biblioteca de clases .NET con C# - 4 mayo, 2014
• Rendimiento de Access contra backend Access en servidor de archivos remoto. Cuarta parte. - 27 abril, 2014
• Rendimiento de Access contra backend Access en servidor de archivos remoto. Aclaración. - 21 abril, 2014
• Utilizar biblioteca de clases .NET en Access. Tercera aproximación a la Interoperabilidad COM - 14 abril, 2014
• Vincular tablas en Access con Visual Basic - 11 abril, 2014