Caso de ejemplo 3: acceso de clientes con Consultas públicas a bases de datos de usuario internas

El objetivo de este caso de ejemplo es permitir el acceso de los clientes a una base de datos interna de ClearQuest, para ver registros de sus problemas, y ver otra información pública relevante.

Esto a menudo es útil para permitir el acceso de los clientes a una base de datos interna de ClearQuest, con la intención de permitirles ver registros asociados con sus problemas, enviar nuevos problemas y posiblemente ver otra información pública no específica de ningún cliente en particular.

Contexto del caso de ejemplo 3

Un aspecto clave de esta capacidad es que no se puede permitir a un cliente ver ni descubrir la existencia de ninguna información de otros clientes. Tampoco se les puede permitir ver, o descubrir, la existencia de ningún usuario interno ni de información interna.

Es importante tener en cuenta que los permisos de carpeta del espacio de trabajo sólo forman parte de la solución para conseguir el objetivo mencionado anteriormente. Muchos esquemas de ClearQuest incluyen registros que contienen datos que es posible que sea aconsejable que no vea un cliente.

La función Contexto de seguridad de Rational ClearQuest debe utilizarse para restringir la visibilidad de los registros devueltos por una consulta. Los permisos de carpeta del espacio de trabajo no restringen de ningún modo qué datos son devueltos por una consulta. Y los permisos de carpeta del espacio de trabajo no restringen en ningún modo la posibilidad de los usuarios de realizar consultas privadas. Sólo la función Contexto de seguridad de Rational ClearQuest puede restringir qué registros son devueltos por una consulta.

El desarrollador de esquemas debería modificar los tipos de registro proporcionados por el esquema, añadiendo referencias a los registros de Contexto de seguridad y, posiblemente, separando los tipos de registro lógico en varios registros donde el contenido lógico de cada registro se puede controlar separadamente, a fin de permitir realmente el acceso de los clientes a una base de datos de usuario interna. (Por ejemplo, si un registro de producto tiene la descripción de producto, el precio y el coste para producir en el registro lógico, la función de contexto de seguridad sólo podrá restringir el acceso a todo el registro, no a partes del registro. De esta forma, si un cliente no sabe el coste para producir el producto, entonces dicha información deberá estar en un registro independiente. Esta separación de registros puede ser muy compleja y conducir a otros problemas, por lo que no se recomienda

Flujo de trabajo del caso de ejemplo 3

El administrador de seguridad realiza los siguientes pasos.

  1. Crea un grupo para los usuarios del cliente, CustUsers.
  2. Los usuarios creados para el cliente se hacen miembros del grupo del cliente, CustUsers.
  3. Otorga permiso Lectura limitada a CustUsers sobre la carpeta Consultas públicas.
  4. Crea una carpeta en Consultas públicas para el cliente, CustFolder.
  5. Otorga permiso Sólo lectura o Lectura/escritura a CustUsers sobre la carpeta CustFolder

Los usuarios del cliente sólo podrán ver su propia carpeta Consultas personales y la carpeta CustFolder junto con los elementos que haya dentro de cada una de estas dos carpetas. Si se otorga permiso Sólo lectura a la carpeta CustFolder, los usuarios del cliente no pueden crear o modificar el contenido y la carpeta debe ser gestionada por algún otro grupo que tenga permiso Lectura/escritura sobre la carpeta.

Si también tuvieran permiso Lectura/escritura sobre CustFolder, podrían crear o modificar elementos en esa carpeta, incluyendo la creación de subcarpetas, realizando de esta forma su propia gestión dentro de la carpeta.

Caso de ejemplo alternativo 3a: gestión del cliente de su propia carpeta

Una variación del caso de ejemplo anterior es separar los usuarios del cliente en dos grupos: uno para los usuarios normales y otro que podría administrar el contenido de la carpeta del cliente. Esto permitiría la utilización de CustFolder de forma similar al valor predeterminado para Carpetas públicas, es decir, donde la mayoría de los usuarios tienen acceso de sólo lectura y los usuarios seleccionados tienen acceso de lectura-escritura.

Para conseguirlo, el administrador de seguridad realiza los siguientes pasos además de los ya señalados anteriormente.

  1. Crea un grupo para los administradores del cliente, CustAdmin. Los usuarios creados para el cliente serán miembros de CustUsers o CustAdmin, dependiendo de su rol. Puede ser más adecuado tener algunos usuarios miembros de ambos grupos.
  2. Otorga permiso Lectura limitada a CustAdmin y CustUsers sobre la carpeta Consultas públicas.
  3. Otorga permiso Sólo lectura a CustUsers sobre la carpeta CustFolder (ninguna opción para Lectura/escritura, como se indica en el caso de ejemplo anterior).
  4. Otorga permiso Lectura/escritura a CustAdmin sobre la carpeta CustFolder.

En este caso, los miembros de CustAdmin podrán modificar el contenido de CustFolder, pero los usuarios que son miembros de CustUsers no podrán.

Caso de ejemplo alternativo 3b: varios grupos de cliente

Es posible que un cliente grande tenga distintos grupos internos que necesiten acceder a una base de datos interna de ClearQuest. En esta situación, existen dos casos: los grupos del cliente son independientes o cooperan entre ellos.

En el primer caso, los dos grupos del cliente son independientes y no es necesario que sepan uno del otro. Esto se tratará de la misma forma que dos clientes completamente independientes. El único problema real es qué nombres se deben utilizar para los grupos y las carpetas del cliente de ClearQuest de forma que no se pueda deducir que existen varios grupos. Esto puede o no ser crítico para la política de seguridad necesaria. Por ejemplo, la utilización de “Acme1” y “Acme2” sugerirá a un usuario de un grupo o del otro que hay un número no determinado de otros grupos “AcmeN”. La nomenclatura adecuada para esta situación se deja como ejercicio al lector.

En el segundo caso, los grupos cooperan entre ellos y tienen constancia de que cada uno de ellos está utilizando la misma base de datos. En esta situación, los nombres de grupo y carpeta son menos importantes. Existen diferentes variaciones que se podrían utilizar para este caso, dependiendo del nivel de compartimiento que se desee entre los grupos. El caso típico sería cuando cada grupo, o cada administrador de grupo, controla su propia carpeta de cliente, pero permite al otro grupo tener acceso Sólo lectura. Esto requerirá 2 ó 4 grupos, dependiendo de si cada grupo tenía un grupo separado para administración (como se describe en la sección anterior: Caso de ejemplo alternativo 3a: gestión del cliente de su propia carpeta. Otra variación sería que los grupos compartieran el rol de administración. Esto sólo tiene sentido si se utiliza el flujo anterior; permitiría la utilización de sólo 3 grupos de ClearQuest en lugar de 4: 2 para los grupos de cliente y uno para el administrador común.

Caso de ejemplo alternativo 3c: clientes que cooperan entre ellos

Se trata de una situación en la que más de un cliente está implicado en un único proyecto y ambos necesitan ver los mismos datos en la base de datos interna de ClearQuest. Esto se puede tratar de dos formas.



Comentarios