Limitando los derechos de ejecución de los usuarios

7 comentarios

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

 

 

Anuncios

¿Cuáles usuarios tienen el rol RDB$ADMIN?

Deja un comentario

Como seguramente sabes, si un usuario tiene el rol RDB$ADMIN en una Base de Datos entonces en esa Base de Datos puede hacer de todo, exactamente igual a que si fuera el usuario SYSDBA o el creador de la Base de Datos.

Por lo tanto, a veces puede ser importante responder a la pregunta: ¿Quiénes tienen el rol RDB$ADMIN en esta Base de Datos?

El siguiente SELECT te lo dirá:

SELECT
   *
FROM
   RDB$USER_PRIVILEGES
WHERE 
   RDB$RELATION_NAME = 'RDB$ADMIN';

Como puedes ver, esa información la extraemos de la tabla RDB$USER_PRIVILEGES pues es en esa tabla donde se guardan todos los privilegios (derechos, permisos) que tiene cada usuario. Obtendremos algo similar a esto:

ADMIN1

Captura 1. Si haces clic en la imagen la verás más grande

Entonces, en esta Base de Datos, hay 3 usuarios que pueden conectarse con el rol RDB$ADMIN, ellos son: WOJEDAR, FATIMA y PRUEBA.

Artículos relacionados:

Derechos que poseen los usuarios de la Base de Datos

El índice del blog Firebird21

El foro del blog Firebird21

 

Derechos que poseen los usuarios de la Base de Datos

Deja un comentario

En este artículo ya habíamos visto lo que debemos hacer para conocer los nombres de todos los usuarios de nuestra Base de Datos:

https://firebird21.wordpress.com/2013/10/15/usuarios-de-nuestra-base-de-datos/

Pero a veces nos puede interesar conocer si un usuario tiene derechos (permisos, privilegios) sobre alguna tabla, vista o stored procedure, por ejemplo:

  • ¿SUSANA puede hacerle un SELECT a la vista V_ABM_VENDEDORES?
  • ¿SUSANA puede insertarle filas a la tabla VENTAS?
  • ¿GRACIELA puede ejecutar el stored procedure llamado GRABAR_VENDEDOR?

Toda esa información (y mucha más) la encontraremos en la tabla RDB$USER_PRIVILEGES, como vemos en la Captura 1. Queremos conocer cuales son los derechos del usuario WOJEDAR, para eso escribimos:

SELECT
   *
FROM
   RDB$USER_PRIVILEGES
WHERE
   RDB$USER = 'WOJEDAR'

Y estas son las primeras filas que obtenemos:

DERECHOS1

Captura 1. Si haces clic en la imagen la verás más grande

En la columna RDB$PRIVILEGE hay una letra que nos dice que derechos (permisos, privilegios) tiene el usuario:

  • I = INSERT
  • U = UPDATE
  • D = DELETE
  • S = SELECT
  • R = puede relacionar tablas mediante una FOREIGN KEY
  • X = puede ejecutar el stored procedure

El nombre de la tabla, la vista, o el stored procedure se guarda en la columna RDB$RELATION_NAME.

Entonces, para responder a la primera pregunta podríamos escribir algo como:

SELECT
   *
FROM
   RDB$USER_PRIVILEGES
WHERE
   RDB$USER_NAME = 'SUSANA' AND
   RDB$RELATION_NAME = 'VENDEDORES'

 Y si vemos una fila que tiene una letra “S” en la columna RDB$PRIVILEGE, entonces SUSANA sí puede hacerle un SELECT a la tabla VENDEDORES.

Conclusión:

Siempre es importante saber que derechos tiene cada usuario, si no queremos que el usuario MIRTHA tenga un derecho debemos verificar que ya no lo esté teniendo. Los derechos pueden ser otorgados por el usuario SYSDBA, por el creador de la Base de Datos o por cualquier usuario que tenga el rol RDB$ADMIN WITH GRANT OPTION. Si hay un problema de comunicación entre ellos entonces uno podría estar otorgándole un derecho a MIRTHA que MIRTHA no debería tener.

Para estar seguros de que MIRTHA tiene (o no tiene) un derecho lo que debemos hacer es consultar la tabla RDB$USER_PRIVILEGES, ya que es la única forma en que podremos estar 100% seguros de que tiene o no tiene ese derecho.

Artículos relacionados:

Usuarios de nuestra Base de Datos

El índice del blog Firebird21

Delegando el otorgamiento de derechos

9 comentarios

Lo usual es que el creador de la Base de Datos o el usuario SYSDBA se encarguen de otorgarles derechos (también llamados “permisos” o “privilegios”) a los usuarios y a los roles. Sin embargo, en organizaciones grandes esto puede requerir de mucho tiempo entonces tienen la posibilidad de delegar parte de su autoridad en otros usuarios, para que estos otros usuarios también puedan otorgar derechos.

El comando que sirve para otorgar derechos se llama GRANT. A su vez, el comando que sirve para quitar derechos se llama REVOKE y sus sintaxis son las siguientes:

GRANT
   {<privilegios> ON <objeto> | rol}
   TO <beneficiario>
   [WITH {GRANT|ADMIN} OPTION]
   [{GRANTED BY | AS} [USER] otorgador]
REVOKE
   [{GRANT|ADMIN} OPTION FOR]
   {<privilegios> ON <objeto> | rol}
   FROM <beneficiario>
   [{GRANTED BY | AS} [USER] otorgador]

La clásula WITH GRANT OPTION significa que el usuario que recibió ese derecho puede otorgarlo a otros usuarios, si lo desea. Desde luego que solamente puede otorgar los derechos que posee y nada más.

La cláusula WITH ADMIN OPTION se otorga a los roles y significa que el usuario que tiene un rol puede otorgar ese rol a otros usuarios, si lo desea. Por supuesto que solamente puede otorgar su propio rol y nada más.

La cláusula GRANTED BY se usa para que aparezca como otorgador del derecho no quien lo hizo, sino otro usuario. ¿Y por qué se haría eso? Para que ese otro usuario pueda revocar el derecho.

Existe un rol especial, llamado RDB$ADMIN, que le permite a quien lo recibe tener los mismos derechos que el usuario SYSDBA pero solamente en esta Base de Datos. O sea que en la práctica quien posee el rol RDB$ADMIN puede actuar como si fuera el usuario SYSDBA.

Ejemplos:

Conectado como SYSDBA:

GRANT SELECT ON BANCOS TO MARCELA WITH GRANT OPTION;

SYSDBA le otorgó a MARCELA el derecho de hacer SELECT en la tabla BANCOS y también le permite a MARCELA otorgar ese derecho a otros usuarios.

GRANT R_CONTABILIDAD TO SILVIA WITH ADMIN OPTION;

SYSDBA le otorgó a SILVIA el rol R_CONTABILIDAD y también le permite asignar ese rol a otros usuarios.

GRANT RDB$ADMIN TO FATIMA

SYSDBA le otorgó a FATIMA el rol RDB$ADMIN el cual le permite a FATIMA tener todos los derechos sobre todos los objetos de esta Base de Datos. En otras palabras: FATIMA es exactamente igual que SYSDBA en esta Base de Datos, puede hacer todo lo que SYSDBA puede hacer.

GRANT R_CONTABILIDAD TO MARCELA WITH ADMIN OPTION GRANTED BY FATIMA;

SYSDBA le otorgó a MARCELA el rol R_CONTABILIDAD y también le permite otorgar ese rol a otros usuarios, pero lo hizo en nombre de FATIMA. ¿Por qué en nombre de FATIMA? Para que FATIMA pueda, si lo desea, quitarle ese rol a MARCELA.

 Conectado como MARCELA:

GRANT SELECT ON BANCOS TO DIANA;

MARCELA tiene el derecho de otorgar el SELECT a la tabla BANCOS, así que se lo otorga a DIANA. Desde ahora ambas (MARCELA y DIANA) pueden hacer SELECT a la tabla BANCOS.

GRANT INSERT ON BANCOS TO DIANA;

Esto falla y será rechazado por el Firebird porque MARCELA no tiene el derecho de otorgar INSERT en la tabla BANCOS. Ella tiene el derecho de otorgar SELECT en la tabla BANCOS pero no tiene el derecho de otorgar INSERT en la tabla BANCOS y por lo tanto no se le permitirá hacerlo.

GRANT ALL ON BANCOS TO DIANA;

Esto falla por la misma razón: MARCELA solamente puede otorgar el derecho de SELECT y ninguno más. Si intenta otorgar otro derecho entonces será rechazada. Aquí intentó otorgar todos los derechos y fue rechazada.

GRANT SELECT ON PRODUCTOS TO DIANA;

Esto también fallará, porque MARCELA puede otorgar el derecho de hacer SELECT en la tabla BANCOS, pero no puede otorgar el derecho de SELECT en la tabla PRODUCTOS, nunca se le otorgó ese derecho y ella no puede otorgar un derecho que no posee.

REVOKE SELECT ON BANCOS FROM DIANA;

MARCELA le había otorgado el derecho de hacer SELECT en la tabla BANCOS a DIANA, así que MARCELA puede quitarle ese derecho. Desde este momento DIANA ya no podrá hacer SELECT a la tabla BANCOS.

Conectado como SILVIA

GRANT R_CONTABILIDAD TO DIANA;

SILVIA le otorgó el rol R_CONTABILIDAD a DIANA, desde ahora DIANA ya es miembro de ese rol.

GRANT R_CONTABILIDAD TO MIRTHA WITH ADMIN OPTION;

SILVIA le otorgó el rol R_CONTABILIDAD a MIRTHA y también le dió el derecho de asignar ese rol a otros usuarios.

Conectado como FATIMA

GRANT ALL ON PRODUCTOS TO MIRTHA;

Esto falla, no se le permite a FATIMA otorgarle derechos sobre la tabla PRODUCTOS a MIRTHA. ¿Y por qué falla, acaso FATIMA no posee el rol RDB$ADMIN? Sí, pero no lo usó en el momento de conectarse, por eso falló el GRANT.

Conectado como FATIMA y usando el rol RDB$ADMIN

GRANT ALL ON PRODUCTOS TO MIRTHA;

Esto sí funciona ok porque ahora FATIMA se conectó usando el rol RDB$ADMIN y por lo tanto en esta Base de Datos tiene exactamente los mismos derechos que el usuario SYSDBA.

Artículos relacionados:

Agregando, modificando y borrando usuarios

El índice del blog Firebird21