[RESUELTO] Seguridad para tablas

[jorva82]

Cordial Saludo.
Tengo una inquietud respecto a la seguridad de las tablas. ¿Es posible asegurar una tabla? ¿de tal forma que solo un usuario tenga la posibilidad de modificarla sin el uso de un formulario?.
Si existe la forma, me gustaría que me colaboraran para proteger las tablas de una base de datos que tengo y que varios usuarios tienen acceso a ella.

Saludos


Editado por el moderador (mauricio) un título claro es suficiente, no es necesario ponerlo en mayúsculas

[Cascabel]

Esto es algo que depende específicamente de la BD que utilices como backend.
Como no indicas cuál es, voy a suponer que se trata de una HSQLDB embebida. En otro caso, te remito a la documentación correspondiente, ya que se sale un poco del propósito de este foro.

Todas las HSQLDB embebidas en documentos de Base (ODB) se generan con un usuario administrador genérico por defecto.
Su nombre es "sa" (supongo que viene de standard administrator) y carece de contraseña.
Advertencia: si cambias la contraseña, te encontrarás con que al abrir el archivo ya no tienes conexión con la BD.
El administrador tiene todo tipo de permisos y puede hacer cualquier cosa con las tablas. Para eso es el administrador.

Puedes crear usuarios adicionales mediante sentencias SQL (Menú/Herramientas/SQL):

CREATE USER "USER" PASSWORD "PASS"

Crea un usuario nuevo con la contraseña que quieras. Usa comillas dobles (") para el nombre y la contraseña.

Una vez creado, se le pueden adjudicar o denegar permisos sobre las tablas. Esto debe hacerlo un administrador.

GRANT SELECT ON "TABLA" TO "USER"
REVOKE INSERT ON "TABLA" FROM PUBLIC

Usa GRANT para conceder y REVOKE para denegar permisos.
Cuando quieras dar o quitar permisos a todos los usuarios, usa PUBLIC. Si no, indica el nombre de usuario entre comillas tras FROM o TO.
Los administradores no pueden perder permisos; siempre los conservan todos.
Los permisos que puedes conceder o denegar son SELECT, INSERT, UPDATE y DELETE. Puedes usar ALL para referirte a todos los permisos a la vez.
El nombre de la tabla debe ir entre comillas si no es todo en mayúsculas.

Puedes conectarte en cualquier momento como un usuario determinado o como el administrador.

CONNECT USER "USER" PASSWORD "PASS"
CONNECT USER "sa" PASSWORD ""

Dado que el archivo te conecta como administrador al abrirlo, deberías ejecutar una macro que conectase como un usuario y vincularla al evento "Abrir documento".

Tendrías que preparar un diálogo que pidiera nombre y contraseña, construir la sentencia SQL y ejecutarla.
Dejo un ejemplo sencillo de macro con inputbox en vez de diálogos.
Asegúrate de haber creado algún usuario con contraseña no vacía antes de usarlo o no podrás conectar con la BD.

Código: Seleccionar todo

Sub ConectaUsuario(Event As Object)
	Dim sUser As String
	Dim sPass As String
	Dim sSQL As String
	Dim oStat As Object
	With ThisDatabaseDocument.CurrentController
		If Not .IsConnected Then .Connect
		oStat=.ActiveConnection.CreateStatement
	End With
	On Error Goto ErrorConecta
	Do While sUser="" Or sPass=""
		sUser=InputBox("Usuario")
		sPass=InputBox("Contraseña")
		sSQL="CONNECT USER """ & sUser & """ PASSWORD """ & sPass & """"
		oStat.ExecuteUpdate(sSQL)
	Loop
	Exit Sub
	ErrorConecta:
	sUser=""
	Resume Next
End Sub

Editado:

Ni las contraseñas ni los nombres de usuario distinguen mayúsculas de minúsculas.
Tampoco es necesario usar las comillas, a pesar de lo que indican las especificaciones de HSQL. Sin embargo, yo no recomiendo omitirlas.

Para cambiar la contraseña de un usuario, conectarse como tal y luego:

SET PASSWORD "NEWPASS"

Lo siguiente es para los que gusten de jugar con fuego... tengan cuidado, ¡podrían arruinar su BD!

1. Cambiar la extensión del archivo ODB a ZIP y abrir con un decompresor.
2. Buscar el archivo /database/script. Contiene las sentencias SQL que definen las tablas, restricciones, reinician los campos autonuméricos y otras cosas. Nos interesa la definición de usuarios y privilegios.
3. En el archivo habrán unas líneas parecidas a:

CREATE USER SA PASSWORD ""
GRANT DBA TO SA

Crean el usuario por defecto y se le conceden privilegios de administrador (DBA).
Lo podemos cambiar por algo así:

CREATE USER SA PASSWORD ""
CREATE USER USER PASSWORD "PASS"
GRANT SELECT ON PUBLIC."TABLA" TO PUBLIC
GRANT DBA TO USER

Con lo que conseguimos que el usuario por defecto (SA) no tenga más que privilegios de consulta (SELECT) en la tabla "TABLA" del esquema PUBLIC.
Por el contrario, concedemos los privilegios de administrador al usuario USER, que está protegido por contraseña.

4. Guardar los cambios en el script, volver a empaquetar el ZIP y devolver la extensión ODB.
5. La base de datos está lista para usar.

Pro: No hace falta correr una macro para proteger el archivo, porque se abre con el usuario SA que tiene permisos limitados. Alguien que quiera saltarse las restricciones lo tiene un poco más complicado (no demasiado XD).
Contra: A veces queda sin borrar el archivo LCK al salir de Base. Sin embargo, eso no impide volver a abrir el ODB.

[jorva82]

Muchas Gracias Cascabel,
Toda la explicación fue muy ilustrativa pero fue más sencillo aplicando lo del zip.
Gracias.

[SLV-es]

Hola

Aprovechando este magnífico tema he creado una adaptación en mi blog.

En cuanto al blindaje de la base de datos, he agregado un sistema equivalente al del "zip" aquí comentado, pero, al menos así lo creo yo, menos peligroso y más asequible para todos los usuarios.

Lo podeis encontrar en http://wiki.open-office.es/Gestion_de_p ... ffice_Base

Saludos