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

 

 

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

Otorgando permisos con EMS SQL Manager

3 comentarios

Como hemos visto en este artículo:

https://firebird21.wordpress.com/2013/05/29/entendiendo-los-derechos-de-acceso/

A los usuarios, a los roles y a los objetos (vistas, triggers, database triggers, stored procedures) se les puede otorgar permisos sobre las tablas y sobre los stored procedures.

Para ello podemos utilizar el programa ISQL (que viene incluido con el Firebird) o algún programa de administración gráfica.

En la imagen de abajo vemos como usaríamos el programa ISQL para ese efecto:

GRANT1

(haciendo clic en la imagen la verás más grande)

Si usamos el programa EMS SQL Manager también podemos otorgar permisos, para ello hacemos clic con el botón derecho sobre el nombre de la tabla o del stored procedure, luego elegimos la opción “Tasks” (tareas) y luego la opción “Grants for table…” como podemos ver en la imagen de abajo:

GRANT2

(haciendo clic en la imagen la verás más grande)

 Y ahora la pantalla cambiará para mostrarnos algo similar a esto:

GRANT3

(haciendo clic en la imagen la verás más grande)

 Para otorgale permisos a un usuario hacemos clic sobre su nombre y luego sobre la operación que le queremos otorgar o sobre las opciones que vemos a la izquierda. Por ejemplo, para otorgarle al usuario “Silvia” el derecho de SELECT sobre la tabla PRODUCTOS haríamos clic allí.

GRANT4

(haciendo clic en la imagen la verás más grande)

Fácilmente podemos saber si el usuario “Silvia” tiene un permiso mirando el color del botón. Si es rojo, no lo tiene.

Para otorgarle todos los permisos podemos hacer clic sucesivamente en cada botón o elegir la opción “Grant all” que se encuentra a la izquierda:

GRANT5

(haciendo clic en la imagen la verás más grande)

Después de hacer clic sobre la opción “Grant all” esto es lo que vemos (todos los colores de los botones han cambiado y también las opciones mostradas a la izquierda han cambiado)

GRANT7

(haciendo clic en la imagen la verás más grande)

Si queremos  quitarle todos los permisos utilizaríamos la opción “Revoke all”

Importante:

Para que la acción de otorgar o de quitar permisos funcione debemos hacer clic sobre la opción “Compile”. Recién después de hacer clic sobre “Compile” el usuario tendrá o dejará de tener los permisos.

GRANT6

(haciendo clic en la imagen la verás más grande)

 Resumiendo:

  • Si el botón es de color verde, tiene el permiso
  • Si el botón es de color rojo, no tiene el permiso
  • Para otorgarle todos los permisos podemos hacer clic sobre la opción “Grant all”
  • Para quitarle todos los permisos podemos hacer clic sobre la opción “Revoke all”
  • Si elegimos “with grant option” significa que el usuario puede otorgar ese mismo permiso a otros usuarios
  • Para que el usuario tenga o deje de tener estos permisos debemos hacer clic sobre la opción “Compile”

Agregando, modificando y borrando usuarios

17 comentarios

En Firebird solamente pueden conectarse a una Base de Datos y realizar operaciones en esa Base de Datos (insertar/borrar/modificar/consultar) las personas a quienes específicamente se les permite hacerlo. Si a una persona no se le otorgó el derecho de conectarse, no podrá conectarse. La forma de determinar quien puede y quien no puede conectarse a una Base de Datos es a través de dos parámetros:

  • Nombre del usuario
  • Contraseña del usuario

Para agregar, borrar, modificar y listar los usuarios se puede hacer de dos formas: usando el programa GSEC.EXE o sin usar el programa GSEC.EXE

Usando el programa GSEC.EXE

El programa GSEC.EXE se encuentra en la subcarpeta \BIN\ de la carpeta donde instalaste el Firebird, por ejemplo en la carpeta C:\ARCHIVOS DE PROGRAMA\FIREBIRD\FIREBIRD_2_5\BIN\

Debes abrir la ventana “Símbolo del sistema” y luego ubicarte en la subcarpeta \BIN\ escribiendo allí GSEC, tal como se ve en esta captura de pantalla:

GSEC1

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

Para agregar un nuevo usuario, debes escribir la palabra ADD, el nombre del usuario que deseas agregar y su contraseña, por ejemplo para agregarla a ‘FATIMA’ con contraseña ‘123456’, escribirías:

GSEC2Captura 2. Si haces clic en la imagen la verás más grande

Si deseas ver los nombres de todos los usuarios habilitados lo puedes hacer con el comando DISPLAY, tal como se ve aquí.

GSEC3

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

Como puedes ver, hay solamente dos usuarios habilitados: SYSDBA y FATIMA. El usuario SYSDBA siempre existe, puedes cambiar su contraseña si lo deseas pero no su nombre.

Para cambiar la contraseña de un usuario usas el comando MODIFY:

GSEC4

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

Aquí, se cambió la contraseña de FATIMA, desde este momento su contraseña es BONITA, la contraseña que tenía anteriormente ya no puede ser usada. A partir de este momento para conectarse a la Base de Datos deberá hacerlo con nombre = FATIMA y con contraseña = BONITA

Para borrar a un usuario:

Si por algún motivo deseas borrar (eliminar) a un usuario para que nunca más pueda conectarse a la Base de Datos, entonces en el programa GSEC.EXE debes escribir la palabra DEL y a continuación el nombre del usuario que deseas borrar, como puedes ver en la siguiente captura de pantalla:

GSEC5

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

Al eliminar a un usuario se impide que pueda conectarse a la Base de Datos. En este ejemplo a FATIMA se la eliminó de la lista de usuarios habilitados y por lo tanto ya no podrá conectarse a la Base de Datos con ese nombre.

Agregando usuarios sin usar GSEC.EXE

Lo bueno o malo de agregar usuarios con el programa GSEC.EXE (dependiendo del punto de vista y de las circunstancias) es que dichos usuarios podrán conectarse a cualquier Base de Datos. Esto puede ser malo cuando se tienen varias bases de datos en una computadora y no se quiere o necesita que algunos usuarios se conecten a algunas de ellas.

Desde Firebird 2.5 hay una forma de establecer que un usuario se conecte solamente a la Base de Datos en la cual se lo agregó. Para que pueda conectarse a dos (o más) bases de datos entonces habrá que agregarlo individualmente a esas dos (o más) bases de datos. El usuario que puede agregar nuevos usuarios es SYSDBA o cualquier otro usuario que tenga el rol RDB$ADMIN. La forma de hacerlo es la siguiente:

1. Te conectas a la Base de Datos como SYSDBA o como un usuario que tiene el rol RDB$ADMIN

2. Escribes el comando:

CREATE USER NombreUsuario PASSWORD ‘Contraseña’ [FIRSTNAME ‘PrimerNombre’] [MIDDLENAME ‘SegundoNombre’] [LASTNAME ‘Apellido’];

Ejemplos:

CREATE USER Fatima PASSWORD ‘123123’;

 CREATE USER MKenny PASSWORD ‘MMK12345’ FIRSTNAME ‘Maria’ MIDDLENAME ‘Marcela’ LASTNAME ‘Kenny’;

Para cambiar los datos de un usuario:

ALTER USER NombreUsuario [SET] [PASSWORD ‘Contraseña’] [FIRSTNAME ‘PrimerNombre’] [MIDDLENAME ‘SegundoNombre’] [LASTNAME ‘Apellido’];

Al menos uno de PASSWORD / FIRSTNAME / MIDDLENAME / LASTNAME es requerido cuando se usa ALTER USER

Ejemplo:

ALTER USER Fatima SET PASSWORD ‘Walter’;

El usuario SYSDBA puede modificar los datos de cualquier usuario. Los demás usuarios solamente pueden cambiar sus propios datos.

Para borrar los datos de un usuario:

DROP USER NombreUsuario;

Ejemplo:

DROP USER MKenny;

IMPORTANTE: No puedes utilizar ni vocales acentuadas ni eñes, esos caracteres no están permitidos.

Artículos relacionados:

El índice del blog Firebird21

El foro del blog Firebird21