Una tarea muy importante que tenemos cuando administramos una Base de Datos es limitar los derechos que los distintos usuarios tienen sobre ella. De esa manera impediremos que vean o hagan algo que no deberían ver ni hacer.

Ejemplo:

Tenemos un stored procedure llamado MiStoredProcedure el cual hace un SELECT a una tabla llamada MiTabla. El usuario ELIZABETH debe tener el derecho de ejecutar ese stored procedure. ¿Cómo le otorgamos ese derecho?

Intento 1:

   GRANT EXECUTE ON PROCEDURE MiStoredProcedure TO ELIZABETH;

   COMMIT;

Cuando ELIZABETH quiera ejecutar a MiStoredProcedure obtendrá un mensaje de error: “no permission for read/select access to TABLE MiTabla”

¿Por qué el error?

Porque MiStoredProcedure necesita permiso para realizar el SELECT a la tabla MiTabla y no tiene ese permiso.

Intento 2:

   GRANT SELECT ON MiTabla TO ELIZABETH;

   GRANT EXECUTE ON PROCEDURE MiStoredProcedure TO ELIZABETH;

   COMMIT;

Ahora sí ELIZABETH podrá ejecutar a MiStoredProcedure, no tendrá problemas para hacerlo, pero … hay algo que está mal aquí. ¿Lo has descubierto?, ¿qué es lo que está mal?

Lo que está mal es que ELIZABETH podrá escribir por su cuenta algo como:

SELECT
   *
FROM
   MiTabla;

O sea, podrá conocer todo el contenido de MiTabla y eso puede ser muy inseguro. Por ejemplo, si MiStoredProcedure recibe como parámetro de entrada el Identificador de un Cliente y devuelve el saldo de ese cliente, solamente ese dato queremos que ELIZABETH conozca. Pero si tiene derecho de SELECT sobre la tabla CLIENTES podrá conocer todos los datos de todos los clientes (nombres, direcciones, teléfonos, e-mails, etc.) y no queremos que algo así pueda suceder. Puede ser muy peligroso.

Intento 3:

   GRANT SELECT ON MiTabla TO PROCEDURE MiStoredProcedure;

   GRANT EXECUTE ON PROCEDURE MiStoredProcedure TO ELIZABETH;

   COMMIT;

La diferencia con el Intento 2 es que aquí el derecho de SELECT no se le otorgó a ELIZABETH sino que se le otorgó a MiStoredProcedure.

Como ELIZABETH tiene derecho de ejecución sobre MiStoredProcedure entonces podrá ejecutarlo cuando quiera, pero sin embargo si escribe:

SELECT
   *
FROM
   MiTabla;

Recibirá el mensaje de error: “no permission for read/select access to TABLE MiTabla”. ¿Por qué? Porque ella no tiene permiso de SELECT sobre MiTabla. Ese permiso lo tiene MiStoredProcedure, pero no lo tiene ELIZABETH.

Conclusión:

Mantener a los datos seguros y confidenciales puede ser muy importante en muchos casos, si nosotros somos buenos profesionales debemos tomar las medidas de seguridad apropiadas para que ningún usuario tenga la posibilidad de hacer aquello que no debería hacer.

En general, otorgarle a un usuario o a un rol derechos (permisos) sobre una tabla es un gran error.

Los derechos (permisos) deben otorgarse a las vistas y a los stored procedures, nunca a los usuarios ni a los roles.

De esta manera tendremos bien limitado lo que cada usuario puede hacer, y no nos encontraremos con sorpresas desagradables.

Artículos relacionados:

El índice del blog Firebird21

El foro del blog Firebird21