Permisos

El tercer paso para aterrizar el modelo de gobierno de la organización en Anjana Data, tras la definición de unidades organizativas y de roles, es establecer la configuración de permisos.

Los permisos son los que habilitan a cada rol a realizar acciones a bajo nivel en la plataforma. Constituyen el vínculo entre el rol definido y las acciones efectivas que los usuarios pueden ejecutar sobre los distintos objetos y módulos de Anjana Data.

Gracias a ellos, es posible granular el control operativo y garantizar que las responsabilidades asociadas a cada rol se materialicen de acuerdo con el modelo de gobierno de la organización.

Concepto de Permisos en Anjana Data

Cada permiso especifica qué puede hacer un rol sobre un objeto o conjunto de objetos de la plataforma. Existen permisos aplicables de dos formas:

• Permisos específicos por tipo de entidad o relación:
  Se aplican en función del metamodelo (ej. Dataset, Términos de negocio, Informes, Modelos de IA…) y determinan qué operaciones se pueden realizar sobre cada tipo de objeto (Creación y modificación, cambio de estado, deprecación, cambio de unidad organizativa y owner de la unidad organizativa).

• Permisos globales de aplicación:
  Se aplican de manera transversal en la plataforma, independientemente del dominio o entidad (ej. ACCESS, ADMIN, LINEAGE_ACCESS).

Tipos de Permisos

1. Permisos por entidades y relaciones (metamodelo)

• AUTOMATIC_METADATA: creación de entidades o relaciones de manera asistida en el wizard de creación del portal de datos mediante descubrimiento e importación automática vía plugin.

• CHANGE_STATUS: activar o desactivar entidades o relaciones no nativas.

• CHANGE_OU: modificar la unidad organizativa de una entidad para cambiar la custodia del activo.

• CREATION_MODIF: crear, modificar y enviar a validar entidades o relaciones.

• DELETE_ALL: eliminar entidades o relaciones, independientemente del creador.

• DELETE_MY_OBJ: eliminar entidades o relaciones creados por el propio usuario.

• DEPRECATION: deprecar manualmente entidades nativas.

• ORGANIZATIONAL_UNIT_OWNER: actuar como propietario de entidades dentro de la Unidad Organizativa (OU) asignada.

  • Los usuarios con este permiso aparecerán en la pantalla de Intervinientes (Stakeholders) como Propietario.

  • Al crear y aprobar un DSA, dichos usuarios podrán ser añadidos automáticamente al grupo de acceso correspondiente (esta automatización dependerá de la configuración técnica del plugin que gestione las adherencias)

2. Permisos globales a nivel plataforma

• ACCESS: acceso al portal de datos para visualización de objetos (para el subtipo ALL) y carrito de adherencias (para el subtipo ADHERENCE).

• ADMIN: acceso al panel de administración.

• API_ADMIN: uso de la API administrativa, uso de edición masiva de objetos en el portal de datos y uso de las acciones del panel de administración ( Actions) .

• CREDENTIAL_ADMIN: gestión de credenciales para autenticación (por base de datos) y autorización (acceso a tablas Users y User-OU-Roles) y acceso a configuración técnica ( tabla appConfigurations del panel de configuración).

• LINEAGE_ACCESS: visualización de linaje en el portal de datos.

• WIZARD: acceso al asistente de creación de objetos (requiere CREATION_MODIF o AUTOMATIC_METADATA) en el portal de datos.

• WORKFLOW_ACCESS: acceso, aprobación o rechazo de flujos de validación en el portal de datos.

Tabla Permissions del Panel de Configuración (Visión administrador)

Los permisos se configuran en la tabla Permissionsdel panel de configuración. La definición de los permisos es un paso indispensable para poder acceder a la plataforma (portal de datos o panel de configuración) y realizar acciones dentro de la misma.

Estructura de la tabla Permissions

Cada permiso registrado se caracteriza por los siguientes campos:

Cada registro de la tabla define un permiso y se compone de los siguientes campos:

• id: identificador único del permiso dentro de la tabla.

  • Se asigna automáticamente en base a las secuencias de base de datos.

• action: acción específica que se autoriza.

  • Para asignar acciones, ver las combinaciones posibles de la tabla de permisos

• subType: objeto o entidad del metamodelo sobre el que aplica la acción permitida.

  • Para asignar acciones, ver las combinaciones posibles de la tabla de permisos

• role: referencia al rol al que se le asigna el permiso.

  • El combo de selección muestra los roles configurados en Roles. En caso de no aparecer el rol esperado, revisar la configuración de Roles.

Combinaciones de action y subType:

(1): Name de la tabla object_subtype

(2): No se deben definir permisos para DATASET_FIELD ya que, para él, aplican los permisos de DATASET

(3): CHANGE_OU no puede ser utilizado para INSTANCE

Alta de un Permiso en la tabla Permissions

El alta de un nuevo permiso para un rol (por ejemplo, el borrado de tratamientos de datos creados por cualquier usuario) implica añadir en la tabla Permissionsun nuevo registro.

Para añadir el registro y dar de alta un nuevo permiso:

1. Pulsar el botón New en la esquina superior derecha. Esto abrirá un asistente (wizard) con los campos definidos en el apartado Estructura de la tabla Permissions.

2. Completar los campos de permiso conforme a la estructura descrita en el apartado anterior.

3. Pulsar en Save para guardar el rol o en Cancel para descartar.

Modificación de un Permiso en la tabla Permissions

La modificación de los campos action, subType o role debe realizarse con precaución, ya que puede tener impacto en:

• Las capacidades de los usuarios dentro de la plataforma.

• La validación workflows ya que si el usuario validador no tiene acceso al módulo, no podrá realizar el paso de validación.

Configuración de los Permisos mediante acceso directo a la base de datos (Visión desarrollador)

La tabla de base de datos (BD) que contiene la parametría de los permisos tiene esta estructura:

A continuación se muestra una query de ejemplo para configurar los permisos asociados al rol de DPO:

INSERT INTO zeus."permission"
(id_permission, permission_action, sub_type, id_role)
VALUES
(258, 'ACCESS', 'ALL', 16),
(259, 'CREATION_MODIF', 'TRATAMIENTO_DE_DATOS', 16),
(260, 'DELETE_ALL', 'TRATAMIENTO_DE_DATOS', 16),
(261, 'WORKFLOW_ACCESS', 'ALL', 16),
(262, 'LINEAGE_ACCESS', 'ALL', 16);